Interconnecting NetWare Networks with ISDN
Articles and Tips: article
Senior Product Marketing Engineer
Communications Infrastructure Division
GREG LINN
Engineering Manager
Communications Infrastructure Division
01 Mar 1996
Integrated Services Digital Network (ISDN) is a digital network technology being deployed by international and domestic service providers to replace outdated analog telephone technology. The rapid deployment of ISDN has made this digital Wide Area Network (WAN) service a popular choice for interconnecting Local Area Networks (LANs). This Application Note presents one possible solution for interconnecting NetWare LANs using ISDN. A brief discussion of the ISDN technology is followed by a detailed example of LAN interconnectivity using ISDN.
Introduction
Integrated Services Digital Network (ISDN) is a digital network technology being deployed by international and domestic service providers to replace outdated analog telephone technology. The rapid deployment of ISDN has made this digital WAN service a popular choice for interconnecting NetWare LANs
This Application Note presents an overview of the ISDN technology and describes various ways it can be integrated with NetWare. It then presents one possible solution for interconnecting NetWare networks using ISDN: using the NetWare MultiProtocol Router (MPR) 3.1 software. The bulk of the AppNote is a detailed example of how to configure two routers for interconnectivity using ISDN.
Overview of ISDN
ISDN is a set of digital transmission protocols defined by CCITT (the Consultative Committee for International Telephone and Telegraph, which was recently renamed the Telecommunications Standards Sector of its parent, the International Telecommuni-cations Union). The ISDN protocols are accepted by virtually all the world's communications carriers as standard.
BRI and PRI
In ISDN transmissions, B-channels (Bearer channels) transmit user information at relatively high speeds. Separate D-channels (Data channels) carry call set-up, signaling and other information. ISDN defines two interfaces for providing service: Basic Rate Interface (BRI) and Primary Rate Interface (PRI).
The BRI consists of two B-channels operating at 64 Kbps each, and one D-channel operating at 16 Kbps. Because of this, the interface is frequently referred to as "2 B + D" (see Figure 1).
Figure 1: Basic Rate Interface.
The PRI is defined as "23 B + D": 23 B-channels operating at 64 Kbps each and one D-channel operating at 64 Kbps. In Europe, the PRI is "30 B + D" (30 B-channels and one D-channel).
Advantages of ISDN
ISDN has several advantages over traditional analog phone lines:
ISDN is digital, which means higher speeds and lower errorrates for transmission.
ISDN can run over existing copper wire, which means any location with a phone line is capable of being changed to run ISDN.
ISDN is an international standard, which means (theoretically) that different vendors' products should interoperate.
The reality is there are still differences between ISDN implementations in different countries. The most predominant difference is in the D-channel signaling. In many cases this signaling is country-specific, and in some instances it is PBX-specific. Most vendors offer several options for interoperating with different equipment.
56 Kbps Rate Adaptation
One significant technology issue that still plagues ISDN support in the United States is the use of in-band signaling (or robbed-bit signaling). With in-band signaling, one bit of every byte in a 64 Kbps channel is used for signaling, leaving 56 Kbps for data. Until the international standard called Signaling System 7 (SS7) and its associated out-of-band signaling technology are available throughout the U.S. telephone network, the need will exist for 56 Kbps rate adaptation support based on the V.110 Synchronous specification.
In addition to reducing the usable bandwidth of each B-channel, the constraint of 56 Kbps rate adaptation also complicates international connectivity to locations that provide 64 Kbps service by default. The good news is most service providers are rapidly moving towards full deployment of SS7, so the need for 56 Kbps rate adaptation should not persist for more than a few years.
ISDN and NetWare
The NetWare communications architecture defines a standard subsystem that supports the integration of LAN hardware adapters within NetWare server and client systems. This subsystem is referred to as the Open Data-Link Interface or ODI subsystem. ODI supports connectionless communications services provided by compliant hardware drivers and used by network layer protocols.
ODI provides a central data exchange and management point between multiple network layer protocols and multiple LAN interfaces. The ODI subsystem also provides modular separation of LAN data-link functionality from LAN hardware-specific driver logic (see Figure 2).
Figure 2: The Open Data-Link Interface architecture.
ODI Topology Specific Module (TSM) software, supplied by Novell, provides generic data-link support for LAN media such as Ethernet, Token Ring, and FDDI. ODI Hardware Specific Module (HSM) software, supplied by independent hardware vendors (IHVs), provides low-level data framing services on behalf of TSM software.
WAN-ODI
Extensions to NetWare ODI are provided to support connection management for wide area network communications to the connectionless ODI subsystem. These extensions, referred to as WAN-ODI, allow Network-layer protocols to establish, monitor, and terminate connections through circuit- and packet-switched WANs.
Network-layer protocols issue WAN-ODI connection management commands, which are executed by WAN data-link logic implemented within the TSM software. Data links return command results and connection status to network layers. In the case of analog circuit-switched media, such as public switched telephone networks (PSTNs), TSM-level device management logic interacts with external data communications equipment to control connections through the analog telephone network.
The most typical method of DCE interaction involves a combination of physical interface (RS-232, V.35, and so on) signal manipulation and AT protocol exchanges between WAN-ODI serial interface drivers and externally-attached modems. The modems, in turn, implement in-band analog signaling exchanges with central office telephone network equipment.
In the case of ISDN, the BRI or PRI interface controller is directly responsible for connection management signaling exchanges with the digital telephone network. These signaling protocol exchanges, which are conducted out-of-band over the ISDN D-channel, are considerably more complex than the AT protocol used by analog modems.
As mentioned previously, there are also D-channel signaling protocol variants that must be supported to operate with different ISDN switching equipment. Typically, ISDN connection management requires a significant amount of D-channel protocol software.
WAN-ODI for ISDN defines a simple approach for supporting D-channel signaling within the NetWare environment. In addition to B-channel data framing services, low-level WAN-ODI for ISDN WAN HSM drivers assumes responsibility for all D-channel signaling. The service interface between the ISDN WAN HSM and TSM data link emulates the WAN-ODI analog equivalent. It uses AT protocol exchanges and emulates RS-232 control and status signals.
AT ISDN macro commands are defined for controller and channel initialization, B-channel connection establishment, and B-channel connection termination. Individual ISDN WAN HSM drivers translate the simple AT macro commands into the actual D-channel protocol exchanges necessary to complete specified signaling operations. ISDN WAN HSM drivers report operation results and connection status through a combination of AT responses and RS-232 signal emulation.
ISDN WAN HSM drivers may support AT protocol controlled options for D-channel signaling variants (E-DSS1, 5ESS, NI1, and so on), as well as B-channel data framing options such as 56-Kbps V.110 Synchronous rate adaptation.
This simple integration approach allows Novell-supplied TSM data-link components to operate equally well with analog and digital circuit-switched networks. It places responsibility for D-channel signaling where it is best implemented: in the low-level, hardware-specific drivers. Drivers developed to AT-ISDN may support both NetWare MultiProtocol Router and NetWare Connect.
NetWare CAPI Manager
The approach described above is not the only way for ISDN adapters to be integrated into the NetWare MultiProtocol Router environment. Support of new ISDN-aware applications (such as facsimile, videotex, and imaging) in a hardware-independent manner requires a general-purpose API capable of presenting a variety of ISDN protocols and services supplied by hardware-specific drivers.
Novell has initially chosen to support the COMMON-ISDN-API (CAPI 2.0) specification, as implemented by the NetWare CAPI Manager subsystem. This specification is currently the API most widely implemented by ISDN IHVs and supported by ISDN ISVs. Thus, as the first Novell general-purpose ISDN API, the NetWare CAPI Manager is positioned to leverage the experience of existing ISDN hardware and software developers.
The NetWare CAPI Manager subsystem includes all standard functions defined by the COMMON-ISDN-API version 2.0. It also has auxiliary functions to provide enhanced ISDN resource management for NetWare systems supporting multiple concurrent CAPI applications. The NetWare CAPI Manager specification also includes definition of a NetWare-unique secondary service interface that allows the integration of multiple manufacturer-specific ISDN controller drivers below the NetWare CAPI Manager subsystem.
The open service interfaces defined by the NetWare CAPI Manager specification and provided by the NetWare CAPI Manager subsystem allow the integration of third-party ISDN hardware, drivers, and application software components into NetWare servers. The specification provides both scalability and flexibility, allowing the concurrent operation of multiple CAPI-compliant applications and multiple ISDN controllers provided by different manufacturers in a manner consistent with the overall NetWare architecture.
Figure 3 shows the different components that help support ISDN in the NetWare environment:
The LSL is the Link Support Layer, which handles data multiplexing for multiple protocols across multiple network interfaces.
The CSL is the Call Support Layer, which handles call connection management for use with connection oriented media, such as ISDN.
The PPPTSM is the Topology Specific Module that implements the Point-to-Point Protocol.
Figure 3: Components for supporting ISDN boards and drivers in the NetWare environment.
The WAN HSM interface is one point at which IHVs can write drivers for their ISDN adapters.
The WHSMCAPI is an adaptation layer provided by Novell to interface between the WAN HSM interface expected by the TSM and the CAPI Manager interface.
CAPIMGR is the NLM that implements the CAPI Manager. The CAPI interface is the other point at which IHVs can write drivers for their ISDN adapters.
Currently, ISDN is supported in MPR 3.0 and in NetWare Connect 2.0 through third-party AT-ISDN drivers and configuration snap-ins. MPR 3.1 ships with several CAPI and AT-ISDN drivers. A future version of NetWare Connect will also include the CAPI subsystem to support both CAPI and AT-ISDN drivers.
Obtaining a Currentlist of Novell-certified Boards
|
To ensure wide interoperabilityand compatibility with all Novell products, the Novell Labs group tests network adaptersand drivers for many different types of LANs and WANs (Ethernet, tokenring, FDDI, PPP,X.25, frame relay, ISDN, and others). For a current list of certified boards and drivers, use the Novell Labs Faxback services or check the Novell NetWire bulletin board on CompuServeor the World Wide Web. Faxback To use the Novell Labs Faxback service, dial one of the following numbers: (800) 414-5227 (domestic only) (801) 429-2776 (domestic and international) Select option 2 to receive a copy of the current Master Index, which provides document IDs of product certification bulletins and other general information available from Faxback. If you have problems using Faxback or questions about Novell Labs and its certification program, call (801) 429-5544 or send a fax to (801) 429-5224. NetWire To access the NetWire electronic bulletin board from your CompuServe account, type GO NETWIRE and the select the following option path: 2 (Service and Support) > 7 (Novell Labs Bulletin) > 1 (Product Type) Select the appropriate category, such as LAN Adapter/Drivers or Communications. World Wide Web To obtain a current list of certified adapters, refer to these Novell Labs World Wide Web pages: |
LAN adapters: http://netwire.novell.com/home/novlabs/infosys/10067.htm
Communications: http://netwire.novell.com/home/novlabs/infosys/10071.htm
Novell Labs also offers a search engine to find bulletins based on adapter type:
Goto http://netwire.novell.com/servsup/labform.html
Select the Communications database and search for WAN ODI, WAN HSM or AIO. Or select LAN adapters and search for the appropriate medium (Ethernet,token ring, and so forth).
ISDN Router Configuration Example
With an understanding of ISDN and how ISDN adapters and drivers integrate into the NetWare architecture, let's look at a specfic configuration example. With the NetWare MPR 3.1, ISDN service is predominantly used for one of two purposes:
As a dial backup to a leased line
As a switched connection between sites
This example involves two NetWare MultiProtocol Routers interconnected via a switched, on-demand ISDN connection. The configuration is illustrated in Figure 4.
Figure 4: Example ISDN network with two routers. with two routers.">
Router A is an ISA-based 80486/33MHz machine running NetWare 4.1 and the NetWare BranchLink Router 3.1 software. It contains an NE2000 Ethernet board and an Eicon SCOM board, a BRI ISDN adapter.
Router B is also an ISA-based 80486/33MHz machine running NetWare 4.1, but it has NetWare Enterprise Router 3.1 installed. It contains an NE2000 Ethernet board and an Eicon Quadro board, which is an ISDN adapter supporting two BRI.
|
Note: The NetWare BranchLink Router and the NetWareEnterprise Router are the two versions of the NetWareMultiProtocol Router available from Novell. The NetWareBranchLink Router supports two WAN ports, whereas theNetWare Enterprise Router supports up to 16 WAN ports. |
The sample steps given below describe the configuration of each router in detail. The configuration utility used is INETCFG, the Internetworking Configuration utility. Figure 5 shows INETCFG's main menu.
Figure 5: The INETCFG utility's main menu.
To configure each router, it is necessary to select Boards, Network Interfaces, WAN Call Directory, Protocols, and Bindings. Specific steps for each option are grouped under the corresponding headings below.
Boards
The first step is to create the configuration for the NE2000 board and the Eicon SCOM board in Router A.
Select the Boards entry from the main menu. A list of Configured Boards will appear (see Figure 6).
Figure 6: INETCFG's Configured Boards list.
Press <Insert< to display a list of drivers for various boards that can be configured.
INETCFG builds this list from the LDI files that it finds in the SYS:\SYSTEM directory. Included in the list is NE2000 Novell Ethernet(see Figure 7).
Figure 7: INETCFG driver list for supported hardware.
Highlight NE2000 Novell Ethernet and press <Enter<. A Board Configuration window is displayed.
For this example, the default values are sufficient, so only a board name needs to be assigned. Both routers will use "NE2000" as the board name.
Press <Esc< to exit this window. The NE2000 board now appears in the list of configured boards.
Press <Insert< to bring up the list of possible boards again.
Notice there is no entry for the Eicon SCOM board. This is because the SCOM board is written to the CAPI Interface. The router configuration requires that a WHSMCAPI adaptation board be defined.
Select the driver entry that reads WHSMCAPI - NovellWHSMCAPI.LAN.
As prompted, enter the board name. For this example, it is"SCOMISDN".
From the WHSMCAPI Board Configuration menu, select the CAPI Board Options item. INETCFG asks if it should automatically load the CAPI driver. Answer Yes to thisquestion.
INETCFG builds a list of drivers from the CDI files in the SYS:\SYSTEM directory. Select the DSCAPI20 driver for use with the SCOM board.
Press <Esc< to return to the WHSMCAPI Board Configuration menu.
Select the Driver-Specific Configuration entry. This causes a vendor specific configuration utility to be executed.
The Eicon ISDN Card Configuration menu creates a specific configuration file for use by any Eicon ISDN boards in the system. There is not a great deal of shared information between INETCFG and the vendor specific configuration utility. Therefore, it is necessary to fully define the SCOM board here.
Press <Insert< to bring up the Hardware Configuration window (see Figure 8).
Figure 8: Hardware Configuration window.
Fill in the hardware configuration as follows:
Adapter Name. Once again, enter "SCOMISDN" for the logical name that is being assigned to the ISDN adapter.
Adapter Type. The adapter type should be "SCOM".
Interrupt Level. Set the Interrupt Level to IRQ10.
ISDN Protocol. When you select this entry, the following listis displayed:
Australia, national ISDN protocol Australia, NT emulation for national protocol Belgium, national ISDN protocol Belgium, NT emulation for national protocol Europe and other countries, Euro_ISDN (E-DSS1) Europe and others, NT emulation for Euro-ISDN France, national ISDN protocol France, NT emulation for national protocol Germany, national ISDN protocol Germany, NT emulation for 1tr6 protocol Japan, national ISDN protocol Japan, NT emulation for national protocol Sweden, national ISDN protocol Sweden, NT emulation for national ISDN protcol USA/Canada, AT&T protocol (5E4 or higher)& USA/Canada, National ISDN 1 and NT DMS100 USA/Canada, NT emulation for National ISDN 1
This list shows the number of variations to the signaling standard that currently exist.
The equipment used in this example is connected to the localAT&T switch. This requires the selection of the USA/Canada,AT&T protocol (5E4 or higher) entry.
TEI and NT2. These selections on the card configuration menu are left at the default values of Automatic and Disabled,respectively.
Service Profile ID. To configure the identifiers, select the Service Profile ID entry. This brings up the SPID Configuration menu. There are entries for the Origination Address and Service Profile ID of both B-channels. The origination addressis supplied by the service provider, which in this case is AT&T.
The values used in this example are as follows:
Original Address:
3241651
Service Profile ID:
0132416510
Original Address:
3241758
Service Profile ID:
0132417580
Note: It is possible that only one origination address is given by the vendor, in which case bothchannels will have the same number.
After entering this information, press <Esc< until you return to the main menu, saving changes when prompted.
Network Interfaces
After having selected and configured the boards for Router A, the next step is to configure the logical interfaces presented by the physical boards.
Select the Network Interfaces entry from the main menu. The following list is displayed:
Board Name
Interface
Group
Media
Status
NE2000
NE2000
-
Ethernet
Enabled
SCOMISDN
SCOMISDN_1
Unconfigured
SCOMISDN
SCOMISDN_2
Unconfigured
Note that the SCOM board's two B-channels do not have a media associated with them.
Highlight the entry for the first B-channel (SCOMISDN_1) and select PPP as the medium. A PPP Network Interface Configuration window is presented. The values to fill in are asfollows:
ISDN Address. Enter the origination address for the firstB-channel, which is 3241651 as entered in the board-specific configuration.
Note: No sub-address is required in this example. However, this is a reflection of the address and switch that are being used. Other situations may require sub-addressing.
Modem/DCE Type. This should be set to ISDN (ATControlled).
Press <Esc< and save changes when prompted.
Repeat this process for the second B-channel, which is called the SCOMISDN_2 interface. The only difference is the ISDN Address, which is set to 3241758 for this interface.
Press <Esc< until you return to the INETCFG main menu.
|
Note: NetWare MPR 3.1 supports automatic dial backup forpermanent connections. All of the configuration stepscompleted are equally applicable to creating a backup callusing ISDN. For a backup call, a Permanent WAN call iscreated using the WAN Call Directory option. Then anassociation is made between the primary call and thebackup call using the Backup Call Associations option. |
WAN Call Directory
The goal is to have a configuration where Router A and Router B are able to connect to each other via ISDN. In order to make such a connection, the router needs a WAN call to provide the necessary information.
Select the WAN Call Directory entry from the main menu.
Press <Insert< to create a WAN Call Target.
Give the target a name. This example uses the target name of TO_ROUTER_B.
For the Wide Area Medium, select PPP. The PPP Call Destination Configuration menu is displayed. Several of the fields will need to be modified or set as follows:
Call Type. Set this entry to On Demand (activated by data).This is the usual type of call for ISDN connections, where the ISDN connection is charged on a time usage basis.
Interface Name. Set the Interface Name to SCOMISDN_1.
Telephone Number. In order for Router A to connect to Router B, the phone number for Router B must be entered in the Telephone Number field. The value in this example is 9431219.
Idle Connection Timeout. Because ISDN is charged on a connection time basis, it is desirable to bring the link down when data traffic is idle. To accomplish this, change the Idle Connection Timeout to 1 minute.
Password. This is a standard entry for PPP Authentication and is required when doing on-demand types of calls. In this example, the Password field is set to TEST.
Remote System ID. This is another required, standard entry for PPP Authentication. The Remote System ID is set to ROUTERB. This entry was inserted into the overall list of remote system IDs that INETCFG presented.
Press <Esc< until you return to the main menu, saving changes when prompted. The newly created WAN call appears in the list of Configured WAN Call Destinations.
Protocols
Under the Protocols option, enable IPX and configure it to run NLSP with RIP/SAP Compatibility.
Note that in NetWare MPR 3.0, static routes and services were configured in the Protocols option. They are now configured with the protocol bind.
Bindings
It is necessary to bind IPX to the network interfaces. We need to bind IPX to the NE2000_1 interface and assign a network number. In this example the network number is C9918377.
Select the Bindings option from the main menu.
To bind IPX to the SCOMISDN_1 interface, press <Insert< and select IPX as the protocol.
Select the SCOMISND_1 network interface. This displays the Binding IPX to a WAN Interface menu.
Select the WAN Call Destinations entry.
Press <Insert< to select from the available WAN call destinations. Select TO_ROUTER_B. This brings up the WAN Call Destination Entry menu.
At this point, a "Static On Demand" call type is created. To utilize this properly, it is necessary to create a list of static services and routes. By defining static services and routes, no routing information will travel across the link.
Note: NetWare MPR 3.1 also supports "Routed On Demand" calls. This type of call still requires static routes to initiate the call, but once a connection is made, routing traffic will flow over the link. With Routed On Demand calls, the routingtraffic does not keep the link alive.
Select the Static Services entry and press <Insert< to add to the list of services. ROUTERB is the service name and it has a Service Address Network of C9028377.
Press <Esc< until you return to the WAN Call Destination Entry menu.
Select Static Routes. The network number C9028377 is displayed. This route is automatically added as a result of creating the static service for the file server ROUTERB.
To access all networks at the Router B location, it is necessary to include a router for the Ethernet connection of Router B. Press <Insert< and specify the network number, which for this example is C9928377.
Press <Esc< until you return to the main INETCFG menu.
Router A is now configured to connect to Router B across an ISDN connection in an on-demand manner.
The entire configuration process is then repeated for Router B, substituting the information listed in the Configuration Summary below for Router B.
Configuration Summary
The following is a summary of the configuration information needed for both Router A and Router B.
Router A
Internal network number : C9018377
Boards: (1) NE2000 with default parameters
(2) WHSMCAPI driver
Board Name: SCOMISDN
CAPI Board Options -> auto load driver
Driver: DSCAPI20
Driver-Specific Configuration ->
Adapter Name: SCOMISDN
Adapter Type: SCOM
Interrupt Level: IRQ10
ISDN Protocol: USA/Canada, AT&T protocol (5E4 or higher)&
TEI: Automatic (default)
NT2: Disabled (default)
Service Profile ID ->
Origination Address: 3241651
Service Profile ID: 0132416510
Origination Address: 3241758
Service Profile ID: 0132417580
Network Interfaces: SCOMISDN_1 -> PPP
ISDN Address: 3241651
Modem/DCE Type: ISDN (AT Controlled)
SCOMISDN_2 -> PPP
ISDN Address: 3241758
Modem/DCE Type: ISDN (AT Controlled)
WAN Call Directory: TO_ROUTER_B -> PPP
Call Type: On Demand (activated by data)
Interface Name: SCOMISDN_1
Telephone Number: 9431219
Idle Connection Timeout: 00:01:00 (HH:MM:SS)
Password: TEST
Remote System ID: ROUTERB
Protocols: IPX -> Enabled, NLSP with RIP/SAP compatibility
Bindings: IPX B> NE2000_1
Network Number: C9918377
IPX -> SCOMISDN_1 -> WAN Call Destinations
TO_ROUTER_B
Static Services -> File Server, ROUTERB, C9028377
Static Routes -> C9028377, C9928377
Router B
Internal network number: C9028377
Boards: (1) NE2000 with default parameters
(2) WHSMCAPI
Board Name: QUADRO
CAPI Board Options -> auto load driver
Driver: DQCAPI20
Driver-Specific Configuration ->
Adapter Name: QUADRO
Interrupt Level: IRQ11
ISDN Protocol: USA/Canada, AT&T protocol (5E4 or higher)&
Service Profile ID ->
Origination Address: 9431219
Service Profile ID: 0194312190
Origination Address: 9431149
Service Profile ID: 0194311490
Network Interfaces: QUADRO_1 -> PPP
ISDN Address: 9431219
Modem/DCE Type: ISDN (AT Controlled)
QUADRO_2 -> PPP
ISDN Address: 9431149
Modem/DCE Type: ISDN (AT Controlled)
WAN Call Directory: TO_ROUTER_A -> PPP
Call Type: On Demand (activated by data)
Interface Name: QUADRO_1
Telephone Number: 3241651
Idle Connection Timeout: 00:01:30 (HH:MM:SS)
Password: TEST
Remote System ID: ROUTERA
Protocols: IPX -> Enabled, NLSP with RIP/SAP compatibility
Bindings: IPX -> NE2000_1
Network Number: C9928377
IPX -> QUADRO_1 -> WAN Call Destinations
TO_ROUTER_A
Static Services -> File Server, ROUTERA, C9018377
Static Routes -> C9018377, C9918377
With these configuration parameters set, the two routers will be configured to make calls across the ISDN links in an on-demand manner.
Refer to the AppNote entitled "Configuring Asynchronous Connections with the NetWare MultiProtocol Router 3.0 Software" in the August 1995 Novell Application Notes for further information on configuring on-demand calls and connection time management.
Summary
Novell views ISDN as an important technology for our customers, given the transmission speed and other advantages provided by ISDN. The support of the COMMON ISDN API is an example of how Novell intends to bring ISDN into the NetWare platform. As other standards are developed and accepted by the market, Novell will work with its partners to ensure that NetWare and ISDN stay well integrated.
The use of the NetWare MultiProtocol Router with ISDN is one solution for interconnecting NetWare networks. The majority of this AppNote has focused on an example configuration of MPR and ISDN. The ease of configuration makes this example applicable to many NetWare installations.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.