Lesson 5: Local Network Fault Isolation

"The internet is down" tells you what the user feels.

It does not tell you where the network path failed.

A technician should be able to move through the path and identify the last boundary that still works.

Use this sequence:

NIC / radio
   ↓
physical or wireless link
   ↓
local IP configuration
   ↓
same-subnet destination
   ↓
default gateway
   ↓
remote IP path
   ↓
name / service layers

This week stops before the deeper DNS and service work. The goal is to prove the local path first.

Case 1: no Ethernet link

Evidence:

interface: disconnected
link indicators: absent
known-good switch port: available

Do not troubleshoot DHCP yet.

A client cannot obtain normal network configuration over a path that is not linked.

Start with:

• cable;
• connector;
• NIC state;
• switch port;
• known-good comparison.

If a known-good cable immediately restores link, the evidence narrows toward the original cable path.

Case 2: link exists, but the client has APIPA

Evidence:

link: up
IPv4: 169.254.22.19/16
gateway: none
network design: DHCP on 192.168.40.0/24

The physical link is alive.

The endpoint did not receive expected site configuration.

That moves the investigation to DHCP and address acquisition.

Useful questions include:

• Is DHCP enabled on the client?
• Do other clients on this switch or AP receive leases?
• Is the endpoint on the expected VLAN or port configuration?
• Are DHCP requests and replies reaching the client in the supplied evidence?

Weak move:

Change DNS to 8.8.8.8.

DNS does not assign the missing address and gateway.

Robotnix DHCP diagnosis simulation
No real adapter, DHCP server, or network is connected. Type 'help' for supported commands.

$ ipconfig
Ethernet adapter Ethernet:
   Autoconfiguration IPv4 Address. : 169.254.44.21
   Subnet Mask . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . :

$ ipconfig /all
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . . : Yes
IPv4 Address. . . . . . . . . . . : 169.254.44.21
DHCP Server . . . . . . . . . . . : unavailable

$ ping 192.168.10.1
PING: transmit failed. General failure.
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)

$ ipconfig /renew
Windows IP Configuration
DHCP lease obtained from simulated SOHO router.

$ ipconfig
Ethernet adapter Ethernet:
   IPv4 Address. . . . . . . . . . : 192.168.10.25
   Subnet Mask . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . : 192.168.10.1

Case 3: local works, gateway fails

Evidence:

same-subnet printer: reachable
same-subnet PC: reachable
default gateway: unreachable

What has already been proven?

• endpoint interface works enough for local traffic;
• physical or wireless link works;
• local switching or AP path works;
• local IP configuration is plausible enough for same-subnet communication.

That makes a total NIC or switch failure much less likely.

Focus near the gateway address or configuration, router LAN interface, local path to the router, or policy when applicable.

Positive evidence is narrowing the map.

Case 4: wrong gateway

Endpoint configuration:

IP:      192.168.40.25/24
Gateway: 192.168.50.1

Same-subnet devices may still work because they do not need the default gateway to reach one another.

Remote traffic fails because the configured next hop is not valid for the local design.

This is a configuration problem with a specific symptom pattern.

Case 5: duplicate IPv4 address

Two endpoints are manually configured with the same IPv4 address.

Possible symptoms include:

• intermittent connectivity;
• traffic reaching the wrong device;
• address-conflict warnings;
• behavior changing as local neighbor state changes.

Rebooting until one device happens to work is not a fix.

Correct the address plan and verify uniqueness.

The root problem is that two endpoints are claiming the same logical identity on the local network.

Case 6: Wi-Fi associated, but no valid IP

Evidence:

SSID: connected
signal: strong
IPv4: APIPA
other wireless clients: normal DHCP

The radio and AP association work.

The failure is higher, around client address acquisition or a client-specific network configuration.

"Wi-Fi connected" and "usable IP network configuration" are different states.

Case 7: local network works, provider edge fails

Evidence:

local printer: reachable
router LAN interface: reachable
router WAN/provider state: down

The entire internal network is not broken.

The failure lies at or beyond the provider-facing side of the router.

That matters operationally because the repair owner may change. A local technician can verify the inside network and provider handoff state without pretending they control the external provider network.

Build two service records

Choose two different cases and preserve:

user-visible symptom
physical / radio evidence
IP configuration evidence
same-subnet evidence
gateway evidence
last proven-good boundary
first failed or uncertain boundary
strongest theory
controlled next test
result
verification
one layer not yet tested

Do not skip the last line.

If you have only proven the gateway responds, you have not yet proven DNS or a web application works.

Defend the path

Use your SOHO diagram and point to each boundary while explaining:

media / radio
→ NIC
→ switch / AP
→ valid local IP configuration
→ local destination
→ gateway
→ remote network

For each arrow, name one piece of evidence that could prove that stage.

This turns the network diagram from decoration into a troubleshooting tool.

What Week 7 should change in your head

A network outage is rarely one giant state called "offline."

It is a path with boundaries that can fail independently.

The useful technician question is not:

Why is the internet broken?

It is:

How far can this endpoint communicate, and what is the first thing it cannot prove?

Next week we go higher in the stack into DHCP, DNS, ports, transport, Wi-Fi standards, VPNs, and the services that make an IP network actually useful.