Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi-Level / Nested Modules #9107

Closed
shatt79 opened this issue Apr 10, 2022 · 7 comments
Closed

Multi-Level / Nested Modules #9107

shatt79 opened this issue Apr 10, 2022 · 7 comments
Labels
status: revisions needed This issue requires additional information to be actionable type: feature Introduction of new functionality to the application

Comments

@shatt79
Copy link

shatt79 commented 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

@shatt79 shatt79 added the type: feature Introduction of new functionality to the application label Apr 10, 2022
@cyr0nk0r
Copy link

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.

@shatt79
Copy link
Author

shatt79 commented 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.

@jeremystretch
Copy link
Member

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

@jeremystretch jeremystretch added the status: revisions needed This issue requires additional information to be actionable label Apr 11, 2022
@mmfreitas
Copy link

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]

@guipoletto
Copy link

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

@jeremystretch
Copy link
Member

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.

@cyr0nk0r
Copy link

cyr0nk0r commented Apr 24, 2022

This shouldn't be closed.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 24, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: revisions needed This issue requires additional information to be actionable type: feature Introduction of new functionality to the application
Projects
None yet
Development

No branches or pull requests

5 participants