Switch Management Automation
We have already written a lot about the possibilities offered by modern ONIE boot switches and Linux-based open OSs for them. Building L3 factories , overlay L2 virtual networks - all this has already happened. But one important topic that has been much talked about remains unresolved - automation capabilities.
The command line is, of course, great and generally a classic, but in 2014 I want more. Especially if you have to work with dozens and hundreds of devices on the same network.
So what do we get when using a switch with a Linux-based OS such as Cumulus?
Automation starts already at the stage of connecting the switch to the network environment. And for that, it’s worth thanking the ONIE installation environment that replaced PXE. When booting for the first time using DHCP option 239, the URL is requested from which the system image will be obtained. And along with it, a script is requested that will be executed during installation. The list of supported languages includes Bash (Shell), Perl, Python, Ruby. A typical example looks something like this:
Zero Touch Provisioning
This option can greatly facilitate the process of deploying or expanding a network in which there are a large number of settings of the same type. However, filling the set of necessary software “by default” is already very valuable, it is known to anyone who had to assemble computers or servers in an amount other than “one for personal use”.
But here we broke through the installation phase, and here all the most interesting things in the Linux world are already beginning.
There is a choice from:
The first package is considered more common and convenient, but there is an opinion that the second is better with scalability. For our part, we are only happy about the choice and offer you such statistics on the use of various options on the "nines":
Routing on traffic exchange nodes
Here the choice is small, but very decent from the point of view of the proposed features:
We wrote about VMware NSX in our previous material , and OpenStack is such a voluminous topic that it requires not even a separate article, but a whole series of articles, so we will leave this part without additional comments.
Automation of interface management
When it comes to automation of management, here we have:
- Puppet - written in Ruby, one of the most famous client-server systems for managing OS and software configurations using the special language Guide
- Chef is another well-known configuration system.
- CFEngine - the third world-famous configuration system
As always happens in such cases, holivars about which of the systems are more convenient never stop. Therefore, only with the support of all three systems in the OS of the switch can we say that it has the necessary flexibility to be successfully integrated into most existing environments.
However, even if you use third-party or proprietary control systems, no one bothers you to adapt their client for use within the framework of an open switch OS.
And a few words about the popular network interface management packs. Most likely , many Debian packages like ifupdown are known . Cumulus uses its updated version of ifupdown2 :
By and large, this is still the same package, with preserved backward compatibility, but rewritten in python and with enhanced functionality. The new version has greatly simplified the syntax of commands. But perhaps the most useful feature is the ability to make incremental changes to the configuration of network interfaces without restarting the interfaces.
Understanding the processes occurring at any moment of time, the desire to always keep abreast of what is happening is a characteristic feature of any good administrator, be it system or network.
For those who are used to Linux utilities, there is a host of multifunctional, long-developed packages:
Well, “networkers” will rather enjoy the familiar sFlow .
Prescriptive Topology Manager (PTM)
Another useful feature at the interface of monitoring and automation is PTM. This package allows using LLDP polling of nearest neighbors and BFD (Bidirectional Forwarding Detection) to find failures in existing paths, build a real existing network topology and compare it with a predetermined topology.dot file. The latter is a file of the graphviz-DOT format, a relatively common way of textual description of a connection graph, convenient enough for working with it as text and for converting it into a graphical representation of a topology.
Prescriptive Topology Manager
As a result, we get a convenient way to check the correct connection of cables, which is very important for large installations. In addition, we get another mechanism for monitoring the status of network connections, moreover, it is easily scripted and already integrated with quagga.
Well, something like this looks like the situation with automation in modern networked open OS.
What do you use?