|
Did you arrive at this page because you need to troubleshoot
a network failure symptom that requires running a protocol analysis session
to examine the low-layer 802.5 frame communication processes?
 Go
to page 15.1
Did you arrive at this page because you are encountering a
specific soft or hard error on the network, or the network is freezing
or hanging?
Go
to page 15.2
Did you arrive at this page because you need to troubleshoot
a network failure symptom that requires running a protocol analysis session
to examine the high-layer network frame communication processes?
Go
to page 15.3
Is the network experiencing any of the following failure symptoms:
The whole network is operating slowly; a specific network application is
operating slowly; or log-on failures are occurring?
Go
to page 15.4
 While using these procedures,
keep in mind the prescribed approach for a general protocol analysis session:
capture, view, analyze, check errors, benchmark performance, and focus.
15.1 Perform
a protocol analysis session to examine the low-layer 802.5 frame communication
processes.
First, start the protocol analysis session by establishing the network
baseline of operations. Set up the protocol analyzer to perform a full
capture.
If the higher-layer protocols
are clouding your testing results, you can filter them out, so as to focus
more closely on the low layers.
Closely examine the 802.5 low-level frame communication processes. Interrogate
all the base 802.5 MAC data frames as to how they respectively correlate
with the time-related Token Ring communication processes captured in the
protocol analysis session.
Scrutinize the current state of low-level 802.5 frame communications
exchange between the network entities involved for proper and fluent protocol
exchange. Specifically, if you are troubleshooting a certain network component,
such as a gat eway, router, bridge, ring station, file server, network
peripheral, and so on, look for the low-level 802.5 frame communication
processes associated with that specific network device's Token Ring address.
In other words, are there any noticeable deviations from a normal state
of low-level frame communication process that may indicate a possible failure
within a fault domain or a specific network component? (Refer to the Token
Ring Soft Error descriptions .)
Did you find any deviations from the normal state of low-level 802.5
frame communication processes that indicate a possible failure within a
fault domain or a specific network component failure?
Take the necessary action to resolve the problem by going to the page
for that specific network component (such as 6
Ring Station Problems , 10 Network Peripheral
Problems , 14 File Server Problems ,
and so on).
If you are not completely conclusive as to a specific network component
that may be related to the failure symptom, go to page
2 and troubleshoot the respective Token Ring addresses associated in
the frames (that is, the possible fault domain) that deviate from the normal
state of communication.
If after going to the respective fault domain, network area, or network
component you find a problem, resolve the problem and retest the ring by
coming back to this page (15). Rerun another baseline session to test the
ring. If there are no more deviations from the normal state of operations,
record the problem in the network maintenance and service log. If the problem
still exists after rerunning another session, go to the next
step .
 Go to the next
page, 15.2.
15.2 Encountering
specific soft or hard errors on the network, or the whole network is freezing
or hanging.
Keep in mind that abnormal
high network bandwidth usage can cause performance degradation on the network
that can present itself in the form of soft or hard error conditions. If
you immediately suspect high bandwidth as a problem, first go to page
15.4 and analyze the network bandwidth. If at this point you feel that
the bandwidth is within normal parameters, continue with the following
steps.
Remember that by using any
available error alarm triggering features with your protocol analyzer,
you can observe more dynamically any particular errors as they occur. Examine
the captured data from the respective protocol analysis session for any
recorded soft or hard error cond itions.
If any soft errors are recorded, go to S1.
If any hard errors are recorded, go to S2.
S1
Soft Errors
Keep in mind that soft errors
are the less-critical type of errors that can occur on the ring, and they
do not always indicate a definite problem with any associated network component
through a Token Ring address. They may, however, indicate a marginal failure
with that network component. When following any recommended paths in the
following soft error procedures, use your own logical thought processes
as to the degree of seriousness of the failure symptom that is occurring
before taking any corrective action.
When examining the type of
soft error captured during the protocol analysis session, look closely
at the Report Soft Error MAC frame for the following information and take
appropriate notes: the type of soft error and both associated addresses
in the MAC frame.
Remember that the Report
Soft Error MAC frame contains the soft error counter field, which is a
12-byte field: 10 of the bytes actually represent soft error types, and
the other two bytes are reserved for future use. The hexadecimal value
of a particular soft error byte indicates the actual soft error count for
the soft error type.
Examine the respective Report Soft Error MAC frame captured during the
protocol analysis session for the type of soft error and both associated
addresses in the MAC frame. Place your captured soft error type into one
of the ten soft error type categories
, and then go to that soft error type. Next, use the address information
along with the present ed isolation solution to identify the soft error
failure cause.
Remember that when experiencing
intermittent problems such as soft errors on a Token Ring network, you
can use traffic-generation techniques to load the network with additional
traffic to flush out certain types of intermittent failure causes. By generating
additional network traffic, you can stress the network enough to cause
certain marginal network component failures to surface.
If a particular soft error
occurs frequently and you have thoroughly analyzed the respective soft
error and followed the recommended troubleshooting steps, yet cannot conclusively
locate a failure cause for the error, go to page 15.4
and analyze the network bandwidth.
S2
Hard Errors
Remember that hard errors
are the more critical category of errors that can occur on the ring. They
are actual solid failures with a specific network component and take the
form of a failure symptom by the beaconing process.
If you encounter a hard error in a protocol analysis session, the first
step is to examine the Beacon MAC frame for the following information:
* The assigned fault domain addresses: reporting
ring station and the reporting station's NAUN.
* The Beacon type. When a hard error occurs and
a Beacon MAC frame is captured, troubleshoot the addresses in the assigned
fault domain by going to page 2 . Keep
in mind that if the Beacon type is a signal loss error, the failure cause
is most likely a cable fault in the cabling medium internal to the assigned
fault domain.
If a hard error occurs frequently,
and you have thoroughly analyzed the Beacon MAC frame and followed the
recommended troubleshooting steps for the fault domain and yet cannot conclusively
locate a failure cause for the error, go to page 15.4
and analyze the network bandwidth.
15.3 Perform
a protocol analysis session; to examine the high-layer network frame communication
processes.
Have you verified that the 802.5 base frame communication processes
are proper and fluent as to low-level protocol exchange?
Go to S1.
Go back to
page 15.1 and troubleshoot the low-level 802.5 base communication processes.
S1
First, perform a full-capture session. Next, view the high-layer protocol
communication that occurs concurrently between the network components (the
ring stations, network peripherals, gateways, bridges, routers, file servers,
and so on) involved in the high-layer communication processes that you
are troubleshooting. Closely examine the application and network operati
ng system communication process between the respective network components.
Keep in mind that certain
applications may use multiple layers of the Token Ring protocol model for
transmission. Check all the higher layers.
Are the involved network components and their respective application/network
operating system communication processes exchanging the correct assigned
protocol?
Reference the NOS and software
application manufacturers' manuals and if necessary contact your NOS and
software support channel for assistance with troubleshooting any suspected
high-layer communication process.
Continue.
Does the incorrect protocol exchange appear to be related to some
sort of file access process problem with a particular NOS or software application?
Reference the NOS and software
application manufacturers' manuals and if necessary contact your NOS and
software support channel for assistance with troubleshooting any suspected
high-layer communication process.
Check the network components involved
in the specific high-layer communication process that you are troubleshooting
for a possible failure by going to the page for that particular specific
network component (such as 6 Ring Station
Problems , 10 Network Peripheral Problems
, 14 File Server Problems , and so on).
If you are not completely conclusive as to a specific network component
that may be related to the failure symptom, go to page
2 and troubleshoot the respective Token Ring addresses associated in
the high-layer frames that appear to be involved with failure symptoms.
If after going to the respective fault domain, network area, or network
component you find a problem, resolve the problem and retest the ring by
going back to page 15 and rerun another
baseline session to test the ring. Then reexamine the high-layer communication
processes for any deviations from the previous testing results.
If everything appears normal, record the problem in the network maintenance
and service log. If the problem still exists, contact your NOS and software
support channel for assistance with troubleshooting any suspected high-layer
communication process
15.4 The
network is experiencing one or more of the following failure symptoms:
"the whole network is operating slowly"; " a specific network application
is operating slowly"; or "log-on failures are occurring."
First, set up the protocol analyzer or network monitoring tool to monitor
the network bandwidth utilization at an overall baseline view.
Is the overall network baseline within normal operating levels of
a previously established baseline for your network?
If you do not have a previously
established baseline for your network, attempt to identify that a reasonable
portion of the available maximum bandwidth is still available for use.
Go back to the beginning of this
procedure ( page 15) and follow the subsec tions of this complete procedure.
(That is, examine the low-layer 802.5 frame communication processes; check
for specific soft or hard errors on the network; and examine the high-layer
network frame communication processes.)
Check the overall baseline network
bandwidth as to individual ring stations and all other network components'
level usage. Attempt to locate a particular ring station or other network
component that may be absorbing abnormal bandwidth.
Can you locate any particular ring stations or other network components
that may be absorbing abnormal bandwidth?
If you have not troubleshot the
high-level communication process on the ring, go back to page
15.3 and thoroughly troubleshoot the high-level communication process
for any NOS or application communication processes that may be absorbing
abnormal bandwidth. After analyzing the high-layer communication process,
come back to this page (15.4) and remeasure the baseline network bandwidth.
If you have troubleshot the high-level communication processes, go to the
next step .
Even though you cannot specifically
locate any particular ring stations or other network components that may
be absorbing abnormal bandwidth, still check any ring stations or network
components that are suspect by going to the page for that particular specific
network component (such as 6 Ring Station
Problems , 10 Network Peripheral Problems
, 14 File Server Problems , and so on).
If you are not completely conclusive as to a specific network component
that may be related to the failure symptom, go to page
2 and troubleshoot the respective Token Ring addresses associated with
high bandwidth usage.
If after going to the respective fault domain, network area, or network
component you find a problem, resolve the problem and retest the ring by
coming back to this page. Rerun another baseline bandwidth test session
to reexamine the ring for bandwidth usage.
If everything appears normal, record the problem in the network maintenance
and service log. If the problem still exists, contact your NOS and software
support channel for assistance with troubleshooting any suspected network
bandwidth issues.
If you have benchmarked the
network bandwidth utilization at overall baseline view and usage of the
individual ring stations and other network components, and you still have
a bandwidth problem that you cannot locate, contact your NOS and software
support channel for assistance with troubleshooting any suspected bandwidth
problem.
November 15, 1996
|