Fishing with a Sniffer
Just about everyone in the network support business has used a network analyzer -- or sniffer, named for one of the better-known brands -- at one time or another. Gathering and picking through packet traffic with a LAN or WAN analyzer, usually as a last resort after other diagnostic tools fail us, is considered a high art in our line of work. But how many of us really know how to use these things?
Packet analyzers listen to the conversations among networked devices. They exploit the fact that LANs, in general, are like big party lines: everything every device says on a LAN is present on the wire, where it can be picked up by network analyzers. As the sniffers collect packets, they typically apply standardized network protocol rules, such as TCP/IP, in reverse. By decoding the binary traffic and displaying the headers and data symbolically on their displays, they make it easier to interpret what's been collected.
But in my experience, most of us typically misuse these tools. Here are a few common mistakes.
The first mistake people usually make is under-filtering. Novice LAN analysts enthusiastically hook up to production networks, then turn on their analyzers, gathering everything in sight -- often thousands of packets in a few seconds. With this technique, appropriately called fishing, there's little chance that accurate indications of a network problem will jump off the crowded screen. Of course, this doesn't stop the novice from spotting packets here and there, then jumping to misleading conclusions. "Too much broadcast traffic!" "Look at all those SAPs!" Yeah, right.
It doesn't take much picking through a huge pile of packets before the novice discovers the analyzer's filtering capabilities. Analyzers can be configured to filter out certain kinds of traffic, based on almost any criterion, from MAC and IP addresses, to socket values, to protocol types -- or any combination of these. This often leads to the second common mistake: over-filtering. Over-filtered traffic narrowly focuses on one or two protocols or devices, usually excluding the traffic that's actually causing the problem.
Eventually, with some experience and maybe a little outside advice, the novice finally gets the filters right -- only to fall victim to the third mistake: hidden packets. As LAN technology has advanced over the past several years, LAN devices have become smarter. While plugging an analyzer into an old-style LAN hub will expose it to all network traffic, plugging it into a new-fangled switch or into a hub cascaded from a switch will expose only the traffic the switch has "sub-routed" into the analyzer's part of the network. Switches may look like hubs, but they behave like filters, directing LAN packets selectively through the ports to which they've learned their intended destination devices are attached.
Thus, successful network sniffing depends on four factors.
The utility of a traffic analyzer is determined not by the product's features, but by its user's brain. A basic understanding of the protocols being analyzed -- not just the definitions of header symbols, but their dynamics -- is a prerequisite for effective use of a traffic analyzer. The best way to learn what you need to know is by using an analyzer. But the worst time to start learning is when you're trying to solve an urgent network problem.
Effective LAN analysis starts with a few problem hypotheses to test with the analyzer. Maybe the problem seems like a router problem. Perhaps it leads you to suspect that a DHCP or WINS server is malfunctioning. Take a few minutes to formulate meaningful tests, and look specifically for traffic that will convict or acquit your suspects.
Stay flexible and alert while collecting your samples. If you see something you don't understand, take some time and try to learn enough about it to rule it out as a cause of the problem.
Finally, while you should feel free to discuss what you see with colleagues, don't holler eureka until you've actually found the culprit traffic. In their rush to prove themselves to their peers, novices often loudly announce every anomaly they uncover as the problem. False positives confuse everyone, and may stop others from successfully pursuing an answer. -- Al Cini is a senior consultant with Computer Methods Corp. (Marlton, N.J.) specializing in systems and network integration. Contact him at al.cini@computermethods.com.