Introduction      

Feasibility

SNMP

Features

Problems

Future Expansion

Bibliography

Credits

SNMP - Simple Network Management Protocol

 Introduction

     Since it was developed in 1988, the Simple Network Management Protocol has become the de facto standard for internetwork management. 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 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.

Network Management Architectures

Structure of Management Information

Management Information Base

SNMP Protocol

Underlying communications protocols

 Network Management Architectures

Network management system contains two primary elements: a manager and agents. The Manager is the console through which the network administrator performs network management 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 management information base, and also called MIB. SNMP allows managers and agents to communicate for the purpose of accessing these objects.

The model of network management architecture looks like this:

A typical agent usually:

·         Implements full SNMP protocol.

·         Stores and retrieves management data as defined by the Management Information Base

·         Can asynchronously signal an event to the manager

·         Can be a proxy for some non-SNMP manageable network node.

A typical manager usually:

·         Implemented as a Network Management Station (the NMS)

·         Implements full SNMP Protocol

·         Able to

·         Query agents

·         Get responses from agents

·         Set variables in agents

·         Acknowledge asynchronous events from agents

Some prominent vendors offer network management 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 

Back to Top

Structure of Management Information

In the Manager/Agent paradigm for network management, managed network objects must be logically accessible. Logical accessibility means that management 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 Management 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)

 Each object whether it's a device or 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. 

Back to Top

Management Information Base

Management 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. 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

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

·         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

·         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 management 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

·         system                         ·         interfaces

·         at                                 ·         ip

·         icmp                             ·         tcp

·         udp                               ·         egp

·         transmission                 ·         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)

Back to Top

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 management 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 management commands and responses. The management 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 management 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

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

·         version number

·         community name

·         data - a sequence of PDUs associated with the request

Security levels with basic SNMP

·         Authentication

·         trivial authentication based on plain text community name exchanged in SNMP messages

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

·         Authorization

·         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

·         "View" or "Cut" of the objects together with permitted access rights is then derived for that pair (community name, sending address)

·         Summary

·         Not very secure

·         SNMP version 2 is addressing this

·         Extended security is possible with current protocol (example: DES and MD5)

·         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:

Back to Top

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 management 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 Management 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.....

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

The following diagrams shows the architecture of UDP transport.

For problems or questions regarding this web contact Hardik Tank.
Last updated: June 25, 2001.