Simple Network Management Protocol - SNMP Tutorial

30.9 Simple Network Management Protocol

　　Network management protocols specify communication between the network management client program a manager invokes and a network management server program executing on a host or router. In addition to defining the form and meaning of messages exchanged and the representation of names and values in those messages, network management protocols also define administrative relationships among routers being managed. That is, they provide for authentication of managers.

　　One might expect network management protocols to contain a large number of commands. Some early protocols, for example, supported commands that allowed the manager to: reboot the system, add or delete routes, disable or enable a particular network interface, or remove cached address bindings. The main disadvantage of building management protocols around commands arises from the resulting complexity. The protocol requires a separate command for each operation on a data item. For example, the command to delete a routing table entry differs from the command to disable an interface.

　　As a result, the protocol must change to accommodate new data items. SNMP takes an interesting alternative approach to network management. Instead of defining a large set of commands, SNMP casts all operations in a fetch-store paradigm⁶. Conceptually, SNMP contains only two commands that allow a manager to fetch a value from a data item or store a value into a data item. All other operations are defined as side-effects of these two operations. For example, although SNMP does not have an explicit reboot operation, an equivalent operation can be defined by declaring a data item that gives the time until the next reboot and allowing the manager to assign the item a value (including zero).

　　The chief advantages of using a fetch-store paradigm are stability, simplicity, and flexibility. SNMP is especially stable because its definition remains fixed, even though new data items are added to the MIBand new operations are defined as side-effects of storing into those items. SNMP is simple to implement, understand, and debug because it avoids the complexity of having special cases for each command. Finally, SNMP is especially flexible because it can accommodate arbitrary commands in an elegant framework.

　　From a manager's point of view, of course, SNMP remains hidden. The user interface to network management software can phrase operations as imperative commands (e.g., reboot). Thus, there is little visible difference between the way a manager uses SNMP and other network management protocols. In fact, vendors sell network management software that offers a graphical user interface. Such software displays diagrams of network connectivity, and uses a point-and-click style of interaction.

　　As Figure 30.6 shows, SNMP offers more than the two operations we have described.

　　Operations get-request and set-request provide the basic fetch and store operations; response provides the reply. SNMP specifies that operations must be atomic, meaning that if a single SNMP message specifies operations on multiple variables, the server either performs all operations or none of them. In particular, no assignments will be made if any of them are in error. The trap operation allows managers to program servers to send information when an event occurs. For example, an SNMP server can be programmed to send a manager a trap message whenever one of the attached networks becomes unusable (i.e., an interface goes down).

30.9.1 Searching Tables Using Names

　　We said that ASN.1 does not provide mechanisms for declaring arrays or indexing them in the usual sense. However, it is possible to denote individual elements of a table by appending a suffix to the object identifier for the table. Unfortunately, a client program may wish to examine entries in a table for which it does not know all valid suffixes. The get-next-request operation allows a client to iterate through a table without knowing how many items the table contains. The rules are quite simple. When sending a get-next-request, the client supplies a prefix of a valid object identifier, P. The agent examines the set of object identifiers for all variables it controls, and sends a response for the variable that occurs next in lexicographic order. That is, the agent must know the ASN.1 names of allvariables and be able to select the first variable with object identifier greater than P. Because the MIB uses suffixes to index a table, a client can send the prefix of an object identifier corresponding to a table and receive the first element in the table. The client can send the name of the first element in a table and receive the second, and so on.

　　Consider an example search. Recall that the ipAddrTable uses IP addresses to identify entries in the table. A client that does not know which IP addresses are in the table on a given router cannot form a complete object identifier. However, the client can still use the get-next-request operation to search the table by sending the prefix:

iso . org . dod. internet. mgmt . mib . ip . ipAddrTable . ipAddrEntry . ipAdEntNetMask

which, in numeric form, is:

1.3.6.1.2.1.4.20.1.3

　　The server returns the network mask field of the first entry in ipAddrTable. The client uses the full object identifier returned by the server to request the next item in the table.

⁶ The fetch-store paradigm comes from a management protocol system known as HEMS. See Partridge and Trewitt [RFCs 1021, 1022, 1023, and 10241 for details.

Abstract from Internetworking With TCP/IP Vol I: Principles, Protocols, and Architecture Fourth Edition,

DOUGLAS E. COMER,

Department of Computer Sciences Purdue University, West Lafayette, IN 47907,

PRENTICE HALL,

Upper Saddle River, New Jersey 07458