This is the first post in a multi-part series covering the SovLabs IPAM Modules. In this post we will take a deep dive into some of the more common use cases we encounter with our customers as well as how we use the SovLabs Template Engine to dynamically set the correct IPAM profile on our blueprint. These posts are constructed from more of a solutions design point of view, rather than to be a step-by-step tutorial for setting up IPAM configurations (we have lots of those already at our blog page and on our support portal); what I hope to be able to communicate through these posts is how you can best design your solution to fit your specific use case.
I am starting with these less complex use cases because they will help to build some necessary foundational understanding which we will build on as we move to more advanced use cases in subsequent posts.
Sample Use Case 1 - General Purpose Environment Based Networks - Single Location
We run into many different use cases when working with our customers throughout the course of a proof of concept. Some of our customers have very simple network designs with general purpose networks that include machines of every different kind of purpose. In the following example, the customer has three different types of networks, each correlating to a different environment (Production, Test and Development) and all in a single geographical location. They may have multiple networks that each fit the same type of profile (e.g. 5 Production networks, 2 Test, and 1 Development), but any machine could technically land in any one of those networks that match the desired environment. With this type of environment we would typically create a single IPAM Configuration for each environment, and include all of the networks for each environment in that profile. When one network runs out of IP addresses, the module takes a “fill and spill” approach that would start to consume IP addresses from the next available subnet. It would look something like the diagram below.
The way that we would typically approach the application of the appropriate IPAM profile in this first use case is to set the SovLabs_IPAMProfile_nic0 property on the blueprint to reference the value that the user has selected for their environment similar to the screenshot below. The “” denotes that we are referencing another custom property set on the machine.
If you really wanted to get fancy, you could use the SovLabs Template Engine to do some string manipulation to achieve the desired result.
Sample Use Case 2 - General Purpose Environment Based Networks - Multiple Locations
The next sample use case is very similar to the first, they are still using environment defined subnets, but in this example, they have two datacenters, and depending on the datacenter selected the appropriate IPAM profile needs to be selected for each provisioned resource.
The way that we would typically approach a solution for this use case is to take advantage of the way that vRA propagates Custom Properties. The reservation selection process happens prior to requesting an IP address, so by the time we go to request an IP address we already know what datacenter the request is being routed to and are able to use that information in determining the appropriate IPAM Profile to apply.
First we want to create a custom property on each Compute Resource in the environment that references the datacenter that the Compute Resource is located in. We navigate to Infrastructure > Compute Resources > Compute Resources and then edit each Compute Resource, adding the “dcName” property and a value that corresponds to the datacenter where the cluster is located.
Then we can head back over to our blueprint and the SovLabs_IPAMProfile_nic0 property, setting the value to , which will concatenate the dcName (from the cluster that the machine is provisioned in) and Environment (from the user’s selection) custom properties to dynamically drive our provisioned resources to the correct IPAM profile.
Sample Use Case 3 - Application and Environment Based Networks - Multiple Locations
This final sample use case is more complex still. In this environment, rather than having general purpose based networks, the customer has separate tiers for web, app, and database servers. Each of those tiers has a respective network for each environment, and each datacenter has a representative network for each use case.
The simplest way to address this scenario, at least the simplest way to apply the appropriate profile, would be very similar to use case 2 above where we take things we know about the request that the user submitted and things that we know about where the machine will be provisioned to determine the correct IPAM profile.
In this post I have addressed three of the most common basic use cases that I have run into in customer environments, and how we typically address each of the use cases. However, I have found that in large organizations, networking, as well as the business logic behind it, can often be rather complex. In fact, I have encountered customers where every application was separated into its own network. SQL, Postgres, AD, SCOM, and Apache (as well as 50+ others), for example, all had their own separate subnets for each environment in each location. In this type of complex configuration, the methodology of creating a new IPAM profile for every network use case can increase the management overhead, as well as increasing the amount of required user inputs to create those configurations. In the next post in this series, we will be taking a look at use case 3 from a different angle; we will also cover how to address use case 3 using the SovLabs IPAM modules coupled with the Property Toolkit.