traceroute

Les paquets IP sont acheminés vers la destination en passant d'un routeur à un autre. Chaque routeur examine sa table de routage pour déterminer le routeur suivant. Traceroute va permettre d'identifier les routeurs empruntés, indiquer le délai entre chacun des routeurs et les éventuelles pertes de paquets. Ces informations seront utiles pour diagnostiquer des problèmes de routage, comme des boucles, pour déterminer s'il y a de la congestion ou un autre problème sur un des liens vers la destination.

Le principe de fonctionnement de Traceroute consiste à envoyer des paquets UDP (certaines versions peuvent aussi utiliser TCP ou bien ICMP ECHO Request) avec un paramètre Time-To-Live (TTL) de plus en plus grand (en commençant à 1). Chaque routeur qui reçoit un paquet IP en décrémente le TTL avant de le transmettre. Lorsque le TTL atteint 0, le routeur émet un paquet ICMP d'erreur Time to live exceeded vers la source. Traceroute découvre ainsi les routeurs de proche en proche.

Une fois le paquet sonde arrivé à sa destination finale, traceroute cesse de recevoir des TTL exceeded, et reçoit un paquet réponse ayant pour adresse IP source celle de l'interface de l'équipement sondé à travers laquelle est émis le paquet ICMP. Traceroute essaie volontairement de contacter un port invalide, donc le paquet réponse est normalement de type ICMP Port Unreachable. Si la machine destination avait par hasard un programme écoutant sur ce port, le comportement n'est pas certain et dépend du programme.

Il existe cependant un certain nombre d'éléments qui peuvent compliquer l'interprétation du résultat :

• le chemin suivi par les paquets peut être asymétrique et traceroute ne montre que l'aller ;
• le chemin suivi peut être radicalement différent depuis un autre point, même proche géographiquement ;
• les routeurs émettent le paquet ICMP avec l'adresse source de l'interface utilisée pour vous joindre, ce n'est pas forcément l'interface par laquelle votre paquet sonde est passé ;
• les routeurs ne traitent pas nécessairement les paquets ICMP en transit de la même façon que le trafic de données. Les temps de réponse en cours de route peuvent ne pas refléter ceux que l'on observerait au niveau du trafic applicatif. Ce sera particulièrement le cas si le réseau fait usage de qualité de service et que le trafic sur certains liens approche la congestion.
• la création du paquet ICMP « TTL exceeded » est une opération complexe qui sollicite le CPU du routeur, alors que le trafic est habituellement traité au niveau du matériel spécialisé. Il se peut qu'un délai supplémentaire soit observé si le CPU est occupé à d'autres tâches plus essentielles (gestion des tables de routage, traitement des requêtes de gestion du réseau), alors que ce délai n'a pas d'effet sur le trafic de transit du routeur.
• un routeur peut ne pas répondre aux requêtes ICMP. Dans ce cas, on voit généralement des signes astérisques (*) sur les nœuds intermédiaires qui ne répondent pas aux requêtes ICMP. Il se peut aussi que, pour des raisons de performance, le routeur limite le nombre de paquets ICMP généré par unité de temps, ce qui cause l'apparition d'étoiles sur le parcours, qui ne sont cependant pas le symptôme d'un problème.
• l'adresse IP de la réponse ICMP TTL Exceeded peut être privée (RFC 1918), et donc bloquée en cas de transit par Internet, ou impossible à identifier.

Sous Windows, on utilise l'utilitaire tracert.

%  traceroute fr.wikipedia.org
traceroute to rr.knams.wikimedia.org (145.97.39.155), 30 hops max, 38 byte packets
 1  80.67.162.30 (80.67.162.30)  0.341 ms  0.300 ms  0.299 ms
 2  telehouse2-gw.netaktiv.com (80.67.170.1)  5.686 ms  1.656 ms  0.428 ms
 3  giga.gitoyen.net (80.67.168.16)  1.169 ms  0.704 ms  0.563 ms
 4  62.4.73.27 (62.4.73.27)  2.382 ms  1.623 ms  1.297 ms
 5  ge5-2.mpr2.cdg2.fr.above.net (64.125.23.86)  1.196 ms ge9-4.mpr2.cdg2.fr.above.net (64.125.23.102)  1.290 ms ge5-1.mpr2.cdg2.fr.above.net (64.125.23.82)  30.297 ms
 6  so-5-0-0.cr1.lhr3.uk.above.net (64.125.23.13)  41.900 ms  9.658 ms  9.118 ms
 7  so-7-0-0.mpr1.ams5.nl.above.net (64.125.27.178)  23.403 ms  23.209 ms  23.703 ms
 8  64.125.27.221.available.above.net (64.125.27.221)  19.149 ms so-0-0-0.mpr3.ams1.nl.above.net (64.125.27.181)  19.378 ms 64.125.27.221.available.above.net (64.125.27.221)  20.017 ms
 9  PNI.Surfnet.ams1.above.net (82.98.247.2)  16.834 ms  16.384 ms  16.129 ms
10  af-500.xsr01.amsterdam1a.surf.net (145.145.80.9)  21.525 ms 20.645 ms  24.101 ms
11  kncsw001-router.customer.surf.net (145.145.18.158)  20.233 ms 16.868 ms  19.568 ms
12  gi0-24.csw2-knams.wikimedia.org (145.97.32.29)  23.614 ms  23.270 ms  23.574 ms
13  rr.knams.wikimedia.org (145.97.39.155)  23.992 ms  23.050 ms 23.657 ms

On voit ici que le paquet a transité via Londres (« lhr » est le code international de l'aéroport d'Heathrow) avant d'être acheminé vers Amsterdam « ams ». Cette convention de nommage des routeurs, bien qu'assez répandue en pratique chez les opérateurs de télécommunications, n'est en aucun cas un standard ou une règle.

C:\WINDOWS>tracert fr.wikipedia.org

Détermination de l'itinéraire vers rr.lopar.wikimedia.org [212.85.150.132]
avec un maximum de 30 sauts :

 1    24 ms    22 ms    22 ms  1.32.202.62.cust.bluewin.ch [62.202.32.1]
 2    22 ms    24 ms    22 ms  1.32.202.62.cust.bluewin.ch [62.202.32.1]
 3    24 ms    23 ms    22 ms  net481.bwrt2zhb.bluewin.ch [195.186.121.1]
 4   314 ms   162 ms    22 ms  net125.bwrt1inb.bluewin.ch [195.186.125.71]
 5    34 ms    23 ms    24 ms  if114.ip-plus.bluewin.ch [195.186.0.114]
 6    27 ms    29 ms    29 ms  i68geb-005-gig4-2.bb.ip-plus.net [138.187.130.158]
 7    39 ms    39 ms    38 ms  i00par-005-pos4-0.bb.ip-plus.net [138.187.129.34]
 8    38 ms   320 ms    39 ms  feth2-kara-ielo.freeix.net [213.228.3.203]
 9   284 ms    39 ms    39 ms  feth0-bestelle.tlcy.fr.core.ielo.net [212.85.144.6]
10    90 ms   158 ms    83 ms  chloe.wikimedia.org [212.85.150.132]

Itinéraire déterminé.

Le client avec l'adresse IP 62.202.32.1 se connecte au serveur wikipedia en passant par différents routeurs.