hi glady, hi wordo,
immer ruhig mit den wilden Pferden.
@wordo - ja, es ist schon ganz schön krass was die Provider da so alles machen.
QSC kenn ich hier oben im Norden garnicht mal.
Wobei es nicht nur die Provider sind, sondern auf Firmen wie Siemens, welche
durch ihre Service Techniker teilweise abenteuliche WAN/VPN Verbindungen zaubern.
Zumindest steht irgendwo in der Mitte dann doch irgendwo wieder mal eine Firewall
welche in der Regel bis auch echo/echo reply alles filtert.
Das bedeutet allgemein, dass es manchmal vorkommt, das MTU Path Discovery teilweise
sowieso nicht von End-to-End durchgeht. (Server-Client)
@glady - wordo hat recht, am ATM0 Interface interessiert die MTU so gut wie garnicht.
Das interface welches PPPoE macht ist (der dialer), an diesem sind 1492 richtig.
1500 -8 für den PPPoE Offset.
Auch die operation tcp adjust mss ist richtig, gilt jedoch nur für "tcp", ergo bring der extended echo nur folgende Erkenntnis.
Der Router antwortet mit ICMP Source Quench, Fragmentation needed, welches der Host, mit dem Du den echo abgesetzt hast auch erhält. (gut soweit)
Die Antwort ab 1472byte bedeutet nur, dass der Router im allgemeinen für die gewünscht Verbindung hier, bei mehr als 1472byte großen Packeten anfangen will zu fragmentieren.
Im Umkehrschluss hieße das, dass wenn du einen Ping durch den Tunnel abgesetzt hast, er hier die den IPSec Offset mit 20byte veranschlagt, um am dialer das Packet mit max 1500byte weiterzuleiten.
Die -40 byte, welche Du bereits durch mss-adjust auf 1452 reduziert hast, reichen dafür also vollständig aus.
Dieses gilt jedoch eben ausschließlich für tcp-packete >1452 !
Für genau diese Packete muss der Router also genau wie für den extended Ping nun den ICMP SourceQuench an den Server senden. In diesem teilt er mit "fragmentation needed"
Nun kommt es auf den verwendeten RFC an, ob der Router dem Server auch klar machen kann wie groß das Packet maximal sein darf, um Fragmentation zu vermeiden.
Und zusätzlich muss diese Info auch beim Server ankommen und verwendet werden.
Hier behindert dann oft eine Firewall, da diese den ICMP nicht zum Server kommen lässt.
Sollte es in Deinem Fall nicht so sein, bleibt die Frage danach, ob der Server mit dem verwendeten RFC klar kommt.
Der RFC 791 z.B. ist hier etwas schlauer, dieser veranlasst, das der Router den Offset mit bekannt gibt, wonach sich der Server richten sollte, wenn er RFC 791 versteht oder auch erhält.
Der RFC 792 z.B. umgeht diesen Prozess mit dem Hintergrund:
Wenn der Server mit DF-Bit kommt (Path MTU Discovery) schickt der Router Fragmentation needed, dadurch sollte der Server die mss nach unten korregieren, und es erneut versuchen. Dieses Prinzip so lange, bis er den SourceQuench nicht mehr erhält.
Dann fixed er den Wert (nur für diese Session), und setzt das BF-Bit erneut.
Dieses tut er, um auch hinter den Router (also beim Provider oder in Deinem Remote LAN)
weiter via MTU Path Discovery arbeiten zu können.
So viel zum Dynamische Prozess.
Nun zu dem Probelm:
Was ist beim DF-Bit lsöchen der Unterschied zu diesem Verfahren:
Cisco IOS Security Configuration Guide, Release 12.4 - DF Bit Override Functionality8 with IPSec Tunnels* [Cisco IOS Software Releases 12.4 Mainline] - Cisco Systems
Da steht folgender Hinweis:
Performance Impact
Because each packet is reassembled at the process level, a significant performance impact occurs at a high data rate. Two major caveats are as follows:
•The reassemble queue can fill up and force fragments to be dropped.
•The traffic is slower because of the process switching.
Den Performance Impact hast Du wahrscheinlich so schon
Next post follow
Mr. Oiso
