Perché le acquisizioni di pacchetti di rilevamento MTU iperf, scamper e path non concordano sull'MTU del percorso?

Facciamo un po 'di percorso MTU discovery tra due host Debian separati da un router Debian che esegue regole iptables generate da Shorewall. Ciascuno dei due host utilizza un singolo collegamento Ethernet mentre il router utilizza VLAN con tag su due collegamenti Ethernet aggregati.

Utilizzando 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]

Buono: 6128 byte è il risultato atteso (gli adattatori Ethernet Realtek economici non sono in grado di gestire frame jumbo di dimensioni decenti).

Ora, lascia che iperf esegua un test di throughput e parlaci dell'MTU a proposito:

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 byte? Perché ?

E ora qualcosa di completamente diverso, vediamo cosa conteneva effettivamente il traffico di questa sessione:

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 byte MSS, che significa un 6128 MTU ... Buono. Ma allora perché iperf annuncia un MTU 6116 byte?

A quel punto la completezza richiede uno sguardo più da vicino a ciò che accade durante la sessione di tracciamento degli scamper:

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)

Tutti quei pacchetti hanno una lunghezza udp.l di 24 tranne i due ultimi che hanno una lunghezza udp. di 6108 ... Ma come fa Scamper a dirci che il percorso MTU è 6128?

6108, 6116, 6128 ... Tanti MTU tra cui scegliere!

routing ipv4

— Jean-Marc Liotier
fonte

Qualche risposta ti è stata d'aiuto? in tal caso, dovresti accettare la risposta in modo che la domanda non continui a comparire per sempre, cercando una risposta. In alternativa, potresti fornire e accettare la tua risposta.

— Ron Maupin

Risposte:

Molto interessante.

MSS (dimensione massima del segmento) = MTU - intestazione IP = 6076.

6076 + 40 = 6116.

Debian potrebbe usare i campi delle opzioni IP nell'intestazione IP? Potrebbero essere i 12 byte extra ...

— Peter Tavenier
fonte

È possibile che l'handshake TCP stabilisca un MTU a 6128 byte e poi iperf scopre che non è riuscito a trasmettere più di 6116 byte alla volta, il che sarebbe una sorta di MTU empirico non correlato a quello "ufficiale"?

— Jean-Marc Liotier,

Indipendentemente dalle opzioni IP, non esiste un'imbottitura che garantisce che la lunghezza (opzioni IP + imbottitura) = 32 bit?

— Jean-Marc Liotier,

12 byte ... Non intendevi "Opzioni TCP" anziché "Opzioni IP"?

— Jean-Marc Liotier,

Ho campionato le opzioni TCP della sessione iperf: apparentemente sempre 12 byte (solo i timestamp)

— Jean-Marc Liotier

In github.com/jasonrm/iperf/blob/… un commento dice "// tenere traccia delle dimensioni di lettura -> fornisce alcune indicazioni sulla dimensione MTU" e in github.com/jasonrm/iperf/blob/… un altro dice "Segnala MSS e MTU, dato l'MSS (o una sua ipotesi) "- strano considerando che si suppone che iperf supporti l'attuale MTU Discovery.

— Jean-Marc Liotier,

tshark riporta le dimensioni del frame Ethernet: 6142-14 (intestazione Ethernet) = 6128 byte IP.

scamper esegue un traceroute con piccoli pacchetti prima di sondare con pacchetti di grandi dimensioni per il rilevamento di MTU (ecco perché vedete piccoli pacchetti seguiti da uno grande). questo è utile per distinguere tra tutti i pacchetti che vengono scartati / che non rispondono e solo quelli più grandi.

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

— Matthew Luckie
fonte