Demand-Dial Routing Process

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

  1. Upon receipt of a packet, the calling router finds the best route to forward the packet.

  2. 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 with instructions to bring up the demand-dial interface in the route.

  3. The Dynamic Interface Manager checks the dial-out hours and demand-dial filters configured on the interface. If dial-out hours or demand-dial filters prohibit the initiation of the demand-dial connection, the connection attempt is terminated and the Unreachability reason on the interface is set. For more information about the unreachability reason, see "Troubleshooting Tools" later in this chapter.

  4. If the demand-dial connection is allowed, the Dynamic Interface Manager retrieves the configuration of the indicated demand-dial interface from SystemRoot \system32\ras\router.pbk.

  5. 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 either a PPTP tunnel (for PPTP connections) or an IPSec security association and an L2TP tunnel (for L2TP over IPSec connections).

  6. 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.

    • If the calling router is configured with the IP addresses of Domain Name System (DNS) or Windows Internet Name Service(WINS) servers, then DNS and WINS server IP addresses are not requested. If the calling router is not configured with the IP addresses of DNS and WINS servers, then DNS and WINS servers are requested. The answering router never requests DNS and WINS server IP addresses from the calling router.

    • Unlike Windows 2000 remote access clients, the calling router does not create a default route or send a DHCPINFORM message to the answering router. By default, the calling router does not register itself with the DNS or WINS servers of the answering router unless the RegisterRoutersWithNameServers registry value (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman \PPP\ControlProtocols\BuiltIn) is set to 1.

  7. 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 and local remote access policies to accept the connection.

    • Sends the connection attributes to a configured RADIUS server. If the RADIUS server is a Windows 2000 Internet Authentication Service (IAS) server, it checks the appropriate user account database and remote access policies to accept the connection.

  8. If the user account of the calling router has static routes configured, those routes become static routes in the IP routing table of the answering router.

  9. 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.

  10. 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. If there are no static routes configured on the user account, you might have 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.