02-23-2010 07:46 PM
After reading the docs on the IPSLA ED, I decided to write the following applet just to see if I understand how to use it.
ip sla responder
ip sla enable reaction-alerts
ip sla 1
udp-jitter 210.210.210.1 16384 num-packets 100 interval 20
request-data-size 172
tos 176
ip sla schedule 1 start-time now life forever
ip sla reaction-configuration 1 react jitterDSAvg threshold-value 35 30 threshold-type consecutive 3
ip sla reaction-configuration 1 react jitterSDAvg threshold-value 35 30 threshold-type consecutive 3
ip sla reaction-configuration 1 react rtt threshold-value 225 200 threshold-type consecutive 3
ip sla reaction-configuration 1 react packetLossSD threshold-value 2 1 threshold-type consecutive 3
ip sla reaction-configuration 1 react packetLossDS threshold-value 2 1 threshold-type consecutive 3
event manager applet VoIP-Test-Alert
description "Send syslog msg if rrt delay > 225 or jitter > 35 ms or packet loss > 2%”
event tag e1 ipsla operation-id 1 reaction-type jitterDSAvg
event tag e2 ipsla operation-id 1 reaction-type jitterSDAvg
event tag e3 ipsla operation-id 1 reaction-type rtt
event tag e4 ipsla operation-id 1 reaction-type packetLossSD
event tag e5 ipsla operation-id 1 reaction-type packetLossDS
trigger occurs 1 period 360
correlate event e1 or event e2 or event e3 or event e4 or event e5
action 1.0 if $_ipsla_measured_threshold_value gt $_ipsla_threshold_rising
action 2.0 syslog priority notification msg "$_ipsla_react_type = $_ipsla_measured_threshold_value is over threshold $_ipsla_threshold_rising to destination $_ipsla_dest_ip_addr”
action 3.0 end
Seems to work but I cannot figure whether using applets if it is possible to expend this by having another applet realize that all my reactions for IP SLA 1 are under their falling theshold and thus issue a syslog message that all is A-OK.
thx in advance for any suggestions.
Solved! Go to Solution.
02-24-2010 08:56 PM
Another applet could parse the output of "show ip sla stats 1" to determine if everything is now normal in the collector. Using the regexp action in EEM 3.0, you can parse the results of the show command, and determine if RTT, loss, and jitter are now within acceptable ranges.
02-25-2010 05:10 PM
The group name being referred to here has to do with the Auto IP SLA groups used for the LSP Health Monitor. It has nothing to do with the group scheduling ID which you seem to be using. You will still need to react to the individual IP SLA collector IDs.
02-24-2010 08:56 PM
Another applet could parse the output of "show ip sla stats 1" to determine if everything is now normal in the collector. Using the regexp action in EEM 3.0, you can parse the results of the show command, and determine if RTT, loss, and jitter are now within acceptable ranges.
02-25-2010 04:05 AM
Thank you. That would do it for that but now I have another issue.
I want to expand my applet so only one applet would be all that is needed to alert for ip sla tests to multiple targets so I tried yesterday to expand my applet to somethink like the following:
event manager applet VoIP-Test-Alert
description "Send syslog msg if rrt delay > 225 or jitter > 35 ms or packet loss > 2%”
event tag e1 ipsla group-name 1 reaction-type jitterDSAvg
event tag e2 ipsla group-name 1 reaction-type jitterSDAvg
event tag e3 ipsla group-name 1 reaction-type rtt
event tag e4 ipsla group-name 1 reaction-type packetLossSD
event tag e5 ipsla group-name 1 reaction-type packetLossDS
trigger occurs 1 period 360
correlate event e1 or event e2 or event e3 or event e4 or event e5
I then used the ip sla schedule command to put ip sla operation-id 1 into schedule group id 1. But when I tested, I got the Ip SLA threshold exceeded syslog messages but my applet failed to trigger.
I am not understading something here in regards to IP SLA ED use of group-name. In IP SLA schedule group ids are integers while in the applet group-name are strings. Thus I suspect I am not correctly creating the ip sla group correctly.
Thanks in advance again for any help.
02-25-2010 05:10 PM
The group name being referred to here has to do with the Auto IP SLA groups used for the LSP Health Monitor. It has nothing to do with the group scheduling ID which you seem to be using. You will still need to react to the individual IP SLA collector IDs.
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: