Introduce a model for device modules/line cards

[jeremystretch]

NetBox version

v3.0.10

Feature type

New functionality

Proposed functionality

Add two new models for tracking the installation of field-swappable hardware modules/line cards/etc. within devices: Module and ModuleType. These will roughly parallel Device and DeviceType, where the later serves as a "template" for instances of the former. A ModuleType can have device component templates assigned to it. Upon the "installation" of a Module within a Device, these components will be instantiated and assigned to the new Module, just as with DeviceTypes.

It likely also makes sense to introduce ModuleBays, to which (similar to DeviceBays) Modules can be installed. A ModuleBay can be assigned a position identifier, which can be leveraged to automatically rename component templates assigned to a ModuleType.

For example, suppose we have a DeviceType with six ModuleBayTemplates. When creating a new Device from this DeviceType, it would receive six ModuleBays assigned to it. Next we might device a ModuleType with 24 InterfaceTemplates assigned to it. When "installing" a Module into the Device, 24 new Interfaces would be created and assigned to the Module. Ideally, these would be automatically named to correspond to the Module's position. (The exact logic supporting this is TBD but there are a few options.)

When a Module is removed, it and any associated device components would be deleted.

(This concept was originally introduced in #824, but has been updated and fleshed out a bit.)

Use case

This proposal would address the use case of modeling chassis-based devices with removable line cards or similar components. Some examples include the Cisco Nexus 7000 series switch and Juniper MX480 router. Associating individual components with a module provides a layer of relationship that better facilitates the addition and removal of these components as they relate to the parent module.

Database changes

The proposal above requires the addition of four new models:

• ModuleBayTemplate
• ModuleBay
• ModuleType
• Module

It will also require changing the device_type ForeignKey relationship on the device component template models to a GenericForeignKey, so that they can be associated with ModuleTypes as well.

External dependencies

No response

[mmfreitas]

Hello, would this approach cover multiple levels of line cards?

An example with some Cisco Models:

1. We have a router that has 10 slots (Cisco ASR 9010) [Parent Device]
2. We have a Modular Line Card installed in slot 7 (Cisco A9K-MOD200-TR) [Child device of 1 and Parent device of 3 and 4]
3. We have a Modular Port Adapter installed in the slot 0 of the A9K-MOD200-TR (Cisco A9K-MPA-20X1GE) [Child device of 2]
4. We have another Modular Port Adapter in the slot 1 of the A9K-MOD200-TR (Cisco A9K-MPA-4X10GE) [Child device of 2]

In the command line when connecting to the router the interfaces of the cards have the following name:

3. Cisco A9K-MPA-20X1GE (has 20 interfaces):

   • Gi0/7/0/0,
   • Gi0/7/0/1,
   • Gi0/7/0/2, [...]
   • Gi0/7/0/19;

4. Cisco A9K-MPA-4X10GE (has 4 interfaces):

   • Te0/7/1/0,
   • Te0/7/1/1,
   • Te0/7/1/2,
   • Te0/7/1/3;

Would this level of nesting work as expected?

[jeremystretch]

No; this would only model a single level of module, which I'd expect to be sufficient for the vast majority of use cases.

[hiddenman]

@jeremystretch Great news! However, i can't figure out from the description whether this will close the SFP modules question?
Will it be possible to add a simple SFP module to the interface somehow? Or it's completely different option?

[jeremystretch]

@hiddenman SFPs would be addressed by the solution proposed in #7846.

[martink2]

I just played a bit around with the feature and have a question regarding naming of interfaces in modules.

We have a modular switch having 4 slots: slot1,slot2,slot3,slot4

We have two Linecards:

• Type A, Interfaces: TenGigabitEthernet1, TenGigabitEthernet2 etc.
• Type B, interfaces: GigabitEthernet1, GigabitEthernet2, etc.

When I insert Type A into Slot 1 i get the interfaces named as in the module template
When I insert Type A into Slot 2 i get a "duplicate key value violates unique constraint "dcim_interface_device_id_bffc4ec4_uniq"
When i insert Type B into slot 3 i get i also get the interfaces as in the template

In the real world the following happens:

Type A-Slot1: TenGigabitEthernet1 -> TenGigabitEthernet1/1
Type A-Slot2: TenGigabitEthernet1 -> TenGigabitEthernet2/1
Type B-Slot3: GigabitEthernet1 -> GigabitEthernet3/1

I took a quick survey through our inventory and the pattern seems to
pretty much boil down to:

(interface-type-name)(slot-prefix)(relative-id)
for my example:
(TenGigabitEthernet|GigabitEthernet)([1|2|3/])([1-n])

Where interface-type-name, seems to pretty uniformly come from the module/linecard
slot-prefix is always coming from the parent device and the relative-id again geeing
defined by the linecard.

Is there already any idea how this will be done?

Regex in the module-bay definition which will be applied to all module interfaces?
Regex in the module-type expecting a parameter coming from the module-bay on insertion ?

[jeremystretch]

Just to ensure expectations are clear, this is still very much a work in progress and not yet ready for evaluation.

I'm still weighing options for the component renaming. My plan right now is to add an integer position field to the ModuleBay model, and extend the component instantiation logic to support string replacement referencing it. So for example, you might define interface templates on a ModuleType named Gi{module}/0/[1-24]. When a new Module is "installed", its interfaces are named according to the position of its module bay. I still need to test this though.

If it works out, we might be able to implement something similar for virtual chassis, although that's a but more complicated because devices (and their components) can exist prior to VC assignment.

[martink2]

Totally understood and thanks for quick response, we are currently planning to have
a large number of modular patch pannels moved into netbox and this feature would be
a really big benefit for that effort.

As to the integer "position" field or generally the idea to transport information from
the module bay towards the module, that would be very nice. looking at our devices
we found a few scenarios where pure integer would present a challenge thought.

Devices with where Module bays use alpha-numerical identifiers within the same device:

Device A
ModuleBay a-0
ModuleBay a-1
ModuleBay b-0
ModuleBay b-1

On device name of interface: lc-a-0-0, lc-a-0-1 etc

Devices with internal "paths" to modules, this seems to be common in large modular
devices we have:

Device B
ModuleBay 0/0
ModuleBay 0/1
ModuleBay 0/2
ModuleBay 1/0
ModuleBay 1/1
ModuleBay 1/2

On device name of interface: GigabitEthernet0/1/0, GigabitEthernet1/1/2 etc.

I cross checked and in this case it is not about nested modules, like the comment above,
although most likely technically similar. The example is for a fixed configuration 6 Module
device, where the modules seem to be internally split into two groups by the vendor.
(found this in more then one vendor others use 0-1,0-2 etc notation).

Thanks again for spending time with this feature, we are really looking forward to it
landing in Netbox.

[jeremystretch]

looking at our devices we found a few scenarios where pure integer would present a challenge thought.

That's a fair point; I can just make it a character field to allow for maximum flexibility. My initial thought was to allow modification to it in format strings (e.g. {module+1}) but that should be unnecessary and may actually be dangerous anyway.

[jeremystretch]

Here's what I came up with.

[martink2]

Played around with the latest feature branch, it works quite nicely. Thanks a lot for that functionality.