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.

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. 

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

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