Forum Discussion
Volker_95568
Nimbostratus
NimbostratusiRule http cookie, persist command, storing/reading connection information
Hi,
I'm back again.
I don't understand the information management behind the persist command.
There is the 'bigpipe' command (b), which shows the information, which is stored.
Then you got the persist command (like DB insert/select/update) which will most probably store information about a connection. If the persist command stores information it will do that by using a key (cookie) putting a timestamp on the record.
I. What I want to understand, are the circumstances under which the BigIP stores information.
Persist ... (plus configuration settings, which guard the persist command)
II. Again I want to understand, how I can use the information.
Scenario:
I. Connection gets opened on BigIP Resource
Resource uses iRule command persist ... to store Cookie related connection information.
II. Connection gets opened on another BigIP Resource
Resource uses iRule command lookup ? to read Cookie related connection information and
to obey these connection information, redirect to the given server.
Logging (But I really don't know what I can do with persist/lookup/config ...)
[230 is the physical address of BigIP]
Good Case
Apr 30 18:33:31 tmm tmm[1584]: Rule connection_logging : Connection von 80.187.40.11 auf 192.168.1.232 : 8000
I. BigIP should write, where to go with key1: 192.168.1.150
Apr 30 18:33:32 tmm tmm[1584]: Rule jsession : Connection 192.168.1.231:8080 <- 192.168.1.150:8928, Cookie:key1
Apr 30 18:33:33 tmm tmm[1584]: Rule jsession : Connection 192.168.1.230:8928 -> 192.168.1.150:8080, Cookie:
II. BigIP should read, where to go with this cookie key1: 192.168.1.150
Apr 30 18:34:03 tmm tmm[1584]: Rule jsession : Connection 192.168.1.231:8010 <- 192.168.1.150:3160, Cookie:key1
Good case, connection gets back to 192.168.1.150
Apr 30 18:34:03 tmm tmm[1584]: Rule jsession : Connection 192.168.1.230:3160 -> 192.168.1.150:8050, Cookie:
Bad Case
Apr 30 18:36:33 tmm tmm[1584]: Rule connection_logging : Connection von 80.187.40.210 auf 192.168.1.232 : 8000
I. BigIP should write, where to go with key1: 192.168.1.4
Apr 30 18:36:34 tmm tmm[1584]: Rule jsession : Connection 192.168.1.231:8080 <- 192.168.1.4:54209, Cookie:key1
Apr 30 18:36:34 tmm tmm[1584]: Rule jsession : Connection 192.168.1.230:54209 -> 192.168.1.150:8080, Cookie:
II. BigIP should read, where to go with this cookie key1: 192.168.1.4
Apr 30 18:36:59 tmm tmm[1584]: Rule jsession : Connection 192.168.1.231:8010 <- 192.168.1.150:2622, Cookie:key1
Connection goes out of sight ...
Apr 30 18:36:59 tmm tmm[1584]: Rule jsession : Connection 192.168.1.230:2622 -> 192.168.1.150:8050, Cookie:
hoolioCirrostratus
Hi,
Are you referring to cookie insert persistence? If so, the only place persistence data is stored is in the persistence cookie sent to the client in responses. If you have the timeout set to 0 (session cookie), the BIG-IP will set the cookie on the first response to a request which doesn't contain a persistence cookie. If the timeout is set to something other than 0 (persistence cookie), the BIG-IP will set the persistence cookie on every response to the client.
Deb added a Codeshare example which logs the persistence cookie values. That could be one way to determine what is failing with the iRule.
Persistence Cookie Logger
http://devcentral.f5.com/wiki/default.aspx/iRules/Persistence_Cookie_Logger.html
If you would like more detailed suggestions, can you post the iRule you're testing along with details on the persistence profile(s) you have enabled on the VIP?
Thanks,
Aaron
Volker_95568Hi,
my iRule only logs Request and Responses. I pick the connection information from the environment of the HTT_Request/Response.
The iRule (jsession) is inside the following BigIP Settings:
My default persistence profile is based on the "cookie" profile.
I added "httpclass" and "oneconnect".
Last but not least I configured my own "http" profile.
This is the iRule to log events and pick up the cookie. The persist is just inserted by me, its not usable, because there should be
2 iRules, (if it could not be handled implicit by the configuration.)
1. iRule reacting on the HTTP_REQUEST by storing connection information.
2. iRule reaction on the HTTP_RESPONSE by reading connection information.
when HTTP_REQUEST {
set pers_cookie [HTTP::cookie "JSESSIONID"]
set destination [IP::remote_addr]
set source [IP::local_addr]
set d_port [TCP::remote_port]
set s_port [TCP::local_port]
log local0. "Connection $source:$s_port <- $destination:$d_port, Cookie:$pers_cookie"
if { [HTTP::cookie exists "JSESSIONID"] } {
persist uie [HTTP::cookie "JSESSIONID"]
} else {
set jsess [findstr [HTTP::uri] "JSESSIONID" 11 ";"]
if { $jsess != "" } {
persist uie $jsess
}
}
}
when HTTP_RESPONSE {
set pers_cookie [HTTP::cookie "JSESSIONID"]
set destination [IP::remote_addr]
set source [IP::local_addr]
set d_port [TCP::remote_port]
set s_port [TCP::local_port]
log local0. "Connection $source:$s_port -> $destination:$d_port, Cookie:$pers_cookie"
if { [HTTP::cookie exists "JSESSIONID"] } {
persist add uie [HTTP::cookie "JSESSIONID"]
} else {
set jsess [findstr [HTTP::payload] "JSESSIONID" 11 ";"]
if { $jsess != "" } {
persist uie $jsess
log local0. "Findstr cookie $source:$s_port <- $destination:$d_port, Cookie:$jsess"
}
}
}- Volker_95568This problem is solved with another approach.
It is not possible to 'share' information between virtual hosts on a Big IP.
Shared resources (memory, objects) would decrease performance and would make the load balancing application unmananageable.
Cheers,
Volker. - hoolioHi Volker, sorry I missed your last post here. I'm not sure what you meant in the last post by saying you had to have two iRules: one for the HTTP_REQUEST and one for HTTP_RESPONSE. You could combine both events in a single rule. Either way, as long as they're associated with the same VIP, they could access the same session data. I'm not sure what you mean by 'is it not possible to share information between the virtual hosts on a BIG-IP'.
Were you able to solve the issue you were seeing in another way?
Aaron - Volker_95568Hi Aaron,
in our case the possible solution was: VIP 8080 would tell VIP 8010 what to do.
We didn't understand the F5:
The iRules are bound to a VIP and they get their context from VIP.
It is not possible to share data (objects) between VIP 8080 and VIP 8010 on an F5.
VIP 8080 cannot tell VIP 8010, what to do. We had to find another solution.
I've misled you in my previous questions, because my understanding was wrong.
(Especially HTTP_Request, HTTP_Response) - hoolioYou can share data between VIPs using the session table. If you use the 'any virtual' option when adding the session table entry (Click here), that entry is accessible from an iRule on any virtual server.
Aaron