Understanding demand dial connections in Windows 2000

In previous Daily Drill Downs, Jim Boyce has shown you how to use your Windows 2000 server as a router. But how do you actually make the connections? In this Daily Drill Down, he introduces demand dial connections for Windows 2000.

In previous Daily Drill Downs, I explained how to implement the routing protocols included with Windows 2000—RIP and OSPF—to provide dynamic route management. In this Daily Drill Down, I continue the discussion about Routing and Remote Access Services in Windows 2000 with a look at demand dial connections.

Demand dial connections in detail
When you configure a Windows 2000 router, you have two options for establishing connections with other routers or networks: dedicated or demand dial connections. Dedicated connections typically use connections such as T1 and frame relay. Except on rare occasions when a hardware failure occurs, the connection remains persistent.

Demand dial routing (also called on-demand routing) forwards packets across a non-persistent Point-to-Point Protocol (PPP) connection. In general, you can think of demand dial connections as those routing connections that connect via dial-up means, whether those connections are persistent or not. For example, if you support a remote office that needs to be fed data from your local servers only once or twice a day, and the connection is metered and incurs charges based on connection duration, a dedicated connection might not make sense. In such a situation, a demand dial connection, which only gets used when data actually needs to be transmitted, makes more sense and could save the company a small bundle in connectivity charges. After the data is transmitted and an appropriate idle time has passed, Windows 2000 drops the connection. Figure A illustrates a situation in which demand dial routing would be useful.

Figure A
A demand dial connection serving a satellite office

On-demand versus persistent
There are two types of demand dial connections: on-demand and persistent. An on-demand connection is non-persistent and remains connected only when packets need to be forwarded through the demand dial interface. The previous example of the remote office is a good example of a scenario where an on-demand connection would be the best solution. Any time you have a metered connection, such as a long-distance POTS call or metered ISDN service, on-demand routing is generally the best solution.

The alternative is a persistent connection. At first blush, persistent connections might seem illogical in the context of demand dial routing, but you need to remember that demand dial routing isn’t simply geared toward forwarding packets across metered connections, but rather forwarding packets across any PPP dial-up connection. There are, therefore, scenarios where you’d want the demand dial interface to be persistent. For example, if the connection uses a local POTS call or flat-rate ISDN service where there is no per-minute charge, there’s no reason why you should not have the connection persist. If the connection is dropped, Windows 2000 automatically attempts to reestablish the connection.

Why not make all connections be on-demand, even if it doesn’t cost any more for a given connection to be persistent? Client access is the primary reason. The amount of time required to establish a demand dial connection varies depending on the connection media. A POTS call could take 20 seconds or more to establish a link, while ISDN could take less than five seconds.

This is an important consideration when setting up the demand dial connections—you need to take into account how the client applications will handle the connection delay. If the application supports a variable timeout setting, modify the timeout setting to accommodate the link establishment delay. If increasing the timeout doesn’t address link delay in all situations, modify the number of connection attempts the application makes. The application’s first attempt will initiate the connection sequence, and a secondary attempt will allow the application to connect after the router has time to establish the connection.

For all Microsoft Windows platforms, TCP sets a retransmission timer when it attempts the first data transmission for a connection. The initial retransmission timeout value is three seconds. TCP doubles the retransmission timeout value for each subsequent connection attempt and by default attempts retransmission two times. For example, the first attempt is made at three seconds, the second at 3+6 seconds, and the third at 3+6+12 seconds, for a maximum timeout of 21 seconds. Increasing the initial retransmission timer to five seconds would result in a total maximum timeout of 5+10+20, or 35 seconds. Setting the retransmission count to 4 with a retransmission timer of five would result in a total timeout of 5+10+20+40, or 75 seconds.

You can modify the TCP retransmission timer properties to extend the length of time that TCP will attempt a connection before timing out. For Windows 2000 and Windows NT 4.0 clients, the initial TCP retransmission timeout is set by the registry value HKEY_LOCAL_MACHINE\System\CurrentControlSet\
Services\Tcpip\Parameters\InitialRtt. The InitialRtt value is a REG_DWORD with a valid range from 0-65535 and it specifies the length of the timeout in milliseconds. A value of 5,000, for example, specifies an initial timeout of five seconds. The default value is 3,000.

The number of connection attempts is defined by the registry setting HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\
Parameters\TcpMaxDataRetransmissions. The TcpMaxDataRetransmissions value is also a REG_DWORD with a valid range of 0-65535. The default value is five.

For Windows 9x and Windows Me clients, the registry setting MaxConnectRetries specifies the number of times TCP will attempt a connection. The default is three. As with Windows 2000 and Windows NT, the default value for the initial connection timer is also three seconds.

One-way versus two-way demand dial connections
When you’re setting up a demand dial connection, you need to consider whether the connection will be one-way initiated or two-way initiated. In a one-way connection, one router always functions as the calling router and the other always functions as the answering router. In a two-way connection, either router can function as the calling or answering router.

For both types of connections, the answering router must be configured with an account that the calling router can use to establish the connection. In the case of a two-way connection, you need to create an account on both sides of the connection to be used by the calling router to authenticate on the answering router. Since either router can initiate a connection, both need to have accounts the other can use to authenticate and connect. In addition, the account name used by the calling router must match the demand dial interface name on the answering router—a requirement for both one-way and two-way connections.

Static routing and autostatic updates
In addition to authentication considerations, you also need to think about routing issues. While you could use dynamic routing (RIP or OSPF) over demand dial connections, the routing overhead traffic generated by the routers could nullify the benefit of using demand dial connections, including the reduction of connection charges. This is because the routers must exchange routing announcements, causing additional periodic traffic and requiring more frequent connections.

The solution is to use static routes where the number of routes is small, or use autostatic updates with RIP when the number of routes doesn’t lend itself to manually created static routes. In the case of manually created routes, simply add the static routes to the appropriate interfaces on both sides of the connection. Use the option Use This Route To Initiate Demand Dial Connections to control whether or not traffic that applies to the static route causes the demand dial connection to be initiated.

If the static route directs traffic to a primary subnet that carries critical traffic, you’ll probably want the static route to be used to initiate the demand dial connection. If the traffic is secondary, deselect this option to prevent the traffic from initiating the demand dial connection. In this latter scenario, the traffic will be routed only if the demand dial connection is already established (caused by traffic through another route) and will fail if the demand dial connection is not active.

Where there are more complex routing requirements not easily satisfied with manually created static routes, using RIP with autostatic updates is a viable solution. Autostatic updates marry the convenience of RIP with the connection control of static routes. Autostatic updates enable RIP to request all known routes from the remote router and add them to the local routing table as static routes. The autostatic update is a one-time, one-way event, and no additional route updates occur on the interface until you manually perform another autostatic update or the local router initiates another scheduled update. We’ll cover performing autostatic updates in an upcoming Daily Drill Down.

When you’re configuring routes between your routers, consider the impact that the default route will have on traffic and the demand dial interface. Because the default route is applied to all traffic not serviced by another route, traffic routed through the default route could cause unwanted connections. For example, if you configure the default route to be used to initiate the demand dial connection, the connection will dial any time the traffic is routed through the default route, including when you have traffic bound for a non-existent or unreachable subnet. For that reason, you should configure the default route so that it will not initiate the demand dial connection. To do so (or to configure the behavior for any other route), open the RRAS console, expand the IP Routing branch, and then select the Static Routes node. Select the route in question and display its properties. Deselect the option Use This Route To Initiate Demand Dial Connections.

Demand dial filters and time restrictions
Another issue to consider before you start creating your demand dial connections is whether or not you want to apply filters and time restrictions to the demand dial connections. In addition to configuring each static route according to whether or not it can initiate the demand dial connection, you can control connection initiation through demand dial filters. These filters let you specify criteria for the source and destination that determines when the demand dial interface can be initiated. As Figure B shows, you can configure the filters to allow all traffic that fits the filter criteria to initiate the connection or exclude all traffic fitting the criteria, preventing that traffic from initiating the connection.

Figure B
Configure demand dial filters to determine which traffic can initiate a demand dial connection.

Another consideration is when the demand dial interface can or should be initiated. By default, there are no dial-out hour restrictions on a demand dial interface, so traffic that fits the route or filter criteria can initiate the connection at any time. In some cases, you might want to restrict those hours. For example, you might process data transfers only at night and want the demand dial interface to only be used during those hours, preventing routing during the day as a means of controlling traffic or reducing costs. In my next Daily Drill Down, I’ll show you how you can configure each demand dial interface with hour restrictions to do just that.

So far in our series about Windows RRAS, I’ve discussed many aspects of how you can configure your Windows 2000 server to act as a router. In this Daily Drill Down, I’ve discussed how you can use Windows 2000 as a router even if you don’t have a persistent connection using Windows 2000’s demand dial capabilities. In my next Daily Drill Down concerning RRAS, I’ll show you how to set up demand dial in Windows 2000.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Editor's Picks