Comprendre le VRRP

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 la configuration et réduit les frais de traitement. Toutefois, une défaillance de la passerelle par défaut entraîne normalement un événement catastrophique qui isole les serveurs. L’utilisation du protocole VRRP (Virtual Router Redundancy Protocol) vous permet de fournir dynamiquement d’autres passerelles 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 qu’il est la passerelle active par défaut. Les autres appareils sont des sauvegardes. Les commutateurs attribuent dynamiquement les rôles principal et de secours en fonction des priorités que vous configurez. En cas de défaillance du serveur principal, le commutateur de secours 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 qu’ils participent à une configuration VRRP comme s’il s’agissait de deux commutateurs autonomes. Toutefois, en fonctionnement VRRP normal, un seul système peut être le système principal d’un groupe VRRP donné à la fois, ce qui signifie qu’un seul système peut agir en tant que passerelle par défaut à l’aide de l’adresse IP virtuelle configurée pour le groupe. Lors de l’exécution de VRRP sur deux systèmes QFabric, vous souhaiterez peut-être que les deux systèmes utilisent simultanément l’adresse IP virtuelle pour agir en tant que passerelle et transférer le trafic. Pour ce faire, vous pouvez configurer un filtre de pare-feu afin de bloquer les paquets d’annonces VRRP entre les systèmes QFabric sur la liaison entre les deux groupes de nœuds du réseau. Lorsque vous faites cela, les deux systèmes QFabric agissent en tant que trafic principal et transfère 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 datacenter A peut passer à un serveur connecté à un système QFabric dans le datacenter B sans avoir besoin de résoudre une nouvelle adresse IP de passerelle et une nouvelle adresse MAC, car les deux systèmes QFabric utilisent la même adresse VIP.

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 IVR 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 s’exécutant sur deux systèmes QFabric : le système QFabric A et le système QFabric B. Cet exemple est configuré de manière à ce que les deux systèmes QFabric agissent en tant que VRRP principal pour VIP 10.1.1.50/24 et suppose qu’un filtre de pare-feu bloque les annonces VRRP entre les systèmes. Le Tableau 1 répertorie les caractéristiques requises des RVI dans l’exemple de configuration.

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

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

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

Prise en charge de Junos OS VRRP

Dans les versions antérieures à la version 12.2, Junos OS prenait en charge RFC 3768, Virtual Router Redundancy Protocol (VRRP) (for 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.

À 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 des objets gérés pour le protocole de redondance de routeur virtuel version 3 (VRRPv3)

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, Virtual Router Redundancy Protocol (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 doté de Junos OS version 12.2 (ou versions ultérieures de Junos OS) interagisse avec le routeur exécutant une version de Junos OS antérieure à la version 12.2, incluez l’instruction checksum-without-pseudoheader de configuration au niveau de la [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 RFC 5798, Virtual Router Redundancy Protocol (VRRP) Version 3 pour IPv4 et IPv6. Par conséquent, lorsque tcpdump vous analysez des paquets VRRP IPv6 reçus à partir de versions antérieures à Junos OS (antérieures à Junos OS version 12.2), le message suivant s’affiche bad vrrp cksum :

  Vous pouvez ignorer ce message car il n’indique pas d’échec 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 la 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, 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 versions ultérieures de Junos OS) interagisse avec le routeur exécutant des versions de Junos OS antérieures à la version 12.2, incluez l’instruction checksum-without-pseudoheader de 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, seuls Junos OS version 12.2 et ultérieures prennent en charge VRRPv3.

• VRRP (IPv4 ou IPv6) configuré sur les routeurs qui utilisent Junos OS version 12.2 et versions ultérieures interagissent 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 d’annonces IPv4 VRRPv2 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 paquets principaux dans le réseau. En raison de ce comportement, vous devez être prudent lorsque vous activez VRRPv3 sur vos réseaux VRRPv2 existants. Pour plus d’informations, reportez-vous à la section Mise à niveau de VRRPv2 vers VRRPv3 .

  Note:

  Les paquets d’annonces 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. Le mélange des deux versions de VRRP n’est pas une solution permanente.

La mise à niveau de VRRPv2 vers VRRPv3 doit être effectuée avec le plus grand soin pour éviter les pertes de trafic, en raison des considérations suivantes :

• Il n’est pas possible de configurer VRRPv3 sur tous les routeurs en même temps.

• 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’annonces VRRPv2 (pour IPv4).

• Les paquets VRRPv2 (pour IPv4) ont toujours 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 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 se produisent lors d’une transition de 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 fait office de routeur principal pour G1 et le routeur R2 est le routeur principal pour G2.

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 d’annonces IPv4 VRRPv2 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 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 du réseau local.

Fonctionnalité des fonctionnalités VRRPv3

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

• Authentification VRRPv3
• Intervalles d’annonce VRRPv3
• ISSU unifié pour VRRPv3

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 géré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 les 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 serveur principal envoie ensuite un message ARP gratuit aux groupes VRRP.

2. Le délai du minuteur de basculement commence. Par défaut, le temporisateur 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 modifie l’état un par un 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 interrompue jusqu’à l’expiration du délai de basculement.

4. Après l’expiration du délai de basculement, le moteur de routage envoie un message au moteur de transfert de paquets concernant tous les groupes VRRP qui ont réussi à modifier 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 de tous les groupes VRRP soit terminée.

Ainsi, sans configurer de délai de basculement, la transition d’état complète (y compris les états du moteur de routage et du 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, le trafic de réception pour les groupes VRRP pour les modifications d’état qui n’ont pas encore été effectuées sur le moteur de transfert de paquets peut être abandonné au niveau du moteur de transfert de paquets en raison d’une 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 géré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 temporisation de basculement autorisée est comprise entre 50 et 100000 millisecondes.

3. Le moteur de routage effectue un par un les changements 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.

4. Après l’expiration du délai de basculement, le moteur de routage envoie un message au moteur de transfert de paquets concernant tous les groupes VRRP qui ont réussi à modifier 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 de 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 correspond 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 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.