In der Regel erfolgt die Ermittlung der maximalen Pfadübertragungseinheit (PMTUD) immer dann, wenn ein Host denkt, dass ein Paket verworfen wurde, weil es zu groß ist.
Dies kann eine Reaktion auf die ICMP-Fragmentierung sein, die erforderlich ist (Typ 3, Code 4) und die explizit angibt, dass das Paket verworfen wurde. In der typischen Praxis werden alle IPv4-Pakete mit dem gesetzten DF-Flag (Don't Fragment) gesetzt, sodass jedes Paket, das die MTU überschreitet, eine solche Antwort hervorruft. IPv6 unterstützt überhaupt keine Fragmentierung.
Einige Router oder Host-Firewalls lassen ICMP häufig fallen, da ein naiver Administrator ICMP als Sicherheitsrisiko ansieht . Einige Linkaggregationsschemata können die ICMP-Übermittlung beeinträchtigen . In RFC4821 wird ein alternativer Mechanismus zum Erkennen der MTU vorgeschlagen, der nicht auf ICMP basiert .
tracepathist mein Lieblings-Linux-Tool zum Testen von MTU. Hier ist ein Beispiel von einem Host mit einer 9001-MTU im LAN, der jedoch ein IPsec-VPN durchlaufen muss, um 10.33.32.157 zu erreichen:
$ tracepath -n 10.33.32.157
1?: [LOCALHOST] pmtu 9001
1: 10.1.22.1 0.122ms pmtu 1500
1: 169.254.3.1 1.343ms pmtu 1422
1: 10.255.254.61 23.790ms
2: no reply
^C [this host won't return an ICMP port unreachable, so tracepath won't terminate]
Die ICMP-Fehler können beobachtet werden bei tcpdump:
$ sudo tcpdump -p -ni eth0 'icmp and icmp[0] == 3 and icmp[1] == 4'
14:46:57.313690 IP 10.1.22.1 > 10.1.22.194: ICMP 10.33.32.157 unreachable - need to frag (mtu 1500), length 36
14:46:57.315080 IP 169.254.3.1 > 10.1.22.194: ICMP 10.33.32.157 unreachable - need to frag (mtu 1422), length 556
MTU-Entdeckungen werden zwischengespeichert. In Linux kann dies beobachtet und mit gelöscht werden ip(Vorsicht vor Änderungen seit Linux 3.6 ):
$ ip route get 10.33.32.157
10.33.32.157 via 10.1.22.1 dev eth0 src 10.1.22.194
cache expires 591sec mtu 1422
$ sudo ip route flush cache
$ ip route get 10.33.32.157
10.33.32.157 via 10.1.22.1 dev eth0 src 10.1.22.194
cache
Bei TCP kann das Überschreiten der MTU im Rahmen des Verbindungsaufbaus vermieden werden. In der von jedem Ende gesendeten SYN ist eine maximale Segmentgröße (MSS) enthalten. Der TCP-Header (20 Byte ohne Optionen ) und der IP-Header (20 Byte) bedeuten, dass MSS und MTU um 40 Byte voneinander abweichen.
Hier ist ein Beispiel für einen Verbindungsaufbau zwischen diesen beiden Hosts beim Übertragen einer großen Datei mit scp:
$ sudo tcpdump -p -ni eth0 'host 10.33.32.157 and tcp[13]&2 == 2'
IP 10.1.22.194.45853 > 10.33.32.157.22: Flags [S], seq 634040018, win 26883, options [mss 8961,sackOK,TS val 10952240 ecr 0,nop,wscale 7], length 0
IP 10.33.32.157.22 > 10.1.22.194.45853: Flags [S.], seq 1371736848, ack 634040019, win 26847, options [mss 1379,sackOK,TS val 10824267 ecr 10952240,nop,wscale 7], length 0
Im ersten Paket schlägt der lokale Host einen MSS von 8961 vor. Dies ist die konfigurierte 9001-MTU, abzüglich 40 Bytes. Das zurückgegebene SYN / ACK hat eine MSS von 1379, was eine MTU von 1419 bedeutet. Ich weiß, dass in diesem Netzwerk der Remote-Host ebenfalls 8961 gesendet hat, aber der Wert wurde von einem Router geändert, da er weiß, dass der Pfad einen Internetpfad enthält ( MTU 1500) ein Overhead von einem IPsec-Tunnel. Dieser Router hat auch unser gesendetes MSS von 8961 so geändert, dass es auf dem anderen Host als 1419 angezeigt wird. Dies wird als MSS-Klemmung bezeichnet .
In gewissem Sinne passiert PMTUD die ganze Zeit. In der Praxis kann es tatsächlich niemals vorkommen, wenn MSS-Clamping vorhanden ist und der gesamte Datenverkehr über TCP erfolgt oder keiner der Router eine MTU aufweist, die kleiner ist als die auf den Endpunkten konfigurierten Werte. Auch ohne MSS-Clamping kann es nur selten vorkommen, dass der Cache abläuft.