How to Design the Perfect RFC1918 Subnet Scheme

Throughout my time in networking, I’ve always wondered about the possibility of the perfect subnet scheme. A one size fits all scheme that could be used across all different sizes of internal networks and organizations. In reality, no such scheme truly exists and no one really cares that much about internal subnetting, however, I decided none the less to give it a crack. To quote the famous computer scientist Ellen Ullman;

“We build our computer (networks) the way we build our cities — over time, without a plan, on top of ruins.” — Ellen Ullman

The perfect subnet scheme is difficult to design due to the inflexibility of the subnetting number system in general. The network requirements & size of the organization are, of course, what determines the way a subnet scheme is designed, however, the vast majority of organizations have very basic subnetting requirements. What makes the perfect subnet scheme is largely down to taste; in my case it is structure, logic and usability that reign supreme above all other requirements. Subnetting by design is extremely logical, therefore, if designed correctly, structure & usability will follow.

RFC1918 reserves three address ranges for private internal network use. The obvious choice for the perfect subnet scheme is clearly 10.0.0.0/8. This range provides the most number of usable IP addresses of the three ranges; 16,777,216 to be specific and is the most aesthetically pleasing to administer.

There are three factors to consider when designing the perfect subnet scheme for the 10.0.0.0/8 range.

How many unique sites do I need?

As mentioned in the introduction, this scheme is designed for the average organization. It is reasonable to assume that the average organization does not have more than 256 unique sites. This site ID value will be represented in the second octet, with the maximum value being 255.

• 10.<site-id>.0.0

How big are my subnets?

There is no downside to completely exhausting the private range of RFC 1918 as the address space is not scarce (good luck finding 16 million endpoints on an internal network). Instead of conserving address space, the key is to design an admin-friendly, logical numbering scheme that has sufficient address space per subnet. The following rules have been selected as the guiding criteria for selecting the optimal subnet scheme:

• No site should need more than 64 subnets
• No subnet should need more than 1024 addresses

Retrofitting subnets can be difficult once a subnet has been implemented, primarily due to the shortcomings of static IP addressing (damn printers). Therefore, the logical conclusion is to, by design, assign more space than is required on every subnet, regardless of the use (Servers, VoIP, BYOD, etc). The perfect subnet for this scheme is therefore a /22.

How do I include a VLAN ID into the scheme?

Many network engineers have attempted to include the VLAN ID into the network address space scheme. Almost all fail due to not fully thinking the problem through. The issue is scalability and consistency across the numbering. Which octet does the VLAN ID go in? It can’t sit in the first octet as this is fixed at 10. The second octet is the site ID. The VLAN ID must sit in the 3rd octet.

• 10.0.<vlan-id>.0

Most also tend to assume that VLAN IDs have to go up sequentially; i.e. VLAN 1, VLAN 2, VLAN 3. This thinking is not compatible with the most common subnet size in use; /24. e.g:

• VLAN 1 10.0.1.0/24
• VLAN 2 10.0.2.0/24
• VLAN 3 10.0.3.0/24

Because what if VLAN 2 needs to be bigger than /24? The scheme breaks immediately as it cannot handle larger than /24 subnets without crossing over into another subnet. What about using the same scheme but instead:

• VLAN 10 10.0.10.0/24
• VLAN 20 10.0.20.0/23
• VLAN 30 10.0.30.0/22

Nope, still does not work as you are now capped at 25 VLANs per site. The address space also begins to go backwards when you pick larger than /24 subnets. e.g. the subnet for VLAN 30 starts at 10.0.28.0. This almost works but it’s not good enough for the perfect subnet scheme.

The answer lies in picking the correct VLAN ID and using a fixed subnet size for every VLAN. VLAN IDs do not have to rise sequentially. Instead, they should rise with the subnet network address. e.g:

• VLAN 1 10.0.1.0/22
• VLAN 4 10.0.4.0/22
• VLAN 8 10.0.8.0/22

The final touch is deciding where to place the subnet gateway address. This is an obvious choice as the first usable host address will always contain the VLAN ID as opposed to using the last host address which will have a different set of bits in the 3rd octet.

• VLAN 1 10.0.1.1
• VLAN 4 10.0.4.1
• VLAN 8 10.0.8.1

Most engineers will not bother with this much effort when designing a subnet scheme, however, they fail to understand how much of a mistake this is. When thousands of endpoints are scattered across hundreds of VLANs across tens of sites, subnet management becomes difficult and the issue is only magnified when the organization attempts to perform network automation.

With these three factors considered; we have an equation for a fully logical subnet scheme that has sufficient capacity and scalability for probably 90% of the internal networks in the world.

Thanks for reading; full example table below.

Footnotes

To create larger than /22 subnets, work backwards (to protect the structure of the standardized subnets at the start of the range) from the highest possible subnet and merge the next subnet. e.g. Site 32 needs a /21 network or something bigger;

• Merge VLAN 248 and VLAN 252 together, so the new highest subnet will be VLAN 248 10.32.248.0/21