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 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.

63 1
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 [Link]

or

ping localhost

63 2
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: [Link]
Subnet Mask: [Link]

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
[Link] on another computer and then specify the same Subnet Mask.

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

63 3
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 [Link], you would type:

ping [Link]

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 [Link], type:

tracert [Link]

or

traceroute [Link]

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

63 4
 • 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.

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.

63 5
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.

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.

63 6
 Table 5 Network Data and the OSI Model Layers
Layer Data Collected TranscendcNCS Tool Used
Application
• LANsentry
Presentation Manager
Protocol information and other Remote Monitoring (RMON) and
RMON2 data
Session • Traffix Manager
(for more detail)
Transport
• Status Watch
• LANsentry
Manager
Network Routing information (for more detail)

• Traffix Manager
(for more detail)
• Status Watch

Data Link Traffic counts and other packet breakdowns • LANsentry

Manager
(for more detail)
Physical Error counts • Status Watch

Figure 1 OSI Reference Model and Network Troubleshooting

63 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?
• Does the change interfere with vital network operations?
• Does the change affect one or many devices or network paths?

63 8
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.
• 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:

63 9
 • 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
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:

63 10
 • 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.

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 -

63 11
 • 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.

• 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.

63 12
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.

• 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)

63 13
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

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

63 14
 • 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

• 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".

63 15
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:

• 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

63 16
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.
• 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.

63 17
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
• 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:

63 18
 • 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.
• 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.

63 19
 <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.

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

63 20
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.

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.

63 21
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:

• 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

63 22
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
• 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

63 23
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:

• 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

63 24
 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.

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.

63 25
 • 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.

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.

63 26
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

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.

63 27
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.

Identifying the Problem

To identify the problem, follow this process:

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

63 28
 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.
• 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.

63 29
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

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

63 30
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

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.

63 31
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:

• 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.

63 32
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
M-M A tree of rings topology (illegal connection)

Table 8 lists FDDI connections that create valid topologies.

Table 8 Valid Connection Types

Connection
Reason That the Connection Is Valid
Type
A-B A normal trunk peer connection
A tree connection with possible redundancy. In a single MAC node, Port B has
A-M
precedence (by default) for connecting to a Port M.
B-A A normal trunk ring peer connection
A tree connection with possible redundancy. In a single MAC node, Port B has
B-M
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

63 33
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.

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

63 34
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:

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.

63 35
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
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

63 36
 • 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

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

63 37
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.

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.

63 38
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.

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.

63 39
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.

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

63 40
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
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.

63 41
 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

Possible Problem Possible Action
Faulty cabling Examine the cable and cable connections for breaks or damage.
Look for improper cabling, faulty cable, faulty network equipment, or cables that are too close
Network noise
to equipment that emits electromagnetic interference (lamps, for example).
Use an analyzer to identify the problematic transceiver. If necessary, replace the transceiver,
Faulty transceiver
network adapter, or station.
1 . Locate the source of the errors by looking at the module and port statistics.

Fault at the 2 . Verify the correct operation of the transceiver or adapter card of the device that is connected
transmitting end to the problem port.
station
3 . If the card appears to be operating correctly, examine the cable and cable connections for
breaks or damage.
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
Station powering up
stable network.
or down
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
Use a bridge, router, or switch to reconfigure your
Busy network
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 Isolate each adapter to see if the problem stops.
all types of collisions.
Ensure that no redundant connections to the same
Network loop station have both connections active
simultaneously.

63 42
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:
• 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

63 43
 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:
Correct the cabling problem by doing one or more of the following:

• Segment too long

• Reduce the segment length.
• Failing cable
• Replace the cable.
• Segment not grounded
• Ground the cable.
properly (noise)
• Terminate the cable correctly.
• Improper termination
• Check the taps.
• Taps too close (10BASE-5 and
10BASE-2 only)
• Check for cables too close to equipment that
emits electromagnetic interference.
• Noisy cable
Component problems:
Correct the component problem by doing one of the following:

• Deaf or partially deaf node

• Trace the failing component and replace it.

• Failing repeater, transceiver,

• Replace the NIC or the transceiver.
or controller cards

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

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 1 . Use a network analyzer to identify the problematic
that are transmitted by the attached station. transceiver.

63 44
 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 Replace the network card.
produced by the attached station.
Check for improper cabling, faulty cable, faulty network
Excessive noise on the cable equipment, or cables too close to noisy electronic
equipment (lamps, for example)
Note: Some 10/100 Mbps cards that autodetect the network
speed may connect to the network at the wrong speed, If your network card autodetects the network speed, and
causing excessive noise. you have ruled out other problems, manually configure
the network speed.
Faulty routers (two different network types are connected
Notify the manufacturer.
and the router is not enforcing proper frame size restrictions)
Faulty LAN driver Replace the driver.
® ®
A normal condition on a LinkSwitch 1000, LinkSwitch
These frames are passed successfully but will create the
3000, or CoreBuilder 5000 FastModule
Too Long Frame error message.
If you use maximum-sized, 1518 Ethernet frames, the
If you want to eliminate the error message, reduce your
device's VLT-enabled ports add a frame tag of 4 bytes,
Ethernet packet frames by 4 bytes.
resulting in a misleading Too Long Frame error.

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
Description Use in Troubleshooting
Group
Activity Displays the total This data shows readable packets, broadcast packets, "Collisions", total errors,
network activity and and runts, which cause "Too Short Errors". You can interpret this data in the
errors on the selected following ways:
port.
• 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

63 45
 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.
The significance of errors depends on accompanying errors and prevailing
network conditions. See the following error data for more information:

Displays the number of • Alignment Errors, Table 16

Errors frames with errors on • FCS Errors, Table 16
the selected port. • 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.

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.

63 46
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.

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

63 47
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 If you use a promiscuous network monitor, the number of
"Alignment Errors" Network cabling is too long. Late Collisions reported by stations should correlate with
increase significantly. the FCS and Alignment Errors reported by the monitor.
Typically observed on a 10BASE-T network segment in a
noisy environment. If you use multiple promiscuous
FCS and Alignment Errors monitors, the FCS and Alignment Errors among the
increase proportionally monitors will not correlate.
with interference Network segment is noisy.
(sometimes referred to as
noise hits). 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 Networks do not conform to Occurs when some implementations of Ethernet in the
are much higher than the access scheme of Carrier segment are not entirely compatible with IEEE 802.3
normal. Sense Multiple Access with repeaters.
Collision Detect
(CSMA/CD). 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

63 48
 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:

• 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

63 49
 • 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:

• 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

63 50
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
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:

63 51
 • 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

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.

63 52
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".

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

63 53
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.

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,

63 54
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

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.

63 55
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.

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.

63 56
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.

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

63 57
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.

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.

63 58
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 >[Link]

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

63 59
 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 [Link]).

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 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.

63 60
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 [Link].

• There’s another computer on the network, named Win98, with IP address
[Link]

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

Command Target What Ping

Failure
Indicates

ping [Link] Loopback address Corrupted

TCP/IP
installation

ping localhost Loopback name Corrupted

TCP/IP
installation

ping [Link] This computer’s Corrupted

IP address TCP/IP
installation

ping winxp This computer’s Corrupted

name TCP/IP
installation

ping [Link] Another Bad

computer’s IP hardware
address or NIC
driver

ping win98 Another NetBIOS

computer’s name 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.

63 61
 CommandTargetWhat Ping Failure Indicatesping [Link] GatewayDefault
Gateway downping [Link] ServerDNS Server downping [Link] site IP
addressInternet service provider or web site downping [Link]
site nameDNS Server down or web site down

REFRENCE
[Link]

[Link]

[Link]

63 62
 THANK YOU

63 63