[mrtg] Re: Handling successive counter rollovers

Mon Jan 8 18:23:57 MET 2007

Hello Duane -
That does return a value, but that is not the OID for the highspeed 
counters. When run with the correct OID, I get:

perl ~/scripts/snmpget.pl -v2c -c public 216.218.206.69 1.3.6.1.2.1.31.1.1.1.10
1.3.6.1.2.1.31.1.1.1.10 = noSuchInstance: noSuchInstance

...and when I run cfgmaker with snmp v2 specified on the command 
line, I get this message for all ports:

--base: snmpget public at 216.218.206.69:::::2:v4only for ifHighSpeed.24 
-> 1000 Mb/s
--base: snmpget public at 216.218.206.69:::::2:v4only for ifHCInOctets.24 ->
--base: check for HighspeedCounters failed ... Dropping back to V1

...so that leads me to believe that 64bit counters are not available.

Ed

At 05:44 AM 1/8/2007, Perry, Duane wrote:
>I have some older equipment that will not do SNMP v2 but almost 
>everything less than 5 years old will do v2.  Test it by issuing:
>
>snmpget -v2c -c community xxx.xxx.xxx.xxx .1.3.6.1.2.1.2.2.1.10.port:::::2

1.3.6.1.2.1.31.1.1.1.10
1.3.6.1.2.1.2.2.1.10

>
>Substituting your community, ip address and port of course.  If it 
>works, just add the :::::2 on the end of your Target line and no 
>more rollovers until terabit comes along.
>
>Duane Perry
>University of Missouri
>
>-----Original Message-----
>From: mrtg-bounce at list.ee.ethz.ch 
>[mailto:mrtg-bounce at list.ee.ethz.ch] On Behalf Of Ed LaFrance
>Sent: Sunday, January 07, 2007 12:42 PM
>To: mrtg at list.ee.ethz.ch
>Subject: [mrtg] Handling successive counter rollovers
>
>Hello all -
>
>I am running mrtg 2.15.0 on linux, monitoring various ports on a Gpbs
>managed switch. I've run into an issue on the uplink port, which has
>the most traffic. The Octet counters are not 64 bit, and with a
>5-minute polling interval, it appears that multiple successive
>counter rollovers can happening in between mrtg runs. In other words
>OutOctets will roll over before a data capture, then run all the way
>up and roll over again *before* the next data capture, and so on -
>sometimes this will happen several times in succession, and the
>result is artificially low traffic reports on that interface. I've
>verified this by capturing the Octets out on that particular
>interface at one minute intervals to a log file - note the counter
>has reset by every fifth capture almost like clockwork:
>
>1.3.6.1.2.1.2.2.1.16.24 = Counter: 275615047
>1.3.6.1.2.1.2.2.1.16.24 = Counter: 1099703953
>1.3.6.1.2.1.2.2.1.16.24 = Counter: 1977232053
>1.3.6.1.2.1.2.2.1.16.24 = Counter: 2938038189
>1.3.6.1.2.1.2.2.1.16.24 = Counter: 3871828929
>1.3.6.1.2.1.2.2.1.16.24 = Counter: 425011425
>1.3.6.1.2.1.2.2.1.16.24 = Counter: 1217557647
>1.3.6.1.2.1.2.2.1.16.24 = Counter: 2024459227
>1.3.6.1.2.1.2.2.1.16.24 = Counter: 2896359311
>1.3.6.1.2.1.2.2.1.16.24 = Counter: 3803224615
>1.3.6.1.2.1.2.2.1.16.24 = Counter: 384017160
>1.3.6.1.2.1.2.2.1.16.24 = Counter: 1265435349
>1.3.6.1.2.1.2.2.1.16.24 = Counter: 2157523201
>1.3.6.1.2.1.2.2.1.16.24 = Counter: 2885065373
>1.3.6.1.2.1.2.2.1.16.24 = Counter: 3742325451
>1.3.6.1.2.1.2.2.1.16.24 = Counter: 210382955
>
>
>I am trying a test right now in which mrtg is config'ed for the
>default nominal interval of 5 minutes, but I am actually capturing
>data every 3 minutes to avoid the successive rollovers. It seems to
>be working when I compare it to the data from my provider (who
>monitors their side of the uplink), but I suspect that this is not
>the proper way to handle things - is it? I realize that as traffic
>goes up, I'll have to increase the capture frequency further. I know
>the mrtg logfile contains a timestamp for each actual capture, so I
>guess I'm asking if my solution is 'legal'. I've been using 95.pl
>with mrtg and I want to continue doing this, so going to a different
>monitoring tool is not desired.
>
>Thanks in advance!
>
>Ed
>
>===============================================================
>:::::::::::::     PREMIUM COLOCATION SERVICES     :::::::::::::
>===============================================================
>New Media LLC                    info at servercolocation.ws
>11630 Fair Oaks Blvd., #300      http://www.servercolocation.ws
>Fair Oaks, CA  95628             (916) 961-0446
>(866) 519-4680 Toll-Free         (916) 961-0447 Fax
>===============================================================
>
>--
>Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
>Archive     http://lists.ee.ethz.ch/mrtg
>FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org
>WebAdmin    http://lists.ee.ethz.ch/lsg2.cgi
>

===============================================================
:::::::::::::     PREMIUM COLOCATION SERVICES     :::::::::::::
===============================================================
New Media LLC                    info at servercolocation.ws
11630 Fair Oaks Blvd., #300      http://www.servercolocation.ws
Fair Oaks, CA  95628             (916) 961-0446
(866) 519-4680 Toll-Free         (916) 961-0447 Fax
=============================================================== 

--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://lists.ee.ethz.ch/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org
WebAdmin    http://lists.ee.ethz.ch/lsg2.cgi