1. Ayez la vue de chaque côté du tuyau

Effectuez une capture de chaque côté de la transaction à analyser en utilisant le MultiHop Analysis d’Observer Expert® pour étudier si un des segments est la source de la latence. Apprenez comment configurer l'analyse multi-points.

2. identifier la valeur de TTL (Time to Live) pour connaître combien de sauts (hops)

Si vous analysez la latence entre des bureaux distants, vous devez identifier où le retard se produit. Si vous savez qu’en moyenne les trames mettent 13 sauts pour aller d’un bureau à distance au siège social et que maintenant cela prend 20 sauts, ceci peut indiquer la source de retard. Le nombre de sauts qui se produit pour un itinéraire est déterminé en calculant la différence entre les valeurs de TTL à partir de la source jusqu’à la destination. Ayant déterminé le nombre de sauts, nous verrons si un de ces saut cause de la fragmentation.

3. configurer des filtres pour rechercher des champs de fragmentation dans l'en-tête avec More Fragments ou Don’t Fragment

Des problèmes de fragmentation font que des paquets sont inutilement coupés en de multiples paquets et augmente de ce fait la charge de travail et le retard. Les paquets avec More Fragment peuvent indiquer qu'un routeur le long du chemin fragmente les trames. Tandis que les paquets ayant Don’t Fragment indique très probablement un problème d'application.

4. construisez des filtres pour rechercher des messages d'ICMP

Si un routeur jette un paquet avec Don’t Fragment, il en informera l'expéditeur par l'intermédiaire d'ICMP (Internet Control Message Protocol). Le message peut déterminer la nature et la source exactes de problèmes. Les messages ICMP autres que des pings peuvent indiquer des problèmes de subnet, de masque, de routage, de passerelle par défaut, ou de QoS.

Message d'ICMP	Issue probable
Redirect for Network	La passerelle par défaut n’est pas bien configurée
Redirect for Host	Le masque de subnet est mal configuré
Port Unreachable	Port d'application ne répond pas ou non démarré
Host Unreachable	A la route mais l’équipement ne répondant pas à la demande d'ARP
Protocol Unreachable	Réponse à demande d'ARP mais l’équipement ne répondant pas à la demande spécifique de protocole
Network Unreachable	Le routeur n'a pas l'itinéraire pour atteindre le réseau

Si la couche réseau est sans erreur, la prochaine étape est d'analyser la livraison et l'exécution des applications. Pour découvrir le MultiHop Analysis et le système Expert d'analyse Applicative, lisez le livre blanc Network Application Performance (en Anglais).

Filtre des messages ICMP

Une étape critique dans le dépannage des problèmes réseau est d’identifier rapidement la source de la latence le long d'une route réseau. Les messages ICMP fournissent une manière simple d'identifier la source d’un problème réseau. Créez un filtre pour identifier les erreurs de redirections et de non atteignable (« non reachable ») avec Observer en suivant les étapes suivantes :

1. Dans l'écran principal de la console Observer, menu Actions -> Configuration des filtres pour la sonde sélectionnée…

2. Cliquez sur New Filter dans la fenêtre Active Filters et intitulez le filtre ICMP. Cliquez OK

3. dans la fenêtre Edit Filter, choisissez Edit Filter > Edit Rule As > Protocol

 

4. dans la fenêtre Protocol Filter, déroulez et choisissez ICMP et sélectionnez le filtre désiré du protocole. Pour cet exemple, choisir «Destination Unreachable».

5. pour ajouter d'autres messages d'ICMP au filtre, click droit sur le filtre de protocole et choisissez <OR> puis Protocol > ICMP > Redirect.

En créant avec succès un filtre ICMP vous automatisez le processus qui découvre les erreurs et cela vous rendra la vie plus facile pour déterminer si le problème vient du réseau ou d’ailleurs.

réduire le temps de dépannage de 20%

Et si vous pourriez libérer un jour de travail par semaine sans avoir à faire des tâches de dépannage ? Apprenez comment un nouveau client a automatisé et amélioré son processus de dépannage, tout en réalisant un retour complet sur leur investissement en 24 mois. (en Anglais)

 

 

Tous droits réservés. Network Instruments, Observer, GigaStor, Link Analyst, et tous les logos associés à Network Instruments sont des marques enregistrées de Network Instruments, LLC.
Toutes les autres marques, protégées ou non, sont la propriété de leurs auteurs respectifs.
Network Instruments, LLC, 10701 Red Circle Drive, Minnetonka, MN 55343