usually produces collisions, late collisions, and
FCS errors.
Content 3.2 Characteristics of
Physical Layer Optimization Problems 3.2.6
Resources If network resources are operating at or are near
maximum capacity, this can be the cause of physical layer
problems. In some instances of sub-optimal network performance,
data may flow at expected rates, but it will start and stop
unexpectedly. In other instances the data will flow
continuously, but not at a desirable rate.Poor performance may
be caused by the same conditions that prevent a connection from
being established in the first place, or from the same
conditions that cause connections to drop. The following
procedures assume that this connection has been operating
properly prior to this problem, and the following have already
been checked: - Verified that nothing has been recently
changed on the problem station, or on the server or service
that may have caused this problem, such as reconfiguring or
adding new software or hardware.
- Eliminated
potential station memory allocation problems and software
conflicts on the station by unloading all but the minimum
software required to operate a test application across the
network. For this test disable any virus checking or security
software, but re-enable it immediately after the test.
- Tested the user’s station for viruses and look for
applications that are consuming disproportionate amounts of the
microprocessor resources or hanging the system long enough to
exceed connection timers.
The most common reasons
for slow or poor performance include overloaded or underpowered
servers, unsuitable switch or router configurations, traffic
congestion on a low capacity link, and chronic frame loss.
Content 3.2 Characteristics of Physical Layer
Optimization Problems 3.2.7 Utilization A
component may be operating sub-optimally at the physical layer
because it is being utilized at a higher average than it is
configured to operate. When troubleshooting this type of
problem, it will become evident that resources for the device
are operating at or near the maximum capacity and there is an
increase in the number of interface errors. Gathering symptoms
reveals excessive runts, late collisions, or an increase in the
number of buffer failures. The output from a ping or
traceroute command results in excessive packet loss or
latency. How Much Utilization is ok?
Shared Ethernet
networks are believed to suffer from throughput problems when
average traffic loads approach a maximum average capacity level
of 40 percent. This percentage is actually conservative. Higher
average percentages are certainly possible. The classic
solution to excessive traffic is to micro-segment LANs by
installing switches. This solution works well until the amount
of broadcast traffic grows too large. Since bridges and
switches always forward all broadcast traffic to all ports,
even infrequent broadcasts from each station will eventually be
too many when the station count for the broadcast domain goes
up. If a single station is connected to a half duplex switch
port acceptable utilization is best learned by monitoring
switch port statistics. There will be some level of collisions,
but since there are only two devices on that link (the switch
and the station) the utilization level should be capable of
averaging quite high. There will likely be excessive collisions
errors reported by the switch periodically, resulting from the
Ethernet capture effect. This problem is not terribly
significant overall, and will result in a slight reduction in
performance. If the link is allowed to negotiate to full duplex
instead of half, the connection should be capable of
approaching theoretical limits for full line rate Ethernet.
This will depend on the processing power of the attached
station. The current generation of switches is quite capable of
sustaining line-rate traffic at the minimum frame size. Another
problem can occur when access to servers or services is reached
through a single switch uplink path. Unless the bandwidth of
the uplink path is bigger than the total of simultaneous
station requests, the uplink itself becomes a bottleneck. This
scenario arises when a network is designed with all servers
collected in a server farm, separated from the VLANs they
serve. Network bottlenecks or congestion typically manifests
itself to users with the following symptoms: - Highly
variable response times
- Network time-outs or server
disconnects
- Inability to establish network
connections
- Slower application loading and/or
running
Even when network resources are on the same
LAN segment as the users, it is still necessary to examine the
network architecture to see if bottlenecks exist. If too much
traffic is required to pass through an inadequate aggregation
path then a potentially useful architecture design is defeated.
To prevent this, the network administrator should limit
inter-segment traffic by carefully considering which nodes
should attach to each segment. The process involves an
investment of time and may need to be repeated regularly on
extremely dynamic networks. Monitor uplink paths as a part of
routine maintenance in order to detect impending saturation of
any one path.
Content 3.2 Characteristics of
Physical Layer Optimization Problems 3.2.8
Console messages All error messages begin with a percent
sign, and are displayed in the following format:
%FACILITY-SEVERITY-MNEMONIC: Message-text FACILITY is a code,
consisting of two to five uppercase letters, indicating the
facility to which the message refers. A facility may be a
hardware device, a protocol, or a module of the system
software. Figure lists the codes for some of the system
facilities. SEVERITY is a single-digit code from 0 to 7 that
reflects the severity of the condition. The lower the number,
the more serious the situation. Figure lists the severity
levels. MNEMONIC is a code, consisting of uppercase letters
that uniquely identify the message. Message-text is a text
string describing the condition. This portion of the message
sometimes contains detailed information about the event being
reported, including terminal port numbers, network addresses,
or addresses that correspond to locations in the system memory
address space. Because the information in these variable fields
changes from message to message (see below), it is represented
here by short strings enclosed in square brackets ([ ]). For
example, a decimal number is represented as [dec]. A complete
list of the kinds of variable fields, and the information
contained in them, appears in Figure . Some example error
messages could be as follows: Error message:
%HELLO-2-NORDB: Redistributed IGRP without rdb In this message,
HELLO is the facility, 2 is the severity, and NORDB is the
MNEMONIC. This message indicates that an internal software
error has occurred. The corrective action in this case is to
contact technical support for assistance. Error
message: %IP-4-DUPADDR Duplicate address [inet] on [chars],
sourced by [enet] This error message indicates that two systems
are using an identical IP address and that it should be changed
on one of the two systems. Web Links System Error
Messages http://www.cisco.com/univercd/cc/
td/doc/product/software/ssr83/tsc_r/4041.htm
Content
3.3 Windows and Cisco Commands for
Physical Layer Information Gathering 3.3.1
End-system commands – common commands In order to gather
information on a physical layer problem it is important to be
familiar with end-station commands that exist for this purpose.
Interrogating devices at the periphery of the network is a good
idea when end-systems are experiencing connectivity problems.
There are a number of commands that are common to the popular
operating platforms like Windows, UNIX and Mac OS. These can be
used to ascertain whether an end station is achieving
connectivity with the network. The ping {host |