The problem statement built an industry: carry thousands of customers over one IP backbone, where every customer believes 10.0.0.0/8 is theirs alone, no customer may ever see another's routes, and the provider's core routers must not carry customer routing state. RFC 4364's answer — BGP to carry customer routes between edges, MPLS to forward through a customer-blind core — is the architecture, and it rests on three constructs that must be kept distinct: the VRF, the route distinguisher, and the route target.
VRF: the per-customer router inside the router
A VRF (Virtual Routing and Forwarding instance) is a separate routing table, FIB and set of interfaces on a PE router. The interface facing customer A's site lives in VRF A; routes learned there go into VRF A's table and nowhere else. The customer edge router (CE) speaks ordinary routing — static, OSPF, EIGRP or, most commonly, eBGP — toward the PE and has no idea VRFs exist. Isolation at the edge is that simple: separate tables, separate worlds. The interesting problems are all in the middle: how VRF A's routes cross the core to reach VRF A on other PEs.
PE1(config)# vrf definition CUST-APE1(config-vrf)# rd 65000:101PE1(config-vrf)# address-family ipv4PE1(config-vrf-af)# route-target export 65000:101PE1(config-vrf-af)# route-target import 65000:101PE1(config)# interface gi0/2PE1(config-if)# vrf forwarding CUST-APE1(config-if)# ip address 192.168.1.1 255.255.255.252
RD: making overlap survivable
Customer A's 10.1.0.0/16 and customer B's 10.1.0.0/16 cannot coexist in one BGP table — so they do not. Each VRF is assigned a route distinguisher, an 8-byte value (written like 65000:101) that BGP prepends to every prefix from that VRF, forming a VPNv4 route: 65000:101:10.1.0.0/16 and 65000:102:10.1.0.0/16 are now different routes, propagating independently through the same BGP sessions. That is the RD's whole job — uniqueness. It carries no policy, decides nothing about who imports what, and two sites of the same VPN may use different RDs (deliberately so, in multihomed designs, so both PEs' paths survive route reflection distinctly).
RT: the actual VPN membership
Route targets define the VPN. An RT is a BGP extended community; each VRF exports its routes stamped with configured RTs, and each VRF imports any VPNv4 route carrying an RT on its import list. Any-to-any VPN: every site exports and imports 65000:101. Hub-and-spoke: spokes export 65000:201 and import 65000:200, the hub does the reverse — spokes learn only hub routes, and spoke-to-spoke traffic transits the hub's firewall, by policy rather than physics. A shared-services VRF exports 65000:999, which every customer imports — one extranet, no re-cabling. The mantra that keeps RD and RT straight under exam pressure and outage pressure alike: the RD makes routes unique, the RT makes routes useful.
- PE — holds VRFs, speaks to CEs, converts customer routes to VPNv4 and back.
- P — label-switches; carries no VRFs, no VPNv4, no customer knowledge whatsoever.
- CE — an ordinary router in the customer's world; peers with the PE in plain IPv4.
- MP-BGP between PE loopbacks (via route reflectors at scale) — the only place VPNv4 routes live.
Those four roles and three constructs are the entire architecture; nothing else is new. What remains is watching a route and then a packet actually make the trip — VRF to VPNv4 to VRF, and label stack down the LSP — which is the next chapter.