MPLS TE, or Traffic Engineering is quite an interesting topic. A lot of discussions regarding segment routing ends up discussing how it can be used for TE purposes, but a lot can be done already in a standard MPLS setup using LDP and RSVP. Lets dig in!

Why use TE?

As a network engineer, most cool routing features seems to attract. But often we forget about real usecases. MPLS TE is mostly sold in as a feature to enable a better load distribution in topologies where the IGP cost may vary. Why not just change the IGP cost? Because that would affect all traffic, with TE you may reroute some specific traffic only.

There may also be some use-cases where you may need to suddenly reroute some traffic to distribute load until more bandwidth is setup. This is in other words safetynet for bad planning, but might come handy when shit hits the fan. As well is the ability to configure TE to avoid a specific router or segment.

MPLS TE gives us possibilities to:

  • Ability to reroute specific traffic for load distribution reasons or perhaps some traffic needs to use a more expensive but faster path.
  • Hop-by-hop source routing
  • Dynamic Source routing
  • Explicitly avoid one or more routers or segments.

How does it work then?

In the early stages of MPLS TE, close to the beginning of all times, there was a couple of protocols that those clever guys had in mind. But sooner or later IETF decided to go with one protocol which was RSVP. The very same protocol as we know from our QoS studies. That might sound odd, but looking into what we do with each protocol its not at all hard to grasp.

We need a couple of things

  • Bandwidth reservation
  • MPLS label propagation
  • Signaling
  • Topology information
  • Unidirectional Tunnel

What happens when the ground setup is configured is this. Each router will, thanks to using a link-state routing protocol (IS-IS or OSPF) know all about the topology. All of the links, how every segment connects each router. To enable MPLS-TE some TLVs were added to both IS-IS and OSPF just to be able to also carry information about the bandwidth of these links as well as other attributes used for TE purposes.

Yes, this is the reason why most people choose one of those protocols as IGP for MPLS. There is no other reason that I know of, and if you dont need TE you might as well use a distance vector protocol as IGP.

Now that each router knows about TE attributes for all links, a LSR can calculate a secondary best path based on our TE attributes. What the router needs next is a way to reserve bandwidth for the new LSP, signal to each LSR on the path about the tunnel and it needs to make sure mpls labels are propagated properly for the path.

This signalling is done with RSVP. RSVP was from the beginning a QoS mechanism built for bw allocation on a hop-by-hop basis, and RSVP-TE is extended with the possibility to signal TE tunnels. I am not going to dig deeper into this mechanism in this post.

Lets look at some configurations

Consider this topology:

Lets say we want to create a tunnel to avoid router X, we can do this a couple of ways.

  1. Create an explicit path that defines each hop
  2. Create an explicit path that just excludes the router X
  3. Create a dynamic path and based on other attributes, for example MPLS TE Metric that would be calculated to use a path thats not including X.

Lets look at some configuration examples. I will omit the basic setup and how to enable it for your IGP etc. And just look at how the tunnel can be setup.

At R2:

In the explicit-path we can list each hop in order, giving either the next-hop address of each link, or next-hop routers loopback address.

Another approach could be to just exclude the hop that we want to avoid with similar configuration, the only thing we would need to alter is the path-option command:


That was just a quick overview and a few ways to use MPLS-TE with RSVP. When I learned about this it definitely opened my eyes for how granular you can be with MPLS TE and the right approach. Still I can only suppose that its not widely used even if often implemented since even if its easy to lab up its quite some configuration to do, and for most use-cases IRL i believe most engineers would simply manipulate the IGP cost to reroute traffic.

One Reply to “MPLS TE”

  1. SEO Services says:

    Awesome post! Keep up the great work! 🙂

Leave a Reply

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