JN0-106 Junos OS Fundamentals Practice Question
You are a network engineer at a company that operates a pair of Juniper SRX firewalls in an active/passive cluster (Chassis Cluster). The cluster has been running Junos 15.1X49-D100 for over a year. Management has mandated an upgrade to a newer version to address security vulnerabilities. You follow the recommended upgrade procedure and successfully upgrade the primary node (node0) first, then failover to make node0 the backup, and upgrade the new primary (node1). After the upgrade, both nodes have the same version and appear to be in the cluster, but you notice that the backup node (node0) is stuck in 'ineligible' state and does not synchronize configuration changes. What is the most likely cause?
⚠ Common exam trap
Candidates often confuse 'ineligible' state with configuration synchronization issues, leading them to choose 'commit synchronize' or other configuration-related options, when the root cause is actually a physical or logical connectivity problem on the control link.
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 cluster control link is down or misconfigured on the backup node
The backup node being stuck in 'ineligible' state after a chassis cluster upgrade indicates that the cluster control link (control port) is not functioning correctly. In a Juniper SRX active/passive cluster, the control link is used for heartbeat and cluster state synchronization; if it is down or misconfigured on the backup node, the node cannot participate in the cluster election process and remains ineligible. This is a common issue after upgrades if the control link interfaces are not properly re-established or if the cable is faulty.
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 cluster control link is down or misconfigured on the backup node
Why this is correct
A node becomes ineligible when the cluster control link is not operational on that node, because the control link is the physical interface used to exchange heartbeat messages and cluster control traffic. If the control link is down, misconfigured (e.g., wrong interface name, VLAN mismatch, or disabled), or not connected, the node cannot participate in cluster state synchronization or failover, forcing it into the ineligible state. Even if the node is otherwise healthy and has all other cluster settings correct, the lack of a functioning control link alone is sufficient to prevent it from reaching eligible status.
- ✗
The backup node has not been configured with 'commit synchronize'
Why it's wrong here
'commit synchronize' is a configuration command that replicates changes from one node to the other during commit operations, ensuring configuration consistency. However, it has no bearing on the runtime cluster control operations that determine node eligibility, which are driven by control link health, heartbeat, and cluster protocol states. A backup node without commit synchronize can still be fully eligible if its control link is up and receiving heartbeats; the command only affects automated config propagation, not the ability to join the cluster.
- ✗
The 'set chassis cluster reth-count' statement is missing on the backup node
Why it's wrong here
The 'set chassis cluster reth-count' statement defines how many redundant Ethernet (reth) interfaces are created for the cluster, and it must match on both nodes to avoid interface initialization errors. While a mismatch or missing statement on the backup node could cause reth interfaces to fail to come up, it does not directly affect the eligibility determination, which is based on control link state and cluster status messages. An ineligible state is the result of a failed control link, not a discrepancy in reth interface configuration, so this option incorrectly identifies the root cause.
- ✗
The 'monitor interface' configuration is causing a mis-match between nodes
Why it's wrong here
'monitor interface' configuration is used to track the status of specific interfaces and trigger failover if a monitored interface goes down; it is a redundancy feature that operates after a node is already eligible. A mismatch in monitor interface settings between nodes might cause inconsistent failover behavior, but it does not cause a node to be marked as ineligible. Eligibility is primarily determined by the control link and cluster protocol, not by monitoring policies, so this is not the reason for the backup node's ineligible state.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 156 original JN0-106 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.