When gathering symptoms, it is important that the administrator gather facts and evidence to progressively eliminate possible causes, and eventually identify the root cause of the issue. By analyzing the information, the network administrator formulates a hypothesis to propose possible causes and solutions, while eliminating others.

There are five steps to gathering information:

Step 1. Gather information - Gather information from the trouble ticket, users, or end systems affected by the problem to form a definition of the problem.

Step 2. Determine ownership - If the problem is within the control of the organization, move onto the next stage. If the problem is outside the boundary of the organization’s control (for example, lost Internet connectivity outside of the autonomous system), contact an administrator for the external system before gathering additional network symptoms.

Step 3. Narrow the scope - Determine if the problem is at the core, distribution, or access layer of the network. At the identified layer, analyze the existing symptoms and use your knowledge of the network topology to determine which piece of equipment is the most likely cause.

Step 4. Gather symptoms from suspect devices - Using a layered troubleshooting approach, gather hardware and software symptoms from the suspect devices. Start with the most likely possibility and use knowledge and experience to determine if the problem is more likely a hardware or software configuration problem.

Step 5. Document symptoms - Sometimes the problem can be solved using the documented symptoms. If not, begin the isolating stage of the general troubleshooting process.

Use Cisco IOS commands and other tools to gather symptoms about the network, such as:

The table in the figure describes the common Cisco IOS commands used to gather the symptoms of a network problem.

Note: Although the debug command is an important tool for gathering symptoms, it generates a large amount of console message traffic and the performance of a network device can be noticeably affected. If the debug must be performed during normal working hours, warn network users that a troubleshooting effort is underway and that network performance may be affected. Remember to disable debugging when you are done.