Project

General

Profile

Actions
Copy link

Bug #3876

closed

pfsync is not synchronizing states on 2.2

Added by Jim Pingle about 10 years ago. Updated about 9 years ago.

Status:
Resolved
Priority:
Very High
Assignee:
Ermal Luçi
Category:
High Availability
Target version:
2.2
Start date:
09/19/2014
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.2
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.

Actions
Copy link
 #1

Updated by Chris Buechler about 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.

Actions
Copy link
 #2

Updated by Ermal Luçi about 10 years ago

  • Status changed from New to Feedback

It is fixed for me with new snapshots.

Actions
Copy link
 #3

Updated by Chris Buechler about 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).

Actions
Copy link
 #4

Updated by Chris Buechler about 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.

Actions
Copy link
 #6

Updated by Ermal Luçi about 10 years ago

  • Status changed from Confirmed to Feedback

Seems to be working for me now.

Actions
Copy link
 #7

Updated by Chris Buechler about 10 years ago

  • Status changed from Feedback to Resolved

looks to be fine, works in both directions from testing.

Actions
Copy link
 #8

Updated by Steven Hartland about 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?

Actions
Copy link

Also available in: Atom PDF