You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cloudstack.apache.org by "Filipe Pires (JIRA)" <ji...@apache.org> on 2014/06/19 16:18:24 UTC

[jira] [Created] (CLOUDSTACK-6944) Enable static NAT synchronous call failure.

Filipe Pires created CLOUDSTACK-6944:
----------------------------------------

             Summary: Enable static NAT synchronous call failure.
                 Key: CLOUDSTACK-6944
                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6944
             Project: CloudStack
          Issue Type: Bug
      Security Level: Public (Anyone can view this level - this is the default.)
          Components: API, Management Server
    Affects Versions: 4.3.0
         Environment: XenServer 6.2
            Reporter: Filipe Pires


Hi,

During the setup process of a network, I've noticed a gradual latency increase in the response time of the synchronous enableStaticNat calls.
The last calls actually fail after one minute stating that the static NAT rule already exists.

Bellow are the specific times of both calls and responses from the log, which follows attached:
17:32:55,332 - Associate IP address request;
17:32:55,749 - IP address successfully associated;
17:32:56,788 - Secondary IP address for NIC request;
17:32:56,838 - Secondary IP address allocated successfully;
17:32:57,894 - Enable static NAT request;
17:32:58,084 - Applying IP association in network;  ?
17:33:57,964 - Second enableStaticNat call;  ?
17:33:57,996 - Failed to enable static nat ip address is already associated;  ?
17:34:05,288 - Finished the entire public IP addresses re-association;
17:34:05,291 - Sets the static NAT rule;
17:34:05,932 - Rule successfully set;


It appears that once the enableStaticNat method is called, all the existing public IP addresses are re-associated for some reason. Considering that at this point the network has more than 100 public IP addresses, this process consumes a large amount of time and it seems redundant, unless there's a reason to re-assign all the existing addresses which were already assigned to the network.

There's also a second enableStaticNat call which doesn't appear to be triggered by the user. The response to this call, which reports a failure, actually makes the user's initial request to fail.

Regards,
Filipe Pires.



--
This message was sent by Atlassian JIRA
(v6.2#6252)