SNMP V2 & V3

SNMP V2 Protocol
RFC 3416
3 types of access to management
information

Manageragent request-response
Manager-Manager request-response :
different from SNMPV1
Agent-manager unconfirmed

SNMP V2 Message Structure

SNMPV2 PDU Formats

PDU Details (1)

request-id :unique number to each

outstanding request to the same agent

error-status: a non-zero value indicates
that an exception occurred
error-index: When the error-status field
is nonzero, the error-index value
identifies the object that caused the
error

PDU Details (2)

variable-bindings: this field enables a single
operation to be applied to a group of object
instances

First element is an OID (Object Identifier)

Second element can be
Value Value associated with each object instances
unSpecified a NULL values is used in retrieval requests
NoSuchObject indicates agent does not implement the

object refered this OID

noSuchInstance indicates that this object instance does
not exist for this operation
endOfMibView indicates an attempt to reference an OID
that is beyond the end of the MIB at the agent

SNMP V2 Operations

Comparison of SNMPv1 and

SNMPv2 PDUs

Error Status Codes in responsePDU

Values in Variable Bindings

GetRequest PDU
Same as SNMPv1, it is different only the
way that responses are handled
SNMP v1 operation is atomic
SNMP v2 operation prepares variable
binding according to following rules

1 OID not match value is set to noSuchObject

2 Otherwise, but not accessible for operation
value is set to noSuchInstance
3 Otherwise, value is set to the value of variable

GetNextRequestPDU
Same as SNMPv1, it is different only the

way that responses are handled

SNMP v1 operation is atomic
SNMP v2 processes as many as possible by
the following rule
1 the next instance can be retrieved, set the
name and value in variable-bindings
2 if no lexicographic successor exists, set the
value field to endOfMibView

GetBulkRequest PDU (1)

Its purpose is to minimize the number of

protocol exchanges required to retrieve a

large amount of management information
It uses the same selection principle as the
GetNextRequest but multiple lexicographic
successor can be selected
2 additional fields
Non-repeaters the number of variables that
single successor value to be returned
Max-repetitions the number of successor
value to be returned

GetBulkRequest PDU (2)

SetRequest PDU
The structure is same as SNMPv1
SetRequest PDU for SNMPv1 and
SNMPv2 is both atomic operation

SNMPv2-Trap PDU
The format is different from SNMPv1
It uses the same format as

GetRequestPDU
Using variable bindings field to contain
sysUpTime.0
snmpTrapOID.0
- If the OBJECT clause is present in the macro
NOTIFICATION-TYPE, each variable and its
value are copied to the variable-binding

InformRequest PDU
New PDU type for SNMP
Manager to Manager operation
Response by using Response PDU

SNMPv2 MIB (1)

System Group :
include MIB for
Object
Resources
sysORlast
change
sysORTable

SNMPv2 MIB (2)

System Group of SNMPv2

SNMPv2 MIB (3)

Revised SNMP Group

SNMPv2 MIB (4)

MIB Objects Group
snmpTrap
snmpTrapOID : OID of trap or notification

currently being sent

snmpTrapEnterprise :OID of enterprise
associated with the trap currently being sent

SNMPv2 MIB (5)

snmpSet
snmpSerialNo : TestAndIncr (INTEGER

0..2147483647)
If the agent receive a set operation for this
object with value K then the value is
incremented to K+1 mod 231
If the agent receive a set operation for this
object with value not equal to K then the
operation fails with an error of inconsistentValue
To solve multiple managers using an agent

SNMPv2 MIB (6)

Interfaces Group in RFC1573 :

extension of interface Group in MIB-II

ifXTable (Extension Table)

ifStackTable (Stack Table)
ifTestTable (Test Table)
IfRcvAddressTable (Receive Address
Table)

SNMPv2 MIB (7)

ifXTable

This table contains objects that have

been added to the Interface MIB as a res
ult of the Interface Evolution effort, or re
placements for objects of the original, MI
B-II, ifTable that were deprecated becau
se the semantics of said objects have si
gnificantly changed.

SNMPv2 MIB (8)

ifStackTable

This table contains objects that define the

relationships among the sub-layers of an interface.

ifTestTable

This table contains objects that are used to

perform tests on interfaces.
This table is a generic table.
The designers of media-specific MIBs must define
exactly how this table applies to their specific MIB.

SNMPv2 MIB (9)

ifRcvAddressTable

This table contains objects that are used

to define the media-level addresses
which this interface will receive.
This table is a generic table.
The designers of media- specific MIBs
must define exactly how this table appli
es to their specific MIB.

SNMP V3

SNMP v3 Goals (1)

Use existing materials as much as possible.
It is heavily based on previous work, informally known
as SNMPv2u and SNMPv2*, based in turn on
SNMPv2p.

Address the need for secure SET support, which

is considered the most important deficiency in

SNMPv1 and SNMPv2c.
Make it possible to move portions of the
architecture forward in the standards track, even
if consensus has not been reached on all pieces.
Define an architecture that allows for longevity
of the SNMP Frameworks that have been and will
be defined.

SNMP v3 Goals (2)

Keep SNMP as simple as possible.
Make it relatively inexpensive to deploy a

minimal conforming implementation.

Make it possible to upgrade portions of SNMP
as new approaches become available, without
disrupting an entire SNMP framework.
Make it possible to support features required
in large networks, but make the expense of
supporting a feature directly related to the
support of the feature.

Security Requirement (1)

Modification of Information

Some unauthorized entity may alter intransit SNMP messages generated on behalf
of an authorized principal in such a way as t
o effect unauthorized management operatio
ns, including falsifying the value of an object
.

Masquerade

Management operations not authorized for

some principal may be attempted by
assuming the identity of another principal th
at has the appropriate authorizations.

Security Requirement (2)

Message Stream Modification

Messages may be maliciously re-ordered,

delayed or replayed to an extent which is great
er than can occur through the natural operation
of a subnetwork service, in order to effect unaut
horized management operations.

Disclosure

Eavesdropping on the exchanges between

SNMP engines.
Protecting against this threat may be required
as a matter of local policy.

SNMP engine
An SNMP engine provides services for sen
ding and receiving messages,
authenticating and encrypting messages,
and controlling access to managed object
s.

a Dispatcher
a Message Processing Subsystem
a Security Subsystem
an Access Control Subsystem.

SNMP Manager
An SNMP entity containing one or

more command generator and/or not

ification receiver applications (along
with their associated SNMP engine) h
as traditionally been called an SNMP
manager

SNMP Agent
An SNMP entity containing one or

more command responder and/or not

ification originator applications (alon
g with their associated SNMP engine)
has traditionally been called an SNMP
agent

 SNMPv3 Message Format

SNMPv3 message format is very

different from the above two because

of lot of security parameters
introduced in this version. Below is
how it looks like:

 Version It is an Integer that

identifies the version of SNMP. For

SNMPv3, it is 3.
ID This field contains the SNMP
message identifier which is a unique
ID associated with the message. The
msgID field is different from the reqID
field available in the PDU.

 Max Size This field represents the

maximum size of message which the

requesting SNMP entity can accept.
Flags This field contains the
message security level. 0 message
is authenticated, 1 message uses
privacy, 2 a report PDU is expected
for the message

 Security Model This field indicates

the security model used to generate

the message. When USM is used, it
has a value of 3
Engine Time This field has the
snmpEngineTime value of the
authoritative SNMP entity involved in
the transaction

 Engine ID This field has the

SNMPEngineID of the authoritative

SNMP entity involved in the
transaction. When a request PDU is
generated from an SNMP engine, the
remote peer (agent for Get request
and manager for Trap request) is the
authoritative SNMP entity.

 Engine Boots This field has the

snmpEngineBoots value of the

authoritative SNMP entity involved in
the transaction