Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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.