[
https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15958602#comment-15958602
]
ASF GitHub Bot commented on CLOUDSTACK-9317:
--------------------------------------------
Github user jayapalu commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1908#discussion_r110111189
--- Diff: server/src/com/cloud/network/router/CommandSetupHelper.java ---
@@ -848,13 +849,37 @@ public int compare(final PublicIpAddress o1, final
PublicIpAddress o2) {
associatedWithNetworkId = ipAddrList.get(0).getNetworkId();
}
+ // for network if the ips does not have any rules, then only
last ip
+ List<IPAddressVO> userIps =
_ipAddressDao.listByAssociatedNetwork(associatedWithNetworkId, null);
+
+ int ipsWithrules = 0;
+ int ipsStaticNat = 0;
+ for (IPAddressVO ip : userIps) {
+ if ( _rulesDao.countRulesByIpIdAndState(ip.getId(),
FirewallRule.State.Active) > 0 ) {
+ ipsWithrules++;
+ }
+
+ // check onetoonenat and also check if the ip "add":false.
If there are 2 PF remove 1 static nat add
+ if (ip.isOneToOneNat() && ip.getRuleState() == null) {
--- End diff --
In this case rule state is not set. It is null. I will improve the comment
> 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)