Have Sniffer Will Travel^®

by Tom Reynolds, Emeritus-Member of iLAN Founders

Network troubleshooting is a lot like a gunfight. Anyone can participate but only the experts survive--and the cost for failure is high. In the wild westerns of yesteryear, the butcher, the baker and the pot bellied sheriff were all eager to form a posse and would not rest till them bad guys were brought to justice. Unfortunately, the bad guys were faster, meaner and shot straighter. The town needed Wyatt Earp. He was the ticket to restore peace.

It’s the same with the network. Network importance has surpassed that of individual platforms or applications, as they now rely on the integrity of the network to deliver information to the end user. There is no end in sight for our continued dependence on enterprise networks, second only to telephone in dependence. Unfortunately, as the Network Analysis Forum stated: Network professionals require skill and knowledge in many technologies to solve complex problems. The technician trained in a server-based discipline, Novell or Microsoft NT, for example, is overmatched against a true bad guy, a complex network problem.

In a gunfight, it's not a fair fight if one side is blindfolded. Unfortunately, unless a technician has the ability to read and analyze network traffic, packet by packet, the technician is essentially blind.

Let's look at a simple, server-based problem. A NetWare server is slowing down. Users can't log on. What's the problem? More hardware is the normal answer. A network monitor, Novell's Lanalyzer for example, will show if a server overload condition exists. Assuming it does, the case is open and shut: more hardware!

Not so fast. An analysis of the packets indicates that the server-busy packets are sent only as a response to file requests--open, rename, create and delete files. Well now, that's different. We can diddle with the Novell set commands-directory caching, percent of disk used for directory, etc. Nothing happens. Turn off saving files after deleting [Immediate purge of deleted files=ON] and the problem goes away. What was happening was the application, a stock quote system used by a major money manager, created numerous temporary files. They were saved until the disk space was needed. Unfortunately, this put lots of unnecessary load on the server. The clue to successful server tuning came from the packets!

Most companies with a network of any size have competent network operating systems technicians-Novell or Microsoft. On the other hand, network troubleshooting, particularly packet analysis, is a specialty. It is almost impossible for a technician to get enough experience in this type of work on one company's network. As a result companies often turn to hardware manufacturers for specialized help. This is rarely the right place.

Chris Colt was not a good gunfighter. Chris Colt invented and manufactured the Colt 44 and the Colt 45. These were great guns, well ahead of their time. Nevertheless, Chris Colt would not stand a chance against a real bad guy. Colt might know how to make great revolvers, but the bad guys knew how to use them.

Lets look at another problem from a mixed bridge, router environment. The network is slowing down. There is too much utilization. In comes the router salesman. Yes, his experts confirm, too much utilization. Their instruments prove it. "Get rid of those bridges," croons the router salesman. "Segment the network. I have a design and a quote right here."

Hold it! A free design is worth just what you pay for it. An analysis of the traffic indicates a large amount of broadcast traffic. Now, broadcasts come from lots of activities, some important, some useless. Removing unwanted broadcasts is one useful method of reducing traffic. Unfortunately, finding the source of broadcast traffic is difficult in a bridged environment as packets appear on all networks with the same physical address. Time for more routers and fewer bridges? Not exactly. Bridges are not the plug and play units they are represented to be. By setting up monitoring on all major network segments simultaneously, a bridge traffic analysis will discover what traffic is going where. Armed with this data, we can determine the source of the broadcast traffic.

If we find, for example, NETBIOS broadcasts on segments where NETBIOS is not needed, we can set bridge filters that will eliminate this traffic. Unnecessary broadcasts can be generated from multiple sources, specific protocols and even specific vendor protocols that are usually overlooked--Bay Networks hubs for example. Now, pigs will fly before one vendor mentions a competitor's hub broadcast protocol, even if he happens to know about it, much less write filters to turn it off. Hardware salesmen have a purpose in life, and writing filters for someone else's hardware ain't it.

Now bridges may sound like old news but, today, equipment salesman are replacing routers with switches because the routed networks are thought to be inadequate. What are switches? Multiport bridges--multiport bridges that need bridge traffic analysis procedures to properly understand network traffic and eliminate unwanted packets. We have come full circle.

What's the point? Well, in both examples the technician started with a packet analyzer at hand. In fact, anyone with an NT 4.0 server has a packet analyzer. These days, packet analyzers are as common as six-guns in the old West. Everyone has one. However, in the old West, most cowboys couldn't hit the broad side of a barn. Bullets were simply too expensive for target practice. The same is true today of packet analyzers and the technicians who have them. Practice and experience make all the difference. In both cases the packet analyzer pointed to a solution that was unnecessarily expensive, and might not solve the problem anyway. It took analysis, based on experience, to locate the true problem and find the solution.

One place a company can get an experienced network troubleshooter is iLAN Systems, Inc. of Los Angeles. This company has about forty technicians and makes routine use of Sniffer®, Fluke®, Wavetek® and many other network tools. Their technicians will travel, anywhere, any time. However, in many cases this is not necessary. Assuming an Internet connection can be established, many problems can be solved remotely using the tools already built into the network.

If you would like to see a presentation
of a network assessment follow this link.

Contact Jack "Wyatt" Ng or call 800-678-iLAN.