Changes in an MPLS TE network are possible. Metrics can change, interfaces can go down or up, etc. It’s possible that an already established tunnel doesn’t use the most optimal path anymore. MPLS TE uses reoptimization to calculate the best path for a tunnel. There are two options:
- Periodic reoptimization.
- Manual reoptimization.
We’ll discuss both options in this lesson. To demonstrate reoptimization, I’ll use this topology:

Routers PE1, P1, P2, P3, and PE2 are configured to use MPLS TE. There is a tunnel from PE1 to PE2. I use Cisco IOS Software, IOSv Software (VIOS-ADVENTERPRISEK9-M), Version 15.9(3)M4.
- Configurations
- CE1
- CE2
- P1
- P2
- P3
- PE1
- PE2
Want to take a look for yourself? Here you will find the startup configuration of each device.
Periodic Reoptimization
Let’s take a look at our tunnel:
PE1#show mpls traffic-eng tunnels Tunnel 1
Name: PE1_t1 (Tunnel1) Destination: 6.6.6.6
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 1, type dynamic (Basis for Setup, path weight 20)
Config Parameters:
Bandwidth: 750 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: disabled LockDown: disabled Loadshare: 750 bw-based
auto-bw: disabled
Active Path Option Parameters:
State: dynamic path option 1 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
InLabel : -
OutLabel : GigabitEthernet0/1, 26
RSVP Signalling Info:
Src 2.2.2.2, Dst 6.6.6.6, Tun_Id 1, Tun_Instance 22
RSVP Path Info:
My Address: 192.168.23.2
Explicit Route: 192.168.23.3 192.168.36.3 192.168.36.6 6.6.6.6
Record Route: NONE
Tspec: ave rate=750 kbits, burst=1000 bytes, peak rate=750 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=750 kbits, burst=1000 bytes, peak rate=750 kbits
Shortest Unconstrained Path Info:
Path Weight: 20 (TE)
Explicit Route: 192.168.23.2 192.168.23.3 192.168.36.3 192.168.36.6
6.6.6.6
History:
Tunnel:
Time since created: 6 minutes, 57 seconds
Time since path change: 5 minutes, 36 seconds
Number of LSP IDs (Tun_Instances) used: 22
Current LSP:
Uptime: 5 minutes, 36 seconds
The output above tells us that PE1 goes through P1 to get to PE2. It uses the shortest path. Let’s see what happens when we shut an interface on P1:
P1(config)#interface GigabitEthernet 0/1
P1(config-if)#shutdown
PE1 has to look for another path:
PE1#show mpls traffic-eng tunnels Tunnel 1
Name: PE1_t1 (Tunnel1) Destination: 6.6.6.6
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 1, type dynamic (Basis for Setup, path weight 30)
Config Parameters:
Bandwidth: 750 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: disabled LockDown: disabled Loadshare: 750 bw-based
auto-bw: disabled
Active Path Option Parameters:
State: dynamic path option 1 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
InLabel : -
OutLabel : GigabitEthernet0/2, 16
RSVP Signalling Info:
Src 2.2.2.2, Dst 6.6.6.6, Tun_Id 1, Tun_Instance 23
RSVP Path Info:
My Address: 192.168.24.2
Explicit Route: 192.168.24.4 192.168.45.4 192.168.45.5 192.168.56.5
192.168.56.6 6.6.6.6
Record Route: NONE
Tspec: ave rate=750 kbits, burst=1000 bytes, peak rate=750 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=750 kbits, burst=1000 bytes, peak rate=750 kbits
Shortest Unconstrained Path Info:
Path Weight: 30 (TE)
Explicit Route: 192.168.24.2 192.168.24.4 192.168.45.4 192.168.45.5
192.168.56.5 192.168.56.6 6.6.6.6
History:
Tunnel:
Time since created: 7 minutes, 54 seconds
Time since path change: 12 seconds
Number of LSP IDs (Tun_Instances) used: 23
Current LSP:
Uptime: 12 seconds
Selection: reoptimization
Prior LSP:
ID: path option 1 [22]
Removal Trigger: path error
So far, so good. PE1 now goes through P2 and P3 to get to PE2. Let’s enable the interface on P1 again:
P1(config)#interface GigabitEthernet 0/1
P1(config-if)#no shutdown
Let’s check the tunnel path:
PE1#show mpls traffic-eng tunnels Tunnel 1
Name: PE1_t1 (Tunnel1) Destination: 6.6.6.6
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 1, type dynamic (Basis for Setup, path weight 30)
Config Parameters:
Bandwidth: 750 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: disabled LockDown: disabled Loadshare: 750 bw-based
auto-bw: disabled
Active Path Option Parameters:
State: dynamic path option 1 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
InLabel : -
OutLabel : GigabitEthernet0/2, 16
RSVP Signalling Info:
Src 2.2.2.2, Dst 6.6.6.6, Tun_Id 1, Tun_Instance 23
RSVP Path Info:
My Address: 192.168.24.2
Explicit Route: 192.168.24.4 192.168.45.4 192.168.45.5 192.168.56.5
192.168.56.6 6.6.6.6
Record Route: NONE
Tspec: ave rate=750 kbits, burst=1000 bytes, peak rate=750 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=750 kbits, burst=1000 bytes, peak rate=750 kbits
Shortest Unconstrained Path Info:
Path Weight: 20 (TE)
Explicit Route: 192.168.23.2 192.168.23.3 192.168.36.3 192.168.36.6
6.6.6.6
History:
Tunnel:
Time since created: 8 minutes, 42 seconds
Time since path change: 1 minutes
Number of LSP IDs (Tun_Instances) used: 23
Current LSP:
Uptime: 1 minutes
Selection: reoptimization
Prior LSP:
ID: path option 1 [22]
Removal Trigger: path error
Even though the shortest unconstrained path is through P1, the tunnel doesn’t use this path yet. It remains on the path through P2 and P3. This happens because of the reoptimization timer. Take a look at the output below:
PE1#show mpls traffic-eng tunnels summary
Signalling Summary:
LSP Tunnels Process: running
Passive LSP Listener: running
RSVP Process: running
Forwarding: enabled
Head: 1 interfaces, 1 active signalling attempts, 1 established
2 activations, 1 deactivations
0 SSO recovery attempts, 0 SSO recovered
Midpoints: 0, Tails: 0
Periodic reoptimization: every 3600 seconds, next in 3012 seconds
Periodic FRR Promotion: Not Running
Periodic auto-bw collection: every 300 seconds, next in 12 seconds
The default periodic reoptimization timer is set to 3600 seconds. We’ll have to wait for another 3012 seconds until we switch over to the path through P1. If you want, you can change this timer with a global command:
PE1(config)#mpls traffic-eng reoptimize timers frequency ?
<0-604800> seconds between reoptimizations (0 disables reoptimization)
If you set it to 0, you disable reoptimization. Otherwise, you can select any value between 1 and 604800 seconds. You can’t change the reoptimization timer per tunnel. It’s a global command that applies to all tunnels.
Manual reoptimization
It’s also possible to trigger reoptimization manually. You could shut and no shut the tunnel or use this command:
PE1#mpls traffic-eng reoptimize tunnel 1
Now check out the tunnel:
PE1#show mpls traffic-eng tunnels Tunnel 1
Name: PE1_t1 (Tunnel1) Destination: 6.6.6.6
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 1, type dynamic (Basis for Setup, path weight 20)
Config Parameters:
Bandwidth: 750 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: disabled LockDown: disabled Loadshare: 750 bw-based
auto-bw: disabled
Active Path Option Parameters:
State: dynamic path option 1 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
InLabel : -
OutLabel : GigabitEthernet0/1, 17
RSVP Signalling Info:
Src 2.2.2.2, Dst 6.6.6.6, Tun_Id 1, Tun_Instance 24
RSVP Path Info:
My Address: 192.168.23.2
Explicit Route: 192.168.23.3 192.168.36.3 192.168.36.6 6.6.6.6
Record Route: NONE
Tspec: ave rate=750 kbits, burst=1000 bytes, peak rate=750 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=750 kbits, burst=1000 bytes, peak rate=750 kbits
Shortest Unconstrained Path Info:
Path Weight: 20 (TE)
Explicit Route: 192.168.23.2 192.168.23.3 192.168.36.3 192.168.36.6
6.6.6.6
History:
Tunnel:
Time since created: 11 minutes, 29 seconds
Time since path change: 19 seconds
Number of LSP IDs (Tun_Instances) used: 24
Current LSP:
Uptime: 22 seconds
Selection: reoptimization
Prior LSP:
ID: path option 1 [23]
Removal Trigger: reoptimization completed
The output above tells us that reoptimization has happened. This tunnel is now using the shortest path again.
Conclusion
You have now learned about MPLS TE reoptimization. By default, reoptimization happens every 3600 seconds for all tunnels. You can manually trigger a reoptimization with the mpls traffic-eng reoptimize tunnel
command.
- Unit 1: Introduction
- Unit 2: LDP (Label Distribution Protocol)
- Unit 3: MPLS VPN
- VRFs (Virtual Routing and Forwarding)
- MPLS L3 VPN Explained
- MPLS L3 VPN Configuration
- MPLS L3 VPN BGP Allow AS in
- MPLS L3 VPN BGP AS Override
- MPLS L3 VPN PE-CE RIP
- MPLS L3 VPN PE-CE EIGRP
- MPLS L3 VPN PE-CE OSPF
- MPLS L3 VPN PE-CE OSPF Default Route
- MPLS L3 VPN PE-CE OSPF Global Default Route
- MPLS L3 VPN PE-CE OSPF Sham Link
- VRF Lite Route Leaking
- MPLS VPN Extranet Route Leaking
- MPLS VPN VRF Export Map
- MPLS VPN VRF Import Map
- MPLS over FlexVPN
- Unit 4: MPLS L2 Encapsulation
- Unit 5: IPv6 MPLS
- Unit 6: MPLS Traffic Engineering (TE)
- Introduction to MPLS Traffic Engineering (TE)
- MPLS Traffic Engineering (TE) IS-IS Configuration
- MPLS Traffic Engineering (TE) OSPF Configuration
- MPLS TE RSVP-TE
- MPLS TE Static Routes
- MPLS TE Policy Based Routing (PBR)
- MPLS TE Autoroute Announce
- MPLS TE Autoroute Destination
- MPLS TE Autoroute Metric
- MPLS TE Unequal Cost Load Balancing
- MPLS TE Load Balancing between IGP and TE
- MPLS TE Forwarding Adjacency
- MPLS TE Path Options Explicit
- MPLS TE Class-Based Tunnel Selection (CBTS)
- MPLS TE Metric
- MPLS TE Setup and Hold Priority
- MPLS TE Attribute Flag and Affinity
- MPLS TE Reoptimization
- MPLS TE Fast Reroute (FRR)
- MPLS TE Fast Reroute Path Link Protection
- MPLS TE Fast Reroute Path Node Protection
- MPLS TE FRR RSVP Hello Support
- MPLS TE DiffServ Aware (DS-TE) Traditional
- MPLS TE Diffserv-Aware (DS-TE) IETF Mode
- MPLS VPN over MPLS TE Tunnels
- MPLS TE Per VRF TE tunnel