RFC 1157
Simple Network Management Protocol (SNMP)
A Simple Network Management Protocol (SNMP) 🦋
okay bestie, this one is the SNMP spec 💖 and it dropped in May 1990. here's who made it:
- Network Working Group 💜 (the group it was published under)
- Request for Comments: 1157 🎀 (the RFC number, obviously)
- Authors: J. Case (SNMP Research), M. Fedor (Performance Systems International), M. Schoffstall (Performance Systems International), and J. Davin (MIT Laboratory for Computer Science) 👑
- Date: May 1990 📅
- Obsoletes: RFC 1098 🧹, so this one officially replaces it
- It doesn't list anything it updates ✨
Table of Contents 📚
1. Status of this Memo ................................... 2
2. Introduction .......................................... 2
3. The SNMP Architecture ................................. 5
3.1 Goals of the Architecture ............................ 5
3.2 Elements of the Architecture ......................... 5
3.2.1 Scope of Management Information .................... 6
3.2.2 Representation of Management Information ........... 6
3.2.3 Operations Supported on Management Information ..... 7
3.2.4 Form and Meaning of Protocol Exchanges ............. 8
3.2.5 Definition of Administrative Relationships ......... 8
3.2.6 Form and Meaning of References to Managed Objects .. 12
3.2.6.1 Resolution of Ambiguous MIB References ........... 12
3.2.6.2 Resolution of References across MIB Versions...... 12
3.2.6.3 Identification of Object Instances ............... 12
3.2.6.3.1 ifTable Object Type Names ...................... 13
3.2.6.3.2 atTable Object Type Names ...................... 13
3.2.6.3.3 ipAddrTable Object Type Names .................. 14
3.2.6.3.4 ipRoutingTable Object Type Names ............... 14
3.2.6.3.5 tcpConnTable Object Type Names ................. 14
3.2.6.3.6 egpNeighTable Object Type Names ................ 15
4. Protocol Specification ................................ 16
4.1 Elements of Procedure ................................ 17
4.1.1 Common Constructs .................................. 19
4.1.2 The GetRequest-PDU ................................. 20
4.1.3 The GetNextRequest-PDU ............................. 21
4.1.3.1 Example of Table Traversal ....................... 23
4.1.4 The GetResponse-PDU ................................ 24
4.1.5 The SetRequest-PDU ................................. 25
4.1.6 The Trap-PDU ....................................... 27
4.1.6.1 The coldStart Trap ............................... 28
4.1.6.2 The warmStart Trap ............................... 28
4.1.6.3 The linkDown Trap ................................ 28
4.1.6.4 The linkUp Trap .................................. 28
4.1.6.5 The authenticationFailure Trap ................... 28
4.1.6.6 The egpNeighborLoss Trap ......................... 28
4.1.6.7 The enterpriseSpecific Trap ...................... 29
5. Definitions ........................................... 30
6. Acknowledgements ...................................... 33
7. References ............................................ 34
8. Security Considerations................................ 35
9. Authors' Addresses..................................... 351. Status of this Memo 🌸
okay so this RFC is basically a re-release of RFC 1098 🔁, with a reworked "Status of this Memo" section and a few tiny typo fixes. it defines a simple protocol that lets logically remote users inspect or change the management information for a network element 🔍. together with its companion memos (the ones describing how management information is structured and the management information base), it gives you a simple, workable architecture and system for managing TCP/IP-based internets, and especially the Internet itself 🌐.
the Internet Activities Board recommends that all IP and TCP implementations be network manageable 💅. that means implementing the Internet MIB (RFC-1156) plus at least one of the two recommended management protocols: SNMP (RFC-1157) or CMOT (RFC-1095). just so you know, SNMP is a full Internet standard right now, while CMOT is a draft standard 📜. the Host and Gateway Requirements RFCs have more detail on where this applies, so go check those if you want the specifics 🧐.
for the current state and status of standard Internet protocols, check the latest edition of the "IAB Official Protocol Standards" RFC 📖.
distribution of this memo is unlimited 🫶.
2. Introduction 🎀
so, as RFC 1052 (IAB Recommendations for the Development of Internet Network Management Standards [1]) reported, a two-prong strategy was undertaken for network management of TCP/IP-based internets ✌️. in the short-term, SNMP was going to be used to manage nodes in the Internet community. in the long-term, they were going to examine using the OSI network management framework. two documents were made to define the management information: RFC 1065, which defined the Structure of Management Information (SMI) [2], and RFC 1066, which defined the Management Information Base (MIB) [3]. both were designed to be compatible with both the SNMP and the OSI network management frameworks 🤝.
that short-term plan was honestly a huge win 🏆. Internet-based network management tech got fielded by both the research and commercial communities within a few months, so parts of the Internet community became network manageable in a timely fashion 🚀.
then RFC 1109 (Report of the Second Ad Hoc Network Management Review Group [4]) reported that the requirements of SNMP and the OSI network management frameworks were more different than anyone expected 😭. so the requirement for compatibility between the SMI/MIB and both frameworks got suspended. this let the operational framework, SNMP, respond to new operational needs by producing documents that define new MIB items 🌈.
the IAB designated SNMP, SMI, and the initial Internet MIB as full "Standard Protocols" with "Recommended" status 👑. by doing this, the IAB recommends that all IP and TCP implementations be network manageable, and that the implementations that are network manageable are expected to adopt and implement the SMI, MIB, and SNMP.
so the current network management framework for TCP/IP-based internets is made of three pieces 🧩:
- Structure and Identification of Management Information for TCP/IP-based Internets, which describes how managed objects in the MIB are defined, as set forth in RFC 1155 [5]
- Management Information Base for Network Management of TCP/IP-based Internets, which describes the managed objects contained in the MIB, as set forth in RFC 1156 [6]
- the Simple Network Management Protocol, which defines the protocol used to manage these objects, as set forth in this memo ✨
back to RFC 1052 [1] for a sec: the Internet Activities Board told the Internet Engineering Task Force (IETF) to create two new working groups in network management 🫧. one group was in charge of further specifying and defining the elements to be included in the Management Information Base (MIB). the other was in charge of defining the changes to SNMP that would accommodate the short-term needs of the network vendor and operations communities, and would line up with what the MIB working group put out 💪.
the MIB working group made two memos. the first defines a Structure for Management Information (SMI) [2] for the managed objects in the MIB. the second memo [3] defines the list of managed objects itself 📋.
the output of the SNMP Extensions working group is this memo 💜. it includes changes to the initial SNMP definition [7] that were required to get aligned with the MIB working group's output. the changes were supposed to be minimal, to stay consistent with the IAB's directive that the working groups be "extremely sensitive to the need to keep the SNMP simple." 🙈 a lot of care and debate went into the changes, but the resulting protocol is not backwardly-compatible with its predecessor, the Simple Gateway Monitoring Protocol (SGMP) [8] ⚠️. the syntax got altered, but the original philosophy, design decisions, and architecture all stayed intact 🥹. and to avoid confusion, new UDP ports were allocated for this protocol 🦋.
3. The SNMP Architecture 🧠
the SNMP architectural model is basically a collection of network management stations and network elements 🍓. the stations run management applications that monitor and control the network elements. network elements are things like hosts, gateways, terminal servers, and the like, and they have management agents that carry out the management functions the stations ask for 🛠️. the Simple Network Management Protocol (SNMP) is what communicates management information between the stations and the agents in the network elements 📡.
3.1. Goals of the Architecture 🎯
SNMP explicitly minimizes the number and complexity of management functions the management agent itself has to handle 🧘♀️. this goal is attractive in at least four respects:
- (1) the development cost for the management agent software needed to support the protocol goes down 💸
- (2) the degree of management function that can be remotely supported goes up, which means the fullest use of internet resources for the management task 🌐
- (3) the degree of remotely supported management function goes up too, which puts the fewest possible restrictions on the form and sophistication of management tools 🧰
- (4) simplified sets of management functions are easy for developers of network management tools to understand and use 🫶
a second goal is that the functional paradigm for monitoring and control is extensible enough to handle additional, possibly unanticipated aspects of network operation and management 🔮.
a third goal is that the architecture is, as much as possible, independent of the architecture and mechanisms of particular hosts or particular gateways 🦋.
3.2. Elements of the Architecture 🧩
the SNMP architecture solves the network management problem by looking at it in terms of:
- (1) the scope of the management information the protocol communicates
- (2) the representation of the management information the protocol communicates
- (3) the operations on management information the protocol supports
- (4) the form and meaning of exchanges among management entities
- (5) the definition of administrative relationships among management entities, and
- (6) the form and meaning of references to management information 💅
3.2.1. Scope of Management Information ✨
okay so bestie, the management info that SNMP actually moves around is exactly the stuff represented by instances of all the non-aggregate object types. 💅 Those can come from the Internet-standard MIB, or from anywhere else that follows the conventions in the Internet-standard SMI [5]. Main character energy, fr fr 🎀
Support for aggregate object types in the MIB is neither required for conformance with the SMI nor realized by the SNMP. So no aggregates over here, periodt 🙈
3.2.2. Representation of Management Information 🦋
Management info that SNMP shares gets written in the subset of the ASN.1 language [9] that the SMI sets aside for non-aggregate types. Bestie, it's giving neat and tidy 💖
SGMP started this whole well-defined-subset-of-ASN.1 thing [9]. SNMP keeps that tradition going, but it goes a little further and uses a moderately more complex subset of ASN.1 to describe managed objects and the protocol data units used to manage them. 🌸
Ngl, the goal of making a future move to OSI-based network management protocols easier is also why an Internet-standard Structure of Management Information (SMI) [5] and Management Information Base (MIB) [6] got defined in ASN.1. ✨ ASN.1 was picked partly because it worked so well in earlier efforts, especially SGMP. The SMI's restrictions on ASN.1 are part of why it stays simple, and SGMP proved that simplicity is a total vibe 👑
Also for simplicity, SNMP only uses a subset of the basic encoding rules of ASN.1 [10]. Here's the deal: every encoding uses the definite-length form. And whenever it's allowed, non-constructor encodings get used instead of constructor encodings. This applies to all parts of ASN.1 encoding, for the top-level protocol data units and the data objects inside them. No exceptions, iykyk 🫶
3.2.3. Operations Supported on Management Information 💜
SNMP treats every management agent function as changing or inspecting variables. So a protocol entity on a logically remote host (which could even be the network element itself) talks to the management agent on the network element to either retrieve (get) or alter (set) variables. This strategy has at least two positive consequences: 🧚
(1) It limits the number of essential management functions the management agent has to do to two: one operation to assign a value to a configuration or other parameter, and another to retrieve such a value. Lowkey genius 🔥
(2) It also keeps imperative management commands out of the protocol definition. Those commands keep multiplying in practice, and their semantics can get arbitrarily complex, which is a whole mess 💀
The strategy behind SNMP is that monitoring network state at any significant level of detail happens mainly by polling for the right information from the monitoring center(s). A limited number of unsolicited messages (traps) guide the timing and focus of that polling. Keeping unsolicited messages limited fits the goal of simplicity and of minimizing the traffic that network management creates. 🌈
Leaving imperative commands out of the explicitly supported management functions is unlikely to block any useful management agent operation. Most commands today are requests to set a parameter's value or to retrieve one, and the few imperative commands that do exist can easily be handled in an asynchronous mode under this model. 🦋 In that scheme, an imperative command might be realized as setting a parameter value that later triggers the desired action. For example, instead of building a "reboot command," this action could be invoked by just setting a parameter that indicates the number of seconds until system reboot. Clever, right? 😭✨
3.2.4. Form and Meaning of Protocol Exchanges 🎀
Management entities share management information by exchanging protocol messages in SNMP. The form and meaning of those messages are defined below in Section 4. 🫶
To keep the management agent's complexity down, the exchange of SNMP messages only requires an unreliable datagram service, and every message is entirely and independently represented by a single transport datagram. 🌸 This document specifies the exchange of messages via the UDP protocol [11], but the mechanisms of SNMP are generally suitable for use with a wide variety of transport services. Not me getting excited about how flexible this is 🍓💅
3.2.5. Definition of Administrative Relationships ✨
Okay so this is where SNMP gets into the who-can-do-what drama 💅 The architecture allows a whole bunch of administrative relationships between the entities that take part in the protocol. The entities living at management stations and network elements that talk to each other over SNMP are called SNMP application entities. The peer processes that actually implement SNMP, and therefore back up those application entities, are called protocol entities. 🦋
A pairing of an SNMP agent with some arbitrary set of SNMP application entities is called an SNMP community. Each community is named by a string of octets, and that string is called the community name for said community. 🎀
An SNMP message that was really originated by an SNMP application entity belonging to the community named in that message's community component is called an authentic SNMP message. The set of rules used to decide that a message is an authentic SNMP message for a particular community is called an authentication scheme. An implementation of a function that identifies authentic SNMP messages under one or more authentication schemes is called an authentication service. 💖
Clearly, managing administrative relationships well takes authentication services that can (using encryption or other techniques) identify authentic SNMP messages with a high degree of certainty. Some SNMP implementations may wish to support only a trivial authentication service, one that identifies every SNMP message as authentic. 🙈
For any network element, a subset of the objects in the MIB that pertain to that element is called an SNMP MIB view. Note that the names of the object types in an SNMP MIB view need not belong to a single sub-tree of the object type name space. 🌸
An element of the set { READ-ONLY, READ-WRITE } is called an SNMP access mode. 🍓
A pairing of an SNMP access mode with an SNMP MIB view is called an SNMP community profile. A profile represents specified access privileges to variables in a specified MIB view. For every variable in the MIB view of a given SNMP community profile, access to that variable is represented by the profile according to these conventions: 👑
- If said variable is defined in the MIB with
Access:ofnone, it is unavailable as an operand for any operator. - If said variable is defined in the MIB with
Access:ofread-writeorwrite-onlyand the access mode of the given profile is READ-WRITE, that variable is available as an operand for the get, set, and trap operations. - Otherwise, the variable is available as an operand for the get and trap operations.
- In those cases where a
write-onlyvariable is an operand used for the get or trap operations, the value given for the variable is implementation-specific.
A pairing of an SNMP community with an SNMP community profile is called an SNMP access policy. An access policy represents a specified community profile afforded by the SNMP agent of a specified SNMP community to other members of that community. All administrative relationships among SNMP application entities are architecturally defined in terms of SNMP access policies. 🧚
For every SNMP access policy, if the network element on which the SNMP agent for the specified SNMP community resides is not the one to which the MIB view for the specified profile pertains, then that policy is called an SNMP proxy access policy. The SNMP agent associated with a proxy access policy is called an SNMP proxy agent. Careless definition of proxy access policies can result in management loops, but prudent definition of proxy policies is useful in at least two ways: ⭐
- It permits the monitoring and control of network elements that are otherwise not addressable using the management protocol and the transport protocol. In other words, a proxy agent may provide a protocol conversion function, letting a management station apply one consistent management framework to all network elements, including devices such as modems, multiplexors, and other devices that support different management frameworks.
- It potentially shields network elements from elaborate access control policies. For example, a proxy agent may implement sophisticated access control, so that diverse subsets of variables within the MIB are made accessible to different management stations without increasing the complexity of the network element.
Figure 1 shows the relationship between management stations, proxy agents, and management agents. In this example, the proxy agent is envisioned as a normal Internet Network Operations Center (INOC) of some administrative domain, which has a standard managerial relationship with a set of management agents. 🌈
+------------------+ +----------------+ +----------------+
| Region #1 INOC | |Region #2 INOC | |PC in Region #3 |
| | | | | |
|Domain=Region #1 | |Domain=Region #2| |Domain=Region #3|
|CPU=super-mini-1 | |CPU=super-mini-1| |CPU=Clone-1 |
|PCommunity=pub | |PCommunity=pub | |PCommunity=slate|
| | | | | |
+------------------+ +----------------+ +----------------+
/|\ /|\ /|\
| | |
| | |
| \|/ |
| +-----------------+ |
+-------------->| Region #3 INOC |<-------------+
| |
|Domain=Region #3 |
|CPU=super-mini-2 |
|PCommunity=pub, |
| slate |
|DCommunity=secret|
+-------------->| |<-------------+
| +-----------------+ |
| /|\ |
| | |
| | |
\|/ \|/ \|/
+-----------------+ +-----------------+ +-----------------+
|Domain=Region#3 | |Domain=Region#3 | |Domain=Region#3 |
|CPU=router-1 | |CPU=mainframe-1 | |CPU=modem-1 |
|DCommunity=secret| |DCommunity=secret| |DCommunity=secret|
+-----------------+ +-----------------+ +-----------------+Domain: the administrative domain of the element
PCommunity: the name of a community utilizing a proxy agent
DCommunity: the name of a direct community
Figure 1
Example Network Management Configuration3.2.6. Form and Meaning of References to Managed Objects 🎀
The SMI requires that the definition of a conformant management protocol address:
- The resolution of ambiguous MIB references.
- The resolution of MIB references in the presence of multiple MIB versions.
- The identification of particular instances of object types defined in the MIB.
3.2.6.1. Resolution of Ambiguous MIB References 🦋
Because the scope of any SNMP operation is conceptually confined to objects relevant to a single network element, and because all SNMP references to MIB objects are (implicitly or explicitly) made by unique variable names, there is no possibility that any SNMP reference to any object type defined in the MIB could resolve to multiple instances of that type. 💅
3.2.6.2. Resolution of References across MIB Versions 🌸
The object instance referred to by any SNMP operation is exactly the one specified as part of the operation request or, in the case of a get-next operation, its immediate successor in the MIB as a whole. In particular, a reference to an object as part of some version of the Internet-standard MIB does not resolve to any object that is not part of that version of the Internet-standard MIB, except in the case that the requested operation is get-next and the specified object name is lexicographically last among the names of all objects presented as part of that version of the Internet-standard MIB. 🫶
3.2.6.3. Identification of Object Instances 🧚
The names for all object types in the MIB are defined explicitly, either in the Internet-standard MIB or in other documents that conform to the naming conventions of the SMI. The SMI requires that conformant management protocols define mechanisms for identifying individual instances of those object types for a particular network element. 💜
Each instance of any object type defined in the MIB is identified in SNMP operations by a unique name called its "variable name." In general, the name of an SNMP variable is an OBJECT IDENTIFIER of the form x.y, where x is the name of a non-aggregate object type defined in the MIB, and y is an OBJECT IDENTIFIER fragment that, in a way specific to the named object type, identifies the desired instance. 🍓
This naming strategy allows the fullest exploitation of the semantics of the GetNextRequest-PDU (see Section 4), because it assigns names for related variables so that they are contiguous in the lexicographical ordering of all variable names known in the MIB. ⭐
The type-specific naming of object instances is defined below for a number of classes of object types. Instances of an object type to which none of the following naming conventions apply are named by OBJECT IDENTIFIERs of the form x.0, where x is the name of said object type in the MIB definition. 🌈
For example, suppose you want to identify an instance of the variable sysDescr. The object class for sysDescr is:
iso org dod internet mgmt mib system sysDescr
1 3 6 1 2 1 1 1So the object type, x, would be 1.3.6.1.2.1.1.1, to which an instance sub-identifier of 0 is appended. That is, 1.3.6.1.2.1.1.1.0 identifies the one and only instance of sysDescr. 👑
3.2.6.3.1. ifTable Object Type Names 🌈
The name of a subnet interface, s, is the OBJECT IDENTIFIER value of the form i, where i has the value of that instance of the ifIndex object type associated with s. 💖
For each object type, t, for which the defined name, n, has a prefix of ifEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of the form n.s, where s is the name of the subnet interface about which i represents information. 🫶
For example, suppose you want to identify the instance of the variable ifType associated with interface 2. Accordingly, ifType.2 would identify the desired instance. 🔥
3.2.6.3.2. atTable Object Type Names ✨
okay so bestie, the name of an AT-cached network address, x, is an OBJECT IDENTIFIER shaped like 1.a.b.c.d, where a.b.c.d is the value of the atNetAddress object type linked to x, written in that totally familiar dot notation 🦋
an address translation equivalence, e, gets its own name too. It's an OBJECT IDENTIFIER value of the form s.w, where s is the value of that instance of the atIndex object type linked to e, and w is the name of the AT-cached network address linked to e 💜
and for each object type, t, whose defined name, n, has a prefix of atEntry, an instance, i, of t is named n.y, where y is the name of the address translation equivalence that i is giving you info about. it's giving organized 💅
example time 🌸 say you want the physical address of an entry in the address translation table (ARP cache) for IP address 89.1.1.42 on interface 3. then atPhysAddress.3.1.89.1.1.42 is the instance you're looking for ✨
3.2.6.3.3. ipAddrTable Object Type Names
okay so the name of an IP-addressable network element, x, is the OBJECT IDENTIFIER a.b.c.d, where a.b.c.d is the value (dot notation again, iykyk) of that instance of the ipAdEntAddr object type linked to x 🎀
for each object type, t, whose defined name, n, has a prefix of ipAddrEntry, an instance, i, of t is named n.y, where y is the name of the IP-addressable network element that i is about 🧚
example: say you want the network mask of an entry in the IP interface table for IP address 89.1.1.42. then ipAdEntNetMask.89.1.1.42 is your instance 🍓
3.2.6.3.4. ipRoutingTable Object Type Names
the name of an IP route, x, is the OBJECT IDENTIFIER a.b.c.d, where a.b.c.d is the value (dot notation, obviously) of that instance of the ipRouteDest object type linked to x 🦋
for each object type, t, whose defined name, n, has a prefix of ipRoutingEntry, an instance, i, of t is named n.y, where y is the name of the IP route that i is about ✨
example: say you want the next hop of an entry in the IP routing table for destination 89.1.1.42. then ipRouteNextHop.89.1.1.42 is the instance you want 💖
3.2.6.3.5. tcpConnTable Object Type Names
ngl this one is a little more layered 👑 the name of a TCP connection, x, is the OBJECT IDENTIFIER a.b.c.d.e.f.g.h.i.j, and it's built like this:
a.b.c.dis the value of that instance of thetcpConnLocalAddressobject type linked to xeis the value of that instance of thetcpConnLocalPortobject type linked to xf.g.h.iis the value of that instance of thetcpConnRemoteAddressobject type linked to xjis the value of that instance of thetcpConnRemotePortobject type linked to x
so the local address comes first, then the local port, then the remote address, then the remote port. slay the order 💅
for each object type, t, whose defined name, n, has a prefix of tcpConnEntry, an instance, i, of t is named n.y, where y is the name of the TCP connection that i is about 🌈
example: say you want the state of a TCP connection with local address 89.1.1.42 on TCP port 21 and remote address 10.0.0.51 on TCP port 2059. then tcpConnState.89.1.1.42.21.10.0.0.51.2059 is the instance you're after 🫶
3.2.6.3.6. egpNeighTable Object Type Names
the name of an EGP neighbor, x, is the OBJECT IDENTIFIER a.b.c.d, where a.b.c.d is the value (dot notation, as always 🙈) of that instance of the egpNeighAddr object type linked to x 🌸
for each object type, t, whose defined name, n, has a prefix of egpNeighEntry, an instance, i, of t is named n.y, where y is the name of the EGP neighbor that i is about 💜
example: say you want the neighbor state for IP address 89.1.1.42. then egpNeighState.89.1.1.42 is the instance you want 🎀
4. Protocol Specification ✨
okay so the network management protocol is an application protocol that lets you look at, or change, the variables in an agent's MIB 👀
messages talk to each other by being sent around, and each message is entirely and independently packed into a single UDP datagram, using the basic encoding rules of ASN.1 (as discussed in Section 3.2.2) 📦 a message has three parts: a version identifier, an SNMP community name, and a protocol data unit (PDU) 🍓
a protocol entity receives messages at UDP port 161 on the host it's attached to, for all messages except the ones that report traps (aka all messages except the ones that contain the Trap-PDU). messages that report traps should be received on UDP port 162 for further processing 🦋
heads up, bestie: an implementation of this protocol need not accept messages whose length is more than 484 octets. that said, it is recommended that implementations support larger datagrams whenever feasible 🌈
it is mandatory that all implementations of the SNMP support the five PDUs: GetRequest-PDU, GetNextRequest-PDU, GetResponse-PDU, SetRequest-PDU, and Trap-PDU. no exceptions, main character energy 👑
RFC1157-SNMP DEFINITIONS ::= BEGIN
IMPORTS
ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
FROM RFC1155-SMI;
-- top-level message
Message ::=
SEQUENCE {
version -- version-1 for this RFC
INTEGER {
version-1(0)
},
community -- community name
OCTET STRING,
data -- e.g., PDUs if trivial
ANY -- authentication is being used
}
-- protocol data units
PDUs ::=
CHOICE {
get-request
GetRequest-PDU,
get-next-request
GetNextRequest-PDU,
get-response
GetResponse-PDU,
set-request
SetRequest-PDU,
trap
Trap-PDU
}
-- the individual PDUs and commonly used
-- data types will be defined later
END4.1. Elements of Procedure
okay so this section describes what a protocol entity implementing the SNMP actually does 💅 but it's not trying to boss around how any conformant implementation is built inside, so do your own thing internally 🧚
in the text that follows, the term transport address shows up. for UDP, a transport address is an IP address along with a UDP port 🦋 other transport services can also be used to support the SNMP, and in those cases the definition of a transport address should be made accordingly ✨
here's what the top-level actions of a protocol entity that generates a message look like 💖
- it first constructs the appropriate PDU, e.g., the GetRequest-PDU, as an ASN.1 object.
- it then passes this ASN.1 object, along with a community name, its source transport address, and the destination transport address, to the service that implements the desired authentication scheme. this authentication service returns another ASN.1 object.
- the protocol entity then constructs an ASN.1 Message object, using the community name and the resulting ASN.1 object.
- this new ASN.1 object is then serialized using the basic encoding rules of ASN.1, and then sent using a transport service to the peer protocol entity. 🚀
and similarly, here are the top-level actions of a protocol entity that receives a message 🫶
- it performs a rudimentary parse of the incoming datagram to build an ASN.1 object corresponding to an ASN.1 Message object. if the parse fails, it discards the datagram and performs no further actions.
- it then verifies the version number of the SNMP message. if there is a mismatch, it discards the datagram and performs no further actions.
- the protocol entity then passes the community name and user data found in the ASN.1 Message object, along with the datagram's source and destination transport addresses, to the service that implements the desired 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. 🙈
- 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. periodt 💅✨
4.1.1. Common Constructs ✨
Before we meet the six PDU types of this protocol, bestie, we need the ASN.1 constructs that show up literally everywhere 💅
-- 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
VarBindRequestIDs are how you keep your outstanding requests straight 🎀 Because of the RequestID, an SNMP application entity can match incoming responses to the requests it sent ✨ And if you're on an unreliable datagram service, the RequestID also gives you a simple way to spot messages the network duplicated 👀
A non-zero ErrorStatus means an exception happened while a request was being processed 😭 When that's the case, ErrorIndex can tell you more by pointing at which variable in a list caused the problem 🔍
Quick vocab check: a variable is just an instance of a managed object 🦋 A variable binding, or VarBind, is the pairing of a variable's name with its value 💜 And a VarBindList is a simple list of those names and values 🌸
Some PDUs only care about the name of a variable and not its value, like the GetRequest-PDU 🙈 For those, the protocol entity ignores the value portion of the binding. But that value portion still needs valid ASN.1 syntax and encoding, no skipping it 😤 It's recommended that the ASN.1 value NULL gets used for the value portion of those 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
}A protocol entity only generates a GetRequest-PDU when its SNMP application entity asks it to 🌈
When the GetRequest-PDU arrives, the receiving protocol entity checks the list below and follows whichever rule applies 👑
- Ghost names get rejected 🚫 If any object named in the variable-bindings field doesn't exactly match the name of an object available for get operations in the relevant MIB view, the receiving entity sends the originator a GetResponse-PDU of identical form. The difference is that error-status is
noSuchName, and error-index is the index of that object name component in the received message. - No aggregate types 🙅♀️ If any object named in the variable-bindings field is an aggregate type (as defined in the SMI), the receiving entity sends the originator a GetResponse-PDU of identical form. Again, error-status is
noSuchName, and error-index is the index of that object name component in the received message. - Too chonky 📦 If the GetResponse-PDU generated as described below would be bigger than a local limitation, the receiving entity sends the originator a GetResponse-PDU of identical form. This time error-status is
tooBig, and error-index is zero. - Value unavailable 😵 If the value of any object named in the variable-bindings field can't be retrieved for reasons not covered by the rules above, the receiving entity sends the originator a GetResponse-PDU of identical form. Here error-status is
genErr, and error-index is the index of that object name component in the received message.
If none of those rules apply, the receiving protocol entity sends the originator a GetResponse-PDU that carries, for each object named in the variable-bindings field of the received message, the name and value of that variable in the matching component 🎁 The error-status field of that GetResponse-PDU is noError, the error-index field is zero, and the request-id field matches the request-id of the received message ✨
4.1.3. The GetNextRequest-PDU 🔁
The GetNextRequest-PDU has the exact same form as the GetRequest-PDU. The only thing that changes is the indication of the PDU type. In ASN.1 it looks like this:
GetNextRequest-PDU ::=
[1]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status -- always 0
ErrorStatus,
error-index -- always 0
ErrorIndex,
variable-bindings
VarBindList
}Same rule as before, a protocol entity only generates a GetNextRequest-PDU at the request of its SNMP application entity 💌
When a GetNextRequest-PDU lands, the receiving protocol entity follows whichever of these rules applies 🎯
- Nothing after it 🙃 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, the receiving entity sends the originator a GetResponse-PDU of identical form. The error-status field is
noSuchName, and the error-index field is the index of that object name component in the received message. - Too chonky, again 📦 If the GetResponse-PDU generated as described below would exceed a local limitation, the receiving entity sends the originator a GetResponse-PDU of identical form. The error-status field is
tooBig, and the error-index field is zero. - Successor drama 😭 If, for any object named in the variable-bindings field, the value of its lexicographical successor can't be retrieved for reasons not covered by the rules above, the receiving entity sends the originator a GetResponse-PDU of identical form. The error-status field is
genErr, and the error-index field is the index of that object name component in the received message.
If none of the foregoing rules apply, the receiving protocol entity sends the originator a GetResponse-PDU where, for each name in the variable-bindings field of the received message, the matching component represents the name and value of the object that comes right after that name. "Right after" means the immediate successor in the lexicographical ordering of all objects available for get operations in the relevant MIB view 💫 The error-status field of the GetResponse-PDU is noError, the errorindex field is zero, and the request-id field matches the one in the received message 🫶
4.1.3.1. Example of Table Traversal 🗺️
Okay, this is one of the most iconic uses of the GetNextRequest-PDU 👑 You can walk through conceptual tables of information in the MIB with it. Its semantics, together with the protocol-specific ways of identifying individual object type instances in the MIB, let you access related objects as if they were laid out in a table 📋
In the exchange below, an SNMP application entity might pull the destination address and next hop gateway for each entry in the routing table of a particular network element 🦋 Let's say 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 5The management station sends the SNMP agent a GetNextRequest-PDU with 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 keeps going with:
GetNextRequest ( ipRouteDest.9.1.2.3,
ipRouteNextHop.9.1.2.3,
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 keeps going with:
GetNextRequest ( ipRouteDest.10.0.0.51,
ipRouteNextHop.10.0.0.51,
ipRouteMetric1.10.0.0.51 )The SNMP agent responds:
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 keeps going with:
GetNextRequest ( ipRouteDest.10.0.0.99,
ipRouteNextHop.10.0.0.99,
ipRouteMetric1.10.0.0.99 )Once there are no more entries in the table, the SNMP agent returns the objects that come next in the lexicographical ordering of the known object names 🏁 That response is how the management station knows it has reached the end of the routing table 🎉
4.1.4. The GetResponse-PDU ✨
okay so the GetResponse-PDU is basically the GetRequest-PDU's twin 👯♀️ the only difference is the PDU type tag. here's the ASN.1 bit:
GetResponse-PDU ::=
[2]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status
ErrorStatus,
error-index
ErrorIndex,
variable-bindings
VarBindList
}a protocol entity only makes a GetResponse-PDU when it gets a GetRequest-PDU, GetNextRequest-PDU, or SetRequest-PDU, as described elsewhere in this doc 🫶
when a receiving protocol entity gets a GetResponse-PDU, it hands the contents up to its SNMP application entity 🎀
4.1.5. The SetRequest-PDU 💌
the SetRequest-PDU is also a GetRequest-PDU lookalike, just with a different PDU type tag. ASN.1 time:
SetRequest-PDU ::=
[3]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status -- always 0
ErrorStatus,
error-index -- always 0
ErrorIndex,
variable-bindings
VarBindList
}a protocol entity only generates a SetRequest-PDU when its SNMP application entity asks it to 💅
when a SetRequest-PDU comes in, the receiving entity checks the list below and goes with whichever rule applies 👀
(1) if any object named in the variable-bindings field is not available for set operations in the relevant MIB view, the receiving entity sends the originator a GetResponse-PDU of identical form. the only changes are that error-status is noSuchName, and error-index is the index of that object name component in the received message 🙈
(2) if, for any object named in the variable-bindings field, the contents of the value field don't manifest a type, length, and value that match what the variable requires according to ASN.1, the receiving entity sends the originator a GetResponse-PDU of identical form. this time error-status is badValue, and error-index is the index of that object name in the received message 💀
(3) if the size of the Get Response type message generated as described below would go over a local limitation, the receiving entity sends the originator a GetResponse-PDU of identical form. error-status becomes tooBig, and error-index is zero 📦
(4) if, for any object named in the variable-bindings field, the named object's value can't be altered for reasons not covered by any of the rules above, the receiving entity sends the originator a GetResponse-PDU of identical form. error-status becomes genErr, and error-index is the index of that object name component in the received message 😭
if none of the rules above apply, then for each object named in the variable-bindings field of the received message, the matching value gets assigned to the variable 🎯 each variable assignment in a SetRequest-PDU SHOULD be effected as if it were set at the same time as all the other assignments in that same message, which is very main character behavior 🌸
then the receiving entity sends the originator a GetResponse-PDU of identical form, except error-status is noError and error-index is zero ✨
4.1.6. The Trap-PDU 🚨
the Trap-PDU looks like this:
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
}a protocol entity only generates a Trap-PDU when the SNMP application entity requests it 🔔 how an SNMP application entity picks the destination addresses of other SNMP application entities is implementation-specific, so it's up to the implementation 🤷♀️
when a Trap-PDU arrives, the receiving protocol entity passes its contents up to its SNMP application entity 🎀
what the variable-bindings part of a Trap-PDU actually means is also implementation-specific 🌈
here's how the generic-trap field gets interpreted 👇
4.1.6.1. The coldStart Trap ❄️
a coldStart(0) trap means the sending protocol entity is reinitializing itself, so the agent's configuration or the protocol entity implementation might get changed 🧊
4.1.6.2. The warmStart Trap 🔥
a warmStart(1) trap means the sending protocol entity is reinitializing itself, but neither the agent configuration nor the protocol entity implementation gets changed 🌤️
4.1.6.3. The linkDown Trap 📉
a linkDown(2) trap means the sending protocol entity noticed that one of the communication links in the agent's configuration has failed 💔
a Trap-PDU of type linkDown has, 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 means the sending protocol entity noticed that one of the communication links in the agent's configuration has come back up 🙌
a Trap-PDU of type linkUp has, 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 means the sending protocol entity is the addressee of a protocol message that isn't properly authenticated 🕵️♀️ implementations of the SNMP MUST be capable of generating this trap, and they MUST also be capable of suppressing the emission of these traps through an implementation-specific mechanism 🔐
4.1.6.6. The egpNeighborLoss Trap 🛰️
an egpNeighborLoss(5) trap means that an EGP neighbor, for whom the sending protocol entity was an EGP peer, has been marked down and the peer relationship no longer holds 📴
a Trap-PDU of type egpNeighborLoss has, 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 means the sending protocol entity noticed that some enterprise-specific event has happened 🎪 the specific-trap field tells you which particular trap it was 🎯
5. Definitions 🧚
okay bestie, this is the whole ASN.1 module, and it's giving precise 💅 every field, tag and type is spelled out exactly, so I'm keeping it verbatim.
RFC1157-SNMP DEFINITIONS ::= BEGIN
IMPORTS
ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
FROM RFC1155-SMI;
-- top-level message
Message ::=
SEQUENCE {
version -- version-1 for this RFC
INTEGER {
version-1(0)
},
community -- community name
OCTET STRING,
data -- e.g., PDUs if trivial
ANY -- authentication is being used
}
-- protocol data units
PDUs ::=
CHOICE {
get-request
GetRequest-PDU,
get-next-request
GetNextRequest-PDU,
get-response
GetResponse-PDU,
set-request
SetRequest-PDU,
trap
Trap-PDU
}
-- PDUs
GetRequest-PDU ::=
[0]
IMPLICIT PDU
GetNextRequest-PDU ::=
[1]
IMPLICIT PDU
GetResponse-PDU ::=
[2]
IMPLICIT PDU
SetRequest-PDU ::=
[3]
IMPLICIT PDU
PDU ::=
SEQUENCE {
request-id
INTEGER,
error-status -- sometimes ignored
INTEGER {
noError(0),
tooBig(1),
noSuchName(2),
badValue(3),
readOnly(4),
genErr(5)
},
error-index -- sometimes ignored
INTEGER,
variable-bindings -- values are sometimes ignored
VarBindList
}
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
}
-- variable bindings
VarBind ::=
SEQUENCE {
name
ObjectName,
value
ObjectSyntax
}
VarBindList ::=
SEQUENCE OF
VarBind
END6. Acknowledgements 🎀
this memo was influenced by the IETF SNMP Extensions working group, and these are the legends who helped make it happen 🫶
Karl Auerbach, Epilogue Technology
K. Ramesh Babu, Excelan
Amatzia Ben-Artzi, 3Com/Bridge
Lawrence Besaw, Hewlett-Packard
Jeffrey D. Case, University of Tennessee at Knoxville
Anthony Chung, Sytek
James Davidson, The Wollongong Group
James R. Davin, MIT Laboratory for Computer Science
Mark S. Fedor, NYSERNet
Phill Gross, The MITRE Corporation
Satish Joshi, ACC
Dan Lynch, Advanced Computing Environments
Keith McCloghrie, The Wollongong Group
Marshall T. Rose, The Wollongong Group (chair)
Greg Satz, cisco
Martin Lee Schoffstall, Rensselaer Polytechnic Institute
Wengyik Yeong, NYSERNet7. References 📚
here's the full reading list, every single source, so you can go deep if you're obsessed like me 🤓
- [1] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, IAB, April 1988.
- [2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", RFC 1065, TWG, August 1988.
- [3] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1066, TWG, August 1988.
- [4] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, IAB, August 1989.
- [5] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International and Hughes LAN Systems, May 1990.
- [6] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based Internets", RFC 1156, Hughes LAN Systems and Performance Systems International, May 1990.
- [7] Case, J., M. Fedor, M. Schoffstall, and J. Davin, "A Simple Network Management Protocol", Internet Engineering Task Force working note, Network Information Center, SRI International, Menlo Park, California, March 1988.
- [8] Davin, J., J. Case, M. Fedor, and M. Schoffstall, "A Simple Gateway Monitoring Protocol", RFC 1028, Proteon, University of Tennessee at Knoxville, Cornell University, and Rensselaer Polytechnic Institute, November 1987.
- [9] Information processing systems - Open Systems Interconnection, "Specification of Abstract Syntax Notation One (ASN.1)", International Organization for Standardization, International Standard 8824, December 1987.
- [10] Information processing systems - Open Systems Interconnection, "Specification of Basic Encoding Rules for Abstract Notation One (ASN.1)", International Organization for Standardization, International Standard 8825, December 1987.
- [11] Postel, J., "User Datagram Protocol", RFC 768, USC/Information Sciences Institute, November 1980.
Security Considerations 🔒
🚨 bestie, the entire security section is one sentence: security issues are not discussed in this memo. Read it, respect it, and don't go looking for a security story in here that isn't written down 💀
Authors' Addresses 💌
these are the three (well, four) people behind the memo, with their contact details 🦋
Jeffrey D. Case
SNMP Research
P.O. Box 8593
Knoxville, TN 37996-4800
Phone: (615) 573-1434
Email: case@CS.UTK.EDU
Mark Fedor
Performance Systems International
Rensselaer Technology Park
125 Jordan Road
Troy, NY 12180
Phone: (518) 283-8860
Email: fedor@patton.NYSER.NET
Martin Lee Schoffstall
Performance Systems International
Rensselaer Technology Park
165 Jordan Road
Troy, NY 12180
Phone: (518) 283-8860
Email: schoff@NISC.NYSER.NET
James R. Davin
MIT Laboratory for Computer Science, NE43-507
545 Technology Square
Cambridge, MA 02139
Phone: (617) 253-6020
EMail: jrd@ptt.lcs.mit.edu📦 where this page comes from
- ietf: rfc1157 1990-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms