L3VPN — BGP/MPLS IP VPN · Protocol Atlas

Why it exists

Customers reuse private address space. A provider backbone must keep overlapping prefixes distinct, deliver traffic only to the sites that share a VPN, and keep P routers free of customer routes.

L3VPN is isolation, not confidentiality. Traffic is visible to the provider unless the customer runs encryption over the top.

RD uniqueness, RT import, two-label stack

PE1 pushes a VPN label and a transport label toward PE2. P swaps only the outer label. The RD made the prefix unique in BGP; the RT decided who imported it.

Link
Blocking
Packet in flight
Discarded
Emphasis

Select a device to read its state. Arrow keys walk the topology.

Text equivalent of this diagram

Devices and links at this step
Element	Kind	State
CE-A · 10.0.0.0/8	host	Prefix: 10.0.0.0/8
PE1 · RD 65000:1	router	—
P	router	—
PE2 · RD 65000:2	router	—
CE-B	host	Prefix: 10.0.0.0/8
PE3 · same RT	router	—
CE-A · 10.0.0.0/8 — PE1 · RD 65000:1	link	up
PE1 · RD 65000:1 — P	link	up
P — PE2 · RD 65000:2	link	up
PE2 · RD 65000:2 — CE-B	link	up
P — PE3 · same RT	link	up

1 / 5

CE-A and CE-B both use 10.0.0.0/8 behind different PEs. The provider backbone must keep those prefixes distinct and still deliver packets between the sites that share a VPN.

What changed

CE-A · 10.0.0.0/8: Prefix → 10.0.0.0/8
CE-B: Prefix → 10.0.0.0/8
Emphasis on PE1 · RD 65000:1
Emphasis on PE2 · RD 65000:2

How it works

Each VRF has a Route Distinguisher prepended to customer prefixes so VPN-IPv4 NLRIs are unique in BGP even when the IPv4 prefixes collide.

Route Target extended communities decide import and export. Lists need not be symmetric — that is how hub-and-spoke VPNs are built.

MP-BGP carries VPN-IPv4 (and VPN-IPv6) via MP_REACH_NLRI. The PE that originates the route also assigns a VPN label used at the egress for the VRF lookup.

On the wire the ingress PE pushes a VPN label and a transport label toward the egress PE. P routers swap only the outer label and never see customer routes.

Try it

Distinguish RD from RT

Two RDs make two VPNv4 NLRI for the same IPv4 prefix. Import still keys off the Route Target.

Two VPN-IPv4 NLRI for 10.0.0.0/8PE1 RD assigned (65000:x)PE2 RD assigned (65000:x)

ImportAttached RT (65000:x)VRF A import RT (65000:x)

RD 65000:1 vs 65000:2 · RT 65000:100

rd10.0.0.0/8 appears twice because the RDs 65000:1 and 65000:2 make two VPN-IPv4 NLRI. Import is still decided by Route Targets, not by those RDs.
rtVRF A imports because RT 100 matches the attached target.

On the wire

Constructed examples, encoded from the field table below them — not captured traffic.

MPLS: Stacked after the link-layer header, before the inner IP or Ethernet payload. RFC 3032

Configure it

```
vrf definition CUSTOMER-A
 rd 65000:1
 address-family ipv4
  route-target export 65000:100
  route-target import 65000:100
```
The RD makes this site’s prefixes unique in BGP. The RT decides who imports them — matching export and import here is a simple full-mesh membership.
Common mistake: Believing the RD controls import. Import is entirely the route target list.
RFC 4364 §4.3.1
```
interface GigabitEthernet0/0/1
 vrf forwarding CUSTOMER-A
 ip address 10.0.0.1 255.255.255.0
```
Bind the attachment circuit to the VRF before addressing. The reverse order removes the address.

router bgp 65000
 address-family vpnv4
  neighbor 192.0.2.10 activate
  neighbor 192.0.2.10 send-community extended
 exit-address-family
 address-family ipv4 vrf CUSTOMER-A
  redistribute connected

VPNv4 carries the RD-qualified prefixes and RT communities to other PEs. The VRF address-family originates the local customer routes.

RFC 4364 §4.3.4

Verify

show bgp vpnv4 unicast vrf CUSTOMER-A: Local and remote prefixes with the expected RT community.
show mpls forwarding-table vrf CUSTOMER-A: VPN labels toward remote prefixes.
show ip route vrf CUSTOMER-A: Customer and imported remote routes only in this table.

Caveats

A labelled path to the BGP next hop is required; IP reachability alone does not forward VPN traffic.
Extended communities must be sent or RTs never leave the local PE.

When it breaks

Symptom first, because that is what you have when it happens.

A VPN route is in the provider edge’s BGP table and not in the customer VRF.
Narrow it down
1. Compare the route target the route carries against the import list on the VRF.
2. Check whether route target constraint or filtering is dropping it before import.
3. Confirm the VRF exists on the receiving router at all.
Cause
The route target does not match. Import is entirely driven by the extended community, and a route with the wrong one is a route nobody asked for.
Fix
Align the export target on one side with the import target on the other. They are lists and need not be symmetric, which is how hub-and-spoke topologies are built.
Two customers with overlapping address space see each other’s routes.
Narrow it down
1. Check whether the two VRFs share a route target.
2. Compare the route distinguishers — they must be unique per VRF.
3. Look for a shared services VRF importing from both without filters.
Cause
A shared route target. The distinguisher keeps overlapping prefixes distinct inside BGP; it does nothing to control who imports them. Only the target does that.
Fix
Give each customer its own targets. If a shared services VRF is needed, import into it from both rather than letting them import from each other.
VPN routes are present and correct at both ends and traffic is still dropped.
Narrow it down
1. Check whether the label-switched path between the provider edges is up.
2. Confirm the BGP next hop is reachable through MPLS, not just through IP.
3. Look for a P router that has no label for the next hop.
Cause
The control plane converged and the data plane has no path. A VPN packet needs two labels — one for the VPN, one to reach the far provider edge — and if the transport label is missing the packet has nowhere to go.
Fix
Verify the label-switched path end to end. An IP-reachable next hop with no label is the classic case, and ping will not show it.
Traffic arrives at the egress PE and is dropped or delivered into the wrong VRF.
Narrow it down
1. Compare the VPN label PE1 pushes with the label PE2 advertised in MP-BGP.
2. Confirm PHP did not expose the VPN label to a P router that cannot interpret it.
3. Check whether the attachment circuit is bound to the intended VRF.
Cause
The VPN label selects the VRF at the egress. A stale label, a misbound interface, or an unexpected pop leaves the packet without a correct table.
Fix
Clear and relearn the VPNv4 route, verify the label in the forwarding table, and confirm the CE-facing interface is in the right VRF.
The VRF is empty of customer routes even though RT import from remote PEs works.
Narrow it down
1. Check whether the CE-PE routing protocol (or static) is configured under the VRF.
2. Confirm the attachment circuit is bound to the VRF before addressing.
3. Look for redistribute or network statements scoped to the wrong table.
Cause
Moving an interface into a VRF does not bring a globally configured IGP with it. Local customer prefixes never enter the VRF, so there is nothing to export.
Fix
Configure the CE-PE protocol under the VRF and verify with a VRF-aware show command.

Design notes

Import membership is not the forwarding path. Six PEs can import the same RT while only two sit on a given label-switched path.

An IP-reachable BGP next hop without a labelled transport path produces a converged control plane and a dead data plane. Loopback ping will not catch it.

Shared-services VRFs import many customer targets; never let customers import each other’s targets unless that mesh is intentional.

Misconceptions

“The route distinguisher controls which VRF a route lands in.”: It only makes overlapping prefixes unique inside BGP so two customers can both advertise 10.0.0.0/8. Import is decided by the route target, and conflating the two is the most common misunderstanding in the technology.
“MPLS L3VPN encrypts customer traffic.”: It separates it. Traffic is unencrypted and visible to the provider; the guarantee is isolation between customers, not confidentiality from the operator. Customers wanting confidentiality run their own encryption over the top.
“The provider core carries customer routes.”: P routers carry none. They switch on the transport label and never look at the VPN label or the customer prefix, which is exactly what lets the core stay small while the edge carries millions of routes.

More walkthroughs

VPN route in BGP, missing from the VRFfailure

The VPNv4 prefix arrives at the PE and never lands in the customer VRF. Import is entirely the Route Target — a wrong export or import list leaves a healthy-looking BGP table and an empty VRF.

Link
Blocking
Packet in flight
Discarded
Emphasis

Select a device to read its state. Arrow keys walk the topology.

Text equivalent of this diagram

Devices and links at this step
Element	Kind	State
PE-export · RT 65000:100	router	—
RR / MP-BGP	router	—
PE-import · RT 65000:200	router	BGP: route present
PE-export · RT 65000:100 — RR / MP-BGP	link	up
RR / MP-BGP — PE-import · RT 65000:200	link	up

1 / 3

PE-import shows the VPN-IPv4 route in the BGP table. RD 65000:1 made it unique. The operator assumes the VRF must have it too.

What changed

Emphasis: VPNv4 NLRI
PE-import · RT 65000:200: BGP → route present

Control plane up, data plane deadfailure

VPN routes and RTs are correct at both PEs, yet customer traffic drops. An IP-reachable BGP next hop without a transport label leaves nowhere for the two-label stack to go.

Link
Blocking
Packet in flight
Discarded
Emphasis

Select a device to read its state. Arrow keys walk the topology.

Text equivalent of this diagram

Devices and links at this step
Element	Kind	State
PE1	router	VPNv4: imported · BGP NH: 192.0.2.2 reachable
P · no label for PE2	router	—
PE2 · BGP NH 192.0.2.2	router	—
PE1 — P · no label for PE2	link	up
P · no label for PE2 — PE2 · BGP NH 192.0.2.2	link	up

1 / 3

PE1 has the VPNv4 prefix from PE2 with a matching RT. Ping between PE loopbacks succeeds. The operator concludes the VPN is up.

What changed

PE1: VPNv4 → imported
PE1: BGP NH → 192.0.2.2 reachable
Emphasis on PE1

Terms

Route Distinguisher: Eight octets prepended to an IPv4 prefix so two VPNs can use the same address. Import and export are Route Targets. The RD does not decide who imports the route.
Route Target: An extended community that decides which VRFs import a VPN route. Export and import lists need not be symmetric — that is how hub-and-spoke L3VPNs are built. It is not the Route Distinguisher.
VPN label: The inner MPLS label an ingress PE pushes so the egress PE can select the correct VRF. P routers ignore it and switch only on the outer transport label.

Check yourself

A VPN route is in the PE’s BGP table but not in the VRF. What is wrong?
What does the route distinguisher actually do?
Routes are correct at both ends and traffic is dropped. What should you check?
What do P routers in the core know about customer routes?
Does MPLS L3VPN encrypt customer traffic?
On the PE→P hop, which label does the P router act on?
How do PEs exchange VPN-IPv4 prefixes?
How is a hub-and-spoke L3VPN usually expressed?

Why it exists

RD uniqueness, RT import, two-label stack

How it works

Try it

Distinguish RD from RT

On the wire

Configure it

Verify

Caveats

When it breaks

A VPN route is in the provider edge’s BGP table and not in the customer VRF.

Narrow it down

Cause

Fix

Two customers with overlapping address space see each other’s routes.

Narrow it down

Cause

Fix

VPN routes are present and correct at both ends and traffic is still dropped.

Narrow it down

Cause

Fix

Traffic arrives at the egress PE and is dropped or delivered into the wrong VRF.

Narrow it down

Cause

Fix

The VRF is empty of customer routes even though RT import from remote PEs works.

Narrow it down

Cause

Fix

Design notes

Misconceptions

More walkthroughs

VPN route in BGP, missing from the VRFfailure

Control plane up, data plane deadfailure

Terms

Check yourself

Related

BGP

VRF

SR-MPLS

LDP