Hoe werkt MTU/MSS adjust precies?

[wallywally]

Hallo,

Ik worstel even met de vraag hoe MTU en MSS Adjust precies werken.

MTU als maximum packetsize begrijp ik, zodra het packet wat een client richting een router stuurt groter is dan de ingestelde MTU waarde zal de router gaan fragmenteren waardoor de CPU load omhoog gedreven wordt.

Normaliter is een MTU default 1500. Nu geef ik een ping -l 1472, dat is de hoogste waarde met de ping waarop ik response krijg van de tegenpartij (in dit geval 8.8.8.8). Dus blijkbaar zijn 20 bytes voor de TCP header en kom ik op 1492 (een waarde voor PPPoE, 8 bytes voor het protocol), maar ik gebruik geen PPPoE richting de provider. (Dit is overigens niet op die tunnel verbinding, daarvandaan kan ik niet pingen, dit is gewoon een testje vanuit m'n eigen segment.)

Nu heb ik wat problemen met een VPN tunnel welke een standaard MTU heeft ingesteld op de router, maar een TCP MSS adjust op 1387.

Kan iemand mij verduidelijken hoe dit precies werkt, op google en cisco websites staan wat standaard dingen over MTU maar niet specifiek voor tunnels en wat precies de bedoeling is van TCP MSS adjust. MTU op de tunnel staat overigens op 1438, naar buiten toe op 1500. Provider geeft aan (ziggo) om de MTU aan te passen naar 1456 (wat ik een rare waarde vind, maargoed). Als ik dat doe op één van de interfaces (en welke dan, de uitgaande richting provider?), gaat dat dan wel goed(?), want de devices achter de router (de user-end devices) sturen uit op 1500 lijkt me?

Any help is appreciated.

gr,

Wally

[ Voor 19% gewijzigd door wallywally op 22-12-2016 13:09 . Reden: Tunnel MTU toegevoegd. ]

[ChaserBoZ_]

Vergeet de 8 bytes voor je ping packet niet
Samen met de 20 voor de IP header kom je dan uit op 28, dus hou je die 1472 over.

Je verbinding kan dan idd 1500 bytes MTU hebben.
Bij tunneling raak je bytes kwijt aan de tunnel, en dat kan variëren in grootte.

Zijn je problemen met de VPN tunnel 100% zeker te weten te wijten aan MTU ?

[wallywally]

ChaserBoZ_ schreef op donderdag 22 december 2016 @ 13:14:
Vergeet de 8 bytes voor je ping packet niet
Samen met de 20 voor de IP header kom je dan uit op 28, dus hou je die 1472 over.

Je verbinding kan dan idd 1500 bytes MTU hebben.
Bij tunneling raak je bytes kwijt aan de tunnel, en dat kan variëren in grootte.

Zijn je problemen met de VPN tunnel 100% zeker te weten te wijten aan MTU ?

Ah ja, die 8 bytes voor ping verklaren dat idd.

Nou dat is de vraag dus, de tunnel heeft al die tijd gewoon "normaal" gewerkt. Wel zie ik heel langzaam drops oplopen op de interfaces, wat dus wel kan duiden op een MTU probleem (fragmentatie). En ziggo zegt dat de MTU op de router dus te hoog staat. Maarja, om dit even (ook nog eens remote) aan te gaan passen lijkt me wat link, ik kan daarmee de verbinding slopen lijkt me, en dan ben ik verder van huis.

Edit;
En als ik het dan goed begrijp, is mijn default MTU van 1500 richting buiten (WAN interface) een waarde, en als ik die zou aanpassen, zou ik dus ook de MTU op mijn tunnel moeten veranderen (1438) omdat ik de max waarde richting buiten aanpas. In dit geval zouden dus 62 bytes voor de tunnel nodig zijn (1438+62= 1500).

Dan zou ik de MTU waarde richting WAN dus veranderen naar 1456, en op de tunnel dus naar 1394 (1456 - 62 voor de tunnel). En wat dan te doen met die TCP MSS Adjust op de tunnel van 1387?

[ Voor 21% gewijzigd door wallywally op 22-12-2016 13:21 ]

[ChaserBoZ_]

'heeft altijd zo gewerkt'

Ik zie dat ik op mijn Ziggo verbinding inderdaad een MTU van 1500 bytes heb. Nog nooit hoeven te weten.

Kijk eens op https://networkcanuck.com...-mtu-size-over-ipsec-vpn/ voor een rekenvoorbeeld. Die kerel gebruikt IPSec, mocht je iets anders als VPN techniek gebruiken, pas dan het rekenwerk aan.

Je MTU te laag inschatten met TCP-MSS adjust is niet problematisch, dit kan leiden tot inefficiency maar het werkt. Te hoog instellen kan allerlei problemen opleveren.

[wallywally]

ChaserBoZ_ schreef op donderdag 22 december 2016 @ 14:04:
'heeft altijd zo gewerkt'

Ik zie dat ik op mijn Ziggo verbinding inderdaad een MTU van 1500 bytes heb. Nog nooit hoeven te weten.

Kijk eens op https://networkcanuck.com...-mtu-size-over-ipsec-vpn/ voor een rekenvoorbeeld. Die kerel gebruikt IPSec, mocht je iets anders als VPN techniek gebruiken, pas dan het rekenwerk aan.

Je MTU te laag inschatten met TCP-MSS adjust is niet problematisch, dit kan leiden tot inefficiency maar het werkt. Te hoog instellen kan allerlei problemen opleveren.

Ja, maar heb je ook ziggo zakelijk? En houd er rekening mee dat VPN nogal gevoelig is voor dit soort zaken, dus ik weet niet of je ook VPN's hebt lopen. Voorlopig lijkt de tunnel 62 bytes te gebruiken aangezien de MTU (automatisch lijkt) aangepast te zijn naar 1438 op de default van 1500. Het is ook IPSEC.

Thank Olemo. The consultant I brought in believes the 1435 is due to the IPSEC tunnel settings mismatch. This can only be fixed by Astaro, but they don't even recongnize the issue. It would be nice if they put it on their known issues list, or the release notes. I might try setting MTU on all firewalls IPSEC to 1460, and see what happens when the IPSEC packets are fragmented over the internet, I'm betting it's not going to be pretty. I've captured the IPSEC header at 62 bytes, but if I set MTU to 1438, https sites with packets I see usually at 1460 will be dropped, and I'll be back to square one.

Bij de accepted solution post is dit een waarde die dus blijkbaar correct kan zijn voor IPSEC tunneling.

Het probleem hier is dat ik niet als een cowboy zomaar dingen aan kan passen, want als ik mijn connection verlies moet ik onsite. Dat maakt deze kwestie wat lastiger. Ik kan niet "zomaar dingen uitproberen" zegmaar.

[ Voor 5% gewijzigd door wallywally op 22-12-2016 14:17 ]

[ChaserBoZ_]

wallywally schreef op donderdag 22 december 2016 @ 14:14:
[...]

Ja, maar heb je ook ziggo zakelijk? En houd er rekening mee dat VPN nogal gevoelig is voor dit soort zaken, dus ik weet niet of je ook VPN's hebt lopen. Voorlopig lijkt de tunnel 62 bytes te gebruiken aangezien de MTU (automatisch lijkt) aangepast te zijn naar 1438 op de default van 1500. Het is ook IPSEC.


[...]


Bij de accepted solution post is dit een waarde die dus blijkbaar correct kan zijn voor IPSEC tunneling.

Het probleem hier is dat ik niet als een cowboy zomaar dingen aan kan passen, want als ik mijn connection verlies moet ik onsite. Dat maakt deze kwestie wat lastiger. Ik kan niet "zomaar dingen uitproberen" zegmaar.

Ik zie op mijn Ziggo Ai1 thuis & op Ziggo zakelijk op het werk 1500 bytes. Ik tunnel zelf niet op dit moment.
De MTU van de tunnel lager instellen zou an sich niet zo problematisch mogen zijn, maar ik ben met je eens dat je de continuïteit voorop moet stellen.

Geen apparaat waarbij je kunt zeggen 'reload in x', mocht het niet goed gaan ?

[wallywally]

ChaserBoZ_ schreef op donderdag 22 december 2016 @ 14:44:
[...]


Ik zie op mijn Ziggo Ai1 thuis & op Ziggo zakelijk op het werk 1500 bytes. Ik tunnel zelf niet op dit moment.
De MTU van de tunnel lager instellen zou an sich niet zo problematisch mogen zijn, maar ik ben met je eens dat je de continuïteit voorop moet stellen.

Geen apparaat waarbij je kunt zeggen 'reload in x', mocht het niet goed gaan ?

Ik geloof alleen niet dat ik de MTU van de tunnel lager moet instellen maar van de WAN interface richting ziggo. Het lijkt erop dat de MTU zichzelf aanpast op de tunnels, want MTU WAN is nu 1500, MTU tunnel is nu 1438 maar dat staat nergens hard ingesteld. Dus het lijkt erop dat die tunnels zichzelf die MTU geven m.b.t. wat ze nodig hebben aan bytes voor het protocol, in dit geval 62 dus.

Het enige wat hard staat ingesteld is de TCP MSS Adjust op 1387.

[ Voor 3% gewijzigd door wallywally op 22-12-2016 15:00 ]

[josvane]

Enigzins off-topic.

Je hebt het over Cisco, gebruik je ook cisco?
Als ik op afstand wijzigingen moet maken in routers, dan maak ik gebruik van reload in ...
Op de puntjes dan een waarde in minuten. Verpest je de config gaat hij na deze tijd herstarten en komt terug op de laatst opgeslagen config.

[Kabouterplop01]

Over het algemeen is de mss adjust waarde bij een pppoe verbinding als volgt:
pppoe overhead 8bytes
tcp header 20 bytes
ip header 20 bytes
aan je ethernet kant heb je standaard mtu van 1500
1500 - 8 (pppoe-h) = 1492 - 40 (tcp-h + ip-h)= 1452 bytes.
Dit zou de grootst mogelijk MTU zijn waarbij geen fragmentatie optreedt. de meest efficiente dus.
Als je gaat VPN-en moet je op dezelfde manier testen met de packetsize in de ping, dóór de tunnel.
Hier kun je checken hoe je het kunt berekeken en er wordt een beetje uitleg gegeven.
http://baturin.org/tools/encapcalc/