Routeurs et redondance : VRRP

Cet article a pour objectif de :

–         vous présenter le (ou les) protocole(s) utilisés pour permettre la redondance sur des routeurs CISCO.

–         vous expliquer la théorie, nécessaire à une bonne compréhension de la pratique (et de l’article…)

–         vous donner un exemple concret de configuration !

 

 

Tout d’abord, présentons le contexte.

 

De nos jours, les réseaux informatiques sont de plus en plus grands, compliqués, modernes… mais surtout, ils deviennent de plus en plus « logiques ». C’est-à-dire virtuels. Fini le temps où un réseau était un LAN, physiquement délimité par un routeur. Désormais, les VLANs sont omniprésents, tout comme les interfaces virtuelles, les IPs virtuelles, etc…

Comme détaillé à l’instant, les réseaux informatiques sont logiques. Certes. Mais ils sont aussi plus grands. C’est-à-dire qu’il y a plus de périphériques, plus d’utilisateurs, plus de distance (avec les VLANs, nos LANs ne sont plus géographiquement limités) et souvent plus de débit…

Or, tout LAN a une gateway (passerelle, ou « passerelle par défaut »). Exceptionnellement, ou dans les petites entreprises, la gateway peut être un serveur (Windows Server 2008 R2 par exemple) ou un TMG Forefront. Mais plus généralement, et systématiquement dans les grandes entreprises, une gateway est un routeur.

 

D’où : si la gateway est un routeur, et que le nombre de périphérique augmente de plus en plus, comment assurer un service constant de cette gateway ? Comment être certain que le routeur de sortie ne va pas couper les liens, interdisant toute communication entre le (ou les) LANs et ce qu’il y a derrière (autres LANs, Internet, liaison WAN…) à un moment ou à un autre ?

 

Plus simplement : comment assurer une tolérance de panne efficace et sûre au niveau de toutes nos gateway, afin d’obtenir une disponibilité (DICP) maximale ?

 

La solution est la redondance : si notre routeur tombe, un autre prend sa place. Très simple, non ?

Très, peut être pas, mais simple, oui !

Car effectivement, CISCO (et d’autres) y ont pensé ! Depuis longtemps, les environnements CISCO utilisent un protocole nommé HSRP (Hot Standby Router Protocol) pour gérer tout cela.

 

Je pourrais vous présenter HSRP, mais l’apparition (assez récente) de VRRP change la donne. HSRP est propriétaire CISCO, alors que VRRP est l’adaptation de HSRP à des fins de normalisation : protocole disponible pour tous.

 

VRRPv3 (dernière version), pour Virtual Router Redundancy Protocol, est défini dans la RFC 5798.

 

Comme je ne suis pas le seul à présenter VRRP sur l’Internet, je vous rassure tout de suite : je ne vais pas paraphraser Wikipédia ou l’article d’un autre. Une explication simple et basique, même pas tellement technique, et un bon exemple.

Voilà les ingrédients de la vulgarisation (et donc de la compréhension) !

 

 

1] Comment ça marche ?

 

Vous avez donc deux routeurs (identiques, si possible). Pour l’article, nos deux routeurs seront des routeurs CISCO (2921 par exemple).

Ces deux routeurs sont reliés à un switch, que ce switch soit un switch Access ou pas n’ayant pas vraiment d’importance.

Nous avons donc : Internet/WAN/Autres LANs -> 2 routeurs -> 1 switch -> [d’autres switchs, mais c’est facultatif] -> les périphériques clients.

 

VRRP1

Schéma du réseau sans VRRP

 

Habituellement, chaque périphérique du LAN doit être configuré (soit par DHCP soit de façon statique et manuelle) avec une adresse IP, un masque de sous-réseau (définissant son appartenance au (V)LAN) et une adresse de passerelle.

Et bien dans notre cas, c’est identique ! Sauf que… quelle adresse de passerelle choisir ? Celle du routeur 1 (R1) ou du deuxième (R2) ?

La réponse ? Aucune des deux 😉

 

Et oui ! N’oublions pas que la présence de R2 n’est justifiée que par le besoin de redondance, et donc de VRRP.

Pour l’instant, nous n’avons pas mis en place VRRP, ni même expliqué son fonctionnement.

Voici l’architecture logique cible, une fois VRRP configuré sur nos deux routeurs :

 

VRRP2

Schéma du réseau avec VRRP

 

Que voyons-nous ?

Toujours notre réseau simplifié, avec nos deux routeurs R1 et R2, notre switch SW1 et enfin nos périphériques utilisateurs (serveurs, imprimantes, PCs…). Mais le cadre bleu, nouveau, représente VRRP.

 

En fait, avec VRRP activé, voilà ce qu’il se passe :

1)      Nos deux routeurs ont chacun une priorité ainsi que divers paramètres sur lesquels nous reviendrons dans la suite de l’article.

2)      Le routeur possédant la plus haute priorité est élu Maitre.

3)      L’autre passe en statut « standby ».

4)      L’adresse IP virtuelle (en bleu sur le schéma, 10.10.0.1) est alors utilisée uniquement par le routeur Maitre.

5)      Si les priorités changent (par exemple, lorsqu’un lien tombe, un service réduit la priorité du routeur), une élection a lieu à nouveau afin de désigner le routeur Maitre.

 

Ainsi, si PC1 ping l’adresse IP 10.10.0.1, il ne saura pas quel routeur répond. Cette adresse sera joignable, comme si elle correspondait à une interface physique d’un vrai routeur. En fait, cette IP est virtuelle, et n’est donc qu’un « point » dans le réseau. Point relié aux deux routeurs. C’est ensuite VRRP qui définit quelle interface (et donc quel routeur) doit répondre aux requêtes.

 

Ok. Si cela est (vraiment) compris, le plus dur est fait. Je vous encourage à relire les 2 ou 3 derniers paragraphes et à bien regarder le schéma.

 

Comprenez bien que si R1 est élu maitre, alors PC1 et PC2 passeront par le lien WAN (l’éclair jaune sur le schéma) de R1 (celui de gauche donc) pour accéder à Internet, et non celui de R2.

Le routeur R2 ne sera d’ailleurs pas sollicité, si ce n’est par quelques protocoles de routage ou autres, et bien sur par VRRP. Mais ni PC1, ni PC2 ne passeront par R2 pour communiquer avec Internet ou avec un LAN distant : VRRP ne fait pas de load-balancing (répartition de charge), mais uniquement de la redondance (tolérance de pannes).

 

 

2] Configuration et exemples :

 

Maintenant, attaquons la configuration. Et qui dit configuration, dit exemple !

 

R1> enable

R1# conf t

R1(config)# interface FastEthernet 0/0                                      ! Mode configuration d’interface

R1(config-if)# ip address 10.10.0.2 255.255.252.0                ! Adresse IP de F0/0 sur R1

R1(config-if)# no shutdown                                                                  ! Activation de l’interface

R1(config-if)# interface Serial0/0/0                                               ! Mode configuration d’interface

R1(config-if)# ip address 172.16.1.2 255.255.255.252         ! Adresse IP de S0/0/0 sur R1

R1(config-if)# no shutdown                                                                  ! Activation de l’interface

R2(config)# interface FastEthernet 0/0

R2(config-if)# ip address 10.10.0.3 255.255.252.0

R2(config-if)# no shutdown

R2(config-if)# interface Serial0/0/0

R2(config-if)# ip address 172.16.1.6 255.255.255.252

R2(config-if)# no shutdown

 

Ici, rien à voir avec VRRP, nous nous sommes contentés d’attribuer les IPs du schéma sur nos interfaces, avec le masque correspondant (/22 = 255.255.252.0 ; soit 1024 adresses donnant 1022 hosts).

Par convention et mesure de sécurité, il est préférable de configurer les différentes interfaces AVANT de configurer VRRP. Dites vous bien que généralement, il n’y a pas uniquement deux routeurs…

 

Une fois cela fait, attaquons nous au cœur du sujet : VRRP.

 

R1(config)# interface FastEthernet 0/0                  ! Mode configuration d’interface

R1(config-if)# vrrp 10 priority 160                                ! Réglage de la priorité de R1

R1(config-if)# vrrp 10 timers advertise 3                 ! Réglage du timer “advertise”

R1(config-if)# vrrp 10 timers learn                               ! Réglage du timer “learn”

R1(config-if)# vrrp 10 ip 10.10.0.1                                   ! Réglage de l’IP virtuelle du group

R1(config-if)# vrrp 10 preempt                                        ! Activation du preempt

R1(config-if)# vrrp 10 enable                                             ! Facultatif

 

Et c’est tout pour le routeur R1.

 

Détaillons :

– Ligne 1 (L1) : Nous entrons en mode configuration d’interface.

– L2 : Nous attribuons une priorité à l’interface, c’est-à-dire au routeur. De plus, nous créons par la même occasion le groupe « 10 » (appelé VRID pour Virtual Routeur ID)

– L3/L4 : Réglage des délais d’avertissement (envoie de paquet aux autres routeurs du groupe VRRP pour vérifier l’état du VRID) et de « learn » (fréquence d’apprentissage des infos VRRP)

– L5 : Attribution de l’adresse IP virtuelle du VRID, c’est-à-dire l’IP représentant le groupe qui sera utilisée par R1 ou R2 selon le cas.

– L6 : Cette option autorise un routeur à devenir maitre si sa priorité est supérieure à celle du maitre actuel, même si ce maitre fonctionne correctement. Sans cette option, il y aura réélection si et seulement si le routeur maitre tombe.

– L7 : On active le VRID/routeur virtuel (facultatif).

 

 

Rebelotte sur R2 :

 

R2(config)# interface FastEthernet 0/0

R2(config-if)# vrrp 10 priority 100                          ! Priorité inférieure par choix !!

R2(config-if)# vrrp 10 timers advertise 3

R2(config-if)# vrrp 10 timers learn

R2(config-if)# vrrp 10 ip 10.10.0.1                             ! Même IP que sur R1 ! Logique.

R2(config-if)# vrrp 10 preempt

R2(config-if)# vrrp 10 enable

 

Seule la priorité a changé.

 

Explications :

Nos deux routeurs sont configurés pour appartenir à un seul et même VRID, c’est-à-dire un « groupe VRRP ». En fait, c’est un routeur virtuel (ou logique si vous préférez), un « faux routeur qui n’existe pas physiquement mais seulement virtuellement ». Le fait de créer ce VRID équivaut presque à la création d’un troisième routeur (R3) dans notre schéma : le routeur « bleu ». Ces deux routeurs, R1 et R2 donc, ont des IPs différentes sur leurs interfaces. Le VRID, lui, possède une IP virtuelle : 10.10.0.1.

 

La priorité de R1 étant supérieure à R2 (160 > 100), c’est R1 qui sera élu maitre. C’est donc R1 qui va posséder l’adresse virtuelle 10.10.0.1, et répondre aux différentes requêtes adressées à cette adresse : telnet, ssh, ping…

 

Si, par le plus grand des hasards, R1 s’éteint ou n’est plus joignable (F0/0 down notamment), il y a réélection dans le groupe. R2 est ici le seul autre routeur, il va donc être élu maitre. S’il y avait eu 3 routeurs dans le VRID, et donc 2 routeurs restants, celui avec la plus haute priorité serait devenu maitre. Et, si les 2 restants avaient eu la même priorité, celui avec l’adresse IP la plus élevée serait passé maitre.

 

Une fois R2 devenu maitre, c’est lui qui va répondre à l’adresse virtuelle (10.10.0.1). Le temps de transition est faible – et paramétrable ; généralement configuré pour un délai de 120 secondes, soit 2 minutes, afin d’éviter un changement de routeur à chaque petite coupure de connexion (plus fréquente qu’on ne le pense, mais sans réel danger pour les données).

 

On pourrait presque imager cela en prenant l’exemple du NAT : une fois le routeur maitre élu, son interface (F0/0) est liée au VRID, et donc l’IP de F0/0 est reliée à celle du VRID. Ainsi, 10.10.0.2 est directement liée à 10.10.0.1.

 

Résultat : si vous appelez 10.10.0.1, c’est en fait 10.10.0.2 et donc F0/0 de R1, qui vous répond 😉

 

Fortiche VRRP hein ? Et ce protocole étant une norme, il est surtout multi-tout : OS, plateforme, fabricant… Bien sur, encore faut-il qu’un module/paquet existe pour l’exploiter.

 

 

3] Bonus : surveiller une interface

 

Là où VRRP prend encore plus d’importance et d’intérêt, c’est qu’il est capable de surveiller l’état d’une interface (ou de plusieurs) et d’agir en fonction.

 

Utilisation typique : on force R1 comme maitre (en lui donnant une priorité supérieure à celle de R2) et on utilise donc la table de routage ainsi que la liaison WAN de ce routeur. Si l’interface reliée au LAN tombe, il y a réélection. Mais que se passe-t-il si la liaison WAN tombe ? Rien… Comme VRRP est configuré sur l’interface LAN F0/0 de R1, l’état de S0/0/0 ne l’intéresse pas : VRRP ne sait même pas si cette interface est up ou down !

 

Ne serait ce pas encore plus efficace si VRRP forçait une réélection du routeur maitre dès qu’une des deux liaisons de R1 tombe ? Histoire d’utiliser la liaison WAN de R2 pour sortir du réseau, au lieu d’être bloqué !

Certes. Il est heureusement possible de faire cela !

 

R1(config)# track 1 interface serial 0/0/0 line-protocol

R1(config)# interface F0/0

R1(config-if)# vrrp 10 track 1 decrement 100

 

Sur la première ligne, nous définissons quelle interface “surveiller” (to track en anglais). On attribut un identifiant (1 ici) à cette surveillance, on y désigne l’interface puis le type de surveillance (line-protocol = état du lien ; ip-routing = routage activé ou pas + état du lien).

 

Puis après être entré en mode configuration d’interface (la bonne, celle appartenant au VRID), nous attribuons au VRID 10 la bonne surveillance (via l’identifiant précédemment désigné, « 1 »), suivi du plus important : l’action à prendre en cas de problème. Ici, nous allons enlever 100 à la priorité de R1. Résultat : 160 – 100 = 60 ; 60 < 100 ; d’où : R2 devient maitre.

 

Ainsi, en ne rajoutant que 2 lignes dans notre fichier de configuration de R1 (nous n’avons pas touché à R2 !), nous évitons bien des soucis. Désormais, si la liaison WAN de R1 tombe, le LAN pourra toujours communiquer avec l’extérieur grace à la liaison WAN de R2. Et la transition passera inaperçue !

 

Et bien entendu, vous pouvez appliquer la même chose de l’autre côté, par mesure de sécurité.

 

 

4] Pour aller plus loin !

 

Cet article s’achève. Vous êtes désormais capable de mettre en place VRRP sur un routeur CISCO. Et surtout, vous devriez avoir compris le principe de ce protocole, très important et très utilisé (en fait, HSRP – l’ancêtre propriétaire CISCO – est majoritairement utilisé dans les environnements cisco, mais les services IT sont en train de migrer ; et VRRP est très très proche de HSRP).

 

Pour approfondir, en plus des articles de bloggeurs divers et variés, vous retrouverez toutes les infos nécessaires sur le site (la Bible, devrais je dire) de CISCO, notamment :

–         VRRP sur Cisco.com

–         Configuring VRRP sur Cisco.com

–         VRRP (Fr) sur Wikipédia

–         VRRP (En) sur Wikipédia

 

N’hésitez pas à poser vos questions dans les commentaires, s’il y en a !

Et partagez l’article s’il vous a plu !

2 comments

  1. Salut
    merci pour l’article et je le trouve très intéressent. Je voudrais savoir si c’est possible de configurer la priorité sur un seul routeur abritant plusieurs (3) nœuds internet déversant un seul LAN.Merci

  2. C’est vraiment important mais je voudrais savoir si l’un des routeur tombe est ce que l’autre peut prendre entierement la charge de la connexion

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *