orm@doc-tcpip.org

Erstellt: September 1999 - Letzte Modifikation: Juni 2006

[ Main | Local ]


Alles zu Path MTU Discovery


Die RFCs zum Thema

RFC 1191 ** Path MTU Discovery
RFC 2923 ** TCP Problems with Path MTU Discovery

Die wichtigen Begriffe

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

Es ist mit diesem Kommando auch möglich, Einträge zu löschen (pmtu delete mit Angabe des Zieles oder des Gateways).


[ Main | Local ]

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

Copyright 2001-2014 by Orm Hager - Es gilt die GPL
Feedback bitte an: Orm Hager (orm@doc-tcpip.org )