Skip to content
Networking
Lab 1 of 7·25mBeginner

Read a machine's network configuration

Answer the four questions every network problem starts with — what are my addresses, what is my route out, who is my resolver, and what is listening.

You need

  • A Linux system with iproute2 (any modern distro)

ifconfig has been deprecated for over a decade. The replacement is ip, and four of its subcommands answer almost every question you will have about a box's place on the network.

1. Your interfaces and addresses

ip -brief link
ip -brief address
ip address show

-brief gives one line per interface, which is what you want when scanning. Read the full output once to see what it is summarising:

  • lo is loopback, always 127.0.0.1/8, never leaves the machine
  • eth0 / ens5 / enp0s3 is a real interface with a MAC and usually one IPv4
  • state UP means the link is up; state DOWN means nothing will work regardless of addressing

The /24 after the address is the prefix length, and it is what tells the kernel which addresses are local versus routed. The next lab is entirely about that number.

Verify

ip -brief address | grep -c UP # 2 or more — at least loopback and one real interface

2. MAC versus IP, and why both exist

ip link show
ip neighbour show

A MAC address identifies a card on a local segment; an IP address identifies a host on the internet. Delivering a packet to a neighbour needs both — the IP to decide _who_, the MAC to actually put bytes on the wire.

ip neighbour is the ARP table: the mapping the kernel has learned between the two. An entry stuck in FAILED for a host you believe exists means the address is not on your segment, or nothing is answering there.

Verify

ip neighbour show | head -n 3 # zero or more entries; each pairs an IP with a lladdr

3. Your route out

ip route show
ip route show default
ip route get 1.1.1.1
ip route get 127.0.0.1

The routing table is read most-specific-first. A default via <gateway> line is the catch-all for everything not matched by a more specific route.

ip route get is the question worth asking: given this destination, what does the kernel actually decide? It prints the interface, the gateway, and the source address it would use. Reasoning about longest-prefix matches by hand is how you get it wrong.

Verify

ip route get 1.1.1.1 | head -n 1 # 1.1.1.1 via <gateway> dev <iface> src <your address>

4. Your resolver

resolvectl status 2>/dev/null | head -n 20 || cat /etc/resolv.conf
cat /etc/resolv.conf
cat /etc/nsswitch.conf | grep hosts

Three files, three different jobs, and confusing them causes a specific class of bug.

/etc/resolv.conf names the DNS servers. On a systemd-resolved system it usually points at 127.0.0.53, a local stub — so the real upstream servers are in resolvectl status, not in the file.

/etc/nsswitch.conf's hosts: line is the _order_ of resolution methods: typically files dns, meaning /etc/hosts is consulted before DNS. That is why an entry in /etc/hosts beats a correct DNS record, and why dig and your application can disagree.

Verify

grep "^hosts:" /etc/nsswitch.conf # hosts: files dns (possibly with resolve/myhostname too)

5. What is listening, and on which address

sudo ss -tlnp
sudo ss -ulnp
sudo ss -tnp state established | head -n 5

-t TCP, -u UDP, -l listening, -n numeric (no name lookups, so it never hangs), -p the owning process.

Read the Local Address column carefully — it is the single most misread field in networking:

Local AddressReachable from
127.0.0.1:Xthis machine only
0.0.0.0:Xany IPv4 address on this machine
[::]:Xany IPv6 address, often IPv4 too
10.0.0.5:Xonly via that specific address

A service on 127.0.0.1 that you are trying to reach from another host will never work, and no firewall change will fix it.

Verify

sudo ss -tln | tail -n +2 | wc -l # 1 or more listening TCP sockets

The four questions

  1. ip -brief address — what are my addresses, and is the link up
  2. ip route get <dest> — how would I reach that
  3. resolvectl status — who resolves names for me
  4. ss -tlnp — what is listening, and on which address

Where this goes next

You can read a machine's configuration. The next lab is the one number in it that decides everything else: the prefix length.