MPLS, The Layer 2.5 Protocol & L3VPN: A Weekend Project Journal #1

MPLS, short for Multi-Protocol Label Switching is a “routing” protocol that uses labels to route data from one node to another. The reason why routing is in quote’s is because MPLS is not so much a routing protocol as it is a routing technique, it doesn’t operate on the network layer like Routing protocols and IP, but it also doesn’t operate on the data link layer like ethernet and switching; the MPLS header is added right in the middle at layer 2.5.

Lets briefly break it down.

MPLS works by assigning short labels to data packets, which represent the network path for their destination. When a packet enters the MPLS network, an MPLS label is attached to it. This label contains information that will guide the packet along the most efficient route to its final destination.

As the packet travels through the network, each router it encounters will only look at the MPLS label, instead of examining the packet’s entire header as in traditional IP routing. This allows for faster packet forwarding since the router does not have to perform a lookup in its routing table. Once the packet reaches its destination, the MPLS label is removed and the packet is delivered as usual.

What makes MPLS even more special, is it’s ability to work with IP and IP routing protocols like BGP. MPLS with BGP gives us the ability to create VPN’s between AS’s or run VPN’s like DMVPN, GETVPN etc. This was the concept I wanted to explore and what I focused on for my weekend project. I firstly had to deploy my own MPLS network, simulating a customer and provider MPLS infrastructure.

To build out this network I followed along Roger Perkins Tutorial and modified it to what I wanted for my network.

The configuration is as follows, the “provider” network consists of 2 provider edge routers and one provider core router, all of which have OSPF neighborship. We then have 1 customer with two customer edge devices on either end of our provider network. Think of these as two different office locations that we want to connect together our the provider network. Dedicated MPLS networks are a somewhat common and expensive solution for connecting remote office locations to the “main” hub and that is what we are trying to replicate here.

Now at this point we haven’t configured MPLS, but we do have IP routing so we can move on to the next step. We can now use a feature of Cisco IOS that is only currently supported by OSPF and that is MPLS LDP Autoconfiguration. MPLS LDP Autoconfiguration allows us to enable LDP on all ports that are apart of a specified OSPF area, this makes the configuration a breeze on networks that are already using OSPF as a routing protocol.

So now what the heck is LDP? LDP, Label Distribution Protocol is the protocol used to well distribute labels. LDP uses the underlying routing protocol to distribute labels to the other OSPF neighbors and create a Label Switched Path that will be used to “route” or “switch” MPLS packets. I should also note that the CE routers are in their own OSPF area so none of their ports have LDP enabled, only the provider network devices have LDP enabled. At this point we have MPLS working and running a trace from CE1 to CE2 will show that the data was label switched from PE1 to PE2 where the label was stripped and then the packet was delivered to CE2. While it was a success, it wasn’t enough for me.

Lets take a step back, in a real MPLS network the provider will be supporting multiple customers and there is a high likelihood that the address spaces will be overlapping. How are we going to differentiate between Customer 1’s 10.0.0.1 and Customer 12’s 10.0.0.1 and deliver that data? This is where as I mentioned before we can create a VPN, in this case an L3VPN. We can use MP-BGP and VRF to create separation of routes and distinguish one customers data from another even if they are using the same address space.

On the MP-BGP side, the key to getting this done is through the use of Route Distinguishers and Route Targets, these are going to be unique to each customer. This Route Distinguisher will be prefixed to the IP address and advertised with BGP creating what we call a VPNv4 address. Now because this traffic is logically separate we technically have now created our VPN, though note that this data isn’t encapsulated or encrypted in anyway, this is a common misconception when people hear VPN.

VRF’s on the other hand allow us to create routing tables just for a specific customer, and redistribute the routes from OSPF and BGP. This is important because by default all routes are going to be in the global routing table and if we want logical separation we need to separate each customer and their routes to their own table. Each VRF or Virtual Routing Forward table has its own unique and case sensitive name. We must also apply the VRF to the interface so that the router knows what routing table to use when packets are received on it.

Here’s an example of the Coligo VRF on PE1 compared to its global routing table.

As you can see the routes are completely separate, and the Coligo VRF is tied to the interface G1/0.

Stepping back forward, after implementing MP-BGP and verifying the peering between PE1 & PE2 over BGP, we now have logically separated traffic that is label switched from CE1 to CE2.

Here is the trace from CE1 to the Loopback interface on CE2

It is very likely that your enterprise MPLS circuit works in this fashion but there is a lot more that can be done from a security standpoint to secure our data over this provider network. While we have logical separation, if any of these routers become compromised an attacker can still sniff the data we’re sending over the network so in my next article I plan on expanding this topic by introducing DMVPN and how we can use it as an overlay VPN to secure communications between our two sites.

In the mean time stay curious!