nanog mailing list archives

Re: carping about CARP


From: Stuart Henderson <stu () spacehopper org>
Date: Fri, 30 Nov 2012 13:37:46 +0000 (UTC)

On 2012-11-30, Robert E. Seastrom <rs () 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?)




Current thread: