12-01-2012 10:19 AM
Hi All,
We have observed from the IIS logs on the internal webservers that loadbalancer is not maintaining session persistence for two specific request for the internal servers.
https://123.xyz.com/Webresource.axd
https://123.xyz.com/ScriptResource.axd
Error
Webresource.axd : 500
Scriptresource.axd: 404
Session persistence is maintained for all other requests hitting loadbalancer.
Issue is observerd on hits for these two specified components. WebResource.axd and ScriptResource.axd are Http Handlers used by ASP.NET and Ajax to add client-side scripting to the outgoing web page.
For e.g /WebResource.axd d=t2GXfySdqWmJ-lZSI0KVbw2&t=634868473645172160 is valid for server 1 and return 200 response but the same request is seen on few other servers where the response is 404 even though load balancer cookie is same. This means that if the request for the both the axd contains a valid decrypter and it connects to the right server then the response seen is 200.
The url passed by the user contains d and t parameters when are unique for each user session.
Solution tried:
Accessed website via another VIP without http redirect rule but could not see difference.
Tried to match machine key across all servers : Failed . Could see the ‘d’ value different for each server.
Load balancer VIP :
x.x.x.x
redirect: http > https
SSL Offload : ON
Poool:
WEB1
WEB2
WEB3
WEB4
WEB5
All servers listening on port 80
sticky config:
sticky ihttp-cookie cookie1 vip-1.1.1.1-80-stickyfarm
cookie insert browser-expire
replicate sticky
serverfarm vip-1.1.1.1_80
sticky http-cookie cookie1 vip-farm:1.1.1.1:443
cookie insert browser-expire
replicate sticky
serverfarm farm:1.1.1.1:443
Has anyone else come across similar issue?
Can you plese check if there is any config on cisco ace that will ensure that session persistence is maintained for these 2 requests.
Thank you for all the help.
regards,
Sangram
Solved! Go to Solution.
12-05-2012 09:27 AM
Hello Sangram,
We would need simultanous packet traces before and after the ACE to get to the root cause of this issue so I would recommend that you open a cisco tac case for more in depth troubleshooing of this issue.
Joel Lamousnery
CCIE R&S - 36768
Engineer, Customer Support
Technical Services
12-05-2012 09:27 AM
Hello Sangram,
We would need simultanous packet traces before and after the ACE to get to the root cause of this issue so I would recommend that you open a cisco tac case for more in depth troubleshooing of this issue.
Joel Lamousnery
CCIE R&S - 36768
Engineer, Customer Support
Technical Services
12-05-2012 09:55 AM
Hi Sangram,
Did you try to use the same sticky-group for both URLs?
---------------------
Cesar R
ANS Team
12-08-2012 02:29 AM
Hi Guys,
Thanks for the response.
The isues was caused by wrong IIS configuration from the release engineer where the ASP was not able to generate unique 'd' and 't' parameters for every unique user request.
Apologies got the trouble.
Thankyou everyone.
regards,
Sangram
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide