Cisco 300-410: Conception, métriques et convergence EIGRP — Guide d'étude

By Laurynas Brazys · 16 August 2026 · #cisco #300-410 #certification #exam-prep #study-guide

Fait partie du Cisco CCNP Enterprise 300-410 ENARSI — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Cisco, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Le protocole EIGRP (Enhanced Interior Gateway Routing Protocol) est un protocole de routage à vecteur de distance, sans boucle et à convergence rapide, qui utilise l’algorithme DUAL (Diffusing Update Algorithm) pour calculer des chemins de secours et éviter les boucles transitoires. Les choix de conception concernant les métriques, la sélection des chemins, le confinement des requêtes, la sumarisation, la formation des voisins, l’authentification et la redistribution influencent directement la stabilité et le temps de convergence. Cette section décrit comment concevoir, configurer et dépanner EIGRP pour un comportement déterministe dans les déploiements IPv4 et IPv6.

Fonctionnement de DUAL et sélection des chemins

EIGRP utilise DUAL pour maintenir une topologie sans boucle et accélérer la convergence.

• Successeur (Successor) : Le saut suivant principal pour une destination. Installé dans la table de routage.
• Feasible Distance (FD) : La meilleure métrique connue depuis le routeur local vers une destination (via le successeur).
• Reported Distance (RD) : La métrique vers la destination rapportée par un voisin (aussi appelée distance annoncée).
• Feasible Successor (FS) : Un saut suivant de secours garanti sans boucle par la condition de faisabilité (Feasibility Condition - FC).

Condition de faisabilité : Un voisin se qualifie comme Feasible Successor si sa RD vers la destination est strictement inférieure à la FD locale vers cette destination via le successeur actuel : RDvoisin < FDlocale. Cela garantit que le voisin est plus proche de la destination que le routeur local, empêchant les boucles sans nécessiter un calcul SPF complet.

Résultats comportementaux :

• Si une destination perd son successeur et qu’au moins un FS existe, le routeur effectue une bascule locale immédiate sans requêtes, offrant une convergence inférieure à la seconde sur les liens à vitesse LAN.
• S’il n’existe aucun FS, la destination passe à l’état Actif et le routeur envoie des requêtes (queries) aux voisins pour trouver un remplaçant. La conception de la portée des requêtes devient alors essentielle pour éviter les retards.

Répartition de charge sur des chemins de coûts inégaux avec la variance :

• EIGRP installe plusieurs chemins lorsque la variance est configurée et que ces chemins sont des FS. Un chemin est éligible si sa FD ≤ (variance × FD du meilleur successeur). Seuls les FS peuvent être installés pour le partage de trafic ; les chemins de coût égal qui ne sont pas des FS ne sont pas utilisés pour éviter les boucles.
• Le partage de trafic peut être équilibré (par défaut, proportionnel à l’inverse des métriques) ou minimisé avec traffic-share min across-interfaces.

Exemple :

undefined

undefined

undefined

Note de conception : Si plusieurs liens existent mais ne remplissent pas la FC, envisagez d’ajuster le délai (delay) de l’interface (et non la bande passante) pour influencer les relations FD/RD. Ne modifiez pas les valeurs K à cette fin.

Modèles de configuration, formation des voisins et authentification

EIGRP prend en charge les modèles de configuration classique et nommé.

EIGRP classique (IPv4) :

undefined

undefined

undefined

• La sumarisation et l’authentification par interface sont configurées au niveau de l’interface.

EIGRP nommé (consolide IPv4/IPv6 et centralise la politique) :

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

Découverte des voisins :

• Temporisateurs Hello/Hold : par défaut 5/15 secondes sur les liens à haut débit, 60/180 sur les liens à faible débit. Les temporisateurs n’ont pas besoin de correspondre ; le hold time accepté est celui que le voisin annonce.
• Destinations multicast : 224.0.0.10 (IPv4) et FF02::A (IPv6).
• L’interface passive (passive-interface) supprime les hellos ; à utiliser sur les ports côté accès ou là où aucune adjacence ne doit se former.

Authentification :

• Authentification MD5/HMAC-SHA par interface en mode classique :

undefined

undefined

undefined

• En mode nommé, appliquez l’authentification sous af-interface. Tous les voisins sur un segment doivent partager l’algorithme et les clés ; des non-concordances empêchent l’adjacence.

Routage Stub :

• À configurer uniquement sur le routeur stub lui-même ; les voisins apprennent la capacité stub et suppriment les requêtes non essentielles.

undefined

undefined

Les options stub par défaut annoncent les routes connectées et sumarizées. Ajoutez les routes statiques ou redistribuées selon les besoins.

EIGRP pour IPv6 :

• Nécessite un Router ID de 32 bits et une activation par interface.

undefined

undefined

undefined

undefined

undefined

undefined

undefined

Métriques : composite et étendue, valeurs K et compatibilité

Métrique composite (classique) :

• Valeurs K par défaut : K1=1 (bande passante), K3=1 (délai), K2=K4=K5=0. Métrique effective = 256 × (inverse de la bande passante minimale du lien + délai cumulé). La charge et la fiabilité sont ignorées par défaut.
• Ne modifiez pas les valeurs K dans les conceptions en production ; tous les voisins doivent avoir des valeurs K exactement identiques, sinon les adjacences échouent.

Métrique étendue (Wide metrics) :

• La métrique étendue augmente l’échelle et la précision de la métrique (notamment pour les liens à très haute bande passante/faible délai) et ajoute une marge pour les fonctionnalités TE. Tous les voisins doivent prendre en charge et négocier la même version de métrique EIGRP. Des versions de métrique ou des valeurs K non concordantes empêchent l’adjacence.
• Bonnes pratiques pour la manipulation des métriques :
  • Préférez modifier le délai (delay) de l’interface pour influencer la préférence de chemin ; il est additif et déterministe.
  • Évitez de définir une bande passante irréaliste ; cela affecte également la QoS et d’autres sous-systèmes.
  • Utilisez default-metric ou des métriques explicites pour la redistribution afin d’assurer une sélection de chemin prévisible.

Métriques de redistribution :

undefined

undefined

undefined

Convergence, requêtes, résumé et limites des requêtes

Requêtes et Stuck-in-Active (SIA) :

• Lorsqu’aucun FS (Feasible Successor) n’existe, les routes passent à l’état Actif et le routeur envoie des requêtes à tous les voisins, sauf à ceux qui sont des stubs ou qui ont des limites de résumé. Chaque voisin interrogé doit répondre avant l’expiration du active-time (3 minutes par défaut). L’échec de la réception de toutes les réponses provoque un état SIA ; le voisin peut être réinitialisé et la route purgée.
• Les améliorations EIGRP SIA-Query/SIA-Reply détectent plus tôt les voisins qui répondent lentement, mais une bonne conception reste la principale mesure d’atténuation.

Stratégies de confinement des requêtes :

• Résumé (Summarization) : Créez des agrégats au niveau des limites de distribution ou de type ABR pour empêcher les requêtes de les traverser. EIGRP installe une route de rejet locale Null0 pour le résumé (distance administrative de 5) avec une métrique égale à la meilleure route composante. Cela permet à la fois de réduire la portée des requêtes et de se protéger contre les trous noirs (blackholing) lorsque des routes spécifiques sont manquantes.
• Routage stub : Configurez sur les sites spoke ou leaf pour arrêter les requêtes de transit à travers des équipements aux capacités limitées.
• Filtrage : Limitez la propagation des routes inutiles et réduisez l’empreinte de la topologie.

Résumé IPv4 avec leak-map :

undefined

undefined

undefined

undefined

undefined

Les leak-maps permettent d’annoncer des routes plus spécifiques sélectionnées en même temps que le résumé, par exemple pour orienter le trafic des sous-réseaux critiques via une politique ou pour maintenir des chemins optimaux tout en contenant les requêtes pour le reste.

Compromis de conception :

• Des résumés grossiers maximisent la stabilité mais peuvent masquer des chemins sous-optimaux, ce qui amène le trafic à suivre des routes plus longues. Ne laissez fuiter (leak) que ce qui est nécessaire.
• Une variance excessive peut augmenter les chemins de répartition de charge (load balancing), mais uniquement parmi les FS ; assurez-vous du confinement des requêtes afin que des FS existent pour les destinations critiques.

Politique, redistribution, vérification et dépannage

Redistribution vers/depuis EIGRP :

• Les routes redistribuées dans EIGRP deviennent externes (distance administrative de 170). Définissez toujours une métrique déterministe et appliquez un marquage (tagging) pour éviter les boucles lors d’une redistribution mutuelle.

undefined

!

undefined

!

undefined

!

undefined

Essentiels de la vérification :

• Voisins :

undefined

,

undefined

• Topologie :

undefined

,

undefined

, et les équivalents en mode nommé sous

undefined

• Routage :

undefined

,

undefined

• État du protocole :

undefined

,

undefined

• Trafic et requêtes (queries) :

undefined

Flux de travail pour le dépannage de la convergence :

1. Confirmer les prérequis d’adjacence : AS correspondants, valeurs K/version de la métrique, authentification et absence de passive-interface sur les liens de transit.
2. Inspecter les temporisateurs (timers) et la santé de l’interface ; les instabilités (flaps) provoquent des états actifs fréquents. Ajustez les timers hello/hold uniquement lorsque c’est nécessaire ; privilégiez la correction des problèmes de support physique sous-jacents.
3. Rechercher les indications de SIA (Stuck In Active) et les tempêtes de requêtes (query storms). Ajouter ou affiner les résumés (summaries) et configurer le mode stub sur les routeurs de périphérie (leaf) pour limiter la portée des requêtes.
4. Évaluer la disponibilité des FS (Feasible Successors) dans la topologie. S’ils sont absents, vérifiez que la condition de faisabilité (feasible condition) peut être remplie ; ajustez les délais (delays) pour créer des chemins de secours viables si l’architecture l’exige.
5. Valider les métriques de redistribution et les tags. Des valeurs par défaut manquantes entraînent des métriques infinies, provoquant le rejet des routes ; l’absence de tags peut créer des boucles.
6. Pour IPv6, s’assurer que l’ID du routeur est défini et que l’activation par interface est présente ; EIGRP pour IPv6 n’utilise pas les déclarations de réseau (network) IPv4.

Scénario de problème pratique

Northwind Logistics exploite un réseau EIGRP à double hub avec des dizaines d’entrepôts en étoile (spoke). Des instabilités occasionnelles des circuits d’accès sur les sites distants déclenchent des tempêtes de requêtes, provoquant des états SIA intermittents sur les hubs et des basculements retardés. L’entreprise prévoit également d’activer IPv6 en parallèle d’IPv4 et doit empêcher les boucles de redistribution mutuelle entre EIGRP et OSPF dans les datacenters régionaux.

Approche :

1. Limiter la portée des requêtes avec la sumarisation (résumé) au niveau de la couche de distribution.

• Sur chaque interface de distribution vers les spokes, configurer des résumés IPv4 par interface et autoriser la fuite (leak) des sous-réseaux critiques qui nécessitent un routage optimal. Cela réduit la portée des requêtes lorsqu’un spoke perd une route plus spécifique, tout en préservant les performances pour les préfixes clés.

undefined

!

undefined

undefined

Justification : Les résumés créent une route de rejet vers Null0 (AD 5) pour les sous-préfixes non correspondants et empêchent les états Actifs de se propager au-delà de la frontière, réduisant ainsi considérablement le risque de SIA.

2. Déclarer les spokes comme des stubs ne propageant que les routes connectées et résumées.

undefined

Justification : Les hubs n’enverront pas de requêtes à large portée aux spokes ; les spokes n’ont pas besoin de répondre pour des routes qu’ils ne peuvent pas améliorer, ce qui raccourcit la convergence et préserve le CPU/la mémoire sur les CPE bas de gamme.

3. Activer le partage de charge à coût inégal (unequal-cost load sharing) entre les doubles hubs lorsque la condition FC est satisfaite.

undefined

Justification : La variance permet d’utiliser plusieurs chemins FS vers les hubs, améliorant le débit et la résilience sans violer les garanties d’absence de boucle, à condition que la condition FC soit respectée.

4. Standardiser les métriques et éviter les changements de valeurs K.

• Ne pas modifier les valeurs K. Définir explicitement les métriques de redistribution dans les datacenters.

undefined

undefined

Justification : Des métriques cohérentes produisent une sélection de chemin prévisible ; les tags marquent les routes externes pour empêcher les boucles de ré-entrée.

5. Bloquer les boucles de redistribution depuis EIGRP vers OSPF.

undefined

undefined

Justification : Les tags empêchent les mêmes routes d’osciller entre les protocoles, évitant ainsi l’instabilité (churn) et la confusion des métriques.

6. Renforcer la formation des adjacences avec l’authentification sur les segments LAN des hubs.

undefined

Justification : Empêche les adjacences non autorisées et les non-concordances accidentelles de métriques/valeurs K provenant d’équipements tiers.

7. Déployer EIGRP pour IPv6 par interface et définir un ID de routeur.

undefined

undefined

!

undefined

Justification : EIGRP pour IPv6 nécessite une activation explicite par interface et un ID de routeur 32 bits ; cela reflète le comportement d’IPv4 avec des adjacences distinctes sur FF02::A.

8. Valider et surveiller.

• Utiliser

undefined

pour vérifier la présence de FS ;

undefined

pour confirmer les timers/l’authentification ;

undefined

pour s’assurer que le nombre de requêtes diminue après le changement. Justification : Confirme que les changements de conception réduisent les états actifs/SIA et que plusieurs FS sont disponibles pour un basculement rapide.

← Conception · Tous les domaines · Politiques →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →