SNMP GetPrev: an efficient way to browse large MIB tables

The simple network management protocol (SNMP) is a widely used standard for management of devices in Internet protocol networks. Part of the protocol great success is due to its simplicity; all the managed information is kept in a management information base (MIB) that can be accessed using SNMP queries to a software agent. We develop a general model that abstract the data retrieval process in SNMP. In particular, we study the amount of queries (communication) and time needed to randomly access an element in this model. It turns out that this question has practical importance. For some network management applications, e.g., MIB browsing, there is a need to traverse portions of a MIB tree, especially tables, in both directions. While the GetNext request defined by the SNMP standard allows an easy and fast access to the next columnar object instance or next scalar object, there is no corresponding operator defined in the SNMP framework for retrieving the previous MIB object instance. This, in effect, allows an efficient MIB traversal only in one direction and makes the search in the reverse direction problematic. This paper presents and analyzes the GetPrev application, a tool that enables the retrieval of the previous instances of a columnar objects or scalar MIB objects. Our GetPrev application uses only standard SNMP GetNext and Get requests to carry on a fast and bandwidth efficient search for the required object instance. For example, as predicted by our analysis and shown by our experiments, retrieving a value of the last columnar object instance in a large forwarding table (ipForwardTable) containing about 3000 entries can take several minutes using a sequence of the GetNext requests (the straightforward approach used, e.g., by widely deployed snmpwalk and snmptable applications). The GetPrev application presented in this paper retrieves this value using no more than 20 GetNext requests (in most cases about seven requests), taking no more than a second (i.e., it is two orders of magnitude faster and two to three orders of magnitude less bandwidth consuming).