SNMP Status Messages

[CountryLife08]

Hello All,

So the company I work for is using Nagios to monitor our hosts and core, in the host group we monitor the Ping of each host machine, in the Services tab we monitor various assets attached to our switches. I have done a search and did not find anything relating to my question, but did find some helpful hints to accomplish some other tasks.

My question... using check_snmp! I am trying to determine Operation Status, is there an active connection/cable on said port, this is mainly for the conference rooms and public lobbies, cafe, etc. of our building. My code is as follows:

check_snmp!-C public -o ifOperStatus.(port) -p (SNMP Port) so the end result looks like check_snmp!-C cafepublic -o ifOperStatus.15 -p 2500.

Now if the port is active and linked out to a device Nagios shows the Service as OK with Status Information showing "SNMP Warning - 1, if the admin is up and there is no link (someone unplugged) then I still get Nagios showing "OK" but with a status message of "SNMP Warning - 2". This is 80% of our equipement, 20% shows an unlinked port as yellow "WARNING" and then status information of "SNMP Warning - *2*".

How can I make all Link Status or OperStatus show in the WARNING group when the link show SNMP Warning 2?

Thank you,
Jon

[lgroschen]

Are you using Nagios Core or Nagios XI. I'll move this when I get a better idea.

Here is a good option. I did them without a -p since mine is configured for the default SNMP port (161). Then I added an '-r 1' which is a regex for '1' that will output a warning if not found (-w 1) and the -c 2 is to ensure it's not a critical unless it finds 2:

Code: Select all

[root@XIdevel tmp]# /usr/local/nagios/libexec/check_snmp -H 192.168.5.55  -C public -o ifOperStatus.1 -r 1 -w 1 -c 2
SNMP OK - 1 | IF-MIB::ifOperStatus.1=1;1;2; 
[root@XIdevel tmp]# /usr/local/nagios/libexec/check_snmp -H 192.168.5.55  -C public -o ifOperStatus.2 -r 1 -w 1 -c 2
SNMP WARNING - *2* | IF-MIB::ifOperStatus.2=2;1;2;

1 is set as up and 2 is down in my switch UI. Can you run this for the port in question and see if the response works as you would like it? I would test the down part by unplugging the cord on that port to make sure it works as you want it to.

[CountryLife08]

Luke,

I am using Nagios Core the DIY version. We are on a CentOS 6 machine and running 4.0.4 and are using the check_snmp plugin I believe. So most of the services have corrected to either WARN or CRITICAL based on the criteria we have given the script. However, now several services have gone to unknown, I know the switch in that conference room is dead but I added the -c 2 to the code but nothing changed. I think it may be a MIB error.

[CountryLife08]

It seems as though my last response vanished into cyberoblivion.

Luke,

Thank you, so it turns out I was missing the -w and/or -c variables in the codes, I have them setup now and for the most part all of the services have responded correctly and are now in WARNING or CRITICAL based on what we programmed. One issue I have hit now is that a switch in one of my conference rooms is down/dead and the SNMP check goes out and comes back as unknown, I think it is timing out, but for some reason it looks like Nagios is using the wrong MIB file.

So the code is the same as the others I think except that I subbed 2 for 3 which should be unknown right?

Code: Select all

check_snmp!-C PRAIRIERead -o ifOperStatus.48 -p 6098 -r 1 -w 1 -c 3

I get this following error regarding a Ruckus MIB, Ruckus is the enterprise wireless system that runs of the core switch, what I am reaching out to monitor is an edge switch.

external command error: No log handling enabled - turning on stderr logging
Did not find 'ruckusCommonDHCPModule' in module RUCKUS-ROOT-MIB (/usr/share/snmp/mibs/RUCKUS-DHCP-MIB.txt)
Unlinked OID in RUCKUS-DHCP-MIB: ruckusDHCPMIB ::= { ruckusCommonDHCPModule 1 }
Undefined identifier: ruckusCommonDHCPModule near line 23 of /usr/share/snmp/mibs/RUCKUS-DHCP-MIB.txt
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPClientExternalConfGroup ::= { ruckusDHCPConfGroups 2 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPClientConfGroup ::= { ruckusDHCPConfGroups 1 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPClientExternalRenew ::= { ruckusDHCPClientExternal 1 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPClientExternal ::= { ruckusDHCPObjects 2 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPClientInfo ::= { ruckusDHCPObjects 1 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPClientEntry ::= { ruckusDHCPClientTable 1 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPCompliance ::= { ruckusDHCPCompliances 1 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPMIB ::= { ruckusCommonDHCPModule 1 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPCompliances ::= { rucksDHCPConformance 2 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPConfGroups ::= { rucksDHCPConformance 1 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPClientTable ::= { ruckusDHCPClientInfo 1 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPClientLeaseTime ::= { ruckusDHCPClientEntry 4 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPClientSubnetMask ::= { ruckusDHCPClientEntry 3 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPClientIPAddress ::= { ruckusDHCPClientEntry 2 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPClientHWAddress ::= { ruckusDHCPClientEntry 1 }
Cannot adopt OID in RUCKUS-DHCP-MIB: rucksDHCPConformance ::= { ruckusDHCPMIB 3 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPClientEvents ::= { ruckusDHCPMIB 2 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPObjects ::= { ruckusDHCPMIB 1 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPClientConfGroup ::= { ruckusDHCPConfGroups 1 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPClientExternalConfGroup ::= { ruckusDHCPConfGroups 2 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPClientExternalRenew ::= { ruckusDHCPClientExternal 1 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPClientInfo ::= { ruckusDHCPObjects 1 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPClientExternal ::= { ruckusDHCPObjects 2 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPClientEntry ::= { ruckusDHCPClientTable 1 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPCompliance ::= { ruckusDHCPCompliances 1 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPMIB ::= { ruckusCommonDHCPModule 1 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPConfGroups ::= { rucksDHCPConformance 1 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPCompliances ::= { rucksDHCPConformance 2 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPClientTable ::= { ruckusDHCPClientInfo 1 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPClientHWAddress ::= { ruckusDHCPClientEntry 1 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPClientIPAddress ::= { ruckusDHCPClientEntry 2 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPClientSubnetMask ::= { ruckusDHCPClientEntry 3 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPClientLeaseTime ::= { ruckusDHCPClientEntry 4 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPObjects ::= { ruckusDHCPMIB 1 }
Cannot adopt OID in RUCKUS-DHCP-MIB: ruckusDHCPClientEvents ::= { ruckusDHCPMIB 2 }
Cannot adopt OID in RUCKUS-DHCP-MIB: rucksDHCPConformance ::= { ruckusDHCPMIB 3 }
Timeout: No Response from 12.345.67.89:6098.

[lgroschen]

Here the regex is looking for 1 which is a warning -r 1. If you wanted to look for another type you would do -r and the value.

If you up the -w and -c that will be the count of the -r that it found. So -r 1 -w 1 -c 3 would critical if it found 3 warnings, which I don't think would be possible with a single output message. The -w -c will basically be a way to detect the output you want and trigger a warning or critical based on the output. So if you do -r 3 -w 1 -c 2 it would give you a warning if it finds an unknown (3). If you do -r 3 -w 1 -c 1 it will give you a critical for any unknowns found.

As for the MIB error I would delete all your current RUCKUS-DHCP-MIB and dependencies. It looks like that MIB requires a module to run and make sure you have all of the following from the IMPORTS section in that MIB. Especially the FROM lines which will be imported:

Code: Select all

IMPORTS
    ruckusCommonDHCPModule
        FROM RUCKUS-ROOT-MIB
    MODULE-IDENTITY,
    OBJECT-TYPE,
    IpAddress,
    Unsigned32
        FROM SNMPv2-SMI
    OBJECT-GROUP,
    MODULE-COMPLIANCE
        FROM SNMPv2-CONF
    MacAddress,
    TruthValue
        FROM SNMPv2-TC;

[CountryLife08]

Luke,

So I went ahead and gave that code a try but for some reason when the switch times out I get an unknown instead of a critical. Is there anywhere else that might be changing the response?

Thank you,

Jonathan Burkholder

[lgroschen]

can you post your command and output from the CLI?

[CountryLife08]

Luke,

This is my code, I defined the equipment name.com in the hosts file, if I use the IP then it does the same thing and I tried a few random ports.

Code: Select all

/usr/local/nagios/libexec/check_snmp -H PRAIRIE.com -C PRAIRIERead -o ifOperStatus.10 -p 6098 -r 3 -w 1 -c 1

My out put came back as Timeout: No Response from RICHW.com:6098 if I use the IP it does the same but with the IP and then port number. I am aware the equipment is offline, it is down for repair right now, what I can't figure is how to tell Nagios the timeout is critical vs. unknown.


Thank you for your help,

Jonathan Burkholder

[lgroschen]

So as I understand it, when the device is down you want it to send a critical.

Code: Select all

[root@XIdevr21 tmp]# /usr/local/nagios/libexec/check_snmp -H 192.168.5.55 -C public -o ifOperStatus.2 -r 1 -w 1 -c 2
SNMP WARNING - *2* | IF-MIB::ifOperStatus.2=2;1;2; 
[root@XIdevr21 tmp]# /usr/local/nagios/libexec/check_snmp -H 192.168.5.55 -C public -o ifOperStatus.2 -r 1 -w 1 -c 1
SNMP CRITICAL - *2* | IF-MIB::ifOperStatus.2=2;1;1;

Here's the plugin output from the nagios-plugins developer guidelines documentation:

Code: Select all

-----------
0 -  OK 
-----------
The plugin was able to check the service and it appeared to be functioning properly

-----------
1 -  Warning
-----------
The plugin was able to check the service, but it appeared to be above some "warning" threshold or did not appear to be working properly

-----------
2 - Critical
-----------
The plugin detected that either the service was not running or it was above some "critical" threshold

-----------
3 - Unknown
-----------
Invalid command line arguments were supplied to the plugin or low-level failures internal to the plugin (such as unable to fork, or open a tcp socket) that prevent it from performing the specified operation. Higher-level errors (such as name resolution errors, socket timeouts, etc) are outside of the control of plugins and should generally NOT be reported as UNKNOWN states.

If you want to check if the device is down or up then you should use a different plugin or service to check up vs down since check_snmp needs to connect to the device to receive a 0,1 or 2.

[CountryLife08]

Luke,

Awesome, thank you, I am having to learn and reverse engineer what someone put in place, I will check other plugins!

Thank you very much,

Jonathan Burkholder