How a HAVIP Works
A HAVIP has two parts: the virtual IP itself, and the holder — the one instance that currently owns the address. This chapter describes how those relate and what happens during a failover.
A Subnet-Scoped Virtual IP
A HAVIP is a virtual IP valid across its whole subnet — any instance in the subnet may claim it. At any moment at most one instance is the holder: it owns the VIP on its vNIC and receives all traffic addressed to the HAVIP; the rest stand by.
Which instances participate, and which one holds the VIP, is decided by your failover software — keepalived speaking VRRP, LVS, or kube-vip — not by the platform. ZEC runs no election; the holder it reports is an observation of which instance currently owns the address.
How the Network Follows the Holder
The virtual IP is a single address, but over its lifetime it is served by different vNICs — and therefore different MAC addresses — as the holder changes. For traffic to reach the right place, the VPC network has to know which vNIC owns the HAVIP at this moment.
It learns that from the holder itself:
When an instance takes the VIP, its failover software claims the address on the local vNIC and announces the new ownership on the subnet (a gratuitous ARP, in keepalived's case).
The ZEC network sees that announcement and updates its forwarding so that the HAVIP now resolves to the new holder's vNIC.
From that point, every packet sent to the HAVIP — by any instance in the VPC, or by an EIP bound to it — is delivered to the new holder.
You do not configure step 2. It is automatic, and it is what makes the HAVIP a virtual IP rather than just a spare address: the address is decoupled from the MAC that currently serves it, and the network re-binds the two whenever the holder changes. The subnet's broadcast/multicast support is what carries the announcement.
A Failover, Step by Step
Consider a HAVIP 10.0.1.50 in a subnet, with two instances configured for it in keepalived — vm-A (holder) and vm-B (standby):
1. Steady state
vm-A holds 10.0.1.50. Clients connect to 10.0.1.50 and are served by vm-A. vm-B runs the same service but receives nothing.
2. Holder fails
vm-A crashes, loses power, or its service dies. It stops sending VRRP heartbeats.
3. Standby detects it
vm-B's failover software misses the heartbeats, declares vm-A dead, and promotes itself.
4. Standby claims the IP
vm-B claims 10.0.1.50 on its vNIC and announces the new ownership on the subnet.
5. Network re-points
The ZEC network sees the announcement and re-binds 10.0.1.50 to vm-B's vNIC.
6. New steady state
Traffic to 10.0.1.50 now reaches vm-B. Clients kept the same address throughout.
When vm-A recovers, what happens next depends entirely on your keepalived configuration — it may reclaim the holder role (if configured with a higher priority and preemption) or stay a standby. ZEC simply reports whichever instance currently owns the address.
!!! note "Failover speed is set by your software, not by ZEC" How fast step 3 happens — and therefore how long the outage lasts — is governed by your VRRP advertisement interval and dead-timer, not by the platform. The network's re-point in step 5 follows the announcement within the subnet promptly. Tune the guest-side timers to the failover speed your service needs.
Why a HAVIP Lives in One Broadcast Domain
A HAVIP works because it sits inside a single layer-2 broadcast domain. That broadcast domain is the core of the mechanism: it carries the VRRP advertisements and gratuitous ARP the failover software depends on, and it is what lets a new holder's announcement reach every host so the network re-points the VIP.
A subnet is the visible form of that broadcast domain. So the rule "a HAVIP and every instance that can hold it share one subnet" is really "they share one broadcast domain" — an instance in another subnet sits in another broadcast domain, has no layer-2 path to claim the VIP, and the address cannot move to follow it.
What's Next
EIP to HAVIP — front the HAVIP with an EIP for internet-facing services.
Use Cases — the failover patterns this model is built for.
Last updated