|Previous||Table of Contents||Next|
The concept of remote control has been a powerful tool for diagnostics and troubleshooting for years. Under remote control, a machine is operated from a remote location. Everything that can be done locally on the machine is available to the remote user via the application. (PCAnyWhere is one popular remote-control solution.) As a result, technical support staff have been able to use this resource to fix workstation problemsa solution much more efficient than the please click on the button and tell me what it says approach, which requires training in addition to research and troubleshooting.
For the network designer deploying a remote access solution, the process is reversed. The host machine is located in the data center and typically contains a fixed configuration that provides access to most of the applications that would be available to local users on a local workstation. This configuration is sometimes used with thin-client deployments as well. A thin-client is a workstation that relies on a server for most processing; applications on a thin-client are typically very small as well. A fat-client maintains more of the processing and servicing on the workstation.
For remote users, this solution offers some powerful advantages. First, the configuration and support issues are virtually limited to the server system. The remote user need only be concerned with the remote-control client. Second, the remote user can access all of the applications that are available on the host without installing the application. Third, performance for some applications is increased with remote control. For example, consider a large database query. This might require the transfer of 10 megabytes of data across the phone line. Remote-control solutions would limit the data flow to a screenful of data at a timea fraction of that figure.
All of these advantages cannot be without disadvantages. The most significant is that users must be connected to the remote-control host to access applications and data. So a worker using remote control for eight hours a day pays for a connection for the full eight-hour day. The modem and other equipment at the hosting site are also reserved for that user. In addition, performance is limited to the speed of the connection and the compression provided by the hosting application. The host computers memory and CPU capacity will also limit the performance of remote-control sessions.
Another consideration for remote-control solutions is the lack of offline availability. Many workers need to work while traveling on airplanes or busses, and while wireless solutions exist, they are expensive and unreliable. If the remote-access user will be mobile part of the time, the remote-control solution requires greater scrutiny.
It would be nice to allow remote users the same on-LAN service that they have in the office, and remote-node technology allows exactly that. Although remote-node technology is slower, remote users must connect as a remote node only when transferring data. Under all other circumstances, they can operate with the applications and data stored on their local workstation. This situation introduces support issues that did not exist with remote-control and remote-gateway solutions, but it also makes the service scalable.
Under remote control, a user would need to connect to the server for eight hours a day to be productive. With a remote node connecting only for data transfer, this time could be cut to perhaps less than 15 minutes per daylong enough to transfer a few files and capture e-mail five or six times. In theory, then, the single connection could support 32 users. To illustrate, consider Table 9.1. Designers can make use of the fact that users are not concurrent (a measure of simultaneous users) to oversubscribe the modem pool. As shown, 32 users at 15 minutes can be serviced with four circuits, or 640 users can be supported with 80 circuits at an oversubscription rate of 8:1, which is still double the average concurrent usage figure.
This clearly reduces the costs associated with remote access. Because the LAN connection is slowthe workstation thinks that the modem is a LAN adapterapplications and other static data should be stored locally.
Remote-node solutions are sometimes considered more secure than other remote-access methods, and Cisco supports this position. However, once a node connects, it is capable of running any software on the client workstation, including hacking tools and other applications that may not adhere to corporate policy. Remote gateways, by serving a single function, and remote-control hosts, by placing applications under administrative control, may be more secure solutions.
Given the flexibility of remote-node solutions and the scalability afforded by them, most designers in modern remote solutions will opt for this solution first. If remote control is necessary, it can be combined with remote node by simply attaching to the remote-control host over the network session established as a node. This hybrid solution can provide the bandwidth savings sometimes available with remote control without making it the only connection method.
So far, this chapter has merely touched upon remote users and their needs. However, it is important to expand upon their requirements. After all, the entire reason to deploy remote access is to provide services to users.
Remote users typically fall into one of three general categories:
Cisco recommends different hardware solutions for each of these categories; however, all are predicated on the deployment of remote-node solutions. Lets look at the various hardware solutions.
Cisco recommends the use of its 2509/2511 series routers for small user pools. This solution would address the needs of eight to 16 users and use external modems to provide a modem bank. Note that this solution is analog, which means that v.90/56k is not supported. This will limit users to 28.8 or 33.6Kbps.
Cisco positions its 760/770 ISDN router platform for the remote user operating from a fixed location. This solution incorporates ISDN, which may significantly add to the access costs; however, it also provides greater bandwidth than a dial-up solution. As of this writing, it appears that Cisco is departing from the 760/770 platform in favor of newer 800 series systems. For actual deployments, designers should consult with their local Cisco representative.
|Previous||Table of Contents||Next|