RobotnixAcademy

Week 09 · lesson

Lesson 1: Troubleshoot in Layers

Core path: 42 minutes

The fastest way to waste a support period is to change five network settings before proving what failed.

Use a layered evidence order instead.

1 physical / radio link
2 interface and IP configuration
3 local destination
4 default gateway
5 DNS if a name is involved
6 remote host / path
7 service port / application

The exact order can change with the symptom. The discipline does not.

Start with the user report

"The internet doesn't work."

Translate that into an observation:

  • Ethernet disconnected?
  • Wi-Fi not associated?
  • APIPA address?
  • gateway unreachable?
  • DNS failure?
  • remote host unreachable?
  • port refused?
  • application error?

Those are different incidents.

A+ troubleshooting method

Use the technician loop:

  1. identify the problem;
  2. establish a theory of probable cause;
  3. test the theory;
  4. establish a plan and implement the safe solution;
  5. verify full functionality and preventive measures where appropriate;
  6. document findings, actions, and outcomes.

Robotnix adds one rule: preserve the baseline before the change whenever practical.

Guided case

Evidence:

Ethernet link: up
IPv4: 169.254.42.18
Default gateway: none

A reasonable theory is failed expected DHCP configuration.

A poor first action is replacing the router because "internet is down."

Student action

Build a troubleshooting ladder for these symptoms:

  1. no Ethernet link;
  2. APIPA address;
  3. local printer works but gateway fails;
  4. remote IP works but hostname fails;
  5. host reachable but TCP service is refused.

For each, write the next smallest useful test.

Evidence checkpoint

A good technician can say:

Here is the last boundary I proved good. Here is the next boundary I have not proved.

That sentence is more useful than ten random fixes.

Layered network troubleshooting path from physical link through addressing, local subnet, gateway, DNS, remote path, application service, and verification.
Layered network troubleshooting path from physical link through addressing, local subnet, gateway, DNS, remote path, application service, and verification.

Diagrams open at a readable shape-aware scale. Zoom or expand when you need more detail.

Read it. Prove it.

Lesson knowledge checks

Answer from the lesson you just completed. Results stay in this browser and are not submitted.
Knowledge check 1

What is the benefit of troubleshooting a network in layers?

Knowledge check 2

If link lights are down, what should usually be checked before DNS?

system flow

Network Diagnosis: evidence before changes

  1. Symptom

    Define what failed and what still works before changing configuration.

  2. Address / route

    Inspect interface addressing and the path the host intends to use.

  3. Name resolution

    Check whether the destination name maps to the expected address.

  4. Port / service

    Determine whether the remote service is reachable and listening where expected.

  5. Diagnosis

    Use surviving communication and packet-style evidence to bound the failure and uncertainty.

Read this concept flow as plain text
  1. Symptom. Define what failed and what still works before changing configuration.
  2. Address / route. Inspect interface addressing and the path the host intends to use.
  3. Name resolution. Check whether the destination name maps to the expected address.
  4. Port / service. Determine whether the remote service is reachable and listening where expected.
  5. Diagnosis. Use surviving communication and packet-style evidence to bound the failure and uncertainty.