VRRP Protocol and Keepalived: How Does the Virtual IP "Drift"?

In the previous chapter, we mentioned that a virtual IP (VIP) can "drift" between primary and standby machines, achieving high availability at the entry point.

But how exactly does VIP float up? What is the principle behind it?

The answer is VRRP protocol——Virtual Router Redundancy Protocol (Virtual Router Redundancy Protocol).

This chapter will start from the most fundamental protocol mechanisms and, with Keepalived configuration examples, thoroughly understand the ins and outs of VIP drift.

1. What is the VRRP protocol?

VRRP is a standard network protocol, first defined in RFC 3768. Its goal is simple:Enable multiple routers to share the same virtual IP to achieve high availability of the gateway..

Traditionally, VRRP is used for active/standby failover of routers. But in our scenario, it is equally applicable to ordinary Linux servers—Keepalived is a complete implementation of the VRRP protocol.

Core concepts:

concept	Description
Virtual router	A logical group composed of multiple physical machines that appears externally as a single "virtual" device
Virtual IP (VIP)	The external IP of the virtual router, the address actually accessed by the client (in this article,192.168.0.200）
Virtual MAC	The virtual MAC address generated by VRRP (00-00-5E-00-01-{VRID})
Master	The node that is currently actually processing the request and has the VIP
Backup	Standby node, monitors Master heartbeat, ready to take over
VRID	Virtual router ID must be unique within the same network

II. Core Mechanisms of VRRP

2.1 Priority determines who is Master

VRRP uses a simple rule to determine who is Master:The node with the highest priority becomes Master.

# Master node configuration (192.168.0.201)
priority: 100

# Standby node configuration (192.168.0.202)
priority: 90

# Standby node configuration (192.168.0.203)
priority: 80

The priority range is 1–255. The higher the value, the more likely it is to become Master.

When multiple nodes have the same priority, the node with the largest IP address wins (this is a fallback strategy to prevent conflicts).

2.2 Heartbeat Detection: Master Periodically Reports All Is Well

The Master sends to the multicast address at intervals (default 1 second)224.0.0.18 Send VRRP advertisement packets to tell all Backup nodes: "I'm still alive."

The notification message contains:

• Master's priority

• Virtual IP address (192.168.0.200)

• VRID

• Notification interval

2.3 Fault Detection: Backup Wait Timeout

The Backup node continuously listens for announcements from the Master. If consecutive 3 seconds(Default 3 announcement cycles) If no heartbeat from the Master is received, the Master is determined to be down.

2.4 Preemption Mode: Higher Priority Takes Precedence

VRRP default is Preemption mode This means:

• If the current Master goes down, the node with the highest priority among the Backups takes over and becomes the new Master.

• If the original Master recovers (and its priority is higher), it will preempt the VIP again and become Master again.

The advantage of this model is:Always let the node with the highest configured priority provide the service..

If you need to avoid frequent switching (for example, brief disconnections caused by network jitter), you can enable nopreempt Non-preemptive mode; we will discuss it in detail in the subsequent “Production Best Practices” chapter.

2.5 MAC Address Migration: How Does the Network Topology Perceive the Switchover?

The most ingenious design of VRRP is MAC address flapping.

Each VRRP virtual router generates a virtual MAC address:

00-00-5E-00-01-{VRID}

• 00-00-5E: The OUI assigned to VRRP by IANA

• 00-01 Fixed value

• {VRID}: Virtual Router ID (1-255)

When the Master switches, the new Master will send a Gratuitous ARP (Gratuitous ARP) Broadcast to tell the entire network: The virtual MAC address is now with me, update your ARP cache!

This process is completely transparent to the client. The client accesses the same VIP from beginning to end.192.168.0.200 and the corresponding virtual MAC, with no configuration changes required.

III. Keepalived: A Complete Implementation of VRRP

Keepalived is the most popular VRRP implementation on Linux. It not only implements the VRRP protocol but also integrates health check mechanisms.

3.1 Core Components of Keepalived

Component	Responsibility
VRRP protocol stack	Implement heartbeat, election, and preemption logic.
VIP Management	Add/Delete Virtual IP
Health check framework	Regularly check service status and impact priority.

3.2 A Minimal Keepalived Configuration

The following is an example of primary/standby configuration for three machines (based on a home network 192.168.0.0/24 网段）：

Master node (192.168.0.201):

global_defs {
    router_id KEEPALIVED_MASTER
}

vrrp_instance VI_1 {
    state MASTER              # Initial character: Main
    interface eth0            # Listening network interface
    virtual_router_id 51      # VRID must be consistent within the same cluster.
    priority 100              # Priority: primary is higher than backup
    advert_int 1              # Heartbeat interval: 1 second

    authentication {
        auth_type PASS
        auth_pass 1234        # Simple authentication to prevent malicious joining.
    }

    virtual_ipaddress {
        192.168.0.200/24 dev eth0 label eth0:vip
    }
}

Backup node 1 (192.168.0.202):

global_defs {
    router_id KEEPALIVED_BACKUP_1
}

vrrp_instance VI_1 {
    state BACKUP             # Initial character: Bei
    interface eth0
    virtual_router_id 51
    priority 90              # Priority: lower than primary
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass 1234
    }

    virtual_ipaddress {
        192.168.0.200/24 dev eth0 label eth0:vip
    }
}

Backup Node 2 (192.168.0.203):

global_defs {
    router_id KEEPALIVED_BACKUP_2
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 80              # Lowest priority
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass 1234
    }

    virtual_ipaddress {
        192.168.0.200/24 dev eth0 label eth0:vip
    }
}

3.3 Keepalived + Nginx Health Check

In production environments, we want Keepalived to not only detect whether the machine is alive, but also detect whether Nginx is working properly.

# Health check script (required on all three machines)
cat > /usr/local/bin/check_nginx.sh << 'EOF'
#!/bin/bash
if pgrep -x "nginx" > /dev/null; then
    exit 0   # Nginx is alive, normal
else
    exit 1   # Nginx is down, triggering failover.
fi
EOF

chmod +x /usr/local/bin/check_nginx.sh

Reference this script in the Keepalived configuration:

vrrp_script check_nginx {
    script "/usr/local/bin/check_nginx.sh"
    interval 2        # Check once every 2 seconds
    weight -20        # When the check fails, decrease the priority by 20.
    fall 2            # Only after 2 consecutive failures is it judged as a failure.
    rise 2            # Recovery is only determined after 2 consecutive successes.
}

vrrp_instance VI_1 {
    # ... other configuration ...
    track_script {
        check_nginx
    }
}

Working principle:

• Under normal circumstances, Master (192.168.0.201) Priority is 100

• If Master's Nginx goes down, the priority drops to 80 (100 - 20).

• At this time Backup 1 (192.168.0.202) Priority is 90 > 80, Backup 1 takes over and becomes the new Master

• After Nginx recovers, the priority returns to 100 and it preempts again.

IV. VRRP State Machine

VRRP defines three states; once you understand the state machine, you understand the entire protocol:

State	Have VIP	Send announcement	Heartbeat monitoring
Initialize	❌	❌	❌
Backup	❌	❌	✅
Master	✅	✅	❌

V. Common Questions and Misconceptions

Q1: What is the relationship between VRRP and Keepalived?

VRRP is a protocol standard(RFC 3768),Keepalived is a specific implementation of VRRP. In addition to VRRP, Keepalived also integrates functions such as health checks and load balancing (LVS).

Q2: Must the VIP be on the same subnet as the physical IP?

Yes. VIP 192.168.0.200 Must be with the physical IP (192.168.0.201/202/203) are on the same subnet 192.168.0.0/24, otherwise the switch cannot correctly forward data packets.

Q3: Does there need to be an independent network between Master and Backup?

Not required, but recommended. In production environments, it is recommended to use a dedicated heartbeat network to prevent business traffic fluctuations from affecting heartbeat detection.

Q4: Can VRRP cross network segments?

Cannot. VRRP advertisement packets are Layer 2 multicast (224.0.0.18), TTL is 1 and cannot cross routers. VIP failover can only occur within the same broadcast domain.

Q5: What happens if a network partition (split-brain) occurs?

Split-brain is the trickiest problem in VRRP. When the network between Master and Backup is interrupted, neither side can receive the other's heartbeat, both will consider themselves Master, and both will hold the VIP.192.168.0.200.

We will elaborate on the solution in detail in Chapter 7 (independent heartbeat network, non-preemptive mode, external arbitration, etc.).

VI. Review of the Practice Environment

The hands-on environment for this series uses the following home network configuration:

Configuration item	Value	Description
network segment	192.168.0.0/24	Standard home LAN
gateway	192.168.0.1	router address
VIP	192.168.0.200	Virtual IP, not actually bound to a network interface
node1	192.168.0.201	Priority 100, initial Master
node2	192.168.0.202	Priority 90, Backup 1
node3	192.168.0.203	Priority 80, Backup 2

💡 If your home network subnet is different (e.g.192.168.1.0/24), just need to take all 192.168.0.x Just replace it with your own network segment.

VII. Summary

This chapter provides an in-depth explanation of the core mechanisms of the VRRP protocol:

• Priority determines role.: The node with the highest priority becomes Master (in this example 192.168.0.201 Priority 100)

• Heartbeat detection failure: Master sends an advertisement every second; Backup takes over after a 3-second timeout

• MAC address migration: Notify network topology changes via gratuitous ARP

• Keepalived implementation Complete solution for VRRP + health checks

After understanding these principles, in the next chapter we will move into the hands-on phase: using Golang + Gin to implement a health check service that can speak, preparing for the subsequent deployment of Nginx and Keepalived.

💡 This article is Part 2 of the "Distributed High-Availability Ingress Architecture in Practice" series.

• Click to view all articles

• Previous:High-availability ingress for distributed systems: from single point of failure to VIP + Nginx architecture

• Next article:Implement a Web service with health checks using Golang + Gin