Keepalived limitations - when VRRP is not enough

Keepalived is excellent for the floating-IP use case but has limits. This lesson covers those limits and the alternatives when keepalived is not enough.

Same-subnet requirement

VRRP uses layer 2 multicast. The two routers must be on the same subnet. For cross-subnet or cross-region failover, VRRP does not work.

Alternatives:

• DNS-based failover: update DNS to point to the active host. Latency is high (DNS TTL).
• Anycast IP: multiple sites advertise the same IP via BGP. Used for global services.
• Cloud load balancer: AWS ALB, GCP LB, etc. Cross-region by design.

Basic health checks

Keepalived’s built-in checks (HTTP, TCP, process) are basic. For complex checks, write a script. For distributed services, the check may not capture the full state.

Alternatives:

• HAProxy + Consul: HAProxy for load balancing, Consul for service discovery and health.
• Envoy + xDS: service mesh with health-aware routing.
• Application-level health endpoints: a /health endpoint that reports the full service state.

Two-instance limit

VRRP groups can have many members, but the practical limit is 2-3. For more, use a different pattern.

Alternatives:

• Nginx upstream pool: multiple backends, health checks, load balancing.
• HAProxy backend pool: same idea.
• DNS round-robin: simple, but no health awareness.

No application awareness

Keepalived manages a VIP. The application behind the VIP is its own concern. Keepalived does not drain connections on failover; it just moves the VIP. The application may lose in-flight requests.

Alternatives:

• HAProxy + drain: HAProxy can drain connections on shutdown.
• Envoy + graceful: Envoy supports graceful drain.
• Application-level retry: the client retries on connection loss.

No fencing: dual MASTER split brain

This is the limit that takes production down, and it is missing from most keepalived summaries. Keepalived never verifies that the other peer has stopped. It only infers state from VRRP advertisements. If those advertisements stop arriving while both hosts are alive, both peers declare themselves MASTER, both raise the VIP, and the segment has a duplicate IP with flapping ARP.

Three common causes:

• A host firewall that does not permit IP protocol 112. VRRP is neither TCP nor UDP, so a port-based ruleset silently drops it. This usually appears when the security baseline is applied to a pair that was already working.
• Switch multicast filtering or IGMP snooping dropping the 224.0.0.18 group.
• A genuine partition between the peers.

Detect it by comparing both peers at once - a MASTER transition on each within the same second is the signature:

# Run on BOTH peers and compare timestamps
journalctl -u keepalived --since -1h | grep -i 'Entering MASTER'

# Duplicate address detection from a third host on the segment
arping -D -I eth0 -c 3 10.0.0.100

Prevent it by permitting protocol 112 between the peers before the firewall goes live, and by using unicast_peer so advertisements do not depend on multicast at all. Both are worked through in the keepalived configuration lesson.

A related allocation limit belongs here: the virtual_router_id must match within a group and be unique among all VRRP groups on the same L2 segment. The VRID selects the virtual MAC 00:00:5e:00:01:<vrid>, so two unrelated pairs both using the default 51 collide on one VLAN.

When to use keepalived

• Floating IP between two routers on the same subnet.
• Failover in the low seconds, not sub-second: the master-down interval is 3 x advert_int plus a priority skew, so the advert_int 1 used throughout this course gives roughly 3.6 seconds. Sub-second requires a sub-second advert_int, at the cost of far more sensitivity to transient packet loss. Measure your own number rather than quoting either figure.
• Simple, no need for application awareness.

When not to use keepalived

• More than 3 instances.
• Cross-subnet or cross-region.
• Application needs graceful drain.
• Multiple services with different health.
• The workload cannot tolerate two writers. Keepalived has no fencing, so it cannot rule out dual MASTER.

Use a load balancer (HAProxy, Envoy, cloud LB) for these cases.

Knowledge check