As the website’s name represents, the network is the ScapeGoat of the IT department. Everybody blames the network. Recently I have had two different issues come up that I had to use a packet capture to prove the network was getting the data where it needed to be.
In regards to getting a packet capture, I’m very fortunate to have a hand full of devices in my network that can obtain a packet capture. I have a large number of Cisco ASA Firewall’s, F5 BIG-IP Load Balancers, Cisco NAM module, and of course Wireshark on any laptop we can control. The ability to get a packet capture on these devices has drastically reduced the number of time I have had to go to the data center to get a packet capture, it has become very convenient.
Packet captures are not the easiest to read. You really have to know how TCP or UDP works along with your application. In reality, you need to know enough to prove that your network is working correctly. I can usually accomplish this by doing a simple filter with the source and destination IP’s that you are interested in. It’s easy to see if there is two-way communication or one-way, or none at all.
I recently had an appliance at a remote location fail to connect to the database at the main office. The vendor was complaining that the network was blocking the data flow. I was able to get a capture, find the login packet. I was able to tell the vendor over the phone the username and password they were using. I was also able to tell them how the server responded. This ended the phone call and the vendor knew it wasn’t a network issue.
I could go on and on with examples of times proving that the issue was an application issue, but the important thing is that the Packet Capture doesn’t lie. When all else fails, get a packet capture, learn how to read it and use it to win the blame game!!!
What were you blamed for and proved it wasn’t your network with a packet capture??
If you found this article interesting or helpful, please share it with the share buttons below!!