Novell is now a part of Micro Focus

Using NetWare/IP Over Satellite Networks

Articles and Tips: article

MYRON MOSBARGER
Senior Research Engineer
Systems Research Department

01 Apr 1995


Network engineers and architects are using satellite technology as a means of interconnecting geographically dispersed LANs. Many of these wide area networks use TCP/IP as the communication protocol for the primary LAN backbone. NetWare/IP is a simple alternative designed specifically to integrate NetWare services into TCP/IP environments. NetWare/IP's design allows existing NetWare users to continue uninterrupted, working in their same environment, but use IP instead of IPX as the communications protocol. This Application Note details configuration specifics and recommendations for using NetWare/IP over satellite networks.

Related AppNotes Dec 93 "Wide Area Networking with VSAT: A Customer Installation" Nov 94 "Characteristics of TCP/IP, IPX/SPX, and NCP Protocols Over VSAT"

Introduction

Network engineers and architects are using satellite technology as a means of interconnecting LANs. Many of these networks use TCP/IP as the primary LAN backbone communication protocol. For simplicity, management, and many other reasons, a solution for connecting Novell LANs other than Novell's IPX (Internetwork Packet eXchange) is required.

NetWare/IP is a simple alternative designed specifically to integrate NetWare services into TCP/IP environments. NetWare/IP's design allows existing NetWare users to continue uninterrupted, working in their same environment, but use IP instead of IPX as the communications protocol.

NetWare/IP Architecture

NetWare/IP adds new design and architectural capabilities for deploying and supporting NetWare in local and wide area networks. NetWare/IP consists of several independent, cooperating client and server components:

  • NetWare/IP client

  • NetWare 3.1x or 4.x servers

  • Domain Name System (DNS) servers

  • Domain SAP Servers (DSS)

The NetWare/IP client software consists of a TCP/IP stack (TCPIP.EXE), a module called NWIP.EXE, and either the NetWare Shell (NETX.EXE) or the NetWare DOS Requestor (VLMs).

Note: Support for Novell's new NIOS client is currently in testing and will be available when NIOS 1.0 is released.

The NetWare/IP v1.1 server runs on either NetWare 3.1x or 4.x. NetWare/IP v2.1 runs only on NetWare 4.x servers. NetWare applications that previously used IPX can run on a NetWare server using IP.

The Domain Name System (DNS) server is a distributed look-up service that allows system administrators to centralize host name-to-IP address information. It provides a flexible way for NetWare/IP clients and servers to locate Domain SAP Servers.

Domain SAP Servers (DSS) maintain a database used to store and disseminate IPX Service Advertising Protocol (SAP) information to NetWare/IP clients and servers.

NetWare/IP Client Architecture

To understand the architecture of the NetWare/IP client, we can compare it to the traditional NetWare client architecture represented in Figure 1.

Figure 1: The standard NetWare client architecture.

The bottom or physical layer supports standard network interface cards. ODI drivers, or MLIDs, reside at the next higher layer. The ODI driver links the LAN adapter below it to the protocol stack above it.

The protocol stack (IPXODI.COM) is responsible for the end-to-end transport of data between systems. It exports an Application Binary Interface (ABI) called the IPX Far Call Interface that is backwards compatible with early versions of IPX.

The NetWare shell, libraries, and applications are at the highest layer in the NetWare Client architecture. They use the protocol stack (IPX) layer to transmit data by making function calls to IPXODI.COM using the IPX Far Call Interface.

The key to enabling all existing and future NetWare applications to run over TCP/IP is in making the IPX Far Call Interface available to applications over TCP/IP instead of IPX. Figure 2 shows how this is accomplished in the NetWare/IP client software.

The NetWare/IP client architecture is identical to the traditional NetWare client architecture at the hardware, ODI, and application layers. It is different at the transport layer. Instead of using IPX to transmit information, the NetWare/IP client utilizes the User Datagram Protocol (UDP) in the Novell TCP/IP protocol stack (TCPIP.EXE). This TCPIP.EXE is the same protocol stack used in Novell's LAN WorkPlace for DOS and LAN WorkPlace for Windows products.

Figure 2: The NetWare/IP client architecture.

Many people have wondered why the NetWare client does not run natively over TCP/IP. Porting the NetWare client software to run over TCP/IP is not as simple as replacing IPXODI.COM with TCPIP.EXE. The reason is that the ABI that applications use to call into TCPIP.EXE is different from the IPX Far Call Interface used by NetWare applications that call IPXODI.COM. To address this problem, an IPX Far Call Interface Emulation piece called NWIP.EXE sits above TCPIP.EXE and exports the IPX Far Call Interface to NetWare applications, libraries, and shells above it while making the appropriate calls to TCPIP.EXE below.

This client architecture allows current and future NetWare applications using the IPX Far Call Interface ABI to run unmodified with TCP/IP. In fact, either NETX or the VLMs may be used at the client.

However, there are limitations on IPX-based NetBIOS and other applications that depend on IPX broadcast mechanisms. These other applications are limited to their local subnet because IP routers do not forward non-direct UDP broadcasts to other subnets.

NetWare/IP Server

The NetWare/IP server platform is either NetWare 3.1x or 4.x. As noted previously, NetWare/IP 2.1 runs only on the NetWare 4.x platform. Servers can be either local or remote to the client.

Domain Name System (DNS)

NetWare/IP includes an implementation of the Domain Name System (DNS) server. NetWare/IP supports mnemonic naming of hosts. The table used for this lies off the root in SYS:ETC/HOSTS.

Note: To those unfamiliar with NetWare/IP, there may be some confusion about DNS domains and NetWare/IP domains. They are not one and the same. A NetWare/IP domain is a terminating leaf node of DNS that consists of a logical grouping of NetWare/IP clients, servers, and DSS servers. One domain can be partitioned into multiple subdomains. NetWare/IP domains are subdomains of a DNS domain.

Domain SAP Server (DSS)

Another major component of the NetWare/IP architecture is the Domain SAP Server (DSS). The DSS holds one logical database that stores and disseminates IPX SAP information to NetWare/IP servers. Each DSS maintains SAP information for a single NetWare/IP domain. There is only one primary DSS within each different NetWare/IP domain and, optionally, one or more secondary DSS databases. The DSS database can and should be physically replicated on multiple servers for reliability, fault tolerance, and improved performance across slow WAN links.

Updating the DSS with SAP Information

NetWare services, such as a file, print, and directory services, advertise themselves via the Service Advertising Protocol (SAP). Every 60 seconds these services broadcast a SAP packet that lists their name, service type, and address information. The packets are sent out on every network interface that IPX is bound to on the NetWare server that supports these services. This is how NetWare 3.1x servers and clients discover the location of services on an IPX internetwork.

When a NetWare server boots, it alerts the network to its existence by sending a SAP broadcast throughout the rest of the network. Similarly, when a NetWare/IP server boots, it advertises itself to the rest of the network by sending a SAP record directly to its nearest DSS using the User Datagram Protocol.

Subsequently, the NetWare/IP server refreshes its SAP information every five minutes (configurable) by re-sending it the DSS. This refresh is necessary because the DSS monitors when SAP records are received and discards old ones if they have not been validated within a certain time interval.

Other processes running on the NetWare/IP server, such as print servers and NetWare Directory Services (NDS), advertise themselves using SAP broadcasts. These broadcast packets are also sent by the NetWare/IP server directly to the DSS using UDP. This method of direct forwarding prevents SAP packets from being sent through every network interface, thereby reducing network traffic generated by such broadcast protocols. This makes NetWare/IP well suited for deployment in large network environments.

Updating the NetWare/IP Server with SAP Information

In a native NetWare environment, NetWare servers listen to SAP broadcasts to build their internal services tables. Because applications must be able to locate objects in the bindery, (pre- 4.x) NetWare servers keep the bindery updated with the latest SAP information. With NetWare/IP, this is accomplished by periodically downloading SAP information from the DSS to server cache memory and storing it in the bindery. Like the DSS updates, this occurs every five minutes (configurable).

NetWare/IP Network Design Models

NetWare/IP supports two models or methods of deployment on a network:

  • Server-to-Server

  • Client-to-Server

Server-to-Server

In this model, two NetWare/IP servers can be configured as gateways between networks. This is illustrated in Figure 3.

Figure 3: Server-to-server model.

This option requires modification to the server only. No client modifications are required. Clients continue using IPX and are unaffected by the server changes.

Client-to-Server

A client-to-server configuration requires modification to both the client and the server. This is illustrated in Figure 4.

This option allows users to continue using standard NetWare print and file services, NetWare utilities, and applications, but it uses IP as the communication protocol between the server(s) and client.

Figure 4: Client-to-server model.

Implementation, Configuration, and Test Results

This section outlines some of the implementation and configuration notes gathered as we set up a NetWare/IP network over a satellite link. It also gives the results of Novell's testing of this configuration.

Implementation Considerations

Reducing SAP/RIP Traffic. One of the biggest potential "costs" of interconnecting networks over satellite links is the efficient use of shared bandwidth. In terms of bandwidth, NetWare RIP/SAP traffic is very "expensive." Filtering is one solution, but it eliminates only RIP traffic. NetWare/IP is a better solution for reducing RIP/SAP traffic without filtering. Because it uses DSS to disseminate and route NetWare services, the frequency of updates can be configured on the fly.

NetWare/IP networks are logically partitioned into NetWare/IP domains. Often there is only one NetWare/IP domain that contains all NetWare/IP clients, servers, and Domain SAP Servers on the internetwork. However, the network can be partitioned into multiple NetWare/IP domains. Partitioning the network into multiple NetWare/IP domains is one way of limiting the amount of SAP information that must be maintained by DSS servers within a domain.

Partitioning reduces the load on the DSS server CPU and its memory requirements. However, in general it is better to increase the efficiency of DSS servers by spreading the load across multiple secondary DSS servers deployed throughout the network, rather than by partitioning the network into multiple NetWare/IP domains.

NetWare/IP vs. IP Tunneling. There are many differences between NetWare/IP and tunneling NetWare packets over IP. The primary difference for satellite installations is the DSS. Tunnelling has no configurable parameters to adjust for links speeds, the frequency of SAP/RIP packets, or the ability to replicate remote services on a local server.

When testing the throughput of NetWare/IP and tunneling with two servers, we found no measurable difference. However, as the number of servers increases, tunnelling adds substantially more traffic.

Configuration Guidelines

This section focuses primarily on specific configuration recommendations for networks connected by satellites. Though the research and testing has been done over satellite, results and recommendations can probably be generalized to apply to networks with similar characteristics.

Satellite testing was done in Novell's Superlab located in Provo, Utah, using the test configuration listed below.

Satellite configuration:

Hughes Network Systems ISBN
512Kb outroute
Shared 128Kb inroute
Transaction Reservation

Our test link was shared by other users, with real traffic, to help replicate real customer environments.

Note: Our haul-back link was only a 56Kb line. Many customers use much larger haul-back circuits.

DSS Database Replication. One of the design goals of the DSS architecture was to ensure that its database was highly available to the network. This goal is achieved by allowing DSS database replication on a large number of NetWare/IP servers. If a DSS is unavailable, the NetWare client or server will attempt to contact an alternate DSS (such as Novell's NDS) for the needed information.

DSS database replication can be used to improve performance on a large internetwork connected by WAN links. Since NetWare/IP nodes contact the DSS that is nearest to them, performance can be improved by placing secondary DSS servers on each subnetwork connected by the WAN. This ensures that the NetWare/IP nodes query the secondary DSS located on their local subnetwork, thereby eliminating the need to query a DSS that may be located on the other side of the WAN link.

Ticks. NetWare/IP is designed to support a wide range of bandwidths and latencies. Typically, NetWare expects clients to be relatively close in terms of "ticks." While NetWare accommodates a relatively broad range of response times, latency on busy WANS, satellite, or heavily-bridged networks can cause a substantial amount of re-transmission traffic. NetWare/IP has settable parameters for dealing with these types of environments, which in turn maintains NetWare's efficiency.

These parameters are set in the UNICON utility that comes with NetWare/IP. From the NetWare/IP Administration menu, select "Configure NetWare/IP Server" and then the "Slow Link Customizations" option. Figure 5 shows the resulting screen, in which you can set the Tick Value for various Network/Host IP addresses.

Figure 5: Screen for setting Tick Value for slow links in UNICON.

NetWare/IP 1.1 Server and Client. The NWIP.EXE client piece released with NetWare/IP 1.1 may not function properly with a reservation access method when accessing a DSS on the other side of the space link. Working with a customer, who brought this to our attention, we were able to replicate the problem. Basically, the client reported it could not read the DSS database on the server. What was happening was that the client timeout value was inadequate for some satellite configurations.

One configuration we tested with NWIP 1.1 appeared to function properly, although it has not been certified. Using the NWIP client from NWIP 2.1, we were able to successfully login and run on a NWIP 1.1 server. There were no timeout issues as with the 1.1 client.

The new version of NWIP.EXE (version 2.1) used with the NetWare/IP 2.1 server resolves this problem.

NetWare/IP 2.1 Server and Client. This version was tested in the Superlab prior to shipping. It runs as expected, but some modifications were required.

Modifications to the product are currently underway. By press time, the NetWare/IP engineering team will have tested them over our satellite configuration. NetWare/IP 2.1 is "satellite aware."

Recommendations

NetWare/IP is much more efficient than IP tunneling for inter-connecting multiple servers over WAN links. Because of its efficiency and scalability over satellite links, NetWare/IP is the preferred solution. The flexibility to customize links based on bandwidth and latency is a critical factor for supporting satellite transmissions.

When implementing NetWare/IP, replicate the DSS on local servers as shown in Figure 6.

Figure 6: Replicating the DSS on secondary servers.

Recommended NetWare/IP Server Parameters. Novell recommends that on a NetWare/IP server, you use a TCPIP.NLM dated 10-20-94 or later.

Recommended NetWare/IP Client Parameters. For NetWare/IP 1.1, use NWIP.EXE dated 1-16-95 or later. Configure the following parameters in the NET.CFG file: 

MemPool         8192
Buffers         8, 1500
TCP_Window      8192
PB Buffers      3

Conclusion

The NetWare/IP architecture is designed to support distributed worksites connected by varying bandwidths. The latest release has been tested using satellite connections and successfully passed. Though not tested in this environment, NetWare/IP 1.1 will also run successfully over satellite. In some circumstances the client NWIP.EXE must be upgraded. With either product, distributing the DSS is recommended. The Slow Links Customization parameters should be set to a tick value representative of the average round trip time for each destination.

NetWare/IP is an answer for those needing to support NetWare in an IP environment without losing the functionality of NetWare. It potentially improves performance compared to Novell's IP tunnelling, and is flexible enough to provide either individual client-to-server or workgroup server-to-server configuration.

* 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.

© Copyright Micro Focus or one of its affiliates