LFCE 107 🐧 Keepalived — Installation and Config - KandZ

⏱️ Estimated read: 10 min | |

Keepalived is the userspace daemon that implements the Virtual Router Redundancy Protocol (VRRP) on Linux. Its purpose is narrow and specific: it manages one or more virtual IP addresses (VIPs) that move between a group of servers when the active node fails. The previous chapter covered the high availability concepts; this chapter covers the package installation and the configuration file that makes the failover work. The configuration is built from a global_defs block and one or more vrrp_instance blocks, and the instance block is where the state, the priority, and the virtual IP are defined.

Quick How-To Guides & Fast FixesNeed a quick fix or step-by-step solution? Browse our fast answers on HowTo.KandZ.me:

Operating Systems CLI →Dev Environment Languages →Web Network Tools →Security Accounts →Security Access Tech →Device Phone Basics →Social Messaging →Digital Files Media →

The installation is a single package-manager command on both the Debian and RHEL families, and the service is managed through systemctl. The configuration lives in /etc/keepalived/keepalived.conf. The primary node is configured with the higher priority, and the backup node with the lower priority. The virtual_router_id and the auth_pass must match on both nodes, or the election fails and the VIP never moves . The firewall must allow the VRRP traffic on the multicast address 224.0.0.18 and the protocol number 112, or both nodes become master, which is the split-brain .

Key point: The state parameter is the initial role, not the running role. The election is decided by the priority, and the node with the higher priority becomes the master. A node declared MASTER claims the VIP at startup without listening for an existing master, which causes an unnecessary VIP move on every restart. The recommended practice is to declare both nodes as BACKUP and let the priority decide the master .

Why Keepalived configuration requires the priority and the router ID

The priority problem.

VRRP elects the master by comparing the priority values. The node with the higher priority becomes the master and holds the VIP. The Oracle documentation states the rule explicitly: “Set the value of priority higher on the master server than on a backup server” . In a two-node cluster, the primary is configured with priority 200 and the backup with priority 100 . If both nodes have the same priority, the one with the higher IP address wins the election, which is unpredictable and difficult to debug .

The router-ID problem.

The virtual_router_id is a number between 1 and 255 that identifies the VRRP group. Every node in the same group must use the same ID, and no two groups on the same network segment can share an ID . The VRID selects the virtual MAC address 00:00:5e:00:01:<vrid>, so two unrelated groups using the same ID on one VLAN fight over the same MAC, and both VIPs become intermittently unreachable . The ID is the mechanism that isolates the VRRP group from the other Keepalived instances on the same link.

The authentication problem.

The VRRP advertisements carry a simple password authentication by default. The auth_type PASS and auth_pass must match on every node in the group . The password is limited to eight characters . The authentication is not a strong security measure, but it prevents the accidental cross-talk between the misconfigured groups.

a. The installation

Keepalived is packaged as keepalived on both the Debian and the RHEL families. The installation is a single command, and the service is managed through systemctl.

# Debian / Ubuntu
sudo apt install keepalived

# RHEL / Fedora / Rocky
sudo dnf install keepalived

The Debian and the RHEL packages both include the keepalived.service systemd unit. After the installation, the service can be enabled and started with systemctl enable --now keepalived. The systemctl status keepalived and the journalctl -u keepalived commands show the state and the logs.

b. The configuration file

The configuration file is /etc/keepalived/keepalived.conf. The global_defs block sets the notification and the router ID, and the vrrp_instance block defines the VIP and the election parameters.

# /etc/keepalived/keepalived.conf (primary node)
global_defs {
    notification_email {
        root@example.com
    }
    notification_email_from keepalived@example.com
    smtp_server localhost
    smtp_connect_timeout 30
    router_id node1
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 200
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 12345678
    }
    virtual_ipaddress {
        192.168.1.100/24
    }
}

The state MASTER and the priority 200 make this node the preferred master. The interface eth0 is the physical interface that carries the VRRP advertisements and the VIP. The virtual_router_id 51 identifies the VRRP group, and the advert_int 1 sets the advertisement interval to one second . The virtual_ipaddress block defines the VIP that the master holds.

The backup node uses the same configuration with three differences: the state BACKUP, the lower priority, and the different router_id.

# /etc/keepalived/keepalived.conf (backup node)
global_defs {
    router_id node2
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 12345678
    }
    virtual_ipaddress {
        192.168.1.100/24
    }
}

The virtual_router_id and the auth_pass must match the primary node exactly. The priority 100 is lower than the primary’s 200, so the backup stays in the backup state while the primary is alive .

c. The failover verification and the firewall

The failover is verified by stopping the Keepalived service on the primary and checking that the VIP moves to the backup.

# On the primary: stop keepalived
sudo systemctl stop keepalived

# On the backup: check that the VIP is assigned
ip addr show eth0 | grep 192.168.1.100

When the primary stops, the backup no longer receives the VRRP advertisements, the master-down timer expires, and the backup transitions to the master state and assigns the VIP to its interface . The Oracle documentation states the rule: “If the backup nodes fail to receive three consecutive VRRP advertisements, the backup server with the highest assigned priority takes over as the primary server” . The ip addr show command on the backup confirms the VIP is present.

The VRRP advertisements use the multicast address 224.0.0.18 on the protocol number 112. A firewall that blocks the multicast or the protocol 112 prevents the election, and both nodes remain in the master state, which is the split-brain . The firewall must allow the VRRP traffic on the interface that carries the advertisements.

Complete Example Session

# ============================================
# PART 1: INSTALL KEEPALIVED
# ============================================
sudo apt install keepalived

# ============================================
# PART 2: CREATE THE PRIMARY CONFIG
# ============================================
sudo tee /etc/keepalived/keepalived.conf > /dev/null <<'EOF'
global_defs {
    router_id node1
}
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 200
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 12345678
    }
    virtual_ipaddress {
        192.168.1.100/24
    }
}
EOF

# ============================================
# PART 3: START THE SERVICE
# ============================================
sudo systemctl enable --now keepalived
sudo systemctl status keepalived

# ============================================
# PART 4: VERIFY THE VIP ON THE PRIMARY
# ============================================
ip addr show eth0 | grep 192.168.1.100

# ============================================
# PART 5: CONFIGURE THE BACKUP NODE
# ============================================
# On the backup node, use the same config with:
# state BACKUP, priority 100, router_id node2

# ============================================
# PART 6: TEST THE FAILOVER
# ============================================
# On the primary:
sudo systemctl stop keepalived
# On the backup:
ip addr show eth0 | grep 192.168.1.100

# ============================================
# PART 7: RESTORE THE PRIMARY
# ============================================
sudo systemctl start keepalived
# The primary takes the VIP back if preempt is enabled (default)

The seven parts demonstrate the complete configuration: the installation, the primary config, the service start, the VIP verification, the backup config, the failover test, and the primary restore.

Quick Reference

Installation

Distribution	Command
Debian / Ubuntu	`apt install keepalived`
RHEL / Rocky	`dnf install keepalived`
Service	`systemctl enable --now keepalived`

The vrrp_instance Parameters

Parameter	Purpose	Example
`state`	The initial role	`MASTER` or `BACKUP`
`interface`	The physical interface	`eth0`
`virtual_router_id`	The VRRP group ID	`51`
`priority`	The election weight	`200` (primary), `100` (backup)
`advert_int`	The advertisement interval	`1` (second)
`auth_type` / `auth_pass`	The group authentication	`PASS` / `12345678`
`virtual_ipaddress`	The VIP to manage	`192.168.1.100/24`

The Verification

Command	Purpose
`ip addr show <if>`	Check the VIP presence
`journalctl -u keepalived`	Check the state transitions
`systemctl stop keepalived`	Trigger the failover

Best Practices

✅ Do This:

# Use the explicit priority difference
priority 200    # primary
priority 100    # backup                                      # ✅

# Use the same virtual_router_id on all nodes
virtual_router_id 51                                          # ✅

# Allow the VRRP multicast through the firewall
# Protocol 112, multicast 224.0.0.18                          # ✅

# Verify the failover after the configuration
systemctl stop keepalived                                     # ✅

# Use the router_id for the logs
router_id node1                                               # ✅

❌ Don’t Do This:

# Use the same priority on both nodes
priority 100    # Both nodes → ambiguous election              # ❌

# Use different virtual_router_id values
virtual_router_id 51    # Primary
virtual_router_id 52    # Backup → different groups            # ❌

# Block the VRRP multicast
# The election fails → both nodes stay master                  # ❌

# Forget the auth_pass match
auth_pass 12345678    # Must be identical                      # ❌

# Assume the VIP moves instantly
# The failover takes the advert interval × 3                    # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Both nodes are master	The VRRP multicast is blocked	Allow the protocol 112 and the `224.0.0.18`
The VIP does not move	The `virtual_router_id` differs	Use the same ID on all nodes
The backup does not take over	The priority is the same or higher	Set the lower priority on the backup
The VIP is on both nodes	The split-brain	Check the firewall and the advertisement reachability

Real-World Examples

1. Install Keepalived

sudo apt install keepalived

2. Primary config

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 200
    virtual_ipaddress { 192.168.1.100/24 }
}

3. Backup config

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    virtual_ipaddress { 192.168.1.100/24 }
}

4. Start the service

systemctl enable --now keepalived

5. Check the VIP

ip addr show eth0 | grep 192.168.1.100

6. Test the failover

systemctl stop keepalived

7. Check the logs

journalctl -u keepalived

8. The firewall rule

iptables -A INPUT -p vrrp -j ACCEPT

9. The router ID

router_id node1

10. The authentication

auth_type PASS
auth_pass 12345678

Visual

The VRRP Election

┌──────────────────────────────────────────────────────────────┐
│  THE HIGHER PRIORITY BECOMES THE MASTER                      │
│                                                              │
│  Primary (priority 200)                                      │
│  └── Holds the VIP 192.168.1.100                             │
│  └── Sends the VRRP advertisements every 1s                  │
│                                                              │
│  Backup (priority 100)                                       │
│  └── Listens for the advertisements                          │
│  └── If the advertisements stop for 3× advert_int → master   │
│                                                              │
│  The election is deterministic because of the priority.      │
└──────────────────────────────────────────────────────────────┘

The Failover

┌──────────────────────────────────────────────────────────────┐
│  THE VIP MOVES WHEN THE MASTER STOPS                         │
│                                                              │
│  Before:                                                     │
│  ├── Primary: 192.168.1.100 (VIP)                            │
│  └── Backup: no VIP                                          │
│                                                              │
│  Primary stops                                               │
│       │                                                      │
│       ▼                                                      │
│  Backup waits 3 × advert_int                                 │
│       │                                                      │
│       ▼                                                      │
│  Backup becomes master                                       │
│       │                                                      │
│       ▼                                                      │
│  Backup assigns the VIP to its interface                     │
└──────────────────────────────────────────────────────────────┘

The Configuration Match

┌──────────────────────────────────────────────────────────────┐
│  THE TWO NODES MUST MATCH ON THE GROUP PARAMETERS            │
│                                                              │
│  Same:                                                       │
│  ├── virtual_router_id 51                                    │
│  ├── auth_pass 12345678                                      │
│  └── virtual_ipaddress 192.168.1.100/24                      │
│                                                              │
│  Different:                                                  │
│  ├── state (MASTER vs BACKUP)                                │
│  ├── priority (200 vs 100)                                   │
│  └── router_id (node1 vs node2)                              │
└──────────────────────────────────────────────────────────────┘

Summary

Item	Value
Package	`keepalived`
Config file	`/etc/keepalived/keepalived.conf`
Primary state	`MASTER`
Backup state	`BACKUP`
Primary priority	Higher (e.g., 200)
Backup priority	Lower (e.g., 100)
Router ID	Same group ID on all nodes
Authentication	`PASS` + the matching password
VIP	`virtual_ipaddress` block
Firewall	Allow the protocol 112 and the `224.0.0.18`

Key takeaways:

Keepalived is installed from the distribution repositories. The apt install keepalived on the Debian family and the dnf install keepalived on the RHEL family are the installation commands, and the service is managed through systemctl .
The priority difference is the election mechanism. The primary has the higher priority (e.g., 200) and the backup has the lower (e.g., 100). If the priorities are equal, the election is decided by the IP address, which is unpredictable .
The virtual_router_id must match on all nodes. It identifies the VRRP group, and a mismatch puts the nodes in different groups, so the VIP never moves between them .
The auth_pass must match on all nodes. The authentication is a simple password that prevents the cross-talk between the misconfigured groups. The password is limited to eight characters .
The failover takes three advertisement intervals. When the master stops sending the advertisements, the backup waits three intervals before it transitions to the master state and assigns the VIP .
The firewall must allow the VRRP traffic. The protocol is 112 and the multicast address is 224.0.0.18. A firewall that blocks the traffic causes the split-brain, where both nodes believe they are the master .

Remember: Keepalived is the VRRP implementation that manages the floating VIP. The configuration is the vrrp_instance block with the state, the priority, the router ID, and the VIP. The primary has the higher priority and the backup has the lower. The router ID and the password must match. The failover moves the VIP when the master stops, and the firewall must allow the VRRP traffic. The result is the service that survives the failure of the active node without the client noticing the change.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!