The toughest part of troubleshooting is to fight the urge to jump to conclusions. The best example I can think of is when I see technicians making changes with no quantifiable data to prove if the change made a positive or negative impact. I know when this is happening because I hear a lot of “it should” and “I thought”.
When I teach or present, I explain that the cornerstone of effective troubleshooting is based on having clear data points. That way we can compare these values before and after the change and prove the true impact.
In this video I walk you through a trace file that I just took identifying what I looked for and protocol specifics. It is important to understand that the application is working fine and there are no complaints. But what I saw is an application querying a time server and the results are returned one byte at a time.
This exercise illustrates the value of performing a baseline or application profile. It really doesn’t take long to capture and save some packets. You don’t even have to analyze them right away. Once you have the capture, you can analyze it whenever you get the opportunity or have it on hand for future reference.
The concern is that the client is planning to move this server and inefficient communications might totally break down.