If I'd had this experience, I'd be tempted to use tcpdump on whichever physical interface is carpdev for the suspect carp interface in order to verify that multicast is enabled on your switch. With carp interfaces up, you should see periodic multicast messages. If you don't see any, then you've found your problem (and you need to revisit the switch configuration in order to fix it). I've seen a few cases in the past where action had to be taken in order to enable multicast on a switch; else CARP (or VRRP, or HSRP) of course fails to transition to proper states.
You mention that this machine is not a firewall and you're not using pfsync, but you didn't say right out loud whether you're running pf. Probably you're not, but there do exist some non-firewall applications where pf is used, and I don't know whether your machine falls into that category. If it does, then also make sure the pf ruleset isn't blocking multicast. Bill Tim wrote: > I'm using CARP under 3.7 release version on two boxes that aren't firewalls, > so > no pfsync involved and CARP configured as described in the FAQ. What I'm > seeing > is that the box I've designated as BACKUP always boots with carp0 as INIT and > carp1 and carp2 both come up BACKUP as expected. The other box always boots > with all 3 carp interfaces correctly as MASTER. On the backup box, I can > execute 'ifconfig carp0 up' and the interface correctly transitions to > BACKUP. > To prove to myself that this was not a problem with that particular box, I > tried > switching the roles making the backup the master and vice versa and the > problem > moves to the other box. Here's the output of ifconfig -A on the backup box > and > I can supply more info if needed: > > lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33224 > inet 127.0.0.1 netmask 0xff000000 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 > pflog0: flags=0<> mtu 33224 > pfsync0: flags=0<> mtu 2020 > enc0: flags=0<> mtu 1536 > dc0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 > address: 00:10:a4:c7:51:4e > media: Ethernet autoselect (100baseTX full-duplex) > status: active > inet 192.168.0.3 netmask 0xffffff00 broadcast 192.168.0.255 > inet6 fe80::210:a4ff:fec7:514e%dc0 prefixlen 64 scopeid 0x5 > inet 192.168.0.12 netmask 0xffffff00 broadcast 192.168.0.255 > inet 192.168.0.22 netmask 0xffffff00 broadcast 192.168.0.255 > inet 192.168.0.42 netmask 0xffffff00 broadcast 192.168.0.255 > carp0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500 > carp: INIT carpdev dc0 vhid 4 advbase 1 advskew 100 > inet 192.168.0.20 netmask 0xffffff00 broadcast 192.168.0.255 > carp1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > carp: BACKUP carpdev dc0 vhid 3 advbase 1 advskew 100 > inet 192.168.0.10 netmask 0xffffff00 broadcast 192.168.0.255 > carp2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > carp: BACKUP carpdev dc0 vhid 6 advbase 1 advskew 100 > inet 192.168.0.40 netmask 0xffffff00 broadcast 192.168.0.255 > > Tim > -- William Bloom| Snr Systems Engineer|M P H A S I S Architecting Value | Eldorado Computing 5353 North 16th Street, Suite 400 Phoenix, Az 85016 | Direct: +11-602-604-3100 | Fax: +11-602-604-3115| http://www.eldocomp.com -- CONFIDENTIALITY NOTICE -- Information transmitted by this e-mail is proprietary to MphasiS and/or its Customers and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please notify us immediately at [EMAIL PROTECTED] and delete this mail from your records.