Migrating to Pure IP With NetWare 5
Articles and Tips:
01 Sep 1998
Unlike previous versions of NetWare, NetWare 5 can run over the IPX/SPX stack, the TCP/IP stack, or both. Previous versions of NetWare depend on the IPX/SPX stack for NetWare Core Protocol (NCP) services, such as file reads and writes, user login and authentication, and Novell Directory Services (NDS) synchronization. Because customers wanted to implement TCP/IP-only networks, Novell developed pure IP, which offers NCP services natively over the TCP/IP stack.
The termsnativeandpureimply that encapsulation is not required. In NetWare 5, pure IP allows NCP to sit directly on top of User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) headers and use IP services for discovery, addressing, and data-transfer operations. With NetWare/IP, however, IPX packets are encapsulated within UDP/IP headers.
To help companies migrate to pure IP or to configure a network that supports both IPX/SPX and TCP/IP, NetWare 5 offers the following three options:
Compatibility mode server process
Compatibility mode client process
Migration agent
COMPATIBILITY MODE SERVER PROCESS
By default, the compatibility mode server process runs on every NetWare 5 server to support any server-based applications that are IPX dependent. This process translates IPX communications--such as Service Advertising Protocol (SAP) queries, SAP broadcasts, and IPX packets--into the pure IP format. For example, suppose that a NetWare Loadable Module (NLM) relied on SAP broadcasts to announce its presence on the network, enabling workstations to discover this NLM. If you had a pure IP network, you would not want NLMs transmitting SAP traffic.
The compatibility mode server process would redirect SAP broadcasts to the Service Location Protocol (SLP) process running on the NetWare 5 server. The SLP process would register the IPX-dependent NLM, enabling workstations to discover this NLM just as they discover IP services. The NLM would be unaware that its service announcement had been redirected. (See Figure 1. For more information about SLP, see "Service Location Protocol: Discovering Services in a Pure IP Environment," NetWare Connection, July 1998, pp. 32-37. You can download this article from http://www.nwconnection.com/ jul.98/slp78.)
Figure 1: The compatibility mode server process allows you to run IPX-dependent NLMs on a pure IP network.
COMPATIBILITY MODE CLIENT PROCESS
By default, the compatibility mode client process runs on all NetWare 5 clients. This process ensures that IPX-dependent applications running on NetWare 5 clients transmit only IP communications. For example, if a printer driver were IPX dependent and required a SAP broadcast to locate a print server, the compatibility mode client process would change this SAP query to an SLP query. (See Figure 2.)
Figure 2: The compatibility mode client process allows users to run IPX-dependent applications on their workstations.
MIGRATION AGENT
The migration agent enables you to maintain a mixed IPX and IP network, providing a gateway between two environments: NCP-IPX and NCP-IP. The migration agent enables users on a pure IP network to access services located on an IPX network. Likewise, the migration agent enables users on an IPX network to access services located on a pure IP network.
Figure 3 shows how you can use the migration agent to connect an IPX network and a pure IP network. The FS1 server on the pure IP network is running NetWare 5, and both the server and the client are configured to support only NCP over IP. Although the IPX stack is not loaded on the server or the client on the pure IP network, both the server and the client are running the compatibility mode process. The FS2 server on the IPX network could be running NetWare 2, NetWare 3, NetWare 4, or NetWare 5 (config ured to support only NCP over IPX).
Figure 3: The migration agent allows users on a pure IP network to use the resources on an IPX network, and vice versa.
To enable these two networks to communicate with one another, the company has loaded the migration agent on a NetWare 5 server, which is acting as a gateway between the two networks. The migration agent provides protocol translation services, changing IPX-based queries into pure IP-based queries. As a result, Jillian on the IPX network could access services that resided on the pure IP network. (See Figure 3.)
Configuration Options
The SCMD NLM provides both the compatibility mode server process and the migration agent. Although the compatibility mode server process is enabled by default, you must manually enable and configure the migration agent. To enable the migration agent, you load the SCMD NLM reentrantly by entering one of the following commands:
LOAD SCMD.NLM /G
You would use the /G option if you wanted to configure a migration agent to connect one IPX network and one pure IP network. (See Figure 3.)
LOAD SCMD.NLM /BS
You would use the /BS option if you wanted two disconnected IPX networks to communicate through a pure IP network, as shown in Figure 4. In this case, you would use the /BS option to configure a migration agent for both IPX networks, enabling these migration agents to exchange SAP and Routing Information Protocol (RIP) information about the disconnected IPX networks.
Figure 4: By using the LOAD SCMD /BS command, you can configure disconnected IPX networks to communicate through an IP backbone, such as the Internet.
In Figure 4, for example, two disconnected IPX networks are communicating through the IP-based Internet. If you loaded the SCMD NLM with the /BS option, the migration agents would encapsulate IPX packets inside IP, thus enabling these disconnected IPX networks to communicate.
Because most companies will probably load the SCMD NLM with the /G option to connect an IPX network directly to a pure IP network, the remainder of the article focuses on this configuration.
THE MIGRATION AGENT IN ACTION
The migration agent performs the following five functions:
Registers migration agent services with an SLP service agent. (AnSLP service agentworks on behalf of a service to respond directly to queries for specific services. For more information about SLP service agents, see "Service Location Protocol,"NetWare Connection.)
Registers SAP services with an SLP service agent.
Unencapsulates and forwards SAP queries to an IPX network.
Unencapsulates and forwards RIP queries to an IPX network.
Encapsulates and unencapsulates IPX traffic that is coming from or going to a pure IP network.
Registering Migration Agent Services With an SLP Service Agent
A migration agent registers its services with a local SLP service agent, making these services available to devices on the pure IP network. In Figure 3, for example, the migration agent would register its services with the FS1 server.
Sometimes a NetWare 5 client running the compatibility mode client process might require the services of the migration agent. In this case, the NetWare 5 client would use SLP to discover the migration agent.
Registering SAP Services With an SLP Service Agent
As the translator between an IPX network and a pure IP network, a migration agent receives SAP broadcasts from the IPX network. For example, the FS2 server in Figure 3 would send a SAP broadcast every 60 seconds on the IPX network, announcing the server's file, directory, and other services. After receiving this SAP broadcast, the migration agent would send an SLP packet to the SLP service agent, registering the server's services.
If a NetWare 5 client running the compatibility mode client process wants to use an IPX service, this client sends an SLP query to the SLP service agent. The SLP service agent then returns the network address of the device providing the requested IPX service.
Unencapsulating and Forwarding SAP Queries to an IPX Network
If a NetWare 5 client running the compatibility mode client process queries an SLP service agent for an IPX service and that service is not registered with the SLP service agent, this client can encapsulate a SAP query inside IP and send the query directly to the migration agent. The migration agent, in turn, unencapsulates the SAP query and forwards it to the IPX network. The migration agent then encapsulates the SAP reply inside IP and sends this reply to the requesting NetWare 5 client.
Unencapsulating and Forwarding RIP Queries to an IPX Network
After a NetWare 5 client running the compatibility mode client process locates an IPX service, this client encapsulates a RIP query inside IP and sends the query directly to the migration agent. Next, the migration agent unencapsulates the RIP query and forwards it to the IPX network. The migration agent then encapsulates the RIP reply inside IP and sends this reply to the requesting NetWare 5 client.
Encapsulating and Unencapsulating IPX Traffic
If a NetWare/IP client exists on a pure IP network, the migration agent can unencapsulate IPX packets and forward them in native IPX format to the IPX network. For example, if a NetWare/IP client resided on a pure IP network, this client would encapsulate IPX packets within a UDP/IP header.
When a NetWare/IP client needs to locate a service on an IPX network, the client sends a SAP request to the migration agent. The migration agent then unencapsulates the SAP request and sends it in its native IPX format onto the IPX network.
CONCLUSION
NetWare 5 offers several options to help you migrate your company's network from IPX to pure IP. The compatibility mode processes allow you to run IPX-dependent NLMs and applications on a pure IP network. The migration agent translates protocols between a pure IP network and an IPX network. As a result, you can continue to use IPX-dependent NLMs and applications and you can migrate some segments of your company's network to pure IP while maintaining IPX on other segments. Users on the IPX network can then continue to use services on the pure IP network, and vice versa.
Laura Chappell is the senior protocol analyst for the Network Analysis Institute. Laura provides onsite protocol and application analysis and teaches communications analysis. You can reach Laura via e-mail at lchappell@netanalysis.org.
NetWare Connection,September 1998, pp. 34-37
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.