Novell IPX


Novell IPX (Internetwork Packet Exchange) has been in use since its release in the early 1980s. It’s similar to XNS (Xerox Network Systems), developed by Xerox at its Palo Alto Research Center in the 1960s; IPX even shares a likeness with TCP/IP. IPX is really a family of protocols that coexist and interact to empower sound network communications.

Novell IPX Protocol Suite

IPX doesn’t map directly to the OSI model, but its protocols still function in layers. When designing IPX, engineers were more concerned with performance than with strict compliance to existing standards or models. Even so, comparisons can be made.

Figure 3.6 illustrates the IPX protocols, layers, and functions relative to those of the OSI model.

click to expand
Figure 3.6: IPX protocol suite and the OSI model

IPX

IPX performs functions at Layers 3 and 4 of the OSI model. It controls the assignment of IPX addresses (software addresses) on individual nodes, governs packet delivery across internetworks, and makes routing decisions based on information provided by the routing protocols, RIP or NLSP. IPX is a connectionless protocol (similar to TCP/IP’s UDP), so it doesn’t require any acknowledgment that packets were received from the destination node. To communicate with the upper layer protocols, IPX uses sockets. These are similar to TCP/IP ports in that they are used to address multiple, independent applications running on the same machine.

SPX

SPX (Sequence Packet Exchange) adds connection-oriented communications to the otherwise connectionless IPX. Through it, upper layer protocols can ensure data delivery between source and destination nodes. SPX works by creating virtual circuits or connections between machines, with each connection having a specific connection ID included in the SPX header.

RIP

RIP (Routing Information Protocol) is a distance-vector routing protocol used to discover IPX routes through internetworks. It employs ticks (1/18 of a second) and hop count (number of routers between nodes) as metrics for determining preferred routes.

SAP

SAP (Service Advertising Protocol) is used to advertise and request services. Servers use SAP to advertise the services they offer, and clients use it to locate network services.

NLSP

NLSP (NetWare Link Services Protocol) is an advanced link-state routing protocol developed by Novell. It is intended to replace both RIP and SAP.

NCP

NCP (NetWare Core Protocol) provides clients with access to server resources; functions such as file access, printing, synchronization, and security are all handled by NCP.

What does the presence of routing protocols, connection and connectionless transport protocols, and application protocols indicate to you? All of those factors add up to the fact that IPX is capable of supporting large internetworks running many applications. Understanding how Novell uses these protocols clears the way for you to include third-party devices (such as Cisco routers) into an IPX network.

Client/Server Communication

Novell NetWare follows a strict client/server model (there’s no overlap): a NetWare node is either a client or a server, and that is that. You won’t find peer machines that both provide and consume network resources here. Clients can be workstations running MacOS, DOS, Windows, OS/2, UNIX, or VMS. Servers generally run Novell NetWare. NetWare servers provide the following services to clients:

  • file

  • print

  • message

  • application

  • database

As you would think, NetWare clients depend on servers to locate all network resources. Every NetWare server builds a SAP table composed of all the network resources that it’s aware of. (We’ll explain how they do this a bit later in this chapter.) When clients require access to a certain resource, they issue an IPX broadcast called a GNS (Get Nearest Server) request so they can locate a NetWare server that provides the particular resource the client needs. In turn, the servers receiving the GNS check their SAP tables to locate a NetWare server that matches the specific request, then respond to the client with another GNS response. The GNS response points the client to a specific server to contact for the resource it requested. If none of the servers hearing the client’s GNS request have the requested service or know of a server that does in their SAP tables, they simply don’t respond, leaving the requesting client without the ability to access the requested resource.

Why do you care? Because Cisco routers build SAP tables, too, and they can respond to client GNS requests just as if they were NetWare servers. This doesn’t mean they offer the services that NetWare servers do, just that their responses are identical when it comes to locating services. The GNS response to a client can come from a local NetWare server or from a Cisco router, and generally, if there are local NetWare servers present, they should respond to the client’s request. But if there are no local NetWare servers, the local Cisco router that connects the client’s segment to the IPX internetwork can respond to the client’s GNS request. This saves the client from having to wait for remote NetWare servers to respond. A second advantage of this arrangement is that precious WAN bandwidth isn’t occupied with GNS conversations between clients on a segment with no local NetWare server and remote NetWare servers, as shown in Figure 3.7.

click to expand
Figure 3.7: Remote IPX clients on a serverless network

In this figure you see client workstations at the remote office site: they require access to server resources at the main office. In this situation, RouterA answers client GNS requests from its SAP table rather than forwarding the request across the WAN to the main office servers. The clients never realize or care that there isn’t a NetWare server present on their LAN.

This communication insulates the client from the task of locating and tracking available network resources—it places that burden on the server instead. The client simply broadcasts a GNS and waits for a response. From the client’s perspective, all network resources respond as though they were local, regardless of their physical location in the internetwork.

Server-Server Communication

Communications between two NetWare servers are a bit more complicated than client/server communications. As mentioned earlier, servers are responsible for maintaining tables of all available network resources, regardless of whether those resources are local to the server. Plus, keep in mind that each server must be able to locate any resource on the internetwork.

Servers exchange two types of information using two separate protocols: SAP and RIP. As their names suggest, SAP communicates service information, and RIP communicates routing information.

NetWare servers use SAP to advertise the services they offer by sending out a SAP broadcast every 60 seconds. The broadcast includes all services that the server has learned about from other servers—not just the ones they furnish. All servers receiving the SAP broadcast incorporate the information into their own SAP tables; they then rebroadcast it in their own SAP updates. Because SAP information is shared among all servers, all servers eventually become aware of all available services and are thereby equipped to respond to client GNS requests. As new services are introduced, they’re added to SAP tables on local servers, then rebroadcast until every server knows they exist and where to get them.

So how does a Cisco router fit in here? Well, as far as SAP is concerned, that router acts just like another NetWare server. By default, a SAP broadcast won’t cross a Cisco router. A Cisco router catalogs all SAPs heard on any of its IPX-enabled interfaces in its SAP table; it then broadcasts the whole table from each of those interfaces at 60-second intervals just as NetWare servers do, unless you change the settings. This is an important point, especially with WAN links. The router isolates SAP broadcasts to individual segments and passes along only the summarized information to each segment.

RIP information is exchanged between servers much the same way that SAP information is. Servers build routing tables that contain entries for the networks they’re directly connected to; then they broadcast this information on to all IPX-enabled interfaces. Other servers on those segments receive those updates and broadcast their RIP tables on their IPX interfaces. Just as SAP information travels from server to server until all servers are enlightened, RIP information is proliferated until all servers and routers know of the internetwork’s routes. RIP information is also broadcast at 60-second intervals, as is SAP information.

IPX Addressing

After you’ve struggled through IP addressing, IPX addressing should seem like a day at the beach. The IPX addressing scheme has several features that make it much easier to understand and administer than the TCP/IP scheme.

IPX addresses use 80 bits (10 bytes) of data. As with TCP/IP addresses, IPX addresses are hierarchical and divided into a network and a node portion. The first four bytes always represent the network address, and the last six bytes always represent the node address. There’s none of that Class A, Class B, or Class C TCP/IP stuff in IPX addressing—the network and node portions of the address are always the same length. So after subnet masking, this is sweet indeed!

As with IP network addresses, the network portion of the address is assigned by administrators and must be unique on the entire IPX internetwork. Node addresses are automatically assigned to every node. When an IPX node powers up, it gets the network address from a router and then attaches that to the front of the MAC (hardware) address that comes from the NIC installed in the node. A NetWare server can also give the network address to a node, but a NetWare server can also be called a router.

This offers several notable advantages over TCP/IP addressing. Since client addressing is dynamic (automatic), you don’t have to run Dynamic Host Configuration Protocol (DHCP) or manually configure each individual workstation with an IPX address. Also, since the hardware address (Layer 2) is included as part of the software address (Layer 3), there’s no need for a TCP/IP ARP equivalent in IPX.

As with TCP/IP addresses, IPX addresses can be written in several formats. Most often, they’re written in hexadecimal, such as 00007C80.0000.8609.33E9. The first 8 hexadecimal digits (00007C80) represent the network portion of the address; the remaining 12 hexadecimal digits (0000.8609.33E9) represent the node portion and are the MAC address of the workstation. When referring to the IPX network, it’s a common IPX custom to drop leading 0s. This done, the preceding network address would be referred to as IPX network 7C80. The node portion is commonly divided into three sections of four hexadecimal digits divided by periods, as in this example.




CCDA. Cisco Certified Design Associate Study Guide
CCDA: Cisco Certified Design Associate Study Guide, 2nd Edition (640-861)
ISBN: 0782142001
EAN: 2147483647
Year: 2002
Pages: 201

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net