Bug #959
closedConfig sync removes alias VIPs on the slave
100%
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.
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
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
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
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
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
Updated by Pierre POMES about 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
Updated by Chris Buechler almost 14 years ago
- Status changed from Feedback to Resolved