Aggregating Subnets

Back in the 1990s, all the networks we designed were /24 and we would try to allocate no more than about 100 nodes to each network.

When we are designing almost anything, we never fill it more than 60% to allow for future flexibility and expansion. This is the same with subnets.

As well as needing very small networks, sometimes we need big networks. There are no hard and fast rules as to how big a single LAN or Ethernet network should be, but the largest single networks we size has IP addresses for 2,000 nodes and we only ever use <1,000. So why keep networks smaller?

Some protocols are chatty and broadcast to the local subnet. Once there are enough nodes on a subnet, the background broadcast traffic starts to become significant. A network is considered a broadcast domain. Most of the very chatty protocols have been fixed or deprecated and this is probably no longer a valid reason to limit network size.

If something goes wrong and a node starts broadcasting, this can freeze the entire subnet; this is a failure domain and one of the most common practices in modern design is to limit the size of failure domains, to ensure a broadcast storm is limited to fewer nodes.

Unless there is

• a company policy dictating otherwise

• a valid design reason

keep your networks small!

Let’s look at the example of my biggest normal network. I’ll aggregate eight class C addresses into a single large network of 8 * 256 = 2,048 addresses. All the ATU Letterkenny student networks are sub-netted this way.

Maybe that is too big.

Aggregate four class C addresses into a single large network of 4 * 256 = 1,024 addresses.

Simple!