NetWare Link Services Protocol

Interoperating With RIP and SAP

Laura Chappell

This article is the final part of a three-part series that focuses on NetWare Link Services Protocol (NLSP), Novell's default routing protocol for IntranetWare and NetWare 4.11. The first article in this series explained how NLSP devices create a link state database, which is essentially a map of the entire network. (See "NetWare Link Services Protocol: Building a Link State Database," NetWare Connection, Sept. 1997, pp. 38­45.) The second article described how NLSP devices update the link state database and how you can change NLSP parameters. (See "NetWare Link Services Protocol: Updating the Link State Database," NetWare Connection, Oct. 1997, pp. 34­39.) The third article explains how NLSP devices interoperate with Routing Information Protocol (RIP) and Service Advertising Protocol (SAP) devices (such as NetWare 4.1, NetWare 3.11, and NetWare 2.2 servers).

Although IntranetWare and NetWare 4.11 use NLSP, IntranetWare and NetWare clients use RIP and SAP to locate many services on a network. An NLSP device must reply to a client's RIP or SAP lookup request if the NLSP device knows the route to a particular network and considers itself part of the best route. In addition, an NLSP device may exist on a network that supports a RIP device. As a result, an NLSP device must use RIP and SAP to perform the following tasks:

SENDING AND RECEIVING RIP INFORMATION

NLSP routers are intelligent and incredibly flexible in mixing and matching routing protocols. If an NLSP device detects that a RIP router is broadcasting RIP information on the local circuit, the NLSP device automatically begins sending RIP information to the RIP device, thereby maintaining backward compatibility. (A circuit is a logical connection to the network.) For example, in Figure 1, the MPR1 router is a RIP/SAP device, and the CORP-FS router is an NLSP device.

When an NLSP device learns about a network through RIP, the device absorbs the RIP information as an Xroute, or external route. The distance of Xroutes are described in hops and ticks. (A RIP device assumes that it takes one tick--approximately 1/18th of a second--to cross any network segment.)

Although an NLSP device stores Xroute information in its link state database, only the designated router includes this information in its Link State Protocol (LSP) packet. (Each network has one designated router, which helps the other NLSP devices maintain a map of the entire network.) For example, Figure 2 shows CORP-FS's LSP packet, which includes Xroute information for networks 0x00-11-11-11 and 0xAA-BB-CC-DD.

If an NLSP device detects a RIP router on the local network, the NLSP device automatically sends RIP and SAP update packets. By default, an NLSP device sends these update packets every 60 seconds, but you can use the INETCFG utility to change this time interval.

FORWARDING PACKETS ON A MIXED NETWORK

When an NLSP device forwards packets on a network that includes both NLSP routes and RIP routes, the NLSP device adheres to the following rules:

For example, Figure 3 shows two routes from network A to network F. Router 1, which is an NLSP device, knows that pseudonode E and pseudonode G are connected to network F. (A pseudonode is a virtual device that represents the network.) Because there is no NLSP-only route, Router 1 first considers the tick counts between the two pseudonodes and network F. The tick counts are equal, so Router 1 considers the hop counts, which are also equal. Router 1 then considers the NLSP routes from A to G and A to E. The NLSP route through Router 1 and Router 7 has a cost of 20. Since this route has the lower cost, it is the better route. (For more information about costs, see "NLSP Versus RIP.")

SENDING AND RECEIVING SAP INFORMATION

When an NLSP device receives SAP information, the device absorbs this information into its link state database. The NLSP device then sends SAP update packets every 60 seconds by default.

An NLSP device also propagates SAP information through LSP packets, as shown in Figure 4. LSP 0x02-00-00-22-22-22-01-01 indicates that two services are available on network 0x00-11-11-11: a Novell Directory Services (NDS) server in TREE1 and the MPR1 router.

SAP information is associated with the network on which the SAP device resides. If an NLSP device does not know a route to a network, the NLSP device will not send SAP information for any services on that network.

BUILDING A RIP ROUTE

If an NLSP device detects a RIP network on one side and an NLSP network on the other side, the NLSP device must send both NLSP information and RIP information. When the NLSP device sends RIP broadcast packets, this device must convert entries from its link state database into information that can be used by RIP devices. To convert the entries, the NLSP device must complete the following tasks:

Attach a Hop Count to an LSP Entry

Each NLSP device uses a decision-making process to determine the best route on a network. If the NLSP device is sending RIP packets, this device determines a hop count for NLSP routes as part of the decision-making process. (An NLSP device uses its knowledge of the network to determine the hop count.) The NLSP device includes this hop count in the RIP and SAP packets sent onto the RIP network.

Attach a Tick Count to an LSP Entry

Determining a tick count is a bit more difficult. Each time an NLSP device receives an LSP packet, the NLSP device automatically determines a tick count based on the NLSP delay and throughput values included in the LSP packet.

The NLSP device uses the following calculation for a LAN:

MAX [ 1, (576 x 8 x 18 / throughput) + (delay x 18 / 1,000,000) ]

For example, a typical throughput value for a 10 Mbit/s Ethernet network would be 10 million, and a typical delay value would be 200. You could use the following calculation to determine the tick count based on these values:

MAX [ 1, (576 x 8 x 18 / 10,000,000) + (200 x 18 / 1,000,000) ]

For this calculation, the tick count is 1. Of course, a network with lower throughput would have a higher tick count, thus ensuring that the best route is based on actual performance.

The NLSP device uses the following calculation for a WAN:

MAX [ 1, (576 x 64 x 18 / throughput) + (2 x delay x 18 / 1,000,000) ]

As with the LAN calculation, you would calculate the tick count and the hop count based on the WAN's throughput value and delay value, which varies according to the speed of the WAN.

FILTERING RIP AND SAP PACKETS

As you may know, you can filter RIP and SAP packets to reduce broadcast traffic on a RIP network. You cannot, however, filter RIP and SAP information on an NLSP network: If an NLSP device detects a RIP network or a SAP service, the device propagates RIP and SAP information through LSP packets.

By default, an NLSP device stops sending RIP and SAP information on a link after the device quits receiving RIP and SAP information from other devices. The NLSP device simply waits until the RIP and SAP Xroute entries have timed out of the link state database and then sets the RIP and SAP state to Off. (The state is the mode in which a router is currently operating.)

If the RIP and SAP state is set to On, the NLSP device is a RIP/SAP-only router. If the RIP and SAP state is set to Off, the device is an NLSP-only router. If the RIP and SAP state is set to Auto, the NLSP device sends RIP and SAP broadcasts to provide backward compatibility with any RIP and SAP devices that might appear on the network. You can manually stop an NLSP device from sending RIP and SAP packets by changing the device's RIP and SAP state to Off.

CONCLUSION

Because NLSP devices automatically recognize and participate in the exchange of RIP and SAP information, you can slowly migrate your company's network to NLSP. For more information about migrating from RIP and SAP to NLSP, see "Novell's Guide to NLSP Migration," which is included in the NetWare 4.11 Communications section in the IntranetWare and NetWare 4.11 documentation.

Understanding how NLSP works with RIP and SAP can help you troubleshoot and optimize your company's network. As always, I strongly recommend that you purchase a network analyzer, which shows you what's happening on the network.

Laura Chappell researches, writes, and lectures on TCP/IP and IPX/SPX protocol performance, troubleshooting, and optimization. She speaks at NetWare Conferences and presents customized training courses on network analysis. You can reach Laura at lchappell@imagitech.com.

NetWare Connection, November 1997, pp. 36-39