Static Routes That Track Interfaces or Other Routes

Problem

You want to install a static route only when an interface fails or a prefix drops out of the routing table.

Solution

One of the interesting new features in IOS Versions 12.3T and 12.4 is the ability to track things like interface status or routing table objects. This first example shows how to create a static route that tracks an interface:

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#track 10 interface Serial0/0 line-protocol
Router(config-track)#delay down 5 up 30
Router(config-track)#exit
Router(config)#ip route 192.168.10.0 255.255.255.0 10.3.12.26 track 10
Router(config)#end 
Router#

This second example shows how to create a static route that tracks a prefix in the IP routing table:

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#track 11 ip route 10.2.95.0 255.255.255.0 reachability
Router(config-track)#delay down 5 up 5
Router(config-track)#exit
Router(config)#ip route 0.0.0.0 0.0.0.0 10.3.12.26 track 11
Router(config)#end 
Router#

And the final example installs the static route when a combination of the previous conditions is met:

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#track 12 list boolean and
Router(config-track)#object 10 not
Router(config-track)#object 11 
Router(config-track)#exit
Router(config)#ip route 192.168.13.0 255.255.255.0 10.3.12.26 track 12
Router(config)#end
Router#

Discussion

The idea of tracking objects should already be fairly familiar. In Recipe 5.5, we used a floating static route, which would be installed only if the dynamic routing protocol removed a similar routing prefix. In fact, you can use this method in conjunction with floating statics, as the ip route track command includes an optional administrative distance argument at the end of the line:

Router(config)#ip route 192.168.10.0 255.255.255.0 10.3.12.26 track 10 190

However, in most cases, this is probably not a good idea because it will make your routing more complicated and consequently more difficult to troubleshoot. Combining these two methods means that there are now two potentially complicated and interrelated decisions to be made in selecting which routes to install. So when you look at your routing table, you may not be able to immediately see why a given route is or is not present. Since this method does at least install the routes into the routing table, we prefer this complicated method to policy-based routing, which is always complicated to troubleshoot, but if you are tempted to use this feature, we recommend looking for a simpler solution first.

In Chapter 22, we will show how Hot Standby Routing Protocol (HSRP) can also track changes in interfaces, or how routing prefixes can affect which router is the default gateway for a subnet. The track feature offers a flexible and general method for doing this.

In each of the different examples, there are two steps. First, you define a tracked object:

Router(config)#track 10 interface Serial0/0 line-protocol
Router(config-track)#delay down 5 up 30
Router(config-track)#exit

In this case, we are tracking the line protocol state of interface Serial0/0. If the interface is in an up/up state, then this object will be considered "up" as well, and anything that is tracking this object will respond accordingly.

Note that we have also included a delay command in this example. By default the tracking object will change state as soon as the router notices that the line protocol has come up or gone down. However, this isn't always a good idea. If this interface is flapping up and down frequently, then it would be better to wait a while to ensure that it's really up. Also, some protocols, such as Frame Relay, can take a significant length of time to establish end-to-end connectivity. The delay command allows you to specify and appropriate delay. In this case, we have opted to wait 5 seconds after the interface goes down, and 30 seconds after it comes back up, before changing the state of the tracking object.

Once you have defined an object with the track command, you need to do something with that object. In this case, we have created a static route:

Router(config)#ip route 192.168.10.0 255.255.255.0 10.3.12.26 track 10

In Chapter 22, we will show how to use these tracked objects with Hot Standby Routing Protocol (HSRP) and Virtual Router Redundancy Protocol (VRRP), and introduce several other IOS features that can also respond to tracked objects.

To see the state of a tracking object, use the show track command:

Router#show track 10
Track 10
 Interface Serial0/0 line-protocol
 Line protocol is Up
 6 changes, last change 00:33:44
 Delay up 30 secs, down 5 secs
 Tracked by:
 STATIC-IP-ROUTING 0
Router#

And you can see the corresponding static route as follows:

Router#show ip route track-table
ip route 192.168.10.0 255.255.255.0 10.3.12.26 track 10 state is [up] 
Router#

If the tracked interface goes down, the tracked object follows suit and the static route is removed:

Router#show track 10
Track 10
 Interface Serial0/0 line-protocol
 Line protocol is Down (hw down)
 7 changes, last change 00:00:03
 Delay up 30 secs, down 5 secs
 Tracked by:
 STATIC-IP-ROUTING 0
Router#show ip route track-table
ip route 192.168.10.0 255.255.255.0 10.3.12.26 track 10 state is [down] 
Router#

Cisco offers a useful alternative to merely tracking the Layer 2 line protocol. You can opt instead to track the interface's Layer 3 IP protocol state with the ip routing keywords:

Router(config)#track 15 interface Serial0/0 ip routing
Router(config-track)#

In the second example from the Solution section of this recipe, we showed how to track a particular prefix from the IP routing table:

Router(config)#track 11 ip route 10.2.95.0 255.255.255.0 reachability
Router(config-track)#delay down 5 up 5

When you check the status of this object, it shows several useful pieces of information:

Router#show track 11
Track 11
 IP route 10.2.95.0 255.255.255.0 reachability
 Reachability is Up (EIGRP)
 2 changes, last change 00:00:09
 Delay up 5 secs, down 5 secs
 First-hop interface is FastEthernet0/0
 Tracked by:
 STATIC-IP-ROUTING 0
Router#

Here we can see that the tracked routing prefix is active in the routing table, that it was learned by EIGRP, when it last changed state, and even which interface the router uses to reach this destination.

In the example, we have configured a static default route to be installed whenever the dynamically learned one is also available:

Router(config)#ip route 0.0.0.0 0.0.0.0 10.3.12.26 track 11

The third example in the Solution section shows how you can combine several tracked objects into one:

Router(config)#track 12 list boolean and
Router(config-track)#object 10 not
Router(config-track)#object 11 
Router(config-track)#exit
Router(config)#ip route 192.168.13.0 255.255.255.0 10.3.12.26 track 12

Here we have created a static route that is available only if the condition of object 10 is down and object 11 is up:

Router#show track 12
Track 12
 List boolean and
 Boolean AND is Up
 2 changes, last change 00:00:30
 object 10 not Down
 object 11 Up
 Tracked by:
 STATIC-IP-ROUTING 0
Router#show ip route track-table
 ip route 192.168.10.0 255.255.255.0 10.3.12.26 track 10 state is [down]
 ip route 0.0.0.0 0.0.0.0 10.3.12.26 track 11 state is [up]
 ip route 192.168.13.0 255.255.255.0 10.3.12.26 track 12 state is [up]
Router#

This allows you to construct some complex alternate routing rules that are much more flexible than simple floating static routes. When you get more complex rules that reference other rules like this, it can be useful to use the brief keyword:

Router#show track brief
Track Object Parameter Value
10 interface Serial0/0 line-protocol Down (hw down)
11 ip route 10.2.95.0/24 reachability Up (EIGRP)
12 list boolean Up
Router#

We note in passing that there doesn't appear to be much error checking in this list feature. It is possible to construct an infinite loop of rules where, for example, tracked object 100 tracks object 101, which in turn tracks only the negated object 100. Doing this results in a constant flapping situation, which fortunately doesn't crash the router or run up the CPU, but isn't terribly constructive nonetheless, so we advise checking your logic carefully.

All of the examples we have discussed so far use straight binary up/down logic, but in fact the track feature allows for shades of grey by means of the threshold keyword. Here is an example of the syntax for this option:

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#track 15 ip route 10.4.4.4 255.255.255.4 metric threshold
Router(config-track)#threshold up 99 down 201
Router(config-track)#exit
Router(config)#ip route 0.0.0.0 0.0.0.0 10.3.12.26 track 11
Router(config)#end 
Router#

The key to this command is the threshold command. The "up" and "down" threshold numbers that you specify on this line represent the routing protocol metric rescaled to a range from 0 to 255. What this actually corresponds to in practice depends on your routing protocol. Table 5-4 shows how to convert between routing protocol metrics and threshold numbers.

Table 5-4. Default conversion factors for scaled metrics
Routing protocol	Default conversion rule
RIP	Multiply by 17
EIGRP	Divide by 2,560
OSPF	Divide by 1

We haven't included BGP in this table because BGP metrics don't work in the same way, and consequently aren't supported with this feature.

As an aside, you can change these conversion values for EIGRP and OSPF (but not RIP) by specifying the new conversion rule value in the track resolution command:

Router(config)#track resolution ip route ospf 100
Router(config)#track resolution ip route eigrp 10000

This example will change the conversion factor from the default values shown in Table 5-4 to new values of 100 for OSPF and 10,000 for EIGRP.

In our example, we have configured an "up" threshold of 99 and a "down" threshold of 201, and we're using EIGRP for our routing protocol. This means that when the scaled metric value is less than or equal to 99 (EIGRP metric of 253,440, by default), the tracked object will be considered "up." Similarly, when the scaled metric is greater than or equal to 201 (EIGRP metric of 514,560, by default), it will be considered "down."

When the metric is in between these two values, the state of the tracked object depends on how it has changed. These are classic "rising" and "falling" thresholds, which we will discuss in more detail in Chapter 17. If the metric rises from a value below the "down" threshold value (201) to a higher value, then the tracked object changes state from "up" to "down." Conversely, if the metric falls from above to below the "up" threshold (99), then the tracked object changes state to "up."

The track list feature also allows you to work in logical shades of grey when you use the threshold option:

Router(config)#track 50 interface Serial0/0 line-protocol
Router(config)#track 51 interface Serial0/1 line-protocol
Router(config)#track 52 interface FastEthernet0/0 line-protocol
Router(config)#track 100 list threshold percentage
Router(config-track)#object 50
Router(config-track)#object 51
Router(config-track)#object 52
Router(config-track)#threshold percentage up 65 down 34
Router(config-track)#exit
Router(config)#ip route 192.168.13.0 255.255.255.0 10.3.12.26 track 100

In this example, we create a list of tracking objects that are associated with interfaces. Then we say that we want this list to be considered "up" if 65 percent or more of the objects in the list are "up" and "down" if 34 percent or less are "down." So, if any two of the three in this example are "up," the whole list is considered "up," and if two or more are "down," the whole list is "down."

You can see the state of the list as well as the individual objects very neatly with the show track command:

Router#show track 100
Track 100
 List threshold percentage
 Threshold Percentage is Up (66%)
 4 changes, last change 00:00:27
 object 50 Up (33%)
 object 51 Down (0%)
 object 52 Up (33%)
 Threshold percentage down 34% up 65%
 Tracked by:
 STATIC-IP-ROUTING 0
Router#

There is another way to construct such a list, using the weight keyword:

Router(config)#track 101 list threshold weight
Router(config-track)#object 50 weight 10
Router(config-track)#object 51 weight 15
Router(config-track)#object 52 weight 20
Router(config-track)#threshold weight down 15 up 30
Router(config-track)#exit

Using this method, you can assign different weighting values to each of the objects in the list to define their relative importance in your network. In this case, we have set the "up" threshold to a value of 30. This can be achieved if object 52 is up at the same time as either of 50 or 51. But it is not sufficient to have both 50 and 51 "up" if 52 is "down:"

Router#show track 101
Track 101
 List threshold weight
 Threshold Weight is Up (30/45)
 2 changes, last change 00:07:33
 object 50 Up (10/45)
 object 51 weight 15 Down (0/45)
 object 52 weight 20 Up (20/45)
 Threshold weight down 15 up 30
Router#