Principes de fonctionnement du protocole EIGRP

Cet article parlera d'EIGRP et expliquera comment ce protocole fonctionne. L'EIGRP est un protocole à vecteur de distance, il est parfois dit hybride, mais il ne l'est pas. Lisez le début de l'article sur OSPF et vous comprendrez pourquoi EIGRP est un protocole vectoriel à distance. EIGRP est un protocole de routage dynamique avancé à vecteur de distance développé par Cisco. Faisons les choses correctement. Nous utiliserons la topologie suivante:

Mon image

Exécutez EIGRP sur vIOS1 et vIOS2, voyez comment les informations sont transmises entre les routeurs. Dès que EIGRP est activé sur le routeur, le routeur commence à envoyer des paquets Hello. Nous listons également d'autres types de messages utilisés dans EIGRP.

  • Bonjour - les routeurs utilisent des paquets bonjour pour découvrir les voisins. Les paquets de multidiffusion sont envoyés et ne nécessitent pas de confirmation de réception.
  • Mise à jour - contient des informations sur la modification des itinéraires. Ils ne sont envoyés qu'aux routeurs concernés par la mise à jour. Ces paquets peuvent être envoyés à un routeur spécifique (unicast) ou à un groupe de routeurs (multicast). La réception d'un package de mise à jour est confirmée par l'envoi d'un ACK.
  • Requête - lorsque le routeur calcule l'itinéraire et n'a pas de successeur possible, il envoie un paquet de requête à ses voisins afin de déterminer s'ils ont un successeur possible pour cette destination. En règle générale, les paquets de requête sont envoyés par multidiffusion, mais il peut y avoir unidiffusion. La réception du paquet de requête est confirmée par l'envoi de l'accusé de réception par le récepteur du paquet.
  • Répondre - le routeur envoie un paquet de réponse en réponse au paquet de requête. Les paquets de réponse sont envoyés en envoi individuel à celui qui a envoyé le paquet de requête. La réception d'un paquet de réponse est confirmée par l'envoi d'un ACK.
  • ACK - un paquet qui confirme la réception des paquets de mise à jour, de requête et de réponse. Les paquets ACK sont envoyés en envoi individuel et contiennent un numéro d'accusé de réception. En fait, ce sont des paquets bonjour qui ne transmettent pas de données. La livraison non garantie est utilisée.

Il existe également des packages SIA, mais nous en parlerons ci-dessous.
Les paquets sont envoyés à l'adresse de multidiffusion 224.0.0.10 toutes les 5 secondes (Hello Timer), Hold Timer est de 15 secondes = 3 intervalles de bonjour, si pendant ce minuteur aucun paquet de bonjour n'a été reçu d'un voisin, alors le voisin est supprimé de la liste des voisins. Le package ressemble à ceci:

Mon image

Le package contient les paramètres des coefficients (K1, K2, K3, K4, K5, K6), la minuterie de maintien et le numéro du système autonome. Les coefficients (K1, K2, K3, K4, K5, K6) sont utilisés dans le calcul de la métrique, et nous en parlerons plus tard, ainsi que les temporisateurs EIGRP. Maintenant, il est important de parler du système autonome (AS). Pour activer EIGRP, un processus EIGRP spécifique doit recevoir un numéro, comme dans OSPF. Mais contrairement à OSPF, cette option ne peut pas être sélectionnée au hasard pour chaque routeur, elle doit être la même pour tous les routeurs. Si le routeur reçoit un paquet Hello avec un AS différent de celui-ci, il n'y aura pas de relation de voisinage.

Pour que les routeurs deviennent voisins, les conditions suivantes doivent être remplies:

  • les routeurs doivent être authentifiés,
  • les routeurs doivent être dans le même AS,
  • Les relations de voisinage doivent être établies sur les adresses principales (lorsqu'un paquet bonjour arrive, le routeur vérifie si l'adresse de l'expéditeur du réseau appartient à l'adresse principale de l'interface),
  • les valeurs des coefficients K doivent correspondre.

Pour que les routeurs deviennent des voisins EIGRP, ils ne doivent pas nécessairement correspondre aux durées Hello et Hold. Le routeur utilise des valeurs de temporisation reçues du voisin. Si la minuterie Hello ou Hold est modifiée sur l'un des routeurs, les voisins de ce routeur utiliseront ces valeurs. Pour que le routeur utilise d'autres valeurs, il est nécessaire de changer le temporisateur sur l'interface correspondante du voisin. Après avoir échangé des paquets Hello, un paquet de mise à jour est envoyé, mais il ne contient pas encore de routes, il contient l'indicateur Init, qui informe les routeurs du début de l'échange d'informations sur les routes. Ce paquet est envoyé directement à l'adresse du routeur. Après avoir échangé de tels messages, chaque routeur envoie un paquet de mise à jour avec des routes à l'adresse de multidiffusion 224.0.0.10:

Mon image

Comme vous pouvez le voir, le package de mise à jour ne contient aucune métrique, mais uniquement des informations telles que la bande passante, le retard, le MTU, etc. Après avoir reçu ces informations, le routeur lui-même calcule la métrique à l'aide des coefficients K1-K6. Ces paquets peuvent être envoyés à un routeur spécifique ou à la multidiffusion. En général, il existe trois types de mises à jour:

  • Non périodique (non périodique) - les mises à jour ne sont pas envoyées à intervalles réguliers, mais lorsque la topologie ou la métrique change;
  • Partiel (Partiel) - toutes les informations de la table de routage ne sont pas transmises dans les mises à jour, mais uniquement les modifications;
  • Limité - Les mises à jour sont envoyées uniquement aux routeurs impliqués.

Les quartiers au niveau des paquets ressemblent à ceci:

Mon image

Vous pouvez remarquer qu'en plus du Hello et de la mise à jour répertoriés par nous, il existe également Hello (ACK) et le nombre est égal au nombre de paquets de mise à jour envoyés à l'adresse de multidiffusion. Tout tourne autour du protocole RTP. Le protocole RTP contrôle le processus de transmission des paquets EIGRP et fournit:

  • Livraison de colis garantie.
  • Préserver l'ordre des paquets.

Ce sont les choses. Qu'avons-nous? Les routes ont échangé des paquets de mise à jour et il est maintenant temps de créer une table de routage. Chaque mise à jour est traitée et substitue les données (bande passante, retard, etc.) dans une formule spéciale, la métrique est calculée:

Mon image

Une telle formule a l'air géniale, mais la meilleure chose à ce sujet est que vous ne la connaissez peut-être pas, sachez simplement que quelque chose comme ça existe. Et une autre astuce intéressante est que les coefficients EIGRP par défaut sont:

  • K1 = 1
  • K2 = 0
  • K3 = 1
  • K4 = 0
  • K5 = 0

Et la formule se transforme simplement en métrique = bande passante + retard. Par conséquent, il est si important que les coefficients sur tous les routeurs soient les mêmes, afin qu'il n'y ait pas de problèmes dus aux différentes métriques sur les routeurs. Parlons un peu plus en détail des données dans Update.

  • Bande passante - la valeur minimale parmi les canaux de bande passante menant au réseau est sélectionnée et envoyée à Update.
  • Delay - Résume le délai de tous les canaux menant à ce réseau.
  • Fiabilité - la pire mesure de fiabilité tout au long, basée sur Keepalive
  • Chargement - le pire indicateur de chargement de lien tout le long, basé sur le taux de paquets et la bande passante configurée sur l'interface
  • MTU est le plus petit MTU de tous les temps. Malgré le fait qu'il soit utilisé dans Update, il ne participe pas au calcul de la métrique elle-même.

Comme indiqué ci-dessus, la bande passante et le retard sont utilisés par défaut. Les paramètres restants sont rarement nécessaires en cas de besoin, mais à l'aide d'eux, un ajustement plus fin de la métrique est possible. Ainsi, dans le paquet de mise à jour, le routeur passe la route et les données qui lui sont associées, il ne transmet pas la métrique elle-même. Le routeur qui a reçu la mise à jour calcule la métrique selon la formule et, selon les métriques, décide de router ou non la route vers la table de routage. Il est également important de noter que le routeur ne transmet que les routes qu'il utilise. Voyons comment construire une table de topologie.

Table de topologie - Une liste des routes apprises de chaque voisin. La table de topologie stocke également la métrique que chaque voisin rapporte pour chaque route (AD) et la métrique que le routeur local utilisera pour atteindre la route via le voisin (FD).

Il est nécessaire d'expliquer ce que sont AD et FD. Nous allons configurer EIGRP sur tous nos routeurs. De plus, pour éviter les nombres complexes dans la métrique, nous changeons les coefficients de K1 = 1 K2 = 0 K3 = 1 K4 = 0 K5 = 0 à K1 = 0 K2 = 0 K3 = 1 K4 = 0 K5 = 0. Ainsi, nous aurons 256 * Formule de délai et nous obtenons également un moyen facile de manipuler les métriques en modifiant le paramètre de délai sur les interfaces. Étant donné que sur les interfaces, délai = 1 s, chaque lien, si vous utilisez la terminologie OSPF, coûte 256. Voyons quelle est la table de topologie sur vIOS1:
Topologie vIOS1 # show ip eigrp
Table de topologie EIGRP-IPv4 pour AS (1) / ID (192.168.1.1)
Codes: P - Passif, A - Actif, U - Mise à jour, Q - Requête, R - Réponse,
r - Statut de réponse, s - Statut de sia

P 192.168.3.0/24, 1 successeurs, FD est 512
via 192.168.13.3 (512/256), GigabitEthernet0 / 0
P 192.168.2.0/24, 1 successeurs, FD est 512
via 192.168.12.2 (512/256), GigabitEthernet0 / 3
P 192.168.25.0/24, 1 successeurs, FD est 512
via 192.168.12.2 (512/256), GigabitEthernet0 / 3
P 192.168.35.0/24, 1 successeurs, FD est 512
via 192.168.13.3 (512/256), GigabitEthernet0 / 0
P 192.168.12.0/24, 1 successeurs, FD est 256
via Connected, GigabitEthernet0 / 3
P 192.168.45.0/24, 1 successeurs, FD est 512
via 192.168.14.4 (512/256), GigabitEthernet0 / 2
P 192.168.0.0/24, 1 successeurs, FD est 256
via Connected, GigabitEthernet0 / 1
P 192.168.13.0/24, 1 successeurs, FD est 256
via Connected, GigabitEthernet0 / 0
P 192.168.14.0/24, 1 successeurs, FD est 256
via Connected, GigabitEthernet0 / 2
P 192.168.5.0/24, 3 successeurs, FD est 768
via 192.168.12.2 (768/512), GigabitEthernet0 / 3
via 192.168.13.3 (768/512), GigabitEthernet0 / 0
via 192.168.14.4 (768/512), GigabitEthernet0 / 2

Si vous regardez, par exemple, le réseau - 192.168.5.0/24, vous remarquerez trois chemins via vIOS2, vIOS3 et vIOS4 avec les mêmes métriques. Pour 192.168.5.0/24 FD, pour tous les chemins, il est égal - 768 et AD - 512. Donnons une définition d'un autre article et essayons d'expliquer:

  • La distance annoncée (AD) , également connue sous le nom de distance rapportée (RD), est le coût de la distance entre le routeur voisin qui annonce l'itinéraire et le réseau de destination.
  • Distance réalisable (FD) - le coût de la distance entre le routeur local et le réseau de destination = AD, qui annonce le routeur voisin + le coût de la distance entre le routeur local et le routeur voisin.

P 192.168.5.0/24, 3 successeurs, FD est 768 via 192.168.14.4 (768/512), GigabitEthernet0 / 2

Examinons cette ligne de la table de topologie sur vIOS1. vIOS1 a découvert la route à partir de vIOS4 (192.168.14.4). Étant donné que vIOS1 sépare trois liens de 192.168.5.0/24, la métrique FD avec nos paramètres sera 3 * 256 = 768. Et AD est la métrique de l'itinéraire par rapport au routeur (vIOS4) qui a annoncé ce réseau. AD est la métrique FD de cette route sur vIOS4. Regardons la table de topologie sur vIOS4:
P 192.168.5.0/24, 1 successeurs, FD est 512 via 192.168.45.5 (512/256), GigabitEthernet0 / 1

AD sur vIOS1 = FD sur vIOS4. Confusion silencieuse, mais essayez d'expliquer la logique du travail. Le routeur qui annonce la route envoie les paramètres (Bande passante, Délai, etc.) de la route dans le message de mise à jour sans prendre en compte le lien entre le routeur qui est annoncé. Autrement dit, vIOS4 ne prend en compte que les paramètres de deux liaisons: vIOS4 Gi0 / 1 - vIOS5 Gi0 / 1 et vIOS5 Gi0 / 0 - VPC. Après avoir reçu Update, vIOS1, en remplaçant les paramètres obtenus dans la formule, calcule quoi? C'est vrai - AD = 512. Une fois qu'il prend les paramètres de liaison d'où provient l'itinéraire, vIOS1 Gi0 / 2 - vIOS4 Gi0 / 2 et le remplace à nouveau dans la formule. Compte, obtient le nombre 256 et l'additionne avec AD (512), nous obtenons FD-768. Ce sont les choses! Mais pourquoi tout ce rituel?
Et tout cela pour créer une règle spéciale appelée la condition Faisible , qui est l'un des moyens de se protéger contre la formation de boucles et la convergence rapide.
Définissons les termes suivants:

  • Le successeur est un routeur adjacent avec un chemin sans boucle et le chemin le plus économique vers le réseau de destination.
  • Successeur possible - routeur de sauvegarde avec chemin sans boucles (le successeur réalisable AD doit être inférieur à FD de la route du successeur actuel).
  • État réalisable - Le successeur réalisable AD doit être inférieur au FD de la route successeur actuelle.

Pour expliquer comment tout cela fonctionne et afficher les subtilités, vous devez modifier certaines mesures. Faisons ce qui suit, modifions le délai afin que nous ayons de telles mesures de lien:

Mon image

Cela se fait à l'aide de la commande de délai sur l'interface. Maintenant, nous avons dit - delay = 1 et la métrique est 256. Voyons quelles métriques nous obtenons pour le réseau 192.168.5.0/24 sur le routeur vIOS1:

  • Via vIOS2 - FD = 2304, AD = 1280
  • Via vIOS4 - FD = 1024, AD = 768
  • Via vIOS3 - FD = 1536, AD = 768

Comme nous voyons que le meilleur FD sera pour la route via vIOS4, il sera ajouté à la table de routage générale, cette route est appelée Successeur :
vIOS1 # show ip route eigrp
Codes: L - local, C - connecté, S - statique, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP externe, O - OSPF, IA - OSPF inter zone
N1 - OSPF NSSA externe type 1, N2 - OSPF NSSA externe type 2
E1 - OSPF externe type 1, E2 - OSPF externe type 2
i - IS-IS, su - Résumé IS-IS, L1 - IS-IS niveau 1, L2 - IS-IS niveau 2
ia - inter-zone IS-IS, * - par défaut candidat, U - route statique par utilisateur
o - ODR, P - itinéraire statique téléchargé périodiquement, H - NHRP, l - LISP
a - voie d'application
+ - route répliquée,% - remplacement du saut suivant, p - substitutions de PfR

La passerelle de dernier recours n'est pas définie

D 192.168.2.0/24 [90/512] via 192.168.12.2, 06:01:31, GigabitEthernet0 / 3
D 192.168.3.0/24 [90/1024] via 192.168.13.3, 06:01:28, GigabitEthernet0 / 0
D 192.168.5.0/24 [90/1024] via 192.168.14.4, 06:01:28, GigabitEthernet0 / 2
D 192.168.25.0/24 [90/1024] via 192.168.14.4, 06:01:28, GigabitEthernet0 / 2
D 192.168.35.0/24 [90/1024] via 192.168.14.4, 06:01:28, GigabitEthernet0 / 2
D 192.168.45.0/24 [90/768] via 192.168.14.4, 06:01:28, GigabitEthernet0 / 2

Qu'adviendra-t-il des deux autres routes - elles seront vérifiées pour la condition FS (condition faisable). La route via vIOS3 passe cette condition AD (via vIOS3) = 768 <1024 = FD (via vIOS1). Par conséquent, cette route, bien qu'elle ne soit pas ajoutée à la table de routage générale, elle sera stockée dans les tables de topologie:
Topologie vIOS1 # show ip eigrp
Table de topologie EIGRP-IPv4 pour AS (1) / ID (192.168.1.1)
Codes: P - Passif, A - Actif, U - Mise à jour, Q - Requête, R - Réponse,
r - Statut de réponse, s - Statut de sia

P 192.168.3.0/24, 1 successeurs, FD est 1024
via 192.168.13.3 (1024/256), GigabitEthernet0 / 0
P 192.168.2.0/24, 1 successeurs, FD est 1024
via 192.168.12.2 (1024/256), GigabitEthernet0 / 3
P 192.168.25.0/24, 1 successeurs, FD est 1024
via 192.168.14.4 (1024/768), GigabitEthernet0 / 2
via 192.168.13.3 (1536/768), GigabitEthernet0 / 0
P 192.168.35.0/24, 1 successeurs, FD est 1024
via 192.168.14.4 (1024/768), GigabitEthernet0 / 2
via 192.168.13.3 (1280/512), GigabitEthernet0 / 0
P 192.168.12.0/24, 1 successeurs, FD est 768
via Connected, GigabitEthernet0 / 3
P 192.168.45.0/24, 1 successeurs, FD est 768
via 192.168.14.4 (768/512), GigabitEthernet0 / 2
P 192.168.0.0/24, 1 successeurs, FD est 512
via Connected, GigabitEthernet0 / 1
P 192.168.13.0/24, 1 successeurs, FD est 768
via Connected, GigabitEthernet0 / 0
P 192.168.14.0/24, 1 successeurs, FD est 256
via Connected, GigabitEthernet0 / 2
P 192.168.5.0/24, 1 successeurs, FD est 1024
via 192.168.14.4 (1024/768), GigabitEthernet0 / 2
via 192.168.13.3 (1536/768), GigabitEthernet0 / 0

Il n'a pas la métrique de la meilleure route, c'est-à-dire qu'il n'est pas un successeur, mais il joue le rôle d'une route de sauvegarde et, si le successeur est perdu, prendra immédiatement sa place. Cela permet une convergence très rapide du protocole, mais plus à ce sujet plus tard. Cette route est appelée successeur possible . Et qu'adviendra-t-il de la troisième route? Rien, il ne remplit pas la condition FC (1280> 1024) et ne sera pas pris en compte pour le protéger du bouclage. Toutes les routes reçues via Update mais non testées par FC peuvent être vues à l'aide de la commande show ip eigrp topology all-links. On ne sait pas pourquoi la condition FS protège contre la formation de boucles, essayons maintenant de l'expliquer. Il est important de savoir que lors de l'étude du protocole EIGRP, il est essentiel de comprendre le principe de la condition FC et le but pour lequel il est utilisé. Considérez une topologie légèrement modifiée (ajout d'un lien entre vIOS2 et vIOS4), et utilisez également la métrique la plus primitive:

Mon image

La route vers le réseau 192.168.5.0/24 sera la même avec AD et FD:

  • vIOS4 - via vIOS5, AD = 5, FD = 10.
  • vIOS1 - via vIOS4, AD = 10, FD = 11.
  • vIOS3 - via vIOS1, AD = 11, FD = 12.

Mais vIOS4 recevra une mise à jour de vIOS2, qui contiendra l'itinéraire vers le réseau 192.168.5.0/24 via vIOS2 avec la métrique - AD = 12, FD = 15. Il est clair qu'il ne peut pas être un successeur, si tout à coup cette route est choisie par le successeur faisable, alors si le successeur tombe sur vIOS4 et que le successeur choisit cette route, une boucle se produit. Mais FC ne permettra pas de définir cette route comme FS comme AD = 12> 10 = FD. La route vers vIOS2 contient le chemin d'accès via vIOS4, et dans tous les cas, son AD inclut également FD vIOS4. Autrement dit, AD sur vIOS2 contient les liens suivants:
12 = AD sur vIOS2 = Gi0 / 3 vIOS3 + Gi0 / 2 vIOS4 + Gi0 / 1 vIOS5 + eth0 VPC5, où Gi0 / 1 vIOS5 + eth0 VPC5 = FD = 10 - il s'agit de FD vIOS4 et il est impossible pour AD <FD d'être moins.

Ainsi, la condition FC vérifie la route pour la présence d'elle-même dans cette route. Seuls les itinéraires qui remplissent cette condition peuvent garantir qu'il n'y a pas de boucles. Il peut y avoir des cas où la route ne crée pas de boucle, mais en même temps ne satisfait pas la condition FC, nous ne l'utiliserons pas, dans de tels cas, nous choisissons la stabilité du réseau. Si vous approfondissez, la condition est assez simple et intuitive. L'algorithme qui sélectionne les meilleures routes dans le protocole EIGRP est appelé DUAL . Considérons maintenant le protocole EIGRP à la question de la convergence dans la perte de la route principale. Revenons à notre ancienne grande topologie et imaginons que vIOS4 a disparu. Selon la façon dont vIOS4 a disparu, le comportement sera légèrement différent, mais il différera lorsque le déclencheur se déclenchera. Si, par exemple, nous désactivons l'interface Gi 0/2 sur vIOS1, puis vIOS1 détecte immédiatement la perte d'un voisin et commence à agir, si le voisin disparaît sans avertissement, alors Hold Timer fonctionnera après qu'il ne reçoive pas de paquets Hello pendant 15 secondes:
D 192.168.2.0/24 [90/512] via 192.168.12.2, 06:01:31, GigabitEthernet0 / 3
D 192.168.3.0/24 [90/1024] via 192.168.13.3, 06:01:28, GigabitEthernet0 / 0
D 192.168.5.0/24 [90/1024] via 192.168.14.4, 06:01:28, GigabitEthernet0 / 2
D 192.168.25.0/24 [90/1024] via 192.168.14.4, 06:01:28, GigabitEthernet0 / 2
D 192.168.35.0/24 [90/1024] via 192.168.14.4, 06:01:28, GigabitEthernet0 / 2
D 192.168.45.0/24 [90/768] via 192.168.14.4, 06:01:28, GigabitEthernet0 / 2

P 192.168.3.0/24, 1 successeurs, FD est 1024
via 192.168.13.3 (1024/256), GigabitEthernet0 / 0
P 192.168.2.0/24, 1 successeurs, FD est 1024
via 192.168.12.2 (1024/256), GigabitEthernet0 / 3
P 192.168.25.0/24, 1 successeurs, FD est 1024
via 192.168.14.4 (1024/768), GigabitEthernet0 / 2
via 192.168.13.3 (1536/768), GigabitEthernet0 / 0
P 192.168.35.0/24, 1 successeurs, FD est 1024
via 192.168.14.4 (1024/768), GigabitEthernet0 / 2
via 192.168.13.3 (1280/512), GigabitEthernet0 / 0
P 192.168.12.0/24, 1 successeurs, FD est 768
via Connected, GigabitEthernet0 / 3
P 192.168.45.0/24, 1 successeurs, FD est 768
via 192.168.14.4 (768/512), GigabitEthernet0 / 2
P 192.168.0.0/24, 1 successeurs, FD est 512
via Connected, GigabitEthernet0 / 1
P 192.168.13.0/24, 1 successeurs, FD est 768
via Connected, GigabitEthernet0 / 0
P 192.168.14.0/24, 1 successeurs, FD est 256
via Connected, GigabitEthernet0 / 2
P 192.168.5.0/24, 1 successeurs, FD est 1024
via 192.168.14.4 (1024/768), GigabitEthernet0 / 2
via 192.168.13.3 (1536/768), GigabitEthernet0 / 0

J'ai apporté à nouveau la table de routage et de topologie pour plus de commodité, afin que pour comprendre comment le routeur agira sur chaque route, vous devez savoir dans quel état il se trouvait auparavant. Par exemple, la route dont nous avons discuté précédemment, la route 192.168.5.0/24 sera perdue, mais elle avait FS dans la table de topologie et donc, dès que la route principale sera perdue, elle prendra sa place dans la table de routage. Une question intéressante est de savoir ce qui arrivera aux routes sans FS. Mais un peu de matériel:

Les entrées dans la table de topologie peuvent être dans deux états: actif et passif. La route est dans un état passif lorsque la route est stable et que la recherche de la meilleure route ne se produit pas. En état actif - si vous recherchez le meilleur itinéraire. Une recherche d'itinéraire est effectuée lorsqu'il n'y a pas de successeur possible pour le réseau de destination. Le routeur, à la recherche d'un meilleur itinéraire, envoie une requête (envoie un paquet de requête) à chaque routeur voisin. Si le voisin a une route vers le réseau de destination, il répond (envoie un paquet de réponse), s'il n'y a pas de route, le voisin envoie une requête à ses voisins. Le routeur compare tous les FD pour atteindre un réseau spécifique, sélectionne l'itinéraire avec le plus petit FD et le place dans la table de routage. La table de topologie peut stocker 6 itinéraires vers le réseau du destinataire (principal et de secours).

Les routes qui ont été perdues et qui n'avaient pas FS passeront à Active et vIOS1 commencera à poser des questions sur leurs voisins restants. Cela se fait à l'aide de messages de requête.vIOS1 enverra des messages de requête aux routeurs vIOS2 et vIOS3, où il indiquera clairement les routes dont il a besoin - dans notre cas, ces routes seront 192.168.14.0/24, 192.168.45.0/24. Avec ce message, vIOS1 informe également les routeurs que les itinéraires via vIOS1 vers ces réseaux sont inutilisables. Cela se fait en spécifiant le paramètre Delay: Infifnity dans la métrique de cette route, c'est-à-dire que la métrique est infiniment grande. Dès que les routeurs reçoivent de tels messages, ils suppriment ces routes via vIOS1. Cette technologie est appelée Poison Reverse.. Poison Reverse est également utilisé pour les messages de mise à jour, j'en parlerai un peu plus tard. Après avoir reçu une requête avec une demande de routes 192.168.14.0/24, 192.168.45.0/24, vIOS2 et vIOS3 verront s'ils ont ces routes, qu'ils utilisent, le cas échéant, ils enverront immédiatement une réponse avec de nouvelles métriques pour ces routes. vIOS2 et vIOS3, comme nous le savons, n'ont pas perdu leurs itinéraires, ils enverront donc immédiatement Répondre. Si le routeur qui est également demandé n'a pas cette route, il transmettra la requête à ses voisins et ainsi de suite. vIOS1 attendra la réponse de vIOS2, vIOS3, puis Active Timer entre en scène, qui démarre dès que la requête est envoyée:

Active Timer- l'intervalle de temps pendant lequel l'itinéraire peut rester à l'état actif. Si le temporisateur expire avant que toutes les réponses des voisins ne soient reçues (réponse), le routeur met la route dans un état bloqué-actif. De plus, les relations du quartier sont rompues avec les voisins de qui aucune réponse n'a été reçue. Par défaut, cette minuterie est de 3 minutes.

Autrement dit, si la réponse n'est pas reçue dans les 3 minutes, malgré les paquets Hello, le quartier sera rompu et c'est très mauvais. Malgré le fait que 3 minutes soit comme une éternité pour de tels protocoles, de telles situations sont possibles avec de grandes topologies. Pour se protéger contre la rupture erronée de la relation de voisinage, des messages spéciaux ont été inventés - SIA-Query et SIA-Reply.
Pour améliorer la réponse du routeur à l'état de la route active, deux types de messages sont en outre introduits:

  • SIA-Query - Expédié après 1,5 minute (par défaut) afin de vérifier l'état d'un routeur directement connecté. Afin que, si la route qui se trouve derrière le voisin (alors que la connexion avec le voisin est normale) soit perdue, les relations de voisinage avec le routeur directement connecté ne sont pas réinitialisées. Ne nécessite pas de confirmation de réception. Après avoir envoyé trois messages et ne pas avoir reçu de réponse, le voisin est considéré comme arrêté et l'itinéraire est supprimé de la table de topologie.
  • SIA-Reply - Envoyé en réponse à SIA-Query. Ne nécessite pas de confirmation de réception.

Après 1,5 minute, si la réponse à une requête n'est pas reçue, alors la requête SIA est envoyée, ce qui ne nécessite pas de nouvelle route, mais doit uniquement envoyer la réponse SIA, pour s'assurer que le voisin est en ordre, ne peut tout simplement pas trouver la bonne route

Je pense à la façon dont le routeur réagit à la perte de la route dans le cas où il y a FS ou non, nous en avons assez dit. Il suffit de modifier les éléments suivants. Nous n'avons pas donné correctement la définition de FD, la métrique que nous calculons selon la formule lorsque nous recevons un itinéraire pour la première fois ou lorsque l'état de l'itinéraire change encore, il serait correct d'appeler CD - Distance calculée.

FD est le meilleur indicateur pour un itinéraire donné qui ait jamais été obtenu, et c'est lui qui participe au contrôle FC. Le plus souvent, FD = CD est le meilleur itinéraire, mais voyons comment FD a changé après l'effondrement du quartier avec vIOS4:
P 192.168.5.0/24, 1 successeurs, FD est 1024
via 192.168.13.3 ( 1536 /768), GigabitEthernet0 / 0

Nous n'avons plus de route avec CD = 1024, la meilleure route via vIOS3 est CD = 1536, mais comme vous pouvez le voir, FD = 1024, qui a été corrigé lorsqu'il y avait une route via vIOS4. FD ne sera mis à jour que lorsque cette route passera à l'état Actif. Tant que l'état ne passera pas de passif à actif, FD ne changera pas non plus. Les mises à jour régulières ne s'y appliquent pas. Encore une remarque. Faisons cette expérience: renvoyons le voisinage avec vIOS4, CD via vIOS3 = 1536 et via vIOS2 = 2048. Augmentez le délai du canal entre vIOS1 et vIOS3 afin qu'il devienne plus grand que le CD vIOS2:
P 192.168.5.0/24, 1 successeurs, FD est 1024
via 192.168.14.4 (1024/768), GigabitEthernet0 / 2
via 192.168.13.3 ( 2304 /768), GigabitEthernet0 / 0

Comme nous voyons le CD via vIOS3 = 2304, mais il est resté FS puisque AD n'a pas changé et la condition FC a été remplie, comme auparavant. Nous nous posons une question: que se passe-t-il lorsqu'un itinéraire est perdu via vIOS2? La réponse attendue et logique, comme on nous l'a appris, est FS à la place, mais non! Puisqu'il existe toujours une route via vIOS2 avec CD = 2048 <2304, la route passera à l'état Actif et recalculera la métrique pour elle et sélectionnera la meilleure route malgré le fait qu'elle avait une route de sauvegarde. Nous regardons la table de topologie et obtenons:
P 192.168.5.0/24, 1 successeurs, FD est 2048
via 192.168.12.2 (2048/1280), GigabitEthernet0 / 3
via 192.168.13.3 (2304/768), GigabitEthernet0 / 0

La route via vIOS2 sera utilisée, et comme l'a noté FD, elle a également changé en raison de la transition de la route à l'état Actif. Et l'itinéraire via vIOS3 partage à nouveau le sort de la pièce de rechange.

Fractionner les règles inverses d'horizon et de poison dans EIGRP


Comme dans RIP, EIGRP utilise la règle Split Horizon - si une route est accessible via une interface spécifique, cette route n'est pas incluse dans la mise à jour envoyée via cette interface.

Par exemple, si vIOS4 reçoit un itinéraire vers le réseau 192.168.0.0/24 de vIOS1, il n'enverra pas cet itinéraire à Update via l'interface à laquelle vIOS1 est connecté. Pour être plus précis, imaginez que vIOS1 a commencé à parler du réseau 192.168.0.0/24. J'ai envoyé Update à vIOS4, vIOS4 le recevra et, en règle générale, Split Horizon ne devrait pas envoyer sa mise à jour avec cette route à vIOS1, mais en réalité, il l'enverra avec une métrique infinie. Comme si vIOS4 disait vIOS1 - "N'osez pas utiliser la route vers le réseau 192.168.0.0/24 par moi, j'ai obtenu cette route de vous et si vous l'utilisez, il y aura une boucle."

Poison Reverse - indiquant un itinéraire inaccessible à l'aide d'une métrique lorsqu'il est perdu. Dans EIGRP, cela se fait à l'aide du paramètre Delay. Nous avons indiqué ci-dessus comment cette technologie est utilisée lorsque vIOS1 a perdu le contact avec vIOS4. D'après ce qui précède sur Split Horizon, nous pouvons conclure que la technologie Poison Reverse est utilisée non seulement dans les messages de requête, mais aussi dans la mise à jour. En outre, Poison Reverse peut violer la règle Split Horizon et envoyer Update avec des métriques infinies depuis l'interface à partir de laquelle il a reçu cette mise à jour. Ces deux règles, ainsi que la clause FC, assurent la protection du protocole EIGRP contre les boucles.

Routeurs stub


Comme optimisation, un rôle spécial pour les routeurs a été introduit dans le protocole - Stub. Quelque chose comme la zone Stub dans OSPF, mais voici un principe de fonctionnement légèrement différent. Lors de la configuration du routeur en mode stub, il signale immédiatement dans les paquets Hello à son voisin son état de stub et, selon le mode de stub, peut envoyer certains types de routes:
vIOS5 # eigrp stub [connecté | carte des fuites | recevoir uniquement | redistribué | statique | résumé]

Options de la commande stub Eigrp:

  • Sans options (par défaut) - connecté et résumé;
  • connected - Permet au routeur de raccord d'envoyer des itinéraires connectés, mais uniquement pour les interfaces dont les adresses se trouvent sur les réseaux spécifiés par la commande network;
  • leak-map - Autorise les préfixes dynamiques basés sur la fuite-map;
  • recevoir uniquement - Empêche le routeur de raccord d'envoyer des itinéraires;
  • redistributed — stub redistributed ;
  • static — stub static , , ;
  • summary — stub ( ).

Mais la principale caractéristique de ce paramètre est que si le routeur sait que son voisin est dans le rôle Stub, il ne lui enverra pas de requête pour les routes qui sont devenues actives. Par exemple, si nous configurons vIOS5 en tant que Stub, alors vIOS2-4 le découvrira et si les routes sont perdues, elles n'empoisonneront pas Query. Compte tenu des problèmes pouvant survenir en l'absence de réponse, il serait intéressant d'envoyer la requête uniquement là où cela a du sens. Ceci est important dans les grandes topologies où la convergence peut être un processus complexe. Par conséquent, s'il existe un routeur final et que seuls les réseaux d'utilisateurs y sont connectés (relativement parlant, il n'a qu'un seul voisin), il est préférable de penser à le configurer en tant que Stub.

Quelques mots sur les minuteries


Nous avons parlé de certains d'entre eux, si vous regardez la sortie de la commande show ip eigrp voisins, nous verrons ce qui suit:
vIOS1 # show ip eigrp voisins
EIGRP-IPv4 voisins pour AS (1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2192.168.14.4 Gi0 / 2 11 00:48:43 23138 0168
0 192.168.12.2 Gi0 / 3 12 02:31:12 6 100 0 258
1 192.168.13.3 Gi0 / 0 10 2d13h 7 100 0 291
vIOS1 #

Voici des minuteries qui nécessitent une explication. Si, en réponse à l'envoi de tout paquet de multidiffusion qui nécessite une confirmation de réception, un accusé de réception (ACK) n'a pas été envoyé, alors le paquet de monodiffusion sera transmis au voisin qui ne répond pas. Si la confirmation n'a pas été reçue même après l'envoi de 16 paquets de monodiffusion, le voisin est considéré comme inactif.

  • Temps aller-retour fluide (SRTT) - le temps entre l'envoi d'un paquet à un voisin et la réception d'une confirmation de sa part. Mesuré en millisecondes. La formule de calcul est exclusive.
  • Multicast Flow Timer - la valeur maximale de l'intervalle en secondes pendant lequel le routeur attendra le paquet ACK après avoir envoyé le paquet EIGRP à l'adresse multicast avant de passer à l'envoi unicast. Il est calculé sur la base de SRTT, la formule de calcul elle-même est propriétaire.
  • Retransmission timeout (RTO) - l' intervalle entre l'envoi de paquets unicast. Il est calculé sur la base de SRTT, la formule de calcul elle-même est propriétaire.

Sur ce, je pense que pour terminer l'article. Voici un lien utile:

Source: https://habr.com/ru/post/fr420667/


All Articles