Pourquoi les captures de paquets de découverte iperf, scamper et path MTU ne conviennent-elles pas sur la MTU du chemin?

Faisons une découverte de MTU de chemin entre deux hôtes Debian séparés par un routeur Debian qui exécute les règles iptables générées par Shorewall. Chacun des deux hôtes utilise une seule liaison Ethernet tandis que le routeur utilise des VLAN balisés sur deux liaisons Ethernet agrégées.

Utilisation de 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]

Bon: 6128 octets est le résultat attendu (les adaptateurs Ethernet Realtek bon marché ne peuvent pas gérer les trames jumbo d'une taille décente).

Maintenant, laissez iperf effectuer un test de débit et parlez-nous du MTU en passant:

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 octets? Pourquoi ?

Et maintenant, pour quelque chose de complètement différent, voyons ce que le trafic de cette session contenait réellement:

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 octets MSS, ce qui signifie un 6128 MTU ... Bon. Mais alors pourquoi iperf annonce-t-il un MTU de 6116 octets?

À ce stade, la minutie nécessite un examen plus approfondi de ce qui se passe pendant la session de suivi du 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)

Tous ces paquets ont une longueur udp de 24 sauf les deux derniers qui ont une longueur udp de 6108 ... Mais alors comment le scamper nous dit-il que le chemin MTU est 6128?

6108, 6116, 6128 ... Tant de MTU au choix!

routing ipv4

— Jean-Marc Liotier
source

Une réponse vous a-t-elle aidé? si c'est le cas, vous devez accepter la réponse afin que la question ne s'affiche pas indéfiniment, à la recherche d'une réponse. Alternativement, vous pouvez fournir et accepter votre propre réponse.

— Ron Maupin

Réponses:

Très intéressant.

MSS (taille de segment maximale) = MTU - en-tête IP = 6076.

6076 + 40 = 6116.

Serait-ce que Debian utilise les champs d'options IP dans l'en-tête IP? Cela pourrait être les 12 octets supplémentaires ...

— Peter Tavenier
source

Est-il possible que la prise de contact TCP établisse une MTU de 6128 octets puis qu'iperf découvre qu'il n'a pas réussi à transmettre plus de 6116 octets à la fois - ce qui serait une sorte de MTU empirique sans rapport avec celle "officielle"?

— Jean-Marc Liotier

Quelles que soient les options IP, n'y a-t-il pas un remplissage qui garantit que la longueur (options IP + remplissage) = 32 bits?

— Jean-Marc Liotier

12 octets… Vous ne vouliez pas dire «options TCP» au lieu de «options IP»?

— Jean-Marc Liotier

J'ai échantillonné les options TCP de la session iperf: apparemment toujours 12 octets (seulement les horodatages)

— Jean-Marc Liotier

Dans github.com/jasonrm/iperf/blob/… un commentaire dit "// garder une trace des tailles de lecture -> donne une indication de la taille MTU" et dans github.com/jasonrm/iperf/blob/… un autre dit "Rapport le MSS et le MTU, étant donné le MSS (ou une supposition de celui-ci) "- étrange étant donné que l'iperf est censé prendre en charge la découverte réelle du MTU de chemin.

— Jean-Marc Liotier

tshark signale la taille de la trame Ethernet: 6142 - 14 (en-tête Ethernet) = 6128 octets IP.

scamper fait un traceroute avec de petits paquets avant de sonder avec de gros paquets pour la découverte MTU (c'est pourquoi vous voyez de petits paquets suivis d'un gros). ceci est utile pour faire la distinction entre tous les paquets rejetés / qui ne répondent pas et seulement les gros.

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

— Matthew Luckie
source