MPLS VPN and L3VPN Lab Guide for Enterprise Networks

Introduction

If you have ever wondered how service providers deliver isolated, secure connectivity to multiple enterprise customers over a single shared infrastructure, the answer is MPLS VPN. Multiprotocol Label Switching Virtual Private Networks remain the backbone technology that powers Layer 3 VPN (L3VPN) services across the globe, and mastering them is a non-negotiable requirement for anyone pursuing the CCIE Enterprise Infrastructure certification. Whether you are building a lab from scratch or reinforcing concepts you have studied in theory, hands-on practice with real configurations is the fastest path to competence.

This comprehensive lab guide walks you through every major MPLS VPN building block: enabling MPLS and LDP on a service provider core, authenticating LDP peers, creating VRF instances, establishing MP-iBGP VPNv4 neighbor relationships, and configuring PE-CE routing using four different protocols -- static routing, EIGRP, BGP, and OSPF. You will also tackle advanced scenarios including OSPF domain-ID manipulation, sham-links for backdoor path control, and MPLS VPN extranets for controlled inter-customer route leaking. Each section includes the exact commands, IP addresses, and procedures you need to replicate these labs in your own environment.

For a structured video walkthrough of MPLS VPN fundamentals, explore the MPLS VPN Lab Course on NHPREP.

What Is the MPLS VPN Lab Topology?

Before diving into configurations, it is essential to understand the topology that underpins every lab in this guide. The service provider (SP) core consists of four routers -- R1, R2, R3, and R4 -- connected in a linear chain. R1 and R4 serve as Provider Edge (PE) routers, while R2 and R3 function as Provider (P) routers that carry labeled traffic through the core.

The customer edge (CE) routers connect to the PE routers on dedicated interfaces:

Router	Role	Loopback 0	Key Interfaces
R1	PE	1.1.1.1/32	E0/0 (192.1.12.1), E0/1 (192.1.15.1), E0/2 (192.1.16.1)
R2	P	2.2.2.2/32	E0/0 (192.1.12.2), E0/1 (192.1.23.2)
R3	P	3.3.3.3/32	E0/0 (192.1.23.3), E0/1 (192.1.34.3)
R4	PE	4.4.4.4/32	E0/0 (192.1.34.4), E0/1 (192.1.47.4), E0/2 (192.1.48.4)
R5	CE (Cust-A)	10.5.5.5/24	E0/0 (192.1.15.5)
R6	CE (Cust-B)	10.6.6.6/24	E0/0 (192.1.16.6)
R7	CE (Cust-B)	10.7.7.7/24	E0/0 (192.1.47.7)
R8	CE (Cust-A)	10.8.8.8/24	S0/0 (192.1.48.8)

Two customers are served: Cust-A connects through R5 (at PE R1) and R8 (at PE R4), while Cust-B connects through R6 (at PE R1) and R7 (at PE R4). This topology is deliberately designed to exercise every PE-CE routing scenario you will encounter on the CCIE lab exam.

How Do You Configure MPLS Unicast Routing and LDP?

The foundation of any MPLS VPN deployment is a functioning IGP underlay combined with LDP label distribution across the provider core. Without a working label-switched path between PE routers, VPN traffic cannot traverse the backbone.

Step 1: Configure OSPF as the Underlay IGP

All SP routers (R1 through R4) run OSPF in Area 0. The router-ID on each device matches its loopback address, and all internal links plus loopbacks are advertised into OSPF.

! R1
Router ospf 1
 Router-id 1.1.1.1
 Network 1.1.1.1 0.0.0.0 area 0
 Network 192.1.12.0 0.0.0.255 area 0

! R2
Router ospf 1
 Router-id 2.2.2.2
 Network 2.2.2.2 0.0.0.0 area 0
 Network 192.1.12.0 0.0.0.255 area 0
 Network 192.1.23.0 0.0.0.255 area 0

! R3
Router ospf 1
 Router-id 3.3.3.3
 Network 3.3.3.3 0.0.0.0 area 0
 Network 192.1.23.0 0.0.0.255 area 0
 Network 192.1.34.0 0.0.0.255 area 0

! R4
Router ospf 1
 Router-id 4.4.4.4
 Network 4.4.4.4 0.0.0.0 area 0
 Network 192.1.34.0 0.0.0.255 area 0

Step 2: Enable MPLS and LDP on Core Interfaces

Once OSPF adjacencies are up, enable MPLS on every physical link within the SP network. Set the LDP router-ID to the loopback interface (the most reliable interface) and assign a custom label range per router for easier troubleshooting.

! R1
Mpls ldp router-id Loopback0
Mpls label range 100 199
Interface E0/0
 Mpls ip

! R2
Mpls ldp router-id Loopback0
Mpls label range 200 299
Interface E0/0
 Mpls ip
Interface E0/1
 Mpls ip

! R3
Mpls ldp router-id Loopback0
Mpls label range 300 399
Interface E0/0
 Mpls ip
Interface E0/1
 Mpls ip

! R4
Mpls ldp router-id Loopback0
Mpls label range 400 499
Interface E0/0
 Mpls ip

Pro Tip: Assigning non-overlapping label ranges (100-199 for R1, 200-299 for R2, and so on) makes it immediately obvious which router assigned a particular label when you are reading the output of show mpls forwarding-table. This is an invaluable troubleshooting technique during lab exams.

The Mpls ldp router-id Loopback0 command forces LDP to use the loopback address as its transport address. Since the loopback is always reachable via the IGP (OSPF in this case), LDP sessions remain stable even if a physical interface flaps.

How Do You Authenticate LDP Peers in an MPLS VPN Network?

In production MPLS networks and on the CCIE lab exam, you are expected to secure LDP neighbor relationships with password authentication. This prevents unauthorized routers from injecting labels into the MPLS domain.

The configuration uses the mpls ldp password required command to enforce authentication on all LDP sessions, combined with per-neighbor password definitions.

! R1
Mpls ldp password required
Mpls ldp neighbor 2.2.2.2 password Lab@123

! R2
Mpls ldp password required
Mpls ldp neighbor 1.1.1.1 password Lab@123
Mpls ldp neighbor 3.3.3.3 password Lab@123

! R3
Mpls ldp password required
Mpls ldp neighbor 2.2.2.2 password Lab@123
Mpls ldp neighbor 4.4.4.4 password Lab@123

! R4
Mpls ldp password required
Mpls ldp neighbor 3.3.3.3 password Lab@123

Notice that each router must specify the LDP router-ID (loopback address) of every directly connected LDP neighbor along with the shared password. The password required command means the router will reject any LDP session that does not present valid credentials.

Pro Tip: After configuring LDP authentication, verify that your LDP sessions have re-established using show mpls ldp neighbor. If sessions fail to come up, double-check that the neighbor addresses match the remote router's LDP router-ID, not its physical interface IP.

How Do You Configure VRF and VPNv4 for MPLS VPN?

The core concept that makes MPLS VPN work is Virtual Routing and Forwarding (VRF). Each customer gets its own isolated routing table on the PE router, even though all customers share the same physical infrastructure. The PE routers then exchange customer routes using MP-iBGP with the VPNv4 address family.

Establishing the MP-iBGP VPNv4 Session

Before creating any VRFs, establish the MP-iBGP VPNv4 neighbor relationship between PE routers R1 and R4. This session carries all customer VPN routes across the MPLS backbone.

! R1
Router BGP 1000
 Neighbor 4.4.4.4 remote-as 1000
 Neighbor 4.4.4.4 update-source loopback0
!
Address-family vpnv4
 Neighbor 4.4.4.4 activate

! R4
Router BGP 1000
 Neighbor 1.1.1.1 remote-as 1000
 Neighbor 1.1.1.1 update-source loopback0
!
Address-family vpnv4
 Neighbor 1.1.1.1 activate

Key points about this configuration:

Both PE routers are in AS 1000 (iBGP)
The update-source loopback0 command ensures the BGP session uses the loopback addresses, which are reachable via the OSPF underlay
The address-family vpnv4 activation enables the exchange of VPN-labeled routes, including Route Distinguisher and Route Target communities

Creating VRF Instances

Each customer requires a dedicated VRF with a unique Route Distinguisher (RD) and appropriate Route Target (RT) values for import and export control.

! Cust-A VRF on R1
Vrf definition Cust-A
 rd 1000:1
 address-family ipv4
  route-target both 1000:1
!
Interface E0/1
 vrf forwarding Cust-A
 Ip address 192.1.15.1 255.255.255.0
 No shut

! Cust-A VRF on R4
Vrf definition Cust-A
 rd 1000:1
 address-family ipv4
  route-target both 1000:1
!
Interface E0/2
 vrf forwarding Cust-A
 Ip address 192.1.48.4 255.255.255.0
 No shut

For the second customer:

! Cust-B VRF on R1
Vrf definition Cust-B
 rd 1000:2
 address-family ipv4
  route-target both 1000:2
!
Interface E0/2
 vrf forwarding Cust-B
 Ip address 192.1.16.1 255.255.255.0
 No shut

! Cust-B VRF on R4
Vrf definition Cust-B
 rd 1000:2
 address-family ipv4
  route-target both 1000:2
!
Interface E0/1
 vrf forwarding Cust-B
 Ip address 192.1.47.4 255.255.255.0
 No shut

VRF	RD	Route Target	R1 Interface	R4 Interface
Cust-A	1000:1	1000:1 (both)	E0/1 - 192.1.15.1/24	E0/2 - 192.1.48.4/24
Cust-B	1000:2	1000:2 (both)	E0/2 - 192.1.16.1/24	E0/1 - 192.1.47.4/24

Pro Tip: The route-target both keyword is a shorthand that sets both the import and export RT to the same value. In production deployments, you may need separate import and export RTs to implement hub-and-spoke VPN topologies or extranet scenarios.

Configuring MPLS VPN PE-CE Routing with Static Routes

The simplest PE-CE routing method uses static routes. This approach works well when the CE router has a limited number of networks and does not run a dynamic routing protocol.

On the PE routers, create VRF-aware static routes pointing to the CE routers, then redistribute those static routes into BGP so they can be carried across the VPNv4 session to the remote PE.

! R1 - Static route to reach R5's network via Cust-A VRF
ip route vrf Cust-A 10.5.5.0 255.255.255.0 192.1.15.5
!
Router BGP 1000
!
Address-family ipv4 vrf Cust-A
 Redistribute static

! R5 - Default route toward PE
ip route 0.0.0.0 0.0.0.0 192.1.15.1

The same pattern applies on the remote PE:

! R4 - Static route to reach R8's network via Cust-A VRF
ip route vrf Cust-A 10.8.8.0 255.255.255.0 192.1.48.8
!
Router BGP 1000
!
Address-family ipv4 vrf Cust-A
 Redistribute static

! R8 - Default route toward PE
ip route 0.0.0.0 0.0.0.0 192.1.48.4

For Cust-B, the same approach is used:

! R1 - Cust-B static route
ip route vrf Cust-B 10.6.6.0 255.255.255.0 192.1.16.6
!
Router BGP 1000
!
Address-family ipv4 vrf Cust-B
 Redistribute static

! R6 - Default route toward PE
ip route 0.0.0.0 0.0.0.0 192.1.16.1

! R4 - Cust-B static route
ip route vrf Cust-B 10.7.7.0 255.255.255.0 192.1.47.7
!
Router BGP 1000
!
Address-family ipv4 vrf Cust-B
 Redistribute static

! R7 - Default route toward PE
ip route 0.0.0.0 0.0.0.0 192.1.47.4

Once these configurations are in place, the 10.5.5.0/24 network on R5 is reachable from R8 through the MPLS backbone, and vice versa -- all while remaining completely isolated from Cust-B traffic.

Configuring MPLS VPN PE-CE Routing with EIGRP

When the customer environment runs EIGRP, the PE-CE routing configuration becomes more involved. The PE router must run EIGRP within the VRF context and perform mutual redistribution between EIGRP and BGP.

Cust-A with EIGRP 100

! R1 - EIGRP under Cust-A VRF
Router EIGRP 1
!
Address-family ipv4 vrf Cust-A Autonomous-system 100
 Network 192.1.15.0
 Redistribute BGP 1000 metric 10 10 10 10 10
!
Router BGP 1000
!
Address-family ipv4 vrf Cust-A
 Redistribute eigrp 100

! R5 - CE Router
Router EIGRP 100
 Network 192.1.15.0
 Network 10.0.0.0

On the remote PE:

! R4 - EIGRP under Cust-A VRF
Router EIGRP 1
!
Address-family ipv4 vrf Cust-A Autonomous-system 100
 Network 192.1.48.0
 Redistribute BGP 1000 metric 10 10 10 10 10
!
Router BGP 1000
!
Address-family ipv4 vrf Cust-A
 Redistribute eigrp 100

! R8 - CE Router
Router EIGRP 100
 Network 192.1.48.0
 Network 10.0.0.0

Cust-B with EIGRP 200 and 222

Different EIGRP autonomous system numbers are used for different customer sites:

! R1 - EIGRP under Cust-B VRF (AS 200 toward R6)
Router EIGRP 1
!
Address-family ipv4 vrf Cust-B Autonomous-system 200
 Network 192.1.16.0
 Redistribute BGP 1000 metric 10 10 10 10 10
!
Router BGP 1000
!
Address-family ipv4 vrf Cust-B
 Redistribute eigrp 200

! R6 - CE Router
Router EIGRP 200
 Network 192.1.16.0
 Network 10.0.0.0

! R4 - EIGRP under Cust-B VRF (AS 222 toward R7)
Router EIGRP 1
!
Address-family ipv4 vrf Cust-B Autonomous-system 222
 Network 192.1.47.0
 Redistribute BGP 1000 metric 10 10 10 10 10
!
Router BGP 1000
!
Address-family ipv4 vrf Cust-B
 Redistribute eigrp 222

! R7 - CE Router
Router EIGRP 222
 Network 192.1.47.0
 Network 10.0.0.0

Pro Tip: The metric 10 10 10 10 10 in the Redistribute BGP command sets the EIGRP seed metric (bandwidth, delay, reliability, load, MTU) for routes redistributed from BGP into EIGRP. Without this metric, EIGRP will assign an infinite metric to redistributed routes, making them unreachable.

Notice the use of named EIGRP (process 1) on the PE routers with VRF-aware address families, while the CE routers use classic EIGRP with their respective autonomous system numbers. This is the standard approach for MPLS VPN PE-CE EIGRP configurations.

Configuring MPLS VPN PE-CE Routing with BGP

BGP is the most common PE-CE routing protocol in production MPLS VPN deployments. It provides natural support for VPN route exchange because the PE router already runs BGP for the VPNv4 backbone.

Basic BGP PE-CE (Unique AS per CE)

In the first BGP scenario, each CE router uses a unique private AS number:

! R1 - BGP neighbor in Cust-A VRF toward R5 (AS 65005)
Router BGP 1000
!
Address-family ipv4 vrf Cust-A
 Neighbor 192.1.15.5 remote-as 65005

! R5 - CE Router
Router bgp 65005
 Network 10.5.5.0 mask 255.255.255.0
 Neighbor 192.1.15.1 remote-as 1000

! R4 - BGP neighbor in Cust-A VRF toward R8 (AS 65008)
Router BGP 1000
!
Address-family ipv4 vrf Cust-A
 Neighbor 192.1.48.8 remote-as 65008

! R8 - CE Router
Router bgp 65008
 Network 10.8.8.0 mask 255.255.255.0
 Neighbor 192.1.48.4 remote-as 1000

For Cust-B with unique AS numbers:

! R1 - Cust-B VRF toward R6 (AS 65006)
Router BGP 1000
!
Address-family ipv4 vrf Cust-B
 Neighbor 192.1.16.6 remote-as 65006

! R6
Router bgp 65006
 Network 10.6.6.0 mask 255.255.255.0
 Neighbor 192.1.16.1 remote-as 1000

! R4 - Cust-B VRF toward R7 (AS 65007)
Router BGP 1000
!
Address-family ipv4 vrf Cust-B
 Neighbor 192.1.47.7 remote-as 65007

! R7
Router bgp 65007
 Network 10.7.7.0 mask 255.255.255.0
 Neighbor 192.1.47.4 remote-as 1000

BGP PE-CE with Same AS Number (AS-Override and AllowAS-In)

A more challenging scenario occurs when both CE sites of the same customer use the same AS number. By default, BGP loop prevention rejects routes that contain the local AS in the AS-path. Two mechanisms solve this problem:

AS-Override (configured on the PE): The PE router replaces the customer AS number in the AS-path with its own AS number before advertising routes to the remote CE.

! R1 - AS-Override for Cust-A
Router BGP 1000
!
Address-family ipv4 vrf Cust-A
 Neighbor 192.1.15.5 as-override

! R4 - AS-Override for Cust-A
Router BGP 1000
!
Address-family ipv4 vrf Cust-A
 Neighbor 192.1.48.8 as-override

AllowAS-In (configured on the CE): The CE router accepts routes even if its own AS number appears in the AS-path.

! R6 - AllowAS-In for Cust-B
Router BGP 65002
 Neighbor 192.1.16.1 allowas-in

! R7 - AllowAS-In for Cust-B
Router BGP 65002
 Neighbor 192.1.47.4 allowas-in

Feature	Configured On	Purpose	Use Case
as-override	PE Router	Replaces CE AS with PE AS in AS-path	When CE sites share the same AS and you control the PE
allowas-in	CE Router	Accepts routes containing own AS in path	When CE sites share the same AS and you control the CE

Configuring MPLS VPN PE-CE Routing with OSPF

OSPF as a PE-CE protocol introduces unique behavior because of how the MPLS backbone interacts with OSPF route types. Understanding this behavior is critical for the CCIE exam.

Basic OSPF PE-CE Configuration

! R1 - OSPF for Cust-A VRF (process 58)
Router ospf 58 vrf Cust-A
 Network 192.1.15.0 0.0.0.255 area 0
 Redistribute bgp 1000
!
Router bgp 1000
 Address-family ipv4 vrf Cust-A
 Redistribute ospf 58

! R5 - CE Router
Router ospf 1
 Network 10.5.5.0 0.0.0.255 area 0
 Network 192.1.15.0 0.0.0.255 area 0

! R4 - OSPF for Cust-A VRF (process 58)
Router ospf 58 vrf Cust-A
 Network 192.1.48.0 0.0.0.255 area 0
 Redistribute bgp 1000
!
Router bgp 1000
 Address-family ipv4 vrf Cust-A
 Redistribute ospf 58

! R8 - CE Router
Router ospf 1
 Network 10.8.8.0 0.0.0.255 area 0
 Network 192.1.48.0 0.0.0.255 area 0

For Cust-B, different OSPF process IDs are used on each PE:

! R1 - OSPF for Cust-B VRF (process 6)
Router ospf 6 vrf Cust-B
 Network 192.1.16.0 0.0.0.255 area 0
 Redistribute bgp 1000
!
Router bgp 1000
 Address-family ipv4 vrf Cust-B
 Redistribute ospf 6

! R4 - OSPF for Cust-B VRF (process 7)
Router ospf 7 vrf Cust-B
 Network 192.1.47.0 0.0.0.255 area 0
 Redistribute bgp 1000
!
Router bgp 1000
 Address-family ipv4 vrf Cust-B
 Redistribute ospf 7

Understanding OSPF Route Types in MPLS VPN

A crucial behavior to understand is how OSPF route types appear on the CE routers:

When PE routers use the same OSPF process ID for a given VRF (as with Cust-A, process 58 on both R1 and R4), the MPLS network is treated as the OSPF super-backbone. Routes from the remote site appear as O IA (Inter-Area) routes on the CE routers.
When PE routers use different OSPF process IDs for a given VRF (as with Cust-B, process 6 on R1 and process 7 on R4), routes from the remote site appear as O E2 (External) routes on the CE routers.

This distinction matters because O IA routes are preferred over O E2 routes in OSPF path selection, and it affects how customers perceive route types in their routing tables.

How Does OSPF Domain-ID Fix Route Type Issues in MPLS VPN?

When PE routers use different OSPF process IDs and you need remote VPN routes to appear as O IA (Inter-Area) rather than O E2 (External), configure a matching domain-ID on both PE routers.

! R1
Router ospf 6 vrf Cust-B
 Domain-id 0.0.0.67

! R4
Router ospf 7 vrf Cust-B
 Domain-id 0.0.0.67

By setting the same domain-ID (0.0.0.67) on both PE routers, you instruct the MPLS backbone to treat these two different OSPF processes as belonging to the same OSPF domain. The result is that routes from the remote site now appear as O IA routes on the CE routers, regardless of the differing process IDs.

Pro Tip: The domain-ID is encoded as a BGP extended community and carried within the VPNv4 update. When the receiving PE sees that the domain-ID matches its own OSPF VRF process, it injects the route as an inter-area (Type 3 LSA) rather than an external (Type 5 LSA).

Configuring MPLS VPN OSPF Sham-Links for Backdoor Paths

One of the most challenging MPLS VPN scenarios involves customers that have a backdoor link directly connecting two CE sites in addition to the MPLS VPN path. Since OSPF prefers intra-area routes over inter-area routes, and the backdoor link is typically in the same OSPF area as the PE-CE links, OSPF will prefer the backdoor path even if its cost is much higher.

The Problem

Consider Cust-B where R6 and R7 have a direct backdoor link:

! R6
Interface E0/1
 Ip address 10.67.67.6 255.255.255.0
 Ip ospf cost 1000
 No shut
!
Router OSPF 1
 Network 10.67.67.0 0.0.0.255 area 0

! R7
Interface E0/1
 Ip address 10.67.67.7 255.255.255.0
 Ip ospf cost 1000
 No shut
!
Router OSPF 1
 Network 10.67.67.0 0.0.0.255 area 0

Even though the backdoor link has a cost of 1000, OSPF will prefer it over the MPLS path because routes through the MPLS backbone arrive as O IA (inter-area), while the backdoor provides an intra-area path.

The Solution: Sham-Links

A sham-link creates a virtual intra-area OSPF adjacency between the PE routers across the MPLS backbone. This makes routes through the MPLS cloud appear as intra-area routes, allowing OSPF cost-based path selection to work correctly.

Step 1: Create VRF-aware loopbacks on each PE and advertise them in BGP:

! R1
Interface Loopback 67
 Ip vrf forwarding Cust-B
 Ip address 172.16.67.1 255.255.255.255
!
Router BGP 1000
!
Address-family ipv4 vrf Cust-B
 Network 172.16.67.1 mask 255.255.255.255

! R4
Interface Loopback 67
 Ip vrf forwarding Cust-B
 Ip address 172.16.67.4 255.255.255.255
!
Router BGP 1000
!
Address-family ipv4 vrf Cust-B
 Network 172.16.67.4 mask 255.255.255.255

Step 2: Configure the sham-link between the VRF loopbacks:

! R1
Router ospf 6 vrf Cust-B
 area 0 sham-link 172.16.67.1 172.16.67.4

! R4
Router ospf 7 vrf Cust-B
 area 0 sham-link 172.16.67.4 172.16.67.1

With the sham-link in place, OSPF routes through the MPLS backbone now appear as intra-area (O) routes. Since the sham-link has a default cost of 1 (much lower than the backdoor link's cost of 1000), traffic flows through the MPLS path as intended.

How Do You Configure MPLS VPN Extranets?

MPLS VPN extranets allow controlled route leaking between different customer VRFs. This is a common requirement when two customers need to share specific resources -- for example, when Cust-A needs access to a server in Cust-B's network and vice versa.

The extranet configuration uses route-maps with extended community RT manipulation to selectively export routes with a common RT that both VRFs import.

Step 1: Define Route-Maps for Selective Export

! R1 - Export 10.5.5.0/24 from Cust-A with RT 1000:99
access-list 55 permit 10.5.5.0 0.0.0.255
!
route-map EM-CustA permit 10
 match ip address 55
 set extcommunity rt 1000:99

! R1 - Export 10.6.6.0/24 from Cust-B with RT 1000:99
access-list 66 permit 10.6.6.0 0.0.0.255
!
route-map EM-CustB permit 10
 match ip address 66
 set extcommunity rt 1000:99

Step 2: Apply Export Maps and Import the Common RT

! R1
Vrf definition Cust-A
 Address-family ipv4
  Export map EM-CustA
  Route-target import 1000:99
!
Vrf definition Cust-B
 Address-family ipv4
  Export map EM-CustB
  Route-target import 1000:99

Step 3: Repeat on the Remote PE (R4)

! R4 - Export 10.8.8.0/24 from Cust-A with RT 1000:99
access-list 88 permit 10.8.8.0 0.0.0.255
!
route-map EM-CustA permit 10
 match ip address 88
 set extcommunity rt 1000:99

! R4 - Export 10.7.7.0/24 from Cust-B with RT 1000:99
access-list 77 permit 10.7.7.0 0.0.0.255
!
route-map EM-CustB permit 10
 match ip address 77
 set extcommunity rt 1000:99

! R4 - Apply to VRFs
Vrf definition Cust-A
 Address-family ipv4
  Export map EM-CustA
  Route-target import 1000:99
!
Vrf definition Cust-B
 Address-family ipv4
  Export map EM-CustB
  Route-target import 1000:99

The result is that R5 (Cust-A) can now reach R6's 10.6.6.0/24 network, and R6 (Cust-B) can reach R5's 10.5.5.0/24 network. The same cross-VRF access is enabled on the R4 side between R8 and R7. All other routes remain isolated within their respective VRFs.

Multi-ISP MPLS VPN Topology: Scaling to the Enterprise

Beyond the basic PE-CE lab, real enterprise MPLS VPN deployments often involve multiple ISPs, route reflectors, and complex BGP peering arrangements. The reference topology for this advanced scenario features two ISPs (AS 100 and AS 200) and a service provider (AS 111) with multiple PE routers.

ISP Core Setup

Each ISP runs OSPF as the underlay IGP in Area 0 with MD5 authentication and LDP for label distribution:

ISP	AS Number	Routers	OSPF Auth Key ID	LDP Router-ID
ISP-1	AS 100	ASBR-1 through ASBR-4, RR	100	Loopback10
ISP-2	AS 200	ASBR-1, ASBR-2, RR	100	Loopback10
SP-1	AS 111	PE-1 through PE-4, RR	100	Loopback10

VRF Configuration on SP-1 PE Routers

In the multi-PE topology, all PE routers share the same VRF configuration with consistent RD and RT values:

PE Router	VRF Interface	IP Address	RD & RT
PE-1	E0/1	192.168.100.111/24	111:1
PE-2	E0/1	192.168.101.2/24	111:1
PE-3	E0/1	192.168.102.3/24	111:1
PE-4	E0/1	192.168.103.4/24	111:1

The PE routers use MP-iBGP with a route reflector (RR at loopback 111.1.1.100) to exchange VPNv4 routes, and BGP is used as the PE-CE protocol with different private AS numbers at each branch site (AS 65010 at HQ, AS 65011 at BR-1, AS 65012 at BR-2, AS 65013 at BR-3).

Pro Tip: Using a route reflector in the service provider network eliminates the need for a full mesh of iBGP sessions between PE routers. The RR can accept dynamic neighbors from a defined IP range using peer-groups, significantly reducing configuration overhead in large deployments.

Frequently Asked Questions

What is the difference between RD and RT in MPLS VPN?

The Route Distinguisher (RD) is a 64-bit value prepended to IPv4 prefixes to create unique VPNv4 addresses. It ensures that overlapping customer IP addresses remain distinct in the BGP table. The Route Target (RT) is a BGP extended community used to control which routes are imported into and exported from a VRF. While the RD creates uniqueness, the RT controls route distribution. In the lab, Cust-A uses RD 1000:1 with RT 1000:1, and Cust-B uses RD 1000:2 with RT 1000:2.

Why do OSPF routes appear as O E2 instead of O IA in MPLS VPN?

When PE routers use different OSPF process IDs for the same customer VRF, the MPLS backbone does not recognize them as part of the same OSPF domain. As a result, routes redistributed from BGP into OSPF on the remote PE are injected as external (Type 5 LSA) routes, which appear as O E2 on the CE. To fix this, configure the same domain-ID on both PE routers under the respective OSPF VRF processes.

When should I use a sham-link in MPLS VPN?

A sham-link is needed when a customer has both an MPLS VPN connection and a direct backdoor link between CE sites running OSPF in the same area. Without a sham-link, OSPF will prefer the backdoor path (intra-area) over the MPLS path (inter-area), regardless of cost. The sham-link creates a virtual intra-area adjacency across the MPLS backbone, allowing normal OSPF cost comparison to determine the preferred path.

What is the difference between as-override and allowas-in for BGP PE-CE?

Both features solve the problem of CE sites sharing the same BGP AS number. AS-override is configured on the PE router and replaces the customer AS in the AS-path with the provider AS before sending updates to the CE. AllowAS-in is configured on the CE router and tells it to accept routes that contain its own AS in the path. AS-override is preferred when you control the PE configuration, while allowas-in is useful when the CE configuration is within your control.

Why is the EIGRP seed metric important when redistributing BGP into EIGRP?

EIGRP requires a valid composite metric (bandwidth, delay, reliability, load, MTU) for all routes in its topology table. When redistributing routes from BGP into EIGRP, there is no inherent EIGRP metric to carry over. Without specifying a seed metric using the metric keyword (for example, metric 10 10 10 10 10), EIGRP assigns an infinite metric, effectively making the redistributed routes unreachable.

How does LDP authentication improve MPLS VPN security?

LDP authentication using the mpls ldp password required command ensures that only authorized routers can establish LDP sessions and exchange label bindings. Without authentication, a rogue router could inject false labels into the MPLS domain, potentially intercepting or misdirecting traffic. Each LDP neighbor must be configured with a matching password, and the neighbor is identified by its LDP router-ID (typically the loopback address).

Conclusion

This lab guide has taken you through the complete lifecycle of an MPLS VPN deployment, from building the OSPF and LDP underlay, through VRF creation and VPNv4 session establishment, to PE-CE routing with four different protocols. You have also tackled three advanced scenarios that regularly appear on the CCIE Enterprise Infrastructure exam: OSPF domain-ID manipulation, sham-link configuration for backdoor path control, and extranet route leaking between customer VRFs.

The key takeaways from this guide are:

The MPLS underlay must be solid -- OSPF for IGP reachability and LDP for label distribution must be working before any VPN configuration can succeed
VRF isolation is the foundation -- Route Distinguishers create uniqueness while Route Targets control import/export policy
PE-CE protocol choice matters -- Static routing is simplest, BGP is most common in production, EIGRP requires seed metrics, and OSPF introduces route-type complexities
Advanced OSPF scenarios require deep understanding -- Domain-ID, sham-links, and the super-backbone concept are essential knowledge for CCIE-level proficiency
Extranets use RT manipulation -- Route-maps with extended community settings enable granular inter-VRF route leaking

To continue building your MPLS VPN skills with guided video instruction and additional lab scenarios, visit the MPLS VPN Lab Course on NHPREP. Consistent hands-on practice with these configurations is the most effective way to prepare for both the CCIE lab exam and real-world enterprise network deployments.