Prefix
The slash number, such as /24 or /26, says how many address bits belong to the network part.
10 Subnetting and CIDR for IoT Networks
networking-core
addr
subnetting
10.1 Start With the Boundary Line
Subnetting is the moment an address becomes a design decision. The mask draws a boundary around who can talk directly, who needs a router, how broadcasts are contained, and how much room remains for devices.
For an IoT network, that boundary affects commissioning, service discovery, firewall rules, and future growth. The arithmetic matters because the deployment will inherit every boundary the design creates.
Overview: A Subnet Is an Address Boundary
Subnetting divides one IP address space into smaller segments. In an IoT network, those segments are not just arithmetic. They become security, broadcast, troubleshooting, and ownership boundaries for device families, floors, buildings, gateways, labs, or operational zones.
The boundary decides the first routing question every host asks: is this destination local, or should traffic go to the gateway? If the prefix is wrong, a sensor can ARP for a server that is actually remote, send remote traffic to the wrong gateway, or appear healthy on link status while application traffic never leaves the local segment. That is why subnetting belongs in the deployment record, not only in a design diagram.
Host space
The remaining bits create host addresses inside the subnet. For ordinary IPv4 host subnets, network and broadcast addresses are reserved.
Boundary
The subnet boundary helps limit broadcast scope, separate device groups, and make routing and policy easier to review.
Planning risk
A subnet that fits the device count but ignores gateways, infrastructure, spare addresses, and future joins can fail during rollout.
Useful Mental Model
Pick a subnet because it matches a responsibility boundary. Then verify that its usable host count, gateway placement, DHCP scope, route summary, and security policy match the devices that will live there.
Good IoT subnets make evidence easier to read. A camera subnet can be monitored for video-bandwidth behavior, a lighting subnet can be tied to building-control policy, and a maintenance subnet can have a different firewall path from unmanaged sensors. If all device classes share one flat subnet, every incident starts with mixed ownership, broad broadcast scope, and harder proof of which traffic should have been allowed.
Practitioner: Build the Subnet Plan From Inventory
A defensible subnet plan starts with inventory, not with a favorite prefix. Count endpoint devices, gateways, controllers, management interfaces, DHCP reservations, static infrastructure, lab equipment, spare addresses, and expected growth. Then choose the smallest prefix that satisfies the boundary without forcing premature renumbering.
Capacity is only one part of the review. The selected prefix must also fit the DHCP pool, static reservations, gateway address, monitoring labels, firewall objects, and route summaries used by operations. A subnet that has enough usable addresses can still be a bad design if it splits one ownership domain across many unrelated routes or combines device groups that need different incident response rules.
Planning field
What to record
Review question
Boundary purpose
Device family, floor, building, trust zone, lab, gateway domain, or operational owner.
Does one subnet represent one reviewable responsibility?
Address demand
Endpoints, infrastructure, static addresses, DHCP scope, reservations, and spare capacity.
Does usable capacity exceed the real count, not just the sensor count?
Routing and policy
Gateway, VLAN or segment, route summary, firewall policy, and monitoring scope.
Can operators explain where traffic should and should not flow?
Change trigger
Growth, relocation, new device class, new owner, new security zone, or route-summary pressure.
When does the address plan need to be reopened?
Planning Sequence
- Group devices by operating responsibility and security policy.
- Count endpoints plus gateways, controllers, reservations, and static infrastructure.
- Add a documented growth allowance instead of silently filling the subnet.
- Choose a prefix whose usable host count fits the record.
- Verify route summaries, DHCP scopes, firewall rules, monitoring labels, and support notes.
Common Review Failure
A plan that says "use /24 everywhere" may be easy to remember, but it can waste address space in small zones and underfit dense zones. Use a consistent rule only after checking the actual device and operations record.
Before rollout, test one representative device path per subnet: DHCP or static assignment, gateway reachability, DNS or broker resolution, allowed application service, blocked management service, and monitoring visibility. Keep the result with the subnet record so a later device failure can be compared against a known-good baseline instead of rediscovering the network design from scratch.
Under the Hood: Prefix Bits Define the Address Budget
CIDR notation makes subnet sizing precise. In IPv4, a /24 prefix leaves 8 host bits, a /26 leaves 6 host bits, and a /28 leaves 4 host bits. For ordinary host subnets, usable host count is the total address count minus the network and broadcast addresses.
The arithmetic comes from binary boundaries. A /26 means the first 26 bits are fixed as the network prefix and the remaining 6 bits vary for hosts. Those 6 host bits create 64 possible bit patterns. The all-zero host pattern names the subnet itself, and the all-one host pattern is the directed broadcast address for that subnet, leaving 62 ordinary usable host addresses.
Keep directed broadcast and limited broadcast separate in troubleshooting notes. A directed broadcast names all hosts in one specific subnet, such as the all-one host pattern inside that prefix. The limited broadcast address 255.255.255.255 is local to the sender's current link and should not be routed beyond the gateway.
Address count
Total IPv4 addresses in a subnet equal 2^(32 - prefix length).
Usable host count
For ordinary host subnets, subtract network and broadcast addresses from the total.
VLSM
Use different prefix lengths for different zones when their device counts and growth records differ.
Route summary
Keep contiguous blocks when possible so routers and operators can summarize related zones cleanly.
Worked Reasoning Pattern
For 192.168.10.45/26, the /26 prefix leaves 6 host bits. The block size in the last octet is 64, so addresses 192.168.10.0 through 192.168.10.63 are in the same subnet. The network address is 192.168.10.0, the broadcast address is 192.168.10.63, and ordinary usable host addresses run from 192.168.10.1 through 192.168.10.62.
Variable-length subnet masking works because each subnet still lands on a binary boundary. A /26 block uses increments of 64 in the last octet, a /27 uses increments of 32, and a /28 uses increments of 16. If two proposed subnets overlap those ranges, routing and DHCP records can point different devices at the same address space. If related subnets stay contiguous, a router can often advertise one shorter summary route while operators still keep smaller local policy zones.
The under-the-hood risk is confusing usable host count with deployment capacity. Gateways, static infrastructure, reservations, telemetry gateways, controller interfaces, maintenance laptops, and spare addresses all consume space or policy attention. The capacity calculation should therefore end with a reviewable statement: prefix length, total addresses, usable hosts, counted demand, spare margin, route summary, and the trigger for reopening the plan.
10.2 Summary
- Subnetting divides IP space into reviewable operational boundaries.
- CIDR prefix length determines how many host bits remain and therefore how many addresses are available.
- A subnet plan should count endpoints, gateways, infrastructure, DHCP reservations, static addresses, and spare capacity.
- VLSM lets different IoT zones use different subnet sizes when device counts and growth records differ.
- A defensible subnet design includes route summaries, gateway placement, security policy, monitoring scope, and recheck triggers.
10.3 Key Takeaway
Choose subnet sizes from the deployment record, not from habit. A good IoT subnet plan makes address capacity, policy boundaries, routing, and support ownership visible before devices are installed.
10.4 See Also
- IPv4 Addressing Fundamentals - address structure, host bits, and route context.
- IPv6 Addressing - how IPv6 changes address planning and prefix review.
- DHCP and Address Resolution - dynamic assignment and local resolution evidence.
- Port Numbers and NAT - how address plans interact with translation and service exposure.