Dial-on-Demand Routing

Peter J. Welcher

This month we'll discuss Dial-on-Demand Routing (DDR), a hot topic. DDR can be overwhelming at first, due to all the choices. Cisco has made this a powerful and flexible tool that can be used in a wide variety of ways. We'll focus here on the big picture.

DDR involves using the switched phone system to establish connectivity. Asynchronous modems can be used for DDR on the AUX port of the router. Synchronous modems or ISDN TA's can be used on serial ports. And integrated ISDN (BRI, MBRI, or PRI) ports can perform DDR.

DDR is usually used for low volume, periodic traffic. Low volume, so that a dial-up or ISDN connection suffices. Periodic, so that most of the time the connection can be down.

DDR is also used for dial backup. When a leased line or Frame Relay interface line fails or becomes saturated, a phone call replaces it or adds capacity.

DDR can also be used with dial-up access to X.25 or Frame Relay.

The Main Steps

The main steps in creating a DDR configuration are: Setup, Where, How, and When.

Setup: set up the interface to perform DDR.
Where: where to send the packets?
How: how do they get there?
When: when should the router connect? (What traffic is interesting?)

We'll look at each of these below.

Setup

Setup can be as simple as the following:

interface serial 0 
ip address 1.2.3.4 255.255.255.0 
dialer in-band

This associates an IP address with the interface and indicates that other routers will be connecting up via DDR. On a router that would be calling another, you might add more interface commands like:

dialer idle-timeout 600

This specifies a 10-minute wait (idle time) with no "interesting" traffic before hanging up the connection (see When, below).

With ISDN, setup might also include commands like:

! specify the ISDN switch type:
isdn switch-type basic-dms100
! this service provider requires 2 SPID's,
! one for each B channel
interface bri 0
isdn spid1 412555121201 5551212
isdn spid2 412555121302 5551213

Router interfaces connected by DDR are assigned IP addresses in the same subnet, just as if there was a permanent leased line between them.

This by no means is all that there is to say about Setup, but if you think in terms of Setup, of having to clue the router in on what's going on, then you can dig the details out of UniverCD.

Where

The next issue is where the router is supposed to send packets to. The point is, you have to think about routing information, since there are usually no dynamic routing updates when the phone link is down.

One possibility is to use static routing. The static route indicates a default route via 144.254.50.1.

ip route 144.254.0.0 255.255.0.0 144.254.50.1

When a packet arrives at the DDR router, if its destination is not in the routing table, the router will forward it to 144.254.50.1, which is the address of the router across the DDR link.

If we're doing static routing, we probably are NOT dynamically routing across the DDR link, even when it is up. The above might be suitable for a small branch office, where if an address is not a local LAN, it must be at the main office.

Another possibility follows. This might be a main office. We give it a static route for each branch office, we turn on dynamic routing, and we redistribute the static routes. Redistribution of static routes saves having to put similar static routes on all our other main office routers. The passive-interface keeps the IGRP updates off the DDR link. (We use bri 0 to illustrate how it might look for ISDN).

! static route to branch office:
ip route 144.254.55.0 255.255.255.0 144.254.50.1
! dynamic routing for main office:
router igrp 100
network 144.254.0.0 
passive-interface bri 0 
! advertise the branch office:
redistribute static
default-metric 56 2000 255 1 1500

A third useful approach is Cisco's snapshot routing. Think of it as dynamic static routing, or if you prefer, lazy-person's static routing. It's like static routing information where the router goes out and gets the information for itself. The information gets infrequently refreshed, either via a separate phone call or when the link is up.

How

Routing tells the router what interface to send packets out, and what the address of the next hop is. With DDR, the router then needs to know how to contact that next hop router. So it needs the appropriate phone number.

If there's only one phone number, you can specify it as above with the dialer string command:

interface serial 0
dialer string 5551212

When there's more than one next hop router, the router needs a phone book:

interface serial 0
dialer map IP 144.254.50.1 name nextHopper 5551212

This says that the IP address 144.254.50.1 is reached at phone number 5551212. The name part is optional. The word broadcast may be added to the dialer map, if IP broadcasts need to cause dialing.

There are some other How issues. One is how dialing occurs. Default is v.25bis dialing, as above, on synchronous serial ports (chat scripts on the AUX port). Use the interface command

dialer in-band [odd-parity | no-parity]

to specify DDR with v.25bis dialing (and parity if needed).

The router can instead raise DTR to trigger an autodial modem to dial. This is configured with the interface command:

dialer dtr

A third alternative is to use a chat script, typically with a Hayes-compatible modem. The name of the chat script is specified in the dialer map statement.

ISDN BRI and PRI interfaces of course use ISDN dialing.

When

What traffic is interesting?

Some people want any traffic to cause the phone link to be brought up. That's fairly simple. It's also one approach to dial backup.

Most people want to only place a call when there is traffic to be transmitted. That's because toll calls and ISDN are usually billed based on usage, so it costs to leave the connection up.

However, there are lots of things happening on a network that aren't worth a phone call. For instance, routing updates. If you're running IP RIP, do you want to place a call every 30 seconds? Probably not.

So we need to help the router out, by telling it what traffic is worth a phone call. We do this with an access list (see below). When the router needs to forward an "interesting" packet out the DDR interface, it places the call. The call goes through (we hope), and traffic flows. If we want to block some of the "uninteresting" traffic, we need to do so separately. When the link is up, all traffic may be transmitted across it. The router resets an idle timer every time an interesting packet is sent, and when there are no interesting packets for a while, the idle timer causes the phone call to be ended.

The following is an ISDN configuration that ties BRI interface 0 to dialer-group 1. The dialer group 1 in turn specifies what traffic is interesting, namely all IP traffic and IPX traffic matching the "permit" clauses of access list 901, an extended IPX access list. This is not intended to be realistic, just to illustrate the possibilities. We've omitted the access list for brevity.

! access-list saying RIP, SAP, serialization
! are not interesting:
access-list 901 deny 0 -1 452
access-list 901 deny 0 -1 453
access-list 901 deny 0 -1 457
access-list 901 deny 0 -1 0 -1 452
access-list 901 deny 0 -1 0 -1 453
access-list 901 deny 0 -1 0 -1 457
access-list 901 permit -1
! specify interesting traffic:
dialer-list 1 protocol ip permit
dialer-list 1 protocol list 901
! tie this to the BRI 0 interface:
interface bri 0
dialer-group 1

Nasties

To make full use of DDR, you have to think about the following "nasties":

Routing updates
Ping or SNMP management traffic
NTP (Network Time Protocol)
Novell RIP and SAP (sockets 452, 453)
Novell serialization packets (socket 457)
Novell watchdog packets (IPX, SPX)
Novell NDS and Time synchronization
Appletalk chatty protocols

You may need an access list to deny that these are interesting. You may also want to prevent them from consuming bandwidth, blocking the packets from transmission across the DDR link.