Allow modules to contain module bays and modules to be parents of other modules.

[roadracer96]

NetBox version

v3.3.4

Feature type

Change to existing functionality

Proposed functionality

Some network devices have line cards inserted into slots that provide sub-slots.

Example: Juniper MX Chassis FPC0 - Line card module -- MIC0 - Sub-module -- -- PIC0 - Sub-Sub-module -- -- -- Interface et-0/0/0 -- MIC1 - Sub-module -- -- PIC2 - Sub-Sub-module -- -- -- Interface et-0/2/0 -- -- -- Interface et-0/2/1

Thought would need to be put into using the {module} variable in a nested fashion to permit automatic addition of interfaces based on the module template. In some cases, allowing a limited degree of math in the calculation of interface #s would be needed. But from a pure inventory standpoint, having the ability to populate these the way some network devices see them would be very useful.

Use case

Inventory, Generation of interfaces from templates, modeling device configurations.

Database changes

No response

External dependencies

No response

[mmfreitas]

I did asked about nesting modules when modules were being implemented, but this is not supported, you can check #7844 if you need more information.

Since then I've been using a work around, I have been creating this nesting level by simply adding a module bay with the nested position to the device / device type. This way you have a high level of costumization.

For ex: Slot 0 = Position "0"

• Sub-Slot 0 = Position "0/0"
  • Sub-Sub-Slot 0 = Position "0/0/0"

In reality these are 3 different slots, but you can manage some level of nesting using this logic, also keep in mind that netbox is not an inventory system, and you should not use modules for asset tracking.

[roadracer96]

That is what I am doing in the interim. The problem is, you cant appropriately name template interfaces on the sub-slots. I thought that it may be a beneficial feature/add to have a flexible module design that allows unlimited nesting.

[jeremystretch]

This idea has already been raised under #9107, however no detailed implementation was proposed. This issue also does not provide any substantial detail. Please flesh out your proposal to include the necessary details, especially the proposed database changes, so that they can be considered and discussed.

[kkthxbye-code]

I have looked at this in the past, and am still considering implementing it as we use Juniper devices like the ones in your example.

I think there's a couple of things that needs to be decided:

Are we to support unlimited nesting and how are we templating the position? If we are to support unlimited nesting, we need to figure out how to do the templating. Imagine a FPC -> MIC -> PIC scenario:

• We could either let the user specify the template variable name on the module, so the user could enter fpc for the FPC, mic for the MIC and pic for the pic. Then the templated interface on the PIC could be xe-{fpc}/{mic}/{pic} where we just follow the parent relationship until we reach the root module, gathering the template names and the positions.
• Another way would be to add an index to template variable, so maybe the root would remain {module} and subsequent nested modules would be {module-2}, {module-3}, {module-4} etc.
• A third way would be to just used {module} for all nesting levels but replace them from left to right. This is more limiting but probably easier to implement.

Another thing that needs to be decided is how to make it clear that module bays on a module template applies to the module and will not be instantiated on the device like the other device components. Maybe it's not an issue, but it might be more clear to find another name or figure out another way to present it in the UI instead of under Add components.

[jeremystretch]

Let's keep the discussion focused on the proposed implementation. If you don't have anything of substance to add, please refrain from commenting.

[cyr0nk0r]

I have looked at this in the past, and am still considering implementing it as we use Juniper devices like the ones in your example.

I think there's a couple of things that needs to be decided:

Are we to support unlimited nesting and how are we templating the position? If we are to support unlimited nesting, we need to figure out how to do the templating. Imagine a FPC -> MIC -> PIC scenario:

• We could either let the user specify the template variable name on the module, so the user could enter fpc for the FPC, mic for the MIC and pic for the pic. Then the templated interface on the PIC could be xe-{fpc}/{mic}/{pic} where we just follow the parent relationship until we reach the root module, gathering the template names and the positions.
• Another way would be to add an index to template variable, so maybe the root would remain {module} and subsequent nested modules would be {module-2}, {module-3}, {module-4} etc.
• A third way would be to just used {module} for all nesting levels but replace them from left to right. This is more limiting but probably easier to implement.

Another thing that needs to be decided is how to make it clear that module bays on a module template applies to the module and will not be instantiated on the device like the other device components. Maybe it's not an issue, but it might be more clear to find another name or figure out another way to present it in the UI instead of under Add components.

I don't believe unlimited nesting would be good for anyone. But we must also consider that if we say 1 level is ok, but 2 or 3 or 4 levels isn't .. inevitably someone is going to say "why can't I go 2 or 3 levels deep, my hardware works like that"

If we were to perhaps strike a balance of allowing maybe 2 layers deep? I have not seen any equipment in my years that has a module that goes into a module that goes into a module that goes into a module :D

The Cisco ASR 9K for example has power supplies that go into a Power Module .. that power module then goes into the Chassis. Can anyone offer examples where you would need 3 levels deep?

[roadracer96]

Isn't unlimited nesting already allowed in other places? Like regions?

I'd argue for that to future proof it if possible. It only takes one vendor doing something differently to make it a requirement. Think of it in terms of logical vs physical. Say, a nested bridge port extender scenario..

On Tue, Oct 4, 2022, 11:10 AM cyr0nk0r @.***> wrote:

I have looked at this in the past, and am still considering implementing it as we use Juniper devices like the ones in your example.

I think there's a couple of things that needs to be decided:

Are we to support unlimited nesting and how are we templating the position? If we are to support unlimited nesting, we need to figure out how to do the templating. Imagine a FPC -> MIC -> PIC scenario:

• We could either let the user specify the template variable name on the module, so the user could enter fpc for the FPC, mic for the MIC and pic for the pic. Then the templated interface on the PIC could be xe-{fpc}/{mic}/{pic} where we just follow the parent relationship until we reach the root module, gathering the template names and the positions.
• Another way would be to add an index to template variable, so maybe the root would remain {module} and subsequent nested modules would be {module-2}, {module-3}, {module-4} etc.
• A third way would be to just used {module} for all nesting levels but replace them from left to right. This is more limiting but probably easier to implement.

Another thing that needs to be decided is how to make it clear that module bays on a module template applies to the module and will not be instantiated on the device like the other device components. Maybe it's not an issue, but it might be more clear to find another name or figure out another way to present it in the UI instead of under Add components.

I don't believe unlimited nesting would be good for anyone. But we must also consider that if we say 1 level is ok, but 2 or 3 or 4 levels isn't .. inevitably someone is going to say "why can't I go 2 or 3 levels deep, my hardware works like that"

If we were to perhaps strike a balance of allowing maybe 2 layers deep? I have not seen any equipment in my years that has a module that goes into a module that goes into a module that goes into a module :D

The Cisco ASR 9K for example has power supplies that go into a Power Module .. that power module then goes into the Chassis. Can anyone offer examples where you would need 3 levels deep?

— Reply to this email directly, view it on GitHub https://github.com/netbox-community/netbox/issues/10500#issuecomment-1267158351, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCMTM2LEO6WCR7HWIG6DMDWBRCIFANCNFSM6AAAAAAQX5B3C4 . You are receiving this because you authored the thread.Message ID: @.***>

[kkthxbye-code]

Isn't unlimited nesting already allowed in other places? Like regions?

I don't see any actual downside to allowing unlimited nesting if we figure out a good way for the templating. Operations traversing the relationship back to the root will obviously take longer, but it shouldn't be an issue with normal non-extreme usecases.

In some cases, allowing a limited degree of math in the calculation of interface #s would be needed.

Could you please expand on this? I am fairly certain that this is not something we will entertain, but I would like to understand the usecase regardless.

[DanSheps]

Could you please expand on this? I am fairly certain that this is not something we will entertain, but I would like to understand the usecase regardless.

I think it is more along the lines of the {module} replacement string, however I could see instead having nested bays position being {module}-###

So if you had:

FPC0 - Line card module -- MIC0 - Sub-module -- -- PIC0 - Sub-Sub-module

The PIC0 "position" would be:

0/0/0

On an interface you would end up with:

0/0/0/#

[roadracer96]

Sorry about the delay.. Lots of demands on my time right now.

Right now, we allow a single variable in defining interface names in the form of { module }.

In a nested module scenario, wed need a way to account for sub-modules. In a juniper device, the MIC creates an offset in the PICs.

Example: A 20x1g MIC has 2 PICs The MIC goes into an FPC that has 2 slots. MIC0 and MIC1 If you put the MIC in MIC0, it has PIC0 and PIC1 resulting in ge-0/0/[0-9] and ge-0/1/[0-9] If you put the MIC in MIC1, the ports are ge-0/2/[0-9] and ge-0/3/[0-9]

Real world example: FPC 0 REV 26 750-031089 CAAZ7366 MPC Type 2 3D CPU REV 08 711-030884 CAAZ7050 MPC PMB 2G MIC 0 REV 28 750-028387 ABCA5555 3D 4x 10GE XFP PIC 0 BUILTIN BUILTIN 2x 10GE XFP Xcvr 0 NON-JNPR F8084039010B XFP-10G-SR Xcvr 1 REV 01 740-014289 M1009743 XFP-10G-SR PIC 1 BUILTIN BUILTIN 2x 10GE XFP Xcvr 0 NON-JNPR W443937701B4 XFP-10G-SR Xcvr 1 NON-JNPR C737XS0DU XFP-10G-SR MIC 1 REV 24 750-028392 ABBL7092 3D 20x 1GE(LAN) SFP PIC 2 BUILTIN BUILTIN 10x 1GE(LAN) SFP PIC 3 BUILTIN BUILTIN 10x 1GE(LAN) SFP Xcvr 0 REV 02 740-013111 M0608300101 SFP-T Xcvr 1 REV 02 740-013111 M0608300047 SFP-T Xcvr 2 REV 01 740-011784 M07C1200184 SFP-EX Xcvr 3 REV 01 740-011784 M07C1200194 SFP-EX

So maybe there are 2 asks:

1. Add {module-n} functionality where n is the degree of nesting. module-0 would represent the top level card, module-1 the next level and so-on. This would work for a lot of future use case I could see.
2. Basic math functions in deriving the interface number

The template format may end up looking like this:

ge-{module-0}/{module-12+0}/[0-9] <-- PIC0 ge-{module-0}/{module-12+1}/[0-9] <-- PIC1

Assuming FPC1 {module-0} with MICs 0/1 {module-1} both populated:

ge-1/02+0/[0-9] = ge-1/0/[0-9] <- FPC 1 MIC 0 PIC 0 ge-1/02+1/[0-9] = ge-1/1/[0-9] <- FPC 1 MIC 0 PIC 1 and ge-1/12+0/[0-9] = ge-1/2/[0-9] <- FPC 1 MIC 1 PIC 2 ge-1/12+1/[0-9] = ge-1/3/[0-9] <- FPC 1 MIC 1 PIC 3

This shouldnt tax the system as it is really only used int he templating process and not every time you click on a device..

Thoughts?

On Tue, Oct 4, 2022 at 1:52 PM kkthxbye @.***> wrote:

Isn't unlimited nesting already allowed in other places? Like regions?

I don't see any actual downside to allowing unlimited nesting if we figure out a good way for the templating. Operations traversing the relationship back to the root will obviously take longer, but it shouldn't be an issue with normal non-extreme usecases.

In some cases, allowing a limited degree of math in the calculation of interface #s would be needed.

Could you please expand on this? I am fairly certain that this is not something we will entertain, but I would like to understand the usecase regardless.

— Reply to this email directly, view it on GitHub https://github.com/netbox-community/netbox/issues/10500#issuecomment-1267353758, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCMTMZVHWF6426TJFZUD3DWBRVFBANCNFSM6AAAAAAQX5B3C4 . You are receiving this because you authored the thread.Message ID: @.***>

[craized]

Storing/presenting the module names as a list/stack seems like a pretty clean solution to me. Each sub-module could be pushed onto the module position stack which could then be shifted off in order for name completions. If a module name requires more module positions than are available, an exception is raised. If an interface name requires more module positions than are available in the stack, they are ignored/discarded.

Module 0: FPC 0         - Supports {module} in templating
|-> Module 0: MIC 0     - Supports {module}/{module} in templating
    |-> Module 0: PIC 0 - Supports {module}/{module}/{module} in templating

In the FPC/MIC/PIC scenario, an example interface of ge-{module}/{module}/{module} would only populate when a module is slotted 3 modules deep (sub-sub-module?).

[aztec102]

Let me try another example with the Alcatel Lucent 7750 SR-12 router. The router has 10 useful slots. Line cards (IOMs) are inserted into these slots. Each line card is divided into two compartments, where you can already put a submodule (in Nokia terminology = MDA). Also for example, we will take MDA = m2-10gb-xp-xfp which has two XFP 10Gb ports. Let's imagine a situation that we take IOM and put it in slot 3. get the first index 3 We put the MDA in slot 1 in this IOM. Already got index 3/1 As a result, we get two ports in the system 3/1/1 and 3/1/2

Therefore, I fully agree with my comrades, this implementation is very necessary.

[ppcarvalhof]

Thought would need to be put into using the {module} variable in a nested fashion to permit automatic addition of interfaces based on the module template. In some cases, allowing a limited degree of math in the calculation of interface #s would be needed. But from a pure inventory standpoint, having the ability to populate these the way some network devices see them would be very useful.

Really the lack of this possibility is a big limiting factor in NetBox for modular equipment. There is even something similar missing in the interface itself (for duplex/simplex modules) but, I digress...

keep in mind that netbox is not an inventory system, and you should not use modules for asset tracking.

This statement FOR ME makes no sense if we think that the idea of NetBox is to reflect the reality of how the equipment is and how they are interconnected. This for me is a very objective term when I think about documentation. The inventory, in my view, would be the aggregation of information on this equipment and cabling. Therefore, I cannot understand why it is not correct to add inventory information directly to the equipment. Just look at NetBox's own slogan: "The Premiere Network Source of Truth"

This idea has already been raised under #9107, however no detailed implementation was proposed. This issue also does not provide any substantial detail. Please flesh out your proposal to include the necessary details, especially the proposed database changes, so that they can be considered and discussed.

@jeremystretch I have a suggested implementation of a resource for modular interfaces. Could you contact him privately to help me formulate this proposition well? I know what to suger, but I don't know how. LOL

Storing/presenting the module names as a list/stack seems like a pretty clean solution to me. Each sub-module could be pushed onto the module position stack which could then be shifted off in order for name completions. If a module name requires more module positions than are available, an exception is raised. If an interface name requires more module positions than are available in the stack, they are ignored/discarded.

Module 0: FPC 0         - Supports {module} in templating
|-> Module 0: MIC 0     - Supports {module}/{module} in templating
    |-> Module 0: PIC 0 - Supports {module}/{module}/{module} in templating

In the FPC/MIC/PIC scenario, an example interface of ge-{module}/{module}/{module} would only populate when a module is slotted 3 modules deep (sub-sub-module?).

That would be more or less the way I think it would be interesting.

On how to resolve the recursion in the new feature I think that even using the {module} variable could be something "inheritable". Let's say I have a device (F) that has 4 slots (S) and in these slots we can place boards (P) and these boards allow us to place modules (let's say 4x10G qSFP Modules). I think that, when modeling, I would create something similar to the Frame/Slot/Port/M structure where the inheritance would be directly from the module, the {module} variable would already be resolved and saved as a string (processed only once). Let's say I put card X in slot 1 of the equipment (Frame 0). In the equipment model, the position in the Modulo entry would be 1 and the string would be resolved as 0/1. So what would be modeled on this board as port {module}/[1-12]. In this case, the first port the variable {module} would be saved as the string 0/1/1, the second port the string saved would be 0/1/2, etc... When inserting the module in port 1 the interface being modeled like GE {module}:[1-4]. The first interface string would be saved as GE 0/1/1:1. That is, the variable {module} would refer only to what is saved in "position" of the immediately superior bay. I think this would be the best way to resolve the "infinite" recursion of the variable without compromising the NetBox structure.

[jeremystretch]

As any implementation of nested modules would rely on a recursive nesting strategy, I'm marking this as blocked by #6587 / #11421.

[jeremystretch]

Unblocking this as we still haven't identified a suitable replacement for MPTT

[eronlloyd]

There is a use-case for passive optical equipment, as well. An LGX enclosure that holds LGX patch panels as modules in some cases should also be modeled to have module bays themselves, such as removable splice trays. An example would be this type of patch panel, where I would prefer to model the splice tray separately as they used in many applications. See the picture below for an illustration.