WAN Boards

WAN (Wide Area Network) boards are designed to do a number of different tasks, but all come down to a simple goal: connect two or more networks together. The networks may be local area networks in a corporation, or a network and the Internet. The networks may be next to each other physically, or thousands of miles apart connected to each other over a dedicated telephone line. Whatever the scenario, a WAN board replaces complex and expensive gateways and routers to some extent, and allows better integration between a LAN and other networks.

There are a plethora of competing standards and protocols available for WAN interconnectivity. The most commonly used systems are Frame Relay (which operates over ordinary telephone lines), ISDN and T1, which require dedicated digital lines, and a smattering of much faster systems such as T3 and OC3. Since it is likely most SCO-based networks won’t be using telephone lines that cost more per month than a high-end server’s purchase price, we decided to look at WAN boards that offer Frame Relay, ISDN and T1 capabilities. The most commonly used protocol for WAN connectivity is X.25, but there are others. In order to avoid too much confusion in a small wrap-up, we tested our WAN boards over X.25, ISDN, and Frame Relay.

We contacted several WAN board vendors to check support for SCO operating systems. We eliminated any company that did not offer either SCO UnixWare 7 or SCO OpenServer 5 drivers and asked the remaining companies for evaluation units. We let the companies choose representative boards from the product line that they felt would best serve a SCO audience. All the boards tested are SCO certified. We installed and tested each board for two weeks in a specially constructed test network (see "How we tested") and offer our conclusions below.

Digi DataFire SYNC 2000

Digi is well know for multiport adapters, and to a lesser extent for its networking boards. The DataFire SYNC 2000 may change that, as it is a versatile and flexible WAN adapter that works perfectly with SCO UnixWare 7. We tested the DataFire SYNC 2000 2P+PCI model, which offers two ports (a four-port model is available). The DataFire SYNC 2000 supports Frame Relay, X.25, and PPP. When coupled with the eNetwork communications server from IBM the DataFire SYNC 2000 adds SNA support, too, through a Windows NT server.

The DataFire SYNC 2000 board is well laid out with a lot of surface-mounted devices. A motorola MPC860 PowerQUICC processor (which seems to run at 25MHz) handles on-board processing requests along with a secondary processor also from Motorola. (The Digi DataFire SYNC 2000 2P board – as opposed to our 2P+ -- lacks the second processor.) According the Digi the two processors together offer over 200MIPS, which certainly would off-load the host server CPU a great deal. Our test board had 4MB of on-board RAM. A built-in surge suppressor called SurgeBlock is on the board as well, preventing the board being a conduit to spikes from the attached lines. The back-plane of the board has two SCSI-II type connectors with adapters. The board has automatic cable detection of most interfaces.

Installation was simple: install the PCI board, attach the adapters to the two ports, then attach the cables to the adapters. The drivers for the DataFire SYNC 2000 are provided on a CD-ROM for UnixWare and Windows NT. The X-based software shows the protocols in use by the DataFire SYNC 2000 as well as several diagnostic displays that help administrator monitor the board’s performance as well as the WAN throughput. On-line documentation is used by the DataFire SYNC 2000 instead of a printed manual. We still would have preferred printed documentation as an alternative, but the trend these days is away from printed manuals. The DataFire SYNC 2000 allows both IP and IPX routing, although we tested only IP.

Digi claims support for speeds to T1/E1 rates (2.048Mbps) but our lines were not capable of running to this maximum throughput. Under Frame Relay, the DataFire SYNC 2000 provides FRF.9 compression which boosts throughput on the lines noticeably. When used with Frame Relay, the DataFire SYNC 2000 allows 64 DLCIs per board. The DataFire SYNC 2000 supports up to 256 virtual circuits under X.25 but we only tested 64. Both BECN and LMI flow control is supported.

We experienced no problems at all with the DataFire SYNC 2000. After configuration, the board continued to function perfectly. The diagnostics in the software are handy but no replacement for a data scope. The ease of configuration and the on-board processing should allow the DataFire SYNC 2000 to function even in low-power WAN servers.

Eicon EiconCard S91-U

The EiconCard S91-U is designed to offer X.25 connectivity through a number of interfaces, including ISDN BRI U (128kbps), V.24, V.35, EIA-530, V.36, and X.21 interfaces. The card supports SDLC, PPP and Frame Relay. Intended specifically for UNIX servers, the EiconCard S91-U includes UnixWare 7 drivers.

The EiconCard S91-U is a PCI Plug-and-Play compatible board with an on-board Motorola 68302 CPU. There is 1MB RAM and 1MB FLASH memory on the board, too. The back plane of the EiconCard S91-U includes two ports, one for ISDN’s BRI U port (which can function over the D or B channels) and the other a Very High-Speed Interface (VHSI) port for full duplex protocols with speeds to 2Mbps. The VHSI port has automatic detection and configuration. For ISDN users, you will not need an external NT1 terminator. The back plane also has three small lights that indicate the port status and board state. Depending on the connection required, adapters may be necessary to allow the interface on the EiconCard S91-U to connect to the incoming cable. Eicon has al the connectors available separately, which usually would be ordered with the product.

Installing the EiconCard S91-U was simple, as you would expect. The PCI board plugs into any available slot. A diagnostic test routine booted under DOS verifies the board is operational. We tested the EiconCard S91-U with Eicon’s X.25 Connect for UNIX software, which was loaded after the board is installed. The software loads easily under both SCO UnixWare 7 and SCO OpenServer 5 (both drivers are included). X.25 Connect for UNIX includes integrated PAD support to allow logins over X.25, as well as a Terminal PAD to allow remote administration over the same connections. A STREAMS interface is used over X.25 for UNIX support. Configuring the X.25 Connect for UNIX package took only a few minutes, then the communications lines were available.

X.25 Connect for UNIX includes a developer’s toolkit for those who want to develop applications dependent on the S91-U connections. We didn’t do any application development but the toolkit appears to be easy to work with and would be handy for customizing some legacy applications to use newer communications technology.

One of the strengths of offering a board and software separately is the ability to customize to exactly your needs. However, Eicon’s approach could potentially lead to confusion on the part of administrators who are not sure what they are doing, and wish a simple all-in-one plug-and-play package. For the knowledgeable administrator, though, this setup is a winner. Our connections were flawless and the system easy to work with.

SBE WanXL

SBE’s WanXL has been available for several years and was the subject of a review in an earlier SCO World issue. For this WAN roundup SBE supplied a single port unit designed to provide UnixWare 7 with X.25 capabilities through a V.35 interface. The WanXL we were testing supports both HDLC and X.25. Both PAD and IP can be used with X.25, configured by the administration scripts. The two and four port models of the WanXL have a "personality modules" which can be removed and replaced to change the interface at any time. Our one-port was strictly for V.35.

The WanXL is a PCI board with a DB25 female connector on the back. A supplied cable connects from the DB25 to the V.35 interface. Installation of the board was smooth and it was nice to have the interface cable supplied with the unit. The software for SCO UnixWare 7 installs smoothly using pkgadd. The kernel must be relinked and after a reboot the board is available. Configuring the software takes a few minutes using the X interface. The software consists of a considerable number of scripts and commands that can be invoked separately at a terminal prompt, or managed through the interface. The WanXL comes with a spiral-bound configuration guide which covers all you’ll need to know.

There were a couple of features that we liked about the WanXL. The first is the ability to reconfigure a port at any time, and have the changes effective immediately without a reboot. The second is the breadth of tunable features on the board. The software lets you modify practically every aspect of the protocols and board behavior you could want to modify. Of course, this could lead to confusion and problems for novices, but the defaults are designed to work well in almost every situation.

When we connected the WanXL to our V.35 interface everything was up and running immediately. By tweaking the tunable parameters a little we saw the effect of each change, although we didn’t manage to improve performance noticeably for all our efforts. The WanXL functioned flawlessly and cause no problems at all.

Wrapup

Direct comparison of the WAN boards we tested is impossible because they do not all do the same task. However, a few general observations may be made. First, all the boards installed and configured remarkably easily. A novice administrator or someone not well versed in telephony and networking should be able to get any of these systems up and running with a minimum of fuss. Probably the hardest task with some of the WAN boards will be finding the correct cables. (SBE’s approach of including the interface cable as part of the package is excellent for a single-purpose board.)

Throughout the two week testing period the boards were used to couple our two test networks together, as well as to connect a network to the Internet. Not one problem was encountered with any of the boards. All functioned perfectly and the UNIX systems they were hosted on showed no ill effects for their presence. The Digi and Eicon boards seemed to off-load the host server CPUs a little more than the SBE board, but the difference was not significant. Of the boards we tested, the Digi appears to be the best engineered from both a board layout and design point of view, especially with the 4MB RAM and dual processors on boards, but this all comes at a price, of course. The Eicon software was the better of the bunch, but only marginally. SBE’s software offered more tweakable settings than the others. However, we certainly couldn’t fault any of the boards for their software quality or features. As for documentation, the only complaint we had was the lack of printed documents with the Digi board. The Eicon X.25 for UNIX system was the best documented and presented.

If we had to pick a winner of the comparison (and we do) we’d opt for the Digi board by a hair. The differences are small, but the performance was better, the board better, and the software very good. We couldn’t push the board to its limits because of telephone line limitations, but we have no doubt the DataFire SYNC 2000 can handle everything thrown at it without causing a pause in the host processors.

How we tested

Testing methodology differed a little for each board as they do not all support the same capabilities. Two test networks were assembled. Each was anchored by two SCO servers, one running SCO UnixWare 7 and the other SCO OpenServer 5. The two servers were ALR Revolution 2XLs with dual Pentium 266MHz CPUs, 128 MB RAM, and dual 9.1GB SCSI-II drives. Attached to each network were ten clients, six Windows 98, two SCO OpenServer 5 clients, and two Windows NT workstations.

WAN cabling available to the test networks included Frame Relay, X.25, and T1. All three interfaces were used both between LANs and to the Internet. We ran each board for two weeks, using it with script-driven software across the two LANs then across the Internet to a remote server.