Troubleshooting Scenario Questions

MTU mismatch between the interfaces

Why wrong: MTU mismatch causes OSPF packets to be silently dropped, but the adjacency may still reach the EXCHANGE state before failing.

Passive interface configuration on one router

Why wrong: Passive interface prevents sending hellos, so the neighbor would not be discovered at all.

Area ID mismatch on the interfaces

Why wrong: Area ID mismatch would result in a different area and the adjacency would not form due to area mismatch.

The core routers use LDP labels and ignore DSCP

Why wrong: LDP doesn't process DSCP; DSCP remarking must be due to a policy.

The ingress PE did not set MPLS EXP bits

Why wrong: The problem is DSCP being cleared, not MPLS EXP.

The MPLS EXP bits are not copied from DSCP

Why wrong: MPLS EXP bits are often copied from DSCP, but this does not cause DSCP to become 0.

Spanning Tree Protocol (STP)

Why wrong: STP runs on CE devices, not PEs.

Rapid Spanning Tree Protocol (RSTP)

Why wrong: Same as above.

MAC address aging

Why wrong: MAC aging removes stale entries but does not prevent loops.

The BGP neighbor is not activated under the VPLS address-family

Why wrong: Incorrect. If BGP L2VPN routes are exchanged, the neighbor is activated under the VPLS address-family.

The MTU mismatch between PEs

Why wrong: Incorrect. MTU mismatch would cause pseudowire status to show 'MTU mismatch' or similar, but the pseudowire may still be up.

The VFI name is not consistent across PEs

Why wrong: Incorrect. VFI names are locally significant; they do not need to match across PEs.

show mpls interface

Why wrong: Shows interfaces enabled for MPLS, not forwarding entries.

show mpls ldp neighbor

Why wrong: Shows LDP neighbors, not forwarding details.

show ip route 10.1.1.0

Why wrong: Shows IP routing table, not MPLS forwarding.

Check the MTU size on all interfaces.

Why wrong: MTU issues can cause problems but are not the first step.

Reboot all routers to reset LDP sessions.

Why wrong: Rebooting is drastic and not a diagnostic step.

Verify that OSPF neighbor relationships are established.

Why wrong: LDP relies on reachability, but OSPF is not directly checked for LDP.

The device has a feature license missing for QoS

Why wrong: Missing licenses typically generate clear error messages and would prevent the policy from being configured.

The policy-map name conflicts with an existing one

Why wrong: A name conflict would cause an error during push, making it obvious.

Narrow metrics are used only for L1 routes, while TE metrics are used for L2.

Why wrong: Both metric types can apply to L1 and L2; narrow metrics are not limited to L1.

TE metrics override narrow metrics for SPF calculations.

Why wrong: TE metrics are not used for SPF; they are for TE path computation.

TE metrics are used by default when metric-style wide is configured.

Why wrong: TE metrics are always separate; wide metric style does not automatically set TE metrics.

The CCM interval is too long, causing delayed detection.

Why wrong: Incorrect. A too-long interval would cause slower detection, not frequent false switches.

The working path uses a higher MPLS-TP OAM rate than the protection path.

Why wrong: Incorrect. OAM rates are typically symmetrical and not a standard cause of false failures.

The protection path has a lower priority than the working path.

Why wrong: Incorrect. Priority settings do not cause false CCM loss.

The tunnel interface has an IP address.

Why wrong: Tunnel interfaces can have IP.

The destination loopback is not advertised in IGP.

Why wrong: Not directly preventing tunnel.

The path includes a router that does not support MPLS.

Why wrong: Could still be signalled if not using MPLS? Actually RSVP needs MPLS for label switching; but E might be true if MPLS not enabled. But better: not directly specified.

BGP next-hop-self is not configured on the PE

Why wrong: Next-hop-self changes the next-hop in BGP updates, but the next-hop is already the remote PE.

The VRF route-target import/export is misconfigured

Why wrong: Misconfigured RT would prevent the route from being in the VRF.

The PE router does not have an LSP to the remote PE

Why wrong: LSP existence is a consequence of LDP; this answer is less specific.

The headend router does not have the SR-TE policy configured with the correct path

Why wrong: The policy is configured; the issue is path computation, not policy configuration.

The PCE is not reachable from the headend router

Why wrong: If unreachable, no path could be computed at all; the scenario describes a specific failure with red affinity.

The SR-TE policy is configured with a strict explicit path that conflicts with the constraint

Why wrong: Explicit path would override constraint; but the policy likely uses dynamic path computation.

The red affinity is not properly configured in the network

Why wrong: The affinities are assigned, but PCE may not have them in its database.

The policy-map is applied to a loopback interface

Why wrong: Loopback interfaces do not carry real traffic; packets are not forwarded through them.

The marking is configured under the wrong policy-map

Why wrong: If marking is in the wrong policy, that policy might not even be applied to the interface.

The device is running out of TCAM space

Why wrong: TCAM exhaustion would affect performance but would not silently cause missing markings; errors would appear.

The police rate is configured in bits per second but the traffic is measured in bytes per second

Why wrong: This would cause a factor of 8, not 2, difference between configured and observed rates.

The traffic is using a different DSCP value than expected

Why wrong: If the traffic is not matched by the class, it would be handled by class-default and not be subject to the police, so no drops would occur.

The police action is set to drop, but the exceed-action is transmit

Why wrong: If exceed-action were transmit, no packets would be dropped; the observed drop rate would be zero.

The MTU on the core links is less than 1500

Why wrong: MTU mismatch would cause fragmentation, but pseudowire would still be up.

The control word is enabled on one PE but not the other

Why wrong: Control word mismatch can cause issues, but typically the pseudowire would be up with errors.

The encapsulation type on the AC is different on the two PEs

Why wrong: Encapsulation must match, but both are probably Ethernet, and the question implies it's up.