[et_pb_section fb_built="1" admin_label="section" _builder_version="3.22.3"][et_pb_row admin_label="row" _builder_version="3.22.3" background_size="initial" background_position="top_left" background_repeat="repeat"][et_pb_column type="4_4" _builder_version="3.0.47"][et_pb_text admin_label="Text" _builder_version="3.0.74" background_size="initial" background_position="top_left" background_repeat="repeat"]
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.
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 :
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.
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.
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.
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.
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:
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 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 .
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, 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.
[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]
Visitez notre Politique de Confidentialité
Prenez connaissance de notre Charte de Qualité |
CGU | CGV | Engagement de non-responsabilité
Vous avez une réclamation à nous soumettre ? => Remplissez le formulaire
Vos informations sont 100% sécurisées, nous nous engageons à ne pas les revendre.
Siège social : 34 rue Pasteur, 39110 Salins-les-bains.
SIRET. 890 495 294 00013 ⎜Numero DATA DOCK:0085 282 ⎜Déclaration d’activité enregistré auprès du préfet de region Bourgogne-Franche-Comté sous le numéro : 27390126739
© Copyright 2017 - Formip par Damien.S