A township public-works department needs PE VRF policy that controls which VPN routes are installed into a given VRF. Which MPLS L3VPN construct provides that import/export membership control?
Select an answer to reveal the explanation.
Short Explanation
Route targets are the guest list: export says what you publish from a VRF; import says what you will accept into it. That is how PE VRFs decide VPN route membership.
Full Explanation
A township public-works department that needs PE VRF policy controlling which VPN routes are installed into a given VRF is asking for route targets (RTs). RTs are BGP extended communities attached when a PE exports routes from a VRF into MP-BGP; import RTs on another VRF determine which of those VPN routes are accepted into the local VRF. That import/export membership control is how hub-spoke, full-mesh, or selective extranet L3VPN topologies are built for civic agencies.
Administrative distance values applied globally so all VPN routes prefer OSPF do not define VPN membership. AD influences preference among route sources in a table; it does not select which remote VPN prefixes are eligible to enter a VRF.
LDP session passwords that encrypt VPNv4 NLRI between PE routers confuse LDP authentication (protecting label distribution sessions) with MP-BGP VPN route policy. LDP passwords do not encrypt VPNv4 NLRI or perform RT import/export.
IP SLA probes that rewrite RDs whenever latency exceeds a civic threshold invent a behavior that is not how RT membership works. IP SLA measures performance; it does not rewrite RDs as VRF import policy.
Exam caveat: export RT vs import RT lists can differ; mismatched RTs are a top reason a VRF lacks remote sites. RD ≠ RT. Also know that route-maps can manipulate RTs for advanced designs.
Operational check: on the public-works VRF, show the configured import/export RTs; compare remote PE export RTs; show bgp vpnv4 and show ip route vrf to confirm imported prefixes. Fix membership with RT alignment before blaming LDP or AD.