Sizing the Prefix From Counted Demand
Sizing the Prefix From Counted Demand
Ada re-derives this chapter’s own numbers step by step, at full precision
ADA · CALCULATION AUDIT
Sizing the Prefix From Counted Demand
The chapter’s practitioner example tallies 180 sensors, 12 infrastructure addresses, 8 reserved maintenance addresses, and 40 documented spares, then asks for a prefix with at least 240 usable hosts. A planner who sized on the 180 sensors alone would badly understate the real demand. This audit adds up every address consumer to find which prefix actually clears the counted total.
Companion to the chapter Subnetting and CIDR for IoT Networks — every number here comes from that chapter.
See the relationship before changing it
The figure reads from left to right. The blue card is counted address demand. The middle card applies this page's rule. The green card is spare addresses. Walk the arrows once: set the input, apply the rule, then read the result with its unit.
The retained audit below checks several chapter fixtures. This model keeps those stated values fixed and changes only counted address demand, so the numeric fixture does not switch without explanation.
Derive the baseline in four named moves
- 1
Name the input. The chapter baseline is 240 addresses.
- 2
Name the relationship. spares = 254 usable addresses - counted demand
- 3
Substitute with units. 254 - 240 = 14 spare addresses
- 4
Read the result. Keep the unit beside the value. Use it only inside the technical boundary on this page.
Predict, then change counted address demand
Try Predict the direction of spares = 254 usable addresses - counted demand. Test another counted address demand, then compare spare addresses.
Observe Count infrastructure and reserves as well as sensors; every extra address consumes one place in the fixed /24. Reset counted address demand to 240 and compare spare addresses.
Explain Count infrastructure and reserves as well as sensors; every extra address consumes one place in the fixed /24.
Check yourself
What should you do before trusting a moved-control result?
What does this small model leave out?
Ready: use the stated baseline inputs, then compare each displayed result.
Ada: The practitioner example counts 180 sensors, 12 infrastructure addresses, 8 reserved maintenance addresses, and 40 documented spares, then asks for a prefix whose usable capacity is “at least 240.” Let me check the demand total and see exactly which prefix clears it, using the chapter’s own rule that usable hosts equal 2^(32 - p) - 2.
The demand is the sum of every address consumer, not just the sensors:
- Counted demand:
180 + 12 + 8 + 40 = 240addresses.
Now test the prefixes against that 240:
/25:2^(32 - 25) - 2 = 2^7 - 2 = 128 - 2 = 126usable — short of 240, rejected./24:2^(32 - 24) - 2 = 2^8 - 2 = 256 - 2 = 254usable — clears 240 with254 - 240 = 14to spare.
The two subtracted addresses are the same pair the chapter derives for a /26: 6 host bits give 2^6 = 64 total, and removing the all-zeros network address and the all-ones broadcast address leaves 64 - 2 = 62 usable — the pattern that makes 192.168.10.45/26 span .0 to .63 with hosts .1 through .62.
The design meaning is that headroom must be measured against counted demand, not device count. A /24 clears 240 but leaves only 14 free addresses, so a planner who sized on the 180 sensors alone would believe there were 254 - 180 = 74 spare when only 14 remain — and the next dozen infrastructure or replacement devices would force a /23 or a disruptive renumber. The prefix is chosen from the whole record precisely so that the spare margin is real.
Every number above is taken from the chapter’s own material and re-derived step by step.