l

l
l
l
l
l
l

lOverview of
lNetwork Management
l& the role of SNMP
l
l
l
l

-1-

l
l
l
l
l
l
l

lPurpose and Origin

In the early 1980s computer networks began to grow and be
interconnected. As the size of these networks grew, they became
harder to manage and maintain, thus the need for network
management was realized. One of the oldest forms of network
management is the use of the remote login to monitor or configure a
network device; however, today more sophisticated network
management tools are available. Network management is a
requirement for anyone who wants to control and monitor their
networks & its devices.

lFunctional Areas of Network Management

Network management is the ability to control and monitor a computer
network from a central location. The International Organization for
Standardization (ISO) defined a conceptual model for describing the
key functional areas of network management which are described
below.
Note: In general, network management systems available from
vendors today do not support all the key functional areas, and in a

-2-

supported functional area, the coverage may be incomplete even

though support is claimed.
Fault Management: Provides facilities that allow network managers to
discover faults in managed devices, the network, and network
operation, to determine their cause and to take remedial action. To
enable this, fault management provides mechanisms to:
Report the occurrence of faults
Log reports
Perform diagnostic tests
Correct faults (possibly automatically)
Configuration
Management:
Monitors
network
configuration
information so that the effects of specific hardware and software can
be managed and tracked. It may provide the ability to initialize,
reconfigure, operate and shut down managed devices.
Accounting: Measures network utilization of individual users or groups
to:
Provide billing information
Regulate users or groups
Help keep network performance at an acceptable level

Performance Management: Measures various aspects of network

performance including the gathering and analysis of statistical data
about the system so that it may be maintained at an acceptable level.
Performance management provides the ability to:
Obtain the utilization and error rates of network devices
Provide a consistent level of performance by ensuring that devices
have a sufficient capacity.
Security Management: Controls access to network resources so that
information can not be obtained without authorization by:
Limiting access to network resources
Providing notification of security breaches and attempts

-3-

Network Management Architecture : In general, network

management systems have the same basic architecture, as shown in
the figure below.

Figure 1.1: Typical Network Management Architecture

The architecture consists of the following elements:

-4-

Network Management Station(s): The network management

station runs the network management application that gathers
information about managed devices from the management agent
which resides within a managed device. The network management
application typically must process large amounts of data, react to
events, and prepare relevant information for display. It usually has a
control console with a GUI interface which allows the operator to view
a graphical representation of the network, control managed devices on
the network and program the network management application. Some
network management applications can be programmed to react to
information collected from management agents and/or set thresholds
with the following actions:
Perform tests and automatic corrective actions (reconfiguration,
shutdown of a managed device)
Logging network events
Present status information and alerts to operator
Managed Devices: A managed device can be any type of node
residing on a network, such as a computer, printer or router. Managed
devices contain a management agent.
Management agents: Provides information about the managed
device to the network management application(s) and may also
accept control information.
Network management protocol: Protocol used by the network
management application(s) and the management agent to exchange
management information.
Management Information: The information that is exchanged
between the network management application(s) and the
management agents that allows the monitoring and control of a
managed device.
Network management software (network management applications
and agents) is usually based upon a particular network management
protocol and the network management capabilities provided with the
software are usually based upon the functionality supported by the
network management protocol. Most systems use open protocols;
however, some network management software is based upon vendor
specific proprietary protocols. The selection of network management
software is driven by the following factors:
Network environment (scope and nature of the network)
Network management requirements
Cost
Operating systems involved

-5-

The two most common network management protocols are the

Simple Network Management Protocol
Common Management Information Protocol
SNMP is by far the most widely used network management protocol
and use is widespread in LAN environments. CMIP is used extensively
in telecommunication environments, where networks tend to be large
and complex. MACAX 1628 uses Simple Network Management
Protocol for the management of network devices such as
Uninterrupted Power Supplies. Following is a detailed description of
SNMP.

SNMP : Introduction
-6-

Since it was developed in 1988, the Simple

Network Management Protocol has become the de facto standard
for internetwork management. A key reason for its widespread
acceptance, besides being the chief Internet standard for network
management, is its relative simplicity. Implementing SNMP
management in a networked device is far more straightforward and
better than most other standard or non-standard approaches to
network management. Furthermore, SNMP is extensible, allowing
vendors to easily add network management functions to their existing
products. SNMP also separates the management 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.
Despite that, SNMP application development has not been as simple
as one would like it to be. It has required significant effort to develop
management applications to manage the variety of networked devices
to be managed. This situation is now changing for the better, as more
SNMP tools become available. With improved tools, SNMP is poised to
deliver end-to-end management for all areas of the growing
internetworking industry.

What is SNMP?
SNMP is a protocol used to communicate between the Manager and
the Agent. Just think of it like a language which we speak. If two
people are talking, they should have a common language, so that they
understand each other. Similarly, SNMP serves as a common language
for the Manager and the Agent to communicate. It is named Simple
Network Management Protocol as it is really easy to understand (One
-7-

of the primary reasons for SNMP becoming popular). There are

different versions of SNMP like SNMP V1, SNMP V2 and most recently,
SNMP V3.
SNMP facilitates communication between a managed device (a device
with an SNMP agent, e.g. a router), and an SNMP manager or
management application (represents a user of network management).
The SNMP agent on the managed device serves to provide access to
data (managed objects) stored on the managed device. The SNMP
manager or management application uses this access to monitor and
control the managed device.

Figure 1.2: An SNMP-Managed Network Consists of Managed Devices, Agents, and

NMSs

Communication takes place via SNMP protocol data units (PDUs) that
are typically encapsulated in UDP packets, and essentially four kinds
of operations are permitted between managers and agents (managed
device).

-8-

The manager can perform a get (or read) to obtain information from
the agent about an attribute of a managed object.
The manager can perform a get-next to do the same for the next
object in the tree of objects on the managed device.
The manager can perform a set (or write) to set the value of an
attribute of a managed object.
The agent can send a trap, or asynchronous notification, to the
manager telling it about some event on the managed device.

In order to specify to the SNMP agent which managed objects are of

interest, the SNMP manager or management application, uses a welldefined naming syntax to specify the variables it is interested in.
Object names in this syntax are called object identifiers (object IDs, or
OIDs), and are a series of numbers that uniquely identifies an object to
an SNMP agent.

Overview of SNMP
The Simple Network Management Protocol (SNMP) was designed to be
an easily implemented, basic network management tool that could be
used to meet network management needs. SNMP has become the
dominant standardized network management scheme in use today.
The SNMP set of standards provide a framework for the definition of
management information along with a protocol for the exchange of
that information. The SNMP model assumes the existence of managers
and agents. A manager is a software module responsible for managing
part or the entire configuration on behalf of network management
applications and users. An agent is a software module in a managed
device responsible for maintaining local management information and
delivering that information to a manager via SNMP. A management
information exchange can be initiated by the manager (via polling) or
by the agent (via a trap).

-9-

Figure 1.2: SNMP V2 Architecture

Agents function as collection devices that gather and send data about
the managed resource in response to a request from a manager. UDP
ports 161 and 162 are the default ports reserved for SNMP. The agent
listens for requests and replies to them over port 161 and reports
asynchronous traps on port 162, unless it is instructed to use different
ports.
SNMP accommodates resources that do not implement the SNMP
software by means of proxies. A proxy is an SNMP agent that
maintains information on behalf of one or more non-SNMP devices.
SNMP defines a client-server relationship. The network manager
makes virtual connections to the SNMP agent which executes on a
remote network device, and sends information to the manager
regarding the device's status. In order for a manager to make requests
of an agent and to interpret the responses and unsolicited traps that it
receives, it uses a database which describes the information available
from the agent. The database is referred to as the SNMP Management

- 10 -

Information Base (MIB). There is a standard set of statistical and

control values defined for hardware nodes on a network. These are
described in a MIB which is part of the SNMP. SNMP also allows the
extension of these standard values with values specific to a particular
agent using private MIBs.
Directives issued to an SNMP agent consist of the identifiers of SNMP
variables (referred to as MIB object identifiers or MIB variables) along
with instructions either to get the value corresponding to the
identifier, or set the identifier to a new value.
Through the use of private MIB variables, SNMP agents can be tailored
for use in many devices. The definitions of MIB variables supported by
a particular agent are incorporated in descriptor files, and made
available to network management client programs so that they can
become aware of MIB variables and their usage. These descriptor files
are written using a subset of Abstract Syntax Notation (ASN.1) format
as adopted by SNMP. When a new agent is added to extend the
domain of a manager, the manager must be provided with a new MIB
(ASN.1 file) that describes the features of the resources managed
through that agent.

- 11 -

What is Agent?
Just think of insurance agents. They are the ones who help both the
insurance companies and customers to get smooth access. Suppose I
want to take an insurance policy, I do not need to spend anytime
taking that policy. The agent will take care of it and just inform me the
status. The same way Agent is a program which will communicate with
the Manager on one side and with Device or Application on the other
side. Agents will be part of the Device or Application so that it knows
everything about the Device or Application.
A typical agent usually:
Implements full SNMP protocol.
Stores and retrieves management data as defined by the MIB.
Can asynchronously signal an event to the manager.
Can be a proxy for some non-SNMP manageable network node.

What is Manager?
Just think of it as an entity which will manage one or many agents
from a remote place. For example take an office. We have offices in 4
places, 3 in one building and 1 in the other building. We have more
than 20 UPS's for each building & just 3 System Administrators. To
manage all the UPSs manually, the System Administrators have to
roam around the office. But just imagine a situation where the System
Administrators will sit before their machines with Managers installed in
their machine and agents installed in all the machines in the office.
They will just do queries from the Manager to Agent to know the
status. Just think that the Agent will automatically inform the Manager
if some problem is going to occur, then the System Administrator will
do the to prevent the problem from occurring.
A typical manager usually:
- 12 -

Is implemented as a Network Management Station (the NMS).

Implements full SNMP Protocol.
Is able to
Query agents,
Get responses from agents,
Set variables in agents,
Acknowledge asynchronous events from agents.

The following diagram provides an overview of the Manager - Agent

relationship.

How the Agent Works

An agent communicates with an SNMP manager, on the one hand, and
the device or application ( so called Managed resource ), on the other
hand, in the following way:
1. The SNMP manager sends an SNMP PDU ( Protocol Data Unit ) to the
agent. This PDU contains an encoded request (such as a request to
GET the value, or SET the value, of a specific managed object).

- 13 -

2. When the agent receives the request, it parses the SNMP PDU
(ASN.1 decoding) to determine the type of request (i.e., GET or SET)
and the MIB group, and invokes the appropriate access function
corresponding to the object within the MIB group.
3. The access function does the actual work of retrieving the object's
current value (for a GET request) or modifying the object's value (for a
SET request). The method used to perform the GET or SET depends on
where the managed object resides (i.e., UNIX kernel, shared memory,
file, or in another process) and does not involve SNMP. If the object
resides in another process, you can use shared memory or a
proprietary protocol, such as Sun RPC/XDR or DCE RPC.

Depending on the value received from the access function, the agent
hook layer returns one of the following responses to the agent core:
A value from a GET function
An OK from a SET function
An ERROR, if an error occurred
4. The agent core receives the response from the agent hook and
builds the SNMP PDU (ASN.1 encoding). It then sends the response
PDU to the SNMP manager.
SNMP Primitive Operations
The basic operations in SNMP are :
GET (retrieve operation)
SET (alter operation)
- 14 -

GETNEXT (traversal operation)

TRAP (asynchronous trap operation)
In the following pages, we will discuss the above operations in detail.

GET
GET is an operation where the manager will request the agent for the
value of a particular OID. In our case if the System Administrator likes
to know the variable inputVoltage of the UPS, he will do a get with the

- 15 -

OID of the variable inputVoltage. The agent will send a response with
the value.

- 16 -

SET
If you specify an OID and request the agent to set the value, the agent
will process and set the value, otherwise throw an error. In our case we
should not allow the batteryCharge variable to be SET from the
manager, since it is a variable maintained by the UPS itself. So when a
SET request is made for this OID, the agent will throw an
"noAccessError". We will also define this variable as a read-only
variable in the MIB.

- 17 -

GETNEXT
Suppose we are not aware of an OID of a variable, then we will
traverse the agent by giving GETNEXT till we get the value of the
variable we are interested in. Suppose if we give a GETNEXT with .
1.3.6, then the agent will respond with the next immediate OID it
implements.
- 18 -

TRAP

- 19 -

In addition to retrieving data from the managed resource in response

to requests from a management station, agents typically also have the
ability to send unsolicited messages to managers when they detect
some significant event. An unsolicited message of this sort is called a
trap notification.

- 20 -

All the above are requests sent from a manager to the agent. There is
TRAP which the agent will send to the manager if it detects some
errors. In our example whenever the charge of battery i.e. the
batteryCharge variable is less than 100, we will send a trap, so that
the manager ( System Administrator ) will know it.
The fields that comprise the SNMP trap PDU occur in the order
are shown below.
PDU typeenterpriseagent addressgeneric trap typespecific trap
typetime stampvariable bindingsThe fields have the following
meaning:
PDU type identifies the packet as a trap notification.
enterprise is the vendor identification (OID) for the network
management subsystem that generated the trap ( .1.3.6.1.4.1.2162 )
agent address is the IP address of the node where the trap was
generated.
generic trap type is an integer in the range of 0 to 6. These values
have the meanings indicated in Table 2-1.
specific trap type is a number that further specifies the nature of the
event that generated the trap in the case of traps of generic type 6
(enterpriseSpecific). The interpretation of this code is vendor-specific.
timestamp is the length of time between the last re-initialization of
the agent that issued the trap and the time at which the trap was
issued.
variable bindings provide additional information pertaining to the
trap. This field consists of name/value pairs. The significance of this
field is vendor-specific

SNMPv2 also defines two new protocol operations: GetBulk and Inform.
The GetBulk operation is used by the NMS to efficiently retrieve large
blocks of data, such as multiple rows in a table. GetBulk fills a
response message with as much of the requested data as will fit. The
Inform operation allows one NMS to send trap information to another
NMS and to then receive a response. In SNMPv2, if the agent
responding to GetBulk operations cannot provide values for all the
variables in a list, it provides partial results.

- 21 -

What is MIB ?
MIB stands for "Management Information Base". It is nothing but a
document about the device or the application. There are a lot of
syntaxes defined for defining the MIB, but the purpose of the MIB is
simple. For example, if a company wants to build an application and it
wants the application to be remotely managed. Then while building
the application itself the architects of the application or the device will
write a MIB which will have information like what are all the variables
that should be published outside ( to the Manager ) and what is the
use of each variable and what each value in the variable represents
and other information.
Each variable is assigned a unique identifier in SNMP that is called an
object identifier (OID). Object identifier is nothing but a unique id ( like
registration numbers ), but the uniqueness is maintained all over the
world. Let us see how this uniqueness is maintained. The format of
OID is a sequence of numbers with dots in between. There are two
roots for object identifiers, they are ( iso - which is .1 ) and ccit
( which starts with .0) Most object identifier starts with .1.3.6.1
( where 1 = iso, 3 = org, 6 = dod, 1 = internet ). From internet there
are two branches, mgmt and private.

- 22 -

All standard MIBs reside under mgmt (.1.3.6.1.2) in this diagram - for
example, MIB II (.1.3.6.1.2.1). The distinction between the standard
and private MIBs is that of control over the object definitions ( i.e
defining the variables ). Standard MIBs are those that have been
approved by the Internet Activities Board (IAB). MIBs defined
unilaterally by equipment and software vendors are initially defined as
private MIBs under private.enterprises. A branch within the
private.enterprises subtree is allocated to each vendor that registers
for an enterprises object identifier. AdventNet has got the enterprise
OID as 2162. So all the variables we define for our device or
application
should
fall
under
.1.3.6.1.4.1.2162
(
.iso.org.dod.internet.private.enterprise.adventnet ). Till the
enterprise number ( like 2162 ) the uniqueness is maintained by the
committee, after this the uniqueness should be maintained by each
enterprise.
For e.g. if we are going to manufacture a UPS, then we can think of
variables like batteryCharge, inputFrequency etc. should be published,
so that at anytime the system administrators will know how many
papers are there in the printer without going to the printer. They will
just install the Manager in these machines and will query the printer
agent and get this information.
There are standard MIBs available. For example RFC1628-MIB is a
standard MIB for UPSs which each operating system will implement.
This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it defines objects for managing
uninterruptible power supply (UPS) systems.
SNMP agents for different types of devices provide access to objects
that are specific to the type of device. In order to enable the SNMP
manager or management application to operate intelligently on the
data available on the device, the manager needs to know the names
and types of objects on the managed device. This is made possible by
Management Information Base (MIB) modules, which are specified in
MIB files usually provided with managed devices. For example,
rfc1213-MIB(also known as MIB-II) is a MIB module which is typically
supported by all SNMP agents on TCP/IP enabled devices or systems.

- 23 -

This MIB file contains a description of the object hierarchy on the

managed device, as well as the name (Object ID), syntax and access
privileges for each variable in the MIB. For example, when the MIB
module is loaded in a MIB Browser, the label of the variable, e.g.
sysDescr, can be used to identify it, since the MIB Browser can use the
MIB module to translate this label to an Object ID.
One key aspect of MIB's is that only the types of objects on the
managed device are specified by the MIB, and not the specific objects
(or instances). For example, ifInOctets in rfc1213-MIB specifies a type
of object for number of input octets on an interface, but the specific
objects or instances of that type are specified as ifInOctets.1,
ifInOctets.2, etc., depending on the number of interfaces.
When specifying an object to the SNMP agent, a proper Object ID
which includes the instance needs to be used by the manager. When
not properly specified the agent responds with a "No such variable"
error.

MIB Groups
A MIB group is a collection of managed objects, and is itself
represented by the name or OID of a node in the OID tree. Groups may
contain other groups. For example, bea is a MIB group that is a
member of the private.enterprises MIB group.
The nodes in the OID tree that are not groups - the base level of the
OID tree - are the "leaves" of the OID tree. For example, in the
following diagram:

- 24 -

MIB group x contains a group of objects, a, b, and c .

MIB group y contains a group of objects, d, e, and f .

SNMPV1 Data Types

Data Type NameDescriptionINTEGERUsed to specify a value whose
range may include both positive and negative numbers.
Range = -2e31 to 2e31 - 1 (SMIv1 doesn't specify minimum or
maximum values for the range).
Examples:
INTEGER(0..127) -- corresponds to an unsigned 8-bit int
INTEGER(0..40 | 50 | 65 | 90..100)
INTEGER(-2147483648..2147483647) -- corresponds to a signed 32bit intINTEGER
(enumerated integer) Used to specify a list of labeled integer values.
In SMIv1 the values should be greater than 0, whereas SMIv2 allows
any values in the range ( -2e31 to 2e31- 1)

Examples:
INTEGER { true(1), false(2) } GaugeIt represents a non-negative
integer which may increase or decrease, but which holds at the
maximum or minimum value specified in the range when the actual
value goes over or below the range, respectively. CounterUsed to
specify a value which represents a count. The range is 0 to
4294967295. TimeTicksused to specify the elapsed time between two
events, in units of hundredth of a second. Range is 0 to 2e32 - 1.
OCTET STRINGUsed to specify octets of binary or textual information.
While SMIv1 doesn't limit the number of octets, SMIv2 specifies a limit
of 65535 octets. A size may be specified which can be fixed, varying,
or multiple ranges.

Examples:
- 25 -

OCTET STRING -- length can vary from 0 to 65535 bytes.

OCTET STRING (SIZE(0..255))
OCTET STRING (SIZE(4)) -- fixed length of 4 bytes.
OCTET STRING (SIZE(0 | 4 | 6)) -- varying with 0, 4, or 6 bytes OBJECT
IDENTIFIERUsed to identify a type that has an assigned object
identifier value IpAddressThis type is used to specify an IPv4 address
as a string of 4 octets. NetworkAddressThis type was designed to allow
a network address of any type to be specified. However, it is now
obsolete. A value of this type is an IPv4 address. SMIv2 supports this
type via the IpAddress type. OpaqueUsed to specify octets of binary
information. SMIv2 specifies a limit of 65535 octets while there is no
limit in SMIv1. A size may be specified which can be fixed, varying, or
multiple ranges. A value of this type must be an encapsulation of
ASN.1 BER encoded value.
Examples:
Opaque -- length can vary from 0 to 65535 bytes.
Opaque (SIZE(0..255))
Opaque (SIZE(4)) -- fixed length of 4 bytes.
Opaque (SIZE(0 | 4 | 6)) -- varying with 0, 4, or 6 bytes

- 26 -

SNMPV2 Data Types

Data Type NameDescriptionInteger32Used to specify a value whose
range may include both positive and negative numbers. Range =
-2e31 to 2e31 - 1 (SMIv1 doesn't specify minimum or maximum values
for the range).
Examples:
Integer32(0..127) -- corresponds to an unsigned 8-bit int
Integer32 -- same as -- Integer32(-2147483648..2147483647)
Integer32(0..40 | 50 | 65 | 90..100) INTEGER (enumerated
integer)Used to specify a list of labeled integer values. In SMIv1 the
values should be greater than 0, whereas SMIv2 allows any values in
the range ( -2e31 to 2e31- 1)
Examples:
INTEGER { true(1), false(2) }
INTEGER { lessThan(-1), equal(0), greaterThan(1) } Unsigned 32Used
to specify a value whose range includes only non-negative integers (0
to 2e31 - 1).

- 27 -

Examples:
Unsigned32 -- same as Unsigned32(0..4294967295)
Unsigned32(0..65535) -- corresponds to an unsigned 16 bit int
Unsigned32(0..10 | 50 | 65 | 90..100) Gauge32It represents a nonnegative integer which may increase or decrease, but which holds at
the maximum or minimum value specified in the range when the
actual
value
goes
over
or
below
the
range,
respectively.Counter32Used to specify a value which represents a
count. The range is 0 to 4294967295. Counter 64Similar to Counter32,
except the range is now (0 to 2e64 -1). This type may only be used
when a 32-bit counter rollover could occur in less than an hour.
Otherwise, the Counter32 type must be used.
Since this type is not available SNMPv1 it may only be used when
backwards compatibility is not a requirement. TimeTicksused to
specify the elapsed time between two events, in units of hundredth of
a second. Range is 0 to 2e32 - 1. OCTET STRINGUsed to specify octets
of binary or textual information. While SMIv1 doesn't limit the number
of octets, SMIv2 specifies a limit of 65535 octets. A size may be
specified which can be fixed, varying, or multiple ranges.
Examples:
OCTET STRING -- length can vary from 0 to 65535 bytes.
OCTET STRING (SIZE(0..255))
OCTET STRING (SIZE(4)) -- fixed length of 4 bytes.
OCTET STRING (SIZE(0 | 4 | 6)) -- varying with 0, 4, or 6 bytes OBJECT
IDENTIFIERUsed to identify a type that has an assigned object
identifier value IpAddressThis type is used to specify an IPv4 address
as a string of 4 octets. OpaqueUsed to specify octets of binary
information. SMIv2 specifies a limit of 65535 octets while there is no
limit in SMIv1. A size may be specified which can be fixed, varying, or
multiple ranges. A value of this type must be an encapsulation of
ASN.1 BER encoded value.
- 28 -

Examples:
Opaque -- length can vary from 0 to 65535 bytes.
Opaque (SIZE(0..255))
Opaque (SIZE(4)) -- fixed length of 4 bytes.
Opaque (SIZE(0 | 4 | 6)) -- varying with 0, 4, or 6 bytes BITSUsed to
specify a collection of labelled bits. It provides a way to label individual
bits in an octet (an extension of OCTET STRING type).
Examples:
BITS { 1 (TCP), 2(Netware), 3(NetBIOS)
MIB Constructs
The following tables describe the constructs supported by AgentToolkit
and the mandatory elements which must be defined if the construct is
created/edited.
Constructs Supported by AgentToolkit
SNMPv1 ConstructsSNMPv2 ConstructsConstructs used both in SNMPv1
and SNMPv2TRAP-TYPEMODULE-IDENTITY
TEXTUAL CONVENTION
OBJECT-IDENTITY
OBJECT-GROUP
NOTIFICATION-TYPE
NOTIFICATION-GROUPOBJECT-IDENTIFIER
OBJECT-TYPE (SCALAR)
OBJECT-TYPE (TABLE)
Mandatory and the Optional fields for the various constructs
Construct NameMandatory FieldsOptional FieldsOBJECT-IDENTIFIER
(v1 & v2 Construct)---COMMAND-TYPEOBJECT-TYPE (SCALAR)
(v1 & v2 Construct)SYNTAX
- 29 -

MAX-ACCESS
STATUSDESCRIPTION
REFERENCE
DEFVAL
COMMAND TYPEOBJECT-TYPE (TABLE)
(v1 & v2 Construct)SYNTAX SEQUENCE OF
MAX-ACCESS
STATUSDESCRIPTION
REFERENCE
COMMAND TYPEMODULE-IDENTITY
(v2 Construct)LAST-UPDATED
ORGANIZATION
CONTACT-INFO
DESCRIPTIONREVISION
REV-DESCRIPTIONTEXTUAL-CONVENTION
(v2 Construct)STATUS
DESCRIPTION
SYNTAX DISPLAY-HINT
REFERENCE OBJECT-IDENTITY
(v2 Construct)STATUS
DESCRIPTION REFERENCE OBJECT-GROUP
(v2 Construct)OBJECTS
STATUS
DESCRIPTIONREFERENCENOTIFICATION-TYPE
(v2 Construct)STATUS
DESCRIPTIONOBJECTS
REFERENCENOTIFICATION-GROUP
(v2 Construct)NOTIFICATIONS
STATUS
DESCRIPTIONREFERENCETRAP-TYPE
(v1 Construct)ENTERPRISEVARIABLES
DESCRIPTION
REFERENCE
Scalar Objects and Tabular Objects
A managed object has both a type (defined in ASN.1) and a value. For
example, the SNMP system group variable sysLocation ( this variable
is defined in RFC1213-MIB ) has the type, DisplayString and may have
the value, "AdventNet Velechery". So in our case we can define
batteryCharge or inputFrequency of the UPS as a scalar object in
the MIB.

- 30 -

Managed objects, in SNMP, are of two types: scalar objects and tabular
objects. A managed object that always has a single instance is called a
scalar object. Tabular objects, on the other hand, have multiple
instances, such as the rows of a table. For example, the MIB II system
group has seven "leaf" variables under it, as illustrated in Figure below.
Each of these objects is a scalar object. For example, the value of
sysUpTime is the duration of time since re-initialization of a system's
network management software (SNMP agent), measured in hundredths
of a second.

Tables in SNMP are two-dimensional objects defined as an ASN.1 type

called SEQUENCE OF, which allows 0 or more members. Each element
of the sequence is an entry (row) in the table, which is itself a
sequence of scalar-valued objects. SNMP does not allow tables to be
nested within tables.
For example, the MIB II at group contains simply one tabular object,
the atTable, which contains one row for each of a system's physical
interfaces. Each row in the table is an instance of the object atEntry.
Each row contains instances of the scalar-valued leaf objects atIfIndex,
atPhysAddress, and atNetAddress. The leaf objects are called columnar
objects since the instances of each such object constitute one column
in the table. Although these objects have scalar-valued instances, they
are not scalar objects because they can have multiple instances.
Another example for a table is, consider our organization. Each
organization will have Employees. Suppose we want to define it in a
MIB, we cannot go for scalar objects. We can define it in table format
only. The below figure shows the table.

- 31 -

In this empNumber will be defined as the index column, so that it can

identify the employee.
Relative and Absolute Object Identifiers
The examples on object identifiers discussed so far specifies the path
to the variable always from the root of the OID tree. For example, the
AdventNet object identifier .1.3.6.1.4.1.2162 specifies the path from
the root of the tree. (The root does not have a name or a number but
the initial 1 in this OID is directly below root.) These are called
absolute OIDs. However, a path to the variable may be specified
relative to some node in the OID tree. For example, 2.1.1.7 specifies
the sysContact object in the system group, relative to the internet ( .
1.3.6.1 ) node in the OID tree. This is called a relative OID.
Specifying Object Identifiers Symbolically
Until now we have used only a series of integers separated by dots,
called "dot-dot" notation, to describe OIDs. However, an OID can also
be expressed symbolically, or by a combination of both integers and
textual symbols. A symbolic OID uses mnemonic keywords to specify
the managed object; for example:
mgmt.mib-2.system.sysDescr

- 32 -

The following numeric OID uses integers to specify the same managed
object:
2.1.1.1
Note that this example is a relative OID.
An OID may combine both symbolic and numeric representations of
individual nodes of the OID tree; for example:
mgmt.mib-2.1.sysDescr
Absolute OID names always begin with a dot and must specify every
node of the OID tree from the top-most node to the specific managed
object:
.iso.org.dod.internet.mgmt.mib.system.sysDescr
.1.3.6.1.2.1.1.1
.iso.3.dod.1.mgmt.mib-2.1.sysDescr

Object Identifier with Instance Indices

To obtain values of objects from the manager, it is necessary to specify
the instance of the object. The instance of an object is specified by
appending an instance index to the object identifier. For example, the
last 0 in:

- 33 -

.iso.3.dod.1.mgmt.mib.1.sysUpTime.0
is the instance index. An instance index of "0" (zero) specifies the first
instance, "1" specifies the second instance, and so on. Since
sysUpTime is a scalar object, it has only one instance. Therefore, an
instance index of zero is always specified when retrieving the value of
a scalar object. An instance index higher than 0 can only be used in
the case of columnar objects ( in table ), which can have multiple
instances.
Suppose consider the employee table we saw above have the
following data
empNumber
(
index
column
)empNameempAge
1xxx252yyy303zzz28If a manager wants to do a snmpget and get
the name of the 2nd employee then he will send a get request with
the following OID.
.1.3.6.1.4.1.2162.1.1.2.2 ( where 2 is the instance ). So "yyy" will
be returned from the agent as response to the manager.

lUnderlying 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

- 34 -

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.....
The following figure describes the Transport Mechanism used in SNMP over UDP:

lUDP Transport
lAgent listen on UDP port 161
lResponses are sent back to the originating NMS port from a dynamic port , although
many agents use port 161 also for this target.
- 35 -

lMaximum SNMP message size is limited by maximum UDP message size (i.e 65507
octets)
lAll SNMP implementations have to> receive packets at least 484 octets in length
lSome SNMP implementation will incorrectly or not handle packets exceeding 484 octets
lAsynchronous Traps are received on port 162 of the NMS
lUDP more suitable than TCP when dynamic route changes occur often (e.g. when there
are problems in the network)
lUDP packets minimize the demands placed on the network(no resource tied up as with
connection mode)
lAgent and NMS are responsible for determining error recovery

- 36 -

The following diagrams shows the architecture of UDP transport.

- 37 -

lSNMP Management
SNMP is a distributed-management protocol. A system can operate
exclusively as either an NMS or an agent, or it can perform the
functions of both. When a system operates as both an NMS and an
agent, another NMS might require that the system query manage
devices and provide a summary of the information learned, or that it
report locally stored management information.
- 38 -

lSNMP Security
SNMP lacks any authentication capabilities, which results in
vulnerability to a variety of security threats. These include
masquerading occurrences, modification of information, message
sequence and timing modifications, and disclosure. Masquerading
consists of an unauthorized entity attempting to perform management
operations by assuming the identity of an authorized management
entity. Modification of information involves an unauthorized entity
attempting to alter a message generated by an authorized entity so
that the message results in unauthorized accounting management or
configuration management operations. Message sequence and timing
modifications occur when an unauthorized entity reorders, delays, or
copies and later replays a message generated by an authorized entity.
Disclosure results when an unauthorized entity extracts values stored
in managed objects, or learns of notifiable events by monitoring
exchanges between managers and agents. Because SNMP does not
implement authentication, many vendors do not implement Set
operations, thereby reducing SNMP to a monitoring facility.
lSNMP Interoperability
As presently specified, SNMPv2 is incompatible with SNMPv1 in two
key areas: message formats and protocol operations. SNMPv2
messages use different header and protocol data unit (PDU) formats
than SNMPv1 messages. SNMPv2 also uses two protocol operations
that are not specified in SNMPv1. Furthermore, RFC 1908 defines two
possible SNMPv1/v2 coexistence strategies: proxy agents and bilingual
network-management systems.
lProxy Agents
An SNMPv2 agent can act as a proxy agent on behalf of SNMPv1
managed devices, as follows:
An SNMPv2 NMS issues a command intended for an SNMPv1 agent.
The NMS sends the SNMP message to the SNMPv2 proxy agent.
The proxy agent forwards Get, GetNext, and Set messages to the
SNMPv1 agent unchanged.
GetBulk messages are converted by the proxy agent to GetNext
messages and then are forwarded to the SNMPv1 agent.

- 39 -

The proxy agent maps SNMPv1 trap messages to SNMPv2 trap

messages and then forwards them to the NMS.
lBilingual Network-Management System
Bilingual SNMPv2 network-management systems support both SNMPv1
and SNMPv2. To support this dual-management environment, a
management application in the bilingual NMS must contact an agent.
The NMS then examines information stored in a local database to
determine whether the agent supports SNMPv1 or SNMPv2. Based on
the information in the database, the NMS communicates with the
agent using the appropriate version of SNMP.
lSNMP Reference: SNMPv1 Message Formats
SNMPv1 messages contain two parts: a message header and a
protocol data unit (PDU). Figure 56-4 illustrates the basic format of an
SNMPv1 message.
Figure 56-4: An SNVPv1 Message Consists of a Header and a PDU

lSNMPv1 Message Header

SNMPv1 message headers contain two fields: Version Number and
Community Name.
The following descriptions summarize these fields:
Version numberSpecifies the version of SNMP used.
Community nameDefines an access environment for a group of
NMSs. NMSs within the community are said to exist within the same
administrative domain. Community names serve as a weak form of
authentication because devices that do not know the proper
community name are precluded from SNMP operations.
SNMPv1 Protocol Data Unit

- 40 -

SNMPv1 PDUs contain a specific command (Get, Set, and so on) and
operands that indicate the object instances involved in the
transaction. SNMPv1 PDU fields are variable in length, as prescribed by
ASN.1. Figure 56-5 illustrates the fields of the SNMPv1 Get, GetNext,
Response, and Set PDUs transactions.
Figure 56-5: SNMPv1 Get, GetNext, Response, and Set PDUs Contain the Same
Fields

The following descriptions summarize the fields illustrated in Figure

56-5:
PDU typeSpecifies the type of PDU transmitted.
Request IDAssociates SNMP requests with responses.
Error statusIndicates one of a number of errors and error types.
Only the response operation sets this field. Other operations set this
field to zero.
Error indexAssociates an error with a particular object instance.
Only the response operation sets this field. Other operations set this
field to zero.
Variable bindingsServes as the data field of the SNMPv1 PDU.
Each variable binding associates a particular object instance with its
current value (with the exception of Get and GetNext requests, for
which the value is ignored).
Trap PDU Format
Figure 56-6 illustrates the fields of the SNMPv1 Trap PDU.
Figure 56-6: The SNMPv1 Trap PDU Consists of Eight Fields

The following descriptions summarize the fields illustrated in Figure

56-6:

- 41 -

EnterpriseIdentifies the type of managed object generating the

trap.
Agent addressProvides the address of the managed object
generating the trap.
Generic trap typeIndicates one of a number of generic trap types.
Specific trap codeIndicates one of a number of specific trap
codes.
Time stampProvides the amount of time that has elapsed between
the last network reinitialization and generation of the trap.
Variable bindingsThe data field of the SNMPv1 Trap PDU. Each
variable binding associates a particular object instance with its current
value.
SNMP Reference: SNMPv2 Message Format
SNMPv2 messages consist of a header and a PDU. Figure 56-7
illustrates the basic format of an SNMPv2 message.
Figure 56-7: SNMPv2 Messages Also Consist of a Header and a PDU

lSNMPv2 Message Header

SNMPv2 message headers contain two fields: Version Number and
Community Name.
The following descriptions summarize these fields:
Version numberSpecifies the version of SNMP that is being used.
Community nameDefines an access environment for a group of
NMSs. NMSs within the community are said to exist within the same
administrative domain. Community names serve as a weak form of
authentication because devices that do not know the proper
community name are precluded from SNMP operations.
SNMPv2 Protocol Data Unit

- 42 -

SNMPv2 specifies two PDU formats, depending on the SNMP protocol

operation. SNMPv2 PDU fields are variable in length, as prescribed by
Abstract Syntax Notation One (ASN.1).
Figure 56-8 illustrates the fields of the SNMPv2 Get, GetNext, Inform,
Response, Set, and Trap PDUs.
The following descriptions summarize the fields illustrated in Figure
56-8:
PDU typeIdentifies the type of PDU transmitted (Get, GetNext,
Inform, Response, Set, or Trap).
Request IDAssociates SNMP requests with responses.
Error statusIndicates one of a number of errors and error types.
Only the response operation sets this field. Other operations set this
field to zero.
Error indexAssociates an error with a particular object instance.
Only the response operation sets this field. Other operations set this
field to zero.
Variable bindingsServes as the data field of the SNMPv2 PDU.
Each variable binding associates a particular object instance with its
current value (with the exception of Get and GetNext requests, for
which the value is ignored).
Figure 56-8: SNMPv2 Get, GetNext, Inform, Response, Set, and Trap PDUs Contain
the Same Fields

GetBulk PDU Format

Figure 56-9 illustrates the fields of the SNMPv2 GetBulk PDU.
Figure 56-9: The SNMPv2 GetBulk PDU Consists of Seven Fields

The following descriptions summarize the fields illustrated in Figure

56-9:

- 43 -

PDU typeIdentifies the PDU as a GetBulk operation.

Request IDAssociates SNMP requests with responses.
Non repeatersSpecifies the number of object instances in the
variable bindings field that should be retrieved no more than once
from the beginning of the request. This field is used when some of the
instances are scalar objects with only one variable.
Max repetitionsDefines the maximum number of times that other
variables beyond those specified by the Non repeaters field should be
retrieved.
Variable bindingsServes as the data field of the SNMPv2 PDU.
Each variable binding associates a particular object instance with its
current value (with the exception of Get and GetNext requests, for
which the value is ignored).

- 44 -