This chapter is from the book
This chapter is from the book
This chapter is from the book
Packet Analyzers
Because packet analyzers capture entire data link frames from the wire, you can use their sophisticated software modules to decode these frames and the encapsulated packets, enabling you to examine them for protocol and application problems. (See Figure 21.2 for a sample decode window.) The fact that software analyzers are not hard-coded into chips makes them extremely flexible; you can evaluate and purchase different ones as you need them, install them on a laptop, and use the one that seems to best suit the problem at hand.
){kind=link}
Figure 21.2 Decoding the reply packet for an ARP (Address Resolution Protocol) exchange.
Packet Analyzers, Typical Operation
Most packet analyzers have two modes of operation:
Capture/Monitor mode
Decode
During the capture phase, the analyzer can perform some statistic gathering, including number of errors per station, number of packets transmitted/received by each station, network utilization (how congested the network is), and so on. The really cool analyzers will show you graphs, let you sort by "most talkative station," and so on during the capture phase. The decode phase allows you to sift through the specific data that the analyzer captured (the equivalent of reading the transcript of a party-line wiretap).
Captive Packet: Capturing
Capturing everything on a shared network is possible—although it's resource intensive on your analyzer! Consider a busy 100Mbps network: At a conservative estimate of 6MBps, that would mean you would need 360MB of physical memory (virtual memory simply isn't fast enough to keep up) to capture a minute's worth of data. Gigabit Ethernet? Sorry, you need specialized hardware to even capture the data on a gigabit link, at least as of this writing. (A PCI bus can't keep up with a full-bore gigabit pipe.)
10Mbps Ethernet isn't bad, roughly only requiring 90MB and 36MB, respectively, of physical memory to keep up with a minute's worth of data. Still, that's a lot of stuff to sift through and store. How do analyzers deal with this?
Most analyzers have a certain "buffer space" they allocate to capture data. When the buffer is full, you have an option to stop capturing or you can simply discard data at the "end" of the buffer to make room for new data (see Figure 21.3).
){kind=link}
Figure 21.3 An analyzer can either discard the oldest data once the buffer is full or stop capturing altogether.
TIP
Check with the provider of your software analyzer to see what kind of network interface you need to keep up with the network that you're analyzing. Some hardware is more supported than other hardware; some cheapie drivers and/or hardware won't be able to keep up with full 100Mbps Ethernet and will end up missing some traffic.
How do you deal with this? In other words, are network troubleshooters expected to pore over hundreds of megabytes worth of data to find the problem? No, certainly not. Just as police aren't expected to listen to 50 random wiretaps at once, an effective network troubleshooter should only be expected to scan through a limited number of network conversations at a time.
You usually won't be capturing all the data on the wire. When you are, you're probably concerned with statistic gathering, and you're not really interested in looking at the specifics of what each packet contains—that is, packet analysis. So, for packet analysis, depending on the scenario, you'll tell your analyzer that you're only interested in capturing traffic specific to the following items:
Network or data link protocols
Workstation identification (data link or network)
Service protocols
Miscellaneous packet or frame data
This way, you seriously cut down the amount of data you need to sift through. This is a very important function of any analyzer. The ability to ignore irrelevant data allows you to target the problem and solve it much quicker. Another interesting and useful function is the trigger function; this allows you to tell your analyzer to only start capturing when it sees a certain event on the network (for example, when a certain traffic threshold gets reached).
Secret Decoder Ring: Decodes
After a capture, the analyzer enables you to look at the data you've captured. The analyzer uses software modules called "decodes" to translate the bits and bytes from within the frame into human-readable form. Will all the bits and bytes be translated? Well, maybe not. If not, why not? Well, there are three types of translations that your analyzer has to accomplish before you can view data:
MAC (data link)
Network (network protocol)
Service (server or application oriented)
The MAC layer is sort of simple: There aren't that many ways that you can put data on the wire, and the specifications for this are fairly well laid out. It gets a little more complicated with the network protocol layer because network protocols are more complex, and therefore have more "fields" to interpret. It gets very complicated when you get into services. There are hundreds and hundreds of services, and it's just not possible for every analyzer to be great at decoding each one. Think of it as expecting your translator in another country to also be a good golfer, electrician, doctor, technician, dancer, and architect. Sure, you might find such a translator—but you'd probably have better luck finding several translators with those skills.
Here's the bottom line: Not every analyzer can handle every service. Although the common ones, such as Telnet, DNS, and Microsoft file and print, are pretty well covered, others are covered scantily, and still others are not available at all. Typically, the more proprietary a service protocol is, the less likely that there will be a widely available decode for it. For example, although every protocol analyzer in the universe deals with HTTP (see Figure 21.4 for an Ethereal decode of an HTTP session), there is no decode that I know of for WiredRed's E/Pop, a multiuser chat and remote control program.
){kind=link}
Figure 21.4 Ethereal, a Unix-based analyzer, showing the decode for packet containing HTTP data.
Is this a disaster? Not really. Even though the analyzer can't decode the service so that you can read it, it's still capturing what's going on. If you're working with tech support for a proprietary service, you can bet that they'll be able to read your trace using in-house decoders. After all, for our purposes, one of the primary reasons to use a protocol analyzer is to capture evidence to submit to a vendor, and if the vendor can't decode its own service, we're all in trouble.
Experts: Dave, I'm Afraid I Can't Analyze That
Some packet analyzers have an "expert" mode, which, during packet capture, makes a guess at what could be wrong with your network. In theory, this is wonderful. You and I can't sort through hundreds of conversations at once; this is the sort of job that's well suited to a computer.
In practice? Well, my experience with "expert" analyzers has convinced me that they're somewhat less than expert. Sure, they pick up on workstations that are running slowly—they're very good at seeing that a workstation has a significant delay in responding to a request. They're also good at seeing duplicate IP addresses and other simple problems. But expert? Not really. Teaching a computer how to solve complex network issues would probably be just as hard as teaching a computer how to think. They have no idea how to differentiate the little things that might be wrong with your network from the big thing that is preventing payroll from running.
The truth of the matter is, in any large network, there will be some problems. How do you start prioritizing them? Based on what some expert system tells you, or your users? Sure, you'll go with "user pain."
The bottom line is don't think of an expert analyzer as a panacea for all your hard network problems. An expert is a good tool, and is really useful for identifying a limited set of problems that it has been "taught" about. In combination with your own situation analysis, expert analyzers can be very powerful allies in your troubleshooting wars; in some cases they might actually point to the root cause of a given problem.