SLA reaction-trigger
I have a lab set up where I'm testing reaction-trigger, but it doesn't seem to work. Below is what I have:
ip sla monitor 1
type echo protocol ipIcmpEcho 10.1.12.2
timeout 1000
threshold 200
frequency 5
ip sla monitor reaction-configuration 1 react timeout threshold-type consecutive 3 action-type triggerOnly
ip sla monitor reaction-trigger 1 10
ip sla monitor schedule 1 life forever start-time now
ip sla monitor 10
type http operation get url http://10.1.12.2
timeout 1000
ip sla monitor schedule 10 life forever start-time now
I
was able to get it to work by scheduling both but with 10 as a start
time of pending. I can't find a single example online where anyone
schedules the trigger operation though. Is this necessary to do? If not,
my triggers refuse to work. The way that I'm testing is I have an acl
on the remote router that blocks icmp and allows everything else
through. When the sla times out 3 times, it should flip over to get the
webpage from the router. I have that router also running a web server.
Also,
both operations work fine standalone, but not where 1 is scheduled only
and then depends on the reaction configuration to flip to operation 10.
Any ideas?
Thanks!
Comments
SLA 10 must be set to "pending" when using reaction-triggers. Maybe I don't understand the question. Why would you want to start SLA 10 "now", when you want it only to run when the reaction trigger sets it off?
See the following link from Cisco IOS command reference:
http://www.cisco.com/en/US/docs/ios/ipsla/command/reference/sla_02.html#wp1054822
configuring SLA 10 for "pending" is the correct configuration.
ip sla monitor schedule 10 life forever start-time "pending"
Thanks for the response. I pasted a configuration that I was playing with, but I described that pending on sla 10 worked fine. My problem is that I couldn't find any examples online where it shows to set your triggered sla in a pending start time.
"I
was able to get it to work by scheduling both but with 10 as a start
time of pending."
This does work however, so now I know.
Thanks!
I know what you mean.. I think Cisco assumes that you know the triggered SLA should be in a state of "pending". This tricked me too.