A received VPN route is absent from the customer VRF
A fictional provider edge has an established relevant multiprotocol BGP session and receives a VPN route from a remote edge. Supplied records show that the route carries an export target not accepted by the intended local VRF import policy. The underlay can reach the remote edge, but the customer cannot use that prefix. A colleague proposes placing every customer route in the global table to restore reachability. Another separates transport reachability, received VPN information and deliberate import policy. This exercise changes no routing or policy. It asks the learner to identify the missing stage while preserving customer separation and to avoid interpreting an established session as proof that the intended service route is available.
1. Which stage is not satisfied?
Read the worked answer
The received VPN route does not meet the intended local VRF import policy under the supplied target configuration. Underlay reachability and BGP reception do not replace that import decision.
2. What should an authorized review preserve?
Read the worked answer
Confirm the intended customer/service policy, targets, VRF and return path. Correct only a justified policy error through the approved workflow rather than leak all customer routes into the global table.