The Demand-dial Connection Process
Applies To: Windows Server 2008, Windows Server 2008 R2
This topic describes the demand-dial process as it applies to the scenario described in Demand-dial Routing Example in this guide.
When the user at 172.16.1.10 tries to connect to a resource at 172.16.2.20, the following events occur:
Because the client computer has Router 1 as its default gateway, packets from 172.16.1.10 destined for 172.16.2.20 are forwarded to Router 1.
Router 1 receives the packet from 172.16.1.10 and checks its routing table. A route to 172.16.2.20 is found that uses the DD_NewYork interface.
Router 1 checks the state of the DD_NewYork interface and finds it is in a disconnected state.
Router 1 retrieves the configuration of the DD_NewYork demand-dial interface.
Based on the DD_NewYork configuration, Router 1 uses the modem on COM1 to dial the number 555-0122.
Router 2 answers the incoming call.
Router 2 requests authentication credentials from the incoming caller.
Router 1 sends the user name DD_Seattle with its associated password.
Upon receipt of the authentication credentials, Router 2 checks the user name and password against the security features of Windows Server and verifies that Router 1 has dial-in permission through the dial-in properties of the DD_Seattle user account and the configured remote access network policies.
Router 2 must now determine whether the incoming caller is a dial-up networking client or a router that is creating a demand-dial connection. In its list of demand-dial interfaces, Router 2 finds a demand-dial interface DD_Seattle that matches the user name credential.
Router 2 changes the state of the DD_Seattle demand-dial interface to a connected state.
Router 1 forwards the packet from the computer at 172.16.1.10 across the demand-dial connection to Router 2.
Router 2 receives the packet and forwards it to the computer at 172.16.2.20.
Because the client has Router 2 as its default gateway, the response to the connection request from the computer at 172.16.1.10 is forwarded to Router 2 by the computer at 172.16.2.20.
Router 2 receives the packet destined for 172.16.1.10 and checks its routing table. A route to 172.16.1.10 is found by using the DD_Seattle interface.
Router 2 checks the state of the DD_Seattle interface and finds it is in a connected state.
Router 2 forwards the packet to Router 1.
Router 1 forwards the packet to the computer at 172.16.1.10.
If the user name credential does not match the name of an appropriate demand-dial interface, the calling entity is identified as a remote access client, which can result in routing problems.
For example, if Router 1 uses DialUpRouter1 as its user name credential, then Router 1 is identified as a remote access client rather than a router (assuming DialUpRouter1 is a valid account with dial-in permissions). Packets are routed from the user at 172.16.1.10 to the user at 172.16.2.20 as described in the preceding process.
However, response packets from 172.16.2.20 to 172.16.1.10 are forwarded to Router 2 which, upon inspecting its routing table, determines that the interface to use is DD_Seattle. DD_Seattle is in a disconnected state. Based on the configuration for DD_Seattle, COM2 is to be used. However, COM2 is currently being used for a remote access client (Router 2). Router 2 then tries to locate another modem that is not being used. If found, Router 2 dials Router 1 and forwards the packet after the connection has been established. If another modem cannot be found, the response packets from 172.16.2.20 to 172.16.1.10 are dropped.