1

We are running a spring boot application with embedded tomcat. The application on its own works fine. When we introduced a F5 LOAD Balancer to load-balance the traffic, our throughput went down. When we connect to the server directly we can see that during handshake, the server reuses the cached session.

When the calls are routed from F5, a new session is always created. What can be the cause for this. This was working well and has broken suddenly. We suspect our f5 configuration is broken. Any pointers for further investigation would be helpful.

%% Initialized:  [Session-22, SSL_NULL_WITH_NULL_NULL]
Standard ciphersuite chosen: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
%% Negotiating:  [Session-22, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384]
*** ServerHello, TLSv1.2
user207421
  • 305,947
  • 44
  • 307
  • 483
pointerness
  • 323
  • 3
  • 12

2 Answers2

0

I suspect your SSL session caches and/or timeout profiles may not be configured past defaults or are configured too low for your application.

Check and update your session cache sizes and timeouts to acceptable levels.

K6767: Overview of the BIG-IP SSL session cache profile settings

You may also need to check other timeout settings to verify the entire tcp session isn't being reset due to idle timeouts. Without knowing how your application pins up and tears down traffic, it's difficult to say.

K7606: Overview of BIG-IP idle session time-outs

I suspect the first KB I linked is going to solve your issue but it's always safe to check all timeout settings across profiles used by that virtual server. Hope this gets you in the right direction.

Chase
  • 650
  • 6
  • 17
0

From K6767 mentioned earlier, there's a link to :

K13854: The BIG-IP system incorrectly allocates the SSL session cache size based on per virtual

This explains why it is necessary to shorten SSL Cache size when a same profile is called by several Virtual Servers.

Eugène Adell
  • 3,089
  • 2
  • 18
  • 34