Courseiva
hardMultiple Choice

300-410 Practice Question: A large enterprise network is experiencing…

A large enterprise network is experiencing intermittent BGP session resets between R1 and R2. R1 has the following relevant configuration: event manager applet BGP-MONITOR event syslog pattern "%BGP-3-NOTIFICATION" action 1.0 cli command "enable" action 2.0 cli command "clear ip bgp *" action 3.0 syslog msg "BGP session cleared by EEM". Router R2 shows: BGP neighbor 10.1.1.1 has been up for 0:00:05, state Established. What is the root cause?

⚠ Common exam trap

The trap is overlooking the feedback loop created by an EEM applet that clears BGP sessions in response to BGP notifications — candidates may focus on timer or MTU issues, but the self-inflicted reset loop is the key.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The EEM applet is triggered by the BGP notification and clears all BGP sessions, causing a reset loop.

The root cause is that the EEM applet BGP-MONITOR is triggered by the syslog pattern '%BGP-3-NOTIFICATION', and its action clears all BGP sessions with 'clear ip bgp *'. This creates a feedback loop: a BGP notification triggers the applet, which clears all BGP sessions, causing new BGP notifications, which trigger the applet again, leading to intermittent session resets. The output showing R2's BGP neighbor up for only 5 seconds confirms frequent resets.

Answer analysis

Option-by-option breakdown

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

  • ✓

    The EEM applet is triggered by the BGP notification and clears all BGP sessions, causing a reset loop.

    Why this is correct

    The EEM applet matches the %BGP-3-NOTIFICATION syslog pattern and runs 'clear ip bgp *', tearing down every BGP session. Each reset generates further notifications, retriggering the applet, so sessions never stabilise — explaining R2's five-second uptime.

  • ✗

    The BGP keepalive timer is set too low on R1.

    Why it's wrong here

    A low keepalive timer would cause hold-timer expiry and session teardown, but R2's neighbour is Established and only five seconds old, consistent with a locally issued clear rather than timer expiry. Keepalive tuning is genuinely used to detect dead peers faster on lossy links.

  • ✗

    The syslog pattern is incorrect and matches unrelated messages.

    Why it's wrong here

    The pattern %BGP-3-NOTIFICATION matches the actual notification syslog message, so the applet fires as intended; the resets are caused by the clear command it runs, not by mismatched matching. Pattern tuning would be correct if the applet were failing to trigger on the intended event.

  • ✗

    There is an MTU mismatch between R1 and R2.

    Why it's wrong here

    An MTU mismatch would stall session establishment or cause repeated resets with the neighbour flapping before reaching Established, not a stable five-second-old Established state following a notification. MTU adjustment is genuinely required when large BGP updates or TCP segments are silently dropped.

About these practice questions

This 300-410 question is part of Courseiva's 1,401-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

Same concept, more angles

1 more way this is tested on 300-410

These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.

Variation 1. A network engineer is troubleshooting an intermittent BGP session failure between two routers. The BGP session drops every few hours and recovers after a few seconds. The engineer checks the logs and sees that an EEM applet is triggered just before each failure. The applet is configured to run a script that clears the BGP session when a specific syslog message is generated. What is the most likely cause of the BGP session failure?

medium
  • A.The BGP session is failing due to a physical layer issue.
  • ✓ B.The EEM applet is clearing the BGP session as part of its configured action.
  • C.The BGP session is failing due to a routing loop.
  • D.The EEM applet is causing a memory leak that crashes the BGP process.

Why B: The logs show an EEM applet is triggered just before each BGP failure, and the applet is explicitly configured to clear the BGP session when a specific syslog message appears. This is a direct cause-and-effect: the applet's action (clearing BGP) is what is tearing down the session, not an underlying network fault.

JA

Written and reviewed by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

Last reviewed September 2026 · checked against the official Cisco exam blueprint

This 300-410 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 300-410 exam.