Bug #3876
closedpfsync is not synchronizing states on 2.2
0%
Description
On 2.2, with a valid pfsync configuration, no state information is passed between the HA nodes.
From ifconfig on the primary:
pfsync0: flags=41<UP,RUNNING> metric 0 mtu 1500 pfsync: syncdev: em2 syncpeer: 10.71.71.2 maxupd: 128 defer: on syncok: 1
From ifconfig on the secondary:
pfsync0: flags=41<UP,RUNNING> metric 0 mtu 1500 pfsync: syncdev: em2 syncpeer: 10.71.71.1 maxupd: 128 defer: on syncok: 1
The sync interface is wide open, they can ping each other, config sync works, and so on. Nothing shows up in tcpdump watching for pfsync traffic, and no states are copied to the secondary as expected.
Updated by Chris Buechler almost 10 years ago
- Category changed from CARP to High Availability
Confirmed as described, whether multicast or unicast, no pfsync traffic is ever seen on the wire.
Updated by Ermal Luçi almost 10 years ago
- Status changed from New to Feedback
It is fixed for me with new snapshots.
Updated by Chris Buechler almost 10 years ago
- Status changed from Feedback to Confirmed
This is a little better, but still completely non-functional. It actually sends pfsync traffic now, which is the improvement. The opposite system is passing the pfsync traffic, but doesn't end up with any of the primary's states. Quick test is to run a nmap at the primary from a source IP that has everything passed, that'll create about 2000 states on the primary for a few minutes. The secondary gets none of those (nor anything else, just a quick means of piling up a decent number of states to see clearly that it's not working).
Updated by Chris Buechler almost 10 years ago
- Priority changed from High to Very High
Additional info, secondary spits this out:
kernel: carp: demoted by -240 to 0 (pfsync bulk fail)
moving to "very high" as means of differentiating RC-blocking issues.
Updated by Ermal Luçi almost 10 years ago
- Status changed from Confirmed to Feedback
Seems to be working for me now.
Updated by Chris Buechler almost 10 years ago
- Status changed from Feedback to Resolved
looks to be fine, works in both directions from testing.
Updated by Steven Hartland almost 9 years ago
. . / Ermal LUÇI could you confirm which build you tested on, as I can't see this bug referenced in the release notes?