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

dargspurNetworking and Communications

Oct 27, 2013 (4 years and 13 days ago)

93 views


JUNE 1999
NOVELL RESEARCH
Migration Strategies for
Upgrading IPX and NetWare/IP
Networks to Pure IP
........................................................................................................................................
RAJAYOGASRI P
One of the most compelling features of NetWare 5 is its ability to run in a Pure
Software Consultant
IP environment. It is “pure” in the sense that it doesn’t retain any IPX-based
Server Communications Group, NPGB
encapsulation. Communication between IP-based clients and servers occurs via
HARINATH SUBRAMANIAM
the TCP/IP transport protocol. In fact, for NetWare 5 the NetWare Core
Worldwide Support Engineer
Protocols (NCPs) were rewritten to use TCP/IP natively. Of course, for
Novell Customer Services
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.
Copyright © 1999 by Novell, Inc. All rights
reserved. No part of this document may be
The information in this AppNote replaces that presented in “Migrating from
reproduced or transmitted in any form or by
any means, electronic or mechanical,
NetWare/IP to NetWare 5 and Pure IP” published in the February 1999 issue.
including photocopying and recording, for
any purpose without the express written
permission of Novell.
All product names mentioned are trademarks
of their respective companies or distributors.
25
N OVELL A PP N OTES • J UNE 1999
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.
26
S TRATEGIES FOR U PGRADING IPX AND N ET W ARE /IP N ETWORKS TO P URE IP
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.
IPX
NetWare/IP
IPX IPX IPX
NetWare/IP NetWare/IP NetWare/IP
IPX IPX IPX
NetWare/IP NetWare/IP NetWare/IP
WAN Link (NetWare/IP)
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.
27
N OVELL A PP N OTES • J UNE 1999
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.
IPX IPX
NetWare/IP NetWare/IP
NetWare/IP
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
SRV_IPX1 SRV_NWIP1 SRV_NWIP2 SRV_IPX2
only, IPX on LAN.
(NetWare 4.11/4.2 (NetWare/IP (NetWare/IP (NetWare 4.11/4.2
IPX Server) Forwarding Gateway) Forwarding Gateway) IPX Server)
NetWare/IP
IPX IPX
CLNT_IPX1 CLNT_IPX2 CLNT_IPX3 CLNT_IPX4
(IPX Client) (IPX Client) (IPX Client) (IPX Client)
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.
28
S TRATEGIES FOR U PGRADING IPX AND N ET W ARE /IP N ETWORKS TO P URE IP
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
SRV_NWIP1 SRV_NWIP2 SRV_NWIP3 SRV_NWIP4
LAN.
(NetWare/IP (NetWare/IP (NetWare/IP (NetWare/IP
Server) Server) Server) Server)
NetWare/IP
NetWare/IP NetWare/IP
CLNT_NWIP1 CLNT_NWIP2 CLNT_NWIP3 CLNT_NWIP4
(NetWare/IP (NetWare/IP (NetWare/IP (NetWare/IP
Client) Client) Client) Client)
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,
SRV_NWIP4
SRV_NWIP1
SRV_IPX2
SRV_IPX1 SRV_NWIP2 SRV_NWIP3
(NetWare/IP
mixed IPX and NetWare/IP on LAN. (NetWare/IP
(NetWare 4.11/4.2 (NetWare/IP (NetWare/IP (NetWare 4.11/4.2
Server) Server)
IPX Server) Forwarding Gateway) Forwarding Gateway) IPX Server)
NetWare/IP
IPX & NetWare/IP IPX & NetWare/IP
CLNT_IPX1 CLNT_NWIP1 CLNT_NWIP2 CLNT_IPX2
(IPX Client) (NetWare/IP (NetWare/IP (IPX Client)
Client) Client)
Two NetWare/IP forwarding gateways connect the local segments across a
WAN link using NetWare/IP.
29
N OVELL A PP N OTES • J UNE 1999
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
NetWare 5 NetWare 5
approach, both IPX and IP applications
Client (IP & IPX) Server (IP & IPX)
are supported through their native

protocols on the LAN segment.
IPX IPX
IP Application Application Application IP Application

Pure IP
IPX
LAN Segment
IPX Packet

IP Packet NetWare NCPs

30
S TRATEGIES FOR U PGRADING IPX AND N ET W ARE /IP N ETWORKS TO P URE IP

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
SRV_IP1 SRV_IPX2
during a migration using the dual
(NetWare 5 (NetWare 4.11
Dual Stack Server) IPX Server)
stacks approach.
IPX & IP IPX
NetWare/IP
SRV_NWIP1 SRV_NWIP2
(NetWare/IP (NetWare/IP
Forwarding Gateway) Forwarding Gateway)
CLNT_IP1 CLNT_IPX1 CLNT_IPX2 CLNT_IPX3
(Dual Stack Client) (IPX Client) (IPX Client) (IPX Client)
Pure IP
IPX
NetWare/IP
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.
31
N OVELL A PP N OTES • J UNE 1999
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.
32
S TRATEGIES FOR U PGRADING IPX AND N ET W ARE /IP N ETWORKS TO P URE IP
Figure 8: With the CMD approach,
NetWare 5 NetWare 5
IPX applications are supported through
Client (CMD) Server (CMD)
encapsulating IPX packets within IP

packets.
IPX
IPX
Application
Application
IP Application IP Application
Virtual Virtual

IPX Stack IPX Stack
Pure IP
IPX
LAN Segment (Pure IP Only)
IP Packet IPX Packet

IP Packet NetWare NCPs

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.
33
N OVELL A PP N OTES • J UNE 1999
Figure 9: In NetWare/IP Scenario 1,
SRV_IP1 SRV_IPX1 SRV_IPX2
this is how communication occurs
(NetWare 5 SRV_MA1 (NetWare 4.11/4.2 (NetWare 4.11/4.2
IP+CMD server) (Migration Agent) Server) Server)
during a migration using the CMD
approach.
IP & IPX
IPX
NetWare/IP
SRV_NWIP1 SRV_NWIP2
(NetWare/IP (NetWare/IP
Forwarding Gateway) Forwarding Gateway)
CLNT_IP1 CLNT_IPX1 CLNT_IPX2 CLNT_IPX3
(NetWare 5 (IPX Client) (IPX Client) (IPX Client)
IP+CMD)
SEGMENT A SEGMENT B
Pure IP
IPX
CMD
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.
34
S TRATEGIES FOR U PGRADING IPX AND N ET W ARE /IP N ETWORKS TO P URE IP
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.
35
N OVELL A PP N OTES • J UNE 1999
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.
36
S TRATEGIES FOR U PGRADING IPX AND N ET W ARE /IP N ETWORKS TO P URE IPFigure 10: In NetWare/IP Scenario 2,
SRV_MA1
SRV_IP1 SRV_NWIP1
this is how communication occurs during
(Migration Agent)
(NetWare 5 (NetWare/IP SRV_NWIP4
NetWare 4.11/4.2 Server
NetWare/IP Forwarding Gateway (NetWare/IP Server)
a migration using the CMD approach. IP+CMD server) Server)
NetWare/IP
IP & NetWare/IP
NetWare/IP
SRV_NWIP2 SRV_NWIP3
(NetWare/IP Server) (NetWare/IP Server)
CLNT_IP1 CLNT_NWIP1 CLNT_NWIP3 CLNT_NWIP4
(NetWare 5 (NetWare/IP Client) (NetWare/IP Client) (NetWare/IP Client)
IP+CMD)
SEGMENT A SEGMENT B
Pure IP
NetWare/IP
CMD
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.
37
N OVELL A PP N OTES • J UNE 19995. 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.
38
S TRATEGIES FOR U PGRADING IPX AND N ET W ARE /IP N ETWORKS TO P URE IPIPX 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.
IPX IPX
IPX
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.
39
N OVELL A PP N OTES • J UNE 19993. 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
SRV_IPX1 SRV1_IP1 SRV_IP2 SRV_IPX2
how communication occurs during a
(NetWare 4.11/4.2 (NetWare5 (NetWare5 (NetWare 4.11/4.2
migration using the dual stacks
IPX Server) Dual Stack Server) Dual Stack Server) IPX Server)
approach.
NetWare/IP
IPX & IP IPX & IP
CLNT_IPX1 CLNT_IP1 CLNT_IP2 CLNT_IPX2
(IPX Client) (Dual Stack Client) (Dual Stack Client) (IPX Client)
Pure IP
IPX
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.
40
S TRATEGIES FOR U PGRADING IPX AND N ET W ARE /IP N ETWORKS TO P URE IP3. 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
SRV_IPX1 SRV_IP1 SRV_IP2 SRV_IPX2
migration using the “LAN first, WAN
(NetWare 4.11/4.2 SRV_MA1 (IP+CMD (IP+CMD SRV_MA2 (NetWare 4.11/4.2
server) (Migration Agent) Server) Server) (Migration Agent) server)
next” approach.
IPX & IP
(Dual Protocol)
IP & IPX IP & IPX
CLNT_IPX1
CLNT_IP1 CLNT_IP2 CLNT_IPX2
(IPX Client)
(IP+CMD Client) (IP+CMD Client) (IPX Client)
SEGMENT A SEGMENT B
Pure IP
IPX
CMD
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.
41
N OVELL A PP N OTES • J UNE 1999• 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.
42
S TRATEGIES FOR U PGRADING IPX AND N ET W ARE /IP N ETWORKS TO P URE IPFigure 14: In IPX networks, this is
how communication occurs during a
SRV_IPX1 SRV_IP1 SRV_IP2 SRV_IPX2
migration using the “WAN first, LAN
(NetWare 4.11/4.2 SRV_MA1 (IP+CMD (IP+CMD SRV_MA2 (NetWare 4.11/4.2
server) (Migration Agent) Server) Server) (Migration Agent) server)
next” approach.
IP Only
IP & IPX IP & IPX
CLNT_IPX1 CLNT_IP1 CLNT_IP2 CLNT_IPX2
(IPX Client) (IP+CMD Client) (IP+CMD Client) (IPX Client)
SEGMENT A SEGMENT B
Pure IP
IPX
CMD
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.
43
N OVELL A PP N OTES • J UNE 1999• 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)
44
S TRATEGIES FOR U PGRADING IPX AND N ET W ARE /IP N ETWORKS TO P URE IP