Does your SNMP manager properly support counters? This page will provide you with information that will allow you to test out your manager to see if it supports the following:
The value of a counter is the number of occurences of an event or the measure of a flow modulo the range of the counter, which is 2^32 or 2^64 in SNMP. The single value of a counter is meaningless without having a starting value at a point in time. Also, unless specified in the definition, the initial value of an object that is a counter is undefined. For example, if the value of a counter object is, say, 304, you cannot make any conclusions about what has occured. However, if you previously obtained the value of the counter 40 seconds ago and the value was 144, then you could conclude that 160 units of what the counter was measuring had occured in 40 seconds. And you could compute an average rate of 40 units per second over the last 40 seconds. Figure 1 shows the behavior of a 32-bit counter rollover.
A properly engineered SNMP manager will include a check for counter rollover in its calculation of rates from raw counter values. Figure 2 shows a manager taking periodic samples of a counter and computing a rate for each interval. The length of each period must be chosen so no more than one rollover can occur in a period. A manager must account for rollover in its rate calculation.
During operation, a counter may become disabled and re-enabled. This is called a counter discountinuity. To be able to detect discountinuities, each counter must have an associated time-related indicator of when the last counter discountinuity occured. The default object is sysUpTime, defined in RFC 1213 and updated in RFC 1907. However, a MIB designer may choose another object to indicate a discountinuity. A manager must be given the object that indicates a discountinuity for a counter. A manager cannot assume that object sysUpTime indicates discountinuities for all objects. Figure 3 shows a strip chart of a counter value and the computed rate. Note that the value is sampled only periodically, and the rollover of the counter appears as its value descreasing. A discountinuity is indicated in the chart by a break in the graph.
The SNMPv1 protocol does not support the Counter64 data type. The SNMPv2c, SNMPv2u, and SNMPv3 protocols support both the Counter32 and Counter64 data types. A multi-lingual SNMP agent supporting Counter64 objects must exclude then from all views when a request uses the SNMPv1 protocol. That is, when using the SNMPv1 protocol, GET and SET operations return noSuch errors and GETNEXT operations skip over Counter64 objects. However, there are several approaches that can be taken with the existing data types in SNMPv1 to support the functionality of 64-bit counters using the SNMPv1 protocol.
The BER tag for the Counter (or Counter32) data type is 0x41. The BER tag for Counter64 is 0x46. Values are encoded as signed integers. Therefore, values for 32-bit counters greater than or equal to 2^31 require five octets to encode the value. And, values of 64-bit counters greater than or equat to 2^63 require nine octets to encode the value. For example, the value 2^31 (2147483648 decimal) for a Counter32 data type is encoded in BER as 0x41050080000000, where 0x41 is the tag, 0x05 is the length, and 0x80000000 is the value.
Some early implementations of the BER encoding of values greater than or equal to 2^31 were incorrectly encoded in four octets. For example, the value of 2^31 was incorrectly encoded as 0x410480000000 instead of the correct encoding as 0x41050080000000.
There has not been widespread deployment of data type Counter64. In normal operation, a counter rollover could take many years for typical objects. Thus, testing might not have occured for large values. The BER encoding might be done incorrectly for values greater than 2^63, just as it was done for large values of 32-bit counters. On computers (or languages) that do not directly support 64-bit unsigned integers, a manager might not have added support for parsing or displaying 64-bit unsigned numbers. Some implementations have stored 64-bit counter values is double precision floating point numbers. If so, the complete range for 64-bit counters is not available. The actual range is typically between 52 and 56 bits depending of the floating point encoding used. (You get 52 bits of precision of values using the IEEE encoding format. In the IEEE format for doubles, there is 1 bit for the sign, 11 bits for the exponent, and 52 bits for the fraction (mantissa).)
Since a 64-bit counter data type is not available in the SNMPv1 protocol, many MIBs that contain 64-bit counters also contain 2 32-bit counters to specify the same value. That is, for each object that has data type of Counter64, there are also 2 objects with data type of Counter32. Such a counter is called a split counter. A manager that supports the SNMPv1 protocol should be able to be directed to obtain the two objects used to split a 64-bit counter. Figure 4 shows a 64-bit counter split into 2 32-bit counters.
Another approach to support 64-bit counters in the SNMPv1 protocol is the return the value in a DisplayString object. And yet another approach is to use the Opaque data type return to return the value.
A correct and fully implemented manager must have the following behaviors:
A test MIB module was created to help you test your SNMP manager. Click here to get the MIB module. Click here to get the OID list for the MIB module. The MIB module has the following objects:
Test sub-agents have been written using a commercial SNMP agent toolkit and the SNMP package from UC-Davis. The sub-agent using the commercial toolkit is unfortunately not available at this time. However, the sub-agent using the UC-Davis package is available in both source and binary form. Binaries have been created for Linux, HPUX v10.20, and Solaris v2.5.1.
Click here for information on the UC-Davis sub-agent.
Click here for general information on the UC-Davis SNMP project.
To test your manager, set it up to poll each 64-bit counter. Does it ask for a discountinuity indicator object? Change the values of objects sitCtrInitHigh & sitCtrInitLow to see if the manager indicates a discountinuity. Change the values of objects sitCtrInitHigh & sitCtrInitLow to a high value so a rollover will occur after several polling periods. Did you manager correctly compute the rate (or did you get a negative rate)? Can you specify that you want to use split counters for a 64-bit counter? Can you indicate that you have a counter value encoded in ASCII and have the manager parse it and turn it into a 64-bit counter? Can you indicate to your manager that a 64-bit counter is encoded in an Opaque data type and have it turn it into a 64-bit counter? What happens when you try to obtain a 64-bit counter using the SNMPv1 protocol?
This test of your manager was provided so you could determine the capabilities in your manager in supporting 64-bit counters. It also demonstrates that 64-bit counters can be supported using the SNMPv1 protocol using three approaches, which are 1) split counters, 2) ASCII encoding, and 3) Opaque data type encoding.
Last updated 23-Jun-1998.
Copyright © 1998, SNMPinfo. All rights reserved.