When we get to the point in an investigation where we are about to break out Wireshark, the complexity of the packet analysis can seem quite daunting. And yet by covering a few key points can dramatically cut the time needed to analyze any diagnostic data.
In my previous post I covered the need to thoroughly understand a symptom. In this blog we'll look at the dangers looking for a common cause for multiple symptoms.
Imagine you are faced with a situation where users are complaining about three issues:
- Word documents should open in less than 5 seconds, but intermittently take more than 30 seconds.
- Excel workbooks should save in less than 15 seconds, but intermittently take more than 60 seconds.
- Opening an Outlook Inbox should take less than 20 seconds, but sometimes takes more than 3 minutes.
All problems are reported as having started at the same time, and there’s a widespread belief that they are being caused by a network issue. This is the point where alarm bells should start to ring.
Maybe some of the symptoms are down to the same root cause, but maybe they are not, and starting by assuming they are is likely to lead to a very frustrating time. The choice of a single symptom and ...
... the rationale is covered by RPR.
Let's just take a moment here to digest this. Imagine spending hours or days looking through Wireshark traces searching for a common cause when there isn't one. At what point would you give up? How would you know there isn't a common cause vs. believing your analysis is faulty?
Alternatively, we could start by focusing on the Slow Word Open problem. Once we find the root cause of that problem and fix it, we may find that the Slow Excel save problem is also resolved. If not, we simply investigate this problem next.
I've seen IT teams spend months trying to determine the common factor linking several issues, only to eventually realize that the problems aren't related. Don't fall into this trap - always focus on one symptom at a time.
PS: You can get instant access to the RPR manual via the Network Trace Analysis Guide section of the TribeLab site. It covers additional areas such as prioritization of symptoms and what to do if the chosen symptom occurs infrequently.
Paul is currently leading the TribeLab project to explore new ways to help IT support people troubleshoot performance and stability problems.