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
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[email protected]"
