VRRP High Availability Daemon (keepalived)

AstLinux now supports the keepalived package, High Availability (HA) is achieved via the VRRP protocol. VRRP is a fundamental brick for implementing router failover.

Most AstLinux users will not have an occasion to use keepalived, this is more of an enterprise level feature, but basic usage can be useful for certain AstLinux installations.

Note: AstLinux 1.3.4 or later is required

In AstLinux, keepalived is enabled by creating the configuration file, /mnt/kd/keepalived/keepalived.conf

Tip -> After keepalived is started, the configuration file will be symlinked via /etc/keepalived/keepalived.conf

The next section “Example Basic Configuration” shows a very basic starting point to build upon.

For reference, an updated list of keepalived.conf options is maintained here: keepalived.conf Reference

After the /mnt/kd/keepalived/keepalived.conf is created, start the keepalived service via the CLI with:

service keepalived init

As a very basic example, we are creating a hot standby (backup) to a master AstLinux box.

Note -> For a production solution it is assumed that all the important file storage bits of the master are kept in sync with the backup AstLinux box. Ignored for this example.

Both boxes share the same 10.10.50.0/24 network off the external interface eth0.

The master box has a primary IPv4 of 10.10.50.62

The backup box has a primary IPv4 of 10.10.50.65

The virtual IPv4 address 10.10.50.244 labeled eth0:10 will float between “master” and “backup”, preferring “master” as long as it is available.

Master, primary IPv4: 10.10.50.62
Configuration: /mnt/kd/keepalived/keepalived.conf

! Configuration File for keepalived

global_defs {
  router_id ASTLINUX
  enable_script_security
  script_user root root
  vrrp_check_unicast_src
}

vrrp_instance VI_1 {
  state MASTER
  interface eth0
  virtual_router_id 50
  # How often to send out VRRP advertisements
  advert_int 1
  # The priority to assign to this device. This controls
  # who will become the MASTER and BACKUP for a given
  # VRRP instance (a lower number get's less priority)
  priority 100

  # Use unicast, multicast disabled
  unicast_src_ip 10.10.50.62
  unicast_peer {
    10.10.50.65
  }

  virtual_ipaddress {
    10.10.50.244 dev eth0 label eth0:10
  }
}

Backup, primary IPv4: 10.10.50.65
Configuration: /mnt/kd/keepalived/keepalived.conf

! Configuration File for keepalived

global_defs {
  router_id ASTLINUX
  enable_script_security
  script_user root root
  vrrp_check_unicast_src
}

vrrp_instance VI_1 {
  state BACKUP
  interface eth0
  virtual_router_id 50
  # How often to send out VRRP advertisements
  advert_int 1
  # The priority to assign to this device. This controls
  # who will become the MASTER and BACKUP for a given
  # VRRP instance (a lower number get's less priority)
  priority 99

  # Use unicast, multicast disabled
  unicast_src_ip 10.10.50.65
  unicast_peer {
    10.10.50.62
  }

  virtual_ipaddress {
    10.10.50.244 dev eth0 label eth0:10
  }
}

After the /mnt/kd/keepalived/keepalived.conf files are created, start the keepalived service on each box via the CLI with:

service keepalived init

Tip -> Watch the VRRP packets with: tcpdump -i eth0 -vvn vrrp

At this point on the master ip addr show dev eth0 should display a line containing 10.10.50.244

inet 10.10.50.244/32 scope global eth0:10

and the backup box should not display 10.10.50.244 . Note that if something blocked VRRP packets between the boxes then both boxes would think they are the master and both would have 10.10.50.244 assigned, which is not good. Only one occurrence of 10.10.50.244 should exist at a time.

Now test, disconnect the eth0 cable from the master box … watch the backup box acquire the 10.10.50.244 address, then reattach the network cable and watch 10.10.50.244 move back to the master. For added fun, perform a ping 10.10.50.244 from a local device and watch it (almost) not miss a beat during this test.

More testing, edit the /mnt/kd/keepalived/keepalived.conf file on the backup and change priority 99 to priority 101, restart keepalived by:

service keepalived restart

now the backup box should be the master since it has a higher priority. Undo the priority change and watch it return to normal.

Now you get the idea, to make this a production solution a few more details will need to be addressed, research the topic and build upon this basic example.

More feature-rich keepalived.conf configurations will make use of external shell scripts, organize them in the /mnt/kd/keepalived/ directory. You may also refer to that directory as /etc/keepalived/ in your keepalived.conf configuration.

If your scripts need a runtime, non-persistent state file, the /var/state/keepalived/ directory is provided for such files.

For unicast keepalived configurations, it is not necessary to add firewall rules since the standard stateful connection tracking rules will allow inbound return packets from VRRP unicast peers you associate with.

If for some reason you prefer to use multicast instead of unicast packets, then you will need to configure the firewall to allow VRRP Multicasts.

Edit your /mnt/kd/arno-iptables-firewall/custom-rules file, and add this snippet.

allow_ext_vrrp_mcast()
{
  local src_list="$1" IFS

  echo "[CUSTOM RULE] Allowing external(INET) VRRP Multicasts from: $src_list"
  IFS=' ,'
  for src in $src_list; do
    iptables -A EXT_INPUT_CHAIN -p 112 -s $src -d 224.0.0.18 -j ACCEPT
  done
}
allow_ext_vrrp_mcast "10.10.50.0/24"

The allow_ext_vrrp_mcast argument can be a list of source IP's, network(s) or 0/0 to allow any source.