Packet analysis is difficult enough without having to worry about the GIGO (Garbage In, Garbage Out) effect. Capturing the right spot, with the correct settings, makes all the difference in the world.
In this series, Tony Fortunato of the Technology Firm will cover various tips, tricks, and settings to keep in mind when capturing packets.
Solving Packet Capture Challenges
No one will argue that capturing packets is typically the best way to prove the root cause. Unfortunately, this process can be quite a challenge, not to mention understanding all the variables or options involved.
The best advice I can give before we get into the details is to ensure you document how you captured packets, where you performed the capture, and which tool you used.
Location, Location, Location
You can’t analyze properly if you captured from the wrong ‘spot’. In other words, how you put yourself in the path of the packets is critical.
If you decide to use port mirroring, monitoring, or span ports, be aware that more than likely you won’t be able to capture corrupted packets due to physical level or duplex issues. The solution to this issue is to use a tap or inline capture device.
Be careful when capturing packets directly from the client or server since driver offloading may cause some confusion.
A good rule of thumb is to capture from a separate device and from the sender side to properly analyze if packet loss is an issue.
Know your Tool
Many analysts use Windows computers for troubleshooting. When you think about it makes a lot of sense. It’s convenient and saves you time on your tool learning curve. What you may not know is that you would not be able to capture any corrupted packets caused by physical layer or duplex issues on the wired side. On the WiFi side, you need to ensure your wireless adapter supports promiscuous mode and/or capture administrative packets.
The last variable to be concerned with when using your computer for capturing packets is to determine what packet rate your computer can keep up with. Just because you have a 1 gig interface doesn’t mean you can capture at full line rate at maximum and minimum frame sizes.
Packet Slicing
Packet slicing is a great option to consider if:
- You have limited storage
- Want to extend the capture duration of the trace when storage is limited
- The data is sensitive, or unreadable
A good value to start with is 128 bytes since that will give you layer 2,3,4 addressing and some of the application data. If you want to be more precise, capture a few full-sized packets and determine where the data starts.
Capture Filter
The most effective method of reducing your trace file size, is to use a capture filter. Deciding what to filter on will depend on what the packet tool has available. Most will support layer 2, 3 or 4 addressing. I always suggest you use capture filters after capturing with no filters to determine what you need to filter on and don’t forget to exclude other protocols that may help troubleshoot such as ICMP.
Packet Bookmarks
People tell me this is one their favorite tips from me. It is quite simple; get the client to do something that has nothing to do with the application and look for that in your trace. For example, the client might be experiencing performance issues with their SQL queries, so ask the client to ping Google public DNS, or create a desktop shortcut. The key here is to ensure that the client’s computer doesn’t normally communicate with Google DNS. Now when the client has the issue, they ping Google DNS. When you go through the trace file you can simply search for the ping packet to find the problem area in the trace file. Check your packet capture tool to see if it supports a capture stop trigger. If it does, the capture will automatically stop when it sees the ping. Tips to make the ping unique in addition to a unique target host would be to send your ping with a specific payload or length.
