Mitigating Network Overlap

Note — I am not by trade a “networking guy”. However, I’ve seen my fair share of network designs. Take this with a grain of salt, but also ignore this at your own risk.

How do network architects develop the private network schema (the CIDRs organized to not overlap nor waste IP space) for an organization of sufficient size? The answer is certainly qualified, especially since organizations and products can make large and rapid changes over time, whereas networks have a certain gravity to them that makes them difficult to modify without the potential of significant impact.

AI Generated Image

Private Networks

What are private networks? Generally, they fit into the following predefined CIDR ranges: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. These can be used by any organization for its internal networks, as these are ignored by network switches in the public Internet. The challenge becomes how to further segment these predefined ranges (and in many cases, how to safely/efficiently reuse segments).

For more information on private networks, check out the Wikipedia page.

Options for Segmenting

One common way to use the three private network blocks is to designate one for each of three major groups of networks. The choice of how to group is often either functional (e.g. the purpose of the resources interfacing with the network such as virtual desktop instances or application virtual machines) or based on more physical aspects such as provider. It’s also not uncommon to segment by geographic region (e.g. 10.0.0.0/8 in AMER, 172.16.0.0/12 in EMEA, and 192.168.0.0/16 in APAC), but I would submit this is a poor choice as the sizes of the respective networks imposes unnecessarily incongruous scaling constraints on the regions; instead, regional segmentation should most likely be done within each private network, likely very near the top (e.g. 10.0.0.0/10 for AMER, 10.64.0.0/10 for EMEA, and 10.128.0.0/10 for APAC[1]).

Functional aspects to consider for network segmentation are departmental silos, specific layers of an architecture stack (e.g. web server, database, etc.), product applications, and customer type. Each of these have different implications depending on where they are in the segmentation for a particular organization. There is, to my knowledge, no perfect schema approach, but given a well understood organization (down to the personnel hierarchy), its products, its resources, and its third-party integrations, the choices where and how to split may become obvious. In other words, network architecture should largely match the organizational structure. This is nothing new or exciting, but it’s much easier said than done.

Often, the most typical (and perhaps “mathematically optimal”) approach is to attempt to select a segmentation that best balances the segments (like balancing a mathematical tree). If, for example, different department silos have wildly different network needs (i.e. one owns a massive cloud infrastructure, whereas the other manages virtual desktops for a small, embedded subcontractor team), then it may be more prudent to consider a segmentation that divides one or a few larger departments into chunks roughly the same order of magnitude as the smaller departments (or to consolidate the smaller departments, and further subdivide at a subsequent scope, etc.). It’s not necessary to make a fully symmetrical tree out of the networks, as long as the tree is roughly balanced, and the segments within are well utilized[2].

Activities That Impact Network Architecture

There are many types of business activities that impact an organization’s network architecture. Common examples include mergers & acquisitions, the expansion to new data centers, the choice to build a new cloud environment, almost any kind of migration event, data federation, new products or lines of business (or greenfield replacements thereof), changes to workforce and facilities, changes to certain service providers, and third-party integrations. It is unlikely that a business of a certain size sees none of these activities in a single year.

Networks evolve over time and even optimal decisions made today may not even be appropriate a decade later. That means the network schema developed to implement the datacenter likely won’t see the end of life for that data center. It’s also nontrivial to decide what even “optimal” means. Is it “optimal” to ensure a tight packing of IP addresses, leaving nothing unallocated within large contiguous ranges? Perhaps for some organizations with highly segmented and extremely expansive network needs. But something like that, which may be obviously important to some organizations, may not be an operational concern for others if the goal is to introduce software abstractions of generic network configurations, rather than perfectly packed IPs. Even within an organization, it may be appropriate to develop a mix of approaches.

As mentioned above, one common and notable example is the decision to adopt (or as I like to say, occupy) a cloud provider. This could be with the intent to move one’s entire operation to said cloud provider or to enjoy whatever benefits to your existing operation are promised by the provider. Whatever the reason, this could have a significant impact on the virtual networks. Do we need to fully replicate the same network schema we have today, but in the new provider? If so, are we duplicating the network ranges (the CIDRs), or offsetting by a particular maskg.? E.g. if all of our virtual networks for application VMs are found to be contained within the 10.0.0.0/16 range, do we match them in their corresponding ranges in e.g. 10.1.0.0/16 or in 10.128.0.0/9 or even 10.128.0.0/10? The differences may seem arbitrary at the time of selection, but no decision, even with merit, is without its technical implications. This risk must be mitigated as the cost of making network changes after components are “in production” is much greater.

Another, less common phenomenon is the decision to peer or otherwise connect an internal virtual network with a 3rd-party’s virtual network. This would most typically be done between the same or similar network constructs such as those provided by the same cloud provider or the same co-location service. Without going into the DMZ/Trust-Untrust aspects (which absolutely must be considered for an implementation), there is a risk of the third-party’s network clashing with yours, especially in a heavily segmented hub-and-spoke configuration. Some providers will complain if you try to include a network that overlaps directly, but may not catch transitive peering problems. A common solution preferred by many organizations is to use a dedicated VPN (either directly with the third-party, or between one’s network and a network designated specifically to peer with the third-party; this can also help to address the security concerns glossed over previously).

Another example mentioned above is that of mergers and acquisitions. These are especially cumbersome, as it is very unlikely that both A) the private network allocations align, and B) there are no networks that overlap between the two firms. This topic is complex and takes many forms; it will be covered in more detail in a subsequent post.

Reusing Segments — An Overview

Clearly, there may come a time where it’s determined that the most appropriate course of action is to integrate private networks with clashing CIDRs. Regardless of the “why”, we need an answer to “how”.

There are a few options and a reasonable architecture for a massive organization may include more than one:

• Network Address Translation (NAT) — “Translates” the outbound traffic from the originating IP to a designated IP of the NAT

• Virtual Private Network (VPN) — Similar in function to a NAT, but encrypts the traffic

• Internal Domain Name Server (DNS) — Routes traffic using an alphanumeric domain name to a “next hop” (either the destination itself, or the next DNS in the series)

• Second Network Interface Controller (NIC) — Essentially creates an alternative channel, (mostly) avoiding clashing CIDRs among the two channels

• Internet Protocol version 6 (IPv6) — A newer version of the Internet Protocol which has a 128-bit address space, versus IPv4’s 32-bit address space

This is by no means intended to be exhaustive, but merely a list of common approaches. This area can be a bit dense, so another follow up post will go into further detail on these approaches.

Example of Private Network Segmentation

All things considered, given a hypothetical “large multinational corporation” under ideal circumstances, a successful network address schema might first group components into internal/hr-related vs. product-oriented components, with the latter further segmented into “primary” networks (those that carry traffic between the functional portions of products and services and to and from the public internet) and “secondary” networks (these can take several forms, including overlay networks for container orchestration or second network interfaces used for “back of the house” traffic such as for logging and monitoring[3]).

After the initial segmentation, it is likely most appropriate to split the application networks into regions and environments (e.g. by dev, test, and prod), depending on how even the markets between the various regions are, and then the other at the next level of segmentation. Next, segmenting by application layer (e.g. web server, database, etc.) may be most prudent[4]. Finally, networks can be split by product/application, which seems to be most common.

An additional recommendation would be to intentionally leverage “second NIC networks” (described above) wherever east-west traffic is required. Logs (including metrics) and automated remote operations are both common types of east-west traffic and are both appropriate use cases for this approach. The networks that support east-west traffic will need to be treated as a completely separate set, and can begin its segmentation from the top.

Conclusion

Hopefully this appropriately categorizes the challenges faced by network engineers as business needs introduce new complexities. I hope it also successfully illustrates meaningful approaches and technologies for mitigating issues.

We’ve reviewed typical approaches and patterns with which to split private network ranges to best accommodate growth and scale. We’ve also discussed various common ways in which networks can become overlapped. We then took a quick glance at various ways to integrate private networks in such cases. Finally, we considered a hypothetical network address schema that follows a normal approach.

Check out cidrclash.com today and don’t let clashing networks sneak up on you!

---

Footnotes:

[1] And then perhaps 10.172.0.0/10 for operations teams.

[2] I won’t offer a definition of what “well utilized” might mean; however, the sentiment is that the segments aren’t arbitrarily chosen such that many segments are severely underutilized. That being said, forecasting network needs can seem about as nuanced and volatile as the weather or stock market, so it is necessary to employ high quality judgment.

[3] We’ve mentioned this as a way to ignore overlaps, but under ideal conditions and perfect knowledge/forecasting (and for the sake of everyone’s sanity), it is best to avoid overlaps.

[4] There may also be entire stacks, teams, and departments that get a block of IPs for their purposes, such as for an internally hosted platform.

This article was originally published on Medium on 01/13/2025