Better way to check Cisco switches?

[Chad Rhyner]

Regarding check_ping critical issues...

For this particular issue, the high pings that you are seeing could be
indicative of a problem, and not necessarily false positives.  High ping
times could be indicative of a saturated link, or other problems.  If you
have time, look into the problem by checking the health of the switch or
router.  Playing around with the *check_interval, retry_interval,
max_check_attempts * values can help you avoid the pitfalls of the false
positives happening while still making the check_ping checks still provide
valuable alerts indicative of an issue within the network.  Tweaking these
values sometimes seem to be more of an art than a science, but it is doable.

Regarding SNMP checks helping...

We use some SNMP checks which can help.  Of particular interest for routers
and switches, it is beneficial to know when either receive or transmit
queues are seeing any kind of errors, such as a transmit error, CRC error,
etc.  To do this, you need to turn SNMP on the router, and utilize the *
snmpwalk* command in Linux to determine the MIBs you have available
(check *snmpwalk
--help* for usage).  Once you have found a stat you want you can use the *
check_snmp* plugin to get alerts on your SNMP data that you are interested
in.

In addition, the new *check_snmp* plugin from the nagios_plugins package
(version 1.4.15) can provide information so that you can check the rate on
the stat, which can be beneficial for some stats, such as the amount of
packets or bytes of traffic that is going through the interface.

Hope this helps!

It is not perfect, but this another useful way that we have found problems
with our routers/switches.
On Jul 5, 2011 6:42 AM, "Bailey, Damian S." <baileyds at lcps.k12.va.us> wrote:
> Good morning!
>
>
>
> After posting a bit ago, I found that other Nagios users experienced the
> same issue I did in relying on the check_ping routine when monitoring
> Cisco switches - they would occasionally return false critical; however,
> the switches were actually still online and would immediately recover.
>
>
>
> So this leads me to the obvious question - how do you all use Nagios to
> effectively monitor Cisco switches? Is there a better way to check
> these with snmp? Something else?
>
>
>
> Thanks!
>
>
>
> Damian Bailey
>
> Lead Technician | LCPS Technology
>
>
>
> From: Bailey, Damian S.
> Sent: Monday, June 27, 2011 11:55 AM
> To: 'nagios-users at lists.sourceforge.net'
> Subject: new to Nagios - known issue w/ Cisco switch host checks?
>
>
>
> We're new to using Nagios but I've grown to love it! In using the
> product to perform host checks on our Cisco switches, I find that they
> "randomly" will fail, then recover almost immediately.
>
>
>
> I think the host checks use ping to verify that the switches are active.
>
>
>
>
> Is there something I am likely doing wrong, or should I look at our
> network as a possible cause? Our network itself isn't perfect...but I
> don't want to go looking for problems if it's a nagios issue.
>
>
>
> Thanks for any help. I'll be glad to provide more info if needed.
>
>
>
> Damian Bailey
>
> Lead Technician | LCPS Technology
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20110705/ccc8a55a/attachment.html>
-------------- next part --------------
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
-------------- next part --------------
_______________________________________________
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