Cisco strongly recommends the use of IPX EIGRP when constructing scalable IPX networks.

	The tick count is not incremented when converting from IPX RIP to IPX EIGRP. The hop count is incremented at each conversion; thus, two hops are added when going from IPX RIP to IPX EIGRP and on to another IPX RIP segment.

Designing for NetBIOS over IPX

Networks that rely on NetBIOS typically include those platforms that grew out of the LAN Manager environment. These include OS/2 and Windows. NetBIOS was originally developed to operate over the LLC2 protocol, or NetBEUI. This was an excellent solution for small, non-routed networks and afforded the administrator an easy-to-install-and-maintain environment. Unfortunately, small non-routed networks cannot support the large user populations typically needed in today’s environments.

One of the NetBIOS negatives is its reliance on broadcasts. Given its original design for small, non-routed networks, NetBIOS doesn’t scale particularly well. This is also true when the underlying protocol is IPX; however, it is important for designers to consider using IPX when their Novell networks also require NetBIOS. This solution may negate the need for IP or NetBEUI in the network, which facilitates a single-protocol architecture by placing all traffic on IPX.

In order to scale the protocol (increase the number of networks and users), most designers employ NetBIOS name filtering to control the scope of the broadcasts. This is available in both the IPX NetBIOS implementation and the NetBEUI/NetBIOS protocol.

In order to filter on NetBIOS names, the designer must create, in essence, a NetBIOS domain by establishing a naming scheme that is unique to each subnet. For example, the designer would likely prefix all machines in the marketing department with MKT. In so doing, the router can filter those broadcasts from leaving their local domain or from entering domains that would not contain any devices with that prefix. Consider Figure 6.5—there is no reason for the router’s e0 interface to forward NetBIOS requests for devices with MKT* domain names. The same is true for e2 and SLS* domain names.

FIGURE 6.5  NetBIOS name filtering

	While Figure 6.5 shows varying-length prefixes for NetBIOS names, most administrators and designers use a convention that fixes the length at two or three characters. Some designs use geographic considerations for filtering as well.

IPX Type 20

As noted previously, NetBIOS was originally designed around flat networks that would support broadcasts. However, this solution cannot scale beyond a few hundred nodes, which mandated the use of an alternative lower protocol for NetBIOS traffic. In IP, this protocol is defined as NetBT. In Novell IPX it is called NWLink. By encapsulating NetBIOS in a routable protocol, the network can scale to greater dimensions.

Novell IPX can also support NetBIOS broadcasts in otherwise routed designs. This is serviced with the ipx type-20-propagation command. This command instructs the router to forward all NetBIOS broadcasts to all other interfaces. Remember that routers typically drop broadcasts by default, and the ipx type-20-propagation command does not affect those broadcasts.

	The NetBIOS protocol is fundamental to Windows networking. It will be presented in greater detail, as it relates to Windows, in Chapter 7. Please note that Windows 2000 and Active Directory promise to remove the dependency on NetBIOS from the Windows environment.

IPX Access Lists

Cisco routers support filtering based on a number of protocols, including IPX. In the Novell environment, the designer may choose to employ access lists for security or scalability reasons.

One of the most common reasons for deploying IPX access lists concerns the propagation of SAP traffic. These service advertisements can quickly impact overall network performance, especially on slower WAN links. Consider for a moment the SAP traffic generated by servers in Tokyo. While the data center in Sydney may need to receive these updates, it is unlikely that the Chicago office will need access to files and printers in the Tokyo office. By employing SAP filters, the designer can reduce the size of the Chicago office’s SAP table. Administrators should note that input filters will block SAPs from the local table, while output filters will block the transmission of the SAP entry—the local router will remain aware of the advertised service.

IP eXchange Gateway

The IP eXchange gateway product, now owned by Cisco, was designed to provide access to the Internet and other IP-based resources without installing an IP stack on every client workstation in the Novell environment.

Unfortunately, the simplified workstation administration was offset by the slower performance of gateway translation and the installation of client software for the IP eXchange product. In addition, a server running either Novell or Windows NT was required for the translation, which introduced a single point of failure and added administration.

One of the beneficial features of the IP eXchange gateway was its use of a single IP address to service all the clients in the network. This greatly simplified troubleshooting and administration.

Figure 6.6 illustrates the connectivity between devices in the IP eXchange environment.

FIGURE 6.6  The IP eXchange IPX-to-IP gateway product

IPX Watchdog Spoof and SPX Spoofing

In Novell networking, the IPX server will transmit an IPX watchdog packet in order to verify that the client is still available. This process is used to clear connections to the server that were terminated incorrectly.

Unfortunately, this transmission can cause DDR (dial-on-demand routing) connections to activate. Many designers have forgotten or ignored this function in Novell networks and been surprised when the first telecommunications bill arrived. IPX watchdog packets are sent at five-minute intervals.

Fortunately, Cisco has developed a service to permit the use of IPX watchdog packets in DDR installations. The IPX watchdog spoof process will effectively proxy for the remote client and permit the router to acknowledge the watchdog packet from the server. This function prevents the DDR circuit from activating, so the server believes that it is still connected to the remote workstation.

SPX spoofing is another useful service in DDR environments. This service operates at the remote end of the DDR connection and acknowledges SPX keepalives transmitted by the client. This may be for an rconsole (a remote administration tool for Novell servers) session or connectivity to an SAA (Novell SNA or Systems Network Architecture) gateway. The use of SPX spoofing prevents the router from activating the circuit, which usually reduces costs in the DDR environment.