JNCIA-JUNOS Practice Test 36 — 15 Questions

Question 1

Scenario: Your company has a Juniper MX Series router at a branch office running Junos 18.4. The device has been in production for two years with a stable configuration. Yesterday, a senior engineer made several changes to the OSPF configuration to optimize routing for a new link. They committed the changes and left for the day. This morning, the branch office experiences intermittent connectivity, and the OSPF neighbor relationships are flapping. You suspect the recent OSPF changes caused the issue. You have remote console access to the router. The goal is to restore network stability as quickly as possible while preserving the ability to re-apply the changes after troubleshooting. Which course of action should you take?

Accepted Answer

Use 'rollback 1' to revert to the configuration before the changes, then 'commit confirmed 10' to verify stability.. Option C is correct because 'rollback 1' reverts the active configuration to the previous committed version (before the problematic OSPF changes), and 'commit confirmed 10' applies that rollback with a 10-minute confirmation timer. If connectivity stabilizes, the rollback becomes permanent; if not, the router automatically reverts to the previous configuration, ensuring no prolonged outage. This approach restores stability quickly while preserving the ability to later re-apply and test the OSPF changes in a controlled manner.

Answer

Use 'deactivate protocols ospf' to disable OSPF entirely and then manually re-enable pieces.

Answer

Immediately delete the OSPF configuration sections that were changed and re-add the original settings manually.

Answer

Perform a 'load factory-default' and 'commit' to reset the device to base settings, then reconfigure from backup.

Question 2

A company runs a Juniper SRX firewall cluster consisting of two nodes (node0 primary, node1 secondary). The cluster has been stable. During maintenance, you modify the configuration on node0 and commit. After the commit, the cluster status shows node1 as 'ineligible'. You suspect a configuration mismatch. What should you do to synchronize the configuration without disrupting traffic?

Accepted Answer

On the primary node, execute 'commit synchronize'.. The 'commit synchronize' command on the primary node (node0) pushes the active configuration to the secondary node (node1) and commits it on both nodes, ensuring configuration consistency without requiring a reboot or traffic disruption. In a Juniper SRX cluster, the primary node is the authoritative source for configuration synchronization, and this command is the standard method to resolve a configuration mismatch that causes a node to become 'ineligible'.

Answer

Reboot both nodes to force synchronization.

Answer

Manually copy the configuration file from primary to secondary.

Answer

On the secondary node, execute 'commit synchronize'.

Question 3

A Juniper router experiences a power outage. After power is restored, the router fails to boot completely and stops at the loader (U-Boot) prompt. You have console access. Before the outage, you had saved a rescue configuration. How can you load the rescue configuration to recover the system?

Accepted Answer

Type 'boot rescue' at the loader prompt.. Option B is correct because at the U-Boot loader prompt, the 'boot rescue' command instructs the router to boot using the rescue configuration stored in the /config directory. The rescue configuration is a known-good configuration that can be saved via 'request system configuration rescue save' and is loaded directly by the boot loader when the normal boot process fails.

Answer

Type 'load rescue' at the loader prompt.

Answer

Power cycle with a pin in the reset hole.

Answer

Type 'boot -s' to enter single-user mode, then load rescue.

Question 4

A Juniper SRX300 firewall is deployed at a branch office. The firewall's disk space on /var is critically low, causing logs to stop writing and system performance degradation. You need to free up space quickly without deleting logs (they are required for compliance). Which action should you take?

Accepted Answer

Compress old log files using 'request system storage compress'.. Option D is correct because the 'request system storage compress' command compresses inactive log files on the /var partition, freeing up disk space without deleting any logs. This preserves the logs for compliance requirements while immediately alleviating the low disk space condition. The command targets files that are not currently being written to, such as rotated or archived logs, and compresses them using gzip.

Answer

Increase the /var partition size using LVM.

Answer

Enable log rotation with smaller retention to prevent future growth.

Answer

Move logs to an NFS mount using 'file copy' and delete local copies.

Question 5

A service provider has two MX routers (R1 and R2) connected via two separate physical links. Both links are in an aggregated Ethernet bundle (ae0). The ae0 interface is configured with LACP active on both sides. Recently, a fiber cut occurred on one of the member links, and the aggregated interface continued working. However, after the fiber was repaired, the network operator noticed that the restored link is not being re-added to the bundle. 'show lacp interfaces' indicates the link is in a 'detached' state. The operator checks 'show interfaces diagnostics optics' and finds that the optical parameters are normal. Which action should the operator take to restore the link to the bundle without affecting traffic?

Accepted Answer

Issue the 'clear lacp statistics' command on the interface to reset LACP negotiation on that link. Option C is correct because the 'detached' state in LACP indicates that the link is physically up but LACP negotiation has failed or is stuck. The 'clear lacp statistics' command resets the LACP state machine on the specified interface, forcing it to re-initiate LACP PDUs and renegotiate with the peer. This restores the link to the bundle without disrupting active traffic on other member links.

Answer

Reboot the router to clear all LACP states

Answer

Remove and re-add the member link from the ae0 configuration

Answer

Replace the SFP module on the restored link

Question 6

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?

Accepted Answer

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

The backup node has not been configured with 'commit synchronize'

Answer

The 'set chassis cluster reth-count' statement is missing on the backup node

Answer

The 'monitor interface' configuration is causing a mis-match between nodes

Question 7

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?

Accepted Answer

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 RSTP (802.1w) treats each physical interface in a LAG as a separate link unless the LAG is explicitly configured as a logical interface (ae interface) on Junos. When the two uplinks are not bundled into a single ae interface, RSTP sees two separate links between the new switch and the core, creating a loop. This causes RSTP to block one of the links to break the loop, and when the link flaps or configuration changes occur, the port transitions between blocking and forwarding, leading to intermittent packet loss across the network.

Answer

The LACP system priority is set too low on the new switch, causing it to lose LACP negotiations

Answer

The uplink interfaces are configured as alternate ports instead of root ports

Answer

The new switch has a different root bridge priority, causing it to become the root and disrupting topology

Question 8

A network administrator is trying to configure a firewall filter on a Juniper device. They enter configuration mode and type 'set firewall family inet filter BLOCK-ICMP term 1 from protocol icmp'. They then type 'set firewall family inet filter BLOCK-ICMP term 1 then reject'. After committing, they notice that ICMP traffic is not being blocked. They run 'show configuration firewall' and see the filter is present. They run 'show firewall filter BLOCK-ICMP' to see the counters and notice the packet count is zero. What is the most likely reason?

Accepted Answer

The filter is not applied to any interface.. Option B is correct because a firewall filter in Junos must be applied to an interface to take effect. Simply configuring the filter under the 'edit firewall' hierarchy does not activate it; the filter must be referenced with a 'family inet' statement under the interface configuration (e.g., 'set interfaces ge-0/0/0 unit 0 family inet filter input BLOCK-ICMP'). Without this application, the filter exists in the configuration but never processes traffic, resulting in zero packet counts.

Answer

The protocol icmp is not correct; it should be 'icmp6'.

Answer

The term 'then reject' should be 'then discard'.

Answer

The filter must be applied under the 'edit firewall' hierarchy.

Question 9

A senior network administrator is logged into a Juniper device in operational mode. They need to make a configuration change to the BGP group 'INTERNAL'. They type 'configure terminal' and receive 'unknown command'. They then type 'configure' and enter configuration mode. They make the needed changes and exit configuration mode using 'exit'. They then try to view the active configuration to verify the changes by typing 'show configuration | match INTERNAL'. They see no output. What is the most likely reason?

Accepted Answer

They should have used 'commit' before exiting configuration mode.. Option C is correct because in Junos, configuration changes made in configuration mode are stored in a candidate configuration until explicitly committed using the 'commit' command. Exiting configuration mode with 'exit' without committing discards all uncommitted changes, so the BGP group 'INTERNAL' modification never became part of the active configuration. The 'show configuration' command displays the active (committed) configuration, which explains why no output matching 'INTERNAL' was seen.

Answer

The command 'show configuration' only shows the candidate configuration, not the active.

Answer

They exited configuration mode without committing, so the changes were lost.

Answer

They need to be in configuration mode to run 'show configuration'.

Question 10

A network engineer is configuring a Juniper device in a production network. They have applied several changes to the candidate configuration and run 'commit check', which passes. After a brief pause, they run 'commit' but receive the error: 'commit failed: configuration database modified by another user. Please reload the configuration and try again.' The engineer is the only person currently logged into the device, but they know that another engineer was working on the same device earlier and may have left a commit pending. What is the most likely reason for the commit failure?

Accepted Answer

The other engineer committed their changes between the commit check and the commit.. Option A is correct because the error message 'configuration database modified by another user' indicates that another user (the earlier engineer) had a pending commit that was not yet applied or discarded. When the current engineer ran 'commit check', it validated the candidate configuration against the current active configuration, but between that check and the actual 'commit', the other engineer's pending commit was applied (or their session was closed, causing their changes to be committed automatically if they had left a commit pending). This changed the configuration database, causing the commit to fail due to a version mismatch.

Answer

The commit check did not validate the syntax of the new changes.

Answer

The candidate configuration has timed out and must be re-entered.

Answer

The device has insufficient storage to write the new configuration.

Question 11

You are troubleshooting an OSPF adjacency issue between two Juniper MX series routers, R1 and R2, both running Junos 18.2. They are directly connected via a Gigabit Ethernet link. R1's interface ge-0/0/0 is configured with IP 192.168.1.1/24, and R2's ge-0/0/0 is configured with IP 192.168.1.2/24. Both interfaces are in OSPF area 0.0.0.0. The physical connectivity is confirmed up, and both interfaces are administratively enabled. You have checked that the hello and dead intervals match (hello 10, dead 40), the area IDs are identical, and the subnet masks are /24. No firewall filters are blocking OSPF. The OSPF configuration on R1 includes 'authentication-type md5' and 'authentication-key juniper123' under the interface. On R2, the configuration also includes 'authentication-type md5' but the key is 'juniper321'. Both routers have loopback addresses as router IDs: 1.1.1.1 for R1 and 2.2.2.2 for R2. No explicit OSPF network type is set, so the default is broadcast. Despite these configurations, the OSPF adjacency state on both routers remains in INIT. What is the most likely cause of this issue?

Accepted Answer

The OSPF authentication keys do not match.. Option C is correct because OSPF authentication keys must match exactly for the adjacency to form. R1 uses key 'juniper123' while R2 uses 'juniper321', causing the MD5 digest computed on each Hello packet to differ. Since OSPF authentication is validated per-packet, mismatched keys prevent the routers from moving past the INIT state.

Answer

The interface MTU size is mismatched.

Answer

The OSPF network type is mismatched.

Answer

The router IDs are not properly configured.

Question 12

You are managing a Juniper MX router that serves as a BGP route reflector for multiple customer VPNs. The router has two routing engines (RE0 and RE1) in a graceful switchover (GRES) configuration. During a routine maintenance window, you need to upgrade the Junos OS from version 18.1R1 to 20.2R2. The upgrade must minimize traffic disruption. You have already staged the new image on both REs. Which sequence of commands ensures minimal impact?

Accepted Answer

On RE1: request system software add jinstall-20.2R2.tgz reboot; after reboot, on RE0: request chassis routing-engine master switch; then request system software add jinstall-20.2R2.tgz reboot. Option C is correct because it performs a non-disruptive upgrade by first upgrading the backup RE (RE1), then switching mastership to the upgraded RE, and finally upgrading the original master RE. This sequence leverages Graceful Routing Engine Switchover (GRES) to maintain BGP sessions and VPN forwarding during the upgrade, minimizing traffic disruption.

Answer

On RE0: request system software add jinstall-20.2R2.tgz reboot; then on RE1 same command

Answer

On RE0: request system reboot (without adding software)

Answer

On both REs: request system software add jinstall-20.2R2.tgz reboot

Question 13

You are managing a Juniper MX240 router at a small ISP. The router has been operating normally for months. This morning, a customer reports intermittent packet loss on their connection, which is served by interface ge-0/0/2. You SSH into the router and run 'show interfaces ge-0/0/2 extensive'. The output shows input errors increasing rapidly, including CRC errors and frame errors. The interface is up/up. You also notice that the interface statistics show a high number of carrier transitions. The cable connecting the router to the customer's CPE was recently replaced by the customer's technician. What is the most likely cause of the errors and the correct action to resolve the issue?

Accepted Answer

Replace the cable with a known good one because CRC and frame errors indicate a physical layer problem such as a damaged cable or loose connector.. CRC and frame errors increasing rapidly, combined with a high number of carrier transitions, are classic symptoms of a physical-layer issue. Since the cable was recently replaced by the customer's technician, the most likely cause is a faulty cable or a loose connector. Replacing the cable with a known good one directly addresses the physical layer problem, which is the root cause of these errors.

Answer

Clear the MAC address table on the router to fix possible MAC flapping issues.

Answer

Administer a 'shutdown' and 'no shutdown' on the interface to reset the line protocol.

Answer

Change the interface speed and duplex settings to auto-negotiate because the errors are due to a mismatch between the router and CPE.

Question 14

You are a network engineer for a service provider that recently deployed a Juniper MX router at a new Point of Presence (PoP). The router is used to aggregate customer connections and exchange routes with upstream providers via BGP. After the initial configuration, you notice that the router is not learning any routes from one of the upstream BGP peers. You have verified that the BGP session is established (state Established) and that the peer is sending routes. You suspect that the issue might be related to the firewall filter or routing policy. You want to determine if any inbound routes are being rejected and why. Which command would provide the most direct information about why routes are being rejected?

Accepted Answer

show route receive-protocol bgp 192.0.2.1. Option B, 'show route receive-protocol bgp 192.0.2.1', is correct because it displays the exact routes received from a specific BGP peer along with any policy or filter actions applied (e.g., reject, accept). This command directly shows whether routes are being rejected and the reason (e.g., due to an import policy or firewall filter), making it the most direct diagnostic tool for the described issue.

Answer

show route protocol bgp

Answer

show bgp summary

Answer

show firewall filter <filter-name>

Question 15

You are responsible for a Juniper MX router that connects two customer sites over a Layer 3 VPN. The router is configured with BGP for VPN routes and uses MPLS to forward traffic. Recently, the customer reported that traffic from Site A (10.0.1.0/24) to Site B (10.0.2.0/24) is intermittently failing. You check the routing table on the router and see that both routes are present with valid next-hops. However, when you ping from the router's loopback to the remote site's loopback, the ping succeeds. MPLS labels are being assigned and the LSP is up. You also notice that when the failure occurs, the router's BGP session to the remote PE is still established. The failure seems random and lasts a few seconds before recovering. Which troubleshooting step is most likely to identify the root cause?

Accepted Answer

Review the forwarding table for the affected prefixes and check for any discrepancies.. Option B is correct because the issue is intermittent packet loss with valid routes in the routing table but successful pings from the loopback. This points to a forwarding table (FIB) inconsistency, where the control plane (routing table) has the correct next-hop, but the forwarding plane (PFE) may have a stale or incorrect entry for the specific prefixes. Checking the forwarding table with 'show route forwarding-table' will reveal if the next-hop or label information differs from the routing table, which is a classic symptom of a hardware programming issue or a transient PFE problem.

Answer

Check the interface error counters for CRC errors or drops.

Answer

Verify the BGP session state and check for route flapping.

Answer

Check the MPLS label switching table to ensure labels are correctly assigned.