Create New Article

Wiki Search

Personal tools

Network Troubleshooting - A Case Study

From Proprofs

Network Troubleshooting - A Case Study

You are here: Home > Schools > Comptia > Network+ Certification > Wiki Home >Study Guide

Instead of continuing on with Network+ material here, we would like to take a moment to stop working on the facts and knowledge tidbits covered in the exam to instead work on basic network troubleshooting skills. Network troubleshooting is perhaps the most important network-related skill; as a Network+ technician, you will likely be troubleshooting existing, unfamiliar networks. Many times, you will be working on platforms covered in the Network+ exam, but even when you are not, you can utilize basic troubleshooting logic to resolve issues with even the most obscure networking platforms and setups.

[edit section] Putting it in Perspective

As with virtually all troubleshooting, the fundamental rationale in network troubleshooting is to eliminate potential causes of the issues by process of elimination. Before considering how you would go about network troubleshooting, consider something a bit more familiar to you. For example, perhaps you could not call your Aunt Margaret. You begin to fear the worst – Margaret is over 90 years old and lives in a nursing home. So, you try to go about reaching her. First, you attempt to call her again, but nobody picks up. Then, you call the nursing home, but nobody picks up there as well. You breathe a sigh of relief because it now seems that the nursing home as a whole is having issues with calls.

You then attempt to contact your friend Jane. However, Jane doesn’t pick up as well. You call her cell, and she still doesn’t pick up. You try other friends to no avail. It now seems to you that your phone line connection as a whole is at fault.

The process described above was essentially a troubleshooting process. By calling different people until you arrived at a conclusion, you were able to eliminate (or implicate) a point of failure. Of course, your efforts are not failsafe. Perhaps the reason that none of the people are picking up is because they all suffered terrible and painful deaths, or perhaps (even more likely) they were simply unable to reach the phone. The point is, troubleshooting is not an exact science, but by contacting all of the potential points of failure, you can usually implicate a particular one (or particular ones).

[edit section] The Real World

Let us now consider a more technical example. A coworker cries to you that she cannot access the Internet and therefore cannot complete mission-critical work. The first thing that should come to your mind is not the fact that she cannot access the Internet, but that she cannot access the company network. You then generate a list of potential failure points:

  • PC TCP/IP is not configured
  • PC TCP/IP is configured incorrectly
  • IP address conflict
  • DHCP issue
  • Media issue
  • Switch/hub issue
  • Gateway issue
  • WAN Issue
  • Remote host issue

As you can see, there are quite a number of “potential points of failure” associated with the described issue; in fact, for the sake of brevity, not all of them are included above. The point is that these potential points of failure can all be independently assessed by holding all others the same. Typically, we work “bottom-up,” meaning first from the client PC and ending at the widest possible explanation (for example, the faraway remote host).

So, first youproceed to test if TCP/IP is configured at all on the host computer. The easiest way to do this is to simply ping the local host, or (if you remember your IP addressing), Once the local host returns four replies, you then know TCP/IP is configured.

Upon checking the IP configuration, you determine that the IP address information is automatically configured by DHCP, so you proceed to run ipconfig and check if the said information is actually configured. You further determine that the IP address is and that the default gateway is

Running through our checklist of sorts, we next check if we can ping the default gateway. No replies are returned which means there is a connection issue between the host and the gateway. Checking the media running from the host to the switch, everything appears to be ok. From the switch to the gateway, however, there is a kink in the media caused by what appears to be excessive wear and tear. After replacing the media, all is ok again and the world is once again a happy place.

This short lesson in troubleshooting should have taught you two basic lessons: first, that ping (if it's not turned off on the network for security reasons) is without question your best friend, but second, that even with an almost endless number of potential causes, a network issue can usually be spotted and corrected in a small number of steps.

In the following lessons we will return to Network+ related content, but remember the basic premise of network troubleshooting: identify the issue, determine potential causes of the issue, and eliminate the causes by process of elimination to determine and correct the exact cause of the issue.

Top 5 Contributors to this article

UsersArticle Contributions
Jbrown 4 contribs
Proprofs 1 contribs
lightfoot 1 contribs
Bamim2 1 contribs
Cameronb 1 contribs

Home  |  Site Map  |  Contact
Copyright © 2005-2014 - Privacy & Terms