Troubleshooting practice questions

The native VLAN ID does not match the upstream trunk switch.

Why it fails: Native VLAN settings apply to trunk ports, and a mismatch causes traffic to land in the wrong VLAN or spanning tree inconsistencies, while the physical links stay up. This port is an access port, and down/down means there is no physical link at all, so a native VLAN mismatch cannot explain it. Layer 1 has to be fixed before any VLAN setting matters.

BPDU protection has disabled the port due to a loop.

Why it fails: BPDU protection on Junos does disable a port when a BPDU is received, but the switch reports it as blocked or disabled by BPDU protection in spanning tree and Ethernet switching output, a distinct state with its own reason. down/down instead means no link signal, typically a disconnected or faulty cable, a bad transceiver, or a host interface that is off. Check 'show interfaces ge-0/0/1 extensive' first.

The VLAN 100 has not been created under the [edit vlans] hierarchy.

Why it fails: If VLAN 100 were missing, the configuration referencing it would fail to commit or the port would not belong to a working VLAN, but the physical link would still come up, showing up/up. down/down is a Layer 1 condition, no link signal, so a VLAN configuration error cannot explain it. Fix the physical link first, then confirm VLAN membership with 'show vlans' or 'show ethernet-switching interface'.

KEEPALIVE

Why it fails: KEEPALIVE maintains an idle session by refreshing the hold timer; it carries no error code and cannot terminate a peering. Notification performs that teardown. KEEPALIVE is tempting because a flapping session may show missed keepalives, but the error-driven closure itself is signalled by Notification.

UPDATE

Why it fails: UPDATE advertises reachability and withdrawn routes between peers; it never carries an error code or closes a session. Notification does both. UPDATE is tempting because route churn often accompanies flapping, but the message type that reports the error condition and tears the session down is Notification.

OPEN

Why it fails: OPEN negotiates session parameters such as hold time and capabilities at session establishment; it does not carry error codes or terminate an established session. Notification performs that teardown. OPEN is tempting because it is the first message exchanged, but a flapping session's error-driven closure is signalled by Notification, not by capability negotiation.

show ospf statistics

Why it fails: Statistics summarises counters such as SPF and hello events, not per-neighbour state or dead timer values. Neighbour detail with dead timers and address bindings comes from show ospf neighbor. Statistics is tempting because it reports OSPF activity, but it aggregates protocol counters rather than listing adjacency state.

show route table inet.0

Why it fails: The inet.0 route table shows installed routes and next hops, not OSPF neighbour state or dead timers. Neighbour detail comes from show ospf neighbor. Route tables are tempting because OSPF feeds them, but they reflect forwarding decisions rather than adjacency timers or address bindings.

show ospf database detail

Why it fails: The database detail view lists link-state advertisements and their contents, not adjacency state or dead timer countdowns. Neighbour detail comes from show ospf neighbor. The database is tempting because it is OSPF-specific and detailed, but it describes topology advertisements rather than the state of formed adjacencies.

[edit system services ospf]

Why it fails: OSPF is configured under [edit protocols ospf], not under [edit system services], which holds management daemons such as SSH and Telnet; the area ID is set in the protocols hierarchy. It is tempting because system services groups global daemon settings, but OSPF parameters never reside there.

[edit protocols ospf area <area-id> stub]

Why it fails: The stub statement configures stub-area behaviour, not the area identifier itself; correcting the mismatch requires editing the area number under [edit protocols ospf area], since the stub flag does not set the ID carried in hello packets. It is tempting because it sits inside the area hierarchy, but it governs stubby behaviour only.

[edit routing-options router-id <ip-address>]

Why it fails: The area ID is configured under [edit protocols ospf area], not routing-options, so this path cannot correct the mismatch. The router ID is a separate 32-bit identifier set in routing-options; it would be the right place only when two devices advertise identical router IDs, which is not the logged fault.

Type 2 (Network LSA)

Why it fails: Type 2 LSAs describe the routers attached to a multi-access segment and are generated by the DR; they carry no ASBR reachability between areas. Type 2 is correct when mapping a broadcast or NBMA network's transit subnet and its attached routers.

Type 7 (NSSA External LSA)

Why it fails: Type 7 LSAs flood external routes only within an NSSA and are translated to Type 5 by the ABR; they do not advertise the ASBR's own reachability to other areas. Type 7 is correct when an NSSA's ASBR injects external routes without a backbone connection.

Type 5 (AS-external LSA)

Why it fails: Type 5 LSAs carry external prefix information, not the ASBR's own reachability; routers in other areas learn the ASBR's location through Type 4 summary ASBR LSAs generated by the ABR. Type 5 is correct when flooding redistributed external destinations throughout the OSPF domain.

Duplicate OSPF router IDs in the network

Why it fails: Duplicate router IDs stall the database exchange, but the symptom is repeated ExStart/ExStart negotiation or a router cycling through states, not a persistent ExStart stall. Duplicate IDs are the correct diagnosis when adjacency resets repeatedly during DD exchange.

Different authentication passwords on the links

Why it fails: Authentication mismatch fails at the Hello stage, leaving the neighbour stuck in Down or Init, never ExStart. Checking passwords is right when Hellos are rejected outright or when one side logs authentication failures while the other shows no neighbour.

A mismatch in the OSPF area ID configuration

Why it fails: Area ID mismatch prevents the Hello packets from forming a neighbour relationship at all, so the routers never reach ExStart. Area configuration is the right check when adjacencies stall in Down or Init, or when routers in different areas refuse to form any adjacency.

Configure GRES on the replacement switch using the CLI before connecting stacking cables.

Why it fails: GRES only preserves routing state during a master switchover and cannot reconcile mismatched Junos images or Virtual Chassis port hardware errors. It tempts because GRES is configured on members in high-availability designs, so it would be the right step when planning graceful Routing Engine failover, not for image incompatibility.

Disable LACP on all aggregated links across the stack.

Why it fails: LACP operates on aggregated Ethernet bundles and has no bearing on Virtual Chassis image compatibility or port mismatch errors, so disabling it changes nothing about the boot failure. It tempts because link aggregation faults can destabilise a stack, so it would be relevant if the symptom were member links flapping rather than incompatible Junos images.

Factory reset all existing switches in the Virtual Chassis via the master console.

Why it fails: Factory resetting every existing member erases the working configuration and disrupts production traffic, while the fault lies only with the new member's Junos image and port settings. It tempts because resets do clear corrupted state, so it would suit a chassis-wide configuration corruption, not one incompatible switch.

The interface automatically recovers after a default hold-down timer of 300 seconds.

Why it fails: Shutdown places the port in an err-disabled state requiring manual intervention; no 300-second hold-down timer exists, so it cannot self-recover. The timer idea tempts because other violation actions, such as drop, allow continued operation, but shutdown demands administrative clearance.

The interface drops violating packets but remains operationally up until manually disabled.

Why it fails: Dropping violating packets while staying up describes the drop action, not shutdown, which err-disables the port. It is tempting because drop preserves connectivity for legitimate traffic, and would be correct where only offending frames should be discarded without taking the link down.

The interface transitions to a blocked state and flushes its MAC table every 60 seconds until cleared.

Why it fails: Shutdown err-disables the interface outright; it does not block and periodically flush its MAC table. That behaviour resembles other port-security responses, making it tempting, but the configured action simply disables the port until an administrator clears it.

Identical system IDs configured on both neighboring nodes

Why it fails: System IDs must be unique across the entire IS-IS routing domain; identical system IDs cause conflicts.

Identical DIS priority values on multi-access networks

Why it fails: DIS priorities do not need to be identical; the highest priority wins the election regardless.

The local router has successfully completed the TCP handshake and is waiting for an Open message.

Why it fails: The TCP handshake completing and awaiting an Open message describes OpenSent, not Active. Active means the router is actively attempting to initiate a TCP connection and has not yet completed the handshake, indicating the peer is unreachable or refusing the connection.

BGP has exchanged Open messages and is currently negotiating capability parameters.

Why it fails: Active means the router is actively attempting to establish a TCP connection to the peer, having not yet received a valid response; Open messages are exchanged later, in OpenSent and OpenConfirm. It is tempting because capability negotiation does occur during session setup, but that happens after the TCP handshake completes.

The BGP session is fully operational and exchanging Keepalive messages.

Why it fails: Active is a non-established BGP state where the router is retrying TCP connection attempts; it is not the Established state. Established is the correct answer for a fully operational session exchanging Keepalive and Update messages, which is what the engineer would see on a healthy peer.

BGP AS path settings on core interfaces

Why it fails: BGP AS path attributes govern inter-domain route selection, not Layer 2 forwarding, so they cannot explain a missing bridge-table entry. This is tempting because BGP troubleshooting does involve path verification, but that applies to routing-table issues on core interfaces, not MAC learning.

Routing protocol adjacencies in the default VRF

Why it fails: Routing protocol adjacencies populate the routing table, not the bridge table, so they are irrelevant to MAC learning failures. It is tempting because adjacency checks are standard when diagnosing traffic loss, yet they belong to Layer 3 reachability troubleshooting rather than Layer 2 forwarding-table investigation.

Disable LACP on all aggregated links across the stack.

Why it fails: LACP state on aggregated links is irrelevant to software version compatibility, which is the precaution the scenario demands. Disabling LACP is tempting because it is a real troubleshooting step for link aggregation issues, and would be correct when a member's bundled interfaces fail to form.

Format the flash memory of the existing master switch before inserting the replacement.

Why it fails: Formatting the existing master's flash would erase its Junos OS and configuration, breaking the surviving chassis rather than preparing the replacement. Formatting is tempting because it is a genuine recovery step for corrupted installations, and would be correct when a single switch's software is unusable.

Change the root password of the replacement switch to match the backup routing engine.

Why it fails: Matching root passwords has no bearing on Virtual Chassis formation; the replacement must instead run a Junos OS version compatible with the existing members. Password alignment is tempting because it is a real prerequisite for some management-plane operations, and would matter when merging devices into shared authentication.

The ASBR that originally injected the external route

Why it fails: The ASBR originates Type 7 LSAs inside the NSSA but cannot translate them, since translation requires an interface in the backbone. It is tempting because the ASBR created the external route. The NSSA ABR, not the ASBR, converts Type 7 into Type 5.

Any internal router residing within the NSSA backbone

Why it fails: Internal routers inside the NSSA hold no Type 5 capability and never perform translation; only the NSSA ABR does. The idea tempts because internal routers do flood Type 7 LSAs within the area. The ABR, not an internal router, converts Type 7 to Type 5 toward the backbone.

The designated router (DR) of the NSSA segment

Why it fails: The DR manages adjacency and LSA flooding on the segment, but Type 7 to Type 5 translation is an area-border function, not a broadcast-segment role. Confusing the two is tempting because the DR does originate network LSAs. Only the NSSA ABR performs the translation.

show route summary aggregate

Why it fails: This summarises route table counts, not aggregate generation state, so it cannot confirm the aggregate exists. It is tempting because it is a legitimate route-inspection command, and it would be correct when you need a quick overview of protocol route totals.

show bgp aggregate-routes

Why it fails: No such BGP operational command exists; BGP shows received and advertised routes, not locally generated aggregates. It is tempting because the aggregate is not reaching peers, and it would be correct when inspecting BGP advertisement state for a prefix already present in the routing table.

show routing-options aggregate detail

Why it fails: This displays configured aggregate options rather than the resulting active route, so it cannot confirm generation. It is tempting because it targets aggregate configuration directly, and it would be correct when verifying the aggregate's configured parameters before commit.

The uplink port connecting to the default gateway is missing the 'set protocols arp-inspection trust' statement.

Why it fails: An untrusted uplink causes the gateway's ARP replies to be discarded as untrusted, which DAI logs as 'invalid-ip' or untrusted-port drops, not invalid-ip specifically. Trusting the uplink is correct when legitimate gateway ARP is being dropped on a trusted-port basis, but here the binding mismatch is the cause.

MAC limiting has tripped on the access port, causing ARP packets to be discarded.

Why it fails: MAC limiting drops frames at the port security layer and increments its own violation counters; DAI would never see the ARP packet, so no 'invalid-ip' drop is recorded. MAC limiting is correct when the goal is capping the number of source MAC addresses learned on an access port.

The ARP inspection rate-limit has been exceeded on the access ports.

Why it fails: Rate-limit exhaustion produces drops counted separately as 'rate-limit' or 'exceeded' in DAI statistics, not 'invalid-ip'. Rate limiting is the right remedy when a single port floods ARP and overwhelms the DAI inspection process, but it does not explain a MAC-to-IP binding mismatch against the DHCP snooping database.

Execute 'clear gre statistics' to restart the tunnel encapsulation engine.

Why it fails: Clearing statistics resets counters rather than revealing why encapsulation fails; it destroys the evidence needed to diagnose the fault. It is tempting because clearing counters is a legitimate step to obtain a clean baseline before re-testing, which suits confirming whether a fix worked, not identifying the root cause.

Check that the RSVP bandwidth reservation is set to 100% on the tunnel interface.

Why it fails: GRE is a stateless encapsulation protocol and does not use RSVP; no bandwidth reservation exists on a GRE tunnel interface, so this check cannot explain the failure. RSVP reservation is relevant when diagnosing MPLS TE LSPs, where bandwidth admission control genuinely affects path establishment.

Verify that the BGP AS path matches the tunnel ID.

Why it fails: BGP AS paths and tunnel IDs are unrelated identifiers; no Junos mechanism correlates them, so this check cannot reveal why the tunnel fails. It is tempting because BGP over GRE is common, and verifying routing adjacencies is valid when the tunnel is up but not passing traffic.

Configure all member ports in the LAG to use static mode.

Why it fails: Static LAG mode affects how member links are bundled, not how VRRP advertisements are timed or prioritised, so mastership continues flapping. It is tempting because LAG instability can cause intermittent reachability, but the symptom here is VRRP state churn; adjusting VRRP timers or preemption resolves it.

Disable Virtual Chassis on both switches.

Why it fails: Disabling Virtual Chassis removes the single logical control plane that keeps both EX4600s synchronised, so VRRP timers and interface states diverge, worsening flapping. It is tempting because chassis redundancy feels like a source of instability, but Virtual Chassis is the correct design here; the fix is tuning VRRP timers or tracking.

Remove GRES from the routing engine configuration.

Why it fails: GRES preserves routing state across a Routing Engine switchover; it does not govern VRRP advertisement intervals, so removing it leaves mastership flapping unchanged while losing failover resilience. It is tempting because GRES concerns redundancy, but the actual cause is VRRP timer or preemption settings, which must be adjusted instead.

Verify that the physical interface has an IPv4 address assigned in family inet.

Why it fails: An IPv4 address in family inet configures Layer 3 routing on the interface and has no bearing on whether VLAN 50 tagged frames are accepted on a trunk. It is tempting because interface addressing is a routine check, and it would be correct if the fault involved routed reachability rather than Layer 2 VLAN membership and tagging.

Verify that spanning-tree bridge priority is set to 0.

Why it fails: Spanning-tree bridge priority influences root bridge election and topology, not whether a trunk forwards tagged frames for VLAN 50. It is tempting because STP misconfiguration can block links, and it would be the right check if the symptom were a loop-related blocked port rather than missing VLAN membership on the trunk.

Verify that the port mode is set to access.

Why it fails: An access port carries untagged frames for a single VLAN, so it cannot pass VLAN 50 tagged traffic at all; the fault lies in trunk encapsulation, allowed-VLAN lists or native VLAN mismatches. Access mode is correct only when connecting an end device that sends untagged traffic.

The Virtual Chassis primary routing engine priority is set too low.

Why it fails: LACP timeout errors stem from mismatched timer configuration or one side not receiving PDUs, not from Virtual Chassis primary routing engine priority, which governs RE mastership election within a VC. That setting would matter when designing VC failover behaviour, but it cannot cause member-link flapping on a third-party LAG.

VRRP preemption is enabled on the aggregated interface.

Why it fails: VRRP preemption governs which router becomes master in a virtual gateway; it does not affect LACP negotiation or member link timers. It is tempting because both involve interface redundancy, but the LACP timeout errors point to mismatched aggregation settings, not gateway election.

GRES is disabled on the EX4300 switch.

Why it fails: LACP timeout errors arise from timer mismatches or lost PDUs on the member links, not from GRES, which only preserves routing state across RE failover. GRES would be the right concern when planning non-stop routing during a Routing Engine switchover, not for intermittent LAG member flapping.

Type 3 LSA, flooded between areas but not within an area.

Why it fails: Type 3 LSAs are summary LSAs generated by ABRs to advertise networks from one area to another. They do not carry external route information from ASBRs. External routes are advertised via Type 5 (or Type 7 in NSSA). Type 3 LSAs are used for inter-area routes, not external routes, so they cannot be the missing piece here.

Type 7 LSA, flooded only within an NSSA.

Why it fails: Type 7 LSAs are used within NSSAs to carry external route information. They are flooded only within the NSSA and are translated to Type 5 by the NSSA ABR. Since area 1 is not described as an NSSA, Type 7 LSAs are not relevant. The ASBR in area 0 would generate Type 5 LSAs, not Type 7.

Type 4 LSA, flooded only within the area where the ASBR resides.

Why it fails: Type 4 LSAs are generated by ABRs to describe the ASBR to other areas. They are flooded throughout the OSPF domain except stub areas, not just within the ASBR's area. Their purpose is to tell other areas how to reach the ASBR. They do not carry external route information; that is the role of Type 5 LSAs. So this does not explain missing external routes.