IP addressing and subnetting

Why it matters

Every cloud network starts with someone picking a CIDR block, and that choice is surprisingly hard to change later. Pick too small and the cluster cannot scale; overlap with another network and you can never peer them; misread a mask and two services cannot reach each other. Subnetting is also the logic every host runs on every packet: "is this destination on my network, or do I send it to the router?" A few minutes of binary arithmetic prevents a class of outages that otherwise take days to untangle.

The idea

An IPv4 address is 32 bits, written as four decimal bytes: 10.20.30.40. It splits into a network prefix (which network) and a host part (which machine on it). The split is given by the prefix length in CIDR notation: 10.20.30.0/24 means the first 24 bits are the network and the last 8 identify hosts. The same thing as a mask is 255.255.255.0.

Sizing in one table

Local or remote?

A host knows its own address and prefix. To send a packet, it ANDs the destination with its mask and compares the result with its own network. If they match, the destination is on the same link and the host ARPs for it directly. If not, it sends the packet to its default gateway (the router), which forwards it on. A wrong mask makes a host think a remote machine is local (it ARPs and gets no answer) or a local machine is remote (traffic detours through the router), and both look like flaky connectivity.

1. 1

   Host 10.20.30.40/24 sends to 10.20.30.99

   Masked with /24, both give 10.20.30.0: same subnet. ARP for 10.20.30.99 and send directly.
2. 2

   Host 10.20.30.40/24 sends to 10.20.31.5

   10.20.31.0 differs from 10.20.30.0: different subnet. Send the frame to the gateway's MAC.
3. 3

   Same host with a mistaken /16 mask sends to 10.20.31.5

   It now believes 10.20.31.5 is local, ARPs for it, gets no answer, and the connection fails, even though routing is fine.

Splitting a block

Subnetting borrows host bits to make more, smaller networks. A 10.0.0.0/16 VPC can be cut into 16 subnets of /20 (4,096 addresses each): 10.0.0.0/20, 10.0.16.0/20, 10.0.32.0/20 and so on, each starting on a multiple of its size. A sensible cloud layout gives each availability zone a public and a private subnet, sized for the largest thing that will live there (Kubernetes pods often get their own IP each, which consumes addresses fast), and leaves unused space for growth.

Private ranges and planning

Three ranges are reserved for private networks and never routed on the internet: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. Most VPCs, offices and home networks use them, which is exactly why overlaps happen: two companies merging, a VPC peering request, a VPN to a partner, and both sides used 10.0.0.0/16. Overlapping ranges cannot be routed between without NAT tricks. Planning rules: allocate non-overlapping blocks per environment and region from one central plan, size for pods and future growth, and record it.

Trade-offs

Large blocks give room to grow and waste address space you might need elsewhere; small blocks conserve space and risk exhaustion that forces painful re-addressing. Many small subnets give isolation and finer security boundaries at the cost of more routing entries and planning. IPv4's 4.3 billion addresses ran out globally years ago, which is why private ranges plus NAT dominate and why IPv6, later in this module, exists.

In an interview

Show the arithmetic briefly: "The VPC is a /16 from our central plan, split into three /20 private subnets, one per zone, for nodes and pods, plus three /24 public subnets for load balancers. At about 30 pods per node, a /20 holds roughly 130 nodes per zone, which is our ceiling with headroom." That combination of sizing and non-overlap is what interviewers listen for.