Elements of a topology file

The fabric topology described in a JSON configuration file can include the following elements, some of which are optional while others are mandatory:

  • identifying information for the topology itself
  • a set of nodes
  • a set of links
  • a set of device profiles
  • a set of interface profiles
  • LAG descriptions (for WBX only; this is not supported for an SR Linux topology)

The following tables describe each of these elements in detail.

Table 1. Topology identifying elements
Field Name Default Value Mandatory/Optional Description of use/requirement
name Mandatory The file must include a name for the topology.
description Optional Optionally, you can include a description for the topology.
Table 2. Node description
Field Names Default Value Mandatory/Optional Description of use/requirement
deviceProfile Mandatory You must include a reference to a device profile which must also be specified as part of the topology template. If the device profile does not exist within the template file, the import fails.
systemName Mandatory You must include the system name of the node. Upon import for a particular fabric, the fabric intent prefix is prepended to this name. Only one entry with the same system name is allowed per template.
deviceVendor Mandatory You must specify the following attributes for the node's device vendor:
  • operating system (for example, SRLinux)
  • software version (for exaple, 22.6.1)
  • vendor (for example, Nokia)

The system validates that the specified software is supported by the version in the software catalogue for the chassis type of the device profile.
lags Optional

You can include a list of LAGs that already exist on the device.

This value is only allowed if the node is considered unmanaged, meaning that the Fabric Services System itself is not managing the node configuration. For example, this vaue is supported for WBX nodes, but not for SRLinux nodes.

For more information about LAG data, see the table LAGs.
pod Optional You can include a label to identify a group of nodes.
rack Optional You can include a label to identify a grouping of nodes which reside in the same physical rack.
role Mandatory

You must include a role for the node.

Several roles are available to identify a node's position within the fabric hierarchy:

  • T1_LEAF
  • T2_SPINE
  • T3
  • BORDERLEAF
Table 3. LAGs
Field Names Default Value Mandatory/Optional Description of use/requirement
name Mandatory You must include a text string that is the name for a LAG.
Local name Mandatory
You must include the name of the LAG as specified on the device itself; for example, lag1
Note: A node must not include more than one LAG with the same local name.
Multi Homed True Mandatory You must indicate whether the LAG is multi-homed.
ports Mandatory You must include a list of ports that constitute this particular LAG.
Note: LAG information is supported only for unmanaged topologies, such as those consisting of 210 WBX nodes. For managed topologies, such as those consisting of SR Linux nodes, configure LAGs conventionally as you would for a non-imported topology.
Table 4. Device profile
Field Name Default Value Mandatory/Optional Description of use/requirement
name Mandatory You must include a name for the device profile.
description Optional You can include a description for the device profile
chassis type Mandatory You must include one of the following chassis types:
  • 210-WBX-32Q
  • 7220 IXR-D2
  • 7220 IXR-D2L
  • 7220 IXR D3
  • 7220 IXR D3L
  • 7220 IXR-D5
  • 7220 IXR-H2
  • 7220 IXR-H3
  • 7250 IXR-10
  • 7250 IXR-6
edge links Optional
You can include a list of edge links on nodes acting as a leaf, border leaf, or spine. Only interfaces which are valid according to the inventory for the chassis type are accepted.
Note: Edge links can be configured on spine nodes as part of a manual topology links, and these links will be available for use as subinterfaces in workload intents. This capability is not currently supported for fabric intents configured in the Fabric Services System GUI.

If a configured interface is not valid, the device profile is not accepted and an error results when generating the fabric configuration.

An edge link interface should not be allowed to overlap with an interface configured in a Link object. Overlapping entries are rejected and an error results when generating the fabric configuration.

An edge link should only be specified once for a device profile. Duplicate entries are rejected and an error results when generating the fabric configuration.
loopbacks Optional You can include set of loopback interfaces for the device.
interfaceGroups Optional Interface groups are used to group a set of interfaces within a device and apply an interface profile to the list of interfaces within the group.
Table 5. Interface groups
Field Names Default Value Mandatory/Optional Description of use/requirement
type Mandatory Defines the type of interface. Only "ISL" is currently supported.
interfaces Mandatory

A list of interfaces belonging to the group. Interfaces cannot belong to multiple interface groups.
interfaceProfile Mandatory A reference to an interface profile. If this is specified the profile must also be present within the topology definition. If the interface_profile is not specified then all interface parameters for the list of interfaces must use their default values (such as speed). Interface profiles can be referenced by multiple interface groups.
Table 6. Interface profiles
Field Names Default Value Mandatory/Optional Description of use/requirement
name Mandatory This is the name of the interface profile
breakout Optional

Breakout is a nested object which, if it contains any configuration, will dictate that the interface should use breakouts. The nested breakout object is defined separately.
forwardErrorCorrection rs-528 Optional For ISL ports, enables or disables Forward Error Correction (FEC) on the interface.
Supported values are:
  • base-r
  • disabled
  • rs-108
  • rs-528
  • rs-544
Note: The same port cannot be configured both as a breakout port and with FEC as part of the same interface profile. To configure a port as both broken-out and with FEC:
  1. First apply an interface profile that breaks out the port into multiple broken-out sub-ports.
  2. Then apply a different interface profile that includes FEC on the broken-out sub-port. Individual sub-ports could be configured this way with different FEC settings.
Table 7. Breakout
Field Names Default Value Mandatory/Optional Description of use/requirement
numChannel Mandatory The number of channels for the interface breakout. Values are validated per interface.
channelSpeed Mandatory

The speed of each channel. Values are validated per interface.
Table 8. Links
Field Name Default Value Mandatory/Optional Description of use/requirement
localNode Mandatory You must include the local node name. This must be a valid and existing node name in the topology template.
localPort Mandatory You must identify the interface on the local node that is attached to the remote port on the remote node. This interface cannot belong to more than one link and cannot be an edge link.

If the native interface has been broken out with a configuration in interfaceGroups, identify the broken-out port numbers.
remoteNode Mandatory You must include the remote node name. This must be a valid and existing node name in the topology template.

If the native interface has been broken out with a configuration in interfaceGroups, identify the broken-out port numbers.
remotePort Mandatory You must identify the interface on the remote node which is attached to the local port on the local node. This interface cannot belong to more than one link and cannot be an edge link.
isActive Optional You can indicate with a value of true or false whether the links should be active. If false, an IP address is allocated to the link but the Administrative status is not set to Up.
speed Optional You can indicate a speed for the link.
role Mandatory

You must indicate the relationship between the nodes in this link. Any link that does not fall into one of the existing roles can be assigned a generic ISL role.

Supported roles are:

  • T1_ISL_T2
  • T2_ISL_T3
  • T3_ISL_T4
  • ISL

Additional manual topology settings

When you create a fabric intent using a manual topology, you first import that topology and then configure the fabric intent using the Fabric Services System GUI. You have the opportunity on the Fabric Intents page to configure additional settings for the manual topoogy, including the selection of IP and ASN pools other than the default pools defined for the region.

For more information, see the procedure for creating a fabric using a manual topology.

Topology validation

When you import a topology into the Fabric Services System, the system performs several validation checks on the data in the selected topology.

For node-level data, the system verifies that:

  • If there are duplicate system names, only the first instance is accepted.
  • Every node has a valid device profile name that is defined in the device profile section.
  • For each chassis type, the software image version is equal to or greater than the version supported in the system's software catalog.

For link data, the system verifies that:

  • a valid node name is provided for the local node
  • a valid port is provided for the local port
  • a valid node name is provided for the remote node
  • a valid port is provided for the remote port
  • all ports for the local and remote nodes are unique
  • Any edge link removed as part of the imported topology were not configured with breakout in the previous version of the intent
  • any edge links removed as part of the imported topology are not already participating in a LAG
  • any edge links removed as part of the imported topology are not already participating in a workload
  • for ports participating in an inter-switch link (ISL), the configured port speed is supported by the ports on both ends of the link.
    Note: If a broken-out port is used in an ISL and the speed attribute is set on that link, the Fabric Services System checks that the speed value is the same as the channel speed of that broken-out port.
For edge port data, the system verifies that:
  • the port is valid based on the catalog for the device type.
  • each port used for edge links and ISLs is unique
For LAG data, the system verifies that:
  • each LAG name is locally unique.
  • no LAG data is provided for an imported topology intended for SR Linux nodes.
For breakout ports, the system verifies that:
  • The number of channels for the interface breakout is supported by the interface.
  • The speed of each channel is supported by the interface.