Monday 11 March 2019

Setup Nagios Core for SNMP traps with snmptrapd and snmptt

We'll firstly need to download and execute the installer script from Nagios.com:

sudo yum -y install bzip2

cd /tmp
wget https://assets.nagios.com/downloads/nagiosxi/scripts/NagiosXI-SNMPTrap-setup.sh
sh ./NagiosXI-SNMPTrap-setup.sh

This will install and setup snmptrapd and snmptt while ensuring the firewall is configured properly (udp/162 - however you may wish to lock this down further)

We'll then need to add our MIB's - for this example I'll be using a combination of SG200/300 switches and so will download the MIB's from:

https://software.cisco.com/download/home/284645417/type/283965836/release/1.4.1.03

In the commerical version of Nagios you can add these with ease through the GUI - however if you (like me) are using Core you'll need to use the addmib tool:

cd /tmp
unzip MIBs_Sx200_v1.4.1.03.zip
cd MIBs_Sx200_v1.4.1.03
mkdir /usr/share/snmp/mibs/Cisco-SG200-300
mv *.mib /usr/share/snmp/mibs/Cisco-SG200-300

and add them with:

find /usr/share/snmp/mibs/Cisco-SG200-300 -maxdepth 1 -type f -exec addmib {} \;

We can now send a test trap with:

snmptrap -v 2c -c public localhost '' linkUp ifDescr s eth0 ifAdminStatus i 1 ifOperStatus i 1

You should now see this logged to /var/log/snmptt/snmpttunknown.log

However this wasn't the case for me - everything I was sending was being dropped / didn't show up in the snmptt log. After inspecting the service log for snmptrapd I quickly noticed the following warning:

Mar 11 14:51:33 host.internal snmptrapd[2752]: NET-SNMP version 5.7.2
Mar 11 14:51:33 host.internal systemd[1]: Started Simple Network Management Protocol (SNMP) Trap Daemon..
Mar 11 15:31:28 host.internal snmptrapd[2752]: No access configuration - dropping trap.
Mar 11 15:31:41 host.internal snmptrapd[2752]: No access configuration - dropping trap.

This behaviour is expected by default - as the snmptrapd team decided (wisely) to utilize authentication for incoming SNMP traps - however oddly this shouldn't have been an issue since the installer script from nagios added 'disableAuthorization yes' to '/etc/snmp/snmptrapd.conf' - however after reloading the service all was well - so I can only imagine the config had been added and the service did not reload / restart as intended.

tailing /var/log/snmptt/snmptt.log shows:

Mon Mar 11 16:03:56 2019 .1.3.6.1.6.3.1.1.5.4 Normal "Status Events" localhost - A linkUp trap signifies that the SNMP entity, acting in an eth0 up up

NOTE: Unknown MIB's will be sent to /var/log/snmptt/snmpttunknown.log

You'll also notice that in the nagios logs the following warning:

'Warning:  Passive check result was received for service 'SNMP Traps' on host 'localhost', but the service could not be found!'

So it looks like snmptt is successfully sending the information to nagios - however nagios does not know what to do with it!

We'll proceed by defining the service it's trying to submit data for:

define service {
  name SNMP Traps
  service_description SNMP Traps
  active_checks_enabled 1 ; Active service checks are enabled
  passive_checks_enabled 1 ; Passive service checks are enabled/accepted
  parallelize_check 1 ; Active service checks should be parallelized
  process_perf_data 0
  obsess_over_service 0 ; We should obsess over this service (if necessary)
  check_freshness 0 ; Default is to NOT check service 'freshness'
  notifications_enabled 1 ; Service notifications are enabled
  event_handler_enabled 1 ; Service event handler is enabled
  flap_detection_enabled 1 ; Flap detection is enabled
  process_perf_data 1 ; Process performance data
  retain_status_information 1 ;
  retain_nonstatus_information 1 ;
  check_command check-host-alive ;
  is_volatile 1
  check_period 24x7
  max_check_attempts 1
  normal_check_interval 1
  retry_check_interval 1
  notification_interval 120
  notification_period 24x7
  notification_options w,u,c,r
  contacts contact1,contact2
  register 0
}

define service {
  use SNMP Traps
  host_name localhost
  service_description TRAP
  check_interval 120
}

We can then test the serviced is working correctly with:

/usr/local/nagios/libexec/eventhandlers/submit_check_result localhost TRAP 2 "TESTING"

The changes should now be reflected on the nagios check status.

The next step is to load the relevant MIB files so we can translates the O.I.D's. In this tutorial we will be checking link status of a port so we'll need 'IF-MIB..txt' (which should come as part of the default installation - if not see here: http://www.net-snmp.org/docs/mibs/IF-MIB.txt)

We'll proceed by generating the snmptt.conf with:

rm -rf /etc/snmp/snmptt.conf
snmpttconvertmib --in=/usr/share/snmp/mibs/IF-MIB.txt --out=/etc/snmp/snmptt.conf --exec='/usr/local/nagios/libexec/eventhandlers/submit_check_result $r TRAP 2'

Open up the snmptt.conf file and ensure that the EXEC line for EVENT 'linkUp' returns 0 opposed to '2' and leave EVENT 'linkDown' as it is.

and reload the service with:

sudo service snmptt reload

We can then test it with: snmptrap -v 2c -c public localhost '' linkDown ifDescr s fa0/1 ifAdminStatus i 0 ifOperStatus i 0

and then check it reverts with:

snmptrap -v 2c -c public localhost '' linkUp ifDescr s fa0/1 ifAdminStatus i 0 ifOperStatus i 0

0 comments:

Post a Comment