Basic Network Troubleshooting.

If a computer is unable to connect to a network or see other computers on a network, it may be necessary to troubleshoot the network. A network may not work because of any of the below reasons.

1. Network card not connected properly. 2. Bad network card drivers or software settings.

3. Firewall preventing computers from seeing each other.

4. Connection related issues.

5. Bad network hardware.

Basic network troubleshooting.

Issue:

Basic network troubleshooting.

Cause:

If a computer is unable to connect to a network or see other computers on a network, it may be necessary to troubleshoot the network. A network may not work because of any of the below reasons.

6. Network card not connected properly. 7. Bad network card drivers or software settings.

8. Firewall preventing computers from seeing each other.

9. Connection related issues.

10.Bad network hardware.

Solution:

Because of the large variety of network configurations, operating systems, setup, etc... not all of the below information may apply to your network or operating system. If your computer is connected to a company or large network, or you are not the administrator of the network, it is recommended that if you are unable to resolve your issues after following the below

66 1

recommendations that you contact the network administrator or company representative.

Note: If you are being prompted for a Network password and do not know the password, Computer Hope is unable to assist users with obtaining a new or finding out the old password.

Verify connections / LEDs

Verify that the network cable is properly connected to the back of the computer. In addition, when checking the connection of the network cable, ensure that the LEDs on the network are properly illuminated. For example, a network card with a solid green LED or light usually indicates that the card is either connected or receiving a signal. Note: generally, when the green light is flashing, this is an indication of data being sent or received.

If, however, the card does not have any lights or has orange or red lights, it is possible that either the card is bad, the card is not connected properly, or that the card is not receiving a signal from the network.

If you are on a small or local network and have the capability of checking a hub or switch, verify that the cables are properly connected and that the hub or switch has power.

Adapter resources

Ensure that if this is a new network card being installed into the computer that the card's resources are properly set and/or are not conflicting with any hardware in the computer.

Users who are using Windows 95, 98, ME, 2000 or XP, verify that Device Manager has no conflicts or errors. Additional help and information about Device Manager and resources can be found on our Device Manager page.

Adapter functionality

Verify that the network card is capable of pinging or seeing itself by using the ping command. Windows / MS-DOS users ping the computer from a MS-DOS prompt. Unix / Linux variant users ping the computer from the shell.

To ping the card or the localhost, type either

ping 127.0.0.1

66 2

or

ping localhost

This should show a listing of replies from the network card. If you receive an error or if the transmission failed, it is likely that either the network card is not physically installed into the computer correctly, or that the card is bad.

Protocol

Verify that the correct protocols are installed on the computer. Most networks today will utilize TCP/IP, but may also utilize or require IPX/SPX and NetBEUI.

Additional information and help with installing and reinstalling a network protocol can be found on document CH000470.

When the TCP/IP protocol is installed, unless a DNS server or other computer assigns the IPX address, the user must specify an IP address as well as a Subnet Mask. To do this, follow the below instructions.

1. Click Start / Settings / Control Panel 2. Double-click the Network icon

3. Within the configuration tab double-click the TCP/IP protocol icon. Note: Do not click on the PPP or Dial-Up adapter, click on the network card adapter.

4. In the TCP/IP properties click the IP address tab

5. Select the option to specify an IP address

6. Enter the IP address and Subnet Mask address, an example of such an address could be:

IP Address: 102.55.92.1Subnet Mask: 255.255.255.192

7. When specifying these values, the computers on the network must all have the same Subnet Mask and have a different IP Address. For example, when using the above values on one computer you would want to use an IP address of 102.55.92.2 on another computer and then specify the same Subnet Mask.

66 3

Firewall

If your computer network utilizes a firewall, ensure that all ports required are open. If possible, close the firewall software program or disconnect the computer from the firewall to ensure it is not causing the problem.

Additional time

In some cases it may take a computer some additional time to detect or see the network. If after booting the computer you are unable to see the network, give the computer 2-3 minutes to detect the network. Windows users may also want to try pressing the F5 (refresh) key when in Network Neighborhood to refresh the network connections and possibly detect the network.

Additional troubleshooting

If after following or verifying the above recommendations you are still unable to connect or see the network, attempt one or more of the below recommendations.

If you have installed or are using TCP/IP as your protocol you can attempt to ping another computer's IP address to verify if the computer is able to send and receive data. To do this, Windows or MS-DOS users must be at a prompt and Linux / Unix variant users must open or be at a shell.

Once at the prompt assuming, that the address of the computer you wish to attempt to ping is 102.55.92.2, you would type:

ping 102.55.92.2

If you receive a response back from this address (and it is a different computer), this demonstrates that the computer is communicating over the network. If you are still unable to connect or see the network, it is possible that other issues may be present.

Another method of determining network issues is to use the tracert command if you are a MS-DOS or Windows user or the traceroute command if you are a Linux / Unix variant user. To use this command you must be at the command prompt or shell.

Once at the prompt, assuming that the address is again 102.55.92.2, type:

66 4

tracert 102.55.92.2

or

traceroute 102.55.92.2

This should begin listing the hops between the computer and network devices. When the connection fails, determine which device is causing the issue by reviewing the traceroute listing.

Network Troubleshooting Overview

These sections introduce you to the concepts and practice of network troubleshooting:

Introduction to Network Troubleshooting Network Troubleshooting Framework

Troubleshooting Strategy

Network troubleshooting means recognizing and diagnosing networking problems with the goal of keeping your network running optimally. As a network administrator, your primary concern is maintaining connectivity of all devices (a process often called fault management). You also continually evaluate and improve your network's performance. Because serious networking problems can sometimes begin as performance problems, paying attention to performance can help you address issues before they become serious.

About Connectivity Problems

Connectivity problems occur when end stations cannot communicate with other areas of your local area network (LAN) or wide area network (WAN). Using management tools, you can often fix a connectivity problem before users even notice it. Connectivity problems include:

Loss of connectivity - When users cannot access areas of your network, your organization's effectiveness is impaired. Immediately correct any connectivity breaks.

Intermittent connectivity - Although users have access to network resources some of the time, they are still facing periods of downtime. Intermittent connectivity problems can indicate that your network is on the verge of a major break. If connectivity is erratic, investigate the problem immediately.

Timeout problems - Timeouts cause loss of connectivity, but are often associated with poor network performance.

66 5

About Performance Problems

Your network has performance problems when it is not operating as effectively as it should. For example, response times may be slow, the network may not be as reliable as usual, and users may be complaining that it takes them longer to do their work. Some performance problems are intermittent, such as instances of duplicate addresses. Other problems can indicate a growing strain on your network, such as consistently high utilization rates.

If you regularly examine your network for performance problems, you can extend the usefulness of your existing network configuration and plan network enhancements, instead of waiting for a performance problem to adversely affect the users' productivity.

Solving Connectivity and Performance Problems

When you troubleshoot your network, you employ tools and knowledge already at your disposal. With an in-depth understanding of your network, you can use network software tools, such as "Ping", and network devices, such as "Analyzers", to locate problems, and then make corrections, such as swapping equipment or reconfiguring segments, based on your analysis.

Transcend® provides another set of tools for network troubleshooting. These tools have graphical user interfaces that make managing and troubleshooting your network easier. With "Transcend Applications", you can:

Baseline your network's normal status to use as a basis for comparison when the network operates abnormally

Precisely monitor network events

Be notified immediately of critical problems on your network, such as a device losing connectivity

Establish alert thresholds to warn you of potential problems that you can correct before they affect your network

Resolve problems by disabling ports or reconfiguring devices

Network Troubleshooting Framework

The International Standards Organization (ISO) Open Systems Interconnect (OSI) reference model is the foundation of all network communications. This seven-layer structure provides a clear picture of how network communications work.

66 6

Protocols (rules) govern communications between the layers of a single system and among several systems. In this way, devices made by different manufacturers or using different designs can use different protocols and still communicate.

By understanding how network troubleshooting fits into the framework of the OSI model, you can identify at what layer problems are located and which type of troubleshooting tools to use. For example, unreliable packet delivery can be caused by a problem with the transmission media or with a router configuration. If you are receiving high rates of "FCS Errors" and "Alignment Errors", which you can monitor with Status Watch, then the problem is probably located at the physical layer and not the network layer. Figure 1 shows how to troubleshoot the layers of the OSI model.

Table 5 describes the data that the network management tools can collect as it relates to the OSI model layers.

Table 5 Network Data and the OSI Model Layers

Layer Data Collected TranscendcNCS Tool Used

Application

Presentation

Session

Transport

Protocol information and other Remote Monitoring (RMON) and RMON2 data

LANsentry Manager

Traffix Manager (for more detail)

Network Routing information

Status Watch

LANsentry Manager(for more detail)

Traffix Manager(for more detail)

Data Link Traffic counts and other packet breakdowns

Status Watch

LANsentry Manager(for more detail)

Physical Error counts Status Watch

Figure 1 OSI Reference Model and Network Troubleshooting

66 7

Troubleshooting Strategy

How do you know when you are having a network problem? The answer to this question depends on your site's network configuration and on your network's normal behavior. See "Knowing Your Network" for more information.

If you notice changes on your network, ask the following questions:

Is the change expected or unusual? Has this event ever occurred before?

Does the change involve a device or network path for which you already have a backup solution in place?

66 8

Does the change interfere with vital network operations?

Does the change affect one or many devices or network paths?

After you have an idea of how the change is affecting your network, you can categorize it as critical or noncritical. Both of these categories need resolution (except for changes that are one-time occurrences); the difference between the categories is the time that you have to fix the problem.

By using a strategy for network troubleshooting, you can approach a problem methodically and resolve it with minimal disruption to network users. It is also important to have an accurate and detailed map of your current network environment. Beyond that, a good approach to problem resolution is:

Recognizing Symptoms Understanding the Problem

Identifying and Testing the Cause of the Problem

Solving the Problem

Recognizing Symptoms

The first step to resolving any problem is to identify and interpret the symptoms. You may discover network problems in several ways. Users may complain that the network seems slow or that they cannot connect to a server. You may pass your network management station and notice that a node icon is red. Your beeper may go off and display the message: WAN connection down.

User Comments

Although you can often solve networking problems before users notice a change in their environment, you invariably get feedback from your users about how the network is running,

such as:

They cannot print. They cannot access the application server.

It takes them much longer to copy files across the network than it usually does.

They cannot log on to a remote server.

66 9

When they send e-mail to another site, they get a routing error message.

Their system freezes whenever they try to Telnet.

Network Management Software Alerts

Network management software, as described in "Your Network Troubleshooting Toolbox", can alert you to areas of your network that need attention. For example:

The application displays red (Warning) icons. Your weekly Top-N utilization report (which indicates the 10 ports with the highest utilization

rates) shows that one port is experiencing much higher utilization levels than normal.

You receive an e-mail message from your network management station that the threshold for broadcast and multicast packets has been exceeded.

These signs usually provide additional information about the problem, allowing you to focus on the right area.

Analyzing Symptoms

When a symptom occurs, ask yourself these types of questions to narrow the location of the problem and to get more data for analysis:

To what degree is the network not acting normally (for example, does it now take one minute to perform a task that normally takes five seconds)?

On what subnetwork is the user located?

Is the user trying to reach a server, end station, or printer on the same subnetwork or on a different subnetwork?

Are many users complaining that the network is operating slowly or that a specific network application is operating slowly?

Are many users reporting network logon failures?

Are the problems intermittent? For example, some files may print with no problems, while other printing attempts generate error messages, make users lose their connections, and cause systems to freeze.

Understanding the Problem

Networks are designed to move data from a transmitting device to a receiving device. When communication becomes problematic, you must determine why data are not traveling as

66 10

expected and then find a solution. The two most common causes for data not moving reliably from source to destination are:

The physical connection breaks (that is, a cable is unplugged or broken). A network device is not working properly and cannot send or receive some or all data.

Network management software can easily locate and report a physical connection break (layer 1 problem). It is more difficult to determine why a network device is not working as expected, which is often related to a layer 2 or a layer 3 problem.

To determine why a network device is not working properly, look first for:

Valid service - Is the device configured properly for the type of service it is supposed to provide? For example, has Quality of Service (QoS), which is the definition of the transmission parameters, been established?

Restricted access - Is an end station supposed to be able to connect with a specific device or is that connection restricted? For example, is a firewall set up that prevents that device from accessing certain network resources?

Correct configuration - Is there a misconfiguration of IP address, subnet mask, gateway, or broadcast address? Network problems are commonly caused by misconfiguration of newly connected or configured devices. See "Manager-to-Agent Communication" for more information.

Identifying and Testing the Cause of the Problem

After you develop a theory about the cause of the problem, test your theory. The test must conclusively prove or disprove your theory.

Two general rules of troubleshooting are:

If you cannot reproduce a problem, then no problem exists unless it happens again on its own. If the problem is intermittent and you cannot replicate it, you can configure your network

management software to catch the event in progress.

For example, with "LANsentry Manager", you can set alarms and automatic packet capture filters to monitor your network and inform you when the problem occurs again. See "Configuring Transcend NCS" for more information.

Although network management tools can provide a great deal of information about problems and their general location, you may still need to swap equipment or replace components of your network until you locate the exact trouble spot.

66 11

After you test your theory, either fix the problem as described in "Solving the Problem" or develop another theory.

Sample Problem Analysis

This section illustrates the analysis phase of a typical troubleshooting incident.

On your network, a user cannot access the mail server. You need to establish two areas of information:

What you know - In this case, the user's workstation cannot communicate with the mail server. What you do not know and need to test -

Can the workstation communicate with the network at all, or is the problem limited to communication with the server? Test by sending a "Ping" or by connecting to other devices.

Is the workstation the only device that is unable to communicate with the server, or do other workstations have the same problem? Test connectivity at other workstations.

If other workstations cannot communicate with the server, can they communicate with other network devices? Again, test the connectivity.

The analysis process follows these steps:

1 .   Can the workstation communicate with any other device on the subnetwork?

If no, then go to step 2. If yes, determine if only the server is unreachable.

If only the server cannot be reached, this suggests a server problem. Confirm by doing step 2.

If other devices cannot be reached, this suggests a connectivity problem in the network. Confirm by doing step 3.

2 .   Can other workstations communicate with the server?

If no, then most likely it is a server problem. Go to step 3. If yes, then the problem is that the workstation is not communicating with the subnetwork. (This

situation can be caused by workstation issues or a network issue with that specific station.)

3 .   Can other workstations communicate with other network devices?

If no, then the problem is likely a network problem.

66 12

If yes, the problem is likely a server problem.

When you determine whether the problem is with the server, subnetwork, or workstation, you can further analyze the problem, as follows:

For a problem with the server - Examine whether the server is running, if it is properly connected to the network, and if it is configured appropriately.

For a problem with the subnetwork - Examine any device on the path between the users and the server.

For a problem with the workstation - Examine whether the workstation can access other network resources and if it is configured to communicate with that particular server.

Equipment for Testing

To help identify and test the cause of problems, have available:

A laptop computer that is loaded with a terminal emulator, TCP/IP stack, TFTP server, CD-ROM drive (to read the online documentation), and some key network management applications, such as LANsentry® Manager. With the laptop computer, you can plug into any subnetwork to gather and analyze data about the segment.

A spare managed hub to swap for any hub that does not have management. Swapping in a managed hub allows you to quickly spot which port is generating the errors.

A single port probe to insert in the network if you are having a problem where you do not have management capability.

Console cables for each type of connector, labeled and stored in a secure place.

Solving the Problem

Many device or network problems are straightforward to resolve, but others yield misleading symptoms. If one solution does not work, continue with another.

A solution often involves:

Upgrading software or hardware (for example, upgrading to a new version of agent software or installing Gigabit Ethernet devices)

Balancing your network load by analyzing:

What users communicate with which servers

What the user traffic levels are in different segments

Based on these findings, you can decide how to redistribute network traffic.

66 13

Adding segments to your LAN (for example, adding a new switch where utilization is continually high)

Replacing faulty equipment (for example, replacing a module that has port problems or replacing a network card that has a faulty jabber protection mechanism)

To help solve problems, have available:

Spare hardware equipment (such as modules and power supplies), especially for your critical devices

A recent backup of your device configurations to reload if flash memory gets corrupted (which can sometimes happen due to a power outage)

Your Network Troubleshooting Toolbox

A robust network troubleshooting toolbox consists of items (such as network management applications, hardware devices, and other software) to recognize, diagnose, and solve networking problems. It contains:

Transcend Applications Network Management Platforms

3Com SmartAgent Embedded Software

Other Commonly Used Tools

Transcend management software is optimized for managing 3Com devices and their attached networks. However, some applications, such as LANsentry Manager, can manage any vendor's networking equipment that complies with the Remote Monitoring (RMON) Management Information Base (MIB).

This section describes these Transcend applications, which you can use to troubleshoot your network:

Transcend Central Status Watch

Address Tracker

LANsentry Manager

Traffix Manager

Device View

66 14

Transcend Central

Start with Transcend Central, which is an asset management and device grouping application, to understand what your network consists of and to control the Transcend NCS network management troubleshooting tools. Transcend Central is available as both a native Windows application and a Java application that you can access using a Web browser.

Using Transcend Central for troubleshooting, you can:

Display an inventory of device, module, and port information. Group devices to make your troubleshooting tasks easier. By managing a collection of devices,

you can simultaneously perform the same tasks on each device in a group and locate physical or logical problems on your network.

Launch Transcend NCS applications, including some of your primary Transcend NCS troubleshooting tools:

Status Watch includes Web Reporter (from the Java version)

Address Tracker

LANsentry Manager

Traffix Manager

Device View

Status Watch

The Status Watch applications manage 3Com devices and their attached networks. Status Watch applications primarily poll for "MIB-II" data. This is a performance monitoring application that allows you to monitor the operational status of your network devices and quickly identify any problems that require your attention. It works in conjunction with Web Reporter. .

Web Reporter

Web Reporter is a data-reporting application that runs in a World Wide Web (WWW) browser. It generates reports from data that Status Watch collects, allowing you to compare network statistics against a baseline.

Address Tracker

Address Tracker is an address collection and discovery application that:

Polls managed devices for all MAC addresses

66 15

Polls managed devices and routers for IP addresses to perform MAC-to-IP address translation

Uses Device View to disable troublesome ports

LANsentry Manager

LANsentry Manager is a set of integrated applications that displays and explores the real-time and historical data that RMON-compliant devices (probes) on the network capture. LANsentry Manager uses SNMP polling to gather RMON and RMON2 data from the probes.

Use LANsentry Manager to:

Monitor current performance of network segments See trends over time

Spot signs of current problems

Configure alarms to monitor for specific events

Capture packets and display their contents

LANsentry Manager works with any device (from 3Com or other vendors) that supports the "RMON MIB" or the "RMON2 MIB".

Traffix Manager

Traffix Manager is a performance-monitoring application that provides information about layer 2 (RMON) and layer 3 conversations between nodes. It helps you to assess traffic patterns on your network. Traffix Manager:

Monitors all the stations that the RMON2-compliant probes encounter on your network Captures and stores RMON and RMON2 data for your network's protocols and applications

Displays traffic between stations in user-defined views of the network

Graphs current or historical data on the devices selected

Delivers reports for user-specified stations and time periods as postscript to your printer or as HTML to your Web server

Launches LANsentry Manager tools for in-depth analysis of a station or a conversation between stations

You can use Traffix Manager to:

66 16

Know your network - Understand overall flow patterns and interactions between systems, and determine how your network is really being used at the application level.

Optimize your network - Gain an insight into traffic and application usage trends to help you optimize the use and placement of current network resources and make wise decisions about capacity planning and network growth.

Traffix Manager works with any device (from 3Com or other vendors) that supports the "RMON2 MIB".

Device View

The Device View application is a device configuration tool. When you troubleshoot your network, you can use Device View to determine or change a device's configuration. You can also use Device View to look at a device's statistics and to set alarms.

Device View manages only 3Com devices.

Network Management Platforms

As part of your troubleshooting toolbox, your network management platform is the first place to go to view the overall health of your network. With the platform, you can understand the logical configuration of your network and configure views of your network to understand how devices work together and the role that they play in the users' work. The network management platform that supports your Transcend software installation can provide valuable troubleshooting tools. Transcend runs on several platforms within the NT and UNIX environments.

The platform discovers the devices. Transcend imports that information from the platform to populate the core database. Unless you are rediscovering, the user must manually update the platform

Using this device database, a map displays the graphical representation of your network. Each device on your network appears as a symbol (icon) on the map. You can configure views of your network to show devices on the same subnetworks or floors.

You can monitor network performance and diagnose network performance and connectivity problems. You can also:

Take a snapshot of your network in its normal state. The snapshot records the state of your network at a particular instant. If you later have network performance problems, you can compare the current state of your network to the snapshot.

Quickly determine the connectivity status of a device by noting the color of its map symbol. Red usually means that communication with a device has ceased.

66 17

Diagnose connectivity problems by determining whether two devices can communicate. If they can communicate, then examine the route between the devices, the number of packets that were sent and lost, and the roundtrip time between the two devices.

Manage MIB information (for example, collecting and storing MIB data for trend analysis and graphing) using MIB queries. Transcend compiles MIBs and allows you to navigate up and down the "MIB Tree" to retrieve MIB objects from devices. You can set thresholds for MIB data and generate events when a threshold is exceeded.

Configure the software to act on certain events. The Event Categories window informs you of any unexpected events (which arrive in the form of traps).

For more information, see the documentation that is shipped with your software.

3Com SmartAgent Embedded Software

Traditional Simple Network Management Protocol (SNMP) management places the burden of collecting network management information on the management station. In this traditional model, software agents collect information about throughput, record errors or packet overflows, and measure performance based on established thresholds. Through a polling process, agents pass this information to a centralized network management station whenever they receive an SNMP query. Management applications then make the data useful and alert the user if there are problems on the device.

As a useful companion to traditional network management methods, 3Com's SmartAgent® technology places management intelligence into the software agent that runs within a 3Com device. This scalable solution reduces the amount of computational load on the management station and helps minimize management-related network traffic.

SmartAgent software, which uses the "RMON MIB", is self-monitoring, collecting and analyzing its own statistical, analytical, and diagnostic data. In this way, you can conduct network management by exception - that is, you are notified only if a problem occurs. Management by exception is unlike traditional SNMP management, in which the management software collects all data from the device through polling.

SmartAgent software works autonomously and reports to the network management station whenever an exceptional network event occurs. The software can also take direct action without involving the management station. Devices that contain SmartAgent software may be able to:

Perform broadcast throttling to minimize the flow of broadcast traffic on your network Monitor the ratio of good frames to bad frames

Switch a resilient link pair to the standby path if the primary path corrupts frames

66 18

Report if traffic on vital segments drops below minimum usage levels

Disable a port for five seconds to clear problems, and then automatically reconnect it

The Transcend NCS applications LANsentry Manager and Traffix Manager make RMON data that the SmartAgent software collect more usable by summarizing and correlating important information.

Other Commonly Used Tools

These commonly used tools can also help you troubleshoot your network:

Network software, such as Ping, Telnet, and FTP and TFTP. You can use these applications to troubleshoot, configure, and upgrade your system.

Network monitoring devices, such as Analyzers and Probes.

Tools, such as Cable Testers, for working on physical problems.

Ping

Packet Internet Groper (Ping) allows you to quickly verify the connectivity of your network devices. Ping attempts to transmit a packet from one device to a station on the network, and listens for the response to ensure that it was correctly received. You can validate connections on the parts of your network by pinging different devices:

A successful response indicates that a valid network path exists between your station and the remote host and that the remote host is active.

Slower response times than normal can indicate that the path is congested or obstructed.

A failed response indicates that a connection is broken somewhere; use the message to help locate the problem. See Tips on Interpreting Ping Messages.

Strategies for Using Ping

Follow these strategies for using Ping:

Ping devices when your network is operating normally so that you have a performance baseline for comparison. See "Identifying Your Network's Normal Behavior" for more information.

Ping by IP address when:

You want to test devices on different subnetworks. This method allows you to Ping your network segments in an organized way, rather than having to remember all the hostnames and locations.

66 19

Your Domain Name System (DNS) server is down and your system cannot look up host names properly. You can Ping with IP addresses even if you cannot access hostname information.

Ping by hostname when you want to identify DNS server problems.

To troubleshoot problems that involve large packet sizes, Ping the remote host repeatedly, increasing the packet size each time.

To determine if a link is erratic, perform a continuous Ping (using ping -s on UNIX), which indicates the time that it takes the device to respond to each Ping.

To determine a route taken to a destination, use the trace route function (tracert).

Consider creating a Ping script that periodically sends a Ping to all necessary networking devices. If a Ping failure message is received, the script can perform some action to notify you of the problem, such as paging you.

Use the Ping functions of your network management platform. For example, in your HP OpenView map, select a device and click the right mouse button to gain access to ping functions.

Tips on Interpreting Ping Messages

Use the following ping failure messages to troubleshoot problems:

No reply from <destination>

Indicates that the destination routes are available but that there is a problem with the destination itself.

<destination> is unreachable

Indicates that your system does not know how to get to the destination. This message means either that routing information to a different subnetwork is unavailable or that a device on the same subnetwork is down.

ICMP host unreachable from gateway

Indicates that your system can transmit to the target address using a gateway, but that the gateway cannot forward the packet properly because either a device is misconfigured or the gateway is not operating.

66 20

Telnet

Telnet, which is a login and terminal emulation program for Transmission Control Protocol/Internet Protocol (TCP/IP) networks, is a common way to communicate with an individual device. You log in to the device (a remote host) and use that remote device as if it were a local terminal.

If you have established an out-of-band Telnet connection with a device, you can use Telnet to communicate with that device even if the network is unavailable. This feature makes Telnet one of the most frequently used network troubleshooting tools. Usually, all device statistics and configuration capabilities are accessible by using Telnet to connect to the device's console. For more information about setting up an out-of-band connection, see "Using Telnet, Serial Line, and Modem Connections".

You can invoke the Telnet application on your local system and set up a link to a Telnet process that is running on a remote host. You can then run a program that is located on a remote host as if you were working at the remote system.

FTP and TFTP

Most network devices support either the File Transfer Protocol (FTP) or the Trivial File Transfer Protocol (TFTP) for downloading updates of system software. Updating system software is often the solution to networking problems that are related to agent problems. Also, new software features may help correct a networking problem.

FTP provides flexibility and security for file transfer by:

Accepting many file formats, such as ASCII and binary Using data compression

Providing Read and Write access so that you can display, create, and delete files and directories

Providing password protection

TFTP is a simple version of FTP that does not list directories or require passwords. TFTP only transfers files to and from a remote server.

Analyzers

An analyzer, which is often called a Sniffer, is a network device that collects network data on the segment to which it is attached, a process called packet capturing. Software on the device analyzes this data, which is a process referred to as protocol analysis. Most analyzers can interpret different types of protocol traffic, such as TCP/IP, AppleTalk, and Banyan VINES traffic.

66 21

You usually use analyzers for reactive troubleshooting - when you see a problem somewhere on your network, you attach an analyzer to capture and interpret the data from that area. Analyzers are particularly helpful for identifying intermittent problems. For example, if your network backbone has experienced moments of instability that prevent users from logging on to the network, you can attach an analyzer to the backbone to capture the intermittent problems when they happen again.

Probes

Like Analyzers, a probe is a network device that collects network data. Depending on its type, a probe can collect data from multiple segments simultaneously. It stores the collected data and transfers the data to an analysis site when requested. Unlike an analyzer, probes do not interpret data.

A probe can be either a stand-alone device or an agent in a network device. The Transcend Enterprise Monitor 500 series and the SuperStack® II Monitor series are stand-alone RMON probes. LANsentry Manager and Traffix Manager use data from probes that comply with the "RMON MIB" or the "RMON2 MIB".

You can use a probe daily to determine the health of your network. The Transcend NCS applications can interpret and report this data, alerting you to possible problems so that you can proactively manage your network. For example, an RMON2 probe can help you to analyze traffic patterns on your network. Use this data to make decisions about reconfiguring devices and end stations as needed.

Cable Testers

Cable testers examine the electrical characteristics of the wiring. They are most commonly used to ensure that building wiring and cables meet Category 5, 4, and 3 standards. For example, network technologies such as Fast Ethernet require the cabling to meet Category 5 requirements. Testers are also used to find defective and broken wiring in a building.

Knowing Your Network

You can better troubleshoot the problems on your network by:

Knowing Your Network's Configuration Identifying Your Network's Normal Behavior

Knowing Your Network's Configuration

Part of understanding your network is knowing its physical and logical configuration. You should know:

66 22

Which devices are on your network How the devices are configured

Which devices are attached to the backbone

Which devices connect your network to the outside world (WAN)

To keep track of your network's configuration, gather the following information:

Site Network Map Logical Connections

Device Configuration Information

Other Important Data About Your Network

This data, when kept up-to-date, is extremely helpful for locating information when you experience network or device problems.

Site Network Map

A network map helps you to:

Know exactly where each device is physically located Easily identify the users and applications that are affected by a problem

Systematically search each part of your network for problems

You can create a network map using any drawing or flow chart application. Store your network map online. In addition, make sure that you always have a current version on paper in case you cannot access the online version. Figure 8 shows an example of a network map of 3Com devices.

Figure 8 Example of a Site Network Map

66 23

Consider including the following information on your network map:

Location of important devices and workgroups (by floor, building, or area) Location of the network backbone, data center, and wiring closets, as appropriate for your

network

Location of your network management stations

Location and type of remote connections

IP subnetwork addresses for all managed switches and hubs

Other subnetwork addresses, such as Novell IPX and AppleTalk, if appropriate for your network

Type of media (by actual name, such as 10BASE-T, or by grouping, such as Ethernet), which you can show with callouts, colors, line weights, or line styles

Virtual workgroups, which you can show with colors or shaded areas

66 24

Redundant links, which you can indicate with gray or dashed lines

Types of network applications that are used in different areas of your network

Types of end stations that are connected to the switches and hubs Logical Connections

With the advent of virtual LANs (VLANs), you need to know how your devices are connected logically as well as physically. For example, if you have connected two devices through the same physical switch, you can assume that they can communicate with each other. However, the devices can be in separate VLANs that restrict their communication.

Knowing the setup of your VLANs can help you to quickly narrow the scope of a problem to a VLAN instead of to a network connection.

The Transcend NCS application Enterprise VLAN Manager allows you to view the logical makeup of your network. Depending on the complexity of your network and VLAN configurations, you can use colors to show the VLANs graphically on your network map.

Device Configuration Information

Maintain online and paper copies of device configuration information. Make sure that all online data is stored with your site's regular data backup. If your site does not have a backup system, copy the information onto a backup disc (CD, Zip disk, and the like) and store it offsite.

Follow these guidelines for saving configuration information:

Because the easiest way to recover a device's configuration is to use FTP or TFTP, save the configuration settings of each device that supports this method of uploading.

For other devices, Telnet in and save the session (which contains configuration details) to a file. If you cannot print the configuration of a device, then create a quick "rebuild" guide that explains the quickest way to configure the device from a fresh install.

For devices that store information to diskette, store this data as part of your site's regular backup.

For routers and other important devices with text configuration files, store this data online in a revision control system. Keep the most recent version on paper. Keep previous versions.

For PCs, keep a recovery disk for each type of PC. For any device that you use as a server, store all startup scripts and copies of registries.

Other Important Data About Your Network

For a complete picture of your network, have the following information available:

66 25

All passwords - Store passwords in a safe place. Keep previous passwords in case you restore a device to a previous software version and need to use the old password that was valid for that version.

Device inventory - The inventory allows you to see the device type, IP address, ports, MAC addresses, and attached devices at a glance. Software tools, such as Transcend Central, can help you keep track of the 3Com devices on your network. Using Transcend Central, you can group devices by type and location and have this information on hand for troubleshooting.

MAC address-to-port number list - If your hubs or switches are not managed, you must keep a list of the MAC addresses that correlate to the ports on your hubs and switches. Generate and keep a paper copy of this list, which is crucial for deciphering captured packets, using Address Tracker.

Log book - Document your interactions, no matter how trivial, with each device that is critical to your network's operation (that is, routers, remote access devices, security servers). For example, document that you noticed a fan making noise one morning. Your note may help you to identify why a device is over temperature a week later (because the fan stopped working).

Change control - Maintain a change control system for all critical systems. Permanently store change control records.

Contact details - Store, online and on paper, the details of all support contracts, support numbers, engineer details, and telephone and fax numbers.

LANsentry Reporter - Use LANsentry Reporter to generate reports from the database.

Identifying Your Network's Normal Behavior

By monitoring your network over a long period, you begin to understand its normal behavior. You begin to see a pattern in the traffic flow, such as which servers are typically accessed, when peak usage times occur, and so on. If you are familiar with your network when it is fully operational, you can be more effective at troubleshooting problems that arise.

Baselining Your Network

You can use a baseline analysis, which is an important indicator of overall network health, to identify problems. A baseline can serve as a useful reference of network traffic during normal operation, which you can then compare to captured network traffic while you troubleshoot network problems. A baseline analysis speeds the process of isolating network problems.

By running tests on a healthy network, you compile "normal" data to compare against the results that you get when your network is in trouble. For example, Ping each node to discover how long it typically takes you to receive a response from devices on your network.

66 26

Applications such as Status Watch, Address Tracker, LANsentry Manager, and Traffix Manager allow you to collect days and weeks of data and set a baseline for comparison. Through the reporting mechanisms in the following list, you can continuously assess the data from your network and ensure that its performance is optimal:

Web Reporter generates daily or weekly reports from data collected by Status Watch. Traffix Manager generates weekly reports from collected data and calculates the baselines for

you. Set up Utilization History and Error History reports with data resolution set to Weekly.

LANsentry Manager History View generates daily utilization graphs, which are sampled every 30 minutes, for each day over one week. Use these graphs to calculate your network baselines manually.

Identifying Background Noise

Know your network's background noise so that you can recognize "real" data flow. For example, one evening after everyone is gone, no backups are running, and most nodes are on, analyze the traffic on your network using the Traffix Manager application. The traffic that you see is mostly broadcast and multicast packets. Any errors that you see are the result of faulty devices (trace). This traffic is the background noise of your network - traffic that occurs for little value. If background noise is high, redesign your network.

Identifying Background Noise

Know your network's background noise so that you can recognize "real" data flow. For example, one evening after everyone is gone, no backups are running, and most nodes are on, analyze the traffic on your network using the Traffix Manager application. The traffic that you see is mostly broadcast and multicast packets. Any errors that you see are the result of faulty devices (trace). This traffic is the background noise of your network - traffic that occurs for little value. If background noise is high, redesign your network.

FDDI Connectivity

Use these sections to identify and correct connectivity errors on an FDDI ring:

FDDI Connectivity Overview Monitoring FDDI Connections

Making Your FDDI Connections More Resilient

Fiber Distributed Data Interface (FDDI), which is a self-correcting technology, automatically corrects ring faults to maintain connectivity throughout most of the network. However, you should monitor your FDDI connections for wrapped rings and other problems with ring connectivity.

66 27

Understanding the Problem

As shown in Figure 9, in a thru FDDI LAN, no stations on the trunk ring have a Configuration State (SMTConfigurationState) of Wrap or Isolated. However, users who complain about network performance may have lost connectivity to other stations on the network because the FDDI network is wrapped or segmented.

Figure 9 Thru Ring

Wrapped ring

By monitoring the "Peer Wrap Condition", you can see when the Configuration State changes. In a wrapped ring (Figure 10), two stations on the LAN are in a wrapped Configuration State. This condition may or may not affect the connectivity of certain stations. Although operational, your network may have a cabling problem or a problem with a link.

Figure 10 Wrapped LAN

Segmented ring

In a segmented ring (Figure 11), more than two stations are wrapped on the trunk ring. Although this mode of operation is a valid FDDI LAN configuration, your LAN is probably experiencing a degraded or degrading condition.

Figure 11 Segmented Ring

66 28

When a network connection has excessively high link errors, Station Management (SMT) shuts down the connection and tries to reconnect again. A dual-attachment trunk ring station with an A or B connection that is shut down is one of the wrap points in the network. See "Making Your FDDI Connections More Resilient" for information about keeping a dual-attachment station connection from wrapping.

Isolated station

Sometimes a network wraps a particular station out of the ring. Stations on either side of a problem station can be wrapped. This effectively isolates the station or links that have problems, as shown in Figure 12.

Figure 12 Wrapped Ring with Isolated Station

If a ring was already wrapped when a network wraps a station out of the ring, then a segmented ring results, as shown in Figure 13.

Figure 13 Segmented Ring with Isolated Stations

Twisted ring

In a twisted ring, an A port is connected to an A port and a B port is connected to a B port instead of the normal A-to-B connections. A twisted ring, which always has two twist points (stations), can exist in either a Thru or Wrap state. You can monitor the "Twisted Ring Condition" and "Undesired Connection Attempt Event" for evidence of twisted ring and other connection problems.

66 29

Identifying the Problem

To identify the problem, follow this process:

1 .   At the FDDI LAN level, verify that your network is operating.

If the network is operating, the FDDI ring may be segmented, and therefore an FDDI station or an Ethernet station on an Ethernet link may have lost connectivity to other nodes on the network.

2 .   Determine if a ring is in a Thru, Wrap, or Segmented state.

If the FDDI ring is segmented or wrapped, look for a problem with a link somewhere in the network or for a nonfunctioning node on your trunk ring. If the ring is operating and is not segmented, or if it is segmented but you still have connectivity to the stations in question, move to a more specific level in your network.

See "Monitoring FDDI Connections" for more information.

3 .   Determine if the poorly performing station is an Ethernet or FDDI station.

If the problem is an FDDI station, find out if it is congested (that is, if the station is so busy that it cannot accept all the network traffic that is directed to it) by determining its "Bandwidth Utilization". Also determine if the station has a high frame error rate by looking at the "FDDI Ring Errors".

If the problem is an Ethernet station, look for congestion by examining "Ethernet Packet Loss" and "Bandwidth Utilization".

Solving the Problem

Identify the station that is causing the disconnection and take the appropriate steps:

If the disconnection is caused by a wrapped ring, then fix the hardware or cabling problem at that station.

If the station is congested, you have a device problem rather than a network problem. For example, if the congested station is a file server and every other machine on the network is retrieving and saving files using that server, consider upgrading your server or adding additional servers to the network. A variety of devices from different vendors may be communicating on an FDDI or Ethernet network; some are faster and more capable, and some are slower and more prone to congestion.

66 30

If the station is an Ethernet station that is attached to an Ethernet segment, reevaluate the setup of your Ethernet network and make some changes to improve its performance.

You can also make FDDI connections more resilient by implementing dual homing or installing an Optical Bypass Unit (OBU) where FDDI connections are prone to fail. See "Making Your FDDI Connections More Resilient" for more information.

Monitoring FDDI Connections

Monitor your FDDI devices for Warning or Critical alerts in the FDDI Status tool.

Status Watch

Use Status Watch to identify these FDDI connectivity errors:

Peer Wrap Condition Twisted Ring Condition

Undesired Connection Attempt Event

Follow these steps:

1 .   In the Device area, select the device that is located where you suspect an FDDI ring connectivity problem.

2 .   Monitor the FDDI Status tool for the currently selected device.

Here are some pointers for monitoring:

If the Peer Wrap Configuration State variable is Isolated, the device is not connected to the FDDI trunk ring. If you intend the device to remain isolated, this indication is not a serious condition. However, if the device is supposed to be connected on a trunk ring, a serious problem may exist. The device is no longer transmitting packets to the larger trunk ring.

If the Peer Wrap flag (SMTPeerWrapFlag) is set, the device is one of the wrap points. The cause of the wrapped ring is somewhere in the portion of the network between the two stations that report the peer wrap condition.

Making Your FDDI Connections More Resilient

66 31

When devices are removed from an FDDI ring, there is a break in the fiber path that causes the ring to wrap until the ring is made whole again. To prevent the break in the FDDI connection, you can implement dual homing or install an Optical Bypass Unit (OBU).

Implementing Dual Homing

When the operation of a dual attachment node is critical to your network, dual homing adds reliability by providing a backup connection if the primary link fails. Because a dual attachment station (DAS) has two attachments to the FDDI ring (A-to-M and B-to-M), you can use one of them as a "standby" link if the active link fails. Using dual homing, only one of the two attachments is active at a time. In this sense, a DAS acts as if it is a single attachment station (SAS) by using its A port as the standby link.

Through SMT, a DAS can be dual homed to the same concentrator or, more commonly, to two concentrators. This arrangement provides a more stable trunk ring of concentrators. If one concentrator fails, the DAS enables the standby link to another concentrator to become the active link. See Figure 14.

If the station is a dual path or dual path/dual MAC station, you can configure the dual-homed station in one of two ways:

With both links active With one link active and one connection withheld as a backup, only becoming active when one

link fails

Figure 14 Dual Homing Configuration

66 32

Installing an Optical Bypass Unit

You can insert an Optical Bypass Unit (OBU) into the FDDI ring as if it were a node and then plug your device into it. To use an OBU, your device needs an optical bypass interface. This interface lets the bypass know whether your device is still on the ring or not. See Figure 15.

If your device is removed or if it fails, the bypass unit diverts the optical path away from your device, keeping the ring whole. You can use a bypass on devices that are prone to failure or are likely to be removed often, such as diagnostic equipment.

Figure 15 Optical Bypass Unit Configuration

FDDI Connectivity Reference

This section explains terms that are relevant to FDDI connectivity and provides additional conceptual and problem analysis detail.

Peer Wrap Condition

A Peer Wrap (wrapped ring) condition occurs when a dual-attachment station detects a fault (often a lost connection) and reconfigures the network by wrapping the dual trunk rings to form a single ring. Normally, the two stations that are adjacent to the fault wrap to maintain full connectivity. However, if a second fault occurs before the first is repaired, the network partitions itself into two or more rings and stations lose connectivity.

When a station reports a Peer Wrap condition, locate and repair the problem that caused the station to wrap the rings. Potential causes include:

66 33

Faulty FDDI port hardware Faulty cables or connectors

Unplugged connectors

Powered-down stations

You can expect to find the cause of the problem between the two stations that report the Peer Wrap condition.

Twisted Ring Condition

A Twisted Ring condition occurs when certain undesirable connection types exist. See Table 7 for more information. Although similar to the Undesired Connection Attempt, the Twisted Ring condition provides specific Station Management (SMT) and port information for diagnosis.

Undesired Connection Attempt Event

An Undesired Connection Attempt event occurs when a port tries to connect to another port of a type that may result in an undesirable network topology. Whether the connection attempt is successful depends on the current setting of the station's connection policies.

Table 7 lists connections that the FDDI standard defines as undesirable. The managed devices may or may not permit these connections, depending on their FDDI station configurations.

Table 7 Undesirable Connection Types

Connection Type1 Reason That the Connection Is Undesirable

A-A Twisted primary and secondary rings

A-S A wrapped ring

B-B Twisted primary and secondary rings

B-S A wrapped ring

S-A A wrapped ring

S-B A wrapped ring

66 34

M-M A tree of rings topology (illegal connection)

Table 8 lists FDDI connections that create valid topologies.

Table 8 Valid Connection Types

Connection Type

Reason That the Connection Is Valid

A-B A normal trunk peer connection

A-M A tree connection with possible redundancy. In a single MAC node, Port B has precedence (by default) for connecting to a Port M.

B-A A normal trunk ring peer connection

B-M A tree connection with possible redundancy. In a single MAC node, Port B has precedence (by default) for connecting to a Port M.

S-S A single ring of two slave stations

S-M A normal tree connection

M-A A tree connection that provides possible redundancy

M-B A tree connection that provides possible redundancy

M-S A normal tree connection

Disabling the Offending Interface

Because broadcast storms can ultimately cause your whole network to become unavailable, take action immediately to disable the offending interface. You can enable the interface again after you have corrected the problem.

66 35

Address Tracker

Use Address Tracker to locate the interface that is causing the broadcast storm. Use Device View to disable the port.

Follow these steps:

1 .   In the Find Address window, enter the address of the interface that seems to be receiving the broadcast traffic.

You can copy the MAC or IP address from the Status Watch report and paste it into Address Tracker's Enter the Address You Want to Find field.

2 .   Click Find Now.

Search displays the device name.

3 .   Use Transcend Central to launch Device View and disable the port.

Disabling the port stops the broadcast storm before it interferes with all vital network traffic. You can re-enable this interface using Device View or the device's console later.

Correcting Spanning Tree Misconfigurations

Spanning Tree does not cause broadcast storms, but a loop in your Spanning Tree topology can create data that looks like a storm. A loop can occur in your topology if:

Someone disables Spanning Tree on a port You set up your Spanning Tree configuration incorrectly

Device View

Use Device View to disable any Spanning Tree port that has a repeater attached to it and to correct Spanning Tree misconfigurations.

To correct Spanning Tree misconfigurations, use Device View to disable Spanning Tree Protocol (STP) for a port on a SuperStack® II Switch 1000, Switch 3000, Switch 3000 10/100, Switch 9000SX, Desktop Switch, LinkBuilder® FMS II Bridge/Management Module, or CoreBuilder 6000.

To disable the STP port state for a port on a SuperStack II switch:

66 36

1 .   Select a port and click the right mouse button.

2 .   From the shortcut menu, select Configure.

3 .   In the Port section, click the STP tab.

4 .   From the STP Port State list box, select Disabled.

5 .   Click Apply.

To disable the STP port state for a port on a LinkBuilder FMS II Bridge/Management Module:

1 .   Double-click the module.

2 .   From the shortcut menu, select Configure Bridge.

3 .   In the Port section, click the STP tab.

Broadcast Storms Reference

This section explains terms that are relevant to broadcast storms and provides additional conceptual and problem analysis detail.

Broadcast Packets

Broadcast packets, which are a normal part of network operation, are transmitted by a device to a broadcast address. For example, IP networks use broadcasts to resolve network addresses using Address Resolution Protocol (ARP); IPX networks use a large number of broadcast packets to operate most effectively.

Problems arise when broadcast packets endlessly propagate throughout the network, which increases the traffic volume on your network and the CPU time that each host spends processing and discarding unwanted broadcast packets.

Multicast Packets

Multicast packets, which are a normal part of network operation, are transmitted by a device to a multicast group address. Hosts that want to receive the packets indicate that they want to be members of the multicast group, and then multicast packets are distributed to that group. For example, multicast packets support the Spanning Tree Protocol. Multicast applications and underlying multicast protocols control multimedia traffic and shield hosts from processing

66 37

unnecessary broadcast traffic. However, multicast traffic can also cause storms that saturate your network.

Duplicate Addresses

Use these sections to identify and correct problems caused by duplicate MAC and IP addresses:

Duplicate Addresses Overview Finding Duplicate MAC Addresses

Finding Duplicate IP Addresses

See "Duplicate Addresses Reference" for additional conceptual and problem analysis detail.

Networks sometime generate duplicate MAC and IP addresses. Because duplicate addresses can cause problems with packet delivery, resolve them as soon as possible.

Understanding the Problem

Duplicate MAC addresses are caused by data link layer problems with Fiber Distributed Data Interface (FDDI) media and the passing of tokens on the FDDI ring. Duplicate IP addresses are caused by network layer problems. See these sections for more information about causes of duplicate addresses:

Duplicate MAC Addresses Duplicate IP Addresses

Identifying the Problem

Identify duplicate MAC and IP addresses by following the instructions in these sections:

Finding Duplicate MAC Addresses Finding Duplicate IP Addresses

Solving the Problem

Identify the cause of the duplicate address (such as user error or a hardware problem), and fix the problem, if possible.

Finding Duplicate MAC Addresses

66 38

To find out if duplicate MAC addresses are occurring, monitor your network using Status Watch.

Status Watch

The Status Watch FDDI Status tool identifies duplicate FDDI MAC addresses, and Status Watch reports when two or more MACs on the same ring have the same MAC address (a Duplicate Address condition).

Follow these steps:

1 .   In the Status Watch Summary View window, determine if any FDDI Status conditions are reported. If there are, double-click the table cell value to display the Device List window.

Another approach is to examine only the devices that you know reside on your FDDI ring. In the Status Watch main window, red device icons indicate that a threshold has been exceeded.

2 .   Select a device.

If you selected the device from the Device List window, the real-time report for that device appears in the Status Watch main window.

If you selected the device from the main window, also select the FDDI Status tool to view the real-time report.

3 .   Determine if a Duplicate Address condition caused the FDDI Status tool to trigger a Critical or Warning status for that device.

In Status Watch, you can specify the status severity level to apply to a Duplicate Address condition.

Finding Duplicate IP Addresses

To find out if duplicate IP addresses are occurring, monitor your network using these applications:

Address Tracker - To find duplicate IP addresses on 3Com devices and their attached networks. LANsentry Manager ® - To find duplicate IP addresses that are collected by probes gathering

RMON2 SmartAgent® data from the Enterprise Communications Analysis Module (ECAM) downloaded on your network devices.

66 39

Address Tracker

Use Address Tracker to determine when and where duplicate IP addresses occur.

Follow these steps:

1 .   From the Find Address menu, select Find Duplicate IP Addresses.

2 .   Click Find Now to start your search.

LANsentry Manager

Use the Duplicates table in LANsentry Manager to compile a list of all stations with duplicate IP addresses. This table is available only on probes that have downloaded RMON2 (ECAM) SmartAgent software.

Follow these steps:

1 .   From the LANsentry Manager Address Map menu, select Duplicates. Address Map data is displayed as a table.

2 .   To export the contents of the table, click Export to launch the Data Export dialog box.

Duplicate Addresses Reference

This section explains terms that are relevant to duplicate addresses and provides additional conceptual and problem analysis detail.

Duplicate MAC Addresses

Each device on your network has a unique MAC address. This address identifies a single device on the network, allowing packets to be delivered to correct destinations.

Packets are delivered to their destinations by means of MAC-address-to-IP address translation that the Address Resolution Protocol (ARP) provides. Therefore, if MAC addresses are duplicated on the network, ARP caches of routing devices contain erroneous destinations. In FDDI, devices monitor network traffic, searching for their own MAC address in each packet to determine whether to decode the packet. If MAC addresses are not unique, two stations cannot be distinguished from each other.

66 40

Duplicate MAC addresses can occur for the following reasons:

Someone has manually configured a MAC address for a device instead of using the address that the vendor supplied or allowing it to be assigned dynamically, and this address is also assigned to a different device.

In rare circumstances, loops in a bridged network can cause a MAC hardware problem or an address learning problem that creates a duplicate MAC address entry in the bridging address table.

On DECnet Phase 4 networks, MAC addresses are set from the DECnet address. A duplicate NET address can cause a duplicate MAC address.

Duplicate IP Addresses

Because IP addresses are critical for transmission of packets on TCP/IP networks, resolve them immediately.

Duplicate IP addresses can occur when someone has configured an IP address that is identical to an IP address that is assigned to a different device. Address assignments, although possible for you to configure manually, are usually made using one of these protocols:

Dynamic Host Configuration Protocol (DHCP) - Allows your network to dynamically assign IP addresses to nodes. With this protocol, a DHCP server temporarily assigns an IP address to a node, or you can statically configure addresses as needed.

BOOTstrap protocol (BootP) - Allows you to statically assign IP addresses to nodes. This protocol is more efficient than RARP.

Reverse ARP (RARP) - Allows you to statically assign IP addresses to nodes. However, because this protocol relies on the MAC address to identify the node, you cannot use it on networks that dynamically assign hardware addresses.

Ethernet Packet Loss

Use these sections to identify and correct Ethernet packet loss:

Ethernet Packet Loss Overview Searching for Packet Loss

See "Ethernet Packet Loss Reference" for additional conceptual and problem analysis detail.

If your Ethernet network shows signs of congestion, it may be experiencing packet loss. When your network is congested, utilization is usually high, packets are discarded because buffers are full, and collision rates are up. Problems related to "Collisions" are often at the heart of packet loss.

66 41

Understanding the Problem

Collisions are normal in Ethernet networks. In many cases, Collision rates of 50 percent do not cause a large decrease in throughput. The Collision rate helps mark the upper limit on your network (the maximum percentage of collisions that your network can bear), which is usually around 70 percent. If Collisions increase above this upper limit, your network can become unreliable.

When the Collision rates increase, so do "Excessive Collisions", which causes a delay in transmitting data. An increase in Collisions also indicates that network utilization and network errors, such as "FCS Errors", are probably increasing.

The real packet problems to watch for, however, are undetected collisions that show up as "Late Collisions".

Identifying the Problem

To identify that your network's problem is related to packet loss, verify that frames are being dropped on your network by examining this packet loss data:

Alignment Errors Collisions

Excessive Collisions

FCS Errors

CRC Errors

Late Collisions

Receive Discards

Too Long Errors

Too Short Errors

Transmit Discards

The process of identifying the problem is discussed in "Searching for Packet Loss".

Solving the Problem

If you notice that packet loss data is consistently high, then your network is too congested. In this case, segment your network with the appropriate network device (such as a switch or router). If Collision data shows increases but your network's utilization is the same, then your network may

66 42

have a physical problem, such as cabling that is too long. Other problems that packet loss data can indicate include:

Faulty connectors or improper cabling Excessive numbers of repeaters between network devices

Defective Ethernet transceivers or controllers

Possible solutions to these problems are explained in the procedures in "Searching for Packet Loss".

Searching for Packet Loss

When you look for packet loss, use the following applications:

Status Watch - For Ethernet and MIB-II data collection using SNMP polling LANsentry Manager Network Statistics Graph - For RMON data collection using an RMON probe

Device View - On a per-device basis, you can evaluate statistics for any port on the device.

Status Watch

Status Watch monitors:

Alignment Errors Excessive Collisions

FCS Errors

Receive Discards

Transmit Discards

Follow these steps:

1 .   Determine if the thresholds for the Alignment Errors tool and FCS Errors tool are being exceeded.

Table 16 identifies the problems that this data can indicate and your possible actions. For information about problems related to a nonstandard Ethernet implementation, see "Nonstandard Ethernet Problems".

Table 16 Alignment Errors, FCS Errors, and CRC Errors Data

66 43

Possible Problem Possible Action

Faulty cabling Examine the cable and cable connections for breaks or damage.

Network noise Look for improper cabling, faulty cable, faulty network equipment, or cables that are too close to equipment that emits electromagnetic interference (lamps, for example).

Faulty transceiver Use an analyzer to identify the problematic transceiver. If necessary, replace the transceiver, network adapter, or station.

Fault at the transmitting end station

1 . Locate the source of the errors by looking at the module and port statistics.

2 . Verify the correct operation of the transceiver or adapter card of the device that is connected to the problem port.

3 . If the card appears to be operating correctly, examine the cable and cable connections for breaks or damage.

Station powering up or down

None required.

Early implementations of Ethernet transceivers generate a significant amount of in-band noise when powering up; they frequently cause Alignment Errors and FCS Errors in an otherwise stable network.

When powering up, some software drivers for Ethernet controllers also initiate Time Domain Reflectometry (TDR) tests to test the Ethernet media. Network monitors report TDR tests as Alignment Errors and FCS Errors.

Faulty adapter Replace the adapter.

2 .   Determine if the Excessive Collisions tool threshold is being exceeded. Table 17 identifies the problems that this data can indicate and your possible actions.

Table 17 Collisions and Excessive Collisions Data

Possible Problem Possible Action

Busy network Use a bridge, router, or switch to reconfigure your network into segments with fewer stations.

Faulty device (adapter, switch, hub, and the like) that does not listen before broadcasting. This problem increases the incidence of all types of collisions.

Isolate each adapter to see if the problem stops.

66 44

Network loop Ensure that no redundant connections to the same station have both connections active simultaneously.

3 .   Determine if the Receive Discards and Transmit Discards tools thresholds are being exceeded.

If these errors are high in conjunction with the data that you learned in steps 1 and 2, then your network is overloaded. Segment your network.

LANsentry Manager Network Statistics Graph

Use the LANsentry Manager Network Statistics graph to view data for:

Collisions Late Collisions

Bandwidth Utilization

CRC Errors

Too Long Errors

Too Short Errors

Follow these steps:

1 .   Display a Network Statistics graph for the local Ethernet segment on which users have reported poor performance.

This graph shows the most recent trend in Collision rates. If you have set up a History sample, you can also look at the historical trend. If a number of segments are connected by repeaters, examine the graph for each Ethernet segment.

2 .   Analyze Utilization and Collision rates to determine whether collisions are caused by an overloaded segment or a faulty component.

If Utilization rates are high - The collisions are probably caused by an overloaded segment. If you have added nodes or new applications to your network, consider reconfiguring the cabling system using bridges and routers to filter out remote collisions and to keep local traffic on one segment. This action should level the network load.

If Utilization rates are stable and appear normal - The collisions are probably caused by faulty components. In this case, do the following:

66 45

If the network consists of repeaters - Compare the Network Statistics graphs for each segment connected to the repeater. Because repeaters "repeat" traffic across all connected segments (which makes many segments seem like one network), you should see similar levels of traffic on all segments. One segment that shows dissimilar levels of traffic and collisions may indicate faulty hardware. In this case, monitor several collisions to track the source station that is transmitting too soon after collisions and repair the station. Packets that are transmitted too soon after collisions are unlikely to be valid. See Table 17 for more information about Collisions.

On other networks - Determine the segment cable length.

3 .   Examine the CRC Errors and Late Collisions, which often indicate cabling or component problems.

Table 16 identifies the problems that CRC Errors can indicate and your possible actions. Table 18 identifies the problems that Late Collisions data can indicate and your possible actions.

Table 18 Late Collisions Data

Possible Problem Possible Action

Cabling problems:

Segment too long Failing cable

Segment not grounded properly (noise)

Improper termination

Taps too close (10BASE-5 and 10BASE-2 only)

Noisy cable

Correct the cabling problem by doing one or more of the following:

Reduce the segment length. Replace the cable.

Ground the cable.

Terminate the cable correctly.

Check the taps.

Check for cables too close to equipment that emits electromagnetic interference.

Component problems:

Deaf or partially deaf node

Failing repeater, transceiver, or controller cards

Correct the component problem by doing one of the following:

Trace the failing component and replace it.

Replace the NIC or the transceiver.

4 .   Trace Too Short Errors and Too Long Errors to the sender.

66 46

These errors often indicate faulty routers or LAN drivers and transceiver problems. Table 19 identifies the problems that this data can indicate and your possible actions.

Possible Problem Possible Action

A transceiver on your network is adding bits to the packets that are transmitted by the attached station.

1 . Use a network analyzer to identify the problematic transceiver.

2 . If necessary, replace the transceiver, network adapter, or station.

The jabber protection mechanism on a transceiver has failed; it can no longer protect the network from the jabbering produced by the attached station.

Replace the network card.

Excessive noise on the cable

Note: Some 10/100 Mbps cards that autodetect the network speed may connect to the network at the wrong speed, causing excessive noise.

Check for improper cabling, faulty cable, faulty network equipment, or cables too close to noisy electronic equipment (lamps, for example)

If your network card autodetects the network speed, and you have ruled out other problems, manually configure the network speed.

Faulty routers (two different network types are connected and the router is not enforcing proper frame size restrictions)

Notify the manufacturer.

Faulty LAN driver Replace the driver.

A normal condition on a LinkSwitch® 1000, LinkSwitch® 3000, or CoreBuilder 5000 FastModule

If you use maximum-sized, 1518 Ethernet frames, the device's VLT-enabled ports add a frame tag of 4 bytes, resulting in a misleading Too Long Frame error.

These frames are passed successfully but will create the Too Long Frame error message.

If you want to eliminate the error message, reduce your Ethernet packet frames by 4 bytes.

Device View

Device View allows you to display a variety of port and device-level statistics relevant to Ethernet packet loss. Table 20 describes these statistics and their use in troubleshooting.

Table 20 Activity and Error Statistics in Device View

Statistics Group

Description Use in Troubleshooting

Activity Displays the total

This data shows readable packets, broadcast packets, "Collisions", total errors, and runts, which cause "Too Short Errors". You can interpret this data in the

66 47

network activity and errors on the selected port.

following ways:

The presence of runts can often be caused by Collisions; however, if the values increase at specific times of the day, it may indicate you need to change the network topology to manage the traffic more efficiently (for example, with switches or routers).

Runts can also be caused by a badly terminated coax cable.

Large numbers of runts, not associated with high levels of collisions, can indicate a transmission problem (examine the cable).

Particularly high numbers of Collisions, compared to the total number of readable packets, can point to a hardware problem (a bad adapter) or to a data loop.

A high proportion of "Broadcast Packets" (>10%) on a heavily utilized network (>50% of available bandwidth) can point to an incorrectly configured bridge or router on the network.

Errors Displays the number of frames with errors on the selected port.

The significance of errors depends on accompanying errors and prevailing network conditions. See the following error data for more information:

Alignment Errors , Table 16 FCS Errors , Table 16

Too Long Errors , Table 19

Too Short Errors or runts, Table 19

Late Collisions , Table 18

To display Activity and Errors statistics for a device or port, follow these steps:

1 .   Select the required port or device.

2 .   From the shortcut menu, select Activity or Errors.

The statistics available depend on the type of port or device selected. See Table 20 for troubleshooting information.

Ethernet Packet Loss Reference

This section explains terms that are relevant to Ethernet packet loss and provides additional conceptual and problem analysis detail.

66 48

Alignment Errors

An Alignment Error indicates a received frame in which both are true:

The number of bits received is an uneven byte count (that is, not an integral multiple of 8) The frame has a Frame Check Sequence (FCS) error.

Alignment Errors often result from MAC layer packet formation problems, cabling problems that cause corrupted or lost data, and packets that pass through more than two cascaded multiport transceivers. See "FCS Errors" for more information about interpreting Alignment Errors.

Collisions

Collisions indicate that two devices detect that the network is idle and try to send packets at exactly the same time (within one round-trip delay). Because only one device can transmit at a time, both devices must stop sending and attempt to retransmit. Collisions are detected by the transmitting stations.

The retransmission algorithm helps to ensure that the packets do not retransmit at the same time. However, if the two devices retry at nearly the same time, packets can collide again; the process repeats until either the packets finally pass onto the network without collisions, or 16 consecutive collisions occur and the packets are discarded.

CRC Errors

A Cyclic Redundancy Check (CRC) Error is an RMON statistic that combines "FCS Errors" and "Alignment Errors". These errors indicate that packets were received with:

A bad FCS and an integral number of octets (FCS Errors) A bad FCS and a non-integral number of octets (Alignment Errors)

CRC Errors can cause an end station to freeze. If a large number of CRC Errors are attributed to a single station on the network, replace the station's network interface board. Typically, a CRC Error rate of more than 1 percent of network traffic is considered excessive.

Excessive Collisions

Excessive Collisions indicate that 16 consecutive collisions have occurred, usually a sign that the network is becoming congested. For each excessive collision count (or after 16 consecutive collisions), a packet is dropped. If you know the normal rate of excessive collisions, then you can determine when the rate of packet loss is affecting your network's performance. See "Knowing Your Network's Configuration" for more information.

66 49

FCS Errors

Frame Check Sequence (FCS) Errors, a type of CRC, indicate that frames received by an interface are an integral number of octets long but do not pass the FCS check. The FCS is a mathematical way to ensure that all the frame's bits are correct without having the system examine each bit and compare it to the original. Packets with Alignment Errors also generate FCS Errors.

Both Alignment Errors and FCS Errors can be caused by equipment powering up or down or by interference (noise) on unshielded twisted-pair (10BASE-T) segments. In a network that complies with the Ethernet standard, FCS or Alignment Errors indicate bit errors during a transmission or reception. A very low rate is acceptable. Although Ethernet allows a 1 in 108 bit error rate, typical Ethernet performance is 1 in 1012 or better.

Late Collisions

Late Collisions indicate that two devices have transmitted at the same time, but cabling errors (most commonly, excessive network segment length or repeaters between devices) prevent either transmitting device from detecting a collision. Neither device detects a collision because the time to propagate the signal from one end of the network to the other is longer than the time to put the entire packet on the network. As a result, neither of the devices that cause the late collision senses the other's transmission until the entire packet is on the network.

Although late collisions occur for small packets, the transmitter cannot detect them. As a result, a network suffering measurable Late Collisions for large packets is losing small packets as well.

Nonstandard Ethernet Problems

Table 21 lists the symptoms that typically occur if a system violates the Ethernet standard.

Table 21 Symptoms of Common Ethernet Network Problems

Symptoms Problem Notes

"FCS Errors" and "Alignment Errors" increase significantly.

Network cabling is too long. If you use a promiscuous network monitor, the number of Late Collisions reported by stations should correlate with the FCS and Alignment Errors reported by the monitor.

FCS and Alignment Errors increase proportionally

Network segment is noisy.

Typically observed on a 10BASE-T network segment in a noisy environment. If you use multiple promiscuous monitors, the FCS and Alignment Errors among the

66 50

with interference (sometimes referred to as noise hits).

monitors will not correlate.

If the monitor can track runts, also called "Too Short Errors", the number of runt packets should be significantly higher than normal.

FCS and Alignment Errors are much higher than normal.

Networks do not conform to the access scheme of Carrier Sense Multiple Access with Collision Detect (CSMA/CD).

Occurs when some implementations of Ethernet in the segment are not entirely compatible with IEEE 802.3 repeaters.

Collision fragments linger on the network long enough to collide with retry packets at the minimum interpacket gap (IPG). The IPG is smaller on one side of the repeated network, causing a lost packet.

Ethernet controllers cannot receive packets that are separated by 4.7 µs or less. Some controllers cannot sustain receptions of packets separated by as much as 9.6 µs. If runt packets are received one after another and are followed by a collision fragment, Ethernet controllers that cannot sustain reception will lose packets.

Receive Discards

Receive Discards indicate that received packets could not be delivered to a high-layer protocol because of congestion or packet errors.

Too Long Errors

A Too Long Error indicates that a packet is longer than 1518 octets (including FCS octets) but otherwise well formed. Too Long Errors are often caused by a bad transceiver, a malfunction of the jabber protection mechanism on a transceiver, or excessive noise on the cable.

Too Short Errors

A Too Short Error, also called a runt, indicates that a packet is fewer than 64 octets long (including FCS octets) but otherwise well formed.

Transmit Discards

Transmit Discards indicate that packets were not transmitted because of network congestion.

FDDI Ring Errors

Use these sections to identify and correct FDDI ring errors:

66 51

FDDI Ring Errors Overview Identifying Ring Errors

Fiber Distributed Data Interface (FDDI) often corrects its own problems. However, because FDDI cannot correct all errors (especially those related to hardware problems), you should monitor FDDI errors.

Understanding the Problem

FDDI ring errors that you should monitor include:

Elasticity Buffer Error Condition Frame Error Condition

Frames Not Copied Condition

Link Error Condition

Identifying the Problem

First determine the type of FDDI ring errors and where they are occurring. Similar to the way you identify other FDDI problems, identify the upstream and downstream neighbors of the devices that you are monitoring.

Several types of network errors can cause FDDI performance problems. For example, problems with cables or physical connections may result in a link or frame error. Elasticity buffer (EB) errors can also lead to link and frame errors.

FDDI deals with port-related errors as follows:

The variable PORTlerAlarm is the link error rate (LER) value at which a link connection generates an alarm. When the LER is greater than the alarm setting, Station Management (SMT) sends a Status Report Frame (SRF) to notify you that there is a problem with a port.

The PORTlerAlarm threshold is set lower than the PORTlerCutoff threshold so that you are notified of a problem before the port is actually removed from the ring.

When link errors reach the threshold defined by the variable PORTLERCutoff, SMT breaks the connection, disabling the PHY that detected the problem. A "Link Error Condition" is also generated.

FDDI deals with MAC-related errors as follows:

66 52

When MAC frame errors reach a certain threshold, a "Frame Error Condition" is generated. Because the actual error can be further upstream than the immediate connection, the connection remains intact.

For a large network, the worst case MACFrameErrorRatio is less than 0.1 percent. However, during network configuration, frame error ratios can reach 50 percent for short periods. When you detect a sustained frame error ratio of more than 0.1 percent, a problem exists between the station that is reporting the condition and the nearest upstream MAC.

Solving the Problem

To solve problems related to FDDI errors, fix the hardware, cabling, or congestion problem.

Identifying Ring Errors

Use Status Watch to monitor your FDDI devices for Warning or Critical alerts.

Status Watch

Use Status Watch to identify FDDI ring errors.

Follow these steps:

1 .   Monitor the FDDI Status tool for the currently selected device.

2 .   Determine whether Status Watch is reporting Elasticity Buffer Errors or a high percentage of Frame Errors, Frames Not Copied, or Link Error Rates for the currently selected device.

FDDI Ring Errors Reference

This section provides additional conceptual and problem analysis detail.

Elasticity Buffer Error Condition

The Elasticity Buffer Error condition occurs when a port's elasticity buffer overflows or underflows. This condition usually indicates that a port's hardware is not operating within the tolerances that the FDDI standard specifies. Look for the problem in the hardware of either the port that is reporting the condition or of the immediately adjacent port.

Frame Error Condition

The Frame Error condition occurs when the percentage of frames that contain errors exceeds a preset threshold. In the situation when a device is an uplink to FDDI (that is, a device is

66 53

transmitting onto FDDI), this type of condition indicates that the ring is saturated. The ring is out of buffer space and packets are being dropped from the device's backbone port.

The problem indicated by the frame errors is usually located between the MAC that reports the condition and its upstream neighbor. Because many physical connections can lie along this path, the MACFrameErrorRatio variable identifies only the two MACs between which the problem is occurring.

Frames Not Copied Condition

The Frames Not Copied condition occurs when the percentage of frames that are dropped because of insufficient buffer space exceeds a preset threshold. This condition indicates that the station is congested and is unable to process frames as quickly as they arrive. To help eliminate congestion:

Add more capacity to the station Reconfigure your network so that end stations that communicate heavily with one another are

on the same bridge or switch

Filter out certain traffic

Link Error Condition

The Link Error condition occurs when a port detects link errors at a rate that exceeds a preset threshold. When the Link Error threshold is exceeded, the station removes itself from the ring and tries to reinsert itself on the ring. This action creates a "MAC Neighbor Change Event" (which also occurs if a ring wraps).

Link errors may indicate an FDDI PHY hardware problem (such as a faulty transmitter) or a faulty cable or connector. Look for the problem in the portion of the network between the port that is reporting the condition and the first upstream transmitter.

MAC Neighbor Change Event

The MAC Neighbor Change event occurs when a MAC's upstream or downstream neighbor changes.

This event indicates either:

A network reconfiguration Another station that is leaving or joining the ring

66 54

Network File Server Timeouts

Use these sections to identify and correct timeouts on network file servers:

Network File Server Timeout Overview Looking for Obvious Errors

Reproducing the Fault While Monitoring the Network

Correcting the Fault

See "Network File Server Timeouts Reference" for additional conceptual and problem analysis detail.

A network file server can time out if your network gets congested or if your server is having problems. Users might have problems downloading data from or to the server or copying files from or to the server. To help you to understand the troubleshooting process for this type of problem, an EXAMPLE throughout this section follows the symptoms, analysis, and resolution of a typical file server timeout problem.

Understanding the Problem

When users log in, their stations make network file server calls, either to determine quotas (if this feature has been enabled) or to mount user home directories. The network file server timeout messages, even when spread across multiple nodes, indicate a problem either with the network or with a server.

EXAMPLE: UNIX users notice that it takes a long time - over 30 seconds in some cases - to log in to any machine. Some machines report network file server timeout messages, but the messages have no obvious pattern and are infrequent. You begin to get a sense of the problem.

Identifying the Problem

First, rule out the obvious causes. Ask these questions:

Can you access the network file server with Telnet? Have any alarms been triggered?

Are there any new errors?

The process of identifying the problem is developed in "Looking for Obvious Errors".

66 55

Solving the Problem

To determine the cause, reproduce the fault while you monitor the network. After you know the cause, you can fix the problem.

The solutions to the network file server timeout are identified in these sections:

Reproducing the Fault While Monitoring the Network Correcting the Fault

Looking for Obvious Errors

To look for obvious errors, use these applications:

Ping and Telnet - To determine for connectivity to the network file server nodes LANsentry Manager Alarms View - To search for triggered alarms

LANsentry Manager Statistics View - To look for errors

LANsentry Manager History View - To identify for trends

Ping and Telnet

Determine whether you can contact network file server nodes using "Ping" and "Telnet". If the response is extremely slow, then a problem may exist with the connections to the nodes. No delay indicates that the connections are normal, implying that the delay is occurring elsewhere. In this case, use LANsentry® Manager tools to determine whether packets are being lost or ignored.

LANsentry Manager Alarms View

Using the LANsentry Manager Alarms View, you can determine if any configured alarms have been triggered.

Search the Alarms View to see if any MAC events have been logged.

EXAMPLE: MAC events have not been logged for the network on which the UNIX users are attached.

Even though no alarms have occurred, errors may exist. For example, a lower rate of background errors may exist just below the alarm threshold. Based on maximum and minimum values, RMON errors may miss constant, periodic, or low amounts of errors.

66 56

LANsentry Manager Statistics View

Using the LANsentry Manager Statistics View, you can display a multisegment graph of utilization and error statistics.

Follow these steps:

1 .   Set up a graph that shows utilization and errors on all your major segments.

2 .   Determine whether any segments are particularly busy or error prone.

EXAMPLE: You notice that one segment of the UNIX network, HUB3, is reporting "Too Long Errors" and "FCS Errors" roughly every second sample. While the amount is not higher than normal, it is currently higher than any other segment.

LANsentry Manager History View

Using the LANsentry Manager History View, you can display a rolling history table to determine if the errors that you are seeing are new. For example, if you have a history table that runs for 30-minute samples over two days, you can compare the most recent sample to a previous sample, looking for new errors. If your probe has the resources, use a much finer resolution sample stored for a shorter time (every 30 seconds for 2 hours) to more easily spot recent errors.

EXAMPLE: You see that the history table shows that no error rates remained constant throughout the day. However, errors that did occur were on the device HUB3 and were Too Long Errors and FCS Errors.

Reproducing the Fault While Monitoring the Network

Although the RMON View in LANsentry Manager can show error rates and help you to identify the location of the problem, it may not provide enough data to solve the problem. To determine the cause of the problem, reproduce it while you monitor the network by using these applications:

LANsentry Manager Top-N Graph - To locate a quiet node to use for reproducing the fault LANsentry Manager Packet Capture - To capture packets from the hub to which the quiet node

is attached

LANsentry Manager Packet Decode - To analyze the packets to assess network file server traffic and delays

Address Tracker - To find the location of the problem nodes

66 57

EXAMPLE: Using LANsentry Manager, you find a hub on the network with a higher than normal error rate. However, the error rate does not seem high enough to cause login delays of 60 seconds or more.

LANsentry Manager Top-N Graph

Using the Top-N graph in the LANsentry Manager main window, locate a quiet node that has been showing the same problem. Choose a quiet node so that you do not receive excessive traffic when you try to isolate the problem.

EXAMPLE: You see that the node, Monolith, which has the same Network File System (NFS) mounts as the other nodes on the network, is quiet. You decide to use this node for reproducing the fault. See "Network File System (NFS) Protocol" for more information about NFS.

LANsentry Manager Packet Capture

Using the LANsentry Manager Packet Capture application, capture packets from the network using predefined patterns and start-and-stop conditions.

Follow these steps:

1 .   Set up a capture buffer on a probe that is connected to the same hub as the quiet node. Until you know more about the problem, set a very general filter.

EXAMPLE: You select a MAC-layer filter and set a conversation filter to capture all packets to and from Monolith.

2 .   Telnet into and log out from the quiet node. Then reset the capture buffer. Repeat this procedure until you see the problem reflected in your captured data. To keep the buffer information clean, reset the buffer each time that you repeat the procedure.

3 .   When you see the delay, note the rough value of the packet count on the LANsentry Manager packet buffer.

By noting the packet count at which you think the delay has occurred, you can narrow the problem to within about 20 packets in the buffer. If you have used an extremely quiet node, you may even identify the exact packet.

LANsentry Manager Packet Decode

The LANsentry Manager Packet Decode application decodes all major protocols and displays the packet contents at three levels of detail: summary information, header information, and actual packet content.

66 58

Follow these steps:

1 .   Open the buffer in the Packet Decode application and locate the number of the packet at which the delay occurred.

2 .   Select the packet and launch a MAC-layer conversation filter. In the filter display, look for a gap in the conversation (that is, where the node sent a request and then resent it at approximately the same rate as the delay you experienced when recreating the problem).

3 .   Repeat the test to determine if the result concentrates on one node or if it appears on other nodes.

EXAMPLE: On the quiet node that you selected, the delay is obvious. You see an NFS request going out to a node and a repeat of the request 30 seconds later. During that time, the node did not respond. You now know that the delay occurred because nodes were not seeing responses for NFS requests. When you repeat the test on other nodes, you find that the delay is happening with more than one destination node.

Address Tracker

Use Address Tracker, which polls managed devices, to determine the hubs to which the problem nodes are attached. If the problem end stations are located on unmanaged devices, then you can at least narrow the problem to those unmanaged devices.

EXAMPLE: Although your network does not have managed hubs that Transcend® NCS management software can poll, it does have managed switches. When it polls the switches, Address Tracker displays the switch ports on which addresses were last seen. This information indicates the hub (but not the hub port) on which the device is located.

LANsentry Manager Packet Decode

After you know the location of the hub that has the problem node, monitor the problem from the hub using LANsentry Manager Packet Decode.

Follow these steps:

1 .   To capture packets from one of the nodes on the hub, set up another capture buffer and repeat the exercise that is described in "LANsentry Manager Packet Capture". Because a delay may occur on a different node, use two capture buffers without stopping the first one.

Note the rough packet count where the delay appears.

66 59

2 .   Display a conversation filter of the packet where the delay appears and look for the gap in the conversation.

EXAMPLE: You hope that the nodes are on the same hub. You find that all the nodes are on HUB3. This result indicates that FCS Errors may be causing the timeouts. However, because the errors occur at a low rate, you decide to verify this diagnosis. You monitor the problem from the hub, logging in and out many times, and the delay eventually occurs. This time, the delay shows that the node's reply had an FCS Error even though the node received the request. The switch would not have transmitted this packet, causing a timeout on the NFS protocol. The retry time is presumably 30 seconds. During this test, you see the problem occurring on another node.

Correcting the Fault

Without a managed hub, you may find it very difficult to discover network file server timeout errors. To find the problematic node, you must either systematically isolate nodes by monitoring each node for a prolonged period or temporarily insert a managed hub.

EXAMPLE: You notice that the captured error packet failed FCS because it was corrupted by a regular pattern during transmission. A possible reason for this occurrence is a "Jabbering" node. This explanation makes sense because FCS/Jabber frames increased linearly when you were monitoring the live network.

Network File Server Timeouts Reference

This section explains terms that are relevant to network file server timeouts and provides additional conceptual and problem analysis detail.

Jabbering

When a node transmits illegal length packets and is possibly not operating within carrier specifications. In effect, another node has written bad data over a valid packet. This bad data is often interpreted as a repeated sequence of data.

Network File System (NFS) Protocol

A distributed file system protocol developed by Sun Microsystems that allows a computer system to access files over a network as if they were on its local disks. This protocol has been incorporated into products by more than 200 companies. It is now a de facto Internet standard.

66 60

NFS is one protocol in the NFS suite of protocols, which includes NFS, RPC, XDR (External Data Representation), and others. These protocols are part of a larger architecture that Sun Microsystems refers to as Open Network Computing (ONC). ONC is a distributed applications architecture designed by Sun and currently controlled by a consortium led by Sun.

Troubleshooting TCP/IP - Detailed Steps

This article shows how to troubleshoot TCP/IP connectivity between computers on a Windows network.  If you haven’t already done so, disable XP’s Internet Connection Firewall on all local area network connections, and remove all firewall programs on the network.   Improperly configured firewalls are the most common cause of TCP/IP problems.

Open a Command Prompt Window

For many of these steps, you’ll be typing at the command prompt.  To open a command prompt window in Windows 2000 or XP, click Start | Run, type cmd in the box, and click OK.  To open a command prompt window in Windows 95, 98, or Me, click Start | Run, type command in the box, and click OK.  Type one command per line, and press Enter after each one to execute it.  To close the command prompt window, use the exit command.

Determine the TCP/IP Settings

Determine the TCP/IP settings of each computer on the local area network.  In XP, open the Network Connections folder, right click the LAN connection, and click Status | Support | Details.  For example, here are the Status and Details views for the LAN connection on an Internet Connection Sharing host.

In Windows 95/98/Me, click Start | Run, type winipcfg in the box, and click OK.  Select the LAN adapter from the menu, and click More Info.  Here’s the winipcfg view for an ICS client running Windows Me.

You can also see the TCP/IP settings from the command prompt.  This is especially convenient if a computer has more than one network adapter.  Use the ipconfig /all command, which is available in all versions except Windows 95.  The output from this command can be long, so it’s best to write it to a file.  Specify the file name in the command this way:

   ipconfig /all >ipconfig.txt

66 61

Description of TCP/IP Settings

Here are the TCP/IP settings that are used in network troubleshooting:

IP Address – Unique address assigned to a network adapter.  A computer with multiple network adapters has an IP address for each one, and each one must be in a different subnet.

Subnet Mask – Used in conjunction with the IP address to determine which subnet an adapter belongs to.  At the simplest level, communication is only possible between two network adapters when they’re in the same subnet.

Default Gateway - IP address of a computer or router, on one of this computer’s local area networks, that knows how to communicate with subnets not present on this computer.  For an Internet connection, the default gateway is a router belonging to your Internet service provider, and all access to sites on the Internet goes through it.  For an ICS client, the default gateway is the ICS host.  If you use a hardware router, it serves as the default gateway.

DHCP Server – If an adapter is configured to obtain an IP address automatically, this is the address of the server that provides it.  It could be your ISP, an ICS host, or a hardware router.

DNS Servers – IP address of one or more Domain Name Server computers.  DNS servers translate Internet names to their IP addresses (like 63.146.109.227).

Subnets

See our article on subnets for a brief description of how they work.  For more details, see this Microsoft Knowledge Base article.

If two computers are supposed to be on the same subnet, but aren’t, something is wrong with the network hardware or software configuration.  This is most likely to happen when one of them receives an IP address of 169.254.x.x, which indicates that:

It’s configured to obtain an IP address automatically. It couldn’t find a DHPC server on the network to make the assignment.

Windows assigned it an Automatic Private IP Address.

See our article on Specific Networking Problems and Their Solutions for more information.

Pinging

The ping command is the basic tool for testing TCP/IP connectivity.  It sends a special packet (called ICMP Echo) to a particular IP address and looks for a reply.  If everything is working right, the reply comes back.  If not, the ping times out in a few seconds.  By default, the ping command repeats the process four times.  Here’s an example of an ICS client

66 62

computer pinging a Windows XP Home Edition ICS host, using the host’s IP address and its computer name.

When ping fails, you’ll see one of these error messages:

Request timed out - The IP address is valid, but there’s no reply from it.  If the IP address is on a local area network, the most likely cause is a firewall program blocking the ping.

Unknown host <name> or Ping request could not find host <name> - The computer name doesn’t exist on the local area network.  Make sure that NetBIOS over TCP/IP is enabled.

Destination host unreachable – The IP address isn’t on a local area network, and the default gateway can’t access it.  Either there’s no default gateway, its address is wrong, or it isn’t functioning.

Pinging the Local Area Network

Here is a series of ping commands to use in finding where a problem occurs on a local area network.  Run them in the order shown, and don’t go on to the next command until all of the previous commands work properly.  In this example:

The computer being tested is named Winxp, with IP address 192.168.1.101. There’s another computer on the network, named Win98, with IP address

192.168.1.123

Substitute the appropriate IP addresses and computer names for your network.

Command Target What Ping Failure

Indicates

ping 127.0.0.1 Loopback address Corrupted TCP/IP

installation

ping localhost Loopback name Corrupted TCP/IP

installation

ping 192.168.1.101 This computer’s IP address

Corrupted TCP/IP

installation

66 63

ping winxp This computer’s name

Corrupted TCP/IP

installation

ping 192.168.1.123 Another computer’s IP

address

Bad hardware

or NIC driver

ping win98 Another computer’s name

NetBIOS name

resolution failure

To fix a corrupted TCP/IP Installation on Windows XP, follow the steps in this Microsoft Knowledge Base article. For Windows 95/98/Me, un-install the TCP/IP protocol in Control Panel | Network, reboot, and re-

install it.  If that doesn’t fix it, use this procedure on Windows 95 or 98.

Pinging the Internet

You can also use ping to find a problem with Internet access.  Run these commands in the order shown, and don’t go on to the next command until all of the previous commands work properly.  Use the Default

Gateway and DNS Server addresses that you got from the winipcfg or ipconfig /all command. 

CommandTargetWhat Ping Failure Indicatesping w.x.y.zDefault GatewayDefault Gateway downping w.x.y.zDNS ServerDNS Server downping w.x.y.zWeb site IP

addressInternet service provider or web site downping www.something.comWeb site nameDNS Server down or web site down

66 64

REFRENCEWWW.PRACTICALLYNETWORK.COM

WWW.COMPUTERHOPE.COM

WWW.WIKIPEDIA.ORG

66 65

THANK YOU

66 66