Download - SNMPv1 (cont’d) & SNMPv2 (II) *
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 and limitations of SNMP v1
SNMPv2
Communication Model
MANAGER
AGENTS
SNMP Polling
MIB
Trap
Communication Model
Communicate mgnt information between network mgnt stations and managed elements
Goals:o Management functions maintained by agents are
kept simpleo Protocol flexibility (addition of new aspects of
operation and management)o Transparency (should not be affected by the
architecture of particular hosts and gateways) Operation: 5 messages
o get-request, get-next request, set-requesto get-response, trap
SNMP messages are exchanged using UDP (connection less) transport protocol
Communication Model
SNMP ManagerApplication
Get
-Res
po
nse
Get
-Req
ue
st
Get
Ne
xt-R
equ
est
Set
-Re
que
st
Tra
p
SNMP Manager
SNMP Manager
UDP
IP
DLC
PHY
SNMP AgentApplication
Get
-Res
po
nse
Tra
p
SNMP Agent
SNMP agent
UDP
IP
DLC
PHY
Physical Medium
Manage-mentData
Get
-Req
ue
st
Get
Ne
xt-R
equ
est
Set
-Re
que
st
Network or Internet
ApplicationManages objects
SNMP messages
Message Format
Protocol entities support application entities
Communication between remote peer processes Message consists of :
o Version identifiero Community name
Protocol Data Unit Message encapsulated in
UDP datagrams and transmitted Loss of message time out!
version community 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
3 different versions: SNMPv1, SNMPv2, SNMPv3
Message Format
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}
version community data
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
request-id
error-status
variable-bindingserror-index
PDU-type
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}
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
name value
var-bind 1
name value
var-bind 2
name value
var-bind n
. . .
VarBindList ::= SEQUENCE OF VarBind
VarBind ::= SEQUENCE { name ObjectName, value ObjectSyntax}
ObjectName ::= OBJECT IDENTIFIER
ObjectSyntax ::= CHOICE { simple SimpleSyntax, application-wide ApplicationSyntax}
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
Trap-PDU ::= SEQUENCE { enterprise OBJECT IDENTIFIER, agent-addr NetworkAddress, generic-trap INTEGER { coldStart (0), warmStart (1), linkDown (2), linkUp (3), authenticationFailure(4), egpNeighborLoss (5),
enterpriseSpecific (6) }, specific-trap INTEGER, time-stamp TimeTicks, variable-bindings VarBindList}
EntrepriseAgent
Address variable-bindingsGeneric
Trap TypePDU-type
SpecificTrap Type
TimeStamp
-Pertain to the system generating the trap (sysObjectID)-IP address of the objetc
Elapsed time since last re-initialization
Specific code to identify the trap cause…
SNMP Network Management
SNMP Protocol Specs SNMP Operations
GetRequest-PDU GetNextRequest-PDU SetRequest-PDU GetResponse-PDU Trap-PDU
Polling Frequency and limitations of SNMP v1
SNMPv2
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 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 its OBJECT-IDENTIFIER concatenated with 0 e.g., sysDescr.0:
distinguishes between the object type and an instance of the object
sysServices (7)
sysLocation (6)
sysDescr (1)
system(mib-2 1)
sysObjectId(2)
sysUpTime (3) sysName (5)
sysContact (4)
GetRequest PDU
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)
ManagerProcess
AgentProcess
.0 indicates that the scalar value should be retrieved (scalar objects only)
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
error message is generated if at least one of the variables could not be found/returned; error-status: noSuchName tooBig genErr
error-index: indicate the problem object (i.e., variable in binding list that caused the problem)
With SNMP, only leaf objects in the MIB can be retrieved 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
GetRequest (ipRouteDest.9.1.2.3, ipRouteMetric1.9.1.2.3, ipRouteNextHop. 9.1.2.3 )
ipRouteDest ipRouteMetric1 ipRouteNextHop
9.1.2.3 3 99.0.0.310.0.0.51 5 89.1.1.4210.0.0.99 5 89.1.1.42
Index of table
GetNextRequest PDU
PDU format: 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
sysServices (7)
sysLocation (6)
sysDescr (1)
system(mib-2 1)
sysObjectId(2)
sysUpTime (3) sysName (5)
sysContact (4)
Error message: no object next to sysServices
GetNextRequest PDU
GetRequest (sysDescr.0)
GetResponse (sysDescr .0= "SunOS" )
GetNextRequest (sysDescr.0)
GetResponse ( sysObjectID.0=enterprises.11.2.3.10.1.2 )
Get-Next-Request Operation for System Group
ManagerProcess
AgentProcess
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)
Generalized Case
T ZA B
1.1
E
2.1 3.1
1.2 2.2 3.2
A sample MIB that contains both scalar values and aggregate objects
Retrieving scalar as well aggregate objects using get-request and get-next-request
Generalized Case
T.E.1.1 T.E.2.1 T.E.3.1
T.E.1.2 T.E.2.2 T.E.3.2
E
T
Z
A
B
GetRequest ( A )
GetResponse ( A )
GetRequest ( B )
GetResponse ( B )
GetRequest (T.E.1.1)
GetResponse ( T.E.1.1 )
GetRequest (T.E.1.2)
GetResponse ( T.E.1.2 )
GetRequest (T.E.2.1)
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 )
ManagerProcess
AgentProcess
Generalized Case
T.E.1.1 T.E.2.1 T.E.3.1
T.E.1.2 T.E.2.2 T.E.3.2
E
T
Z
A
B
Observations:
1)- we need to know all the elements in the MIB, including the # of columns and rows in a table
2)- a MIB is traversed from top to bottom (i.e., from left to right in the tree structure)
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
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
Lexicographic Convention
Procedure for orderingStart 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
Lexicographic order
1 1 2 1118 3 115 9 126 15 15 22 2 34 22 115 250 126 2509 250 3 321 321 1118 34 2509 9
Lexicographic Ordring- example
3 91 2
18
1
5
2
6
2 10
9
214
start end1 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
MIB example of lexicographic ordering
T.E.1.1 is next object to scalar B
GetNextRequest PDU
T.E.1.1 T.E.2.1 T.E.3.1
T.E.1.2 T.E.2.2 T.E.3.2
E
T
Z
A
B
GetRequest ( A )
GetResponse ( A )
GetNextRequest ( A )
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 )
ManagerProcess
AgentProcess
GetNextRequest PDU
GetRequest ( A )
GetResponse ( A )
GetNextRequest ( A )
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 )
ManagerProcess
AgentProcess
Advantages of Get-Next-Request
1)- no need to know the object ID of the next entity to retrieve its value2)- 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 ipRouteNextHop
9.1.2.3 3 99.0.0.310.0.0.51 5 89.1.1.4210.0.0.99 5 89.1.1.42
ipRouteTable1.3.6.1.2.1.4.21
ipRouteEntry1.3.6.1.2.1.4.21.1 = x
ipRouteDestx.1
ipRouteMetric1x.3
ipRouteNextHopx.7
ipRouteDest.9.1.2.3x.1.9.1.2.3
ipRouteDest.10.0.0.51 x.1.10.0.0.51
ipRouteDest.10.0.0.99x.1.10.0.0.99
ipRouteMetric1.9.1.2.3x.3.9.1.2.3
ipRouteMetric1.10.0.0.51x.3.10.0.0.51
ipRouteMetric1.10.0.0.99x.3.10.0.0.99
ipRouteNextHop.9.1.2.3x.7.9.1.2.3
ipRouteNextHop.10.0.0.51x.7.10.0.0.51
ipRouteNextHop.10.0.0.99x.7.10.0.0.99
Index of table
Accessing Table Values
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
ipRouteDest ipRouteMetric1 ipRouteNextHop
9.1.2.3 3 99.0.0.310.0.0.51 5 89.1.1.4210.0.0.99 5 89.1.1.42
Accessing Table Values
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))
ipRouteDest ipRouteMetric1 ipRouteNextHop
9.1.2.3 3 99.0.0.310.0.0.51 5 89.1.1.4210.0.0.99 5 89.1.1.42
Accessing Table Values
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))
ipRouteDest ipRouteMetric1 ipRouteNextHop
9.1.2.3 3 99.0.0.310.0.0.51 5 89.1.1.4210.0.0.99 5 89.1.1.42
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
Updating the value of ipRouteMetric1 metric of the first row:SetRequest (ipRouteMetric1.9.1.2.3 = 9)
GetResponse (ipRouteMetric1.9.1.2.3 = 9)
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))
ipRouteDest ipRouteMetric1 ipRouteNextHop
9.1.2.3 3 99.0.0.310.0.0.51 5 89.1.1.4210.0.0.99 5 89.1.1.42
Index of the new object instance in the table
But this is currently unknown for the agent!
Three ways for the agent to handle the request:1)- reject the operation with error-status = noSuchName2)- recognize the operation (as creation of a new row) and check
whether the operation can be accepted (i.e., all values are correct, no syntax error, etc..)2.1)- if NO, then return error-status = badValue2.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))
If only this argument is passed, then the agent may accept or not; if it accepts to create the row, then the other objects are assigned default values
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))
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 Groupsnmp
(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)
snmpEnableAuthenTraps (30)
snmpOutTraps (29)
snmpOutGetResponses (28)
snmpOutSetRequests (27)
snmpOutGetNexts (26)
snmpOutGetRequests (25)
snmpOutGenErrs (24)
-- not used (23)
snmpOutBadValues (22)
snmpOutNoSuchNames (21)
snmpOutTooBigs (20)
snmpInGenErrs (12)
snmpInTotalReqVars (13)
snmpInTotalSetVars (14)
snmpInGetRequests (15)
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 and limitations of SNMP v1
SNMPv2
Few traps exist in the standard!o Thus most of the management information is gathered by means of polls (GetRequest, GetNextRequest)
If polling is done un-frequentlyo A MS may have outdated view of the network (e.g., congestion might happen and the NM may not be alerted)
If polling is done frequentlyo The control messages overhead will be high and degrade the performance
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 transactionsThe maximum number of agents a MS can handle, considering that it is engaged full time in polling is: N (T/)
N: number of agentsT: desired polling interval: average time required to perform a single poll
Polling Frequency
T
Agent 1Agent 2 Agent 1
Agent N
depends on multiple factors:o Processing time to generate a request at the MS o Network delay from MS to agento Processing time at the agent to interpret the received messageo Processing time at the agent to generate response o Network delay from agent to managero Processing time at the manager to interpret the message o Number of request/response transactions to obtain all desired info.
ExampleoDevices on a LAN; each device is to be polled every 15 minutesoProcessing times = 50ms; oNetwork delay = 1ms (no network congestion)
N (1560/) = 4,500 Where = 50 + 1+ 50+ 50+ 1+ 50 = 202 ms
Polling Frequency
In WAN, network delays are significantly large (order of 0.5s)
oData rates on WANs are less than LANsoDistances are greater (delays are higher, e.g. 0.5 seconds)oDelays introduced by bridges and routers
N (1560/) = 750 Where = (4 0.05) + (20.5)
Summary: 4 critical parameterso# agentsoProcessing time of a messageoNetwork delaysoPolling interval
Polling Frequency
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 actionsoi.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!
Some Limitations of SNMPv1
SNMP Network Management
SNMP Protocol Specs SNMP Operations
GetRequest-PDU GetNextRequest-PDU SetRequest-PDU GetResponse-PDU Trap-PDU
Polling Frequency and limitations of SNMP v1
SNMPv2
Bulk data transferRequest and receive bulk data using the get-bulk message
Manager-to-manager messageEnhances interoperability and allows for managing large distributed networks
Enhancements to SMI: SMIv2Module definitions: MODULE-IDENTITY macroObject definitions: OBJECT-TYPE macro (same as before)Trap definitions: NOTIFICATION-TYPE macro
Textual conventions: define new data typesConformance statements
Help customers compare features of various productsKeeps vendors open to their product’s compatibility with SNMP
Major Changes
Row creation and deletion in tableA table can also be expanded by augmenting another table
MIB enhancementsTwo new subgroups: security and snmpV2
Transport mappingsUDP remains the preferred transport protocol; however, other protocols can also be used with SNMPv2
Security features, originally to be in SNMPv2 moved to SNMPv3SNMPv2 is community-based administrative framework
Major Changes
SNMPv2
mgmt(2)
directory(1)
experimental(3)
private(4)
Internet{1 3 6 1}
security(5)
snmpv2(6)
SNMPv2 Internet Group
SNMPv2 System Architecture
SNMP ManagerApplication
resp
on
se
ge
t-b
ulk
-re
qu
est
ge
t-n
ext
-re
qu
est
set-
req
ues
t
snm
pV
2-tr
ap
SNMP Manager
SNMP
UDP
IP
DLC
PHY
Physical Medium
SNMP PDU
ge
t-re
qu
est
info
rm-r
eq
ue
st
SNMP AgentApplication
resp
on
se
ge
t-b
ulk
-re
qu
est
ge
t-n
ext
-re
qu
est
set-
req
ues
t
snm
pV
2-tr
ap
SNMP Agent
SNMP
UDP
IP
DLC
PHY
ge
t-re
qu
est
SNMP ManagerApplication
resp
on
se
ge
t-b
ulk
-re
qu
est
ge
t-n
ext
-re
qu
est
set-
req
ues
t
snm
pV
2-tr
ap
SNMP Manager
SNMP
UDP
IP
DLC
PHY
ge
t-re
qu
est
info
rm-r
eq
ue
st
SNMP PDU
ApplicationPDU
Physical Medium
ApplicationPDU
inform-requestmanager-to-manager messageThe receiving manager responds with a response messageEnhances interoperability
get-bulk-request transfer of large data, e.g. retrieval of table data
Reportnot used
SNMPv2-trapSimilar to trap messages in SNMPv1
Additional Messages
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}
Example of MODULE-IDENTITY Macro
SMIv2- Modules DefinitionsDefines 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
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!)• 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 Definitions, example
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
isiRouter OBJECT-IDENTIFIER ::= {private.entreprises.isi 2}
NOTE: A specific instance of routerIsi123 could be identified by its IP address 10.1.2.3
Table DefinitionStatic Tables
oTables completely controlled by the agent. Access is read-only, and read-writeoThese are useful when the number of rows corresponds to a fixed attribute (e.g., # physical interfaces) or a quantity controlled only by agent
Dynamic TableoAllows row creation/deletion by a manageroAccess includes also read, write and create privilegesoA 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 affectedoINDEX of the second table is the same as the first tableoOne to one correspondence between rows of two tables
Augmentation of Tables
T1.E1.C1.1
table1(T1)
table1Entry(E1)
T1.E1.C2.1 T1.E1.C3.1
T1.E1.C1.2 T1.E1.C2.2 T1.E1.C3.2
T1.E1.C1.3 T1.E1.C2.3 T1.E1.C3.3
T1.E1.C1.4 T1.E1.C2.4 T.E1.C3.4
table 2(T2)
table2Entry(E2)
T2.E2.C4.1 T2.E2.C5.1
T2.E2.C4.2 T2.E2.C5.2
T2.E2.C4.3 T2.E2.C5.3
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
Table 1 Table 2Base table Augmented table
ExampleColumnar object:T2.E2.C4Index: T1.E1.C1.2Value: 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} 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}
table2 OBJECT-TYPE SYNTAX SEQUENCE OF table2Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION “Table 2 under T” ::= {table 2} table2Entry OBJECT-TYPE SYNTAX Table2Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION “An entry (conceptual row) in Table 2” AUGMENTS {table1Entry} ::= {table2 1}
--Conceptual row extension
A clause used to increase the number of columns in a table w/out rewriting the table definition
The resulting table is therefore treated the same way as if it was defined in a single table definition
Example: a vendor can easily specify vendor-specific objects as extensions to standard MIB table. It should be easier for applications to access these objects than if they were defined as new, separate table
Row Creation
A new feature in SMIv22 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 Enumer-ation
Description
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
2 states for RowStatus: createAndGo, createAndWait
Row to be created/deleted
entry1
status.1
table1
index.1 data.1
status.2
status.3
index.2
index.3
data.2
data.3
Create and Go
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
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
Create and WaitManagerProcess
AgentProcess
SetRequest (status.3 = 5,index.3 = 3 ) Create and wait, no default
data specifiedResponse (status.3 = 3,index.3 = 3 )
Agent responds with “notReady”(no default value)
GetRequest (data.3 )
Get the data for the row
Response (data.3 = noSuchInstance)Data value is missing
SetRequest (data.3 = DefData ) Value of data is sent
Response (status.3 = 2data.3 = DefData )
Agent responds with notInServcie
SetRequest (status.3 = 1 ) Manager requests to activate
the rowResponse (status.3 = 1 )Row activated
Row Deletion
SetRequest (status.3 = 6 )
Response (status.3 = 6 )
ManagerProcess
AgentProcess
ManagedEntity
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 rowsDisplayString ::= OCTET STRING-- This data type is used to model textual informationtaken from the NVT-- ASCII character set. By convention, objects with thissyntax are-- declared as having-- SIZE (0..255) DisplayString ::= TEXTUAL-CONVENTION
DISPLAY-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) )
SNMPv1
SNMPv2
A string of up to 255 characters(refer to table 6.2 for more rules)
Textual Conventions-MacroTEXTUAL-CONVENTION MACRO ::=BEGIN
TYPE NOTATION ::=DisplayPart"STATUS" Status"DESCRIPTION" TextReferPart"SYNTAX" SyntaxVALUE NOTATION ::= value(VALUE Syntax)DisplayPart ::= "DISPLAY-HINT" Text | emptyStatus ::= "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- exampleRowStatus ::= TEXTUAL-CONVENTION
STATUS currentDESCRIPTION "The RowStatus textual convention is used to manage the …”SYNTAX INTEGER {
-- the following two values are states:-- these values may be read or writtenactive(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 readcreateAndGo(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
SNMPv2 PDU
PDUType
RequestID ErrorStatus
ErrorIndex
VarBind 1
nameVarBind 1
value...
VarBind n
nameVarBind n
value
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 ProtocolValues for Types of PDU and Error-status Fields
in SNMPv2 PDU
Field Type Value PDU 0 Get-Request-PDU 1 GetNextRequest-PDU 2 Response-PDU 3 Set-Request- PDU 4 obsolete 5 GetBulkRequest-- PDU 6 InformRequest- PDU 7 SNMPv2 - Trap- PDU Error Status 0 noError 1 tooBig 2 noSuchName 3 badValue 4 readOnly 5 genErr 6 noAccess 7 wrongType 8 wrongLength 9 wrongEncoding 10 wrongValue 11 noCreation 12 inconsistentValue 13 resourceUnavailable 14 commitFailed 15 undoFailed 16 authorizationError 17 notWritable 18 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
GetBulkRequest enables the retrieval of data in bulkUses 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-repeatersNon-repeaters indicates the number of non repetitive (scalar) field values requested
Error index field replaced by Max repetitionsMax repetitions designates the maximum number of table rows requested to be returned in the response messageNOTE 1: value depends on the size of the SNMP message and buffer size in implementationNOTE 2: no one to one relationship between the VarBindList of request and response messages
SNMPv2 GetBulkRequest PDU
PDUType
RequestID Non-Repeaters
MaxRepetitions
VarBind 1
nameVarBind 1
value...
VarBind n
nameVarBind n
value
GetBulkRequest-PDU Operation
T ZA B
1.1
E
1.2
1.3
1.4
2.1
2.2
2.3
2.4
3.1
3.2
3.3
3.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
E
T
Z
A
B
T.E.1.3 T.E.2.3 T.E.3.3
T.E.1.4 T.E.2.4 T.E.3.4
GetBulkRequest-PDU Operation
GetRequest ( 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)
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)
GetResponse (T.E.2.1,T.E.3.1,Z)
Manager
Process
Agent
ProcessGetResponse (A,B)
GetNextRequest (T.E.1.4,T.E.2.4,T.E.3.4)
GetNextRequest (T.E.1.2,T.E.2.2,T.E.3.2)
GetBulkRequest-PDU Operation
T.E.1.1 T.E.2.1 T.E.3.1
T.E.1.2 T.E.2.2 T.E.3.2
E
T
Z
A
B
T.E.1.3 T.E.2.3 T.E.3.3
T.E.1.4 T.E.2.4 T.E.3.4
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.1T.E.1.2, T.E.2.2, T.E.3.2
T.E.1.3, T.E.2.3, T.E.3.3 )
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")
ManagerProcess
AgentProcess
2 non repetitive objects (A, B)
3 repetitive instances Of the columnar objectT.E.1, T.E.2, T.E.3
3 more rows
Z is next in the lexicographic order
GetBulkRequest-PDU Operation
atIfIndex231316
atPhysAddress0000000C3920B40000000C3920AC0000000C3920AF
atNetAddress192.68.3.1
172.46.46.1172.46.49.1
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") )
Figure 6.42 Get-Bulk-Request Example
GetBulkRequest ( 1,3,sysUpTime,
atPhysAddress.23.192.168.3.1 )
Response( (sysUpTime.0 = "315131800"),(ipForwarding.0 = "1") )
ManagerProcess
AgentProcess
SNMPv2 Trap PDU
Addition of NOTIFICATION-TYPE macroPositions 1 and 2 in VarBindList are sysUpTime and snmpTrapOIDInform-Request behaves as trap in that the message goes from one manager to another unsolicited
oThe receiving manager sends response to the sending manager
PDUType
RequestID ErrorStatus
ErrorIndex
VarBind1sysUpTime
VarBind1
valueVarBind2snmpTrapOID
VarBind 2
value...
linkUp NOTIFI CATI ON-TYPE OBJ ECTS { ifI ndex} STATUS current DESCRI PTION "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 }
SNMPv2- Decentralized management
MIBSNMPv2agent
MIBSNMPv2agent
MIBSNMPv2agent
MIB
SNMPv2Manager/agent
MIB
SNMPv2Manager/agent
MIB
Management Applications
SNMPv2 manager
Management server
Element manager
Agent
SNMPv2 Configuration
Compatibility with SNMPv1
SNMPv2 MIB is not backward compatible with SNMPv1 Compatibility with SNMPv1 2 evolution paths:
o Bilingual Managero Proxy Server
Bilingual Manager expensive in resource and operation
SNMPv1Agents
Bilingual Manager
SNMPv1Interpreter
SNMPv2Interpreter
AgentProfile
SNMPv2Agents
SNMP Bilingual Manager
Both interpreters are required!
SNMP Proxy Server
SNMPv1Agents
SNMPv2 Manager
ProxyServer
SNMPv2Agents
Pass-Through
Pass-Through
SNMPv2 Manager SNMPv1 Agent
GetNextRequest
GetRequest
Pass-ThroughSetRequest
Set: 1. non-repeaters = 0 2. max-repetitions = 0
GetBulkRequest
Pass-ThroughException: For 'tooBig' error, contents of variable-bindings
field removed .Response
Prepend VarBind: 1. sysUpTime.0 2. snmpTrapOID.0
SNMPv2-Trap
GetRequest
GetResponse
GetNextRequest
SetRequest
GetNextRequest
Trap
SNMP v2-v1 Proxy Server
SNMP v2-v1 Proxy Server