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