Hands-On Lab: Configuring Embedded Event Manager (EEM)

This hands-on lab configures an EEM applet that automatically detects an interface flapping and executes a corrective action, demonstrating how IOS itself can respond to specific events without external monitoring software or manual intervention.

EEM Applet ConfigurationEvent DetectorAutomated Corrective Action

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۴ مهر ۱۴۰۵

Lab Objective

Configure an EEM applet that triggers on a specific syslog message pattern indicating interface instability, automatically executes a corrective command sequence, and sends a notification, verifying the entire response happens without any external scripting or manual intervention.

Lab Purpose

Syslog and SNMP, covered earlier in this series, are excellent for reporting events to a human or external system, but they require someone or something outside the router to actually act on that information. EEM lets the router itself watch for specific conditions and automatically respond, useful for well-understood, repeatable problems that do not need human judgment to resolve.

Lab Topology

R1 ---- Gi0/1 ---- (interface prone to
                    intermittent flapping
                    in this scenario)

Task 1: Configure an EEM Applet Watching for Link Flap Syslog Messages

Create an EEM applet that triggers when the LINK-3-UPDOWN syslog message appears for Gi0/1.

Task 2: Configure the Applet to Log a Custom Message

Have the applet generate a distinct, easily searchable log entry when triggered.

Task 3: Configure the Applet to Execute a Corrective Command

Have the applet automatically shut down and re-enable the interface as a basic corrective action.

Task 4: Simulate the Triggering Condition

Manually cause the interface to flap and observe the applet fire.

Task 5: Verify the Applet's Actions Occurred

Confirm both the custom log message and the corrective interface action took place automatically.

Solution and Verification

R1(config)# event manager applet LINK-FLAP-RESPONSE
R1(config-applet)# event syslog pattern "LINEPROTO-5-UPDOWN.*GigabitEthernet0/1"
R1(config-applet)# action 1.0 syslog msg "EEM detected Gi0/1 flap - initiating response"
R1(config-applet)# action 2.0 cli command "enable"
R1(config-applet)# action 3.0 cli command "configure terminal"
R1(config-applet)# action 4.0 cli command "interface gigabitethernet0/1"
R1(config-applet)# action 5.0 cli command "shutdown"
R1(config-applet)# action 6.0 wait 5
R1(config-applet)# action 7.0 cli command "no shutdown"

-- The event detector watches for a regex
-- pattern in syslog output specifically,
-- rather than polling interface status
-- directly

-- Simulating a flap:

R1(config)# interface gigabitethernet0/1
R1(config-if)# shutdown
R1(config-if)# no shutdown

*Jun 20 10:15:02: %LINEPROTO-5-UPDOWN: Line protocol
on Interface GigabitEthernet0/1, changed state to down
*Jun 20 10:15:05: %LINEPROTO-5-UPDOWN: Line protocol
on Interface GigabitEthernet0/1, changed state to up

R1# show logging | include EEM

*Jun 20 10:15:05: %HA_EM-6-LOG: LINK-FLAP-RESPONSE:
EEM detected Gi0/1 flap - initiating response
-- The custom log message confirms the
-- applet fired in response to the matched
-- syslog pattern

R1# show logging | include GigabitEthernet0/1

*Jun 20 10:15:06: %LINEPROTO-5-UPDOWN: ... changed
state to down
*Jun 20 10:15:11: %LINEPROTO-5-UPDOWN: ... changed
state to up
-- A SECOND shutdown/no-shutdown cycle
-- appears, automatically triggered by the
-- applet's own action sequence, distinct
-- from the manually initiated flap that
-- triggered it

Key Takeaway

EEM applets close the loop between detection and remediation entirely within the router itself, without depending on any external management system to notice a problem and issue a fix — this makes EEM valuable specifically for well-understood, low-risk, repeatable issues where the correct response is already known in advance, though care is warranted since an automated action taken in response to a misunderstood or overly broad trigger pattern can itself cause unintended disruption.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه