Ik begrijp dat de (huidige) keuze voor PPPoE gemaakt is om de overgang van o.a. XS4ALL zo naadloos mogelijk te maken. Het zal nog even duren voor ikzelf de overstap kan maken (vanaf Ziggo), gezien de aanleg van glasvezel nog moet beginnen en DSL geen optie is. Maar ik vroeg me af of er wellicht in de toekomst gekeken gaat worden om naast PPPoE ook bv via DHCP op vlan-basis toegang verleend kan worden? Zou het wel eenvoudiger maken.
1 like
Momenteel zijn daar nog geen plannen voor. Waarom zou jij DHCP prefereren boven PPPoE?
Ik schuif even aan bij @Tim81. Niet alle externe routers snappen PPPoE. Ik denk dat twee VLANâs met twee keer DHCP makkelijker is voor veel routers. Ik begrijp dat FortiNet routers niet tot volle wasdom kunnen komen als PPPoE aan staat.
@Anco, waarom gebruik maken van PPPoE? 
Ook bij Ubiquiti Edgerouters (en USG) is er potentieel een performance bottleneck i.c.m. IPv6 bij PPPoE. Bij hardware offload staat specifiek:
It is currently not possible to enable IPv6 offloading for PPPoE and VLANs simultaneously.
Gezien DHCP op alle hardware standaard wordt ondersteund heeft dit voorkeur boven PPPoE, gezien je dan zeker geen last hebt van hardware offloading issues. Tevens is het dan standaard ethernet en heb je niks van doen met aanpassen van MTU / MSS clamping.
1 like
De hardware (in ieder geval in het gebied waar ik zit) heeft de mogelijkheid om âmini-jumboâ frames in te stellen. (ie. MTU = 1508) voor VLAN6.
Daardoor is het mogelijk om BINNEN de PPPoE ook 1500 byte frames te maken. Dan is MSS/MTU Clamping zeker niet nodig.
Waarom DHCP prefereren boven PPPoE? Omdat je dan niet te maken hebt met onnodige encapsulatie. Je kan gewoon gebruik maken van de volledige MTU zonder RFC 4638 nodig te hebben. En natuurlijk geeft het een klein voordeel dat de bandbreedte die anders gebruikt zou worden voor de PPPoE overhead beschikbaar blijft.
Betreft Fortinet-devices, hier nog het knowledgebase-artikel:
Fortinet KB
PPPoE Interface.
PPPoE is commonly used to connect to the provider edge.
It is handled by a PPP software process and connections are terminated in virtual interfaces where traffic is not able to be handled by hardware acceleration.
Ik wil geen aanname doen dat âhet gewoon weglaten van PPPoEâ gewoon kan. Zelf zie ik ook graag een alternatieve manier. Dat maakt het routeren op mijn eigen apparatuur (modem, pfsense, wlan), net iets eenvoudiger. pfsense(lees: freebsd) gaat ook anders om met PPPoE t.o.v. native. Met name single- versus multicore was (of is?) een ding. Met de snelheid van DSL is het nu prima, en denk ik nog niet wat de impact is van PPPoE op de huidige apparatuur met gbps snelheden.
Freedom heeft geen eigen fysieke kabel (koper/glas) liggen en is naar mijn idee hierdoor ook afhankelijk van andere partijen. Een aanname doen dat Freedom zomaar PPPoE kan laten vallen vind ik kort door de bocht.
Hier heb ik een DSL verbinding. Deze gaat in ieder geval eerst langs KPN apparatuur (koperlijn naar de Nokia apparatuur die KPN hier gebruikt) en mogelijk nog een andere partij. Het is meer de vraag hoeveel en welke lagen er nodig nodig zijn. (RFC1483 bridge, GRE tunnels, ⊠netwerk specialisten zijn hier beter in dan ik).
Toch een aanname: stel dat dit verzoek op de agenda komt (2021/202?). Ik kan mij niet voorstellen dat er geen andere vorm van overhead gaat ontstaan. Dit kan technisch-, contractueel-, administratief of anders van aard zijn. En wat is hiervan de impact op de dienst en uiteindelijk het gevolg voor een klant. (mijn denkrichting ging even richting complexere storingen waarbij de oorzaak lastiger te vinden is).
Dan vraag ik mij af of PPPoE echt een probleem is? En is een alternatief echt zoveel beter?
Ik heb me nooit bemoeid met inrichting van deze netwerkenâŠ
Ik kan me voorstellen dat PPPoE noodzakelijk is voor de wijkcentrale om doorsturen naar de juiste provider mogelijk te maken.
(Multivendor netwerken). Anders zijn al snel unieke VLANâs nodig (dus tv voor ISP1 = 4, voor ISP2 =14, voor ISP 3 = 24 ⊠Of meerdere switches (een per ISP) en gebruik van QinQ.
Dan wel moeten switches ingericht worden om met filterlijsten macaddressen van bepaalde verbindingen onderling toe te staanâŠ
PPP lost veel van dit soort issues op.
1 like
Dit zijn de redenen voor PPPoE ipv DHCP:
DHCP is per definitie gebonden aan IPv4. PPPoE is momenteel de enige mogelijkheid om IPv6 te kunnen bieden. Access netwerken bieden gewoon geen DHCPv6-relays. Met PPPoE kunnen we DHCPv6 en/of ICMPv6 ND/RA door de tunnel heen doen.
PPPoE is een handige en veilige manier om zonder echte username/password toch te kunnen authentiseren en autoriseren. De PPPoE-informatie wordt door de access-provider verrijkt met informatie over fysieke huisaansluiting (PADI tagging).
Deze âout-of-band signalingâ is veiliger en robuuster dan âin-band signalingâ wat DHCP option 82 uiteindelijk is. Het scheelt een hele hoop gedoe met gebruikersnamen en wachtwoorden. Onderschat niet wat een werk ons dat scheelt.
Nadelen zijn er ook:
Er is protocoloverhead. Momenteel is dat her-en-der nog een probleem. Maar daar werken we aan. Het streven is dat we voor iedereen RFC4638 kunnen aanzetten. Dan heeft iedereen een MTU/MRU van 1500 bytes.
De meeste CPE-hardware doet PPPoE-encapsulatie inderdaad in software. Tot gigabit snelheden moet dat prima gaan. De PPPoE-concentrators waar de tunnels eindigen doen dat overigens wel in hardware.
12 likes
Dit topic is 24 uur na het laatste antwoord automatisch gesloten. Nieuwe antwoorden zijn niet meer toegestaan.