Novell is now a part of Micro Focus

Migration Strategies for Upgrading IPX and NetWare/IP Networks to Pure IP

Articles and Tips: article

RAJAYOGASRI P
Software Consultant
Server Communications Group, NPGB

HARINATH SUBRAMANIAM
Worldwide Support Engineer
Novell Customer Services

01 Jun 1999


This AppNote is for those who've been anxiously anticipating a move to NetWare 5 and Pure IP but aren't quite sure how to go about migrating from their existing IPX or NetWare/IP networks.

Introduction

One of the most compelling features of NetWare 5 is its ability to run in a Pure IP environment. It is "pure" in the sense that it doesn't retain any IPX-based encapsulation. Communication between IP-based clients and servers occurs via the TCP/IP transport protocol. In fact, for NetWare 5 the NetWare Core Protocols (NCPs) were rewritten to use TCP/IP natively. Of course, for backward compatibility, NetWare 5 also provides support for the traditional IPX transport protocol. This allows customers to select the protocol that best fits their needs: IPX, Pure IP, or any combination thereof.

Many customers who already have mixed IPX and IP networks have implemented NetWare/IP as a means for IPX and IP applications to intercommunicate. While NetWare/IP remains an effective solution for NetWare 4 networks, those wanting to upgrade to NetWare 5 are faced with the challenge of migrating from their existing IPX or NetWare/IP networks to a Pure IP environment.

This AppNote is targeted to network administrators and technicians interested in undertaking such a migration. It discusses general migration strategies and provides guidelines for converting IPX and/or NetWare/IP networks into Pure IP. However, it does not explain how to set up Compatibility Mode (CMD) and configure it. It is assumed that the reader is familiar with CMD concepts, network setup, and configuration. For more information, refer to the related AppNotes listed at the end of this AppNote.

This information is not specific to any particular customer network scenario. You will need to fine tune the strategies presented to suit the needs of your own network.

The information in this AppNote replaces that presented in "Migrating from NetWare/IP to NetWare 5 and Pure IP"published in the February 1999 issue.

Why Migrate to NetWare 5 and Pure IP?

NetWare 5 supports the traditional NetWare services, including the NetWare Core Protocols, in a Pure IP environment. Using IP as the default protocol has several advantages over IPX:

  • It allows better interoperability between NetWare services and today's Internet/intranet solutions.

  • In routed environments, a single protocol requires less hardware and software.

  • The more efficient use of bandwidth increases network performance and lowers cost.

  • Less management is required to support a single protocol on the client.

Even though Pure IP is the primary transport protocol provided in NetWare 5, customers still have the option of using IPX as their transport protocol. However, for many customers the goal is to eventually eliminate IPX where it is not needed and use standard protocols whenever possible.

NetWare 5 gives IPX and NetWare/IP customers the option of moving to Pure IP to take advantage of the benefits listed above. The main objective is to provide a smooth migration from IPX and NetWare/IP to Pure IP. By smooth, we mean the following:

  • The ability to do a phased migration, but maintain full connectivity throughout the process

  • No disruption of network service visibility and accessibility during the migration

  • Reducing the amount of administrative overhead required

  • Keeping the migration as transparent as possible for users

The IPX Compatibility Mode Driver (CMD) provided with NetWare 5 facilitates this by providing compatibility between the IP and IPX protocols on the same network. Likewise, the Migration Agent (MA) allows all routes and services from a Pure IP segment of a network to be communicated to and be accessible from the IPX side of the network, and vice versa. However, CMD and MA are simply components which make the migration possible. To ensure a successful migration, a complete strategy is essential.

Typical Network Scenarios

This AppNote presents migration strategies for various scenarios that we have identified as being typical. Customers should examine these scenarios and identify which ones best match their network configuration. The chosen migration strategy can then be implemented, with any necessary fine tuning.

Depending on the protocol used on the network, customer networks can be classified into the following two categories:

  • NetWare/IP networks

  • IPX networks

It is assumed that most customers have an overall network configuration where local segments at central and regional offices are connected via WAN links. Figure 1 depicts such a configuration.

Figure 1: Typical customer network configuration.

For convenience, we will focus on subsets of this configuration and propose migration strategies for various scenarios within these subsets. Since the entire configuration can be considered as multiple instances of the same subset or a combination of scenarios, an overall migration strategy can be devised by combining the migration strategies for the individual subsets.

NetWare/IP Customer Scenarios

For NetWare/IP networks, the subset we will focus on is two local segments connected via a WAN link (see Figure 2).

Figure 2: A subset of the NetWare/IP customer configuration.

Based on how NetWare/IP has been implemented on their network, NetWare/IP customers can have any of the following scenarios in their configuration:

  • NetWare/IP on WAN only, IPX on LAN

  • NetWare/IP on WAN and LAN

  • NetWare/IP on WAN, mixed IPX and NetWare/IP on LAN

Following are descriptions of each scenario, along with a brief discussion of how the segments are connected.

Scenario 1: NetWare/IP on WAN Only, IPX on LAN

In the scenario depicted in Figure 3, the local segments have only IPX servers and clients attached. Two (or more) NetWare/IP forwarding gateways connect the segments across a WAN link using NetWare/IP.

Figure 3: NetWare/IP on WAN only, IPX on LAN.

The DSS could be located at either one of the sites or at both sites. The DSS may be loaded on the same computer as a NetWare/IP forwarding gateway, or on a different computer.

Scenario 2: NetWare/IP on WAN and LAN

In the scenario depicted in Figure 4, NetWare/IP is the transport protocol used on both the WAN and the LAN. In addition to the IPX server and clients, there are NetWare/IP servers and clients on the local segments.

Figure 4: NetWare/IP on WAN and LAN.

Two (or more) NetWare/IP servers connect the local segments via a WAN link. These NetWare/IP servers do not have to be configured as forwarding gateways.

Scenario 3: NetWare/IP on WAN, IPX/NetWare/IP Mixed on LAN

In the scenario depicted in Figure 5, NetWare/IP is the transport protocol used on the WAN. Both IPX and NetWare/IP servers and clients are present on the local segments. Both IPX and NetWare/IP protocols are used on the LAN segments.

Figure 5: NetWare/IP on WAN, mixed IPX and NetWare/IP on LAN.

Two NetWare/IP forwarding gateways connect the local segments across a WAN link using NetWare/IP.

Migration Strategies for NetWare/IP Scenarios

The idea behind migrating to Pure IP is to ultimately remove IPX and its overhead from the network. The general migration strategy and guidelines proposed for the three NetWare/IP scenarios are based on the following assumptions:

  • The LAN segments will be migrated to Pure IP first.

  • Since NetWare/IP is already implemented on the WAN, the WAN can be migrated to Pure IP last.

  • Leaving NetWare/IP on the WAN will not be of concern while the LAN segments are being migrated.

Scenario 1: NetWare/IP on WAN Only, IPX on LAN

Two approaches are proposed for this scenario: a dual stack approach and a CMD approach. Each approach has its own advantages and disadvantages. Customers can evaluate the effectiveness of an approach based on the following factors:

  • How easy is it to adopt the approach?

  • How expensive is the approach in terms of administration and changes?

  • How risky is the approach?

  • How quickly can customers reap the benefits of Pure IP?

Dual Stack Approach. The basic idea behind this approach is to let both IPX and IP protocols exist together throughout the migration period. (see Figure 6).

Figure 6: Using the dual stacks approach, both IPX and IP applications are supported through their native protocols on the LAN segment.

With both IPX and IP protocols active on the wire, NetWare 5 servers and clients can support IPX and IP applications through the respective protocol stacks. Once the migration is complete, IPX can be disabled on all the servers and clients.

The migration strategy guidelines based on this approach are outlined below.

  1. Start upgrading the servers to dual stacks on the local segments. In this scenario there is normally one DSS server per segment, which may reside on the same server node as the NetWare/IP forwarding gateway. It is a good idea to upgrade the DSS server last.

  2. Start upgrading the clients to dual stacks on the local segments. The client and server upgrades can happen in parallel, but you should preferably upgrade the majority of the servers before upgrading the clients. During much of the migration, most of the communication will occur over IPX.

  3. During the migration, all servers remain connected and accessible because of the dual stacks. Dual-stack NetWare 5 clients communicate with NetWare 5 servers over IP, and with IPX servers over IPX. Older clients still use IPX to communicate with the upgraded servers, as illustrated in Figure 7.

    Figure 7: In NetWare/IP Scenario 1, this is how communication occurs during a migration using the dual stacks approach.

  4. Once the migration to Pure IP is complete on all the local segments, start migrating the WAN segments one by one. You cannot proceed with this dual-stack migration approach on the WAN until all the servers and clients in the entire organization have been migrated to NetWare 5. This is required because, at any given time, a server running NDS may need to communicate with any other server in the same tree. This will not be possible if the servers are not using the same transport protocol for communication.

    To migrate a WAN segment, begin by upgrading the NetWare/IP forwarding gateways at both ends of the WAN link to NetWare 5 Pure IP. Then disable NetWare/IP and DSS on these computers.

  5. After the migration, DSS/IPX filtering (if present earlier) should be implemented using Service Location Protocol (SLP) scopes and a Directory Agent (DA) across the WAN link. Alternatively, it can be implemented through any level of IP filtering on the WAN routers.

  6. After the WAN migration is completed, you should disable IPX on the local segment if there are no IPX application dependencies. Leaving IPX on the server and client will not pose any problem, but it creates unnecessary redundant traffic after the migration.

Advantages and Disadvantages. The advantages of the dual stack migration approach are:

  • It is easy to define and implement.

  • It is less expensive in terms of extra configuration, administration, and resources required during and after migration.

  • It is less risky, since the existing IPX configuration and connectivity remain undisturbed until the migration is complete and all communication is verified to be happening correctly over Pure IP.

The disadvantages of the dual stack migration approach are:

  • Since IPX cannot be disabled until the entire organization has been completely migrated to Pure IP, it may not be practical (especially for large sites) to maintain the overhead of having two protocols and the extra IPX traffic on the wire.

  • For the same reason, it may not be feasible when the migration period is too long.

  • The configuration on clients and servers must be changed twice—once to upgrade them to dual stacks, and later to disable IPX.

CMD Approach. This approach focuses on removing IPX from the wire as early as possible during the migration. This gives you the flexibility to do a slow, phased migration.

A phased migration is achieved by migrating the network to Pure IP segment by segment. In other words, you migrate one local segment at a time to Pure IP, or you may migrate multiple segments in parallel. As with the previous approach, it is preferable to concentrate on migrating local segments first before moving on to the WAN migration ("LAN first, WAN next"). To reduce the complexity of the migration, you should always begin with the "branch" segments that have the fewest links to other segments. Then you can proceed to migrate the "central" segments that have more local segments connected to them via WAN links.

Note: Although the recommendation is to migrate all LAN segments first, this approach gives you the flexibility to start the WAN migration while local segment migration is in progress.

Figure 8: With the CMD approach, IPX applications are supported through encapsulating IPX packets within IP packets.

As shown in Figure 8, this approach uses the NetWare 5 IPX Compatibility Mode Driver to provide support for IPX applications during the migration. With Pure IP running on the wire, IPX packets are encapsulated within IP packets (also referred to as CMD packets).

Keeping the "LAN first, WAN next" approach in mind, here are the guidelines for a complete migration.

  1. Place a Migration Agent (MA) on the LAN segment before upgrading any of the servers or clients to NetWare 5.

    As mentioned earlier, this approach supports a phased migration. To maintain communication between newly upgraded NetWare 5 servers and clients and their IPX counterparts during a slow migration, it is better to have an MA in place before you start upgrading any of the servers or clients on the segment.

  2. Once the MA is in place, start upgrading the servers to IP with CMD active. The idea is to have all NCP-based communication occur via IP, and all IPX-based communication occur via CMD and the MA.

  3. Once majority of the servers have been upgraded to IP and CMD, start upgrading the clients to IP and CMD.

    At this point, all communication between the servers and clients (running IP and CMD) to access IP/NCP-based services occurs via Pure IP. Communication to access legacy IPX services occurs via CMD, as illustrated in Figure 9.

    Figure 9: NetWare/IP Scenario 1, this is how communication occurs during a migration using the CMD approach.

    In Figure 9, Segment A is migrated first. SRV_MA1 is the MA placed on the segment to provide interoperability between IPX and IP nodes. At this point, communication between the various clients and servers occurs as follows:

    • For all IP-based services, IP clients and servers communicate directly via Pure IP. For example, CLNT_IP1 communicates with SRV_IP1 via Pure IP.

    • For any legacy IPX services, IP clients and servers communicate indirectly through CMD. For example, CLNT_IP1 communicates with SRV_IP1 via CMD.

    • Communication between IP clients (such as CLNT_IP1) and IPX servers (such as SRV_IPX1) occurs through the MA (SRV_MA1). CLNT_IP1 talks to SRV_MA1 via CMD, and SRV_MA1 talks to SRV_IPX1 via IPX.

    • Similarly, communication between IPX clients (such as CLNT_IPX1) and IP servers (such as SRV_IP1) occurs through the MA (SRV_MA1). CLNT_IPX1 talks to SRV_MA1 via IPX, and SRV_MA1 talks to SRV_IP1 via CMD.

    • Communication between IP clients (such as CLNT_IP1) and any IPX servers across the WAN link occurs through a combination of CMD, IPX, and NetWare/IP. For example, CLNT_IP1 talks to SRV_MA1 via CMD, SRV_MA1 talks to SRV_NWIP1 via IPX, SRV_NWIP1 talks to SRV_NWIP2 via NetWare/IP, and SRV_NWIP2 talks to SRV_IPX2 via IPX.

  4. Do not upgrade the DSS and NetWare/IP servers during this period.

  5. Once the migration on the LAN segment is complete (or when migration of the WAN between that segment and another is desirable from the administrative perspective), upgrade the NetWare/IP servers connecting the two segments to MAs and enable the MA-MA protocol between them.

    Referring to our example in Figure 9, you would upgrade SRV_NWIP1 on segment A to an MA, and do the same for SRV_NWIP2 across the WAN link on Segment B. You would then enable the MA-MA protocol between these two MAs.

  6. Upgrade the DSS server on the segment (if there is one) to NetWare 5 with Pure IP and CMD. If any remote clients are configured to have this DSS server as their preferred DSS, they must be upgraded to NetWare 5 at this time and then be configured to have the MA on the segment as their preferred MA for service discovery and communication.

    In our example in Figure 9, any upgraded clients on segment A can be configured to have the MA in Segment A (SRV_NWIP1) as preferred MA.

    Note: Before upgrading the DSS, make sure all the NetWare/IP servers pointing to this DSS are upgraded to NetWare 5.

  7. Any previous DSS or IPX filtering can be realized by implementing SLP scopes and IPX filtering on the MA. (For more information on IPX filtering, refer to the related AppNotes listed at the end of this AppNote.)

  8. At this point, the NetWare/IP server on Segment B (SRV_NWIP2) can be removed, as long as there are no other segments connected to Segment B via NetWare/IP. You can also remove the DSS on Segment B, based on your dependence on NetWare/IP.

  9. Once the migration on the local segment is complete, the MA placed on that segment (SRV_MA1 in our example) can be switched to function in IP CMD mode. This decision should be made based on the load handled by the MAs on that segment.

  10. Once the migration on the local segments on either side of the WAN (Segments A and B in our example) is complete, the MAs on the WAN can be removed. CMD support can also be removed from the local servers and clients.

    Note: If you still have IPX applications running, you need to leave CMD running on both the clients and the servers.

In the case of a single server site (as would be the case if SRV_NWIP1 were the only server on Segment A in our example), perform the WAN migration first. Then begin migrating the IPX clients on the local segment to IP CMD.

Advantages and Disadvantages. The advantages of this approach are:

  • It facilitates a phased migration.

  • IPX can be removed from the wire and from WAN routers at an early stage of the migration. You need not wait until the entire migration is complete.

  • There is no need to maintain two protocols (IPX and IP) during the entire migration period.

The disadvantages of the CMD approach are:

  • It requires additional overhead in terms of planning, administration and configuration.

  • Certain decisions must be made during planning: for example, where to place the MA, how many MAs are required for a segment to handle the load, and so on.

  • An extra hop is introduced by the MA for each packet going through it, which can affect network performance.

Scenario 2: NetWare/IP on WAN and LAN

Since NetWare 5 does not support NetWare/IP, no dual stack approach is possible for this scenario. The following is the CMD approach proposed for this scenario.

CMD Approach. This approach is similar to the one outlined for NetWare/IP Scenario 1. The main difference is that the MA is running on a NetWare 4.11 server, rather than on a NetWare 5 server.

As mentioned earlier, the migration starts with the local segments and then moves to the WAN segments. The guidelines for this approach are outlined below.

  1. To maintain connectivity between the IP and NetWare/IP networks during the migration, install an MA on the existing NetWare 4.11 server and make it function as a NetWare/IP forwarding gateway also. This must be done before migrating any of the servers or clients on the segment to IP with CMD.

  2. Start migrating the NetWare/IP servers to IP with CMD.

  3. Once the majority of the servers have been migrated to IP with CMD, begin migrating the clients to IP with CMD in parallel.

  4. During this period, all communication between IP CMD clients and servers to access IP/NCP-based services occurs via Pure IP. Communication to access legacy IPX services occurs via CMD, as shown in Figure 10.

    Figure 10: In NetWare/IP Scenario 2, this is how communication occurs during a migration using the CMD approach.

    In Figure 10, Segment A is being migrated first. SRV_MA1 is the MA placed on the segment to provide interoperability. At this point, communication between IP and IPX nodes occurs as follows:

    • For all IP-based services, communication between IP clients and servers occurs directly via Pure IP. For example, CLNT_IP1 communicates with SRV_IP1 directly via Pure IP.

    • For any legacy IPX services, IP clients and servers communicate indirectly via CMD. For example, CLNT_IP1 communicates with SRV_IP1 via CMD.

    • Communication between IP clients and NetWare/IP servers occurs through the MA. For example, CLNT_IP1 and SRV_NWIP1 communicate through SRV_MA1 using a combination of protocols. CLNT_IP1 talks to SRV_MA1 via CMD, and SRV_MA1 talks to SRV_NWIP1 via NetWare/IP. Inside SRV_MA1, CMD packets are converted to IPX by the MA, and then the IPX packets are converted to NetWare/IP by the NetWare/IP forwarding gateway.

    • Similarly, communication between NetWare/IP clients and IP servers occurs through the MA. For example, communication between CLNT_NWIP1 and SRV_IP1 occurs through SRV_MA1. CLNT_NWIP1 talks to SRV_MA1 via NetWare/IP, and SRV_MA1 talks to SRV_IP1 via CMD. This time, within SRV_MA1, NetWare/IP packets are converted to IPX by the NetWare/IP forwarding gateway, and the IPX packets are converted to CMD by the MA.

    • Communication between IP clients and any NetWare/IP servers across the WAN link occurs through a combination of CMD, IPX, and NetWare/IP. For example, CLNT_IP1 talks to SRV_MA1 via CMD, and SRV_MA1 talks to SRV_NWIP2 via NetWare/IP.

  5. Do not upgrade the DSS server until NetWare/IP is completely removed from the local segment.

  6. Once the migration on the local segment is complete and all remote NetWare/IP clients contacting the servers on that segment have been upgraded to IP with CMD, upgrade the NetWare/IP server at the WAN (SRV_NWIP2 in our example) to an MA. Place another MA across the WAN link. Enable the MA-MA protocol between these two MAs.

  7. During this period, the DSS on the local segment can also be upgraded to NetWare 5 with IP and CMD support. Even though leaving the DSS on the segment as it is will not create any problems (since there are no NetWare/IP servers or clients in the segment to use it), DSS synchronization—the operation the DSS would be performing at this stage—across the WAN link is redundant.

  8. All remote clients connected to the servers in the local segment should be upgraded to NetWare 5 before the NetWare/IP servers and DSS on the segment are upgraded to NetWare 5. When the remote clients are being upgraded, their preferred MA can be configured to point to the MA in the local segment.

  9. Once the migration on the local segment is complete, the MA placed on that segment can be switched to an IP CMD node.

  10. Once the migration on the local segments on either side of the WAN link (segments A and B in our example) is complete, the MAs on the WAN can be removed. You can also remove CMD support on the local servers and clients.

Note: If you still have IPX applications running, you need to leave CMD running on both the clients and the servers.

In the case of a single server site, install the MA for NetWare 4.11 in SRV_NWIP1 and leave it as a NetWare/IP server and the DSS also. Start by migrating the IPX clients to IP with CMD. Once the LAN migration is complete, proceed with the WAN migration as mentioned earlier.

Advantages and Disadvantages. This approach has the same advantages and disadvantages that are listed for NetWare/IP Scenario 1 using the CMD approach.

Scenario 3: NetWare/IP on WAN, IPX/NetWare/IP Mixed on LAN

Since the LAN in this scenario is a mixed implementation of IPX and NetWare/IP, you can simply apply a combination of the dual stack and CMD approaches outlined for the first two scenarios.

Advantages and Disadvantages. The advantages and disadvantages listed previously for the dual stack and CMD approaches hold true here too, depending upon the approach taken for the LAN migration.

IPX Customer Scenario

Unlike NetWare/IP customers, IPX customers normally have a simpler network configuration consisting of IPX everywhere, on the LAN as well as the WAN. As with the NetWare/IP customer scenarios, we will focus on a subset of the typical network configuration illustrated in Figure 1. This subset is illustrated in Figure 11.

Figure 11: A subset of the typical IPX customer configuration.

An overall migration strategy for the entire organization can be devised by extrapolating the solutions suggested for this subset.

Migration Strategies for the IPX Scenario

Three migration strategies are possible for this single IPX scenario:

  • Dual stack approach

  • "LAN first, WAN next" approach

  • "WAN first, LAN next" approach

Guidelines for these approaches are given in the subsequent sections.

Dual Stack Approach

The basic idea behind this approach is to let both the IPX and TCP/IP protocol stacks exist together throughout the migration. Once the migration process is complete, IPX can be disabled on all servers, clients, and routers.

The migration strategy guidelines based on this approach are outlined below.

  1. Begin by upgrading the servers on the local segments to dual stack configuration.

  2. Start upgrading the clients on the local segments to a dual stack configuration.

    The client and server upgrades can happen in parallel. Preferably, though, you should upgrade the majority of the servers before upgrading the clients. This ensures that most of the communication would still occur over IP even during migration.

  3. During the migration, everything remains connected and accessible because of the dual stacks. Dual-stack NetWare 5 clients communicate with NetWare 5 Pure IP servers via IP, and with IPX servers via IPX. Old clients use IPX to communicate with the upgraded servers. Both IPX and IP are running across the WAN link during migration, as shown in Figure 12.

    Figure 12: In IPX networks, this is how communication occurs during a migration using the dual stacks approach.

  4. Once the migration is completed on all the local segments (that is, once all the servers and clients in the entire organization have been migrated to NetWare 5), remove IPX from all the routers. (This is required because of the NDS backlink issue.)

  5. If there are no IPX application dependencies, IPX should be disabled on the local segment. Even though leaving IPX on the server and clients will not pose any problems, it creates redundant traffic after the migration.

"LAN First, WAN Next" Approach

The approach is appropriate when upgrading the servers to NetWare 5 is the main objective, and the primary concern is not to reduce or remove IPX traffic from the WAN (and thus from the WAN routers as well) as early as possible.

It is advisable to start the migration with the "branch" segments that have the fewest links to other segments. However, the migration strategy outlined below supports migration of various segments in parallel.

  1. Before starting the migration, place an MA on the local segment to be migrated first.

  2. Begin migrating the servers on the local segment to Pure IP + CMD, enable IP on the WAN routers. This facilitates communication when migration on another local segment is happening in parallel, as it allows the Pure IP server-to-server communication between the segments over IP.

  3. Once the majority of the servers on the local segment have been migrated to Pure IP, start migrating the clients to Pure IP + CMD.

    During the migration period, CMD clients communicate with IPX servers via the MA. Both IPX and IP traffic will exist on the WAN, as shown in Figure 13.

    Figure 13: In IPX networks, this is how communication occurs during a migration using the "LAN first, WAN next" approach.

    In Figure 13, Segment A is the one being migrated first. The MA is SRV_MA1. The communication between nodes during the migration occurs as follows:

    • For all IP-based services, IP clients and servers communicate directly via Pure IP. For example, CLNT_IP1 communicates with SRV_IP1 directly via Pure IP.

    • For any legacy IPX services, IP clients and servers communicate indirectly via CMD. For example, CLNT_IP1 communicates with SRV_IP1 via CMD.

    • Communication between IP clients and IPX servers occurs through a combination of protocols. For example, CLNT_IP1 and SRV_IPX1 communicate through SRV_MA1. CLNT_IP1 talks to SRV_MA1 via CMD, and SRV_MA1 talks to SRV_IPX1 via IPX.

    • Similarly, communication between IPX clients and IP servers occurs through a combination of protocols. For example, CLNT_IPX1 and SRV_IP1 communicate through SRV_MA1. CLNT_IPX1 talks to SRV_MA1 via IPX, and SRV_MA1 talks to SRV_IP1 via CMD.

    • Communication between IP clients (such as CLNT_IP1) and any IPX servers across the WAN link occurs through CMD and IPX. CLNT_IP1 talks to SRV_MA1 via CMD, and SRV_MA1 talks to SRV_IPX2 via IPX.

    • Similarly, communication between IPX clients (such as CLNT_IPX1) and any IP servers across the WAN link happens through IPX and CMD. For example, CLNT_IPX1 talks to SRV_MA1 via IPX, and SRV_MA1 talks to SRV_IP2 via CMD.

    • Communication between IPX clients and servers across the WAN link (such as CLNT_IPX1 and SRV_IPX2) happens via IPX. Communication between IP clients and servers (such as CLNT_IP1 and SRV_IP2) across the WAN occurs via Pure IP.

  4. Once the migration on the first local segment is complete, migration on the WAN can happen in one of two ways. The choice depends upon the status of the connected segment migration and the nature of the WAN link.

    • If the network on the connected segment (Segment B in Figure 13) is not very dynamic and the WAN link is stable, remove the MA on Segment A. If there isn't one already, place an MA on Segment B. All communication with IPX services on Segment B occurs via this MA. All service lookups for IPX services occurs with CMD servers on Segment A only. Disable IPX from the WAN routers.

    • Otherwise, place an MA on Segment B (if there isn't one already). Enable MA-to-MA communication between the MAs on Segment As and B. Disable IPX from the WAN routers.

    Note: You should also adopt this approach if WAN migration is desirable even before Segment A has been migrated fully.

  5. Once migration on both sides is complete, there is no more need for an MA. You can also disable IPX from the WAN routers.

"WAN First, LAN Next" Approach

This approach is appropriate when the primary objective is migration of the WAN to Pure IP, thus disabling IPX from the routers. The migration strategy outlined below enables IPX traffic to be removed from WAN, and thus from the routers, as early as possible during the migration.

  1. Place an MA on both the sides of the WAN link and enable MA-to-MA communication between them.

  2. Remove IPX from the routers connecting the WAN.

    At this point, all communication on the LAN segments is through IPX. Whenever a client on one local segment wants to communicate with a server on another segment across the WAN link, it goes through the two MAs, as shown in Figure 14.

    Figure 14: In IPX networks, this is how communication occurs during a migration using the "WAN first, LAN next" approach.

    After the WAN migration, communication between nodes on the segments occurs as described below:

    • For all IP-based services, IP clients and servers communicate directly via Pure IP. For example, CLNT_IP1 communicates with SRV_IP1 directly via Pure IP.

    • For any legacy IPX services, IP clients and servers communicate indirectly via CMD. For example, CLNT_IP1 communicates with SRV_IP1 via CMD.

    • Communication between IP clients and IPX servers occurs through the MA. For example, CLNT_IP1 and SRV_IPX1 communicate through SRV_MA1. CLNT_IP1 talks to SRV_MA1 via CMD, and SRV_MA1 talks to SRV_IPX1 via IPX.

    • Similarly, communication between IPX clients and IP servers occurs through the MA. For example, CLNT_IPX1 and SRV_IP1 communicate through SRV_MA1. CLNT_IPX1 talks to SRV_MA1 via IPX, and SRV_MA1 talks to SRV_IP1 via CMD.

    • Communication between IP clients (such as CLNT_IP1) and any IPX servers across the WAN link occurs through CMD and IPX. For example, CLNT_IP1 talks to SRV_MA2 directly via CMD, and SRV_MA2 talks to SRV_IPX2 via IPX.

    • Similarly, communication between IPX clients (such as CLNT_IPX1) and any IP servers across the WAN link occurs through IPX and CMD. For example, CLNT_IPX1 talks to SRV_MA1 via IPX, and SRV_MA1 talks to SRV_IP2 via CMD.

    • Communication between IPX clients and servers across the WAN occurs through a combination of protocols. For example, CLNT_IPX1 and SRV_IPX2 communicate via IPX, CMD, and IPX. CLNT_IPX1 talks to SRV_MA1 via IPX, SRV_MA1 talks to SRV_MA2 via CMD, and SRV_MA2 talks to SRV_IPX2 via IPX.

    • Communication between IP clients and servers across the WAN occurs via Pure IP. For example, CLNT_IP1 and SRV_IP2 communicate over the WAN via Pure IP.

  3. Start upgrading the servers on the local segment to Pure IP. The MA on the WAN (SRV_MA1 in our example) can also be used for intra-segment interoperability, but for load balancing purposes, it is preferable to have another MA local to the segment.

    Migration on the connected segment (Segment B in our example) can also happen in parallel.

  4. Once the migration on the first segment is complete, remove the MA from the local segment. The MA on the WAN can also be removed, and CMD-to-MA communication can occur over WAN, as long as the traffic between the segments is less and the WAN link is stable.

  5. Once the migration on both segments is complete, remove the MA from the WAN. At this point, you can also remove CMD support on all the servers and clients.

Conclusion

This AppNote has provided migration strategies for upgrading existing IPX and NetWare/IP networks to NetWare 5 and Pure IP. Customers should evaluate their networks and select an appropriate strategy for their particular configurations.

For more information about NetWare 5, Pure IP, and Compatibility Mode, refer to the following AppNotes:

  • "Migrating to Pure IP with NetWare 5" (September 1998)

  • "Compatibility Mode Installation and Configuration" (September 1998)

  • "Dynamically Discovering Services on an IP Network with SLP" (March 1999)

  • "Configuration Parameters for the Compatibility Mode Driver" (April 1999)

* 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