For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

What is HTTP Part VII - OneConnect

In the last article in this What is HTTP? series we finished covering the settings in the HTTP profile itself. This week, we begin the transition to technologies that support, enhance, optimize, secu...
Published Nov 06, 2017
Version 1.0
application delivery
http
LTM
oneconnect
series-what-is-http
TMOS
JRahm's avatar
Icon for Admin rankAdmin
Christ Follower, Husband, Father, Technologist. I love community and I especially love THIS community. My background is networking, but I've dabbled in all the F5 iStuff, I'm a recovering Perl guy, and am very much a python enthusiast. Learning alongside all of you in this accelerating industry toward modern apps and architectures.
View Profile
JRahm's avatar
Icon for Admin rankAdmin
Christ Follower, Husband, Father, Technologist. I love community and I especially love THIS community. My background is networking, but I've dabbled in all the F5 iStuff, I'm a recovering Perl guy, and am very much a python enthusiast. Learning alongside all of you in this accelerating industry toward modern apps and architectures.
View Profile
dragonflymr's avatar
dragonflymr
Icon for Cirrostratus rankCirrostratus
Jan 11, 2018

Hi,

 

Nice recap! I think there is one small error here:

 

The fourth request goes to server2 and because there are no idle connections open to server2 then a new connection is created:

 

Rule /Common/check_oneconnect : BIG-IP: 172.16.199.234:38648 sent GET to 172.16.199.31:80

 

[TCP::local_port] should be different [IP::server_addr] should end with .32

 

I am still not sure when TCP profile Idle Timeout kicks in. Only scenario I can imagine is when:

 

  • Server Keep Alive timeout is grater that value set for TCP Idle Timeout
  • Single request is send from client, so TCP connection to server is created
  • No more requests are sent over this connection for period longer than TCP Idle Timeout

Is above correct?

 

I am as well curious why after Max Age is over connection is not closed by BIG-IP? Seems that waiting for server to close is preferred but exactly why it's preferred?

 

What will happen if server will send anything over connection marked as illegible for reuse? Packet will be accepted, dropped? Will it influence connection state - so it will be marked back as eligible for reuse?

 

Why there is such difference between handling connections that exceeded Max Age and Maximum Reuse? If it's preferred to have server close connection why for Maximum Reuse same strategy as for Max Age is not used?

 

Idle Timeout Override - similar question as for TCP Idle Timeout - when this timeout will be used? Only when connection was never reused?

 

You can also set the idle-timeout-override to infinite, which will ignore the other BIG-IP protocol timers but not overcome the settings of the server keep alives.

 

It's obvious that server timeouts can not be overridden, but which BIG-IP timeouts are in this case? TCP Idle Timeout? I do not expect that this setting overrides Max Age - am I right?

 

And last one, there are two settings related to reuse. I assume that the first one that hits threshold wins, so if Max Age never was reached but Maximum Reuse was connection will be closed, and vice versa?

 

Piotr