Switching From IPX to IP
Articles and Tips: article
01 Oct 1999
If you ask a network administrator why he or she uses IPX rather than IP, that network administrator may well reply: "Because IPX is easy." If you agree with this assessment, the prospect of changing your company's network transport protocol from IPX to IP can be daunting. IPX networks are easy to manage because you do not need to manually address IPX network devices, as you do devices on IP networks. Manual addressing on IPX networks is unnecessary because Router Information Protocol (RIP) and Service Advertising Protocol (SAP) make IPX networks literally plug-and-play. (For an explanation of terms used in this article, including IPX, IP, RIP, and SAP, see the glossary.)
Furthermore, if you have been managing NetWare networks for a while, you understand how IPX works and know how to manage it. You may not be as familiar with IP.
However, the ease of managing IPX networks can come at a price: For example, the very protocols that give IPX its plug-and-play capabilities, such as SAP and RIP, can also use a considerable amount of bandwidth. As you know, you must pay particular attention to SAP and RIP traffic if your company has a WAN. To reduce the traffic across WAN links, you must filter SAP broadcasts, and this filtering technology adds to the costs associated with managing IPX networks.
In addition, running an IPX network may make it difficult to adopt many of the latest technologies. Internet-inspired technologies, such as browser-based access to network resources, rely on IP, rather than on IPX. Although you can use tunneling or encapsulation solutions to deploy Internet technologies on an IPX network, these solutions also add to the cost of managing an IPX network. As a result, the costs of managing an IPX network may begin to outweigh the benefits of that IPX network.
If you suspect that your company's network would benefit by migrating from IPX to pure (unencapsulated) IP, take heart. Novell has worked hard to make migrating your network to NetWare 5 and pure IP as simple as possible.
WAY TO GO
Obviously, not all IPX networks are alike. Like any other type of network, IPX networks can be small or large, simple or complicated. Some IPX networks use only unencapsulated IPX; others use IPX-in-IP encapsulation to communicate across WAN links or over the Internet.
To a large degree, the type of IPX network your company is using will determine how you migrate that network to IP. You may be able to roll the entire network over to NetWare 5 and pure IP all at once, or you may prefer to gradually migrate your company's network to NetWare 5 and pure IP.
ALL OR NOTHING
The all-or-nothing rollover method of network migration has one clear advantage over a gradual migration to IP: You can configure the hardware and software on your network once and be done with it. If you gradually migrate your company's network, you must enable and disable transport protocols and other processes at least twice: once when you begin the migration and once when you complete that migration.
On the other hand, one disadvantage of using the all-or-nothing rollover method is the up-front costs of purchasing new software for the entire network. In fact, the up-front costs of using this method may also include the price of new hardware. For example, if you are currently running NetWare 3.2 on 386-based servers, you will need to purchase Pentium-based servers to run NetWare 5.
Another disadvantage of using the all-or-nothing rollover method is network downtime: You must take down the entire network while you upgrade to or install NetWare 5 and pure IP. Again in contrast, a gradual migration allows you to strategically choose when and where to perform hardware and software upgrades.
Obviously, the bigger your company's network, the more an all-or-nothing rollover will cost--both in money and in network downtime. In other words, the all-or-nothing roll-over method is "best suited to small networks where you have single-server NDS [Novell Directory Services] trees," says Paul McKeith, a senior consultant for Novell.
Although the all-or-nothing rollover method is "generally not an option for companies with sizable networks," McKeith explains that this migration method can be suitable for medium-sized companies that are using old hardware. For example, if a medium-sized company has a network that is running NetWare 3.2 on 386-based servers, that company may want to consider using the all-or-nothing rollover method to migrate to NetWare 5 and pure IP.
TAKING YOUR TIME
NetWare 5 includes two features specifically designed to help you gradually migrate an IPX network to a pure IP network: Compatibility Mode Driver (CMD) and dual IPX and IP stacks. CMD is a NetWare Loadable Module (NLM) that encapsulates IPX packets in IP packets and transports those packets via Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). Dual IPX and IP stacks enable your company's network to use both the IP and IPX network transport protocols.
Compatibility at a Distance
The CMD NLM (SCMD.NLM) loads by default when you configure a NetWare 5 server to run in IP mode. This NLM supports IPX-based applications by encapsulating IPX packets in IP packets. If you use the CMD NLM, you can also configure the NetWare 5 client software to run in IP CMD mode. This client software then runs a CMD component on the workstation. (For more information about NetWare 5 client software, visit http://www.novell.com/documentation/lg/client/docui/index.html.)
To eliminate the management costs of filtering SAP broadcasts on your company's WAN links, you can configure CMD migration agents on each side of these links. These migration agents then act as gateways between unencapsulated IPX LANs and encapsulated IPX WAN segments.
For example, suppose your company has IPX LANs in Newark, New Jersey, and in Buffalo, New York. The two LANs are connected via a WAN link. To eliminate IPX routing across this WAN link, you can place a NetWare 5 server at each end of the link and configure each server to run a CMD migration agent. (See Figure 1.)
Figure 1: With NetWare 5, two IPX-dependent LANs can communicate across a WAN link using CMD migration agents.
The CMD migration agent in Newark encapsulates Buffalo-bound IPX packets in IP packets before sending these packets to Buffalo. The CMD migration agent in Buffalo unencapsulates the IPX packets and forwards them to the Buffalo IPX LAN.
The two CMD migration agents exchange SAP information about their LANs via NetWare Link Services Protocol (NLSP), a much less bandwidth-intensive protocol than SAP. NLSP transmits information about network services and routing only when service or routing changes occur or every two hours, depending upon which event occurs first. (CMD uses NLSP only when CMD is running in the migration agent configuration and only on the servers running CMD in the migration agent configuration. For more information about NLSP, see "NetWare Link Services Protocol: Building a Link State Database,"NetWare Connection, Sept. 1997, pp. 38-45; "NetWare Link Services Protocol: Updating the Link State Database,"NetWare Connection, Oct. 1997, pp. 34-39; "NetWare Link Services Protocol: Interoperating With RIP and SAP,"NetWare Connection, Nov. 1997, pp. 36-39. You can download these articles from http://www.nwconnection.com/past.)
The two CMD migration agents communicating across a WAN link also use the NetWare 5 Service Location Protocol (SLP). The migration agents check the SLP service agent for information about NetWare 5 services and then use SAP to broadcast this information to their IPX LANs. (For more information about SLP and the SLP service agent, see "Agents Give 'Em the SLP.")
DID YOU KNOW?
If you are planning to migrate your company's network to IP, you should become familiar with IPv6, the next generation of IP. Although many experts believe that IPv6 is still years away from adoption, other experts believe that the time for IPv6 is coming. To start learning about IPv6, visit the IPv6 home page at http://www.ipv6.org, or read "IPv6: At the Starting Line,"NetWare Connection, May 1999, pp. 6-17. (You can download this article from http://www.nwconnection.com/past.)
Compatibility Issues
You can also use the CMD method to gradually phase out IPX on your company's LAN. However, using this method to migrate LANs to pure IP requires careful planning. For example, you must configure a migration agent to unencapsulate IPX packets for all network segments that still use pure IPX.
Despite this drawback, the CMD method is the best option if you are using NetWare/IP on the entire network. NetWare 5 does not support NetWare/IP packets in the dual-stack configuration. (NetWare/IP encapsulates IPX packets in IP packets, eliminating the need for IPX routing on NetWare 4 networks. For information about how to migrate NetWare 4 networks using NetWare/IP to NetWare 5 using pure IP, see "Migration Strategies for Upgrading IPX and NetWare/IP Networks to Pure IP,"Novell AppNotes, June 1999. You can download this article at http://developer.novell.com/research/appnotes.htm.)
It All Stacks Up
IT professionals such as McKeith and Vincent Hanchon, a senior Novell consultant, say that in most cases, using the dual-stack method is by far the best option for migrating a network from IPX to pure IP. The dual-stack method enables NetWare 5 to use both an IPX stack and an IP stack for network communications. (See Figure 2.) Novell consultants prefer the dual-stack method, McKeith explains, because "it makes your migration very straightforward and very, very easy."
Figure 2: Network devices that are configured to support the dual-stack method of migration can communicate using either IPX or IP.
To deploy the dual-stack method, you enable both IP and IPX when you install or upgrade to NetWare 5 server and client software. Because the dual-stack method enables both IPX and IP packets to travel across your company's network, you don't need to plan your company's migration strategy quite as carefully as you must when you use the CMD method.
For example, if you use the CMD method, you must configure migration agents to unencapsulate packets sent to IPX segments on the network. If you use the dual-stack method, however, you only need to upgrade the network to NetWare 5.
"That's what's so nice about [the dual-stack method]," McKeith asserts. "You can do anything you want, you can migrate your network aimlessly, and there's really no place where it's going to get you."
A Preference for IP
When configured to run both IP and IPX, NetWare 5 will try first to communicate using IP. If communicating with IP doesn't work, however, NetWare 5 will try to communicate using IPX.
Because NetWare 5 prefers IP to IPX, IPX communications will eventually drop off as you migrate IPX-dependent applications to IP-dependent applications. "IPX just falls off your wire," McKeith explains. "It actually tends to get rid of itself." When IPX is no longer running on the network, you can turn off IPX on routers and unbind the IPX protocol from servers.
One obvious drawback of using the dual-stack method alone is that the entire network must use pure IP before you can turn off IPX on the routers. Although the dual-stack method doesn't adversely affect network performance, it doesn't immediately improve network performance, either. That is, while IPX is enabled, routers will still be receiving SAP broadcasts every 60 seconds. This drawback is especially significant if your biggest reason for migrating from IPX to IP is network performance.
ONE METHOD OR TWO?
Although the dual-stack method is easier to implement than the CMD method, using the dual-stack method alone is not always possible. For example, suppose your company is using both IPX and NetWare/IP on LAN segments and is using NetWare/IP on WAN segments. In this case, you will not be able to use the dual-stack method alone. (As mentioned earlier, NetWare 5 does not support NetWare/IP packets in the dual-stack mode.)
Even if it is impractical or impossible to use the dual-stack method alone, you may be able to simplify your company's migration to IP by using the dual-stack method in combination with the CMD method. In other words, to avoid unnecessarily complex migration strategies for your company's network, you can use the dual-stack method--alone or in combination with the CMD method--whenever it is possible to do so.
A STEP-BY-STEP GUIDE TO MIGRATING IPX NETWORKS TO IP
To help you understand how you can use the CMD method and the dual-stack method to migrate your company's network to pure IP, the remainder of this article explains two migration strategies. Although these strategies may not exactly meet the needs of your particular network, they will provide a starting point for planning your company's migration to pure IP.
Two to Get Ready
Suppose a company has three LANs, which communicate via WAN links. To avoid IPX routing across these WAN links, the company is using NetWare/IP gateways.
Because NetWare/IP communications occur only across the WAN links, LAN segments do not receive NetWare/IP packets. As a result, you can use the dual-stack method to migrate the LAN segments. You can then keep using the NetWare/IP gateways to route packets between the WAN links until you have eliminated IPX from the LAN segments. (See Figure 3.)
Figure 3: If a network uses NetWare/IP on WAN links, you should migrate LAN segments to pure IP before you migrate NetWare/IP gateways to pure IP.
To use this strategy to migrate the network to pure IP, complete the following steps.
Upgrade the servers--except the servers acting as NetWare/IP gateways--to NetWare 5, and then upgrade the workstations to the NetWare 5 client software. To deploy the dual-stack method, enable both IP and IPX each time you upgrade server and client software.
Because CMD is installed by default when you install NetWare 5, you must either unload this NLM or comment it out of the AUTOEXEC.NCF file. (If you do not disable this NLM, the server automatically encapsulates IPX packets in IP packets, adding an additional IPX route on the network.) To unload this NLM, type the following command at the NetWare 5 server command prompt:
UNLOAD SCMD.NLM
If NetWare/IP Domain SAP Servers (DSSs) are running on servers other than the NetWare/IP gateway servers, move these DSSs to the NetWare/IP gateway servers. (A DSS stores information contained in SAP and RIP broadcasts and then delivers this information to NetWare/IP servers upon request.)
Migrate all IPX-dependent applications to IP-dependent applications.
Unbind IPX on NetWare 5 servers. To unbind IPX, type the following commands at each server console:
UNLOAD IPXRTR
(If IPX routing is not enabled on your server, this command is unnecessary.)
UNBIND IPX FROM<NODE NAME>=<NETWORK ADDRESS OF SERVER>
Replacenode namewith the appropriate node name, and replacenetwork address of serverwith the address of the NetWare 5 server.
If you later discover that you have not successfully eliminated IPX-dependent applications from the network, you can rebind IPX to a server by typing the following commands at the server console:
LOAD IPXRTR
(This step is unnecessary if you do not need IPX routing on your network.)
BIND IPX FROM<NODE NAME>=<NETWORK ADDRESSOF SERVER>
When the LAN segments are no longer running IPX, upgrade the NetWare/IP gateway servers to NetWare 5 and enable only pure IP. Disable DSS and NetWare/IP on these servers. (For detailed information about how to disable NetWare/IP and DSS, see theNetWare/IP Administrator's Guideathttp://www.novell.com/documentation/lg/nias42/docui/index.html#../uscomm/nwip_enu/data/hfpxmpbo.html.)
The Combo
Suppose a network includes two or more LANs that use IPX to communicate across WAN links. To migrate this network to pure IP, you may want to use a combination of the CMD and dual-stack methods. To use this migration strategy, complete the following steps:
Install NetWare 5 on the servers at each end of the WAN links, and configure CMD to run as a migration agent. (See Figure 4.) Although CMD automatically loads when you install NetWare 5, you must manually configure CMD to act as a migration agent by typing the following command at the server console:
Figure 4: When migrating a network to pure IP, you may need to use a combination of migration methods. For example, you can use the dual-stack method on IPX LANs, and you can use the CMD method on WAN links.
LOAD SCMD.NLM/BS
The migration agent allows IPX LANs to communicate over WAN links using IPX-in-IP encapsulation, eliminating the need for IPX routing across these links. In this configuration, SLP and NLSP take over the function of SAP broadcasts. (For more information about configuring CMD, see Novell's Technical Information Documents [TIDs] about SCMD.NLM at http://support.novell.com/cgi-bin/search/tidfinder.cgi?2944065. See also "Migrating to Pure IP With NetWare 5,"NetWare Connection, Sept. 1998, pp. 34-37. You can download this article from http://www.nwconnection.com/past.)
Upgrade servers to NetWare 5, and upgrade the workstations to the NetWare 5 client software. Enable both IP and IPX on the servers and workstations.
If possible, reconfigure IPX-dependent applications to communicate via IP.
Note: Note: You can reconfigure some IPX-dependent applications that run on NetWare, such as Lotus Notes 4.6 and above, to be IP-dependent. (You can deploy Lotus Notes in either TCP/IP mode or SPX/IPX mode. For more information about Lotus Notes, visit http://www.lotus.com/home.nsf/tabs/lotusnotes.)
If it is not possible to reconfigure existing IPX-dependent applications, replace these applications with IP-dependent applications.
After you have completely eliminated IPX from your company's network, unbind IPX at NetWare 5 servers. You can unbind IPX by typing the following commands at each server console:
UNLOAD IPXRTR
(If IPX routing is not enabled on the server, this command is unnecessary.)
UNBIND IPX FROM<NODE NAME>=<NETWORK ADDRESS OF SERVER>
If you later discover that you have not eliminated IPX-dependent applications from your network, you can rebind IPX to the servers by typing the following commands at each server console:
LOAD IPXRTR
(This step is unnecessary if you do not need IPX routing on your network.)
BIND IPX FROM<NODE NAME>=<NETWORK ADDRESS OF SERVER>
Unload the SCMD.NLM from the NetWare 5 servers that are running the migration agent.
The Consultant Is In
Whether your company's network is as simple as the networks described in this article or much more complicated, you may want to talk to a Novell consultant about the best plan for migrating your company's network to pure IP. Novell consultants can help you determine which migration method will work best for your company's network. You can find out more about the services Novell Consulting offers by visiting http://consulting.novell.com.
CONCLUSION
Changing your company's network can be daunting--especially when that change includes changing network transport protocols. No matter which method or combination of methods you choose to migrate your network from IPX to IP, you will have to plan a migration strategy--a strategy that includes becoming more familiar with IP. As Hanchon points out, IP "is a different beast for [NetWare] administrators" who are accustomed to managing plug-and-play IPX networks.
No matter how uncomfortable change may be, change is arguably inevitable. With NetWare 5, however, you may find that migrating your company's network transport protocol is less difficult than you now imagine it to be.
Cheryl Walton works for Niche Associates, an agency that specializes in writing and editing technical documents.
Agents Give 'Em the SLP
Service Location Protocol (SLP) is a service discovery protocol for TCP/IP. Based on the Internet Engineering Task Force (IETF) Request For Comments (RFC) 2165, SLP is designed to enable network devices, such as servers, to locate other devices and services available to the network. (You can download RFC 2165 at http://www.ietf.org/rfc/rfc2165.txt.) A service agent is a SLP component that is responsible for advertising available services to network devices.
Unlike Service Advertising Protocol (SAP), SLP sends multicast packets--not broadcast packets--to request information about services that are available on the network. Only network devices that have been configured to recognize a specific multicast address will accept packets with that address. In contrast, all network devices must accept broadcast packets. SLP sends multicast packets only when network devices, such as users' workstations, are booted.
For example, when a user boots a workstation that is running NetWare 5 client software, this software sends an SLP multicast request for information about services that are available on the network. SLP service agents running on NetWare 5 servers use unicast packets to send the requested information to the NetWare 5 client software. A unicast packet goes only to the network device--in this example, the user's workstation--to which that packet is addressed. (For more information about SLP, see "Service Location Protocol: Discovering Services in a Pure IP Environment," NetWare Connection, July 1998, pp. 32-37. You can download this article from http://www.nwconnection.com/past.)
* Originally published in Novell Connection Magazine
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.