Dial on Demand Routing

When a router detects the need to initiate a dial-up connection to a

remote network, it does so automatically according to pre-defined
parameters set by the network manager.
The objective of Dial-on-Demand is to automatically initiate a DialUp Networking connection when the Autodial Manager detects that
access to a network resource has been requested.
If you have a LAN connection as well as a Dial-Up Networking
connection, then the auto-dial Manager may behave in an
unpredictable way, particularly if some network resources can be accessed both via the LAN and
via Dial-Up Networking.
Short for Dial-on-Demand Routing, DDR is a routing technique that allows a user to utilize
existing telephone lines or public circuit-switched networks to form a WAN instead of lines that
are dedicated specifically to the WAN. DDR is typically implemented by users that do not need
permanent, continuous links between sites on the WAN, because the volume of traffic over the
WAN is low and the transmissions are periodic as opposed to continuous. The connection only
becomes active when data is sent to the remote site. When no data has been sent over the link
for a specified amount of time, the link is disconnected.
Using DDR, a connection between sites is only established when a specific type of traffic initiates
the call or when you a back-up link is needed for redundancy or load sharing.
DDR is used in order to save on the costs of a dedicated WAN line for organizations that do not
need permanent continuous connection and as a back-up for organizations that use the
dedicated line for critical applications.

Dial-on-demand routing also has a long history of usage in routed networks. Dial-on-demand
routing is designed to provide cost-effective connectivity in dial-up environments where the goal
is to minimize the time spent with the line engaged. Filters are used to define "interesting
traffic." Calls are connected when the dial link is determined to be the best route to the
destination for the interesting traffic and dropped when no interesting traffic has used the dial
link for a specified period.
The challenge is that, back-up interface only works when a link failure is detected at the link
level. Meanwhile, dial-on-demand routing only works when interesting traffic is present. If
traffic suitable for forcing the link up cannot be guaranteed, the link may not be up when
needed. At the same time, care must be taken to ensure that the dial-up link will only be the
best path for interesting traffic when the primary link is down. Otherwise, the back-up link will
be kept up unnecessarily, wasting money and potentially preventing its use for backing up a link
that does need support.
With a little extra effort, dial-on-demand routing can be used to provide most of the dialer
watch functionality using any vendor's routers or any supported IOS release routers. The trick is
to use floating static routes to trigger dial-on-demand routing to bring up the back-up link. This
makes the implementation a little more complex, but benefits from using only proven, welldebugged capabilities.
Typical of most network decisions, which dial back-up methodology use to implement link backup, is not always a clear choice. Each approach has advantages and disadvantages and whether a
particular feature is an advantage or a disadvantage depends on the application. Some of the
more critical tradeoffs include speed of response to failure, reliability of response to failure, call
stability, testability, link performance and ease of implementation.

Speed of Response to Failure : When properly configured, all three approaches respond
immediately to a hard failure of the primary link. A soft failure triggers dialer watch or
dial-on-demand routing as soon as the loss of connectivity is detected by the routing
protocol running over the link.
Reliability of Response to Failure : Back-up interface commands only respond to a link
problem that the router can detect as a physical or link layer down on the interface. Any
event that can trigger the back-up interface commands will also immediately remove the
associated destinations from the routing tables so that dialer watch or dial-on-demand
will also respond correctly. Conversely, failures inside the WAN that are not reported by
the physical or link layer protocols will not trigger back-up interface, but when detected
by the routing protocol, will cause dialer watch or dial-on-demand routing to bring up
the back-up link. It is to be noted that none of the three will protect against the
situation in which the primary link is good enough to support the exchange of routing
protocol packets, but not good enough to support production traffic.
Call Stability: Back-up interface merely removes the dial link from standby state; it's up
to the designer to ensure that the call will be dialed and redialed as required. Dial-ondemand routing requires interesting traffic to force dialing and keep the link up, so if
there is insufficient traffic the link may drop when it should be up. On the other hand,
dial-on-demand routing allows taking advantage of the cost savings possible by only
activating the dial link when traffic actually requires it.
Testability : Testing the dial back-up link when using back-up interface can require
going into configuration mode on the remote router, removing the back-up interface
command from the running configuration, verifying that the dial link comes up correctly,
and then restoring all back-up interface commands defined on the interface. This is not
only a cumbersome procedure, but also a risky one from the viewpoint of security, as it
requires the ability to reconfigure the router; only the integrity of the operator prevents
adjusting other parameters. Testing back-up interface by taking down the primary link

and waiting for dial back-up to restore communications, while effective, disrupts
production traffic.
Link Performance: Back-up interface has the advantage that the dial back-up line can
be used not only for back-up, but also for bandwidth augmentation. The ability to use an
ISDN line for additional bandwidth on demand is lost when using dialer watch or dial-ondemand routing. On the other hand, when using dialer watch or dial-on-demand routing,
it's easier to use the same line to back up multiple primary links.
Ease of Implementation: Back-up interface is trivial to implement, making it the choice
where skills are not available to develop a complex configuration that works reliably. At
the same time, its simplicity can mask the fact that the implementation is not fully
functional.

Dax Product Offering:

Some of the Dax products that support Dial-on-Demand routing are as under:
DXMP-801:
https://www.daxnetworks.com/Dax/Products/router_asp/dxmp801.asp
DXMP-1700 :
https://www.daxnetworks.com/Dax/Products/router_asp/dxmp1700.asp
DXMP-2600 E:
https://www.daxnetworks.com/Dax/Products/router_asp/dxmp2600E.asp
DXMP-2691 / DXMP-2692:
https://www.daxnetworks.com/Dax/Products/router_asp/dxmp2690.asp
DXMP-3600 Series:
https://www.daxnetworks.com/Dax/Products/router_asp/dxmp3600.asp
Dax Eicon Diva ISDN Router :
https://www.eicon.com/worldwide/products/dsl/divalan.htm

For complete Dax Product information, please visit: https://www.daxnetworks.com/PFF.htm

If you have been forwarded this e-mail and wish to recommend this Newsletter, please click here.
To unsubscribe to this Newsletter, please click here.

www.daxnetworks.com
2003 Dax Networks. All rights reserved.