Timothy
Parker Consulting Incorporated
|
|
|
|
More RAS calculations Last column we looked at the overall issues that we need to consider when setting up a remote access server (RAS) for dial-in to a corporate network or server. One of the fundamental decisions we mentioned last month is the number of lines that the RAS has to support. There are three categories that can be considered: those with only a few lines (three or four lines maximum), those with up to 16 lines maximum, and the expandable system with many more lines available. In general, if you purchase a system that has three or four lines available expanding to more lines means buying a completely new unit as a supplement to the existing one. For those RAS units with up to 16 ports, you can use any combination of those ports for modems or any other serial devices. Going beyond 16 ports again means buying another box. The expandable system is usually a rack-like box that has slide-in trays with multiple ports per tray. Start with 16 ports, for example, and when you need more just add another 16-port expansion unit. Some subsystems allow well over one hundred ports. Naturally, these rack-like units have a higher initial cost than a dedicated 16 port RAS, but when more ports are added the per-port costs drop. The second fundamental decision (which is sometimes solved by your choice of the size of unit) is whether the RAS unit will be network-based or connected directly to the server. A network-based RAS unit is a stand-alone chassis that uses a network connector to talk to the server or any other machine on the network. A server-connected unit is a more traditional approach wherein an umbilical cord attaches from a plug-in board to the RAS break-out box, controlled by the server directly. (This is really one of the traditional multi-port serial cards retuned for RAS use.) Server-controlled RAS units impose more server load than network-based units as the server has to field all requests, whether for the server or some other machine on the network. On the other hand, network-based units impose more network traffic, so if the network is already pushed to capacity adding the network-based RAS can cause real problems. Server-controlled units are less expensive (on the whole) than network-based units, but network-based units are more autonomous in case of server problems. My advice? All else being equal, go for a network-based unit. Having said all that, let's look at some concrete examples. We'll start with the smallest RAS systems with three or four ports. One of the more sensible units I've tested is the Multitech RASFinder 200. This is a slightly-larger than normal external modem case that has three K56Flex modems embedded in the same chassis. The RASFinder 200 has both BNC and RJ-45 network ports on the back panel to connect to the network. Controlling software for the unit is designed for Windows systems (both Windows 95/98 and Windows NT work the same). To date there are no dedicated UNIX drivers for the system. The RASFinder 200 has one advantage over most other RAS systems: it works with IPX/SPX as well as TCP/IP (most RAS network units are TCP/IP only). This lets you use it for many NetWare, UNIX, and Windows networks equally. The RASFinder 200 is configured through a connection to a COM port on the Windows machine with the setup software. The COM port is used only for configuration, not RAS use. The software is straight-forward, allowing you to set dial-in and dial-out access to each of the three modems in a number of ways. Every user who is going to dial in to the RASFinder 200 has to have an entry in the server's remote user database. Each name and an optional password has to be added separately through the configuration software, as there is no import facility for pulling users from the NT User Manager. IP addresses for each port are assigned, and the unit is up and running after ten minutes. Client software is not required, as any package capable of PPP or SLIP works fine (which includes Windows' Dial-Up Networking). Since the RASFinder 200 has three modems built in, there's nothing extra to buy or cable with the unit. As a standard-alone RAS subsystem it has a lot going for it. For example, call backs are supported either in security mode (where the system administrator specifies the call back number for each user) or the user can enter their call-back number themselves before the RASFinder 200 terminates the session. Call backs (the modem dials the user back instead of connecting right away from the remote location) are an excellent way to cut remote access telephone charges and implement better security. The only downside to the RASFinder 200 is that it is limited to three modems. Need more ports? You must buy another RASFinder 200, expanding in multiples of three. Since it's unlikely the K56Flex standard will be superseded in the next few years, there's no obsoleteness issue to worry about. On the other hand, you need a completely separate subsystem for faster-than-analog connections. A version of the RASFinder 200 is available which acts as a proxy server, allowing multiple Internet users to share the same phone connections. The cost of the RASFinder 200 is quite high if you consider it as three modems in a single case, and compared to a 16-port RAS unit with 16 analog external modems it's much more expensive to buy six RASFinder 200s, but if all your client needs is three or less ports this may be the easiest way. I was impressed during my trials of the RASFinder 200 and definitely recommend it as a starting RAS. Next column, we move up to the 16-port units, both network-based and server-connected. Call back then. |
|
Send mail to
tparker@tpci.com with
questions or comments about this web site.
|