3 Ways Generative AI Will Help Marketers Connect With Customers
3 min read
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 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.
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.
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.
To extend your network to Anypoint Platform, create a private space (a virtual, private, and isolated network) hosted in CloudHub 2.0 to deploy your apps to.
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:
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:
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
You need to estimate how many workers your app needs. There are mainly two reasons to add more than one worker to your app:
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 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:
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.
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.
When specifying CIDR blocks, ensure that they:
You can’t use the following reserved CIDR blocks:
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.
Get the latest articles in your inbox.