Re: mrtg 3 ... a mockup cfg file

Tobias -

We came to the same conclusion you did and are currently testing some
code that uses a perl module as its config.  We included enough stuff
so that a graphing program could understand how to label the results
and do nicities such as converting bytes to bits, ATM cells to bits,
etc.  We do already have a script that can rebuild the perl module
configs so we can refresh our interface list every half hour.

We are currently using SNMP version 2c so we can take advantage of
snmpbulkwalks when collecting data for interfaces - this allows us to
grab both the normal 32 bit counters as well as the 64 bits ones with
less overhead than we used to get with snmpgets for the 32 bit
registers.  I am very much interested in version 3, but haven't
started playing around with that yet.

The end result is that we can collect data for all interfaces on a mix
of 75xx and 120xx (60+ routers) in just over 1 minute.

I will have the programmer who is working on this project (Todd Caine)
send some samples of what he is doing to this list.  He doesn't have
home connectivity, so it will be tomorrow before he will see any of
this discussion.

	     --------------------------------------------
	     Alan Lichty - Supervisor NMS & Applications
	      Electric Lightwave Data & Packet Services
	     Vancouver, Washington         (360)816-4167
	     --------------------------------------------

On Sun, 30 Apr 2000, Henry Steinhauer wrote:

> 
> 
> Tobias -
> 
> One of the thoughts that I have had on the entire SNMP Polling process is the
> following.
> 
> 1 - Possible to use SNMP-V3 for security
> 2 - Possible to use the Bulk read functions ?
> 3 - Possible to grab a whole set of OIDs rather than one at a time.
> 
> Why ?
> 
> If have seen that for some of the switches that I monitor that the SNMP
> processing to report the information takes a long time.  This is true even if
> there is one interface to return or a set of interfaces.  Using the bulk read
> would allow you to gather a whole set of read/write interfaces at the same time
> with one packet. Thus cutting down on the overhead as well as the impact on the
> switch to provide the information.
> 
> Then the MRTG pm could decode these and call RRD to update the tables with the
> interfaces without having to go back to the switch.
> 
> Thoughts ?
> 
> Henry Steinhauer
> 
> 
> --
> Unsubscribe mailto:[email protected]?subject=unsubscribe
> Help        mailto:[email protected]?subject=help
> Archive     http://www.ee.ethz.ch/~slist/mrtg-developers
> 
> 

--
Unsubscribe mailto:[email protected]?subject=unsubscribe
Help        mailto:[email protected]?subject=help
Archive     http://www.ee.ethz.ch/~slist/mrtg-developers