network until the possible cause of the problem is found. It is a requirement to document each conclusion and possibility. The challenge is to determine which devices to start with. In many cases, problems within the first four layers can be determined by entering a ping or traceroute command. If the connection is successful, then the cause is likely at the application level. Otherwise, a closer look at the lower levels will be needed to locate the problem. Verify that Internet control message protocol (ICMP) echo request and echo reply are enabled on the network in order for commands such as ping and traceroute to work. This action should include authorization from the network administrator and documentation of that authorization. If ping has been disabled on the network, it is a result of the implementation of policy. Document in a station log or your personal work log that ping, or any command that was initially disabled, was enabled for network testing and subsequently disabled. This is important should there be an unauthorized intrustion into the network while you are troubleshooting the network. If disabled, the failure of a ping or traceroute command can easily be mistaken for a loss of connectivity.
Content 2.2 Troubleshooting Approaches 2.2.3 Top-down When applying a top-down approach towards troubleshooting a networking problem, the end user application is examined first. Then work down from the upper-layers of the OSI model until the cause of the problem has been identified. When a troubleshooter selects this approach, the applications of an end system are tested before tackling the more specific networking pieces. A troubleshooter would most likely select this approach for simpler problems or when the troubleshooter thinks that the problem is with a piece of software. The disadvantage to selecting this approach is that it requires checking of every network application until the possible cause of the problem is found. It is a requirement to document each conclusion and possibility. Like the bottom-up approach, the challenge is to determine which application to start with.
Content 2.2 Troubleshooting Approaches 2.2.4 Divide and conquer When the divide and conquer approach is applied towards troubleshooting a networking problem, a layer is selected and tested in both directions from the starting layer. The divide and conquer approach is initiated at a particular layer. The layer is based on troubleshooter experience level and the symptoms gathered about the problem. Once the direction of the problem is identified, troubleshooting follows that direction until the cause of the problem is identified. If it can be verified that a layer is functioning, it is typically a safe assumption that the layers below it are functioning as well. If a layer is not functioning properly, gather symptoms of the problem at that layer and work downward to lower layers.
Content 2.2 Troubleshooting Approaches 2.2.5 Guidelines for selecting and approach When selecting an effective troubleshooting approach to solve a network problem, the problem is usually resolved in a quicker, more cost-effective manner. Consider the following when selecting an effective troubleshooting approach. Determine the scope of the problem
A troubleshooting approach is often selected based on its complexity. A bottom-up approach typically works better for complex problems. Using a bottom-up approach for a simple problem may be overkill and inefficient. Typically, if symptoms come from users then a top-down approach is used. If symptoms come from the network, a bottom-up approach will likely be more effective. Apply previous experiences
If a particular problem has been experienced previously, then the troubleshooter may know of a way to shorten the troubleshooting process. A less experienced troubleshooter will likely implement a bottom-up approach, while a skilled troubleshooter may be able to jump into a problem at a different layer using the divide and conquer approach. Analyze the symptoms
The more known about a problem, the better the chance that it can be solved. It may be possible to immediately correct a problem simply by analyzing the symptoms. Example
Two IP routers have been identified in a network that have connectivity, but are not exchanging routing information. Before attempting to solve the problem, a troubleshooting approach needs to be selected. Similar symptoms have been seen previously, which point to a likely protocol issue. Since there is connectivity between the routers, it is not likely to be a problem at the physical or data link layer. Based on this past experience knowledge, it is decided to use the divide and conquer approach, and the troubleshooter begins testing the TCP/IP-related functions at the network layer.
Content 2.3 Gathering Symptoms 2.3.1 Gathering symptoms for a network problem Following are the stages for gathering symptoms for a network problem:Stage 1
The troubleshooter analyzes symptoms gathered from the trouble ticket, users, or end systems affected by the problem to form a definition of the problem. Stage 2
If the problem is in the troubleshooter’s system, it will be necessary to move on to stage 3. If the problem is outside the boundary of the troubleshooter’s control, it will be necessary to contact an administrator for the external system before gathering additional network symptoms. Stage 3
The troubleshooter determines if the problem is at the core, distribution or access layer of the network. At the identified layer use an analysis of existing symptoms and knowledge of the network topology to determine which piece or pieces of equipment are the most likely cause. Stage 4
Using a layered troubleshooting approach, the troubleshooter gathers hardware and software symptoms from the suspect devices. The technician starts with the most likely possibility and uses knowledge and experience to determine if the problem is more likely a hardware or software configuration problem. Stage 5
Document any hardware or software symptoms. If the problem can be solved using the documented symptoms, a troubleshooter will solve the problem and document the solution. If the problem cannot be solved, the technician begins the isolating phase of the general troubleshooting process. Be prudent with use of the debug command on a network. It generates enough console message traffic that the performance of a network device can be noticeably affected. Be sure to disable debugging when its capabilities are no longer needed.
Content 2.3 Gathering Symptoms 2.3.2 Gathering symptoms from an end-user: hardware When gathering symptoms for perceived hardware problems, a troubleshooter should physically inspect or ask for physical inspection of the devices using the senses of hearing, sight, smell, and touch. Physical symptoms may be related, but not limited, to the following:
Content 2.3 Gathering Symptoms 2.3.3 Gathering symptoms from an end-user: software When gathering symptoms for probable software configuration problems, a troubleshooter should start at the last known point where the network functioned correctly. If an end-user station can successfully ping the gateway but not the DNS server on another network segment, then an entire set of potential problems associated