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

When physical interfaces belong to a LAG, they should inherit access/trunk detail from the parent lag #4039

New Issue
Closed
opened 2025-12-29 18:32:46 +01:00 by adam · 6 comments
adam commented 2025-12-29 18:32:46 +01:00
Owner
Copy Link

Originally created by @anubisg1 on GitHub (Aug 28, 2020).

Environment

netbox version 2.8.8 (according to bottom of the page) , python version i have no clue i am an application user not a devops, i do not deploy the app on the server

Proposed Functionality

When physical interfaces belong to a LAG, they should inherit access/trunk detail from the parent lag

right now i can say that parent lag in access and interfaces belonging to that lag are in trunk.

this isn't correct. when an interface is in a lag, details like access/trunk and allowed vlan should only be configurable in the parent lag, and children interfaces should only inherit

Use Case

Any user working with devices. having consistency between devices and documentation without having to verbosely configure every single slave interface, which among the other things is error prone

Database Changes

No clue really

External Dependencies

Likely none, i am not a developer, so i don't really know

Originally created by @anubisg1 on GitHub (Aug 28, 2020). ### Environment netbox version 2.8.8 (according to bottom of the page) , python version i have no clue i am an application user not a devops, i do not deploy the app on the server ### Proposed Functionality When physical interfaces belong to a LAG, they should inherit access/trunk detail from the parent lag right now i can say that parent lag in access and interfaces belonging to that lag are in trunk. this isn't correct. when an interface is in a lag, details like access/trunk and allowed vlan should only be configurable in the parent lag, and children interfaces should only inherit ### Use Case Any user working with devices. having consistency between devices and documentation without having to verbosely configure every single slave interface, which among the other things is error prone ### Database Changes No clue really ### External Dependencies Likely none, i am not a developer, so i don't really know
adam closed this issue 2025-12-29 18:32:47 +01:00
adam commented 2025-12-29 18:32:48 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 28, 2020):

This issue is pending closure as it does not conform to one of the provided templates as required by the contributing guide. If you'd like to request that your issue be re-opened, please first update the content so that it matches the appropriate template (this may require rewriting your issue entirely).

@jeremystretch commented on GitHub (Aug 28, 2020): This issue is pending closure as it does not conform to one of the [provided templates](https://github.com/netbox-community/netbox/issues/new/choose) as required by the [contributing guide](https://github.com/netbox-community/netbox/blob/master/CONTRIBUTING.md). If you'd like to request that your issue be re-opened, please first update the content so that it matches the appropriate template (this may require rewriting your issue entirely).
adam commented 2025-12-29 18:32:48 +01:00
Author
Owner
Copy Link

@anubisg1 commented on GitHub (Aug 28, 2020):

why is it pending closure? the template was provided with all information.. what else is it missing?

@anubisg1 commented on GitHub (Aug 28, 2020): why is it pending closure? the template was provided with all information.. what else is it missing?
adam commented 2025-12-29 18:32:48 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 28, 2020):

It was marked as pending closure because you originally posted only the following:

When physical interfaces belong to a LAG, they should inherit access/trunk detail from the parent lag
right now i can say that parent lag in access and interfaces belonging to that lag are in trunk.
this isn't correct. when an interface is in a lag, details like access/trunk and allowed vlan should only be configurable in the parent lag, and children interfaces should only inherit

@jeremystretch commented on GitHub (Aug 28, 2020): It was marked as pending closure because you originally posted only the following: > When physical interfaces belong to a LAG, they should inherit access/trunk detail from the parent lag > right now i can say that parent lag in access and interfaces belonging to that lag are in trunk. this isn't correct. when an interface is in a lag, details like access/trunk and allowed vlan should only be configurable in the parent lag, and children interfaces should only inherit
adam commented 2025-12-29 18:32:48 +01:00
Author
Owner
Copy Link

@anubisg1 commented on GitHub (Aug 28, 2020):

Yes, that's the first time... But the i changed it as requested, the bot cleared it up but was placed back as pending closure... Regardless, doesn't matter really, let's stay on topic.

I hope the feedback is clear

@anubisg1 commented on GitHub (Aug 28, 2020): Yes, that's the first time... But the i changed it as requested, the bot cleared it up but was placed back as pending closure... Regardless, doesn't matter really, let's stay on topic. I hope the feedback is clear
adam commented 2025-12-29 18:32:48 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 31, 2020):

The proposed behavior relies upon dangerous assumptions concerning the user's intended design, and would introduce a development burden that far outweighs the provided value. Thank you for the suggestion, but I'm going to pass on this.

@jeremystretch commented on GitHub (Aug 31, 2020): The proposed behavior relies upon dangerous assumptions concerning the user's intended design, and would introduce a development burden that far outweighs the provided value. Thank you for the suggestion, but I'm going to pass on this.
adam commented 2025-12-29 18:32:48 +01:00
Author
Owner
Copy Link

@anubisg1 commented on GitHub (Aug 31, 2020):

Thanks for the response.

Can i ask what "assumption" is that we are making? when a creating a LAG, the slave interfaces cannot have different configurations else they won't belong to a LAG...

this is nothing to do with "intended design", this is how the technology works. is like that we don't want to considered tagged/untagged vlans on a dot1q trunk

@anubisg1 commented on GitHub (Aug 31, 2020): Thanks for the response. Can i ask what "assumption" is that we are making? when a creating a LAG, the slave interfaces cannot have different configurations else they won't belong to a LAG... this is nothing to do with "intended design", this is how the technology works. is like that we don't want to considered tagged/untagged vlans on a dot1q trunk
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#4039
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?