[ https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15409211#comment-15409211 ]
ASF GitHub Bot commented on CLOUDSTACK-9317: -------------------------------------------- Github user ProjectMoon commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1623#discussion_r73664374 --- Diff: server/src/com/cloud/network/IpAddressManagerImpl.java --- @@ -1698,6 +1698,22 @@ public String acquireGuestIpAddress(Network network, String requestedIp) { Random _rand = new Random(System.currentTimeMillis()); + /** + * Get the list of public IPs that need to be applied for a static NAT enable/disable operation. + * Manipulating only these ips prevents concurrency issues when disabling static nat at the same time. + * @param staticNats + * @return The list of IPs that need to be applied for the static NAT to work. + */ + public List<IPAddressVO> getStaticNatSourceIps(List<? extends StaticNat> staticNats) { + List<IPAddressVO> userIps = new ArrayList<>(); + + for (StaticNat snat : staticNats) { + userIps.add(_ipAddressDao.findById(snat.getSourceIpAddressId())); + } --- End diff -- This makes sense, yes. Better to have one database query than many. > 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.4#6332)