0.3 Networking basics for cloud work

What this is and why it exists

Nearly every cloud problem that looks mysterious is a networking problem in a costume: a firewall rule that never allowed the port, a DNS record still cached, a database in another region adding milliseconds to every query. You do not need a networking qualification. You need to narrate what happens between typing a URL and the page arriving, because that narration is also the fault-finding order.

The vocabulary

• IP address — a machine's address on a network: four numbers for IPv4 (203.0.113.10), eight hex groups for IPv6.
• Subnet — a block of addresses treated as one network, so the machines in it can share rules.
• CIDR notation — how a block is written: an address, a slash, and the number of fixed leading bits, as in 10.0.0.0/16.
• DNS — the system turning a name people remember into an address a machine can use.
• Record — one answer in DNS: A holds an IPv4 address, AAAA an IPv6 address, CNAME an alias to another name, MX the mail servers for a domain.
• TTL (time to live) — how many seconds a resolver may keep an answer before asking again.
• Port — the number saying which program on a machine a connection is for; 80 is HTTP, 443 is HTTPS, 22 is SSH.
• Latency — how long one round trip takes, in milliseconds.
• Bandwidth — how much data fits through per second.

The mental model

Read a CIDR block as "how much of this address is fixed". In 10.0.0.0/16 the first sixteen bits are fixed and the rest varies, so the whole of 10.0.x.y is inside it; /24 fixes twenty-four bits, so 10.0.5.0/24 runs from 10.0.5.0 to 10.0.5.255. The bigger the number after the slash, the smaller the block: /24 is a street, /16 a district. Every cloud network you build later is a /16-ish block chopped into /24-ish subnets, so this habit pays for itself in module four.

DNS is a cache hierarchy, not a database you edit. Your machine asks a resolver, the resolver works down from the root to whoever is authoritative, and the answer comes back stamped with a TTL that every resolver along the way may honour. That is the whole truth behind "DNS propagation", which is a myth in the form people mean it: nothing propagates and nothing is pushed — old answers expire. So lower the TTL a day before a change, not after. After is too late, because the old TTL is already out there governing the copies.

A page arriving is five acts, and knowing them in order is knowing where to look. The name resolves. TCP opens a connection to a port, costing a round trip. TLS negotiates encryption, costing at least one more. HTTP carries the request and the response. Then the browser repeats it all for every asset the page names. Each act has its own failure: name not resolving, connection refused or timing out, certificate rejected, a status in the 400s or 500s.

Then physics, which no budget removes. Light in glass travels at about two-thirds of its speed in vacuum, roughly two hundred thousand kilometres per second, so a thousand kilometres of fibre costs about five milliseconds each way and ten for the round trip — before any router touches it. Bandwidth behaves differently: you can buy more of it, and it does nothing for an application making forty sequential round trips. The design lesson lives here — put things that talk to each other in the same region, and reduce the number of round trips before you widen the pipe.

Portable operations

Three tools, one per act of the story. Checked against the Linux man-pages, the ISC BIND manual and the curl reference.

ping -c 4 203.0.113.10
dig example.com
dig example.com A +short
dig example.com MX
curl -I example.com
curl -I -L example.com

ping "uses the ICMP protocol's mandatory ECHO_REQUEST datagram to elicit an ICMP ECHO_RESPONSE from a host or gateway", and -c stops "after sending count ECHO_REQUEST packets". The times it prints are your latency floor. A silent ping is not proof of a dead machine — many clouds refuse ICMP by default — so treat it as evidence, not verdict.

For dig, the type argument "specifies what kind of query is needed — ANY, A, MX, SIG, etc."; with no type it performs "a lookup for an A record". +short gives "a terse answer" — the address alone. Read the full form when a change is not appearing: it shows the TTL counting down, which is how long the stale answer has left.

Given a bare host name, the curl manual says it "guesses what protocol you want. It then defaults to HTTP", so the first curl line asks the plain-HTTP door what it says. -I fetches "the headers only" using the HTTP HEAD method, and -L follows redirects, so the second line walks the chain from the plain address to the secure one and prints every step. Between them you learn the status code, whether plain HTTP hands off to HTTPS as it should, and which server answered — three facts that separate "my code is broken" from "my request never arrived".

What you should now be able to explain or do

Read 10.0.5.0/24 aloud and say how many addresses it holds and which. Explain why lowering a TTL after the change does not help. Narrate the five acts between a typed URL and a rendered page, naming the failure that belongs to each. Estimate the unavoidable round-trip cost of a two-thousand-kilometre hop. Use ping, dig and curl to decide in under a minute whether a broken site is a name problem, a reachability problem or an application problem.

Check yourself