Retail L3VPN: Firewall-Inspected Data but Direct Store-to-Store Voice
A retail customer buys MPLS L3VPN for 620 stores, one hub data center with a firewall, and a shared-services VRF hosting DNS, NTP, and PCI logging. Stores attach to three regional PEs and run eBGP to the PE. The contract states three requirements: all store-to-store data traffic must transit the hub firewall for inspection; SIP and RTP between stores must take the direct PE-to-PE path because the hub adds 35 ms against a 40 ms latency budget; and every store must reach shared services. No store may reach another customer's VRF. The customer's CE cannot run VRF-lite on the data path but will accept two subinterfaces with one BGP session each. The provider backbone is MPLS L3VPN with RT constraint enabled on the route reflectors. Only IPv4 is in scope.
1. Write the route-target and route-distinguisher plan, and explain precisely why it produces hub-and-spoke for data but any-to-any for voice.
Read the worked answer
Use three VRFs per PE: DATA_SPOKE (stores), DATA_HUB (data center), VOICE (stores), plus SHARED for services, with RTs of the form ASN:nn so they cannot collide with another customer.
- DATA_SPOKE: export 65001:1001, import 65001:1002 (hub) and 65001:1099 (shared).
- DATA_HUB: export 65001:1002, import 65001:1001 and 65001:1099.
- VOICE: export and import 65001:2001, plus import 65001:1099.
- SHARED: export 65001:1099, import 65001:1001, 65001:1002, 65001:2001.
The mechanism is import matching, not filtering. A store PE receives a data route from another store tagged 65001:1001; DATA_SPOKE does not import 1001, so the route never enters that VRF's RIB and the store can only reach peers through the hub, which does import 1001 and re-advertises into 1002. VOICE imports its own RT, so every store learns every other store's voice prefix directly over the PE-to-PE path.
RDs must be unique per VRF per PE: use the PE loopback address plus a VRF index (192.0.2.7:101). RD uniqueness matters because the same store subnet can appear in both DATA_SPOKE and VOICE, and identical RDs would make them indistinguishable VPNv4 routes.
RT constraint means PEs advertise only RTs they import, so the RRs stop forwarding VOICE routes to VRFs that never import them; this keeps the 620-store VPN table manageable.
2. The customer accepts two CE subinterfaces and two BGP sessions. Explain how you keep data and voice traffic in the correct VRF on the CE, and what misconfiguration would silently defeat the whole design.
Read the worked answer
The CE must treat the two subinterfaces as separate routing contexts, not two links into one table. Each subinterface gets its own VRF (or a VRF-aware BGP instance), its own address family, and its own default route pointing at the PE next hop inside that VRF. The store LAN is then attached so that data subnets select the DATA_SPOKE instance and voice endpoints select the VOICE instance; this is normally done with a VRF-aware static or a policy route on the CE matching the voice VLAN and the SIP/RTP destination ranges.
The silent failure modes are all leaks between contexts:
- One BGP session importing both families into a single CE table, so the store installs the direct voice path for data prefixes or vice versa. The symptom is subtle: everything pings, but inspection is bypassed.
- A default route in DATA_SPOKE learned from the hub that is more specific than the leaked hub summary, which is fine, but a default in VOICE learned from the hub would pull voice back through the firewall and blow the latency budget. Verify that the voice VRF's only path to another store is the PE-to-PE route.
- Redistributing one VRF into the other on the CE for "convenience".
Verify from the provider side: on the originating PE, show bgp vrf VOICE must show the remote store prefix with the remote PE as next hop, and show bgp vrf DATA_SPOKE must not contain that prefix at all. Trace the data path with a TTL-limited ping to prove it crosses the hub firewall.
3. The customer asks whether a single VRF with per-prefix route targets could satisfy both requirements and save a VRF. Assess that option honestly.
Read the worked answer
It can be made to work in a lab and is a poor operational choice in production.
Mechanically, you would attach RTs per prefix with outbound route-maps: voice prefixes get 65001:2001 and data prefixes get 65001:1001. All store VRFs import 65001:2001 and 65001:1002 (hub), and the hub exports 65001:1002. Stores would then accept the direct voice prefix and reach data only via the hub. That satisfies both policies with one VRF per PE.
The problems are practical:
- Policy is now per-prefix and lives in route-maps that must stay in sync with the customer's addressing plan on three PEs and every future site. Adding a voice subnet without updating the map silently sends voice through the firewall.
- Both paths exist in one VRF's RIB, so BGP bestpath decides. If the hub ever advertises a voice prefix with a better local preference or shorter AS path, the direct path loses and latency degrades without any visible fault.
- The CE has a single routing table, so the store itself cannot enforce which traffic uses which path; you have removed the CE-side control that the two-VRF design provides.
- RT changes require route refresh across the VPN, and RT constraint means every change ripples to the RRs.
Recommend the two-VRF design and price the extra VRF honestly: it is one more BGP session and one more import policy per PE, and it makes the latency requirement a structural fact rather than a route-map accident.