It is common to allocate /24 or /22 subnets to a single VLAN but William writes to ask whether is related to broadcasts. What is the best subnet size for VLAN allocation and why ? The answer isn’t what you think.

William writes

A CCNP friend of mine says that you should never use any subnet bigger than /22 if all the available addresses will be used due to the broadcast chatter from do many hosts. This sounds reasonable, but I haven’t found anything on the Googles yet to second the opinion (citation needed!). What do you think, is a /22 the largest VLAN you would use in an enterprise? Could you cite any reference on this subject?

Well, back in the mid-1990’s the maximum practical size of a shared Ethernet segment was about 100 hosts. This was a time of hubs and shared Ethernet segments with bridges to reduce Ethernet domains by filtering MAC addresses. Importantly, network protocols like NetBEUI and IPX/SPX used a LOT of broadcasts for name resolution. Literally, every device would broadcast at regular intervals its protocol name and MAC address to other devices to hold a name/address table. Or they would respond to name resolution requests received by broadcast.

For 10Megabit Shared Ethernet with some bridges, 100-200 hosts was the rule of thumb. When TCP/IP subnetting came around in early 2000’s we went to /24 because that was a good number of 254 hosts, sat on the classful IP boundary for Class C networking and was roughly the same as existing practices. Networking doesn’t like to adopt change so nothing changed.

In the mid-2000’s as TCP/IP took hold it became common to increase the Campus Subnets to /22 as the number of devices in the network increased and we were limited to 1024 VLAN IDs. Networking was forced to make a change, so we did.

Broadcasts had reduced significantly because the dominant protocol of Microsoft’s NetBIOS over TCP/IP had stopped using broadcasts for name resolution by default and switched to using Windows Internet Naming Service (WINS) . The logic was that 1000 or so hosts would a reasonable number for pure TCP/IP networks.

Broadcasts Bad For Performance

At that time, IP Broadcasts were a problem for performance because Microsoft operating systems on the desktop (of which there was an ever increasing number) would constantly broadcast their name and IP Address so that each computer could build a list of NetBIOS services in the network. For every broadcast received, the network driver in the workstation would directly interrupt the CPU with Non-Maskable Interrupt and process the packet. Many packets are simply discarded because they aren’t needed by every workstation e.g. An ARP request to resolve an IP Address to a MAC Address is processed by every workstation in a VLAN. Back in the old days, it was common to see desktops computers with 5 to 10% of CPU time spent handling broadcasts. Expensive in terms of power and lost processing time.

And Now

Today, broadcasts are rare because protocols have been updated AND rolled out to operating systems . Device operating systems are better hardened against broadcasts storms. CPU speed has increased to the point where even a large amount of broadcasts has zero impact to operation.

1000 Hosts to A Failure Domain

But I would still use 1000 hosts as maximum because of failure domains. An Ethernet VLAN is, and always will be, a single failure domain because it is a shared medium. A fault on one host may impact every host in the VLAN.

Network adapters are much more reliable these days but sometimes network adapters have a silicon failure and transmit corrupted frame onto Ethernet network. These electrical/silicon faults create frames that look like broadcasts and can take down the entire VLAN/Subnet. I’ve seen it happen a couple of times in the last two years. Worst case can take down a Spanning Tree and the entire Ethernet network because broadcasts can cause bridging loops.

The EtherealMind View

So, 1000 hosts or /22 would still be my advice but not because there are too many broadcasts but to limit failure domain when bad things happen while having enough IP addresses to support a lot of endpoints like laptops and smartphones.