Чому б iperf, scamper і path MTU пакет виявлення пакетів не узгодили MTU шляху?

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

Використання шахрая :

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 не можуть обробляти рамки jumbo пристойного розміру).

Тепер дозвольте 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.length 24, крім двох останніх, які мають udp.length 6108 ... Але тоді як шахрай говорить нам, що шлях MTU дорівнює 6128?

6108, 6116, 6128 ... Стільки МТУ на вибір!

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 повинен підтримувати фактичне відкриття Path MTU.

— Жан-Марк Ліотьє

tshark повідомляє розмір кадру Ethernet: 6142 - 14 (заголовок Ethernet) = 6128 байт IP.

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

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

— Метью Лукі
джерело