Previous Table of Contents Next


Hour 21
Tell Me About Your Network: Network Analyzers

Sure, most network troubleshooting cases that you’ll encounter will be “elementary, my dear Watson” (solvable by deductive reasoning alone). However, to solve your most hard-boiled network crimes, you’ll need to get a wire tap to give you the evidence you need. Network analyzers provide a type of “wire tap” that allows you to gather objective data about a networking problem.

Like a wire tap, network analyzers shouldn’t be used indiscriminately; you definitely want to use your noodle before you use your analyzer. You should always formulate a theory before breaking out the analyzer—otherwise, what are you looking for? (After all, it’s a big network out there.)

Still, when you run into a problem that needs an analyzer, it can be the difference between a stone wall and a breakthrough. After you’ve formulated a theory, analyzers can prove your theory by providing you tangible evidence to either sift through yourself or to give to a vendor for analysis.

What the Heck Is a Network Analyzer?

I have to smile every time I talk about network analyzers: I always think about a piece of network gear reclined on a couch, with some Freudian white-bearded psychoanalyst asking it about its origins. As silly as that seems, this picture isn’t far off—a network analyzer’s primary job is to listen while other network gear talks.

Here are the two basic kinds of network analysis tools:

  Cable scanners (hardware analyzers)
  Packet sniffers (software analyzers)

A cable scanner’s primary job is to test the electrical characteristics of your network wire. As we discussed in Hour 9, “Ethernet Basics,” CAT-V cable needs to have certain electrical characteristics, without which you’ll get data link errors. A cable scanner will test any particular cable run “end to end” and let you know if something is out of whack.

Some of the more sophisticated scanners will also listen to the signal on the wire to see whether there are physical or data link problems on your network. For example, the only way to truly detect collisions on an Ethernet network is to use a cable scanner. A cable scanner is fairly simple to use (turn it on, plug it into the hub, and watch for errors). However, it operates differently than other scanners and is expensive! (Typically $3,000 and up for a modern scanner.)

In contrast, software network analyzers will only listen to data link traffic, and they do not test the physical cable that the traffic is running on. A software analyzer is typically a PC with a special type of network card in it. Software analyzers rely on network cards that are able to run in “promiscuous” mode—that is, they’re physically able to listen for packets that are not destined for themselves. Nosy, nosy, nosy!


Software network analyzers are typically not very expensive. Some of them do run $10,000, but many of them are less than $1,000. See http://feldman.org/analyzers.html for a list of some of the less expensive software analyzers.

Also, check out the Network Monitor that comes with Windows NT Server 4.0. It lives in C:\WINNT\SYSTEM32\NetMon and works either with NT Server or NT Workstation. It only captures packets to or from the station that you use it on, and it has other limitations. A full-featured version of Microsoft’s Network Monitor is only available if you purchase Microsoft’s SMS (Systems Management Server). Still, the “vanilla” free version is a good way for you to get familiar with how this stuff works.


Finally, because software analyzers capture entire data link packets from the wire, they are able to use sophisticated software to decode these packets and allow you to examine them for protocol and application problems. (See Figure 21.1 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! There are a lot more options and applications for a software analyzer than for a cable scanner; we’ll examine software analyzer theory and practice in the remainder of this hour.


Figure 21.1  Decoding the reply packet for an ARP (Address Resolution Protocol) exchange.


Previous Table of Contents Next