|
|
In this implementation, the SNMP commands that get or set variables are getid, getmany, getnext, getone, setany, and snmpstat. All these commands contain a community name for authentication and one or more OIDs to refer to the variables[1] they are interested in retrieving or modifying. When a network administrator issues one of these commands, an SNMP Protocol Data Unit (PDU) is generated and handed over to the authentication mechanism. The authentication mechanism, in turn, returns a string of bytes that are subjected to further conversion before being sent over the transport service, usually using UDP.
The agent, upon receiving this UDP message, first converts the string of bytes in the message into a form it can understand and then performs authentication checks using the community name field contained therein. Upon passing authentication, the agent takes necessary actions to get or set the variable and issues a response indicating success or failure of the operation, which is then interpreted by the management station.
There are five different types of PDU used in SNMP. They are:
The commands getid and getone use the get operation while the command setany uses the set operation. The commands getnext, getmany, and snmpstat use the getnext operation. ``Flow diagram of the get/getnext operation'', and ``Flow diagram of the set operation'', illustrate flow sequences that take place during get and set operations.
Flow diagram of the get/getnext operation
Flow diagram of the set operation
The getnext operation deserves special mention here since it works differently from others. The OID contained in a PDU formed as a result of this operation is taken by the agent, and an object instance whose OID is lexicographically next to this OID is retrieved. For example, referring to ``Flow diagram of the set operation'', if the OID contained in a getnext request is 1.3.6.1.2.1.2.2.1.7.2 ifAdminStatus.2, the agent looks for the lexicographically next variable, which could be ifAdminStatus.3, and returns its value. Similarly, when the OID contained in the request is 1.3.6.1.2.1.2.2.1.7.3 (ifAdminStatus.3), the lexicographically next variable chosen by the agent could be 1.3.6.1.2.1.2.2.1.8.1 (ifOperStatus.1). Thus, it can be seen that the getnext operation could be useful in retrieving values of object instances even when the management station is not aware of the instances of an object, as is done by getnext. It could also be useful in retrieving values of all object instances under a subtree of the MIB by starting with the OID of the root object of the subtree, as is done by getmany. ``Flow diagram of the trap operation'', illustrates the flow sequence that takes place during the trap operation.
Flow diagram of the trap operation