Home/Engineer/Networking / Servers/keepalived VRRP: Setting Up …
Networking / ServersAdvancedUbuntuDebianCentOSkeepalivedvrrpha

keepalived VRRP: Setting Up Virtual IP Failover with Health Checks and Split-Brain Prevention

Share a virtual IP across nodes with VRRP so traffic fails over without downtime when the master dies. Covers MASTER/BACKUP setup, vrrp_script health checks, and split-brain prevention for production.

Contents
  1. keepalived and VRRP — a virtual IP that never dies
  2. Configuration scenario
  3. Installation and kernel settings
  4. MASTER configuration (node1)
  5. BACKUP configuration (node2)
  6. Verifying the VIP and failover
  7. Service health checks — vrrp_script
  8. Notifications and state-transition hooks
  9. Split-brain and caveats

keepalived and VRRP — a virtual IP that never dies

If you have only one load balancer or gateway, the whole service stops the moment that server dies (SPOF, a single point of failure). keepalived uses VRRP (Virtual Router Redundancy Protocol) so multiple nodes share a virtual IP (VIP): when the master dies, a backup takes over the VIP immediately.

Here is how it works.

  • Several nodes compete for one VIP using priority.
  • The node with the highest priority becomes MASTER and holds the VIP.
  • The MASTER periodically sends VRRP advertisements via multicast.
  • If advertisements stop (master down), a BACKUP detects it and takes over the VIP. From the client’s point of view the IP never changes, so no reconnect is needed.

keepalived is not a tool that “keeps a server alive.” It is a tool that “moves an IP onto a living node.” The usual pattern is HAProxy/Nginx behind it for actual traffic distribution, with keepalived handling only failover of the front-end VIP.


Configuration scenario

  • VIP: 10.0.0.100 (the address clients talk to)
  • node1: 10.0.0.11 — MASTER in normal operation (higher priority)
  • node2: 10.0.0.12 — BACKUP in normal operation

Installation and kernel settings

Bash
# Ubuntu / Debian
sudo apt update && sudo apt install -y keepalived

# RHEL / CentOS / Rocky
sudo dnf install -y keepalived

Enable the kernel option so a service can bind the VIP before it is locally assigned (useful when pairing with HAProxy).

Bash
echo 'net.ipv4.ip_nonlocal_bind = 1' | sudo tee /etc/sysctl.d/60-keepalived.conf
sudo sysctl --system

MASTER configuration (node1)

/etc/keepalived/keepalived.conf:

Config
vrrp_instance VI_1 {
    state MASTER
 interface eth0 # VIP
 virtual_router_id 51 # (0~255)
 priority 110 # (MASTER )
 advert_int 1 #

    authentication {
        auth_type PASS
 auth_pass s3cretVRRP # 8 ,
    }

    virtual_ipaddress {
 10.0.0.100/24 # VIP
    }
}

BACKUP configuration (node2)

Only state and priority differ. Everything else (virtual_router_id, auth_pass, VIP) must be identical.

Config
vrrp_instance VI_1 {
    state BACKUP
    interface eth0
 virtual_router_id 51 # MASTER
 priority 100 # MASTER
    advert_int 1

    authentication {
        auth_type PASS
 auth_pass s3cretVRRP #
    }

    virtual_ipaddress {
        10.0.0.100/24
    }
}

Start the service on both nodes.

Bash
sudo systemctl enable --now keepalived
sudo systemctl status keepalived

Verifying the VIP and failover

The VIP should appear on the interface only on the MASTER (check with ip addr. ifconfig may not show secondary IPs).

Bash
# node1 (MASTER)
ip addr show eth0
# inet 10.0.0.11/24 ...
# inet 10.0.0.100/24 scope global secondary eth0 ← VIP

# node2 (BACKUP) VIP

Failover test:

Bash
# node1 keepalived → when
sudo systemctl stop keepalived

# node2 when check → VIP
ip addr show eth0 | grep 10.0.0.100

#
sudo journalctl -u keepalived -f
# ... Entering MASTER STATE

When you start keepalived on node1 again, its higher priority takes the VIP back (preemption).


Service health checks — vrrp_script

Plain VRRP only watches whether the keepalived process is alive. What actually matters is whether HAProxy/Nginx behind it is alive. Use vrrp_script to watch application health and drop priority when the service dies so the VIP moves.

Config
vrrp_script chk_haproxy {
 script "/usr/bin/killall -0 haproxy" # check( 0)
 interval 2 # 2
 weight -20 # failed when priority 20
 fall 2 # 2 failed DOWN
 rise 2 # 2 UP
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 110
    advert_int 1
    authentication { auth_type PASS; auth_pass s3cretVRRP }
    virtual_ipaddress { 10.0.0.100/24 }

    track_script {
 chk_haproxy # Result
    }
}

Now if HAProxy on node1 dies, priority falls from 110 to 90, which is lower than node2 (100), and the VIP moves to node2 automatically. The key point is failover when the service dies even if the server is still up.


Notifications and state-transition hooks

To get notified or run extra work on a transition, attach notify scripts.

Config
vrrp_instance VI_1 {
    # ...
    notify_master "/etc/keepalived/to_master.sh"
    notify_backup "/etc/keepalived/to_backup.sh"
    notify_fault  "/etc/keepalived/to_fault.sh"
}

Split-brain and caveats

  • virtual_router_id collision: If another keepalived group on the same L2 network uses the same VRID, they will mistake each other. Use a value unique within the segment.
  • Allow VRRP on the firewall: VRRP uses IP protocol 112 and multicast (224.0.0.18). If advertisements are blocked, both sides become MASTER — split-brain (duplicate VIP).
Bash
# : firewalld VRRP
sudo firewall-cmd --permanent --add-rich-rule='rule protocol value="vrrp" accept'
sudo firewall-cmd --reload
  • Cloud environments: AWS/GCP block multicast and control IP movement themselves, so keepalived VRRP does not work as-is. In the cloud, reassign an ENI/secondary IP (unicast peer setup) or use a managed load balancer. You can configure unicast VRRP with unicast_src_ip / unicast_peer.

keepalived is the lightest HA tool for keeping the VIP in front of HAProxy or Nginx without downtime. Follow three rules — “VRID, auth, and VIP identical on both nodes; only state and priority differ; watch the service with vrrp_script” — and a solid two-node failover is straightforward.

#keepalived#vrrp#ha
Editorial note

AI tools may assist drafting. Check the evidence in each guide for whether commands were run and which environment was used. Confirm the current docs for your version before applying instructions, and email us about errors. email us

Questions & answers

Ask a question about this guide. We'll review and reply.