The tags used in the Static Configuration Studio are user tags assigned to devices. A user tag identifies one or more devices, and the tag is assigned to a container.

There are some built in tags like device: *, which identifies all devices registered to studios; or device: <hostname>, which identifies a single device. You can also create your own custom tags in Tags and assign devices to them.

Typically, you will use the tags created in other studios. For example, the Campus Fabric (L2/L3/EVPN) Studio creates a Campus: <campusName> tag for each network. If a network called HQ is created, all devices in that network will have the tag Campus: HQ. You can assign all devices in that network to a container using the Campus: HQ tag. Similarly, you could use the Campus-Pod or Access-Pod tags to target specific campus pod and access pod devices.

The Hierarchy section explains how you can use the container hierarchy to further refine which device tags are targeted, such as a specific campus pod in Campus: HQ.

Containers are arranged in a tree-like hierarchy of parent and child containers that control device rules of inheritance. Devices in containers lower down in the tree must have the tags of all parent containers higher in the tree in order for configlets to be pushed to them.

The following image shows a simple tree-like structure of containers relating to two data centers. Devices must be assigned any parent container tags for a container’s configlets to be pushed to them.

A more complex example shows a data center where specific configlets are pushed to devices depending on the pod they belong to. Another container stands outside the DC:HQ hierarchy, which contains configlets pushed to all devices regardless of what pod or data center they belong to.

The hierarchy can be understood as follows:

• device:* applies to all devices registered to Studios

  • DC:HQ applies to all devices only with this tag

    • DC-POD:1 applies only to devices that have this tag and the DC:HQ tag.

While spine devices in both DC-POD:1 and DC-POD:2 have the same Role:Spine tag, the hierarchical structure means that only configlets within either Role:Spine container will be pushed to devices with the parent container tag. Therefore, devices with the tag DC-POD:1 will only receive configlets from the Role:Spine container under the DC-POD:1 container, and similarly, for devices with the DC-POD:2 tag.

By contrast, configlets assigned to the last container, Role:Leaf, will be pushed to all leaf devices because the parent container has the tag device:* assigned to it. This way, devices can be associated with multiple containers and hierarchies.

CloudVision uses several configuration sources. To create and maintain a single designed configuration, a hierarchy exists for CloudVision to determine which configuration source is used to compile the designed configuration. This means that where different sources provide overlapping EOS commands, one source takes precedence over another.

This hierarchy can cause you to see missing or unexpected configuration when using Studios or Network Provisioning. You can use Config Sources in the Configuration of a selected device to view the configuration source to help resolve these issues.

CloudVision begins with the lowest-ranked source when creating the designed configuration and will then overwrite that configuration with a higher-ranked source.

The process CloudVision moves through from lowest ranked to highest ranked is:

Network Provisioning's reconciled configlets are the highest ranked source. Each source has its own internal ranking, which is explained in further detail below.

The Static Configuration Studio is preferred to any configuration sources from Network Provisioning and other studios. It has its own internal hierarchy for how configuration is assigned to devices, can be understood in the following example:

Configuration in child containers takes precedence over any parent containers. The Access-Pod:* container will overwrite any conflicting configuration supplied by the Campus-Pod:* and Campus:NYC containers.

For sibling containers, the bottom container in the tree will take precedence over sibling containers higher in the tree. The Campus-Pod:Downtown container will overwrite conflicting configuration from the Campus-Pod:Midtown and Campus-Pod:* containers.

Understanding the parent-child and sibling precedences together, the Access-Pod:Three container overwrites conflicting configuration from all parent containers and their siblings.

When multiple configlets are assigned to a container, the precedence is ordered from left to right. This means that any conflicting configuration between a configlet to the left and configlet to the right is overwritten by the configlet on the right.

You will need to create a new container when you want to associate a configuration with a specific set of tagged devices. Placing containers in a hierarchy allows you to further refine which tagged devices receive configuration assignments, because the hierarchy of containers forms a relation chain based on tags.

Once you have created your hierarchy, you can add configlets to containers.

Devices that already have the tag assigned to a container will have that container’s configuration pushed to them. You will only need to add devices when they do not have the container’s tag or you want to create a device-specific container. A device-specific container is for configlets that only apply to one device.

In most cases, adding a device should only be relevant for device-specific configuration; any new devices configured in another studio will automatically be assigned the tags of that studio.

For example, assigning new devices to an existing leaf domain in the L3 Leaf-Spine Studio will tag those devices with the relevant DC: tag, the DC-Pod tag, and Leaf-Domain tag. However, if you created a new leaf domain, you will need to add a new Leaf-Domain container to your Static Configuration Studio container tree.

Adding a device will assign the device to the tag associated with the container. To add devices to a container:

Configuration associated with the selected container and any parent containers will be pushed to the devices once the workspace is submitted and its associated change control executed.

A configlet is a set of EOS commands with a defined scope that form part of the device’s running configuration when pushed to devices. You will define the EOS commands of a configlet in a text editor by creating a new configlet or editing an existing configlet.

If you edit any configlets already assigned to tagged devices, that new configuration will be applied to each assigned device. In this way, configlets provide a way to change the configuration of multiple devices at once.

Config Library

All configlets you create in the Static Configuration Studio are stored in the Config Library. This library allows you to view and edit configlets. It also serves as a repository from which you can repeatedly assign configlets to containers.

The status of a configlet shows whether it is unused, assigned to a single container, or shared across multiple containers.

The container hierarchy can be further customized with match rules. The two rules allow you to define how the devices associated with sibling containers have configlets pushed to them.

The match rules operate in a top-down hierarchy from the parent container. The hierarchy of containers is complemented by match rules. These rules further control how configlets are pushed to child containers.

Match First

The match first rule will only push configlets to devices that have not already received configlets from a sibling container.

In the following diagram, Device D has the tag DC-Pod: 4. Only Device D receives configlets from Container 3, because all other devices have already received configuration from sibling containers.

Match All

The Match All instruction will push configlets to all child devices with matching tags.

Match Rule Example

The following example shows the match rules combined with container hierarchy for four devices. There are two campus tags that associate devices with the Google and Azure containers. Match rules allow you to control which configlets are assigned on a per-device level when devices match multiple containers.

Notice how using the Match First Policy allows us to control which configlets are assigned to a device. Device A and B match both the Google and Azure containers due to the Campus: NY tag. But by using the Match First Policy, they do not inherit the configlets in the Azure container because they matched the Google container first. The order of the containers is controlled by the operator, by dragging and dropping them in the Static Configuration Studio UI.

You will create a new container when you want to push configlets to a specific set of devices. These devices are identified by a tag, which is assigned to the container.

When the workspace is submitted, a change-control is created, and when executed the configlets are pushed to devices with the container’s assigned tag.