Open-source automation in data centers

On May 5th, Christian explained us the role of automation in today's networks. We saw how most companies use as their main method of device configuration a connection via SSH and there are still people who configure devices by connecting directly via console.

Of course, as the size of the network increases, programming devices individually (using SSH/console) becomes more and more tedious, and more importantly, the probability of configuration failures increases. These bugs may be undetectable a priori, but once they come to light it takes a lot of hours to find them and put an end to them.

It is because of these problems that companies are gradually tending to configure their devices using the automation provided by systems such as NETCONF or RESTCONF. Systems such as gNMI or APIs are also used but are not as popular.

Automation also provides us with telemetry and analysis tools, very useful to diagnose problems or any kind of inconvenience. An example of such a tool would be Zabbix. This application allows us to create a database with all the devices in our internal network and then monitor each of them. This monitoring includes ICMP messages, SNMP packet collection and even HTTP GET for front-end applications. The best part of this type of applications is that they are often complementary to others, i.e. Zabbix can be complemented with other applications, such as elasticstack, to visualize the data collected through graphs. We see then how the union of the different applications facilitates the control and proper functioning of the network.

Automation focused on the configuration of devices has a similar operation, where several applications are joined to form a better one in which, for example, translate the commands for each of the manufacturers. The configuration application par excellence is netmiko. The rest are based on this application, since netmiko is based exclusively on sending commands and collecting the response. With this type of automation we can talk to multiple devices at the same time and thus facilitate the configuration and exponentially reduce the chances of making mistakes.
All these automations are the simplest examples. Nowadays, telemetry applications could be mixed with configuration applications to automatically solve problems that are reflected in the logs. Adding all this to larger scale projects, we obtain systems capable of automating any device, including servers and even firewalls.

Unfortunately, no matter how modern our automation system is, there will always be the configuration via console or SSH to start the device or reboot it in case of error, so although we have to get used to the new working systems, we cannot forget the basics.

Fortunately for us, Christian has provided us with a series of applications to create virtual environments and test everything we have seen, such as ContainerLab or Kubernetes. Certainly, these applications will be very useful to test everything pending implementation, since it would be practically a crime to deploy something new in our network without having tested it before.

Arturo Moseguí