[c-nsp] Re: Graphing multiple PVC's on multipoint ATM
subinterface?
Andre Beck
cisco-nsp at ibh.net
Fri May 6 07:46:16 EDT 2005
On Thu, May 05, 2005 at 09:24:53AM -0700, Roger Weeks wrote:
> On May 4, 2005, at 8:35 PM, Vinny Abello wrote:
>
> > Any suggestions on keeping the automatic config generation with
> > configmaker or something equivalent using rrdtool as the backend
> > and a nice front end, anyone? :) I'm sure it's out there in several
> > flavors.
>
> We were using an MRTG cgi front-end called Routers2.cgi, and rrdtool
> for the graphing, and I just found it wasn't flexible enough to
> support DSL aggregation routers. It works great if you're graphing
> enterprise routers. I used it a few years ago at a large telecom
> company to graph their whole US network, hundreds of routers, with no
> problem.
MRTG with rrdtool as backend is a nice way to migrate existing MRTG
installations to if they just stop to scale, but I wouldn't propose
it for new installations.
One of the major systems that scaled better than MRTG and was deployed
by a lot of people was Cricket, but AFAIK it stopped to evolve any
further some years ago.
If you look for something that does auto discovery (and can be extended
in the ways doing that discovery), seems to scale to large networks
and works by means of templates and XML configuration, have a look on
Torrus. AFAIK it is the only free solution available that can monitor
Cisco's QoS MIBs. I dont think it already supports direct ATM PVC
monitoring, but if any, than Torrus could easily be extended to do so.
Stan is always looking for patches and code additions or, as well,
sponsors to such additions.
> Cacti does away with MRTG and cfgmaker altogether and uses its own
> polling engine, but still uses RRDTOOL for the graphing. All the
> configuration is web-based - so it's not totally automated. I have
> to click a few times in a web page to generate a new config for a
> router, but compared to what I was doing with mrtg it's a huge
> timesaver.
Cacti is IMO great for prototyping RRDs, but I'm not sure whether it
scales for large network monitoring. It is way too granular IMO, but as
you can create a config for a whole router with a few clicks now, I'd
likely have to look on it again - seems it got features for templating
and building compounds. In Torrus you would just add the router to one
of your .ddx files, run "torrus devdiscover", run "torrus compilexml"
and off you go with a new box in your monitoring.
HTH,
Andre.
--
The _S_anta _C_laus _O_peration
or "how to turn a complete illusion into a neverending money source"
-> Andre Beck +++ ABP-RIPE +++ IBH Prof. Dr. Horn GmbH, Dresden <-
More information about the cisco-nsp
mailing list