MPLS Tutorial header image

MPLS Tutorial

≡ Menu

Simple Network Management Protocol (SNMP), MIBs and SMI

7.1Network Management Systems (NMS)

Networks, today, are a complex mixture of heterogeneous components with different operating systems and different software communication utilities. Moreover, the network requirements are also growing in at least two dimensions:

1.  The number of stations per network is permanently increasing,

2.  The logical complexity of functions to be performed by the network is increasing.

Because of all this, it has become almost impossible to put together and manage large networks by human efforts alone. This is where, NMSs step in.

7.2OSI Management Functional Areas

The key functional areas of network management as defined by International Organization for Standardization (ISO) are as follows: [14]

  • Fault management: The facilities that enable the detection, isolation and correction of abnormal operation of OSI environment.
  • Accounting management: The facilities that enable charges to be established for the use of managed objects and costs to be identified for the use of those managed objects.
  • Configuration and name management: The facilities that exercise control over, identify, collect data from and provide data to managed objects for the purpose of assisting in providing for the continuous operation of inter-connection services.
  • Performance management: The facilities needed to evaluate the behaviour of managed objects and the effectiveness of communication activities.
  • Security management: The facilities that address those aspects of OSI security essential to operate OSI network management correctly and protect managed objects.

These are called FCAPS as a form of mnemonics and form the basics of any NMS.

7.3SNMP Introduction

The Simple Network Management Protocol (SNMP) was introduced in 1988 to meet the growing need for a standard for managing Internet Protocol (IP) devices. SNMP provides a standard for monitoring and controlling a network, in vendor-independent manner. SNMP allows the retrieval and alteration of networking information maintained by hosts and routers attached to a network. A network administrator can use SNMP to diagnose and correct network problems from remote hosts.

While SNMP’s predecessor, the Simple Gateway Management Protocol (SGMP), was developed to manage Internet routers, SNMP can be used to manage Unix systems, Windows systems, printers, modem racks, power supplies, and more. Any device running software that allows the retrieval of SNMP information can be managed. This includes not only physical devices but also software, such as web servers and databases.

There are currently 3 versions of SNMP:

1.  SNMP Version 1 (SNMPv1) is the current standard version of the SNMP protocol. It’s defined in RFC 1157 and is a full IETF standard. SNMPv1’s security is based on communities, which are plain-text strings (passwords) that allow any SNMP-based application, which knows the strings, to gain access to a device’s management information. There are typically three communities in SNMPv1: read-only, read-write, and trap.

2.  SNMP Version 2 (SNMPv2) is often referred to as community string-based SNMPv2. This version of SNMP is technically called SNMPv2c and is still in experimental stage.

3.  SNMP Version 3 (SNMPv3) will be the next version of the protocol to reach full IETF status. It’s currently a proposed standard. It adds support for strong authentication and private communication between managed entities.

7.4SNMP Architecture

The four key elements of the SNMP architecture are:

1.   Management station act as an interface for the human network manager into the network management station (or network operation centre NOC), from where he can monitor and control the network and help in fault recovery.

2.   Management agent is an application that resides in managed devices such as hosts, bridges, routers, etc. The agent responds to request for information and actions from the NOC and itself may send asynchronous messages to the NOC in case of important events.

3.   Management Information base (MIB): Management information is represented as a collection of managed objects. These objects together form a virtual information base called MIB. An agent may implement many MIBs, but all agents must implement a particular MIB called MIB-II [16]. This standard defines variables for things such as interface statistics (interface speeds, MTU, octets sent, octets received, etc.) as well as various other things pertaining to the system itself (system location, system contact, etc.). The main goal of MIB-II is to provide general TCP/IP management information.

4.  Network management protocol: The SNMP protocol is used to for conveying information and commands between agents and managing entities. SNMP uses the User Datagram Protocol (UDP) as the transport protocol for passing data between managers and agents. The reasons for using UDP for SNMP are, firstly it has low overheads in comparison to TCP, which uses a 3-way hand shake for connection. Secondly, in congested networks, SNMP over TCP is a bad idea because TCP in order to maintain reliability will flood the network with retransmissions. SNMP uses the UDP port 161 for sending and receiving requests, and port 162 for receiving traps from managed devices.

7.5Structure of Management Information (SMI)

Management information was used to define MIB. But what exactly does management information contain and how is it represented? The Structure of Management Information defines precisely how managed objects are named and specifies their associated data-types. SMI is based on object definition language called Abstract Syntax Notation One (ASN.1).

A managed object can be said to have 3 attributes [15]:

1.  Name: Its name or the object identifier (OID) uniquely defines a managed object. The names may be human readable or numeric (IP address like). The naming of SNMP managed objects is based on the universally accepted ASN.1 naming scheme, which is hierarchical in nature. An object ID is made up of a series of integers based on the nodes in the tree, separated by dots. For example,


 
 
 
 
 
 
 
 
 
 

Fig. 7.1 SMI tree

So, the management branch or mgmt, which defines a standard set of Internet management objects, is named as 1.3.6.1.2 or iso.org.dod.internet.mgmt . Strictly speaking, only the leaf objects are called as managed objects.

2. Type and syntax: As mentioned earlier, a manages objects type using a subset of ASN.1 data types. ASN.1, in particular, is a machine-independent, OS-independent, language-independent method for describing integers and other data types and rules that state the manner in which each of the data types are to be transmitted over the network.SMI and its data-types will be discussed in detail, shortly.

3. Encoding: A single instance of a managed object is encoded into a string of octets using the Basic Encoding Rules BER). BER defines how the objects are encoded and decoded so they can be transmitted over a transport medium such as Ethernet. BER uses TLV (Type, Length, Value) approach to encoding data for transmission. So, for each data item to be sent, the data type, the length of the data item and then the actual value of the data item are sent, in that order.

SMI currently has 2 versions: SMIv1 and SMIv2. SMIv2 provides enhancements for SNMPv2. The important data types supported by SMI are: [4,8]

INTEGER, Integer32, Unsigned32, OCTET STRING, Counter32, Counter64, OBJECT IDENTIFIER, IPaddress, Gauge32, TimeTicks, Opaque.

Brief explanation of each is as follows:

Both INTEGER and Integer32 can vary from -231 to 231-1 inclusive. Only difference being INTEGER can also be used to specify enumerated types i.e. named constants e.g. {up=1, down=2}.

Unsigned32 can have values from 0 to 232-1 inclusive.

OCTET STRING is usually used to represent text string or arbitrary binary data, up to 65535 bytes long.

Counter32 and Counter64 are counters that increase from 0 to 232-1/264-1 respectively and then wrap around to 0. 64-bit counters have been introduced for high capacity interfaces in which 32-bit counters do not provide enough capacity and wrap too fast. As the speed of network media increases, the minimum time in which a 32-bit counter wraps decreases. For example, a 10 Mbps stream of back-to-back, full-size packets causes ifInOctets to wrap in just over 57 minutes.

At 100 Mbps, the minimum wrap time is 5.7 minutes, and at 1 Gbps, the minimum is 34 seconds. [17]

OBJECT IDENTIFIER is a dotted-decimal string that represents a managed object within the object tree.

IPaddress is used to represent IP addresses.

Gauge32 represents a 32-bit number with minimum value 0 and maximum value 232 – 1 inclusive. Unlike a Counter, a Gauge can increase and decrease at will, but it can never exceed its maximum value. The interface speed on a router is measured with a Gauge.

TimeTicks is the time measured in 1/100th of a second since some event.

Opaque is an uninterpreted ASN.1 string.

In addition to these, SMI also provides:

SEQUENCE which defines lists that contain 0 or more than 1 ASN.1 datatypes.

SEQUENCE OF which defines a managed object that is made up of a SEQUENCE of ASN.1 types.

The basic structure of all the object definitions:

<name> OBJECT-TYPE

SYNTAX <datatype>

ACCESS <either read-only, read-write,write-only, not- accessible>

STATUS <either mandatory, optional, or obsolete>

DESCRIPTION

“Textual description describing this particular managed object.”

::= { <Unique OID that defines this object> }

In SNMP, MIB objects are identified by the convention x.y where,

x: actual OID of the managed object

y: instance identifier

For scalar objects, y is ALWAYS 0.

For tables, to select I row: y=1,

to select II row: y=2, so on

7.6SNMP Operations

The SNMP messages are transferred between agents and managers in the form of protocol data units (PDU). SNMPv1 supports 5 PDU types, which are as follows: [14]

Table 71 SNMPv1 PDUs

SNMPv1 PDUs

Sender-Receiver

Description

GetRequest

manager to agent

Get value of one of more MIB object instances

GetNextRequest

manager to agent

Get value of next MIB instance in list or table

SetRequest

manager to agent

Set values of one or more MIB instances.

GetResponse

agent to manager or manager to agent

Generated in response to GetRequest, GetNextRequest, SetRequest.

Trap

agent to manager

Inform manager of an exceptional agent

mplsLsrStdMIB MIB module contains managed object definitions for the Multiprotocol Label Switching (MPLS) Router as defined in Multiprotocol Label Switching Architecture, RFC 3031. Its OID is: [18]

{iso(1).identified-organization(3).dod(6).internet(1).mgmt(2). mib2(1).transmission(10).mplsStdMIB(166).mplsLsrStdMIB(2)}

css.php