SNMPv2c and 64-bit Counters

The standard integer in SNMP MIB2 is 32 bits long. SNMPv2C MIB defines a new type of integer with the attribute name unsigned64 that is 64 bits long. Its maximum value is:

18,446,744,073,709,551,615

The reason for specifying such a large counter is found in rfc2233:

“As the speed of network media increase, the minimum time 
in which a 32 bit counter will wrap decreases. For 
example, a 10Mbs stream of back-to-back, full-size 
packets causes ifInOctets to wrap in just over 57 
minutes; at 100Mbs, the minimum wrap time is 5.7 
minutes, and at 1Gbs, the minimum is 34 seconds. 
Requiring that interfaces be polled frequently enough 
not to miss a counter wrap is increasingly problematic.”

Note that NNM handles a single counter wrap properly, but if two counter wraps occur between SNMP samples, the result is bad data. Recall that you suggested using a five-minute sample interval for SNMP data collections (See “Estimating SNMP Data Sample Rates” on page149). Here you see that ordinary fast Ethernet interfaces must be sampled at almost exactly this speed to avoid counter wrap in highly utilized situations. Since it is impossible to know in advance how utilized a circuit is, all of them have to be sampled at five-minute intervals to avoid a wrap. If you use the SNMPv2C 64-bit counters, you can tolerate a larger sample interval for SNMP historical data collections.

The new SNMPv2C 64-bit counters are found in the IfXEntry branch in the interfaces section of MIB2, as shown in Figure 9-9. You can find detailed definitions for them in rfc2233.

Figure 9-9. 64-bit counters in SNMPv2C.

This is the extended interface section defined by SNMPv2C. Note the Counter64 variables such as ifHCInOctets and ifHCOutOctets are sufficient such that a 1-terabit/second (1,000 Gbps.) link will cause the counter to wrap in just under five years. The old ifSpeed variable is limited to about 2.2Gbps, while the new ifHighSpeed variable measures in units of 1,000,000 bits per second.

IfXEntry ::= 
       SEQUENCE {> 
           ifName                     DisplayString,
           ifInMulticastPkts          Counter32, 
           ifInBroadcastPkts          Counter32, 
           ifOutMulticastPkts         Counter32, 
           ifOutBroadcastPkts         Counter32, 
           ifHCInOctets               Counter64, 
           ifHCInUcastPkts            Counter64, 
           ifHCInMulticastPkts        Counter64, 
           ifHCInBroadcastPkts        Counter64, 
           ifHCOutOctets              Counter64, 
           ifHCOutUcastPkts           Counter64, 
           ifHCOutMulticastPkts       Counter64,
           ifHCOutBroadcastPkts       Counter64, 
           ifLinkUpDownTrapEnable     INTEGER, 
           ifHighSpeed                Gauge32, 
           ifPromiscuousMode          TruthValue, 
           ifConnectorPresent         TruthValue, 
           ifAlias DisplayString, 
           ifCounterDiscontinuityTime TimeStamp 
       }

Note that NNM makes a standard configuration check for every SNMP-capable device to determine if it supports SNMPv2C. This check can be disabled by specifying the -2 option in $OV_CONF/ netmon.lrf. Some devices and systems may misbehave, log a message, or display a warning when they receive an SNMPv2C request. This netmon option avoids the problem. It’s better in the long term to update the offending SNMP agents while temporarily unmanaging these devices or putting their IP addresses in netmon.noDiscover.

It is not advisable to manage gigabit Ethernet without using 64-bit counters.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.128.206.48