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

Cannot add child interfaces to lag #10264

New Issue
Closed
opened 2025-12-29 21:29:07 +01:00 by adam · 4 comments
adam commented 2025-12-29 21:29:07 +01:00
Owner
Copy Link

Originally created by @craigmoscardini on GitHub (Sep 19, 2024).

Deployment Type

Self-hosted

NetBox Version

4.0.9

Python Version

3.12

Steps to Reproduce

Create parent interface with child. e.g. Juniper notation:

et-0/0/0 - QSFP56-DD
et-0/0/0.0 - Virtual
et-0/0/0.1 - Virtual
et-0/0/0.2 - Virtual
et-0/0/0.3 - Virtual

Create LAG interface

In this scenario it is 400G optic to 4x100G breakout cable.

Add et-0/0/0.0 to LAG
image

Cannot be added as virtual interface prevented from being in LAG.

So instead try deviate from reality a bit and set child interfaces to a physical QSFP28 (100G) each still as child for the QSFP56-DD.

image

Cannot be done as child must be parent.

Expected Behavior

Adding a child interface to a lag is a valid scenario based on the forced parent-child model. This should not be prevented.

Observed Behavior

Prevented from adding interfaces to lag. Only possible option I see currently is to remove the parent-child relationship and incorrectly create the sub-interfaces as individual 100G ports. This does not match the reality of the configuration though.

Originally created by @craigmoscardini on GitHub (Sep 19, 2024). ### Deployment Type Self-hosted ### NetBox Version 4.0.9 ### Python Version 3.12 ### Steps to Reproduce Create parent interface with child. e.g. Juniper notation: et-0/0/0 - QSFP56-DD et-0/0/0.0 - Virtual et-0/0/0.1 - Virtual et-0/0/0.2 - Virtual et-0/0/0.3 - Virtual Create LAG interface In this scenario it is 400G optic to 4x100G breakout cable. Add et-0/0/0.0 to LAG ![image](https://github.com/user-attachments/assets/2a2a90e7-914f-480b-800d-c7f258821ed0) Cannot be added as virtual interface prevented from being in LAG. So instead try deviate from reality a bit and set child interfaces to a physical QSFP28 (100G) each still as child for the QSFP56-DD. ![image](https://github.com/user-attachments/assets/6899fb20-36cc-44e9-add4-098ac4ed6e88) Cannot be done as child must be parent. ### Expected Behavior Adding a child interface to a lag is a valid scenario based on the forced parent-child model. This should not be prevented. ### Observed Behavior Prevented from adding interfaces to lag. Only possible option I see currently is to remove the parent-child relationship and incorrectly create the sub-interfaces as individual 100G ports. This does not match the reality of the configuration though.
adam added the type: bug label 2025-12-29 21:29:07 +01:00
adam closed this issue 2025-12-29 21:29:07 +01:00
adam commented 2025-12-29 21:29:08 +01:00
Author
Owner
Copy Link

@craigmoscardini commented on GitHub (Sep 19, 2024):

Note for completeness I have replicated this behaviour on the 4.1.0 hosted demo and it works in the same way

@craigmoscardini commented on GitHub (Sep 19, 2024): Note for completeness I have replicated this behaviour on the 4.1.0 hosted demo and it works in the same way
adam commented 2025-12-29 21:29:09 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 19, 2024):

The error messages are expected: Only physical interfaces can be LAG members.

In this scenario it is 400G optic to 4x100G breakout cable.

You need to define the channelized subinterfaces as physical 100G interfaces; these aren't virtual interfaces.

@jeremystretch commented on GitHub (Sep 19, 2024): The error messages are expected: Only physical interfaces can be LAG members. > In this scenario it is 400G optic to 4x100G breakout cable. You need to define the channelized subinterfaces as physical 100G interfaces; these aren't virtual interfaces.
adam commented 2025-12-29 21:29:09 +01:00
Author
Owner
Copy Link

@craigmoscardini commented on GitHub (Sep 19, 2024):

Thanks for the very quick rejection, but that goes against the whole principle of Netbox actually being accurate?

The device has a QSFP56-DD port. It does not have 4x QSFP28 ports. Your suggestion is to incorrectly represent the device, which means every device with channelised interfaces needs manual deviation from the device model template which actually is correct.

If as you say you cannot use virtual interface type (which I say can be legit), then surely we need a separate field or dedicated type to represent a breakout sub-interface rather than picking a fictional port type?

@craigmoscardini commented on GitHub (Sep 19, 2024): Thanks for the very quick rejection, but that goes against the whole principle of Netbox actually being accurate? The device has a QSFP56-DD port. It does not have 4x QSFP28 ports. Your suggestion is to incorrectly represent the device, which means every device with channelised interfaces needs manual deviation from the device model template which actually is correct. If as you say you cannot use virtual interface type (which I say can be legit), then surely we need a separate field or dedicated type to represent a breakout sub-interface rather than picking a fictional port type?
adam commented 2025-12-29 21:29:09 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 19, 2024):

I'm sorry but this decision has already been made. Each channel within the optic is a discrete, independent physical interface which can be operationally enabled or disabled without affecting its peers. This is in contrast to e.g. an 802.1Q-encapsulated virtual interface, which exists purely as a logical construct.

@jeremystretch commented on GitHub (Sep 19, 2024): I'm sorry but this decision has already been made. Each channel within the optic is a discrete, independent physical interface which can be operationally enabled or disabled without affecting its peers. This is in contrast to e.g. an 802.1Q-encapsulated _virtual_ interface, which exists purely as a logical construct.
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 type: bug
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#10264
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?