SNMPv2

1. In the Name of the Most High SNMPv2 by Behzad Akbari Fall 2008

2. Overview SNMPv1 was developed as an interim solution to an eventual adoption of OSI. This never came about: OSI was not as widely adopted as originally hoped. SNMPv2, released in 1996, was basically major revisions added to SNMP.

3. SNMPv1 • SNMPv1 Protocol • RFC 1157 – Simple Network Management Protocol • SMIv1 Data Definition Language • Full Standards: • RFC 1155 - Structure of Management Information • RFC 1212 - Concise MIB Definitions • Informational: • RFC 1215 - A Convention for Defining Traps • SMIv1 MIB Modules • Full Standards: • RFC 1213 - Management Information Base II • RFC 1643 - Ethernet-Like Interface Types MIB

4. SNMPv2 • SMIv2 Data Definition Language • Full Standards: • RFC 2578 - Structure of Management Information • RFC 2579 - Textual Conventions • RFC 2580 - Conformance Statements • SMIv2 MIB Modules • Full Standards: • RFC 2819 - Remote Network Monitoring MIB • RFC 3411 - SNMP Framework MIB • RFC 3412 - SNMPv3 MPD MIB • RFC 3413 - SNMP Applications MIBs • RFC 3414 - SNMPv3 USM MIB • RFC 3415 - SNMP VACM MIB • RFC 3418 - SNMP MIB

5. Major Changes • Bulk data transfer • Manager-to-manager message • Enhancementsto SMI: SMIv2 • Module definitions: MODULE-IDENTITY macro (information) • Object definitions: OBJECT-TYPE macro (managed object) • Trap definitions: NOTIFICATION-TYPE macro • Textual conventions (Help define new data types) • Conformance statements (Compatibility to standard) • Row creation and deletion in table • MIB enhancements (added security & snmpv2) • Transport mappings • Security features, originally to be in SNMPv2, moved to SNMPv3 – Hence, SNMPv2, like SNMPv1, uses a community-based administrative framework  RFC 2578 SMIv2

6. SMIv1, SMIv2 • SMIv1: • SMI (RFC 1155) • Concise MIB (RFC 1212) • Trap-Type (RFC 1215) • SMIv2: • SMIv2 (RFC 2578) • Textual Conventions (RFC 2579) • Conformance Statements (RFC 2580)

7. Three Parts of SMIv2 • Module definitions • MODULE-IDENTITY • Object definitions • OBJECT-TYPE • Notification definitions • NOTIFICATION-TYPE

8. MODULE-IDENTITY

9. MODULE-IDENTITY Example

10. OBJECT-TYPE OBJECT-TYPE MACRO ::= BEGIN TYPE NOTATION ::= "SYNTAX" Syntax UnitsPart "MAX-ACCESS" Access "STATUS" Status "DESCRIPTION" Text ReferPart IndexPart DefValPart VALUE NOTATION ::= value(VALUE ObjectName)

11. "SYNTAX" Syntax Syntax ::= -- Must be one of the following: -- a base type (or its refinement), -- a textual convention (or its refinement), or -- a BITS pseudo-type type | "BITS" "{" NamedBits "}“ NamedBits ::= NamedBit | NamedBits "," NamedBit NamedBit ::= identifier "(" number ")“ -- number is nonnegative

12. (Example) SYNTAX BITS protocolDirType OBJECT-TYPE SYNTAX BITS { extensible(0), addressRecognitionCapable(1) } MAX-ACCESS read-only STATUS current DESCRIPTION “…” ::= { protocolDirEntry 5 }

13. UnitsPart: UNITS UnitsPart ::= "UNITS" Text | empty hrDiskStorageCapacity OBJECT-TYPE SYNTAX KBytes UNITS "KBytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The total size for this long-term storage device. If the media is removable and is currently removed, this value should be zero." ::= { hrDiskStorageEntry 4 } Back to OBJECT-TYPE

14. "MAX-ACCESS" Access Access ::= "not-accessible" | "accessible-for-notify" | "read-only" | "read-write" | "read-create" ordered from least to greatest: "not-accessible": indicates an auxiliary object "accessible-for-notify": accessible only via a notification "read-only": read only "read-write": read and write, but create does not. "read-create": read, write and create

15. "STATUS" Status Status ::= "current" | "deprecated" | "obsolete" “current”: the definition is current and valid. “deprecated”: indicates an obsolete definition, it permits new/continued implementation. “obsolete”: the definition is obsolete and should not be implemented.

16. ReferPart ReferPart ::= "REFERENCE" Text | empty ipForwardTable OBJECT-TYPE SYNTAX SEQUENCE OF IpForwardEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "This entity's IP Routing table." REFERENCE "RFC 1213 Section 6.6, The IP Group“ ::= { ipForward 2 }

17. 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(ObjectName) Status ::= "current" | "deprecated" | "obsolete" ReferPart ::= "REFERENCE" Text | empty Text ::= value(IA5String) END NOTIFICATION-TYPE NotificationName ::= OBJECT IDENTIFIER

18. NOTIFICATION-TYPE Example Reference: SNMPv2-MIB (RFC 1907)

19. OBJECT-IDENTITY Macro • The OBJECT-IDENTITY macro is there to define information about an object identifier in the MIB. • Recall that an OBJECT IDENTIFIER defines the administrative identification of a node in the MIB • – For example let’s consider a class of router that is manufactured by InfoTech Services Inc. that is identified by the OBJECT IDENTIFIER isiRouter • isiRouter OBJECT-IDENTITY • STATUS current • DESCRIPTION "An 8-slot IP router in the IP router • family." • REFERENCE "ISI Memorandum No. ISI-R123 dated • January. 20, 1997" • ::= {private.enterprises.isi 1} (a) Example of OBJECT-IDENTITY Macro

20. OBJECT-TYPE • OBJECT-TYPE details the description needed for implementation of the managed object. It defines the type of a managed object. routerIsi123 OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "An 8-slot IP router that can switch up to100 million packets per second. ::= {isiRouter 1} (b) Example of OBJECT-TYPE Macro

21. Table Aggregation • SNMPv2 also defines a very powerful concept known as aggregate objects that support compound tables. • This allows, for example, to define parameters associated with interface cards in a router. • 3 types of table aggregation is supported: – Augmentation of a table (dependent table) adds additional columns to an existing table (base table) – Dense table enables addition of more rows to base table – Sparse table supplements less rows to a base table

22. Table Aggregation (…) • Can happen when all of the following are true: • – Number of rows is not affected by the addition • – Rows match one-to-one • – The INDEX of the first table can be used for second one as well. • Table 1: base table • Table 2: augmented table

23. Augmentation of Tables: Example • For example the parameters of the interface of the router, RouterIsi123, adds proprietary information to the standard • ipAddrTable. • This new table, ipAugAddrTable has the same number of rows as ipAddrTable and adds information that defines the board and port number associated with the ipAdEntAddr Figure 6.13 Example of Augmentation of Tables

24. Dense Tables • In this case, the number of rows of an augmented table is more than that of the base table. The INDEX for the combined table is the combination of the 2 INDEX values of the tables.

25. Sparse Tables • In this case the number of rows of an augmented table is less than that of the base table. The INDEX for the combined table is the same of the base table.

26. Appending a Spare Table hrDeviceTable OBJECT-TYPE SYNTAX SEQUENCE OF HrDeviceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table of devices…" ::= { hrDevice 2 } hrDeviceEntry OBJECT-TYPE SYNTAX HrDeviceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A (conceptual) entry for one device contained by the host. …" INDEX { hrDeviceIndex } ::= { hrDeviceTable 1 } hrDiskStorageTable OBJECT-TYPE SYNTAX SEQUENCE OF HrDiskStorageEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table of long-term storage devices contained by the host..." ::= { hrDevice 6 } hrDiskStorageEntry OBJECT-TYPE SYNTAX HrDiskStorageEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A (conceptual) entry for one long-term storage devices contained by the host..." INDEX { hrDeviceIndex } ::= { hrDiskStorageTable 1 }

27. Textual Convention • Enables defining new data types • Makes semantics of data types consistent and human readable • Creates new data types using existing ones and applies restrictions to them • An important textual convention in SNMPv2, RowStatus creates and deletes rows

28. SNMPV1: DisplayString ::= OCTET STRING -- This data type is used to model textual information taken -- from the NVT ASCII character set. By convention, objects -- with this syntax are declared as having -- SIZE (0..255) • SNMPv2: Also see Page 251

29. InterfaceIndex ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A unique value, greater than zero, for each interface or interface sub-layer in the managed system. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub-layer must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization." SYNTAX Integer32 (1..2147483647)

30. Creation of Row: RowStatus

32. Create-and-Go Row Creation Manager Agent Managed Process Process Entity SetRequest ( status.3 = 4, index.3 = 3, Create Instance data.3 = DefData ) Response ( Instance Created status.3 = 1, index.3 = 3, data.3 = DefData )

33. Create-and-Wait: Row Creation

34. Row Deletion