I want to look at how you can find - and fight - bandwidth-hungry applications and other bandwidth busters on LANs. After looking at several alternative solutions to the problem, I've settled on Network General's Distributed Sniffer. Sniffer products are like electrocardiograph units used to monitor your heart's performance. Network General's Distributed Sniffer system uses a centralised server in conjunction with remote nodes connected to various segments on your LAN or WAN. Data about each monitored network segment is forwarded to the server unit for analysis and review. The sniffer can be an exceptionally effective tool in mapping out bandwidth usage, diagnosing performance woes, and boosting LAN/WAN performance.
Today's LANs typically interconnect several departmental networks and, in many cases, have bridged links to other networks that LAN administrators don't know about. In our research department, network performance nosedived recently and a sniffer revealed that a local, multidepartmental LAN was bridged to other networks. Those networks were spewing SAP and RIP broadcasts and source-route bridged traffic, and were generally wasting precious bandwidth.
Although several very good sniffer-type products are on the market, the reasons I like Network General's sniffers are pretty straight-forward. First, they are easy to use. Second, the Distributed Sniffer enables me to connect monitoring nodes to various parts of a network. In this way, I can surround a router or switch that is performing suspiciously. Third, the products offer auto-analysis, which means you don't need a PhD to understand what the data means. And fourth, I can easily place the monitors as probes anywhere on my network.
With the portability of these monitors, I can use triangulation and correlation methods to assess what is really happening over the wire. Network General's monitors can transfer information using in-hand or out-of-hand mechanisms. Once at the server, the data can be correlated and analysed using some of the company's newer reporting tools. For example, after monitoring three or four points in the LAN for several days, you might discover that several servers are responding to the Get Nearest Server request. That can lead to connection problems for workstations.
After a few days of monitoring, I discovered that older print stations still running Novell's PSERVER were spewing garbage broadcasts that showed up on LAN segments two floors away. Talk about wasting bandwidth!
Hewlett-Packard JetDirect cards were also identified as noisemakers. It turns out older JetDirect cards have broadcast properties in NetWare and Windows NT environments that can clog channels as the printer server announces its availability to the world (HP has resolved this in later revisions.)