Scenario practice questions

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

Why it fails: 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.

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

Why it fails: 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.

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

Why it fails: 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.

Loop guard

Why it fails: Loop guard is a protection mechanism for non-designated ports, such as alternate or root ports, that prevents them from entering the forwarding state when BPDUs stop arriving—typically due to a unidirectional link failure. It does not proactively shut down a port that receives an unexpected BPDU; instead, it places the port into an inconsistent state if BPDUs cease. On a PortFast edge port, loop guard is not appropriate because PortFast assumes no other bridge is attached, and loop guard does nothing to stop the initial reception of a BPDU from a rogue switch. Therefore, while loop guard addresses certain failure scenarios, it does not fulfill the rapid BPDU-triggered shutdown that is needed here.

Root guard

Why it fails: Root guard is designed to enforce the root bridge placement by preventing a designated port from becoming a root port. When a port configured with root guard receives a superior BPDU—one that advertises a lower bridge ID or path cost—it transitions the port to a root-inconsistent state rather than allowing the port to be selected as the root port. This does not cause the port to be disabled merely for receiving any BPDU; only superior BPDUs trigger the reaction, and the port continues to forward normal traffic before that event. On a PortFast access port, an end host would never send a superior BPDU, so root guard would not provide the expected protection against a connected switch. Hence, root guard solves a different problem and is not interchangeable with BPDU guard.

UplinkFast

Why it fails: UplinkFast is a Cisco proprietary feature that accelerates convergence after an uplink failure on a switch by immediately promoting an alternate port to forwarding and sending multicast frames to update CAM tables. It operates on root and alternate ports, not on edge ports, and relies on the underlying spanning tree state rather than monitoring for unexpected BPDUs. Enabling UplinkFast alongside PortFast would not shut down a port that receives a BPDU; it only speeds up recovery after a link fails. Therefore, UplinkFast is unrelated to the security concern of an unauthorized switch being connected to a PortFast port, making it an incorrect answer here.

It performs a commit check on both REs but does not activate the config.

Why it fails: A commit check is a dry-run validation that examines the candidate configuration for syntax errors, semantic problems, and other inconsistencies without applying it to the active configuration. In a dual-RE high-availability cluster, you might run 'commit check' (or 'commit check synchronize') to preview the change, but it never activates the configuration on either RE. This is in contrast to the required 'commit synchronize', which loads and activates the configuration on both Routing Engines, making it the actual commit operation.

It commits the configuration only on the primary RE.

Why it fails: A plain 'commit' executed on the primary Routing Engine without the 'synchronize' option applies the candidate configuration only to that RE, leaving the backup Running the previous configuration. This creates a mismatch between the two REs, which is dangerous in a high-availability cluster because if the primary fails, the backup will come online with stale or incompatible settings. High-availability clusters mandate that both REs share the same configuration, so a non-synchronized commit is insufficient and violates the dual-RE consistency requirement.

It commits the configuration only on the backup RE.

Why it fails: Committing only on the backup Routing Engine is non-standard and particularly flawed: it forces the backup to accept a configuration that the primary never validated or activated, while the primary continues running its old configuration. Even if you execute a commit from the backup RE (which may be possible in some Junos configurations), the primary's configuration remains untouched, resulting in two divergent active configurations. The proper operation for a cluster is always a synchronized commit that writes and activates the same configuration on both REs, ensuring cluster-wide consistency.

Use 'monitor interface ge-0/0/0' and rely on terminal persistence

Why it fails: The 'monitor interface ge-0/0/0' command displays real-time interface statistics and status updates in an interactive terminal, but its output is only visible while that terminal session is open. Relying on terminal persistence, such as a terminal emulator's scrollback or a multiplexer, still requires the SSH connection to remain active; if the connection drops or the administrator stops watching, the flapping events are not captured or logged. Moreover, this command does not produce a persistent records of state changes — it merely shows a live snapshot, so intermittent flaps are easily missed.

Use 'monitor start' to capture logs

Why it fails: The 'monitor start' command streams the contents of log files to the terminal, typically showing syslog messages generated by the device, but it is purely a live output mechanism. The data is sent only over the active SSH session, and if that session terminates, the log stream stops and no copy is retained on the device unless the log was already being written to a file by other means. Therefore, this approach still requires an active SSH session to receive the data, and it does not inherently record the interface flap event in an easily accessible way without additional configuration.

Schedule a cron job to run 'show interfaces ge-0/0/0' every minute and log output

Why it fails: A cron job that runs 'show interfaces ge-0/0/0' every minute from a remote server depends on the remote server being able to establish an SSH session to the Junos device at each scheduled run. This polling interval is far too coarse to catch multiple interface flaps that occur within the same minute, so a brief down/up transition can easily slip between polls and never be logged. Additionally, the approach requires the SSH connection to be available during the poll, which may fail if the interface or the management path is temporarily down — exactly the situation being investigated.

Roll back to the previous configuration to ensure the device is in a known state.

Why it fails: Rolling back to the previous committed configuration is a reactive, disruptive measure that removes the new policy and returns the device to an older state without addressing the underlying cause. It does not reveal whether a previously existing policy is intercepting the traffic, and the same denial could recur even after rollback if the issue lies in policy ordering or other global settings.

Run 'show configuration | display set | match policy' to verify the policy is present.

Why it fails: The 'show configuration | display set | match policy' command displays the candidate configuration in set format, confirming that the policy exists in the configuration hierarchy, but it does not show the active, evaluated policy order at runtime. A policy can be present yet still be shadowed by an earlier rule; this command lacks the operational context needed to diagnose a traffic matching issue.

Check the firewall logs with 'show log messages | match deny' to see which policy is denying.

Why it fails: Checking 'show log messages | match deny' is indirect and often misleading because 'show log messages' primarily displays system operations logs, not the dedicated security event stream where firewall deny logs are recorded unless specifically configured. Even if you locate a deny entry, it only tells you that a denial occurred, not which policy caused it or why it matched before your intended rule; examining the active policy order is far more definitive.

show system processes

Why it fails: show system processes displays a snapshot of the routing engine's active processes, including PID, CPU time, and memory utilization per process. It is a granular diagnostic tool for identifying a specific process consuming excessive resources, but it does not present a consolidated system-level view of overall CPU load or aggregate memory in the way the operational state query requires.

show system storage

Why it fails: show system storage focuses exclusively on the filesystem and disk usage, showing space allocated and available on the routing engine's storage media (e.g., /, /config, /var/tmp). It provides no insight into CPU load averages, memory pressure, or process activity, so while it is an operational state check, it is for storage, not for the CPU or memory state the engineer needs to assess.

show chassis hardware

Why it fails: show chassis hardware enumerates the physical components installed in the chassis, such as the Routing Engine, FPCs, PICs, power supplies, and fans, along with their serial numbers and hardware revision levels. It reports static inventory information, not dynamic operational state like CPU load or memory usage, so it cannot be used to assess the current running state of the system's processors or memory.

show system information

Why it fails: The show system information command is not a valid Junos operational command. The correct command to display system information including software version is show version. This option is a distractor that sounds plausible but does not exist in Junos.

show configuration version

Why it fails: The show configuration version command is not a valid Junos command. Configuration version information is typically viewed using show system commit or similar, but that does not provide software version. This option is incorrect and would not yield the desired information.

show chassis hardware

Why it fails: The show chassis hardware command provides detailed information about the physical hardware components, such as chassis, power supplies, and fans, but it does not display the Junos OS software version. While useful for hardware inventory, it does not meet the requirement to check the software version.