Using EEM to generate a syslog message via IP SLA for high RTT

[twiggles]

Hi,

I'm a little taken aback at how difficult this is and I'm wondering if I'm missing something right under my nose.  I set up several IP SLAs to monitor RTT on our WAN links and they work fine ... if you log in and type "show ip sla statistics."

What I really need is a way to have the IP SLAs generate a syslog message when the RTT is over a threshold.  The docs are pretty confusing on whether you can even accomplish this, or if you can do so but must use EEM.  The type of IP SLA I'm using is UDP Echo, with a little ICMP Echo to hit non-Cisco devices.  My test box's configuration is below.  I get about a 12ms ping to 8.8.8.8 (sorry google, picking on your box), set the threshold to 8ms and can't get a peep out of the router.

Any ideas are welcome.

Thanks

ip sla 22
icmp-echo 8.8.8.8 source-ip 10.6.10.100
threshold 8
frequency 5
ip sla schedule 22 life forever start-time now

event manager applet SLA22
event ipsla operation-id 22 reaction-type rtt
action SLA22_ACTION syslog priority warnings msg "SLA-22-triggered"

! Here I tried to generate traps, but ... nothing

ip sla reaction-configuration 22 react rtt threshold-value 8 6 threshold-type immediate action-type trapOnly

[Francesco Molino · Accepted solution]

Hi

Here the configuration that should achieve what you want:

ip sla 22
icmp-echo 8.8.8.8 source-ip 10.6.10.100
frequency 5
ip sla schedule 22 life forever start-time now
ip sla reaction-configuration 22 react rtt threshold-value 3 2 threshold-type immediate ==> The first number (3) is when the higher threshold to send message and the second number (2) is when to send back another message when rtt reaches the lower threshold
ip sla enable reaction-alerts

!

event manager applet SLA22
event ipsla operation-id 22 reaction-type rtt
trigger occurs 1 period 1 ==> Many possibilities when the trigger should take effect
action test syslog priority warnings msg "THIS IS RTT TEST SYSLOG"

Thanks

PS: Please don't forget to rate and mark as correct answer if this answered your question

[twiggles]

Thanks Francesco.  Unfortunately it's still sitting there silently being "over threshold."

I left SLA 22 as it was and put yours in as IP SLA 23 so I could compare the differences and they look almost the same in the show outputs.  They're both doing the actual test, the test is "OK" in that the pings are being replied to, and they're "over threshold" due to timers.

But nothing I can do will make them tell me the results are bad.  I suspect it's the triggering mechanism, though I can't figure out what's wrong.  Results here show no triggers.

LAX-IDF4-3#sh event manager statistics policy

Average Maximum
No. Class Triggered Suppressed Run Time Run Time Name
-------------------------------------------------------------------------------
1 applet 0 0 0.000 0.000 SLA22
event {} ipsla

2 applet 0 0 0.000 0.000 SLA23
event {} ipsla

But the SLAs are clearly reporting back what I want.

LAX-IDF4-3#sh ip sla statistics 23
IPSLAs Latest Operation Statistics

IPSLA operation id: 23
Latest RTT: 12 milliseconds
Latest operation start time: 16:42:53 UTC Thu Jul 27 2017
Latest operation return code: Over threshold
Number of successes: 124
Number of failures: 0
Operation time to live: Forever

[twiggles]

Spoke too soon, as is usually the case.  I replicated SLA23's configuration as SLA24, and only added "threshold 5" so anything over 5ms as a response would trigger it and I got an immediate syslog message.

I'm honestly confused as he-double-hockeystick about the syntax here.

The threshold is configured now in both the IP SLA, *and* in the reaction-configuration, and I don't know which is required (both?), or which takes precedence.  I'll keep monkeying around with it, but here's the working model.  I have so much cruft in there right now (not shown) I'm not sure what's required, so I'll try removing one line at a time too.

ip sla 24
icmp-echo 8.8.8.8 source-ip 10.6.10.100
threshold 5
frequency 5

ip sla schedule 24 life forever start-time now

ip sla reaction-configuration 24 react rtt threshold-value 3 2 threshold-type immediate
ip sla enable reaction-alerts

event manager applet SLA24
event ipsla operation-id 24 reaction-type rtt
trigger occurs 1 period 1
action test syslog priority warnings msg "THIS IS RTT TEST SYSLOG"

[twiggles]

Ok I yanked it all out and put back the least lines possible to make sure I understand exactly what's happening here, and your post was correct - the "threshold 5" was not needed.

The reason I wasn't triggering events was the order of commands entered and the thresholds on the "sla reaction-configuration" command.  Basically I was starting an SLA with such low thresholds that it immediately failed and stayed bad.  THEN I was putting in the event manager.  But the event manager only responds to state changes in the IP SLA, so it never sent me a message because the state never changed.

So I grabbed the ping times to my target:

ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/12/16 ms

And adjusted the IP SLA reaction timers to 13ms (fail) and 12ms (ok again) and now I'm getting constant syslogs.  Here's the final, working copy for any googlers of the future.

ip sla 24
icmp-echo 8.8.8.8 source-ip 10.6.10.100
frequency 5
ip sla schedule 24 life forever start-time now
ip sla reaction-configuration 24 react rtt threshold-value 13 12 threshold-type immediate
ip sla enable reaction-alerts

event manager applet SLA24
event ipsla operation-id 24 reaction-type rtt
trigger occurs 1 period 1
action test syslog priority warnings msg "THIS IS RTT SLA24 TEST SYSLOG"

[Francesco Molino]

Sorry I missed all your posts as I was in an urgency.

I'm glad that now everything works as expected.