Dept. of Computer Science and Engineering SNMP Version 2 (SNMPv2) J. Won-Ki Hong Dept. of Computer Science and Engineering POSTECH Tel: 054-279-2244 Email: jwkhong@postech.ac.kr 1 1

Table of Contents The Birth of SNMPv2 SNMPv2 RFCs SNMPv2 Enhancements SNMPv2 Protocol Operations SNMPv2 Coexistence with SNMPv1 3

The Birth of SNMPv2 a major problem with SNMP is the lack of security secure SNMP was proposed (July 1992) to solve this problem in SNMP Simple Management Protocol (SMP) was also proposed (July 1992) to extend the SNMP functionality secure SNMP + SMP = SNMPv2 (March 1993) a major security flaw was detected in this proposal and the security aspects were dropped and the result is community-based SNMPv2 (Jan. 1996)

SNMPv2 RFCs RFC 1901 (experimental) Introduction to Community-based SNMPv2 RFC 1902 (draft) -> RFC 2578 (standard) Structure of Management Information for SNMPv2 (SMIv2) RFC 1903 (draft) -> RFC 2579 (standard) Textual Conventions for SMIv2 RFC 1904 (draft) -> RFC 2580 (standard) Conformance Statements for SMIv2

SNMPv2 RFCs (cont’d) RFC 1905 (draft) RFC 1906 (draft) Protocol Operations for SNMPv2 RFC 1906 (draft) Transport Mappings for SNMPv2 RFC 1907 (draft) Management Information Base for SNMPv2 RFC 1908 (draft) Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework

SNMPv2 Key Enhancements SMIv2 (a superset of SMIv1) provides more elaborate specification and documentation of managed objects and MIB modules object type macros expanded (see Fig. 11.1, 11.2 & Table 11.2) creating and deleting conceptual rows in a table (as used in RMON) notification definitions information modules new SNMP MIB definitions are defined using SMIv2 Manager-to-Manager Capability for managing large, distributed networks Protocol Operations bulk management information retrieval manager-to-manager communication

Comparison of Data Types

Notification Type MACRO NOTIFICATION-TYPE MACRO ::= BEGIN TYPE NOTATION ::= ObjectsPart “STATUS” Status “DESCRIPTION” Text ReferPart VALUE NOTATION ::= value (VALUE NotificationName) ObjectsPart ::= “OBJECTS” “{“ Objects “}” | empty Objects ::= Object | Objects “,” Object Object ::= value (Name ObjectName) Status ::= “current” | “deprecated” | “obsolete” ReferPart ::= “REFERENCE” Text | empty Text ::= “““ string “““ END

Notification Type Example coldStart NOTIFICATION-TYPE STATUS current DESCRIPTION "A coldStart trap signifies that the SNMPv2 entity, acting in an agent role, is reinitializing itself and that its configuration may have been altered." ::= { snmpTraps 1 } -- From RFC 1907

Module Identity MACRO MODULE-IDENTITY MACRO ::= BEGIN TYPE NOTATION ::= “LAST-UPDATED” value (Update UTCTime) “ORGANIZATION” Text “CONTACT-INFO” Text “DESCRIPTION” Text RevisionPart VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) RevisionPart ::= Revisions | empty Revisions ::= Revision | Revisions Revision Revision ::= “REVISION” value (Update UTCTime) Text ::= “““ string “““ END

Module Identity Example rmon MODULE-IDENTITY LAST-UPDATED "9605270000Z" ORGANIZATION "IETF RMON MIB Working Group" CONTACT-INFO "Steve Waldbusser (WG Editor) Postal: International Network Services 650 Castro Street, Suite 260 Mountain View, CA 94041 Phone: +1 415 254 4251 Email: waldbusser@ins.com DESCRIPTION "The MIB module for managing remote monitoring device implementations. This MIB module augments the original RMON MIB as specified in RFC 1757." ::= { mib-2 16 }

Object Identity MACRO OBJECT-IDENTITY MACRO ::= BEGIN TYPE NOTATION ::= “STATUS” Status “DESCRIPTION” Text ReferPart VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) Status ::= “current” | “deprecated” | “obsolete” ReferPart ::= “REFERENCE” Text | empty Text ::= “““ string “““ END

Object Identity Example snmpUDPDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMPv2 over UDP transport domain. The corresponding transport address is of type SnmpUDPAddress." ::= { snmpDomains 1 } -- from RFC 1906

SNMPv2 MIB Access

SNMPv2 Operations GetRequest - get the value for each listed object GetNextRequest - get next value for each listed object GetBulkRequest - get multiple values Response - respond to manager request SetRequest - set value for each listed object InformRequest - send unsolicited information from a manager to another SNMPv2-Trap - send unsolicited information from an agent to a manager

SNMPv2 PDU Formats version (1) community PDU SNMPv2 Message variable-bindings request id PDU type (a) GetRequest-PDU, GetNextRequest-PDU, SetRequest-PDU, SNMPv2-Trap-PDU, InformRequest-PDU PDU type request id error status error index variable-bindings (b) Response-PDU PDU type request id non- repeaters max- repetitions variable-bindings (c) GetBulkRequest-PDU name1 value1 name2 value2 . . . nameN valueN (d) variable-bindings

GetBulkRequest used to minimize the exchanges required to retrieve a large amount of information selection principle is the same as GetNextRequest the next object instance in lexicographic order includes a list of (N + R) variable names in the variable-bindings list the first N variables for retrieving single values the next R variables for retrieving multiple values non-repeaters and max-repetition fields are used to indicate the number of N and R variables

Interpretation of GetBulkRequest Fields name1 name2 .... nameN nameN+1 .... nameN+R For first N variables: provide one value each (first lexicographic successor) For last R variables: provide M values each (first M lexicographic successors) L = number of names in variable-bindings field N = MAX [ MIN (non-repeaters, L), 0 ] M = MAX [ max-repetitions, 0 ] R = L - N

GetBulkRequest Example GetBulkRequest (non-repeaters = 2, max-repeaters = 6, X, Y, TA, TB, TC) Manager issues request with six variable names; for the first two variable (non-repeaters=2), a single value is requested; for the remaining variables six successive values (max-repeaters=6) are requested. Agent (e.g, router) x Y Table a TA TB TC NMS Agent returns single value for X, Y, and six rows of table a Response [X, Y, TA(1), TB(1), TC(1), TA(2), TB(2), TC(2), TA(3), TB(3), TC(3), TA(4), TB(4), TC(4), TA(5), TB(5), TC(5), TA(6), TB(6), TC(6) ]

SNMPv2-Trap and InformRequest is sent from an agent to a manager when an unusual event occurs no response is required InformRequest is sent from a manager for passing information to an application running in another manager Response PDU is used to acknowledge the request for hierarchical or distributed management where multiple managers are involved

SNMPv2 PDU Sequences Manager Agent GetRequest PDU GetNextRequest PDU Response PDU SetRequest PDU GetNextRequest PDU SNMPv2-Trap PDU GetBulkRequest PDU InformRequest PDU

PDU Comparisons

Transport Mappings RFC 1906 specifies the mapping of SNMPv2 onto the following transport protocols User Datagram Protocol (UDP) OSI Connectionless-Mode Network Service (CLNS) OSI Connection-Oriented Network Service (CONS) Novell Internetwork Packet Exchange (IPX) Appletalk The SNMPv2 document states that UDP is the preferred mapping

Coexistence by Means of Proxy Agent SNMPv1 agent SNMPv2 manager SNMPv2 environment SNMPv1 environment GetRequest GetNextRequest SetRequest GetBulkRequest Response GetResponse SNMPv2-Trap Trap SNMPv2 manager-to-agent PDUs SNMPv1 manager-to-agent SNMPv2 agent-to- manager PDUs SNMPv1 agent-to-

Coexistence by Means of Bilingual Manager SNMPv2 manager InformRequest, Response GetRequest, GetNextRequest, SetRequest Bilingual manager (v1, v2) InformRequest, Response SNMPv1 agent SNMPv2-Trap, Response GetResponse, Trap SNMPv2 agent getRequest, getNextRequest getBulkRequest, setRequest

Summary SNMPv2 is a natural extension of SNMPv1 Key enhancements in SNMPv2 are: more elaborate MIB specification capability (SMIv2) Manager-to-Manager communication Bulk information transfer SNMPv2 failed to improve on security More powerful but more complex than SNMPv1 SNMPv3 focuses on improving the security aspect