Forum Discussion
mpromny_136509
Nimbostratus
NimbostratusHow LTM attaches information about node to JSessionsID ?
Hi all,
I'd like to ask whether you could explain me how LTM attaches information about node to JSessionsID used in cookie.
Introduction:
-
we have pool SRV_POOL: -SRV1 10.10.10.1 -SRV2 10.10.10.2 -SRV3 10.10.10.3 (new)
-
system creates cookies with JSessionID
ISSUE:
Recently we've added additional node to our pool. Issue occurs when request goes to last node and we get: C73AA9C0CC0F1045667015AF8F281AD4.node1 instead of node3
Logs:
Rule /Common/Node3Log : 10.7.255.251:16966: Used persistence record from cookie. Existing key? /Common/SRV_POOL 10.10.10.3 8080 Rule /Common/Node3Log : 10.7.255.251:16965: Request to .../soria/images/tooltipConnectorRight.gif with cookie: C73AA9C0CC0F1045667015AF8F281AD4.node1
Question:
Would you please explain me how LTM assignes nodes' information to JSession?
Thank you in advance, Mateusz
Hello,
I am not sure how you have persistence configured on the F5 but it sounds like the session persistence table needs to be investigated. Use something similar to the following command to check.
tmsh show /ltm persistence persist-records all-propertiesIf your server is generating cookies then then above command can help you to understand which cookie is being persisted to each server.
What is the lifetime of your cookies that the server generates?
Christian
Thanks. So looking at the output do you have a cookie persistence or a universal persistence profile enabled on the virtual server? Also do you have any iRules enabled influencing the persistence?
mpromny_136509Hi Christian,
We have universal and cookie because:
iRULE - uie
virtual - cookie
Virtual server configuration:
ltm virtual PI-SSL {
destination 10.59.20.10:https
fallback-persistence PI_Tomcat-src
ip-protocol tcp
mask 255.255.255.255
persist {
PI_COOKIE {
default yes
}
}
pool SRV_POOL
profiles {
PI-HTTPS-NEW.app/PI-HTTPS-NEW_http_profile { }
PI-HTTPS-NEW.app/PI-HTTPS-NEW_lan-optimized_tcp_profile {
context serverside
}
PI-HTTPS-NEW.app/PI-HTTPS-NEW_oneconnect { }
PI-HTTPS-NEW.app/PI-HTTPS-NEW_wan-optimized_tcp_profile {
context clientside
}
PI-requestLog { }
PI_SSL {
context clientside
}
analytics { }
}
rules {
PI_X-Forward
PI_JSESSION_ID
}
snat automap
source-port change
vlans-disabled
}IRULE:
when HTTP_REQUEST {
if { [HTTP::cookie exists "JSESSIONID"] } {
persist uie [HTTP::cookie "JSESSIONID"] 500
} else {
set jsess [findstr [HTTP::uri] "JSESSIONID" 11 ";"]
if { $jsess != "" } {
persist uie $jsess 500
}
}
}
when HTTP_RESPONSE {
if { [HTTP::cookie exists "JSESSIONID"] } {
persist add uie [HTTP::cookie "JSESSIONID"] 500
}
}OK thanks, and is this BIG-IP running in a HA cluster?
fpaj_137139Hi, I'm working on this issue with Mateusz. It is standalone box, no HA cluster.
fpaj
- mpromny_136509
Nope, we have only one LTM here.
- Kevin_Stewart
Employee
If I may add:
-
The universal persistence iRule (I'm assuming "PI_JSESSION_ID" in this case), should be applied to the universal persistence profile, not the VIP.
-
You wouldn't have two persistence profiles then, either universal or cookie.
-
If you can support cookies, and there's no specific technical reason to rely on the JSESSIONID from the server, I would recommend standard LTM Cookie persistence. You can change the name of the cookie if you need to, but it is easily the most reliable persistence method.
-
