Novell networking adheres to a client-server model in almost all cases. Therefore, servers are strictly servers and clients are resources that use the services provided by servers. This differs from AppleTalk and Microsoft peer-to-peer networking, where clients can be servers as well.

Note that the GNS request is a broadcast and is not forwarded by a router. Although this might lead an administrator to believe that an IPX server must be installed on each network segment, such is not the case. IPX places a GNS listener on each IPX network. The router also contains a SAP table and responds as necessary to GNS requests.

	Cisco routers do not respond to a GNS request if a NetWare server is on the segment with current versions of the IOS.

Figure 6.2 provides a visual representation of the GNS process in an IPX network where the server is separated from the client by a router. The first two transmissions from the client are broadcasts, whereas the responses are unicasts. NCP is a connection-oriented protocol that is used for primary Novell functions. Once the client and server establish an NCP session, the client proceeds to the login phase. At this point, the designer may be involved to address slow login issues.

FIGURE 6.2  The Novell connection sequence with a remote server

Designing Networks with NLSP

Most distance-vector routing protocols are inefficient when compared to link-state routing protocols. These inefficiencies include high bandwidth utilization, slow convergence, and limited route calculations. Link-state protocols improve upon distance-vector protocols; however, they typically consume substantial amounts of processor and memory resources.

In order to improve the scalability of the IPX protocol, Novell developed NLSP, or the NetWare Link Services Protocol. NLSP is an open standard that greatly improves upon the limitations found in IPX RIP. These benefits include faster convergence, lower bandwidth consumption, and a greater network diameter.

	Networks that use both IPX RIP and NLSP are limited to the 15-hop diameter imposed by IPX RIP. It is possible to adjust the hop count during redistribution; however, this can be confusing in a troubleshooting scenario and should only be used with clear documentation and training.

Unlike IPX EIGRP, NLSP is available on servers, which can permit its use on populated segments. This factor can facilitate migration to an all-NLSP network, which would allow for a greater network diameter.

In addition, NLSP supports route aggregation, a service not supported by IPX EIGRP or IPX RIP. This option can greatly reduce the size of the IPX routing table.

Network architects should limit the number of routing nodes per NLSP area when designing their networks. The recommended limit is approximately 400 nodes; however, a more accurate impact definition may be found with the formula n*log(n).

NLSP is also best deployed with each area contained in a geographic region—a single campus, for example. Large, international IPX networks should not place all routers in a single area.

Incorporating NLSP into a network design is made easier by the automatic redistribution mechanism on Cisco routers. Routers running both IPX RIP and NLSP will automatically learn of the other process’s routes, and the implementation will automatically limit the likelihood of routing loops. Note that this may lead to suboptimal routing, and designers should verify the routing table following implementation to confirm that the paths selected are, in fact, the most desirable.

Some administrators are leery of deploying NLSP because they believe that readdressing will be required. Readdressing is necessary only to create logical areas for summarization. If the network resides in a single area, readdressing will not be required.

This leads to a design consideration for new networks, of course. Designers should strive to create logical addressing schemes even when not designing for NLSP, for two reasons. First, a logical addressing scheme will greatly assist in address assignments and troubleshooting. Second, the use of logical addressing will avail route summarization options in the future should the network expand beyond the initially conceived boundaries.

Consider a network design where slow frame-relay links are used for the WAN. The designer would likely select NLSP over IPX RIP and IPX EIGRP for the following reasons:

•  NLSP uses little bandwidth.

•  NLSP can be configured for fault tolerance.

•  NLSP is based on standards.

•  NLSP is based on updates.

•  NLSP can perform route summarization.

Typically, in link-state protocols a full-mesh topology is required. This would reduce the desirability of using NLSP, as the costs associated with the network would increase—additional PVCs (permanent virtual circuits) would be required to maintain the full mesh. This is not a fault of NLSP, but rather an outcome of the full-mesh requirement. In NLSP, the designated router creates a pseudonode, which is responsible for reporting the adjacencies to all other routers. Because of this, the number of PVCs in a five-router Frame Relay configuration can be reduced to four, as opposed to the ten that would be required with a full mesh. Note the formulas to calculate this:

•  Full-Mesh Topology = n*(n–1)/2

•  Partial-Mesh Topology = n–1

N is equal to the number of routers in the network. These formulas dis-count redundant links and other considerations.

Figures 6.3 and 6.4 illustrate the use of NLSP and the summarization of addresses within NLSP areas.

FIGURE 6.3  NLSP areas

FIGURE 6.4  IPX addressing and summarization within NLSP areas

Designing Networks with IPX EIGRP

In order to augment support for the IPX protocol, Cisco developed a version of EIGRP to replace IPX RIP on WAN links and other transit media. IPX EIGRP is very similar to IP EIGRP in that the AS number must be the same on all routers in the autonomous system. This differs, as you may recall, from AppleTalk EIGRP, which uses different AS numbers on each router.

This chapter will later present the use of access lists to block SAP traffic from different portions of the network. However, one benefit of IPX EIGRP is that it can replace the normal SAP distribution method and control broadcasts so that they are transmitted only when there is a change in the SAP table. This can greatly conserve bandwidth on slower WAN links. Unfortunately, this may not resolve all of the designer’s issues with SAP traffic in the network, as the size of the SAP table to be calculated and propagated throughout the network remains the same.