Dial-on-demand routing (DDR) is a feature available on ISDN-capable Cisco routers. It was created to
enable users to save money on usage-based ISDN. Use-based ISDN occurs when charges are assessed for
every minute of ISDN circuit connect time. In such environments, the connection should be down during no
or low-volume traffic times. DDR provides that capability and offers a wide array of commands and
configuration variations. The configuration tasks for implementing basic DDR are as follows:
• The telephone company provides the type of switch to which you are connecting. Manufacturers of
ISDN central office switches, or local exchange equipment, divide the local exchange into two functions:
local termination and exchange termination. The local termination function primarily deals with the
transmission facility and termination of the local loop. The exchange termination function deals with the
switching portion of the local exchange. To function, the switch type must be specified on the router.
You can use the isdn switch-type command to configure the router for the type of switch to which the
router connects. Your telephone company will inform you about the type of switch that your router will
connect to.
• The configuration of DDR depends on how the traffic types that cause a call setup to occur are triggered.
This traffic is known as interesting traffic. Cisco's implementation of DDR allows for as much or as
little specificity of interesting traffic as is deemed necessary; interesting traffic is defined by the creation
of dialer-lists that can specify that an entire protocol suite, no matter the level of traffic, can trigger a
call setup. Dialer-lists can be associated with standard or extended access lists to be specific to various
traffic types. Rather than associating an access list with an interface, it is associated with a dialer-list. To
define specific traffic types as interesting traffic, you should use access lists. Any type of access list can
be implemented in defining interesting traffic.
• In the DDR model, dynamic routing protocol updates do not move across the link, so it is important that
static routes be used in place of dynamic updates. To provide bi-directional reachability between the two
sites in the absence of routing protocol traffic, static routes should be configured at both the local and
remote routers. Any IP traffic that needs to cross the link should be defined as interesting and will trigger
a call setup. Once a call has been established, any type of traffic that has been configured on the BRI
interface traverses the link freely, including routing updates. If the IP network on which the BRI
interface exists is included in the routing protocol configuration and the BRI interface is not specified as
passive, routing updates can flow across the link while it is active. Once static routes have been specified,
it is important to make the BRI interfaces passive.
• ISDN installations are capable of employing HDLC or PPP encapsulation. PPP is most often used. It
offers the use of a single B channel or the combination of the two B channels in a single aggregate pipe.
It enables you to decide when a connection should be dialed, when an additional channel should be
brought up and used, when to disconnect the call, and other options that are discussed in the next couple
of sections. To establish communications over an ISDN link, each end of the PPP link must first send
Link Control Protocol (LCP) packets to configure and test the data link. After the link has been
established and optional facilities have been negotiated as needed, PPP must send Network Control
Protocol (NCP) packets to choose and configure one or more network-layer protocols. Once each of the
chosen network layer protocols has been configured, datagrams from each network layer protocol can be
sent over the link. The link remains configured for communications until explicit LCP or NCP packets
close the link down, or until some external event occurs. Functionally, PPP is simply a pathway opened
for multiple protocols to share simultaneously. The call setup is initiated by interesting traffic as defined
using access lists and terminated by an external event, such as manual clearing or idle timer expiration.
Any interesting traffic that traverses the link resets the idle timer; non-interesting traffic does not.
• Once the encapsulation has been decided upon, you must apply a protocol addressing scheme. You can
configure DDR with any routable protocol. Each protocol that must pass across the link must have a
configured address. For IP implementations, you must supply an IP address and subnet mask to the
interface. The protocol addressing scheme should be decided upon well in advance of any deployment of
any networking technology. In IPX implementations, you must apply an IPX network number to the BRI
interface. The host portion of the address is hard-coded in the global configuration or is taken from the
Burned In Address (BIA) of the lowest numbered LAN interface (that is, Ethernet 0). When IPX
routing is enabled and IPX network numbers are configured on interfaces, the IPX RIP and the SAP
protocols are automatically enabled for those interfaces. IPX RIP and SAP are broadcast-based updates
for routing table information and Novell NetWare service propagation, respectively. These broadcasts
are on independent 60-second timers. You might or might not wish for this traffic to go across your
ISDN link. To avoid this traffic, you can simply not include RIP and SAP in your interesting traffic
definitions. This is accomplished by implementing IPX access lists to filter out RIP and SAP. The access
lists are then associated with the dialer list defining interesting traffic. At this point, RIP and SAP go
across the link only as long as the link is up because of the transfer traffic that fits the interesting
parameters. You can also define IPX static routes and static SAP entries.
• The purpose of DDR is to bring down the ISDN link when the traffic volume is low or idle. However, at
times, the traffic volume can simply be in a short lull. To avoid the link coming down when traffic flow
ceases and then being forced to redial, use the dialer idle-timeout command. Executing this
command dictates that when traffic defined as interesting has ceased to flow across the link for the
specified period of time, the link can be brought down.