Hard Difficulty Questions

The route is a reject route.

Why wrong: A reject route in Junos is an explicit static route with a next-hop action of 'reject' or 'discard', which actively drops packets and, for reject, sends an ICMP unreachable message. Such routes appear in the routing table with a next-hop type of 'Reject' or 'Discard'—not 'Unreachable'. The 'Unreachable' status in the exhibit indicates that the next-hop address cannot be resolved, rather than the route being defined with a reject action, so this option is incorrect.

The route is being overridden by an OSPF route with lower preference.

Why wrong: Incorrect: if an OSPF route with a lower preference (e.g., 10) existed, it would be active, but the static route would still appear in the table as a backup; the exhibit shows the route is not active at all.

The static route preference is too high.

Why wrong: In Junos, the default preference for static routes is 5, which is lower (more preferred) than OSPF (10) or RIP (100), meaning a static route is normally chosen unless another protocol supplies a lower preference. The exhibit gives no indication of a preference value, and the route's failure is due to the unreachable next hop, not preference. Even if the preference were high, the route would still be installed if the next hop were reachable; it just might not be the active route selected when compared to other protocols. Thus, a high static preference is not the cause.

show configuration

Why wrong: Displays entire candidate configuration, no comparison.

run show configuration

Why wrong: From configuration mode, this shows the active configuration, not a comparison.

show system commit

Why wrong: Shows commit history, not differences.

set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.1/24

Why wrong: The 'set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.1/24' command is a configuration mode command used to add an IP address to an interface in the candidate configuration. It is invalid in operational mode because 'set' commands are exclusively used to edit configuration statements, and operational mode provides no access to modify the configured state of the device.

commit and-quit

Why wrong: The 'commit and-quit' command is a configuration mode command that commits the active candidate configuration to the device and then exits configuration mode, returning to operational mode. It is not valid in operational mode because there is no configuration to commit from operational mode; the 'commit' action only makes sense after configuration changes have been staged in configuration mode.

show ntp statistics

Why wrong: The Junos operational command 'show ntp statistics' provides packet-level counters such as packets sent, received, dropped, and last update times, but it does not break down the synchronization state per NTP peer. This makes it useful for diagnosing packet loss or rate issues, yet it lacks the per-peer offset, jitter, and delay values needed to analyze the overall synchronization hierarchy.

show ntp status

Why wrong: While 'show ntp status' does reveal whether the local system is synchronized, along with the stratum and the reference peer, it only offers a single global summary. It lacks the detailed per-peer metrics (delay, offset, jitter) for all candidate peers, so it cannot support a thorough analysis of how NTP synchronization is behaving across multiple associations.

show ntp peer

Why wrong: The command 'show ntp peer' is not a valid Junos operational command; Junos uses the syntax 'show ntp associations' and 'show ntp status' for NTP inspection. Entering 'show ntp peer' will produce a CLI parse error, so it cannot provide any NTP synchronization information.

The 'commit confirmed' command immediately discards changes if not confirmed.

Why wrong: It schedules a rollback; changes are not immediately discarded.

The 'commit' command always requires 'commit synchronize' when using dual Routing Engines.

Why wrong: 'commit synchronize' is used only when you want to synchronize configurations; 'commit' alone commits only on the local RE.

The router has 'no-policy-statistics' enabled on the BGP sessions.

Why wrong: The 'no-policy-statistics' setting on BGP sessions disables collection of routing policy match counters and per-route statistics. It affects only operational telemetry and accounting, not the BGP decision process or the install of routes into the routing table. Consequently, enabling it cannot prevent BGP multipath from functioning; it only makes it harder to observe why a path was not selected.

The BGP routes have different next-hop addresses.

Why wrong: BGP multipath in Junos is specifically designed to load-balance across multiple routes that resolve to different next-hop addresses. A difference in next-hop addresses is expected and, in fact, desirable for equal-cost multipath (ECMP) to spread traffic across distinct links or routers. Thus, having BGP routes with different next hops is not a blocking condition; it would only become relevant if the differing next hops are in different routing instances or not reachable.

The router is configured with 'multipath multiple-as' under BGP.

Why wrong: The 'multipath multiple-as' statement under BGP is a configuration directive that tells Junos to ignore the AS-path origin difference when considering eBGP paths for load balancing. If this directive were active, the Router would install multiple routes from different autonomous systems and perform equal-cost load balancing across them. Since the scenario describes an absence of load balancing, the presence of this command would be a remedy, not a cause; it would need to be included and verified, not diagnosed as the source of the issue.

The default confirmation timeout is 5 minutes.

Why wrong: The claim that the default confirmation timeout is 5 minutes is incorrect for Junos. The actual default is 10 minutes when `commit confirmed` is issued without an explicit timeout value. This misconception may arise from other networking platforms that use a shorter default timer. An administrator expecting 5 minutes might be caught off guard if an automatic rollback occurs later than anticipated, since the timer is longer than assumed.

It requires a reboot to revert to the previous configuration.

Why wrong: Reverting a configuration after a `commit confirmed` does not require a reboot. When the confirmation timer expires without a confirming commit, Junos automatically rolls back to the previously active configuration in real time. This rollback is handled by the control plane and does not disrupt traffic forwarding on the data plane. A reboot would be unnecessary and would undermine the purpose of the auto-rollback safety mechanism, especially in high-availability designs.

It stages the configuration in the candidate configuration but does not apply it until confirmed.

Why wrong: This option incorrectly depicts `commit confirmed` as a staging process that only applies changes after explicit approval. In reality, the configuration is applied instantly upon executing the command; it does not sit in the candidate configuration waiting for confirmation. The confirmation step simply indicates that the already-active configuration should be kept, thereby canceling the scheduled rollback. Staging without activation is characteristic of `commit check` or merely leaving changes in the candidate configuration, not `commit confirmed`.

commit check

Why wrong: This command validates the syntax, semantics, and resource limits of the candidate configuration without committing it. It reports errors but does not modify the active configuration and does not leave configuration mode. Therefore, it is useful for testing changes but is not a method to exit configuration mode.

quit

Why wrong: The 'quit' command is not recognized in the Junos CLI; it is a common command in other operating systems and CLIs, but Junos uses 'exit' to leave configuration mode. Typing 'quit' produces an error message such as 'unknown command' and leaves you in configuration mode. Therefore, it is not a valid method.

show spanning-tree bridge

Why wrong: `show spanning-tree bridge` only reports the Spanning Tree Protocol state for the switch, such as the bridge ID, root ID, and per-port STP roles. It does not inspect the data-plane traffic that is causing the CPU spike. Even if a layer-2 loop is the root cause, this command alone cannot show you the actual storm packets or which interface is receiving them; you would need commands that expose traffic behavior.

show ethernet-switching table

Why wrong: `show ethernet-switching table` lists the MAC addresses learned on each VLAN and the associated interfaces, which is useful for checking forwarding decisions or MAC flapping. During a traffic storm, this table may be large or unstable, but it does not reveal the rate, type, or source of the packets hitting the CPU. MAC learning happens in the data plane; the CPU spike is driven by traffic that is punting, and this table gives no visibility into packet contents or streams.

show interfaces extensive ge-0/0/0

Why wrong: `show interfaces extensive ge-0/0/0` displays cumulative interface counters, error counts, and queue statistics, so you can see high input rates or CRC errors. However, it is a historical counter snapshot, not a live packet analysis; it cannot tell you whether the storm is broadcast, multicast, or a specific source host. To find the actual culprit, you need to see the packets themselves, not just aggregate statistics.

The rescue configuration is automatically saved after every commit.

Why wrong: The rescue configuration is not saved automatically at any point in the commit process. A user must explicitly issue the operational-mode command 'request system configuration rescue save' to capture the active configuration as the rescue configuration. Because a commit only updates the active configuration and its rollback log, the rescue file remains untouched until manually overwritten.

The 'rollback rescue' command loads the factory-default configuration.

Why wrong: The 'rollback rescue' command loads the previously saved rescue configuration, not the factory-default configuration. When you issue this command, Junos replaces the active configuration with the rescue configuration that was captured by an earlier 'request system configuration rescue save' operation. Factory defaults are a separate baseline that you load with 'load factory-default' or by deleting the rescue configuration and rebooting.

The rescue configuration can be used to restore only a subset of the configuration.

Why wrong: The rescue configuration always contains the full active configuration at the time it was saved, and rolling back to it replaces the entire running configuration. It does not support partial or subset restoration, such as restoring only a specific interface or protocol stanza. For selective rollback, you would instead use the rollback log or configuration groups; the rescue configuration is an all-or-nothing recovery mechanism.

BGP routes

Why wrong: BGP is an exterior gateway protocol that establishes TCP sessions with peers and exchanges prefixes as it learns them. Because these routes depend on the BGP process, its neighbors, and the network state, they are dynamically learned and cannot be considered protocol-independent. Their presence in the routing table is entirely contingent on BGP's operation.

OSPF routes

Why wrong: OSPF is a link-state interior gateway protocol that builds adjacencies, floods link-state advertisements, and runs Dijkstra's algorithm to compute routes. All OSPF routes are dynamically discovered and derived from the state of the OSPF domain. Because they result from a running dynamic protocol, they are not protocol-independent.

The native VLAN cannot be changed after initial configuration.

Why wrong: In Junos, the native VLAN is not a permanent, immutable value: it is a per-interface setting in the ethernet-switching family configuration, and you can change it at any time with the `native-vlan` statement (e.g., `set interfaces ge-0/0/1 unit 0 family ethernet-switching native-vlan sales`). The running configuration is updated immediately and no reboot or complete trunk rebuild is required. Thus, claiming it cannot be changed after initial configuration misrepresents a simple, live-updatable parameter.

Frames in the native VLAN are always tagged with the VLAN ID on the trunk.

Why wrong: IEEE 802.1Q trunk links carry frames from multiple VLANs by adding a 4-byte tag, but each trunk is also allowed to designate one native VLAN whose frames are transmitted without any tag — and on arrival, those untagged frames are placed into that same native VLAN. Therefore, the statement that native VLAN frames are 'always tagged' directly contradicts how a native VLAN works; the entire point is to leave those frames untagged, often to interoperate with legacy devices or to support mixed-format traffic. On Junos, you explicitly configure the native VLAN to control which untagged packets are associated with which VLAN.

The native VLAN must be the same as the management VLAN.

Why wrong: The native VLAN and the management VLAN are conceptually separate: the native VLAN is a layer-2 trunk-port property that handles untagged frames, while the management VLAN is a layer-3 construct used for out-of-band or in-band management access (SSH/SNMP/CLI). On a Junos device, the management interface could be a separate routing (RE) port (like `me0`) or a VLAN with an IRB interface, and that VLAN is wholly independent of the trunk's native VLAN setting. There is no Junos requirement that the management VLAN equal the native VLAN; they are different configuration namespaces, and you can set them to any values you need.

Check the interface error counters for CRC errors or drops.

Why wrong: Interface errors would likely cause persistent failures, not intermittent.

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.

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.

set system syslog archive world-readable

Why wrong: This option configures the archive to be world-readable but does not store logs locally, so it does not ensure logs are stored when the remote server is unavailable.

set system syslog host 10.10.10.1 facility-override

Why wrong: This option configures a remote syslog host with facility override, which sends logs to a remote server. It does not provide local storage for when the remote server is unavailable.

set system syslog rate-limit 1000

Why wrong: This option sets a rate limit for syslog messages but does not create a local log file, so logs are not stored locally.

The router's boot device failed; need to replace hardware

Why wrong: A hardware boot-device failure would prevent the Junos kernel from loading at all, so the router would not present an Amnesiac prompt or any CLI/SSH interface. The fact that the device boots and reaches a prompt proves the boot media and OS are functional. The Amnesiac state is a configuration-layer issue, not a hardware fault, so replacing hardware is both unnecessary and would not restore the missing configuration.

The router booted from backup media; run 'request system software add' to reinstall Junos

Why wrong: Booting from backup media still yields a normally functioning Junos OS, and the router would not identify itself as 'Amnesiac' just because the primary media was unavailable. 'request system software add' is used to install or upgrade the OS itself, not to recover a lost configuration, and it would not reload the rescue configuration. Since the device is running, the software is intact; the problem is solely that no committed configuration was found at boot.

The router's flash memory is corrupted; perform a full reinstall via USB

Why wrong: Flash memory corruption typically manifests as boot failures, file-system errors, or a kernel panic, not as a clean Amnesiac prompt. If the flash were corrupted to the point of losing the configuration, the device likely would not boot at all or would show CRC/checksum errors. Performing a full reinstall via USB wipes the system and would not restore the lost configuration unless you also have a backup; the rescue-config command is a far more targeted and appropriate remedy.

Configure a virtual-link between area 2 and area 0

Why wrong: A virtual-link is an OSPF mechanism that connects a non-backbone area to Area 0 through a transit area, typically used when an area cannot physically attach to the backbone. It does not perform route summarization, and configuring one between area 2 and area 0 would only fix reachability issues, not reduce the number of routes advertised. Since the enterprise already has multiple areas and wants to reduce routing table size, a virtual-link fails to address the actual problem.

Configure a default route from area 2 using 'default-metric'

Why wrong: The 'default-metric' command is used to generate a default route into an OSPF area, often in conjunction with 'default-information originate' or when a router injects a default route. This creates a single route for all destinations outside OSPF, but it does not summarize the specific internal prefixes within area 2. The question asks for reducing the number of routes from area 2, so injecting a default route would not hide or aggregate the 10.0.x.x subnets; it would instead advertise a default alongside them or replace nothing.

Use a static route for the summary and redistribute it into OSPF

Why wrong: Configuring a static route for the summary and redistributing it into OSPF is an indirect and unnecessary approach. OSPF natively supports summarization on area border routers (ABRs) using the 'area range' command, which aggregates internal prefixes before advertising them to other areas. Redistribution would create a static route that must be manually maintained, could introduce suboptimal routing, and does not take advantage of OSPF's built-in routing hierarchy. Furthermore, redistributing a static route would require external route tagging and might cause routing loops if not carefully controlled.

VLAN translation is configured on the trunk

Why wrong: VLAN translation remaps the 802.1Q tag on a trunk link, but it operates strictly at Layer 2 and only changes which VLAN a frame belongs to. The host in VLAN 10 still has no route to the 20 subnet and no default gateway, so it will not forward the packet to the router. Even if the router received the frame, the host must first make the decision to send it there, and VLAN translation cannot influence that Layer 3 decision.

IP routing is enabled on the router

Why wrong: Enabling IP routing on the router turns on its Layer 3 forwarding capabilities, but it does nothing to address the host's missing default gateway. When the host determines the destination is off-subnet, it checks for a gateway; without one, it cannot generate a frame to reach the router. The router never sees the packet, so its routing table is irrelevant to this problem.

Dynamic ARP Inspection

Why wrong: Dynamic ARP Inspection (DAI) is a switch security feature that validates ARP packets against DHCP snooping bindings to block spoofing attacks. It only inspects and filters ARP messages; it does not influence a host's forwarding decision or provide any Layer 3 reachability. DAI cannot cause the host to send packets to the router, nor can it make a remote host appear local, so it has no bearing on inter-VLAN communication.

Remove the previous image.

Why wrong: Removing the previous image is neither necessary nor recommended because Junos automatically manages multiple software versions on the device's storage. The old image is preserved on a separate partition, enabling a quick rollback if the new release has issues. Manually deleting it could compromise rollback ability and is not part of the official upgrade path.

Commit the configuration.

Why wrong: Commit configuration is used to activate changes made in the candidate configuration, which is unrelated to software installation. During a Junos OS upgrade, existing configuration files are preserved automatically across the new install, so no commit is needed to complete the upgrade. Running commit might even trigger an unrelated config activation that is not part of the upgrade procedure.

show chassis hardware

Why wrong: The `show chassis hardware` command outputs inventory data such as model numbers, serial numbers, part numbers, and hardware revision information for installed FRUs, not runtime telemetry. While that command verifies what hardware is present or helps track spares, it never reads the environmental sensors. An operator inspecting temperature or voltage needs a command that polls the sensor plane, which is exactly what `show chassis environment` does.

show system health

Why wrong: `show system health` is not a recognized Junos operational command in standard Junos OS; typing it returns a syntax or unknown-command error. Some other network operating systems use that phrase, but Junos uses `show chassis environment` for sensor values. Because the command is not valid, it cannot produce any temperature or voltage readings, regardless of the operator's intent.

show log messages | match temperature

Why wrong: `show log messages | match temperature` pipes the system message log through a filter to find lines containing the string "temperature." This yields only historical log entries—usually alarms or threshold notices—that were previously written by the chassis daemon, not current live sensor values. If no temperature event has been logged recently, the output is empty even when a component is running warm, so this is neither a real-time nor a reliable way to monitor environmental conditions.

Increase the preference of the BGP default routes to 180 so that the static default is always preferred.

Why wrong: This would make the static default always active, preventing failover between ISPs.

Configure a routing policy on R2 to reject the default route from ISP-B, forcing all traffic through R1.

Why wrong: This would eliminate redundancy.

Remove the static default route and rely on OSPF to propagate a default route from the router with the active BGP session.

Why wrong: Without any static default, if both BGP sessions fail, there is no default route.