Packets Never Lie

This is a site for those who took the Red Pill and decided to perform a packet capture to troubleshoot a network or security issue. If you are completely new to packet captures and analysis, you will want to start with the Wireshark Docs Page which has the Wireshark User Guide, display filter reference and several videos to get you started.

Learning how to take a capture is a good start. And you will find that it is just a start. The more captures you take and analyze, the better and faster you will become at this crucial skill. Often the tool that can give you the most information (packet captures) is a tool of desperation in troubleshooting scenarios. Once you become familiar with the techniques, a capture won't seem so daunting and there will be less hesitation to suggest that a trace might help solve your problem. Granted, packet captures will not solve every problem. Sometimes it will only show you to look upstream or downstream from your capture point. Other times it will show you exactly what is breaking. But it won't show you anything if you don't know where and how to look.

This site is software independent. There is nothing here for sale and a number of tools are covered. There may be a bit more emphasis on Wireshark, but only because it is available for free on numerous platforms. But it is not the only software that can be used and in some situations, other products might be better suited to the task. For those who may be working at companies with smaller budgets or new to the network and security fields, exposure to these tools can be useful. It can help you determine if the features are really what you need or if you can adapt what you have to suit the same purpose.

For those who work with Cisco devices, you know that Wireshark has been incorporated into the Nexus, ASA and is now included in the 5.0 version of the CCIE Routing and Switching Written and Lab exams. You can even take a packet capture on F5 devices (load balancers). This does not mean that these are packet capture devices and choosing to pull a capture from one of these devices should be something that is not taken lightly. Packet captures can have a performance impact which is not a good thing in a production environment during business hours. However, if you limit the capture to the packets of interest and perform the capture off-hours, you can minimize the impact. If you really need to take a capture at that point in the path, it could be a better option for you than disconnecting the cable and putting a probe inline for that purpose.

For those who focus on Security rather than troubleshooting, there are a number of items that focus on packet captures and analysis related to scanning, reassembling transferred files, and network forensics. File reassembly and packet analysis is often included in security challenges, security training and security operations. Coloring rules can help spot signature packets in real time and good profiles can quickly drill down into the trace to find evidence or pinpoint a problem. When it comes to "network" troubleshooting, quite often security devices are in the path and can be the cause (or scapegoat) of poor application performance.

And let's not forget the Application, Server and Desktop teams. Although the packets are travelling the network, they are mostly coming from and going to clients and servers. Many services such as DNS and DHCP are configured on servers as well as network devices. And when it comes to application performance - the applications, their web interfaces and backend databases are all found on servers. Your configurations and code can contribute to perceived application or network slowness and by learning to look at capture results, you can often improve performance.