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!
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 ...
la source
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
la source