Michael K. Smith - Adhost wrote:

I'm having reachability problems with a CARP interface set up on two 7.1
boxes with an uplink to Cisco routers.  However, the inside CARP address
on the same set of PF boxes are reachable with no trouble.  Here's the

Cisco           Cisco
       HSRP Gateway
       CARP Interface 1
PF Box               PF Box
       CARP Interface 2

When I try to ping CARP Interface 1 above from the Internet, I get no
response.  When I ping the CARP Interface 2, which has a route set from
the Cisco's to CARP Interface 1, it works.  Here's what I see in my

00:38:45.763975 IP6 fe80::203:6cff:fef9:2c00 > ff02::1:ff00:7: ICMP6,
neighbor solicitation, who has 2001:4970:cccc::7, length 32

... with no response.

Here is the ifconfig from one box.

carp0: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500
        inet6 2001:4970:cccc::6 prefixlen 64
        inet6 2001:4970:cccc::7 prefixlen 64
        carp: MASTER vhid 1 advbase 1 advskew 100
carp1: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500
        inet6 2001:4970:cccc:aaaa::1 prefixlen 64
        carp: MASTER vhid 2 advbase 1 advskew 100

and the other shows appropriately as "BACKUP".  There is no change if I
run with just one PF box.

Any help would be greatly appreciated.

* Do you have PF rulesets written to take account of the CARP interfaces
 and IPs correctly?  You can say things like:

pass in on carp0 proto icmp6 from any to { carp0 carp1 } keep state
 You may not need carp specific rules if the carp IP is from the same
 network as the IPs on the front interfaces of those PF boxes, and your
 rules are written to filter traffic crossing those interfaces by network
(say) rather than by specific IP numbers. A good debugging trick is to make sure that all pf rules that block packets have a log clause, and then tcpdump pflog0 while doing your
 connectivity tests.  Immediately tells you if its PF blocking things
 rather than some other problem.

* I'm sure this is far too obvious, but in case you've tripped over this
 one accidentally:

   pass ... proto inet ....

 only allows IPv4.  Either drop the proto clause altogether, or add explicit
 'proto inet6' rules.

* Have you tried tcpdump on the various physical and carp interfaces on those
 machines while trying to ping?  Probably the most interesting data to be 
 from that is if there are ping responses being sent, and what IP they originate



Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                 Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                 Kent, CT11 9PW

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to