SAP and GNS

To connect to a local Novell server, a client must be able to locate the server. The Get Nearest Server (GNS) protocol and the Service Advertising Protocol (SAP) are used to handle this task. Novell NetWare clients use GNS to request information on the nearest active server of a given type. GNS uses broadcasts that are answered by all IPX servers on the network, accepting the first broadcast for the initialization process. The first server that responds is not always the preferred server identified in the client's configuration file.

Novell clients can't also be a server. A server is a server, and a client uses resources from the server. IPX assigns a GNS listener to each IPX network. The router contains an SAP table that can respond to a GNS request. Both routers and servers can reply to a GNS request. GNS request broadcasts are not forwarded by a router, and a Cisco router will not respond to a GNS request if a NetWare server is on the segment.

If the router must respond to a GNS request because a server is on another segment, a client will request routing information from the router. The router will provide this information to the client to establish a direct connection to the server. IPX Routing Information Protocol (IPX RIP) is a dynamic routing protocol used with Novell NetWare to locate networks and devices in the internetwork. This protocol uses a hop count as a routing metric.

The following are the steps used to resolve a GNS request when the server resides on another segment and a router must handle the request:

1. The Novell client sends a GNS request.

2. No server resides on the segment, so the router responds with a GNS reply.

3. The client responds with an IPX RIP request to get the routing information to the server.

4. The client sends a NetWare Control Protocol ( NCP ) request, which is a connection-oriented protocol used for primary Novell functions. After the client and server establish an NCP session, the client proceeds to the login phase after an IPX NCP reply.

Understanding SAP

By default, every 60 seconds, NetWare servers use SAP to advertise their services to other servers and routers. SAP is a protocol used in Novell NetWare to notify network clients of available resources in the network. It's through these advertisements that Novell clients find the servers that they need. The nearest server needs to have an entry in its SAP table for that resource. Unless the router has a security policy using access lists, all the servers and routers become aware of all the NetWare resources in the internetwork. This enables any client to obtain the network topology information from any server in the network.

All the services that are learned from SAP are entered into the server's or router's topology tables. These tables summarize a list of where resources reside in the network. This information is then re-sent out to each interface on the router or server to help inform all the other routers and servers in the network of the existence of other resources. If a problem arises when forwarding or storing the SAP table on any server or router, the problem can cause services to become unavailable. If a new service is introduced, it is automatically broadcast and added to local SAP tables and added to new SAP advertisements to populate the other servers' and routers' SAP tables.

Troubleshooting SAP

Troubleshooting SAP is not that difficult if you make a small checklist of the most common issues. You can narrow down the source of an SAP- related problem by doing the following:

• Check the frame types and the client configuration. This includes checking the frame type and hardware settings (including the IRQ [interrupt request] and DMA [Direct Memory Access] settings). This check also involves making sure the client has the proper drivers for the NIC and physical connectivity to the network. All the network servers and routers need to have their external IPX network numbers set to the same value.

  

  A good indicator of a misconfigured network number is an error that is similar to "00:50:60:2A:94:AD claims network 200 should be 300."

  
  

• Check the local Cisco router configuration. This includes checking the configured network numbers especially for duplicates, encapsulation type, access lists, frame types, and SAP table sizes.

  

  The NetWare servers, routers, and clients on the same physical cable segments using a common frame type must share the same network address. All devices on a common network must also use the same frame type.

  
  

• Check for non-IPX protocolrelated problems. This includes overloaded segments, down links, processor overloads on the routers, IP configuration, and AppleTalk issues.

• Check for incorrectly set timers.

Managing IPX and SAP on Virtual Circuits

A NetWare file server and other network resources can be located on a remote segment of the network. You can also configure the routers to dial a server remotely over a switched virtual connection ( SVC ) or a permanent virtual connection ( PVC ) connecting across a WAN link.

When setting up an SVC connection (which is an interface that is set to dial only when traffic is present), remember to turn off IPX RIP routing or the connection will not terminate, because the routing updates will keep the link active. (IPX RIP is discussed in detail in the next section of this chapter.)

A PVC is a permanent, always-on communication connection. As an IPX network begins to grow, the sheer volume of IPX RIP traffic and SAP traffic also grows. Eventually, a WAN connection will be overwhelmed with RIP and SAP updates where data cannot be sent successfully over the links without high latency. In some medium to large networks, a T1 line can easily be saturated , causing difficulty sending RIP messages, SAP messages, and data. That saturation occurs even without including any other protocols, such as IP and AppleTalk, that may be running in the network.

Always remember that very few networks in existence today have only Novell NetWare's IPX protocol running on them.

In an SVC where the router must dial when data traffic is queued to be sent, the router must respond when a server is not present. The time it takes a router to dial and make a connection may cause GNS queries sent by a client to fail due to timeouts or other unforeseen issues. In these situations, you can use debugging commands to find the problem, but use them with cautionand don't rely on them. The debugging commands can actually cause a timeout issue, because the commands are given a high priority on the processor and are processor- intensive .

The ipx gns-round- robin command provides a form of load balancing between the servers, making sure no one server is overburdened with data traffic. This command can be helpful for the router when the servers are overloaded. This command can be used if multiple servers are an equal distance from the router. Although such a problem is rare, you can use another command to set a delay if a problem occurs in the network whereby the router responds to a client more quickly than the client can handle a return request. The default delay is 0 milliseconds (ms), but this can be changed by using the ipx gns-response-delay command.

If your network consists of just a few locations connected by three routers using T1 WAN lines, and not too many servers, RIP and SAP can probably run successfully in your network. The reason is that SAP and RIP broadcast everything that they know every 60 seconds throughout the network. In a small network, SAP and RIP tables are pretty small and don't use up a lot of bandwidth. But imagine that you manage a network that has 100 servers and 50 locations. This may sound far- fetched to some, but chances are good that if you're administering a Novell network, it is going to be at least this size.

Now, imagine that SAP updates advertising all of those servers are crossing your WAN connections every 60 seconds. You probably realize that you might need to implement some flow control or buffering, or perhaps you need a lot more than that. You have to leave some bandwidth for data traffic, too.

In this situation you might have a very lengthy convergence time, the amount of time required to update IPX network addresses and services in a router's SAP tables if a link or server problem exists in the network. If you are using IPX RIP, the convergence time compared to newer more efficient routing protocols is a lot longer. IPX RIP doesn't notify other servers and routers until it is time for their regularly scheduled 60 second spaced broadcast. If you have more than one hop (you can have up to 15 with RIP), you can add up to an extra minute to that convergence time per hop.

IPX RIP and SAP just don't scale well in larger networks. Even if nothing else but the convergence time or redundancy is important to you, you should consider IPX Enhanced Interior Gateway Routing Protocol (EIGRP) and NetWare Link State Protocol (NLSP), discussed in later sections of this chapter.

Configuring IPX RIP

Configuring IPX RIP is rather simple. Use the ipx router rip command at the global configuration prompt and identify the network numbers running in the network. The following is an example of configuring IPX RIP:

 DCS2514(config)#  ipx router rip  DCS2514(config-ipx-router)#  network 100  DCS2514(config-ipx-router)#  network 200  DCS2514(config-ipx-router)#  network 300  DCS2514(config-ipx-router)#^  Z  DCS2514#