A Real-World VRRP Issue: How Duplicate VRIDs Caused Cross-Site HA Confusion

Introduction

Sometimes high availability doesn’t fail loudly — it fails confusingly.

I recently ran into an issue in a multi-site Keepalived setup where everything looked correct: VIPs were assigned, services were running, and nodes were reachable. Yet the logs kept filling up with VRRP warnings.

What followed was a classic troubleshooting journey — checking configs, capturing packets, and slowly connecting the dots.

The Environment

We had:

Two separate sites

• Each site had two Keepalived nodes
• Each pair shared VIPs for service high availability
• VRRP was running in multicast mode

On paper, the design was straightforward.

The First Sign of Trouble

One of the nodes kept logging messages like:

“IP address associated with VRID not present in MASTER advertisement”

The strange part?

• The VIP was actually configured
• The node did hold the VIP correctly
• Failover still worked

So why did Keepalived think the VIP was “missing”?

Step 1 — Check the Configuration

We verified everything:

• VIP definitions ✅
• Priorities and master/backup roles ✅
• Authentication settings ✅
• Network interface bindings ✅

Everything looked clean. Nothing obviously wrong.

But the logs didn’t lie — something was off at the VRRP level.

Step 2 — Look at the Network (tcpdump)

Next step: check what VRRP traffic the node was actually receiving.

We ran a packet capture for VRRP advertisements.

What we discovered changed everything.

The node was receiving multiple advertisements for the same VRID — but those advertisements were announcing different VIPs.

That should never happen inside a single VRRP group.

This meant one thing:

👉 The node was seeing VRRP traffic that didn’t belong to its own HA pair.

Step 3 — The Root Cause

After reviewing configurations across both sites, the issue became clear:

Both sites were using the same VRIDs.

Even though the sites were logically separate, they shared the same broadcast domain for multicast traffic. That meant:

• Site A nodes sent VRRP advertisements
• Site B nodes also received them
• Keepalived saw advertisements for the same VRID but with different VIPs
• It assumed something was wrong and logged warnings

Nothing was “broken” — but the VRRP groups were overlapping unintentionally.

The Fix

We simply:

✔ Assigned unique VRIDs per site ✔ Restarted the nodes in proper order (backup first, master after) ✔ Monitored VRRP traffic and logs

Result?

• No more warnings
• Clean advertisements
• Stable VIP ownership
• HA behavior remained perfect.

Conclusion

This wasn’t a service outage — it was a visibility and design issue. But resolving it improved stability, reduced log noise, and ensured long-term reliability of the HA setup.

And like many good troubleshooting stories, the fix was simple — once the real cause was understood.