Le protocole EIGRP : Stuck in Active

Stuck in Active = coincé en actif.

• Actif = Lien mort.
• Passif = Lien fonctionnel.

On retrouve ces états dans la Table Topologique EIGRP !

Pour voir tout ça, on va prendre des exemples concrets 🙂

Stuck in Active EIGRP : Mise en situation

• R-00, R1, R11, R12, R21, R22, R23 et R24 sont tous bien configurés, fonctionnent parfaitement et utilisent le protocole EIGRP.
• Le seul LAN qui existe est le lan X.X.X.X (on ignore les réseaux d’interconnections).
• Le routeur R1 ne possède qu’un seul Successor pour joindre le réseau X.X.X.X.

Voici la table topologique de R1.

P = Passive = Information toujours valide.

Stuck in Active EIGRP : Réaction en cas de panne

La panne :

• Le lien entre R-00 et R1 tombe et R-00 n’est plus le Neighoor de R1.
• R1 passe le réseau X.X.X.X en mode Active.

A = Active = injoignable.

Que va faire R1 pour remédier à ce problème ?

• R1 envoie un paquet QUERY à tous ces neighbor sauf à son ancien Successor.
• R1 lance un Timer de 3 minutes, s’il ne reçoit pas de paquet Reply d’un Neighoor, il le mettra dans le stade “STUCK IN ACTIVE“.

• R11 et R12 reçoivent un paquet Query de R1.
• R11 envoie un paquet Query à R21 et R22.
• R12 envoie un paquet Query à R23 et R24.
• R11 et R12 lancent un Timer de 3 minutes.

R21, R22, R23 et R24

• Reçoivent un paquet Query.
• Ne possèdent pas d’autres Neighboor.
• Répondent au paquet Query avec un paquet Reply.

• R11 et R12 ont reçu une réponse à tous leurs paquets Query.
• R11 et R12 répondent au paquet Query de R1 avec un paquet Reply.

Vu que personne ne sait comment joindre ce réseau, tout le monde a mis un Metric infini dans leurs Reply.

R1 en conclut que ce réseau n’est plus du tout joignable et le supprime de sa table topologique et donc de sa table de routage.

Stuck in Active EIGRP : si R1 ne reçoit pas de Reply

Pourquoi :

• R1 est trop occupé.
• Problème de lien.
• Liaison unidirectionnelle via fibre optique. ( voir l’article sur l’UDLD ).

Ce qui se passe :

• R1 supprime R12 de ses neighboors.

Tout ça parce que R1 n’a pas traité la réponse de R12 ?
C’est n’importe quoi !

Cisco à réagit depuis l’IOS 12.1 et à créer les paquets SIA-Query et SIA-Reply.

Stuck in Active EIGRP : SIA-Query et SIA-Reply

Nous sommes dans la même situation, R1 attend le Reply de R12 …

Au bout d’1 minute et 30 secondes, R1 commence à s’inquiéter et décide d’envoyer un SIA-Query à R12.

R12 répond avec un SIA-Reply, R1 est content, il n’a toujours pas l’information demandé mais il ne vas pas supprimer R12 de sa table de Neighboor.

Stuck in Active EIGRP : Conclusion

On se fait une petite image :

• R1 = Professeur CM1.
• Les autres routeurs = Élèves de CM1.

Le professeur aimerait connaitre le numéro de téléphone de la principale de l’école, car il l’a perdu et demande à sa classe de CM1 de demander à tous leurs amis de l’école si quelqu’un connaît ce numéro de téléphone… Cela ne va servir à rien, car les élèves ne connaissent que le numéro de téléphone de leurs parents. Bah là, on va dire à chaque élève de l’école que si quelqu’un leurs demandes un numéro de téléphone en dehors du numéro de leurs parents de répondre :

• Je ne connais pas d’autres numéros et mes copains pareils.

Avantage :

• Pas de brouhaha inutile dans la cour de récréation.
• Le Professeur sait directement qu’il n’obtiendra pas cette information de ses élèves.

Afin de dire à un routeur d’annoncer uniquement les réseaux qu’on lui autorise et de ne pas lancer des paquets Query inutiles, nous allons le configurer en mode STUB.