Breakout parent-child interface relationship

[dmulyalin]

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.

[Cricket357]

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).

[dmulyalin]

@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.

[oneone84]

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;

[oneone84]

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.

[tdentafix]

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.

[github-actions[bot]]

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]]

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.