Nav - LLDP Missing on some FS model
Hello, First of all thanks for your job, we really appreciate nav solution. We noticed that some of our FS.COM switch, (we got, cisco, hp, dlink, fs) does not work as expected. Nav doesn't get LLDP information, and for this it is wrongly populating the net map. The FS model working properly are s3900, s5850; But not so lucky with s2800, s1400, s3400 . It's possible to force nav to choose a neighbor from cam candidate? Or set it manually? Or is it possible to make these switch works with nav? Maybe passing mib somehow? Many Thanks in advance Best Regards [cid:image001.png@01D8D356.6C245C00] Marco V. Bifolco System Engineer Office (+39) 0694320122 | Mobile (+39) 3519666252 marco.bifolco@sferanet.net<mailto:marco.bifolco@sferanet.net> assistenza@sferanet.net<mailto:assistenza@sferanet.net> [cid:image002.png@01D8D356.6C245C00] sferanet.net<http://www.sferanet.net/>
On Wed, 28 Sep 2022 14:25:29 +0000 Marco Valerio Bifolco <marco.bifolco@sferanet.net> wrote:
First of all thanks for your job, we really appreciate nav solution.
Thank you for using it :)
We noticed that some of our FS.COM switch, (we got, cisco, hp, dlink, fs) does not work as expected. Nav doesn’t get LLDP information, and for this it is wrongly populating the net map.
I assume the switches *do* support LLDP, then. You need to confirm whether the switches support the LLDP-MIB, as specified in IEEE Std 802.1AB-2005. This is currently the only API NAV supports for getting LLDP information from a device.
The FS model working properly are s3900, s5850; But not so lucky with s2800, s1400, s3400 .
I have no experience with FS.COM equipment, so I cannot really comment as to why that seems to be the case.
It's possible to force nav to choose a neighbor from cam candidate? Or set it manually?
Not really, although that could be a viable feature request. NAV will trust LLDP or CDP over CAM information - but relying on CAM information isn't foolproof, since a MAC address will be "visible" on many switch ports. An algorithmic reduction of the possible candidates per port must take place over the entirety of the collected layer 2 information. If the collected information isn't complete, there will sometimes be incorrect neighbor guesses.
Or is it possible to make these switch works with nav? Maybe passing mib somehow?
Again, you need to verify which MIBs are supported by the FS devices. -- Sincerely, Morten Brekkevold Sikt – Norwegian Agency for Shared Services in Education and Research
Is there a side channel for NAV users to discuss non-NAV stuff? I'm curious to hear actual experienced with FS switches... Corey Thompson Technology Manager East Grand Forks Water and Light 1010 5th Ave NE East Grand Forks, MN 56721 218-399-3310 cthompson@egf.mn [cid:c764e4a2-02ee-4da1-a7a5-58b6e6f828f4] ________________________________ From: Morten Brekkevold <morten.brekkevold@sikt.no> Sent: Thursday, September 29, 2022 8:51 To: Marco Valerio Bifolco <marco.bifolco@sferanet.net> Cc: nav-users@lister.sikt.no <nav-users@lister.sikt.no>; Isaia Mammano <isaia.mammano@sferanet.net> Subject: [EXTERNAL][Nav-users] Re: Nav - LLDP Missing on some FS model WARNING - this email is originated from outside the City of East Grand Forks email system. Do not click any link and do not open attachments unless you can confirm the sender. On Wed, 28 Sep 2022 14:25:29 +0000 Marco Valerio Bifolco <marco.bifolco@sferanet.net> wrote:
First of all thanks for your job, we really appreciate nav solution.
Thank you for using it :)
We noticed that some of our FS.COM switch, (we got, cisco, hp, dlink, fs) does not work as expected. Nav doesn’t get LLDP information, and for this it is wrongly populating the net map.
I assume the switches *do* support LLDP, then. You need to confirm whether the switches support the LLDP-MIB, as specified in IEEE Std 802.1AB-2005. This is currently the only API NAV supports for getting LLDP information from a device.
The FS model working properly are s3900, s5850; But not so lucky with s2800, s1400, s3400 .
I have no experience with FS.COM equipment, so I cannot really comment as to why that seems to be the case.
It's possible to force nav to choose a neighbor from cam candidate? Or set it manually?
Not really, although that could be a viable feature request. NAV will trust LLDP or CDP over CAM information - but relying on CAM information isn't foolproof, since a MAC address will be "visible" on many switch ports. An algorithmic reduction of the possible candidates per port must take place over the entirety of the collected layer 2 information. If the collected information isn't complete, there will sometimes be incorrect neighbor guesses.
Or is it possible to make these switch works with nav? Maybe passing mib somehow?
Again, you need to verify which MIBs are supported by the FS devices. -- Sincerely, Morten Brekkevold Sikt – Norwegian Agency for Shared Services in Education and Research _______________________________________________ Nav-users mailing list -- nav-users@lister.sikt.no To unsubscribe send an email to nav-users-leave@lister.sikt.no
On Thu, 29 Sep 2022 14:00:36 +0000 Corey Thompson <cthompson@ci.east-grand-forks.mn.us> wrote:
Is there a side channel for NAV users to discuss non-NAV stuff? I'm curious to hear actual experienced with FS switches...
Not specifically, no. We recently enabled the new Discussions feature on our GitHub repository - this could potentially be used for this purpose. However, I'm not sure many NAV users are actually monitoring the discussion boards at this time. https://github.com/Uninett/nav/discussions Or, maybe someone has a better suggestion? -- Sincerely, Morten Brekkevold Sikt – Norwegian Agency for Shared Services in Education and Research
Hi, Thanks for your support, I can't really say if that model as lldp-mib (I'll ask the vendor) . But now I got an other issue, s3900 model that I'm sure is working due 6 of them with same firmware are working fine, seems to be isolated, but looking on candidate it has 2 lldp neighbour that it is not using . [cid:image001.png@01D8D8D6.D4F31110] [cid:image002.png@01D8D8D7.341A80B0] [cid:image003.png@01D8D8D7.341A80B0] [cid:image004.png@01D8D8D7.341A80B0] I don’t know why this is happening, as you can see in this case nav in able to retrieve lldp info, but not using them. So if it’s not possible to solve it, I would suggest to add the possibility on candidate neighbours a button “choose this as elected neighbor” or something like . Many thanks again Marco V. Bifolco System Engineer Office (+39) 0694320122 | Mobile (+39) 3519666252 marco.bifolco@sferanet.net assistenza@sferanet.net sferanet.net -----Messaggio originale----- Da: Morten Brekkevold <morten.brekkevold@sikt.no> Inviato: giovedì 29 settembre 2022 15:51 A: Marco Valerio Bifolco <marco.bifolco@sferanet.net> Cc: nav-users@lister.sikt.no; Isaia Mammano <isaia.mammano@sferanet.net> Oggetto: Re: [Nav-users] Nav - LLDP Missing on some FS model On Wed, 28 Sep 2022 14:25:29 +0000 Marco Valerio Bifolco <marco.bifolco@sferanet.net<mailto:marco.bifolco@sferanet.net>> wrote:
First of all thanks for your job, we really appreciate nav solution.
Thank you for using it :)
We noticed that some of our FS.COM switch, (we got, cisco, hp, dlink,
fs) does not work as expected. Nav doesn’t get LLDP information, and
for this it is wrongly populating the net map.
I assume the switches *do* support LLDP, then. You need to confirm whether the switches support the LLDP-MIB, as specified in IEEE Std 802.1AB-2005. This is currently the only API NAV supports for getting LLDP information from a device.
The FS model working properly are s3900, s5850; But not so lucky with
s2800, s1400, s3400 .
I have no experience with FS.COM equipment, so I cannot really comment as to why that seems to be the case.
It's possible to force nav to choose a neighbor from cam candidate? Or
set it manually?
Not really, although that could be a viable feature request. NAV will trust LLDP or CDP over CAM information - but relying on CAM information isn't foolproof, since a MAC address will be "visible" on many switch ports. An algorithmic reduction of the possible candidates per port must take place over the entirety of the collected layer 2 information. If the collected information isn't complete, there will sometimes be incorrect neighbor guesses.
Or is it possible to make these switch works with nav? Maybe passing
mib somehow?
Again, you need to verify which MIBs are supported by the FS devices. -- Sincerely, Morten Brekkevold Sikt – Norwegian Agency for Shared Services in Education and Research
On Wed, 5 Oct 2022 14:29:45 +0000 Marco Valerio Bifolco <marco.bifolco@sferanet.net> wrote:
But now I got an other issue, s3900 model that I'm sure is working due 6 of them with same firmware are working fine, seems to be isolated, but looking on candidate it has 2 lldp neighbour that it is not using
The exact reason NAV isn't using it is because there are *2* instead of *1*. NAV's topology model will only allow a single neighbor on any port - and this port reports *2* neighbors. How can `Trunk1` have *2* neighbors? Is a virtual MLAG port? -- Sincerely, Morten Brekkevold Sikt – Norwegian Agency for Shared Services in Education and Research
HI, 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. Any advice will be appreciated. Thanks Best Regards Marco V. Bifolco System Engineer Office (+39) 0694320122 | Mobile (+39) 3519666252 marco.bifolco@sferanet.net assistenza@sferanet.net sferanet.net -----Messaggio originale----- Da: Morten Brekkevold <morten.brekkevold@sikt.no> Inviato: venerdì 21 ottobre 2022 13:29 A: Marco Valerio Bifolco <marco.bifolco@sferanet.net> Cc: nav-users@lister.sikt.no; Isaia Mammano <isaia.mammano@sferanet.net> Oggetto: Re: R: [Nav-users] Nav - LLDP Missing on some FS model On Wed, 5 Oct 2022 14:29:45 +0000 Marco Valerio Bifolco <marco.bifolco@sferanet.net> wrote:
But now I got an other issue, s3900 model that I'm sure is working due 6 of them with same firmware are working fine, seems to be isolated, but looking on candidate it has 2 lldp neighbour that it is not using
The exact reason NAV isn't using it is because there are *2* instead of *1*. NAV's topology model will only allow a single neighbor on any port - and this port reports *2* neighbors. How can `Trunk1` have *2* neighbors? Is a virtual MLAG port? -- Sincerely, Morten Brekkevold Sikt – Norwegian Agency for Shared Services in Education and Research
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&temp... 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. -- Sincerely, Morten Brekkevold Sikt – Norwegian Agency for Shared Services in Education and Research
participants (3)
-
Corey Thompson -
Marco Valerio Bifolco -
Morten Brekkevold