Creating a OneFuse IPAM Policy

Caution: Articles written for technical not grammatical accuracy, If poor grammar offends you proceed with caution ;-)

OneFuse IPAM policies have some special qualities that make managing IPAM integrations very easy, flexible, and portable.  IPAM policies in OneFuse define the network or networks they represent abstracted from the actual IPAM provider.  This offers many benefits over network definitions that are tightly tied to a specific provider.  This allows for the use of more than one provider in the environment, it also allows for easy migration from one IPAM provider to another.

While being able to use more than one provider, or easily switching between providers in an environment is on its own valuable, IPAM policies within OneFuse offer even more benefits.  Below is a list outlining some of the features and value offered with the OneFuse IPAM Module:

  • Switch between IPAM providers
  • Consume multiple IPAM providers in the same environment
  • Define multiple networks in an IPAM policy
  • Normalize networks across cloud technologies
  • Dynamically drive network placement
  • Scenario-based overrides for IP configuration attributes (subnet mask, gateway, DNS settings, etc.)
  • Drive advanced DDI vendor features such as extensible attributes, custom fields, views, record types, etc.
  • Consume IPAM policies across platforms (vRA7, vRA8, vRA Cloud, Terraform, etc)
    • Allow for upstream providers to drive network assignment, e.g. using vRA8 constraint tags
  • Standardize network consumption across environments

In this article we are going to walk through creating a simple IPAM policy that will later be used to show how OneFuse IPAM policies can be consumed within upstream platforms.  In future articles I will cover more advanced topics related to the features listed out above.

IPAM Considerations

  1. Which IPAM provider are you currently using? OneFuse supports multiple providers. For a list of current providers please visit the OneFuse IPAM Module documentation page.
  2. What platform(s) will you be using? vSPhere, AWS, Azure, GPC, etc. OneFuse can support all platforms through integrations with its upstream providers such as vRA7, vRA8, vRA Cloud, Terraform, Cloudbolt, etc.
  3. How do you determine what network a particular workload or service should be placed on?


  • A supported IPAM provider and version.  See the OneFuse IPAM Module documentation page for supported providers and versions.
  • Service Account with appropriate permission.  See documentation for details.
  • Information related to the networks you wish to create IPAM policies for for example:
    • Network –
    • Subnet –
    • Gateway –
    • DNS Servers
    • Network Name in the consumption platform – dvs_vsphere_172_10_1_0_24
    • DNS Suffix
    • DNS Search Suffix

Tasks to Complete

  1. Create OneFuse Credential for use with the IPAM EndPoint
  2. Create a Module EndPoint for your IPAM provider
  3. Create IPAM policy

Creating a OneFuse Credential for use with the IPAM EndPoint

The first thing you need to do is create a credential for the Service Account that will be used to communicate with your IPAM provider.

  1. Select “Module Credentials” from the menu on the left.
  2. Next select “Create” on the “Module Credentials” page.
  3. In this example I will be using “Infoblox” and my IPAM provider, but you can select the “Endpoint” type for whichever supported provider you are utilizing. Input name, select endpoint type, provider the username, password and select “Create”.
  4. You will then see your created credential listed.

Create a Module Endpoint for your IPAM provider

Now that the “Module Credential” has been created we can go ahead and create the “Module Endpoint.  This endpoint will be specific to the IPAM provider instance you would like to integrate to with OneFuse.  If you have multiple instances you can create multiple endpoints to connect them all to OneFuse.  It’s also important to note that the endpoints have slight variants to account for differences in the specific provider.

  1. Select “Module Endpoints” from the left menu.
  2. On the “Module Endpoint” page select “Create” and then choose your IPAM provider for the list.
  3. On the “General” page give your endpoint a name, select the Version, enable SSL if in use, input the FQDN (or IP) and port for your provider, select the credential you created in the previous section and then choose if you want to to communicate in single or multi-threaded fashion. Once complete select “Next: IPAM” from up above.
  4. This example is specific to Infoblox and will vary slightly between providers. For Infoblox you will need to provide the “Network View” that you would like to utilize. Next you may wish to customize the “Template”. For the most part you will not need to modify this outside of updating the “comment” section. Click “Select:DNS” once complete.
  5. One on the DNS page you need to set the “DNS View”, this again is specific to Infoblox and may vary for other providers. If needed you can adjust the “Templates” for Host Records, A Records, and PTR records. Like the IPAM section most of this will not need to be updated aside from customizing the “comment” section.
  6. Once completed select “Create” to create the IPAM Endpoint. You will then see the new endpoint in the list of endpoints.

Creating an IPAM policy

Now that we have an IPAM Module Endpoint created we can now create an IPAM policy. If you have followed along or read my article on Creating a OneFuse Naming Policy, I mentioned how policies get consumed from OneFuse. With naming most often there may only be one policy but you can have as many as you need. With IPAM you may have more than one.

  1. Select “IPAM” from the “Home” screen or by expanding “Modules” on the left menu.
  2. Select “Create” from the top of the IPAM page.
  3. One the first page of the IPAM policy creation we need to input some information. They are broken out below with some additional details on each:
    1. IPAM Policy Name – This could warrant an article all in its own and I’m sure I will write one in the future. How you name your policies has a direct correlation to how to target it for use. In this example I’m using a simple name that ties to this methodology. My name in this example is “atlprod”. This is meant to indicate this policy is for prod networks in the atl datacenter. This would equate to {{location}}{{environment}} two items that I can use to identify and target this network. For now you can create your policy using whatever name you like, but keep this in mind and this will be covered in more details in a future article.
    2. Description – Give a description that will allow you to understand what the policy should be used for.
    3. Endpoint Type – Choose the value for your particular IPAM provider.
    4. Endpoint – Select the endpoint we created in the previous section.
    5. NIC Label – This is an optional custom label for which you can use to identify the NIC Label for which it should be assigned when you have multiple policies applied to a single machine. Examples could be primary, backup, monitoring, etc.
    6. Hostname Override – This is another optional field that can help address having multiple interfaces on a single machine. When registering the machine in your IPAM and later to DNS do you want all the IP addresses to be registered to the same hostname, or do you want to make them specific to the intended use. For example {{ request.hostname }}-bk. The -bk would be added to the hostname when the IPAM reservation and DNS records are created.
  4. One you have filled out all the fields to meet your needs select “Next:Subnet(s)” from above.
  5. Select the “Add” button to add a new subnet to the IPAM policy.
  6. When the dialog opens we need to provide some information that defines a network we would like to include in the policy. Each field is broken down with additional details below:
    1. Subnet (CIDR) – Here input the network subnet in CIDR format. Example
    2. Gateway – If your network is routable and has a gateway specify the gateway in this field.
    3. Network Name – vSphere, AWS, Azure, GCP, and others all have networks with names you can use to identify what network the workload should be placed on. This is where you would put the relevant name based on the backend the workload would be provisioned to. You may be wondering why this field would be optional. It’s optional because you can offer IPAM as a service where a consumer could request to get the relevant IP information and in that scenario you may not need to return the Network because the work would be done manually. This will be discussed in a future article.
    4. Network Mask Override – This is another optional field that you can define if you essentially want to supernet the subnet otherwise it will be automatically computed based on the defined Subnet CIDR.
    5. {} – You have seen this symbol to the left of many fields throughout this article. I have discussed this in previous articles as well. Whenever you see this symbol you can use template language in the field. This means I can do things like include logic or simply put a variable in the field so I can determine its value based on inputs that are taken in as part of the request. Like many other things I mentioned this will be covered in more detail in future articles.
  7. After filling in the fields select “ADD” in the lower right corner of the dialog.
  8. Once you add the Subnet you will see it in the list. You can now add additional subnets to the policy if you have a need to. This is especially helpful if you have multiple networks that can host the same or similar types of workloads. In this example if I had more than one network in my Atlanta datacenter that could host production workloads I would add them all to this policy. Doing so will simplify targeting, reduce configuration overhead, and allow OneFuse to manage the consumption across the networks. Select “Next: DNS” to move to the DNS section.
  9. On the DNS page we will be inputting the Primary & Secondary DNS servers to be assigned, the DNS Suffix we want assigned, and the DNS Search Suffixes to be utilized. You will again notice the {} denoting these fields can be templated so we can drive them dynamically. You will see this in the screenshot below I am using {{dnsSuffix}} as a variable to dynamically drive the suffix based on the input that will be sent to OneFuse when the policy is requested. Select “Create” once you are finished.
  10. You will now see your new IPAM policy in the list.

Now that we have created an IPAM policy we can consume the OneFuse IPAM policy from one of our supported upstream providers or through the OneFuse API.

Visit for more information and to join the OneFuse Community Forum