Forum Discussion

Leslie_South_55's avatar
Leslie_South_55
Icon for Nimbostratus rankNimbostratus
Oct 29, 2007

CR83311 - High CPU with iControl

With a recent upgrade to 9.3 vanilla (no hotfixes applied) our iControl app is causing high cpu spikes, showing on the graph at 90-100%. Support has noted that this is being tracked in CR 83311 and there is currently no fix, but offered this work around:

 

 

"Change the application to capture the BIGIPAuthCookie and then return it in a Cookie header in subsequent requests"

 

 

After chatting with our in-house c guy, it looks like the HTTP request and HTTP responses are not defined in our app, only with what info we get back from the F5; so the question is "how can I specify to catch the BIGIPAuthCookie and then present it with future requests?"

 

 

Thanks

 

-L
dev
devops
iControl
  • Joe_Pruitt's avatar
    Joe_Pruitt
    Oct 31, 2007
    This CR looks to be addressed in 9.4.2. Not sure if you can upgrade to that or not, but the CR notes show that it was verified fix in that release. The CR notes also show an entry from 10/26 that show a merge of this fix was checked into 9.3.1.

     

     

    As for capturing auth cookies, your client application will have to have access to the response HTTP headers, store that cookie value, and then re-add it to the request. Most client toolkits (ie, .Net, Axis, etc) do not have this built in and you have to override some code to be able to do it. That might be a good feature to put in the iControl Assembly someday B-).

     

     

    Anyway, I'm not sure what the status of 9.3.1 is, but you might look into that. Refer to CR 83311-1.

     

     

    -Joe
  • Joe_Pruitt's avatar
    Joe_Pruitt
    Nov 14, 2007
    Not that I know of. I'm not sure if you have access directly to the HTTP headers with SOAP::Lite, but I could be wrong. I'll see what I can find out.

     

     

    -Joe
  • Joe_Pruitt's avatar
    Joe_Pruitt
    Nov 15, 2007
    How are you filing the cookieJar variable? The issue I see with toolkits like this is that there is no concept of "cookies" that go across connections. You'll have to extract the cookies in a response and then manually add them back for future requests. I assume this is what you are doing, but I can't tell for sure. Send me some more code where you extract the cookies into $cookieJar and I'll debug he headers from my side.

     

     

    -Joe
  • Joe_Pruitt's avatar
    Joe_Pruitt
    Nov 15, 2007
    In the SOAP::Lite docs, here's the comments on the arguments to the proxy method:

     

     

    When extra information is needed, it is also passed in the call to this method. Connecting to a server that uses browser cookies for authentication can be done by creating an instance of the HTTP::Cookies class (from the LWP package) and passing it as the value following a key of cookie_jar.

     

     

     

    I did a search and found an example reference for using the cookie_jar parameter.

     

     

    Give this a try:

     

     

    $Failover = new SOAP::Lite
  uri('urn:iControl:System/Failover')
  proxy("https://$hostName:443/iControl/iControlPortal.cgi",
    cookie_jar => HTTP::Cookies->new(ignore_discard => 1));

     

     

    I tested this out and for subsequent requests on the same SOAP::Lite object, it did send the BIGIPAuthCookie on subsequent requests.

     

     

    Let me know if this works for you and I'll work on getting the sample code upgraded to support the auth cookie.

     

     

    -Joe