Demystifying CIDR notation
What is a CIDR block and how it is appropriated
If you have been around networking at all, or really anything involving computers, there is no doubt you have heard the terms CIDR and CIDR notation at some point. You probably have an idea that it has to do with ranges of IP addresses, but if you are anything like me it takes a while to wrap your head around how the address ranges are actually created, and how many available IP addresses can be available in a range.
There are quite a few rabbit holes you could go down from a networking perspective that involve IPv4 vs IPv6, when to use specific address ranges, binary math, subnet masks, etc. But for the sake of conceptually understanding what is going on here we will abstract a lot of that and focus more on what a CIDR block is, and some easy ways to define a range of IP addresses. Subsequently I will give you a tool you can use in conjunction with CIDR notation that will make your life a lot easier.
CIDR stands for Classless Inter Domain Routing. In other words, it is a way of assigning IP addresses to a host so that they can be found over the internet and/or within a subnet. With all the millions upon millions of computers out in the world an IP address is a way to identify a specific computer, or computing instance.
What many companies will do to keep their computers easier to find and identify is assign all computers within their network IP addresses within a specific range. In slightly more technical terms, they will utilize CIDR notation to create a CIDR block. Before we look at how that would work and some examples you want to keep in mind the suffix of CIDR notation.
The suffix in CIDR notation can be a number between /0 and /32, where 0 represents the largest amount of IP addresses you could have and 32 relates to one single address. To make determining the number of addresses in a range easier, I would recommend using something like cidr.xyz. As a simple example, a notation of 0.0.0.0/0 refers to any traffic from anywhere over the internet, and 1.2.3.4/32 would only refer to the IP address 1.2.3.4.
Let’s say your company decides to move to AWS and test out a smaller subset of their application. You have 2 subnets, one will be public for users to connect to and one will be private where your database resides. A simple visualization for this is below.
Because this is a test environment, you do not need to allocate a ton of IP addresses. So you decide for the public subnet you will use 10.0.0.0/24, and the private subnet will use 10.0.1.0/24. If you enter those notations into cidr.xyz as linked above, you will see that each of them could have up to 256 different IP addresses that could be used within each subnet. Relatively easy to understand right?
There are a couple catches that you should be aware of though that you will need to keep in mind when allocating IP addresses:
- You can’t have overlapping IP addresses in multiple subnets in the same VPC ( In the example above put in /23 for the notation on the public subnet and you will see they start to overlap).
- The first 4 IP addresses and last one in a range are reserved by AWS. So in our example above in each of those ranges you would actually only have 251 available IP addresses that you could use.
To tie up a loose end, using the public subnet IP range above as an example, here is what AWS uses those reserved IP addresses for:
10.0.0.0 -> Network address
10.0.0.1 -> AWS routing address
10.0.0.2 -> AWS DNS address
10.0.0.3 -> AWS Future use
10.0.0.255 -> Broadcast address
So as you can see determining a range of IP addresses is not very challenging. Use a tool like cidr.xyz to do it for you to save yourself time, just remember to not have overlapping IP addresses and plan enough space to include the reserved IP addresses.
Like I mentioned earlier we abstracted a lot of the finer details of networking to get a better idea of what CIDR notation is and how organizations will use it to appropriate IP addresses within CIDR blocks. Hopefully it was helpful, and as always best of luck on your continued journey in cloud computing.
