Device Profiles
Device Profile Overview
Device profiles define capabilities of supported hardware devices. Some feature capabilities have different behaviors across NOS versions and thus, capabilities are expressed per NOS version. By default, the version matches all supported versions. As additional hardware models are qualified, they are added to the list of qualified devices.
Device profiles are associated with logical devices (abstractions of physical devices) to create interface maps.
The following sections describe device profile parameters.
Summary
| Summary Section | Description |
|---|---|
| Name | Name of device profile. 64 characters or fewer. |
| Number of slots | Number of slots or modules on the device. Modular switches have multiple slots. |
| Start from ID |
Selector
The Selector section contains device-specific information to match the hardware device to the device profile as described below:
| Selector Section | Description |
|---|---|
| Manufacturer | Selected from drop-down list |
| Model | Determines whether a device profile can be applied to specific hardware. Selected from drop-down list or entered as a regular expression (regex). |
| OS family | Defines how configuration is generated, how telemetry commands are rendered, and how configuration is deployed on a device. Selected from drop-down list. |
| Version | Determines whether a device profile can be applied to specific OS versions. Selected from drop-down list or entered as regex. If the OS version of a device doesn't match the OS version of the device profile, then the device will be in the ERROR state (Devices > Managed Devices). |
Capabilities
You can leverage the hardware and software capabilities defined in this section in other parts of the Apstra environment to adapt the generated configuration, or to prevent an incompatible situation. With the exception of ECMP, hardware capabilities modify configuration rendering or deployment. Capabilities include the following details:
| Capabilities Section | Description |
|---|---|
| CPU (cpu:string) | Describes the CPU architecture of the device. For example: "x86" |
| Userland (bits) (userland:integer) | Type of userland (application binary/kernel) the device supports. For example: "32" or "64". |
| RAM (GB) (ram:integer) | Amount of memory on the device. For example: "16" |
| ECMP limit (ecmp_limit:integer) | Maximum number of Equal Cost Multi Path routes. For example: "64". This field changes BGP configuration on the device (ecmp max-paths). |
| Form factor (form_factor:string) | Number of rack units (RU)s on the device. For example: "1RU", "2RU", "6RU", "7RU", "11RU","13RU" |
| ASIC (asic:string) | The switch chipset ASIC. For example: "T2", "T2(3)", "T2(6)", "Arad(3)", "Alta", "TH", "Spectrum", "XPliant XP80", "ASE2", "Jericho". Used to assist telemetry, configuration rendering and VXLAN routing semantics |
| LXC (lxc_support: boolean) | Selected if the device supports LXC containers. |
| ONIE (onie: boolean) | Selected if the device supports ONIE. |
Supported Features (Cisco only)
COPP - When Control Plane Policing is enabled (COPP), strict CoPP profile config is rendered for the specified NX-OS version resulting in the following configuration rendering:
terminal dont-ask copp profile strict
This terminal dont-ask config is needed only when enabling the CoPP profile strict config, since we do not want NX-OS to wait for confirmation:
switch(config)# copp profile strict This operation can cause disruption of control traffic. Proceed (y/n)? [no] ^C switch(config)# switch(config)# terminal dont-ask switch(config)# copp profile strict switch(config)#
CoPP is enabled by default, except for Cisco 3172PQ NXOS. You can specify multiple versions.
Breakout - Enable breakout to indicate that ports on specified modules can be broken out to lower speed split ports.
Apstra software first un-breakouts all ports that are breakout-capable, and then
applies the proper breakout commands according to intent. This is based on the
assumption that the global negation command no interface breakout
module<module_number> can always be applied successfully to a
module with breakout capable ports. (This is idempotent when applied on ports
that are not broken out.) However, we recognize that this assumption may be
broken in future versions of NX-OS, or with a certain combination of cables /
transceivers inserted into breakout-capable ports.
The example below is for the negation command for a module (1) that is set to True:
no interface breakout module 1 !
Since the negation command is always applicable per module, each module is specified individually. The advantages of this include:
- In modular systems, not all line cards have breakout capable ports.
- In non-modular systems, the breakout capable ports may not always be in module 1.
Breakout is enabled by default except for the following devices with modules incapable of breaking out ports: 3172PQ NXOS, 9372TX NXOS, C9372PX NXOS, C9396PX NXOS, NXOSv.
Historical Context - With a particular version of NX-OS the POAP stage would apply breakout config on those ports which are breakout capable. POAP behavior, introduced in 7.0(3)I4(1) POAP, determines which breakout map (for example, 10gx4, 50gx2, 25gx4, or 10gx2) brings up the link connected to the DHCP server. If breakout is not supported on any of the ports, POAP skips the dynamic breakout process. After the breakout loop completes, POAP proceeds with the DHCP discovery phase as normal. Apstra reverts any such breakout config that might have been rendered during the POAP stage to ensure that the ports are put back to default speed by applying the negation command.
Sequence Numbers Support - Applicable to autonomous system (AS) path. Enable when the device supports sequence numbers. Apstra sequences into the entry list to resequence and generate config as follows:
ip as-path access-list MyASN seq 5 permit ^$ ip as-path access-list Rtr seq 5 permit ^3 ip as-path access-list Srvr seq 15 permit _103$
The numbers 5 and 15 are sequence numbers applicable to devices that support AS sequencing.
Sequence numbers support is enabled for all Cisco device profiles by default (except Cisco 3172PQ NXOS, which does not support sequence numbers). For platforms that do not support sequence numbers, disabling this feature ensures that the AS sequence numbers are removed from the device model dictionary to avoid addition and negation in the event that something is resequenced. This scenario has no requirement to render anything on these platforms, because the entry can't be sequenced.
Other supported features - not available from the Apstra GUI include "vxlan", "bfd", "vrf_limit", "vtep_limit", "floodlist_limit", "max_l2_mtu", and "max_l3-mtu". They can be included in the backend using the following format:
key : value :: feature : feature_properties Example: 32 vtep_limit: 32
Ports
The ports section defines the types of available ports, their capabilities and how they are organized.
Every port contains a collection of supported speed transformations. Each transformation represents the breakout capability (such as 1-40GBe port breaking out to 4-10GBe ports), and hence contains a collection of interfaces.
Example: If port 1 is a QSFP28 100->4x10, 100->1x40 breakout capable port, then port 1 has a collection of three transformations, one each for 4x10, 1x40 and 1x100 breakouts. The transformation element in the collection which represents the 4x10 has a collection of 4 interfaces, 1x40 and 1x100 has a collection of 1 interface.
Ports parameters include the following details:
| Ports Section | Description |
|---|---|
| Port Index (port_id: integer) | Indicates a unique port in the collection of ports in the Device Profile. |
| Row Index (row_id: integer) | Represents the top-to-bottom dimensions of the port panel. Shows where the port is placed in the device's panel. For instance, in a panel with two rows and many columns the row index is either "1" or "2". |
| Column Index (column_id: integer) | Represents the left-to-right dimensions of the port panel. Shows where the port is placed in the device's panel. For instance, in a panel with thirty-two ports and two rows, the column index is in the range of "1" through "16". |
| Panel Index (panel_id: integer) | Indicates the panel that the port belongs to given the physical layout of ports in the device specification |
| Slot ID (slot_id: integer) | Represents the module that the port belongs to. A modular switch has more than one slot. In fixed function network function devices, Slot ID is usually "0". |
| Failure Domain (failure_domain_id: integer) | Indicates if multiple panels are relying on the same hardware components. Used when creating the cabling plan to ensure that two uplinks are not attached to the same failure domain. |
| Connector Type (connector_type: string) | Port transceiver type. Speed capabilities of the port are directly related to the connector type, given that certain connector types can run in certain speeds. For instance, "sfp", "sfp28", "qsfp", "qsfp28". |
| Transformations (transformations: list) | Possible breakouts for the port. Every entry is a specific supported speed. Each transformation has a collection of interfaces. |
| Number of interfaces (interfaces:list) | Dependent on the breakout capability of the port. For a transformation representing a certain breakout speed, the interfaces contain information about the interface names and interface settings with which the device intends to be configured. The "setting" information is crucial for configuring the interfaces correctly on the device. |
Based on the OS information entered in the device profile's selector field, the Apstra GUI displays the applicable settings fields. The fields vary with the vendor OS (as found in examples below). When a device profile is created or edited, the "setting" is validated from the vendor-specific schema as listed below.:
eos_port_setting = Dict({
'interface': Dict({
'speed': Enum([
'', '1000full', '10000full', '25gfull', '40gfull',
'50gfull', '100gfull',
])}),
'global': Dict({
'port_group': Integer(),
'select': String()
})
})
nxos_port_setting = Dict({
'interface': Dict({
'speed': Enum([
'', '1000', '10000', '25000', '40000', '50000',
'100000',
])}),
'global': Dict({
"port_index": Integer(),
"speed": String(),
"module_index": Integer()
})
})
junos_port_setting = Dict({
'interface': Dict({
'speed': Enum([
'', 'disabled', '1g', '10g', '25g', '40g', '50g', '100g'
])}),
'global': Dict({
'speed': Enum([
'', '1g', '10g', '25g', '40g', '50g', '100g'
]),
"port_index": Optional(Integer()),
"fpc": Optional(Integer()),
"pic": Optional(Integer())
})
})
sonic_port_setting = Dict({
'interface': Dict({
"command": Optional(String()),
"speed": String(),
"lane_map": Optional(String())
})
})
})Apstra does not necessarily use all the information above for modeling. It's made available to other Apstra API orchestration tools for collection and use.
View Device Profiles
From the left navigation menu in the Apstra GUI, navigate to Devices
> Device Profiles to go to the device profile table view.You
can create, clone, edit, and delete device profiles. 