01-19-2011 10:11 AM
Hello.
I have the following config in order to send a SNMP trap to a server when I cannot ping a public site:
snmp-server community ****** RO
snmp-server trap-source Vlan****
snmp-server enable traps syslog
snmp-server host ***** version 2c **** syslog
snmp-server enable traps rtr
snmp-server enable traps syslog
ip sla monitor logging traps
ip sla monitor 1
type echo protocol ipIcmpEcho "public IP address"
timeout 2000
frequency 10
ip sla monitor reaction-configuration 1 react timeout threshold-type immediate action-type trapOnly
ip sla monitor schedule 1 start-time now
All works fine when I have a timeout since the snmp trap is sent to the server. However I dont know how to setup a config in order to send a trap stating that the link is up again.
Can anyone help me?
Thanks in advance.
Best regards,
Joao Ribau
Solved! Go to Solution.
01-22-2011 11:53 AM
You can't, not with pure IP SLA. You could do this with the Embedded Event Manager, though. Looks like you're using 12.4 mainline. This applet should do what you want:
event manager applet ipsla-up
event snmp oid 1.3.6.1.4.1.9.9.42.1.2.10.1.2.1 get-type exact entry-op eq entry-val 1 exit-op ne exit-val 1 poll-interval 10
action 1.0 snmp-trap strdata "IP SLA collector 1 is up"
!
snmp-server enable traps event-manager
01-22-2011 11:53 AM
You can't, not with pure IP SLA. You could do this with the Embedded Event Manager, though. Looks like you're using 12.4 mainline. This applet should do what you want:
event manager applet ipsla-up
event snmp oid 1.3.6.1.4.1.9.9.42.1.2.10.1.2.1 get-type exact entry-op eq entry-val 1 exit-op ne exit-val 1 poll-interval 10
action 1.0 snmp-trap strdata "IP SLA collector 1 is up"
!
snmp-server enable traps event-manager
01-24-2011 08:01 AM
Hello Joseph.
Thank you very much for your help. It worked just fine.
Best regards,
Joao Ribau.
P.S. - do you know any good link about OIDs and event manager?
01-24-2011 08:06 AM
OIDs have nothing to do with EEM per se. EEM is just one consumer of SNMP. The OID I used is documented in the CISCO-RTTMON-MIB. It is rttMonLatestRttOperSense. More on writing EEM applets can be found at http://www.cisco.com/en/US/partner/docs/ios/netmgmt/configuration/guide/nm_eem_policy_cli.html .
01-25-2011 10:32 AM
Hello.
Can you help me one more time?
I am trying to monitor the CPU of two 6500.
I am using rmon to trigger a log message and then I am using "event manager" to send a trap if the log appear 3 times in less than 60 sec.
The thing is that I am not being able to trigger the log message and then the trap is not send.
This is the config that I am using:
rmon event 1 log description "CPU above 50%" owner me
rmon event 2 log description "CPU below 49%" owner me
rmon alarm 1 cpmCPUTotalTable.1.6 10 absolute rising-threshold 3 1 falling-threshold 2 2 owner me
event manager applet CPU-50 trap
event syslog occurs 3 period 60000 pattern "CPU above 50%"
action 1.0 snmp-trap strdata "CPU above 50%"
event manager applet CPU-30 trap
event syslog occurs 3 period 60000 pattern "CPU below 49%"
action 1.0 snmp-trap strdata "CPU below 50%"
For this I am using the mib that checks for 5sec CPU.
P.S. - I am using 3% in order to trigger the log message since the cpu usage at the moment is very low.
Best regards,
Joao Carvalho
01-25-2011 02:59 PM
Your OID is missing an instance. You need another number at the end of cpmCPUTotalTable.1.6. That number will either be 1 or 2 depending on the CPU to monitor.
08-01-2013 07:08 PM
I found this thread while looking for configuration guide for this, you can absolutely generate SNMP traps from IPSLA natively. You can configure IPSLA SNMP Traps using this guide
http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hsthresh.html
Basic Config:
ip sla 42000
icmp-echo 192.155.82.98
verify-data
owner "Keith"
frequency 90
threshold 200
!
ip sla schedule 42000 life forever start-time now
ip sla reaction-configuration 42000 react timeout threshold-type immediate action-type trapOnly
ip sla reaction-configuration 42000 react rtt threshold-value 200 150 action-type trapOnly
ip sla logging traps
ip sla enable reaction-alerts
!
snmp-server enable traps ipsla
The resulting traps:
2013-Aug-02-09:59:23 meatball.packnet UDP:=[192.168.1.254]:61904->[192.168.1.7] SNMPv2-MIB::sysUpTime.0=4:20:38:35.02 SNMPv2-MIB::snmpTrapOID.0=CISCO-RTTMON-MIB::rttMonTimeoutNotification CISCO-RTTMON-MIB::rttMonCtrlAdminTag.42000= CISCO-RTTMON-MIB::rttMonHistoryCollectionAddress.42000="C0 9B 52 62 00 00 00 00 00 00 00 00 00 00 00 00 00=00 00 00 00 00 00 00 00 00 00 00 " CISCO-RTTMON-MIB::rttMonCtrlOperOverThresholdOccurred.42000=true
2013-Aug-02-09:59:23 meatball.packnet UDP:=[192.168.1.254]:61904->[192.168.1.7] SNMPv2-MIB::sysUpTime.0=4:20:38:35.03 SNMPv2-MIB::snmpTrapOID.0=CISCO-RTTMON-MIB::rttMonNotification CISCO-RTTMON-MIB::rttMonCtrlAdminTag.42000= CISCO-RTTMON-MIB::rttMonHistoryCollectionAddress.42000="C0 9B 52 62 00 00 00 00 00 00 00 00 00 00 00 00 00=00 00 00 00 00 00 00 00 00 00 00 " CISCO-RTTMON-MIB::rttMonReactVar.42000=timeout CISCO-RTTMON-MIB::rttMonReactOccurred.42000=true CISCO-RTTMON-MIB::rttMonReactValue.42000=1 CISCO-RTTMON-MIB::rttMonReactThresholdRising.42000=0 CISCO-RTTMON-MIB::rttMonReactThresholdFalling.42000=0 CISCO-RTTMON-MIB::rttMonEchoAdminLSPSelector.42000="00 00 00 00 00 00 00 45 00 00 00 01 28 00 00 28 00=00 00 00 00 00 00 00 00 00 00 00 "
2013-Aug-02-10:20:19 meatball.packnet UDP:=[192.168.1.254]:61904->[192.168.1.7] SNMPv2-MIB::sysUpTime.0=4:20:59:30.22 SNMPv2-MIB::snmpTrapOID.0=CISCO-RTTMON-MIB::rttMonThresholdNotification CISCO-RTTMON-MIB::rttMonCtrlAdminTag.42000= CISCO-RTTMON-MIB::rttMonHistoryCollectionAddress.42000="C0 9B 52 62 00 00 00 00 00 00 00 00 00 00 00 00 00=00 00 00 00 00 00 00 00 00 00 00 " CISCO-RTTMON-MIB::rttMonCtrlOperOverThresholdOccurred.42000.0.0.0=false
2013-Aug-02-10:20:19 meatball.packnet UDP:=[192.168.1.254]:61904->[192.168.1.7] SNMPv2-MIB::sysUpTime.0=4:20:59:30.22 SNMPv2-MIB::snmpTrapOID.0=CISCO-RTTMON-MIB::rttMonNotification CISCO-RTTMON-MIB::rttMonCtrlAdminTag.42000= CISCO-RTTMON-MIB::rttMonHistoryCollectionAddress.42000="C0 9B 52 62 00 00 00 00 00 00 00 00 00 00 00 00 00=00 00 00 00 00 00 00 00 00 00 00 " CISCO-RTTMON-MIB::rttMonReactVar.42000=timeout CISCO-RTTMON-MIB::rttMonReactOccurred.42000=false CISCO-RTTMON-MIB::rttMonReactValue.42000=0 CISCO-RTTMON-MIB::rttMonReactThresholdRising.42000=0 CISCO-RTTMON-MIB::rttMonReactThresholdFalling.42000=0 CISCO-RTTMON-MIB::rttMonEchoAdminLSPSelector.42000="00 00 00 00 00 00 00 45 00 00 00 01 28 00 00 28 00=00 00 00 00 00 00 00 00 00 00 00 "
I am getting lots of these, so will need to raise my timeouts and threshold I think.
Cheers
Keith
08-01-2013 07:20 PM
Wow, this takes me back. I think what I was saying here is that there is no corresponding "clear" trap for timeout occurred. So, while you can generate traps based on various threshold values, you don't have an exact reciprocal of the timeout occurred trap. That is, he didn't in his train of code (12.4 mainline).
In the current version of the CISCO-RTTMON-MIB, you now have the rttMonNotification notification that has the
rttMonReactOccurred object to tell you if the condition occurred or not. Your example here shows a more recent version of IOS.
08-01-2013 07:37 PM
Joe,
Works in 12.4 "Version 12.4(25f)" as well, the link I included was from then, just that extra monitor key word:
ip sla monitor responder
ip sla monitor logging traps
ip sla monitor 42000
type echo protocol ipIcmpEcho 192.155.82.98
threshold 200
verify-data
owner Keith
frequency 90
ip sla monitor reaction-configuration 42000 react timeout threshold-type immediate action-type trapOnly
ip sla monitor reaction-configuration 42000 react rtt threshold-value 200 150 action-type trapOnly
ip sla monitor schedule 42000 life forever start-time now
I have been looking through the traps to decifer them, looks like you get a trap when the timeout occurs and then when it clears.
CISCO-RTTMON-MIB::rttMonNotification
CISCO-RTTMON-MIB::rttMonReactVar.42000=timeout
CISCO-RTTMON-MIB::rttMonReactOccurred.42000=true
CISCO-RTTMON-MIB::rttMonNotification
CISCO-RTTMON-MIB::rttMonReactVar.42000=timeout
CISCO-RTTMON-MIB::rttMonReactOccurred.42000=false
I will look into this a little more to see if it is fully stateful and tracking up/down correctly.
2013-Aug-02-09:59:23 meatball.packnet UDP:=[192.168.1.254]:61904->[192.168.1.7] SNMPv2-MIB::sysUpTime.0=4:20:38:35.03 SNMPv2-MIB::snmpTrapOID.0=CISCO-RTTMON-MIB::rttMonNotification CISCO-RTTMON-MIB::rttMonCtrlAdminTag.42000= CISCO-RTTMON-MIB::rttMonHistoryCollectionAddress.42000="C0 9B 52 62 00 00 00 00 00 00 00 00 00 00 00 00 00=00 00 00 00 00 00 00 00 00 00 00 " CISCO-RTTMON-MIB::rttMonReactVar.42000=timeout CISCO-RTTMON-MIB::rttMonReactOccurred.42000=true CISCO-RTTMON-MIB::rttMonReactValue.42000=1 CISCO-RTTMON-MIB::rttMonReactThresholdRising.42000=0 CISCO-RTTMON-MIB::rttMonReactThresholdFalling.42000=0 CISCO-RTTMON-MIB::rttMonEchoAdminLSPSelector.42000="00 00 00 00 00 00 00 45 00 00 00 01 28 00 00 28 00=00 00 00 00 00 00 00 00 00 00 00 "
2013-Aug-02-10:20:19 meatball.packnet UDP:=[192.168.1.254]:61904->[192.168.1.7] SNMPv2-MIB::sysUpTime.0=4:20:59:30.22 SNMPv2-MIB::snmpTrapOID.0=CISCO-RTTMON-MIB::rttMonNotification CISCO-RTTMON-MIB::rttMonCtrlAdminTag.42000= CISCO-RTTMON-MIB::rttMonHistoryCollectionAddress.42000="C0 9B 52 62 00 00 00 00 00 00 00 00 00 00 00 00 00=00 00 00 00 00 00 00 00 00 00 00 " CISCO-RTTMON-MIB::rttMonReactVar.42000=timeout CISCO-RTTMON-MIB::rttMonReactOccurred.42000=false CISCO-RTTMON-MIB::rttMonReactValue.42000=0 CISCO-RTTMON-MIB::rttMonReactThresholdRising.42000=0 CISCO-RTTMON-MIB::rttMonReactThresholdFalling.42000=0 CISCO-RTTMON-MIB::rttMonEchoAdminLSPSelector.42000="00 00 00 00 00 00 00 45 00 00 00 01 28 00 00 28 00=00 00 00 00 00 00 00 00 00 00 00 "
2013-Aug-02-10:21:53 meatball.packnet UDP:=[192.168.1.254]:61904->[192.168.1.7] SNMPv2-MIB::sysUpTime.0=4:21:01:05.03 SNMPv2-MIB::snmpTrapOID.0=CISCO-RTTMON-MIB::rttMonNotification CISCO-RTTMON-MIB::rttMonCtrlAdminTag.42000= CISCO-RTTMON-MIB::rttMonHistoryCollectionAddress.42000="C0 9B 52 62 00 00 00 00 00 00 00 00 00 00 00 00 00=00 00 00 00 00 00 00 00 00 00 00 " CISCO-RTTMON-MIB::rttMonReactVar.42000=timeout CISCO-RTTMON-MIB::rttMonReactOccurred.42000=true CISCO-RTTMON-MIB::rttMonReactValue.42000=1 CISCO-RTTMON-MIB::rttMonReactThresholdRising.42000=0 CISCO-RTTMON-MIB::rttMonReactThresholdFalling.42000=0 CISCO-RTTMON-MIB::rttMonEchoAdminLSPSelector.42000="00 00 00 00 00 00 00 45 00 00 00 01 28 00 00 28 00=00 00 00 00 00 00 00 00 00 00 00 "
2013-Aug-02-10:29:19 meatball.packnet UDP:=[192.168.1.254]:61904->[192.168.1.7] SNMPv2-MIB::sysUpTime.0=4:21:08:30.24 SNMPv2-MIB::snmpTrapOID.0=CISCO-RTTMON-MIB::rttMonNotification CISCO-RTTMON-MIB::rttMonCtrlAdminTag.42000= CISCO-RTTMON-MIB::rttMonHistoryCollectionAddress.42000="C0 9B 52 62 00 00 00 00 00 00 00 00 00 00 00 00 00=00 00 00 00 00 00 00 00 00 00 00 " CISCO-RTTMON-MIB::rttMonReactVar.42000=timeout CISCO-RTTMON-MIB::rttMonReactOccurred.42000=false CISCO-RTTMON-MIB::rttMonReactValue.42000=0 CISCO-RTTMON-MIB::rttMonReactThresholdRising.42000=0 CISCO-RTTMON-MIB::rttMonReactThresholdFalling.42000=0 CISCO-RTTMON-MIB::rttMonEchoAdminLSPSelector.42000="00 00 00 00 00 00 00 45 00 00 00 01 28 00 00 28 00=00 00 00 00 00 00 00 00 00 00 00 "
2013-Aug-02-10:30:53 meatball.packnet UDP:=[192.168.1.254]:61904->[192.168.1.7] SNMPv2-MIB::sysUpTime.0=4:21:10:05.03 SNMPv2-MIB::snmpTrapOID.0=CISCO-RTTMON-MIB::rttMonNotification CISCO-RTTMON-MIB::rttMonCtrlAdminTag.42000= CISCO-RTTMON-MIB::rttMonHistoryCollectionAddress.42000="C0 9B 52 62 00 00 00 00 00 00 00 00 00 00 00 00 00=00 00 00 00 00 00 00 00 00 00 00 " CISCO-RTTMON-MIB::rttMonReactVar.42000=timeout CISCO-RTTMON-MIB::rttMonReactOccurred.42000=true CISCO-RTTMON-MIB::rttMonReactValue.42000=1 CISCO-RTTMON-MIB::rttMonReactThresholdRising.42000=0 CISCO-RTTMON-MIB::rttMonReactThresholdFalling.42000=0 CISCO-RTTMON-MIB::rttMonEchoAdminLSPSelector.42000="00 00 00 00 00 00 00 45 00 00 00 01 28 00 00 28 00=00 00 00 00 00 00 00 00 00 00 00 "
08-01-2013 07:42 PM
The config doesn't change (expect for dropping monitor), but the MIB does. The MIB in 12.4(25) didn't support the newer trap. Yes, your code supports the newer MIB and the newr trap.
The older MIB supported the rttMonTimeoutNotification trap (now deprecated), and I believe while it could have sent cleared traps, they weren't actually sent, which spawned my response. But it's been over two years, so I may be a bit fuzzy.
08-01-2013 08:10 PM
FYI, definitely getting stateful events in syslog
Aug 2 13:06:54 meatball.packnet 1056: Aug 2 03:06:54.094: %RTT-4-OPER_TIMEOUT: condition occurred, entry number = 42000
Aug 2 13:09:49 meatball.packnet 1058: Aug 2 03:09:49.289: %RTT-4-OPER_TIMEOUT: condition cleared, entry number = 42000
02-11-2015 06:12 PM
Update:
This post is kind of old, but when doing research for IP SLA traps via SNMP this support forum is the first hit so I hope the below information comes in handy.
The configuration used is similar to the configuration in the original post:
snmp-server enable traps syslog
snmp-server enable traps ipsla
ip sla monitor logging traps
ip sla monitor reaction-configuration 1 react timeout threshold-type consecutive 3 action-type trapOnly
It looks like recent versions of code do send a trap when the link comes back up, below is a test in my local lab which confirms this:
Below we see when the interface goes down and the first trap is sent:
2811#
Feb 12 01:54:28.112: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
2811#
2811#show ip sla
Feb 12 01:54:41.009: %TRACKING-5-STATE: 8 ip sla 8 reachability Up->Down
2811#
Feb 12 01:54:56.205: %RTT-4-OPER_TIMEOUT: condition occurred, entry number = 8
Feb 12 01:54:56.329: %RTT-3-IPSLATHRESHOLD: IP SLAs(8): Threshold Occurred for timeout
Then I brought the interface back up and we can see where we actually receive another trap stating that the operation timeout is cleared which means the link is back up:
2811#
2811#debug snmp headers
Feb 12 01:55:14.341: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
2811#debug snmp headers
Feb 12 01:55:31.206: %RTT-4-OPER_TIMEOUT: condition cleared, entry number = 8
Feb 12 01:55:31.334: %RTT-3-IPSLATHRESHOLD: IP SLAs(8): Threshold Cleared for timeout
2811#debug snmp headers
I brought the interface back down and a new trap was generated:
Feb 12 01:55:36.018: %TRACKING-5-STATE: 8 ip sla 8 reachability Down->Up
2811#debug snmp headers
Feb 12 01:55:56.834: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
2811#debug snmp headers
Feb 12 01:56:06.026: %TRACKING-5-STATE: 8 ip sla 8 reachability Up->Down
2811#debug snmp headers
Feb 12 01:56:21.206: %RTT-4-OPER_TIMEOUT: condition occurred, entry number = 8
Feb 12 01:56:21.330: %RTT-3-IPSLATHRESHOLD: IP SLAs(8): Threshold Occurred for timeout
Hope this information is useful.
Regards,
Emmanuel Hernandez
02-11-2015 06:59 PM
You're not actually showing any evidence of SNMP traps here. If you wanted to do that, you should enable "debug snmp packet". Of course, you should receive an rttMonNotification trap with the correct true/false value for the rttMonReactOccurred varbind depending on the condition of the collector.
02-11-2015 07:10 PM
Joe,
Thanks for pointing this out, attaching corresponding debugs below:
Operation timing out:
CISCO-SYSLOG-MIB:clogMessageGenerated snmpTrapEnterprise = CISCO-SYSLOG-MIB:ciscoSyslogMIBNotificationPrefix
experimental.1057.1.0 = 50.203.195.1
sysUpTime = 32 days 22 hours 57 minutes 28.24 seconds
snmpTrapOID = CISCO-SYSLOG-MIB:clogMessageGenerated
clogHistTimestamp.981 = 284744823
clogHistMsgText.981 = IP SLAs(8): Threshold Occurred for timeout
clogHistMsgName.981 = IPSLATHRESHOLD
clogHistSeverity.981 = 4
clogHistFacility.981 = RTT
experimental.1057.1.0 = 50.203.195.1
sysUpTime = 32 days 22 hours 57 minutes 28.24 seconds
snmpTrapOID = CISCO-SYSLOG-MIB:clogMessageGenerated
clogHistTimestamp.980 = 284744822
clogHistMsgText.980 = condition occurred, entry number = 8
clogHistMsgName.980 = OPER_TIMEOUT
clogHistSeverity.980 = 5
clogHistFacility.980 = RTT
Below is an example of the link coming back up:
Feb 12 01:49:41.339: SNMP: V1 Trap, ent ciscoSyslogMIB.2, gentrap 6, spectrap 1
clogHistoryEntry.2.178 = RTT
clogHistoryEntry.3.178 = 5
clogHistoryEntry.4.178 = OPER_TIMEOUT
clogHistoryEntry.5.178 = condition cleared, entry number = 8
clogHistoryEntry.6.178 = 62629431
Feb 12 01:49:41.399: SNMP: V1 Trap, ent ciscoSyslogMIB.2, gentrap 6, spectrap 1
clogHistoryEntry.2.179 = RTT
clogHistoryEntry.3.179 = 4
clogHistoryEntry.4.179 = IPSLATHRESHOLD
clogHistoryEntry.5.179 = IP SLAs(8): Threshold Cleared for timeout
clogHistoryEntry.6.179 = 62629444
And below is an the debug output we should expect for the rttMonReactOccurred trap with the corresponding value:
snmpTrapOID = CISCO-RTTMON-MIB:rttMonNotification
rttMonEchoAdminLSPSelector.8 = AAAAAAAAAAAgu8wYlX8AAH38UQMAAAAAAAAAAg==
rttMonReactThresholdFalling.8 = 0
rttMonReactThresholdRising.8 = 0
rttMonReactValue.8 = 1
rttMonReactOccurred.8 = True
rttMonReactVar.8 = 7
rttMonHistoryCollectionAddress.8 = BAQEBA==
rttMonCtrlAdminEntry.12.8 =
Thanks again,
Emmanuel Hernandez
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide