EIGRP TP No 3 : Stuck In Active

Avant de finir cette série sur l’EIGRP, voyons une dernière notion.

Nous allons parler d’un problème nommé Stuck In Active.

Ce problème peut survenir lors de l’envoi de Query.

Nous aborderons deux solutions. La Summarization de route, et les routeurs Stub.

Ces deux solutions ont pour avantage de réduire les risques de Stuck In Active, mais aussi de réduire l’utilisation de ressources (CPU, RAM, réseau)

 

1)    Explication et configuration

 

1.1) Stuck In Active

Dans certains cas, un routeur EIGRP peut se retrouver dans un état appelé SIA – Stuck In Active.

Mais qu’est-ce donc ?

Nous en avions parlé dans un précédent article.

Vous souvenez vous de ce qu’il se passe quand un routeur perd son Successor pour une destination, et qu’il n’a pas de Feasible Successor ?

Il envoie alors des Query à tous ses voisins, en leur demandant s’ils connaissent une route pour le réseau en question.

Prenons l’exemple suivant :

Ceci pourrait être le réseau d’une entreprise.

Le QG est à Paris, et 3 autres bureaux sont répartis dans la France.

Entre les bureaux, des liaisons ont été établies (VPN, Frame Relay, etc…).

Dans ce cas-ci, les liaisons sont lentes et peu fiables. Elles ont donc été redondées.

Chaque routeur possède des interfaces dans les réseaux indiqués.

 

Imaginons que R1 perde son lien vers 10.1.0.0 /24. De plus, il n’avait pas de Feasible Successor.

Il envoie alors des Query vers R2, R3, R4 et R5, en leur demandant un chemin de secours pour 10.1.0.0 /24.

R1 étant le seul lien vers 10.1.0.0 /24, aucun des routeurs ne sera capable de fournir un chemin de secours.

Et que fait un routeur quand il ne peut pas répondre à une Query ? Il la transmet à ses voisins.

Les requêtes de Query vont donc tourner en rond sur le réseau.

 

R1 va donc attendre des réponses, qui ne viendront jamais.

On dit alors que le routeur est en « Stuck In Active » (ou plutôt la route pour cette destination).

Une route est dite active quand le routeur cherche un autre chemin (qu’il envoie des Query pour cette destination).

Le routeur est donc coincé dans ce mode « Active » pour la route vers 10.1.0.0 /24

Et même si l’un des routeurs venait à fournir une route de secours à R1, ce dernier attendrait quand même une réponse de tous les autres voisins.

En bref, R1 a peu de chance de sortir du mode Stuck In Active.

Va-t-il y rester indéfiniment ?

Heureusement non. Après 3 minutes, s’il n’a pas reçu toutes les réponses à ses Query, il va réinitialiser les connexions avec les voisins n’ayant pas répondu.

Dans notre exemple, R1 va réinitialiser ses connexions avec R2, R3, R4, R5.

 

Bien entendu, les connexions avec les voisins vont revenir, mais cela aura tout de même causé une interruption de service.

 

Pour faire simple :

–          R1 perd son lien vers 10.1.0.0 /24

–          Il envoie des Query vers R2, R3, R4, R5

–          Les Query tournent en rond, personne ne répond

–          Au bout de 3 minutes, R1 réinitialise les connexions vers R2, R3, R4, R5

Au final, la perte du lien vers 10.1.0.0 /24 a perturbé tout le réseau.

 

Il s’agit d’un exemple. Il peut y avoir d’autres raisons pour que les voisins ne répondent pas au Query.

 

1.2) Solutions No 1 : Summarization

Maintenant que nous avons mis en évidence le problème, parlons des solutions.

La première est simple et déjà connue.

Il s’agit de mettre en place de la Summarization de route.

Par exemple, R1 devra annoncer une route résumée pour 10.1.0.0 /22.

R1(config)#interface serial 0/0
R1(config-if)#ip summary-address eigrp 90 10.1.0.0 255.255.252.0

A faire sur toutes les interfaces voulues

 

Et en quoi cela nous aide ?

Quand un routeur reçoit un Query pour un réseau, depuis un routeur qui lui a annoncé une route résumée incluant ce réseau, il va répondre à la Query en disant qu’il n’a pas de lien pour la destination voulue.

 

Vous suivez toujours ?

Prenons un exemple :

Nous mettons en place de la Summarization.

R1 n’annonce plus 10.1.0.0, 10.1.1.0, 10.1.2.0 et 10.1.3.0 /24

Il annonce simplement 10.1.0.0 /22.

R3 retient donc que pour le réseau 10.1.0.0 /22, il faut joindre R1.

Si maintenant R1 perd son lien vers 10.1.0.0 /24, il va envoyer des Query à tout le monde, y compris R3.

Ce dernier va répondre négativement à la Query, car R1 lui a annoncé une route résumée, laquelle inclue 10.1.0.0 /24.

En bref, un routeur qui annonce des routes résumées obtiendra toujours une réponse négative à une Query vers une route inclue dans le résumé.

De plus, la réponse négative est envoyée immédiatement.

 

Donc, si nous mettons en place de la Summarization sur tout le réseau, le Stuck In Active ne devrait plus être une menace.

En plus, nous réduisons l’utilisation de ressource, car les routes sont résumées.

Bien entendu, il n’est pas toujours possible de mettre en place de la Summarization partout.

 

1.3) Solutions No 2 : Stub Routeur

Un routeur Stub est un routeur en bout de réseau.

A quoi sert un routeur Stub :

–          Il ne permet que de joindre les réseaux qui lui sont directement connectés (10.3.0.0 /22 pour R3)

–          Aucune Query ne lui est envoyée

Cela empêche donc que le routeur Stub soit utilisé comme point de transit.

En effet, dans notre exemple, nous ne voulons pas que R3 (ou R4 et R5) ne servent de point de transit entre R1 et R2.

 

De plus, nous réduisons les chances de Stuck In Active.

Reprenons l’exemple précédent : R1 perd son lien vers 10.1.0.0 /24.

Il n’enverra pas de Query vers R3, car il sait que c’est un Stub. En allant vers R3, impossible de joindre autre chose que ce qu’il annonce (en l’occurrence 10.3.0.0 /22).

 

Voyons la configuration d’un stub :

La commande « eigrp stub » permet de choisir une ou plusieurs options :

–          Connected : les réseaux directement connectés sont annoncés

–          Leak-map : annonce les routes en se basant sur la Leak-map (non traitée en CCNP)

–          Recive-only : le routeur n’envoie pas de MAJ de routage (mais peut en recevoir)

–          Redistributed : annonce les routes redistribuées

–          Static : annonce les routes statiques

–          Summary : annonce les routes résumées

–          <cr> : mode par défaut, utilise Connected et Summary

 

Dans notre exemple, R3, R4 et R5 doivent être configurés en Stub.

 

Le Stub a donc plusieurs avantages :

–          Seul du trafic destiné au routeur lui est envoyé (ne sert pas de point de transit)

–          Pas de Query envoyée au Stub (donc moins de risque de SIA)