A network engineer is configuring MPLS L3VPN on a Cisco IOS-XE router. The VRF CUSTOMER_C has route-target import 300:1 and export 300:1. The PE receives VPNv4 routes from the route reflector, but the CE router connected to the PE cannot ping any remote site IP addresses. The PE can ping the remote site IP addresses from the VRF. What is the most likely cause?
Trap 1: The VRF is missing the route-target export command.
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.
Trap 2: The PE router is not running a routing protocol with the CE router.
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.
Trap 3: The MPLS LDP is not enabled on the PE-CE link.
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.
- A
The CE router does not have a default route pointing to the PE's VRF interface.
In an MPLS L3VPN, the CE router must have a route—either a default route or a specific prefix—that points toward the PE's VRF-facing interface as the next hop. Without such a route, the CE cannot forward packets to the PE for remote VPN destinations, so pings from the CE fail. The PE can still ping remote sites because its VRF routing table contains the remote VPNv4 routes, which proves the problem is the CE's missing next hop rather than the PE's VRF configuration.
- B
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.
- C
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.
- D
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.