Forum Discussion
レザ
Cirrus
CirrusUsing reselect method to keep http session persistence
Hi, I have two http servers behind a specific VIP, i'm using cookie method for persistency which working fine, The problem I have is that when one of the my pool members goes down, the users who we...
レザCirrus
CirrusHello 🙂
Both virtual server and pool members are on same subnet, and service port is 80 (HTTP)
for example:
Virtual Server is: 192.168.23.254
Server1: 192.168.23.180
Server2: 192.168.23.181
Hello,
you are right, you need to disable both translation to use this option based on the below article.
Reselect option is only appropriate for:
- Virtual servers with address and port translation disabled
- Transparent pool members, such as firewalls, routers, proxy servers, and cache servers
https://support.f5.com/csp/article/K15095
It actually doesn't matter for the port translation. But regarding the address translaiton, the service will stop working because the address must be translated to the pool member.
So based on this, unfortunately, i think you will not be able to use the reselect option.
- Mike757
MVP
Forgive me if I'm reading this wrong, but Isn't everyone forgetting a little thing? Even is the reselect action was a valid option, the user would still need to login again on the "new" server.
/Mike/
- レザ
Hi Mike,
That's the question. I am looking for a way to prevent users from re-authenticating, as far as I understand, it is not possible because when the user who currently loggined transferred to the new server must be re-authenticated by the new server back-end. Unless the servers themselves (meaning the back-end part) have the ability to exchange the session information of their users.
Thanks
PeteWhiteEmployee
I agree with Mike - this is not about connections to servers, it is at the HTTP level. In short, you need a common authentication mechanism across backend servers, or use APM to handle the authentication and passthrough the user credentials to the server. You may find that federation such as SAML or OAuth gives a near-seamless solution ( to re-authenticate, the client would be redirected to the IdP and assuming they have a valid session then be redirected back immediately ).
This requires some architectural thought - we in F5 Professional Services do this sort of thing all the time, it might be worth looking into that if you want to discuss it further.
