How to build MPLS network

How to build MPLS network with 6WIND Virtual Service Router? 6WIND has been a leader in the network software industry for over 2 decades and today’s network evolution is towards defining function virtualization at the service infrastructure. At 6WIND, we are constantly reinventing how tomorrow’s networks would look like.

As a start to a multiple-blog series, we will introduce in this first part, how the Virtual Service Router designed by 6WIND can leverage the requirements of a light virtual Provider Edge functionality. The aim of these writings is to introduce our readers to the virtualized routing functions that are available with the 6WIND Virtual Service Router and how it can be used to build your MPLS networks.

1. What is MPLS network?

Multiprotocol Label Switching (MPLS) is a routing technique in telecommunications networks that directs data from one node to the next based on short path labels rather than long network addresses, thus avoiding complex lookups in a routing table and speeding traffic flows. The labels identify virtual links or paths (LSP – Label Switched Path) between distant nodes rather than endpoints. MPLS can encapsulate packets of various network protocols, hence the “multiprotocol” reference on its name. MPLS, in its original designs, supports a range of access technologies, including T1/E1, ATM, Frame Relay, DSL and Ethernet.

Virtual routing and forwarding (VRF) is a technology that allows multiple instances of a routing table to co-exist within the same Virtual Border Router at the same time. One or more logical or physical interfaces may belong to a VRF and these VRFs do not share routes (unless explicit leaking is configured) therefore the packets are only forwarded between interfaces within the same VRF.

VRFs can be defined as the TCP/IP layer 3 equivalent of a VLAN. Because the routing instances are independent, the same or overlapping IP addresses can be used in a given VRF without conflicting with other instances. Network functionality is improved because network paths can be segmented without requiring multiple routers.

A Route Distinguisher (RD) separates routes (one VRF for each customer routing table) of one customer from another. RD is prepended to each route (64-bit identifier is prepended) within a VRF to identify which VPN the route belongs to. An RD is carried along with a route via MP-BGP when exchanging VPN routes with other PE routers.

Route Target is a 64-bit identifier used as part of MP-BGP attribute (extended community) to identify which route should be exported or imported to specific VPN. Whereas route distinguishers are used to maintain uniqueness among identical routes in different VRFs, route targets can be used to share routes among them. We can apply route targets to a VRF to control the import and export of routes.

2. How can 6WIND help you build your MPLS Network?

Network Virtual Functions is becoming an attraction today when designing cloud-native and virtualized architectures. We will demonstrate in this blog how the 6WIND Virtual Service Router can be deployed as a light MPLS virtual Provider Edge network function.

For the simplicity of this write-up we will showcase the MPLS Layer3 VRF functionality using Ethernet links on 6WIND’s Virtual Service Router and segregating our virtual MPLS router into two distinct L3VRFs (Cust1 and Cust2) each connecting a subset of sites as seen in the following diagram:

In this implementation, a virtual core backbone network is responsible for the transmission of data across the wide area between VRF instances at each edge location belonging to Cust1 and Cust2. This model of MPLS L3VPN has been traditionally deployed by carriers to provide a shared wide-area backbone network for multiple customers. They are also appropriate in the large enterprise, multi-tenant and shared data center environments.

In a typical virtual deployment, the virtual customer edge (vCE) routers handle local routing in a traditional fashion using static routes, IGP or eBGP and disseminate the routing information into the virtual provider edge (vPE) where the routing tables are virtualized. The vPE router then encapsulates the traffic, marks it with the RD/RT to identify the VRF instance, and transmits it across the provider backbone network to the destination vPE router. The destination vPE router then decapsulates the traffic based on the RD/RT identity and forwards it to the vCE router at the destination. The backbone network is completely transparent to the customer equipment, allowing multiple customers or user communities to use the common backbone network while maintaining end-to-end traffic separation.

The IP addressing for each customer is globally distinct except one entity that has an overlapping subnet with the other customer:

Cust1 uses subnets 10.0.0.0/24, 10.1.0.0/24 and 10.1.1.0/24 for its 3 site entities.

Cust2 uses subnets 10.0.0.0/24, 10.2.0.0/24 and 10.2.2.0/24 for its 3 site entities.

As a prerequisite and best practice for the 6WIND Virtual Border Router configuration, some elements should be configured on all nodes, such as, management vrf, system license and system fast path. As a reminder, The fast path is the Virtual Border Router component in charge of packet processing. To accelerate ethernet NICs, the latter must be dedicated to the fast path, and the fast path must be started. To note that in the GNS3 setup we simulated, the “–cpu host” option must be configured in the advanced additional settings when defining the virtual node properties.

The following configuration is typical of a 6WIND Virtual Service Router performing label switching functionalities using the Open Shortest Path First (OSPF) as the underlying IGP with MPLS LDP enabled. For the purpose of this demo, we have enabled route-reflector (RR) capability on this virtual P Router to reduce the number of MP-BGP neighbors to be configured on each of the vPE routers. Typically, for a more complex setup, a VPNv4 RR is better to be designed in an out-of path deployment architecture:

The following configuration is typical of a 6WIND Virtual Service Edge Router acting as a PE router using OSPF as the underlying IGP with MPLS LDP enabled for label distribution and Multi-Protocol Border Gateway Protocol (MP-BGP) for L3VRF distribution and connectivity using the vpn-ipv4 address-family:

Using Cross-VRF (xvrf) interfaces to perform vrf route leaking with BGP requires a specific semantic between VRs and interface names. VR naming must meet the requirements of interface naming. Actually, the Cross-VRF interface name chosen must be equal to the target VR the interface is connected to. To illustrate, in order to reach VR “main” from VR “Client1”, a Cross-VRF interface named “main” has to be created in VR “Client1”. Reversely, an Cross-VRF interface named “Client1” has to be created in VR “main”. In this way, the interface “main” and the interface “Client1” will be connected together. The naming convention is not only done to reflect the intent of the interface. It is mandatory to configure it in this way, if one wants to benefit from route leaking across VRs, using Cross-VRF interfaces, and BGP.

With the above configuration applied, VR route leaking is possible. Subsequently, if BGP peering is done between a CE and the BGP instance of each VR instance, then route importation and exportation occurs. Below output demonstrates that the routes from Client1 have been imported to the main vrf. The VR route leaks are visible with the @1< indicating that the route entry originated from VR Client1.

We verify that the routing tables to Client1 contain the correct routes to reach the adjacent site:

A quick look at the mpls forwarding tables and LDP bindings would show us the labels that were allocated for interfaces and prefixes:

The following configuration is typical of the virtual CE router used in our setup. The vCE-vPE routing can be a static route, OSPF or eBGP.

To test the end-to-end functionality of our setup we will issue the traditional ping between the end client and capture the traffic on outgoing interfaces to check the label advertisements:

In the above example, we can see the label 80 assigned by BGP for the VRF Client1 and transport labels from vSER1 and vSER2 are set by LDP to 21 and 16 respectively as already listed in the show mpls table output above.

This concludes our first blog about the 6WIND Virtual Service Router capabilities to operate with MPLS L3VPN functionalities.

In the forthcoming series, we would discuss additional deployment scenarios for MPLS L3VPN and how our technology would help you to transition from traditional hardware vendor lock-in to a virtualized and open deployment model.

We would be glad to get in touch with you should you have any questions related to this post and would be more than happy to discuss further your current and future requirement: marketing@6wind.com