How to set up floating virtual IP with Keepalived on Linux

What is high availability and why do we need it

Keeping systems running without interruptions is one of the greatest challenges in local network administration. When a primary server suffers a hardware crash or requires maintenance, users instantly lose access to essential services. In practice, this means relying on a single machine creates a single point of failure capable of paralyzing entire operations in a company or tech lab.

To solve this problem, we adopt the concept of high availability, which involves keeping servers in redundancy so that if the main equipment stops responding, another takes its place instantly. To complement infrastructure stability, many administrators also apply strategies such as how to configure internet link redundancy and load balancing, ensuring external connectivity remains active even during ISP outages.

How the VRRP protocol and virtual IP work

The core of gateway redundancy in Linux is the VRRP protocol, short for Virtual Router Redundancy Protocol, an open standard that allows multiple routers or servers to share a single virtual IP address. In practice, imagine two computers constantly talking to each other in a room, both with their own physical IP addresses, but deciding to share a common phone number to answer customer calls.

In this scenario, the client on the network always points to this floating virtual IP, regardless of which physical machine is answering data packets at that exact moment. As long as the primary server is healthy, it periodically emits signals stating it remains in charge; if these signals stop arriving, the secondary server takes over the shared IP address and routes traffic without users noticing the interruption.

Installing and preparing the environment with Keepalived

Keepalived is the industry standard tool for implementing this dynamic on the Linux operating system in a lightweight and efficient way. Before proceeding with configuration, verify that all servers involved in redundancy have static IP addresses in the same local network range and that the internal firewall allows multicast traffic for the VRRP protocol.

Package installation can be done via your distribution's native package manager, such as APT in Debian or Ubuntu-based systems. Next, configuration files located in the system directory must be adjusted to define which machine acts as primary and which acts as secondary, establishing the priorities of each node in the cluster.

1. Install the Keepalived package on both primary and secondary servers by running the package manager command.

   sudo apt update && sudo apt install keepalived -y

2. Edit the main configuration file located in the system service directory to define network parameters.

   sudo nano /etc/keepalived/keepalived.conf

3. Restart the Keepalived service on both machines to apply new rules and start automated monitoring.

   sudo systemctl restart keepalived && sudo systemctl enable keepalived

Writing the configuration file for the master node

Keepalived's configuration file defines server behavior during failures and sets priority rules. On the master node, we set a higher priority, such as value 100, ensuring it always tries to take control of the virtual IP when operational and connected to the main network.

Additionally, we configure the correct network interface through which control packets flow and specify the virtual IP address to be enabled on the network card. To maintain corporate environment robustness, it is also essential to track physical server hardware, integrating practices such as how to set up IPMI temperature alerts for rack servers to prevent unexpected thermal shutdowns.

Configuring the backup node and automatic failover

The backup node has a configuration structure very similar to the master node, but with two fundamental differences: the defined priority must be lower, such as value 90, and the state directive must clearly indicate the machine acts as secondary. When the master node stops sending heartbeat signals, the backup node notices the absence after a few seconds and promotes itself to master state.

At that exact moment, Keepalived executes internal operating system commands to add the virtual IP to the local network interface and sends an announcement notice to update ARP tables of other devices connected to the network. This transition happens in fractions of a second, ensuring applications relying on continuous connections experience minimal oscillation or no noticeable drop.

Validating failover and testing cluster resilience

After completing configuration on both machines, the most important step is performing practical tests to confirm automatic failover works as planned. A simple and effective way to do this is monitoring system log files in real time while the primary server's network cable is physically disconnected from the switch or wall port.

If configured correctly, logs will show the secondary server taking over master state and claiming the virtual IP immediately, while continuous ping tests from a third network machine record at most one or two dropped packets during transition. If failures occur, diagnostics usually point to permission errors in the monitoring script or blocks caused by restrictive firewall rules on the system. To explore these architectural concepts further in production, see our related technical analysis on How to measure real GPU power consumption.

Final thoughts on local high availability

Implementing gateway redundancy with Keepalived transforms fragile network infrastructure into a resilient environment capable of handling hardware mishaps. Although it requires initial attention when setting priority values and isolating control traffic, the operational gain widely compensates for the technical effort invested. Keeping critical services protected against unexpected failures ensures peace of mind for administrators and continuity for end users relying on the network every day.