As remote access solutions proliferate, the companies that provide these solutions must
work harder to make their offerings stand out. In this competitive atmosphere, where
price/ port keeps falling, many remote access products attempt to distinguish themselves
by bundling services.
One company taking the bundled services route is 3Com, which offers the NETServer Plus
line. Products in this line combine remote LAN dialin access, shared dial-out access,
LAN-toLAN routing, and terminal server functions. The NETServer products are flexible and
powerful remote access servers designed for environments such as SOHO, satellite offices,
departments, and even small ISPs.
NETServer products offer 8 or 16 analog ports, and the I-modem models provide ISDN
support as well as analog on each port, automatically matching the type and speed of the
incoming calls. Add in simple and sophisticated administration, and the NETServer becomes
possibly one of the best products in the crowded SOHO remote access market. In this
review, we take a look at the NETServer 8 Plus, which is based on X2 technology and comes
with eight V.34 analog modem ports. (We should mention that the NETServer was originally
produced by U.S. Robotics; however, with the 3Com acquisition of U.S. Robotics, NETServer
became a product of 3Com’s Small Business Systems Division.)
INSTALLATION
To install NETServer, you can take one of two approaches: 1) use the Command Line
Interface (CLI) throughout or 2) use the CLI for initial setup, and the NETServer Manager
software for more advanced configuration, via a user-friendly GUI. The approach you choose
is largely a matter of taste. Some people like the ease of use of a graphical interface;
others like the unrestricted command specification of a command line interface, which can
enable faster configuration, once you get used to entering the commands.
We started by plugging the console port into a PC’s COM port. Then, we fired up
Hyper Terminal (a terminal emulator program supplied with Windows 95) to interact with the
NETServer. We then plugged analog POTS lines into two of the eight available modem jacks,
connected the NETServer to our 10BaseT network, and turned on the box.
After issuing a few boot-up messages, the NETServer indicated that it was ready for
setup. In order to use NETServer Manager, we had to make some initial configurations to
the NETServer. Using the Quick setup procedure from the CLI, we provided information on
the NETServer, network management, and IP setup (Figure 16). At this point, we installed
the NETServer Manager Plus application on a Windows NT 4.0 Workstation PC. Finally, we
installed the NCSI client on another PC on our network running Windows 95.
DOCUMENTATION
In general, the documentation was mixed, with GUI-oriented topics getting the scantiest
treatment. Fortunately, many NETServer tasks don’t require users or administrators to
rely on the NETServer Manager application. The NETServer User’s Manual and the AT
Modem Reference Guide were unexceptionable, thoroughly covering installation, setup, and
configuration, as well as procedures for remote access, network dial-in/dial-out access,
LAN-toLAN routing, addressing schemes, event messages, dial security, etc. The CLI
Reference Guide, which descr bes the NETServer CLI (Command Line Interface), was accurate
and complete; however, it could have been even better, if only it had included examples
for some of the more complicated commands. We should note that the NETServer CLI also had
online help. While it wasn’t as extensive as we had hoped, it was enough to help us
with command syntax.
The documentation for the administration software and the client software was
disappointing. For example, to install and configure the NETServer Manager (GUI
application to administer NETServer), we relied on NETServer’s Getting Started manual
(which covered NETServer Manager but briefly), as well as online help (insufficiently
detailed), and contextsensitive help (not very useful).
To set up a Windows 95 client for dial-out access, we had to rely on the NETServer
User’s Manual, since the Network Communications Services Interface (NCSI) Client
lacked its own, separate documentation. There was, however, a short text file accompanying
the NCSI client files, but no online help for the NCSI Client and its supporting
applications.
FEATURES
Basic Services
- Network dial-in access. (Remote IP, IPX, or AppleTalk clients can dial into the
NETServer and attach to the LAN. NETServer offers access security and dial-back
capabilities with the dial-in functionality.)
- Network dial-out access. (Individual PCs can access the LAN via designated
NETServer modems. A PC can connect to the Internet through an ISP, send faxes, or connect
to other networks over a dial-up PPP connection. To the PC, the modem appears to be
locally attached.)
- LAN-to-LAN routing. (Two NETServers on different LANs can establish a dial-up
connection and, using their routing capabilities, pass network traffic between the LANs.
Dial-up routing methods include manual, on-demand, timed, and continuous. Various routing
and protocol parameters are supported, and additional connections can be used to realize
larger bandwidths.)
- IP terminal service. (The NETServer can provide dumb terminals, or terminal
emulation applications with host connections. This service utilizes Telnet, Rlogin, or
ClearTCP protocols, bi-directionally converting these protocols into ASCII data streams.)
Modem/Port Sharing
- Modem sharing allows users on a local-area network to dial out through the
NETServer’s modems.
- Dynamic sharing (on a call-bycall basis) of ports between remote LAN dial access,
LAN-to-LAN routing, and terminal server functions.
Setups/Updates
- Quick and easy setup via the NETStarter autoconfiguration Wizard.
- Software downloadable Flash ROM, including modem updates from the support Web site.
Standards
- Support for 56 Kbps X2 modem technology.
- Support for V.everything modem technology, including support for the ITU-T V.34 standard
(33.6 Kbps and 28.8 Kbps).
- Support for packet transmission protocols such as PPP, SLIP, and ARAP.
- Support for the RADIUS protocol, which provides for centralized user authentication
(used with industrystandard security servers).
Administration/Management
- Access security for dial-in user authentication.
- Call accounting by department or user.
- Common management from any location, local or remote.
OPERATIONAL TESTING
After we configured the system, we tested the dial-in and dial-out capabilities and the IP
terminal service. We didn’t test the LAN-to-LAN routing, but we discuss it below, as
well as remote administration.
Basic Setup
To establish a basic configuration for the NETServer, we used the setup wizard.
By inspecting the wizard, we saw how we could accommodate various types of users,
including dial-in users that would need to access the Internet through the NETServer,
users that would need remote access to the network, and users that would need direct
dial-in connections to a host computer (terminal service).
Our actual use of the wizard was limited to checking on our global settings. When we
clicked on the Global key, a screen came up showing various parameters, including IP and
IPX settings and DNS (Domain Name Service) information.
To set up dial-in and dial-out connections, we launched NETServer Manager, an
application that let us interface with the NETServer and configure the system through a
GUI instead of a command line. (Incidentally, NETServer Manager, which uses SNMP, lets you
administer all the NETServers you may have on your network.) Changes made through
NETServer Manager can be saved to a local file or to the NETServer’s Flash ROM for
immediate system reconfiguration. Several configurations can be saved under different
local files, which can be accessed at any time and pushed onto the NETServer.
Modem Groups
With NETServer, you can designate pools of modems (modem groups) for dial-out
service, which has the advantage of making all the modems in the group available to
dial-out users. We were able to quickly add a new modem group from the modems screen.
Adding Users
NETServer can accommodate various types of users. User classifications include:
Login (remote dial-in users requesting terminal service from an IP host using Telnet,
Rlogin, or ClearTCP); Network (remote dialin users wishing to become a node on the LAN);
Callback (remote users who dial into the system, are disconnected, and are called back
using a pre-defined telephone number); Dial Out (users authorized to use the available
modems on the NETServer to dial-out to remote servers); Manage (users with administration
privileges).
We added a few users for Login and Network services, specifying Telnet for the Login
service and PPP for the Network service (Figure 18). We noticed that Network service could
be extended to an individual or to an entire network.
Dial-In Service From a Windows 95 machine on our network, we dialed into one of the
available modems, specifying a user account and password that we had established on the
NETServer. The dial-up process started, but the connection failed. Thinking that the
problem was with the user account or password, we dou-blechecked these parameters, but
they were fine. Next, we tried several different configurations using the CLI and the
NETServer Manager. No luck. At this point, we called technical support. We have to say the
support engineer wasn’t all that helpful, although we were impressed he was able to
log into our system through an available port. The engineer told us the system was
configured correctly, and he gave us a few options to try. None of them worked.
Frustrated, we called technical support again, and this time we received excellent
help. Apparently, in our haste to make things work, we had created a messy configuration.
We decided to start over. Using the CLI, we easily deleted the existing configuration and
reconstructed the system configuration in no time.
It soon became obvious to us that once the CLI is mastered, it provides for a much
faster and cleaner way to configure the system than NETServer Manager. Moreover, unless
there is an SNMP access to the NETServer, the only way to administer the system is through
CLI. In our LAN, we have a Windows NT server configured to hand out IP addresses using
DHCP (Dynamic Host Control Protocol) when nodes come online. When we found that we
couldn’t use our DHCP server, we set up a pool of IP addresses on the NETServer. IP
addresses were assigned from this pool to the incoming nodes.
Finally, we configured our Windows 95 machine, which we had set up with DUN (Dial-Up
Networking), to use DHCP for WINS (Windows Internet Name Service) resolution. Since we did
not have WINS running on our network, this was a work-around for the incoming Windows 95
node to be able to browse our LAN. We tested our connection again, and this time
everything worked perfectly. We were authenticated by our Windows NT domain (just like
other nodes on our LAN), and we successfully attached to our network.
An easy way to provide dial-in services for several people using the NETServer is to
set up the system with the necessary accounts and hook up a sufficient number of modems to
telephone lines with rollover capability. Then, all the users would use the same number to
dial into the NETServer. Each successive user would be connected to the first available
modem. (You can probably see how a small ISP could serve its clients using
NETServer’s dial-in service.)
NETServer’s dial-in access feature resembles RAS (Remote Access Service, available
on Windows NT), but it is much more flexible. For starters, the NETServer comes with
integrated modems, whereas a RAS connection via a Windows NT server must be outfitted with
modems. In addition, NETServer supports multiple protocols, and it relieves other servers
from having to perform remote access services. Finally, NETServer connections can be used
for other purposes, such as dial-out services.
Dial-Out Service
To set up our NETServer to provide dial-out service to clients, we had to
configure it with the Dial Out service, and we had to associate the service with a modem
group or pool. We carried out these tasks with the CLI, since we had become familiar with
it by then. Then, just for fun, we verified the setup with the NETServer Manager
application.
The next step was to configure the NCSI (Network Communications Services Interface)
client application for our Windows 95 client. The NCSI client application, which comes in
three flavors (DOS, Windows 3.x, and Windows 95), allows clients to dial out via NETServer
modems as if the modems were local to the client systems. Thus, NCSI saves you the trouble
of purchasing, installing, and maintaining modems and telephone lines for all users; that
is, you can assign a pool of modems to multiple users. (When a user requires a modem
connection, a modem is automatically allocated. When the user is finished with the
connection, the modem is returned to the pool, and becomes available for the next user.)
To configure our Windows 95 NCSI client, we used the Add New Hardware applet of the
Control Panel, adding an NCSI Shared Port, which appeared as COM4 on Windows 95. Then,
using the NCSI Port Setup program, we assigned the new COM4 to the available modem pool on
the NETServer. This was easy, since the Port Setup application automatically detected the
available modem pool on the NETServer and presented it to us as an option.
In Windows 95, we specified that COM4 was connected to a standard modem. Our Windows 95
machine was now fooled into believing that this modem was locally installed. We set up a
dial-up networking configuration to connect to our favorite ISP using the new (remote)
modem and successfully made the connection.
IP Terminal Service
With this service, dumb terminals or terminal emulators can gain access to hosts
over network protocols such as Telnet or Rlogin. Using the CLI, we set up one of the users
for Login access with Telnet service (which is the default connection method). Then, we
completed the configuration by adding our target host name and its IP address to the
NETServer, designating this machine as the default host.
To test the service, we used a terminal emulator application on a remote machine to
dial into the NETServer. Upon entering our account and password, we were granted entry
into the NETServer. From there, we specified the Telnet command, which connected us
directly to our host. We really liked the ease and effectiveness of setting up the IP
terminal service on the NETServer.
LAN-To-LAN Routing
Unfortunately, we didn’t test NETServer’s LAN-to-LAN routing
capabilities. We did notice, however, that network traffic between facilities can be
routed over dial-up connections established between NETServer systems. In such a scenario,
one NETServer dials up another NETServer and logs in as a user, creating a
NETServer-to-NETServer connection. The NETServer supports static routing as well as
dynamic routing using protocols such as RIP and RTMP. Advanced packet filtering is also
provided by the NETServer to provide optimum performance and a high degree of security.
Remote Administration
Once a Manage account has been set up on the system, an administrator can dial in
on any available port. Then, using the CLI, the administrator can gain complete control
over the NETServer.
CONCLUSION
We found the NETServer Plus an indispensable tool for providing remote access to the
office. A capable, flexible, and versatile system, NETServer Plus offers an integrated
solution to many SOHO network and terminal access needs. The NETServer is perfect for
small service providers, small and medi-umsize companies and departments, satellite
offices, and home offices requiring advanced networking access.
Once we climbed the initial learning curve, we found the system easy to install,
configure, and maintain. We do, however, hope that 3Com will provide a more robust and
intuitive NETServer Manager GUI program, as well as improved documentation and online help
for the NETServer Manager and the NCSI client application. We should mention that we
really liked 3Com’s support Web site, which is named TOTALservice ( totalservice.usr.com ). This site offers a lot of
valuable information on the NETServer and other 3Com products. Typical Web site contents
include the latest code, documentation, and frequently asked questions. |
Internet Telephony Magazine
Click here to read latest issue
CUSTOMER 
Cloud Computing Magazine
Click here to read latest issue
IoT EVOLUTION MAGAZINE
