Why start troubleshooting from the bottom of the stack instead of the top?

Because every layer depends on the layers below it. There is no point asking why a website won't load (an application-layer symptom) if the device doesn't even have a valid IP address. Fixing the lower problem often makes the higher symptom disappear on its own. When only one application fails and everything else works, starting from the top can be faster.

What does it mean if I can ping an IP address but not a domain name?

It points to DNS. The link, the routing and the destination all work; the device just can't translate the name into an IP address. Check which DNS server the device uses and whether that server answers.

My connection works but feels slow. Is that the same kind of problem?

Not quite. Slowness is usually caused by delay or packet loss, not by a complete failure at one layer, so a yes/no decision tree won't find it. Compare the ping times to a nearby device and a distant one, look at the interface error counters, and check whether a link is overloaded.

Network Troubleshooting Course: Method, Ping, Traceroute, Show Commands and Common Faults

Troubleshooting

Learn a practical, repeatable way to find what is actually broken on a network, which commands to run on Windows, Linux, macOS and Cisco devices, and what their output means.

Intermediate · 9 lessons + lab + test · Before this: OSI & TCP/IP Models, DHCP, DNS

Network troubleshooting is the structured process of locating and correcting faults in a network, using a repeatable method and diagnostic tools such as ping, traceroute, host commands and device show commands to narrow a problem down to one layer and one cause.

In simple terms: When something on the network stops working, troubleshooting is how you find out what broke and fix it, step by step, instead of guessing.

Good troubleshooting is not guesswork. It is a calm, step-by-step process: describe the problem clearly, check each layer in a sensible order, change one thing at a time, and prove that the fix worked. This course teaches that method, the everyday tools and the faults you will meet most often.

1. Link: is the cable plugged in, is the switch port up, and is it in the right VLAN?
2. Gateway: does the PC have a correct IP address, and can it reach its default gateway?
3. Beyond: do the routers know a path to the remote network, and a path back again?
4. Names: can the PC translate names into IP addresses? If not, everything seems broken even though the network is fine.

Try it: diagnose "the internet isn't working"

Answer each question based on what you would actually see on the device. The tool points you towards where the problem most likely is. The first lesson explains the method behind it.

Learn more: A Troubleshooting Method

Internet not working?

Does the device have a valid IP address?

Check with ipconfig (Windows) or ip addr (Linux/macOS). A 169.254.x.x address counts as "no."

What you'll learn

Work with a method

Define the problem, gather facts, test one idea at a time, apply a fix and confirm that it worked.

Read the tools

Understand what ping, traceroute, ipconfig, ip, arp, nslookup and Cisco show commands are really telling you.

Know the usual faults

Recognise down ports, duplex mismatches, wrong VLANs, bad addresses, missing routes and broken DNS.

Practise on a real case

Work through a small office network with five hidden faults. Find each one, fix it and prove that it is fixed.

Skills you'll gain

Problem definition
Bottom-up / top-down
ping
traceroute
ipconfig / ip
nslookup
show commands
Duplex & VLAN faults
Gateway & routes
DNS

Who is this for?

CCNA students, help desk staff and anyone who gets asked “why is the network down?” You should already know what an IP address, a subnet mask and a default gateway are. The OSI & TCP/IP Models lesson is a good refresher before you start.

Start the first lesson →

FAQ

Why start troubleshooting from the bottom of the stack instead of the top?: Because every layer depends on the layers below it. There is no point asking why a website won't load (an application-layer symptom) if the device doesn't even have a valid IP address. Fixing the lower problem often makes the higher symptom disappear on its own. When only one application fails and everything else works, starting from the top can be faster.
What does it mean if I can ping an IP address but not a domain name?: It points to DNS. The link, the routing and the destination all work; the device just can't translate the name into an IP address. Check which DNS server the device uses and whether that server answers.
My connection works but feels slow. Is that the same kind of problem?: Not quite. Slowness is usually caused by delay or packet loss, not by a complete failure at one layer, so a yes/no decision tree won't find it. Compare the ping times to a nearby device and a distant one, look at the interface error counters, and check whether a link is overloaded.