starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Introduce a model for device modules/line cards #5667

New Issue
Closed
opened 2025-12-29 19:30:53 +01:00 by adam · 10 comments
adam commented 2025-12-29 19:30:53 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Nov 16, 2021).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v3.0.10

Feature type

New functionality

Proposed functionality

Add two new models for tracking the installation of field-swappable hardware modules/line cards/etc. within devices: Module and ModuleType. These will roughly parallel Device and DeviceType, where the later serves as a "template" for instances of the former. A ModuleType can have device component templates assigned to it. Upon the "installation" of a Module within a Device, these components will be instantiated and assigned to the new Module, just as with DeviceTypes.

It likely also makes sense to introduce ModuleBays, to which (similar to DeviceBays) Modules can be installed. A ModuleBay can be assigned a position identifier, which can be leveraged to automatically rename component templates assigned to a ModuleType.

For example, suppose we have a DeviceType with six ModuleBayTemplates. When creating a new Device from this DeviceType, it would receive six ModuleBays assigned to it. Next we might device a ModuleType with 24 InterfaceTemplates assigned to it. When "installing" a Module into the Device, 24 new Interfaces would be created and assigned to the Module. Ideally, these would be automatically named to correspond to the Module's position. (The exact logic supporting this is TBD but there are a few options.)

When a Module is removed, it and any associated device components would be deleted.

(This concept was originally introduced in #824, but has been updated and fleshed out a bit.)

Use case

This proposal would address the use case of modeling chassis-based devices with removable line cards or similar components. Some examples include the Cisco Nexus 7000 series switch and Juniper MX480 router. Associating individual components with a module provides a layer of relationship that better facilitates the addition and removal of these components as they relate to the parent module.

Database changes

The proposal above requires the addition of four new models:

  • ModuleBayTemplate
  • ModuleBay
  • ModuleType
  • Module

It will also require changing the device_type ForeignKey relationship on the device component template models to a GenericForeignKey, so that they can be associated with ModuleTypes as well.

External dependencies

No response

Originally created by @jeremystretch on GitHub (Nov 16, 2021). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v3.0.10 ### Feature type New functionality ### Proposed functionality Add two new models for tracking the installation of field-swappable hardware modules/line cards/etc. within devices: Module and ModuleType. These will roughly parallel Device and DeviceType, where the later serves as a "template" for instances of the former. A ModuleType can have device component templates assigned to it. Upon the "installation" of a Module within a Device, these components will be instantiated and assigned to the new Module, just as with DeviceTypes. It likely also makes sense to introduce ModuleBays, to which (similar to DeviceBays) Modules can be installed. A ModuleBay can be assigned a position identifier, which can be leveraged to automatically rename component templates assigned to a ModuleType. For example, suppose we have a DeviceType with six ModuleBayTemplates. When creating a new Device from this DeviceType, it would receive six ModuleBays assigned to it. Next we might device a ModuleType with 24 InterfaceTemplates assigned to it. When "installing" a Module into the Device, 24 new Interfaces would be created and assigned to the Module. Ideally, these would be automatically named to correspond to the Module's position. (The exact logic supporting this is TBD but there are a few options.) When a Module is removed, it and any associated device components would be deleted. (This concept was originally introduced in #824, but has been updated and fleshed out a bit.) ### Use case This proposal would address the use case of modeling chassis-based devices with removable line cards or similar components. Some examples include the Cisco Nexus 7000 series switch and Juniper MX480 router. Associating individual components with a module provides a layer of relationship that better facilitates the addition and removal of these components as they relate to the parent module. ### Database changes The proposal above requires the addition of four new models: - ModuleBayTemplate - ModuleBay - ModuleType - Module It will also require changing the `device_type` ForeignKey relationship on the device component template models to a GenericForeignKey, so that they can be associated with ModuleTypes as well. ### External dependencies _No response_
adam added the status: acceptedtype: feature labels 2025-12-29 19:30:53 +01:00
adam closed this issue 2025-12-29 19:30:53 +01:00
adam commented 2025-12-29 19:30:53 +01:00
Author
Owner
Copy Link

@mmfreitas commented on GitHub (Nov 16, 2021):

Hello, would this approach cover multiple levels of line cards?

An example with some Cisco Models:

  1. We have a router that has 10 slots (Cisco ASR 9010) [Parent Device]
  2. We have a Modular Line Card installed in slot 7 (Cisco A9K-MOD200-TR) [Child device of 1 and Parent device of 3 and 4]
  3. We have a Modular Port Adapter installed in the slot 0 of the A9K-MOD200-TR (Cisco A9K-MPA-20X1GE) [Child device of 2]
  4. We have another Modular Port Adapter in the slot 1 of the A9K-MOD200-TR (Cisco A9K-MPA-4X10GE) [Child device of 2]

In the command line when connecting to the router the interfaces of the cards have the following name:

  1. Cisco A9K-MPA-20X1GE (has 20 interfaces):

    • Gi0/7/0/0,
    • Gi0/7/0/1,
    • Gi0/7/0/2, [...]
    • Gi0/7/0/19;

  2. Cisco A9K-MPA-4X10GE (has 4 interfaces):

    • Te0/7/1/0,
    • Te0/7/1/1,
    • Te0/7/1/2,
    • Te0/7/1/3;

Would this level of nesting work as expected?

@mmfreitas commented on GitHub (Nov 16, 2021): Hello, would this approach cover multiple levels of line cards? An example with some Cisco Models: 1. We have a router that has 10 slots (Cisco ASR 9010) [Parent Device] 2. We have a Modular Line Card installed in slot 7 (Cisco A9K-MOD200-TR) [Child device of 1 and Parent device of 3 and 4] 3. We have a Modular Port Adapter installed in the slot 0 of the A9K-MOD200-TR (Cisco A9K-MPA-20X1GE) [Child device of 2] 4. We have another Modular Port Adapter in the slot 1 of the A9K-MOD200-TR (Cisco A9K-MPA-4X10GE) [Child device of 2] In the command line when connecting to the router the interfaces of the cards have the following name: 3. Cisco A9K-MPA-20X1GE (has 20 interfaces): - Gi0/7/0/0, - Gi0/7/0/1, - Gi0/7/0/2, [...] - Gi0/7/0/19; 4. Cisco A9K-MPA-4X10GE (has 4 interfaces): - Te0/7/1/0, - Te0/7/1/1, - Te0/7/1/2, - Te0/7/1/3; Would this level of nesting work as expected?
adam commented 2025-12-29 19:30:54 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 16, 2021):

No; this would only model a single level of module, which I'd expect to be sufficient for the vast majority of use cases.

@jeremystretch commented on GitHub (Nov 16, 2021): No; this would only model a single level of module, which I'd expect to be sufficient for the vast majority of use cases.
adam commented 2025-12-29 19:30:54 +01:00
Author
Owner
Copy Link

@hiddenman commented on GitHub (Nov 17, 2021):

@jeremystretch Great news! However, i can't figure out from the description whether this will close the SFP modules question?
Will it be possible to add a simple SFP module to the interface somehow? Or it's completely different option?

@hiddenman commented on GitHub (Nov 17, 2021): @jeremystretch Great news! However, i can't figure out from the description whether this will close the SFP modules question? Will it be possible to add a simple SFP module to the interface somehow? Or it's completely different option?
adam commented 2025-12-29 19:30:54 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 17, 2021):

@hiddenman SFPs would be addressed by the solution proposed in #7846.

@jeremystretch commented on GitHub (Nov 17, 2021): @hiddenman SFPs would be addressed by the solution proposed in #7846.
adam commented 2025-12-29 19:30:55 +01:00
Author
Owner
Copy Link

@martink2 commented on GitHub (Dec 18, 2021):

I just played a bit around with the feature and have a question regarding naming of interfaces in modules.

We have a modular switch having 4 slots: slot1,slot2,slot3,slot4

We have two Linecards:

  • Type A, Interfaces: TenGigabitEthernet1, TenGigabitEthernet2 etc.
  • Type B, interfaces: GigabitEthernet1, GigabitEthernet2, etc.

When I insert Type A into Slot 1 i get the interfaces named as in the module template
When I insert Type A into Slot 2 i get a "duplicate key value violates unique constraint "dcim_interface_device_id_bffc4ec4_uniq"
When i insert Type B into slot 3 i get i also get the interfaces as in the template

In the real world the following happens:

Type A-Slot1: TenGigabitEthernet1 -> TenGigabitEthernet1/1
Type A-Slot2: TenGigabitEthernet1 -> TenGigabitEthernet2/1
Type B-Slot3: GigabitEthernet1 -> GigabitEthernet3/1

I took a quick survey through our inventory and the pattern seems to
pretty much boil down to:

(interface-type-name)(slot-prefix)(relative-id)
for my example:
(TenGigabitEthernet|GigabitEthernet)([1|2|3/])([1-n])

Where interface-type-name, seems to pretty uniformly come from the module/linecard
slot-prefix is always coming from the parent device and the relative-id again geeing
defined by the linecard.

Is there already any idea how this will be done?

Regex in the module-bay definition which will be applied to all module interfaces?
Regex in the module-type expecting a parameter coming from the module-bay on insertion ?

@martink2 commented on GitHub (Dec 18, 2021): I just played a bit around with the feature and have a question regarding naming of interfaces in modules. We have a modular switch having 4 slots: slot1,slot2,slot3,slot4 We have two Linecards: - Type A, Interfaces: TenGigabitEthernet1, TenGigabitEthernet2 etc. - Type B, interfaces: GigabitEthernet1, GigabitEthernet2, etc. When I insert Type A into Slot 1 i get the interfaces named as in the module template When I insert Type A into Slot 2 i get a "duplicate key value violates unique constraint "dcim_interface_device_id_bffc4ec4_uniq" When i insert Type B into slot 3 i get i also get the interfaces as in the template In the real world the following happens: Type A-Slot1: TenGigabitEthernet1 -> TenGigabitEthernet1/1 Type A-Slot2: TenGigabitEthernet1 -> TenGigabitEthernet2/1 Type B-Slot3: GigabitEthernet1 -> GigabitEthernet3/1 I took a quick survey through our inventory and the pattern seems to pretty much boil down to: (interface-type-name)(slot-prefix)(relative-id) for my example: (TenGigabitEthernet|GigabitEthernet)([1|2|3/])([1-n]) Where interface-type-name, seems to pretty uniformly come from the module/linecard slot-prefix is always coming from the parent device and the relative-id again geeing defined by the linecard. Is there already any idea how this will be done? Regex in the module-bay definition which will be applied to all module interfaces? Regex in the module-type expecting a parameter coming from the module-bay on insertion ?
adam commented 2025-12-29 19:30:55 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 18, 2021):

Just to ensure expectations are clear, this is still very much a work in progress and not yet ready for evaluation.

I'm still weighing options for the component renaming. My plan right now is to add an integer position field to the ModuleBay model, and extend the component instantiation logic to support string replacement referencing it. So for example, you might define interface templates on a ModuleType named Gi{module}/0/[1-24]. When a new Module is "installed", its interfaces are named according to the position of its module bay. I still need to test this though.

If it works out, we might be able to implement something similar for virtual chassis, although that's a but more complicated because devices (and their components) can exist prior to VC assignment.

@jeremystretch commented on GitHub (Dec 18, 2021): Just to ensure expectations are clear, this is still very much a work in progress and not yet ready for evaluation. I'm still weighing options for the component renaming. My plan right now is to add an integer `position` field to the ModuleBay model, and extend the component instantiation logic to support string replacement referencing it. So for example, you might define interface templates on a ModuleType named `Gi{module}/0/[1-24]`. When a new Module is "installed", its interfaces are named according to the position of its module bay. I still need to test this though. If it works out, we might be able to implement something similar for virtual chassis, although that's a but more complicated because devices (and their components) can exist prior to VC assignment.
adam commented 2025-12-29 19:30:55 +01:00
Author
Owner
Copy Link

@martink2 commented on GitHub (Dec 20, 2021):

Totally understood and thanks for quick response, we are currently planning to have
a large number of modular patch pannels moved into netbox and this feature would be
a really big benefit for that effort.

As to the integer "position" field or generally the idea to transport information from
the module bay towards the module, that would be very nice. looking at our devices
we found a few scenarios where pure integer would present a challenge thought.

Devices with where Module bays use alpha-numerical identifiers within the same device:

Device A
ModuleBay a-0
ModuleBay a-1
ModuleBay b-0
ModuleBay b-1

On device name of interface: lc-a-0-0, lc-a-0-1 etc

Devices with internal "paths" to modules, this seems to be common in large modular
devices we have:

Device B
ModuleBay 0/0
ModuleBay 0/1
ModuleBay 0/2
ModuleBay 1/0
ModuleBay 1/1
ModuleBay 1/2

On device name of interface: GigabitEthernet0/1/0, GigabitEthernet1/1/2 etc.

I cross checked and in this case it is not about nested modules, like the comment above,
although most likely technically similar. The example is for a fixed configuration 6 Module
device, where the modules seem to be internally split into two groups by the vendor.
(found this in more then one vendor others use 0-1,0-2 etc notation).

Thanks again for spending time with this feature, we are really looking forward to it
landing in Netbox.

@martink2 commented on GitHub (Dec 20, 2021): Totally understood and thanks for quick response, we are currently planning to have a large number of modular patch pannels moved into netbox and this feature would be a really big benefit for that effort. As to the integer "position" field or generally the idea to transport information from the module bay towards the module, that would be very nice. looking at our devices we found a few scenarios where pure integer would present a challenge thought. Devices with where Module bays use alpha-numerical identifiers within the same device: Device A ModuleBay a-0 ModuleBay a-1 ModuleBay b-0 ModuleBay b-1 On device name of interface: lc-a-0-0, lc-a-0-1 etc Devices with internal "paths" to modules, this seems to be common in large modular devices we have: Device B ModuleBay 0/0 ModuleBay 0/1 ModuleBay 0/2 ModuleBay 1/0 ModuleBay 1/1 ModuleBay 1/2 On device name of interface: GigabitEthernet0/1/0, GigabitEthernet1/1/2 etc. I cross checked and in this case it is not about nested modules, like the comment above, although most likely technically similar. The example is for a fixed configuration 6 Module device, where the modules seem to be internally split into two groups by the vendor. (found this in more then one vendor others use 0-1,0-2 etc notation). Thanks again for spending time with this feature, we are really looking forward to it landing in Netbox.
adam commented 2025-12-29 19:30:55 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 20, 2021):

looking at our devices we found a few scenarios where pure integer would present a challenge thought.

That's a fair point; I can just make it a character field to allow for maximum flexibility. My initial thought was to allow modification to it in format strings (e.g. {module+1}) but that should be unnecessary and may actually be dangerous anyway.

@jeremystretch commented on GitHub (Dec 20, 2021): > looking at our devices we found a few scenarios where pure integer would present a challenge thought. That's a fair point; I can just make it a character field to allow for maximum flexibility. My initial thought was to allow modification to it in format strings (e.g. `{module+1}`) but that should be unnecessary and may actually be dangerous anyway.
adam commented 2025-12-29 19:30:56 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 20, 2021):

Here's what I came up with.

Peek 2021-12-20 09-40

@jeremystretch commented on GitHub (Dec 20, 2021): Here's what I came up with. ![Peek 2021-12-20 09-40](https://user-images.githubusercontent.com/13487278/146785196-e65daa29-582c-47f8-b0d9-df10d29b5786.gif)
adam commented 2025-12-29 19:30:58 +01:00
Author
Owner
Copy Link

@martink2 commented on GitHub (Dec 20, 2021):

Played around with the latest feature branch, it works quite nicely. Thanks a lot for that functionality.

@martink2 commented on GitHub (Dec 20, 2021): Played around with the latest feature branch, it works quite nicely. Thanks a lot for that functionality.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: accepted type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#5667
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?