skip to content

A provider's MPLS L3VPN carries two customers that both use 10.0.0.0/8; how do VRFs, route distinguishers and route targets keep their routes and traffic apart?

level: seniorimportance: must knowfreq 26%

answer

  1. one table per customer per PE
  2. make the prefix unique
  3. membership is a separate tag
  4. two labels, two jobs

basics

~20 s

Each PE holds a VRF per customer; a route distinguisher turns each customer's 10.0.0.0/8 into a distinct VPN-IPv4 route for MP-BGP, route targets decide which remote VRFs import it, and an inner VPN label selects the VRF at the egress PE.

solid answer

~50 s

Under RFC 4364, a CE router exchanges routes with its PE, never with the provider's core, and the PE binds each attachment circuit to a **VRF**, a separate routing and forwarding table per customer. Routes learned from a CE get an 8-byte **route distinguisher** prepended, forming a 12-byte VPN-IPv4 prefix, so customer A's and customer B's `10.0.0.0/8` are different routes to BGP. PEs exchange them over MP-BGP (AFI 1, SAFI 128) with a **VPN label** and export **route targets**, extended communities per RFC 4360. A remote PE installs a route only into VRFs whose import targets match one of its route targets. In the data plane the ingress PE pushes the VPN label, then a transport label toward the egress PE's loopback; P routers switch on the outer label and hold no customer routes at all.

go deeper

for a junior

Recall the three roles, CE, PE and P, and that each customer gets its own routing table, a VRF, on the provider's edge routers.

for a middle

Explain how the route distinguisher makes overlapping prefixes unique for BGP and how route targets decide which VRFs import a route.

for a senior

Trace a packet through the two-label stack, explain why P routers hold no VPN state, and design import and export targets for hub-and-spoke or an extranet.

for a principal

Judge the isolation model honestly: separation without encryption rests on provider configuration, and RD and RT plans need ownership as the VPN count grows.

## The roles: CE, PE and P RFC 4364 (BGP/MPLS IP VPNs, which obsoletes RFC 2547) splits the network into three kinds of router: | Role | Belongs to | Knows | |---|---|---| | **CE** (customer edge) | the customer | its own site's routes and the routes its PE gives it | | **PE** (provider edge) | the provider | a VRF per attached customer, plus the core IGP and labels | | **P** (provider) | the provider | the core IGP and transport labels only, no VPN routes | The customer configures none of the provider's routers; its CE peers with the PE and never with the provider's core routers. The CE can learn routes from its PE by static configuration, eBGP, OSPF or RIP; the protocol on that link is a local choice. ## VRFs: separate tables on one PE A **VRF** (VPN routing and forwarding table) is a routing table plus a forwarding table that the PE uses only for packets arriving on the interfaces bound to it. Customer A's interfaces map to VRF A and customer B's to VRF B, so a packet from A to `10.1.2.3` is looked up only in A's table. Two VRFs on one PE can hold the same prefix with no conflict. A VRF on its own, without labels or MP-BGP, is VRF-lite segmentation; L3VPN extends the separation across a shared core. ## Route distinguishers: making the prefixes unique BGP between PEs must carry both customers' `10.0.0.0/8` at once. Plain BGP would treat them as one prefix and keep one best path. RFC 4364 defines the **VPN-IPv4 address family**: a 12-byte quantity made of an 8-byte **route distinguisher (RD)** followed by the 4-byte IPv4 address. The RD has a 2-byte type field and a 6-byte value: - **Type 0**: a 2-byte AS number plus a 4-byte assigned number. - **Type 1**: a 4-byte IP address plus a 2-byte assigned number. - **Type 2**: a 4-byte AS number plus a 2-byte assigned number. The RFC is explicit that an RD carries no meaning: it does not identify the VPN or say where the route goes. It only lets BGP hold several distinct routes to the same IPv4 prefix. Many operators give each PE its own RD for a VPN so that a dual-homed site's two PE routes stay distinct prefixes through a route reflector, rather than collapsing into one best path. ## Route targets: deciding who imports what Membership is the job of the **route target (RT)**, a BGP extended community (RFC 4360 defines it with low-order type octet `0x02`). Each VRF has a set of **export targets** that the PE attaches to routes it learns from the site, and a set of **import targets**. A received VPN-IPv4 route is eligible for a VRF only if one of its route targets is among that VRF's import targets. Because import and export are separate sets, the same mechanism builds: - a **full mesh** VPN, with one RT used as both import and export everywhere; - **hub and spoke**, where spokes export "spoke" and import only "hub", so spoke-to-spoke traffic passes through the hub; - an **extranet**, where a shared-services VRF imports from several customers and they import its routes. ## The control plane and the two-label data plane 1. The CE advertises `10.0.0.0/8` to PE1, which places it in VRF A. 2. PE1 prepends VRF A's RD, allocates a **VPN label**, attaches the export RTs, and sends the route in MP-BGP's `MP_REACH_NLRI` (AFI 1, SAFI 128, RFC 4760) with its own loopback as the BGP next hop. PEs peer in an iBGP mesh or through route reflectors. 3. PE2 imports the route into every VRF with a matching import RT. 4. A packet from customer A's other site arrives at PE2 in VRF A. PE2 pushes the **VPN label** (bottom of stack), then a **transport label** for PE1's loopback, learned by LDP or RSVP-TE (top). 5. P routers swap only the transport label. With penultimate hop popping, PE1 receives the packet with just the VPN label, which tells it which VRF and next hop to use. That is why the P routers need no per-VPN state: they never see a customer address, only a label leading to a PE. ## What L3VPN does not give you - **No encryption.** RFC 4364 states that the architecture provides no cryptographic privacy; separation depends on correct provider configuration. - **Mistakes leak.** A wrong import RT installs another customer's routes, so RT plans are change-controlled. - **The VPN label is local** to the egress PE, like every other label.

  • If two customers use different route distinguishers, why are route targets still needed?
    The RD only makes prefixes unique inside BGP; RFC 4364 says it carries no information about the VPN or where the route should go. Import and export decisions need a separate tag, so the route target, an extended community, says which VRFs may install the route. That separation is what allows hub-and-spoke and extranet designs, where import and export sets differ.
  • Why do the P routers in an MPLS L3VPN need no customer routes?
    The ingress PE pushes two labels: the VPN label at the bottom and a transport label for the egress PE's loopback on top. P routers switch only on the top label, which needs only the core IGP and label distribution. The customer address and the VPN label are not read until the egress PE.

saying these in an interview costs you the question

  • The route distinguisher identifies which VPN a route belongs to.
  • Routes with the same RD are imported into each other's VRFs automatically.
  • P routers hold every customer's VRF so they can route overlapping prefixes.
  • MPLS L3VPN encrypts customer traffic across the provider core.
  • A single label is enough because the transport label already names the VRF.
  • Route targets are ordinary 4-byte BGP communities.