📄 rfc1157.txt
字号:
GetResponse (( ipRouteDest.10.0.0.99 = "10.0.0.99" ),
( ipRouteNextHop.10.0.0.99 = "89.1.1.42" ),
( ipRouteMetric1.10.0.0.99 = 5 ))
The management station continues with:
GetNextRequest ( ipRouteDest.10.0.0.99,
ipRouteNextHop.10.0.0.99,
ipRouteMetric1.10.0.0.99 )
As there are no further entries in the table, the SNMP agent returns
those objects that are next in the lexicographical ordering of the
known object names. This response signals the end of the routing
table to the management station.
4.1.4. The GetResponse-PDU
The form of the GetResponse-PDU is identical to that of the
GetRequest-PDU except for the indication of the PDU type. In the
ASN.1 language:
GetResponse-PDU ::=
[2]
IMPLICIT SEQUENCE {
request-id
RequestID,
Case, Fedor, Schoffstall, & Davin [Page 24]
RFC 1157 SNMP May 1990
error-status
ErrorStatus,
error-index
ErrorIndex,
variable-bindings
VarBindList
}
The GetResponse-PDU is generated by a protocol entity only upon
receipt of the GetRequest-PDU, GetNextRequest-PDU, or SetRequest-PDU,
as described elsewhere in this document.
Upon receipt of the GetResponse-PDU, the receiving protocol entity
presents its contents to its SNMP application entity.
4.1.5. The SetRequest-PDU
The form of the SetRequest-PDU is identical to that of the
GetRequest-PDU except for the indication of the PDU type. In the
ASN.1 language:
SetRequest-PDU ::=
[3]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status -- always 0
ErrorStatus,
error-index -- always 0
ErrorIndex,
variable-bindings
VarBindList
}
The SetRequest-PDU is generated by a protocol entity only at the
request of its SNMP application entity.
Upon receipt of the SetRequest-PDU, the receiving entity responds
according to any applicable rule in the list below:
(1) If, for any object named in the variable-bindings field,
Case, Fedor, Schoffstall, & Davin [Page 25]
RFC 1157 SNMP May 1990
the object is not available for set 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, for any object named in the variable-bindings field,
the contents of the value field does not, according to
the ASN.1 language, manifest a type, length, and value
that is consistent with that required for the variable,
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
badValue, and the value of the error-index field is the
index of said object name in the received message.
(3) If the size of the Get Response type message 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 named object cannot be altered 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 for each object named in
the variable-bindings field of the received message, the
corresponding value is assigned to the variable. Each variable
assignment specified by the SetRequest-PDU should be effected as if
simultaneously set with respect to all other assignments specified in
the same message.
The receiving entity then sends to the originator of the received
message the GetResponse-PDU of identical form except that the value
of the error-status field of the generated message is noError and the
value of the error-index field is zero.
Case, Fedor, Schoffstall, & Davin [Page 26]
RFC 1157 SNMP May 1990
4.1.6. The Trap-PDU
The form of the Trap-PDU is:
Trap-PDU ::=
[4]
IMPLICIT SEQUENCE {
enterprise -- type of object generating
-- trap, see sysObjectID in [5]
OBJECT IDENTIFIER,
agent-addr -- address of object generating
NetworkAddress, -- trap
generic-trap -- generic trap type
INTEGER {
coldStart(0),
warmStart(1),
linkDown(2),
linkUp(3),
authenticationFailure(4),
egpNeighborLoss(5),
enterpriseSpecific(6)
},
specific-trap -- specific code, present even
INTEGER, -- if generic-trap is not
-- enterpriseSpecific
time-stamp -- time elapsed between the last
TimeTicks, -- (re)initialization of the network
-- entity and the generation of the
trap
variable-bindings -- "interesting" information
VarBindList
}
The Trap-PDU is generated by a protocol entity only at the request of
the SNMP application entity. The means by which an SNMP application
entity selects the destination addresses of the SNMP application
entities is implementation-specific.
Upon receipt of the Trap-PDU, the receiving protocol entity presents
its contents to its SNMP application entity.
Case, Fedor, Schoffstall, & Davin [Page 27]
RFC 1157 SNMP May 1990
The significance of the variable-bindings component of the Trap-PDU
is implementation-specific.
Interpretations of the value of the generic-trap field are:
4.1.6.1. The coldStart Trap
A coldStart(0) trap signifies that the sending protocol entity is
reinitializing itself such that the agent's configuration or the
protocol entity implementation may be altered.
4.1.6.2. The warmStart Trap
A warmStart(1) trap signifies that the sending protocol entity is
reinitializing itself such that neither the agent configuration nor
the protocol entity implementation is altered.
4.1.6.3. The linkDown Trap
A linkDown(2) trap signifies that the sending protocol entity
recognizes a failure in one of the communication links represented in
the agent's configuration.
The Trap-PDU of type linkDown contains as the first element of its
variable-bindings, the name and value of the ifIndex instance for the
affected interface.
4.1.6.4. The linkUp Trap
A linkUp(3) trap signifies that the sending protocol entity
recognizes that one of the communication links represented in the
agent's configuration has come up.
The Trap-PDU of type linkUp contains as the first element of its
variable-bindings, the name and value of the ifIndex instance for the
affected interface.
4.1.6.5. The authenticationFailure Trap
An authenticationFailure(4) trap signifies that the sending protocol
entity is the addressee of a protocol message that is not properly
authenticated. While implementations of the SNMP must be capable of
generating this trap, they must also be capable of suppressing the
emission of such traps via an implementation-specific mechanism.
4.1.6.6. The egpNeighborLoss Trap
An egpNeighborLoss(5) trap signifies that an EGP neighbor for whom
Case, Fedor, Schoffstall, & Davin [Page 28]
RFC 1157 SNMP May 1990
the sending protocol entity was an EGP peer has been marked down and
the peer relationship no longer obtains.
The Trap-PDU of type egpNeighborLoss contains as the first element of
its variable-bindings, the name and value of the egpNeighAddr
instance for the affected neighbor.
4.1.6.7. The enterpriseSpecific Trap
A enterpriseSpecific(6) trap signifies that the sending protocol
entity recognizes that some enterprise-specific event has occurred.
The specific-trap field identifies the particular trap which
occurred.
Case, Fedor, Schoffstall, & Davin [Page 29]
RFC 1157 SNMP May 1990
5. Definitions
RFC1157-SNMP DEFINITIONS ::= BEGIN
IMPORTS
Object⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -