September 15, 2000
User-Initiated Packet Capture
Have you ever been troubleshooting an intermittent problem, and never were able to capture the right information at the right time? Calls from a help desk or a user seem to arrive when you've left the building, or when you're not available to stop the capture that you've previously left running. By the time you arrive back at the analyzer, the information you were trying to gather has long left the always-too-small buffer.
What if your end users could start the capture themselves, without even touching the network analyzer? With this technique, your users don't even have to know that an analysis tool is on the network!
The key to this tip is to use a 'trigger.' This isn't referring to a horse or a firearm, it refers to a feature that can begin and end a capture session when certain traffic characteristics traverse the network. Many analysis tools have a 'trigger' feature, so you'll need to check your analyzer for the specifics of your trigger function.
You'll need to define two trigger instances; one that will start the capture (the start trigger), and one that will stop the capture (the stop trigger). The start and the stop triggers can be based on many external forces, depending on the analysis tool. Statistical thresholds, analysis 'expert' settings, a protocol type, or a specific hex value offset a specific number of bytes into the frame can be used as triggers. As you can see, triggers have amazing flexibility!
The stop trigger is dependent on the circumstances surrounding your troubleshooting. Many network managers have their analyzer capture another N packets, or stop capturing after 30 seconds have elapsed. More advanced triggers can be based on network traffic or monitoring thresholds.
The start trigger is the key to this troubleshooting technique. Using the trigger function of the analyzer, define a traffic pattern from a user that would not occur during a normal operations. To provide a start trigger for this function, I've used an ICMP packet (a ping) from the user's workstation as the trigger to begin capturing. To make things easier, I've added an icon on the screen for the user, and made sure they clicked that icon when the network problem occurred.
The events occur as follows:
* The user notices the network slowdown, and clicks the icon on their desktop to begin the PING command across the network.
* The analzyer sees the ICMP packet, and recognizes the event for a trigger start. The analyzer begins capturing from the network.
* The analyzer continues to capture traffic from the network for the specified time period, for N packets, or any other timeframe. I've configured my analyzer to capture directly to disk for future reference. If I capture to disk, I can restart the trigger after it completes, allowing the user to capture any number of trace files!
Posted by james_messer at September 15, 2000 10:46 PM
Thanks for signing in, . Now you can comment. (sign out)
(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)
