Building My First Network Automation with the Itential Automation Platform

On a bright and sunny Atlanta morning in July of 2021 this year, I entered the Itential office for the first time as a new employee. Being fresh out of college, I was excited for my first day as a Software Engineer. After my initial onboarding process, I started working on a few training modules assigned to me to help learn more about the Itential Automation Platform (IAP), its applications, and best practices.

Soon after completing my training, I was assigned my first project ever under the Delivery Support team and was incredibly surprised with how easy it was to build and deploy my first automation within the Itential Automation Platform. As my very first project, I was tasked with building an automated workflow that can create temporary virtual network devices, such as routers and switches, on demand by provisioning memory, storage, and computing power on local servers. A further requirement was set that the system should free up storage when the use of the virtual device is over. It was decided that we would use the applications offered by IAP to build this system.

In this blog, I would like to take you through the journey of how I created this automation, the IAP applications and integrations I used, enhancements made to this project, and more.

Building My First Workflow in Itential

I started by selecting VMWare vSphere and vCenter as the cloud virtualization platform for this system. Upon exploring all the APIs offered by these technologies, I found an API that could spin up new VMs out of Templates. So, whenever a new device is requested, a new virtual machine is created from the template. By using Itential’s Automation Studio, a low code development interface that allows for rapid designing and building of automation workflows, I developed a workflow that could communicate with the vSphere backend via REST calls. To make this system more interactive, I created a form that would allow the user to set a device name, select a device type, the template in vSphere, and an expiration time.

After the initial development was complete, our team faced our first challenge – getting the IP address of the newly provisioned device. After a lot of research, we observed that Cisco Meraki assigned our device’s IP Address. Once a device was provisioned to connect to the Itential Network via DHCP, the machine communicated with the Meraki controller. Meraki has a fantastic set of Robust APIs and one such API could give details of a device, like its IP address, once it connects to the local Itential Network. Therefore, I modified the workflow, so it communicated with the Meraki controller using the API, which made it possible to get the virtual machine’s IP Addresses.

The next requirement we needed to meet was to build the functionality to automatically free the resources once the use of the device is over. This is where Itential’s Operations Manager, application that allows managing jobs and workflow executions, came in. One such feature offered by Operations Manager is known as “triggers.” For example, with the help of triggers, we can schedule the execution of Jobs. I used the potential offered by Operations Manager Triggers to schedule jobs that execute cleanup workflows once the use of the device was over.

Further Refining Our Automation

Once we had the baseline workflow functioning as intended, three enhancements were made – role-based access control, Slack Bot notifications, and the ability to onboard new devices to Cisco NSO and Itential’s Automation Gateway. This was essential to track the number of devices created so let’s take a quick look at each.

We needed the ability to control who could request a machine from this powerful and dynamic system. Luckily, IAP allows an admin to leverage LDAP groups to fine-tune access based on different levels of privilege. Hence, once a user requests a device, only an admin can perform a set of tasks that approve a request.

To make this procedure real-time, we used a Slack Bot that notifies the admins that a device is requested. Once the request was approved, and a device was created, all the necessary details to access the device, such as its credentials and IP address, were also messaged to the user by the Slack Bot.

In many scenarios, it was observed that the virtual device needed to be onboarded to Cisco NSO and Itential Automation Gateway, a way for network teams to securely organize, run and share their library of CLI automations. To automate this onboarding, I used Itential’s Pre-Built Collection of Integrations, Automations, and Transformations.  Our Pre-Builts are out-of-the-box, ready-to-use collections that can be directly imported into IAP. With over 150 open-source integrations available in easily accessible Gitlab repositories, I was able to quickly onboard Cisco NSO and IAG into the automation.

What We Accomplished

In summary, we created a self-service automation with a form to request and process user input. Based on those results, the system creates a brand-new virtual machine, gets its IP address from the Cisco Meraki controller, and, if requested, automatically onboards the newly provisioned device to selected NSOs and IAGs. Moreover, the system takes care of deletion by running Operations Manager Triggers on device expiry.

All in all, as a first-time user of Itential, I was amazed by the capabilities of the platform, how easy it was to learn, and how quickly you can get an automation up and running. It is highly comprehensive software, and combined with Pre-Built Integrations offered by Itential, the platform can support rapid implementation of almost any automation across both network and cloud infrastructure.

I’m thankful to everyone at Itential who helped me in building this automation and am proud to be working with a company that can build robust and superior software. To see just how easy it is for yourself, you can check out the “Introduction to the Itential Automation Platform” or create your free account of our cloud platform to give it a try for yourself.