Operational Monitoring and Maintenance practice questions

The interface is administratively down

Why it fails: An administratively down interface is a Layer 2/3 state that is independent of the BGP configuration. When an interface is disabled with 'set interfaces ge-0/0/0 disable' or the equivalent, the interface will be shown as 'Administratively down' in 'show interfaces', and all protocols on that interface will fail, not just BGP. BGP's inability to establish a session would be a secondary symptom; the interface state provides the clearest evidence of the cause. Additionally, if BGP had a configured group, the session state would be Active (attempting to connect) rather than Idle, because the peer address exists.

The router has a full BGP table

Why it fails: A full BGP table—referring to the ~750,000 Internet routes a default router receives—affects memory and CPU, but it does not interfere with the BGP state machine. The establishment of a BGP session occurs over TCP port 179 and only requires the configured peers to complete the OPEN, KEEPALIVE, and UPDATE exchanges. Even with a full table, two BGP peers can establish a session; the router may be slow to process updates, but the session will come up. BGP session establishment does not depend on the number of routes in the RIB.

The firewall filter is blocking ICMP

Why it fails: BGP relies on TCP port 179 for all peer communication, including session establishment, route exchanges, and keepalive messages. ICMP is neither required nor used for BGP session setup; while 'ping' is often used as a connectivity test, it is not a prerequisite for BGP to establish. A firewall filter blocking ICMP would prevent ping-based troubleshooting but would not affect the BGP TCP connection unless port 179 is also blocked. Therefore, ICMP filtering is an unrelated symptom, not the root cause of BGP sessions not being established.

It includes only layer 1 information

Why it fails: This statement is false because 'show interfaces extensive' aggregates information from multiple layers of the OSI model. While it does include Layer 1 physical properties like link state and media type, it also reports Layer 2 statistics such as MAC packet counts and VLAN membership, and Layer 3 details like configured IP addresses and MTU size. Therefore, the output is a multi-layer snapshot rather than being limited to Layer 1 alone.

It shows the interface configuration

Why it fails: This is incorrect because 'show interfaces extensive' displays operational runtime data, such as link status, protocol state, and live counters, not the configured settings of the interface. The configuration is stored in a separate configuration database and can be viewed with 'show configuration interfaces' or 'edit' mode. The operational output may differ from the configuration if the daemon has not fully applied settings or if the interface is in a failed state.

show interfaces terse

Why it fails: The show interfaces terse command does not provide routing protocol monitoring; it merely displays a summary of all configured interfaces with their administrative and link status. While it can indicate whether a physical or logical interface is Up, it cannot show whether a routing protocol neighbor is established or any protocol-specific state. Therefore, it is not useful for operational monitoring of OSPF, IS-IS, or BGP adjacencies.

show arp

Why it fails: The show arp command is irrelevant to routing protocol monitoring because it displays the Address Resolution Protocol cache, which maps IP addresses to physical MAC addresses on a local network. It has no visibility into the state of IS-IS, OSPF, or BGP adjacencies, nor does it show routing protocol sessions. Its purpose is purely for layer-2 connectivity verification, not for operational status of dynamic routing protocols.

It shows a static snapshot

Why it fails: A static snapshot would show one instant of data and never change until you re-issue the command, but monitor interface repaints the entire screen with current values on every refresh cycle. Because counters increment and rates are recalculated continuously, the output is inherently dynamic and cannot be a static snapshot.

It requires a 'start' parameter

Why it fails: The command syntax is simply 'monitor interface <interface-name>' and monitoring begins immediately upon execution. There is no 'start' parameter to trigger the process; the Junos CLI starts the real-time display as soon as the command is entered, so any statement requiring a 'start' parameter is incorrect.

It provides historical statistics

Why it fails: This command shows only the current values and rates computed since the interface counters were last cleared or since the monitoring session began. It does not retrieve historical statistics such as past utilization trends or archived counter snapshots; historical data would have to be collected separately through SNMP polling, logging, or a management system.

On RE0: request system software add jinstall-20.2R2.tgz reboot; then on RE1 same command

Why it fails: Upgrades primary first, causing longer downtime.

On RE0: request system reboot (without adding software)

Why it fails: Reboots without upgrading.

On both REs: request system software add jinstall-20.2R2.tgz reboot

Why it fails: Both reboot simultaneously, causing traffic loss.

It compresses the backup to save space.

Why it fails: Snapshots in Junos do not perform any form of compression. The operation copies the root filesystem's contents verbatim to the destination media, preserving the exact files, permissions, and structure needed to make the media bootable. Compressing the image would prevent the media from being used as a direct boot device, since the device would need a separate unpacking step before booting. Therefore, the size of the snapshot equals the installed software and configuration, not a compressed archive.

It copies the active partition to the alternate partition on the same media.

Why it fails: This option incorrectly describes the behavior of 'request system partition' or 'request system software add' operations. A snapshot does not copy partitions to another partition on the same physical disk; instead, it duplicates the entire system to a completely separate, bootable medium. The internal partitioning commands are used for software installation or partitioning the internal storage, not for creating recovery media. Misunderstanding this distinction can lead you to expect a snapshot to work during a primary disk failure when it actually requires a different destination.

IS-IS

Why it fails: In the exhibit, the interface configuration contains no IS-IS adjacency configuration. IS-IS would appear under 'protocols isis' with an 'interface' statement, not as a protocol family like 'family mpls'. Unless the interface is explicitly listed in the IS-IS configuration, the protocol is not enabled there. Since no such configuration is shown, IS-IS is not enabled on this interface.

BGP

Why it fails: BGP is not a Layer 2 or Layer 3 protocol family that you enable on an interface in Junos; it is a TCP-based protocol whose sessions are configured at the [edit protocols bgp] hierarchy level. The exhibit only displays per-interface family settings, and BGP does not appear as one of those families. Therefore BGP cannot be the protocol enabled on this interface; it would require an IP address family like 'inet' for its underlying TCP transport, not a dedicated BGP family.

OSPF

Why it fails: OSPF is a routing protocol that is enabled by referencing an interface in a protocol stanza, not by setting a protocol family directly in the interface hierarchy. In Junos, OSPF adjacency parameters are configured under 'protocols ospf area', and the interface is merely listed there; no 'family ospf' exists in the interface unit. The exhibit does not show such an OSPF area or interface statement, so OSPF is not enabled on this interface; the only protocol family present is MPLS.

On both REs: request system software add <image>; then request system reboot both REs simultaneously.

Why it fails: Issuing the add and reboot commands on both REs at the same time removes chassis redundancy during the upgrade window. Both control planes go offline concurrently, which drops routing, management, and any services that rely on the Routing Engine. The whole point of a dual-RE system is to keep one RE available while the other is upgraded, so this approach guarantees an outage and is never acceptable.

On RE0: request system software add <image> re0; on RE1: request system software add <image> re1; then request system reboot both.

Why it fails: This sequence stages the new image on both REs but then reboots them together, without first making the backup active. Because the primary is still running when both REs restart, the system loses its active control plane at the same time as the backup. A clean NSSU-style upgrade requires upgrading and rebooting the backup, switching mastership, and only then rebooting the old primary. Skipping the switchover means the new software on the old primary is never properly validated before it is used.

On RE0 (primary): request system software add <image> re0; request system reboot re0. After reboot, on RE1: request system software add <image> re1; request system reboot re1.

Why it fails: Upgrading RE0 (primary) first and rebooting it leaves the backup RE1 running the old version as the only control plane, and the primary reboot triggers a switchover before the new image has been verified. More importantly, the primary is rebooted while it is still the active Routing Engine; even if RE1 takes over, the disruption is unnecessarily large because the proper procedure dictates that the backup be upgraded and rebooted first. The accepted approach is to make the backup the mastership target, not to force the primary down while it is still active.

It captures packets from the Routing Engine only.

Why it fails: This statement is incorrect because 'monitor traffic' captures packets on the specified network data path interface, not exclusively from or to the Routing Engine. While the command is executed from the RE, it sees all traffic that crosses the selected interface, including forwarding-plane traffic that never reaches the RE. To capture only RE-specific control-plane traffic, you would need a different mechanism, such as 'monitor traffic interface lo0' or traceoptions on specific protocols, but the default behavior covers both planes on the chosen interface.

It requires a reboot to start capturing packets.

Why it fails: This statement is incorrect because 'monitor traffic' is a CLI-based operational command that starts capturing packets immediately after invocation, without any need to reboot the device. A reboot would actually terminate the monitoring session and is completely unnecessary for initiating packet capture. The command runs in the foreground and can be stopped with Ctrl+C, making it a lightweight, on-demand diagnostic tool.

Remove and reinsert the PIC on FPC0 to reseat the connection.

Why it fails: Re-seating a PIC only remakes the mechanical/electrical connection between the PIC and the FPC midplane. The PFE is an integral hardware component of the FPC itself, containing the forwarding ASICs and memory, so a PIC reseat cannot affect the PFE's state. The reported repeated PFE interrupts indicate a failure on the FPC's own forwarding hardware, not a loose interface card.

Restart the PFE process using 'restart pfe' command.

Why it fails: The 'restart pfe' command would only restart the forwarding process flow, but the FPC has already automatically restarted and flapped itself offline due to repeated PFE hardware faults. A software-level restart cannot heal physical degradation such as ECC memory errors or ASIC overheating on the line card. After a manual restart, the same failing interrupt pattern would reoccur, so this is at best a temporary and ineffective measure.

Perform a software upgrade on the router to fix a known bug.

Why it fails: Upgrading Junos is only appropriate when the PFE interrupt pattern matches a known, fixed software bug, and the FPC recovers after the upgrade. Here, the error repeats continuously on FPC0, persists through reboots, and is accompanied by actual traffic loss, all of which point to failing silicon rather than a bug. A software upgrade will not replace damaged hardware or alter the mechanical/electrical behavior of the faulty line card.

Step 1: Configure the OSPF area and assign interfaces. Step 2: Configure the router ID. Step 3: Verify OSPF neighbor relationships.

Why it fails: This is incorrect because OSPF may use an automatically derived router ID if not set, but it is best practice to set the router ID before assigning interfaces to avoid instability or mismatched router IDs.

Step 1: Verify OSPF neighbor relationships. Step 2: Configure the router ID. Step 3: Configure the OSPF area and assign interfaces.

Why it fails: Attempting to verify OSPF neighbors before configuring the router ID and assigning interfaces to areas is logically impossible: OSPF has not been enabled on any interface, so no HELLO packets are sent and the OSPF neighbor table is empty. The 'show ospf neighbor' command would return no output, not a failure state, because the OSPF process has no active interface to establish adjacencies with. Router ID and area/interface configuration are prerequisites for the OSPF protocol to operate, so verification must always come last.

Step 1: Configure the router ID. Step 2: Verify OSPF neighbor relationships. Step 3: Configure the OSPF area and assign interfaces.

Why it fails: Though setting the router ID first is a good practice, inserting verification as step 2 is premature because OSPF adjacencies cannot form unless at least one interface is explicitly assigned to an OSPF area. Without an area-to-interface association, OSPF does not actively send HELLOs on any link, so the router has no neighbors to report even after a router ID is configured. Verification of neighbor relationships is only meaningful after interfaces are bound to areas and DR/BDR or point-to-point transitions have had time to complete.

Step 1: Configure a DHCP pool with subnet and range. Step 2: Enable DHCP services. Step 3: Set DHCP options. Step 4: Exclude specific addresses.

Why it fails: This sequence is invalid because you cannot configure a DHCP pool before the DHCP service is enabled. In Junos, all pool definitions live under the [edit system services dhcp] hierarchy; without first issuing 'set system services dhcp', there is no parent container to attach a pool to. The commit will fail with a 'missing hierarchy' or 'statement not found' error. Thus, enabling the service is a mandatory prerequisite, which is exactly why the correct procedure starts with Step 1 as enabling DHCP services.

Step 1: Enable DHCP services. Step 2: Set DHCP options. Step 3: Configure a DHCP pool with subnet and range. Step 4: Exclude specific addresses.

Why it fails: This order incorrectly attempts to set DHCP options before defining a pool. On Junos, options like router and domain-name-servers are not top-level settings; they are subordinate statements inside a specific pool. Without first configuring the pool with its subnet and range, there is no context or location to attach these options, and the CLI will reject the commands. The pool must exist before its options can be specified, so Step 2 must be the pool definition.

Step 1: Enable DHCP services. Step 2: Configure a DHCP pool with subnet and range. Step 3: Exclude specific addresses. Step 4: Set DHCP options.

Why it fails: In this arrangement, addresses are excluded before DHCP options are set, which violates the preferred logical ordering. Although both exclusions and options are pool-level statements in Junos, the standard workflow is to configure lease parameters (gateway, DNS) first, then reserve/exclude addresses. This prevents a client from receiving an address that should have been excluded during a brief window, and it keeps the configuration readable and maintainable. Setting options after exclusions is illogical because the pool's basic behavior is not fully defined at the time exclusions are made.

Screen: Defines rules to permit or deny traffic based on source, destination, application

Why it fails: This description is incorrect because it defines a security policy, not a Screen. A Junos Screen is designed for attack detection and mitigation by inspecting packet headers and payloads for anomalies like malformed packets, flood attacks, or port scans, rather than making per-traffic allow/deny decisions based on source, destination, and application. Screens use static signatures and thresholds to drop malicious packets, whereas policies use multi-dimensional match criteria and actions.

Zone: Translates private IP addresses to public IP addresses

Why it fails: This description is incorrect because address translation is the function of NAT, not of a zone. A zone in Junos is a logical grouping of interfaces that establishes a security trust boundary and serves as a container for policies, screens, and address books. Zones themselves do not modify packet fields; they act as the source and destination context in which policies and NAT rules are evaluated.

show interfaces: Displays routing table entries

Why it fails: The show interfaces command completely lacks the ability to display the contents of the routing table. Its output is strictly limited to interface-level data such as physical and logical state, MTU, packet and byte counters, and interface flags. To view routing table entries, you would need to issue show route, which reads from the Routing Information Base; expecting show interfaces to provide routing information would yield no relevant entries. Hence, this pairing is incorrect.

show version: Displays interface status

Why it fails: The show version command outputs system-wide inventory and revision data: the Junos software release, hostname, hardware model, installed package information, and uptime since the last boot. It does not interrogate interface state and therefore cannot report on link status, error rates, or packet counts. Interface status is a dynamic operational property that must be queried with the show interfaces command. This makes show version an incorrect match for displaying interface status.

delete interfaces fxp0

Why it fails: The fxp0 interface is the internal management Ethernet port used for out-of-band device management, not a physical line card or PIC. Running 'delete interfaces fxp0' would remove its configuration, severing remote management connectivity (e.g., SSH, SNMP, NETCONF) and leaving the device without a routable management address. This is a configuration deletion, not a hardware deactivation command, and it has absolutely no effect on any PIC or FPC that you intend to replace.

set interfaces <name> disable

Why it fails: The 'set interfaces <name> disable' command administratively disables a single logical or physical interface by adding the 'disable' flag in the configuration. This only affects that one interface; the underlying PIC and FPC remain fully powered and operational, and all other interfaces on the same line card continue to carry traffic. It also does not prepare the hardware for physical removal—there is no power-down or graceful shutdown of the line card—so it is not a substitute for the proper chassis offline commands.

request system reboot

Why it fails: 'request system reboot' initiates a full reboot of the entire Junos OS, which affects the routing engine, all FPCs, PICs, and management interfaces. It is a disruptive, system-wide action that takes down all traffic and services, not just the target line card. While a reboot might power-cycle all FPCs along the way, it does not selectively deactivate a single slot and causes unnecessary downtime for unrelated traffic, making it inappropriate for replacing one specific PIC or FPC.

The peer is unreachable

Why it fails: An unreachable peer would typically manifest as a TCP connection failure or a network-level unreachable message before BGP even establishes. Because the log records a hold time expiry, the TCP session must have been up; otherwise the hold timer would not have started. Unreachability can contribute to keepalive delay, but the immediate logged cause is the hold timer, not unreachability.

BGP configuration mismatch

Why it fails: A BGP configuration mismatch, such as an incorrect AS number or MD5 authentication key, is usually detected during the OPEN exchange, producing errors like 'BGP OPEN failed' or 'authentication failed'. The fact that the session reached the established state and then expired the hold timer means the OPEN was accepted, so a mismatch at session establishment is not indicated. This log entry alone provides no evidence of configuration incompatibility.

Route flapping

Why it fails: Route flapping describes frequent changes in network reachability that generate many BGP UPDATE and WITHDRAWAL messages. Such activity would not prevent keepalives from being received; in fact, it would increase the message rate. A hold timer expiry requires an absence of BGP messages, so route flapping is inconsistent with the observed log and is not the cause.

Neither route is valid

Why it fails: The route via 10.0.0.2 is valid and has been installed in the routing table by OSPF. Both routes exist in the OSPF database but only the best one is selected for forwarding. Claiming neither route is valid ignores the fact that OSPF has successfully calculated and installed a usable path.

The route via 10.0.0.1 because it was learned later

Why it fails: OSPF route selection is based solely on the SPF-computed cost (metric), never on the order in which routes were learned or timestamps. A route learned later does not get preference; the route via 10.0.0.2 is chosen because its metric is lower, not because of when it was received.

Both routes are used for load balancing

Why it fails: OSPF performs load balancing only when multiple routes to the same destination have identical metrics (equal-cost multipath). Here the routes via 10.0.0.1 and 10.0.0.2 have different metrics, so they are not equal-cost. Only the lower-metric route is installed in the forwarding table and used.

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

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

show log messages | last 100

Why it fails: This command shows the last 100 lines of the log file, but it is a one-time snapshot, not real-time monitoring.

show system log messages

Why it fails: This is not a valid command. Real-time monitoring is done with 'monitor start'.

show configuration system syslog

Why it fails: This command shows the syslog configuration, not live log messages.

monitor start interactive-commands

Why it fails: The 'monitor start interactive-commands' command displays real-time output of user commands logged to the interactive-commands log file. It is another real-time monitoring option.

The commit operation can be confirmed with a time delay.

Why it fails: The 'commit confirmed' feature is a specific commit operation that applies a configuration with an automatic rollback timer. By default, the rollback occurs after 10 minutes unless you execute 'commit confirm' again to finalize the change. The time delay is configurable using the 'confirm' option, e.g., 'commit confirmed 5' for a 5-minute window. If the confirmation is not received within the timeout, Junos automatically reverts to the previous configuration, which helps prevent loss of access to the device during remote configuration changes.

The commit operation always requires a reboot.

Why it fails: The vast majority of configuration changes in Junos take effect without a reboot because the commit operation pushes the new configuration to the relevant system processes and daemons, which re-read the updated data and apply it to their operational state. Only extremely low-level changes, such as certain kernel parameters or package installations, might require a reboot to take effect. Junos provides load-and-go behavior for most routing, switching, security, and interface configurations, so requiring a reboot is the exception rather than the rule. This design is a key advantage of Junos architecture, allowing non-disruptive configuration changes in production networks.