Introduction

I’m currently designing and implementing a large network which will run MPLS.
This network will replace an old network that was mainly L2 based and did not
run MPLS, only VRF lite. There are a few customers that need to have diverse
paths in the network and quick convergence when a failure occurs.
This led me to consider MPLS-TE for those customers and to have plain MPLS
through LDP for other customers buying VPNs. What is the usage for MPLS-TE?

Weaknesses of IGP

When using normal IP forwarding a least cost path is calculated through an IGP,
such as OSPF or ISIS. The problem though is that only the least cost path will
be utilized, any links not on the best path will sit idle, which is a waste of
bandwidth. IGP metrics can be manipulated but that only moves the problem to
other links, it does not solve the root cause. Manipulating metrics is cumbersome
and prone to error. It’s difficult to think of all the traffic flows in the network
and get all the metrics correct. IGPs also lack the granularity in metrics to
utilize all the bandwidth in the network.

RSVP-TE

RSVP in the past was a protocol used for quality of service in the Intserv model.
It never got a lot of traction due to scalability issues of keeping state in the
core of the network. RSVP was modified to support MPLS and that protocol is known
as RSVP-TE. RSVP-TE provides support for:

  • Explicit path configuration
  • Path numbering
  • Route recording

RSVP assigns labels to the LSPs. The headend of the tunnel sends PATH messages
towards the tailend and then from the tailend back, RESV messages are sent together
with a label to use for the LSP.

RSVP-TE1

Constrained SPF (CSPF)

To overcome the limitations of IGPs mentioned above in the post, the SPF algorithm has
to be modified. This is called Constrained SPF (CSPF) and besides a simple metric it
can take other factors into account such as:

  • Bandwidth
  • Affinity
  • Administrative weight
  • Explicitly defined path

To support this modified SPF algorithm and to carry the information needed in the
LSU/LSP, the IGPs have been modified to support this. OSPF supports TE by using
an opaque LSA. ISIS which is easily modifiable with TLVs, supports TE through a new
TLV. When using ISIS as the IGP, a wide style metric must be used to support TE.

The CSPF path can either be calculated dynamically by the router or the user can
configure an explicit path. Both methods support the use of constraints to build
the path.

Routing Across an TE Tunnel

Once the tunnel has been built, traffic must be sent through the tunnel.
This can be achieved in a couple of different ways:

  • Static routing
  • Dynamic routing
  • Policy-based routing

The Lab

That was a brief overview of MPLS-TE. To test this out in a lab I have setup a
topology like this:

MPLS-TE1

All routers are running IOS except for one router. This is to show the syntax of
IOS-XR and for me to practice using it. IOS1 and IOS6 advertise their loopbacks to
the PE routers. Normal routing has been setup as well as MPLS and BGP. This is the
configuration so far:

IOS1:

IOS2:

XR1:

IOS6:

The other configuration has been left out, it’s just plain IGP routing and enabling MPLS.
The lab is currently using MPLS VPN and taking the upper path due to the IGP path
being shorter. Let’s confirm this with a traceroute.

The traceroute confirms this.

MPLS-TE tunnels are always unidirectional. To configure MPLS-TE we need to
go through the following steps:

  • Enable CEF (default)
  • Enable TE support in IGP
  • Enable MPLS-TE tunnels globally
  • Enable MPLS-TE tunnels on interface(s) in path
  • Enable RSVP on interface(s) in path

The following configuration is added to all IOS routers:

The following configuration is added to the IOS-XR router:

This is enough to have ISIS support MPLS-TE. From the IOS-XR router we can
see that the IGP is now carrying more information in the LSPs.

The next step is to create the tunnel. We will build a tunnel from IOS2 to XR1.

Autoroute announce is used to advertise the tunnel into the IGP. Another option
would be a static route for the tunnel destination across the tunnel interface.

The tunnel is now up and traffic is forwarding across it.

The label 19 is the label used for the tunnel and label 16012 is the VPN label.
We are still using the upper path though. Let’s configure an explicit path to
use the lower path of the topology.

We try a traceroute from IOS1 to see if the traffic is following the lower path.

This is the power of MPLS-TE. The ability to from the headend, define where
the traffic should go. This is essentially source routing. There are also new
features coming out such as segment routing which does something similar by
extending OSPF and ISIS and generating labels through the IGP.

What happens if the explicit path goes down? We can use a dynamic path as a
fallback by setting it to a higher ID in our tunnel configuration.
This is the current configuration of the tunnel:

We will initiate a ping from IOS1, then I will shutdown IOS4 interface towards IOS3.
Traffic should then go over the upper path again.

Only a single packet was lost. We confirm on IOS2 that the secondary path
is being used.

IOS1 is using the upper path again.

Conclusion

MPLS-TE can help overcome some of the limitations that come bundled with
IGPs, such as not utilizing links and not being able to consider constraints,
solely relying on a metric that says nothing about the bandwidth available.
MPLS-TE can be used to provide fast convergence by defining several path options.
It can also be combined with FRR to provide convergence times around 50ms.

A Quick Look at MPLS-TE
Tagged on:                 

4 thoughts on “A Quick Look at MPLS-TE

  • October 25, 2014 at 5:30 pm
    Permalink

    Nice article! One important aspect of RSVP-TE is that routers involved currently need to be in the same IGP area for the CSPF to run. Meaning the RSVP-TE extensions are not reaching outside of an area. An IGP area could be an OSPF area or IS-IS level. I noticed your routers are actually in different IS-IS areas but in the same IS-IS level, maybe that was your intention. Everything left of the system id (always 6 bytes) in the NSAP is considered to be the area:

    net 49.0001.0002.0002.0002.0002.00
    net 49.0001.0007.0007.0007.0007.00

    area: 49.0001.0002
    area: 49.0001.0007

    Regards
    Sebastian

    Reply
    • October 26, 2014 at 8:34 am
      Permalink

      Thanks Sebastian!

      I must have made a mistake there. Do you use MPLS-TE? It’s a nice addition but the number of tunnels can grow quickly, the administrative overhead seems quite heavey unless you have some kind of auto tunnel setup.

      Reply
  • October 26, 2014 at 5:43 pm
    Permalink

    Yes, I use MPLS-TE for FRR and to influence LSP setup with administrative-groups or “link coloring” as a constraint. I have however never configured MPLS-TE on Cisco, only on other vendor platforms. I am currently looking into how similar setup is done on IOS XR. From my quick research it seems like Cisco is calling administrative-groups for affinity.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: