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

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

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

5. 5 Major Changes Bulk data transfer  Manager-to-manager message  Enhancements to 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. 6 SMIv1, SMIv2 SMIv1:  SMI (RFC 1155)RFC 1155  Concise MIB (RFC 1212)RFC 1212  Trap-Type (RFC 1215)RFC 1215 SMIv2:  SMIv2 (RFC 2578)RFC 2578  Textual Conventions (RFC 2579)RFC 2579  Conformance Statements (RFC 2580)RFC 2580

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

8. 8 MODULE-IDENTITY

9. 9 MODULE-IDENTITY Example

10. 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. 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. 12 (Example) SYNTAX BITS protocolDirType OBJECT-TYPE SYNTAXBITS { extensible(0), addressRecognitionCapable(1) } MAX-ACCESS read-only STATUS current DESCRIPTION “…” ::= { protocolDirEntry 5 }

13. 13 UnitsPart: UNITS 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 } UnitsPart ::= "UNITS" Text | empty Back to OBJECT-TYPE

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

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

16. 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. 17 NOTIFICATION-TYPE 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 NotificationName ::= OBJECT IDENTIFIER

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

19. 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. 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. 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. 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. 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. 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. 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. 26 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 } Appending a Spare Table

27. 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. 28 SNMPv2: SNMPV1: Also see Page 251 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)

29. 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. 30 Creation of Row: RowStatus

31. 31

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

33. 33 Create-and-Wait: Row Creation

34. 34 Row Deletion