Gathering Symptoms

Chapter 5, "Gathering Symptoms," presents a flow diagram (see Figure 13-1) that depicts the process of gathering symptoms from a network.

Figure 13-1 Gathering Network Symptoms

Figure 13-1 Gathering Network Symptoms

The process of gathering symptoms from a network is composed of the following steps:

1. Analyze Existing Symptoms—After you gather symptoms from the users, end systems, or trouble ticket documents, you must analyze the symptoms and describe the problem.

2. Determine Ownership—Based on the gathered symptoms, analysis of the symptoms, and resulting problem definition, you must decide whether the devices or the territories affected fall within your area of responsibility. If they do not, you must contact the administrator(s) or the personnel responsible; otherwise, go to the next step.

3. Narrow Scope—Based on your knowledge, past experience, and symptoms observed, determine if the problem is at the access, distribution, or core layer. Then try to narrow the scope to one of a few devices or segments within the determined layer.

4. Determine Symptoms—Using a layered troubleshooting approach, you must gather further data and symptoms from the suspected devices and decide whether the problem is hardware related or if it is a software configuration problem. Finally, you must determine what might be the most likely culprit.

5. Document Symptoms—At this stage, you must document all your findings and the symptoms observed. If you can solve the problem(s), you must proceed to do so. Otherwise, you must start the Isolating stage of the general troubleshooting process.

The following scenario presents a realistic case that required a network support engineer to go through the stages of gathering network symptoms. The users within the Toronto branch office of a company have reported that they can no longer communicate with the users and servers who reside in other branches. Figure 13-2 depicts how the users are connected to the Toronto branch office's TorASW switch, and how the Toronto office is connected to the other company offices residing in Canada and the United States via a Frame Relay service.

Figure 13-2 Diagram of the Toronto Branch Office

Figure 13-2 Diagram of the Toronto Branch Office

As per the guidelines for gathering symptoms from users, the network engineer asks the users the following questions and makes note of the answers:

■ What works and what doesn't work?

Users state that they can communicate among themselves, but they cannot communicate with the users or servers who reside outside their branch.

■ Could you communicate with the users and servers residing in other branches before? When was the last time you did? And when did you first notice the problem?

Users say that those functionalities were lost after their lunch break. They could communicate with the remote devices before noon.

■ Did you change anything or are you aware of any changes that took place around noon?

Most users do not report making changes or being aware of changes, but a couple of them said that they heard rumors in the cafeteria about some wide-area connection problems. (Whatever that means!)

Next, the network engineer decides to see the problem for herself and observes that as the local users stated, their computers can communicate, but they cannot connect to the devices in other branches.

The network engineer tests connectivity of user workstations to their default gateway (Toronto router) and notices that is also okay. Then the network engineer decides to Telnet to the Toronto router and test its Frame Relay (serial) connection to the other branches. She notices that the Toronto router has lost all its Frame Relay connections to the other branches. Evidently, what the users have heard in the cafeteria about the wide-area connection being down is valid. However, the wide-area connection and service is outside of this network engineer's ownership and responsibility, so she documents her findings and notifies the personnel in charge of the Toronto office's wide-area connection about the problem.

0 0

Post a comment