# data[].attributes.body
The follow-the-path approach is one of the most basic troubleshooting techniques, and it usually complements one of the other troubleshooting methods such as the top-down or the bottom-up approach. The follow-the-path approach first discovers the actual traffic path all the way from source to destination. Next, the scope of troubleshooting is reduced to just the links and devices that are actually in the forwarding path. The principle of this approach is to eliminate the links and devices that are irrelevant to the troubleshooting task at hand.

# data[].attributes.body
The divide-and-conquer troubleshooting method strikes a balance between the top-down and bottom-up troubleshooting approaches. If it is not clear which of the top-down or bottom-up approaches will be more effective for a particular problem, an alternative is to start in the middle (typically the network layer) and perform some tests such as ping. Ping is an excellent connectivity testing tool. If the test is successful, you can assume that all lower layers are functional, and so you can start a bottom-up troubleshooting starting from this layer. However, if the test fails, you can start a top-down troubleshooting starting from this layer. Whether the result of the initial test is positive or negative, this method will usually result in a faster elimination of potential problems than what you would achieve by implementing a full top-down or bottom-up approach. Therefore, the divide-and-conquer method is considered a highly effective troubleshooting approach.

# data[].attributes.body
Troubleshooting Method

The bottom-up troubleshooting approach also uses the OSI model as its guiding principle with the physical layer (bottom layer of the OSI stack) as the starting point. In this approach you work your way layer by layer up toward the application layer, and verify that relevant network elements are operating correctly. You try to eliminate more and more potential problem causes so that you can narrow down the scope of the potential problems. A benefit of this method is that all of the initial troubleshooting takes place on the network, so access to clients, servers, or applications is not necessary until a very late stage in the troubleshooting process. Based on experience, you will find that most network problems are hardware related. If this is applicable to your environment, the bottom-up approach will be most suitable for you. A disadvantage of this method is that, in large networks, it can be a time-consuming process, because a lot of effort will be spent on gathering and analyzing data and you always start from the bottom layer. The best bottom-up approach is to first reduce the scope of the problem using a different strategy and then switch to the bottom-up approach for clearly bounded parts of the network topology.
https://www.youtube.com/watch?v=3dc7ZmWpjcc

# data[].attributes.body
The top-down troubleshooting method uses the OSI model as a guiding principle. One of the most important characteristics of the OSI model is that each layer depends on the underlying layers for its operation. This implies that if you find a layer to be operational, you can safely assume that all underlying layers are fully operational as well. So for instance, if you are researching a problem of a user that cannot browse a particular website and you find that you can establish a TCP connection on port 80 from this host to the server and get a response from the server, you can typically draw the conclusion that the transport layer and all layers below must be fully functional between the client and the server and that this is most likely a client or server problem and not a network problem. Be aware that in this example it is reasonable to conclude that Layers 1 through 4 must be fully operational, but it does not definitively prove this. For instance, non-fragmented packets might be routed correctly, while fragmented packets are dropped. The TCP connection to port 80 might not uncover such a problem. Essentially, the goal of this method is to find the highest OSI layer that is still working. All devices and processes that work on that layer or layers below are then eliminated from the scope of the problem. It might be clear that this method is most effective if the problem is on one of the higher OSI layers. This approach is also one of the most straightforward troubleshooting methods, because problems reported by users are typically defined as application layer problems, so starting the troubleshooting process at that layer is an obvious thing to do. A drawback or impediment to this method is that you need to have access to the client's application layer software to initiate the troubleshooting process, and if the software is only installed on a small number of machines, your troubleshooting options might be limited.

# data[].attributes.headline
ATIKAH HAZIMAH BINTI HATA (03DDT16F1098)

# data[].attributes.subject
ATIKAH HAZIMAH BINTI HATA (03DDT16F1098)

# data[].attributes.body
INTRODUCTION

Troubleshooting is a form of problem solving, often applied to repair failed products or processes on a machine or a system. It is a logical, systematic search for the source of a problem in order to solve it, and make the product or process operational again. Troubleshooting is needed to identify the symptoms. Determining the most likely cause is a process of elimination—eliminating potential causes of a problem. Finally, troubleshooting requires confirmation that the solution restores the product or process to its working state.

PROCESS

1. Power Cycle Everything and Check Other Devices

There’s no need to get upset right away, as the fix to your problem might be as simple as rebooting your equipment. Restarting fixes a ton of issues, so make sure it’s your first response to network issues, too.

Go ahead and reboot your PC, as well as your modem and router. To clear the modem and router caches, wait 60 seconds before you turn them back on again. Turning everything off and back on first ensures that it isn’t a temporary problem. It’s better to reboot now than to waste 30 minutes continuing on when you don’t need to.

2. Check Physical Connections

Does your problem persist after rebooting? Before we start diving into settings and tests, the next thing to check is that you’re physically connected. If you use an Ethernet cable to connect to your router, check to make sure that it’s not unplugged. If your laptop has a physical wireless switch (check specific tips for fixing wireless connections), make sure that it didn’t get bumped to the off position.

Once you’ve verified a proper connection, check your equipment. Are the lights on your router and/or modem flashing green as normal? If no lights come on after the reboot, the device could be dead. If you get red lights, or a power light but no connection light, your ISP is likely down.

3. Run the Network Troubleshooter

Windows includes some built-in troubleshooters that can automatically find and fix issues. To run the troubleshooter for network problems, right-click the network icon in your System Tray and choose Troubleshoot Problems. Once the troubleshooter runs, it could fix issues, find issues but fail to fix them, or find no issues.

If the troubleshooter finds a problem that it fixes, try to connect again. If you get a specific error or problem name that Windows can’t fix automatically, take note of it for later research.

4. Check for a Valid IP Address

At this point, we’ve verified that the problem is not temporary and that all of our hardware works. Since Windows can’t fix the problem on its own, we need to pinpoint the spot along the connection where the problem is occurring.

5. Try a Ping and Trace Its Route

If your IP address starts with anything other than 169 when you run ipconfig, you have a valid IP address from your router and the problem is occurring between your router and the internet.

Type this command to ping Google’s DNS servers to see if you can get online: (you can replace 8.8.8.8 with anything, such as www.msn.com)

ping 8.8.8.8

This will send four packets to Google. If they fail to send, you’ll be told what the problem was. For more information, type this line to trace the route between your computer and Google’s DNS servers:

tracert 8.8.8.8

The above command gives you a step-by-step breakdown of the path that the information takes to reach the destination you specify. Watch it, and if it fails, check to see where the problem occurs. If an error pops up early in the route, the issue is likely with your local network.

6. Contact Your ISP

Should all the above steps complete successfully, we’ve verified that our equipment is working, we have a valid IP address from the router, and the problem is occurring outside of our network for multiple devices. If this is the case, your next best option is to find out if your ISP is having issues.

VIDEO

https://www.google.com/url?sa=t&source=web&rct=j&url=%23&ved=0ahUKEwj3kM7anL7SAhUNS48KHTp4ACsQxa8BCBkwAA&usg=AFQjCNF1sHlk2z9QIx28jtvfnGP_UlkifA&sig2=GHpT3h81dBubRzWdbgB17w

PHOTOS

# data[].attributes.body
A structured troubleshooting method is used as a guideline through a troubleshooting process. The key to all structured troubleshooting methods is systematic elimination of hypothetical causes and narrowing down on the possible causes. By systematically eliminating possible problem causes, you can reduce the scope of the problem until you manage to isolate and solve the problem. If at some point you decide to seek help or hand the task over to someone else, your findings can be of help to that person and your efforts are not wasted.
Commonly used troubleshooting approaches include the following:
~Top down: Using this approach, you work from the Open Systems Interconnection (OSI) model's application layer down to the physical layer.
~Bottom up: The bottom-up approach starts from the OSI model's physical layer and moves up to the application layer.
~Divide and conquer: Using this approach, you start in the middle of the OSI model's stack (usually the network layer) and then, based on your findings, you move up or down the OSI stack.
~Follow the path: This approach is based on the path that packets take through the network from source to destination.
~Spot the differences: As the name implies, this approach compares network devices or processes that are operating correctly to devices or processes that are not operating as expected and gathers clues by spotting significant differences. In case the problem occurred after a change on a single device was implemented, the spot-the-differences approach can pinpoint the problem cause by focusing on the difference between the device configurations, before and after the problem was reported.
~Move the problem: The strategy of this troubleshooting approach is to physically move components and observe whether the problem moves with the components.

# data[].attributes.headline
SITI ROJIHAH BINTI MOHD ROZI (03DDT16F1084) Troubleshooting Methodologies

# data[].attributes.subject
SITI ROJIHAH BINTI MOHD ROZI (03DDT16F1084) Troubleshooting Methodologies

# data[].attributes.body
Troubleshooting is not an exact science, and a particular problem can be diagnosed and sometimes even solved in many different ways. However, when you perform structured troubleshooting, you make continuous progress, and usually solve the problems faster than it would take using an ad hoc approach. There are many different structured troubleshooting approaches. For some problems, one method might work better, whereas for others, another method might be more suitable. Therefore, it is beneficial for the troubleshooter to be familiar with a variety of structured approaches and select the best method or combination of methods to solve a particular problem.