Purpose
The aim of this project is to give a guideline on network troubleshooting. The project attempts to illustrate how the guide will help the PC support team comprehend the basics and eliminate the work load for the network administrator, save time and money for remote campuses.
In essence, the PC support technician will be able to solve several network issues with no assistance, and acts as a network technician in case the network technician is not available.
Context of the situation
Network troubleshooting normally occurs in learning environments. Skilled labor is hard to come by in a remote campus. The campus has just installed a new PC in the office. Everything seems fine till the next day. No teacher can send any mail and one of the fellows decide it is time to rebuild the mail server. However, the support technician realizes that the only change since yesterday is the new PC.
When technician disconnects the PC from the network system, the trouble disappears. The new PC reveals a broken wire, which caused the problem affecting the mail server. Once the support technician replaces the cable, everything returns to normalcy. The trouble of having to rebuild a fine mail serve is no longer an issue. The point is network troubleshooting is not always easy to recognize and fix.
More often than not, it is always difficult to know what has changed or even who has changed it. This is a case of nobody admits anything principle common in the field of IT. Sometimes the system just breaks without any human interference. The challenge is network ties everything together, and any element might be a source of trouble.
The support technician should simply figure out what the trouble is, or its source is but most importantly must not blame the network. The rule is the support technician should just know a little bit about everything in order to start troubleshooting a problem, and then adapt and learn as possible in order to solve a given problem in the network systems.
The current focus and justification of the study
Not much of AR studies have focused on teaching and network troubleshooting in a learning environment. As teaching and instruction integrate IT systems, the teacher or the network support technician needs to learn troubleshooting in the network systems in order to handle not so complex network troubleshooting cases.
The cyclic nature of AR will enable the support technician to master networking knowledge through redoing one task over and over. This knowledge will be useful in remote campus where getting skilled labor is difficult (Sleeter & Cornbleth, 2011).
Literature review
The initial stage in a network problem diagnosis is to collect information. Collecting information entails getting if from the users as per the nature of the problem they are experiencing and collecting data from the network. The success of resolving a problem depends on efficiency in collecting data, and the quality of data the technician collects. Therefore, network troubleshooting starts with the collection of data.
Approaches to troubleshooting
The best thing for a technician is to learn troubleshooting through experience because of its complex nature. The key step is to collect information. Technicians can avoid troubleshooting, but they cannot escape it. The best way is to master sound engineering practices, redundancy, documentation, and training.
Information collection in networking troubleshooting relies on three methods mainly bottom-down approach, top-up approach and divide and conquer approach. All these strategies are depended on the seven-layer ISO model.
The first move is to reset the system. Problems like bit rot, alignment of the planets or cosmic rays may force system into a strange state, which it cannot exit. This is the best way to get rid of system fluke. The technician should keep in mind that there are several ways of rebooting a system.
For instance, simple restart of the program, sending the signal to the system in order to reload the initialization file restores the problem. This is the least disruptive method. Alternatively, the technician can restart the system but without cycling the power i.e. a warm reboot, or do a cold reboot (Feldman, 2003).
AR teachers should beware of dangers associated with resetting the system. For instance, it is common inadvertently make changes to the system so that it cannot reboot. However, the teacher can correct the problem. If the system has shut down already, then it may be too late. Systems, which do not have a backup boot disk, may force the administrator to rebuild the system (Pine, 2009).
Scheduled maintenance requires restart of the system. The support technician then tests the changes he has made, including their impacts on a system reset. Prior to such maintenance, ensure that there are no problems or else the system can fail restart. It is worth to do resetting more than once.
An operating system with no adequate memory protection normally becomes a wedge. Therefore, rebooting is the best option. As time goes by, rebooting becomes part of the support technician normal procedure.
The next stage involves swapping and reinstalling components and software. The support technician should use spare components to resolve problems. Software reinstallation is problematic. Reinstallation more often leads to configuration mistakes that create more problems. The support technician should master the system configuration to avoid errors. These are just quick steps into troubleshooting.
Troubleshooting strategies
When facing a network troubleshooting problem, the support technician should be able to select a suitable tool for the problem and augment with other tools as necessary. Look at the specific task and select the most appropriate tool based on the problem and solution needed (Sloan, 2001).
The generic troubleshooting tasks involve several steps. The steps differ depending on the nature of the problems. The fundamental point is that mapping out the steps eliminates unnecessary steps and help the technician to stay focused.
Documentation: the support technician should document what he is going to do before starting anything else. It is difficult, but the management may require the report. Reports may also be necessary if the problem persists particular where the trouble results into legal consequences. At the same time, reports are useful when handling complex problems.
Information gathering and identification of symptoms: the support technician should collect information as he filters for any indicator of unusual behavior. These two steps recur throughout the troubleshooting steps.
The support technician must keep in mind that if he cannot recognize a normal system behavior, then it will be impossible to recognize anomalous behavior. Technician should recreate the problem in order to observe it directly. For instance, support technician should check on both local and remote hosts in order to see the extent of the problem.
Definition of the problem: once the support technician as defined the problem, he can now begin coming to terms with it. This process involves joining the symptoms and making generalizations. The idea is to look for a common element for succinct description of the unusual behavior.
The support technician may redefine the problem several times and regenerate several other problems. Keep on redefining the problem as new pieces of information emerges.
iv. Identification of the system and subsystems affected: the support technician should define and refine the nature and scope of the problem. This is a step in dividing and conquering the problem. This step strives to narrow the problem. However, in networking, the opposite may just happen. The support technician should develop a full scope of the problem before narrowing down.
Developing of testable hypothesis: what the support technician can tests depends on the tools he has. Once the support technician has defined and refined the problem, he then generates the hypotheses as to the nature or cause of the problem. The hypotheses must be verifiable.
He should be able to develop a couple of tests. He should keep in mind that the hypotheses must be guided by what he tests. AR believes in both answers i.e. either right or wrong answer. In this case, the support technician must go back and develop new hypotheses. He should keep it as simple as he can.
Selection and application of test: tests vary in their applications and testing. The support technician should identify the optimal order for a set of tests. Simple tests, which answer the questions clearly, are the best options.
Assessment of results: according Action Research, as the support technician performs tests, he will need to assess the outcomes, refine the tests, and do the process again. This is a cyclic or iterative nature of AR. The support technician must perform new tests that confirm his results.
Development and assessment of solutions: once the support technician has identified the problem, he must develop and assess possible alternative solutions.
Several problems are most likely to give several alternatives. Support technician should not hurriedly implement a solution before he figures out its consequences. The solutions may range from rebooting the system to reinstalling the software. Choose the simple solution first i.e. reboot the system.
Implementation and evaluation of the solution: once the support technician has decided on a solution and implemented it, he should confirm the efficiency operation of the system. A system may require extensive testing if the ranges of changes needed are numerous. This may imply that testing all the systems and their subsystems. For instance, a connection gets restored when the support technician rebooted the system.
The fundamental question to ponder over is the cause of the problem. Further, the support technician should inquire whether rebooting the system is the final solution to the problem. Conversely, if rebooting the system did not produce any positive results, what would have been the next course of action? AR guidelines provide alternatives for the researcher to go over and restart the process till he finds the solution.
If the software has been corrupted how can the support technician handle it? The best way is to run an integrity checker and try to locate any changes then do a selective reinstallation. If the technician ignores the selective reinstallation, then the support technician may be forced to reinstall the whole system again. The fundamental lesson is to start with the simple solution, even for complex problems.
There are task-specific troubleshooting problems. These guidelines focus on generic steps of network troubleshooting. The support technician should take into account that each problem will be different. Therefore, he will need to vary his approaches to fit a specific identified problem.
The specific network troubleshooting testing normally involves installation testing, firewall, performance monitoring and analysis, bottleneck analysis, among others (Ranjbar, 2010).
Methods and sources of information (reflective model)
The best sources of information in network troubleshooting situation are people who use the IT systems to teach in a learning environment. Therefore, using the reflective model in AR, the support team can use a suitable method to collect the data and analyze for the sake of resolving the problem. Another source of information is a PC and its components itself.
Support technician should observe any anomalous behavior in the system and notes them down. However, he must be able to differentiate between normal behavior, and abnormal behavior of a PC. Otherwise he will not be able to detect any network troubleshooting problem (Kozierok, 2005).
There are several approaches to network troubleshooting. These approaches all depends on the seven-layer model. The layer tries to look at physical connections, data transmission and links, network systems, transport systems, session runs, presentation and application (Ranjbar, 2010).
The bottom-up method looks at the network physical layer of the networking troubleshooting. The support technician collects data related to damages to network cable and network interface cards. In case of any broken cables or disconnected cables, then troubleshooting may end here and he fixes the problem before proceeding for any further troubleshooting. The support technician may move on to the data link layer.
Top-down method is the opposite of a bottom-up method. In this case, the troubleshooting starts at the top of the model i.e. at the application down to the physical layer in the model.
Most network support technicians like to use divide and conquer method, as in the example in the context situation. Technician gathers data from the place most likely to be the source of the problem. From here, he can take either direction in the ISO model.
Description of the results
These are practical situation in troubleshooting network problems. The support technician chooses an approach to provide him with results depending on where the problem lies. We have a situation where a user cannot access Web pages or browse. The support technician may decide that most users have a problem with their browsers, spyware and firewalls. He may wish to adopt the top-down approach.
However, if one user has just confirmed to him that he just connected his laptop to the network system, then he may use divide and conquer by eliminating that laptop first to determine the cause of the problem either a disconnected cable or some other similar forms of interferences.
Reflective analysis
Study outcomes
This Action Research project aims to provide a guideline for a network support technician on the basics of network troubleshooting and problem resolutions. Network problem resolution is not a linear process, but rather is a step by step process with multiple intricate.
The study outcome shows that a support technician should master the knowledge of network troubleshooting in mostly used and easily accessible maintenance troubleshooting commands, and their related software tools. Maintenance of network switches is fundamental in diagnosis of network troubleshooting problems. The support technician should pay close attention to maintenance and troubleshoot of routing protocol.
Since networking relies on the IP addresses configuration, any alteration in the addresses might results into failure of mail deliveries. Therefore, routine maintenance and troubleshoot of IP address forms part of his core jobs.
Occasionally, network performance might not perform as expected. In this regard, maintenance and troubleshoot of networking speeds to detect any anomalies is crucial in a networking environment. Data and information are crucial for any organization. Most institutions are investing heavily to secure their data.
A network administrator should have a profound knowledge on maintaining and troubleshooting network security and implement and any security feature in the system so as to secure data.
Own process
Most network support technicians do not like to adopt troubleshooting methodology when handling networking issues. However, networking troubleshooting methodologies are useful in handling a given troubleshooting in the network system.
Inquiry into this project reveals that the best approach to troubleshooting network problem depends on the technician’s adoption of guides and methodology. Even most complex network problems start with a simple step in resolving.
The development in IT system has brought several tools to help network administrators detect problems in their systems. Network troubleshooting research tools, such as Ethereal can analyze and troubleshoot a network in a matter of minutes and saves the institutions time and money when looking for skilled labor in a remote location.
There are several versions depending on your networking systems and operating systems of an institution. These versions include Sniffer, Observer. At the same time, there are organizations specializing on network troubleshooting such as tripwire.
This Action Research gives insight for teachers who might be stranded in a remote location on how to hand issues of network problems. The teacher should bear in mind that the problems on networks are not fixed neither are they linear. The cyclic nature of it is the essence of AR in solving such problems.
Significance of insights
We realize that AR studies into network troubleshooting provide ideal guidelines to remote support technicians. However, not every teacher or support technician in charge of network administration cares to keep documentation, but other probably does. It is significant to note that meeting the ideals of network troubleshooting is useful for support technician and management of an institution for the future references.
Special software exists for network administrators’ use in troubleshooting network problems. At the same, the there are specialized companies dealing with network troubleshooting.
Most network administrators do not like the use of troubleshooting methodologies in resolving network problems. However, it is necessary to do so since it saves a lot of time and useful for the records.
The information support technician is collecting are usually tied to activities of individuals. Therefore, the technician should consider such information highly confidential, and he should gather only the information he needs in order to resolve the problem.
He should beware that even seemingly innocent institution’s information may be sensitive in a given context. For instance, in resolving mail troubleshooting, the address pairing in source and destination may exposure communications between individuals that they prefer to remain confidential.
References
Feldman, J. (2003). Sams Teach Yourself Network Troubleshooting in 24 Hours, 2nd Edition. Indianapolis, Indiana: Sams Publishing.
Kozierok, C. M. (2005). The TCP/IP Guide. Ontario: John Wiley & Sons.
Pine, G. J. (2009). Teacher action research; building knowledge democracies. Boston: Sage Publications.
Ranjbar, A. (2010). Troubleshooting and Maintaining Cisco IP Networks (TSHOOT) Foundation Learning Guide. Indiana: Cisco Press.
Sleeter, C. E. & Cornbleth, C., Eds. (2011). Teaching with vision: Culturally Responsive Teaching in Standards-Based Classrooms. New York: Teachers College Press.
Sloan, J. D. (2001). Network Troubleshooting Tools. Los Altos Hills, CA: O’Reilly.