Ensuring Proper Disconnection

Problem

You want to ensure that the dial backup line disconnects properly when the primary link recovers.

Solution

Sometimes funny things happen when the primary link comes back and the backup link has not yet disconnected. These problems are usually due to poor routing metrics, causing at least one of the routers to prefer the dial path, even if the primary is available. The easiest way to handle these problems is to use bandwidth commands to ensure that the primary is the better path:

Router1#configure terminal 
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#interface Serial0/0.1 point-to-point
Router1(config-subif)#bandwidth 56
Router1(config-subif)#exit
Router1(config)#interface BRI0/0
Router1(config-subif)#bandwidth 54
Router1(config-subif)#end
Router1#

 

Discussion

This example assumes that you have a Frame Relay connection using a 56 Kbps primary link, and an ISDN dial backup connection. The problem is that the default ISDN interface bandwidth is 64 Kbps. So, if both the primary and the backup are active at the same time, the routing protocol will see the backup link as the preferred path. As a result, there will always be interesting traffic flowing through the backup link, and the router will fail to disconnect the dialup session properly.

To address this problem, we have configured a bogus bandwidth on the BRI interface. This will ensure that if both primary and backup are active simultaneously, the primary will be the better path. The only stipulation is that the value be lower for the backup path.

Actually, this change only affects the routing decisions for traffic going from this router to the dial router. It is not difficult to get a situation in which traffic from the branch to the hub site takes the primary path, while outbound packets to the branch take the backup path. So you have to be careful to adjust the values on both ends.

Dial backup situations can get more complicated in some networks. Perhaps the most insidious problems happen when the router responsible for the primary WAN link summarizes a large number of branch IP address ranges. This summarization is normally a good thing because it simplifies the global routing tables, and improves overall performance.

However, suppose the branch has a LAN segment that uses 10.11.100.0/24. And suppose the primary WAN router connects to many branches, offering the network core only a summary route that describes all of the branches as 10.11.0.0/16. When the primary WAN link for this branch breaks, the branch router dials to a dedicated dial backup router. The dynamic routing works because although the primary WAN router advertises a summary route that includes this branch's LAN address, the backup router advertises a more specific route. So other devices in the network core can route to the branch by using the more specific route from the backup router.

The problem appears when the primary link recovers. There are now two paths available. By adjusting bandwidths as shown in this recipe, the branch router knows that it should switch to using the primary link. But the rest of the network doesn't see any change. The primary router continues to present only a summary route for all of its branches, and the dial backup host still presents the more specific route for this particular branch. So all outbound traffic to the branch still uses the backup link.

We know of no simple solution to this problem except to ensure that the branch router is responsible for dropping the dial connection with an appropriate timeout. The alternatives are to avoid summarization or to have the dial backup router be the same physical device as the primary WAN router. You can help the branch router to switch to the primary by ensuring that the dial host router only sends a default route rather than a full routing table. This way, when the primary circuit recovers, the branch router will use the more specific routes that it learns through the primary circuit, thus quickly removing any interesting packets from the backup link.