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

Multi-Level / Nested Modules #6340

New Issue
Closed
opened 2025-12-29 19:39:36 +01:00 by adam · 7 comments
adam commented 2025-12-29 19:39:36 +01:00
Owner
Copy Link

Originally created by @shatt79 on GitHub (Apr 10, 2022).

NetBox version

3.2.0

Feature type

Change to existing functionality

Proposed functionality

Create functionality for modules within modules, aka nested modules. A device-type can be a parent or child. In the real world, a module/line card can also be a parent or child.

Use case

Cisco, Adtran, Juniper and others have product lines that employ line cards that may contain multiple child slots. One example that another user brought up is the Cisco ASR9K. One such line card associated with that platform is the A9K-MOD-160. The MOD80 and MOD160 each have two child slots. Those child slots hold MPAs (modular port adapters). MPAs come in many flavors. 8x10GE, 4x10G, 20x1G, 2x100G, etc. You can mix and match MPAs in a MOD80/160.

The ASR9K interface naming is always "Type chassis/slot/subslot/number". Eg, TenGig 0/1/1/2. This would indicate a TenGig interface in chassis 0, parent slot 1, subslot 1, port 2. Because of this, I don't think that simply allowing a module-type to be a parent or child will work. I think a new table for "sub-module-types" would be required. And for that to work, we'd need to be able to create module-bays within a module.

That way, when one is creating an automated interface naming convention during the creation of the sub-module, it can be done with something like:
TenGigabitEthernet0/{module}/{submodule}/[1-8]

This type of setup is extremely common with ISP/Carrier-grade equipment.

Database changes

No response

External dependencies

No response

Originally created by @shatt79 on GitHub (Apr 10, 2022). ### NetBox version 3.2.0 ### Feature type Change to existing functionality ### Proposed functionality Create functionality for modules within modules, aka nested modules. A device-type can be a parent or child. In the real world, a module/line card can also be a parent or child. ### Use case Cisco, Adtran, Juniper and others have product lines that employ line cards that may contain multiple child slots. One example that another user brought up is the Cisco ASR9K. One such line card associated with that platform is the A9K-MOD-160. The MOD80 and MOD160 each have two child slots. Those child slots hold MPAs (modular port adapters). MPAs come in many flavors. 8x10GE, 4x10G, 20x1G, 2x100G, etc. You can mix and match MPAs in a MOD80/160. The ASR9K interface naming is always "Type chassis/slot/subslot/number". Eg, TenGig 0/1/1/2. This would indicate a TenGig interface in chassis 0, parent slot 1, subslot 1, port 2. Because of this, I don't think that simply allowing a module-type to be a parent or child will work. I think a new table for "sub-module-types" would be required. And for that to work, we'd need to be able to create module-bays within a module. That way, when one is creating an automated interface naming convention during the creation of the sub-module, it can be done with something like: TenGigabitEthernet0/{module}/{submodule}/[1-8] This type of setup is extremely common with ISP/Carrier-grade equipment. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: featurestatus: revisions needed labels 2025-12-29 19:39:36 +01:00
adam closed this issue 2025-12-29 19:39:37 +01:00
adam commented 2025-12-29 19:39:37 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Apr 11, 2022):

Adding that this would be very useful as I've already encountered this limitation.
Also going back to the Cisco ASR9K it has 2 separate 'modules' that can be slotted in PS0 for their power supplies.
You can slide either an A9K-AC-PEM-V3 or a A9K-DC-PEM-V3 to make the chassis accept either AC or DC power.
The AC power module accepts 3 power supplies, but the DC power module accepts 4.

Allowing the ASR chassis to have a module PS0, to then have the A9K-AC-PEM-V3 also be able to have it's own nested modules to slide power supplies into would be helpful.

@ghost commented on GitHub (Apr 11, 2022): Adding that this would be very useful as I've already encountered this limitation. Also going back to the Cisco ASR9K it has 2 separate 'modules' that can be slotted in PS0 for their power supplies. You can slide either an A9K-AC-PEM-V3 or a A9K-DC-PEM-V3 to make the chassis accept either AC or DC power. The AC power module accepts 3 power supplies, but the DC power module accepts 4. Allowing the ASR chassis to have a module PS0, to then have the A9K-AC-PEM-V3 also be able to have it's own nested modules to slide power supplies into would be helpful.
adam commented 2025-12-29 19:39:37 +01:00
Author
Owner
Copy Link

@shatt79 commented on GitHub (Apr 11, 2022):

Agreed. And eventually we're going to need this functionality for transceivers. A port/interface is NOT always a singular entity. There are such things as 40 & 100G breakouts and CSFPs. Years ago, the "modular" models of things was typically geared toward service providers. They were the exception rather than the rule. Today, multi level modular systems are the norm rather than the exception.

@shatt79 commented on GitHub (Apr 11, 2022): Agreed. And eventually we're going to need this functionality for transceivers. A port/interface is NOT always a singular entity. There are such things as 40 & 100G breakouts and CSFPs. Years ago, the "modular" models of things was typically geared toward service providers. They were the exception rather than the rule. Today, multi level modular systems are the norm rather than the exception.
adam commented 2025-12-29 19:39:38 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 11, 2022):

Please describe under the "Database changes" of your post above the specific schema change(s) you are proposing to accommodate the described functionality.

@jeremystretch commented on GitHub (Apr 11, 2022): Please describe under the "Database changes" of your post above the specific schema change(s) you are proposing to accommodate the described functionality.
adam commented 2025-12-29 19:39:38 +01:00
Author
Owner
Copy Link

@mmfreitas commented on GitHub (Apr 12, 2022):

I have mentioned this on the #7844. Nested modules would be a good implementation, and I do have uses for it, but I've done a workaround by adding extra module bays to the chassis-based device, although this isn't the truthful way of doing it, since the chassis doesn´t have these "child card slots"...

Ex: (ASR9010 in reality has Slots 0/[0-7]/CPU0 module bays)
image
Since the 0/7 doesn't have any interfaces, but has 2 slots within it I added to the chassis the 0/7/0 and 0/7/1 module bays and installed the modular port adapter cards there.

With nested modules this would not need a workaround and all would be modeled correctly:

  • ASR9010 (chassis-based device):
    • Slot 0/7/CPU0 (module-bay of chassis) [installed A9K-MOD200-TR] {module}
      • Slot 0/7/0 (module-bay of A9K-MOD200-TR) [installed card A9K-MPA-20X1GE] {submodule}
        • interfaces: GigabitEthernet{module}/{submodule}/[0-19]
      • Slot 0/7/1 (module-bay of A9K-MOD200-TR) [installed card A9K-MPA-4X10GE] {submodule}
        • interfaces: TenGigabitEthernet{module}/{submodule}/[0-3]
@mmfreitas commented on GitHub (Apr 12, 2022): I have mentioned this on the #7844. Nested modules would be a good implementation, and I do have uses for it, but I've done a workaround by adding extra module bays to the chassis-based device, although this isn't the truthful way of doing it, since the chassis doesn´t have these "child card slots"... Ex: (ASR9010 in reality has Slots 0/[0-7]/CPU0 module bays) ![image](https://user-images.githubusercontent.com/91552302/162948306-d6d551dd-6384-4f39-a061-78206694acf4.png) Since the 0/7 doesn't have any interfaces, but has 2 slots within it I added to the chassis the 0/7/0 and 0/7/1 module bays and installed the modular port adapter cards there. With nested modules this would not need a workaround and all would be modeled correctly: - ASR9010 (chassis-based device): - Slot 0/7/CPU0 (module-bay of chassis) [installed A9K-MOD200-TR] {module} - Slot 0/7/0 (module-bay of A9K-MOD200-TR) [installed card A9K-MPA-20X1GE] {submodule} - interfaces: GigabitEthernet{module}/{submodule}/[0-19] - Slot 0/7/1 (module-bay of A9K-MOD200-TR) [installed card A9K-MPA-4X10GE] {submodule} - interfaces: TenGigabitEthernet{module}/{submodule}/[0-3]
adam commented 2025-12-29 19:39:38 +01:00
Author
Owner
Copy Link

@guipoletto commented on GitHub (Apr 21, 2022):

ZTE calls these "subcards" (generally stuff that plugs in inside the card, before insertion, not being externally exposed.

Another example i know of is huawei. Some service routers come in AC and DC chassis variants

The AC chassis is basically the DC version with blanks in the DC_IN ports

Two of the Service Slots are taken up by a "PSU_Cage" with tho "Subslots" that can in turn hold the AC bricks.

Examples:
https://support.huawei.com/enterprise/en/doc/EDOC1100149053/f446cf6d/netengine-8000-m14
https://download.huawei.com/mdl/image/download?uuid=25b2f6a39a23400f9a9e65d24ccb5f4a

@guipoletto commented on GitHub (Apr 21, 2022): ZTE calls these "subcards" (generally stuff that plugs in inside the card, before insertion, not being externally exposed. Another example i know of is huawei. Some service routers come in AC and DC chassis variants The AC chassis is basically the DC version with blanks in the DC_IN ports Two of the Service Slots are taken up by a "PSU_Cage" with tho "Subslots" that can in turn hold the AC bricks. Examples: https://support.huawei.com/enterprise/en/doc/EDOC1100149053/f446cf6d/netengine-8000-m14 https://download.huawei.com/mdl/image/download?uuid=25b2f6a39a23400f9a9e65d24ccb5f4a
adam commented 2025-12-29 19:39:38 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 22, 2022):

Closing this out as there's been no response to my request for a more detailed implementation proposal. @shatt79 I'm happy to re-open the issue if you'd like to flesh out your proposed implementation.

@jeremystretch commented on GitHub (Apr 22, 2022): Closing this out as there's been no response to my request for a more detailed implementation proposal. @shatt79 I'm happy to re-open the issue if you'd like to flesh out your proposed implementation.
adam commented 2025-12-29 19:39:39 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Apr 24, 2022):

This shouldn't be closed.

@ghost commented on GitHub (Apr 24, 2022): This shouldn't be closed.
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: revisions needed 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#6340
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?