Forum Discussion

Mick's avatar
Mick
Icon for Altocumulus rankAltocumulus
Aug 07, 2019

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's avatar
    JG
    Icon for Cumulonimbus rankCumulonimbus

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

  • Mick's avatar
    Mick
    Icon for Altocumulus rankAltocumulus

    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

  • Mick's avatar
    Mick
    Icon for Altocumulus rankAltocumulus

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

  • JG's avatar
    JG
    Icon for Cumulonimbus rankCumulonimbus

    "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's avatar
    Mick
    Icon for Altocumulus rankAltocumulus

    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