Re: Removed IPs with add = true in /etc/cloudstack/ips.json on router

[Jayapal Uradi]

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:  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 
> 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 
> 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
www.greenqloud.com

On Thu, Mar 2, 2017 at 4:52 AM, Jayapal Uradi 
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  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 

Re: Removed IPs with add = true in /etc/cloudstack/ips.json on router

[Jayapal Uradi]

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  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
> www.greenqloud.com
>
> On Thu, Mar 2, 2017 at 4:52 AM, Jayapal Uradi 
> 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  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
>>>
>>> 
>>>
>>> On Wed, Mar 1, 2017 at 8:41 AM, Jeff Hair  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  wrote:

> PR 1907 has been merged. You can test with it.
>
>
> 2017-03-01 14:12 GMT+01:00 Jeff Hair :
>
>> 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.

Re: Removed IPs with add = true in /etc/cloudstack/ips.json on router

[Jeff Hair]

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
www.greenqloud.com

On Thu, Mar 2, 2017 at 4:52 AM, Jayapal Uradi 
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  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
> >
> > 
> >
> > On Wed, Mar 1, 2017 at 8:41 AM, Jeff Hair  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  wrote:
> >>
> >>> PR 1907 has been merged. You can test with it.
> >>>
> >>>
> >>> 2017-03-01 14:12 GMT+01:00 Jeff Hair :
> >>>
>  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.
>

Re: Removed IPs with add = true in /etc/cloudstack/ips.json on router

[Jayapal Uradi]

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  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
>
> 
>
> On Wed, Mar 1, 2017 at 8:41 AM, Jeff Hair  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  wrote:
>>
>>> PR 1907 has been merged. You can test with it.
>>>
>>>
>>> 2017-03-01 14:12 GMT+01:00 Jeff Hair :
>>>
 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.

Re: Removed IPs with add = true in /etc/cloudstack/ips.json on router

[Will Stevens]

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



On Wed, Mar 1, 2017 at 8:41 AM, Jeff Hair  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  wrote:
>
> > PR 1907 has been merged. You can test with it.
> >
> >
> > 2017-03-01 14:12 GMT+01:00 Jeff Hair :
> >
> > > 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
> > >
> >
>

Re: Removed IPs with add = true in /etc/cloudstack/ips.json on router

[Wei ZHOU]

Jeff,

We had several VR issues in the testing of 4.7.1, including this one. We
fixed it by removing unused IPs from ips.json.
As there are lot of changes between 4.7.1 and master, I do not know the
current status in master/4.10
PR 1907 seems to fix this issue (not tested). There might be other issue
caused by unused IPs in ips.json.

-Wei

2017-03-01 14:41 GMT+01:00 Jeff Hair :

> 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  wrote:
>
> > PR 1907 has been merged. You can test with it.
> >
> >
> > 2017-03-01 14:12 GMT+01:00 Jeff Hair :
> >
> > > 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
> > >
> >
>

Re: Removed IPs with add = true in /etc/cloudstack/ips.json on router

[Jeff Hair]

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  wrote:

> PR 1907 has been merged. You can test with it.
>
>
> 2017-03-01 14:12 GMT+01:00 Jeff Hair :
>
> > 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
> >
>

Re: Removed IPs with add = true in /etc/cloudstack/ips.json on router

[Wei ZHOU]

PR 1907 has been merged. You can test with it.


2017-03-01 14:12 GMT+01:00 Jeff Hair :

> 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
>

Removed IPs with add = true in /etc/cloudstack/ips.json on router

[Jeff Hair]

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