By Andrew Garcia  |  Posted 2004-05-10 Print this article Print

Compared with the other products in our review, the 9400 has a staggering price, although buyers will get many more network services in return. The starting price for a single 9400 is $35,000, with SSL VPN license packs starting at $2,500 for 50 users. Our test deployment—a 100-user configuration—would cost a hefty $55,000 with a discount for the second device used for high availability. The software build we tested, 49.5, was released last month. The 9400 was intended to be managed from the command-line interface, plain and simple. The unit does offer a Java-based Web interface, which does little to pretty up the commands, but we dont recommend using it. In fact, the vendor may be leaning the same way: We could find hardly any mention of the Web console in the switchs documentation, even though the console has been available for a few years now.

The 9400 also has the steepest management learning curve of all the products we tested. Assigning rights to services required building some comparatively complex access expressions from the ground up. But once we figured out the nuances, the product let us get incredibly granular with our Boolean expressions.

The 9400 permits only one authentication server per log-in page; we had to create separate virtual servers for RADIUS and LDAP users. NetScaler plans to address this issue in a forthcoming release, according to company officials.

To recognize the group information extracted from our AAA servers, we first had to create local groups of the same name, then tie in the group info on the authentication configuration page. Unlike the Symantec and Juniper products, the 9400 does not offer tools to help discover groups on remote AAA servers.

Unlike all the other products we tested, the 9400 does not offer dynamic portal pages for the user. Administrators must manually change the portal page to reflect new bookmarks.

Its fairly easy to disrupt the cluster configuration when managing the primary device with the Java GUI. If the primary device fails, the secondary device is promoted, but the Java console user is not notified of this switch. The Java console does not require reauthentication when the downed device comes back online, re-establishing a management session with the now-secondary device. Therefore, changes we thought we were making to the primary device were being made to the secondary device, and the changes were not propagated to the rest of the cluster. Result: system hosed.

Click here to read the next review in this series.
Check out eWEEK.coms Security Center at http://security.eweek.com for security news, views and analysis.
Be sure to add our eWEEK.com security news feed to your RSS newsreader or My Yahoo page:  

Andrew cut his teeth as a systems administrator at the University of California, learning the ins and outs of server migration, Windows desktop management, Unix and Novell administration. After a tour of duty as a team leader for PC Magazine's Labs, Andrew turned to system integration - providing network, server, and desktop consulting services for small businesses throughout the Bay Area. With eWEEK Labs since 2003, Andrew concentrates on wireless networking technologies while moonlighting with Microsoft Windows, mobile devices and management, and unified communications. He produces product reviews, technology analysis and opinion pieces for eWEEK.com, eWEEK magazine, and the Labs' Release Notes blog. Follow Andrew on Twitter at andrewrgarcia, or reach him by email at agarcia@eweek.com.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel