A single network interface or one public IP address is a silent single point of failure on any . When that interface goes down — whether due to a NIC fault, an upstream routing change, or a carrier outage — every service bound to that address becomes unreachable until the problem is manually resolved. For high-traffic applications, even a few minutes of unplanned downtime translates directly into lost revenue, broken user sessions, and damaged trust.
IP failover, combined with properly configured failover DNS, removes that dependency by ensuring traffic can shift to a standby address or node automatically, without human intervention. This guide walks through the architecture and configuration logic behind a high-availability IP failover setup on a dedicated server.
You will learn how IP failover routing works at the network level, how failover DNS complements it at the resolution layer, and how the two mechanisms interact to close gaps that neither can cover alone. The guide also covers health-check design, failover trigger thresholds, and the verification steps that confirm your setup will actually hold under real failure conditions — not just in theory.
Why IP Failover Matters for Bare-Metal High Availability
IP failover matters on infrastructure because a dedicated server has no hypervisor layer to migrate workloads away from failing hardware. When a virtual machine encounters a host fault, the virtualization platform can restart it elsewhere. On a dedicated server, that abstraction does not exist.
A failed NIC, a corrupted network driver after a kernel update, or an upstream routing fault leaves the server's public IP unreachable with no automatic recovery path — unless one has been explicitly configured.
The failure modes that make this consequential differ from those in shared environments. Hardware faults on bare metal tend to be abrupt: a NIC stops responding, a switch port loses the link, or an unplanned reboot leaves the server in a recovery loop for several minutes. Each of these scenarios produces the same result — the primary IP becomes unroutable, and every service bound to it stops accepting connections.
Network bonding can mitigate a physical NIC or link failure. It cannot protect against an upstream carrier outage, a data center network segment failure, or a scenario where the server itself must be taken offline for emergency maintenance. For that class of failure, IP failover at the routing layer is the correct control.
DNS-based failover addresses a different gap. By pointing a hostname at a standby IP when health checks detect a failure, failover DNS ensures that new connection attempts resolve to a reachable address. However, DNS propagation is constrained by TTL values and resolver caching, which means it is not instantaneous.
IP routing failover — where the address itself is moved or traffic is redirected at the network level — can act within seconds, making the two mechanisms complementary rather than interchangeable. A robust high-availability architecture uses both layers together.
Understanding where each mechanism starts and stops is the foundation for everything that follows in this guide.
When a primary server goes offline, the floating IP is instantly reassigned to a standby host, allowing inbound traffic to reach a live machine without any change on the client side.
How IP Failover Routing Works on a Dedicated Server
IP failover routing works by reassigning a publicly routable address — often called a floating IP or virtual IP — from one physical host to another, so that traffic continues to reach a live server even when the original machine becomes unavailable. The mechanism that moves the address differs by approach, but the outcome is the same: the network learns a new path to that address, and inbound connections follow it.
The two primary approaches are provider-managed IP mobility and self-managed routing announcements. With provider-managed mobility, the hosting platform exposes an API endpoint. A health-check script detects that the primary server has stopped responding and calls the API to reassign the floating IP to a standby host. The provider's routing infrastructure propagates the change internally.
Failover windows under this model typically range from a few seconds to around one minute, depending on how frequently the health check polls and how quickly the provider's control plane applies the reassignment. With self-managed routing, the two servers run a protocol such as BGP or VRRP. The standby host detects the primary's absence through missed keepalive messages and begins announcing the shared address itself.
This approach gives you finer control over timing and priority, but it requires that your provider support custom routing announcements — not all bare-metal plans do.
One detail that is easy to overlook is what happens to in-flight TCP connections during the switchover. Existing sessions are interrupted regardless of which approach you use. A client that had an open connection to the primary server must reconnect. The failover mechanism preserves reachability for new connections; it does not preserve session state.
Applications that need seamless session continuity require an additional layer — shared session storage or a connection broker — sitting above the routing control.
Choosing between these two approaches depends on your provider’s capabilities and your team’s operational scope. A well-structured dedicated server setup documents both the health-check logic and the reassignment procedure so the failover path is repeatable, not improvised under pressure.
How Failover DNS Complements IP-Layer Redundancy
Failover DNS solves a different problem than IP routing failover: instead of moving an address, it changes which address a domain name resolves to. The two mechanisms are not redundant — they operate at separate layers and handle failure scenarios the other cannot address cleanly.
DNS failover reaches failure scenarios that IP routing simply cannot handle, such as cross-provider standby hosts.
Where DNS failover earns its place is in scenarios IP routing cannot reach: cross-provider standby hosts, geographic failover to a different datacenter, or situations where a floating IP is simply unavailable on the infrastructure in use.
The practical constraint to plan around is TTL-driven propagation delay — a 60-second TTL reduces exposure but does not eliminate it, since some resolvers ignore low TTL values and clients with persistent connections are unaffected by a DNS change until they reconnect.
DNS failover complements it by covering resolvers and clients that have not yet observed the routing change, and by providing a fallback path when the routing mechanism itself is unavailable.
The two layers also differ in geographic reach. An IP routing change propagates through the network infrastructure of your provider and its upstream peers. A DNS change propagates globally to any resolver that re-queries after the TTL expires — making DNS-layer failover more effective for geographically dispersed user bases where a single routing change may not be visible to all traffic paths equally.
A complete high-availability setup on a dedicated server integrates both layers: routing failover for speed, DNS failover for breadth. The implementation details — health-check intervals, TTL staging, and record-swap automation — are where the architecture moves from concept to a working configuration, and that full walkthrough is exactly what this guide covers in the sections ahead.
Configure the floating or failover IP according to the provider’s routing model. Some providers route the address to the selected server and require it to be configured locally; others inject the address through their network or API. Do not activate the same address simultaneously on two hosts unless the provider explicitly documents that design.
How to Configure a Floating IP Address for Failover
Configuring a floating IP for failover requires four concrete actions executed in the right order: request the additional address from your provider, bind it to your primary server's network interface, and wire the reassignment API call to a health-check trigger. Configure the address on the standby server only as required by the provider’s documented routing model. Do not activate the same address simultaneously on both hosts unless the provider explicitly supports that design. The binding step is where most implementations break down. Running ip addr add 203.0.113.50/32 dev eth0 works immediately but disappears on reboot.
Example: add a floating/secondary address on the active node (interface and IP are placeholders):
IP=203.0.113.10/32
IFACE=eth0
sudo ip addr add "$IP" dev "$IFACE"
ip -br addr show "$IFACE"
On systemd-based distributions, the correct approach is to define the alias in a /etc/systemd/network/ unit file or the equivalent netplan YAML so the address survives a restart without manual intervention.
Configure the standby host to accept the failover address only according to the provider’s documented procedure. If routing reassignment succeeds but the standby host has not been configured to accept traffic on that address, the cutover can succeed at the network layer and fail silently at the host layer: packets arrive at the correct server and are dropped.
Firewall rules on both servers must explicitly permit inbound traffic on the floating IP, not just on the server's primary address. A missing ufw allow in on eth0:1 or equivalent iptables rule is one of the most reliable ways to produce exactly that failure mode.
The reassignment script ties these layers together. At minimum it should call your provider’s API to move the floating IP when required, log the timestamp and exit code of each step, and use gratuitous ARP only when failover occurs within the same Layer 2 network and the provider supports that mechanism. Provider-routed or cross-network failover normally requires an API or routing update instead. Test the exact provider-supported procedure from an external client. That log becomes your audit trail when you verify the failover completed cleanly — and it is the same output you will reference when coordinating the DNS A-record update covered in the next section.
How to Set Up Health Checks and Automated Failover Triggers
A health-check system is the nerve center of any IP failover setup: it detects failure, applies a threshold to avoid reacting to transient noise, and then fires the reassignment call. Without it, the floating IP and DNS records configured in earlier steps remain static — ready but never activated.
The two most practical implementation paths are a structured daemon such as Keepalived, which handles VRRP-based virtual IP management natively, and a lightweight shell loop that polls the primary node with a curl request and counts consecutive failures before acting.
With a shell-based approach, the core logic is straightforward. A loop runs every few seconds, issues an HTTP or TCP check against the primary server's service endpoint, and increments a failure counter on each non-response. Only when that counter crosses a defined threshold — commonly three to five consecutive failures — does the script trigger the provider API call to move the floating IP.
This threshold design is the critical tuning decision: a threshold of one makes the system hypersensitive and prone to false-positive failover flaps, where a single slow response causes an unnecessary switch and a subsequent switch back. A threshold of ten introduces too much delay before real failures are acted on.
Three to five consecutive failures, checked at five-second intervals, gives a detection window of fifteen to twenty-five seconds — acceptable for most production workloads without generating noise.
Keepalived offers a more structured alternative. It manages the virtual IP directly through the operating system’s network stack, uses a configurable health-check script, and supports priority-based failback once the primary recovers. Its failure threshold and interval parameters map directly to the same tuning logic, but the daemon handles the interface binding and route advertisement internally, reducing the amount of custom scripting required.
Whichever approach you choose, log every check result — not just failures. A log of check outcomes makes it possible to distinguish a genuine outage from a network hiccup, and provides the audit trail that compliance-oriented environments often require. Dedicated Server Log Management – rsyslog and logrotate Setup covers how to structure that logging pipeline so check output is retained and rotatable without manual intervention.
Lowering your DNS TTL to 30 seconds must happen well before any expected failover event, because resolvers will continue honoring the old cached value until the previous high-TTL answer naturally expires.
How to Configure Low-TTL DNS Records for Fast Failover
For DNS, that preparation has a hard timing constraint: because resolvers cache your current TTL until it expires, a reduction from 3,600 seconds to 30 seconds only takes effect after the old high-TTL answer has already aged out — meaning you must make the change 24 to 48 hours before you need it, not at the moment of crisis.
The practical minimum TTL that most major public resolvers will honour sits at 30 seconds; values below that threshold are often floored to the resolver’s own minimum, so a TTL of 5 or 10 seconds does not reliably produce faster propagation — it simply adds unnecessary DNS query volume. Set your A and AAAA records to between 30 and 60 seconds as early as your maintenance window allows, and confirm your DNS provider supports that range before depending on it in a failover scenario.
Dropping your TTL to 30 seconds at least 48 hours early is the single most effective preparation before a planned failover.
This is the DNS layer's contribution to your recovery window: the floating IP moves in seconds, but if resolvers are caching your domain's old address for 3,600 seconds or more, end users remain directed at a dead host for the entire cache lifetime.
The practical minimum TTL that most major public resolvers will honour sits at 30 seconds. Values below that threshold are often floored by resolvers to their own minimum, meaning a TTL of 5 or 10 seconds does not reliably produce faster propagation — it simply adds unnecessary DNS query volume. The safe, widely respected floor is 30 seconds.
Pre-stage this value at least 24 to 48 hours before you need it: because resolvers cache the previous TTL until it expires, a TTL reduction takes effect only after the old high-TTL record has already been served and cached. If your current records carry a one-hour TTL and you lower it during an incident, you may wait a full hour before the short TTL is in circulation.
Integrating a DNS API update call directly into your failover script closes the gap between IP reassignment and name resolution. Your script should update the A record immediately after — or in parallel with — the floating IP move, rather than treating DNS as a manual follow-up step. Validate propagation by querying multiple geographically distributed resolvers from your monitoring host; a successful check confirms that the updated record is visible beyond your local network.
How to Test Your Failover Setup Without Affecting Live Traffic
Testing your failover setup means deliberately triggering each failure condition in a controlled environment before a real incident forces the issue. A structured rehearsal sequence — run against a staging floating IP rather than your production address — lets you verify both the IP reassignment path and the DNS update path without exposing live users to risk.
From a third host, confirm reachability before and after you move the address:
ping -c 3 203.0.113.10
curl -I --max-time 5 http://203.0.113.10/
Begin by provisioning a staging floating IP that mirrors your production configuration exactly: same binding logic, same health-check script, same DNS API call, but pointed at a subdomain or internal test record that carries no real traffic. This separation is the foundation of safe rehearsal. From a separate monitoring host — one that sits outside the primary server's network path — observe each switchover objectively.
A monitoring host on the same physical switch as your primary server may miss NIC-level failures entirely, so geographic or network separation matters here.
Run three distinct failure simulations in sequence. First, simulate a NIC failure by bringing down the primary server's network interface without shutting the machine down; confirm that the floating IP migrates to the standby host within your target window. Second, kill the primary application process while leaving the host fully reachable; this tests whether your health check distinguishes a process failure from a host failure — a distinction that matters because the remediation path differs.
Third, block the health-check endpoint at the firewall level to simulate a scenario where the host is alive but unreachable to the checker. Each simulation should produce a logged trigger event and a confirmed IP reassignment. Verify a DNS update only when DNS failover is part of the selected architecture.
Measure the total elapsed time from failure onset to DNS propagation for each scenario and record the values. Concrete timing data from rehearsal runs gives you a realistic recovery window to communicate to stakeholders — and a baseline to detect regressions if you later modify the trigger logic. For teams managing compliance requirements, these rehearsal logs serve as documented evidence that the failover mechanism has been validated under realistic conditions.
The full implementation sequence — including runbook structure and threshold documentation — is covered in our dedicated server high-availability guide.
The most dangerous failover mistakes are the ones that only surface under real incident conditions, such as a standby server whose firewall rules were never updated to accept traffic on the reassigned address.
Common IP Failover Pitfalls and How to Avoid Them
What that section does not cover is why this failure is so easy to miss: most teams verify the routing reassignment and stop, never auditing whether the standby's interface list and firewall ruleset were updated to match.
The subtler failures emerge only under conditions a controlled lab simulation rarely reproduces: asymmetric firewall rules on the standby that silently drop inbound traffic addressed to the floating IP, ARP cache staleness on upstream routers that keeps routing packets to the old MAC address after reassignment, and health-check scripts configured to fail open, triggering reassignment on transient noise rather than confirmed outages.
Catching these gaps before a live incident requires testing from an external vantage point and auditing both the routing layer and the standby's interface configuration as separate verification steps.
- Asymmetric firewall rules on the standby server that silently drop inbound traffic addressed to the floating IP
- ARP cache staleness on upstream routers that continues routing packets to the old MAC address after reassignment
- Health-check scripts that fail open, triggering reassignment on transient noise rather than confirmed outages
- Floating IP bound only at the provider routing layer but never added as an interface alias on the standby server
- DNS TTL left at default high values, extending the recovery window even after the IP reassignment completes in seconds
- Reassignment script never tested under real failure conditions, leaving silent misconfigurations undiscovered until a live incident
Asymmetric firewall rules occur when the firewall on your standby server does not permit inbound traffic on the floating IP address. If packets arrive but connections do not complete, inspect the firewall's accept rules for that specific address.
Add an explicit rule permitting inbound traffic on the floating IP before you ever need it in production.
Conclusion – Build a Failover Stack That Holds Under Real Failure
For provider fit and procurement context, see our guide to choosing a dedicated server provider and the honest recommendation overview.
A robust IP failover stack is not a single configuration file — it is a coordinated sequence of routing decisions, DNS updates, health-check logic, and ARP management that must function correctly in the exact moment your primary server stops responding. The sections above walk through each layer in order: floating IP assignment, keepalived configuration, low-TTL DNS failover, and the testing rehearsals that confirm the whole chain holds under realistic failure conditions.
One misconfigured firewall rule or slow ARP flush can silently cancel every other layer of your failover stack.
Getting any one layer wrong — a firewall rule that blocks the reassigned address, a health-check script that fails open, an ARP cache that takes minutes to clear — can nullify every other safeguard. Treating the stack as an integrated system, and validating it as one, is what separates a failover setup that survives an incident from one that only looks correct in documentation.
The full implementation framework — including runbook templates, threshold guidance, and post-failover validation steps — is collected in our high-availability resource for bare-metal infrastructure.
