CCNP Network Assurance Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  event tag ospf-neighbor timer watchdog time 60

  Why it's wrong here

  This applet uses a timer event detector that triggers every 60 seconds. It does not specifically react to OSPF neighbor state changes; it would run periodically regardless of OSPF events. This is useful for periodic tasks, but not for event-driven monitoring of OSPF adjacencies. The engineer needs immediate notification, so a timer is inappropriate.

• ✗

  event tag ospf-neighbor cli pattern "show ip ospf neighbor"

  Why it's wrong here

  This applet uses a CLI event detector that triggers when the command output matches a pattern. However, the CLI event detector is used to trigger on command-line input, not on the output of show commands. To monitor OSPF neighbor states, the engineer would need to poll with a timer and parse the output, which is more complex and not event-driven. This is not a valid trigger for OSPF state changes.

• ✓

  event tag ospf-neighbor syslog pattern "%OSPF-5-ADJCHG"

  Why this is correct

  This applet uses a syslog event detector that matches the OSPF adjacency change syslog message. When the router logs a %OSPF-5-ADJCHG message, the EEM applet triggers. This is a common method to monitor OSPF neighbor state changes without polling. The pattern must match the exact syslog text, and the tag is used to associate actions.

• ✗

  event tag ospf-neighbor snmp oid 1.3.6.1.2.1.14.10.1.6

  Why it's wrong here

  This applet uses an SNMP event detector to poll the OSPF neighbor state OID. While SNMP can monitor OSPF, it requires SNMP configuration and polling, which is not as immediate as syslog. The OID 1.3.6.1.2.1.14.10.1.6 corresponds to ospfNbrState, but triggering on SNMP traps for state changes would require the router to send traps, not an EEM SNMP event. This is not the typical way to trigger on OSPF state changes.