Device Profiles Introduction

Summary

Selector

The Selector section contains device-specific information to match the hardware device to the device profile as described below:

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:

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:

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.