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!
Odpowiedzi:
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 ...
źródło
tshark zgłasza rozmiar ramki ethernetowej: 6142 - 14 (nagłówek ethernetowy) = 6128 bajtów IP.
scamper robi traceroute z małymi pakietami przed sondowaniem dużych pakietów w celu wykrycia MTU (dlatego widzisz małe pakiety, a po nich duże). przydaje się to do rozróżnienia wszystkich odrzucanych / nieodpowiadających pakietów od tylko tych dużych.
https://www.usenix.org/conference/imc-05/inferring-and-debugging-path-mtu-discovery-failures
źródło