IT Certification and Training Blog

By James Hanback

We live in a hurry-up world.

There's the person behind you in traffic who leans on the horn if your brake lights don't go dark during the nanosecond that the traffic light is transitioning from red to green. There's the one behind you in the self-checkout lane who does the heavy sigh and eye roll bit because you must take the time to dislodge your rewards card from your wallet so you can start scanning your groceries (you knew you should have installed that rewards card app on your smart phone). Oh, and then there's the person who blows past you at the speed of light on a single-lane stretch of highway only to find you puttering up behind them at the next clogged intersection. You no doubt chuckle quietly to yourself as you await the go signal on such an occasion because you know that you've covered the same amount of distance and arrived at a simultaneous point with the speed demon, but at a lower fuel cost.

It's easy to laugh and shake your world-weary head at those who are in what seems like an unnecessary rush to get through daily mundane tasks, especially if you're the type of person who appreciates the lower cortisol, methodical approach to life. Chances are that the person who blared the horn at the traffic light isn't actually late for anything; he or she just doesn't like sitting still. Ditto the person in line at the checkout and the one who blows past you in a no-pass zone. They most likely don't care as much about method and efficiency as they do about speed (or they confuse efficiency with speed, which is an altogether different problem). With ever-advancing technology making it ever-easier to accelerate the pace of modern life, the number of speedsters in the world seems to be growing at an exponential rate while all the methodical can do is stand aside and gawk at how crazy it all looks from the outside.

Perhaps a heavy volume of blame for harried modern life can be placed squarely on technology's metaphorical shoulders. You might therefore assume that the ideal personality for a troubleshooting role in your organization would be the very people who are most heavily influenced by that increased pace—the speedsters—because they won't dally. They'll get in there, make the quick fix, and before you know it you'll be on with your day. You'd also probably be right so long as the speedster immediately knows what the problem is that needs to be fixed. On a Smurf's birthday, that's the case. Most times, the speedster is probably shooting in the dark because the problem sounds similar to a problem he or she has encountered before.

Fortunately, the methodical and efficiency-minded among us are not entirely extinct. For network administrators in particular, a less haphazard and more methodical approach to isolating and solving problems is the most effective means of fixing whatever ails your own little segment of the series of tubes. Contrary to what the non-techies may believe about those gifted with the magic of technical knowledge, there are actual documented troubleshooting processes that are intended to mitigate the all-too-human penchant for wild guesses and belief in the ability to tap into mystical stores of secret knowledge. One general purpose troubleshooting method cited by Cisco is based on the scientific method and consists of the following steps:

1. Define the problem: Narrowing the technical definition of the problem to a specific set of symptoms can help you identify a starting point for your troubleshooting technique and immediately eliminate some possible causes of the problem.
2. Gather the facts: After you have defined the problem, you should gather information by interviewing users who are affected by the problem and by using troubleshooting tools, such as the ping command. The information that is gathered from these interviews and troubleshooting tools can help pinpoint the location of a problem and narrow down the cause.
3. Consider the possibilities: Troubleshooting documentation, reference guides, and online user groups can all be sources of information about possible causes of a problem. At this step, you can potentially eliminate some components of a network or system as causes.
4. Create an action plan: Document in detail the steps you will take to solve the problem. In the plan, you should completely document the effects of any changes you intend to make to the configuration of the network or device. This documentation will aid you in the next step by enabling you to step through the plan and know what you have and have not done, which will additionally assist you in backing out any changes you make that negatively affect the network.
5. Implement the action plan: Implement the plan in a step-by-step fashion. Ensure that you test each change to see whether the symptoms of the problem are still present. If you implement a half-dozen changes at once and suddenly discover that the symptoms are gone, you won’t know which change solved the problem.
6. Gather the results: In particular, you should repeat the process of interviewing affected users to see if the problem is solved. Remember that just because you are no longer seeing the symptoms you identified in Step 1 does not necessarily indicate that the problem is fixed.
7. Analyze the results: If you have solved the problem, you should document the solution step-by-step so that it is simple to implement or to back out when you next implement it. If the change does not solve the original problem, might create other problems, or does not otherwise positively affect the network, you should back out the change and reconsider the possible causes of the original problem.
8. Return to Step 4: If the problem has not been resolved, you might need to create a new action plan based on the next potential cause of the problem and try again.
   
   

The above steps can be used for troubleshooting networks or for troubleshooting individual systems. However, there are network-specific troubleshooting techniques that can be used to aid you in logically and methodically isolating problems. In fact, a simple understanding of the Open Systems Interconnection (OSI) network model can go a long way toward solving network problems because there are at least three logical network troubleshooting techniques that are based on that model.

For example, if a user in your company's sales force reports that they can no longer access the Internet, you might begin the troubleshooting process at Layer 1, or the Physical layer, by verifying that the user's network cable is good and that the network interface card (NIC) is working properly. You could then move up the OSI model to the Data Link layer, the Network layer, the Transport layer, and so on until the problem is isolated. This troubleshooting technique is known as the Bottom Up technique.

The opposite of the Bottom Up technique is the Top Down technique, which, as the name implies, begins at Layer 7, or the Application layer, of the OSI model and works toward the Physical layer. Using the Top Down technique, you might begin by verifying that the user's browser is functioning normally by using it to access a Web server that is located inside the local area network (LAN). If a Web page loaded successfully from the internal server, you would have eliminated an Application layer problem.

Another technique that uses the OSI model is called the Divide and Conquer technique. The Divide and Conquer technique begins at the Network layer of the OSI model and moves either up or down the model depending on the results of network tests. For example, you might attempt to ping a server on the Internet from the salesperson's workstation. If the ping succeeds, then you have verified Network layer, Data Link layer, and Physical layer connectivity because the data you generated had to pass through all those layers to reach the Internet server. Therefore, you should next move up the OSI model and test Transport layer connectivity. If the ping had failed, you might next move down the OSI model to determine whether Data Link layer and Physical layer connectivity exist.

Of course, there are other logical, methodical ways of troubleshooting networks. The aforementioned are simply some common ones. The main thing you should remember as a network administrator is to be mindful and efficient, but not rushed. Don't leap without looking. Just because a current problem looks like a problem you saw once before does not necessarily mean that it has the same cause, and trying to use a previous problem's fix on a new problem could cause more trouble than it fixes.

So although the pace of modern life might sometimes make you feel like Brooks from The Shawshank Redemption, it's worth remembering that there is a place for the methodical minded among us, even among technology. Using the methods described above, you might not be able to solve problems in record time, but you're more likely to solve them effectively and less likely to create new problems along the way.

Studying for a certification exam? Download the Boson NetSim Network Simulator and the Boson Exam Environment today and try our demos!

George Shuttleworth Photo: Paolo Camera

Hope. Which way? Photo: bixentro