[c-nsp] Re: Graphing multiple PVC's on multipoint ATM subinterface?

Roger Weeks rjw at mcn.org
Thu May 5 12:24:53 EDT 2005


On May 4, 2005, at 8:35 PM, Vinny Abello wrote:

> configmaker does indeed recognize the subinterface. That wasn't a  
> problem I was trying to solve. The problem was that I have one  
> subinterface with dozens of PVC's and I needed the bandwidth  
> utilization on the PVC, not the total traffic on the subinterface  
> which is a sum of all PVC's.
>
(snip)
>
> This provides you with a configuration file that generates 4 unique  
> graphs (pvc's 4/200, 4/201, 4/202, and 4/203)??

Yes it does.  But I think I know why ours does and yours doesn't...

> In our setup the PVC's don't have IP addresses assigned to them on  
> either side. They accept PPPoE connections from our customer's CPE/ 
> Computer. It's just bridged traffic from their side to ours. PPPoE  
> is initiated to provide a transport protocol and assign them an IP  
> address.

Ah, that's the problem, I think.  Cfgmaker doesn't know how to  
uniquely identify those PVCs on the subinterface.  Since each PVC on  
our interface gets an IP address, first using ip unnumbered and the  
helper address to get DHCP, each PVC can be graphed individually.

I would try experimenting with those ifref= and ifdesc= parameters in  
cfgmaker, and see if any of the options there allow you to identify  
each PVC seperately.  It seems there should be something.

> I think I've checked into that among other things. Just haven't  
> switched to anything yet... I was hoping Tobi might have the newer  
> MRTG that's based on rrdtool sometime soon, but I've been waiting a  
> long time for that. :) I should probably just switch to rrdtool  
> with some decent front end. I'd like to still have configurations  
> automatically created if desired though.
>
> 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.

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.

Roger Weeks


More information about the cisco-nsp mailing list