[ Main | Local ]

Die RFCs zum Thema

Die wichtigen Begriffe

• MTU - Maximum Transmission Unit
  Die MTU wird von der Netzwerk-Hardware bzw. vom Netzwerk-Protokoll vorgegeben. Es ist die mögliche Anzahl an Daten in Bytes, die in einer Übertragung gesendet werden können. Je nach Terminologie sind das dann Frames, Cells, Pakets, Datagramms ...

• MSS - Maximum Segment Size
  Das TCP ist ein Protokoll, das mit kontinuierlichen Datenströmen umgeht. Der Datenstrom wird von TCP in Teile zerlegt, sogenannte Segmente. Diese werden mit einem Header zur Flußkontrolle versehen und dann an die IP-Ebene weitergegeben. IP seinerseits gibt das Paket weiter an das Netzwerkinterface. Auf dem Kabel gibt es nun eine maximal zulässige Größe für eine Dateneinheit, die MTU. Da es sinnlos wäre, größere Einheiten zu senden, beziehen sich die oberen Schichten auf diese MTU und ermitteln die reine Nutzlast, also die MTU minus aller Header, die noch dazu kommen. Das ist die Maximum Segment Size.

• Path MTU - Die MTU auf dem Pfad
  Das ist die MTU entlang des Pfades einer Verbindung im Netz. Die kann sich mit der Zeit, speziell in einem Internet, ändern. Da das Routing in Hin- und Rückrichtung nicht gleich sein muß, kann sich auch die Path MTU pro Richtung unterscheiden.

• Fragmentierung - Zerschneiden von Paketen
  Ein Paket hat eine bestimmte Größe und kommt nun an ein Link, das diese Größe nicht zur Verfügung stellen kann. Auf diesem Gateway/Router wird das Paket dann in einzelne, kleinere Teile zerlegt, die es dem Empfänger ermöglichen, das originale Paket wieder zusammenzusetzen. Es ist der Empfänger, der das Paket wieder zusammensetzt - ein einmal fragmentiertes Paket setzt den Rest des Weges in Teilen zurück.
  Fragmentierung ist nicht erwünscht, weil sie einmal Last auf Router und Empfänger bringt, die Performance drückt und bei Verlusten einzelner Fragmente ein erneutes Senden des ganzen Paketes erzwingt. Zu guter Letzt gibt es noch Firewalls, die damit nicht richtig umgehen können, und Pakete ohne kompletten TCP-Header fallen lassen.

• Das DF (Don't Fragment) Bit
  Dieses Bit wird gesetzt, wenn der Sender nicht will, das ein Paket zerstückelt wird. Findet ein Gateway/Router es unmöglich, das Paket unter diesen Umständen wieterzuleiten, so läßt er es fallen und sendet einen ICMP Error (fragmentation needed).

• ICMP Fragmentation Needed Error
  Das ist ein ICMP Error des Typs 3, also destination unreachable, in Kombination mit dem Code 4, also fragmentation needed but DF bit set. Diesen Error gibt eine Maschine zurück, die ein zu großes Paket fragmentieren muß, es aber verboten bekommt. Das Paket wird verworfen und die ICMP-Message gesendet. Ganz schlaue Implementationen geben auch die MTU des lokalen Links mit zurück, sodaß der Sender sofort weiß, was Phase ist. Ist das Bit nicht gesetzt, dann wird das Paket zerstückelt und weitergereicht.

Path MTU Discovery (PMTU-D)

TCP ist in der Lage, die MSS, die auf dieser Verbindung benutzt werden soll, auszuhandeln. Dabei wird die vom lokalen System unterstützte MSS als Option im TCP-Header mitgegeben. Das findet beim Aufbau der Verbindung statt, also während des TCP Handshakes - beide Seiten wählen dann den kleineren Wert. In einem Internet kann eine Maschine aber nicht wissen, wie groß die MTU auf dem Weg sein wird - und einmal ausgehandelt ist es auch nicht mehr möglich, die Path-MTU zu ändern (obwohl sie sich leicht ändern kann). Daher gehen alle Implementationen hin und bieten bei der Verhandlung die Mindest-MTU an, die jedes Device auf dem Netz können muß. Das sind 576 Byte, was einer MSS von 512 Byte entspricht. Da die "Verhandlung" immer auf den kleinsten gemeinsamen Wert hinausläuft, ist das für große Datentransfers völlig unzureichend.

PMTU-Discovery soll dieser Schwäche des TCP abhelfen. Die Idee ist, das für das lokale Netz größtmögliche Paket zu schicken und das DF-Bit zu setzen. Dieses Paket wird dann am ersten Router, der es zerstückeln müßte, fallengelassen, und der ICMP Error zeigt an, das es mit dieser Größe nicht geht. Dann wird das Paket verkleinert und es wird nochmal versucht - solange, bis die optimale Größe gefunden ist. Diese wird dann mit der Routing-Information gespeichert.

Neuere Implementationen geben den richtigen Wert im ICMP Paket mit an, ansonsten muß der Sender eine Liste sinnvoller MTUs abarbeiten. Unter AIX ist die Implementation etwas eigenwillig. Hier werden nicht die ersten Datenpakete geschickt, sondern es werden ICMP-Pakete mit der entsprechenden Größe gesendet - das macht einige Firewall-Administratoren wahnsinnig, da es für diese wie ein Ping aussieht und sie sich angegriffen fühlen (spricht für die Qualität der Ausbildung).

Das führt direkt zum größten Problem mit PMTU Discovery - gedankenloses Filtern von ICMP-Messages. Alle ICMP-Messages gehören zum normalen Funktionieren und Leben auf dem Internet, und man muß sich sehr genau überlegen, was man wann und an welcher Stelle filtert.

Werden die für PMTU Discovery nötigen ICMP-Messages gefiltert, dann kommen alle kleinen Pakete problemlos durch, nur richtige Datenübertragungen bleiben ohne Fehlermeldung stehen. Viel machen kann man nicht - man muß PMTU Discovery ausschalten und sich mit der Standard MSS begnügen. Man kann versuchen, den Admin der Firewall Maschine zu finden und im ein paar RFCs nennen, die er vielleicht lesen sollte.

Die Path MTU Discovery kann man hier in Action sehen.

Alles anders mit AIX 5.3

Hier ist ein kleines Wunder passiert: Die AIX Entwickler sind davon abgekommen, die Path MTU mit speziell geschnittenen ICMP-Paketen zu ermitteln. Es werden jetzt die ersten Pakete des Datenstroms mit dem Dont't Fragment Bit verschickt und so die optimale MTU des Pfades ermittelt.

Da sich Multipath Routing und PMTU Discovery beissen (bisher wurde die entdeckten Parameter einer Route in einer neuen, geklonten Hostroute hinterlegt; das hebelt Mechanismen aus, die auf gleichwertige Routen verteilen sollen) wurde eine neue Kernel-Tabelle implementiert, in der die Parameter der einzelnen Pfade gespeichert werden. Es gibt also auch in der Ausgabe es netstat-Kommandos keine geklonten Routen (Flag w) mehr. Diese Information kann jetzt mit dem pmtu Kommando direkt aus der Kernel Tabelle ausgelesen werden:

0:root@testy:/# pmtu display

   dst           gw            If    pmtu     refcnt   redisc_t    exp

 -------------------------------------------------------------------------

172.16.145.5  172.16.144.1    en0    1500        1         21       0

10.3.4.3      172.16.144.1    en0    1500        0         24       2

[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]