1. Dept. of Computer Science and Engineering
SNMP Version 2 (SNMPv2)
J. Won-Ki Hong
Dept. of Computer Science and Engineering
POSTECH
Tel: 1 1

2. Table of Contents The Birth of SNMPv2 SNMPv2 RFCs SNMPv2 Enhancements
SNMPv2 Protocol Operations
SNMPv2 Coexistence with SNMPv1 3

3. The Birth of SNMPv2 a major problem with SNMP is the lack of security
secure SNMP was proposed (July 1992) to solve this problem in SNMP
Simple Management Protocol (SMP) was also proposed (July 1992) to extend the SNMP functionality
secure SNMP + SMP = SNMPv2 (March 1993)
a major security flaw was detected in this proposal and the security aspects were dropped and the result is community-based SNMPv2 (Jan. 1996)

4. SNMPv2 RFCs RFC 1901 (experimental)
Introduction to Community-based SNMPv2
RFC 1902 (draft) -> RFC 2578 (standard)
Structure of Management Information for SNMPv2 (SMIv2)
RFC 1903 (draft) -> RFC 2579 (standard)
Textual Conventions for SMIv2
RFC 1904 (draft) -> RFC 2580 (standard)
Conformance Statements for SMIv2

5. SNMPv2 RFCs (cont’d) RFC 1905 (draft) RFC 1906 (draft)
Protocol Operations for SNMPv2
RFC 1906 (draft)
Transport Mappings for SNMPv2
RFC 1907 (draft)
Management Information Base for SNMPv2
RFC 1908 (draft)
Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework

6. SNMPv2 Key Enhancements
SMIv2 (a superset of SMIv1)
provides more elaborate specification and documentation of managed objects and MIB modules
object type macros expanded (see Fig. 11.1, 11.2 & Table 11.2)
creating and deleting conceptual rows in a table (as used in RMON)
notification definitions
information modules
new SNMP MIB definitions are defined using SMIv2
Manager-to-Manager Capability
for managing large, distributed networks
Protocol Operations
bulk management information retrieval
manager-to-manager communication

7. Comparison of Data Types

8. Notification Type MACRO
NOTIFICATION-TYPE MACRO ::= BEGIN
TYPE NOTATION ::= ObjectsPart
“STATUS” Status
“DESCRIPTION” Text
ReferPart
VALUE NOTATION ::= value (VALUE NotificationName)
ObjectsPart ::= “OBJECTS” “{“ Objects “}” | empty
Objects ::= Object | Objects “,” Object
Object ::= value (Name ObjectName)
Status ::= “current” | “deprecated” | “obsolete”
ReferPart ::= “REFERENCE” Text | empty
Text ::= “““ string “““
END

9. Notification Type Example
coldStart NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"A coldStart trap signifies that the
SNMPv2 entity, acting in an agent role, is
reinitializing itself and that its
configuration may have been altered."
::= { snmpTraps 1 }
-- From RFC 1907

10. Module Identity MACRO MODULE-IDENTITY MACRO ::= BEGIN
TYPE NOTATION ::= “LAST-UPDATED” value (Update UTCTime)
“ORGANIZATION” Text
“CONTACT-INFO” Text
“DESCRIPTION” Text
RevisionPart
VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
RevisionPart ::= Revisions | empty
Revisions ::= Revision | Revisions Revision
Revision ::= “REVISION” value (Update UTCTime)
Text ::= “““ string “““
END

11. Module Identity Example
rmon MODULE-IDENTITY
LAST-UPDATED " Z"
ORGANIZATION "IETF RMON MIB Working Group"
CONTACT-INFO
"Steve Waldbusser (WG Editor)
Postal: International Network Services
650 Castro Street, Suite 260
Mountain View, CA 94041
Phone:
DESCRIPTION
"The MIB module for managing remote monitoring
device implementations. This MIB module augments
the original RMON MIB as specified in RFC 1757."
::= { mib-2 16 }

12. Object Identity MACRO OBJECT-IDENTITY MACRO ::= BEGIN
TYPE NOTATION ::= “STATUS” Status
“DESCRIPTION” Text
ReferPart
VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
Status ::= “current” | “deprecated” | “obsolete”
ReferPart ::= “REFERENCE” Text | empty
Text ::= “““ string “““
END

13. Object Identity Example
snmpUDPDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMPv2 over UDP transport domain.
The corresponding transport address
is of type SnmpUDPAddress."
::= { snmpDomains 1 }
-- from RFC 1906

14. SNMPv2 MIB Access

15. SNMPv2 Operations GetRequest - get the value for each listed object
GetNextRequest - get next value for each listed object
GetBulkRequest - get multiple values
Response - respond to manager request
SetRequest - set value for each listed object
InformRequest - send unsolicited information from a manager to another
SNMPv2-Trap - send unsolicited information from an agent to a manager

16. SNMPv2 PDU Formats version (1) community PDU SNMPv2 Message
variable-bindings
request id
PDU
type
(a) GetRequest-PDU, GetNextRequest-PDU, SetRequest-PDU,
SNMPv2-Trap-PDU, InformRequest-PDU
PDU
type
request id
error
status
error
index
variable-bindings
(b) Response-PDU
PDU
type
request id
non-
repeaters
max-
repetitions
variable-bindings
(c) GetBulkRequest-PDU
name1
value1
name2
value2
. . .
nameN
valueN
(d) variable-bindings

17. GetBulkRequest
used to minimize the exchanges required to retrieve a large amount of information
selection principle is the same as GetNextRequest
the next object instance in lexicographic order
includes a list of (N + R) variable names in the variable-bindings list
the first N variables for retrieving single values
the next R variables for retrieving multiple values
non-repeaters and max-repetition fields are used to indicate the number of N and R variables

18. Interpretation of GetBulkRequest Fields
name1 name nameN
nameN nameN+R
For first N variables:
provide one value each
(first lexicographic successor)
For last R variables:
provide M values each
(first M lexicographic successors)
L = number of names in variable-bindings field
N = MAX [ MIN (non-repeaters, L), 0 ]
M = MAX [ max-repetitions, 0 ]
R = L - N

19. GetBulkRequest Example
GetBulkRequest (non-repeaters = 2,
max-repeaters = 6, X, Y, TA, TB, TC)
Manager issues request with six variable
names; for the first two variable (non-repeaters=2),
a single value is requested; for the remaining variables
six successive values (max-repeaters=6) are requested.
Agent
(e.g, router) x Y
Table a TA TB TC
NMS
Agent returns single
value for X, Y, and six
rows of table a
Response [X, Y, TA(1), TB(1), TC(1),
TA(2), TB(2), TC(2),
TA(3), TB(3), TC(3),
TA(4), TB(4), TC(4),
TA(5), TB(5), TC(5),
TA(6), TB(6), TC(6) ]

20. SNMPv2-Trap and InformRequest
is sent from an agent to a manager when an unusual event occurs
no response is required
InformRequest
is sent from a manager for passing information to an application running in another manager
Response PDU is used to acknowledge the request
for hierarchical or distributed management where multiple managers are involved

21. SNMPv2 PDU Sequences Manager Agent GetRequest PDU GetNextRequest PDU
Response PDU
SetRequest PDU
GetNextRequest PDU
SNMPv2-Trap PDU
GetBulkRequest PDU
InformRequest PDU

22. PDU Comparisons

23. Transport Mappings
RFC 1906 specifies the mapping of SNMPv2 onto the following transport protocols
User Datagram Protocol (UDP)
OSI Connectionless-Mode Network Service (CLNS)
OSI Connection-Oriented Network Service (CONS)
Novell Internetwork Packet Exchange (IPX)
Appletalk
The SNMPv2 document states that UDP is the preferred mapping

24. Coexistence by Means of Proxy Agent
SNMPv1
agent
SNMPv2
manager
SNMPv2 environment
SNMPv1 environment
GetRequest
GetNextRequest
SetRequest
GetBulkRequest
Response
GetResponse
SNMPv2-Trap
Trap
SNMPv2 manager-to-agent
PDUs
SNMPv1 manager-to-agent
SNMPv2 agent-to-
manager PDUs
SNMPv1 agent-to-

25. Coexistence by Means of Bilingual Manager
SNMPv2
manager
InformRequest, Response
GetRequest, GetNextRequest,
SetRequest
Bilingual
manager
(v1, v2)
InformRequest, Response
SNMPv1
agent
SNMPv2-Trap, Response
GetResponse, Trap
SNMPv2
agent
getRequest, getNextRequest
getBulkRequest, setRequest

26. Summary SNMPv2 is a natural extension of SNMPv1
Key enhancements in SNMPv2 are:
more elaborate MIB specification capability (SMIv2)
Manager-to-Manager communication
Bulk information transfer
SNMPv2 failed to improve on security
More powerful but more complex than SNMPv1
SNMPv3 focuses on improving the security aspect