Learn Keepalived - Installation & Hello Keepalived

#Introduction

Time to get to work! Episode 3 is the point where you install Keepalived on real machines, create your first floating IP configuration, and watch two nodes fight over MASTER status. All the concepts from episode 2 become real the moment the log shows Entering MASTER STATE.

We'll accomplish three things: installation on Ubuntu and RHEL, a simple keepalived.conf configuration for one virtual IP, then starting the service and reading its status and logs. By the end of the episode, you'll have a working two-node HA lab.

#Installing Keepalived

#Ubuntu and Debian

On the Debian family, installation is just one command:

sudo apt update
sudo apt install -y keepalived

The sudo apt install -y keepalived command pulls the daemon along with dependencies like libssl and libnl. This package is already integrated with systemd, so the keepalived.service unit is available automatically.

#RHEL and CentOS

On the Red Hat family, use dnf:

sudo dnf install -y keepalived
sudo systemctl enable --now keepalived

The Keepalived package on RHEL is available in the base or EPEL repositories. After installing, you should disable firewalld temporarily while in the lab so multicast VRRP isn't blocked, then re-enable it in episode 13 when we cover firewall hardening.

#Verifying the Installation

Make sure the daemon and version are ready to use:

keepalived --version
systemctl is-enabled keepalived

The keepalived --version output shows the build version, and systemctl is-enabled keepalived should return enabled if the service has been enabled.

#First Floating IP Configuration

#The MASTER Node

Create the /etc/keepalived/keepalived.conf file on the first node. We designate this host as MASTER with priority 100:

global_defs {
  router_id KEEPALIVED-MASTER
}
 
vrrp_instance VI_1 {
  state MASTER
  interface eth0
  virtual_router_id 51
  priority 100
  advert_int 1
  virtual_ipaddress {
    192.168.1.100/24 dev eth0
  }
}

The vrrp_instance VI_1 block defines a VRRP instance with the VIP 192.168.1.100. state MASTER sets the initial status, and priority 100 is your main asset in the election.

#The BACKUP Node

On the second node, the configuration is almost identical, only the state and priority differ:

global_defs {
  router_id KEEPALIVED-BACKUP
}
 
vrrp_instance VI_1 {
  state BACKUP
  interface eth0
  virtual_router_id 51
  priority 90
  advert_int 1
  virtual_ipaddress {
    192.168.1.100/24 dev eth0
  }
}

Notice that virtual_router_id, interface, and virtual_ipaddress must be exactly the same on both nodes. What may differ is router_id (the local identity) and priority. Mismatches in those first three parameters are the most common source of problems.

#Starting the Service and Observing Status

#Enable and Start the Service

Start the service on both nodes, then check its status:

sudo systemctl enable --now keepalived
sudo systemctl status keepalived --no-pager

sudo systemctl enable --now keepalived enables and starts the service in one step. If the configuration is valid, the status will show active (running) and the VIP will appear on the MASTER node's interface.

#Reading State Transition Logs

Check the logs to confirm the election ran:

sudo journalctl -u keepalived --no-pager

On the MASTER node you'll see Entering MASTER STATE, while the BACKUP shows Entering BACKUP STATE or Entering MASTER STATE only if the MASTER dies. The journalctl -u keepalived logs are your main window into understanding all behavior in this and later episodes.

Verify the VIP is actually attached to the interface:

ip -brief addr show eth0

The ip -brief addr show eth0 output on the MASTER node must include 192.168.1.100/24. On the BACKUP node, that address should not appear while the MASTER is healthy.

#Simple Failover Test

From a client machine on the same subnet, ping the VIP continuously in one terminal:

ping -i 0.5 192.168.1.100

While the ping is running, take down the MASTER node by stopping the service:

sudo systemctl stop keepalived

The sudo systemctl stop keepalived command stops the daemon and simulates a dead node. Within seconds, the BACKUP node takes over the VIP and the ping returns to normal without any manual intervention.

#Checking MAC Movement

A successful failover is visible from the change in MAC owner in the client's ARP table:

ip neigh show | grep 192.168.1.100

The ip neigh show output shows the MAC bound to the VIP. After failover, that MAC must have changed to the BACKUP node's MAC. This is proof that gratuitous ARP was sent and traffic now flows to the new node.

#Closing

Episode 3 completes the first cycle: installation, two-node configuration, starting the service, and proving failover works with uninterrupted pings. You now have a functional HA lab ready for experiments in the episodes ahead.

Key takeaways:

• Installation is just apt or dnf, and the service is ready via systemd.
• MASTER and BACKUP nodes must share the same virtual_router_id and VIP.
• state and priority determine who wins the election.
• The journalctl -u keepalived logs are the source of truth for VRRP status.
• Failover is proven by the VIP MAC change in the client's ARP table.
• Always test failover before building more complex architectures.

In episode 4, we dissect VRRP instances and virtual IPs fully — priority parameters, authentication, tracked interfaces, preemption, and floating IP behavior under various conditions. Your configuration will go from a mere example to one you truly understand.