Zoekende naar de juiste MTU settings KPN PPPoE configuratie

[Genestealer]

Goedendag,

Ik wil graag weten of ik mijn MTU settings juist heb voor de KPN PPPoE configuratie op PfSense?



Tijdens wat speedtest oefeningen (speedtest-cli) heb ik wisselvallige resultaten. Met mijn 1000/1000 verbinding haal ik soms 900/900, maar over het algemeen zit het rond de 500+.

[ Voor 16% gewijzigd door Genestealer op 29-09-2023 12:19 ]

[lier]

Je zou de handleiding kunnen volgen:

https://kpn.com/w3/file?u...ntid=50183&mode=incontext

MTU max 1500 staat daarin.

[ Voor 7% gewijzigd door lier op 29-09-2023 13:23 ]

[CH4OS]

Een provider is volgens mij verplicht om de settings te geven wanneer je daar om vraagt, lijkt mij dat zij dus beter kunnen vertellen welke instellingen je waar nodig hebt.

[Genestealer]

lier schreef op vrijdag 29 september 2023 @ 13:22:
Je zou de handleiding kunnen volgen:

https://kpn.com/w3/file?u...ntid=50183&mode=incontext

MTU max 1500 staat daarin.

Heb ik al keer doorgenomen inderdaad. Maar je hebt je fysieke WAN connectie en je PPPoE connectie. De PPPoE connectie heb ik op 1500 gezet, en de fysieke op 1508 puur omdat ik dit bij andere heb gezien. Ik weet niet of die 2 in combinatie juist is.

De WAN_PPPOE connectie is namelijk een VLAN(6) gekoppeld op de WAN_FTTH_KPN interface.

[ Voor 8% gewijzigd door Genestealer op 29-09-2023 13:34 ]

[Bigs]

Je vergeet volgens mij de overhead van de VLAN tag. Ik heb de fysieke interface op 1512 staan, VLAN 6 op 1508 en de PPPoE op 1500. Dit is met AON glasvezel.

Ik dacht dat ik dit uit de KPN documentatie had, maar ik zie dat het daar helemaal niet in benoemd wordt 🤔 geen idee waar ik dit vandaan heb dan

[ Voor 32% gewijzigd door Bigs op 29-09-2023 13:39 ]

[Genestealer]

Bigs schreef op vrijdag 29 september 2023 @ 13:37:
Je vergeet volgens mij de overhead van de VLAN tag. Ik heb de fysieke interface op 1512 staan, VLAN 6 op 1508 en de PPPoE op 1500. Dit is met AON glasvezel.

Ik dacht dat ik dit uit de KPN documentatie had, maar ik zie dat het daar helemaal niet in benoemd wordt 🤔 geen idee waar ik dit vandaan heb dan

Het is zo dat ik VLAN6 interface nooit had toegevoegd aan mijn interface assignment in PfSense. Hierdoor heb ik de MTU ook nooit ingesteld op VLAN6. Net aangepast zoals jij hebt beschreven, maar tot dit moment zie ik nog dezelfde resultaten.

[stormfly]

Genestealer schreef op vrijdag 29 september 2023 @ 12:14:
Goedendag,

Ik wil graag weten of ik mijn MTU settings juist heb voor de KPN PPPoE configuratie op PfSense?

[Afbeelding]

Tijdens wat speedtest oefeningen (speedtest-cli) heb ik wisselvallige resultaten. Met mijn 1000/1000 verbinding haal ik soms 900/900, maar over het algemeen zit het rond de 500+.

MTU maakt dit verschil niet zo groot. En 1500 op PPPoE is goed, perfect zelfs.

Dit duidt eerder op een under powered router. Hoe is de CPU verdeling draai je hem virtueel of baremetal?

[Genestealer]

stormfly schreef op vrijdag 29 september 2023 @ 13:49:
[...]


MTU maakt dit verschil niet zo groot. Dit duidt eerder op een under powered router. Hoe is de CPU verdeling draai je hem virtueel of baremetal?

Baremetal, N100. Pfsense draait op FreeBSD dus single core PPPoE. Ik had hiervoor een APU2, daar haalde ik maar tegen de 300. De Intel N100 werd op de forums aangegeven het wel te kunnen halen. Ik haal ook zo nu en dan 900+.

[stormfly]

Genestealer schreef op vrijdag 29 september 2023 @ 13:50:
[...]


Baremetal, N100. Pfsense draait op FreeBSD dus single core PPPoE. Ik had hiervoor een APU2, daar haalde ik maar tegen de 300. De Intel N100 werd op de forums aangegeven het wel te kunnen halen. Ik haal ook zo nu en dan 900+.

Tja je zou een eerste stap kunnen maken door alleen op KPN speedtest servers te testen. Ik haal ook vaak 900 maar ook vaak zat 700 als ik in de logs kijk van de speedtest docker container.

Heb je al eens met die “deferred” tunable gespeeld voor je cores?
https://docs.netgate.com/...poe-with-multi-queue-nics

[bramassendorp]

Je kan eventueel gewoon testen met ping

https://kb.netgear.com/19...ptimal-MTU-Size-on-Router

[Genestealer]

stormfly schreef op vrijdag 29 september 2023 @ 13:53:
[...]


Tja je zou een eerste stap kunnen maken door alleen op KPN speedtest servers te testen. Ik haal ook vaak 900 maar ook vaak zat 700 als ik in de logs kijk van de speedtest docker container.

Heb je al eens met die “deferred” tunable gespeeld voor je cores?
https://docs.netgate.com/...poe-with-multi-queue-nics

Zal eens testen op KPN servers, goeie. Ja, de tunable settings heb ik inderdaad toegepast vanuit de link.

[stormfly]

Genestealer schreef op vrijdag 29 september 2023 @ 13:59:
[...]


Zal eens testen op KPN servers, goeie. Ja, de tunable settings heb ik inderdaad toegepast vanuit de link.

En wat heb je nog meer aangepast? Want met een N100 zou je gewoon de snelheden moeten halen. Met een N5105 haal ik het ook.

[Genestealer]

stormfly schreef op vrijdag 29 september 2023 @ 14:16:
[...]


En wat heb je nog meer aangepast? Want met een N100 zou je gewoon de snelheden moeten halen. Met een N5105 haal ik het ook.

code:

Tunable Name    Description Value   
net.inet6.ip6.redirect  Send ICMPv6 redirects for unforwardable IPv6 packets    0    
net.inet.ip.redirect    Enable sending IP redirects 0    
net.inet.tcp.tso    Enable TCP Segmentation Offload 0    
net.isr.dispatch        deferred     
net.inet.ip.portrange.first     1024    
net.inet.tcp.blackhole  Do not send RST on segments to closed ports 2   
net.inet.udp.blackhole  Do not send port unreachables for refused connects  1   
net.inet.ip.random_id   Assign random ip_id values  1   
net.inet.tcp.drop_synfin    Drop TCP packets with SYN+FIN set   1   
net.inet6.ip6.use_tempaddr  Create RFC3041 temporary addresses for autoconfigured addresses 0   
net.inet6.ip6.prefer_tempaddr   Prefer RFC3041 temporary addresses in source address selection  0   
net.inet.tcp.syncookies Use TCP SYN cookies if the syncache overflows   1   
net.inet.tcp.recvspace  Initial receive socket buffer size  65228   
net.inet.tcp.sendspace  Initial send socket buffer size 65228   
net.inet.tcp.delayed_ack    Delay ACK to try and piggyback it onto a data packet    0   
net.inet.udp.maxdgram   Maximum outgoing UDP datagram size  57344   
net.link.bridge.pfil_onlyip Only pass IP packets when pfil is enabled   0   
net.link.bridge.pfil_member Packet filter on the member interface   1   
net.link.bridge.pfil_bridge Packet filter on the bridge interface   0   
net.link.tap.user_open  Enable legacy devfs interface creation for all users    1   
net.link.vlan.mtag_pcp  Retain VLAN PCP information as packets are passed up the stack  1   
kern.randompid  Random PID modulus. Special values: 0: disable, 1: choose random value  347 
net.inet.ip.intr_queue_maxlen   Maximum size of the IP input queue  1000    
hw.syscons.kbd_reboot   enable keyboard reboot  0   
net.inet.tcp.log_debug  Log errors caused by incoming TCP segments  0   
net.inet.icmp.icmplim   Maximum number of ICMP responses per second 0   
vfs.read_max    Cluster read-ahead max block count  32  
kern.ipc.maxsockbuf Maximum socket buffer size  4262144 
net.inet.ip.process_options Enable IP options processing ([LS]SRR, RR, TS)  0   
kern.random.harvest.mask    Entropy harvesting mask 351 
net.route.netisr_maxqlen    maximum routing socket dispatch queue length    1024    
net.inet.udp.checksum   compute udp checksum    1   
net.inet.icmp.reply_from_interface  ICMP reply from incoming interface for non-local packets    1   
net.inet6.ip6.rfc6204w3 Accept the default router list from ICMPv6 RA messages even when packet forwarding is enabled   1   
net.key.preferred_oldsa     0   
net.inet.carp.senderr_demotion_factor   Send error demotion factor adjustment   0   
net.pfsync.carp_demotion_factor pfsync's CARP demotion factor adjustment    0   
net.raw.recvspace       65536   
net.raw.sendspace       65536   
net.inet.raw.recvspace  Maximum space for incoming raw IP datagrams 131072  
net.inet.raw.maxdgram   Maximum outgoing raw IP datagram size   131072  
kern.corefile   Process corefile name format string /root/%N.core

[stormfly]

Genestealer schreef op vrijdag 29 september 2023 @ 14:55:
[...]

code:

Tunable Name    Description Value   
net.inet6.ip6.redirect  Send ICMPv6 redirects for unforwardable IPv6 packets    0    
net.inet.ip.redirect    Enable sending IP redirects 0    
net.inet.tcp.tso    Enable TCP Segmentation Offload 0    
net.isr.dispatch        deferred     
net.inet.ip.portrange.first     1024    
net.inet.tcp.blackhole  Do not send RST on segments to closed ports 2   
net.inet.udp.blackhole  Do not send port unreachables for refused connects  1   
net.inet.ip.random_id   Assign random ip_id values  1   
net.inet.tcp.drop_synfin    Drop TCP packets with SYN+FIN set   1   
net.inet6.ip6.use_tempaddr  Create RFC3041 temporary addresses for autoconfigured addresses 0   
net.inet6.ip6.prefer_tempaddr   Prefer RFC3041 temporary addresses in source address selection  0   
net.inet.tcp.syncookies Use TCP SYN cookies if the syncache overflows   1   
net.inet.tcp.recvspace  Initial receive socket buffer size  65228   
net.inet.tcp.sendspace  Initial send socket buffer size 65228   
net.inet.tcp.delayed_ack    Delay ACK to try and piggyback it onto a data packet    0   
net.inet.udp.maxdgram   Maximum outgoing UDP datagram size  57344   
net.link.bridge.pfil_onlyip Only pass IP packets when pfil is enabled   0   
net.link.bridge.pfil_member Packet filter on the member interface   1   
net.link.bridge.pfil_bridge Packet filter on the bridge interface   0   
net.link.tap.user_open  Enable legacy devfs interface creation for all users    1   
net.link.vlan.mtag_pcp  Retain VLAN PCP information as packets are passed up the stack  1   
kern.randompid  Random PID modulus. Special values: 0: disable, 1: choose random value  347 
net.inet.ip.intr_queue_maxlen   Maximum size of the IP input queue  1000    
hw.syscons.kbd_reboot   enable keyboard reboot  0   
net.inet.tcp.log_debug  Log errors caused by incoming TCP segments  0   
net.inet.icmp.icmplim   Maximum number of ICMP responses per second 0   
vfs.read_max    Cluster read-ahead max block count  32  
kern.ipc.maxsockbuf Maximum socket buffer size  4262144 
net.inet.ip.process_options Enable IP options processing ([LS]SRR, RR, TS)  0   
kern.random.harvest.mask    Entropy harvesting mask 351 
net.route.netisr_maxqlen    maximum routing socket dispatch queue length    1024    
net.inet.udp.checksum   compute udp checksum    1   
net.inet.icmp.reply_from_interface  ICMP reply from incoming interface for non-local packets    1   
net.inet6.ip6.rfc6204w3 Accept the default router list from ICMPv6 RA messages even when packet forwarding is enabled   1   
net.key.preferred_oldsa     0   
net.inet.carp.senderr_demotion_factor   Send error demotion factor adjustment   0   
net.pfsync.carp_demotion_factor pfsync's CARP demotion factor adjustment    0   
net.raw.recvspace       65536   
net.raw.sendspace       65536   
net.inet.raw.recvspace  Maximum space for incoming raw IP datagrams 131072  
net.inet.raw.maxdgram   Maximum outgoing raw IP datagram size   131072  
kern.corefile   Process corefile name format string /root/%N.core

Heb je dit er allemaal zelf in gezet?

[Genestealer]

stormfly schreef op vrijdag 29 september 2023 @ 15:08:
[...]


Heb je dit er allemaal zelf in gezet?

Nee, zeker niet. Dit is de totale uitdraai van System Tunables. Zover ik weet heb ik alleen net.isr.dispatch zelf toegevoegd. Voor het zekere gewoon hele uitdraai, mocht er iemand zien dat iets niet goed staat.

[ChaserBoZ_]

De PPPoE header meerekenend, zou je fysieke koppelvlak nog steeds MTU 1500 kunnen zijn, maar je IP koppelvlak zou dan 1472 worden. Dan ga je nog fragmenteren, vanwege de TCP/IP headers. Feitelijk hou je netto 1452 bytes over.

Op een Cisco(/meeste routers) kun je de LAN kant forceren alle apparaten dus maximaal 1452 bytes te laten sturen, de router hoeft er dan zelf weinig aan te veranderen. Het is een lap tekst maar het dekt de lading;

https://www.cisco.com/c/n...-MSS-Adjustment-Conc.html

[stormfly]

Genestealer schreef op vrijdag 29 september 2023 @ 15:17:
[...]


Nee, zeker niet. Dit is de totale uitdraai van System Tunables. Zover ik weet heb ik alleen net.isr.dispatch zelf toegevoegd. Voor het zekere gewoon hele uitdraai, mocht er iemand zien dat iets niet goed staat.

Via de GUI is dat beter leesbaar.

[stormfly]

ChaserBoZ_ schreef op vrijdag 29 september 2023 @ 16:12:
De PPPoE header meerekenend, zou je fysieke koppelvlak nog steeds MTU 1500 kunnen zijn, maar je IP koppelvlak zou dan 1472 worden. Dan ga je nog fragmenteren, vanwege de TCP/IP headers. Feitelijk hou je netto 1452 bytes over.

Op een Cisco(/meeste routers) kun je de LAN kant forceren alle apparaten dus maximaal 1452 bytes te laten sturen, de router hoeft er dan zelf weinig aan te veranderen. Het is een lap tekst maar het dekt de lading;

https://www.cisco.com/c/n...-MSS-Adjustment-Conc.html

KPN ondersteund de nieuw variant van PPPoE waarin je volledig 1500 kunt gebruiken. 1492 is een achterhaalde standaard en voor KPN niet van toepassing als we spreken over een maximale MTU.

MSS is wel wat anders dan MTU, ik betwijfel of het dat grote gat in snelheid gaat oplossen.

Ik heb met KPN en pfSense niets ingevuld.

If a value is entered in this field, then MSS clamping for TCP connections to the value entered above minus 40 for IPv4 (TCP/IPv4 header size) and minus 60 for IPv6 (TCP/IPv6 header size) will be in effect.

[Genestealer]

stormfly schreef op vrijdag 29 september 2023 @ 16:25:
[...]


Via de GUI is dat beter leesbaar.

Dit is vanuit de GUI, alleen copy past in code zodat het hier weer wat beter leesbaar is.

[Kabouterplop01]

Draai je dual stack?

[Genestealer]

Kabouterplop01 schreef op zaterdag 30 september 2023 @ 11:54:
Draai je dual stack?

Nee.

Ik denk overigens dat het nu meer aan KPN ligt. Sinds ik de fysieke WAN connectie MTU op 1512 heb gezet en de PPPoE connectie op 1500 draait het vrij stabiel. Zie plaatje hieronder van mijn speedtest die om het uur draait. Vanaf 29e haal ik continue 800+ met wat dipjes rond de middag uur (pauze moment voor vele) en rond etenstijd.

[damige]

Voor KPN glasvezel is een WAN mtu van 1512 is correct. Dan een vlan interface met 1508 (dot1q header is 4 bytes) en de PPPOE interface met 1500 bytes(PPPOE header is 8 bytes).

Testen kan hier: https://www.speedguide.net/analyzer.php. Wanneer het goed staat is "MTU = 1500".

Het fluctueren van een speedtest kan aan veel dingen liggen. o.a KPN maar ook de (eventueel) tussenliggende provider(s) en de load van de server waartegen je speedtest.

Ook zijn er wat instellingen in pf/opnsense te modificeren die de snelheid kunnen verbeteren.

• Bijv: het in of uitschakelen van de hardware acceleratie op de interfaces. Sommige vendors van de NIC (zoals intel) kunnen hier beter mee overweg dan andere (zoals realtek).
• In mijn geval met PPPOE werkt de tunable "net.isr.dispatch" op "deferred" ook beter. zie https://docs.netgate.com/...latest/hardware/tune.html

[TheMystery]

damige schreef op zaterdag 30 september 2023 @ 14:30:
Voor KPN glasvezel is een WAN mtu van 1512 is correct. Dan een vlan interface met 1508 (dot1q header is 4 bytes) en de PPPOE interface met 1500 bytes(PPPOE header is 8 bytes).

Testen kan hier: https://www.speedguide.net/analyzer.php. Wanneer het goed staat is "MTU = 1500".

Het fluctueren van een speedtest kan aan veel dingen liggen. o.a KPN maar ook de (eventueel) tussenliggende provider(s) en de load van de server waartegen je speedtest.

Ook zijn er wat instellingen in pf/opnsense te modificeren die de snelheid kunnen verbeteren.

• Bijv: het in of uitschakelen van de hardware acceleratie op de interfaces. Sommige vendors van de NIC (zoals intel) kunnen hier beter mee overweg dan andere (zoals realtek).
• In mijn geval met PPPOE werkt de tunable "net.isr.dispatch" op "deferred" ook beter. zie https://docs.netgate.com/...latest/hardware/tune.html

Bij deze site staat bij mij een MTU van 1492 terwijl ik wel 1512 ingesteld heb op de WAN interface en op vlan 6 1508, opnsense geeft een calculated PPP van 1500, wat zou hier dan fout kunnen gaan?

[Genestealer]

TheMystery schreef op zaterdag 30 september 2023 @ 15:17:
[...]


Bij deze site staat bij mij een MTU van 1492 terwijl ik wel 1512 ingesteld heb op de WAN interface en op vlan 6 1508, opnsense geeft een calculated PPP van 1500, wat zou hier dan fout kunnen gaan?

[Afbeelding]

[Afbeelding]

Ik heb op de pppoe interface 1500 ingesteld staan, bij jou zie ik daar 1508 staan.

Test site geeft bij mij 1500 aan. Vlan6 interface heb ik niet enabled in mijn interface overzicht van Pfsense.

[Frogmen]

Ik snap dat het technisch interessant is. Maar in het gebruik merk je deze verschillen toch niet, daarvoor zijn er teveel factoren die het beinvloeden.

[stormfly]

TheMystery schreef op zaterdag 30 september 2023 @ 15:17:
[...]


Bij deze site staat bij mij een MTU van 1492 terwijl ik wel 1512 ingesteld heb op de WAN interface en op vlan 6 1508, opnsense geeft een calculated PPP van 1500, wat zou hier dan fout kunnen gaan?

[Afbeelding]

[Afbeelding]

1508 past niet in PPPoE, ik zou hem eens hardcoded op die plaats op 1500 zetten.

[TheMystery]

Genestealer schreef op zaterdag 30 september 2023 @ 15:19:
[...]


Ik heb op de pppoe interface 1500 ingesteld staan, bij jou zie ik daar 1508 staan.

Test site geeft bij mij 1500 aan. Vlan6 interface heb ik niet enabled in mijn interface overzicht van Pfsense.

Vlan 6 staat bij mij in het overzicht op unassigned met een mtu van 1500, als je vlan 6 edit kun je geen mtu instellen, ik moet even verder zoeken hoe dit goed te zetten of weet iemand dit toevallig?

[stormfly]

Frogmen schreef op zaterdag 30 september 2023 @ 15:22:
Ik snap dat het technisch interessant is. Maar in het gebruik merk je deze verschillen toch niet, daarvoor zijn er teveel factoren die het beinvloeden.

Precies dat is ook mijn visie, 1492 of 1500 gaat geen lifechanger zijn.

[damige]

Frogmen schreef op zaterdag 30 september 2023 @ 15:22:
Ik snap dat het technisch interessant is. Maar in het gebruik merk je deze verschillen toch niet, daarvoor zijn er teveel factoren die het beinvloeden.

Hier ben ik het niet mee eens, de client (bijv je computer) heeft standaard een MTU van 1500. Een server op het internet heeft ook standaard een MTU van 1500.
Deze zullen bij het opstarten van een TCP sessie een MSS van 1460 onderhandelen (wat een MTU van 1500 is in het geval van IPv4).

Als je router een MTU heeft van 1492, dan moet de ipv4 packet worden opgeknipt in 2 stukken. Dit kost de cpu van de router (en de server aan de overkant) meer CPU. Kost meer overhead op het netwerk(2x headers). En als je packetloss hebt (wat altijd voorkomt bij netwerken) heb je complexiteit bij retransmissions (aangezien de client helemaal niet weet dat een deel van zijn 1500 byte packet is verdwenen, en dus de gehele packet opnieuw moet worden verstuurd)

Je zou om dit "op te lossen" hiervoor:

• MSS clamping kunnen gebruiken op de router om een MTU van 1492 af te dwingen, maar dit is alleen voor TCP. UDP packets van dat formaat worden nog altijd gefragment.
• Het alternatief zou ook kunnen dat je op al je clients 1492 instelt als MTU.

In dat geval heb je gelijk en is het verschil niet zo groot met 1500.
De oplossingen hierboven zijn eigenlijk gewoon een lapmiddel.
Ik raad gewoon aan de router te configureren met een MTU van 1500.

[ Voor 21% gewijzigd door damige op 30-09-2023 15:37 ]

[Frogmen]

@damige En dit merk je doordat? Ik gebruik een Fritzbox en een Mac en bij een speedtest kom ik boven mijn contract waarde uit in het begin om er daarna iets onder te zakken naar 395 in plaats van 400.
Ik denk dat je gehele netwerk goed op orde hebben meer invloed heeft dan dit.

[damige]

Frogmen schreef op zaterdag 30 september 2023 @ 15:38:
@damige En dit merk je doordat? Ik gebruik een Fritzbox en een Mac en bij een speedtest kom ik boven mijn contract waarde uit in het begin om er daarna iets onder te zakken naar 395 in plaats van 400.
Ik denk dat je gehele netwerk goed op orde hebben meer invloed heeft dan dit.

Hoe sneller je router is in verhouding tot je verbinding: hoe minder je het gaat merken.
Let ook op dat doorvoersnelheid niet het enige is wat belangrijk is.
Stel dat je CPU in de router 80% load heeft om gefragmenteerde packets te verwerken. Dit heeft een effect op je latency onder load. (Bijv gamen terwijl er windows updates binnen komen)

Of als je CPU in de router sterk genoeg is en geen last heeft met het fragmenteren van packets (op jouw internet snelheid) heb je nog altijd 2x zoveel impact als 1 v/d 2 gefragmenteerde packets gedropped worden.

En packets worden altijd gedropped als je ergens een limiet bereikt. (bijv je 400mbit internet verbinding) Packetloss is namelijk de manier waarop TCP meet/weet dat hij niet harder kan.

[Frogmen]

@damige Ja je hebt gelijk maar in de praktijk tijdens het gebruik merk je het allemaal niet, op de latency na bij gamen. Blijft dat je ook alle factoren in je netwerk goed moet hebben, ben ervan overtuigd dat een goedkope switch meer invloed kan hebben.

[TheMystery]

Ik heb het gevonden op de point to point device onder advanced setting nu MTU van 1508 ingevuld, na reboot heb ik in het overzicht nu onder vlan 6 een mtu van 1508 was eerst 1500 en op de wan interface heb ik nu 1500 wat eerst 1492 was. Op de test site krijg ik nu ook 1500.



Of het ligt aan de 23.7.5 update die ik er net op heb gezet, deze heeft ook pppoe mtu fixes

[damige]

Frogmen schreef op zaterdag 30 september 2023 @ 15:50:
@damige Ja je hebt gelijk maar in de praktijk tijdens het gebruik merk je het allemaal niet, op de latency na bij gamen. Blijft dat je ook alle factoren in je netwerk goed moet hebben, ben ervan overtuigd dat een goedkope switch meer invloed kan hebben.

Het netwerk zal zo goed zijn als het zwakste punt. Dat klopt. En met hoe snel het internet tegenwoordig is merk je dat het inefficiënt is ook minder. (browsen kan ook goed met 50mbit of minder ipv 400mbit)

Maar dit topic ging over de juiste MTU settings, en dat is wat ik probeer mee te geven aan OP.

[damige]

TheMystery schreef op zaterdag 30 september 2023 @ 15:52:
Ik heb het gevonden op de point to point device onder advanced setting nu MTU van 1508 ingevuld, na reboot heb ik in het overzicht nu onder vlan 6 een mtu van 1508 was eerst 1500 en op de wan interface heb ik nu 1500 wat eerst 1492 was. Op de test site krijg ik nu ook 1500.

[Afbeelding]

Of het ligt aan de 23.7.5 update die ik er net op heb gezet, deze heeft ook pppoe mtu fixes

Ja de laatste update heeft ook het e.e.a gedaan m.b.t mtu bij PPPOE.

Top dat het werkt.

[Vorkie]

Even in plaatjes voor PFsense:

Op de WAN interface (interfaces > WAN> zet je de MTU van 1508 (of 1512, ligt aan je eigen config)



Daarna via Interfaces > Assignements> PPPs verander je de KPN PPPoE met onderstaande MTU setting onder Advanced":


Als je dit goed hebt ingesteld zou de website nu met onderstaande groene lijntjes komen.

[Plopeye]

Even de uitleg bij jullie vragen:

Standaard ethernet: 1518 bytes of 1522 indien vlan tag gebruikt. 14 bytes ethernet header + 4 bytes CRC + 4 bytes VLAN tag indien gebruikt (14+4 = 18 bytes of 14+4+4= 22bytes) na aftrek headers blijft er dus 1500 over voor een payload.

PPP ( 2 ) + PPPoE ( 6 ): 8 bytes
TCP: 20 bytes
IP: 20 bytes

Ethernet 1500 - TCP 20 - IP 20 = MSS 1460...

De vraag is dus laat KPN oversized packages toe, en kan je de VLAN tag en PPPoE header in de oversize stoppen. Zo niet, dan is het dus:

Ethernet (1500) - PPP ( 2 ) - PPPoE ( 6 ) = 1492 en wordt je MSS 1452

[kmichael]

Na aanleiding van het KPN topic waar ze recent over de MTU instellingen hebben.
Nu ben ik daar ook verder op gaan zoeken, ik kwam deze topic tegen.

Sommigen hebben het over (KPN) WAN interface in PFSense echter ik heb een tutorial gevolgd geen idee welke meer... toen moest ik de WAN NIC "ix!" die gebruikt wordt voor PPPoE en VLAN niet toevoegen als WAN
Adapter ix1 die bij available network ports staat wordt gebruikt voor de PPPoE verbinding VLAN6.




Vlan 6 config:




PPPoE


Ik haal +- 940/940 Mbit met internet only Fiber gaat rechtstreeks in PFsense (geen media converters) en intern netwerk is 10G,
Ik zie sommigen 1000+ Halen in het KPN topic door de MTU aan te passen.
Alles werkt, maar moet ik deze alsnog "ix1" nu als WAN toevoegen of zie ik wat over het hoofd waar ik de MTU van de WAN zelf kan aanpassen?