Neden iperf, scamper ve yol MTU bulma paketi yakalamaları yolun MTU'su üzerinde aynı fikirde değil?

Shorewall tarafından oluşturulan iptables kurallarını çalıştıran bir Debian yönlendiricisi ile ayrılmış iki Debian ana bilgisayarı arasında bir yol MTU keşfi yapalım. İki ana bilgisayarın her biri tek bir Ethernet bağlantısı kullanırken, yönlendirici iki toplu Ethernet bağlantısı üzerinde etiketli VLAN kullanır.

Scamper kullanarak :

root@kitandara:/home/jm# scamper -I "trace -M 10.64.0.2"
traceroute from 10.1.0.5 to 10.64.0.2
 1  10.1.0.1  0.180 ms [mtu: 6128]
 2  10.64.0.2  0.243 ms [mtu: 6128]

İyi: 6128 bayt beklenen sonuçtur (ucuz Realtek Ethernet adaptörleri iyi boyutta jumbo çerçeveleri işleyemez).

Şimdi, iperf'in bir işlem testi yapmasına ve bu arada bize MTU hakkında bilgi vermesine izin verin :

root@kitandara:/home/jm# iperf -c 10.64.0.2 -N -m
------------------------------------------------------------
Client connecting to 10.64.0.2, TCP port 5001
TCP window size: 66.2 KByte (default)
------------------------------------------------------------
[  3] local 10.1.0.5 port 59828 connected with 10.64.0.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1011 MBytes   848 Mbits/sec
[  3] MSS size 6076 bytes (MTU 6116 bytes, unknown interface)

6116 bayt? Neden ?

Ve şimdi tamamen farklı bir şey için, bu oturumun trafiğinin gerçekte ne içerdiğini görelim:

root@kitandara:/home/jm# tshark -i eth0 -R "(ip.dst == 10.64.0.2) || (ip.src == 10.64.0.2)" | head
Capturing on eth0
  1.308557     10.1.0.5 -> 10.64.0.2    TCP 74 60310 > 5001 [SYN] Seq=0 Win=5340 Len=0 MSS=534 SACK_PERM=1 TSval=101928961 TSecr=0 WS=16
  1.308801    10.64.0.2 -> 10.1.0.5     TCP 74 5001 > 60310 [SYN, ACK] Seq=0 Ack=1 Win=18328 Len=0 MSS=6088 SACK_PERM=1 TSval=3764064056 TSecr=101928961 WS=64

6088 bayt MSS, yani 6128 MTU ... İyi. Peki iperf neden 6116 bayt MTU'yu duyurdu?

Bu noktada, titizlik, scamper izleme oturumu sırasında neler olduğuna daha yakından bakılmasını gerektirir:

root@kitandara:/home/jm# tshark -i eth0 -R "(ip.dst == 10.64.0.2) || (ip.src == 10.64.0.2)"
Capturing on eth0
  0.000000     10.1.0.5 -> 10.64.0.2    UDP 58 Source port: 43870  Destination port: 33435
  0.000175     10.1.0.1 -> 10.1.0.5     ICMP 86 Time-to-live exceeded (Time to live exceeded in transit)
  0.050358     10.1.0.5 -> 10.64.0.2    UDP 58 Source port: 43870  Destination port: 33436
  0.050592    10.64.0.2 -> 10.1.0.5     ICMP 86 Destination unreachable (Port unreachable)
  0.099790     10.1.0.5 -> 10.64.0.2    UDP 6142 Source port: 43870  Destination port: 33437
  0.100912    10.64.0.2 -> 10.1.0.5     ICMP 590 Destination unreachable (Port unreachable)

Tüm bu paketler, udp.length 6108 olan son ikisi hariç 24 udp uzunluğuna sahiptir ... Ama sonra scamper bize MTU yolunun 6128 olduğunu nasıl söyler?

6108, 6116, 6128 ... Aralarından seçim yapabileceğiniz çok fazla MTU!

routing ipv4

— Jean-Marc Liotier
kaynak

Herhangi bir cevap size yardımcı oldu mu? öyleyse, cevabı kabul etmelisiniz, böylece soru sonsuza kadar ortaya çıkmayacak, bir cevap arıyor. Alternatif olarak, kendi cevabınızı verebilir ve kabul edebilirsiniz.

— Ron Maupin

Yanıtlar:

Çok ilginç.

MSS (maksimum segment boyutu) = MTU - IP başlığı = 6076.

6076 + 40 = 6116.

Debian IP başlığındaki IP seçenekleri alanlarını kullanıyor olabilir mi? Fazladan 12 bayt olabilir ...

— Peter Tavenier
kaynak

TCP el sıkışmasının bir 6128 bayt MTU oluşturması ve sonra iperf, bir seferde 6116 bayttan fazlasını iletemediğini fark edebilir mi - ki bu da "resmi" olanla ilgili olmayan bir tür ampirik MTU olabilir mi?

— Jean-Marc Liotier

IP seçenekleri ne olursa olsun, bu uzunluğu sağlayan bir dolgu yoktur (IP seçenekleri + dolgu) = 32 bit?

— Jean-Marc Liotier

12 bytes… Şunu mu demek istediniz: "IP seçenekleri" yerine "TCP seçenekleri"?

— Jean-Marc Liotier

İperf oturumunun TCP seçeneklerini örnekledim: görünüşe göre her zaman 12 bayt (sadece zaman damgaları)

— Jean-Marc Liotier

Github.com/jasonrm/iperf/blob/… 'da bir yorum "// okuma boyutlarını takip et -> MTU boyutunun bir göstergesini veriyor" ve github.com/jasonrm/iperf/blob/… MSS ve MTU, MSS (veya bir tahmin) verildiğinde "- iperf'in gerçek Path MTU Discovery'yi desteklemesi gerektiği göz önüne alındığında gariptir.

— Jean-Marc Liotier

tshark ethernet çerçeve boyutunu bildiriyor: 6142 - 14 (ethernet başlığı) = 6128 IP baytı.

scamper, MTU keşfi için büyük paketlerle araştırma yapmadan önce küçük paketlerle bir traceroute yapar (bu yüzden küçük paketleri ve ardından büyük paketleri görürsünüz). bu, atılan / yanıt vermeyen tüm paketleri ve yalnızca büyük olanları ayırt etmek için yararlıdır.

https://www.usenix.org/conference/imc-05/inferring-and-debugging-path-mtu-discovery-failures

— Matthew Luckie
kaynak