The Novell NetWare network operating system allows the sharing of information among desktop computers and network servers over a local area network (LAN). NetWare can be divided into three components: NetWare server, NetWare clients, and transport protocol.
This component controls operation of the network and provides the core functionality for the network file system, memory management and scheduling of processing tasks such as file and print-sharing and handles functionality common to many users, such as file- and record-locking and database queries.
This component deals with end-user-intensive activities.
This component facilitates communication between the server and the clients.
This chapter helps you:
This component is comprised of the following drivers:
This component includes the following protocols by which the SCO OpenServer system can advertise itself to NetWare clients:
This component consists of an executable that allows a DOS client to establish a connection to the UNIX server. The NVT.EXE executable is a terminate-and-stay-resident program (TSR) and acts as a network redirector, allowing a DOS end user to establish a connection with an NVT server. For more information about installing the DOS component and using NVT.EXE, see ``Installing and using the DOS component''.
In addition to NVT.EXE, the DOS client must be running a NetWare protocol support module to provide the IPX protocol support and the device driver for the LAN card used in the DOS client machine. Currently, there are two prevalent IPX protocol modules and a terminal emulator provided by Novell:
The following table describes which protocols
are used and supported by SCO IPX/SPX:
Table 4-1 Protocols supported by SCO IPX/SPX
-------------------------------------------------------------- Protocol Supported API provided -------------------------------------------------------------- Internetwork Packet Exchange (IPX) yes yes Sequenced Packet Exchange (SPX) yes yes Service Advertising Protocol (SAP) yes yes Routing Information Protocol (RIP) yes no NetWare Core Protocol (NCP) yes no Novell Virtual Terminal (NVT) yes yesNCP is supported by SCO IPX/SPX but is only used by SCO Gateway for NetWare.
For detailed information on Novell networks, see the Novell documentation.
How protocols work
Most computer networks require that information transferred
between two nodes be divided into blocks, called packets.
These packets make the information more manageable for
sending and receiving nodes, as well as any intermediate nodes
(bridges 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 used on the network define the content of this control information. In most cases, multiple protocols exist within a packet; each protocol defines a different portion of the control information for the 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 placed around the data first, then the control information for each subsequent protocol in the protocol stack is added to the beginning and/or end of the packet. This process is called ``enveloping'' and is illustrated in Table 4-2.
Table 4-2 Example of multiple protocols in a packet
--------------------------------------------- | Header Control Information for Protocol #3 | |--------------------------------------------| | Header Control Information for Protocol #2 | |--------------------------------------------| | Header Control Information for Protocol #l | |--------------------------------------------| | Data | |--------------------------------------------| | Trailer Control Information for Protocol #l| |--------------------------------------------| | Trailer Control Information for Protocol #2| |--------------------------------------------| | Trailer Control Information for Protocol #3| |--------------------------------------------|
The enveloping pattern illustrated in the previous table is common in the computer communications industry. However, the tasks assigned to each protocol in the packet differ for different vendors' 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 the following seven categories, or layers, presented below from the highest to the lowest:
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:
These protocols are described in greater detail in the following sections.
Figure 4-1 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 pattern previously shown in Table 4-2. More specifically, the upper level protocols (NCP, SAP, and RIP) are enveloped by IPX, and IPX is subsequently enveloped by a medium-access protocol header and trailer.
Figure 4-1 Mapping of NetWare protocols to OSI model
Medium-access protocols
Medium-access protocol
implementations define the addressing that
distinguishes each node on a NetWare network.
This addressing is
implemented within the hardware of each network interface controller
(NIC).
A number of medium-access protocols are 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:
The 802.x protocols are defined by the Institute of Electrical and Electronic Engineers (IEEE). Ethernet version 2.0 was co-developed by XEROX and Digital Equipment Corporation. These medium-access protocol implementations are primarily concerned with the transport of packets from one node to another on a single network segment.
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 address fields for both the source and destination nodes 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 to which it is attached. 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.
Two types of error-checking can be performed:
IPX is a datagram-based, connectionless protocol. Datagram-based, connectionless protocols do not require an acknowledgment for each packet sent. Packet acknowledgment, or connection control, must be provided by protocols above IPX.
The basis of IPX addressing is the network number assigned during the installation and configuration process. Each network segment on a NetWare internetwork must be assigned a unique network number (sometimes called the external network number). Each server (SCO or NetWare) must also be assigned a unique internal network number. These network numbers are used by routers to forward packets to their final destination segment.
Figure 4-2 illustrates how internal and external network numbers are used.
Figure 4-2 Network numbering
The basis of IPX intranode addressing is socket numbers. Since several processes normally operate within a node, socket numbers provide a means by which each process can distinguish itself to IPX. When a process needs to communicate on the network, it requests that a socket number be assigned to it. Any packets IPX receives that are addressed to that socket are passed on to the corresponding 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 Table 4-3. Because socket numbers are internal to each node, several workstations can use the same socket number at one time without any fear of confusion.
Table 4-3 Socket numbers used in the NetWare environment
----------------------------------------------------
Socket number Description
----------------------------------------------------
451h NetWare Core Protocol
452h Service Advertising Protocol
453h Routing Information Protocol
455h NetBIOS
456h Diagnostics
4000h-6000h Ephemeral sockets; used for
interaction with file servers and
other network communications
The network, node, and socket addresses for both the destination 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 usually contains the header of a higher-level protocol.) Figure 4-3 illustrates the structure of an IPX packet on an 802.3 network.
Figure 4-3 IPX packet structure
Sequenced Packet Exchange (SPX)
The Sequenced Packet Exchange (SPX) protocol works
with the Internetwork Packet Exchange protocol (IPX)
to provide reliable delivery. SPX guarantees that
packets are received intact, in the order they were sent, and
eliminates duplicate packets.
IPX receives packets from the network and passes on those for SPX to handle.
SPX requests verification from the destination module for each packet sent. By checking a verification value against a value calculated before transmission, SPX ensures that the packet arrives intact. In the case of a missing packet, the transmitting SPX module retransmits, and continues to do so up to a program-specified number of retries.
SPX does not provide group broadcast support; packets can only be sent to a single session partner. SPX can detect if its partner has disappeared.
SPX uses IPX and a medium-access protocol for its transport.
The SPX packet structure is shown in Figure 4-4. This structure is enveloped within the data area of IPX.
Figure 4-4 SPX packet structure
An SPX packet contains the following fields:
The broadcast of RIP packets allows:
For more information on routers and the functions they perform,
see the Novell NetWare documentation.
The RIP packet structure is shown in Figure 4-5. This structure is enveloped within the data area of IPX.
Figure 4-5 RIP packet structure
The packet contains the following fields:
The ``Operation'' field can be followed by one or more 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 original XNS definition of the RIP did not include the ``Number of Ticks'' field. The ``Number of 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. Also, if multiple routes exist to a network number, a router uses the route with the smallest 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 ``Number of hops'' and ``Number of 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.
Service Advertising Protocol (SAP)
The Service Advertising Protocol (SAP) allows service-providing
nodes
-- such as file servers, print servers, gateway servers,
and application servers --
to advertise their services and addresses.
SAP makes the
process of adding and removing services on an internetwork dynamic.
As servers are booted up, they advertise their services
using SAP;
when they are brought down, they use SAP to
indicate that their services will no longer be available.
Through 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, because a workstation cannot initiate a session with a service provider 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 SAP)
onto the network segment to which it is connected.
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 IPX address.
Like RIP, SAP uses IPX and a medium-access protocol for its transport. Figure 4-6 illustrates the structure of a SAP packet.
Figure 4-6 SAP Packet Structure
A SAP packet contains the following fields:
The ``Operation'' field can specify the following operations:
There can be one or more sets of fields
following the ``Operation'' field.
If the
packet contains information about more than one server, it will
contain more than one set of fields (n sets of fields).
Each SAP
packet can contain information about up to seven servers.
Packet delivery
The successful delivery of a packet over a NetWare network
depends on the proper addressing of the packet.
To send a packet,
the sender must know the full IPX address
(network, node, and socket) of the recipient.
The address is specified in the packet's medium-access
protocol and IPX protocol address fields.
Once the sender has the recipient's
address, it can address the packet.
The way the
MAC header of that packet is addressed, however, depends on
the network's topography.
Specifically, it depends on
whether the sending node and the destination node are separated by a
router.
The effect of network topography on IPX addressing
is discussed in the following sections.
Network interconnection devices
Segments on a network can be interconnected using a:
Figure 4-7 OSI Representations of Network Devices
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 bridge:
Figure 4-8 Sample Transparent Bridge
After examining the packets transmitted on both segments, the bridge 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.
Routers interconnect different network segments. However, unlike bridges, routers, by definition, are network layer devices (see Figure 4-7). In other words, routers receive their instructions for forwarding a packet from one segment to another from a network layer protocol.
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 the external bridge installed at workstations. Novell has officially renamed these two devices ``internal router'' and ``external router''.
NetWare-compatible routers can be configured to interconnect two
or more segments.
Each of these segments, however, must be
assigned a unique network number to distinguish it from other
segments on the network.
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.
For more information on assigning a segment's network number, see
Appendix A, ``Configuration parameters'' in Configuring Network Connections.
Intrasegment packet routing
If the sending node and the destination node are on the
same network segment -- that is, they both have the same IPX
network number -- the sending node addresses the packet in the
following way:
Figure 4-9 shows an example of two nodes that are connected to network number AA.
Figure 4-9 Transmission to Same Network Segment (No Routing Required)
The sending node (node 01) sends a packet to
node 02.
The sending node places node number 02 in the
destination field and node number 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 IPX address
of the receiving node).
The sending node places its own
IPX address of AA, 01, and 4003 in the source address
fields of the IPX header.
Intersegment packet routing
The addressing method depicted in
Figure 4-9
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.
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 packets 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. This RIP request is responded to by the router residing on the sending node's segment with the shortest path to the desired segment; in the response, the router includes its node number.
Once the sending node receives the router's node number, it is prepared to send packets to the destination node. The sending node addresses these packets by placing:
Figure 4-10 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 to which the router is directly connected, the router will:
Table 4-4 Portion of routing information table
---------------------------------------------------------------------------------- Network Hops to Ticks to Immediate address Net Aging number LAN segment LAN segment NIC of forwarding router status timer ---------------------------------------------------------------------------------- 00000001 1 2 A 0 00000002 1 2 B 0 FEED0038 1 20 C R 0 FEED0035 2 3 B 00001B029927 1 000000FF 2 3 A 00001B0349B2 2 FEED0036 3 4 A 00001B0349B2 2Each entry in the routing information table gives the router forwarding information for a network 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 megabyte per second (Token-Ring, Ethernet, Arcnet, and so on), the driver makes the assumption that delivery time is one tick. For remote segments (Tl, 64 KBps, X.25, and asynchronous), the driver will periodically poll to determine the current time delay. For example, 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 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.
For NetWare versions prior to 2.16c, 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
all routes. The fastest route, the one that requires the least number
of ticks, will always be used as the primary route.
NetWare
versions 2.16c and later maintain alternate routes only if these
alternate routes require the same number of ticks to reach the
segment as the primary route.
This procedure reduces the size of the routing information table.
Routing information broadcasts
On a network, 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
network.
To accomplish this, routers transmit a series of
broadcasts from the time they come up until they are brought
down.
Routing information broadcasts can be classified by the time at which they
occur:
A router sends routing information broadcasts to every network segment to which it is directly connected, as illustrated in Figure 4-11.
Figure 4-11 The best information algorithm
The purpose of routing information broadcasts is 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 particular network segment to which the information is being sent.
For example, if the router within server FS2 in Figure 4-11 is going to broadcast routing information 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 FSl and another through FS2.
The best information algorithm also states that routers should not include information about the network segment to which they are sending routing information broadcasts. For example, FS2 would not include information about BB in its broadcast to BB.
Taking these rules into account, the information that FS2 would broadcast to segment BB would be information about segments CC and DD.
When a router is first brought up, it:
Figure 4-12 Sequence used to build and maintain the 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 network remain synchronized.
Because of the 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.
When a router receives information that causes it to change its routing information table, the router immediately passes that information on to its other directly connected network segments, except the segment from which the router received the information. If a new network segment comes up or an existing segment goes down, all the routers on the network will learn about the change in a short period of time.
The primary causes of a change in the network's configuration are file servers or external routers coming up or going down. If a router needs to be brought down, the router will inform its directly connected segments of the fact before discontinuing service. The router issues broadcasts, using the best information algorithm, that indicate that the network segments that the router had made available will no longer be accessible through this router.
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 into 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.
Because this information is new or changed, the routers
that receive the information will pass it on immediately and the
change will quickly permeate the network.
Service advertising
Servers on a NetWare network advertise their
services and IPX addresses
with the Service Advertising Protocol (SAP).
The information that these servers
broadcast is not used directly by clients but, instead, is 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 network
have information about all servers that are active on the
network -- 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 network are exchanging SAP information
properly, each agent's server information table should have
information about all the servers on the network,
thus
providing clients with nearby access to the IPX addresses
of all the servers on the network.
The server information table contains the following fields:
Table 4-5 Novell object types
--------------------------------------------------------- Description Object type (hexadecimal) --------------------------------------------------------- User 1 User group 2 Print queue 3 File server 4 Job server 5 Gateway 6 Print server 7 Archive queue 8 Archive server 9 Job queue A Administration B NAS SNA gateway 21 NACS 23 Remote bridge server 24 Bridge server 26 TCP/IP gateway 27 Gateway 29 Time synchronization server 2D Archive server SAP 2E Advertising print server 47 BTrieve VAP 5.0 48 SQL VAP 4C Xtree network version 4D BTrieve VAP 4.11 50 Print queue user 53 WANcopy utility 72 TES - NetWare for VMS 7A NetWare access server 98 NVT server 9E NetWare 386 107 Communications executive 130 NNS domain 133 NetWare 386 print queue 137 Wildcard FFFF
Figure 4-13 Sequence used to build and maintain the server information table
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
network. 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.
File server addressing
Value-added servers, such as database and print servers, normally
contain only one network adapter and use the address of that
adapter as the address they advertise in their periodic SAP
broadcasts.
In contrast, NetWare file servers 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 differs for 286- and
386-based servers.
Within the 286-based environment, the services of a file server are addressed with respect to its first NIC, A. This convention guarantees consistency because every server will have at least one network adapter installed. Figure 4-14 illustrates this convention.
Figure 4-14 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, as shown in
Figure 4-15.
This different method of addressing requires that an internal
network number be assigned when a NetWare 386-based file server
is brought up.
SCO IPX/SPX requires an internal network number.
Figure 4-15 Addressing of file services on a 386-based NetWare file server
NetWare 386-based servers can be distinguished by a node number of one.
This node number is
assigned to the file services on the internal network number.
Client-server interaction
The NetWare shell facilitates client-server communication 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 is the link between the client (the user
application) and the server.
It 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.
Two programs must be run on the client for it to communicate with the server - NETx.COM and one of two IPX protocol drivers:
The utilities enable you to:
The SCO IPX/SPX graphical utilities can be accessed in the following ways:
A useful feature of the NetWare NVT Monitor is automatic screen refresh which updates the NVT connection display at a regular, user specified, interval. The refresh interval can be controlled using a slider for the amount of time in minutes and seconds between refreshes. Automatic screen refresh can be set using the Set Auto Refresh cascade menu, which is available under the View menu.
The NetWare NVT Monitor's output looks like this:
The NetWare NVT Monitor displays the following:
In a NetWare network, routers periodically emit broadcasts containing their routing information tables, as specified by the NetWare RIP (Routing Information Protocol) standard.
The NetWare RIP Monitor and its command-line alternatives, drouter(PADM) and rrouter(PADM), display the current routing information tables and allow the superuser to reset and update the routing tables. Both of these features can be used to highlight potential problems in a network's configuration.
A useful feature of the NetWare RIP Monitor is automatic screen refresh which updates the routing information display at a regular, user-specified interval. The refresh interval can be controlled using a slider for the amount of time in minutes and seconds between refreshes. Automatic screen refresh can be set using the Set Auto Refresh cascade menu, which is available under the View menu.
If information about known nodes is missing from the routing information table, then there may be problems with the routing information broadcasts. See ``Router operation'' for procedures to remedy this situation.
The NetWare RIP Monitor's output looks like this:
The NetWare RIP Monitor displays the following:
Using this information, it is possible to detect the following situations:
One of the most common errors when adding a host to a network is choosing an internal network number or network number that is not unique. If you have a situation where a host is visible to only a portion of your network, it is likely that the network number(s) have been misconfigured. In this case, compare the output from the NetWare RIP Monitor on a number of different hosts on your network. You should be able to trace the same path to the new host from all the different hosts on your network. This is possible because the network and node number information in the routing information table will either be that of a router, the local host, a host on the network, or the network the host is connected to.
From the command line,
a combination of rrouter
and drouter can monitor the operation
of routing information broadcasts:
rrouter clears and updates the routing information table.
A command-line user can periodically run drouter
to monitor the status of the routing information table
as it is updated by routing information broadcasts,
updating the tables with rrouter if required.
Displaying IPX/SPX and network media interface information (getlan)
The
IPX Configuration Monitor
and its command-line equivalent,
getlan(PADM),
can be used to display the media interface
information for SCO IPX/SPX.
This information can be used to verify the IPX/SPX configuration.
The
IPX Configuration Monitor's
output looks like this:
The IPX Configuration Monitor displays the following:
All LANs should be in state BOUND except the
internal network, which should be UNBOUND.
To start IPX/SPX and NVT,
use the following command line:
/etc/ipx start
The following output is displayed:
Starting IPX/SPX: npsd sapd nvtdTo restart IPX/SPX and NVT (that is, to stop and then start automatically, and to display detailed information on the status of the startup procedure), use the following command line:
You should see output similar to the following:
IPX/SPX Shutdown ... IPX/SPX Shutdown Complete. NPSD: Novell Protocol Suite Streams Architecture daemon. NPSD: Configuring Internal Network: 100 NPSD: Configured Internal Network: 100 NPSD: Configuring: LAN 1 00000099 /dev/net0 NPSD: Configured: LAN 1 00000099 /dev/net0 DLPI 802_2_LLI(E0) NONE NOSRTo save all of this output to a logfile named logfile, modify the command as shown here:NPSD: Lan Network Node Mux ID State Stream NPSD: --- -------- ------------ -------- ------- ------ NPSD: 0 00000100 000000000001 00000000 UNBOUND OK NPSD: 1 00000099 0000C0E1D26B 0000006E IDLE OK NPSD: Spawning the SAP daemon "/etc/sapd" NPSD: Spawning the NVT daemon "/etc/nvtd" NPSD: Including SPX Version 3.0.1 NOVELL Inc. NPSD: Binding XECHO Stream to socket 0002
To stop IPX/SPX and NVT,
use the following command line:
/etc/ipx stop
The following output is displayed:
IPX/SPX Shutdown ... IPX/SPX Shutdown Complete.
The NetWare NVT Login Manager allows users to log into one or more NVT servers simultaneously by selecting the desired servers and pressing the Login button. When the NetWare NVT Login Manager is used in a graphical X-windows environment, one window is opened for each server to which the user logs in. Each window will contain a login prompt for the associated server. When the NetWare NVT Login Manager is run in non-graphical mode (that is, character mode, or "CHARM"), only one server at a time can be logged into. In this case, the window in which the NetWare NVT Login Manager is running will be "taken over" by the remote login session. When the session is complete, control will automatically be passed back to the NetWare NVT Login Manager .
A useful feature of the
NetWare NVT Login Manager
is automatic screen refresh which
updates the display
of available NVT servers at a regular, user specified interval.
The refresh interval can be controlled using a slider for the amount of
time in minutes and seconds between refreshes.
Automatic screen refresh can be set using the
Set Auto Refresh
cascade menu,
which is available under the View menu.
Testing IPX/SPX connections (nping)
After installation or reconfiguration,
one should test for connectivity to the local and remote hosts
using the
nping command,
which sends packets to a specified host and waits for them to be
returned by the host.
One of the first aspects of IPX/SPX operation that should be tested for is the correct operation of the IPX/SPX server itself. The next aspect of operation that should be tested is the ability of the server to communicate with other SCO IPX/SPX or NetWare for UNIX servers on the network. nping can perform both of these tests.
To test for the local host, run nping with the command line:
nping local_host_name
For local_host_name, use the machine name as reported by uname.
If IPX/SPX is performing properly, nping displays output similar to the following:
Received 64 bytes from [60.01.02], seq#=0 time=0 (ms) Received 64 bytes from [60.01.02], seq#=1 time=0 (ms) Received 64 bytes from [60.01.02], seq#=2 time=0 (ms) Received 64 bytes from [60.01.02], seq#=3 time=0 (ms) Received 64 bytes from [60.01.02], seq#=4 time=0 (ms) 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max 0/0/0 ms
If nping does not display the previous output, see ``Daemon operation'' for procedures to remedy this situation.
To test for a remote host, run nping with the following command line:
nping remote_host_name
remote_host_name should be the name of a known server on the network. Note that the remote host must be an SCO host or a NetWare-for-UNIX host. nping cannot currently communicate with NetWare servers or clients. Press <Del> to stop the test.
If IPX/SPX can communicate with the remote host, nping displays output similar to the following:
Received 64 bytes from [50.01.02], seq#=0 time=0 (ms) Received 64 bytes from [50.01.02], seq#=1 time=0 (ms) Received 64 bytes from [50.01.02], seq#=2 time=0 (ms) Received 64 bytes from [50.01.02], seq#=3 time=0 (ms) Received 64 bytes from [50.01.02], seq#=4 time=0 (ms) 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max 0/0/0 msIf nping does not display the previous output, see ``Daemon operation'' for procedures to remedy this situation.
Displaying available NetWare services (showsvcs)
The Service Advertising Protocol daemon (SAPD)
included with SCO IPX/SPX
constantly receives information about the services available on the NetWare
network via SAP broadcasts.
The
NetWare SAP Monitor
and the corresponding
showsvcs(PADM)
command display the SAP
information in a convenient format, allowing selective
display based on server type and/or name.
The output from this command is useful to
ensure that services are available on the network.
A useful feature of the NetWare SAP Monitor is automatic screen refresh which updates the available NetWare services display at a regular, user specified, interval. The refresh interval can be controlled using a slider for the amount of time in minutes and seconds between refreshes. Automatic screen refresh can be set using the Set Auto Refresh cascade menu, which is available under the View menu.
The NetWare SAP Monitor's output looks like this:
The NetWare SAP Monitor
displays the following:
For more information on Novell object types, see Table 4-5.
track
can monitor the operation of service advertising broadcasts.
Run track with the command line:
track on
track starts listing SAP traffic to
the file specified by the parameter sap_track_out
in NPSConfig.
The default output file is /dev/console.
To stop the listing,
run track with the command line:
track off
The track listing looks like this:
IN [00000299:10005AAC41B2] 2:18:59pm TIGER 1 DEMING 2
FRED 1
OUT [00000080:FFFFFFFFFFFF] 2:19:00pm TIGER 2 DEMING 3
OPUS 2 CALVIN 1
OUT [00000299:FFFFFFFFFFFF] 2:19:00pm OPUS 2 CALVIN 1
OUT [00000099:FFFFFFFFFFFF] 2:19:00pm TIGER 2 DEMING 3
OPUS 2 CALVIN 1
OUT [00000199:FFFFFFFFFFFF] 2:19:00pm TIGER 2 DEMING 3
CALVIN 1
IN [00000299:10005AAC41FC] 2:19:00pm OPUS 2 CALVIN 1
IN [00000080:000000000001] 2:19:01pm CALVIN 0
IN [00000199:0000C00FAB13] 2:19:23pm OPUS 1
IN [00000099:0000C0448328] 2:19:33pm FRED 1
OUT [00000080:FFFFFFFFFFFF] 2:19:33pm FRED 2
OUT [00000299:FFFFFFFFFFFF] 2:19:33pm FRED 2
OUT [00000199:FFFFFFFFFFFF] 2:19:33pm FRED 2
IN [00000299:10005AAC41FC] 2:19:33pm FRED 2
It presents the following:
track can monitor the current state of the server information table. The NetWare SAP Monitor and showsvcs can list selected information from the server information table that you can use to monitor and validate the network names, addresses, and services offered by servers on the network.
To display the information currently in
the server information table,
run track with the command line:
track tables
track writes the contents of the server information table to /etc/ipx.d/sapd.out.
The output from track looks like this:
TIGER Type: 009E Hops: 0001 Address: 00000020 000000000001 8063 TIGER Hops: 0001 Timer: 0001 connectedLan: 0001 10005AAC41B2For each known server on the network, track outputs the following information:DEMING Type: 009E Hops: 0002 Address: 00000040 000000000001 8063 DEMING Hops: 0001 Timer: 0001 connectedLan: 0001 10005AAC41B2
OPUS Type: 009E Hops: 0001 Address: 00000060 000000000001 8063 OPUS Hops: 0001 Timer: 0001 connectedLan: 0001 10005AAC41B2
CALVIN Type: 009E Hops: 0000 Address: 00000080 000000000001 8063 CALVIN Hops: 0001 Timer: 0001 connectedLan: 0001 10005AAC41B2
FRED Type: 0004 Hops: 0001 Address: 00000098 000000000001 0451 FRED Hops: 0001 Timer: 0001 connectedLan: 0001 10005AAC41B2
Type 009Eh Count 4 Type 0004h Count 1 total number of server types known 5
This output provides information about the services
offered across the network and the location of these services.
To obtain more information about these services
with the
NetWare SAP Monitor
and showsvcs
utilities, see
``Displaying available NetWare services (showsvcs)''.
Troubleshooting IPX/SPX
The following sections describe:
If you suspect that the IPX protocol is not operating correctly, you can use the following commands to verify its state:
For IPX/SPX to operate correctly, NPSD, SAPD, and NVTD must be running.
To make sure that the daemons are running,
execute the following command lines:
ps -ef | grep npsd
ps -ef | grep nvtd
ps -ef | grep sapd
If there is no output from these commands, these daemons are not running.
To restart the daemons,
execute the following command line:
/etc/ipx restart
If services on the network are inaccessible, then SAPD may not be operating correctly. Use showsvcs to display the services. If services are not displayed, then IPX/SPX may not have been configured correctly.
If LANs on the network are inaccessible, then routers on the network may not be operating correctly. To verify the operation of routers, use the drouter command. If known LANs do not appear in the output of drouter, it is likely that the routers for the missing segments are not operating. For further details, refer to the documentation that came with your routing hardware.
Incorrectly configured LAN adapters are the principal cause of IPX failures. It is essential to verify that all LAN adapters have been installed correctly without any hardware and/or software configuration conflicts. Examine settings for: IRQ, I/O port, DMA, and shared-memory settings (depending on the type of adapter). For further details, refer to Appendix A, ``Configuration parameters'' in Configuring Network Connections, as well as to the documentation that came with your network adapter hardware.
The llistat(ADM) command, provided with the network adapter drivers, can verify the operation of drivers. Execute the following command line:
llistatIn the llistat output, In/Out counts of zero typically point to configuration or installation errors.
The SCO IPX/SPX installation mechanism prevents many potential installation errors. However, it is important to have a clear picture of the network topology prior to software installation. This is particularly important when routers and multiple subnetworks are being configured.
Incorrect specification of internal or subnet network numbers cause host addressing problems. All server network numbers and subnet numbers have to be manually checked for uniqueness. This should be done prior to configuration or installation. It is advisable to establish a numbering convention to distinguish internal (that is, logical) networks from physical subnetworks. This facilitates the interpretation of the outputs from certain utilities, for example, drouter.
The naming of servers, as well as services offered by servers, should be done in a meaningful way. Duplicate names and addresses can cause serious addressing problems. A meaningful naming scheme and corresponding addressing convention reduce potential problems significantly.
Each NVT connection
requires at least one pseudo-tty to service it.
If you are experiencing a high number of failed connections,
make sure that the number of configured pseudo-ttys is not less
than the value of the nvt_max_logins
parameter in NPSConfig.
See
NPSConfig(SFF)
for more information.
If you use a hot-key to bring up DOS when using NVT.EXE for several minutes at a time, the UNIX session may be disconnected. This occurs because the NVT protocol specification states that new connection requests will use existing inactive connections.
Increase the value of the parameter
NVT_KEEP_ALIVE_INTERVAL_TIME
in nvt_tune.h to work around this problem.
Once you have increased this parameter, you will need
to relink the kernel and reboot the system.
For more information, see the
nvt_tune.h(SFF)
manual page.
If the changes made during the reconfiguration
of IPX/SPX do not seem to take effect,
you may have omitted relinking the kernel and/or
restarting IPX/SPX.
When the IPX/SPX configuration is changed
using the Network Configuration Manager, you are informed
when it is necessary to relink the kernel and when
it is simply enough to restart IPX/SPX.
After a configuration change, make sure that the UNIX kernel has
been relinked and the system is rebooted or, if relinking is not required,
that IPX/SPX is restarted with the command line:
/etc/ipx restart
Installing and using the DOS component
The DOS component of SCO IPX/SPX allows users on
DOS workstations to access data served by your
SCO IPX/SPX system. To install the DOS component of IPX/SPX,
you need to:
where path is the directory to which NVT should be copied.
NVT is now copied to your hard drive.
Configuring IPXODI
To configure IPXODI for the chosen LAN adapter
and network type, see the Novell-distributed installation and
configuration notes.
Configuring NVT
To configure NVT, you must
modify AUTOEXEC.BAT to
load IPXODI and NVT
as follows:
where path is the path to the directory where IPXODI is stored.
where path is the path to the directory where NVT is stored.
Configuring terminal emulation software
To configure the terminal emulation software, follow the
installation and configuration instructions supplied by the
terminal emulator vendor. Make sure that the emulation software
is configured to use
INT14 (BIOS)
or INT6B/UB-NETCI.
Command-line options for NVT
The default hot-key used to display the NVT connection window is
<Alt>-T.
If this conflicts with other DOS applications, a new hot-key
can be specified on the NVT command line.
For example, the following command changes the hot-key to
<Alt>-K:
NVT -ALTk
To unload NVT from memory on the DOS client
machine, enter the following command:
NVT -y
To specify the SCO server server_name as the
server to which NVT is supposed to connect,
use the following command:
NVT server_name
These options can be combined. For example, to set the
hot-key to
<Ctrl>-d
and to connect to an SCO host named "data",
use the following command line:
NVT -CTRLd data
Using the DOS component
To start up the DOS component of IPX/SPX, perform the following steps:
NVT LOADED OK
(The active NVT connection will not be dropped during the reboot.)
For more about IPX/SPX
The following books may provide additional useful
information for administrators of IPX/SPX networks: