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

Support Multi-Chassis LAG Interfaces #3802

New Issue
Closed
opened 2025-12-29 18:31:17 +01:00 by adam · 3 comments
adam commented 2025-12-29 18:31:17 +01:00
Owner
Copy Link

Originally created by @aleheux-tc on GitHub (Jun 23, 2020).

Proposed Functionality

LAG Interfaces should be able to connect to LAG interfaces on multiple devices.

Use Case

There is a variety of MC-LAG type functionality across many platforms that is widely used, EVPN is one, regular MC-LAG another.

This feature was requested before:
https://github.com/netbox-community/netbox/issues/3033
https://github.com/netbox-community/netbox/issues/2830

EVPN is a standard and definitely relevant. I argue that the fact that regular MC-LAG implementations are proprietary is irrelevant as on the front end they all look the same and they interoperate between vendors just fine. That each vendor implements it their own way in the forwarding and control plane is irrelevant. The same could actually be said of regular LAG: Every vendor implements that their own way too.

If Netbox wants to be able to model network devices and how they're connected, which it clearly is, this is definitely in scope as all the various ways there are to connect one logical LAG port to multiple others are widely used.

If Netbox implements this 1-N (or even N-M) functionality in a generic way, it could also be extremely useful for things like DWDM, 10G breakout, etc.

Database Changes

External Dependencies

Originally created by @aleheux-tc on GitHub (Jun 23, 2020). ### Proposed Functionality LAG Interfaces should be able to connect to LAG interfaces on multiple devices. ### Use Case There is a variety of MC-LAG type functionality across many platforms that is widely used, EVPN is one, regular MC-LAG another. This feature was requested before: https://github.com/netbox-community/netbox/issues/3033 https://github.com/netbox-community/netbox/issues/2830 EVPN is a standard and definitely relevant. I argue that the fact that regular MC-LAG implementations are proprietary is irrelevant as on the front end they all look the same and they interoperate between vendors just fine. That each vendor implements it their own way in the forwarding and control plane is irrelevant. The same could actually be said of regular LAG: Every vendor implements that their own way too. If Netbox wants to be able to model network devices and how they're connected, which it clearly is, this is definitely in scope as all the various ways there are to connect one logical LAG port to multiple others are widely used. If Netbox implements this 1-N (or even N-M) functionality in a generic way, it could also be extremely useful for things like DWDM, 10G breakout, etc. ### Database Changes ### External Dependencies
adam added the status: duplicate label 2025-12-29 18:31:17 +01:00
adam closed this issue 2025-12-29 18:31:17 +01:00
adam commented 2025-12-29 18:31:17 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 23, 2020):

This was already addressed under #2830. Please don't open duplicate issues. This functionality is not something we're exploring at this time.

@jeremystretch commented on GitHub (Jun 23, 2020): This was already addressed under #2830. Please don't open duplicate issues. This functionality is not something we're exploring at this time.
adam commented 2025-12-29 18:31:17 +01:00
Author
Owner
Copy Link

@aleheux-tc commented on GitHub (Jun 23, 2020):

You have not addressed anything I've said and neither does #2380.

If this project is just not interested in feedback from and/or participation by its users, perhaps this can be clearly stated somewhere so everyone knows to pass it by.

@aleheux-tc commented on GitHub (Jun 23, 2020): You have not addressed anything I've said and neither does #2380. If this project is just not interested in feedback from and/or participation by its users, perhaps this can be clearly stated somewhere so everyone knows to pass it by.
adam commented 2025-12-29 18:31:17 +01:00
Author
Owner
Copy Link

@steffann commented on GitHub (Jun 23, 2020):

It's not that this is a bad idea, but there are other things on the roadmap at the moment that require the focus of the maintainers for the foreseeable future. There is technical debt to be paid off before support for new concepts like EVPN and MC-LAG can be introduced.

So thank you for bringing this up. It is definitely something that occurs in real life, and it would be nice to support modelling it in NetBox. Once the maintainers have more brain cycles available this can be reconsidered.

Help with resolving the open issues and reducing the technical debt is appreciated. The sooner that is done, the sooner new features can be considered!

@steffann commented on GitHub (Jun 23, 2020): It's not that this is a bad idea, but there are other things on the roadmap at the moment that require the focus of the maintainers for the foreseeable future. There is technical debt to be paid off before support for new concepts like EVPN and MC-LAG can be introduced. So thank you for bringing this up. It is definitely something that occurs in real life, and it would be nice to support modelling it in NetBox. Once the maintainers have more brain cycles available this can be reconsidered. Help with resolving the open issues and reducing the technical debt is appreciated. The sooner that is done, the sooner new features can be considered!
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 status: duplicate
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#3802
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?