Connected endpoints for LAGs

[candlerb]

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

[jeremystretch]

Blocked by #9102

[jeremystretch]

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.

[candlerb]

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.

[jeremystretch]

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

[DanSheps]

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.

[jcralbino]

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

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