View Full Version : Don't Fragment Flag (DF) im IP-Header
hallo
habe folgendes problem:
letztens haben wir unser netzwerk etwas gesnifft
und der sniffer meldet über AS400:
Don't Fragment Flag (DF) im IP-Header
weiss jemand vielleicht wieso AS400 fragmentieren verbietet
und wie man dies beheben kann ?
unser release: V4R4M0
gruss
cc
kuempi von stein
12-03-06, 15:07
hallo
habe folgendes problem:
letztens haben wir unser netzwerk etwas gesnifft
und der sniffer meldet über AS400:
Don't Fragment Flag (DF) im IP-Header
weiss jemand vielleicht wieso AS400 fragmentieren verbietet
und wie man dies beheben kann ?
unser release: V4R4M0
gruss
cc
uhh..
DAS nenne ich mal ne interessante Frage.
also...
Das (DF) ...gibt es ja angeblich seit Version 4 Release 3 als TCP/IP enhancement.
Es firmiert unter Path MTU discovery und ist angeblich in RFC1192 (ftp://ftp.isi.edu/in-notes/rfc1191.txt) beschrieben.
Und wenn ich ehrlich bin...
ich hab keine Ahung wie man das abstellen könnte...
Da muss mal ein AS/400 TCP/IP Cracker ran (Einstellung Parameter?)...
k.
holgerscherer
12-03-06, 15:36
Da muss mal ein AS/400 TCP/IP Cracker ran (Einstellung Parameter?)...
k.
Drücken wir das mal einfach aus: Pakete im Internet haben eine gewisse Grösse, sagen wir 1400b. Manche Router im Internet können nur beispielsweise 1300b pro Paket übertragen. Nun müsste ein Paket von A nach B, das die Grösse 1400b hat, an diesem Router aufgeteilt werden in 2 Pakete von 1300b und 100b. Das verschwendet etwas Ressourcen im Netz, da ja zusätzlich Paket-Header gesendet werden müssen.
Das Prinzib der MTU-Pfaderkennung basiert auf der Überlegung, dass ein System das DontFragment-Bit einschaltet, und ein Router, der ein Paket der gesendeten Grösse nicht weiterleiten kann, das Paket (wegen dem DF-Bit) verwirft und eine ICMP-Meldung an den Sende-Host zurückgibt, worauf dieser die Paketgrösse reduziert.
Leider... (wie das mit RFCs so ist) wurde noch nicht richtig spezifiziert, bzw. können nicht alle Router in dieser negativen ICMP-Meldung auch mitgeben, welche Paketgrösse sie selbst unterstützen, so dass der Sendehost sofort weiss, wie gross die Pakete maximal sein dürfen. Daher reduziert der Sendehost bei einer einkommenden negativen ICMP-Meldung die Paketgrösse selbst um ein paar Bytes.
Das wird dann solange gemacht, bis keine negative ICMP-Meldung mehr kommt, und der Sendehost hat nun die passende Paketgrösse ermittelt, mit der die Pakete von A nach B ohne Fragmentierung weitergeleitet werden können.
Diesen Vorgang nennt man dann MTU(maximum transfer unit)-Pfaderkennung, weil - im Falle von mehreren Netzanbindungen des Sendehosts - dieser auch einen anderen Weg der Pakete wählen kann. Beispielsweise, wenn ein System mit 4 Netzanbindungen im Internet hängt, eine davon kann nur kleine Pakete bis 1000b übermitteln.
Schaltet man das DF-Bit aus mit
CHGTCPA IPPATHMTU(*NO), wird das DF-Bit nicht mehr gesetzt, und dem Sendehost ists wurstegal, ob die Pakete im Netz fragmentiert werden oder nicht.
Ich hoffe, das war grob verständlich.
Das ganze Thema ist nicht ohne und wird stellenweise religiös behandelt. Die einen beschweren sich über das DF-Bit oder über zurückkommende negative ICMP-Pakete, und empfehlen, gleich eine recht niedrige MTU einzustellen; andere empfehlen, möglichst nur Router und Hops mit möglichst grosser MTU-fähigkeit einzusetzen. Aber wer hat schon Einfluss auf die Wege des Herrn äh der Pakete?
In der Regel (...) wenn auf dem Weg von A nach B nur Kabelgebundene Ethernet-Geräte involviert sind, ist man mit einer MTU von 1496 über CHGLIND LIND(xxx) MAXFRAME(1496) gut bedient, und schaltet die PMTU aus.
Ob das wirklich viel bringt oder nicht, kann man nur mit Detailkenntnissen und einem grösseren Snifferprotokoll rausfinden.
An den Ursprungsposter: die alleinige Existenz des DF-Bits ist nicht schlecht, das Problem sollte man nur angehen, wenn zu viele negative ICMP-Pakete zurückkommen. Gruss an den Admin mit dem Sniffer :-)
-h
holgerscherer
12-03-06, 16:15
...
Jaja, ein Selbst-Zitat.
Was ich vergessen habe: nach dem der sendende Host mittels PMTU erkannt hat, welche MTU zwischen ihm und dem Ziel maximal möglich ist, wird das DF-Bit aber *nicht* abgeschaltet, weil sich ja irgendwann das Routing und somit die dazwischen liegenden Stationen ändern könnten und die Situation wieder anders ist. Dafür gibt es dann noch den Parameter des Intervals bei CHGTCPA IPPATHMTU(...); denn nach der dort angegebenen Zeit geht die AS/400 davon aus, man könnte es ja noch mal probieren und setzt die MTU wieder ein wenig hoch. Wenn man diese Werte nun extrem setzt, z.B. auf *YES 5 (sprich, PMTU an, alle 5 Minuten MTU steigern), spricht man auch von "Kampfparametern" ;-)
-h
vielen herzlich dank !
ich werde vorläufig PMTU auf NO setzen mit:
CHGTCPA IPPATHMTU(*NO)
und schaue wie sich das ganze verhalten wird.
holgerscherer
13-03-06, 01:39
vielen herzlich dank !
ich werde vorläufig PMTU auf NO setzen mit:
CHGTCPA IPPATHMTU(*NO)
und schaue wie sich das ganze verhalten wird.
Okay. Im lokalen Netz dürftest Du keine spürbare Veränderung feststellen. (Ausser, Du hast irgendwo ein paar schräge HUBs dazwischen :-)
Ansonsten vielleicht, wenn man sich per Modem via VPN einwählt, aber auch das ist minimal.
Übrigens: bevor ich es Vergesse. Der Einsatz eines Sniffers im Netzwerk ist mit Vorsicht zu geniessen. Nicht nur technisch, sondern auch rechtlich. Falls Ihr einen Betriebsrat habt... Ich wollte ja nur darauf hingewiesen haben.
-h
Okay. Im lokalen Netz dürftest Du keine spürbare Veränderung feststellen. (Ausser, Du hast irgendwo ein paar schräge HUBs dazwischen :-)
Ansonsten vielleicht, wenn man sich per Modem via VPN einwählt, aber auch das ist minimal.
Übrigens: bevor ich es Vergesse. Der Einsatz eines Sniffers im Netzwerk ist mit Vorsicht zu geniessen. Nicht nur technisch, sondern auch rechtlich. Falls Ihr einen Betriebsrat habt... Ich wollte ja nur darauf hingewiesen haben.
-h
meinst du wegen personen schutz ?
und was meinst du genau mit Betriebsrat ?
übrigens wir haben viele vpn clients (cisco vpn tunnels)
andere filialen sind zu uns via vpn angeschlossen und griefen über das vpn auf AS400 via telnet sessions.
kann es probleme geben ?
holgerscherer
13-03-06, 08:59
meinst du wegen personen schutz ?
und was meinst du genau mit Betriebsrat ?
übrigens wir haben viele vpn clients (cisco vpn tunnels)
Datenschutz! Personenschutz ist das, was Ihr braucht, wenn Ihr sowas ohne vorhandenen Betriebsrat macht. Denn der ist (sofern vorhanden) auch bei Netzwerküberwachung mitbestimmungspflichtig.
Wie genau die Ciscos ihr VPN vertüdeln, habe ich grade nicht im Kopf. Also mal dort prüfen, was die für eine MTU über das VPN kriegen, und (falls hier Performanceprobleme auftreten) die MTU der LIND anpassen. Oder lieber doch das PMTU eingeschaltet lassen.
-h