This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

General troubleshooting methodology - network/transfer slowness

0

I'm looking for ideas and thoughts on a general troubleshooting methodology for network transfer slowness, using Wireshark, and would like to see what others do when troubleshooting "slow network" issues.

For example, a user complains about slow SMB or FTP transfer of large files over the WAN, and a capture of the transfer is saved to be analyzed.

Right now, I start by analyzing this way:

1) Statistics/Conversations - sort by largest Bytes column, and then follow that TCP stream. (If it is a file transfer, generally it is going to be the TCP conversation with the most data transferred)

1A) Added: Look at the TCP StreamGraphs Time/Sequence (tcptrace) graph, and look for flat sections, showing delays in the transfer.

1B) Look at 3-way handshake and make note of TCP Window scaling option/RWIN size and TCP SACK options, and note the RTT. 1C) Make use of the Bytes in Flight column, and verify if data transfer is filling or nearing the receiver's advertised window.

2) Look at average bits/s using the statistics screen for the display filter, and note this. (This averages the transfer speed for the displayed packets, so if you are capturing, and the user is connected to an SMB server, but sitting idle for 5 minutes before copying files, the reported speed in Wireshark will be slower than the actual max speed of data transfer)

3) Look for packet loss (excessive TCP retransmissions/dup acks)

  • Some packet loss is obviously acceptable over a WAN link.
  • How do I determine the percent or rate of packet loss?
  • In general what percentage packet loss will typically cause a transfer to degrade?
  • For small amounts of packet loss, what is an easy way to determine if this is the cause of slowness?

3a) Here is an example of a tcptrace graph showing 1-2% packet loss on a connection. The packet loss was causing slowness. Notice the bumpy looking graph. If you click the bumpy sections, packet loss was causing the sender to throttle back it's transfer rate, and it was never coming close to filling the Receive Window. alt text

5) Look for high delta times.

6) Look for TCP Window Full messages

Unless there is high packet loss, or obvious client/server processing delay, often times I have a difficult time pinpointing the cause for connections being "slow".

*** Edit: I found a lot of great videos on packetbomb.com explaining how to read the TCP Graphs, as well as the TCP sections in Laura Chappel's book were really helpful.

asked 19 Aug '16, 08:54

crrimson's gravatar image

crrimson
15337
accept rate: 0%

edited 26 Oct '16, 09:55


2 Answers:

1

I too default to Laura as a great resource for methodologies, as Paul mentioned. From your above description, it looks like you already use the method she discusses in the "Wireshark 101" book: 1) Determine who is talking 2) Determine what applications are talking 3) Filter on the conversation(s) of interest 4) Graph the IO to look for drops in throughput 5) Open expert 6) Determine RTT

In the "Troubleshooting with Wireshark" book, she dedicates the first chapter to discussing a sample troubleshooting methodology that abstracts to a higher level - where you first define the problem - and the work down to the analysis tasks. I think this is important to identify, since as network engrs/analysts/admins it is very easy to jump down a rabbit hole, without clearly assessing the various information at hand and formulating a strategy.

I shared some thoughts on the methodology topic at this year's SharkFest - https://sharkfest.wireshark.org/assets/presentations16/23.pdf

Looks like you are on a solid path and are asking the right questions...good luck!

answered 29 Aug '16, 11:15

BruteForce's gravatar image

BruteForce
1203
accept rate: 9%

Thanks,

I read your PDF and I appreciate the perspective you share, it looks like you have a good system.

I own the Wireshark Network Analysis 2nd ed. by Laura, and after looking at the table of contents, I should probably read chapter 29: "Find the Top Causes of Performance Problems"!

I may come back and edit my post after reading through that chapter.

(29 Aug '16, 13:28) crrimson

0

We have a guide to analysis on the TribeLab site - see http://www.tribelab.com then check the Network Analysis Guide and TRANSUM sections.

Also look out for a series of articles by Gary Kaiser. Laura Chappel also produced a video which I think was called 12345 Guide but I can't find it at the moment.

Best regards...Paul

answered 19 Aug '16, 15:18

PaulOfford's gravatar image

PaulOfford
131283237
accept rate: 11%