Optimizing CIDR Prefixes

1. From Host Requirements to Subnet Size

The core task is to find the smallest possible subnet that can accommodate the required number of hosts. This involves a simple but crucial calculation.

Remember from our foundational module that a subnet prefix reserves a certain number of bits for the network portion of an address, leaving the rest for hosts. If a subnet has H host bits, the total number of addresses in that subnet is $2^H$. However, two of these addresses are reserved: one for the network address itself and one for the broadcast address.

Therefore, the number of usable host addresses is $2^H-2$.

Our goal is to find the smallest value of H for which $2^H-2$ is greater than or equal to the number of hosts we need.

For example, if a department needs 25 hosts:

• A subnet with 4 host bits ($H=4$) gives $2^4-2=14$ usable hosts. Too small.
• A subnet with 5 host bits ($H=5$) gives $2^5-2=30$ usable hosts. This works. It's the smallest size that meets the requirement.

Since an IPv4 address has 32 bits total, a subnet with 5 host bits will have a prefix length of $32-5=27$. So, the optimal prefix is /27.

2. Building a Reference Chart

Constantly doing these calculations in your head is possible, but most network engineers use a mental or written reference chart. This is the "well explained" theoretical foundation you asked for, presented in a practical format.

The following video shows how to build and use a simple decimal-based chart to map host requirements directly to CIDR prefixes, without needing to work in binary.

Here is a summary of that information in a table format, which you can use as a quick reference. This is a powerful tool for any network planning task.

How to use the table: Find your host requirement in the first column. The CIDR prefix in the last column is your optimal choice.

3. Applying the Method

Now let's see this method in action. The next video walks through several examples, showing how to select the right prefix based on different host requirements. It provides a slightly different visualization that you might also find helpful.

This highlights a critical rule: always round up. If your requirement falls between two sizes, you must choose the larger one. Wasting a few addresses is better than not having enough for all your devices.

4. A Special Case: Point-to-Point Links

A common requirement in any large network is connecting your switches and routers. These "point-to-point" (P2P) links only ever need two IP addresses—one for the interface at each end.

Using our table, the optimal prefix is a /30, which provides exactly 2 usable addresses. This has been the standard for years.

However, modern networking offers an even more efficient option. Since there will only ever be two devices on a P2P link, a broadcast is technically unnecessary. RFC 3021 recognized this and allows for the use of a /31 prefix on these links.

• A /30 uses 4 total addresses to provide 2 usable addresses.
• A /31 uses 2 total addresses to provide 2 usable addresses.

Using /31s can save a significant number of addresses in a large network with many routed links. For your goal of building an architecture with L3 switches, this is a highly relevant technique.

The next segment of the video you just watched covers this topic perfectly.

5. Let's Practice

You've got the theory down. Now it's time to apply it. This is the core skill for this lesson.

Let's work through an example from a Cisco design guide.
Given Requirements:

• netA: must support 330 hosts
• netB: must support 6 hosts (P2P link)
• netC: must support 2 hosts (P2P link)

Determining the Prefixes:

1. netA (330 hosts):

   • Looking at our chart, 330 hosts is between the 254 hosts provided by a /24 and the 510 hosts provided by a /23.
   • We must round up.
   • Optimal Prefix: /23

2. netB (6 hosts):

   • Our chart shows that for 3-6 hosts, a /29 is the perfect fit.
   • Optimal Prefix: /29

3. netC (2 hosts):

   • For exactly 2 hosts, we can use a /30. If we want to be more efficient, we could use a /31.
   • Optimal Prefix: /30 (or /31)

This process of analyzing requirements and selecting a prefix is the first step in creating a full VLSM allocation plan.

Your Turn: Practice Exercise

Now it's your turn to perform this step. The image below shows a set of requirements for a company's network. Your task is to determine the optimal CIDR prefix for each network segment listed.

For each "Network" listed in the table (Headquarters, Inventory, Sales, etc.), write down the required number of hosts and the optimal CIDR prefix you would choose. Don't worry about the other columns (Network Address, Host IPs, etc.) for now; we will cover those in the next lesson.

Take your time and use the reference chart we discussed.

Conclusion

Excellent work. You have now mastered the first and most fundamental skill in VLSM design: translating a list of network requirements into a set of optimal CIDR prefixes.

Key Takeaways:

• To find the optimal prefix, you find the smallest power of two ($2^H$) that provides enough addresses for your requirement, keeping the $-2$ rule for usable hosts in mind.
• The CIDR prefix is then calculated as $32-H$.
• Using a reference chart makes this process fast and reliable.
• For point-to-point links, a /30 is the standard, but a /31 is a more efficient, modern alternative.

In our next lesson, we will build directly on this skill. You'll learn how to take the list of prefixes you've just determined and assign actual, non-overlapping subnets from a larger parent address block, following the "largest-to-smallest" allocation strategy we introduced previously.