starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Allow to model passive pass-thru-modules (for example on blade centers) #1805

New Issue
Closed
opened 2025-12-29 17:19:16 +01:00 by adam · 2 comments
adam commented 2025-12-29 17:19:16 +01:00
Owner
Copy Link

Originally created by @kasimon on GitHub (Jun 20, 2018).

Issue type

[X] Feature request
[ ] Bug report
[ ] Documentation

Environment

  • Python version: 2.7.13
  • NetBox version: 2.3.3

Description

When trying to model HPE Bladecenters/enclosures (C7000) with netbox, we currently have to decide if we want the pysical cabling to be accurate or the logical network connection. The blade centers are equipped with pass-thru-modules, which simply extend each network port of the servers directly to a physical network port on back of the bladecenter. As in, blade server 1 has it's first nic mapped to the first port of the first pass-thru-module and so on for all 16 blades in the blade enclosure. The blade center and blade servers are modeled with a parent-child relation. Now, depending on how you look at it, the connection of this ports to the switch ends either on the blade chassis (if you look at the physical cabling) or on the server nic inside the blade server (if you look at layer 2/lldp/show neighbor/ethtool). Now the datacenter guys insist on modeling the physical cabeling between the blade center and the switch, in order to for example create proper cable labeling from the netbox data. The server guys on the other hand really want the logical connection modeled as for them the nic is conncected to the switch and they want to build upon the connection data for proper interface labeling, verifying vlan configurations and so on.

So in order to fix this we had the idea of a new interface type that 'borrows' the interface from another device, like 'this interface on this device is in fact that interface on that device', kind of an alias or symlink. This would allow both parties to accurately describe their setups.

I'm aware this would be a larger change, so I wonder if there is demand for this kind of mapping.

Originally created by @kasimon on GitHub (Jun 20, 2018). ### Issue type [X] Feature request [ ] Bug report [ ] Documentation ### Environment * Python version: 2.7.13 * NetBox version: 2.3.3 ### Description When trying to model HPE Bladecenters/enclosures (C7000) with netbox, we currently have to decide if we want the pysical cabling to be accurate or the logical network connection. The blade centers are equipped with pass-thru-modules, which simply extend each network port of the servers directly to a physical network port on back of the bladecenter. As in, blade server 1 has it's first nic mapped to the first port of the first pass-thru-module and so on for all 16 blades in the blade enclosure. The blade center and blade servers are modeled with a parent-child relation. Now, depending on how you look at it, the connection of this ports to the switch ends either on the blade chassis (if you look at the physical cabling) or on the server nic inside the blade server (if you look at layer 2/lldp/show neighbor/ethtool). Now the datacenter guys insist on modeling the physical cabeling between the blade center and the switch, in order to for example create proper cable labeling from the netbox data. The server guys on the other hand really want the logical connection modeled as for them the nic is conncected to the switch and they want to build upon the connection data for proper interface labeling, verifying vlan configurations and so on. So in order to fix this we had the idea of a new interface type that 'borrows' the interface from another device, like 'this interface on this device is in fact that interface on that device', kind of an alias or symlink. This would allow both parties to accurately describe their setups. I'm aware this would be a larger change, so I wonder if there is demand for this kind of mapping.
adam closed this issue 2025-12-29 17:19:16 +01:00
adam commented 2025-12-29 17:19:16 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 29, 2018):

Since the module is just pass-through, I would model the connections in NetBox as connecting to the servers themselves. This seems reasonable since the position of the cable is deterministic as you say (slot 1 = interface 1, etc.). Attempting to model the pass-through module would require an entire new level of abstraction and yield very little real value.

@jeremystretch commented on GitHub (Jun 29, 2018): Since the module is just pass-through, I would model the connections in NetBox as connecting to the servers themselves. This seems reasonable since the position of the cable is deterministic as you say (slot 1 = interface 1, etc.). Attempting to model the pass-through module would require an entire new level of abstraction and yield very little real value.
adam commented 2025-12-29 17:19:17 +01:00
Author
Owner
Copy Link

@kasimon commented on GitHub (Jun 29, 2018):

I'm not objecting that this ticket is closed, I just wan to add one use case we identified in the meantime that speaks against mapping the ports directly to the servers: When relocating blade servers in a blade center, the patching would follow the server location, where in "reality" the patching would still be on the same port, only that port now being connected to another server. But I can understand that this level of realism could be more distracting than helpful.

@kasimon commented on GitHub (Jun 29, 2018): I'm not objecting that this ticket is closed, I just wan to add one use case we identified in the meantime that speaks against mapping the ports directly to the servers: When relocating blade servers in a blade center, the patching would follow the server location, where in "reality" the patching would still be on the same port, only that port now being connected to another server. But I can understand that this level of realism could be more distracting than helpful.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#1805
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?