A public health clinic needs on-box automation so that when a critical uplink flaps three times, onsite staff get an immediate notification without waiting for an off-box controller. Which approach best fits?
Select an answer to reveal the explanation.
Short Explanation
EEM is the router’s little night watchman: it watches for the flap pattern and rings the clinic bell (syslog/email) right away. You do not need a big off-box brain for that simple if-this-then-that.
Full Explanation
Public-health clinics that need immediate onsite notification when a critical uplink flaps three times—without waiting for an off-box controller—should configure an EEM applet that correlates the flap events and runs an action such as syslog, email, or SNMP notify. EEM provides local, event-driven automation with sub-controller latency, which matches the stem’s on-box urgency.
Scheduling a nightly full debug all hoping someone reads the buffer by morning is neither immediate nor safe. Disabling the uplink permanently after the first flap causes avoidable outages. Replacing the clinic router with a Layer-2-only bridge so routing events disappear removes needed L3 function instead of monitoring flaps.
Exam caveat: EEM applets must rate-limit actions and avoid recursive events that re-trigger on their own syslog output. Operational check: craft an applet matching three flaps within a window, test with controlled shutdown/no-shutdown cycles, confirm notification delivery, and disable the test trigger. Document the applet in the clinic runbook alongside the controller-based monitoring that still covers fleet views. Record the chosen control and the rejected alternatives in the municipal change record so future on-call staff understand which failure modes were avoided for city services.