Route Target Added with Both Flags Leaks All Spoke Prefixes
An enterprise runs BGP/MPLS L3VPN over AS 65000 with PE-1, PE-2, PE-3 and a route reflector. Security policy requires all inter-site traffic to pass through a firewall attached to PE-1 in VRF HUB. The spoke VRFs on PE-2 and PE-3 export unique route targets 65000:12 and 65000:13 and import only 65000:1. The HUB VRF exports 65000:1 and imports 65000:12 and 65000:13.
A new backup service prefix 10.99.0.0/24 is attached to PE-1 in VRF SVC. The requirement is that only this prefix be reachable directly from the spoke VRFs, without crossing the hub firewall.
Under change control, the engineer added vpn-target 65000:99 both to VRF SPOKE-A on PE-2, VRF SPOKE-B on PE-3 and VRF SVC on PE-1.
Two days later the firewall team reports a 70% drop in inter-site sessions. On PE-2, display ip routing-table vpn-instance SPOKE-A shows 10.22.0.0/24, a SPOKE-B subnet, with next hop 10.255.0.3, PE-3's loopback, instead of the hub. The backup service works, but so does everything else.
1. Explain why adding the route target to the spoke VRFs leaked every spoke prefix, not just the service prefix.
Read the worked answer
A route target is an extended community attached to VPNv4 routes at export and matched at import. The key point is granularity: vpn-target is configured per VRF and is applied to every route that VRF exports or imports. It is not a prefix filter.
Using both added 65000:99 to the export list of SPOKE-A and SPOKE-B as well as to their import lists. From that moment, every prefix exported from SPOKE-A carried 65000:1, 65000:12 and 65000:99, and every prefix from SPOKE-B carried 65000:1, 65000:13 and 65000:99. Because each spoke imported 65000:99, each accepted the other spoke's entire prefix set. The hub firewall was bypassed by the more specific direct VPN routes, which is consistent with the 70% session drop.
Retracing the path: PE-2 exports 10.22.0.0/24 with RT 65000:13 and 65000:99, the RR reflects it, PE-2's SPOKE-A VRF imports 65000:99 and installs it with next hop PE-3. Nothing about 10.22.0.0/24 itself changed; only the community attached to it did.
2. Give the corrected design and configuration approach, and say why the simple version is preferable.
Read the worked answer
The service prefix needs to be exported with 65000:99 by one VRF, and imported with 65000:99 by the spoke VRFs. No spoke VRF should export 65000:99.
Correct configuration:
- On PE-1, VRF SVC:
vpn-target 65000:99 export-extcommunityand its existing import targets. - On PE-2 and PE-3, in SPOKE-A and SPOKE-B:
vpn-target 65000:99 import-extcommunityonly, keeping their existing export targets unchanged.
Now only 10.99.0.0/24 carries 65000:99, so only that prefix is imported by the spokes and all other spoke traffic continues to use the hub path and the firewall.
A route-policy can also apply an RT to a specific prefix with apply extcommunity rt 65000:99 additive, but it is applied in the VPNv4 context on that PE and must match the prefix and the correct RD or it will tag unintended routes. The import-only design is simpler, auditable and hard to break during later changes. If a spoke later needs to export a service-specific prefix, create a separate VRF rather than mixing directions in the transit VRF.
3. How would you verify the fix and clean up the already-leaked routes?
Read the worked answer
Verification sequence:
display ip vpn-instance verboseon PE-1, PE-2 and PE-3 to confirm 65000:99 appears only as an import target on the spokes and only as an export target on SVC.display bgp vpnv4 vpn-instance SPOKE-A routing-table 10.22.0.0on PE-2 to confirm the extended community no longer includes 65000:99, and the same command for a service prefix to confirm it does.display ip routing-table vpn-instance SPOKE-Ato confirm hub-path next hops are restored and 10.99.0.0/24 remains direct.
Cleanup: after removing the export target, the previously advertised routes still carry the old community until they are re-advertised. Perform a VPNv4 soft reset or refresh toward the RR, then re-check. Confirm the firewall session count and throughput return to baseline, and keep the change record showing the direction of each target. As a control, add a pre-change check that lists every VRF importing and exporting the new target, so a both keyword cannot be applied without a second pair of eyes.