Page 1

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.

Page 2
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

Page 3
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.

How it works
There are two parts to a establishing a connection with DDR: the physical connection and the digital connection. The physical connection consists of the actual cable that connects computers on the network and the network interface card that allows for communication over these cables. DDR uses existing Public Switched Telephone Network (PSTN) lines or the network of all public circuit-switched telephone networks - to form a connection between the sender and receiver.

The second part of establishing a DDR connection consists establishing the digital signal. This requires one to determine the protocols to be used over the logical connection. DDR uses a Point-to-Point Protocol (PPP) link, which handles all networking functions such as sending, receiving and compressing the signals between two computers on the internet. In other words, the PPP link uses telephone lines to send signals between you and the computer containing your desired website when you wish make a connection to the internet.

DDR can be used both as a primary and as a backup connection. Today, DDR is mainly used for backup connections which go live when the primary connection fails. DDR connections are inherently slow and service fees are charged like phone calls depending on the uptime. DDR can be used with modems or Integrated Services Digital Network (ISDN) connections, which allow it to achieve a maximum connection speed of only 1.544 Mbit/s in the US and 2.048 Mbit/s in Europe and Australia.ref>ISDN PRI. (n.d.). . Retrieved March 2, 2010, from http://www.topbits.com/isdn-pri.html</ref>

[edit] Design Considerations

One important factor to be minimized is the connection establishment delay. This is the time from when the user first attempts to make a connection to when the receiving computer begins to receive information. This delay can range from 3 to over 20 seconds depending on various factors. These include but are not limited to the type of physical cable used in the connection, the distance the data is being sent, and the protocols used to send the information. Knowing the extent of the delay is a very important part of designing an efficient DDR system. If the delay when attempting to establish a connection is too great, the application will abandon the connection attempt and try again.[2]

[edit] Why DDR is Still Used Today

Despite its drawbacks, there are two important reasons why Dial-on-Demand routing is used today: reliability and cost. These two factors become exceedingly important when a company has multiple locations that need to communicate with one another on a regular basis.

If a company or organization communicates between its different branches or firms regularly, it will most likely lease a dedicated cable line to connect each of the branches together. These lines are not always reliable meaning one branch may be cut off from the rest. In situations like this, having a backup connection ready is essential. Since DDR uses existing telephone lines, a DDR connection will almost always be available as a backup solution. A second reason why DDR is still used is because its cheap. Leasing cable lines can be needlessly expensive if information isnt constantly being sent back and forth between branches. This makes DDR very cost effective.

[edit] Defining Connection Access

DDR is commonly configured as a hub and spoke network, where remote sites dial a central site to exchange data. Depending on the needs, the central site can also be the one to contact the remote sites to retrieve data. Calls are initiated on a per need basis and are shut down once the transmission is terminated. Access Control Lists (ACLs) can be used to restrict which type of traffic is allowed to establish a connection. ACLs can be refined so that the interface is brought up only when the connection established matches a specific set of criteria. These specific criteria are essential to minimizing connections which would otherwise be initiated needlessly, thereby minimizing cost.

When using dynamic routing protocols to discover remote networks, it is crucial to configure interesting traffic accordingly; otherwise the connection will be initiated on every dynamic

routing update. Depending on the protocol being used this could occur as often as once every 60 seconds. Additionally, it is equally crucial to filter out any native Ethernet traffic which would otherwise cause an unwanted connection to initialize.

ACLs can also restrict the establishment of a link depending on the destination host being contacted and the host trying to establish the connection. For example, if only certain users are to be allowed to establish connections, but all users should have intranet access, then ACLs can be configured so that only the computers of the select users are allowed access.

Furthermore, ACLs can be configured so that only connections to a specific destination will be initialized. For example, if a hypothetical user Alice wants to connect to a Destination X and a hypothetical User Bob wants to connect to Destination Y, but traffic to destination X is not considered interesting, then only Bob would be able to establish a WAN connection.

Interesting traffic can also be defined such that only SSH packets are allowed to establish the link. In that case, then all other packets trying to access valid destinations will be discarded. When configuring dynamic routing protocols to communicate over a DDR connection, their update packets must be classified as interesting traffic. Depending on the dynamic routing protocol being used, setting their updates as interesting traffic might cause the connection to be initialized often.

For example RIP v1, which updates every 30 seconds, would cause the connection to be initialized on every update. It is common to see static routes defined for these connections in order to avoid extra service charges. Other routing protocols such as Open Shortest Path First (OSPF) and Enhanced Interior Gateway Routing Protocol (EIGRP) only send updates when a connection changes. These routing protocols are ideal for DDR and must be configured with "default-information originate" on a Cisco router.[3]

[edit] Dialer Maps and Rotary Groups

Dialer maps are configured on each interface to specify which numbers to dial and how long to stay on the line waiting for the receiving end to pick up. For example, if two dialer map commands on the Serial Interface 0/0/0 (Serial port 0 of module 0 of interface 0) have the same next hop address, or the IP address of the connection at the destination end, but with different phone numbers, then the first number is dialed and only once the wait-for-carrier timer expires will the next number be dialed. The wait-for-carrier timer can be specified when configuring the dialer map.

Backup interfaces can also be defined in the event that all of the numbers on a dialer map for that interface were unreachable. A single interface can be configured for multiple remote sites because no two connections to one interface can be on at the same time. The first step in

specifying a DDR interface is defining a rotary group. Although the DDR interface is a virtual one, all of the configuration commands for physical interfaces are available. A dialer Rotary Group can be created so that either of the interfaces in it can be used to dial any of the destinations defined in it.[4]