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

Breakout parent-child interface relationship #8417

New Issue
Closed
opened 2025-12-29 20:36:26 +01:00 by adam · 7 comments
adam commented 2025-12-29 20:36:26 +01:00
Owner
Copy Link

Originally created by @dmulyalin on GitHub (Aug 4, 2023).

NetBox version

v3.5.7

Feature type

Change to existing functionality

Proposed functionality

Currently for interfaces to have parent set they have to be of type "virtual", which does not allow to model child-parent relationship for breakout interfaces, to overcome this limitation can:

Option-1 - ease the restriction of child interface having to be a virtual interface or
Option-2 - extend existing interface model to add new child-parent relationship to designate interfaces as a breakout child of the parent interface

Use case

Break out ports child-parent relationship modeling.

Breakout interfaces behave as normal physical interfaces as they are not logical entities but rather physical interfaces hanging off the end of the breakout cable, designating child-parent relationship for breakout ports allows to capture dependecies for impact analysis, configuration generation and better representation of the network.

Other loosly related issues:
https://github.com/netbox-community/netbox/issues/7552
https://github.com/netbox-community/netbox/issues/5798

Having said that, I do admit that this functionality can be implemented using custom fields with multiobject references, but believe including this in a core feature set can benefit many users.

Database changes

Not sure.

External dependencies

Not sure.

Originally created by @dmulyalin on GitHub (Aug 4, 2023). ### NetBox version v3.5.7 ### Feature type Change to existing functionality ### Proposed functionality Currently for interfaces to have parent set they have to be of type "virtual", which does not allow to model child-parent relationship for breakout interfaces, to overcome this limitation can: Option-1 - ease the restriction of child interface having to be a virtual interface or Option-2 - extend existing interface model to add new child-parent relationship to designate interfaces as a breakout child of the parent interface ### Use case Break out ports child-parent relationship modeling. Breakout interfaces behave as normal physical interfaces as they are not logical entities but rather physical interfaces hanging off the end of the breakout cable, designating child-parent relationship for breakout ports allows to capture dependecies for impact analysis, configuration generation and better representation of the network. Other loosly related issues: https://github.com/netbox-community/netbox/issues/7552 https://github.com/netbox-community/netbox/issues/5798 Having said that, I do admit that this functionality can be implemented using custom fields with multiobject references, but believe including this in a core feature set can benefit many users. ### Database changes Not sure. ### External dependencies Not sure.
adam added the type: featurepending closure labels 2025-12-29 20:36:26 +01:00
adam closed this issue 2025-12-29 20:36:26 +01:00
adam commented 2025-12-29 20:36:27 +01:00
Author
Owner
Copy Link

@Cricket357 commented on GitHub (Aug 4, 2023):

I am inclined to propose an Option-3 -- split "interface" objects from "port" objects within devices and modules. Leave virtual interfaces as they are since they serve a vital purpose in this sort of documentation.

The default behavior would remain a one-to-one "interface-to-port" design. However, users would be able to remove the existing named interface and configure the port to have multiple positions. Then create the additional interfaces to associate to the port positions inside the device/module. This would essentially treat the physical aspect of devices and modules the same as newer patch panels while allowing the logic to match the OS configuration, keeping both the physical and logical connection paths intact.

Existing devices/modules and templates would just have the physical interface duplicated to a new single-position "port" field.

By going a step further and allowing one logical Interface to associate with multiple physical Ports, this might also lead to properly cataloging fiber TX/RX connectivity and tracing for those occasions where a single "interface" terminates to separate ports (think Duplex LC connections to Simplex like FC and ST, or physically separate MUX/DEMUX).

@Cricket357 commented on GitHub (Aug 4, 2023): I am inclined to propose an Option-3 -- split "interface" objects from "port" objects within devices and modules. Leave virtual interfaces as they are since they serve a vital purpose in this sort of documentation. The default behavior would remain a one-to-one "interface-to-port" design. However, users would be able to remove the existing named interface and configure the port to have multiple positions. Then create the additional interfaces to associate to the port positions inside the device/module. This would essentially treat the physical aspect of devices and modules the same as newer patch panels while allowing the logic to match the OS configuration, keeping both the physical and logical connection paths intact. Existing devices/modules and templates would just have the physical interface duplicated to a new single-position "port" field. By going a step further and allowing one logical Interface to associate with multiple physical Ports, this might also lead to properly cataloging fiber TX/RX connectivity and tracing for those occasions where a single "interface" terminates to separate ports (think Duplex LC connections to Simplex like FC and ST, or physically separate MUX/DEMUX).
adam commented 2025-12-29 20:36:27 +01:00
Author
Owner
Copy Link

@dmulyalin commented on GitHub (Aug 5, 2023):

@Cricket357 this is too big of an ask IMHO, I am after much simpler thing - be able to build parent child relationships between physical interfaced.

@dmulyalin commented on GitHub (Aug 5, 2023): @Cricket357 this is too big of an ask IMHO, I am after much simpler thing - be able to build parent child relationships between physical interfaced.
adam commented 2025-12-29 20:36:28 +01:00
Author
Owner
Copy Link

@oneone84 commented on GitHub (Aug 24, 2023):

I might be thinking of another kind of break out panel and break out cables, but I think the multi-object cable-peer already solves this? It is one of the newer functions added (earlier this year I think)

In the case of break out panels we can use a break-out-cable in the rear-ports;
bild

bild

@oneone84 commented on GitHub (Aug 24, 2023): I might be thinking of another kind of break out panel and break out cables, but I think the multi-object cable-peer already solves this? It is one of the newer functions added (earlier this year I think) In the case of break out panels we can use a break-out-cable in the rear-ports; ![bild](https://github.com/netbox-community/netbox/assets/44062096/b056baef-9472-4787-8680-7974a6677e4b) ![bild](https://github.com/netbox-community/netbox/assets/44062096/62bf17b7-8caa-43e1-becb-0c4b89a87de1)
adam commented 2025-12-29 20:36:28 +01:00
Author
Owner
Copy Link

@oneone84 commented on GitHub (Sep 18, 2023):

After doing more testing, I also see some problems.
When "splitting" an interface by adding multiple connected objects, there is no separation of values, for example the vlan, that is set on the interface. The current functionality does not support using a 40G break-out to 4x10G with different vlan(s) for each of the 10g connections.

Child interfaces does not support connecting cables as they need to be virtual.

@oneone84 commented on GitHub (Sep 18, 2023): After doing more testing, I also see some problems. When "splitting" an interface by adding multiple connected objects, there is no separation of values, for example the vlan, that is set on the interface. The current functionality does not support using a 40G break-out to 4x10G with different vlan(s) for each of the 10g connections. Child interfaces does not support connecting cables as they need to be virtual.
adam commented 2025-12-29 20:36:28 +01:00
Author
Owner
Copy Link

@tdentafix commented on GitHub (Nov 7, 2023):

Adding a few comments on this issue. This is a problem we are very often running into as we do use breakout optics all over the place. Here are a few examples of those new optics that came to market very recently :

And a lot more optics that do the same kind of thing.
The model currently doesn't allow this usage and this is a problem to us because we want :

  • to track optical modules for inventory purposes : then we need the concept of the equipment's QSFP-DD cage with the module inside
  • to track individual interfaces offered by those modules, for automation and information system purposes
  • to link the two because optical power measurements are done at the cage level, not the sub-interface level, but we still need to know which optical lanes correspond to which sub-interfaces

Currently the only workaround I can see to this is :

  • create dummy interfaces for the module itself
  • create "real" interfaces for the breakouts - but this does not reflect reality as it has no link to the master module and the form factor isn't accurate

Any progress on this matter will be appreciated ; to me, the "child interfaces" feature is very close to a good solution.

@tdentafix commented on GitHub (Nov 7, 2023): Adding a few comments on this issue. This is a problem we are very often running into as we do use breakout optics all over the place. Here are a few examples of those new optics that came to market very recently : - 2x100G LR4 : one module, dual interfaces with independant CS-duplex connectors(no breakout cable) (ex: https://www.flexoptix.net/en/d-161hg2-10.html) - 4x100G DR/FR/LR : one module, four different physical interfaces with independant SN-duplex connectors (again no breakout cable) (ex: https://www.flexoptix.net/en/d-134hg-10-n.html) And a lot more optics that do the same kind of thing. The model currently doesn't allow this usage and this is a problem to us because we want : - to track optical modules for inventory purposes : then we need the concept of the equipment's QSFP-DD cage with the module inside - to track individual interfaces offered by those modules, for automation and information system purposes - to link the two because optical power measurements are done at the cage level, not the sub-interface level, but we still need to know which optical lanes correspond to which sub-interfaces Currently the only workaround I can see to this is : - create dummy interfaces for the module itself - create "real" interfaces for the breakouts - but this does not reflect reality as it has no link to the master module and the form factor isn't accurate Any progress on this matter will be appreciated ; to me, the "child interfaces" feature is very close to a good solution.
adam commented 2025-12-29 20:36:29 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Feb 6, 2024):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Feb 6, 2024): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 20:36:29 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Mar 7, 2024):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Mar 7, 2024): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
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 pending closure type: feature
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#8417
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?