On 2-3-2012 9:23, Marios Makassikis wrote: >> 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.
Ok! > The demotion counter is decremented when you lose connectivity (ip_output > errors for instance), but shouldn't it be reincremented when you regain > connectivity? Yup, it should. Maybe inet4 clears the errorcounter for inet6 or vice versa. I'll take a look. > I also tested the issue Frederic was having, and it seems to be fixed when > you > flush the rules and states after disabling PF. Hmm, could be an issue as well. It looks like disabling pf does not clear out all states etc. > @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. As it trips up many people maybe pfctl and/or pf should apply "no-sync" automatically for carp.
