check_snmp to monitor isdn if on cisco?

[Subhendu Ghosh]

Hi Michael

just a note - while the -d option works nicely - but don't use it on any 
routers with a lot of interfaces.  It has to walk thru all the interface 
descriptions and then select the ifIndex and it's operational status.

The imposed load is a bit higher in this case.

-sg

On Thu, 27 Jan 2005, Michael Hüttig wrote:

> Hi Carsten,
> i´m monitoring some serial lines, here my config-snippet:
>
> define service{
> 	host_name		btcis01
> 	service_description	FV-Serial2/0
> 	contact_groups		netz-admins
> 	use				ping-template
> 	check_command	check_cisco_ifoperstatus!Serial2/0
> 	}
>
> define command{
> 	command_name	check_cisco_ifoperstatus
> 	command_line     $USER1$/check_ifoperstatus -H $HOSTADDRESS$  -C public -d $ARG1$
>        }
>
> I think, this should work for you.
>
> Regards
> Michael
>
> Am Mittwoch, 26. Januar 2005 16:20 schrieb Schmitz, Carsten:
>> Hi,
>>
>> Many thanks for the reply.
>>
>>> What do you want to monitor for the isdn connections?
>>
>> I'd like to be able to fetch the status (up or down) of each of the eight
>> ISDN lines from the 2600, and the status of the one DSL line from the 828.
>> Eventually, I'd like to set up nine seperate Nagios service checks, one for
>> each line, which reports "up" or "down".
>>
>> Thanks,
>> Carsten
>>
>>
>> -----Original Message-----
>> From: Subhendu Ghosh [mailto:sghosh at sghosh.org]
>> Sent: Wednesday, January 26, 2005 4:05 PM
>> To: Schmitz, Carsten
>> Cc: nagios-users at lists.sourceforge.net
>> Subject: Re: [Nagios-users] check_snmp to monitor isdn if on cisco?
>>
>> On Wed, 26 Jan 2005, Schmitz, Carsten wrote:
>>> Hi,
>>>
>>> Is anyone using Nagios to monitor the ISDN / SDSL ports on a Cisco 2600
>>> or 828, respectively?
>>>
>>> The network folks told me I should be able to send queries with snmp. Did
>>> that before (I monitor Windows boxes with snmp which works fine). But I
>>> can't get data from the device and I think maybe I have the wrong "oid".
>>>
>>> I'm not an expert on snmp, I pieced together OIDs from
>>>
>>> ftp://ftp.cisco.com/pub/mibs/oid/CISCO-ISDN-MIB.oid   and
>>> http://carsten.familie-doh.de/mibtree/cisco-isdn.html
>>>
>>> and end up with something like this:
>>>
>>> /usr/local/nagios/libexec/check_snmp -H ip_address -C community_string -o
>>> ".1.3.6.1.4.9.9.26.1.1.1.16" SNMP problem - No data recieved from host
>>> CMD: /usr/bin/snmpget -t 1 -r 9 -m ALL -v 1 -c aegongs 212.29.172.2:161 > > .1.3.6.1.4.9.9.26.1.1.1.16
>>>
>>> Anyone done this before and could confirm, or supply me with a valid OID?
>>
>> I haven't done anything with this particular MIB - but your OID is
>> incomplete for check_snmp.
>>
>> the base oid should be  .1.3.6.1.4.9.9.26.1.1.1.1.16 (note four 1s between
>> 26 and 16)
>>
>> To the base oid you need to append the table index values
>> namely:
>> 1. demandNbrPhysIf (the ifIndex value of the D channel for the
>>     neighbor)
>> 2. demandNbrId (a table sequence number)
>>
>>
>> Also the base oid above - is for RowStatus and does not tell you anything
>> about the line being up/down .
>>
>> The NeighborTable only stores call information.
>>
>> for the object descriptions...
>> ftp://ftp.cisco.com/pub/mibs/v2/CISCO-ISDN-MIB.my
>>
>> What do you want to monitor for the isdn connections?
>
>
> **********************************************************************
> Diese E-Mail wurde auf Viren ueberprueft.
> www.mimesweeper.com
> **********************************************************************
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> 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
>

--