monitoring cisco via snmpget

Sure, looks fine. Hopefully you have a real community name, and SNMP is blocked to the outside world as well.

They are in Octets :), just like the MIB says (an octet is a fancy word meaning byte).

So, this is how many bytes have crossed the interface since last poweron, or the last time the 32-bit counters wrapped.

Multiply by 8 to get bits. Divide by 1000 to get kilo, divide by your time measurement delta in seconds to get seconds.

Wouldn't you be scripting this? No, its not going to harm your router. What do you think MRTG (or any other statistics package) does?

Now walking the whole ARP cache on a big switch/router every minute might start chowing some CPU... Or the whole routing table on a core internet router.

These are bytes. Octet is another (better?) word for byte.

mrtg can do what you want if you have the time and skill to set it up.

very quick and easy but not neaqrly so capable. I think you just run the exe.

It displays Octets/Bytes per second. Multiply by 8 to get bits per second. I usually multiply by 10 since that is good enough in almost all situations.

Getting graphs is slightly non-intuitave.

You have to select the mib, press start, then select the instance THEN Add to Graph.

It is a bit clunky and unless you have a very fast computer is slow but I use it a lot.

Be aware that many MIBS are 16 bit values and they wrap at about 4,000,000,000. getif doe not handle this well.

You cannot save the data except by screenshot either.

It is FREE.

Getting 2 MIBs every 60 seconds will not affect the router. Getting 100 every second may well.

sh proc cpu is your friend.

Those look plausible. Myself, usually use the numeric OID instead of the MIB name, in order to avoid the overhead of parsing the MIB files each time the command fires up. Also, you should likely be able to poll both values with a single snmpget command, which would reduce overhead.

To get kb/s you need to record the time you took each sample, do a difference in octets between the recordings, divide by the time difference, and convert from octets to kilooctets.

If your router is highly loaded already it could cause problems.

If I recall correctly, mrtg will (with minor configuration) take

1 minute readings. *Possibly* you might have to make a small change to it to keep a full two hours around instead of summarizing it.

One issue you should think about a bit, is that if the interfaces are fast interface or are highly loaded, the traffic counters you are polling might overflow -- they are only 32 bit counters. [Cisco generally provides 64 bit counters as well as 32 bit counters, but we'd need more information about your IOS release to know whether you have that support or not. ] Thus, your calculation routines should not merely take the difference in counters: they should check to see if the new counter appears to be less than the old one, and if so then assume that the new counter is 2^32 higher than it appears. Then you just have to worry about restarts and interface counter clearing, and about the possibility of having more than

2^32 octets of traffic in one minute (which corresponds to about 1/2 gigabit per second.)

Oh :) that's great.. thanx!

I'm using rrdtool too.. it is a very nice tool, quite complex but really powerfull. My questions cos every kind of tool do a "query" every 5 minutes..

rrdtool graph too.. So I just wanna be sure every 1 minute is not usefull.

Thanx again!

Doug McIntyre ha scritto: