Troubleshooting Scenario Questions

IGMPv2 leave messages are received on an interface without active listeners.

Why it fails: Unsolicited or extra leaves do not cause RPF failures.

PIM hello messages are exchanged with an incorrect hold time.

Why it fails: Hold time mismatches affect adjacency timers, not the RPF check.

show bgp summary

Why it fails: This command reports peer session state, uptime and prefix counts, not next-hop resolution, so it cannot show why the route stays hidden. It is tempting because it is the standard first check for BGP problems, and is correct when a session is flapping or down.

show bgp group

Why it fails: This command lists group-level peer and policy configuration, not routing-table next-hop resolution, so it cannot explain the unresolved next hop. It is tempting because it inspects BGP structure, and is correct when verifying group membership or peer configuration.

show route advertising-protocol bgp

Why it fails: This command displays routes advertised to BGP peers, showing outbound policy results rather than how a received next hop resolves. It is tempting because it inspects BGP route information, and is correct when verifying which prefixes are being sent to a neighbour.

Junos rejects configurations where both BA and MF classifiers are applied to the same interface

Why it fails: Junos permits both classifier types on one interface and resolves them by precedence, so the configuration is accepted. It is tempting because some platforms restrict combining classifier types, but on Junos the documented behaviour is ordered evaluation, not rejection.

Both classifiers are executed simultaneously in hardware without precedence

Why it fails: Junos applies a defined precedence between the two classifier types rather than running them concurrently; hardware evaluates them in a fixed sequence. It is tempting because both classifiers do operate in hardware, but that shared execution plane does not mean simultaneous, order-independent processing.

Multi-field classification is evaluated first, followed by behavior aggregate classification

Why it fails: Junos evaluates the behaviour aggregate classifier first, then the multi-field classifier, so this reverses the documented order. It is tempting because multi-field classifiers are more granular and appear logically prior, but granularity does not determine processing sequence on ingress.

Reconfigure the port from access mode to trunk mode.

Why it fails: Trunk versus access mode affects VLAN tagging of traffic, not Power over Ethernet detection or delivery. A hardware error is a physical-layer PoE fault, so changing the link mode cannot resolve it; trunk reconfiguration is correct when a phone needs multiple VLANs, such as voice and data separation.

Modify the LLDP-MED network policy timeout value to allow longer initialization.

Why it fails: LLDP-MED network policy timeout governs how long a phone waits for VLAN and QoS policy information, not power negotiation. A hardware error points to the PoE controller or port hardware, so extending the timeout would not clear it; LLDP-MED tuning suits phones that power up but fail to receive voice VLAN settings.

Disable spanning tree protocol on the interface.

Why it fails: Spanning tree operates at Layer 2 and has no bearing on Power over Ethernet delivery; a hardware error indicates a physical or controller fault. Disabling STP is relevant when resolving Layer 2 loops or topology convergence issues, not power faults.

The RADIUS server took too long to validate the client credentials and dropped the session.

Why it fails: EAPOL-TIMEOUT is generated by the authenticator when the supplicant fails to answer EAPOL retransmissions; RADIUS latency produces authentication-server timeout or reject messages instead, after EAPOL has already reached the switch. It is tempting because slow RADIUS does break 802.1X, but that scenario logs RADIUS, not EAPOL, timeouts.

The switch port's operational mode reverted from access to trunk, dropping EAPOL frames.

Why it fails: EAPOL-TIMEOUT means the switch received no EAPOL response from the supplicant within the retransmit window, not that the port reverted to trunk mode. A trunk/access mismatch would typically produce native VLAN or tagging errors, and it is tempting because misconfigured port modes do disrupt authentication, but that is a different fault signature.

The client sent an invalid EAP message that failed integrity checks.

Why it fails: An invalid EAP message failing integrity checks triggers EAP failure or authentication rejection, not EAPOL-TIMEOUT, which specifically indicates the supplicant never replied to EAPOL retransmissions. It is tempting because malformed EAP frames do abort authentication, but that fault surfaces as EAP integrity or method errors, not silence from the client.

Run 'show ospf database multicast' to verify LSA type 6 propagation.

Why it fails: MOSPF uses type 6 LSAs, but standard enterprise deployments use PIM, and MOSPF does not use this command syntax.

Run 'show bgp summary multicast-unicast' to verify BGP routing tables for multicast RPF checks.

Why it fails: Multicast RPF checks rely on the unicast routing table (or MBGP if explicitly configured), but 'bgp summary multicast-unicast' is not the correct troubleshooting syntax for standard PIM RPF verification.

show ip ospf interface

Why it fails: This is an IOS-style syntax; Junos uses 'show ospf interface' without the 'ip' keyword, so the command is rejected. Operators familiar with Cisco CLI find it tempting, and it would be correct on IOS devices, not Junos.

show protocols ospf status

Why it fails: Junos exposes OSPF neighbour and interface state through 'show ospf neighbor' and 'show ospf interface'; 'show protocols ospf status' is not a valid operational command and returns a syntax error. It is tempting because 'show protocols' lists configured routing protocols, which suits verifying configuration rather than troubleshooting adjacency failures.

show route ospf-table

Why it fails: Junos stores OSPF routes in the inet.0 table, inspected with 'show route protocol ospf'; 'ospf-table' is not a routing table name and the command fails. It is tempting because other vendors expose per-protocol tables, so the naming feels familiar, but Junos uses a single inet.0 table with protocol filters.

show configuration protocols evpn

Why it fails: This command displays the EVPN protocol configuration, such as VNI mappings and route distinguishers. It is useful for verifying configuration correctness but does not show operational status of tunnels or VTEPs. Since the problem is likely a data plane failure, checking configuration alone will not reveal whether the VXLAN tunnel is up or down. Therefore, it is not the appropriate command for this scenario.

show route table bgp.evpn.0

Why it fails: This command displays the BGP EVPN routing table, which shows EVPN routes received and advertised. While useful for control plane verification, it does not provide information about the VXLAN tunnel interface status or VTEP operational state. The scenario already indicates that Type 2 routes are exchanged, so the issue is likely in the data plane, not the control plane. Therefore, this command is not the best choice.

show ethernet-switching table

Why it fails: This command shows the MAC address table for Ethernet switching, including locally learned and remotely learned MACs via EVPN. It can help verify that remote MACs are installed, but it does not indicate whether the VXLAN tunnel is operational. If the tunnel is down, remote MACs might still appear in the table if control plane routes are present, leading to misleading conclusions. Thus, it does not directly diagnose tunnel status.

The OSPF route preference is lower than another protocol's route.

Why it fails: If another protocol has a lower preference (higher priority), the OSPF route would not be installed. However, the scenario does not mention any other protocol, and the route is not in the table at all. This is less likely than an unreachable forwarding address, which is a specific OSPF issue.

The OSPF area is a stub area, which blocks external LSAs.

Why it fails: In a stub area, external LSAs are not flooded, so the route would not appear in the LSDB. The scenario states the route is present in the LSDB as an external LSA, so the area cannot be stub. Therefore, this is not the cause.

The OSPF router ID is not configured.

Why it fails: An OSPF router ID is required for OSPF to operate, but if it were missing, OSPF would not function at all, and no routes would be present. Since the route is in the LSDB, OSPF is operational, so this is not the issue.

show vstp topology-change

Why it fails: Invalid command syntax.

show spanning-tree vstp-status

Why it fails: Invalid command syntax.

show ethernet-switching vstp-neighbors

Why it fails: Invalid command syntax.

The voice VLAN is not configured under the switch-options vlan-group hierarchy.

Why it fails: The vlan-group hierarchy configures VLAN membership for authenticated supplicants, not LLDP-MED voice VLAN advertisement; the phone needs the voice VLAN TLV from the interface's voice VLAN configuration. It is tempting because vlan-group is a genuine voice-related setting, correct when assigning VLANs dynamically via 802.1X rather than LLDP-MED.

IEEE 802.1p priority marking is missing from the global bridge-options statement.

Why it fails: 802.1p priority marking sets CoS bits on egress frames; it does not generate the LLDP-MED voice VLAN TLV, so the phone still receives no VLAN information. It is tempting because 802.1p is genuinely part of voice QoS configuration, and would be correct when prioritising voice traffic after the VLAN is already known.

LLDP advertisement interval is set too high, causing timeout on the phone.

Why it fails: A long advertisement interval delays TLV delivery but does not stop the voice VLAN TLV being transmitted; the phone would eventually receive it, so this cannot explain its complete absence. It is tempting because interval tuning is a real LLDP consideration, correct when reducing discovery latency or protocol overhead on stable links.

The RP in AS 65001 must be configured as a candidate RP for the source's group range to receive Source-Active messages.

Why it fails: A router receives Source-Active messages as an MSDP peer regardless of whether it is a candidate RP for that group range. Candidate RP configuration affects which RP is elected within a domain, not whether SA messages are accepted from a peer. The absence of SA messages is due to missing source state at the originating RP, not RP candidacy.

The MSDP TCP session must be encrypted with IPsec before Source-Active messages are exchanged.

Why it fails: MSDP uses plain TCP port 639 for peer sessions and does not require IPsec to exchange Source-Active messages. While IPsec can be layered for security, its absence does not prevent SA messages from being generated or sent. The real issue is that the source RP has no (S,G) state, so there is nothing to advertise over the established session.

The receiver's last-hop router must send an MSDP Source-Active request to the remote RP before any messages are sent.

Why it fails: MSDP has no request mechanism; Source-Active messages are pushed by the RP that knows the source toward its peers. A last-hop router does not query a remote RP over MSDP. The receiving RP relies on SA messages already being sent, which requires the source RP to have learned the source through a PIM Register.

Yes, all routes received by a route reflector are reflected to all peers regardless of client status.

Why it fails: A route reflector reflects routes from clients to all peers, but routes learned from non-clients go only to clients, never to other non-clients. It is tempting because route reflectors do relay most IBGP routes, which is correct when the receiving peer is a client of that reflector.

No, route reflectors never reflect routes received from any IBGP peer.

Why it fails: Route reflectors do reflect routes received from clients, so the blanket claim that no IBGP route is ever reflected is false. It is tempting because it correctly captures that non-client routes are not reflected to non-clients, but overstates this into a rule covering all IBGP peers.

Yes, provided the routes contain the same Cluster ID as the receiving non-client peer.

Why it fails: Cluster ID matching is not the criterion; reflection depends on client or non-client status, and non-client routes are never sent to non-clients. It is tempting because Cluster ID and Originator ID do drive loop prevention in route reflection, so they appear relevant to whether a route propagates.

show mpls lsp extensive

Why it fails: MPLS LSP extensive details label-switched path state, not EVPN routes or peers; the stem asks for EVPN routing table and neighbour diagnostics. It is tempting because EVPN signalling often rides over MPLS transport, so LSP health can indirectly affect EVPN, making it the right choice when isolating underlay forwarding faults rather than control plane adjacencies.

show spanning-tree interface

Why it fails: Spanning-tree interface output shows Layer 2 loop-prevention states, which EVPN eliminates by design; it reveals nothing about EVPN route types or peer adjacencies. It is tempting because EVPN deployments still carry bridged traffic, so STP issues can disrupt forwarding, making this command correct when diagnosing legacy Layer 2 topology problems instead.

Incorrect MAC mobility sequence numbers.

Why it fails: MAC mobility sequence numbers handle host moves, not DF election stability.

Exceeding the maximum MAC address table limit.

Why it fails: MAC limits restrict learning size, not DF election roles.

Using VXLAN instead of MPLS data plane encapsulation.

Why it fails: Encapsulation type does not dictate DF algorithm stability; DF is a control-plane function.