MPLS Traffic Engineering and RSVP-TE

MPLS Traffic Engineering and RSVP-TE

This guide covers RouterOS MPLS Traffic Engineering (MPLS-TE): configuring explicit paths and bandwidth reservations, creating TE tunnels, and verifying traffic-engineered Label Switched Paths (LSPs).

MPLS-TE solves a fundamental limitation of plain LDP: LDP builds LSPs along the IGP shortest path, so congested links remain congested even when capacity exists on alternate paths. Traffic engineering adds two capabilities — explicit path control, so you can steer LSPs through specific routers regardless of the IGP metric, and bandwidth reservation, so a tunnel can guarantee capacity along every hop before traffic flows.

RouterOS implements RSVP-TE as defined in RFC 3209. All MPLS-TE configuration lives under /mpls traffic-eng — the sub-menus are tunnel, path, and interface.

Hardware and Licensed CHR Required

MPLS-TE forwarding is not supported on CHR free-tier instances. On free CHR, tunnels remain permanently invalid and never forward traffic — the MPLS package accepts the configuration but the dataplane does not support TE. Testing this feature requires physical RouterOS hardware or a paid CHR license (p1 or higher). Verification of the configuration examples below is not possible on free CHR.

Overview

RSVP-TE Signaling

When a TE tunnel is established, RSVP-TE performs a two-phase handshake:

1. PATH message — sent hop-by-hop from the ingress router toward the egress, carrying the Explicit Route Object (ERO) that lists the required hops and the bandwidth request. Each transit router allocates resources and forwards the PATH toward the next hop.
2. RESV message — sent in the reverse direction from egress to ingress. Each router confirms the reservation and allocates a label, building the LFIB entry. When the RESV reaches the ingress, the tunnel is up and forwarding begins.

Note

There is no global enabled=yes toggle for RSVP-TE in RouterOS 7. RSVP-TE becomes active automatically once TE interfaces and tunnels are configured and a TE-capable IGP (OSPF or IS-IS with TE extensions) has discovered the topology. Tunnels will show “RSVP not active for VRF” until the IGP brings up TE adjacencies.

Router Roles

Role	Responsibility
Ingress	Originates PATH messages, pushes the TE label, sends traffic into the tunnel
Transit	Receives PATH, reserves bandwidth, swaps labels, forwards RESV back
Egress	Terminates the tunnel, pops the TE label, delivers traffic to the IP layer

Explicit Paths

An explicit path is a named list of IP hop addresses. Each hop must specify its type:

• /strict — the LSP must reach that address directly, with no intermediate routers
• /loose — the LSP must pass through that address but may take any IGP path to get there

Strict hops give deterministic path control; loose hops allow IGP flexibility between fixed waypoints.

See MPLS-TE Hop Types for the full ERO notation reference.

Bandwidth Reservation

Bandwidth reservation is optional. When specified on a tunnel, RSVP-TE signals the requested bandwidth in the PATH message. If any link along the path cannot satisfy the request, the PATH fails and the tunnel does not come up. This hard-admission-control model ensures you never over-provision a link beyond its declared TE capacity.

Prerequisites

• RouterOS with the mpls package enabled (verify with /system/package/print)
• OSPF or IS-IS advertising loopback /32 addresses and transport subnets — RSVP-TE uses IGP reachability to route PATH messages between explicit hops. OSPF Opaque LSA support (RFC 3630) is required to flood TE link attributes for CSPF path computation; this is built into RouterOS OSPF and does not require additional configuration
• MPLS forwarding enabled on core interfaces (/mpls interface) — required on every link that will carry labeled TE traffic
• LDP is not required for RSVP-TE tunnels; TE tunnels carry their own label bindings via RESV messages

Note

RSVP-TE tunnels are independent of LDP LSPs. The same physical interfaces can carry both LDP-switched and RSVP-TE-switched traffic simultaneously.

Configuration

The examples below use the following three-router topology:

Router	Role	Loopback	Links
R1	Ingress	1.1.1.1/32	ether1 — 10.0.12.0/30 → R2
R2	Transit	2.2.2.2/32	ether1 — 10.0.12.0/30 → R1, ether2 — 10.0.23.0/30 → R3
R3	Egress	3.3.3.3/32	ether1 — 10.0.23.0/30 → R2

Step 1: Enable MPLS on Interfaces

MPLS forwarding must be active on every interface that will carry TE traffic. If you followed the LDP guide, this is already done.

# R1
/mpls interface add interface=ether1

# R2
/mpls interface add interface=ether1
/mpls interface add interface=ether2

# R3
/mpls interface add interface=ether1

Verify:

/mpls interface print

Step 2: Configure OSPF with TE Extensions

RSVP-TE relies on the IGP to discover the network topology and flood TE link attributes (available bandwidth, admin groups) via Opaque LSAs. CSPF uses this information to compute constrained paths. Configure OSPF on all core-facing interfaces with a stable router-id.

In RouterOS 7, no default OSPF instance exists on a fresh install — you must create one with add. The backbone area must also be created explicitly before interface templates can reference it — it is not present by default.

# R1 — create the OSPF instance with a stable router-id (loopback address recommended)
/routing ospf instance add name=ospf1 router-id=1.1.1.1

# Create the backbone area (area-id 0.0.0.0) — required before adding interface templates
/routing ospf area add area-id=0.0.0.0 name=backbone instance=ospf1
/routing ospf interface-template add interfaces=ether1 area=backbone

# R2
/routing ospf instance add name=ospf1 router-id=2.2.2.2
/routing ospf area add area-id=0.0.0.0 name=backbone instance=ospf1
/routing ospf interface-template add interfaces=ether1 area=backbone
/routing ospf interface-template add interfaces=ether2 area=backbone

# R3
/routing ospf instance add name=ospf1 router-id=3.3.3.3
/routing ospf area add area-id=0.0.0.0 name=backbone instance=ospf1
/routing ospf interface-template add interfaces=ether1 area=backbone

Verify OSPF adjacencies are established before proceeding:

/routing ospf neighbor print

Do not proceed to TE interface configuration until OSPF adjacencies are Full on all core links. RSVP-TE will show “RSVP not active for VRF” on tunnels until the IGP has converged and distributed TE attributes.

Step 3: Configure TE Interfaces

Add each core-facing interface to /mpls traffic-eng interface and declare its available bandwidth. This bandwidth figure is what RSVP-TE uses for admission control — it does not restrict physical throughput.

# R1 — declare 1 Gbps available on ether1
/mpls traffic-eng interface add interface=ether1 bandwidth=1G

# R2 — both core-facing interfaces
/mpls traffic-eng interface add interface=ether1 bandwidth=1G
/mpls traffic-eng interface add interface=ether2 bandwidth=1G

# R3
/mpls traffic-eng interface add interface=ether1 bandwidth=1G

Verify:

/mpls traffic-eng interface print detail

Step 4: Define Explicit Paths

Paths are named lists of hop addresses with type qualifiers. Define paths on the ingress router only — transit and egress routers do not need path definitions.

# On R1 — strict path through R2's ether1 address to R3's loopback
/mpls traffic-eng path add name=primary-path hops=10.0.12.2/strict,3.3.3.3/strict

# Loose path (IGP chooses how to reach each waypoint)
/mpls traffic-eng path add name=loose-path hops=2.2.2.2/loose,3.3.3.3/loose

# Path with record-route (records actual hops taken for verification)
/mpls traffic-eng path add name=verified-path hops=10.0.12.2/strict,3.3.3.3/strict record-route=yes

Verify:

/mpls traffic-eng path print detail

Each hop address must include a type suffix — /strict or /loose. Multiple hops are comma-separated. Omitting the type suffix causes expected /.

Step 5: Create TE Tunnels

Create tunnels under /mpls traffic-eng tunnel. These tunnel objects handle RSVP-TE signaling and label forwarding.

# On R1 — basic tunnel to R3 with no bandwidth reservation
/mpls traffic-eng tunnel add name=te0 to-address=3.3.3.3 primary-path=primary-path

# Tunnel with 500 Mbps bandwidth reservation and a secondary fallback path
/mpls traffic-eng tunnel add name=te1 to-address=3.3.3.3 \
    primary-path=primary-path \
    secondary-paths=loose-path \
    bandwidth=500M

# Tunnel with explicit priority (setup-priority and holding-priority; 0 = highest, 7 = lowest)
/mpls traffic-eng tunnel add name=te2 to-address=3.3.3.3 \
    primary-path=primary-path \
    bandwidth=100M \
    setup-priority=0 \
    holding-priority=0

Note: secondary-paths is the documented parameter name (plural). RouterOS also accepts the singular form secondary-path as an alias — both work identically.

Verify:

/mpls traffic-eng tunnel print detail

Step 6: Route Traffic into the Tunnel

TE tunnels must be referenced by name in routing rules to carry traffic:

# Route a destination prefix through a TE tunnel
/ip route add dst-address=192.168.10.0/24 gateway=te0

Verification

Check Tunnel State

/mpls traffic-eng tunnel print detail

Key fields:

Field	Meaning
state	up — tunnel established and forwarding; down — signaling failed
active-path	Name of the currently active explicit path
bandwidth	Bandwidth reserved across all hops

A tunnel showing “RSVP not active for VRF” means the TE-capable IGP has not yet established TE adjacencies. Confirm OSPF or IS-IS with TE extensions is running and has converged.

Verify TE Interface Bandwidth

/mpls traffic-eng interface print detail

Shows available and reserved bandwidth per interface, confirming reservation accounting is correct.

Verify Explicit Paths

/mpls traffic-eng path print detail

Where record-route=yes is set on a path, the actual route recorded in the last RESV message is displayed. Compare the recorded route against the intended explicit path to confirm the LSP is using the expected hops.

Verify Forwarding

From R1, confirm traffic to R3 is forwarded into the TE tunnel:

# Route should resolve via the te0 interface
/ip route print where dst-address=3.3.3.3/32

# Traceroute to verify actual path
/tool traceroute 3.3.3.3 use-dns=no

Practical Examples

Example 1: Bandwidth-Guaranteed Video Tunnel

A video streaming application needs 500 Mbps guaranteed from R1 to R3, using a specific path to avoid a shared edge link.

On R1:

# Strict path through transit R2 on the 1G core link
/mpls traffic-eng path add name=video-path hops=10.0.12.2/strict,3.3.3.3/strict

# TE tunnel with 500 Mbps reservation and high priority
/mpls traffic-eng tunnel add name=te-video \
    to-address=3.3.3.3 \
    primary-path=video-path \
    bandwidth=500M \
    setup-priority=0 \
    holding-priority=0

# Route video traffic through the TE tunnel
/ip route add dst-address=192.168.10.0/24 gateway=te-video

Verify the tunnel is up and bandwidth is reserved:

/mpls traffic-eng tunnel print detail

Example 2: Tunnel with Fallback Path

Critical management traffic with a secondary path for resilience.

On R1:

# Primary path — strict through R2
/mpls traffic-eng path add name=mgmt-primary hops=10.0.12.2/strict,3.3.3.3/strict

# Secondary path — loose (IGP-routed fallback)
/mpls traffic-eng path add name=mgmt-fallback hops=3.3.3.3/loose

# Create tunnel with primary and secondary paths
/mpls traffic-eng tunnel add name=te-mgmt \
    to-address=3.3.3.3 \
    primary-path=mgmt-primary \
    secondary-paths=mgmt-fallback \
    bandwidth=10M

When the primary path fails, RSVP-TE re-signals along the secondary path.

Example 3: Tunnel-Based Policy Routing

Route voice traffic and best-effort traffic over separate TE tunnels using strict and loose paths.

On R1:

# Two paths — strict core path and loose fallback path
/mpls traffic-eng path add name=path-core hops=10.0.12.2/strict,3.3.3.3/strict
/mpls traffic-eng path add name=path-secondary hops=2.2.2.2/loose,3.3.3.3/loose

# TE tunnel for voice (high priority, core link)
/mpls traffic-eng tunnel add name=te-voice to-address=3.3.3.3 \
    primary-path=path-core bandwidth=50M \
    setup-priority=0 holding-priority=0

# TE tunnel for best-effort (secondary link, no reservation)
/mpls traffic-eng tunnel add name=te-best-effort to-address=3.3.3.3 \
    primary-path=path-secondary

# Policy routing — mark voice packets to use te-voice
# RouterOS 7: routing table must be created before it can be referenced in mangle
/routing table add name=voice fib
/ip firewall mangle add chain=prerouting protocol=udp dst-port=5060,10000-20000 \
    action=mark-routing new-routing-mark=voice passthrough=no
/ip route add dst-address=0.0.0.0/0 gateway=te-voice routing-table=voice

Troubleshooting

Tunnel Stays Down

# 1. Confirm MPLS is enabled on core interfaces
/mpls interface print

# 2. Verify TE interfaces are configured on all routers in the path
/mpls traffic-eng interface print

# 3. Check IGP reachability to each explicit hop address
/ping 10.0.12.2 count=3
/ping 3.3.3.3 count=3

# 4. Inspect tunnel state for error reason
/mpls traffic-eng tunnel print detail

# 5. Check path configuration
/mpls traffic-eng path print detail

If the tunnel shows “RSVP not active for VRF”, the TE-capable IGP has not established TE adjacencies yet. Ensure OSPF or IS-IS is running with TE extensions enabled and has converged across all routers.

Bandwidth Reservation Fails

Tunnels with bandwidth requests fail if any link lacks sufficient declared TE capacity.

# Check per-interface declared and reserved bandwidth
/mpls traffic-eng interface print detail

# Increase TE bandwidth on the constrained interface
/mpls traffic-eng interface set [find interface=ether1] bandwidth=10G

# Or reduce the requested tunnel bandwidth
/mpls traffic-eng tunnel set [find name=te1] bandwidth=200M

Tunnel Takes Unexpected Path

If record-route=yes is set on the path, the RESV message records the actual route taken:

/mpls traffic-eng path print detail
# explicit-route: configured hops
# recorded-route: actual hops taken

Discrepancies indicate a loose hop was resolved differently than expected. Convert critical intermediate hops to /strict for deterministic routing.

Common Issues

Symptom	Likely Cause	Resolution
Tunnel permanently I - invalid on CHR free	CHR free does not support MPLS-TE forwarding	Requires physical hardware or paid CHR license (p1+)
Tunnel stays down after creation	TE-capable IGP not running or no TE adjacencies	Enable OSPF/IS-IS TE extensions on all routers
”RSVP not active for VRF”	IGP TE extensions not yet converged	Wait for IGP convergence; verify TE adjacencies
Tunnel up but no traffic forwarded	Route not pointing to TE tunnel	Add /ip route with gateway=<tunnel-name>
Bandwidth reservation rejected	Requested bandwidth exceeds TE interface capacity on some hop	Reduce tunnel bandwidth or increase /mpls traffic-eng interface bandwidth on constrained links
expected / on path add	Missing /strict or /loose hop type	Use hops=10.0.12.2/strict,3.3.3.3/strict format
Loose hop using wrong path	IGP metric change shifted the resolved path	Convert critical intermediate hops to /strict

Command Reference

/mpls traffic-eng interface

Enables RSVP-TE on a physical interface and declares its TE bandwidth for admission control.

Parameter	Description
interface	Interface name
bandwidth	Total bandwidth available for TE reservations

/mpls traffic-eng interface add interface=ether1 bandwidth=1G
/mpls traffic-eng interface print detail

/mpls traffic-eng path

Defines named explicit paths used by TE tunnels.

Parameter	Description
name	Path identifier, referenced by tunnel primary-path or secondary-paths
hops	Comma-separated list of ip/strict or ip/loose hop entries
record-route	Record actual path taken in RESV (yes/no)

/mpls traffic-eng path add name=primary-path hops=10.0.12.2/strict,3.3.3.3/strict
/mpls traffic-eng path print detail

/mpls traffic-eng tunnel

RSVP-TE tunnel objects. Each tunnel corresponds to a signaled LSP.

Parameter	Description
name	Tunnel identifier (usable as a gateway name in /ip route)
to-address	Egress router IP address
primary-path	Name of the primary explicit path
secondary-paths	Name(s) of fallback path(s) — note: plural
bandwidth	Bandwidth to reserve (default 0 — no reservation)
setup-priority	Priority for establishing the tunnel: 0 (highest) to 7 (lowest)
holding-priority	Priority for keeping the tunnel: 0 (highest) to 7 (lowest)

/mpls traffic-eng tunnel add name=te0 to-address=3.3.3.3 primary-path=primary-path
/mpls traffic-eng tunnel print detail

Related Information

• MPLS and LDP — LDP-based LSPs that provide the MPLS underlay
• VPLS — Layer 2 VPN services that can run over RSVP-TE tunnels
• MPLS-TE Explicit Paths — Detailed guide to explicit path configuration and path selection
• MPLS-TE Hop Types — Strict and loose hop reference with ERO notation

RFC References

• RFC 3209 — RSVP-TE: Extensions to RSVP for LSP Tunnels
• RFC 3031 — MPLS Architecture
• RFC 2205 — Resource ReSerVation Protocol (RSVP)