Introduction to the Simple Network Management Protocol (SNMP)

SNMP was made with one design in mind… to be simple. SNMP is a simple protocol that
can be used on just about any networking device in use today. In some environments it’s
used heavily, in others it’s scarce. Some view it as a security threat; others see it as a way to
efficiently manage some of their key systems. However you decide to see it, SNMP is a
easy to use, easy to set up and not very difficult to understand.

The SNMP protocol was designed to provide a "simple" method of centralizing the
management of TCP/IP-based networks – plain and simple. If you want to manage devices
from a central location, the SNMP protocol is what facilitates the transfer of data from the
client portion of the equation (the device you are monitoring) to the server portion where
the data is centralized in logs for centralized viewing and analysis. Many application
vendors supply network management software: IBM’s Tivoli, Microsoft’s MOM and HP
Openview are three of over 100+ applications available today to manage just about
anything imaginable. The protocol is what makes this happen. The goals of the original
SNMP protocols revolved around one main factor that is still in use today: Remote
Management of Devices. SNMP is commonly used to manage devices on a network.

SNMP uses UDP

UDP stands for User Datagram Protocol and is the opposite of TCP, Transmission Control
Protocol which is a very reliable and high overhead protocol.

User Datagram Protocol is very low overhead, fast and unreliable. It is defined by RFC
768. UDP is easier to implement and use than a more complex protocol such as TCP. It
does however provide plenty of functionality to allow a central manager station to
communicate with a remote agent that resides on any managed device that it can
communicate with. The unreliability comes in the form of checks and balances whereas if
TCP sends something, it waits for an acknowledgment and if it doesn’t hear back, it will
resend. Since logging of devices usually happens within a time period that is cyclic in
nature, then it’s common sense that you missed the event and you’ll catch it next time… the
tradeoff being that the low overhead protocol is simple to use and doesn’t eat up all your
bandwidth like TCP based applications going across your WAN.

SNMP Operation

SNMP design is pretty simple. There are two main players in SNMP. The manager and the
agent. The manager is generally the ‘main’ station such as HP Openview. The agent would
be the SNMP software running on a client system you are trying to monitor.
The manager is usually a software program running on a workstation or larger computer
that communicates with agent processes that run on each device being monitored. Agents
can be found on switches, firewalls, servers, wireless access points, routers, hubs, and even
users' workstations – the list goes on and on. As seen in the illustration, the manager polls
the agents making requests for information, and the agents respond when asked with the
information requested.

Network Management Station (NMS)

The manager is also called a Network Management Station or NMS for short. The software
used to create the NMS varies in functionality as well as expense. You can get cheaper
applications with lesser functionality or pay through the nose and get the Lamborghini of
NMS systems. Other functionalities of the NMS include reporting features, network
topology mapping and documenting, tools to allow you to monitor the traffic on your
network, and so on. Some management consoles can also produce trend analysis reports.
These types of reports can help you do capacity planning and set long-range goals.

SNMP Primitives

SNMP has three control primitives that initiate data flow from the requester which is
usually the Manager. These would be get, get-next and set. The manager uses the get
primitive to get a single piece of information from an agent. You would use get-next if you
had more than one item. When the data the manager needs to get from the agent consists of
more than one item, this primitive is used to sequentially retrieve data; for example, a table
of values. You can use set when you want to set a particular value. The manager can use
this primitive to request that the agent running on the remote device set a particular variable
to a certain value. There are two control primitives the responder (manager) uses to reply
and that is get-response and trap. One is used in response to the requester's direct query
(get-response) and the other is an asynchronous response to obtain the requester's attention
(trap). As I mentioned earlier, I alluded to the fact that the manager doesn’t always initiate –
sometimes the agent can as well. Although SNMP exchanges are usually initiated by the
manager software, this primitive can also be used when the agent needs to inform the
manager of some important event. This is commonly known and heard of as a ‘trap’ sent by
the agent to the NMS.

The Management Information Base (MIB)

We just learned what primitives were… the agent and the manager, exchanging data. The
data they exchange also has a name. The types of data the agent and manager exchange are
defined by a database called the management information base (MIB).The MIB is a virtual
information store. Remember, it is a small database of information and it resides on the
agent. Information collected by the agent is stored in the MIB. The MIB is precisely
defined; the current Internet standard MIB contains more than a thousand objects. Each
object in the MIB represents some specific entity on the managed device.

SNMPv2 and SNMPv3

With all TCP/IP related protocols, it’s a well known fact that anything dating before the
creation of IPv6 (or IPng) has security weaknesses such as passwords sent in cleartext.
SNMP in its original form is very susceptible to attack if not secured properly, messages
sent in cleartext exposing community string passwords, or default passwords of public and
private being ‘guessed’ by anyone who knew how to exploit SNMP… beyond its inherent
weaknesses SNMP in its original implementation is still very simple to use and has been
widely used throughout the industry. SNMP in its first version lacked encryption or
authentication mechanisms. So, now that SNMP in its first version was good enough, work
began to make it better with SNMPv2 in 1994. Besides for some minor enhancements, the
main updates to this protocol come from the two new types of functionality, where traps
can be sent from one NMS to another NMS as well as a ‘get-bulk’ operation that allows
larger amounts of information to be retrieved from one request. SNMPv3 still being worked
on and is incorporating the best of both versions and enhanced security as well. SNMPv3
provides secure access to devices by a combination of authenticating and encrypting
packets over the network. The security features provided in SNMPv3 are message integrity
which ensures that a packet has not been tampered with while in transit, authentication
which is determining the message is from a valid source and encryption, which is the
securing of the packet by scrambling its contents.
SNMP Tutorial Series: 5 Quick Steps to
Understanding SNMP and its Role in Network
Alarm Monitoring
SNMP Tutorial Part 1: An Introduction to SNMP
SNMP Tutorial Part 2: The Management Information Base (MIB)
SNMP Tutorial Part 3: Understanding Packet Types and Structure
SNMP Tutorial Part 4: Layered Communication
SNMP Tutorial Part 5: Common Mistakes Made When Integrating SNMP and
Non-SNMP Systems

SNMP Tutorial Part 1: An Introduction to SNMP

Since its creation in 1988 as a short-term solution to manage elements in the growing
Internet and other attached networks, SNMP has achieved widespread acceptance.
SNMP was derived from its predecessor SGMP (Simple Gateway Management Protocol)
and was intended to be replaced by a solution based on the CMIS/CMIP (Common
Management Information Service/Protocol) architecture. This long-term solution,
however, never received the widespread acceptance of SNMP.

SNMP is based on the manager/agent model consisting of a manager, an agent, a

database of management information, managed objects and the network protocol. The
manager provides the interface between the human network manager and the
management system. The agent provides the
interface between the manager and the
physical device(s) being managed (see the
illustration above).

The manager and agent use a Management

Information Base (MIB) and a relatively small
set of commands to exchange information. The SNMP is based on the manager/agent
MIB is organized in a tree structure with model of a network management
individual variables, such as point status or architecture.
description, being represented as leaves on the
branches. A long numeric tag or object identifier (OID) is used to distinguish each
variable uniquely in the MIB and in SNMP messages.

SNMP uses five basic messages (GET, GET-NEXT, GET-RESPONSE, SET, and TRAP) to
communicate between the manager and the agent. The GET and GET-NEXT messages
allow the manager to request information for a specific variable. The agent, upon
receiving a GET or GET-NEXT message, will issue a GET-RESPONSE message to the
manager with either the information requested or an error indication as to why the
request cannot be processed. A SET message allows the manager to request a change
be made to the value of a specific variable in the case of an alarm remote that will
operate a relay. The agent will then respond with a GET-RESPONSE message indicating
the change has been made or an error indication as to why the change cannot be
made. The TRAP message allows the agent to spontaneously inform the manager of an
‘important’ event.
As you can see, most of the messages (GET, GET-NEXT, and SET) are only issued by
the SNMP manager. Because the TRAP message is the only message capable of being
initiated by an agent, it is the message used by DPS Remote Telemetry Units (RTUs) to
report alarms. This notifies the SNMP manager as soon as an alarm condition occurs,
instead of waiting for the SNMP manager to ask.

The small number of commands used is only one of the reasons SNMP is "simple." The
other simplifying factor is its reliance on an unsupervised or connectionless
communication link. This simplicity has led directly to its widespread use, specifically in
the Internet Network Management Framework. Within this framework, it is considered
‘robust’ because of the independence of the managers from the agents, e.g. if an
agent fails, the manager will continue to function, or vice versa. The unsupervised
communication link does however create some interesting issues for network alarm
monitoring we will discuss more thoroughly in a later issue of our tutorial.

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

top

Each SNMP element manages

specific objects with each object
having specific characteristics.
Each object / characteristic has
a unique object identifier (OID)
consisting of numbers separated
by decimal points (i.e.,
1.3.6.1.4.1.2682.1). These
object identifiers naturally form
a tree as shown below. The MIB
associates each OID with a
readable label (i.e.,
dpsRTUAState) and various
other parameters related to the
object. The MIB then serves as
a data dictionary or code book
that is used to assemble and
interpret SNMP messages.

When an SNMP manager wants

to know the value of an object /
characteristic, such as the state
of an alarm point, the system The branch of the MIB object identifier tree.
name, or the element uptime, it
will assemble a GET packet that includes the OID for each object / characteristic of
interest. The element receives the request and looks up each OID in its code book
(MIB). If the OID is found (the object is managed by the element), a response packet
is assembled and sent with the current value of the object / characteristic included. If
the OID is not found, a special error response is sent that identifies the unmanaged
object.

When an element sends a TRAP packet, it can include OID and value information
(bindings) to clarify the event. DPS remote units send a comprehensive set of bindings
with each TRAP to maintain traditional telemetry event visibility. Well-designed SNMP
managers can use the bindings to correlate and manage the events. SNMP managers
will also generally display the readable labels to facilitate user understanding and
decision-making.

SNMP Tutorial Part 3: Understanding Packet Types and Structure

top

This part of our tutorial on the Simple Network Management Protocol (SNMP) examines
the communication between managers and agents. Basic serial telemetry protocols,
like TBOS, are byte oriented with a single byte exchanged to communicate. Expanded
serial telemetry protocols, like TABS, are packet oriented with packets of bytes
exchanged to communicate. The packets contain header, data and checksum bytes.
SNMP is also packet oriented with the following SNMP v1 packets (Protocol Data Units
or PDUs) used to communicate:

1. Get
2. GetNext
3. Set
4. Trap

The manager sends a Get or GetNext to read a variable or variables and the agent's
response contains the requested information if managed. The manager sends a Set to
change a variable or variables and the agent's response confirms the change if
allowed. The agent sends a Trap when a specific event occurs.

The image below shows the packet formats. Each variable binding contains an
identifier, a type and a value (if a Set or response). The agent checks each identifier
against its MIB to determine whether the object is managed and changeable (if
processing a Set). The manager uses its MIB to display the readable name of the
variable and sometimes interpret its value.

SNMP Packet Formats

SNMP Tutorial Part 4: Layered Communication

top
In this fourth article in our series, we continue to examine the Simple Network
Management Protocol (SNMP) focusing 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 Understanding this
Internet Protocol (IP). These are commonly
referred to as layers and are based on a four-layer layered model makes
model developed by the Department of Defense
(you may recall the DoD origins of the Internet).
it easier to
troubleshoot
SNMP resides in what is called the Application
layer, UDP resides in the Transport layer and IP
communication
resides in the Internet layer (somewhat obvious). problems. When there
The fourth layer is the Network Interface layer
where the assembled packet is actually interfaced is a problem, you can
to some kind of transport media (i.e., twisted pair
copper, RG58 co-axial or fiber). While this multi- simply trace it down...
layer model may seem a bit confusing, it
effectively isolates the tasks of communication and ultimately 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 to which the response packet should be sent and 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 before 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.

After working its way across bridges and through routers (the modern equivalent of
over the rivers and through the woods) based on the IP information, the packet 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.
 An SNMP message passes through the protocol layers at both the manager and the agent.
Each layer addresses a specific communication task.

An Aid for Troubleshooting

Understanding this layered model makes it easier to troubleshoot communication

problems. 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 and
the functioning of the Application layer. Each step can be verified independently until
all steps are working correctly for end-to-end communication.

SNMP Tutorial Part 5: Common Mistakes Made When Integrating

SNMP and Non-SNMP Systems ... and How You Can Avoid Them
top

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, but
this doesn't mean that any off-the-shelf SNMP manager can provide adequate visibility
and control of your network.

The typical off-the-shelf SNMP manager is not designed for displaying and processing
telemetry data for effective network monitoring, especially 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. 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 the detailed alarm data you expect. Before you commit to an SNMP monitoring
solution, you need to make sure it supports essential 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 representing all
the monitored points in your network — and then also create and maintain a
database associating 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 corresponds to
an alarm condition or a clear condition. Creating this addition to the trap
association database often requires analyzing multiple 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 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, and then, for whatever reason, 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 or to assign
responsibility for the resulting problems.

5. Trusting a system that’s insecure for multiple 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
category, posting the same alarm to multiple logical categories, or sorting which
alarms the user wants to see. If Jones is in charge of all equipment for the
Western region, and Smith is in charge of power plants, both need to know
about a generator failure in Tucson, but 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 necessary for best quality
telemetry monitoring, such as notifications escalation, legacy protocol
mediation, nuisance alarm silencing, automatic control relay operation, and
automatic notifications 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, but implementing network alarm monitoring in a basic SNMP manager
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, and 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 that 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 take into
account the tons of legacy and non-SNMP equipment that is functioning perfectly fine
out in networks all over the world. The role of an SNMP manager is best used for
inventorying network devices and drilling down into equipment details after your
network monitoring system notifies you of a problem.

SNMP can be an effective tool, but it's only one item in your network alarm monitoring
toolkit, and 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. Network managers who rely
on T/Mon for their network alarm monitoring, notification, and control comment,
“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."