Project

General

Profile

Bug #1598

IP Alias VIP configured on a CARP VIP, resets CARP VIP on sync

Added by Jim Pingle about 8 years ago. Updated almost 8 years ago.

Status:
Resolved
Priority:
High
Assignee:
Ermal Luçi
Category:
CARP
Target version:
Start date:
06/13/2011
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.0
Affected Architecture:
All

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.

Associated revisions

Revision 2708a5cf (diff)
Added by Ermal Luçi about 8 years ago

NEw functiong does_vip_exist() which works for carp and ipalias type vips to help in carp sync issues. Fixes #1598

Revision b526daaf (diff)
Added by Ermal Luçi about 8 years ago

Correct functiong does_vip_exist() to actually work. Fixes #1598

Revision 5aa7a46c (diff)
Added by Ermal Luçi about 8 years ago

Ticket #1598. Correctly handle ipalias vips when re-enabling carp from the carp_status screen.

History

#1 Updated by Ermal Luçi about 8 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

#2 Updated by Ermal Luçi about 8 years ago

#3 Updated by Jim Pingle about 8 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.

#4 Updated by Ermal Luçi about 8 years ago

  • Status changed from New to Feedback

#5 Updated by Andreas Bochem about 8 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.

#6 Updated by Steve Polyack about 8 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.

#7 Updated by Andreas Bochem about 8 years ago

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

#8 Updated by Jim Pingle about 8 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

#9 Updated by Andreas Bochem almost 8 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.

#10 Updated by Andreas Bochem almost 8 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.

#11 Updated by Jim Pingle almost 8 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.

#12 Updated by Chris Buechler almost 8 years ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF