Zazwyczaj wykrywanie maksymalnej ścieżki transmisji (PMTUD) ma miejsce zawsze, gdy host myśli, że pakiet został odrzucony z powodu zbyt dużego rozmiaru.
Może to być odpowiedź na wymaganą fragmentację ICMP (typ 3, kod 4), która wyraźnie wskazuje, że pakiet został odrzucony. W typowej praktyce wszystkie pakiety IPv4 są ustawione z ustawioną flagą „nie fragmentuj” (DF), więc każdy pakiet przekraczający MTU wywoła taką odpowiedź. IPv6 w ogóle nie obsługuje fragmentacji.
Niektóre routery lub zapory hosta często odrzucają cały ICMP, ponieważ naiwny administrator uważa ICMP za zagrożenie bezpieczeństwa . Lub niektóre schematy agregacji łączy mogą przerywać dostarczanie ICMP . W RFC4821 zaproponowano alternatywny mechanizm wykrywania MTU, który nie opiera się na ICMP .
tracepathto moje ulubione narzędzie do sondowania MTU w systemie Linux. Oto przykład z hosta z jednostką MTU 9001 w sieci LAN, ale który musi przejść przez sieć VPN IPsec, aby osiągnąć 10.33.32.157:
$ 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]
Błędy ICMP można zaobserwować za pomocą 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
Odkrycia MTU są buforowane. W Linuksie można to zaobserwować i usunąć ip(uwaga na zmiany od Linuksa 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
W przypadku protokołu TCP przekroczenie MTU można uniknąć w ramach konfiguracji połączenia. Do SYN wysyłanego przez każdy koniec zawarty jest maksymalny rozmiar segmentu (MSS). Nagłówek TCP (20 bajtów bez opcji ) i nagłówek IP (20 bajtów) oznaczają, że MSS i MTU są powiązane różnicą 40 bajtów.
Oto przykład konfiguracji połączenia między tymi dwoma hostami podczas przesyłania dużego pliku za pomocą 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
W pierwszym pakiecie host lokalny proponuje MSS 8961. Jest to skonfigurowana jednostka MTU 9001, mniej niż 40 bajtów. Zwrócony SYN / ACK ma MSS 1379, co sugeruje MTU 1419. Zdarza się, że w tej sieci zdalny host również wysłał 8961, ale wartość została zmodyfikowana przez router, ponieważ wie, że ścieżka zawiera ścieżkę internetową ( MTU 1500) narzut z tunelu IPsec. Router zmodyfikował również nasz wysłany MSS 8961, aby pojawiał się jako 1419 na drugim hoście. Nazywa się to zaciskaniem MSS .
W pewnym sensie PMTUD dzieje się cały czas. W praktyce może się to nigdy nie zdarzyć, jeśli blokowanie MSS jest na miejscu, a cały ruch odbywa się przez TCP lub jeśli żaden z routerów nie ma MTU mniejszej niż skonfigurowana w punktach końcowych. Nawet bez blokowania MSS może się to zdarzyć rzadko, gdy pamięć podręczna wygaśnie.