cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2625
Views
30
Helpful
27
Replies

Multiple Event SNMP Triggers in a script.

IAN HOLMES
Level 1
Level 1

I gather EMM 2.4 now allows multiple Event triggers for SNMP in the one script. Do I just add the ::cisco::eem::event_register_snmp oid lines multiple times ?? And how do I differentiate the $_snmp_oid_val values returned from the different Events in order to call upon them separately ??

1 Accepted Solution

Accepted Solutions

Try this as a workaround:

:cisco::eem::event_register_snmp tag 1 oid 1.3.6.1.4.1.9.9.42.1.5.2.1.27.12 get_type exact entry_op ge entry_val 2 poll_interval 10

::cisco::eem::event_register_snmp tag 2 oid 1.3.6.1.4.1.9.9.42.1.5.2.1.26.12 get_type exact entry_op ge entry_val 2 poll_interval 10

::cisco::eem::trigger {

::cisco::eem::correlate event 1 or event 2

::cisco::eem::attribute tag 1 occurs 1

::cisco::eem::attribute tag 2 occurs 1

} occurs 1

Note: there is a single space before the '}' character.

View solution in original post

27 Replies 27

Joe Clarke
Cisco Employee
Cisco Employee

You're mixing terminology here. Are you using a script (in which case you'd use the ::cisco::eem notation) or an applet (in which case $_snmp_oid_val would be a valid variable). In either case, it's not as simple as specifying an event registration multiple times. You have to correlate the multiple events. See http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6555/ps6815/whitepaper_c11-492226.html for more details an some examples.

If you still need help, please spell out what you'd like to do, and I can cook up an example policy for you.

Looked at link, yes my mistake mixing terminology. Only learnt about EEM a few days ago, so steep learning curve. I want to use scripts as I need the calculation ability therein. But it appears even though we can look at multiple correlated events, I can only get one oid_val passing to the script to use in the variable calculations, that I can differentiate and then pass to other variables for summing etc.

Basically I wanted to monitor PacketLossSD, DS and MIA for a given IP SLA process.....polling it every 10 seconds, and at the end of a given total period, maybe 1 or 5 minutes, send a trap containing the number of errored 10 second intervals, and the total lost packets grouped for the three catagories.

My thoughts so far is that I would need three separate scripts per IP SLA UDP-Jitter process......which would probably simplify the message handling in the SNMP trap receiver.....I have tested the applet function with multiple events correlated with the OR function.....and when they are triggered I can see syslog entries for both oid_val variables being sent to the log, but I cannot see how I can use the equivalent options in a script to then set a new variable to the specific oid_val. I supposed the tag function would assist me, but I don't know the syntax to define say a command like "set variable1 [{tag 1} oid_val]" and "set variable2 [{tag 2} oid_val]" I suspect the bracketing is wrong, but just guessing in an attempt to explain what I am trying to obtain. With these separate variables I hoped to use IF statements to loop a certain number of times and sum the variable values along with instance counts, to then populate a single trap string.

Actually I think I just need to be able to make an OID snmp Get, after the trigger occurs, from within the script. Setting the various variables required with multiple Gets, for my calculations and traps if required. What commands can I use to perform Get SNMP OID within the script.

The command you want is sys_reqinfo_snmp. For example, to get sysDescr.0:

array set snmp_result [sys_reqinfo_snmp oid 1.3.6.1.2.1.1.1.0 get_type exact]

This array, snmp_result, will consist of two elements: oid and value:

puts $snmp_result(oid)

result>>> 1.3.6.1.2.1.1.1.0

puts $snmp_result(value)

result>>> Cisco IOS Software, 7200 Software (C7200-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2008 by Cisco Systems, Inc.

Compiled Fri 11-Jul-08 04:22 by prod_rel_team

You wouldn't need three policies for this. You could do it all in one policy using EEM contexts. In a script, to get the OID value, you need to use event_reqinfo. For example:

array set arr_einfo [event_reqinfo]

puts $arr_einfo(val)

result>>> 10

See http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_eem_policy_tcl.html for more on writing EEM policies in Tcl. If you want an EEM context example, let me know.

Thank you for the command sets and examples. I think with those and some practice I can create the outputs I need.....I was stumped thinking I needed to bring the snmp oid values in via the event triggers. Very good. I now have a bunch of TCL pieces still to put together.....and I am assuming from your next post, that I need to be familiar with the process of storing these values in an array in order to recall them each time the events trigger or prior to sending traps.

Can I clarify one other aspect......if I were to have many IP SLA processes for different endpoints, and a separate script customised for each, would the array for storing values have to be unique......obviously OID's will be, to track the different IPSLA processes, and the script names.......but are the variables then defined with a local context or global ??

The array name could be a combination the IPSLA process ID.....

The final piece of the puzzle for me, is, I can get the trap to present the applet name (using the applet for testing purposes), but the OID value and the strdata string doesn't show. The syslog of the same info works fine. Am I doing something wrong here ?

action 1.0 syslog priority critical msg "LostPacketsMIA: $_snmp_oid_val"

action 1.1 snmp-trap strdata "LostPacketsMIA: $_snmp_oid_val" intdata1 10

Read the information about contexts in the EEM Tcl link I showed you. Contexts will allow you to persist EEM data across policy invocations. This way, you can store history from previous policy executions, and react on that history accordingly.

If you had multiple EEM policies, each would need to use a custom context name to persist their data.

What does the trap actually look like? A raw sniffer trace of the trap PDU would help.

For the traps I am relying on the output from a script that one of my associates is running, so I suspect I may not be seeing everthing presented. If the action statements look O.K. then I will get a complete dump of them during business hours. I have read the previous link info....now with a TCL handbook and your advice I will see what I can get working. Thanks once again and I will show you what I get completed....you will probably cringe at what comes out. But thanks again for all your assistance and I have been very impressed by the power of this EEM feature to really leverage the power of the Cisco kit.

You should also check out the example scripts at http://www.cisco.com/go/ciscobeyond . I have posted a few policies there (some using contexts).

Since upgrading to 12.4(20)T I have not had one trap sent..... show event manager history traps registers a trap being sent. But debug snmp packets shows nothing and I am no longer receiving anything at the remote end. What is the most stable version with EEM 2.3 running ? That does still trap. I have double checked and the IOS upgrade changed the snmp-server statements from enabel traps rtr to ipsla.

My EEM test router now runs 12.4(20)T. I was previous using 12.4(15)T3 without problems. I just tested on my router, and I did get a trap:

snmp-server enable traps event-manager

snmp-server host 14.32.100.33 public ds1 ds3 config event-manager

event manager applet traptest

event none

action 1.0 strdata "XXX: This is a test" intdata1 3

When I run this policy, I get:

Sep 7 20:20:09 nms-server2 snmptrapd[90209]: 2008-09-07 20:20:09 14.32.100.75(via UDP: [14.32.100.75]:56604) TRAP, SNMP v1, community public CISCO-EMBEDDED-EVENT-MGR-MIB::cEventMgrMIB Enterprise Specific Trap (CISCO-EMBEDDED-EVENT-MGR-MIB::cEventMgrPolicyEvent) Uptime: 1 day, 11:21:04.27 CISCO-EMBEDDED-EVENT-MGR-MIB::ceemHistoryEventType1.3 = Gauge32: 131 CISCO-EMBEDDED-EVENT-MGR-MIB::ceemHistoryEventType2.3 = Gauge32: 0 CISCO-EMBEDDED-EVENT-MGR-MIB::ceemHistoryEventType3.3 = Gauge32: 0 CISCO-EMBEDDED-EVENT-MGR-MIB::ceemHistoryEventType4.3 = Gauge32: 0 CISCO-EMBEDDED-EVENT-MGR-MIB::ceemHistoryPolicyPath.3 = STRING: CISCO-EMBEDDED-EVENT-MGR-MIB::ceemHistoryPolicyName.3 = STRING: applet: traptest CISCO-EMBEDDED-EVENT-MGR-MIB::ceemHistoryPolicyIntData1.3 = INTEGER: 3 CISCO-EMBEDDED-EVENT-MGR-MIB::ceemHistoryPolicyIntData2.3 = No Such Instance currently exists at this OID CISCO-EMBEDDED-EVENT-MGR-MIB::ceemHistoryPolicyStrData.3 = STRING: XXX: This is a test CISCO-EMBEDDED-EVENT-MGR-MIB::ceemHistoryEventEntry.13.3 =

All fine.....my mistake. I had defined the "rtr" flag on the snmp-server host line, and this was then converted to "ipsla".....but either way was working and sending all traps. But after the upgrade, the command began restricting to just IPSLA traps as is probably designed, and so I needed to add the "event-manager" flag, and all is now working. Ignore the bumblings of the un-edumakated.

Our systems guys are cursing me, as the OID's in the trap are incrementing each time. They are related to the EEM MIB, but they are defined with the last value as the job number as defined in the history command. Hence they are unable to grab the specific fields and pass them through to the logs. Is there any way to make them persistent ? The 305 value is that specific event as seen in history list.

-------- START --------

203.174.20.249

UDP: [203.174.20.249]:52024

.1.3.6.1.2.1.1.3.0 1:12:36:38.35

.1.3.6.1.6.3.1.1.4.1.0 .1.3.6.1.4.1.9.10.91.0.2

.1.3.6.1.4.1.9.10.91.1.2.3.1.2.305 51

.1.3.6.1.4.1.9.10.91.1.2.3.1.3.305 0

.1.3.6.1.4.1.9.10.91.1.2.3.1.4.305 0

.1.3.6.1.4.1.9.10.91.1.2.3.1.5.305 0

.1.3.6.1.4.1.9.10.91.1.2.3.1.6.305 ""

.1.3.6.1.4.1.9.10.91.1.2.3.1.7.305 "applet: LostPacketsDSRichmond "

.1.3.6.1.4.1.9.10.91.1.2.3.1.9.305 10

.1.3.6.1.4.1.9.10.91.1.2.3.1.10.305 No Such Instance currently exists at this OID

.1.3.6.1.4.1.9.10.91.1.2.3.1.11.305 "LostPacketsDS: 2"

.1.3.6.1.4.1.9.10.91.1.2.3.1.13.305 0

.1.3.6.1.4.1.9.10.91.1.2.3.1.14.305 0

.1.3.6.1.4.1.9.10.91.1.2.3.1.15.305 0

.1.3.6.1.4.1.9.10.91.1.2.3.1.16.305 0

-------- END --------

All fine.....traps now propagating to our logs. They were searching too deep along the OID structure. All working fine. Now onto the scripts as per the examples supplied. Very cool stuff and powerful. Thanks.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: