HTTPS Virtual Server doesn't automatically direct existing connections to available pool member

[Mick]

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?

[JG]

Have you applied a "OneConnect" profile to the virtual server?

[Mick]

no i'm not, should I?

[JG]

I would apply one. Please see "K7208: Overview of the OneConnect profile".

[Mick]

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]

There is a knowledge article to assist troubleshooting: K15292: Troubleshooting SSL/TLS handshake failures.

[Mick]

thanks yes i saw this, would this be contributing to the issue i'm having though?

[JG]

"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]

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