Home Lab IP Addressing Done Right: A Sensible Plan for Your Growing Network
Most home labs begin with one small computer and good intentions. A Raspberry Pi arrives to run Pi-hole, the popular ad-blocking DNS server (DNS is the Domain Name System, the service that turns names like ipcraft.io into numbers computers can dial), and for a while that is the whole lab. Then a NAS (network-attached storage, a box of hard drives that lives on your network) shows up to hold backups, then a used mini PC for experiments, then a second Pi because the first one is busy, plus a scattering of smart plugs and bulbs that joined the Wi-Fi while nobody was paying attention. The night something breaks, you discover the problem underneath the problem: you have no idea what address anything has. Every device got its IP address (Internet Protocol, the numbering system that gives each device on a network a spot other devices can reach) from the router in whatever order it happened to show up, and the result reads like a guest list sorted by arrival time. This post is about doing home lab addressing on purpose: claiming a range that will not fight you later, deciding how each device gets its address, separating the things you trust from the things you merely tolerate, and writing all of it down somewhere that survives the next rebuild.
The chaos is the factory default doing exactly what it promised. Your router shipped configured to use 192.168.1.0/24, a small block from the address space set aside for private networks, ranges anyone may use inside their own walls without asking anyone's permission. That reservation comes from a standard called RFC 1918 (RFC stands for Request for Comments, the numbered document series where internet standards are published), and our tour of the 10 reserved IP ranges every network engineer should know walks through all of the special ranges, including this one. The slash in /24 is CIDR notation (Classless Inter-Domain Routing), which our visual guide to subnetting unpacks from scratch; for now it is enough to know that 192.168.1.0/24 means the 254 usable addresses from 192.168.1.1 through 192.168.1.254. Into that block, the router's DHCP service (Dynamic Host Configuration Protocol, the feature that hands each new device an address automatically) assigns whatever address happens to be free when a device asks. For a household that never thinks about its network, this is a genuinely good system, because its entire job is making sure nobody has to think about it. A home lab is the decision to start thinking about your network, and the first thing you notice is that nothing was placed anywhere on purpose.
Left alone, the default arrangement fails in predictable ways. DHCP addresses are leases, and leases expire, so a power outage or a router reboot can reshuffle who lives where, which matters enormously once other machines depend on finding a service at a known address. If the Pi-hole silently moves, every device still pointing at its old address loses DNS, and the internet appears to be down in a way no amount of modem-restarting will fix. The classic countermove, typing a fixed address directly into a device, plants a different landmine: pick an address inside the DHCP pool and the router will eventually hand that same address to something else, producing the duplicate-address standoff our guide to IP address conflicts teaches you to hunt down and prevent. And the default range itself turns hostile the moment you leave the house. Nearly every hotel, coffee shop, and relative's guest network also uses 192.168.1.0/24 or its twin 192.168.0.0/24, and a VPN (Virtual Private Network, an encrypted tunnel back to your own house) cannot route you home to 192.168.1.10 while the cafe you are sitting in claims the very same address, a collision our guide to VPN and overlay network addressing explains in full.
The router's DHCP lease table, eight months into the hobby
192.168.1.101 raspberrypi ← the Pi-hole, or possibly the other Pi
192.168.1.102 ESP_7F3A2C ← one of eleven smart plugs
192.168.1.103 raspberrypi ← definitely one of them
192.168.1.104 (no hostname) ← the NAS. Probably.
192.168.1.118 HS105 ← a smart plug of a different brand
192.168.1.131 raspberrypi ← wait, there are three?
192.168.1.147 DESKTOP-4KJ2N8 ← unclear whose
The fix starts with claiming better land. Private address space includes 10.0.0.0/8, a range so large it contains more than sixty-five thousand /24 blocks, and almost no consumer equipment defaults to anything in it beyond the first few. Pick a two-number prefix that pleases you, say 10.27, and take 10.27.0.0/16 as your lab's territory: 256 subnets of 254 usable addresses each, carved out of space no hotel Wi-Fi will ever occupy. The specific numbers matter far less than the act of choosing them, though it pays to steer around the popular corners, 10.0.0.0/24, 10.0.1.0/24, and 10.1.1.0/24 among them, precisely because other people's equipment loves those too. Choosing an unfashionable corner of private space is a one-time decision that quietly deletes an entire category of future headaches, including the remote-access collision above.
With territory claimed, the next decision is how each device gets its address, and there are exactly three mechanisms to choose from. A static address is typed into the device by hand and never changes. A pool address comes from DHCP automatically and may change. The compromise, and the workhorse of a well-run home lab, is the DHCP reservation: the router still hands the address out automatically, but a note in its configuration pins a specific address to a specific device's MAC address (Media Access Control, the hardware serial number burned into every network interface), so the same device always receives the same address. Our decision framework for DHCP, static, and reservations covers the trade-offs in depth, but the short version for a lab is easy to remember. Infrastructure the network needs before DHCP can even function gets static addresses: the router itself, switches, access points, and the Pi-hole, because DNS is infrastructure now. Everything you host gets a reservation: servers, the NAS, containers, cameras. Everything transient rides the pool: phones, laptops, and visitors.
The three mechanisms need to stay out of each other's way inside a subnet, which takes one minute of arithmetic and saves years of mystery. Carve each /24 into lanes that never overlap, tell the router that its DHCP pool is only one of those lanes, and the arrangement enforces itself from then on: an address you assign deliberately can never collide with one the router hands out, because they come from different lanes. The exact boundaries are yours to pick, and a carve like this one leaves room in every direction.
One /24, carved into lanes that cannot collide
10.27.10.0/24, the lab subnet
.1 to .19 static router, switches, access points, DNS
.20 to .99 reservations everything you host
.100 to .199 DHCP pool everything transient
.200 to .254 spare future experiments
Once addresses mean something, the natural next step is putting walls between the groups, and the standard tool is the VLAN (virtual LAN, where LAN is a local area network, the network inside your own building). A VLAN makes one physical switch behave like several isolated ones, so the smart gadgets, the guests, and the lab can each live in their own segment with their own subnet, unable to poke at one another. This matters most for the smart-home fleet, the IoT (Internet of Things) devices, which are famously chatty, rarely updated, and not the kind of company your backups should be keeping; it also matters for lab experiments, which should be free to fail without taking the household's internet down with them. Our guide to VLANs vs VRFs explains the mechanics from zero, and plenty of prosumer routers and modest managed switches support VLANs today. You can also skip most of the sizing agonies that our guide to how big a subnet should actually be works through for offices, because at home a /24 per segment is roomy, readable, and almost always the right answer.
| Subnet | What lives there | How addresses are assigned |
|---|---|---|
10.27.1.0/24 | Family life: laptops, phones, the TV | DHCP pool |
10.27.10.0/24 | The lab: servers, Pis, containers, the NAS | Reservations, with statics for infrastructure |
10.27.30.0/24 | Smart home: plugs, bulbs, sensors, cameras | Pool, with reservations for the cameras |
10.27.40.0/24 | Guests | Pool, isolated from everything above |
The last step is the one that separates a plan from a memory. Six months from now you will not remember why the cameras have reservations in the .30 block, and future you, squinting at an unlabeled switch at 11 p.m., is functionally a stranger inheriting an undocumented network, the exact predicament our guide to rebuilding an IP inventory from scratch was written for. Most people start with a spreadsheet, and a spreadsheet genuinely beats memory, though our post on what spreadsheet IP management actually costs explains how the tab quietly rots as reality drifts away from it. Whatever the medium, the habit is the point: when a device gets an address, the record changes in the same sitting. And if this kind of planning turns out to be the part of the hobby you enjoy, our worked example of designing an IP plan from scratch runs the identical logic at company scale, across sites, VLANs, and clouds.
This is also exactly the scale IPCraft's free plan was built for. IPAM (IP Address Management, keeping an authoritative record of which addresses are assigned to what) has historically been enterprise software, but the free plan gives you 5 folders, 100 subnets, and 1,500 tracked IP addresses, which holds a 10.27.0.0/16 home lab plan with room for every experiment on the horizon. You get the visual subnet tree, per-subnet utilization, instant search, and CSV import for whatever spreadsheet you are graduating from, with no credit card involved; the free subnet calculator is there for checking your carves before you commit them, and the paid plans keep the same records growing if the lab ever escapes the house. Creating an account takes about a minute, which is less time than you spent scrolling the lease table looking for the third Raspberry Pi.
The whole discipline compresses into four moves: claim an unfashionable corner of private space, decide on purpose how every device gets its address, wall off what you do not trust, and write down what you did. None of it requires enterprise gear, and most of it is one quiet evening with the equipment you already own. The reward arrives the next time something breaks, when you type an address from memory, land on exactly the machine you expected, and realize the network in your house finally has a map.