Date: Wed, 16 Jan 2019 17:56:53 +0000 From: Steven Hartland <killing@multiplay.co.uk> To: Pete French <petefrench@ingresso.co.uk>, freebsd-stable@freebsd.org, thomas@gibfest.dk Subject: Re: CARP stopped working after upgrade from 11 to 12 Message-ID: <9335fa4b-b2cf-038c-706c-d0c7bbbfe00e@multiplay.co.uk> In-Reply-To: <E1gjp4C-000ErD-1K@dilbert.ingresso.co.uk> References: <E1gjp4C-000ErD-1K@dilbert.ingresso.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9335fa4b-b2cf-038c-706c-d0c7bbbfe00e>