Forum Discussion
13 Replies
- RyannnnnnnnnAltocumulus
what persistence method are you using?
- hut98_37518Nimbostratus
We use persistence type : Source Address Affinity.
- RyannnnnnnnnAltocumulus
That is what i suspected. Your client's IP changes and therefore their persistence session is destroyed.
As you mentioned you are balancing web systems. Have you investigated using cookie persistence with an appropriate HTTP profile and SSL offload/bridging (if you're load balancing HTTPS services)?
- hut98_37518Nimbostratus
Our LTM is load balancing for HTTPS service, and we only deploy SSL certificate on our servers, LTM does not perform the task of SSL certificate authentication. So can we use SSL persistence type ? I also confuse if one of the server is down suddenly, could LTM directs the session requests to the other server ?
- What_Lies_Bene1Cirrostratus
Yes, SSL Persistence should work fine with v11.
- hut98_37518Nimbostratus
I changed SSL persistence but a lot of clients are lost their session even when they login our website.
- Kevin_StewartEmployee
SSL persistence is somewhat peculiar with most browsers. Back in the IE4 days, many browsers actually forced SSL renegotiated every few seconds. Modern browsers can (sometimes configurably) go for several minutes or hours between SSL renegotiations. In any case, when the browser (or server) initiates an SSL renegotiation, the SSL sessionid, the thing you're using for persistence, changes. This leaves you with a real dilemma, and one which generally begs the question "why not offload the SSL on the F5?" By offloading (and optionally re-encrypting) the SSL on the F5, you're performing SSL operations in hardware, which is 1) higher performance, and 2) generally more secure than doing it at the server. Plus you then have the benefit of iRules, optimization, acceleration, security, authentication, and most important in this case, robust persistence mechanisms.
But in any case, if you don't want to, or cannot offload the SSL at the F5, then you're basically limited to what the proxy can see, which is the SSL sessionid and the client's source address. You could technically define SSL sessionid as the primary and source as the secondary (fallback) persistence methods, and get a better result than what you're experiencing now, but it's not a 100% guaranteed solution.
- Cameron_Parker1Nimbostratus
Have you tried implementing cookie persistence?
- Mahmoud_Eldeeb_Cirrostratus
I prefer cookie persistence. it works fine with me
- hut98_37518Nimbostratus
But the cookie persistence is used for HTTP traffic, we use BigIP F5 controlling HTTPS traffic.