On Tue, 17 Nov 2020 15:11:04 +0100 Simon Brown <simon.brown(a)eiscat.se> wrote:
> I'm testing with two device types, an ordinary WLAN access point and a switch.
>
> https://www.zyxel.com/products_services/802-11ac-Dual-Radio-Dual-optimized-…
NAV does not have any specific support for WLAN access points, so there is
no pre-existing framework to model that type of information in today's
data model.
Normally, an AP will expose information about its ethernet ports using
the standardised IF-MIB, which includes traffic counters and status of
these ports. These might be its uplink port(s) and its "virtual" WLAN
ports.
> https://sevensols.es/index.php/index/timing-products/white-rabbit-switch/
>
> Regarding basic information, I'm not really sure what to expect as I'm not
> that good yet at parsing MIB files. I don't know what is generic standard info
> and what is device specific. As a first step for the switch I see nothing in
> the Ports tab "No ports found" I was hoping for someway to setup VLANs.
>
> The MIB file for the switch is here:
> https://ohwr.org/project/wr-switch-sw/blob/
> 4df35933f51680e7497cb2b5b183905b374ed28e/userspace/snmpd/WR-SWITCH-MIB.txt
>
> And it looks like individual port status is exposed, version information,
> temperatures and a host of other things. I don't know yet how much of this
> will be useful so I would like to make as much of it available as possible.
> What is basic from your point of view?
To be blunt: I am asking "What do _you_ expect NAV to tell you about
these devices that it isn't already telling you?"
If you have a network device, it will have the concept of network
interfaces, whether they be physical or virtual. I expect to at least be
able to see these interfaces listed in NAV - and there is only one
definitive MIB to provide this information: IF-MIB (RFC 2863).
If you have an SNMP-enabled networking device and it does not support
this MIB, it is useless for most network monitoring tools (maybe the
vendor sells their own NMS and want to make money off of that?).
Personally, I have never come across such a device before.
The MIB you pointed to seems to provide some proprietary information
about ports, with an information model that seems to differ considerably
from IF-MIB. I'm sure you can author support for this proprietary MIB
and make some things work, but NAV's model for interfaces follows IF-MIB
pretty closely, and I'm not sure how the concepts of WR-SWITCH-MIB will
map into those.
These are the necessary steps I foresee:
1. Dump WR-SWITCH-MIB to a Python dictionary representation.
2. Write a MibRetriever to implement the abstractions necessary to fetch
and make sense of the data in the MIB. As an example, here is the
corresponding MibRetriever for the IF-MIB: [1].
These two steps more or less overlap with start of the howto for writing
support for sensor equipment [2].
3. Write something that corresponds to the ipdevpoll interfaces plugin
[3], which will use the abstractions provided by your MibRetriever
implementation to fetch data from the device and map that data into
NAV's interface model.
Worst-case scenario: You may want to store attributes that aren't part
of NAV's standard interface model. Then you will need to propose changes
to the generic model used by everyone, and that will take much longer to
design and approve.
NB:
I suggest moving this entire discussion to the nav-dev mailing list,
rather than bother everyone on the users list with the low-level
details. Cc: to nav-dev(a)uninett.no.
[1] https://github.com/Uninett/nav/blob/master/python/nav/mibs/if_mib.py
[2] https://nav.uninett.no/doc/5.0/hacking/adding-environment-probe-support.html
[3] https://github.com/Uninett/nav/blob/master/python/nav/ipdevpoll/plugins/int…
--
Best regards,
Morten Brekkevold
Senior systems developer
Uninett
