Troubleshooting practice questions

The hello timer is too slow

Why it fails: A hello timer that is too slow still allows hellos to be sent, only at longer intervals than the default 10 seconds on broadcast interfaces. OSPF requires matching hello intervals between neighbors, but even a mismatched or slow timer would still generate packets and could eventually form an adjacency if intervals align. The absence of any neighbor in the OSPF database indicates that no hellos are being transmitted at all, which is characteristic of a passive interface, not a slow timer.

Authentication is missing

Why it fails: OSPF authentication is an optional feature and not enabled by default. If authentication were configured on one side but not the other, it would cause a checksum or key mismatch and prevent adjacency formation. However, the problem statement gives no indication that authentication is configured on the router, and OSPF operates normally without it. The lack of neighbors is better explained by a passive interface, which suppresses hellos regardless of authentication settings.

The interface is administratively down

Why it fails: An administratively down interface would be displayed in a 'down' state in the interface terse output, and OSPF would not run on it because the physical or logical link is disabled. The provided terse output explicitly shows the interface is up, ruling out any administrative shutdown as the cause. Administrative down is also a deliberate action that disables all traffic, whereas a passive interface leaves the interface operational but restricts only OSPF hello processing.

rollback 2

Why it fails: rollback 2 changes only the candidate configuration, setting it to the state from the second-most-recent commit, but it does not affect the active running configuration. Without a subsequent commit, the device continues to operate with the current active configuration, so this command alone is insufficient. In the Junos CLI, rollback always operates on the candidate configuration and requires an explicit commit to make the change take effect.

commit confirmed 2

Why it fails: commit confirmed 2 is unrelated to rolling back to commit number 2. It initiates a confirmed commit with a 2-minute timeout, meaning the configuration is committed temporarily and will automatically roll back to the previous configuration if the technician does not issue a commit confirm within two minutes. This mechanism is designed for safe remote commits, not for reverting to a specific earlier commit index. To revert to a prior commit, use rollback with the appropriate number and then commit.

rollback 3

Why it fails: rollback 3 would set the candidate configuration to the state from three commits ago, which is one commit further back than the intended target. The technician explicitly wants to revert to the configuration from two commits ago, so rollback 2 is the correct index. Using rollback 3 would bring the device to an older configuration and may introduce additional unwanted changes.

monitor traffic

Why it fails: monitor traffic does not interact with saved state; instead, it initiates a live libpcap-based packet capture on a specified interface or protocol, decoding packets in real time until interrupted. It is designed for data-plane debugging and never writes a support archive to disk, so it cannot save the operational state of the system.

show system information

Why it fails: show system information displays a one-shot inventory summary that includes the hostname, model, Junos version, uptime, and build information, outputting it only to the terminal. It is a single show command, not an automated collection routine, and unless the user manually pipes the output to '| save' it does not create any file. Even when redirected, it captures only that command's output, not the full operational snapshot that request support information gathers.

file copy

Why it fails: file copy is the Junos file-management utility for moving existing files over FTP, SCP, HTTP, or local paths; it simply duplicates files from one location to another. It generates no diagnostic data and cannot capture operational state. In a troubleshooting workflow, file copy would typically be used to transfer a support bundle off the device after request support information creates it, but it is not the command that creates that bundle.

The interface MTU size is mismatched.

Why it fails: An MTU mismatch on an OSPF interface typically surfaces during the Database Description (DBD) exchange, because the MTU value is carried in DBD packets and a larger packet is dropped or truncated. This manifests as adjacency stagnation in the EXSTART or EXCHANGE state, not INIT. In INIT, the router has received a valid Hello but is still waiting for bidirectional reachability, which is a layer of operation prior to MTU negotiation.

The OSPF network type is mismatched.

Why it fails: Both routers in this scenario default to the broadcast OSPF network type on Ethernet interfaces, so there is no network type mismatch to cause the INIT state. A true mismatch (e.g., broadcast on one side and point-to-point on the other) would alter Hello packet fields like the DR/BDR priority and options, preventing proper neighbor discovery or two-way establishment, but that is not the case here. The existing configuration resolves to identical network types.

The router IDs are not properly configured.

Why it fails: Router IDs are unique and correctly set in this scenario, so they cannot be the cause. OSPF uses router IDs for DR/BDR election, database exchange, and LSA identification, but the INIT state only depends on seeing your own router ID in an unauthenticated neighbor's Hello. Duplicate or missing router IDs tend to create later problems in EXSTART/EXCHANGE or cause LSDB inconsistencies, not a failure to establish two-way adjacency in INIT.

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.

set interfaces ge-0/0/1 unit 0 family inet cost 200

Why it fails: The `cost` parameter is not a valid interface-level statement under `family inet` in JUNOS; OSPF interface cost or metric is configured under the `protocols ospf` hierarchy, typically as `metric`. This command would be rejected by the CLI because the leaf `cost` does not exist at that level, so it has no effect on OSPF path selection. Even if it were accepted, OSPF reads its interface metric from the OSPF configuration, not from the interface family settings, so this change would not influence the preference between ge-0/0/0 and ge-0/0/1.

set protocols ospf area 0 interface ge-0/0/1 passive

Why it fails: Configuring `ge-0/0/1` as a passive OSPF interface stops the device from sending or processing OSPF Hello packets on that link, which prevents the formation of an OSPF adjacency with the neighbor attached to that interface. Without an adjacency, the remote router will not learn the routes through ge-0/0/1, and OSPF will not advertise transit transit traffic over that link, potentially causing a blackhole or loss of connectivity if the path should remain usable. Passive mode is useful for advertising directly connected networks like loopbacks or stub segments without exchanging routing information, but it is the wrong tool here because the goal is to alter path preference while keeping the neighbor relationship intact.

set interfaces lo0 unit 0 family inet address 10.0.0.1/32 metric 100

Why it fails: The `metric` statement is not valid under `family inet` at the interface hierarchy level; JUNOS does not allow setting an OSPF metric on the loopback interface that way, and the command would be rejected. More importantly, the loopback address `10.0.0.1/32` is a host route that OSPF advertises as a stub network, and its OSPF metric is derived from the OSPF interface metric configured for the loopback in OSPF, not from any generic interface metric. Altering a loopback metric would only affect how other routers see the loopback itself, not how transit traffic is routed through ge-0/0/1, so it cannot solve the intended path-selection problem.

show version

Why it fails: show version on a Junos device displays the Junos OS version, hostname, and hardware information. It provides no visibility into BGP peering state, session establishment, or exchanged prefixes. While it might be useful for confirming a fix that required a reboot, it cannot reveal why a BGP session is down or why routes are being rejected.

show interfaces terse

Why it fails: show interfaces terse summarizes the administrative and operational status of all interfaces, along with their configured IP addresses. It does not show the BGP peer's state, such as Active, OpenConfirm, or Established, nor does it report any BGP-specific error or negotiation statistics. Even if the interface is up, the BGP session could be down due to a misconfigured peer, so this command gives no diagnostic value for BGP issues.

show route protocol bgp

Why it fails: show route protocol bgp lists the BGP routes currently installed in the Junos routing table, focusing on the best path to each prefix. It does not explain why a neighbor's advertised routes were not accepted, as rejected routes typically appear as hidden or are simply absent. To see the neighbor's advertised prefixes and the reason for rejection, one must inspect the BGP-specific counters and policy statistics, not the routing table.

show interface statistics

Why it fails: The show interface statistics command outputs a single, point-in-time view of the interface's cumulative input/output counters and error counts. Because it does not automatically refresh, any transient traffic spikes or intermittent drops occurring after the output is printed will not be visible. To observe live changes in these counters, you need a continuously updating command such as monitor interface traffic.

monitor start messages

Why it fails: The monitor start messages command begins streaming system log messages (events such as routing protocol state changes, login events, or error conditions) to the terminal. It does not display or track interface traffic statistics, so it cannot tell you whether packets are being forwarded or dropped on the interface. In this troubleshooting scenario it would show unrelated log activity rather than the real-time interface counters you need.

show interfaces extensive

Why it fails: The show interfaces extensive command provides a comprehensive, single-blurb output containing every available detail about the interface, including physical link state, protocol state, and extensive statistics. However, it is a one-time operational query that does not refresh on its own, so it cannot reveal how those statistics evolve in real time. For a live view you would need to repeatedly issue it, which is less practical than the automatic refresh of monitor interface traffic.

show route table inet6.0

Why it fails: The `show route table inet6.0` command is incorrect for this scenario because it displays only the IPv6 unicast routing table. If the routing issue involves IPv4 destinations, which is almost always implied by a generic 'routing issue' unless IPv6 is explicitly mentioned, filtering to `inet6.0` would omit the very routes the engineer needs to inspect. This command is useful only when troubleshooting IPv6 connectivity, such as missing RA-learned routes or BGP IPv6 prefixes, but it would not show IPv4 entries like `10.0.0.0/8` or `192.168.1.0/24`. Running it for an IPv4 problem would produce an empty or irrelevant table, leading the engineer to mistakenly conclude that routing is down when the issue is actually in the IPv4 table.

show route forwarding-table

Why it fails: The `show route forwarding-table` command is incorrect because it displays the forwarding table (also known as the FIB or PFE forwarding table), not the route table (RIB). The forwarding table is derived from the route table and contains only the active next-hops that are programmed into the Packet Forwarding Engine, with no protocol preference or route origin information. It is used to verify what is actually being forwarded in hardware or software, but it does not show all candidate routes, hidden routes, or secondary paths that the routing table holds. For troubleshooting why a route is not being selected or why a specific path is preferred, the engineer must examine the route table (`inet.0`), because it shows the routing decision process before the FIB is populated.

show route protocol bgp

Why it fails: The `show route protocol bgp` command is incorrect because it filters the route table to display only routes learned or advertised by the BGP protocol. A generic routing issue could be caused by an OSPF, IS-IS, static, or directly connected route problem, and this command would hide those entries entirely. Even if the root cause involves BGP, this command shows only BGP-route entries and does not reveal the full routing table context, such as how a BGP route competes with a static or IGP route for the same prefix. To troubleshoot comprehensively, the engineer should view the complete IPv4 routing table in `inet.0` and apply protocol filters only after narrowing down the suspected source, not at the outset.

show log messages

Why it fails: The `show log messages` command retrieves messages written to the syslog buffer or a log file, such as interface events, user logins, or protocol errors. While a CPU spike might eventually be reflected in log entries, the command does not provide a real-time or per-process metric of CPU usage; it is asynchronous and historically framed. Even if high CPU were recorded in some log, you would not see which process consumed the cycles without inspecting process tables.

show system memory

Why it fails: The `show system memory` command reports memory utilization on the Routing Engine, including buffer pool usage, free memory, and a summary of allocated kernel and user memory. It does not expose the CPU load percentage, per-process CPU time, or scheduler state; a process that hogs CPU can do so with minimal memory footprint. This command is meant for diagnosing memory exhaustion or leaks, not for identifying the cause of high CPU utilization.

show interfaces

Why it fails: The `show interfaces` command displays per-interface operational statistics like input/output packet counts, error rates, and traffic bandwidth utilization. While extremely high interface traffic might contribute to overall CPU load due to interrupt handling or protocol queue processing, it does not show the internal CPU usage of the Routing Engine or enumerate processes. It is a command for link-level performance analysis, not for isolating which software component is consuming CPU cycles.

The route mask must be equal to or greater than the specified prefix length.

Why it fails: It describes an `orlonger` match behavior, not an `exact` match. In Junos, the `exact` keyword requires the route's prefix length to be identical to the configured prefix length — no longer, no shorter. Saying the mask must be "equal to or greater than" the prefix length would allow routes with supernet masks (e.g., 10.0.0.0/8 matching a filter for 10.0.0.0/16), which violates the strict equality enforced by `exact`. Junos route-filter lists use `exact`, `longer`, `orlonger`, and `through` to express different matching semantics, and only `exact` imposes bit-for-bit and length-for-length equality.

The prefix 0.0.0.0/0 is never matched by 'exact' filters.

Why it fails: This option is false because the default route 0.0.0.0/0 can absolutely be matched by an `exact` filter if you explicitly configure it, e.g., `route-filter 0.0.0.0/0 exact`. Junos does not treat 0.0.0.0/0 as a special exception for `exact` matching; the same equality rules apply — the route's prefix length must be 0 and the address must be 0.0.0.0. The misconception likely arises because 0.0.0.0/0 is often used as a "catch-all" with `orlonger`, but that is a choice of filter semantics, not a limitation of `exact`.

The route mask must be greater than the specified prefix length.

Why it fails: Requiring the mask to be strictly greater than the specified prefix length defines a `longer` match, not an `exact` match. In Junos, the `longer` keyword is used to match only routes that are more specific than the specified prefix (e.g., `route-filter 10.0.0.0/8 longer` matches 10.1.0.0/16 or 10.1.2.0/24, but not 10.0.0.0/8 itself). The `exact` keyword does not allow any difference in mask length — it demands the mask be exactly the same as the configured prefix length. Confusing `exact` with `longer` or `orlonger` is a common source of route-filter misconfiguration, especially when an administrator intends to match only a single subnet.

show log messages

Why it fails: The 'show log messages' command is used to inspect system event and error logs, such as daemon failures or interface flapping events. While these logs can give clues about why a connectivity issue occurred, they do not display the routing table or the current forwarding state. This makes it a diagnostic tool for historical context, not for verifying whether a route to a destination exists.

show configuration

Why it fails: The 'show configuration' command outputs the applied configuration in either set or hierarchy format, detailing static routes, protocols, and interfaces as they are configured. However, it shows only the intended or configured state, not the dynamically learned routes or active routing table entries. A route may be configured but still not be active in the routing table due to an error, so this command cannot confirm the actual routing state.

show interface

Why it fails: The 'show interface' command provides information about physical and logical interface properties, including link status, input/output errors, and protocol state (e.g., up/down). This is useful for verifying Layer 1 and Layer 2 connectivity, but it does not provide Layer 3 route information. Even if all interfaces show 'up', a route may still be missing or the next hop may be unreachable, so this command cannot be used to troubleshoot routing-table-level issues.

show interfaces terse

Why it fails: The 'show interfaces terse' command outputs only a one-line summary per interface, showing administrative status, link status, and IPv4/IPv6 addresses. It deliberately omits data-link encapsulation details such as PPP or HDLC, making it unsuitable for verifying that both routers use the same encapsulation. This command is intended for a quick health check of interface state and IP addressing, not for diagnosing layer-2 framing mismatches. Relying on it here would miss the specific information needed to confirm encapsulation compatibility.

show configuration interfaces

Why it fails: The 'show configuration interfaces' command displays the configured settings for the interface from the candidate or active configuration, which might include an explicit encapsulation statement. However, it shows only the intended configuration, not the operational state or whether the encapsulation negotiation has succeeded. If the encapsulation is left at the default (e.g., HDLC on serial links), the command may not display it at all, lulling the engineer into thinking it is correct. A true verification requires the operational state shown by 'show interfaces extensive', which also exposes any mismatch between the local and remote encapsulation.

monitor traffic interface

Why it fails: The 'monitor traffic interface' command captures and displays packet data in real time, showing headers like Ethernet type or PPP protocol field, but it does not reveal the router's configured encapsulation parameter. You might see what encapsulation appears to be on the wire, but you cannot determine if the router is intentionally configured for that encapsulation or if it is a mismatch. Additionally, it is a troubleshooting tool for observing traffic flow, not a configuration inspection tool. It would not show whether the local interface's encapsulation setting matches the peer's configured setting.

The router IDs are not the same.

Why it fails: Router IDs are 32-bit identifiers that must be unique within the OSPF routing domain. If two routers have different router IDs, that is the normal and expected condition; adjacency formation does not require router IDs to match. In fact, matching router IDs would create an error, because each router would see the other's packets as coming from itself and reject them. Therefore, the router IDs not being the same is not a fault; it is a prerequisite for a valid OSPF neighbor relationship to exist.

The area ID is not configured.

Why it fails: If the area ID were not configured, the interface would not be enabled for OSPF at all, and you would not see any neighbor entry or adjacency state. In this scenario, the adjacency reaching EXSTART means OSPF is operationally up on both ends and the routers have already exchanged Hello packets. A mismatch in area IDs would prevent the routers from even becoming neighbors, typically leaving the state at DOWN or INIT, not EXSTART. The stem indicates the configurations match in this regard, so an unconfigured or mismatched area ID is not the cause.

The hello and dead intervals are mismatched.

Why it fails: Mismatched hello and dead intervals produce failures much earlier in the OSPF neighbor discovery process. Routers only accept Hello packets that carry matching values for these timers; if they differ, the Hello packets are ignored, and the neighbor state never progresses past DOWN or INIT. EXSTART represents a far later stage, after the routers have already exchanged Hello packets and reached the 2-Way state, which proves that the hello/dead intervals were successfully matched and accepted. Thus, this option cannot explain an adjacency stuck specifically in EXSTART.

show route protocol ospf

Why it fails: In Junos, 'show route protocol ospf' displays only the active OSPF routes that have been selected and placed into the routing table, not every route received or advertised. Routes hidden due to higher preference, unreachable next hops, or import policy are omitted. Therefore, if the OSPF LSA exists but the route is not installed, this command will not provide the needed diagnostic insight.

show ospf neighbor

Why it fails: This command focuses on the state of OSPF neighbor adjacencies, such as Full or ExStart, and verifies hello timers, dead intervals, and area membership. It does not expose the contents of LSAs or the prefix information learned from those neighbors. A missing route can occur even when all neighbors show Full, so this command cannot directly confirm whether a specific prefix was received.

show interface terse

Why it fails: This command displays the administrative and operational status of interfaces, along with their configured IP addresses and protocol flags, but it carries no OSPF-specific state or route information. Checking interface terse only tells you whether the physical or logical interfaces are up, not whether OSPF has learned or processed any routes. The missing route would not be visible here, and an interface being down alone does not explain an OSPF LSA's absence from the database.

Privileged mode

Why it fails: Privileged mode is a concept from Cisco IOS, not Junos. Junos separates the CLI into operational and configuration modes, and user access is governed by login classes and permissions rather than a distinct privileged exec level. Claiming that viewing the active configuration requires 'privileged mode' is incorrect because operational mode already provides that access without any elevation.

Configuration mode

Why it fails: Configuration mode is entered with 'configure' and is intended for modifying the candidate configuration using commands like 'set', 'edit', and 'delete'. While 'show' is available inside configuration mode, it displays the candidate configuration, not necessarily the active configuration. This mode is not read-only, and it is not required merely for viewing the current active configuration.

Exclusive configuration mode

Why it fails: Exclusive configuration mode is a special form of configuration mode invoked with 'configure exclusive', which locks other users out of configuring the device. It is still an editing mode, not a read-only viewing mode, and it is overkill for simply inspecting the active configuration. Exclusivity is about preventing concurrent edits, not about enabling read-only access.

show interfaces extensive

Why it fails: Although 'show interfaces extensive' displays a rich set of static statistics—including input/output octets, packet counts, queue depths, and error counters—it is a one-time snapshot that does not refresh automatically. To measure traffic rates during high latency, an administrator would have to run this command repeatedly and manually compute deltas, which can miss short-lived bursts. It is useful for post-incident analysis or for drilling into queuing/error details once a real-time problem is observed, but it is not the appropriate first tool for live troubleshooting.

show interfaces terse

Why it fails: The 'show interfaces terse' command outputs only a brief, static listing of interface names, admin/operational states, and configured IP addresses. It omits bandwidth, packet counts, error statistics, and any time-varying metrics, so it cannot indicate whether an interface is congested or oversubscribed. For diagnosing high latency, you need to observe traffic load and throughput, not just the administrative and link-up/down status.

show log messages

Why it fails: Issuing 'show log messages' reads the system syslog file, which records asynchronous events such as interface transitions, routing protocol changes, and error alarms—but it does not sample interface traffic counters or bandwidth utilization. High latency typically arises from ongoing traffic load, not from discrete loggable events, so this command will not help spot a current congestion spike. It may be consulted after the fact for correlated warning messages, but it is not a real-time interface monitoring tool.

show routing-table VPN-A

Why it fails: The Junos CLI does not accept 'show routing-table'; the correct operational verb is 'route', not 'routing-table'. The command should be 'show route table VPN-A' to display the routing tables of the VPN-A routing instance. The hyphenated form is not a valid keyword in Junos syntax, so this command will fail with a CLI parsing error rather than returning any route information.

show route instance VPN-A

Why it fails: The Junos CLI distinguishes between 'show route' for route lookup and 'show routing instance' for instance parameters. 'show route instance VPN-A' is invalid because the 'route' command does not take 'instance' as a subcommand; instead, use 'show route table VPN-A'. Conversely, 'show routing instance VPN-A' is a valid command for viewing instance configuration and status, but it does not display routes.

show routing instance VPN-A route

Why it fails: This command incorrectly appends 'route' to 'show routing instance', which is a config- and status-oriented command. The valid form for displaying routes is 'show route table VPN-A', not 'show routing instance ... route'. Junos commands are verb-noun oriented: 'show routing instance' is one complete command, and adding 'route' at the end is not a recognized modifier, causing a syntax error.

monitor traffic

Why it fails: monitor traffic captures and decodes packets that traverse a specific interface on the local device, similar to tcpdump, using filters to narrow the capture. It is a passive troubleshooting tool that does not generate probe packets, nor does it follow a packet's journey beyond the local segment. Consequently, it cannot reveal the forward path across multiple routers, making it unsuitable for path tracing.

show route

Why it fails: show route displays the routing table on a single Junos device, including prefixes, active routes, next hops, and protocol preferences. While it tells you where the router would forward a packet based on its local forwarding table, it gives no information about how those packets are actually processed by downstream routers. It is a snapshot of local routing state, not a measurement of the end-to-end path.

ping

Why it fails: ping sends ICMP Echo Requests to a destination and waits for ICMP Echo Replies to verify reachability and measure round-trip time. It is a valuable connectivity check, but it only gives an end-to-end up/down result: the reply comes from the final destination, not from intermediate routers, so the path taken is completely hidden. No per-hop information appears, making it useless for path tracing.

show log messages

Why it fails: This command displays the system log messages, such as alerts, errors, and operational events, stored in the event log. It does not provide a real-time snapshot of per-process CPU utilization, so it cannot be used to pinpoint which specific process is consuming high router CPU. Even if log entries mention resource thresholds, they lack the detailed, current process-level breakdown needed for this diagnostic.

show system resource

Why it fails: This command shows a high-level summary of system-wide resource usage, including percentages for CPU idle time, memory usage, and disk space. While it can indicate that the router is under high CPU load, it does not identify which individual process is responsible, making it too coarse for this task. The output aggregates all processes rather than attributing usage to a specific process.

show chassis routing-engine

Why it fails: This command provides status information about the Routing Engine(s), such as model, serial number, and overall CPU and memory utilization. It reports the aggregate load on the RE but does not enumerate per-process CPU usage, so an administrator cannot determine which process is spiking. It is intended for hardware and RE health monitoring, not for process-level CPU diagnostics.