IPX Frame Types

When Novell first released the IPX protocol, it included a specification for the two octets that immediately followed the source MAC address in the LAN frame. In the proprietary Novell Ethernet specification, this incorporated a length field immediately followed by the data (unlike the IEEE standard, which specified a length field followed by an LLC, or Logical Link Control, header). However, as standards evolved and multiprotocol and multitopology support was required, numerous frame encapsulations for IPX were ratified. These are defined in Table 6.5.

It is important to note that each frame type is a separate network in IPX. This is true for multiple physical media running the same encapsulation or for multiple encapsulations on a single physical media.

Connecting Same-Interface Frame Types

There may be design requirements that mandate temporary support for multiple IPX frame types on the same media. This is frequently the case when migrating from one encapsulation to another. Older software programs may also require a specific encapsulation, necessitating the use of multiple frame types. Fortunately, few programmers would consider writing an application “down the stack” today, which negates this concern for most administrators.

When configuring to support multiple frame types, designers must keep in mind that all traffic destined for the other network on the wire must traverse the router. This is called local router, even when using subinterfaces. In this configuration, all broadcast traffic on the wire is doubled. Ideally, networks should be designed to use multiple frame types on the same segment as seldom as possible. Figure 6.1 illustrates the multiple frame-type installation.

FIGURE 6.1  Multiple frame types on an interface

The administrator and designer can take a couple of steps to improve performance under multiple frame-type configurations: First, the command ipx route-cache same-interface will enable faster processing of packets between networks on the same local wire. Second, installations of Windows 95/98/NT should be configured for the specific frame type in use on the segment. The setting of auto, which is the default, can occasionally cause problems and loss of connectivity, and it may also generate additional network traffic. This is the result of a station requiring a router to transmit to another station running a different automatic frame type— depending on the software, auto may select the first or select all heard frame types, which can result in four packets being transmitted where one was necessary.

IPX Get Nearest Server

The Get Nearest Server (GNS) process provides a mechanism for clients to locate a server. The server will then provide the necessary information to the client so that the login and authentication process may continue.

Designers should be familiar with the overall GNS process and how these datagrams may affect users on the network. It is important not only to understand the process, but also to consider what impact the user might experience if the server is located on the remote end of a slow WAN link. There are instances when it is not appropriate to place servers in every remote location, but performance—specifically login performance—will likely suffer.

The GNS request is specified as part of the Service Advertising Protocol (SAP). GNS is a broadcast datagram that is answered by any IPX server on the network. If there are multiple servers on a network segment, the client receives a response from each one and accepts the first one for the rest of the initialization process. Note that the first server may not be the preferred server listed in the client’s configuration file. When configured for a preferred server, the client will wait to hear from that server until a timeout occurs, and the next available server will be used. An example of the GNS broadcast, which is captured with an EtherPeek analyzer, follows. In this example, the workstation’s MAC address is 00:60:08:9e:2e:44, and the first packet is the client’s GNS request.