> I just thought of something that bit me recently as well. > > With a real IPv6 address CARP will send out advertisements via IPv4 > _and_ IPv6. It's the same CARP message so if either one reaches the > backup it's ok. > > Your block rule had "inet" so you were probably blocking IPv4 only. But > because of the send errors (due to pf blocking) fw1 started to demote > itself. > > Anyway, you have to block inet6 too if you want to block carp completely. >
Hi, I thought of this yesterday shortly after leaving ... Indeed, after bumping the net.inet.carp.log value even more, there are messages such as this one in /var/log/messages : fw1 /bsd: carp0: ip_output failed: 65 fw1 /bsd: carp0: ip6_output failed: 65 fw1 /bsd: carp1: ip_output failed: 65 fw1 /bsd: carp1: ip6_output failed: 65 After clearing the states, reloading PF to allow CARP packets, fw1 says it transitioned from master to backup. I take it's because of the demote counter: as soon as I set it back up to 0, fw1 goes back to master and fw2 to backup. The demotion counter is decremented when you lose connectivity (ip_output errors for instance), but shouldn't it be reincremented when you regain connectivity? I'm guessing the user is expected to do this with something like ifstated if it isn't done automatically. I also tested the issue Frederic was having, and it seems to be fixed when you flush the rules and states after disabling PF. @Russell I think either pass quick proto carp keep state (no-sync) or pass quick proto carp no state is more appropriate, as it also takes into account pfsync presence and saves you from debugging issues like the one I was having. Thank you all for your help. Marios.
