1

SNMPv2

by

Behzad Akbari

Fall 2008

In the Name of the Most High

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 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 RFC 2578 SMIv2SMIv2

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-TYPEOBJECT-TYPE MACRO ::=BEGIN

TYPE NOTATION ::="SYNTAX" SyntaxUnitsPart"MAX-ACCESS" Access"STATUS" Status"DESCRIPTION" TextReferPartIndexPartDefValPart

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-TYPESYNTAX BITS {

extensible(0), addressRecognitionCapable(1)

} MAX-ACCESS read-only

STATUS current DESCRIPTION “…”

::= { protocolDirEntry 5 }

13

UnitsPart: UNITS

hrDiskStorageCapacity OBJECT-TYPESYNTAX 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

"MAX-ACCESS" AccessAccess ::=

"not-accessible"| "accessible-for-notify"| "read-only"| "read-write"| "read-create"

ordered from least to greatest: "not-accessiblenot-accessible": indicates an auxiliary object "accessible-for-notifyaccessible-for-notify": accessible only via a notification "read-onlyread-only": read only "read-writeread-write": read and write, but create does not. "read-createread-create": read, write and create

15

"STATUS" StatusStatus ::=

"current" | "deprecated"

| "obsolete"

“currentcurrent”: the definition is current and valid.“deprecateddeprecated”:indicates an obsolete definition, it permits

new/continued implementation.“obsoleteobsolete”: the definition is obsolete and should not be

implemented.

16

ReferPartReferPart ::=

"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-TYPENOTIFICATION-TYPE MACRO ::= BEGIN

TYPE NOTATION ::=ObjectsPart"STATUS" Status"DESCRIPTION" TextReferPart

VALUE NOTATION ::=value(VALUE NotificationName)

ObjectsPart ::= "OBJECTS" "{" Objects "}“ | emptyObjects ::= Object | Objects "," ObjectObject ::= value(ObjectName)Status ::= "current" | "deprecated" | "obsolete"ReferPart ::= "REFERENCE" Text | emptyText ::= value(IA5String)

ENDNotificationName ::= OBJECT IDENTIFIER

18Reference: SNMPv2-MIB (RFC 1907)

NOTIFICATION-TYPE Example

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-IDENTITYSTATUS currentDESCRIPTION "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-TYPESYNTAX 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 standardipAddrTable.• 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

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

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

DisplayString ::= TEXTUAL-CONVENTIONDISPLAY-HINT "255a"STATUS currentDESCRIPTION "Represents textual

information taken from the NVTASCII character set, as defined inpages 4, 10-11 of RFC 854. …."

SYNTAX OCTET STRING (SIZE (0..255) )

• SNMPv2:

• SNMPV1:

Also see Page 251Also 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

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

Table 6.4 RowStatus Textual Convention

State Enumer-ation

Description

active 1 Row exists and is operationalnotInService 2 Operation on the row is suspendednotReady 3 Row does not have all the columnar objects

neededcreateAndGo 4 This is a one-step process of creation of a

row; immediately goes into active statecreateAndWait 5 Row is under creation and should not be

commissioned into servicedestroy 6 Same as Invalid in EntryStatus. Row should

be deleted

31

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 )

ManagerProcess

AgentProcess

ManagedEntity

Create Instance

Instance Created

33

Create-and-Wait:Row Creation

34

Row Deletion