In the Network+ troubleshooting model, there are eight steps you must follow:
To facilitate our discussion of the troubleshooting steps, let’s assume that a user has called you, the network administrator, to complain about not being able to connect to the Internet.
Step 1: Establish Symptoms
Obviously, if you can’t identify a problem, you can’t begin to solve it. Typically, you need to ask some questions to begin to clarify exactly what is happening. In our example, we should ask the user the following:
We find out that the user cannot access the corporate intranet or get to any sites on the Internet. He can, however, use his web browser to access the corporate FTP site, which he has bookmarked (by IP address 10.0.0.2). We can, therefore, rule out the web browser as the source of the problem.
Step 2: Identify the Affected Area
Computers and networks are fickle; they can work fine for months, suddenly malfunction horribly, and then continue to work fine for several more months, never again exhibiting that particular problem. And that’s why it’s important to be able to reproduce the problem and identify the affected area. Identifying the affected area narrows down what you have to troubleshoot.
One of your goals is to make problems easier to troubleshoot and, thus, get users working again as soon as possible. Therefore, the best advice you can give when training users is that when something isn’t working, try it again and then write down exactly what is and is not happening. Most users’ knee-jerk reaction is to call you immediately when they experience a problem. This isn’t necessarily the best thing to do because your response is most likely, “What were you doing when the problem occurred?” And most users don’t know precisely what they were doing at the computer because they were primarily trying to get their job done. Therefore, if you train users to reproduce the problem first, they’ll be able to give you the information you need to start troubleshooting it.
In our example, we find out that when the user tries to access the corporate intranet, he gets the following error message:
We’re in luck—we can re-create this problem.
Step 3: Establish What Has Changed
If you can reproduce the problem, your next step is to attempt to determine what has changed. Drawing on your knowledge of networking, you might ask yourself and your user questions such as the following:
Were you ever able to do this? If not, then maybe this is not an operation the hardware or software is designed to do. You can inform the user that the system won’t do the operation (or that they may need additional hardware or software to do it).
If so, when did you become unable to do it? If the computer was able to do the operation and then suddenly could not, the conditions that surround this change become extremely important. You may be able to discover the cause of the problem if you know what happened immediately before the change. It is likely that the cause of the problem is related to the conditions surrounding the change.
Has anything changed since you were last able to do this? This question can give you insight into a possible source for the problem. Most often, the thing that changed before the problem started is the source of the problem. When you ask this question of a user, the answer is typically that nothing has changed, so you might need to rephrase it. For example, you can try asking, “Did anyone add anything to your computer?” or “Are you doing anything that’s different from the way you normally proceed?”
Were any error messages displayed? This is one of the best indicators of the cause of a problem. Error messages are designed by programmers to help them determine what aspect of a computer system is not functioning correctly. These error messages are sometimes clear, such as “Disk Full” (indicating that the disk cannot store any more files on it because it is full). Or they can be cryptic, such as “A random bit has been flipped in the I/O subsystem of memory junction 44FA380h” (this is a fictitious error, but you may encounter some just as complex). If you get a cryptic error message, you can go to the software or hardware vendor’s support website and usually get a translation of the “programmerese” of the error message into English.
Are other people experiencing this problem? This is one question you must ask yourself. That way you might be able to narrow down the cause of the problem to a specific item. Try to duplicate the problem yourself from your own workstation. If you can’t duplicate the problem on another workstation, it may be related to only one user or group of users (or possibly their workstations). If more than one user is experiencing this problem, you may know this already because several people will be calling in with the same problem.
Is the problem always the same? Generally speaking, when problems crop up, they are almost always the same problem each time they occur. But their symptoms may change ever so slightly as conditions surrounding them change. A related question is, “If you do x, does the problem get better or worse?” For example, you might ask a user, “If you use a different file, does the problem get better or worse?” If the symptoms become less severe, it might indicate that the problem is related to the original file being used.These are just a few of the questions you can use to isolate the cause of the problem.
In our example, we find out that the problem is unique to one user, indicating that the problem is specific to his workstation. When we watch him as he attempts to reproduce the problem, we notice that he is typing the address correctly. The error message leads us to believe that the problem has something to with Domain Name Service (DNS) lookups on his workstation.
Step 4: Select the Most Probable Cause
After you observe the problem and isolate the cause, your next step is to select the most probable cause for the problem. Trust me, this gets easier with time and experience.
You must come up with at least one possible cause, even though it may not be correct. And you don’t always have to come up with it yourself. Someone else in the group may have the answer. Also, don’t forget to check online sources and vendor documentation.
In our example, we determined earlier that the cause was improperly configured DNS lookup on the workstation. The correction, then, is to reconfigure DNS on the workstation.
Step 5: Implement a Solution
In this step, you implement the solution. In our example, we need to reconfigure DNS on the workstation by following these steps in Windows 2000 Server:
DNS settings are uniform across all adapters. So, using one adapter to access these configuration pages affects the solitary DNS configuration for the entire system. As you can see in the previous screen shot, there are no static DNS settings on this workstation. You should only change such settings when you fully understand the effect of these changes or are told to do so by someone who does. Incorrect configuration of these settings will disable the normal operation of your workstation. We can assume our DNS configuration requires some sort of static changes, such as the specification of DNS suffixes, which can coexist with DHCPlearned DNS settings.
Step 6: Test the Result
Now that you have made the changes, you must test your solution to see if it solves the problem. In our example, we’d ask the user to try to access the intranet (since that was the problem reported). In general terms, ask the user to repeat the operation that previously did not work. If it works, great! The problem is solved. If it doesn’t, try the operation yourself.
If the problem isn’t solved, you may have to go back to step 4, select a new possible cause, and redo steps 5 and 6. But it is important to make note of what worked and what didn’t so that you don’t make the same mistakes twice.
Step 7: Recognize the Potential Effects of the Solution
A fundamental flaw of any network technician is solving only the one problem and not realizing what other problems that solution may cause. It is possible that the solution may be worse than the problem. As the saying goes, “Sometimes the cure is worse than the disease.”
Before fully implementing the solution to a problem, make sure you are completely aware of the potential effects of the solution and the other problems it may cause. If it causes more problems than it fixes, the solution probably isn’t the best solution for the problem.
Step 8: Document the Solution
As you learned in Chapter 6, “Wired and Wireless Networks,” network documentation is very important. You’ll definitely want to document problems and solutions so that you have the information at hand when a similar problem arises in the future. With documented solutions to documented problems, you can assemble your own database of information that you can use to troubleshoot other problems. Be sure to include information such as the following:
Networking Related Tutorials
|Network Security Tutorial|
Networking Related Interview Questions
|Network Technical Support Interview Questions||Networking Interview Questions|
|CCNA Interview Questions||Network Security Interview Questions|
|Computer Network Security Interview Questions||Hardware and Networking Interview Questions|
|CCNP Interview Questions||Routing Protcol Interview Questions|
|CWNA (Certified Wireless Network Administrator) Interview Questions||Border Gateway Protocol (BGP) Interview Questions|
|Enhanced Interior Gateway Routing Protocol (EIGRP) Interview Questions||Virtual Private Network (VPN) Interview Questions|
|Controller Area Network (CAN bus) Interview Questions||Cisco Network Engineer Interview Questions|
|Storage Area Network Interview Questions||Network Troubleshooting Interview Questions|
Networking Related Practice Tests
|Network Technical Support Practice Tests||Networking Practice Tests|
|CCNA Practice Tests||Network Security Practice Tests|
|Computer Network Security Practice Tests||Hardware and Networking Practice Tests|
|CCNP Practice Tests||Routing Protcol Practice Tests|
|CWNA (Certified Wireless Network Administrator) Practice Tests||Border Gateway Protocol (BGP) Practice Tests|
|Enhanced Interior Gateway Routing Protocol (EIGRP) Practice Tests|
The Osi Model
Network Operating Systems
Wired And Wireless Networks
Wan And Remote Access Technologies
Network Access And Security
Fault Tolerance And Disaster Recovery
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.