When it comes to monitoring a network, most of the emphasis traditionally seems to be placed on the servers. Although it is important to keep tabs on your servers' performance, it is also important to monitor hardware devices such as switches and routers. After all, these devices make up the backbone of your network. You need to be able to tell not only that these types of devices are functional, but also that they are not being saturated by excessive traffic. In this article, I will share some techniques you can use to monitor utilization of network hardware. My discussion will focus primarily around switches, but similar techniques can be applied to other types of network hardware.
The problem with switches
When it comes to monitoring hardware utilization, switches present a special problem. In the normal method for measuring network utilization, a sniffer monitors packets of data as they flow across the network. If nodes on a network are connected by a hub, it is possible to plug a sniffer into an empty port on that hub and monitor all of the traffic that flows through it. This is because all the nodes that are plugged into a hub share a common collision domain. When a node transmits a packet of data, that packet is sent out through the hub's ports and is received by every device connected to the hub. (Unless a device is running in promiscuous mode, it will ignore packets of data not intended for it.)
Switches, however, are designed to isolate ports. When a packet of data passes through a port on a switch, that packet is sent to only the port to which the destination device is connected. A switch offers much greater performance than a hub because you no longer have to worry about collisions. At the same time, this means you can't just plug a sniffer into an empty port and monitor all the traffic flowing through that switch. This makes monitoring a switch's utilization especially tricky.
Another factor that makes monitoring switches tricky is that there is no real standard for switch design. Every manufacturer builds a different set of capabilities into its switches. Therefore, a monitoring technique that might work on a Cisco Systems Inc. switch might not work on a 3Com Corp. switch.
Port mirroring
Most of the higher-end switches manufactured in the past few years support a feature called port mirroring. The basic idea behind port mirroring is you can mirror the traffic that's flowing through ports of your choosing to a special monitoring port. Port mirroring is a generic term; the various switch manufacturers each have their own names for the technology. For example, Cisco calls port monitoring SPAN, which stands for Switched Port Analyzer.
Port mirroring is not commonly enabled by default. It is usually up to an administrator to choose which ports should be monitored. Cisco switches use CatOS, which allows the administrator to configure the switch through a command line interface (some switches also provide a graphical user interface). For example, if an administrator wanted to enable port monitoring on ports 1, 2 and 3, and use port 6 as the destination port, he or she could use these commands:
Monitor session 1 source interface fastethernet 0/1, 0/2, 0/3
Monitor session 1 destination interface fastethernet 0/6
Keep in mind that these commands only enable port mirroring. It is still up to you to attach a sniffer to the monitoring port and interpret the data the sniffer collects. It is worth noting that not all sniffers are created equally. Some sniffers do not perform any capacity analysis. I tend to think a better solution is to look for a network monitoring application specifically designed for monitoring switches. An example of such a product is OpManager from ManageEngine.
I'm not necessarily recommending this particular application, because I have never used it before. The reason why I mention it is because it has some very useful switch management features. The software is able to monitor traffic levels flowing across a switch, and compare those levels to threshold values. The software can be configured to trigger an alarm if a threshold value is exceeded.
About the author:
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer he has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at www.brienposey.com.
