Bug #3876
closed
pfsync is not synchronizing states on 2.2
Added by Jim Pingle about 10 years ago.
Updated about 9 years ago.
Category:
High Availability
Affected Architecture:
All
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.
- Category changed from CARP to High Availability
Confirmed as described, whether multicast or unicast, no pfsync traffic is ever seen on the wire.
- Status changed from New to Feedback
It is fixed for me with new snapshots.
- 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).
- 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.
- Status changed from Confirmed to Feedback
Seems to be working for me now.
- Status changed from Feedback to Resolved
looks to be fine, works in both directions from testing.
. . / Ermal LUÇI could you confirm which build you tested on, as I can't see this bug referenced in the release notes?
Also available in: Atom
PDF