Traceroute — et son petit frère, ping — est l'un des outils les plus couramment utilisés dans les réseaux dépannageAussi utile que soit cet outil, son utilisation pour résoudre des problèmes actuels beaucoup plus complexes pose quelques défis majeurs. N'oubliez pas que Traceroute a été créé à la fin des années 1980, à une époque où les réseaux étaient bien plus simples.
Tout était physique, le point à point était à la mode et les protocoles à gérer étaient moins nombreux. Les commutateurs étaient communément appelés « ponts », avec des routeurs LAN vers WAN reliant un bâtiment à l'autre. (Rappelez-vous, c'était six ans avant l'avènement d'Internet !) Et qui se souvient des « lignes T1 louées » ? Le bon vieux temps, pour ainsi dire.
Alors, comment des outils anciens comme celui-ci résistent-ils à l'ère du logiciel et de la virtualisation ? Il doit sûrement exister une solution plus moderne pour dépanner les réseaux actuels. Oui, il existe, alors poursuivez votre lecture.
Pour commencer, découvrons la commande traceroute. Nous aborderons ensuite les erreurs de traceroute, ses limites, etc.
La machine source (SRC) envoie généralement trois paquets de test vers l'adresse IP de destination, en commençant par une durée de vie (TTL) définie sur 1. On pense à tort que le type de paquet de test est toujours ICMP. En réalité, cela dépend de l'appareil à l'origine du traceroute. Les systèmes d'exploitation Windows utilisent souvent ICMP, tandis qu'Unix et les périphériques de routage utilisent généralement des messages UDP vers des ports éphémères (ports supérieurs à 1024 qui ne sont pas des services connus comme DNS, SMTP, WEB, etc.).
À mesure que chaque périphérique de couche 3 reçoit le paquet de sonde, sa durée de vie diminue. Lorsque la durée de vie atteint 0, le périphérique récepteur envoie un message ICMP depuis l'interface de réception : « TTL expiré ». C'est ainsi que traceroute identifie chaque saut sur le chemin.
Dans l'image ci-dessous, 172.16.2.1 et 10.3.2.2 seraient les adresses renvoyées dans les résultats de traceroute.
Par défaut, un traceroute indique le chemin entre les points A et B. L'itinéraire inverse nécessite un second traceroute. Voyons pourquoi cela peut constituer une limitation.
Le routage asymétrique est courant dans les réseaux modernes. De nombreux protocoles de routage sont utilisés, notamment :
Selon l'algorithme de hachage utilisé, le trafic empruntera probablement un chemin différent dans chaque direction. Ces différents chemins sont difficiles à détecter par une seule exécution d'une commande traceroute. Il est donc difficile de déterminer l'origine du retard.
Comme vous pouvez le voir ci-dessus, la valeur du délai augmente considérablement sur ce saut. Mais où se situe le délai ? Est-il sur le chemin aller ou retour ?
Si nous regardons à nouveau le traceroute ci-dessus, les seules informations fournies sont :
Pour analyser le saut six, nous devons établir une connexion Telnet ou SSH avec le routeur et déterminer quelle interface est associée à cette adresse IP. « Afficher la route IP 129.259.2.41 » était ma méthode préférée. Cependant, vous pouvez afficher l'interface IP et rediriger la sortie vers un parser… « Afficher le résumé de l'interface IP | dans 129.150.2.41. » Une recherche complémentaire est nécessaire pour identifier l'interface de sortie. Par exemple, « Afficher la route IP 192.41.37.40 ».
La messagerie ICMP signale parfois un retard plus important que celui subi par le trafic, principalement parce qu'elle utilise un traitement de chemin lent plutôt qu'un chemin rapide.
Qu'est-ce qu'un chemin lent ? C'est le moment où le routeur doit traiter le contenu du paquet. Pratiquement tous les paquets destinés à un périphérique sont traités de cette manière. Les mécanismes internes des routeurs récents priorisent les paquets à traiter.
Ils traitent d'abord les mises à jour du protocole de routage, puis les messages ICMP, ce qui aggrave le problème. De nombreux systèmes utilisent des messages UDP. Cependant, la génération du message ICMP TTL expiré est moins prioritaire. Le chemin de retour sera alors un message ICMP. Par conséquent, les mesures de délai fournies dans les résultats sont difficiles à accepter comme des problèmes réels.
CONSEIL : Lorsqu'un traceroute saute à une étape particulière et que les résultats sont faibles, cela indique souvent que le routeur « lent » subit un retard de traitement. Si le chemin saute et que les étapes suivantes sont incrémentées, cela indique généralement une forme de file d'attente due à une congestion.
Nous connaissons maintenant le chemin vers une destination spécifique, mais comment analyser plus en détail d'autres sauts le long du chemin ? Si un utilisateur utilise la console Telnet ou SSH, il devra se connecter à chaque appareil. La réponse traceroute ne fournit que l'adresse IP de l'interface. Dans de nombreux réseaux, cela pose problème.
Les politiques de sécurité exigent que les utilisateurs utilisent Telnet ou SSH pour accéder à l'adresse IP de gestion. Les interfaces spécifiques signalées dans le traceroute peuvent bloquer Telnet, ce qui nécessiterait une recherche manuelle pour déterminer l'interface de gestion de l'appareil avec cette adresse. Sans résolution DNS, cela peut s'avérer quasiment impossible. En cas de panne, chaque seconde peut être comptée.
Comme mentionné précédemment, les routes multichemins à coût égal ou inégal sont courantes dans la plupart des réseaux actuels. Traceroute ne signale que le chemin spécifique faisant partie des messages de sonde d'interrogation. La plupart des implémentations de traceroute courantes envoient trois paquets de sonde avec des ports de destination UDP différents. Par conséquent, dans un environnement ECMP, il est possible que chaque saut ait jusqu'à trois adresses IP différentes signalées. Suivre l'appartenance d'une réponse à un chemin peut s'avérer fastidieux.
Comme nous le comprenons maintenant, traceroute diminue la valeur TTL d'un paquet IP et génère des messages ICMP expirés. Seuls les périphériques de couche 3 diminuent la valeur TTL. Par conséquent, il n'existe aucune visibilité ni fonction intégrée permettant de déterminer facilement le chemin de couche 2 à partir du résultat. La plupart des environnements d'entreprise et de centre de données disposent d'un commutateur d'accès de couche 2 utilisé pour agréger les stations terminales.
Certaines conceptions intègrent une couche de distribution de couche 2 avant d'atteindre un routeur central. Le routeur effectue la première fonction de routage de couche 3, qui peut renvoyer une requête traceroute.
Si une perte de paquets apparaît dans la sortie du traceroute, cela peut être dû à :
Seule l'inspection des éléments de la couche 2 le long du chemin permet de détecter certains problèmes. Pour obtenir ces informations, il faut :
Ce processus peut prendre beaucoup de temps, surtout si CDP/LLDP n’est pas activé sur le réseau ou si la documentation est obsolète.
Les résultats obtenus avec un traceroute correspondent à l'état actuel. Il est impossible de déterminer le chemin utilisé lorsque le trafic a fonctionné (hier, par exemple). Prenons l'exemple du traceroute ci-dessous. Il serait utile de comprendre le saut quatre avant le changement afin d'identifier le problème potentiel.
Note: D'après notre expérience, d'après le résultat de la commande traceroute ci-dessus, les ingénieurs supposent que le problème vient du saut trois. Ce n'est souvent pas le cas. L'utilisateur doit d'abord se connecter à l'appareil au saut trois et vérifier s'il dispose d'une entrée de routage vers la destination. Si c'est le cas, l'appareil problématique est souvent le saut suivant dans l'entrée de routage. Pour être précis, il est utile de vérifier l'interface de sortie vers le saut suivant afin de vérifier les performances au niveau de l'interface et la configuration des listes de contrôle d'accès (ACL).
Lorsque je rencontre un problème avec la commande traceroute, il m'arrive d'obtenir un caractère surprenant dans la sortie. Le tableau ci-dessous est tiré de l'implémentation de traceroute par Cisco. L'une des limites de traceroute est qu'il peut paraître simple, mais comprendre ce qui se passe nécessite généralement des recherches supplémentaires.
Imaginons, par exemple, que je reçoive la lettre A dans la réponse du traceroute. Je comprends qu'une liste d'accès bloque le traceroute, mais de quelle liste d'accès s'agit-il ? Pour le déterminer, je dois :
Ce processus peut être long et nous sommes toujours préoccupés par le temps nécessaire à la résolution des problèmes. Par conséquent, un meilleur accès à ces informations serait précieux.
REMARQUE : D'après notre expérience, ces messages d'erreur de traceroute ne sont générés qu'en fonction de l'interface d'entrée. Une fois qu'un paquet est reçu puis transmis au saut suivant, si une liste de contrôle d'accès (ACL) est présente sur le port de sortie, un astérisque (*) est affiché pour le saut suivant. Cela implique de prendre des mesures supplémentaires pour s'assurer que l'interface de sortie est connue et que toutes les ACL sont validées sur ce port.
NetBrain Il inclut de nombreuses fonctionnalités d'automatisation et de visualisation nécessaires à la maintenance des réseaux modernes. Il comprend les réseaux définis par logiciel, virtualisés et même cloud. Il communique en continu avec chaque appareil du réseau de bout en bout et crée un jumeau numérique en temps réel, reproduisant fidèlement les détails de chaque appareil.
Il peut visualiser les réseaux en temps réel et inclut un remplacement moderne pour traceroute, le Calculateur de chemin A/BCet outil aide les ingénieurs de manière dynamique cartographier un chemin réseau détaillé entre deux points quelconques du réseau.
Il prend en charge la cartographie via des sous-couches, des superpositions et des technologies modernes, notamment :
Simultanément, il prend en compte des protocoles avancés tels que :
Une fois déployée, la structure visualisée est la plate-forme idéale pour automatisation sans code de chaque tâche, grande et petite !
Permettez à vos équipes de dépanner et de diagnostiquer les performances des applications au niveau du flux de trafic avec NetBrain's Garantie des applications (AAM). Il :
Prévenez la dégradation des performances des applications avec NetBrainAutomatisation basée sur l'intention sans code de 's. NetBrain AAM protège l'expérience utilisateur en :