Forum Discussion

Caio_178191's avatar
Caio_178191
Icon for Nimbostratus rankNimbostratus
Jan 19, 2015

time_wait connection in a VS

Hi.

 

I would like to get the connections that are in time_wait in a VS. I tried to do it using netstat but it doesn't give me IPs that are connected in VS.

 

I would like to know if in iRule is it possible to do that.

 

Thanks.

 

6 Replies

  • from tmsh you will have access to the idle tiemout for connections. the time_wait connection table is available through snmp via the general TCP mib.

     

  • Hi cmdmss,

    are you really about to look for connections in time wait on the BIG-IP?

    This will be connections initiated by a client to a virtual server which were recently closed.

    The default time wait settings on the BIG-IP (please see the associated TCP profile of the related virtual server) are pretty short and I wouldn´t expect them to cause issues.

    If they would, you could track it by logging the RESETs (please see AskF5 SOL13223 and SOL13898).

    The following command provides current statistics (including number of connections in time wait) for the TCP profiles in use:

    watch -d tmsh show ltm profile tcp

    Please enter a specific profile (the one associated with your particular virtual server) as additional parameter.

    From my perspective it´s more likely to see time wait issues on your real servers (pool members) as the default MSL (max. segment lifetime) is 120 seconds on most systems.

    This will cause RESETs from pool members to your serverside SNAT or in case of un-snatted traffic to to few clients with connection rates.

    Thanks, Stephan
  • Hi cmdmss,

    the statistics command indeed just tells about the number of clientside connections in tcp time-wait. No information about the specific client IPs is provided.

    The default time wait setting in the tcp profile is 2,000 ms only (2 sec) and one would need to dump it continuosly and verify it with a simultaneous tcpdump to figure out the client with the high connection rate from constant source port (causing a time wait issue). (If I got your clients request right.)

    Did you check one of the troubleshooting options from SOL13223 already?

    tmsh show /net rst-cause

    In my first response I mentioned two knowledge base solutions (one was wrong, sorry about that). How about turning on the inclusion of the TCP RST cause into the RESET packets?

    To run a tcpdump with a filter to RST packets (dumped to /shared/tcpresets.cap and to be analyzed by WireShark with the F5 Ethernet Trailer plugin) only you may want to use the following syntax:

    tcpdump -nnni 0.0:nnnp -s 0 -c 100000 -w /shared/tcpresets.cap 'tcp[13] & 4!=0'

    (Please see SOL13637 for details on the F5 ethernet trailer feature.)

    This trace should help to figure out the clients which get a RST because they try to open a new connection while the BIG-IP still have it in time wait (may be caused be duplicated SYNs as well).

    If you turn on the reset cause transmission the RST packet should contain the related information:

    tmsh modify /sys db tm.rstcause.pkt value enable

    To turn it off you will use the following command:

    tmsh modify /sys db tm.rstcause.pkt value disable

    I recommended to turn on the reset cause transmission for troubleshooting purposes only.

    Thanks, Stephan
  • Hi Sthephan, thanks for your considerations.

     

    The customer only want the IP address from connections that are in time_wait. We do not have more details about it... Just what I said some posts up.

     

    We give the RESET option to customer, but he still needing IP address. It's his demmand for something specific, we don't have details about that.

     

    I'm already have a case opened in F5. The analyst said to make netstat command, I said to him this is not going to show the IP address like I said before here, I'm waiting his answer about that.

     

    We imagine we couldn't get this time of connection with iRule... but I would like to have the Devcentral community considerations.

     

    Thanks for you attention.

     

    Regards.

     

    CAIO

     

    • StephanManthey's avatar
      StephanManthey
      Icon for MVP rankMVP
      As TMOS has it´s own TCP stack it would have surprised me, if netstat would have shown the expected result. That´s why the "tmsh show sys conn" has to be used. And may be there are hidden parameters to show connections still in time wait. But I guess only F5 support can help further.