BGP with MPLS L3VPN · Lesson 01 of 01
Carrying customer routes with VPNv4
In an MPLS L3VPN, BGP is the control plane that keeps every customer's routes separate while sharing one provider core.
Written lesson
RD makes routes unique, RT moves them
Two customers can both use 10.0.0.0/8. To keep them apart across one core, each PE prepends a Route Distinguisher to the prefix, making a globally unique VPNv4 route (RD:10.0.0.0/8). The RD only guarantees uniqueness. What decides which VRF a route lands in is the Route Target — an extended community attached on export and matched on import. Export RT 65001:100 on one PE, import RT 65001:100 on another, and the route joins that VRF. RD identifies; RT distributes.
Configuration
A VRF with RD and RTs
vrf definition CUST-A
rd 65001:100
address-family ipv4
route-target export 65001:100
route-target import 65001:100
!
router bgp 65001
address-family vpnv4
neighbor 10.0.0.2 activate
neighbor 10.0.0.2 send-community extendedWritten lesson
PE-CE and the tricky bits
Between the provider PE and the customer CE, BGP (or another protocol) exchanges the customer's own routes. Two traps recur. When several sites share one AS, the CE rejects routes carrying its own AS — as-override (on the PE) or allowas-in (on the CE) works around it. And a route that leaves a site and could loop back is guarded by Site of Origin (SoO), an extended community that marks where a route entered so it is not sent back out the same site.
send-community extended, again
VPNv4 troubleshooting almost always starts here: routes are exported with an RT, the VPNv4 session is up, but the far PE imports nothing — because send-community extended was missing and the RT never travelled. Check it before anything deeper.