23 Subnetting and CIDR for IoT Networks
23.2 Learning Objectives
By the end of this chapter, you will be able to:
- Interpret subnet masks: Convert between dotted-decimal and CIDR notation
- Calculate network addresses: Use binary AND operations to determine network boundaries
- Apply CIDR notation: Calculate host counts from prefix lengths
- Design IoT subnets: Plan network segmentation for security and management
- Implement VLSM: Allocate variable-sized subnets for efficient address utilization
MVU: Minimum Viable Understanding
Core concept: A subnet mask divides an IP address into network portion (identifies the segment) and host portion (identifies devices within that segment).
Why it matters: Subnetting enables security isolation, broadcast control, and logical organization of thousands of IoT devices.
Key takeaway: Plan /24 subnets (254 hosts) per floor, building, or sensor type - always include 30% growth buffer.
23.3 Prerequisites
Before diving into this chapter, you should be familiar with:
- IPv4 Addressing Fundamentals: Understanding of 32-bit address structure and binary representation
- Networking Basics: Foundation in networking concepts
For Beginners: What is Subnetting?
Subnetting is dividing a large network into smaller segments. Think of it like organizing a company: instead of one huge department with 10,000 employees, you create smaller teams (engineering, sales, HR).
Each subnet gets a range of IP addresses. For example, 192.168.1.0/24 gives you 254 usable addresses (192.168.1.1 through 192.168.1.254), perfect for a small office or building floor.
Why subnet?
- Security: Isolate cameras from HVAC from sensors
- Performance: Reduce broadcast traffic in each segment
- Management: “All cameras are in 192.168.10.x” simplifies troubleshooting
| Term | Simple Explanation |
|---|---|
| Subnet Mask | Defines which part of IP is network vs device (255.255.255.0) |
| CIDR Notation | Slash notation for subnet size (/24 = 255.255.255.0) |
| Network Address | First address in subnet, identifies the segment |
| Broadcast Address | Last address in subnet, reaches all hosts |
Sensor Squad: Dividing the Neighborhood!
“We have 1,000 sensors in this building, and they are all on one big network,” sighed Sammy the Sensor. “When anyone sends a broadcast, ALL of us have to listen. It is so noisy!” Max the Microcontroller had a plan. “Time for subnetting! We are going to divide this big network into smaller neighborhoods.”
“A subnet mask is like a fence between neighborhoods,” Lila the LED explained. “The mask 255.255.255.0 – or /24 in CIDR notation – means the first three numbers are the street name and the last number is the house. So 192.168.1.x is one neighborhood with 254 houses, and 192.168.2.x is another.”
“We will put all temperature sensors on 192.168.1.0/24, motion detectors on 192.168.2.0/24, and cameras on 192.168.3.0/24,” said Max. “Now broadcasts stay within each neighborhood instead of flooding the entire building.”
Bella the Battery was thrilled. “Fewer broadcasts means less radio noise, which means I waste less energy listening to messages that are not even for me. Plus, if a hacker gets into the camera network, they cannot easily reach the temperature sensors – the subnets create security boundaries. Always plan with a 30% buffer for future growth!”
23.4 Understanding Subnet Masks
A subnet mask determines which portion of an IP address represents the network and which represents the host. The mask is a 32-bit number where consecutive 1s represent the network portion, and 0s represent the host portion.
Alternative View: IoT Subnet Planning by Device Count
This variant shows subnet selection based on actual IoT deployment needs:
Planning tip: Always allocate at least 30% more addresses than current needs to accommodate growth. A home with 20 sensors (26 with 30% buffer) should use /27 (30 hosts), not /28 (14 hosts, which does not fit).
Alternative View: Subnet Mask Binary Visualization
This variant shows how the binary mask pattern determines network/host division:
Each borrowed bit doubles the number of subnets but halves the hosts per subnet.
Common Subnet Masks:
| CIDR | Subnet Mask | Binary | Network Bits | Host Bits | Total Hosts | Usable Hosts |
|---|---|---|---|---|---|---|
| /8 | 255.0.0.0 | 11111111.00000000… | 8 | 24 | 16,777,216 | 16,777,214 |
| /16 | 255.255.0.0 | 11111111.11111111.0… | 16 | 16 | 65,536 | 65,534 |
| /24 | 255.255.255.0 | 11111111.11111111.11111111.0 | 24 | 8 | 256 | 254 |
| /25 | 255.255.255.128 | …11111111.10000000 | 25 | 7 | 128 | 126 |
| /26 | 255.255.255.192 | …11111111.11000000 | 26 | 6 | 64 | 62 |
| /27 | 255.255.255.224 | …11111111.11100000 | 27 | 5 | 32 | 30 |
| /28 | 255.255.255.240 | …11111111.11110000 | 28 | 4 | 16 | 14 |
| /29 | 255.255.255.248 | …11111111.11111000 | 29 | 3 | 8 | 6 |
| /30 | 255.255.255.252 | …11111111.11111100 | 30 | 2 | 4 | 2 |
Why “Usable Hosts” is Less Than Total
Two addresses in each subnet are reserved: - Network address (all host bits = 0): Identifies the subnet itself (e.g., 192.168.1.0) - Broadcast address (all host bits = 1): Sends to all hosts on subnet (e.g., 192.168.1.255 for /24)
A /24 subnet has 256 total addresses, but only 254 are assignable to devices.
23.5 Calculating Network and Broadcast Addresses
Example: 192.168.10.45/26
Step 1: Convert subnet mask to binary - /26 = 255.255.255.192 = 11111111.11111111.11111111.11000000
Step 2: Calculate network address (AND operation)
IP: 192 . 168 . 10 . 00101101 (45)
Mask: 255 . 255 . 255 . 11000000 (192)
--- --- --- --------
Net: 192 . 168 . 10 . 00000000 (0)Network Address: 192.168.10.0
Step 3: Calculate broadcast address (set all host bits to 1)
A /26 has 6 host bits. The network address last octet in binary is 00000000. Setting all 6 host bits (rightmost) to 1: 00111111 = 63.
Network: 192.168.10.00|000000 (| marks network/host boundary)
Broadcast: 192.168.10.00|111111 = 192.168.10.63Step 4: Determine usable range - First usable host: 192.168.10.1 - Last usable host: 192.168.10.62 - Total usable hosts: 62 (2^6 - 2 = 64 - 2)
23.6 CIDR Notation and Classless Addressing
CIDR (Classless Inter-Domain Routing) replaced the rigid class-based system with flexible prefix lengths, enabling efficient address allocation.
CIDR Format: network-address/prefix-length - Example: 192.168.1.0/24 - /24 means “first 24 bits are network, remaining 8 bits are host”
23.6.1 CIDR Calculation Formula
Number of addresses = 2^(32 - prefix length)
Examples:
- /24: 2^(32-24) = 2^8 = 256 addresses
- /26: 2^(32-26) = 2^6 = 64 addresses
- /30: 2^(32-30) = 2^2 = 4 addresses (2 usable, for point-to-point links)
Putting Numbers to It
Subnet sizing follows the power-of-2 formula. For a /24 subnet (common for IoT deployments):
\[\text{Total addresses} = 2^{32-24} = 2^8 = 256\] \[\text{Usable addresses} = 256 - 2 = 254\]
The “minus 2” accounts for network (.0) and broadcast (.255) addresses.
For a building with 180 sensors needing 30% growth buffer: \[\text{Required} = 180 \times 1.3 = 234 \text{ devices}\]
Checking /24: \(256 - 2 = 254\) usable ✓ (fits with 20 addresses spare)
But if infrastructure uses 40 IPs (gateway, DHCP, switches, cameras): \[\text{Available for sensors} = 254 - 40 = 214\]
This fails! Need /23 instead: \[2^{32-23} = 2^9 = 512 - 2 = 510 \text{ usable}\] \[510 - 40 = 470 \text{ available} \gg 234 \text{ needed}\]
The math shows why subnet planning must account for all infrastructure, not just endpoint devices.
23.6.2 Quick Reference: Common IoT Subnet Sizes
| Prefix | Hosts | Usable | Typical IoT Use Case |
|---|---|---|---|
| /30 | 4 | 2 | Point-to-point links (gateway to gateway) |
| /29 | 8 | 6 | Very small sensor clusters |
| /28 | 16 | 14 | Small room automation (lighting, HVAC) |
| /27 | 32 | 30 | Single floor sensors and actuators |
| /26 | 64 | 62 | Medium building floor, lab environment |
| /25 | 128 | 126 | Large floor, small building |
| /24 | 256 | 254 | Typical building network, standard choice |
| /23 | 512 | 510 | Multi-building campus segment |
| /22 | 1024 | 1022 | Large campus, industrial facility |
| /20 | 4096 | 4094 | Smart city district |
23.7 Subnetting for IoT Networks
23.7.1 Why Subnet IoT Deployments?
1. Security Isolation
- Separate IoT devices from corporate networks
- Contain breaches (compromised camera can’t access HR data)
- Apply different firewall rules per device type
2. Broadcast Domain Management
- IoT devices often use mDNS, DHCP broadcasts
- Large broadcast domains degrade performance
- Subnetting reduces broadcast traffic
3. Logical Organization
- Group devices by function, floor, building, or security level
- Simplifies troubleshooting (“all cameras are in 192.168.10.x”)
- Enables targeted firmware updates
4. QoS and Traffic Prioritization
- Route critical sensor data (fire alarms) through priority paths
- Throttle non-critical traffic (environmental sensors)
5. Scalability
- Plan for growth (reserve address space for future devices)
- Hierarchical addressing supports large deployments
23.7.2 IoT Subnetting Design Principles
Design Checklist:
23.7.3 Practical Subnetting Example: Smart Building
Scenario: Design addressing for a 10-floor smart office building with: - 50 HVAC sensors per floor (500 total) - 200 LED lighting controllers per floor (2,000 total) - 30 security cameras per floor (300 total) - 20 access control readers per floor (200 total) - 10 environmental sensors per floor (100 total) - 5 network infrastructure devices per floor (50 total)
Total devices: ~3,150 devices
Solution 1: By Device Type (Flat Network)
| Device Type | Count | Buffer | Total | Subnet | CIDR | Usable IPs | IP Range |
|---|---|---|---|---|---|---|---|
| HVAC Sensors | 500 | 150 | 650 | 192.168.1.0 | /22 | 1,022 | .1.1 - .3.254 |
| Lighting | 2,000 | 600 | 2,600 | 192.168.4.0 | /21 | 2,046 | .4.1 - .11.254 |
| Cameras | 300 | 100 | 400 | 192.168.12.0 | /23 | 510 | .12.1 - .13.254 |
| Access Control | 200 | 60 | 260 | 192.168.14.0 | /23 | 510 | .14.1 - .15.254 |
| Environmental | 100 | 30 | 130 | 192.168.16.0 | /24 | 254 | .16.1 - .16.254 |
| Infrastructure | 50 | 15 | 65 | 192.168.17.0 | /26 | 62 | .17.1 - .17.62 |
Solution 2: By Floor (Hierarchical)
Each floor is assigned a /16 address block as its namespace (10.X.0.0/16, where X = floor number), then subdivided into smaller subnets per device type. The /16 is a hierarchical reservation, not a single broadcast domain: - Floor 1: 10.1.0.0/16 → subdivided into /24, /26, /27 etc. per device type - Floor 2: 10.2.0.0/16 → similarly subdivided - Floors 3-10: Same pattern
Example Floor 1 subdivision:
| Device Type | Subnet | CIDR | Usable IPs |
|---|---|---|---|
| HVAC | 10.1.1.0 | /26 | 62 (50 needed) |
| Lighting | 10.1.2.0 | /24 | 254 (200 needed) |
| Cameras | 10.1.3.0 | /26 | 62 (30 needed, room for growth) |
| Access Control | 10.1.4.0 | /27 | 30 (20 needed) |
| Environmental | 10.1.5.0 | /28 | 14 (10 needed) |
| Infrastructure | 10.1.6.0 | /29 | 6 (5 needed) |
Recommendation: Solution 2 (hierarchical by floor) offers better: - Scalability: Easy to add floors - Troubleshooting: “Problem on Floor 3” = check 10.3.x.x - Physical topology mapping: IP matches physical location - Firewall rules: Floor-level access controls
23.7.4 VLSM (Variable Length Subnet Masking)
VLSM allows different subnet sizes within the same network, maximizing address efficiency.
Example: Subdividing 192.168.10.0/24
Breakdown:
- 192.168.10.0/26 (64 addresses) → Cameras
- 192.168.10.64/26 (64 addresses) → HVAC
- 192.168.10.128/27 (32 addresses) → Access Control
- 192.168.10.160/27 (32 addresses) → Environmental
- 192.168.10.192/28 (16 addresses) → Infrastructure
- 192.168.10.208/28 (16 addresses) → Future expansion
- 192.168.10.224/27 (32 addresses) → Reserved
Total: 256 addresses allocated with zero waste!
Tradeoff: Static IP Assignment vs DHCP for IoT Devices
Option A: Static IP addresses - Each device configured manually with fixed IP, subnet mask, gateway. No DHCP dependency (works during network outages), predictable firewall rules, easy asset tracking. Management cost: 2-5 minutes per device setup, spreadsheet/IPAM database required, IP conflicts if mismanaged.
Option B: DHCP with reservations - Server assigns IPs automatically, reservations tie MAC address to specific IP. Self-healing (device reboots get correct IP), centralized management, automatic DNS registration. Dependencies: DHCP server must be available at boot, reservation database must be maintained, potential delays (DORA: 4 packets, 50-500ms).
Decision Factors: Use static for critical infrastructure (<20 devices), devices that must work during network failures (safety systems, gateways), or extremely constrained devices without DHCP client. Use DHCP for large deployments (>50 devices), devices with easy configuration interfaces, or when devices move between locations. Hybrid approach: static for gateways/servers, DHCP for sensors.
23.8 Real-World Case Study: Retrofit Subnetting for a University Smart Campus
A mid-size university (12,000 students, 45 buildings) deployed 8,500 IoT devices over three years with no subnetting plan – all devices shared a single 10.0.0.0/16 network. By year three, the network was failing.
The Problem: With 8,500 devices on one flat /16 subnet, broadcast traffic consumed 12% of the 100 Mbps backbone. ARP storms during peak hours caused 3-8 second latency spikes on the building management system, and a compromised IP camera in the library gave attackers lateral access to HVAC controllers in the chemistry building – a safety incident that triggered an emergency network redesign.
Initial Flat Network (Before):
10.0.0.0/16 (65,534 usable addresses)
- 3,200 HVAC/environmental sensors
- 2,100 lighting controllers
- 1,500 IP cameras
- 800 access control readers
- 500 lab equipment monitors
- 400 digital signage displays
Total: 8,500 devices, zero segmentation
Broadcast traffic: ~1,200 packets/second (12% of link capacity)Redesigned Hierarchical Subnetting (After):
The network team allocated 10.{building}.{type}.0/24 per device category per building:
| Building ID | HVAC Subnet | Cameras Subnet | Access Control | Lighting |
|---|---|---|---|---|
| Science (10.1.x.x) | 10.1.1.0/24 | 10.1.2.0/24 | 10.1.3.0/27 | 10.1.4.0/24 |
| Library (10.2.x.x) | 10.2.1.0/25 | 10.2.2.0/25 | 10.2.3.0/28 | 10.2.4.0/25 |
| Admin (10.3.x.x) | 10.3.1.0/26 | 10.3.2.0/26 | 10.3.3.0/28 | 10.3.4.0/26 |
| … (42 more) | … | … | … | … |
Firewall rules between subnets:
- Cameras cannot initiate connections to any other subnet (outbound to NVR only)
- HVAC sensors can reach BMS server (10.100.1.0/28) only
- Access control readers connect to door controller server only
- No inter-building IoT traffic permitted without explicit rule
Quantitative Results:
| Metric | Flat /16 (Before) | Hierarchical (After) | Improvement |
|---|---|---|---|
| Broadcast traffic per segment | 1,200 pkt/s | 15-40 pkt/s | 30-80x reduction |
| ARP resolution latency | 3-8 seconds (storms) | <10 ms | 300-800x faster |
| Lateral attack surface | 8,499 reachable devices | 30-60 per subnet | 140-280x smaller |
| Troubleshooting time (avg) | 4.2 hours | 35 minutes | 7x faster |
| Annual downtime | 127 hours | 8 hours | 94% reduction |
Key Insight: Subnetting is not optional for IoT deployments exceeding 500 devices. The university’s flat network worked for the first 500 devices but degraded quadratically as broadcast traffic scales with N-squared (every device ARPs every other device). At 8,500 devices, the broadcast storm consumed more bandwidth than actual sensor data. The /24-per-type-per-building scheme provides natural security boundaries, manageable broadcast domains, and an IP addressing scheme that doubles as an asset inventory (10.1.2.x = “Science building, cameras”).
Worked Example: Subnetting a 3-Floor Smart Office Building
You’re designing the network for a new 3-floor office building with the following requirements:
Floor 1 (Lobby/Public): 50 IoT devices (cameras, access control, digital signage) Floor 2 (Offices): 120 devices (workstations, VoIP phones, sensors) Floor 3 (Operations): 200 devices (servers, printers, HVAC, lighting control) Allocated address space: 10.50.0.0/22 (1,022 usable addresses)
Step 1: Calculate needed addresses per floor (with 30% growth buffer)
Floor 1: 50 devices × 1.3 = 65 → need /25 (126 hosts) ✓
Floor 2: 120 devices × 1.3 = 156 → need /24 (254 hosts) ✓
Floor 3: 200 devices × 1.3 = 260 → need /23 (510 hosts) ✓
Total needed: 65 + 156 + 260 = 481 addresses
Available: 1,022 addresses
Utilization: 47% (good - leaves room for Floor 4 expansion)Step 2: Assign subnets using VLSM (largest first)
Floor 3 (largest): 10.50.0.0/23
Network: 10.50.0.0
Broadcast: 10.50.1.255
Usable: 10.50.0.1 - 10.50.1.254 (510 hosts)
Floor 2 (medium): 10.50.2.0/24
Network: 10.50.2.0
Broadcast: 10.50.2.255
Usable: 10.50.2.1 - 10.50.2.254 (254 hosts)
Floor 1 (smallest): 10.50.3.0/25
Network: 10.50.3.0
Broadcast: 10.50.3.127
Usable: 10.50.3.1 - 10.50.3.126 (126 hosts)
Reserved for future: 10.50.3.128/25
(126 additional hosts for future floors/departments)Step 3: Verify no subnet overlap
Floor 3: 10.50.0.0 - 10.50.1.255 (512 addresses, 0000-0001 in 3rd octet)
Floor 2: 10.50.2.0 - 10.50.2.255 (256 addresses, 0010 in 3rd octet)
Floor 1: 10.50.3.0 - 10.50.3.127 (128 addresses, 0011.0--- in 3rd-4th octets)
Reserved: 10.50.3.128 - 10.50.3.255 (128 addresses, 0011.1--- in 3rd-4th octets)
✓ No overlap - each subnet is distinct
✓ Contiguous allocation - easy to summarize as 10.50.0.0/22Result: Efficient use of allocated space with room for growth, clean subnet boundaries, and hierarchical organization that maps to physical building layout.
Decision Framework: Flat vs Hierarchical Subnetting
| Criterion | Flat Network (Single /16) | Hierarchical Subnetting (Multiple /24-/27) |
|---|---|---|
| Device count | <500 devices | >500 devices |
| Broadcast traffic | ~50-100 pkt/s (tolerable for 100 Mbps) | ~5-10 pkt/s per subnet (isolated) |
| Security isolation | None (all devices see each other) | Per-floor or per-type isolation possible |
| Troubleshooting | Harder (“IP conflict somewhere in building”) | Easier (“Floor 2 DHCP issue: check 10.50.2.x”) |
| Hardware requirements | Simple switch ($200) | Layer 3 switch or router ($800-$2,000) |
| Setup complexity | Low (1 DHCP server, 1 VLAN) | Medium (multiple VLANs, inter-VLAN routing) |
| Scalability | Poor (broadcast storms >500 devices) | Excellent (add floors = add subnets) |
| Firewall rules | Difficult (by IP address only) | Easy (by subnet: “Block Floor 1 → Floor 3”) |
| Best for | Single-floor office, home network | Multi-floor buildings, security-sensitive environments |
Decision Factors:
- Broadcast threshold: If >500 devices OR >1% of link capacity consumed by broadcasts → subnet
- Security requirements: Regulated industries (HIPAA, PCI-DSS) → subnet by department minimum
- Physical layout: Multiple buildings or floors → subnet per location (simplifies troubleshooting)
- Growth rate: Rapid expansion expected → hierarchical from day one (avoid re-IP later)
Example Decision:
- Home network (20 devices): Flat 192.168.1.0/24 - simple, no subnetting needed
- Small business (150 devices, 1 floor): Flat 10.0.0.0/23 - still manageable
- Mid-size office (300 devices, 3 floors): Hierarchical /24 per floor - security + troubleshooting benefits outweigh cost
- Enterprise campus (5,000 devices, 10 buildings): Hierarchical /24 per building-floor - mandatory for scale
Rule of thumb: Subnet when broadcast traffic exceeds 1% of link capacity OR when security isolation is required.
Common Mistake: Failing to Account for Infrastructure Device Consumption
The Error: “I have a /24 subnet (254 usable addresses) for 200 workstations. That leaves 54 addresses for growth - plenty of headroom!”
What’s Missing: Infrastructure devices consume IPs before user devices even start:
Subnet: 10.20.30.0/24 (254 usable IPs)
Infrastructure overhead:
- Default gateway (router): 1 IP (typically .1)
- DHCP server: 1 IP (typically .2 or .254)
- DNS servers: 2 IPs (typically .3, .4 for redundancy)
- Network printers: 3 IPs (.5, .6, .7)
- Wi-Fi access points: 5 IPs (.10-.14)
- IP cameras: 8 IPs (.20-.27)
- Building automation (HVAC, lighting): 4 IPs (.30-.33)
- Network management station: 1 IP (.100)
- Reserved for static assignments: 10 IPs (.240-.249)
Total infrastructure: 35 IPs consumed
Available for workstations: 254 - 35 = 219 IPs
Deployment: 200 workstations
Actual headroom: 219 - 200 = 19 IPs (NOT 54!)
Utilization: 91% (DANGEROUS - no room for growth)Real-World Failure (Hospital Floor, 2022):
Planned: 180 medical devices on 192.168.5.0/24 subnet
Expected headroom: 254 - 180 = 74 IPs
Reality after deployment:
- Infrastructure: 42 IPs (more printers/cameras than anticipated)
- Medical devices: 180 IPs
- Total: 222 IPs consumed
Remaining: 254 - 222 = 32 IPs (13% buffer)Then they added 40 new patient monitoring devices:
Needed: 222 + 40 = 262 IPs
Available: 254 IPs
Result: 8 devices couldn't get addresses (DHCP pool exhausted)Emergency fix cost:
- Weekend network re-IP project: $12,000 in overtime
- Changed to /23 (510 usable) with proper infrastructure audit
Correct Sizing Formula:
Infrastructure overhead = gateway + DHCP + DNS + printers + cameras +
access points + automation + reserved + 20% misc
User devices needed = current count × 1.3 (30% growth)
Total required IPs = infrastructure + user devices
Subnet size = next power-of-2 subnet that provides ≥ total required IPs
Safety check: Actual utilization should be <70% on deployment dayExample (corrected):
Infrastructure: 35 IPs
Workstations: 200 × 1.3 = 260 IPs (with growth)
Total needed: 295 IPs
/24 provides 254 → Too small! (115% utilization)
/23 provides 510 → Correct choice (58% utilization with buffer)Key Insight: Always audit infrastructure before sizing subnets. The “hidden” 30-50 IPs for infrastructure turn a comfortable /24 into an overloaded one. Factor in reality, not just the user device count from the spreadsheet.
Common Pitfalls
1. Off-by-One Errors in Host Count Calculations
A /25 subnet has 7 host bits → 2^7 = 128 addresses, but only 126 usable hosts (subtract network and broadcast). Forgetting to subtract 2 leads to address shortages. Fix: always subtract 2 from 2^(host bits) to get the usable host count.
2. Not Aligning Subnets to Power-of-Two Boundaries
A /26 subnet (64 addresses) must start at a multiple of 64 (0, 64, 128, 192). Starting at 192.168.1.50 is invalid. Fix: always verify that the network address is a multiple of the subnet size (2^host bits).
3. Creating Subnets That Are Too Small for IoT Deployments
Assigning a /28 (14 usable hosts) to an IoT VLAN that starts with 10 devices seems adequate, but adding sensors over time quickly exhausts the space. Fix: allocate at least 3× the current device count as the subnet size to allow for growth.
23.9 Summary
- Subnet masks divide IP addresses into network and host portions using consecutive 1s (network) and 0s (host)
- CIDR notation expresses masks compactly: /24 = 255.255.255.0 = 256 addresses (254 usable)
- Network address is calculated by ANDing the IP with the mask; broadcast address has all host bits set to 1
- Subnet sizing formula: 2^(32 - prefix length) = total addresses, minus 2 for network and broadcast
- IoT subnetting provides security isolation, broadcast control, logical organization, and scalability
- VLSM enables efficient address allocation with variable-sized subnets for different device types
- Design best practice: Inventory devices, add 30% growth buffer, document everything, and consider hierarchical addressing for large deployments
23.10 What’s Next
Now that you can design and calculate subnets for IoT networks, continue building your networking knowledge:
| Topic | Chapter | Description |
|---|---|---|
| Ports and NAT | Ports and NAT | Identify services with port numbers and enable internet access for private IoT subnets using Network Address Translation |
| IPv6 for IoT | IPv6 for IoT | Apply the next-generation addressing protocol with its vastly larger address space designed for IoT scale |
| DHCP and Address Resolution | DHCP and Address Resolution | Configure automatic IP assignment for large IoT deployments and understand ARP and Neighbour Discovery protocols |
| IPv4 Addressing Fundamentals | IPv4 Fundamentals | Reinforce the 32-bit address structure and binary representation that underpins all subnet calculations |
| Networking Basics | Networking Basics | Review foundational networking concepts including OSI layers, frames, and packet forwarding |