[
https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15887950#comment-15887950
]
ASF GitHub Bot commented on CLOUDSTACK-9317:
--------------------------------------------
Github user ProjectMoon commented on the issue:
https://github.com/apache/cloudstack/pull/1908
We have been testing this PR internally for some time now, and we have seen
some strange `arping` issues. We have seen that `/etc/cloudstack/ips.json` on
the router has IPs on them that aren't cleaned up. Since #1908 is now merged,
I'm worried that the changes in this PR will not play well with #1908.
Specifically, we have seen that IPs left over in the `ips.json` file can be
stuck on `"add": true` even if the IP is no longer on the account.
Thus, the code that was added in PR 1907 concerns me:
```
if not address['add'] and not ip.configured():
logging.info("Skipping %s as the add flag is set to %s " %
(address['public_ip'], address['add']))
continue
```
The `if` condition fails in a case we've been investigating. Because our IP
is `"add": true`, but `configured()` returns `False`, the IP gets reconfigured
anyway. This doesn't add the IP to the router's interface, but it _does_ run an
`arping` command (see CsAddress.py). Essentially, if this PR is merged as-is,
we might wind up with a regression on CLOUDSTACK-9500.
I will do a bit of manual testing combining both #1908 and #1907 to see
what happens. It may just be that after restarting the network (and thus
cleaning the router), these issues will vanish.
> Disabling static NAT on many IPs can leave wrong IPs on the router
> ------------------------------------------------------------------
>
> Key: CLOUDSTACK-9317
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, Virtual Router
> Affects Versions: 4.7.0, 4.7.1, 4.7.2
> Reporter: Jeff Hair
>
> The current behavior of enabling or disabling static NAT will call the apply
> IP associations method in the management server. The method is not
> thread-safe. If it's called from multiple threads, each thread will load up
> the list of public IPs in different states (add or revoke)--correct for the
> thread, but not correct overall. Depending on execution order on the virtual
> router, the router can end up with public IPs assigned to it that are not
> supposed to be on it anymore. When another account acquires the same IP, this
> of course leads to network problems.
> The problem has been in CS since at least 4.2, and likely affects all
> recently released versions. Affected version is set to 4.7.x because that's
> what we verified against.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
