|
On Thu, 2007-02-15 at 17:43 -0500, Sal Tepedino wrote:
> Alright... this is driving me nuts and countless searches have turned up
> tons of help, but no solution.
<snip>
> On the master:
> Feb 15 17:21:26 pd-lvs01 Keepalived_vrrp: VRRP_Instance(VI_1) Received lower
> prio advert, forcing new election
> Feb 15 17:21:26 pd-lvs01 Keepalived_vrrp: VRRP_Instance(VI_1) IPSEC-AH :
> Syncing seq_num - Increment seq
> Feb 15 17:21:26 pd-lvs01 Keepalived_vrrp: VRRP_Instance(VI_1) Sending
> gratuitous ARPs on eth1 for 10.1.1.110
> Feb 15 17:21:27 pd-lvs01 Keepalived_vrrp: VRRP_Instance(VI_1) Received lower
> prio advert, forcing new election
> Feb 15 17:21:27 pd-lvs01 Keepalived_vrrp: VRRP_Instance(VI_1) IPSEC-AH :
> Syncing seq_num - Increment seq
> Feb 15 17:21:27 pd-lvs01 Keepalived_vrrp: VRRP_Instance(VI_1) Sending
> gratuitous ARPs on eth1 for 10.1.1.110
>
> . . . Repeat ad nauseum.
<snip>
> Any ideas? I'm stumped. I tried changing just about everything. I'm out of
> ideas.
Don't use IPSEC authentication for your VRRP packets. As far as I
recall, the algorithm was (and may still be) broken. Try it with no auth
at all and see what happens.
If you're worried about predictive packet injection knocking the pants
off of your VRRP instances, change the mcast_src_ip to something only
you know, and then firewall the heck out of stuff arriving to the VRRP
multicast address such that only the two known sources can talk to each
other.
Graeme
|
