Network-Engineering | 7 min read
CloudVision – Configuration Hierarchy
Learn how to use CloudVision to manage your network and introduce Change Management in your organization.
CloudVision is the front end to the Arista Network infrastructure and it includes tools for Configuration Management and Automation, Network Monitoring, Trending, Analytics and it integrates a Change Management framework.
In this review, we will introduce two fundamental components that make up the Configuration Management of CloudVision: Configuration Hierarchy and Configlets. We will also briefly touch on its Change Management capabilities that bring Change Control into the network.
In order to manage network equipment, the first requirement is to build up a list of devices that we are going to control. If the network is configured with the ZeroTouch Provisioning, new nodes will be automatically discovered, otherwise, manual enrollment is also possible.
Once devices are enrolled, they can be viewed under the Inventory section in the Devices Menu.
CloudVision can display the network nodes in a configuration-based topology. Compared to the network-based topology, configuration topology has the purpose of grouping nodes based on their configuration, rather than position in the network, so that configuration elements can later be applied on the basis of commonalities between the nodes configuration.
Configuration elements applied at the higher end of the hierarchy will become common to all underlying nodes. The lower we move in the hierarchy, the more specific configuration elements will become. At the very bottom, configuration elements will be applied only to the individual node.
An example of configuration hierarchy is presented below where all nodes are displayed in a flat hierarchy, being initially part of the default group.
As described before, the configuration hierarchy allows grouping nodes with similar configurations together. In CloudVision, these groups are called Containers and are used to build up this hierarchy starting from a flat representation.
Let’s create a new container called: Group1.
And move some devices under this newly created container.
Being associated with the same group, Host1 and Host2 can now be managed collectively by applying the changes to the upper group.
Let’s apply the same SNMP configuration to both devices:
! ! snmp-server local-interface Loopback0 snmp-server community ACL1 ro snmp-server host 10.0.0.1 informs version 2c public snmp-server enable traps bgp ! ip access-list ACL1 10 permit ip 10.0.1.0/24 10.255.255.0/24 20 permit ip 10.0.2.0/24 10.255.255.0/24 ! !
We could apply the configuration element – or Configlet – to the root group “Tenants” and in this way, all nodes, including the ones belonging to Group1 would inherit this configuration.
In our example, we will apply the configuration only to Host1 and Host2 via Group1.
Configlets are one of the building blocks allowing configuration management within CloudVision to scale.
Rather than managing a large configuration file for each node, individual segments of CLI commands are combined to build up specific configuration files and can be reutilized across multiple nodes. Nodes sharing similar configuration will therefore share common Configlets.
In our example, the SNMP addition to the node could be achieved by a specific Configlet.
Once the configlet is created, it can be applied to the individual node or at a container level. The first option could be used for a very specific purpose, such as a troubleshooting script or a port-specific configuration. However, for optimal utilization of the Configlets and to bring scalability, the network should be designed in a way that configuration repetition is maximized, and Configlets applied at the group level.
Network Provisioning using Configlets
Going back to our example, let’s apply the newly configured segment to Group1.
Before the application, the new configuration lines are presented for review and confirmation.
Following confirmation and application, we can see that the lines are applied to the node:
host1#show running-config | i snmp snmp-server local-interface Loopback0 snmp-server community ACL1 ro snmp-server host 10.0.0.1 informs version 2c public snmp-server enable traps bgp ! ! host1#show running-config | s ip access-list ACL1 ip access-list ACL1 10 permit ip 10.0.1.0/24 10.255.255.0/24 20 permit ip 10.0.2.0/24 10.255.255.0/24
Change Management and Control
Now that we have described some of the basic concepts of the Configuration Management in CloudVision, let’s see how the platform introduces a Change Management framework.
We explained how CV can automatically manage and apply configuration commands to individual components or groups. Before these actions are implemented, however, we have must instruct CloudVision on how these tasks must take place.
Let’s first define the task of applying the configuration elements represented by the Configlet:
Right after a Configlet is associated to a node or container, a Task is automatically created describing this action. Let’s review the process:
Create a new Configlet
Select the node that will receive the Configlet
Apply configlet to the node
As soon as the configlet is confirmed and validated, a task to apply that new configuration change is created and associated with the node. This is visible already from the configuration topology with the “T” symbol showing both the node and the group affected.
The Task is available from the list.
The Task details indicate the actions that will be performed on the node.
Now, the last step is instructing CloudVision on how and when to execute this new task.
After defining and applying a task to a node, or group, the next step is planning for its execution.
In a Change Management context, this involves:
- planning the Change Request
- having the Change Request approved
- scheduling the execution of the Change Request
- validating the Change effects – and –
- in the event that the Change Request did not bring the expected results, evaluating and requesting a RollBack
All these phases are specified and automated within CloudVision.
In our example, we will simply execute the task without including pre and post validation.
In this case, we will also be evaluating and approving our own change request. It’s important to specify that this function can be moved to a separate team, or operator, so that the responsibility of approving the Change Request is separated from the one of execution.
The Change Management Panels shows the sequence of actions that will be implemented.
On the right panel, we can select the available actions and tasks. The central panel list the actions previously selected and it indicates the sequence of implementation, or phases. In our simple case, we will have one single task of implementing the static route within an individual phase.
After the Change Request is created, it must be validated and approved. This ia normally performed by a separate team, but in our example, we will be taking care of this aspect as well.
During the Change approval process, the changes to be pushed to the nodes will be shown for the operator to review.
Once approved, the change is ready for execution.
The execution of the change is visible through the panel.
Finally, a Rollback can easily be called if the change does not bring the expected results.
In this brief article, we wanted to show how CloudVision is designed to manage and automate the configuration of network nodes within an integrated Change Management environment.
We introduced two basic components of the Network Management aspect: Configuration Hierarchy and Configlets. The first one is a way to group nodes based on common configuration aspects, rather than their position in the network. The second is used to build up nodes configuration through small segments of CLI commands to be reutilized throughout the infrastructure.
We then showed how Network Management is integrated into the Change Management process bringing separation between the roles of Change Execution and Change Evaluation. This makes CloudVision a useful tool to bring Change Management into those new environments that are willing to adopt this framework; for those organization where Change Control is already implemented, CloudVision can simply work as a network collector to integrate with the existing Change Management tools. For example, the Change Approval could be performed via Service Now.
Our conclusion is that CloudVision serves a dual purpose: on one side, it provides a turnkey solution to bring network management and automation into environments that have not yet adopted these advantages; for well-established realities, it can be used to provide the interface between the network layer and external tools already existing within the organization.