Forum Discussion
troubleshooting if the dropping of connections is by the F5 or Tomcat
Hello,
We have an F5 servicing a pool of Apache servers coming from the internet, and these in turn, again via the F5, through another pool communicate to a tomcat server. Since the beginning of the week, the version of the Internet application has changed. This has doubled the volume of packets on the F5, but it can handle it according to the stats that we get. What we are getting from various logs is that connections are reset/dropped. The question is, is it the F5 who is dropping the connections of the tomcat ? How can I find out, which parameters, which logs, on the F5 if the problem is coming from the F5, or vice versa, i.e. that the problem is coming from the tomcat ? Just to clear from the beginning that the issue has nothing to do with load balancing etc etc. Anybody any idea ?? Thank you.
5 Replies
- Arnaud_Lemaire
Employee
Hello you can ask to log reset causes : https://support.f5.com/kb/en-us/solutions/public/13000/200/sol13223.html?sr=56047771
that could have some perf impacts.
- Michael_Jenkins
Cirrostratus
Have you tried running a tcpdump (and ssldump to decrypt if using https) on the virtuals and checking to see if you can determine it that way?
A couple links to check out that may help:
- SOL411: Overview of packet tracing with the tcpdump utility
- SOL10209: Overview of packet tracing with the ssldump utility
Standard format I use for tcpdump would look liketcpdump -nni 0.0:nnnp -s0 host x.x.x.x -w /var/tmp/filename.pcap -vvv - SOL13223: Configuring the BIG-IP system to log TCP RST packets so you could get more information in a capture
- Getting Started with the F5 Wireshark Plugin on Windows - This plugin can help out with packet captures from the F5.
Another thought might be to add an iRule that either logs different steps of the request (or at least tracks them) and then logs if something doesn't look right.
Hi,
You can active log for TCP reset in tmsh :
SOL13223: Configuring the BIG-IP system to log TCP RST packets
Then, you can check the tcp reset reason on /var/log/ltm logfile.
Alternatively, you can also launch a tcpdump or ssldump on the F5 system in CLI to check who drop the packet, ...
- cmard_195831
Nimbostratus
Hello and thank you. We will monitor the case today.
- cmard_195831
Nimbostratus
Hello,
and thank you all for your advises. We will monitor the case today to try and figure out the issue. We have a weird feeling that all the problems are coming from Tomcat, and that is the million dollar issue as how to rectify this. Thank you.
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com