0% found this document useful (0 votes)
41 views

Snmpv2: in The Name of The Most High

This document provides an overview of SNMPv2, including its development in response to SNMPv1 and the OSI model. It describes key changes and enhancements in SNMPv2, such as bulk data transfer capabilities and additional PDU message types. The document also outlines the SMIv2 data definition language and its modules, objects, and conformance statements.

Uploaded by

Wubliker B
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
41 views

Snmpv2: in The Name of The Most High

This document provides an overview of SNMPv2, including its development in response to SNMPv1 and the OSI model. It describes key changes and enhancements in SNMPv2, such as bulk data transfer capabilities and additional PDU message types. The document also outlines the SMIv2 data definition language and its modules, objects, and conformance statements.

Uploaded by

Wubliker B
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 65

In the Name of the

Most High

SNMPv2

by
Dr. Angelito F. Argete

2nd Sem 2020-2021

1
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.

2
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

3
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

4
Major Changes
 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

Internet
{1 3 6 1}

SNMPv2
directory mgmt experimental private security snmpv2
(1) (2) (3) (4) (5) (6)

SNMPv2 Internet Group


inform-request
get-request

get-next-request

get-bulk-request

IP

DLC

PHY
UDP
SNMP
set-request Application
SNMP Manager
SNMP Manager

response
snmpV2-trap

Physical Medium
PDU

PDU
SNMP
Application

inform-request
get-request

get-next-request

IP get-bulk-request

DLC

PHY
UDP
SNMP

set-request
Application
SNMP Manager

SNMP Manager

response
snmpV2-trap
SNMPv2 System Architecture

PDU

PDU
SNMP
Application

Physical Medium

get-request

get-next-request

get-bulk-request
IP

DLC

PHY
UDP
SNMP

set-request
Application
SNMP Agent
SNMP Agent

response
snmpV2-trap
Additional Messages
 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
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
 OBJECT IDENTIFIER, OBJECT-IDENTITY, OBJECT-TYPE

 OBJECT IDENTIFIER defines the administrative identification of a


node in the MIB

 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

 OBJECT-TYPE macro defines the type of a managed object (e.g., a


specific router type)
 Focuses on the details of implementation
 NOTE:
 OBJECT-IDENTITY is high level description
 OBJECT-TYPE details description needed for implementation
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
Object Definitions, example

NOTE: A specific instance of


routerIsi123 could be identified by
its IP address 10.1.2.3
Table Definition
 Static Tables
 Tables completely controlled by the agent. Access is read-only, and read-
write
 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
 Allows row creation/deletion by a manager
 Access includes also read, write and create privileges
 A table can be initialized with no rows and expanded as needed
 SNMPv2: Augmentation of a table (dependent table)
 Adds additional columns to an existing table (base table)
 Number of rows is not affected
 INDEX of the second table is the same as the first table
 One to one correspondence between rows of two tables
Augmentation of Tables
Table 2
Table 1
Base table Augmented table
table1 table 2
(T1) (T2)

table1Entry table2Entry
(E1) (E2)

T1.E1.C1.1 T1.E1.C2.1 T1.E1.C3.1 T2.E2.C4.1 T2.E2.C5.1

T1.E1.C1.2 T1.E1.C2.2 T1.E1.C3.2 T2.E2.C4.2 T2.E2.C5.2

T1.E1.C1.3 T1.E1.C2.3 T1.E1.C3.3 T2.E2.C4.3 T2.E2.C5.3

T1.E1.C1.4 T1.E1.C2.4 T.E1.C3.4 T2.E2.C4.4 T2.E2.C5.4

Conceptual rows: Example


Index: 1. T1.E1.C1.1 Columnar object:T2.E2.C4
First columnar object in Table 1 2. T1.E1.C1.2
3. T1.E1.C1.3
Index: T1.E1.C1.2
4. T1.E1.C1.4 Value: T2.E2.C4.2
Augmentation of Tables

--Conceptual row extension

Example: a vendor can easily specify


vendor-specific objects as A clause used to increase the number of
extensions to standard MIB table. It columns in a table w/out rewriting the
should be easier for applications to table definition
access these objects than if they
were defined as new, separate The resulting table is therefore treated the same way
table 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 agent to send


responses to a manager

Used by manager for


row creation/deletion
Row Creation
table1

entry1

status.1 index.1 data.1

status.2 index.2 data.2

status.3 index.3 data.3

Row to be created/deleted

2 states for RowStatus: createAndGo, createAndWait


Create and Go

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 )

 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
Create and Wait
Manager Agent
Process Process

SetRequest (
status.3 = 5,
index.3 = 3 ) Create and wait, no default
Response ( data specified
Agent responds with “notReady” status.3 = 3,
(no default value) index.3 = 3 )

GetRequest ( Get the data for the row


data.3 )
Response (
Data value is missing data.3 = noSuchInstance)

SetRequest (
data.3 = DefData ) Value of data is sent
Response (
status.3 = 2
Agent responds with
data.3 = DefData )
notInServcie
SetRequest (
status.3 = 1 ) Manager requests to activate
Response ( the row
Row activated status.3 = 1 )
Row Deletion

Manager Agent Managed


Process Process Entity

SetRequest (
status.3 = 6 )
Delete Instance
Instance Deleted
Response (
status.3 = 6 )
Textual Conventions
 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

SNMPv2

SNMPv1

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 (0..10000)
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

PDU Error Error VarBind 1 VarBind 1 VarBind n VarBind n


RequestID ...
Type Status Index name value name value

SNMPv2 PDU
Indicate the type of PDU
(e.g., Request-PDU, etc) identifies the first variable binding
in the variable-binding list that
Indicate the status of the error caused the error
(e.g., noError, tooBig, etc.)
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
PDU Non- Max VarBind 1 VarBind 1 VarBind n VarBind n
RequestID ...
Type Repeaters Repetitions name value name value

SNMPv2 GetBulkRequest PDU

 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
GetBulkRequest-PDU Operation
A

A B T Z B

E
T

E
1.1 2.1 3.1

T.E.1.1 T.E.2.1 T.E.3.1


1.2 2.2 3.2

T.E.1.2 T.E.2.2 T.E.3.2

1.3 2.3 3.3


T.E.1.3 T.E.2.3 T.E.3.3

1.4 2.4 3.4 T.E.1.4 T.E.2.4 T.E.3.4

Z
GetBulkRequest-PDU Operation

GetRequest ( A,B )
Manager Agent
Process GetResponse (A,B) Process
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)

GetNextRequest (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)

GetNextRequest (T.E.1.4,T.E.2.4,T.E.3.4)
GetResponse (T.E.2.1,T.E.3.1,Z)
GetBulkRequest-PDU Operation
A

2 non repetitive objects (A, B)

3 repetitive instances B
Of the columnar object
Manager T.E.1, T.E.2, T.E.3 Agent
Process Process T

GetBulkRequest ( 2,3,
A,B,T.E.1, T.E.2, T.E.3 ) E
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 ) 3 more rows T.E.1.1 T.E.2.1 T.E.3.1

GetBulkRequest ( 0,3,
T.E.1.3, T.E.2.3, T.E.3.3 ) T.E.1.2 T.E.2.2 T.E.3.2

Response ( T.E.1.4, T.E.2.4, T.E.3.4, Z , " endOfMibView") T.E.1.3 T.E.2.3 T.E.3.3

T.E.1.4 T.E.2.4 T.E.3.4


Z is next in the lexicographic order

Z
GetBulkRequest-PDU Operation
SNMPv2 Trap PDU

PDU Error Error VarBind1 VarBind1 VarBind2 VarBind 2


RequestID ...
Type Status Index sysUpTime value snmpTrapOID value

 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
 The receiving manager sends response to the sending manager
Conformance Statements for SMIv2
(RFC 2580)

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

NG
OG OG
NT
OT OT OT NT NT

OT OT OT OT NG
NT NT

OG OG NG NG MC
MC

40
Four Macros in SNMPv2-CONF

 OBJECT-GROUP macro
 NOTIFICATION-GROUP macro
 MODULE-COMPLIANCE macro
 AGENT-CAPABILITIES macro

41
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

42
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
43
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 }

44
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

45
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
46
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 }

47
Compliance

• Compliance has two classes of groups


• MANDATORY-GROUPS ... Required
• GROUP …Optional

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

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

50
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

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

52
MODULE-COMPLIANCE Example
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."

53
::= { hrMIBCompliances 1 }
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)."

54
OBJECT-GROUP

55
Agent Capabilities

• AGENT-CAPABILITIES macro
• SUPPORTS modules and includes groups
• VARIATION identifies additional features

56
AGENT-CAPABILITIES

57
SNMPv2 Internet Group

58
NOTIFICATION-TYPE

59
Object Types for SNMPv2 Traps

60
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

61
SNMPv2- Decentralized management

Agent

Element manager
SNMPv2
agent MIB
SNMPv2
Manager/agent
Management server
MIB
Management Applications
SNMPv2
agent MIB
SNMPv2
MIB
manager SNMPv2
Manager/agent

MIB
SNMPv2
agent MIB

SNMPv2 Configuration
Compatibility with SNMPv1
 SNMPv2 MIB is not backward compatible with SNMPv1
 Compatibility with SNMPv1  2 evolution paths:
 Bilingual Manager
 Proxy Server
 Bilingual Manager expensive in resource and operation

Bilingual Manager Agent


Profile

SNMPv1 SNMPv2
Interpreter Interpreter Both interpreters are required!

SNMPv1 SNMPv2
Agents Agents

SNMP Bilingual Manager


SNMP Proxy Server
SNMPv2 Manager

Proxy
Server

SNMPv1 SNMPv2
Agents Agents

SNMPv2 Manager SNMP v2-v1 Proxy Server SNMPv1 Agent

GetRequest Pass-Through GetRequest

GetNextRequest Pass-Through GetNextRequest

SetRequest Pass-Through SetRequest

GetBulkRequest
Set: 1. non-repeaters = 0 GetNextRequest
2. max-repetitions = 0
Pass-Through
Response Exception: For 'tooBig' error, contents of variable-bindings GetResponse
field removed .

SNMPv2-Trap
Prepend VarBind: 1. sysUpTime.0 Trap
2. snmpTrapOID.0

SNMP v2-v1 Proxy Server


SNMPv2 MIB

65

You might also like