Lab Objective
Configure an IP SLA operation measuring latency to a critical destination, define reaction thresholds that trigger when latency exceeds an acceptable level, and configure an EEM applet that logs a clear, human-readable health status change when the threshold is crossed, approximating the automated health-scoring behavior of a full assurance platform using only IOS-native tools.
Lab Purpose
The IP SLA lab covered earlier in this series measured and reported performance statistics, but did nothing with that data beyond storing it for manual review. Combining IP SLA's reaction configuration with an EEM applet, covered in an earlier lab, creates a simple but genuine automated health-monitoring loop — detecting a problem and clearly logging it — the same fundamental pattern full assurance platforms build upon at much greater scale and sophistication.
Lab Topology
R1 ---- WAN link ---- CriticalDestination: 203.0.113.100
Acceptable latency threshold: 100ms
Currently healthy, but will be
artificially degraded during this labTask 1: Configure an IP SLA Operation with a Reaction Threshold
Configure an IP SLA ICMP echo operation to the critical destination, with a reaction condition triggering when round-trip time exceeds 100ms.
Task 2: Configure an EEM Applet Watching for the SLA Threshold Event
Configure an EEM applet triggered by the IP SLA reaction event rather than a syslog pattern this time.
Task 3: Verify Normal Healthy Status
Confirm the link currently reports as healthy, with latency below the threshold.
Task 4: Simulate Link Degradation
Introduce artificial latency (e.g., via a shaping/delay simulation) pushing round-trip time above 100ms.
Task 5: Verify the Automated Health Status Change Is Logged
Confirm the EEM applet fires and logs a clear health status change the moment the threshold is crossed.
Solution and Verification
R1(config)# ip sla 20
R1(config-ip-sla)# icmp-echo 203.0.113.100
R1(config-ip-sla-echo)# frequency 10
R1(config-ip-sla-echo)# exit
R1(config)# ip sla reaction-configuration 20 react rtt threshold-value 100 1 threshold-type immediate action-type trapOnly
R1(config)# ip sla schedule 20 life forever start-time now
-- The reaction configuration defines the
-- unhealthy condition explicitly: any
-- single RTT measurement exceeding 100ms
-- triggers an immediate reaction eventR1(config)# event manager applet HEALTH-DEGRADED
R1(config-applet)# event ipsla operation-id 20 reaction-type rtt
R1(config-applet)# action 1.0 syslog msg "HEALTH CHECK: WAN link to critical destination DEGRADED - latency exceeded threshold"R1# show ip sla statistics 20
Latest RTT: 24 ms
Latest operation return code: OK
-- Currently healthy -- well below the
-- 100ms threshold-- Artificially degrading the link
-- (simulated via a shaping policy adding
-- delay, or a lab-specific impairment tool):
R1# show ip sla statistics 20
Latest RTT: 187 ms
Latest operation return code: OK
-- Latency now well above the 100ms
-- thresholdR1# show logging | include HEALTH CHECK
*Jun 27 11:04:02: %HA_EM-6-LOG: HEALTH-DEGRADED:
HEALTH CHECK: WAN link to critical destination
DEGRADED - latency exceeded threshold
-- The EEM applet fired automatically the
-- moment IP SLA detected the threshold
-- violation, producing a clear, immediately
-- actionable log entry without any manual
-- monitoring or polling requiredKey Takeaway
Combining IP SLA's threshold-based reaction configuration with an EEM applet reproduces the essential pattern behind automated health monitoring — continuously measuring a meaningful metric, comparing it against a defined acceptable threshold, and clearly signaling when that threshold is crossed — entirely using tools native to the device itself, without any external assurance platform; a full-scale solution would add correlation across many devices and metrics simultaneously, but the fundamental detect-and-alert loop is identical to what was built here.