VRRP looks simple until it isn't: two routers both claiming Master at once, a switchover that technically works but takes twenty minutes to actually recover, or two sites that silently generate the exact same virtual MAC. Three real field cases, the commands that pinned down each root cause, and what to check the next time VRRP misbehaves.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
In all three cases below, the VRRP configuration itself was fine — the fault was sitting one layer away, in MSTP, in ARP handling, or in a second site nobody had cross-checked.
VRRP itself is a simple protocol: priority decides who's Master, and a well-known virtual MAC derived from the VRID makes the failover invisible to hosts on the segment. That simplicity is exactly why, when VRRP misbehaves, re-reading the VRRP configuration line by line is usually the wrong first move. The three field cases below all trace back to something adjacent to VRRP — a loop that STP hadn't actually blocked, an ARP-hardening feature interacting badly with a link failure, and a virtual MAC collision between two sites that were never checked against each other.
What follows is each case broken down — the network it happened on, the symptom, the commands that pinned down the cause, and the fix — plus the FAQ answers on VRRP master election and dual-master causes that come up whenever these tickets get discussed.
Dual-master, a slow recovery, and total silence between two sites look like the same protocol misbehaving — they aren't the same fault, and they aren't fixed the same way.
Placing the symptom on this tree first tells you which case below is actually the one you're looking at, and which feature outside VRRP itself you should go check.
Diagram labels are kept in English for engineering clarity.
None of these three faults are VRRP protocol bugs — they're VRRP exposing a problem that was already sitting in the network: an unblocked loop, an ARP-hardening feature that assumed the topology would never change, and a VRID that was never coordinated across sites. Fixing the adjacent feature fixes VRRP.
Same protocol, three completely different root causes — and three different sets of commands to confirm each one.
SwitchA and SwitchB both showed VRRP state Master at the same time; wired and wireless clients on part of the network lost internet access. The cause wasn't VRRP — it was a loop MSTP hadn't actually blocked.
<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 (Master) and SwitchB (Backup) were linked by a heartbeat cable; a dual-homed server sat on both. When the server's link to SwitchA failed, traffic did move to the backup path — but service didn't actually recover for 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 and Site2 talked to each other through a backbone; each site's firewall pair ran its own VRRP cluster. SW-1 could ping SW-2 across the backbone, but the two sites' firewalls could not reach each other at all.
[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 MACOnce the tree above has told you which case you're in, these five account for most of what's actually wrong.
SYMPTOMBoth VRRP routers report Master simultaneously; the two routers' own VRRP configuration is completely consistent when you compare them.
CAUSEA loop somewhere downstream floods VRRP advertisements and corrupts the MAC table on the path between the two routers, so each router stops reliably hearing the other's hellos and independently decides it's the only Master left standing.
FIXDon't start by re-reading the VRRP configuration — check display cpu-defend statistics all and display trapbuffer for a MAC-move alarm first, and trace the loop from there. See Layer 2 Loop Storm: Finding the Loop When the Whole Network Goes Down for the full loop-hunting process.
SYMPTOMFailover happens, but the network doesn't actually recover until several minutes later — not seconds, minutes.
CAUSEARP fixation has three mutually exclusive modes for different situations: fixed-mac suits a fixed MAC address that roams between access ports; fixed-all suits both MAC and access location staying fixed; send-ack suits both changing frequently. Configuring fixed-all in a topology where the access point does change — like a dual-homed server failing over between two switches — locks the stale entry in place until it naturally ages out.
FIXMatch the fixation mode to how the network actually behaves, not to a generic security hardening checklist. If the access point can legitimately change, fixed-mac or send-ack is the correct mode — fixed-all is not.
SYMPTOMTwo sites that should be independent of each other can't communicate at all, even though each site's own VRRP cluster works fine internally.
CAUSEThe virtual MAC a VRRP group advertises is derived deterministically from its VRID (00-00-5E-00-01-{VRID}), not chosen independently. Two sites configured with the same VRID — entirely plausible when each site was built by a different team, or from the same template — end up generating the identical virtual MAC, and any device on the path between them sees the same MAC arriving from two directions.
FIXTreat VRID as a value that has to be coordinated across every site sharing the same backbone, not just unique within a single site's own VRRP group. Renumber one site's VRID to resolve the collision.
SYMPTOMVRRP state changes more often than an actual link event would explain, or the "wrong" router keeps becoming Master.
CAUSEBy default VRRP preempts: any router that discovers its own priority is higher than the current Master's immediately takes over, and the previous Master steps down to Backup. If priority values, preemption mode, or preemption delay aren't configured consistently with the intended design, routers can trade the Master role back and forth every time a monitored interface flaps or a priority recalculation happens.
FIXDecide deliberately which router should hold Master under normal conditions, set its priority accordingly, and configure a sensible preemption delay so a flapping interface doesn't trigger a role swap on every transition.
SYMPTOMdisplay vrrp shows the group is healthy and Master is active, but pinging the virtual IP address itself gets no reply.
CAUSEThis is expected default behavior, not a fault — VRRP doesn't respond to pings addressed to the virtual IP unless that behavior is explicitly turned on.
FIXEnable vrrp virtual-ip ping enable in the system view if you specifically need the virtual IP to answer ICMP echo requests for monitoring purposes.
[HUAWEI] vrrp virtual-ip ping enablePulled straight from the field — the ones worth having an answer ready for.
Priority decides it: the router with the highest configured priority in the group becomes Master, and the rest stay Backup. With the default preempt mode, any router that later discovers its own priority is higher than the current Master's takes over immediately, and the old Master drops back to Backup. In non-preempt mode, once a router is Master, it stays Master even if a higher-priority router joins later, as long as it hasn't failed. A monitored interface going down automatically lowers that router's priority by a configured amount, which is how link failures get reflected into the election.
By default the virtual IP doesn't answer ICMP echo requests at all — that's normal, not a fault. Run vrrp virtual-ip ping enable in the system view if you need it to respond for monitoring purposes.
Worth checking in order: asymmetric configuration parameters between the two routers (authentication type and key, group ID, virtual IP list, VRRP version); the heartbeat link between the two routers being down or unstable; a port that should have been blocked by STP or RRPP failing to block; and unusually high CPU utilization on one of the routers delaying its VRRP hello processing.
When priorities are equal, the router with the higher primary IP address on the VRRP interface becomes Master. This is a corner case worth avoiding by design — deliberately assigning different priorities to the intended primary and backup router removes the ambiguity entirely.
Yes. If the two routers rely on a dedicated heartbeat link to exchange VRRP hellos and that link goes down while both routers are otherwise healthy, each side stops hearing the other and independently promotes itself to Master — exactly the same end symptom as Case 1 above, but with a completely different root cause to chase down.
These three cases are drawn from Huawei S-series campus switch and firewall-cluster VRRP deployments, using the display cpu-defend statistics / display trapbuffer / display mac-address commands shown above. The underlying logic — priority-driven election, a VRID-derived virtual MAC, and ARP behavior around a failover — carries over to most vendors' VRRP-family implementations, but exact command syntax will differ. This note doesn't cover VRRP6, VRRP load-balancing with multiple virtual routers per group, or third-party VRRP-like protocol interoperability in depth.
Tell us the symptom — dual-master, a slow recovery, or two sites that can't talk — plus your display trapbuffer / display mac-address output, and we'll help you read it.