Solving IP Overlap in Multi-Cloud

Private IP addressing is one of the most useful features of the protocol. This address space is designated for unregulated use within a local scope—within an organization, not connecting across the Internet—and has brought the freedom to create large scale internal networks.

However, there is a price for this flexibility: when trying to connect two previously separate private IP networks, some of the same IP addresses may have been used in both networks. Since IP addresses must be unique within each network or routing domain, these duplicates cause unstable network access into and out of the overlapping areas. While there are traditional workarounds to reduce the impact, F5 Volterra provides a way to avoid the problem altogether.

Why Overlap is a Problem

When two different parts of a network overlap and use the same IP subnet address range, there are two main problems that occur. First, those two subnets cannot communicate with each other at all, since none of the devices will know the address isn’t intended for a local endpoint. If those subnets are both client-only, full of users, this problem may be simple to fix, but if one subnet contains network services, those services will be completely unreachable by the other. Additionally, IP overlap affects all traffic going to those subnets from anywhere else in the network. Since routers in the network exchange information, both subnets will be advertised, but from two different locations. Connections may be sent to the wrong location at any time, even for connections that were successfully established.

The Modern Influx of IP Overlap

The most common cause of IP overlap in well-managed networks is connecting or merging two previously separate networks. The scenario is easy to imagine when two organizations merge, especially if IT in each organization used a similar address allocation convention, such as 10/8 for endpoints and 172.16/12 for infrastructure. However, overlap is becoming increasingly common when connecting to one or more clouds. The largest individual networks are at hyperscalers like public cloud providers, and they use private IP addressing by necessity. When every server is host to large numbers of VMs, or a larger number of containers, a single row could consume an entire /16 network. As demand for cloud grew, so did demand for access, expanding from client-site VPNs to site-site VPNs, multi-cloud networking products, and even direct WAN connections to cloud data centers. Site-site VPNs and WAN links effectively connect portions of the cloud network to the customer’s network, and, since most customer networks are also built on private IP addresses, IP overlap increasingly is the result.

Patching IP Overlap vs. Solving IP Overlap

As distributed modern apps become more common, so will app to app connections, such as hybrid cloud, cloud to cloud, and edge to cloud. Scalable architectures will require a method of dealing with IP overlap that can cleanly be automated. Many network admins turn first to NAT—after all, NAT is what allows private IP addresses to connect to the public Internet. However, NAT merely shifts the problem instead of solving it: the abstraction does not extend inside the subnet, so there is a burden shifted onto applications and services to deal with edge cases (like remote networks with the same subnet range). Additionally, NAT obscures visibility by creating skew between events gathered inside vs. outside the subnet. The ongoing operations costs introduced by NAT are only justified when other options—such as renumbering—are worse.

F5’s Volterra VoltMesh provides a clean solution to IP overlap. Overlap is only an issue when connections rely on L3, so VoltMesh separates the L3 addresses from the transactions at L4 or L7, using the same application delivery methods F5 customers have relied on for 25 years. However, VoltMesh adds a unique feature: because its functions are distributed, IT can choose any IP address anywhere in the mesh the deliver the application, and because its functions are integrated, full end-to-end visibility is maintained for networking, security, and even the application. Using VoltMesh, it is even possible to deliver a remote service—whatever its real IP address—into a local subnet, with a local IP address, so there are no network changes required at all: no NAT, no firewall pinholes, and no routing changes. VoltMesh provides full control and full visibility without network disruption, for the cleanest possible IP overlap solution.

Networks continue to expand and interconnect in the multi-cloud era, enabled by private IP addressing, which means that IP overlap is going to continue to be a problem as long as the focus is on legacy connectivity. Whether on-prem or between clouds, F5 Volterra VoltMesh is able to deliver services safely by decoupling applications from the network layer, providing reachability without connectivity, and ensuring clean separation to keep private networks private.

For additional, please visit Journey to the Multi-Cloud Challenges on F5’s DevCentral and Get Complete Multi-Cloud Management with F5.