Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Comprendre le VRRP

RÉSUMÉ Le protocole VRRP (Virtual Router Redundancy Protocol) peut être utilisé pour créer des plates-formes de routage redondantes virtuelles sur un réseau local, ce qui permet de router le trafic sur le réseau local sans recourir à une plate-forme de routage unique.

Comprendre le VRRP

Pour les interfaces Ethernet, Fast Ethernet, Gigabit Ethernet, 10 Gigabit Ethernet et logiques, vous pouvez configurer le protocole VRRP (Virtual Router Redundancy Protocol) ou VRRP pour IPv6. Le VRRP permet aux hôtes d’un réseau local d’utiliser des plates-formes de routage redondantes sur ce réseau local sans nécessiter plus que la configuration statique d’un seul itinéraire par défaut 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 de secours 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 réseau local sans recourir à une plate-forme de routage unique. Grâce au VRRP, un périphérique de sauvegarde peut prendre le contrôle d’un périphérique par défaut défaillant en quelques secondes. Cela se fait avec un minimum de trafic VRRP 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 appareils exécutant le VRRP élisent dynamiquement les appareils principaux et de secours. Vous pouvez également forcer l’affectation des périphériques principaux et secondaires en utilisant des priorités de 1 à 255, 255 étant la priorité la plus élevée. En fonctionnement VRRP, le périphérique principal par défaut envoie des publicités aux périphériques de sauvegarde à intervalles réguliers. L’intervalle par défaut est de 1 seconde. Si une unité de sauvegarde ne reçoit pas de publicité pendant une période définie, l’unité de sauvegarde ayant la priorité la plus élevée suivante prend le relais en tant que périphérique principal et commence à transférer les paquets.

Note:

La priorité 255 ne peut pas être définie pour les interfaces VLAN routées (RVI).

Note:

Pour minimiser le trafic réseau, VRRP est conçu de telle sorte que seul l’appareil qui agit en tant que principal envoie des publicités VRRP à un moment donné. Les périphériques de sauvegarde n’envoient aucune publicité tant qu’ils n’ont pas assumé le rôle principal.

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.

Note:

Ne confondez pas les plates-formes de routage principale et de secours VRRP avec les commutateurs membres principaux et de secours d’une configuration Virtual Chassis . Les membres principaux et secondaires d’une configuration Virtual Chassis forment 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.

Le VRRP est défini dans la norme RFC 3768, Virtual Router Redundancy Protocol. VRRP for 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.

Note:

Même si le 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 compatibilité descendante de la norme RFC 3768.

Note:

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 flaps lors d’opérations gourmandes en ressources processeur, tels que le basculement du moteur de routage, les volets 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 forment 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).

Figure 1 : VRRP Basic VRRP de base

Étant donné que 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 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 se rétablit, il redevient le routeur virtuel principal.

Note:

Dans certains cas, au cours d’une session d’héritage, il existe un court laps de temps pendant lequel deux routeurs sont à l’état principal-principal. Dans de tels cas, les groupes VRRP qui héritent de l’État envoient des publicités VRRP toutes les 120 secondes. Ainsi, il faut aux routeurs jusqu’à 120 secondes pour récupérer après être passés de l’état primaire-primaire à l’état primaire.

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 uniquement configuré pour VRRP, 64 identificateurs de groupe VRRP uniques sont pris en charge. Si les familles IPv4 et IPv6 partagent le même groupe VRRP, seuls 32 identificateurs VRRP uniques sont pris en charge.

Note:

Les routeurs ACX Series prennent en charge VRRP version 3 pour les adresses IPv6.

ACX5448 routeur prend en charge RFC 3768 VRRP version 2 et RFC 5798 VRRP version 3. ACX5448 routeur prend également en charge la configuration du VRRP sur Ethernet agrégé et des interfaces IRB (Integrated Routing and Bridging).

Les limitations suivantes s’appliquent lors de la configuration de VRRP sur ACX5448 routeur :

  • Configurez un maximum de 16 groupes VRRP.

  • L’interfonctionnement de VRRP version 2 et VRRP version 3 n’est pas pris 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 forment ensemble une plate-forme de routage virtuelle. L’adresse IP de cette plate-forme de routage virtuelle est 10.10.0.1 (la même adresse que l’interface physique du commutateur A).

Figure 2 : VRRP de base sur les Basic VRRP on EX Series Switches commutateurs 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 commutateurs Ethernet EX4200 de Juniper Networks interconnectés. Chaque configuration Virtual Chassis fonctionne comme un commutateur unique, qui exécute VRRP, et forment ensemble une plate-forme de routage virtuelle. L’adresse IP de cette plate-forme de routage virtuelle est 10.10.0.1 (la même adresse que l’interface physique du commutateur A).

Figure 3 : VRRP sur les VRRP on Virtual Chassis Switches commutateurs Virtual Chassis

Étant donné que la plate-forme de routage virtuelle utilise l’adresse IP de l’interface physique du commutateur A, le commutateur A est la plate-forme de routage VRRP principale, tandis que le commutateur B et le commutateur C fonctionnent comme des plates-formes de routage VRRP de secours. Les clients 1 à 3 sont configurés avec l’adresse IP de passerelle par défaut puisque 10.10.0.1 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 plate-forme de routage virtuelle principale.

Présentation de VRRP et VRRP pour IPv6

Vous pouvez configurer le protocole VRRP (Virtual Router Redundancy Protocol) et VRRP pour IPv6 pour les interfaces suivantes :

  • Ethernet

  • Fast Ethernet

  • Cuivre Ethernet triple vitesse

  • Gigabit Ethernet

  • Photo LAN/WAN Ethernet 10 Gigabit

  • Interfaces logiques Ethernet

VRRP et VRRP pour IPv6 permettent aux hôtes d’un réseau local d’utiliser des routeurs redondants sur ce réseau local sans nécessiter plus que la configuration statique d’un seul itinéraire par défaut 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. Si le routeur principal tombe en panne, l’un des routeurs de secours devient le nouveau routeur principal, fournissant ainsi toujours un routeur virtuel par défaut et permettant de router le trafic sur le réseau local sans dépendre d’un seul routeur.

Le VRRP est défini dans la norme RFC 3768, Virtual Router Redundancy Protocol.

Pour obtenir des informations sur VRRP et VRRP for IPv6, des instructions de configuration et des résumés d’instructions, reportez-vous au Guide de l’utilisateur de haute disponibilité de Junos OS.

Comprendre le VRRP entre les systèmes QFabric

Les systèmes QFabric de Juniper Networks prennent en charge le protocole VRRP (Virtual Router Redundancy Protocol). Cette rubrique couvre :

Différences VRRP sur les systèmes QFabric

La configuration de serveurs sur votre réseau avec des routes statiques vers une passerelle par défaut minimise les efforts et la complexité de configuration et réduit la charge de traitement. Toutefois, une défaillance de la passerelle par défaut entraîne normalement un événement catastrophique, isolant les serveurs. L’utilisation du protocole VRRP (Virtual Router Redundancy Protocol) vous permet de fournir dynamiquement des passerelles alternatives pour les serveurs en cas de défaillance de la passerelle principale.

Les commutateurs configurés avec VRRP partagent une adresse IP virtuelle (VIP), qui est l’adresse que vous configurez comme route par défaut sur les serveurs. En fonctionnement VRRP normal, l’un des commutateurs est le VRRP principal, ce qui signifie qu’il possède l’adresse IP virtuelle et constitue la passerelle active par défaut. Les autres appareils sont des sauvegardes. Les commutateurs attribuent dynamiquement des rôles principaux et de sauvegarde en fonction des priorités que vous configurez. Si le serveur principal tombe en panne, le commutateur de sauvegarde ayant la priorité la plus élevée devient le commutateur principal et prend possession de l’adresse IP virtuelle en quelques secondes. Cela se fait sans aucune interaction avec les serveurs.

Vous pouvez configurer deux systèmes QFabric pour participer à une configuration VRRP comme s’il s’agissait de deux commutateurs autonomes. Toutefois, dans un fonctionnement VRRP normal, un seul système peut être le système principal pour un groupe VRRP donné à la fois, ce qui signifie qu’un seul système peut agir comme passerelle par défaut à l’aide de l’adresse IP virtuelle configurée pour le groupe. Lorsque vous exécutez VRRP sur deux systèmes QFabric, vous souhaiterez peut-être que les deux systèmes utilisent simultanément l’adresse IP virtuelle pour servir de passerelle et transférer le trafic. Pour ce faire, vous pouvez configurer un filtre de pare-feu pour bloquer les paquets de publication VRRP entre les systèmes QFabric sur la liaison entre les deux groupes de nœuds réseau. Lorsque vous effectuez cette opération, les deux systèmes QFabric agissent en tant que trafic principal et direct reçu par l’adresse IP virtuelle (qui est l’adresse de passerelle par défaut que vous configurez sur les serveurs connectés aux deux systèmes QFabric). Si vous utilisez vMotion de VMware, cette configuration permet aux machines virtuelles de passer d’un serveur à l’autre connecté aux systèmes QFabric sans mettre à jour leurs informations de passerelle par défaut. Par exemple, une machine virtuelle s’exécutant sur un serveur connecté à un système QFabric dans le centre de données A peut passer à un serveur connecté à un système QFabric dans le centre de données B sans avoir à résoudre une nouvelle adresse IP de passerelle et une nouvelle adresse MAC, car les deux systèmes QFabric utilisent le même VIP.

Note:

Pour utiliser un filtre de pare-feu afin de bloquer le trafic VRRP, créez un terme de pare-feu qui correspond au trafic correspondant au trafic et protocol vrrp ignorez ce trafic.

Détails de configuration

La configuration d’un groupe VRRP sur deux systèmes QFabric est similaire à la configuration de VRRP sur deux commutateurs. Les principales différences sont énumérées ici :

  • Toutes les interfaces des deux systèmes QFabric qui participent au VRRP doivent être membres du même VLAN.

  • Vous devez créer des interfaces VLAN routées (RVI) dans ce VLAN sur les deux systèmes QFabric.

  • Les adresses IP que vous attribuez aux deux RVI doivent se trouver dans le même sous-réseau.

  • Vous devez configurer VRRP sur les RVI.

  • Les deux RVI doivent être membres du même groupe VRRP. C’est ce qui permet aux deux systèmes QFabric de partager une adresse IP virtuelle.

Les tableaux suivants répertorient les éléments d’un exemple de configuration VRRP exécuté sur deux systèmes QFabric : le système QFabric A et le système QFabric B. Cet exemple est configuré de sorte que les deux systèmes QFabric agissent comme VRRP principal pour VIP 10.1.1.50/24 et suppose qu’un filtre de pare-feu bloque les publicités VRRP entre les systèmes. Le tableau 1 répertorie les caractéristiques requises des RVI dans l’exemple de configuration.

Note:

La plupart des paramètres de configuration indiqués dans les tableaux suivants s’appliquent également à une configuration VRRP traditionnelle. Toutefois, l’intervalle de publication et les paramètres de priorité devraient être différents (comme indiqué).

Tableau 1 : RVI sur les systèmes QFabric dans un exemple de configuration VRRP
RVI sur QFabric System A RVI sur QFabric System B

VLAN.100

VLAN.200

Membre du VLAN 100. (Notez que le VLAN est le même sur les deux systèmes QFabric.)

Membre du VLAN 100

Adresse IP 10.1.1.100/24

Adresse IP 10.1.1.200/24

Membre du groupe VRRP 500

Membre du groupe VRRP 500

Adresse IP virtuelle 10.1.1.50/24

Adresse IP virtuelle 10.1.1.50/24

Vous devez configurer VRRP sur les RVI des deux systèmes QFabric. Le tableau 2 répertorie les éléments d’un exemple de configuration VRRP sur chaque RVI. Notez qu’à l’exception de la priorité, les paramètres doivent être les mêmes sur les deux systèmes.

Tableau 2 : Exemple de configuration VRRP pour chaque RVI
VRRP sur RVI sur QFabric System A VRRP sur RVI sur QFabric System B

VRRP groupe 500

VRRP groupe 500

Adresse IP virtuelle 10.1.1.50/24

Adresse IP virtuelle 10.1.1.50/24

Intervalle de publication 60 secondes. (Dans une configuration VRRP normale, vous devez définir cet intervalle pour qu’il soit beaucoup plus petit, par exemple 1 seconde. Cependant, dans cette configuration, ces paquets sont bloqués par le filtre de pare-feu sur l’interface qui se connecte au système QFabric B, il n’est donc pas nécessaire de les envoyer fréquemment.)

Intervalle de publicité 60 secondes

Type d’authentification md5

Type d’authentification md5

Clé d’authentification $9$1.4ElMVb2aGi4aZjkqzFRhSeWx7-wY2aM8

Clé d’authentification $9$1.4ElMVb2aGi4aZjkqzFRhSeWx7-wY2aM8

Priorité 254. (Dans une configuration VRRP normale, cette valeur serait différente sur les deux systèmes et le système avec la valeur la plus élevée serait le système principal. Toutefois, dans cette configuration, les deux systèmes agissent en tant que systèmes principaux, vous n’avez donc pas besoin de configurer des valeurs différentes.)

Priorité 254

Note:

La priorité 255 n’est pas prise en charge pour les RVI.

Le tableau 3 répertorie toutes les interfaces du système QFabric A dans l’exemple de configuration et identifie à quoi elles se connectent.

Tableau 3 : interfaces sur le système QFabric A. Toutes les interfaces sont membres du VLAN 100.
Interfaces VLAN 100 sur QFabric System A Se connecte à

VLAN.100

VLAN.200

Interface de groupe de nœuds réseau QFA-NNG :xe-0/0/0

QFB-NNG :xe-0/0/0 sur le système QFabric B

Interface de groupe de nœuds réseau QFA-NNG :xe-0/0/1

Serveur redondant Interface de groupe de nœuds QFA-RSNG :xe-0/0/0

Serveur redondant Interface de groupe de nœuds QFA-RSNG :xe-0/0/0

Se connecte à un réseau Interface de groupe de nœuds QFA-NNG :xe-0/0/1

Serveur redondant Interface de groupe de nœuds QFA-RSNG :xe-0/0/1

LAN avec serveurs exécutant des machines virtuelles

Le tableau 4 répertorie toutes les interfaces du système QFabric B dans l’exemple de configuration et identifie à quoi elles se connectent.

Tableau 4 : interfaces sur le système QFabric B. Toutes les interfaces sont membres du VLAN 100 (comme sur le système QFabric A).
Interfaces VLAN 100 sur QFabric System B Se connecte à

VLAN.200

VLAN.100

Interface de groupe de nœuds réseau QFB-NNG :xe-0/0/0

QFA-NNG :xe-0/0/0 sur le système QFabric A

Interface de groupe de nœuds réseau QFB-NNG :xe-0/0/1

Serveur redondant Interface de groupe de nœuds QFB-RSNG :xe-0/0/0

Serveur redondant Interface de groupe de nœuds QFB-RSNG :xe-0/0/0

Se connecte à une interface de groupe de nœuds QFB-NNG :xe-0/0/1

Serveur redondant Interface de groupe de nœuds QFB-RSNG :xe-0/0/1

LAN avec serveurs exécutant des machines virtuelles

Prise en charge de VRRPv3 par Junos OS

L’avantage d’utiliser 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

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 qui utilisent des versions antérieures à Junos OS version 12.2 et n’est pas non plus pris en charge pour IPv6 sur les commutateurs QFX10000.

Note:

VRRPv3 pour IPv6 est pris en charge sur QFX10002-60C.

À partir de la version 12.2, Junos OS prend en charge :

  • RFC 3768, Protocole VRRP (Virtual Router Redundancy Protocol)

  • RFC 5798, VRRP (Virtual Router Redundancy Protocol) version 3 pour IPv4 et IPv6

  • RFC 6527, Définitions des objets gérés pour VRRPv3 (Virtual Router Redundancy Protocol Version 3)

Note:

Le VRRP (pour IPv6) sur les routeurs qui utilisent Junos OS version 12.2 et versions ultérieures 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 checksum VRRP. Voir Différences comportementales de somme de contrôle VRRP IPv6.

Différences comportementales de 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 à Junos OS version 12.2, lorsque VRRP for IPv6 est configuré, la somme de contrôle VRRP est calculée conformément à la section 5.3.8 de la norme RFC 3768, Virtual Router Redundancy Protocol (VRRP).

  • À partir de Junos OS version 12.2, 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, Virtual Router Redundancy Protocol (VRRP) 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 doté de Junos OS version 12.2 (ou ultérieure de Junos OS version 12.2) IPv6 VRRP interagisse avec le routeur exécutant une version de Junos OS antérieure à la version 12.2, incluez l’instruction de configuration au niveau de la checksum-without-pseudoheader [edit protocols vrrp] hiérarchie dans le routeur exécutant Junos OS version 12.2 ou ultérieure.

  • L’utilitaire tcpdump de Junos OS version 12.2 et ultérieure calcule la somme de contrôle VRRP conformément à la norme RFC 5798, Virtual Router Redundancy Protocol (VRRP) version 3 pour IPv4 et IPv6. Par conséquent, lors tcpdump de l’analyse des paquets VRRP IPv6 reçus d’anciennes versions de Junos OS (antérieures à Junos OS version 12.2), le message s’affiche bad vrrp cksum :

    Vous pouvez ignorer ce message car il n’indique pas l’échec du VRRP.

Interopérabilité VRRP

Dans les versions antérieures à Junos OS version 12.2, VRRP (IPv6) suivait le brouillon Internet ietf-vrrp-ipv6-spec-08, mais la somme de contrôle a été calculée sur la base de la section 5.3.8 de la RFC 3768. À partir de la version 12.2, VRRP (IPv6) suit la norme RFC 5798 et la somme de contrôle est calculée conformément à la section 5.2.8 de la RFC 5798. En raison des différences dans les calculs de somme de contrôle VRRP, le VRRP IPv6 configuré sur les routeurs qui utilisent Junos OS version 12.2 et versions ultérieures n’interagit pas avec IPv6 VRRP configuré dans les versions antérieures à Junos OS version 12.2.

Pour que le routeur doté de Junos OS version 12.2 (ou ultérieure de Junos OS version 12.2) interagisse avec le routeur exécutant des versions de Junos OS antérieures à la version 12.2, incluez l’instruction de configuration au niveau de la checksum-without-pseudoheader [edit protocols vrrp] hiérarchie dans le routeur avec Junos OS version 12.2 ou ultérieure.

Voici quelques points généraux à connaître 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, seuls Junos OS version 12.2 et versions ultérieures prennent en charge VRRPv3.

  • Le VRRP (IPv4 ou IPv6) configuré sur les routeurs qui utilisent Junos OS version 12.2 et versions ultérieures 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 VRRPv2 IPv4 sont reçus par un routeur sur lequel VRRPv3 est activé, le routeur passe lui-même à l’état de sauvegarde pour éviter de créer plusieurs primaires 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.

    Note:

    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.

ATTENTION:

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 les FPC impliqués, ainsi que la charge des autres services et protocoles exécutés sur le routeur.

La mise à niveau de VRRPv2 vers VRRPv3 doit être effectuée très soigneusement pour éviter la perte de trafic, en raison de ces considérations :

  • 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 sur le réseau.

  • La modification des versions VRRP redémarre l’ordinateur d’état pour tous les groupes VRRP.

  • Les routeurs VRRPv3 (pour IPv4) utilisent par défaut l’état de sauvegarde lorsqu’ils reçoivent des paquets de publication VRRPv2 (pour IPv4).

  • Les paquets VRRPv2 (pour IPv4) ont toujours la plus haute priorité.

  • 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 sauvegarde lors de la mise à niveau pour éviter de créer plusieurs routeurs principaux.

Le tableau 5 illustre les étapes et les événements qui ont lieu lors de la transition d’un VRRPv2 vers VRRPv3. Dans le tableau 5, deux routeurs VRRPv2, R1 et R2, sont configurés en deux groupes, G1 et G2. Le routeur R1 agit comme le principal pour G1 et le routeur R2 agit comme le principal pour G2.

Tableau 5 : étapes et événements de transition de VRRPv2 vers VRRPv3
  1. Mettez à niveau le routeur R1 avec Junos OS version 12.2 ou ultérieure.

    • Le routeur R2 devient le routeur principal pour G1 et G2.

    • Une fois la mise à niveau du routeur R1 terminée, le routeur R1 devient le principal pour G1.

    • Le routeur R2 reste le principal pour G2.

  2. Mettez à niveau le routeur R2 avec Junos OS version 12.2 ou ultérieure.

    • Le routeur R1 devient le routeur principal pour G1 et G2.

    • Une fois la mise à niveau du routeur R2 terminée, le routeur R2 devient le principal pour G2.

    • Le routeur R1 reste le principal pour G1.

For IPv4

For IPv6

  1. Activez VRRPv3 sur le routeur R1.

    • Le routeur R1 devient la sauvegarde pour G1 et G2 car les paquets de publicité VRRPv2 IPv4 ont une priorité plus élevée.

  2. Activez VRRPv3 sur le routeur R2.

    • Le routeur R1 devient le routeur principal pour G1.

    • Le routeur R2 devient le principal pour G2.

  1. Désactivez G1 et G2 sur le routeur R2.

    • G1 et G2 sur le routeur R1 deviennent principaux.

  2. Activez VRRPv3 sur le routeur R1.

    • Le routeur R1 devient le routeur principal pour G1 et G2.

  3. Activez VRRPv3 sur le routeur R2.

  4. Activez G1 et G2 sur le routeur R2.

    • Le routeur R2 devient le principal pour G2.

    • Le routeur R1 reste le principal pour G1.

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 primaires 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 du réseau local.

Fonctionnalités de VRRPv3 Caractéristiques

Certaines fonctionnalités de Junos OS diffèrent dans VRRPv3 des versions précédentes de VRRP.

Authentification VRRPv3

Lorsque VRRPv3 (pour IPv4) est activé, il n’autorise pas l’authentification.

  • Les authentication-type instructions et authentication-key ne peuvent être configurées pour aucun groupe 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 (pour IPv4 advertise-interval ).

  • N’utilisez pas l’instruction (pour IPv6 inet6-advertise-interval ).

ISSU unifié pour VRRPv3

Junos OS version 15.1 apporte des modifications à la conception de la mise à niveau logicielle en service unifiée (ISSU) VRRP pour obtenir les fonctionnalités suivantes :

  • Maintenez la contiguïté du protocole avec les routeurs homologues lors de l’ISSU unifié. L’adjacence de protocole créée sur les routeurs homologues pour le routeur subissant un ISSU unifié ne doit pas s’affaiblir, ce qui signifie que le VRRP sur le routeur homologue distant ne doit pas basculer.

  • Maintenir 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 (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 l’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 principal vers le bas (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 relève de la responsabilité du moteur de transfert de paquets. L’ISSU unifié du moteur de transfert de paquets doit garantir un flux de trafic ininterrompu.

  • VRRP n’est affecté par aucun événement de changement pendant l’ISSU unifié, par exemple, le basculement du moteur de routage principal vers la sauvegarde ou du moteur de routage de secours vers le moteur principal.

  • VRRP peut arrêter et ignorer tout chronomètre avant d’entrer dans l’ISSU unifié. Cela signifie que l’action attendue à l’expiration de la minuterie n’a jamais lieu. Toutefois, vous pouvez différer ISSU unifié jusqu’à l’expiration de tous les minuteurs en cours d’exécution.

  • L’ISSU unifié au niveau des routeurs locaux et distants ne peut pas être effectué simultanément.

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 programmé. Le basculement fait généralement partie intégrante des systèmes critiques qui doivent être constamment disponibles sur le réseau.

VRRP ne prend pas en charge la synchronisation de session entre les membres. Si le périphérique principal tombe en panne, le périphérique de sauvegarde 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 déposées sur l’appareil de sauvegarde en tant que hors état.

Un basculement rapide nécessite un court délai. Ainsi, failover-delay configure le délai de basculement, en millisecondes, pour les opérations VRRP et VRRP pour IPv6. Junos OS prend en charge un délai de basculement compris entre 50 et 100 000 millisecondes.

Le processus VRRP (vrrpd) exécuté 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 entre le moteur de routage et le 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, tel que la reprogrammation des filtres matériels du moteur de transfert de paquets, des sessions VRRP, etc. Les sections suivantes développent 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 des événements pour les sessions VRRP exécutées à partir du moteur de routage est la suivante :

  1. 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 pour ce groupe sont reprogrammés sans délai. Le nouveau primaire envoie alors un message ARP gratuit aux groupes VRRP.

  2. Le délai du minuteur de basculement commence. Par défaut, le minuteur de délai de basculement est :

    • 500 millisecondes : lorsque l’intervalle d’annonce VRRP configuré est inférieur à 1 seconde.

    • 2 secondes : lorsque l’intervalle d’annonce VRRP configuré est de 1 seconde ou plus et que le nombre total de groupes VRRP sur le routeur est de 255.

    • 10 secondes : lorsque l’intervalle d’annonce VRRP configuré est de 1 seconde ou plus et que le nombre de groupes VRRP sur le routeur est supérieur à 255.

  3. Le moteur de routage effectue un par un un un changement d’état pour les 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 supprimée jusqu’à l’expiration du délai de basculement.

  4. Une fois le délai de basculement expiré, le moteur de routage envoie au moteur de transfert de paquets un message concernant tous les groupes VRRP qui ont réussi à changer d’état. En conséquence, les filtres matériels pour 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 minuteries d’annonce VRRP configurées et du nombre de groupes VRRP. Au cours de cet état intermédiaire, le trafic reçu pour les groupes VRRP pour les changements d’état qui n’ont pas encore été effectués sur le moteur de transfert de paquets peut être abandonné 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 le délai de basculement est configuré, la séquence d’événements pour les sessions VRRP exécutées à partir du moteur de routage est modifiée comme suit :

  1. Le moteur de routage détecte que certains groupes VRRP nécessitent un changement d’état.

  2. Le délai de basculement commence pour la période configurée. La plage de temporisateur de délai de basculement autorisée est comprise entre 50 et 100000 milisecondes.

  3. Le moteur de routage modifie un par un l’état des 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 supprimée jusqu’à l’expiration du délai de basculement.

  4. Une fois le délai de basculement expiré, le moteur de routage envoie au moteur de transfert de paquets un message concernant tous les groupes VRRP qui ont réussi à changer d’état. En conséquence, les filtres matériels pour 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é. Cependant, l’opérateur réseau a l’avantage de configurer une valeur de délai de basculement adaptée au mieux aux besoins du déploiement du réseau afin de minimiser les pannes lors d’un changement d’état VRRP.

Le délai de basculement n’influence que les sessions VRRP gérées par le processus VRRP (VRRPD) exécuté 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 plate-forme 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.

Libération
Description
12.2
Junos OS version 12.2 et versions ultérieures prennent en charge VRRPv3.