Quatrième article dédié au Troubleshooting de niveau 3.
Comme précédemment, le but ici est de rechercher des erreurs de configuration.
Le travail est concentré sur le niveau 3.
Hormis pour la partie L3 sur DSW1 et DSSW2, les switchs seront ignorés.
1) Topologie et scénario
La topologie reste inchangée par rapport aux autres articles.
Le scénario est le suivant.
Le client 1 n’arrive plus à joindre le serveur WEB.
En revanche, le serveur FTP peut joindre le serveur WEB
De plus, l’outil de supervision du réseau met en évidence un autre problème.
Il semblerait que le lien DSW1 – R4 ne soit pas utilisé.
En revanche, le lien DSW2 – R4 est fortement chargé.
2) Troubleshooting – Partie 1
Commençons le problème de connectivité entre le Client 1 et le serveur Web.
Essayons de joindre le serveur Web depuis le Client 1.
Cela ne passe pas.
Essayons depuis le serveur FTP.
Effectivement, la connexion fonctionne.
Le message d’erreur du Client 1 n’indique pas que la passerelle n’a pas de route.
Le problème doit se situer plus loin.
Commençons tout de même les investigations sur le Client.
Voyons sa configuration IP, et sa connectivité avec sa passerelle.
Le Client 1 n’a pas de problème pour joindre sa passerelle.
Allons voir les routes sur celle-ci.
DSW1 possède une route par défaut qui pointe vers R4.
Il peut aussi être bon de voir si des ACL ont été mises en place.
Sinon, jeter un coup d’œil à toute la configuration peut aussi être bon.
Bref, allons voir sur R4.
R4 possède aussi une route par défaut.
Elle pointe vers R3.
Les autres routes présentes sont correctes.
Il n’y a pas d’ACL.
Allons voir R3.
Le constat est le même.
La route par défaut pointe vers R2.
Il n’y a pas non-plus d’ACL.
Allons voir R2.
De même que pour les autres routeurs.
La route pointe vers R1.
Il n’y a pas non-plus d’ACL.
Allons voir R1.
Enfin, nous trouvons quelque chose.
R1 ne possédant pas de route adéquate pour le retour, nous pourrions dire que c’est pour cela que le Client 1 ne peut pas joindre le serveur WEB.
Mais cela n’explique pas pourquoi le Serveur FTP peut le joindre.
Faisons un Tracert depuis le Serveur FTP pour voir par où il passe.
Les paquets passent bien par les différents routeurs.
Il s’agit bien de la route escomptée.
Au passage, un tracert sur le Client 1 aurait permis de gagner du temps.
Nous aurions pu commencer le TSHOOT sur R2.
Bref, revenons-en à la table de routage de R1.
Elle ne comporte aucune route vers 172.17.0.0 /24.
Pourtant, le Serveur FTP parvient à joindre le serveur WEB.
Aucun lien n’a été ajouté, donc les paquets passent forcément part R1.
Il faut savoir qu’il n’y a pas que la table de routage qui permet de faire du routage.
Une Route Map le permet aussi.
Habituellement les Route Map sont utilisées pour influencer le routage.
Voyons si R1 en possède.
Il possède 2 Routes Map.
La deuxième est clairement utilisée pour la redistribution BGP.
La première peut très bien être utilisée pour le routage.
Le mieux ici est d’extraire les portions de configurations relatives à cette Route Map.
Les voici :
En analysant cette Route Map, le comportement du réseau s’explique.
C’est cette Route MAP qui assure la quasi-totalité du routage sur R1.
Dans l’état actuel, elle permet de router les paquets allant du Serveur Web vers les réseaux internes (Client 1 et Serveur FTP).
Sauf que, l’ACL utilisée n’a pas d’entrée pour 10.2.1.0 /24 (Client 1).
Ce qui explique pourquoi seul le Client 1 a des problèmes pour joindre le Serveur WEB.
Essayons de corriger cela.
no ip access-list extended InternalNetwork ip access-list extended InternalNetwork permit ip any 192.168.11.128 0.0.0.127 permit ip any 10.2.1.0 0.0.0.255 permit ip any 10.2.2.0 0.0.0.255 permit ip any 10.1.4.4 0.0.0.3 permit ip any 10.1.4.8 0.0.0.3 permit ip any 10.1.1.8 0.0.0.3
Voyons le résultat.
La Route Map était donc bien le problème.
Moralité, toujours vérifier la présence de Route Map sur un routeur.
3) Troubleshooting – Partie 2
Attaquons le deuxième problème.
L’outil de supervisions nous indique que le lien DSW1 – R4 n’est que très peu sollicité, alors que le lien DSW2 – R4 est très chargé.
Il y a donc un problème de répartition de charge.
DSW1 et DSW2 devraient normalement jouer le rôle de Gateway.
Vérifions cela.
Les IP des interfaces Vlan 10 et 20 ne correspondent pas aux IP de passerelle du Client 1 et du Serveur FTP.
D’après la topologie et l’adressage IP, c’est impossible que ce soit R4.
Ce ne peux pas non-plus être ASW1 ou ASW2, car ce ne sont que des switchs de niveau 2.
Il y a un autre moyen de vérifier qui se cache dernière les IP de passerelle.
Il suffit d’initier une session Telnet vers ces IP.
Allons voir en détail la configuration des interfaces.
Il y a donc une configuration HSRP.
Cela explique les IP de passerelle.
Voyons donc l’état HSRP.
En mettant en évidence les points importants, le problème saute aux yeux.
Pour le VLAN 10, DSW1 devrait être la passerelle Active, car il a la priorité à 150 (contre 100 pour DSW2).
Sauf qu’à un moment, DSW2 a dû passer en Active, probablement suite à une panne de DSW1.
Comme le mode Preemte n’est pas activé, DSW1 n’a jamais repris son rôle.
La correction est alors très simple.
DSW1(config)#interface vlan 10 DSW1(config-if)#standby 1 preempt
Tout de suite, DSW1 redevient Active.
Les deux problèmes sont donc résolus.
Laisser un commentaire