Le VRRP semble simple jusqu'à ce qu'il ne le soit plus : deux routeurs revendiquant tous deux le rôle de maître en même temps, un basculement qui fonctionne techniquement mais met vingt minutes à réellement se rétablir, ou deux sites qui génèrent silencieusement la même adresse MAC virtuelle. Trois cas de terrain réels, les commandes qui ont permis d'identifier chaque cause racine, et ce qu'il faut vérifier la prochaine fois que le VRRP se comporte mal.
Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026
Dans les trois cas ci-dessous, la configuration VRRP elle-même était correcte — la panne se trouvait une couche plus loin, dans le MSTP, dans la gestion ARP, ou dans un second site que personne n'avait vérifié.
Le VRRP lui-même est un protocole simple : la priorité décide qui est maître, et une adresse MAC virtuelle bien connue dérivée du VRID rend le basculement invisible pour les hôtes du segment. C'est précisément cette simplicité qui fait que, lorsque le VRRP se comporte mal, relire la configuration VRRP ligne par ligne est généralement le mauvais premier réflexe. Les trois cas de terrain ci-dessous remontent tous à quelque chose d'adjacent au VRRP — une boucle que le STP n'avait pas réellement bloquée, une fonctionnalité de durcissement ARP interagissant mal avec une panne de lien, et une collision d'adresse MAC virtuelle entre deux sites jamais vérifiés l'un par rapport à l'autre.
Voici chaque cas décomposé — le réseau où il s'est produit, le symptôme, les commandes qui ont identifié la cause, et la solution — ainsi que les réponses de FAQ sur l'élection du maître VRRP et les causes du double-maître qui reviennent chaque fois que ces tickets sont discutés.
Le double-maître, une récupération lente et un silence total entre deux sites ressemblent au même protocole qui dysfonctionne — ce ne sont pas la même panne, et elles ne se résolvent pas de la même façon.
Placer d'abord le symptôme sur cet arbre indique lequel des cas ci-dessous correspond réellement à ce que vous observez, et quelle fonctionnalité en dehors du VRRP lui-même il faut aller vérifier.
Les légendes du schéma restent en anglais pour la clarté technique.
Aucune de ces trois pannes n'est un bug du protocole VRRP — le VRRP expose un problème qui existait déjà dans le réseau : une boucle non bloquée, une fonctionnalité de durcissement ARP qui supposait que la topologie ne changerait jamais, et un VRID jamais coordonné entre les sites. Corriger la fonctionnalité adjacente corrige le VRRP.
Même protocole, trois causes racines complètement différentes — et trois ensembles de commandes différents pour confirmer chacune.
SwitchA et SwitchB affichaient tous deux l'état VRRP Master en même temps ; les clients filaires et sans fil d'une partie du réseau avaient perdu l'accès Internet. La cause n'était pas le VRRP — c'était une boucle que le MSTP n'avait pas réellement bloquée.
<HUAWEI> display cpu-defend statistics all
Statistics on slot 2:
--------------------------------------------------------------------------------
Packet Type Pass(Packet/Byte) Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
vrrp 47876567 1856471019 2017-06-21 10:46:18
3255606556 126240029k
// huge pass+drop counts on vrrp -> far more VRRP traffic than two routers should generate
<HUAWEI> display trapbuffer
#Jun 21 2017 10:36:14 HX-1 L2IFPPI/4/MFLPVLANALARM:OID 1.3.6.1.4.1.2011.5.25.160.3.7 MAC move
detected, VLANID = 28, MacAddress = 12b7-c3d0-9070, Original-Port = XGE2/0/0, Flapping port =
XGE2/0/10 and XGE2/0/6. Please check the network accessed to flapping port.
// Original-Port / Flapping port -> trace these down to the downstream switch with the loopSwitchA (maître) et SwitchB (secours) étaient reliés par un câble de battement de cœur ; un serveur à double rattachement se trouvait sur les deux. Lorsque le lien du serveur vers SwitchA est tombé en panne, le trafic est bien passé sur le chemin de secours — mais le service n'a réellement récupéré qu'après 20 minutes.
[SwitchB] undo arp anti-attack entry-check fixed-all enable
[SwitchB] undo arp learning strict
// server's ARP entry is now free to re-learn against the new inbound interface
// instead of waiting up to ~20 minutes for the old heartbeat-interface entry to age outSite1 et Site2 communiquaient via un réseau fédérateur ; la paire de pare-feu de chaque site exécutait son propre cluster VRRP. SW-1 pouvait pinguer SW-2 à travers le réseau fédérateur, mais les pare-feu des deux sites ne pouvaient pas du tout se joindre.
[SW-1] display mac-address | include 0000-5e00-0136
-------------------------------------------------------------------------------
MAC Address VLAN/VSI Learned-From Type
-------------------------------------------------------------------------------
0000-5e00-0136 339/- XGE0/0/1 dynamic
0000-5e00-0136 339/- GE0/0/2 dynamic
-------------------------------------------------------------------------------
// same virtual MAC learned from two different directions -> loop, or duplicate VRID
// no loop found -> checked VRRP config on both firewall clusters -> same VRID both sites
// virtual MAC format: 00-00-5E-00-01-{virtual-router-ID} -> identical VRID = identical MACUne fois que l'arbre ci-dessus vous a indiqué dans quel cas vous êtes, ces cinq points expliquent l'essentiel de ce qui ne va vraiment pas.
SYMPTÔMELes deux routeurs VRRP signalent simultanément l'état maître ; la configuration VRRP des deux routeurs est parfaitement cohérente lorsqu'on la compare.
CAUSEUne boucle quelque part en aval inonde les annonces VRRP et corrompt la table MAC sur le chemin entre les deux routeurs, de sorte que chaque routeur cesse d'entendre de façon fiable les hellos de l'autre et décide indépendamment qu'il est le seul maître restant.
SOLUTIONNe commencez pas par relire la configuration VRRP — vérifiez d'abord display cpu-defend statistics all et display trapbuffer pour une alarme de déplacement MAC, puis remontez la boucle à partir de là. Voir « Tempête de boucle de couche 2 » pour le processus complet de chasse à la boucle.
SYMPTÔMELe basculement se produit, mais le réseau ne récupère réellement que plusieurs minutes plus tard — pas des secondes, des minutes.
CAUSELa fixation ARP dispose de trois modes mutuellement exclusifs pour différentes situations : fixed-mac convient à une adresse MAC fixe qui erre entre les ports d'accès ; fixed-all convient lorsque le MAC et l'emplacement d'accès restent tous deux fixes ; send-ack convient lorsque les deux changent fréquemment. Configurer fixed-all dans une topologie où le point d'accès change réellement — comme un serveur à double rattachement basculant entre deux commutateurs — verrouille l'entrée périmée en place jusqu'à ce qu'elle expire naturellement.
SOLUTIONFaites correspondre le mode de fixation au comportement réel du réseau, pas à une liste générique de durcissement sécuritaire. Si le point d'accès peut légitimement changer, fixed-mac ou send-ack est le mode correct — fixed-all ne l'est pas.
SYMPTÔMEDeux sites qui devraient être indépendants l'un de l'autre ne peuvent pas du tout communiquer, même si le cluster VRRP propre à chaque site fonctionne bien en interne.
CAUSEL'adresse MAC virtuelle qu'un groupe VRRP annonce est dérivée de façon déterministe de son VRID (00-00-5E-00-01-{VRID}), et non choisie indépendamment. Deux sites configurés avec le même VRID — tout à fait plausible lorsque chaque site a été construit par une équipe différente, ou à partir du même modèle — finissent par générer l'adresse MAC virtuelle identique, et tout équipement sur le chemin entre eux voit la même adresse MAC arriver depuis deux directions.
SOLUTIONTraitez le VRID comme une valeur devant être coordonnée sur tous les sites partageant le même réseau fédérateur, pas seulement unique au sein du propre groupe VRRP d'un seul site. Renumérotez le VRID d'un site pour résoudre la collision.
SYMPTÔMEL'état VRRP change plus souvent qu'un événement de lien réel ne l'expliquerait, ou le « mauvais » routeur devient sans cesse maître.
CAUSEPar défaut, le VRRP préempte : tout routeur qui découvre que sa propre priorité est supérieure à celle du maître actuel prend immédiatement le relais, et l'ancien maître redevient secours. Si les valeurs de priorité, le mode de préemption ou le délai de préemption ne sont pas configurés de manière cohérente avec la conception prévue, les routeurs peuvent échanger le rôle de maître à chaque fois qu'une interface surveillée oscille ou qu'un recalcul de priorité se produit.
SOLUTIONDécidez délibérément quel routeur doit détenir le rôle de maître en conditions normales, réglez sa priorité en conséquence, et configurez un délai de préemption raisonnable afin qu'une interface instable ne déclenche pas un échange de rôle à chaque transition.
SYMPTÔMEdisplay vrrp montre que le groupe est en bonne santé et que le maître est actif, mais pinguer l'adresse IP virtuelle elle-même ne donne aucune réponse.
CAUSEIl s'agit d'un comportement par défaut attendu, pas d'une panne — le VRRP ne répond pas aux pings adressés à l'IP virtuelle à moins que ce comportement ne soit explicitement activé.
SOLUTIONActivez vrrp virtual-ip ping enable en vue système si vous avez spécifiquement besoin que l'IP virtuelle réponde aux requêtes ICMP echo à des fins de surveillance.
[HUAWEI] vrrp virtual-ip ping enableTirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
C'est la priorité qui décide : le routeur ayant la priorité configurée la plus élevée dans le groupe devient maître, et les autres restent secours. Avec le mode de préemption par défaut, tout routeur qui découvre ensuite que sa propre priorité est supérieure à celle du maître actuel prend immédiatement le relais, et l'ancien maître redevient secours. En mode sans préemption, une fois qu'un routeur est maître, il le reste même si un routeur de priorité supérieure rejoint plus tard, tant qu'il n'est pas tombé en panne. Une interface surveillée qui tombe abaisse automatiquement la priorité de ce routeur d'une valeur configurée, c'est ainsi que les pannes de lien se reflètent dans l'élection.
Par défaut, l'IP virtuelle ne répond pas du tout aux requêtes ICMP echo — c'est normal, pas une panne. Exécutez vrrp virtual-ip ping enable en vue système si vous avez besoin qu'elle réponde à des fins de surveillance.
À vérifier dans l'ordre : des paramètres de configuration asymétriques entre les deux routeurs (type et clé d'authentification, ID de groupe, liste d'IP virtuelles, version VRRP) ; le lien de battement de cœur entre les deux routeurs en panne ou instable ; un port qui aurait dû être bloqué par STP ou RRPP ne bloquant pas ; et une utilisation CPU anormalement élevée sur l'un des routeurs retardant son traitement des hellos VRRP.
Lorsque les priorités sont égales, le routeur ayant l'adresse IP principale la plus élevée sur l'interface VRRP devient maître. C'est un cas limite qu'il vaut mieux éviter par conception — attribuer délibérément des priorités différentes au routeur principal et de secours prévus élimine entièrement l'ambiguïté.
Oui. Si les deux routeurs dépendent d'un lien de battement de cœur dédié pour échanger les hellos VRRP et que ce lien tombe en panne alors que les deux routeurs sont par ailleurs en bonne santé, chaque côté cesse d'entendre l'autre et se promeut indépendamment maître — exactement le même symptôme final que le Cas 1 ci-dessus, mais avec une cause racine complètement différente à traquer.
Ces trois cas sont tirés de déploiements VRRP sur des commutateurs de campus Huawei série S et des clusters de pare-feu, utilisant les commandes display cpu-defend statistics / display trapbuffer / display mac-address montrées ci-dessus. La logique sous-jacente — élection pilotée par la priorité, adresse MAC virtuelle dérivée du VRID, et comportement ARP autour d'un basculement — s'applique à la plupart des implémentations de la famille VRRP des autres fournisseurs, mais la syntaxe exacte des commandes différera. Cette note ne couvre pas en profondeur VRRP6, l'équilibrage de charge VRRP avec plusieurs routeurs virtuels par groupe, ni l'interopérabilité avec des protocoles tiers de type VRRP.
Dites-nous le symptôme — double-maître, récupération lente, ou deux sites qui ne peuvent pas communiquer — avec la sortie de display trapbuffer / display mac-address, et nous vous aiderons à l'interpréter.