# CIDR Explained in Decimal Numbers

# CIDR Explained in Decimal Numbers

### Do you allocate IP addresses with CIDR but aren't quite sure how the math works? Here's a lesson for your cloud, container, and orchestration routing needs.

Join the DZone community and get the full member experience.

Join For FreeGet the Metrics Collection and Monitoring Essentials tutorial collection. A 4-part tutorial series from DigitalOcean.

If you work in the cloud, it is likely that you have used the numbers and slash that follow IP addresses. You might find documentation that points to something called CIDR. It is said to be a super helpful and awesome standard adopted to extend the life of IPV4.

But have you tried searching 'what is CIDR'? It is all jargon, all of it.

There is hardly any layman-friendly explanation of the term. Even Wikipedia managed to find a complex way of explaining it. And yet, it is something we use every day, especially if you are working with the cloud, containers, or container orchestration frameworks.

We use it t define networks when using Docker. We use it when we specify services and networks in orchestration frameworks like Swarm, Compose, Kubernetes, ECS, or GKE. We use it when we specify ingress/egress rules in an AWS security group. We use it when we create a subnet in AWS EC2, when we define VPCs, and when we define clusters. Even single IP addresses (range size 1), at times, are defined using CIDR notation.

I was wondering if CIDR could be explained without getting into binary number calculations or more jargon of classes or routing.

I found one.

CIDR is simply a way of specifying a range of IP addresses. In the cloud, we mostly deal with IPV4 addresses, so let us see how we can think of CIDR in an IPV4 context.

An IP address has four parts joined together by dots. Each part can have 2 ^ 8 = 256 values (between 0-255, both inclusive). In CIDR, we add a slash after the IP followed by a number between 1 to 32, both inclusive. These numbers are, in fact, a netmask specification.

Now, these 32 numbers can be divided into four groups of size 8, similar to IP addresses (groups being 1-8, 9-16, 17-24, and 25-32). Each group has an effect on the corresponding section of the IP address to generate a range. Let's look at the diagram below:

Now looking at the numbers in the groups, you can quickly tell which IPs can come as part of the range. For example:

99.123.43.64/8 --> 99.0.0.0 to 99.255.255.255

99.123.43.64/16 --> 99.123.0.0 to 99.123.255.255

99.123.43.64/24 --> 99.123.43.0 to 99.123.43.255

99.123.43.64/32 --> 99.123.43.64!

The size of the range decreases as this number goes up, 1 being widest and 32 being strictest. Simple enough?

Now, onto a slightly more complex part.

What about numbers that are not multiples of 8? You can certainly define something like: 99.123.43.64/18 or 99.123.43.64/5 or 99.123.43.64/27. But what would that mean? We have seen that each group of netmasks governs IP values (0-255) in its group (and the groups that come after it). What if we divided these groups further? Larger groups were with multiples of 8, so now we will divide the 255 numbers in 8 different ways using 8 powers of 2. Time to use a little 10th-grade math:

The seventh power of 2, i.e. 128 creates

*two*sub-groups: 0-127 and 128-255.The sixth power of 2, i.e. 64 creates

*four*sub-groups: 0-63, 64-127, 128-191, and 192-255.The fifth power of 2, i.e. 32 creates

*eight*sub-groups: 0-31, 32-63, 64-95, 96-127, 128-159, 160-191, 192-223, and 224-255.The fourth power of 2, i.e. 16 creates

*16*sub-groups: 0-15, 16-31, ..., and 240-255.The third power of 2, i.e. 8 creates

*32*sub-groups: 0-7, 8-16, ..., 240-247, and 248-255.The second power of 2, i.e. 4 creates

*64*sub-groups: 0-3, 4-7, ..., 248-251, and 252-255.The first power of 2, i.e. 2 creates

*128*sub-groups: 0-1, 2-3, 4-5, ... 252-253, and 254-255.The 0th power of 2, i.e. 1 creates

*256*sub-groups: 0, 1, 2, 3, 4, 5, ..., 253, 254, and 255.

With me so far? Now let us see how we can understand the meaning of intermediate numbers:

Step 1: Identify the larger group your netmask belongs to using the IP address diagram above. Call it the major group. Ex: /18 belongs to group 3 (17-24) and /30 belongs to group 4 (25-32)

Step 2: Deduct your netmask number from the higher bound of the group. Ex: with /18, you get 24-18 =

**6,**and with /30, you get 32-30 =**2**; this is your power of 2 (say**n**).Step 3: Now you can calculate the number of IPs that fall in this range by the

**n**th power of 2. Meaning when you specify /18, you have 2 ^ 6 = 64, and for /30, you have 2 ^ 2 = 4 possible values in the range.Now it's just a job of identifying which sub-group your number in the place of the major group fits in and you have the exact range of IPs that fit your CIDR. Ex: /18 means group 3 and a sub-group with power 6. So the number in the third group in an IP like 99.123.43.64 is 43, and it fits in first sub-group.

Let us look at some examples:

- 99.123.43.64/27
- 27 is in group 4 (25-32)
- There are 32 - 27 = 5 and 2 ^ 5 = 32 addresses. We pick from the 5th power sub-group.
- And the 4th group number, 64, falls in the 64-95 subgroup. So the range is: 99.123.43.64 to 99.123.43.95

- 99.123.43.64/30
- 30 is in group 4 (25-32)
- The power would be: 32-30 = 2, and there would be 2 ^ 2 = 4 addresses.
- And the range would be: 99.123.43.64 to 99.123.43.67

- 99.123.43.64/18
- 19 is in major group 3 (17-24).
- The power would be: 24 - 18 = 6, and there will be 2 ^ 6 = 64 possible values in group 3. Applying all possible values in group 4 for each in group 3 gets us: 2 ^ 6 * 2 ^ 8 = 16384 addresses
- And the range would be: 99.123.0.0 to 99.123.63.255

- 99.123.43.64/13
- 13 is in major group 2 (9-16)
- The power would be: 16 - 13 = 3, and there will be 2 ^ 3 = 8 possible values in group 2. Applying all possible values from group 4 and 3, we get 2 ^ 3 * 2 ^ 8 * 2 ^ 8 = 524288 addresses
- And the range would be: 99.120.0.0 to 99.127.255.255

I hope that clarifies it a bit!

(Disclaimer: The IP used in examples is a random value.)

Getting Started with Kubernetes: A Webinar Series brought to you by DigitalOcean

Published at DZone with permission of Nikhil Wanpal , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

## {{ parent.title || parent.header.title}}

## {{ parent.tldr }}

## {{ parent.linkDescription }}

{{ parent.urlSource.name }}