MPLS TE with RSVP-TE: Tunnels, CSPF and FRR

MPLS traffic engineering with RSVP-TE lets an operator choose the path a flow takes instead of accepting whatever the IGP computes, reserve bandwidth along that path, and protect it with a pre-signalled backup. It is the difference between forwarding based on a shortest-path metric and forwarding based on an engineered constraint set. This guide builds a working RSVP-TE tunnel between two PE routers, adds an explicit path and fast reroute, and lists the verification commands that prove the reservation exists on every hop — because a tunnel that shows as up in the headend but has no reservation downstream is worse than no tunnel at all.

Prerequisites: IGP with TE extensions

Every router in the path must flood link and bandwidth information so the headend can run CSPF. OSPF needs mpls traffic-eng enabled in the IGP and a TE router ID; IS-IS needs wide metrics, since narrow metrics cannot carry the bandwidth sub-TLVs.

! transit and headend routers, IOS XE syntax
mpls traffic-eng tunnels
!
router ospf 1
 mpls traffic-eng router-id Loopback0
 mpls traffic-eng area 0
!
interface GigabitEthernet0/0
 ip address 10.0.10.1 255.255.255.252
 mpls ip
 mpls traffic-eng tunnels
 ip rsvp bandwidth 1000000 1000000

The two numbers on ip rsvp bandwidth are the global pool and the maximum reservable per-flow bandwidth in kbps. A reservation larger than the per-flow value is rejected even when aggregate capacity exists — one of the most common reasons a tunnel stays down.

Build the tunnel at the headend

interface Tunnel12
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination 8.8.8.8
 tunnel mpls traffic-eng bandwidth 512000
 tunnel mpls traffic-eng priority 2 2
 tunnel mpls traffic-eng path-option 10 dynamic
 tunnel mpls traffic-eng path-option 20 explicit name PE1-PE2
 tunnel mpls traffic-eng fast-reroute
 no shutdown

Path options are evaluated in order: option 10 builds a CSPF path from the IGP database with the bandwidth and priority constraints applied, and option 20 falls back to a hand-built explicit path if CSPF cannot find a route. Put the dynamic option first on well-connected networks and the explicit path first when the customer contract requires a specific route.

ip explicit-path name PE1-PE2 enable
 next-address 10.0.10.2
 next-address 10.0.20.2
 next-address 10.0.30.2

Reservation semantics and priorities

RSVP-TE reservations are soft state refreshed every 30 seconds, and each tunnel carries setup and hold priorities (0 is highest, 7 lowest). Priorities decide who wins when the available bandwidth shrinks: a preemption of a lower-priority tunnel frees capacity and re-signals the reservation. Use setup priority slightly better than hold priority — for example priority 3 4 — so a tunnel can preempt a lower-priority one to establish itself but never preempts its own class.

Autoroute: putting traffic into the tunnel

A tunnel is useless until traffic enters it. Three approaches, in order of preference:

• Autoroute announce — the IGP installs the tunnel as a next hop for destinations behind the tailend. The standard choice for backbone TE.
• Static route into the tunnel — predictable but does not reroute when the tunnel falls back to another path option.
• Policy-based routing — useful for steering specific traffic classes, harder to operate at scale.

interface Tunnel12
 tunnel mpls traffic-eng autoroute announce
 tunnel mpls traffic-eng autoroute metric relative 10

Fast reroute: protection without waiting for convergence

FRR pre-signals a backup tunnel around each protected link or node. When the protected resource fails, the point of local repair switches traffic to the backup in tens of milliseconds — before the IGP has recalculated anything.

interface Tunnel12
 tunnel mpls traffic-eng fast-reroute
!
! backup tunnel around the link toward 10.0.20.1
interface Tunnel99
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination 10.0.20.2
 tunnel mpls traffic-eng path-option 10 explicit name BYPASS-20
 no shutdown
!
interface GigabitEthernet0/1
 mpls traffic-eng backup-path Tunnel99

Verification: prove the reservation end to end

show mpls traffic-eng tunnels brief
show mpls traffic-eng tunnels tunnel12
show mpls traffic-eng topology 2.2.2.2
show ip rsvp interface
show ip rsvp reservation
show mpls traffic-eng autoroute
show mpls forwarding-table 8.8.8.8 32 detail
traceroute 8.8.8.8 source Loopback0

On the headend output, confirm the tunnel is UP, that the path option in use is the one you expect, and that the actual route matches the explicit path. Then check the tailend and each transit hop for a matching reservation — the RSVP reserved bandwidth should be visible on the interfaces the tunnel crosses. A traceroute sourced from the loopback should now follow the engineered path rather than the IGP shortest path, which is the fastest proof that autoroute took effect.

Troubleshooting the usual failures

• Tunnel down, "no route": the destination is not reachable in the IGP, or the TE router ID is missing so the topology database has no node to compute through.
• Tunnel down, "RSVP reservation failed": bandwidth exhausted or the per-flow maximum is smaller than the requested value. Check show ip rsvp interface for reservable and available bandwidth.
• Tunnel flaps with "reoptimize": periodic reoptimization is moving the tunnel to a better path; if that path is unstable, use an explicit path option or raise the reoptimization interval.
• Traffic still follows the IGP: autoroute is configured but the tunnel metric is worse than the IGP path. Use a relative metric, or an absolute metric that beats the IGP cost.

RSVP-TE versus segment routing

Many operators now build the same engineered paths with segment routing instead of RSVP-TE: no per-tunnel soft state, better scaling, but no native bandwidth reservation. A common hybrid keeps SR for the underlay and RSVP-TE for a handful of bandwidth-guaranteed customer tunnels. If the goal is label distribution with traffic engineering as a secondary concern, the MPLS LDP deployment guide is the simpler starting point, and the L3VPN RD/RT design guide covers what rides on top of whichever transport you choose.

原文链接：https://www.noction.com/knowledge-base/mpls-traffic-engineering