alexa Architecture for MPLS L3 VPN Deployment in Service Provider Network | Open Access Journals
ISSN: 2167-0919
Journal of Telecommunications System & Management
Make the best use of Scientific Research and information from our 700+ peer reviewed, Open Access Journals that operates with the help of 50,000+ Editorial Board Members and esteemed reviewers and 1000+ Scientific associations in Medical, Clinical, Pharmaceutical, Engineering, Technology and Management Fields.
Meet Inspiring Speakers and Experts at our 3000+ Global Conferenceseries Events with over 600+ Conferences, 1200+ Symposiums and 1200+ Workshops on
Medical, Pharma, Engineering, Science, Technology and Business

Architecture for MPLS L3 VPN Deployment in Service Provider Network

Ravi Kumar CV*, Dhanumjayulu C, Bagubali A and Bagadi KP

School of Electronics Engineering, VIT University, India

*Corresponding Author:
Ravi Kumar CV
School of Electronics Engineering
VIT University, India
Tel: 9751282729
E-mail: [email protected]

Received Date: March 24, 2017; Accepted Date: March 31, 2017; Published Date: April 11, 2017

Citation: Ravi Kumar CV, Dhanumjayulu C, Bagubali A, Bagadi KP (2017) Architecture for MPLS L3 VPN Deployment in Service Provider Network. J Telecommun Syst Manage 6: 152. doi: 10.4172/2167-0919.1000152

Copyright: © 2017 Ravi Kumar CV, et al. This is an open-access article distributed under the terms of the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.

Visit for more related articles at Journal of Telecommunications System & Management


Now a days in Service Provider’s core network we do not use IP forwarding rather we go for MPLS because it gives more efficient switching of packets. MPLS is the combination of layer-3 routing and layer-2 switching because every network prefix is assigned a particular Label. In this paper I am going to do testing and implement scalability over MPLS L3 VPN. This testing and implementation are to proof the scalability is the one important thing when design MPLS L3 VPN technology. This Topology of MPLS L3 VPN also provides the secure tunnel between two customer sites. By this implementation we show that there is a transparent tunneling over SP network. We are also avoiding the BGP implementation In SP core. So we call it as BGP free core. This implementation also saves the routing table space on provider routers. We have used the concept of Route Reflector (RR) to avoid more BGP sessions and to make it more scalable.


Architecture; Communications; Virtual private networks; Topology


SP: Service Provider; BGP: Border Gateway Protocol; MPLS: Multi Protocol Label Switching; VPN: Virtual Private Network; OSPF: Open Shortest Path First



In SP’s core network labels are shared between routers using LDP. Label is associated with next-hop IP address. First router will tell the path to follow. All packets that enter the MPLS network get a label depending on is used for incoming unlabeled packets where the router matches the packet’s destination IP address to the best prefix in the FIB and forwards the packet base on that entry. The LFIB is used for incoming labeled packets. In this case, the router compares the label in the incoming packet to the list of labels in the LFIB and forwards the packet based on that LFIB entry [1].


Network connection between devices that do not literally share a physical cable is called VPN. VPN (Virtual Private Network) is simply a way of using a public network for private communications, among a set of users and/or sites [1].

Remote access

Most common form of VPN is dial-up remote access to corporate database-for example, road warriors connecting from laptops.

Site-to-site: Connecting two local networks (may be with authentication and encryption)-for example, a Service Provider connecting two sites of the same company over its shared network.

MPLS VPN uses the power of multiprotocol label switching (MPLS) to create virtual private networks (VPNs). MPLS based Layer 3 virtual private networks (VPNs) allows us to securely connect geographically diverse sites across an MPLS network. MPLS services can be used to connect various sites to a backbone network and to ensure better performance for low-latency applications such as voice over IP (VoIP) and other business-critical functions. Layer 3 VPN utilizes layer 3 VRF (VPN/virtual routing and forwarding) to segment routing tables for each “customer” utilizing the service. The customer router peers with the service provider edge (PE) router and the two exchange routes, which are then placed into a routing table specific to that customer. MP-BGP (Multiprotocol BGP) is required in the cloud to exchange the VPNv4 routes [2].


This is the topological implementation of MPLS L3 VPN in GNS3. In the Figure 1 topology we have 4 PE’s, 2 P’s and 7 CE’s. We have made one of the PE as Route Reflector to avoid more iBGP sessions. In the topology we have 3 cisco sites, 2 Google sites and 2 VIT sites. Cisco sites are exchanging their routes with other cisco sites but not with any other company sites.


Figure 1: MPLS L3 VPN GNS3 topology.

Requisites for Running MPLS L3 VPNs

Basic IP reachability, IGP running, Cisco Express Forwarding (CEF), MPLS, Label Distribution Protocol (LDP), BGP VPNv4 session between the PEs.


By creating VRFs we ensure that a virtual router is created inside IOS which has its own routing table. And that routing table is different than global routing table. Whenever we want to differentiate between routes of two companies like in this topology I have 3 Cisco sites 2 Google sites and 2 VIT sites so all can use same Private IP addresses space but they are differentiated by using Route distinguisher which is the characteristics of VRF. While configuring VRF in IOS we have to specify route distinguisher and then Route Targets which are extended communities.


It is the best of both worlds from overlay VPNs and peer to peer VPNs. In MPLS L3 VPN no static provisioning is required. Whenever we want to add new sites we can add very easily without reconfiguring other existing sites. In MPLS VPN Service provider keeps separate routing tables per customer. It gives flexibility in customer addressing. In MPLS L3 VPN manual route and ACL filtering is not required in Service Providers. Customers can use default routing as needed [3].

How MPLS L3 VPN works

MPLS L3 VPN has two basic components. Separation of customer routing information.

• VRF - Virtual routing and forwarding instance.

• Different customers have different “Virtual routing tables”.

• IGP/BGP run inside the VRF between the customer and SP. Exchange of customer’s routing information inside SP.

• It uses Multi-Protocol BGP through the SP network to share customer’s route.

• Traffic destined for customer is label switched towards BGP next hop.

VPN Route Distribution-Route Targets.

• “Export” Route Target: Every VPN route is tagged with one or more route targets when it is exported from a VRF (to be offered to other VRFs).

• “Import” Route Target: A set of routes targets can be associated with a VRF, and all routes tagged with at least one of those route targets will be inserted into the VRF.

Transport label vs. VPN label

L3VPN needs at least 2 labels to deliver traffic can be more with applications like MPLS TE, FRR etc.

Transport label: It tells the SP core routers which PE Traffic is destined to. It is derived from LDP or we can say that it is the MPLS label which is swapped in MPLS core network. It is also called the IGP label.

VPN label: This label is below the MPLS label so it is exposed to PE routers only and based on these label PE routers can know which CE the traffic should go [4].

Controlling VPNv4 routes: Route distinguisher is used to make route unique. Rd allows for overlapping IPv4 addresses between customers. BGP extended community “route-target” is used to control what enters/exits into VRF table. “Export” route-target-what routes will go from VRF into BGP. “Import” route-target-what routes will go from BGP into VRF. These route-targets allow us to control what sites have what routes.


VRF configurations on R2

Here in configuration we can see we have two VRFs, one is for cisco customers and one for Google customers and for these VRFs we have route-targets defined. Routes are being redistributed from BGP to VRF so that one site of company can get access to another (Figure 2).


Figure 2: VRF configurations on R2.

MBGP configuration on R2

As mentioned before MBGP is used to share VPnv4 routes (Figure 3).


Figure 3: MBGP configuration on R2.

Route-reflector configurations on R3

Route-Reflector is used for scalability purpose because when you have more PEs you can’t establish sessions with all the PEs so to avoid this we have Route-Reflector so that each and every PE can establish iBGP session only VRF aware OSPF is used for PE-to-CE routing RR (Figure 4).


Figure 4: Route-reflector configurations on R3.

PE-to-CE routing configuration with VRF

Details mentioned in Figure 5.


Figure 5: PE-to-CE routing configuration with VRF.


Son R20 we have loopback0 with address which is in vrf cisco1 so need to get this route to R1 which is also in same VRF (Figure 6).


Figure 6: R1’s routing table.

As we can see is highlighted in R1’s routing table. Connectivity check between R1 and R20: I have initiated ping from R1’s Loopback0 to R20’s Loopback 0 which is (Table 1 and Figure 7).

Source IP Destination IP No of packets Min time Avg time Max time 10 232ms 290 ms 404 ms 100 176 ms 246ms 376 1000 140 ms 246 ms 376 ms

Table 1: R1’s routing table.


Figure 7: Connectivity check between R1 and R20.

As we see in Table 1 when we sent first set of packets it is taking more time because first the destination is not available in CEF table so it builds when we first try to reach any destination and then uses that to forward packets so it take less time [5].

Testing Best Practices

Using RR for scaling BGP-Deploy RRs in pair for the redundancy. Keep RRs out of the forwarding paths and disable CEF (it saves memory).

Choose AS format for RT and RD i.e., ASN: X Reserve first few 100s of X for the internal purposes such as filtering.

Don‘t use customer names as the VRF names; difficult for NOC. Consider A101, A102, A201 etc. and use description for naming.

Consider unique RD per VRF per PE.

Limit the number of prefixes per-VRF and/or per-neighbor on PE.

Utilize SP‘s public address space for PE-CE IP addressing.


Using this model of MPLS L3 VPN we can deploy a small size service provider network and scale it to a bigger. In this topology we have shown how to deploy a service provider network. For future work this topology can be taken as reference to deploy all kind of SP network and we have included some important configuration also those will help audience to understand the topology and network very easily. While deploying network in future people might need to configure on different platform but the basic of MPLS L3 VPN remains same and the scalability measures will remain same so you can adopt this method of deploying of SP network.


First of all I wish to give my gratitude to prof. Kala Praveen Bagadi who guided me to complete this paper and helped me a lot while configuring and testing this network. Secondly I would like to thank my colleagues who helped me and guided me all the way till the completion of this paper..


Select your language of interest to view the total content in your interested language
Post your comment

Share This Article

Relevant Topics

Article Usage

  • Total views: 494
  • [From(publication date):
    April-2017 - Sep 24, 2017]
  • Breakdown by view type
  • HTML page views : 441
  • PDF downloads :53

Post your comment

captcha   Reload  Can't read the image? click here to refresh

Peer Reviewed Journals
Make the best use of Scientific Research and information from our 700 + peer reviewed, Open Access Journals
International Conferences 2017-18
Meet Inspiring Speakers and Experts at our 3000+ Global Annual Meetings

Contact Us

Agri, Food, Aqua and Veterinary Science Journals

Dr. Krish

[email protected]

1-702-714-7001 Extn: 9040

Clinical and Biochemistry Journals

Datta A

[email protected]

1-702-714-7001Extn: 9037

Business & Management Journals


[email protected]

1-702-714-7001Extn: 9042

Chemical Engineering and Chemistry Journals

Gabriel Shaw

[email protected]

1-702-714-7001 Extn: 9040

Earth & Environmental Sciences

Katie Wilson

[email protected]

1-702-714-7001Extn: 9042

Engineering Journals

James Franklin

engine[email protected]

1-702-714-7001Extn: 9042

General Science and Health care Journals

Andrea Jason

[email protected]

1-702-714-7001Extn: 9043

Genetics and Molecular Biology Journals

Anna Melissa

[email protected]

1-702-714-7001 Extn: 9006

Immunology & Microbiology Journals

David Gorantl

[email protected]

1-702-714-7001Extn: 9014

Informatics Journals

Stephanie Skinner

[email protected]

1-702-714-7001Extn: 9039

Material Sciences Journals

Rachle Green

[email protected]

1-702-714-7001Extn: 9039

Mathematics and Physics Journals

Jim Willison

[email protected]

1-702-714-7001 Extn: 9042

Medical Journals

Nimmi Anna

[email protected]

1-702-714-7001 Extn: 9038

Neuroscience & Psychology Journals

Nathan T

[email protected]

1-702-714-7001Extn: 9041

Pharmaceutical Sciences Journals

John Behannon

[email protected]

1-702-714-7001Extn: 9007

Social & Political Science Journals

Steve Harry

[email protected]

1-702-714-7001 Extn: 9042

© 2008-2017 OMICS International - Open Access Publisher. Best viewed in Mozilla Firefox | Google Chrome | Above IE 7.0 version