Thanks everyone I figured it out!
19:13:46.334037 CARPv2-advertise 36: vhid=50 advbase=1 advskew=0
demote=0 (DF) [tos 0x10]
19:13:46.334299 CARPv2-advertise 36: vhid=50 advbase=1 advskew=0
demote=0 (DF) [tos 0x10]
Something is mirroring and replaying all the packets back.
Grrr. Must be a vmWare config issue.
William
Jason Dixon wrote:
If you'd like to send me your full `ifconfig -a` and pf.conf from both
systems I'll take a look.
-J.
On Fri, Jul 18, 2008 at 06:19:22PM -0700, William Stuart wrote:
Not before the failure, but I did test negative demoting as a fix..
-bash-3.2# ifconfig -g carp carp: carp demote count 0
Jason Dixon wrote:
Any chance you've been adjusting your carpdemote counters?
-J.
On Fri, Jul 18, 2008 at 06:04:19PM -0700, William Stuart wrote:
Gotcha. Nope, only one set of OpenBSD boxes.
Just as a test, I replaced the carp config for one of the IP
addresses and changed the VHID. still backup.
-bash-3.2# ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33168
groups: lo
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff000000
em0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:50:56:a0:4f:81
groups: egress
media: Ethernet autoselect (1000baseT full-duplex,master)
status: active
inet6 fe80::250:56ff:fea0:4f81%em0 prefixlen 64 scopeid 0x1
inet 172.19.161.64 netmask 0xffffffff broadcast 172.19.161.64
enc0: flags=0<> mtu 1536
carp5: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:00:5e:00:01:32
carp: BACKUP carpdev em0 vhid 50 advbase 1 advskew 0
groups: carp
inet6 fe80::200:5eff:fe00:132%carp5 prefixlen 64 scopeid 0x4
inet 172.19.161.67 netmask 0xffffff00 broadcast 172.19.161.255
-bash-3.2# cat /etc/hostname.carp5
inet 172.19.161.67 255.255.255.0 172.19.161.255 vhid 50 carpdev em0
pass blahblahblah
Jason Dixon wrote:
I didn't mean someone else had. I meant that perhaps you setup another
pair on another network, but on the same switch. It happened to us, and
even though we didn't see "leaking" carp/vrrp packets, the problem
disappeared as soon as we changed the vhid to something unique.
Oh well, try try again.
-J.
On Fri, Jul 18, 2008 at 03:58:56PM -0700, William Stuart wrote:
Nope. Confirmed with tcpdump. No other carp/vrrp.
Plus, where I am, no one else can spell B-S-D let alone install
one, let alone setup carp.
William
Jason Dixon wrote:
On Fri, Jul 18, 2008 at 01:26:07PM -0700, William Stuart wrote:
Markus Wernig wrote:
Hi
Are you sure that all the interfaces you have configured
carp on have link and can connect to each other? (I've
seen similar behaviour caused by defective NICs: receive
buffer not receiving while send buffer still sending - try
ping on all interfaces) Is lo up? Is there any other
router on the same network segment that propagates the same
VHID with a better metric (i suppose that a VRRP router on
the same net could cause trouble if it uses the same
VHIDs).
no answers, just questions, I know ...
hth /markus
Don't mind the questions! Just hoping someone will ask one
where I say, "I am such an IDIOT! Why didn't I think of
that!"
Yes, it had link (I was ssh'ing to the configured interface).
They can connect to each other (I would assume if they
couldn't see each other I would have a MASTER/MASTER issue
and not a BACKUP/BACKUP issue), I ended up halting one of
them to see if I can get just one to go MASTER when it was
alone, no dice. I did a tcpdump and did not see any other
VRRP traffic.
Is there any chance another CARP segment has recently been added to the
same switch / stack? I've seen CARP vhid's "leak" through to other
broadcast domains on some Avaya switches.
