📄 rfc1157.txt
字号:
authentication scheme. This entity returns another ASN.1
object, or signals an authentication failure. In the
latter case, the protocol entity notes this failure,
(possibly) generates a trap, and discards the datagram
and performs no further actions.
(4) The protocol entity then performs a rudimentary parse on
the ASN.1 object returned from the authentication service
to build an ASN.1 object corresponding to an ASN.1 PDUs
object. If the parse fails, it discards the datagram and
performs no further actions. Otherwise, using the named
SNMP community, the appropriate profile is selected, and
the PDU is processed accordingly. If, as a result of
this processing, a message is returned then the source
transport address that the response message is sent from
shall be identical to the destination transport address
that the original request message was sent to.
Case, Fedor, Schoffstall, & Davin [Page 18]
RFC 1157 SNMP May 1990
4.1.1. Common Constructs
Before introducing the six PDU types of the protocol, it is
appropriate to consider some of the ASN.1 constructs used frequently:
-- request/response information
RequestID ::=
INTEGER
ErrorStatus ::=
INTEGER {
noError(0),
tooBig(1),
noSuchName(2),
badValue(3),
readOnly(4)
genErr(5)
}
ErrorIndex ::=
INTEGER
-- variable bindings
VarBind ::=
SEQUENCE {
name
ObjectName,
value
ObjectSyntax
}
VarBindList ::=
SEQUENCE OF
VarBind
RequestIDs are used to distinguish among outstanding requests. By
use of the RequestID, an SNMP application entity can correlate
incoming responses with outstanding requests. In cases where an
unreliable datagram service is being used, the RequestID also
provides a simple means of identifying messages duplicated by the
network.
A non-zero instance of ErrorStatus is used to indicate that an
Case, Fedor, Schoffstall, & Davin [Page 19]
RFC 1157 SNMP May 1990
exception occurred while processing a request. In these cases,
ErrorIndex may provide additional information by indicating which
variable in a list caused the exception.
The term variable refers to an instance of a managed object. A
variable binding, or VarBind, refers to the pairing of the name of a
variable to the variable's value. A VarBindList is a simple list of
variable names and corresponding values. Some PDUs are concerned
only with the name of a variable and not its value (e.g., the
GetRequest-PDU). In this case, the value portion of the binding is
ignored by the protocol entity. However, the value portion must
still have valid ASN.1 syntax and encoding. It is recommended that
the ASN.1 value NULL be used for the value portion of such bindings.
4.1.2. The GetRequest-PDU
The form of the GetRequest-PDU is:
GetRequest-PDU ::=
[0]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status -- always 0
ErrorStatus,
error-index -- always 0
ErrorIndex,
variable-bindings
VarBindList
}
The GetRequest-PDU is generated by a protocol entity only at the
request of its SNMP application entity.
Upon receipt of the GetRequest-PDU, the receiving protocol entity
responds according to any applicable rule in the list below:
(1) If, for any object named in the variable-bindings field,
the object's name does not exactly match the name of some
object available for get operations in the relevant MIB
view, then the receiving entity sends to the originator
of the received message the GetResponse-PDU of identical
form, except that the value of the error-status field is
noSuchName, and the value of the error-index field is the
index of said object name component in the received
Case, Fedor, Schoffstall, & Davin [Page 20]
RFC 1157 SNMP May 1990
message.
(2) If, for any object named in the variable-bindings field,
the object is an aggregate type (as defined in the SMI),
then the receiving entity sends to the originator of the
received message the GetResponse-PDU of identical form,
except that the value of the error-status field is
noSuchName, and the value of the error-index field is the
index of said object name component in the received
message.
(3) If the size of the GetResponse-PDU generated as described
below would exceed a local limitation, then the receiving
entity sends to the originator of the received message
the GetResponse-PDU of identical form, except that the
value of the error-status field is tooBig, and the value
of the error-index field is zero.
(4) If, for any object named in the variable-bindings field,
the value of the object cannot be retrieved for reasons
not covered by any of the foregoing rules, then the
receiving entity sends to the originator of the received
message the GetResponse-PDU of identical form, except
that the value of the error-status field is genErr and
the value of the error-index field is the index of said
object name component in the received message.
If none of the foregoing rules apply, then the receiving protocol
entity sends to the originator of the received message the
GetResponse-PDU such that, for each object named in the variable-
bindings field of the received message, the corresponding component
of the GetResponse-PDU represents the name and value of that
variable. The value of the error- status field of the GetResponse-
PDU is noError and the value of the error-index field is zero. The
value of the request-id field of the GetResponse-PDU is that of the
received message.
4.1.3. The GetNextRequest-PDU
The form of the GetNextRequest-PDU is identical to that of the
GetRequest-PDU except for the indication of the PDU type. In the
ASN.1 language:
GetNextRequest-PDU ::=
[1]
IMPLICIT SEQUENCE {
request-id
RequestID,
Case, Fedor, Schoffstall, & Davin [Page 21]
RFC 1157 SNMP May 1990
error-status -- always 0
ErrorStatus,
error-index -- always 0
ErrorIndex,
variable-bindings
VarBindList
}
The GetNextRequest-PDU is generated by a protocol entity only at the
request of its SNMP application entity.
Upon receipt of the GetNextRequest-PDU, the receiving protocol entity
responds according to any applicable rule in the list below:
(1) If, for any object name in the variable-bindings field,
that name does not lexicographically precede the name of
some object available for get operations in the relevant
MIB view, then the receiving entity sends to the
originator of the received message the GetResponse-PDU of
identical form, except that the value of the error-status
field is noSuchName, and the value of the error-index
field is the index of said object name component in the
received message.
(2) If the size of the GetResponse-PDU generated as described
below would exceed a local limitation, then the receiving
entity sends to the originator of the received message
the GetResponse-PDU of identical form, except that the
value of the error-status field is tooBig, and the value
of the error-index field is zero.
(3) If, for any object named in the variable-bindings field,
the value of the lexicographical successor to the named
object cannot be retrieved for reasons not covered by any
of the foregoing rules, then the receiving entity sends
to the originator of the received message the
GetResponse-PDU of identical form, except that the value
of the error-status field is genErr and the value of the
error-index field is the index of said object name
component in the received message.
If none of the foregoing rules apply, then the receiving protocol
entity sends to the originator of the received message the
GetResponse-PDU such that, for each name in the variable-bindings
field of the received message, the corresponding component of the
Case, Fedor, Schoffstall, & Davin [Page 22]
RFC 1157 SNMP May 1990
GetResponse-PDU represents the name and value of that object whose
name is, in the lexicographical ordering of the names of all objects
available for get operations in the relevant MIB view, together with
the value of the name field of the given component, the immediate
successor to that value. The value of the error-status field of the
GetResponse-PDU is noError and the value of the errorindex field is
zero. The value of the request-id field of the GetResponse-PDU is
that of the received message.
4.1.3.1. Example of Table Traversal
One important use of the GetNextRequest-PDU is the traversal of
conceptual tables of information within the MIB. The semantics of
this type of SNMP message, together with the protocol-specific
mechanisms for identifying individual instances of object types in
the MIB, affords access to related objects in the MIB as if they
enjoyed a tabular organization.
By the SNMP exchange sketched below, an SNMP application entity might
extract the destination address and next hop gateway for each entry
in the routing table of a particular network element. Suppose that
this routing table has three entries:
Destination NextHop Metric
10.0.0.99 89.1.1.42 5
9.1.2.3 99.0.0.3 3
10.0.0.51 89.1.1.42 5
The management station sends to the SNMP agent a GetNextRequest-PDU
containing the indicated OBJECT IDENTIFIER values as the requested
variable names:
GetNextRequest ( ipRouteDest, ipRouteNextHop, ipRouteMetric1 )
The SNMP agent responds with a GetResponse-PDU:
GetResponse (( ipRouteDest.9.1.2.3 = "9.1.2.3" ),
( ipRouteNextHop.9.1.2.3 = "99.0.0.3" ),
( ipRouteMetric1.9.1.2.3 = 3 ))
The management station continues with:
GetNextRequest ( ipRouteDest.9.1.2.3,
ipRouteNextHop.9.1.2.3,
Case, Fedor, Schoffstall, & Davin [Page 23]
RFC 1157 SNMP May 1990
ipRouteMetric1.9.1.2.3 )
The SNMP agent responds:
GetResponse (( ipRouteDest.10.0.0.51 = "10.0.0.51" ),
( ipRouteNextHop.10.0.0.51 = "89.1.1.42" ),
( ipRouteMetric1.10.0.0.51 = 5 ))
The management station continues with:
GetNextRequest ( ipRouteDest.10.0.0.51,
ipRouteNextHop.10.0.0.51,
ipRouteMetric1.10.0.0.51 )
The SNMP agent responds:
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -