Résumé

  • L’état Active de VRRPv3 résulte d’une revendication de propriété configurée, d’une priorité, d’annonces et de temporisations ; il établit un rôle de protocole pour une instance, pas une autorité authentifiée ni la santé du plan de données.
  • La preuve d’une relève réussie doit relier l’élection au déplacement de la MAC virtuelle, à ARP ou Neighbor Discovery, aux adjacences, aux routes amont, aux instances IPv4 et IPv6 séparées et au retour du trafic réel.

Le journal d’un équipement peut raconter une histoire parfaitement cohérente : dernière annonce reçue, expiration calculée, passage de Backup à Active, émission immédiate de nouvelles annonces. Sept secondes plus tard, les utilisateurs peuvent pourtant rester isolés. Le protocole n’a pas menti. C’est l’interprétation qui a confondu une décision locale avec un résultat de bout en bout.

VRRP répond à un problème très précis. Des hôtes utilisent une adresse de premier saut sans participer à un protocole de routage dynamique. Plusieurs routeurs se présentent comme candidats pour porter cette adresse virtuelle. Il faut qu’un seul d’entre eux, dans le cas normal, assume le rôle actif et que les autres sachent quand prendre sa place. RFC 9568 décrit cette coordination pour IPv4 et IPv6.

Une annonce décrit une candidature, pas un chemin

L’annonce transporte le VRID, la priorité, l’intervalle maximal d’annonce et la liste des adresses protégées. Le propriétaire configuré de l’adresse utilise la priorité 255. Les secours utilisent de 1 à 254, avec 100 par défaut. La valeur zéro indique que l’actif abandonne sa responsabilité. La somme de contrôle repère une corruption accidentelle ; le TTL ou Hop Limit fixé à 255 limite l’injection depuis un réseau distant.

Ce paquet ne contient ni état de FIB, ni résultat de sondage amont, ni preuve qu’une ACL laisse passer le service, ni état de session, ni mesure utilisateur. Plus grave pour toute lecture trop confiante, RFC 9568 précise que VRRPv3 n’authentifie pas ses messages. Un nœud hostile ou mal configuré sur le même lien peut se comporter comme un routeur actif. Le contrôle à 255 réduit la surface distante ; il ne transforme pas le LAN en domaine de confiance.

La priorité 255 mérite donc une lecture rigoureuse. Elle signifie « cet équipement est configuré comme propriétaire de l’adresse » dans la logique de l’instance. Elle ne constitue ni un titre externe, ni une attestation cryptographique, ni un contrôle de cohérence avec l’intention de l’opérateur. Lorsque plusieurs équipements annoncent 255, la norme recommande de journaliser l’anomalie. Le rôle ne tranche pas l’autorité légitime ; il révèle un conflit de configuration.

Le silence est un signal, pas un diagnostic

Un secours calcule Skew_Time à partir de sa priorité et de l’intervalle annoncé, puis attend trois intervalles plus ce décalage avant de déclarer l’actif perdu. La mécanique produit un ordre de relève reproductible. Elle ne dit pas ce qui a disparu.

L’équipement précédent peut être arrêté. Le multicast peut être filtré. Le processus VRRP peut être bloqué alors que l’ASIC continue d’acheminer. L’interface locale peut fonctionner alors que la route amont est rompue. À l’inverse, les annonces peuvent continuer à arriver depuis un routeur dont le plan de données ne transporte plus rien. Dans les deux cas, VRRP observe son propre canal ; il ne surveille pas toutes les dépendances du service.

Réduire l’intervalle accélère la décision, pas nécessairement la reprise. RFC 9568 signale même qu’un actif de haute priorité mais lent peut entrer temporairement en concurrence avec un secours moins prioritaire qui annonce plus vite. Les différences de priorité influencent le décalage et doivent être suffisantes pour éviter que plusieurs secours deviennent actifs presque simultanément. Le réglage du temps est donc aussi un réglage du risque.

La bascule doit encore traverser le lien

Après l’élection, la MAC virtuelle doit être associée au bon port. Les hôtes et les routeurs voisins doivent apprendre la nouvelle situation par ARP ou Neighbor Discovery. Une annonce non sollicitée peut être émise correctement sans que tous les caches l’acceptent. RFC 9131 rappelle que des réglages supplémentaires peuvent être nécessaires pour que certaines annonces IPv6 mettent effectivement les caches à jour.

Une capture prise sur le nouveau routeur prouve l’émission. Elle ne prouve pas l’apprentissage de chaque commutateur, la mise à jour de chaque voisin ni l’absence d’un filtre de sécurité. Une seule MAC périmée suffit à diviser le trafic : certains clients rejoignent le nouvel actif, d’autres continuent d’envoyer vers l’ancien port.

Le test par ping ajoute une ambiguïté. Avec Accept_Mode désactivé — valeur par défaut — un actif qui n’est pas propriétaire de l’adresse peut refuser les paquets destinés à cette adresse tout en acheminant correctement le trafic de transit. Un ping en échec n’invalide donc pas automatiquement le service. Un ping réussi ne valide pas davantage la route au-delà du premier saut. Le test doit porter sur le trajet promis.

Deux familles, deux verdicts

Les instances IPv4 et IPv6 sont indépendantes. Une icône « passerelle redondante » unique masque cette séparation. Le châssis peut être actif pour un VRID IPv4 et rester Backup, ou mal converger, pour l’instance IPv6 correspondante. ARP et Neighbor Discovery suivent également des chemins de preuve distincts.

La norme ajoute une frontière importante pour les services annoncés en IPv6 : un propriétaire ne devrait transmettre certaines options de Router Advertisement que si les secours peuvent reprendre intégralement le service avec un état synchronisé. Émettre la même adresse ne garantit pas que les fonctions attachées à cette adresse aient suivi.

Le reçu minimal d’exploitation

Une relève vérifiable rassemble au moins neuf éléments : l’instance exacte et sa famille ; la configuration de propriété, priorité, préemption et acceptation ; la dernière annonce valide ; le calcul du délai ; la raison du vainqueur ; la MAC virtuelle vue sur les commutateurs ; les caches ARP ou ND ; les interfaces, adjacences, politiques et routes du nouvel actif ; enfin la perte, le temps de reprise et le résultat applicatif observés séparément en IPv4 et IPv6.

BFD peut apporter une observation supplémentaire d’un chemin bidirectionnel lorsqu’il est réellement intégré à la décision. Le modèle YANG de VRRP peut exposer états et compteurs. Ni l’un ni l’autre n’est implicitement contenu dans le mot Active. Ils deviennent utiles lorsqu’un système de preuve les relie explicitement à l’élection et au trafic.

La force de RFC 9568 tient à sa modestie : une élection locale, déterministe et interopérable. La faiblesse naît ailleurs, lorsque l’organisation demande à ce rôle de certifier un monde que les annonces n’ont jamais observé.

Sources