Introduction à l’EIGRP

Vous avez surement déjà entendu parler de l’EIGRP. Il s’agit de l’un des principaux  protocoles de routage disponible aujourd’hui.

A travers cet article, nous allons voir ensemble le fonctionnement de ce protocole.

Nous commencerons par les notions à connaitre pour passer la CCNA, puis nous irons jusqu’au niveau CCNP.

Quant à la pratique, elle fera l’objet d’un prochain article.

1)     Présentation de l’EIGRP

 

1.1) Caractéristiques de base

Avant de voir comment fonctionne ce protocole, attardons nous sur ses caractéristiques de base.

L’EIGRP était un protocole propriétaire Cisco (il est ouvert depuis 2013). Il a été développé en améliorant le protocole IGRP, l’ancêtre de l’EIGRP.

 

Il s’agit d’un protocole de routage interne (IGP), au même titre que RIP, OSPF, etc…

Cela veut dire qu’il est capable de réaliser du routage au sein d’un Autonomous System.

Pour faire simple, un AS c’est un ensemble de réseaux sous une même autorité. Sur ces réseaux nous utilisons des protocoles dits IGP (Interior Gateway Protocol).

Entre les AS, c’est-à-dire sur internet, nous utilisons des protocoles EGP (tel que BGP).

 

Retenez donc que l’EIGRP est un protocole de routage interne, comme RIP et OSPF.

 

Autre détail, EIGRP utilise le protocole RTP (Reliable Transport Protocol) pour échanger des infos avec les autres routeurs (à ne pas confondre avec le protocole Real-time Transport Protocole)

Il s’agit d’un protocole de couche 4, semblable au protocole TCP, mais en plus léger.

Il a lui aussi été développé par Cisco.

Comme chaque protocole, il possède une distance administrative.

Elle est de 90 pour les routes internes, et 170 pour les routes externes (importées dans EIGRP).

 

Bien entendu, EIGRP prend en charge le VLSM.

 

Il utilise l’adresse de Multicast 224.0.0.10 pour communiquer avec ses voisins.

 

EIGRP possède un avantage non négligeable, il est capable de calculer une route de secours.

Le protocole va donc garder deux routes pour chaque destination : la route principale (celle avec la meilleure métrique), et une route secondaire. Nous verrons plus tard qu’il faut remplir une condition pour garder une route de secours.

 

Autre avantage, EIGRP est capable de faire du Load Balancing s’il connait plusieurs liens équivalents.

Il peut utiliser jusqu’à 6 liens. Il est aussi capable de faire de l’Unequal Cost Load Ballancing. C’est-à-dire, répartir la charge sur des liens qui n’ont pas la même métrique.

Si R1 veut joindre le réseau 10.3.0.0/24, en temps normal il va passer par R2. La métrique est alors de 100 + 100, soit 200.

Il est donc normal qu’il ne choisisse pas de passer par R4, car la métrique y est de 250.

Mais après configuration, il est possible d’utiliser aussi le lien vers R4.

Pour joindre 10.3.0.0/24, R1 va donc répartir les paquets entre R2 et R4.

 

Enfin, l’EIGRP est capable de router plusieurs types de protocoles : le classique IPv4 (et IPv6), mais aussi de l’IPX et de l’Apple Talk.

 

En résumé :

–          Développé par Cisco

–          IGP (routage interne à un AS)

–          Distance administrative : 90 (170 pour les routes externes)

–          Utilise le protocole RTP pour communiquer

–          Supporte VLSM

–          Utilise 224.0.0.10 pour communiquer

–          Routage multi protocole (IP, IPX, Apple Talk)

 

1.2) Un protocole à vecteur de distance

La plupart diront que c’est un protocole à vecteur de distance.

La plupart ? Oui, car d’autres dirons qu’il est hybride …

 

Afin de mieux saisir cette première notion, faisons quelques rappels !

Qu’est-ce qu’un protocole à vecteur de distance ?

Si vous avez déjà étudié le protocole RIP, cette notion devrait vous être familière.

 

Il s’agit en fait d’un protocole qui n’a pas de vision global du réseau.

 

Quand R1 apprend l’existence du réseau 10.3.0.0 /24 (lequel réseau se trouve derrière R3), il l’apprend par R2.

R2 envoie donc un message à R1, contenant plus ou moins ceci : « Bonjour c’est ton voisin R2. Si tu veux joindre le réseau 10.3.0.0/24, passe par chez moi. Le réseau est à une distance de XXX. »

Au final, R1 ne sait pas réellement ou se trouve le réseau 10.3.0.0/24. Il sait simplement que R2 possède un chemin pour joindre ledit réseau.

On appelle cela un protocole à vecteur de distance.

A mettre en opposition avec un protocole à état de lien (OSPF), qui lui, connait la topologie complète du réseau, et fait lui-même le choix du chemin.

 

Au final, EIGRP est donc un protocole à vecteur de distance, mais qui possède certains avantages des protocoles à état de lien.

Parmi c’est avantages, nous retrouvons une autre notions très importante, la façon dont fonctionnent les MAJ de routage.

 

1.3) Les mises à jour de routage

Un des atouts de l’EIGRP est sa façon de gérer les MAJ de routage.

Vous vous souvenez du protocole RIP qui envoie sa table de routage complète toutes les 30 secondes ?

Pas génial n’est-ce pas ?

L’EIGRP n’envoie des MAJ qu’en cas de changement. C’est-à-dire qu’en l’absence de changement dans l’infrastructure, aucune mise à jour ne circule.

Et quand un changement se produit, la MAJ est propagée directement.

Il en résulte une réactivité bien meilleure.

 

Deuxièmement, seul ce qui a changé est transmis dans la MAJ.

Si une route a été rajoutée dans la table de routage, seule cette route sera transmise dans la MAJ.

 

L’EIGRP est donc peu gourmand en ressource, et très rapide.

 

1.4) Les messages

Même si EIGRP n’est pas un grand bavard, il discute tout de même avec ses voisins.

Il existe 5 types de messages en EIGRP.

 

Hello

Le Hello permet de créer et d’entretenir des relations de voisinage.

Cela fonctionne comme une relation sociale. Un premier bonjour permet de  faire la connaissance avec une autre personne. Ensuite, une prise de nouvelle régulière permet d’entretenir la relation.

EIGRP fait de même. Sauf que lui envoie un Hello toutes les 5 secondes, pour s’assurer que le voisin est toujours Up.

Après 3 Hello sans réponse, EIGRP considère le voisin comme down.

Le Hello est envoyé en Multicast sur l’adresse 224.0.0.10.

 

Update

Je pense qu’il se passe d’explication, non ?

Il permet d’envoyer les MAJ de routage aux voisins. Pour rappel, ce message est envoyé seulement en cas de changement, et seul le changement est inclus dans la MAJ.

Le message Update est envoyé en Multicast quand il y a un changement à annoncer. Quand un nouveau voisin apparait, un Update lui est envoyé en Unicast.

 

Query.

Il est un peu particulier. C’est un message qui est envoyé par un routeur qui cherche une route vers un certain réseau.

Si R2 tombe en panne, R1 n’aura plus de route pour joindre le réseau 10.3.0.0/24.

Il va alors envoyer une Query (en Unicast ou en Multicast) à tous ses voisins, dans l’espoir que l’un d’eux lui propose une route alternative.

Quand un routeur reçoit une requête de Query, s’il n’est pas capable d’y répondre, il la transmet alors à tous ses autres voisins.

Vous l’aurez compris, une requête Query peut aller très loin sur le réseau.

 

Nous reviendrons plus tard sur une notion appelée Stuck In Active.

En bref, il s’agit d’un état dans lequel se trouve le routeur quand il envoie des requêtes Query, et qu’il n’a pas encore reçu toutes les réponses. S’il envoie 4 requêtes (à 4 de ses voisins), il attendra que ses 4 voisins aient répondu aux Query.

Si les voisins ne répondent pas (les Query tournent en boucle, etc…), le routeur attendra 3 minutes, avant d’intégrer une nouvelle route à sa table (à condition qu’une des Query ai rapporté une nouvelle route).

 

Reply

Comment un routeur fait pour répondre à une Query ? Il envoie un Reply (en Unicast).

Ce Reply va indiquer que la destination recherchée peut être jointe en passant par ce routeur, et va donner la métrique.

Si le routeur ne permet pas de joindre la destination voulue, le Reply annonce une métrique infinie.

Prenons un exemple pour mettre les choses au clair :

Voici le topo :

R1 possède une route vers le réseau 10.3.0.0/24. Cette route lui indique de passer par R2.

Donc, tous les messages à destination de 10.3.0.0/24 seront envoyés à R2 (qui se chargera de les envoyer à R3).

Mais voilà, R2 ne répond plus. Après 3 Hello sans réponse, R1 doit se rendre à l’évidence. Son voisin préféré a rendu l’âme, et il n’est plus capable de router des paquets vers R3.

Nous avons dit que le protocole EIGRP est capable de garder une route de secours.

Malheureusement, le lien vers R4 est très lent. R1 a donc choisit de ne pas prendre R4 comme route de secours pour joindre 10.3.0.0/24.

Mais comme R2 n’est plus, R1 doit faire un effort. Il envoie donc une Query à R4, en demandant une route vers 10.3.0.0/24.

R4 répond donc avec un Reply, qu’il connait un chemin pour aller vers 10.3.0.0/24.

La version courte :

–          R2 ne répond plus (3 Hello manqués)

–          R1 envoie une Query à R4

–          R4 envoie un Reply à R1

 

Ack

Ce dernier est beaucoup plus simple. Il sert d’accusé réception pour les Update, Query et Reply.

Les Hello ne renvoient pas de Ack.

 

En résumé :

Hello : Créer et entretenir les relations de voisinage. Toutes les 5 secondes. 3 Hello sans réponse = voisin Down. Envoyé sur 224.0.0.10

Update : MAJ de routage. Envoyée en cas de changement. Seul le changement est inclus.

Query : demande de route pour une destination. Si un routeur ne peut pas répondre, il transmet la Query aux voisins.

Ack : Accusé réception des Update, Query et Reply.

 

1.5) La métrique

Vous l’attendiez n’est-ce pas ?

Comment EIGRP évalue les différentes routes ? Quelle est sa métrique ?

 

Pour la métrique nous parlons des 5 K.

Les voici :

–          K1 : Bande passante

–          K3 : Délai

–          K2 et K4 : fiabilité

–          K5 : charge

EIGRP utilise donc 4 attributs pour juger les routes qu’il apprend.

Les 5 K sont placés dans une formule. Le résultat le plus faible l’emporte.

 

 

Facile n’est-ce pas ?

 

K1 à K5 peuvent prendre la valeur 0 ou 1.

Pour calculer une métrique basée sur la bande passante et le délai, K1 et K3 valent 1, K2, K4 et K5 valent 0.

La formule s’en trouve alors réduite.

Seul K1 et K3 sont utilisés par défaut.

 

Une autre valeur existe. Il s’agit du MTU – Maximum Transmission Unit. Elle représente la taille maximum des PDU que peu gérer le routeur.

Plus un routeur annonce un MTU élevé, plus il est capable de gérer des grands paquets.

Mais cette notion n’entre pas en compte dans le calcul de la métrique, non ?

Tout à fait. Le MTU est annoncé par les routeurs. Il est utilisé pour choisir entre plusieurs routes ayants des métriques équivalentes. Bien sûr, EIGRP peut faire du Load Balancing. Mais s’il possède plus de lien équivalent qu’il n’a le droit d’en utiliser, il devra faire un choix.

Le routeur de prochain saut ayant un MTU plus élevé sera privilégié.

 

En bref, il faut retenir :

–          K1 : Bande passante (utilisé par défaut)

–          K3 : Délai (utilisé par défaut)

–          K2 et K4 : fiabilité

–          K5 : charge

Le MTU est annoncé, mais n’est pas utilisé dans le calcul de la métrique.

 

1.6) La terminologie

Passons à quelque chose de plus complexe.

Rassurez-vous, il n’y a rien de bien méchant.

En EIGRP il existe plusieurs termes. Faisons un petit tour d’horizon.

 

La Feasible Distance

La FD est la distance totale pour joindre une destination.

Plaçons-nous sur R1. Pour joindre 10.3.0.0/24 la FD est de 200 en passant par R2, et de 250 en passant par R4.

 

La Advertised Distance (ou Reported Distance)

Il s’agit de la distance que nous annonce notre voisin pour une certaine destination.

Toujours sur R1, pour joindre 10.3.0.0/24.

L’AD de R2 est 100. L’AD de R4 est 150.

Donc, l’AD annoncé par le voisin + la métrique vers ce voisin = la FD

 

Le Successor

Le Successor est simplement le voisin qui a été choisi pour joindre une destination.

C’est le Next-Hop de la route.

Pour joindre 10.3.0.0/24, R1 aura comme Successor R2.

 

Le Feasible Successor

Le Feasible Successor est le Next-Hop de secours pour une route.

Si le Successor tombe, automatiquement le routeur va envoyer les paquets au FS, qui devient alors Successor.

Il va ensuite chercher un autre FS, si possible.

Et comment devient-on FS ?

Et bien c’est ici que ça se corse.

Pour devenir FS, il faut avoir une AD (Advertised Distance) plus faible que la FD (Feasible Distance) du Successor.

Vous suivez toujours ? Relisez la dernière phrase quelques fois.

Bien. Prenons un exemple, les choses seront plus claires.

 

R1 arrive sur le réseau. Il cherche un Successor et un Feasible Successor pour joindre le réseau 10.3.0.0/24.

Qui devient le Successor ? R2 bien sûr !

La métrique total (Feasible Distance) jusqu’à R3 est de 200.

 

Mais R4 peut-il devenir Feasible Successor ?

R4 annonce une AD de 150.

Nous avons dit que pour devenir FS, il fallait avoir une AD plus faible que la FD du Successor.

R4 à une AD de 150 pour 10.3.0.0/24.

En passant par R2, la FD est de 200.

150 < 200 (AD de R4 < FD de R2). R4 devient donc le Feasible Successor.

Relisez tout cela deux ou trois fois pour bien comprendre.

 

A retenir :

Feasible Distance – FD : métrique totale la plus faible, pour joindre la destination.

Advertised Distance – AD : métrique annoncé par le voisin, pour joindre une destination.

Successor : le voisin que l’on utilise pour joindre une destination.

Feasible Successor – FS : Successor de secours pour une destination. Pour devenir FS, il faut avoir une AD plus faible que la FD du Successor.

 

1.7) Les tables

Maintenant que nous avons vu certaines notions de l’EIGRP, nous pouvons donc aborder les tables.

Celles-ci vont reprendre une bonne partie de ce que nous avons vu.

Il existe 3 tables en EIGRP :

–          La Neighbor Table

–          La Topology Table

–          La Routing Table

 

La Neighbor Table

Que contient-elle ?

Simplement la liste de tous les voisins du routeur. C’est à dire, tous les routeurs directement connectés, et qui utilisent EIGRP.

Voici un exemple :

 

Les 3 routeurs utilisent EIGRP dans l’AS 90.

R1 a pour IP : 172.16.1.1 et 172.16.2.1

R2 : 172.16.1.2

R3 : 172.16.2.3

Les interfaces de Loopback symbolisent des sous-réseaux connectés aux routeurs.

Jetons un coup d’œil à la Neighbor table de R1 :

 

Nous sommes sur R1.

Nous pouvons voir qu’il possède deux voisins : R2 et R3.

Mais la table contient d’autres informations :

–          Interface : derrière qu’elle interface se trouve le voisin

–          Hold : décompte de 15 à 0. Arrivé à 0, le voisin est considéré comme Down. Le compteur revient à 15 à chaque Hello reçu. Comme les Hello sont envoyés toutes les 5 secondes, le décompte ne devrait pas tomber en dessous de 10

–          Uptime : depuis combien de temps connait-on le voisin

–          SRTT – Smooth Round Trip Time : temps nécessaire pour recevoir un Ack après avoir transmis un message

–          RTO – Retransmission Timeout : Combien de temps le routeur attend, avant de retransmettre un message au voisin, si ce dernier n’a pas répondu par un Ack. Le RTO est égale à 6 fois le SRTT

–          Queue count : combien de paquet sont en attente d’être transmis. S’il y a beaucoup de paquet dans la queue, cela indique une congestion

–          Sequence numbers : le compteur augmente à chaque MAJ reçue de ce voisin

 

La Topology Table

J’ai modifié la topologie, pour que l’exemple soit plus fourni.

Le lien entre R3 et R2 est un lien 150M, contre 100M pour les autres.

L’idée ici, est de faire apparaitre des Feasible Successor, et du Load Ballancing.

Nous prendrons l’exemple de R1.

Quand il cherche à joindre 10.2.1.0/24 (c’est-à-dire R2) il passera directement par R2.

R2 sera donc le Successor pour 10.2.1.0 /24. Mais il prendra aussi R3 comme Feasible Successor.

 

Revenons à la Topology Table.

Que contient-elle ?

Elle contient la liste de toutes les destinations joignables, avec le Successor associé, et si possible, le Feasible Successor.

Le terme topologie porte donc à confusion. Le routeur ne connaît pas la topologie complète du réseau. Rappelons qu’EIGRP est un protocole à vecteur de distance.

Voici donc la table de R1 :

Nous pouvons voir que R1 connait toutes les destinations qu’il peut joindre :

–          Le réseau 10.1.0.0 /22 (directement connecté à ses interfaces Loopback)

–          Le réseau 10.2.0.0 /22 (les Loopback de R2)

–          Le réseau 10.3.0.0 /22 (les Loopback de R3)

–          Le réseau 172.16.1.0 (entre R1 et R2)

–          Le réseau 172.16.2.0 (entre R1 et R3)

–          Le réseau 172.16.3.0 (entre R2 et R3)

Pour chaque destination nous pouvons voir le Successor et éventuellement le Feasible Successor.

Prenons le premier exemple en Jaune :

P 10.2.0.0/22, 1 successors, FD is 409600
        via 172.16.1.2 (409600/128256), FastEthernet0/0
        via 172.16.2.3 (435200/170496), FastEthernet0/1

La table nous indique que le routeur connait 1 Successor et qu’il est à une distance de 409600 (la Feasible Distance).

La ligne d’en dessous « via 172.16.1.2 … » représente le Successor (en l’occurrence R2).

Nous avons son IP 172.16.1.2 et la FD 409600 qui bien sûr est la même qu’au-dessus.

La troisième valeur 128256 correspond à l’Advertised Distance que nous a annoncé le Successor (R2) pour la destination. C’est-à-dire la distance entre R2 et 10.2.0.0 /22. Si on y ajoute la distance entre R1 et R2, on obtient la FD.

Enfin, nous avons l’interface derrière laquelle se trouve R2.

Et la deuxième ligne, à quoi correspond-elle ? La table nous annonce un Successor, mais nous affiche deux voisins possibles. A quoi sert le deuxième voisin ?

Il s’agit bien sûr du Feasible Successor !

Nous avons son IP 172.16.2.3 (R3), puis la Feasible distance 435200. Celle-ci est plus élevée que la FD de R2. Il est donc logique que R1 ai choisi R2 comme Successor au lieu de R3.

Vient ensuite l’Advertised Distance 170496. Encore une fois, c’est la distance annoncée par R3 pour joindre 10.2.0.0 /22.

Vous souvenez vous de la Feasible Condition ? Il s’agissait de la condition à remplir pour devenir le Feasible Successor. La condition était d’avoir une Advertised Distance plus faible que la Feasible Distance du Successor.

Il est donc logique que R3 devienne le FS, car 170496 < 409600

Enfin, nous pouvons voir l’interface derrière laquelle se trouve le FS.

 

Vous avez suivi ? Je vous conseille de relire cette dernière partie deux ou trois fois pour bien l’assimiler.

Jetons un œil au dernier exemple en Jaune sur la capture :

P 172.16.3.0/24, 2 successors, FD is 307200
        via 172.16.1.2 (307200/42496), FastEthernet0/0
        via 172.16.2.3 (307200/42496), FastEthernet0/1

La différence est que la table nous indique 2 Successor.

En y regardant de plus près, c’est tout à fait normal : les Feasible Distance sont les mêmes !

 

Mais alors, comment le routeur va choisir quel Successor utiliser ?

Et bien, il ne va pas choisir.

Il va faire ce que l’on appel du Load Balancing.

Quand R1 devra envoyer des paquets vers 172.16.3.0 /24, il enverra un paquet à R2, puis un à R3, puis un à R2, puis un à R3, etc…

 

Je vous ai tout expliqué, sauf une chose.

Que signifie le « P » avant chaque destination dans la table ?

Cela veut dire que la destination est Passive (stable). Le routeur est capable de router des paquets vers ce réseau.

Quand elle devient Active (symbolisé par un A), cela veut dire que le routeur n’est pas capable de router des paquets vers cette destination. Il n’a donc plus de Successor. Il envoie alors des Query pour trouver un nouveau Successor.

 

Plus tard, lors des Labs, vous aurez l’occasion d’aller voir par vous-même les tables.

 

La Table de routage

Le plus facile pour la fin !

Dans cette table se trouvent les Next Hop pour chaques destination.

Vous connaissez déjà la table de routage.

Les routes EIGRP sont symbolisées par un « D » en début de ligne.

Nous retrouvons l’adresse de la destination, la distance administrative (90 pour les routes internes).

La deuxième valeur entre crochet est la métrique. Ou plutôt la FD du Successor.

Vient ensuite l’adresse du Next Hop, le UpTime de la route, et si possible, l’interface de sortie.

 

Voyons certains exemples en détail.

Le premier exemple en jaune :

D       172.16.3.0                 [90/307200] via 172.16.2.3, 04:45:56, FastEthernet0/1                                                      [90/307200] via 172.16.1.2, 04:45:56, FastEthernet0/0

Il s’agit de notre Load Balancing de tout-à-l’heure (dans la Topology Table):

Le routeur possède donc deux Next-Hop pour joindre la destination 172.16.3.0 (car les deux voisins ont une FD équivalente)

Le deuxième exemple en jaune :

D       10.2.0.0/22 [90/409600] via 172.16.1.2, 04:43:14, FastEthernet0/0

Il correspond à cette entrée dans la Topology Table :

La table de topologie nous annonçait 1 Successor et un Feasible Successor.

Nous retrouvons donc un Next Hop dans la table de routage. C’est-à-dire R2, le Successor.

 

Nous verrons plus tard les routes externes.

 

2) Conclusion

 

Nous avons fini la partie théorique sur EIGRP. Nous avons vu une bonne partie des notions théoriques à connaitre.

Certaines notions plus avancées seront abordées plus tard.

Place maintenant à la pratique !