# IPAM module best practices

> Best practices for naming, subnet grouping, and DNS configuration in OneFuse IPAM policies

---

Site [llms.txt](/llms.txt)

---

The CloudBolt OneFuse integration platform offers an IPAM module that can be leveraged to provide enterprise grade IP address assignment automation to CloudBolt CMP, vRealize Automation, Terraform, and other platforms. It allows for easy, flexible, consistent integration to Infoblox, BlueCat, and Men & Mice IPAM providers with more to come.

The OneFuse IPAM module takes IPAM integration a step further by validating every IP address before it is assigned. This ensures you won't have conflicts from IP addresses that were assigned for use without being reserved in the IPAM system.

## Resources

For additional information regarding OneFuse IPAM, refer to the following documentation:

- [OneFuse IPAM Module](/docs/onefuse/configure/modules/ipam/)
- [Terraform Provider and OneFuse IPAM Module](/docs/onefuse/consume/hashicorp-terraform/modules/ipam/)
- [Aria Automation 8 and OneFuse IPAM Module](/docs/onefuse/consume/vmware-aria-automation/aria-automation-8x/modules/ipam/)
- [vRealize Automation 7.6 and OneFuse IPAM Module](/docs/onefuse/consume/vmware-aria-automation/vrealize-automation-76/modules/ipam/)

## Prerequisites

For each IPAM Policy you create, gather the following data:

1. Subnet(s) you will be assigning to the policy, including:
   - Subnet CIDR
   - Gateway
2. Name of the network within the hosted environment (vSphere, AWS, Azure, GCP, and others) for each subnet you will add.
3. The purpose of the subnet; decide what types of workloads can be hosted on the subnet.

## Policy naming

How you name your IPAM Policy determines how to target the policy for use. Adopting standardized naming offers the most effective way to dynamically determine which network a workload belongs on. Your naming convention should be based on the same factors you would use to manually determine placement.

For example, network placement deciding factors might be:

- Datacenter
- Environment
- Function
- Compliance

A naming convention for these factors might look like `{{datacenter}}{{environment}}{{function}}{{compliance}}`.

Values for each factor could be:

- **Location:** `atl` or `por`
- **Environment:** `prod`, `dev`, or `test`
- **Function:** `web`, `app`, or `db`
- **Compliance:** `none`, `sox`, or `pci`

Resulting names could be `atlprodweb`, `atlprodwebsox`, `atlprodwebpci`, `pordevdb`, and so on. Each variation hosts workloads based on the four factors above. By naming your IPAM policies this way, you can dynamically target them based on what they can host:

```jinja2
OneFuse_IPAMPolicy = {{location | required("Location is required") }}{{environment | required("Environment is required") }}{{function | required("Function is required") }}{{compliance}}
```

Required components will fail and return the error statement if not passed. Compliance is optional, allowing it to be passed in or omitted. With this methodology, you can take in the relevant information and dynamically determine the network for any requested workload.

## Subnets

Group your subnets into logical groupings that can host the same type of workloads. If you have more than one network that can host production databases in Atlanta with no compliance requirement, put them all in the same IPAM policy. OneFuse handles consumption across them.

![Grouping subnets in an IPAM policy](/img/onefuse/configure/modules/ipam/best-practices/bpd_onefuse-ipam-subnets.png)

## DNS

If your environment leverages different DNS servers, suffixes, or search suffixes within subnets, don't hard-code them into your IPAM policies. Set placeholders and pass them in dynamically. This results in fewer IPAM policies to maintain and maximum flexibility.

![Passing DNS values into an IPAM policy](/img/onefuse/configure/modules/ipam/best-practices/bpd_onefuse-ipam-dns.png)

## Outcomes

Use best practices to name your IPAM policies, group your subnets, and pass in placeholders for DNS items to maintain flexibility.