SNMP has become the de facto standard for network management. SNMP is a simple solution that requires little code to implement, which enables vendors to easily build SNMP agents for their products. In addition, SNMP is often the foundation of the network management architecture. SNMP defines how management information is exchanged between network management applications and management agents. Below Figure shows the terms used in SNMP; they are described as follows:

■ Manager: The manager, a network management application in an NMS, periodically polls the SNMP agents that reside on managed devices for the data, thereby enabling information to be displayed using a GUI on the NMS. A disadvantage of periodic SNMP polling is the possible delay between when an event occurs and when it is collected by the NMS; there is a trade-off between polling frequency and bandwidth usage.

■ Protocol: SNMP is a protocol for message exchange. It uses the User Datagram Protocol (UDP) transport mechanism to send and retrieve management information, such as MIB variables.

■ Managed device: A device (such as a router) managed by the manager.

■ Management agents: SNMP management agents reside on managed devices to collect and store a range of information about the device and its operation, respond to the manager’s requests, and generate traps to inform the manager about certain events. SNMP traps are sent by management agents to the NMS when certain events occur. Trap notifications could result in substantial network and agent resource savings by eliminating the need for some SNMP polling requests.

MIB: The management agent collects data and stores it locally in the MIB, a database of objects about the device. Community strings, which are similar to passwords, control access to the MIB. To access or set MIB variables, the user must specify the appropriate read or write community string; otherwise, access is denied.

Figure: NMP Is a Protocol for Management Information Exchange

SNMPv1

The initial version of SNMP, SNMPv1 is defined in RFC 1157, Simple Network Management Protocol (SNMP). The protocol’s simplicity is apparent by the set of operations that are available. Figure below shows the basic SNMP messages, which the manager uses to transfer data from agents that reside on managed devices. These messages are described as follows:

■ Get Request: Used by the manager to request a specific MIB variable from the agent.

■ Get Next Request: Used after the initial get request to retrieve the next object instance from a table or list.

■ Set Request: Used to set a MIB variable on an agent.

■ Get Response: Used by an agent to respond to a manager’s Get Request or Get Next Request message.

■ Trap: Used by an agent to transmit an unsolicited alarm to the manager. A Trap message is sent when specific conditions occur, such as a change in the state of a device, a device or component failure, or an agent initialization or restart.

Figure: NMP Is a Protocol for Management Information Exchange

SNMPv2

SNMPv2 is a revised protocol that includes performance and manager-to-manager communication improvements to SNMP. SNMPv2 was introduced with RFC 1441, Introduction to version 2 of the Internet-standard Network Management Framework, but members of the IETF subcommittee could not agree on several sections of the SNMPv2 specification (primarily the protocol’s security and administrative needs). Several attempts to achieve acceptance of SNMPv2 have been made by releasing experimental modified versions, commonly known as SNMPv2*, SNMPv2, SNMPv2u, SNMPv1+, and SNMPv1.5, which do not contain the disputed parts. Community-based SNMPv2 (or SNMPv2c), which is defined in RFC 1901, Introduction to Community-based SNMPv2, is referred to as SNMPv2 because it is the most common implementation. The “c” stands for community-based security because SNMPv2c uses the same community strings as SNMPv1 for read and write access. SNMPv2 changes include the introduction of the following two new message types:

■ GetBulk message type: Used for retrieving large amounts of data, such as tables. This message reduces repetitive requests and replies, thereby improving performance.

■ InformRequest: Used to alert the SNMP manager of a specific condition. Unlike unacknowledged trap messages, InformRequest messages are acknowledged. A managed device sends an InformRequest to the NMS; the NMS acknowledges the receipt of the message by sending a Response message back to the managed device.

Another improvement of SNMPv2 over SNMPv1 is the addition of new data types with 64-bit counters because 32-bit counters were quickly overflowed by fast network interfaces. On Cisco routers, Cisco IOS software release 11.3 and later versions implement SNMPv2. However, neither SNMPv1 nor SNMPv2 offers security features. Specifically, SNMPv1 and SNMPv2 can neither authenticate the source of a management message nor encrypt the message. Because of the lack of security features, many SNMPv1 and SNMPv2 implementations are limited to a read-only capability, reducing their usefulness to that of a network monitor.

SNMPv3

SNMPv3 is the latest SNMP version to become a full standard. Its introduction has moved SNMPv1 and SNMPv2 to historic status. SNMPv3, which is described in RFCs 3410 through 3415, adds methods to ensure the secure transmission of critical data to and from managed devices. Table 3-2 lists these RFCs. Note that these RFCs make RFCs 2271 through 2275 and RFCs 2570 through 2575 obsolete.

SNMPv3 introduces the following three security levels:

■ NoAuthNoPriv: Without authentication and without privacy (encryption).

■ AuthNoPriv: With authentication but without privacy. Authentication is based on Hash- Based Message Authentication Code-Message Digest 5 or HMAC-Secure Hash Algorithm algorithms.

■ AuthPriv: With authentication as described earlier and privacy using the 56-bit Cipher-Block Chaining-Data Encryption Standard encryption standard.