How to deal with device types with same model and manufacturer

[tschmidtb51]

According to the documentation (and the error message), the model must be unique for a manufacturer. Unfortunately, I come across many instance where this is not the case. See some examples below:

• a manufacturer uses the same model name for different hardware revisions (e.g. Nintendo Switch - see https://switchbrew.org/wiki/Switch_System_Flaws for examples)
• a manufacturer uses the same model name for different type/part numbers (e.g. Lenovo T440p: 20AACTO1WW, 20AA000955, 20AA0009UK)
• a manufacturer uses the same model name for different hardware options / part numbers (e.g. AVM Fritz!Box 7590: 20002998 doesn't have ISDN, 20002929 does have ISDN)

So the question is: How should we deal with this?
If we append some explaining string to the model it can't be used to programmatically (reliably) match against security advisories. Should we then introduce custom fields to separate the data, e.g., hardware version and model name?

Any thoughts?

[candlerb]

I see a few possible approaches:

1. Create distinct models (e.g. "Lenovo", "T440p-20AACTO1WW"; "Lenovo", "T440p-20AA000955"). This means that when a user selects from the dropdown, they are visually distinct and they are forced to select the correct one if they know it. It may be a good idea to add another option "Lenovo", "T440p (unknown variant)" so that users who are unsure don't pick a random one.
2. Use a single model number (e.g. "Lenovo", "T440p"). Use a custom field on the device to record the part number, if it's known. This way is arguably simpler for users and allows multiple variants without having to create new device types, but you get no validation of the part numbers entered.
3. Like 2, but add an "Inventory Item" to record the chassis part number. If it's not added, then the variant is unknown. Again, the part number is just a free-text field and is not validated.

In the case of the Fritz!Box 7590 variants, because they are physically different I'd suggest distinct named models (option 1) so that you can put different interfaces in the device type template, e.g. "AVM", "Fritz!Box 7590 20002929 (ISDN)" has the ISDN interface.

[zmaster7]

I think option 1 is probably the best bet, as there are quite a few cases where the hardware layout can be quite different even though the model is the same. For example, I have 3 different variants of a Dell PowerEdge R7515 (e.g. "PowerEdge R7515 (24SFF)," "PowerEdge R7515 (12LFF+2LFF)," etc.), because the front and the rear of the chassis changes based on selected options, especially when it comes to the number of PCIe slots on the back. If you are using visio stencils for the front/rear images, this is the better approach, as there can only be one set per device type.

[Crubumble]

I agree with zmaster7. Option 2 and 3 are workarounds that oppose the idea where the information should be. Option 1 could result in high human efforts.

caption: Mockup that illustrates relevant fields for a unique device model name based on Model, hardware version, model number and partnumber.

To avoid this, one approach would be to automatically generate the current model field, which is displayed in the Netbox GUI as “Model Name”, by the following fields:

• DeviceType: model_name (new core field – mandatory)
• DeviceType: hardware_version (new core field – default “”)
• DeviceType: model_number (new core field – default “”, highly recommended)
• DeviceType: part_number (existing core field – default “”)

The new field “model_name” would be the current Model Name (DeviceType: model) field. The Model Name (DeviceType: model) illustrated in the picture cannot be manually entered in this approach. Instead, it is a combination of the above-mentioned fields. This guaranties a unique name. In addition, changes to those fields should automatically adjust the device type Model Name.

Description of the fields:

• Hardware version can be “N/A” if just one version was build. Multiple products exist in multiple hardware versions (due to PCB layout changes or chip shortages or hardware improvements), which can have impact on the software that can be used with the device.
• Model_number: A model number can be used as an article number. However, an article number is not always/necessarily a model number. Usually, all products have model numbers, often they are listed on the sticker on the device besides the serial number.
• Part_number: It can be the same as model_number, especially when seller is the vendor itself. This can be used as an alternative presentation of the model number e.g. SKU as in devicetype-library
  

These changes would make it possible to match machine-readable security advisories in CSAF against the Netbox asset database.

[Crubumble]

Background

To understand the underlying problem, I add some information about vulnerability management by using the Common Security Advisory Framework (CSAF). CSAF 2.0 makes it possible to have a machine readable format for sharing information about vulnerabilities, the affected products and remediation. But how a product is described? Let look at an excerpt of the security advisory ssa-723487.

There, you have 424 affected products. In the current state of netbox data model that would mean 424 device type. Since the device type is identified only by manufacturer + model number in netbox we would see this:

manufacturer	model-number
Siemens	SCALANCE SC622-2C (6GK5622-2GS00-2AC2)
Siemens	SCALANCE SC626-2C (6GK5626-2GS00-2AC2)
Siemens	SCALANCE SC632-2C (6GK5632-2GS00-2AC2)
Siemens	SCALANCE SC636-2C (6GK5636-2GS00-2AC2)
Siemens	SCALANCE SC642-2C (6GK5642-2GS00-2AC2)
Siemens	SCALANCE SC646-2C (6GK5646-2GS00-2AC2)

the manufacturer is always the same. Well then, add product family as an additional category to get it more readable:

manufacturer	product family	model-number	part number
Siemens	SCALANCE	SC622-2C	(6GK5622-2GS00-2AC2)
Siemens	SCALANCE	SC626-2C	(6GK5626-2GS00-2AC2)
Siemens	SCALANCE	SC632-2C	(6GK5632-2GS00-2AC2)
Siemens	SCALANCE	SC636-2C	(6GK5636-2GS00-2AC2)
Siemens	SCALANCE	SC642-2C	(6GK5642-2GS00-2AC2)
Siemens	SCALANCE	SC646-2C	(6GK5646-2GS00-2AC2)

Now we have a distinguished presentation of product families of the manufacturer Siemens, right? However, SC-600 is also a device family which let's to:

manufacturer	product family (parent)	product family (child)	model-number	part number
Siemens	SCALANCE	SC-600	SC622-2C	(6GK5622-2GS00-2AC2)
Siemens	SCALANCE	SC-600	SC626-2C	(6GK5626-2GS00-2AC2)
Siemens	SCALANCE	SC-600	SC632-2C	(6GK5632-2GS00-2AC2)
Siemens	SCALANCE	SC-600	SC636-2C	(6GK5636-2GS00-2AC2)
Siemens	SCALANCE	SC-600	SC642-2C	(6GK5642-2GS00-2AC2)
Siemens	SCALANCE	SC-600	SC646-2C	(6GK5646-2GS00-2AC2)

Lets do this further...

manufacturer	product family (parent)	product family (child)	product family (grandchild)	model-number	part number
Siemens	SCALANCE	SC-600	SC622-2C	specification A	(6GK5622-2GS00-2AC2)
Siemens	SCALANCE	SC-600	SC622-2C	specification B	(6GK5622-2GS00-2AC2)
Siemens	SCALANCE	SC-600	SC622-2C	specification C	(6GK5622-2GS00-2AC2)
Siemens	SCALANCE	SC-600	SC622-2C	specification D	(6GK5622-2GS00-2AC2)
Siemens	SCALANCE	SC-600	SC622-2C	specification E	(6GK5622-2GS00-2AC2)

Note: the part number might be changed also. This however might also not be true always and even further not true for a different vendor which does not need device families at all.

In that way, you can add specifications that would be otherwise fix and not variable. Like hardware version.

Solution

As a conclusion, a dynamic model is needed to handle the different levels of hierarchy of manufacturer product description. There might be an easier solution to this problem as previously suggested. The solution is derived in more detail here

Manufacturer
├── product family A
│   └── product of family A
│       ├── further specification
│       │   └── final specification (part number)
│       └── further specification
│           └── ...
├── product family B
    └── product family BA of family B
        ├── further specification
        │   └── ...
        └── further specification
            └── final specification (part number) 

In netbox, the concept of parent and child are already implemented. An additional field product parent/child should do it? Since it is a tree structure the values should be:

Value	meaning
-	its the leaf already
parent	root of device type
parent and child	it is a branch
child	it is the finally device type description having unique information

Open issues with this solution

• Can/Should a parent (and child) have further information at all or which one?
• what is if a child becomes also a parent with the information in this leaf?

Benefits

• use the existing framework
• adjust netbox for vulnerability management with CSAF
• on average faster mapping (not comparing every device type with a csaf product.)
• better usability?

[Crubumble]

Discussion of two Plausible Solutions

Two suitable solutions were mentioned above. With this post, possible implementations are compared.
In summary, "Option 1" from @candlerb seems to be the reasonable solution. However, the dynamic model suggested by @Crubumble seems to be a long-term solution.

Solution Child/Parent (dynamic model)

Necessary changes:

• view of device type has to be adjusted in order to display the relationship parent-child
• additional mechanism for parent child checks have to be implemented (e.g. a parent can not be child of itself)

Solution Create Individual Names (Option 1) as Plugin

Necessary changes:

• a plugin is needed
• add hardware version as custom field
• add device family as custom field
• add model as custom field (see model vs model name)
• change order of part number
• change the create button so that the model name is generated once by concatinating device family, model, part number and hardware version during creation.

Solution Create Individual Names (Option 1) as core update

Necessary changes:

• add device family and hardware version as a core field (default: empty; optional)
• change order of part number
• make the model name (see model vs model name) read-only, gets created as concatenation (on the fly via JavaScript in the Create dialogue) of device family, model, part number and hardware version
• values for matching with CSAF are stored in the individual database fields (device family, model, part number and hardware version)
• implement a getter for model name (that does the concat on the fly) ensure backwards compatibility
• migration puts existing strings from model name into model, removes part number if duplicate

Comparison

The recursive structure comes with a steeper learning curve but more flexibility for power users. It is the most suitable solution for CSAF matching. On the contrary, "Option 1" is easier to implement and only small user behavior changes.

Criteria	child/parent	Option 1 as plugin	Option 1 in core
Usability (entry)	++	+	++
Downstream Dependencies	o	-	o
Sustainability	++	-	++
Implementation Effort	o	+	+
Usability (CSAF)	++	+	+

Usability for Creating a new Device Type

child/parent: The user has to choose the parent from a list.
comments for script population: If you do not need the recursive approach, you simply leave the default "parent" (parent acts as a root).
plugin: The user can fill out some additional fields. Plugin is needed. The user has to choose the specific tab "create model name".
core: There are just some additional optional core fields.

Implications for Downstream Dependencies

Existing databases such as device type library have to be checked for data quality and be reprocessed as no guidance was given in previous NetBox versions. For implementing "Option 1" as plugin, existing databases can not assumed that the plugin exists. Therefore, the maintainer of the databases either have to create two versions or still use the old format which hinders matching CSAF security advisories.

Sustainability

child/parent: The fields become part of the core model.
plugin: A plugin has to be maintained and kept up-to-date and compatible with new versions of NetBox.
core: The fields become part of the core model.

Implementation

child/parent: The overview of device types would need a proper modification.
plugin One migration (transition + new fields), changed view (View Device Type), new view (Create model name)
core: One migration (transition + new fields), two changed views (Create Device Type and View Device Type)

Usability for CSAF

child/parent: This solution reflects the CSAF structure.
plugin: The model name is generated by the mentioned field. However, it can be edited afterwards. If the user does that instead of adjusting the corresponding field, the data gets inconsistent.
core: Single data fields exist for the matching. The data fields might be inconsistent as no guidance was given previously in older versions of NetBox. As the model name is build on the fly and read-only, the inconsistencies like in the plugin can not exists.

Illustration of Option 1

To illustration the Option 1 solution both, creating a device type and showing the device types list, are presented below:

Creating a Device Type

Option 1 as Plugin

The tab "create model name" would only be necessary within the plugin solution.

Option 1 in Core

Rules

The rules for generating the model name.

• all field are processed. However, not all fields are mandatory
• if empty (e.g. "-") it is not considered for the model name
• the model name still has to be unique

Results are shown in the device types overview

Model and Model Name

NetBox is using model (creating and editing) and model name (view) both for naming the device type as illustrated in the view of device types and editing one. Above, the names have different meaning.