Re: Keepalived keeps forcing new elections despite priority not 255

To: " users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: Keepalived keeps forcing new elections despite priority not 255
From: Peter Broadwell <peter@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Sun, 24 Jul 2005 21:54:54 -0700
Con Tassios wrote:

On Sun, 24 Jul 2005, peter wrote:

I have two boxes that are also trying to be firewalls, load balancers and provide high
availability via keepalived.

Either box alone works, but if I have keepalived running on both they get into a non-stop effort to force new elections.

Both boxes are 64bit (x86_64 AMD Opteron(tm)) with a 2.6.12-gentoo-r4 kernel
running Keepalived v1.1.11 all compiled at the same time.

They seemed to work once for a bit, then started failing.
I suspect failed multicasting between them, but cant determine what traffic actually has to get passed on which interfaces when... (Other thoughts are uint8 vs int instances of priority in vrrp.c - I am on a 64 bit processor?
Configuration confusion - I'm a newbie at this.)

Sound like you may be blocking VRRP packets -

Thanks for the quick input.

I used to have them blocked, but fixed that by allowing both and traffic in and out after seeing these address mentioned in the log files. This was before the current problems - and am not seeing them in the logs anymore so pretty sure I got that right, but the above situation persists. Are there other multicast addresses needed too (I have scanned my logs but not sure what to look for)?

If this was the case how would the notifications about the need for new elections be coming through? If is indeed the sum total of how the boxes need to communicate I may need to look at my
firewall rules more carefully.


_______________________________________________ mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to

<Prev in Thread] Current Thread [Next in Thread>