Select Two (Multi-Select) Questions

BGP routes

Why it fails: 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 it fails: 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 `commit confirmed` command saves the configuration permanently.

Why it fails: The `commit confirmed` command does not save the configuration permanently. Instead, it performs a temporary commit that remains active for a default timeout of 10 minutes, after which Junos automatically reverts to the previous configuration unless the commit is explicitly confirmed with a standard `commit` command. This mechanism is designed for safe remote changes, ensuring that if connectivity or validation fails, the device returns to a known-good state.

The `set cli screen-length 0` command disables command-line editing features.

Why it fails: The `set cli screen-length 0` command does not disable command-line editing features; it disables paging or pagination of output. Setting screen-length to 0 means the terminal will not pause after each screenful of output, allowing the full output to scroll continuously. Command-line editing features, such as keyboard shortcuts, history navigation, and emacs/vim editing modes, are controlled separately via `set cli` options like `set cli editing-mode` or the terminal's line-editing behavior.

The `rollback 0` command reverts to the previous committed configuration.

Why it fails: The `rollback 0` command does not revert to the previous committed configuration; it loads the current active committed configuration into the candidate configuration. The rollback number refers to an index of previous configurations in the rollback buffer, with `rollback 0` being the most recent committed configuration, `rollback 1` being the one before that, and so on. To revert to an earlier state, you would use `rollback 1`, `rollback 2`, etc., depending on how far back you need to go.

show log

Why it fails: 'show log' is wrong because it outputs syslog-style messages written by system processes, not a direct query of current interface operational state. Log messages may be delayed, filtered by severity, or even absent for an interface issue if no event triggered a log entry. While logs can help diagnose past link flaps or errors, they cannot reliably report the real-time admin/operational status of an interface, so they are supplementary diagnostics, not an operational state viewer.

show configuration interfaces

Why it fails: 'show configuration interfaces' is wrong because it displays the configured interface hierarchy from the configuration database, including logical units, IP addresses, and settings such as 'disable'. That represents the administrator's intended state after a commit, not the current runtime state; an interface can be configured up with valid addressing yet still be operationally down due to a missing cable, no carrier, or hardware failure. Since it cannot report live link state or interface counters, it does not fulfill the requirement to view current operation.

show route

Why it fails: 'show route' is wrong because it displays the routing table, which lists active routes, protocol preferences, next-hop addresses, and route flags. Although a route learned through an interface can be an indirect clue that the interface is functioning, the command does not directly report the interface's link state, speed, errors, or protocol status. Routes might be stale, aggregated, or reachable through indirect next hops, so this command is not designed to answer 'what is the current operation of this interface?'

show route protocol static

Why it fails: The command 'show route protocol static' filters the routing table to display only routes that were learned through the static routing protocol, as identified by the protocol field for each route entry. It omits other IPv4 unicast routes, such as direct, OSPF, or BGP routes, so it is too narrow to show the current routing table in its entirety. While useful for verifying static route installation, it does not fulfill the requirement of viewing all IPv4 unicast routes.

show forwarding-table

Why it fails: The command 'show forwarding-table' displays the forwarding table (FIB), not the routing table (RIB). The forwarding table is derived from the routing table and contains only the routes that are active and selected for actual packet forwarding, along with next-hop and interface information optimized for the forwarding engine. It does not show all routes present in the routing table, such as inactive or backup paths, so it is not a valid way to view the current routing table itself.

show route table inet6.0

Why it fails: The command 'show route table inet6.0' explicitly selects the IPv6 unicast routing table, which is used for IPv6 routes only. Since the question asks about the current routing table (implied to be IPv4 unicast, as inet.0 is the default), this command would display a different address-family's routes and would not show IPv4 information. To view IPv4 routes, one must specify inet.0 or use the default 'show route'.

show ip route

Why it fails: The command 'show ip route' is Cisco IOS syntax and is not a valid operational command in Junos. Junos uses 'show route' as the base command for displaying routing information, and a network administrator familiar with Cisco will need to adapt to this syntax. In Junos, the IPv4 unicast routing table is displayed with 'show route' or 'show route table inet.0', not 'show ip route'.

show route protocol ospf

Why it fails: The command 'show route protocol ospf' displays only the routes that were learned through the OSPF protocol, filtering out direct, static, and other protocol routes. It does not provide a complete view of the IPv4 unicast routing table, as it intentionally narrows the output to a specific protocol. Since the question asks for the entire IPv4 unicast routing table, this command is incorrect for that purpose.

show routing

Why it fails: There is no Junos operational command called 'show routing'; the correct command for displaying routing table information is 'show route'. The Junos CLI is very particular about command naming, and typing 'show routing' will result in a syntax error or an unknown command message. Therefore, this option is not a valid way to display the IPv4 unicast routing table.

It validates the replacement configuration for correctness before applying.

Why it fails: The replace pattern command does not perform any syntactic or semantic validation on the edited configuration text. It blindly substitutes the matching pattern with the replacement string, even if the result creates duplicate statements or references nonexistent interfaces. Validation only occurs when you explicitly run 'commit check' or 'commit' later, and those operations will fail if the configuration is invalid.

It automatically commits the changes after replacement.

Why it fails: After replacing text patterns, the command leaves the changes in the candidate configuration but does not trigger a commit. The running configuration remains unchanged until you issue a separate 'commit' statement; if you exit configuration mode without committing, the changes are not applied. This manual commit requirement is consistent with all Junos configuration editing commands.

show log

Why it fails: show log displays messages that have already been written to the system's log files, such as interface transitions, login successes, or routing protocol events. It is a historical snapshot of past activity, not a live feed; to follow a log in real time, you would use monitor start or monitor traffic for interface data. Therefore, it cannot satisfy the requirement for real-time interface display.

request system reboot

Why it fails: request system reboot is a system control command that shuts down and restarts the Junos device, causing all interfaces to go down and then recover during the reboot process. It does not display any interface information; its purpose is to perform a disruptive maintenance action, not to provide real-time monitoring. Consequently, it is completely unrelated to the operational need described in the question.

show system storage

Why it fails: show system storage reports on disk space utilization, file system mount points, and available flash capacity, which are critical for system health but independent of interface operation. It provides no data about interface status, traffic rates, or packet flow, and the output is a static point-in-time measurement rather than a real-time stream. Thus, it does not fulfill the command requirement for displaying real-time interface information.

Commit configuration changes

Why it fails: In Junos, the commit command is valid only from configuration mode, accessed via the 'configure' command at the CLI. It applies the candidate configuration to the active configuration after validation. Operational mode lacks commit because it is designed for monitoring and operational actions, not for altering configuration state.

Configure interface IP addresses

Why it fails: Assigning IP addresses to interfaces requires entering configuration mode and editing the 'interfaces' hierarchy, for example with 'set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.1/24'. Operational mode only offers read-only visibility of interface settings, such as 'show interfaces terse' or 'show configuration interfaces'. The CLI deliberately separates these modes so that configuration changes are validated and committed atomically, preventing accidental live changes.

The rescue configuration is automatically saved after every commit.

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

A maximum of 10 groups can be applied to a single configuration statement.

Why it fails: Junos imposes no fixed limit of 10 groups per configuration statement; the number of usable groups scales with platform memory and CPU resources. In practice, you can apply many groups, though an excessive number may impact commit performance and readability. The 'maximum of 10' misconception likely stems from examples and training materials that happen to illustrate a small set of groups.

Configuration groups do not allow individual statements within the group to be overridden in the main configuration.

Why it fails: The main configuration can override individual statements inherited from a group; this override behavior is fundamental to how groups work. Junos uses a precedence scheme where more specific configuration levels take priority over less specific ones, and within the same level, the main configuration beats group values. Additionally, if multiple groups are applied, the first group in the apply-groups list wins over later groups for conflicting statements.

They allow users to enter only operational mode.

Why it fails: Login classes define permissions that determine whether a user can access operational mode, configuration mode, or both. The default login class, 'super-user', permits both operational and configuration commands, while a custom class can be configured with a permission set that includes or excludes the 'configure' permission. Therefore, a login class does not inherently restrict a user to operational mode only; it is the specific permissions within the class that control mode access, and many classes allow both modes depending on their configuration.

They are automatically assigned to all users by default.

Why it fails: Login classes are not automatically assigned to all users; they must be explicitly associated with a user account. In Junos OS, a user is created under the [edit system login user] hierarchy, and the 'class' statement is required to specify which login class the user belongs to. Without this explicit assignment, the user account is not fully configured and cannot be used for login, so there is no implicit default class applied universally to all users.

They cannot be modified after creation.

Why it fails: Login classes are fully modifiable after they are created. An administrator can use the 'set' or 'edit' commands in configuration mode to change a class's permissions, add or remove allowed commands, or alter its description. For instance, 'set system login class myclass permissions configure' adds the ability to enter configuration mode to an existing class, and the change takes effect immediately for future logins, so the idea that they are immutable is incorrect.

All configuration is stored in a flat file with line numbers

Why it fails: The Junos OS configuration is structured as a hierarchy, not a flat file. After a commit, the active configuration is written to a single file named juniper.conf.gz on the device, which is compressed but not line-numbered or flat. The hierarchy is represented by indentation and statement levels, not line numbers.

The hierarchy is stored in multiple configuration files that are merged at boot

Why it fails: Junos maintains the active configuration in a single file (juniper.conf.gz) after each commit. While multiple files exist for rollback and rescue configurations, these are not merged at boot. The device loads the designated active configuration file, and the candidate config is held in memory and committed to that same single file.

Configuration values are inherited from the root level automatically

Why it fails: Inheritance in Junos is not automatic from the root. Instead, you explicitly use configuration groups with apply-groups statements to apply a set of configurations to multiple places. Specific inheritance exists like from physical interfaces to logical units, but not from the root level universally.

System uptime

Why it fails: System uptime is a counter that tracks how long the routing engine has been running; it is a candidate metric in BGP route selection (preferring older routes) but does not, by itself, cause the routing table to be rebuilt or updated. Routing table changes are driven by topology events, protocol messages, or explicit administrative actions, not by the passage of time or system restarts.

Log file rotation

Why it fails: Log file rotation is a housekeeping task performed by the system to archive or truncate log files (e.g., /var/log/messages). It has no connection to the routing protocol daemon (rpd) or the routing table because it neither alters interface states, receives routing updates, nor modifies active configuration that affects network reachability.

Configuration commit

Why it fails: A configuration commit only activates the candidate configuration into the active configuration. Unless that configuration change directly alters an interface address, enables or disables a routing protocol, or adds/removes a static route, committing it does not itself modify the existing routing table; the table changes only when the underlying protocol or interface state actually changes.

The preference of a route cannot be changed.

Why it fails: In Junos, route preference is not fixed; it can be modified through routing policy by using the 'preference' statement to override the default value for matched routes. This mechanism allows network administrators to influence path selection, for example, making a BGP route preferred over an OSPF route. Therefore, the claim that preference cannot be changed is incorrect.

Static routes have a default preference of 10.

Why it fails: Static routes in Junos actually have a default preference of 5, making them more preferred than OSPF's 10 and BGP's 170, but less preferred than direct routes at 0. A preference of 10 is the default for OSPF internal routes, so attributing it to static routes is a common misconception. The default preference can be overridden with routing policy, but the out-of-box value for static is 5.

BGP routes have a default preference of 200.

Why it fails: BGP routes in Junos are assigned a default preference of 170, not 200, and this value is used for both internal and external BGP routes unless overridden by policy. A preference of 200 does not represent any standard Junos route type, so this statement is incorrect. Adjusting BGP's preference via routing policy is a common way to manipulate route selection.

show interfaces terse

Why it fails: 'show interfaces terse' gives a one-line static summary per interface, not continuously refreshed real-time statistics or error counters. It is tempting because it does display interface state and counters, but real-time monitoring requires the 'monitor interface' command, which refreshes output at intervals.

show interfaces ge-0/0/0

Why it fails: 'show interfaces ge-0/0/0' returns a single static snapshot of one interface's counters, not continuously refreshed real-time statistics. It is tempting because it does display error counters for that interface, but real-time monitoring requires 'monitor interface ge-0/0/0', which updates the display at set intervals.

monitor security log

Why it fails: 'monitor security log' streams security log entries, not interface statistics or error counters. It is tempting because 'monitor' commands do provide real-time streaming output, but this one targets security events; interface monitoring uses 'monitor interface', which refreshes counters continuously.

Archival stores the candidate configuration.

Why it fails: Archival stores the committed (active) configuration, not the candidate.

Archival only saves the rescue configuration.

Why it fails: Archival saves the active configuration, not specifically the rescue config.

Archival automatically archives after every commit without any configuration.

Why it fails: Archival must be explicitly configured; it is not automatic.

A static route with a next-hop of an interface will be active even if the interface is down.

Why it fails: A static route with a next-hop of an interface (e.g., a directly connected interface) remains active only while that interface is operationally up and has at least one configured IPv4/IPv6 address. If the interface is administratively or physically down, Junos removes the route from the routing table and it cannot be used for packet forwarding. Thus the statement that it would be active even when the interface is down is incorrect.

A static route with a preference of 10 is preferred over a static route with a preference of 5.

Why it fails: Junos uses the route preference (also called administrative distance) to select the best route; a lower preference value indicates a more preferred route. A static route with a preference of 5 is preferred over one with a preference of 10 because 5 is numerically lower. Therefore, the statement claiming a preference of 10 is preferred is backwards and would cause routing decisions to be made incorrectly if followed.

Static routes cannot be used for load balancing.

Why it fails: Static routes absolutely can be used for load balancing in Junos by configuring multiple equal-cost next-hops under the same static route (e.g., via the 'qualified-next-hop' with equal preferences or by listing multiple next-hops). These paths are installed in the forwarding table, and traffic is distributed among them using per-flow or per-packet load balancing. The claim that static routes cannot be used for load balancing is false because Junos supports static route load sharing when the next-hops have equal preference and are reachable.

set routing-options static route 10.0.0.0/8 reject-all

Why it fails: The keyword `reject-all` is not a recognized static route next-hop action in Junos; the correct term is `reject`, which drops packets and sends an ICMP unreachable back to the source. Configuring `reject-all` would result in a syntax error because Junos expects either `discard`, `reject`, or an actual next-hop address. This option is invalid because it uses a nonexistent keyword rather than the actual Junos CLI token.

set routing-options static route 10.0.0.0/8 next-hop 192.168.1.1 metric 10

Why it fails: Junos static routes do not use a `metric` option to influence route selection; instead, the correct parameter is `preference`, which sets the administrative distance. The statement attempts to use `metric`, which is not recognized for static routes (unlike protocols like RIP or OSPF), so Junos would reject the configuration. Since `metric` is not a valid static route attribute, this option is invalid.

set routing-options static route 10.0.0.0/8 passive

Why it fails: The keyword `passive` is not a valid configuration option for static routes in Junos; it is used in dynamic routing protocols such as OSPF or IS-IS to suppress hello messages on an interface. Static routes have no concept of being 'passive'—they are manually defined and do not participate in neighbor discovery. Attempting to apply `passive` in this context would produce an error, making the statement invalid.

Next-hop reachability

Why it fails: Next-hop reachability is a prerequisite for a route to be considered active in the routing table, but it is not a factor in comparing route preference. If a route's next hop is unreachable, the route is removed from consideration entirely, regardless of how low its preference or metric might be. The comparison of preference and metric only happens among routes whose next hops are already reachable and valid. Thus, reachability filters routes, it does not rank competing routes.

Number of hops

Why it fails: Hop count is a protocol-specific metric—for example, RIP uses hop count as its metric—but it is not directly used as an independent factor in route preference comparison. In Junos, route preference (administrative distance) is evaluated first, and only after that is a metric like hop count compared between routes from the same protocol. Even when a protocol advertises hop count, it is just one kind of cost value, not a separate comparison parameter. So hop count never appears as a standalone input in the route preference decision.

Prefix length

Why it fails: Prefix length is not a factor in route preference comparison at all; it is used by the forwarding table for longest-prefix-match route lookup. A more specific (longer) prefix will be chosen for a destination regardless of the preference or metric of a less specific route. This means that even a route with a very high preference can win if it has a longer prefix length, because the comparison happens during destination lookup, not during route preference evaluation. Therefore, prefix length is orthogonal to route preference.

The rollback 0 command will cause a system reboot.

Why it fails: The rollback 0 command resets the candidate configuration to the currently active configuration, effectively discarding any uncommitted changes. It is purely a configuration-level operation that replaces the contents of the candidate; it does not restart the device or the management processes. A system reboot would require a separate command such as request system reboot, which is unrelated to configuration rollback. Therefore, this statement is false.

The commit check command applies the configuration to the running system.

Why it fails: The commit check command validates the candidate configuration for syntax correctness and proper Junos policy checks without activating it. It is essentially a dry run that reports errors but leaves the running configuration untouched. Only an explicit commit will apply the changes to the active configuration, so claiming that commit check applies changes is incorrect.

The commit at command is used to schedule a system reboot.

Why it fails: The commit at command schedules a commit operation to occur at a specified future time, allowing the candidate configuration to be activated later. It does not schedule a reboot; system reboots are performed with the request system reboot command, which is a separate operational action. Therefore, using commit at to schedule a reboot is a clear misconception.