Auteur Sujet: Déboguer les problèmes réseau: la taille des paquets ICMP compte avec mtr  (Lu 4379 fois)

0 Membres et 2 Invités sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 37 278
    • Twitter LaFibre.info
Déboguer les problèmes réseau: la taille des paquets ICMP compte avec mtr

Je reprends ci-dessous un article du blog de Stéphane Bortzmeyer, qui explique concrètement pourquoi tester des traceroute avec la taille par défaut n'est pas une bonne idée.

Avec mtr, c'est l'option --psize qui s'abrége -s, suivit de la taille en octet du paquet IP. La taille minimum est de 28 octets -s28 (si vous mettez une valeur inférieure, le ping sera toujours de 28 octets ; 20 pour les en-tête IP et 8 pour les en-têtes ICMP)
La taille maximale, pour un MTU de 1500 octets, est de 1500 octets -s1500.


Tout administrateur réseaux le sait : lorsqu'il y a un problème de connectivité IP, le premier outil à dégainer est ping. C'est en général un bon réflexe. Mais malheureusement beaucoup de ces administrateurs ne dépassent pas le stade de ping nom-machine et ne regardent jamais le manuel. Ils se privent ainsi d'options intéressantes, comme celle qui permet de faire varier la taille des paquets de test. Ils ont tort car cette taille a une influence importante sur le test.

Prenons un exemple réel, sur un réseau CPL qui marchait mal (adaptateur CPL défaillant, a été changé par la suite). Le Web est peu utilisable (trop lent, certaines images ne chargent pas du tout). Pourtant, ping ne montre aucun problème :


% ping 208.75.84.80
PING 208.75.84.80 (208.75.84.80) 56(84) bytes of data.
64 bytes from 208.75.84.80: icmp_seq=1 ttl=46 time=132 ms
64 bytes from 208.75.84.80: icmp_seq=2 ttl=46 time=131 ms
64 bytes from 208.75.84.80: icmp_seq=3 ttl=46 time=131 ms
64 bytes from 208.75.84.80: icmp_seq=4 ttl=46 time=131 ms
64 bytes from 208.75.84.80: icmp_seq=5 ttl=46 time=132 ms
64 bytes from 208.75.84.80: icmp_seq=6 ttl=46 time=131 ms
64 bytes from 208.75.84.80: icmp_seq=7 ttl=46 time=131 ms
64 bytes from 208.75.84.80: icmp_seq=8 ttl=46 time=131 ms
64 bytes from 208.75.84.80: icmp_seq=9 ttl=46 time=130 ms
64 bytes from 208.75.84.80: icmp_seq=10 ttl=46 time=131 ms
^C
--- 208.75.84.80 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9033ms
rtt min/avg/max/mdev = 130.773/131.526/132.131/0.521 ms


L'excellent logiciel mtr ne montre rien de plus. tcpdump montre peu de trafic (donc la ligne n'est pas surchargée) et de longues attentes (puis ça repart). Mais si on fait varier la taille des paquets avec l'option -s de ping, on voit bien le problème :

% ping -s 1450 208.75.84.80
PING 208.75.84.80 (208.75.84.80) 1450(1478) bytes of data.
1458 bytes from 208.75.84.80: icmp_seq=1 ttl=46 time=168 ms
1458 bytes from 208.75.84.80: icmp_seq=5 ttl=46 time=167 ms
1458 bytes from 208.75.84.80: icmp_seq=6 ttl=46 time=167 ms
1458 bytes from 208.75.84.80: icmp_seq=9 ttl=46 time=169 ms
1458 bytes from 208.75.84.80: icmp_seq=10 ttl=46 time=167 ms
1458 bytes from 208.75.84.80: icmp_seq=13 ttl=46 time=168 ms
1458 bytes from 208.75.84.80: icmp_seq=15 ttl=46 time=168 ms
1458 bytes from 208.75.84.80: icmp_seq=18 ttl=46 time=167 ms
^C
--- 208.75.84.80 ping statistics ---
19 packets transmitted, 8 received, 57% packet loss, time 18013ms
rtt min/avg/max/mdev = 167.407/168.034/169.066/0.639 ms


Avec des paquets de 1450 octets (la taille par défaut utilisée par ping est de 56 octets), le taux de perte, qui était nul, passe à plus de 50 %. On comprend pourquoi le Web avait des problèmes : si les requêtes HTTP sont souvent petites, les réponses, elles, ont en général la taille maximum permise par le réseau (1500 octets pour Ethernet). Si un problème frappe spécifiquement les gros paquets, un ping naïf marchera alors qu'une navigation Web échouera.

Mais pourquoi est-ce que les gros paquets auraient plus de mal à passer que les petits ? Une raison possible est un parasite aléatoire. Si le signal parasite frappe au hasard, les gros paquets auront une probabilité plus élevée d'être touchés (sur Ethernet, en raison de la somme de contrôle des paquets, si un seul bit est modifié, le paquet entier est jeté). Ce genre de choses arrive rarement sur les réseaux filaires mais est bien plus fréquent en WiFi.

Autre exemple de comportement différent selon la taille, les problèmes du point d'échange Sfinx en juin 2011 (ticket Sfinx n° 2215418). Un mtr ordinaire montre un certain pourcentage de pertes, dont la cause est inconnue :


% mtr --report --report-cycles 100 -4 f.root-servers.net
                                  Loss%   Snt   Last   Avg  Best  Wrst StDev
  ...
  3. vl387-te2-6-paris1-rtr-021.n  0.0%   100    1.4   2.2   1.4  33.1   4.4
  4. te0-1-0-3-paris1-rtr-001.noc  0.0%   100   94.2  18.5   1.5  98.7  24.5
  5. isc-f-root-server-2.sfinx.tm  7.0%   100    1.9   4.7   1.8 179.3  20.6
  6. f.root-servers.net            6.0%   100    1.9   2.7   1.8  10.0   1.8


En augmentant la taille des paquets grâce à l'option --psize, le taux de pertes augmente nettement :

% mtr --report --report-cycles 100 --psize 1000 -4 f.root-servers.net
                                  Loss%   Snt   Last   Avg  Best  Wrst StDev
...
  3. vl387-te2-6-paris1-rtr-021.n  0.0%   100    1.6   1.7   1.5  19.6   1.8
  4. te0-1-0-3-paris1-rtr-001.noc  0.0%   100    2.0  19.3   1.7 130.3  24.7
  5. isc-f-root-server-2.sfinx.tm 17.0%   100    2.1   5.3   2.1 179.4  21.2
  6. f.root-servers.net           17.0%   100    2.7   3.5   2.6  10.5   1.9


Cela indique clairement un problème situé dans les couches 1 ou 2, par exemple une mauvaise adaptation Ethernet (half-duplex au lieu de full-duplex). Merci à Johan Remy pour son aide sur ce point.

Autre cas où faire varier la taille est utile, l'étude de problèmes de performances : dans certains cas, c'est le nombre de paquets par seconde qui est le facteur limitant de la performance du réseau, dans d'autres (réseaux lents, par exemple vieux modems), c'est le nombre de bits par seconde et, dans ce cas, le test avec des gros paquets donnera une vision plus réaliste des performances réelles.

Enfin, faire varier la taille des paquets de tests est nécessaire lorsqu'on veut déboguer des problèmes de MTU. En raison de la fréquence des tunnels et d'une incompréhension du rôle d'ICMP par les gérants de pare-feux, c'est le plus souvent IPv6 qui est affecté par ce genre de problèmes. Voici un exemple. Tout se passe bien ?


% ping6 -n e.ext.nic.fr       
PING e.ext.nic.fr(2a00:d78:0:102:193:176:144:6) 56 data bytes
64 bytes from 2a00:d78:0:102:193:176:144:6: icmp_seq=1 ttl=59 time=22.3 ms
64 bytes from 2a00:d78:0:102:193:176:144:6: icmp_seq=2 ttl=59 time=22.7 ms
64 bytes from 2a00:d78:0:102:193:176:144:6: icmp_seq=3 ttl=59 time=22.2 ms
64 bytes from 2a00:d78:0:102:193:176:144:6: icmp_seq=4 ttl=59 time=22.3 ms
64 bytes from 2a00:d78:0:102:193:176:144:6: icmp_seq=5 ttl=59 time=22.3 ms
^C
--- e.ext.nic.fr ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 22.221/22.407/22.772/0.211 ms


Hélas non. Si on augmente la taille des paquets, cela se passe bien jusqu'à une certain valeur :

% ping6 -n -c 5 -s 1400 e.ext.nic.fr
PING e.ext.nic.fr(2a00:d78:0:102:193:176:144:6) 1400 data bytes
1408 bytes from 2a00:d78:0:102:193:176:144:6: icmp_seq=1 ttl=59 time=24.8 ms
1408 bytes from 2a00:d78:0:102:193:176:144:6: icmp_seq=2 ttl=59 time=24.9 ms
1408 bytes from 2a00:d78:0:102:193:176:144:6: icmp_seq=3 ttl=59 time=24.8 ms
1408 bytes from 2a00:d78:0:102:193:176:144:6: icmp_seq=4 ttl=59 time=27.0 ms
1408 bytes from 2a00:d78:0:102:193:176:144:6: icmp_seq=5 ttl=59 time=24.9 ms

--- e.ext.nic.fr ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 24.867/25.339/27.024/0.861 ms


Mais plus après :

% ping6 -n -c 5 -s 1470 e.ext.nic.fr
PING e.ext.nic.fr(2a00:d78:0:102:193:176:144:6) 1470 data bytes

--- e.ext.nic.fr ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4018ms


C'est caractéristique des problèmes de MTU. Lorsque la liaison réseau est correcte (pas de filtrage d'ICMP nulle part), la réduction de la MTU (ici, la machine cible est derrière un tunnel) ne gêne pas :

% ping6 -s 3000 -c 5 2001:470:1f11:3aa::1 
PING 2001:470:1f11:3aa::1(2001:470:1f11:3aa::1) 3000 data bytes
From 2001:470:0:6e::2 icmp_seq=1 Packet too big: mtu=1480
3008 bytes from 2001:470:1f11:3aa::1: icmp_seq=1 ttl=56 time=102 ms
3008 bytes from 2001:470:1f11:3aa::1: icmp_seq=2 ttl=56 time=103 ms
3008 bytes from 2001:470:1f11:3aa::1: icmp_seq=3 ttl=56 time=103 ms
3008 bytes from 2001:470:1f11:3aa::1: icmp_seq=4 ttl=56 time=103 ms
3008 bytes from 2001:470:1f11:3aa::1: icmp_seq=5 ttl=56 time=102 ms

--- 2001:470:1f11:3aa::1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 102.757/102.968/103.097/0.138 ms


Notez le « Packet too big » qui montre que le paquet ICMP a été bien reçu.

Un point important pour tous ces tests : le routage dans l'Internet n'est pas forcèment symétrique. Rien ne dit que les paquets de réponse suivront le même trajet que les paquets de requête. Cela peut rendre le déboguage très délicat : par exemple, une session HTTP où les requêtes (petites) empruntent un chemin et les réponses (grandes) un autre, sera parfois difficile à déboguer avec un ping -s où les paquets auront la même taille à l'aller et au retour (merci à Thomas Mangin pour la précision).

Autre point, question outils. Comme certains réseaux (ou systèmes) traitent différemment les protocoles, le test avec ICMP, que fait ping, peut ne pas être représentatif. Un outil comme hping permet le même genre de manipulations avec les autres protocoles par exemple hping --syn -p 80 --data 1200 example.com va tester en TCP avec des paquets de 1200 octets. hping dispose de nombreuses autres options (merci à Florian Crouzat pour la suggestion).

Bref, pour résumer, lors des entretiens d'embauche d'un administrateur réseaux, pensez à l'interroger sur le rôle de l'option -s. C'est un bon test !


Source : blog de Stéphane Bortzmeyer, le 17 juin 2011

vivien

  • Administrateur
  • *
  • Messages: 37 278
    • Twitter LaFibre.info
Déboguer les problèmes réseau : la taille compte
« Réponse #1 le: 17 septembre 2015 à 17:19:37 »
Un exemple concret où tout se passe bien :

--psize 28 :
$ mtr -s28 -4rwc100 lafibre.info
Start: Thu Sep 17 17:09:16 2015
HOST: ikoula                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 213.246.63.2                 0.0%   100    0.5   1.4   0.3  64.5   6.6
  2.|-- po2.core8.ikdc1.ikoula.com   0.0%   100    0.3   4.9   0.3 142.6  20.4
  3.|-- po5.core13.ikdc2.ikoula.com  0.0%   100    4.0   7.8   4.0 138.0  17.8
  4.|-- po3.core12.ikdc2.ikoula.com  0.0%   100    4.1   6.7   3.9 198.9  19.7
  5.|-- po4.core10.rb.ikoula.com     0.0%   100    4.4   5.1   3.9 100.1   9.6
  6.|-- po1.core9.rb.ikoula.com      0.0%   100    4.1   8.6   4.0 178.4  20.5
  7.|-- po2.core11.th2.ikoula.com    0.0%   100    4.0   9.2   3.9 216.5  25.4
  8.|-- adeli.equinix-ix.fr          0.0%   100    9.5  13.0   9.3 256.2  25.1
  9.|-- lafibre.info                 0.0%   100    9.4   9.4   9.3  10.4   0.0


--psize 1500 :
$ mtr -s1500 -4rwc100 lafibre.info
Start: Thu Sep 17 17:11:07 2015
HOST: ikoula                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 213.246.63.2                 0.0%   100    0.5   2.9   0.4 147.6  15.4
  2.|-- po2.core8.ikdc1.ikoula.com   0.0%   100    0.5   3.4   0.4 179.8  19.2
  3.|-- po5.core13.ikdc2.ikoula.com  0.0%   100    4.1   5.2   4.1  59.8   5.9
  4.|-- po3.core12.ikdc2.ikoula.com  0.0%   100    5.0   7.7   4.0 130.0  19.3
  5.|-- po4.core10.rb.ikoula.com     0.0%   100    4.2   5.7   4.0 134.7  13.0
  6.|-- po1.core9.rb.ikoula.com      0.0%   100    4.4   9.2   4.1 182.6  24.1
  7.|-- po2.core11.th2.ikoula.com    0.0%   100    4.1  11.4   4.0 195.0  29.1
  8.|-- adeli.equinix-ix.fr          0.0%   100    9.6  10.8   9.4  48.6   4.1
  9.|-- lafibre.info                 0.0%   100    9.7   9.7   9.6  10.3   0.0


Les autres options que j'ai utilisé pour mtr :
-4 => Force IPv4 (-6 pour forcer IPv6)
-r => --report donne les info une fois le test termine pour faire un copier / coller (nécessite l'option -c)
-c => --report-cycles COUNT : on indique combien de ping à  faire (option complèmentaire de -r)
-w => permet de ne pas couper le reverse-DNS pour le voir en entier

Bono2007

  • Client Free fibre
  • *
  • Messages: 66
  • 59
Déboguer les problèmes réseau: la taille des paquets ICMP compte avec mtr
« Réponse #2 le: 23 février 2021 à 11:26:08 »
Bonjour, je teste la commande et j'ai ceci:
mtr -s28 -4rwc100 lafibre.info
Start: 2021-02-23T11:19:46+0100
HOST: bonoX470                                 Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- unifi.llc                                 0.0%   100    0.1   0.1   0.1   0.2   0.0
  2.|-- 192.168.9.254                             0.0%   100    0.3   0.2   0.2   0.3   0.0
  3.|-- 194.149.169.85                            0.0%   100    7.6   6.9   6.3   7.6   0.3
  4.|-- ???                                      100.0   100    0.0   0.0   0.0   0.0   0.0
  5.|-- free-bzn.th2-1.rt.hopus.net               0.0%   100    6.6   6.6   6.2   7.2   0.3
  6.|-- lag-th2-1.dc3-2.rt.hopus.net              0.0%   100    7.6   7.3   6.9   7.9   0.3
  7.|-- appliwave.dc3-2.hopus.net                 0.0%   100    6.9   7.1   6.6   8.5   0.3
  8.|-- lo0.ccr2004.edge.dc2.bb.ip4.milkywan.net  0.0%   100    7.3   7.0   6.5  15.6   0.9
  9.|-- lo0.ccr2004.edge.vnx.bb.ip4.milkywan.net  0.0%   100   13.8  13.9  13.3  18.7   0.6
 10.|-- lafibre.cust.milkywan.net                 0.0%   100   15.6  15.6  14.7  38.1   2.5

Aurais-tu une explication pour le 4. ? Merci
Je suis chez Free 10G - Delta S. Pas de problème le matin, mais le soir grosse congestion (comme d'autres).

Hugues

  • AS57199 MilkyWan
  • Expert
  • *
  • Messages: 8 807
  • Paris (19ème)
    • Twitter
Déboguer les problèmes réseau: la taille des paquets ICMP compte avec mtr
« Réponse #3 le: 23 février 2021 à 11:58:22 »
Juste un routeur qui ne répond pas au ping, rien de spécial

 

Mobile View