SNMP Tutorial Part 2: The Management Information Base (MIB)

Understanding this layered model makes it easier to troubleshoot communication problems. When there is a problem, you can simply trace it down...

Now, we continue to examine the Simple Network Management Protocol (SNMP). We'll focus specifically on the layered communication model used to exchange information. Our last article focused on the structure of SNMP messages, however an SNMP message is not sent by itself. It is wrapped in the User Datagram Protocol (UDP), which in turn is wrapped in the Internet Protocol (IP). These are commonly referred to as layers and are based on a four-layer model developed by the Department of Defense (you may recall the DoD origins of the Internet).

SNMP resides in what is called the Application layer. UDP resides in the Transport layer. IP resides in the Internet layer (somewhat obvious). The fourth layer is the Network Interface layer where the assembled packet is actually interfaced to some kind of transport media (i.e., twisted pair copper, RG58 co-axial or fiber).

While this multi-layer model may seem a bit confusing, it effectively isolates the tasks of communication. In the end, it assists in designing and implementing a network.

Traversing the Layers.

To illustrate the function of this layered model, let's look at a single SNMP GET request from the agent's perspective. The SNMP manager wants to know what the Agent's System Name is and prepares a GET message for the appropriate OID. It then passes the message to the UDP layer. The UDP layer adds a data block that identifies the manager port. This is where the response packet should be sent. It's also the port on which it expects the SNMP agent to be listening for messages. The packet thus formed is then passed to the IP layer. Here a data block containing the IP and Media Access addresses of the manager and the agent is added. Then, the entire assembled packet gets passed to the Network Interface layer. The Network Interface layer verifies media access and availability and places the packet on the media for transport.

The packet works its way across bridges and through routers (the modern equivalent of over the river and through the woods) based on the IP information. Then it finally arrives at the agent. Here it passes through the same four layers in exactly the opposite order as it did at the manager. First, it is pulled off the media by the Network Interface layer. After confirming that the packet is intact and valid, the Network Interface layer simply passes it to the IP layer. The IP layer verifies the Media Access and IP address and passes it on to the UDP layer where the target port is checked for connected applications. If an application is listening at the target port, the packet is passed to the Application layer. If the listening application is the SNMP agent, the GET request is processed as we have discussed in previous articles. The agent response then follows the identical path in reverse to reach the manager.

SNMP Layer Application
An SNMP message passes through the protocol layers at both the manager and the agent. Each layer addresses a single communication task.

An Aid for Troubleshooting.

Understanding this layered model makes it easier to troubleshoot communication problems. These might include TCP/IP problems, MIB problems, or a variety of other types. When there is a problem, you can simply trace it down, out one end, into, and up the other. LAN/WAN link and activity status indicators provide some visibility to the Network Interface layer. ICMP echo requests and responses (Pings) provide some information regarding the proper functioning of the IP layer. SNMP processing indicators can be used to verify the passage of the packet through the UDP layer. They also check the functioning of the Application layer. Each step can be verified independently until all steps are working correctly for end-to-end communication.

SNMP is a standard protocol that has wide acceptance in the industry and is flexible enough to describe almost anything. Because of these advantages, many network managers have come to believe that SNMP should be used for all network monitoring applications.

SNMP certainly has its place in an effective telecom network management solution. This doesn't mean that any off-the-shelf SNMP manager can provide adequate visibility and control of your network, though.

The typical off-the-shelf SNMP manager is not designed for displaying and processing telemetry data for effective network monitoring. This counts double for the kind of real-world monitoring tasks network managers most need performed. These capabilities can be added to an SNMP manager, but it usually requires substantial custom software development.

Before you buy... make sure you avoid these 7 common mistakes.

Relying on off-the-shelf SNMP systems for mission-critical telemetry is a major mistake. What if you're switching from traditional telemetry or integrating non-SNMP monitoring with an SNMP-based system? An off-the-shelf SNMP manager will not provide what you need and expect. You won't get detailed alarm data. Before you commit to an SNMP monitoring solution, you need to make sure it supports key network alarm monitoring functions.

There are seven common mistakes network managers typically make when integrating SNMP and non-SNMP monitoring. Your SNMP implementation will be successfully only if you can avoid them.

  1. Selecting a system that doesn't provide complete, precise alarm descriptions.
    A basic SNMP manager doesn't record the location, time, severity, or a precise description of alarm events. To adapt an off-the-shelf SNMP manager to monitor these factors, you must create and maintain a master alarm list. This list represents all the monitored points in your network. Then you must also create and maintain a database. That database will associate all the traps that may be sent to the SNMP manager with the alarms on that list.
  2. Settling for a system that can't identify cleared alarms.
    Even more database work is required to identify whether a trap matches to an alarm condition or a clear condition. Creating this addition to the trap association database often requires analyzing a lot of variable bindings within the trap packet.
  3. Not maintaining a history of standing alarms.
    Relying solely on a basic SNMP manager for network alarm monitoring is not wise. That can potentially result in completely losing visibility of threats to your network. A basic SNMP manager doesn't maintain a list of standing alarms. Instead, the typical SNMP manager maintains an event log of newly reported traps and a history log of acknowledged traps. As soon as a trap is acknowledged, it is considered cleared. Imagine what might happen to your network if a system operator acknowledges an alarm. Then, for whatever reason, that operator fails to correct the alarm condition. Who would know the alarm is still standing?
  4. Not identifying system operators.
    Basic SNMP managers do not record the identity of the system operator who acknowledges an alarm. In the example of the negligent system operator, it would be impossible to determine who had made the mistake. You couldn't assign responsibility for the resulting problems.
  5. Trusting a system that's insecure for a lot of users.
    Out of the box, the typical SNMP manager is not designed for multi-user security. All traps are posted to one alarm list; all users may view all alarms, and all users may acknowledge all alarms.
  6. Broadcasting all alarms to all system users.
    Basic SNMP managers have no built-in functions for organizing alarms by logical group. The can't post the same alarm to multiple logical categories. They can't sort which alarms the user wants to see. Let's say that Jones is in charge of all gear for the Western region. Smith is in charge of power plants. Both need to know about a generator failure in Tucson. Neither one needs to know about all the alarms in the network. And if one manager corrects the alarm condition and acknowledges the alarm, the other manager needs to know it was acknowledged and by whom. Unfortunately, standard SNMP managers will not support these functions.
  7. Allowing yourself to be bombarded by nuisance alarms.
    No SNMP manager supports the advanced features needed for best quality telemetry monitoring. These features include notifications escalation, legacy protocol mediation, and nuisance alarm silencing. They also include automatic control relay operation and automatic alerts by pager and e-mail.

Requirements for Extensive Customization Reduce the Advantages of an Open Standard.

It is true that many, but not all, of these functions can be added to standard SNMP managers. Don't forget that implementing network alarm monitoring in a basic SNMP manager isn't easy. It usually involves a substantial amount of custom software module development. Even when pre-built software modules are available, they usually require custom tweaking to perform exactly as you want them to.

The need for extensive customization eliminates the advantage of using a simple open standard. It is difficult to justify significant development costs after purchasing an already expensive SNMP manager. Why take the time, trouble, and expense to recreate capabilities? These functions are already present in a high-quality, SNMP-capable network alarm management system?

The Right Role for Your SNMP manager.

Relying on an SNMP manager for critical network monitoring just doesn't make sense. It doesn't take into account the tons of legacy and non-SNMP equipment that is functioning perfectly fine out in networks all over the world. That gear works. Don't throw it away. The role of an SNMP manager is best used for inventorying network devices. You can also use it for drilling down into equipment details. This is mostly done after your network monitoring system notifies you of a problem.

SNMP can be an effective tool. Still, it's only one item in your network alarm monitoring toolkit. It can be used more effectively when it is part of a total network monitoring solution.

The T/Mon Network Alarm Monitoring Solution.

If you are looking to avoid these 7 mistakes, then the T/Mon network alarm monitoring system is for you. It is specifically designed to avoid them. What about Network managers who rely on T/Mon for their network alarm monitoring, notification, and control? What do they say? "Looking at one map and knowing it represents every piece of equipment you're monitoring in the field... that's pretty good peace of mind."

SNMP Tutorial Part 1: The MIB, the manager, the agents...

SNMP Tutorial Part 3: Protocol Packet Types and Structure