1.1 Diagnostics and Troubleshooting Methodologies Flashcards
1.1.1 Troubleshooting Process Review
Troubleshooting is the process of identifying, locating and correcting problems. This process involves gathering information and using one or more structured troubleshooting methods.
After the problem in the network is first discovered, one of the first steps is to gather information. The following list provides a review of some of the information you may wish to collect.
Determine the nature of problem
End-user reports
Problem verification report
Gather relevant equipment information
Manufacturer
Make / model
Firmware version
Operating system version
Ownership / warranty information
Gather configuration and topology information
Physical and logical topology
Configuration files
Log files
Determine if there were any similar issues previously
Steps taken
Results achieved
1.1.2 Seven-Step Troubleshooting Process
DEFINE THE PROBLEM
The goal of this stage is to verify that there is a problem and then properly define what the problem is. Problems are usually identified by a symptom (e.g., the network is slow or has stopped working). Network symptoms may appear in many different forms, including alerts from the network management system, console messages, and user complaints.
While gathering symptoms, it is important to ask questions and investigate the issue in order to localize the problem to a smaller range of possibilities. For example, is the problem restricted to a single device, a group of devices, or an entire subnet or network of devices?
In an organization, problems are typically assigned to network technicians as trouble tickets. These tickets are created using trouble ticketing software that tracks the progress of each ticket. Trouble ticketing software may also include a self-service user portal to submit tickets, access to a searchable trouble tickets knowledge base, remote control capabilities to solve end-user issues, and more.
GATHER INFORMATION
In this step, targets (i.e., hosts, devices) to be investigated must be identified, access to the target devices must be obtained, and information gathered. During this step, the technician may gather and document more symptoms, depending on the characteristics that are identified.
ANALYZE INFORMATION
Possible causes must be identified. The gathered information is interpreted and analyzed using network documentation, network baselines, searching organizational knowledge bases, searching the internet, and talking with other technicians.
ELIMINATE POSSIBLE CAUSES
If multiple causes are identified, then the list must be reduced by progressively eliminating possible causes to eventually identify the most probable cause. Troubleshooting experience is extremely valuable to quickly eliminate causes and identify the most probable cause.
PROPOSE HYPOTHESIS
When the most probable cause has been identified, a solution must be formulated. At this stage, troubleshooting experience is very valuable when proposing a plan.
TEST HYPOTHESIS
Before testing the solution, it is important to assess the impact and urgency of the problem. For instance, could the solution have an adverse effect on other systems or processes? The severity of the problem should be weighed against the impact of the solution. For example, if a critical server or router must be offline for a significant amount of time, it may be better to wait until the end of the workday to implement the fix. Sometimes, a workaround can be created until the actual problem is resolved.
SOLVE THE PROBLEM
When the problem is solved, inform the users and anyone involved in the troubleshooting process that the problem has been resolved. Other IT team members should be informed of the solution. It is important to properly document the cause and solution as this can assist other support technicians to prevent and solve similar problems in the future.
1.1.3 Troubleshooting with Layered Models
The OSI and TCP/IP models can be applied to isolate network problems when troubleshooting. For example, if the symptoms suggest a physical connection problem, the network technician can focus on troubleshooting the cables and their connections at the physical layer.
1.1.4 Structured Troubleshooting Methods
A technician may choose one or more of the following methods to solve a problem:
Bottom-Up - Start with the physical layer and the physical components of the network and move up through the layers of the OSI model until the cause of the problem is identified.
Top-Down - Start with the end-user applications and move down through the layers of the OSI model until the cause of the problem has been identified.
Divide-and-Conquer - Start by collecting user experiences of the problem, document the symptoms and then, using that information, make an informed guess as to which OSI layer to start your investigation.
Follow-the-Path - Discover the traffic path all the way from source to destination. This approach usually complements one of the other approaches.
Substitution - Physically swap the problematic device or component with a known, working one. If the problem is fixed, then the problem is with the removed item. If the problem remains, then the cause is elsewhere.
Comparison - Compare specifics such as configurations, software versions, hardware, or other device properties, links, or processes between working and nonworking situations and spot significant differences between them.
Educated Guess - A less-structured troubleshooting method that uses an educated guess based on the experience of the technician and their ability to solve problems.
1.1.6 Document Findings, Actions, and Outcomes
After troubleshooting and resolving all issues, it is important to complete the troubleshooting process by documenting all information.
A technician must document the:
Problem - Includes the initial report of the problem, a description of the symptoms, information gathered and any other information that would help resolve similar problems.
Solution - Includes the steps taken to resolve the problem.
Commands and Tools Used - Include the commands and tools used in diagnosing the problem and solving the problem.
Verify the solution with the customer. If the customer is available, demonstrate how the solution has corrected their problem. Have the customer test the solution and try to reproduce the problem. When the customer can verify that the problem has been resolved, you can update the documentation with any new information provided by the customer.
