Troubleshooting practice questions

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?

Trap 1: The interface MTU size is mismatched.

An MTU mismatch on an OSPF interface typically surfaces during the Database Description (DBD) exchange, because the MTU value is carried in DBD packets and a larger packet is dropped or truncated. This manifests as adjacency stagnation in the EXSTART or EXCHANGE state, not INIT. In INIT, the router has received a valid Hello but is still waiting for bidirectional reachability, which is a layer of operation prior to MTU negotiation.

Trap 2: The OSPF network type is mismatched.

Both routers in this scenario default to the broadcast OSPF network type on Ethernet interfaces, so there is no network type mismatch to cause the INIT state. A true mismatch (e.g., broadcast on one side and point-to-point on the other) would alter Hello packet fields like the DR/BDR priority and options, preventing proper neighbor discovery or two-way establishment, but that is not the case here. The existing configuration resolves to identical network types.

Trap 3: The router IDs are not properly configured.

Router IDs are unique and correctly set in this scenario, so they cannot be the cause. OSPF uses router IDs for DR/BDR election, database exchange, and LSA identification, but the INIT state only depends on seeing your own router ID in an unauthenticated neighbor's Hello. Duplicate or missing router IDs tend to create later problems in EXSTART/EXCHANGE or cause LSDB inconsistencies, not a failure to establish two-way adjacency in INIT.

A
The interface MTU size is mismatched.
Why wrong: An MTU mismatch on an OSPF interface typically surfaces during the Database Description (DBD) exchange, because the MTU value is carried in DBD packets and a larger packet is dropped or truncated. This manifests as adjacency stagnation in the EXSTART or EXCHANGE state, not INIT. In INIT, the router has received a valid Hello but is still waiting for bidirectional reachability, which is a layer of operation prior to MTU negotiation.
B
The OSPF network type is mismatched.
Why wrong: Both routers in this scenario default to the broadcast OSPF network type on Ethernet interfaces, so there is no network type mismatch to cause the INIT state. A true mismatch (e.g., broadcast on one side and point-to-point on the other) would alter Hello packet fields like the DR/BDR priority and options, preventing proper neighbor discovery or two-way establishment, but that is not the case here. The existing configuration resolves to identical network types.
C
The OSPF authentication keys do not match.
When MD5 authentication keys differ, each router silently drops the other's Hello packets after the keyed digest fails verification. Because the local router never receives a valid Hello containing its own router ID, the neighbor state cannot advance from INIT to 2-Way. The adjacency therefore remains stuck in INIT, even though the Hello packets arrive at the interface, making this the misconfiguration exactly consistent with the symptoms.
D
The router IDs are not properly configured.
Why wrong: Router IDs are unique and correctly set in this scenario, so they cannot be the cause. OSPF uses router IDs for DR/BDR election, database exchange, and LSA identification, but the INIT state only depends on seeing your own router ID in an unauthenticated neighbor's Hello. Duplicate or missing router IDs tend to create later problems in EXSTART/EXCHANGE or cause LSDB inconsistencies, not a failure to establish two-way adjacency in INIT.

Open the full BGP breakdown →

Question 2hardmultiple choice

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?

Trap 1: Check the interface error counters for CRC errors or drops.

Interface errors would likely cause persistent failures, not intermittent.

Trap 2: Verify the BGP session state and check for route flapping.

The BGP session is established and routes are present, so route flapping may not be the cause.

Trap 3: Check the MPLS label switching table to ensure labels are correctly…

The LSP is up and labels are assigned, so this is likely not the issue.

A
Check the interface error counters for CRC errors or drops.
Why wrong: Interface errors would likely cause persistent failures, not intermittent.
B
Review the forwarding table for the affected prefixes and check for any discrepancies.
The forwarding table may have stale entries or incorrect label operations causing intermittent forwarding failures.
C
Verify the BGP session state and check for route flapping.
Why wrong: The BGP session is established and routes are present, so route flapping may not be the cause.
D
Check the MPLS label switching table to ensure labels are correctly assigned.
Why wrong: The LSP is up and labels are assigned, so this is likely not the issue.

Question 3hardmultiple choice

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?

Trap 1: Use 'deactivate protocols ospf' to disable OSPF entirely and then…

Deactivating the entire [edit protocols ospf] hierarchy disables all OSPF adjacencies and routes at once, not just the problematic changes. You would then have to manually re-enable each piece, including areas, interfaces, and authentication, without knowing exactly what the prior stable configuration contained. This approach both prolongs the routing outage and introduces a high risk of configuration drift or a syntax error, so it is not a quick or safe recovery.

Trap 2: Immediately delete the OSPF configuration sections that were…

Deleting and re-adding the OSPF sections manually means you are reconstructing the original configuration by hand in the candidate configuration. Since the changed portion is already loaded in the candidate, you would have to type out every original statement from memory or a separate backup, which is slow and prone to omissions or typos. Junos already provides a robust rollback mechanism, so manual editing is an unnecessary risk that extends the outage and offers no benefit over a proper rollback.

Trap 3: Perform a 'load factory-default' and 'commit' to reset the device…

Loading factory-default is a drastic operation that erases the entire Junos configuration, including system settings, interfaces, routing instances, and security policies, not just the OSPF portion. After that, you would need a complete backup to restore the router to its original state, and even with a backup, it is much slower than a targeted rollback and risks losing other untracked changes. This is meant for initial provisioning or complete reinitialization, not for fixing a single protocol misconfiguration, so it causes far longer downtime than necessary.

A
Use 'deactivate protocols ospf' to disable OSPF entirely and then manually re-enable pieces.
Why wrong: Deactivating the entire [edit protocols ospf] hierarchy disables all OSPF adjacencies and routes at once, not just the problematic changes. You would then have to manually re-enable each piece, including areas, interfaces, and authentication, without knowing exactly what the prior stable configuration contained. This approach both prolongs the routing outage and introduces a high risk of configuration drift or a syntax error, so it is not a quick or safe recovery.
B
Immediately delete the OSPF configuration sections that were changed and re-add the original settings manually.
Why wrong: Deleting and re-adding the OSPF sections manually means you are reconstructing the original configuration by hand in the candidate configuration. Since the changed portion is already loaded in the candidate, you would have to type out every original statement from memory or a separate backup, which is slow and prone to omissions or typos. Junos already provides a robust rollback mechanism, so manual editing is an unnecessary risk that extends the outage and offers no benefit over a proper rollback.
C
Use 'rollback 1' to revert to the configuration before the changes, then 'commit confirmed 10' to verify stability.
This is the correct approach because rollback 1 reverts the candidate configuration to the last committed configuration prior to the current one, which is exactly the stable state you want. Issuing commit confirmed 10 activates that configuration for 10 minutes; if nothing else is done, the system automatically rolls back to the previous config, ensuring connectivity is restored without a permanent lock-in. You can later issue commit (or commit confirmed again) to make the change permanent once you have verified OSPF stability.
D
Perform a 'load factory-default' and 'commit' to reset the device to base settings, then reconfigure from backup.
Why wrong: Loading factory-default is a drastic operation that erases the entire Junos configuration, including system settings, interfaces, routing instances, and security policies, not just the OSPF portion. After that, you would need a complete backup to restore the router to its original state, and even with a backup, it is much slower than a targeted rollback and risks losing other untracked changes. This is meant for initial provisioning or complete reinitialization, not for fixing a single protocol misconfiguration, so it causes far longer downtime than necessary.

Question 4hardmultiple choice

You are a junior network engineer at a company that uses Juniper MX routers. You are troubleshooting a connectivity issue on a branch router. The branch router has two upstream links to the corporate network: ge-0/0/0 (10.1.1.1/30, connected to core router A) and ge-0/0/1 (10.1.1.5/30, connected to core router B). The branch router runs OSPF and has a default route learned from both upstream routers. The routing table shows two equal-cost default routes via both next hops. However, traffic from the branch to the corporate network is experiencing intermittent high latency and some packet loss. You suspect that asymmetric routing is causing issues because the return traffic is not following the same path. You want to influence the router to prefer one upstream link for all traffic to the corporate network. You have decided to adjust the OSPF metric on the branch router to make the link to core router A more preferred. You are in configuration mode on the branch router. Which single configuration change will accomplish this goal?

Trap 1: set interfaces ge-0/0/1 unit 0 family inet cost 200

The `cost` parameter is not a valid interface-level statement under `family inet` in JUNOS; OSPF interface cost or metric is configured under the `protocols ospf` hierarchy, typically as `metric`. This command would be rejected by the CLI because the leaf `cost` does not exist at that level, so it has no effect on OSPF path selection. Even if it were accepted, OSPF reads its interface metric from the OSPF configuration, not from the interface family settings, so this change would not influence the preference between ge-0/0/0 and ge-0/0/1.

Trap 2: set protocols ospf area 0 interface ge-0/0/1 passive

Configuring `ge-0/0/1` as a passive OSPF interface stops the device from sending or processing OSPF Hello packets on that link, which prevents the formation of an OSPF adjacency with the neighbor attached to that interface. Without an adjacency, the remote router will not learn the routes through ge-0/0/1, and OSPF will not advertise transit transit traffic over that link, potentially causing a blackhole or loss of connectivity if the path should remain usable. Passive mode is useful for advertising directly connected networks like loopbacks or stub segments without exchanging routing information, but it is the wrong tool here because the goal is to alter path preference while keeping the neighbor relationship intact.

Trap 3: set interfaces lo0 unit 0 family inet address 10.0.0.1/32 metric 100

The `metric` statement is not valid under `family inet` at the interface hierarchy level; JUNOS does not allow setting an OSPF metric on the loopback interface that way, and the command would be rejected. More importantly, the loopback address `10.0.0.1/32` is a host route that OSPF advertises as a stub network, and its OSPF metric is derived from the OSPF interface metric configured for the loopback in OSPF, not from any generic interface metric. Altering a loopback metric would only affect how other routers see the loopback itself, not how transit traffic is routed through ge-0/0/1, so it cannot solve the intended path-selection problem.

A
set interfaces ge-0/0/1 unit 0 family inet cost 200
Why wrong: The `cost` parameter is not a valid interface-level statement under `family inet` in JUNOS; OSPF interface cost or metric is configured under the `protocols ospf` hierarchy, typically as `metric`. This command would be rejected by the CLI because the leaf `cost` does not exist at that level, so it has no effect on OSPF path selection. Even if it were accepted, OSPF reads its interface metric from the OSPF configuration, not from the interface family settings, so this change would not influence the preference between ge-0/0/0 and ge-0/0/1.
B
set protocols ospf area 0 interface ge-0/0/1 passive
Why wrong: Configuring `ge-0/0/1` as a passive OSPF interface stops the device from sending or processing OSPF Hello packets on that link, which prevents the formation of an OSPF adjacency with the neighbor attached to that interface. Without an adjacency, the remote router will not learn the routes through ge-0/0/1, and OSPF will not advertise transit transit traffic over that link, potentially causing a blackhole or loss of connectivity if the path should remain usable. Passive mode is useful for advertising directly connected networks like loopbacks or stub segments without exchanging routing information, but it is the wrong tool here because the goal is to alter path preference while keeping the neighbor relationship intact.
C
set protocols ospf area 0 interface ge-0/0/1 metric 200
This is the correct configuration because in JUNOS, OSPF interface metric is explicitly set with the `metric` statement under `protocols ospf` for the specific interface. By assigning a metric of 200 to ge-0/0/1, the router's OSPF cost calculation makes that interface significantly more expensive than ge-0/0/0 (which retains the default metric, typically 10 for Ethernet), thereby forcing transit traffic to prefer ge-0/0/0. This effectively shifts traffic away from ge-0/0/1 while still allowing the OSPF adjacency to remain established, so the link stays available for redundancy or less-preferred use.
D
set interfaces lo0 unit 0 family inet address 10.0.0.1/32 metric 100
Why wrong: The `metric` statement is not valid under `family inet` at the interface hierarchy level; JUNOS does not allow setting an OSPF metric on the loopback interface that way, and the command would be rejected. More importantly, the loopback address `10.0.0.1/32` is a host route that OSPF advertises as a stub network, and its OSPF metric is derived from the OSPF interface metric configured for the loopback in OSPF, not from any generic interface metric. Altering a loopback metric would only affect how other routers see the loopback itself, not how transit traffic is routed through ge-0/0/1, so it cannot solve the intended path-selection problem.

Review the full routing breakdown →

Question 5mediummultiple choice

A network engineer is troubleshooting connectivity between two directly connected Juniper routers. The interface on Router A shows 'up' but no packets are being received from Router B. Which command should the engineer use on Router A to check if the interface is expecting to receive a specific encapsulation type?

Trap 1: show interfaces terse

The 'show interfaces terse' command outputs only a one-line summary per interface, showing administrative status, link status, and IPv4/IPv6 addresses. It deliberately omits data-link encapsulation details such as PPP or HDLC, making it unsuitable for verifying that both routers use the same encapsulation. This command is intended for a quick health check of interface state and IP addressing, not for diagnosing layer-2 framing mismatches. Relying on it here would miss the specific information needed to confirm encapsulation compatibility.

Trap 2: show configuration interfaces

The 'show configuration interfaces' command displays the configured settings for the interface from the candidate or active configuration, which might include an explicit encapsulation statement. However, it shows only the intended configuration, not the operational state or whether the encapsulation negotiation has succeeded. If the encapsulation is left at the default (e.g., HDLC on serial links), the command may not display it at all, lulling the engineer into thinking it is correct. A true verification requires the operational state shown by 'show interfaces extensive', which also exposes any mismatch between the local and remote encapsulation.

Trap 3: monitor traffic interface

The 'monitor traffic interface' command captures and displays packet data in real time, showing headers like Ethernet type or PPP protocol field, but it does not reveal the router's configured encapsulation parameter. You might see what encapsulation appears to be on the wire, but you cannot determine if the router is intentionally configured for that encapsulation or if it is a mismatch. Additionally, it is a troubleshooting tool for observing traffic flow, not a configuration inspection tool. It would not show whether the local interface's encapsulation setting matches the peer's configured setting.

A
show interfaces extensive
The 'show interfaces extensive' command is essential because it reveals the actual data-link encapsulation currently in use on the interface, along with detailed physical and protocol state information. This allows the engineer to confirm whether both routers are configured with matching encapsulation types (e.g., PPP, HDLC, or Frame Relay). It also provides error counters and keepalive statistics, which can expose framing mismatches or negotiation failures. Without this operational view, a layer-1 connectivity issue could be mistakenly attributed to configuration when the real cause is an encapsulation mismatch.
B
show interfaces terse
Why wrong: The 'show interfaces terse' command outputs only a one-line summary per interface, showing administrative status, link status, and IPv4/IPv6 addresses. It deliberately omits data-link encapsulation details such as PPP or HDLC, making it unsuitable for verifying that both routers use the same encapsulation. This command is intended for a quick health check of interface state and IP addressing, not for diagnosing layer-2 framing mismatches. Relying on it here would miss the specific information needed to confirm encapsulation compatibility.
C
show configuration interfaces
Why wrong: The 'show configuration interfaces' command displays the configured settings for the interface from the candidate or active configuration, which might include an explicit encapsulation statement. However, it shows only the intended configuration, not the operational state or whether the encapsulation negotiation has succeeded. If the encapsulation is left at the default (e.g., HDLC on serial links), the command may not display it at all, lulling the engineer into thinking it is correct. A true verification requires the operational state shown by 'show interfaces extensive', which also exposes any mismatch between the local and remote encapsulation.
D
monitor traffic interface
Why wrong: The 'monitor traffic interface' command captures and displays packet data in real time, showing headers like Ethernet type or PPP protocol field, but it does not reveal the router's configured encapsulation parameter. You might see what encapsulation appears to be on the wire, but you cannot determine if the router is intentionally configured for that encapsulation or if it is a mismatch. Additionally, it is a troubleshooting tool for observing traffic flow, not a configuration inspection tool. It would not show whether the local interface's encapsulation setting matches the peer's configured setting.

Question 6hardmultiple choice

A network engineer is troubleshooting OSPF adjacencies between two Juniper routers. The routers are directly connected and have matching OSPF configurations except for the router IDs. Router A has router-id 10.0.0.1, Router B has router-id 10.0.0.2. The adjacency remains in the EXSTART state. What is the most likely cause?

Trap 1: The router IDs are not the same.

Router IDs are 32-bit identifiers that must be unique within the OSPF routing domain. If two routers have different router IDs, that is the normal and expected condition; adjacency formation does not require router IDs to match. In fact, matching router IDs would create an error, because each router would see the other's packets as coming from itself and reject them. Therefore, the router IDs not being the same is not a fault; it is a prerequisite for a valid OSPF neighbor relationship to exist.

Trap 2: The area ID is not configured.

If the area ID were not configured, the interface would not be enabled for OSPF at all, and you would not see any neighbor entry or adjacency state. In this scenario, the adjacency reaching EXSTART means OSPF is operationally up on both ends and the routers have already exchanged Hello packets. A mismatch in area IDs would prevent the routers from even becoming neighbors, typically leaving the state at DOWN or INIT, not EXSTART. The stem indicates the configurations match in this regard, so an unconfigured or mismatched area ID is not the cause.

Trap 3: The hello and dead intervals are mismatched.

Mismatched hello and dead intervals produce failures much earlier in the OSPF neighbor discovery process. Routers only accept Hello packets that carry matching values for these timers; if they differ, the Hello packets are ignored, and the neighbor state never progresses past DOWN or INIT. EXSTART represents a far later stage, after the routers have already exchanged Hello packets and reached the 2-Way state, which proves that the hello/dead intervals were successfully matched and accepted. Thus, this option cannot explain an adjacency stuck specifically in EXSTART.

A
The MTU on the interface is mismatched.
An MTU mismatch is a classic cause of OSPF adjacency being stuck in the EXSTART state. During the Database Description (DD) packet exchange, OSPF embeds the interface MTU in the DD header. If one interface has a larger MTU and sends a DD packet that exceeds the neighbor's MTU, the receiving router will drop the packet. Since the neighbor never receives the DD packet, the routers cannot complete the master/slave negotiation, and the adjacency remains permanently in EXSTART rather than progressing to FULL.
B
The router IDs are not the same.
Why wrong: Router IDs are 32-bit identifiers that must be unique within the OSPF routing domain. If two routers have different router IDs, that is the normal and expected condition; adjacency formation does not require router IDs to match. In fact, matching router IDs would create an error, because each router would see the other's packets as coming from itself and reject them. Therefore, the router IDs not being the same is not a fault; it is a prerequisite for a valid OSPF neighbor relationship to exist.
C
The area ID is not configured.
Why wrong: If the area ID were not configured, the interface would not be enabled for OSPF at all, and you would not see any neighbor entry or adjacency state. In this scenario, the adjacency reaching EXSTART means OSPF is operationally up on both ends and the routers have already exchanged Hello packets. A mismatch in area IDs would prevent the routers from even becoming neighbors, typically leaving the state at DOWN or INIT, not EXSTART. The stem indicates the configurations match in this regard, so an unconfigured or mismatched area ID is not the cause.
D
The hello and dead intervals are mismatched.
Why wrong: Mismatched hello and dead intervals produce failures much earlier in the OSPF neighbor discovery process. Routers only accept Hello packets that carry matching values for these timers; if they differ, the Hello packets are ignored, and the neighbor state never progresses past DOWN or INIT. EXSTART represents a far later stage, after the routers have already exchanged Hello packets and reached the 2-Way state, which proves that the hello/dead intervals were successfully matched and accepted. Thus, this option cannot explain an adjacency stuck specifically in EXSTART.

Question 7easymultiple choice

A network administrator is troubleshooting a missing route in the routing table. The route is learned via OSPF, and the OSPF neighbor adjacency is up. Which command would help determine if OSPF received the route?

Trap 1: show route protocol ospf

In Junos, 'show route protocol ospf' displays only the active OSPF routes that have been selected and placed into the routing table, not every route received or advertised. Routes hidden due to higher preference, unreachable next hops, or import policy are omitted. Therefore, if the OSPF LSA exists but the route is not installed, this command will not provide the needed diagnostic insight.

Trap 2: show ospf neighbor

This command focuses on the state of OSPF neighbor adjacencies, such as Full or ExStart, and verifies hello timers, dead intervals, and area membership. It does not expose the contents of LSAs or the prefix information learned from those neighbors. A missing route can occur even when all neighbors show Full, so this command cannot directly confirm whether a specific prefix was received.

Trap 3: show interface terse

This command displays the administrative and operational status of interfaces, along with their configured IP addresses and protocol flags, but it carries no OSPF-specific state or route information. Checking interface terse only tells you whether the physical or logical interfaces are up, not whether OSPF has learned or processed any routes. The missing route would not be visible here, and an interface being down alone does not explain an OSPF LSA's absence from the database.

A
show route protocol ospf
Why wrong: In Junos, 'show route protocol ospf' displays only the active OSPF routes that have been selected and placed into the routing table, not every route received or advertised. Routes hidden due to higher preference, unreachable next hops, or import policy are omitted. Therefore, if the OSPF LSA exists but the route is not installed, this command will not provide the needed diagnostic insight.
B
show ospf neighbor
Why wrong: This command focuses on the state of OSPF neighbor adjacencies, such as Full or ExStart, and verifies hello timers, dead intervals, and area membership. It does not expose the contents of LSAs or the prefix information learned from those neighbors. A missing route can occur even when all neighbors show Full, so this command cannot directly confirm whether a specific prefix was received.
C
show ospf database
The OSPF database command reveals the link-state advertisements (LSAs) stored in the router's OSPF LSDB, including Router, Network, and Summary LSAs that contain the actual prefix information. This is the authoritative source to verify whether a route's LSA has been received and is present in the network topology. If the prefix appears here but not in the routing table, the troubleshooting focus shifts to route selection or policy, making this the correct diagnostic step.
D
show interface terse
Why wrong: This command displays the administrative and operational status of interfaces, along with their configured IP addresses and protocol flags, but it carries no OSPF-specific state or route information. Checking interface terse only tells you whether the physical or logical interfaces are up, not whether OSPF has learned or processed any routes. The missing route would not be visible here, and an interface being down alone does not explain an OSPF LSA's absence from the database.

Read the full Troubleshooting explanation →

Question 8easymultiple choice

An engineer needs to view the current active configuration of a Junos device without making any changes. Which CLI mode should they use?

Trap 1: Privileged mode

Privileged mode is a concept from Cisco IOS, not Junos. Junos separates the CLI into operational and configuration modes, and user access is governed by login classes and permissions rather than a distinct privileged exec level. Claiming that viewing the active configuration requires 'privileged mode' is incorrect because operational mode already provides that access without any elevation.

Trap 2: Configuration mode

Configuration mode is entered with 'configure' and is intended for modifying the candidate configuration using commands like 'set', 'edit', and 'delete'. While 'show' is available inside configuration mode, it displays the candidate configuration, not necessarily the active configuration. This mode is not read-only, and it is not required merely for viewing the current active configuration.

Trap 3: Exclusive configuration mode

Exclusive configuration mode is a special form of configuration mode invoked with 'configure exclusive', which locks other users out of configuring the device. It is still an editing mode, not a read-only viewing mode, and it is overkill for simply inspecting the active configuration. Exclusivity is about preventing concurrent edits, not about enabling read-only access.

A
Operational mode
Operational mode is the default Junos CLI state, where an engineer can execute read-only commands such as 'show configuration' and 'show interfaces'. It provides a complete view of the active configuration without permitting any direct edits. To change the configuration, the engineer must explicitly enter configuration mode, making operational mode strictly for monitoring and verification.
B
Privileged mode
Why wrong: Privileged mode is a concept from Cisco IOS, not Junos. Junos separates the CLI into operational and configuration modes, and user access is governed by login classes and permissions rather than a distinct privileged exec level. Claiming that viewing the active configuration requires 'privileged mode' is incorrect because operational mode already provides that access without any elevation.
C
Configuration mode
Why wrong: Configuration mode is entered with 'configure' and is intended for modifying the candidate configuration using commands like 'set', 'edit', and 'delete'. While 'show' is available inside configuration mode, it displays the candidate configuration, not necessarily the active configuration. This mode is not read-only, and it is not required merely for viewing the current active configuration.
D
Exclusive configuration mode
Why wrong: Exclusive configuration mode is a special form of configuration mode invoked with 'configure exclusive', which locks other users out of configuring the device. It is still an editing mode, not a read-only viewing mode, and it is overkill for simply inspecting the active configuration. Exclusivity is about preventing concurrent edits, not about enabling read-only access.

Question 9easymultiple choice

You are a network engineer for a company that uses two Juniper routers, R1 and R2, connected via an Ethernet link. R1 and R2 are running OSPF in the same area, and R2 also has an eBGP session with a service provider to reach the internet. On R1, you have configured a static route to the subnet 172.16.10.0/24 with a next-hop of 192.168.1.2, which is the IP address of R2's interface facing R1. You have verified that the static route is configured correctly in the configuration, but traffic from R1 to 172.16.10.0/24 is not being forwarded. You check the routing table on R1 and see that the static route is present but marked as 'hidden'. You also notice that R1 has an OSPF-learned route to 192.168.1.0/30 (the link between R1 and R2) with a cost of 1. What is the most appropriate next troubleshooting step?

Trap 1: Disable the eBGP session on R2 to remove the BGP routes from the…

Incorrect: BGP routes on R2 do not affect R1's static route next-hop reachability; the issue is on R1.

Trap 2: Increase the static route's preference to a lower value (e.g., 4).

Incorrect: the default preference of 5 is already very low; a lower preference would not help because the route is hidden, not competing with another route.

Trap 3: Configure a more specific static route to 172.16.10.0/24 with a…

Incorrect: a more specific route would still have the same next-hop and would also be hidden if the next-hop is unreachable.

A
Disable the eBGP session on R2 to remove the BGP routes from the routing table.
Why wrong: Incorrect: BGP routes on R2 do not affect R1's static route next-hop reachability; the issue is on R1.
B
Increase the static route's preference to a lower value (e.g., 4).
Why wrong: Incorrect: the default preference of 5 is already very low; a lower preference would not help because the route is hidden, not competing with another route.
C
Configure a more specific static route to 172.16.10.0/24 with a mask of /25.
Why wrong: Incorrect: a more specific route would still have the same next-hop and would also be hidden if the next-hop is unreachable.
D
Check if the next-hop IP 192.168.1.2 is reachable via the directly connected interface.
Correct: the next-hop unreachability is the most common cause of a hidden static route; verifying reachability (e.g., ping, ARP) will identify the issue.

Read the full Troubleshooting explanation →

Question 10mediummultiple choice

A junior engineer is troubleshooting connectivity issues and wants to trace the path packets take to a remote destination. Which Junos command should be used?

Trap 1: monitor traffic

monitor traffic captures and decodes packets that traverse a specific interface on the local device, similar to tcpdump, using filters to narrow the capture. It is a passive troubleshooting tool that does not generate probe packets, nor does it follow a packet's journey beyond the local segment. Consequently, it cannot reveal the forward path across multiple routers, making it unsuitable for path tracing.

Trap 2: show route

show route displays the routing table on a single Junos device, including prefixes, active routes, next hops, and protocol preferences. While it tells you where the router would forward a packet based on its local forwarding table, it gives no information about how those packets are actually processed by downstream routers. It is a snapshot of local routing state, not a measurement of the end-to-end path.

Trap 3: ping

ping sends ICMP Echo Requests to a destination and waits for ICMP Echo Replies to verify reachability and measure round-trip time. It is a valuable connectivity check, but it only gives an end-to-end up/down result: the reply comes from the final destination, not from intermediate routers, so the path taken is completely hidden. No per-hop information appears, making it useless for path tracing.

A
monitor traffic
Why wrong: monitor traffic captures and decodes packets that traverse a specific interface on the local device, similar to tcpdump, using filters to narrow the capture. It is a passive troubleshooting tool that does not generate probe packets, nor does it follow a packet's journey beyond the local segment. Consequently, it cannot reveal the forward path across multiple routers, making it unsuitable for path tracing.
B
show route
Why wrong: show route displays the routing table on a single Junos device, including prefixes, active routes, next hops, and protocol preferences. While it tells you where the router would forward a packet based on its local forwarding table, it gives no information about how those packets are actually processed by downstream routers. It is a snapshot of local routing state, not a measurement of the end-to-end path.
C
traceroute
traceroute is the correct tool because it actively probes the network path by sending packets with incrementally increasing TTL values, then collects the ICMP TTL-exceeded messages sent back by each router in turn. This reveals the sequence of IP addresses of every hop along the route to the destination, along with round-trip times for each hop, thus mapping the actual forwarding path hop by hop.
D
ping
Why wrong: ping sends ICMP Echo Requests to a destination and waits for ICMP Echo Replies to verify reachability and measure round-trip time. It is a valuable connectivity check, but it only gives an end-to-end up/down result: the reply comes from the final destination, not from intermediate routers, so the path taken is completely hidden. No per-hop information appears, making it useless for path tracing.

Open the full VLAN trunking answer →

Question 11mediummultiple choice

You are troubleshooting a network connectivity issue at a medium-sized company that uses Juniper EX4300 switches. Users in VLAN 100 (10.10.100.0/24) report that they cannot access a server in VLAN 200 (10.10.200.0/24). The switch has IRB interfaces configured for both VLANs and is acting as the default gateway. The IRB interfaces are up and have correct IP addresses. The server and users have correct IP configurations. 'show arp' on the switch shows incomplete entries for some hosts in VLAN 100. 'show ethernet-switching table' shows MAC addresses for users are present on the correct access ports. However, pings from the switch to a user in VLAN 100 fail. What is the most likely issue?

Trap 1: Spanning Tree Protocol is blocking the user ports.

Spanning Tree Protocol (STP) blocking the user ports would place those interfaces in a BLK/alternate state, preventing the switch from sending or receiving frames on them. In that state, the switch would not transmit ARP requests on those ports, so it would not record an incomplete ARP entry for the user host; instead, the ARP entry would be absent entirely. Since the symptom is an ARP entry stuck in 'incomplete', STP is not the cause—that state indicates the switch actively sent ARP requests but received no replies.

Trap 2: A static MAC address entry for the server is missing.

The issue is with the switch trying to resolve the user's IP address to a MAC address via ARP, not with forwarding to the server. ARP entries are populated dynamically from received packets, and a static MAC address entry for the server would only matter if the switch needed to reach the server's MAC directly without an ARP exchange. If the server's MAC were missing, traffic to the server would fail with 'no route to host' or a different symptom, not an incomplete ARP entry for a user host in VLAN 100.

Trap 3: The IRB interface for VLAN 100 is not configured with a proxy ARP.

Proxy ARP is a feature where a Layer 3 device responds to ARP requests on behalf of another device, typically one on a different subnet. In this scenario, the switch's IRB interface for VLAN 100 and the user host are on the same subnet, so the user host should respond to ARP requests directly—proxy ARP is unnecessary for local subnet communication. Disabling or omitting proxy ARP does not prevent the switch from resolving ARP for a directly connected host; it only affects resolution across subnets when routing is involved.

A
Spanning Tree Protocol is blocking the user ports.
Why wrong: Spanning Tree Protocol (STP) blocking the user ports would place those interfaces in a BLK/alternate state, preventing the switch from sending or receiving frames on them. In that state, the switch would not transmit ARP requests on those ports, so it would not record an incomplete ARP entry for the user host; instead, the ARP entry would be absent entirely. Since the symptom is an ARP entry stuck in 'incomplete', STP is not the cause—that state indicates the switch actively sent ARP requests but received no replies.
B
A static MAC address entry for the server is missing.
Why wrong: The issue is with the switch trying to resolve the user's IP address to a MAC address via ARP, not with forwarding to the server. ARP entries are populated dynamically from received packets, and a static MAC address entry for the server would only matter if the switch needed to reach the server's MAC directly without an ARP exchange. If the server's MAC were missing, traffic to the server would fail with 'no route to host' or a different symptom, not an incomplete ARP entry for a user host in VLAN 100.
C
The switch cannot resolve ARP requests because the user's host is not responding.
When a switch's ARP table shows an entry as 'incomplete', it means the switch has sent ARP requests for that IP address but has not received any ARP reply. This occurs when the target host is down, has the wrong IP address, or is configured with a firewall that silently drops ARP probes. The user's host is not responding to the ARP requests, so the switch cannot determine the MAC address needed to forward frames, breaking connectivity even though the host may be physically connected.
D
The IRB interface for VLAN 100 is not configured with a proxy ARP.
Why wrong: Proxy ARP is a feature where a Layer 3 device responds to ARP requests on behalf of another device, typically one on a different subnet. In this scenario, the switch's IRB interface for VLAN 100 and the user host are on the same subnet, so the user host should respond to ARP requests directly—proxy ARP is unnecessary for local subnet communication. Disabling or omitting proxy ARP does not prevent the switch from resolving ARP for a directly connected host; it only affects resolution across subnets when routing is involved.

Open the full VLAN trunking answer →

Question 12easymultiple choice

An engineer is troubleshooting a network issue where hosts on the same VLAN cannot communicate with each other. Which configuration element is most likely missing?

Trap 1: An IRB interface for the VLAN

An IRB interface provides Layer 3 functionality for a VLAN on MX or EX series.

Trap 2: A Layer 3 switchport

Layer 3 switchports are for routed ports, not VLAN interfaces.

Trap 3: A default gateway for the VLAN

Default gateway is for inter-VLAN communication, not intra-VLAN.

A
Spanning Tree Protocol enabled
STP prevents loops, does not affect Layer 3 connectivity.
B
An IRB interface for the VLAN
Why wrong: An IRB interface provides Layer 3 functionality for a VLAN on MX or EX series.
C
A Layer 3 switchport
Why wrong: Layer 3 switchports are for routed ports, not VLAN interfaces.
D
A default gateway for the VLAN
Why wrong: Default gateway is for inter-VLAN communication, not intra-VLAN.

Read the full Troubleshooting explanation →

Question 13hardmultiple choice

During troubleshooting, an engineer needs to view real-time logging messages on a Junos device. Which command should be used?

Trap 1: file show /var/log/messages

Shows file content, not real-time.

Trap 2: show log messages

Shows log file, not real-time.

Trap 3: traceoptions

Configuration statement, not a command.

A
file show /var/log/messages
Why wrong: Shows file content, not real-time.
B
monitor start messages
Displays real-time log messages.
C
show log messages
Why wrong: Shows log file, not real-time.
D
traceoptions
Why wrong: Configuration statement, not a command.