cisco ace Load balancer not maintaining session persistence

[sangram palande]

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

[jlamousn · Accepted solution]

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

[Cesar Roque]

Hi Sangram,

Did you try to use the same sticky-group for both URLs?

---------------------
Cesar R
ANS Team

[sangram palande]

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