The key to successful troubleshooting is to know how the network functions under normal conditions. If you can't recognise abnormal operation, anything you do is little better than a shot in the dark. Unfortunately, many networking products lack the performance specifications, theory of operation, or condensed technical data to aid in troubleshooting.
The successful technician thoroughly studies the data available, and develops in-depth insight into the function of all components and how to operate them. Finally, he or she remembers that what looks like a serious defect is often the result of misuse, misconfiguration or operator error.
The foundation of this insight comes from formal training, but grows from practical experience. The true troubleshooting master learns in the trenches through trial and error, and compares notes with others to discover useful methods that are not taught in school.
The following information can help shorten your learning curve and give you proven advice on how to isolate and solve network problems. Successful troubleshooters quickly master the following basic concept: a few minutes spent evaluating symptoms can eliminate hours of time lost chasing the wrong problem.
1. Document your network
Up-to-date documentation such as physical and logical maps, performance baselines and audits, device inventories, and so on, will dramatically reduce the amount of troubleshooting time spent in "discovery mode", where you are simply trying to figure out where a specific PC fits in the larger scheme of things.
2. Collect all available information, and analyse the symptoms of the failure
Ask yourself if you understand the symptoms. Can the user demonstrate the problem or can you recreate it? Determine if something was altered at the workstation or on the network just before the problem started.
3. Localise and isolate the problem
Reduce the scope of the problem. Is the problem related to a segment of the network or is it isolated to a single client? Within a single client, the problem can be further isolated to the network, the physical cabling or the workstation. As you will see, the process of collecting information and isolating the problem are often concurrent activities.
Before you head for the door, you should ask yourself, "Is this trip really necessary?" As well as being less effort, it’s more efficient to fix the problem remotely. This can be done by phone, or even by taking control of the user’s PC remotely. There are a variety of tools to do this, including Microsoft’s remote desktop.
Verify that the problem is not the PC: Even with today’s operating system software reliability, "Reboot your PC" is still the mantra of help desk technicians. Sadly, a cold-start reboot resolves so many otherwise inexplicable problems that it really is an unavoidable step.
If a re-boot doesn’t solve the problem then the next thing to look at is the network card configuration.
Verify the PC network card or configuration: This step is to check if the PC has an appropriate address for the subnet to which it is physically or wirelessly connected. If the PC is configured for Dynamic Host Control Protocol (DHCP), but returns a Windows default IP address (169.254.x.x), then the client is not communicating with the DHCP server.
If the address is incorrect, type IPCONFIG from the DOS prompt:
C:\>ipconfig /release then C:\>ipconfig /renew
If this does not work then there is a problem with the DHCP Server or the connection from this PC to it.
If the IP addresses are set statically on your network, then verify that the IP Address, subnet and default router are set correctly for the segment the PC is connected.
If none of this worked it’s time to go to the place where the user is. In this situation an inline tester that isolates the problem between PC and network can save a lot of time.
Verify wired (patch cable) or wireless (RF) connection in to the network: Testing the patch cable must be done with some kind of tool. Swapping the patch cord for another, even if new, will not always enable you diagnose the problem. In most cases at this stage in the process a simple wire map and length test will be useful. A range of tools with wire mapping, link, length and ping functions or even cable certification tools can be used.
To verify a wireless connection you will need a utility or tester to assure the PC is communicating to the right access point. There are a number of functions required to verify wireless connectivity, wireless survey (to identify access points and their properties), security utilities (to verify connectivity to network services), RF Spectrum analysis to verify, signal strength, quality and access point and client population. Wireless protocol analysis may even be required to follow association and authentication process problems. Additional functions like ping, web browsing and throughput testing are also useful.
The service or application is not available on the local or remote network segment: If DHCP is still not working and you know the IP address of the DHCP server. Try pinging it from the PC from the DOS prompt.
Type C:\> ping -t x.x.x.x
If the ping does not respond then Trace Route is useful to isolate the segment where the fault exists. Type
C:\> tracert x.x.x.x or C:\> pathping x.x.x.x
4. Correct the problem and verify resolution
Once isolated, identifying and repairing the specific fault should be simple. For network hardware, it is simplest to replace a part, such as replacing a bad patch cable, changing hub/switch port or client network interface card (NIC). This step is complete when the user tests for the problem (what they were doing when it first occurred) to ensure that it has been repaired.
5. Document what you did
Remember step 1? Having a record of problems and their resolution (such as is offered in many trouble-ticketing applications) builds an internal knowledge base that can be referred to when similar problems occur in the future. This information speeds future troubleshooting sessions.