Previous Table of Contents Next Typical Operation Most network analyzers have two modes of operation: o Capture o Decode During the capture phase, the analyzer can perform 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 wire tap). Captive Packet 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. Token-Ring and 10Mbps Ethernet aren't this 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.2). [21-02t.jpg] Figure 21.2 An analyzer can either discard the oldest data once the buffer is full or stop capturing altogether. ______________________________________________________________ Check with the maker of your software analyzer to see what kind of PC hardware you need to keep up with the network that you're analyzing. For example, some hardware isn't able to run fast enough to capture 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 damning conversation? No! 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. As we'll discuss later, you usually won't be capturing all the data on the wire-when you are, you're primarily concerned with statistic gathering, and you're not really interested in looking at the specifics of what each packet contains. Therefore, the fact that the analyzer can't keep up is okay. Many times, depending on the scenario, you'll tell your analyzer that you're only interested in the following items: o Certain protocols o Certain workstations o Certain services This way, you seriously cut down the amount of data you need to sift through. As we'll discuss later, this is a very important function of any analyzer. Secret Decoder Ring After a capture, the analyzer will allow you to look at the data you've captured. The analyzer will "decode" the bits and bytes from within the packet into human-readable form. Will all the bits and bytes be translated? No, probably not. Why not? Well, there are three types of translations that your analyzer has to accomplish before you can view data: o MAC o Protocol o Service 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 protocol layer, because the analyzer needs to "understand" the language's bits and bytes in order to display what's going on. 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 good 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 and Novell file and print, are pretty well covered, others are covered scantily, and still others are not available at all! (For example, I don't know of anybody who makes a decoder for the popular Internet chat package ICQ. ICQ is a fairly proprietary service.) 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 network 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. Dave, I'm Afraid I Can't Analyze That Some network 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. Idiot savant would be more like it. In my opinion, a complex network problem must be dealt with by a human; there are just too many unknowns, too many guesses, and too much intuition involved to have a computer do it. Teaching a computer how to solve complex network issues would probably be just as hard as teaching a computer how to think. I definitely don't want to run down analyzers with an "expert" feature-they can be really useful for common simple problems. Just don't think of an expert analyzer as a panacea for all your hard network problems. However, in combination with your own situation analysis, expert analyzers can be very powerful allies in your troubleshooting wars; they tend to point you to bona fide problems that need further investigation. Previous Table of Contents Next