Network management can be passive or active. Passive network management involves the collection of statistical data to profile the network activity of each host. Every variable in the Internet-standard Management Information Base (MIB) has a value that can be queried and used for this purpose.
Active network management uses a subset of MIB variables that are designated read-write. When an Simple Network Management Protocol (SNMP) agent is instructed to modify the value of one of these variables, an action is taken on the agent's host as a side effect. For example, a request to set the ifAdminStatus.3 variable to the value of 2 has the side effect of disabling the network adapter card whose ifIndex variable is set to a value of 3.
Requests to read or change
variable values are generated by manager applications. Three kinds of
requests exist:
Requests are encoded according to the ISO ASN.1 CCITT standard for data representation (ISO document DIS 8825). Each get request contains a list of pairs of variable instances and variable values called the variable binding list. The variable values are empty when the request is transmitted. The values are filled in by the receiving agent and the entire binding list is copied into a response packet for transmission back to the monitor. If the request is a set request, the request packet also contains a list of variable values. These values are copied into the binding list when the response is generated. If an error occurs, the agent immediately stops processing the request packet, copies the partially processed binding list into the response packet, and transmits it with an error code and the index of the binding that caused the error.
The get-next request deserves special consideration. It is designed to navigate the entire Internet-standard MIB subtree. Because all instance IDs are sequences of numbers, they can be ordered.
The first eight instance IDs
are:
A get-next request for a MIB variable instance returns a binding list containing the next MIB variable instance in sequence and its associated value. For example, a get-next request for the sysDescr.0 variable returns a binding list containing the pair (sysObjectId.0, Value). A get-next request for the sysObjectId.0 variable returns a binding list containing the pair (sysUpTime.0, Value), and so forth.
A get-next request for the sysServices.0 variable in the previous list does not look for the next instance ID in sequence (1.3.6.1.2.1.1.8.0) because no such instance ID is defined in the Internet-standard MIB subtree. The next MIB variable instance in the Internet-standard MIB subtree is the first instance ID in the next MIB group in sequence, the interfaces group. The first instance ID in the interfaces group is the ifNumber.0 variable.
Thus, a get-next request for the sysServices.0 variable returns a binding list containing the pair (ifNumber.0, Value). Instance IDs are similar to decimal number representations, with the digits to the right increasing more rapidly than the digits on the left. Unlike decimal numbers, the digits have no real base. The possible values for each digit are determined by the RFCs and the instances that are appended to the variable names. The get-next request allows traversal of the whole tree, even though instances are not known.
The following example is an illustration of an algorithm, not of actual code:
struct binding {
char instance[length1];
char value[length2];
}bindlist[maxlistsize];
bindlist[0] = get(sysDescr.0);
for (i = 1; i < maxlistsize && bindlist[i-1].instance != NULL; i++) {
bindlist[i] = get_next(bindlist[i-1].instance);
}
The fictitious get and get-next functions in this example return a single binding pair, which is stored in an array of bindings. Each get-next request uses the instance returned by the previous request. By daisy-chaining in this way, the entire MIB database is traversed.