Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] Help with troubleshooting SQL and application server commu

From: Hansang Bae <hbae@xxxxxxxxxx>
Date: Wed, 13 Aug 2008 21:13:45 -0400
Michael Montgomery wrote:
Hello All,
I am a Wireshark newbie (who really wants to learn how to use the tool and my employer won't pay for training) and was wondering if someone could help me understand a capture between a SQL database server and its front end application server. We had a company come in and analyze our network and they stated in their report that our application server is not processing SQL data being received fast enough to keep up with the rest of the application. I've been tasked to re-create this trace, after reconfiguring services to use specific port numbers, to either validate/invalidate their report by using Wireshark. After running a capture I've noticed a ton of [TCP Out-of-Order] [TCP segment of a reassembled PDU] and several [TCP Dup ACK] errors. I am assuming this is bad and not sure why this would be occurring. Any ideas? or what I should be looking for? Your assistance is greatly appreciated!


It has been my experience that *most* companies who claim to have protocol analysis experts - don't. But let's start with the basics first.

1) Check the duplex setting of the server's NIC. If you use NIC teaming check the speed and duplex setting within the NIC teaming software.
2)  Check the switch port's speed and duplex.
3) *MAKE* sure the settings in #1 and #2 match. 100/FD to 100/FD or Auto/auto to auto/auto.

Now repeat the same thing for all servers involved. Then repeat for users who are complaining.

You can partially tell if the server cannot keep up by mapping out the (receiver's) TCP window size. It may get smaller and smaller as the server struggles to keep up with the amount of incoming data. But let's check the duplex settings first to see if you you have a lot of packet loss.

You can also get a feel # of retransmissions by doing a "netstat -s" on the servers and PCs. Under the TCP section, keep an eye on "Segments Retransmitted"

Ironically, my next (in-house) training will involved picking out real retransmissions/packet loss from fake ones. Fake ones meaning incorrect capturing technique is the real culprit.

I'm starting to record all my in-house training sessions so I'll see if I can get them posted somewhere. They run about 1.5 hours per and the sessions are taken from real live troubleshooting.

Also, it may help if you post snippets of packet traces for others to look at.

**** BUT *****

make sure you run "editcap infile outfile -s XX" to remove all pertinent data. We only need TCP headers (-s 56 or so may be enough, but play around in case you have bigger TCP headers)

--

Thanks,
Hansang