In this blog I will show you how to install Arista CloudVision Partal (CVP) and discuss the basic functions that can be performed through the portal. CloudVision is a solution for network management and work automation. The CloudVision portal can be managed via the interactive interface EOS CLI, eAPI or directly from the GUI. This tool allows you to build hierarchical configurations, monitor various system parameters in real time, change software versions and much more. The CVP works on ESX or KVM hypervisors and can be configured as a single server or cluster. Due to the scalability and redundancy, it is recommended to implement the cluster.
In this post I intend to demonstrate the implementation with one node due to the lack of computing resources on my home server. Arista’s official documentation says ESX and KVM are the recommended hypervisors for CVP. Due to the fact that I do not have ESX and KVM on my computer, I intend to run CVP on a VMWare workstation. Before I show you how to install CPV, I must first possess the right CVP image. CVP can be downloaded from the official Arista website, but only with a valid technical support contract.
In this example I will use OVA cvp-2019.1.2.ova template. I will first import the OVA template and then show you the basic steps required during the first installation.
It should be noted that OVE for CVP is quite resource-consuming and requires 16 CPUs and at least 22 GB of RAM. I was able to lower the processor requirements to 8 CPUs, which did not affect the operation of the system significantly.
After setting a new password, the screen will show the available list of configuration options, as shown in the screenshot below. In this example, I will show you how to install singlenode, which is why I chose the [s] option for singlenode.
When new password is setup you will see some available option for initial setup as shown below. In this example I am going to use singlenode deployment so I choose [s] option for singlenode.
Below I showed the initial configuration for my laboratory implementation. If all the information has been entered into the system, using the [v] option, we can verify the correctness of the configurations. If the verification was successful, we can save [s] the configurations.
The next step is to apply the configuration using option [a] as shown below. This process can take up to several minutes.
When the system completes the initial configuration and all required services are started, we should get access to the CVP portal. The first time you log in, you must log in with the default username cvpadmin and the default password cvpadmin. After logging in, you will be asked to enter a new password as below.
First, let’s look at the available options in the system settings. The new CVP version provides several additional functionalities compared to the previous version, they are available in beta, as can be seen in the screenshot below. In the system settings you can add new users and configure RBAC for them accordingly.
RBAC provides a lot of flexibility in creating access policies for individual users depending on the role and tasks they will have to perform when administering the system.
In the system settings you will also find other available options, such as Audit Logs, EOS Feature Licenses, Compliance, etc., but they are quite obvious and easy to understand. A fairly useful feature is Compliance, which uses an authentication token and integrates with the Arista portal to update the CVP bug database. This allows system to inform the administrator if the devices we manage are not expose to critical bugs.
The top menu contains various tabs such as Devices, Events, Provisioning, Metrics, CloudTracer, Topology and TapAgg. It allows us to access various system functionalities as described below.
- Devices: View all devices across multiple topologies.
- Events: View multiple events on multiple devices.
- Provisioning: Hierarchical tree structure of the network is maintained here. All the configuration and image assignment to the network switches are made via this module.
- Metrics: View multiple metrics across multiple devices.
- CloudTracer: CloudTracer metrics across multiple devices or hosts.
- Topology: View the location of devices in individual topologies.
- TapAgg: Use this app to manage tap aggregation clusters.
First, let’s look at the Devices tab, which contains information about all devices managed by our system. This tab allows us to access information about any given device that is monitored by the CVP. If we want to learn more about a particular device, just click the device we are interested in and then the system will display all the information, such as the version, the number of interfaces, CPU consumption, etc.
The screenshot below shows information about the LEAF01 device. This view provides a lot of useful information such as management IP address, uptime, MLAG status, information about VXLAN and other system parameters such as routing table, arp table, number of interfaces etc.
The Events tab is a centralized system log that contains information about each event displayed on the end device monitored by the CVP portal. This card is quite intuitive to use and will not spend too much time on it. Below is a screenshot showing the view of this card.
The Provisioning card is the one where you will probably spend most of your time. It is used to configure templates, create containers, manage images, and create and commit changes. I am going to devote more time to discuss this tab and show how to add a new device to the system, how to make configuration changes via the CVP portal, and send the desired configuration to the device.
Currently, I have several devices added to the system, but I will go through the process of manually integrating the new device with the CVP system, because before we add the device to the system we need to configure the switch so that the CVP portal can communicate with the device via the API.
Time to add a new device to the CVP. To do this, first you need to enter the following configuration on the switch, this will allow communication using the API.
Note: In this blog I will not discuss ZTP, which I will try to describe in another post.
SPINE02#sh run | sec api
management api http-commands
no shutdownTo register the device in CVP, go to Device-> Inventory and press Add Device
After clicking the Add Device button, a new window will appear in which you must enter the IP address of the device that you want to add to the system. In this example, it is the SPINE02 switch with the IP address 192.168.1.206.
After entering the IP address of the new device that we want to register in After entering the IP address of the new device you want to register in the CVP portal and pressing the Register button, the message “Registration in progress” will be displayed, as shown below. Please note that the user we used to log in to the CVP portal must have the appropriate administrative rights for the device that we want to add. In other words, it should be added statically to the device configuration if we do not use AAA, or have the appropriate permissions in the system we use for authorization. After successful registration, you should see information that ‘Registration was successful’ as highlighted below.
Now let’s return to the Provisioning tab to see if the new SPINE02 switch has been added correctly. As you can see, the device has been added to a special container called “Undefined“. This container is a type of placeholder for each newly added device to the system.
Based on the role of that switch I am going to move that SPINE02 box to a container called SPINE. To move switch from “Undefined” container to more specific one based on the role, you have to right click on that switch and select Move and then pickup destination container as shown below. Then press OK and Save button right at the bottom.
After saving the change, a yellow icon with the letter T should appear. This icon means that there is a pending task to be performed. Additionally, in the upper right corner there is a small icon that can take you directly to the Task tab or you can press the Task tab on the left.
Let’s go to the Task tab and see what options are available there. As you can see, there is one pending task to complete.
To perform this task, select it and press the Create Change Control button. When you do this, a new view will appear that will allow you to create a change as highlighted.
After creating the change, a new view will appear in the system with the option to accept the change and complete the task.
After confirming the change, you should see the view like below. This view informs you about the status of each task in a given change. While the system is making changes, you can view logs and monitor your work progress. In my case it shows that the task was completed successfully.
Looking again at the Provisioning tab, we can see that the SPINE02 switch has been correctly moved to the SPINE target container.
Now let’s try to implement some simple configuration into the SPINE container that will be sent to all switches belonging to this container. To prepare the basic configuration, you need to go to Provisioning -> Configlets and create a new configuration as shown below.
So let’s create a simple configuration that will contain information such as banner and domain. This configuration should appear on all devices in the SPINE container. When you create such a configuration, you should save it. The configuration prepared in this way can be used many times and assigned to different containers, it can be used e.g. as a standard that should be used on all devices managed by CVP.
The configuration prepared in this way must be assigned to a given container, in this example it is a SPINE container. To do this, go to the Provisioning Network tab and right-click on the target container and choose Manage->Configlet.
After pressing the Configlet button you will be taken to a new view, in which you can select a new created template and assign it to the target container. In my example there is a SPINE container. Before you save changes, you can verify the configuration and make sure it is correct and meets your expectations.
Now we need to accept the configuration changes by clicking the Update button. When you do this, you will return to the Network Provisioning view. Then you will see that your container along with all the devices in this container has turned green, as shown below.
After saving the change, the container and all devices belonging to this container will appear with a yellow icon and the sign “T”. This means that a task is pending.
Let’s check the configuration before making changes. To do this, I need to right-click one of the spine switches and then select Manage->Configlet
In the new window you will be able to see and verify the configuration before making changes. Here, you can add a new template if you need to add new functionalities. Lets. press validation button.
After pressing the validation button a new window will appear with the following information, the left column is the location where the proposed configuration is located, the middle column is the target configuration, and the column on the right shows the current configuration on the device. In this example, we can see that the banner and domain configuration will be added to the current configuration. Now just save the changes, which will create a configuration change task.
To make a change on devices, go to the Task tab and create a Control Change, then verify and confirm the change. I described these steps above, so it makes no sense for me to describe the same process again.
After confirming the changes, the system will show us exactly what changes will be made on the target devices. In the examples described, the target switches are in the SPINE container and they are the SPINE01 and SPINE02 swatches. As you can see, in the example below the banner and dns configuration will be added to the existing configuration on the target devices. If you look at the configuration update information, you will see that 2 lines (green) will be added, 0 will be updated (blue) and 0 will be reconciled (red).
Let’s make a change. During the change execution, the system will keep you updated on the progress of each task. All tasks are performed in parallel.
When task will be completed we can do final verification and look at the config.
To verify if the change was really push to the switch go to the Network To check if the change was really made on devices, go to the Provisioning Network tab and right-click on the switch and then select View-> Config.
I see that the change has been made on the switch, and the information about the banner is displayed in the right column, which represents the current configuration of the device. In addition, the middle column for the designated configuration shows all zeros for new lines, mismatch lines and reconciled line retrospectively. That means that our config on the switch is in syn with CVP.
The proces was successfully completed. As was demonstrated the CVP allows easily manage configuration, build hierarchical config dependency and push changes for hundreds devices at the same time.
What if I would like to remove the banner config, I just pushed to the switches, because I made typo or sent wrong banner description. Actually the process is very simple, you have to rollback the change. How can you do it? You have to go to the Change Control Tab click on your change and select Rollback Change as shown below.
Next you have to select all devices or specific one from the task list and create Rollback Change.
Now you need to approve and execute the rollback change. As you can see below on the picture the designated config on the left has not banner configuration. Now it’s enough to approve that change and execute it.
Finally my config was reverted and there is no more banner information.
The only thing to note is that after such process if you go to Network Provisioning Tab you will see your switches with yellow color as config is out of sync between your designated config and running on the box.
You have to go to each switch in the container and press configlet and validate the config , create new change control and push the config to make sure that
CloudVision is a next-generation tool that can be useful especially in a larger-scale enterprise environment and for those who do not have programability skills to write own scripts. The other thing I like about CVP, is that all of the Events and Telemetry data is streamed in real time such as bandwidth utilization, interface errors, memory usage, cpu utilization etc.
I next part I will look into Configlet again and show you more hierarchical way to built the config or remove even single line of code. In addition, I will go through image upgrade procedure.
netmindblog 