Network and Protocol Analyzers Part 2

Establishing a Baseline

Before you begin to perform monitoring or analysis of the network usage and utilization, you need to establish a set of baseline data. To interpret the statistical data that you can collect using LAN analyzers, you need to have something with which to compare future measurements. Baseline data is used to define the normal operating environment for a system and provides a reference for monitoring and troubleshooting efforts.

Baseline data is useful not only for troubleshooting, but also for planning capacity and measuring the effectiveness of an upgrade. Things you should consider recording in your baseline documentation in addition to values you monitor with a LAN analyzer include such things as these:

• Location of equipment in the network
• Type of equipment in use
• The number and distribution of users
• Protocols in use

Knowing the type of equipment is important because different models of NICs, hubs, and other devices can vary widely in their performance. Knowing where each piece of equipment is located can enable you to create an audit trail for troubleshooting. For example, it is common in a business environment for users and workstations to be constantly on the move.

A simple weekend move, in which you take a few workstations or servers and move them to a different location, might have a dramatic, unexpected impact on the network. Suppose you have two servers that you want to move from a departmental location to a central computer room. When they were located on the same network segment as the users that use them the most, traffic was localized. Placing them on a different segment might cause capacity problems in a backbone link or in a device such as a switch or router that connects the network. If you keep track of hardware and statistical information about its performance and usage, you can usually prevent this sort of thing from happening. At least, you can look back and determine where a problem lies and be in a better position tofind a solution.

This same principle applies to the location of users in the network. Different users can make widely differing demands on a single workstation or server. Keep a list of users, the applications they use, and, when appropriate, the time of day they work in situations in which shift-work is performed.

Understanding the protocols that are used is also important. A simple problem that can be hard to figure out occurs when you move a device to a different network segment and are unaware that it is using a nonroutable protocol. Most routers can be configured to pass these nonroutable protocols (such as NetBEUI), but you need to be aware of this and configure the router accordingly before you make the move.

Finally, baseline data is going to be something that is cast in stone and unchangeable. Modify your documentation as the network grows or changes so that the data remains useful.

Statistical Data

Although most analyzers provide a wide range of statistical data, the analyzer should be able to give you a few general values.

First, be sure that the analyzer can give you statistics that tell you the utilization of the network. In addition to a real-time graphical display, you should also look for the capability to monitor the network and tell you when peak utilization occurs. That is, what times during the day does the network reach its busiest points? Overall utilization calculated over the average workday might not be nearly as helpful as identifying the periods of time when users are working their hardest and getting frustrated with a bogged-down network. Using peak utilization statistics, you can work to resolve the traffic problems by reallocating resources, or perhaps rearranging work habits of the user base.

Another statistic that is found on most analyzers is Frames Per Second (FPS). By itself, FPS isn't a revealing value, but when combined with data showing the size of packets traversing the network, it can produce meaningful data. The larger the packet size used by a protocol, the more efficient the protocol is likely to be. This is because each packet requires overhead necessary to implement the protocol, such as addressing and error-checking information. With a larger packet size, the ratio of overhead to payload is reduced.