Forum Discussion

ccraddock's avatar
ccraddock
Icon for Cirrus rankCirrus
Jul 26, 2019

TCP states of Virtual Servers

Community,

Is there any way to see the actual TCP states of a Virtual server both between the client and VS as well as the VS and the pool member? I can run a show /sys connection and see the IP's and port #s but it doesnt exactly show me what the state is (for example ESTABLISHED). I can run a netstat -alptun in bash but that only gives me the TCP states of connections to the device itself.

 

The reason I ask is because we are having an issue where when the client disconnects its TCP session to the VS, the F5 will send a FIN to the pool member (a Linux server running Jira in this case) but the Linux server only sends an ACK, it never sends its own FIN,ACK. This is resulting in hundreds and sometimes thousands of CLOSED_WAIT connections on the Linux server. By this time the client and the F5 have long since reaped their own connections (the client to the VS and the VS to the pool member) but the pool member (Jira/Linux Server) just seems to cling to these connections.

 

Also, when we connect to the Jira/Linux server directly from a browser, it has no issues sending a FIN,ACK after it receives one from the client. The issue only seems to occur when connecting to it through the VS. The Pool uses the same port to connect to the server (8080) as we are using in the browser.

 

Any ideas?

 

Thanks.

  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus

    I can't help but think that this is somehow a connectivity issue between the BigIP and the Jira server. Because as you state there FIN/ACK is never sent by Jira, even though the FIN is (presumably) seen arriving at the Jira

     

    • Is the BigIP to Jira connection passing through a firewall?
    • If you tcpdump a connection between the BigIP and the Jira server at BOTH the BigIP and the Jira server, then what do you see at the end of the connection at each end? Is it possible that one of the FIN's is being lost somewhere in the network?
    • ccraddock's avatar
      ccraddock
      Icon for Cirrus rankCirrus

      Hamish,

       

      Thanks for the response. The next step is definitely to do a TCP dump at the F5. The inbound traffic to Jira coming from the F5 is not going through a FW as the F5 has a direct layer 2 connection (VLAN) into the subnet. However, the Jira server's response has to pass through a firewall in order to return to the F5. What I find interesting is the following:

       

      The VS is on the 10.110.8.x subnet and Jira is on the 10.110.90.x subnet. When we do a TCP dump on Jira, Jira sees the traffic coming from 10.110.8.92 (the VS) and not the floating IP for the Jira subnet on the F5 (10.110.90.7). In this instance Jira has to route its return traffic back thru our Firewall, because the firewall is its default gateway. I am considering SNAT'ing the traffic so that inbound traffic appears to be coming from the floating IP 10.110.90.7 and thus Jira should not have to route its return traffic thru our FW.

       

      UPDATE: This issue is completely unrealted to the F5 and has to do with Jira application not closing out its own TCP:443 connections. We confirmed that all browser based connections either directly or through the F5 are closing without issue. The only sessions that arent closing are the ones being sourced by the Jira server itself. Thanks for your help!