wlnode function

What would be really interesting is to figure out if the client browser doesn't accept the cookie, to write the JSessionID to the URL as part of the query string. There are folks that turn off cookies in their browser, so in this instance, how could we ensure they persist to the same SessionID but not in the browser, in the URL. You capture this in the HTTP_REQUEST portion of the code, where you set the jsess variable, which it looks for the ID in the URL, question is, how does it get there?

 

 

I know weblogic I believe at times will default the ID to the URL if it knows the browser blocks it, in which case you'd see that jsess findstr work great, but what about other servlet engines like JBoss?

 

 

I'm going to play around with this iRule and see if I can figure out how to force it into the URL, just to see if it's possible (meaning, the client denies the cookie, so default to the URL).

We have solved this issue by using the following rule, there is no persistence in the persistence table, but so far it appears to work based on the logging info and the server assigned

when HTTP_REQUEST {
set reqpath [HTTP::path]
log local0. "HTTP Request path is $reqpath"
if { [HTTP::cookie exists "ltmcookie"] }{
log local0. "Cookie found"
HTTP::cookie decrypt "ltmcookie" "ltmcookiepassword"
log local0. "Cookie decrypted"
set vipid [lindex [HTTP::cookie ltmcookie] 0]
set poolid [lindex [HTTP::cookie ltmcookie] 1]
set serverid [lindex [HTTP::cookie ltmcookie] 2]
set portid [lindex [HTTP::cookie ltmcookie] 3]
use pool $poolid member $serverid $portid
log local0. "Sending request to pool $poolid, member $serverid, port $portid"
persist cookie
log local0. "Cookie persist instruction passed"}
else {
log local0. "Cookie NOT found"
use pool pool_my-http-pool
}
}
when HTTP_RESPONSE {
log local0. "HTTP Response path is $reqpath"
if { $reqpath eq "/"} {
HTTP::cookie insert path / name ltmcookie value [concat [virtual name] [LB::server]]
log local0. "Creating cookie"
HTTP::cookie encrypt "ltmcookie" "ltmcookiepassword"
log local0. "Encrypting cookie"
}
elseif { $reqpath eq "/SEUILibrary/controller/Customer:Enter"} {
HTTP::cookie insert path / name ltmcookie value [concat [virtual name] [LB::server]]
log local0. "Creating cookie"
HTTP::cookie encrypt "ltmcookie" "ltmcookiepassword"
log local0. "Encrypting cookie"
}
elseif { $reqpath eq "/SEUILibrary/controller/checkout.workflow:StartCheckout"} {
HTTP::cookie insert path / name ltmcookie value [concat [virtual name] [LB::server]]
log local0. "Creating cookie"
HTTP::cookie encrypt "ltmcookie" "ltmcookiepassword"
log local0. "Encrypting cookie"
}
}

glad to hear it! You won't see cookie persistence in the table. Because all the information needed to persist is in the cookie, there is no need to build a table for it.

 

 

BTW, the persist cookie command shouldn't be necessary because you are specifying where the traffic is going in this statement:

 

 

use pool $poolid member $serverid $portid

Functionally, this rule is working as expected, but it's taking a toll on the CPU. I am running this on a 6400 with 2 procs, and 4 GB of RAM, ver 9.2.3 build 142, and when our App Team runs a load of 400 users against the VS, the TMM cpu runs at 50%; I have seen the TMM CPU hit 100% when they throw 800+ users at it.

 

 

Along with this rule, I am running a HTTP URI completion rule as well as a HTTP to HTTPS redirect rule; the HTTPS VS uses the same pool as the HTTP VS, but I am terminating SSL on the LTM, so I thought this was the best way to handle it.

 

 

Any idea why my CPU is getting hit so hard?

You can use the timing on command to help isolate. Try not encrypting/decrypting the cookie and see what that does to your performance.

How many SSL TPS licenses are you licensed for? If you are doing 800+ but only the default SSL license, I have seen v9 and v4 tank because you hit the SSL TPS limit (e.g. how many net new parallel SSL connections are allowed to be created per second).

 

 

Just a thought. On a pair of 6400's you shouldn't have any issues with the irule you just sent through, encrypting and decrypting the cookie shouldn't take a toll on pair of 6400's, those are some heavy duty appliances.

 

 

-Wes

have the performance pack which includes 5000 TPS, plus the caching and compression. F5 has told me that the iRule could be causing the issue. So I am rolling back to Cookie Insert prsistence to see if I can simplify things. I did disable the encryption of the cookike and F5 has told me that this is a know issue and there is a CR (CR59772)to fix this.

 

 

I am beginning to think that 9.2.3 has bugs in it, because I periodically see reference's in my log pointing to rules or pools that I have deleted from the config, and the answer is 'bigstart restart'

 

 

I've experienced the last as an artifact of connection management when editing the config file directly, then re-loading.

 

Old instances of the iRule will still be in effect for connections begun before the iRule was edited.

 

 

To avoid that, I prefer to edit iRules in the iRules Editor (Click here)(or you can edit in the GUI).

 

 

If you really must edit the bigip.conf file directly, as an alternative to "bigstart restart tmm", you can instead run "bigpipe conn delete" to clear the connection. ("b conn help" for syntax)

 

 

HTH

 

/deb