Or prove that it is the network.
If you’re a network engineer, how much time do you spend defending the network? Everyone points a finger at the network; it’s guilty until proven innocent. Everything looks good from your standpoint: monitoring, alerts, maybe some pings, download a file from a server…it all seems to check out. So you point fingers back. But how do you definitively exonerate the network?
Maybe you’re a sysadmin your application server is running in the green. CPU, memory, interface stats all check out. So you point a finger at the network. But how can you be sure there’s not an issue lurking somewhere with your server?
Maybe you’re an application developer on the client or server side. It’s not your code, right? It’s definitely the network, or maybe IT needs to give you a bigger server because it doesn’t have enough horsepower. But are there some clues that could let you know if your app has a logic or inefficiency issue?
That’s where packet analysis comes in. Through this video and more to come, I’m going to show you how to dig in and start eliminating things and finding the right direction to do your investigation, whether you are a network guy, a server girl, or a developer chipmunk.
Here’s a hypothetical scenario: Ol’ Betty in accounting (who is also the CEO’s mother) is having trouble downloading her cat pictures and she’s real upset about it. If Betty’s upset, we don’t get paid on time. So it’s in everybody’s best interest to get this solved.
It’s a good idea to get data as close to the source of the complaint as possible, to see it from their perspective. So capture on Betty’s machine if possible or span her port or use a hub between her computer and the wall port. Now, I’m going to skip over a lot of important steps before you get to the analysis: asking the right questions, narrowing down the problem, getting the data, etc. We can cover those things in the future but in the interest of this video not being two hours long, let’s get to the analysis.
This is just one possible outcome of the scenario. There are endless possible outcomes and analyses. For example, I just finished troubleshooting a Windows 7 upload performance issue that is completely different than this. I’ll be writing it up soon; I learned more about Windows TCP than I ever thought I would.
Here’s the Wireshark setup videos I mentioned:
I’ve got two pcaps for you: the FTP one from the video and an iperf one for you to analyze. Analyze the iperf pcap and leave a comment or email me and tell me where the delay is: client, server, network, etc. Hints:
P.S. The iperf capture is a sneak peek of the next thing I’m working on.