Section 12.2. Sample Legacy DDR Configurations

12.2.1. DDR Backup Links

Dial-on-demand is frequently used to provide a backup link for a permanent connection. There are two methods for dial backup: backup interface commands and floating static routes. Backup interface commands are relatively easy to configure, can provide bandwidth on demand, and stay idle until brought online. On the other hand, they are dependent on encapsulation, and they provide only one backup interface per "permanent" interface.

A floating static route is simply a static route whose administrative distance has been raised so that it is less desirable than the primary route. We covered backup static routes and administrative distances in Chapter 8, so this should be familiar. Floating static routes are convenient if you require multiple backup interfaces or backup routes that are encapsulation-independent. But floating static routes are somewhat difficult to configure, require the use of a routing protocol, and require that the "interesting traffic" access list actually cause the backup interface to be dialed .

First let's look at the backup interface commands and what they can do for us. Then we will revisit the example using a floating static route.

12.2.1.1. Backup interface commands

In this example, the ISDN interface bri0 is defined as a backup to our serial link. If the serial link goes down, the bri0 interface is dialed and the connection is made. Once the serial link has been restored for a period of time, the bri0 link is disconnected. The first number in the backup delay command tells the router to wait 5 seconds before bringing the bri0 interface up after serial1 goes down; the second number tells the router to wait 30 seconds after serial1 comes back online before switching back. These delay values try to ensure that the serial1 link is really up or down before switching over to the backup interface.

interface serial1
      description T1 to Baltimore
      ip address 10.10.2.1 255.255.255.0
      ! The backup for this link is bri0. When serial1 goes down, bri0 comes up
      backup interface bri0
      ! Set delay values. Wait 5 seconds before bringing bri0 up
      ! and wait 30 seconds after serial1 comes back up before switching back
      backup delay 5 30
    !
    interface bri0
      ip address 10.10.3.1 255.255.255.0
      encapsulation ppp
      dialer map ip 10.10.3.2 name baltimore-rtr broadcast 4105552323
      dialer-group 1
    !
    isdn switch-type basic-5ess
    username baltimore-rtr password hello123
    !
    ! Configure the dialer list
    dialer-list 1 protocol ip permit

12.2.1.2. DDR bandwidth on demand with backup interface commands

In the previous example, bri0 acts as a backup for serial1 . However, the ISDN link is used only as a backup. In this example, we'll take things a bit farther and use bri0 to provide some additional bandwidth, helping out serial1 during periods of congestion. In particular, we will bring up bri0 when the load on serial1 is greater than 70%, using the backup load command. When the load on serial1 drops back to 15%, we drop the bri0 link.

This configuration does not use an explicit access list to specify what traffic is interesting. Instead, it uses a variant of the dialer list command that incorporates a simple access list saying "Any IP traffic is permitted." If your requirements are simple, this approach is often clearer and more straightforward than using a separate access list.

interface serial1
      description T1 to Baltimore
      ip address 10.10.2.1 255.255.255.0
      ! Set the backup interface to bri0
      backup interface bri0
      ! Use bri0 when load hits 70, take offline when load drops back to 15
      backup load 70 15
    !
    interface bri0
      ip address 10.10.3.1 255.255.255.0
      encapsulation ppp
      dialer map ip 10.10.3.2 name baltimore-rtr broadcast 4105552323
      dialer-group 1
    !
    isdn switch-type basic-5ess
    username baltimore-rtr password hello123
    !
    ! Configure the dialer list for dialer-group 1
    dialer-list 1 protocol ip permit

12.2.1.3. DDR backup with floating static routes

It's easy to write our backup interface example using a floating static route. In order for this example to work properly, we also need to configure a routing protocolin this case, we'll use EIGRP. So, to get our floating static route to work, we need to set the administrative distance for the static route higher than EIGRP's distance. The default administrative distance for EIGRP routes is 170 (for external routes), so we'll use a distance of 200 for our backup route. The rest is straightforward.

! Almost the same serial configuration as before except no backup commands.
    interface serial1
      description T1 to Baltimore
      ip address 10.10.2.1 255.255.255.0
      ! We are going to tweak EIGRP so our backup dialer link comes online faster
      ! the 100 is our EIGRP AS number
      ip hello-interval eigrp 100 3
      ip hold-time eigrp 100 10
    !
    interface bri0
      ip address 10.10.3.1 255.255.255.0
      encapsulation ppp
      dialer map ip 10.10.3.2 name baltimore-rtr broadcast 4105552323
      dialer-group 1
    !
    isdn switch-type basic-5ess
    username baltimore-rtr password hello123
    !
    ! Configure EIGRP
    router eigrp 100
      network 10.0.0.0
    !
    ! Configure our floating/backup static route, setting the administrative
    ! distance to 200
    ip route 10.10.5.0 255.255.255.0 10.10.3.2 200
    !
    ! Configure the dialer list; this time use an access list to block
    ! EIGRP traffic from bringing up our link
    dialer-list 1 protocol ip list 101
    !
    ! Finally, our access list. This list blocks EIGRP and permits everything else.
    ! REMEMBER: This list is used only to identify interesting traffic. It
    ! does nothing to block traffic once the link is established.
    access-list 101 deny eigrp any any
    access-list 101 permit ip any any

12.2.2. Dialer Maps

Dialer maps allow IP addresses to be mapped directly to phone numbers and dialer scripts. With this feature, one interface can be configured to dial several different sites, or to dial the same site using different phone numbers , based on the IP address.

12.2.2.1. The most basic form of this command

In the following example, we use the dialer map command to configure the two B channels of an ISDN interface bri0 :

interface bri0
      ip address 10.10.3.1 255.255.255.0
      encapsulation ppp
      dialer map ip 10.10.3.2 name ROUTER1 broadcast 4105552323
      dialer map ip 10.10.3.4 name ROUTER2 broadcast 4105552333
      ppp authentication chap
      ppp multilink
      dialer-group 1
    !
    dialer-list 1 protocol ip permit

The dialer map commands map the remote device's IP address, its device name (for authentication), and a dial string (phone number). Optionally, we can also set the speed (56 or 64) and whether or not we want to allow broadcasts. The broadcast keyword says that we will allow broadcasts, such as routing updates. By default, broadcasts aren't allowed.

Dialer maps are the preferred way to configure dialing of a link. They are used throughout this chapter.

12.2.2.2. A more complicated use of dialer maps

In this example, we want to set up a router to communicate with two remote offices through a single serial interface. Office 1's local network is 10.10.2.0/24; Office 2's network is 10.10.4.0/24. To create this configuration, we map the IP address 10.10.1.2 and the phone number 555-1111 to the chat script that dials Office 1; we map 10.10.1.4 and 555-1112 to the chat script for Office 2. To do so, we use two dialer map commands, plus several chat-script commands for setting up the scripts. Both connections are handled by the same interface and the same modem. The static routes set the routes to the proper office network.

In this configuration, it's impossible for both offices to be connected at the same time because we are using a single analog modem. With ISDN, this wouldn't be a problem. BRI interfaces have two B channels, which enable one interface to dial two different locations at once.

Once a connection has been made to either destination, the connection remains up until it has been idle for a certain timeout period. To make this configuration more flexible, we use two different idle timeout periods. The normal timeout, set by the dialer idle-timeout command, is 300 seconds; this timeout is used if there is no traffic waiting for the other office. If there is traffic waiting, the configuration specifies a shorter timeout of 15 seconds, using the dialer fast-idle command.

! Set up the chat script for the modem (we have only one type of modem)
    chat-script usr ABORT ERROR "" "at z" OK "atdt \T" TIMEOUT 20
    !
    ! Set up the login script for office1
    chat-script office1 ABORT invalid TIMEOUT 10 name: frank word: letmein ">"
    !
    ! Set up the login script for office2
    chat-script office2 ABORT invalid TIMEOUT 10 name: saul word: letme ">"
    !
    interface async 3
      description DDR connection to remote offices
      ip address 10.10.1.1 255.255.255.0
      dialer in-band
      ! Create the map for this interface to office1
      dialer map ip 10.10.1.2 modem-script usr system-script office1 555-1111
      ! Create the map for this interface to office2
      dialer map ip 10.10.1.4 modem-script usr system-script office2 555-1112
       ! Set the idle timeouts
      dialer idle-timeout 300
      dialer fast-idle 15
      dialer-group 1
    !
    ! Set a static route to office1
    ip route 10.10.2.0 255.255.255.0 10.10.1.2
    ! Set a static route to office2
    ip route 10.10.4.0 255.255.255.0 10.10.1.4
    !
    ! Set up the dialer groups
    access-list 110 deny icmp any any
    access-list 110 permit ip any any
    dialer-list 1 protocol ip list 110

We've made one additional improvement to our earlier configurations: we added a deny rule that blocks ICMP traffic to access list 110. Since this rule is used in a dialer list, it prevents a ping from bringing up the connection. We don't want the line to be dialed every time someone pings the remote site. However, we don't actually block pings : this access list isn't applied to the traffic going into or out of an interface. If the line is up, the ping will succeed.

This configuration assumes that a routing protocol is not in use. A routing protocol would bring up the links each time it sends routing updates to adjacent routers, and this is almost certainly undesirable. If you do use a routing protocol in a configuration like this one, make the DDR interface a passive interface. In the following statements, we start a RIP routing process and specify that the interface async3 is passive:

router rip
      network 10.0.0.0
      passive-interface async3