CompTIA Network+ N10-006 Cert Guide (2015)

Chapter 13. Network Troubleshooting

After completion of this chapter, you will be able to answer the following questions:

What are the elements in a structured troubleshooting model?

What common physical layer troubleshooting issues might you encounter?

What potential Layer 2 issues are you most likely to face when troubleshooting a network containing Ethernet switches?

Aside from routing protocol troubleshooting, what Layer 3 troubleshooting issues are common in a routed network?

How do characteristics unique to wireless networks impact your troubleshooting of a network containing wireless access points?

As you perform your day-to-day tasks of administering a network, a significant percentage of your time will be dedicated to resolving network issues. Whether the issues that you are troubleshooting were reported by an end user or were issues you discovered, you need an effective plan to respond to those issues. Specifically, you need a systematic approach to clearly articulate the issue, gather information about the issue, hypothesize the underlying cause of the issue, validate your hypothesis, create an action plan, implement that action plan, observe results, and document your resolution. Without a plan, your efforts might be inefficient, as you try one thing after another, possibly causing other issues in the process.

Although your troubleshooting efforts can most definitely benefit from a structured approach, realize that troubleshooting is part art and part science. Specifically, your intuition and instincts play a huge role in isolating an issue. Of course, those skills are developed over time and come with experience and exposure to more and more scenarios.

To help you start developing, or continue honing, your troubleshooting skills, this chapter begins by presenting you with a formalized troubleshooting methodology, which can act as a guide for addressing most any network issue. Then the remainder of this chapter presents you with a collection of common network issues to consider in your real-world troubleshooting efforts (and issues to consider on the Network+ exam).

These common network issues are broken down into the following categories: physical layer issues, data link layer issues, network layer issues, and wireless network issues.

Foundation Topics

Troubleshooting Basics

Troubleshooting network issues is implicit in the responsibilities of a network administrator. Such issues could arise as a result of human error (for example, a misconfiguration), equipment failure, software bugs, or traffic patterns (for example, high utilization or a network being under attack by malicious traffic).

Many network issues can be successfully resolved using a variety of approaches. This section begins by introducing you to troubleshooting fundamentals. Then you are presented with a structured troubleshooting methodology you should know for the Network+ exam.

Troubleshooting Fundamentals

The process of troubleshooting, at its essence, is the process of responding to a problem report (sometimes in the form of a trouble ticket), diagnosing the underlying cause of the problem, and resolving the problem. Although you normally think of the troubleshooting process beginning when a user reports an issue, realize that through effective network monitoring, you might detect a situation that could become a troubleshooting issue and resolve that situation before it impacts users.

After an issue is reported, the first step toward resolution is clearly defining the issue. After you have a clearly defined troubleshooting target, you can begin gathering information related to that issue. Based on the information collected, you might be able to better define the issue. Then you hypothesize the likely causes of the issue. Evaluation of these likely causes leads to the identification of the suspected underlying root cause of an issue.

After a suspected underlying cause is identified, you define approaches to resolve an issue and select what you consider to be the best approach. Sometimes the best approach to resolving an issue cannot be implemented immediately. For example, a piece of equipment might need replacing. However, implementing such an approach during working hours might disrupt a business’s workflow. In such situations, a troubleshooter might use a temporary fix until a permanent fix can be put in place.

As a personal example, when helping troubleshoot a connectivity issue for a resort hotel at a major theme park, my coworkers and I discovered that a modular Ethernet switch had an issue causing Spanning Tree Protocol (STP) to fail, resulting in a Layer 2 loop. This loop flooded the network with traffic, preventing the hotel from issuing keycards for guest rooms. The underlying cause was clear. Specifically, the Ethernet switch had a bad module. However, the time was about 4:00 p.m., a peak time for guest registration. So, instead of immediately replacing the faulty module, we disconnected one of the redundant links, thus breaking the Layer 2 loop. The logic was that it was better to have the network function at this time without STP than for the network to experience an even longer outage while the bad module was replaced. Late that night, someone came back to the switch and swapped out the module, resolving the underlying cause while minimizing user impact.

Consider Figure 13-1, which depicts a simplified model of the troubleshooting steps previously described. This simplified model consists of three steps:

Step 1 Problem report

Step 2 Problem diagnosis

Step 3 Problem resolution

Figure 13-1 Simplified Troubleshooting Flow

Of these three steps, the majority of a troubleshooter’s efforts are spent in the problem diagnosis step. Table 13-1 describes key components of this diagnosis step.

Table 13-1 Steps to Diagnose a Problem

Structured Troubleshooting Methodology

Troubleshooting skills vary from administrator to administrator. Therefore, although most troubleshooting approaches include the collection and analysis of information, elimination of potential causes, hypothesis of likely causes, and testing of the suspected cause, different troubleshooters might spend different amounts of time performing these tasks.

If a troubleshooter does not follow a structured approach, the temptation is to move between the previously listed troubleshooting tasks in a fairly random way, often based on instinct. Although such an approach might well lead to a problem resolution, it can become confusing to remember what you have tried and what you have not tried. Also, if another administrator comes to assist you, communicating to that other administrator the steps you have already gone through could be a challenge. Therefore, following a structured troubleshooting approach not only helps prevent your trying the same thing more than once and inadvertently skipping a task but also aids in communicating to someone else the possibilities you already eliminated.

You might encounter a variety of structured troubleshooting methodologies in networking literature. However, for the Network+ exam, the methodology shown in Figure 13-2 is what you should memorize.

Figure 13-2 Structured Troubleshooting Approach

The following is an elaboration on this seven-step methodology:

Step 1 Define the problem. Effective troubleshooting begins with a clear problem definition. This definition might include specific symptoms, such as, “User A’s computer is unable to communicate with server 1 (as verified by a ping test). However, user A can communicate with all other servers. Also, no other user seems to have an issue connecting to server 1.” This problem definition might come from questioning the impacted user(s) and doing your own testing (for example, seeing if you can ping from user A’s computer to server 1). If possible, determine whether anything has changed in the network (or in the computer) configuration. Also, find out whether this is a new installation, which has never worked in the past.

Step 2 Hypothesize a probable cause. This is the point in the troubleshooting process where your experience and intuition can be extremely helpful because you are now going to brainstorm a list of possible causes. When examining your collected data (for example, output from the ipconfig /all command), question everything. For example, you might think that the issue described in Step 1 could result from causes such as an ACL blocking traffic to or from the PC, a connectivity issue with the PC or server, or an incorrect IP address configuration on the PC. From your list of possible causes, select the one that you consider the most likely. From the previous list, you might believe that an incorrect IP address configuration on the PC is the most likely cause of the problem. Specifically, you conclude that the issue is not related to connectivity because other PCs can get to the server, and user A’s PC can get to other servers. Also, you conclude that it is more likely that user A’s PC has a bad IP-address configuration than for an ACL to have been administratively added to the router to only block traffic between user A’s PC and server 1.

Step 3 Test the hypothesis. Before taking action on what you consider to be the most likely cause of a problem, do a sanity check on your theory. Would your hypothesized cause lead to the observed symptoms? In the example presented in the preceding steps, you might examine the subnet mask assigned to user A’s computer and determine that it is incorrect. Specifically, the subnet mask makes user A’s computer think that server 1 is on the same subnet as user A’s computer. As a result, user A’s computer does not forward traffic to its default gateway when attempting to reach server 1. If your hypothesis is technically sound, you can proceed to Step 4. However, if you notice a flaw in your logic, you need to formulate an alternate hypothesis. The formation of an alternate hypothesis might involve escalating the problem to someone more familiar with the device(s) in question.

Step 4 Create an action plan. Now that you have confirmed that your theory makes sense technically, the time has come to develop an action plan. If time permits, you should document your action plan. The documentation of your action plan can be used as a back-out plan if your hypothesis is incorrect. In the example we have been building on throughout these steps, an action plan might be to change the subnet mask on user A’s computer from 255.255.0.0 to 255.255.255.0.

Step 5 Implement action plan. Based on your documented plan of action, you should schedule an appropriate time to implement your action plan. The selection of an appropriate time is a balance between the severity of a problem and the impact your action plan will have on other users. Sometimes, when attempting to implement your action plan, you realize that you do not have sufficient administrative privileges to perform a task in your action plan. In such cases, you should escalate the issue to someone with appropriate administrative rights. In this example, changing the subnet mask on one computer should not impact any other devices. So, you might immediately make the configuration change on user A’s computer.

Step 6 Verify problem resolution. After implementing your action plan, you need to verify that the symptoms listed in your original problem definition are gone. Also, attempt to determine whether your action plan has caused any other issues on the network. A mistake many troubleshooters make at this point is believing that the issue has been resolved because the specific symptom (or symptoms) they were looking for is gone. However, the user who originally reported the issue might still be having a problem. Therefore, troubleshooters should live by this mantra: “A problem isn’t fixed until the user believes it’s fixed.” So, you should always get confirmation from the person reporting an issue that, from her perspective, the reported issue has indeed been resolved. In our example, you could attempt to ping server 1 from user A. If the ping is successful, check with user A to see whether she agrees that the problem is resolved.

Step 7 Create a post-mortem report. A post-mortem report is a document that describes the reported issue, its underlying causes, and what was done to resolve the issue. This report might be useful when troubleshooting similar issues in the future.

Keep in mind when working your way through the previous steps that you might encounter an issue that you do not have sufficient information to solve. When that happens, you might need to further research the issue yourself. However, if time is of the essence, you might need to immediately escalate the issue to someone else within your organization, to an equipment vendor, or to an outside consultant.

Physical Layer Troubleshooting

Layer 1 (the physical layer) of the OSI model is foundational to all the other layers. As a result, if Layer 1 isn’t functioning, none of the upper layers will function properly. Table 13-2 presents a collection of common Layer 1 issues.

Table 13-2 Common Layer 1 Troubleshooting Issues