ASF GitHub Bot commented on CLOUDSTACK-9317:

Github user ProjectMoon commented on a diff in the pull request:

    --- 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 --
    Similar to the comments about checking if `lastIp` isn't null, I find that 
checking rule state to be null is a bit ... obscure. What is null supposed to 
mean in this context? It seems the `rule_state` column is only changed to 
`Releasing` when releasing an IP and nothing else. I guess that's intentional?

> 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

Reply via email to