pfSense

Applied in changeset b526daafae3405b27fa7219d90a81272d0979f57.

Checked on 2.0-RC3 (amd64) built on Wed Jun 22 23:09:34 EDT 2011:

Dis-/re-enabling CARP is an issue even with no IP aliases defined.
Backup becomes master and does not demote itself again, until explicitly turning CARP off/on again on the secondary node as well.

I do, however, have some CARP VIPs defined on interfaces which are currently not cabled or have the port disabled on the switch side. Just in case that matters. Those VIPs always stay in "INIT" (no cable) or both sides master (switchport disabled) all the time, which is what I expect.

But I'd also still expect the fully cabled VIPs to be fully functional.

For what it's worth, I have a pair of devices running 2.0-BETA5 (8.1-RELEASE-p2 #0: Tue Jan 25 20:12:38 EST 2011 sullrich@FreeBSD_8.0_pfSense_2.0-snaps.pfsense.org:/usr/obj.pfSense/usr/pfSensesrc/src/sys/pfSense_wrap.8.i386 i386).

When a sync or rule reload occurs, the secondary/standby device assumes a MASTER role for all CARP VIPs. Unlike described above, it's only temporal; the secondary unit drops its CARP VIPs back to BACKUP within a few seconds. With pfsync also in use, there is no noticeable effect on traffic for end-users, but managed switches complain about the CARP HA MAC address flapping between the ports the two devices are connected to.

Same issue persisting on latest 2.0-RC3 (amd64) built on Mon Jul 4 16:49:48 EDT 2011.

Andreas Bochem wrote:

Same issue persisting on latest 2.0-RC3 (amd64) built on Mon Jul 4 16:49:48 EDT 2011.

That is not the most recent snapshot. See http://forum.pfsense.org/index.php/topic,38687.0.html

Jim P wrote:

That is not the most recent snapshot. See http://forum.pfsense.org/index.php/topic,38687.0.html

Thanks for the info. I updated to 2.0-RC3 (amd64) built on Thu Jul 21 00:28:37 EDT 2011 now and checked again.

The issue on my machine is resolved in that version.

Reminder: I don't have IP aliases defined, though.

Andreas Bochem wrote:

The issue on my machine is resolved in that version.

Addendum:
Not quite. The secondary node successfully does demote itself to backup in the case of
simply dis-/enabling CARP on the primary node now.

However, I just noticed that it does not demote itself again when the primary node got rebooted. Triple-checked that: In two cases the secondary node did not demote itself at all, one case resulted in a mixed state of one CARP VIP being demoted, the other remaining master on the secondary node.

I have no problems with this that I can reproduce. I have about every combination of VIPs on interfaces and IP aliases and they all properly promote and demote now, whether it's a manual failover or a reboot of the master.