On Wed, 2 Nov 2022 17:23:17 +0000 Davide Miccone davide@wpweb.com wrote:
Seems that NAV (versione 5.4.0) does not full support switch Cisco Business 350-8T-E-2G.
I get some box infos but - for example - port VLANs are not correctly get.
I have no experience with Cisco Small Business switches, but I did a quick Google search and found a data sheet for the 350 series:
https://www.cisco.com/c/en/us/products/collateral/switches/business-350-seri...
NAV solely uses Cisco-proprietary methods to get VLAN configuration information (as Cisco has never supported the standardized Q-BRIDGE-MIB for this). However, from this data sheet, it looks like the 350 series does not use any of the usual proprietary Cisco MIBS (usually prefixed by `CISCO-`), but instead employs a full set of alternative proprietary MIBs specific to the "Small Business" series of devices (prefixed `CISCOSB-`). These MIBs are not supported by NAV.
I do see, however, that the data sheet includes Q-BRIDGE-MIB in its MIB list. If that is indeed true, NAV should be able to get the VLAN configuration information and forwarding tables. If you're not getting the native or tagged VLANs correctly collected from these switches, it stands to reason that they might still not support it properly - or, it could be that NAV eschews collecting from the standard MIBs because it sees it's a Cisco device.
LLDP data and neighbors are not correctly get.
That is just strange - the data sheet does claim compliance with LLDP-MIB.
If you would enable some debug logging in ipdevpoll and sharing some of those logs, we might be able to figure out what is happening here.
I would suggest adding these entries to the `[levels]` section of `/etc/nav/logging.conf`:
nav.ipdevpoll.plugins = DEBUG nav.mibs = DEBUG
Then you could manually re-run an inventory job for one affected switch and collect the logs from stdout:
ipdevpolld -J inventory -n <name-of-affected-switch>
(afterwards, you should consider commenting out the new entries from `logging.conf`, or your ipdevpoll.log might fill up very fast after the ipdevpoll daemon is restarted the next time)