Genellikle, yol ana iletim birimi keşfi (PMTUD), bir ana bilgisayar çok büyük olduğu için bir paketin düştüğünü düşündüğünde gerçekleşir.
Bu, paketin bırakıldığını açıkça gösteren ICMP parçalanması (tip 3, kod 4) yanıtı şeklinde olabilir. Tipik uygulamada, tüm IPv4 paketleri "parçalanma" (DF) bayrağı ayarlanmış olarak ayarlanır, bu nedenle MTU'yu aşan herhangi bir paket böyle bir yanıtı ortaya çıkarır. IPv6, parçalanmayı desteklemez.
Bazı yönlendiriciler veya ana bilgisayar güvenlik duvarları, saf bir yönetici ICMP'nin bir güvenlik riski olduğuna inandığı için tüm ICMP'leri sık sık düşürür . Veya, bazı bağlantı toplama şemaları ICMP dağıtımını bozabilir . MTU'yu keşfetmek için ICMP'ye dayanmayan alternatif bir mekanizma aşıldı RFC4821'de önerilmektedir .
tracepathMTU'yu araştırmak için en sevdiğim Linux aracı. LAN'da 9001 MTU'lu bir ana bilgisayardan 10.33.32.157'ye ulaşmak için bir IPsec VPN'den geçmesi gereken bir örnek:
$ 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]
ICMP hataları şunlarla gözlemlenebilir 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 keşifleri önbelleğe alınır. Linux'ta bu gözlemlenebilir ve temizlenebilir ip( Linux 3.6'dan bu yana değişikliklere dikkat edin ):
$ 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
TCP için, bağlantı kurulumunun bir parçası olarak MTU'nun aşılması önlenebilir. Her bir uç tarafından gönderilen SYN'ye maksimum segment boyutu (MSS) dahildir. TCP üstbilgisi ( seçenekler hariç 20 bayt ) ve IP üstbilgisi (20 bayt) ortalama MSS ve MTU, 40 baytlık bir farkla ilişkilidir.
Aşağıda, büyük bir dosyayı aktarırken bu iki ana bilgisayar arasında bir bağlantı kurulumu örneği verilmiştir 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
İlk pakette, yerel ana bilgisayar 8961 MSS önerir. Bu, yapılandırılmış 9001 MTU, daha az 40 bayttır. Döndürülen SYN / ACK, 1379'luk bir MTU'yu ima eden 1379'luk bir MSS'ye sahiptir. Bu ağda uzak ana bilgisayarın da 8961 gönderdiğini biliyorum, ancak değer bir yönlendirici tarafından değiştirildi, çünkü yol bir internet yolu içerdiğini biliyor ( MTU 1500) bir IPsec tünelinden bir ek yük. Bu yönlendirici ayrıca gönderilen 8961 MSS'yi diğer ana bilgisayarda 1419 olarak görünecek şekilde değiştirdi. Buna MSS kelepçesi denir .
Yani bir anlamda PMTUD her zaman oluyor. Pratikte, MSS sıkıştırması mevcutsa ve TCP üzerinden tüm trafik meydana geliyorsa veya yönlendiricilerin hiçbirinin uç noktalarda yapılandırılandan daha küçük bir MTU'su yoksa, asla gerçekleşmeyebilir. MSS kelepçesi olmasa bile, önbellek sona erdiğinde nadiren gerçekleşebilir.