ISDN routing made simple
|
|
|||
|
|
One of the most effective ways to roll out ISDN for branch office use is by employing ISDN routers, devices that shuttle traffic between an Ethernet LAN and one or more ISDN connections.
We tested four ISDN routers at the high end of the range for branch offices and small offices. The Symplex Communications DR-1 stood head and shoulders above the rest in terms of power and ease of use. Advanced Computer Communications' (ACC) Danube and 3Com Corp.'s NetBuilder Remote Office 427 were solid performers but rather difficult to learn and use, plus the NetBuilder works only with certain NT1 devices. Xyplex, Inc.'s 3850 also operated well but was difficult to set up.
The Symplex DR-1 is the only product in the group designed to support ISDN from the ground up, and this forethought shows in both its performance and ease of use. The DR-1 was designed to support bridging as well as IP and IPX routing over ISDN. It also supports one or two dedicated line connections using serial ports that can handle data rates of up to 500K bit/sec.
The ACC Danube, 3Com NetBuilder and Xyplex 3850 belong to families of routing products in which ISDN was more of an afterthought, added on top of frame relay, SMDS and dedicated-line implementations. All three can bridge or route a range of protocols - including IP, IPX, AppleTalk and DECnet ---- and support a variety of routing options, such as Routing Information Protocol, Open Shortest Path First, Border Gateway Protocol and static routes.
There were some interesting differences in performance. Figure 1 shows the performance of each product using two B channels on one Basic Rate Interface uploading and downloading compressed and uncompressed versions of a 295K-byte Excel spreadsheet file. The calls for these tests were made between our San Francisco laboratory and Ann Arbor, Mich., for Symplex, and between San Francisco and Littleton, Mass., for Xyplex. The calls for ACC and 3Com were made between two ISDN lines in our lab. This should have put Xyplex and Symplex at a disadvantage, but, in fact, 3Com's NetBuilder was no faster than the Xyplex 3850, and Symplex's DR-1 was the fastest of the group.
3Coms NetBuilder supports only per-packet ISDN compression and not history-based compression, which probably accounts for it being at the low end of the performance in the group. History-based compression looks for repetitive data patterns across multiple packets, while per-packet compression looks for repetitive data patterns only within a single packet.
History-based compression is more effective, but it requires more memory to maintain a history buffer. Performance was more consistent when sending the incompressible file, with a maximum variation of 10% between the fastest and slowest performers.
The Xyplex 3850 supports two BRIs, while the Symplex DR-1 supports four. To test the higher number of B channels that these products support, we uploaded and downloaded a NETSCAPE.EXE file and a PKzipped version of that same file (see Figure 2, page 48).
Our tests with two BRIs on the Xyplex 3850 gave us nearly twice the performance of a single BRI, as expected. However, the improvement on our compressible file was a disappointing 30%. This makes us wonder if the 3850 has the computing power to drive compression to its full performance potential with more than one BRI.
The Symplex DR-1 ran all tests easily. There was a drop in performance as B channels were added, more so with the compressible file than the incompressible file. Going from six to eight BRIs improved performance on the compressible file by 13%, about half the maximum potential performance improvement of 25%. The incompressible file was 19% faster, or about 80% of potential. In any case, throughput of 400K bit/sec using four BRI lines in a $3,800 product is impressive cost/performance.
We ran the tests on the DR-1 with all B channels set as permanent calls in order to eliminate the effects of the performance degradation inherent in dropping and setting up calls. The DR-1 has an option to keep a call up at all times, which can be useful in a flat-rate calling environment such as within a Centrex group.
We also tested connection times using 64K bit/sec clear-channel ISDN connections. The times were all in the 2- to 3-second range, which is three to four times faster than the connection times we measured using 56K bit/sec ISDN calling in previous tests (NW, July 10, page 41 and April 3, page 48). The connections for ACC's Danube were about 2 1/4 seconds when calling between two ISDN lines in our office. This is a "best case" call.
All four of these products use demand dialing - that is, they make an ISDN connection based on the presence of traffic to the remote location. They keep the connection up as long as the traffic persists and bring it down after a user-configured timer expires. We found that once any of these four products is set up, you can forget about it. It will make and break connections appropriately based on traffic. This minimizes your usage charges, while the quick connection times of an ISDN line gives you response times close to what you would see on a dedicated line.
Installation and operation
Putting most of these products to work requires little more time than establishing a link. ACCs Danube and Xyplexs 3850 are available as a chassis and one or more interface modules that you can assemble yourself, which lets you or your integrator buy the chassis and interface modules separately.
ACC Danube, 3Com NetBuilder and the Xyplex 3850, as tested, all had S/T interfaces that required an external NT1. NetBuilder has one unusual characteristic: It requires phantom power be supplied before it will initialize the ISDN line.
Phantom power is an option that provides a relatively small amount of power on the four signal pins of the ISDN S/T interface, usually as a backup power source. 3Com had to lend us a pair of AT&T NTIU250 NT1s because the Alpha Telecom NT1s in our lab couldn't supply phantom power, although they worked just fine with Danube, the 3850 and every other S/T interface device we tested.
Danube, NetBuilder and the 3850 all have complex command-line interfaces that re-quire a tedious setup process that asks you to enter the Service Profile Identifiers (SPID) and directory numbers, set up the dialing and PPP parameters for each B channel, bundle the B channels into a multilink group and turn on compression - either for each B channel or for the multilink group. You then set up IP routing, assign IP addresses to the local Ethernet interface and to the ISDN interfaces (if numbered interfaces are used), and set up the static routes.
The Xyplex 3850 has a Windows-based graphical interface utility called FocalPoint that writes a configuration file to a boot diskette, which you then install in the 3850. At least, that's the way it's supposed to work. Due to poor documentation, we needed technical support assistance to use FocalPoint and ultimately found the configuration file it built didn't work; we had to modify it using the command-line interface on the 3850 itself. FocalPoint also does not support the entry of static routes, so you have to enter them into the 3850 manually.
All things considered, we suggest you skip FocalPoint and set up the 3850 directly using its command interface.
3Coms NetBuilder has a "menu" command that makes it easier to use than the ACC or Xyplex products. For each command, the unit can display a list of options and lead you through them so you don't have to remember exact syntax.
For NetBuilder, Danube and the 3850, we found ourselves constantly referring to the documentation. These three products come with a formidable set of documents or a CD-ROM. We found it difficult to find the information we needed using the CD-ROMs, but it appeared that the CDs would be of more use once you understood the product well enough to know what you were looking for.
With guidance from each manufacturer, we got over the rather steep learning curves of these three products and became reasonably comfortable with each of them. Formal training for each product may be well worth the investment in time.
Routing test runs
Once the setup was complete, we tested our channels of communications. ACC Danube and the Xyplex 3850 require that you make the first connection directly to a remote unit rather than making a loop-back call to another local B channel. This can make isolating problems more difficult because it's harder to tell whether a problem is related to ISDN configuration, PPP, IP or an authentication issue.
Setting up the Xyplex 3850 was particularly difficult. It was not until we started working with one of the development engineers that we were able to get on-demand dialing with four B channels working. This engineer showed us how to simplify the configuration and set up the options that control ISDN as a backup facility to get the on-demand dialing to work.
3Com's NetBuilder lets you make a loop-back call from one B channel to another on the local ISDN line to verify the ISDN operation before connecting to the remote unit. Once this local call is successfully completed, any remaining ISDN problems are likely to be limited to setting the 56K/64K bit/sec speed correctly or, in rare cases, long-distance carrier issues.
The Symplex DR-1 is much easier to use, partly because it does not support as many options as the other products in this test. The main reason, however, is that the DR-1 automates many of the functions that require manual setup in the other three products. That makes it a good choice for remote offices where there are no technical people.
When you power up the DR-1, it leads you through a set of menus to enter the SPIDs and directory numbers of the local and remote BRIs and the unit's local IP address. It then automatically creates the multilink groups that bind B channels together, and also automatically makes a synchronization call to all of the configured remote sites and learns the IP addresses of the remote networks.
The unit uses this information to set up static routing table entries. The automatic operation of the DR-1 eliminates many of the tedious, error-prone steps required to set up the other three products.
The DR-1 has a suite of tests that you can use to verify its operation. The LAN test verifies the local LAN using ping commands. Separate WAN tests verify voice capabilities, by making a call from the DR-1 to any nearby voice telephone, and data setup, by placing an ISDN data call from the DR-1 back to itself. The final test is to make a call to a remote Symplex unit and pass data between them.
Troubleshooting tools
Getting the information you need to isolate a problem in an ISDN network is important in order to maximize uptime and minimize operation costs. All four of these products support telnet access, which allows you to examine and configure them remotely.
The ACC, 3Com and Xyplex units provide ping commands that let you test the WAN as well as the LAN. The Symplex DR-1 can ping only the LAN connected to the Ethernet port. We found that we did not need the ping command in the DR-1 because its automated setup avoids some of the problems that we ran into with the other products. The DR-1 also provides an easily accessible list of the addresses that it has discovered on both the local and the remote networks.
The DR-1 has an event log that describes actions that take place and problems that occur. We like having a log file, but we found that there is not enough detailed information in Symplex's log to determine the source of many problems. More detailed information may be appropriate only for the expert, but equipped with this information, an expert can resolve problems more quickly.
On the other hand, the logs on the Xyplex 3850 were as good or better than the Q.931 protocol trace that we were seeing on our NCC7000 protocol analyzer. The Xyplex also has a monitor command that provides a real-time update of the logs so you can watch them while a connection is being established.
This monitor command can also be used to show other continuously updated displays. Monitoring the circuit summary display showed the B-channel connections being made and broken. All ISDN product manufacturers should take a look at how Xyplex has implemented these logs.
ACC Danube displays messages about its functions, including ISDN, PPP, dial ports, multilink groups or compression, on-line while you are working. We found this disconcerting while we were trying to enter commands. We also found that these messages were difficult to interpret. While they did give us general ideas on how to resolve problems, it was not always clear what they meant. We used these messages to make educated guesses rather than define specific solutions to problems.
The Xyplex 3850 has a configurable log that can be accessed after a problem occurs to see what has happened. Just about every aspect of the operation of this system can be included in this log. For ISDN, it includes both the Q.921 Layer 2 events as well as the Q.931 Layer 3 events. Most of the time, eliminating the chatty Layer 2 heartbeats and showing only the Layer 3 messages is the right approach. We used this log to identify ISDN calling issues and to communicate them back to Xyplex for resolution.
3Com's NetBuilder gave reasonably informative messages but did not provide the detail available with any of the other three products. We found ourselves depending on a protocol analyzer to solve problems with NetBuilder.
We also were able to identify several knotty problems by using the NCC7000 portable protocol analyzer. The first ACC Danube that we received had a bad ISDN interface card. It was able to establish Layer 1 communication but not Layer 2.
The messages the Danube gave were not that helpful, but the NCC7000 made it clear Danube was not responding to the Layer 2 messages from the network. Based on this information, ACC shipped us a replacement Danube and it came up right away.
When we found that some of the products would not answer calls, we looked at the full text of the SETUP message that was being received and saw that Pacific Bell's network was delivering a seven-digit rather than a 10-digit phone number.
When we changed the local number from 10 to seven digits, these products accepted calls just fine.
We saw strange behavior from the Xyplex 3850 when we were testing with four B channels. Three calls were being set up from the same B channel rather than three different B channels. Since a B channel can support only one call at a time, the 3850 was clearly operating incorrectly.
Product configuration is also a consideration. ACC Danube includes a single Ethernet port and a single ISDN port. The Symplex DR-1 included a single Ethernet port, four ISDN ports and two serial ports. 3Coms NetBuilder includes a single Ethernet port, a single ISDN port and a serial port. The Xyplex 3850 we tested included a single Ethernet port, two ISDN ports, a high-performance processor and a 12-port hub.
Users should consider not only performance, but also the packaging that meets their needs. All things being equal, however, we found the Symplex DR-1 the most impressive ISDN router of the bunch.
