Loading learning content...
Network domain sizing sits at the intersection of theoretical computer networking and practical engineering trade-offs. How many hosts should share a collision domain? How large can a broadcast domain grow before performance degrades? These questions don't have universal answers—the right sizing depends on traffic patterns, device capabilities, application requirements, and administrative constraints.
This page develops a systematic framework for domain sizing decisions. We'll examine the factors that influence optimal sizes, provide concrete guidelines for different scenarios, and develop calculation methods that let you analyze and predict network behavior. The goal is to equip you with the knowledge to make informed, defensible sizing decisions in real network designs.
In modern switched networks with full-duplex links, collision domain sizing is essentially moot—each device has its own collision-free domain. However, we cover collision domain sizing for completeness, legacy network understanding, and scenarios where shared media still exists (wireless networks, half-duplex links, hub-based segments).
Collision domain sizing determines how many stations share a contention-based medium. While largely historical for wired Ethernet, these principles remain relevant for wireless networks (which still use contention-based access) and any scenario involving shared media.
Theoretical Maximum: The Throughput Ceiling
CSMA/CD protocols have fundamental efficiency limits. As covered in earlier modules:
These limits set the upper bound on total traffic a collision domain can carry, regardless of the number of stations.
Station Count Impact
More stations in a collision domain increase collision probability:
| Active Stations | Probability of Collision | Effective Throughput | Assessment |
|---|---|---|---|
| 2 | Low (~2-5%) | ~90-95% of max | Optimal |
| 5 | Moderate (~10-15%) | ~80-90% of max | Good |
| 10 | Higher (~20-30%) | ~65-80% of max | Acceptable |
| 20 | High (~35-50%) | ~50-65% of max | Marginal |
| 30+ | Very High (>50%) | <50% of max | Problematic |
Practical Collision Domain Sizing Guidelines
For legacy shared Ethernet or any contention-based medium:
Optimal: 2-10 active stations per collision domain
Acceptable: 10-20 active stations
Problematic: 30+ active stations
Physical Constraints
Collision domains also have physical size limits dictated by the slot time requirement:
| Network Speed | Slot Time | Maximum Domain Size |
|---|---|---|
| 10 Mbps | 51.2 µs | ~2,500 m |
| 100 Mbps | 5.12 µs | ~250 m |
| 1 Gbps | 512 ns | ~25 m (impractical) |
At Gigabit speeds, the slot time constraint makes shared-media collision domains impractical—this is why Gigabit Ethernet requires full-duplex or uses carrier extension techniques.
The most effective collision domain sizing strategy is to eliminate shared collision domains entirely. Use switches instead of hubs, ensure full-duplex operation, and you've reduced every wire segment to a point-to-point, collision-free link. This is why discussions of collision domain sizing are largely academic for modern wired networks.
Broadcast domain sizing remains critically important in modern networks. Unlike collision domains (which have been largely eliminated by switching), broadcast domains persist and directly affect network performance, scalability, and manageability. The goal is to find the optimal balance between:
Several factors influence the optimal size for a given environment:
The Broadcast Tax: Quantifying the Load
Every host in a broadcast domain pays a 'broadcast tax'—the CPU cycles spent processing broadcast frames destined for other hosts. Let's quantify this:
Per-Frame Processing Cost:
For a single ARP request, this might consume 1-5 µs of CPU time on a modern processor. Trivial for one frame, but at 1,000 broadcasts/second across 500 hosts, that's 2.5-12.5 milliseconds of cumulative CPU time per host per second—enough to affect real-time or CPU-bound applications.
Broadcast traffic often scales with N² where N is the number of hosts. If each of N hosts sends broadcasts that N-1 hosts must process, total processing events approach N × (N-1) = N² - N. This non-linear scaling is why very large broadcast domains become problematic even with modern hardware. Doubling the hosts more than doubles the aggregate broadcast load.
Based on decades of collective industry experience and evolving hardware capabilities, we can establish sizing guidelines for different network scenarios. These are starting points for design—actual optimal sizes depend on specific conditions.
Historical Evolution of Recommendations
| Era | Typical Recommendation | Primary Constraint | Notes |
|---|---|---|---|
| 1990s (10 Mbps) | ~250 hosts max | Bandwidth | Broadcast traffic consumed significant bandwidth |
| 2000s (100 Mbps) | ~500 hosts max | CPU Processing | Bandwidth less of an issue; CPU became bottleneck |
| 2010s (1 Gbps) | ~500-1000 hosts | Management/Visibility | Hardware handles load; operational concerns dominate |
| 2020s (10+ Gbps) | Varies widely | Design Philosophy | From ~250 (conservative) to 4000+ (data center) |
Current Guidelines by Scenario
Enterprise Campus Networks (Traditional)
Small to Medium Business
Data Centers (Modern)
IoT and Industrial Networks
Wireless Networks
Many organizations default to /24 subnets (254 usable addresses) without analysis. This can be wasteful (if you need 20 hosts) or constraining (if you legitimately need 300 hosts). Let requirements drive subnet sizing, not tradition. Variable Length Subnet Masking (VLSM) allows right-sized subnets.
Beyond general guidelines, you can calculate expected broadcast load for a specific design. This quantitative approach helps justify sizing decisions and identify potential problems before deployment.
Step 1: Identify Broadcast Sources
Catalog the types of devices and their broadcast behavior:
| Device Type | Broadcasts/Second | Primary Sources | Notes |
|---|---|---|---|
| Windows Workstation (NetBIOS enabled) | 0.3 - 1.0 pps | NetBIOS, ARP, DHCP | Chatty; consider disabling NetBIOS |
| Windows Workstation (NetBIOS disabled) | 0.1 - 0.3 pps | ARP, DHCP, mDNS | More reasonable baseline |
| Linux Server (well-configured) | 0.05 - 0.15 pps | ARP (rarely) | Minimal broadcast traffic |
| IP Phone | 0.1 - 0.3 pps | DHCP, discovery | May have periodic announcements |
| Printer/Scanner | 0.1 - 0.5 pps | mDNS, SSDP | Discovery protocols quite chatty |
| IoT Device (varies) | 0.01 - 1.0 pps | Variable | Wide range; test specific devices |
| Mac Workstation | 0.2 - 0.5 pps | Bonjour/mDNS, ARP | Service discovery is primary source |
Step 2: Calculate Total Broadcast Rate
Total Broadcasts/Second = Σ(Device Count × Broadcast Rate per Device Type)
Example Calculation:
Step 3: Calculate Bandwidth Consumption
Broadcast Bandwidth = Total pps × Average Frame Size × 8 bits/byte
Assuming average broadcast frame size of 100 bytes:
94 pps × 100 bytes × 8 bits/byte = 75,200 bps ≈ 75 Kbps
On a 1 Gbps network: 75 Kbps / 1,000,000 Kbps = 0.0075% of bandwidth
Step 4: Calculate CPU Impact
Each broadcast must be processed by every host:
Processing Events/Second = Total Broadcasts × (Host Count - 1)
For 250 hosts at 94 broadcasts/second:
94 × 249 = 23,406 processing events/second across the domain
Per host: 94 broadcasts/second to process
At 5 µs of CPU time per broadcast:
94 × 5 µs = 470 µs per second = 0.047% CPU overhead
This is negligible for modern CPUs but accumulates in larger domains or with chatty devices.
While calculations provide estimates, measuring actual broadcast traffic is more accurate. Use SNMP to poll switch ports for broadcast packet counts, or capture traffic at a monitoring point. Real measurements reveal device behaviors that differ from theoretical estimates and catch misconfigured or misbehaving devices.
In standard network design, each broadcast domain corresponds to one IP subnet. This one-to-one relationship simplifies management and ensures proper IP routing. Understanding subnet sizing is thus essential to broadcast domain sizing.
Common Subnet Sizes
| CIDR Notation | Subnet Mask | Total Addresses | Usable Hosts | Typical Use Case |
|---|---|---|---|---|
| /30 | 255.255.255.252 | 4 | 2 | Point-to-point links |
| /29 | 255.255.255.248 | 8 | 6 | Small DMZ, WAN links |
| /28 | 255.255.255.240 | 16 | 14 | Small server cluster |
| /27 | 255.255.255.224 | 32 | 30 | Lab network, small VLAN |
| /26 | 255.255.255.192 | 64 | 62 | Department subnet |
| /25 | 255.255.255.128 | 128 | 126 | Medium VLAN |
| /24 | 255.255.255.0 | 256 | 254 | Standard VLAN (common default) |
| /23 | 255.255.254.0 | 512 | 510 | Large department, floor |
| /22 | 255.255.252.0 | 1024 | 1022 | Large VLAN, campus building |
| /21 | 255.255.248.0 | 2048 | 2046 | Data center segment |
| /20 | 255.255.240.0 | 4096 | 4094 | Large data center VLAN |
Sizing Strategy: Top-Down vs. Bottom-Up
Top-Down Approach (Allocation-First):
Example: You have a /16 (65,536 addresses). You need 64 subnets for different VLANs. 65,536 ÷ 64 = 1,024 addresses per subnet = /22 subnets.
Bottom-Up Approach (Requirement-First):
Example: You need:
Total: (10 × 256) + (5 × 64) + (20 × 4) = 2,560 + 320 + 80 = 2,960 addresses → need at least /20
Address Efficiency Considerations
Smaller subnets waste more addresses proportionally:
In IPv4 environments with address scarcity, this matters. In IPv6, address efficiency is less of a concern, and operational simplicity often wins.
Remember that each subnet 'loses' addresses to network ID (first address), broadcast address (last address), and usually a gateway (often first or last usable). A /30 has 4 addresses but only 2 usable hosts. A /28 has 16 addresses but only 14 usable hosts. Always calculate usable hosts, not total addresses.
Every domain sizing decision involves trade-offs. There is no universally 'correct' size—only the right size for a given set of requirements and constraints. Let's examine the trade-offs systematically.
When to Favor Larger Domains
When to Favor Smaller Domains
The Modern Trend: Microsegmentation
Recent security-focused architectures push toward very small domains:
These approaches favor many small domains (or individual host isolation) over large, shared domains. The trade-off is significant complexity in management, policy definition, and troubleshooting.
A pragmatic approach: size domains based on functional groupings. A department of 50 people gets a /26. A server farm of 200 machines gets a /24. Point-to-point links get /30s. Guest WiFi gets its own VLAN sized for expected capacity. This balances operational needs with isolation benefits.
We have developed a comprehensive framework for collision and broadcast domain sizing. This knowledge enables informed network design decisions that balance performance, scalability, manageability, and security concerns.
With domain sizing principles understood, you're prepared for the final topic in this module: performance implications. The next page examines how collision and broadcast domain design decisions affect network throughput, latency, reliability, and troubleshooting complexity.