Tunnel Reoptimization

What happens if, while a tunnel is up, a path appears that is a new best path from head to tail? Consider the network shown in Figure 4-7.

In Figure 4-7:

• All links start with 100-Mbps reservable bandwidth.

• Router A and Router D both want to build 60-Mbps tunnels to Router H.

• The link between Router D and Router H is down.

Assume that the following sequence of events happens:

• Router D builds a tunnel DCH.

• Router A builds a tunnel ABCEFGH.

• Router D reduces its DCH bandwidth reservation to 30 Mbps, either by configuration or because of something like auto bandwidth adjustment.

At this point, the best possible path Router A could take to get to Router H is ABCH. But Router A already has a tunnel established. Should Router A change its tunnel over to the BCH path? What if Router D needs to increase its tunnel bandwidth again? How long should Router A wait before cutting over to the best path? You can ask all kinds of questions along this line.

When a router looks to see if there is a better path for tunnels that are already up, this is known as reoptimization. Four things affect reoptimization:

• Periodic reoptimization

• Manual reoptimization

• Event-driven reoptimization

• Lockdown

It's important to understand that this reoptimization has nothing to do with the behavior when a tunnel goes down. If a tunnel goes down, you don't wait for the reoptimization timer to kick in before trying to find a better path for that tunnel; that calculation is done immediately.

Finally, realize that RSV-TE has what's called make-before-break, so that the act of making a new tunnel reservation does not disturb any existing reservations for that tunnel. This is covered in more detail in the "Resource Reservation Protocol (RSVP)" section.

Periodic Reoptimization

Cisco implements a periodic reoptimization timer, which can be configured on a global basis. After a tunnel comes up, an attempt is made to find a better path for it, given the tunnel's configured constraints. By default, this happens once an hour; this timer can be configured through the command mpls traffic-eng tunnels reoptimize timers frequency 0-604800. 0-604800 is how often (in seconds) Cisco IOS Software looks for a better path for a tunnel.

Setting this timer to 0 means that tunnels are never reoptimized after they are up; on the other end of the scale, 604,800 is the number of seconds in 168 hours, or exactly one week. The default reoptimization timer is 3600 seconds, or one hour.

It's important to note that the reoptimization timer, although it can be configured only globally, is kept on a per-tunnel basis. What does this mean? Suppose you have 20 different tunnels, T1 through T20, that come up 2 minutes after each other (T1 comes up at 00:00, T2 at 00:02, T3 at 00:04, and so on). T20 comes up at 00:40. Twenty minutes after that, the global reoptimization timer for T1 kicks in and tries to find a better path, but only for T1. T20 is not reoptimized until it has been up for an hour, or when the clock reads 1:40.

Manual Reoptimization

What if you know there's been a change in your network, and you don't want to wait for that tunnel's reoptimization timer to kick in before finding a better path? You can use the enable-level command mpls traffic-eng reoptimize [tunnel-name] to force the router to reoptimize a specific tunnel at any time.

Event-Driven Reoptimization

Finally, consider the link between RtrD and RtrH in Figure 4-7. If that link comes up, should RtrD reoptimize its DH tunnel so that this tunnel flows over the directly connected link? Probably. But there are scenarios in which a link coming up should not trigger a reoptimization.

One scenario in which an up link should not trigger a reoptimization is if the link is flapping and the IGP timers aren't enough to hide the flapping from the network. Reoptimizing onto a flapping link and then calculating a path around that link when it fails again constantly changes the tunnel's path characteristics. Although RSVP's make-before-break leads to minimal data loss along this path, a constantly changing tunnel path could lead to large delay variation, which isn't good for either data (TCP) or voice.

For this reason, tunnels are not automatically reoptimized when a new link comes up. Tunnels are reoptimized onto a link that has just come up when the tunnel reoptimization timer goes off, but not until then. You can change this behavior with the following global configuration:

mpls traffic-eng reoptimize events link-up

Lockdown

You might have some tunnels that you don't ever want to reoptimize. You can specify this on a per-tunnel basis using the lockdown option in the path option specification:

tunnel mpls traffic-eng path-option preference {dynamic | explicit name name |

  identifier id>} {lockdown}

The reason for putting lockdown on a path option as opposed to a tunnel itself is that there might be some paths you never want to leave as long as the links underneath those paths are up, but if the underlying links are down, you want to fall back to another path until the preferred path is up.

To make that last sentence clearer, an example is in order.

In Figure 4-8, each link has 100 Mbps reservable to begin with.

At some point in time, two tunnels were established; at that time, the lower link between RtrC and RtrD was down. At some point after these tunnels came up, the lower link also came up. A 60-Mbps tunnel from RtrA to RtrE crosses the top CD link, and a 30-Mbps tunnel from RtrB to RtrE crosses the same link. Figure 4-9 shows this.

When a reoptimization happens on either of these tunnels (periodic, manually triggered, or because of the link-up event), whichever tunnel happens to reoptimize puts itself on the other link. Assume that it's the BE tunnel. Figure 4-10 shows what things look like after that reoptimization.

But what if you didn't want the BE tunnel to reoptimize for some reason? If that tunnel had been configured with tunnel mpls traffic-eng path-option … lockdown, it would not have reoptimized and shifted to the other link. It will reconverge on the bottom CD link if the top CD link goes down, however.