Méthodes et outils de dépannage de réseau

Méthodes et outils de dépannage de réseau cisco

Au cours de plusieurs article sur ce site web, le dépannage de réseau a fait partie de nombreux sujets d’examen. Aujourd’hui, nous passons en revue les sujets d’examen qui portent spécifiquement sur le dépannage.

Documentation du dépannage réseau Cisco

Pour surveiller et dépanner un réseau, les administrateurs réseau doivent disposer d’une documentation réseau complète, précise et à jour. Cette documentation comprend les éléments suivants :

  • Fichiers de configuration, y compris les fichiers de configuration réseau et les fichiers de configuration du système final
  • Diagrammes des topologies physique et logique
  • Un niveau de performance de référence

Fichiers de configuration

Les fichiers de configuration réseau doivent contenir des informations détaillées pour chaque périphérique réseau, telles que les suivantes :

  • Type d’appareil et désignation du modèle
  • Nom de l’image IOS
  • Nom d’hôte du périphérique réseau
  • Emplacement de l’appareil (bâtiment, étage, pièce, rack, panneau)
  • Tous les types de modules et l’emplacement où ils se trouvent (s’il s’agit d’un appareil modulaire)
  • Adresses des couches de liaison de données
  • Adresses de la couche réseau
  • Toute autre information importante sur les aspects physiques de l’appareil

Les informations suivantes peuvent être documentées dans les fichiers de configuration du système final :

  • Nom de l’appareil (raison d’être)
  • Système d’exploitation et version
  • Adresses IPv4 et IPv6
  • Masque de sous-réseau et longueur du préfixe
  • Adresses par défaut de la passerelle, du serveur DNS et du serveur WINS
  • Toutes les applications réseau à large bande passante que le système final exécute.

Diagrammes topologiques

Les topologies physiques comprennent généralement des informations vitales pour aider les techniciens du réseau à localiser et à résoudre les problèmes. La figure A montre un exemple simplifié du type d’information que vous pourriez trouver sur une topologie physique.

Figure A - Topologie physique
Figure A – Topologie physique

NOTE: Une topologie physique d’un réseau existant est généralement beaucoup plus complexe que l’exemple montré ici.

Les topologies physique et logique peuvent être combinées en une seule topologie réseau. Cependant, cela pourrait rendre la documentation complexe et bruyante en termes de données.

Figure B - Topologie logique
Figure B – Topologie logique

Par conséquent, les organisations ont souvent une topologie logique séparée, comme dans l’exemple de la figure B.

Date de référence

La base de référence initiale de la performance du réseau prépare le terrain pour mesurer les effets des modifications du réseau et les efforts de dépannage qui s’ensuivent. L’établissement de cette base de référence nécessite trois grandes étapes :

Étape 1. Déterminer les types de données à recueillir.
Étape 2. Identifier les périphériques et les ports d’intérêt.
Étape 3. Déterminer la durée de la base de référence.

Vous pouvez collecter manuellement une grande partie des données à l’aide des commandes show que vous avez appris au cours de vos études (show ip route, show ip interface brief, show running-config, et ainsi de suite).

Toutefois, l’établissement d’une base de référence initiale et la réalisation d’une analyse de la surveillance du rendement nécessitent plusieurs heures ou plusieurs jours pour refléter avec précision le rendement du réseau.

Les logiciels de gestion de réseau ou les inspecteurs et sniffers de protocole fonctionnent souvent en continu tout au long du processus de collecte des données.

Méthodes de dépannage de réseau

Quelle que soit la méthode que vous utilisez, le dépannage d’un problème réseau comporte trois étapes principales, comme le montre la Figure C.

Figure C - Le processus de dépannage de réseau
Figure C – Le processus de dépannage de réseau

Au cours de la première étape, des symptômes peuvent apparaître sous de nombreuses formes différentes, y compris des alertes provenant des systèmes de gestion de réseau, des messages de console et des tickets de help desk.

Les informations recueillies à partir de ces symptômes finissent par attirer l’attention de l’administrateur réseau sur une zone du réseau – un seul appareil, un groupe d’appareils ou un sous-réseau entier d’appareils.

Au cours de la deuxième étape, l’administrateur réseau isole le problème en utilisant des outils qui génèrent le plus souvent les données nécessaires pour recommander une démarche à suivre pour la prochaine étape.

Enfin, dans la troisième étape, l’administrateur réseau met en œuvre la solution la plus appropriée et la teste. Si le problème initial est résolu, l’administrateur documente et enregistre la solution.

Si le problème n’est pas résolu, l’administrateur supprime la solution mise en œuvre et revient à la première étape (collecte des symptômes).

Une façon systématique de mettre en œuvre le processus de dépannage consiste à utiliser le modèle OSI et l’une des trois méthodes suivantes :

De bas en haut : Commencez par la couche physique et vérifiez tous les composants physiques. Comme de nombreux problèmes sont liés à la couche 1, cette méthode s’avère souvent efficace. L’inconvénient est que cette méthode consiste à vérifier physiquement chaque appareil dans la zone affectée du réseau.

De haut en bas : Commencer par les applications de l’utilisateur final qui ne fonctionnent pas correctement et descendre à travers les couches. Cette méthode s’avère plus efficace lorsque le problème est lié a un logiciel. L’inconvénient est qu’il faut vérifier chaque application réseau jusqu’à ce que le problème éventuel soit trouvé. Par quelle application commencez-vous?

Diviser pour régner : L’administrateur réseau utilise l’expérience et la nature des symptômes pour faire une prédiction fondée de la couche OSI à partir de laquelle il faut lancer le diagnostic. Après avoir vérifié qu’une couche fonctionne correctement, l’administrateur peut supposer que les couches inférieures fonctionnent.

L’administrateur peut alors remonter dans les couches OSI. Si une couche OSI ne fonctionne pas correctement, l’administrateur peut descendre dans le modèle de couche OSI pour trouver la source du problème. L’inconvénient de cette méthode est qu’elle nécessite plus d’expertise que les autres méthodes.

Pour résoudre rapidement les problèmes de réseau, prenez le temps de choisir la méthode de dépannage de réseau la plus efficace. (voir Figure D).

Figure D - Lignes directrices pour le choix d'une méthode de dépannage
Figure D – Lignes directrices pour le choix d’une méthode de dépannage

Dépannage réseau à chaque couche

La présente section passe en revue certains des problèmes les plus courants à chaque niveau du modèle OSI.

Couche physique

Comme les couches supérieures du modèle OSI dépendent de la couche physique pour fonctionner, un administrateur réseau doit savoir comment isoler et corriger efficacement les problèmes à cette couche. La figure E montre les symptômes typiques et leurs causes associées à la couche physique.

Figure E - Symptômes et causes de la couche physique
Figure E – Symptômes et causes de la couche physique

Couche de liaison de données

Les problèmes de la couche 2 causent des symptômes spécifiques qui, lorsqu’ils sont reconnus, aident à identifier rapidement le problème. La figure F montre des symptômes typiques et leurs causes associées au niveau de la couche de liaison de données.

Figure F - Symptômes et causes de la couche de liaison de données
Figure F – Symptômes et causes de la couche de liaison de données

Couche réseau

Les problèmes de couche réseau comprennent tout problème impliquant un protocole de couche 3, qu’il s’agisse de protocoles routés (tels que IPv4 ou IPv6) ou de protocoles de routage (tels que EIGRP et OSPF).

La figure G montre des symptômes typiques et leurs causes associées au niveau de la couche réseau.

Figure G - Symptômes et causes de la couche réseau
Figure G – Symptômes et causes de la couche réseau

Couche de transport

Les problèmes de réseau peuvent résulter de problèmes de couche transport sur le routeur, en particulier à la périphérie du réseau où le trafic est examiné et modifié.

Deux des technologies de couche de transport les plus couramment mises en œuvre sont les listes de contrôle d’accès (ACL) et la translation d’adresse réseau (NAT), comme le montre la Figure H.

Figure H - Symptômes et causes de la couche de transport
Figure H – Symptômes et causes de la couche de transport

Les problèmes les plus fréquents avec les ACLs résultent d’une mauvaise configuration, comme l’illustre la Figure I.

Figure I - Mauvaises configurations courantes des ACLs
Figure I – Mauvaises configurations courantes des ACLs

Le NAT peut causer certains problèmes uniques, y compris un NAT mal configuré à l’intérieur ou à l’extérieur, ou des listes de contrôle d’accès mal configurées (ACL). Le NAT peut également causer des problèmes lors de l’interopérabilité avec d’autres technologies, telles que celles de la Figure J.

Figure J - Problèmes communs d'interopérabilité avec le NAT
Figure J – Problèmes communs d’interopérabilité avec le NAT

Couche d’application

Les problèmes de couche d’application empêchent les services TCP/IP d’être fournis aux programmes d’application.

Un problème au niveau de la couche application peut entraîner un problème de ressources inaccessibles ou inutilisables lorsque les couches physique, liaison de données, réseau et transport sont fonctionnelles. Il est possible d’avoir une connectivité réseau complète, mais l’application ne peut tout simplement pas fournir des données.

Les types de symptômes et de causes dépendent de l’application elle-même. La Figure K montre les protocoles les plus populaires qui peuvent causer des problèmes au niveau de la couche application.

Figure K - Protocoles de couche d'application
Figure K – Protocoles de couche d’application

La méthode ascendante et les couches OSI

Lorsqu’il n’existe pas de connectivité de bout en bout et que vous choisissez d’utiliser la méthode ascendante, vous pouvez suivre ces étapes types :

Étape 1. Vérifiez la connectivité physique au point où la communication réseau s’arrête.

Étape 2. Vérifiez s’il n’y a pas d’erreurs duplex.

Étape 3. Vérifier la liaison de données et l’adressage de la couche réseau sur le réseau local. Cela inclut les tables ARP IPv4, les tables de voisins IPv6, les tables d’adresses MAC et les affectations VLAN.

Étape 4. Vérifiez que les passerelles par défaut sont correctement configurées sur les périphériques qui en ont besoin.

Étape 5. Assurez-vous que les périphériques déterminent le chemin correct de la source à la destination.
Manipulez les informations de routage, si nécessaire.

Étape 6. Vérifiez que la couche de transport fonctionne correctement. Vous pouvez également utiliser Telnet pour tester les connexions de la couche transport depuis la ligne de commande.

Étape 7. Vérifiez qu’aucune liste de contrôle d’accès ne bloque le trafic.

Étape 8. Assurez-vous que les paramètres DNS sont corrects et qu’un serveur DNS est accessible.

Dépannage avec IP Service Level Agreement (SLA)

La fonction d’accord de niveau de service IP (SLA) sur les routeurs Cisco permet de mesurer les performances sur une période de temps pour déterminer si une liaison respecte son accord de niveau de service.

Cela contribue au dépannage en identifiant immédiatement l’existence d’un problème. Plusieurs opérations IP SLA peuvent être exécutées sur le réseau ou sur un périphérique à tout moment. Les informations IP SLA sont affichées à l’aide des commandes CLI ou via SNMP.

Un ingénieur réseau peut utiliser l’opération IP SLA ICMP Echo pour tester de façon intermittente et automatique la disponibilité des périphériques réseau.

Par exemple, un appareil peut être configuré avec un IP SLA qui envoie un ping toutes les 30 secondes. Cette opération IP SLA ICMP ICMP Echo fournit les mesures suivantes :

  • Surveillance de la disponibilité (statistiques de perte de paquets)
  • Suivi des performances (latence et temps de réponse)
  • Exploitation du réseau (connectivité de bout en bout)

Considérons la topologie de la figure L. L’administrateur réseau veut mesurer la qualité de la liaison entre R1 et R3 dans le temps.

Figure L - Topologie de la configuration IP SLA
Figure L – Topologie de la configuration IP SLA

L’exemple A montre la configuration de R1.

Example A – Configuration IP SLA

R1(config)# ip sla 1
R1(config-ip-sla)# icmp-echo 192.168.1.5
R1(config-ip-sla-echo)# frequency 30
R1(config-ip-sla-echo)# exit
R1(config)# ip sla schedule 1 start-time now life forever
R1(config)# end
R1#

 

REMARQUE : Pour configurer les IP SLAs, assurez-vous que le package de technologie de sécurité est activé sur l’appareil Cisco.

Les étapes suivantes expliquent la configuration :

Étape 1. La commande ip sla configure un numéro IP SLA défini par l’utilisateur et passe en mode de configuration IP SLA.

Étape 2. La commande icmp-echo configure l’adresse IP pour tester le SLA.

Étape 3. La commande de fréquence définit la fréquence (en secondes) à laquelle le ping est envoyé .

Étape 4. La commande ip sla schedule définit un planning pour un IP SLA configuré. Dans l’exemple, IP SLA 1 est configuré pour démarrer immédiatement et fonctionner pour toujours ou jusqu’à ce que l’administrateur réseau l’arrête.

Utilisez la commande show ip sla configuration pour vérifier le SLA IP, comme dans l’exemple B.

Example B – Verification de la configuration IP SLA

R1# show ip sla configuration
IP SLAs Infrastructure Engine-III
Entry number: 1
Owner:
Tag:
Operation timeout (milliseconds): 5000
Type of operation to perform: icmp-echo
Target address/Source address: 192.168.1.5/0.0.0.0
Type Of Service parameter: 0x0
Request size (ARR data portion): 28
Verify data: No
Vrf Name:
Schedule:
   Operation frequency (seconds): 30 (not considered if randomly scheduled)
   Next Scheduled Start Time: Start Time already passed
   Group Scheduled : FALSE
   Randomly Scheduled : FALSE
   Life (seconds): Forever
   Entry Ageout (seconds): never
   Recurring (Starting Everyday): FALSE
   Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
   Number of statistic hours kept: 2
   Number of statistic distribution buckets kept: 1
   Statistic distribution interval (milliseconds): 20
Enhanced History:
History Statistics:
   Number of history Lives kept: 0
   Number of history Buckets kept: 15
   History Filter Type: None
R1#

Utilisez la commande show ip sla statistics pour afficher les statistiques de surveillance des opérations IP SLA, comme dans l’exemple C.

Exemple C – Affichage des statistiques IP SLA

R1# show ip sla statistics

IPSLAs Latest Operation Statistics
   IPSLA operation id: 1
Latest RTT: 1 milliseconds
Latest operation start time: 12:15:36 UTC Sat Dec 17 2016
Latest operation return code: OK
Number of successes: 10
Number of failures: 0
Operation time to live: Forever
R1#

 

LAISSER UN COMMENTAIRE

Please enter your comment!
Please enter your name here


CAPTCHA Image
Reload Image