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

Connected endpoints for LAGs #6500

New Issue
Closed
opened 2025-12-29 19:41:35 +01:00 by adam · 8 comments
adam commented 2025-12-29 19:41:35 +01:00
Owner
Copy Link

Originally created by @candlerb on GitHub (May 20, 2022).

NetBox version

v3.2.3

Feature type

Change to existing functionality

Proposed functionality

(I don't know if this has been proposed before)

It would be helpful for a LAG interface to record what its corresponding partner LAG interface is at the other end device.

That is:

  • If device A has LAG interface AL1 with member ports AP1, AP2, ...
  • And any combination of those ports are connected to ports BP1, BP2, ...
  • And ports BP1, BP2, ... are all members of the same LAG interface BL1 on device B
  • Then AL1 should see BL1 as its "connected neighbor", and vice versa

In the event of any inconsistency, like two links going to two different LAGs or to non-LAG interfaces, then I'd suggest leaving the neighbor as null.

Use case

  • Suppose I have an interface Lag1 with subinterfaces Lag1.100 and Lag1.200
  • On the the remote device I have interface Lag2 with subinterfaces Lag2.100 and Lag2.200
  • It would be easier to determine that there is a path from Lag1.100 to Lag2.100, if there is already a neighbor association between Lag1 and Lag2.

Currently I have to evaluate:
Lag1.100 -> Lag1 => list of member interfaces => list of remote connected interfaces => check if these are all the members of the same Lag => Lag2 -> Lag2.100

This would become:
Lag1.100 -> Lag1 -> Lag2 -> Lag2.100
which is the same as I'd have to do for subinterfaces on two directly connected non-LAG interfaces.

Database changes

None: dcim_interface already has _link_peer_id and _link_peer_type_id.

However the logic to maintain the invariants may be tricky: whenever a cable is added or deleted that affects an interface that's a member of a LAG, or the LAG to which an interface is assigned is changed or removed, the connections may need to be re-evaluated.

External dependencies

None

Originally created by @candlerb on GitHub (May 20, 2022). ### NetBox version v3.2.3 ### Feature type Change to existing functionality ### Proposed functionality (I don't know if this has been proposed before) It would be helpful for a LAG interface to record what its corresponding partner LAG interface is at the other end device. That is: * If device A has LAG interface AL1 with member ports AP1, AP2, ... * And any combination of those ports are connected to ports BP1, BP2, ... * And ports BP1, BP2, ... are all members of the same LAG interface BL1 on device B * Then AL1 should see BL1 as its "connected neighbor", and vice versa In the event of any inconsistency, like two links going to two different LAGs or to non-LAG interfaces, then I'd suggest leaving the neighbor as null. ### Use case * Suppose I have an interface Lag1 with subinterfaces Lag1.100 and Lag1.200 * On the the remote device I have interface Lag2 with subinterfaces Lag2.100 and Lag2.200 * It would be easier to determine that there is a path from Lag1.100 to Lag2.100, if there is already a neighbor association between Lag1 and Lag2. Currently I have to evaluate: Lag1.100 -> Lag1 => list of member interfaces => list of remote connected interfaces => check if these are all the members of the same Lag => Lag2 -> Lag2.100 This would become: Lag1.100 -> Lag1 -> Lag2 -> Lag2.100 which is the same as I'd have to do for subinterfaces on two directly connected non-LAG interfaces. ### Database changes None: dcim_interface already has `_link_peer_id` and `_link_peer_type_id`. However the logic to maintain the invariants may be tricky: whenever a cable is added or deleted that affects an interface that's a member of a LAG, or the LAG to which an interface is assigned is changed or removed, the connections may need to be re-evaluated. ### External dependencies None
adam added the type: featurepending closurestatus: under review labels 2025-12-29 19:41:35 +01:00
adam closed this issue 2025-12-29 19:41:36 +01:00
adam commented 2025-12-29 19:41:36 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 24, 2022):

Blocked by #9102

@jeremystretch commented on GitHub (May 24, 2022): Blocked by #9102
adam commented 2025-12-29 19:41:37 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 26, 2022):

It would be helpful for a LAG interface to record what its corresponding partner LAG interface is at the other end device.

There is no concept of a connection between LAG interfaces. In fact, multichassis LAG allows that a LAG interface on switch can have multiple corresponding interfaces on other devices.

Currently I have to evaluate:
Lag1.100 -> Lag1 => list of member interfaces => list of remote connected interfaces => check if these are all the members of the same Lag => Lag2 -> Lag2.100

Yes, and this validation would still be required if the relationship were added. What is the actual use case for this proposal? There's probably an easier way to achieve what you're trying to do.

@jeremystretch commented on GitHub (Aug 26, 2022): > It would be helpful for a LAG interface to record what its corresponding partner LAG interface is at the other end device. There is no concept of a connection between LAG interfaces. In fact, multichassis LAG allows that a LAG interface on switch can have multiple corresponding interfaces on other devices. > Currently I have to evaluate: > Lag1.100 -> Lag1 => list of member interfaces => list of remote connected interfaces => check if these are all the members of the same Lag => Lag2 -> Lag2.100 Yes, and this validation would still be required if the relationship were added. What is the actual use case for this proposal? There's probably an easier way to achieve what you're trying to do.
adam commented 2025-12-29 19:41:37 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Aug 26, 2022):

There is no concept of a connection between LAG interfaces. In fact, multichassis LAG allows that a LAG interface on switch can have multiple corresponding interfaces on other devices.

By 'multichassis' do you mean Netbox's Virtual Chassis? If so, then there's a single "LAG" virtual interface at each end - even if the member links are spread across multiple devices within a virtual chassis. And those LAG interfaces are point-to-point peers.

What is the actual use case for this proposal?

So: I'm tracing the network to prepare a service. At device A, I know for business reasons that the outbound connection is on Ether-Bundle1.1000. From looking at Netbox topology data, I want to know that the far end is device B and the interface there is Ether-Bundle5.1000. I need that because I want to create a pseudowire from B's Ether-Bundle5.1000 to device C.

@candlerb commented on GitHub (Aug 26, 2022): > There is no concept of a connection between LAG interfaces. In fact, multichassis LAG allows that a LAG interface on switch can have multiple corresponding interfaces on other devices. By 'multichassis' do you mean Netbox's Virtual Chassis? If so, then there's a single "LAG" virtual interface at each end - even if the member links are spread across multiple devices within a virtual chassis. And those LAG interfaces are point-to-point peers. > What is the actual use case for this proposal? So: I'm tracing the network to prepare a service. At device A, I know for business reasons that the outbound connection is on Ether-Bundle1.1000. From looking at Netbox topology data, I want to know that the far end is device B and the interface there is Ether-Bundle5.1000. I need that because I want to create a pseudowire from B's Ether-Bundle5.1000 to device C.
adam commented 2025-12-29 19:41:37 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 26, 2022):

By 'multichassis' do you mean Netbox's Virtual Chassis?

No, the inverse. Juniper's MC-LAG is one example; other vendors have different names for it (of course).

@jeremystretch commented on GitHub (Aug 26, 2022): > By 'multichassis' do you mean Netbox's Virtual Chassis? No, the inverse. [Juniper's MC-LAG](https://www.juniper.net/documentation/us/en/software/junos/mc-lag/topics/topic-map/examples-mc-lag.html) is one example; other vendors have different names for it (of course).
adam commented 2025-12-29 19:41:37 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Aug 26, 2022):

VPC is the Cisco name in the Nexus world. VSS is the name in Cisco Catalyst world (although Virtual Chassis works better for VSS use cases).

That said, it might be a good idea to show the link peers for lags if we don't. It will lead to inconsistent results though in a multi-chassis lag world.

@DanSheps commented on GitHub (Aug 26, 2022): VPC is the Cisco name in the Nexus world. VSS is the name in Cisco Catalyst world (although Virtual Chassis works better for VSS use cases). That said, it might be a good idea to show the link peers for lags if we don't. It will lead to inconsistent results though in a multi-chassis lag world.
adam commented 2025-12-29 19:41:37 +01:00
Author
Owner
Copy Link

@jcralbino commented on GitHub (Oct 7, 2022):

I think that before addressing the remote side of the lag, we should tackle first the switch side of lag.
Considering that more and more vendors/devices are using MultichassisLAG ( vPC like) not being able to capture this information correctly will break this remote lag functionality.

Eventually having a solution for a model for MLAG will fix the issue of the remote side as this can even be show in the netbox cable path visualisation

@jcralbino commented on GitHub (Oct 7, 2022): I think that before addressing the remote side of the lag, we should tackle first the switch side of lag. Considering that more and more vendors/devices are using MultichassisLAG ( vPC like) not being able to capture this information correctly will break this remote lag functionality. Eventually having a solution for a model for MLAG will fix the issue of the remote side as this can even be show in the netbox cable path visualisation
adam commented 2025-12-29 19:41:38 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Dec 7, 2022):

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 (Dec 7, 2022): 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 19:41:38 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jan 6, 2023):

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 (Jan 6, 2023): 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 status: under review 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#6500
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?