> > > Tip of the Month

Tip of the Month

April 2001

The Wonderful Thing About Triggers Is That Triggers Are Wonderful Things!

As you become more experienced with the features of your protocol analyzer, you will appreciate the benefits of applying Triggers from time to time.

Triggers are set up like filters; but, instead of accepting only certain frames into the capture buffer, Triggers start or stop the capture. You may want to set up a Trigger that will continue capturing packets after a trigger event so that you capture packets that led up to as well as follow the event. EtherPeek, TokenPeek and AiroPeek allow you to have simultaneous captures from one adapter. The first capture can be set to stop on the Trigger while a second can be set to start on the Trigger. That way, you can look at a buffer of packets that led up to the event and a second buffer of packets after the event.

If you know the precise event that you are waiting for, such as an ICMP packet containing a "host unreachable" message or a packet from your server containing an SMB return code of "invalid password," setting up a Trigger is very straight forward. Simply start with a trace containing the event you are looking for and look inside the packet of interest for the appropriate patterns and offsets to set up your Trigger. Don't have such a trace? Then force the event yourself while capturing with your analyzer.

Now for the challenging part. What if you have no clue what the event will be? For example, what if there are random times that your server locks up for no apparent reason? This is where a couple of handy analysis tricks come into play.

Trick #1: Detecting a failed server.

This technique is for Windows-based servers but can be generalized for other servers and services as well. Set up the following batch file on a workstation:

:TOP
NET VIEW \\A_SERVER
If errorlevel 1 GOTO FAIL
GOTO TOP
:FAIL
PING 215.16.173.4

Make sure that \\A_SERVER is the name of the server in question, and that the Ping IP address is either your analyzer or one that will cross the segment where your analyzer is located. Then, set up your Trigger to recognize a Ping (ICMP Echo) packet to 215.17.173.4 from the IP address of the workstation performing the Ping. That way, when the server fails, the NET VIEW command will time out and the Ping statement will be executed, sending a packet to cause your analyzer to Trigger! As with any Trigger, always test it first (a manual Ping in the above example will be sufficient). Also, make sure that you test the load on your network of the batch file. Despite the tight GOTO loop in the example, this batch file actually consumes less than 1% of a 100 Mbps Ethernet.

Trick # 2: Stopping the analyzer remotely.

Suppose your server or some other device fails. Assuming that you have a nice large buffer and have a near immediate notification from a user or help desk that something has failed on the segment being analyzed, simply set up a Trigger similar to the first example, but manually ping the analyzer from your desktop with a Trigger set on an ICMP Echo packet from your IP address.

All registered and unregistered trademarks are the sole property of their respective owners