Forum Discussion
HTTPS Virtual Server doesn't automatically direct existing connections to available pool member
Hi
We have the following scenario, HTTPS VS presenting a web application configured with 2 pool members, when we are logged into the application and when we test a failover by shutting a web server down, the F5 doesn't direct the session to the other available pool member. We need to force a refresh on the browser for the connection to re-establish to the available pool member. Both VS and pool members are configured with HTTPS
We have:
VS - HTTPS
- SSL Client profile with Verisign certificate
- SSL Server inscure compatible
- Using APM profile
- persistence profile dest_addr
- Pool with 2 members using round robin load balancing.
We have a pretty simple VS setup. I would have thought the F5 will automatically redirect the session to the next pool member, but i need to hit refresh on the browser.
Any tips?
8 Replies
- JG
Cumulonimbus
Have you applied a "OneConnect" profile to the virtual server?
- Mick
Cirrus
no i'm not, should I?
- JG
Cumulonimbus
I would apply one. Please see "K7208: Overview of the OneConnect profile".
- Mick
Cirrus
Thanks JG, i tried that but no luck.
I noticed in the ltm logs complaining about SSL Handshake to one of the web servers:
SSL Handshake failed for TCP web server:443 -> F5 SNAT:33968, not sure if thats causing an issue. The web servers are configured with SSL but are using self signed certs not imported to the F5
- JG
Cumulonimbus
There is a knowledge article to assist troubleshooting: K15292: Troubleshooting SSL/TLS handshake failures.
- Mick
Cirrus
thanks yes i saw this, would this be contributing to the issue i'm having though?
- JG
Cumulonimbus
"When a pool member fails to respond to a health monitor, the system marks that pool member down. Persistence entries associated with the pool member are removed when a new connection matches the entry or when the timeout period is reached. If a new connection matches a persistence record that has not timed out, the BIG-IP system removes the old persistence record and creates a new entry." (K15095: Overview of the Action On Service Down feature).
So a current or a persistent connection will still be forwarded to the failed server until the connection times out or is killed.
With a OneConnect profile, the load balance decision is made based on each HTTP request, not just at the beginning of a TCP connection, as I understand it.
It is probably better to get other issues (SSL) out of the way before testing this issue.
- Mick
Cirrus
thanks JG, i've done some more testing and i think the issue is on the application side, i've tested the same VIP settings on another web application and it works ok
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com
