On 16/01/2019 17:33, Pete French wrote:>> I have confirmed that pfsync is the culprit. Read on for details. > Excellent work. I;m home now, so won't get a chnace to out this into > practice until tomorrow unfortunately, but it's brilliant that you have > confirmed it. > >> I tried disabling pfsync and rebooting both nodes, they came up as >> MASTER/SLAVE then. > This is very useful to know - I willprobably try tomorrow running my > firewalls back up with pfsync disabled to see if it works for me too. > >> Then I tried enabling pfsync and starting it, and on the SLAVE node I >> immediately got: > That kind of confirms it really doesnt it ? > > So, is it possible to get r342051 backend out of STABLE for now ? This > is a bit 'gotcha' for anyone running a firewall pair with CARp after all. > > -pete. > > PS: are you going to file a PR ?You could also try setting net.pfsync.pfsync_buckets="1" in /boot/loader.conf which reading the code should ensure all items are processed in a single bucket so if its the bucketing split has the issue then this will fix. If the issue is more ingrained then it won't. ??? Regards ??? Steve
Thomas Steen Rasmussen
2019-Jan-16 19:16 UTC
CARP stopped working after upgrade from 11 to 12
On 1/16/19 6:56 PM, Steven Hartland wrote:> >> PS: are you going to file a PR ?Yes here https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235005> You could also try setting net.pfsync.pfsync_buckets="1" in > /boot/loader.conf which reading the code should ensure all items are > processed in a single bucket so if its the bucketing split has the > issue then this will fix. If the issue is more ingrained then it won't.Setting net.pfsync.pfsync_buckets="1" in /boot/loader.conf doesn't fix it. That would have been a neat workaround though :) /Thomas