Novell is now a part of Micro Focus

Migrating from IPX to Pure IP

Novell Cool Solutions: Feature
By Fahim Siddiqui

Digg This - Slashdot This

Posted: 13 Apr 2006

Migrating NetWare 5.1 Servers from IPX to Pure IP - A Synopsis
By: Fahim Siddiqui

Back in early 2005, when we decided to make a shift from IPX to Pure IP based NetWare 5.1 servers; we were under the impression that we are probably the last in the NetWare's install base to do so.

Albeit many apprehensions, we embarked on the changeover process. Various available documents were scanned for gaining insight into how Novell deals with TCP/IP, some of them written way back in 1999. Much to our dismay, many of such articles/tech notes were found dealing with large, multi geographical, multi server environments with only few dealing with a small NetWare Infrastructure serving around a 500 users on a LAN like ours.

Our single tree, single partition, multiple OU design is served by three NetWare 5.1 servers that are accomplishing our File/Print needs just fine, with IPX/IP dual stacked on the workstations we could spend weekends and weekdays with a peace of mind of not having our major or core services running on IP and being prone to regular IP based attacks from within or outside.

Nevertheless, it had to change. There was now a need to take servers to WAN and implement VPN from locations outside our secure zone. Our new CISCO Routers 2600 Series no longer support IPX and that further precipitated the decision in IP's favor.

Quite surprisingly, recent visits to various forums and groups brought home the fact that unlike what we had initially thought; we are definitely not the last ones in the world to undertake this changeover, as many NetWare administrators are still contemplating on such a move and have various questions on the subject, for which they seek answers.

Synopsis and Tips:

To make matters a bit easier for them, I thought of putting together a few tips and lessons learned from experience.

Tip 1: Be very certain of your needs before you make the jump to IP. There could be two reasons for making such a move. Either a corporate wide policy, a genuine requirement to do so or a mix of both. In our case, the most secure infrastructural option would still be to continue with what we had. We had ipx and ip dual stacked on the workstations and 'IPX only' on the file servers. With an IPX/IP enabled perimeter firewall/gateway (Fire starter on SuSe Linux 9.3) to secure the network. Alternatively. Winsock Proxy server or with the help of Microsoft Proxy 2, Internet connectivity could have been established even from Pure IPX workstations.

Tip 2: Having made sure of the strong case to migrate to IP, Start by verifying that all applications can run in a pure IP environment. Test them in a test environment. We almost eliminated SCMD usage having successfully ported everything to IP. To know bit more about SCMD and see if you are in need of it, check out:

Tip 3: If possible create a test lab. Decide whether to do an in-place upgrade of your Servers or do a Data migration on new hardware. Ours was a case of Hardware upgrade and so it made the migration a lot easier. I suggest that you get hold of new server class machines for your upgrades as after installing Service Pack 8 and EDirectory, there is quite an increase in the thirst for CPU/RAM resources by NetWare 5.1.

So how did we go about it? Most of the related resources for NetWare 5.1 product can be downloaded from here:

eDirectory base 8.7.3 is available here:

eDirectory base upgrade to is available here:

Note: The version that we used in our setup was and has since been taken off file finder. You can as well use instead.

Without getting into details of our existing version/patch level of our pre-upgrade NetWare 5.1 servers, our post-upgrade goal was to have NetWare Servers 5.1, patched up to Service Pack 8 and NDS upgraded to eDirectory version

So, on new machines, NetWare servers were built from an English / Portuguese Overlay NetWare 5.1 SP8 CD (128 bit). Yes! There is never an English only Overlay CD image there. You can legally use 128bit encryption even if you are licensed for anything lower.

Tip 4: Have an IP Scheme ready. Do you need to use DNS/DHCP? Would your NetWare Servers host DNS/DHCP services (recommended and easier to configure), also decide on hostnames and domain name server now.

Note: A DNS/DHCP Servers doesn't require user connection licenses, just the 'Base server + 5 Connections' license will do. We used one such for catering to our DNS/DHCP needs.

Tip 5: After the base NetWare Installation it's advisable to do a NICI upgrade to version 2.6.8:

Having installed/upgraded all the required servers to SP8 and NICI 2.6.8, it's time to start undertaking eDirectory upgrade. You already have eDirectory base 8.7.3 CD built from ISO CD given above. Having installed base 8.7.3 on all the servers in your partition/tree, I upgraded to sub version 4 (in your case it would be sub version 7 of Dir 8.7.3.

Note: During the install of eDirectory, amongst the products listed, choose to also install the following: NDS iMonitor services and eDirectory management Utilities toolbox including SLPDA snap in.

Once all the servers are at the same patch levels, you are ready to configure SLP.

Tip 6: You can check your version / patch levels of your server by typing 'version' at the console prompt. Alternatively at the server console, 'load nwconfig', then Product Options, then View/Configure/Remove installed products, and then check the listing for SPACK to know about Service Pack level, as an example.

Configuring SLP

Concept: This is the preferred method to configure NetWare 5.x on IP infrastructure that contain eDirectory. One or more servers are strategically designated as Directory Agents (DA) while other Servers (also called Service Agents) are configured to register their services to these DA. Clients that are termed as User Agents (UA), then query the DA with a unicast request as opposed to multicast (in non-SLPDA environment) and receive their answers back quite quickly.

Configuration of SLP was probably a few minutes job but it took us a month. Month not in configuration but in fine tuning it and making it work for us the way we wanted.

Now, you would like to let have a glimpse of our TREE structure. (All names/IP assignments have been changed to ward off the black hats out there.)

Figure 1

The IP Scheme was based upon VLSM, as we didn't have a spare router or a Layer 3 switch for Inter-Subnet / InterVLAN routing (then) and it was a requirement to accommodate more than 254 clients. The good thing about NetWare is, it's easy to change the subnet mask but the bad one is that it's difficult to change the IP addressing or names of the Servers. Now that we do have Layer 3 switches, we can easily shift over to multiple subnets/VLANS as desired but more about that design as and when we implement it.

The current scheme is based upon Class A Private addressing scheme of 10.x.x.x network (RFC 1918)

With the Network ID of: and a subnet mask of (23 bits masked), we managed to get a maximum of 510 hosts.

Note: NetWare does support VLSM (variable length subnet masking) but does not support usage of CIDR notations while configuration.

Say, the IP's I assigned to my Servers are as follows:
IP to Server X :
IP to Server Y :
IP to Server Z (Also acting as my DNS/DHCP Server) :

Keeping in mind that we had to span across subnets and routers at a later stage, it was incumbent that we incorporate at least one SLP Directory Agent in our NetWare tree. Server A being Master Replica, we chose it to be the Directory Agent. If the intention would have been to keep our network within one subnet long into the future too, there was no need for us to configure SLP. NetWare folks tout SLP DA as a 'good practice' network design and they have reasons for saying this. SLP does for IP what SAP did for IPX all along.

There is no dearth of TIDs dealing with the need and technology behind configuring SLP DA on NetWare. Some of the more useful ones are TID No 10062474, 10014467, 10059981 & 10060296. Yes! You should go through them all to get a grip on this topic.

Hence, we configured Server A as DA and Servers B and C as SA (Service Agents). Server C also serves as our DNS/DHCP server for the clients.

Figure 2

Note: The network diagram above is most basic, neither the best nor the most secured.

We had kept the initial 50 IP addresses for configuring other servers / printers/ management switch interfaces etc. while leasing out the remaining 460 to our clients with a set time limit.

So, Server A was configured to be our SLP DA. One of the requirements for configuring SLP DA is that the server selected to act as DA should be a master or read write replica within the partition. Server A was our Master. As we had a single Tree, we chose to go with only single SCOPE and 'DEFAULT' as it's name.

To make Server A, a SLP DA of our 'ABC_TREE', we did the following;

On Windows 2000 Workstation, Novell Client 4.90 SP2 works best with NMAS and NICI options chosen. NMAS might be later used to incorporate Mobile iManager 2.5 during testing and NICI is mandatory if you want to use Console One's Version 1.3.6 as this is the version we get after SP8 upgrade. Assigned a static IP: to our Client PC.

  • Step 1: After launching Console One as admin / admin equivalent to root of the tree and selecting OU=X (The container unit where our Master Server A resides), Create an object of class 'SLP Scope Unit' and name it as 'DEFAULT'. Someone mentioned that upper/lower case matter so maintain 'cases'. Wouldn't harm!

  • Step 2: Create another object of class 'SLP Directory Agent' within the same container (OU=X).

  • Step 3: On Server A console prompt (not the Console One GUI), load MONITOR ->
  • Server parameters -> Service Location Protocol -> SLP Scope List -> Insert (Enter the Scope name DEFAULT)

  • Step 4: On Server A's console: type 'EDIT SYS:\ETC\SLP.CFG', and make sure that all the lines are commented out.

  • Step 5: On console prompt type: 'RESET SERVER', and wait for the server to reboot.

  • Step 6: When the server has rebooted, from the console prompt again, type 'load SLPDA'. Add this entry into the 'AUTOEXEC.NCF' too by doing a 'edit autoexec.ncf'.

  • Step 7: From console of Server A, type 'edit c:\nwserver\startup.ncf', and the add the following:


    Note: Do make sure that this TCP = OFF setting is in place. Missing on this small detail gave us a tough time. The setting was recommended ON for communication between DA and SA, but we realized the hard way that setting this to on, none of the clients (Windows 2000/XP) were able to communicate with SLP DA as they send queries via UDP ports and got a reply via TCP ports ending up in a no response. The only exceptions to this were Windows 98 SE clients. Don't ask me how this works with Win98 clients. Probably a case of the OS design for communications.

    Shifting over to Servers B and C (Non DA Server), we did the following

  • Step 8: Repeat of step 3 on Server B and C and a do reset/reboot of servers.

  • Step 9: From Console: 'EDIT SYS:\ETC\SLP.CFG', added a line at the end of file: DA IPV4, where is our SLP DA's IP address.

  • Step 10: From console of Server B and C respectively, type 'edit c:\nwserver\startup.ncf', and the add the following lines:


    Note: Option 12 means that we have statically defined our DA within this SA by entering it's IP entry previously in SLP.CFG file. It's binary value (0x04 + 0x08), meaning that if the Servers (B and C) finds a valid DA from SLP.CFG file, dynamic discovery will be disabled and network traffic will be reduced. 'SLP Default Lifetime' parameter determines how often an SA will try to register it's services with DA (Server A). The default for this parameter is 3600 seconds (1 Hour). We had set this to 12 hours (43200) in order to reduce the network traffic again.

  • Step 11: On all the three servers console, type: STARTUP to bring the changes done on 'startup.ncf' into effect.

    To test whether your configuration is flawless, type "Display SLPDA" at the consoles of Servers B and C. You should see a line that starts with : ACTIVE

    Type "DISPLAY SLP SERVICES BINDERY.NOVELL" at console of Server A. One URL for every SLP configured NetWare 5.1 server would be displayed. In this case, we saw it for Servers B and C.


This part is comparatively easy. Choose to install DNS/DHCP Services on Server C during the initial install of the server.

The related documentation is available at:

In the set up shown in Figure 2, Server C is acting as a secondary DNS Server for we had a Primary on the Public address. Hence the configuration of DNS on Server C was done in order to forward all Internet requests while resolving only internal O=ABC related queries, with zone type of Server C set to secondary (Read page 82 of the above listed pdf document). The main purpose of this was to be able to easily access NetWare Management Portal and Intranet services by assigning them URL.

The same server is also responsible for leasing out addresses to the workstations on 10.20.30.* subnet.

An old article by Charles Steinhaus on configuration steps of DHCP, is still much relevant and available at:

The last hitch was to push the SLP parameters via NetWare DHCP server. Here's how it can be done:

And finally NDPS:

NDPS relevant documentation is available at:

Prior to upgrade, all our printers were queue based and currently all are NDPS enabled. There is also an alternative of directing print jobs to queue based printers through NDPS through the transition. The procedure of doing so is defined on Page 95 of the NDPS admin guide, but we should strive to completely do away with such mixes unless absolutely unavoidable.

Also, use Novell gateway instead of the inbuilt HP Printer Gateway if you have to enable HP Printers to work in your NDPS environment. Novell gateway works far better than native HP gateway for HP Printers.

Tip 7: To start nwadmin for NDPS configuration (yes!! It's not possible via ConsoleOne), from windows Start-Run type: "nwadmin32.exe /disabletlsmgr", or else, you will not be able to activate the 'browse' button while adding printer drivers to NetWare Broker's resource management service.


Shifting to pure IP is a labor-intensive job as it would require you to go to each and every workstation in your organization and re-install the clients with new options. The labor can be minimized with meticulous planning and should be done in phases keeping both the networks (old ipx and new IP) in place for some time. The best option for smaller (LAN only) networks is to build up the IP only NetWare servers on a separate piece of hardware from scratch. Not many company administrators can enjoy such lavish resources but if you can, then you'll be in a better position to deal with nasty surprises that usually spring up during such migrations.

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions.

© Copyright Micro Focus or one of its affiliates