Troubleshooting Scenario Questions

The interface MTU size is mismatched.

Why wrong: 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 wrong: 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 wrong: 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.

Check the interface error counters for CRC errors or drops.

Why wrong: Interface errors would likely cause persistent failures, not intermittent.

Verify the BGP session state and check for route flapping.

Why wrong: The BGP session is established and routes are present, so route flapping may not be the cause.

Check the MPLS label switching table to ensure labels are correctly assigned.

Why wrong: The LSP is up and labels are assigned, so this is likely not the issue.

Use 'deactivate protocols ospf' to disable OSPF entirely and then manually re-enable pieces.

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

The engineer must manually rollback using the rollback command.

Why wrong: The rollback happens automatically after timeout.

The change remains committed until the next reboot.

Why wrong: Commit confirmed automatically rolls back if not confirmed.

The device reloads with factory defaults.

Why wrong: The device reverts to the previous configuration, not factory defaults.

show system connections

Why wrong: 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 wrong: 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 wrong: 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.

show interfaces terse

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Perform a 'show log messages' to check for errors before taking action

Why wrong: Checking 'show log messages' is purely a diagnostic step; it can help identify the cause of high CPU but does nothing to reduce the processing load on rpd. The BGP sessions continue to send updates, and rpd still parses and processes every received prefix. While logging is a sensible troubleshooting step, it should follow or accompany an active mitigation, not replace it.

Bounce all BGP sessions by clearing them with 'clear bgp neighbor *'

Why wrong: Clearing all BGP sessions with 'clear bgp neighbor *' is disruptive and counterproductive under high CPU. It forces every neighbor to re-establish and re-send its complete routing table, causing a burst of route-processing activity that can spike rpd CPU even higher. This approach also drops all active traffic that depends on those BGP-learned routes and widens the impact of whatever issue is driving the CPU load.

Disable BGP multipath to reduce route processing

Why wrong: BGP multipath allows multiple equal-cost routes to be installed in the forwarding table, which requires rpd to perform additional path computation only when best-path selection runs; it is not the primary driver of CPU utilization. The sustained high CPU is almost always caused by the number of received updates, prefixes, or peers, not by multipath. Disabling multipath could even harm traffic distribution without meaningfully reducing the work rpd does for every incoming BGP message.

show route protocol ospf

Why wrong: 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 wrong: 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 wrong: 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.

Perform a loopback test on the interface using 'test interface so-0/0/0'.

Why wrong: Loopback testing places the interface into a loopback mode, redirecting transmitted signals back to the receiver to isolate internal hardware faults, but it takes the interface out of service and drops all production traffic on that link. It should only be considered when less intrusive diagnostics have already indicated a specific hardware or cabling fault, not as a first step in troubleshooting intermittent physical errors. Furthermore, on a Junos router, the exact loopback command and behavior may depend on the specific serial PIC hardware, and an internal loopback may not validate external cabling.

Review the system syslog file using 'show log messages' and search for interface down messages.

Why wrong: Syslog captures only state transitions and alarms explicitly logged by the routing engine, such as link-up/link-down or high-severity events; it does not record incremental CRC error counters or transient physical-layer anomalies that do not trigger a state change. In many cases, intermittent serial interface errors occur without the interface going down, so there will be no relevant syslog entries, making this method insufficient for detecting the underlying physical degradation. The absence of 'interface down' messages does not imply a healthy physical layer.

Immediately replace the serial interface card to rule out hardware failure.

Why wrong: Replacing hardware before collecting empirical evidence is a costly, disruptive, and often ineffective troubleshooting step. The intermittent CRC errors could originate from a faulty cable, improper grounding, electromagnetic interference, or a mismatch in framing or clocking settings rather than from the interface card itself. Only after verifying the physical layer with monitoring, checking configuration, and testing with non-disruptive methods should you consider hardware replacement, and then it's often better to use a swap with a known-good component in a controlled maintenance window.

Disable the eBGP session on R2 to remove the BGP routes from the routing table.

Why wrong: Incorrect: BGP routes on R2 do not affect R1's static route next-hop reachability; the issue is on R1.

Increase the static route's preference to a lower value (e.g., 4).

Why wrong: Incorrect: the default preference of 5 is already very low; a lower preference would not help because the route is hidden, not competing with another route.

Configure a more specific static route to 172.16.10.0/24 with a mask of /25.

Why wrong: Incorrect: a more specific route would still have the same next-hop and would also be hidden if the next-hop is unreachable.

monitor traffic

Why wrong: 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 wrong: 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 wrong: 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.

Spanning Tree Protocol is blocking the user ports.

Why wrong: Spanning Tree Protocol (STP) blocking the user ports would place those interfaces in a BLK/alternate state, preventing the switch from sending or receiving frames on them. In that state, the switch would not transmit ARP requests on those ports, so it would not record an incomplete ARP entry for the user host; instead, the ARP entry would be absent entirely. Since the symptom is an ARP entry stuck in 'incomplete', STP is not the cause—that state indicates the switch actively sent ARP requests but received no replies.

A static MAC address entry for the server is missing.

Why wrong: The issue is with the switch trying to resolve the user's IP address to a MAC address via ARP, not with forwarding to the server. ARP entries are populated dynamically from received packets, and a static MAC address entry for the server would only matter if the switch needed to reach the server's MAC directly without an ARP exchange. If the server's MAC were missing, traffic to the server would fail with 'no route to host' or a different symptom, not an incomplete ARP entry for a user host in VLAN 100.

The IRB interface for VLAN 100 is not configured with a proxy ARP.

Why wrong: Proxy ARP is a feature where a Layer 3 device responds to ARP requests on behalf of another device, typically one on a different subnet. In this scenario, the switch's IRB interface for VLAN 100 and the user host are on the same subnet, so the user host should respond to ARP requests directly—proxy ARP is unnecessary for local subnet communication. Disabling or omitting proxy ARP does not prevent the switch from resolving ARP for a directly connected host; it only affects resolution across subnets when routing is involved.