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.

Reply via email to