IntranetWare Over TCP/IP
Articles and Tips:
01 Jun 1997
Now that most companies are connecting their network to the Internet,they are trying to standardize on a single transport protocol. Since theInternet uses TCP/IP, these companies are evaluating TCP/IP solutions forIntranetWare, which, of course, is currently IPX/SPX based. In the past,Novell has provided several TCP/IP solutions for IntranetWare and NetWare,but a future release of IntranetWare will provide a significant enhancement:IntranetWare will send NetWare Core Protocol (NCP) calls directly over TCP/IP.
This article briefly explains the TCP/IP solutions Novell has offeredfor IntranetWare and then takes a first look at a pre-alpha version of IntranetWarethat has native support for TCP/IP. In fact, the version of IntranetWareI tested ran only on TCP/IP, although the final release of the product willsupport both TCP/IP and IPX/SPX.
WHAT TCP/IP OPTIONS HAS NOVELL PROVIDED IN THE PAST?
To provide TCP/IP connectivity for IntranetWare and NetWare, Novell hasoffered several solutions, including IP tunneling, IP relay, the LAN WorkPlaceproduct family (client TCP/IP stack), the IPX-IP gateway, and NetWare/IP.
IP Tunneling
Novell introduced IP tunneling in NetWare 3.11, and every subsequentversion of IntranetWare and NetWare has supported IP tunneling. IP tunnelingtechnology is popular on IPX/SPX networks that are linked by a TCP/IP-onlybackbone.With this solution, an IPX/SPX-based workstation sends its packetsto the IP tunnel partner, such as a local router. This partner encapsulatesthe IPX/SPX packet within a TCP/IP header, addresses this packet directlyto its IP tunnel partner (such as a remote router), and sends the packetacross the TCP/IP network. The receiving IP tunnel partner strips off theTCP/IP header and transmits the IPX/SPX packet to the remote network. (See Figure 1.)
Figure 1: With IP tunneling, an IP tunnel partner, such as a router, encapsulates IPX/SPX communications within a TCP/IP header.
To set up IP tunneling, you simply configure the IP tunnel partners tocommunicate with each other; you do not have to use specialized client software.You install the standard IntranetWare or NetWare client software, and theworkstations are unaware that their communications are temporarily encapsulatedin another protocol en route. As a result, IPX/SPX applications work inthe IP tunneling world.
However, IP tunneling does not provide TCP/IP communications all theway to the desktop; the networks are still supporting IPX/SPX communications.If you are trying to restrict your network traffic to a single protocolto reduce protocol troubleshooting and management software, IP tunnelingis not a viable solution. NetWare/IP, which is explained later in this article,provides TCP/IP communications all the way to the desktop.
IP Relay
IP relay is based on IP tunneling: IP relay temporarily encapsulatesIPX/SPX communications within TCP/IP packets between IP tunnel partners.However, IP tunneling was designed as a single point-to-point connection.IP relay, on the other hand, was designed to tunnel IPX/SPX packets to acollection of point-to-point permanent virtual circuits (PVCs). APVCis a continuously available communications path, such as a leased line,between two fixed points. For example, if a company supported six branchoffices that were connected to the corporate backbone through leased lines,the company would have six point-to-point PVCs. If your network is designedin a star topology with a central hub office connected to several remoteoffices, IP relay provides IP tunneling technology for multiple point-to-pointlinks.
IP relay offers the same advantages as IP tunneling by enabling workstationsto maintain IPX/SPX at the desktop while encapsulating their communicationswithin a TCP/IP header to cross a TCP/IP link. The workstations still communicatewith the IP tunnel partner via IPX/SPX. If you want to restrict multipointlinks to TCP/IP-only communications, IP relay is a viable solution.
Like IP tunneling, IP relay enables IPX/SPX workstations to communicateacross a TCP/IP network but does not bring TCP/IP all the way to the desktop.You must still manage two protocols on your IntranetWare or NetWare network.
LAN WorkPlace
Novell's LAN WorkPlace products enable DOS, Windows 3.x, Windows 95,and Windows NT 3.51 and 4.0 workstations to run TCP/IP and IPX/SPX applicationssimultaneously. For example, with LAN WorkPlace Pro for Windows 95 and NT,a Windows NT workstation could use TCP/IP to access a UNIX host and IPX/SPXto view IntranetWare drives. However, Novell's LAN WorkPlace products donot convert an IPX/SPX network to a TCP/IP network. These products simplyadd TCP/IP connectivity, allowing users to run TCP/IP applications.
Unlike IP tunneling and IP relay, Novell's LAN WorkPlace products donot encapsulate IPX/SPX communications within a TCP/IP header. Instead,TCP/IP applications use the TCP/IP stack, and IPX/SPX communications usethe IPX/SPX stack. However, you must run LAN WorkPlace on each workstationthat needs TCP/IP connectivity, and you must manage two protocols on yourIntranetWare or NetWare network.
IPX-IP Gateway
IntranetWare includes an IPX-IP gateway, which converts IPX/SPX communicationsto TCP/IP communications. This gateway allows you to run TCP/IP applications(such as Netscape Navigator) over an IPX/SPX network.
With Novell's IPX-IP gateway, you do not have to load a TCP/IP stackon your IPX/SPX-based workstations. However, you must install the IPX-IPgateway client software on these workstations. This client software interceptsTCP/IP communications, appends an IPX header to the TCP/IP packets, anddirects these packets to the IPX-IP gateway. The gateway, in turn, convertsthe transport protocol to TCP/IP and forwards the packets to their intendeddestination.
If you are managing a large IPX/SPX network that requires TCP/IP communications,Novell's IPX-IP gateway can be a blessing: You can provide workstationswith TCP/IP connectivity without enduring the IP addressing headache. Unfortunately,however, these workstations must communicate with an IP host through a gateway,which affects the performance of your network communications. (See Figure 2.) (For more information about IPX-IP gateways,see "IPX-IP Gateways: Find Internet Solutions at a NetWare Conference and Exhibits,"NetWare Connection, July 1996, pp. 60[shy ]64.)
Figure 2: Novell's IPX-IP gateway provides TCP/IP connectivity without the hassle of managing multiple IP addresses.
NetWare/IP
NetWare/IP allows you to maintain a TCP/IP-only IntranetWare or NetWarenetwork. As the predecessor to IntranetWare over TCP/IP, NetWare/IP offersan excellent stepping stone to native TCP/IP.
With NetWare/IP, all IPX/SPX communications are encapsulated within IP.If you analyze NetWare/IP communications, you can see the IPX header insidea User Datagram Protocol (UDP)/IP header. (See Figure 3.) UDP is a connectionless protocol similar to IPX. The UDP headerdefines the specific port (such as the FTP or Telnet port) that should processthe packet.
Figure 3: NetWare/IP actually encapsulates IPX/SPX communications within a TCP/IP header.
One of NetWare/IP's main advantages is that it works with TCP/IP applications.NetWare/IP also works with IPX/SPX applications because the IPX/SPX stackis still available on each workstation and applications can communicatedirectly with that stack. In fact, IPX/SPX applications are unaware thatthe workstation is using TCP/IP as the transport protocol.
In addition to enabling IntranetWare and NetWare workstations to communicateover TCP/IP, NetWare/IP uses domain SAP servers, which reduce the RoutingInformation Protocol (RIP) and Service Advertising Protocol (SAP) trafficsent across the network. Unlike IntranetWare and NetWare servers that supportSAP and RIP, domain SAP servers do not broadcast SAP and RIP informationacross the network every 60 seconds. Domain SAP servers reduce SAP and RIPtraffic by maintaining SAP and RIP information for NetWare/IP servers anddistributing this information when servers request it. You can load thedomain SAP server NetWare Loadable Modules (NLMs) on any IntranetWare orNetWare 4 server.
Although NetWare/IP is a viable solution, it still encapsulates IPX/SPXcommunications, and workstations must continue to run the IPX/SPX stack.
THE FUTURE: INTRANETWARE OVER TCP/IP
IntranetWare with native support for TCP/IP does not encapsulate or tunnelIPX/SPX communications. With this future version of IntranetWare, NCP callsrun directly over the TCP/IP stack and can be routed by any IP router. (See Figure 4.) Novell severed the IntranetWare kernel'sIPX/SPX dependency and rewrote the applications and utilities that madeIPX-specific calls. As a result, IntranetWare servers and workstations canuse TCP/IP, IPX/SPX, or both.
Figure 4: A future release of IntranetWare will send NCP calls directly over TCP/IP.
IntranetWare over TCP/IP uses the standard installation program. Duringthe installation process, you select the protocols that your server willsupport. If you enable IPX/SPX, you must select an internal IPX addressfor the server, as you normally would. If you enable TCP/IP, you must selectan IP address for the server. (Since I tested a pre-alpha version of IntranetWarewith native TCP/IP support, I am not sure how you will select protocolsin the shipping version of the product.)
NCP takes advantage of both TCP and UDP as transport protocols. LikeIPX, UDP providesconnectionless datagram services, which do notrequire a"handshake"to set up communications.
TCP, on the other hand, is similar to SPX, which provides connection-orientedservices.Connection-oriented servicesrequire communication partnersto perform a"handshake"before exchanging data and enable thesepartners to acknowledge the receipt of transmitted data. Although both SPXand TCP provide connection-oriented services, TCP's windowing and streamingcapabilities provide greater throughput than SPX provides.
Some NCP calls use UDP, and some NCP calls use TCP: For example,"control"NCP calls, such as a request for file server information, use UDP. On theother hand, large transactions, such as NCP file reads and writes and NovellDirectory Services (NDS) synchronization, use TCP. Large transactions useTCP because TCP's streaming capability is similar to IPX's burst-mode technology.This capability provides quicker and more efficient file transfers.
The IntranetWare NCP Port
In the IPX/SPX world, developers use sockets to define the sending orreceiving process in communications. In the TCP/IP world, however, the InternetRegistration Group assigns port numbers to vendors, thereby differentiatingbetween the various processes on the network. For example, IntranetWare'sport number is 524.
The Workstation Connection Sequence
A workstation on an IPX/SPX network sends a SAP Get Nearest Server requestto locate an IntranetWare or NetWare server. (For more information aboutIPX/SPX communications, see Standard IntranetWare Communications: NCP Over IPX/SPX.") A workstation on a TCP/IP network,on the other hand, uses the Dynamic Host Configuration Protocol (DHCP) tolocate an IntranetWare or NetWare server. After the workstation locatesa server using DHCP, this workstation transmits an Address Resolution Protocol(ARP) request to find the server's hardware address. (See Figure 5.) (Because DHCP and BOOTP use the same socket number, LANalyzer forWindows 2.2 refers to both protocols as BOOTP communications. For more informationabout LANalyzer for Windows 2.2, see "Configuring LANalyzer for Windows 2.2 to Decode Native TCP/IP Communications.") At this point, the workstation uses NCP calls to retrieve the file serverinformation, authenticate to NDS, and log in to the server.
Figure 5: A workstation uses standard ARP broadcasts to locate an IntranetWare or NetWare server's hardware address.
SLP Versus SAP
On an IPX/SPX network, workstations use SAP to locate servers, and serversuse SAP to share service information with each other. However, servers cannotuse SAP to exchange service information on a TCP/IP network. Instead, IntranetWareservers with native TCP/IP support use the Service Location Protocol (SLP)to exchange service information. SLP is an emerging technology defined forthe TCP/IP community.
IP Address Assignments
With IntranetWare, you can configure a workstation to automatically obtainan IP address from a DHCP host. Using a DHCP host can dramatically reducethe amount of time required to configure and maintain IP addressing on yournetwork.
IntranetWare offers DHCP support through a DHCP configuration NLM (DHCPCFG.NLM).You use this NLM to configure DHCP addressing, and it performs the DHCPfunctions for your IntranetWare network.
On the other hand, you can manually assign an IP address to your workstation.For example, if you wanted to manually assign an IP address to a Windows95 workstation, you would define the IP address and subnetwork mask in theTCP/IP Properties window. To access the IP Address Configuration window,select Run, and then select Settings. Next, select Control Panel, selectNetwork, and finally, select the TCP/IP entry listed. (For DOS and Windows3.x workstations, you can define individual IP addresses in the NET.CFGfile.)
The next sections explain how to configure the IntranetWare client forTCP/IP and the IntranetWare server to send NCP calls over TCP/IP.
CONFIGURING THE INTRANETWARE CLIENT FOR TCP/IP
To run NCP calls over TCP/IP, you must install the IntranetWare clientfor TCP/IP and then load and configure a TCP/IP stack. You can use any standardTCP/IP stack, such as the TCP/IP stack that ships with Windows 95.
When I selected Network on my Windows 95 workstation, the following optionswere listed:
Novell NetWare Client 32
LAN Driver (NDIS or ODI) (if you use ODI drivers, you must also load ODINSUP for TCP/IP support)
IPX 32-bit Protocol for Novell NetWare Client 32
TCP/IP
The NetWare Client 32 entry was set up when I installed the client software,but I manually added the TCP/IP entry: To add this entry, I selected Addand then Protocol. Next, I selected Microsoft and then TCP/IP.
With IntranetWare, you can configure the IntranetWare workstation touse both IPX/SPX and TCP/IP. This dual-stack configuration enables the workstationto communicate with both IPX/SPX- and TCP/IP-based servers. If you configureall of your servers to run TCP/IP, however, you may want to eliminate theIPX/SPX protocol stack to conserve resources on the workstation. Figure 6 shows the transport options for an IntranetWarenetwork that supports NCP calls over both TCP/IP and IPX/SPX.
Figure 6: IntranetWare with native TCP/IP support allows you to set up a TCP/IP-only network, an IPX/SPX-only network, or a network that supports both protocols.
If you decide to change your IPX/SPX network to a TCP/IP network, youmay want to support NCP over both transport protocols during the migrationphase. In this way, you can gradually move your workstations to the TCP/IPnetwork. You can also ensure that your NCP applications work properly whenthey run directly over the TCP/IP stack.
CONFIGURING THE SERVER TO RUN NCP CALLS OVER TCP/IP
As mentioned earlier, you use the standard IntranetWare installationprogram to install IntranetWare with native TCP/IP support. During the installationprocess, you are prompted for the LAN driver information and IP addressof your server.
To set up DHCP, load the DHCP NLM (DHCPSRVR.NLM) on the server. Thenuse the DHCPCFG NLM to configure IP address assignments. It's that easy!
Packet Structures for NCP Over TCP/IP
If you examine the packets sent by IntranetWare with native TCP/IP support,you can see immediately that these communications do not contain embeddedIPX/SPX packets. For example, if you look at the packet shown in Figure 7, you will notice that this packet includesan IP header that defines the next protocol as UDP. The UDP header, in turn,defines the next protocol as NCP by specifying the destination port numberas 524--the port assigned to IntranetWare. The NCP header and data (if any)sit directly behind the UDP header. Since these packets are IP based, theycan be forwarded by any IP router.
Figure 7: Analyzing communications proves that IntranetWare is running directly on TCP/IP.
SHOULD YOU INSTALL NETWARE/IP OR WAIT FOR NATIVE TCP/IP SUPPORT?
When I attended BrainShare Salt Lake City '97 in March, many CNEs askedme if they should install NetWare/IP now or wait until Novell releases theversion of IntranetWare that includes native TCP/IP support. Migrating toa TCP/IP-only network is obviously a hot topic. (If you are trying to decidewhether you should migrate your network to TCP/IP, see "DoesYour Company Need TCP/IP?") My recommendation is to install NetWare/IPnow. This option has two advantages over waiting for IntranetWare with nativeTCP/IP support:
First, you can get all of the IP addressing hassles out of the way beforeyou move to TCP/IP. If you have never set up a TCP/IP-only network, design-ingand implementing an IP addressing scheme can take a long time. By configuringyour IP addressing scheme now, you can resolve any problems you encounter.Then if a communications problem occurs when you install IntranetWare withnative TCP/IP support, you will know that the problem is not caused by yourIP addresses.
Second, because some of your applications may not be protocol independent,they will not work without NetWare/IP. Although most applications have beenengineered to use standard NCP calls and are 100-percent compatible withnative TCP/IP, some applications have been written directly to IPX or SPX.Therefore, these applications must be rewritten to work over the TCP/IPstack. By installing NetWare/IP now, you will be prepared to support anyapplications that may not work with native TCP/IP when you roll it out.
CONCLUSION
If you are evaluating all of the advantages and disadvantages of configuringa TCP/IP-only network, IntranetWare with native TCP/IP support just mayconvince you to take the TCP/IP plunge. With this version of IntranetWare,you can easily run TCP/IP, IPX/SPX, or a combination of both protocols onyour network. In my opinion, native TCP/IP support is one of the greatestenhancements that Novell has made to IntranetWare since NDS was implemented.
Laura Chappell researches, writes, and lectures on NetWare protocolperformance, troubleshooting, and optimization. Her partner, Roger Spicer,focuses on NetWare-Internet integration. They can be reached at info@imagitech.com. Special thanks to KathyJensen at Novell for her help with this article.
NetWare Connection, June 1997, pp.30-39
Standard IntranetWare Communications: NCP Over IPX/SPX
IntranetWare and NetWare use IPX/SPX to send NetWare Core Protocol (NCP) calls over the network. The following sections explain this communications process:
WORKSTATION CONNECTIONS
Using Service Advertising Protocol (SAP), a workstation transmits a Get Nearest Server request to locate either a file server for bindery-based connections or a directory server for Novell Directory Services (NDS) connections. IntranetWare and NetWare servers respond with their internal IPX address. Then to communicate with a server using NCP, the workstation uses the Routing Information Protocol (RIP) to find out how to locate the server's internal IPX address on the network.
After receiving a RIP reply from a device that can forward the workstation's packets to the requested internal IPX address, this workstation begins to communicate with the server using NCP over IPX. (See Sidebar Figure 1.)
IPX ADDRESSING SCHEME
An IPX addressing scheme is different from an IP address-ing scheme. As you know, you do not assign an IPX address to IPX workstations--they dynamically learn their IPX address when they boot up. When first booted, an IPX-based worksta-tion does not know its network address, so it uses network address 0x00-00-00-00 as its source address in its first SAP and RIP packets.
When servers and routers reply to the workstation's request, they include the workstation's network address in the IPX header. The workstation learns its network address when it receives the SAP and RIP reply packets. This workstation then uses its own network interface board address, or node address, as a unique host ID address.
Servers are assigned a network address either manually or automatically (in the case of IntranetWare and NetWare 4 servers) during the installation process. When a server is rebooted, it uses this assigned network address and the host ID address 0x00-00-00-00-00-01 for its communications.
Servers also use SAP to share server information tables. By default, servers use SAP to broadcast their server information tables every 60 seconds for every frame type to which IPX/SPX is bound.
IPX/SPX COMMUNICATIONS
Connection-oriented communications use SPX as the transport protocol. (A connection-oriented protocol such as SPX requires communication partners to perform a "handshake" before exchanging data. A connectionless protocol such as IPX, on the other hand, does not require a handshake to set up communications.) SPX relies on IPX for network addressing information. Because SPX is dependent on IPX, applications that are written to use SPX as the transport protocol must be rewritten to use IP.
If you want to see a protocol analysis of IPX/SPX communications, visit the BrainShare section of ImagiTech's World-Wide Web (WWW) site (http://www.imagitech.com/Bstrace.htm). This site offers a variety of workstation connection sequences that use IPX-only communications. You can also see a protocol analysis of IntranetWare with native TCP/IP support for comparison.
Configuring LANalyzer for Windows 2.2 to Decode Native TCP/IP Communications
LANalyzer for Windows 2.2 and below cannot decode native TCP/IP communications. However, you can use a text editor to configure LANalyzer for Windows 2.2 to decode NetWare Core Protocol (NCP) over TCP/IP. Complete the following steps to edit the LZFW.INI file (which is usually located in the C:\WINDOWS subdirectory on the workstation that is running LANalyzer for Windows 2.2):
Using a text editor, open the LZFW.INI file, and locate the section that starts with "; NetWare." (In LANalyzer for Windows 2.2, you will find "; NetWare" on line 245.)
Next, locate the line that begins with "ncp=NetWare," and after this line, add the line below. (This format is case-sensitive.)
ncp(ncp/udp)=NetWare,udp,TCP/IP,300,0,0,0,0
In the [protocols] section, add the following text to the end of the existing DLLFiles1= line. (Make sure you include the comma as shown below.)
,l_tdtncp
This line should now read:
DLLFiles1=l_tdlnk,l_tdatk,l_tdnw,l_tdsnmp,l_tdtcp,l_tdnfs,l_tdsna,l_tdnwip,l_tdtncp
In the same section, add the following lines before the "; TCP/IP" line:
; ; NCP over TCP/IP tncp=NCPTCPSuite,tcp,TCP/IP,524 ncp(tcp)=NetWare,tncp,NCPTCPSuite,0 ;
Save the LZFW.INI file.
Locate the L_TDTNCP.DLL file on the CD-ROM that contains the alpha version of IntranetWare over TCP/IP. Copy this file to the LANalyzer subdirectory on your workstation. (If you do not have the alpha version of IntranetWare over TCP/IP, you can download the L_TDTNCP.DLL file from http://www.imagitech.com/Bstrace.htm.)
After you complete these steps, LANalyzer for Windows 2.2 can decode NCP over User Datagram Protocol (UDP) communications. (See Sidebar Figure 2.) To ensure that you have edited the LZFW.INI file correctly, download the Moab traces from ImagiTech's World-Wide Web (WWW) site (http://www.imagitech.com/Bstrace.htm). If you have edited this file correctly, the NCP information is decoded in plain English. (See Figure 7.)
Does Your Company Need TCP/IP?
IPX/SPX or TCP/IP? Deciding whether you should switch to TCP/IP is the big debate among network administrators today. Many companies are deciding to migrate to TCP/IP simply because TCP/IP is the transport protocol for the Internet. A programmer named Guy Yost uses a great analogy when comparing IPX/SPX and TCP/IP, and I'm going to borrow this analogy.
QUICK LIKE A FOX, OR STEADY LIKE A CAMEL?
IPX/SPX is like a fox--fast and relatively easy to handle in small spaces. In addition, IPX/SPX doesn't need much care and feeding: The IPX addressing system is plug-and-play. Workstations dynamically learn their IPX address, and servers can have their internal IPX address manually assigned.
However, just as a fox is not equipped to run long distances, IPX/SPX is not ideally suited to communicate over long distances. In addition, IPX/SPX does not support fragmentation or connection-oriented streaming of large chunks of data. Fragmentation is the ability to break a single, large packet into smaller packets to transverse a data path that supports small packet sizes. For example, IP routers can fragment and defragment packets as needed. Although Novell does have a version of SPX that supports some connection-oriented streaming, this version is limited to eight packets in a single burst--a good reason to look at TCP/IP's connection-oriented streaming capability.
TCP/IP, on the other hand, is like a camel--built to communicate over long distances (via IP fragmentation and TCP's connection-oriented streaming capability). If you have ever seen a camel, however, you know that they smell bad and often spit at you. To get a camel to cooperate, you must groom and pamper that camel. Likewise, to ensure that you have a foolproof IP addressing scheme, you must carefully plan that scheme.
So which protocol is right for your company? You should consider the following questions when making this decision:
Do you have any IPX/SPX-dependent applications?
Can you and your team support more than one protocol stack?
Do you have any routers that support only one protocol?
Do you need Internet connectivity?
Do you need IP fragmentation to send packets over diverse data paths?
Many companies seem to be jumping on the TCP/IP bandwagon even though IPX/SPX is working well and they don't need TCP/IP. For companies that do need TCP/IP, however, IntranetWare with native TCP/IP support is exactly what they are looking for!
FOR MORE INFORMATION ABOUT TCP/IP
If you need more information about TCP/IP before you make your decision, you can read several documents from the Internet Engineering Task Force (IETF). To access these documents, go to ftp://ietf.org/internet-drafts. For example, you can get more information about the Service Location Protocol (SLP) in the IETF document draft-ietf-svrloc-protocol-17.txt. (This draft expires Oct. 3, 1997 and will be superseded by draft-ietf-svrloc-protocol-18.txt.) For more information about Dynamic Host Configuration Protocol (DHCP), download IETF document draft-ietf-dhc-dhcp-09.txt.
In addition, you can download Requests for Comments (RFCs) from ftp://ds.internic.net/rfc. For example, you can get more information about the following protocols:
User Datagram Protocol (UDP) is explained in RFC 768.
TCP is explained in RFC 793.
IP is explained in RFC 791.
Address Resolution Protocol (ARP) is explained in RFC 826.
* Originally published in Novell Connection Magazine
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.