Imagine that you have two or more sites which you want to connect together using MPLS technology. You cannot afford dark fiber and your Service Provider cannot offer you L2 connections of any kind. The only thing your SP can offer is L3 transport. Still, you want to build your own MPLS environment and there is no way to convince your SP to enable CsC.

I will use the following topology to demonstrate one of the possibilities to build an overlay MPLS over SP backbone.

Overlay MPLS over SP

The provider has already his MPLS backbone configured (P1, PE1, PE2 and PE3) and it’s offering you, as customer, IP transport over it’s backbone. Usually, from customer perspective, you don’t get to see the SP backbone, but just for reference, it is using ISIS for IGP, MP-BGP and MPLS VPN to transport our prefixes.

From IP prefixes allocation I’m using “xy” in the third octet (x – lower router number, y – higher router number) and “z” in the last octet (router number) with a /24 mask.

We have three locations named CPE1, CPE2 and CPE3. Currently between my CPE and provider PE I have enabled BGP, but you can use any protocol (even static) if your SP is able to route your IP prefixes over its backbone. On each CPE device I have a Loopback interface and its IP address will be the only prefix you announce (through BGP in this demonstration) to SP.

Let’s establish the BGP connection from our CPE to SP PE. As I’m playing the role of customer here, only the CPE exhibits will be shown:

CPE5

CPE6

CPE7

BGP neighborship suppose to be up now and on each CPE I should receive the Loopback prefixes of the other two CPE devices.

BGP neighborship is up alright, but where are my prefixes? State/PfxRcd is 0, when it should show 2.
I did that on purpose.

Notice that we are using the same AS number on all our sites. I think you already know that the rule in BGP is that if our own ASN is seen in the AS-Path of a particular IP prefix, BGP will not install that prefix in BGP table. This is fixable:
1. We ask our provider to have a little “as-override” command in its BGP configuration for our neighbor
2. We use different ASN on each site (assuming that we are using private ASN)
3. We configure “allowas-in” on BGP neighborship with SP

Basically you may use any of the three methods (or other if you can think of any other), but in my case I don’t want to ask the SP nor I want to change my ASN scheme. I’ll go with the third option and be careful not run into loop issues (consider this is an Enterprise environment I think it’s doable).

CPE5

CPE6

CPE7

Let’s check again and do some testing. I will use CPE5

Next part involves the creation of Tunnels interfaces, to have a full mesh connection between the three sites, enable of IGP / MPLS and creation of a second Loopback interface which we will use later for the iBGP configuration. I did chose IS-IS for IGP and LDP for MPLS. The new Loopback interface will be routed using the IS-IS protocol.

A note from my side. Since I had limited number of routers, my CPE devices will be kind of P / PE / CE router in my overlay MPLS demonstration.

CPE5

CPE6

CPE7

I will use CPE5 for some show commands output and to check that everything is running fine:

I will create now two VRF instances as I want to separate Financial department traffic from the Technical one.

On all three CPE devices:

Configuration of iBGP depends on the previous Loopback1 interfaces, so be sure that you have that interfaces reachable through IS-IS. Because it’s an iBGP and I don’t want to type the same command over and over, I will use peer-groups.

CPE5

CPE6

CPE7

We should check that everything is up. I will use again CPE5:

Finally we are getting somewhere. In real world you will have the CPE routers connected to downstream devices, using subinterfaces in particular VRF and so on. I’m short on devices, so I will use some additional Loopback interfaces and add them to VRF FIN and TEK for testing.

CPE5

CPE6

CPE7

To check if everything is working fine, I will use CPE5 for some tests:

You may wonder why somebody would put together such a complex configuration. There may be multiple reasons, beyond the scope of this example, but I would like to add MPLS TE, Encrypted Site-to-Site traffic with route manipulation, independent configuration from the SP, learning purposes and many more.

Can we encounter problems with this configuration? Well, yes.
If the provider has a very low MTU size support, you may get a lot of fragmentation. Also maintenance and operation of Tunnels may be tricky for a very large environment, but there are solutions to limit the number of tunnels. Still the benefits exit.

To enumerate one benefit from real world. Applying this configuration in Enterprise environment, you have the possibility to change your SP without too much of a dazzle as long as your new provider can transport the IP address of your primary Loopback interface. The rest, stays the same.

Please let me know if you have questions or if something in my explanation is wrong.


2 thoughts on “Overlay MPLS over provider backbone

  • February 12, 2013 at 19:52
    Permalink

    very neat article. thank you for sharing this knowledge.
    how do you fix the MTU issue when you don’t know what the SP is using? start with very low MTU and do incremental increases?

    Reply
    • February 12, 2013 at 20:11
      Permalink

      Thanks for your comment!

      MTU size is always tricky when it involves environment where you cannot have control. From own experience, we had a leased line from a certain provider, we wanted dot1q over it and had problems because of MTU size.

      The best suggestion is a strong SLA with SP in which to specify the minimum MTU size they should deliver. Depending of multiple factors (financial, technical) the SP may deliver or not. It would help to calculate the minimum MTU size you need before going to negotiate with provider.

      Also it’s important what “tunnel” technology will be used. Here I had a simple GRE tunnel, but if you need encryption you may want to use IPsec also or maybe something tunnel-less like GETVPN. All this may be a factor in your decision about MTU size.

Leave a Reply

%d bloggers like this: