Learn Keepalived - Performance Tuning & Latency Reduction
Episode 15 of 23

Learn Keepalived - Performance Tuning & Latency Reduction

This episode optimizes Keepalived timing: tuning advert_int and learning the VRRPv3 centisecond unit, understanding skew time and master down interval, and adjusting the daemon for large-scale HA with low-latency failover.

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

Introduction

In an HA topology, time is everything. The faster a new node takes over the VIP, the smaller the disruption window for clients. Episode 15 opens the performance tuning toolbox: tuning advert_int, understanding the VRRP timing formulas, and adjusting the daemon so failover feels almost seamless.

But speed isn't the only goal. Too-aggressive failover can trigger flapping and even bigger disruption. You'll learn to find the balance between failover latency and stability, and which parameters are safe to change in a production environment.

Tuning the Advert Interval

advert_int is the interval at which the MASTER sends advertisements, 1 second by default. The smaller the interval, the faster a BACKUP detects a dead MASTER, because the BACKUP waits roughly three times the interval before deciding the MASTER is gone.

The Centisecond Unit in VRRPv3

Modern Keepalived accepts the centisecond unit with the cs suffix:

advert_int in centiseconds
vrrp_instance VI_1 {
  state MASTER
  interface eth0
  virtual_router_id 51
  priority 100
  advert_int 100cs
  virtual_ipaddress {
    192.168.1.100/24 dev eth0
  }
}

The value advert_int 100cs equals 1 second. For faster failover, you can lower it to 50cs or 20cs on VRRPv3, but remember that every advertisement is a network packet that must be sent periodically to all nodes.

Interval Trade-offs

A small interval means faster detection but more network load and sensitivity to packet loss. A single lost advertisement is no big deal at a 1-second interval, but can trigger a false failover at very small intervals. Start with 100cs and lower it gradually while monitoring stability.

Understanding Skew Time and Master Down Interval

The Timing Formulas

As discussed in episode 2, these two formulas determine takeover speed:

VRRP takeover timing
skew_time = (256 - priority) / 256 detik
master_down_interval = (3 * advert_int) + skew_time

skew_time makes higher-priority nodes wait shorter, so the node that deserves to be MASTER wins the competition. master_down_interval is the window before a BACKUP takes over.

Calculating with an Example

With an advert_int of 100cs and priority 90, skew time is about 0.65 seconds and master down interval about 3.65 seconds. Lower advert_int to 50cs, and master down interval shrinks to about 2.15 seconds. This simple calculation helps you estimate your failover SLO target before changing any configuration.

Tuning GARP for Fast Takeover

When the new MASTER takes over, fast GARP makes clients and switches redirect traffic immediately:

Responsive GARP
vrrp_instance VI_1 {
  state MASTER
  interface eth0
  virtual_router_id 51
  priority 100
  advert_int 100cs
  garp_master_delay 1
  garp_master_repeat 3
  virtual_ipaddress {
    192.168.1.100/24 dev eth0
  }
}

garp_master_delay 1 sends GARP 1 second after becoming MASTER, and garp_master_repeat 3 sends it three times. This balances speed with the tolerance of switches that may be a little slow to absorb GARP.

Tuning the Daemon for Large Scale

Many Instances in One Daemon

A single Keepalived daemon can handle hundreds of VRRP instances. For large scale, pay attention to:

  • A reasonable advert_int, for example 100cs to 1 second, to limit packet volume.
  • vrrp_sync_group so related instances don't move erratically.
  • Health check load: limit the script interval and the number of heavy scripts.

Monitoring the Impact in the Logs

After tuning, monitor the daemon from the logs:

Monitor after tuning
sudo journalctl -u keepalived -f

Watch for MASTER and BACKUP transition patterns in journalctl -u keepalived. Flapping that appears after shrinking the interval is a signal to return to more conservative values.

Testing Low-Latency Failover

Failover latency can only be claimed once it's measured. Build a measurable procedure:

Measure failover time
date +%s.%N > /tmp/failover-start
sudo systemctl stop keepalived
while ! ping -c 1 -W 1 192.168.1.100 > /dev/null; do sleep 0.2; done
date +%s.%N > /tmp/failover-end
awk '{print "failover:", $1}' /tmp/failover-start

The sequence systemctl stop keepalived then waiting for the VIP to come back measures the actual disruption window. Record the results at every tuning change so decisions are based on data, not feelings.

Closing

Episode 15 makes your failover fast yet stable: advert_int in centiseconds, an understanding of skew time and master down interval, responsive GARP, and measurable latency testing. Your HA is now not just reliable, but agile.

Key takeaways:

  • advert_int determines how fast a dead MASTER is detected.
  • 50cs or 20cs speeds up failover but adds sensitivity.
  • master_down_interval is roughly three times advert_int plus skew time.
  • Fast GARP speeds up traffic redirection on clients and switches.
  • Intervals that are too small can trigger flapping.
  • Measure failover latency after every tuning change.

In episode 16 next, we cover health check advanced patterns — health checks for external services, HTTP and custom scripts, tiered failure detection with rise and fall, and integration of restarts and alerting with monitoring.

Learn Keepalived - Performance Tuning & Latency Reduction | Learn Keepalived