Step-by-step guide to configure the MPLS-L3VPN in GNS3

MPLS Layer 3 VPN (L3VPN) is one of the most widely used technologies in enterprise and service provider networks, enabling secure and scalable communication between different sites. 
MPLS L3VPN might sound complex, but once broken down into clear steps, it becomes much easier to understand. 
In this blog, we will use GNS3 to create a practical MPLS L3VPN setup from scratch, covering everything from PE-CE routing to VRF configurations along with MPLS backbone configuration.

To understand easily we will use the below lab setup – 

Below is a summary of the routers used in this lab:

• R1 and R5: Provider Edge (PE) routers.
• R2, R3, and R4: Provider/Core (P) routers.
• R6 and R8: Customer Edge (CE) routers for Customer A.
• R7 and R9: Customer Edge (CE) routers for Customer B.

I have structured the configuration steps into three parts for easy understanding:

1. ISP Readiness-OSPF, MPLS, and LDP configuration on the MPLS Core routers (R1 to R5)
2. VRF setup on the PE router and PE-CE configuration (R1 and R5)
3. MP-BGP configuration and redistribution of customer routes into MP-BGP (R1 and R5)

I hope the lab topology is clear to you. If you closely examine the WAN IP address schema for Customer A and Customer B, you’ll notice that both have the same IP addresses. You might wonder—how will this work? Won’t there be a conflict at the PE router?

Well, that’s the beauty of MPLS and VRF! These routes are not installed in the global routing table of the router. Instead, they are placed in separate VRF routing tables, ensuring that each VRF remains isolated. As a result, there is no IP conflict, and we can even use the same LAN subnet for multiple customers. However, in this lab, we are using different LAN pools for better understanding.

Now, let’s begin the configuration with the first step.

1. OSPF, MPLS, and LDP configuration on the MPLS Core routers (R1 to R5):

1.1 MPLS Label Range Assignment

To simplify understanding of MPLS label allocation, we will assign a specific label range to each router as follows:

• R1: 100 to 200
• R2: 201 to 300
• R3: 301 to 400
• R4: 401 to 500
• R5: 501 to 600

1.2 Loopback Address Configuration

Each router will have a loopback address configured, which will be used for LDP and OSPF peering. The assigned loopback IPs are:

• R1: 1.1.1.1/32
• R2: 2.2.2.2/32
• R3: 3.3.3.3/32
• R4: 4.4.4.4/32
• R5: 5.5.5.5/32

1.3 OSPF Configuration

We will enable OSPF on all routers, using Area 0 throughout the MPLS core.

1.4 IP Addressing & MPLS Enablement

• Configure IP addresses on all interfaces.
• Enable MPLS on interfaces that are part of the MPLS domain.
• To activate MPLS on a router, apply the mpls ip command on the required interfaces.
• Note: Interfaces connecting to customer networks (e.g. R1’s f0/0 and f3/0) will not be included in the MPLS domain.
• Configuration of Routers –

That’s great! Now, let’s verify the OSPF and LDP status along with network reachability.

From R1, we can successfully ping the loopback IP of R5, confirming end-to-end connectivity. Additionally, the OSPF and LDP neighborships have been successfully established.

Perfect! We have successfully completed the first step of our configuration, and the MPLS backbone is now ready to support MPLS L3VPN connectivity for multiple customers.

Lets move ahead for step no 2.

2. VRF setup on the PE router and PE-CE configuration (R1 and R5):

2.1 Create the VRF at PE router and configure the RD and RT – 

In this step we will configure the VRF for two customer (Customer A and Customer B), on which we will use the below parameter – 

Customer A – 

Route target import and export – 100:100

Customer B – 

Route target Import and Export – 200:200

In this example we use the Full mesh topology for the both customer. in the full mesh topology the RT(Route target) value of import and export are same.

Route Distinguisher – 

A Route Distinguisher (RD) is a unique identifier added to VPN routes to differentiate overlapping IP prefixes in an MPLS L3VPN environment. It ensures that identical IP subnets from different customers remain distinct within the provider’s network by prepending a unique RD value to each route.

Route Target (RT) –

A Route Target (RT) is a BGP extended community attribute used to control the import and export of VPN routes between VRFs in an MPLS L3VPN. It allows service providers to define which VPN routes should be shared between different sites by tagging them with specific RT values.2.2 Configure the WAN IP addresses for both customers on the PE end, and set up static routes towards the LAN pools of Customer A and Customer B.

2.3 For the customer edge (CE) devices, assign an IP address to the WAN interface and configure a loopback interface to represent the LAN, assigning it an appropriate IP address.

To advertise the LAN pool to the ISP, either a static or dynamic routing protocol can be used.

In this setup, we are using a static routing protocol, so configure a static default route on the CE device.

Customer_A CE device configuration – 

Customer_B CE device configuration – 

Great! We have successfully completed the second step of the configuration. However, if you examine the routing table of VRF Customer_A and Customer_B, you’ll notice that only locally connected and static routes are present. The routes from the remote site are missing from the routing table.

So, how do we advertise these routes to the remote site? Ensuring proper route exchange is crucial so that both sites of Customer_A can communicate seamlessly.

Additionally, I have verified the connectivity from the PE to the Customer LAN and successfully pinged the Customer LAN from the PE end. However, I am still unable to reach the remote site’s LAN. To achieve this reachability, MP-BGP will play a crucial role. Now, let’s proceed to the third step.

Routing table of Customer_A and Customer_B vrf –

At R1 Side – 

At R5 side – 

3. MP-BGP configuration and redistribution of customer routes into MP-BGP: Alright, my friends, let’s take a moment to recap what we have done so far and understand why MP-BGP is essential.

Recap of Our Progress:

1. Step 1: ISP Core Configuration
   • We configured all ISP-end devices and established reachability within the ISP network.
   • For this, we used OSPF as the IGP routing protocol.
   • MPLS was enabled using LDP (Label Distribution Protocol) by default.
2. Step 2: Customer Connectivity Setup
   • We created VRFs (Virtual Routing and Forwarding) on the PE routers to separate customer traffic.
   • We also configured the customer-end devices.

At this point, the setup is limited to individual customer sites. However, our goal is to establish inter-site connectivity between multiple customer locations.

How Do We Exchange Routes Between Sites?

To achieve site-to-site connectivity, we need to exchange routes between the two customer locations. This raises an important question:

👉 Can we use any dynamic routing protocol for this?
👉 Or are we restricted to using only BGP?

The Answer: No!

For exchanging routes between sites, we must use MP-BGP (Multiprotocol BGP).

Why Do We Need MP-BGP?

Let’s break it down:

• In our setup, customers at different sites might be using the same WAN IP address or even the same LAN subnet.
• Normally, this would cause a conflict. However, since each customer belongs to a separate VRF, there is no issue at the PE router.
• The real challenge arises when these routes need to traverse the ISP’s MPLS network. How do we differentiate them?

The Solution: Route Distinguisher (RD)

• The RD (Route Distinguisher) is added to customer prefixes, making them unique.
• This transforms a standard IPv4 route into a VPNv4 route (or VPNv6 for IPv6 networks).
• As a result, our address space expands from 32-bit (IPv4) to 96-bit (VPNv4).

How Are VPNv4 Routes Advertised?

This is where MP-BGP comes into play.

• MP-BGP allows us to advertise and carry VPNv4/VPNv6 routes across the MPLS backbone.
• It ensures that customer traffic remains isolated while enabling communication between sites.

Configuration –

That’s it. Now lets check the BGP status – 

Yes, the BGP status is showing as UP.

Have there been any changes in the routing table of the Customer VRF?

Let’s verify it.

Customer_A VRF – 

Customer_B VRF – 

That’s exactly what we were expecting! Now, the VRF routing table displays all the remote site subnets.

Lets check the VPNv4 Routes at PE end – 

At Router R1 – 

At Router R5 – 

Finally, let’s verify the end-to-end connectivity from the customer edge device—

LAN-to-LAN reachability for Customer_A:

LAN-to-LAN reachability of Customer_B

In conclusion, by following the configuration steps outlined in this blog, we’ve effectively established a secure and scalable MPLS L3VPN connection between customer sites. The integration of MP-BGP ensures seamless route exchange, making the communication between sites possible, even with overlapping address spaces. As we’ve seen, this setup allows for greater flexibility and scalability in handling complex network topologies.

This process is a fundamental part of modern enterprise networks, providing reliable connectivity, security, and isolation for multiple customer sites. By leveraging the power of MP-BGP, MPLS, and VRFs, we’ve created a robust solution that can easily scale as network demands grow.

Thank you for following along, and we hope this guide helps you implement and understand MPLS L3VPN in your own network environments!

Thank you 😊