Novell is now a part of Micro Focus

NetWare IPX Routing Enhancements

Articles and Tips: article

JOE GERVAIS
Product Marketing Engineer
NetWare Enterprise Products

01 Dec 1994


The IPX™ Upgrade for NetWare Servers product is a collection of enhancement NetWare® Loadable Module™ software provided for NetWare 3™ and NetWare 4™ servers. This Application Note describes the major enhancements made to the Internetwork Packet Exchange (IPX) routing code in this upgrade. These include new management capabilities for IPX, features such as filtering and load balancing, as well as other requested modifications to IPX routing, such as being able to disable routing on a NetWare server. The AppNote lists which files to load on the server and gives example configurations for the various IPX routing enhancements.

A companion AppNote, "Customizing Your NetWare Link Services Protocol Routing Configuration" in this issue, describes how to implement the NLSP routing enhancements contained in this upgrade.

Related AppNotes Sep 94 "Effectively Managing RIP and SAP Traffic with Filtering" May 94 "NetWare Link Services Protocol: Link-State Routing in a NetWare Environment"

Introduction

This Application Note describes the major enhancements made to the IPX routing code for NetWare 3 and NetWare 4 software in the IPX Upgrade for NetWare Servers product. These enhancements include increased IPX routing functionality (including NetWare Link Services Protocol™ [NLSP™] routing), the capability to disable IPX routing on a NetWare server, load sharing, filtering, and enhanced manageability.

This AppNote lists the files that comprise the IPX Upgrade for NetWare Servers and tells which ones to load for enhanced IPX routing operation. It also gives examples of how to configure server AUTOEXEC.NCF files for the various options. A companion AppNote, "Customizing Your NetWare Link Services Protocol Routing Configuration" in this issue, describes how to implement the NLSP routing enhancements contained in this upgrade.

Upgrade Overview and Installation

The IPX Upgrade for NetWare Servers product is a collection of enhancement NLM software provided for NetWare 3 and NetWare 4 servers. One key point is that to take advantage of the new functionality offered in this upgrade, no changes are required to the NetWare Client™ software. You can continue to use your NETX or Virtual Loadable Module™ (VLM™) client and take full advantage of these routing enhancements.

The IPX Upgrade for NetWare Servers is available from the following sources:

  • The NetWire electronic bulletin board. Type GO NOVLIB , then download the files:

    NOVLIB\08\IPXRTR.EXE
NOVLIB\08\IPXDOC.EXE

  • Anonymous FTP from ftp.novell.com. Log in, then copy the files:

    pub/novlib/08/ipxrtr.exe
pub/novlib/08/ipxdoc.exe

  • The Novell Network Support Encyclopedia Professional Volume(NSE Pro) CD-ROM. Type CD DOWNLOAD, then download the files:

    IPXRTR.EXE
IPXDOC.EXE

Overview of Components

This section presents the new files introduced with the IPX Upgrade for NetWare Servers product. The following NLM files represent the minimum set required for enhanced IPX operation:


IPXRTR

IPX protocol stack that containsthe NLSP and RIP/SAP routing software. IPXRTRuses the loadable router interface that isbuilt into NetWare 4 or implemented in IPXSTACK forNetWare 3. IPXRTR automatically loads theAFTER311 and A3112 modules.

IPXSTACK

Patch that provides the NetWare 4 loadable routerinterface for NetWare 3 software. IPXSTACKis required only on NetWare 3 servers.

NCPIDFIX

Patch that corrects a problemwith the NetWare 4.01 loadable router interface.NetWare 4.01 also requires NetWare DirectoryServices to be upgraded to at least DS296for proper operation of IPXRTR. For thesereasons, Novell strongly encourages usersto upgrade to the latest version of NetWare4, rather than implement IPXRTR on NetWare4.01. NCPIDFIX is required only onNetWare4.01 servers.

Several additional NLM files are also introduced with this release:


IPXCON

New utility NLM file that provides access tothe Simple Network Management Protocol (SNMP)Management Information Base (MIB) objectsprovided in IPXRTRNM. The IPX network management console (IPXCON) automatically loads IPXRTRNM ifit is not already loaded. IPXCON also automaticallyloads NWSNUT and TUI.

IPXPING

New utility NLM file to "ping" a remote systemwith IPXRTR software running on it. Third-partyrouters that implement the entire NLSP suitealso respond properly to IPXPING.

IPXRTRNM

New module that provides the SNMP instrumentation for three MIB groups: IPX MIB, NLSP MIB, andRIPSAP MIB. IPXRTRNM allows you to monitorthe server from a remote location using anSNMP management system. Although IPXRTRNMis not required for operation, Novell recommendsthat you load it as part of the server configuration.Note also that IPXRTRNM automatically loadsSNMP.NLM, IPXS.NLM, TLI.NLM, STREAMS.NLM,and CLIB.NLM; make sure the server has enoughmemory to load these additional NLM files.

Note: The supplemental disk provided with the IPX Upgradefor NetWare Servers software includes ASN.1formatted text files to integrate the IPX,NLSP, and RIPSAP MIBs into systems with MIBcompilers, such as NetWare Management System™(NMS)™ software, LANalyzer™for Windows software, and third-party SNMPmanagement software.

Installing the IPX Upgrade for NetWare Servers

Because of space considerations in making the upgrade work for customers with either 3.5" diskette drives or 5.25"diskette drives, one file (IPXCON.NL_) is compressed on the first floppy diskette. Unfortunately, due to the way the compression logic is implemented in the PINSTALL.NLM file supplied with the IPX Upgrade for NetWare Servers, PINSTALL will only decompress files from diskette and not from a NetWare volume.

To be able to install the software from a NetWare volume, you will have to install it once from diskette. Once you have done that, the decompressed IPXCON.NLM file exists in the SYS:SYSTEM directory of the server on which you installed the product. You then can replace the IPXCON.NL_ file with the IPXCON.NLMin the \IPXSERV1\IPX directory on the volume that you will be using as a source for future installations. With this uncompressed file in place, you can now use the NetWare volume as the source during future installations.

Loading IPXRTR

IPXRTR contains the NLSP and RIP/SAP routing software. The LOAD IPXRTR command supports the ROUTING= parameter, with which you can specify the following options:

  • ROUTING=RIPSAP enables RIP/SAP routing-the default setting. In this case, IPXRTR operates like a typical RIP/SAP router.

  • ROUTING=NLSP enables NLSP routing on the server. However, if IPXRTR detects RIP routers on the network, it automatically runs RIP/SAP in addition to NLSP.

  • ROUTING=NONE disables all IPX routing on the server in a RIP/SAP network.

Loading IPXRTR without specifying one of these options enables RIP/SAP routing by default. All other required NLM files are loaded automatically.

During installation, the NLSPAUTO.NLM file is executed to edit the AUTOEXEC.NCF file. It places commented LOAD lines to assist you in configuring the product. When you have reviewed and edited these comments to produce actual LOAD lines for your server, they should look like ones shown in the table below, depending on the NetWare version being used on the server. (Note that these examples do not have the ROUTING=parameter specified.)


To run IPX Upgrade on this type of server:

Add these lines to the AUTOEXEC.NCF file:

NetWare 3 server

LOAD IPXSTACK LOAD IPXRTR LOAD IPXRTRNM*

NetWare 4.01 server

LOAD NCPIDFIX LOAD IPXRTR LOAD IPXRTRNM*

NetWare 4.02 server

LOAD IPXRTR LOAD IPXRTRNM*

*Loading IPXRTRNM is recommended, but not required.

Activating the New Configuration

To activate the new IPX routing configuration, bring down the server and then restart it.

Sample Configurations

This section provides sample configurations for the IPX Upgrade for NetWare Servers. Each sample shows the commands you need to add to the server's AUTOEXEC.NCF file.

Improving RIP/SAP Processing on a NetWare 3.11 Server

With NetWare 3.11, RIP and SAP processing in large internetworks (those with 500 or more services and networks) starts consuming a significant amount of server CPU time. This was due to an inefficient method of scanning the routing and service tables in NetWare 3.11.

NetWare 3.12 and NetWare 4 use a new hashing algorithm that is much more efficient than the previous algorithm. The IPX Upgrade for NetWare Servers implements this same algorithm. To take advantage of this algorithm on a NetWare 3.11 server, you need to install the IPX Upgrade for NetWare Servers software and place lines similar to the following in the server's AUTOEXEC.NCF file:

LOAD IPXSTACK
LOAD IPXRTR
LOAD IPXRTRNM

#Load and bind LAN board
LOAD NE3200 SLOT=3 FRAME=ETHERNET_II NAME=ORDER_ENTRY_NET
BIND IPX ORDER_ENTRY_NET NET=C9971223

This sample configuration enables the new RIP/SAP routing algorithm on a NetWare 3.11 server. This most basic configuration replaces the standard RIP/SAP operation with that provided by IPX Upgrade for NetWare Servers, and also adds server and network monitoring capability.

Disabling IPX Routing on a NetWare File Server

As a typical part of its operation, a NetWare server forwards IPX packets between its network interfaces. With ROUTING=NONE enabled, the server still performs its duties as a file server, but broadcasts only its own services and internal network number-not those associated with its network interfaces. (A server operating in this way is sometimes called a multihomed server.)

Disabling IPX routing eliminates the burden of forwarding packets from the file server, leaving more resources available for other processing such as file, print, and database services. It also allows higher routing performance from systems such as dedicated routers running NetWare MultiProtocol Router software.

As an example of how this works, consider the network shown in Figure 1. By default, file server ENG1 forwards information about itself plus servers ACCT1 and MKTG1 to each of its attached networks. This information is also available from Router A and Router B.

Figure 1: By default, server ENG1 acts as a router between its two attached network segments.

Disabling IPX routing on the file server, as shown in Figure 2, forces traffic from the MANUFACTURING_NET network to pass through one of the routers instead of the file server to reach the ORDER_ENTRY_NET network.

Figure 2: With IPX routing disabled, traffic must pass through Router A or Router B and cannot go through server ENG1.

The AUTOEXEC.NCF file on server ENG1 looks like this:

#ROUTING=NONE disables all IPX routing
LOAD IPXRTR ROUTING=NONE
LOAD IPXRTRNM

#Load and bind LAN boards
LOAD NE3200 SLOT=3 FRAME=ETHERNET_II NAME=ORDER_ENTRY_NET
BIND IPX ORDER_ENTRY_NET NET=C9971223
LOAD NE2000 SLOT=4 FRAME=ETHERNET_II NAME=MANUFACTURING_NET
BIND IPX MANUFACTURING_NET NET=C997F13A

Disabling routing on servers can drastically reduce SAP overhead when a server is connected to the same router(s) over two or more paths. As another example, take the case of a superserver connected to six token rings, with those six rings also connected to two dedicated routers. This server must process the SAP broadcasts from each of the dedicated routers on each LAN segment. The server also prepares an update for each LAN segment, advertising all the information learned from each of the other five interfaces according to the split horizon algorithm.

With ROUTING=NONE set, the file server advertises in its RIP and SAP packets only the internal IPX network and the services contained on the file server. In large internetworks (those with over 500 advertised services), this could result in the elimination of dozens of RIP packets and hundreds of SAP packets on each LAN segment. The result is reduced processing overhead on both the file server and the dedicated routers.

Using NLSP routing is more efficient than disabling routing for multihomed servers. Unfortunately, for many customers it may be a number of months before they can upgrade their routers to support NLSP routing. Until these customers can fully deploy NLSP routing, disabling routing is an alternative.

Note: Use ROUTING=NONE only if you do not want the server to forward packets between its interfaces. Also ROUTING=NONE must not be used on NLSP-only network segments. IPXRTR does not support both ROUTING=NONEand ROUTING=NLSP concurrently on a system, which forces systems with routing disabled to depend upon RIP and SAP to keep their binderies updated.

Load Balancing on a NetWare File Server

Traditionally, a NetWare server has been allowed only one logical attachment to each LAN segment. This does not provide redundancy for instances when a LAN adapter or cable segment fails, nor does it allow load balancing to be done from the server to today's Ethernet and Token Ring switching hubs.

With ROUTING=NLSP enabled, the server is allowed multiple attachments to the same segment. The server answers Get Nearest Server requests based on current load, and so distributes the load from multiple clients across the interfaces.

LOAD and BIND Commands. To enable this type of load balancing, the AUTOEXEC.NCF file should look like this (assuming a NetWare 4.02 file server): 

LOAD IPXRTR ROUTING=NLSP
LOAD IPXRTRNM

#Load LAN boards
LOAD NE3200 SLOT=3 FRAME=ETHERNET_II NAME=ETH_SW_P1
LOAD NE3200 SLOT=4 FRAME=ETHERNET_II NAME= ETH_SW_P2

#Bind LAN boards
BIND IPX ETH_SW_P1 NET=C9971223
BIND IPX ETH_SW_P2 NET=C9971223

In this case, both network interface cards must be attached to the same physical network segment, whether it is joined by a hub, a switching hub, or a bridge.

Setting MaxPaths in the NLSP.CFG File. To enable true path splitting, some additional work is required. You must create a special file named NLSP.CFG in the file server's SYS:ETC directory. This is a text file that contains configuration information for NLSP. In this file, you need to set a MaxPaths parameter using the following syntax: 

{ GLOBAL
  MaxPaths = n
}

The value for n in the MaxPaths parameter must be in the range 1 to 8. The number to use depends on the topology of your network.

For example, suppose you want to enable load sharing between two NLSP devices, such as a server and a router, with two NICs each, interconnected by two LAN segments, as shown in Figure 3a. Each of these segments has a unique IPX network number. In this case, you would set MaxPaths to 2. The setting in NLSP.CFG looks like this:

{ GLOBAL
  MaxPaths = 2
}

MaxPaths is set to 2 to allow traffic along the following paths:

  • Server NIC A to Router NIC A

  • Server NIC B to Router NIC B

If the server and router are interconnected by a switching hub, you have the potential for four paths to be active, as illustrated in Figure 3b. You set MaxPaths to 4 because you must allow traffic along the following paths:

  • Server NIC A to Router NIC A

  • Server NIC A to Router NIC B

  • Server NIC B to Router NIC A

  • Server NIC B to Router NIC B

A sample NLSP.CFG file that enables load sharing across two switched paths is as follows:

{ GLOBAL
  MaxPaths = 4
}

Figure 3: The NLSP MaxPaths setting depends on the topology of the network.

Remember, NLSP routing must be enabled by adding the ROUTING=NLSP option to the LOAD IPXRTRcommand.

Managing IPX NetBIOS and Other Type 20 Packet Traffic

Prior to the release of IPX Upgrade for NetWare Servers, NetWare forwarded NetBIOS packets that were encapsulated inside IPX by default. There was no mechanism to restrict or filter this traffic. IPX Upgrade for NetWare Servers includes a new SET command that enables you to control the propagation or completely filter out Type 20 packets through the server's interfaces. (Type 20 is a special IPX packet type that refers to any propagated packet. NetBIOS packets, for example, are Type 20 packets.)

To use this command, type the following at the server console:

SET IPX NETBIOS REPLICATION OPTION [0|1|2|3] <Enter>

You can type the command without a number to check the current setting, or you can specify one of the numeric options described in the table below.


Setting
Description

0

Server discards, rather than propagates, any Type 20 packet it receives. This option filters all Type 20 packets.

1

(Default) Serverreceives and propagates Type 20 packets throughall its interfaces, regardless of whetherthose interfaces are equal-cost routes tothe same source (that is, the server fromwhich the packets originated).

2

Affects howthe server propagates Type 20 packets in two ways:

- The server does not re-propagateType 20 packets originating from the samesource but received through different interfaces.For example, if Server A receives a Type20 packet from Server B, it forwards thepacket through its other interfaces. If ServerA then receives the same packet from ServerC, it discards it. This is a packet forwardingmechanism known as reverse path forwarding.

- The server does not propagate Type20 packets through the same interface fromwhich it receives them. This is known assplit horizon, a technique used with RIPand other distance vector routing protocols.

3

Server propagatesType 20 packets the same way as in Option2, but does not forward them across WAN connections.

Option 3 is not applicable for servers that do not have the NetWare MultiProtocol Router software installed. The other three options can be summarized as follows:

Option 0 No NetBIOS allowed

Option 1 Standard NetWare action (default)

Option 2 Full NetBIOS connectivity with minimal packet propagation

From these choices, you should be able to select the option that best meets your network traffic needs.

Network Management Features

As mentioned earlier, IPX Upgrade for NetWare Servers includes several new utilities to enhance the manageability of NetWare servers. These utilities are IPXCON and IPXPING.

The IPXCON Utility

IPXCON is an SNMP console that runs on the server. IPXCON has the ability to view the IPX MIBs for the local server, as well as viewing these MIBs through SNMP over UDP/IP or SNMP over IPX. This provides considerably more power than was previously available in consoles such as TCPCON, because now you can troubleshoot a protocol over that protocol or using an alternate protocol.

For a system running RIP and SAP, IPXCON provides all the information available through the DISPLAY SERVERS and DISPLAY NETWORKS commands, as well as a wealth of additional information. Just from the opening screen shown in Figure 4, you receive immediate feedback on the operation of your IPX internetwork. Additional information is also provided on IPX error conditions and on individual network interfaces.

Figure 4: The opening screen of the IPXCON utility displays information about IPX internetwork operation.

Because IPXCON is an SNMP console, every piece of information presented in IPXCON can also be obtained from a MIB browser from any other SNMP console.

The IPXPING Utility

IPXPING is a simple NLM for checking connectivity to systems running IPXRTR. Like the IP Internet Control Message Protocol (ICMP) echo request, an IPX ping packet is sent to a remote system and echoed back. Because IPXPING uses the IPX ping protocol defined in the NLSP specification rather than the IPX diagnostics port, it cannot ping clients or other systems that have not implemented the same IPX ping protocol.

Summary

This Application Note has given an overview of some of the more important features of the IPX Upgrade for NetWare Servers, including load balancing, filtering, disabling routing, and new management capabilities for IPX. These features have been implemented in response to a number of customer requests, and also to provide an enhanced IPX environment for the future.

* 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