[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

carping about CARP



On 2012-11-30, Robert E. Seastrom <rs at seastrom.com> wrote:
>
> I can't seem to recall anyone griping about this here on our august
> little list but google finds that I'm by no means the first to have
> been burned by an unholy interaction between VRRP and CARP.
>
> Let's skip the protocol discussions (same protocol number and uses
> multicast) [*] and go straight to the behavioral observations.
>
> I turned on VRRP this evening on a pair of routers.  All of a sudden a
> CARP instance between a pair of pfSense boxes in the rack (which I
> didn't even know was there) invited itself to the party and started
> flailing all over the place and causing oscillating packet loss for
> anything that was going off-segment.
>
> Note that the Ciscos didn't exhibit any untoward behavior, and there
> were "passwords" on the VRRP sessions too.  Meanwhile, the pfSense box
> spazzed out and filled its dmesg logs with stuff like:
>
> arp: 192.0.2.1 moved from 00:00:0c:xx:xx:01 to 00:00:5e:xx:xx:01 on em1
> arp: 192.0.2.1 moved from 00:00:5e:xx:xx:01 to 00:00:0c:xx:xx:01 on em1
>
> (no other hosts on the segment were logging such activity)

All this shows is that the IP address is flip-flopping between
a Cisco MAC address and a CARP/VRRP unicast MAC address.
I would double check the vrrp config and make sure that the vrrp
IP address is *only* configured on vrrp, not ethernet interfaces.

> Looks like CARP is a bit loose about believing stuff coming in over
> the wire.  Seems a bit out of character for OpenBSD, but maybe these
> days it's considered all good so long as such a malfunction only
> causes an outage, not a core dump.

I don't see anything here indicating that it's to do with CARP
believing things sent over the wire, I suspect the problem would still
occur if CARP were disabled on the pfSense box. (Do people really
run CARP in the wild without authentication anyway?)