The Wonderful Thing About Triggers...
by Laura Chappell [PDF version]
Copyright 2001 Protocol Analysis Institute, LLC

When one customer mentioned that he needed more information on triggers (finding that the analyzer Help system was inadequate), my mind started reeling! There are so many creative ways to use triggers to catch just the traffic (and people) that you are interested in.

This is part one of a two-part article on triggers. In this part, we'll look specifically at the Sniffer's trigger capability. In part two, we'll focus on EtherPeek's triggers.

What is a Trigger?

A trigger defines when an analyzer will start or stop capturing when running unattended. For example, an analyzer can be set up to sit in the server room and start capturing traffic when a specific packet arrives (perhaps an FTP USER command). Additionally, the analyzer can be configured to only capture FTP traffic and stop capturing after a specific number of packets, a specific amount of time has transpired, or a specific event or alarm has occurred. Cool, eh?

Note: Check out "Packet Filtering: Catching the Cool Packets!" from podbooks.com. In Chapter 4, I detail a bunch of really awesome filters including some filters to catch the FTP traffic sneaking through on non-standard port numbers.

As I mentioned earlier, I'm going to focus on Sniffer's triggering functionality in this article - in the next article I'll be poking around EtherPeek's trigger and filtering system.

There are three elements involved with triggers:

• Start trigger
• Capture filter
• Stop trigger

Figure 1 shows the Sniffer trigger window - on the left side is a visual that (attempts) to clarify the basic functionality of the trigger. In my sample trigger, the graphic indicates that the start and stops are automatic (the little light switch).

Figure 1: This trigger starts and stops automatically.

This sample trigger is set up to start capturing all packets (default filter) when an ICMP Redirect packet is seen. It will capture packets for another 200 seconds and then automatically stop.

The Start Trigger

The Start Trigger defines when the analyzer will begin capturing packets off the network. As shown in Figure 2, the Start Trigger can be defined based on the date and time, a specific alarm, or an 'event.'

An event is based on a filter that you have made - for example, in Figure 2, I have selected to start capturing packets when the ICMP-Redirect event has occurred. The ICMP-Redirect is simply a filter that I built on the analyzer (Protocol offset 0x14, data value 05).

Using the start trigger I've defined, the Sniffer will start capture packets when the Sniffer sees an ICMP Redirect. In this case, I'm concerned with some strange routing problems that seem to occur in the evening. There are complaints that indicate a route has been switched in the middle of the night - I'm going to go out and have a Margarita and let the analyzer catch this for me.

Figure 2: I've selected a start trigger based on an event (a filter that has been matched).

The other start trigger options here are pretty interesting - the start date/time is nice because you can set up the Sniffer to start capturing later in the week (you know, when Fred arrives). The Alarms option gives you the chance to start capturing packets when a specific alarm (or a set of alarms) is triggered. Wow! You can select a whole bunch of alarms if you'd like. These alarms are logically OR'd.

The following lists some of the more interesting alarms:

• Broadcast/Multicast Storm
• FTP Slow Transfer Diagnosis
• High Rate of Ring Purge Diagnosis
• LAN Overload Percentage
• Ring Beaconing
• Server Running WINS Shutting Down (sounds good to me!)

1. Broadcast/Multicast Storm: What's going on here? I'd set this up to capture all traffic after this alarm is triggered so I can get an idea of what type of packets are being sent on the network following the storm and how long the storm lasts. I'm not going to look only at the storm itself - I want to know how other devices were affected - the delays between requests and replies, the retransmissions, the timeouts, etc.
   
   
2. FTP Slow Transfer Diagnosis: When people complain that "the network is slow" or "it takes forever to access the Internet," I'd consider setting up a little batch file to perform FTP file downloads - I'll set up my sample system so that my packets cross the most common links on the network. By setting up this trigger, I'll catch the traffic that occurs around the time the network begins to bog down. I would look for any indication of routing problems, broadcast/multicast storms, traffic hogs, etc. In this case, I'd put my analyzer on the inside of the firewall or directly below the most active network server.
   
   
3. LAN Overload Percentage: This alarm is triggered when the network utilization goes over a defined percentage rate. I'd look at the general traffic around this time to find out who or what is hogging the bandwidth. If this is going off all the time, I'd look for a common cause and work on resolving it if it's causing retransmissions and timeouts on the network.
   Puff, puff…. Next, we need to define what packets should be captured and when this capturing should stop.

The Capture Filter

The capture filter option (seen in Figure 1 in the Start Trigger section) enables you to specify the packets that should be captured once the trigger starts. For example, if you only want to see the broadcast packets on the network after a broadcast/multicast alarm triggers the capture, simply build and select a broadcast filter.

This can be really helpful to reduce the amount of traffic that you save in the buffer. You can also use the "Save to File" option to save trace files for review at a later time.

The Stop Trigger

The stop trigger defines when the analyzer should turn off the capture function. The stop trigger can be based on a date/time setting, an alarm or an event (filter) that you specify.

In addition, you can state that you want to capture a few extra packets after the stop trigger criteria has been met. This is particularly useful when you are capturing all traffic in a wrapping buffer (first in, first out) and you have a stop trigger defined on some problem. Ideally, you'd like to see what lead up to the problem and then you'd like to see some of the packets that crossed the network after the problem.

There are two restarting/looping options listed at the bottom of the trigger window as well.

Automatically Restart Capture After Stop

This check box is inside the Stop Trigger area - check this box when you want the analyzer to automatically start capturing traffic again after the stop trigger has occurred. Clicking on this setting alone does not mean that the start trigger criteria must be matched again. It simply means that the analyzer will immediately start capturing again after the stop trigger is reached.

Repeat Mode

Set the analyzer in repeat mode when you want to repeat the Start Trigger and Stop Trigger process multiple times. Unlike the previous "automatic restart" function, repeat mode requires that the start is launched based on the start trigger criteria.

I hope you start working with the triggers - they can really help out when you're determined not sit around and watch traffic all night long! -- Laura

The following section gives you some ideas of how you can use triggers on your network: Trigger Examples and Ideas:

• Someone sends packets from a specific machine in the middle of the night. Build a filter on the subject device (hardware/IP address filter) - use this as the event filter. Use the same filter as the capture filter so you will only capture all traffic to and from the subject system.

• NDS error packets are sent from a server and then you want all other traffic to/from that server. Set up a filter on the NDS error and another filter on the server's address.

• ICMP traffic in the middle of the night… Build a filter on all ICMP traffic and set that up as your event start trigger. Set up the ICMP filter as your capture filter. Cool! I love to watch ICMP traffic overnight.

• TCP handshakes to a specific server…Set up a filter for the TCP handshake process (see that Packet Filtering book!). Use this filter as your stop trigger event. Set up the system to save additional packets after the stop trigger is hit.

• Someone trying to telnet to the network router…Set up a telnet filter. You can use this as either the start filter and capture a bunch more packets or set this up as the stop trigger and capture a bunch more packets. Either way, you'll find out who's trying to get to your router!

Special thanks to Todd Reibling for suggesting this topic! Got something you'd like to have more details on? Send us an email at ideas@packet-level.com.

Got other ideas for articles/documentation or training? Send email directly to Laura at lchappell@packet-level.com.

Laura Chappell
Sr. Protocol Analyst
Copyright 2000 Protocol Analysis Institute, L.L.C.

Other Articles:
• Catching the Lovsan Worm in Action [PDF]
• Time is of the Essence
• The Wonderful Thing About Triggers... [PDF]
• The Pain of Gnutella
• About the 2301 Traffic
• 10 Cool Things You Can Do with the EtherPeek Demo [PDF]
• Basic Packet Filtering [PDF]
• Advanced Packet Filtering [PDF]
• Looking at the Sniffer Dashboard [PDF]
• TrenchTime: Ports to Watch
• Did Your Know: Wireless Networks are Not Immune to Sniffing? [PDF]
• The 10 Truths of Network Troubleshooting [PDF]
• Carnivore? [PDF]
• Sniffer: Using the Capture Panel [PDF]