Closed candlerb closed 1 year ago
Blocked by #9102
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.
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.
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).
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.
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
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.
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.
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:
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
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