Chapter 6 SNMPv2 6-1 Network Management: Principles and Practice © Mani Subramanian 2000 6-1

SNMPv1 vs. SNMPv2 Notes SNMPv2 released in 1996. Basic components are the same in SNMPv1 & SNMPv2 (agent and manager). Significant differences between SNMPv1 & SNMPv2. Not backward compatible with SNMPv1. RFC1908 → Coexistence between Version 1, and Version 2 of SNMP. RFC 3584 → Coexistence between Version 1, Version 2, and Version 3 of SNMP. Notes Security features, originally to be in SNMPv2, but moved to SNMPv3 SNMPv2, like SNMPv1, is community-based administrative framework → SNMPv2C [RFC 1901] (01/1996) Framework details: → RFC 2578-2580 [STD 58] (04/1999) and RFC 3416-3418 [STD 62] (12/2002) → Obsoletes RFC 1902-1907 Network Management: Principles and Practice © Mani Subramanian 2000 6-2

SNMPv1 & SNMPv2 Documents Chapter 4 SNMPv1 & SNMPv2 Documents Network Management: Principles and Practice © Mani Subramanian 2000 6-3

Major Changes Bulk data transfer: [RFC 3416/STD 62] Speeds up get-next-request process (e.g., retrieve data from tables). Manager-to-manager message: [RFC 3416/STD 62] Interoperability of NMSs. Enhancements to SMI: SMIv2 [RFC 2578/STD 58] Module definitions: MODULE-IDENTITY macro Object definitions: OBJECT-TYPE macro Trap definitions: NOTIFICATION-TYPE macro SMI (SNMPv1) → STD 16 [RFC 1155, RFC 1212, and RFC 1215] Textual conventions: [RFC 2579/STD 58] Help define new data types. Make semantics consistent and clear. Conformance statements: [RFC 2580/STD 58] Check compatibility with an SNMP version. Compliance defines minimum set of capabilities. Vendors can offer additional capabilities as options. Network Management: Principles and Practice © Mani Subramanian 2000 6-4

Major Changes (Cont.) Row creation and deletion in tables: [RFC 2579/STD 58] RowStatus columnar object added. Conceptual rows can be added or deleted to/from a table. Table Expansion: [RFC 2578/STD 58] Tables can be expanded → adding columnar objects to existing tables. MIB enhancements: [RFC 3418/STD 62] Two new subgroups added to the Internet node: security & snmpV2. Significant changes to the System group and to the SNMP group of version 1. System group → under mib-2 node. SNMP(v2) group → some from SNMP group + others from groups under snmpV2 node. Transport mappings: [RFC 3417/STD 62] Communication model changes. Other transport protocols can be used with SNMPv2 (besides UDP). Network Management: Principles and Practice © Mani Subramanian 2000 6-5

SNMPv2 Internet Group Notes Additional SNMPv2 group added Security group is a placeholder (not used) Network Management: Principles and Practice © Mani Subramanian 2000 6-6

SNMPv2 MIB - Internet Group - Notes Objects added to System group Extensive modification of the SNMP group Entities under the new SNMPv2 group added Network Management: Principles and Practice © Mani Subramanian 2000 6-7

SNMPv2 RFCs RFC 1901: Introduction to Community-based SNMPv2 RFC 2578: Structure of Management Information Version 2 (SMIv2) RFC 2579: Textual Conventions for SMIv2 RFC 2580: Conformance Statements for SMIv2 RFC 3416: Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP) RFC 3417: Transport Mappings for the Simple Network Management Protocol (SNMP) RFC 3418: Management Information Base (MIB) for the Simple RFC 1908: Coexistence between Version 1 and Version 2 of SNMP RFC 1909: An Administrative Infrastructure for SNMPv2 6-8

SNMPv2 NM Architecture Notes Eight messages (Seven + one Report message). Two managers can communicate with each other at peer level. Report message, defined but not specified (left to implementers). It is not currently used. Network Management: Principles and Practice © Mani Subramanian 2000 6-9

SNMPv2 New Messages Notes inform-request manager-to-manager message get-bulk-request transfer of large data report not used Notes RFC 3416/STD 62 PDUs ::= CHOICE { get-request GetRequest-PDU, get-next-request GetNextRequest-PDU, get-bulk-request GetBulkRequest-PDU, response Response-PDU, set-request SetRequest-PDU, inform-request InformRequest-PDU, snmpV2-trap SNMPv2-Trap-PDU, report Report-PDU } -- PDUs GetRequest-PDU ::= [0] IMPLICIT PDU GetNextRequest-PDU ::= [1] IMPLICIT PDU Response-PDU ::= [2] IMPLICIT PDU SetRequest-PDU ::= [3] IMPLICIT PDU -- [4] is obsolete GetBulkRequest-PDU ::= [5] IMPLICIT BulkPDU InformRequest-PDU ::= [6] IMPLICIT PDU SNMPv2-Trap-PDU ::= [7] IMPLICIT PDU -- Usage and precise semantics of Report-PDU are not defined -- in this document. Any SNMP administrative framework making -- use of this PDU must define its usage and semantics. Report-PDU ::= [8] IMPLICIT PDU Network Management: Principles and Practice © Mani Subramanian 2000 6-10

SMIv2 - Enhancements to SMI [RFC 2578/STD 58] Three parts: Module definitions: Semantics of an information module MODULE-IDENTITY macro Object definitions: Describe managed objects (syntax and semantics) OBJECT-TYPE macro Notification definitions: Describe unsolicited transmissions of management information (syntax and semantics) NOTIFICATION-TYPE macro Notes Module is a group of related assignments Network Management: Principles and Practice © Mani Subramanian 2000 6-11

SMIv2 – Information Modules [RFC 2578/STD 58] Three kinds of information modules: MIB Modules: Contain definitions of inter-related managed objects Make use of OBJECT-TYPE and NOTIFICATION-TYPE macros RFC 2579/STD 58 formalizes the textual conventions used to describe MIB modules TEXTUAL-CONVENTION macro snmpModules object identifier Compliance statements for MIB Modules: Make use of MODULE-COMPLIANCE and OBJECT-GROUP macros RFC 2580/STD 58 snmpMIBConformance object identifier Capability statements for agent implementations: Make use of AGENT-CAPABILITIES macro SMIv1 macros must not be used in SMIv2 information modules. Network Management: Principles and Practice © Mani Subramanian 2000 6-12

MODULE-IDENTITY Macro [RFC 2578/STD 58] MODULE-IDENTITY used to concisely convey the semantics of an information module. Provides administrative information such as contact and revision history for each information module. Must appear exactly once in every information module. Example: [RFC3418/STD62] SNMPv2-MIB DEFINITIONS ::= BEGIN … snmpMIB MODULE-IDENTITY ::= { snmpModules 1 } END Notes The expansion of the MODULE-IDENTITY macro is something which conceptually happens during implementation and not during run-time. 6-13

MODULE-IDENTITY Macro (cont.) Network Management: Principles and Practice © Mani Subramanian 2000 6-14

(Example from RFC 3418/STD 62) MIB Module (Example from RFC 3418/STD 62) Network Management: Principles and Practice © Mani Subramanian 2000 6-15

OBJECT Definitions Notes [RFC 2578/STD 58] OBJECT IDENTIFIER defines the administrative identification of a node in the MIB. OBJECT-IDENTITY macro Defines information about an OBJECT IDENTIFIER assignment. Assigns an object identifier value to the object node in the MIB. OBJECT-TYPE macro: Defines the type of a managed object (both syntax and semantics). Describes a new type (not instance) of object. Notes Network Management: Principles and Practice © Mani Subramanian 2000 6-16

OBJECT-IDENTITY Macro OBJECT-IDENTITY macro defines information about an OBJECT IDENTIFIER assignment. Example [RFC 2578/STD 58]: zeroDotZero OBJECT-IDENTITY STATUS current DESCRIPTION "A value used for null identifiers." ::= { 0 0 } Network Management: Principles and Practice © Mani Subramanian 2000 6-17

OBJECT-TYPE Macro OBJECT-TYPE macro defines the type of a managed object. STATUS: mandatory replaced with current optional is not used deprecated is added → objects required to be implemented in current version, but may not exist in future versions of SNMP (for backward compatibility) 6-18

OBJECT-IDENTITY / OBJECT-TYPE OBJECT-IDENTITY is a high level description. OBJECT-TYPE details description needed for implementation. Network Management: Principles and Practice © Mani Subramanian 2000 6-19

Table Expansion [RFC 2578/STD 58] Augmentation of a table (augmented table) adds additional columns to an existing table (base table). If there is a one-to-one correspondence between the conceptual rows of this table and an existing table, then the AUGMENTS clause should be used. Sparse dependent table supplements less rows to a base table. If there is a sparse relationship between the conceptual rows of this table and an existing table, then an INDEX clause should be used which is identical to that in the existing table. Dense dependent table enables addition of more rows to If no existing objects have the required syntax and semantics, then auxiliary objects should be defined within the conceptual row for the new table, and those objects should be used within the INDEX clause for the conceptual row. Network Management: Principles and Practice © Mani Subramanian 2000 6-20

Augmentation of Tables Network Management: Principles and Practice © Mani Subramanian 2000 6-21

Augmentation of Tables: Example Network Management: Principles and Practice © Mani Subramanian 2000 6-22

Addition of a Sparse Table to Base Table T1.E1.C1.1 table1 (T1) table1Entry (E1) T1.E1.C2.1 T1.E1.C3.1 T1.E1.C1.2 T1.E1.C2.2 T1.E1.C3.2 T1.E1.C1.3 T1.E1.C2.3 T1.E1.C3.3 T1.E1.C1.4 T1.E1.C2.4 T.E1.C3.4 table 2 (T2) table2Entry (E2) T2.E2.C4.1 T2.E2.C5.1 T2.E2.C4.2 T2.E2.C5.2 Figure 6.16 Addition of a Sparse Table to Base Table Index: First columnar object in Table 1 Conceptual rows: 1. T1.E1.C1.1 2. T1.E1.C1.2 3. T1.E1.C1.3 4. T1.E1.C1.4 Table 1 Table 2 Network Management: Principles and Practice © Mani Subramanian 2000 6-23

Augmentation of Tables: Example - Sparse Table - Network Management: Principles and Practice © Mani Subramanian 2000 6-24

Combining Indexing of Tables (Dense Table) T1.E1.C1.1 table1 (T1) table1Entry (E1) T1.E1.C2.1 T1.E1.C3.1 T1.E1.C1.2 T1.E1.C2.2 T1.E1.C3.2 table 2 (T2) table2Entry (E2) T2.E2.C4.1 T2.E2.C5.1 T2.E2.C4.2 T2.E2.C5.2 T2.E2.C4.3 T2.E2.C5.3 T2.E2.C4.4 T2.E2.C5.4 Figure 6.14 Combined Indexing of Tables Index: First columnar objects in Table 1 and 2 Conceptual rows: 1. T1.E1.C1.1, T2.E2.C4.1 2. T1.E1.C1.1, T2.E2.C4.2 3. T1.E1.C1.1, T2.E2.C4.3 4. T1.E1.C1.1, T2.E2.C4.4 Table 1 Table 2 5. T1.E1.C1.2, T2.E2.C4.1 8. T1.E1.C1.2, T2.E2.C4.4 ………………………… Network Management: Principles and Practice © Mani Subramanian 2000 6-25

Augmentation of Tables: Example - Dense Table- Network Management: Principles and Practice © Mani Subramanian 2000 6-26

Textual Convention Notes [RFC 2579/STD 58] 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. Notes SNMPv1 [RFC1213/STD17]: SNMPv2 [RFC 2579/STD 58]: Network Management: Principles and Practice © Mani Subramanian 2000 6-27

TEXTUAL-CONVENTION Macro [RFC 2579/STD 58] 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 TEXTUAL-CONVENTION Macro [RFC 2579 - Textual Conventions for SMIv2, April 1999] 6-28

DISPLAY-HINT Clause [RFC 2579/STD 58] The DISPLAY-HINT clause may be present if and only if the syntax has an underlying primitive type of INTEGER or OCTET STRING. Syntax has an underlying primitive type of INTEGER, the hint consists of two parts. Part 1: A single character suggesting a display format, either: 'x' for hexadecimal, 'd' for decimal, 'o' for octal, 'b' for binary. Part 2: Can only be present with ‘d’ (optional). If present, uses “-” followed by a decimal number, i.e., implied decimal point when rendering the value. Example: Hundredths ::= TEXTUAL-CONVENTION DISPLAY-HINT “d-2” ... SYNTAX INTEGER (0..10000) -- suggests that a hundredths value of 1234 be rendered as "12.34" 6-29

Examples from RFC 2579/STD 58 PhysAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT “1x:” STATUS current DESCRIPTION “Represents media- or physical-level addresses.” SYNTAX OCTET STRING TruthValue ::= TEXTUAL-CONVENTION DESCRIPTION “Represents a boolean value.” SYNTAX INTEGER { true(1), false(2) } DateAndTime ::= TEXTUAL-CONVENTION DISPLAY-HINT “2d-1d-1d,1d:1d:1d.1d,1a1d:1d” DESCRIPTION “A date-time specification. … For example: 1992-5-26,13:30:15.0,-4:0 …” SYNTAX OCTET STRING (SIZE (8 | 11)) See Table 6.3 for SMIv2 Textual Conventions for Initial Data Types 6-30

Examples from RFC 2579/STD 58 SYNTAX INTEGER { 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) } See Table 6.3 for SMIv2 Textual Conventions for Initial Data Types 6-31

Creation/Deletion of Rows: RowStatus [RFC 2579/STD 58] Notes Two methods: Create a row and make it active (createAndGo) → immediately available Create a row and make it available at a later time. (createAndWait) Status: A new column is added to the conceptual table. SYNTAX of Status is RowStatus. Value of RowStatus is Enumerated INTEGER. Manager uses states 1, 2, 4, 5 & 6 to create/delete rows on the agent. Agent uses states 1, 2 & 3 to send responses. Network Management: Principles and Practice © Mani Subramanian 2000 6-32

Row Creation and Deletion Notes Network Management: Principles and Practice © Mani Subramanian 2000 6-33

Status Columnar Object [RFC 2578/STD 58] MAX-ACCESS clause extended to include “read-create” for status objects. → read, write, and create privileges. If any columnar object in a conceptual row has “read-create” as its maximal level of access → No other columnar object of the same conceptual row may have a maximal access of “read-write”. Example: If status columnar object is present: row can have a max access of read-write. Notes Usage example in section 7.11. of RFC 2578. Network Management: Principles and Practice © Mani Subramanian 2000 6-34

INDEX clause [RFC 2578/STD 58] Objects which are both specified in the INDEX clause of a conceptual row and also columnar objects of the same conceptual row are termed auxiliary objects. The MAX-ACCESS clause for auxiliary objects is "not-accessible", except in the following circumstances: within a MIB module originally written to conform to SMIv1, and later converted to conform to SMIv2; or a conceptual row must contain at least one columnar object which is not an auxiliary object. In the event that all of a conceptual row's columnar objects are also specified in its INDEX clause, then one of them must be accessible, i.e., have a MAX-ACCESS clause of "read-only". (Note that this situation does not arise for a conceptual row allowing create access, since such a row will have a status column which will not be an auxiliary object.) Note that objects specified in a conceptual row's INDEX clause need not be columnar objects of that conceptual row. In this situation, the DESCRIPTION clause of the conceptual row must include a textual explanation of how the objects which are included in the INDEX clause but not columnar objects of that conceptual row, are used in uniquely identifying instances of the conceptual row's columnar objects. 6-35

States for Row Creation and Deletion [RFC 2579/STD 58] See RFC 2579 for more details on references 1-8. Network Management: Principles and Practice © Mani Subramanian 2000 6-36

Create-and-Go Row Creation Network Management: Principles and Practice © Mani Subramanian 2000 6-37

Create-and-Wait: Row Creation Network Management: Principles and Practice © Mani Subramanian 2000 6-38

Row Deletion 6-39 Network Management: Principles and Practice © Mani Subramanian 2000 6-39

Conformance Statements [RFC 2580/STD 58] A product is in compliance with a standard if it meets the minimum set of features in its implementation. Module compliance are the minimum requirements for SNMPv2 compliance (i.e., minimum MIB modules that should be implemented) Agents capabilities specify the actual MIB modules that are implemented in an agent. Conformance defined using: OBJECT-GROUP macro NOTIFICATION-GROUP macro Notes Network Management: Principles and Practice © Mani Subramanian 2000 6-40

Conformance Statements: OBJECT-GROUP [RFC 2580/STD 58] Defines a group of related objects in a MIB module. Compiled during implementation, not at run time. OBJECTS clause names each object contained in the conformance group. Each of the named objects, has a MAX-ACCESS, and is defined in the same informational module as the OBJECT-GROUP macro. Every object, with MAX-ACCESS other than “not-accessible”, belongs to at least one OBJECT-GROUP. Notes Network Management: Principles and Practice © Mani Subramanian 2000 6-41

Conformance Statements: NOTIFICATION-GROUP [RFC 2580/STD 58] NOTIFICATION-GROUP Contains notification entities. NOTIFICATIONS clause identifies the notifications in the group. NOTIFICATIONS-GROUP macro compiled during implementation, not at run time. Notes Network Management: Principles and Practice © Mani Subramanian 2000 6-42

Conformance Statements: Module Compliance [RFC 2580/STD 58] Expansion of MODULE-COMPLIANCE macro is done during implementation, not at run time. Can be defined as a component of the information module or as a companion module. Compliance has two classes of groups: MANDATORY-GROUPS ... Required GROUP …Optional Notes Network Management: Principles and Practice © Mani Subramanian 2000 6-43

Conformance Statements: Agent Capabilities [RFC 2580/STD 58] Conveys a set of capabilities present in an SNMPv2 agent entity. AGENT-CAPABILITIES macro SUPPORTS modules and INCLUDES groups VARIATION identifies additional features Notes Network Management: Principles and Practice © Mani Subramanian 2000 6-44

noSuchObject [RFC 2580/STD 58] If a SNMPv2 entity acting in an agent role can not implement an object, the management protocol provides for the SNMPv2 entity to return an exception or error, e.g, noSuchObject. Under no circumstances shall a SNMPv2 entity return a value for objects which it does not implement -- it must always return the appropriate exception or error, as described in the protocol specification [RFC 3416] If a SNMPv2 entity returns a noSuchObject exception in response to a management protocol get operation for any object within any mandatory conformance group for every MIB view, or if the SNMPv2 entity cannot generate each notification listed in any conformance group under the appropriate circumstances, then that SNMPv2 entity is not a conformant implementation of the MIB module. 6-45

Transport Mappings [RFC 3417/STD 62] Although several mappings are defined, the mapping onto UDP is the preferred mapping. As such, to provide for the greatest level of interoperability, systems which choose to deploy other mappings should also provide for proxy service to the UDP mapping. The following are included: UDP CLNS (OSI) CONS (OSI) IPX Appletalk SNMPv2-TM DEFINITIONS ::= BEGIN … END 6-46

Transport Mappings – Cont. [RFC 3417/STD 62] -- SNMPv2 over UDP over IPv4 snmpUDPDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMPv2 over UDP transport domain. The corresponding transport address is of type SnmpUDPAddress.“ ::= { snmpDomains 1 } SnmpUDPAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d/2d“ DESCRIPTION "Represents a UDP address: octets contents encoding 1-4 IP-address network- byte order 5-6 UDP-port network-byte order " SYNTAX OCTET STRING (SIZE (6)) 6-47

Transport Mappings – Cont. [RFC 3417/STD 62] -- SNMPv2 over OSI snmpCLNSDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMPv2 over CLNS transport domain. The corresponding transport address is of type SnmpOSIAddress.“ ::= { snmpDomains 2 } snmpCONSDomain OBJECT-IDENTITY DESCRIPTION "The SNMPv2 over CONS transport domain. The corresponding transport address is of type SnmpOSIAddress.“ ::= { snmpDomains 3 } SnmpOSIAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT “*1x:/1x:” DESCRIPTION "Represents an OSI transport-address: octets contents encoding 1length of NSAP 'n' as an unsigned-integer (either 0 or from 3 to 20) 2..(n+1) NSAP concrete binary representation (n+2)..m TSEL string of (up to 64) octets " SYNTAX OCTET STRING (SIZE (1 | 4..85)) 6-48

SNMPv2 MIB Notes [RFC 3418/STD 62] Security is a placeholder. mgmt (2 directory (1) experimental (3) private (4) Internet {1 3 6 1} security (5) snmpv2 (6) snmpdomains snmpProxys (2) snmpModules Figure 6.31 SNMPv2 Internet Group snmpMIB mib-2 system snmp (11) snmpMIBConformance snmpMIBObjects Notes Security is a placeholder. System group: A table sysORTable added that lists resources that the agent controls. It is a collection of objects which describe the SNMP entity's (statically and dynamically configurable) support of various MIB modules. Most of the objects in the SNMPv1 snmp group obsoleted. Object Groups and Notification Groups defined for conformance specifications (specified under snmpMIBConformance). Network Management: Principles and Practice © Mani Subramanian 2000 6-49

SNMPv2 System Group [RFC 3418/STD 62] sysDescr (1) system (mib-2 1) sysObjectId (2) sysUpTime (3) sysContact (4) sysORLastChange (8) sysServices (7) sysLocation (6) sysName (5) sysORTable (9) sysOREntry (1) sysORIndex (1) sysORID (2) sysORDescr (3) sysORUpTime (4) Figure 6.32 The SNMPv2 System Group Entity OID Description sysORLastChange system 8 sysUpTime value at time of most recent change in state or value of any instance of sysORID. sysORTable system 9 Table listing system resources that the agent controls; manager can configure these resources through the agent sysOREntry sysORTable 1 An entry in the sysORTable sysORIndex sysOREntry 2 Row index, also index for the table sysORID sysOREntry 3 ID of the resource module sysORDescr sysOREntry 4 Textual description of the resource module sysORUpTime sysOREntry 5 System up-time since the object in this row was last instantiated 6-50 Network Management: Principles and Practice © Mani Subramanian 2000

SNMPv2 SNMP MIB Notes 6-51 Network Management: Principles and Practice © Mani Subramanian 2000 6-51

SNMPv1 SNMP MIB 6-52 Network Management: Principles and Practice © Mani Subramanian 2000 6-52

snmpMIBObjects MIB Notes snmpSetSerialNo OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "An advisory lock used to allow several cooperating SNMPv2 entities, all acting in a manager role, to coordinate their use of the SNMPv2 set operation. This object is used for coarse-grain coordination. To achieve fine-grain coordination, one or more similar objects might be defined within each MIB group, as appropriate.“ ::= { snmpSet 1 } Network Management: Principles and Practice © Mani Subramanian 2000 6-53

SNMPv2 Protocol - SNMPv2 PDU - Notes Standardized format for all messages Interpretation of error status and error index fields: In SNMPv1, if error occurs → status and index field filled, but varBindList blank In SNMPv2, (x: means non-zero value) Interpretation Status Index varBindList ignored x 0 varBind of index field ignored x x Network Management: Principles and Practice © Mani Subramanian 2000 6-54

SNMPv2 PDU and Error Status Network Management: Principles and Practice © Mani Subramanian 2000 6-55

SNMPv2 GetBulkRequest PDU Notes Error status field replaced by Non-repeaters Error index field replaced by Max repetitions No one-to-one relationship between request and response Network Management: Principles and Practice © Mani Subramanian 2000 6-56

Get-Bulk-Request: Generic MIB Network Management: Principles and Practice © Mani Subramanian 2000 6-57

Get-Next-Request Operation Network Management: Principles and Practice © Mani Subramanian 2000 6-58

Get-Bulk-Request Operation Network Management: Principles and Practice © Mani Subramanian 2000 6-59

Get-Bulk-Request Example Notes Network Management: Principles and Practice © Mani Subramanian 2000 6-60

SNMPv2 Trap Notes Addition of NOTIFICATION-TYPE macro OBJECTS clause, if present, defines order of variable bindings Positions 1 and 2 in VarBindList are sysUpTime and snmpTrapOID Network Management: Principles and Practice © Mani Subramanian 2000 6-61

Notification Definitions (RFC 2578, 1573) linkUp NOTIFICATION-TYPE OBJECTS { ifIndex, ifAdminStatus, 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 has transitioned out of the down state.” ::= { snmpTraps 4 } RFC 2578: The OBJECTS clause, which need not be present, defines the ordered sequence of MIB object types which are contained within every instance of the notification. An object type specified in this clause may not have an MAX-ACCESS clause of “not-accessible”. 6-62

Inform-Request Notes 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 Network Management: Principles and Practice © Mani Subramanian 2000 6-63

Bilingual Manager Notes Compatibility with SNMPv1 Bilingual Manager Proxy Server Bilingual Manager expensive in resource and operation Network Management: Principles and Practice © Mani Subramanian 2000 6-64

SNMP Proxy Server 6-65 Network Management: Principles and Practice © Mani Subramanian 2000 6-65