Pour les partenaires
Vous êtes déjà partenaire?
ConnexionAvez-vous un compte?
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
L'Enhanced Interior Gateway Routing Protocol (EIGRP) est un protocole de serveur interne adapté à de nombreux médias et topologies. Dans un réseau bien conçu, EIGRP évolue correctement et fournit des temps de convergence extrêmement rapides avec un trafic réseau minimal.
Certains des nombreux avantages d'EIGRP sont :
utilisation très basse des ressources réseau lors du fonctionnement normal ; seulement des paquets Hello sont transmis sur un réseau stable ;
quand une modification se produit, seules les modifications apportées aux tables de routage sont propagées, pas la table de routage entière ; ceci réduit la charge que le protocole de routage place lui-même sur le réseau ;
temps de convergence rapides pour des changements de la topologie du réseau (dans certains cas, la convergence peut être quasi instantanée)
EIGRP est un protocole de vecteur de distance optimisé, reposant sur l'algorithme DUAL (Diffused Update Algorithm (DUAL) pour calculer le plus court chemin vers une destination dans un réseau.
Il existe deux révisions majeures du protocole EIGRP, les versions 0 et 1. Les versions de Cisco IOS antérieures à 10.3(11), 11.0(8) et 11.1(3) exécutent la version antérieure du protocole EIGRP ; certaines explications dans ce document peuvent ne pas s'appliquer à cette version antérieure. Nous recommandons vivement d'utiliser la version ultérieure d'EIGRP, car elle inclut de nombreuses améliorations en termes de performance et de stabilité.
Un protocole de vecteur de distance typique sauvegarde l'information suivante en calculant le meilleur chemin vers une destination : la distance (distance ou métriques totales, comme le nombre de sauts) et le vecteur (le saut suivant). Par exemple, tous les routeurs du réseau sur la Figure 1 exécutent le Protocole d'informations de routage (RIP). Le routeur deux choisit le chemin vers le réseau A en examinant le nombre de sauts sur chaque chemin disponible.
Puisque le chemin via le routeur trois contient trois sauts, et que le chemin via le routeur un en contient deux, le routeur deux choisit le chemin via le routeur un et supprime les informations qu'il a apprises via le routeur trois. Si le chemin entre le routeur un et le réseau A se désactive, le routeur deux perd toutes les connexions à cette destination jusqu'à ce que la route de sa table de routage parvienne à expiration (trois périodes de mise à jour ou 90 secondes) et le routeur trois annonce à nouveau la route (qui se produit toutes les 30 secondes dans RIP). Sans compter de temps de blocage, il faudra entre 90 et 120 secondes au routeur deux pour basculer le chemin du routeur un sur le routeur trois.
Au lieu de reposer sur des mises à jour périodiques complètes pour reconverger, EIGRP construit une table de topologie à partir de chacune des annonces de son voisin (plutôt que de supprimer les données), et converge soit en recherchant une route sans boucle probable dans la table de topologie, soit, en l'absence d'autre route, en questionnant ses voisins. Le routeur deux sauvegarde les informations reçues des deux routeurs un et trois. Il choisit le chemin via le routeur un comme meilleur chemin (le successeur) et le chemin via le routeur trois comme chemin sans boucle (un successeur possible). Quand le chemin via le routeur un devient indisponible, le routeur deux examine sa table de topologie et, trouvant un successeur possible, commence à utiliser immédiatement le chemin via le routeur trois.
À partir de cette brève explication, il ressort qu'EIGRP doit fournir :
un système où il envoie seulement les mises à jour requises à un moment donné ; cela est accompli via la découverte des voisins et la maintenance ;
une façon d'identifier, pour un routeur, les chemins sans boucle ;
un processus pour effacer les chemins incorrects des tables de topologie de tous les routeurs sur le réseau ;
un processus pour questionner les voisins afin de trouver le chemin des destinations perdues.
Nous couvrirons ces conditions chacune à leur tour.
Pour distribuer les informations de routage au sein du réseau, EIGRP utilise les mises à jour de routage incrémentielles non périodiques. C'est-à-dire qu'EIGRP envoie seulement des mises à jour de routage concernant les chemins qui ont changé, le cas échéant.
L'envoi seul des mises à jour de routage pose un problème de base : vous ne pouvez pas savoir quand un chemin via un routeur voisin n'est plus disponible. Vous ne pouvez pas faire expirer les routes, dans l'espoir de recevoir une nouvelle table de routage de vos voisins. EIGRP se fonde sur des relations de voisinage pour propager de manière fiable les modifications de la table de routage dans tout le réseau ; deux routeurs deviennent voisins quand ils voient les paquets Hello de chacun d'entre eux sur un réseau commun.
EIGRP envoie des paquets Hello toutes les 5 secondes sur des liaisons à large bande passante et toutes les 60 secondes sur des liaisons multipoints à faible bande passante.
Hello toutes les 5 secondes :
supports de diffusion, tels qu'Ethernet, Token Ring, et FDDI
liaisons de série point à point, telles que les circuits loués PPP ou HDLC, les sous-interfaces point à point à relais de trame et la sous-interface point à point ATM ;
circuits multipoints à large bande passante (supérieure à T1), tels que PRI RNIS et et le relais de trame
Hello toutes les 60 secondes :
circuits multipoints à bande passante T1 ou plus faible, comme des interfaces multipoints à relais de trame, des interfaces multipoints ATM, des circuits virtuels commutés ATM et des RNIS BRI ;
Le débit auquel EIGRP envoie des paquets Hello s'appelle l'intervalle entre deux paquets Hello et vous pouvez l'ajuster par interface avec la commande ip hello-interval eigrp. La durée d'attente est le laps de temps pendant lequel un routeur considérera un voisin vivant sans recevoir de paquet Hello. La durée d'attente est en général trois fois l'intervalle entre deux paquets Hello, par défaut, 15 secondes et 180 secondes. Vous pouvez ajuster la durée d'attente avec la commande ip hold-time eigrp.
Notez que si vous changez l'intervalle entre deux paquets Hello, la durée d'attente n'est pas automatiquement ajustée afin de tenir compte de cette modification : vous devez l'ajuster manuellement pour refléter l'intervalle entre deux paquets Hello configuré.
Il est possible que deux routeurs deviennent des voisins EIGRP même si les temporisateurs Hello et d'attente ne correspondent pas. La durée d'attente est incluse dans les paquets Hello afin que chaque voisin reste vivant même si l'intervalle entre deux paquets Hello et le temporisateur d'attente ne correspondent pas.
Bien qu'il n'existe aucun moyen direct de déterminer l'intervalle Hello sur un routeur, vous pouvez le déduire à partir du résultat de la commande show ip eigrp neighbors sur le routeur voisin.
Si vous disposez de la sortie d'une commande show ip eigrp neighbors depuis votre périphérique Cisco, vous pouvez utiliser Cisco CLI Analyzer pour afficher les problèmes potentiels et les correctifs. Pour utiliser Cisco CLI Analyzer, JavaScript doit être activé.
router# show ip eigrp neighbors IP-EIGRP neighbors for process 1 H Address Interface Hold Uptime SRTT RTO Q Seq Type (sec) (ms) Cnt Num 1 10.1.1.2 Et1 13 12:00:53 12 300 0 620 0 10.1.2.2 S0 174 12:00:56 17 200 0 645 rp-2514aa# show ip eigrp neighbor IP-EIGRP neighbors for process 1 H Address Interface Hold Uptime SRTT RTO Q Seq Type (sec) (ms) Cnt Num 1 10.1.1.2 Et1 12 12:00:55 12 300 0 620 0 10.1.2.2 S0 173 12:00:57 17 200 0 645 rp-2514aa# show ip eigrp neighbor IP-EIGRP neighbors for process 1 H Address Interface Hold Uptime SRTT RTO Q Seq Type (sec) (ms) Cnt Num 1 10.1.1.2 Et1 11 12:00:56 12 300 0 620 0 10.1.2.2 S0 172 12:00:58 17 200 0 645
La valeur dans la colonne Hold de la sortie de commande ne devrait jamais dépasser la durée d'attente et ne jamais être inférieure à la durée d'attente moins l'intervalle entre deux paquets Hello (à moins évidemment que vous ne perdiez des paquets Hello). Si la colonne Hold oscille généralement entre 10 et 15 secondes, l'intervalle entre deux paquets Hello est de 5 secondes et la durée d'attente est de 15 secondes. Si la colonne Hold oscille généralement plus largement, entre 120 et 180 secondes, l'intervalle entre deux paquets Hello est de 60 secondes et la durée d'attente est de 180 secondes. Si les numéros ne semblent pas s'adapter à l'un des paramètres du temporisateur par défaut, vérifiez l'interface en question sur le routeur voisin ; les temporisateurs Hello et d'attente ont peut-être été configuré manuellement.
Note:
EIGRP n'établit pas des rapports de partenariat sur des adresses secondaires. Tout le trafic EIGRP est originaire de l'adresse principale de l'interface.
En configurant EIGRP sur un réseau à relais de trame à plusieurs accès (point-à-multipoint, etc.), configurez le mot clé broadcast dans les instructions de mappage de relais de trame. Sans le mot clé broadcast les juxtapositions ne s'établiraient pas entre deux routeurs EIGRP. Référez-vous au Guide complet de configuration et de dépannage de Frame Relay pour plus d'informations.
Il n'y a aucune limitation sur le nombre de voisins qu'EIGRP peut prendre en charge. Le nombre réel de voisins pris en charge dépend de la capacité du périphérique, comme :
la capacité mémoire,
la puissance de traitement,
la quantité d'informations échangées, telle que le nombre de routes envoyées,
la complexité de topologie,
la stabilité du réseau.
À présent que ces routeurs parlent entre eux, de quoi parlent-ils ? De leurs tables de topologie, naturellement ! EIGRP, à la différence de RIP et IGRP, ne se fonde pas sur la table de routage (ou de transfert) dans le routeur pour conserver toutes les informations dont il a besoin pour fonctionner. Au lieu de cela, il construit une seconde table, la table de topologie, à partir de laquelle il installe des routes dans la table de routage.
Note: À partir des versions 12.0T et 12.1 de Cisco IOS, RIP met à jour sa propre base de données à partir de laquelle elle installe des routes dans la table de routage.
Pour voir le format de base de la table de topologie sur un routeur exécutant EIGRP, émettez la commande show ip eigrp topology. La table de topologie contient les informations requises pour construire un jeu de distances et de vecteurs pour chaque réseau accessible, incluant :
la bande passante la plus faible en direction de cette destination comme enregistré par le voisin en amont,
le retard total,
la fiabilité du chemin,
le chargement du chemin,
l'unité de transmission maximale (MTU) du chemin minimal,
la distance acceptable,
la distance relevée,
l'origine de la route (les routes externes sont marquées).
Les distances acceptables et relevées sont discutées ultérieurement dans cette section.
Si vous disposez de la sortie d'une commande show ip eigrp topology depuis votre périphérique Cisco, vous pouvez utiliser Cisco CLI Analyzer pour afficher les problèmes potentiels et les correctifs. Pour utiliser Cisco CLI Analyzer, JavaScript doit être activé.
EIGRP emploie la bande passante minimale en direction du réseau de destination et le retard total pour calculer des métriques de routage. Bien que vous puissiez configurer d'autres métriques, nous vous ne le recommandons pas, car cela peut entraîner des boucles de routage dans votre réseau. Les métriques de bande passante et de délai sont déterminées à partir des valeurs configurées sur les interfaces des routeurs en direction du réseau de destination.
Par exemple, dans la Figure 2 ci-dessous, le routeur un calcule le meilleur chemin vers le réseau A.
Il commence par les deux annonces pour ce réseau : un via le routeur quatre, avec une bande passante minimale de 56 et un retard total de 2200 ; et l'autre via le routeur trois, avec une bande passante minimale de 128 et un retard de 1200. Le routeur un choisit le chemin aux métriques les plus basses.
Calculons les métriques. EIGRP calcule les métriques totales par l'évolution de la bande passante et les métriques de délai. EIGRP emploie la formule suivante pour faire évoluer la bande passante :
bande passante = (10000000/bande passante(i)) * 256
où bande passante(i) est la bande passante la plus faible de toutes les interfaces sortantes en direction du réseau de destination en kilobits.
EIGRP emploie la formule suivante pour faire évoluer le retard :
retard = retard(i) * 256
où retard(i) est la somme des retards configurés sur les interfaces, en direction du réseau de destination, en dizaines de microsecondes. Le retard suivant les indications des commandes show ip eigrp topology ou show interface est exprimé en microsecondes, ainsi vous devez le diviser par 10 avant de l'utiliser dans cette formule. Dans ce document, nous utilisons le retard comme il est configuré et montré sur l'interface.
EIGRP emploie ces valeurs mesurées pour déterminer les métriques totales vers le réseau :
métrique = ([K1 * bande passante + (K2 * bande passante) / (256 - charge) + K3 * délai] * [K5 / (fiabilité + K4)]) * 256
Note: Ces valeurs K devraient être utilisées après une planification soigneuse. Les valeurs K inadaptées empêchent la construction d'une relation de voisinage, ce qui peut faire échouer la convergence de votre réseau.
Note: Si K5 = 0, la formule se réduit à Métrique = ([k1 * bande passante + (k2 * bande passante)/(256 - charge) + k3 * délai]) * 256.
Les valeurs par défaut pour K sont :
K1 = 1
K2 = 0
K3 = 1
K4 = 0
K5 = 0
Pour le comportement par défaut, vous pouvez simplifier la formule comme suit :
metric = bandwidth + delay
Les routeurs Cisco n'exécutent pas des calculs avec des virgules flottantes ; à chaque étape du calcul, vous devez donc arrondir au nombre entier le plus proche pour calculer correctement les métriques. Dans cet exemple, le coût total via le routeur quatre est :
Dans cet exemple, le coût total via le routeur quatre est :
minimum bandwidth = 56k total delay = 100 + 100 + 2000 = 2200 [(10000000/56) + 2200] x 256 = (178571 + 2200) x 256 = 180771 x 256 = 46277376
Et le coût total via le routeur trois est :
minimum bandwidth = 128k total delay = 100 + 100 + 1000 = 1200 [(10000000/128) + 1200] x 256 = (78125 + 1200) x 256 = 79325 x 256 = 20307200
Ainsi, pour atteindre le réseau A, le routeur un choisit la route via le routeur trois.
Notez que les valeurs de bande passante et de retard que nous avons utilisées sont celles configurées sur l'interface via laquelle le routeur atteint son saut suivant vers le réseau de destination. Par exemple, le routeur deux a annoncé le réseau A avec le retard configuré sur son interface Ethernet ; Le routeur quatre a ajouté le retard configuré sur son Ethernet, et le routeur un a ajouté le retard configuré sur son interface série.
La distance acceptable est la meilleure métrique le long d'un chemin vers un réseau de destination, y compris les métriques vers le voisin qui annonce ce chemin. La distance relevée est la métrique totale le long d'un chemin vers un réseau de destination comme annoncé par un voisin en amont. Un successeur possible est un chemin dont la distance relevée est inférieure à la distance acceptable (meilleur chemin actuel). La Figure 3 montre ce processus :
Le routeur un voit qu'il a deux routes vers le réseau A : une via le routeur trois et une autre via le routeur quatre.
La route via le routeur quatre a un coût de 46277376 et une distance relevée de 307200.
La route via le routeur trois a un coût de 20307200 et une distance relevée de 307200.
Notez que dans chaque cas EIGRP calcule la distance relevée à partir du routeur annonçant la route vers le réseau. En d'autres termes, la distance relevée à partir du routeur quatre est la métrique pour atteindre le réseau A à partir du routeur quatre, et la distance relevée à partir du routeur trois est la métrique pour atteindre le réseau A à partir du routeur trois. EIGRP choisit la route via le routeur trois comme meilleur chemin, et utilise la métrique via le routeur trois comme distance acceptable. Puisque la distance relevée vers ce réseau via le routeur quatre est inférieure à la distance acceptable, le routeur un considère le chemin via le routeur quatre comme un successeur possible.
Lorsque la liaison entre les routeurs un et trois s'arrête, le routeur un examine chaque chemin qu'il connaît vers le réseau A et découvre qu'il a un successeur possible via le routeur quatre. Le routeur un utilise cette route, utilise la métrique via le routeur quatre comme nouvelle distance acceptable. Le réseau converge immédiatement, et les mises à jour vers les voisins en aval sont le seul trafic à partir du protocole de routage.
Considérons un scénario plus complexe, représenté dans la Figure 4.
Il y a deux routes vers le réseau A à partir du routeur un : une via le routeur deux avec une métrique de 46789376 et une autre via le routeur quatre avec une métrique de 20307200. Le routeur un choisit la métrique inférieure parmi ces deux métriques en tant que route vers le réseau A, et ce métrique devient la distance acceptable. Ensuite, considérons le chemin via le routeur deux pour voir s'il se qualifie comme successeur possible. La distance relevée à partir du routeur deux est 46277376, qui est plus élevée que la distance acceptable ; ce chemin n'est donc pas un successeur possible. Si vous deviez regarder dans la table de topologie du routeur un à ce point (en utilisant show ip eigrp topology), vous verriez seulement une entrée pour le réseau A, via le routeur quatre. (En réalité, il y a deux entrées dans la table de topologie au routeur un, mais seulement l'un d'entre eux sera un successeur possible, l'autre ne sera donc pas affiché dans show ip eigrp topology ; vous pouvez voir les routes qui ne sont pas des successeurs possibles avec show ip eigrp topology all-links).
Supposons que la liaison entre le routeur un et le routeur quatre s'arrête. Le routeur un voit qu'il a perdu sa seule route vers le réseau A, et questionne chacun de ses voisins (dans ce cas, seulement le routeur deux) pour voir s'ils ont une route vers le réseau A. Puisque le routeur deux a une route vers le réseau A, il répond à la requête. Puisque le routeur un n'a plus la meilleure route via le routeur quatre, il accepte cette route via le routeur deux vers le réseau A.
Comment EIGRP emploie-t-il les concepts de la distance acceptable, la distance relevée et le successeur possible pour déterminer si un chemin est valide, et pas une boucle ? Dans le schéma 4a, le routeur trois examine des routes vers le réseau A. Puisque la fonction de découpage de l'horizon est désactivée (par exemple, si ce sont des interfaces à relais de trame multipoints), le routeur trois affiche trois routes vers le réseau A : via le routeur quatre, via le routeur deux (le chemin est deux, un, trois, quatre), et via le routeur un (le chemin est un, deux, trois, quatre).
Si le routeur trois reçoit toutes ces routes, il termine dans une boucle de routage. Le routeur trois pense qu'il peut atteindre le réseau A via le routeur deux, mais le chemin via le routeur deux passe par le routeur trois pour atteindre le réseau A. Si la connexion entre le routeur quatre et le routeur trois s'arrête, le routeur trois croit qu'il peut atteindre le réseau A par l'un des autres chemins, mais en raison des règles pour déterminer des successeurs possibles, il n'utilisera jamais ces chemins en tant que substituts. Considérons la métrique pour comprendre pourquoi :
la métrique totale vers le réseau A via le routeur quatre : 20281600
la métrique totale vers le réseau A via le routeur deux : 47019776
la métrique totale vers le réseau A via le routeur un : 47019776
Puisque le chemin à travers le routeur quatre a la meilleure métrique, le routeur trois installe cette route dans la table de transfert et utilise 20281600 comme distance de faisabilité vers le réseau A. Le routeur trois calcule ensuite la distance annoncée vers le réseau A via les routeurs deux et un : 47019776 pour le chemin via le routeur deux et 47019776 pour le chemin via le routeur un. Puisque chacune des deux métriques est plus grande que la distance acceptable, le routeur trois n'installe aucune route comme successeur possible pour le réseau A.
Supposons que la liaison entre les routeurs trois et quatre s'arrête. Le routeur trois demande à chacun de ses voisins une autre route vers le réseau A. Le routeur deux reçoit la requête et, comme la requête provient de son successeur, recherche chacune des autres entrées de sa table topologique pour voir s'il existe un successeur potentiel. La seule autre entrée dans la table de topologie est à partir du routeur un, avec une distance relevée égale à la dernière meilleure métrique via le routeur trois. Puisque la distance relevée via le routeur un n'est pas inférieure à la dernière distance acceptable connue, le routeur deux marque la route comme étant inaccessible et questionne chacun de ses voisins - dans ce cas, seulement le routeur un - pour un chemin vers le réseau A.
Le routeur trois envoie également une requête pour le réseau A vers le routeur un. Le routeur un examine sa table de topologie et trouve que le seul autre chemin vers le réseau A est via le routeur deux avec une distance relevée égale à la dernière distance acceptable connue via le routeur trois. De nouveau, puisque la distance relevée via le routeur deux n'est pas inférieure à la dernière distance acceptable connue, cette route n'est pas un successeur possible. Le routeur un marque la route comme étant inaccessible et questionne son seul autre voisin, le routeur deux, pour un chemin vers le réseau A.
C'est le premier niveau de requêtes. Le routeur trois a interrogé chacun de ses voisins pour tenter de trouver une route vers le réseau A. À leur tour, les routeurs Un et Deux ont marqué la route comme inaccessible et ont interrogé chacun de leurs voisins restants afin de trouver un chemin vers le réseau A. Quand le routeur deux reçoit la requête du routeur un, il examine sa table de topologie et note que la destination est marquée comme inaccessible. Le routeur deux répond au routeur un que le réseau A est inaccessible. Quand le routeur un reçoit la requête du routeur deux, il répond également que le réseau A est inaccessible. Maintenant que les routeurs un et deux ont conclu que le réseau A est inaccessible, ils répondent à la requête originale du routeur trois. Le réseau a convergé, et toutes les routes repassent à l'état passif.
Dans l'exemple précédent, nous avons supposé que le découpage de l'horizon n'était pas en vigueur pour montrer comment EIGRP emploie la distance acceptable et la distance relevée pour déterminer si une route est susceptible d'être une boucle. Dans certaines circonstances, cependant, EIGRP emploie le Split Horizon pour empêcher aussi des boucles de routage. Avant de traiter en détail la façon dont EIGRP utilise le Split Horizon, examinons en quoi il consiste et comment il fonctionne. La règle de Split Horizon est :
Il ne faut jamais annoncer une route hors de l'interface par laquelle vous l'avez connue.
Par exemple, dans la Figure 4a, si le routeur un est connecté aux routeurs deux et trois via une interface multipoint simple (telle que le relais de trame), et que le routeur un a pris connaissance du réseau A à partir du routeur deux, il n'annoncera pas la route vers le réseau A à l'extérieur de la même interface au routeur trois. Le routeur un suppose que le routeur trois se renseigne sur le réseau A directement à partir du routeur deux.
Le Poison Reverse est une autre manière d'éviter des boucles de routage. Sa règle est :
Une fois que vous avez pris connaissance d'une route via une interface, annoncez-la comme inaccessible via cette même interface.
Disons que les routeurs dans la Figure 4a ont la fonctionnalité de Poison Reverse activée. Quand le routeur un se renseigne sur le réseau A à partir du routeur deux, il annonce que le réseau A est inaccessible via sa liaison aux routeurs deux et trois. Le routeur trois, s'il montre n'importe quel chemin vers le réseau A via le routeur un, supprime ce chemin en raison de l'annonce d'inaccessibilité. EIGRP combine ces deux règles pour empêcher les boucles de routage.
EIGRP utilise le Split Horizon ou annonce qu'une route est inaccessible quand :
deux routeurs sont en mode de démarrage (permutant des tables de topologie pour la première fois) ;
l'annonce d'une modification de table de topologie ;
l'envoi d'une requête ;
Examinons chacune de ces situations.
Quand deux routeurs deviennent voisins pour la première fois, ils échangent des tables de topologie au cours du mode de démarrage. Pour chaque entrée de table qu'un routeur reçoit au cours du mode de démarrage, il annonce la même entrée à son nouveau voisin avec une métrique maximale (route du poison).
Dans la Figure 5, le routeur un utilise la variance pour équilibrer le trafic destiné au réseau A entre les deux liaisons série - la liaison 56k entre les routeurs deux et quatre et la liaison 128k entre les routeurs trois et quatre (voir la section « Équilibrage de charge » pour une discussion de la variance).
Le routeur deux considère le chemin via le routeur trois comme un successeur possible. Si la liaison entre les routeurs deux et quatre faiblit, le routeur deux reconverge simplement sur le chemin via le routeur trois. Puisque la règle de Split Horizon établit que vous ne devriez jamais annoncer une route hors de l'interface par laquelle vous l'avez connue, le routeur n'envoie généralement aucune mise à jour. Cependant, ceci laisse le routeur un avec une entrée de table de topologie incorrecte. Quand un routeur change sa table de topologie de sorte que l'interface à travers laquelle le routeur atteint le réseau est modifiée, cela désactive le split horizon et le poison inverse l'ancienne route pour toutes les interfaces. Dans ce cas, le routeur deux arrête le split horizon pour cette route et annonce que le réseau A est inaccessible. Le routeur un reçoit cette annonce et vide sa route vers le réseau A via le routeur deux de sa table de routage.
Les requêtes entraînent un split horizon seulement quand un routeur reçoit une requête ou une mise à jour du successeur qu'il utilise pour la destination dans la requête. Observons le réseau sur le schéma 6.
Le routeur trois reçoit une requête au sujet de 10.1.2.0/24 (auquel elle accède via le routeur un) à partir du routeur quatre. Si le routeur trois n'a pas de successeur pour cette destination en raison de l'affolement d'une liaison ou de tout autre état provisoire du réseau, il envoie une requête à chacun de ses voisins ; dans ce cas, les routeurs un, deux et quatre. Si, toutefois, le routeur trois reçoit une requête ou une mise à jour (comme une modification métrique) du routeur un pour la destination 10.1.2.0/24, il ne renvoie pas de requête au routeur un, parce que ce dernier est son successeur vers ce réseau. Au lieu de cela, il envoie seulement des requêtes aux routeurs deux et quatre.
Dans certaines circonstances, le temps de réponse à une requête peut être long. Si long, en fait, que le routeur qui a émis la requête renonce et efface sa connexion au routeur qui ne répond pas, relançant effectivement la session voisine. On parle alors de route bloquée en actif (SIA). Les routes SIA les plus basiques se produisent quand une requête met trop de temps à atteindre l'autre extrémité du réseau et que la réponse revienne. Par exemple, dans la Figure 7, le routeur un enregistre un grand nombre de routes SIA à partir du routeur deux.
Après quelques recherches, le problème est identifié autour du retard de la liaison satellite entre les routeurs deux et trois. Il existe deux solutions possibles à ce type de problème. La première consiste à augmenter le temps d'attente du routeur après qu'il a envoyé une requête avant la déclaration de la route SIA. Cette configuration peut être changée en utilisant la commande timers active-time .
La meilleure solution, cependant, est de remodeler le réseau pour réduire la portée des requêtes (ainsi, seul un petit nombre de requêtes passent par la liaison satellite). La plage de requêtes est traitée dans la section « Plage de requêtes ». Cependant, la portée de la requête en elle-même n'est pas une raison commune du signalement des routes SIA. Le plus souvent, certains routeurs sur le réseau ne peuvent pas répondre à une requête pour l'une des raisons suivantes :
le routeur est trop occupé pour répondre à la requête (généralement en raison de l'utilisation élevée du CPU) ;
le routeur connaît des problèmes de mémoire et ne peut pas allouer de la mémoire pour traiter la requête ou construire le paquet de réponse ;
le circuit entre les deux routeurs n'est pas bon : suffisamment de paquets passent afin de maintenir la relation de voisinage, mais une partie des requêtes ou des réponses sont perdues entre les routeurs ;
les liaisons unidirectionnelles (une liaison sur laquelle le trafic peut seulement circuler dans un sens en raison d'une panne).
Le dépannage des routes SIA consiste généralement en un processus en trois étapes :
Recherchez les routes qui sont uniformément relevées comme SIA.
Recherchez le routeur qui ne répond pas uniformément aux requêtes pour ces routes.
Recherchez la raison pour laquelle le routeur ne reçoit ou ne répond pas aux requêtes.
La première étape devrait être assez facile. Si vous enregistrez des messages de console, une lecture rapide du journal indique quelles routes sont le plus souvent marquées comme étant SIA. La deuxième étape est plus difficile. La commande permettant de recueillir ces informations est show ip eigrp topology active :
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - Reply status A 10.2.4.0/24, 0 successors, FD is 512640000, Q 1 replies, active 00:00:01, query-origin: Local origin via 10.1.2.2 (Infinity/Infinity), Serial1 1 replies, active 00:00:01, query-origin: Local origin via 10.1.3.2 (Infinity/Infinity), r, Serial3 Remaining replies: via 10.1.1.2, r, Serial0
Tout voisin affichant un R doit encore répondre (le temporisateur actif montre la durée d'activité de la route). Notez que ces voisins peuvent ne pas apparaître dans la section des réponses restantes ; ils peuvent apparaître parmi les autres RDB. Prêtez une attention particulière aux routes qui ont des réponses en attente et ont été en activité pendant un certain temps, généralement deux à trois minutes. Exécutez la commande plusieurs fois avant de commencer à identifier les voisins qui ne répondent pas aux requêtes (ou les interfaces qui semblent avoir beaucoup de requêtes sans réponse). Examinez chacun de ces voisins pour voir s'ils attendent des réponses de l'un de leurs voisins. Répétez ce processus jusqu'à ce que vous trouviez le routeur qui ne répond pas systématiquement aux requêtes. Vous pouvez rechercher des problèmes sur la liaison avec ce voisin, la mémoire ou l'utilisation du CPU, ou d'autres problèmes.
Si la portée de la requête semble être la raison du problème, il est toujours préférable de réduire la portée de la requête plutôt que d'augmenter le temporisateur SIA.
Cette section examine différents scénarios impliquant la redistribution. Veuillez noter que les exemples ci-dessous montrent la configuration minimale requise pour la redistribution. La redistribution peut potentiellement poser des problèmes, tels que le routage non optimal, des boucles de routage ou la convergence lente. Pour éviter ces problèmes, référez-vous à « Éviter les problèmes causés par la redistribution » dans Redistribution des protocoles de routage.
Sur le schéma 8, les routeurs sont configurés comme suit :
Routeur un
router eigrp 2000 !--- The "2000" is the autonomous system network 172.16.1.0 0.0.0.255
Routeur deux
router eigrp 2000 redistribute eigrp 1000 route-map to-eigrp2000 network 172.16.1.0 0.0.0.255 ! router eigrp 1000 redistribute eigrp 2000 route-map to-eigrp1000 network 10.1.0.0 0.0.255.255 route-map to-eigrp1000 deny 10 match tag 1000 ! route-map to-eigrp1000 permit 20 set tag 2000 ! route-map to-eigrp2000 deny 10 match tag 2000 ! route-map to-eigrp2000 permit 20 set tag 1000
Routeur trois
router eigrp 1000 network 10.1.0.0 0.0.255.255
Le routeur trois annonce le réseau 10.1.2.0/24 au routeur deux via le système autonome 1000 ; le routeur deux redistribue cette route dans le système autonome 2000 et l'annonce au routeur un.
Note: Les routes à partir d'EIGRP 1000 sont marquées 1000 avant de les redistribuer à EIGRP 2000. Quand des routes à partir d'EIGRP 2000 sont redistribuées à nouveau à EIGRP 1000, les routes comportant les balises 1000 sont refusées afin de garantir une topologie sans boucle. Pour plus d'informations sur la redistribution parmi des protocoles de routage, référez-vous à Redistribution des protocoles de routage.
Sur le routeur un, nous voyons :
one# show ip eigrp topology 10.1.2.0 255.255.255.0 IP-EIGRP topology entry for 10.1.2.0/24 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 46763776 Routing Descriptor Blocks: 20.1.1.1 (Serial0), from 20.1.1.1, Send flag is 0x0 Composite metric is (46763776/46251776), Route is External Vector metric: Minimum bandwidth is 56 Kbit Total delay is 41000 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 2 External data: Originating router is 10.1.2.1 AS number of route is 1000 External protocol is EIGRP, external metric is 46251776 Administrator tag is 1000 (0x000003E8)
Notez que bien que la liaison entre les routeurs un et deux ait une bande passante de 1 544 Mo, la bande passante minimale affichée dans cette entrée de table de topologie est 56 K. Cela signifie qu'EIGRP préserve toute les métriques en redistribuant entre deux systèmes autonomes EIGRP.
Sur le schéma 9, nous avons changé les configurations comme suit :
router eigrp 2000 network 172.16.1.0
router eigrp 2000 redistribute igrp 1000 route-map to-eigrp2000 network 172.16.1.0 ! router igrp 1000 redistribute eigrp 2000 route-map to-igrp1000 network 10.0.0.0 ! route-map to-igrp1000 deny 10 match tag 1000 ! route-map to-igrp1000 permit 20 set tag 2000 ! route-map to-eigrp2000 deny 10 match tag 2000 ! route-map to-eigrp2000 permit 20 set tag 1000
router igrp 1000 network 10.0.0.0
La configuration du routeur un est affichée ci-dessous :
one# show ip eigrp topology 10.1.2.0 255.255.255.0 IP-EIGRP topology entry for 10.1.2.0/24 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 46763776 Routing Descriptor Blocks: 20.1.1.1 (Serial0), from 20.1.1.1, Send flag is 0x0 Composite metric is (46763776/46251776), Route is External Vector metric: Minimum bandwidth is 56 Kbit Total delay is 41000 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 1 External data: Originating router is 10.1.1.1 AS number of route is 1000 External protocol is IGRP, external metric is 180671 Administrator tag is 1000 (0x000003E8)
Des métriques IGRP sont conservées quand des routes sont redistribuées dans EIGRP avec un système autonome différent, mais elles évoluent en multipliant la métrique IGRP par la constante 256. Il existe un obstacle à la redistribution entre à IGRP et d'EIGRP qui doit être noté. Si le réseau est directement connecté au routeur effectuant la redistribution, il annonce la route avec une métrique de 1.
Par exemple, le réseau 10.1.1.0/24 est directement connecté au routeur deux et IGRP effectue le routage pour ce réseau (il y a une instruction réseau sous le routeur IGPR qui couvre cette interface). EIGRP n'effectue pas le routage pour ce réseau, mais apprend au sujet de cette interface directement connectée via la redistribution d'IGRP. Sur le routeur un, l'entrée de table de topologie pour 10.1.1.0/24 affiche :
one# show ip eigrp topology 10.1.1.0 255.255.255.0 IP-EIGRP topology entry for 10.1.1.0/24 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2169856 Routing Descriptor Blocks: 20.1.1.1 (Serial0), from 20.1.1.1, Send flag is 0x0 Composite metric is (2169856/1), Route is External Vector metric: Minimum bandwidth is 1544 Kbit Total delay is 20000 microseconds Reliability is 0/255 Load is 1/255 Minimum MTU is 1500 Hop count is 1 External data: Originating router is 10.1.1.1 AS number of route is 1000 External protocol is IGRP, external metric is 0 Administrator tag is 1000 (0x000003E8)
Notez que la distance relevée à partir du routeur deux, qui est en gras, est 1."
Les changements suivants sont apportés aux configurations du routeur du schéma 10 :
router eigrp 2000 network 172.16.1.0
router eigrp 2000 network 172.16.1.0 ! router igrp 2000 network 10.0.0.0
router igrp 2000 network 10.0.0.0
Et le routeur un est configuré comme suit :
one# show ip eigrp topology 10.1.2.0 255.255.255.0 IP-EIGRP topology entry for 10.1.2.0/24 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 46763776 Routing Descriptor Blocks: 20.1.1.1 (Serial0), from 20.1.1.1, Send flag is 0x0 Composite metric is (46763776/46251776), Route is External Vector metric: Minimum bandwidth is 56 Kbit Total delay is 41000 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 1 External data: Originating router is 10.1.1.1 AS number of route is 2000 External protocol is IGRP, external metric is 180671 Administrator tag is 0 (0x00000000)
Cette configuration ressemble étrangement à la sortie précédente lors de la redistribution entre deux systèmes autonomes différents exécutant IGRP et EIGRP. Le réseau 10.1.1.0/24 directement attaché est traité de la même façon dans les deux scénarios :
one# show ip eigrp topology 10.1.1.0 255.255.255.0 IP-EIGRP topology entry for 10.1.1.0/24 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2169856 Routing Descriptor Blocks: 20.1.1.1 (Serial0), from 20.1.1.1, Send flag is 0x0 Composite metric is (2169856/1), Route is External Vector metric: Minimum bandwidth is 1544 Kbit Total delay is 20000 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 1 External data: Originating router is 10.1.1.1 AS number of route is 2000 External protocol is IGRP, external metric is 0 Administrator tag is 0 (0x00000000)
Ainsi ce réseau, qui est directement connecté au routeur un, est redistribué à partir d'IGRP vers EIGRP avec une métrique de 1, la même métrique constatée lors de la redistribution entre deux systèmes autonomes différents.
Il existe deux obstacles à la redistribution EIGRP/IGRP dans le même système autonome :
Des routes EIGRP internes sont toujours préférables aux routes EIGRP ou IGRP externes.
La métrique de route EIGRP externe est comparée aux métriques IGRP ayant évoluées (la distance administrative est ignorée).
Examinons ces obstacles sur le schéma 11 :
Le routeur un annonce 10.1.4.0/24 dans le système autonome 100 IGRP ; le routeur quatre annonce 10.1.4.0/24 comme étant externe dans le système autonome 100 EIGRP ; le routeur deux exécute EIGRP et IGRP dans le système autonome 100.
Si nous ignorons la route EIGRP annoncée par le routeur quatre (en fermant la liaison entre les routeurs deux et quatre, par exemple), le routeur deux affiche :
two# show ip route 10.1.4.0 Routing entry for 10.1.4.0/24 Known via "igrp 100", distance 100, metric 12001 Redistributing via igrp 100, eigrp 100 Advertised by igrp 100 (self originated) eigrp 100 Last update from 10.1.1.2 on Serial1, 00:00:42 ago Routing Descriptor Blocks: * 10.1.1.2, from 10.1.1.2, 00:00:42 ago, via Serial1 Route metric is 12001, traffic share count is 1 Total delay is 20010 microseconds, minimum bandwidth is 1000 Kbit Reliability 1/255, minimum MTU 1 bytes Loading 1/255, Hops 0
Notez que la distance administrative est 100. Quand nous ajoutons la route EIGRP, le routeur deux affiche :
two# show ip route 10.1.4.0 Routing entry for 10.1.4.0/24 Known via "eigrp 100", distance 170, metric 3072256, type external Redistributing via igrp 100, eigrp 100 Last update from 10.1.2.2 on Serial0, 00:53:59 ago Routing Descriptor Blocks: * 10.1.2.2, from 10.1.2.2, 00:53:59 ago, via Serial0 Route metric is 3072256, traffic share count is 1 Total delay is 20010 microseconds, minimum bandwidth is 1000 Kbit Reliability 1/255, minimum MTU 1 bytes Loading 1/255, Hops 1
Notez que les métriques de ces deux routes sont identiques après avoir été mises à l'échelle du protocole IGRP vers le protocole EIGRP (voir la section « Mesures ») :
12001 x 256 = 3072256
où 12001, une métrique IGRP, est via le routeur une ; et 3072256, une métrique EIGRP, est via le routeur quatre.
Le routeur deux préfère la route externe EIGRP avec la même métrique (après évolution) et une distance administrative plus élevée. Cela se vérifie chaque fois qu'une redistribution automatique se produit entre EIGRP et IGRP dans le même système autonome. Le routeur préfère toujours le chemin ayant la métrique la moins coûteuse et ignore la distance administrative.
La redistribution entre EIGRP et d'autres protocoles, RIP et OSPF par exemple, fonctionne de la même manière que toute redistribution. Il est toujours mieux d'utiliser la métrique par défaut en redistribuant entre les protocoles. Vous devriez être conscient des deux problèmes suivants lors de la redistribution entre EIGRP et d'autres protocoles :
Les routes redistribuées dans EIGRP ne sont pas toujours résumées. Reportez-vous à la section Récapitulation pour obtenir une explication.
Les routes EIGRP externes ont une distance administrative de 170.
Quand vous installez une route statique vers l'interface, et que vous configurez une instruction réseau utilisant router eigrp, qui inclut la route statique, EIGRP redistribue cette route comme si c'était une interface directement connectée. Examinons le réseau sur le schéma 12.
Le routeur un a une route statique vers le réseau 172.16.1.0/24 configuré via l'interface série 0 :
ip route 172.16.1.0 255.255.255.0 Serial0
Et le routeur un a également une instruction réseau pour la destination de cette route statique :
router eigrp 2000 network 10.0.0.0 network 172.16.0.0 no auto-summary
Le routeur un redistribue cette route, même s'il ne redistribue pas des routes statiques, parce qu'EIGRP la considère comme un réseau directement raccordé. Sur le routeur deux, ceci ressemble à cela :
two# show ip route .... 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C 10.1.1.0/24 is directly connected, Serial0 D 10.1.2.0/24 [90/2169856] via 10.1.1.1, 00:00:47, Serial0 172.16.0.0/24 is subnetted, 1 subnets D 172.16.1.0 [90/2169856] via 10.1.1.1, 00:00:47, Serial0
Notez que la route vers 172.16.1.0/24 apparaît comme une route EIGRP interne sur le routeur deux.
Il y a deux formes de récapitulation dans EIGRP : les résumés automatiques et les résumés manuels.
EIGRP exécute une récapitulation automatique chaque fois que il franchit une frontière entre deux réseaux principaux différents. Par exemple, sur le schéma 13, le routeur deux annonce seulement le réseau 10.0.0.0/8 au routeur un, parce que l'interface que le routeur deux utilise pour atteindre le routeur un est dans un réseau principal différent.
Sur le routeur un, cela ressemble à ce qui suit :
one# show ip eigrp topology 10.0.0.0 IP-EIGRP topology entry for 10.0.0.0/8 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 11023872 Routing Descriptor Blocks: 172.16.1.1 (Serial0), from 172.16.1.2, Send flag is 0x0 Composite metric is (11023872/10511872), Route is Internal Vector metric: Minimum bandwidth is 256 Kbit Total delay is 40000 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 1
Cette route n'est pas marquée comme une route récapitulative en aucune sorte ; elle ressemble à une route interne. La métrique est le meilleure parmi les routes récapitulées. Notez que la bande passante minimale sur cette route est 256 K, bien qu'il y ait des liaisons dans le réseau 10.0.0.0 dont la bande passante est de 56 K.
Sur le routeur effectuant la récapitulation, une route est construite sur null0 pour l'adresse récapitulée :
two# show ip route 10.0.0.0 Routing entry for 10.0.0.0/8, 4 known subnets Attached (2 connections) Variably subnetted with 2 masks Redistributing via eigrp 2000 C 10.1.3.0/24 is directly connected, Serial2 D 10.1.2.0/24 [90/10537472] via 10.1.1.2, 00:23:24, Serial1 D 10.0.0.0/8 is a summary, 00:23:20, Null0 C 10.1.1.0/24 is directly connected, Serial1
La route à 10.0.0.0/8 est marquée comme récapitulative via Null0. L'entrée de table de topologie pour cette route récapitulative ressemble à ce qui suit :
two# show ip eigrp topology 10.0.0.0 IP-EIGRP topology entry for 10.0.0.0/8 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 10511872 Routing Descriptor Blocks: 0.0.0.0 (Null0), from 0.0.0.0, Send flag is 0x0 (note: the 0.0.0.0 here means this route is originated by this router) Composite metric is (10511872/0), Route is Internal Vector metric: Minimum bandwidth is 256 Kbit Total delay is 20000 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 0
Pour que le routeur deux annonce les composants du réseau 10.0.0.0 au lieu d'un résumé, configurez no auto-summary sur le processus EIGRP du routeur deux :
Sur le routeur deux
router eigrp 2000 network 172.16.0.0 network 10.0.0.0 no auto-summary
Le résumé automatique étant arrêté, le routeur un voit maintenant tous les composants du réseau 10.0.0.0 :
one# show ip eigrp topology IP-EIGRP Topology Table for process 2000 Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - Reply status P 10.1.3.0/24, 1 successors, FD is 46354176 via 20.1.1.1 (46354176/45842176), Serial0 P 10.1.2.0/24, 1 successors, FD is 11049472 via 20.1.1.1 (11049472/10537472), Serial0 P 10.1.1.0/24, 1 successors, FD is 11023872 via 20.1.1.1 (11023872/10511872), Serial0 P 172.16.1.0/24, 1 successors, FD is 2169856 via Connected, Serial0
Il y a quelques mises en garde lors de la récapitulation des routes externes qui sont traitées plus loin dans la section « Récapitulation automatique des routes externes ».
EIGRP vous permet de récapituler des routes internes et externes sur pratiquement n'importe quelle limite de bit utilisant la récapitulation manuelle. Par exemple, dans la Figure 14, le routeur deux récapitule 192.1.1.0/24, 192.1.2.0/24, et 192.1.3.0/24 dans le bloc CIDR 192.1.0.0/22.
La configuration sur le routeur deux est affichée ci-dessous :
two# show run .... ! interface Serial0 ip address 10.1.50.1 255.255.255.0 ip summary-address eigrp 2000 192.1.0.0 255.255.252.0 no ip mroute-cache ! .... two# show ip eigrp topology IP-EIGRP Topology Table for process 2000 Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - Reply status P 10.1.10.0/24, 1 successors, FD is 45842176 via Connected, Loopback0 P 10.1.50.0/24, 1 successors, FD is 2169856 via Connected, Serial0 P 192.1.1.0/24, 1 successors, FD is 10511872 via Connected, Serial1 P 192.1.0.0/22, 1 successors, FD is 10511872 via Summary (10511872/0), Null0 P 192.1.3.0/24, 1 successors, FD is 10639872 via 192.1.1.1 (10639872/128256), Serial1 P 192.1.2.0/24, 1 successors, FD is 10537472 via 192.1.1.1 (10537472/281600), Serial1
Notez la commande ip summary-address eigrp sous l'interface Serial0 et la route récapitulative via Null0. Sur le routeur un, nous voyons cela comme route interne :
one# show ip eigrp topology IP-EIGRP Topology Table for process 2000 Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - Reply status P 10.1.10.0/24, 1 successors, FD is 46354176 via 10.1.50.1 (46354176/45842176), Serial0 P 10.1.50.0/24, 1 successors, FD is 2169856 via Connected, Serial0 P 192.1.0.0/22, 1 successors, FD is 11023872 via 10.1.50.1 (11023872/10511872), Serial0
EIGRP ne récapitulerons pas automatiquement des routes externes à moins qu'il y ait un composant du même réseau principal qui soit une route interne. Pour illustrer, observons le schéma 15.
Le routeur trois injecte des routes externes à 192.1.2.0/26 et à 192.1.2.64/26 dans EIGRP en utilisant la commande redistribute connected, suivant les indications des configurations ci-dessous.
Routeur trois
interface Ethernet0 ip address 192.1.2.1 255.255.255.192 ! interface Ethernet1 ip address 192.1.2.65 255.255.255.192 ! interface Ethernet2 ip address 10.1.2.1 255.255.255.0 !router eigrp 2000 redistribute connected network 10.0.0.0 default-metric 10000 1 255 1 1500
Avec cette configuration sur le routeur trois, la table de routage sur le routeur un affiche :
one# show ip route .... 10.0.0.0/8 is subnetted, 2 subnets D 10.1.2.0 [90/11023872] via 10.1.50.2, 00:02:03, Serial0 C 10.1.50.0 is directly connected, Serial0 192.1.2.0/26 is subnetted, 1 subnets D EX 192.1.2.0 [170/11049472] via 10.1.50.2, 00:00:53, Serial0 D EX 192.1.2.64 [170/11049472] via 10.1.50.2, 00:00:53, Serial0
Bien qu'un résumé automatique conduit normalement le routeur trois à récapituler les routes 192.1.2.0/26 et 192.1.2.64/26 dans une destination de réseau principal (192.1.2.0/24), il ne le fait pas parce que les deux routes sont externes. Cependant, si vous reconfigurez la liaison entre les routeurs deux et trois sur 192.1.2.128/26, et ajoutez des instructions réseau pour ce réseau sur les routeurs deux et trois, le résumé automatique 192.1.2.0/24 est alors généré sur le routeur deux.
Routeur trois
interface Ethernet0 ip address 192.1.2.1 255.255.255.192 ! interface Ethernet1 ip address 192.1.2.65 255.255.255.192 ! interface Serial0 ip address 192.1.2.130 255.255.255.192 ! router eigrp 2000 network 192.1.2.0
À présent, le routeur deux génère le résumé pour 192.1.2.0/24 :
two# show ip route .... D 192.1.2.0/24 is a summary, 00:06:48, Null0 ....
Et le routeur un montre seulement la route récapitulative :
one# show ip route .... 10.0.0.0/8 is subnetted, 1 subnets C 10.1.1.0 is directly connected, Serial0 D 192.1.2.0/24 [90/11023872] via 10.1.50.2, 00:00:36, Serial0
Quand un routeur traite la requête d'un voisin, les règles suivantes s'appliquent :
Requête de | État de la route | Action |
---|---|---|
voisin (pas le successeur actuel) | passif | répondre avec les informations actuelles du successeur |
successeur | passif | tente de rechercher le nouveau successeur ; en cas de succès, répondre avec les nouvelles informations ; sinon, marquer la destination comme inaccessible et questionner tous les voisins excepté le précédent successeur |
tout voisin | aucun chemin via ce voisin avant la requête | répondre avec le meilleur chemin actuel connu |
tout voisin | non connu avant la requête | répondre que la destination est inaccessible |
voisin (pas le successeur actuel) | actif | s'il n'y a aucun successeur actuel vers cette destination (normalement ce serait vrai), répondre avec inaccessible |
s'il y a un bon successeur, répondre avec les informations de chemin actuel | ||
successeur | actif | tente de rechercher le nouveau successeur ; en cas de succès, répondre avec les nouvelles informations ; sinon, marquer la destination comme inaccessible et questionner tous les voisins excepté le précédent successeur |
Les actions figurant dans la table ci-dessus ont une conséquence sur la portée de la requête dans le réseau en déterminant combien de routeurs reçoivent et répondent à la requête avant que le réseau ne converge sur la nouvelle topologie. Pour voir comment ces règles affectent la façon dont les requêtes sont traitées, examinons le réseau dans la Figure 16, qui fonctionne dans des conditions normales.
Nous pouvons nous attendre à ce que les éléments suivants se produisent concernant le réseau 192.168.3.0/24 (côté le plus à droite) :
le routeur un a deux chemins vers 192.168.3.0/24 :
via le routeur deux avec une distance de 46533485 et une distance relevée de 20307200 ;
via le routeur trois avec une distance de 20563200 et une distance relevée de 20307200 ;
le routeur un choisit le chemin via le routeur trois et conserve le chemin via le routeur deux comme successeur possible ;
les routeurs deux et trois montrent un chemin vers 192.168.3.0/24 via le routeur quatre.
Supposons que 192.168.3.0/24 échoue. Quelle activité pouvons-nous attendre sur le réseau ? Les schémas 16a à 16h montrent le processus.
Le routeur cinq marque 192.168.3.0/24 comme inaccessible, et questionne le routeur quatre :
Le routeur quatre, à la réception d'une requête de son successeur, tente de rechercher un nouveau successeur possible pour ce réseau. Il n'en trouve pas, il marque alors 192.168.3.0/24 comme inaccessible et questionne les routeurs deux et trois :
Les routeurs deux et trois, à leur tour, voient qu'ils ont détruit leur seule route praticable vers 192.168.3.0/24, et le marquent comme inaccessible ; chacun d'eux envoie des requêtes au routeur un :
Pour plus de simplicité, supposons que le routeur un reçoit la requête du routeur trois en premier, et marque la route comme inaccessible. Le routeur un reçoit alors la requête du routeur deux. Bien qu'un autre ordre soit possible, ils obtiendront tous le même résultat final.
Le routeur un répond aux deux requêtes avec des marques d'inaccessibilité ; Le routeur un est maintenant passif pour 192.168.3.0/24 :
Les routeurs deux et trois répondent à la requête du routeur quatre ; Les routeurs deux et trois sont maintenant passifs pour 192.168.3.0/24 :
Le routeur cinq, lors de la réception de la réponse du routeur quatre, supprime le réseau 192.168.3.0/24 de sa table de routage ; Le routeur cinq est maintenant passif pour le réseau 192.168.3.0/24. Le routeur cinq renvoie des mises à jour au routeur quatre, la route est alors supprimée de la topologie et les tables de routage aux routeurs restants.
Bien qu'il puisse y avoir d'autres chemins de requête ou ordres de traitement, tous les routeurs du réseau traitent une requête pour le réseau 192.168.3.0/24 quand cette liaison s'arrête. Certains routeurs peuvent finir par traiter plus d'une requête (routeur un dans cet exemple). En fait, si les requêtes consistaient à atteindre les routeurs dans un ordre différent, certains finiraient par traiter trois ou quatre requêtes. Voici un bon exemple d'une requête illimitée dans un réseau EIGRP.
Maintenant observons les chemins vers 10.1.1.0/24 dans le même réseau :
Le routeur deux a une entrée de table de topologie pour le réseau 10.1.1.0/24 avec un coût de 46251885 via le routeur un.
Le routeur trois a une entrée de table de topologie pour le réseau 10.1.1.0/24 avec un coût de 20281600 via le routeur un.
Le routeur quatre a une entrée de table de topologie pour le réseau 10.0.0.0/8 (parce que les routeurs deux et trois résument automatiquement à la limite du réseau principal) via le routeur trois avec une métrique de 20307200 (la distance relevée via le routeur deux est plus élevée que la métrique totale via le routeur trois, ainsi le chemin via le routeur deux n'est pas un successeur possible).
Si 10.1.1.0/24 s'arrête, le routeur un le marque comme inaccessible, puis questionne chacun de ses voisins (les routeurs deux et trois) pour un nouveau chemin vers ce réseau :
Le routeur deux, à la réception de la requête du routeur un, marque la route comme inaccessible (parce que la requête provient de son successeur) et questionne alors les routeurs quatre et trois :
Le routeur trois, quand il reçoit la requête du routeur un, marque la destination comme inaccessible et questionne les routeurs deux et quatre :
Le routeur quatre, quand il reçoit les requêtes des routeurs deux et trois, répond que 10.1.1.0/24 est inaccessible (notez que le routeur quatre n'a aucune connaissance du sous-réseau en question, puisqu'il a seulement la route 10.0.0.0/8) :
Les routeurs deux et trois se répondent entre eux que 10.1.1.0/24 est inaccessible :
Puisque les routeurs deux et trois n'ont maintenant aucune requête en attente, ils répondent tous les deux au routeur une que 10.1.1.0/24 est inaccessible :
La requête, dans ce cas, est limitée par les routeurs de récapitulation automatique deux et trois. Le routeur cinq ne participe pas au processus de requête, et n'est pas impliqué dans la reconvergence du réseau. Les requêtes peuvent également être limitées par la récapitulation manuelle, les frontières du système autonome et les listes de distribution.
Si un routeur redistribue des routes entre deux systèmes autonomes EIGRP, il répond à la requête dans les règles de traitement normales et lance une nouvelle requête dans l'autre système autonome. Par exemple, si la liaison au réseau attaché au routeur trois s'arrête, le routeur trois marque la route comme inaccessible et questionne le routeur deux pour un nouveau chemin :
Le routeur deux répond que ce réseau est inaccessible et lance une requête dans le système autonome 200 vers le routeur un. Une fois que le routeur trois reçoit la réponse à sa requête initiale, elle supprime la route de sa table. Le routeur trois est maintenant passif pour ce réseau :
Le routeur un répond au routeur deux et la route devient passive :
Tandis que la requête initiale ne se propageait pas dans le réseau (elle était limitée par la frontière du système autonome), la requête initiale fuit dans le deuxième système autonome sous la forme d'une nouvelle requête. Cette technique peut contribuer à empêcher les problèmes de routes bloquées en actif (SIA) dans un réseau en limitant le nombre de routeurs qu'une requête doit passer avant de recevoir une réponse, mais elle ne résout pas le problème global, à savoir que chaque routeur doit traiter la requête. En fait, cette méthode de limitation d'une requête peut faire empirer le problème en empêchant la récapitulation automatique des routes qui pourraient être récapitulées (des routes externes ne sont pas récapitulées à moins qu'il y ait un composant externe dans ce réseau principal).
Plutôt que de bloquer la propagation d'une requête, des listes de distribution dans EIGRP marquent n'importe quelle réponse de requête comme inaccessible. Utilisons comme exemple le schéma 19.
Dans la figure ci-dessus :
Le routeur trois a une liste de distribution appliquée à ses interfaces série qui lui permet seulement d'annoncer le réseau B.
Les routeurs un et deux ne savent pas que le réseau A est accessible via le routeur trois (le routeur trois n'est pas utilisé comme point de transit entre les routeurs un et deux).
Le routeur trois utilise le routeur un en tant que chemin préférentiel vers le réseau A, et n'utilise pas le routeur deux comme successeur possible.
Lorsque le routeur un perd sa connexion au réseau A, il marque la route comme inaccessible et envoie une requête au routeur trois. Le routeur trois n'annonce pas un chemin vers le réseau A en raison de la liste de distribution sur ses ports série.
Le routeur trois marque la route comme inaccessible, puis questionne le routeur deux :
Le routeur deux examine sa table de topologie et détecte qu'elle a une connexion valide au réseau A. Notez que la requête n'a pas été affectée par la liste de distribution dans le routeur trois :
Le routeur deux répond que le réseau A est accessible ; Le routeur trois a maintenant une route valide :
Le routeur trois établit la réponse à la requête à partir du routeur un, mais la liste de distribution conduit le routeur trois à répondre que le réseau A est inaccessible, même si le routeur trois a une route valide vers le réseau A :
Certains protocoles de routage consomment toute la bande passante disponible sur une liaison à faible bande passante tandis qu'ils convergent (s'adaptant à un changement du réseau). EIGRP évite cet encombrement en régulant la vitesse à laquelle les paquets sont transmis sur un réseau, utilisant de ce fait seulement une partie de la bande passante disponible. La configuration par défaut pour EIGRP est d'utiliser jusqu'à 50 percent de la bande passante disponible, mais cela peut être changé avec la commande suivante :
router(config-if)# ip bandwidth-percent eigrp 2 ? <1-999999> Maximum bandwidth percentage that EIGRP may use
En résumé, chaque fois que EIGRP met en file d'attente un paquet à transmettre sur une interface, il emploie la formule suivante pour déterminer le temps d'attente avant l'envoi du paquet :
(8 * 100 * taille de paquet en octets) / (bande passante en kbps * pourcentage de bande passante)
Par exemple, si EIGRP met en file d'attente un paquet à envoyer sur une interface série qui a une bande passante de 56 K, et que le paquet est de 512 octets, EIGRP attend :
(8 * 100 * 512 octets)/(56000 bits par seconde * 50 % de bande passante) (8 * 100 * 512)/(56000 * 50) 409600/2800000 0,1463 secondes
Cela permet à un paquet (ou à des groupes de paquets) de 512 octets au moins d'être transmis sur cette liaison avant qu'EIGRP n'envoie son paquet. Le temporisateur de régulation détermine quand le paquet est envoyé, et est exprimé généralement en millisecondes. Le temps de régulation pour le paquet, dans l'exemple qui précède, est de 0,1463 secondes. Il y a un champ dans show ip eigrp interface qui affiche le temporisateur de régulation, comme affiché ci-dessous :
router# show ip eigrp interface IP-EIGRP interfaces for process 2 Xmit Queue Mean Pacing Time Multicast Pending Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes Se0 1 0/0 28 0/15 127 0 Se1 1 0/0 44 0/15 211 0 router#
L'heure affichée est l'intervalle de régulation pour l'unité de transmission maximale (MTU), le plus grand paquet qui peut être envoyé sur l'interface.
Il y a deux manières d'injecter une route par défaut dans EIGRP : redistribuer une route statique ou récapituler à 0.0.0.0/0. Utilisez la première méthode quand vous voulez diriger tout le trafic aux destinations inconnues vers une route par défaut au cœur du réseau. Cette méthode est efficace pour annoncer des connexions sur Internet. Exemple :
ip route 0.0.0.0 0.0.0.0 x.x.x.x (next hop to the internet) ! router eigrp 100 redistribute static default-metric 10000 1 255 1 1500
La route statique qui est redistribuée dans EIGRP ne doit pas l'être au réseau 0.0.0.0. Si vous utilisez un autre réseau, vous devez employer la commande ip default-network pour marquer le réseau comme réseau par défaut. Référez-vous à Configuration d'une passerelle de dernier recours à l'aide de commandes IP pour plus d'informations.
La récapitulation à une route par défaut est pertinente seulement quand vous voulez fournir à des sites distants une route par défaut. Puisque des résumés sont configurés par interface, vous n'avez pas besoin d'employer des listes de distribution ou d'autres mécanismes pour empêcher la route par défaut d'être propagée vers le cœur de votre réseau. Notez qu'une récapitulation à 0.0.0.0/0 remplace une route par défaut connue à partir de tout autre protocole de routage. La seule façon de configurer une route par défaut sur un routeur utilisant cette méthode est de configurer une route statique sur 0.0.0.0/0. (À partir du logiciel Cisco IOS 12.0(4)T, vous pouvez également configurer une distance administrative à la fin de la commande ip summary-address eigrp, de sorte que le résumé local ne remplace pas la route 0.0.0.0/0).
router eigrp 100 network 10.0.0.0 ! interface serial 0 encapsulation frame-relay no ip address ! interface serial 0.1 point-to-point ip address 10.1.1.1 frame-relay interface-dlci 10 ip summary-address eigrp 100 0.0.0.0 0.0.0.0
EIGRP met en place jusqu'à quatre routes de coût égal dans la table de routage, dont la charge est alors équilibrée par le routeur. Le type d'équilibrage de charge (par paquet ou par destination) dépend du type de commutation actuellement effectué dans le routeur. EIGRP, cependant, peut également équilibrer la charge sur des liaisons de coût inégal.
Note: Utilisant max-paths, vous pouvez configurer EIGRP afin qu'il utilise jusqu'à six routes de coût égal.
Disons qu'il existe quatre chemins vers une destination donnée, et les métriques pour ces chemins sont :
chemin 1 : 1100
chemin 2 : 1100
chemin 3 : 2000
chemin 4 : 4000
Le routeur, par défaut, place le trafic sur le chemin 1 et 2. En utilisant EIGRP, vous pouvez employer la commande variance pour indiquer au routeur de placer également du trafic sur les chemins 3 et 4. La variance est un multiplicateur : le trafic sera placé sur toute liaison dotée d'une métrique inférieure au meilleur chemin multiplié par la variance. Pour équilibrer la charge entre les chemins 1, 2 et 3, utilisez la variance 2, car 1100 x 2 = 2200 est supérieure à la métrique via le chemin 3. De même, pour ajouter le chemin 4, émettez la variance 4 sous la commande router eigrp. Référez-vous à Comment fonctionne l'équilibrage de charge à coût inégal (Variance) dans IGRP et EIGRP ? pour plus d'informations.
Comment le routeur divise-t-il le trafic entre ces chemins ? Il divise la métrique via chaque chemin par la plus grande métrique, arrondit au nombre entier le plus proche et utilise le résultat obtenu comme nombre de répartition du trafic.
router# show ip route 10.1.4.0 Routing entry for 10.1.4.0/24 Known via "igrp 100", distance 100, metric 12001 Redistributing via igrp 100, eigrp 100 Advertised by igrp 100 (self originated) eigrp 100 Last update from 10.1.2.2 on Serial1, 00:00:42 ago Routing Descriptor Blocks: * 10.1.2.2, from 10.1.2.2, 00:00:42 ago, via Serial1 Route metric is 12001, traffic share count is 1 Total delay is 20010 microseconds, minimum bandwidth is 1000 Kbit Reliability 1/255, minimum MTU 1 bytes Loading 1/255, Hops 0
Pour cet exemple, les nombres de répartition du trafic sont :
pour les chemins 1 et 2 : 4000/1100 = 3
pour le chemin 3 : 4000/2000 = 2
pour le chemin 4 : 4000/4000 = 1
Le routeur envoie les trois premiers paquets sur le chemin 1, les trois paquets suivants sur le chemin 2, les deux paquets suivants sur le chemin 3 et le paquet suivant sur le chemin 4. Le routeur redémarre alors en envoyant les trois paquets suivants sur le chemin 1, etc.
Note: Même avec la variance configurée, EIGRP n'enverra pas de trafic sur un chemin à coût inégal si la distance relevée est supérieure à la distance acceptable pour cette route particulière. Référez-vous à la section « Distance possible, Distance signalée et successeurs possibles » pour plus d'informations.
Quand vous commencez à configurer EIGRP, si vous essayez d'influencer les métriques EIGRP, rappelez-vous ces deux règles de base :
La bande passante devrait toujours être configurée selon la bande passante réelle de l'interface ; les liaisons série multipoints et d'autres situations de vitesse du support mal adaptées sont les exceptions à cette règle.
Le retard devrait toujours être utilisé pour influencer les décisions de routage EIGRP.
Puisqu'EIGRP emploie la bande passante de l'interface pour déterminer le débit d'envoi des paquets, il est important que ces derniers soient correctement configurés. S'il est nécessaire d'influencer le chemin qu'EIGRP choisit, utilisez toujours le retard dans cette optique.
Si elle est plus faible, la bande passante a plus d'influence sur la métrique totale ; Si la bande passante est plus élevée, le retard a plus d'influence sur la métrique totale.
Les balises administratives externes sont utiles pour rompre les boucles de routage de redistribution entre EIGRP et d'autres protocoles. En balisant la route quand elle est redistribuée dans EIGRP, vous pouvez bloquer la redistribution à partir d'EIGRP dans le protocole externe. Il n'est pas possible de modifier la distance administrative pour une passerelle par défaut qui a été connue à partir d'une route externe car, dans EIGRP, la modification de la distance administrative s'applique seulement dans le cas de routes internes. Afin d'élever la métrique, utilisez une carte de route avec la liste de préfixes ; ne changez pas la distance administrative. Un exemple de base de configuration de ces balises apparaît ci-dessous, mais cet exemple ne montre pas la configuration entière utilisée pour rompre les boucles de redistribution.
Le routeur trois, qui redistribue des routes connectées dans EIGRP, affiche :
three# show run .... interface Loopback0 ip address 172.19.1.1 255.255.255.0 ! interface Ethernet0 ip address 172.16.1.1 255.255.255.0 loopback no keepalive ! interface Serial0 ip address 172.17.1.1 255.255.255.0 .... router eigrp 444 redistribute connected route-map foo network 172.17.0.0 default-metric 10000 1 255 1 1500 .... access-list 10 permit 172.19.0.0 0.0.255.255 route-map foo permit 10 match ip address 10 set tag 1 .... three# show ip eigrp topo IP-EIGRP Topology Table for process 444 Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - Reply status P 172.17.1.0/24, 1 successors, FD is 2169856 via Connected, Serial0 via Redistributed (2169856/0) P 172.16.1.0/24, 1 successors, FD is 281600 via Redistributed (281600/0) P 172.19.1.0/24, 1 successors, FD is 128256, tag is 1 via Redistributed (128256/0)
Le routeur deux, qui redistribue des routes à partir d'EIGRP dans RIP, affiche :
two# show run .... interface Serial0 ip address 172.17.1.2 255.255.255.0 ! interface Serial1 ip address 172.18.1.3 255.255.255.0 .... router eigrp 444 network 172.17.0.0 ! router rip redistribute eigrp 444 route-map foo network 10.0.0.0 network 172.18.0.0 default-metric 1 ! no ip classless ip route 1.1.1.1 255.255.255.255 Serial0 route-map foo deny 10 match tag 1 ! route-map foo permit 20 .... two# show ip eigrp topo IP-EIGRP Topology Table for process 444 Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - Reply status P 172.17.1.0/24, 1 successors, FD is 2169856 via Connected, Serial0 P 172.16.1.0/24, 1 successors, FD is 2195456 via 172.17.1.1 (2195456/281600), Serial0 P 172.19.1.0/24, 1 successors, FD is 2297856, tag is 1 via 172.17.1.1 (2297856/128256), Serial0
Notez la balise 1 sur 172.19.1.0/24.
Le routeur un, qui reçoit les routes RIP redistribuées par le routeur 2, affiche :
one# show run .... interface Serial0 ip address 172.18.1.2 255.255.255.0 no fair-queue clockrate 1000000 router rip network 172.18.0.0 .... one# show ip route Gateway of last resort is not set R 172.16.0.0/16 [120/1] via 172.18.1.3, 00:00:15, Serial0 R 172.17.0.0/16 [120/1] via 172.18.1.3, 00:00:15, Serial0 172.18.0.0/24 is subnetted, 1 subnets C 172.18.1.0 is directly connected, Serial0
Notez que 172.19.1.0/24 manque.
Cette commande permet d'afficher des informations sur les configurations nommées EIGRP et les configurations de système autonome EIGRP. Le résultat de cette commande montre les informations échangées entre le routeur EIGRP voisin. Une explication de chaque champ de sortie suit la table.
show ip eigrp traffic |
---|
|
Explications de configuration
Les paquets envoyés/reçus indiquent le nombre de paquets Hello envoyés et reçus (envoyés -1927/reçus - 1930).
Mises à jour envoyées/reçues affiche le nombre de paquets de mise à jour envoyés et reçus (sent-20/ived-39).
Requêtes envoyées/reçues signifie le nombre de paquets de requête envoyés et reçus (sent-10/ived-18).
Les réponses envoyées/reçues indiquent le nombre de paquets de réponse envoyés et reçus (sent-18/ived-16).
Acks envoyés/reçus signifie le nombre de paquets d'accusé de réception envoyés et reçus (sent-66/ived-41).
Les requêtes SIA envoyées/reçues signifient le nombre de paquets bloqués dans les paquets de requête actifs envoyés et reçus (sent-0/ived-0).
SIA-Réponses envoyées/reçues affiche le nombre de paquets bloqués dans les paquets de réponse actifs envoyés et reçus (sent-0/ived-0).
L'ID de processus Hello est l'identificateur de processus Hello (270).
PDM Process ID désigne l'identificateur de processus IOS du module dépendant du protocole (251).
Socket Queue affiche les compteurs de file d'attente de socket IP to EIGRP Hello Process (current-0/max-2000/high-1/drops-0).
Input Queue affiche les compteurs de file d'attente de socket PDM EIGRP Hello Process (current-0/max-2000/high-1/drops-0).
Cette commande affiche seulement les successeurs possibles. Pour afficher toutes les entrées dans la table de topologie, utilisez la commande show ip eigrp topology all-links . Une explication de chaque champ de sortie suit la table.
show ip eigrp topology |
---|
|
Explications de configuration
A signifie actif. P peut aussi être affiché, signifiant passif.
10.2.4.0/24 est la destination ou le masque.
0 successors montre combien de successeurs (ou chemins) sont disponibles pour cette destination ; si des successeurs sont capitalisés, la route est en cours de transition.
FD is 512640000 montre la distance acceptable, qui est la meilleure métrique pour atteindre cette destination ou la meilleure métrique connue quand la route est devenue active.
tag is 0x0 peut être configuré et/ou filtré en utilisant les cartes de route avec les commandes set tag et match tag.
Q signifie qu'une requête est en attente. Ce champ peut également être : U, pour une mise à jour en attente ; ou R, pour la réponse en attente.
1 replies affiche le nombre de réponses en attente.
active 00:00:01 affiche combien de temps cette route a été active.
query origin: Local origin montre que cette route est à l'origine de la requête. Ce champ peut également être : Multiple origins, signifiant que plusieurs voisins ont envoyé des requêtes sur cette destination, mais pas le successeur ; ou Successor origin, signifiant que le successeur a lancé la requête.
via 10.1.2.2 montre que nous avons connu cette route par un voisin dont l'adresse IP est 10.1.2.2. Ce champ peut également être : Connected, si le réseau est directement connecté à ce routeur ; Redistributed, si cette route est redistribuée dans EIGRP sur ce routeur ; ou Summary, si c'est une route récapitulative générée sur ce routeur.
(Infinity/Infinity) montre la métrique pour atteindre ce chemin via ce voisin dans le premier champ, et la distance relevée via ce voisin dans le second champ.
r montre que nous avons questionné ce voisin et attendons une réponse.
Q est la balise d'envoi pour cette route, signifiant qu'une requête est en attente. Ce champ peut également être : U, signifiant qu'une mise à jour est en attente ; ou R, signifiant qu'une réponse est en attente.
Serial1 est l'interface par laquelle le voisin est accessible.
Via 10.1.1.2 montre le voisin duquel une réponse est attendue.
r montre que nous avons questionné ce voisin au sujet de la route et que nous n'avons pas encore reçu de réponse.
Serial0 est l'interface par laquelle le voisin est accessible.
Via 10.1.2.2 (512640000/128256), Serial1 montre que nous utilisons cette route (indique quel chemin le prochain chemin/destination prendra quand plusieurs routes de coût égal seront disponibles).
Cette commande affiche toutes les entrées dans la table de topologie pour cette destination, pas simplement des successeurs possibles. Une explication de chaque champ de sortie suit la table.
show ip eigrp topology network |
---|
|
Explications de configuration
State is Passive signifie que l'état du réseau est passif ou, en d'autres termes, que nous ne recherchons pas un chemin vers ce réseau. Les routes sont presque toujours dans un état passif dans les réseaux stables.
Query origin flag is 1 Si cette route est active, ce champ fournit des informations en fonction de l'initiateur de la requête.
0: cette route est active mais aucune requête n'a été lancée pour elle (nous recherchons un successeur possible localement).
1: Ce routeur a lancé la requête pour cette route (ou la route est passive).
2: plusieurs calculs de diffusion pour cette requête. Ce routeur a reçu plus d'une requête pour cette route de plus d'une source.
3: Le routeur par lequel nous avons connu le chemin vers ce réseau recherche une autre route.
4: plusieurs sources de requête pour cette route, y compris le routeur par lequel nous avons connu cette route. Semblable à 2, mais signifie également qu'il y a une chaîne d'origine de requête qui décrit les requêtes en attente pour ce chemin.
2 Successeur(s) signifie qu'il existe deux chemins possibles vers ce réseau.
FD is 307200 montre la meilleure métrique actuelle vers ce réseau. Si la route est active, cela indique la métrique du chemin que nous utilisions précédemment pour router des paquets vers ce réseau.
Routing Descriptor Blocks Chacune des entrées suivantes décrit un chemin vers le réseau.
10.1.1.2 (Ethernet1) est le saut suivant vers le réseau et l'interface par laquelle le saut suivant est atteint.
from 10.1.2.2 est la source de ces informations de chemin.
Send flag is :
0x0 : si des paquets doivent être envoyés par rapport à cette entrée, ceci indique le type de paquet.
0x1 : Ce routeur a reçu une requête pour ce réseau, et doit envoyer une réponse de monodiffusion.
0x2 : Cette route est active et une requête de multidiffusion doit être envoyée.
0x3 : Cette route a changé et une mise à jour de multidiffusion doit être envoyée.
Composite metric is (307200/281600) montre les coûts calculés totaux sur le réseau. Le premier nombre entre parenthèses est le coût total du réseau via ce chemin, y compris le coût au prochain saut. Le second nombre entre parenthèses est la distance relevée, ou, en d'autres termes, le coût que le routeur du prochain saut utilise.
Route is Internal signifie que cette route a été lancé dans ce système autonome EIGRP (AS). Si la route a été redistribuée dans cet AS EIGRP, ce champ indique que la route est externe.
Vector metric montre les métriques individuelles utilisées par EIGRP pour calculer le coût pour un réseau. EIGRP ne propage pas les informations de coût total dans tout le réseau ; les métriques de vecteurs sont propagées et chaque routeur calcule le coût et la distance relevée individuellement.
Minimum bandwidth is 10000 Kbit montre la bande passante la plus faible sur le chemin vers ce réseau.
Total delay is 2000 microseconds montre la somme des retards sur le chemin vers ce réseau.
Reliability is 0/255 montre un facteur de fiabilité. Ce nombre est calculé dynamiquement, mais n'est pas utilisé par défaut dans les calculs de métriques.
Load is 1/255 indique la quantité de charge que la liaison porte. Ce numéro est calculé dynamiquement et n'est pas utilisé par défaut quand EIGRP calcule le coût d'utilisation de ce chemin.
Minimum MTU is 1500 Ce champ n'est pas utilisé dans des calculs de métriques.
Hop count is 2 Cela n'est pas utilisé dans des calculs de métriques, mais limite la taille maximale d'un AS EIGRP. Le nombre maximal de sauts qu'EIGRP acceptera est 100 par défaut, bien que le maximum puisse être configuré sur 220 avec des sauts de métriques maximales.
Si la route est externe, les informations suivantes sont incluses. Une explication de chaque champ de sortie suit la table.
Route externe |
---|
|
Explications de configuration
Originating Router montre le routeur qui a injecté cette route dans le AS EIGRP.
External AS montre au système autonome d'où provient la route (le cas échéant).
External Protocol montre au protocole d'où provient la route (le cas échéant).
external metric montre les métriques internes dans le protocole externe.
Administrator Tag peut être configuré et/ou filtré en utilisant les cartes de route avec les commandes set tag et match tag.
Format de sortie semblable à show ip eigrp topology, mais montre également une certaine partie de la table de topologie.
Format de sortie semblable à show ip eigrp topology, mais montre également tous les liens dans la table de topologie, au lieu des seuls successeurs possibles.