Feature #2218

Ability to delay CARP master status at boot time

Added by Chris Buechler almost 9 years ago. Updated over 1 year ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


On some systems that have packages installed, the package start time is long enough that it leaves certain services down for up to a minute during boot time because CARP switches back to master on the primary too early. Would be nice to have an option to delay CARP taking master status (but still having the CARP IPs there so services can bind to them) for a defined period of time.


#1 Updated by Jim Thompson over 6 years ago

  • Target version changed from 2.2 to 2.3

pushed to 2.3

#2 Updated by Jim Thompson about 6 years ago

  • Assignee set to Ermal Luçi

#3 Updated by Chris Buechler over 5 years ago

  • Assignee deleted (Ermal Luçi)
  • Target version deleted (2.3)

#4 Updated by Louis Hather over 3 years ago

This is still an issue as of 2.3.4.

#5 Updated by Jim Pingle over 3 years ago

It's a non-issue if you put a node into maintenance mode from Status > CARP before updating or rebooting.

#6 Updated by Louis Hather over 3 years ago

Sure, but I don't reboot my firewalls - they crash. See the issue?

#7 Updated by Jim Pingle over 3 years ago

Then focus on fixing the source of the crashes if they happen that often -- The avoidable cases are already avoidable.

#8 Updated by Louis Hather over 3 years ago

While true, it'll still fail at some point. I'm not sure this can be reasonably described as a non-issue with such severe service interruption. We're talking no packet movement for 30-90 seconds. I assume configuring pfSense to not fail back could be done, and that would be acceptable, but if I do that I'd simply be working around the issue.

#9 Updated by Seb A over 3 years ago

Jim, what about if you have a power failure on the master firewall (and you have each firewall connected to different power, like we do): it goes down, backup takes over, power restored, old master comes up, takes over, and you lose all connectivity for over 1 minute. I'm sorry, but this is not a 'non-issue' - this is supposed to be a highly available system, so I think you should take another look at this.

#10 Updated by Jim Pingle over 3 years ago

I didn't close the ticket and say it wouldn't be addressed eventually. When this old ticket was opened, maintenance mode did not exist and the most common cases (upgrades and manual reboots) are easily addressed with maintenance mode. That was not noted on this ticket, so anyone searching the problem and finding this ticket may not realize it was possible.

#11 Updated by Black BlackBinary over 2 years ago

Hi there, is see the point of @Seb A,. I am prepare two pfsense with CARP IPs for our data center. We made some tests: the Fail-over in a unexpected hardware failure (simulated by pull the power plug) works great. the Slave-pfsense takes over in 1-10 sec with everything that is needed. IPsec, DNS, HAproxy, OpenVPN, routing and more. But! if i boot the master-pfsense again, the device never expected the failure and therefore is not in CARP-maintinance. the CARP-Feature is one of the first things that is loaded at boot and the Interface makes an instand-fail-back without even being ready. THIS fail-back creates a service Down for 1-2 minutes.

i would prefere:
  • optional: a pfsense-box is in CARP Maintinace by default (and manually reactivated)
  • optional: the failback of CARP can be delayed : maintinace by default + reenable X secundes after boot

#12 Updated by Greg Harris over 1 year ago

I agree with @BlackBinary. The second optional should be the normal operation. A reboot should automatically trigger a maintenance mode, but it should always make sure that PFSense is operational before disabling maintenance mode and then begin taking over CARP interfaces. Otherwise, sessions and connections are being lost. A variable of X seconds after reboot would be a nicety.

Also available in: Atom PDF