SNMP monitoring of a Dell switch: snmpwalk succeds but check_snmp fails.

[Max]

Hi Rahul,

On Fri, Jan 30, 2009 at 1:06 PM, Rahul Nabar <rpnabar at gmail.com> wrote:
> Ah! Now I am lost! What do you mean by this. Sorry I am a networks newbiee
> and especially SNMP is greek-n-latin to me!

SNMP data is represented as a huge heirarchical tree.  Branches of the
global tree can also be called tables.  Tables are often organized by
purpose.  MIBs map the numerical OID tables to human readable
descriptions.

In tables, entities will often have a representation that is similar
to how data is represented in a table in a database .. there may be a
unique string identifier for an a but there is also a numeric ID
(index number) for the row as well that uniquely identifies it within
the table.

So an interface eth0 in the IF-MIB table of an agent might have a
numeric index of 1.

If you are going to be working a lot with SNMP devices, I recommend
getting a book on SNMP :) and reading online about it.  it is fairly
easy to use once you understand it, but understanding can take some
serious time.

> Actually I am not even sure what I should be monitoring on a switch. I was
> just using the example from the nagios tutorial for now. Maybe its
> "alive/dead status" ; bandwidth of individual ports (but that's mrtg's job
> right?) ; dropped packets; some thermal events? How does one go about this?
> What are other users montoring on their switches and how does one go about
> translating the fairly cryptic SNMP fields into something usable? Should I
> dig into my Dell switch manuals? Or is this reinventing the wheel and Nagios
> has an automated way to achieve this already?

There are a number of metrics you can monitor; which you choose
depends on what is important to your network staff and your project.

Yes, hardware events are good, most managed switches will send SNMP
traps (asyncronous events sent by the monitored entity to the
management station).  Using SNMPTT and Net-SNMP's snmptrapd along with
a simple shell script you can ingest these traps into Nagios and
associate them with passive services on the host they are occuring on.

CPU and memory utilization are always good to watch as well.

There are several MIBs (SNMP tables) that network device agents can
implement.  The most common one is the IF-MIB.  This covers a number
of important, basic, fault management metrics.

For polling, often these metrics from the IF-MIB are desirable:
* Interface status
* Discards in/out
* Errors in/out
* Interface speed

Those are the simple fault management metrics, for performance thresholds:
* Volume in/out
* bits per second in/out

sometimes are used, depending on the context.  ISPs or companies
paying for bandwidth really care about volume and bps

There can be others as well, depending on how mature the SNMP agent on
the device is; a common one that is implemented in agents in a number
of ways is duplex.

Vendors often also implement device-specific MIBs that expose greater
numbers of metrics than standard MIBs do, so please make sure you read
the documentation for your device carefully.

MRTG does not alert based on thresholds, so no, having Nagios poll
performance data doesn't duplicate effort.

However, you might want to look at a framework like PNP
(http://www.pnp4nagios.org) and use that instead of MRTG.  There is a
learning curve to integrating it, but with PNP in place each Nagios
poll can do both fault management and performance trending.

PNP uses RRDtool and is a very flexible and useful framework for
graphing.  There are other graphing frameworks as well, but thus far I
have been the most happy with PNP.

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null