MPLS Traffic Engineering and RSVP-TE
MPLS Traffic Engineering and RSVP-TE
Section titled “MPLS Traffic Engineering and RSVP-TE”This guide covers RouterOS MPLS Traffic Engineering (MPLS-TE): enabling RSVP-TE, configuring explicit paths and bandwidth reservations, creating TE tunnel interfaces, 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. RSVP-TE extends the basic RSVP protocol with path computation and resource reservation across an MPLS domain. TE tunnel interfaces appear as standard routable interfaces (/interface traffic-eng), making them straightforward to use in routing and policy configurations.
Overview
Section titled “Overview”RSVP-TE Signaling
Section titled “RSVP-TE Signaling”When a TE tunnel is established, RSVP-TE performs a two-phase handshake:
- 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.
- 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.
RSVP-TE maintains tunnel state with periodic soft-state refresh messages (default every 30 seconds). If refresh messages stop arriving, routers release their reservations after the keepout timer expires (default 60 seconds). This soft-state model means RSVP-TE is self-healing: re-establishing a failed tunnel cleans up stale state automatically.
Router Roles
Section titled “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
Section titled “Explicit Paths”An explicit path is a named list of IP addresses that the LSP must traverse. Hops can be strict (the LSP must reach that router directly, with no intermediate routers) or loose (the LSP must reach that router but may follow any 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
Section titled “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 inadvertently over-provision a link beyond its declared TE capacity.
Interface subscription can be set above 100% to allow overbooking, which is appropriate when you know reservations will not all be fully utilized simultaneously.
Prerequisites
Section titled “Prerequisites”- RouterOS with the
mplspackage enabled (verify with/system/package/print) - An IGP (OSPF or IS-IS) advertising loopback
/32addresses and transport subnets — RSVP-TE uses IGP reachability to route PATH messages between explicit hops - 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
Configuration
Section titled “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
Section titled “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=ether1Verify:
/mpls interface printStep 2: Enable RSVP-TE Globally
Section titled “Step 2: Enable RSVP-TE Globally”RSVP-TE is disabled by default. Enable it on all routers that will participate in TE (ingress, transit, and egress).
# All routers/mpls rsvp-te set enabled=yesOptionally configure timing and authentication:
# Faster failure detection (at the cost of higher control-plane load)/mpls rsvp-te set refresh-time=10s keepout-time=30s
# MD5 authentication for RSVP messages/mpls rsvp-te set authentication=md5 password=rsvp-secret
# Verify global settings/mpls rsvp-te printStep 3: Configure RSVP-TE Interfaces
Section titled “Step 3: Configure RSVP-TE Interfaces”Add each core-facing interface to RSVP-TE 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 rsvp-te interface add interface=ether1 bandwidth=1G
# R2 — both core-facing interfaces/mpls rsvp-te interface add interface=ether1 bandwidth=1G/mpls rsvp-te interface add interface=ether2 bandwidth=1G
# R3/mpls rsvp-te interface add interface=ether1 bandwidth=1GTo allow overbooking (for environments where reservations are not simultaneously fully utilized):
/mpls rsvp-te interface set [find interface=ether1] subscription=150Verify:
/mpls rsvp-te interface print detailStep 4: Define Explicit Paths
Section titled “Step 4: Define Explicit Paths”Paths are named lists of hop addresses. Define paths on the ingress router only — transit and egress routers do not need path definitions.
# On R1 — path through R2 to R3 (all hops strict)/mpls rsvp-te path add name=primary-path path=10.0.12.2,3.3.3.3
# Verify/mpls rsvp-te path printFor a loose hop (intermediate nodes chosen by IGP between waypoints):
/mpls rsvp-te path add name=loose-path path=2.2.2.2,3.3.3.3For record-route (records the actual path taken for verification):
/mpls rsvp-te path add name=verified-path path=10.0.12.2,3.3.3.3 record-route=yesStep 5: Create a TE Tunnel Interface
Section titled “Step 5: Create a TE Tunnel Interface”Create a traffic-eng interface that binds the path and bandwidth reservation together. This interface appears as a standard routable interface.
# On R1 — basic tunnel to R3 with no bandwidth reservation/interface traffic-eng add name=te0 to-address=3.3.3.3 primary-path=primary-path
# Tunnel with 500 Mbps bandwidth reservation and a secondary fallback path/interface traffic-eng add name=te1 to-address=3.3.3.3 \ primary-path=primary-path \ secondary-path=loose-path \ bandwidth=500M
# Tunnel with fast reroute protection enabled/interface traffic-eng add name=te2 to-address=3.3.3.3 \ primary-path=primary-path \ bandwidth=100M
# Enable fast reroute on the RSVP-TE tunnel/mpls rsvp-te tunnel set [find] setup-protection=yes
# Verify interfaces/interface traffic-eng print detailVerification
Section titled “Verification”Check Tunnel Interface Status
Section titled “Check Tunnel Interface Status”/interface traffic-eng print detailA healthy tunnel shows running flag and the resolved next-hop. If the flag is absent, the tunnel has not signaled successfully.
Check RSVP-TE Tunnel State
Section titled “Check RSVP-TE Tunnel State”/mpls rsvp-te tunnel print detailKey fields:
| Field | Meaning |
|---|---|
state | up — tunnel established and forwarding; down — signaling failed |
active-path | Name of the currently active explicit path |
reserved-bandwidth | Bandwidth successfully reserved across all hops |
View Active Reservations
Section titled “View Active Reservations”/mpls rsvp-te reservation printLists all active RSVP-TE reservations passing through this router, including tunnel name, source, destination, and reserved bandwidth.
Verify RSVP-TE Interface Utilization
Section titled “Verify RSVP-TE Interface Utilization”/mpls rsvp-te interface print detailShows available and reserved bandwidth per interface, confirming that reservation accounting is correct.
Check PATH/RESV Signaling State
Section titled “Check PATH/RESV Signaling State”/mpls rsvp-te path print detailDisplays explicit path configurations and, where record-route=yes is set, the actual route recorded in the last RESV message. Compare the recorded route against the intended explicit path to confirm the LSP is using the expected path.
Verify Forwarding
Section titled “Verify Forwarding”From R1, confirm traffic to R3 is forwarded into the TE tunnel:
# Route should resolve via te0 interface/ip route print where dst-address=3.3.3.3/32
# Traceroute to verify path/tool traceroute 3.3.3.3 use-dns=noPractical Examples
Section titled “Practical Examples”Example 1: Bandwidth-Guaranteed Video Tunnel
Section titled “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 rsvp-te path add name=video-path path=10.0.12.2,3.3.3.3
# TE tunnel with 500 Mbps reservation and high priority (0 = highest)/interface traffic-eng add name=te-video \ to-address=3.3.3.3 \ primary-path=video-path \ bandwidth=500M
/mpls rsvp-te tunnel set [find name~"te-video"] priority=0
# Route video traffic through the TE tunnel/ip route add dst-address=192.168.10.0/24 gateway=te-videoVerify the reservation:
/mpls rsvp-te reservation print# reserved-bandwidth should show 500MExample 2: Protected Tunnel with Fast Reroute
Section titled “Example 2: Protected Tunnel with Fast Reroute”Critical management traffic needs sub-50 ms failover if the primary link fails.
On R1:
# Primary path — strict through R2/mpls rsvp-te path add name=mgmt-primary path=10.0.12.2,3.3.3.3
# Create protected TE interface/interface traffic-eng add name=te-mgmt \ to-address=3.3.3.3 \ primary-path=mgmt-primary \ bandwidth=10M
# Enable fast reroute protection on the tunnel/mpls rsvp-te tunnel set [find] setup-protection=yes
# Monitor protection status/mpls rsvp-te tunnel monitorWhen fast reroute is enabled, RouterOS establishes a pre-computed backup LSP. On primary path failure, traffic switches to the backup in under 50 ms without waiting for control-plane reconvergence.
Example 3: Tunnel-Based Policy Routing
Section titled “Example 3: Tunnel-Based Policy Routing”Route voice traffic and best-effort traffic over separate TE tunnels to different links.
On R1:
# Two paths — primary core link and secondary link/mpls rsvp-te path add name=path-core path=10.0.12.2,3.3.3.3/mpls rsvp-te path add name=path-secondary path=10.0.12.6,3.3.3.3
# TE tunnel for voice (high priority, core link)/interface traffic-eng add name=te-voice to-address=3.3.3.3 \ primary-path=path-core bandwidth=50M/mpls rsvp-te tunnel set [find name~"te-voice"] priority=0
# TE tunnel for best-effort (secondary link, no reservation)/interface traffic-eng add name=te-best-effort to-address=3.3.3.3 \ primary-path=path-secondary
# Policy routing — mark voice packets to use te-voice/ip firewall mangle add chain=prerouting protocol=udp dst-port=5060,10000-20000 \ action=mark-routing new-routing-mark=voice/ip route add dst-address=0.0.0.0/0 gateway=te-voice routing-mark=voiceTroubleshooting
Section titled “Troubleshooting”Tunnel Stays Down
Section titled “Tunnel Stays Down”# 1. Verify RSVP-TE is enabled globally and on required interfaces/mpls rsvp-te print/mpls rsvp-te interface print
# 2. Confirm MPLS is enabled on core interfaces/mpls 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 rsvp-te tunnel print detail
# 5. Check path signaling details/mpls rsvp-te path print detailBandwidth Reservation Fails
Section titled “Bandwidth Reservation Fails”Tunnels with bandwidth requests fail if any link lacks sufficient declared TE capacity.
# Check per-interface declared and reserved bandwidth/mpls rsvp-te interface print detail
# Reduce the requested bandwidth or increase interface TE bandwidth/mpls rsvp-te interface set [find interface=ether1] bandwidth=10G
# Or allow overbooking/mpls rsvp-te interface set [find interface=ether1] subscription=200Tunnel Takes Unexpected Path
Section titled “Tunnel Takes Unexpected Path”If record-route=yes on the path, the RESV message records the actual route taken. Compare it to the explicit path:
/mpls rsvp-te path print detail# explicit-route: configured hops# recorded-route: actual hops takenDiscrepancies between explicit and recorded routes indicate a loose hop was resolved differently than expected, or that a strict hop was unreachable and RSVP fell back to a loose resolution.
Common Issues
Section titled “Common Issues”| Symptom | Likely Cause | Resolution |
|---|---|---|
state=down immediately after creation | RSVP-TE not enabled on all transit interfaces | Run /mpls rsvp-te interface print on transit routers; add missing interfaces |
| Tunnel up but no traffic forwarded | Route not pointing to TE interface | Add /ip route with gateway=<te-interface-name> |
| Bandwidth reservation rejected | Requested bandwidth exceeds TE interface capacity on some hop | Reduce tunnel bandwidth or increase /mpls rsvp-te interface bandwidth on constrained links |
| Tunnel flaps every 30 seconds | Soft-state refresh not reaching neighbor | Check IP connectivity for RSVP messages (UDP/TCP 46); verify no firewall drops RSVP |
| FRR not activating on failure | setup-protection=yes not set on tunnel | Set setup-protection=yes in /mpls rsvp-te tunnel |
| Loose hop using wrong path | IGP metric change shifted the resolved path | Convert critical intermediate hops to strict, or set explicit metric constraints in IGP |
Command Reference
Section titled “Command Reference”/mpls rsvp-te
Section titled “/mpls rsvp-te”Global RSVP-TE protocol settings.
| Parameter | Description |
|---|---|
enabled | Enable RSVP-TE globally (yes/no) |
refresh-time | Interval for soft-state refresh messages (default 30s) |
keepout-time | Time resources stay reserved after refresh timeout (default 60s) |
authentication | Message integrity: md5 or none |
password | MD5 authentication password |
ip-ttl | IP TTL for RSVP control messages (default 255) |
/mpls rsvp-te set enabled=yes/mpls rsvp-te print/mpls rsvp-te interface
Section titled “/mpls rsvp-te interface”Enables RSVP-TE on a physical interface and declares its TE bandwidth.
| Parameter | Description |
|---|---|
interface | Interface name |
bandwidth | Total bandwidth available for TE reservations |
subscription | Overbooking percentage — 200 allows up to 2× declared bandwidth to be reserved |
priority | Default reservation priority for this interface |
/mpls rsvp-te interface add interface=ether1 bandwidth=1G/mpls rsvp-te interface print detail/mpls rsvp-te path
Section titled “/mpls rsvp-te path”Defines named explicit paths used by TE tunnels.
| Parameter | Description |
|---|---|
name | Path identifier, referenced by tunnel or traffic-eng interface |
path | Comma-separated list of IP addresses the LSP must traverse |
record-route | Record actual path taken in RESV (yes/no) |
/mpls rsvp-te path add name=primary-path path=10.0.12.2,3.3.3.3/mpls rsvp-te path print detail/mpls rsvp-te tunnel
Section titled “/mpls rsvp-te tunnel”Low-level RSVP-TE tunnel objects. In most deployments, manage tunnels via /interface traffic-eng instead.
| Parameter | Description |
|---|---|
name | Tunnel identifier |
to | Egress router IP address |
path | Explicit path name |
bandwidth | Bandwidth to reserve (default 0 — no reservation) |
priority | Reservation priority: 0 (highest) to 7 (lowest) |
setup-protection | Enable fast reroute backup LSP (yes/no) |
/mpls rsvp-te tunnel print detail/mpls rsvp-te tunnel monitor/mpls rsvp-te reservation
Section titled “/mpls rsvp-te reservation”Read-only view of active RSVP-TE reservations on this router.
/mpls rsvp-te reservation print/interface traffic-eng
Section titled “/interface traffic-eng”Higher-level TE tunnel interface. Creates a named interface usable in routing and firewall rules.
| Parameter | Description |
|---|---|
name | Interface name (e.g., te0) |
to-address | Egress router IP address |
primary-path | Name of the primary explicit path |
secondary-path | Name of the fallback path (activated if primary fails) |
bandwidth | Bandwidth to reserve via RSVP-TE (default 0) |
mtu | Interface MTU (default 1500; reduce by 4 bytes per MPLS label) |
dscp | DSCP marking for tunneled traffic |
/interface traffic-eng add name=te0 to-address=3.3.3.3 primary-path=primary-path/interface traffic-eng print detailRelated Information
Section titled “Related Information”Related Topics
Section titled “Related Topics”- MPLS and LDP — LDP-based LSPs that provide the MPLS underlay for TE tunnels
- 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
Section titled “RFC References”- RFC 3209 — RSVP-TE: Extensions to RSVP for LSP Tunnels
- RFC 3031 — MPLS Architecture
- RFC 2205 — Resource ReSerVation Protocol (RSVP)
- RFC 4090 — Fast Reroute Extensions to RSVP-TE for LSP Tunnels