5 Use Cases to start your network automation journey

We have finished our training in automation, we have watched the videos on YouTube, we have set our IDE; We have cloned the repositories, and now? What’s next ?

A possible strategy could be to develop basic use cases over, which will become the foundations for the automated network we will create. This does not necessarily mean to create complex automation use cases and autonomous ( we will get there), but to be effective when it comes to creating and deploying automation use cases that:

• Are valuable per se,
• Are reliable for the networking staff and managers,
• Are possible to be improved or enhanced.

In addition, it is very important to back this strategy by incorporating the DevOps mindset of continuous and constant delivery of value. We need to make small early changes, measure results and get feedback soon.

If you are launching network automation projects in your company, I share these use cases for you to start with the right foot:

1. Backup
The aim of this use cases is to periodically collect the running-config of our network elements in an agnostic way and store it in a customized repository.

• Easy to be implemented by those who are starting to use automation technologies;
• Multivendor, as there is wide availability of modules and libraries;
• No changes in the network since we are performing read-only actions;
• Possibility to use it on other more complex automation;
• Possibility to see changes in the configuration.

Bonus

• We can process/parse configurations and build services inventories.

2. Operational Checks
We need to count with a picture of the operational state of the network, really useful for having a reference or baseline of the usual functioning. For this, we need a well-known, documented and deterministic process.

• Listing, commands healing and deterministic reports provide us the independence from the engineer’s expertise who is carrying out the check.
• It does not produce changes to the network.
• It can be used to monitor changes periodically or pre/post maintenance windows.

Bonus

• By Processing / Parsing the outputs, we can normalize the results and make agnostic reports of the vendor.

3. Inventory | Facts

Through this automation operations we look for building our own inventory in an autonomous way. We can execute commands which let us know more about the hardware, software and configured resources in our devices ( interfaces, VLAN, IPs, etc ) and generate our inventory.

• Automatic generation of reports about our infrastructure in multiple formats.
• Controlled discovery of services and resources of the network element.
• Automatic and periodic update.
• No changes in the network.

Bonus

• Thanks to MAT’s idempotence, it is possible to detect changes in the parameters of our infrastructure (configuration drift ).

4. Compliance

In many industries , there are a number of safety regulations which need to be implemented in our network, and it is necessary to provide evidence for internal and external audits.
We can develop a use case that makes evidence collection easier and that makes the required reports.

• Proactive scanning of the network. It Improves the security standards of the company.
• Makes evidence collection faster.
• Automates the generation and reuse of reports for different audits.
• No changes in the network.

Bonus

• We can build dashboards to see how many devices are in compliance.
• We can reuse the backup automation and process the sections or configuration parameters we are interested in.

5. Network services configuration
By starting with the automation operations which make changes in the devices, we can provide a set of basic services such as syslog, DNS, SNMP, NTP, banners, hostname, local users, authentication mechanisms, etc. These services are essential to put devices into operation according to the standards or guidelines of our company.

A vital concept that naturally arises in the construction of this automation is that, on the one hand, the different services are parameterized ( IP, port, etc ), which show the “desired” state of our network. On the other hand, all the logic of the implementation is programmed (controller that executes the necessary commands in each device according to the technology, vendor, operating system). This lets us move to “infrastructure as a code” since we can manage and provide our infrastructure through code instead of through manual processes.

• Automated provision of network services.
• Reduction in times associated with manual configuration of devices.
• It speeds up deployment times.
• Reduction in human errors.
• It eliminates diversions in the configurations.

Conclusion
To sum up, we choose these automation operations since the input is relatively simple. By investing a few hours of programming, we can see real and measurable results, even in production.

Another important feature of these automation operations is that they are generic and common in the daily use of network. This allows us to reuse them in more complex flows.

In addition, the deployment of these automation in the production stage, positions us ahead in certain challenges we will have to face, for example:

• Building an inventory.
• Connectivity, credentials and privileges for network elements.
• Management services configuration in the devices (SSH, SNMP, NETCONF, REST, etc).

I hope this post has been of great help! See you next time!

By: Juan Pedro Aldunate

Related resources

• Check the definition of DevOps
• Request a demo of this use Cases
• Know more about the CI/CD engine in MAT