What is the difference between top-down, bottom-up and divide-and-conquer troubleshooting?
Show the answer
Say this first
All three use the OSI layers as a checklist. Bottom-up starts at the physical layer and works up: thorough but slow, good for new installs or cabling suspicions. Top-down starts at the application and works down: good when one app fails and others work. Divide and conquer starts in the middle, usually with a ping at layer 3. If it works, the lower layers on that path are fine and I go up; if it fails, I go down.
Go deeper
Bottom-up
Link lights and show interfaces status, then counters, speed and duplex, then VLAN, trunk and STP, then
IP and routing, then transport and the application. Nothing is skipped, which is why it wastes time on a
problem that turns out to be DNS.
Top-down
Start with what the user does. Does the page load? Does DNS resolve? Does TCP 443 connect? Then go down to routing and links. Works well when the user's report is specific.
Divide and conquer
Pick the layer that splits the stack, usually layer 3. A successful ping proves the physical layer, the data link and IP routing in both directions along that path, for ICMP. Most experienced engineers start here because one command rules out half the possibilities.
The limit of a passing ping
It does not prove that a TCP port is allowed, that large packets pass, or that the application takes the same path. Policy-based routing, proxies, load balancers and per-protocol firewall rules all break that assumption.
They will ask next
Which one do you use most?
Divide and conquer. A ping and a traceroute from the right source take seconds and cut the problem in half. The moment I see a down link or climbing error counters, I switch to bottom-up.
Where does the OSI model stop helping?
Real faults cross layers. An MTU problem looks like an application hang, and a duplex mismatch looks like slowness. I use the layers as a checklist, not as a diagnosis.
Traps
- Saying a successful ping proves the application path works.