# Linux Network Inspection

## Every command below is really a question

Module 3 gave you the model. This module gives you the commands — but treat each one as
ANSWERING a specific question, not as syntax to memorize.

## "What addresses does this machine have?" — `ip addr`

```
$ ip -4 addr show eth0
inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
```

This machine's IPv4 address is `172.17.0.2`, on a `/16` subnet.

## "Where will this machine send traffic?" — `ip route`

```
$ ip route
default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2
```

The second line says: anything in `172.17.0.0/16` is reachable directly. The first line (the
`default` route) says: everything else goes through `172.17.0.1` — the default gateway from
Module 3, now a real line in a real table.

## "What TCP ports are listening?" — `ss -lnt`

```
$ ss -lnt
LISTEN  0  511  0.0.0.0:80  0.0.0.0:*
```

Something is listening on port 80, on every interface (`0.0.0.0` as a BIND address, exactly the
convention Module 3 flagged). `ss` replaced the older `netstat` on modern Linux — same idea.

## "What does DNS say this name resolves to?" — `getent hosts` / `dig`

```
$ getent hosts example.test
10.0.0.5  example.test
```

`getent hosts` checks the same resolution path the rest of the system uses (local `/etc/hosts`
entries first, then DNS) — a reliable first choice. `dig <name>` queries DNS directly and shows
more detail, useful once you specifically suspect a real DNS server issue rather than a local
override.

## "Can the application actually respond?" — `curl`

```
$ curl -sf http://localhost:80/ -o /dev/null -w '%{http_code}\n'
200
```

Everything before this point (address, route, port, DNS) can be perfect, and the APPLICATION
itself can still be broken — `curl` is the only one of these tools that actually tests the full
chain end to end, including the application's own response.

## Instructor Notes

**Lesson goal:** Convert Module 3's mental model into muscle-memory commands, each explicitly
framed as answering one specific diagnostic question.

**Approximate timing:** 15 minutes read; 10 minutes live.

**Common misconception to watch for:** treating all five commands as redundant ways to "check
the network" — reinforce that each answers a DIFFERENT layer's question, and a real diagnosis
usually needs more than one.

**Demo idea:** run all five in sequence against this Lab's own nginx, narrating which Module 3
layer each one answers.