DDI Automation for Infrastructure as Code

When using code to automate the activities in the infrastructure department, a DDI solution (DNS, DHCP & IPAM) is one of the parts to connect to and use data from. It may actually be a good strategy to start your Infrastructure as Code initiative with DDI in your bucket of tools and software integrations, as it will facilitate the development of other parts thanks to its “IP Source of Truth” data repository and network services automation.

Automated Infrastructure

It was a long time ago that we started automating the configuration of some elements of the infrastructure. The networking devices were among the first to propose an external way of being configured, mainly through SNMP and CMIP/CMIS (anyone remember these?) at a time when asynchronous connection through a passive terminal was the only way to talk with most machines. Immediately, some of us started to automate actions, perform supervision of the statuses, and configure parts of our networks. This movement still goes on, methods to exchange with equipment and devices are still not universal but more options are available and virtualization has brought much simplification and many opportunities.

The Promise of Infrastructure as Code

What we call Infrastructure as Code (aka IaC) is generally a way to perform actions on any infrastructure component based on declarative instructions explaining what the expected result is. It mostly tries to apply the idempotency principle so that the same code can be executed multiple times in order to either reach a specific state or ensure that the infrastructure is still in this state. For example, when we declare that VLAN 1423 exists and supports the routed subnet 2a01:e0a:3bc:7240::/64, all components should be configured (or tested) in such a way that if the VLAN does not exist, it is created, if the subnet is not present in the IPAM it is created and associated with the VLAN, and finally, the routing infrastructure made aware of the IPv6 subnet, at least through the router interface directly connected to the VLAN. We can see that this declarative approach is independent of the equipment and solution supporting the infrastructure, and should be helpful when multiple vendors and solutions are present in the field, limiting vendor lock-in and simplifying operations.

Infrastructure as Code Scope

For this to work in the real world, a tool or a set of tools is required to bridge the gap between the declaration and the various infrastructure solutions that are available via a specific set of methods and API (REST, SNMP, YAML, NETCONF…). Ideally, the tools are directly attached to a pipeline system able to trigger changes to the configuration described in a version control system (e.g. git), perform validation, authorization checking, and execute the related actions either immediately, based on a schedule, or during an operation window.

At the center of such an ecosystem, the DDI has its role to play. IPAM is the repository of IP information, with some advanced solutions also being able to manage adjacent objects like VLAN, VRF, devices, applications, identities, links between network ports, and network interfaces. It’s, therefore, the central solution to use as the source of truth, and in which to store any valuable information on networking elements through metadata like location, usage, business unit, external relationships with other repositories, deployment status, dates.

DDI steers Infrastructure as Code

The engine sitting in between the descriptive infrastructure source and the infrastructure components should use the IPAM as its reference and repository of information. That will considerably ease deployment, follow the processes and link the Infrastructure as Code process with the rest of the ecosystem that may be managed using different methods.

On top of the repository feature inherent to the IPAM, complete DDI automation brings added value with the automatic configuration of network core services like DNS and DHCP. When DDI is managing the reverse DNS zone associated with a subnet, it simplifies the code, when the DHCP scope is automatically created or destroyed based on the information in the IP addressing plan, the code is even easier. In addition, since the DDI solution can be linked with a lot of components in the IT ecosystem through events/webhooks and specific integration, the amount of effort required to write code for the I&O teams can be significantly reduced. For example, the creation of an IP subnet triggered by the SD-WAN solution for a new site can automatically be sent to the security solution that will set up the firewall rules and zoning conditions for this new network.

In order to move forward with an Infrastructure as Code initiative or project, it is important to study the connection to the DDI solution already in place or maybe to take the opportunity of such a project to establish an IPAM repository that will be helpful. By connecting the IPAM data storage and the IaC engine, the I&O and DevOps teams would be able to train themselves how to code and how to use APIs, start using more advanced features like metadata, and benefit from a sandbox that is generally not available on the infrastructure itself. All the work around automation of the IP addressing plan and additional information like VLAN and devices will play a fundamental role in the deployment of new pieces of code since most of the time infrastructure components are dealing with IP parameters.

Our recommendation is therefore to take advantage of EfficientIP SOLIDserver’s rich API set to embark on your IaC journey. You’ll be able to leverage its ability to create a dedicated space for testing purposes, its integrated automation of core services, integration with common platforms like Terraform and AWS, and easy connection with the rest of the ecosystem through webhooks. Afterwards, you will probably not turn back.