Internetwork Troubleshooting Model | CCNP CIT Exam Cram 2 (Exam Cram 642-831)

As you will read many times in this book, networks can grow to be very complex. Effective troubleshooting of these complex networks requires a systematic approach, such as the Internetwork Troubleshooting model you learn about in this section. The Internetwork Troubleshooting model assumes that you are in a large company that uses helpdesk software. The model is illustrated in Figure 2.2.

Figure 2.2. The process map of a typical Internetwork Troubleshooting Model.

graphics/02fig02.gif

You should remember that just because a user in your network reports a problem, you can't assume that the problem is in your network. Instead, you need to obtain more information to determine if the issue affects only the user reporting the problem, or if it affects many other system users. In some cases, you may determine that user error or lack of training is causing the problem, and that a technical problem never really existed.

The model in Figure 2.2 is called a process map, which illustrates the steps used to troubleshoot typical problems in a representative network. The Internetwork Troubleshooting model takes a step-by-step approach to troubleshooting network problems. The steps are as follows :

Define the problem.
Gather the facts.
Review and evaluate the possibilities.
Design a plan of action.
Implement the action plan.
Evaluate and observe the solution.
Document the solution.

You should know these steps for the exam. The following sections discuss these steps in detail.

An eighth step sometimes noted in Cisco texts is called "Iterate the Process." If the results of the first seven steps do not resolve the problem or issue, redo the steps. Iterate by definition means to redo or repeat the process.

The following sections describe each of these steps in detail.

Step 1: Define the Problem

Most of the time, you, as the network administrator, will receive a ticket from the help desk, indicating that a problem needs to be resolved. You cannot always accept the information on the ticket at face value. The help desk person who could not resolve the issue over the phone may exaggerate, overestimate, or misinterpret the problem in his or her description on the ticket. If, for example, you get a call or a ticket from the helpdesk that says "Nobody can connect to the Internet," you have to question whether everyone in the building is truly unable to connect to the Internet. Does that mean that the user calling in the problem truly asked everyone in the building if they could access the Internet? You get the point. In defining the problem, you clear away any mistakes or misconceptions about the issue you must deal with.

The ticket should be used only as a notification that a problem exists. In defining the problem, you need to investigate the information you received with the ticket and verify its accuracy. It is usually necessary to contact those who are having the problem to get a clear explanation of what the problem is and what is being affected by the problem. Occasionally, you may have to visit the user and have the user demonstrate what he or she is seeing.

Step 2: Gather the Facts

Gathering facts may be more than just talking to the users who are reporting that an issue or problem in the network exists. Sometimes the issues reported may indicate a problem with a Cisco switch or router; you may need to use show or debug commands on the switch or router to determine if the issue or problem is being caused by the hardware or software used by the switch or router. If more than one person has a problem, you might want to ask questions to determine what are common symptoms, what devices are affected, and what network services are affected.

Step 3: Review and Evaluate the Possibilities

At this point you should have accumulated a mountain of information within an appropriate timeframe. After reviewing the information you have gathered about the problem, you should start to list the possible cause or causes, and how you can eliminate multiple possibilities. If you need to, consult with your peers and other network administrators, do research on the Web, or look at closed helpdesk tickets to review past issues the network has had.

Step 4: Design a Plan of Action

Once you have narrowed down the possibilities to a short list of potential causes for the problem, you can create a plan for resolving the problem. When you have some ideas as to what the problem might be, you can outline the steps you must take to resolve the issue; these steps form your plan of action. The plan may require reconfigurations of network devices or the resolution of a major outage , or it could be as small as rebooting a single device in the network. Your plan must anticipate how the resolution will affect the users on the network. Your plan of action may need to include notifying users of outages or other interruptions that will occur during the resolution of the problem.

Step 5: Implement the Action Plan

You have an idea of what the problem is; you have a plan to resolve it. Whether this is a hardware change or a software or operating system reconfiguration, now is when you need to follow your action plan and implement the resolution. Carefully document the process of implementing your plan, so you can use the information should the process fail or further problems arise.

Step 6: Evaluate and Observe the Solution

Did your action plan and implementation resolve the issue? If it didn't, you need to go back to step 2, and gather more facts. Even if your plan of action didn't resolve the issue, during the attempt you may have gathered more information to make a more informed decision.

Sometimes solving one issue actually creates new problems. Once you think you have resolved the issue, you should test and make sure that the problem has truly been addressed and no new problems now exist, creating an error-free solution. If a new problem exists, it becomes step 1 of a new troubleshooting phase. You need to start with step 1 of the process and add your resolution here to your gathering of facts. You should always remember to document everything that you have tried in resolving the issue in case you need to go back and reevaluate your troubleshooting steps.

Step 7: Document the Solution

Once you are sure you have resolved the issue, the next and final step is to make sure that the trouble ticket you opened is closed with a very detailed explanation of what was done to resolve the issue. This documentation may help you or another network administrator resolve the same issue if it happens again. If your solution created a secondary issue, your careful documentation may help you or another administrator back-track to resolve the secondary issue.