Bug #2012: 4th+ CARP member will not work with default automatic skew - pfSense - pfSense bugtracker

Bug #2012

4th+ CARP member will not work with default automatic skew

Added by Brian Scholer over 1 year ago. Updated 3 months ago.

Status:

Resolved

Start date:

11/18/2011

Priority:

Very Low

Due date:

Assignee:

% Done:

100%

Category:

CARP

Target version:

Affected version:

Affected Architecture:

Description

I created a pfSense cluster with 4 members. I'm using CARP IPs and XMLRPC for configuration sync. As designed, the skew on each VIP gets increased by 100 on each successive member. The skew is a value between 0 and 254, and as a result, the 4th member would be assigned a value of 300, but since it's too high, it just doesn't work. When you look at Status -> CARP it will show the VIPs as being in the init state. I worked around it by manually setting the skew to a valid value in the VIP settings.

Associated revisions

Revision 648a3ed8
Added by Brian Scholer 11 months ago

255 is not a valid skew value. Fixed bug #2012 (http://redmine.pfsense.org/issues/2012)

Revision 63a202a8
Added by Scott Ullrich 11 months ago

Merge pull request #127 from briantist/patch-1

255 is not a valid skew value. Fixed bug #2012

History

#1 Updated by Brian Scholer over 1 year ago

I just upgraded to 2.0.1 and after the upgrade the 4th member of my cluster reverted to having a skew that shows as 0 and being stuck in the init state. I had to reset it back to 250 and it seems to be fine since then (it doesn't change back on reboot of any of the members). I'm not sure what part of the upgrade process resets this stuff.

#2 Updated by Ermal Luçi 12 months ago

I am unsure why you'd want more than 3 members!

#3 Updated by Brian Scholer 12 months ago

I am using it for HAProxy in a virtualized environment where we have two sites which are part of the same vCenter (we'll call them upper and lower sites). I have two VMs forced to the upper site and two forced to the lower site. In each site, the VMs are forced to be on separate hosts. It's purely for redundancy to allow for quick failover. To allow for a situation where an issue affects the entire VMware environment, I may yet add more members.