Get Next Request

A manager uses a get-next request to retrieve management information from an agent, just as with a get request. However, contrary to an ordinary get request, the OIDs in the variable bindings do not specify the objects that are to be retrieved directly. Instead, for each OID specified in the request, the agent is requested to return the object with the OID that comes in lexicographical order right after that OID. An OID supplied with a get-next request can be but does not have to be an OID of an actual object.

For example, assume that an agent has a MIB with objects as depicted in Figure 8-1. If the manager issues a get-next request with an OID of 0, it is equivalent to the manager having issued a get request for the object with the lowest lexicographical OID in the MIB—in this case, the instance of countA with an OID of 1.3.6.1.387.5.1.1.0. This is the object that will be returned. The manager could also have issued a get-next request for the OID 1.2, or 1.3, or 1.3.6.1.350, or 1.3.6.1.387.5.1—they would all have resulted in the same object to be returned.

Figure 8-1 Navigation of a MIB with Get-Next

Figure 8-1 Navigation of a MIB with Get-Next

To abbreviate the OIDs a bit, let us in the following substitute the prefix 1.3.6.1.387.5 with the word myMib. With this notation, the OID of the countA object is myMib.1.1.0. If the manager subsequently issues a get-next request with the OID of the countA instance that was returned with the response to the previous get-next request, the object instance with the first subsequent OID will be returned—namely, myMib.1.2.0; that is, not countA, but countB. In other words, a get-next request directed at countA has the same effect as a get request directed at the object after it, countB.

By the same token, a get-next request that specifies the OID of an object type is equivalent to the get request of the OID of the first object instance of that object type—the object with the lowest index in case of a columnar object, or the only object instance in case of a scalar. In this example, a get-next of myMib.1.2 (the countB object type) is equivalent to a get of myMib.1.2.0 (the countB object instance). A get-next of myMib.2.2.1.2.2 is equivalent to a get of myMib.2.2.1.2.3 (column B in the third row—in other words, the row with index 3—of xyzTable). And so on. The dashed arrows in the figure indicate the way the MIB is traversed with the get-next if each subsequent get-next operation contains the OID of the object that was returned in response to the previous get-next operation.

So why would anyone need an operation like this, when a manager could use a get request and simply specify the desired object's OID directly? The reason is that in quite a few situations, the manager actually might not know what objects are in a MIB and hence what OIDs to ask for. Using get-next requests, a manager can effectively discover an agent's MIB. The manager can simply start with an OID of 0 to retrieve the first object, use that object's OID to retrieve the next one, and so forth. This pattern of iterative get-next requests is also called walking a MIB.

Being able to walk a MIB is especially useful in the case of MIB tables. In many cases, entries in a table are dynamically created and deleted by the agent—the contents of the table change over time, and with it do the indexes of the objects in the table. An example is a MIB table that represents a routing table because routing table entries are subject to occasional change through routing protocols. To traverse a table, for example, you can simply start with the OID of the table—not an instance of a columnar object within the table, but the OID given to the table definition in the MIB specification. The agent then returns the object with the first OID lexicographically behind it—that is, the first columnar object of the first row in the table. With the OID of that object, you continue on until you get to an object that, per its OID, is no longer part of the table. At that point, you know you have reached the end.

Interestingly, the way the get-next operation works means that a table is traversed by column, not by row. Remember that the OIDs of the columnar objects in the MIB are formed by concatenating the object type definition with the table index. This means that for any columnar object in the table, every index needs to be traversed before get-next finally moves on to the next columnar object type, or the next column in the table. Consider again the example from Figure 8-1. When issuing a get-next operation for OID myMib.2.2.1.2.2, the next OID will be myMib.2.2.1.2.3 (the object in the next row of the same column), not myMib.2.2.1.3.2 (the next column in the same row).

So what if you want to retrieve a table row by row? This is still possible, of course. Just as with the get operation, a manager can specify several variable bindings with several OIDs to retrieve in the same get-next request (the same message-length limitations apply). The agent returns the object with the next lexicographical OID for each of the OIDs specified. Therefore, one way in which a manager can retrieve a table row by row is by specifying several OIDs in the same get-next request at the same time. Each OID designates a different columnar object type, but with the same index. This way, get-next iterations proceed along multiple objects in multiple columns at the same time. Figure 8-2 illustrates this. For xyzTable/Entry, you can substitute your favorite MIB table, such as a table with operational data for your device's interfaces; for colA, colB, and colC, you can substitute the columnar objects of its table entries that you are interested in, such as the number of packets that were sent over the interfaces, the number that were received, and the number that were received but discarded.

Figure 8-2 Row-by-Row Navigation of a MIB with Get-Next

Figure 8-2 Row-by-Row Navigation of a MIB with Get-Next

Was this article helpful?

+1 0

Post a comment