Dial-on-Demand Routing (DDR) backup is a method of bringing up an alternate link should the primary WAN link fail. The router configured for DDR backup recognizes that the connection to the remote site has been lost, and initiates a DDR connection to the remote site using a different transmission media.
There are no specific prerequisites for this document.
This document is not restricted to specific software and hardware versions.
The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.
For more information on document conventions, see the Cisco Technical Tips Conventions.
Configuring DDR backup involves two distinct steps:
Configure the DDR with either legacy DDR or dialer profiles. Verify that your DDR connection functions correctly before implementing the backup configuration. This will allow you to verify the dial method used, the Point-to-Point Protocol (PPP) negotiation, and authentication are successful before configuring backup. For sample DDR configurations (without DDR Backup) refer to Configuring ISDN DDR with Dialer Profiles and Configuring BRI-to-BRI Dialup with DDR Dialer Maps.
Configure the router to initiate the backup DDR connection when the primary link fails. This document discusses how to determine which backup method to use.
The router uses one of three methods to monitor the primary connection and initiate the backup connection when needed, as listed below:
Backup Interface - This is an interface that stays in standby until the primary interface line protocol is detected as down and then is brought up.
Floating Static Route - This backup route has an administrative distance greater than the administrative distance of the primary connection route and therefore would not be in the routing table until the primary interface goes down.
Dialer Watches - Dialer watch is a backup feature that integrates dial backup with routing capabilities.
This document discusses the features of each method and provides references to other documents that describe how to configure them. For more information on configuration and troubleshooting, refer to Configuring and Troubleshooting DDR Backup.
A backup interface is an interface that stays idle until certain circumstances occur, then it is activated. The backup interface can be a physical interface such as a Basic Rate Interface (BRI), or an assigned backup dialer interface to be used in a dialer pool. While the primary line is up, the backup interface is placed in standby mode. Once in standby, the backup interface is effectively shutdown until enabled. Any route associated with the backup interface will not appear in the routing table.
When the device receives an indication that the primary interface is down, the backup interface is brought up. The amount of time that the device waits to bring up the backup interface is adjustable using the backup delay command. You can also configure the backup interface to go down (after a specified time) when the primary connection is restored.
Since the backup interface command is dependent on the router identifying that an interface is physically down, it is commonly used to back up ISDN BRI connections, async lines and leased lines. This is because the interfaces to such connections go down when the link fails, hence the backup interface can quickly identify such failures. The backup interface approach may also be used for point-to-point Frame Relay subinterfaces. However, with Frame Relay, the main or multipoint interfaces can remain in an up/up state even if the permanent virtual connection (PVC) goes down. This could cause the router to not detect a down primary Frame Relay connection and hence fail to bring up the backup link.
It is independent of routing protocols. That is, it does not depend on routing protocol convergence, route stability and so on.
It can be based upon load (Bandwidth On Demand). Additional links can be added to a connection depending on the traffic load.
It is dependent upon the interface going down. The router must detect that the primary interface line protocol is down for it to activate the backup link.
It is dependent upon interesting traffic to trigger the DDR backup call. Hence, even if the backup interface comes out of standby mode, the router will not trigger the backup call unless it receives interesting traffic for that backup interface.
Encapsulation is a factor. For example, with a Frame Relay connection, the line protocol may not go down when a particular PVC/DLCI goes down. Since the router cannot detect the failure, the backup link may not be activated.
The backup interface is placed in standby mode and is unusable while the primary interface is up. Hence, placing physical interfaces such as interface bri 0 (for BRIs), or interface Serial0:23 (for PRIs) as the backup interface, renders them unusable. You can avoid this by using dialer profiles for the backup link. With dialer profiles, only the logical (dialer interface) is placed in the standby mode while the physical interface (BRI) can still be used for other connections by making it a member of another pool.
It provides backup to one interface on a single router.
Floating static routes are static routes that have an administrative distance greater than the administrative distance of dynamic routes. Administrative distances can be configured on a static route so that the static route is less desirable than a dynamic route. In this manner, the static route is not used when the dynamic route is available. However, if the dynamic route is lost, the static route can take over, and traffic can be sent through this alternate route. If this alternate route is provided using a DDR interface, then that interface can be used as a backup mechanism.
Following is the sequence for floating static routes:
The primary interface learns a primary route to a remote network (using a static route or a dynamic routing protocol). The administrative distance of this learned route is less than the floating static, so the learned route is used.
The primary interface becomes inoperable, although line protocol may remain up. Loss of routing updates eventually removes the learned primary route from the routing table.
Note: When the primary route is a static route, the primary interface line protocol must go down for the floating static route to be used.
The floating static route is used since it is now the route with the lowest administrative distance.
This is independent of line protocol status. This is an important consideration on Frame Relay circuits, where the line protocol may not go down if the DLCI is inactive.
It is encapsulation independent.
It can backup multiple interfaces/networks on a router.
This requires a routing protocol.
It is dependent upon the routing protocol convergence times. A flapping route can cause the backup interface to be activated unnecessarily.
It can typically only provide backup for a single router.
It is dependent upon interesting traffic to trigger the DDR backup call. Therefore, even if the router installs the floating static route in the route table, the router does not actually trigger the backup call unless it receives interesting traffic for that backup interface. In most cases, you must mark the routing protocol as uninteresting to prevent the periodic updates/hellos from keeping the backup link up.
Note: Although the above documents describe using floating static routes to backup a Frame Relay connection, the same configuration concepts apply to most other WAN backup scenarios.
Dialer watch is a backup feature that integrates dial backup with routing capabilities. Dialer watch provides reliable connectivity without relying solely on defining interesting traffic to trigger outgoing calls at the central router. Therefore, dialer watch can also be considered regular DDR with no requirement for interesting traffic, just lost routes. By configuring a set of watched routes that define the primary interface, you are able to monitor and track the status of the primary interface as watched routes are added and deleted.
With dialer watch, the router monitors the existence of a specified route and if that route is not present, it initiates dialing of the backup link. Unlike the other backup methods (such as backup interface or floating static routes) dialer watch does not require interesting traffic to trigger the dial. The process used by dialer watch is described below:
When a watched route is deleted, dialer watch checks for at least one valid route for any of the IP addresses or networks being watched.
If there is no valid route, the primary line is considered down and unusable. Dialer watch then initiates the call, the routers connect and exchange routing information. All traffic for the remote network will now use the backup link.
If there is a valid route for at least one of the watched IP networks defined and the route is pointing to an interface other than the backup interface configured for dialer watch, the primary link is considered up and dialer watch does not initiate the backup link.
After the backup link is up, the primary link is checked again at the expiration of each idle timeout. If the primary link remains down, the idle timer is reset. Since the router should periodically check whether the primary link has been reestablished, you should configure a small value for the dialer idle-timeout. When the primary link is reestablished, the routing protocol updates the routing table and all traffic should once again pass on the primary link. Since traffic no longer passes across the backup link, the idle timeout expires and router deactivates the backup link.
Note:
Configure on caller router routing protocols as uninteresting in the interesting traffic definition to prevent periodic hellos from resetting the idle timeout. Since the router uses the interesting traffic definition ONLY to check whether the primary link is active, consider making all IP traffic uninteresting using the command dialer-list number protocol ip deny. With this interesting traffic definition, the idle timeout is never reset, and the router checks the status of the primary link at the specified interval. On the calling router, you do not need to define dynamic routing protocol as uninteresting traffic, as long as the router will not do any dial-out.
Configure the backup link to be less desirable than the primary link as seen by the routing protocol used. This is because when the primary link becomes available once again, the dynamic routing protocol prefers the primary over the dialup link and not load balance across the two links, thus keeping the backup link up indefinitely. The backup link can be configured as less desirable with any of the following commands; bandwidth, delay or distance as appropriate.
If the primary link is reactivated, the secondary backup link is disconnected. However, you can implement a disable timer so that there is a delay before the backup link is dropped once the primary link recovers. This delay timer is started when the idle timer expires, and the primary route is found to be up. This delay timer can ensure stability, especially for flapping interfaces or interfaces experiencing frequent route changes. This delay timer can ensure stability, especially for flapping interfaces or interfaces experiencing frequent route changes. This delay timer can be configured using the dialer watch-disable seconds interface command.
Dialer Watch has the following considerations:
Routing - Backup initialization is linked to the dynamic routing protocol, rather than a specific interface or static route entry. Therefore, both primary and backup interfaces can be any interface type, and can be used across multiple interfaces and multiple routers.
Nonpacket Semantics - Dialer watch does not rely on interesting packets to trigger dialing. The link is automatically brought up when the primary route goes down without postponing dialing. This is an important consideration on Frame Relay circuits, where the line protocol may not go down if the DLCI is inactive.
Dial Backup Reliability - The dialer watch redial functionality is extended to dial indefinitely in the event that secondary backup lines are not initiated. Typically, DDR backup redial attempts are affected by enable-timeouts and wait-for-carrier time values. Intermittent media difficulties or flapping interfaces can cause problems for traditional DDR links. However, dialer watch automatically re-establishes the secondary backup line on ISDN, synchronous, and asynchronous serial links.
You can use dialer watch to enable the router to check whether the primary route is up after the initial startup of the router is complete and a configured timer (in seconds) expires. You can use the following command to achieve this:
dialer watch-list <group-number> delay route-check initial <seconds>
This command enables the router to check whether the primary route is up after the initial startup of the router is complete and the timer (in seconds) expires. Without this command, dialer watch is only triggered when the primary route is removed from the routing table. If the primary link fails to come up during initial startup of the router, the route is never added to the routing table and hence cannot be watched. Therefore, with this command, dialer watch dials the backup link in the event of a primary link failure during the initial start up of the router.
It is useful for a multiple router backup scenario. A router can watch the link/route between two other routers and initiate the backup if that link fails.
It is independent of line protocol status.
It is dynamic routing protocol independent.
It is encapsulation independent.
It dials immediately upon detecting the loss of the primary route.
Routing—Backup initialization is linked to the dynamic routing protocol rather than a specific interface or static route entry. Therefore, both primary and backup interfaces can be any interface type, and can be used across multiple interfaces and multiple routers. Dialer watch also relies on convergence which is sometimes preferred over traditional DDR links.
Routing protocol independent—Static routes or dynamic routing protocols such as Interior Gateway Routing Protocol (IGRP), Enhanced IGRP (EIGRP) or Open Shortest Path First (OSPF) can be used.
Nonpacket semantics—Dialer watch does not exclusively rely on interesting packets to trigger dialing. The link is automatically brought up when the primary line goes down without postponing dialing.
Dial backup reliability—DDR redial functionality is extended to dial indefinitely in the event that secondary backup lines are not initiated. Typically, DDR redial attempts are affected by enable-timeouts and wait-for-carrier time values. Intermittent media difficulties or flapping interfaces can cause problems for traditional DDR links. However, dialer watch automatically re-establishes the secondary backup line on ISDN, synchronous, and asynchronous serial links.
It is more difficult to configure than the backup interfaces and floating static routes methods.
It requires a routing protocol.
It is dependent upon the routing protocol convergence time.
The router is dial backup-capable, meaning that the router has a data communications equipment (DCE), a terminal adapter, or a network termination 1 device attached that supports V.25 bis.
The router is configured for DDR. This configuration includes traditional commands such as dialer map and dialer in-band commands.
Dialer watch is only supported for IP at this time.
Dialer watch was unstable until Cisco IOS® Software Release 12.1(7).
Note: It is recommenced that you use Cisco IOS Software Release12.1(7) or higher, which includes fixes for IOS bugs that affect dialer watch.
The following table summarizes the characteristics of the three backup methods. You can use it to compare and evaluate them to make a decision on which method to use.
Note: Following the table are links to various documents on CCO that provide examples on how to configure each of the DDR backup methods.
Backup Interface | Floating Static Route | Dialer Watch |
---|---|---|
Dependent on line protocol status of primary interface and requires that the primary interface go down. | Employs static routes with higher administrative distance to trigger DDR call. | Watches specific routes in the routing table and initiates backup link if the route is missing. |
Encapsulation is a factor. For example, Frame Relay backup may not work correctly with backup interface. | Encapsulation independent. | Encapsulation independent. |
Does not consider end-to-end connectivity. Problems with end-to-end connectivity, such as routing errors, do not trigger backup links. | Evaluates status of primary link based on the existence of routes to the peer. Hence it considers primary link status based on the ability to pass traffic to the peer. | Evaluates status of primary link based on the existence of routes to the peer. Hence it considers primary link status based on the ability to pass traffic to the peer. |
Needs interesting traffic to trigger dialing the backup link. | Needs interesting traffic to trigger dialing the backup link even after the route to the peer is lost. | Does not rely on interesting packets to trigger dialing. Dialing the backup link is done immediately when the primary route is lost. |
Does not depend on the Routing protocol. | Dependent on the routing protocol convergence time. | Dependent on the routing protocol convergence time. |
Routing protocol independent. | All dynamic routing protocols supported. | All dynamic routing protocols supported. |
Limited to one router, one interface. | Typically limited to single router, but with multiple interface/networks. | Supports multiple router backup scenario. For example, one router monitors the link between two other routers and initiates the backup if that link fails. |
Can be used to provide bandwidth on demand. The backup interface can be setup to activate when the primary link reaches a specified threshold. | Bandwidth on demand is not possible since the route to the peer will exist regardless of the load on the primary link. | Bandwidth on demand is not possible since the route to the peer will exist regardless of the load on the primary link. |