* Freitag, 09. November 2001 um 13:02 (+0100) schrieb Matthias Kleine:
ich möchte nochmals die Diskussion aufwerfen, woran es liegt, daß bei "falscher" Konfiguration des pppd die mru-Verhandlung scheitert in dem Sinne, daß danach gewisse Server nicht mehr erreichbar sind.
"Scheitert" ist nicht der richtige Begriff. Die Verhandlung ist sehr wohl erfolgreich, nur sind die Ergebnisse für PPPoE und PMTUD untauglich. Doch dazu später mehr...
[ ... ] daher möchte ich das folgende Protokoll nochmal zur Diskussion stellen:
---------------------------------------------------------------- Nov 8 16:43:23 server pppd[11972]: sent [LCP ConfReq id=0x1
]
pppd: "Ich möchte Pakete _empfangen_, die kleiner oder gleich ( -le ) 1490 Bytes sind."
Nov 8 16:43:24 server pppd[11972]: rcvd [LCP ConfReq id=0x47
<auth pap> ]
AC: "Ich möchte Pakete _empfangen_, die -le 1492 Bytes sind."
Nov 8 16:43:24 server pppd[11972]: sent [LCP ConfAck id=0x47
<auth pap> ]
Der pppd antwortet dem AC: "OK, du _bekommst_ von mir Pakete -le 1492 Bytes, aber..."
Nov 8 16:43:25 server pppd[11972]: sent [LCP ConfReq id=0x1
]
pppd: "... ich möchte Pakete _empfangen_, die -le 1490 Bytes sind."
Nov 8 16:43:26 server pppd[11972]: rcvd [LCP ConfAck id=0x1
]
Worauf der AC antwortet: "OK, du _bekommst_ von mir Pakete, die -le 1490 Bytes sind."
---------------------------------------------------------------
So, die MRU-Verhandlungen sind erfolgreich abgeschlossen. Keiner der
beiden hat (bisher) einen Fehler gemacht, d.h. gegen RFC 1661
verstossen.
Aber wir haben jetzt eine asymetrische Verbindung (Ich versuche mich
jetzt mal in ASCII-Art.):
+------+ MTU max. Paket-Größe 1492 MRU +-------+
| | >--------------->-----------------> | |
| pppd | | AC |
| | <---------------<-----------------< | |
+------+ MRU max. Paket-Größe 1490 MTU +-------+
Die MTU des pppd ist die MRU des AC und die MTU des AC ist die MRU des
pppd. (Alles klar soweit ;-) )
Die beiden Partner verhandeln immer nur _ihre_ MRU und die können
durchaus unterschiedlich sein. Das ist "normalerweise" auch kein
Problem..., wenn es nicht die PPPoE-PMTUD-Problematik gäbe:
"Unser Rechner" sendet eine Anforderung an einen PMTUD-Server im
Internet mit einer MTU von 1492. Der Server antwortet darauf mit
1492-Bytes-großen Paketen und gesetztem DF-Bit. Diese Pakete kommen
bis zum AC (zurück), der "feststellt", dass er sie in dieser Größe
nicht ohne Fragmentierung an "unseren Rechner" senden kann (weil
"unser Rechner" ja nur 1490-Bytes-große Pakete empfangen will/kann),
das DF-Bit aber gesetzt ist. Er verwirft also das Paket und schickt
dem Server eine ICMP-Nachricht "Fragmentation needed, but DF-Bit
set". Tja, und was mit dieser Nachricht passiert, das ist IMHO nicht
ganz klar. Auf jeden Fall erzeugt der Server keine kleineren Pakete.
So richtig "falsch" macht der Siemens-AC nichts (zumindest nicht an
dieser Stelle, die Pausen, das TermAck und die doppelte Aushandlung
der Remote-IP halte ich schon für buggy...), nur für PPPoE und die
damit verbundene PMTUD-Problematik ist er halt nicht fehlertolerant.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke