1

Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
Overview and History of the TCP/IP Internet Standard Management Framework and
Simple Network Management Protocol (SNMP)

An adage from the world of professional sports says that a baseball umpire is doing a good
job when you forget that he is there. In many ways, the same could be said of a network
administrator. The administrator is doing a good job when the network is running so
smoothly and efficiently that users forget that the administrator exists. Because as the
administrator knows all too well, the second there is a problem, the users will all remember
that he or she is there very quickly.

This means that a primary job of a network administrator is to keep tabs on the network and
ensure that it is operating normally. Information about the hardware and software on the
network is a key to performing this task properly. When networks were small, an
administrator could stay informed about the status of hardware and software using simple
means, such as physically walking over to a computer and using it, or using a low-level link
layer management protocol.

This is simply not possible with modern internetworks, which are large, geographically
diverse, and often consist of many different lower-layer technologies. Usually, the only thing
all the devices on the network have in common is an implementation of a particular
internetworking protocol suite, such as TCP/IP. This makes the internetwork itself a logical
way to facilitate the communication of network management information between devices
and a network administrator.

Early Development of SNMP

Many people recognized during the early days of the Internet that some sort of network
management technology would be needed for TCP/IP. Unfortunately, at first there was no
single standard—in the 1980s, several different technologies were developed by different
working groups. There were three main contestants: the High-level Entity Management
System (HEMS) / High-level Entity Management Protocol (HEMP) as defined by RFCs
1021 through 1024; the Simple Gateway Monitoring Protocol (SGMP), defined by RFC
1028; and the Common Management Information Protocol (CMIP), which is actually part of
the OSI protocol suite.

The Internet Engineering Task Force (IETF) recognized the importance of having a unifying
management standard for TCP/IP, and in 1988 published RFC 1052, IAB
Recommendations for the Development of Internet Network Management Standards. This
memo is not a standard, but more of a statement of intention and documentation of a
meeting held on this subject. The conclusion of RFC 1052 was that SGMP be used as the
basis of a new Internet standard to be called the Simple Network Management Protocol
(SNMP). This development was to be carried out by the SNMP Working Group.

The Two Meanings of "SNMP"

 2
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
The rationale of the middle two words in the name “Simple Network Management Protocol”
is obvious, but the other two words are slightly more problematic. The word “Protocol”
implies that SNMP is just a TCP/IP communication protocol, like other protocols such as
DHCP or FTP. Unfortunately, this is both true and untrue: the term “SNMP” is ambiguous.

At a lower level, SNMP does indeed refer specifically to the actual protocol that carries
network management information between devices. This is in fact what most people think
of when they talk about “SNMP”. However, as defined by the SNMP working group, the
TCP/IP network management solution as a whole consists of a number of different
elements arranged in an architecture.

This architecture originally had no specific name, but is now called the Internet Standard
Management Framework. Oddly, this higher-level framework is not abbreviated “ISMF” or
anything like that; it is also called “SNMP”, which means that context is important in
understanding that term.

Note: To avoid confusion, I will often use the phrases “SNMP Framework” and “SNMP
Protocol” to differentiate these two uses of the term “SNMP”.

Design Goals of SNMP

The word “Simple” in “Simple Network Management Protocol” is another sore spot for me;
having researched and written about this technology, I now consider the presence of this
term in the name “SNMP” to be almost a taunt. Let's put it this way: if a brain surgeon tells
you that something is a “simple procedure”, you probably know to take that with a grain of
salt—well, the same applies here. Even in its first iteration it was only somewhat simple; the
most current version of SNMP is fairly complicated indeed, with many different standards
defining the SNMP Framework, the SNMP Protocol itself, and a number of supporting
elements.

So why is it called “simple”? Well, as they say, everything's relative; SNMP is “simple” when
compared to other protocols that are even more complex. Some of this can be seen by
looking at the basic goals of the Internet Standard Management Framework and the SNMP
protocol as a whole:

o SNMP defines a universal way that management information can be easily defined
for any object and then exchanged between that object and a device designed to
facilitate network management;

o SNMP separates the functions of defining and communicating management

information from the applications that are used for network management;

o The actual SNMP protocol is fairly simple, consisting of only a few easy-to-
understand protocol operations;

o The implementation of SNMP is relatively simple for the designers and

manufacturers of products.
 3
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
Since SNMP is a TCP/IP application layer protocol, it can theoretically run over a variety of
transport mechanisms. It is most commonly implemented over IP, of course, but the most
recent versions also define transport mappings that can allow SNMP information to be
carried over other internetworking technologies. Again, my focus will continue to be almost
exclusively on TCP/IP.

Key Concept: The Simple Network Management Protocol (SNMP) defines a set of
technologies that allows network administrators to remotely monitor and manage
TCP/IP network devices. The term “SNMP” refers both to a specific communication
protocol (sometimes called the SNMP Protocol) and an overall framework for Internet
management (the SNMP Framework).

Further Development of SNMP and the Problem of SNMP Variations

The description above provides the history of how the first version of SNMP was
developed, leading to the publishing of the first Internet Standard Management Framework
in 1988; this is now called SNMP version 1 (SNMPv1). This initial version of SNMP
achieved widespread acceptance, and it is still probably the most common version of
SNMP.

Much of the history of SNMP since that time has been a rather confusing “standards
nightmare”. SNMPv1 had a number of weaknesses, particularly in the area of security. For
this reason, shortly after SNMPv1 was done, work began on a new version of SNMP.
Unfortunately, this effort became a quagmire, with many competing variations of SNMPv2
being created. After many years of confusion, none of the SNMPv2 variants achieved
significant success.

Recently, a third version of the SNMP Framework and Protocol has been published, which
adds new features and “reunites” SNMP back under a single universal protocol again. The
topics on SNMP versions and SNMP standards later in this section further explore the
history of SNMP since 1988; they can be considered a continuation of this topic, as they
help clarify the very confusing story behind SNMP versions over the last decade and a half.

This overview may have put more questions in your mind about the Internet Standard
Management Framework and SNMP than it answered. This is part of why I said this stuff
isn't really that simple. The next two topics in this section provide more information
about the Framework and its components, and what those components do, so you can
understand better what the Framework is all about.
 4
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

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 MIB is
organized in a tree structure with individual variables, SNMP is based on the
such as point status or description, being manager/agent model of a network
represented as leaves on the branches. A long management architecture.
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
 5
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
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 name, or the
element uptime, it will assemble a GET
packet that includes the OID for each
object / characteristic of interest. The The branch of the MIB object identifier tree.
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.
 6
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
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 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). Understanding this layered
model makes it easier to
SNMP resides in what is called the Application layer, troubleshoot communication
UDP resides in the Transport layer and IP resides in problems. When there is a
the Internet layer (somewhat obvious). The fourth problem, you can simply trace it
down...
 7
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
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 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

 8
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
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.
 9
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
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.
 10
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
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."

SNMP - Simple Network Managment Protocol

Introduction

Since it was developed in 1988, the Simple Network Managment Protocol has become the de facto
standard for internetwork managment. Because it is a simple solution, requiring little code to
implement, vendors can easily build SNMP agents to their products. SNMP is extensible, allowing
vendors to easily add network managment functions to their existing products. SNMP also separates
the managment architecture from the architecture of the hardware devices, which broadens the base
of multivendor support. Perhaps most important, unlike other so-called standards,SNMP is not a
mere paper specification, but an implementation that is widely available today.

This article will discuss the following issues:

Network Managment Architectures

 11
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
Structure of Managment Information
Managment Information Base
SNMP Protocol
Underlying communications protocols
Click here for list of WWW pages related to SNMP

Network Managment Architectures

Network managment system contains two primary elements: a manager and agents. The Manager is
the console through which the network administrator performs network managment functions.
Agents are the entities that interface to the actual device being managed. Bridges, Hubs, Routers or
network servers are examples of managed devices that contain managed objects. These managed
objects might be hardware, configuration parameters, performance statistics, and so on, that directly
relate to the current operation of the device in question. These objects are arranged in what is known
as a virtual information database ,called a managment information base, also called MIB. SNMP
allows managers and agents to communicate for the purpose of accessing these objects.

The model of network managment architecture looks like this:

A typical agent usually:

 12
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
• Implements full SNMP protocol.
• Stores and retrieves managment data as defined by the Managment Information Base
• Can asynchronously signal an event to the manager
• Can be a proxy for some non-SNMP manageable network node. Click here to see a typical
proxy architecture.

A typical manager usually:

• Implemented as a Network Managment Station (the NMS)

• Implements full SNMP Protocol
• Able to
o Query agents
o Get responses from agents
o Set variables in agents
o Acknowledge asynchronous events from agents

Some prominent vendors offer network managment platforms which implement the role of the
manager (listed in alphabetic order) :

• Dec PolyCenter Network Manager

• Hewlett-Packard OpenView
• IBM AIX NetView/6000
• SunConnect SunNet Manager

Structure of Managment Information

In the Manager/Agent paradigm for network managment, managed network objects must be
logically accessible. Logical accessibility means that managment information must be stored
somewhere, and therefore, that the information must be retrievable and modifiable. SNMP actually
performs the retrieval and modification. The Structure of Managment Information (SMI) which is
given in RFC 1155, is based on the OSI SMI given in Draft proposal 2684.

The SMI organizes, names, and describes information so that logical access can occur. The SMI
states that each managed object must have a name, a syntax and an encoding. The name, an object
identifier(OID), uniquely identifies the object. The syntax defines the data type,such as an integer or
a string of octets. The encoding describes how the information associated with the managed objects
is serialized for transmission between machines.

The syntax used for SNMP is the Abstract Syntax Notation One, ASN.1. The encoding used for
SNMP is the Basic Encoding Rules, BER. The names used are object identifiers. later we will see
how the MIB uses these names.

ASN.1 is used to specify many RFCs (and not just the SMI), for example the Internet standard MIB
and SNMP. ASN.1 is used widely in OSI for specification purposes. ASN.1 used for defining SMI
and MIBs is a subset of the ASN language given by OSI. ASN.1 does specify in itself

Object instances (protocol specific)

message transmission format (BER)
 13
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
Click here to see more information on ASN.1 . Each object whether it's a device or a characteristics
of a device, must have a name by which it can be uniquely identified. That name is the object
identifier. It is written as a sequence of integers, separated by periods. For example, the sequence
1.3.6.1.2.1.1.1.0 specifies the system description within the system group, of the mgmt subtree.

Managment Information Base

Managment information bases (MIBs) are a collection of definitions, which define the properties of
the managed object within the device to be managed. Every managed device keeps a database of
values for each of the definitions written in the MIB. It is not the actual database itself - it is
implementation dependant. Definition of the MIB conforms to the SMI given in RFC 1155. Latest
Internet MIB is given in RFC 1213 sometimes called the MIB-II. Click here to see MIB architecture.
You can think of a MIB as an information warehouse

Criteria and Philosophy for standardized MIB

• Objects have to be uniquely named

• Objects have to be essential
• Abstract structure of the MIB needed to be universal
• For the standard MIB maintain only a small number of objects
• Allow for private extensions
• Object must be general and not too device dependant
• Objects can not be easily derivable from their objects
• If agent is to be SNMP manageable then it is mandatory to implement the Internet MIB
(currently given as MIB-II in RFC 1157)

Naming an Object

• Universal unambiguous identification of arbitrary objects

• Can be achieved by using an hierarchical tree
• Based on the Object Identification Scheme defined by OSI
 14
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

Object identifiers

• Object name is given by its name in the tree

• All child nodes are given unique integer values within that new sub-tree
• Children can be parents of further child sub-tree(i.e they have subordinates) where the
numbering scheme is recursively applied
• The Object Identifier (or name) of an object is the sequence of non-negative Integer values
traversing the tree to the node required.
• Allocation of an integer value for a node in the tree is an act of registration by whoever has
delegated authority for that sub tree
• This process can go to an arbitrary depth
• If a node has children then it is an aggregate node
• Children of the same parent cannot have the same integer value

Object and Object identifiers

 15
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
• Object is named or identified by the sequence of integers in traversing the tree to the object
type required
• This does notidentify an instance of the object
• The Object Identifier (OID) is shown in a few ways with a.b.c.d.e being the preferred
• OIDs can name many types of objects:

Standard documents (e.g.: FTAM)

people (e.g.: Tax file numbers in Sweden are OIDs)
Organizations (e.g.: RAD or LANNET)
Computing network nodes (e.g.: workstations)
Dumb devices (e.g.: toasters)
... in fact anything at all ...

• For SNMP it is the Internet sub-tree for constructing OIDs for SNMP manageable agents

The Internet Sub-tree

• Directory sub-tree if for future directory services

• Experimental sub-tree is for experimental MIB work - still has to be registered with the
authority (IESG)
• Mib sub-tree is the actual mandatory Internet MIB for all agents to implement (currently
MIB-II RFC 1156 - this is the only sub tree of mgmt)
• Enterprise sub-tree (of private) are MIBs of proprietary objects and are of course not
mandatory (sub-tree registered with Internet Assigned Numbers Authority) for example:
Cisco router OID: 1.3.6.1.4.1.9.1.1
• SNMP managment nearly always interest in MIB and specific enterprises MIBs

MIB-II Standard Internet MIB

• Definition follows structure given in SMI

• MIB-II (RFC 1213) is current standard definition of the virtual file store for SNMP
manageable objects
• Has 10 basic groups
o system
o interfaces
o at
o ip
o icmp
o tcp
o udp
o egp
o transmission
o snmp
• If agent implements any group then is has to implement all of the managed objects within
that group
• An agent does not have to implement all groups
• Note: MIB-i and MIB-II have same OID (position in the internet sub-tree)
 16
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

SNMP Protocol

SNMP is based on the manager/agent model.SNMP is referred to as "simple" because the agent
requires minimal software.Most of the processing power and the data storage resides on the
managment system, while a complementary subset of those functions resides in the managed system.

To achieve its goal of being simple,SNMP includes a limited set of managment commands and
responses. The managment system issues Get, GetNext and Set messages to retrieve single or
multiple object variables or to establish the value of a single variable. The managed agent sends a
Response message to complete the Get, GetNext or Set. The managed agent sends an event
notification, called a trap to the managment system to identify the occurrence of conditions such as
threshold that exceeds a predetermined value. In short there are only five primitive operations:

get (retrieve operation)

get next (traversal operation)
get response (indicative operation)
set (alter operation)
trap (asynchronous trap operation)

SNMP Message Construct

Each SNMP message has the format:

• Version Number
• Community Name - kind of a password
• One or more SNMP PDUs - assuming trivial authentication
 17
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
Each SNMP PDU except trap has the following format:

• request id - request sequence number

• error status - zero if no error otherwise one of a small set
• error index - if non zero indicates which of the OIDs in the PDU caused the error2
• list of OIDs and values - values are null for get and get next

Trap PDUs have the following format:

• enterprise - identifies the type of object causing the trap

• agent address - IP address of agent which sent the trap
• generic trap id - the common standard traps
• specific trap id - proprietary or enterprise trap
• time stamp - when trap occurred in time ticks
• list of OIDs and values - OIDs that may be relevant to send to the NMS

Outline of the SNMP protocol

• Each SNMP managed object belongs to a community

• NMS station may belong to multiple communities
• A community is defined by a community name which is an OctetString with 0 to 255 octets
in length.
• Each SNMP message consists of three components
o version number
o community name
o data - a sequence of PDUs associated with the request

Security levels with basic SNMP

Authentication

o trivial authentication based on plain text community name exchanged in SNMP

messages
o authentication is based on the assumption that the message is not tampered with or
interrogated

Authorisation

o Once community name is validated then agent or manager checks to see if sending
address is permitted or has the rights for the requested operation
o "View" or "Cut" of the objects together with permitted access rights is then derived
for that pair (community name, sending address)

Summary

o Not very secure

o SNMP version 2 is addressing this
o Extended security is possible with current protocol (example: DES and MD5)
 18
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
o Does not reduce its power for monitoring

What does SNMP access

• SNMP access particular instances of an object

• All instances of an object in the MIB reside at the leaf nodes of the MIB tree
• SNMP Protocol access objects by forming an Object identifier of form
x.y
where x is the "true" OID for the object in the MIB, and y is a suffix specified by the protocol
that uniquely identifies a particular instance (e.g.. when accessing a table)
• For primitive single instance leaf objects use y=0
for example: sysDescr (OID: 1.3.6.1.2.1.1.1) would be referenced in the SNMP protocol by
1.3.6.1.2.1.1.1.0 (i.e sysDescr.0)
• For single instance of columnar leaf objects (i.e one instance from a table type of object) use
y=I1.I2.I3.... (Ii are table indexes) for example: Click here to see access to the interfaces table

MIB traversal using GetNext operation

Underlying communication protocols

SNMP assumes that the communication path is a connectionless communication subnetwork.In other
words, no prearranged communication path is established prior to the transmission of data.As a
result , SNMP makes no guarantees about the reliable delivery of the data.although in practice most
messages get through , and those that don't can be retransmitted. The primary protocols that SNMP
implements are the User Datagram Protocol (UDP) and the Internet Protocol (IP).SNMP also
requires Data Link Layer protocols such as Ethernet or TokenRing to implement the communication
channel from the managment to the managed agent.

SNMP's simplicity and connectionless communication also produce a degree of robustness. Neither
the manager nor the agent relies on the other for its operation.Thus, a manager may continue to
function even if a remote agent fails. When the agent resumes functioning , it can send a trap to the
manager, notifying it of its change in operational status. The connectionless nature of SNMP leaves
the recovery and error detection up to the NMS(Network Managment Station) and even up to the
agent. However keep in mind that SNMP is actually transport independent (although original design
was connectionless transport function, which corresponds to the UDP protocol) and can be
implemented on other transports as well:

• TCP (Connected approach)

• Direct mapping onto Ethernet MAC level
• Encapsulation onto X25 protocol
• Encapsulation onto ATM Cell
• and so on.....
 19
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
The following figure describes the Transport Mechanism used in SNMP over UDP:

UDP Transport

• Agent listen on UDP port 161

• Responses are sent back to the originating NMS port from a dynamic port , although many
agents use port 161 also for this target.
• Maximum SNMP message size is limited by maximum UDP message size (i.e 65507 octets)
• All SNMP implementations have to> receive packets at least 484 octets in length
• Some SNMP implementation will incorrectly or not handle packets exceeding 484 octets
• Asynchronous Traps are received on port 162 of the NMS
• UDP more suitable than TCP when dynamic route changes occur often (e.g. when there are
problems in the network)
• UDP packets minimize the demands placed on the network(no resource tied up as with
connection mode)
• Agent and NMS are responsible for determining error recovery
 20
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
The following diagrams shows the architecture of UDP transport.
 21
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
 22
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
1. What is SNMP?
2. How is SNMP vulnerable?
3. Is our network or system in danger of attack?
4. What can happen if we are attacked?
5. How can we protect our network or system?
6. Are there any alternatives to using SNMP?
7. Do these vulnerabilities affect home users?
8. What are managers and agents?
9. What is a community string and how is it used?
10. What protocols/ports does SNMP use?
11. Where can I find the specifications for SNMP?
12. Where can I find additional information about SNMP?
13. Has the CERT/CC received any reports of SNMP scanning?
14. I have detected scanning of my network or systems for SNMP. Should I report that to
the CERT/CC?
15. Has the CERT/CC received any reports of exploitation of these vulnerabilities?
16. An intruder has exploited these SNMP vulnerabilities on my system. What should I do?
17. I am not a vendor, but I use or otherwise have first-hand knowledge of an SNMP product
that is vulnerable, but it is not on the CERT/CC's list. Should I report that to the
CERT/CC?
18. Our company manufactures a product that uses SNMP, and we think it might be
vulnerable, but we are not sure. How can we get more information on these
vulnerabilities?
19. Our company manufactures a product that uses SNMP, and we know it to be affected by
these vulnerabilities, but we are not listed in any of your vendor statements. How can
we get added to your list of vendors?
20. Our company manufactures a product that uses SNMP, but we know it is not affected by
these vulnerabilities. Nonetheless, we are being swamped with calls to our help desk
about this issue. We are not currently listed in any of your vendor statements, but we'd
like to be. How can we get added to your list of vendors?
21. Who is OUSPG?

1. What is SNMP?

The Simple Network Management Protocol (SNMP) is the most popular protocol in use to
manage networked devices. SNMP was designed in the late 80's to facilitate the
exchange of management information between networked devices, operating at the
application layer of the ISO/OSI model. The SNMP protocol enables network and system
administrators to remotely monitor and configure devices on the network (devices such
as switches and routers). Software and firmware products designed for networks often
make use of the SNMP protocol. Support for SNMP is available on a multitude of
systems, including, but not limited to,

• Core Network Devices (Routers, Switches, Hubs, Bridges, and Wireless Network
Access Points)
• Operating systems (on nearly all architectures)
• Consumer Broadband Network Devices (Cable Modems and DSL Modems)
• Consumer Electronic Devices (Cameras and Image Scanners)
• Networked Office Equipment (Printers, Copiers, and FAX Machines)
 23
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
• Network and Systems Management/Diagnostic Frameworks (Network Sniffers and
Network Analyzers)
• Uninterruptible Power Supplies (UPS)
• Networked Medical Equipment (Imaging Units and Oscilloscopes)
• Manufacturing and Processing Equipment
2. How is SNMP vulnerable?

The vulnerabilities affect both manager and agent software (see "What are managers
and agents?" for an explanation of these terms). Vulnerabilities in both managers and
agents include denial-of-service conditions, format string vulnerabilities, and buffer
overflows. Some of the vulnerabilities do not require the malicious packet to use the
proper community string (see "What is a community string and how is it used?").
Several of the more serious vulnerabilities allow the execution of arbitrary code by a
remote unauthenticated attacker. Refer to CERT advisory CA-2002-03
(http://www.cert.org/advisories/CA-2002-03.html) for a detailed description of the
vulnerabilities.

3. Is our network or system in danger of attack?

Because of the relatively large number of products that support SNMP, it is unlikely that
our list of affected products is comprehensive. Therefore, if you use products that
support SNMP, we encourage you to first refer to CERT advisory CA-2002-03
(http://www.cert.org/advisories/CA-2002-03.html) for a partial list of affected vendors
and products. If your vendor(s) are not listed you should contact them directly for more
information to ensure your system is protected.

4. What can happen if we are attacked?

Exploitation of these vulnerabilities can cause denial-of-service conditions, service

interruptions, and in some cases will allow an attacker to gain unauthorized, privileged
access to the affected device. Effects for some specific products can be found in CERT
advisory CA-2002-03 (http://www.cert.org/advisories/CA-2002-03.html). Contact your
vendor(s) for additional information on other products.

5. How can we protect our network or system?

A number of steps can be taken to improve the security of systems relying on SNMP:

• Apply a patch from your vendor.

• Disable all nonessential SNMP software.
• Filter SNMP access to managed devices to ensure the traffic originates from
known management systems.
• Filter SNMP services at your network perimeter (ingress/egress filtering).
• Change SNMP community strings from their defaults.
• Segregate network management traffic onto a separate network.

Refer to CERT advisory CA-2002-03 (http://www.cert.org/advisories/CA-2002-03.html)

for more details and the most recent information regarding recommended solutions.

6. Are there any alternatives to using SNMP?

 24
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
Although there aren't many practical alternatives to SNMP, there are steps that
administrators can take to better secure their systems that use SNMP. See the "How can
we protect our network or system?" section above or refer to CERT Advisory CA-2002-03
(http://www.cert.org/advisories/CA-2002-03.html) for more information.

7. Do these vulnerabilities affect home users?

Most home users are not directly affected by these vulnerabilities. However, home users
with more advanced configurations may be at risk. If you use one or more of the
following in your home system or network, additional steps might be necessary to
ensure protection:

• Microsoft Windows operating systems with SNMP services enabled

• advanced operating systems (e.g., Linux or other Unix operating systems)
• network-based router appliances
• network-based firewall appliances
• wireless Ethernet (802.11a/b) access points

Note that in many cases SNMP services are not enabled by default, so merely using one
or more of the products above does not mean that you are definitely vulnerable. Home
users with one or more of the above technologies in use on their home networks are
encouraged to refer to CERT advisory CA-2002-03 (http://www.cert.org/advisories/CA-
2002-03.html) for a partial list of affected vendors and products. If your vendors are not
listed you should contact them directly for more information to ensure your system is
protected.

8. What are managers and agents?

SNMP is built around the concept of "managers" and "agents." Manager software
(commonly installed on a network management system) makes requests to agent
software running on a host or device to gather data on the operational status,
configuration, or performance statistics of that system (polling). Some agents allow
configuration parameters to be changed by managers, while others provide read-only
statistics and configuration information. Additionally, agents can generate ad hoc
messages to manager systems to inform them of unusual events (traps).

9. What is a community string and how is it used?

The community string (a.k.a. community name) provides a weak authentication

mechanism to the SNMP protocol. Agents can be configured to allow read-only, read-
write, or no access to their parameters based on the community string in a request.
Community strings are passed in clear text in SNMP messages, so they can be easily
sniffed and are therefore insufficient for authenticating legitimate manager requests.

Note that many of the vulnerabilities described in CERT advisory CA-2002-03

(http://www.cert.org/advisories/CA-2002-03.html) do not require an attacker to know
the configured community strings in order to exploit the vulnerability.

10. What protocols/ports does SNMP use?

SNMP uses 161/udp for general purpose (request/response) communications, and

162/udp for traps. Additionally, the SNMP multiplexing protocol (smux, defined in
 25
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
RFC1227 http://www.ietf.org/rfc/rfc1227.txt) uses 199/tcp. Another SNMP extension,
the AgentX protocol (RFC2741, http://www.ietf.org/rfc/rfc2741.txt) uses 705/tcp.

11. Where can I find the specifications for SNMP?

The current SNMPv1 standard is defined in the Internet Engineering Task Force (IETF)
STD0015 / RFC1157 (http://www.ietf.org/rfc/rfc1157.txt). There are also a number of
draft and proposed standards for SNMPv2 and SNMPv3. Refer to IETF STD0001 /
RFC3000 (http://www.ietf.org/rfc/rfc3000.txt) for the current status of the various
SNMP-related RFCs.

12. Where can I find additional information about SNMP?

The comp.protocols.snmp FAQ may be found at

http://www.faqs.org/faqs/snmp-faq/part1/ and
http://www.faqs.org/faqs/snmp-faq/part2/

There are a number of SNMP-related Working Groups in the "Operations and

Management" area of the IETF (http://www.ietf.org/).

13. Has the CERT/CC received any reports of SNMP scanning?

As of 9:25 EST (UTC-0500) February 12, 2002, we have received reports of scanning for
SNMP services related to these vulnerabilities and are working to verify. New incident
reports are being sent to the CERT/CC all the time, though, so you are encouraged to
refer to our Current Activity page (http://www.cert.org/current/current_activity.html) for
the latest information on incident trends.

14. I have detected scanning of my network or systems for SNMP. Should I report
that to the CERT/CC?

If you have detected scanning for SNMP services on your network, you should first
determine whether this scanning has led to a compromise or not. You may wish to refer
to our Intruder Detection Checklist
(http://www.cert.org/tech_tips/intruder_detection_checklist.html) for additional tips on
determining whether a compromise has occurred.

Once you are certain that no compromise has occurred and the impact was limited to
scanning only, you are encouraged to report this activity to the CERT/CC using our
Incident Reporting Form, available at http://www.cert.org/reporting/incident_form.txt.

Reporting scanning activity to the CERT/CC will help us better assist you, and allow us to
relate ongoing intruder activities. This also provides us a better overview of trends in
attack profiles and provides input for other CERT documents such as advisories and
summaries. We prefer that Incident Reporting Forms be sent to us via email to
[email protected].

15.Has the CERT/CC received any reports of exploitation of these vulnerabilities?

As of 9:25 EST (UTC-0500) February 12, 2002, we have received reports of exploitation
of SNMP services related to these vulnerabilities and are working to verify them. New
incident reports are being sent to the CERT/CC all the time, though, so you are
 26
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
encouraged to refer to our Current Activity page
(http://www.cert.org/current/current_activity.html) for the latest information on incident
trends.

16. An intruder has exploited these SNMP vulnerabilities on my system. What

should I do?

As described in CERT advisory CA-2002-03 (http://www.cert.org/advisories/CA-2002-

03.html), exploitation of these SNMP vulnerabilities can cause denial-of-service
conditions, service interruptions, and in some cases will allow an attacker to gain
unauthorized, privileged access to the affected device(s).

If you suspect that your system may have been compromised, you may wish to refer to
our Intruder Detection Checklist
(http://www.cert.org/tech_tips/intruder_detection_checklist.html). Once you have
confirmed that a compromise has occurred, please refer to our Steps for Recovering
from a UNIX or NT System Compromise
(http://www.cert.org/tech_tips/root_compromise.html)

Regardless of whether the exploitation resulted in system compromise or denial-of-

service, we would appreciate it if you would complete and return an Incident Reporting
Form as this will help us better assist you, and allow us to relate ongoing intruder
activities. This also provides us a better overview of trends in attack profiles and
provides input for other CERT documents such as advisories and summaries. We prefer
that Incident Reporting Forms be sent to us via email to [email protected]. The Incident
Reporting Form is available from http://www.cert.org/reporting/incident_form.txt.

17. I am not a vendor, but I use or otherwise have first-hand knowledge of an

SNMP product that is vulnerable, but it is not on the CERT/CC's list. Should I
report that to the CERT/CC?

If you have first-hand knowledge of an SNMP product that is vulnerable to either of

these vulnerabilities, and that product or vendor is not listed in CERT advisory CA-2002-
03 (http://www.cert.org/advisories/CA-2002-03.html), you are encouraged to contact us
using our Product Vulnerability Reporting Form. This form can be found at
http://www.cert.org/reporting/vulnerability_form.txt.

Please send the completed form to [email protected] with VU#617947 in the subject line.

18. Our company manufactures a product that uses SNMP, and we think it might be
vulnerable, but we are not sure. How can we get more information on these
vulnerabilities?

The CERT/CC encourages any vendors whose products are affected (whether vulnerable
or not) by these or any other security vulnerabilities to contact us so that we can
establish a working relationship on this and any future issues that may arise. If you are
authorized to represent your organization on this issue, please contact the CERT/CC via
our hotline at +1 412-268-7090. CERT/CC personnel answer 8:00 a.m.- 5:00 p.m.
EST(GMT-5) / EDT(GMT-4) on working days; they are on call for emergencies during
other hours and on weekends and holidays.

19. Our company manufactures a product that uses SNMP, and we know it to be
affected by these vulnerabilities, but we are not listed in any of your vendor
statements. How can we get added to your list of vendors?
 27
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
The CERT/CC encourages any vendors whose products are affected (whether vulnerable
or not) by these or any other security vulnerabilities to contact us so that we can
establish a working relationship on this and any future issues that may arise. If you are
authorized to represent your organization on this issue, please contact the CERT/CC via
our hotline at +1 412-268-7090. CERT/CC personnel answer 8:00 a.m.- 5:00 p.m.
EST(GMT-5) / EDT(GMT-4) on working days; they are on call for emergencies during
other hours and on weekends and holidays.

20. Our company manufactures a product that uses SNMP, but we know it is not
affected by these vulnerabilities. Nonetheless, we are being swamped with
calls to our help desk about this issue. We are not currently listed in any of
your vendor statements, but we'd like to be. How can we get added to your list
of vendors?

The CERT/CC encourages any vendors whose products are affected (whether vulnerable
or not) by these or any other security vulnerabilities to contact us so that we can
establish a working relationship on this and any future issues that may arise. If you are
authorized to represent your organization on this issue, please contact the CERT/CC via
our hotline at +1 412-268-7090. CERT/CC personnel answer 8:00 a.m.- 5:00 p.m.
EST(GMT-5) / EDT(GMT-4) on working days; they are on call for emergencies during
other hours and on weekends and holidays.

21. Who is OUSPG?

The Oulu University Secure Programming Group (OUSPG) is an academic research group
located at Oulu University in Finland. The purpose of this research group is to test
software for vulnerabilities.

History has shown that the techniques used by the OUSPG have discovered a large
number of previously undetected problems in the products and protocols they have
tested. Earlier this year, the OUSPG produced a comprehensive test suite for evaluating
implementations of the Lightweight Directory Access Protocol (LDAP). This test suite was
developed with the strategy of abusing the protocol in unsupported and unexpected
ways, and it was very effective in uncovering a wide variety of vulnerabilities across
several products. This approach can reveal vulnerabilities that would not manifest
themselves under normal conditions.

What's the difference between SNMPv1, SNMPv2 and SNMPv3?

-------------------------------------------------------

What's the difference between SNMPv2 and SNMPv2c?

------------------------------------------------

A full description is probably beyond the scope of this FAQ.

Very briefly, the original protocol and admin framework was
described in RFCs 1155-1157, and is now known as SNMPv1.

Practical experience showed up various problems and deficiencies

with this, and a number of revised frameworks were developed to try
and address these problems. Unfortunately, it proved difficult to
achieve any sort of agreement - particularly over the details of
 28
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
the administrative framework to use.

There was less disagreement over the proposed changes to the

protocol operations. These included:
* increasing the range of errors that could be reported
* introducing "exception values"
(so a single missing value didn't affect
the other varbinds in the same request)
* a new GETBULK operation
(a supercharged GETNEXT)
* new notification PDUs
(closer in structure to the other request PDUs)

Strictly speaking, it's this revised protocol (originally defined

in RFC 1905, and most recently in RFC 3416) that is "SNMPv2".

The only framework based on this protocol that saw a significant

level of use was "Community-based SNMPv2" or "SNMPv2c" (defined in
RFCs 1901-1908). This retained the same administrative framework
as SNMPv1 (with all of the accompanying limitations), but using
the new protocol operations.

More recently, a new administrative framework has been developed,

building on the various competing SNMPv2 proposals, and using the
same SNMPv2 protocol operations. This is SNMPv3, which is defined
in RFCs 3411-3418. It addresses some of the deficiencies of the
community-based versions, including significant improvements to
the security of SNMP requests (like it finally has some!).
SNMPv3 is now a full IETF standard protocol.

Strictly speaking, SNMPv3 just defines a fairly abstract framework,

based around the idea of "Security Models" and "Access Control Models".
It's this combination of SNMPv3 plus accompanying models that actually
provides a working SNMP system.
However, the only models in common use are the "User-based Security
Model" (RFC 3414) and the "View-based Access Control Model" (RFC 3415).
So "SNMPv3" is frequently used to mean the combination of the basic
SNMPv3 framework with these two particular models.
This is also sometimes described as "SNMPv3/USM".

So in brief:
- SNMPv2c updated the protocol operations
but left the administrative framework unchanged.
- SNMPv3 updated the administrative framework
but left the protocol operations unchanged.

Can I use SNMPv1 requests with an SNMPv2 MIB (or vice versa)?
 29
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
------------------------------------------------------------

Yes.

The syntax used to specify a MIB file (better referred

to as SMIv1 or SMIv2) is purely concerned with how to define
the characteristics of various management objects. This is
(almost) completely unrelated to the versions of the protocol
used to operate on these values. So it is quite reasonable to
use SNMPv1 requests on objects defined using SMIv2, or SNMPv2
(or SNMPv3) requests on objects defined using SMIv1.

The one exception is objects of syntax Counter64, which are

only accessible using SNMPv2 or higher. SNMPv1 requests will
either treat such objects as an error, or skip them completely.

Where can I find more information about network management?

----------------------------------------------------------

There are a number of sites with network management information on

the World Wide Web. A couple of the most useful are

http://www.simpleweb.org/
http://www.snmplink.org/
http://www.mibdepot.com/

There are two Usenet newsgroups which are relevant.

'comp.dcom.net-management'
which discusses general issues relating to network management
'comp.protocols.snmp'
which is specifically concerned with use of SNMP in particular

(though there is a large overlap between these two groups).

The SNMP group also has an FAQ (split into two parts) which discusses more
general issues related to SNMP, including books, software, other sites,
how to get an enterprise number, etc, etc.
This is available from

ftp://rtfm.mit.edu/pub/usenet/comp.protocols.snmp/

or via any of the Web sites above.

 30
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

How do I add a MIB?

------------------

This is actually two separate questions, depending on whether you

are referring to the tools, or the agent (or both).
See the next question or the next section respectively.

How do I add a MIB to the tools?

-------------------------------

Adding a MIB to the client-side tools has two main effects:

- it allows you to refer to MIB objects by name

(rather than having to use the numeric OIDs)
- it allows the results to be displayed in a more immediately
meaningful fashion. Not just giving the object names, but
also showing named enumeration values, and interpreting table
indexes properly (particularly for string and OID index values).

Most of the tools (apart from 'snmptable') will work quite happily
without any MIB files at all - although the results won't be displayed
in quite the same way.
The same holds true for the agent - see the AGENT section for details.

There are two steps required to add a new MIB file to the tools.
Firstly, copy the MIB file into the appropiate location:

cp MY-MIB.txt /usr/local/share/snmp/mibs
(which makes it available to everyone on the system)

or

mkdir $HOME/.snmp
mkdir $HOME/.snmp/mibs
cp MY-MIB.txt $HOME/.snmp/mibs
(which makes it available to you only)

Note that the location of the shared MIB directory may be different
from that given here - particularly if you're working with a vendor
supplied distribution. See where the MIBs are currently installed,
and copy the new MIB to the same place.

Secondly, tell the tools to load this MIB:

 31
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

export MIBS=+MY-MIB
(load it for this session only)

or

echo "mibs +MY-MIB" >> $HOME/.snmp/snmp.conf

(load it every time)

This will add the new MIB to the list of MIBs loaded by default.
Omitting the '+' will *replace* the list of MIBs to be loaded by
the specified (colon-separated) list - together with any MIBs that
they explicitly rely on.
Note that the value for this variable is the name of the MIB
module, *not* the name of the MIB file. These are typically the
same (apart from the .txt suffix), but if in doubt, check the contents
of the file. The value to use is the token immediately before the
word DEFINITIONS at the start of the file.

If you prefer to have the tools load all available MIBs (which
may slow them down), then set the MIBS environmental variable
(or the snmp.conf token "mibs") to the special value "ALL".

Note that you need *both* steps.

Why can't I see anything from the agent?

---------------------------------------

There are two main general causes of problems retrieving information

from the agent. Either the client tool may not like the request (and
refuse to send it at all), or the agent may not respond with anything
useful. The simplest way to distinguish between the two is to run the
command with the command-line option '-d'.

If this doesn't display a hex dump of the raw outgoing packet, then
it's the client side which is dropping the request. Hopefully you
should see some form of error message, to help identify what's wrong.

If this displays one or more outgoing dumps (but nothing coming back),
then the request is failing at the agent end. See the next entry for
more details.

If you see dumps of both the outgoing request, and a response, but
no results are displayed, then either there may be a problem with
decoding the response (in which case you should see an error message),
or the agent may simply not support the requested information (and the
 32
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
response is being discarded as irrelevant).

Why doesn't the agent respond?

-----------------------------

Assuming that the agent is actually sending the request (see the
previous entry), there are two main likely causes for the agent not
to respond. Either it doesn't receive the request (e.g. it's being
blocked by a firewall or packet filtering), or it receives it, but
is unwilling (or unable) to process it.

If the remote system is running the Net-SNMP agent, then the easiest
way to check what's going wrong is to shut down the agent, and re-start
it using the options:
-f -Le -d
This will display raw dumps of packets seen (or sent) by the agent,
just as the '-d' flag did for the client side in the previous entry.

Restart the agent with these flags, and send the same query as before.
If the agent doesn't display anything in response to this request, then
it's probably some form of firewall settings, which are preventing the
agent from ever seeing the request.

If the agent displays a dump of the incoming request, but nothing going
out, then the most likely cause is access control settings. See the
relevant entries in the AGENT section for details.

A third possibility is that the agent *is* responding to the request,

but only after a long delay. This would be indicated by a series of
incoming packet dumps (showing various retries from the client side),
followed by several outgoing dumps - possibly long after the client
tool has given up in disgust.
See the entry
The agent worked for a while, then stopped responding. Why?
later in this section.

The same basic causes could also affect other vendors' SNMP agents.
Please consult the relevant documentation for how to investigate and
address such problems.

I can see the system group, but nothing else. Why?

--------------------------------------------------
 33
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
This is almost definitely due to the access configuration of the agent.
Many pre-configured systems (such as most Linux distributions) will only
allow access to the system group by default, and need to be configured
to enable more general access.

The easiest way to test this is to try a GETNEXT request that ought
to return the entry of interest.
e.g.
snmpgetnext -v1 -c public localhost UCD-SNMP-MIB::versionTag
instead of
snmpget -v1 -c public localhost UCD-SNMP-MIB::versionTag.0

If the agent responds with "end of MIB" or a different object, then

either the agent doesn't implement that particular object at all, or
the access control won't allow you access to it.

See the entries on access control in the AGENT section for how to
configure the Net-SNMP agent, or consult the agent's own documentation.

Why can't I see values in the <INSERT ENTERPRISE HERE> tree?

-----------------------------------------------------------

If you're walking a specific tree, but failing to see anything in

it, then the most likely cause is that the agent simply does not
implement those particular MIB objects. Or if it does, that the
access control or other configuration settings mean that there's
nothing for you to see there.

However, if you're trying a basic "snmpwalk" with no explicit OID

specified, then this would also explain why you're not seeing any
enterprise-specific results.

By default, unless given an explicit starting OID, then the 'snmpwalk'

command will display the contents of the 'mib-2' tree, containing most
of the IETF-standard management information supported by the agent.
When the agent reaches the end of this tree, it will return the first
enterprise-specific value, and 'snmpwalk' will recognise that this
marks the end of the (implicitly) request tree, and stop. No
enterprise-specific information will be displayed.

To walk the whole tree, and see *all* the information that the
agent supports, specify a starting point of '.iso' or '.1'.
To walk a specific enterprise subtree, specify the root of this tree
as the starting point - e.g:

snmpwalk -v1 -c public localhost UCD-SNMP-MIB::ucdavis

 34
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

There is more information about particular UCD-specific subtrees in

the AGENT section.

The agent worked for a while, then stopped responding. Why?

-----------------------------------------------------------

There are three basic possibilities:

- the agent has crashed
- it is hanging
- it is temporarily overloaded

Detecting whether the agent has crashed should be fairly straighforward.

If you can reliably reproduce this crash (e.g. by sending a particular
SNMP request), then contact the coders list for advice.
It's the other two cases that are probably more significant.

To tell the difference between these two, try leaving the agent
undisturbed for a while, and then probe it using a single 'snmpget'
request, specifying a longer timeout (e.g. '-t 120'). If it now
responds, then something was probably sending requests (including
duplicate retries) faster than the agent could process them, and it
was building up a backlog. Try adjusting the timeout period and retry
frequency of these client requests, or look at improving the efficiency
of the implementation of the relevant MIB objects.

If the agent remains unresponsive (particularly if the load on the

system is steadily climbing), then it's probably hanging, and all
you can really do is restart the agent. If you can identify what
causes this to happen, then contact the coders list for advice.

Requesting an object fails with "Unknown Object Identifier" Why?

----------------------------------------------------------------

If a general snmpwalk shows a particular entry, but asking for it more

specifically gives a "sub-identifier not found:" or "Unknown Object
Identifier" error, then that's a problem with the tool, rather than
the agent.

Firstly, make sure that you're asking for the object by the right name.
Object descriptors are case-sensitive, so asking for 'sysuptime' will
not be recognised, but 'sysUpTime' will.
 35
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
Alternatively, the object may be defined in a MIB that hasn't been
loaded. Try loading in all the MIB files:

snmpget -m ALL -v1 -c public localhost sysUpTime.0

or specify the name of the appropriate MIB explicitly:

snmpget -v1 -c public myhost SNMPv2-MIB::sysUpTime.0

Note that this uses the name of the *module*, not the name of the file.
See the second entry in this section for the distinction. However,
if 'snmpwalk' displays the object by name, this is unlikely to be the
cause, and you should look closely at the exact object name you are using.

Why do I get "noSuchName" when asking for "sysUpTime" (or similar)?

------------------------------------------------------------------

Assuming that you do have access to this object, the most likely
cause is forgetting the "instance subidentifier".

If you try walking the 'system' group, you should notice that all
of the results have a number after the MIB object name. This is
the "instance subidentifier" of that particular MIB instance.

For values from the sysORTable, this basically provides an index into
the table, and should be very familiar. But the other values in the
system group also have an instance number displayed. For non-table
objects ("scalars"), this instance subidentifier will always be '0',
and it *must* be included when making a GET request.

Compare the following:

$ snmpget -v1 -c public localhost sysUpTime

Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
This name doesn't exist: system.sysUpTime
$ snmpget -v1 -c public localhost sysUpTime.0
system.sysUpTime.0 = Timeticks: (69189271) 8 days, 0:11:32.71

This is a little less obscure when using SNMPv2c or v3 requests:

$ snmpget -v 2c -c public localhost sysUpTime

system.sysUpTime = No Such Instance currently exists
 36
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

Why do I sometimes get "End of MIB" when walking a tree, and sometimes not?
--------------------------------------------------------------------------

This depends on which MIB modules are supported by the agent you are
querying and exactly what you're asking for.

Note that a tree is walked by repeatedly asking for "the next entry" until
all the values under that tree have been retrieved. However, the agent has
no idea that this is what's happening - all it sees is a request for "the
next entry after X".

If the object X happens to be the last entry in a sub-tree, the agent will
provide the next object supported (as requested) even though this will be
in a different subtree. It's up to the querying tool to recognise that
this last result lies outside the area of interest, and simply discard it.

If the object X happens to be the last entry supported by the agent, it

doesn't have another object to provide, so returns an "end of MIB"
indication. The Net-SNMP tools report this with the message above.

But in either case, the actual information provided will be the same.

How do I use SNMPv3?

-------------------

The simplest form of SNMPv3 request (unauthenticated, unencrypted)

would be something like:

snmpget -v 3 -l noAuthNoPriv localhost sysUpTime.0

An authenticated request would specify a username and pass phrase:

snmpget -v 3 -l authNoPriv -u dave -A "Open the Door"

localhost sysUpTime.0

A fully secure request would also specify the privacy pass phrase:

snmpget -v 3 -l authPriv -u dave -A "Open the Door"

-X "Bet you can't see me" localhost sysUpTime.0

In practise, most of these would probably be set via configuration

directives in a personal $HOME/.snmp/snmp.conf file (note, *not* the
agent's snmpd.conf file). The equivalent settings for the third
example would be:
 37
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
defSecurityName dave
defSecurityLevel authPriv
defAuthPassphrase "Open the Door"
defPrivPassphrase "Bet you can't see me"

If the AuthPassphrase and the PrivPassphrase are the same, then you
can use the single setting
defPassphrase "Open the Door and see me"
instead.

See the AGENT section for how to configure the agent for SNMPv3 access.

I cannot set any variables in the MIB.

-------------------------------------

There are three possible reasons for this:

Many MIB objects are defined as "read-only" and inherently cannot be

changed via SET requests. Attempts to do so will typically be dropped
by the 'snmpset' command without ever being sent to the agent.

Of those objects that can in principle be changed, the agent may not
include the code necessary to support SET requests. (GET and GETNEXT
are much easier to handle - particularly for objects relating to the
internals of the underlying operating system).

Even if SET support has been implemented, the agent may not be configured
to allow write access to this object.

Ready-installed distributions (such as those shipped with Linux) tend

to be configured with read-only access to part of the mib tree (typically
just the system group) and no write access at all.

To change this, you will need to set up the agent's access control
configuration. See the AGENT section for more details.

Note that neither the community string "public" nor "private" can be
used to set variables in a typical default configuration.

Variables seem to disappear when I try to set them. Why?

--------------------------------------------------------

This is actually the same as the previous question - it just isn't

 38
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
particularly obvious, particularly when using SNMPv1. A typical
example of this effect would be

$ snmpget -v1 -c public localhost system.sysLocation.0

system.sysLocation.0 = somewhere nearby

$ snmpset -v1 -c public localhost system.sysLocation.0 s "right here"

Error in packet.
Reason: (noSuchName) There is no such variable name in this MIB.
This name doesn't exist: system.sysLocation.0

Trying the same request using SNMPv2 or above is somewhat more informative:

$ snmpset -v 2c -c public localhost system.sysLocation.0 s "right here"

Error in packet.
Reason: notWritable

The SNMPv1 error 'noSuchName' actually means:

"You can't do that to this variable"

rather than "this variable doesn't exist". It may be the case that it
doesn't exist at all. It may exist but you don't have access to it
(although someone else with different administrative credentials might do).
Or it may exist, but you simply can't perform that particular operation
(e.g. changing it).
Similarly, the SNMPv2 error 'notWritable' means "not writable in
this particular case" rather than "not writable under any circumstances".

If you are sure that the object is writable (and has been implemented
as such), then you probably need to look at the agent access control.
See the AGENT section for more details.

Why can't I change sysLocation (or sysContact)?

----------------------------------------------

Assuming that the access control settings should allow this, another
possibility for the 'sysLocation' and 'sysContact' objects is that
you've got a configuration option in the 'snmpd.conf' file which
already sets the corresponding value there.

Earlier versions of the Net-SNMP agent would allow you to write to

these objects, but the new value would be forgotten the next time the
agent was re-started. More recent versions of the agent reject such
write requests if there's a value configured via the 'snmpd.conf' file.
If there isn't such a config setting, then the write request will succeed
 39
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
(assuming suitable access control settings), and the new value will be
retained the next time the agent restarts.

I get an error when trying to set a negative value - why?

--------------------------------------------------------

This is a different problem. What's happening here is that the

routine that parses the arguments to the 'snmpset' command is seeing
the '-' of the new value, and treating it as a command-line option.
This normally generates an error (since digits typically aren't valid
command line options).

The easiest way to solve this is include the "end-of-option"

indicator '--' in the command line, somewhere before the new value
(but after all of the options, obviously). For example:

snmpset -v 2c -c public localhost -- versionRestartAgent.0 i -1

(This will also fail, since -1 isn't an acceptable value for this
particular object, but that's not the point here!)

I get an error when trying to get a string-indexed table value - why?

--------------------------------------------------------------------

This is probably due to the shell swallowing the quotes, before

they ever get to the SNMP command's OID parser. Try escaping them:

snmpget ..... vacmGroupName.3.\"wes\"

or snmpget ..... 'vacmGroupName.3."wes"'

How do I send traps and notifications?

---------------------------------------

Traps and notifications can be sent using the command 'snmptrap'.

The following examples generate the generic trap 'coldStart' and a
(dummy) enterprise specific trap '99' respectively:

snmptrap -v 1 -c public localhost "" "" 0 0 ""

snmptrap -v 1 -c public localhost "" "" 6 99 ""
 40
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
The empty parameters "" will use suitable defaults for the relevant
values (enterprise OID, address of sender and current sysUptime).

An SNMPv2 or SNMPv3 notification (either trap or inform) takes

the OID of the trap to send:

snmptrap -v 2c -c public localhost "" UCD-SNMP-MIB::ucdStart

snmptrap -v 2c -c public localhost "" .1.3.6.1.4.1.2021.251.1

(These two are equivalent ways of specifying the same trap).

Any of these commands can be followed by one or more varbinds,

using the same (OID/type/value) syntax as for 'snmpset':

snmptrap -v 2c -c public localhost "" ucdStart sysContact.0 s "Dave"

Generating traps from within the agent is covered in the AGENT and
CODING sections.

You should also read the snmptrap tutorial at

http://www.net-snmp.org/tutorial-5/commands/snmptrap.html
which will help you understand everything you need to know about traps.

How do I handle traps and notifications?

---------------------------------------

Handling received traps is done using the tool 'snmptrapd'.

This can log these traps via the syslog mechanism:

snmptrapd -Ls 7 (log to 'LOCAL7')

printed to standard output

snmptrapd -f -Lo

or pass them to an external command. This last approach uses

a 'traphandle' directive in the configuration file 'snmptrapd.conf'.
A typical file might look something like:

traphandle .1.3.6.1.6.3.1.5.1 page_me up

traphandle .1.3.6.1.4.1.2021.251.1 page_me up
traphandle .1.3.6.1.4.1.2021.251.2 page_me down
traphandle default log_it

where 'page_me' and 'log_it' are the command to be run. (You probably
need to specify full pathnames, to ensure that the commands will be
 41
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
found. They're just short here for readability).

Note that the first entry uses the OID corresponding to the SNMPv1
'coldStart' trap. See the co-existence RFC (RFC 2576) for details
of mapping SNMPv1 traps to SNMPv2 OIDs.

Starting with net-snmp 5.3, snmptrapd will no longer automatically

accept all incoming traps. It must be configured with authorized
SNMPv1/v2c community strings and/or SNMPv3 users. Non-authorized
traps/informs will be dropped.
Please refer to the snmptrapd.conf(5) manual page for details.

There's a tutorial with more details on the web site at

http://www.net-snmp.org/tutorial-5/commands/snmptrap.html

My traphandler script doesn't work when run like this - why not?
---------------------------------------------------------------

If a traphandler script works fine when run manually from the

command line, but fails or generates an error when triggered by
an incoming notification, then there are two likely causes.

Firstly, the interactive shell environment may not be precisely

the same as that for programs executed by the snmptrapd daemon.
In particular, it's quite possible that the PATH environmental
variable may not include all the additional directories that are
commonly set up for a personal login configuration. To avoid this
problem (particularly for traphandler shell scripts), it's worth
giving the full path to all programs used within the script.

Secondly, the snmptrapd daemon may not always recognise the

appropriate interpreter to use for a particular trap handler.
If this is the case, then you can specify this interpreter
explicitly as part of the trap handle directive:

traphandle default /usr/bin/perl /usr/local/bin/log_it

In this case, it's almost certain that you'll also

need to give the full path to the traphandle script (as shown)

How big can an SNMP request (or reply) be?

-----------------------------------------
 42
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
The protocol definition specifies a "minimum maximum" packet size
(484 bytes for UDP), which all systems must support, but does not
attempt to define an upper bound for this maximum size. This is left
to each individual implementation.

The UCD software used a fixed size buffer of 1472 bytes to hold the
encoded packet, so all requests and responses had to fit within this.
The Net-SNMP releases handle packet buffers rather differently, and
are not subject to the same fixed restrictions.

How can I monitor my systems (disk, memory, etc)?

------------------------------------------------

In general, the Net-SNMP suite consists of relatively low-level

tools, and there is nothing included that is designed for high-level,
long-term monitoring of trends in network traffic, disk or memory
usage, etc.

There are a number of packages available that are designed for this
purpose. Two of the most widely used are MRTG (http://www.mrtg.org/)
and RRDtool (http://oss.oetiker.ch/rrdtool/). There are also several
frontends built on top of RRDtool, including Cacti (http://www.cacti.net/)
and Cricket (http://cricket.sourceforge.net/). There are details of
how to set up Cricket to monitor some of the UCD extensions at
http://www.afn.org/~jam/software/cricket/

We have also set up a page that describes in detail how MRTG

can be set up to monitor disk, memory and cpu activity at
http://www.net-snmp.org/tutorial-5/mrtg/index.html

There is also a web-based network configuration system "Net-Policy",

based upon SNMP. This is not strictly connected to the Net-SNMP project,
but a number of the core developers are also involved with that system.
See http://net-policy.sourceforge.net for more details.

Applications complain about entries in your example 'snmp.conf' file. Why?

--------------------------------------------------------------------------

There *is* no example 'snmp.conf' shipped with the standard distribution.

The configuration file 'EXAMPLE.conf' is designed as a config for

the agent, and should be installed as 'snmpd.conf' (note the 'd').
The file 'snmp.conf' is intended for general configuration options,
 43
Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)
applicable to all applications (via the SNMP library).
Rename (or merge) the 'snmp.conf' file to 'snmpd.conf', and this
should fix the problem.

OK, what should I put in snmp.conf?

----------------------------------

This is used to set common configuration values for most of the

applications, to avoid having to specify them every time. Examples
are the SNMPv3 settings mentioned above, defaults for which MIBs to
load and where from (see the second entry in the APPLICATIONS section),
and the default SNMP version, port and (if appropriate) community
string to use.

Some of these (such as the MIB file location), might be best put in
a shared snmp.conf file (typically /usr/local/share/snmp/snmp.conf or
/etc/snmp/snmp.conf) to apply to all users of the system. Others
(particularly the SNMPv3 security settings), are more likely to refer
to a particular user, and should go in a personal snmp.conf file
(typically $HOME/.snmp/snmp.conf).

See 'snmpget -H' and/or the snmp.conf(5) man page for more details.

You can also use the "snmpconf" command to help you generate your
snmp.conf configuration file (just run it and answer its questions).