How to Set Up an MPLS VPN

In this tutorial, we'll go through setting up a basic MPLS VPN network using MP-BGP (Multi-Protocol Border Gateway Protocol) with just two VRFs (Virtual Routing and Forwarding) instances. This setup will help to illustrate the core configuration steps and key concepts. Below is a diagram of the network topology we will be working with, but first, what exactly are MPLS VPN, MP-BGP, and VRFs?

Here is a breakdown of MPLS VPN, MP-BGP, and VRFs in the context of networking:

1. MPLS VPN (Multiprotocol Label Switching Virtual Private Network)

MPLS VPN is a technology that allows service providers to create virtual private networks over their core MPLS (Multiprotocol Label Switching) infrastructure. Using MPLS, packets are directed through the network using labels rather than traditional IP-based routing. This approach provides the following:

• Improved performance, as label-based forwarding is proven to be faster than standard IP routing.

• Isolation between adjacent networks, enabling multiple VPNs to exist on the same infrastructure with overlapping conflicts.

• Enhanced scalability, as it reduces routing table size on core, edge, boundary, and perimeter routers.

In an MPLS VPN, customer data remains isolated from other VPNs even when they're sharing the same physical infrastructure.

❓But. Why use an MPLS VPN configuration when you can just add VPN servers to their own DMZ or VLAN?

You can implement multiple VPN servers within a DMZ (Demilitarized Zone) of different VLANs (Virtual Local Area Networks) as an alternative to using an MPLS VPN. Here's how this approach compares and what to consider:

Using DMZs or VLANs for Multiple VPN Servers

Using an MPLS VPN configuration offers several advantages over simply adding VPN servers to a DMZ or VLAN.

First, MPLS (Multiprotocol Label Switching) provides a more scalable and efficient way to manage traffic across a Wide Area Network (WAN). It allows for the creation of VPNs that can span multiple sites while ensuring consistent performance and low latency. This is particularly beneficial for organizations with geographically dispersed branches, as MPLS can prioritize traffic and manage bandwidth more effectively than traditional routing.

Second, MPLS VPNs enhance security by isolating customer traffic within the service provider's network. Each MPLS VPN is logically separated, ensuring that data from one customer does not mix with another's, even if they share the same physical infrastructure. This level of segregation is harder to achieve with traditional VLANs or DMZ setups.

Additionally, MPLS VPNs simplify network management. With a centralized management framework in place, you can more easily configure, monitor, and troubleshoot connections across multiple sites. This is especially useful for enterprises that require quick adjustments to their network configurations due to changing business needs.

Finally, MPLS VPNs can provide better Service Level Agreements (SLAs) in terms of uptime, latency, and performance guarantees, which are crucial for businesses that rely on consistent and reliable connectivity for critical applications, and while using multiple VPN servers is feasible for small to medium setups, scaling can become challenging as the number of clients increases. Managing numerous servers may lead to higher administrative overhead. Overall, while DMZs and VLANs can provide some level of isolation, MPLS VPNs offer a more robust, secure, and efficient solution for complex network environments.

❓Can't you just implement virtualization if scaling physical VPN servers becomes too challenging?

Using virtualization can effectively address many challenges associated with scaling multiple VPN servers in small to medium setups. It allows multiple VPN servers to run on a single physical host, optimizing resource usage such as CPU, memory, and storage. This efficiently reduces hardware costs and minimizes the physical footprint and attack surface, as well. Furthermore, virtualized environments can be managed through centralized platforms like VMware vSphere, Microsoft Hyper-V, or OpenStack, simplifying administration, monitoring, and maintenance of multiple VPN instances.

Virtualization also enhances scalability, as virtual machines (VMs) can be quickly deployed, cloned, or resized to accommodate growth. Adding new VPN servers becomes straightforward with virtualization - simply create a new VM. This rapid deployment capability allows for quick replication of existing VPN configurations, which is advantageous for scaling operations. Each virtual server operates in its own isolated environment, enhancing security and reducing the risk of interference between different VPN clients or services.

Moreover, virtual machines can be easily backed up and restored, facilitating quicker recovery from failures and maintaining uptime. Virtualization also allows for load balancers to distribute traffic across multiple VPN servers, improving performance and reliability. It also provides a flexible platform for testing new VPN configurations or services without impacting production systems, facilitating better planning and deployment.

However, while virtualization simplifies certain aspects of server administration and management, it can introduce complexity in the overall infrastructure. Managing virtual networks and ensuring proper configurations across multiple VMs can require significant expertise. Additionally, virtualization may introduce some performance overhead compared to running dedicated physical servers, potentially impacting performance and availability, especially in high-throughput VPNs.

Moreover, while basic VPN functionality can be achieved with virtualized servers, advanced features like traffic engineering, QoS management, and multi-tenancy, which are offered by MPLS VPN infrastructures, may be missed. The dependency on the underlying physical infrastructure can also pose risks, as any issues at the hardware level can impact all virtualized instances running on that hardware.

In conclusion, using virtualization is a most practical and effective solution for scaling multiple VPN servers, particularly in small to medium setups, as it helps reduce administrative overhead and improves resource efficiencies; however, it may lack some advanced capabilities and benefits provided by an MPLS VPN infrastructure, especially for larger organizations or those requiring robust traffic management and security features. The choice between virtualization for VPN servers and an MPLS VPN configuration should be based on specific organizational needs, growth expectations, budget constraints, and required features and enhancements, as each approach has its own unique strengths and limitations.

2. MP-BGP (Multiprotocol Border Gateway Protocol)

MP-BGP, or Multiprotocol Border Gateway Protocol, is an extension of BPG designed to support multiple network layer protocols. While traditional BGP primarily handles IPv4 addresses, MP-BGP enables the routing of different types of addresses, including IPv6, multicast, and VPNs. This capability is crucial for service providers and enterprises that need to manage diverse network environments and facilitate inter-provider communications.

3. VRF (Virtual Routing and Forwarding)

Virtual Routing and Forwarding (VRF) is a technology that allows multiple instances of a routing table to coexist within the same router. Each VRF instance operates independently, enabling the segmentation of network traffic and the creation of isolated networks without requiring additional hardware. This is particularly beneficial in scenarios such as service provider environments, where multiple customers may share the same physical infrastructure while maintaining separate, secure, and independent networks. VRFs work hand-in-hand with MP-BGP, as they allow for the efficient distribution of routes among different VRFs, enhancing network scalability and flexibility.

So, back to the main discussion at-hand; and our network topology:

In the diagram above, three routers are interconnected. Routers R1 and R3 each have two loopback interfaces. The Loopback 0 interface will be utilized to establish a BGP neighbor adjacency, while the Loopback 1 interfaces will be assigned to two distinct VRFs named VRF Blue and VRF Red.

To start, we will configure OSPF (Open Shortest Path First) to ensure that R1 and R3 can reach each other's Loopback 0 interface.

R1(config)#router ospf 1
R1(config-router)#network 192.168.12.1 0.0.0.0 area 0
R1(config-router)#network 1.1.1.1 0.0.0.0 area 0

R2(config)#router ospf 1
R2(config-router)#network 192.168.12.2 0.0.0.0 area 0
R2(config-router)#network 192.168.23.2 0.0.0.0 area 0

R3(config)#router ospf 1
R3(config-router)#network 192.168.23.3 0.0.0.0 area 0
R3(config-router)#network 3.3.3.3 0.0.0.0 area 0

‼ Make sure you configure a /32 network mask on the Loopback0 interfaces. Otherwise, you will run into issues with MPLS because OSPF by default will always advertise a loopback interface as a /32.

We'll continue by configuring MPLS on the interfaces of all routers as such:

R1(config)#interface fastEthernet 0/0
R1(config-if)#mpls ip

R2(config)#interface fastEthernet 0/0
R2(config-if)#mpls ip

R2(config)#interface fastEthernet 1/0
R2(config-if)#mpls ip 

R3(config)#interface fastEthernet 0/0
R3(config-if)#mpls ip

Enabling MPLS is simple enough. Let's now verify that we have adjacent neighbors:

R2#show mpls ldp neighbor 
    Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 192.168.23.2:0
	TCP connection: 1.1.1.1.646 - 192.168.23.2.35345
	State: Oper; Msgs sent/rcvd: 7/7; Downstream
	Up time: 00:00:21
	LDP discovery sources:
	  FastEthernet0/0, Src IP addr: 192.168.12.1
        Addresses bound to peer LDP Ident:
          192.168.12.1    1.1.1.1         
    Peer LDP Ident: 3.3.3.3:0; Local LDP Ident 192.168.23.2:0
	TCP connection: 3.3.3.3.646 - 192.168.23.2.45741
	State: Oper; Msgs sent/rcvd: 7/7; Downstream
	Up time: 00:00:03
	LDP discovery sources:
	  FastEthernet1/0, Src IP addr: 192.168.23.3
        Addresses bound to peer LDP Ident:
          192.168.23.3    3.3.3.3   

Fair enough. R2 has two MPLS LDP neighbors. If you are interested, you can also take a look at the labels that are in use:

R1#show mpls forwarding-table 
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop    
tag    tag or VC   or Tunnel Id      switched   interface              
16     17          3.3.3.3/32        0          Fa0/0      192.168.12.2 
17     Pop tag     192.168.23.0/24   0          Fa0/0      192.168.12.2

R2#show mpls forwarding-table 
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop    
tag    tag or VC   or Tunnel Id      switched   interface              
16     Pop tag     1.1.1.1/32        0          Fa0/0      192.168.12.1 
17     Pop tag     3.3.3.3/32        0          Fa1/0      192.168.23.3

R3#show mpls forwarding-table 
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop    
tag    tag or VC   or Tunnel Id      switched   interface              
16     Pop tag     192.168.12.0/24   0          Fa0/0      192.168.23.2 
17     16          1.1.1.1/32        0          Fa0/0      192.168.23.2

With MPLS running and labels actively being advertised, we can continue and create the two VRFs:

R1(config)#ip vrf BLUE
R1(config-vrf)#rd 100:1
R1(config-vrf)#route-target export 100:1
R1(config-vrf)#route-target import 100:3

VRF Blue will be created on R1. We will use RD (Route Distinguisher) 100:1 for VRF Blue and 100:3 for VRF Red. Now, we can create a new loopback and add it to our VRF:

R1(config)#interface loopback1
R1(config-if)#ip vrf forwarding BLUE
R1(config-if)#ip address 11.11.11.11 255.255.255.0

Loopback 1 has an IP address and is added to VRF Blue. Now, let's do the same thing on R3:

R3(config)#ip vrf RED
R3(config-vrf)#rd 100:3
R3(config-vrf)#route-target export 100:3
R3(config-vrf)#route-target import 100:1

R3(config)#interface loopback 1
R3(config-if)#ip vrf forwarding RED
R3(config-if)#ip address 33.33.33.33 255.255.255.0

On R3, we'll create VRF Red and use 100:3 as the RD. Now, we can finally configure BGP on both routers:

R1(config)#router bgp 13
R1(config-router)#neighbor 3.3.3.3 remote-as 13
R1(config-router)#neighbor 3.3.3.3 update-source loopback 0
R1(config-router)#address-family vpnv4 
R1(config-router-af)#neighbor 3.3.3.3 activate 
R1(config-router-af)#neighbor 3.3.3.3 send-community extended 
R1(config-router-af)#exit
R1(config-router)#address-family ipv4 unicast vrf BLUE
R1(config-router-af)#redistribute connected 

R3(config)#router bgp 13
R3(config-router)#neighbor 1.1.1.1 remote-as 13
R3(config-router)#neighbor 1.1.1.1 update-source loopback 0
R3(config-router)#address-family vpnv4 
R3(config-router-af)#neighbor 1.1.1.1 activate 
R3(config-router-af)#neighbor 1.1.1.1 send-community extended 
R3(config-router-af)#exit
R3(config-router)#address-family ipv4 unicast vrf RED
R3(config-router-af)#redistribute connected

In the configuration above, we set up several key elements for BGP:

First, we established a BGP neighbor adjacency between the Loopback 0 interfaces of R1 and R3.

Next, we enabled the VPNv4 address family on both routers to facilitate the exchange of VPN routes. We also ensured that the routers are configured to send extended community attributes to one another.

Finally, we redistributed the Loopback 1 interfaces into their respective VRFs on both routers, allowing for effective traffic segmentation within the network.

Let's verify our configuration:

R1#show bgp vpnv4 unicast all summary 
BGP router identifier 11.11.11.11, local AS number 13
BGP table version is 3, main routing table version 3
2 network entries using 274 bytes of memory
2 path entries using 136 bytes of memory
2/1 BGP path/bestpath attribute entries using 248 bytes of memory
1 BGP extended community entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 682 total bytes of memory
BGP activity 2/0 prefixes, 2/0 paths, scan interval 15 secs

Neighbor  V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
3.3.3.3   4    13       7       5        3    0    0 00:02:29        1

R3#show bgp vpnv4 unicast all summary 
BGP router identifier 3.3.3.3, local AS number 13
BGP table version is 5, main routing table version 5
3 network entries using 411 bytes of memory
3 path entries using 204 bytes of memory
3/2 BGP path/bestpath attribute entries using 372 bytes of memory
2 BGP extended community entries using 48 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1035 total bytes of memory
BGP activity 7/4 prefixes, 7/4 paths, scan interval 15 secs

Neighbor  V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1   4    13      25      26        5    0    0 00:04:44        1

R1 and R3 have received a prefix from each other. Let's find out what they got:

R1#show bgp vpnv4 unicast all 
BGP table version is 13, local router ID is 11.11.11.11
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 100:1 (default for vrf BLUE)
*> 11.11.11.0/24    0.0.0.0                  0         32768 ?
*>i33.33.33.0/24    3.3.3.3                  0    100      0 ?
Route Distinguisher: 100:3
*>i33.33.33.0/24    3.3.3.3                  0    100      0 ?

R3#show bgp vpnv4 unicast all 
BGP table version is 5, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 100:1
*>i11.11.11.0/24    1.1.1.1                 0    100      0 ?
Route Distinguisher: 100:3 (default for vrf RED)
*>i11.11.11.0/24    1.1.1.1                  0    100      0 ?
*> 33.33.33.0/24    0.0.0.0                  0         32768 ?

The routers learned about each other's networks. Let's see if they can ping each other:

R1#ping vrf BLUE 33.33.33.33 source loopback 1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 33.33.33.33, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms

Great! We've established reachability between the two routers. Remember to specify the VRF when pinging between R1 and R3. The example provided can be easily adjusted if you want to test OSPF, EIGRP, or RIP - simply replace "redistribute connected" with the desired routing protocol.

I hope you found this information helpful! If you have any questions, please drop us a line below!

Happy Setting Up MPLS VPN!

Rate This Article

Thanks for reading: How to Set Up an MPLS VPN, Sorry, my English is bad:)