Project

General

Profile

Bug #959

Config sync removes alias VIPs on the slave

Added by Thiago Witt about 9 years ago. Updated almost 9 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
CARP
Target version:
Start date:
10/20/2010
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.0
Affected Architecture:

Description

I want to have 2 CARP VIPs on the same interface, but each using a different subnet, so I need an alias on each system for the second subnet to be able to create the second CARP VIP, otherwise it won't let me.

The problem is that when I create or modify a VIP on the master it deletes the extra aliases created on the slave, and the CARP VIPs that use the second subnet become invalid on the slave.

I think pfsync shouldn't remove the extra aliases on the slave when synchronizing.

Associated revisions

Revision b019222a (diff)
Added by Pierre POMES about 9 years ago

Ticket #959: keep local ipalias and proxyarp vip's during a XMLRPC restore

Revision 00752d5a (diff)
Added by Pierre POMES almost 9 years ago

Ticket #959. Keep local items at the top of vip section

History

#1 Updated by Pierre POMES about 9 years ago

  • Assignee set to Pierre POMES

#2 Updated by Chris Buechler about 9 years ago

  • Subject changed from pfsync removes alias VIPs on the slave to Config sync removes alias VIPs on the slave

#3 Updated by Pierre POMES about 9 years ago

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

Hi Thiago,

This should be ok now. Can you try again and let me know ?

Regards,
Pierre

#4 Updated by Thiago Witt about 9 years ago

Hi Pierre,

I just tested it and the config sync no longer removes the alias vips on the slave, but there's a catch.
When I change something on the master and it performs the config sync, the alias vips on the slave end up at the bottom of the VIP list, they become the last VIPs.

The problem is that when I reboot the slave, the CARP VIPs that depend on those aliases don't get configured properly, because at that point the aliases are not yet configured, so those interfaces become invalid and the failover doesn't work.

Here is what my ifconfig shows after the reboot:

vip21: flags=9<UP,LOOPBACK> metric 0 mtu 1500
carp: INIT vhid 21 advbase 1 advskew 100
vip22: flags=9<UP,LOOPBACK> metric 0 mtu 1500
carp: INIT vhid 22 advbase 1 advskew 100

They don't get the IP that was supposed to be assigned to them.

So I guess the alias VIPs on the slave should be kept at the beginning of the list, before the carp vips.
I've manually edited the config to change the order and it solved the problem.

Regards,
Thiago

#5 Updated by Thiago Witt about 9 years ago

Here I made the following change and it seems to be working fine:

--- /usr/local/www/xmlrpc.php   2010-10-27 12:51:33.000000000 -0200
+++ /tmp/xmlrpc.php     2010-10-27 12:51:03.000000000 -0200
@@ -169,7 +169,7 @@
         // Then add ipalias and proxyarp types already defined on the backup
         foreach ($vipbackup as $vip)
                 if (($vip['mode'] == 'ipalias') || ($vip['mode'] == 'proxyarp'))
-                        $config['virtualip']['vip'][] = $vip ;
+                        array_unshift($config['virtualip']['vip'], $vip);
        $mergedkeys = implode(",", array_keys($params[0]));
        write_config(sprintf(gettext("Merged in config (%s sections) from XMLRPC client."),$mergedkeys));
        interfaces_vips_configure();

Regards,
Thiago

#6 Updated by Pierre POMES about 9 years ago

Thanks for the feedback.

I do not know if you should apply any "sorting" on the VIP array on the backup firewall. With my code, "ipalias" and "proxyarp" VIP are at added at the end on the list, and with your patch, at the beginning. Both cases may be wrong, because:
- In the GUI, VIP list may not appear in the same order in the master and the backup.
- Internally in the code, I do know if this may have an impact (for fw rules for examples), or in screens on which there is a dropdown list with all VIP's type (OpenVPN for example).

For the dev team: any suggestion ?

Pierre

#7 Updated by Pierre POMES almost 9 years ago

Hi Thiago,

I finally added your suggestion, everything is ok on my pair of boxes

Revision 00752d5a82baea1f05c8dcfdff58112b1d42620e

Can you also confirm this is ok ?

Regards,
Pierre

#8 Updated by Chris Buechler almost 9 years ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF