Why IPAM Repository is the Key Enabler for Network Automation

Nowadays, things are moving quickly and nothing is set in stone. The same is true for IT and networking services. Today, deploying applications or websites must be done quickly for faster Time-to-Service but in addition, must be done as many times as required to account for the necessary functional upgrades or mandatory security patches. So, most of the mundane IT and networking tasks must now be thought of in terms of cycles with their seasonalities and not as a one-off “kick-off and forget”. In short, applications and Infrastructures must be approached in terms of life-cycle with repeatable configuration kits using templates and relying on a Single Source of Truth repository such as an IPAM for storing their data and metadata. We are talking about automation here. Such a framework will grant provisioning and booking of all required resources and means to deploy applications, websites, infrastructure, etc. for their run phases. And at the end of their life will permit them to easily decommission themselves and their related dependencies. This brings obvious benefits such as cost savings on labor as well as the optimization of resource usage. It also strengthens security by never leaving security holes behind the decommission of an app for instance.

Limits of Manual Operations

Let’s look at the “manual” creation of any application. The deployment must comply with the existing network infrastructure and company policies in place e.g. IP address, DNS Resource Records, servers, virtual machines, containers, naming conventions, security policies, etc. This is at best documented in various out-of-band documents (e.g. spreadsheets) or simply known by the NetOps, SecOps, and DevOps teams. So the first thing to consider for network automation is to set up a common and shared repository for applications and network data and metadata. An IPAM is meant for that.

The manual deployment of an application will also require multiple touchpoints to gather all necessary information and sync up with the related teams via out-of-band exchanges of information such as email, phone calls, and chat. As a consequence, such a process relying on a successful exchange of accurate and up-to-date information won’t be predictable, and in addition, it will be slow and time-consuming to execute as handled by multiple IT and network staff.

Lastly, manual processes are in essence error-prone even with the prejudice that exchanged information is accurate and up-to-date, which is reliant on all involved teams have done their jobs in due time. Nothing is less certain…

When the time comes for this application to be decommissioned, it will be difficult to ensure all resources used by the app will be released in a timely fashion. At best they’ll all be at the cost of multiple touchpoints again to gather the information and proceed. At worst some resources will remain provisioned, typically DNS Resource Records, leaving security holes that will soon be exploited by cybercriminals.

So all in all, manual operations bring challenges regarding labor costs, time-to-service, and optimization of IT and Network resources, and they are risky for the security of the infrastructure in the long run. All of the above are questions and challenges NetOps, SecOps, and DevOps teams face every day in their operations and their relationships with their counterparts.

Capabilities of IPAM for Network Automation

It is easy to understand how automation will solve the challenge of manual operations. App creation and removal can then be done with a single touchpoint using orchestrators, schedulers, or infrastructure-as-code software tools such as Terraform, Ansible, or Chef to name a few. To streamline both the creation and removal of Apps and their dependencies (IP addresses, DNS RRs, servers, VMs, containers, security policies, etc.), there is a need for a consolidated single source of truth repository for IP plan, apps, devices, etc. from which the automation solution will collect the needed data and metadata to proceed. That’s typically the role of an IPAM. And it is preferable to use the IPAM as the single source of truth to ensure whatever is modified on the network is reflected in the repository independently of the applications’ ecosystems using it.

Another facet of the need for an IPAM is its connection with DNS. Once created an application must be reachable by its users. This will be done usually via a URL. This means DNS resource records must be associated with the App. An integrated DDI solution offers automatic synchronization between IPs in the IPAM repository and DNS RRs, so applications’ URLs can be derived from the DNS zones hosting them themselves bound to IP subnets.

Last but not least, an SSoT can not only be the sole repository to store all apps data and metadata, meaning they won’t have to be stored as well in the automation software using them but this repository can be used by multiple automation software solutions from various ecosystems – NetOps, DevOps, SecOps as well as in the case of M&A when several ecosystems from the merged organizations must coexist.

All in all, whichever scope of automation is ambitioned, and whatever automation suites are used, the recommended practice is to use an independent IPAM single source of truth repository integrated into a DDI solution.

Benefits of using an IPAM for Network Automation

• From multiple manual/out-of-band (calls, email, etc) touch points to a single touch point for:
  • Quicker time-to-service
  • Reliable and consistent configurations
  • Enforced company policies and security
  • Lower cost of operations with reduced workload/time saving and optimal resource utilization
  • Connecting management silos for more efficient cross-team working
  • Quick, easy and secure removal of apps and their dependencies
• Exhaustive visibility and control of all resources booked and consumed (IPs, DNS RRs, apps, devices, etc.) and their relationships (which apps run on which servers with which IPs, DNS RRs, etc.)
• Independent Single Source of Truth Repository allowing:
  
  
  • Access and updates by multiple automation solutions
  
  
  • Application and infrastructure referential for capacity planning and disaster recovery plans
  
  

  Another benefit to consider when using an IPAM single source of truth (SSoT) repository is that it can serve as the Application inventory for all apps and their dependencies. This will come in handy for Disaster Recovery Plans – DRP. There is one place where all information required to remediate the disaster is stored and such a repository is independent of the resources it documents.

IPAM SSoT Repository as the Foundation of Network Automation

Network automation goes far beyond faster repeatable operations to save labor time at the individual level. It is about a mode of operation leveraging repeatable operations by using templates to ensure compliance with the company policies and reliable and consistent configuration. It allows connecting silos between NetOps, SecOps, and DevOps teams by implementing a common Single Source of Truth repository that all can use and add to. Using an IPAM as part of an integrated DDI Solution provides an exhaustive shared and actionable inventory of the assets in use plus visibility and control on the consumed IT and network resources. An IPAM Single Source of Truth inventory is the foundation of network automation ecosystems and ensures fast, reliable, controlled, and secured operations.