MPLS Traffic Engineering exists to solve a problem the IGP creates. OSPF and IS-IS always forward along the shortest path, every flow, all the time. That is correct for reachability and terrible for capacity: the shortest path saturates while parallel links sit idle. MPLS-TE is how you override the IGP and steer traffic onto the paths you choose. This post explains the problem, the components, and why segment routing is now changing how it is done.
For the cluster overview, see the MPLS complete guide.
The problem: the shortest path is not the only path
Picture two paths between a pair of core routers - a direct link and a slightly longer detour. The IGP computes the direct link as shorter, so every flow takes it. Under load, the direct link hits 95 percent utilization and starts dropping packets while the detour link sits at 10 percent. The capacity exists. The IGP simply will not use it, because "longer" disqualifies it regardless of how congested "shorter" is.
You could fudge IGP metrics to shift traffic, but metric tuning is blunt - it moves all traffic for affected destinations and tends to just relocate the congestion. MPLS-TE is the precise tool: it lets you place specific traffic on specific paths, with bandwidth accounted for.
What MPLS-TE does
MPLS-TE builds explicit label-switched paths - TE tunnels - across the network. A tunnel is a one-way LSP from a headend router to a tailend router, and it can be told to follow a path the IGP would never choose. Traffic mapped into the tunnel rides that path. The MPLS data plane forwards it by label, exactly as ordinary MPLS does; what changes is that the path was chosen by TE constraints, not by shortest-path SPF.
The three components
The TE database
A normal IGP floods topology and reachability. For TE, OSPF and IS-IS are extended to also flood resource information about each link: how much bandwidth is configured for TE, how much is currently reserved, and any administrative "colors" (also called affinities) tagging the link. Every router collects this into a TE database that describes not just the shape of the network but its available capacity.
CSPF: shortest path with rules
The headend of a tunnel runs CSPF against the TE database. Ordinary SPF asks "what is the shortest path?" CSPF asks "what is the shortest path that also has at least 200 Mbps free, and avoids any link colored red?" It prunes every link that fails a constraint, then finds the shortest path through what remains. The output is an explicit hop list.
Typical constraints are required bandwidth, link affinities (include or exclude links by color), and an explicit hop list you supply directly when you want a fully specified path.
RSVP-TE: signaling and reservation
Once CSPF produces a path, RSVP-TE builds it. A PATH message travels headend to tailend along the chosen hops; a RESV message travels back, and as it returns each router reserves the requested bandwidth on its outgoing link and allocates a label. The result is a signaled LSP with bandwidth booked end to end.
That bandwidth accounting is the point. RSVP-TE reservations are why the network knows a link has 200 Mbps already committed, so the next tunnel's CSPF will not oversubscribe it. The cost is state: every router along every tunnel holds per-tunnel RSVP state and refreshes it. In a large network with many tunnels, that state grows fast - the well-known scaling weakness of classic MPLS-TE.
Fast ReRoute
A major reason to deploy MPLS-TE is Fast ReRoute (FRR). FRR pre-computes and pre-signals a backup tunnel around a protected link or node. When the protected resource fails, the router at the point of failure switches traffic onto the pre-built backup in well under 50 milliseconds - long before the IGP would even notice the failure. For voice, video, and other loss-sensitive traffic, sub-50ms protection is the headline feature.
The configuration shape on Cisco IOS XE
TE is enabled globally and per interface, then tunnels are defined at the headend:
! Global + per-link enablement
mpls traffic-eng tunnels
!
interface GigabitEthernet0/1
mpls traffic-eng tunnels
ip rsvp bandwidth 500000
!
router ospf 1
mpls traffic-eng router-id Loopback0
mpls traffic-eng area 0
!
! A TE tunnel at the headend
interface Tunnel10
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 10.255.0.5
tunnel mpls traffic-eng bandwidth 200000
tunnel mpls traffic-eng path-option 10 dynamicThe dynamic path-option lets CSPF compute the path; an explicit path-option with a named hop list pins it. Verify with show mpls traffic-eng tunnels.
The modern shift: segment routing
Classic MPLS-TE works, but the RSVP-TE per-tunnel state does not scale gracefully. This is exactly the problem SR-MPLS (Segment Routing) addresses: the path is encoded as a label stack pushed at the headend, and core routers hold no per-tunnel state at all. New traffic-engineering deployments increasingly use SR Policy instead of RSVP-TE, while keeping the same goals - explicit paths, bandwidth awareness, fast protection via TI-LFA. If you are designing TE today, see the segment routing article; if you are running an existing RSVP-TE network, the concepts here are what you are operating.
Common gotchas
Key takeaways
MPLS Traffic Engineering overrides the IGP's shortest-path-only behaviour so you can place specific traffic on specific paths and stop congesting one link while parallel capacity sits idle. It works through three pieces: IGP TE extensions that flood per-link bandwidth and colors into a TE database, CSPF at the headend that finds the shortest path meeting your constraints, and RSVP-TE that signals the path and reserves bandwidth hop by hop. Fast ReRoute gives sub-50ms protection by pre-signaling backup tunnels. The trade-off is RSVP per-tunnel state, which does not scale gracefully - and that is why modern TE deployments are moving to segment routing, which keeps the goals while leaving core routers stateless.
For the MPLS cluster, see the MPLS pillar.
