Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
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.
Ce document décrit comment utiliser le protocole de passerelle intérieure appelé Enhanced Interior Gateway Routing Protocol (EIGRP).
Aucune spécification déterminée n'est requise pour ce document.
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Dans un réseau bien conçu, le protocole EIGRP évolue bien et offre des temps de convergence extrêmement rapides avec un trafic réseau minimal.
Voici quelques-uns des avantages du protocole EIGRP :
Le protocole EIGRP est un protocole à vecteur de distance amélioré qui s’appuie sur l’algorithme DUAL (Diffused Update Algorithm) pour calculer le chemin le plus court vers une destination au sein d’un réseau.
Il existe deux versions principales 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 de ces informations ne s'appliquent pas aux versions antérieures. La dernière version de dans EIGRP est recommandée car elle inclut de nombreuses améliorations en termes de performances et de stabilité.
Un protocole à vecteur de distance type enregistre ces informations lorsqu'il calcule 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 de la Figure 1 exécutent le protocole RIP (Routing Information Protocol). Le routeur deux choisit le chemin vers le réseau A en examinant le nombre de sauts sur chaque chemin disponible.
Figure 1
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). En l'absence de tout temps de mise hors service, il faut entre 90 et 120 secondes au routeur deux pour commuter le chemin du routeur un au routeur trois.
Le protocole EIGRP ne dépend pas de mises à jour périodiques complètes pour reconverger, mais il crée une table topologique à partir de chacune de ses annonces voisines (les données ne sont pas ignorées) et converge en recherchant une route sans boucle probable dans la table topologique ou, s’il ne trouve pas une autre route, il interroge 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). Lorsque le chemin via le routeur un devient indisponible, le routeur deux examine sa table topologique et, lorsqu’il trouve un successeur potentiel, commence immédiatement à utiliser 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 méthode permettant de déterminer quels chemins un routeur a appris sont sans boucle
un processus pour effacer les chemins incorrects des tables de topologie de tous les routeurs sur le réseau ;
Processus de recherche de voisins pour trouver des chemins vers des destinations perdues
Chacune de ces exigences est couverte à tour de rôle.
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.
Si vous envoyez uniquement des mises à jour de routage, vous ne pouvez pas détecter quand un chemin via un routeur adjacent n'est plus disponible. Vous ne pouvez pas expirer les routes et vous attendre à recevoir une nouvelle table de routage de vos voisins. Le protocole EIGRP s’appuie sur les relations de voisinage pour propager les modifications de la table de routage sur le réseau ; deux routeurs deviennent voisins lorsqu’ils voient des paquets Hello 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
les liaisons série point à point, telles que les circuits loués PPP ou HDLC, les sous-interfaces point à point Frame Relay et les sous-interfaces 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. Le temps d’attente est la durée pendant laquelle un routeur considère un voisin comme vivant lorsqu’il ne reçoit pas de paquet Hello. Le temps d'attente est généralement trois fois l'intervalle Hello, par défaut, 15 secondes et 180 secondes. Vous pouvez ajuster la durée d'attente avec la commande ip hold-time eigrp.
Note: Si vous modifiez l'intervalle Hello, le temps d'attente n'est pas automatiquement ajusté pour prendre en compte cette modification. Vous devez ajuster manuellement le temps d'attente pour refléter l'intervalle Hello configuré.
Il est possible que deux routeurs deviennent des voisins EIGRP même si les temporisateurs Hello et d'attente ne correspondent pas. Le temps d'attente est inclus dans les paquets Hello afin que chaque voisin puisse rester en vie même si l'intervalle Hello et les minuteurs d'attente ne correspondent pas. Bien qu'il n'y ait aucun moyen direct de déterminer quel est 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 adjacent.
Si vous disposez de la sortie d'une commande show ip eigrp neighbors de votre périphérique Cisco, vous pouvez utiliser l'analyseur CLI Cisco pour afficher les problèmes potentiels et les correctifs, si JavaScript est 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 de la colonne Attente du résultat de la commande ne doit jamais dépasser le temps d'attente et ne doit jamais être inférieure au temps d'attente moins l'intervalle Hello (sauf si, bien sûr, vous perdez des paquets Hello). Si la colonne Attente est généralement comprise entre 10 et 15 secondes, l'intervalle Hello est de 5 secondes et le temps d'attente est de 15 secondes. Si la colonne Attente a généralement une plage plus large (entre 120 et 180 secondes), l'intervalle Hello est de 60 secondes et le temps d'attente est de 180 secondes. Si les numéros ne semblent pas correspondre à l'un des paramètres de minuteur par défaut, vérifiez l'interface en question sur le routeur voisin. Les minuteurs Hello et de mise en attente ont peut-être été configurés manuellement.
Remarque : le protocole EIGRP ne crée pas de relations d'homologues sur les adresses secondaires. Tout le trafic EIGRP est originaire de l'adresse principale de l'interface.
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 des capacités du périphérique, telles que :
la capacité mémoire,
le pouvoir de traiter
la quantité d'informations échangées, telle que le nombre de routes envoyées,
la complexité de topologie,
la stabilité du réseau.
Maintenant que ces routeurs communiquent 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 topologique sur un routeur qui exécute EIGRP, émettez la commande show ip eigrp topology. La table topologique contient les informations nécessaires à la création d’un ensemble de distances et de vecteurs vers chaque réseau accessible, ainsi que :
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).
Si vous disposez de la sortie d'une commande show ip eigrp topology de 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. Il n'est pas recommandé de configurer d'autres métriques 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, le routeur un calcule le chemin vers le réseau A.
Figure 2
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.
Calculez les mesures. Le protocole EIGRP calcule la métrique totale lorsqu’il adapte la bande passante et les métriques de délai. Le protocole EIGRP utilise cette formule 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.
Le protocole EIGRP utilise cette formule pour faire évoluer le délai :
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. Le délai est utilisé car il s’affiche 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: Les valeurs K doivent être utilisées après une planification minutieuse. Les valeurs K non concordantes empêchent la création d'une relation de voisinage, ce qui peut entraîner l'échec de 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 :
inimum 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
Pour atteindre le réseau A, le routeur 1 choisit la route passant par le routeur 3.
Note: Les valeurs de bande passante et de délai utilisées sont celles configurées sur l’interface par laquelle le routeur atteint son tronçon 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 de faisabilité est la meilleure métrique le long d’un chemin vers un réseau de destination, qui inclut la métrique 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 :
Figure 3
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.
Note: Dans chaque cas, le protocole EIGRP calcule la distance annoncée à partir du routeur qui annonce 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. Le protocole EIGRP choisit la route via le routeur trois comme meilleur chemin et utilise la métrique via le routeur trois comme distance de faisabilité. 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, qui utilise la métrique via le routeur quatre comme nouvelle distance de faisabilité. Le réseau converge immédiatement, et les mises à jour vers les voisins en aval sont le seul trafic à partir du protocole de routage.
Le scénario illustré à la Figure 4 est plus complexe.
Figure 4
Il y a deux routes vers le réseau A à partir du routeur un : une via le routeur deux avec une mesure de 46789376 et une autre via le routeur quatre avec une mesure de 20307200. Le routeur un choisit la plus basse de ces deux mesures comme route vers le réseau A, et cette mesure devient la distance de faisabilité. Examinez le chemin via le routeur 2 pour voir s’il est qualifié de successeur potentiel. 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 topologique du routeur un à ce stade (utilisez show ip eigrp topology), vous ne verriez qu'une seule entrée pour le réseau A - via le routeur quatre. (En réalité, il y a deux entrées dans la table topologique au niveau du routeur un, mais une seule est un successeur potentiel, donc l'autre n'est pas affichée dans show ip eigrp topology ; vous pouvez voir les routes qui ne sont pas des successeurs possibles avec show ip eigrp topology all-links).
Supposez que la liaison entre le routeur un et le routeur quatre est interrompue. Le routeur un constate qu’il a perdu sa seule route vers le réseau A et interroge chacun de ses voisins (dans ce cas, uniquement le routeur deux) pour voir s’ils disposent d’une route vers le réseau A. Comme le routeur deux dispose d’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 la Figure 4a, le routeur trois examine les routes vers le réseau A. Puisque le découpage d'horizon est désactivé (par exemple, s'il s'agit d'interfaces Frame Relay 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).
Figure 4a
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 est interrompue, le routeur trois pense qu’il peut accéder au réseau A par l’un des autres chemins, mais en raison des règles permettant de déterminer les successeurs potentiels, il n’utilise jamais ces chemins comme alternatives. Examinez les indicateurs 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
Comme le chemin via le routeur quatre présente 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 interroge chacun de ses voisins à la recherche d’une route alternative vers le réseau A. Le routeur deux reçoit la requête et, puisque 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 1 et 2 ont marqué la route comme inaccessible et interrogé chacun de leurs autres voisins pour tenter 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, le découpage d'horizon n'indique pas comment le protocole EIGRP utilise la distance de faisabilité et la distance annoncé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 d’examiner en détail la manière dont le protocole EIGRP utilise le découpage d’horizon, examinez ce qu’est le découpage d’horizon 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 1 est connecté aux Routeurs 2 et 3 via une interface multipoint unique (telle que Frame Relay) et que le Routeur 1 a appris l'existence du Réseau A à partir du Routeur 2, il n'annonce pas la route vers le Réseau A de retour à la même interface vers le Routeur 3. Le routeur un suppose que le routeur trois se renseigne sur le réseau A directement à partir du routeur deux.
Figure 4a
L’antipoison est une autre façon d’éviter les 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.
Par exemple, l'antipoison est activé sur les routeurs de la Figure 4a. 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 (ils échangent des tables topologiques pour la première fois)
un changement de table topologique est annoncé
une requête est envoyée
Examinez chaque cas.
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 ; c'est-à-dire la liaison 56 000 entre les routeurs deux et quatre et la liaison 128 000 entre les routeurs trois et quatre.
Figure 5
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. Comme la règle de découpage d’horizon stipule que vous ne devez jamais annoncer une route à partir de l’interface par laquelle vous en avez pris connaissance, le routeur deux n’envoie normalement pas de mise à jour. Cependant, ceci laisse le routeur un avec une entrée de table de topologie incorrecte.
Lorsqu’un routeur modifie sa table topologique de telle sorte que l’interface par laquelle il atteint le réseau change, il désactive le découpage d’horizon et empoisonne 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 découpage d'horizon uniquement lorsqu'un routeur reçoit une requête ou une mise à jour du successeur qu'il utilise pour la destination dans la requête. Examinez le réseau dans la Figure 6.
Figure 6
Le routeur trois reçoit une requête sur 10.1.2.0/24 (qu’il atteint via le routeur un) 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.
La réponse à une requête peut prendre un certain temps. Si tel est le cas, le routeur qui a émis la requête abandonne et efface sa connexion au routeur qui ne répond pas, ce qui redémarre 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.
Figure 7
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 viables à ce type de problème. La première consiste à augmenter le temps d'attente du routeur après avoir envoyé une requête avant de déclarer le SIA de route. Ce paramètre peut être modifié avec 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 de cet article. 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 du 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 d'une utilisation élevée du processeur).
Le routeur a des problèmes de mémoire et ne peut pas allouer la mémoire pour traiter la requête ou créer le paquet de réponse.
Le circuit entre les deux routeurs n’est pas bon ; il n'y a pas assez de paquets qui passent pour maintenir la relation de voisinage active, mais certaines requêtes ou 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).
Lorsque vous dépannez des routes SIA, utilisez ce processus en trois étapes :
Recherchez les routes qui sont systématiquement signalées comme SIA.
Recherchez le routeur qui ne répond pas systématiquement aux requêtes pour ces routes.
Recherchez la raison pour laquelle le routeur ne reçoit pas ou ne répond pas aux requêtes.
La première étape est facile. Si vous consignez des messages de console, une lecture rapide du journal affiche les routes souvent marquées comme 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). Ces voisins ne peuvent pas apparaître dans la section 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 cette commande plusieurs fois et vous commencez à voir quels voisins ne répondent pas aux requêtes (ou quelles interfaces semblent avoir beaucoup de requêtes sans réponse). Examinez ce voisin pour voir s'il attend toujours des réponses de l'un de ses voisins. Répétez cette procédure 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 plage de requêtes est le problème, n'augmentez pas le minuteur SIA ; réduisez plutôt la plage de requêtes.
Cette section examine différents scénarios impliquant la redistribution. Les exemples répertoriés montrent le minimum requis pour configurer 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, consultez la section Éviter les problèmes dus à la redistribution.
La Figure 8 montre que les routeurs sont configurés comme suit :
Figure 8
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 du protocole EIGRP 1000 sont étiquetées 1000 avant d'être redistribuées vers le protocole 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.
Pour le routeur 1 :
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: 172.16.1.2 (Serial0), from 172.16.1.2, 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 172.16.1.2 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 que le protocole EIGRP conserve toutes les métriques lorsqu'il les redistribue entre deux systèmes autonomes EIGRP.
La redistribution entre EIGRP et d'autres protocoles, par exemple RIP et OSPF, fonctionne de la même manière que toute redistribution. Utilisez la métrique par défaut lorsque vous redistribuez entre les protocoles. Vous devez être conscient de ces deux problèmes lorsque vous redistribuez entre EIGRP et d'autres protocoles :
Les routes redistribuées dans le protocole EIGRP ne sont pas toujours récapitulées. Reportez-vous à la section « Récapitulation » pour obtenir une explication.
Les routes EIGRP externes ont une distance administrative de 170.
Lorsque vous installez une route statique vers une interface et configurez une instruction network avec router eigrp, qui inclut la route statique. Le protocole EIGRP redistribue cette route comme s’il s’agissait d’une interface connectée directement.
Figure 9
Dans la Figure 9, le routeur un a une route statique vers le réseau 172.16.1.0/24 configurée via l'interface Serial 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 les routes statiques, car le protocole EIGRP considère qu’il s’agit d’un réseau connecté directement. 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
La route vers 172.16.1.0/24 apparaît comme une route EIGRP interne sur le routeur 2.
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 10, 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.
Figure 10
Sur le routeur un, il ressemble à ceci :
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.2 (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. La bande passante minimale de cette route est de 256 Ko, bien que des liaisons du réseau 10.0.0.0 aient une bande passante de 56 Ko.
Sur le routeur avec le résumé, une route est construite sur null0 pour l'adresse résumé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 vers 10.0.0.0/8 est marquée comme résumé via Null0. L’entrée de la table topologique pour ce résumé de route ressemble à ceci :
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 2 :
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 172.16.1.2 (46354176/45842176), Serial0 P 10.1.2.0/24, 1 successors, FD is 11049472 via 172.16.1.2 (11049472/10537472), Serial0 P 10.1.1.0/24, 1 successors, FD is 11023872 via 172.16.1.2 (11023872/10511872), Serial0 P 172.16.1.0/24, 1 successors, FD is 2169856 via Connected, Serial0
Le résumé des routes externes fait l'objet de quelques avertissements, qui seront traités plus loin dans la section « Résumé automatique des routes externes ».
Le protocole EIGRP vous permet de récapituler des routes internes et externes sur pratiquement n’importe quelle limite de bit avec une récapitulation manuelle. Par exemple, dans la Figure 11, le routeur deux récapitule 192.168.1.0/24, 192.168.2.0/24 et 192.168.3.0/24 dans le bloc CIDR 192.168.0.0/22.
Figure 11
La configuration du routeur deux est présentée ci-dessous :
two#show run .... ! interface Serial0 ip address 10.1.50.1 255.255.255.0 ip summary-address eigrp 2000 192.168.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.168.1.0/24, 1 successors, FD is 10511872 via Connected, Serial1 P 192.168.0.0/22, 1 successors, FD is 10511872 via Summary (10511872/0), Null0 P 192.168.3.0/24, 1 successors, FD is 10639872 via 192.168.1.1 (10639872/128256), Serial1 P 192.168.2.0/24, 1 successors, FD is 10537472 via 192.168.1.1 (10537472/281600), Serial1
Examinez la commande ip summary-address eigrp sous l’interface Serial0 et la route récapitulative via Null0. Sur le routeur un, ceci est vu comme une 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.168.0.0/22, 1 successors, FD is 11023872 via 10.1.50.1 (11023872/10511872), Serial0
Le protocole EIGRP ne récapitule pas automatiquement les routes externes, sauf si un composant du même réseau principal est une route interne. La Figure 12 illustre ceci :
Figure 12
Le routeur trois injecte des routes externes vers 192.168.2.0/26 et 192.168.2.64/26 dans EIGRP avec la commande redistribute connected, comme indiqué dans les configurations répertoriées.
Routeur trois
interface Ethernet0 ip address 192.168.2.1 255.255.255.192 ! interface Ethernet1 ip address 192.168.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.168.2.0/26 is subnetted, 1 subnets D EX 192.168.2.0 [170/11049472] via 10.1.50.2, 00:00:53, Serial0 D EX 192.168.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.168.2.0/26 et 192.168.2.64/26 dans une destination de réseau principal (192.168.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.168.2.128/26 et ajoutez des instructions réseau pour ce réseau sur les routeurs deux et trois, le résumé automatique 192.168.2.0/24 est alors généré sur le routeur deux.
Routeur trois
interface Ethernet0 ip address 192.168.2.1 255.255.255.192 ! interface Ethernet1 ip address 192.168.2.65 255.255.255.192 ! interface Serial0 ip address 192.168.2.130 255.255.255.192 ! router eigrp 2000 network 192.168.2.0
À présent, le routeur deux génère le résumé pour 192.168.2.0/24 :
two#show ip route .... D 192.168.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.168.2.0/24 [90/11023872] via 10.1.50.2, 00:00:36, Serial0
Lorsqu’un routeur traite une requête d’un voisin, ces règles s’appliquent comme indiqué dans le tableau.
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 pas de successeur actuel vers ces destinations (normalement, cela serait vrai), répondez avec un 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 du tableau précédent ont un impact sur la portée de la requête dans le réseau lorsqu’il découvre combien de routeurs reçoivent et répondent à la requête avant que le réseau converge vers la nouvelle topologie. Pour voir comment ces règles affectent la façon dont les requêtes sont gérées, regardez le réseau dans la Figure 13, qui fonctionne dans des conditions normales.
Figure 13
Ceci est attendu en ce qui concerne le réseau 192.168.3.0/24 (à l’extrême 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. L’activité attendue sur ce réseau est que les figures 13a à 13h illustrent le processus.
Le routeur cinq marque 192.168.3.0/24 comme inaccessible, et questionne le routeur quatre :
Figure 13a
Lorsque le routeur quatre reçoit une requête de son successeur, il tente de trouver un nouveau successeur potentiel 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 :
Figure 13b
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 :
Figure 13c
Supposez que le routeur un reçoit d’abord la requête du routeur trois 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 ont tous le même résultat final.
Figure 13d
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 :
Figure 13e
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 :
Figure 13f
Lorsque le routeur cinq reçoit la réponse du routeur quatre, il supprime le réseau 192.168.3.0/24 de sa table de routage ; Le routeur cinq est désormais passif pour le réseau 192.168.3.0/24. Le routeur cinq renvoie les mises à jour au routeur quatre afin que la route soit supprimée de la topologie et des tables de routage des autres routeurs.
Figure 13g
Bien qu’il puisse y avoir d’autres chemins d’interrogation ou d’autres commandes à traiter, tous les routeurs du réseau traitent une requête pour le réseau 192.168.3.0/24 lorsque cette liaison est interrompue. Certains routeurs peuvent traiter plusieurs requêtes (le routeur un dans cet exemple). En fait, si les requêtes devaient atteindre les routeurs dans un ordre différent, certaines traiteraient trois ou quatre requêtes. Voici un bon exemple d'une requête illimitée dans un réseau EIGRP.
Observez 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 possède une entrée de table topologique pour le réseau 10.0.0.0/8 (car 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 annoncée via le routeur deux est supérieure à la métrique totale via le routeur trois, de sorte que le chemin via le routeur deux n'est pas un successeur potentiel).
Figure 14
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 :
Figure 14a
Le routeur deux, lorsqu’il reçoit la requête du routeur un, marque la route comme inaccessible (car la requête provient de son successeur), puis interroge les routeurs quatre et trois :
Figure 14b
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 :
Figure 14c
Le routeur quatre, lorsqu’il reçoit les requêtes des routeurs deux et trois, répond que 10.1.1.0/24 est inaccessible (le routeur quatre n’a aucune connaissance du sous-réseau en question, car il n’a que la route 10.0.0.0/8) :
Figure 14d
Les routeurs deux et trois se répondent entre eux que 10.1.1.0/24 est inaccessible :
Figure 14e
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 :
Figure 14f
Dans ce cas, la requête est limitée par la récapitulation automatique au niveau des routeurs 2 et 3. 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 normales du processus 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 :
Figure 15a
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 :
Figure 15b
Le routeur un répond au routeur deux et la route devient passive :
Figure 15c
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. Cela permet d'éviter les problèmes de blocage (SIA) dans un réseau, car cela limite le nombre de routeurs par lesquels une requête doit passer avant d'obtenir une réponse. Cependant, elle ne résout pas le problème global avec chaque routeur qui doit traiter la requête. Cette méthode peut aggraver le problème et empêcher la récapitulation automatique des routes qui seraient autrement récapitulées (les routes externes ne sont pas récapitulées sauf s’il y a 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. Utilisez la Figure 16 comme exemple.
Figure 16
Dans la figure 16 :
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 comme chemin préféré vers le réseau A et n’utilise pas le routeur deux comme successeur potentiel.
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.
Figure 16a
Le routeur trois marque la route comme inaccessible, puis questionne le routeur deux :
Figure 16b
Le routeur deux examine sa table de topologie et détecte qu'elle a une connexion valide au réseau A. La requête n'a pas été affectée par la liste de distribution du routeur trois :
Figure 16c
Le routeur deux répond que le réseau A est accessible ; Le routeur trois a maintenant une route valide :
Figure 16d
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 :
Figure 16e
Certains protocoles de routage consomment toute la bande passante disponible sur une liaison à faible bande passante lorsqu’ils convergent (s’adaptent à une modification du réseau). Le protocole EIGRP évite cet encombrement et gère la vitesse à laquelle les paquets sont transmis sur un réseau. Il n’utilise donc qu’une partie de la bande passante disponible. La configuration par défaut du protocole EIGRP consiste à utiliser jusqu’à 50 % de la bande passante disponible, mais vous pouvez la modifier à l’aide de la commande suivante :
router(config-if)# ip bandwidth-percent eigrp 2? <1-999999> Maximum bandwidth percentage that EIGRP can use
Essentiellement, chaque fois qu’EIGRP met en file d’attente un paquet à transmettre sur une interface, il utilise cette formule pour déterminer le délai d’attente avant d’envoyer le paquet :
ip bandwidth-percent eigrp 2
(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) d’au moins 512 octets de transmettre sur cette liaison avant que le protocole EIGRP n’envoie son paquet. Le temporisateur détermine le moment où le paquet est envoyé et est exprimé en millisecondes. Le temps de régulation du paquet dans l'exemple précédent est de 0,1463 seconde. Il y a un champ dans show ip eigrp interface qui affiche le compteur de stimulation :
outer#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 : redistribuez une route statique ou effectuez un résumé vers 0.0.0.0/0. Utilisez la première méthode lorsque vous voulez attirer tout le trafic vers des destinations inconnues vers une route par défaut au coeur du réseau. Cette méthode annonce les connexions à 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 nécessairement être vers le réseau 0.0.0.0. Si vous utilisez un autre réseau, vous devez utiliser la commande ip default-network pour marquer le réseau comme réseau par défaut.
En résumé, une route par défaut ne fonctionne que si vous souhaitez fournir aux sites distants une route par défaut. Puisque les résumés sont configurés par interface, vous pouvez utiliser les listes de distribution ou d'autres mécanismes pour empêcher la propagation de la route par défaut vers le coeur 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 avec cette méthode est de configurer une route statique à 0.0.0.0/0. (Commencez avec le logiciel Cisco IOS 12.0(4)T, et 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
Le protocole EIGRP place jusqu’à quatre routes de coût égal dans la table de routage, que le routeur équilibre ensuite en charge. Le type d’équilibrage de charge (par paquet ou par destination) dépend du type de commutation effectué sur le routeur. Cependant, le protocole EIGRP peut également équilibrer la charge sur des liaisons de coût inégal.
Note: Avec max-paths, vous pouvez configurer EIGRP pour utiliser jusqu'à six routes de coût égal.
S’il existe quatre chemins vers une destination donnée et que les métriques de ces chemins sont les suivantes :
chemin 1 : 1100
chemin 2 : 1100
chemin 3 : 2000
chemin 4 : 4000
Le routeur, par défaut, place le trafic sur les deux chemins 1 et 2. Avec EIGRP, vous pouvez utiliser la commande variance pour demander au routeur de placer également le trafic sur les chemins 3 et 4. La variance est un multiplicateur : le trafic est placé sur toute liaison dont la métrique est inférieure au meilleur chemin multiplié par la variance. Pour équilibrer la charge sur les chemins 1, 2 et 3, utilisez la variance 2, car 1100 x 2 = 2200, ce qui est supérieur à la mesure via le chemin 3. De même, pour ajouter également 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 lorsqu’il envoie les trois paquets suivants sur le chemin 1 et continue ce modèle.
Note: Même avec la variance configurée, le protocole EIGRP n’envoie pas de trafic sur un chemin de coût inégal si la distance annoncée est supérieure à la distance de faisabilité pour cette route particulière. Référez-vous à la section Distance acceptable, distance relevée et successeurs possibles pour plus d'informations.
Lorsque vous configurez le protocole EIGRP pour la première fois, gardez à l'esprit ces deux règles de base si vous tentez d'influencer les métriques EIGRP :
La bande passante doit toujours être définie sur 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 délai doit 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 peuvent interrompre la redistribution des boucles de routage entre EIGRP et d’autres protocoles. Si vous marquez la route quand elle est redistribuée dans EIGRP, vous pouvez bloquer la redistribution depuis 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 pour configurer ces balises suit, mais cet exemple ne montre pas la configuration complète utilisée pour rompre les boucles de redistribution.
Figure 17
Le routeur trois, qui redistribue les routes connectées au protocole 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 les routes du protocole EIGRP vers le protocole RIP, indique :
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 10.10.10.10 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 a disparu.
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 qui ont été échangées entre le routeur EIGRP adjacent. Une explication de chaque champ de sortie suit la table.
show ip eigrp traffic |
![]() |
Hello sent/received indique 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/received-39).
Les requêtes envoyées/reçues correspondent au nombre de paquets de requête envoyés et reçus (sent-10/received-18).
Réponses envoyées/reçues indique le nombre de paquets de réponse envoyés et reçus (sent-18/received-16).
Les accusés de réception envoyés/reçus représentent le nombre de paquets d'accusé de réception envoyés et reçus (sent-66/received-41).
SIA-Queries sent/received signifie le nombre de paquets de requête actifs bloqués envoyés et reçus (sent-0/received-0).
SIA-Replies sent/received affiche le nombre de paquets de réponse actifs bloqués envoyés et reçus (sent-0/received-0).
L'ID de processus Hello est l'identificateur de processus Hello (270).
PDM Process ID est l'acronyme de Cisco IOS process identifier (251).
Socket Queue affiche les compteurs de files d'attente de socket du processus Hello IP vers EIGRP (current-0/max-2000/high-1/drops-0).
Input Queue affiche les compteurs de files d'attente de socket PDM EIGRP Hello Process to EIGRP (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 le tableau.3+
show ip eigrp topology |
![]() |
Explications de configuration
A signifie actif. On peut aussi voir un P, qui signifie 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 défini et/ou filtré avec des 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, ce qui signifie que la mise à jour est en attente ; ou R, ce qui signifie qu'une réponse est 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, ce qui signifie que plusieurs voisins ont envoyé des requêtes sur cette destination, mais pas sur le successeur ; ou Origine du successeur, ce qui signifie que le successeur a émis la requête.
via 10.1.2.2 indique que cette route a été apprise à partir d’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 ; Redistribué, 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 indique que ce voisin a été interrogé et attend une réponse.
Q est l'indicateur d'envoi de cette route, ce qui signifie qu'une requête est en attente. Ce champ peut également être U, ce qui signifie que la mise à jour est en attente ; ou R, ce qui signifie qu'une réponse est en attente.
Serial1 est l'interface par laquelle le voisin est accessible.
Via 10.1.1.2 indique que le voisin est interrogé et attend une réponse.
r indique que ce voisin a été interrogé sur la route et n'a 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 indique que cette route est utilisée (indique le chemin que le chemin/la destination suivant prend lorsqu’il existe plusieurs routes de coût égal).
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 |
![]() |
2 Le ou les successeurs signifient qu’il existe deux chemins possibles vers ce réseau.
Blocs descripteurs de routage Chacune de ces entrées 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 pour le réseau via ce chemin, ainsi que le coût pour le tronçon suivant. 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.
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 acceptés par le protocole EIGRP est de 100 par défaut, bien que le nombre maximal puisse être configuré sur 220 avec le nombre maximal de sauts métriques.
Si la route est externe, ces informations sont incluses. Une explication de chaque champ de sortie suit la table.
Route externe |
![]() |
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.
La balise d'administrateur peut être définie et/ou filtrée à l'aide de mappages de route à l'aide des 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.
Révision | Date de publication | Commentaires |
---|---|---|
3.0 |
12-Jul-2022 |
Republié pour améliorations. Recertification. 7/12/2022 |
2.0 |
30-Jun-2022 |
Mise à jour de recertificationSupprimez toutes les PII du texte et des figures.
Mettre à jour les exigences de style, traduction automatique, géronds et autres formatages. |
1.0 |
03-Jan-2002 |
Première publication |