Checkvraag: overstappen op glasvezel met PPPoE-verbinding vanaf server, toch "modem"/router nodig?

Binnenkort wil ik overstappen van VDSL op glasvezel (bij mij recent aangelegd, betreft XGSPON van KPN/Glaspoort) en ik heb een checkvraag, voor degenen die hier ervaring mee hebben.

Momenteel gebruik ik een VDSL-modem in bridge-modus in combinatie met een softwarematige router (gewoon een server met PPPoE). Dit werkt voor VDSL al heel lang feilloos.

Nu begrijp ik dat voor glasvezel geen modem nodig is in de klassieke zin van het woord (uitleg onder andere in deze geweldig behulpzame post van anon97139585: Terminologie rondom glasvezel).

Als ik het goed begrijp, kan ik straks dus helemaal zonder modem (en ook zonder “modem” in de foutieve zin). PPP en routering zijn immers op de server geconfigureerd.

Dus in plaas van
ISRA-punt —telefoonkabel— VDSL Modem (bridged) —s/ftp-kabel— server

verwacht ik te straks te hebben
—glasvezelkabel— FTU + ONT (Genexis XGS2110) —s/ftp-kabel— server

Mijn checkvraag is of die veronderstelling klopt; ik wil natuurlijk niet offline gaan omdat ik zelf een schakel vergeet.

Ik begrijp dat de meeste gebruikers met eigen apparatuur alsnog een “modem” gebruiken in de zin van een router. Die functies zitten bij mij allemaal in de server.

De voornaamste reden voor mijn twijfel: alle door Freedom genoemde gegevens voor eigen apparatuur (Welke instellingen heb ik nodig voor mijn eigen modem? | Freedom Helpdesk) zijn nu geconfigureerd op de server (die blijven trouwens grotendeels hetzelfde bij overstap op glas).
Alleen VLAN: 6 (802.1Q) is momenteel ingesteld op het modem. Het is geen optie van PPPoE.

Is er nog een schakel die dit regelt? Hoeft misschien niet omdat het hier XGSPON betreft? Doet de ONT iets op dit punt? Zie ik nog iets anders over het hoofd?

Hopelijk weet iemand dit. Gewoon overstappen en proberen lijkt me iets te risicovol.

Alvast dank voor de reacties.

Groet,
Bas

De ONT doet niets voor het afvangen van het VLAN. Om het VLAN 6 op je server te krijgen moet je dit op je server regelen.
Als je server op linux gebaseerd is, moet je een nieuwe interface maken met het VLAN nummer die gekoppeld is aan de interface die naar de ONT toe gaat. Bijvoorbeeld: eth0.6
En over deze interface moet je dan PPPoE gaan doen.

1 like

thx @subbink ! Ik had een dergelijke optie al ergens zien langskomen. Het is inderdaad linux. Het bijzondere is dat PPPoE nu gekoppeld is aan een interface zonder VLAN-nummer, en het toch werkt.

VLAN-nummer is wel ingesteld in het modem. VLAN 6 wordt daar mogelijk alsnog afgedwongen, óf het is sowieso de default.

Ik verwacht (zeker als je geen TV hebt) dat je modem nu de VLAN tag er afhaalt en je dan dus gewoon ethernet overhoudt.

1 like

Zolang je server op vlan 6 PPPoE uitstuurt blijft alles werken. De ONT zet alleen licht (glasvezel) om in electrische impulsen. Bij een ONT wordt er geloof ik ook nog wat encrypt, maar dat zou niet uit mogen maken. Ik heb hier een RPi 4 als ‘router’ en dat werkt prima, al heb ik een NTU (KPN) ipv een ONT.

Hier was de overstap van ADSL naar glas jaren geleden in de goede oude xs4all tijd, freedom heeft exact dezelfde werkwijze. De ADSL-fiber overstap was letterlijk de ethernet kabel in meterkast van het ene kastje in de andere pluggen en de PPPoE verbinding herstarten (ik was te ongeduldig om een reconnect af te wachten).

1 like

Er is weinig risico wanneer je gewoon standaard inclusief modem en de monteur overstapt. Op die paar euro besparen, doe je wmb alleen wanneer je zeker bent dat er geen risico is van & met welke malleur dan ook.

Dat je dan ms het (huur)modem niet (eens/meer) wil of gaat gebruiken of zelf(s) het (zg) beter weet dan wie dan ook in de wereld, is dan op jaarbasis een investering dat er geen risico is (of qua support).

Mocht er daarna ooit wat fout gaan, zet je alles standaard conform (helpdesk) ondersteuning neer en voorkomt een heleboel omwegen en irritaties.

Dat het straks een kwestie is van ompluggen, hoopte en vermoedde ik al. Maar toch altijd ff checken. Dank @KoffieNu. Geeft vertrouwen.

Over de reden om het op een servetje te doen, heb ik het niet gehad. Misschien nog eens een ander mooi topic over starten, mocht dat er nog niet zijn. :slight_smile:

Altijd leuk te achterhalen wat iemand anders drijft, ook als dat elders in geheel of deel als eens is besproken.

Voor mij was het simpel, ik heb al jaren een netfilter/iptables/netfilter config voor de firewall die ik naar volle tevredenheid heb afgericht. Werkt en ik kan in de code kijken wat er gebeurt en als er iets niet goed gaat met tcpdump sniffen om te debuggen. Dat gaat niet (makkelijk) in een closed-source ‘modem’. Een modem zou hier per definitie in bridged staan, dus een onnodig extra hop en stroomvreter. (en in 2 jaar geen moden huur heb ik de RPi eruit :wink: )

Het is overigens ook mijn vakgebied, dus ik moet dit gewoon kunnen.

Gaat onder meer om weten wat er in je huis op je apparatuur gebeurt, maar ook:

  • minder losse apparaten, minder afval, minder verbruik
  • software waar software volstaat; het is de hardware die de voetafdruk vergoot
  • geen bottleneck in een relatief klein apparaatje
  • minder hitte (klein behuisd, dus zeer welkom)
  • onafhankelijkheid
  • Leering ende Vermaeck

Een kleine kostenbesparing speelt niet zo’n heel grote rol, maar het hele roll-you-own-verhaal verdient een eigen topic (én een stortvloed aan aparte sites en een heel ecosysteem, als we toch bezig zijn)

Als ik het goed lees is het ompluggen en zorgen dat PPPoE over VLAN 6 gaat werken. Hoe dat het handigst in te stellen is, vind je in de instructies van je GNU/Linux distributie. Daarnaast is er vermoed ik ook nog wat nodig voor IPv6.

Extra hardware voegt in ieder geval niets toe om het te laten werken.

Lang verhaal kort: het is me gelukt om de vlan-selectie uit het modem te halen en correct te configureren op de server.

+-----+------------+--------------+-------------------+
|optie| modem vlan |  server vlan | ->    PPPoE werkt |    
|-----|------------+--------------+-------------------|
|  1  |    6       |   geen       | ->    JA          |
|  2  |    6       |   6          | ->    NEE         |
|  3  |  geen      |   geen       | ->    NEE         |
|  4  |  geen      |   6          | ->    JA          |
+-----+-----------------------------------------------+

optie 1) Deze situatie had ik al toen ik nog bij xs4all zat. Doet het prima. De server doet helemaal niets met vlan-tags. Vermoedelijk haalt het modem de tags weg, zoals subbink zegt.
optie 2 en 3) Niet verbazend dat dit niet werkt. Waarschijnlijk krijgt het verkeer hiermee dubbele vlan-tags resp. geen vlan-tags.
optie 4) Heb ik nu. Aangezien het modem bij glasvezel wegvalt, is 1 geen optie meer. Ik heb zo’n vermoeden dat de overstap nu een kwestie wordt van ompluggen (uit bridge-modem, in ONT)

De relevante instellingen voor wie er ook naar zoekt:

/etc/network/interfaces (met ens3 als interface die aan het modem hangt)

iface ens3 inet static
address 192.168.1.238/24
(…)
auto ens3.6
iface ens3.6 inet static
address 192.168.238.238/24
mtu 1508
vlan-raw-device ens3

auto ppp0
iface ppp0 inet ppp
pre-up /bin/ip link set ens3.6 up
provider freedom

/etc/ppp/peers/freedom

noipdefault
defaultroute
replacedefaultroute
hide-password
noauth
persist
mtu 1500
plugin rp-pppoe.so
nic-ens3.6
user “fake@freedom.nl”

Voor IPv6 overigens niets anders hoeven doen dan wat ik al had. Is gewoon blijven werken.

Dank voor de reacties

2 likes

bedankt voor de terugkoppeling en de configuratie die anderen weer verder kunnen helpen.

Hoi

Sommige services starten alleen nadat alle interfaces in
/etc/network/interfaces up zijn. Dit is de reden dat ik de PPP link niet
direct uit /etc/network/interfaces start maar middels een scriptje. Als de PPP link dan niet direct na de boot op komt, werkt de rest in ieder geval wel.

Vr.Gr,
Rob

1 like

Ik heb ook één zo’n service (wide-DHCPv6-client). Ik heb dat opgelost door de service te laten (her)starten na het opkomen van de ppp-interface ( in /etc/network/if-up.d zetten). Voordeel is dat ook na eventuele onderbreking van de ppp-link (komt sporadisch voor) de service weer wordt geïnitialiseerd, en daarmee de ipv6-range wordt hersteld.

1 like

Dat is hier opgelost door systemd verder af te richten… In de oude init.d setup wachte alles netjes totdat networking klaar is… systemd heeft zoveel haast dat ‘after networking’ voor 'm inhoudt ‘nadat ik gestart ben met networking’. Dat levert grote problemen hier, want netwerk starten is niet efficient hier met de stapel vlans (12) en tunnels (6) die ik heb.

Ik heb een override voor wide dhcpcd zodat ie pas start als het virtuele interface daadwerkelijk in de lucht is:

ik@vuurmuur:/etc/systemd/system/wide-dhcpv6-client.service.d# cat override.conf 
[Unit]
BindsTo=sys-devices-virtual-net-freedom.device
After=sys-devices-virtual-net-freedom.device
1 like

Hoi

Dingen hangen erg af van hoe de boot in elkaar zit.
The powers that be hadden ooit besloten Bind pas te starten na NFS mounts. Als je dan hostnamen ipv IP adressen in /etc/fstab hebt staan heb je een probleem. Wegens timeouts duurt de boot dan vele minuten.

Hier start ik dus Bind en NPTD voordat dat de PPP link er is. Als deze dan niet of traag opkomt heb ik in ieder geval een werkend systeem. En nadat de link up is worden deze dan geherstart;
De meeste services hebben een listening socket op alle interfaces ‘::’. Sommige per IP adres. En die mis je dan op de PPP link als je deze services start voor de link up is. Vandaar de restart.

Vr.Gr,
Rob

1 like

Dit topic is 24 uur na het laatste antwoord automatisch gesloten. Nieuwe antwoorden zijn niet meer toegestaan.