SNMP -- Network Management In Evolution


As network complexity grows, the management capabilities of SNMP evolve

With the transition from centralized computing systems in the early to mid 1980's, system and network managers became faced with a growing problem. Instead of a single, centrally managed system, systems have become widely distributed, with the importance and sophistication of each component increasing. Issues such as availability, performance, fault identification and diagnosis all became greater challenges to system administrators. In the extreme case, the exponential growth of the Internet presented a clear need for standard management approaches. Following some early protocols such as the Simple Gateway Monitoring Protocol (SGMP), the Simple Network Management Protocol (SNMP) gained early acceptance as the management protocol of choice for IP networks.

From its original beginnings as a "simple" solution to the challenges involved in managing the operation of networking equipment, SNMP continues to evolve in support of increasingly sophisticated requirements. Through several steps, SNMP has evolved into two major versions, the original Simple Network Management Protocol, and the enhanced SNMP version 2, or SNMPv2. Where the original network management strategies for TCP/IP networks were to start with the use of SNMP and gradually evolve to the more sophisticated OSI based CMIP protocols known as CMIP over TCP/IP (CMOT), the additional features provided by SNMPv2 have led to two separate network management strategies. Where many data network equipment providers have chosen the SNMP route, most of the major telcos have opted to make use of the OSI network management protocol suite using the CMIP family of protocols and services.

Components and Terms...

Network management architectures typically consist of the use of two primary components, managers and agents. Managers provide a higher level perspective of system performance monitoring and controling the behavior of the managed devices. Agents are processes that reside at the managed device and provide the managers with insight into the managed equipment status. Agents are either integrated into the devices or in cases where insufficient resources are available, in protocol translating equipment that is collocated with the managed device. These translation devices are also known as proxy agents.

SNMP provides a set of services that allows SNMP managers (of which there are a number of commercial applications available) interact with SNMP agents that provide access to management information of the managed equipment (and/or software). Through this information, a central manager, or managers provide detailed and/or enterprise wide views of a network. This management information is referenced through a construct called a Management Information Base (MIB) that is defined through a set of primitives referred to as the Structure of Management Information (SMI). MIBs are constructed of individually addressable objects that can take a variety of forms depending on the managed application and the version of SNMP. The protocol itself provides a set of mechanisms for the managers and agents to exchange values of elements contained within a MIB.

With the complexity of networks continuing to increase, the capabilities of SNMP have grown. Shortcomings in the original version of SNMP (now often referred to as SNMPv1), included a lack of security, a limited protocol transaction set, limitations in the SMI, and a lack of a manager to manager communication. Security limitations of SNMP can make managed equipment vulnerable to unauthorized users reconfiguring equipment managed on an open network. The SNMPv1 protocol transaction set is limited to gets, sets, and traps of individual objects in the MIB; large information sets can require several transactions to retrieve a row of information. Refinements to the SMI were viewed as useful for a more complete description of management information. Manager to manager capabilities were viewed as affording the ability for a standard approach to large management architectures.

Two parallel efforts were performed to augment the capabilities of SNMPv1. Secure SNMP, also referred to as S-SNMP, defined a set of modifications to the SNMP protocols and MIB to provide authentication, confidentiality, integrity and access control for the SNMP services. A separate effort, the Simple Management Protocol (SMP) addressed the security issues along with the ability to transfer larger sets of information with individual protocol exchanges and a capability to operate over architectures beyond just TCP/IP. SMP was published as a private proposal by Jeffrey Case of SNMP Research, Keith McCloghrie of Hughes LAN Systems, Marshall Rose of Dover Beach Consulting, and Steven Waldbusser of Carnegie-Mellon University. With SMP containing both the security and functional elements, it was selected over S-SNMP as the baseline for the follow-on to SNMP, SNMPv2. Many of the S-SNMP security features are included in SNMPv2, with some simplifications to limit the clock-synchronization dependencies of S-SNMP. While many have felt that the simplicity of SNMP has been lost with SNMPv2, SNMPv2 retains much of the flavor of the original, with modifications and enhancements to address SNMP's shortcomings.

SMI

Request For Comment (RFC) 1155 defines the SNMP SMI, identifying the data types, information organization, and encoding rules used in SNMP implementations. All information stored in the SNMP MIB is defined using a subset of the Abstract Syntax Notation One (ASN.1). Information is referenced through a heirarchical set of tables, as the MIB-II example shown in Figure 1.

Figure 1 - MIB-II Object Groups (from Stallings, SNMP and SNMPv2)


Addressing of individual items uses the dot separated notation that you may already be familiar with in the IP addressing notation. For example, the mib-2 interfaces group address is "1.3.1.1.2.1.2". Each entry in the database is referred to as an "OBJECT-TYPE". The MIB is described using a set of ASN.1 macros that can be found in RFC 1155 and RFC 1212 (used for MIB-II). Each object macro takes the following form:

OBJECT-TYPE MACRO ::=

BEGIN

TYPE NOTATION ::= "SYNTAX" type (TYPE ObjectSyntax)

"ACCESS" Access

"STATUS" Status

VALUE NOTATION ::= value (VALUE ObjectName)


Access ::= "read-only"

| "read-write"

| "write-only"

| "not-accessible"

Status ::= "mandatory"

| "optional"

| "obsolete"

END


Object types (SYNTAX) supported by SNMP include the following:


Integer

Octet String

NULL

Object Identifier (OID)

Sequence, Sequence of



Of these items, the first three are used to express specific object values, an object identifier is used to reference a subsequent layer (row) of information, a sequence is used to express an element as a sequence of information elements (that can be any of the object types). Finally, "sequence of" is used to reference a table of information, such as IP routing tables, TCP connections, and any other item that is likely to be repeated several times. Access types include read-only, read-write, write-only, and not-accessible.

As an example, the interface table (from RFC 1213) is table of interface entry rows, each of which is described by the object IfEntry.

ifTable OBJECT-TYPE

SYNTAX SEQUENCE OF IfEntry

ACCESS not-accessible

STATUS mandatory

DESCRIPTION

"A list of interface entries. The number of

entries is given by the value of ifNumber."

::= { interfaces 2 }


ifEntry OBJECT-TYPE

SYNTAX IfEntry

ACCESS not-accessible

STATUS mandatory

DESCRIPTION

"An interface entry containing objects at the

subnetwork layer and below for a particular

interface."

INDEX { ifIndex }

::= { ifTable 1 }


ifEntry ::=

SEQUENCE {

ifIndex

INTEGER, .....

}



In this example, the interface table can be found at 1.3.1.1.2.1.2.2, and each ifEntry is found as a separate row beneath ifTable, with each element of the ifEntry holding the actual information values.

An important component in the SNMP series of standards is the MIB structure, briefly outlined in Figure 1. MIB-II, defined in RFC 1213 as a superset of MIB-I (RFC-1156), provides a framework for management of TCP/IP network components. Several groups are contained in the MIB, including a system group to provide general information about the managed device, the interfaces group that provides statistics and configuration information on the component's interfaces,an address translation (at) group that provides the device's physical to network address mappings, the IP group that describes the device's IP operations, etc. Vendors can add objects describing the operation of their devices to the private subtree. Also, an important addition to MIB-II is the Remote Monitoring (RMON) MIB definition that provides a mechanism to use SNMP to analyze network traffic, to the level of detail of even acting as a protocol analyzer, capturing packets for analysis by the management systems.

The transfer of this information between the manager and the agents is accomplished through the SNMP protocol defined in RFC 1157. SNMP provides three primitive operations, Get, for retrieving information from the agent to the manager, Set that allows the manager to change the value of MIB objects, and Traps, that provide the agents with a mechanism to inform managers that a network critical event has occurred. For TCP/IP networks, it is recommended that SNMP transactions are sent using the User Datagram Protocol (UDP). While UDP does not provide delivery guarantees, it was selected to prevent the management protocols from interfering with network performance, and to not have them be reliant on maintaining connections through all conditions. SNMP messages include: Each of these protocol data units (PDUs) can reference one or more MIB variables.specified in what is referred to as the variable-bindings portion of the message. Each of the message consists of two major parts, with all messages beginning with the version and community name that can be used by the agent as an access control mechanism to limit access to authorized managers, followed by the PDU specific information. Variable bindings are sent using the ASN.1 Basic Encoding Rules (BER).

While extremely useful as a tool in network management, concerns have been expressed in the use of SNMP for managing large networks. These deficiencies include: high-overhead to retrieve large blocks of data, heavy reliance on polling, unreliable trap delivery that can result in critical events being missed, limited security, and no ability to support manager to manager communications. In response, S­SNMP and SMP were developed with pieces of each of these protocols resulting in SNMPv2. S-SNMP added stronger authentication, confidentiality, and access control features to the SNMP protocols. However, one of its major drawbacks was a heavy reliance on clock synchronization, that could result in additional hardware requirements for managed equipment (e.g., GPS receivers). The SNMPv2 security protocols resolved the time synch problems by adding information to the security protocol elements. Features of SNMPv2 can be found in the following RFCs: The most notable of the substantial modifications to SNMP are the GetBulkRequest that supports large queries, extensions and modifications to the SMI, the Manager to Manager MIB, and the security protocol that helps to mitigate threats of unwanted attacks on network operation through the network management system.

SNMP has achieved a strong market presence, and hopes for SNMPv2 are riding high, with many of the agent software vendors providing complete support for version 2 and management products being developed. There is still a good bit of active discussion on the final form and interpretations of the version 2 administrative model. Most major internet communications equipment providers have developed and published MIB extensions to support the control and management of their equipment. Many test equipment vendors provide SNMP support for the Remote Monitoring (RMON) MIB. The transition from SNMP to CMOT (or even from TCP/IP to OSI based protocols) has evolved into more of segmented support for each of these useful sets of standards. SNMP will likely remain a dominant management protocol for some time to come.


References:

Miller, M. "Managing Internetworks with SNMP" 1993, M&T Books, New York, N.Y.
Rose, M, "The Simple Book -- AnIntroduction To Internet Management", Prentice Hall Englewood Cliffs New Jersey, 1994
Stallings, W., "SNMP, SNMPv2, and CMIP, The Practical Guide to Network-Management Standards," 1993 Addison-Wesley Publishing Company, Reading Massachusetts