Network troubleshooting is best done by adhering closely to a formal methodology. A methodology can be defined as a collection of methods, practices, procedures, and rules used by those who work in some field. Using the seven-step methodology described here may help you to resolve network issues quickly and efficiently.
Before you can solve a problem, you typically will need to troubleshoot the problem by figuring out what the problem is. Asking the right questions can get you far along this path and really help clarify the situation. Identifying the problem involves steps that together constitute information gathering.
When a user reports an issue, you should attempt to duplicate the issue. When this is possible, it will help in discovering the problem. When you cannot duplicate the issue, your challenge becomes harder because you are dealing with an intermittent problem. These issues are difficult to solve because they don’t happen consistently.
Do your best to determine if anything has changed. If you can reproduce the problem, your next step is to verify what has changed and how.
EXAMPLE
Drawing on your knowledge of networking, you ask yourself and your user questions like these:After you observe the problem and identify the symptoms, the next step is to establish its most probable cause. You need to 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, remember to check online sources and vendor documentation.
Understand that there are lots of problems that can occur on a network, which could include, but not be limited to the following:
Once you’ve gathered information and established a plausible theory, you need to determine the next steps to resolve your problem. When the testing of the theory is complete, you will have determined if the suggested cause is correct. If you find you are correct, the next step is to establish a plan of action to resolve the problem and identify potential effects.
If you find that the suggested theory is not the cause of the issue, then you should move on to test any other theories you may have developed. When you have exhausted all theories you have developed, escalate the issue to a more senior technician or, when it involves a system with which you are unfamiliar, the system owner or manager.
Identify some possible configuration changes to resolve the problem, and then follow through and test your solutions to see if they work. Once your solution seems to work, test the proposed solution on the computer of the user who is waiting for a solution. If the user is satisfied that the problem is resolved, all is well. If not, go back to step 2, select a new possible cause, and redo step 3.
Now that you have determined what the problem is, you need to resolve the problem for all affected users. And if you can’t fix the problem, you should know how to escalate it and to whom. Resources to help you in this process include your own problem-solving skills, reference-oriented technical books, the internet, or even an expert at the vendor’s technical support center.
Below is a list of complex issues that a junior network technician may need to escalate to a senior network engineer who has the additional experience and knowledge required to resolve the problems:
If you can’t implement a solution and instead have to escalate the problem, there is no need for you to go on with steps 6 and 7 of the seven-step troubleshooting model. Instead, meet with the emergency response team to determine the next step.
After you have executed your solution to solve a network problem, be sure to carefully test the network to verify that your solution actually fixed the problem. Once you have verified that the issue has been corrected, then spot check the network to look for any new problems that your solution may have caused. Use your network troubleshooting tools to verify proper network functionality, and then follow up with the individual users who initially reported the problem to have them verify that the network is working correctly for them.
A mistake that a network technician might make is to solve one problem and think it is fixed without stopping to consider the possible consequences of the solution. Occasionally, fixing one problem may cause other functions or features to break. So before you fully implement a solution, make sure you thoroughly understand the ramifications of their actions.
Accurate network documentation is vital to the success of any information technology operation. Always 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 like the following:
Now that you’ve learned the basics of network troubleshooting, let’s review some troubleshooting tips for you to consider when you need to create a technical solution to a challenging problem.
Many network issues are caused by a physical problem at Layer 1 of the OSI Reference Model, like power cords not plugged in, broken network cables, and electromagnetic interference generated by various sources in the physical environment. Therefore, you should generally start your troubleshooting process with the physical components that reside in Layer 1, and then work up the layers sequentially from there.
Remember that problems are often caused by little things like a bad power switch; a power switch in the wrong position; a card or port that’s not working, indicated by a link light that’s not lit; or simply, operator error. Even the most experienced system administrator has forgotten to turn on the power, left a cable unplugged, or mistyped a username and password. And make sure that users get effective training for the systems they use. Good training should dramatically decrease problems caused by user errors.
Being a network administrator or technician can keep you busy, and it’s typical to receive multiple calls for help at once. So, you’ve got to prioritize and handle the most urgent problem first.
You would start this process by asking some basic questions to determine the severity of the problem being reported. Clearly, if the new call is about something little and you already have a huge issue to deal with, you should put the new call on hold or get their info and get back to them later. If you establish a good set of priorities, you’ll make much better use of your time.
Here’s an example of the rank you probably want to give to networking problems, from highest priority to lowest:
Small-scale problems are not always easier to deal with. You may be able to bring up a crashed server in minutes, whereas a user who doesn’t know how to make columns line up in Microsoft Word could take a big chunk out of your day. You’d want to put the latter problem toward the bottom of the list because of the time involved. It’s generally more efficient to solve problems for a big group of people than to fix one user’s problem immediately.
Many network administrators manage all network-service requests by using support-call tracking software, the only function of which is to track and prioritize all network and computer problems.
Occasionally, network problems can be traced to software configuration, so when you’re checking for software problems, don’t forget to check types of configurations:
You want to make sure that from a network-design standpoint, the physical environment for a server is optimized for placement, temperature, and humidity. When troubleshooting an obscure network problem, don’t forget to check the physical conditions under which the network device is operating. Check for problems like these:
Source: This content and supplemental material has been adapted from CompTIA Network+ Study Guide: Exam N10-007, 4th Edition. Source Lammle: CompTIA Network+ Study Guide: Exam N10-007, 4th Edition - Instructor Companion Site (wiley.com)
