Forum Discussion

Piotr_Lewandows's avatar
Piotr_Lewandows
Icon for Altostratus rankAltostratus
May 29, 2017

TCP close vs active close and timers

Hi,

I already read few great post here as well as some articles but I am still not sure how things are working on BIG-IP.

First of all I wonder if there is a way to monitor connection states via some command on BIG-IP (like FIN_WAIT, TIME_WAIT etc.). I know on the host subsystem 

netstat -ano
can be used, but this command is not reporting any TMM managed connections.

When 

tmsh show sys connection cs-client-addr  all-properties
is used there is as well no info about current connection state.

I can probably use tmsh show ltm profile tcp for that - but that is only possible in test environment when I can just send single connection, not so easy in production 😞

So I can do 

watch -n 1 'tmsh show ltm profile tcp lamp-cs-tcp-lan-optimized | grep 'Connections' -A9'
for that.

Now I have issue which timers are used on what situation.

Scenario 1 (all performed on v11.2.0HF7)
  • Client connects to VS
  • BIG-IP send FIN-ACK to client

What kind of close is used for such scenario? Rather not standard close when connection initiator (client) sends FIN, so I guess active close like that:

Now which timers will be used for such case by BIG-IP? My guess is:

  • Fin Wait
  • Close Wait
  • Time Wait

Let's say BIG-IP received ACK to FIN but not FIN from client. Which timer will be used? What state connections is - still FIN_WAIT_1? Or not because there is no FIN from client?

From monitoring I can see that BIG-IP is entering FIN-WAIT/CLOSING state and stays in this state until Idle Timeout expires - pitty that there is no way to say if it's FIN-WAIT or CLOSING state.

Why so? Because there is no FIN from client?

If I will send FIN-ACK from client then connection enters TIME-WAIT state immediately after BIG-IP replies with ACK.

So why Fin Wait timer is not triggered here?

Scenario 2
  • Client connects to VS
  • Client send FIN-ACK to BIG-IP

I assume that we have now standard close like that:

Timers used seems to be only:

  • Close Wait
  • Time Wait

Fin Wait is not used as this is state on client side not on BIG-IP side - or I am wrong?

Another question is what action is performed after each timer expires (assuming BIG-IP closes connection - I guess happens usually more often on server side than client side):

  • Fin Wait - BIG-IP already send FIN, entered FIN_WAIT_1, no ACK from client. Will this timer be triggered, if so what will happen when expired:
    • RST from BIG-IP (if Reset On Timeout enabled?)
    • Nothing
    • Timer will not trigger and Idle Timeout will be used - consider that from test it seems that nothing happens and Idle Timeout is used
  • Close Wait - BIG-IP received FIN from client, entering CLOSING state, same question as above - what happen if there will be no ACK to BIG-IP FIN?
  • Time Wait - BIG-IP send ACK to client FIN and received ACK to its own FIN - that part seems to be working, TIME-WAIT state is reported and disappear after Time Wait timeout (2s)

Piotr

active close
application delivery
close wait
devops
fin wait
LTM
rst
time wait

1 Reply

Sort By
  • dragonflymr's avatar
    dragonflymr
    Icon for Cirrostratus rankCirrostratus
    May 29, 2017

    Just another question that popped up after some more tests.

     

    Client is closing connection with BIG-IP, sequence of packets is (sequence number and ack i parenthesis):

     

    • C (115, 432) -> BIG-IP - FIN-ACK (ACK is for last packet send by BIG-IP - HTTP reply)
    • BIG-IP (432, 115) -> C - FIN-ACK (ACK for last packet received from client)
    • C (116, 433) -> BIG-IP - ACK - for FIN packet from BIG-IP
    • BIG-IP (433, 116) -> C - ACK to client FIN

    Is above indication that it is active close - both sides are closing connection at the same time?

     

    Is that default behavior for BIG-IP or it can be changed so standard close is performed?

     

    Another strange issue noticed - when Time Wait Recycle is disabled.

     

    I expected that BIG-IP will send RST when another connection from same IP:port is comming when connection on BIG-IP is in TIME-WAIT state.

     

    It was not the case. Instead BIG-IP replied with ACK but using ack number send in last packet of previus connection. As an result client is sending RST and then retrying with SYN (again ACK and RST until client maximum SYN retransmission is reached or connection on BIG-IP is removed after Time Wait expires.

     

    Piotr