Cisco packet tracer : Découverte du protcole EIGRP

Aujourd’hui j’ai décidé de revenir un peu sur ce bon vieux Packet tracer pour me replonger dans le monde Cisco.

Je me suis récemment remis à feuilleter mes anciens cours Cisco, histoire de revoir un peu quelques notions semi-oubliées, ça ne fait jamais de mal. Je me suis donc dit que réaliser un article sur le protocole de routage EIGRP avec un petit lab’ packet tracer pourrait être sympathique, donc nous voici !

I) EIGRP, c’est quoi ?

EIGRP est donc un protocole de routage dynamique intérieur propriétaire de chez Cisco. Son principal avantage outre sa compatibilité avec IPv4/IPv6 est le fait qu’il permet de régler les métriques sur chacun de ses liens, permettant par exemple de préférer une route 10Gbits/s à une route 1Gbit/s, et permet donc de répartir la charge équitablement sur des liaisons non-identiques. De cette manière, il permet de converger très rapidement lors de coupure de réseau.

C’est peut être encore (sûrement?) flou pour vous, alors on va rapidement décrire quelques notions :

• Protocole de routage dynamique : par opposition aux protocoles de routages statiques, où l’on doit rentrer manuellement les routes dans la table de routage de l’appareil. Pour le dynamique, la configuration est quasi voir entièrement automatique. Voici un petit tableau comparatif tiré du site waytolearnx d’ailleurs :

• Protocole de routage intérieur : par opposition aux protocoles de routage extérieur. Pour résumer, dans un ensemble de réseau géré par une même entité (on appelle cela un système autonome, AS), les protocoles de routage utilisés à l’intérieur sont dit intérieurs, et ceux utilisés à l’extérieur sont bien entendu dits extérieurs. Par exemple :
  • RIP, EIGRP, OSPF sont des protocoles de routage intérieurs ;
  • BGP est un protocole de routage extérieur ;

II) Présentation du lab

Nous allons donc partir sur quelque chose d’assez classique, le but étant ici de mettre en place EIGRP et de bien comprendre son fonctionnement, donc pas de VLAN, DHCP, NAT, ou autre.

Voici le plan d’adressage réseau :

LAN-01 : 192.168.1.0/24
LAN-02 : 192.168.2.0/24
LAN-03 : 192.168.3.0/24
LAN-04 : 192.168.4.0/24

III) Mise en place du lab

Ici je ne vais pas revenir sur l’attribution des adresses IP pour chaque interface ou sur la configuration basique de chaque équipement, j’ai déjà réalisé l’un ou l’autre article traitant de ça.

Bien, nous aurons donc 4 lans classiques avec pour chacun d’eux un router. Notre but sera d’inter-connecter ces 4 réseaux en utilisant le protocole EIGRP qui est comme vous le verrez très simple et rapide à mettre en oeuvre.

Sauf que, car il faut toujours un bémol, je vais devoir encore vous parler théorie et vous expliquer la notion de masque inverses, ou wildcard mask et après promis je vous fiche la paix et on passe à la pratique !

Donc, ce qu’il faut savoir c’est que chez Cisco (et d’autres fabricants mais soit), quand il s’agit de configurer des ACLs, du NAT, ou justement certains protocoles de routage, les masques de sous-réseaux classiques ne sont pas suffisant. Je m’explique.

Imaginons que l’on ait un routeur avec 4 interfaces présentes dans le même réseau, mais dans des sous-réseaux différents, comme ici :

On a donc quatre réseaux différents, mais tous basés sur le réseau 172.168.0.0/16, jusque là vous me suivez ? Le soucis, c’est qu’EIGRP comme d’autres protocoles fonctionnent via la notion de Classfull Configuration, c’est-à-dire que pour notre protocole de routage, c’est quatre réseaux bien que différents sont identiques, car de « base » ils « reposent » sur le réseau en /16, donc EIGRP ne vérifiera que les 16 premiers bits de chaque adresse réseaux, à savoir 172.168, ce qui est quand même problématique.

Imaginons que l’on veuille exclure les deux interfaces Serial en 172.168.3.0/24 et 172.168.4.0/24, nous allons devoir utilisé un masque inverse, un wildcard mask.

Si l’on utilise un wildcard en 0.0.0.255, cela équivaut à un masque /24 (je vous expliquerai plus bas), et si l’on dit à EIGRP ceci :

Router(config-router)# network 172.168.1.0 0.0.0.255
Router(config-router)# network 172.168.2.0 0.0.0.255

EIGRP vérifiera les 24 premiers bits de l’addresse et non plus les 16 premiers bits. Il laissera donc tranquille nos deux adresses Serial en 172.168.3.0 et 4.0 car elles ne matchent pas à celles juste au-dessus.

Voici un tableau récapitulatif de correspondance d’octets masques de sous-réseaux/masques génériques tiré du site Linuxtricks :

Retournons donc à notre lab, histoire d’avoir un autre exemple pour bien saisir la chose.

Ici nous allons donc devoir utiliser ces fameux masques inverses, car les adresses de notre « WAN » sont basées sur l’addresse 10.0.0.0/16, et comme dit plus haut, EIGRP ainsi que d’autres protocoles ne comprennent pas la notion de masques de sous-réseaux, et cela risque donc de poser quelques soucis.

Ici nous utiliserons donc une wildcard 0.0.0.3 qui équivaut donc à toutes les addresses contenues dans un /30, comme besoin ici. Pour calculer le wildcard mask il suffit de soustraire le masque voulu sur base d’un /32 :

  255.255.255.255 (/32)
- 255.255.255.252 (/30)
-----------------
=   0.  0.  0.  3 

De cette manière, si on reprend donc le réseau qui relie le router R1 à R2 à savoir 10.0.0.0/30, le wildcard mask ne prendra en compte que nos deux addresses disponibles, à savoir 10.0.0.1/30 et 10.0.0.2/30, et non pas tout le réseau 10.0.0.0/8 avec ses 16777214 hôtes disponibles…

Si tout cela est encore abscon pour vous, reportez-vous à la description d’EIGRP en début d’article ! Grossièrement, on déclare simplement les réseaux directement connectés à notre routeur, ni plus, ni moins !

On se connecte donc pour commencer sur le router R1 et on active EIGRP avec l’ASN 100 puis on renseigne les réseaux directement connectés, avec les wildcard adéquats (l’ASN est un numéro qui doit être identique sur chacun des membres du réseau EIGRP, il doit être compris entre 1 et 65 535) :

Ici nous n’avons setup que le réseau local de R1 ainsi que le réseau vers R2, et si l’on se rend sur R2 justement pour rajouter son réseau local et sa liaison vers R1, un message devraît apparaître nous disant qu’un nouveau neighbor (voisin) est détecté :

Si l’on vérifie d’ores et déjà la table de routage du routeur R1, on peut voir qu’une nouvelle entrée de type D (pour EIGRP) est apparue :

Ensuite c’est la même histoire, il ne reste qu’à rajouter les réseaux directements connectés sur chaque router, et au final vous devriez obtenir ceci (ici il s’agit d’une capture d’écran du router R3) :

Et si ensuite via par exemple le PC-09 présent dans le LAN-03 nous essayons de ping l’une des deux IP publiques du router R1 :

On voit que cela fonctionne parfaitement ! Le routage est donc bien fonctionnel.

Je vous ai parlé en début d’article qu’un des principaux avantages d’EIGRP est de pouvoir indiquer la bande passante de chaque lien pour préférer certaines routes plutôt que d’autres, pour cela rien de plus simple. Imaginons que l’on veuille dire à EIGRP que le lien reliant R1 à R2 est en 100Mbp/s :

R1(config)# inteface Serial0/3/0
R1(config-if)# bandwith 1000000
R2(config)# inteface Serial0/3/0
R2(config-if)# bandwith 1000000

On choisi notre interface, et on utilise simplement la commande bandwith valeur et le tour est joué ! Après bien entendu il est possible de réaliser une configuration bien plus poussée en modifiant d’autres paramètres, mais nous allons nous contenter de la configuration basique ici.

Pour vérifier que notre routage est bien fonctionnel, on peut couper les liens du router R4 et on peut voir que le premier ping du PC du LAN-01 vers celui du LAN-03 ne passe pas, mais que le reste suit sans problèmes :

Tout est donc bon ! J’espère donc vous avoir fait (re?)découvrir ce protocole de routage, et vous avoir un peu éclairé sur la notion de masque inverse. Je pense refaire d’autres petits labs de ce genre si vous trouvez cela intéressant, je trouve pour ma part que ça change un peu des classiques labs avec pfSense 😉

Bonne fin de week-end à vous !