On 1-3-2012 10:08, Marios Makassikis wrote: > Hello, > No, I'm using hardware machines. > > I tested what Imre suggested, i.e.: flushing PF states with > 'pfctl -F states'. > With a freshly booted machine, CARP packets are allowed to pass. > I then disabled pf, flushed the states and reloaded pf with the > 'block log' rule. At this point, CARP is effectively blocked, and > remains so until a reboot happens: adding a pass rule, clearing states > or even completely disabling pf had no effects. > > I tried using the following rule to let CARP pass: > pass quick log inet proto carp no state > > which leads me to a very odd CARP configuration: fw2 remains master > although it should go back to backup state. advskew on fw1 is 50, and > 100 on fw2. > A closer look at tcpdump revealed that CARP packets sent by fw1 have a > demote value of 1, which explains why fw2 remains master as its demote > value is 0. > What I can't explain is this: > > fw1~# ifconfig -g carp > carp: carp demote count 0 > > In other words, fw1 says it's demotion counter is null, but the messages > sent have a demote value of 1. At the same time, fw1 transitions from > backup to master and back again repeatedly, as I saw in > /var/log/messages.
Are you sure that fw1 is sending and not receiving those? The only way to be really sure is to use "tcpdump -D out". > I tried setting the demotion counter to a higher value, say 10, using > 'ifconfig -g carp carpdemote 10' and then I get the expected behavior: > fw2 remains master, fw1 remains backup and the demote value displayed by > ifconfig is the same as the one that is sent to the other machine. Not sure what's going on yet, but the following may provide more hints: - bump net.inet.carp.log to 3 - check "netstat -s -p carp" - if you use pfsync, use "no-sync" on the carp pass rules
