MPLS VPN enables a private network service over an MPLS infrastructure, allowing customer traffic to be securely routed between multiple sites while maintaining isolation between different customers. In this lesson, we will start with an MPLS VPN configuration example on Cisco devices. In the next lessons, we will focus on how MPLS VPN operates in both the control plane and data plane.
Cisco MPLS VPN Configuration Example
This is the topology we will use to configure MPLS VPN. The service provider’s infrastructure includes two PE routers, connected via two intermediate P routers. We have two customers, A and B, each with two sites: A1 and A2 for customer A, and B1 and B2 for customer B. Notice taht we are intentionally using identical IP subnets (172.16.1.0/24 and 172.16.2.0/24) for both customers to demonstrate that their traffic remains isolated and that overlapping addressing is supported in MPLS VPN.
The 10.0.0.0/8 subnet is used for the service provider’s network, with each router assigned a unique number: 1 and 2 for P1 and P2, and 11 and 12 for PE1 and PE2. The IP addressing follows a structured scheme:
The first octet is always 10.
The second and third octets represent the router numbers on both sides of a link.
The last octet corresponds to the router’s own identifier in that link.
For example, on the link between PE1 and P1, the IP address assigned to PE1 is 10.1.11.11, where 1 and 11 represent routers P1 and PE1, and .11 at the end signifies PE1’s identity in that connection.
Each router has a loopback interface with an IP address in the 10.10.10.X/32 range, where the last octet (X) corresponds to the router’s unique identifier. For example, PE1 has 10.10.10.11/32, while P1 has 10.10.10.1/32.
MPLS VPN Configuration Steps
To better understand how MPLS VPN works, I will first walk you through the configuration steps and its results. In the next lessons, we will dive deeper into how MPLS VPN operates in the control plane and data plane.
To implement an MPLS VPN, we need to follow these configuration steps:
Step1: IPv4 Addressing, OSPF, LDP
First, we must configure the MPLS infrastructure, including IP addressing, a routing protocol such as OSPF, and LDP to establish LSPs. This ensures that the MPLS core is properly set up, as discussed in previous lessons.
### P1
ip cef
!
mpls label protocol ldp
mpls ldp router-id loopback 0
!
interface loopback0
ip address 10.10.10.1 255.255.255.255
interface eth0/0
no shutdown
ip address 10.1.11.1 255.255.255.0
mpls ip
interface eth0/1
no shutdown
ip address 10.1.2.1 255.255.255.0
mpls ip
!
router ospf 1
network 10.0.0.0 0.255.255.255 area 0
### P2
ip cef
!
mpls label protocol ldp
mpls ldp router-id loopback 0
!
interface loopback0
ip address 10.10.10.2 255.255.255.255
interface eth0/0
no shutdown
ip address 10.1.2.2 255.255.255.0
mpls ip
interface eth0/1
no shutdown
ip address 10.2.12.2 255.255.255.0
mpls ip
!
router ospf 1
network 10.0.0.0 0.255.255.255 area 0
### PE1
ip cef
!
mpls label protocol ldp
mpls ldp router-id loopback 0
!
interface loopback0
ip address 10.10.10.11 255.255.255.255
interface eth0/0
no shutdown
ip address 10.1.11.11 255.255.255.0
mpls ip
!
router ospf 1
network 10.0.0.0 0.255.255.255 area 0
### PE2
ip cef
!
mpls label protocol ldp
mpls ldp router-id loopback 0
!
interface loopback0
ip address 10.10.10.12 255.255.255.255
interface eth0/0
no shutdown
ip address 10.2.12.12 255.255.255.0
mpls ip
!
router ospf 1
network 10.0.0.0 0.255.255.255 area 0
To confirm that this step is correctly implemented, I perform a traceroute between the Provider Edge (PE) routers. The connectivity must be successful, and I should see MPLS labels along the path between the PE routers. This verifies that both routing and MPLS are functioning correctly.
PE1#traceroute 10.10.10.12 source 10.10.10.11 Type escape sequence to abort. Tracing the route to 10.10.10.12 VRF info: (vrf in name/id, vrf out name/id) 1 10.1.11.1 [MPLS: Label 21 Exp 0] 2 msec 2 msec 1 msec 2 10.1.2.2 [MPLS: Label 21 Exp 0] 5 msec 6 msec 6 msec 3 10.2.12.12 2 msec 0 msec 1 msec
If MPLS labels are missing or there are connectivity issues, we need to use the troubleshooting commands covered in previous lessons to diagnose and resolve MPLS-related problems.
# show ip ospf neighbor
# show mpls ldp discovery
# show mpls ldp neighbor
# show mpls ldp binding
# show mpls forwarding-table
show ip cef
Step2: Configure BGP between PE routers
In this step, we establish an IPv4 BGP session between the Provider Edge (PE) routers. Although we do not need IPv4 BGP for advertising standard IPv4 routes, this setup is an intruction to advertise VPNv4 route between PE routers, which we will configure later. The goal of this step is to prepare the BGP infrastructure for MPLS VPN.
### PE1
router bgp 65001
bgp log-neighbor-changes
neighbor 10.10.10.12 remote-as 65001
neighbor 10.10.10.12 update-source Loopback0
neighbor 10.10.10.12 next-hop-self
### PE2
router bgp 65001
bgp log-neighbor-changes
neighbor 10.10.10.11 remote-as 65001
neighbor 10.10.10.11 update-source Loopback0
neighbor 10.10.10.11 next-hop-self
To confirm that BGP neighborships are successfully established, use the command „show ip bgp summary“.
PE1#show ip bgp summary
BGP router identifier 10.10.10.11, local AS number 65001
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.10.10.12 4 65001 5 5 1 0 0 00:01:09 0
Step3: Configure Customer VRFs
Next, we will configure VRFs on the PE routers. A VRF (Virtual Routing and Forwarding) instance is essentially a virtual router used to isolate different customers connected to the PE routers.
In future lessons, we will see that, depending on the customer’s topology, each customer requires at least one VRF on the PE routers. In our current topology, we will configure a single VRF for each customer.
To configure a VRF, we need to:
Define the VRF.
Assign the VRF to the corresponding interfaces.
Configure RD (Route Distinguisher) and RT (Route Targets) for each VRF.
### PE1 / PE2 vrf definition A rd 1:100 ! address-family ipv4 route-target export 1:100 route-target import 1:100 exit-address-family vrf definition B rd 1:200 ! address-family ipv4 route-target export 1:200 route-target import 1:200 exit-address-family ! interface Ethernet0/1 vrf forwarding A interface Ethernet0/2 vrf forwarding B
Understanding RD and RT
RD and RT are completely independent concepts, which we will discuss in detail in upcoming lessons.
For now, here’s a general idea:
RD (Route Distinguisher) is a prefix used to make overlapping customer address spaces unique. For example, if both Customer A and Customer B use the subnet 172.16.1.0/24, we can assign different RDs (e.g., 1:100 for Customer A and 1:200 for Customer B). This ensures that BGP can differentiate between customer routes when they are advertised between PE routers.
RT (Route Target) determines how connectivity between different sites of a customer is allowed. It can enforce various topologies, such as:
Hub-and-Spoke: Only certain sites (spokes) are allowed to communicate with a central site (hub).
Full-Mesh: All sites of a customer can communicate with each other directly.
In this example, for simplicity, we configure both RD and RT with the same values:
Customer A → RD & RT = 1:100
Customer B → RD & RT = 1:200
However, in real deployments, RD and RT values can be different, as they serve separate purposes.
To verify VRF configuration, one of the most useful commands is to use „show ip vrf brief“.
This command displays:
The VRF names
The interfaces assigned to each VRF
The RD values configured for each VRF
PE1#show ip vrf brief Name Default RD Interfaces A 1:100 Et0/1 B 1:200 Et0/2
Step4: Configure Connectivity Between CE and PE Routers
In this step, we will configure the connectivity between the PE (Provider Edge) and CE (Customer Edge) routers.
In this example, the CE routers use a simple static default route to forward customer traffic over the MPLS network. However, in more complex topologies— which we will discuss in upcoming lessons—a routing protocol such as OSPF, IS-IS, EIGRP, or BGP can be configured between PE and CE routers to enable dynamic routing and better scalability.
### A1 / B1
interface Ethernet0/0
no shutdown
ip address 172.16.1.2 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 172.16.1.1
### A2 / B2
interface Ethernet0/0
no shutdown
ip address 172.16.2.2 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 172.16.2.1
### PE1
interface Ethernet0/1
no shutdown
vrf forwarding A
ip address 172.16.1.1 255.255.255.0
interface Ethernet0/2
no shutdown
vrf forwarding B
ip address 172.16.1.1 255.255.255.0
### PE2
interface Ethernet0/1
no shutdown
vrf forwarding A
ip address 172.16.2.1 255.255.255.0
interface Ethernet0/2
no shutdown
vrf forwarding B
ip address 172.16.2.1 255.255.255.0
Step5: Configure VPNV4 BGP between PE routers
Next, we will extend the BGP protocol between the PE routers to enable the transfer of VPNv4 routes.
To simplify, VPNv4 is used because different customers might use the same IPv4 subnet, which can cause address overlap. Without a unique identifier, BGP cannot distinguish between the IPv4 routes of different customers. To resolve this, we introduce a Route Distinguisher (RD), which is specific to each VRF (Virtual Routing and Forwarding). The RD is prepended to the customer’s IPv4 address,
creating a unique VPNv4 prefix. This new VPNv4 prefix is what is exchanged between PE routers via BGP.
To configure the VPNv4 extension for BGP, we need to:
Activate the BGP neighborship in the VPNv4 address family.
Allow the standard and advanced communities which is actually Route Targets (RT) to be advertised between PE routers.
### PE1 router bgp 65001 address-family vpnv4 neighbor 10.10.10.12 activate neighbor 10.10.10.12 send-community both neighbor 10.10.10.12 next-hop-self exit-address-family
### PE2 router bgp 65001 address-family vpnv4 neighbor 10.10.10.11 activate neighbor 10.10.10.11 send-community both neighbor 10.10.10.11 next-hop-self exit-address-family
To troubleshoot whether the BGP neighborship is established for the VPNv4 address family, use the command „show bgp vpnv4 unicast all summary“.
PE1#show bgp vpnv4 unicast all summary
BGP router identifier 10.10.10.11, local AS number 65001
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.10.10.12 4 65001 13 13 1 0 0 00:07:58 0
Step6: Advertise Customer Routes Through VPNv4 BGP Between PE Routers
The final step is to advertise customer routes into BGP so they can be exchanged between PE routers. In this simple topology, we only have connected routes to advertise into BGP. However, in more complex scenarios, the routes can be static, from OSPF, IS-IS, EIGRP, or even BGP, which we will discuss in upcoming lessons.
To advertise customer routes via BGP, we must add a new address family in BGP for the customer’s IPv4 VRF. This is because customer interfaces are IPv4 and reside within a specific VRF. The customer’s routes are received from the IPv4 VRF and then advertised through VPNv4 between the PE routers, with the VRF RD prepended to the beginning of the IPv4 routes.
### PE1 router bgp 65001 address-family ipv4 vrf A redistribute connected exit-address-family ! address-family ipv4 vrf B redistribute connected exit-address-family
### PE2 router bgp 65001 address-family ipv4 vrf A redistribute connected exit-address-family ! address-family ipv4 vrf B redistribute connected exit-address-family
Verify MPLS VPN operation
To verify the operation of the MPLS VPN, we can now check the connectivity between customer sites, including the connections between A1 and A2, as well as between B1 and B2.
A1#traceroute 172.16.2.2 Type escape sequence to abort. Tracing the route to 172.16.2.2 VRF info: (vrf in name/id, vrf out name/id) 1 172.16.1.1 5 msec 6 msec 5 msec 2 10.1.11.1 [MPLS: Labels 21/16 Exp 0] 1 msec 6 msec 5 msec 3 10.1.2.2 [MPLS: Labels 21/16 Exp 0] 5 msec 5 msec 5 msec 4 172.16.2.1 4 msec 5 msec 5 msec 5 172.16.2.2 5 msec 1 msec 0 msec
B1#traceroute 172.16.2.2 Type escape sequence to abort. Tracing the route to 172.16.2.2 VRF info: (vrf in name/id, vrf out name/id) 1 172.16.1.1 1 msec 5 msec 6 msec 2 10.1.11.1 [MPLS: Labels 21/22 Exp 0] 1 msec 1 msec 1 msec 3 10.1.2.2 [MPLS: Labels 21/22 Exp 0] 0 msec 1 msec 0 msec 4 172.16.2.1 1 msec 0 msec 0 msec 5 172.16.2.2 1 msec 0 msec 1 msec
The output of the traceroute shows that traffic is transferred with two label stacks through the MPLS network.
The outer label is the LDP label, which forwards traffic through the LSP (Label Switched Path) between PE1 and PE2 routers. This label changes at each hop, as discussed in previous lessons on the MPLS LDP protocol.
The inner label is the VPN label, used by the destination PE router to identify which customer the traffic belongs to. This label is carried through MP-BGP along with VPNv4 routes between PE routers.
We will discuss the details of this label in an upcoming lesson on the MPLS VPN Control Plane and Data Plane concepts.
You can use the command „show to verify which VPNv4 routes are being transferred between PE routers for each VRF.
bgp vpnv4 unicast all“
#code
PE1#show bgp vpnv4 unicast all BGP table version is 7, local router ID is 10.10.10.11 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 1:100 (default for vrf A) *> 172.16.1.0/24 0.0.0.0 0 32768 ? *>i 172.16.2.0/24 10.10.10.12 0 100 0 ? Route Distinguisher: 1:200 (default for vrf B) *> 172.16.1.0/24 0.0.0.0 0 32768 ? *>i 172.16.2.0/24 10.10.10.12 0 100 0 ?
To verify the VPN labels associated with each VPNv4 route advertised through VPNv4 BGP, use the command „show
bgp vpnv4 unicast all labels“.
PE1#show bgp vpnv4 unicast all labels Network Next Hop In label/Out label Route Distinguisher: 1:100 (A) 172.16.1.0/24 0.0.0.0 20/nolabel(A) 172.16.2.0/24 10.10.10.12 nolabel/16 Route Distinguisher: 1:200 (B) 172.16.1.0/24 0.0.0.0 19/nolabel(B) 172.16.2.0/24 10.10.10.12 nolabel/22
Final MPLS VPN Configuration
This is the final configuration for the PE1 router and a single P router, providing an overview of how MPLS VPN is configured in service provider networks.
## PE1 hostname PE1 ! vrf definition A rd 1:100 ! address-family ipv4 route-target export 1:100 route-target import 1:100 exit-address-family ! vrf definition B rd 1:200 ! address-family ipv4 route-target export 1:200 route-target import 1:200 exit-address-family ! ip cef ! mpls label protocol ldp ! interface Loopback0 ip address 10.10.10.11 255.255.255.255 ! interface Ethernet0/0 ip address 10.1.11.11 255.255.255.0 mpls ip ! interface Ethernet0/1 vrf forwarding A ip address 172.16.1.1 255.255.255.0 ! interface Ethernet0/2 vrf forwarding B ip address 172.16.1.1 255.255.255.0 ! router ospf 1 network 10.0.0.0 0.255.255.255 area 0 ! router bgp 65001 bgp log-neighbor-changes neighbor 10.10.10.12 remote-as 65001 neighbor 10.10.10.12 update-source Loopback0 neighbor 10.10.10.12 next-hop-self ! address-family vpnv4 neighbor 10.10.10.12 activate neighbor 10.10.10.12 send-community both neighbor 10.10.10.12 next-hop-self exit-address-family ! address-family ipv4 vrf A redistribute connected exit-address-family ! address-family ipv4 vrf B redistribute connected exit-address-family ! mpls ldp router-id Loopback0
## P1
hostname P1
!
ip cef
!
mpls label protocol ldp
!
interface Loopback0
ip address 10.10.10.1 255.255.255.255
!
interface Ethernet0/0
ip address 10.1.11.1 255.255.255.0
mpls ip
!
interface Ethernet0/1
ip address 10.1.2.1 255.255.255.0
mpls ip
!
router ospf 1
network 10.0.0.0 0.255.255.255 area 0
!
mpls ldp router-id Loopback0