Previous Table of Contents Next Each SNMP agent can be configured to broadcast a trap to the network (trap is just another word for an alert). If your network management station is listening for traps, it will raise a red flag to let you know about it. For example, it can page you or do whatever you wish. Traps provide excellent ways of letting you know that something is wrong with your network. However, in real life, a trap can also be a silly extravaganza. For example, the print servers that we use in my office will all send an SNMP trap out when their printers are offline. Argh! Give me a break. We've got hundreds of printers out there on the network, many of which are purposely offline at any given time (to change paper, add forms, and so on). There's no way I want all of them sending traps to my network management station every time this happens. Fortunately, when I configured the print server, I had the option to turn off this trap. (See Figure 22.2.) [22-02t.jpg] Figure 22.2 A dedicated print server with an SNMP configuration via a Telnet session. Some SNMP agents can be configured to send several different "levels" of traps to your network manager. This way, you don't get paged for silly stuff. For example, my GroupWise MIB defines certain traps as "informational" (for instance, when the post office first starts up) and others as "critical" (for instance, when the post office must go down). Obviously, I'd like to be paged for critical issues but not for informational ones. RMON The Internet MIBs (MIB-I and MIB-II) are a set of variables that allow individual devices to keep track of their internal status. But what about the status of the segment that the devices are on? That's where RMON comes in. RMON (Remote Monitoring) is an MIB defined specifically for a probe device-that is, a device whose sole purpose is to keep track of network traffic statistics. Is this much like a network analyzer? Well, yes and no. Each RMON probe does keep track of network statistics much like your analyzer does when it's capturing packets. However, RMON probes aren't expected to sit there and continually capture packets; instead, they're meant to sit there and continually gather statistical data about the network and other network stations. (Yes, some RMON probes will also act to capture specific packets from the network in conjunction with a network analyzer.) Because RMON probes are always active, when you have a problem, there's a pretty good chance that the probe has picked up what's going on. For example, rather than connect your sniffer or other network analyzer to the segment and chance missing the problem event on the network, you can simply ask the RMON agent what's been going on. Because RMON keeps track of utilization of each station, if the network is slow, you can check the statistical data and see your top talkers. Very neat. A package that supports RMON in combination with RMON probes also allows you to perform long-term statistical analysis on multiple segments, as well as create a baseline of how your network runs when it is healthy. This is really important when trying to figure out why the network is slow today when it wasn't yesterday; we'll discuss baselining more in Hour 23, "The Network Is Slow! Getting a Definitive Answer to a Subjective Question." Here are some examples of SNMP-compliant management packages: o Kaspia Network Audit Technology (www.kaspia.com) o Technically Elite MeterWare (www.tecelite.com) o HP OpenView (www.hp.com) o IBM NetView (www.ibm.com) o NetScout (www.netscout.com) Network Management Nonstandards I love standards because they ensure that everyone is reading from the same sheet of music. However, SNMP management stations and RMON tend to be large, expensive solutions, and sometimes they're overkill for what you want to do. Accordingly, many vendors provide their own proprietary monitoring tools or will even give you a combination of SNMP and proprietary monitoring software. There's nothing wrong with this. If it works for you, great! For example, Dell provides a modified version of HP OpenView's Server Manager-all it can do is monitor Dell servers, but if Dell servers are all that you have, no problem! ALR, Compaq, and HP all do this type of thing as well. Sometimes switch vendors and hub vendors will also provide their own monitoring package. Olicom, for example, provides a neat little Windows-based switch manager application that collects switch statistics, reports trouble, and so on. Such packages are handy when all you have are one vendor's switches, but this approach starts to break down if you've got to run 12 different programs to monitor 18 different pieces of equipment. In addition to vendor-supplied monitoring tools for particular pieces of gear, you can also use third-party monitoring tools that generically monitor any service or server that you choose. These tools work as follows: 1. Get a list of IP numbers and services (socket numbers) that the user wants to monitor. 2. Every so often, try to poll the service (check it using the appropriate protocol). 3. If something doesn't respond correctly, sound the alarm (via pager, email, and so on). This is actually a pretty cool way of monitoring your services; after all, SNMP might be working, but in the final analysis, you want to know that your service is working. Who cares if SNMP thinks that your Web server is up? If it's not actually responding to the service when a network station tries it, it might as well be a boat anchor! Many third-party packages are available; some monitor whether generic TCP sockets are "alive and listening," whereas others are complex utilities that are designed to monitor specific applications such as email or network databases. Previous Table of Contents Next