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.
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.
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.
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).
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.
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 )
Het is overigens ook mijn vakgebied, dus ik moet dit gewoon kunnen.
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.
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.
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:
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.
)