Adding Cisco Syslog Trap Mappings to Alarms
search cancel

Adding Cisco Syslog Trap Mappings to Alarms

book

Article ID: 195487

calendar_today

Updated On:

Products

CA Spectrum DX NetOps

Issue/Introduction


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.

 

$SPECROOT/SS/CsVendor/Cisco_Router/AlertMap

# ciscoSyslogMIBNotification
1.3.6.1.4.1.9.9.41.2.6.1     0x00210d40 1.3.6.1.4.1.9.9.41.1.2.3.1.2(1,0)\
                                        1.3.6.1.4.1.9.9.41.1.2.3.1.3(2,0)\
                                        1.3.6.1.4.1.9.9.41.1.2.3.1.4(3,0)\
                                        1.3.6.1.4.1.9.9.41.1.2.3.1.5(4,0)\
                                        1.3.6.1.4.1.9.9.41.1.2.3.1.6(5,0)

 

CISCO-SYSLOG-MIB

clogMessageGenerated NOTIFICATION-TYPE
	VARIABLES {
	   clogHistFacility               1.3.6.1.4.1.9.9.41.1.2.3.1.2   DisplayString  
            clogHistSeverity               1.3.6.1.4.1.9.9.41.1.2.3.1.3   SyslogSeverity    
		{
		   emergency(1)
		   alert(2)
		   critical(3)
		   error(4)
		   warning(5)
		   notice(6)
		   info(7)
		   debug(8)
		}
	   clogHistMsgName                1.3.6.1.4.1.9.9.41.1.2.3.1.4   DisplayString  
	   clogHistMsgText                1.3.6.1.4.1.9.9.41.1.2.3.1.5   DisplayString                  
	   clogHistTimestamp              1.3.6.1.4.1.9.9.41.1.2.3.1.6   TimeStamp                      
	}
	DESCRIPTION
	"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."
-- 1.3.6.1.4.1.9.9.41.2.0.1

 

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
   separately.


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.

 

 

Environment

Release : 10.x.x

Component : Spectrum Core / SpectroSERVER

Resolution

 

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

$SPECROOT/SS/CsVendor/Cisco_Router/Rtr.txt

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

SFF8472 2 THRESHOLD_VIOLATION 0xfff00003



**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)

     $SPECROOT/SS/CsVendor/Cisco_Router/EventDisp

** 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 '' 1.3.6.1.4.1.9.9.41.2.0.1 1.3.6.1.4.1.9.9.41.1.2.3.1.2 s "SFF8472" 1.3.6.1.4.1.9.9.41.1.2.3.1.3 i 3 1.3.6.1.4.1.9.9.41.1.2.3.1.4 s THRESHOLD_VIOLATION 1.3.6.1.4.1.9.9.41.1.2.3.1.5 s "Te0/2: Rx power high warning; Operating value:   0.0 dBm, Threshold value:  -3.0 dBm." 1.3.6.1.6.3.18.1.3.0 a <TARGET_DEVICE_IP>

 

 

 

Additional Information

From Spectrum 21.2.4 we are periodically checking for the changes in the Rtr.txt file from the $SPECROOT/custom/Events/ directory instead of the old path $SPECROOT/SS/CsVendor/Cisco_Router/Rtr.txt, and any changes to the file will be automatically updated without the need of SS restart.

Below are the new files location:
Syslog message filter files (Syslog0..7) location.
$SPECROOT/custom/SYSLOG

Syslog to events mapping files location:
$SPECROOT/custom/Events/Switch.txt
$SPECROOT/custom/Events/GenCisco.txt
$SPECROOT/custom/Events/Rtr.txt
$SPECROOT/custom/Events/Pix.txt

 

Syslog Trap Support
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/it-operations-management/spectrum/10-4-2/managing-network/cisco-device-management/cisco-technology-support/syslog-trap-support.html

https://techdocs.broadcom.com/us/en/ca-enterprise-software/it-operations-management/spectrum/22-2/managing-network/cisco-device-management/cisco-technology-support/syslog-trap-support.html


Dynamic Alarm Titles (New Feature as of 10.4.1)
Working with Events and Alarms - Creating Dynamic Alarm Titles
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/it-operations-management/spectrum/10-4-1/managing-network/event-configuration/working-with-events-and-alarms.html