Configuring a Simple DDR Connection

Let's start by configuring a simple dial-up connection to a remote office. The connection will be made only if there is "interesting" traffic for the network at the remote office. For the connection, we'll use an async interface with an analog modem attached to it.

First, we need to define the dialer script (also called a chat script) for the modem. Chat scripts define the process by which the router communicates with the modem and logs into the remote site. The script is organized as a sequence of "expect" and "send" strings, that is, strings the router expects to receive and strings the router sends. For example, here's a simple script that dials the number (410) 555-1111 and waits for a connection:

chat-script usr-modem "" "atdt 4105551111" TIMEOUT 60 "CONNECT"

After the chat-script command, we have the name usr-modem, which identifies the script in other parts of the configuration. Then we start the expect-send pairs. First, we expect nothing ("") and send the familiar modem dialing command, atdt 4105551111. We specify a 60-second timeout, during which we expect to receive the string CONNECT. The default timeout is 5 seconds.

Next, we'll start configuring the interface. We set up PPP as the encapsulation mode, and specify the authentication procedure (in this case, CHAP) and the username and password to be used for authentication to the remote office. And of course, we need to specify an IP address for this end of the connection. (There are alternatives to providing an explicit IP addresswe'll see them later.)

! Set up username and password for CHAP authentication on remote router username office1 password letmein ! ! Async interface interface async 1 description DDR link to the remote office encapsulation ppp ppp authentication chap ip address 10.10.3.1 255.255.255.0

Now back to setting up DDR. We need to enable DDR on the interface by using the dialer in-band command. (This command is not required for BRI interfaces because they are automatically set for dialing.) We specify that the connection should hang up if there is no traffic for 300 seconds (5 minutes). Next, we specify a dialer group. The dialer group corresponds to a dialer list, which in turn points us to an access list that defines the traffic for which the router will establish the connection:

! Enable DDR for this interface dialer in-band ! Extend the idle period to 5 minutes dialer idle-timeout 300 ! This next command specifies that this interface is part of dialer group 2, ! which is defined below with the dialer-list command dialer-group 2 ! Select the correct chat script dialer map ip 10.10.3.2 modem-script usr-modem

Now we need to tell the router when to dial the link by providing a dialer list. The dialer list defines the traffic that we consider interesting. In this case, we use an extended IP access list to state that we're interested in any traffic using the IP protocol. (A dialer list can also specify the allowed protocols directly, without using an access list.) In the following commands, we define dialer list 2, which matches the previous dialer-group command. The dialer list points to access list 101:

! Define a dialer list for dialer group 2 dialer-list 2 list 101 access-list 101 permit ip any any

Access list 101 permits all IP traffic; in this context, it means that IP traffic will cause the router to dial. After the link is established, this access list does nothing to block any traffic traversing the link; it merely controls when the link is dialed.

Finally, we need to create routes to send traffic to the remote office:

! Define a static route for the remote-office IP addresses ip route 10.10.4.0 255.255.255.0 10.10.3.2 ip route 10.10.5.0 255.255.255.0 10.10.3.2

Without the static routes, the router would never know the address space of the remote office because no routing protocol can run across a link that is down. With these routes, any traffic bound for the 10.10.4.0 or 10.10.5.0 subnets is routed via the async1 interface. If the interface is down, the connection is automatically dialed. If the connection is idle for more than 300 seconds, the link is disconnected. This example is fairly simple; in most cases the access list needs to be more restrictive to stop unwanted traffic or routing updates from causing our link to come up. Remember that the access list should describe only "interesting" traffic, and most sites using dial-on-demand routing should not consider routing updates interestingif for no other reason than that routing updates will tend to keep the link up all the time.