Showing results for 
Search instead for 
Did you mean: 
Xavier Hick

The goal of this document is strictly to provide an introduction to mpls traffic engineering in a vulgarized manner and in no way to be considered as technical reference.


Imagine yourself having to go to some place you don't know by car. Nowadays, we would use a GPS system to do so. However, at traffic peak hours, most of the GPS systems are unable to avoid the traffic jams. Why ? Because they take only into account the maximum speed we can reach depending on the roads. Since more speed means less time, they usually choose highways, then national roads and if no other choice, small roads.

In an internetwork, the same problem arises as we use the interior gateway protocols (IGPs) to calculate the best path towards a destination. They only select the best theoretical path to the destination without taking into account the possible congestions. Even though IGPs allow several best paths to be used, similarly to having several lanes on highways, they reach a limit at some point. Even EIGRP with its variance feature will always prefer to send more traffic to the highest bandwidth link while other links could be used much more than they are.

All in all, IGPs are like GPS systems. They tell you to choose the best theoretical path to your destination but they don't take into consideration the amount of traffic already present on the road/links. Luckily for us, we don't end up as car drops but frustration can increase over time...

After observing these same conditions several days in a row, we decide then to modify our itinary by not listening to the GPS when it tells us to take the highway at peak hours. Instead the GPS has to adapt to the smaller roads we decide to take (even though it tries so much to get us back on the highway). After some time and many trials & errors, we end up finding out the least worst road sections to that place at peak hours which make us gain a precious time as opposed to what our beloved GPS ordered us to do.

Since IGPs don't allow us to do so in internetworks, traffic engineering (TE) is born. By using a reservation protocol (RSVP), TE verifies first that the bandwidth we want can be achieved by the link the IGP prefers. If the bandwidth can't be achieved,


  1. Addresses the inherent limitations of IGPs allowing the use of all the links and not only the least cost path to be used
  2. Allows setting up a labelled switched path (LSP) without the use of LDP/TDP/MP-BGP


  1. Requires RSVP and IS-IS / OSPF throughout the traffic path(s)
  2. Remains level (IS-IS) / area (OSPF) specific in current implementation



In the example above, and with the use of a typical IGP, only the FastEthernet links R1-R3-R4 would be used to route traffic, making the path R1-R2-R4 only good for backup purposes if one of the FastEthernet links is not available.

By introducing MPLS TE, we'll see then how to make use of the two paths despite their bandwidth difference by means of dynamic and explicit path, thus achieving destination-based load-balancing.

Step-by-step approach:

  1. Ensure CEF is enabled on the router, otherwise label distribution will not happen
  2. Enable TE support for IS-IS or OSPF
    • IS-IS
      • metric-style wide
      • mpls traffic-eng {level-1 | level-2}
      • mpls  traffic-eng router-id <router-id>
    • OSPF
      • mpls traffic-eng area <area-id>
      • mpls traffic-eng router-id <router-id>
  3. Enable mpls traffic-eng tunnels in global configuration mode on all the routers in the path (in the example, enable it on the 4 routers)
  4. Enable mpls traffic-eng tunnels and ip rsvp bandwidth on all interfaces in the path
  5. Define the explicit path(s) if needed:
    ip explicit-path {name word | identifier number} enable
    next-hop <ip address>
  6. Define the tunnel with an interface Tunnel X, setting the mode to MPLS TE with tunnel mode mpls traffic-eng, define the tunnel source and destinations with tunnel source Y.Y.Y.Y and tunnel destination Z.Z.Z.Z then specify the tunnel mpls traffic-eng path-option number {dynamic | explicit {name path-name | id path-number}} specifying if you want to use routing protocol learnt path (dynamic) or the path you configured manually (explicit)
  7. Advertise the desired destinations through the Tunnel by means of static routing, policy-based routing or dynamic routing

            Getting Started

            Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

            Recognize Your Peers
            Quick Links