[an error occurred while processing this directive]

How to transition from IPX to pure IP
Deployment Guide
Reader Rating    from ratings rate this article
View a PDF Version of this Document View a Printer Friendly Version of this Page Send this page to a friend
Contents
Moving To A Pure IP Environment
Why Move?
The Path To Pure IP
How Novell Addressed IPX-Dependent Services
Maintaining IPX Services Temporarily In A Pure IP Environment
Additional Information
Moving To A Pure IP Environment

With the release of Novell® NetWare® 5 (and above), you can now move to a pure IP environment, even if you are still using NetWare Core Protocols. That's because in NetWare 5 (and above), all NetWare Core Protocols can use the TCP/IP transport protocol giving you the ability to run in a pure IP environment-pure in the sense that it doesn't retain an IPX-based encapsulation (or, in the case of NT Server, a NetBIOS encapsulation).

Why Move?

Why would you want to move to a pure IP environment? There are many possible reasons, including:

  • To simplify your routing infrastructure by moving to a single protocol.
  • To create a more uniform WAN and remote connectivity options.
  • Your router vendor may charge more for support and upgrades of multiple protocols.
  • To reduce the load on NetWare/NDS® servers that currently support the IPX protocol and its Name Space Providers, Bindery and SAP.

The following section of this document, "The Path To Pure IP," describes a step–by-step procedure for moving to pure IP. Novell developed this procedure in migrating their large, global network to pure IP. (During the transition, Novell migrated over 750 servers and more than 6,000 workstations.) In some of the steps, Novell's approaches to some of the tasks are pointed out to help you address certain issues.

In some cases, you will need to continue to maintain IPX services temporarily in your new pure IP environment. The section of this document, "Maintaining IPX Services Temporarily in a Pure IP Environment," describes a practical solution.

The Path To Pure IP

Once you've decided to make the transition to Pure IP you need to answer two questions:

  1. What are your IPX dependencies?
  2. How quickly do you need to make the transition?

The answer to the first question is important because your ultimate goal is to eliminate all IPX dependencies. The answer to the second question determines whether you must move your entire network to pure IP all at once, or whether you can make the transition in phases.

You can move from an IPX environment (or a mixed IPX/IP environment) to a pure IP environment by performing the 12 steps presented in this section.

Helpful Documentation

Migrating to Pure IP with NetWare 5

Migrating from NetWare/IP to NetWare 5 and Pure IP

Protocols and ports used
by NetWare 5 IP

Step 1. Implement TCP/IP Routing, Security and Management

To make the transition to pure IP, you must begin to route the protocol. But before you route your first IP packet, you should have a TCP/IP security infrastructure (such as firewalls) in place. If you have already been using TCP/IP, you may already have a security infrastructure in place.

You'll also need tools to monitor the health of your TCP/IP network. If you have already been using TCP/IP, you may already have a monitoring infrastructure in place. You may also be able to use some of the tools you have for monitoring the health and performance of your IPX network to monitor your IP network.

You may also need to tweak your network to accommodate the new TCP/UDP ports used by NetWare 5:

TCP 524-NCP Requests-Source port will be a high port (1024-65535).

UDP 524-NCP for time synchronization-
Source port will be a high port.

UDP 123-NTP for time synchronization-
Source port will be the same.

UDP 427-SLP Requests-Source port will be the same (427).

TCP 427-SLP Requests-Source port will be the same (427).

TCP 2302-CMD-Source port will be a high port.*

UDP 2645-CMD-Source port will be the same (2645).*

*These ports are only necessary if your organization is planning to use CMD as part of the IPX to IP Migration strategy.

Step 2. Implement DNS/DHCP

DNS allows you to refer to network resources by user-friendly DNS names rather than obscure IP addresses. With NetWare 5, you can access a server using its IP address or fully-qualified DNS name.

Anyone who has had to manage IP addresses on a large scale is probably already familiar with the IP address management simplification provided by DHCP. DHCP is especially useful with NetWare 5 because it not only simplifies the assignment and administration of client IP addresses, but also allows you to distribute Novell Client configuration information such as Preferred Tree, Preferred Server, SLP Directory Agent addresses, SLP Scope and Migration Agent addresses.

DHCP also simplifies network usage.
For example, you can use DHCP to give clients the name of the corporate tree, the name of a local server holding replicas, any local Directory Agents and other information. That allows users to login from any location without wrestling with IP settings or client configuration.

Step 3. Design SLP Implementation

Running NetWare in a pure IP environment eliminates IPX SAP packets. IPX SAP provides two services: dynamic discovery and the ability to use short names. As a result, in a pure IP environment, you'll have to deal with name resolution.

In the IPX world, if you want to attach to a particular server, you don't need to know where that server is located, its IP address, its domain, or the NDS context in which the server resides. You simply refer to the server by its short name.

Helpful Documentation

Novell DNS/DHCP Services: Design Issues and Troubleshooting

SLP Deployment Guide

An overview of SLP

Dynamically Discovering Services on an IP Network with SLP

This is not the case in the world of Pure IP. For example, if you want to get to Yahoo's Web site, you can't simply type the word "yahoo" into your browser. Instead, you must type the Yahoo Web server's fully qualified DNS name: www.yahoo.com.

The opposite is also true, that is, you can refer to a single server by any number of names. For example, in the IP world you can refer to the Novell GUI Map utility that maps a drive to the server on your desk, in a number of ways:

Use the fully qualified DNS name: \\serverut.provo.novell.com\sys

Use the fully qualified NDS name: \\novell_inc\.serverut_sys.gta.prv.novell

Use the IP address: \\xxx.xx.xxx.xxx\sys

Using SLP to provide dynamic discovery in a Pure IP environment can go a long way toward easing the transition from IPX. With SLP, you can refer to the server in the above example in the same way that you have been using with IPX, that is, with the server's short name: \\serverut\sys SLP resolves short names by looking for an SLP object type of "bindery.novell" with that particular name.

At this point, you should design your SLP implementation in preparation for deploying SLP in the following step (Step 4) as you upgrade your servers to NetWare 5. To design your SLP implementation, you need to perform the following steps:

  1. Determine the number of Directory Agents (DAs) to host the scope(s).
  2. Partition the SLP Scope Units in the tree and ensure that the servers designated to run the DA service hold replicas of all Scope Units that they service.

DNS resolves short names by taking the name and concatenating the current DNS sub-domain onto the end. For example, prv-botanica becomes prv-botanica.provo.novell.com.

NDS resolves short names by taking the name and concatenating the current NDS context. (For example, prv-botanica becomes
prv-botanica.gta.prv.novell.)

The Windows NT client requests information from all of the Name Service Providers at once and uses the one that responds first.

Step 4. Upgrade To NetWare 5

In this step you will upgrade your servers and clients to NetWare 5, and at the same time implement the SLP design you developed in Step 3.

Novell offers an Education course-Course 529 NetWare 4.11 to NetWare 5.1 Update-to help you upgrade from NetWare 4.11 to NetWare 5. You'll find information on this course at: http://novell.netpub.com/cgi-bin/edcatalog/ilt_one_sresult?m=689

Upgrade servers to NetWare 5

You need to upgrade your servers to NetWare 5 including the currently recommended service pack.

NOTE: The first server you upgrade should be a replica of the root partition. The next servers you upgrade should be the servers you will use as the SLP DAs for the environment. You need to implement SLP on each of these servers after you upgrade that server to NetWare 5. To do so, perform the following steps:

How Novell implemented SLP

Novell implemented SLP on a per site basis. Novell decided on this approach because not rolling out an enterprise-wide SLP implementation would allow each site to migrate from IPX to IP independently of the other sites on the network.

At smaller sites (less than 100 clients), Novell did not install a Directory Agent and simply allowed the individual systems to use multicasting to advertise their presence and look for services. At larger sites, Novell installed two Directory Agents (for redundancy and load balancing), but that SLP information was replicated only locally. Using SLP locally allows it to provide dynamic discovery of local resources (the resources users are most likely to need). Novell then trained users to use fully-qualified DNS names to perform such actions as login and drive mapping.

Novell standardized on fully-qualified DNS names, using DNS as the primary name resolver (followed by NDS, SLP, and then, if all else fails, local host files). That's because DNS is the only naming standard that is independent of the user's location and the location of the desired network resource. Fully-qualified DNS names work everywhere. For example, DNS works regardless of whether the user is mapping a drive locally, across the Internet from a customer site, via a VPN client, or dialing in with RADIUS.


Helpful Documentation

SLP Console and Set Commands

SLP, How to use it with DNS and DHCP

TIDs: These documents can be found by searching at: Click Here

TID 10025313-
Frequently Asked Questions about SLP

TID 10014396-
"SLP Terms and Configuration Reference"

TID 10014467-
"Configuring a LAN/WAN infrastructure for SLP"

TID 10014466-
"Configuring SLP for a NetWare Client"

TID 10027163-
"Configuring SLP for a NetWare Server"

  1. Load the SLP DA service.
  2. Configure/tune the various server SLP SET parameters (Set the NCP PROTOCOL PREFERENCES = TCP IPX UDP. You must also put in the AUTOEXEC.NCF because it is not persistent between server reboots).
  3. Configure the SLP.CFG on every NW 5.x server (define the 2 "closest" DAs in the SLP.CFG, REGISTER TYPE commands for regional vs. global scoping).

You can then upgrade all remaining servers to NetWare

NOTE: When upgrading your servers to NetWare 5, Novell recommends that you run both IP and IPX during the transition to pure IP, that is, run a dual stack. That enables your NetWare servers to communicate with both your IP-based clients and services, and your IPX-based clients and services during the transition. The dual stack approach helps ensure a smooth migration from IPX to pure IP.

Upgrade Clients To NetWare 5

You need to upgrade your clients to NetWare 5. In addition, although it is not necessary to do so at the time you upgrade your servers to NetWare 5, you should perform the client-side configuration for SLP. This may require you to reinstall the client if is not currently installed with IP support.

NOTE: When upgrading your NetWare Clients to NetWare 5, you may want to ensure that they can run both IP and IPX if you need the two protocols to coexist during the transition to pure IP. That ensures that your NetWare Clients can communicate with your IP- based servers and services, and with your IPX-based servers and services during the transition.

Helpful Documentation

For information on Automatic Client Upgrade (ACU), search support.novell.com for "ACU" or look in the Novell Client documentation.

How Novell Deployed DNS and DHCP in its Global Network

Step 5. Set Up DNS

Set Up DNS Entries for All NetWare 5 Servers

You need to set up DNS entries for all NetWare 5 servers. This will allow DNS to provide name resolution when dealing with your new IP-based servers. (Name resolution will be discussed in more detail in Step 7.)

Convert Server Names in Login Scripts to Fully-qualified DNS Names

Once you turn off IPX, referring to servers by their short name will no longer work. Therefore, it is important that you convert the server names in all login scripts to fully-qualified DNS names.

Step 6. Identify IPX Dependencies and Transition Those Services To IP

Your largest source of IPX dependencies will probably be NetWare, NDS and Printing (queue-based printing is IPX-based) on your NetWare 4.x servers. Depending on your tree design, NDS background processes may require that all the servers in your tree be able to communicate with all the other servers in the tree.

Rather than researching, diagramming and coordinating which servers must talk to which servers, it's easier to allow servers to continue to communicate via IPX until they can all communicate via IP. That's why Novell recommends taking the dual stack approach in Step 3.

Although upgrading all servers to NetWare 5 typically eliminates most IPX dependencies, you still need to look at all of the other network services you have to see what IPX dependencies they may have.

Some applications make the transition to a Pure IP environment easier than others. For example, with Novell GroupWise®, all you have to do is set the clients to use client/server mode. Other applications, however, are not that easy.

Although some services may not use IPX on the client side, they may have IPX hooks in their management pieces. Some services may use IPX for dynamic discovery to show a list of available servers in a dialogue box, or they may be able to communicate with the server via IP, but they may rely on SAP (Service Advertising Protocol) to actually discover the address of the server.

You will also need to check for short name dependencies. Some applications may not be capable of referring to servers by their fully-qualified DNS names, and depending on your setup, short name resolution may not work enterprise-wide. Step 6 will help you resolve this problem.

For help in ferreting out the IPX dependencies in your network, you can use the NetWare IPXCON utility to see what SAPs are out on the wire. Two other useful tools are SAP List and SAP Snoop. You can find utilities that will help you detect SAPs at: http://www.netwarefiles.com/ and at http://www.novellshareware.com/

How Novell Trained Users

You need to give users a way to determine the fully-qualified DNS names of servers. Novell did this by creating a simple but effective CGI script that allows a user to type in the short name of any server.
In response, the script returns the fully-qualified DNS name for that server.

Step 7. Convert to Fully-qualified DNS Names

Convert Login Scripts to Use Fully-qualified DNS Names

In this step, you must convert login scripts to use fully-qualified DNS names. For example,

Change the script line:

map z:=s16:=\\prv botanica\sys\public

to:

map z:=s16:=\\prv- botanica.provo.novell.com\ sys\public

Train Users to Use Fully-qualified DNS Names

You must train users to use fully-qualified DNS names in performing such operations as login and drive mapping.

How Novell Addressed IPX-Dependent Services

The table below shows some of the services that Novell had to migrate in moving the Novell network infrastructure to pure IP. The table also shows the solutions on which the company standardized at the time of transition.

Service Product 
Anti-Virus McAfee NetShield 4.0.x
Backup BackupExec 8.0 (Build 251)
Caching/Proxy Novell BorderManager® 3.0
DNA/DHCP Novell DNS/DHCP 3.0
E-Mail/Messaging GroupWise 5.5
FTP NetWare NFS 2.4
Network Management ManageWise 2.6, HP OpenView 5.01
NFS NetWare NFS 2.4
Printing NDPS
Remote Access (RADIUS) Novell BorderManager 3.0
Web Server Netscape Enterprise/Fastrack Server for NetWare

Step 8. Change Timesync Time Sources to Use IP Addresses

Timesync doesn't currently resolve fully-qualified DNS names. In this case you must specify an
IP address.

Step 9. Turn Off IPX SAP at the Routers

This step does not shut down IPX entirely. It turns off only IPX SAP. You need to continue to route IPX RIP until you have upgraded every server in the tree to NetWare 5.

NOTE: Before performing Step 9, you should make sure that there are no other services using SAP.

Remember, SAP packets and IPX packets are not equivalent. SAP is merely the aspect of the protocol that provides service advertisement.
It is analogous to a telephone directory in that it simply maps server names into server addresses. IPX RIP, on the other hand, is used to transfer information from point A to point B.

To ensure the network remains operational, turn off SAP using the following procedure:

  • Turn off SAP at the routers.
  • Wait for 5-10 minutes.
  • At the server console, enter RESET ROUTER a few times.
  • Wait a few more minutes.
  • At the server console, enter DISPLAY SERVERS. You should see only a list of IPX servers from the local site.
  • At the server console, enter DISPLAY NETWORKS. You should see the full list of IPX networks on both sides of the router, not just the IPX networks from the local site.

This step provides a good test for IPX dependencies. Once you've turned off SAP at the routers, you may find that some applications that you assumed didn't have IPX dependencies actually do have IPX dependencies.

Step 10. Check NDS Synchronization

Go into DSRepair and force a synchronization to make sure that NDS is synchronizing properly without SAP.

Step 11. Verify Client Logins

At this point, you should make sure that users can still login to the network. Make sure that both container and personal login scripts are working properly.

Step 12. Turn Off IPX At The Servers

Finally, turn off IPX on every server.

NOTE: Do not perform this step until you have upgraded every server in the tree to NetWare 5.

Congratulations, you have just made the transition to pure IP.

Maintaining IPX Services Temporarily In A Pure IP Environment

In some cases, you will have to maintain IPX services temporarily in your new pure IP environment. That could be due to a variety of reasons. For example, you may not be able to migrate all your servers to NetWare 5 in the time allotted for transition to pure IP, yet you still need to be able to access those resources from areas that are pure IP. In these cases, you must allow your IPX-dependent services to continue to function in a world where IPX no longer exists, until you can move them to IP.

NetWare 5 provides a solution-the NetWare 5 Migration Agent-a NetWare 5 server running Compatibility Mode Drivers (CMD) with the Migration Agent option enabled. The Migration Agent lives in the IPX world and acts as the intermediary between the IP and IPX worlds. It allows IP-only clients and servers to communicate with their IPX-based counterparts, and vice-versa.

Useful Documentation

Configuration Parameters
for the Compatibility
Mode Driver

SCMD: Frequently
Asked Questions

To take advantage of the NetWare 5 Migration Agent, you must be running IPX Compatibility Mode Drivers (IP/CMD) on all clients and servers that reside in the IP-only world. If applications on these IP-only devices make an IPX call or communicate with IPX devices, the CMD drivers intercept the IPX call, encapsulate it in an IP packet and route it to the Migration Agent.
The Migration Agent accepts that request and makes the IPX call on behalf of the IP-only device, receives an IPX response and then delivers that response back to the original requester via IP.

The Migration Agent also translates between IPX SAPs and SLP. It takes IPX SAPs and registers these advertised services with the Directory Agents so that they are available via SLP to IP-only devices. The Migration Agent also takes the SLP information from the IP-only devices and broadcasts SAPs on their behalf so they are visible to the IPX services.

Additional Information

For additional information on day-to-day management of Novell NetWare, product features, Q&A, etc. please see the following links:

© Copyright 2001, Novell, Inc. All rights reserved. Novell is a registered trademark of Novell, Inc. in the United States and other countries.