looking for a plugin to monitor changes on Cisco routers

[juliobaglivo]

Hi all, hope you are fine. I'm looking for a plugin which informs Nagios when a change is made in a Cisco router.
Thank you for your help
Julio Baglivo

[jsmurphy]

I think the only way to do this would be to set up passive SNMP monitoring... the Cisco mibs for many devices have an "on configuration change" (or something to that affect) entry that you could use to send a trap with.

This isn't the easiest to set up with Nagios Core (XI makes it a little easier as the tools are pre-configured) I would begin by reading and investigating the following:
snmptt - http://xavier.dusart.free.fr/nagios/en/snmptraps.html
Nagios passive checks - http://nagios.sourceforge.net/docs/3_0/ ... hecks.html

[ethanpickering]

I think the only way to do this would be to set up passive SNMP monitoring... the Cisco mibs for many devices have an "on configuration change" (or something to that affect) entry that you could use to send a trap with.

This isn't the easiest to set up with Nagios Core (XI makes it a little easier as the tools are pre-configured) I would begin by reading and investigating the following:
snmptt - http://xavier.dusart.free.fr/nagios/en/snmptraps.html
Nagios passive checks - http://nagios.sourceforge.net/docs/3_0/ ... hecks.html

How long would the whole setup usually take? I am planning to implement the passive SNMP monitoring. Thanks.

[jsmurphy]

The install itself doesn't take too long, what will take a while is importing the mib files and then manually classifying them... which will depend on the size of your environment or the breadth of your passive monitoring needs.

[crfriend]

The install itself doesn't take too long, what will take a while is importing the mib files and then manually classifying them... which will depend on the size of your environment or the breadth of your passive monitoring needs.

From experience, I will second jsmurphy's assertion. I took the hard route using the NET-SNMP "snmptrapd" as a base and extending that with a perl-based "traphandler" that uses a MySQL backend to determine what to do with traps it receives. Traps that it knows about can get transmitted to users via e-mail (useful where there is a lot of data in the traps) or submitted to Nagios Core as a "passive check" (volitile at that) with a sane "return code" (OK, WARN, CRIT) and one OID for context that shows up in the "output". Traps that it does not know about go to me directly via e-mail so I can "classify" them (i.e. set the dispatch mechanism (e-mail or Nagios), and the "return code" and "output OID"); it also de-dups traps that arrive more often than once every 10 minutes, but that's trivially configurable.

As always, the devil is in the details, and some SNMP agents benefit wonderfully from having authors that use different trap OIDs for failure and recovery events (e.g. "power loss" and "power restored") and other SNMP agents suffer horribly from authors that do not use OIDs in that manner. In the former case, it's easy to classify traps to set Nagios statuses accordingly; in the latter, it's usually better to transmit the things via e-mail or have the Nagios operators manually submit "passive checks" to clear the offending traps when the trouble has been fixed.