We have a two machine keepalived setup where both machines are configured in the same way.

vrrp_instance RP_VI_1 {
  interface                 eth3
  state                     BACKUP
  virtual_router_id         61
  priority                  150
  advert_int                1
  garp_master_delay         5

  virtual_ipaddress {
    x.x.x.x dev eth2

Both machines have been running with this configuration for about half a year now with no problems, but tonight there was a seemingly erroneous state transition.

host1: in BACKUP state
host2: in MASTER state

03:44:44: host1: Transition to MASTER state
03:44:45: host1: Entering MASTER STATE
03:44:46: host1: Received higher prio advert 150
03:44:46: host1: Entering BACKUP state

In that time host2 did not transition between any states and did not log any information. Thus host1 sent out a gratuitous ARP to the network and it's mac address was cached for several hours while it dropped all traffic.

Our biggest problem here is, that host1 reverted to BACKUP state saying a "higher prio advert" was received while both hosts have the same prio of 150. How can it be that this transition was triggered without the systems communicating afterwards to decide who should stay master and thus send out a new gratuitous ARP to ensure packets are transferred to the correct host?

1 Answer 1


After reading through VRRPv2 (RFC3768) definitions the following is aparent:

1) As a tie breaker between two masters of same priority primary IP address is used. The host with higher IP address wins, the one with lower IP address will transition to MASTER

2) The option garp_master_refresh for keepalived can be used to resend gratuitous ARP after x seconds. As this defaults to 0 now requests are resend by default, specifying it should cause the system to recover after some time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.