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

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.

MSTP boundary ports drop all RSTP BPDUs and treat the link as a point-to-point blocked topology.

Why it fails: MSTP boundary ports transmit and receive RSTP BPDUs, mapping the region's CIST onto the common spanning tree rather than discarding them. Dropping BPDUs would break loop detection. The option tempts those picturing hard isolation, but interoperability, not blockage, defines boundary behaviour.

The entire MSTP region converts its configuration digest to match the RSTP region's default region name.

Why it fails: MSTP regions retain their own configuration digest and region name; only the CIST interoperates with RSTP at boundary ports, so no digest conversion occurs. The option tempts engineers who assume regions must harmonise, yet region identity is deliberately independent to preserve internal topology.

MSTP isolates the RSTP region into a separate MSTI instance automatically.

Why it fails: MSTP maps the RSTP region into the CIST, not a dedicated MSTI; MSTIs are configured internally and never auto-created for external regions. The option tempts engineers expecting automatic segregation, but RSTP switches lack MSTI awareness, so they participate only in the common instance.

An incorrect IGMPv2 timer setting on the receiver VLAN

Why it fails: IGMP timers affect host membership reports, not MSDP peering.

An invalid PIM dense-mode setting on the core interface

Why it fails: PIM dense-mode is unrelated to MSDP TCP session establishment.

Disable LLDP-MED globally to force all phones to draw maximum class power.

Why it fails: Disabling LLDP-MED removes power negotiation, so powered devices fall back to a default class and may draw more power, worsening the deficit. LLDP-MED is tempting because it manages voice VLAN and PoE negotiation, but disabling it increases consumption rather than reducing the budget shortfall.

Enable RSTP root guard on all voice interfaces.

Why it fails: RSTP root guard prevents a switch port from becoming the spanning-tree root, which addresses Layer 2 topology hijacking and has no bearing on PoE power allocation. It is tempting because it is a legitimate access-port hardening feature, but it neither reduces power draw nor increases the switch's available power budget.

Convert all access ports to trunk ports.

Why it fails: Converting access ports to trunk ports changes VLAN tagging behaviour and does not alter PoE class negotiation or the switch's power budget. Trunking is tempting because it is a common access-layer configuration change, but it addresses frame handling, not the power deficit causing devices to fail to power up.

show interfaces ge-0/0/10 extensive

Why it fails: This command provides detailed interface statistics and error counters for the physical and logical interface. While it can confirm link state, it does not expose 802.1X protocol state or EAPOL message counts. It would not explain why the switch is not sending RADIUS requests after starting EAPOL exchanges.

show network-access aaa statistics radius

Why it fails: This command shows RADIUS client statistics such as requests sent, retransmissions, and responses received. It is useful when RADIUS traffic is occurring, but in this scenario the switch is not even sending Access-Requests. It would show zero requests and not reveal why EAPOL is stalled at the supplicant level.

show ethernet-switching table

Why it fails: This command displays the MAC address forwarding table and learned entries. It does not show 802.1X authentication state or EAPOL counters, so it cannot indicate why authentication is not progressing. It would be relevant for forwarding or MAC learning issues, not for diagnosing the EAPOL exchange stall.

The policer is applied to the egress interface, and egress policers do not drop packets that exceed the rate.

Why it fails: Egress policers do drop packets that exceed the configured rate, although they are less common than ingress policers. The statement is incorrect because egress policers enforce rate limits just like ingress policers. The observed behavior of no drops during short bursts is due to the burst size, not the direction of the policer.

The policer is misconfigured because it should drop all traffic that exceeds 100 Mbps immediately.

Why it fails: A policer does not necessarily drop all traffic that exceeds the committed rate immediately. It uses a token bucket algorithm that allows bursts up to the burst size. Only when the burst size is exhausted are packets dropped. Therefore, the policer is not misconfigured; it is behaving as designed.

The policer is configured as a two-rate three-color policer, which allows traffic to exceed the committed rate without penalty.

Why it fails: A two-rate three-color policer has a committed rate and a peak rate. Traffic between the committed and peak rates is marked as yellow (medium loss priority) and may be dropped depending on congestion, but it is not exempt from policing. The scenario describes traffic exceeding the committed rate without dropping, which is more characteristic of a single-rate policer with burst allowance.

show evpn instance extensive

Why it fails: This command provides details about the EVPN instance, such as route tables and VNI information, but it does not specifically show DF election state for Ethernet segments. While useful for overall EVPN troubleshooting, it lacks the granular DF information needed here. Therefore, it is not the best choice for verifying DF election.

show ethernet-switching table

Why it fails: This command displays the MAC address table for Ethernet switching, which can show locally learned MACs but not EVPN DF election state. It is useful for verifying MAC learning but does not address DF election. In an EVPN context, the MAC table may not reflect remote MACs learned via BGP, and it certainly does not show DF status.

show bgp evpn summary

Why it fails: This command shows BGP EVPN neighbor summary and route counts, which helps verify BGP session health but does not provide DF election details. It is not relevant to the DF election process. The issue described is about DF election, so this command would not provide the necessary information.