Configuring and Troubleshooting DDR Backup

Introduction

Dial-on-demand routing (DDR) backup is used to provide backup to a WAN link (for example, Frame Relay and T1) using any DDR or a dial-capable interface. Common DDR backup links include ISDN BRIs, modems on auxiliary ports and T1/E1s.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

Background Information

For the purpose of this document, the two DDR terms used are defined as follows:

• Normal DDR - A scenario where one router dials the other side whenever there is traffic that needs to traverse the link. This configuration does not include any backup related commands.

• Backup DDR - A normal DDR configuration with the added capability that it is triggered when the primary interface goes down. This is accomplished by adding the appropriate backup commands to a normal DDR configuration.

The following steps provide guidelines on designing, configuring, verification, and troubleshooting DDR backup:

• Design:

  • Determine which interfaces are the Primary and Backup Links.

  • Determine the backup method to implement. The choices are Backup Interface, Floating Static Router and Dialer Watch.

• Configuration:

  • Configure the backup link with normal DDR using either legacy DDR (dialer maps) or dialer profiles.

  • Verify that the backup link with normal DDR is functioning correctly.

  • Configure the router to initiate the backup DDR connection when the primary link fails.

• Verification:

  • Verify that the backup router does indeed dial the backup link when the primary circuit goes down.

  • Verify that the backup link is stable (does not flap).

  • Verify that the backup link is brought down, within a specified timeframe, after the primary link is restored.

• Troubleshoot:

  • Check whether the interesting traffic definition is correct.

  • Check whether the route to the appropriate dial interface is valid (only for backup interface and floating static routes).

  • Remove the backup DDR configuration and check whether the normal DDR connection (using the same circuit that is used in the backup) is properly established.

  • Perform Troubleshooting specific to Backup Interface, Floating Static Routes or Dialer Watch as appropriate.

Each of the above steps is discussed in detail throughout the rest of this document.

Design

Use the following information to design a DDR Backup Scenario:

• Determine the Primary and Backup Link

  When designing a DDR Backup scenario, one must first determine the types of links that one has to work with. For example, the primary link is Frame Relay, and the backup is ISDN BRI. This information should be used to determine which backup method to use.

• Determine the backup method to implement. The choices are Backup Interface, Floating Static Router and Dialer Watch

  Determining the backup method is based mostly on the primary interface type as well as the overall network design (including routing protocols).

  Note: Do not use backup interface to backup a Frame Relay physical interface. However backup interfaces CAN be used to backup Frame Relay subinterfaces.

  Evaluate the backup methods to determine which method is most suitable to your particular situations. Refer to Evaluating Backup Interfaces, Floating Static Routes, and Dialer Watch for DDR Backup for more information.

Configuration

Use the following information for configuring normal DDR:

• Configure the Backup link for normal DDR using either legacy DDR (dialer maps) or dialer profiles.

  Configure the normal DDR connection using the same circuit that is used in the backup and make sure it functions correctly before implementing the backup configuration. This will allow you to verify that the dial method used, the Point-to-Point Protocol (PPP) negotiation, and the authentication are all successful before configuring backup.

  For information on configuring normal DDR refer to:

  Normal DDR Scenario	Document
  ISDN BRI w/Dialer Profiles	Configuring ISDN DDR with Dialer Profiles
  ISDN BRI w/dialer maps	Configuring BRI-to-BRI Dialup with DDR Dialer Maps
  Modem on the AUX Port	Configuring Dialout using a Modem on the AUX Port
  NM-8AM/NM-16AM	Configuring Dialout with the NM-8AM or NM-16AM Analog Modem Module
  Analog Calls (using Digital Modems) with a T1/E1	Configuring a T1 or E1 Interface for Outgoing Analog Calls
  ISDN PRI (T1/E1):	AS5300 Dialing out with ISDN/Async (Outbound DDR)

• Verify that the Backup DDR link is functioning correctly.

  Generate interesting traffic and initiate the normal DDR link. The link should come up and continue to stay up. This will allow you to verify that the dial method used, the Point-to-Point Protocol (PPP) negotiation, and authentication are successful before configuring backup.

• Configure the router to initiate the backup DDR connection when the primary link fails:

  Once you have verified that normal DDR over the backup link is functioning correctly, you can configure the interface to be the backup using one the following methods:

  • Backup Interface

    Configure the command backup interface interface on the primary interface. The interface referenced in the backup interface command should be the interface used for the backup. For example, if a BRI provides backup to a serial link, then the configuration would be similar to the following:

        maui-soho-01(config)#interface Serial 0
        maui-soho-01(config-if)#backup interface bri 0 

    Sample Configurations:

    • Configuring BRI Backup Interface with Dialer Profiles

    • DDR Backup using BRIs and the backup interface Command

    • Async Backup with Dialer Profiles

  • Floating Static Route:

    Configure the floating static route for the backup link: For example,

    ip route 172.16.4.0 255.255.255.0 172.16.3.2 200
    

    The administrative distance of 200, means that the router will not install this route in the routing table if a similar route with a lower administrative distance exists. The primary route (for the same network/mask) should be supplied by a routing protocol or a static route. When the primary link goes down, the router will install the floating static route and the backup link can be activated.

    • Configuring ISDN Backup for Frame Relay

    • Configuring Frame Relay Backup

    • Using Floating Static Routes and Dial-on-Demand Routing

    Note: Though 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

    Create a Dialer Watch List that defines the network to watch. This is done using the command dialer watch-list group-number ip ip-address address-mask . This exact route (including subnet mask) must already exist in the routing table. For example,

    dialer watch-list 8 ip 172.22.53.0 255.255.255.0
    

    Enable dialer watch on the backup interface using the command dialer watch-group group-number (where group-number must match that configured using the dialer watch-list command)

    Sample Configurations:

    • Configuring DDR Backup using BRIs and Dialer Watch

    • Configuring AUX-to-AUX Port Async Backup with Dialer Watch

    • Configuring Dial Backup Using Dialer Watch

Verification

Perform the following steps to verify that the DDR Backup connection is functioning correctly. If any of the conditions are not satisfied proceed to the troubleshooting section in this document

• Verify that the backup router does dial the backup link

  With a backup interface implementation, this will involve physically bringing down the primary interface by unplugging cables or something similar. For Floating Static Routes and Dialer Watch, removing the route is necessity to activate the backup link.

• Verify that the backup link is stable (does not flap)

  We must verify that the backup link is stable once it comes up.

• Verify that the backup link is brought down when the primary link is restored

  Verify that:

  • The router recognizes that the primary link is up.

  • The router disconnects the backup link after the primary link has been up the desired timeframe.

Troubleshooting Scenarios

Use the Troubleshooting Procedure specific to the DDR backup method you have employed

Troubleshooting Backup Interface

Problem: The Backup link is not dialed when the primary link goes down.

• Possible Solution 1: Check that when the primary link goes down, the interface on which the backup interface command is configured goes down as well. For example, if the primary interface is interface Serial 0, then the line protocol for that interface must go down for the backup interface to be brought out of standby. Since the backup interface method relies on the interface it is configured on to be in a down state before the backup interface actually comes up, we must verify that a primary link failure is actually reflected in the state of the interface. You can determine the state of the interface using the command show interface interface slot/port . If you observe that the primary link line protocol does not go down during a failure, then you can select one of the following solutions:

  • Choose another interface that does go down when the primary dies

  • Use either floating static routes or dialer watch for backup.

• Possible solutions 2: Check to see if the router generated a console message indicating that the backup interface changed out of standby mode. This message will only appear after the enable-timer, specified by the backup delay enable-timer disable-timer command, has expired. If you do not see this console message, adjust the backup delay enable timer to a lower value. Refer to the document Dial Backup for Serial Lines Commands for more information. An example of a 10 second delay timer is shown:

  *Mar  1 03:37:31.788: %LINEPROTO-5-UPDOWN: 
  Line protocol on Interface Serial0, changed state to down
  
  !-- The primary interface goes down.
  
  *Mar  1 03:37:42.719: %LINK-3-UPDOWN: Interface Dialer1, 
  changed state to up
  
  !-- The backup interface is brought out of standby mode !-- approximately ten seconds later.
  
  

• Possible solutions 3: Verify the routing table contains a valid route to the backup interface to be dialed. If there is no route, select one of the following:

  • For Dialer Profiles, create a route such as a floating default route pointing to the backup interface.

  • For Dialer Maps, create a route such as a floating default route pointing to the ip address specified in the dialer map statement.

• Possible solution 4: Check that the interesting traffic definition is correctly defined and is applied to the interface providing the backup. For example, if you want the routing protocol periodic updates/hellos to trigger the backup link, then verify that the routing protocol is defined as interesting.

  The interesting traffic definition is specified with a dialer-list command and this list is applied to the backup interface using the command dialer-group. For example:

  maui-soho-04#configure terminal
  Enter configuration commands, one per line.  End with CNTL/Z.
  maui-soho-04(config)#dialer-list 1 protocol ip permit
  
  ! --- All IP traffic is marked interesting.
  
  maui-soho-04(config)#interface bri 0
  maui-soho-04(config-if)#dialer-group 1
  
  !--- Apply interesting traffic definition !--- (for BRI 0) from dialer-list 1.
  
  

• Possible Solution 5: Verify that the DDR configuration is correct. Remove the backup configuration, and ensure that the routers can connect successfully using normal DDR. Refer to Dialup Technology: Troubleshooting Techniques for further assistance.

Problem: The Backup link dials but does not connect to the other side.

• Possible Solution 1: Since the router dials the backup link, but fails to connect, then it is no longer a DDR backup issue and you should refer to Dialup Technology: Troubleshooting Techniques for further assistance.

Problem: The backup link is not deactivated when the primary link recovers.

• Possible Solution 1: Check that when the primary link recovers, the interface (on which the backup interface command is configured) comes up as well. This is necessary since the router will not recognize that the primary link is up until the line protocol of that interface is up. For example, if the primary interface is interface Serial 0, then the line protocol for that interface must come up for the backup interface to change into standby. You can determine the state of the interface using the command show interface interface slot/port .

• Possible Solution 2: Verify that the disable timer is set appropriately. The disable timer is specified with the command backup delay enable-timer disable-timer . For example, the command backup delay 10 60 indicates that the backup link will be enabled 10 seconds after the primary link goes down, and that the backup link will be brought down 60 seconds after the primary link recovers. If your backup link stays up longer than desired, adjust the disable time downwards.

Problem: The backup link is not stable (for example, it flaps). This is usually caused by an unstable primary link, since the router brings the backup link up and down for every primary link flap.

• Possible Solution 1: Verify that the backup delay timer values are appropriate. If the primary link is unstable, raising the disable timer allows the router to keep the backup link up longer until the primary link is found to be up and stable for the specified amount of time.

• Possible Solution 2: Verify that the physical interface and circuit are functioning. Refer to Dialup Technology: Troubleshooting Techniques for further assistance.

Troubleshooting Floating Static Routes

Problem: The Backup link is not dialed when the primary link goes down.

• Possible Solution 1: Use the show ip route command to verify that the floating static route exists in the routing table after the primary link goes down. Remember that the floating static route will only be installed in the routing table after all other identical routes, with lower administrative distance are removed. Hence, check to make sure that there are no other sources for the primary route (possibly due to a routing loop).

• Possible Solution 2: Check that the interesting traffic definition is correctly defined (using the dialer-list command ) and is applied to the interface (using the dialer-group command) providing the backup. Generate interesting traffic, then use the command debug dialer packet to verify the traffic is designated interesting and can bring up the link.

  Note: The routing protocol should not be defined as interesting. This prevents the periodic updates or hellos from keeping the backup link up indefinitely. The following is an example of a good interesting traffic definition for this backup method:

  maui-soho-04(config)#dialer-list 1 protocol ip list 101
  
  ! --- Use access-list 101 for the interesting traffic definition.
  
  maui-soho-04(config)#access-list 101 deny ospf any any
  
  ! --- Mark the Routing Protocol (in this case, OSPF) as NOT interesting.
  
  maui-soho-04(config)#access-list 101 permit ip any any
  
  ! --- All other IP traffic is designated interesting.
  
  maui-soho-04(config)#interface bri 0
  maui-soho-04(config-if)#dialer-group 1
  
  !--- apply interesting traffic definition (for BRI 0) from dialer-list 1.
  
  

  Keep in mind that due to this restriction, backups using floating static routes cannot be activated using routing protocol traffic. The router must receive other interesting user traffic to bring up the backup interface. Possible Solution #3: Verify that the DDR configuration is correct. Remove the backup configuration, and ensure that the routers can connect successfully using normal DDR. Refer to Dialup Technology: Troubleshooting Techniques for further assistance.

• Possible Solution 3: Verify that the DDR configuration is correct. Remove the backup configuration, and ensure that the routers can connect successfully using normal DDR. Refer to Dialup Technology: Troubleshooting Techniques for further assistance.

Problem: The Backup link dials but does not connect to the other side.

• Possible Solution 1: Since the router dials the backup link, but fails to connect, then it is no longer a DDR backup issue and you should refer to Dialup Technology: Troubleshooting Techniques for further assistance.

Problem: The backup link is not deactivated when the primary link recovers.

• Possible Solution 1: Use show ip route to verify that the routing protocol reinstalls the primary route. This should cause the floating static route to be removed from the routing table. All traffic should now use the primary link. If the primary route is not reinstalled, troubleshoot the routing protocol.

• Possible Solution 2: Use debug dialer to verify that there is no interesting traffic that passes on the backup link. Since interesting traffic resets the idle timeout, the link will not be brought down if there is unwanted interesting traffic. Keep an eye out for certain broadcast and multicast packets that can reset the idle time-out. If necessary, modify the interesting traffic definition to be more restrictive and designate such rogue packets as not interesting.

• Possible Solution 3: Lower the dialer idle-timeout (default is 120 seconds). Keep in mind that the backup link is only brought down when the idle time-out expires. Hence a lower idle timeout can hasten bringing down the backup link; provided there are no rogue interesting packets that can reset the timeout, (which was described in Solution #2 above)

Problem: The backup link is not stable (for example, it flaps) when the primary interface is down:

• Possible Solution 1: Change the interesting traffic to be less restrictive. This will provide a better chance that the idle timeout will be reset, and thus keeping the line up. However be sure to verify that any changes will not cause the backup link to stay up indefinitely (described in the previous problem).

• Possible Solution 2: Raise the dialer idle-timeout so that the backup link will not be brought down often. However, be sure to verify that any changes will not cause the backup link to stay up indefinitely (as described in the previous problem).

• Possible Solution 3: Verify that the physical interface and circuit are functioning. Refer to Dialup Technology: Troubleshooting Techniques for further assistance

Troubleshooting Dialer Watch

Configure and verify that the DDR connection is working properly before you configure dialer watch. This will help you to isolate and troubleshoot DDR issues before you tackle backup related problems. When configuring Dialer Watch it is recommenced that you use Cisco IOS® Software Release 12.1(7) or higher.

The following section discusses several problems and possible solutions:

Problem: The router does not dial the backup link when the primary link goes down.

• Possible Solution 1: Use the show ip route command to verify that the route you are watching exists in the routing table. The route configured for dialer watch must exactly match the one in the routing table. This includes verifying that the network as well as the masks are identical. For example, if the routing table shows 10.0.0.0/8 and you use dialer watch-list 1 ip 10.0.0.0 255.255.255.0 (which is 10.0.0.0/24), the dialer watch feature will not be able to detect that 10.0.0.0/8 is no longer in the routing table.

• Possible Solution 2: Verify there are two dialer map statements on the backup interface.

  • There should be one map statement for the route/network specified by the dialer watch-list command

  • There should be one map statement for the IP address of the remote router's interface.

• Possible Solution 3: Configure the command dialer watch-list group-number delay route-check initial seconds . Refer to for more information.

Problem: The backup link is established but no routing information is transmitted across the backup link.

• Possible Solution: Verify that the backup interface IP network is included in the routing protocol configuration

Problem: The backup link is not deactivated when the primary link recovers.

Note: With dialer watch, interesting traffic is only used to control the idle-timeout which in turn controls the interval used to poll the status of the primary route.

• Possible Solution 1: Lower the dialer idle-timeout. The default is 120 seconds, but you may wish to lower this value depending on your needs.

• Possible Solution 2: Use the show dialer command to verify the idle timeout is not being reset.

  Change your interesting traffic definition (configured with the dialer-list command) to be more restrictive. Routing Protocol traffic should be marked uninteresting.

  As a last resort, you can configure all IP traffic as uninteresting using the command dialer-list 1 protocol ip deny. With this interesting traffic definition, the idle timeout will never be reset, and the router will check the status of the primary link at the specified interval.

• Possible Solution 3: Check to make sure that the backup link is less desirable than the primary link from the perspective of the routing protocol in use. This is so that when the primary link recovers, the dynamic routing protocol will prefer the primary over the backup link and not load balance across the two links. Failure to do this can cause the backup link to stay up persistently. Use show ip route to determine if the router is using both the primary and backup links to route traffic between the routers. In such a case the router will keep identical duplicate routes; one for the primary and one for the backup link

  You can use the any of the following methods to ensure that the backup link is less desirable from the perspective of the routing protocol: bandwidth, delay, or distance. Refer to the Cisco IOS software Command Reference for more details.

Related Information

• Technical Support - Cisco Systems