fbpx

Network-Engineering | 7 min read

CloudVision – Configuration Hierarchy

December 2020
written by Francesco Vestri
Senior Network Engineer

Learn how to use CloudVision to manage your network and introduce Change Management in your organization.

Introduction

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.

Network Management

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.

Cloud Vision - Configuration Hierarchy

Configuration Hierarchy

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.

Cloud Vision - Configuration Hierarchy

Containers

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.

Configuration Hierarchy

New Container

And move some devices under this newly created container.

Configuration Hierarchy

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

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.

Cloud Vision - Configuration Hierarchy

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.

Configuration Hierarchy

Configuration Hierarchy

Before the application, the new configuration lines are presented for review and confirmation.

Cloud Vision - Configuration Hierarchy

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:

Task

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

Cloud Vision - Configuration Hierarchy

Select the node that will receive the Configlet

Cloud Vision - Configuration Hierarchy

Apply configlet to the node

Cloud Vision - Configuration Hierarchy

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.

Cloud Vision - Configuration Hierarchy

The Task is available from the list.

Cloud Vision - Configuration Hierarchy

The Task details indicate the actions that will be performed on the node.

Cloud Vision - Configuration Hierarchy

Now, the last step is instructing CloudVision on how and when to execute this new task.

Related Service See how we help businesses with our network engineering services:
Network Engineering We provide engineering services for over the whole lifecycle process. See more

Change Request

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:

  1. planning the Change Request
  2. having the Change Request approved
  3. scheduling the execution of the Change Request
  4. validating the Change effects – and –
  5. 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.

Cloud Vision - Configuration Hierarchy

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.

Cloud Vision - Configuration Hierarchy

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.

Cloud Vision - Configuration Hierarchy

Once approved, the change is ready for execution.

Cloud Vision - Configuration Hierarchy

The execution of the change is visible through the panel.

Cloud Vision - Configuration Hierarchy

Until completion.

Cloud Vision - Configuration Hierarchy

Finally, a Rollback can easily be called if the change does not bring the expected results.

Cloud Vision - Configuration Hierarchy

Conclusion

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.

December 2020
written by Francesco Vestri
Senior Network Engineer

Most Popular

Network-Engineering | 8 min read

Junos upgrade – filesystem is full

Not enough storage during Junos upgrade (EX2300 and EX3400). An extension of Juniper's article…

Read more

Get your Free Gartner PDF: Magic Quadrant for Data Center and Cloud Networking