When configuring VRRP, priority is the parameter which decides which peer is the Master or the Slave.

A few parameters can influence a peer's priority:

  • Peer's vrrp priority value

  • VRRP daemon parameters that modify the priority based on the presence of some elements in the ALOHA:

    • A connected network interface: remove 6 points from priority for each DOWN interface belonging to the group

    • A load-balancing or high availability service: add track_weight_svc (default 8) points to the priority for each track_svc service up

    • A management service: add track_weight_mgt points to the priority for each track_mgmt service up

Warning

VRRP priority is very important. If improperly set up (too big gap between Slave and Master), it may prevent a failover to occur.

Use case: ALOHA cluster with default configuration

Consider an ALOHA cluster with the factory configuration as described below:

  • Master vrrp priority set to 101

  • Slave vrrp priority set to 100

  • track_svc monitors haproxy and track_weight_svc set to 8

  • track_mgt monitors wui and sshd and track_weight_mgt set to 2

  • All interfaces are UP

Default VRRP priority

  • Master priority computation: 101 + 8 (haproxy) + 2 (sshd) + 2 (wui) = 113

  • Slave priority computation: 100 + 8 (haproxy) + 2 (sshd) + 2 (wui) = 112

When the Slave fails

When the Slave node of a VRRP cluster fails (power off, unreachable through the network, etc.), nothing happens.

Result: The Master node carries on handling the traffic.

When the Master fails

When Master node of a VRRP cluster fails (power off, unreachable through the network, etc.), then:

  • No other VRRP heartbeat is emitted

  • The Slave node waits for 3s before considering the Master as definitively unavailable

  • The Slave node becomes the Master and emits VRRP heartbeat packets with priority set to 112

  • In the meantime, the new Master sends gratuitous ARP to announce the new MAC address associated to the VIPs

Result: The traffic fails over to the Slave node.

When HAProxy fails on the Slave

  • Slave priority computation becomes: 100 + 2 (sshd) + 2 (wui) = 104

  • 104 is lower than 113 (current Master priority), hence the Slave remains slave

Result: The Master node carries on handling the traffic.

When HAProxy fails on the Master

  • Master priority computation becomes: 101 + 2 (sshd) + 2 (wui) = 105

  • 105 is lower than 112 (current Slave priority), so the Slave becomes the new master

  • The new Master emits VRRP heartbeat packets with priority set to 112

  • In the meantime, the new Master sends gratuitous ARP to announce the new MAC address associated to the VIPs

Result: The traffic fails over to the Slave node.

When SSHD or WUI fails on the Slave

If SSHD crashes:

  • Slave priority computation becomes: 100 + 8 (haproxy) + 2 (wui) = 110

  • 110 is lower than 113 (current Master priority), so the Slave remains slave

Result: The Master node carry on handling the traffic.

When SSHD or WUI fails on the Master

If SSHD crashes:

  • Master priority computation becomes: 101 + 8 (haproxy) + 2 (wui) = 111

  • 105 is lower than 112 (current Slave priority), hence the Slave becomes the new Master

  • The new Master emits VRRP heartbeat packets with priority set to 112

  • In the meantime, the new Master sends gratuitous ARP to announce the new MAC address associated to the VIPs

Result: The traffic fails over to the Slave node.

Note

It is possible to trigger a failover only when both SSHD and WUI crash. To do this, you set up a difference of 3 points between the VRRP priority of the Slave and the Master (for example, 100 and 103, respectively.)