04-24-2013 12:15 PM
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
Solved! Go to Solution.
05-03-2013 05:42 PM
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.
04-24-2013 12:17 PM
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.
04-24-2013 12:53 PM
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
04-29-2013 10:24 AM
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.
04-29-2013 05:46 PM
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?
04-29-2013 08:17 PM
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.
04-29-2013 10:28 PM
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?
04-29-2013 11:04 PM
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
05-01-2013 11:03 AM
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)#
05-03-2013 05:42 PM
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.
05-11-2013 01:37 PM
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.
05-11-2013 01:52 PM
Correct. It is the FIRST trap regardless of how long the device has been up.
05-11-2013 01:54 PM
Ok. Thanks for your help. Much appreciated.
Sent from Cisco Technical Support iPhone App
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: