> For the complete documentation index, see [llms.txt](https://docs.console.zenlayer.com/welcome/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.console.zenlayer.com/welcome/elastic-compute/01-overview/02-how-it-works.md). # 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](https://www.keepalived.org/) speaking [VRRP](https://en.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol), 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: 1. 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). 2. The ZEC network sees that announcement and updates its forwarding so that the HAVIP now resolves to the new holder's vNIC. 3. From that point, every packet sent to the HAVIP — by any instance in the VPC, or by an [EIP](/welcome/elastic-compute/01-overview/03-eip.md) 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 ![Before and after a failover: the virtual IP moves from the failed holder to a standby](/files/dmVeJs6ZnfvDDU6lheXl) 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): | Step | What happens | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | **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**](/welcome/elastic-compute/01-overview/03-eip.md) — front the HAVIP with an EIP for internet-facing services. * [**Use Cases**](/welcome/elastic-compute/01-overview/04-use-cases.md) — the failover patterns this model is built for. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.console.zenlayer.com/welcome/elastic-compute/01-overview/02-how-it-works.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.