12 Subnetting and CIDR for IoT Networks

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.

Before sizing device groups, inspect Figure 12.1 to see what the prefix actually divides. The diagram turns slash notation into the local-delivery boundary every host applies before choosing direct resolution or a gateway.

+

Read Figure 12.1 from the most significant network bits into the remaining host bits. Addresses with the same reviewed prefix are treated as local; other destinations use the configured gateway. Extending the prefix creates more, smaller subnets while reducing host space. That relationship connects the arithmetic to broadcast scope, routing policy, DHCP capacity, and the failure clues a deployment will expose.

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.

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.

Read Figure 12.2 down its rows, because the subnet size is the last decision, not the first.

+

Four device families run across the table. The reason for splitting them is on the second row, and it is different every time: cameras for bandwidth, HVAC for control safety, access control for security, and environmental sensors because they are low-rate. Only then do the prefixes appear. Cameras and HVAC take a /26 each, while access and environmental take a /27, which is half the size. The bottom row shows why this holds up in operations. Each subnet also carries one policy, such as video only, BMS only, or the MQTT broker. Figure 12.2 sizes by ownership first and by host count second.

Planning Sequence

Begin by grouping devices according to operating responsibility and security policy. Count endpoints together with gateways, controllers, reservations, and static infrastructure, then add a documented growth allowance instead of silently filling the subnet. Choose a prefix whose usable host count fits that record. Finally, verify the resulting route summaries, DHCP scopes, firewall rules, monitoring labels, and support notes.

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.

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.

Read the host counts in Figure 12.3 to see how fast address space disappears as a prefix grows.

+

The prefixes run from /24 to /30 across the table. Under each one is the usable host count, and it halves at every step: 254, then 126, 62, 30, 14, and finally 2. The bottom row gives each size a job. A /24 suits a floor LAN, a /26 a camera group, a /28 a small cluster, and a /30 exists for a router-to-router link where only two addresses are ever needed. So Figure 12.3 is a budget, not a rule. Each extra prefix bit buys another subnet and charges you half the hosts in it.

Read Figure 12.4 for a budgeting question: what happens when one block is cut into pieces of different sizes instead of equal ones.

+

Begin at the single parent block across the top of Figure 12.4 and the count of addresses it holds. Everything below is spent from that one total. The next row shows the cut, and the pieces are deliberately unequal: the two largest device groups take a quarter of the block each, while the smallest take a sixteenth. Read those sizes against the group names beneath them and the rule becomes concrete. Prefix length is chosen from the device count, not from a habit of splitting evenly. The two slices at the end deserve a look, because one is held for growth and one is held back entirely. A block allocated with no spare is a block that will be renumbered later.

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.