High Packet Drop and connection failure

4) Take a capture and put it into wireshark. filter for all broadcast and multicast. From there we can get an idea of any harmful drops. Bursty traffic could overflow the buffers but you stated earlier that direct pings were fine. Did you do extended pings as well with a larger payload?

 

5) TCP Resets and look for long Delta times in wireshark. Isolate that conversation and compare the external and internal captures to see if a particular server is taking a long time to respond. You could also use AVR, fidderl or httpwatch to hit the most problematic VS and attempt to locate a particular URL/uri combo that is taking long time to complete.

 

7) In the gui, Network -> Interface or cli:

 

[root@ltm1:Active:Disconnected] config tmsh show /net interface

 

 

-----------------------------------------------------------------

 

Net::Interface

 

Name Status Bits Bits Pkts Pkts Drops Errs Media

 

In Out In Out

 

-----------------------------------------------------------------

 

1.1 up 118.1M 8.8K 137.9K 19 0 0 none

 

1.2 up 62.8M 10.5K 23.0K 24 0 0 none

 

1.3 up 90.7M 19.1M 80.8K 57.0K 0 0 none

 

mgmt up 9.6M 7.3M 8.2K 5.6K 0 0 100TX-FD

 

 

[root@ltm1:Active:Disconnected] config

 

 

9) a) If a particular server gets busy, RR will keep hammering it. I use Observed Member as my Best Practice. It will monitor server repsonse times (amongst other things) to determine when to back off of a server, giving it time to catch up.

 

b) When you say "pinging to the node", what node? LTM VS? If so, that ping does NOT make it to the pool member. If you are having trouble here, then I tend to look back at the network/cabling again.

 

 

10) Is the specific VS a 3-tier app? Are there database calls being made by the web or middleware that the webserver/client would need to wait on.

 

 

11) If you can find a time when you failed to make a connection to the VS (node in your terms?) and you have front and back captures, you will most likely have caught the main portion of your problem or at least the biggest clue. I would keep a continuous ping going as well to see what happens at the same a failed attempt occurs.