Floating IP setup: where the network loses availability
As long as the address is pinned to a specific node, the entire availability of the service rests on that one node.
This is a classic single point of failure: if the hardware, hypervisor, or network interface fails, the service disappears entirely, even though a second node is present in the design and sitting idle.
At that moment, the client does not even receive a clear error: requests time out, and externally it looks like “the site is down.”
The most costly part is dropped connections.
You cannot simply move the address to another node: already established sessions are tied to the previous one, and everything that was in flight at the moment of failure — file uploads, long transactions, data streams — breaks with no way to send the remainder.
If switching is done only via DNS, the resolver cache TTL adds more: some clients keep hitting the dead machine for minutes, while others hit the new one, and the picture becomes inconsistent.
Floating IP setup removes the problem because the address no longer belongs to a specific machine.
Keepalived keeps the virtual address on the primary node, monitors service health, and if the node fails, moves the address to the backup — without editing DNS and without waiting for caches.
The details that determine the outcome: the check must look at the service itself, not at interface responsiveness; the backup node must correctly announce the address on the network, otherwise traffic goes nowhere; if the network is split, two primary nodes can exist at the same time, so a quorum or external arbiter is needed.
Next, we look at how this is handled in practice.
What fault-tolerant service addressing provides
A portable address eliminates the most expensive type of downtime — the kind that lasts while an engineer manually rewrites records and waits for changes to propagate across all nodes.
Failure is detected by health checks, and the address moves to the backup node in seconds, not minutes. For external clients, this looks like isolated failed requests instead of an outage window.
The share of retained connections depends on where the service state lives. If sessions are stored on the node itself, some long-lived connections will break during failover — the client will reconnect, but the progress of the operation may be lost.
When state is moved to a separate layer and nodes remain interchangeable, the node change is seamless: short requests do not notice it at all.
The main effect is that an entire class of failures associated with manual address failover disappears. A mistake in a record, forgotten configuration on the backup node, different update times on different servers — all of this stops being a source of incidents.
The address is managed by automation according to a single set of rules, not by an on-call engineer from memory and in a hurry.
Switching speed becomes predictable and the same for an incident and for planned maintenance. Updating, replacing a node, editing configuration — traffic is moved to the backup, work proceeds without a downtime window, then the address returns.
This makes it possible to schedule maintenance during business hours, rather than at night, when staffing is thinnest.
The effect is verified with numbers: service downtime, the share of successful requests at the moment of switching, and the number of manual operations by the on-call engineer.
The first two metrics are compared before and after — this confirms that the addressing is truly fault-tolerant, and not just configured.
Address fault-tolerance modes: comparison of schemes
The choice of scheme is determined not by ease of configuration, but by what happens to incoming traffic at the moment of failure: whether established sessions are preserved, how many seconds it takes routing to converge, and how many addresses must be announced. Below are the options that are actually chosen between, with their limitations.
| Scheme | When it is suitable | Scheme limitations |
|---|---|---|
| Active-passive with address failover (VRRP, keepalived) | One node carries the load, the second is in hot standby; minimal infrastructure changes are needed | The backup node sits idle; a short gap during re-elections; protection against state split-brain between nodes is mandatory |
| Active-active with a shared address | Multiple sites, latency sensitivity, requirement for seamless failover | More complex announcement configuration and debugging of asymmetric routes; a configuration error affects all sites at once |
| Cloud-provided floating address (switching via API) | Service in one region, switching by monitoring signal | Dependence on the cloud API; automation is assembled manually; switching takes tens of seconds |
| Switching at the DNS level | Backup sites where fast failover is not critical | Delay due to resolver cache; established connections are not saved |
The key metric is the same for all schemes: how many seconds incoming traffic goes nowhere and how many sessions break during that time.
With active-passive, the address moves in seconds, but the bottleneck is failure detection time; with active-active, the failure is almost invisible, but the cost of a configuration error grows.
Therefore, before choosing, we record the load profile: the share of long-lived connections, acceptable downtime, and geographic requirements. Then we select a scheme and test it by failure on a test bench, not on paper.
Stages of implementing fault-tolerant addressing
A virtual address is the single entry point for all traffic, and an error in it takes down the entire service, not just a single node.
Therefore, we work in a fixed order: first we record the current state of the network, then we design address roles, and only then do we touch the switching rules. This way, an address conflict surfaces at the design stage, not during an incident.
- Network audit. We build a map of segments, gateways, and routes, look at where addresses are assigned statically and where automatically, and search for subnet overlaps. The output is a list of free addresses and those already assigned to equipment.
- Addressing scheme. We define roles: which address serves the application, which remains for service purposes, which is kept as backup, and who owns each. The scheme removes the main risk — dual ownership of an address, when both nodes consider themselves active.
- Failover configuration. We set health checks, node priorities, and the time it takes for the address to move. We separately specify behavior during a partial failure — the node responds, but the application on it no longer does.
- Testing under load. We run not only node shutdown, but also link failure, loss of connectivity between nodes, and a planned restart. We look at how long the address move takes and whether live connections break during it.
- Handover to operations. We provide the address scheme, configurations, manual switching procedure, and rules for returning the address to the primary node. The on-call shift receives not a “black box,” but a clear procedure.
The order is the same for a cloud site and your own hardware — only where the address physically lives changes. Before putting it into operation, we run the failure scenarios again, already on the production environment.
Addressing and configuration policies in the infrastructure
Fault tolerance rests not on the mere presence of a second address, but on whether its configuration is reproducible. We document each element so that failover does not depend on which engineer is on call at that moment. The package goes into your repository and remains functional when new nodes and zones are added.
- Address configurations: binding Floating IP to interfaces, node priorities, health check intervals, and behavior when a node comes back online — with an explanation of which parameters are changed during scaling.
- Traffic flow diagram: the path of external traffic to application servers, failure points, the moment at which the virtual address moves to the backup node, and how established connections behave.
- Access rules: network policies, allowed sources for service traffic, the procedure for granting permissions to the on-call engineer, and prohibition of manual edits bypassing the repository.
- Verification procedure: a planned failover scenario with expected time, a set of confirmation commands, and the criterion by which the on-call engineer considers traffic switching successful.
- Recovery procedure: actions for address split-brain between two nodes, the procedure for returning traffic to the original zone, and the boundaries beyond which our team gets involved.
- Documentation: service passport with owners, addressing change history, node placement diagram, and dependencies on external networks.
The package is reviewed during scheduled drills: if failover does not fit within the agreed time, we fix the configuration, not the instruction.
Address failover between nodes: results before and after
A service on two nodes behind a load balancer: before configuring a floating address, the failure of any machine meant manual intervention.
The address remained on the unavailable node, client requests ended with errors, the on-call engineer changed the DNS record and waited for resolver caches to update. The failure was more often learned about from users than from monitoring.
How it was before implementation
Access recovery time was 9–14 minutes per incident: about a minute for the actual failover and the rest waiting for caches. Active connections were completely lost during a failure, and long sessions had to be started over.
Failure testing was rarely performed, so the real failover scenario remained untested until the first serious outage.
What changed after
The floating address was pinned to a pair of nodes and linked to application-state checking via keepalived: as long as the node responds to a health check, the address stays on it, and the connection table is synchronized between machines.
On failure, the address moves to the backup node in 3–5 seconds, retained connections survive the switch, and the share of failed requests at that moment is below 0.5%.
Failure testing was made regular: a node is shut down during business hours, failover time and request loss are recorded, then it is returned to service.
Downtime for the quarter decreased from hours to single-digit seconds, manual actions by the on-call engineer disappeared from the scenario — what remained was reviewing the report after the drills.
How does Floating IP differ from Virtual IP?
Floating IP and Virtual IP solve the same task — giving a service an address that survives node failure — but their nature is different.
Floating IP belongs to the platform or provider: it does not “stick” to a machine, but is bound to a network interface by command, and during failover external routing directs traffic to the new node.
Virtual IP lives inside your infrastructure: the same address is brought up on several nodes, and a selected leader keeps it active — in practice this is Keepalived or a similar daemon that brings the address up on an interface and announces it on the network.
This is where the use cases diverge. Floating IP is used where a public entry point is needed: an external load balancer, a reverse proxy, an administration node — the address is rebound to a backup instance, and clients do not notice the change.
Virtual IP is used internally: a fault-tolerant gateway, a pair of database servers, an application cluster where a single address for a group of nodes and failover in seconds matter.
Network requirements also differ. Floating IP relies on the platform’s ability to redirect traffic to another node, so subnet boundaries, correct routing, and the absence of hard bindings to the address on the firewall side are critical.
Virtual IP requires the nodes to be neighbors in the same broadcast domain: permitted exchange of leader-election service packets, unrestricted ARP transmission, and the ability of a node to respond to an address that is not its own.
In cloud networks, these conditions are not always met — then Floating IP or a managed load balancer remains.
At the design stage, we check three things: where the physical point of failure is — at the provider or in the cluster; who holds the address at the moment of an incident and how long failover takes; and how session state behaves after a node change.
Very often a combination is chosen: Virtual IP inside for fast failover, Floating IP or a load balancer outside for public access. Next, we look at how this is assembled for a specific scheme.
Technical questions on configuration and operations
Engineering doubts during implementation are almost always the same: how established connections will behave, whether a second node is needed, and how to verify failover without waiting for a real incident. Below are brief answers to each.
What happens to active connections during failover?
The address moves in seconds, but open sessions on the old node do not continue — the connection table is not synchronized between nodes.
That is why critical services are designed with short timeouts and retryable requests, and long transactions are moved to the application layer.
Can you do without a second node?
A floating address by itself does not increase availability: if there is no backup node, there is nowhere to switch it to. The second node can be weaker — in standby mode it only holds the address and polls the service with a liveness check.
How to test failover under load?
Run with a production traffic profile: hold connections, shut down the active node, and measure the pause and the share of failed requests.
Separately, check that the address appeared on the network exactly once and that two owners did not arise at the same time — cluster split-brain is more dangerous than a short outage.
Who manages the address during operations?
We keep the binding in the infrastructure description, not in the provider panel: then the address moves reproducibly when a node is recreated, and the change of owner does not depend on manual actions by the on-call engineer.
Let’s discuss the task and come back with an estimate and plan
To come back with an estimate of the work, we need to understand the topology: where the point of failure currently is, who holds the address, and how services learn about failover.
Floating IP setup almost always hinges not on the address itself, but on the behavior of the application layer after a node change. In the first conversation, we go over this — and based on it, we provide an implementation plan with the scope of work and timelines.
Let’s discuss the task — in the meeting we clarify:
- how many nodes and services must survive a failure and how traffic is distributed between them;
- how addressing is arranged now: address pools, subnets, gateways, site or cloud limitations;
- who will hold the address — an external load balancer, an agent on the nodes, or a managed service — and what is already deployed;
- what verifies service liveness and how many seconds of downtime are acceptable during failover;
- whether automatic return of the address to the primary node is needed and how it will affect active connections;
- requirements for configuration rollback and the procedure for engineer access to the environment;
- format of work: one-time design and configuration or support after go-live.
In response, we send the scope of work by stage, timelines, an address placement scheme, and a list of checks before go-live. Describe the task and your current network scheme — we will come back with an estimate and plan.