Learn Keepalived - VRRP Instances & Virtual IPs

#Introduction

In episode 3 you turned on a two-node configuration. Now it's time to dissect every line of vrrp_instance so you understand, not just copy. Episode 4 covers the parameters that determine VRRP behavior: state, priority, authentication, the VIP list, tracked interfaces, and preemption rules.

Understanding this part is what separates operators who resolve incidents in five minutes from those who blindly restart nodes. Floating IP behavior during failover, the MASTER vs BACKUP conditions, and how preemption works will determine the quality of your HA.

We'll structure this episode starting with the complete instance anatomy, then virtual IP behavior, tracked interfaces, and closing with the failback mechanism.

#Anatomy of a Complete vrrp_instance

#State and Interface Parameters

The first two parameters you always see:

• state: the initial instance status, MASTER or BACKUP. This is only the initial status; after election, the actual status is determined by priority and health.
• interface: the NIC where VRRP packets are sent and the VIP is attached.

Pick an interface that genuinely connects the node to the shared network. Using the wrong interface means nodes never hear each other's advertisements, and every node will consider itself MASTER.

#Virtual Router ID and Priority

virtual_router_id (1-255) separates VRRP groups. Two instances with the same ID on the same network will fight each other. priority (1-254) determines the election winner:

• The node with the highest priority becomes MASTER.
• If priorities are equal, the node with the higher primary IP wins.
• Priority 255 is reserved for the IP address owner.

Make sure virtual_router_id is unique for each distinct VIP, and consistent between nodes on the same instance.

#Authentication

The authentication block secures advertisements:

authentication {
  auth_type PASS
  auth_pass rahasia123
}

Important note: on Keepalived 2.2 and above, auth_type PASS has been removed because the VRRP standard deems this mechanism insecure. On newer versions, you use auth_type AH or drop this block entirely and rely on network isolation. We cover the full details in episode 9.

#Virtual IP: Placement and Behavior

#virtual_ipaddress

This block contains the list of VIPs owned by the instance:

virtual_ipaddress {
  192.168.1.100/24 dev eth0
  192.168.1.101/24 dev eth0
}

You can place multiple VIPs in a single instance. When the node becomes MASTER, all VIPs are attached; when it drops to BACKUP, all are released.

#virtual_ipaddress_excluded

If a VIP must be carried by the MASTER but isn't used for VRRP advertisements (for example, an IP for backend traffic), use a separate block:

virtual_ipaddress_excluded {
  10.0.0.10/24 dev eth0
}

The virtual_ipaddress_excluded block is useful for separating service VIPs from the VIPs involved in the VRRP mechanism, so the configuration stays clean and easy to inspect.

#Floating IP Behavior on Failover

When the MASTER dies, the BACKUP waits for the master_down_interval, then promotes itself and attaches the VIP. At the same time, Keepalived sends a gratuitous ARP so clients update their ARP tables with the new MAC. Without GARP, clients keep sending to the old MAC and the service appears dead even though the VIP has moved.

#Tracked Interfaces and Master vs Backup Conditions

#track_interface

A failed uplink interface should lower a node's priority automatically, so a node with a broken outbound path doesn't stay MASTER:

vrrp_instance VI_1 {
  state MASTER
  interface eth0
  virtual_router_id 51
  priority 100
  track_interface {
    eth0
    eth1
  }
}

If eth1 (the uplink) goes down, the instance priority automatically drops, and a healthy BACKUP takes over the VIP.

#Failed Interface Lowers Priority

The priority reduction per interface follows weight. The default value is -2 per interface. Keepalived only reduces priority when the node is not in the IP address owner condition. This mechanism ensures a MASTER with a broken uplink quickly hands over the VIP to a node that's genuinely healthy.

#Preemption and Failback

#Default Behavior: Preemption Active

By default, preemption is active. This means if the old MASTER node returns to health with a higher priority, it will reclaim the VIP after preempt_delay. This is called automatic failback.

#preempt_delay

Failback that's too fast can cause flapping when the service on the MASTER node has just started. Delay preemption with:

vrrp_instance VI_1 {
  state MASTER
  interface eth0
  virtual_router_id 51
  priority 100
  preempt_delay 120
  virtual_ipaddress {
    192.168.1.100/24 dev eth0
  }
}

The value preempt_delay 120 makes the returning MASTER wait 120 seconds before reclaiming the VIP. This gives the service and caches on that node time to warm up, reducing the risk of disruption.

#nopreempt

If you want a recovered node to never reclaim the VIP and stay BACKUP, enable nopreempt. This pattern is used when manual failback is preferred, and we'll dig deeper into it in episode 18.

#Verifying Behavior in the Field

After changing the configuration, check the syntax then observe:

sudo keepalived -t -f /etc/keepalived/keepalived.conf
sudo systemctl restart keepalived
sudo ip -brief addr show eth0

The keepalived -t then restart sequence is a mandatory routine every time you touch the configuration. Also verify that ip -brief addr show eth0 only shows the VIP on the node that is MASTER.

#Closing

Episode 4 completes your understanding of vrrp_instance: how state, priority, and virtual_router_id determine election, how VIPs behave during failover, how tracked interfaces lower priority, and how preemption and preempt_delay govern failback.

Key takeaways:

• virtual_router_id and VIPs must be consistent across all nodes in one instance.
• state is only the initial status; election is decided by priority and health.
• GARP ensures clients update their MAC when the VIP moves.
• track_interface lowers priority when the uplink has issues.
• Default preemption returns the VIP to the original MASTER; preempt_delay prevents flapping.
• Use nopreempt for manual or controlled failback scenarios.

In episode 5, we cover health checks and failover policies — writing vrrp_script and track_script, using notify hooks, combining multiple health check sources, and configuring nopreempt, preempt_delay, and garp_master_delay to make your failover precise.