[c-nsp] using snmp views effectively

[Rolf Mendelsohn]

Hi Ray,

Thanks for the recommendation (i haven't looked at Cricket for years), but 
currently use cacti / rrdtool and a couple of other utilities for this type 
of monitoring.

Specifically what this customer is looking for is 'triggers' when QoS policies 
are exceeded, i.e. as opposed to having to look at 150graphs of CBWFQ, and 
then see - quality has been degraded due to this policy being exceeded, they 
are interested in a system that can define threasholds and generate reports 
about how the policies are performing.

(If you know an easy open-source program which does this please let me know).

On the other hand, my suspicion of snmp-views is that they become problematic 
to define for a large number of interfaces and various MIB's - does anybody 
have a working example of a number of interfaces - defined in a view for the 
following graphs:

Utilisation(interface)
Errors/Discards(interface)
CBWFQ policies on those interfaces?

tx
/rolf

On Friday 15 September 2006 11:00, Ray Burkholder wrote:
> Here is a slightly different peak at the situation.
>
> Cricket, when coupled with some slightly modified Acktomic tools, is very
> adept at bringing out 'demanding SLA/QoS/ Performance trending
> requirements' in routers.  I have SLA's and QoS settings in may routers,
> and use Cricket to pull this info out. Information can be stored at
> whatever resolution you'd like with a few extra modifications.  The data is
> stored in rrdtool data files.  Rrdtool data is accessible through a simple
> api.
>
> The next cool step is that all the configuration and scanning parameters
> for Cricket are stored in a configuration database.  This is a central
> location desribing all the data and labels stored in the rrdtools files. 
> I've managed to reverse engineer some key queries from this special purpose
> database.
>
> With a few perl scripts, I'm able to query this database for parameters and
> labels, and with a few calls to the rrdtools api, I'm able to pull out data
> and present the data in any fashion I wish.
>
> For your particular requirement, if you need to present authorization
> screens before viewing certain aspects, it is a relative no-brainer with
> another perl script or two.
>
> There is a utility out there called drraw that can be used to configure
> custom graphs from rrdtool data.
>
> So, I think, with not too much extra work, it may be possible to integrate
> some open source tools to take care of your demanding requirements.  On the
> other hand, can you name any specific requirements that may contradict this
> line of reasoning?
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Rolf Mendelsohn
> Sent: Friday, September 15, 2006 04:44
> To: Ed Ravin
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] using snmp views effectively
>
> Hi Ed,
>
> Generally I would agree with you that this is a messy a potential
> problematic approach in many respects.
>
> However as mentioned I have a specific customer with some complex
> enterprise requirements and we cannot build integrate Open Source
> applications to do everything this specific customer needs.
>
> Therfore I'm asking:
>
> Does anybody have reasonable experience with snmp view statements
> (basically to allow: Interface Stats, CBWFQ stats)?
>
> If you do a sample config would be much appreciated, perhaps off-list.
>
> tx
> /rolf
>
> On Thursday 14 September 2006 17:09, Ed Ravin wrote:
> > On Thu, Sep 14, 2006 at 12:33:11PM +0100, Rolf Mendelsohn wrote:
> > > I am wondering if there are any service providers who effectively
> > > deploy complex snmp-view statement in order to allow customers who
> > > have demanding SLA/QoS/ Performance trending requirements to 'view'
> > > the MIB's of their connected interfaces.
> > >
> > > Obviously we don't want them to see all MIB's but there are a large
> > > number which would be required in order to effectively collect this
>
> data.
>
> > When faced with a similar problem a few years ago, I decided it was
> > better to have customers query my Cricket server to see their graphs
> > rather than poke the router directly.  The only catch was, Cricket
> > didn't have any access control, so I had to patch it in.  The patch is
> > available on Sourceforge.
> >
> > If you think about it, it's a lot easier to manage the customers on a
> > separate server rather than the router.  And what if you change your
> > network, change your SNMP communities or switch to SNMPv3, etc?
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> --
> Scanned for viruses and dangerous content at http://www.oneunified.net and
> is believed to be clean.

-- 
Rolf Mendelsohn
ITA/MAXNET
+244 923524981