Cumulus Device Profile

Device profiles are how devices are recognized and used inside Apstra. They capture device-specific semantics, which are required for being discovered by Apstra and to run network configs that work well for the datapath once inside the blueprint.

Device profiles are REST entities, which enable you to create, edit, delete, and list during the design phase. Device profiles are used to create interface maps, which get directly used inside the Apstra config rendering engine when blueprints are deployed.

This document covers the knowledge required to create (and edit) a semantically correct Cumulus DP, so that not only does it pass the validations in place in Apstra which ensure the right DP is created in the database, but also honors the vendor semantic requirement applicable to the device so that it does not result in deploy failure when the generated configuration is pushed to the network device.

To create a device profile, you need the device specification (usually released by the vendor). You also needs to know how to translate these specifications into Apstra DP data model so as to create the valid and config-friendly JSON. This is because the DP is a vendor semantics aware data structure.

The high level data model is the same for all DPs, i.e. there are the same keys for every vendor’s DP, just the way we get the values might differ, or might be loaded with a vendor constraint. The document enlists the following:

• The schema of the DP and the nested elements inside the DP.
• The meaning of each key value pair in the schema.
• The vendor specific recipe the values are populated.
• List any constraints, corner cases which need to be considered, especially for port configurations for certain (group of) models.
• Any lessons learnt along the way creating those DPs already in production useful in creating future ones.

When you create device profiles from the Apstra GUI, some of your entries are semantically validated. It's not completely capable of ensuring deep vendor-specific constraints and requirements though. With the exact vendor specification, the GUI assists you with creating a semantically valid DP which becomes part of the Apstra database data model.

Alternatively, you can write your own Python code that contains the vendor specifications, normalize it as per Apstra DP data model and generate the json to then import with the GUI.

This section discusses the general DP data model in order to set the ground for Cumulus specific details. Some of the optional fields might not apply to Cumulus and we will discuss those in more detail in subsequent sections.

Here is the front panel of the device Edgecore AS5712-54X as seen on the vendor's data specification. Some of the elements of the device are marked to highlight how they map in the Apstra device profile model.

Key	Value data type	Value required(R) or optional(O)	Meaning	Purpose/Examples
id	string	R	The id of the device profile REST entity, needs to be unique	The DP is a rest entity like some of the other AOS elements like logical device and IM etc. Each need a unique identifier which is also used as an index into the database when looking up DPs.
failure_domain_id	int	R	When a device has multiple failure domains, this represents the one that is currently active.
hardware_capabilities	dict	R	Captures those specifications of the device which are purely hardware	AOS needs a way to capture some of the HW capabilities which identify the device or highlight some of its unique strengths like ram, cpu, ecmp limit etc
userland	int	R	The type of application binary/kernel that the device supports. Usually this value is 32 or 64.
copp_strict	list	O	when set to ' 'True, generate strict copp ' 'profile config for NXOS	This field is used in the nxos jinja files to generate the config. Usually for most models, this value is True, except for models like Cisco 3172 and Cisco nxosv
breakout_capable	list	O	When set to true for a module, indicates that ports of that module are breakout capable
ram	int	R	How much memory does the device have	The unit is GB.
asic	string	R	Type of chipset on the device	Example: “T2”, “T3”, “Arad (3) ”, “Alta”
as_seq_num_supported	list	O
form_factor	string	R	How much rack space/units does the device need	Examples: ‘1RU’, ‘2RU’, ‘7RU’, ‘13RU’
ecmp_limit	int	R	Maximum number of next hops for ECMP routes	This field changes the BGP configuration on the device (ecmp max-paths)
cpu	string	R	What is the cpu architecture of the device. Note: AOS can only support "x86" if users intend to use onbox device agents because of TACC limitations. If the users intend to use offbox agents, then there is no such restriction.	Example: ‘x86’
label	string	R	A human readable name for the DP
software_capabilities	dict	R	A device might have some unique software capabilities.AOS requires these fields to have been set correctly for proper config rendering and deployment.
onie	bool	R	Does the NOS support onie
lxc_support	bool	R	Does the device support LXC containers
slot_count	int	R	How many slots does the device have	If the device is a modular device, it will have a non-zero slot_count.
selector	dict	R	The selector information is used by the AOS to match the DP to the actual device. Each of the four fields in the selector need to exactly match the ones as derived from the device.	As part of device bring up, the device agent does an exact match on each of these fields to successfully assign the DP to the device. Unless this happens, the device cannot be made part of AOS
os_version	string	R	Regex for the OS version on the device. AOS will use this regex from the DP to match and assign a system device to a DP
model	string	R	Regex for the Model information as seen on syseeprom that AOS will use to match and assign a system device to a DP
os	string	R	Regex for OS name that AOS will use to match and assign a system device to a DP
manufacturer	string	R	Regex of vendor/manufacturer that AOS will use to match and assign a system device to a DP
ports	list	R	Number of ports that the device specifies.	Port is a physical entity on the device as seen from the switch’s front panel
panel_id	int	R	Being a per port field, This field is used by UI to display the rows and columns. For devices where the ports are divided between multiple panels, user will need to rightly map ports to the correct panel	panel_id is informational only at this point. The Apstra GUI uses this information to geometrically place the ports as close to how they appear on the device’s physical front panel.The panel_id is not used in the config rendering engine inside AOS and is purely for cosmetic mapping between the physical appearance of the ports on the device to that on AOS UI port display.
slot_id	int	R	Being a per port field, this represents the module/slot this port belongs to. For modular devices, there will be multiple slots.
connector_type	string	R	Being a per port field, this records the connector type for the physical port
row_id	int	R	This is used to represent the port layout. User can see the specification and figure out how many rows the layout has and the row ID for this port.
column_id	int	R	This is used to represent the port layout. User can see the specification and figure out how many columns the layout has and the column ID for this port.
transformations	list	R	Transformations capture the breakout capabilities of the port. If a port is 40G->4x10G, there will be 2 transformations. There is at least one transformation per port, because every port is capable of at least one speed.
is_default	bool	R	Being a per transformation field, this represents if the speed this transformation represents is the default speed of the port. This information can be read from the spec. For example for a qsfp28 port, the default speed is 100G, so the transformation with 100G interfaces sets the is_default to True
interfaces	list	R	This is a per transformation field. For the 4x10G transformation, there will be 4 active interfaces, each capable of 10G. Similarly for the 40G transformation, there will be one active interface with speed 40G.	Interfaces are the effective port state when put in a breakout mode.
state	string	R	Per interface field. Represents if it is active or inactive interface. This field is useful when building IMs using this DP, especially for models with inter-port constraints	On certain vendors like EOS, the OS expects inactive and active interfaces in the config. For example, in a 40G->4x10G, transformation #1 will have 1 active 40G interface and 3 inactive interfaces. Transformation #2 will have 4 active 10G interfaces. Example values: “active” , “inactive”
setting	string	Optional	Per interface field. This captures the vendor specific command to apply an interface speed andand to bring the port into selected breakout mode.
speed	dict	Optional	Per interface field. This represents the speed this interface is to run once configured on the device.
unit	string	R	Per speed field, represents the speed unit
value	int	R	Per speed field, represents the speed value
name	string	R	Per interface field, this is the name of the interface as the vendor/operating system requires the name when the interface is configuredin the selected breakout transformationon the device. This is a semantic heavy field.
interface_id	int	R	A unique identifier which is used to ID the interface in the database.
transformation_id	int	R	A unique identifier which is used to ID the transformation in the database.
port_id	int	R	A unique identifier which is used to ID the port in the database.

Entering the correct information in all the 4 fields of the selector is critical for the device to get matched to the device profile.

In the following table, mostly column 4 is enough for us to get all the 4 fields. Column 5 discusses a little more in detail how Apstra gets these fields and processes in Python. Reading Column 5 helps the user gain certainty, nevertheless it is not necessary if one logs into the box and is able to read the file, type the commands and manually human-read this simple information.

Reference: Read this link` to understand the Cumulus TLV codes for the sys eeprom fields.

General Example output of a typical Cumulus device syseeprom information.

Now, let's try and apply these to an example in Apstra, let's pick Accton 5712-54X.

Selector field	Value	Example	What files on the device have this information	[Extra information] Python processing to get the exact fields after we run the command/read the file
model	0x21	5712-54X-O-AC-F	decode_syseeprom_command = "/usr/cumulus/bin/decode-syseeprom"	Not much, read the syseeprom, use the 0x21 value in TLV
manufacturer	If 0x2D in syseeprom, 0x2D else 0x2B	Edgecore	decode_syseeprom_command = "/usr/cumulus/bin/decode-syseeprom"	Not much, read the syseeeprom, use the (0x2D or 0x2B )value in TLV
version	cat /etc/lsb-release, pick the DISTRIB_RELEASE	3.7.3	lsb_release_file = "/host_etc/lsb-release"	cumulus_info = read the lsb-release file match = re.search(r'%s=(.+)' % re.escape('NAME'), cumulus_info) value = match.group(1) if value[0] == value[-1] and value[0] in """: value = value[1:-1] return value.split(" ")[0]
OS family	cat /etc/os-release, pick the first part of the NAME	Cumulus	os_release_file = "/host_etc/os-release"	Read the file cumulus_info = <file contents> match = re.search(r'%s=(S+)' % re.escape(‘DISTRIB_RELEASE’), cumulus_info) return match.group(1)

Using the above gotten information to Accton 5712 54X’s selector as displayed in UI:

What makes the Apstra SDK generators fast tools when it comes to generating the JSONs is using some of the knowledge specific to a vendor and re-using them in Python code to generate more than one DP. Commonalities across models are set as defaults. While every field in the DP should be populated per device carefully consulting the specification, one can also use these defaults as a reference when populating the fields.

Field	Default value	Meaning
ports	-NA- (list)	Ports for a device are one of those things which mostly vary by device. There is no point in having a default for ports, more often than not it won’t be used.
label	-NA- (string)	Every label needs to be unique, so a default does not apply
slot_count	0 (int)	Affects config. For non-modular devices, leave this 0. For modular device, this is the number of linecards excludes the supervisor units.
id	No default. When user is constructing json, make sure to provide a unique string as id for the DP. This is especially applicable when user builds the json and imports the payload into AOS using the REST POST/PUT API. However, if the user uses the UI to populate the fields, the UI prompts for the label but assigns an id behind the scenes. Nevertheless, this id field is required for a valid DP.
os_version	"(3\.[5-7]\.\d+)" (string)	Usually the default reflects the versions as supported by AOS for the release. As of AOS 3.1.1 we support 3.5-3.7. AOS maintains an officialfeature matrix by NOS herehttp://docs.dc1.apstra.com/feature_matrix.html The os_version value in the DP is more permissive than what is officially certified, to facilitate experiments of (not officially supported) OS versions for given hardware model.

If you have the device specification, you can obtain its hardware and software capabilities for entry into the device profile.

The table below contains commonly found values in Cumulus devices (based on qualified devices).

Selector Field	Value	Description
userland	64 (int)	This does not affect config as of AOS 3.1.1
form_factor	‘1RU’ (string)	This does not affect config as of AOS 3.1.1
ecmp_limit	64 (int)	This does not affect config as of AOS 3.1.1
asic	‘T2’ (string)	AOS looks at this for certain scenarios like Cumulus release noteRN 766. The RN states that on the Broadcom Trident II+, Trident 3, and Maverick platforms, in an external VXLAN routing environment, the switch does not rewrite MAC addresses and TTL, so packets are dropped by the next hop. To configure this, the asic field is looked at in conjunction with the os version field to determine if RN766 applies to the DP/device version and if yes, to handle it accordingly.
cpu	‘x86’ (string)	This does not affect config as of AOS 3.1.1
ram	16 (int) (Note, the unit is in GB)	This does not affect config as of AOS 3.1.1
onie	True (bool) (default)	This does not affect config as of AOS 3.1.1
lxc	True (bool) (default)	This does not affect config as of AOS 3.1.1

Note:

You are not required to configure any extra configurables for "supported features" for Cumulus device profiles. Thus the GUI says "no supported features".

Every interface per transformation per port per device profile requires a setting.

This port setting is used by the configuration renderer (jinja files) to correctly configure the interfaces on the device. The DP allows you to configure these for the device. Thus, it is very important these setting fields are populated correctly in the DP. In this section, we will look at what is the schema Apstra enforces for Cumulus port settings.

Example port setting:

Where is this field found: If you have 32 ports, each port capable of 40G and 4x10G, you will have:

• 2 transformations per port
• 1 active interface in 1st transformation; setting can be found in each of these interfaces
• 4 active interfaces in the 2nd transformation; setting can be found in each of these interfaces

The rules for naming an interface are as follows:

• Arguments: port_id(required), lane_id(optional, applies only in case of a broken out port)

Example of an interface name on Cumulus, swp49s0. First get the lane_suffix:

Example: s0

If lane_id:	Lane_suffix = "s%d" % lane_id
Else:	Lane_suffix = ""

Then build the name, using port id and lane_suffix Name = "'swp%d%s' % (port_id, lane_suffix)"

Examples: Interfaces for 4x10G transformation on port id 49: - swp49s0 - swp49s1 - swp49s2 - swp49s3 Interfaces for 40G transformation on port id 49: - swp49

Cumulus port setting	dict	Required/Optional field	The high level dictionary
interface	dict	R	The interface this setting is applicable to
command	string	R. This is the speed to command mapping as required by cumulus. For example, if interface speed is 1G, then command is ‘link-speed 1000’ command = { 1: 'link-speed 1000', 10: '', 20: '', 25: '', 40: '', 50: '', 100: '', }	The command if applicable when user needs to apply the speed on this interface
speed	string	R ()	The speed to be applied to this interface

The setting contains two important pieces of information, the command and the speed. The "command" goes underneath the interface paragraph in /etc/network/interfaces, and "speed" is the value that goes to ports.conf.

• I know my port breakout capability
• I am ready to create ports in Apstra UI
• I am in the DP->edit->ports->port
• How do I populate the Setting?

Interfaces applicable in this transformation	This interface speed	to_count	No breakout?	Speed to be populated in interface setting	command	Settingas found per interface on UI
40G	40G	1	Yes (Note the setting remains same even for a port which is capable of 40G breakout. For exampleOn the Accton 6712, we have all ports capable of 40G->4x10G. Whereas on the DellS6010, we have ports 13-16 and 29-32 which are 40G non breakout capable ports. Irrespective of whether it is breakout capable or non breakout capable, the setting for 40G interface remains same)	‘40G’	‘’	{ "interface": { "command": "", "speed": "40G" } }
1x40G->4x10G	10G	4	No	‘4x10G’	‘’	{ "interface": { "command": "", "speed": "4x10G" } }
1G	1G	1	Yes	‘1G’	link-speed 1000'	{ "interface": { "command": "link-speed 1000", "speed": "10G" } }
1G auto neg	1G autoneg	1	Yes	‘’	‘’	{ "interface": { "command": "link-speed 1000", "speed": "" } }
10G	10G	1	Yes	‘10G’	‘’	{ "interface": { "command": "", "speed": "10G" } }
1x10G->1x1G	1G	1	No	‘10G’	link-speed 1000'	{ "interface": { "command": "link-speed 1000", "speed": "10G" } }
1x10G->1x1G autoneg	1G	1	No	‘’	link-speed 1000'	"interface": { "command": "link-speed 1000", "speed": "" } }
1x10G->1x1G setting(used on Dell 4128 and 4148F) As per cumulus release notes rn778, this switch should use 1G (or 1000) in Ports.conf when 10G port is broken into 1G	1G	1	Yes	‘1G’	link-speed 1000'	{ "interface": { "command": "link-speed 1000", "speed": "1G" } }
1x10G->1x10G autoneg	10G	1	No	‘’	‘’	{ "interface": { "command": "", "speed": "" } }
100G	100G	1	Yes	‘100G’	‘’	{ "interface": { "command": "", "speed": "100G" } }
1x100G->4x25G	25G	4	No	‘4x25G’	‘’	{ "interface": { "command": "", "speed": "4x25G" } }
1x100G->4x10G	10G	4	No	‘4x10G’		{ "interface": { "command": "", "speed": "4x10G" } }
1x100G->4x1G	1G	4	No	‘10G’	link-speed 1000'	{ "interface": { "command": "link-speed 1000", "speed": "10G" } }
1x100G->12x10G	10G	12	No	‘’12x10G’	‘’	{ "interface": { "command": "", "speed": "12x10G" } }
1x100G->2x20G	20G	2	No	‘2x20G’	‘’	{ "interface": { "command": "", "speed": "2x20G" } }
1x100G->1x40G	40G	1	No	‘40G’	‘’	{ "interface": { "command": "", "speed": "40G" } }
1x100G->3x40G	40G	3	No	‘3x40G’	‘’	{ "interface": { "command": "", "speed": "3x40G" } }
1x100G->2x50G	50G	2	No	‘2x50G’	‘’	{ "interface": { "command": "", "speed": "2x50G" } }
1x100G->1x50G	50G	1	No	‘50G’	‘’	{ "interface": { "command": "", "speed": "50G" } }
25G	25G	1	Yes	‘25G’	‘’	{ "interface": { "command": "", "speed": "25G" } }
1x25G->1x10G	10G	1	No	‘10G’	‘’	{ "interface": { "command": "", "speed": "10G" } }

On the 10GBaseT, Cumulus supports auto negotiation for some devices.

To incorporate this into the DP, on that port which supports the 10G->1x1G breakout, for the 1G transformation, have the interface setting as follows:

Note the "speed" inside the "interface" setting is set to "". This allows the interface to be configured in auto-neg mode and device will auto-negotiate the interface speed.

In the IM, pick the auto-neg transformation for this port.

How to make the interface as auto neg in the DP:

1. Go to the 10GBaseT port
2. Create a 1G transformation as follows:
   • state: active
   • speed: max speed possible for interface speed
   • setting->interface->speed: empty
   • name: as per interface name rules

For example, on the Dell S4148T-ON, the ports from 1-24 and 31-54 are 10GBaseT ports. Thus, Transformation #2, configures the speed in the interface setting as "".

To capture all the essence of ports of a particular device, not only does the user need to read the device specification, but also the OS specific port rules. Fortunately, Cumulus packages these rules in the ports.conf in the dpkg bundle.

When we are writing device profiles for new Cumulus devices, the procedure ideally to be followed is:

1. To generate a list of ports(with correct transformations and interfaces) in the DP, a good way is to have access to the ports.conf and work our way backwards to then generate the ports list in the DP such that the Cumulus OS likes it. To know the detailed port constraints, read the ports.conf of that particular model in the dpkg.
2. run the following command on any Cumulus box(even VX) to get access to ports.conf:

   Pay attention to the comments sections which lists the port breakout constraints usually. It looks something like this:

   ports.conf --

   This file controls port aggregation and subdivision. For example, QSFP+ ports are typically configurable as either one 40G interface or four 10G/1000/100 interfaces. This file sets the number of interfaces per port while /etc/network/interfaces and ethtool configure the link speed for each interface.

   You must restart switchd for changes to take effect.

   The DELL S6010 has:

   32 QSFP ports numbered 1-32 These ports are configurable as 40G, split into 4x10G ports or disabled.

   The X pipeline covers QSFP ports 1 through 16 and the Y pipeline covers QSFP ports 17 through 32.

   The Trident2+ chip can only handle 52 logical ports per pipeline.

   This means 13 is the maximum number of 40G ports you can ungang per pipeline, with the remaining three 40G ports set to "disabled". The 13 40G ports become 52 unganged 10G ports, which totals 52 logical ports for that pipeline.

   QSFP+ ports <port label 1-32> = [4x10Gdisabled]

3. Use the comments when writing a new Cumulus DP.

Port Constraint:

The Dell Z9100 has:

32 QSFP28 ports numbered 1-32 These ports are configurable as 100G, 50G, 40G, 2x50G, 4x25G, 4x10G or disabled. Two SFP+ ports. These ports are configurable as 10G or disabled. The system can only handle 128 logical ports. This means that if all 32 QSFP28 ports are broken out into 4x25G or 4x10G mode, the two 10G ports (33 and 34) must be set to "disabled".

To honor this, in the DP, the ports 33-34 should provide a transformation with the interface with disabled setting.

IM constraint:

If all the 32 QSFP28 ports are broken out into 4x25G or 4x10G, then the two 33-34 need to be disabled. So explicitly pick the disabled transformation for 33-34 in this case.

Port Constraint:

The Dell S4128 has:

28 SFP+ ports numbered 1-24 and 27-30 These ports are configurable as 10G, or groups of four adjacent ports can be configured as 40G. 2 QSFP28 ports numbered 25-26 These ports are configurable as 100G, 50G, 40G, or split into 2x50G, 4x25G, or 4x10G ports.

Note:

SFP+ ports 13, 14, 23, and 24 are not in a group of four adjacent ports and cannot be configured as part of a ganged 40G.

Ganged ports configuration is not supported.

For the 1G broken out interface, the speed inside the interface setting should be "1G" and not "10G" (which usually is for other cumulus devices)

To honor this, in the DP, the ports 33-34 should provide a transformation with the interface with disabled setting.

IM constraint:

If all the 32 QSFP28 ports are broken out into 4x25G or 4x10G, then the two 33-34 need to be disabled. So explicitly pick the disabled transformation for 33-34 in this case.

Port Constraint:

The Dell S4148T has:

48 10GT ports numbered 1-24 and 31-54 These ports are not configurable. 2 QSFP+ ports numbered 27-28 These ports are configurable as 40G or split into 4x10G ports. 4 QSFP28 ports numbered 25-26 and 29-30 These ports are configurable as 100G, 50G, 40G, or split into 2x50G, 4x25G, or 4x10G ports.

Note:

The two QSFP+ ports are DISABLED by default, and the four QSFP28 ports are configured for 100G by default. In order to enable the two QSFP+ ports for 40G or 4x10G, all four QSFP28 ports must also be configured for either 40G or 4x10G.

In the DP, to honor this constraint we need a transformation with "disabled" setting as follows for the ports 27-28

IM constraint:

In order to enable the two QSFP+ ports(27-28) for 40G or 4x10G, all four QSFP28 ports must also be configured for either 40G or 4x10G.

Port Constraint:

The Dell S4148 has:

48 SFP+ ports numbered 1-24 and 31-54 These ports are configurable as 10G, or groups of four adjacent ports can be configured as 40G. 2 QSFP+ ports numbered 27-28 These ports are configurable as 40G or split into 4x10G ports. 4 QSFP28 ports numbered 25-26 and 29-30 These ports are configurable as 100G, 50G, 40G, or split into 2x50G, 4x25G, or 4x10G ports.

Note:

The two QSFP+ ports are DISABLED by default, and the four QSFP28 ports are configured for 100G by default. In order to enable the two QSFP+ ports for 40G or 4x10G, all four QSFP28 ports must also be configured for either 40G or 4x10G.

The 2 QSFP+ and 4 QSFP28 have same rules as Dell 4148T. The 48 SFP+ ports have same 1G setting constraints as Dell 4128F, i.e.

Port Constraint:

This file controls port aggregation and subdivision. For example, QSFP+ ports are typically configurable as either one 40G interface or four 10G/1000/100 interfaces. This file sets the number of interfaces per port while /etc/network/interfaces and ethtool configure the link speed for each interface.

You must restart switchd for changes to take effect.

Accton AS6812_32X has:

32 QSFP+ ports numbered 1-32 These ports are configurable as 40G, split into 4x10G ports or disabled. The X pipeline covers QSFP ports 1-16 and the Y pipeline covers QSFP ports 17-32. The Trident2+ chip can only handle 52 logical ports per pipeline. This means 13 is the maximum number of 40G ports you can ungang per pipeline, with the remaining three 40G ports set to "disabled". The 13 40G ports become 52 unganged 10G ports, which totals 52 logical ports for that pipeline.

To honor this constraint, in the DP, all the 40g->4x10G ports need to have a transformation with an interface with diaabled setting as follows:

IM Constraint:

When picking 10G interfaces, make sure there are only a maximum of 52 10G interfaces (coming from the 13 ports) for this IM. Also for the rest of the 3 leftover 40G ports, explicitly select the "disabled" transformation.

This way, the port config will be generated correctly as per port constraints.

Port Constraint:

Odd numbered ports can do full breakout up to 4x10G and 4x25G.

Even numbered ports can only have upto 2x50G interfaces and should be disabled if immediately preceding odd-numbered port is broken out into 4 interfaces. (Source: https://docs.mellanox.com/display/sn2000pub/Cable+Installation)

How does this translate in the DP?

The odd numbered ports, like port 1, have following transformations:

#1 (100 Gbps, default)	swp1
#2 (50 Gbps)	swp1s0 swp1s1
#3 (50 Gbps)	swp1
#4 (40 Gbps)	swp1
#5 (25 Gbps)	swp1s0 swp1s1 swp1s2 swp1s3
#6 (10 Gbps)	swp1s0 swp1s1 swp1s2 swp1s3
#7 (1 Gbps)	swp1s0 swp1s1 swp1s2 swp1s3

Whereas the even numbered ports, like port 2, have following transformations.

#1 (100 Gbps, default)	swp2
#2 (50 Gbps)	swp2s0 swp2s1
#3 (50 Gbps)	swp2
#4 (40 Gbps)	swp2
#5 (100 Gbps)	swp2

Note that even ports do not have the 10G and 25G transformations. Additionally, they have a "disabled" interface in transformation 5 with the following setting:

IM constraints:

If you want to include an odd numbered port which is broken out into 4 interfaces, then make sure you also pick the disabled transformation of the following even numbered port.

For example in the Interface Map Mellanox_MSN2700_Cumulus__AOS-48x10_8x100-1

Because we are using the ports: [1,3,5,7,9,11,13,15,17,19,21,23] to generate the 4x10G interfaces, we also pick the 5th transformation(disabled) for ports [2,4,6,8,10,12,14,16,18,20,22,24]. Thus on the UI, for the Interface Map, you see 12 unused interfaces corresponding to these disabled interfaces.

Only if these are included in the Interface Map, will Apstra generate the right ports.conf honoring the above Cumulus Mellanox 2700 constraint. Refer to the use case for Inter Port Constraints on the Interface Maps page for more details on Interface Map creation.

Device mismatch usually occurs at the beginning of a device’s lifecycle. If a device profile is not being selected by the device, check the four selector fields in the device profile.

Deploy errors could arise because of incorrect port configurations. This could be either the ports were configured with incorrect speeds, or the OS specific port constraints were not handled in the device profile or in the interface map.

A possible flow for root cause would be:

1. Check the DP for obvious port capabilities errors. Is the port really capable of the speeds the DP has configured. The /var/log/switchd logs on the device are a good resource to parse for ERROR messages.
2. Check if the DP has configured autoneg or disabled interfaces correctly. Autoneg and disabled can both be expressed in the interface setting field.
3. The port constraints can be read from the following files:

Mapping the DP to LD in the IM

The mapping specifies how exactly the user wants to map the physical ports to the logical interfaces.

The 5 fields on the mapping are: [DP portID, DP transformationID, DP InterfaceID, LD panelID, LD portID].

These five fields allow the user to map the DP exactly to the LD. The first three fields specify which port, transformation and interface in the DP is the interface in the IM referencing:

1. (port id, transformation id) - all active interfaces in the given transformation are used; active interfaces are mapped in the order they appear in the transformation.
2. (port id, transformation id, interface id) - If the user specifies the third field in the mapping, the particular interface in the transformation is used in mapping.

[Reading syseeprom on Cumulus device] https://docs.cumulusnetworks.com/cumulus-linux/Monitoring-and-Troubleshooting/Monitoring-System-Hardware/

[Edgecore AS5712-54X-0] https://www.edge-core.com/productsInfo.php?cls=1&cls2=8&cls3=44&id=15