Comprendre le VRRP
Le protocole VRRP (Virtual Router Redundancy Protocol) peut être utilisé pour créer des plates-formes de routage virtuelles redondantes sur un LAN, ce qui permet de router le trafic sur le LAN sans dépendre d’une plate-forme de routage unique.
Comprendre le VRRP
Pour Ethernet, Fast Ethernet, Gigabit Ethernet, 10-Gigabit Ethernet et les interfaces logiques, vous pouvez configurer le protocole VRRP (Virtual Router Redundancy Protocol) ou VRRP pour IPv6. VRRP permet aux hôtes d’un LAN d’utiliser des plates-formes de routage redondantes sur ce LAN sans nécessiter plus que la configuration statique d’une route par défaut unique sur les hôtes. Les plateformes de routage VRRP partagent l’adresse IP correspondant à la route par défaut configurée sur les hôtes. À tout moment, l’une des plates-formes de routage VRRP est la principale (active) et les autres sont des sauvegardes. En cas de défaillance de la plate-forme de routage principale, l’une des plates-formes de routage secondaire devient la nouvelle plate-forme de routage principale, fournissant une plate-forme de routage virtuelle par défaut et permettant de router le trafic sur le LAN sans dépendre d’une plate-forme de routage unique. Avec VRRP, un périphérique de sauvegarde peut prendre en charge un périphérique par défaut défaillant en quelques secondes. Cela se fait avec un trafic VRRP minimal et sans aucune interaction avec les hôtes. Le protocole de redondance de routeur virtuel n’est pas pris en charge sur les interfaces de gestion.
Les équipements exécutant VRRP choisissent dynamiquement les équipements principaux et de secours. Vous pouvez également forcer l’attribution des périphériques principaux et de secours en utilisant les priorités de 1 à 255, 255 étant la priorité la plus élevée. Dans le fonctionnement VRRP, l’appareil principal par défaut envoie des messages aux appareils de secours à intervalles réguliers. L’intervalle par défaut est de 1 seconde. Si un périphérique de sauvegarde ne reçoit pas d’annonce pendant une période définie, le périphérique de secours ayant la priorité la plus élevée suivante prend le relais en tant que périphérique principal et commence à transférer les paquets.
La priorité 255 ne peut pas être définie pour les interfaces VLAN routées (RVI).
Pour minimiser le trafic réseau, le VRRP est conçu de manière à ce que seul l’appareil qui fait office de périphérique principal envoie des messages VRRP à un moment donné. Les périphériques de sauvegarde n’envoient aucune publicité jusqu’à ce qu’ils assument le rôle principal.
Le VRRP pour IPv6 permet de basculer beaucoup plus rapidement vers un autre routeur par défaut que les procédures de découverte de voisins IPv6. Les déploiements classiques n’utilisent qu’un seul routeur de secours.
Ne confondez pas les plates-formes de routage VRRP principale et de secours avec les commutateurs principaux et de secours d’une configuration Virtual Chassis . Les membres principal et de secours d’une configuration Virtual Chassis composent un seul hôte. Dans une topologie VRRP, un hôte fonctionne comme plate-forme de routage principale et un autre comme plate-forme de routage de secours, comme illustré à la Figure 3.
VRRP est défini dans la RFC 3768, Virtual Router Redundancy Protocol. Le VRRP pour IPv6 est défini dans draft-ietf-vrrp-ipv6-spec-08.txt, Virtual Router Redundancy Protocol for IPv6. Voir aussi draft-ietf-vrrp-unified-mib-06.txt, Définitions des objets gérés pour le VRRP sur IPv4 et IPv6.
Même si VRRP, tel que défini dans la RFC 3768, ne prend pas en charge l’authentification, l’implémentation Junos OS de VRRP prend en charge l’authentification telle que définie dans la RFC 2338. Cette prise en charge est obtenue grâce aux options de rétrocompatibilité du RFC 3768.
Sur les commutateurs EX2300 et EX3400, le protocole VRRP doit être configuré avec un intervalle Hello de 2 secondes ou plus avec un intervalle mort d’au moins 6 secondes pour éviter les problèmes lors d’opérations gourmandes en ressources processeur, tels que le basculement du moteur de routage, les problèmes d’interface et la collecte exhaustive de données à partir du moteur de transfert de paquets.
La figure 1 illustre une topologie VRRP de base. Dans cet exemple, les routeurs A, B et C exécutent VRRP et constituent ensemble un routeur virtuel. L’adresse IP de ce routeur virtuel est 10.10.0.1 (la même adresse que l’interface physique du routeur A).
de base
Comme le routeur virtuel utilise l’adresse IP de l’interface physique du routeur A, le routeur A est le routeur VRRP principal, tandis que les routeurs B et C fonctionnent comme des routeurs VRRP de secours. Les clients 1 à 3 sont configurés avec l’adresse IP de passerelle par défaut 10.10.0.1. En tant que routeur principal, le routeur A transfère les paquets envoyés à son adresse IP. Si le routeur virtuel principal tombe en panne, le routeur configuré avec la priorité la plus élevée devient le routeur virtuel principal et fournit un service ininterrompu aux hôtes LAN. Lorsque le routeur A récupère, il redevient le routeur virtuel principal.
Dans certains cas, au cours d’une session d’héritage, il y a un court laps de temps pendant lequel deux routeurs sont en état principal-primaire. Dans de tels cas, les groupes VRRP qui héritent de l’État envoient des messages VRRP toutes les 120 secondes. Ainsi, il faut jusqu’à 120 secondes aux routeurs pour récupérer après être passés de l’état Primaire-Principal à l’état Secours.
Les routeurs ACX Series peuvent prendre en charge jusqu’à 64 entrées de groupe VRRP. Il peut s’agir d’une combinaison de familles IPv4 ou IPv6. Si l’un des membres de la famille (IPv4 ou IPv6) est configuré uniquement pour VRRP, 64 identifiants de groupe VRRP uniques sont pris en charge. Si les familles IPv4 et IPv6 partagent le même groupe VRRP, seuls 32 identifiants VRRP uniques sont pris en charge.
Les routeurs ACX Series prennent en charge VRRP version 3 pour les adresses IPv6.
Le routeur ACX5448 prend en charge RFC 3768 VRRP version 2 et RFC 5798 VRRP version 3. Le routeur ACX5448 prend également en charge la configuration VRRP sur Ethernet agrégé et les interfaces IRB (Integrated Routing and Bridging).
Les limitations suivantes s’appliquent lors de la configuration de VRRP sur le routeur ACX5448 :
-
Configurez un maximum de 16 groupes VRRP.
-
L’interopérabilité des VRRP version 2 et VRRP version 3 n’est pas prise en charge.
-
Le traitement des délégués VRRP n’est pas pris en charge.
-
L’authentification VRRP version 2 n’est pas prise en charge.
La figure 1 illustre une topologie VRRP de base avec des commutateurs EX Series. Dans cet exemple, les commutateurs A, B et C exécutent VRRP et constituent ensemble une plate-forme de routage virtuelle. L’adresse IP de cette plate-forme de routage virtuel est 10.10.0.1 (la même adresse que l’interface physique du commutateur A).
EX Series
La figure 3 illustre une topologie VRRP de base utilisant des configurations Virtual Chassis. Les commutateurs A, B et C sont chacun composés de plusieurs Juniper Networks interconnectés EX4200 Commutateurs Ethernet. Chaque configuration de Virtual Chassis fonctionne comme un commutateur unique, qui exécute VRRP, et constituent ensemble une plate-forme de routage virtuelle. L’adresse IP de cette plate-forme de routage virtuel est 10.10.0.1 (la même adresse que l’interface physique du commutateur A).
La plate-forme de routage virtuel utilisant l’adresse IP de l’interface physique du commutateur A, le commutateur A est la plate-forme de routage VRRP principale, tandis que les commutateurs B et C fonctionnent comme des plates-formes de routage VRRP de secours. Les clients 1 à 3 sont configurés avec l’adresse 10.10.0.1 IP de passerelle par défaut, car le routeur principal, le commutateur A, transfère les paquets envoyés à son adresse IP. En cas de défaillance de la plate-forme de routage principale, le commutateur configuré avec la priorité la plus élevée devient la plate-forme de routage virtuelle principale et fournit un service ininterrompu aux hôtes LAN. Lorsque le commutateur A se rétablit, il redevient la principale plate-forme de routage virtuel.
Présentation du VRRP et du VRRP pour IPv6
Vous pouvez configurer le protocole VRRP (Virtual Router Redundancy Protocol) et VRRP pour IPv6 pour les interfaces suivantes :
Ethernet
Fast Ethernet
Ethernet cuivre à trois vitesses
Gigabit Ethernet
10 Gigabit Ethernet LAN/WAN PIC
Interfaces logiques Ethernet
VRRP et VRRP pour IPv6 permettent aux hôtes d’un LAN d’utiliser des routeurs redondants sur ce LAN sans nécessiter plus que la configuration statique d’une route par défaut unique sur les hôtes. Les routeurs VRRP partagent l’adresse IP correspondant à la route par défaut configurée sur les hôtes. À tout moment, l’un des routeurs VRRP est le principal (actif) et les autres sont des sauvegardes. En cas de défaillance du routeur principal, l’un des routeurs de secours devient le nouveau routeur principal, fournissant ainsi toujours un routeur virtuel par défaut et permettant au trafic sur le LAN d’être acheminé sans dépendre d’un seul routeur.
VRRP est défini dans la RFC 3768, Virtual Router Redundancy Protocol.
Pour obtenir des informations générales, des instructions de configuration et des résumés d’instructions sur VRRP et VRRP pour IPv6, reportez-vous au Guide de l’utilisateur haute disponibilité de Junos OS.
Prise en charge de Junos OS pour VRRPv3
L’avantage de l’utilisation de VRRPv3 est que VRRPv3 prend en charge les familles d’adresses IPv4 et IPv6, alors que VRRPv2 ne prend en charge que les adresses IPv4.
Les rubriques suivantes décrivent la prise en charge et l’interopérabilité de VRRPv3 par Junos OS, ainsi que certaines différences entre VRRPv3 et ses précurseurs :
- Prise en charge VRRP de Junos OS
- Différences de comportement de la somme de contrôle VRRP IPv6
- Interopérabilité VRRP
- Mise à niveau de VRRPv2 vers VRRPv3
- Fonctionnalité des fonctionnalités VRRPv3
Prise en charge VRRP de Junos OS
Dans les versions antérieures à la version 12.2, Junos OS prenait en charge RFC 3768, Virtual Router Redundancy Protocol (VRRP) (pour IPv4) et Internet draft draft-ietf-vrrp-ipv6-spec-08, Virtual Router Redundancy Protocol for IPv6.
VRRPv3 n’est pas pris en charge sur les routeurs utilisant des versions antérieures à la version 12.2 de Junos OS, ni pour IPv6 sur les commutateurs QFX10000.
VRRPv3 pour IPv6 est pris en charge sur le QFX10002-60C.
À partir de la version 12.2, Junos OS prend en charge :
RFC 3768, Protocole de redondance de routeur virtuel (VRRP)
RFC 5798, Protocole de redondance de routeur virtuel (VRRP) version 3 pour IPv4 et IPv6
RFC 6527, Définitions d’objets gérés pour le protocole VRRPv3 (Virtual Router Redundancy Protocol)
VRRP (pour IPv6) sur les routeurs qui utilisent Junos OS version 12.2 et ultérieure n’interagit pas avec VRRP (pour IPv6) sur les routeurs avec des versions antérieures de Junos OS en raison des différences dans les calculs de somme de contrôle VRRP. Voir Différences de comportement de la somme de contrôle VRRP IPv6.
Différences de comportement de la somme de contrôle VRRP IPv6
Vous devez tenir compte des différences de somme de contrôle suivantes lors de l’activation des réseaux VRRP IPv6 :
Dans les versions antérieures à la version 12.2 de Junos OS, lorsque VRRP pour IPv6 est configuré, la somme de contrôle VRRP est calculée conformément à la section 5.3.8 de la RFC 3768, Protocole de redondance de routeur virtuel (VRRP).
À partir de la version 12.2 de Junos OS, lorsque VRRP pour IPv6 est configuré, que VRRPv3 soit activé ou non, la somme de contrôle VRRP est calculée conformément à la section 5.2.8 de la RFC 5798, VRRP (Virtual Router Redundancy Protocol) version 3 pour IPv4 et IPv6.
De plus, le pseudo-en-tête n’est inclus que lors du calcul de la somme de contrôle VRRP IPv6. Le pseudo-en-tête n’est pas inclus dans le calcul de la somme de contrôle VRRP IPv4.
Pour que le routeur avec Junos OS version 12.2 (ou versions ultérieures de Junos OS) IPv6 VRRP interagisse avec le routeur exécutant une version de Junos OS antérieure à la version 12.2, incluez l’instruction de
checksum-without-pseudoheaderconfiguration au niveau de la[edit protocols vrrp]hiérarchie dans le routeur exécutant Junos OS version 12.2 ou ultérieure.L’utilitaire
tcpdumpde Junos OS version 12.2 et ultérieure calcule la somme de contrôle VRRP conformément à la RFC 5798, VRRP (Virtual Router Redundancy Protocol) version 3 pour IPv4 et IPv6. Par conséquent, lorstcpdumpde l’analyse de paquets VRRP IPv6 provenant d’anciennes versions de Junos OS (antérieures à la version 12.2 de Junos OS), le message s’affichebad vrrp cksum:23:20:32.657328 Out ... -----original packet----- 00:00:5e:00:02:03 > 33:33:00:00:00:12, ethertype IPv6 (0x86dd), length 94: (class 0xc0, hlim 255, next-header: VRRP (112), length: 40) fe80::224:dcff:fe47:57f > ff02::12: VRRPv3-advertisement 40: vrid=3 prio=100 intvl=100(centisec) (bad vrrp cksum b4e2!) addrs(2): fe80::200:5eff:fe00:3,2001:4818:f000:14::1 3333 0000 0012 0000 5e00 0203 86dd 6c00 0000 0028 70ff fe80 0000 0000 0000 0224 dcff fe47 057f ff02 0000 0000 0000 0000 0000 0000 0012 3103 6402 0064 b4e2 fe80 0000 0000 0000 0200 5eff fe00 0003 2001 4818 f000 0014 0000 0000 0000 0001Vous pouvez ignorer ce message car il n’indique pas l’échec du VRRP.
Interopérabilité VRRP
Dans les versions antérieures à la version 12.2 de Junos OS, VRRP (IPv6) suivait Internet draft draft-ietf-vrrp-ipv6-spec-08, mais la somme de contrôle était calculée sur la base de la section 5.3.8 de la RFC 3768. À partir de la version 12.2, VRRP (IPv6) suit RFC 5798 et la somme de contrôle est calculée sur la base de la section 5.2.8 de la RFC 5798. En raison des différences dans les calculs de somme de contrôle VRRP, VRRP IPv6 configuré sur les routeurs qui utilisent Junos OS version 12.2 et versions ultérieures n’interagit pas avec VRRP IPv6 configuré dans les versions antérieures à Junos OS version 12.2.
Pour que le routeur avec Junos OS version 12.2 (ou versions ultérieures de Junos OS) IPv6 VRRP interagisse avec le routeur exécutant des versions de Junos OS antérieures à la version 12.2, incluez l’instruction de checksum-without-pseudoheader configuration au niveau de la [edit protocols vrrp] hiérarchie dans le routeur avec Junos OS version 12.2 ou ultérieure.
Voici quelques points généraux à savoir sur l’interopérabilité VRRP :
Si vous avez configuré VRRPv3 (IPv4 ou IPv6) sur des routeurs qui utilisent Junos OS version 12.2 ou ultérieure, il ne fonctionnera pas avec les routeurs qui utilisent Junos OS version 12.1 ou versions antérieures. En effet, seules les versions 12.2 et ultérieures de Junos OS prennent en charge VRRPv3.
VRRP (IPv4 ou IPv6) configuré sur les routeurs qui utilisent Junos OS version 12.2 et ultérieure interagit avec VRRP (IPv4 ou IPv6) configuré sur les routeurs qui utilisent des versions antérieures à Junos OS version 12.2.
VRRPv3 pour IPv4 n’interagit pas avec les versions précédentes de VRRP. Si des paquets de publication IPv4 VRRPv2 sont reçus par un routeur sur lequel VRRPv3 est activé, le routeur passe à l’état de sauvegarde pour éviter de créer plusieurs serveurs principaux dans le réseau. En raison de ce comportement, vous devez être prudent lorsque vous activez VRRPv3 sur vos réseaux VRRPv2 existants. Voir Mise à niveau de VRRPv2 vers VRRPv3 pour plus d’informations.
Remarque :Les paquets de publication VRRPv3 sont ignorés par les routeurs sur lesquels les versions précédentes de VRRP sont configurées.
Mise à niveau de VRRPv2 vers VRRPv3
Activez VRRPv3 dans votre réseau uniquement si VRRPv3 peut être activé sur tous les routeurs VRRP de votre réseau.
Activez VRRPv3 sur votre réseau VRRPv2 uniquement lors de la mise à niveau de VRRPv2 vers VRRPv3. Mélanger les deux versions de VRRP n’est pas une solution permanente.
Le changement de version VRRP est considéré comme catastrophique et perturbateur et peut ne pas être sans impact. La durée de perte de paquets dépend de nombreux facteurs, tels que le nombre de groupes VRRP, les interfaces et FPC impliqués, et la charge des autres services et protocoles en cours d’exécution sur le routeur.
La mise à niveau de VRRPv2 vers VRRPv3 doit être effectuée très soigneusement pour éviter les pertes de trafic, en raison des considérations suivantes :
Il n’est pas possible de configurer VRRPv3 sur tous les routeurs simultanément.
Pendant la période de transition, VRRPv2 et VRRPv3 fonctionnent tous deux dans le réseau.
La modification des versions VRRP redémarre la machine d’état pour tous les groupes VRRP.
Les routeurs VRRPv3 (pour IPv4) passent par défaut à l’état de sauvegarde lorsqu’ils reçoivent des paquets d’annonce VRRPv2 (pour IPv4).
VRRPv2 (pour IPv4) la priorité la plus élevée.
Les différences de somme de contrôle entre VRRPv2 et VRRPv3 (pour IPv6) peuvent créer plusieurs routeurs principaux.
Désactivez VRRPv3 (pour IPv6) sur les routeurs de secours lors de la mise à niveau pour éviter de créer plusieurs routeurs principaux.
Le Tableau 1 illustre les étapes et les événements qui se déroulent lors d’une transition de VRRPv2 à VRRPv3. Dans le Tableau 1, deux routeurs VRRPv2, R1 et R2, sont configurés en deux groupes, G1 et G2. Le routeur R1 agit en tant que routeur principal pour G1 et le routeur R2 agit en tant que routeur principal pour G2.
|
|
For IPv4 |
For IPv6 |
|
|
Lorsque vous activez VRRPv3, assurez-vous que VRRPv3 est activé sur tous les routeurs VRRP du réseau, car VRRPv3 (IPv4) n’interagit pas avec les versions précédentes de VRRP. Par exemple, si des paquets de publication IPv4 VRRPv2 sont reçus par un routeur sur lequel VRRPv3 est activé, le routeur passe à l’état de sauvegarde pour éviter de créer plusieurs serveurs principaux dans le réseau.
Vous pouvez activer VRRPv3 en configurant l’instruction version-3 au niveau de la hiérarchie (pour les [edit protocols vrrp] réseaux IPv4 ou IPv6). Configurez la même version de protocole sur tous les routeurs VRRP sur le LAN.
Fonctionnalité des fonctionnalités VRRPv3
Certaines fonctionnalités de Junos OS diffèrent dans VRRPv3 des versions VRRP précédentes.
Authentification VRRPv3
Lorsque VRRPv3 (pour IPv4) est activé, il n’autorise pas l’authentification.
Les
authentication-typeinstructions etauthentication-keyne peuvent pas être configurées pour des groupes VRRP.Vous devez utiliser une authentification non-VRRP.
Intervalles de publication VRRPv3
Les intervalles de publication VRRPv3 (pour IPv4 et IPv6) doivent être définis avec l’instruction fast-interval au niveau de la [edit interfaces interface-name unit 0 family inet address ip-address vrrp-group group-name] hiérarchie.
N’utilisez pas l’instruction
advertise-interval(pour IPv4).N’utilisez pas l’instruction
inet6-advertise-interval(pour IPv6).
ISSU unifié pour VRRPv3
Les modifications de conception de la mise à niveau logicielle en service unifié (ISSU) VRRP sont apportées dans Junos OS version 15.1 pour obtenir les fonctionnalités suivantes :
Maintenez la contiguïté des protocoles avec les routeurs homologues pendant l’ISSU unifiée. L’adjacence de protocole créée sur les routeurs homologues pour le routeur subissant un ISSU unifié ne doit pas vaciller, ce qui signifie que VRRP sur le routeur homologue distant ne doit pas vaciller.
Maintenez l’interopérabilité avec des équipements concurrents ou complémentaires.
Maintenez l’interopérabilité avec les autres versions de Junos OS et les autres produits Juniper Network.
Les valeurs des configurations suivantes (trouvées au niveau de la [edit interfaces interface-name unit 0 family inet address ip-address vrrp-group group-name] hiérarchie) doivent être maintenues aux valeurs maximales pour prendre en charge ISSU unifié :
Sur le routeur principal, l’intervalle de publication (l’instruction
fast-interval) doit être maintenu à 40950 millisecondes.Sur le routeur de sauvegarde, l’intervalle d’arrêt principal (l’instruction
advertisements-threshold) doit être maintenu à la valeur seuil la plus élevée.
Cette conception ISSU unifiée VRRP ne fonctionne que pour VRRPv3. Il n’est pas pris en charge sur VRRPv1 ou VRRPv2. Les autres limitations sont les suivantes :
L’ISSU unifié VRRP s’occupe uniquement du VRRP. Le transfert de paquets est la responsabilité du moteur de transfert de paquets. Le moteur de transfert de paquets ISSU unifié doit garantir un flux de trafic ininterrompu.
VRRP n’est affecté par aucun événement de changement lors de l’ISSU unifié, par exemple, le basculement du moteur de routage principal vers le moteur de secours ou du moteur de routage de secours vers le moteur principal.
VRRP peut arrêter et éliminer tout chronomètre en cours avant d’entrer dans ISSU unifié. Cela signifie que l’action attendue à l’expiration de la minuterie n’a jamais lieu. Cependant, vous pouvez différer l’ISSU unifié jusqu’à l’expiration de tous les minuteurs d’exécution.
Il est impossible de réaliser simultanément une ISSU unifiée sur les routeurs locaux et distants.
Présentation du délai de basculement VRRP
Le basculement est un mode opérationnel de secours dans lequel les fonctions d’un équipement réseau sont assumées par un équipement secondaire lorsque l’équipement principal devient indisponible en raison d’une panne ou d’un temps d’arrêt planifié. Le basculement fait généralement partie intégrante des systèmes critiques qui doivent être disponibles en permanence sur le réseau.
VRRP ne prend pas en charge la synchronisation de session entre les membres. En cas de défaillance de l’équipement principal, l’équipement de secours ayant la priorité la plus élevée prend le relais en tant que périphérique principal et commence à transférer les paquets. Toutes les sessions existantes seront supprimées sur le périphérique de sauvegarde comme hors état.
Un basculement rapide nécessite un court délai. Ainsi, le délai de basculement configure le délai de basculement, en millisecondes, pour les opérations VRRP et VRRP pour IPv6. Junos OS prend en charge une plage de 50 à 100000 millisecondes pour le délai de basculement.
Le processus VRRP (vrrpd) s’exécutant sur le moteur de routage communique un changement de rôle principal VRRP au moteur de transfert de paquets pour chaque session VRRP. Chaque groupe VRRP peut déclencher une telle communication pour mettre à jour le moteur de transfert de paquets avec son propre état ou l’état hérité d’un groupe VRRP actif. Pour éviter de surcharger le moteur de transfert de paquets avec de tels messages, vous pouvez configurer un délai de basculement pour spécifier le délai entre les communications suivantes du moteur de routage et du moteur de transfert de paquets.
Le moteur de routage communique un changement de rôle principal VRRP au moteur de transfert de paquets pour faciliter le changement d’état nécessaire sur le moteur de transfert de paquets, comme la reprogrammation des filtres matériels du moteur de transfert de paquets, des sessions VRRP, etc. Les sections suivantes décrivent la communication entre le moteur de routage et le moteur de transfert de paquets dans deux scénarios :
Lorsque le délai de basculement n’est pas configuré
Sans délai de basculement configuré, la séquence d’événements pour les sessions VRRP exécutées à partir du moteur de routage est la suivante :
Lorsque le premier groupe VRRP détecté par le moteur de routage change d’état et que le nouvel état est principal, le moteur de routage génère des messages d’annonce VRRP appropriés. Le moteur de transfert de paquets est informé du changement d’état, de sorte que les filtres matériels de ce groupe sont reprogrammés sans délai. Le nouveau principal envoie ensuite un message ARP gratuit aux groupes VRRP.
Le délai du minuteur de basculement démarre. Par défaut, le délai de basculement est le suivant :
500 millisecondes : lorsque l’intervalle d’annonce VRRP configuré est inférieur à 1 seconde.
2 secondes : lorsque l’intervalle d’annonce VRRP configuré est égal ou supérieur à 1 seconde et que le nombre total de groupes VRRP sur le routeur est de 255.
10 secondes : lorsque l’intervalle d’annonce VRRP configuré est égal ou supérieur à 1 seconde et que le nombre de groupes VRRP sur le routeur est supérieur à 255.
Le moteur de routage modifie un par un l’état des groupes VRRP suivants. Chaque fois qu’il y a un changement d’état et que le nouvel état d’un groupe VRRP particulier est principal, le moteur de routage génère des messages d’annonce VRRP appropriés. Toutefois, la communication avec le moteur de transfert de paquets est interrompue jusqu’à l’expiration du délai de basculement.
Une fois le délai de basculement expiré, le moteur de routage envoie un message au moteur de transfert de paquets concernant tous les groupes VRRP qui ont réussi à changer l’état. En conséquence, les filtres matériels de ces groupes sont reprogrammés et pour les groupes dont le nouvel état est primaire, des messages ARP gratuits sont envoyés.
Ce processus se répète jusqu’à ce que la transition d’état pour tous les groupes VRRP soit terminée.
Ainsi, sans configurer le délai de basculement, la transition d’état complète (y compris les états sur le moteur de routage et le moteur de transfert de paquets) pour le premier groupe VRRP est effectuée immédiatement, tandis que la transition d’état sur le moteur de transfert de paquets pour les groupes VRRP restants est retardée d’au moins 0,5 à 10 secondes, en fonction des temporisateurs d’annonce VRRP configurés et du nombre de groupes VRRP. Au cours de cet état intermédiaire, la réception de trafic pour les groupes VRRP pour des changements d’état qui n’ont pas encore été effectués sur le moteur de transfert de paquets peut être abandonnée au niveau du moteur de transfert de paquets en raison de la reconfiguration différée des filtres matériels.
Lorsque le délai de basculement est configuré
Lorsque la fonction de délai de basculement est configurée, la séquence d’événements des sessions VRRP exécutées à partir du moteur de routage est modifiée comme suit :
Le moteur de routage détecte que certains groupes VRRP nécessitent un changement d’état.
Le délai de basculement commence pour la période configurée. La plage de délai de basculement autorisée est comprise entre 50 et 100000 millisecondes.
Le moteur de routage effectue un par un changement d’état pour les groupes VRRP. Chaque fois qu’il y a un changement d’état et que le nouvel état d’un groupe VRRP particulier est principal, le moteur de routage génère des messages d’annonce VRRP appropriés. Toutefois, la communication avec le moteur de transfert de paquets est interrompue jusqu’à l’expiration du délai de basculement.
Une fois le délai de basculement expiré, le moteur de routage envoie un message au moteur de transfert de paquets concernant tous les groupes VRRP qui ont réussi à changer l’état. En conséquence, les filtres matériels de ces groupes sont reprogrammés et pour les groupes dont le nouvel état est primaire, des messages ARP gratuits sont envoyés.
Ce processus se répète jusqu’à ce que la transition d’état pour tous les groupes VRRP soit terminée.
Ainsi, lorsque le délai de basculement est configuré, même l’état du moteur de transfert de paquets pour le premier groupe VRRP est différé. Toutefois, l’opérateur réseau a l’avantage de configurer une valeur de délai de basculement qui convient le mieux aux besoins du déploiement du réseau afin de minimiser les pannes lors du changement d’état VRRP.
Le délai de basculement influence uniquement les sessions VRRP exploitées par le processus VRRPD (VRRPD) s’exécutant sur le moteur de routage. Pour les sessions VRRP distribuées au moteur de transfert de paquets, la configuration du délai de basculement n’a aucun effet.
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.