Maintaining IPX Compatibility During a Migration to TCP/IP on a NetWare Network
Articles and Tips: article
Senior Research Engineer
Novell Developer Information
01 Mar 1998
Looking forward to moving from IPX to TCP/IP when NetWare 5 becomes available later this year? Read up on some of the tools Novell is providing to facilitate such a transition while maintaining compatibility with legacy IPX-based applications.
Shortly after their development in the 1980s, Novell's IPX (Internetwork Packet eXchange) family of protocols became widely established as a standard platform for corporate LANs. While many networks continue to use IPX today, there has been a push to embrace the TCP/IP protocols being used on the Internet and in corporate intranets. As a result, many businesses are trying to build and maintain heterogeneous, multi-protocol computing environments which combine LAN, WAN, Internet, and intranet operations.
These efforts to combine and consolidate diverse computing environments have been challenging at best. Most solutions require multi-level security and multiple systems for resource discovery and naming, leading to increased administrative burdens and interoperability headaches. Another problem is that many TCP/IP networks do not easily accommodate systems based on other protocols. Often, large organizations perceive that TCP/IP is easier to install and maintain because their routers are designed for optimal operation in a TCP/IP environment. Thus many companies have had to choose between the high performance of IPX/SPX-based applications and the increased administration and maintenance costs of running those applications in a TCP/IP environment.
To make it easier and more efficient for customers to build and maintain heterogeneous networks, Novell is bringing together the four architectural platforms of LAN, WAN, Internet, and intranet into a single, integrated environment. This integration will be greatly facilitated by the native TCP/IP support available in the upcoming NetWare 5 operating system (formerly known by the code name "Moab").With NetWare 5, Novell is simplifying the management of multiple-protocol environments by enabling customers to select which protocol or protocols they would like to deploy.
This AppNote introduces Novell's IP Compatibility Mode, a new feature of NetWare 5 which helps facilitate the transition from IPX/SPX-based networks to a TCP/IP-based environment.
NetWare 5's Protocol Strategy
NetWare 5 is the culmination of company-wide efforts within Novell to transform its products, making them open and standards-based. NetWare 5 is based on the IP protocol and embraces standards-based technologies such as Domain Name Service (DNS) and Dynamic Host Configuration Protocol (DHCP). Furthermore, NetWare 5 allows these technologies to work with de facto standards such as Novell Directory Services (NDS) and WinSock 2.
Pure IP in NetWare 5
The most significant change in NetWare 5 is that the network services are now able to use TCP/IP as their "native" network protocol. This is accomplished by modifying Novell technologies and combining them with TCP/IP standards, as follows:
Modifying the NetWare operating system to remove all IPX dependencies (IPX functionality therefore exists only to provide backward compatibility with IPX-based applications)
Modifying NetWare Core Protocols (NCPs) to use both TCP and UDP (User Datagram Protocol) transports.
Having DHCP broker IP addresses and help the Novell client requester locate an NDS server.
Using NDS for naming and Service Location Protocol (SLP) to provide service discovery that replaces Service Advertising Protocol (SAP) without the "chatty" overhead.
These modifications give customers the ability to run NetWare in a "Pure IP" environment pure in the sense that it doesn't retain any of the IPX-based encapsulation that was the basis of NetWare/IP in previous versions of NetWare. (Of course, NetWare 5 provides full compatibility with the existing NetWare/IP product so that customers can continue to use it if they so choose.)
The Customer's Choice
The advantages of consolidating to a single TCP/IP protocol are many:
In routed environments, consolidation requires less hardware and software.
It allows more efficient use of bandwidth.
Support costs are lower when you have only one client protocol to deal with.
There is a wider range of opportunities for remote user connectivity.
However, Novell recognizes that our customers have invested significant time and money in building their existing IPX-based networks. Many have mission-critical applications or services that rely on the IPX/SPX protocols. To support our customer base, Novell is committed to remaining backward compatible with IPX/SPX as we adapt our transport technology to meet the changing needs of businesses both large and small.
Although a single-protocol environment may be the ultimate objective, most customers are looking for a phased approach in migrating from IPX-only or mixed IPX-TCP/IP networks to a TCP/IP-only scenario. The primary concern is maintaining compatibility with existing IPX-based functions and applications during the course of the migration. To ease such concerns, NetWare 5 will ship with several features that provide seamless compatibility between IPX and IP-based technologies. This AppNote discusses two such features:
IP Compatibility Mode, which provides support for IPX-based applications in a TCP/IP-only environment Migration Gateway, which acts as a "bridge" between IPX segments and IP segments, enabling users to access all network information during the migration process
Compatibility Mode enables customers that want to move to an IP-only environment to do so, without having to replace valuable IPX-based applications right away. The Migration Gateway allows customers to move to an IP-only environment incrementally, at their own pace, without disrupting their day-to-day business operations.
The remainder of this AppNote describes these two features and discusses some of the issues to be considered in anticipation of a migration from IPX to TCP/IP with NetWare 5.
For moreinformation about NetWare 5 and its features, see the Novell We site at www.novell.com. For a more detailed overview of NetWare 5's move to TCP/IP, see "NetWare over TCP/IP: integrating NetWare Services into the TCP/IP Environment" in the March 1997 issue of Novell AppNotes.
Overview of IP Compatibility Mode
NetWare 5's IP Compatibility Mode provides a link between the IPX world and the IP world. It allows all routes and services being advertised by RIP and SAP on the IPX side of the network to be communicated to and be accessible from the IP side, and vice versa. As illustrated in Figure 1, it allows interoperability between IPX, NetWare/IP, and Native IP networks.
Figure 1: Compatibility Mode allows interoperability between various types of networks.
Clarification of Terms To better understand the discussion of Compatibility Mode and the Migration Gateway, we needto clarify some of the terminology that will be used throughout this AppNote.
NetWare server. A computer system controlled by the NetWare operating system which provides and supports NetWare services. NetWare client. A workstation computer executing software that facilitates the access and use of NetWare services. NetWare services. Tose network services that are provided by the NetWare operating system (including file services, print services, directory services, and others). NetWare service provider. Novell-supplied software executing in a NetWare server or NetWare client that provides access to, or facilitates the use of, NetWare services. NetWare service protocol. An application-layer protocol used by NetWare service providers to communicate with other peer service providers typically this protocol is NCP (NetWare Core Protocol). IPX network. A collection of network segments and routers that carry only IPX packets. IPX client. A NetWare client that only supports IPX protocols. IPX server. A NetWare server that only supports IPX protocols. NetWare/IP. An add-on product for NetWare servers and clients that "tunnels" orencapsulates IPX traffic within IP packets for transport across a TCP/IP network.
TCP/IP Internet Protocol Suite. The official name of the collection of protocols that collectively enable the transmission of data packets over an IP- based internetwork. These protocols are defined by network standards which are under the jurisdiction of the Internet Architecture Board. IP network. A network containing at least one IP server. Native IP server. A NetWare server capable of functioning in both TCP/IP and IPX networks. This includes communicating with other NetWare nodes using protocols native to the network environment and providing the services necessary for IP clients to function in TCP/IP networks. Native IP client. A NetWare client capable of functioning in both TCP/IP and IPX networks. This includes the ability to complete the bootstrap process and communicate with other NetWare nodes using protocols native to the network environment. NetWare-aware application. Software executing in a NetWare server or on a NetWare client that uses NetWare services or NetWare APIs to accomplish its task. IPX-based application. Application which uses IPX APIs directly to communicate between clients and servers, or it may use SAP and RIP to advertise services and routes. NCP-based application. Application which uses NCP to communicate between clients and servers, and which does not use IPX APIs directly. IP-based application. Application which uses IP directly to communicate between clients and servers.
Compatibility Mode is implemented in the form of "drivers" that are loaded on NetWare servers and clients in the IP-only environment. If an IPX-based application requires access to NetWare services at the NCP level, the Compatibility Mode drivers deliver the requested information to the IPX application. This delivery takes place via the IP protocol, not via IPX.
Compatibility Mode provides IPX support on an "on demand" basis. If an enterprise is running all IP-based applications, Compatibility Mode lies dormant. On the other hand, if an enterprise has a mix of old and new network applications, Compatibility Mode is active and enables applications that depend on IPX to run in an IP-only environment.
Another aspect of Compatibility Mode is the Migration Gateway, which can be enabled to facilitate cross-communication between IPX and IP networks. As shown in Figure 2, the Migration Gateway allows clients in an IPX network to access services on a Native IP network, and vice versa. It also allows traditional NetWare servers to communicate with Native IP servers that have Compatibility Mode enabled.
Figure 2: The Migration Gateway allows cross-communication between the IPX and IP worlds.
For example, NDS synchronization can occur between a Native IP server and an IPX-based server via the Migration Gateway. Similarly, if a print service behaves as an IPX-based service in the IP environment, an IPX client could use the print service being provided by Compatibility Mode server on its side of the Migration Gateway.
The Migration Gateway can be used in a variety of ways to ease the transition from IPX to IP. For example, during migration you can continue to use IPX-based applications on local network segments, but run only IP on your WAN backbone. Thus, local IPX-based applications can span the IP-based wide area links, without imposing any unwanted IPX traffic. (We'll discuss this and other migration options later in this AppNote.)
These technologies will enable Novell's customers to transition to IP without being burdened by the bandwidth-filling aspects of IPX, or without forcing applications and services to be immediately upgraded. They make it possible for customers to gradually remove IPX-based applications from the network as they're replaced or rewritten to be transport-independent. When IPX applications are no longer required, no reconfiguration is necessary. Compatibility Mode simply remains dormant in the background in case on-demand IPX is needed again.
Compatibility Mode Server
With the Compatibility Mode enabled on a Native IP server, the server can support IPX-based applications running in IP-only networks. To do this, it must support three types of communications coming from other servers:
SAP and RIP
Protocol (IPX/SPX or TCP/IP)
In NetWare 5, all basic operating system applications have been modified to behave both as pure IP applications and as IPX-based applications. In other words, they register themselves as an IP-based application, and they broadcast service information via SAP for compatibility with existing networks. In addition, network services such as file and print advertise themselves as both IP-based services and as IPX-based services using the SAP/RIP mechanism. These services can thus be used as an IP service by IP clients, and as an IPX service by an IPX-based client.
In a pre-Compatibility Mode network, all requests from NetWare clients pass through the IPX protocol stack. Therefore, Compatibility Mode conversion starts with the server (the server must first migrate to IP-only). For compatibility in the server, applications take SAP information and put it into SLP for the non-IPX clients on the segment and for the cross-boundary communication. SLP is also used to add service information to NDS (or to the NetWare bindery on NetWare 3.x servers). Subsequently, all SLP information is sent over IP. In the other direction, incoming SLP traffic is translated to IPX, SAP, and RIP for non-IP (pre-upgrade) NetWare clients.
In every case, NCPs are still required. In NetWare 5, the NCPs have been modified to use TCP/IP as a transport protocol (sometimes referred to as NCP/IP). To handle requests from IPX clients, Compatibility Mode requires tunneling or encapsulation of IPX packets, so that only pure IP or tunneled IPX packets exist on the IP-only network (see Figure 3).
Figure 3: Compatibility Mode components on a Native IP server.
Compatibility Mode Client
An IP client with the Compatibility Mode driver loaded can access services being provided by:
An IP server with the Compatibility Mode driver loaded
An IPX server through the Migration Gateway
To support IPX applications, NCP applications, and IP applications with the new NetWare client, Novell has developed several new sets of APIs (Application Programming Interfaces):
Network Client (NCP engine) API
These new APIs funnel through the NWCLI API, along with all file system requests. This is also true for user applications which run at the client. The Network Client APIs are supported by an NCP engine underneath the session layer.
Handling Protocol-Dependent Traffic. In addition to the IPX API, there is a need to handle network traffic that relies on information found in the IPX header. Such protocol-dependent traffic must be handled in some fashion in order to maintain network communications. This requires an IPX stack at the client; however, the cost is only the memory footprint. If the IPX stack is not used, there is no performance hit (that is, no additional burden on client system performance).
Note: If NCPs are used on both ends instead of IPX requests, then the IPX code is dormant. It is virtually IPX on demand.
The Migration Gateway
The Migration Gateway is only needed when you want to link the two logical worlds of IP and IPX. That is, it provides emulation that prevents IPX protocols from populating the IP world, and it replaces SAP and RIP packets on behalf of IPX clients. The Migration Gateway uses IPX and IP addresses, as well as routing information contained in IPX packets, to send packets to the appropriate node. The Migration Gateway has normal IPX router functionality and can route between IPX and IP segments.
The Migration Gateway component resides on the node which would act as an agent or translator between the existing IPX-based network and the TCP/IP network. This node should be accessible to all the nodes from both networks that desire to access services provided by the other network. This agent node would become the Migration Gateway. All of the TCP/IP servers and clients would use this component as a gateway to the IPX segment, and vice versa.
The Migration Agent moderates between the IPX and IP segments. It provides service information about the IPX-based services in an IP segment to the IPX segment, and information about services in the IPX segment to the IP segment. It also facilitates access of IPX-based services provided in the IP segment in the IPX segment, as well as access to the service being provided in IPX segment in the IP segment. (The functionality between NetWare/IP segments and IP-only segments remains the same as in previous versions of NetWare.)
Within the Compatibility Mode functionality, the Migration Gateway registers to SLP as an agent. This enables the IP Client to talk to the Migration Gateway and access services provided by IPX-based networks. The Migration Gateway also behaves as an IPX server for the connected IPX segment that provide services from IP networks. An IPX client would contact the agent node to access the services being provided by IP networks, which the agent would then process and forward (see Figure 4).
Figure 4: The Migration Gateway bridges the IP and IPX worlds.
The mechanism for this uses SLP encapsulation of IPX datagrams via UDP packets (see RFC 2165). Thus, as the system allows communication between the pure IP and IPX nodes, Compatibility Mode becomes aware of them both. (Compatibility Mode retains the information about nodes to be able to resolve SAP requests.)
Note: The services of SLP are not required in an IP-only environment. The only reason they are required in NetWare 5 is for backward compatibility to services and applications that rely on SAP-based network discovery. With Compatibility Mode installed, SLP can be used for the IPX client to determine the IP address of the server. However, it is but one of several options available to clients for determining the IP address of an NDS server. Other options include DNS, DHCP, and local host files.
Since the basis for interoperability is coexistence, Compatibility Mode also supports combinations of NetWare/IP networks and IP networks, allowing IP clients to use services being provided by an existing NetWare/IP-based network. It also allows an existing NetWare/IP client to be able access services being provided by IP servers. Again, this does not include services which do not advertise using the SAP/RIP mechanism. In NetWare 5, all of the basic operating system services such as file and print advertise using both IP and the SAP/RIP mechanism.
Interoperability between NetWare/IP networks and IPX-based networks is already provided as a feature of the NetWare/IP product itself. This provides support for IPX-based applications on a Native IP server and on a Native IP client.
Compatibility Mode Configuration Options
When the appropriate installation option is chosen, a NetWare 5 server behaves as a Compatibility Mode server. The Compatibility Mode server can be converted into a Migration Gateway simply by setting the Migration Agent Mode to "on" (the default is "off").
Beyond the "on" or "off" setting, the Migration Gateway has no other configuration parameters in the initial release of NetWare 5. Likewise, Compatibility Mode requires no mandatory configuration in the initial release; however, optional configuration parameters may be added in future versions to support various features such as SAP filtering.
Issues to Consider in Preparing for a Migration from IPX to IP
With network sizes ranging to thousands of servers in many installations, network administrators are considering a phased approach to IP network migration. While there are other alternatives such as Single Protocol TCP/IP, TCP-only, and multiple level implementations, we will focus on a Compatibility Mode implementation. In doing so, we recognize that other considerations such as SLP, DHCP, and multicast, will also affect the way administrators configure their systems. However, these considerations are beyond the scope of this discussion.
There are four basic migration options:
Leveraged segment migration
The first two migration options involve removing IPX on a segment-by-segment basis. This can be done simply by starting at one end of the network and working through each segment sequentially, or it can be done in a leveraged fashion beginning with the most strategic segments. Again, Compatibility Mode and the Migration Gateway greatly facilitate these types of migrations.
The backbone migration was alluded to earlier in this AppNote. It involves leaving IPX in place on local segments while moving to only IP on the WAN backbone infrastructure. The main reason for doing a backbone migration first is to eliminate multiple protocols on the routers, since configuring routers for multiple protocols is often expensive. Of course, considering the number of protocols that could exist, administrators are somewhat limited in the choices they can make to eliminate protocols. For instance, even though Apple has stated it will not do any further updates to the AppleTalk protocol, that protocol is not likely to go away very soon in networks that support Macintosh computers.
This example highlights the so-called link problem. Hypothetically speaking, if you turn off the router settings for IPX on an IP backbone, you form an "island" of IPX. At that point, there is no way to pull information about the existing services out of the IPX segment and disseminate it across the network. However, in practice, Compatibility Mode actually allows you to do exactly that: establish islands of IPX, while the information on existing services continues to flow all the way to the ends.
As a fourth option, Compatibility Mode offers customers an immediate but small scalability solution for IP migration: implementing NetWare/IP in IPX client-server networks. This is basically a coexistence environment in which clients of the IPX or NetWare/IP network can communicate with a Native IP server, and Native IP clients can communicate with an IPX-based server or with a NetWare/IP server.
Customer configurations may dictate various combinations of these options to arrive at an appropriate solution. Using both Compatibility Mode and the Migration Gateway, any aggregation of protocols, packet information, and addressing is plausible between segments, for any combination of clients and servers.
Support for Existing IPX Applications
Most IPX-based NetWare or NetWare/IP networks are used for mission critical applications, so the time it takes to develop new or modified applications for another protocol is a critical factor which may well determine the feasibility of migration. In the past, protracted application development time has been a deterring factor in migrating IPX-based applications.
IPX-based applications rely on SAP and RIP for service and route advertisements. Since SAP and RIP are specific to the IPX protocol, such applications would need to be rewritten to work in an IP-only environment. However, due to the time and effort involved, rewriting existing applications should be a long-term strategy. Compatibility Mode allows IPX-based applications to operate across IP networks without having to be rewritten.
A small number of IPX-based applications (less than 5%) have been developed using IPX hooks directly, instead of going through NCP and the normal methods of communication. This practice is known informally as using "dirty hooks." Compatibility Mode can allow even these types of applications to run due to its ability to encapsulate IPX within IP. When Compatibility Mode encounters such an application, it will capture the IPX traffic and encapsulate it into IP packets to avoid compromising the IP-only environment.
Many Novell customers have NetWare 3.x servers installed on their networks. In IPX networks, SAP information is used to populate the NetWare 3.x server bindery. Even though there is no SAP in the IP-only environment, IPX clients still expect a full bindery. Compatibility Mode allows for backward compatibility to the NetWare 3.x bindery by including a Bindery Agent in the Migration Gateway. The Bindery Agent is responsible for populating the bindery by transforming dynamic bindery objects into static ones and placing them into NDS. Thus, legacy IPX applications that depend on the bindery can still find the object information (from NDS) that they need to function properly. In this way, NetWare 5 minimizes traffic on the wire, while still providing on-demand IPX functionality.
In most enterprises, the migration to IP has already started. This migration has proven to be extremely costly, especially for customers that have a large investment in IPX-based applications and resources. With NetWare 5, Novell is mitigating the cost of this migration by making it possible for you to continue to utilize your investment and at the same time make the network more manageable by deploying a single protocol.
NetWare 5's IP Compatibility Mode and Migration Gateway features provide an immediately-viable solution for supporting existing IPX-based applications during a migration from IPX to IP. They allow a controlled segment-by-segment migration or backbone isolation of IPX LANs while maintaining cross-boundary interoperability, giving organizations time to update or modify their applications.
With Novell's IP migration tools, IPX communications at the protocol level can disappear from the network, while maintaining the visibility of legacy IPX-based applications. For those making the transition to a single protocol (IP-only) environment, NetWare 5 allows administrators to migrate to TCP/IP at their convenience, while ensuring continuous user access to network services.
For maximum flexibility, customers can leverage the strengths of both the TCP/IP and IPX/SPX protocols in the same integrated solution. For example, they can take advantage of the speed and openness of IP for wide-area networking and the management simplicity of IPX for local network traffic.
Novell believes that the need for Compatibility Mode will diminish over time as applications eliminate direct dependencies on IPX. Until that happens, NetWare 5's implementation of Pure IP and Compatibility Mode allows customers complete control over both the degree and the rate of change in their integration of their existing networks into global, IP-only LAN, WAN, Internet/intranet solutions.
* Originally published in Novell AppNotes
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.