Hi Jeff, I tested in my setup with latest master rebasing. I did not see the add:true (ips.json) when ips are removed from the UI.
Removed public ip is not configured on the eth2 interface. Here is the output: 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 06:f6:cc:00:00:0e brd ff:ff:ff:ff:ff:ff inet 10.147.46.102/24 brd 10.147.46.255 scope global eth2 inet 10.147.46.112/24 brd 10.147.46.255 scope global secondary eth2 "eth2": [ { "add": true, "broadcast": "10.147.46.255", "cidr": "10.147.46.102/24", "device": "eth2", "first_i_p": true, "gateway": "10.147.46.1", "netmask": "255.255.255.0", "network": "10.147.46.0/24", "new_nic": false, "nic_dev_id": 2, "nw_type": "public", "one_to_one_nat": false, "public_ip": "10.147.46.102", "size": "24", "source_nat": true, "vif_mac_address": "06:4a:54:00:00:0e" }, { "add": false, "broadcast": "10.147.46.255", "cidr": "10.147.46.107/24", "device": "eth2", "first_i_p": true, "gateway": "10.147.46.1", "netmask": "255.255.255.0", "network": "10.147.46.0/24", "new_nic": false, "nic_dev_id": 2, "nw_type": "public", "one_to_one_nat": true, "public_ip": "10.147.46.107", "size": "24", "source_nat": true, "vif_mac_address": "06:b5:36:00:00:13" }, { "add": false, "broadcast": "10.147.46.255", "cidr": "10.147.46.108/24", "device": "eth2", "first_i_p": true, "gateway": "10.147.46.1", "netmask": "255.255.255.0", "network": "10.147.46.0/24", "new_nic": false, "nic_dev_id": 2, "nw_type": "public", "one_to_one_nat": true, "public_ip": "10.147.46.108", "size": "24", "source_nat": true, "vif_mac_address": "06:6d:c8:00:00:14" }, { "add": false, "broadcast": "10.147.46.255", "cidr": "10.147.46.111/24", "device": "eth2", "first_i_p": true, "gateway": "10.147.46.1", "netmask": "255.255.255.0", "network": "10.147.46.0/24", "new_nic": false, "nic_dev_id": 2, "nw_type": "public", "one_to_one_nat": true, "public_ip": "10.147.46.111", "size": "24", "source_nat": true, "vif_mac_address": "06:32:90:00:00:17" }, { "add": true, "broadcast": "10.147.46.255", "cidr": "10.147.46.112/24", "device": "eth2", "first_i_p": true, "gateway": "10.147.46.1", "netmask": "255.255.255.0", "network": "10.147.46.0/24", "new_nic": false, "nic_dev_id": 2, "nw_type": "public", "one_to_one_nat": true, "public_ip": "10.147.46.112", "size": "24", "source_nat": true, "vif_mac_address": "06:83:68:00:00:18" } Thanks, Jayapal On Mar 3, 2017, at 10:08 AM, Jayapal Uradi <jayapal.ur...@accelerite.com<mailto:jayapal.ur...@accelerite.com>> wrote: Let me have quick look at my setup and will respond to you. Thanks, Jayapal On Mar 2, 2017, at 3:48 PM, Jeff Hair <j...@greenqloud.com<mailto:j...@greenqloud.com>> wrote: Jayapal, As far as I understand and it (and what I've seen based on some testing), IPs shouldn't be getting reconfigured (and thus arpinged) once PR 1907 is applied. The JSON entry is not removed from the DataBag, but they SHOULD have the "add" property set to false, at least. Can you clarify: Is the problem with 1907 still happening on 1908? This was my original fear, but as far as I can tell in my testing, it's not happening. Jeff *Jeff Hair* Technical Lead and Software Developer Tel: (+354) 415 0200 j...@greenqloud.com<mailto:j...@greenqloud.com> www.greenqloud.com On Thu, Mar 2, 2017 at 4:52 AM, Jayapal Uradi <jayapal.ur...@accelerite.com> wrote: Because of removed ips get configured again on VR, it is giving the perception that PR #1908 is not removing the static nat ips in VR. Thanks, Jayapal On Mar 1, 2017, at 10:12 PM, Will Stevens <wstev...@cloudops.com> wrote: Hey Jeff, We were having this issue as well before we implemented 1907 and we have not had it since. We don't user RvR yet though, so that could be a different story. We had tried a couple other implementations previously and we were still having the issue. So far 1907 has been working without issues for us. We have been running it in production for a couple months now and we were running into the issue you described quite a bit before that. *Will STEVENS* Lead Developer <https://goo.gl/NYZ8KK> On Wed, Mar 1, 2017 at 8:41 AM, Jeff Hair <j...@greenqloud.com> wrote: Yes, i know it's been merged. The problem is that this issue seems to come up "randomly" (of course, nothing is ever really random), and I was wondering if anyone else has run into it. My initial testing of PR 1907 hasn't yielded the issue happening yet, and the only place I've seen it so far is on a router that doesn't have 1907 applied. But I'm not convinced that it won't happen ever after applying 1907... *Jeff Hair* Technical Lead and Software Developer Tel: (+354) 415 0200 j...@greenqloud.com www.greenqloud.com On Wed, Mar 1, 2017 at 1:39 PM, Wei ZHOU <ustcweiz...@gmail.com> wrote: PR 1907 has been merged. You can test with it. 2017-03-01 14:12 GMT+01:00 Jeff Hair <j...@greenqloud.com>: Hi, In the testing of PR 1908 (https://github.com/apache/ cloudstack/pull/1908 ), it has come up that some IPs which are removed from the router get put into the /etc/cloudstack/ips.json data bag with add = True. This causes the IPs to be re-added to the interface and arpinged, breaking connectivity and causing IP conflicts. Does anyone know anything about this? Is it due to old routers that were affected by CLOUDSTACK-9500 (fixed in PR 1907), or is this behavior still actively happening on master? Jeff DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Accelerite, a Persistent Systems business. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Accelerite, a Persistent Systems business does not accept any liability for virus infected mails. DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Accelerite, a Persistent Systems business. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Accelerite, a Persistent Systems business does not accept any liability for virus infected mails. DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Accelerite, a Persistent Systems business. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Accelerite, a Persistent Systems business does not accept any liability for virus infected mails.