Using Dialer Watch

Problem

You want to use Cisco's Dialer Watch feature to trigger dial backup.

Solution

The Dialer Watch feature allows the router to track a particular destination IP address in its routing table. If all of the tracked IP addresses disappear from the routing table, the router automatically triggers the dial backup connection:

Router1#configure terminal 
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#interface BRI0/0
Router1(config-if)#ip address 10.1.99.55 255.255.255.0
Router1(config-if)#encapsulation ppp
Router1(config-if)#dialer map ip 10.1.1.0 name dialhost broadcast 95551212
Router1(config-if)#dialer map ip 10.2.0.0 name dialhost broadcast 95551212
Router1(config-if)#dialer map ip 10.1.99.1 name dialhost broadcast 95551212
Router1(config-if)#dialer load-threshold 50 either
Router1(config-if)#dialer watch-group 1
Router1(config-if)#dialer-group 1
Router1(config-if)#isdn switch-type basic-ni
Router1(config-if)#isdn spid1 800555123400 5551234
Router1(config-if)#isdn spid2 800555123500 5551235
Router1(config-if)#ppp authentication chap
Router1(config-if)#ppp multilink
Router1(config-if)#exit
Router1(config)#router eigrp 55
Router1(config-router)#network 10.0.0.0
Router1(config-router)#exit
Router1(config)#username dialhost password cisco
Router1(config)#access-list 101 deny eigrp any any
Router1(config)#access-list 101 permit ip any any
Router1(config)#dialer-list 1 protocol ip list 101
Router1(config)#dialer watch-list 1 ip 10.2.0.0 255.255.0.0
Router1(config)#dialer watch-list 1 ip 10.1.1.0 255.255.255.0
Router1(config)#dialer watch-list 1 delay route-check initial 300
Router1(config)#dialer watch-list 1 delay disconnect 15
Router1(config)#end
Router1#

 

Discussion

This configuration is similar to that of Recipe 13.1, but this time the router uses the dialer watch feature to trigger the dial backup. The dialer watch-group command configures the backup interface to belong to a particular group. Usually you would only configure one such group on a router, but there is nothing to prevent you from having several different watch groups with different dial interfaces in each.

The watch group in this example looks for two prefixes in the routing tables, 10.1.1.0/24 and 10.2.0.0/16. If both of these routes drop out of the routing table, the router will automatically bring up the dial interface. Note that all of the watched routes must disappear before the router will dial.

We have configured several dialer map statements for this example. There is the same dialer map statement that we used in Recipe 13.1 to define the basic IP routing of the interface. And we have also included a dialer watch-list that specifies the two watched IP addresses.

We have also included the same dialer list configuration here, as we did in Recipe 13.1. This is because we still don't want routine EIGRP packets to bring up the dial interface or to keep the link up after the watched routes have returned to the routing table.

After it triggers the dial backup, the dialer watch configuration will keep track of the primary interface by periodically looking for the watched IP addresses in its routing table. The dialer watch feature will only consider the primary circuit active if the watched routes exist in the routing table, and if they do not point through the dial interface. We have configured two special timers that affect the dialer watch behavior:

Router1(config)#dialer watch-list 1 delay route-check initial 300
Router1(config)#dialer watch-list 1 delay disconnect 15

The first of these commands, with the delay route-check initial keywords, tells the router to wait for 300 seconds (5 minutes) after the router boots before starting to watch the routing table. This is useful because it often takes some time for all of the links to come up, and longer still before the routing tables have stabilized. By default, the router will begin checking the routing table immediately after booting. So setting a reasonable value like 300 seconds, as we have done, prevents unnecessary and potentially costly dialing.

The second command, with the delay disconnect keywords, tells the router to wait the specified number of seconds before disconnecting the dialup link.

Both of these commands are new to IOS Version 12.2(8)T. For earlier IOS versions, you can set the disconnect time by using the dialer watch-disable command:

Router1(config-if)#dialer watch-disable 15

However, prior to Version 12.2(8)T, there is no option for preventing unnecessary dialing immediately after booting.

Note that we also have defined a dialer-group command in the example:

Router1(config)#interface BRI0/0
Router1(config-if)#dialer-group 1
Router1(config-if)#exit
Router1(config)#dialer-list 1 protocol ip list 101
Router1(config)#access-list 101 deny eigrp any any
Router1(config)#access-list 101 permit ip any any

This specifies the interesting packets that will reset the dial idle-timer. This is not strictly necessary, but we believe that it is a good idea. The router will only check the status of the watched routes when the idle-timer reaches zero. If we did not include a dialer-group command on the interface, then no packets would be considered interesting and the idle-timer would count down from its maximum value (120 seconds by default) before rechecking the watch condition. If the missing routes have returned, the router will start the watch-disable timer and then disconnect the dialer.

The default dialer watch-list delay disconnect timer is zero, meaning that the router will immediately drop the connection. This could cause problems because it is possible that the routing protocol has not yet fully converged throughout the network. In this case, we have set a watch disconnect timer of 15 seconds to make sure that there is sufficient time to allow the routing protocol to fully recover before breaking the connection. And, because we are somewhat paranoid, we have also configured a dialer-group command to ensure that the router will never drop the dial connection if it is still in use.

In general, we still prefer to use floating static routes to trigger dial backup, as in Recipes 13.1 and 13.2. This is because they offer greater control and flexibility. The floating static method allows you to dial on the loss of any of a list of routing prefixes, while the dialer watch method won't trigger until you lose all of the list of prefixes. However, it is interesting to note that the dialer-group configuration in this recipe is the same as in the floating static route examples. So you could actually combine the two approaches by simply including a static route with a high administrative distance pointing to the dialer interface.

See Also

Recipe 13.1; Recipe 13.2