Working with subnets

An attempt to identify the importance of subnet sizes.

Lance Westmoreland

4 min read

I had a good friend ask me recently about subnet sizes the other day. Specifically, he wondered why a subnet of a smaller size was preferred to a larger one. Before we get too far into some of the reasons why, I think it's important to identify what a subnet is, some history, and why we use them.

SUBNET (Subnetwork): a segmented piece of a larger network

If we recall that an IPv4 address has a 32-bit, four octet IP address and a corresponding subnet mask, where a subnet mask identified the network/host portion of an IP address. This might look something like 10.1.1.10 255.255.0.0, meaning 10.1.x.x was the network portion and x.x.1.10 was the host portion.

Originally, subnets were classful and the classes determined host portion sizes. For example:

Class A: 1 - 126.0.0.0 255.0.0.0 - Over 16 million identifiers

Class B: 128-191.0.0.0 255.255.0.0 - 65,535 identifiers

Class C: 192 - 233.0.0 255.255.255.0 - 254 identifiers

If an organization needed more than the 254 hosts allowed in a Class C network, it would be switched to a Class B. By doing this, though, they potentially waste 60,000 hosts if they don't use every IP available to the new Class B network. This inefficiency brought about, the necessary, Classless Inter-Domain Routing (CIDR).

CIDR is based on variable-length subnet masking (VLSM) which allowed for more granular use of network spaces and avoid wasting large numbers of addresses. It accomplished this by allowing network engineers to pull singular bits of the host portion into the network portion. So instead of large jumps between a Class C to a Class B we could denote, in CIDR notation, what bits had been borrowed to create smaller network sizes that landed between those two class sizes. A Class C would be a /24 network (255.255.255.0) and a Class B would be a /16 network (255.255.0.0). The difference in size between these two network sizes is very large and we don't want to waste all of that space we would create a /21 subnetwork (255.255.248.0). Now we have 2,048 IPs to use from, expanding out from 254 that the Class C originally gave us but not wasting 60,000+ that the Class B would have.

If this sounds like a foreign language, I get it. But trust me the more you subnet the more it makes sense as you see the bit values change and see the sizes of the networks grow and IP spaces/needs fluctuate.

But to the original question...

Aside from avoiding wasting IPs, why would you care about subnet size?

I had to think a little about why as, while you work on these things in a production environment, sometimes things are just set the way they are based on original network needs and multiple /24 subnets worked well. But then you consider expansion. In the explanation above we want to avoid wasting IPs but what if, now, there are subnets that have been created one after the next. For example, we have subnet 10.1.1.0/24, 10.1.2.0/24, and 10.1.3.0/24. We need to expand 10.1.2.0/24 and retain its default gateway to do this "cleanly". You couldn't simply adjust the subnet to a /23 or larger because 10.1.2.0/23 falls within the 10.1.3.0/24 IP space, borrowing a bit from the network portion to expand the host portion.

Planning for expansion and creating subnets with accurate use cases/expected host counts is important as we want to be able to flex as things grow without major adjustments to infrastructure, ACLs, firewall rules, DHCP, etc. So we want to find a good middle ground between IP spaces that have room for expansion based on the expected host number in a network and wasting IP spaces by making the host portions too large in networks.

But wait there's more!

I also would add, from experience, that having smaller well-defined subnets has other perks. When you have penetration testing done on internal LAN subnets where scans are ran against subnets, it makes a large difference between scan times based on subnet size. A /16 network scan runs protocol and port scans against all 65,535 IPs to see if there is a host behind each IP and whether or not it responds on certain ports. This could take a while depending on the pen test configuration. By targeting smaller subnet sizes, scans take less time to complete. But doesn't this mean an attacker can scan faster as well if he had internal access? Yes, but that leads me to my last point...

And even more...

By using smaller subnet types we can control traffic more effectively through the use of ACLs and firewall rules. Sure, entering a rule in either of these is no harder based on subnet size but, when parsing through logs, seeing an IP with a specific role attached and a limited host size can be useful. Searching for traffic matching a smaller subnet size may also be simplified by the same means. A security bonus! If an attacker were scanning an entire /8 network size but there are smaller network sizes within that, they may not get a response from their scan before the blue team were notified by a scan or attack in progress alert.

I hope this all made some sense and maybe helped understand why we approach subnetting in certain ways. Another tool for learning here would be a subnet calculator (FOR SHAME! No, but seriously, it's good for a quick visual on subnetting) like this one at https://www.calculator.net/ip-subnet-calculator.html. There are plenty of others online as well as subnet reference charts that can be handy.

 

A video on subnetting by the legendary Professor Messer