Customizing Your NetWare Link Services Protocol Routing Configuration
Articles and Tips: article
Product Marketing Engineer
NetWare Enterprisee Products
01 Dec 1994
This Application Note describes the new NetWare® Loadable Module® (NLM™) files used for NetWare Link Services Protocol™ (NLSP™) routing available for NetWare 3™ and NetWare 4™ software in the Internetwork Packet Exchange™ (IPX™) Upgrade for NetWare Servers. After providing an overview of the files, this Application Note describes specific customizations to tune the operation of your NLSP network.
A companion AppNote, "NetWare IPX Routing Enhancements" in this issue, explains how to install and use the non-NLSP IPX 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
- Upgrade Overview and Installation
- Overview of NLSP Routing
- Tuning NLSP for Optimal Performance
- Summary
Introduction
This Application Note describes the new NetWare Loadable Module (NLM) files used for NLSP routing available for NetWare 3 and NetWare 4 software in the IPX Upgrade for NetWare Servers. After providing an overview of the files required for NLSP routing, this AppNote describes specific customizations for tuning the operation of your NLSP network. A companion AppNote, "NetWare IPX Routing Enhancements" in this issue, describes how to implement the non-NLSP IPX routing enhancements contained in this upgrade.
Several sections of this AppNote assume a thorough knowledge of NLSP. These sections are identified, and in these sections you are warned not to make changes unless you understand the protocol and ramifications from changing certain parameters. If you are not familiar with NLSP, an overview of the protocol is available in "NetWare Link Services Protocol: Link-State Routing in a NetWare Environment" in the May 1994 Novell Application Notes. The complete protocol specification is available in PostScript* format from the NetWire® electronic bulletin board and by anonymous FTP in novlib\11\nlsp.exe.
Upgrade Overview and Installation
The IPX Upgrade for NetWare Servers is a collection of enhancement NLM files 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 that are required for NLSP operation. The following NLM files represent the minimum set required for NLSP operation:
|
IPXRTR |
IPX protocol stack that contains the NLSPand RIP/SAP routing software. IPXRTR uses the loadable routerinterface that is built into NetWare 4, or is implemented in IPXSTACKfor NetWare 3. IPXRTR automatically loads AFTER311. |
|
IPXSTACK |
Patch that provides the NetWare 4 loadablerouter interface for NetWare 3 software. IPXSTACK is requiredonly on NetWare 3 servers. |
|
NCPIDFIX |
Patch that corrects a problem with the NetWare4.01 loadable router interface. NetWare 4.01 requires NetWareDirectory Services to be upgraded to at least DS296 for properoperation of IPXRTR. For these reasons, users are strongly encouragedto upgrade to the latest version of NetWare 4, rather than implementIPXRTR on NetWare 4.01. NCPIDFIX is required only on NetWare 4.01servers. |
Several additional NLM files were also introduced with this release. The functionality of these NLM files is described in the Application Note titled "NetWare IPX Routing Enhancements" in this issue.
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=NONEdisables all IPX routing on the server.
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 NLSP operation on your own server, they should look like the ones in the table below (depending on the NetWare version being used).
|
To provide NLSP operation on this type of server: |
Add these lines to the AUTOEXEC.NCF file: |
|
NetWare 3 server |
LOAD IPXSTACK LOAD IPXRTR ROUTING=NLSP LOAD IPXRTRNM* |
|
NetWare 4.01 server |
LOAD NCPIDFIX LOAD IPXRTR ROUTING=NLSP LOAD IPXRTRNM* |
|
NetWare 4.02 server |
LOAD IPXRTR ROUTING=NLSP LOAD IPXRTRNM* |
*Loading IPXRTRNM is recommended, but not required.
Binding IPX to a Network Interface
The command for binding IPX to a network interface is as follows:
BIND IPX boardname NET=network_number >Enter<
The boardname variable is the name assigned to the network interface board associated with the LAN driver; network_number is the external network number of the IPX network to which the interface is connected.
You can override the routing default you specify in the LOAD IPXRTR command by adding one of the following options to the BIND command line:
RIP=Yes|NO|AUTO SAP=Yes|NO|AUTO NLSP=Yes|NO
These options have the following meaning:
Yes enables RIP, SAP, or NLSP routing on the network interface.
NO disables RIP, SAP, or NLSP routing on the network interface.
AUTO accepts and broadcasts RIP or SAP packets only if non-NLSP devices-such as NetWare 2 servers-are operating on the network.
Note: You cannot enable NLSP on an interface after you have disabled NLSP routing from the LOAD IPXRTR command.
Specific BIND command lines are required for interfaces connected to networks running OS/2* Named Pipes, UnixWare, and NetWare/IP. For configuration instructions, see the IPX Upgrade for NetWare Servers 1.0 NLSP Migration Guide. This guide is available in PostScript format in the IPXDOC.EXE file.
Installing the Minimum NLM Files Required for NLSP Operation
If you want to test or implement NLSP functionality but you have concerns about upgrades to CLIB and other support modules on your server, you can implement NLSP with just IPXRTR.NLM and AFTER311.NLM (plus NCPIDFIX.NLM or IPXSTACK.NLM if required for your NetWare version).
The following table lists the minimum files you need to copy from the IPX Upgrade distribution diskettes. It is assumed you will use NLSPAUTO.NLM to provide a template of load lines in your AUTOEXEC.NCF file. If you enter load lines by hand, the NLSPAUTO.NLM file is not required.
|
NetWareVersion
|
Fromthis diskette...
|
Copythese files...
|
Tothese server directories:
|
|
NetWare 3.11 |
IPXSERV1 |
IPX\IPXRTR.NLMIPX\IPXSTACK.NLM |
SYS:SYSTEM\IPXRTR.NLMSYS:SYSTEM\IPXSTACK.NLM |
|
IPXSERV2 |
3X\A3112.NLM3X\AFTER311.NLM |
SYS:SYSTEM\A3112.NLMSYS:SYSTEM\AFTER311.NLM |
|
|
NetWare 3.12 |
IPXSERV1 |
IPX\IPXRTR.NLMIPX\IPXRTR.MSGIPX\IPXSTACK.NLMIPX\IPXSTACK.MSG |
SYS:SYSTEM\IPXRTR.NLMSYS:SYSTEM\NLS\4\IPXRTR.MSGSYS:SYSTEM\IPXSTACK.NLMSYS:SYSTEM\NLS\4\IPXSTACK.MSG |
|
IPXSERV2 |
3X\A3112.NLM3X\AFTER311.NLMNLSPAUTO.NLM |
SYS:SYSTEM\A3112.NLMSYS:SYSTEM\AFTER311.NLMSYS:SYSTEM\NLSPAUTO.NLM |
|
|
NetWare 4.01 |
IPXSERV1 |
IPX\IPXRTR.NLMIPX\IPXRTR.MSG |
SYS:SYSTEM\IPXRTR.NLMSYS:SYSTEM\NLS\4\IPXRTR.MSG |
|
IPXSERV2 |
40X\NCPIDFIX.NLMNLSPAUTO.NLM |
SYS:SYSTEM\NCPIDFIX.NLMSYS:SYSTEM\NLSPAUTO.NLM |
|
|
NetWare 4.02 |
IPXSERV1 |
IPX\IPXRTR.NLMIPX\IPXRTR.MSG |
SYS:SYSTEM\IPXRTR.NLMSYS:SYSTEM\NLS\4\IPXRTR.MSG |
|
IPXSERV2 |
NLSPAUTO.NLM |
SYS:SYSTEM\NLSPAUTO.NLM |
Completing the Manual Installation
Once you copy the files, load NLSPAUTO to place configuration templates in the AUTOEXEC.NCF file. Once you run NLSPAUTO, edit the AUTOEXEC.NCF file to make the proper load lines.
For NetWare 3 systems, AFTER311 and A3112 (along with any modules that depend on these modules) must be unloaded and reloaded if an older version is running. For NetWare 4 systems, you can just load IPXRTR with the proper syntax.
Overview of NLSP Routing
This AppNote assumes you are familiar with the concepts of NLSP and have at least read the May 1994 Application Note titled "NetWare Link Services Protocol: Link-State Routing in a NetWare Environment." That AppNote gives an overview of the operation of the protocol and benefits of using NLSP, but doesn't look at the internal operation of the protocol.
NLSP introduces several new routing information packets for its operation. As opposed to IPX RIP and SAP, which only use broadcast packets, an NLSP packet can be sent either as a broadcast packet or as a multicast packet. Only the LAN adapters of NLSP devices must receive NLSP multicast packets, whereas broadcast packets must be received by all LAN adapters on the segment. The use of NLSP on a network does not change the format, use, or frequency of any IPX packets other than RIP and SAP packets. In other words, SPX and NCP packets are not changed by the use of NLSP.
Hello Packets
The first step NLSP devices take is to form adjacencies. This is done with a Hello packet. The Hello packet lists the device sending the packet and some basic capabilities of the device (such as the ability to send multicasts). It then lists all the neighbors from which the device has received Hello packets on the segment. This Hello packet is used to ensure that all adjacencies are still valid. If a device fails to receive three Hello packets from a neighbor, it assumes the neighbor is down.
Hello packets are also used to elect the Designated Router. Hello packets are sent every 20 seconds by each device except the Designated Router. The Designated Router sends its Hello packets every 10 seconds.
Link State Packets
NLSP devices are also responsible for sending Link State Packets (LSPs). Each device sends an LSP describing the device, all the networks to which the device is connected, and any services that reside on the device. This LSP is known as the non-pseudonode LSP.
On each segment, a Designated Router sends a pseudonode LSP that lists all the devices adjacent to the segment. This LSP also lists any information learned only from IPX RIP broadcasts and IPX SAP broadcasts on the segment. This RIP and SAP information does not include the contents of RIP and SAP broadcasts from other NLSP devices, nor does it include the information learned natively by NLSP elsewhere in the internetwork. LSPs are sent to every NLSP device within the NLSP area without being changed. (In contrast, RIP and SAP packets have the hop count and tick count adjusted at every hop.) Every NLSP device maintains this complete link state database and forms a complete map of the NLSP area.
LSP packets are sent every two hours unless there is change to the contents, in which case they are sent immediately.
Sequence Number Packets
On LAN segments, NLSP packets are sent without reliable delivery. Sequence Number Packets (SNPs) are used to ensure database integrity. To ensure that all devices are synchronized, the Designated Router on each segment sends out a Complete SNP (CSNP) every 30 seconds. This packet contains an ID and sequence number for every LSP in the database.
From this information, all other NLSP devices can determine whether they have the same LSPs, newer LSPs, or older LSPs. If a device has a newer LSP, it is multicast to the LAN. If a device has an older LSP, it sends a Partial SNP (PSNP) to request the missing LSP. The Designated Router then multicasts the requested LSP.
On WAN circuits, because there are never more than two devices adjacent to each other, each LSP is explicitly acknowledged by a PSNP. This mode consumes far less bandwidth than periodically sending CSNPs for two devices. On LANs with more than two NLSP devices, periodically sending CSNPs consumes far less bandwidth than explicitly acknowledging each LSP.
For More Information
There are many more details to NLSP than can be provided in this overview. For further information, refer to the NLSP specification.
Tuning NLSP for Optimal Performance
In many cases, NLSP operates very well with no tuning. NLSP was tested extensively in Novell's corporate network for over a year before product release. This extensive testing allowed Novell to learn about the characteristics of NLSP in a very large NLSP internetwork. NLSP was also tested in campus environments with hundreds of NLSP servers and routers, and on an extensive international WAN running Frame Relay and the Point-to-Point protocol (PPP).
With NetWare 4.10 and the NetWare MultiProtocol Router 3 software, you can see an extensive number of NLSP parameters in the "IPX Protocol Configuration" section of INETCFG. Novell strongly recommends that you do not change any of these parameters unless you have obtained the NLSP specification (NLSP.ZIP in NOVLIB on CompuServe* and ftp.novell.com) and thoroughly understand the protocol.
The following sections describe several of the more common parameters that might improve your NLSP internetwork operation in specific circumstances. They also describe how to do the manual configuration necessary for each of these parameters. For NetWare 4.10 and the NetWare MultiProtocol Router 3, these parameters are configured in the INETCFG utility. Global parameters are in the IPX protocol section of INETCFG, and BIND parameters are accessible when doing IPX binds.
Multicast Operation
By default, the Novell implementation of NLSP broadcasts its packets on an IPX network. The choice to use broadcast as the default transmission mode was made because some NetWare Server ODI LAN drivers do not properly support packet multicasts. However, you can and should configure NLSP to use multicast transmission. The use of multicast reduces overhead on all non-NLSP systems on a network segment. Workstations and other devices that are not NetWare servers or routers running NLSP do not have to take an interrupt for a broadcast packet that is meaningless for the workstation.
For this purpose, the LOAD IPXRTR command supports the MCAST= parameter, with which you can specify the following options:
MCAST=Yesenables NLSP packet multicast on the server
MCAST=NO (the default option) enables NLSP packet broadcast on the server
Loading IPXRTR without the MCAST parameter specifies broadcast transmission by default.
Implications of Changing Multicast Mode. IPXRTR detects the NLSP packet transmission mode of other systems on the LAN. For this reason, it is very important that you configure every NLSP system on the LAN segment to use multicast transmission. Even if you load IPXRTR with MCAST=Yes, IPXRTR automatically reverts to broadcast if it discovers another system using broadcast.
Note that with INETCFG, the multicast parameter must be changed on every bind. There is no global switch to turn on multicast by default in the NetWare 4.10 and NetWare MultiProtocol Router 3 software.
Changing Designated Router Priority
By default, NetWare systems are configured for a priority of 44 to become elected NLSP LAN Level 1 Designated Router. In some cases, you might want to designate systems that never get elected Designated Router, or that always are Designated Router if they are operational. Changing the Designated Router priority makes these states possible. For example, a system with a priority of 65 or higher always takes over operation from any NetWare system set to default values. A system with a priority of 23 or less always resigns if a NetWare system with default values is in operation on a LAN segment.
The syntax for changing the Designated Router priority in the NLSP.CFG file is:
{ BIND
Name = "boardname"
Priority = 23;
}
The variable "boardname" is the name assigned to the network interface board associated with the LAN driver. NLSP.CFG must have "boardname" in quotation marks. The Priority parameter is the priority of the router to become elected NLSP LAN Level 1 Designated Router, and can range from 0 to 127.
Implications of Changing Router Priority. The Priority parameter affects the operation of a single system and its ability to become elected NLSP LAN Level 1 Designated Router. The main risk is in designating systems that have low stability to become Designated Router, as this could decrease the stability of the network segment and cause extra LSPs to be flooded through the internetwork.
Adjusting Hello Intervals
NLSP has default Hello intervals that determine network convergence time. Because NLSP only sends LSPs when there is a change to the data in the packet or when the LSP has aged out (which, by default, is 2 hours and 5 minutes), there needs to be a mechanism to ensure that all NLSP systems are functional. For this purpose, Hello packets are generated on each network segment from every system. This traffic is contained on the local segment, and if no change occurs on that segment, no traffic is generated elsewhere on the internetwork for that segment. If the Hello process detects a system change stateCeither a newly detected system or a system failing to respond for 3 consecutive Hello intervals-the Designated Router updates the LSP for the network segment.
Typically, there are two scenarios where a customer might want to change the Hello interval. The first is in an extended, bridged segment with hundreds of NLSP devices on a single network number and low-speed bridged WAN links. This can be a source route bridged IPX network or a VSAT bridged IPX network. The second is when the customer has a WAN circuit that incurs a per-packet charge.
Adjusting WAN Hello Intervals. The NonBHello or Nonbroadcast Hello parameter changes the Hello interval for WAN circuits. This parameter is not supported by the IPX Upgrade for NetWare Servers or by NetWare 4.10. When NetWare MultiProtocol Router 3.0 software is available, this parameter can be configured under the "IPX Protocol Configuration" section of INETCFG.
Adjusting LAN Hello Intervals. . To change your LSP generation interval, you must install the SYS:ETC\NLSP.CFG file containing the following lines:
{ GLOBAL
BHello = 20;
HoldMult = 3;
DRBHello = 10;
}
This example shows the defaults. The BHello or Broadcast Hello interval is the interval that all NLSP devices (except the Designated Router) send Hello packets on a LAN, regardless of whether NLSP traffic is sent as broadcast or multicast packets. The DRBHello or Designated Router Broadcast interval is the interval that the Designated Router send Hello packets on a LAN. The valid range is from 1 to 600 seconds for BHello and from 1 to 100 seconds for DRBHello. The HoldMult or Hello multiplier is the number of Hellos a device fails to send before it is marked unreachable. The valid range for HoldMult is from 2 to 20.
Implications of Changing Hello Interval. To reduce the number of Hellos, all routers on a network segment must have the same configured values. It is possible for multiple systems to have different values without negative implications, other than having different convergence times based on different routers being elected Designated Router. Changes to the Hello interval affect how long it takes systems to detect the failure of a router or server. In some cases where there are link-level assurance protocols, such as the Point-to-Point Protocol's Link Quality Monitoring or Echo Protocol, this might not be as critical, because the data link protocol notifies IPX in most instances of link or router failures.
Adjusting LSP Generation Intervals
In Novell's operational experience, we measured a 30:1 reduction in the amount of routing information when migrating from RIP and SAP to NLSP. Some customers might want to reduce the amount of routing information even further. Hello intervals is the logical place to start; however, adjusting this impacts network convergence time. The other type of periodic traffic is LSPs. Even though NLSP has effective mechanisms to ensure LSP data is always correct through the use of sequence number packets, these packets are sent every two hours if there is no change to the contents. Changing the LSP generation interval, along with the Maximum LSP Age, can further reduce periodic NLSP traffic.
In adjusting the LSP generation interval, two parameters must be changed in tandem. In addition, these parameters must be the same on every NLSP device in the entire network. The LSP interval cannot be changed on a system-by-system basis while retaining operation of the internetwork.
If you must change your LSP generation interval, you must install the SYS:ETC\NLSP.CFG file containing the following lines:
{ GLOBAL
MaxLSPAge = 7500;
MaxLSPGen = 7200;
}
This example shows the defaults. The range is from 800 to 65,535 seconds for MaxLSPAge and from 500 to 65,000 seconds for MaxLSPGen. MaxLSPGen must be smaller than MaxLSPAge. Setting MaxLSPGen 600 seconds smaller than MaxLSPAge is reasonable.
Implications of Changing LSP Generation Interval. The tradeoff for changing the LSP generation interval is that LSP information is held in memory for a much longer period after the information is no longer valid. Even though portions of the network are no longer reachable due to changes in topology, the LSPs for the unreachable portion are retained until the MaxLSPAge time elapses.
This improves the efficiency of NLSP when there are correctable failures in the network. A link fails, and an LSP is sent reporting that link as failed. Any LSPs that become unreachable due to the failure are retained, so that if the disconnected portion of the internetwork becomes reachable again, only a single LSP is required to return that portion of the internetwork to operation. If the information being aged out will never reappear, you are consuming unnecessary memory for an extended period of time.
Adjusting LSP Size
The LSP size determines the maximum size for LSP packets that are transported across the internetwork. This affects how many networks and services can be contained in a single LSP. Changes to the LSP size can impact the amount of traffic NLSP generates during times of network transition. For this reason, this parameter should not be changed without complete understanding of the protocol.
If you must change your LSP size, install the SYS:ETC\NLSP.CFG file containing the following lines:
{ GLOBAL
LSPSize = 512;
}
This example shows the default of 512 bytes for LSPSize. The range is from 128 to 4,096 bytes.
Implications of Changing LSP Size. Changes to LSP size and the effects of those changes are network-dependent. In a pure NLSP environment, LSP size is usually not significant because LSPs are only carrying data for a single router or server. Changes to the LSP size in this environment usually have no effect, since LSPs are normally smaller than the maximum size.
In environments with large amounts of RIP and SAP being imported into NLSP, LSP size can have significant impact. In RIP and SAP environments, changes to one network or one service force the transmission of an LSP carrying many other networks and/or services.
This parameter must be the same on every NLSP device in the entire internetwork. The LSP size must also be smaller than the smallest MTU in the network. The LSP size cannot be changed on a system-by-system basis while retaining uninterrupted operation of the internetwork. There is also risk of new systems being installed on the network with default parameters, causing network disruptions. This parameter should not be changed without complete understanding of the protocol.
Adjusting Circuit Delay for Satellite Operation
In some environments, such as bridged VSAT networks, it is necessary to adjust the default delay and throughput parameters for your LAN interfaces with VSAT connections. This adjustment is made on a bind-by-bind basis.
As an example, for the load line:
BIND IPX TO VSAT_NET NET=12345678 <Enter>
the SYS:ETC\NLSP.CFG file has the following lines:
{ BIND
Name = "VSAT_NET"
Delay = 500;
Throughput = 56000;
}
Remember that the boardname variable (VSAT_NET in this example) must be enclosed in quotes in the NLSP.CFG file. The Delay parameter is the delay in microseconds for the link, and can range from 1 to 5000000. The Throughput parameter is the speed of the link in bits per second, in the range from 300 to 4,294,967,295.
Implications of Changing Circuit Delay Parameters. For proper operation of bridged VSAT networks, the changes outlined above are mandatory for proper network operation. Refer to "Wide Area Networking with VSAT: A Customer Installation" in the December 1993 NetWare Application Notes for further information about the implications of these parameters.
Summary
This Application Note has provided an overview of the NLSP routing features included in the IPX Upgrade for NetWare Servers. It has also discussed some of the ways you can optimize NLSP operation.
* 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.