After spending a lifetime working in networking, I can tell you that IP addresses matter!
A well thought out IP plan you should tell you right away, what, where, and how important a resource is by looking at the 4 octets of its IP address.
Now I understand that network topologies are incredibly unique and there is no "one size fits all" IP address plan. This is just an example to help you think holistically about IP addressing plans for your cloud.
First, let's set the stage... In this example scenario we will imagine a mid-sized company with a requirement for a primary cloud presence in the West and a secondary cloud presence in the East.
The company estimates they will have approximately 200 endpoints per region. These end points will be divided up amongst Virtual Machines, Database Servers, App Services, and other assorted cloud resources.
Creating the framework...
The regional supernet should be a large block of IP addresses that we intend to reserve for an entire region. In this case we can use the second octet of the address to mark the region.
Going forward, when we see an IP address with a second octet of 100 we will automatically know that it is in the West and 200 in the East.
Acendri-Solutions West - 10.100.0.0/16
Acendri-Solutions East - 10.200.0.0/16
We need to look at our requirements and make choices based on how large our cloud footprint will be. How many different types of applications are in the DevOps lifecycle that we need to partition IP space for?
In this example, we will plan for a fairly standard 3 phase DevOps lifecycle:
Development -> Testing -> Production
With entire IP space from the Supernet framework available we can carve out large IP blocks for each infrastructure segment of our DevOps life cycle. We can use /18 CIDR subnet boundaries for each segment if we want even sized address ranges.
10.x.0.0/18 - Subnet 0 to 63 - Infrastructure Services
10.x.64.0/18 - Subnet 64 to 127 - Production Services
10.x.128.0/18 - Subnet 128 to 191 - Testing Services
10.x.192.0/18 - Subnet 192 to 254 - Development Services
Using this address plan, we can roughly estimate how important a resource is based on how low its address is.
For example, if I received an email alert late at night for a server outage with an address of 10.200.235.x, I would automatically know that the server is in our secondary data centers development range and go to bed without thinking twice about it. Conversely, an alert from the 10.100.1.x space would indicate a regional internet facing firewall outage in the primary cloud region.
I'll say it again, IP addresses matter!
Continuing further down this address scheme, let's begin by allocating the first block.
Creating the Hub network...
If you read my last article, Azure Hub-Spoke Virtual Network Design Best Practices you would know that a well built cloud network has separated virtual network spokes for almost all purposes. This forces the cloud into a zone based security architecture that routes all traffic to a centralized firewall in the hub for inspection before routing it back to the spokes.
The Hub network landing zone should be purpose built and small. In our example, the enterprise sized company plans to use third party NVA firewalls and load balancers.
Because of these requirements we will need between 8 and 15 subnets for the Hub network. Let's create virtual networks of /20 size.
EnterpriseHub-West-Vnet - 10.100.0.0/20
Firewall-Untrust Subnet - 10.100.1.0/24
Firewall-Trusted Subnet - 10.100.2.0/24
LoadBalancer-Untrust Subnet - 10.100.3.0/24
LoadBalancer-Trusted Subnet - 10.100.4.0/24
RouteServerSubnet Subnet - 10.100.5.0/24
GatewaySubnet Subnet - 10.100.6.0/24
AzureBastionSubnet - 10.100.14.0/24
NetworkManagement Subnet - 10.100.15.0/24
EnterpriseHub-East-Vnet - 10.200.0.0/20
Firewall-Untrust Subnet - 10.200.1.0/24
Firewall-Trusted Subnet - 10.200.2.0/24
LoadBalancer-Untrust Subnet - 10.200.3.0/24
LoadBalancer-Trusted Subnet - 10.200.4.0/24
RouteServerSubnet Subnet - 10.200.5.0/24
GatewaySubnet Subnet - 10.200.6.0/24
AzureBastionSubnet - 10.200.14.0/24
NetworkManagement Subnet - 10.200.15.0/24
Creating the Identity Subscription Network...
The Identity network should be small, with space for a subnet to contain domain controllers. If we only plan on using a single tier of domain controllers across the enterprise, we can keep the Identity network sized to a single subnet or two. However, if we want to run separate domain controllers per DevOps lifecycle, we can create a virtual network with room for 3 or more subnets. Let's create the Identity network with the next available block of the Infrastructure Services supernet.
Identity-West-Vnet - 10.100.16.0/22
Production-DC-Subnet 10.100.16.0/24
Testing-DC-Subnet 10.100.17.0/24
Dev-DC-Subnet 10.100.18.0/24
Identity-East-Vnet - 10.200.16.0/22
Production-DC-Subnet 10.200.16.0/24
Testing-DC-Subnet 10.200.17.0/24
Dev-DC-Subnet 10.200.18.0/24
Creating the Lifecycle Environment IP Address Plans...
The Production and Testing lifecycle environments should be identical copies of each other in as many ways as possible so that the applications deployed into the test environment will provide measurable results before the same code is deployed into production.
Development is an area where having an IP framework that is similar to production and testing is a good practice, it can also be a lot more fluid. Needing to be flexible and responsive to the needs of the development team.
In our example architecture, we will follow an IP format that goes like this:
10.x.(y+z).0/nn
x = Region / y = DevOps lifecycle / z = Virtual Network / nn = Network Mask Size
So for West US region Production environment virtual network segments, we will start with 10.100.64.0/24 and count up from there.
Network Purpose
10.100.64.0/24 App1Name-WebServer01-vnet
10.100.65.0/24 App1Name-MiddlewareServer01-vnet
10.100.66.0/24 App1Name-DatabaseServer01-vnet
10.100.67.0/24 App1Name-Storage01-vnet
10.100.68.0/24 App2Name-AppService01-vnet
10.100.69.0/24 App2Name-FunctionApp01-vnet
10.100.70.0/24 App2Name-AzureSQL01-vnet
10.100.71.0/24 ...
The size and complexity of these virtual networks will be different for every company.
In this example address plan, it is important to understand that we will have a limit of sixty-four /24 networks with 255 hosts per DevOps environment. This should suffice for a mid-sized company with requirements to support a few main applications. However, we may need to be more flexible for the large enterprise.
We can double or triple the capacity of this address plan by shrinking the subnet sizes but will need to be more conscious of the subnet mask and gateway address for our endpoints.
From here we can duplicate this IP scheme into Testing by increasing the third octet to 128.
Network Purpose
10.100.128.0/24 App1Name-WebServer01-vnet
10.100.129.0/24 App1Name-MiddlewareServer01-vnet
10.100.130.0/24 App1Name-DatabaseServer01-vnet
10.100.131.0/24 App1Name-Storage01-vnet
... etc
Okay Great... Got Any Other Bright Ideas?
Well, if we wanted to have larger IP space that is a more identical replicate of each other we could play with the second octet instead for our lifecycle environment supernets. The downside to this IP plan is that you would need to inject several /16 routes for connectivity to your on-prem network. However, this might not be that big of a problem if you are using ExpressRoute and dynamically inject the cloud advertised BGP routes into the on-prem routing tables.
Azure West - 10.100s
10.100.0.0/16 - Hub
10.110.0.0/16 - Prod
10.120.0.0/16 - Testing
10.130.0.0/16 - Dev
Azure East - 10.200s
10.200.0.0/16 - Hub
10.210.0.0/16 - Prod
10.220.0.0/16 - Testing
10.230.0.0/16 - Dev
However, if summarizing is of more importance to you, chop out your regional blocks from large CIDR subnet boundaries. This might be important for a large enterprise who needs to route hybrid cloud space into a large and diverse on-prem network.
Azure West - 10.128.0.0/12
10.128.0.0/16 - Hub
10.129.0.0/16 - Prod
10.130.0.0/16 - Testing
10.131.0.0/16 - Dev
Azure East - 10.224.0.0/12
10.224.0.0/16 - Hub
10.2250.0.0/16 - Prod
10.226.0.0/16 - Testing
10.227.0.0/16 - Dev
The Conclusion
In summary, there are many ways to chop up your cloud IP space. I hope this article was helpful in highlighting how holistic IP planning can help create networks that communicate to your IT staff where, and what something is by just looking at the IP.
Thanks for reading.