Network Troubleshooting


A General Approach For Troubleshooting:
Network engineers, administrators, and support personnel realize that troubleshooting is a process that takes the greatest percentage their time. Using efficient troubleshooting techniques shortens overall troubleshooting time when working in a production environment.
Two extreme approaches to troubleshooting almost always result in disappointment, delay, or failure. At one extreme is the theorist, or rocket scientist, approach. At the other extreme is the impractical, or caveman, approach.
The rocket scientist analyzes and reanalyzes the situation until the exact cause at the root of the problem has been identified and corrected with surgical precision. While this process is fairly reliable, few companies can afford to have their networks down for the hours or days that it can take for this exhaustive analysis.

The caveman's first instinct is to start swapping cards, cables, hardware, and software until miraculously the network begins operating again. This does not mean that the network is working properly, just that it is operating. While this approach may achieve a change in symptoms faster, it is not very reliable, and the root cause of the problem may still be present.
Since both of these approaches are extremes, the better approach is somewhere in the middle using elements of both. It is important to analyze the network as a whole rather than in a piecemeal fashion. A systematic approach minimizes confusion and cuts down on time otherwise wasted with trial and error.

Using Layered Method For Troubleshooting:
OSI Versus TCP/IP Layered Models
Logical networking models, such as the OSI and TCP/IP models, separate network functionality into modular layers. When troubleshooting, these layered models can be applied to the physical network to isolate network problems. For example, if the symptoms suggest a physical connection problem, the network technician can focus on troubleshooting the circuit that operates at the physical layer. If that circuit functions properly, the technician looks at areas in another layer that could be causing the problem.

OSI Reference Model
The OSI model provides a common language for network engineers and is commonly used in troubleshooting networks. Problems are typically described in terms of a given OSI model layer.
The OSI reference model describes how information from a software application in one computer moves through a network medium to a software application in another computer.
The upper layers (5-7) of the OSI model deal with application issues and generally are implemented only in software. The application layer is closest to the end user. Both users and application layer processes interact with software applications that contain a communications component.
The lower layers (1-4) of the OSI model handle data-transport issues. Layers 3 and 4 are generally implemented only in software. The physical layer (Layer 1) and data link layer (Layer 2) are implemented in hardware and software. The physical layer is closest to the physical network medium, such as the network cabling, and is responsible for actually placing information on the medium.

TCP/IP Model
Similar to the OSI networking model, the TCP/IP networking model also divides networking architecture into modular layers. The figure shows how the TCP/IP networking model maps to the layers of the OSI networking model. It is this close mapping that allows the TCP/IP suite of protocols to successfully communicate with so many networking technologies.
The application layer in the TCP/IP suite actually combines the functions of the three OSI model layers: session, presentation, and application. The application layer provides communication between applications such as FTP, HTTP, and SMTP on separate hosts.
The transport layers of TCP/IP and OSI directly correspond in function. The transport layer is responsible for exchanging segments between devices on a TCP/IP network.
The TCP/IP Internet layer relates to the OSI network layer. The Internet layer is responsible for placing messages in a fixed format that allows devices to handle them.
The TCP/IP network access layer corresponds to the OSI physical and data link layers. The network access layer communicates directly with the network media and provides an interface between the architecture of the network and the Internet layer.

General Troubleshooting Procedure:
The stages of the general troubleshooting process are:

Stage 1 Gather symptoms - Troubleshooting begins with the process of gathering and documenting symptoms from the network, end systems, and users. In addition, the network administrator determines which network components have been affected and how the functionality of the network has changed compared to the baseline. Symptoms may appear in many different forms, including alerts from the network management system, console messages, and user complaints.
While gathering symptoms, questions should be used as a method of localizing the problem to a smaller range of possibilities.
Stage 2 Isolate the problem - The problem is not truly isolated until a single problem, or a set of related problems, is identified. To do this, the network administrator examines the characteristics of the problems at the logical layers of the network so that the most likely cause can be selected. At this stage, the network administrator may gather and document more symptoms depending on the problem characteristics that are identified.
Stage 3 Correct the problem - Having isolated and identified the cause of the problem, the network administrator works to correct the problem by implementing, testing, and documenting a solution. If the network administrator determines that the corrective action has created another problem, the attempted solution is documented, the changes are removed, and the network administrator returns to gathering symptoms and isolating the problem.
These stages are not mutually exclusive. At any point in the process, it may be necessary to return to previous stages. For instance, it may be required to gather more symptoms while isolating a problem. Additionally, when attempting to correct a problem, another unidentified problem could be created. As a result, it would be necessary to gather the symptoms, isolate, and correct the new problem.
A troubleshooting policy should be established for each stage. A policy provides a consistent manner in which to perform each stage. Part of the policy should include documenting every important piece of information.

0 comments:

Post a Comment

 

NBA Live Streaming. Copyright 2008 All Rights Reserved Revolution Two Church theme by Brian Gardner Converted into Blogger Template by Bloganol dot com | Distributed by Blogger Templates Blog