1 SNMPv2 by Behzad Akbari Fall 2011 In the Name of the Most High These slides are based in parts upon slides of Prof. Dssouli (Concordia university )

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

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

 Bulk data transfer  Request and receive bulk data using the get-bulk message  Manager-to-manager message  Enhances interoperability and allows for managing large distributed networks  Enhancements to SMI: SMIv2  Module definitions: MODULE-IDENTITY macro  Object definitions: OBJECT-TYPE macro (same as before)  Trap definitions: NOTIFICATION-TYPE macro  Textual conventions: define new data types  Conformance statements  Help customers compare features of various products  Keeps vendors open to their product’s compatibility with SNMP Major Changes

 Row creation and deletion in table  A table can also be expanded by augmenting another table  MIB enhancements  Two new subgroups: security and snmpV2  Transport mappings  UDP remains the preferred transport protocol; however, other protocols can also be used with SNMPv2  Security features, originally to be in SNMPv2 moved to SNMPv3  SNMPv2 is community-based administrative framework Major Changes SNMPv2 mgmt (2) directory (1) experimental (3) private (4) Internet { } security (5) snmpv2 (6) SNMPv2 Internet Group

SNMPv2 System Architecture

 inform-request  manager-to-manager message  The receiving manager responds with a response message  Enhances interoperability  get-bulk-request  transfer of large data, e.g. retrieval of table data  SNMPv2-trap  Similar to trap messages in SNMPv1 Additional Messages

SMIv2- Modules Definitions  Defines and describe semantics of an information module (info. related to network management)  added to provide administrative information regarding the informational module and the revision history  MODULE-IDENTITY macro defines the module definitions

SMIv2- Object Definitions r OBJECT IDENTIFIER, OBJECT-IDENTITY, OBJECT-TYPE m OBJECT IDENTIFIER defines the administrative identification of a node in the MIB m OBJECT-IDENTITY macro (defines info. about OID) assigns an object identifier to a class of managed objects in the MIB (e.g., defining a class of routers!) The object itself is not managed m OBJECT-TYPE macro defines the type of a managed object (e.g., a specific router type) Focuses on the details of implementation m NOTE: OBJECT-IDENTITY is high level description OBJECT-TYPE details description needed for implementation

11 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)

12 "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

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

14 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

15 "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

16 "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.

17 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 }

Object Definitions, example NOTE: A specific instance of routerIsi123 could be identified by its IP address

Table Definition  Static Tables o Tables completely controlled by the agent. Access is read-only, and read- write o These are useful when the number of rows corresponds to a fixed attribute (e.g., # physical interfaces) or a quantity controlled only by agent  Dynamic Table o Allows row creation/deletion by a manager o Access includes also read, write and create privileges o A table can be initialized with no rows and expanded as needed  SNMPv2: Augmentation of a table (dependent table) o Adds additional columns to an existing table (base table) o Number of rows is not affected o INDEX of the second table is the same as the first table o One to one correspondence between rows of two tables

Augmentation of Tables T1.E1.C1.1 table1 (T1) table1Entry (E1) T1.E1.C2.1T1.E1.C3.1 T1.E1.C1.2 T1.E1.C2.2T1.E1.C3.2 T1.E1.C1.3 T1.E1.C2.3T1.E1.C3.3 T1.E1.C1.4 T1.E1.C2.4T.E1.C3.4 table 2 (T2) table2Entry (E2) T2.E2.C4.1T2.E2.C5.1 T2.E2.C4.2T2.E2.C5.2 T2.E2.C4.3T2.E2.C5.3 T2.E2.C4.4T2.E2.C5.4 Index: First columnar object in Table 1 Conceptual rows: 1. T1.E1.C T1.E1.C T1.E1.C T1.E1.C1.4 Table 1 Table 2 Base tableAugmented table Example Columnar object:T2.E2.C4 Index: T1.E1.C1.2 Value: T2.E2.C4.2

Augmentation of Tables Example: a vendor can easily specify vendor-specific objects as extensions to standard MIB table. It should be easier for applications to access these objects than if they were defined as new, separate table --Conceptual row extension A clause used to increase the number of columns in a table w/out rewriting the table definition  The resulting table is therefore treated the same way as if it was defined in a single table definition

Row Creation  A new feature in SMIv2  2 methods  Create a row and make it active (or available)  Create a row and make it available at a later time   definition of the status of a row Used by manager for row creation/deletion Used by agent to send responses to a manager

Row Creation 2 states for RowStatus: createAndGo, createAndWait Row to be created/deleted entry1 status.1 table1 index.1data.1 status.2 status.3 index.2 index.3 data.2 data.3

Create and Go  Manager initiates a SetRequest-PDU to create a new row  status = 4, i.e., create and go  Agent interacts with the management entity and successfully create an instance; subsequently a response is transmitted to the manager  status = 1, indicates that the row is active 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

Create and Wait Manager Process Agent Process SetRequest ( status.3 = 5, index.3 = 3 ) Create and wait, no default data specified Response ( status.3 = 3, index.3 = 3 ) Agent responds with “notReady” (no default value) GetRequest ( data.3 ) Get the data for the row Response ( data.3 = noSuchInstance) Data value is missing SetRequest ( data.3 = DefData ) Value of data is sent Response ( status.3 = 2 data.3 = DefData ) Agent responds with notInServcie SetRequest ( status.3 = 1 ) Manager requests to activate the row Response ( status.3 = 1 ) Row activated

Row Deletion SetRequest ( status.3 = 6 ) Response ( status.3 = 6 ) Manager Process Agent Process Managed Entity Delete Instance Instance Deleted

Textual Conventions r Enables defining new data types r Makes semantics of data types consistent and human readable r Creates new data types using existing ones and applies restrictions to them r An important textual convention in SNMPv2, RowStatus creates and deletes rows SNMPv1 SNMPv2 A string of up to 255 characters (refer to table 6.2 for more rules)

Textual Conventions-Macro TEXTUAL-CONVENTION MACRO ::= BEGIN TYPE NOTATION ::= DisplayPart "STATUS" Status "DESCRIPTION" Text ReferPart "SYNTAX" Syntax VALUE NOTATION ::= value(VALUE Syntax) DisplayPart ::= "DISPLAY-HINT" Text | empty Status ::= "current" | "deprecated" | "obsolete“ ReferPart ::= "REFERENCE" Text | empty ……………………….. END Example: Hundredths ::= TEXTUAL-CONVENTION DISPLAY-HINT “d-2”... SYNTAX INTEGER ( ) suggests that a Hundredths value of 1234 be rendered as "12.34"

Textual Conventions- example RowStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The RowStatus textual convention is used to manage the …” SYNTAX INTEGER { -- the following two values are states: -- these values may be read or written active(1), notInService(2), -- the following value is a state: -- this value may be read, but not written notReady(3), -- the following three values are -- actions: these values may be written, -- but are never read createAndGo(4), createAndWait(5), destroy(6) }

SNMPv2 Protocol  Overall, 8 messages with almost common message format to improve the efficiency and performance  Significant improvement is that trap message has the same format SNMPv2 PDU PDU Type RequestID Error Status Error Index VarBind 1 name VarBind 1 value... VarBind n name VarBind n value Indicate the type of PDU (e.g., Request-PDU, etc) Indicate the status of the error (e.g., noError, tooBig, etc.) identifies the first variable binding in the variable-binding list that caused the error NOTE: SNMPv1 operations (e.g., GET-REQUEST ) are atomic: either all values are returned or none! In SNMPv2: a binding list (with corresponding values) is prepared even if one variable cannot be returned  an (error-status), (error-index) are returned in the case of anomaly.

SNMPv2 Protocol Error index is set to “0” if there is no error; otherwise, it identifies the first variable binding in the variable binding list that caused the error

SNMPv2 Protocol  GetBulkRequest enables the retrieval of data in bulk  Uses the same selection principle as GetNexRequest (i.e., next object instance)  Retrieval of multiple rows of data from table (constrained by the max. message size)  Error status field replaced by Non-repeaters  Non-repeaters indicates the number of non repetitive (scalar) field values requested  Error index field replaced by Max repetitions  Max repetitions designates the maximum number of table rows requested to be returned in the response message  NOTE 1: value depends on the size of the SNMP message and buffer size in implementation  NOTE 2: no one to one relationship between the VarBindList of request and response messages SNMPv2 GetBulkRequest PDU PDU Type RequestID Non- Repeaters Max Repetitions VarBind 1 name VarBind 1 value... VarBind n name VarBind n value

GetBulkRequest-PDU Operation TZAB 1.1 E T.E.1.1T.E.2.1T.E.3.1 T.E.1.2T.E.2.2T.E.3.2 E T Z A B T.E.1.3T.E.2.3T.E.3.3 T.E.1.4T.E.2.4T.E.3.4

GetBulkRequest-PDU Operation GetRequest ( A,B ) GetNextRequest (T.E.1,T.E.2,T.E.3) GetResponse (T.E.1.1,T.E.2.1,T.E.3.1) GetNextRequest (T.E.1.1,T.E.2.1,T.E.3.1) GetResponse (T.E.1.2,T.E.2.2,T.E.3.2) GetResponse (T.E.1.3,T.E.2.3,T.E.3.3) GetNextRequest (T.E.1.3,T.E.2.3,T.E.3.3) GetResponse (T.E.1.4,T.E.2.4,T.E.3.4) GetResponse (T.E.2.1,T.E.3.1,Z) Manager Process Agent Process GetResponse (A,B) GetNextRequest (T.E.1.4,T.E.2.4,T.E.3.4) GetNextRequest (T.E.1.2,T.E.2.2,T.E.3.2)

GetBulkRequest-PDU Operation T.E.1.1T.E.2.1T.E.3.1 T.E.1.2T.E.2.2T.E.3.2 E T Z A B T.E.1.3T.E.2.3T.E.3.3 T.E.1.4T.E.2.4T.E.3.4 GetBulkRequest ( 2,3, A,B,T.E.1, T.E.2, T.E.3 ) Response ( A, B, T.E.1.1, T.E.2.1, T.E.3.1 T.E.1.2, T.E.2.2, T.E.3.2 T.E.1.3, T.E.2.3, T.E.3.3 ) GetBulkRequest ( 0,3, T.E.1.3, T.E.2.3, T.E.3.3 ) Response ( T.E.1.4, T.E.2.4, T.E.3.4, Z, "endOfMibView") Manager Process Agent Process 2 non repetitive objects (A, B) 3 repetitive instances Of the columnar object T.E.1, T.E.2, T.E.3 3 more rows Z is next in the lexicographic order

GetBulkRequest-PDU Operation

SNMPv2 Trap PDU  Addition of NOTIFICATION-TYPE macro  Positions 1 and 2 in VarBindList are sysUpTime and snmpTrapOID  Inform-Request behaves as trap in that the message goes from one manager to another unsolicited o The receiving manager sends response to the sending manager PDU Type RequestID Error Status Error Index VarBind1 sysUpTime VarBind1 value VarBind2 snmpTrapOID VarBind 2 value...

38 Conformance Statements for SMIv2 (RFC 2580)

39 MIB MODULE  IMPORTS  EXPORTS  MODULE-IDENTITY  TEXTUAL-CONVENTION  OBJECT IDENTIFIER  Application Data Types  OBJECT-TYPE  NOTIFICATION-TYPE  OBJECT-GROUP  NOTIFICATION-GROUP  MODULE-COMPLIANCE I E MI TCs OIs OTs NTs OGs NGs MCs

40 MC OT OG OT OG NT NG NT NG OI I E data types TC OG NG MC MI

41 Four Macros in SNMPv2-CONF OBJECT-GROUP macro NOTIFICATION-GROUP macro MODULE-COMPLIANCE macro AGENT-CAPABILITIES macro

42 Conformance: OBJECT-GROUP Conformance defined by OBJECT-GROUP macro NOTIFICATION-GROUP macro OBJECT-GROUP Compiled during implementation, not at run time OBJECTS clause names each object Every object belongs to an OBJECT-GROUP Access defined by MAX-ACCESS, the maximum access privilege for the object

43 OBJECT-GROUP OBJECT-GROUP MACRO ::= BEGIN TYPE NOTATION ::= ObjectsPart "STATUS" Status "DESCRIPTION" Text ReferPart VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER) ObjectsPart ::= "OBJECTS" "{" Objects "}" Objects ::= Object | Objects "," Object Object ::= value(ObjectName) Status ::= "current" | "deprecated" | "obsolete" ReferPart ::= "REFERENCE" Text | empty Text ::= value(IA5String) END

44 OBJECT-GROUP Example hrSWRunGroup OBJECT-GROUP OBJECTS { hrSWOSIndex, hrSWRunIndex, hrSWRunName, hrSWRunID, hrSWRunPath, hrSWRunParameters, hrSWRunType, hrSWRunStatus } STATUS current DESCRIPTION "The Host Resources Running Software Group." ::= { hrMIBGroups 4 }

45 Conformance: NOTIFICATION-GROUP NOTIFICATION-GROUP Contains trap entities defined in SMIv1 NOTIFICATIONS clause identifies the notifications in the group NOTIFICATIONS-GROUP macro compiled during implementation, not at run time

46 NOTIFICATION-GROUP NOTIFICATION-GROUP MACRO ::= BEGIN TYPE NOTATION ::= NotificationsPart "STATUS" Status "DESCRIPTION" Text ReferPart VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER) NotificationsPart ::= "NOTIFICATIONS" "{" Notifications "}" Notifications ::= Notification | Notifications "," Notification Notification ::= value(NotificationName) Status ::= "current" | "deprecated" | "obsolete" ReferPart ::= "REFERENCE" Text | empty Text ::= value(IA5String) END

47 NOTIFICATION-GROUP Example linkUpDownNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { linkUp, linkDown } STATUS current DESCRIPTION "The notifications which indicate specific changes in the value of ifOperStatus." ::= { ifGroups 14 }

48 Compliance Compliance has two classes of groups MANDATORY-GROUPS... Required GROUP …Optional

49 MODULE-COMPLIANCE MODULE-COMPLIANCE MACRO ::= BEGIN TYPE NOTATION ::= "STATUS" Status "DESCRIPTION" Text ReferPart ModulePart VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER)

50 ModulePart ModulePart ::= Modules Modules ::= Module | Modules Module Module ::= "MODULE" ModuleName MandatoryPart CompliancePart ModuleName ::= identifier ModuleIdentifier | empty ModuleIdentifier ::= value(OBJECT IDENTIFIER) | empty MandatoryPart ::= "MANDATORY-GROUPS" "{" Groups "}“ | empty Groups ::= Group | Groups "," Group Group ::= value(OBJECT IDENTIFIER)

51 CompliancePart (1/2) CompliancePart ::= Compliances | empty Compliances ::= Compliance | Compliances Compliance Compliance ::= ComplianceGroup | Object ComplianceGroup ::= "GROUP" value(OBJECT IDENTIFIER) "DESCRIPTION" Text Object ::= "OBJECT" value(ObjectName) SyntaxPart WriteSyntaxPart AccessPart "DESCRIPTION" Text

52 CompliancePart (2/2) SyntaxPart ::= "SYNTAX" Syntax | empty -- must be a refinement for object's SYNTAX clause WriteSyntaxPart ::= "WRITE-SYNTAX" Syntax | empty Syntax ::= type | "BITS" "{" NamedBits "}" NamedBits ::= NamedBit | NamedBits "," NamedBit NamedBit ::= identifier "(" number ")" AccessPart ::= "MIN-ACCESS" Access | empty Access ::= "not-accessible" | "accessible-for-notify" | "read-only" | "read-write" | "read-create"

53 hrMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The requirements for conformance to the Host Resources MIB." MODULE -- this module MANDATORY-GROUPS { hrSystemGroup, hrStorageGroup, hrDeviceGroup } OBJECT hrSystemDate MIN-ACCESS read-only DESCRIPTION "Write access is not required.“ GROUP hrSWRunGroup DESCRIPTION "The Running Software Group. Implementation of this group is mandatory only when the hrSWRunPerfGroup is implemented." … ::= { hrMIBCompliances 1 } MODULE-COMPLIANCE Example

54 OBJECT ifAdminStatus SYNTAX INTEGER { up(1), down(2) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, nor is support for the value testing(3)."

55 OBJECT-GROUP

56 Agent Capabilities AGENT-CAPABILITIES macro SUPPORTS modules and includes groups VARIATION identifies additional features

57 AGENT-CAPABILITIES

58 SNMPv2 Internet Group

59 NOTIFICATION-TYPE

60 Object Types for SNMPv2 Traps

61 Inform-Request Inform-Request behaves as trap in that the message goes from one manager to another unsolicited The receiving manager sends response to the sending manager

SNMPv2- Decentralized management MIB SNMPv2 agent MIB SNMPv2 agent MIB SNMPv2 agent MIB SNMPv2 Manager/agent MIB SNMPv2 Manager/agent MIB Management Applications SNMPv2 manager Management server Element manager Agent SNMPv2 Configuration

Compatibility with SNMPv1  SNMPv2 MIB is not backward compatible with SNMPv1  Compatibility with SNMPv1  2 evolution paths: o Bilingual Manager o Proxy Server  Bilingual Manager expensive in resource and operation SNMPv1 Agents Bilingual Manager SNMPv1 Interpreter SNMPv2 Interpreter Agent Profile SNMPv2 Agents SNMP Bilingual Manager Both interpreters are required!

SNMP Proxy Server SNMPv1 Agents SNMPv2 Manager Proxy Server SNMPv2 Agents Pass-Through SNMPv2 ManagerSNMPv1 Agent GetNextRequest GetRequest Pass-Through SetRequest Set: 1. non-repeaters = 0 2. max-repetitions = 0 GetBulkRequest Pass-Through Exception: For 'tooBig' error, contents of variable-bindings field removed. Response Prepend VarBind: 1. sysUpTime.0 2. snmpTrapOID.0 SNMPv2-Trap GetRequest GetResponse GetNextRequest SetRequest GetNextRequest Trap SNMP v2-v1 Proxy Server

65 SNMPv2 MIB