Transcript inse7120-lec6

SNMPv1 (cont’d) & SNMPv2 (II)*
*Mani
Subramanian “Network Management: Principles and
practice”, Addison-Wesley, 2000.
SNMP Network Management
 SNMP Protocol Specs
 SNMP Operations
 GetRequest-PDU
 GetNextRequest-PDU
 SetRequest-PDU
 GetResponse-PDU
 Trap-PDU
 Polling
Frequency
limitations of SNMP v1
 SNMPv2
and
Communication Model
MANAGER
AGENTS
MIB
Communication Model
 Communicate mgnt information between network
mgnt stations and managed elements
 Goals:
o
o
o
Management functions maintained by agents are kept
simple
Protocol flexibility (addition of new aspects of
operation and management)
Transparency (should not be affected by the
architecture of particular hosts and gateways)
 Operation: 5 messages
o
o
get-request, get-next request, set-request
get-response, trap
 SNMP messages are exchanged using UDP (connection
less) transport protocol
Communication Model
SNMP Manager
SNMP messages
SNMP agent
UDP
UDP
IP
IP
DLC
DLC
PHY
PHY
Network or
Internet
Physical Medium
Trap
Get-Response
SNMP Agent
Application
Set-Request
Application
Manages objects
Trap
Get-Response
Set-Request
GetNext-Request
Get-Request
SNMP Manager
Application
GetNext-Request
Management
Data
SNMP Agent
Get-Request
SNMP Manager
Message Format
version
community
 Protocol entities support
application entities
 Communication between
remote peer processes
Message consists of :
o
o
Version identifier
Community name
Protocol Data Unit
 Message encapsulated in UDP
datagrams and transmitted


Loss of message  time out!
data
 Like FTP, SNMP uses two well-
known ports to operate:



UDP Port 161 - SNMP
Messages
UDP Port 162 - SNMP Trap
Messages
Size of SNMP message: 1472
bytes
Message Format
version
community
data
 SNMP message format is defined using ASN.1,
encoded for transmission over UDP using BER
Message ::= SEQUENCE {
version
INTEGER {version-1(0)},
community OCTET STRING,
data
PDUs
}
3 different versions:
SNMPv1, SNMPv2, SNMPv3
Message Format-Set/Get PDU
version
community
data
Message ::= SEQUENCE {
version
INTEGER {version-1(0)},
community OCTET STRING,
data
PDUs
}
PDUs::= CHOICE {
get-request
[0] IMPLICIT PDU,
get-next-request [1] IMPLICIT PDU,
get-response
[2] IMPLICIT PDU,
set-request
[3] IMPLICIT PDU,
trap
[4] IMPLICIT Trap-PDU
}
Message Format-Set/Get PDU
PDUtype
requestid
errorstatus
errorindex
PDU ::= SEQUENCE {
request-id
INTEGER,
error-status
INTEGER {
noError
(0),
tooBig
(1),
noSuchName(2),
badValue (3),
readOnly (4),
genErr
(5)
},
error-index
INTEGER,
variable-bindings VarBindList
}
variable-bindings
request-id:
track a message and
indicate loss of a message
(e.g., timeout, etc.)
error-status: indicate the
occurrence of error
error-index: indicate the
occurrence of error (position
in the list of variables)
variable-bindings: grouping of
number of operations in a
single message:
e.g., one request to get all
values and one response listing
all values
Message Format-variable bindings
var-bind 1
name
value
VarBindList
var-bind 2
name
value
var-bind n
...
::= SEQUENCE OF VarBind
VarBind
::= SEQUENCE {
name ObjectName,
value ObjectSyntax
}
ObjectName
::= OBJECT IDENTIFIER
ObjectSyntax ::= CHOICE {
simple
SimpleSyntax,
application-wide ApplicationSyntax
}
name
value
Message Format-variable bindings
SimpleSyntax ::= CHOICE {
number INTEGER,
string OCTET STRING,
object OBJECT IDENTIFIER,
empty NULL
}
ApplicationSyntax::= CHOICE {
address
NetworkAddress,
counter
Counter,
gauge
Gauge,
ticks
TimeTicks,
arbitrary Opaque
}
NetworkAddress::= CHOICE {
internet IpAddress
}
Message Format-Trap PDU
PDUAgent
Generic
Specific
Entreprise
type
Address Trap Type Trap Type
Time
Stamp
variable-bindings
Trap-PDU ::= SEQUENCE {
-Pertain to the system generating
enterprise
OBJECT IDENTIFIER,
the trap (sysObjectID)
agent-addr
NetworkAddress,
-IP address of the objetc
generic-trap
INTEGER {
coldStart
(0),
warmStart
(1),
linkDown
(2),
linkUp
(3),
authenticationFailure(4),
egpNeighborLoss
(5),
enterpriseSpecific
(6)
},
Specific code to identify the
specific-trap
INTEGER,
trap cause…
time-stamp
TimeTicks,
Elapsed time since last re-initialization
variable-bindings VarBindList
}
SNMP Network Management
 SNMP Protocol Specs
 SNMP Operations
 GetRequest-PDU
 GetNextRequest-PDU
 SetRequest-PDU
 GetResponse-PDU
 Trap-PDU
 Polling
Frequency
limitations of SNMP v1
 SNMPv2
and
SNMP Operations
An SNMP entity performs the
following to transmit a PDU


Construct a PDU using ASN.1
Pass PDU to Authentication
Service (AS) along with s-d
transport addresses and
community name
o AS returns a PDU that is
encrypted (if encryption is
supported)


The Protocol entity then
constructs an SNMP message
by adding the version field
and the community name to
the PDU
Message is encoded using BER
and it is passed to the
transport service
An SNMP entity performs the
following upon reception of an
SNMP message
 Basic syntax check, message is
discarded in case of error
 Verifies the version number-message discarded if there is
mismatch
o Authentication (if supported):
if message does not
authenticate, generate trap
and discard message.

Finally, using the community
name, the access policy is
selected and PDU is processed
GetRequest PDU
 Sender includes the following
system
(mib-2 1)
fields:



PDU Type
request-id
Variable-bindings
 A list of object instances
whose values are requested
 SNMP dictates that a scalar
object is identified by
OBJECT-IDENTIFIER
concatenated with 0

its
e.g., sysDescr.0: distinguishes
between the object type and an
instance of the object
sysDescr (1)
sysObjectId
(2)
sysUpTime (3)
sysServices (7)
sysLocation (6)
sysName (5)
sysContact (4)
GetRequest PDU
.0 indicates that the scalar value
should be retrieved (scalar objects only)
Agent
Process
Manager
Process
GetRequest (sysDescr.0)
GetResponse (sysDescr .0= "SunOS" )
GetRequest (sysObjectID.0)
GetResponse ( sysObjectID.0=enterprises.11.2.3.10.1.2 )
GetRequest (sysUpTime.0)
GetResponse (sysUpTime.0=2247349530)
GetRequest (sysContact.0)
GetResponse (sysContact.0=" ")
GetRequest (sysName.0)
GetResponse (sysName.0="noc1 ")
GetRequest (sysLocation.0)
GetResponse (sysLocation.0=" ")
GetRequest (sysServices.0)
GetResponse (sysServices.0=72)
The manager could have used only one message to obtain
the values of all objects under system group: using
“variable binding list”
GetRequest PDU
 Get Request is atomic

Either all values (of all
variables provided in the
binding list) retrieved or none
 With SNMP, only leaf objects
in the MIB can be retrieved

 error message is generated if
at least one of the variables
could not be found/returned;
error-status:



noSuchName
tooBig
genErr
indicate the
problem object (i.e., variable in
binding list that caused the
problem)
 error-index:

e.g.
it is not possible to
retrieve an entire row of a
table by simply accessing the
Entry
Object
(e.g.,
ipRouteEntry)
 the management stations has
to include each object instance
(in the row) in the binding list
o By including the complete
object
identifier
and
respecting the rule of indexing!
GetRequest PDU
ipRouteDest
9.1.2.3
10.0.0.51
10.0.0.99
ipRouteMetric1
3
5
5
ipRouteNextHop
99.0.0.3
89.1.1.42
89.1.1.42
Index of table
 GetRequest (ipRouteDest.9.1.2.3,
ipRouteMetric1.9.1.2.3, ipRouteNextHop. 9.1.2.3 )
GetNextRequest PDU
 PDU format:

system
(mib-2 1)
same as GetReqest
 Difference:

each variable in the binding list
refers to an object instance next in
the lexicographic order
 GetNextRequest
(sysDescr.0)
 return the value of the object
instance of sysObjectId
 Advantages:


Allows a network manager to
discover
a
MIB
structure
dynamically
Efficient way for searching through
tables whose entries are unknown
sysDescr (1)
sysObjectId
(2)
sysUpTime (3)
sysServices (7)
sysLocation (6)
sysName (5)
sysContact (4)
GetNextRequest PDU
Agent
Process
Manager
Process
GetRequest (sysDescr.0)
GetResponse (sysDescr .0= "SunOS" )
GetNextRequest (sysDescr.0)
GetResponse ( sysObjectID.0=enterprises.11.2.3.10.1.2 )
GetNextRequest (sysObjectID.0)
GetResponse (sysUpTime.0=2247349530)
GetNextRequest (sysUpTime.0)
GetResponse (sysContact.0=" ")
GetNextRequest (sysContact.0)
GetResponse (sysName.0="noc1 ")
GetNextRequest (sysName.0)
GetResponse (sysLocation.0=" ")
GetNextRequest (sysLocation.0)
GetResponse (sysServices.0=72)
GetNextRequest (sysServices.0)
GetResponse (noSuchName)
Error message: no object next
to sysServices
Get-Next-Request Operation for System Group
Generalized Case
A sample MIB that contains
both scalar values and aggregate
objects
Retrieving scalar as well
A
B
aggregate objects using getrequest and get-next-request
T
Z
E
1.1
2.1
3.1
1.2
2.2
3.2
Generalized Case
Manager
Process
A
Agent
Process
B
GetRequest ( A )
GetResponse ( A )
T
GetRequest ( B )
GetResponse ( B )
GetRequest (T.E.1.1)
E
GetResponse ( T.E.1.1 )
GetRequest (T.E.1.2)
GetResponse ( T.E.1.2 )
GetRequest (T.E.2.1)
T.E.1.1
T.E.2.1
T.E.3.1
T.E.1.2
T.E.2.2
T.E.3.2
GetResponse ( T.E.2.1 )
GetRequest (T.E.2.2)
GetResponse ( T.E.2.2 )
GetRequest (T.E.3.1 )
GetResponse ( T.E.3.1 )
GetRequest (T.E.3.2 )
GetResponse ( T.E.3.2 )
GetRequest (Z )
GetResponse ( Z )
Z
Generalized Case
Observations:
A
1)- we need to know all the elements in the MIB,
including the # of columns and rows in a table
B
2)- a MIB is traversed from top to bottom (i.e., from
left to right in the tree structure)
T
3)- data in tables is retrieved by traversing all
instances of a columnar object
NOTES:
1)- dynamic table: # rows may not be known to
manager
E
T.E.1.1
T.E.2.1
T.E.3.1
T.E.1.2
T.E.2.2
T.E.3.2
A request to T.E.1.3 results in error message
3)- GetNextRequest could avoid this!
4)- A convention is required for the definition of the
next object in a MIB
 SNMP uses lexicographic convention
Z
Lexicographic Convention
Procedure for ordering
Start
with leftmost digit as first
position
 Before increasing the order in the
first position, select the lowest digit in
the second position
 Continue the process till the lowest
digit in the last position is captured
 Increase the order in the last position
until all the digits in the last position are
captured
 Move back to the last but one position
and repeat the process
 Continue advancing to the first
position until all the numbers are
ordered

Tree structure for the above process
Numerical
Order
1
2
3
9
15
22
34
115
126
250
321
1118
2509
Lexicographic
order
1
1118
115
126
15
2
22
250
2509
3
321
34
9
Lexicographic Ordring- example
start
1
1.1
1.1.5
1.1.18
1.2
1.2.6
2
2.2
2.10
2.10.9
3
3.4
3.21
9
end
1
2
2
1
5
2
18
6
3
10
4
9
21
9
MIB example of lexicographic ordering
GetNextRequest PDU
Agent
Process
Manager
Process
A
GetRequest ( A )
GetResponse ( A )
B
GetNextRequest ( A )
GetResponse ( B )
GetNextRequest ( B )
T.E.1.1 is next
object to scalar B
T
GetResponse ( T.E.1.1 )
GetNextRequest (T.E.1.1 )
GetResponse ( T.E.1.2 )
E
GetNextRequest (T.E.1.2 )
GetResponse ( T.E.2.1 )
GetNextRequest (T.E.2.1 )
GetResponse ( T.E.2.2 )
T.E.1.1
T.E.2.1
T.E.3.1
T.E.1.2
T.E.2.2
T.E.3.2
GetNextRequest (T.E.2.2 )
GetResponse ( T.E.3.1 )
GetNextRequest (T.E.3.1 )
GetResponse ( T.E.3.2 )
GetNextRequest (T.E.3.2 )
Z
GetResponse ( Z )
GetNextRequest ( Z )
GetResponse ( noSuchName )
GetNextRequest PDU
Agent
Process
Manager
Process
GetRequest ( A )
GetResponse ( A )
GetNextRequest ( A )
Advantages of Get-NextRequest
GetResponse ( B )
GetNextRequest ( B )
GetResponse ( T.E.1.1 )
GetNextRequest (T.E.1.1 )
GetResponse ( T.E.1.2 )
GetNextRequest (T.E.1.2 )
GetResponse ( T.E.2.1 )
GetNextRequest (T.E.2.1 )
GetResponse ( T.E.2.2 )
GetNextRequest (T.E.2.2 )
GetResponse ( T.E.3.1 )
GetNextRequest (T.E.3.1 )
GetResponse ( T.E.3.2 )
GetNextRequest (T.E.3.2 )
GetResponse ( Z )
GetNextRequest ( Z )
GetResponse ( noSuchName )
1)- no need to know the
object ID of the next entity
to retrieve its value
2)- issues with dynamic table
resolved
3)- allows NMS to discover
the structure of a MIB view
dynamically
4)- provides an efficient
mechanism for searching a
table whose entries are
unknown
Lexicographic Ordring- example
ipRouteDest
ipRouteMetric1
9.1.2.3
10.0.0.51
10.0.0.99
3
5
5
Index of table
ipRouteNextHop
99.0.0.3
89.1.1.42
89.1.1.42
ipRouteTable
1.3.6.1.2.1.4.21
ipRouteEntry
1.3.6.1.2.1.4.21.1 = x
ipRouteDest
x.1
ipRouteMetric1
x.3
ipRouteNextHop
x.7
ipRouteDest.9.1.2.3
x.1.9.1.2.3
ipRouteMetric1.9.1.2.3
x.3.9.1.2.3
ipRouteDest.10.0.0.51
x.1.10.0.0.51
ipRouteMetric1.10.0.0.51
x.3.10.0.0.51
ipRouteNextHop.10.0.0.51
x.7.10.0.0.51
ipRouteMetric1.10.0.0.99
x.3.10.0.0.99
ipRouteNextHop.10.0.0.99
x.7.10.0.0.99
ipRouteDest.10.0.0.99
x.1.10.0.0.99
ipRouteNextHop.9.1.2.3
x.7.9.1.2.3
Accessing Table Values
ipRouteDest
9.1.2.3
10.0.0.51
10.0.0.99
ipRouteMetric1
3
5
5
ipRouteNextHop
99.0.0.3
89.1.1.42
89.1.1.42
Retrieving the entire table w/out knowing its contents or number of
rows:
GetNextRequest (ipRouteDest, ipRouteMetric1, ipRouteNextHop)
 The agent will respond with the values from the first row
GetResponse ((ipRouteDest.9.1.2.3 = 9.1.2.3),
(ipRouteMetric1.9.1.2.3 = 3),
(ipRouteNextHop.9.1.2.3 = 99.0.0.3))
 The MS stores this info and retrieves the second row
Accessing Table Values
ipRouteDest
9.1.2.3
10.0.0.51
10.0.0.99
ipRouteMetric1
3
5
5
ipRouteNextHop
99.0.0.3
89.1.1.42
89.1.1.42
GetNextRequest (ipRouteDest.9.1.2.3, ipRouteMetric1.9.1.2.3,
ipRouteNextHop.9.1.2.3)
------------------------------------------GetResponse ((ipRouteDest.10.0.0.51 = 10.0.0.51),
(ipRouteMetric1.10.0.0.51 = 5),
(ipRouteNextHop.10.0.0.51 = 89.1.1.42))
--------------------------------------------------------------------GetNextRequest (ipRouteDest.10.0.0.51, ipRouteMetric1.10.0.0.51,
ipRouteNextHop.10.0.0.51)
------------------------------------------GetResponse ((ipRouteDest.10.0.0.99 = 10.0.0.99),
(ipRouteMetric1.10.0.0.99 = 5),
(ipRouteNextHop.10.0.0.99 = 89.1.1.42))
Accessing Table Values
ipRouteDest
9.1.2.3
10.0.0.51
10.0.0.99
ipRouteMetric1
3
5
5
ipRouteNextHop
99.0.0.3
89.1.1.42
89.1.1.42
What happens next!, When does the MS stop?
GetNextRequest (ipRouteDest.10.0.0.99, ipRouteMetric1.10.0.0.99,
ipRouteNextHop.10.0.0.99)
------------------------------------------GetResponse ((ipRouteMetric1.9.1.2.3 = 3),
(ipRouteNextHop.9.1.2.3 = 99.0.0.3),
(ipNetToMediaIfIndex.1.3 = 1))
Object names in the list in the response does not match those in the request
 MS knows it has reached the end of the table
SetRequest-PDU
 Write a value rather than reading a variable
 The operation is atomic:
o
either all variables in binding list are updated or none
Procedure receive-SetRequest:
begin
if object not available for set then
issue getresponse (noSuchName, index)
else if inconsistent object value then
issue getresponse (badValue, index)
else if generated PDU too big then
issue getresponse (tooBig)
else if value not settable for some other reason then
issue getresponse (genErr, index)
else issue getresponse (variable bindings)
end;
SetRequest-PDU-example
ipRouteDest
9.1.2.3
10.0.0.51
10.0.0.99
ipRouteMetric1
3
5
5
ipRouteNextHop
99.0.0.3
89.1.1.42
89.1.1.42
Updating the value of ipRouteMetric1 metric of the first row:
SetRequest (ipRouteMetric1.9.1.2.3 = 9)
GetResponse (ipRouteMetric1.9.1.2.3 = 9)
Index of the new
object instance in
the table
Adding a row to the table -- a MS issues a command:
SetRequest ((ipRouteDest.11.3.3.12 = 11.3.3.12),
(ipRouteMetric1.11.3.3.12 = 9),
(ipRouteNextHop.11.3.3.12 = 91.0.0.5))
But this is currently
unknown for the agent!
SetRequest-PDU-example
Adding a row to the table -- a MS issues a command:
SetRequest ((ipRouteDest.11.3.3.12 = 11.3.3.12),
(ipRouteMetric1.11.3.3.12 = 9),
(ipRouteNextHop.11.3.3.12 = 91.0.0.5))
Three ways for the agent to handle the request:
If only this argument is passed,
the agent may accept or not;
1)- reject the operation with error-status =then
noSuchName
if it accepts to create the row,
2)- recognize the operation (as creation of a new
and objects
check are
whether
thenrow)
the other
assigned
default
values
the operation can be accepted (i.e., all values
are correct,
no syntax
error, etc..)
2.1)- if NO, then return error-status = badValue
2.2)- if YES, then new row is created and
GetResponse ((ipRouteDest.11.3.3.12 = 11.3.3.12),
(ipRouteMetric1.11.3.3.12 = 9),
(ipRouteNextHop.11.3.3.12 = 91.0.0.5))
SetRequest-PDU-example
Row Deletion:
SetRequest (ipRouteMetric1.7.3.5.3 = invalid)
GetResponse (ipRouteMetric1. 7.3.5.3 = invalid)
Some other tables may/may not allow any operation to be done on its
columnar objects – check RFCs for more details
Performing an action:
SNMP can read and set values of objects. SNMP can also issue
commands to perform certain actions: example, a device may have a
flag “reBoot”, if it is set by the manager, then the device will reboot.
SNMP Group
snmp
(mib-2 11)
snmpInPkts(1)
snmpOutPkts (2)
snmpInBadVersions (3)
snmpInCommunityNames (4)
snmpInBadCommunityUses (5)
snmpInASNParseErrors (6)
-- not used (7)
snmpInTooBigs (8)
snmpInNoSuchNames (9)
snmpInBadValues (10)
snmpInReadOnlys (11)
snmpInGenErrs (12)
snmpInTotalReqVars (13)
snmpInTotalSetVars (14)
snmpInGetRequests (15)
snmpEnableAuthenTraps (30)
snmpOutTraps (29)
snmpOutGetResponses (28)
snmpOutSetRequests (27)
snmpOutGetNexts (26)
snmpOutGetRequests (25)
snmpOutGenErrs (24)
-- not used (23)
snmpOutBadValues (22)
snmpOutNoSuchNames (21)
snmpOutTooBigs (20)
snmpInTraps (19)
snmpInGetResponses
(18)
snmpInSetRequests (17)
snmpInGetNexts (16)
SNMP Network Management
 SNMP Protocol Specs
 SNMP Operations
 GetRequest-PDU
 GetNextRequest-PDU
 SetRequest-PDU
 GetResponse-PDU
 Trap-PDU
 Polling
Frequency
limitations of SNMP v1
 SNMPv2
and
Polling Frequency
Few traps exist in the standard!
Thus most of the management information is gathered by
means of polls (GetRequest, GetNextRequest)
o
If polling is done un-frequently
A MS may have outdated view of the network (e.g., congestion
might happen and the NM may not be alerted)
o
If polling is done frequently
The control messages overhead will be high and degrade the
performance
o
Polling frequency requires some policy definition
o
e.g., size of the network (i.e., #agents a MS can handle)
Polling Frequency
Assumption: assume the MS can handle only one agent at a time (i.e.,
when polling an agent, a MS does no other work until it is done)
A poll may involve a single get/response transaction or multiple such
transactions
The maximum number of agents a MS can handle, considering that it
is engaged full time in polling is:
N  (T/)
Agent 1
Agent N
Agent 2
N: number of agents

T: desired polling interval
: average time required to perform a single poll
T
Agent 1
Polling Frequency
 depends on multiple factors:
Processing time to generate a request at the MS
o Network delay from MS to agent
o Processing time at the agent to interpret the received message
o Processing time at the agent to generate response
o Network delay from agent to manager
o Processing time at the manager to interpret the message
o Number of request/response transactions to obtain all desired info.
o
Example
oDevices
on a LAN; each device is to be polled every 15 minutes
oProcessing times = 50ms;
oNetwork delay = 1ms (no network congestion)
N  (1560/) = 4,500
Where  = 50 + 1+ 50+ 50+ 1+ 50 = 202 ms
Polling Frequency
In WAN,
0.5s)
network delays are significantly large (order of
oData
rates on WANs are less than LANs
oDistances are greater (delays are higher, e.g. 0.5 seconds)
oDelays introduced by bridges and routers
N  (1560/) = 750
Where  = (4 0.05) + (20.5)
Summary: 4 critical parameters
o# agents
oProcessing time of a message
oNetwork delays
oPolling interval
Some Limitations of SNMPv1
SNMP may not be suitable for the mgmt of truly large networks because of
the performance limitations of polling
SNMP is not well suited for retrieving large volumes of data, such as an
entire routing table
SNMP traps are unacknowledged & may not be delivered
SNMP provides only trivial authentication
oi.e.
it is suitable for monitoring rather than control
SNMP does not support explicit actions
oi.e.,
an action is taken by changing a parameter or setting an object value
(indirectly)
SNMP does not support manager-to-manager communications
Many of these problems are addressed in SNMPv2!
SNMP Network Management
 SNMP Protocol Specs
 SNMP Operations
 GetRequest-PDU
 GetNextRequest-PDU
 SetRequest-PDU
 GetResponse-PDU
 Trap-PDU
 Polling
Frequency
limitations of SNMP v1
 SNMPv2
and
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
(1)
mgmt
(2)
experimental
(3)
private
(4)
SNMPv2 Internet Group
security
(5)
snmpv2
(6)
SNMP
SNMP
PDU
Physical Medium
SNMP
SNMP
PDU
Physical Medium
SNMP
UDP
UDP
UDP
IP
IP
IP
DLC
DLC
DLC
PHY
PHY
PHY
snmpV2-trap
response
set-request
Application
PDU
get-bulk-request
SNMP Manager
get-next-request
SNMP Manager
Application
get-request
snmpV2-trap
response
set-request
Application
PDU
get-bulk-request
SNMP Manager
get-next-request
get-request
SNMP Manager
Application
inform-request
snmpV2-trap
response
set-request
get-bulk-request
get-next-request
get-request
inform-request
SNMPv2 System Architecture
SNMP Agent
SNMP Agent
Application
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
Report
not used
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
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 (UTCTime)
"DESCRIPTION" Text
-- uses the NVT ASCII character set
Text ::= """" string """"
END
isiMIBModule
MODULE-IDENTITY
LAST-UPDATED "9802101100Z"
ORGANIZATION "InfoTech Services Inc."
CONTACT-INFO
"John P Smith
Tele: 770-111-1111
Fax: 770-111-2222
email: [email protected]"
DESCRIPTION
" Version 1.1 of the InfoTech
Services MIB module"
Revision
"9709021500Z"
DESCRIPTION
"Revision 1.0 on September 2, 1997
was a draft version"
:: {enterprises.isi 1}
MODULE-IDENTITY Macro
Example of MODULE-IDENTITY Macro
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!)
•

OBJECT-TYPE macro defines the type of a managed object (e.g., a
specific router type)
•

The object itself is not managed
Focuses on the details of implementation
NOTE:
• OBJECT-IDENTITY is high level description
• OBJECT-TYPE details description needed for implementation
Object Definitions, example
isiRouter OBJECT-IDENTIFIER ::= {private.entreprises.isi 2}
isiRouter OBJECT-IDENTITY
STATUS
current
DESCRIPTION
"An 8-slot IP router in the IP router
family."
REFERENCE "ISI Memorandum No. ISI-R123 dated
January. 20, 1997"
::= {private.enterprises.isi 2}
Example of OBJECT-IDENTITY Macro
routerIsi123 OBJECT-TYPE
SYNTAX
DisplayString
MAX-ACCESS read-only
STATUS
current
DESCRIPTION
"An 8-slot IP router that can
switch up to 100 million packets
per second."
::= {isiRouter 1}
Example of OBJECT-IDENTITY Macro
NOTE: A specific instance of
routerIsi123 could be identified
by its IP address 10.1.2.3
Table Definition
Static Tables
oTables
completely controlled by the agent. Access is read-only, and
read-write
oThese 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
oAllows
row creation/deletion by a manager
oAccess includes also read, write and create privileges
oA table can be initialized with no rows and expanded as needed
SNMPv2: Augmentation of a table (dependent table)
oAdds
additional columns to an existing table (base table)
oNumber of rows is not affected
oINDEX of the second table is the same as the first table
oOne to one correspondence between rows of two tables
Augmentation of Tables
Base table
Table 2
Table 1
table1
(T1)
table 2
(T2)
table1Entry
(E1)
table2Entry
(E2)
Augmented table
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
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
Example
Columnar object:T2.E2.C4
Index: T1.E1.C1.2
Value: T2.E2.C4.2
Augmentation of Tables
table1 OBJECT-TYPE
SYNTAX
SEQUENCE OF table1Entry
MAX-ACCESS not-accessible
STATUS
current
DESCRIPTION “Table 1 under T”
::= {table 1}
table2 OBJECT-TYPE
SYNTAX
SEQUENCE OF table2Entry
MAX-ACCESS not-accessible
STATUS
current
DESCRIPTION “Table 2 under T”
::= {table 2}
table1Entry OBJECT-TYPE
SYNTAX
Table1Entry
MAX-ACCESS not-accessible
STATUS
current
DESCRIPTION “An entry (conceptual row) in
Table 1”
INDEX {T1.E1.C1}
::= {table1 1}
table2Entry OBJECT-TYPE --Conceptual row extension
SYNTAX
Table2Entry
MAX-ACCESS not-accessible
STATUS
current
DESCRIPTION “An entry (conceptual row)
in Table 2”
AUGMENTS {table1Entry}
::= {table2 1}
Example: a vendor can easily specify
A clause used to increase the number of
vendor-specific objects as extensions
columns in a table w/out rewriting the
to standard MIB table. It should be
table definition
easier for applications to access
these objects than if they were
The resulting table is therefore treated the same way
defined as new, separate 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
RowStatus Textual Convention
State
EnumerDescription
ation
active
1
Row exists and is operational
notInService
2
Operation on the row is suspended
notReady
3
Row does not have all the columnar objects
needed
createAndGo
4
This is a one-step process of creation of a
row; immediately goes into active state
createAndWait
5
Row is under creation and should not be
commissioned into service
destroy
6
Same as Invalid in EntryStatus. Row should
be deleted
Used by manager for
row creation/deletion
Used by agent to send
responses to a manager
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
Process
Agent
Process
SetRequest (
status.3 = 4,
index.3 = 3,
data.3 = DefData )
Response (
status.3 = 1,
index.3 = 3,
data.3 = DefData )
Managed
Entity
Create Instance
Instance Created
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
Process
Agent responds with “notReady”
(no default value)
Agent
Process
SetRequest (
status.3 = 5,
index.3 = 3 )
Response (
status.3 = 3,
index.3 = 3 )
GetRequest (
data.3 )
Data value is missing
Value of data is sent
Response (
status.3 = 2
data.3 = DefData )
SetRequest (
status.3 = 1 )
Row activated
Get the data for the row
Response (
data.3 = noSuchInstance)
SetRequest (
data.3 = DefData )
Agent responds with
notInServcie
Create and wait, no default
data specified
Response (
status.3 = 1 )
Manager requests to activate
the row
Row Deletion
Manager
Process
Agent
Process
SetRequest (
status.3 = 6 )
Response (
status.3 = 6 )
Managed
Entity
Delete Instance
Instance Deleted
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

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
SNMPv2
-- declared as having
-- SIZE (0..255)
DisplayString ::= TEXTUAL-CONVENTION
SNMPv1
A string of up to 255 characters
(refer to table 6.2 for more rules)
DISPLAY-HINT
"255a"
STATUS
current
DESCRIPTION
"Represents textual
information taken from the NVT
ASCII character set, as defined in
pages 4, 10-11 of RFC 854. …."
SYNTAX
OCTET STRING (SIZE (0..255) )
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
format
PDU
Type
RequestID
improvement is that trap message has the same
Error
Error
Status
Index
VarBind 1 VarBind 1
name
value
...
VarBind n VarBind n
name
value
SNMPv2 PDU
Indicate the type of PDU
(e.g., Request-PDY, etc)
Indicate the status of the error
(e.g., noError, tooBig, etc.)
identifies the first variable binding
in the variable-binding list that
caused the error
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
Values for Types of PDU and Error-status Fields
in SNMPv2 PDU
Field
PDU
Error Status
Type
0
1
2
3
4
5
6
7
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Value
Get-Request-PDU
GetNextRequest-PDU
Response-PDU
Set-Request- PDU
obsolete
GetBulkRequest-- PDU
InformRequest- PDU
SNMPv2 - Trap- PDU
noError
tooBig
noSuchName
badValue
readOnly
genErr
noAccess
wrongType
wrongLength
wrongEncoding
wrongValue
noCreation
inconsistentValue
resourceUnavailable
commitFailed
undoFailed
authorizationError
notWritable
inconsistentName
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
Type
RequestID
Non-
Max
Repeaters Repetitions
VarBind 1 VarBind 1
name
value
...
VarBind n VarBind n
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
requested
indicates the number of non repetitive (scalar) field values
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
B
Z
T
E
E
1.1
2.1
3.1
1.2
2.2
3.2
1.3
1.4
2.3
2.4
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
T.E.1.4
T.E.2.4
T.E.3.4
3.3
3.4
Z
GetBulkRequest-PDU Operation
Manager
Process
GetRequest ( A,B )
GetResponse (A,B)
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)
Agent
Process
GetBulkRequest-PDU Operation
A
2 non repetitive objects (A, B)
Manager
Process
3 repetitive instances
Of the columnar object
T.E.1, T.E.2, T.E.3
B
Agent
Process
T
GetBulkRequest ( 2,3,
A,B,T.E.1, T.E.2, T.E.3 )
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 )
E
3 more rows
GetBulkRequest ( 0,3,
T.E.1.3, T.E.2.3, T.E.3.3 )
Response ( T.E.1.4, T.E.2.4, T.E.3.4, Z , " endOfMibView")
Z is next in the lexicographic order
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
T.E.1.4
T.E.2.4
T.E.3.4
Z
GetBulkRequest-PDU Operation
Manager
Process
Agent
Process
GetBulkRequest ( 1,3,
sysUpTime,
atPhysAddress )
Response( (sysUpTime.0 = "315131795"),
(atPhysAddress.13.172.46.46.1 = "0000000C3920AC")
(atPhysAddress.16.172.46.49.1 = "0000000C3920AF")
(atPhysAddress.23.172.17.3.1 = "0000000C3920B4") )
GetBulkRequest ( 1,3,
sysUpTime,
atPhysAddress.23.192.168.3.1 )
atIfIndex
23
13
16
Response( (sysUpTime.0 = "315131800"),
(ipForwarding.0 = "1") )
Figure 6.42 Get-Bulk-Request Example
atPhysAddress
0000000C3920B4
0000000C3920AC
0000000C3920AF
atNetAddress
192.68.3.1
172.46.46.1
172.46.49.1
SNMPv2 Trap PDU
PDU
Type
RequestID
Error
Status
VarBind1 VarBind1 VarBind2 VarBind 2
...
Index sysUpTime value snmpTrapOID value
Error
linkUp NOTIFICATION-TYPE
OBJECTS { ifIndex}
STATUS current
DESCRIPTION "A linkUp trap signifies that the SNMPv2 entity,
acting in an agent role, recognizes that one of the communication
links has come up.“
::= { snmpTraps 4 }
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
oThe
receiving manager sends response to the sending manager
SNMPv2- Decentralized
management
Agent
Element manager
SNMPv2
MIB
agent
Management server
SNMPv2
Manager/agent
MIB
Management Applications
SNMPv2
MIB
agent
SNMPv2
manager
MIB
SNMPv2
Manager/agent
MIB
SNMPv2
MIB
agent
SNMPv2 Configuration
Compatibility with SNMPv1
 SNMPv2 MIB is not backward compatible with SNMPv1
 Compatibility with SNMPv1  2 evolution paths:
Bilingual Manager
o Proxy Server
 Bilingual Manager expensive in resource and operation
o
Agent
Profile
Bilingual Manager
SNMPv1
Interpreter
SNMPv1
Agents
SNMPv2
Interpreter
SNMPv2
Agents
SNMP Bilingual Manager
Both interpreters are required!
SNMP Proxy Server
SNMPv2 Manager
Proxy
Server
SNMPv1
Agents
SNMPv2 Manager
GetRequest
GetNextRequest
SetRequest
GetBulkRequest
SNMPv2
Agents
SNMP v2-v1 Proxy Server
SNMPv1 Agent
Pass-Through
GetRequest
Pass-Through
GetNextRequest
Pass-Through
Set: 1. non-repeaters = 0
2. max-repetitions = 0
SetRequest
GetNextRequest
Pass-Through
Response
SNMPv2-Trap
Exception: For 'tooBig' error, contents of variable-bindings
field removed .
Prepend VarBind: 1. sysUpTime.0
2. snmpTrapOID.0
SNMP v2-v1 Proxy Server
GetResponse
Trap