stickiness when services are of type redirect?

[clayton-price]

I have a site that accomplishes ssl persistence via the use of redirects. This is outlined in

http://www.cisco.com/en/US/products/hw/contnetw/ps789/products_configuration_example09186a0080094068.shtml

This works great, however my problem is that they are now needing to direct users back to the VIP (which contains the two services of type redirect) in order to submit some information back to the application. I need to make sure these users get redirected to the same url that they were originally redirected towards. I would have thought enabling advanced-balance sticky-srcip would have worked, however users are still round robined between the two redirect services.

Is what I'm wanting to do possible?

Thanks!

[stevehall]

I am not sure why they need to be re-directed again in order to submit the information. If they remain on the server they are redirected to (ww1 for example) are they not able to submit the information?

Are they going to a separate site and the separate site needs to send them back to the site being "redirected"?

The "sticky-srcip" should work if the source IP of the client has not changed. Can you confirm that the source IP of the client has not changed?

Also, you can check to see the size of the sticky table with the following:

CSS501-2# llama

CSS501-2(debug)# show sticky-table all

ALL Sticky List on Slot 1, subslot 1:

Entries for page 1.

Entry Hash Rule Rule Srv Srv Time(Sec) Hit Col Elem Inact

Number Value Indx State Indx State Elapsed Cnt Cnt Type Cfg(Min)

------------------------------------------------------------------------------

Total number of entry found is 0.

CSS501-2(debug)#

I don't have any entries there, but that is where you would see them. They would be hashed, so the IP is not easy to figure out. you can see which services have which index numbers from a "show service"

-Steve

[clayton-price]

Thanks for the response. I agree with you on wondering why they need to hit the redirect VIP again. They want to have the code send them back to the redirect VIP incase there is a problem with the node they were redirected to. This would allow the application to work, however the users session ID would be lost and they would need to log in to the new server.

Anyway's I have tested from the same source IP and get redirected to both nodes in an exact round robin fashion.

As a work around, I'm thinking of adding the other service as a sorry service to the 443 content rules.

Clayton

[stevehall]

ok, it looks like they are worried about the "bookmark problem". If you want to use source IP sticky on the redirects, you might as well not use redirects, and use source IP sticky with the SSL services.

if you send the output of "show run owner" and "show run service" I can take a look at it...

-Steve

[clayton-price]

I think I have convinced myself to use the sorry server under each 443 content rule. That should accomplish what we are trying to do. You raise a good point with the persistence on the redirect rule.

From my perspective it looks like persistence won't work if the services are of type redirect. It is no longer an issue for me, but if you wish to investigate, I can send you my configs.

Thanks!