On Tue, 25 Oct 2022 09:47:07 +0000 Marco Valerio Bifolco marco.bifolco@sferanet.net wrote:
Again thanks for your time, yes it is a mlag configuration, but the strange thing, it's that is not the only one, but is the unique having this problem.
So, I guess again my only chance is the feature to choose the right neighbor.
NAV's low-level topology model cares about the physical interconnections. This problem arises when a device vendor reports LLDP records on the virtual aggregate port instead of the individual physical ports that make up the aggregate.
If the device doesn't report LLDP data on the level of the physical ports, there is really no way for NAV to automatically select one of the records as the "correct" one for the aggregate port. Also, I would say it is incorrect to select a *single* neighbor for the aggregate port, since it principally has two neighbors.
What about the LLDP records on the neighboring devices, which ports do these indicate they are connected to? If these have the information about the actual physical ports, NAV's topology detector could be made able to discern what's really going on there.
Any advice will be appreciated.
I would start here: https://github.com/Uninett/nav/issues/new?assignees=&labels=enhancement&...
Also, verifying and documenting what LLDP data is available on each end could potentially make us able to improve the topology detector in these scenarios.