Troubleshooting Communication Problems

Communication problems are related to network boards, LAN drivers, network performance, and server/workstation communications, as well as to internetwork communications.

General Communication Problems

To diagnose general network communication problems, you should identify whether the following conditions exist:

The server network board is not seated or configured correctly.

The network board cable from the server is faulty.

Cabling on the network is faulty.

The connector closest to the server is faulty.

The RX-Net^TM active hub is off.

The correct Ethernet frame type has not been specified. NetWare 4 defaults to frame type 802.2.

The repeater is off or is nonfunctional.

The cabling is not terminated properly.

Volume SYS: is not mounted.

ISA disk controller boards installed in EISA machines have not been configured.

To resolve general network communication problems, you should perform the following actions:

Check all hubs and repeaters to make sure they are on.

Check the cables for proper termination.

Make sure the server network board is seated properly.

Replace the server network board with a board that works correctly. Make sure the new board has the same jumper settings.

Run VOLUMES at the server console. If volume SYS: is not mounted, mount it. The server does not broadcast to the network until volume SYS: is mounted.

Run CONFIG at the server console to check the configuration of the network boards. Then bring down the server, turn off the power, and check the actual network board settings:

Run CONFIG at the server console to make sure each network board has a LAN protocol bound to it. Network boards cannot broadcast without a protocol.

Run NLIST at a workstation, if possible, to check node addresses. Each node address on the network should be unique. Sometimes you can find the problem by turning off all workstations and turning them on one at a time.

Have a user log in to the network from a workstation. Load MONITOR and choose Connection Information from the Available Options menu.

If the Active Connections list shows the user's login name, the server is receiving and responding to the workstation's request.

If the workstation receives a Server cannot be found error, make sure the server and workstation are using the same frame type.

Replace segments of cable and cabling connections until communication is restored.

Resolving Server Boot Problems After a Network Board Is Installed

To diagnose server boot problems after a network board is installed, you should identify whether the following conditions exist:

The network board is not attached properly to the cable.

The hardware conflicts with other boards, the monitor board, or ports in the server.

The network board is faulty.

To resolve server boot problems after a network board is installed, you should perform the following actions.

Cable the network board to at least one workstation and check the termination.

Make a list of all I/O ports, interrupts, and memory addresses used by the equipment.

Also do the following to identify potential conflicts:

Check the documentation that came with the computer and all installed hardware components.

Make sure no two pieces of hardware are using the same I/O port, interrupt, or memory address.

Make sure that the memory range for the I/O ports and memory addresses do not overlap. If there are conflicts, reconfigure the equipment so that no conflicts exist.

Resolving Problems When Workstations Can't Communicate with a Server

To diagnose problems when workstations cannot communicate with a server, you should identify whether the following conditions exist:

The server's network board is not initializing when the server is brought up because the board is not configured correctly or it has failed.

The server is anticipating the wrong frame type. NetWare 4 uses Ethernet 802.2 as the default frame type for Ethernet LAN drivers that were loaded at the system console. Workstations running earlier versions of NetWare may be using Ethernet 802.3.

Address or interrupt conflicts exist between two boards inside the server or between a board and the computer's hardware.

The server does not have enough packet receive buffers.

A protocol (such as IPX^TM) is not bound to the network board.

The cabling is too close to sources of interference.

Volume SYS: is not mounted.

To resolve problems when workstations cannot communicate with a server, you should perform the following actions.

Make sure all network connectors (including transceivers and repeaters) are installed and the cable is attached securely.

Make sure all network boards are seated firmly and the cabling connections are in place.

Make sure the network cable is terminated properly. Many network boards send a broadcast message during initialization and will hang if the network is not cabled or terminated properly.

Check cabling for interference from fluorescent lights, microwaves, radar, X rays, and copy machines. Either move the cable or shield it from the source of interference.

Run VOLUMES at the server console to ensure that volume SYS: is mounted. Volume SYS: must be mounted before the server can advertise its name to the network.

Run CONFIG at the server console to see what settings appear on the screen. Then check network board configurations in the server. Be sure the network board configurations match the settings that appear when you run CONFIG.

Check the workstation frame types to see that they match those of the server.

Check node address settings on all server and workstation network boards. Each address should be unique.

Check all IPX internal and external network numbers. Each server and cabling system should have a unique IPX external network number.

Make sure no two boards in the server are using the same I/O port, memory address, or interrupt.

Bind the LAN driver (TRXNET, NE1000^TM, TOKEN, etc.) to IPX (or another communication protocol).

If you have a lot of network traffic, increase the maximum number of packet receive buffers. (See SET in Utilities Reference.)

Resolving Communication Problems Between Servers

To diagnose communication problems between servers, you should identify whether the following conditions exist:

The hardware settings in the server are incorrect.

The IPX internal/external network numbers conflict.

The Novell Directory database is corrupted.

Frame types are different.

The router is filtering out the IPX external network number.

To resolve communication problems between servers, you should perform the following actions:

Check the IPX internal network number for the server and the IPX external network number for the cabling.
When multiple servers share the same cabling system (called a multiserver network), all servers must have the same IPX external network number. However, the servers must have unique IPX internal network numbers and unique node numbers.

When network cabling systems are connected through routers (internal or external), each cabling system must have a unique IPX external network number. NetWare 4 servers must also have a unique IPX internal network number apart from the cabling.

The unique IPX external network number is the first item read in a packet sending/receiving interaction.

Reset the router with the RESET ROUTER console command.

Check the cabling system for faulty termination.

Bring down all servers except one. Reset its router with RESET ROUTER. Bring up each server, one at a time, establishing communications with it before bringing up the next one. Run DISPLAY NETWORKS to check for duplicate IPX external network numbers as each server is booted.

Run DSREPAIR.

Load FILTCFG.NLM at each server and verify that SAP traffic is being routed.

Resolving Slow Server Response

To diagnose slow server response problems, you should identify whether the following conditions exist:

The workstation network board is slow or faulty.

Network cabling is faulty.

The server network board is slow or faulty.

Too many users are using the network.

The server speed is not set to the highest speed.

The server hard disk is slow or faulty.

The server is low on memory.

The volume has too many deleted files that have not been purged.

Network traffic is extremely high.

The cabling system is experiencing too much interference.

A hard disk has failed or is failing.

Insufficient directory buffers, cache buffers, or packet receive buffers have been allocated.

An EISA controller board needs to be configured to use interrupts.

To resolve slow server response problems, you should perform the following actions.

Check the computer's documentation for switch information. Set the CPU speed to its highest setting. Use SPEED to verify that the CPU is running at the appropriate speed.

If a workstation or the server seems slow, insert a new network board into the slow computer to check performance. If the speed is still below normal, reinstall the original network board and replace the cable attaching the workstation or server to the network.

Load MONITOR to check the status of packet receive buffers and service processes. Compare their values to the maximum allowable value.
Use SET to increase the values for the following parameters if your system is at the maximum value: Maximum Service Processes and Maximum Packet Receive Buffers.

(For additional ideas, see Assessing Server RAM.)

Load MONITOR and check the Hot Fix^TM status of all hard disks. Verify that all mirrored disks are still mirrored.

Run the FILER text utility or the NetWare Administrator graphical utility to purge deleted files. Or set the Purge attribute on files you want to be purged immediately after being deleted.
For more information, see Managing Directories, Files, and Applications.

Load MONITOR and check the LAN driver statistics. If you have more than one network board, compare the boards' Total Packets Sent statistics. If one board is receiving most of the traffic, recable the network so that the boards have equal loads.

If you are on a multiserver network or an internetwork, recable the system with a backbone to reduce network traffic. See Network backbone in Concepts for a description of a backbone.

Check the cabling for interference from fluorescent lights, microwaves, radar, X rays, and copy machines. Either move the cable or shield it from the source of interference.

Resolving Periodic Loss of Connection

To diagnose periodic loss of connection problems, you should identify whether the following conditions exist:

A network board in either the server or a workstation is faulty.

A user on the network is using an old NetWare shell file (for example, NETX.COM).

Two workstations have the same node number.

The cabling system is not terminated properly.

To resolve periodic loss of connection problems, you should perform the following actions.

Run NLIST to make sure all node numbers are unique. At a DOS workstation, type

NLIST USER /A <Enter>

Check all boot files. Make sure all users are using the latest version of the workstation software.

Check the cabling for improper termination, loose connections, and faulty components.

Use a LAN analyzer product to check the network boards, cables, and packets. (NetWare Care^TM and LANalyzer^® products are available from your Novell Authorized Reseller representative.) Replace faulty boards and cables.

Refer to your network hardware's documentation to review the cabling specifications for your cabling system. Make sure your system is in compliance with all the specifications.

Set the console to display all workstation connections cleared by the watchdog. (See SET in Utilities Reference.)
If workstations are being cleared by the watchdog, check all network boards and the entire cabling system between the workstations and the server. Check for faulty cables, improper termination, and faulty hubs.

Resolving ARCnet-Specific Software Problems

To diagnose ARCnet-specific software problems, you should identify whether the following conditions exist:

The LAN driver being used is not specifically designed for the ARCnet* network board.

The LAN driver is outdated.

Receive buffer sizes conflict.

Node numbers are illegal or conflicting.

The monitor board settings conflict with the network board settings.

To resolve ARCnet-specific software problems, you should perform the following actions.

Load the LAN driver that matches the network board installed.

Contact the vendor for an updated version of the LAN driver.

Run NLIST. Make sure that all client workstation addresses are unique and that no station uses address 0. At a DOS workstation, type
NLIST USER /A <Enter>

If the monitor is blank when the network board is in the workstation, the monitor could be using interrupt 2. Try setting the network board to an option that does not use interrupt 2; then edit the NET.CFG file to reconfigure the workstation's IPXODI.COM file.
(See the hardware documentation for a list of supported options for your board.)

Resolving ARCnet-Specific Hardware Problems

To diagnose ARCnet-specific hardware problems, you should identify whether the following conditions exist:

The passive or active hubs are faulty.

The network boards are faulty.

Improper cable lengths are connected to passive or active hubs.

Two passive hubs are connected together.

A passive hub is terminated improperly.

To resolve ARCnet-specific hardware problems, you should perform the following actions.

Check the fuses in all active hubs. Replace faulty fuses.

If active hub lights blink, bad packets are being sent on the network. Check for conflicting node addresses, bad network boards, and improperly terminated passive hubs.

Check all passive hubs for proper termination.

Check the lengths of the cables connecting active and passive hubs to make sure they are within specifications. (See the hardware documentation to review the cabling specifications for your network board.)

Check the cabling system for loopbacks, such as a cable from an active hub that attaches back to the active hub rather than to a workstation. Make sure that two passive hubs are not cabled to each other.

Resolving Ethernet-Specific Software Problems

To diagnose Ethernet-specific software problems, you should identify whether the following conditions exist:

The workstation and the server are using two different Ethernet frame types.

The monitor board settings conflict with the network board settings.

To resolve Ethernet-specific software problems, you should perform the following actions.

Make sure that the server LAN drivers and the workstation LAN drivers have been configured for the same Ethernet frame type. (See Frame in Concepts for information on frame types.) Configure the workstations for the appropriate frame type.

For instructions on configuring workstation LAN drivers, see the Novell Client documentation.

See LOAD in Utilities Reference for the parameter you need to configure the Ethernet LAN driver in the NetWare server.

Some VGA boards use interrupt 2. If the monitor is blank when the network board is installed, set the network board to an option that does not use interrupt 2; then edit the NET.CFG file to reconfigure the workstation software.

(See the appropriate hardware documentation for a list of supported options for your network board.)

For workstation LAN drivers or specialized software that set the node address for the client workstation's network board, run NLIST to make sure that each network board has a unique node number. At a DOS workstation, type

NLIST USER /A <Enter>

Resolving Ethernet-Specific Hardware Problems

To diagnose Ethernet-specific hardware problems, you should identify whether the following conditions exist:

T-connectors are not terminated properly.

The network board is set up for one type of cabling, but it is connected to a different type (such as thick Ethernet instead of thin Ethernet).

Hardware conflicts exist between the workstation and the network board.

To resolve Ethernet-specific hardware problems, you should perform the following actions.

Check for faulty termination. Each T-connector that has only one cable attached to it must be terminated. Each trunk must be terminated with a grounded terminator.

Check the network boards. Make sure that the board is set for the type of cabling (thick or thin Ethernet) you are using.

Check terminators with an ohmmeter for a resistance of 48 to 52 ohms. Replace any terminators that do not fall within the specified range.

Resolving Token Ring-Specific Software Problems

To diagnose token ring-specific software problems, you should identify whether the following conditions exist:

IBM LAN Support has not been loaded at the workstations.

The LAN driver software is not loaded.

To resolve token ring-specific software problems, you should perform the following actions.

Check for duplicate client workstation addresses if you have used DOS ODI^TM drivers or specialized software to set the node addresses.

Run DXMAID at each workstation, and set LAN Support to load automatically when the workstation is booted. The DXMAID program is on the IBM LAN Support Program diskette.

Resolving Token Ring-Specific Hardware Problems

To diagnose token ring-specific hardware problems, you should identify whether the following conditions exist:

A MAU (Multistation Access Unit) is faulty or has been set improperly.

A faulty token ring adapter has been installed in a workstation or server.

To resolve token ring-specific hardware problems, you should perform the following actions.

Reset the MAU.

Check the MAU for faulty fuses, power problems, and bad ports.

Check for faulty token ring adapters by running the DXMAID program found on the IBM LAN Support Program diskette.

Check for breaks in the daisy-chained MAUs.