Many organizations are experiencing challenges when they shift the focus of their application infrastructure from on-premises data centers to public clouds. Multiregion, hybrid cloud, and multicloud architectures are incorporated into the logical design of their cloud networks. The drivers of this architectural change include the following examples:

  • Acquisition of a new company to expand current product capabilities and solution features set that result in multiple disparate networks and a varying degree of cloud adoption and deployment across the newly acquired company

  • Customers, partners, and employees are physically dispersed throughout the world. A multiregion design enables customers, partners, and workers to use cloud resources from the region most convenient for them. To access cloud-based apps and resources, users first enter the cloud service provider’s infrastructure and then navigate across it, regardless of where they reside.

  • Some cloud-based applications are only available in specific regions of the cloud service provider’s network. Some of these limitations are caused by the service provider business model or deployed to cater to specific requirements, such as government restrictions.

  • A high level of availability and redundancy is required for applications that require disaster recovery capabilities. Multiregion fault tolerance and high availability in every critical infrastructure architecture and network design, availability, and resilience are design pillars to consider in the planning process.

The problem of overlapping IP addresses

Because of the inherent architectural change, new challenges emerge in unexpected ways because of the rapid industry developments happening in cloud infrastructure. One network-related example is the challenge produced by overlapping IP addresses. As a result of this new hybrid and multicloud environment, no centralized authority is responsible for allocating dedicated network spaces, IP addresses and subnets. No standard process for doing so exists either. As a result, businesses of all sizes find themselves in circumstances where their applications can’t communicate with newly acquired company resources, data resources, customer networks, or other applications because IP addresses or subnets are overlapping on the network.

When the same IP address is assigned to more than one application on the same network, this setup is called overlapping IP addressing. The more common scenario is mapping the same range of IP addresses implemented on multiple networks. Although feasible, this problem doesn’t usually manifest itself within an organization’s own network. When two networks with overlapping IP addresses or subnets (at different organizations) attempt to connect to each other, the issue arises from the overlap.

This blog post describes how the overlapping IP address problem can occur and the steps you can take to resolve the problem on your own using Aviatrix, a solution available in the Oracle Cloud Marketplace. We also offer another method that’s natively available.

Overlapping subnets connection utilizing NAT virtual machines

The solution described should be utilized as a temporary solution. Every network address translation (NAT) solution includes overhead in the configuration and maintenance and may impose in performance penalty and some degree of latency. The final solution commissions a unique, non-overlapping IP address space for every end consumer. For more details of this implementation, see ISV Solutions Architecture – overlapping subnets communication using NAT VMs.

Using the Aviatrix Gateway mapping solution

This solution uses the following steps:

  1. Deploy Aviatrix from Oracle Cloud Marketplace.

    A screenshot of the Aviatrix listing in the Oracle Cloud Marketplace.

  2. Configure all the necessary credentials to run the Aviatrix Controller with your Oracle Cloud Infrastructure (OCI) account.

    A screenshot of Aviatrix Connector create account screen.

  3. Create a gateway for OCI and define SNAT and DNAT as required.

    A screenshot of the Aviatrix gateway configuration page with fields selected.

  4. Set up Site2Cloud.

    A screenshot of the Aviatrix Site2cloud setup page showing the fields selected.

Conclusion

You can deploy the Site2Cloud and transit gateway in countless use cases, ranging from very complex network topology to scenarios with on-premises data centers and multiple cloud providers with overlapping IPs! To help with the building and planning, I found MCNA EP 15: Advanced NAT In The Cloud With Aviatrix useful for reference and testing purposes. Say goodbye to IP overlapping, and happy testing!