A travers cet article, nous allons voir un quatrième cas de Troubleshooting sur une topologie complète.
Dans cette topologie, un problème s’est glissé.
Celui-ci peut être à n’importe quel niveau (routeur, switch, PC, etc…).
Il faudra donc adopter la bonne approche, pour trouver le problème rapidement.
1) Scénario et topologie
Il y a quelques temps, il a été décidé de mettre en place un lien de secours entre R5 et R2.
En effet, il arrive que le lien R5 – R1 soit instable.
Le lien de secours est en train d’être monté.
L’un de vos collègues a partiellement modifié les configurations pour supporter ce lien.
Malheureusement, vous venez de voir qu’il y a des problèmes de connectivité pour joindre le Web Serveur.
Etant actuellement le seul présent, vous cherchez seul la solution au problème.
Voici la topologie à votre disposition.
Le lien de secours n’est pas encore en place.
L’accès à internet est simulé par un accès à WEB Serveur
2) TSHOOT
Pour être sûr, vérifions que WEB Serveur n’est plus joignable.
Depuis Client 1 :
Peut-il encore joindre R1 ?
Oui.
Et R5 ?
Non.
Le Client 1 peut donc joindre R1, mais pas R5.
Voyons si R1 peut joindre R5.
Oui.
R5 est donc toujours UP.
Peut-il joindre WEB Serveur avec une IP qui n’est pas d’un réseau directement connecté à R5 ?
Non.
Il y a donc probablement un problème de routage, ou bien une ACL qui bloque le trafic.
Vu le scénario, la première option est la plus plausible.
Consultons la table de routage de R1 :
Elle comporte une route par défaut pointant vers R5.
A première vue, il n’y a pas de problème de routage.
Assurons-nous qu’il n’y a pas d’ACL qui bloque le trafic.
Non, rien ne bloque le trafic.
Allons voir du côté de R5.
Voici donc l’origine du problème.
R5 ne possède pas les bonnes routes.
Voyons sa configuration de routage.
Il n’y a pas de configuration de routage, mais il y a un objet de tracking.
Cela doit faire partie de la configuration pour le lien de secours.
Voici les autres parties de la configuration qui s’y rapportent.
Résumons.
Nous avons une Route Map qui route le trafic.
Elle peut router le trafic vers deux Next-Hop.
Pour savoir si elle doit router le trafic au Next-Hop principal (donc pas le lien de secours), elle vérifie sa disponibilité.
Sinon, c’est le lien de secours qui est utilisé.
Maintenant analysons bien cette configuration.
La structure semble bonne.
Il y a tous les éléments nécessaires (Route Map, Tracking, ACL, application de la Route Map).
En revanche, sur le contenu, il y a une erreur.
Si R1 (172.16.0.1) est disponible, R5 envoie le trafic vers 172.16.0.11.
Or, 172.16.0.11 ne correspond à rien.
La bonne IP devrait être 172.16.0.1.
Corrigeons cela.
route-map DG_TRAFFIC permit 10
no set ip next-hop verify-availability 172.16.0.11 10 track 1
set ip next-hop verify-availability 172.16.0.1 10 track 1
Voyons si le problème est résolu.
Toujours pas.
Vérifions l’état du Tracking.
Il est Down.
Donc actuellement, le trafic est redirigé vers 172.18.0.1, qui n’existe pas.
Dans la configuration, il y a un autre élément susceptible de poser problème.
Il s’agit du Start Time du SLA Monitor.
La date de début a été fixée en dur au 23 Octobre.
Vérifions que la date soit déjà passée.
Pire que cela, la date n’a pas été configurée.
Corrigeons cela.
R5#clock set 15:00:00 23 oct 2014
Forçons aussi le Tracking à commencer tout de suite.
R5(config)#ip sla monitor schedule 1
R5(config)#ip sla monitor schedule 1 start-time now life forever
Le problème est-il résolu ?
Il semblerait.
Testons depuis Client 1.
Il peut à nouveau joindre WEB Serveur.
Pour résumé, tout le routage est bon de Client 1 à R1.
R1 utilise une route par défaut pour joindre R5 et ses réseaux.
Quant à R5, il utilise une Route Map et du Tracking pour diriger le trafic.
Si R1 est joignable, il l’utilise pour router le trafic.
Sinon, il envoie le trafic à 172.18.0.1, qui n’est pas encore en place.
Pour finir, vérifions si R2 possède déjà sa configuration du même type.
Non, pour le moment il n’a pas été configuré.
’accès à internet est simulé par un accès à WEB Serveur
