Primary elements of Metro Edge Fabric Manager

These are the primary elements of Metro Edge Fabric Manager:

• Fabric definition: is a container or database that is used to store all attributes of the fabric including the devices, their roles, and the connectivity between fabric devices.

• Role definition: is a container for a set of attributes which may be applied to multiple devices in the same role.

  The role definition must contain the topology role (leaf or spine) along with all required role attributes. The role definitions are located outside of a specific Fabric instance. So, they may be applied across devices in different fabrics.

• Fabric connectivity: is a part of a specific fabric instance that is used to define the connection between all devices and contains information about the type of connection and the explicit endpoints of the connection.

Components of Fabric-enabled ZTP

These are the high-level components of fabric-enabled ZTP.

Fabric

The Fabric Definition is the container or database used to store all attributes of the fabric including the devices, their roles, and the connectivity between fabric devices.

A fabric is defined along with device roles to be assigned to devices when onboarded.​

Sample configuration:

config xmlns="http://tail-f.com/ns/config/1.0">
  <fabrics xmlns="http://fabric.manager/edge-fabric-manager-instance">
    <fabric-id>edge123</fabric-id>
    <device-role>
      <device-role-name>xr-leaf</device-role-name>
      <device-model>N540-12Z20G-SYS-A</device-model>
      <topology-role>leaf</topology-role>
      <role-templates>
        <role-template-id>day1-leaf-l2vpn</role-template-id>
      </role-templates>
      <interface-template>
        <interface-template-id>leaf-interface-connection</interface-template-id>
      </interface-template>
      <target-os-version></target-os-version>
    </device-role>
    <device-role>
      <device-role-name>xr-spine</device-role-name>
      <device-model>NCS-5501-SE</device-model>
      <topology-role>spine</topology-role>
      <role-templates>
        <role-template-id>day1-leaf-l2vpn</role-template-id>
      </role-templates>
      <role-templates>
        <role-template-id>day1-leaf-l3vpn</role-template-id>
      </role-templates>
      <interface-template>
        <interface-template-id>leaf-interface-connection</interface-template-id>
        <interface-template-variables>
          <name>MTU</name>
        </interface-template-variables>
      </interface-template>
      <target-os-version></target-os-version>
    </device-role>
  </fabrics>
</config>

Device role

The role definition is at the global <fabrics > level and you can use it across different fabrics.

Along with attributes such as device role name, device model, the device role in turn contains these templates:

• Role templates: templates defined under a role that are applied when the device is added to the fabric with a specific role. ​

  You can apply multiple configuration templates for a single role.

• Interface templates: templates that are applied when a fabric connection is made between two devices.

  Variables inside this template refer to template variables. The variables are assigned values when a device or a connection is added. ​

Sample configuration:

    <device-role>
      <device-role-name>xr-leaf-xvpn</device-role-name>
      <device-model>NCS-5501-SE</device-model>
      <topology-role>spine</topology-role>
      <role-templates>
        <role-template-id>day1-leaf-l2vpn</role-template-id>
      </role-templates>
      <role-templates>
        <role-template-id>day1-leaf-l3vpn</role-template-id>
      </role-templates>
      <interface-template>
        <interface-template-id>spine-interface-connection</interface-template-id>
        <interface-template-variables>
          <name>MTU</name>
        </interface-template-variables>
      </interface-template>
      <target-os-version></target-os-version>
    </device-role>

Supported FSLM base functionalities

FSLM supports these base functionalities:

• Upgrade or downgrade single device based on {fabric, device}

• Upgrade or downgrade a set of devices based on {fabric, role}

• Upgrade or downgrade all devices based on {fabric}

• Upgrade cycles including the use of GISO for evolved XR (eXR) and XR7 operating systems

• Pre- and post-operations on the device and adjacent fabric devices that can be used for pre- and post-upgrade checks

• The dry-run capabilities to determine devices that are not running their target software version

• Upgrades as a set of atomic functions—for example, software download (staging), software upgrade, and software commit

Unsupported FSLM functionalities

FSLM does not support these functionalities:

• Automated graceful maintenance: the upgrade use case does not cover moving traffic off the node being upgraded. You can modify your own pre-check and post-check scripts as needed to perform these tasks.

• Service awareness

• User-guided interaction

FSLM Components

FSLM involves these components:

• CX NSO OS Upgrade application

• Crosswork Workflow Manager (CWM)

Configuration template versioning

Configuration template versioning is done in two ways:

• Template versioning managed by the user: When a new template is built for a role, use a different name for the template and update the template being used in the fabric manager role definition.

• Templates stored with a revision number: Templates in NSO used for fabric management will be stored with a revision number. When a device is onboarded into the fabric with a specific role, the latest version of the template referenced in the role definition is used for configuration. At the device level, we also record the latest role and interface templates assigned to the device.

Device template compliance check and remediation

The compliance action starts with a CWM workflow that is used to first determine which devices are using a non-compliant template and then remediation of the device by deploying the correct template.

In the Fabric Manager, the compliance action is used with the config type to check each device to make sure that it is utilizing the correct template. The enforce-compliance API call is then used with the config type along with the list of devices to deploy the correct template.

Configuration enforcement dry-run

The configuration compliance includes a dry-run capability to see the changes prior to device provisioning.

Use this existing command in the CX Fabric Manager:

edge-fabric-actions enforce-compliance enforce-compliance-type config-compliance commit-type dry-run response-type show-dry-run fabric-details { fabric-id edge123 devices { device fabric-leaf2 } }