Previous | Table of Contents | Next |
Most network analyzers have two modes of operation:
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 possiblealthough its 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 isnt fast enough to keep up) to capture a minutes worth of data.
Token-Ring and 10Mbps Ethernet arent this bad, roughly only requiring 90MB and 36MB respectively of physical memory to keep up with a minutes worth of data. Still, thats 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).
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 youre analyzing. For example, some hardware isnt 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 arent 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 well discuss later, you usually wont be capturing all the data on the wirewhen you are, youre primarily concerned with statistic gathering, and youre not really interested in looking at the specifics of what each packet contains. Therefore, the fact that the analyzer cant keep up is okay. Many times, depending on the scenario, youll tell your analyzer that youre only interested in the following items:
This way, you seriously cut down the amount of data you need to sift through. As well 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 youve 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:
The MAC layer is sort of simple: There arent 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 languages bits and bytes in order to display whats going on. It gets very complicated when you get into services. There are hundreds and hundreds of services, and its 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 translatorbut youd probably have better luck finding several translators with those skills.)
Heres 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 dont 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 cant decode the service so that you can read it, its still capturing whats going on. If youre working with tech support for a proprietary service, you can bet that theyll 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 cant decode its own service, were all in trouble.
Dave, Im Afraid I Cant 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 cant sort through hundreds of conversations at once; this is the sort of job thats well suited to a computer.
In practice? Well, my experience with expert analyzers has convinced me that theyre somewhat less than expert. Sure, they pick up on workstations that are running slowlytheyre very good at seeing that a workstation has a significant delay in responding to a request. Theyre 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 dont want to run down analyzers with an expert featurethey can be really useful for common simple problems. Just dont 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 |