12/15/97 Network Computing 116
1997 WL 8749676
Network Computing
Copyright 1997 CMP Publications Inc.
Monday, December 15, 1997
822
Reviews
Smokin' Remote Access Pushed To The Max: Part II
Mike Fratto
This past March, we tested remote-access servers (see "Remote-Access
Servers Pushed to Their Limits,"
www.NetworkComputing.com/805/805f1.html). In that instance, servers from
Ascend Communications, Cisco Systems, Microcom (recently purchased by
Compaq Computer Corp.), Shiva Corp., 3Com Corp. and U.S. Robotics
(recently purchased by 3Com) were pushed to the max.
For the many vendors that were in the middle of product cycles and
could not participate in that earlier roundup, we offer this sequel. The
six vendors from the first test were invited to participate again if
their products underwent major upgrades, or if they had released new
products since our last test (minor revisions or bug fixes did not
count). Of the original players, only Ascend joined us again.
As in the first roundup, we tested remote-access servers capable of
handling at least two T1 (48 channels, 46 for PRI) connections (four T1
were preferred) and able to negotiate PPP and IP/IPX. Access Beyond's
AB4400 Remote Access Server, Advanced Computer Communications' Tigris
Integrated Access Platform, Ascend Communications' MAX 4048, Bay
Networks' Model 5399 Remote Access Concentrator, Cabletron Systems'
CSX7000, Gandalf's Xpressway RLAN, General DataComm's SpectraComm RLN
and Multi-Tech Systems' CommPlete Communication Server were tested.
With the exception of identifying the best and worst servers, rating
the devices was difficult because each vendor offered a little
something different than the others. 3Com's AccessBuilder 5000, with
superior performance, flexibility and accounting, retains its title from
our first round of testing.
Not too far behind, Access Beyond's AB4400 and the Compaq Microcom
Access Integrator share second place. The units from Shiva, Cisco and
Bay Networks are close on their heels.
Access Beyond AB4400 Remote Access Server
Access Beyond's AB4400 is the top finisher in this roundup, tying for
second place overall behind 3Com's AccessBuilder 5000. It offers high
throughput, excellent diagnostic tools and easy-to-use management and
installation features, and it works extremely well as a medium-sized
solution when PPP connectivity is needed for remote users. However, the
AB4400 isn't as flexible as the servers from 3Com or Microcom. It lacks
LAN-to-LAN routing and Multilink PPP support, and it does not have as
high a port density as some of the others.
On the outside, the AB4400 looks like a desktop PC. Inside the box,
though, lies a modular architecture designed for custom configurations.
It maximizes throughput by off-loading processing from the CPU to
separate intelligent I/O boards. Routine PPP processing, for example, is
handled on the port modules and packets flow through the device without
processing from the CPU. This is a remote-access server that can push
data from the WAN to the LAN with little degradation. IP and IPX
transfer times rivaled those from Bay Networks' unit and-with the
exception of ZIP file performance over IPX-blew away the rest of the
pack.
Access Beyond's diagnostic tools were second to none, and only the
Cisco AS5200 offered a higher level of detail in traces. Using the
terminal screen, via telnet or through an RS-232 connection to the
console port, you can dig deep into call tracing from Layer 1 up to
Layer 3 of the protocol stack. This could be very beneficial for you
when you're setting up the AB4400. Additionally, with the AB4400 we were
able to verify the operation of our test bed from the server side by
looking at the T1 A/B signaling bits up to the IP negotiations within
PPP.
We did have initial problems setting up more than 16 calls connected
simultaneously. Access Beyond located a limitation in the AB4400's hash
table, which maintains the port IP addresses: It could hold only 16
addresses per Class B subnet. The code was recompiled, allowing for a
larger range of addresses, and the connections ran well. Access Beyond
states that this will be fixed and will appear in the next release of
the code base.
Server installation and management of AB4400 is relatively
straightforward. Both the GUI and the terminal interface are
well-thought-out, and important functions are placed where they are
needed.
Bay Networks Model 5399 Remote Access Concentrator
Bay Networks' Model 5399 scored well largely because of excellent
performance and its flexibility-it accepts a range of cards in the
chassis. The Model 5000 chassis isn't strictly a remote-access server;
rather, it's a network-access concentrator capable of ATM, shared and
switched Ethernet, FDDI, remote access and more. Our tests used two 5399
remote-access servers with integrated T1/PRI and 48 modems per card.
Network connectivity was accomplished through a 5308P Ethernet host
10-Mbps card.
To drive the 5399s, you need a Windows NT or a Unix server that can
host boot images, configuration files and other tools necessary for the
proper boot-up and management of the server. When booting, the 5399s
look to the 5000 management module and obtain their IP address and the
network address of the configuration server. The 5399 Remote Access
Concentrator then contacts the configuration server and obtains other
details. The information is stored as text files, which are created by
hand or with the Q2Config management GUI. In the absence of a
configuration server, the 5399 configures itself to factory defaults. We
encountered a few problems when using the Q2Config GUI, such as an
inability to configure the T1 ports. Bay Networks is aware of these
problems and says it will address them in a future release.
In terms of performance, Bay Networks' server kept pace with the top
winners, largely because of its multiprocessor architecture. Each card
is populated with three Intel 486 DX2/33 processors: one main processor
and two processors for I/O. The I/O processors have 4 MB of RAM-for both
the code and memory buffering. The main CPU has 8 MB of RAM. These three
cards provide more than adequate CPU power and memory to handle packet
processing for the modems. In addition, performance is enhanced by two
daughterboards that perform data compression, relieving other processors
from that task.
Prepared for Failure Bay designed the 5399 for reliability, but all
hardware eventually fails. To prepare for the inevitable, the 5399's
modems are located on daughterboards (24 to a board). If a modem board
needs to be replaced, simply pull the 5399 out of the rack and replace
the daughterboard. New cards are automatically configured at boot time.
Since it gets its configuration information from a single location,
configuring the 5399 was a snap. We wanted both of our 5399 units
configured identically, so we made one configuration file and pointed
the two 5399s at it. We were able to make configuration changes on the
fly-but only to one 5399 at a time. Changes made after the unit is
booted won't take hold until the next reboot. However, using the
Q2Config utility, you can make changes to the server and the
configuration file simultaneously. Port-level changes can be made on the
fly.
General DataComm SpectraComm RLN
The SpectraComm RLN remote-access server is the result of a pairing
between General DataComm and Attachmate Corp.; Attachmate's Remote LAN
Node software has been redesigned to work seamlessly with General
DataComm's hardware. We found the bundled management and accounting
packages useful for organizations that don't have any accounting
servers. The software provides an extensive set of utilities to manage
both the server and your user base. But the SpectraComm hardware
supports only 64 modems, making it less scalable than Bay's Model 5399,
and more difficult to configure than Access Beyond's AB4400 or the 5399.
And even though its performance was acceptable, the SpectraComm RLN
still lagged the leaders.
The SpectraComm RLN runs on a Dell Computer Corp. OptiPlex GM5122
system and uses modem racks and a multiport serial adapter board from
Equinox for asynchronous connectivity. The server manages call control,
routing and server functionality while the Equinox modem racks handle
data I/O. Although the SpectraComm RLN can accommodate a maximum of 64
modems, two Equinox racks (supporting a single T1 each) can be chained
together for 48 modems. The remaining 16 modems, eight in each rack, can
be attached to a multiport asynchronous board in the server.
Running on DOS, the SpectraComm server requires a sparse 8 MB of RAM,
though the unit we tested shipped with 16 MB.
On the plus side, we particularly liked the range of authentication
methods SpectraComm supports. It also allows seamless management of user
authentication and profiles across multiple servers. Using a
hierarchical approach, we were able to add servers to our domains and
distribute management functions and authentication profiles from one
central location.
Getting the Bugs Out General DataComm's unit also has some
comprehensive debugging and tracing capabilities, though not as detailed
as the AB4400's. For example, while debugging connectivity problems, we
were able to track call setup and disconnect. The RLN manager offers
very detailed reporting for connection start and stop times, user names
and the amount of data sent over the link. The log file can be viewed
within the management GUI, or it can be imported into a spreadsheet for
customized reports. While reviewing the reports, we were able to tell
when calls ended prematurely (an event that occurs with all
remote-access servers), how long they were up and who was logged in.
Configuring and managing the SpectraComm server is straightforward and
flexible. Using a keyboard and monitor attached to the server, you can
quickly move through important screens during the initial installation.
You must manually define each port as a specific modem type-a task that
in practice isn't as tedious as it sounds. You can move through each
port with the cursor in the same relative position. Having a default
configuration or allowing modem grouping would make the configuration
easier.
Ascend Communications MAX 4048
The MAX 4048 is Ascend Communications' latest medium-density
remote-access unit. It performed a bit better than its predecessor, the
MAX 4004, in the areas of accounting, performance and configuration. The
newer unit has the same form factor and VT-100 interface as the MAX
4004, with one exception-it supports only two T1 lines and 48 analog
modems. In addition, the MAX 4048 has a Java-based configuration
tool-with its own Java virtual machine. The MAX 4048 showed average
performance in our testing and it offers the best overall support for
authorization and accounting facilities via RADIUS (Remote
Authentication Dial-In User Service).
Configuring the MAX 4048 was easily accomplished via its Java-based
configuration tool. After setting the basic LAN interface parameters
through the VT-100 interface, we were able to continue configuring the
unit via the GUI. Unfortunately, we had trouble getting the GUI to run
on our Microsoft Windows95 management station. After testing two
versions of the Java application, we were able to get it functioning
only on a Windows NT server. We found that to run smoothly, the applet
requires the recommended configuration of a 133-MHz Pentium, but with
more than 32 MB of RAM.
Configuring and managing the MAX 4048 takes a considerable amount of
buy-in to the Ascend mind-set. Configuring dial-in users, for example,
is a two-step process where you must first create a user profile and
then attach users who are associated with the profile. This process is
tiresome and not nearly as versatile as the solutions offered by Access
Beyond's AB4400 or the SpectraComm RLN.
Once the MAX 4048 was configured properly, we faced the task of user
setup. Here is where the Ascend product really shines. Offering extreme
flexibility, the MAX 4048 lets you make minute changes to user
connectivity options through RADIUS. Nearly all network access,
authorization and accounting functionality is supported in the MAX 4048.
For example, after we set up a remote client profile using Funk
Software's Steel-Belted Radius user-authentication software, we were
able to quickly make broad changes to our user parameters, including
setting the idle time-out and authentication method.
Many of the parameters, such as call setup, PPP link control and
network access, could be assigned through Ascend's proprietary RADIUS
extensions. This also eliminates the need to make separate profiles on
each device and allows centralized management of users.
Gandalf Xpressway RLAN
Gandalf's Xpressway RLAN got off to a rough start in our tests because
of some hardware problems and a few issues with the management system.
But once the unit was up, our tests ran smoothly. Throughput was average
for IP performance and just above average for IPX. However, we found the
management GUI in Xpressway RLAN lacking and the VT-100 interface
difficult to use.
To maximize performance, we configured the chassis with two separate
backplane segments; each with its own controller card, T1 card and
digital modem cards. With its modular design, Gandalf's Xpressway RLAN
can handle a variety of cards. Each segment in our configuration had a
RAC9000e controller, a PRI 9346 T1/PRI card and two MRM (Modem Resource
Module) 9340 modem cards. We attached each segment to the LAN via the
RJ-45 connector located on the front of the RAC9000e rather than
shuttling the traffic over the backplane.
Although the terminal interface performs some real-time monitoring of
the Xpressway RLAN, only a few debugging utilities are available to the
administrator. This makes installation and maintenance difficult. For
example, during the initial installation we had trouble configuring the
T1 lines. Our Adtran CSU (the Xpressway doesn't have one built in) and
the Madge Teleos switch showed "Out of Frame" errors-a red alarm-while
the Xpressway showed nothing. Thus began several hours of painful
troubleshooting. We eventually tracked the problem to a faulty RAC9000e
controller card.
We configured Xpressway RLAN via the RS-232 console port of the
RAC9000e because of a problem we encountered with Gandalf's telnet
terminal-it doesn't play well with Microsoft's telnet client. The
application engineer at Gandalf suggested we try a shareware telnet
client. We were unable to test the Xpressview Central GUI because of a
known bug, which would inform us that our configuration had been deleted
when we attempted to set it. Gandalf is aware of this problem and says
it's working on a fix for its next release.
Cabletron Systems CSX7000
Cabletron Systems' CSX7000 uses a Cubix Corp. chassis to house
separate PC subsystems along with the requisite modems and WAN cards.
But at $75,775 when configured with 96 modems, the CSX7000 is the most
expensive unit we tested. Add $4,995 for the management station
software, an NT server and a SQL server, and you end up with a fairly
steep price to pay for average performance and less-than-simple
configuration and management. However, the CSX7000 was the most stable
server in the bunch. It connected every call-on the first try-and didn't
drop a single one during any of our testing; these claims can't be made
for any other remote-access server in this roundup.
You can configure the CSX7000 in two ways, depending on your goals.
Both methods are terminal based-the static management application on
the CSX7000 lets you configure the remote-access server and the hardware
on the Cubix box. Once you've made the appropriate changes with the
static console, you must reboot the box. For other management and
configuration tasks, you can use an interactive manager that makes
changes to the server on the fly.
Cabletron's static editor is menu-driven, and configurations can take
you several layers deep. For example, while configuring users on the
CSX7000, we found that it takes no less than four separate menu choices.
Adding users to the system quickly became monotonous. The interactive
configuration utility is command-line-driven, with menus appearing as
commands are entered. The interactive systems are fairly easy to
navigate and can be accessed via a telnet session for remote management.
Because the CSX7000 is built atop Cubix hardware, installation of
additional hardware is an exercise in patience. We found that it is
quite easy to misconfigure the physical resources of the device-to the
point that it won't communicate or provide any indication of the error.
Multi-Tech Systems CommPlete Communications Server
The CommPlete Communications Server was a disappointment because of
random hardware problems and a lack of a common management system.
CommPlete's performance was average, but its management GUI, the Multi
Modem Manager, offered little value other than occasionally showing
modem status.
Inside the chassis are four independent DOS-based computers running
RASExpress remote-access server and its associated modem hardware. The
modem modules are connected to a common backplane and can attach to your
network through a central shared hub. We experienced several
hardware-related problems, such as fatal errors, when attempting to
configure the 13th modem connection. In addition, during our throughput
tests, the server stalled when trying to find its devices. Multi-Tech is
aware of these boot failures and says they stem from a modem problem;
the modem card fails to load and the RASExpress dies on the next modem
card load. Multi-Tech says it thought this issue was fixed. However, we
received two modem cards that suffered from this problem.
Configuring and managing the CommPlete Communications Server is a
chore because of a lack of a common management scheme. Every module is
isolated; to initiate change you must attach to servers individually,
either through the console port or via telnet. After all the time and
energy spent configuring the server, the CommPlete Communications Server
yielded average performance.
Advanced Computer Communications Tigris Integrated Access Platform
"Not ready for prime time" is the phrase that best describes this
remote-access server. Lacking in management, acceptable throughput and
stability, Advanced Computer Communications (ACC)'s Tigris fell to the
bottom of this roundup.
We uncovered several problems with the Tigris during our testing that
simply should not be found in a shipping product. The Tigris failed to
identify misconfigured compression packets and subsequently failed to
stop attempting CCP compression or drop the connection. The result was
garbage across the link. Once we resumed testing, results were still
alarmingly slow. After another call to ACC, we learned that there was a
problem in the V.42 compression scheme and that turning it off would
improve performance. We did note an improvement in performance, but it
was still double the average of the other servers. ACC states that there
is a problem with a low-level driver that forwards packets from the
modems to the network stack. If a connection is up for longer than 10 to
15 minutes, the driver would choke and stop passing data. Another
firmware fix was issued, but the sluggish throughput remained. At the
time we went to press, ACC said it was still working on the problem.
ACC's command-line interface and its cryptic commands left us
scratching our heads on more than one occasion. On a more positive note,
however, we did receive an early look at a the company's RiverView SNMP
management product. RiverView, which is designed for the Tigris, will
run with CastleRock's SNMPc application, the company says. It shows much
promise and will greatly facilitate easier configuration and management.
Mike Fratto can be reached at mfratto@nwc.com.
SIDEBAR: Testing Enterprise Remote Access
Although we tested only analog connections, most of the servers can
handle both analog and ISDN PRI simultaneously.
Our performance testing was designed specifically to stress servers
with a constant stream of traffic-down to each of the 96 simultaneous
ports tested.
Instead of rounding up 96 computers and trying to coordinate their
communications, we used two Micron Millennia Pro 200-MHz servers, each
configured with a 48-port Digi EPC/CON multiport serial board. The
servers ran Windows NT 4.0; 48 dial-up networking clients were created,
each with its own preconfigured IP address and separate Class C network
to ensure that data was passed down every port, rather than down the
first port of the subnet. We used V.34 modems topping out at 33.6 with
V.42 compression. On the dial-out side, two Compaq Computer Corp.
Microcom 6100 chassis were connected to a Madge Networks Teleos Model 60
T1/PRI switch via a T1 connection. Funk Software's Steel-Belted Radius
provided user authentication.
The majority of the severs came in with transfer times between 5.5 KB
to 7.5 KB per second for IP and IPX file transfers. The Access Beyond
AB4400 and Bay Networks Model 5399 offered the fastest overall
throughput. ACC Tigris came in a disappointing last with no transfer
times greater than 3 KB per second.
---- INDEX REFERENCES ----
COMPANY (TICKER): Ascend Communications Inc.; CISCO SYSTEMS INC.; Compaq Computer Corp.; Shiva Corp.; 3Com Corp.; BAY NETWORKS INC.; CABLETRON SYSTEMS INC.; Multi Tech Corp. (ASND CSCO CPQ SHVA COMS BAY CS MUHC)
|
