Simple Network Management Protocol (SNMP)

The Simple Network Management Protocol(SNMP)is an application-layer protocol that facilitates the exchange of management information between network devices. It is part of the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite. SNMP enables network administrators to manage network performance, find and solve network problems, and plan for network growth. Two versions of SNMP exist: SNMP Version 1 (SNMPv1) and SNMP Version 2 (SNMPv2). Both versions have a number of features in common, but SNMPv2 offers enhancements, such as additional protocol operations. Standardization of yet another version of SNMPSNMP Version 3 (SNMPv3)is pending. This chapter provides descriptions of the SNMPv1 and SNMPv2 protocol operations. Figure 52-1 illustrates a basic network managed by SNMP.

SNMP Basic Components

An SNMP managed network consists of three key components: managed devices, agents, andnetwork-management systems (NMSs). A managed device is a network node that contains an SNMP agent and resides on a managednetwork. Managed devices collect and store management information and make this informationavailable to NMSs using SNMP. Managed devices, sometimes called network elements, can berouters and access servers, switches and bridges, hubs, computer hosts, or printers. An agent is a network-management software module that resides in a managed device. An agent haslocal knowledge of management information and translates that information into a form compatiblewith SNMP. An NMS executes applications that monitor and control managed devices. NMSs provide the bulkof the processing and memory resources required for network management. One or more NMSsmust exist on any managed network.

SNMP Basic Commands

Managed devices are monitored and controlled using four basic SNMP commands: read, write, trap, and traversal operations. The read command is used by an NMS to monitor managed devices. The NMS examines different variables that are maintained by managed devices. The write command is used by an NMS to control managed devices. The NMS changes the values of variables stored within managed devices. The trap command is used by managed devices to asynchronously report events to the NMS. When certain types of events occur, a managed device sends a trap to the NMS. Traversal operations are used by the NMS to determine which variables a managed device supports and to sequentially gather information in variable tables, such as a routing table.

SNMP Management Information Base (MIB)

A Management Information Base (MIB) is a collection of information that is organized hierarchically. MIBs are accessed using a network-management protocol such as SNMP. They are comprised of managed objects and are identified by object identifiers. A managed object (sometimes called a MIB object, an object, or a MIB) is one of any number of specific characteristics of a managed device. Managed objects are comprised of one or more object instances , which are essentially variables.

Two types of managed objects exist: scalar and tabular. Scalar objects define a single object instance. Tabular objects define multiple related object instances that are grouped together in MIB tables . An example of a managed object is at Input, which is a scalar object that contains a single object instance , the integer value that indicates the total number of input AppleTalk packets on a router interface . An object identifier (or object ID) uniquely identifies a managed object in the MIB hierarchy. The MIB hierarchy can be depicted as a tree with a nameless root, the levels of which are assigned by different organizations

SNMP Version 2 (SNMPv2)

SNMP Version 2 (SNMPv2) is an evolution of the initial version, SNMPv1. Originally, SNMPv2was published as a set of proposed Internet standards in 1993; currently, it is a Draft Standard. As with SNMPv1, SNMPv2 functions within the specifications of the Structure of Management Information (SMI). In theory, SNMPv2 offers a number of improvements to SNMPv1, including additional protocol operations.

SNMPv2 and Structure of Management Information (SMI)

The Structure of Management Information (SMI) defines the rules for describing management information, using Abstract Syntax Notation One (ASN.1). The SNMPv2 SMI is described in RFC 1902. It makes certain additions and enhancement to the SNMPv1 SMI-specific data types, such as including bit strings, network addresses, and counters. Bit strings are defined only in SNMPv2 and comprise zero or more named bits that specify a value. Network addresses represent an address from a particular protocol family. SNMPv1 supports only 32-bit IP addresses, but SNMPv2 can support other types of addresses as well. Counters are non-negative integers that increase until they reach a maximum value and then return to zero. In SNMPv1, a 32-bit counter size is specified. In SNMPv2, 32-bit and 64-bit counters are defined. SMI Information Modules The SNMPv2 SMI also specifies information modules, which specify a group of related definitions. Three types of SMI information modules exist: MIB modules, compliance statements, and capability statements. MIB modules contain definitions of interrelated managed objects. Compliance statements provide a systematic way to describe a group of managed objects that must be implemented for conformance to a standard. Capability statements are used to indicate the precise level of support that an agent claims with respect to a MIB group. An NMS can adjust its behavior toward agents according to the capabilities statements associated with each agent.

SNMPv2 Protocol Operations

The Get, GetNext, and Set operations used in SNMPv1 are exactly the same as those used in SNMPv2. SNMPv2, however, adds and enhances some protocol operations. The SNMPv2 Trap operation, for example, serves the same function as that used in SNMPv1. It, however, uses a different message format and is designed to replace the SNMPv1 Trap. 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 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.

SNMP 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 managed devices and provide a summary of the information learned, or that it report locally stored management information.

SNMP Security
SNMP lacks any authentication capabilities, which results in vulnerability to a variety of security threats. These include masquerading, 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.

SNMP 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 dataunit (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.

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

Bilingual 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

SNMPv2 Message Format

SNMPv2 messages consist of a header and a PDU. Figure 52-7 illustrates the basic format of an SNMPv2 message.

SNMPv2 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 (PDU)

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)

The following descriptions summarize the fields illustrated in Figure 52-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).

SNMPv3
Due to lack of security with the use of SNMP, network administrators were using other means, such as telnet for configuration, accounting, and fault management. SNMPv3 addresses issues related to the large-scale deployment of SNMP, accounting, and fault management. Currently, SNMP is predominantly used for monitoring and performance management. SNMPv3 defines a secure version of SNMP and also facilitates remote configuration of the SNMP entities. Primary Goals of SNMPv3 1. To verify that each received SNMP message has not been modified during its transmission through the network. 2. To verify the identity of the user on whose behalf a received message claims to have been generated. 3. To detect received messages that contain management information, whose time of generation was not recent. 4. To assure that the contents of each received message are protected from disclosure. Comparative Overview of SNMPv3 with SNMPv1 and SNMPv2c SNMPv1 and SNMPv2c have a wide deployment base covering the following.

A platform-independent data definition syntax - A subset of ASN.1 A platform-independent data transfer notation - BER Communication between the peer entities - SNMP communication protocol with message formats, message types, etc. o Message contains the SNMP version o Message contains the community string which is used to provide some security Guidelines for definition of management data - SMI Management data definition repository - The MIB files

SNMPv3 provides a secure environment for the management of systems covering the following.

Identification of SNMP entities to facilitate communication only between known SNMP entities - Each SNMP entity has an identifier called the SNMPEngineID, and SNMP communication is possible only if an SNMP entity knows the identity of its peer. Traps and Notifications are exceptions to this rule. Support for security models - A security model may define the security policy within an administrative domain or an intranet. SNMPv3 contains the specifications for USM. Definition of security goals where the goals of message authentication service include protection against the following.

o o

Modification of Information - Protection against some unauthorized SNMP entity altering in-transit messages generated by an authorized principal. Masquerade - Protection against attempting management operations not authorized for some principal by assuming the identity of another principal that has the appropriate authorizations. Message Stream Modification - Protection against messages getting maliciously re-ordered, delayed, or replayed to effect unauthorized management operations. Disclosure - Protection against eavesdropping on the exchanges between SNMP engines.

Specification for USM - USM consists of the general definition of the following communication mechanisms available. o Communication without authentication and privacy (NoAuthNoPriv). o Communication with authentication and without privacy (AuthNoPriv). o Communication with authentication and privacy (AuthPriv). Definition of different authentication and privacy protocols - Currently, the MD5 and SHA authentication protocols and the CBC_DES and CFB_AES_128 privacy protocols are supported in the USM. Definition of a discovery procedure - To find the SNMPEngineID of an SNMP entity for a given transport address and transport endpoint address. Definition of the time synchronization procedure - To facilitate authenticated communication between the SNMP entities. Definition of the SNMP framework MIB - To facilitate remote configuration and administration of the SNMP entity. Definition of the USM MIBs - To facilitate remote configuration and administration of the security module. Definition of the VACM MIBs - To facilitate remote configuration and administration of the access control module.

The SNMPv3 focuses on two main aspects, namely security and administration. The security aspect is addressed by offering both strong authentication and data encryption for privacy. The administration aspect is focused on two parts, namely notification originators and proxy forwarders. SNMPv3 defines two security-related capabilities, namely the USM and VACM. USM provides authentication and privacy (encryption) functions and operates at the message level. VACM determines whether a given principal is allowed access to a particular MIB object to perform specific functions and operates at the PDU level.

The SNMPv3 message consists of the following fields.

1. msgVersion - This field contains the SNMP message version. A value 0 is an SNMPv1 message, 1 is an SNMPv2c message, 2 is an SNMPv2 message, and 3 is an SNMPv3 message. The value of message version is used to choose between the different message processing models (SNMPv1, SNMPv2c, or SNMPv3) available in the SNMP engine/entity. The following fields are part of the SNMPv3 message and are not available in the SNMPv1 or SNMPv2c message. 2. msgID - This field contains the SNMP message identifier. This is the unique ID associated with the message. The msgID field is different from the reqID field available in the PDU. It is possible that a received PDU that is part of a message cannot be decoded due to security parameters between the SNMP entities. The msgID is used to relate the request with a response during a transaction. 3. msgMaxSize - This field gives the maximum size of the message which the requesting SNMP entity can accept. 4. msgFlags - This field contains the message security level. The bit 0 of msgFlags indicates whether a message is authenticated. The bit 1 indicates whether a message uses privacy. The bit 2 indicates whether a report PDU is expected for the message (in case the message is dropped or a response cannot be generated). 5. msgSecurityModel - This field indicates the security model used to generate the message. It has a value of 3 when USM is used. 6. msgEngineID - This field has the SNMPEngineID of the authoritative SNMP entity involved in the transaction. When a request PDU is generated from an SNMP engine, the remote peer (agent for Get request and manager for Trap request) is the authoritative SNMP entity. 7. msgEngineBoots - This field indicates the number of times the authoritative SNMP entity has booted. This field is used in authenticated message to validate the timeliness of a message. 8. msgEngineTime - This field indicates the time since the authoritative SNMP entity has been rebooted. This field is used in authenticated messages to validate the timeliness of a message. 9. msgUserName - This field contains the principal who originated the request. The fields msgUserName and the msgEngineID are used to locate the security data associated with the message from the USM database. This security data is used to authenticate and process the message. 10. msgSecurityParams - This field contains the security parameters that are security model dependent. It contains the authentication parameters and the privacy parameters for USM. For an AuthPriv message, the authentication parameter has the digest computed for the message using the authentication protocol applicable for the USM entry and the privacy parameter has the salt generated, while encrypting the message using the privacy protocol applicable to the USM entry. 11. contextEngineID - Within an administrative domain, the contextEngineID uniquely identifies an SNMP entity that may realize an instance of a context with a particular contextName. 12. contextName - A contextName is used to name a context. Each contextName must be unique within an SNMP entity.

13. pdu - The SNMP PDU (Protocol Data Unit) is used for communication between the SNMP entities. PDU encapsulates the SNMP request ID, error status, variable bindings, and so on. There are different types of PDUs, such as GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, Response-PDU, SetRequest-PDU, Trap-PDU, InformRequest-PDU, SNMPv2-Trap-PDU, and Report-PDU. The exact format of the PDU depends on the type of the PDU.

Remote Monitoring (RMON)

Remote Monitoring (RMON) is a standard monitoring specification that enables various network monitors and console systems to exchange network-monitoring data. RMON provides network administrators with more freedom in selecting network-monitoring probes and consoles with features that meet their particular networking needs. This chapter provides a brief overview of the RMON specification, focusing on RMON groups. RMON Groups An important part of network management lies in monitoring parts of the network in order to provide summary information such as error or performance statistics. Some application level program was required to gather the statistics from each network monitoring station in order to build a central view of the network SNMP does not have this functionality. To address this disparity the RMON (Remote Monitoring) MIB was developed .This specification provided a repository for statistics in the form of a MIB accessible to SNMP. Previously the central management station would gather low-level data from devices around the network and perform the analyses required to generate required statistics. As networks became larger, management stations had to become more powerful resulting in scalability problems.The sample network shown in Fig. 20

The management station must poll each machine on the network at regular intervals to gather and then analyse this data. At points D, E and C the traffic from each sub-network would be acceptable. When this traffic is directed through points B and A there is great potential for bottlenecks. Thus, the central LAN must be able to deal with large volumes of management traffic, which may require costly upgrades. Further, what happens when the WAN link at point G becomes congested or goes down? By introducing RMON facilities into the network at each of the asterisked points, potential bottlenecks can be alleviated. The RMON entity within each sub-network gathers raw data and generates the required statistics. The management station may then poll each RMON entity for the (less voluminous) statistics when required (pre-emptive monitoring). If a sub-network is isolated from the central LAN for a period of time, the RMON entity may continue monitoring (off-line operation). RMON entities can be configured to report concurrently to each manager (multiple managers). A shortcoming of RMON is its inability to operate above the MAC layer as it was originally designed to provide remote monitoring services for physical networks and as a result the RMON MIB only contains object definitions for these layers. RMON2 is a modification to RMON that includes monitoring of protocol traffic within layers 37. Hence traffic at specific network addresses (e.g. IP numbers) or even between specific hosts (e.g. WWW servers) may be monitored. This allows the management system to determine the ultimate sources and destinations of traffic (rather than just that coming in and going out of the sub-network).

CMIP
The Common Management Information Protocol (CMIP) is the OSI specified network management protocol.Common Management Information Protocol (CMIP), an OSI protocol used with the Common Management Information Services (CMIS), supports information exchange between network management applications and management agents. CMIS defines a system of network management information services. CMIP supplies an interface that provides functions which maybe used to support both ISO and user-defined management protocols. The CMIP specification for TCP/IP networks is called CMOT (CMIP Over TCP) and the version for IEEE 802 LAN's is called CMOL (CMIP Over LLC). CMIP/CMIS are proposed as competing protocols to the Simple Network Management Protocol (SNMP ) in the TCP/IP suite . CMIP uses an ISO reliable connection-oriented transport mechanism and has built in security that supports access control, authorization and security logs. The management information is exchanged between the network management application and management agents thru managed objects. Managed objects are a characteristic of a managed device that can be monitored, modified or controlled and can be used to perform tasks. CMIP does not specify the functionality of the network management application, it only defines the information exchange mechanism of the managed objects and not how the information is to be used or interpreted. The following picture provides a high level picture of the network management system based on the CMIP/CMIS:

The major advantages of CMIP over SNMP are:

CMIP variables not only relay information, but also can be used to perform tasks. This is impossible under SNMP. CMIP is a safer system as it has built in security that supports authorization, access control, and security logs. CMIP provides powerful capabilities that allow management applications to accomplish more with a single request. CMIP provides better reporting of unusual network conditions

Access to managed information in the managed objects is provided by the Common Management Information Service Element (CMISE) that uses CMIP (Common Management Information Protocol) to issue requests for management services. The management services provided by CMIP/CMISE can be organized into two distinct groups, management operation services initiated by a manager to request that an agent provide certain services or information, and notification services, used by the management agents to inform the managers that some event or set of events have occurred.