Junos OS Fundamentals practice questions

request support information

Why it fails: request support information is an operational command that bundles configuration, logs, system statistics, and core files into a single archive, typically for transmission to Juniper Technical Assistance Center (JTAC) or for post-mortem analysis. It is not a targeted diagnostic for immediate high-CPU investigation because it gathers a broad, time-consuming snapshot of the entire system and may take several minutes to complete, during which the command itself can add CPU overhead. Additionally, its output is written to a tar archive (e.g., a .tgz file) rather than displayed in a real-time manner, so the operator cannot interactively sort or drill down into process-level CPU data.

show bgp summary

Why it fails: show bgp summary provides an overview of BGP peering sessions, including neighbor IP addresses, peer AS numbers, up/down times, state (Established/Active), and the number of routes sent and received per peer. While a BGP-related issue (such as route churn or a flapping peer) can cause high CPU utilization in the routing protocol daemon, this command only reveals the external symptoms of those sessions, not the CPU consumption of the underlying processes. It does not display process-level metrics or system-wide CPU usage, so it cannot conclusively identify whether excessive CPU is actually being caused by BGP processing or by another subsystem.

monitor traffic interface

Why it fails: monitor traffic interface puts the specified interface into packet-capture mode and streams packet headers and payload data to the terminal in real time, similar to a built-in tcpdump. The output is focused on network traffic content—source/destination addresses, protocol, port, and raw packet bytes—and has no bearing on process list or CPU consumption. High CPU may occur due to heavy traffic being punted to the Route Engine, but this command shows only the packets themselves, not the computational cost or the specific process responsible, so it is unsuitable for determining why the device's CPU is elevated.

Each change is applied incrementally to the active configuration.

Why it fails: This statement is false because Junos never applies edits directly to the active configuration. Instead, all changes are made to a separate candidate configuration, and a commit applies the entire candidate as a single atomic operation. Therefore, changes are not incremental; they are batched until commit, and no partial changes affect the running configuration.

The candidate configuration is stored in a separate file from the active configuration.

Why it fails: This statement is false because Junos stores the active and candidate configurations in the same configuration database, not as separate files. The candidate is a working copy of the active configuration with your pending edits, maintained in the system's memory and configuration store. There is no distinct file for the candidate; it is a logical copy within the same database.

After a commit, the candidate configuration is automatically discarded.

Why it fails: This statement is false because after a commit, the candidate configuration is promoted to become the new active configuration. It is not discarded; rather, the active configuration is replaced by the candidate, and the candidate continues to exist as the current active configuration. If you want to discard changes, you must explicitly issue a rollback command before committing.

show configuration

Why it fails: 'show configuration' is an operational command, but it only displays the candidate or active configuration hierarchy; it does not perform active network diagnostics like probing endpoints. It is used for configuration verification and review, not for live reachability or path analysis. Since the question specifically asks for diagnostic commands, this option is incorrect.

request system reboot

Why it fails: 'request system reboot' is a system control command that restarts the device or a specific component, such as a line card or routing engine. It is an operational command but not a diagnostic tool; it changes device state/availability rather than gathering network information. It is not used to test reachability or analyze traffic.

It schedules the configuration to be applied at a later time.

Why it fails: A standard commit operation applies the candidate configuration immediately, not at a later time. To defer activation, Junos provides the 'commit at' command, which schedules a commit for a specified date/time, or 'commit delay' to stage the change for a short interval. The base 'commit' command itself has no scheduling behavior; it acts synchronously as soon as it is issued.

It discards the candidate configuration after saving.

Why it fails: When a commit is executed, the candidate configuration is not discarded; instead, it is promoted to become the active configuration. After the commit completes, the candidate and active configurations are identical, and the system continues to use the newly committed settings. The candidate configuration remains available for further edits, and a subsequent 'rollback' can revert to a previous configuration, so nothing is lost.

It automatically reboots the device to apply the changes.

Why it fails: Committing a configuration does not reboot the device; Junos dynamically applies changes to the running processes without restarting the system. Many configuration changes, such as interface settings or routing policies, are applied on the fly and take effect immediately. Only a few rare changes (like certain system hardware parameters) might require a reboot, but the commit itself never triggers a reboot.

Immediately shut down all BGP peers to stop the influx of routes.

Why it fails: Shutting down all BGP peers is a drastic measure that halts route exchange but also disrupts production traffic, causing session flaps and potential packet loss. This action does not help diagnose the underlying memory issue; it only temporarily stops new routes from arriving while leaving the existing oversized routing table untouched. As a diagnostic step, it fails to provide insight into which peers or routes are consuming memory, making it both risky and uninformative.

Configure a prefix limit on all BGP peers.

Why it fails: Configuring a prefix limit on all BGP peers is a preventive policy control that restricts the number of routes accepted per peer, but it does not reveal current memory usage or the characteristics of already-learned routes. While it can mitigate future route influx, it is not a diagnostic command and may drop legitimate routes if thresholds are set incorrectly. For immediate diagnosis of memory exhaustion without disrupting traffic, this option is a management action rather than a troubleshooting step.

Use the 'show route summary' command to check the routing table size and memory usage.

Why it fails: The 'show route summary' command displays aggregate route counts per protocol and the memory consumed by the routing table, enabling you to quickly confirm whether the routing table is oversized. This non-disruptive command helps identify which protocol (e.g., BGP) is contributing the most prefixes and whether memory exhaustion is indeed caused by route volume. It also provides a baseline for further investigation, such as using 'show route protocol bgp' or 'show route prefix-length' to pinpoint specific problem routes, without affecting active traffic.

show interfaces terse

Why it fails: The 'show interfaces terse' command provides a concise summary of all interfaces on the device, including their admin/operational status and any assigned IP addresses. It is a general interface visibility tool and contains no information about firewall filter configuration, packet counters, or the log entries that would reveal why traffic is being dropped by a filter. Therefore, it cannot be used to identify which filter term is denying traffic and preventing forwarding.

show firewall filter counter

Why it fails: The 'show firewall filter counter' command displays only the aggregate packet and byte counts for filter terms that have a 'count' action configured. It does not show per-packet log entries that include timestamps, source/destination IP addresses, or port information, so it cannot tell the engineer which specific packets are being dropped or why the drop is occurring. It only indicates that a counter is incrementing, not the forwarding details needed for a diagnosis.

show firewall filter log

Why it fails: The 'show firewall filter log' command is the operational command that displays the logs of packets that matched filter terms configured with either 'log' or 'syslog' actions. Each log entry includes the timestamp, interface, source and destination IP addresses and ports, protocol, and the action taken (permit or deny), giving the engineer direct visibility into which packets were dropped by the filter. This is the correct command to identify why a Junos device is not forwarding traffic due to firewall filter drops.

You can run multiple commit scripts during a single commit operation.

Why it fails: Only one commit script can be active at a time.

The rollback command reverts to the current active configuration.

Why it fails: Rollback reverts to a previously committed configuration, not the current one.

Both routes have a preference of 0.

Why it fails: The default preference of a static route in Junos is 5, not 0. In the exhibit, the [Static/5] notation explicitly shows that both routes carry a preference value of 5. A preference of 0 is reserved for directly connected interfaces (and certain special routes), so it would never appear for a configured static route unless explicitly set to 0, which is not the case here. Therefore, stating both routes have a preference of 0 misreads the [Static/5] tag.

Only the 10.0.1.0/24 route is active.

Why it fails: Both routes in the exhibit are marked with the '*' next-hop flag, which is Junos' way of indicating that a route is active and selected for forwarding. The 10.0.1.0/24 route is active, but so is the 10.0.2.0/24 route; the asterisk appears on both entries. A route could become inactive if its next hop becomes unreachable, but nothing in the exhibit suggests that either next hop is down. Choosing only 10.0.1.0/24 ignores the matching asterisk on the second route.

Both routes use the same next-hop IP address.

Why it fails: The exhibit shows two different next-hop IP addresses: 192.168.1.1 for the 10.0.1.0/24 route and 192.168.1.2 for the 10.0.2.0/24 route. In Junos, a static route's next hop is configured individually, and there is no requirement that multiple static routes point to the same gateway. The routing table output lists each route with its own next hop, and the two values are visibly different. Thus, the claim that both routes use the same next-hop IP address contradicts the output.

show configuration interfaces

Why it fails: Incorrect. 'show configuration interfaces' displays the configuration, not operational status.

show interfaces terse

Why it fails: Incorrect. 'show interfaces terse' provides a summary but does not include error counters.

show interface descriptions

Why it fails: Incorrect. 'show interface descriptions' shows only interface descriptions, not operational status or error counters.

0

Why it fails: 0 is incorrect because the route 192.168.1.0/24 has next hops configured.

3

Why it fails: 3 is incorrect because there are only two next-hop addresses, not three. Candidates may mistakenly count lines or include a local interface.

1

Why it fails: 1 is incorrect because there are two next hops, one via 10.0.0.2 and another via 10.0.0.3, not just one.

Set the class, commit the configuration, then set the authentication method to plain-text-password.

Why it fails: This is incorrect because committing before setting authentication leaves the user without a password, making it impossible to log in.

Set the authentication method to plain-text-password, commit the configuration, then set the class.

Why it fails: This is incorrect because committing before setting the class results in an incomplete user configuration; the user would not have a privilege level.

/altroot: Contains software packages

Why it fails: This is incorrect because /altroot is not a storage location for software packages; instead, it is an alternate root filesystem used for backup and recovery. If the primary root becomes corrupted, /altroot provides a minimal boot environment to recover the system. Installed Junos software packages are actually mounted under /packages, which contains the individual package directories for the OS components.

/packages: Backup root filesystem

Why it fails: This is incorrect because /packages is not a backup root; it is the mount point for the installed Junos software packages. The /packages directory contains subdirectories for each installed package, such as the kernel and base OS components, which are loaded as part of the boot process. The backup root filesystem is /altroot, a separate recovery environment used if the primary root fails.

show chassis hardware

Why it fails: The 'show chassis hardware' command is designed to inventory physical components such as the Routing Engine, PICs, power supplies, and their serial numbers and revision levels. It does not display the logical system hostname because the hostname is a configuration property, not a hardware attribute. While some hardware outputs may include a device name in a banner or header, that is incidental and not a reliable or intended method for hostname lookups, making this option incorrect for the task.

show configuration system host-name

Why it fails: The 'show configuration system host-name' command is valid only in configuration mode and displays the hostname as defined in the candidate or committed configuration, not necessarily the active operational hostname if an uncommitted change exists. It requires configuration-mode authority, which is a higher privilege level than what is needed for the simple operational command 'show system host-name'. The question asks for a command to display the current hostname, and this option, while related, is not the direct operational-mode command that answers the requirement.

show system uptime

Why it fails: The 'show system uptime' command reports the system's current time, uptime duration, number of users logged in, and load averages. It focuses on system availability and performance metrics, and its output contains no hostname information whatsoever. The hostname is a discrete identifier that is not bundled into uptime or load statistics, so this command cannot satisfy the request to display the device's hostname.

set system login user admin class operator

Why it fails: Assigning the operator class to the admin user grants read-write privileges, not read-only access. Within Junos, the operator class allows the user to edit and commit configuration changes, along with executing operational commands such as show and ping. Because the administrator requires read-only access, this configuration would exceed the requested permission level and is therefore incorrect.

set system login user readonly class super-user

Why it fails: The super-user class provides unrestricted administrative access to the entire Junos system, including configuration changes, user management, and the Unix shell. Granting this class to the readonly user would provide far more than read-only access, creating a significant security risk. Since the requirement is strictly read-only, this option must be rejected.

set system login user guest class operator

Why it fails: Although the username 'guest' suggests a limited account, the assigned class determines the actual privilege level. The operator class provides read-write access, allowing the user to modify and commit configuration changes, which is inappropriate for a read-only requirement. This configuration would give the guest account more access than intended, making it an invalid choice.

1

Why it fails: The answer 1 is incorrect because a single commit would appear in `show system commit` output as only one entry, typically with ID 0. However, the exhibit shows multiple entries, with IDs 0, 1, and 2 present, indicating that more than one commit has been made. Counting only the most recent commit or misreading the list's first line ignores the full history recorded in the output.

2

Why it fails: The answer 2 is a common mistake caused by reading the highest commit ID (2) as the total number of commits. However, Junos commit IDs are zero-based, meaning the first commit is ID 0, the second is ID 1, and the third is ID 2. Since the exhibit shows three entries with IDs 0, 1, and 2, the total number of commits is three, not two.

0

Why it fails: The answer 0 is incorrect because the exhibit clearly shows a non-empty commit history. A zero-commit state would produce no entries in `show system commit` or display a message indicating no commits exist. The presence of commit ID 0 might be misinterpreted as 'no commits,' but in Junos, ID 0 is simply the label for the most recent commit, and it still counts as one commit in the history.

The forwarding engine is initialized before the kernel.

Why it fails: Incorrect: The forwarding engine is initialized after the kernel, not before.

The configuration is loaded from /config before the kernel starts.

Why it fails: Incorrect: The configuration is loaded after the kernel starts, not before.

The kernel mounts the root file system.

Why it fails: Incorrect: The kernel accesses the root file system directly without mounting it; mounting occurs later for other filesystems.

show system time

Why it fails: This is not a valid Junos command; 'show system uptime' is used for time and date.

show system inventory

Why it fails: Incorrect; this displays hardware inventory, not time or date.

show system processes

Why it fails: Incorrect; this displays process information, not time or date.

show arp routing-instance <instance-name>

Why it fails: On Junos, the correct operational command to view ARP entries for a specific routing instance is 'show arp instance <instance-name>'. The keyword 'routing-instance' is not valid after 'show arp'; in fact, 'show arp' uses the 'instance' keyword to select a routing instance. Attempting 'show arp routing-instance' results in a syntax error or unknown command. Additionally, even if the CLI accepted it, the command would not be recognized by the management daemon.

show arp

Why it fails: Without any qualification, 'show arp' displays ARP entries only from the default routing instance (inet.0). In a multi-instance environment, ARP entries for other routing instances are hidden, which can mislead troubleshooting if you expect to see all interfaces. To see a specific non-default instance, you must add the 'instance <instance-name>' clause. This is a common pitfall for engineers migrating from other platforms where a single ARP table is global.

show route table <instance-name>.inet.0

Why it fails: This command is for inspecting the IP routing table (route entries) of a routing instance, specifically the inet.0 address family table. It does not display ARP entries and therefore cannot satisfy the requirement of checking ARP neighbor resolutions. While a route might be present, you would still need to look at the ARP table (or 'show arp instance') to see the MAC address mapping. Moreover, the command requires the instance name plus the table suffix (e.g., .inet.0), which is not the issue here; the issue is it's the wrong operational table.

The commit command is used to discard changes.

Why it fails: The `commit` command does not discard changes; it activates the candidate configuration by copying it to the active configuration and creating a numbered rollback snapshot. Discarding changes is done with `rollback 0` followed by `commit` or by exiting without committing, not by `commit`. Thus the statement misidentifies the commit operation, which is the moment changes become live.

A commit validation is performed automatically before commit.

Why it fails: Junos does not automatically invoke the separate `commit check` validation before every `commit`; that command is a manual step you run only when you want to test the candidate for errors without activating it. While a `commit` will fail if it encounters syntactic or semantic errors, that check is part of the commit process itself, not an additional automatic pre-validation pass. Therefore, saying a commit validation is performed automatically before commit mischaracterises the workflow.

Multiple candidates can be active simultaneously.

Why it fails: The standard Junos configuration model maintains a single candidate configuration, not multiple active candidates; all concurrent users edit the same candidate unless they explicitly use `configure private` to create a private workspace. Even with a private candidate, only one candidate can be committed at a time, and the device still maintains one active configuration. Thus, multiple candidate configurations cannot be active simultaneously in the normal commit model.

Remove the previous image.

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