How to Choose a CIDR Block for a Private Space in Anypoint Platform

If you’re creating a Private Space in MuleSoft’s Anypoint Platform and are unsure about what a CIDR block is or how it affects your IP address range, we can help you understand. A CIDR block is a crucial parameter and the first step toward extending your network to Anypoint Platform. 

CIDR block definition

CIDR stands for Classless Inter-Domain Routing, which is an IP address allocation method that enhances data routing efficiency. CIDR notation is used in IP addressing to define a range of IP addresses.

What is an IP address? 

To understand a CIDR block fully, we need to understand IP addresses. An IP address is the numerical representation of a location in a network. Similarly to how your phone number identifies your cell phone, your IP address identifies your device, your server, and your network interface. Computers only understand binary numbers (comprised of zeros and ones), therefore an IP address is just a sequence of zeros and ones. An IP address uses a combination of 32 zeros and ones, 32 bits. 

Humans, however, need another format. That’s why that binary number is split into four blocks or bytes and each block is represented with a decimal value. Each decimal number goes from 0 to 255 (decimal representation of eight 1s). Because of that, you always see an IP address as a combination of four decimal numbers, something like: 192.168.1.1. 

Creating a CIDR block for your Private Space  

Whether you’re well-versed or need a refresher, we need to know what a Private Space and Private networks are before discussing how CIDR blocks are set up, which is crucial for configuring these networks.

• Private Space: Think of this as your own private corner of the internet. This is how you extend your company’s network to MuleSoft’s Anypoint Platform. It is a virtual, private, and isolated logical space in CloudHub 2.0 to run your apps in. You can create multiple private spaces either in the same or different regions.  
• Private Network: When setting up a private network, you assign a range of IP addresses for applications within your private space to utilize, specify the region in which they will operate, and optionally designate internal DNS servers to handle requests for custom domains. You can configure multiple private spaces within a single region, allowing for the creation of distinct and isolated networks for different environments, like development or staging, in addition to the production environment.

CIDR block sizing

The size of a Private Space is determined by the CIDR block. When you create a private space, you must specify the CIDR block. For Private Spaces, the size of this CIDR needs to be a number between 24 (256 IPs) and 16 (65,536 IPs). Having a short block might cause your deployment to run out of IPs, meaning it won’t be able to deploy apps in the Private Space. From that perspective, setting your VPC size to the maximum CIDR block would be the best solution.

However, the moment you connect a Private Space to your Private Network using Anypoint Virtual Private Network or Transit Gateway Attachments, the CIDR block will become part of your internal network and consume private IP addresses from your internal addressing space. It’s important not to oversize your Private Space as it will take out more IPs than necessary from your internal network.

For many organizations, if you consider the amount of SaaS solutions that require a private connection, it becomes a challenge to reserve big CIDR blocks for all of them. You can’t resize or change the CIDR block after you create a Private Space. For this reason, ensure that you correctly anticipate your requirements before configuring this parameter.

To further clarify, here’s a table with CIDR block sizes and their corresponding number of IP addresses:

How to estimate the number of IPs needed for your CIDR block

Considering the above, how do we estimate the number of IPs we need for our Mule deployment? Start from the number of applications you’ll deploy onto that Private Space. The key is to understand that there’s not a one-to-one relation between apps and IPs. It’s likely that one application will consume more than one IP. Here are the key concepts to understand to do a proper estimation for the CIDR block:

Number of workers 

A Mule app is deployed to one or more workers. Every worker gets its own IP address, so an app deployed to one worker will get one IP and the same app deployed to four workers will get four IPs 

Horizontal scaling and high availability

You need to estimate how many workers your app needs. There are mainly two reasons to add more than one worker to your app:

• Horizontal scaling: Some apps, due to their type of processing, require more than one worker to distribute the load between the workers and get better performance.
• High availability: If your app is critical, you need to add additional workers so if one worker fails, the app can continue serving requests.

Fault tolerance

Redundancy is a critical technique for achieving fault tolerance in CloudHub 2.0. By providing multiple availability zones, CloudHub 2.0 can deploy redundant resources across different zones. In the event of a failure in one zone, traffic can be seamlessly redirected to another zone, ensuring high availability of services. Providing more than a worker for an app will give fault tolerance at the worker level, but if we require fault tolerance for the whole region, we need to provide one worker per AZ.

Zero downtime deployment 

Zero downtime deployment is a deployment style that allows CloudHub to deploy new versions of an application without causing any interruption to the consumers of the application. The goal here is to be able to quickly make changes to the environment without impacting the SLAs. 

With this technique, we can deploy a new version of our app or update the runtime with no service interruption. It’s also useful if you need to scale your app vertically or horizontally. Zero downtime leverages a side-by-side deployment. For any of those operations, CloudHub starts up a new worker with the new version of the app and keeps both workers (the new and the old one) until the old one is removed and the new one remains. 

In this process, the new worker will require a new IP; for a short time, you will have two workers and two IPs running. So zero downtime affects the required size of your CIDR block. You need to have enough free IPs in the IP range of your VPC so that you can duplicate the number of IPs assigned to existing apps when a bulk update happens. A few must-answer questions are:

• How many apps would you be updating in parallel?
• Do you need to update your apps in groups?
• Do you update your runtimes periodically? How many different versions of the mule runtime do you keep in your deployment?
• How does security and continuous patching affect your apps?
• What type of traffic do you have for your apps? Is there a group of critical apps in your deployment that you typically scale vertically or horizontally to accommodate peaks of traffic?

Answering all these questions gives a better understanding of the block of IPs you need to maintain unused in your CIDR block for zero downtime operations.

Number of environments

In practice, software applications are typically deployed across multiple environments, with at least two: one for production and another for non-production. It’s also not uncommon to have multiple non-production environments. When determining the appropriate CIDR block size, you need to consider the number of environments your applications are expected to be deployed on.

Considerations

When specifying CIDR blocks, ensure that they:

• Are from a private IP space
• Don’t overlap with any other CIDR blocks assigned to your other private spaces
• Don’t overlap with any CIDR blocks in use in your corporate network

You can’t use the following reserved CIDR blocks:

Extend your network  

Because some addresses are reserved for fault tolerance, infrastructure, and zero-downtime, CIDR block sizes are unique to an organization. Note that the size of the block does not limit the number of IPs that your apps can use. Now that you’re informed, all you have to do is plan ahead and get the number of apps + number of workers per app. The rest? It’s just math.