TSHOOT – Niveau 3 – Ticket 1

Dans ce premier article dédié au troubleshooting de niveau 3, nous nous concentrerons sur la partie routeur de la topologie.

Le but sera de trouver les erreurs de configuration au niveau 3.

Hormis pour la partie L3 sur DSW1 et DSSW2, les switchs seront ignorés.

 

1) Scénario et topologie

 

La topologie reste la même que dans les autres articles de TSHOOT.

 

J’ai choisi de laisser visibles les adresses IP et les noms d’interface.

Dans un cas réel, si vous ne les connaissez pas, le mieux est d’utiliser les commandes suivantes :

• Show ip interface brief
• Show cdp neighbors
• Show run (puis voir les descriptions dans la partie interface)

 

Ici le scénario sera simple.

Le Client 1 n’arrive plus à joindre le serveur WEB.

Il semble que les configurations aient été modifiées.

 

2) Troubleshooting – Partie 1

 

Comme toujours, la première étape est de constater le problème.

Effectivement, le PC ne peut par joindre le serveur WEB.

Vérifions la configuration IP.

Vérifions la passerelle.

L’adressage IP est correct.

L’article étant basé sur le TSHOOT de niveau 3, nous ne nous attarderons pas sur la configuration des switchs.

La méthode d’approche utilisée sera Divide And Conquer, car nous savons que le problème est au niveau 3.

 

Vérifions la table de routage de DSW1.

Premièrement, nous n’avons pas le réseau 172.17.0..0 /24, le réseau du serveur.

Deuxièmement, à part 10.1.1.8/30 et 10.1.4.8 /30, nous n’avons que les réseaux auxquels DSW1 est connecté.

Il semble qu’il y a un problème d’échange de route.

Nous pouvons aussi noter que le routeur utilise EIGRP (grâce au code D).

 

Consultons R4.

R4 ne possède pas plus de route.

Nous utilisons ici la méthode Follow The Path, car nous suivons le chemin des paquets, tout en vérifiant les tables de routage.

Voyons R3.

Il possède une route par défaut, à priori utilisée pour l’accès internet et autre.

Par contre, il ne possède pas les réseaux 192.168.11.0 /24, 10.2.1.0 /24, etc…

 

Il doit y avoir un problème d’échange de route.

Nous pouvons voir que R3 utilise OSPF.

Vérifions les relations OSPF.

Les relations ne sont pas bonnes.

Au passage, nous pouvons vérifier celles d’EIGRP.

Les relations entre R4 et DSW1 – DSW2 sont bonnes.

 

Bref, il y a un problème de relation OSPF entre R3 et R4.

 

Le mieux dans ce genre de cas est de comparer les configurations (méthode Spot The Diffrences).

Pour R3 et R4 les commandes Network sont bonnes.

Elles ont été entrées directement avec les IP des interfaces.

Nous pouvons voir que R4 redistribue les routes EIGRP qu’il possède.

 

Par contre il y a un problème au niveau des types de zones.

La zone entre R3 et R4 est la zone 34.

 

R3 est en mode Totally Stubby Not So Stubby Area.

Pour rappel, une zone TSNSSA est une zone qui ne laisse pas circuler les LSA de type 3, 4 et 5 (une Totaly Stubby Area) mais qui autorise la présence d’un ASBR dans la zone.

Pour plus de détails, je vous invite à consulter l’article sur les zones.

http://www.networklab.fr/les-differents-types-de-zones-ospf/

 

Donc R3 remplacera toutes les routes externes à l’area 34 par une route par défaut. Mais il autorisera un ASBR à redistribuer ses routes.

 

R4 quant à lui est en mode Stub. Cela veut dire qu’il ne laisse pas circuler les LSA de type 4 et 5.

 

Il y a donc ici un problème de configuration de zone.

 

Pour créer une TSNSSA, il faut que R3 garde sa configuration, mais que R4 change la sienne.

 

Voici la bonne configuration.

R4(config-router)#no area 34 stub
R4(config-router)#area 34 nssa

 

Pour de plus amples explications, référez-vous à l’article associé.

http://www.networklab.fr/configuration-des-differents-types-de-zones-ospf/

 

Dans les logs de la console nous pouvons voir la relation R3 – R4 monter.

Vérifions les tables de routage.

Nous pouvons voir que R4 a récupéré la route par défaut.

Quant à R3, il a maintenant les routes venant d’EIGRP.

 

A présent, R4 n’a toujours pas de route pour 172.17.0.0 /24, mais il a une route par défaut.

De même pour R3.

Les deux possèdent des routes pour 10.2.1.0 /24 pour le retour.

 

Testons un Ping pour voir si le problème est résolu.

Le client peut joindre le serveur.

 

Pour le moment le problème semble résolu.

 

3) Troubleshooting – Partie 2

 

Quelques temps après, des clients se plaignent de problème d’accès au réseau de management des switchs (192.168.11.128 /27).

Par exemple, il n’est pas possible de joindre les switchs depuis le serveur WEB.

(Dans un cas réelle cela serait une bonne chose, mais laissons la sécurité de côté pour nous concentrer sur le TSHOOT).

R4 et R3 possèdent la route pour 192.168.11.0 /27.

 

Allons voir R2.

Pour R2 tout est OK.

 

Voyons R1.

A première vue tout semble OK.

 

Nous avons une route pour 172.17.0.0 /24, une pour 192.168.11.0 /24 et la route de retour.

 

Mais il faut faire attention.

La route par défaut comporte une erreur.

Elle pointe vers 10.1.1.2, c’est-à-dire R2.

 

Nous risquons donc une boucle de routage.

 

Le code S pour la route par défaut indique que c’est une route statique configurée sur R1.

 

Changeons-la.

R1(config)#no ip route 0.0.0.0 0.0.0.0 10.1.1.2
R1(config)#ip route 0.0.0.0 0.0.0.0 172.16.0.2

 

A présent nous avons une vraie route par défaut.

 

Finissons par voir R5.

Il n’a pas de route pour 192.168.11.128 /29.

Pour qu’il y ai cette route il y a plusieurs solution.

Vue les routes qu’il y a déjà dans la table, 192.168.11.0 /24 devrait être redistribuée.

 

Voyons sur R1.

Dans la configuration de la redistribution, il manque l’autorisation pour redistribuer 192.168.11.0 /29

 

Ajoutons-la :

R1(config)#ip access-list standard OSPFRedistributeToBGP
R1(config-std-nacl)#permit 192.168.11.0 0.0.0.255

Cela ne semble pas résoudre le problème.

Il n’y a toujours pas de route pour 192.168.11.128 /27.

 

Avant de chercher plus loin, réinitialisons la relation BGP R1 – R5.

 

R1#clear ip bgp *

 

BGP étant un protocole lent, il faut attendre avant que la table de routage de R5 se remplisse.

Parfait, la route est là.

 

Finissons par tester :