Forum Discussion
Help on persist and/or persist add
Hello
I am newbie to F5’s and LTM’s and trying to use Universal persistence to have clients persist to a server if the serve has field of ID= and then two characters e.g. ID=25. If the field is not present then persistence is not required.
Trying to understand difference between the two following iRules, which appear to do what I need, but not sure which is best approach.
iRule 1 – Just using the HTTP Request
when HTTP_REQUEST {
set sessid [findstr [HTTP::uri] "ID=" 3 2]
if { $sessid != "" } {
persist uie $sessid
}
}
iRule 2 – Checking HTTP Response and Request.
when HTTP_RESPONSE {
set sessid [findstr [HTTP::uri] "ID=" 3 2]
if {$sessid != ""} {
persist add uie $sessid
}
}
when HTTP_REQUEST {
set sessid [URI::query [HTTP::uri] "ID="]
if {$sessid != ""} {
persist uie $sessid
}
}
Could somebody be kind enough to explain the difference and merits of each?
2 Replies
- Kevin_Stewart
Employee
Think of it like a database table. Each of the persistence options (except cookie) stores some information about the client and chosen server in a record in that table (in memory on the BIG-IP), so that when the client returns with a new request the server can identify the client, look up the table entry, and load balance accordingly. Source and destination address persistence use the client's source or server's destination address, respectively, while universal persistence is basically an open table that you can store anything in. The first iRule above looks for an ID value in the request URI and load balances that based on a match in the uie table (universal inspection engine). But wait. When did a value ever get stored in that table? In the second iRule, the HTTP_RESPONSE is looking for an ID in the URI, but there's not going to be a URI in a response, so that persist add is not going to happen and so you're back to looking for a persistence record in the request that never exists. You can verify all of this by looking at persistence records with tmsh:
tmsh show ltm persistence persist-recordsUltimately for universal persistence to be effective, you need the server to send something that you can grab in a response, and that the client will transmit back in every request. This is why cookie persistence is usually the best choice, because it's basically automatic for any browser-based application.
- Paul_Brand_2026
Nimbostratus
Hi Kevin
Thanks for the answer. Bit clearer now. I believe the session ID is sent in Location field, but still awaiting confirmation. Assuming it is would the below be a good approach to capture the session in the response and check requests.
when HTTP_RESPONSE { if {[HTTP::header exists Location]} { get next 2 characters after ID= and assign value to parameter sessid set sessid [findstr [HTTP::header Location] "ID=" 3 2] If value for sessid is not empty add a persistance entry if { $sessid != "" } { persist add uie $sessid 600 log local0. "[IP::client_addr]:[TCP::client_port], Session ID: $sessid, created persist record: [persist lookup uie $sessid]" } else { log local0. "[IP::client_addr]:[TCP::client_port], No Session ID" } } } when HTTP_REQUEST { if { [HTTP::uri] contains "ID=" } { get next 2 characters after ID= and assign value to parameter sessid set sessid [findstr [HTTP::uri] "ID=" 3 2] If value is not empty then persist on the session ID if { $sessid != "" } { persist uie $sessid } if value is empty then no persistence else { persist none } } }
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com