cannot calculate octets

Subtract the numbers from two polls, and divide the difference by 300 to get bytes/sec.

Sorry, quite difficult to understand.. Let me try.

I've got these output every 60 seconds (not 300)

in 4114816394 | out 1416674403 in 4120532506 | out 1419886543

you said "substract" from two polls.. I cannot understand this.

Really thanx if you can help me

It's a continuous counter(until it reaches the 64-bit limit), so you have to substract the last poll from the actual poll to get the actual value. In other words: polling the values does not reset the counters, it's relative values.

Oh.. I see.. so maybe I'm driving in the wrong way!

I need to measure the input and output bandwidth via snmp in the moment I type the command snmpget. In other words.. I need to see the fomous 5 minutes output and 5 minutes input of "show interface" IOS command by snmp

Thanx.

Nicolaj Kamensek ha scritto:

Subtract. Like the - key on the calculator?

4120532506-4114816394 = 5716112 bytes per 60 seconds

Or about 762 kbps

The OP indicated ifInOctets and ifOutctets . Those are 32 bit counters. The 64 bit counters are ifHCInOctets and ifHCOutOctets, and according to one of Cisco's documents, the 64 bit counters are not supported on interfaces of less than 20 Mbps.

In another thread, the same original poster indicated that the device in question is a Cisco 2600 router. According to the above Cisco web page, the 2600 series does not support 64 bit counters.

The original poster must therefor worry about the counters wrapping, and must make adjustments in the calculations for that. I described the adjustments to the original poster in an earlier posting, in which I specifically indicated the calculations required to get the kb/s values the poster wanted. Unfortunately the original poster did not appear to read (or understand) my posting.

So, I undertsand this:

I have:

in 4114816394 | out 1416674403 in 4120532506 | out 1419886543

I type this math calculation:

4120532506 - 4114816394 = 5716112 5716112 * 8 = 45728896 45728896 / 1000 = 45728 45728 / 60 = 762

Walter, I red your nice post. I banged my head on this problem some years ago.. becouse my mrtg on certain interface crashes the png graphic cos I use 32 bit octets but

64.. In this case I use a cisco 2600 on a simple 2mb interface (Sorry I didn't say) so I think is not the case to get via snmp the ifHCInOctets values.

I'm just a unix sysadmin.. my boss say to me to write a script who monitor the traffic router and output the result in ascii way.. the problem is explain him what "4120532506" Octets is :)

now is quite clear..

762 kbps is more human readble

isn't it? :P

Walter Roberson ha scritto:

Yes, the octet difference, However, if the second reading appears to be less than the first reading, then you have to add 2^32 to the first reading before doing the subtraction.

Yes, convert octets to bits.

That would convert bits per time interval into kilobits per time interval.

Yes, kilobits per time interval divided by the time interval in seconds returns kilobits per second.

However, if you are typing in the commands manually, you are not going to be able to take a reading every 60 seconds: you probably will not do better than every 58 to 62 seconds. An error of 2 seconds in the timing would give about a 3% error in the rate calculation.

At the very least, you should write a little script that prints out the time and then does a single snmp get of two values; I would suggest that printing out the time again afterwards would help you determine how accurate the figures were.

Unix systems administrators often know a lot about how systems and networks really work.

Unix systems administrators often have the privilege to install things like MRTG and present nice coloured graphs to their bosses (hint, hint).

Sam