Troubleshooting Scenario Questions

The VRF is missing the route-target export command.

Why it fails: The route-target export command is what attaches the route-target value to VPNv4 routes when the PE advertises them over MP-BGP. If export were missing, the remote PE would have no RT to match against its import list, and it would not install the routes into the VRF, so the PE could not ping remote sites. Since the PE can reach remote sites, the export RT must already be correctly configured, making this a false cause.

The PE router is not running a routing protocol with the CE router.

Why it fails: PE-CE connectivity in an L3VPN can use static routing as well as dynamic protocols such as OSPF, EIGRP, or BGP, so the absence of a dynamic routing protocol is not in itself a failure. As long as the CE has a static route pointing to the PE's VRF interface and the PE has a static route for the CE's subnet, traffic will flow. The observed symptom—CE unable to reach remote sites—points to the CE lacking any route toward the PE, not to a missing routing protocol.

The MPLS LDP is not enabled on the PE-CE link.

Why it fails: MPLS LDP is used to distribute labels for core transport between P and PE routers, and those labels carry VPNv4 traffic across the service provider backbone. The PE-CE link is a regular IP link that carries customer traffic, not an MPLS-labeled interface, so LDP on that link is neither required nor configured in a standard L3VPN. Therefore, this option describes a component that is irrelevant to the CE-to-PE forwarding failure.

SW2 has a lower priority than SW1, so it takes longer to become the root bridge after failure.

Why it fails: Incorrect because the root bridge election is decided by bridge priority, but the priority value has no effect on convergence timing. Rapid PVST+ uses RSTP's proposal/agreement mechanism to rapidly transition ports to forwarding, and this occurs in milliseconds regardless of which switch is elected root. A lower priority on SW2 would only make it more likely to be root under normal operation; it would never cause it to 'take longer' to become root after a failure, since convergence speed is determined by protocol state machines and timers, not by priority.

BPDU Guard is enabled on the uplink ports, which prevents BPDU exchange.

Why it fails: Incorrect because BPDU Guard is a PortFast security feature that error-disables a port the moment it receives any BPDU, to prevent unauthorized switches from participating in spanning tree. It does not filter, drop, or slow BPDU exchange while the link is up; rather, it shuts the port down completely, which would cause an immediate loss of connectivity, not a delay in convergence. On normal uplink ports BPDU Guard is not enabled, and even if it were, it would not alter the STP timers or slow down the root port failover process.

Loop Guard is enabled on the uplink ports, which delays port transition.

Why it fails: Incorrect because Loop Guard is designed to protect against unidirectional link failures by blocking a port that stops receiving BPDUs, placing it in a loop-inconsistent state. It does not add any artificial delay to the normal forwarding transition process; instead, it actively prevents a port from becoming designated when BPDUs are absent, which is a safety measure, not a timer-based delay. Loop Guard would only interfere after a BPDU loss and would block the port entirely, so it cannot explain the slower convergence caused by using legacy STP timers.

The WLC is configured with the wrong authentication port; RADIUS uses port 1645, not 1812.

Why it fails: This is incorrect because RADIUS authentication uses UDP port 1812 as the IANA-assigned standard port; port 1645 is a legacy alternative from early RADIUS implementations that has been deprecated due to conflicts with the datametrics service. More importantly, the server logs in the scenario show that the WLC's Access-Request messages are being received, which proves the WLC is sending to the correct destination port (1812). If the WLC were mistakenly configured for 1645, the requests would never reach the RADIUS listener on 1812, and no Access-Reject entries would appear in the server logs.

The WLC's RADIUS server configuration has the wrong shared secret, causing the server to reject requests.

Why it fails: Incorrect because the server logs show 'Access-Reject', which indicates the server received the request and processed it; a shared secret mismatch would typically result in no response or a 'Access-Challenge' but not necessarily a reject. However, the server could still reject if the secret is wrong, but the WLC would still see a response, not 'server not responding'.

The WLC is not configured with a valid management interface IP address to reach the RADIUS server.

Why it fails: This is incorrect because the RADIUS server logs show that it is receiving Access-Request packets from the WLC, which proves the WLC's management interface has a valid IP address and can route to the server. An invalid management interface IP (or missing route) would prevent the WLC from sourcing or sending any RADIUS traffic, so the server would see nothing at all. The real issue is asymmetric routing or a source-address mismatch: the server replies from a different IP than the configured RADIUS server address, causing the WLC to drop those responses and log 'server not responding'.

The AS-path contains the local AS number.

Why it fails: This is incorrect. While an AS-path containing the local AS number can cause routes to be rejected due to loop prevention, the typical symptom is routes not being received at all or being marked as invalid, not the specific 'received but not valid' status. The most common cause for 'not valid' is next-hop unreachability.

BGP synchronization is enabled.

Why it fails: This is incorrect. BGP synchronization is a legacy feature that requires the route to be in the IGP before it is advertised. In modern networks, synchronization is disabled by default. Even if enabled, it affects advertisement, not the validity of received routes in the BGP table.

The maximum-prefix limit has been exceeded.

Why it fails: This is incorrect. Exceeding the maximum-prefix limit typically causes the BGP session to reset or routes to be withdrawn, not to be marked as 'not valid' in the BGP table. Routes would likely be removed entirely, not just marked invalid.

The router's interface is configured with the no ip forward-protocol udp bootps command.

Why it fails: The `no ip forward-protocol udp bootps` command disables the forwarding of UDP broadcasts destined for BOOTPS/DHCP port 67 by the relay agent. However, the router here is acting as the DHCP server itself, not as a relay. A local DHCP server receives DHCPDISCOVER broadcasts natively on its directly connected interface, so this command has no effect on the server's ability to see those broadcasts. This option is incorrect because it targets the relay function rather than the local server reception.

The DHCP pool is configured with the wrong default-router option.

Why it fails: The `default-router` option in a DHCP pool sets the gateway address that the client will configure via the DHCPOFFER message. This option does not influence whether the router receives the DHCPDISCOVER or whether the server responds to it. A wrong default-router address would cause the client to have an incorrect gateway after obtaining an address, but it would not prevent the client from being assigned an IP. Therefore, this cannot explain a complete failure to receive broadcast messages.

The router's DHCP server is disabled globally with the no service dhcp command.

Why it fails: The global `no service dhcp` command disables both the DHCP server and relay functionality on the router. If this were the cause, the router would not respond to any DHCP requests, but when an engineer attempts to configure a DHCP pool, Cisco IOS displays an error like 'DHCP is disabled on this router' or requires the `service dhcp` command to be enabled. Since the pool is presumably configured and active, the service must be running, making this option unlikely. This option is incorrect because the failure mode would be immediately apparent during configuration, not a silent absence of DHCPDISCOVER reception.

The physical interface is configured with 'no ip address'.

Why it fails: The physical interface in a PPPoE configuration is intentionally left without an IP address. This interface operates at Layer 2 only and is used to encapsulate PPPoE frames via a dialer pool, while the dialer interface carries all Layer 3 addressing. IPCP assigns the IP address to the dialer interface, not to the physical Ethernet port. Therefore, seeing 'no ip address' on the physical interface is both expected and correct, and it is not the cause of the connectivity failure.

The default route is pointing to the wrong next-hop IP.

Why it fails: A default route in a PPPoE environment is typically configured with the dialer interface as the egress, using the form 'ip route 0.0.0.0 0.0.0.0 dialer 0' rather than a concrete next-hop IP. If the default route points to a specific next-hop IP, that IP would normally be the ISP gateway IP assigned during IPCP. However, because the dialer interface lacks an IP address, IPCP has not provided that next-hop value, and even a correctly pointed route cannot function. Thus the issue is not the route's target, but the missing IPCP address that makes any route unusable.

The ISP's gateway is not responding to ICMP.

Why it fails: While an unresponsive gateway could cause symptoms like this, it is not the root cause when the PPPoE session is already up. A PPPoE session being established confirms that the Ethernet link, PPP authentication, and LCP negotiation have succeeded, but ICMP requires IP-level routing and addressing. If the dialer interface has no IP address, the router cannot generate an ICMP echo request, so the gateway's response (or lack thereof) is irrelevant. The gateway is not the problem; the router's own missing IP address prevents it from participating in IP communication.

Check the output of 'show vlan id 10' to see if VLAN 10 is active and mapped to the VNI.

Why it fails: The 'show vlan id 10' command displays VLAN information, such as ports and status, but it does not show VNI mapping or EVPN route advertisement. While VLAN-to-VNI mapping is necessary for VXLAN, this command does not verify EVPN control plane operations. The engineer should focus on EVPN-specific commands to troubleshoot route advertisement.

Check the output of 'show interface nve1' to verify that the NVE interface is operational.

Why it fails: The 'show interface nve1' command provides status and statistics for the NVE interface, such as whether it is up and the source IP address. However, it does not show EVPN route advertisement or VNI-to-EVPN association. While it is useful for verifying the NVE interface state, it does not address the specific issue of EVPN route advertisement for a VNI.

Check the output of 'show nve vni' to see if the VNI is up and associated with the NVE interface.

Why it fails: The 'show nve vni' command displays the status of VNIs and their mapping to VLANs, but it does not directly show EVPN route advertisement. While it can confirm that the VNI is up, it does not verify the EVPN control plane association. The engineer needs to check EVPN route advertisement specifically, so this command alone is insufficient.

The RP is not configured as the DR on its segment.

Why it fails: The Designated Router (DR) on a segment is responsible only for sending PIM register messages on behalf of a directly connected source, not for selecting the tree used by other routers. The RP's DR status on its own segment has no bearing on whether last-hop routers use the SPT or the shared tree. In this scenario, the issue is purely a tree-switching delay, not any DR misconfiguration on the RP's link.

The multicast source is using a different group address.

Why it fails: If the source were sending to a different group address, the last-hop router wouldn't receive those packets at all—they'd be dropped because the router has no group state for that other group. The fact that traffic is flowing at all, albeit via the RP, proves the group address is correctly matched. This option incorrectly conflates the tree type with group addressing; the group address is consistent, and the actual problem is the absence of an SPT switchover.

The last-hop router has a higher metric to the source than to the RP.

Why it fails: The SPT switchover in PIM-SM is triggered by the first packet arriving at the last-hop router, or by the spt-threshold configuration—not by any comparison of unicast metrics to the source versus the RP. Even if the metric to the source is higher, PIM defaults to switching to the SPT anyway, and a higher metric would only delay the switch if a policy like spt-threshold were in place. Thus, a metric difference alone cannot explain why the traffic remains on the shared tree.

The priority queue is not configured with a bandwidth statement.

Why it fails: This is incorrect because, in LLQ, the priority queue is always configured with a bandwidth statement via the `priority` command. A missing bandwidth statement would make the configuration invalid or cause the class to be treated as a normal class, not a priority queue. The drops in question are due to the implicit policer that is activated when the priority bandwidth is assigned, not because of a missing statement. Thus, the problem is traffic exceeding the configured bandwidth, not the absence of a bandwidth value.

The class-map is not matching voice traffic correctly.

Why it fails: This is not the cause. The scenario explicitly states that drops are occurring in the priority queue, which proves that voice traffic is being matched and placed into that queue. If the class-map were misconfigured, voice traffic would be classified into a different queue (such as the default class) and would not experience policer drops. The fact that the drops happen at the priority queue indicates the matching is working correctly; the issue lies in the policer's configured bandwidth threshold.

The router is using FIFO queuing instead of LLQ.

Why it fails: This is incorrect because LLQ is indeed in operation, as evidenced by the policer dropping excess traffic. FIFO queuing has no built-in policer; drops under FIFO occur only through tail drop when the interface buffer is full, not based on a configured bandwidth. The scenario describes drops specifically due to policing, which is a signature feature of LLQ's priority queue. Therefore, the queuing mechanism is correctly identified as LLQ, and the drops are not caused by using FIFO instead.

The OSPF adjacency between PE1 and CE1 is down.

Why it fails: An OSPF adjacency failure would prevent the PE from learning CE routes in the first place, so the VRF routing table would not contain the missing prefix as an OSPF route. The scenario explicitly indicates the route is present in the VRF, which proves that the OSPF hello/DBD/LSU process has completed and the neighbor is in the Full state. Therefore, an adjacency-down condition cannot explain why an already-installed VRF route is absent from BGP.

The VRF forwarding table on PE1 is full.

Why it fails: A full VRF forwarding table is an FIB/CEF resource issue and would affect how packets are forwarded or whether a new route can be programmed into the data plane, not whether that route exists in the BGP VPNv4 table. In L3VPN operation, VPNv4 advertisement is driven by the VRF routing table and the redistribution policy under BGP, not by the size or capacity of the VRF forwarding table. If the route already appears in the VRF RIB, there is no capacity-related reason it cannot also be redistributed into BGP.

MPLS LDP is not enabled on the PE1-CE1 link.

Why it fails: LDP on the PE-CE link is nonsensical in a standard L3VPN design because LDP typically allocates labels for IGP routes across the MPLS core (P-to-P and PE-to-P interfaces), while the PE-to-CE link runs a plain IP routing protocol such as OSPF. VPNv4 prefixes are carried end-to-end in MP-BGP, which also allocates the inner VPN label; any core label needed for transport is handled by LDP or segment routing inside the service provider backbone. Missing LDP on the access link therefore has nothing to do with the failure to redistribute OSPF VRF routes into BGP on PE1.

VTP pruning has removed VLAN 10 from the trunk.

Why it fails: VTP pruning would remove VLAN 10 from the trunk's allowed list only when no active access port exists for that VLAN on the downstream switch, and this would be visible with show interface trunk. If VLAN 10 still appears in the allowed list on the trunk, pruning has not occurred; the failure is due to the VLAN not being defined in the VLAN database on one switch. VTP pruning cannot remove a VLAN from the database itself—it only controls which VLANs are permitted on specific trunk links.

The native VLAN is mismatched.

Why it fails: A native VLAN mismatch appears on an 802.1Q trunk when the two ends are configured with different untagged VLAN IDs. This condition triggers CDP error messages and can put the trunk into an inconsistent state, but it affects only untagged traffic on the native VLAN, not a tagged VLAN such as VLAN 10. Since the problem is specific to VLAN 10 and other VLANs are presumably passing, native VLAN mismatch is not a valid explanation.

Spanning Tree Protocol is blocking VLAN 10 on the trunk.

Why it fails: While STP can block a VLAN on a trunk in PVST+ or Rapid PVST+, it does so only when a loop or redundant path exists for that VLAN. A single trunk link without an alternative path is not placed in a blocking state for one VLAN, and the port would remain forwarding for all other VLANs. Additionally, STP blocking would not hide a missing VLAN database entry—it would still show VLAN 10 as defined but in a discarding state, which is not the situation described.

The switch has DHCPv6 snooping enabled, which conflicts with RA guard.

Why it fails: DHCPv6 snooping and RA guard are complementary IPv6 security mechanisms that do not conflict when enabled together. DHCPv6 snooping inspects DHCPv6 messages to build a binding table and prevents rogue DHCPv6 servers, whereas RA guard inspects ICMPv6 Router Advertisements to block unauthorized routers. These features operate on different protocols and layers of the IPv6 stack, so enabling both is a recommended defense-in-depth approach rather than a source of failure. The issue described would still occur even if DHCPv6 snooping were absent, indicating RA guard itself is the culprit.

SLAAC requires the host to send a router solicitation first, which is being blocked by RA guard.

Why it fails: RA guard is designed to filter Router Advertisements (RAs), not Router Solicitations (RSs). In normal SLAAC operation, a host first sends an RS to the all-routers multicast address to elicit an RA from a legitimate router; RA guard does not inspect or block RS traffic. Even if RA guard were aggressively filtering, it would not prevent the host from sending RSs — it only drops the unsolicited or matching RAs. Thus, the problem is not that RSs are blocked, but that the router's RA is discarded by the RA guard policy.

RA guard is configured in 'block' mode, which drops all RAs regardless of the policy.

Why it fails: RA guard is a policy-based mechanism that permits or denies RAs based on configured criteria such as trusted ports, device roles, or explicit addresses; there is no standard 'block' mode that indiscriminately drops every RA while keeping RA guard enabled. If the switch were dropping all RAs regardless of policy, it would more likely be an ACL or a disabled RA forwarding setting, not RA guard itself. Even in 'block' or 'protect' style implementations, the action is applied per-policy and still relies on matching the configured authorized source addresses. Therefore, the answer lies in the policy's missing gateway entry, not a global block mode.

The access list used for NAT does not permit the web server's IP address.

Why it fails: An ACL referenced in a NAT configuration (e.g., ip nat inside source list) serves only to match inside local addresses for dynamic translation. Static NAT entries are created with an explicit ip nat inside source static command and are never filtered by an ACL. Therefore, even if the ACL denied the web server's address, it would have no bearing on a static mapping; the inability to reach the web server is due solely to the missing static entry.

The ip nat inside and ip nat outside commands are applied on the wrong interfaces.

Why it fails: If ip nat inside and ip nat outside were swapped on the interfaces, the router would fail to correctly translate traffic for all hosts, and outbound sessions would typically break as well. The scenario focuses on a single internal web server being unreachable from outside, which indicates a missing static mapping rather than a global interface configuration error. Correct interface placement is a prerequisite, but the specific symptom of only the web server failing points to the absence of the static NAT command, not to misapplied interface directives.

The global configuration mode is missing the ip nat pool command.

Why it fails: An ip nat pool defines a range of global addresses for use with dynamic NAT or PAT, typically paired with a source ACL in a command like ip nat inside source list <acl> pool <name>. Static NAT, which is what a web server requires for inbound access, does not involve a pool; it uses the ip nat inside source static command to map one specific inside local address to one inside global address. The absence of a pool is irrelevant because static NAT never references a pool, so this cannot explain why the web server is unreachable.

The load-balancing method is set to src-mac, and the traffic is from multiple MAC addresses.

Why it fails: With the src-mac load-balancing algorithm, the EtherChannel hash is computed solely from the source MAC address. If traffic originates from multiple distinct MAC addresses, those frames produce different hash values and are distributed across different member links, not all on one link. Therefore, this scenario cannot explain why all traffic is traversing a single port.

The physical ports have different speeds.

Why it fails: If member ports operated at different speeds, the EtherChannel would not form correctly; Cisco switches require all ports in a channel to have matching speed and duplex settings. Ports with mismatched speeds would be excluded from the bundle or the channel would fail, rather than the channel staying up and simply sending all traffic on the fastest port. Since the port-channel is operational, speed mismatch is not the underlying cause.

The port-channel is configured with 'lacp fast-switchover'.

Why it fails: The 'lacp fast-switchover' feature reduces the time needed to move traffic to a hot-standby port when an active port fails; it does not alter the load-balancing hash or influence how traffic is initially distributed across links. It is a failover optimization for LACP EtherChannels, not a mechanism that changes steady-state forwarding behavior. Hence, it cannot be responsible for single-link congestion.

Use the same VLAN for all tenants and rely on VLAN ACLs.

Why it fails: VLAN ACLs operate at Layer 2 and filter traffic within a broadcast domain; they cannot maintain separate routing tables or forwarding decisions per tenant. If all tenants share the same VLAN, their IP subnets and MAC addresses are visible to one another at the data-link layer, and VACLs cannot prevent ARP spoofing or other L2 attacks. Moreover, VACLs cannot resolve overlapping IP address spaces because they rely on a single L3 forwarding context, so the isolation required for multi-tenancy is fundamentally unavailable.

Configure static routes on each switch pointing to the next-hop IP in the global routing table.

Why it fails: Static routes placed in the global routing table are unaware of VRFs and cannot direct traffic that arrives on a VRF-aware interface. Even if the route points to a valid next hop in the global table, packets from a VRF will be dropped because the VRF's routing table has no corresponding route or because the next hop is not reachable from that VRF's context. Additionally, with overlapping subscriber addresses, a single global route is ambiguous and cannot select the correct egress interface. The fix would be to define separate static routes inside each VRF, not in the global table.

Enable OSPF with a single area on all switches and redistribute between VRFs.

Why it fails: OSPF running in a single area without VRF-aware configuration builds one LSDB and one SPF tree for the entire device, so it cannot distinguish tenant A's routes from tenant B's routes. Redistribution between VRFs is not a native OSPF feature; it requires route leaking between VRFs, which violates the isolation VRFs are meant to enforce and can cause routing loops if not carefully filtered. Furthermore, OSPF's router ID and neighbor relationships are global by default, so you cannot run multiple independent OSPF instances for each tenant without enabling VRF-lite (per-VRF OSPF process). Therefore, a single-area OSPF approach cannot provide the per-tenant segregation this multi-tenant network demands.