cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3203
Views
0
Helpful
12
Replies

EEM Traps Incrementing OID values

matthewathom
Level 1
Level 1

I'm running IOS Version 15.1(4)M4 on two 2951 routers with EEM version 3.2.  I am utilizing an EEM applet on Router A (triggered by a syslog message) to send an SNMP trap to a loopback on Router B. 

event manager applet OSPF

event syslog pattern "OSPF-5-ADJCHG: Process 33, Nbr 4.4.4.4 on GigabitEthernet0/2 from FULL to DOWN, Neighbor Down: Interface down or detached"

action 1.0 cli command "enable"

action 2.0 snmp-trap intdata1 333333

Router B has an EEM applet that utilizes an snmp-notification event to triggger it's action when it sees the SNMP trap from Router A. 

event manager applet SNMP

event snmp-notification oid 1.3.6.1.4.1.9.10.91.1.2.3.1.9.1 oid-val "333333" op eq

action 1.0 cli command "enable"

action 2.0 cli command "config terminal"

action 3.0 cli command "interface gig 0/2"

action 4.0 cli command "no shutdown"

The issue I'm having is that the oid values seem to increment for each SNMP trap.  The last integer for each EventEntry below increments with each new SNMP trap.  You can see that all of the oids end in .1 for the first trap and .2 for the second trap.  This means the snmp-notification oid value utilized on Router B will only properly trigger the first time the trap is sent.  The only way I can find to reset that last oid value is to reload the router.  Is this a bug?  Why is the oid value incrementing?

First trap sent by Router A:

Apr 24 18:54:12.202: SNMP: V2 Trap, reqid 3, errstat 0, erridx 0

sysUpTime.0 = 458242

snmpTrapOID.0 = cEventMgrMIB.0.2

ceemHistoryEventEntry.2.1 = 41

ceemHistoryEventEntry.3.1 = 0

ceemHistoryEventEntry.4.1 = 0

ceemHistoryEventEntry.5.1 = 0

ceemHistoryEventEntry.6.1 =

ceemHistoryEventEntry.7.1 = applet: OSPF

ceemHistoryEventEntry.9.1 = 333333

ceemHistoryEventEntry.10.1 = 0

ceemHistoryEventEntry.11.1 =

ceemHistoryEventEntry.13.1 = 0

ceemHistoryEventEntry.14.1 = 0

ceemHistoryEventEntry.15.1 = 0

ceemHistoryEventEntry.16.1 = 0

Second trap sent by Router A:

Apr 24 18:55:18.757: SNMP: V2 Trap, reqid 4, errstat 0, erridx 0

sysUpTime.0 = 464898

snmpTrapOID.0 = cEventMgrMIB.0.2

ceemHistoryEventEntry.2.2 = 41

ceemHistoryEventEntry.3.2 = 0

ceemHistoryEventEntry.4.2 = 0

ceemHistoryEventEntry.5.2 = 0

ceemHistoryEventEntry.6.2 =

ceemHistoryEventEntry.7.2 = applet: OSPF

ceemHistoryEventEntry.9.2 = 333333

ceemHistoryEventEntry.10.2 = 0

ceemHistoryEventEntry.11.2 =

ceemHistoryEventEntry.13.2

1 Accepted Solution

Accepted Solutions

Hmmm, I certainly didn't see delays like that.  The delay should only happen for the first trap sent from the device (there is code in IOS to introduce that delay to make sure IP and the SNMP ENGINE are working).  After that, the traps should flow rather quickly.

View solution in original post

12 Replies 12

Joe Clarke
Cisco Employee
Cisco Employee

Change your OID in your Router B applet so that it ends with a '.' instead of a specific instance:

1.3.6.1.4.1.9.10.91.1.2.3.1.9.

Then it will work.

Ah...ok. I had tried ending it with the integer before ("9") but that hadn't worked.

1.3.6.1.4.1.9.10.91.1.2.3.1.9

Thanks for your help.

Sent from Cisco Technical Support iPhone App

I was finally able to test this out today, but unfortunately ending with a "." would not trigger the applet.  The only way I have been able to trigger the applet is by using the exact OID value including the last decimal which increments with each SNMP trap sent. 

Then that's a bug.  I have a very clear working example where I can use EEM traps to trigger remote policies.  Here are my two applets:

Sender:

event manager applet ospf-change

event syslog pattern "OSPF-5-ADJCHG"

action 1.0 cli command "enable"

action 2.0 cli command "debug ip ospf packet"

action 3.0 snmp-trap intdata1 424242

!

snmp-server enable traps event-manager

snmp-server host 10.1.1.1 traps public event-manager

Receiver:

event manager applet ospf-change

event snmp-notification oid 1.3.6.1.4.1.9.10.91.1.2.3.1.9. oid-val "424242" op eq src-ip-address 10.1.1.2

action 1.0 cli command "enable"

action 2.0 cli command "debug ip ospf packet"

!

snmp-server manager

Can you confirm all configs are consistent with this?

The only inconsistency is that I have not configured the source address on the receiving router.

Sender:

event manager applet OSPF

event syslog pattern "OSPF-5-ADJCHG: Process 33, Nbr 4.4.4.4 on GigabitEthernet0/2 from FULL to DOWN, Neighbor Down: Interface down or detached"

action 1.0 cli command "enable"

action 2.0 snmp-trap intdata1 333333

!

snmp-server trap-source Loopback0

snmp-server enable traps event-manager

snmp-server host 1.1.1.1 public event-manager

!

Receiver:

event manager applet SNMP

event snmp-notification oid 1.3.6.1.4.1.9.10.91.1.2.3.1.9. oid-val "333333" op eq

action 1.0 cli command "enable"

action 2.0 cli command "config terminal"

action 3.0 cli command "interface gig 0/2"

action 4.0 cli command "no shutdown"

!

snmp-server community public

snmp-server manager

!

When I add the last integer to the oid value (corresponding to whatever integer the next SNMP trap will utilize) the applet on the receiving router triggers properly.

I tried your config and it works for me.  I had a few second delay after enabling the host, but now it works and works quickly.  I do not need to specify the instance.  I see the packets in "debug snmp packet" and the receiver applet fires.  Would it be possible to post the output of "debug snmp packet" and "debug event manager detector snmp-notif" from the receiver?

I can do that, but I won't be able to do the capture until Wednesday. What IOS and EEM versions are you running for your test?

Sent from Cisco Technical Support iPad App

I have been able to successfully trigger the applet today while  utilizing the "." at the end of the OID value. I may have found the  issue I had when I was previously unsuccessful at getting this to work.   I'm having a tough time reproducing it though.  I first noticed it  after a reboot on the sending router.  I know you mentioned you saw a  few second delay after enabling the host.  I noticed a roughly two  minute delay between the script being run on the sender and the SNMP  trap being sent when I ran this after a reboot.  I had given the router  several minutes after the reboot and all OSPF process came up before I  attempted to run this. 

I had "debug snmp packets" and "debug event manager  action cli" turned on for the following output.  You can see that I  shutdown the Gig 0/2 interface and the script on the sending router runs  properly.  After about 30 seconds without the SNMP trap being generated  I brought back up the Gig 0/2 interface.  After another minute and a  half the SNMP trap is finally generated and sent (I immmediately saw the  applet on the receiving router run).  If these were the types of delays occurring when I initially tested this configuration I may not have waited long enough.

VENETIAN(config)#int gig 0/2

VENETIAN(config-if)#shut

VENETIAN(config-if)#

May  1  17:12:42.586: %OSPF-5-ADJCHG: Process 33, Nbr 4.4.4.4 on  GigabitEthernet0/2 from FULL to DOWN, Neighbor Down: Interface down or  detached

VENETIAN(config-if)#

May  1 17:12:42.590: %HA_EM-6-LOG: OSPF : DEBUG(cli_lib) : : CTL : cli_open called.

May  1 17:12:42.590: %HA_EM-6-LOG: OSPF : DEBUG(cli_lib) : : OUT : VENETIAN#

May  1 17:12:42.590: %HA_EM-6-LOG: OSPF : DEBUG(cli_lib) : : IN  : VENETIAN#enable

May  1 17:12:42.602: %HA_EM-6-LOG: OSPF : DEBUG(cli_lib) : : OUT : VENETIAN#

May  1 17:12:42.602: %HA_EM-6-LOG: OSPF : DEBUG(cli_lib) : : CTL : cli_close called.

VENETIAN(config-if)#

May  1 17:12:44.530: %LINK-5-CHANGED: Interface GigabitEthernet0/2, changed state to administratively down

May  1 17:12:45.530: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/2, changed state to down

VENETIAN(config-if)#no shut

VENETIAN(config-if)#

May  1 17:13:18.394: %LINK-3-UPDOWN: Interface GigabitEthernet0/2, changed state to down

VENETIAN(config-if)#

May  1 17:13:21.554: %LINK-3-UPDOWN: Interface GigabitEthernet0/2, changed state to up

May  1 17:13:22.554: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/2, changed state to up

VENETIAN(config-if)#

May  1 17:14:03.345: %OSPF-5-ADJCHG: Process 33, Nbr 4.4.4.4 on GigabitEthernet0/2 from LOADING to FULL, Loading Done

VENETIAN(config-if)#

May  1 17:14:42.605: SNMP: Queuing packet to 1.1.1.1

May  1 17:14:42.605: SNMP: V1 Trap, ent cEventMgrMIB, addr 2.2.2.2, gentrap 6, spectrap 2

ceemHistoryEventEntry.2.1 = 41

ceemHistoryEventEntry.3.1 = 0

ceemHistoryEventEntry.4.1 = 0

ceemHistoryEventEntry.5.1 = 0

ceemHistoryEventEntry.6.1 =

ceemHistoryEventEntry.7.1 = applet: OSPF

ceemHistoryEventEntry.9.1 = 333333

ceemHistoryEventEntry.10.1 = 0

ceemHistoryEventEntry.11.1 =

ceemHistoryEventEntry.13.1 = 0

ceemHistoryEventEntry.14.1 = 0

ceemHistoryEventEntry.15.1 = 0

ceemHistoryEventEntry.16.1 = 0

May  1 17:14:42.857: SNMP: Packet sent via UDP to 1.1.1.1

VENETIAN(config-if)#

Hmmm, I certainly didn't see delays like that.  The delay should only happen for the first trap sent from the device (there is code in IOS to introduce that delay to make sure IP and the SNMP ENGINE are working).  After that, the traps should flow rather quickly.

That was most likely what I saw then.  I was only able to reproduce this delay when it was the first trap being sent from the device.  Does this delay occur on the first trap sent regardless of how long the device has been up?  For instance, I reloaded the router and waiting a full 20 minutes after all OSPF relationships had come up before running the script.  I still saw this two minute delay, but only on the first trap sent.

Correct.  It is the FIRST trap regardless of how long the device has been up.

Ok. Thanks for your help. Much appreciated.

Sent from Cisco Technical Support iPhone App

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: