Network automation has been with us for a while and its popularity is growing exponentially, but still, there are a lot of companies that are resisting this structural revolution in the network realm. There's a joke from Big Switch Networks, that so far, the biggest shift in the network area was the migration from Telnet to SSH. Times change and the software-defined networks, along with network automation are playing a huge role in the future of many companies.
That's why in this article, we would like to shed some light on network automation itself. We will explain why network automation is a thing, and why it's worth considering implementation.
The benefits of network automation
Below, we described the network automation pros from which we benefit most often while developing projects.
Consistency
Having a large-scale network has its challenges, and it's very difficult to keep it consistent using a traditional approach without network automation. One issue is configuration consistency. Devices in manually-maintained networks often have outdated pieces of configuration that are left by the engineers. Those chunks can disrupt network' operation in an extreme case. There are many reasons for having consistent configuration across the entire network topology. Security concerns lead the way. It's way easier to secure a consistent network, than an inconsistent one.
Let's take a look at some examples of how configuration consistency (or inconsistency) affects the network:
- Services – Any running service is a potential risk for the network and could be exploited by attackers. The key is to run only the necessary services.
- Device software version – No released software version is free of bugs and they can impact network stability, or be used by attackers. It's way easier to maintain a network with devices having the same software versions.
- Configuration clarity – When unused chunks of configuration are not affecting the network directly, they can be a mess for engineers during configuring or troubleshooting actions. An automated network approach helps to eliminate such configuration issues.
- Unpleasant surprises – In a large-scale network it's not too hard to overlook a device in the case of, for example, a service migration. Imagine having a new syslog server and figuring out that the device that you're troubleshooting right now wasn't reconfigured and you don't have any historical logs that could help you solve the problem.
Those are just a few examples of how configuration consistency affects the network operation. Network automation comes in handy in the cases mentioned above. It can be used to configure devices in a certain way, and to keep track of the manual changes made by the engineers if they're in track with the configuration policy.
Lower changes costs
In smaller-scale networks, the cost of making configuration changes on the whole topology isn't a real problem. However, that changes with scale. Let's imagine a network topology with 1,000 network devices and a situation in which we have to reconfigure something on each device. It can be a minor change, such as a reconfiguration for a new syslog server IP. The reconfiguration process can be even more efficient with the use of configuration templates. Such situations show a real case scenario where automation plays a significant role. Such changes can be done manually, but at what cost, and time? And here is what is great about network automation. The amount of work that can be done manually has its boundaries, in contrast to automation, which doesn't really have such limitations.
Robust to human errors
We're all human and we all make mistakes sometimes, it's our nature. In the realms of computer networks, those oversights can be costly. Very costly, because human misconfiguration errors are hard to spot due to their indeterministic nature, and can take a lot of time to troubleshoot. Just imagine the financial losses from a network outage in a factory or large office. Automation helps to reduce the chance of human error. It matters, especially at scale. The more manual reconfiguration has to be done, the more likely a human error will occur. On the other hand, the automation approach is predictable. An automation script can be tested on a small part of the network, and if it works as expected, can then be executed across the whole topology. With such a workflow, we know exactly what changes are being made to our network.
Security visibility
Today, security is taken very seriously. Network automation can be used to search for vulnerabilities and weak points. There are various solutions for that problem, depending on what you want to achieve, starting from self-made scripts to full blown products such as Qualys. Network scan reports keep you informed about current overall network status. They highlight which network elements could be vulnerable to an attacker. Such risks can be then addressed by security engineers and solved.
Documentation
Asset maintenance can cause headaches among network engineers. Let's be honest here, who likes to update documentation? But there's a solution for that problem too. Such tasks can be done automatically.
Automated scripts can be used to perform tasks like:
There are situations when hardware changes occur. It could be intentional or as a result of component failure.
Some network topologies are dynamic, which means that they are constantly changing. This is especially accurate in R&D environments.
Various information can be gathered from the device, such as the serial numbers of components. It's important to track assets, especially in large environments.
There are device configuration changes that should also be included in the documentation/IPAM, like hostname or location.
Some networking devices require subscription in order to use advanced features. Scripts may be able to get information about licenses and support contracts that are soon to expire.
The tasks described above can be significantly accelerated when we use automation. Any detected changes should be reflected in the documentation/IPAM. Any inconsistency between documentation and the environment introduces chaos, which can lead to longer troubleshooting times or mistakes being made by engineers.
Common doubts about network automation
Despite the many benefits of network automation, there are still concerns. Let's face them:
Time is a real struggle for a lot of us. How can we find even more time for additional tasks such as writing scripts? Well, we have to look at it as an investment which in the future will bring time savings. If we are performing repetitive tasks on one or many devices, any time invested in writing a script which will handle it for us, will save our time in the future.
Not every network engineer has developed programming skills; some don't even want to. For an engineer that just started with automation, writing a complete script will take much longer compared to an experienced colleague. In such a case, we have to treat it as an investment, as in the previous point. Further scripts will take less and less time to write. For network engineers that don't want to develop their programming skills there's another solution: a joint team of network engineers and programmers is a very efficient way to approach automation topics. In such a team, a network engineer is responsible for specifying the steps which can be programmed by a developer. The benefits of this approach lie in the expertise of both engineers. The networking part is properly handled, and the script is written efficiently and swiftly.
There is always a fear that a script will break something and create problems in our environment. That's why, before executing a script, it first should be run in a test environment. Also, to better understand what the script is doing, good practice is to implement a wide level of logging. By doing that, we're able to clearly see what's happening during the script execution, on many levels.
Conclusion
We took you through some examples of when network automation comes in handy. However, its real power comes with its flexibility. There are many problems that you’re probably facing on a daily basis that could be automated. The boundary of the possibilities stands at the limits of the network engineer's imagination and automation skills.
If you are interested in network-related topiss, check out our other articles:
