Dépannage IPv4 : Il est impossible d’écrire un ensemble de procédures de dépannage qui résoudraient tout problème de connectivité IP. Même si chaque problème dépend de nombreux facteurs, nous allons voir les étapes d’analyses afin de résoudre au mieux un problème réseau.

Dépannage IPv4 : Guide de dépannage

Dans une entreprise, lorsqu’il y’a un problème réseau, l’utilisateur informera l’administrateur. C’est lui qui commencera le processus de dépannage.

Nous allons le détailler en plusieurs étapes :

• Connectivité physique

• Identification du chemin

• Vérification de la Gateway

• DNS Incorrect

• Trafic bloqué par ACL

           Connectivité physique

La première chose à faire est de commencer par vérifier la connectivité physique.
Il existe trois catégories principales de problèmes qui pourraient être à l’origine d’une panne sur le réseau : les pannes matérielles, les pannes de logiciels (bugs) et les erreurs de configuration. Une quatrième catégorie pourrait être des problèmes de performance, mais ce type-là est plutôt un symptôme et non la cause d’un problème.

Après avoir commencé par des ping et traceroute pour bien déterminer qu’un problème de connectivité réseau existe, il faut commencer par analysé la couche physique avant de s’impliquer dans un dépannage plus complexe. Il est tout à fait possible de passer des heures à dépanner juste pour constater que le problème vient d’un câble réseau qui est mal connecté ou défectueux.

 

Si on a, un accès aux périphériques, on peut allez checker l’état des leds des ports des équipements. Ces LED’s affichent l’état du lien et permettent d’indiquer s’il existe des erreurs. Par exemple, s’il n’y a pas de lumière sur un lien, il faut alors vérifier aux deux extrémités du câble s’ils sont bien branchés.

Les interfaces ou le trafic circulent, est un élément qui vaut toujours la peine d’être vérifié, en cas de problème sur la performance ou s’il y’a carrément une panne matérielle. Généralement, c’est la première chose qu’on regarde en cas de problème, pour suivre le chemin entre les périphériques.

la sortie de la commande « show interfaces » affiche des statistiques importantes qui doivent être vérifiées.

la première ligne de sortie de cette commande nous indique si l’interface est up ou down.

la seconde ligne indique des informations sur la file d’attente. Cela permet de voir si le routeur reçoit trop de données qu’il ne pourrait traiter. Cela n’indique pas forcément un problème, car c’est normal pendant un pic de trafic. Mais si ces données sont constamment élevées, il faudrait en déterminer la cause.

L’output drops, indiquent le nombre de paquets qui ont été droper suite à une congestion de l’interface. Pendant les pics de Traffic, les paquets sont supprimés, si le trafic est livré à l’interface plus rapidement que l’interface peut l’envoyer. Ce comportement peut être normal, mais cela entraine des retards sur les files d’attente. Les applications sensibles à ces retards, comme la voix sur IP, peuvent subir d’énormes problèmes de performances. Dans ce cas, il faudrait envisager d’implémenter un mécanisme permettant de contrôlé cette fils d’attente, par exemple une QOS, qui signifie qualité de service.

Le champ Input errors : Dépannage IPv4 : indiquent les erreurs enregistrées lors de la réception de la trame, comme les erreurs  CRC qui signifie : « contrôle de redondance cyclique » . Un nombre élevé d’erreurs CRC pourrait indiquer des problèmes de câblage, des problèmes de matériel sur les interfaces ou dans un réseau Ethernet ou bien des erreurs de correspondance entre les duplex.

• Le champ Output errors indique des erreurs de collisions, pendant la transmission d’une trame.

C’est souvent causé par un paramétrage duplex non adapté entre les deux extrémités d’une liaison Ethernet. Aujourd’hui, la plupart des liaisons Ethernet fonctionnent en mode full-duplex.

la commande « show interface » permet d’afficher le mode duplex de l’interface, afin de vérifier si la configuration est identique entre 2 extrémités d’une même liaison.

En général, pour les ports qui sont connectés à des points d’extrémités non critiques, comme des serveurs ou pc, il est recommandé d’utiliser l’autonégociation pour la vitesse et le mode duplex.

 

           Identification du chemin actuel et désiré

Lorsqu’on est sûr d’avoir éliminé les problèmes de connectivité physique, on peut passer à un dépannage plus approfondi, comme des problèmes de routage et de swithing.

 

Pour dépanner la connectivité de couche 3, on a besoin d’une bonne compréhension des processus impliqués dans le routage d’un paquet d’un hôte qui traversent plusieurs routeurs avant d’atteindre sa destination finale.

prenons comme exemple un scénario ou on ne peut pas envoyer un email via le serveur SMTP 172.16.1.100.

La commande « show IP route » permet d’afficher la table de routage sur un équipement de couche 3 comme un routeur.

lorsque l’on analyse la sortit de cette commande, il faut ce demander, quelles sont les informations que le PC1 aura besoin et quelles sont les actions à prendre pour qu’il puissent transmettre le paquet au prochain routeur. Sur cet exemple on remarque que le routeur « Branch » n’a pas d’itinéraire vers le serveur 172.16.1.100.

 

Table de routage

si on voit le sigle C pour Directly connected: c’est que l’interface du routeur est directement liée au segment de ce réseau. Si l’interface est shutdown, le routeur supprimera cette ligne de sa table de routage. La distance administrative pour ce code est de 0, ce qui signifie qu’elle sera prioritaire sur toutes les autres entrées de la table de routage.  Petit rappel,  la distance administrative la plus basse sont les sources les plus fiables.

• si c’est un L pour Local:C’est que l’IP rattaché à cette ligne correspond à l’IP de l’interface du routeur, c’est pour cela que le masque est en /32.
• le S pour Static routing:signifie qu’un administrateur réseau à entré directement et manuellement la route statique, dans la configuration du routeur. La distance administrative par défaut pour une route statique est 1. Ce qui signifie que les itinéraires statiques sont prioritaires dans la table de routage, à moins qu’il n’y ait une connexion directe à ce réseau. Les routes statiques sont une méthode efficace pour les petits réseaux simples qui ne changent pas fréquemment. Sur des réseaux plus grand et plus vaste, ce n’est pas recommandé d’avoir des routes statiques, car il est assez difficile de les gérer si le réseau change constamment.
• Pour les protocoles de routage dynamique, on a le sigle R qui est réservé pour RIP, le O pour l’OSPF et le D pour EIGRP. Le D signifie « Dual » qui est l’algorithme de mise à jour utilisé par EIGRP:
• La Default route:est une route par défaut, c’est une entrée facultative qui est utilisée lorsqu’aucun chemin vers une destination n’est trouvé dans la table de routage. On peut l’insérer manuellement, ou il peut être appris par un protocole de routage dynamique.

           Vérification de la gateway

en l’absence d’ itinéraire sur le routeur ou d’une passerelle par défaut mal configuré sur le PC, , la communication réseau entre deux-points ne fonctionnera pas.

 

Dans l’exemple, PC1 a besoin de communiqué avec le serveur. Pour que cela fonctionne, le routeur doit avoir une route de définie pour joindre le réseau 172.16.1.0 et avoir une passerelle par défaut.

 

La sortie de la commande « show IP route » sur le routeur, montre bien que la configuration est correcte, puisque la route par défaut pointe vers le prochain routeur qui porte l’IP 192.168.1.2.

sur un équipement cisco la commande pour vérifier la passerelle par défaut est « show IP route » . mais sur un PC Windows, il faut exécuter la commande « route print » .

dans l’exemple, on voit que la passerelle par défaut sur le PC est mal configurée. Pour que la communication entre le PC et le Serveur puissent se faire correctement, le PC devrait avoir comme passerelle par défaut, l’adresse IP 10.1.10.1, qui correspond à l’interface du routeur Branch.

           DNS Incorrect

La prochaine étape de dépannage consiste à déterminer s’il existe un problème de résolution de nom sur le réseau. Le DNS est le mappage des adresses IP vers des noms, et inversement des noms vers des adresses IP. Cela est très important pour les réseaux, car il est plus simple d’utiliser des noms que des adresses IP pour accéder à des ressources réseau. Par exemple, pour aller sur le site de Google, c’est plus simple de se rappeler qu’il faut taper 3w.google.fr que de taper son adresse IP 8.8.8.8.

Le mappage des noms d’ordinateur aux adresses IP peut se faire de deux façons:

• en Statique: l’administrateur système crée un fichier texte, qu’on appele le fichier hôtes, dans lequel figure chaque nom d’ordinateur avec leurs adresses IP. Et il est ensuite distribué sur le réseau. Et lorsqu’un utilisateur demande une connexion à un autre ordinateur, le système utilisera le fichier pour résoudre le nom à l’adresse IP correcte. Ce système fonctionne bien pour les réseaux simples qui ne changent pas très souvent.
• et on à en Dynamique:Le protocole DNS contrôle une base de données avec laquelle on peut mapper les noms d’hôte en adresses IP.

Il est possible que le réseau fonctionne correctement, mais que la résolution des noms échoue. Si on ne parvient pas à accéder à un site Web par son nom, on peut éventuellement l’accéder par son adresse IP.
Pour déterminer si vous rencontre bien un problème de DNS, il faut faire un ping vers la destination par son adresse IP puis par son nom.
Si le ping répond par l’adresse IP et qu’il échoue par son nom, c’est qu’il y’a bien un problème de résolution de nom.

S’il y’a un problème de mappage DNS, on peut modifier cela dans 3 endroits différents :

• dans le fichier hosts du PC:qui se trouve en général dans C: \ Windows \ System32 \ drivers et le dossier «  etc ». On peut ouvrir ce fichier avec un éditeur de texte comme le bloc note et le modifier comme on veut. Le fichier Host est plutôt  utilisé sur des réseaux de petite taille.
• on peut faire la modification dans son serveur DNS:Pour ajouter le serveur DNS dans le pool DHCP, il faut utiliser la commande « dns-server + l’IP du DNS » .
• et sur un switch ou routeur cisco en utilisant la commande :« IP host name + l’IP du DNS » . Par exemple, si on souhaite ajouter une entrée qu’on surnomme «Serveur» et qui résoudra l’adresse IP 172.16.1.100, la syntaxe serait IP host Server 172.16.1.100 .

 

Dans l’image, PC1 est configuré avec un mappage statique du nom et de l’adresse IP, puis cette résolution de nom est  vérifiée à l’aide de la commande ping .

           Trafic bloqué par ACL

après avoir testé la connectivité physique, le routage, vérifier la gateway et le DNS, s’il y’a toujours un problème, la prochaine étape consiste à aller voir du coté des accès listes, car les routeurs peuvent avoir des ACL de configurées, qui interdisent un protocole de passer l’interface dans le sens entrant ou sortant.

 

Sur l’image, PC1 est incapable d’utiliser Telnet pour se connecter au serveur.

Pour commencer à diagnostiquer, il faudra utiliser la commande « show ip access lists » pour afficher le contenu de toutes les ACL configurées sur le routeur.

ici on voit qu’il existe une ACL nommée “Outbound” qui n’accepte que le trafic ICMP. Le trafic Telnet sera bloqué par la dernière ligne implicite deny any any, qu’il y’a dans toutes les ACL’s.

Lorsque l’on découvre qu’une ACL sur un routeur bloque le trafic que l’on souhaite autoriser, on peut utiliser la commande  « show IP interface » pour déterminer où l’ACL est appliquée.

ici on voit que l’ACL qui s’appelle “Outbound” a été configurée sur l’interface GigabitEthernet0 / 1 comme ACL sortante du routeur Branch.

pour lui autorisé Telnet, il faut ajouter une entrée ACL qui autorise le protocole Telnet et le son port 23, comme pour l’ICMP.

après cela, la communication Telnet entre le PC1 et le serveur devrait en principe fonctionner.

SPAN Sniffer de Trafic

SPAN, plus connu sous le nom de «Port mirroring »  à été créer à cause de la différence entre les hubs et les switchs. Quand un hub reçoit un paquet sur un port, il transfère une copie du paquet à tous les ports excepté le port source. Tandis que Le switch, quant à lui, envoie les paquets qui sont destinés à une adresse MAC précise sur un port spécifique, il utilise pour cela sa table de correspondance de niveau 2, qu’il remplit avec les adresses MAC des équipements directement connectés.

Le SPAN nous aide à capturer du trafic sur un switch, en écoutant avec un sniffer, comme si nous étions sur un Hub. Car si on branche seulement un sniffer sur un switch, on ne verra passer aucun trafic qui ne nous est pas directement envoyé. On ne recevra que les flux Broadcast, multicast, et les unicast inconnus, c’est-à-dire les trames flooder sur tous les ports.

La fonction SPAN permet d’analyser tout le trafic réseau passant par un port du switch et envoie une copie du trafic vers un autre port qui aura été connecté avec analyseur de réseau comme Wireshark par exemple.

Sur l’image, si on souhaite analyser le trafic qui passe de PC1 à PC2, il faudra spécifier un port source avec la commande « monitor session » + un chiffre pour l’identifier, suivi de « source interface » et de l’interface qu’on souhaite analyser.

Dans cet exemple, il est possible de configurer l’interface Ethernet0 / 1 pour capturer le trafic d’entrée ou bien l’interface Ethernet0 / 2 pour capturer le trafic de sortie. Ensuite, il faudra spécifiez  l’interface Ethernet0 / 3 comme port de destination avec à peu près la même commande sauf qu’il faut spécifier que c’est pour la destination. Et comme ça, tout le trafic qui passe de PC1 à PC2 sera copié sur l’interface Ethernet 0/3. Il restera plus qu’a l’analyser les données avec un sniffer de trafic comme wireshark.

Il est possible de spécifier le trafic que l’on souhaite surveiller sur l’interface source avec les mots clés RX et TX. RX pour uniquement le trafic reçu et TX pour seulement le trafic transmis. Ou bien les deux avec la combinaison de RX et TX.  Par défaut, si on ne spécifiez rien, c’est les deux sens qui sont transmis.

la commande show monitor permet de vérifier la configuration du SPAN.