Dlaczego przechwytywanie pakietów wykrywania MTI ścieżki iperf, scamper i ścieżki nie zgadza się z MTU ścieżki?


11

Zróbmy ścieżkę wykrywania MTU między dwoma hostami Debiana oddzielonymi routerem Debian, który uruchamia reguły iptables generowane przez Shorewall. Każdy z dwóch hostów używa pojedynczego łącza Ethernet, podczas gdy router wykorzystuje oznaczone sieci VLAN w dwóch zagregowanych łączach Ethernet.

Za pomocą scampera :

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]

Dobrze: oczekiwany wynik to 6128 bajtów (tanie adaptery Realtek Ethernet nie są w stanie obsłużyć dużych ramek o przyzwoitym rozmiarze).

Teraz pozwól iperf wykonać test przepustowości i powiedz nam o MTU:

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 bajtów? Czemu ?

A teraz coś zupełnie innego, zobaczmy, co faktycznie zawiera ruch tej sesji:

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 bajtów MSS, co oznacza 6128 MTU ... Dobrze. Ale dlaczego więc iperf ogłasza MTU o rozmiarze 6116 bajtów?

W tym momencie dokładność wymaga dokładniejszego spojrzenia na to, co dzieje się podczas sesji śledzenia scampera:

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)

Wszystkie te pakiety mają udp. Długość 24, z wyjątkiem dwóch ostatnich, które mają udp. Długość 6108 ... Ale w jaki sposób scamper mówi nam, że MTU ścieżki to 6128?

6108, 6116, 6128 ... Tyle MTU do wyboru!


Czy jakaś odpowiedź ci pomogła? jeśli tak, powinieneś zaakceptować odpowiedź, aby pytanie nie wyskakiwało wiecznie, szukając odpowiedzi. Alternatywnie możesz podać i zaakceptować własną odpowiedź.
Ron Maupin

Odpowiedzi:


4

Bardzo interesujące.

MSS (maksymalny rozmiar segmentu) = MTU - nagłówek IP = 6076.

6076 + 40 = 6116.

Czy to możliwe, że Debian używa pól opcji IP w nagłówku IP? To może być dodatkowe 12 bajtów ...


Czy to możliwe, że uzgadnianie TCP ustanawia 6128 bajtów MTU, a następnie iperf dowiaduje się, że nie przesłał więcej niż 6116 bajtów naraz - co byłoby rodzajem empirycznej MTU niezwiązanej z „oficjalną”?
Jean-Marc Liotier

Niezależnie od opcji IP, czy nie ma wypełnienia zapewniającego, że długość (opcje IP + wypełnienie) = 32 bity?
Jean-Marc Liotier

12 bajtów… Czy nie chodziło Ci o „Opcje TCP” zamiast „Opcje IP”?
Jean-Marc Liotier

Próbkowałem opcje TCP sesji iperf: najwyraźniej zawsze 12 bajtów (tylko znaczniki czasu)
Jean-Marc Liotier

2
W github.com/jasonrm/iperf/blob/… komentarz mówi „// śledź rozmiary odczytów -> daje pewne informacje o rozmiarze MTU”, aw github.com/jasonrm/iperf/blob/… inny mówi „Zgłoś MSS i MTU, biorąc pod uwagę MSS (lub ich przypuszczenie) ”- dziwne, biorąc pod uwagę, że iperf ma wspierać faktyczne wykrywanie ścieżki MTU.
Jean-Marc Liotier

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.