JN0-106 Junos OS Fundamentals Practice Question
Your enterprise network uses Juniper EX4300 switches in a collapsed core design with RSTP (802.1w) as the Layer 2 loop prevention protocol. You add a new EX2300 switch to an access closet and connect it to two different core switches using two uplink interfaces configured in an LACP LAG. After connecting the new switch, you notice intermittent connectivity issues across the entire network, with some devices reporting temporary packet loss. The issue occurs sporadically, especially during configuration changes or when links flap. You suspect the problem is related to RSTP. Upon investigation, you see that the new switch's uplink interfaces are both in the forwarding state, but occasionally one of them transitions to blocking and then back to forwarding. What is the most likely cause of the intermittent issues?
⚠ Common exam trap
The trap here is thinking that a LAG across two different switches works like a single LAG. In Junos, a standard LACP LAG spans only a single remote switch (unless using MC-LAG or virtual chassis). Without that, RSTP treats the links as separate and blocks one.
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 LAG is not recognized as a single logical link by RSTP, causing RSTP to see two separate links and create a loop
B is correct because the two uplinks are connected to two different core switches. A standard LACP LAG requires both links to terminate on the same remote switch. Since they terminate on different switches, the LAG does not form and RSTP sees two separate physical links. This creates a loop between the EX2300 and the core (via the core switches' interconnection), so RSTP blocks one link. When configuration changes or link flaps occur, RSTP recalculates and the blocked port can temporarily transition to forwarding, causing intermittent packet loss.
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 LACP system priority is set too low on the new switch, causing it to lose LACP negotiations
Why it's wrong here
LACP system priority is not a negotiation metric that can cause the bundle to be 'lost'; a numerically lower value actually grants the switch a higher priority when deciding which end controls aggregation, so setting it lower on the new switch would make it more likely to become the active side, not less. Even with an unfavorable priority, LACP still completes if both peers are configured with compatible modes and key values, and once the LAG forms, RSTP treats it as a single logical interface. The described symptom points to RSTP failing to see the aggregate, which is a LAG configuration issue, not an LACP priority issue.
- ✓
The LAG is not recognized as a single logical link by RSTP, causing RSTP to see two separate links and create a loop
Why this is correct
RSTP should treat a LAG as one link, but if the LAG is not configured correctly (e.g., missing 'lacp' or 'aggregate' statements), RSTP can see separate links and cause a loop, leading to intermittent blocking.
- ✗
The uplink interfaces are configured as alternate ports instead of root ports
Why it's wrong here
RSTP port roles (root, alternate, designated, backup) are derived dynamically from the exchange of BPDUs and the calculated path cost to the root bridge; they cannot be manually assigned as 'alternate' or 'root' in configuration. If both uplinks were somehow placed into an alternate state, they would be discarding traffic rather than forwarding, so the result would be a total loss of uplink connectivity, not an intermittent loop. The actual loop occurs because RSTP sees two separate forwarding links, and the blocking decision between them is unstable—not because a role was preselected.
- ✗
The new switch has a different root bridge priority, causing it to become the root and disrupting topology
Why it's wrong here
A different root bridge priority can change which switch is elected root, but after the spanning-tree topology converges, port roles stabilize and the switch stops flushing its forwarding database; it does not cause ongoing intermittent blocking. For the new switch to become root, its priority must be numerically lower (higher priority) than the current root, and the resulting topology change would be a one-time convergence event, not a recurring loop. The intermittent blocking in this scenario is the classic symptom of RSTP treating two separate physical links as independent paths while the LAG fails to aggregate them, which is unrelated to the root bridge election.
Visual reference
Go deeper
Related to this question
About these practice questions
Courseiva writes every JN0-106 question from scratch — 326 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This JN0-106 practice question is part of Courseiva's free Juniper Networks 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 JN0-106 exam.