Internetwork Packet Exchange (IPX) is a Layer 3 protocol that forms the basis for Novell's network operating system (NOS) called NetWare. IPX was developed from the earlier Xerox Network System (XNS). Today, it is used almost exclusively to support networks of Novell NetWare servers. It is primarily used for file and printer sharing, but the capabilities are broader. IPX is able to carry a large variety of applications.
Unfortunately, some of the terminology adopted by Novell is different from that used in IP networks. For example, Novell calls every device that provides IPX services a router. This term can cause some confusion. Thus, in this book, I continue with the already adopted language. I call a device that provides application services a server. In this book, a router is a device that primarily performs Layer 3 network functions. As always, I strongly caution the reader against using general-purpose application servers to perform network functions such as bridging and routing.
Just running applications creates a lot of work for application servers. At peak utilization times, they frequently are unable to perform their network functions as well. Therefore, when the network is needed the most, it is unavailable for all applications, not just the ones served by this device. I mention this fact specifically in the context of IPX because Novell servers are frequently configured to either bridge or route—a situation I do not recommend.
Every device in an IPX network has a globally unique address. This address is divided into two parts. A 32-bit address called the network number defines on which segment the device lives and the 48-bit node number defines the specification on the segment. Usually, the node number is identical to the device's MAC address.
The network number is similar to IP, which also uses 32-bit addresses, but IPX does not use the same notation for its addresses. While IP shows the four octets of the address as separate decimal numbers separated by dots, IPX network and node numbers are usually written in hexadecimal format. Furthermore, in most cases, leading "0" digits from the IPX network number are dropped when the address is written. For example, a network might include the network number A1A. This number means that its address is really 00000A1A. The first and second octets of the address are both 00. The third octet has a value of 0A (10 in decimal) and the last has the value 1A (26 in decimal).
Another difference from IP is the absence of a subnet mask. The whole network number refers to a particular network. This reference causes confusion in networks that have more than one server on a LAN segment. To get around this problem, every Novell server also has an internal network number. This internal number need not have a relationship to the network number of the segment.
As I discuss later in this section, if the network uses Novell Link State Protocol (NLSP) areas, it is more efficient to allocate all addresses in blocks. This allocation includes both the LAN network numbers and these internal network numbers.
The services associated with any particular server are generally associated with the internal network number. The server acts like a router that connects the external LAN segment address to this internal network number that, in turn, represents the unique server.
One of the most important issues to remember when building an IPX network is that these IPX network numbers are not administered rigorously. Novell does offer a service called the Novell Network Registry that allocates and tracks IPX network numbers. This allocation and tracking permits different organizations to interconnect their IPX networks without worrying about address conflicts. However, participation in the Novell Network Registry is optional. Thus, merging two IPX networks together can be extremely challenging.
When merging occurs, it is quite common to find that both IPX network numbers and server names appear in both networks. The only solution to this problem is to adopt a single common standard for naming and addressing servers and IPX networks. However, this standard can take a long time to implement, and corporate priorities may make it necessary to merge the networks quickly.
There is a convenient way around this problem. Usually, in such situations just a few servers actually need to be simultaneously accessible to both networks. These few servers can then be readdressed and renamed according to the new common standard. You can then build a simple IPX routing firewall between the two networks by using a pair of routers with a LAN segment between them. One router connects this common segment to the first network and the other connects to the second network.
You can then implement Access lists on the exchange of IPX routing and service information (I discuss these protocols shortly). The two routers prevent those network numbers and server names that are in conflict from entering this common segment. Then, as IPX names and addresses are migrated to the new standard, the new addresses pass through the routing firewall setup. In this way, one can gradually migrate the entire networks to a common addressing scheme. When it is complete, the firewall connection can be replaced by a common LAN infrastructure.
There are three reasons for deploying two routers with a common segment (rather than a single router) between them. First, much greater control is possible over the routing Access lists because the first can see all of the first network's routes and services and only pick and choose those that will be permitted to pass to the second network. Second, this sort of filtering can be rather CPU- and memory-intensive in a large network. Splitting the task between two routers helps ensure stability. Third, it might become necessary to implement one or more servers on this intermediate segment. For example, if both networks use IPX for their email services, then the network designer can implement an email relay server on this intermediate segment. Since this LAN segment is visible to both sides, it is also a natural place to put central file servers or servers that download common information to remote user servers.
IPX itself is a connectionless protocol and similar in concept to IP. Programmers can build connectionless applications to run over IP using UDP. For applications that require connections, with the network protocol ensuring that all of the packets arrive intact and in order, an IP programmer would instead use TCP.
IPX also has a connection-based transport layer called Sequenced Packet Exchange (SPX). Like UDP and TCP, SPX includes the concept of well-known port numbers to ensure that a server knows to which application to connect the session.