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:

Mpls Te Pe C Router Topology Tunnel

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.