Project

General

Profile

Actions

Bug #5800

closed

Rule to block carp from (self) ineffective when pfsync is in use

Added by Jim Pingle almost 9 years ago. Updated almost 9 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
CARP
Target version:
Start date:
01/22/2016
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.2.x
Affected Architecture:

Description

Adding this primarily for documentation purposes. Normally with our default ruleset pf will block CARP packets coming in from (self) to prevent L2 packet duplication from affecting the CARP status. However when pfsync is enabled, there is a bit of a quandary here:

  • CARP heartbeat packet from primary leaves the primary
  • CARP heartbeat packet is delivered both to the secondary and also back to the primary by the misconfigured L2
  • The primary rejects this first CARP heartbeat packet and the secondary accepts it (both correct actions)
  • The secondary creates a state allowing the heartbeat packet
  • The state is synchronized back to the primary
  • The primary then accepts subsequent duplicate heartbeat packets, causing itself to be demoted due to the packets arriving faster than it transmits, ending up with flapping VIPs and what appears to the user as a dual backup situation

Disabling pfsync and clearing the CARP states allows the CARP VIPs to function until the L2 is repaired.

Not sure if there is any good way around that. Given that it's an L2 problem there is only so much we can do to stop foot-shooting in that area. Perhaps pass carp in expected directions/interfaces with no state?

Actions #1

Updated by Jim Thompson almost 9 years ago

  • Assignee set to Jim Pingle

assigned to Pingle until he assigns it elsewhere.

Actions #2

Updated by Chris Buechler almost 9 years ago

Rather than trying to block the traffic, CARP should really just ignore its own advertisements. Fix the root issue rather than trying to block traffic to work around it. mgrooms posted a patch for this years back:
https://lists.freebsd.org/pipermail/freebsd-net/2009-July/022545.html

that won't cleanly apply to FreeBSD 10.x, though it's probably straight forward enough to bring it up to date for Luiz.

Actions #3

Updated by Jim Pingle almost 9 years ago

  • Assignee changed from Jim Pingle to Luiz Souza
Actions #4

Updated by Jim Thompson almost 9 years ago

  • Assignee changed from Luiz Souza to Jim Pingle

abort patches like this.

Either determine that it's a problem in upstream, or deal with it in another way.

Actions #5

Updated by Chris Buechler almost 9 years ago

  • Status changed from New to Confirmed

it's a problem in upstream, for which we should be able to get a fix along the lines of what was linked above committed to FreeBSD.

Actions #6

Updated by Jim Pingle almost 9 years ago

  • Assignee changed from Jim Pingle to Luiz Souza

Back to Luiz to analyze the patch and get it pushed upstream.

Actions #7

Updated by Jim Thompson almost 9 years ago

  • Assignee changed from Luiz Souza to Jim Pingle
Actions #8

Updated by Chris Buechler almost 9 years ago

  • Status changed from Confirmed to Resolved
  • Affected Version changed from All to 2.2.x

Workaround applied and confirmed to fix subject issue.

Actions

Also available in: Atom PDF