Почему пакеты iperf, scamper и path MTU обнаружения не согласуются с MTU пути?

Давайте сделаем некоторое обнаружение MTU пути между двумя хостами Debian, разделенными маршрутизатором Debian, который запускает правила iptables, генерируемые Shorewall. Каждый из двух хостов использует единую линию Ethernet, в то время как маршрутизатор использует маркированные VLAN по двум агрегированным каналам Ethernet.

Используя scamper :

[email protected]:/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]

Хорошо: 6128 байт - ожидаемый результат (дешевые адаптеры Ethernet Realtek не могут обрабатывать большие рамки достойного размера).

Теперь пусть iperf выполнит пробный тест и расскажет нам о MTU, кстати:

[email protected]:/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 байт? Почему?

И теперь для чего-то совершенно другого, давайте посмотрим, что на самом деле трафик этого сеанса:

[email protected]:/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 байтов MSS, что означает 6128 MTU ... Хорошо. Но почему же iperf объявляет MTU с 6116 байтами?

В этот момент тщательность требует более пристального изучения того, что происходит во время сеанса трассировки scamper:

[email protected]:/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)

Все эти пакеты имеют длину udp.length 24, за исключением двух последних, у которых длина udp.length 6108 ... Но тогда как scamper сообщает нам, что путь MTU равен 6128?

6108, 6116, 6128 ... Так много MTU на выбор!

11 голосов | спросил Jean-Marc Liotier 16 Mayam13 2013, 06:17:00

2 ответа


3

Очень интересно.

MSS (максимальный размер сегмента) = MTU - заголовок IP = 6076.

6076 + 40 = 6116.

Может ли Debian использовать поля IP-параметров в заголовке IP? Это могут быть дополнительные 12 байтов ...

ответил Peter Tavenier 16 Mayam13 2013, 09:41:58
2

tshark сообщает размер кадра ethernet: 6142 - 14 (заголовок ethernet) = 6128 IP-байтов.

scamper выполняет трассировку с небольшими пакетами перед зондированием большими пакетами для обнаружения MTU (поэтому вы видите небольшие пакеты, за которыми следует большой). это полезно, чтобы различать все отбрасываемые /не отвечающие пакеты и просто большие.

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

ответил Matthew Luckie 29 Maypm13 2013, 19:30:55

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132