Continuing from previous blogs, it is now time to tackle another MPLS application – the L3VPN. When creating a L3VPN, conceptually speaking, you actually create a Virtual Router over an existent  MPLS core; you then dedicate that virtual router to a specific VPN – this is in contrast to L2VPNs where you end-up creating a Virtual Switch over the MPLS core.

When setting up MPLS-L3VPN, you need to understand the distinction between Route-Targets and Route-Distinguishers. 

Route-Distinguisher’s purpose is to allow routing updates within the MPLS core while ensuring uniqueness of the routes being exchanged between multiple VPNs. The Route-Distinguisher is an extension to the original IP route – it converts a standard L3 IP into a unique L3 VPN IP

The Route Distinguisher makes possible the exchange of L3 routes between two different customers (VPNs) employing the same LAN range in their network.

On the other hand, Route Targets help PE routers map the L3 VPN IP Addresses, to the respective VPNs. The Route Target is an BGP extended community attribute and therefore, it gets transported into BGP updates.

At last, MP-BGP is used between the PE routers – MP-BGP allows L3VPN IP Routes exchange between the PE routers within the respective VPNs.

In the following lab, I will be using the same core network created in a previous blog.

  • Host1 and Host2 are two different sites for the same company
  • They both connect to the Internet using a separate Internet connection provided by another provider
  • You, as another independent ISP, are running  MPLS core;
  • You could also provide a dedicated infrastructure for DNS resolution


Objective: Your sales guys approach this customer and find out they need to interconnect two of their sites in a VPN. You also find out that this company  is currently having some issues with Internet DNS resolution. It is then agreed that you will be providing both Inter-site connectivity as well as Internet DNS services.

Flip over to the next tab to see the solution.

Based on the objective set, you come up with the following solution:


The diagram above shows your solution only and it doesn’t include the current Internet access this company has already in place.

Once setup has been completed, the following will happen:

  1. You will be providing site-to-site connectivity
  2. Connectivity into your core is provided by two different carriers, VM and COLT respectively
  3. You will also be providing Internet DNS resolution; though Internet access is still kept as before, through the initial provider
  4. You will not be responsible for NAT


1. Configure MPLS in your core – this has been done already

2. Configure BGP/MP-BGP between all your PE routers – see configuration snippet below for PE1 router; PE2 and PE3 routers will have similar configuration


At this stage we have all our PE routers configured for MP-BGP – the command neighbor <nbour> send-community both allows sending extended community attributes to the specified neighbor – remember that the Route Target is an extended community attribute!

3. Creating the Virtual Router – this is done by using the ip vrf <vrfName> command. Initially, this virtual router will have no interfaces attached


Each PE router is configured with a “local” route-target which will be added/exported into outgoing BGP updates. Above, you can see the configuration for PE1, PE2 and PE3 respectively. Furthermore, each PE router will also import routes coming in BGP updates which match the route-target set in the route-target import <rt> command.

If you look at the PE1 configuration, it reads as below: “My local route-target is 65000:1 and I will set this BGP attribute on all outgoing BGP updates. I also accept BGP updates and will import into this VRF/VPN/Virtual-Router all routes which have the Route-Target attribute set to 65000:2 & 65000:3”. 

4. I will now attach interfaces to our router – if you look at the network diagram above, it becomes clear that the interfaces I will be attaching are are the ones facing the customer


5. Since the PE can have multiple VRFs/VPNs, we need to, somehow, separate each VPNs routing domain – so we need to have a separate routing table for each VPN. Once the routing-table has been created, all we need to do is redistribute routes into the BGP process attached to the VRF – so let’s set this up:


6. So we now have the routing process into which we’ll be importing routes. We also defined the criteria for importing & exporting routes to/from other PE routers with which we peer. We’ve also create the Virtual router by means of a VRF and attached interfaces to it. Next, we create the actual routes we want to import & export:


We have now concluded setting up the MPLS based L3VPN.


For DNS functionality, I’ve used the following commands:


Flip to the next tab to see test results …

You can see below how routes show up including the Route-Target and the Route-Distinguisher, in the BGP table:


Also, see below the ping result as well as the DNS resolution:


Go back to Index


Thank you,
View Rafael A Couto Cabral's profile on LinkedIn

Leave a reply

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>