Protocol Analyzers

Today there is a wide variety of troubleshooting tools for analyzing network problems. Cable testers, designed simply to register common electrical faults, may include sophisticated time domain reflectometry and digital signal processing to precisely localize fault conditions and rapidly examine performance over a broad bandwidth. Handheld troubleshooting tools may combine some cable-testing capabilities with NIC and hub testing, as well as with higher-layer protocol tests such as Ping and Traceroute. SNMP consoles, once found only on management platforms such as OpenView and SunNet Manager, are now commonly supplied with individual devices. They are also attached to Web servers, and used for network drawing and documentation tools, as well as built into handheld diagnostic devices.

As a result, many of the tasks that once required a protocol analyzer can be resolved with other tools. Nevertheless, most of the hardest and subtlest problems still require protocol analysis for complete resolution.

Analyze This

In its simplest form, a protocol analyzer captures all the traffic on a medium, parses it according to the rules of any network protocols that are present, and displays the results. Ethernet, the most widespread shared-network medium, is the most common interface for protocol analyzers, but any other Physical-layer or Data- link-layer medium that can redirect signals to a probe will have protocol analysis tools. Of course, on shared media and high-speed media, the analysis software will have to work harder than it would on point-to-point lines or low-throughput networks (see figure).

Figure 1: Protocol analyzers capture network traffic, parse each frame to identify the protocol that defines it, and pass the decoded traffic along for display or for further analysis.

Most shared-medium network technologies-Ethernet, Fast Ethernet, Token Ring, and FDDI NICs-support a "promiscuous mode" operation, where all the traffic on a segment or ring can be processed . Ordinarily, a NIC processes only frames with its own MAC address as the destination, as well as broadcast frames , which are intended for everyone by definition. If the NIC is switched into promiscuous mode, it can also capture unicast and multicast traffic sent to other nodes.

Most current protocol analyzers run on ordinary portable PCs, though some of the high-end models use proprietary OSs and hardware for detecting rare error conditions that ordinary NICs are blind to. (Some NICs that operate in promiscuous mode suppress bad frames, which is undesirable for protocol analysis if your network produces such things.)

The analyzer software takes the frames received by the NIC and typically writes them into a big capture buffer in RAM. Ordinary commercial CPUs can keep up with a saturated 10BaseT network, but not with 100BaseT. One option for dealing with high-speed networks is to apply filters before capture, eliminating particular protocols or particular addresses that seem extraneous to the problem. Alternatively, many analyzers now have dedicated hardware that can capture full-duplex , 100BaseT traffic-normally a package of RAM with as direct a connection as possible to the network, and an interface to send captured data to the analyzer software.

From a captured frame it's easy to display the source and destination MAC addresses. A Type identifier field indicates what higher-level protocol defines the payload of the frame. Applying the rules for IP, IPX, AppleTalk, SNA, DECnet, and other layer-3 protocols lets the software display the network addresses for the source and destination nodes, and branch out and unpack the higher-layer protocols. Once the Application layer is reached, the decoding job is finished and the captured traffic is ready for display.

Key Features

One essential element the analyzer adds to the display is a time stamp for each packet, which may be absolute or relative to some other time. Packet order and the duration of delays between particular packets are often crucial diagnostic information. Some analyzers have the valuable feature of supporting multiple views for the different protocol stack layers , reducing the quantity of data and simplifying the display.

Filtering the captured traffic at this point is also a valuable technique for focusing on the most relevant data. It's also quite useful for the analyzer software to convert hexadecimal data fields to ASCII text, at least when the payload is e-mail, text files, or HTTP data. Yet another very useful feature lets the user substitute names-either DNS or NetBIOS or NetWare device names, or arbitrary mappings of addresses to meaningful names -for numeric addresses in the capture display.

Traditionally, protocol analyzers stopped at this point and left it up to the often-flabbergasted user to figure out what was going on. Users needed to know in detail how the steps of a login procedure were carried out and what the meaning of various time-outs and error conditions were. They needed to understand how RIP and OSPF operated to define the transit paths through the network. They needed to understand how long SNA would be willing to wait for an acknowledgment before timing out and disconnecting.

While the definition of protocols is usually well-documented, the way they behave on a live network and the way they interact with one another is not generally well-documented, and often known only to engineers and programmers who have spent large portions of their careers examining protocol analyzer trace files.

The protocol analyzer makers responded to the shortage of experience in this area with software-based expert systems that could identify multi-packet patterns and suggest error conditions that might have caused the symptoms. Hewlett-Packard's Expert Advisor and Network Associates' Expert Sniffer were two of the earliest implementations of expert systems technology for protocol analysis, but most other vendors do much the same thing nowadays.

Filtering is another key feature in protocol analysis, as I mentioned earlier. Filtering before capturing runs the risk of not capturing the key problem indicators, but is sometimes unavoidable if the traffic level is too high for the analyzer to capture in real time. It's better to ignore rationally chosen traffic streams than to ignore random frames whenever the software can't keep up. Filtering after capture is an essential part of simplifying the display, and has no disadvantages because the data remains in the capture buffer or trace file, even if you filter too aggressively and fail to display the key data on the first attempt.

Aside from filtering by protocol and addresses, most analyzers permit you to define filters based on bit patterns anywhere within the frame. For example, you could easily search for packets containing specific text or with custom combinations of multiple layer parameters.

Capture buffers can be written to disk as trace files. The Network Associates Sniffer format is the most commonly used format, employed by practically every vendor. Trace files that can't be diagnosed at one site or by a particular model of analyzer can be sent elsewhere for deeper investigation.

Double Duty

Most modern protocol analyzers also perform network-monitoring functions. As long as they're vacuuming up all the traffic on a segment, it doesn't take much work to count total frames, collisions, error frames, and broadcasts; to keep track of which conversations generate the most traffic; or to display the rates at which these events take place. These statistics can be presented as graphs or speedometer gauges, or captured to files in order to generate reference baselines for future comparison.

If you're familiar with what an RMON system does, you'll probably recognize the similarity among these network-monitoring functions. RMON probes are generally distinct from RMON consoles with SNMP as the protocol that allows them to communicate, while protocol analyzers were not originally designed with this standardized distribution of functions. However, many protocol analyzers today can accept frames captured by an RMON probe and decode them as if they had captured them directly. This is a valuable capability, as the rise of switched networks threatens some of the utility of the protocol analyzer as a diagnostic tool.

Because protocol analyzers depend on promiscuous-mode NICs (or on some form of signal duplication or "mirroring"), their reach is bounded by the edge of the Ethernet collision domain (or the presence of a bridge or router on other topologies).

In the past, when dozens or even hundreds of users shared a single network segment, the protocol analyzer could capture all the problems and clues from a single location. Today, as users are divided into smaller subnets, or even into microsegments with a single switch port per user, the scope of the protocol analyzer has shrunk. On a switched Ethernet network with full-duplex ports, the protocol analyzer can't even capture traffic without a special capture port on the switch.

In some cases, switches come with RMON probes built into each segment. Unfortunately, these implementations are usually stripped-down versions of RMON that don't include the packet capture function that a protocol analyzer would require. Sometimes switches support a backplane connection that could give the protocol analyzer access to all of the traffic on the switch, but more often port-mirroring functions only support the redirection of one port at a time to the protocol analyzer.

One interesting extension of protocol analysis is the relatively new field of intrusion detection. The same sorts of "expert analysis" and pattern recognition that are employed to identify the signatures of misconfigured routers and broadcast storms can also be used to lock on to suspicious patterns of failed logins and inappropriate file browsing. The front end of the protocol analyzer is much the same as the front end of the intrusion detector; the primary difference lies in the patterns they are trained to detect.

Glory Days

In some respects, the heyday of the protocol analyzer has passed. Ten or even five years ago, network protocols were not implemented as sure-footedly as they are today. Many early networking mistakes have been solved and left behind, despite the fact that a network manager's day is still a full one. A modern switched network can practically be a plug-and-play environment.

Nevertheless, when a problem comes along that the cable testers, the handheld troubleshooting tools, and the SNMP management platform can't pin down, the only alternative is to fire up the old protocol analyzer and start capturing and decoding packets.

This tutorial, number 131, by Steve Steinke, was first published in the June 1999 issue of Network Magazine.