Adding Cisco Syslog Trap Mappings to Alarms


Article ID: 195487


Updated On:


CA Spectrum CA eHealth


DX NetOps Spectrum has the ability to process Syslog Traps from Cisco devices and map the traps to events that can raise alarms. Out of the
  box Spectrum maps the default trap to an event 0x00210d40.



# ciscoSyslogMIBNotification     0x00210d40,0)\



clogMessageGenerated NOTIFICATION-TYPE
	   clogHistFacility        DisplayString  
            clogHistSeverity        SyslogSeverity    
	   clogHistMsgName         DisplayString  
	   clogHistMsgText         DisplayString                  
	   clogHistTimestamp       TimeStamp                      
	"When a syslog message is generated by the device a
                 clogMessageGenerated notification is sent.  The
                 sending of these notifications can be enabled/disabled
                 via the clogNotificationsEnabled object."


The problem is that syslog traps can contain a wide variety of messages that should not all be treated the same. Spectrum contains logic to 
   filter and match syslog traps based upon facility, severity, and the mnemonic and generate separate event id's which then can be handled

Spectrum's documentation provides a good explanation of this process.

Syslog Trap Support

This KB article will serve as a supplement to the documentation and will map the following syslog trap to a new event and raise an alarm in Spectrum.


Jun 27 03:00:52.167 CDT: %SFF8472-3-THRESHOLD_VIOLATION: Te0/2: Rx power high warning; Operating value:   0.0 dBm, Threshold value:  -3.0 dBm.




Release : 10.x.x

Component : Spectrum Core / SpectroSERVER



We will start by generating a new event ID to be generated when the following syslog is sent to Spectrum %SFF8472-3-THRESHOLD_VIOLATION.

- In the Event Configuration GUI



- Configure the new Event to raise an Alarm



- File ~~> Save All (this should push out to the OneClick and SpectroSERVERs)



- The device I was testing with was a Cisco Router so I modified the Rtr.txt file


I added <facility> <severity> <mnemonic> <event code>


**Interestingly although the severity is 3  (%SFF8472-3-THRESHOLD_VIOLATION) the mapping is 2-3 to orange and
     the 3 gets bumped to a 2 when processed. So the entry in the Rtr.txt needs to be 2 otherwise it will not process. Testing with
     1 and it was bumped it down to 0 (0-1 red critical)**


- EventDisp
    When we generated our new event id above the entry was added in the $SPECROOT/custom/Events/ area. In order for this
       syslog parsing to work the entry needs to be moved to the $SPECROOT/SS/CsVendor/ directory in the same folder as the
       Rtr.txt (if switches same folder as the Switch.txt, if Pix same folder as Pix.txt see documentation)


** The SpectroSERVER has an internal Inference Handler to process the 0x00210d40 event, parse the Rtr.txt/Switch.txt/Pix.txt files, and the EventDisp for 
       a match and the new event code.



- Next, I triggered the SpectroSERVER to reload event files
OneClick ~~> VNM ~~> SpectroSERVER Control ~~> Update Event Configuration


To test the configuration, I used snmptrap on a Linux system to simulate this syslog trap

snmptrap -v 2c -c SysLogTest  <SS_IP_ADDRESS>:162 '' s "SFF8472" i 3 s THRESHOLD_VIOLATION s "Te0/2: Rx power high warning; Operating value:   0.0 dBm, Threshold value:  -3.0 dBm." a <TARGET_DEVICE_IP>




Additional Information

Syslog Trap Support

Dynamic Alarm Titles (New Feature as of 10.4.1)
Working with Events and Alarms - Creating Dynamic Alarm Titles