Philosophy of NetBox working with modules

[lakhnod]

Hi all.

Maybe I don't quite understand the philosophy of NetBox working with modules, but when using them I had some questions and suggestions

---

Why 'Module Types' doesn't have 'slug' field?

---

''Modules' and 'Module bay' in 'Devices' don't have property 'Module roles'

Divide modules by roles so that modular power supplies are not inserted into the 'Module bay' for SFP and simplify the selection of a module from a large list when added to the device

The 'Module roles' are made of fixed types, like interface types, it needed for same reasons, to allow use it in .yaml pattern files. If the device has no 'Module roles' specified in the 'Module bay', show all entire list of 'Module' and allow to add any module in that 'Module bay'

Example of 'Module roles':

• SFP modules
• Network modules
• Stack modules
• Power modules
• ... some other modules
• Other modules

---

Replicate components - Automatically populate components associated with this module type
Adopt components - Adopt already existing components

When we install module to module bay with options 'Replicate components' and 'Adopt components', same existing components deleted from device, and using from module, but when we removing module from module bay adopted components also removing and deleted components not recovering in device. Maybe need hide same components in device when install module and unhide them when module removed?

---

• modules should have a module bays for insert them into each other like a matryoshka

for example

• Cisco Catalyst 9300 Series Switch (device)
  • C9300-NM-4G (network module in device)
    • Copper SFP 1G Module (SFP module in network module C9300-NM-4G)
    • Optical SFP 1G Module (SFP module in network module C9300-NM-4G)
  • C9300-STACK (stacking module StackAdapter{stack-id}/1 in device)
    • STACK-T1-50CM (stacking module, cable on end like SFP module, StackPort{stack-id}/1 in 1 stacking module)
  • C9300-STACK (stacking module StackAdapter{stack-id}/1 in device)
    • STACK-T1-50CM (stacking module, cable on end like SFP module, StackPort{stack-id}/2 in 2 stacking module)
  • PWR-C1-1100WAC-P Power Supply A (power module in device)
  • PWR-C1-1100WAC-P Power Supply B (power module in device)

note: stacking module and stacking cable end is independent devices with its own serial numbers

https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9300-series-switches/nb-06-cat9300-ser-data-sheet-cte-en.html#Platformdetails

---

Some about stacking devices:

If we stacking devices in Virtual Chassis - Position 0 - not display (Huawei switches in stack counting from 0).
Variable Position must be - none(empty),0,1,...,N

New variable {stack-id} or {position} in Virtual Chassis needed like variable {module} for auto renumbering interfaces in stacking devices.

iterfacees in .yaml will look like this:

• GigabitEthernet{stack-id}/0/1 or GigabitEthernet{vc-position}/0/1
• GigabitEthernet{stack-id}/{module}/1 or GigabitEthernet{vc-position}/{module}/1

For example: Huawei switch stacking - Stack ID

The slot number of the member switches used to identify and manage member switches. In a stack, each switch has a unique stack ID, which can be manually configured to be 0, the stack ID has an impact on the number of the exchange port, and the specific manifestation is, after the switch adds a stack, its port number will become:

Stack ID / sub-card number / port number

(if you do not add stacking, G0/0/1 after adding stack, if the stack ID of the switch is 2, then the number of port G0/0/1 becomes G2/0/1)

[Zeawiel]

Hello,

I'm interested in this conversation. Especially about the Matryoshka-ish part!

I'm working with Nokia equipment and at some point it's really looking like puppets on each other:

• Shelf
  • XCM mother card
    • IOM daugter card
      • MDA port card

This looks like this, except there is XCM before IOM on shelf ... : https://static.wixstatic.com/media/c7820a_d6288bfaed604267ae0d0d2ff7001139~mv2.png

And also, afterwards on MDA, we have to specify, on each interface, the connector to have 1100G or 410G ports.

This is a nightmare to model in any tools. I think the other vendors make some mystic things like this too.

Module bay is really interesting but it would be lovely to have module bay in module to be able to populate those routers.

Anyone had already facing this? Do you know which is the bay way to model it?
At this time, we are just making interface one by one on router and we are not using modules.

[smasharov]

I have faced the same issue. A lot of devices have module hierarchy, so in my opinion NetBox must have a submodule function. Also it will be good to add compatibility options, so you can "insert" only a compatible module in the bay.

[josegaert]

I face the same issue. The bay system seems unworkable with advanced machines like the Juniper MX routers. Bay in Module seems necessary for it to make sense.

[mtinberg]

I'm not a Netbox developer but I have opinions, I think a big trap for modeling is prioritizing accuracy over usefulness. Sure, the linecards have nested modules, but what benefit to config templating or audit automation would this accuracy bring? Recursive joins in the database to model nesting are more complex, is that complexity worth it for everyone who uses Netbox? Would that nesting need to be resolved on every query to Device records, Location is nested and doesn't do that, querying of Device records are likely performance sensitive when Netbox is used as inventory for config management. For example could you model these as Inventory Items if the main thing are tracking is the model/serial number association to the device, and add/remove the Interfaces from the Device by script or by hand when the physical device is changed, ignoring the Device/Module Bays feature entirely. Or create a naming convention for Module Bays like slot1_module1, slot1_module2, slot2_module1_part1, slot3, ... if you do need to track the Module Types association with Devices and have Interfaces auto-created from the Modules, with custom scripts to help manage and sanity check the naming convention, maybe even adding the Module Bays to the existing Device record as linecards which accept modules are added/removed. This gives indication of hierarchy while keeping the DB schema flat. If there are a number of groups using similar equipment you could even collaborate with them on making Scripts/Reports or Plugins, so you wouldn't be alone in creating/debugging these conventions and custom code. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: Zeawiel ***@***.***> Sent: Thursday, January 26, 2023 5:04 AM To: netbox-community/netbox ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [netbox-community/netbox] Philosophy of NetBox working with modules (Discussion #9621) Hello, I'm interested in this conversation. Especially about the Matryoshka-ish part! I'm working with Nokia equipment and at some point it's really looking like puppets on each other: * Shelf * XCM mother card * IOM daugter card * MDA port card This looks like this, except there is XCM before IOM on shelf ... : https://static.wixstatic.com/media/c7820a_d6288bfaed604267ae0d0d2ff7001139~mv2.png And also, afterwards on MDA, we have to specify, on each interface, the connector to have 1100G or 410G ports. This is a nightmare to model in any tools. I think the other vendors make some mystic things like this too. Module bay is really interesting but it would be lovely to have module bay in module to be able to populate those routers. Anyone had already facing this? Do you know which is the bay way to model it? At this time, we are just making interface one by one on router and we are not using modules. — Reply to this email directly, view it on GitHub<#9621 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM5TVREL3ETYMGDRM33WUJK4XANCNFSM52CDHURQ>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[smasharov]

I do not agree, each module have it's own model and serial number, and with proper hierarchy interface names will be created automatically
for example we have a lot of Juniper MX960 devices, they have hundreds of interfaces, the top layer is the FPC and most of modules a created at this level, but some devices have MX-MPC2E-3D-P modules, that is in fact twin submodule to insert smaller modules and we have two additional layers: MIC and PIC, also it will be good to add SFP/XFP modules as well