Multiple Event SNMP Triggers in a script.

Answered Question
Sep 6th, 2008

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 ??

I have this problem too.
0 votes
Correct Answer by Joe Clarke about 8 years 4 weeks ago

Try this as a workaround:

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

::cisco::eem::event_register_snmp tag 2 oid 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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (7 ratings)
Joe Clarke Sat, 09/06/2008 - 12:58

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

IAN HOLMES Sun, 09/07/2008 - 00:57

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.

IAN HOLMES Sun, 09/07/2008 - 03:22

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.

Joe Clarke Sun, 09/07/2008 - 06:43

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

array set snmp_result [sys_reqinfo_snmp oid get_type exact]

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

puts $snmp_result(oid)


puts $snmp_result(value)

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

Technical Support:

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

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

Joe Clarke Sun, 09/07/2008 - 06:52

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 for more on writing EEM policies in Tcl. If you want an EEM context example, let me know.

IAN HOLMES Sun, 09/07/2008 - 07:32

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

Joe Clarke Sun, 09/07/2008 - 07:52

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.

IAN HOLMES Sun, 09/07/2008 - 08:07

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

IAN HOLMES Sun, 09/07/2008 - 16:12

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.

Joe Clarke Sun, 09/07/2008 - 16:21

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 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 UDP: []: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 =

IAN HOLMES Sun, 09/07/2008 - 17:48

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

IAN HOLMES Mon, 09/08/2008 - 02:05

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

UDP: []:52024

. 1:12:36:38.35

. .

. 51

. 0

. 0

. 0

. ""

. "applet: LostPacketsDSRichmond "

. 10

. No Such Instance currently exists at this OID

. "LostPacketsDS: 2"

. 0

. 0

. 0

. 0

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

IAN HOLMES Mon, 09/08/2008 - 03:43

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.

IAN HOLMES Tue, 09/09/2008 - 07:37

Traps don't match expected behaviour. I cannot get the system to consistently trap when an access-list blocks packets. I see the logged packets blocked, the IP SLA job only shows them after it has compeleted. And it appears that is when the OID values are updated. Therefore I have brought the SLA job frequency down to 10 seconds....and the applet event poll to 2 seconds. I am getting more traps as expected, but still some fail to be triggered. What is the function of the Increment does it handle the OID counter wrap ? The system just seems to go to sleep.....I can see the OID walk showing a value > 0 and the polling event applet just doesn't seem to grab it....even though it should be testing every 2 seconds.

Joe Clarke Tue, 09/09/2008 - 07:45

You'll need to provide the actual show run from the device. I'm not really sure what you're seeing.

IAN HOLMES Tue, 09/09/2008 - 08:02

I have attached the key config. It is not really clear but I have blocked multiple times and nothing is captured. Then suddenly one will work. The OID value is only available for the period of the process, but as this is 10 seconds, and the event poll interval is 2 seconds, they should overlap. I cannot use the OID stored in historical OID as it's OID has an associated timestamp, and is therefore always changing.....can only use this "latest" OID for UDP-Jitter PacketsLostDS

Joe Clarke Tue, 09/09/2008 - 08:09

The problem is you're using the entry-type of increment. This won't work correctly for rttMonLatestJitterOperPacketLossDS since the object is implemented as a Gauge, and gauges can both increment and decrement between polls (i.e. in one poll the value may be 5, and in the next poll, the value could be 1). The increment type is only applicable for monotonically increasing counters. What you want is:

event snmp oid get-type exact entry-op ge entry-val 1 poll-interval 2

Really, 2 seconds is too low. It is recommended that you poll no quicker than every 10 seconds.

Joe Clarke Tue, 09/09/2008 - 08:11

On top of this, since your IP SLA frequency is 10, you should stick to a 10 second SNMP polling period.

IAN HOLMES Tue, 09/09/2008 - 08:31

Set poll-interval to 10 seconds, and removed entry-type inc. That tracks correctly..... excellent. One access-list block for one trap....sometimes two if they fall across an IPSLA process period. I was assuming the OID value was watching the latest process as described, but it tracts the last completed process. So it makes sense increment process would be watching and sometimes seeing values that are non-zero but lower that the last inc value. Hence the intermittent nature...and zero values are anyones guess. The devil in the detail.....having the IPSLA at 10 seconds gives the roll-up values needed....I was trying to use the event poll to give the 10 seconds blocks. Thanks Joe. Now that all works I can start the TCL side. had to get the basics working.

IAN HOLMES Mon, 09/15/2008 - 04:41

Receiving error when registering script: Trying to follow config guidelines....applet multi-event works O.K.

Register event failed: Only correlate and attribute statements are allowed within trigger

while executing

"::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

} o..."

Embedded Event Manager configuration: failed to retrieve intermediate registration result for policy AdelaideSW.tcl



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

::cisco::eem::event_register_snmp tag 2 oid 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

Joe Clarke Mon, 09/15/2008 - 07:47

The document is misleading. All of these commands must be on the same line:

::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

IAN HOLMES Tue, 09/16/2008 - 03:10

Register event failed:Invalid argument "::cisco::eem::attribute"

while executing

"::cisco::eem::correlate event 1 or event 2 ::cisco::eem::attribute tag 1 occurs 1 ::cisco::eem::attribute tag 2 occurs 1"

invoked from within

"::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 } occ..."

Tried altering the config as a guess and remove the second attribute command.....

so the line was:

::cisco::eem::trigger { ::cisco::eem::correlate event 1 or event 2 ::cisco::eem::attribute tag 1 occurs 1 tag 2 occurs 1 } occurs 1

But another error:

IVisionPoller(config)#event manager policy AdelaideSW.tcl typ user

Register event failed:Invalid argument "::cisco::eem::attribute"

while executing

"::cisco::eem::correlate event 1 or event 2 ::cisco::eem::attribute tag 1 occurs 1 tag 2 occurs 1"

invoked from within

"::cisco::eem::trigger { ::cisco::eem::correlate event 1 or event 2 ::cisco::eem::attribute tag 1 occurs 1 tag 2 occurs 1 } occurs 1"

Joe Clarke Tue, 09/16/2008 - 07:04

You're hitting CSCsr44967 which won't be fixed until the next 12.4T release. I'll see if I can get this pushed into a 12.4(20)T throttle build.

Correct Answer
Joe Clarke Tue, 09/16/2008 - 07:38

Try this as a workaround:

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

::cisco::eem::event_register_snmp tag 2 oid 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.

IAN HOLMES Wed, 09/17/2008 - 04:06

It has loaded after putting the config back into multi-line format, and adding the space before the "}" as suggested. Thanks.


This Discussion