Good morning all. I am migrating from an F5 to Stingray and am having some ASP.net SessionID problems. On the F5 is was able to write an iRule (See below) and then use the Universal persistence. I am trying to duplicate this on the StingRay. Could someone please give me a little guidance?
F5 iRule:
when RULE_INIT {
set ::debug 0
}
when HTTP_REQUEST {
set cli [IP::remote_addr]:[TCP::remote_port]
set SessionId [HTTP::cookie ASP.NET_SessionId]
if {$::debug}{log local0. "Client: $cli Request SessionId: >$SessionId<"}
if { $SessionId != "" } { persist uie $SessionId 1800 }
}
when LB_SELECTED {
if {$::debug}{log local0. "Client: $cli LB to: [LB::server addr]"}
}
when HTTP_RESPONSE {
set SessionId [HTTP::cookie ASP.NET_SessionId]
if {$::debug}{log local0. "Client: $cli Response SessionId: >$SessionId<"}
if { $SessionId != "" }{ persist add uie $SessionId 1800 }
}
Thanks.
Solved! Go to Solution.
Hi Arnold,
If the ASP.NET sessions persistence is not working as expected then I would suggest you open a support ticket. It is designed specifically to track ASPSESSIONID and ASP.NET_SessionId cookies without the need for a TrafficScript rule. Can I ask you to elaborate on what you mean by "not working as anticipated"?
In order for it to work then your Virtual Server must be set to the HTTP protocol. It will not work with SSL Pasthrough. If the service is SSL, then you must use SSL Termination on the Stingray.
It could also be filling up the ASP Session cache if you have a large number of sessions. You may need to tune the global setting asp_cache_size. You can find this under System -> Global Settings -> Cache Settings.
Cheers,
Mark
Hi Arnold,
Is there a reason why you are not using the built-in ASP.NET Session Persistence class? in STM you can simply create a new persistence class, set the type to ASP.NET and then apply the class to the Pool. Have you tried this?
Cheers,
Mark
Mark,
Thank you for your comment. I am testing that now. I did not see a lot of documentation on this. So I am trying to look at my alternatives.
We have tested the built-in ASP.NET Session Persistence class and it is not working as anticipated. Does anyone else have any suggestions?
Hi Arnold,
If the ASP.NET sessions persistence is not working as expected then I would suggest you open a support ticket. It is designed specifically to track ASPSESSIONID and ASP.NET_SessionId cookies without the need for a TrafficScript rule. Can I ask you to elaborate on what you mean by "not working as anticipated"?
In order for it to work then your Virtual Server must be set to the HTTP protocol. It will not work with SSL Pasthrough. If the service is SSL, then you must use SSL Termination on the Stingray.
It could also be filling up the ASP Session cache if you have a large number of sessions. You may need to tune the global setting asp_cache_size. You can find this under System -> Global Settings -> Cache Settings.
Cheers,
Mark