Condividi tramite

The demand-dial connection process

  • Articolo

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

The demand-dial connection process

When the user at 172.16.1.10 tries to connect to a resource at 172.16.2.20, the following events occur:

  1. Packets from 172.16.1.10 destined for 172.16.2.20 are forwarded to Router 1.

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

  3. Router 1 checks the state of the DD_NewYork interface and finds it is in a disconnected state.

  4. Router 1 retrieves the configuration of the DD_NewYork demand-dial interface.

  5. Based on the DD_NewYork configuration, Router 1 uses the modem on COM1 to dial the number 555-0122.

  6. Router 2 answers the incoming call.

  7. Router 2 requests authentication credentials from the incoming caller.

  8. Router 1 sends the user name DD_Seattle with its associated password.

  9. Upon receipt of the authentication credentials, Router 2 checks the user name and password against the security features of the Windows Server 2003 family 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 policies.

  10. 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. Router 2 looks in its list of demand-dial interfaces to find one that matches the user name sent by Router 1 as part of the authentication credentials. Router 2 finds a demand-dial interface DD_Seattle that matches the user name credential.

  11. Router 2 changes the state of the DD_Seattle demand-dial interface to a connected state.

  12. Router 1 forwards the packet from the computer at 172.16.1.10 across the demand-dial connection to Router 2.

  13. Router 2 receives the packet and forwards it to the computer at 172.16.2.20.

  14. The response to the connection request by the computer at 172.16.1.10 is forwarded to Router 2 by the computer at 172.16.2.20.

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

  16. Router 2 checks the state of the DD_Seattle interface and finds it is in a connected state.

  17. Router 2 forwards the packet to Router 1.

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