RFC 1905
Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)
RFC 1905 ✨ Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2) 🎀
okay bestie, the title block is giving everything so here's the tea 🫶
- Number: RFC 1905 💖
- Working group: SNMPv2 Working Group, under the Network Working Group 🌸
- Authors: J. Case (SNMP Research, Inc.), K. McCloghrie (Cisco Systems, Inc.), M. Rose (Dover Beach Consulting, Inc.), and S. Waldbusser (International Network Services) 👑
- Category: Standards Track 🦋
- Date: January 1996 📅
- Obsoletes: RFC 1448 💅
- Updates: nothing is listed as updated here 🧚
Status of this Memo 📜
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. 💌
1. Introduction ✨
okay so a management system is basically a little family of parts 🧸. You've got several (potentially many) nodes, and each one has a processing entity called an agent that can get to the management instrumentation 🔧. You also need at least one management station, plus a management protocol that carries management information between the agents and the stations 📨. Everything runs under an administrative framework that defines authentication, authorization, access control, and privacy policies 🔐. no cap, it's a whole system.
Management stations run management applications that monitor and control managed elements. Managed elements are devices like hosts, routers, terminal servers, etc., and they get monitored and controlled through access to their management information 🖥️.
Management information is seen as a collection of managed objects living in a virtual information store called the Management Information Base (MIB) 🗂️. Collections of related objects get defined in MIB modules. These modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [1], which is called the Structure of Management Information (SMI) [2] 💜.
The management protocol, version 2 of the Simple Network Management Protocol, handles the exchange of messages that carry management information between agents and management stations 💬. The shape of these messages is a message "wrapper" that encapsulates a Protocol Data Unit (PDU) 🎁. The form and meaning of the "wrapper" is determined by an administrative framework, which defines both authentication and authorization policies 🛡️.
This document, Protocol Operations for SNMPv2, is here to define the operations of the protocol with respect to sending and receiving the PDUs. This is the main event 🎬✨.
1.1. A Note on Terminology 🏷️
For the sake of exposition, the original Internet-standard Network Management Framework is called the SNMP version 1 framework (SNMPv1). It's described in RFCs 1155 (STD 16), 1157 (STD 15), and 1212 (STD 16). The current framework is called the SNMP version 2 framework (SNMPv2). Easy peasy 🌈.
2. Overview 🔭
2.1. Roles of Protocol Entities 🎭
A SNMPv2 entity may operate in a manager role or an agent role. Think of it like a costume change 👗.
A SNMPv2 entity acts in an agent role when it performs SNMPv2 management operations in response to received SNMPv2 protocol messages (other than an inform notification), or when it sends trap notifications 🔔.
A SNMPv2 entity acts in a manager role when it starts SNMPv2 management operations by generating SNMPv2 protocol messages, or when it performs SNMPv2 management operations in response to received trap or inform notifications 🧑💼.
A SNMPv2 entity may support either or both roles, depending on its implementation and configuration. It can also act as a proxy agent 🪞. In that case it looks like it's acting in an agent role, but it satisfies management requests by acting in a manager role with a remote entity. the way that's so iconic 😭.
2.2. Management Information 📚
The term "variable" refers to an instance of a non-aggregate object type, defined according to the conventions set forth in the SMI [2] or the textual conventions based on the SMI [3]. The term "variable binding" usually refers to the pairing of the name of a variable and its associated value 💕. However, if certain kinds of exceptional conditions happen while a retrieval request is being processed, a variable binding will pair a name with an indication of that exception 🚨.
A variable-binding list is a simple list of variable bindings 📝.
The name of a variable is an OBJECT IDENTIFIER made by concatenating the OBJECT IDENTIFIER of the corresponding object-type with an OBJECT IDENTIFIER fragment that identifies the instance. The OBJECT IDENTIFIER of the corresponding object-type is called the OBJECT IDENTIFIER prefix of the variable 🧩✨.
2.3. Access to Management Information 🚪
There are three types of access to management information provided by the protocol 🔑.
The first type is a request-response interaction. A SNMPv2 entity acting in a manager role sends a request to a SNMPv2 entity acting in an agent role, and the agent-role entity then responds to the request. This type is used to retrieve or modify management information associated with the managed device 🖲️.
The second type is also a request-response interaction. A SNMPv2 entity acting in a manager role sends a request to a SNMPv2 entity that is also acting in a manager role, and the latter entity then responds. This type is used to notify a manager-role entity of management information associated with another entity that is also acting in a manager role 🤝.
The third type is an unconfirmed interaction. A SNMPv2 entity acting in an agent role sends an unsolicited message, called a trap, to a SNMPv2 entity acting in a manager role, and no response is returned 📣. This type is used to notify a manager-role entity of an exceptional situation that has resulted in changes to management information associated with the managed device 🚩.
2.4. Retransmission of Requests 🔁
For all types of request in this protocol, the receiver is required under normal circumstances to generate and transmit a response to the originator of the request 📬. Whether or not a request should be retransmitted when no corresponding response arrives in an appropriate time interval is up to the application that originated the request 🕰️. This will normally depend on how urgent the request is. Still, such an application needs to act responsibly about the frequency and duration of re-transmissions 🙏.
2.5. Message Sizes 📏
The maximum size of a SNMPv2 message is limited to the minimum of:
(1) the maximum message size which the destination SNMPv2 entity can accept; and,
(2) the maximum message size which the source SNMPv2 entity can generate.
The former may be known on a per-recipient basis. If that's not known, it's indicated by the transport domain used when sending the message 🗺️. The latter is imposed by implementation-specific local constraints 🛠️.
Each transport mapping for SNMPv2 indicates the minimum message size that a SNMPv2 implementation must be able to produce or consume. Implementations are encouraged to support larger values whenever possible, but a conformant implementation must never generate messages larger than allowed by the receiving SNMPv2 entity 🫧.
One of the aims of the GetBulkRequest-PDU, specified in this protocol, is to minimize the number of protocol exchanges required to retrieve a large amount of management information 🎯. So this PDU type lets a SNMPv2 entity acting in a manager role ask that the response be as large as possible, given the constraints on message sizes. Those constraints include the limits on the size of messages that the agent-role entity can generate, and the size of messages that the manager-role entity can receive 📦.
However, such maximum sized messages may be larger than the Path MTU of the path across the network that the messages travel. When that happens, the messages are subject to fragmentation. Fragmentation is generally considered to be harmful [4], since among other problems, it leads to a decrease in the reliability of message transfer 💔. Thus, a SNMPv2 entity that sends a GetBulkRequest-PDU must take care to set its parameters accordingly, so as to reduce the risk of fragmentation 🧐. In particular, under conditions of network stress, only small values should be used for max-repetitions 🐢.
Bestie, this is the part to remember: when the network is stressed, keep max-repetitions small so your big responses don't get fragmented 🚨.
2.6. Transport Mappings 🚚
It is important to note that exchanging SNMPv2 messages requires only an unreliable datagram service, with every message being entirely and independently contained in a single transport datagram 📮. Specific transport mappings and encoding rules are specified elsewhere [5]. However, the preferred mapping is the use of the User Datagram Protocol [6] 💖.
3. Definitions 🎀
okay so here's the big ASN.1 module, the official dictionary for all the SNMPv2 PDUs 📖💅
SNMPv2-PDU DEFINITIONS ::= BEGIN
IMPORTS
ObjectName, ObjectSyntax, Integer32
FROM SNMPv2-SMI;
-- protocol data units
PDUs ::=
CHOICE {
get-request
GetRequest-PDU,
get-next-request
GetNextRequest-PDU,
get-bulk-request
GetBulkRequest-PDU,
response
Response-PDU,
set-request
SetRequest-PDU,
inform-request
InformRequest-PDU,
snmpV2-trap
SNMPv2-Trap-PDU,
report
Report-PDU,
}
-- PDUs
GetRequest-PDU ::=
[0]
IMPLICIT PDU
GetNextRequest-PDU ::=
[1]
IMPLICIT PDU
Response-PDU ::=
[2]
IMPLICIT PDU
SetRequest-PDU ::=
[3]
IMPLICIT PDU
-- [4] is obsolete
GetBulkRequest-PDU ::=
[5]
IMPLICIT BulkPDU
InformRequest-PDU ::=
[6]
IMPLICIT PDU
SNMPv2-Trap-PDU ::=
[7]
IMPLICIT PDU
-- Usage and precise semantics of Report-PDU are not presently
-- defined. Any SNMP administrative framework making use of
-- this PDU must define its usage and semantics.
Report-PDU ::=
[8]
IMPLICIT PDU
max-bindings
INTEGER ::= 2147483647
PDU ::=
SEQUENCE {
request-id
Integer32,
error-status -- sometimes ignored
INTEGER {
noError(0),
tooBig(1),
noSuchName(2), -- for proxy compatibility
badValue(3), -- for proxy compatibility
readOnly(4), -- for proxy compatibility
genErr(5),
noAccess(6),
wrongType(7),
wrongLength(8),
wrongEncoding(9),
wrongValue(10),
noCreation(11),
inconsistentValue(12),
resourceUnavailable(13),
commitFailed(14),
undoFailed(15),
authorizationError(16),
notWritable(17),
inconsistentName(18)
},
error-index -- sometimes ignored
INTEGER (0..max-bindings),
variable-bindings -- values are sometimes ignored
VarBindList
}
BulkPDU ::= -- MUST be identical in
SEQUENCE { -- structure to PDU
request-id
Integer32,
non-repeaters
INTEGER (0..max-bindings),
max-repetitions
INTEGER (0..max-bindings),
variable-bindings -- values are ignored
VarBindList
}
-- variable binding
VarBind ::=
SEQUENCE {
name
ObjectName,
CHOICE {
value
ObjectSyntax,
unSpecified -- in retrieval requests
NULL,
-- exceptions in responses
noSuchObject[0]
IMPLICIT NULL,
noSuchInstance[1]
IMPLICIT NULL,
endOfMibView[2]
IMPLICIT NULL
}
}
-- variable-binding list
VarBindList ::=
SEQUENCE (SIZE (0..max-bindings)) OF
VarBind
END4. Protocol Specification ✨
4.1. Common Constructs 💖
okay bestie, the request-id field in a Response-PDU takes the exact same value as the request-id in the request it's answering 🫶 that's how a SNMPv2 app keeps track of all the (possibly many) outstanding requests and matches each incoming response to the right one. over an unreliable datagram service, the request-id also helps spot messages the network duplicated, which is so smart 🧠
if you retransmit a request with the same request-id, then the response to either the original or the retransmission can satisfy it. BUT to calculate the round trip time for a request-response transaction, the app needs to use a different request-id on a retransmitted request. the latter strategy is recommended for use in the majority of situations 💅
a non-zero error-status in a Response-PDU means an exception happened and stopped the request from being processed 😭 when that happens, a non-zero error-index tells you which variable binding in the list caused it. each variable binding is identified by its index value. the first variable binding in a variable-binding list is index one, the second is index two, and so on 🌸
SNMPv2 limits OBJECT IDENTIFIER values to a maximum of 128 sub-identifiers, where each sub-identifier has a maximum value of 2**32-1 🔢
4.2. PDU Processing 🦋
it is mandatory that all SNMPv2 entities acting in an agent role can generate these PDU types: Response-PDU and SNMPv2-Trap-PDU. they also must be able to receive these: GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, and SetRequest-PDU 🧚
it is mandatory that all SNMPv2 entities acting in a manager role can generate these PDU types: GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU, InformRequest-PDU, and Response-PDU. they must also be able to receive these: Response-PDU, SNMPv2-Trap-PDU, InformRequest-PDU 👑
in the elements of procedure below, any field of a PDU that the relevant procedure doesn't reference gets ignored by the receiving SNMPv2 entity. BUT every component of a PDU, even the ones whose values get ignored, must have valid ASN.1 syntax and encoding ⚠️ for example, some PDUs (like the GetRequest-PDU) only care about the name of a variable and not its value. so the value portion of the variable binding gets ignored, and the unSpecified value exists specifically to fill that spot 🙈
when generating a management communication, the message "wrapper" that encapsulates the PDU gets generated by following the "Elements of Procedure" of whatever administrative framework is in use 🎀 the definition of max-bindings does put an upper bound on the number of variable bindings, but in practice a message's size is limited only by the maximum message size constraints. it is NOT limited by the number of variable bindings 🍓
when receiving a management communication, you follow the "Elements of Procedure" of the administrative framework in use. if those procedures say the operation in the message should be performed locally, they also say which MIB view is visible to that operation 👀
4.2.1. The GetRequest-PDU 🌈
a GetRequest-PDU gets generated and transmitted whenever a SNMPv2 application asks for it 💌
when a receiving SNMPv2 entity gets a GetRequest-PDU, it processes each variable binding in the variable-binding list to produce a Response-PDU. every field of that Response-PDU has the same values as the matching fields of the received request, except for the stuff listed below. each variable binding gets processed like this:
(1) if the variable binding's name exactly matches the name of a variable accessible by this request, then the variable binding's value field gets set to the value of that named variable ✅
(2) otherwise, if the variable binding's name doesn't have an OBJECT IDENTIFIER prefix that exactly matches the OBJECT IDENTIFIER prefix of any (potential) variable accessible by this request, then its value field is set to noSuchObject 🫠
(3) otherwise, the variable binding's value field is set to noSuchInstance 🤷♀️
if processing any variable binding fails for a reason other than the ones listed above, then the Response-PDU is re-formatted. it keeps the same values in its request-id and variable-bindings fields as the received GetRequest-PDU, but its error-status gets set to genErr, and its error-index is set to the index of the failed variable binding 💀
otherwise, the value of the Response-PDU's error-status field is set to noError, and its error-index value is zero 🥰
the generated Response-PDU then gets encapsulated into a message. if the size of that resultant message is less than or equal to BOTH a local constraint AND the maximum message size of the originator, it gets transmitted to the originator of the GetRequest-PDU 🚀
otherwise, an alternate Response-PDU is generated. this one has the same value in its request-id field as the received GetRequest-PDU, its error-status is set to tooBig, its error-index is set to zero, and it has an empty variable-bindings field. this alternate Response-PDU then gets encapsulated into a message. if THAT resultant message is less than or equal to both a local constraint and the maximum message size of the originator, it gets transmitted to the originator of the GetRequest-PDU. otherwise, the snmpSilentDrops [9] counter is incremented and the resultant message is discarded 😤
4.2.2. The GetNextRequest-PDU 💜
a GetNextRequest-PDU gets generated and transmitted at the request of a SNMPv2 application, same energy as before 🌷
when a receiving SNMPv2 entity gets a GetNextRequest-PDU, it processes each variable binding in the variable-binding list to produce a Response-PDU. every field of the Response-PDU has the same values as the corresponding fields of the received request, except as noted below. each variable binding gets processed like this:
(1) the variable gets located. it's the one in the lexicographically ordered list of the names of all variables accessible by this request, and its name is the first lexicographic successor of the variable binding's name in the incoming GetNextRequest-PDU. the matching variable binding's name and value fields in the Response-PDU then get set to the name and value of the located variable 🦄
(2) Okay so, if the requested variable binding's name doesn't lexicographically precede the name of any variable accessible by this request, aka there is no lexicographic successor 💀, then the matching variable binding in the Response-PDU gets its value field set to endOfMibView, and its name field set to the variable binding's name from the request. 🦋
If the processing of any variable binding fails for a reason other than the ones listed above, the Response-PDU gets re-formatted. It keeps the same request-id and variable-bindings values as the received GetNextRequest-PDU, its error-status is set to genErr, and its error-index is set to the index of the failed variable binding. 😭 That's the "something broke" energy, bestie.
Otherwise, the Response-PDU's error-status is set to noError and its error-index is zero. ✨
The generated Response-PDU then gets encapsulated into a message. If the size of that message is less than or equal to both a local constraint and the maximum message size of the originator, it gets transmitted to the originator of the GetNextRequest-PDU. 🎀
Otherwise, an alternate Response-PDU is generated. It's formatted with the same request-id as the received GetNextRequest-PDU, its error-status is set to tooBig, its error-index is set to zero, and its variable-bindings field is empty. 🫶 This alternate Response-PDU then gets encapsulated into a message. If that message's size is less than or equal to both a local constraint and the maximum message size of the originator, it gets transmitted to the originator of the GetNextRequest-PDU. Otherwise, the snmpSilentDrops [9] counter is incremented and the resultant message is discarded. 🥀
4.2.2.1. Example of Table Traversal
An important use of the GetNextRequest-PDU is traversing conceptual tables of information within a MIB. 🌸 The semantics of this kind of request, together with the way individual instances of objects in the MIB are identified, gives you access to related objects in the MIB as if they were organized in a table. It's giving spreadsheet energy, honestly. 💅
In the protocol exchange sketched below, a SNMPv2 application retrieves the media-dependent physical address and the address-mapping type for each entry in the IP net-to-media Address Translation Table [7] of a particular network element. It also retrieves the value of sysUpTime [9], at which the mappings existed. Suppose that the agent's IP net-to-media table has three entries:
Interface-Number Network-Address Physical-Address Type
1 10.0.0.51 00:00:10:01:23:45 static
1 9.2.3.4 00:00:10:54:32:10 dynamic
2 10.0.0.15 00:00:10:98:76:54 dynamicThe SNMPv2 entity acting in a manager role begins by sending a GetNextRequest-PDU containing the indicated OBJECT IDENTIFIER values as the requested variable names: 🧚
GetNextRequest ( sysUpTime,
ipNetToMediaPhysAddress,
ipNetToMediaType )The SNMPv2 entity acting in an agent role responds with a Response-PDU: 💖
Response (( sysUpTime.0 = "123456" ),
( ipNetToMediaPhysAddress.1.9.2.3.4 =
"000010543210" ),
( ipNetToMediaType.1.9.2.3.4 = "dynamic" ))The SNMPv2 entity acting in a manager role continues with: 🌈
GetNextRequest ( sysUpTime,
ipNetToMediaPhysAddress.1.9.2.3.4,
ipNetToMediaType.1.9.2.3.4 )The SNMPv2 entity acting in an agent role responds with: ⭐
Response (( sysUpTime.0 = "123461" ),
( ipNetToMediaPhysAddress.1.10.0.0.51 =
"000010012345" ),
( ipNetToMediaType.1.10.0.0.51 = "static" ))The SNMPv2 entity acting in a manager role continues with: 🍓
GetNextRequest ( sysUpTime,
ipNetToMediaPhysAddress.1.10.0.0.51,
ipNetToMediaType.1.10.0.0.51 )The SNMPv2 entity acting in an agent role responds with: 🦋
Response (( sysUpTime.0 = "123466" ),
( ipNetToMediaPhysAddress.2.10.0.0.15 =
"000010987654" ),
( ipNetToMediaType.2.10.0.0.15 = "dynamic" ))The SNMPv2 entity acting in a manager role continues with: 🔥
GetNextRequest ( sysUpTime,
ipNetToMediaPhysAddress.2.10.0.0.15,
ipNetToMediaType.2.10.0.0.15 )Since there are no further entries in the table, the SNMPv2 entity acting in an agent role responds with the variables that come next in the lexicographical ordering of the accessible object names. For example: 👑
Response (( sysUpTime.0 = "123471" ),
( ipNetToMediaNetAddress.1.9.2.3.4 =
"9.2.3.4" ),
( ipRoutingDiscards.0 = "2" ))This response signals the end of the table to the SNMPv2 entity acting in a manager role. 🎀 Table traversal, complete. Periodt. 💅
4.2.3. The GetBulkRequest-PDU
A GetBulkRequest-PDU is generated and transmitted at the request of a SNMPv2 application. 🧚 Its whole purpose is to request the transfer of a potentially large amount of data, including, but not limited to, the efficient and rapid retrieval of large tables. Big data, bestie. 🌊
Upon receipt of a GetBulkRequest-PDU, the receiving SNMPv2 entity processes each variable binding in the variable-binding list to produce a Response-PDU with its request-id field having the same value as in the request. Processing begins by examining the values in the non-repeaters and max-repetitions fields. If the value in the non-repeaters field is less than zero, the value of that field is set to zero. Similarly, if the value in the max-repetitions field is less than zero, the value of that field is set to zero. 🫶
For the GetBulkRequest-PDU type, successfully processing each variable binding in the request generates zero or more variable bindings in the Response-PDU. In other words, the one-to-one mapping between the variable bindings of the GetRequest-PDU, GetNextRequest-PDU, and SetRequest-PDU types and the resulting Response-PDUs does not apply to the mapping between the variable bindings of a GetBulkRequest-PDU and the resulting Response-PDU. 🙈 Plot twist, it's a whole different vibe.
The values of the non-repeaters and max-repetitions fields in the request specify the processing requested. One variable binding in the Response-PDU is requested for each of the first N variable bindings in the request, and M variable bindings are requested for each of the R remaining variable bindings in the request. So the total number of requested variable bindings communicated by the request is given by N + (M * R), where:
- N is the minimum of: a) the value of the non-repeaters field in the request, and b) the number of variable bindings in the request
- M is the value of the max-repetitions field in the request
- R is the maximum of: a) the number of variable bindings in the request minus N, and b) zero
The receiving SNMPv2 entity produces a Response-PDU with up to the total number of requested variable bindings communicated by the request. The request-id shall have the same value as the received GetBulkRequest-PDU. 💜
If N is greater than zero, the first through the (N)-th variable bindings of the Response-PDU are each produced as follows:
(1) The variable is located which is in the lexicographically ordered list of the names of all variables which are accessible by this request and whose name is the first lexicographic successor of the variable binding's name in the incoming GetBulkRequest-PDU. The corresponding variable binding's name and value fields in the Response-PDU are set to the name and value of the located variable. 🌸
(2) If the requested variable binding's name does not lexicographically precede the name of any variable accessible by this request, i.e., there is no lexicographic successor, then the corresponding variable binding produced in the Response-PDU has its value field set to endOfMibView, and its name field set to the variable binding's name in the request. 🥀
If M and R are non-zero, the (N + 1)-th and subsequent variable bindings of the Response-PDU are each produced in a similar manner. For each iteration i, such that i is greater than zero and less than or equal to M, and for each repeated variable, r, such that r is greater than zero and less than or equal to R, the (N + ( (i-1) * R ) + r)-th variable binding of the Response-PDU is produced as follows: 🧚
(1) The variable which is in the lexicographically ordered list of the names of all variables which are accessible by this request and whose name is the (i)-th lexicographic successor of the (N + r)-th variable binding's name in the incoming GetBulkRequest-PDU is located, and the variable binding's name and value fields are set to the name and value of the located variable. ✨
(2) If there is no (i)-th lexicographic successor, then the corresponding variable binding produced in the Response-PDU has its value field set to endOfMibView, and its name field set to either the last lexicographic successor, or, if there are no lexicographic successors, to the (N + r)-th variable binding's name in the request. 💀
While the maximum number of variable bindings in the Response-PDU is bounded by N + (M * R), the response may be generated with a lesser number of variable bindings (possibly zero) for any of three reasons. 🌈
(1) If the size of the message encapsulating the Response-PDU containing the requested number of variable bindings would be greater than either a local constraint or the maximum message size of the originator, then the response is generated with a lesser number of variable bindings. This lesser number is the ordered set of variable bindings with some of the variable bindings at the end of the set removed, such that the size of the message encapsulating the Response-PDU is approximately equal to, but no greater than, either a local constraint or the maximum message size of the originator. Note that the number of variable bindings removed has no relationship to the values of N, M, or R. 🎀
(2) The response may also be generated with a lesser number of variable bindings if, for some value of iteration i, such that i is greater than zero and less than or equal to M, all of the generated variable bindings have the value field set to the endOfMibView. In this case, the variable bindings may be truncated after the (N + (i * R))-th variable binding. 🦋
(3) okay so, if handling a request with a ton of repetitions takes way longer than a normal request would, an agent may stop early with fewer than the full number of repetitions 🐢. The one catch is that at least one repetition has to actually get completed ✨.
If processing any variable binding fails for a reason that isn't listed above, the Response-PDU gets re-formatted 💅. Its request-id and variable-bindings fields keep the same values as the received GetBulkRequest-PDU, its error-status field is set to genErr, and its error-index field points to the index of the variable binding in the original request that matches the failed one 🫶.
Otherwise, the Response-PDU's error-status field is set to noError and its error-index field is set to zero 🌸.
Next, the generated Response-PDU (its variable-bindings field might be empty, and that's totally fine 🧚) gets encapsulated into a message. If the size of that message is less than or equal to both a local constraint and the maximum message size of the originator, it gets sent back to the originator of the GetBulkRequest-PDU 💌. If it's too big, the snmpSilentDrops [9] counter goes up and the message gets discarded 💀.
4.2.3.1. Another Example of Table Traversal 🦋
This example shows how the GetBulkRequest-PDU can work as an alternative to the GetNextRequest-PDU. We're doing the same traversal of the IP net-to-media table from Section 4.2.2.1, but it only takes fewer exchanges 🔥.
The SNMPv2 entity acting in a manager role starts things off by sending a GetBulkRequest-PDU with a modest max-repetitions value of 2. It includes the OBJECT IDENTIFIER values it wants as the requested variable names 🎀:
GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
( sysUpTime,
ipNetToMediaPhysAddress,
ipNetToMediaType )The SNMPv2 entity acting in an agent role responds with a Response-PDU 👑:
Response (( sysUpTime.0 = "123456" ),
( ipNetToMediaPhysAddress.1.9.2.3.4 =
"000010543210" ),
( ipNetToMediaType.1.9.2.3.4 = "dynamic" ),
( ipNetToMediaPhysAddress.1.10.0.0.51 =
"000010012345" ),
( ipNetToMediaType.1.10.0.0.51 = "static" ))The SNMPv2 entity acting in a manager role keeps going with 🏃♀️:
GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
( sysUpTime,
ipNetToMediaPhysAddress.1.10.0.0.51,
ipNetToMediaType.1.10.0.0.51 )The SNMPv2 entity acting in an agent role responds with 😭:
Response (( sysUpTime.0 = "123466" ),
( ipNetToMediaPhysAddress.2.10.0.0.15 =
"000010987654" ),
( ipNetToMediaType.2.10.0.0.15 =
"dynamic" ),
( ipNetToMediaNetAddress.1.9.2.3.4 =
"9.2.3.4" ),
( ipRoutingDiscards.0 = "2" ))This response is how the SNMPv2 entity acting in a manager role finds out the table has ended 🏁✨.
4.2.4. The Response-PDU 🍓
The Response-PDU only gets generated by a SNMPv2 entity when it receives a GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU, or InformRequest-PDU, as described elsewhere in this document 💜.
If the error-status field of the Response-PDU is non-zero, the value fields of the variable bindings in the variable binding list get ignored 🙈.
If both the error-status field and the error-index field of the Response-PDU are non-zero, then the error-index field holds the index of the variable binding (from the variable-binding list of the corresponding request) that failed 😩. Index one is the first variable binding in a request's variable-binding list, index two is the second, and so on 🔢.
A compliant SNMPv2 entity acting in a manager role must be able to properly receive and handle a Response-PDU whose error-status field is equal to noSuchName, badValue, or readOnly 🫶. (See Section 3.1.2 of [8].)
When a Response-PDU comes in, the receiving SNMPv2 entity hands its contents to the SNMPv2 application that made the request, matched up by the same request-id value 🎁.
4.2.5. The SetRequest-PDU 🌈
A SetRequest-PDU gets generated and transmitted when a SNMPv2 application asks for it 💖.
When a SetRequest-PDU comes in, the receiving SNMPv2 entity figures out how big a message would be if it encapsulated a Response-PDU with the same request-id and variable-bindings values as the received SetRequest-PDU. It also looks at the largest possible sizes of the error-status and error-index fields 📏. If that message size is bigger than either a local constraint or the maximum message size of the originator, then an alternate Response-PDU gets generated and sent to the originator of the SetRequest-PDU, and processing of the SetRequest-PDU stops right there 🛑. This alternate Response-PDU uses the same request-id value as the received SetRequest-PDU, its error-status field is set to tooBig, its error-index field is set to zero, and its variable-bindings field is empty 🫧. Then it gets encapsulated into a message. If that message is less than or equal to both a local constraint and the maximum message size of the originator, it's sent to the originator of the SetRequest-PDU. Otherwise, the snmpSilentDrops [9] counter goes up and the message is discarded. Either way, processing of the SetRequest-PDU ends 🏁.
Otherwise, the receiving SNMPv2 entity processes each variable binding in the variable-binding list to produce a Response-PDU. All of the Response-PDU's fields match the corresponding fields of the received request, except where noted below 🎀.
Conceptually, the variable bindings go through a two phase operation. In the first phase, each variable binding gets validated, and if every validation passes, each variable gets altered in the second phase ✨. Implementors are totally free to do either phase, or both, as multiple implementation phases instead, and sometimes that's actually needed to keep everything consistent 🧩.
The following validations happen in the first phase on each variable binding, either until they all succeed or until one fails 🔍:
(1) If the variable binding's name specifies an existing or non-existent variable that this request is or would be denied access to because it is or would not be in the appropriate MIB view, then the Response-PDU's error-status field is set to noAccess, and its error-index field is set to the index of the failed variable binding 🚫.
(2) Otherwise, if there are no variables sharing the same OBJECT IDENTIFIER prefix as the variable binding's name that are able to be created or modified no matter what new value is specified, then the Response-PDU's error-status field is set to notWritable, and its error-index field is set to the index of the failed variable binding 🙅♀️.
(3) Otherwise, if the variable binding's value field specifies, according to the ASN.1 language, a type that is inconsistent with what's required for all variables sharing the same OBJECT IDENTIFIER prefix as the variable binding's name, then the Response-PDU's error-status field is set to wrongType, and its error-index field is set to the index of the failed variable binding 😵.
(4) Otherwise, if the variable binding's value field specifies, according to the ASN.1 language, a length that is inconsistent with what's required for all variables sharing the same OBJECT IDENTIFIER prefix as the variable binding's name, then the Response-PDU's error-status field is set to wrongLength, and its error-index field is set to the index of the failed variable binding 📐.
(5) Otherwise, if the variable binding's value field contains an ASN.1 encoding that is inconsistent with that field's ASN.1 tag, then the Response-PDU's error-status field is set to wrongEncoding, and its error-index field is set to the index of the failed variable binding. (Note that not all implementation strategies will generate this error 🤓.)
(6) Otherwise, if the variable binding's value field specifies a value that could under no circumstances be assigned to the variable, then the Response-PDU's error-status field is set to wrongValue, and its error-index field is set to the index of the failed variable binding 🙃.
(7) Otherwise, if the variable binding's name specifies a variable that does not exist and could never be created (even though some variables sharing the same OBJECT IDENTIFIER prefix might be able to be created under some circumstances), then the Response-PDU's error-status field is set to noCreation, and its error-index field is set to the index of the failed variable binding 🚧.
(8) Otherwise, if the variable binding's name specifies a variable that does not exist but cannot be created under the present circumstances (even though it could be created under other circumstances), then the Response-PDU's error-status field is set to inconsistentName, and its error-index field is set to the index of the failed variable binding 🌀.
(9) Otherwise, if the variable binding's name specifies a variable that exists but cannot be modified no matter what new value is specified, then the Response-PDU's error-status field is set to notWritable, and its error-index field is set to the index of the failed variable binding 🔒.
(10) Otherwise, if the variable binding's value field specifies a value that could under other circumstances be held by the variable, but is presently inconsistent or otherwise unable to be assigned to the variable, then the Response-PDU's error-status field is set to inconsistentValue, and its error-index field is set to the index of the failed variable binding 🥺.
(11) When, during the steps above, assigning the value specified by the variable binding's value field to the specified variable requires allocating a resource that is presently unavailable, then the Response-PDU's error-status field is set to resourceUnavailable, and its error-index field is set to the index of the failed variable binding 🪫.
(12) If processing the variable binding fails for a reason other than those listed above, then the Response-PDU's error-status field is set to genErr, and its error-index field is set to the index of the failed variable binding 💥.
Okay so once every variable binding has passed validation ✅, the Response-PDU's error-status field gets set to noError' and its error-index field gets set to zero, and then we move on to the next part of the plot 🎬
For each variable binding in the request, the named variable gets created if it doesn't exist yet, and the specified value gets assigned to it 🎀. All of these assignments happen as if they're simultaneous with respect to each other ⏱️. The twist is that if the same variable is named more than once in a single request with different values attached, the actual assignment that ends up being made to it is implementation-specific 🤷♀️.
If any of these assignments fail (even after all the earlier validations passed 😭), then all the other assignments get undone, the Response-PDU's error-status field gets set to commitFailed', and its error-index field gets set to the index of the failed variable binding 💀.
If and only if it's not possible to undo all the assignments, the Response-PDU's error-status field gets set to undoFailed' and its error-index field gets set to zero. Implementations are strongly encouraged to take every possible measure to avoid commitFailed' or undoFailed'. Bestie, these two error-status codes are not a free pass to take the easy way out in an implementation 🙅♀️.
Finally, the generated Response-PDU gets encapsulated into a message and transmitted to the originator of the SetRequest-PDU 📬✨
4.2.6. The SNMPv2-Trap-PDU 🚨
A SNMPv2-Trap-PDU is generated and transmitted by a SNMPv2 entity acting in an agent role when an exceptional situation occurs. It's giving "hey, something's going on!" energy 😳.
The SNMPv2 entity decides where the SNMPv2-Trap-PDU gets sent, in an implementation-dependent fashion 🤷♀️. The first two variable bindings in the variable binding list of a SNMPv2-Trap-PDU are sysUpTime.0 [9] and snmpTrapOID.0 [9] respectively, so those two lead the pack 👑. If the OBJECTS clause is present in the invocation of the corresponding NOTIFICATION-TYPE macro, then each corresponding variable, as instantiated by this notification, is copied, in order, into the variable-bindings field 📋. And if the generating SNMPv2 entity wants to add any extra variables (totally its call 🫶), each one gets copied into the variable-bindings field too 🎁.
4.2.7. The InformRequest-PDU 📣
An InformRequest-PDU gets generated and transmitted when an application in a SNMPv2 entity acting in a manager role asks for it 📣. That application wants to notify another application (in a SNMPv2 entity also acting in a manager role) about information in a MIB view that's remote to the receiving application 👀.
The requesting application picks the destination(s) for the InformRequest-PDU 🎯. The first two variable bindings in the variable binding list of an InformRequest-PDU are sysUpTime.0 [9] and snmpTrapOID.0 [9] respectively. If the OBJECTS clause is present in the invocation of the corresponding NOTIFICATION-TYPE macro, then each corresponding variable, as instantiated by this notification, is copied, in order, into the variable-bindings field 📋.
Upon receipt of an InformRequest-PDU, the receiving SNMPv2 entity works out the size of a message encapsulating a Response-PDU that has the same values in its request-id, error-status, error-index and variable-bindings fields as the received InformRequest-PDU 📏. If that size is greater than either a local constraint or the maximum message size of the originator, then an alternate Response-PDU is generated, transmitted to the originator of the InformRequest-PDU, and processing of the InformRequest-PDU terminates immediately after 🛑. This alternate Response-PDU is formatted with the same value in its request-id field as the received InformRequest-PDU, with its error-status field set to tooBig', its error-index field set to zero, and an empty variable-bindings field 🫙. This alternate Response-PDU then gets encapsulated into a message. If the size of that resultant message is less than or equal to both a local constraint and the maximum message size of the originator, it gets transmitted to the originator of the InformRequest-PDU ✅. Otherwise, the snmpSilentDrops [9] counter is incremented and the resultant message is discarded 🗑️. Regardless, processing of the InformRequest-PDU terminates 🏁.
Otherwise, the receiving SNMPv2 entity does three things 🌈:
- presents its contents to the appropriate SNMPv2 application;
- generates a Response-PDU with the same values in its
request-idandvariable-bindingsfields as the received InformRequest-PDU, with itserror-statusfield set tonoError'and itserror-indexfield set to zero; and - transmits the generated Response-PDU to the originator of the InformRequest-PDU.
5. Security Considerations 🔐
Okay bestie, serious moment 🫢. Security issues are not discussed in this memo at all. Like, zero. Nada. 🙈
6. Editor's Address 📮
Our editor is Keith McCloghrie, and here's how to reach him 💌:
Keith McCloghrie
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
US
Phone: +1 408 526 5260
EMail: kzm@cisco.com7. Acknowledgements 🫶
This document is the result of significant work by the four major contributors 👑:
- Jeffrey D. Case (SNMP Research, case@snmp.com)
- Keith McCloghrie (Cisco Systems, kzm@cisco.com)
- Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us)
- Steven Waldbusser (International Network Services, stevew@uni.ins.com)
In addition, the contributions of the SNMPv2 Working Group are acknowledged 🙌. A special thanks also goes to these legends for their contributions 💖:
- Alexander I. Alten (Novell)
- Dave Arneson (Cabletron)
- Uri Blumenthal (IBM)
- Doug Book (Chipcom)
- Kim Curran (Bell-Northern Research)
- Jim Galvin (Trusted Information Systems)
- Maria Greene (Ascom Timeplex)
- Iain Hanson (Digital)
- Dave Harrington (Cabletron)
- Nguyen Hien (IBM)
- Jeff Johnson (Cisco Systems)
- Michael Kornegay (Object Quest)
- Deirdre Kostick (AT&T Bell Labs)
- David Levi (SNMP Research)
- Daniel Mahoney (Cabletron)
- Bob Natale (ACE*COMM)
- Brian O'Keefe (Hewlett Packard)
- Andrew Pearson (SNMP Research)
- Dave Perkins (Peer Networks)
- Randy Presuhn (Peer Networks)
- Aleksey Romanov (Quality Quorum)
- Shawn Routhier (Epilogue)
- Jon Saperia (BGS Systems)
- Bob Stewart (Cisco Systems, bstewart@cisco.com), chair
- Kaj Tesink (Bellcore)
- Glenn Waters (Bell-Northern Research)
- Bert Wijnen (IBM)
8. References 📚
[1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987).
[2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996.
[3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
[4] Kent, C., and J. Mogul, Fragmentation Considered Harmful, Proceedings, ACM SIGCOMM '87, Stowe, VT, (August 1987).
[5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
[6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, USC/Information Sciences Institute, August 1980.
[7] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991.
[8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework", RFC 1908, January 1996.
[9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907, January 1996.
📦 where this page comes from
- ietf: rfc1905 1996-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms