Demand-dial routing (also called on-demand routing) forwards packets across a non-persistent Point-to-Point Protocol (PPP) connection. Here's how you make demand-dial connections work in Windows Server 2003.
When you configure Windows Server 2003 to act as a 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 drops the connection. Here's how you make demand-dial connections work in Windows Server 2003.
In general, the process involves several steps:
- Enabling demand-dial routing
- Enabling remote access on the called router
- Enabling demand-dial connections on the dial-out hardware
- Creating the connection
- Configuring accounts and authentication
- Adding RIP and/or creating static routes
- Configuring demand-dial initiation filters
- Configuring dial-out hours
- Configuring Auto-Static updates
- Configuring persistence
- Enabling demand-dial routing and remote access
First, you must enable demand-dial routing for each router that needs to support it. To do so, open the RRAS console by clicking Start | Administrative Tools | Routing And Remote Access. Next, connect to that router. In the console, right-click the server and choose Properties. On the General page, verify that the Router option is selected and then select the option LAN And Demand-Dial Routing. On a called router, also select the option Remote Access Server and click OK. Windows Server 2003 will restart the RRAS service to accommodate the change.
In addition to configuring RRAS to support demand-dial routing, you have to configure the dial-out port to support demand-dial connections. In the RRAS console, expand the server, right-click on the Ports node, and choose Properties. Locate the device's port, click the port, and choose Configure. Select the Demand-Dial Routing Connections option, and if you also want to use the device for incoming remote access calls, select the Remote Access Connections option as well. Close the dialog boxes when you're done.
Creating the demand-dial connection
Next, create the demand-dial interface. First, install and configure the hardware to be used for the connection, such as the modem and ISDN interface. Then, open the RRAS console, expand the server, right-click Network Interfaces, and choose New Demand-Dial Interface to start the Demand-Dial Interface wizard. The wizard prompts for the following information:
- Interface Name: Specify the name as it will appear in the RRAS console. For easy identification, consider naming the connection after the remote router. If you're configuring a demand-dial connection for incoming calls in a two-way connection, give the interface a name that matches the account the remote router will use to connect to the local router.
- Connection Type: Choose between a physical device (modem, ISDN, etc.) or VPN connection, depending on the requirements of the remote router.
- VPN Type: If you choose to connect through a VPN, the wizard prompts for additional properties. Select the VPN type as PPTP, L2TP, or automatic selection. Remember that if you choose L2TP, you'll need to configure certificates and filters. If you choose the VPN option, you'll also need to specify the IP address or DNS name of the remote router.
- Phone Number: For non-VPN connections, specify the phone number of the remote router, including alternate numbers to dial if the primary is unavailable.
- Route IP Packets On This Interface: Select this option to allow IP routing on the demand-dial interface.
- Route IPX Packets On This Interface: Select this option to allow IPX routing on the demand-dial interface.
- Add A User Account So A Remote Router Can Dial In: If you're configuring a two-way demand-dial interface, select this option. The wizard will prompt you for the account properties of the account the remote router will use to connect to the local router. The wizard automatically uses the name specified in the Interface Name property (the first wizard page) as the account name and prompts only for the password for the account. The User Name field is dimmed to prevent you from changing the account name.
- Send A Plain-Text Password If That Is The Only Way To Connect: This option allows the router to accept plain-text passwords if it doesn't support encrypted passwords. This option is dimmed for VPN connections.
- Use Scripting To Complete The Connection With The Remote Router: Select this option to enable the local router to use a script to complete the connection to the remote router after dialing. You specify the script after completing the wizard.
After the wizard finishes, you have some additional configuration to perform. In the RRAS console, right-click the demand-dial interface you just created and click Properties. The General page enables you to configure the dial-up device used by the demand-dial connection. The properties are the same as those you'd configure for a typical dial-out connection through the Network And Dial-Up Connections folder. If you want to use multilink to improve throughput, select all appropriate devices from the Connect Using group. You configure additional multilink options through the Options page.
The Options page shown in Figure A lets you configure several connection options. In the Connection Type group, you specify whether the connection will be on demand (demand dial) or persistent. If choosing Demand Dial, use the drop-down list to specify the idle time for hanging up. Make sure you specify a length of time that accommodates normal idle times during data transmission. Use the Dialing Policy group to specify the number of redial attempts and the interval between redial attempts.
|Use the Options page to configure the connection as demand dial or persistent.|
The Multiple Devices group lets you configure multilink for the demand-dial connection. From the drop-down list, select the method you want Windows Server 2003 to use to establish multilink connections. If you choose Dial Devices Only As Needed, click Configure Bandwidth Utilization Parameters to control dialing and hanging up. Finally, if you need to use callback or X.25, click the appropriate button to configure those properties for the connection.
The Security page is the place to go to configure the authentication method(s) used by the demand-dial connection, and the settings are just like any other outgoing dial-up connection. If you need to run a script to complete the demand-dial connection, configure the script in the Interactive Logon And Scripting group.
The final property page, Networking, enables you to configure the network services that the demand-dial connection will use, including network protocols, clients, and server type. Again, these properties are the same as for any other outgoing remote access connection. Configure the settings according to the requirements for your data transfer. If the clients use a given protocol, for example, make sure that protocol is enabled for the dial-out connection.
Configure filters and hour restrictions
Next, you'll need to configure demand-dial filters to determine which traffic can initiate the demand-dial connection and, if desired, to restrict the connection to specific hours. First, open the RRAS console and select the Routing Interfaces branch. In the right pane, right-click the demand-dial interface you want to configure and choose Set IP Demand-Dial Filters. Click Add and then specify the criteria based on source network or destination network (or both), as well as the protocol. Then, click OK. Add filters as needed and then select one of the following options:
- For All Traffic Except: Select this option if you want all traffic except that falling under your specified filter criteria to be able to initiate the connection. All traffic that fits the filter criteria will not initiate the demand-dial connection.
- Only For The Following Traffic: Select this option if you want only traffic that meets the filter criteria to be able to initiate the demand-dial connection.
Click OK when you've finished creating the filters.
Next, configure dial-out restrictions if you don't want the demand-dial connection to be available all the time. Right-click the demand-dial interface and choose Dial-Out Hours. Use the resulting dialog box to select the hours that the demand-dial connection is either permitted or denied.
Setting up the routes
If the number of routes you need to manage over the demand-dial connection is relatively high and you intend to use Routing Information Protocol (RIP) and Auto-Static updates to maintain the routes, you need to add RIP. In the RRAS console, expand the server, open the IP Routing branch, right-click General, and choose New Routing Protocol. Select RIP and choose OK.
Next, right-click RIP in the IP Routing branch and choose New Interface. Select the demand-dial connection and click OK. Windows Server 2003 presents a tabbed property sheet that is the same as when you configure RIP on any other routing interface. Verify that Auto-Static Update Mode is selected in the Operation Mode drop-down list. The other default settings are correct for connecting to another Windows Server 2003 RRAS router. If you need to tweak the settings to accommodate a different remote router or your network requirements, make the changes now.
If the number of routes for the demand-dial interface is low, a better solution than using RIP is to simply create static routes. Open the IP Routing\Static Routes node in the RRAS console, right-click the node (or right-click in the right pane), and choose New Static Route. Select the demand-dial interface from the Interface drop-down list and configure the static route as needed.
If you want traffic destined for the selected route to be able to initiate the demand-dial connection, select the option Use This Route To Initiate Demand-Dial Connections. Deselect the option if you don't want traffic destined for the selected route to be able to initiate the connection. When you're satisfied with the static route properties, close the dialog box and then repeat the process to create any other required static routes.
Performing manual and scheduled Auto-Static updates
When RRAS performs an Auto-Static route update, it deletes the existing routes and then requests an update from the remote router, obtaining all remote routes. If the update request fails for some reason (the remote router is unavailable, for example), the local router won't be able to rebuild its routing table. This means that the routes will be unavailable until a successful update occurs. This is one minor disadvantage to using RIP instead of static routes for the demand-dial interface, but in most situations it is a manageable risk. Be sure to take this risk into account when you're developing your routing strategy for the demand-dial connection.
When you want to initiate an Auto-Static update, open the RRAS console and then expand the server. Open the IP Routing branch and then open the General branch. Right-click the demand-dial interface whose routes you want to update and choose Update Routes. If the demand-dial connection is currently active, the route transfer begins. If not, the local router initiates the demand-dial connection and then requests the update. Keep in mind that an Auto-Static update transfers routing data from the remote router to the local router. If you're updating routes in a two-way demand-dial connection, you need to also perform an Auto-Static update at the remote router to update its routes.
The RRAS GUI interface doesn't provide a mechanism for scheduling Auto-Static route updates to occur automatically, but you can use the NETSH command from a command console to update routes. This enables you to create a script containing the appropriate NETSH commands and schedule that script using the Windows Server 2003 AT command. Here is an example of a script that updates the routing information for a demand-dial connection named RemoteOffice:
netsh interface set interface name=RemoteOffice connect=CONNECTED
netsh routing ip rip update RemoteOffice
netsh interface set interface name=RemoteOffice connect=DISCONNECTED
You can also create a script for NETSH and execute that script through the NETSH command. For example, save the previous commands to a text file called RemoteUp.scp. Then, run the following command to execute the script:
netsh -f RemoteUp.scp
Setting up a two-way demand-dial connection
Up to this point, I've primarily focused on setting up a one-way demand-dial connection. Setting up a two-way connection is essentially the same, except you perform the configuration tasks at both ends of the connection. You'll need to configure the hardware, set up the connection, configure routes, and perform the other tasks explained above.
One of the most potentially confusing aspects of two-way demand-dial connections is the naming convention you use on both routers. Remember when you're naming the connections that each connection's name should be the same as the connection authentication account on the remote router.
For example, assume you have two routers in two locations. At your Headquarters location, you have a router with an interface name of RemoteOffice. At your remote location, you have a router with an interface name of HomeOffice. Therefore, to make the connection work properly you should create a user account at Headquarters with a user account name of HomeOffice, as well as a user account at the remote site with a user account name of RemoteOffice.