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.

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.
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.
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.
Different instances can have different priorities for different services. For example, VI_API prefers node A, while VI_GW prefers node B:
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.
If several VIPs must always stay on the same node, put them 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.
Keepalived lets an instance track interfaces, routes, and scripts at the same time:
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.
As instances grow, the config file can get large. Split roles across several files and include them in the main configuration:
global_defs {
router_id LB-01
}
include /etc/keepalived/conf.d/*.confThe 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.
sudo keepalived -t -f /etc/keepalived/keepalived.confAlways validate with keepalived -t after restructuring. You can also check how many instances and virtual servers were formed via the logs.
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.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.