Editing Simple Network Management Protocol (section)

== Protocol details ==
SNMP operates in the [[application layer]] of the [[Internet protocol suite]]. All SNMP messages are transported via [[User Datagram Protocol]] (UDP). The SNMP agent receives requests on [[UDP port]] 161. The manager may send requests from any available source port to port 161 in the agent. The agent response is sent back to the source port on the manager. The manager receives notifications (''[[#Trap|Traps]]'' and ''[[#InformRequest|InformRequests]]'') on port 162. The agent may generate notifications from any available port. When used with [[Transport Layer Security]] or [[Datagram Transport Layer Security]], requests are received on port 10161 and notifications are sent to port 10162.<ref>{{IETF RFC|6353}} Section 10</ref>

SNMPv1 specifies five core [[protocol data unit]]s (PDUs). Two other PDUs, ''GetBulkRequest'' and ''InformRequest'' were added in SNMPv2 and the ''Report'' PDU was added in SNMPv3. All SNMP PDUs are constructed as follows:

{| class="wikitable"
|-
| IP header
| UDP header
| version
| community
| PDU-type
| request-id
| error-status
| error-index
| variable bindings
|}

The seven SNMP PDU types as identified by the ''PDU-type'' field are as follows:

; GetRequest : A manager-to-agent request to retrieve the value of a variable or list of variables. Desired variables are specified in variable bindings (the value field is not used). Retrieval of the specified variable values is to be done as an [[atomic operation]] by the agent.{{Citation needed|date=May 2025}} A ''Response'' with current values is returned.
; SetRequest : A manager-to-agent request to change the value of a variable or list of variables. Variable bindings are specified in the body of the request. Changes to all specified variables are to be made as an atomic operation by the agent.{{Ref RFC|1157|p=26|quote=Each variable assignment specified by the SetRequest-PDU should be effected as if simultaneously set with respect to all other assignments specified in the same message.}} A ''Response'' with (current) new values for the variables is returned.
; GetNextRequest : A manager-to-agent request to discover available variables and their values. Returns a ''Response'' with variable binding for the [[Lexicographical order|lexicographically next]] variable in the MIB. The entire MIB of an agent can be walked by iterative application of ''GetNextRequest'' starting at OID 0. Rows of a table can be read by specifying column OIDs in the variable bindings of the request.
; GetBulkRequest : A manager-to-agent request for multiple iterations of ''GetNextRequest''. An optimized version of ''GetNextRequest''. Returns a ''Response'' with multiple variable bindings walked from the variable binding or bindings in the request. PDU specific ''non-repeaters'' and ''max-repetitions'' fields are used to control response behavior. ''GetBulkRequest'' was introduced in SNMPv2.
; Response: Returns variable bindings and acknowledgement from agent to manager for ''GetRequest'', ''SetRequest'', ''GetNextRequest'', ''GetBulkRequest'' and ''InformRequest''. Error reporting is provided by ''error-status'' and ''error-index'' fields. Although it was used as a response to both gets and sets, this PDU was called ''GetResponse'' in SNMPv1.
; {{Visible anchor|Trap}}: Asynchronous notification from agent to manager. While in other SNMP communication, the manager actively requests information from the agent, these are PDUs that are sent from the agent to the manager without being explicitly requested. SNMP [[#Trap|Traps]] enable an agent to notify the management station of significant events by way of an unsolicited SNMP message. Trap PDUs include current ''sysUpTime'' value, an OID identifying the type of trap and optional variable bindings. Destination addressing for traps is determined in an application-specific manner typically through trap configuration variables in the MIB. The format of the trap message was changed in SNMPv2 and the PDU was renamed ''SNMPv2-Trap''.
; {{Visible anchor|InformRequest}}: Acknowledged asynchronous notification. This PDU was introduced in SNMPv2 and was originally defined as ''manager to manager'' communication.<ref>{{Cite web |url=https://tools.ietf.org/html/rfc1448#page-27 |title=RFC 1448 – Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2) |publisher=Internet Engineering Task Force |quote=An InformRequest-PDU is generated and transmitted at the request an application in a SNMPv2 entity acting in a manager role, that wishes to notify another application (in a SNMPv2 entity also acting in a manager role) of information in the MIB View of a party local to the sending application. |author1=J. Case |author2=K. McCloghrie |author3=M. Rose |author4=S. Waldbusser |date=April 1993|doi=10.17487/RFC1448 }}</ref> Later implementations have loosened the original definition to allow ''agent to manager'' communications.<ref>{{Cite web |url=https://tools.ietf.org/html/rfc2573#section-3.3 |title=RFC 2573 – SNMP Applications |publisher=Internet Engineering Task Force |author1=D. Levi |author2=P. Meyer |author3=B. Stewart |date=April 1999|doi=10.17487/RFC2573 }}</ref><ref name="cisco_a">{{Cite web |url=http://www.cisco.com/en/US/docs/ios/11_3/feature/guide/snmpinfm.html |title=SNMP Inform Requests |publisher=Cisco |access-date=2011-12-09}}</ref><ref>{{Cite web |url=https://www.juniper.net/techpubs/software/junos-security/junos-security10.2/mib-srx5600-srx5800-service-gateway/topic-21511.html |title=Understanding the SNMP Implementation in JUNOS Software |publisher=Juniper Networks |access-date=2013-02-11}}</ref> Manager-to-manager notifications were already possible in SNMPv1 using a ''Trap'', but as SNMP commonly runs over UDP where delivery is not assured and dropped packets are not reported, delivery of a ''Trap'' was not guaranteed. ''InformRequest'' fixes this as an acknowledgement is returned on receipt.<ref name="cisco_a" />

{{anchor|Community string}}{{IETF RFC|1157}} specifies that an SNMP implementation must accept a message of at least 484 bytes in length. In practice, SNMP implementations accept longer messages.<ref name="Tipton">{{Cite book|title= Information Security Management Handbook, Sixth Edition|author1=Harold F. Tipton |author2=Micki Krause |publisher= CRC Press|year=2007 |isbn= 9780849374951}}</ref>{{rp|1870}} If implemented correctly, an SNMP message is discarded if the decoding of the message fails and thus malformed SNMP requests are ignored. A successfully decoded SNMP request is then authenticated using the community string. If the authentication fails, a trap is generated indicating an authentication failure and the message is dropped.<ref name="Tipton"/>{{rp|1871}}

SNMPv1 and SNMPv2c use ''communities'' to establish trust between managers and agents. Most agents support three community names, one each for read-only, read-write and trap. These three ''community strings'' control different types of activities. The read-only community applies to ''get'' requests. The read-write community string applies to ''set'' requests. The trap community string applies to receipt of ''traps''. SNMPv3 also uses community strings, but allows for secure authentication and communication between SNMP manager and agent.<ref>{{Cite book|title= Information Security Management Handbook, Sixth EditioEssential SNMP: Help for System and Network Administrators|author1=Douglas Mauro |author2=Kevin Schmidt |publisher= O'Reilly Media, Inc.|year=2005 |isbn= 9780596552770|pages=21–22}}</ref>