Bug #1598
closed
IP Alias VIP configured on a CARP VIP, resets CARP VIP on sync
100%
Description
Found while looking at #1534 but is really a separate issue, so I'm splitting it off into a new ticket.
Prerequisites: CARP VIP, ex: vhid 40, and an IP Alias VIP configured on interface vip40
When syncing from master to slave, the CARP VIP underneath the IP Alias VIP will be reconfigured like so on the slave:
Jun 13 18:27:54 pfSense-b kernel: vip40: link state changed to DOWN
Jun 13 18:27:54 pfSense-b kernel: vip40: INIT -> MASTER (preempting)
Jun 13 18:27:54 pfSense-b kernel: vip40: link state changed to UP
It appears then that the reconfigured VIP also stays master on the slave box. 5 minutes after the sync it's still showing as master on both units.
Updated by Ermal Luçi over 13 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset 2708a5cf1648c6d776588e0e4b9be1b6aad65994.
Updated by Ermal Luçi over 13 years ago
Applied in changeset b526daafae3405b27fa7219d90a81272d0979f57.
Updated by Jim Pingle over 13 years ago
- Status changed from Feedback to New
Just tried on a current snapshot, and your carp patch did fix the CARP VIP changing itself to master (so that's great!)
However, if it ever becomes master, it never demotes itself to backup again.
Easy to reproduce with an IP alias on a CARP VIP, and then disable CARP on the master, see that they're all MASTER on the slave as expected. Re-enable CARP on the master, and check the CARP status on the slave box and all VIPs are backup except for the VIP that has an IP alias on top - it's still master, and never goes back to the backup state.
If you disable/enable CARP on the backup it does go back, but the transition should be automatic.
To add to the weirdness, after you disable/enable CARP on both units, it will keep transitioning automatically.
Updated by Andreas Bochem over 13 years ago
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.
Updated by Steve Polyack over 13 years ago
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.
Updated by Andreas Bochem over 13 years ago
Same issue persisting on latest 2.0-RC3 (amd64) built on Mon Jul 4 16:49:48 EDT 2011.
Updated by Jim Pingle over 13 years ago
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
Updated by Andreas Bochem over 13 years ago
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.
Updated by Andreas Bochem over 13 years ago
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.
Updated by Jim Pingle over 13 years ago
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.
Updated by Chris Buechler over 13 years ago
- Status changed from Feedback to Resolved