Back

Troubleshooting Process

# Fundamentals
Easy

1.1 Diagnostic and Troubleshooting Methodologies

1.1.1 Review of the Troubleshooting Process

Troubleshooting is the process of identifying, locating, and correcting problems. We should collect information and use one or more structured troubleshooting methods.
When a network problem is first discovered, one of the initial steps is to gather information. The following are examples of information that may be useful:
  • Determine the nature of the problem.
    • Reports from end users.
    • A problem verification report.
  • Collect relevant equipment information.
    • Manufacturer.
    • Brand and model.
    • Firmware version.
    • Operating system version.
    • Ownership and warranty information.
  • Collect configuration and topology information.
    • Physical and logical topologies.
    • Configuration files.
    • Log files.
  • Determine whether similar problems occurred before.
    • Steps that were taken.
    • Results that were achieved.

1.1.2 The Seven-Step Troubleshooting Process

The seven-step troubleshooting process is a detailed approach for resolving network problems. Some steps are interconnected, allowing experienced technicians to move between them according to the situation and their experience.
The seven-step process is interconnected. Experienced technicians may move between steps according to the nature of the problem and the information already available.

Define the problem

  • Verify and define the problem correctly.
  • Identify symptoms, such as a slow network or dropped connections.
  • Collect symptoms from multiple sources.
    • System alerts.
    • End-user reports.
    • System logs.
    • Console messages.
  • Limit the scope of the problem.
  • In organizations, problems are commonly assigned through support tickets.
Ticketing systems, self-service portals, and searchable knowledge bases are commonly used to track progress.

Gather information

  • Identify the targets of the investigation, such as devices, systems, and applications.
  • Obtain access to the relevant devices.
  • Collect and document relevant information and symptoms.

Analyze information

  • Identify possible causes.
  • Use network documentation, performance baselines, and knowledge bases.
  • Consult other technicians and research reliable sources.

Eliminate possible causes

  • Gradually eliminate possible causes.
  • Use troubleshooting experience to identify the most likely cause.
Experience is important when quickly eliminating unlikely causes.

Propose a hypothesis

  • Formulate a solution based on the most likely cause.
  • Use troubleshooting experience to create an effective plan.

Test the hypothesis

  • Evaluate the impact and urgency of the problem.
  • Consider possible effects on other systems and processes.
  • Compare the severity of the problem with the impact of the proposed solution.
  • For critical systems, consider applying the solution outside peak hours.
  • Create a temporary workaround when necessary.
Always consider potential adverse effects before implementing a solution.

Resolve the problem

  • Implement the solution.
  • Inform all affected parties, including users and the IT team.
  • Document the cause and the solution in detail.
Good documentation helps prevent and resolve similar problems in the future.

1.1.3 Troubleshooting with Layered Models

The OSI and TCP/IP models can be used to isolate network problems during troubleshooting.
For example, if the symptoms indicate a physical connectivity issue, the technician can focus on cables, ports, and physical connections before investigating upper layers.
A useful practice is to investigate one layer at a time, beginning with the physical layer whenever possible.
  • This approach makes the source of the problem easier to identify.
  • It also avoids spending time on layers that are not related to the failure.
Routers and multilayer switches are shown next to Layer 4 because, although they normally forward traffic based on Layer 3 information, access control lists on these devices may use Layer 4 data when making filtering decisions.

1.1.4 Structured Troubleshooting Methods

Several structured methods are available for resolving computer and network problems. The appropriate method depends on the problem and the technician's experience. One or more methods may be combined.
  • Bottom-up
    • Begins with the physical layer and physical components.
    • Moves upward through the OSI layers until the cause is identified.
  • Top-down
    • Begins with the end-user application.
    • Moves downward through the OSI layers until the cause is identified.
  • Divide and conquer
    • Collects the user's description of the problem.
    • Documents the symptoms.
    • Estimates the OSI layer where the investigation should begin.
  • Follow the path
    • Discovers the path taken by traffic from source to destination.
    • Complements other troubleshooting approaches.
  • Substitution
    • Replaces the suspected device or component with a known working one.
    • If the problem disappears, the removed item was probably the cause.
    • If the problem remains, the cause is elsewhere.
  • Comparison
    • Compares configurations, versions, and hardware between working and non-working situations.
    • Identifies meaningful differences.
  • Educated guess
    • A less structured method.
    • Relies on the technician's experience and judgment.

1.1.5 Guidelines for Selecting a Troubleshooting Method

To resolve network problems efficiently, select the method that is most appropriate for the type of failure and the available evidence.
  • Software-oriented problems are commonly resolved with a top-down approach.
  • Hardware-related problems are commonly resolved with a bottom-up approach.
  • An experienced technician may use divide and conquer for a new problem. Otherwise, bottom-up is a safe starting point.
  • Problems encountered before can often be resolved using divide and conquer.
Troubleshooting is a practical skill that improves through experience. Each network problem that you identify and resolve adds to your technical knowledge.

1.1.6 Documenting Findings, Actions, and Results

After resolving the problem, close the troubleshooting cycle with clear documentation.
  • Problem
    • Include the initial report and how the issue was received.
    • Describe the symptoms in detail.
    • Record all information collected during the investigation.
    • Include any additional information that may help with similar problems in the future.
  • Solution
    • Record every step used to resolve the problem.
    • Provide a repeatable step-by-step procedure whenever possible.
  • Commands and tools
    • List the commands used to diagnose and resolve the issue.
    • Record the tools that were used.
Verify the solution with the customer:
  • When possible, demonstrate what was changed.
  • Ask the customer to test and confirm that the issue is resolved.
  • Add any new information provided by the customer to the documentation.
This documentation helps both you and the rest of the team solve future incidents more efficiently.

1.1.7 Check Your Understanding — Troubleshooting Process

  1. During which step of the seven-step troubleshooting process would you create a rollback plan that explains how to quickly reverse a solution?
    • Test the hypothesis.
  2. What is the highest OSI layer that should be considered when troubleshooting routers and Layer 3 switches?
    • Layer 4 — Transport.
  3. Which structured troubleshooting method should be used when a cabling problem is suspected?
    • Bottom-up.
  4. Which structured troubleshooting method should be used for a software-oriented problem?
    • Top-down.

PreviousCisco Support Network
Next Network Documentation