IP Addresses, CIDR and Routing

Why this matters

A service moves to a new subnet and half its callers fail. The application did not change, DNS did not change, and the firewall team insists nothing changed. What changed is the longest-prefix match: packets that used to fall through to a default gateway now match a more specific route that points nowhere. Engineers who read routing tables solve this in minutes; everyone else reboots machines and reopens the same ticket.

Concepts

An IPv4 address is 32 bits, and CIDR notation says how many of them identify the network. In 10.20.5.0/24 the first 24 bits are the network and the last 8 are hosts: 256 addresses from 10.20.5.0 to 10.20.5.255, with .0 as the network identity and .255 as broadcast, leaving 254 usable. A /26 halves that twice more down to 62 usable hosts. The prefix length is the whole game: a /24 and a /25 on the same wire overlap, and overlapping subnets are how packets get answered by the wrong machine.

The routing table answers one question per packet: through which interface, via which gateway. Read it with ip route: each line is destination, device and next hop, and the kernel picks the longest matching prefix, falling back to default. Two routes to the same place mean the more specific wins, always. On the machine itself, ip addr shows which addresses live on which interfaces; a service bound to 127.0.0.1 answers localhost only, and no firewall rule will ever make it reachable from outside, because the packet never leaves the loopback.

The classic split: correct address, wrong route (packets leave through the wrong gateway and die), correct route, nothing listening (packets arrive and get RST, which ss -tlnp confirms in seconds), and correct everything except the mask (two hosts each believe the other is local, ARP succeeds, but return traffic routes away). Each has a different fix, and the table tells you which world you are in before you touch anything.

Worked example

App at 10.20.5.40 cannot reach a database at 10.20.6.10 that moved subnets:

$ ip route show default via 10.20.5.1 dev eth0 10.20.5.0/24 dev eth0 scope link 10.20.0.0/16 via 10.20.5.254 dev eth0 $ ip route get 10.20.6.10 10.20.6.10 via 10.20.5.254 dev eth0 src 10.20.5.40

Expected reading: no direct /24 covers .6.x, the /16 via .5.254 matches, so packets leave toward the old interconnect gateway. If that gateway no longer routes to the database's new subnet, every connection times out while DNS, ports and credentials all look healthy. The fix is a route, not a restart: a correct more-specific entry or a corrected gateway, verified with ip route get before and after. Note what was not touched: the application, its config and the database.

The common wrong move

Disabling the firewall first. When the problem is addressing or routing, the firewall was never in the path, and the test teaches nothing except that the team now runs without a firewall while debugging. Firewalls get their turn in a fixed order: address (do I have the right IP), route (does the packet leave correctly), listener (is anything there), then filter (is it blocked). Skipping to step four turns every outage into a security incident of your own making.

Lab and next step

Module labs L04-L06 each start from this table-first discipline. Next, lesson 2 adds names to numbers: how a hostname becomes an address, and every place that translation can lie.