Options
Sticky sessions cookie issue
PjarInk
Member ✭
Hello
I have an issue with sticky sessions, currently we're using a cookie set by the AX on http-request, the issue I have (it's a webshop) is that upon checkout, the store switches from http to https and thus we get a new cookie and there's a high probability that the shopping cart is lost due to server switch.
This is one possible solution: https://www.a10networks.com/vadc/index.php/forums/topic/aflex-for-individual-server-cookie-persist/
Though I don't see how it would work, what makes it so that the AX knows what server to keep track of with that http-response cookie? (We already use JSESSIONID for other stuff).
Another solution I thought of is to somehow create the https-cookie upon the first http-request.
Any ideas/thoughts?
I have an issue with sticky sessions, currently we're using a cookie set by the AX on http-request, the issue I have (it's a webshop) is that upon checkout, the store switches from http to https and thus we get a new cookie and there's a high probability that the shopping cart is lost due to server switch.
This is one possible solution: https://www.a10networks.com/vadc/index.php/forums/topic/aflex-for-individual-server-cookie-persist/
Though I don't see how it would work, what makes it so that the AX knows what server to keep track of with that http-response cookie? (We already use JSESSIONID for other stuff).
Another solution I thought of is to somehow create the https-cookie upon the first http-request.
Any ideas/thoughts?
0
Comments
I believe that should do the trick.
Kind regards,
Thomas
I am on version 2.7.1, cookie persistence, match type and change that from port to server.
BR
Thomas
Cookie persistance is on match service group, server and not on port.
I'm in quite a bind here.
Are both services set to use match type service?
Good luck,
Thomas
Mischa: Not using aflex, it's a cookie persistance template at the moment, though I linked to that aflex as I think it's a possible solution, but I want to understand how it works, because to my eyes all that script does is to check if there is a cookie and then save the info, I don't see any connection between that info and which server to send the client to.
On the incoming client request a server is selected based on the load balancing method you have specified. One the server is selected a cookie is inserted, to the client only, which contains a hash of the destination server. Any subsequent request will be send to this server as long as the cookie is present.
The different match types will tell us for which requests we would use the same server.
When the match type is port we will only forward requests to the specific port to which the template is applied. Which can mean that request via port 80 and port 443 will end up at different serves.
By using match-type server you can prevent this.
The cookie template will need to look something like:
slb template persist cookie tp-cookie-persist match-type serverWithout an expire the cookie will be removed as soon as the browser closes.
This template needs to be applied to both ports, 80 and 443.
Hope this helps.
My guess is that we have either done something wrong in the server group/virtual server or there's a bug in the gui showing us wrong information (match type server set, but not effective).
Could you go through how it should be set up or point me to a resource with instructions? Because what I have available today is not entirely logical or correct it seems.
1) Create an cookie persist template as mentioned.
2) Apply it to the virtual server ports.
3) Done...
But in order to do proper trouble shooting, would you be able to supply the running config or show tech?
2 service groups, app:80 and app:443, 1 virtual server pointing port 80 and 443 to respective service group. 2 virtual service, 80 and 443, both have the same cookie persist template.
Most of the settings are default.
Where are you terminating the SSL session? On the AX or the Server?
No idea if you can PM me through this forum, but you can drop me an email on mpeters [at] a10networks [dot] com
I thought we had something wrong there, I will test and configure both ports on one service group! Thanks.
The application is probably doing the redirect when it's not receiving traffic in port 443.
What we see right now is that when you open the site (http) the request comes in on 8080 to the servers. It's not encrypted between the AX and the servers since the AX is terminating the SSL.