Un traceroute / tracert montre-t-il chaque saut ou saute-t-il / cache-t-il certains détails du chemin?

Je suis actuellement au collège pour un baccalauréat en ingénierie de réseau et un de mes professeurs a expliqué en classe qu'un traceroute qui montre, par exemple, 15 sauts est en train de faire abstraction du chemin, et en réalité beaucoup plus de nœuds sont impliqués. Est-ce vrai?

Cela contredit tout ce que je peux trouver sur traceroute. À ma connaissance, traceroute fonctionne en envoyant des paquets ICMP (ou UDP) à une destination spécifique avec une durée de vie comprise entre 0 -> n jusqu'à ce que la destination soit atteinte. Les paquets de sondage envoyés expirent à chaque emplacement le long du chemin, ce qui génère une réponse ICMP "délai dépassé" et enfin un message "port inaccessible" lorsqu’il atteint la destination.

Je comprends les imperfections de traceroute - par exemple, le trafic de traceroute peut être bloqué par certaines passerelles ou la durée de vie du paquet de réponse peut être définie sur la durée de vie restante de la sonde, l'empêchant de ne jamais revenir à l'expéditeur.

Cependant, après de nombreuses recherches, je ne trouve plus rien qui fasse référence au traceroute qui soit inexact dans le cas d’un traceroute qui retourne toujours le même chemin. De même, rien ne mentionne l'existence de sauts "supplémentaires" non signalés par traceroute (autres que les sauts * * * ayant expiré sans réponse).

Je suis ouvert à la discussion et je suis vraiment intéressé de connaître la réponse à cette question.

Une traceroute vous indiquera le nombre de sauts de couche 3 que vous avez obtenus de A à B.

Cependant, vous pourriez passer par des centaines de commutateurs entre les deux. Vous pourriez également passer par 10 routeurs ISP exécutant un vpn de couche 2 qui apparaît sous la forme d’un saut simple. Un réseau MPLS peut cacher ses éléments internes ou vous en montrer les éléments internes. Vous pouvez également avoir des pare-feu transparents dans le chemin.

Dans les deux cas, votre professeur a raison de dire que vous ne pouvez pas garantir que chaque périphérique du chemin comptera pour vous. En raison des points ci-dessus que j'ai mentionnés, vous pourriez utiliser 50 appareils, mais cela pourrait vous sembler être trois.

Cela n'arrive pas tout le temps cependant. Si vous voyez 15 sauts, il pourrait très bien s'agir de 15 sauts.

Voici un exemple de base d'une configuration MPLS en matière de TTL: http://www.juniper.net/techpubs/en_US/junos13.2/topics/reference/configuration-statement/no-propagate-ttl-edit-protocols -mpls.html

Tout périphérique qui ne décrémente pas la valeur du champ IP TTL ne sera pas affiché dans le chemin traceroute. Par exemple, Cisco ASA Firewall peut être configuré pour décrémenter le champ IP TTL pour les paquets traversant le pare-feu ( set connection decrement-ttl ). Par défaut, la durée de vie n'est pas en cours de décrémentation, masquant ainsi (quelque peu) le pare-feu.

Traceroute ne vous montrera pas les périphériques qui ne décrémentent pas les champs TTL d'un datagramme IP.

De plus, il ne montrera pas les périphériques qui décrémentent le champ TTL et consomment le paquet si la durée de vie atteint zéro, mais négligent d'informer l'expéditeur de cet événement via un datagramme ICMP. Ce n'est pas entièrement invisible cependant; vous pouvez en déduire l'existence de ce saut manquant dans traceroute car, lorsque la valeur TTL immédiatement supérieure est utilisée, le périphérique suivant de la chaîne répond, et nous savons que quelque chose entre ce dernier et le périphérique précédent décrémente la durée de vie, mais ne s'annonce pas lui-même. . L' tracerouteutilitaire traditionnel imprime des astérisques lorsqu'il ne reçoit pas de réponse. il afficherait une rangée d’astérisques pour ce type d’hôte.

Il existe également la possibilité à distance qu'un routeur situé entre les deux supprime de manière sélective ces messages ICMP en fonction de leur adresse source, rendant ainsi certaines parties du chemin invisibles, même si elles ont généré la réponse.