Gathering Network Symptoms

Figure 5-1 displays the process of gathering symptoms from a network using a flowchart. Figure 5-1 sends the message that you must first ascertain that the problem is within your area of responsibility. Next, you must determine whether the symptoms and facts gathered are enough to identify the cause and take corrective actions. Sometimes gathering more facts is necessary; when you have gathered enough information and determined the cause, you can take corrective actions.

The stages of gathering network symptoms are as follows:

■ Stage 1: Analyze Existing Symptoms—In Stage 1, you must define the problem. This entails analyzing any gathered symptoms from the trouble ticket, the users, or from the end systems that are affected by the problem. The problem description must be short yet accurate.

■ Stage 2: Determine Ownership—In Stage 2, you must determine whether solving the problem at hand is your responsibility or must be handled by someone else. If the problem is in the system that you are responsible for, move on to Stage 3. If the problem is outside the boundary of control for you, contact an administrator for the external system.

■ Stage 3: Narrow Scope—In Stage 3, you determine whether the problem is at the core, distribution, or access layer of the network. At the identified layer, analysis of existing symptoms and knowledge of the network topology helps determine which segment, device, or component is the most likely culprit.

Gathering Network Symptoms 77

Figure 5-1 The Process of Gathering Symptoms from a Network

Figure 5-1 The Process of Gathering Symptoms from a Network

■ Stage 4: Determine Symptoms—During Stage 4, you gather hardware and software symptoms from the suspect devices using a layered troubleshooting approach. You must start with the most likely culprit and use your knowledge and experience to determine whether the problem is more likely a hardware or software configuration problem. Gathering symptoms and facts about hardware that is perceived to be malfunctioning is effective if you physically inspect the suspected devices. In contrast, when you are gathering symptoms for possible software configuration problems, you should use Cisco IOS commands to check the status of various aspects of the suspected devices.

■ Stage 5: Document Symptoms—In Stage 5, you document any hardware or software symptoms. If you can solve the problem by using the documented symptoms, you should solve the problem and document the solution. If you cannot solve the problem, you must begin the Isolating phase of the general troubleshooting process. Table 5-2 describes the common Cisco IOS commands that you can use to gather symptoms about a network.

Table 5-2 Cisco IOS Commands for Gathering Network Symptoms

Command

Description

ping {host | ip-address}

Sends an echo request packet to an address and then waits for a reply. The {host | ip-address} variable is the IP alias or IP address of the target system.

traceroute {host | ip-address}

Identifies the path that a packet takes through the network. The {host | ip-address} variable is the IP alias or IP address of the target system.

continues continues

Table 5-2 Cisco IOS Commands for Gathering Network Symptoms (Continued)

Command

Description

telnet {host | ip-address}

Connects to an IP device using the Telnet application. The {host | ip-address} variable is the IP alias or IP address of the target system.

show ip interface [brief]

Displays a summary of the status of all interfaces on a device.

show ip route

Displays the current state of the IP routing table.

show running-config

Displays the contents of the currently running configuration file.

[no] debug ?

Displays a list of options for enabling or disabling debugging events on a device.

NOTE Be prudent with your use of the debug command on a network. It generates enough output to noticeably affect the performance of a network device. Be sure to disable debugging as soon as you have achieved your objectives.

0 0

Post a comment