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

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

Используя scamper :

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]

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

Теперь позвольте iperf выполнить тест пропускной способности и рассказать нам о 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 байт? Зачем ?

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

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 байт MSS, что означает 6128 MTU ... Хорошо. Но тогда почему iperf объявляет MTU 6116 байт?

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

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)

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

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

routing ipv4

— Жан-Марк Лиотье
источник

Вам помог какой-нибудь ответ? Если это так, вы должны принять ответ, чтобы вопрос не появлялся вечно, ища ответ. Кроме того, вы можете предоставить и принять свой собственный ответ.

— Рон Мопин

Ответы:

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

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

6076 + 40 = 6116.

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

— Питер Тавенье
источник

Возможно ли, что TCP-рукопожатие устанавливает MTU в 6128 байт, а затем iperf обнаруживает, что ему не удалось передать более 6116 байтов за раз - что будет своего рода эмпирическим MTU, не связанным с «официальным»?

— Жан-Марк Лиотье,

Какими бы ни были параметры IP, не существует ли отступ, гарантирующий, что длина (параметры IP + отступ) = 32 бита?

— Жан-Марк Лиотье,

12 байт… Разве вы не имели в виду «параметры TCP» вместо «параметры IP»?

— Жан-Марк Лиотье,

Я выбрал параметры TCP сессии iperf: по-видимому, всегда 12 байтов (только временные метки)

— Жан-Марк Лиотье,

В github.com/jasonrm/iperf/blob/… комментарии говорится, что «// отслеживаем размеры чтения -> дает некоторое представление о размере MTU», а в github.com/jasonrm/iperf/blob/… другой пишет «Сообщить MSS и MTU, учитывая MSS (или их предположение) "- странно, учитывая, что iperf должен поддерживать фактическое обнаружение MTU пути.

— Жан-Марк Лиотье

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

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

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

— Мэтью Лаки
источник