Novell is now a part of Micro Focus

NetWare Communications Processes

Articles and Tips: article

Paul Turner
Consultant
Systems Engineering Division

01 Sep 1990


This AppNote provides a comprehensive explanation of the protocols and algorithms that govern communications in the 286- based NetWare, NetWare 386, and Portable NetWare environments. Topics covered include routing and connection control.

Introduction

This AppNote is a preliminary excerpt from an upcoming Novell Systems Engineering Division research report entitled "NetWare Internals and Structure." It provides a technical description of the protocols that make client-server communications possible on NetWare networks. The information contained in this document will be most valuable to those individuals designing, implementing or administrating large NetWare internetworks. It will also be useful to individuals and organizations developing applications specifically for NetWare.

The document begins with an explanation of the packet structures defined by each protocol. If then describes the algorithms followed by workstations, routers and file servers when transmitting or receiving packets.

Protocols

Most computer networks require that information transferred between two nodes be broken up into blocks, called packets. This packetizing makes the information more manageable for the sending and receiving nodes, and any intermediate nodes (bridge or routers). In addition to the information, or data, that is being transferred, each packet contains control information used for error checking, addressing, and other purposes. The protocols being used on the network define the content of this control information. In most cases multiple protocols exist within a packet and the control information for each protocol serves a different purpose. When multiple protocols are used, the control information for the highest level protocol is first placed around the data, then the control information for each subsequent protocol in the protocol stack is added to the beginning and/or end of the packet. This is called enveloping. (See Figure 1.)

The enveloping pattern illustrated in Figure 1 is common in the computer communications industry but the tasks assigned to each protocol in the packet differs for different vendor's implementations. In an effort to standardize the definition of protocols--and therefore make the networking implementations of different vendors interoperable--several standards organizations have been formed by governments and corporations. One of these, the International Standards Organization (ISO), has developed a model, called the Open Systems Interconnection (OSI) model, that specifies how protocols should be defined in the future. The OSI model separates the functions required for effective computer communications (such as error checking and addressing) into seven categories, or layers. These layers are the Application, Presentation, Session, Transport, Network, Data-Link and Physical layers.

Figure 1: Example of Multiple Protocols in a Packet.

Having been defined prior to the finalization of the OSI model, the protocols used by NetWare do not all correspond exactly to the OSI model's definitions. NetWare uses a variety of protocols. Some of these protocols were developed specifically for NetWare; some are used throughout the networking industry. The protocols required for communications between NetWare workstations and file servers are the following:

  • Medium-access Protocols

  • Internetwork Packet Exchange (IPX)

  • Routing Information Protocol (RIP)

  • Service Advertising Protocol (SAP)

  • NetWare Core Protocol (NCP)

Figure 2 provides a relative mapping of the NetWare protocols-- also called the NetWare protocol stack--to the OSI model; in actuality, a direct correlation to the layer boundaries of the two architectures does not exist. The NetWare protocols follow the enveloping patern shown in Figure 1. More specifically, the upper level protocols (NCP, SAP, and RIP) are enveloped by the IPX and IPX is subsequently enveloped by the medium-access protocol header and trailer.

Figure 2: Mapping of NetWare Protocols to OSI Model .

Medium-Access Protocol Implementations

A number of medium-access protocols have been defined, many of which are used with NetWare. The focus within this document is on the implementations of medium-access protocols, the most common of which are 802.5 Token-Ring, 802.3 Ethernet, Ethernet v2.0, and Arcnet. The 802.x protocols have been defined by the Institute of Electrical and Electronic Engineers (IEEE). Ethernet v2.0 was co-developed by Xerox and Digital Equipment Corporation, and Arcnet was developed by Datapoint, Inc. These medium-access protocol implementations are primarily concerned with the transport of packets from one node to another on a single network segment.

Medium-access protocols provide bit-level error checking in the form of a cyclic redundancy check (CRC). This CRC, which is appended to every packet that is transmitted, assures that 99.9999 percent of the packets successfully received will be free of corruption. In view of this level of integrity, NetWare does not provide any additional bit-level error checking within any of its upper-level protocols. (Note that bit-level error checking checks to make sure that bits within a packet have not been corrupted. The packet-level error checking discussed later checks that complete packets are not lost.)

Medium-access protocol implementations define the addressing that distinguishes each mode on a NetWare network. This addressing is implemented within the hardware of each network interface card (NIC). To move a packet to the proper node on a network, a medium-access control (MAC) header is placed at the beginning of every packet. This header contains source and destination node address fields to indicate where the packet originated and where it is going. Each NIC checks the destination address in the MAC header of each packet sent on the network segment it is attached to. If the destination address matches the NIC's own address, or if the packet is a broadcast packet intended for all nodes, the NIC will copy the packet.

Bit-level error checking and node addressing are provided by the majority of medium-access protocol implementations. IBM's Token- Ring (802.5) implementation defines a method of routing called source routing. Source routing allows ring segments to be interconnected by bridges, allowing administrators to segment network traffic. This requries that each workstation maintain a table of routes to the nodes it is communicating with. Furthermore, routing information must be included in the MAC header of each packet it sends. This information instructs bridges how to properly forward each packet to its destination. Source routing can be used instead of or in conjunction with NetWare routing.

Internetwork Packet Exchange (IPX)

The IPX protocol was adopted by Novell from Xerox Network System's (XNS) Internet Datagram Protocol. IPX is a datagram, connectionless protocol that does not require an acknowledgement for each packet sent. This packet acknowledgement, or connection control, must be provided by protocols above IPX. IPX defines internetwork and intranode addressing schemes, while relying on the network hardware for the definition of node addressing.

The network number assigned in NETGEN (NetWare 2.1x) is the basis of IPX's internetwork addressing. Each network segment on a NetWare internetwork must be assigned a unique network number. This network number is used by routers to forward packets to their final destination segment.

The IPX intranode address comes in the form of socket numbers. Since several processes are normally operating within a node, socket numbers provide a sort of mail slot so that each process can distinguish itself to IPX. As a process needs to communicate on the network, it requests that a socket number be assigned to it. Any packets that IPX receives that are addressed to that socket are passed on to the process. Hence, socket numbers provide a quick method of routing packets within a node.

Novell has reserved several socket numbers for specific purposes. These are shown in Figure 3. Since socket numbers are internal to each node, several workstations can use the same socket number at one time without any fear of confusion. All NCP requests from workstations must be addressed to socket 451h.

Figure 3: Socket Numbers Used in The NetWare Environment.

The network, node, and socket addresses for both the desetination and the source are held within the packet's IPX header. The IPX header is placed after the MAC header and before the packet data. (Packet data is usually the header of a higher-level protocol.) Figure 4 illustrates the structure of an IPX packet on an 802.3 network.

Figure 4: Structure of an IPX Packet.

Routing Information Protocol

The Routing Information Protocol (RIP) facilitates the exchange of routing information on a NetWare internetwork. Like IPX, the RIP was derived from the XNS. However, an extra field was added to the packet structure to improve the decision criteria for selecting the fastest route to a destination. This change prohibits the straight integration of NetWare's RIP with other undeviating XNS implementations.

The single packet structure defined by the RIP allows the following exchanges of information:

  • Workstations locate the fastest route to a network number by broadcasting a route request (represented by "Route Request" entry on the TRACK ON screen).

  • Routers request routing information from other routers to update their own internal tables by broadcasting a route request(represented by "Route Request" entry on the TRACK ON screen).

  • Routers respond to route requests from workstations and other routers.

  • Routers perform periodic broadcasts to make sure that all other routers are aware of the internetwork configuration.

  • Routers perform broadcasts whenever they detect a change in the internetwork configuration.

The RIP packet structure is shown in Figure 5. This structure is enveloped within the data area of IPX. The Operation field indicates whether the packet is a request or a response. A 1 in this field indicates a request and a 2 indicates a response. The Operation field can be followed by one or more (I>n) sets of information, each consisting of a network number and the number of Hops and Ticks to that network number. A RIP packet can contain a maximum of 50 sets of network number information.

The term "Hops" refers to the number of routers that must be passed through to reach a network number. A "tick" is roughly 1/18 of a second (there are 18.21 Ticks in a second, to be precise). The number of Ticks measures how much time the packet takes to reach a network number. The number in this field is always at least one. The original XNS definition of the RIP did not include the Number of Ticks field. The Ticks field was added by the developers of NetWare so that the NetWare shell could estimate how long it should wait for a response from a file server. (This will be explained in the discussion of the shell's receive time-out.) Also, if multiple routes exist to a network number, a router uses the route with the shortest number of Ticks when forwarding packets to that network number.

If a RIP packet is a request for information, only the Network Number field applies; the Hops and Ticks fields are essentially nulled out. A response packet can be either a reply to a request from a router or workstation or a periodic broadcast by a router.

Figure 5: RIP Packet Structure.

Service Advertising Protocol (SAP)

The Service Advertising Protocol (SAP) allows service-providing nodes--such as file servers, print servers, and gateway servers- -to advertise their services and addresses. The SAP makes the process of adding and removing services on an internetwork dynamic. As servers are booted up, they advertise their services using the SAP; when they are brought down, they use the SAP to indicate that their services will no longer be available.

Through the SAP, clients on the network can determine what services are available on the network and obtain the internetwork address of the nodes (servers) where they can access those services. This is an important function, since a workstation cannot initiate a session with a file server without first having that server's address.

A gateway server, for instance, will broadcast a SAP packet every 60 seconds (the period defined for all servers advertising with the SAP) onto the network segment it is connected to. The SAP agent in each router on that segment copies the information contained in the SAP packet into an internal table called the Server Information table. Because the SAP agent in each router keeps up-to-date information on available servers, a client wanting to locate the gateway server can access a nearby router for the correct internetwork address.

Like the RIP, the SAP uses IPX and the medium-access protocol for its transport. Figure 6 illustrates the SAP packet structure. The first field defines the operation that the packet is performing. The packet can perform five different operations.

  • A workstation request for the name and address of the nearest server of a certain type (this is represented by a "Get Nearest Server" entry on a TRACK ON screen.)

  • A general request, by a router, for the names and addresses of either all the servers or all the servers of a certain type on the internetwork ("Send All Server Info." on TRACK ON.)

  • A response to either a "Get Nearest Server" request ("Give Nearest Server" entry on TRACK ON) or a general request

  • Periodic broadcasts by servers and routers

  • Changed server information broadcasts

Following the Operation field are one or more sets of fields. Each set includes a service type server name, network address, node address, socket number and a number of Hop fields. If the packet contains information about more than one serer, it will contain more than one set of fields (n sets of fields). Each SAP packet can contain information about up to seven servers.

Figure 6: SAP Packet Structure.

NetWare Core Protocol

The NetWare Core Protocol (NCP) makes interaction between clients and file servers possible by defining two aspects of their interaction, connection control and service request encoding. Because the creation and handling of NCP packets is done by the NetWare shell or NetWare Requester for OS/2, you do not need an in-depth understanding of the NCP, but you should have some idea of what the protocol does.

The NCP provides its own session control and packet-level error checking instead of relying on other protocols for these functions. Consequently, the modularity of the protocol stack is reduced but, in the long run, a more efficient mechanism is attained. Figure 7 shows the general structure of an NCP packet. When a client establishes a session with a file server, it is assigned a connection number. This connection number must be included in all subsequent service requests that the client submits. The connection number allows the file server to keep track of which clients are making requests, for response and security purposes.

Figure 7: Structure of an NCP Packet.

Each NCP request packet submitted on a gaiven connection must be assigned a sequence number by the client. The first request following the establishment of the connection is assigned the number 1; that number is incremented by one for each subsequent request. When a file server finishes processing a request, it places the sequence number for that request in the response packet. Hence, the client can make sure that it is receiving the correct responses for the requests that it submits.

Each of the services available at a NetWare file server has been assigned a number. When it needs to submit a request to a server, the shell or requester places the number--as well as any additional information that might be needed--in the service code field of NCP packet. Depending on the service being requested, the NCP might provide additional fields for the shell to give specific instructions to the file server--such as which part of a file to read. The file server might report any problems or errors that might have occurred while processing the request in these additional fields.

Packet Delivery

On a NetWare network, the successful delivery of a packet depends on the proper addressing of the packet and the internetwork configuration (whether it is a single segment network or series of segments interconnected by repeaters, bridges and/or routers). The addressing of the packet is handled in its medium-access protocol and IPX address fields. To send a packet to another node, the sending node must know the full internetwork address (network, node, and socket) of the node it desire to send to (the destination node). (The process of obtaining another node's address is explained in the section entitled "Establishing a Connection.") Once the sending node has the destination node's address it can proceed with addressing the packet. The way the MAC header of that packet is addressed, however, depends on whether the sending and destination nodes are separated by a router.

In the event that the sending and destination node are on the same network segment--that is, they both have the same IPX network address--the sending node addresses the packet in the following way: The node address of the destination node is placed in the MAC header destination address field. The node address of the sending node is placed in the MAC header source address field. The full internetwork address of the destination node is placled in the IPX header destination addres fields. The full internetwork address of the sending node is placed in the IPX header source address fields.

Figure 8 shows an example of two nodes that are connected to network number AA. The sending node (node 01) sending a packet to node 02. The sending node places node address 02 in the destination field and node address 01 in the source field of the MAC. In the destination address fields of the IPX header, the sending node places AA, 02 and 451 (the full internetwork address of the receiving node). The sending node places its own internetwork address of AA, 01 and 4003 in the source address fields of the IPX header.

Figure 8: Transmission to Same Network Segment (No Routing Required).

Network Interconnection Devices

The addressing method depicted in Figure 8 is used when the two nodes reside on the same physical segment (or ring) or if they reside on separate segments interconnected by repeaters or bridges. A repeater is a Physical Layer (OSI model) device that amplifies the signal of one segment onto one or more other segments. Repeaters are used to extend the maximum possible distance between end nodes on a segment. They are completely transparent to the sending and receiving nodes.

A bridge is a Data-Link Layer device used to interconnect cable segments locally or over wide area network links. Instead of simply amplifying a signal as repeaters do, bridges retransmit packets received on one segment onto another segment. Bridges are considered Data-Link Layer devices because they examine the data-link (or MAC header) portion of packets before retransmitting them onto other segments. There are two predominant types of bridges, transparent bridges and source routing bridges.

Transparent bridges interconnect two or more segments. They examine the MAC header source and destination fields of every packet transmitted on their connected segments. From the source address fields of packets, these bridges develop a table of the nodes that reside on (or are accessible through) each of their connected segments. With this table of information, a bridge can determine whether packets should be passed on to other segments.

Figure 9 shows a transparent bridge connected to two separate segments. After examining the packets transmitted on both segments it creates a table that tracks which nodes exist on each segment. With this table, the bridge can filter unnecessary traffic. For instance, if node 1 sends a packet to node 5, the bridge will not retransmit that packet on its port B. It will, however, retransmit packets sent from node 1 to node 7. Like repeaters, transparent bridges--as their name implies--are transparent to the sending and receiving nodes.

Figure 9: Example Transparent Bridge.

Routers

Routers, like bridges, interconnect different network segments; however, the operation of routers and bridges is quite different. Routers by definition are network layer devices. (See Figure 10.) In other words, routers receive their instructions for forwarding a packet from one segment to another from a network layer protocol. The network layer protocol that routers use in the NetWare environment is IPX. NetWare-compatible routers are available with NetWare or from third-party manufacturers. The routers that come packaged with NetWare have actually been misnamed bridges in the past. The NetWare routers include what has been called the internal bridge within NetWare file servers and external bridge installed at workstations. Novell has officially renamed these two devices internal router and external router.

NetWare-compatible routers may be configured to interconnect two or more segments. Each of these segments, however, must be assigned a unique IPX network number to distinguish it from other segments on the internetwork. A segment's network number must be configured into each of the routers connected to that segment. The network number serves as a common address for each node connected to a segment.

Figure 10: OSI Representations of Network Devices.

Packet Routing

When a node wants to send information to another node, it must first have network address--as well as the node address--of the destination node. If the two nodes have the same network number (reside on the same segment), the sending node can simply send packets to the destination node using method illustrated in Figure 8. On the other hand, if the two nodes have different network numbers (reside on different network segments), the sending node must find a router on its own segment that can forward packes to the destination node's network segment. To find this router, the workstation broadcasts a RIP packet requesting the fastest route to the destination node's network number (RIP requests are discussed in more detail later in the section entitled "Establishing a Connection". This RIP request is responded to by the router residing on the sending nodes segment with the shortest path to the desired segment; in the response, the router includes its node address.

Once the sending node receives the router's node address, it is prepared to send packets to the destination node. The sending node addresses these packets in the following way: It places the destination node's internetwork address (network, node and socket number) in the destination address fields of the IPX header. Next the sending node places its own internetwork address in the source address fields of the IPX header. Then the sending node places the node address of the router--the one that responded to the RIP request--in the destination address field of the MAC header. The sending node places its own node address in the source address field of the MAC header. (See Figure 11.)

Figure 11: Packet Addressing Through a Router.

When a router receives a packet to be routed, it can take one of two possible actions. If the packet is destined for a network number that the router is directly connected to, the router will place the destination node address from the IPX header in the destination address field of the MAC header, place its own node address in the source address field of the MAC header, and transmit the packet. (See Figure 11.)

If the router is not directly connected to the segment that the final destination node resides on, however, it will send the packet to the next router in the path to the destination node. To forward the packet to another router, the router will place the node address of that other router in the destination address field of the MAC header. The router will place its own node address in the source address field of the MAC header. The router leaves the IPX header as intially set by the sending node and sends the packet.

Routing Information Administration

To forward packets by the best possible route, NetWare routers maintain a Routing Information table that holds information about all the network segments on the internetwork. Figure 12 gives an example of a Routing Information table (only the fields pertinent to this discussion have been included). Each entry in the Routing Information table gives the router forwarding information for a network segment.

Figure 12: Portion of Routing Information Table.

The first field contains the network numbers for segments that the router is currently aware exist. The router simply matches the destination network number in the packet's IPX header with an entry in this field to get its forwarding instructions for the packet. The second field indicates the number of routers that must be traversed to reach the network segment.

An estimate of the time necessary to reach the destination segment is recorded in the third field. The initial time setimate for a segment is the responsibility of the driver directly connected to it. This driver reports this estimate to its router. This time estimate is used by the router in its periodic broadcasts to indicate the time necessary to deliver a packet to a node on that segment. The method that drivers use for estimating the time delay on a segment depends on the segment type. For local segments with more than 1 Mb/sec of bandwidth (Token-Ring, Ethernet, Arcnet, and so on), the driver makes the assumption that delivery time is one tick. For remote segments (T1, 64 kbps, X.25, and asynchronous), the driver will periodically poll to determine the current time delay. For instance, the delay for a T1 link normally ranges from six to seven Ticks. If this delay changes, the driver will inform its router. As information about the segment is passed along throughout the network (by way of periodic broadcasts), routers will add any additional delay that they impose to the initial time estimate for the segment.

The NIC field of the Routing Information table records which NIC in the router the network segment can be reached through. The Immediate Address field contains the node address of the router that can forward packets to each segment. If the segment is directly connected to the router, this field will remain empty. The "Net Status" field indicates whether the segment is directly connected to the router and whether the segment is considered reliable. The final field is used to make sure that information about the segment is current.

For NetWare versions prior to 2.15c, the Routing Information table keeps a list of all alternate routes for each network number in case the primary shortest route to a network number goes down. In other words, if the router can reach the segment through more than one of its NICs, it will make a record of both routes. The fastest route, the one that requires the least number of Ticks, will always be used as the primary route. NetWare versions after 2.15c maintain alternate routes only if these alternate routes require the same amount of Ticks to reach the segment as the primary route. This reduces the size of the Routing Information table.

Routing Information Broadcasts

On an internetwork, routers are constantly exchanging information with each other to make sure that their Routing Information tables reflect up-to-the-minute changes in the layout of the internetwork. To accomplish this, routers transmit a series of broadcasts from the time they come up until they are brought down. These broadcasts can be separated by the time at which they occur:

  • Initial broadcast of directly connected network segments

  • Initial request to receive routing information from other routers

  • Periodic broadcasts (every 60 seconds) of current list of active network numbers

  • Broadcast of change in internetwork configuration

  • Final broadcast when brought down

Although the broadcasts occur at different times and, for the most part, contain different information, they must follow two important rules. First, each broadcast must be a local broadcast, addressed so that it will not be immediately passed on, intact, by the routers that receive it. This reduces the network traffic created by these information exchanges. Second, routers must follow a "best information" algorithm when providing information to other routers through a broadcast (since the second broadcast listed above is a request for information, this rule does not apply to it).

Best Information Algorithm

The purpose of routing information broadcasts is twofold: to allow a router to share its current impression of the layout of internetwork with other routers, and to inform the routers of an internetwork change so the routers can update their tables. A router sends routing information broadcasts to every network segment that it is directly connected to. The first rule of the best information algorithm dictates that a router about to broadcast to a particular network segment should not include any information about other segments that it has received from the segment to which the information is being sent.

For example, if the router within server FS2 in Figure 13 is going to broadcast a routing information broadcast to network segment BB, it will not include information that it received from FS1 about network segment AA. If it did, someone on segment BB might erroneously conclude that there are two paths to segment AA--one through FS1 and another through FS2.

Figure 13: The Beset Information Algorithm.

The best information algorithm also states that routers should not include information about the network segment that they are sending routing information broadcasts to. For example, FS2 would not include information about BB in its broadcast onto BB.

Taking these rules into account, the information that FS2 would broadcast onto segment BB would be information about segments CC and DD.

Initial and Periodic Broadcasts

Then a router is first brought up, it places the network numbers of its directly connected segments into its Routing Information table. Then, following the best information algorithm, the router sends a routing information broadcast to inform the routers on its directly connected segments of the segments that the router will be making available. The router next broadcasts a request to each of its directly connected segments for information about all other network segments that exist on the internetwork. This request is responded to by all the routers (each using the best information algorithm) on these directly connected segments. The router places the information gleaned from these responses in its Routing Information table. Figure 14 illustrates this initial sequence of broadcasts.

Figure 14: Sequence Used to Build and Maintain Routing Information Table.

Once the router has performed these initial broadcasts and updated its Routing Information table, it is ready to accept routing requests and route packets. In addition to routing packets, the routers will broadcast all the information in their Routing Information table (except that excluded by the best information algorithm) to each of their connected network segments every 60 seconds. Routers perform these periodic broadcasts to make sure that all routers on the internetwork remain synchronized.

Because of lower bandwidth of X.25 and asynchronous links, routers do not perform 60 second broadcasts on these links--only initial broadcasts, changed information broadcasts and final broadcasts are sent over these links.

Changed Information Broadcasts

When a router receives information that causes it to change its Routing Information table, the rouer will immediately pass that information on to its other directly connected network segments except the segment that the router received the information from. If a new network segment comes up or an existing segment goes down, all the routers on the internetwork will learn about the change in a short amount of time.

The primary cause of a change in the internetwork's configuration are file servers and external routers coming up or going down. If a router needs to be brought down (using the DOWN command at the console) the router will inform its directly connected segments of the fact before discontinuing service. The router issues broadcasts (as always, using the best information algorithm) that indicate that the network segments which the router had made available will no longer be accessible through this router. (See Figure 15.)

Figure 15: Routers Inform Other Routers When Going Down.

The Process of Aging

If a router goes down due to a hardware failure, power glitch, or power outage, other routers will not be notified that a change has occurred. To safeguard against this eventuality an "aging" mechanism has been built in to NetWare routers.

Routers maintain a timer for each entry in their Routing Information table. Every time that information is received concerning the entry, the timer is reset to zero. If the timer reaches three minutes, the router assumes that the route to the network number is down and broadcasts that fact to its other segments. Since this information is new or changes, the routers that receive the information will pass it on immediately and the change will quickly permeate the internetwork.

Service Advertising

Using the SAP, serveres on a NetWare network can advertise their services and addresses. The information that these servers broadcast is not directly used by clients but instead collected by a SAP agent within each NetWare router on the server's segment. The SAP agents store this information in a Server Information table and, if they reside within a server, in their server's bindery. The clients can then contact the nearest SAP agent or file server for server information.

The SAP broadcasts that servers perform are local broadcasts and, therefore, only received by SAP agents on their connected segments. Consequently, SAP agents periodically broadcast their server information so that all SAP agents on the internetwork have information about all servers that are active on the internetwork--this is the same broadcast method used by routers to distribute and exchange network number (RIP) information.

Server Information Table

The table that SAP agents use to store information received in SAP broadcasts is called the Server Information table. If all SAP agents on the internetwork are exchanging SAP information properly, each agent's Server Information table should have information about all the servers on the internetwork--thus providing clients with nearby access to the addresses of all the servers on the internetwork. Figure 16 illustrates some of the more peritnent fields of the Server Information table.

Figure 16: Portion of a NetWare Router's Server Information Table.

The Server Address field contains the service's full address, including network, node, and socket addresses. The Server Type field holds a number of designating what type of service the server provides. One server might provide printing services as opposed to file services, for instance. The server type designation used to assign numbers to the different services that servers provide is part of a more generic scheme used in the bindery to classify objects. Some of the more common object types are shown in Figure 17.

Figure 17: Object Types.

The Time Since Changed field is used for aging servers that have unexpectedly gone down. The NIC that the information about the server was received on is specified in the NIC Number field.

The way that information within the Server Information table is stored makes sequential access (send me information about all servers with server type 4, for instance) possible but makes database access (send me information about server NCS) very difficult. Therefore, the Server Name, Server Address, Server Type and Hops to Server fields of the Server Information table are periodically copied to file server's binderies by internal SAP agents--SAP agents that reside within file servers. With this information stored in file server binderies, any client that has a connection with a NetWare file server can query the bindery for the addres of a specific server.

Server Information Administration

When a file server is first brought up, its internal SAP agent places the name of the server in the agent's Server Information table. The SAP agent then sends a SAP broadcasts onto each of its directly connected segments to inform the SAP agents on those segments that a new server has become available. (See Figure 18.)

Figure 18: Sequence Used to Build and Maintain Server Information Table.

After performing its initial broadcasts, the SAP agent broadcasts a request onto each of its directly connected segments for information about other servers that exist on the internetwork. These requests are responded to by all the SAP agents on these directly connected segments. The SAP agent places the information received in these responses in its Server Information table. Thereafter, the SAP agent performs broadcasts about the servers that it is aware of every 60 seconds (except on asynchronous and X.25 links). Figure 18 illustrates these initial and periodic broadcasts.

As with routing information broadcasts, all server information broadcasts are local broadcasts and are subject to the best information algorithm. Any changes in server information are passed on immediately to ensure current information across the internetwork. The router applies the aging process to its Server Information table entries in case any servers become unavailable. Finally, if the router is brought down, it will indicate to its directly connected segments that the servers the router has been advertising will no longer be available. (See Figure 19.)

Figure 19: FS2 Brought Down.

File Server Addressing

Value-added servers, such as gateway and print services, normally contain only one network adapter and will use the address of that adapter as the addres they advertise in their periodic SAP broadcasts. NetWare file servers, on the other hand, may contain multiple adapters. This requires that they use some sort of convention for advertising the address of their file services; the convention used for this addressing differes for 286- and 386-based servers. Within the 286-based environment, the file services of a server are addressed with respect to its NIC A. This convention guarantees consistency since every server will have at least one network adapter installed. (See Figure 20.) If you enter an SLIST command, the address you see for 286-based servers is the network and node address assigned to the server's NIC A.

Figure 20: Addressing of File Services on a 286-based NetWare File Server.

In the NetWare 386-based servers, an internal network has been added for the addressing of internal services, shown in Figure 21. This different method of addressing requires that an internal network number be assigned when a NetWare 386-based file server is brought up.

Figure 21: Addressing of File Services in NetWare 386-based Server.

Figure 22 displays an SLIST screen that contains 286- and 386- based servers. The 386-based servers can be distinguished by their node address of one. This node address is assigned to the file services on the internal network number. The implementation of redundant cabling systems with 286-based servers is discussed in a later section.

Figure 22: Example SLIST Listing.

Client-Server Interaction

The NetWare shell facilitates client-server communications for DOS-based workstations. In a typical client-server interaction, one station (the client) requests services from another station (the server). Through the shell, DOS-based applications can request file services (such as writing to and reading from files) from NetWare file servers. At the workstation, the shell, the user application, and the user together act as the client requesting file services; the NetWare file server acts as the server providing file services.

The shell, then, is the liaison between the client (the user application) and the server. The shell performs the tasks necessary to request file services from a NetWare file server: for example, establishing a connection with the file server, maintaining the connection, and terminating the connection.

The NetWare shell is a terminate-and-stay-resident (TSR) program called NETx.COM (where x depends on the version of DOS being run). Netx.COM is loaded into a NetWare workstation's memory when the workstation is booted. Before you load the shell, however, you must load another TSR called IPX.COM.

IPX.COM

Novell's IPX protocol serves as the communication link with the NIC installed in the workstation. At installation, a customized version of IPX.COM is generated for each workstation by linking in a driver written specifically for the NIC that resides in that workstation. Once IPX.COM is loaded, any workstation programs, including the shell, can communicate on the network through NetWare's IPX protocol.

In addition to interfacing with the NIC, IPX.COM performs several communication-related functions. For example, it manages the IPX sockets used with the workstation. The shell and other applications access IPX.COM to open and close IPX sockets. When the workstation receives an IPX packet, IPX.COM checks which socket the packet is addressed to and passes the packet to the program having that socket open.

Finally, IPX.COM is responsible for determining the address of the network segment to which the workstation is physically connected. The workstation's network number, along with its node address, make up the workstation's full internetwork address.

IPX can determine the workstation's network number in one of two ways. In the first method, IPX.COM watches for any RIP broadcasts sent on the network. Since RIP packets are not forwarded to other network segments, IPX knows that this type of broadcast originated on the segment to which the workstation is directly connected. IPX simply reads the source network addres contained in the IPX header of a RIP broadcast to determine the workstation's network number.

IPX uses an alternate method if the shell requests a route to a network number before IPX can determine the workstation's network number from a RIP broadcast. In this case, IPX broadcasts a Get Local Target request, which requests the fastest route to the destination network number requested by the shell. Upon receiving a response, IPX.COM checks the source network number in the IPX header of the response packet. This source network number (the network number of the router that responded to the Get Local Target request) is the workstation's network number.

The NetWare Shell

The shell (NETx.COM) acts as the interface between user applications and NetWare file servers. As user applications make requests, the shell determine whether the requests should be handled locally by DOS or sent to a server on the network. If the shell determines that the request should be sent to a network serer, the shell formulates a request packet, hands it to IPX.COM for transmission, and waits for a response.

Prior to submitting any requests to a server, the shell must establish a connection with that serer. The shell can establish a connection to a server in two ways: When the shell is first loaded at the workstation, it logically attaches to the first server that responds (usually the server nearest to the workstation). The LOGIN and ATTACH command line utilities, when executed, also establish a server connection.

To establish a connection, the workstation and the server must exchange several packets: a packet requesting that a connection number be assigned to the shell, and another proposing the maximum packet size that will be allowed in the interaction between the file server and the shell. Before sending these initial packets, the shell needs the address of the server and a route to the server.

Getting a Server's Address

To get a server's address, the shell can use the SAP to broadcast a request for the address of the nearest server--a Get Nearest Server request. All routers on the workstation's network segment having information about the nearest server respond to the Get Nearest Server request. Each response contains the nearest server's name, its full internetwork address, and the number of Hops required to reach the serer. (See Figure 23.)

Figure 23: Getting the Address of the Nearest File Server.

When first loaded at a workstation, the shell issues a Get Nearest Server request to establish an initial connection to a file server. If the shell loses its connections with all file servers, it resorts to the Get Nearest Server request method to re-establish a server connection.

A second method the shell uses to get a server's address is to use the NCP to access a file server's bindery. The bindery is a database within NetWare file servers that contains informations about many network entities, including users, groups, and servers.

Because the shell must already have a server connection before it can access the server's bindery, the shell can use this second method only after it has established an initial connection to a file server. The LOGIN and ATTACH utilities use this method, as does the new "preferred server" shell (version 3.01). These utilities allow the user to specify a specific file server name, and then these utilities use that name to scan the bindery for the server's address.

Getting a Route to a Server

Once the shell has the address of a server, it needs a route to that address. The shell uses this route for all subsequent communications with the server for the duration of the connection.

To obtain a route, the shell submits a Get Local Target request to IPX.COM. IPX first compares the network numer of the desired server to the workstation's network number. If these two numbers are the same, IPX tells the shell to send requests directly to the server (without going through an intermediate router).

If the network number the shell submits and the workstation's network number are not the same, IPX broadcasts a RIP request for the fastest route to the submitted network number. Whichever router on the workstation's network segment has the shortest route to the network will respond to the request. More than one router might respond if several routers have a route equal to the shortest route. IPX accepts only the first router's response, discarding all others.

IPX then returns to the shell the node address of the first router that responded. The shell places the node address of this router in the MAC header of a Create Connection request packet; it addresses the IPX header of the request packet to the file server it wants to connect to. With the packet addressed in this fashion, the router will receive the packet first, check the IPX destination address, and forward the packet toward the network number on which the file server resides. (See Figure 24.)

Figure 24: Requesting the Fastest Route to an Address.

Establishing an Initial Connection

To establish its connection to a file server, the shell uses a combination of the SAP, the RIP, and the NCP. The sequence followed is slightly different for the new "preferred server" shell (version 3.01) than it is for previous shell versions.

Figure 25 shows the steps taken by pre-v3.01 shells to make a connection with a file server. The first column represents the call or packet sent. The second column lists the source, or sender, of the packet. The third column lists the addressee of the packet. The final column indicates the protocol used for the packet.

Figure 25: Initial Connection Sequence for NetWare Shells.

We have already seen how the first four steps work. In steps 1 and 2, the shell obtains the address of the nearest server. Step 3 is IPX.COM's request for the fastest route to the address that the shell received in step 2. Step 4 is the response by all routers with the shortest route to that segment.

Steps 5 through 8 show the packets exchanged between the shell and the server to establish the initial connection. Once this connection is made, the shell move to the background (terminates- and-stays-resident) and returns the DOS prompt to the user. The user can then execute LOGIN.EXE to log in to the connected server or to another server.

The Preferred Server Shell

The preferred server shell (v3.01 and above) features several additional functions not offered by older verseions of the shell. As its name implies, the preferred server shell allows users to specify, either at the command line or in the SHELL.CFG file, which server they would like to connect with. Whether or not a preferred server is specified, the preferred server shell goes through the same initial eight steps as the old shells.

If the server the shell connects to during the initial eight steps is not the preferred server the user specified, the preferred server shell performs several additional steps to establish a connection with the specified server. (See Figure 26.)

For instance, if the workstation in Figure 24 initially connects to FS1 and the user specifies FS3 as the preferred server, the shell will follow a sequence similar to that shown in Figure 25. As you can see in step 9, the preferred server shell uses the bindery method of acquiring the server's address.

Figure 26: Connection Sequence for the Preferred Server Shell.

Steps 11 and 12 of this preferred server sequence are not always required. If the preferred server resides on the same network segment as the workstation, the shell skips these two steps and sends the Create Connection request directly to the server. The shell destroys the connection with the initial server once it has successfully established the connection with the preferred server.

Another major difference between old shells and the preferred server shell involves the receipt of Give Nearest Server responses. Older shells accept the first Give Nearest Server response they receive and ignore all subsequent responses. Preferred server shells accept the first response also, but save the next four Give Nearest Serve responses in case a connection cannot be made to the first server.

Servers respond to get Nearest Server requests even if they have no free connections. Consequently, older shells fail to establish a connection (steps 5 and 6 of Figure 25) if the first Give Nearest Server response they receive is from a server with no free connections. The preferred server shells, on the other hand, can refer to the next saved Give Nearest Server response if the current attempt to establish a connection fails.

LOGIN.EXE

Users can run LOGIN.EXE at any time after they have established a connection to a NetWare file server. LOGIN submits the user's name and password to the file server for verification. It also establishes a new server connection if the user specifies a file server in the LOGIN command.

If the server specified at the command line is not the one the shell is already connected to, LOGIN follows the steps outlined in Figure 27. Once these steps are completed, LOGIN verifies the username and password. If the server specified at the command line is located on the same segment as the workstation, steps 3 and 4 are not necessary.

Figure 27: Additional Steps Performed by LOGIN.EXE.

ATTACH.EXE uses the same sequence as that described for LOGIN.EXE when establishing connections to a file server.

Connection Management

Communication between any two workstations requires a certain amount of responsibility on both sides to ensure that no information is lost. NICs maintain error checking at the bit level in the NetWare environment. File servers and workstation shells handle packet- and session-level error checking; each maintains a table to handle this level of error checking. The NCP governs the way that the connection control information is exchanged. (It is a common misconception that SPX is used for packet level error checking between workstations and servers; however, SPX is only used for peer-to-peer interaction.) Every NCP packet submitted to a NetWare file server by a client must have a connection number and sequence number attached to it. The connection number is the number that client was assigned by the file server when the connection was established. The sequence number identifies each packet so that both the server and the shell can determine when a packet is lost.

The Shell's Connection Table

NETx.COM (the shell) can support up to eight server connections concurrently. Netx.COM maintains a connection table to track these connections. (See Figure 28.) Within each entry in this table, the shell stores the same and full internetwork address of the server it is connected to. If the shell is forwarding packets through an intermediate router to the server, the node address of that router will be stored in the Router's Node Address field. The shell's connection number and packet sequence number are also in the table. The sequence number is set to zero when the connection is first established and incremented with each new request.

Figure 28: Portion of Shell's Connection Table.

The shell's connection table also maintains two time-outs. One time-out is the maximum time that the shell will wait for a response from the server before resending a request packet. This time-out is based on an estimate of the time (in ticks) needed to deliver a packet to the server. This time estimate is provided by the router in its Give Immediate Address response. (If the workstation and the server are on the same segment, this value is set to one tick.) The shell multiples this estimate by 16 and adds 10 ticks to the result to set its maximum time-out for communications with that server.

The Receive Time-Out is a dynamic time-out that is originally set to four times the time estimate (received in the Give Local Target response) plus 10 ticks.

Receive Time-Out = 4t + 10

Once initially set, the receive time-out adjusts up or down to adapt to changing network conditions. The receive time-out is increased if the shell issues a request to a server and does not receive a response within its current receive time-out. The receive time-out is multiplied by one and one-half when the first retry to the server is issued. It remains at this new value for all subsequent retries on the request and for use on the next request. If the next request requires a retry, the receive time- out will be increased again. The receive time-out will continue to be increased in this fashion until it reaches the maxiumum time-out.

New Receive Time-Out = 1.5 (Current Receive Time-Out)

The shell decreases the receive time-out each time that the shell does not have to issue a retry to a request. To decrease the receive time-out, the shell takes the time necessary to receive a resonse to the last request--the request that didn't require a retry--and multiples that value by two and adds 10 Ticks to it. The shell sets the new receive time-out to the average of this calculated value and the current receive time-out.


New Receive Time-Out =

[2(Time to Receive Response) + 10] + Current Receive Time-Out)

2

The number of times that the shell will resend a request to a server is determined by a number called the IPX Retry Count. If this count is exceeded the shell will give up and present the user with a "Network error on server xxxxx. Error xxxxx from network. Abort, Retry?" message. A default for this retry count exists for all drivers. This default differse from driver to driver but is generally between 20 and 40. The "IPX RETRY COUNT = xx" option for the SHELL.CFG files allows the default IPX retry count to be modified; however, some drivers will ignore this entry in the configuration file and leave the retry count at their default.

The File Server Connection Table

The file server connection table, shown in part in Figure 29, allows the server to keep information about each of the clients that it is servicing. The address fields are used for addressing response packets and for security purposes. When a packet arrives with a service request, it contains the connection number assigned to the sender. The server matches the packet's IPX source address (network, node, socket) with the address registered for that connection number. If the addresses don't match, the server regards the request as a security breach.

Figure 29: A Portion of the NetWare File Server's Connection Table.

The NIC Number and Intermediate Router's Address fields are used for sending responses to clients. As a request packet is received, the number of NIC that the request came in on is placed in the NIC Number field--this number would A, B, C, or D for NetWare v2.15c and earlier versions, or the network number of the NIC for NetWare version 3.0 and above. If the packet was forwarded through one or more routers, the node address of the last router is stored in the Intermediate Router's Address field. Hence, when the request has been processed, the server does not have to find a route to the client to send a response. The server places the node address of the first router in the path to the client--from the Intermediate Routers Address field--in the MAC header destination address field and sends the packet through the NIC specified in the NIC number field. Of course, it first places the client's and its own full network address in the destination and source address fields of IPX header, respectively.

The Sequence Number field is used for packet-level error checking. The Watchdog Count and Timer fields are used by the watchdog process, which is discussed later. File servers also maintain a 100-byte reply buffer for each of their connections. If a response to a client is less than 100 bytes, the server will make a copy of the response in the buffer that corresponds to that connection. If the client does not receive the response and resends the request, the server will not have to reprocess the request.

Packet-Level Error Checking

The bit-level error checking that network adapters provide detects the corruption of individual bits within a packet. When an adapter finds that part of a received packet is corrupted, it discards the entire packet. Due to the drive's simple design, no mechanism exists within the driver to request that the packet be resent or to inform the upper-layer processes and applications that an error occurred. Therefore, the upper-level sending process (shell or file server) must determine when a packet has not reached its intended destination.

In the NetWare environment, this packet-level error checking is the responsibility of the shell. The NCP specifies that a workstation shell can submit only one request to a server at a time. Furthermore, the response that the server provides must fit in a single packet--the shell should never requeste more than a packet's worth of information. Thus, to guarantee that no packets have been lost, the shell only has to make sure that it receives a completed response to each of its requests.

Each request that a shell sends to a server has a sequence number attached to it within the NCP header. The response that the server returns is labeled with the same sequence number. Ultimately, the shell is responsible for getting completed responses for each of the service requests that it submits. If the shell does not receive a response to its most recent request within a specified receive time-out, it will submit the request. The shell continues to resubmit the request until it receives a response or exceeds its IPX Retry count.

Three conditions could cause a shell to time-out while waiting for a response from a server. Figure 30 illustrates a case in which the request is lost in transit to the server. The workstation's timer eventually expires and the shell resends the same request. The server receives the second request, processes it, and sends back the response.

Figure 30: Request Lost in Transit to File Server.

In Figure 31, the request is received by the server but the response is lost in transit to the workstation. Once the workstation's timer reaches its limit, the shell sends a second identical request to the server.

When a server receives any request, it checks the request's sequence number to see that it is one greater than the sequence number registered in the server's connection table. If it is, the server increments that number and processes the request as usual. However, if the two numbers are the same, the server determines that the client, for whatever reason, is resubmitting its last request. In some cases, the server will have a copy of the last response. NetWare file servers maintain a 100-byte response buffer for each of their connections. If the server is sending a response that is less than 100 bytes in size, the server will make a copy to that client's buffer--that is, the buffer corresponding to that client's connection number. Since a large percentage of responses are les than 100 bytes, a good chance exists that a server will have a copy of the response when requests are resubmitted by clients. (This type of response increments the Duplicate Replies Sent counter on the FCONSOLE Statistics->LAN I/O Statistics screen). On the other hand, if the request was larger than 100 bytes, the server must reprocess the request and send the response. (This type of response increments the Reexecuted Requests counter in FCONSOLE.)

If the response is still in transit to the workstation when the shell times out and resubmits the request--that is, the shell receives the completed response after resending the request--the server will send another response, but the shell will ignore it.

Figure 31: Response Lost in Transit to Shell.

Sometimes a server may be too busy to respond within the shell's time out. The shell then resends the requeset. When the server receives this second request, it sends a reply to the workstation stating that the initial request was received successfully, but that the processing of it has not yet been completed (This intermediate response increments the Positive Acknowledgments Sent counter within the FCONSOLE Statistics->LAN I/O Statistics screen.) When the shell receives this reply from the server, it sets its time-out to zero and waits for the request. If the shell's time-out expires again, it will send a third copy of the request just in case the response was sent by the server but lost in transit. This process will continue until the shell finally receives a completed response. (See Figure 32.)

Figure 32: File Server is Busy.

Connection-Level Error Checking

The connection between a workstation and server can be lost due to a power failure or a communications problem. Both file servers and workstation shells are equipped to handlle this eventuality. On the workstation side, the connection is checked each time a request is made. If the shell does not receive a response to a request after it retries a certain number of times (the number dictated by the IPX Retry Count), the shell assumes that a problem exists with the connection and displays a message for the user. At this point, the user has the choice of ordering the shell to resubmit the request again or to abort the operation completely.

If the operation is aborted the shell removes that connection from its Connection table. If it does not have any other server connections, it attempts to create a new connection with a server (using the initial connection sequence outlined in Figure 25). If this attempt is unsuccessful, the shell informs the user with the following message: You are not connected to any file servers. The shell will try to connect to a file server whenever the current default drive is changed to an invalid drive. <Current drive is no longer valid<.

Connection-level error checking at a NetWare file server comes in the form of address verification and periodic watchdog polling. When a file server receives a request packet for a certain connection, it verifies that the IPX source address within the request packet matches the address recorded for that connection within its connection table. If the addresses do not match, the server returns a response to the sender of the request indicating that the connection number and address do not match.

The Watchdog Process

When a workstation is turned off, regardless of whether the LOGOUT command was issued, the station's connection remains occupied at the server. To clear these unused connections, the server uses the watchdog process to poll (send a query packet to) clients that the server hasn't heard from for a period of five minutes. This five-minute period is tracked for each connection in the Watchdog Timer field of the server's Connection table. If the shell within the station that the server is polling is still operational, it will respond to the query and the server will reset its timer for that connection.

However, if the workstation has been turned off or some communications problems exists on the network, the server will not receive a response from the shell. In this instance, the watchdog process resets the connection's Watchdog Timer field to zero, but increments the Watchdog Counter field by one. The next packet that the watchdog process sends to the workstation will be sent a minute later. If the watchdog continues to hear nothing from the workstation, it will send a packet every minute until it has sent a total of 11 polling packets to that workstation. Figure 33 illustrates the timetable for a connection that does not answer to a server's queries. The server will clear the workstation's connection if no response to the last watchdog packet is received. (NetWare 386-based servers provide a setable parameter that allows administrators to monitor when workstations are logged out by the watchdog process. This option is set with the following command: SET CONSOLE DISPLAY WATCHDOG LOGOUTS=ON.)

Figure 33: Watchdog Timetable for a Connection that Does Not Respond.

Conclusions

NetWare's client-server communications are governed by a series of protocols. These protocols can be broken up by functionality: protocols used for all communications (the medium access protocols and IPX), administrative protocols (the RIP and SAP), protocols concerned with connection control (the NCP and Watchdog) and, finally, the protocol with defines the coding of service requests (the NCP). This document explains the operation and interoperation of these protocols; however, it does not attempt to apply this information to all possible network configurations and environments. It is up to you to apply this information to your specific network(s).

Appendix A: Implementing Redundant Cabling

In internetworks that contain 286-based NetWare file servers, incorporating multiple paths to those file servers may result in inefficient routing. Figure 34 shows an example of a 286-based NetWare internet work that contains redundant paths to two file servers.

Figure 34: Sample Redundant Path Configuration.

The problem with this sample network configuration involves the route taken by workstations on segment BB to communicate with file server FS1. Although the shortest route between the workstations on BB and FS1 is through NIC B on FS1, there is a good chance that packets may pass through FS2 onto AA and subsequently through NIC A of FS1.

Since traversing through an intermediate NetWare router can cause up to 40 percent degradation in the performance of packet exchanges between a workstation and afile server, the scenario illustrated in Figure 35 is not the most desirable.

Figure 35: Inefficient Path to FS1.

Routing problems occur because of the file service addressing scheme used for 286-based NetWare file servers, combined with the algorithm for establishing a connection to a file server.

File Service Addressing

The file services of a NetWare file server are assigned a specific address within the file server. With 286-based NetWare servers, file services are addressed with respect to NIC A in the file server. In other words, when the file server advertises its existence, it provides only the network and node address assigned to its NIC A--a socket address is also included but it is not specific to NIC A. Figure 36a shows a logical representation of the file service addressing within a 286-based NetWare file server.

Figure 36: Addressing of File Services in NetWare File Servers.

With NetWare 386, the file services are addressed with respect to an internal network number assigned when the server is booted up. NetWare 386 assigns the file services node address 1. (See Figure 36b.)

The Connection Algorithm

The problem inherent to the addressing scheme used for 286-based NetWare file servers arises when LOGIN, ATTACH or the preferred server shell attempts to connect to a specific server. Figure 37 illustrates the way that the file services of both servers appear to the workstations.

As we have seen, a workstation's Get Local Target request asks for the fastest route to the network segment on which the file server is located (segment AA for FS1.) Since the router in FS1 and the router in FS2 both register the same distance to network segment AA (two Ticks), both will respond to the Get Local Target request.

Figure 37: Logical Positioning of File Services.

If FS2 is the first to respond to the requests, the workstation assumes that FS2 has the fastest route, and therefore sends the create connection request packet through FS2. If FS2 is consistently faster than FS1 in responding to Get Local Target requests, connections to FS1 will always be established through FS2.

Figure 38 shows the entire sequence that the workstation goes through to connect to FS1 if FS2 responds to a Get Local Target request first. In this sequence, FS2 is assumed to be consistently faster than FS1 in responding to Get Local Target requests.

Since FS2 is always the first to respond, the shell initially connects to FS2 (using the sequence shown in Figure 25). After making this intial connection, the shell returns the DOS prompt to the user.

Figure 38: Workstation Sequence For Get Local Target.

The user can then enter the command "LOGIN FS1/" to log in to FS1 (following the sequence outlined in Figure 27). First, the shell queries FS2's bindery for FS1's address.

Next the workstation broadcasts a Get Local Target request. The router for FS1 and the router for FS2 both answer this request, but FS2's router responds first. Therefore, the workstation assumes that FS2 must have the fastest route to network segment AA and sends its connetion request--and all subsequent packets intended for FS1--through FS2. Since FS1 depends on the workstation to find the fastest route between the, FS1 sends all responses through FS2.

To avoid this inefficient routing scenario, you can connect workstations on the same segment as a file server's NIC A when you have redundant paths to the server. (See Figure 39.) With the correct configuration, the shell receives the address of FS1 from FS2's bindery and makes the Get Local Target call to IPX. IPX determines that FS1 and the workstation are on the same network segment and tells the shell to address packets directly to FS1.

Figure 39: Correct Configuration of Redundant Paths with 286-based NetWare.

Note that the connection sequence followed for the pre-v3.01 shell and LOGIN.EXE is the same as that followed by the preferred server shell. Therefore, the scenario described above applies for the preferred server shell when a preferred is specified by the user.

Another Redundant Path Configuration

Figure 40 shows another possible configuration that incorporates redundant paths with 286-based NetWare file servers. In this configuration, workstations on network BB should have direct access to both FS1 and FS2. Due to the 286-based NetWare addressing scheme, however, packets destined for one file server might go through the other file server first.

For instance, if a workstation on BB wants to log in to FS1 but initially connects to FS2, it will query FS2's bindery for FS1's address. The address returned will include network number AA. The workstation will then issue a Get Local Target request for AA. If FS2 responds to this request first, the workstation's communications with FS1 will go through FS2.

Figure 40: Redundant Paths With 286-based NetWare File Server.

Unfortunately, there is no all-inclusive solution to the routing problems possible with this configuration. However, the configuration shown in Figure 41 will keep unnecessary routing to a minimum. This configuration places NIC A for server FS1 and NIC A for server FS2 on different networks: FS1's NIC A is connected to AA; FS2's NIC A is connected to BB. Furthermore, workstations that access FS1 the majority of the time are connected to AA, while those that access FS2 most often are connected to BB. This configuration guarantees workstations a direct path to the file server that they access most frequently.

Figure 41: Keeping Routing To A Minimum.

Redundant Paths with NetWare 386

Thanks to the internal network addressing scheme used by NetWare 386-based file servers, they avoid the redundant-path problems experienced by 286-based file servers. To illustrate, suppose FS1 is a NetWare 386 file server with an internal network address of CC. In this case, FS2 registers two Hops to CC, while FS1 registers only one Hop to CC.

When the shell obtains the address CC from FS2's bindery, only FS1 responds to the Get Local Target request. FS2 does not answer the request because it no longer has a route equal to the fastest route to network segment CC.

The algorithms the NetWare shell uses to connect to a file server are relatively simple in design. The basic procedure is the same: get a server's address, obtain a route to that address, and send a request to establish a connection with the server.

However, when you configure 286-based NetWare file servers in an internetwork with redundant paths, the shell may inadvertently route packets through an intermediate router, even though the workstation is connected to the same network segment as the file server it wants to communicate with. As a result, you must carefully design redundant-path networks to avoid such routing inefficiencies. As a general rule, always connect those workstations that will spend most of the time accessing a certain server to the NIC A segment of that server.

Appendix B: Internal Components of a File Server

It is a common misconception that NIC A enjoys a higher priority within the 286-based NetWare servers and that it is therefore somewhat faster than the other NICs. However, NIC A must vie for access to routing and file services as a peer of NICs B, C, and D. In fact, within 286-based NetWare servers, the only difference between NIC A and its peers is that the address of the server is tied to it.

286-Based NetWare Communication Components

To fully understand the part that NICs play within 286-based and NetWare 386 servers, it is necessary to look at the communications components that make up a server. Figure 42 gives a graphic representation of the communication-related components of a 286-based server that contains two NICs.

Figure 42: Internal Communication Components of a 286-based NetWare File Server .

Each NIC has a corresponding driver. These drivers can be logically separated into a send portion that transmits packets through the NIC and a receive portion that pulls packets off the NIC. The receive portion is commonly called the driver interrupt service routine (ISR) since it is executed each time the NIC generates a hardware interrupt. (In most cases, a hardware interrupt from the NIC indicates that a packet has been received.) When a packet is received, the ISR checks the length of the packet to make sure that it is large enough to be viable IPX packet but not so large that it will not fit into the server's buffers. If the packet does not pass this test, the driver simply discards it. If the packet is viable, the driver attempts to place the packet in a buffer.

A 286-based file server uses two sets of packet buffers: file service process (FSP) buffers and communication buffers. The FSP buffers are primarily used for processing service requests (NCP packets) and can number between one and 10, depending on the configuration of the server. These buffers reside within the DGroup memory segment of the server and are subject to its limitations. (Due to the design of the Intel 80286 processor, memory must be divided into 64KB segments. The DGroup segment has been optimized in the NetWare operating system code to be the fastest segment. It contains several components besides the FSP buffers which, for larger server configurations, may limit the memory available for these FSP buffers.)

All FSP buffers are the same size; they are sized to handle the largest packet that any of the server's NIC drivers can receive. For instance, if the server contains an Ethernet driver able to handle l,024-byte packets and an Arcnet driver able to handle 512-byte packets, the buffers will sized to handle 1,024-byte packets.

The communication buffers act as overflow areas for packets being received by the server. The number of buffers that exist ranges from 40 (the default) to 250 for version 2.15c--this number is set within NETGEN at installation. These communication buffers are also sized to handle the largest receivable packet size. Both sets of buffers are set up as first in, first out queues, or linked lists, where the first packets to be received are placed at the front of the queue and all subsequent packets placed in line after that.

Without examining the contents of the received packet, the driver ISR first attempts to place the packet in an FSP buffer. If the FSP buffers are full, the ISR will try to place the packet in a communication buffer. The packet is discarded if both sets of buffers are full. The assumption is that the packet-level error checking implemented at the transport layer (handled by the NCP, SPX, and so on.) will cause the sender to send another packet later when the server is not so busy. Once the ISR has placed the packet in a buffer or has discarded it, the ISR returns control of the CPU to the server and waits for another packet to be received by its NIC. The ISR for each NIC follows this same routine. Each has equal access to the buffers and places received packets at the end of the FSP or communication buffer queues.

A routing process services the FSP and communication buffers. (This process is technically referred to as the Mux process or polling process.) The routing process periodically checks the contents of the FSP and communication buffers. This process is responsible for routing packets found within these buffers to their proper desteination, whether that be in or outside the server. Generally, five types of packets can be found in the buffers:

  • Service requests for the file server (NCP packets addressed to the server)

  • Packets that need to be routed to another network segment

  • RIP packets

  • SAP packets

  • Packets addressed to other processes internal to the file server,such as nondedicated DOS process or a value-added process (VAP)

When the routing process examines a packet in one of its buffers, it takes one of four actions:

  • If it finds a service request for the server, the routing process will schedule an FSP to service the request. The routing process will then go on to the next buffer.

  • If it finds a packet not addressed to the server, the routing process will check its Routing Information table for the best route to the destination and send the packet through the appropriate NIC. In this capacity, the routing process acts as the internal router of a file server.

  • If it finds a RIP or SAP packet the routing process will update its Routing or Server Information table, respectively, if necessary. However, if the packet is a RIP or SAP request (such as a Get Nearest Server request) the routing process will get the appropriate information from its tables and send a response.

  • If it finds a packet addressed to another process within the server (the packet would be identified by the destination socket number in the IPX header) the routing process will pass the packet on to that process.

The routing process first checks the FSP buffers, starting at the top of the queue. Since file service requests to the server can only be processed in the FSP buffers, the routing process must try to keep the FSP buffers as free as possible for these types of packets. Since the NIC driver ISRs indiscriminately place packets into whichever bufferse are free at the time, the routing process may have to shuffle packets back and forth between the FSP and communication buffers. Before checking the contents of the FSP buffers, the routing process checks into see if all the buffers are full. If so, the routing process asssumes that some NCP requests may have overflowed to the communication buffers. Therefore, any non-NCP packets that the routing process finds in the FSP buffers are moved over to the communication buffers to make room in the FSP buffers for all the NCP requests. If the FSP buffers are not full, the routing process simply processes all of the packets where they are.

Having completed the scheduling or movement of packets in the FSP buffers, the routing process switches its attention to the communication buffers. The routing process attempts to move any NCP request packets that it finds over the FSP buffers. It places these packets in a separate queue within the communication buffers if the FSP buffers are full. This queue is later checked by the FSP buffers as they finish processing their current requests. Any packets that are not NCP requests are routed or processed within the communication buffers by the routing process.

NetWare 386

The NetWare 386 servers follow the same communication mode as 286-based servers, with the following exceptions:

  • NIC drivers may be used re-entrantly to handle one or more NICs, therefore saving RAM.

  • Only one set of packet buffers exists within a NetWare 386 server(this difference stems from the 32-bit addressing scheme used by 386 processors.)

  • FSP buffers are taken from a pool as they are needed and are not assigned to one specific buffer. The number of FSP buffers may increase as the load on the server increases.

  • NetWare 386 servers contain an internal network number for server addressing.

Figure 43 illustrates the structure of the NetWare 386 communications environment.

Figure 43: Internal Communication Components of a NetWare 386 File Server .

Appendix C: RIP and SAP Bandwidth Requirements

On large internetworks with several hundred servers, administrators become concerned with the load that RIP and SAP broadcasts will place on their network segments. Of course, these concerns can be appeased for asynchronous and X.25 links since only changed server and routing information is sent on these lines. On other segment types the traffic caused by these broadcasts does not cause a significant load. The requirements and some examples are shown in Figure 44. As you can see, the SAP broadcasts for an internetwork containing 250 servers account for less than one percent of the total bandwidth (10Mb/s) of an Ethernet segment.

Figure 44: Bandwidth Requirements for 60 Second Broadcasts.

Total traffic load of routing and server information broadcasts on any given segment will be equal to broadcasting information about all the network segments and servers that exist on the internetwork. For example, on a T1 link between two NetWare routers, one router will broadcast information about all of the network segments and servers that it is making available to the other router (using the best information algorithm). The other router will broadcast information about all the segments and servers that it is making available to the first router. The total fo the two equals the total number of servers and segments that reside on the internetwork.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates