-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Comments
Adding that this would be very useful as I've already encountered this limitation. 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. |
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. |
Please describe under the "Database changes" of your post above the specific schema change(s) you are proposing to accommodate the described functionality. |
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) With nested modules this would not need a workaround and all would be modeled correctly:
|
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: |
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. |
This shouldn't be closed. |
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
The text was updated successfully, but these errors were encountered: