The Wire shark capture for this issue will almost certainly point to the switch as being the culpable problem. This issue could be easy to mis diagnose. you will see many ACK entries, which are acknowledgments. ACK is not necessarily bad so how to prove there is a problem? This file transfer took 600 seconds, instead of 12. There is definitely a problem. An example Wireshark will look like below. ( I filtered for TCP):
So in this case it is important to focus on only what we care about. The ACK is taking up the majority of the trace. For Slow transfers, we really care about things like retransmits, high time between ACKs and such. So how do we isolate a slow transfer without getting a headache? In this example, I will show you the tools filtering ability and alos a direct Filter to find the issue.
You want to know a little about how TCP congestion control works; you may read the RFC 5681 on how the send and acknowledge process works. Basically, The TCP window is increased until the largest packet size is reached. The acknowledgement occurs at certain intervals, like when adjustments need to be made. There is often a selective acknowledgment (SACK), which clients will use to update time out variables, amount other things.
I begin by going to Statistics->conversations->IPV4. I chose the largest bytes which was between 10.200.12.215. and 172.23.251.29. Select the filter for A and B.
The resultant trace then should be adjusted to show us the latency by going to View-> time Display format – and select seconds since previous captured packet:
After selecting seconds since previous captured packet, highlight the time column and this will bring the highest time between packets to the top. 38 Seconds for the trace I reviewed!! this is like an eternity!
It looks like our problem is TCP retransmits. So how do we know for sure? There is a filter you want to commit to memory called “tcp.analysis.flags“. If you filer the capture on this, you will see just the problem packets. The statistics on this filter (statistics->summary) is basically equal to the statistics on the unfiltered trace. the main thing to note is all of the high wait time packets are in the retransmit category. We have captured our issue.
Now what to do?
“high retransmits ftp transfer server 2008 r2” – The first result is
Here is your Issue, along with the hot fix on how to fix the issue.