How to: VRRP (Virtual Router Redundancy Protocol) Keepalived Configuration

Introduction

VRRP (Virtual Router Redundancy Protocol) is a commonly used protocol that offers high availability for a network (or subnetwork). Keepalived is a Linux package that uses VRRP to deliver high availability among Linux servers. It also delivers load-balancing services, but this article concentrates on getting started with just the VRRP portion.

Prerequisites

– Linux installation on at least 2 hosts (be sure they are already updated).
– At least 3 available IP addresses (1 for each of at least 2 peer keepalived servers, and 1 virtual IP shared amongst them).

Install Keepalived

Keepalived should be available through most Linux repositories, so use the appropriate package manager to your distribution to install it on each device that will be running the service.

On CentOS/RedHat/Fedora:

sudo yum install keepalived

On Debian/Ubuntu:

sudo apt-get install keepalived

Example Topology

Here’s a diagram of the topology we’ll be using in this example.

Configuring VRRP

First, it’s prudent to back up the default configuration file, in case you’d like to use it later as a template or for reference.

sudo mv /etc/keepalived/keepalived.conf /etc/keepalived/keepalived.conf.original

Then, using the text editor you prefer, create a new configuration file:

sudo nano /etc/keepalived/keepalived.conf

You can paste in the following configuration block, though you’ll want to make the appropriate changes for your environment (including IPs and interfaces).

NOTE: If using private IP’s on the Atlantic.Net Public Cloud, replace eth0 with eth1 in all instaces.  eth0 is used as a public interface and not private.

########################
## VRRP configuration ##
########################

# Identify the VRRP instance as, in this case, "failover_link".
vrrp_instance failover_link {

    # Initial state of the keepalived VRRP instance on this host
    # (MASTER or BACKUP). Once started, only priority matters.
    state MASTER

    # interface this VRRP instance is bound to.
    interface eth0

    # Arbitrary value between 1 and 255 to distinguish this VRRP
    # instance from others running on the same device. It must match
    # with other peering devices. 
    virtual_router_id 15

    # Highest priority value takes the MASTER role and the
    # virtual IP (default value is 100).
    priority 110

    # Time, in seconds, between VRRP advertisements. The default is 1,
    # but in some cases you can achieve more reliable results by
    # increasing this value.
    advert_int 4

    # Authentication method: AH indicates ipsec Authentication Header.
    # It offers more security than PASS, which transmits the
    # authentication password in plaintext. Some implementations
    # have complained of problems with AH, so it may be necessary
    # to use PASS to get keepalived's VRRP working.
    #
    # The auth_pass will only use the first 8 characters entered.
    authentication {
        auth_type AH
        auth_pass 1nrRYh*j
    }

    # VRRP advertisements ordinarily go out over multicast. This 
    # configuration paramter causes keepalived to send them
    # as unicasts. This specification can be useful in environments
    # where multicast isn't supported or in instances where you want
    # to limit which devices see your VRRP announcements. The IP
    # address(es) can be IPv4 or IPv6, and indicate the real IP of
    # other members.
    unicast_peer {
        10.5.132.122
    }
    # Virtual IP address(es) that will be shared among VRRP
    # members. "Dev" indicates the interface the virtual IP will
    # be assigned to. And "label" allows for clearer description of the
    # virtual IP.
    virtual_ipaddress {
        10.5.132.120 dev eth0 label eth0:vip    
    }
}

You can paste the same configuration block into your other VRRP peers, just be sure to adjust the priority and unicast_peer (if using this option) as appropriate.

Once you have completed editing this file, save and exit.

Start the service on each device:

sudo service keepalived start

What’s next?

Congratulations on installing and configuring VRRP and Keepalived! We have included some basic VRRP troubleshooting issues below, in case you run into some common issues. We hope that you enjoyed following along this tutorial. Please check out some of our other guides below or search using the search bar above.

Basic VRRP Troubleshooting

To verify that the VRRP virtual IP is operating on the correct host, check the interfaces on participating hosts (assuming eth0 is the interface bound by VRRP):

ip addr show eth0

You should see your virtual IP (here’s where the “eth0:vip” label comes in handy) only under the host whose /etc/keepalived/keepalived.conf priority is the highest.

Split-Brain VRRP

If multiple hosts take the virtual IP, then they are likely either not receiving VRRP advertisements from the host with the highest configured priority or have a misconfiguration in their /etc/keepalived/keepalived.conf files.

First, check to ensure your /etc/keepalived/keepalived.conf files are correct and consistent. In particular, verify that your virtual_router_id, advert_int, and authentication configuration parameters match (the vrrp_instance name doesn’t have to be the same across hosts, but it does make things easier to verify if it is consistent).

If you make any changes, to /etc/keepalived/keepalived.conf, you’ll need to restart the keepalived service.

sudo service keepalived restart

If your configuration files look good, then verify that your hosts participating in VRRP are able to talk to each other on via the interface bound to VRRP. From the host that should be backup but thinks it’s master, see if it’s receiving traffic from the primary host:

sudo tcpdump -i eth0 -nn 'host 10.5.132.121'

You might be getting a lot of extra traffic on this interface, so to help narrow it down to traffic related to VRRP, filter by the AH protocol header.

sudo tcpdump -i eth0 -nn 'host 10.5.132.121 and ah'

If you opted for PASS instead of AH as your authentication type, then try to filter by VRRP packets.

sudo tcpdump -i eth0 -nn 'host 10.5.132.121 and vrrp'

Virtual IP not responding

In some Linux implementations, your virtual IP address may not respond if you don’t tell it that it can bind nonlocal IPs to real interfaces. To allow this behavior, add the following line to /etc/sysctl.conf:

sudo nano /etc/sysctl.conf

net.ipv4.ip_nonlocal_bind = 1

And then, to load this new parameter into the running kernel with the following shell command:

sysctl -p

 

Thank you for following along this how-to, we hoped you have enjoyed it. Please check back here for more updates or check out the many services offered by Atlantic.Net, including dedicated server hosting, Private Cloud Hosting and PCI Hosting.