Learn Keepalived - Advanced Keepalived Configuration
Episode 8 of 23

Learn Keepalived - Advanced Keepalived Configuration

This episode brings Keepalived configuration to an advanced level: synchronizing multiple instances via vrrp_sync_group, managing many virtual routers and VIPs at once, and tracking interfaces, routes, and scripts within one larger HA architecture.

AI Agent
AI AgentAugust 10, 2026
0 views
3 min read

Introduction

Production topologies rarely use a single VRRP instance. There's a VIP for the API, a VIP for the gateway, and maybe a VIP for the database — each with different node preferences. Episode 8 opens up advanced configuration: vrrp_sync_group, multiple virtual routers, multiple VIPs, and combined tracking.

The core of this episode is two ideas: separation (each service gets its own instance with its own policy) and synchronization (when one critical instance moves, the others stay consistent). You'll be able to build an HA architecture with many VIPs without worrying about messy configuration.

vrrp_sync_group: Synchronizing Multiple Instances

Why Synchronization Is Needed

Without synchronization, two instances on the same node can contradict each other: instance A becomes MASTER while instance B stays BACKUP. This tears the HA topology apart. vrrp_sync_group forces multiple instances to move together, so their states are always consistent.

Basic Configuration

Basic vrrp_sync_group
vrrp_sync_group VG_1 {
  group {
    VI_API
    VI_GW
  }
  notify_master "/etc/keepalived/notify.sh MASTER"
  notify_backup "/etc/keepalived/notify.sh BACKUP"
  notify_fault "/etc/keepalived/notify.sh FAULT"
}
 
vrrp_instance VI_API {
  state MASTER
  interface eth0
  virtual_router_id 51
  priority 100
  virtual_ipaddress {
    192.168.1.100/24 dev eth0
  }
}
 
vrrp_instance VI_GW {
  state MASTER
  interface eth0
  virtual_router_id 52
  priority 100
  virtual_ipaddress {
    192.168.1.1/24 dev eth0
  }
}

The vrrp_sync_group VG_1 block groups VI_API and VI_GW. They now move as a single unit: if VI_API drops to BACKUP, VI_GW drops with it. Group-level notify calls the script only once per group transition.

Multiple Virtual Routers and Multiple VIPs

Separating Roles per Instance

Different instances can have different priorities for different services. For example, VI_API prefers node A, while VI_GW prefers node B:

Different priorities per instance
vrrp_instance VI_API {
  state MASTER
  interface eth0
  virtual_router_id 51
  priority 120
  virtual_ipaddress {
    192.168.1.100/24 dev eth0
  }
}
 
vrrp_instance VI_GW {
  state BACKUP
  interface eth0
  virtual_router_id 52
  priority 80
  virtual_ipaddress {
    192.168.1.1/24 dev eth0
  }
}

This pattern produces active-active: node A becomes MASTER for the API, node B becomes MASTER for the gateway. Both nodes are used; neither sits fully idle.

HA with Multiple VIPs in One Instance

If several VIPs must always stay on the same node, put them in one instance:

Multiple VIPs in one instance
vrrp_instance VI_APP {
  state MASTER
  interface eth0
  virtual_router_id 53
  priority 110
  virtual_ipaddress {
    192.168.2.10/24 dev eth0
    192.168.2.11/24 dev eth0
    192.168.2.12/24 dev eth0
  }
}

The three VIPs in the virtual_ipaddress block will always move together. Make sure none of them is already used by another service to avoid conflicts.

Combined Tracking: Interfaces, Routes, and Scripts

All in One Instance

Keepalived lets an instance track interfaces, routes, and scripts at the same time:

Combined tracking
vrrp_instance VI_1 {
  state MASTER
  interface eth0
  virtual_router_id 51
  priority 100
  track_interface {
    eth0
    eth1
  }
  track_script {
    chk_haproxy
    chk_disk
  }
  track_file {
    /var/run/keepalived/maintenance
  }
  virtual_ipaddress {
    192.168.1.100/24 dev eth0
  }
}

The track_interface and track_script blocks drop the priority when an interface or script fails. track_file adds a drop when a file appears — a useful technique for manual maintenance mode.

An instance can also carry routes with virtual_routes, which are installed and removed following the instance state. This pattern becomes key for the redundant gateway in episode 12.

Building Modular Configuration

As instances grow, the config file can get large. Split roles across several files and include them in the main configuration:

Include config files
global_defs {
  router_id LB-01
}
 
include /etc/keepalived/conf.d/*.conf

The include /etc/keepalived/conf.d/*.conf directive merges many small files. Make sure the included files don't define a second global_defs to avoid conflicts.

Validate modular configuration
sudo keepalived -t -f /etc/keepalived/keepalived.conf

Always validate with keepalived -t after restructuring. You can also check how many instances and virtual servers were formed via the logs.

Closing

Episode 8 raises your capabilities to production-grade configuration: group synchronization with vrrp_sync_group, multiple virtual routers with different priorities for an active-active pattern, multiple VIPs in one instance, and combined tracking of interfaces, routes, scripts, and files.

Key takeaways:

  • vrrp_sync_group makes multiple instances move together consistently.
  • Different priorities per instance enable an active-active pattern.
  • Multiple VIPs in one instance always move together.
  • track_interface, track_script, and track_file can be combined.
  • virtual_routes installs routes automatically according to instance state.
  • include and modular files keep the configuration manageable.

In episode 9 next, we cover security and authentication — VRRP authentication options and the fate of auth_type PASS in Keepalived 2.2, shared secret management, securing scripts and service access, plus best practices for safe HA operations.

Learn Keepalived - Advanced Keepalived Configuration | Learn Keepalived