Project

General

Profile

Actions

Bug #959

closed

Config sync removes alias VIPs on the slave

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

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

100%

Estimated time:
Plus Target Version:
Release Notes:
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.

Actions #1

Updated by Pierre POMES about 14 years ago

  • Assignee set to Pierre POMES
Actions #2

Updated by Chris Buechler about 14 years ago

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

Updated by Pierre POMES about 14 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

Actions #4

Updated by Thiago Witt about 14 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

Actions #5

Updated by Thiago Witt about 14 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

Actions #6

Updated by Pierre POMES about 14 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

Actions #7

Updated by Pierre POMES almost 14 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

Actions #8

Updated by Chris Buechler almost 14 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF