Forum Discussion

Dazzla_20011's avatar
Dazzla_20011
Icon for Nimbostratus rankNimbostratus
Apr 12, 2011

Difference between tcp and tcp half open monitor

Hi,

 

 

What's the difference between the a tcp and tcp half open montor?

 

 

I thought the Tcp monitor just checked the tcp three way hadshake and tcp half open just checked SYN-ACk is received?

 

We have an application which falls over when I apply the default tcp monitor. How can check if the LTM is closing the tcp connection for the monitor and also would the tcp half open be a better option just for checking the status of a tcp port?

 

 

Thanks

 

Darren
  • TCP half open monitor will send RST after it receives Syn-Ack from the pool member.

     

    TCP monitor not only doing three-way handshake but it can also be configured to send string and check the response.
  • TCP - Syn | Syn, Ack | Ack |

     

    TCP-Half-Open - Syn | Syn, Ack

     

     

    I can't remember whether TCP sends a FIN or a RST after the connection is complete but I'm almost certain Half-Open sends an RST after the Syn, Ack.

     

     

    It's concerning that your application falls over from a simple 3-way handshake - at what interval are you checking?
  •  

    Just the default every 5 seconds. Yes seems as though we have a problem with the application which is written in house.

     

     

    Thanks
  • You can use "tcpdump" on the BIG-IP system to check the connection status. For quick check

    tcpdump -ni [internal_vlan] host [pool_member_ip] and tcp

    That is if you are checking a pool member 10.0.0.10 on vlan named "internal":

    tcpdump -ni internal host 10.0.0.10 and tcp

    If you do not have normal traffic from virtual, you'll only see probes going to that node.
  • (maybe this is obvious to you) Chances are that your app/server is keeping connections open long enough for the ltm to exaust all sockets available; even with the RST coming back. It 'should' close the connection, but I've see on a few occasions that the member server keeps them open. From a clean slate, (stop service, kill app) check your sockets open with netstat with no monitor applied, and observe the behavior of the sockets under some load. Rinse and repeat with the monitor back on, and see if sockets are remaining open. I think you can tune the server connection open timeouts to get it to be more aggresive. If it's your application, it could be opening a connection expecting to do work (method call) and keeps that connection open until it reaches it's default/configured time out. I think .net default is ~2 mins. In case where I didn't have access to source or configuration, I've had to put together an external monitor that acts like a client.
  • You said:

     

    "We have an application which falls over when I apply the default tcp monitor."

     

     

    What monitor was applied prior?

     

     

     

    Generally, you use TCP Half Open when you don't want to leave a bunch of connections hanging out there on the server that need to timeout..

     

     

     

     

    Definitley take the one posters advice and run a tcpdump to see what's actually going on..

     

  • Interesting. One of our Application support guys has come to see about a totally unrelated issue, he's seen loads of TCP TIME-WAIT connections from the LTM. We've created http monitors using alias ports to monitor some internal apps. There's no issues at the moment but as Steffen said he's concerned it could exhaust all sockets available. So from reading the posts above I have two options to ensure the socktes don't become exhausted.

     

     

    1) Tune the server connection timeouts

     

    2) increase the monitor interval time

     

     

    I take it we shouldn't be seeing lots of TIME_WAIT stats?
  • Nah, snat automap is used when your pool members are not in line any need to route back to the LTM.. yes u will see the LTM as the source.. but it should be valid traffic..