Wireshark-users: Re: [Wireshark-users] Help with troubleshooting SQL and application server commu
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
