SNMPv2 Management Information

1. SNMPv2Management Information Prof. Choong Seon HONG

2. Overview • SNMPv2 expands the functionality of SNMP and broadens it applicability to include OSI-based as well as TCP/IP-based networks

3. 11.1 Background • The development of SNMPv2 • SNMP advantages • SMI and SNMP MIB are quite simple and therefore can be easily and quickly implemented • SNMP is based on the Simple Gateway Monitoring Protocol (SGMP), for which a great deal of operational experience had been gained. • By 1988, the critical need of network management, in short term (for current level of network complexity) and long term (for more complex environments) • So, two-track policy was adopted: SNMP would be used to meet immediate network management needs, and an OSI-based solution would be pursued for long-term needs. • OSI-based solution was CMOT (CMIP over TCP/IP)

4. Background (cont’d) • The development of SNMPv2 (cont’d) • Two-track strategy has not worked, for several reasons 1. It was initially intended that SMI and MIB of SNMP be subsets of those for OSI systems management. • So, this was planned to enable a relatively easy transition. • But, the complex object-oriented approach of OSI was incompatible with quick deployment of SNMP 2. Development of stable OSI standards, and the product implementation for network management has taken than anticipated. • SNMP has been implemented by a broad range of vendors and is widely deployed. • According to the large and complex network configuration, SNMP life is reaching the end of its useful life • So, interesting in fixing SNMP to extend its useful lifetime

5. Background (cont’d) • The development of SNMPv2 (cont’d) • One major flaw of that has inhibited the use of SNMP is that it provides no security facilities • no capability to authenticate the source management message nor any capability to prevent eavesdropping. • SNMP is vulnerable to attacks that can modify or disable a network configuration • So, secure SNMP was proposed, in July 1992 • Because secure SNMP does not address other deficiencies related performance and functionality. • SMP (Simple Management Protocol) was developed.

6. Background (cont’d) • The development of SNMPv2 (cont’d) • The extensions defined in the SMP proposal fall into four categories • Scope : SMP is designed to facilitate management of arbitrary resources, not just “network resource”. Thus, SMP can be applications management, systems management, and manager-to-manager communication • Size, speed, and efficiency : The development of a bulk transfer capability for the efficient exchange of large amounts of management information • Security and privacy : SMP incorporate the enhancements found in secure SNMP • Deployment and compatibility : designed to incorporate with SNMP platforms, using a subset of SMP capabilities • After the publication of secure SNMP and SMP, both in July of 1992,, a consensus emerged within the Internet community that it was highly desirable to enable users and vendors to make a single transition for the original SNMP to second-generation SNMP • SMP was accepted as a baseline for beginning the process of defining a new SNMP standard, known as SNMP version2

7. Background (cont’d) • The development of SNMPv2 (cont’d) • SNMPv2 functional working group completed its work in Dec. of 1992 • SNMPv2 security working group completed its work in Jan. of 1993 • Then, a set of Proposed Internet Standards in March of 1993 • New set of RFCs issued in 1996 with dropping the security aspects of SNMPv2 • SNMP Specifications (Table 11.1)

8. Background (cont’d) • SNMPv2 Enhancement • SNMPv2 can support either a highly centralized network management strategy or a distributed one. In the latter case, some system operate in the role of both manager and agent. Agent/intermediate manager/superior manager • The key enhancement to SNMP that are provided in SNMPv2 • Structure of Management Information (SMI) • Manager-to-manager capability • Protocol operations • SMI expansion • The macro used to define object types has been expanded to include several new data types and to enhance the documentation associated with an object. • New convention that has been provided for creating and deleting conceptual rows in the table • SNMPv2 MIB contains basic traffic information about the operation of the SNMPv2 protocol; analogous to the snmp group in MIB-II

9. Background (cont’d) • SNMPv2 Enhancement • Most noticeable change in protocol operations • GetBultRequest PDU : enabling the manager to retrieve large blocks of data efficiently. It is well suited to retrieving multiple rows in a table • InformRequest PDU : enabling one manager to send trap of information to another

10. 11.2 Structure of Management Information • SNMPv2 SMI is nearly a proper superset of the SNMPv1 SMI • SNMPv2 introduces four key concepts of • Object definitions • Conceptual tables • Notification definitions • Information modules

11. SMI (cont’d) • Object definitions • SNMPv2 SMI are used to describe managed objects. • ASN.1 macro OBJECT-TYPE is used to convey the syntax and semantics of all managed objects in a systematic way • SNMPv2 specification the OBJECT-TYPE macro (Fig.11.1). • Some associated definitions (Fig. 11.2) • Same general structure as the OBJECT-TYPE macro defined in RFC 1155 (SNMP SMI) , with refinements in RFC1212 (concise MIB Definitions) • Comparison between the macro defined in the SNMPv2 documents and the macro defined for SNMP in RFCs 1155 and 1212

12. SMI (cont’d) • Data types Data Type SNMPv1 SNMPv2 X X X X X X X X INTEGER Unsigned32 Counter32 Counter64 Guage32 TimeTicks OCTET STRING IpAddress OBJECT IDENTIFIER Opaque X X X X X X X X X X

13. SMI (cont’d) • An example of enumerated integers, taken from ifTestTable in RFC 1573 (Evolution of the Interfaces Group of MIB-II) ifTestResult OBJECT-TYPE SYNTAX INTEGER { none (1) -- no test yet requested success (2) inProgress (3) notSupported (4) unAbleToken (5) -- due to state of system aborted (6) failed (7) } MAX ACCESS read-only STATUS current Description “ “ ::= {ifTestEntry4}

14. SMI (cont’d) • Limited-range gauge for Guage32

15. SMI (cont’d) • UnitsPart • contains a textual definition of the units associated with an object • is useful for any object that represents a measurement in some kind of units, such as time • MAX-ACCESS Clause • not-accessible • accessible-for-notify • read-only • read-create • STATUS Clause • indicating that this definition is current or historic, not including the “optional” or “mandatory” categories defined for SNMPv1 • “obsolete” means that this object should not be implemented, but “deprecated” that implementer wishes to support for backward compatibility with older implementations

16. SMI (cont’d) • SNMPv2 Tables • Table has zero or more rows, and each row contains one or more scalar objects • Form of SNMPv1, SNMPv2 1. A conceptual table has a SYNTAX clause of the form SEQUENCE OF <entry> where <entry> is conceptual row 2. A conceptual row has a SYNTAX clause of the form SEQUENCE {<type1>, ……., <typeN>} where <type> is columnar object form of each <type> is <descriptor><syntax> <descriptor> is name of columnar objects <syntax> is the value of object’s SYNTAX Clause 3. Each columnar object is defined in the usual manner with an OBJECT_TYPE macro

17. SMI (cont’d) • SNMPv2 enhances conventions used in RFC 1212 and in the RMON specification (RFC 1757) to facilitate row creation, deletion, and access. • Two categories of conceptual tables are allowed in SNMPv2 • Tables that prohibit row creation and deletion by a manager: These are controlled completely by the agent • Tables that allow row creation and deletion by a manager : Such a table may be initialized with no rows, with only the manager causing row creation and deletion.

18. SMI (cont’d) • Table Indexing • INDEX Clause defines a base conceptual row • INDEX component of the row definition determines which object value(s) will unambiguously distinguish one row in the table • That is, INDEX objects (or objects) determine a conceptual row instance • optional use of IMPLIED modifier to an object name in SNMPv2 • Given object identifier is y, INDEX objects are i1, i2, …., iN, then the instance identifier for an instance of object y in particular row is y.(i1).(i2)…..(iN)

19. SMI (cont’d) • In the previous slide, each term in parentheses is interpreted as follows:  Integer-valued  String-valued, fixed-length  String-valued, variable length preceded by the IMPLIED keyword  String-valued, variable length not preceded by the IMPLIED keyword  Octet-identifier-valued preceded by the IMPLIED keyword  Octet-identifier-valued not preceded by the IMPLIED keyword  IpAddress-valued - IMPLIED keyword enables a small savings in the instance identifier when the index objects is a variable string

20. SMI (cont’d) • Flowchart for conceptual row creation

21. SMI (cont’d) • Checklist of features of row creation MANDATORY FEATURES 1. It must handle rows larger than one PDU 2. It must allow management station to learn of columns not implemented in agent 3. It must allow management station to learn of columns not accessible in agent 4. It must arbitrate between multiple managers accessing same row 5. It must protect create operations from reordering 6. It must allow protocol entity to detect tooBig before create is executed 7. It must allow read-only and read-create object to coexist in same row VERY IMPORTANT FEATURES USEFUL FEATURES

22. SMI (cont’d) • Checklist of features of row creation Feature Category createAndWait createAndGo 1 Must Yes No 2 Must Yes Yes 3 Must Yes Yes 4 Must Yes Yes 5 Must Yes Yes 6 Must Yes Yes 7 Must Yes Yes 8 Important No Yes 9 Important Yes Yes 10 Important Yes Yes 11 Useful No No 12 Useful Yes No 13 Useful Yes No 14 Useful Yes Yes 15 Useful No No

23. SMI (cont’d) • Notification Definitions • NOTIFICATION-TYPE macro is used to define the information that is sent by an SNMPv2 entity when an exceptional event occurs at the entity. • Example linkUp NOTIFICATION-TYPE OBJECTS {ifIndex, ifAdminStats, ifOperStatus} STATUS current DESCRIPTION “A linkUp trap signifies that the SNMPv2 entity, acting in an agent role, has detected that the ifOperStatus object for one of its communication links transitioned out of the down state.” ::= {snmpTraps4}

24. SMI (cont’d) • example snmpMIB MODULE-IDENTITY LAST-UPDATED “9511090000Z” ORGANIZATION “IETF SNMPv2 Working Group” CONTACT-INFO “ Marshall T. Rose Postal : Dover Beach Consulting, Inc. 420 Whisman Court Mountain View, CA 94043-2186 US Tel : +1 415 968 1052 E-mail : mrose@dbc.mtview.ca.us” DESCRIPTION “The MIB module for SNMPv2 entities.” REVISION “930401000Z” DESCRIPTION “The initial revision of this MIB module was published as RFC 1450.” ::= {snmpModules 1}