Troubleshooting Scenario 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.

VLAN10 is not defined in the global VLAN configuration.

Why it fails: The exhibit shows VLAN10 listed with its member interfaces and an active status, which proves VLAN10 is defined at the [edit vlans] hierarchy. A VLAN only appears in the output of operational commands like 'show vlans' when it is configured. Since VLAN10 is active, a missing global VLAN definition cannot be the cause of the connectivity failure.

An IRB interface for VLAN10 is not configured.

Why it fails: An IRB (integrated routing and bridging) interface provides a Layer 3 gateway for a VLAN, enabling routing between VLANs or to other subnets. For two hosts on the same VLAN and the same IP subnet, communication is purely a Layer 2 broadcast and MAC-learning process, so an IRB is unnecessary. Even if the hosts were on different subnets, an IRB alone would not help unless the hosts are configured with that IRB as their default gateway.

The interface ge-0/0/2 is configured as a trunk port.

Why it fails: On Junos, a trunk port can explicitly include VLAN10 in its 'vlan members' list, so the port would still forward VLAN10 frames. The exhibit shows ge-0/0/2 as a member of VLAN10, which is consistent with either an access port or a trunk whose allowed list contains VLAN10. A trunk port is not inherently incompatible with Layer 2 connectivity in VLAN10; the port's membership matters more than its mode, so this is not the root cause.

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.

The LACP system priority is set too low on the new switch, causing it to lose LACP negotiations

Why it fails: LACP system priority is not a negotiation metric that can cause the bundle to be 'lost'; a numerically lower value actually grants the switch a higher priority when deciding which end controls aggregation, so setting it lower on the new switch would make it more likely to become the active side, not less. Even with an unfavorable priority, LACP still completes if both peers are configured with compatible modes and key values, and once the LAG forms, RSTP treats it as a single logical interface. The described symptom points to RSTP failing to see the aggregate, which is a LAG configuration issue, not an LACP priority issue.

The uplink interfaces are configured as alternate ports instead of root ports

Why it fails: RSTP port roles (root, alternate, designated, backup) are derived dynamically from the exchange of BPDUs and the calculated path cost to the root bridge; they cannot be manually assigned as 'alternate' or 'root' in configuration. If both uplinks were somehow placed into an alternate state, they would be discarding traffic rather than forwarding, so the result would be a total loss of uplink connectivity, not an intermittent loop. The actual loop occurs because RSTP sees two separate forwarding links, and the blocking decision between them is unstable—not because a role was preselected.

The new switch has a different root bridge priority, causing it to become the root and disrupting topology

Why it fails: A different root bridge priority can change which switch is elected root, but after the spanning-tree topology converges, port roles stabilize and the switch stops flushing its forwarding database; it does not cause ongoing intermittent blocking. For the new switch to become root, its priority must be numerically lower (higher priority) than the current root, and the resulting topology change would be a one-time convergence event, not a recurring loop. The intermittent blocking in this scenario is the classic symptom of RSTP treating two separate physical links as independent paths while the LAG fails to aggregate them, which is unrelated to the root bridge election.

show system connections

Why it fails: The 'show system connections' operational command displays the current TCP and UDP socket table, similar to netstat, showing local and remote addresses and connection states. It does not perform any DNS lookups or query a resolver; it only reads the kernel's connection table. If a hostname was previously resolved and left in the socket cache, it might appear, but the command itself never triggers a name resolution for the purpose of testing DNS. Therefore, it cannot verify whether the configured DNS servers are able to resolve an external FQDN.

traceroute <external website FQDN>

Why it fails: Traceroute uses ICMP or UDP packets to map the hop-by-hop path to a destination, but it does not perform a DNS lookup to validate name resolution. This command is useful for diagnosing routing paths and identifying where packet loss occurs along a network trajectory. It would be the correct tool if you needed to identify which specific router in a sequence is dropping traffic to an IP address.

show dns name-server

Why it fails: The 'show dns name-server' command outputs the list of IP addresses configured as DNS servers on the device, typically from the 'system name-server' hierarchy. It is a read-only display of configuration; it does not send any DNS query packets to those servers, nor does it check whether they are reachable, responding, or returning correct answers. A server could be listed but be down, or have a misconfigured network path, and this command would still show it without any error. Thus, while useful for verifying which servers should be used, it cannot diagnose resolution failures.