IP Addressing & Subnetting — What You Actually Need to Know
Before you can touch a single firewall rule, debug a routing problem, or deploy anything to the cloud, you need to speak the language of IP addresses fluently. Not memorise-and-forget fluently — genuinely understand it so you can think through problems you’ve never seen before.
This is the stuff I avoided for too long because it looked like pure maths. It isn’t. Once the mental model clicks, it becomes one of the most satisfying parts of networking. Let’s go through it properly.
The Subnet Mask — What /24, /25, and /16 Actually Mean
CIDR notation (the /number after an IP address) tells you how many bits of the address are the network portion and how many are available for hosts.
An IPv4 address is 32 bits total. That’s it. Every subnet calculation comes down to splitting those 32 bits.
| CIDR | Network Bits | Host Bits | Total Addresses | Usable Hosts |
|---|---|---|---|---|
| /16 | 16 | 16 | 65,536 | 65,534 |
| /24 | 24 | 8 | 256 | 254 |
| /25 | 25 | 7 | 128 | 126 |
Why “usable hosts” instead of total addresses? Because every subnet reserves two addresses: the network address (first IP — identifies the subnet itself) and the broadcast address (last IP — used to send a message to all devices on the subnet). You can never assign those two to a machine.
So a /24 gives you 256 total, but you live in the 254 in the middle. A /25 is exactly half of that — you’ve sliced the subnet in two. A /16 is massive: useful for large internal networks or cloud VPCs where you need thousands of addresses with room to grow.
The key intuition: every time the prefix number increases by 1, you cut the available addresses in half.
Working Through a Real Subnet: 192.168.10.45/26
A /26 means 26 bits are network, 6 bits are host. That gives us 2⁶ = 64 total addresses, 62 usable.
To find the network address, you mask the IP against the subnet:
The /26 subnet mask in decimal is 255.255.255.192. In binary, the last octet is 11000000 — meaning the block size is 64.
The subnets within the 192.168.10.x range for /26 are:
192.168.10.0→.63192.168.10.64→.127192.168.10.128→.191192.168.10.192→.255
Since 45 falls in the first block (0–63):
- Network address:
192.168.10.0 - Broadcast address:
192.168.10.63 - Valid host range:
192.168.10.1—192.168.10.62
So the machine at .45 is valid — it’s a host, not a network or broadcast address. That’s your check.
I’d recommend practising this a few times with different IPs until you can find the block boundaries without hesitation. This exact calculation comes up in AWS VPC subnet design, security group rules, and firewall ACLs constantly.
What is CIDR and Why Did It Replace the Old System?
Before CIDR (Classless Inter-Domain Routing), IPv4 addresses were divided into rigid classes:
- Class A:
1.0.0.0–126.255.255.255→ /8, up to 16 million hosts per network - Class B:
128.0.0.0–191.255.255.255→ /16, up to 65,534 hosts - Class C:
192.0.0.0–223.255.255.255→ /24, up to 254 hosts
The problem was catastrophic waste. A company that needed 500 addresses would get a Class B (65,534 addresses) because there was no Class between C and B. That company would burn through 65,000 addresses it would never use — while the global address pool shrank.
CIDR, introduced in 1993, threw out the class system entirely. Now you can have /22, /27, /29 — whatever fits your actual need. CIDR also made route aggregation (also called supernetting) possible, which dramatically reduced the size of routing tables across the internet. Routers could now represent many small networks as a single larger block, instead of carrying a separate entry for each one.
The slash notation you use every single day is CIDR. It’s not a decoration — it’s the whole mechanism.
Public vs. Private IP Addresses
Not all IP addresses are the same type. The internet runs on public IPs — routable, globally unique addresses that anyone on the internet can reach. Your ISP assigns you one.
Private IPs are different. They’re reserved for internal networks — your home router, your company LAN, your cloud VPC. They’re not routed across the public internet directly. Three ranges are reserved for private use (RFC 1918):
| Range | CIDR Block | Common Use |
|---|---|---|
10.0.0.0 – 10.255.255.255 | 10.0.0.0/8 | Large private networks, cloud VPCs |
172.16.0.0 – 172.31.255.255 | 172.16.0.0/12 | Mid-size networks |
192.168.0.0 – 192.168.255.255 | 192.168.0.0/16 | Home and small office networks |
The reason private addresses work at scale is because of NAT (covered below). Millions of home networks can all use 192.168.1.x without conflicting, because they’re never exposed directly to the internet — they all sit behind NAT.
In cloud environments like AWS, your VPC uses private IP space internally. Your EC2 instances get private IPs. Traffic leaving to the internet goes through a NAT Gateway or Internet Gateway that handles the translation.
Loopback — Talking to Yourself
The loopback address is a special IP address your machine uses to talk to itself. The entire 127.0.0.0/8 range is reserved for this, but in practice you’ll always see 127.0.0.1. In IPv6 it’s ::1.
When you run a local web server and open http://127.0.0.1 or http://localhost in your browser, you’re using loopback. The packet never leaves your machine’s network stack — no physical interface, no cable, no router is involved.
Why does this matter in production work?
- MySQL by default only binds to
127.0.0.1— it won’t accept remote connections until you explicitly change this. That’s intentional security behaviour. - nginx proxying to PHP-FPM often uses
127.0.0.1:9000— the request loops back internally within the same machine. - Testing services locally — you can start a service and curl
127.0.0.1:<port>to verify it’s listening before you worry about firewall rules.
On my own server (limonlab.online), the nginx → PHP-FPM communication happens over loopback. It’s not glamorous, but it’s running production traffic every day.
The 169.254.x.x Address — Something Went Wrong
If you see a machine with an address in the 169.254.0.0/16 range, that’s a red flag. This is an APIPA address — Automatic Private IP Addressing — and it means the machine tried to get an IP from a DHCP server and failed.
The sequence is:
- Machine boots, broadcasts a DHCP request looking for an IP
- No DHCP server responds (server is down, network cable isn’t connected, VLAN misconfiguration, etc.)
- The OS self-assigns a random address in
169.254.x.xso the network interface has something — mostly to allow local link communication
An APIPA address means the machine has no real network access. It can potentially talk to other machines on the same segment that also got APIPA addresses, but it can’t reach the router, the internet, DNS, or anything useful.
In a cloud environment, this is especially significant. AWS uses 169.254.169.254 as the EC2 Instance Metadata Service (IMDS) endpoint — an intentional use of the link-local range that’s always accessible from within an instance to retrieve instance metadata, IAM credentials, and user data. You’ll use this constantly when working with EC2.
So when you see 169.254.x.x:
- On a physical machine: DHCP failure, check your network
- On an EC2 instance as destination: That’s IMDS — expected and useful
IPv6 — Why It Exists and What ::1 Means
IPv4 gives us about 4.3 billion addresses. That sounds like a lot until you remember there are 8 billion people on the planet, plus every server, router, IoT device, phone, and cloud resource competing for addresses. We ran out. IPv4 exhaustion is not a future concern — regional internet registries depleted their pools over a decade ago.
IPv6 was designed to fix this permanently. It uses 128-bit addresses instead of 32-bit, which produces approximately 340 undecillion addresses (3.4 × 10³⁸). That’s enough to give every grain of sand on Earth its own IP address with addresses to spare.
An IPv6 address looks like this: 2001:0db8:85a3:0000:0000:8a2e:0370:7334
Eight groups of four hex digits, separated by colons. Leading zeros in each group can be omitted, and one continuous run of all-zero groups can be replaced with ::.
So 2001:0db8:0000:0000:0000:0000:0000:0001 becomes 2001:db8::1.
::1 is the IPv6 loopback address — the exact equivalent of 127.0.0.1 in IPv4. It’s as short as it gets: all 128 bits are zero except the last one.
From a practical standpoint as a junior cloud/DevOps engineer: you don’t need to be an IPv6 expert yet, but you should recognise IPv6 addresses, understand that ::1 is loopback, and know that AWS, GCP, and Azure all support dual-stack networking (IPv4 and IPv6 simultaneously). As IPv4 address costs rise in cloud environments, IPv6 awareness is becoming genuinely useful.
NAT — How Private Networks Talk to the Internet
Here’s the core problem NAT solves: your machine has a private IP like 192.168.1.100. The internet doesn’t know how to route back to that address, because millions of other machines also have 192.168.1.100. How does your request ever get a response?
Network Address Translation (NAT) sits at the edge of your network — typically your router at home, or a NAT Gateway in AWS — and handles the translation between private and public IP addresses.
Here’s what happens when you open a website from your home network:
Your machine → Router (NAT) → Internet
192.168.1.100:52341 Public IP: 82.45.12.7 Website server
NAT translates source to
82.45.12.7:52341 before sending
The router keeps a NAT table mapping each outbound connection:
| Private IP | Private Port | Public IP | Public Port |
|---|---|---|---|
| 192.168.1.100 | 52341 | 82.45.12.7 | 52341 |
| 192.168.1.105 | 48920 | 82.45.12.7 | 48920 |
When the response comes back to 82.45.12.7:52341, the router checks the table, translates it back to 192.168.1.100:52341, and delivers it to the right machine. Multiple machines share one public IP through different port numbers.
Why this matters in cloud environments:
In AWS, your EC2 instances in a private subnet have no direct path to the internet. To give them outbound internet access (for downloading packages, calling external APIs, etc.) without exposing them to inbound connections, you place a NAT Gateway in a public subnet. The instances route through it for outbound traffic — the NAT Gateway translates their private IPs to its own public Elastic IP, and returns the responses. Inbound traffic from the internet can’t initiate a connection to the private instance because there’s no inbound NAT mapping.
This is a core AWS architecture pattern. Private subnet + NAT Gateway = instances can reach out, but can’t be directly reached from outside. You’ll implement this in almost every real AWS project.
What to Take Away From This
These aren’t trivia. Every concept in this post maps directly to something you’ll do in the real world:
- Subnet calculation → designing VPC CIDR blocks and subnets in AWS
- Public vs private IPs → understanding why your EC2 instance has two addresses
169.254.x.x→ troubleshooting DHCP failures and understanding IMDS- NAT → explaining why instances in private subnets need a NAT Gateway to download packages
- Loopback → debugging why a local service isn’t responding or why MySQL won’t accept remote connections
Get these concepts solid. The rest of networking builds directly on top of them.
This post is part of my Linux Mastery Road to Cloud series — documenting every domain from scratch as I work toward a cloud/DevOps engineering role. All examples run on my live home server at limonlab.online.