Demand Dial Routing

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

This information was adapted for Microsoft Windows NT 4.0 with the Routing and Remote Access Service (RRAS) from a chapter in the Windows 2000 Server Resource Kit.

Microsoft® Windows® NT Server version 4.0 with the Routing and Remote Access Service (RRAS) provides extensive support for demand dial routing, the routing of packets over point-to-point links such as analog phone lines and ISDN. Demand dial routing allows you to connect to the Internet, to connect branch offices, or to implement router-to-router virtual private network (VPN) connections.

In This Document

Introduction to Demand Dial Routing

Demand Dial Routing Process

Demand Dial Routing Security

Creating User Accounts with the Demand Dial Wizard

Demand Dial Routing and Routing Protocols

IPX Demand Dial Connections

Troubleshooting Demand Dial Routing

Related Information

For more information about unicast routing, see the "Unicast Routing Principles" article in Microsoft TechNet.
For more information about RRAS and IP routing, see the "Unicast IP Routing" article in Microsoft TechNet.
For more information about RRAS and IPX routing, see the "IPX Routing" article in Microsoft TechNet.
For more information about PPP connection establishment and the PPP protocol suite, see the "Remote Access Server" article in Microsoft TechNet.
For more information about virtual private networks, see the "Virtual Private Networking" article in Microsoft TechNet.

Introduction to Demand Dial Routing

Demand dial routing is the forwarding of packets across a Point-to-Point Protocol (PPP) link. The PPP link is represented inside the Windows NT router as a demand dial interface. Demand dial interfaces can be used to create on-demand connections across dial-up, non-permanent or persistent media.

With local area network (LAN) and permanent wide area network (WAN) links, the interface that is being used to forward the packet is always in an active or connected state. The packet can be forwarded without having to create the physical or logical connection. However, the demand dial interface can either be in a connected state or a disconnected state. If in a disconnected state when the packet is being forwarded, the demand dial interface must be changed to a connected state before the packet can be forwarded.

The connection establishment process, consisting of creating a physical connection or a logical connection and a PPP connection, introduces a delay in the forwarding of the packet called the connection establishment delay. The length of the connection establishment delay varies for the type of physical or logical connection being established. For example, the connection establishment delay for analog phone lines or X.25 dialing in to a packet assembler-disassembler (PAD) can be 10 to 20 seconds or more. For Integrated Services Digital Network (ISDN) lines, the connection establishment delay can be as small as 3 to 5 seconds.

The connection establishment delay is an important consideration for applications being used across a demand dial connection. There are two behaviors of applications to consider:

How long it takes for the application to abandon the attempt to establish network communications, also known as application time-out. If the application time-out is longer than the connection establishment delay, then the application fails to establish communications and presents an error message to the user.
How many times it attempts to establish network communications. On the first attempt, network traffic is forwarded to the demand dial router which begins the connection establishment process. Due to the size of a finite buffer in the router, additional packets to be forwarded across the demand dial connection that arrive during the connection establishment process might overwrite the initial application connection attempt packet. If the application tries to establish communications multiple times, then there is a better chance of forwarding an application connection attempt packet once the connection is established.

Applications that have long time-outs or multiple retries might not fail while waiting for the link to become available. Interactive applications such as Web browsers and Telnet might fail when first connecting. However, when the user retries the connection attempt, it succeeds because the first connection attempt created the demand dial connection.

Once the connection is established, packets are forwarded across the demand dial connection. Because the costs of demand dial connections are typically time sensitive, after a configured amount of idle time the demand dial link is terminated. Demand dial connections have the benefit of allowing the user to use cheaper dial-up WAN links and only pay for the link when it is being used.

Demand Dial Routing and Remote Access

Demand dial routing is not the same as remote access; remote access connects a single user to a network, and demand dial routing connects networks together. However, both remote access and demand dial routing use PPP as the protocol mechanism to negotiate and authenticate the connection and encapsulate data sent on the connection. As implemented with RRAS, both remote access and demand dial connections can be enabled separately but share the same:

Behavior of the dial-in properties of user accounts.
Security, including authentication protocols and encryption.
Use of Windows or Remote Authentication Dial-In User Service (RADIUS) as authentication providers.
IP and Internetwork Packet Exchange (IPX) address allocation configuration.
Use of PPP features such as Microsoft Point-to-Point Compression (MPPC) and Microsoft Point-to-Point Encryption (MPPE).
Troubleshooting facilities including event logging and tracing.

On-Demand and Persistent Connections

On-demand connections are used when the cost of using the communications link is time-sensitive. For example, long distance analog phone calls are charged on a per-minute basis. With on-demand connections, the connection is made when traffic is forwarded, and the connection is terminated after a configured amount of idle time.

Idle disconnect behavior can be configured on the calling router. To configure idle disconnect on the calling router, the router initiating the connection, set an idle disconnect time on the Dialing tab of the properties of the demand dial interface.

Persistent demand dial connections use a dial-up WAN technology when the cost of the link is fixed and the connection can be active 24 hours a day. Examples of WAN technologies for persistent demand dial connections include local calls that use analog phone lines, leased analog lines, and flat-rate ISDN. If a persistent connection is lost, the calling router immediately attempts to reestablish the connection.

Persistent connection behavior must be configured on the calling router.

To configure connection persistence on the calling router

In the Routing and RAS Admin administrative tool, right-click the demand dial interface under LAN and Demand Dial Interfaces, and then click Properties.
On the Dialing tab, select Persistent connection.

Demand Dial Interface Configuration

Either router can be the answering router or the calling router depending on who is initiating the connection. Both routers must be configured to initiate and accept a demand dial connection. This requires that:

Both routers are configured as demand dial routers.
User accounts are added for both routers so that the authentication credentials of the calling router can be validated by the answering router.
Demand dial interfaces, with the same name as the user account that is used by the calling router, are fully configured at both routers, including the phone number of the answering router and user account credentials to authenticate the calling router.
Static routes are configured on both routers.

For demand dial routing to work properly, the user name in the authentication credentials of the calling router must match the name of a demand dial interface on the answering router for both sides of the connection. Table 1 shows an example of this configuration.

Table 1 Example of a Demand Dial Interface Configuration

Router	Demand Dial Interface Name	User Account Name
Corporate office router	NewYorkRouter	CorpHub
Branch office router	CorpHub	NewYorkRouter

Components of Demand Dial Routing

The main components of demand dial routing are the calling router, the answering router, and the connection medium as illustrated in Figure 1.

Figure 1: Components of Demand Dial Routing

Figure 1: Components of Demand Dial Routing

Calling Router

The calling router initiates the demand dial connection. It contains the following components:

Routing and Remote Access Service

The Routing and Remote Access Service on the calling router must be configured for demand dial routing and configured for IP address allocation (either using DHCP or a static pool) and authentication methods.
Port

A port is a logical or physical communications channel capable of supporting a single PPP connection. Physical ports are based on equipment installed in the calling router. Virtual private network (VPN) ports are logical ports.
Demand dial interface

A demand dial interface configured on the calling router represents the PPP connection and contains configuration information such as the port to use, the addressing used to create the connection (such as a phone number), authentication and encryption settings, and authentication credentials.
Route

An IP or IPX route in the routing tables of the calling router is configured to use a demand dial interface to forward traffic.

Answering Router

The answering router, the router that accepts an initiated demand dial connection from a calling router, contains the following components:

Routing and Remote Access Service

The Routing and Remote Access Service on the answering router must be configured for demand dial routing and configured for IP address allocation (either using DHCP or a static pool) and user authentication.
Port

A port is a logical or physical communications channel capable of supporting a single PPP connection. Physical ports are based on equipment installed in the answering router. Virtual private network (VPN) ports are logical ports.
User account

To authenticate the calling router, the credentials of the calling router must be verified by the properties of a corresponding user account. A user account for the calling router must be either locally present or available through Windows NT security. If the answering router is configured for RADIUS authentication, then the RADIUS server must have access to the user account of the calling router.

The user account must have the following settings:
- On the Dialin Information dialog box, Grant dialin permission to user is selected.
- On the User Properties dialog box, User Must Change Password at Next Logon is disabled and Password Never Expires is enabled.
Demand dial interface

A demand dial interface configured on the answering router represents the PPP connection to the calling router.
Route

An IP or IPX route in the routing tables of the calling router is configured to use a demand dial interface to forward traffic.

Connection Medium

The PPP link is established over either a physical medium or a tunnel medium. Physical mediums include analog phone lines and ISDN. Tunnel mediums include the Point-to-Point Tunneling Protocol (PPTP).

Demand Dial Routing Process

The following sequence outlines the demand dial routing process when both the calling router and the answering router are Windows NT routers:

Upon receipt of a packet, the calling router finds the best route to forward the packet.
If the interface on the best route is a demand dial interface, the connection state of the interface is checked.

If the connection state is "Connected," then the packet is forwarded across the interface subject to the packet filters configured on the interface.

If the connection state is "Disconnected," then the IP or IPX forwarder component calls the Dynamic Interface Manager, a component of the RRAS, with instructions to bring up the demand dial interface in the route.
The Dynamic Interface Manager retrieves the configuration of the indicated demand dial interface from SystemRoot\system32\ras\router.pbk.
Based on the port of the demand dial interface configuration, a physical or logical connection with the endpoint of the connection is made.

For direct serial or direct parallel configurations, there is no phone number. A physical connection is made between the two computers using the serial or parallel port.

For modem or ISDN ports, the configured phone number is dialed using the configured port. If the configured port is not available, another port of the same type is used. If no other ports of the same type are available, then the connection attempt is terminated and the unreachability reason is set.

For VPN connections, the configured IP address or host name is used to establish a PPTP tunnel.

Once the physical or logical connection is made, a PPP connection is negotiated with the endpoint. PPP connection behavior that is specific to demand dial connections is as follows:
- The calling router is allocated an IP address by the answering router and the answering router is allocated an IP address by the calling router. The allocated IP addresses should be on different subnets to prevent both routers from allocating the same IP address.
- Unlike remote access clients, the calling router does not create a default route.
The credentials of the calling router are sent during the PPP authentication phase based on the negotiated PPP authentication protocol.

Based on the user credentials, the answering router either:
- Checks the appropriate account database to authenticate the connection.
- Sends the connection attributes to a configured RADIUS server.
The answering router looks in SystemRoot\System32\ras\router.pbk for the name of a demand dial interface that matches the user name of the user credential of the calling router.

If a demand dial interface name matching the calling router user name is found, the demand dial interface is changed to a "Connected" connection state.
Once the PPP connection establishment is completed, the calling router forwards packets across the demand dial connection subject to the packet filters configured on the demand dial interface.

If the user name credential of the calling router does not match the name of a demand dial interface, the calling router is interpreted as a remote access client. This situation might cause routing problems.

For example, if the calling router uses a user name credential that does not correspond to a demand dial interface on the answering router, then the calling router is identified as a remote access client rather than a router. Packets forwarded from the calling router's intranet are forwarded across the demand dial connection and then forwarded by the answering router.

However, when response packets sent back to the calling router's intranet are received by the answering router, the routes for the calling router's intranet are configured to use a demand dial interface. Because the demand dial interface is in a "Disconnected" state, the answering router attempts a demand dial connection to the calling router. If another port of the same type is available, a second demand dial connection is made. If another port of the same type is not available, the packet is dropped and the unreachability reason is set. The end result is that either two demand dial connections are created when only one is needed or the packet is dropped.

On-Demand Router-to-Router VPN

A router-to-router VPN connection is typically used to connect remote offices together when both routers are connected to the Internet through permanent WAN links, such as T1 or Frame Relay. In this configuration, the VPN connection is persistent and available 24 hours a day. However, when a permanent WAN link is not possible or practical, you can configure an on-demand router-to-router VPN connection.

Figure 2 shows an on-demand router-to-router VPN connection.

Figure 2: On-Demand Router-to-Router VPN Connection

Figure 2: On-Demand Router-to-Router VPN Connection

An on-demand router-to-router VPN connection consists of two demand dial interfaces that are configured on the VPN client (the calling router):

A demand dial interface to dial-in to a local Internet service provider (ISP).
A demand dial interface for the router-to-router VPN connection.

An on-demand router-to-router VPN connection is automatically established when you route traffic to a specific location. For example, in a branch office configuration, when a packet is received to be routed to the corporate office, the branch office router uses a dial-up link to connect to a local ISP and then creates a router-to-router VPN connection with the corporate office router located on the Internet.

Note: This discussion assumes that the corporate office router (the answering router) is connected to the Internet using a permanent WAN link. It is possible to have both routers connected to the Internet by using a dial-up WAN link. However, this is only feasible if the Internet service provider (ISP) supports demand dialing routing to customers; the ISP calls the customer router when an IP packet is to be delivered to the customer. Demand dial routing to customers is not widely supported by ISPs.

To configure an on-demand router-to-router VPN connection at the branch office router, do the following:

Create a demand dial interface for the Internet connection that is configured for the appropriate equipment (a modem or ISDN device), the phone number of the local ISP, and the user name and password to gain Internet access.
Create a demand dial interface for the VPN connection with the corporate office router that is configured for a VPN port (a PPTP port), the IP address of the interface on the Internet for the corporate office router, and a user name and password that can be verified by the VPN server. The user name must match the name of a demand dial interface on the corporate office router.
Create a static host route for the IP address of the corporate office router's Internet interface that uses the ISP demand dial interface.
Create a static route (or routes) for the IP network of the corporate intranet that uses the VPN demand dial interface.

To configure the corporate office router, do the following:

Create a demand dial interface for the VPN connection with the branch office that is configured for a VPN port (a PPTP port). The demand dial interface must have the same name as the user name in the authentication credentials that is used by the branch office router to create the VPN connection.
Create a static route (or routes) for the IP network IDs of the branch office that uses the VPN demand dial interface.

The router-to-router VPN connection is automatically initiated by the branch office router through the following process:

Packets sent to a corporate network location from a computer in the branch office are forwarded to the branch office router.
The branch office router checks its routing table and finds a route to the corporate intranet network, which uses the VPN demand dial interface.
The branch office router checks the state of the VPN demand dial interface and finds it is in a disconnected state.
The branch office router retrieves the configuration of the VPN demand dial interface.
Based on the VPN demand dial interface configuration, the branch office router attempts to initialize a router-to-router VPN connection at the IP address of the corporate office router on the Internet.
To establish a PPTP VPN connection, a TCP packet must be sent to the corporate office router that acts as the VPN server. The VPN establishment packet is created.
To forward the VPN establishment packet to the corporate office router, the branch office router checks its routing table and finds the host route that is using the ISP demand dial interface.
The branch office router checks the state of the ISP demand dial interface and finds it is in a disconnected state.
The branch office router retrieves the configuration of the ISP demand dial interface.
Based on the ISP demand dial interface configuration, the branch office router uses its modem or ISDN device to dial and establish a connection with its local ISP.
Once the ISP connection is made, the VPN establishment packet is sent to the corporate office router.
A router-to-router VPN connection is negotiated between the branch office router and the corporate office router. As part of the negotiation, the branch office router sends authentication credentials that are verified by the corporate office router.
The corporate office router checks its demand dial interfaces and finds one that matches the user name sent during authentication and changes the interface to a connected state.
The branch office router forwards the routed packet across the VPN and the corporate office router forwards the packet to the appropriate intranet location.
When the intranet location responds to the packet sent to it by the user in the branch office, the packet is forwarded to the corporate office router.
The corporate office router checks its routing table and finds a route to the branch office network that uses the VPN demand dial interface.
The corporate office router checks the state of the VPN demand dial interface and finds it is in a connected state.
The response packet is forwarded across the Internet by using the VPN connection.
The response packet is received by the branch office router and is forwarded to the original user.

Testing Demand Dial Connections

You can test whether a demand dial connection works correctly either manually or automatically.

Manual Test

By manually testing a demand dial connection, you are testing whether the PPP link can be established. Manual testing verifies that the configuration of the authentication methods, encryption, user credentials, and address for the demand dial interface are valid.

To manually connect a demand dial interface

In the Routing and RAS Admin administrative tool, double-click LAN and Demand Dial Interfaces.
Right-click the appropriate demand dial interface.
Click Connect.

Once the demand dial connection is made, the Connection Status column of the demand dial interface changes from Disconnected to Connected.

If you cannot manually connect the demand dial interface, see "Troubleshooting Demand Dial Routing".

Automatic

By automatically testing a demand dial connection, you are testing whether the demand dial connection is automatically initiated when traffic matching a configured route is sent to the demand dial router. Before automatic testing, ensure that the appropriate static routes are configured on the calling router and answering router.

To test for an automatic connection, verify that the demand dial interface being tested is in a disconnected state. Next, generate network traffic for a location that exists across the demand dial connection. One easy way to generate IP traffic is to use the ping or tracert commands.

For ping and tracert, the first attempt might fail due to the connection establishment delay. However, the first packet being sent across the interface causes the demand dial interface to be connected. Subsequent use of the testing utility is successful once the connection has been made. One way to see the connection process from an application viewpoint is to use the ping command with the "-t" command line option to continue sending Internet Control Message Protocol (ICMP) Echo Request messages until interrupted. You see "Request timed out" messages until the demand dial connection is made, after which you see the replies.

If you cannot automatically connect the demand dial interface, see "Troubleshooting Demand Dial Routing".

Demand Dial Routing Security

Security for demand dial connections uses the same security features as remote access connections including:

Dialin permission
Authentication
Encryption
Callback

For more information about callback, see "Remote Access Server".

Dialin Permission

The user account of the calling router must be a valid account in the security database of the answering router or RADIUS server (if RADIUS authentication is being used) and it must be granted dialin permission explicitly in the user account (the Grant dialin permission to user option in the Dialin Information dialog box for the user account is selected).

Authentication

The calling router is authenticated at the user level. As part of the PPP connection establishment process, the calling router's credentials must be authenticated. User-level authentication occurs through one of the following PPP authentication methods:

Password Authentication Protocol (PAP)
Shiva Password Authentication Protocol (SPAP)
Challenge Handshake Authentication Protocol (CHAP)
Microsoft Challenge Handshake Authentication Protocol (MS-CHAP)

The calling router's credentials consist of a user name, a domain, and a password. In all of the previously listed authentication methods except PAP, the password is sent over the connection in an encrypted or hashed form.

One-Way and Two-Way Authentication

Authentication of the demand dial connection can be one-way or two-way.

One-Way Authentication

With one-way authentication, the calling router authenticates itself to the answering router. PAP, SPAP, CHAP, and MS-CHAP authentication methods only provide for the passing of credentials from the calling router to the answering router. With one-way authentication, the calling router does not receive any verification that the answering router is the proper router. One-way authentication does not provide protection from unauthorized or masquerading answering routers.

Two-Way Authentication

Two-way authentication uses one-way authentication methods to perform mutual authentication. When two-way authentication is enabled on a demand dial interface, the calling router forces the answering router to authenticate itself after the calling router authenticates itself to the answering router. Two-way authentication is enabled by selecting Use two-way authentication on the Security tab from the properties of a demand dial interface.

Encryption

Microsoft Point-to-Point Encryption (MPPE) is available for demand dial connections. All PPP connections, including PPTP, can use Microsoft Point-to-Point Encryption (MPPE). MPPE uses the Rivest-Shamir-Adleman (RSA) RC4 stream cipher and is only used when the MS-CHAP authentication method is used.

MPPE can use 40-bit or 128-bit encryption keys. By default, the highest key strength supported by the calling router and answering router is negotiated during the connection establishment process. If the answering router requires a higher key strength than is supported by the calling router, the connection attempt is rejected. You can require encryption by selecting Require data encryption on the Network Configuration dialog box from the properties of the Routing and Remote Access Service in Control Panel-Network. You can require 128-bit encryption by selecting Require strong data encryption on the Network Configuration dialog box from the properties of the Routing and Remote Access Service in Control Panel-Network.

Demand Dial Interface Packet Filtering

IP and IPX packet filters on the demand dial interface can be used to restrict the types of traffic that are allowed in to (input filters) and out of (output filters) the interface. IP and IPX packet filtering only occurs when the demand dial interface is in a connected state.

Packet filtering is especially useful for an extranet, a portion of your private intranet that is accessible to business partners over demand dial connections. For example, when a business partner makes a demand dial connection, packet filters on the demand dial interface can restrict the TCP/IP traffic to only specific network segments or specific resources as identified by IP address and TCP or UDP port number.

Creating User Accounts with the Demand Dial Wizard

When a demand dial interface is created with the Demand Dial wizard in the Routing and RAS Admin administrative tool, the Add a user account so a remote router can dial in option on the Protocols and Security page of the wizard allows you to create a new user account that is used by the calling router. When this option is selected, a user account with the same name as the demand dial interface is created in the security accounts database being used by the router on which the demand dial interface is being created. The user account is created with the following settings:

Grant dialin permission to user is enabled.
User must change password at next logon is disabled.
Password never expires is enabled.

Demand Dial Routing and Routing Protocols

The method of updating the routing tables of demand dial routers depends on the type of demand dial connection.

For on-demand connections, use static routing.
For persistent connections, use dynamic routing with routing protocols.

On-Demand Connections

The recommendation of static routing for on-demand demand dial connections is based on the fact that the routing protocols provided with RRAS (Routing Information Protocol [RIP] for IP, Open Shortest Path First [OSPF], RIP for IPX, Service Advertising Protocol [SAP] for IPX) have a periodic advertising behavior that can cause the connection to be made for each advertisement or to keep the connection up permanently if the advertising interval is less than the idle time-out. Due to the time, distance, and cost-sensitive nature of typical dial-up WAN links, running routing protocols over on-demand connections is not recommended.

Static routes for demand dial routing are either manually configured or automatically configured by using autostatic updates.

Manual Configuration of Static Routes

Manual configuration of static routes is the adding of static routes that are available across the demand dial interface using the Routing and RAS Admin administrative tool. For TCP/IP traffic, static IP routes must be added. For IPX traffic, static IPX routes and static SAP services must be added.

Using a Default IP Route for an On-Demand Connection

Make sure to use the default IP route (0.0.0.0 with a subnet mask of 0.0.0.0) carefully. While the default route can be used to simplify configuration of static routing over on-demand connections, you must consider its implications. The default IP route effectively summarizes all IP destinations and becomes the route used to forward IP packets when another more specific route is not found.

The use of the default route is an assumption that all other destinations is in the direction of the default route. When you are using a demand dial interface to connect to the Internet, this is a valid assumption. However, when you are using a demand dial interface to connect a branch office to a corporate office in a private intranet, the use of a default route needs to be carefully considered.

If a default IP route is configured to use a demand dial interface, then the demand dial connection can be initiated for IP traffic that is unreachable. For example, if an organization is using the private IP network 10.0.0.0 with the subnet mask 255.0.0.0 for its address space and a branch office uses 10.1.1.0 with the subnet mask 255.255.255.0 for the hosts of the branch office, then the static routing of the branch office router can be configured in the following ways:

Configure a static route for 10.0.0.0 with the subnet mask 255.0.0.0 using the on-demand demand dial interface.

If someone in the branch office attempts to send traffic to the destination IP address of 192.168.0.1, the router at the branch office does not have a route in its routing table for the packet. The packet is discarded and an ICMP Destination Unreachable-Host Unreachable message is sent to the sending host.
Configure a default route using the on-demand demand dial interface.

If someone in the branch office attempts to send traffic to the destination IP address of 192.168.0.1, the router at the branch office initiates the connection and forward the packet across the demand dial connection to the corporate router. Neither the corporate router nor another router on the corporate intranet has a route in its routing table for the packet. The packet is discarded and an ICMP Destination Unreachable-Host Unreachable message is sent to the sending host.

Using a default route for branch office connectivity can produce undesirable results for unreachable traffic.

Autostatic Updates

While manually entering a small number of static routes might be a feasible solution, when the number of routes is large or routes change, manual configuration is no longer a viable administrative option. To automatically add routes and services to the routing tables of a Windows NT router, RRAS supports autostatic updates across demand dial interfaces.

An autostatic update requests all known routes or services from the router on the other side of the connection and adds them to the routing tables of the requesting router. An autostatic update is a one-time, one-way exchange of routing information. After the routes are sent, the two routers do not periodically advertise even though the connection remains in a connected state.

Note: The "auto" in autostatic is the automatic adding of routes as static routes in a routing table. Autostatic updates do not occur automatically when the demand dial connection is made.

To use autostatic updates for IP routes, the demand dial interface must be added to the RIP for Internet Protocol routing protocol. The default operation mode for demand dial interfaces for RIP is Autostatic update mode. The default outgoing packet protocol is RIP version 2 multicast. The default settings are correct when initiating a connection with another Windows NT router.

To use autostatic updates for IPX routes and SAP services, the demand dial interface must be added to the RIP for IPX and SAP for IPX routing protocols. The default update mode for demand dial interfaces for RIP for IPX is No update. You must change the update mode to Autostatic. The default update mode for demand dial interfaces for SAP for IPX is No update. You must change the update mode to Autostatic.

To change the update mode

In the Routing and RAS Admin administrative tool, double-click IPX Routing.
For RIP for IPX, click RIP for IPX, right-click the appropriate demand dial interface, click Autostatic under Update mode, and then click OK.
For SAP for IPX, click SAP for IPX, right-click the appropriate demand dial interface, click Autostatic under Update mode, and then click OK.

Note: When an autostatic update is requested, the existing routes that were obtained through a previous autostatic update are deleted before the request for routes is sent. If there is no response to the request, then the router cannot replace the routes it has deleted. This might lead to a loss of connectivity to remote networks.

Autostatic updates can be made manually or on a scheduled basis.

Manual Autostatic Updates

To manually update static IP routes across a demand dial interface, perform the following procedure.

To manually perform an IP autostatic update

In the Routing and RAS Admin administrative tool, double-click IP Routing, and then double-click Summary.
Right-click the appropriate demand dial interface, and then click Update routes.

If the demand dial interface is in a disconnected state, the connection is automatically made. After the link is in a connected state, the autostatic update begins. The autostatic update only transfers routing information from the answering router to the calling router. To transfer routing information from the calling router to the answering router, perform the preceding procedure on the answering router.

The transfer of IP routing information occurs through RIP for IP. The router on which the update was initiated sends a General RIP Request. The router on the other end of the connection responds with a RIP Response containing all of the appropriate routes in its IP routing table. The RIP routes received by the requesting router are automatically added as static routes to the requesting router's IP routing table. For more information about RIP messages, see "Unicast IP Routing".

To manually update static IPX routes and SAP services across a demand dial interface, perform the following procedure.

To manually perform an IPX and SAP autostatic update

In the Routing and RAS Admin administrative tool, double-click IPX Routing and then open Summary.
Right-click the appropriate demand dial interface, and then click Update routes.

Just as in the case of an IP autostatic update, if the demand dial interface is in a disconnected state, the connection is automatically made. After the link is in a connected state, the auto static update begins. The autostatic update only transfers routing and service information from the answering router to the calling router. To transfer routing and service information from the calling router to the answering router, perform the preceding procedure on the answering router.

The transfer of IPX routing information occurs through RIP for IPX. The router on which the update was initiated sends a RIP General Request. The router on the other end of the connection responds with a RIP Response containing all of the appropriate routes in its IPX routing table. The RIP for IPX routes received by the requesting router are added as static routes to the requesting router's IPX routing table. For more information about RIP messages, see "IPX Routing".

The transfer of SAP service information occurs through SAP for IPX. The router on which the update was initiated sends a SAP General Request. The router on the other end of the connection responds with a SAP Response containing all of the appropriate services in its SAP service table. The SAP services received by the requesting router are added as static services to the requesting router's SAP service table. For more information about SAP messages, see "IPX Routing".

Scheduled Autostatic Updates

Scheduled updates can be automated using a combination of ROUTEMON scripts and the Windows NT Scheduler service (the AT command). To perform an automated auto-static update, the following ROUTEMON commands need to be run:

ROUTEMON interface connect <Demand Dial interface name>
ROUTEMON interface update <Demand Dial interface name> <protocol: IP, IPX>
ROUTEMON interface disconnect <Demand Dial interface name>

For example, to automatically update the RIP for IP routes using a demand dial connection called CorpHub, the ROUTEMON commands would be:

ROUTEMON interface connect CorpHub
ROUTEMON interface update CorpHub IP
ROUTEMON interface disconnect CorpHub

The above commands can be run from a batch file or they can be placed in a ROUTEMON script file. For example, the following script file CORPHUB.SCP is created to run the above commands:

interface connect CorpHub
interface update CorpHub IP
interface disconnect CorpHub

To run the above script file, execute the following at the command line:

ROUTEMON script= CORPHUB.SCP

Note the use of the space between the "=" and the script file name.

Once the ROUTEMON script file is created, running it on a scheduled basis is done by enabling the Windows NT Schedule service and using the AT command to execute the ROUTEMON script when desired.

Persistent Connections

For persistent demand dial connections, routing protocols can be enabled to operate in the same fashion as LAN interfaces to provide dynamic updates of routing tables. Special configuration of the routing protocol for a persistent demand dial interface is outlined in Table 2.

Table 2 Changes to Default Routing Protocol Configuration for Demand Dial Interfaces

Routing Protocol	Configuration Change
RIP for IP	Change the default operation mode to Periodic update mode and enable triggered updates.
OSPF	Select the Point-to-point network type on the General tab on the properties of an OSPF interface. This is the default network type for demand dial interfaces. For a persistent router-to-router VPN connection, you might want to increase the values of the transit delay, the re-transmit interval, the hello interval, and the dead interval on the Advanced tab on the properties of an OSPF interface to account for the delay of forwarding OSPF packets across the Internet.
RIP for IPX	Change the update mode to Standard.
SAP for IPX	Change the update mode to Standard.

IPX Demand Dial Connections

IPX-based demand dial connections have two different ways in which the IPX parameters of the connection are negotiated, corresponding to two different IPX control protocols:

IPXCP

IPX Control Protocol (IPXCP) is the Link Control Protocol (LCP) for IPX negotiation for PPP connections and is documented in RFC 1552. IPXCP is the default control protocol for IPX connections. For more information about IPXCP, see "Remote Access Server".
IPX WAN

IPX WAN is a control protocol used by Novell NetWare and compatible remote access servers and routers. Use IPX WAN when calling a Novell NetWare server or router or other router that supports the IPX WAN control protocol.

To change the IPX control protocol on a demand dial interface

Use the Routing and RAS Admin administrative tool and open IPX Routing and then click Summary.
Right-click the desired demand dial interface.
Under Dial In Control Protocol, click either IPX CP or IPX WAN and click OK.

Troubleshooting Demand Dial Routing

Remote access problems typically include the following:

On-demand connection not being made automatically.
Unable to make demand dial connection.
Unable to reach locations beyond the calling router or answering router.
Autostatic updates not working.

The following sections give troubleshooting tips to isolate the configuration or infrastructure problem causing the demand dial routing problem.

On-demand connection not being made automatically

Verify that the correct static routes exist and are configured with the appropriate demand dial interface.
Verify that the demand dial interface is not in a disabled state. To enable, right-click the demand dial interface under LAN and Demand Dial Interfaces and select Enable.

Unable to make a demand dial connection

Verify that the Routing and Remote Access Service is running on both the calling router and the answering router.
Verify that demand dial routing is enabled on both the calling router and the answering router.
Verify that the port usage on the dial-up ports being used on both the calling router and answering router are configured for Dial out and receive calls as a demand dial router.
Verify that all of the dial-up ports on both the calling router and answering router are not already connected.
Verify that the calling router and the answering router are enabled to use a common authentication method.
Verify that the calling router and the answering router are enabled to use a common encryption method.
Verify that the calling router's credentials consisting of user name, password, and domain name are correct and can be validated by the answering router.
Verify that the user account of the calling router has not been disabled or is not locked out on the properties of the user account.
Verify that account options on the User Properties tab on the properties sheet of the user account of the calling router are configured to not change the password at the next logon attempt, and that the password never expires.
If the answering router is configured to obtain IP addresses for dialin clients using a static IP address pool, verify that there are enough addresses in the pool.

If all of the addresses in the static pool have been allocated to connected demand dial routers or remote access clients, then the answering router is unable to allocate an IP address. If the calling router is only configured to route IP packets, the connection attempt is aborted.
If the answering router is configured to obtain IP addresses for dialin clients using DHCP, verify that a DHCP server is available.
Verify the configuration of the authentication provider of the answering router.

The answering router can be configured to use either Windows authentication or RADIUS to authenticate the credentials of the calling router. If RADIUS is selected, verify the RADIUS configuration of the answering router.
For RADIUS authentication, verify that the answering router computer can communicate with the RADIUS server.

Unable to reach locations beyond the calling router or answering router

Verify that the demand dial connection is not being interpreted as a remote access connection. In order for the answering router to determine that the incoming call is a router rather than remote access client, the user name of the calling router's credentials must match the name of a demand dial interface configured on the answering router.

If the incoming caller is a router, the port on which the call was received under Active Connections and Ports displays a type of Demand Dial, and the corresponding demand dial interface is in a Connected state. If the name of the calling router's user name credential appears under Active Connections and Ports with a type of Dialin Client, then the calling router has been interpreted by the answering router as a remote access client.

The user names and demand dial interface names must be properly matched. For example, demand dial connections should work under the following configuration:

Router 1 has a demand dial interface called NEW-YORK, which is configured to use SEATTLE as the user name when sending authentication credentials.

Router 2 has a demand dial interface called SEATTLE, which is configured to use NEW-YORK as the user name when sending authentication credentials.

This example assumes that the SEATTLE user name can be validated by Router 2 and the NEW-YORK user name can be validated by Router 1.
Verify that there are routes on both sides of the demand dial connection that support the two-way exchange of traffic. Unlike a remote access client connection, a demand dial connection does not automatically create a default IP route. Routes on both sides of the demand dial connection have to be created so that traffic can be routed to and from the other side of the demand dial connection.
Verify that there are routes in the intranet routers on the calling router and answering router's intranet that support the forwarding of packets between hosts on the intranets. Routes can be added to the routers of each intranet through static routes or by enabling a routing protocol on the intranet interface of the calling and answering routers.
Verify that there are no IP or IPX packet filters on the demand dial interfaces that are preventing the flow of wanted traffic. Each demand dial interface can be configured with IP and IPX input and output filters that allow you to control the exact nature of TCP/IP and IPX traffic allowed in to and out of the demand dial interface.

Autostatic updates not working

For IP autostatic updates, verify on both routers that the appropriate demand dial interface is added to the RIP routing protocol, that its operation mode is set to Autostatic update mode, and that the outgoing packet protocol is RIP version 2 multicast.
For IPX autostatic updates, verify that the desired demand dial interface on both routers is added to the RIP for IPX and SAP for IPX routing protocols and that for each routing protocol, the update mode is set to Autostatic.

Troubleshooting Tools

The following tools, which enable you to gather additional information about the source of your problem, are included with Windows NT.

Unreachability Reason

If a demand dial connection attempt fails, the demand dial interface is left in an unreachable state. A Windows NT router records the reason why the connection failed through the unreachability reason. You can troubleshoot further based on the information in the unreachability reason.

To check the unreachability reason

In the Routing and RAS Admin administrative tool, open LAN and Demand Dial Interfaces, right-click the appropriate demand dial interface.
Click Unreachability reason.

The following are some of the reasons why the demand dial interface is left in an unreachable state:

There are no more ports of the type being used by the demand dial interface.
The Routing and Remote Access service has paused.
The demand dial interface is disabled.

When a demand dial interface is configured, a port is selected. A port is a hardware or software channel that represents a single point-to-point connection. Ports are grouped by type such as analog phone ports, ISDN B-channel ports, and VPN ports such as PPTP.

While you might configure a demand dial interface to use a specific port, you are also configuring the demand dial interface to use a port type. If the specific port is not available when the connection needs to be made, the Routing and Remote Access service attempts to use another port of the same type. For example, if you have two modems and you configure a demand dial interface to use a specific modem and that modem is in use when the demand dial connection needs to be made, the calling router uses the other modem automatically.

The Routing and RAS Admin administrative tool allows you to configure more demand dial interfaces for a given port type than there are actual ports. For example, you can configure multiple demand dial interfaces that are all configured to use the same modem port. If that modem port is in use when the demand dial connection needs to be initiated and there are no other ports of that port type available, the connection attempt fails and the unreachability reason is recorded.

Event Logging

Event logging is the recording of events in the Windows NT system event log. Event logging is typically used for troubleshooting or for notifying network administrators of unusual events.

Network Monitor

Network Monitor is a packet capture and analysis tool that you can use to view the traffic sent between demand dial routers during the connection establishment process and during data transfer. Network Monitor does not interpret the compressed or encrypted portions of demand dial traffic.

The proper interpretation of the PPP connection establishment traffic with Network Monitor requires an understanding of PPP protocols described in "Remote Access Server". Network Monitor captures can be saved as files and sent to Microsoft support for analysis.

Tracing

Tracing records the sequence of programming functions called during a process to a file. Enable tracing for remote access or demand dial components and try the connection again. After you are done viewing the traced information, reset the tracing settings back to their default values.

The tracing information can be complex and very detailed. Most of the time, this information is useful only to Microsoft support professionals, or to network administrators who are very experienced with the Routing and Remote Access service. The tracing information can be saved as files and sent to Microsoft support for analysis.

For more information about the PPP log and PPP tracing, see "Remote Access Server".

Demand Dial Routing

On This Page

Introduction to Demand Dial Routing

Demand Dial Routing and Remote Access

On-Demand and Persistent Connections

Demand Dial Interface Configuration

Components of Demand Dial Routing

Demand Dial Routing Process

On-Demand Router-to-Router VPN

Testing Demand Dial Connections

Demand Dial Routing Security

Dialin Permission

Creating User Accounts with the Demand Dial Wizard

Demand Dial Routing and Routing Protocols

On-Demand Connections

Persistent Connections

IPX Demand Dial Connections

Troubleshooting Demand Dial Routing

Troubleshooting Tools

Additional resources