[KPN XGS-PON] Eigen router/ONT gebruiken

[jllerk]

Voor de volledigheid, dit was de bron:

https://www.reddit.com/r/Ubiquiti/comments/1t5eydz/efg_have_pppoe_hardware_accelleration/

[Workaholic]

jllerk schreef op zondag 31 mei 2026 @ 20:35:
Beste Medetweakerts,

al meer dan een jaar geniet ik van een werkende stabiele 4/4 gbit internet verbinding van KPN. Hier ben ik heel blij mee Alles werkt naar behoren alleen vanaf dag 1 kwam mijn upload snelheid nooit boven de 2.2 - 2.5 gbit. Ik hoor dat dit aan het onbreken van "PPPoE hardware offload" in de ubiquiti devices kan komen. Weten jullie hier iets meer over? De aansluiting is nu FTU -> SC APC -> SC APC -> FS XGS-ONU-25-20NI -> EFG. Misschien dat mensen hun ervaringen kunnen delen voor de beste settings die bij hun momenteel werken. bvd

Ik kan helaas bevestigen dat dit aan PPPoE ligt icm geen hardware offloading. Kijk maar naar de single threaded cpu performance bij het stress testen van je verbinding. SSH -> HTOP command

Bizar dat de 2000+ euro EFG hier geen ondersteuning voor heeft. Ik zat zelf te wachten op de udm beast maar ook hier hetzelfde verhaal. Al Schijnt deze het wel iets beter te doen door nieuwe cpu en verbeterde specs. Maar nog steeds geen hw offloading.

Enige oplossing is de ucg fiber die hw offloading heeft, kpn modem er tussen, of wachten op nieuw model… of wanneer kpn gaat afstappen van PPPoE (verwacht dat dit niet gauw gaat gebeuren).

Ik blijf daarom voorlopig maar bij 1/1G up and down. Eigenlijk voor thuis ook al meer dan voldoende :-)

[ Voor 5% gewijzigd door Workaholic op 31-05-2026 22:25 ]

[Ikkerens]

Ik zit nu ook aangesloten op XGS-PON met een Zaram SFP op mijn UCG Fiber, met KPN 4000/4000.

Maar helaas zie ik met de Zaram toch lagere snelheden dan ik met de Nokia ONT zag. Waar ik bij de Nokia ONT toch redelijk strak 3.3gbit of beter (both ways) kon trekken, zit de Zaram op 3.1gbit down en 2gbit up.

Moet ik hier nog iets bijzonders voor instellen oid? Want zover ik weet gaat die PPPoE one-liner niet helpen omdat de UCG Fiber toch dedicated hardware heeft voor PPPoE.

[jllerk]

Ik heb nu twee dagen geprobeerd met MTU waarden, MSS clamping, ipv4/ipv6 te spelen en dergelijke. En vrijwel alle servers op iperf3serverlist.net geven hetzelfde resultaat. Zet ssh aan bij console en gebruik een van de links op die site. Met -P 8 -R erachter kan je de download testen en haal ik altijd strak 3.8-4 gbit en zonder de R begint hij op 3.1 en wordt hij teruggedrongen naar 2.5 - 2.3gbit.

Met htop kan je ook zien dat de download een gedeelte van de cores naar 100% brengt en met de upload dat niet het geval is en 30-50% heeft. Het ligt volgens mij niet aan de hardware, maar ik hoor het graag als iemand dat tegendeel wil bewijzen. =]

[lesswood]

Ikkerens schreef op dinsdag 2 juni 2026 @ 14:49:
Ik zit nu ook aangesloten op XGS-PON met een Zaram SFP op mijn UCG Fiber, met KPN 4000/4000.

Maar helaas zie ik met de Zaram toch lagere snelheden dan ik met de Nokia ONT zag. Waar ik bij de Nokia ONT toch redelijk strak 3.3gbit of beter (both ways) kon trekken, zit de Zaram op 3.1gbit down en 2gbit up.

Moet ik hier nog iets bijzonders voor instellen oid? Want zover ik weet gaat die PPPoE one-liner niet helpen omdat de UCG Fiber toch dedicated hardware heeft voor PPPoE.

Ik zou verwachten dat je dan de lijn zou moeten kunnen dichtrekken. Zeker met ids/ips uit.

[Ikkerens]

lesswood schreef op dinsdag 16 juni 2026 @ 08:07:
[...]

Ik zou verwachten dat je dan de lijn zou moeten kunnen dichtrekken. Zeker met ids/ips uit.

Exact. Jammer genoeg maakt ids/ips niet eens een verschil (wat ik eigenlijk ook verwachtte aangezien de UCG rated is voor 5gbit daarvan).

Maarja, tot op heden heb ik nog geen manier gevonden om het te verbeteren, het enige wat anders is geworden is het gebruik van de Zaram.

[ernstoud]

Ikkerens schreef op woensdag 17 juni 2026 @ 00:01:
[...]

Exact. Jammer genoeg maakt ids/ips niet eens een verschil (wat ik eigenlijk ook verwachtte aangezien de UCG rated is voor 5gbit daarvan).

Maarja, tot op heden heb ik nog geen manier gevonden om het te verbeteren, het enige wat anders is geworden is het gebruik van de Zaram.

De Zaram zal het probleem niet zijn. Er zijn gebruikers op Delta die tussen 7 en 8 Gbps. halen.

[Ikkerens]

ernstoud schreef op woensdag 17 juni 2026 @ 09:00:
[...]


De Zaram zal het probleem niet zijn. Er zijn gebruikers op Delta die tussen 7 en 8 Gbps. halen.

Dan ben ik erg benieuwd waar het wel fout gaat, want zover ik weet moet mijn UCG Fiber het ook prima kunnen halen.

Tips zijn welkom?

[lesswood]

Zag deze langskomen. Gaat dit helpen bij performance ? En zo ja, hoe dit goed te configureren?

[andMax]

lesswood schreef op dinsdag 23 juni 2026 @ 15:32:
Zag deze langskomen. Gaat dit helpen bij performance ? En zo ja, hoe dit goed te configureren?

[Afbeelding]

Zojuist de early access build van Network geïnstalleerd [Settings -> Control Plane -> Network (onder Application) -> Release Channel -> Early Access] en de optie verschijnt inderdaad bij mijn KPN WAN connectie! In principe was het alleen een kwestie van het vinkje aanzetten, waarna de PPPoE verbinding opnieuw opgezet wordt.



Testen kan door te pingen naar Google, waarbij je expliciet meegeeft om 1472 bytes te gebruiken, en die geeft nu geen fragmentatie meer. Waarom 1472 en niet de volle 1500? Het pakketje mag nu maximaal 1500 bytes zijn, en bij pingen wordt er standaard al 28 gebruikt voor de IP header (20 bytes) en de ICMP header (8 bytes).

code:

ping -f -l 1472 google.com

Of je echt iets gaat merken van het verschil durf ik niet te zeggen. Zelf draaide ik het https://github.com/ishioni/unifi-pppoe-fix-mtu nu een weekje, maar merkte daar eigenlijk geen verschil van. Wel is het de ultieme tweaker gedachte dat ik nu de laatse 8 bytes per pakketje ook kan gebruiken .

[Malino]

andMax schreef op dinsdag 23 juni 2026 @ 16:51:

Wel is het de ultieme tweaker gedachte dat ik nu de laatse 8 bytes per pakketje ook kan gebruiken .

Ik gebruikte dezelfde fix, en merkte ook geen verschil in de praktijk.

Maar volgens mij is het voordeel ook niet zo zeer dat je 8 bytes meer in een pakket kwijt kan, maar dat wanneer er vanuit je lokale netwerk pakketjes verzonden worden die te groot zijn (>1492), de gateway ze niet hoeft op te knippen in kleinere stukjes, alvorens ze verder te zenden. Als alles 1500 is, kunnen ze gewoon 1 op 1 zonder wijzigingen doorgestuurd worden, wat weer rekenkracht en snelheid scheelt.

Overigens stond er in de Readme van die fix:

You might encounter configurations suggesting the parent interface should be set to 1512 to account for the 4-byte VLAN tag (1508 + 4). However, in the context of the Linux kernel network stack on these devices, this is incorrect.

• VLAN Interface (e.g., eth8.35): Must be set to 1508 to accept the full PPPoE frame.
• Parent Interface (e.g., eth8): Must also be set to 1508, NOT 1512.

The interface MTU setting defines the maximum size of the payload the interface executes on. When the VLAN interface passes the 1508-byte payload to the parent interface, the parent interface validates that the packet size does not exceed its own MTU. The 4-byte VLAN tag is added by the hardware offloading or driver logic at a layer that typically does not count towards the logical Interface MTU limit for the payload itself.

Setting the parent to 1512 is unnecessary and can sometimes lead to inconsistencies. Both the physical parent and the VLAN child interface should be aligned at 1508 to cleanly pass the RFC4638 compliant PPPoE frames.

Dit leek mij best een plausibel verhaal. Maar bij de nieuwe setting in UnifyOS viel het me na controle op dat er nu toch 1508/1512 gebruikt wordt, in plaats van 1508/1508 zoals bij de fix.

Dus: ofwel de auteur van de fix zat ernaast of Unify heeft het nu fout geïmplementeerd.

[lesswood]

Malino schreef op dinsdag 23 juni 2026 @ 18:27:
[...]

Ik gebruikte dezelfde fix, en merkte ook geen verschil in de praktijk.

Maar volgens mij is het voordeel ook niet zo zeer dat je 8 bytes meer in een pakket kwijt kan, maar dat wanneer er vanuit je lokale netwerk pakketjes verzonden worden die te groot zijn (>1492), de gateway ze niet hoeft op te knippen in kleinere stukjes, alvorens ze verder te zenden. Als alles 1500 is, kunnen ze gewoon 1 op 1 zonder wijzigingen doorgestuurd worden, wat weer rekenkracht en snelheid scheelt.

Overigens stond er in de Readme van die fix:


[...]


Dit leek mij best een plausibel verhaal. Maar bij de nieuwe setting in UnifyOS viel het me na controle op dat er nu toch 1508/1512 gebruikt wordt, in plaats van 1508/1508 zoals bij de fix.

Dus: ofwel de auteur van de fix zat ernaast of Unify heeft het nu fout geïmplementeerd.

Ik denk dat het goed geïmplementeerd is door Ubiquity:

Ifconfig geeft:

PPoE :ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500

+8 bytes header

VLAN : eth9.6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1508

+VLAN tag 4 bytes

Fysieke poort : eth9: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1512

Gateway kan hem ongewijzigd doorsturen lijkt me.

[Malino]

lesswood schreef op dinsdag 23 juni 2026 @ 20:43:
[...]

Ik denk dat het goed geïmplementeerd is door Ubiquity:

Ifconfig geeft:

PPoE :ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500

+8 bytes header

VLAN : eth9.6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1508

+VLAN tag 4 bytes

Fysieke poort : eth9: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1512

Gateway kan hem ongewijzigd doorsturen lijkt me.

Maar volgens de uitleg die ik ge-quote had, is het dus fout om die 4 bytes voor de VLAN tag mee te rekenen, en zou je voor de fysieke poort niet op 1512 moeten uitkomen als je het geheel correct wil doen.

Ik heb verder geen idee of dat waar is verder, en of het überhaupt negatieve gevolgen heeft. Maar de uitleg van de auteur van die patch klinkt niet als totale onzin en er staat expliciet bij dat 1512 inconsistencies kan opleveren, dus vandaar dat ik me afvraag wie van beiden nu gelijk heeft.

[stormfly]

Malino schreef op dinsdag 23 juni 2026 @ 21:21:
[...]

Maar volgens de uitleg die ik ge-quote had, is het dus fout om die 4 bytes voor de VLAN tag mee te rekenen, en zou je voor de fysieke poort niet op 1512 moeten uitkomen als je het geheel correct wil doen.

Ik heb verder geen idee of dat waar is verder, en of het überhaupt negatieve gevolgen heeft. Maar de uitleg van de auteur van die patch klinkt niet als totale onzin en er staat expliciet bij dat 1512 inconsistencies kan opleveren, dus vandaar dat ik me afvraag wie van beiden nu gelijk heeft.

Hangt er volgens mij vanaf of de NICoffload de tag zet of het OS. Lees: of het geplaatst wordt voor of na de OS MTU telling. Zonder offload bouwt het OS het frame op inclusief tag, dan heb je 1512 nodig. Met hardware offloading voegt de NIC de 4 bytes pas onder de MTU-accounting toe, dus tellen ze niet mee tegen de parent en is 1508 voldoende. Er gaat in beide gevallen 1512 over de lijn naar KPN.