Network automation, just as most types of automation, is seen as a way to do things quickly. Doing things quickly is good, but reducing the time of deployment and settings changes are not always priority issues. However, there are other reasons for organizations of all shapes and sizes to, gradually, opt for network automation:
Presently, several network devices’ settings are unique, different from the default. These unique changes in the network make it more difficult to maintain and manage, while also making it difficult to automate. Instead of treating automation as a secondary project, take it into consideration as soon as designing or implementing the networks.
When acquiring technologies and services, it is necessary to verify whether they include programmability and automation features. A few questions can assist in this task:
- Which characteristics are common to all platforms acquired?
- Which types of APIs or automation tools work for the architecture?
- Is there reliable documentation for the APIs?
- What libraries exist for a given product?
- What is the knowledge level of the manufacturer or supplier?
When asking these questions during the design process, the final architecture becomes simpler and easier to replicate, maintain, and automate.
Whenever there is need to change the network architecture of a large organization, telecommunications operators or any other organization that has the network as a critical asset, it is paramount to carry out planning meetings to assess the changes’ impact, as well as rollback strategies. One single faulty setting command could have catastrophic results for the continuity of the services provided by the network architecture or on the network itself.
Let us imagine three, five, or 30 engineers on a maintenance window, operating at the command line of each device, or maybe through a graphic interface. The probability of making mistakes is quite high and, even worse; there is no guarantee that such mistakes will not repeat in future attempts. In this methodology, when it comes to the likelihood of making mistakes, the result is random.
The programmability and automation methodology goes through trial and correction phases before implementation, thus transforming the previous activity in a task of deterministic results. It ensures that the same fault does not happen twice. The deterministic result linked to programmability and automation is a feature way more significant than promptness.
Due to the rise and the adoption of what we know as server virtualization, engineers and managers are now able to implement new applications in an almost-instant way. The quicker and safer are new applications’ implementation, the more pressing are doubts and questions regarding the motive behind the time it takes to set network resources, such as vLANs, routers, firewalls, policies, etc. It is evident that network automation allows quicker and safer actions, in line with applications’ automation to streamline services delivery.
Many people believe that the concepts of automation and deployment agility are the same, and this may be the reason for the real value of network automation to not yet be perceived. Thus, it is crucial to understand that there are several types of automation and the nature of each one:
It is a broadly used term. Provisioning is the creation of configuration files, or config-files, for different devices, and their subsequent installation – pushing – on the devices. As there are various config-file formats or structures, depending on device and manufacturer, it is required to separate content from structure. This means combining template and content creation techniques (data model). The Provisioning model allows, for instance, generating tens or hundreds of config-files and installing them on the devices in a quick and safe way.
The traditional and most popular method for gathering data on the performance of network devices is through a protocol known as SNMP (Simple Network Management Protocol). Current programmability and automation techniques (APIs, templates, etc.) allow getting the same SNMP information while also seeing how a certain config-file OSPF section was written, for instance. Data Collection is essential to extract all types of information from network devices in a structured manner for future analyses.
Migrating from one platform to another is never an easy task, especially when it is migration from different manufacturers. The creation of scripts and templates provides a migration platform that disregards models and makers.
Compliance & Validations
Compliance Configurations and Validations Configurations are the most significant tasks during automation. So, execute Data Collection on all network devices to verify whether their configurations are in accordance with the control rules. The vLANs, IP addresses, routing protocols, and adjacencies are just some of the check-ups on the information collected from network devices under configuration.
It is the most commonly known form of automation. Configuration management refers to the preparation and changes in the settings of network devices. It goes from vLANs creation or adjustment to VPN configuration, and through complex routing schemes. These are some of the tasks executed during this sort of automation. Configuration management and compliance & validation are phases tightly connected to the automation process, as once validated, it requires only simple changes to the settings.
All stages mentioned thus far require the proper documentation. While the automation process is executed and evolves, the documentation must be updated. Manually preparing and keeping the documentation offer fewer risks, however, is just as highly fault-sensitive as the manual configuration of networks devices.
Within the network context, as it is noticeable, automation means more than quickly executing changes in the settings. Automation is a method that includes knowledge and tools, which allow meeting the growing networking demand: networks are not configured, but programmed.