Build1 publisher3 min readPublished
VRRP hands the load balancer's IP to a standby in about three seconds
A dev.to walkthrough of RFC 5798 shows two balancers sharing one virtual IP, electing an owner by priority and heartbeating once a second. The adoption cost includes a firewall rule that names IP protocol 112.
The Engineer · Build desk

What happened
- A dev.to walkthrough argues that fronting three API servers with a single load balancer does not remove the single point of failure, it moves it to the balancer, where healthy backends become unreachable.
- VRRP, defined in RFC 5798, lets several machines agree on who currently owns a virtual IP and elect a replacement when that owner disappears.
- Backups declare the master gone after roughly three intervals of silence, then elect a new owner by priority, with typical failover in the 1 to 3 second range.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- capability Recovery time stops depending on client-side caches. The address moves to another machine while clients keep dialling the same one, so no resolver, browser or operating system has to be persuaded to forget anything.
- constraint Firewall policy written the usual way cannot admit the heartbeat, since protocol 112 has no port number. The rule has to be expressed in a form many cloud security group interfaces make awkward.
- decision Choosing direct server return for speed pushes the failover design down into every backend host, because each one must accept traffic addressed to the VIP before the path works at all.
- cost The second balancer is paid for and carries no traffic until an election happens. A backup is silent by design, so proving it is ready needs a separate check.
Two nodes get the same virtual IP and the same group ID, the VRID, and each gets a priority number [8]. The highest priority becomes master and is the only node that claims the address, while every backup stays completely silent [9]. The master multicasts small advertisement packets to 224.0.0.18, by default once per second [10]. Backups listen for those packets, and when roughly three intervals pass in silence they hold an election by priority and the winner claims the VIP [12].
Three intervals at the default one-second advertisement is three seconds of detection [1]. That is the slow end of the 1 to 3 second failover the dev.to write-up describes as typical [12].
The protocol number is what bites during deployment. VRRP runs directly over IP as protocol 112, not TCP and not UDP, so there is no port to open [11]. A security group or host firewall written in terms of ports will never admit an advertisement; the rule has to permit the protocol itself [11].
Repointing DNS does not buy you the same behaviour. TTLs are cached by resolvers, by operating systems and by browsers, and some of them ignore the TTL entirely. The article puts DNS failover at minutes of downtime at best, with a long tail of clients still hammering the dead address [2]. A virtual IP is an address no machine owns permanently: clients connect to it, DNS points at it, firewall rules reference it, and it can move between servers with nothing changing on the client side [3]. In the article's example, api.example.com resolves to 203.0.113.10 on load balancer 1 while load balancer 2 sits at 203.0.113.11 with no traffic at all [14].
What the floating address costs you depends on how packets reach the backends. In proxy mode, which the article lists as ALB, nginx and HAProxy, the balancer terminates the client connection and opens a separate one to the backend, so the backend sees the balancer's IP as the source. That is why X-Forwarded-For exists [4]. With NAT or direct server return, as in LVS and classic L4 balancers, the balancer rewrites the destination and forwards the packet, and the backend replies straight to the client [5]. That path is faster, and it requires every backend to be configured to accept traffic addressed to the VIP [5].
Priority runs from 1 to 254, the default is 100, and 255 is reserved for a node that holds the address as a real interface address. The article's suggestion is 100 for the intended master and 90 for the standby [13]. Two machines answering for one address would be a disaster, so silence is the backup's default state [9]. A healthy backup emits nothing, so the only way to know it is ready is to check it directly.
RFC 5798 defines the protocol, and the article notes it was written for redundant routers before being used for load balancers, firewalls, database proxies and NFS heads [6][7]. The supplied text breaks off mid-sentence as it introduces preempt, the setting that governs what happens when a failed master returns [15].
What to watch
- Measured failover times from a named production pair, against the 1 to 3 second range the article states.
- Guidance for networks that do not forward multicast to 224.0.0.18, where the once-per-second advertisement cannot reach backups.
- What the article's truncated preempt section specifies about a recovered master reclaiming the VIP from a working standby.