Upon completion of this chapter, you will be able to answer the following questions:
- What are some of the approaches used to troubleshoot networks?
- What is the process of detecting physical layer problems?
- What network utilities can you use to troubleshoot networks?
- How do you troubleshoot a wireless network problem?
- What are some common Internet connectivity problems?
- What outside sources and Internet resources are available for troubleshooting?
Key Terms
There are no key terms in this chapter.
Introduction (20.0.1)
Congratulations! You‛ve made it to the final chapter in Networking Essentials. While learning about networking in this course, you‛ve likely developed skills you didn‛t even know you needed. Was the purpose of this whole course learning how to set up a simple network? Of course, network setup is important, but it‛s just part of your learning.
What do you do when your network doesn‛t work? This is your real test as a network administrator—to be able to figure out what is wrong, fix it, (and here‛s the tricky part) and not accidentally create a whole new problem. Get good at troubleshooting, and you will always be in demand.
The Troubleshooting Process (20.1)
Troubleshooting is the process of identifying, locating, and correcting problems. Experienced individuals often rely on instinct to troubleshoot. However, you can use structured techniques to determine the most probable cause and solution to problems.
Network Troubleshooting Overview (20.1.1)
When troubleshooting, you must maintain proper documentation. This documentation should include as much information as possible about the following:
- The problem encountered
- Steps taken to determine the cause of the problem
- Steps to correct the problem and ensure that it will not reoccur
You must document all steps taken in troubleshooting, even the ones that did not solve the issue. This documentation becomes a valuable reference should the same or a similar problem occur again. Even in a small home network, good documentation saves hours of trying to remember how a problem was fixed in the past.
Gather Information (20.1.2)
When a problem is first discovered in the network, it is important to verify the problem and determine how much of the network is affected by it. After the problem is confirmed, the first step in troubleshooting is to gather information. The following checklist provides some of the important information you should check:
- Nature of Problem
- End-user reports
- Problem verification report
- Equipment
- Manufacturer
- Make/model
- Firmware version
- Operating system version
- Ownership/warranty information
- Configuration and Topology
- Physical and logical topology
- Configuration files
- Log files
- Previous Troubleshooting
- Steps taken
- Results achieved
One of the first ways to gather information is to question the individual who reported the problem, as well as any other affected users. Questions can include end-user experiences, observed symptoms, error messages, and information about recent configuration changes to devices or applications.
Next, collect information about any equipment that may be affected. This information can be gathered from documentation. A copy of all log files and a listing of any recent changes made to equipment configurations are also necessary. Log files are generated by the equipment itself and can usually be obtained through the management software. Other information on the equipment includes the manufacturer, make, and model of devices affected, as well as ownership and warranty information. The version of any firmware or software on the device is also important because there may be compatibility problems with particular hardware platforms.
Information about the network can also be gathered using network monitoring tools. These tools are complex applications often used on large networks to continually gather information about the state of the network and network devices. They may not be available for smaller networks.
After all necessary information is gathered, you start the troubleshooting process.
Structured Troubleshooting Methods (20.1.3)
Several structured troubleshooting approaches can be used. Which one you use depends on the situation. Each approach has its advantages and disadvantages. Here, you‛ll learn methods and guidelines for choosing the best method for a specific situation.
Bottom-Up
In bottom-up troubleshooting, you start with the physical layer and the physical components of the network, as shown in Figure 20-1, and move up through the layers of the OSI model until the cause of the problem is identified.
Figure 20-1 Bottom-Up Troubleshooting
Bottom-up troubleshooting is a good approach to use when the problem is suspected to be a physical one. Most networking problems reside at the lower levels, so implementing the bottom-up approach is often effective.
The disadvantage with the bottom-up troubleshooting approach is that it requires you to check every device and interface on the network until the possible cause of the problem is found. Remember that each conclusion and possibility must be documented, so a lot of paperwork can be associated with this approach. A further challenge is to determine which devices to start examining first.
Top-Down
As shown in Figure 20-2, top-down troubleshooting starts with the end-user applications and moves down through the layers of the OSI model until the cause of the problem has been identified.
Figure 20-2 Top-Down Troubleshooting
End-user applications of an end system are tested before tackling the more specific networking pieces. You can use this approach for simpler problems or when you think the problem is with a piece of software.
The disadvantage with the top-down approach is it requires you to check every network application until the possible cause of the problem is found. Each conclusion and possibility must be documented. The challenge is to determine which application to start examining first.
Divide-and-Conquer
Figure 20-3 shows the divide-and-conquer approach to troubleshooting a networking problem. As network administrator, you select a layer and test in both directions from that layer.
Figure 20-3 Divide-and-Conquer Troubleshooting
In divide-and-conquer troubleshooting, you 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. When a layer is verified to be functioning properly, it can be assumed that the layers below it are functioning. You can work up the OSI layers. If an OSI layer is not functioning properly, you can work down the OSI layer model.
For example, if users cannot access the web server but can ping the server, the problem is above Layer 3. If pinging the server is unsuccessful, the problem is likely at a lower OSI layer.