On Mon, 14 Mar 2005, Kristian Eide wrote:

...

In my opinion main NAV problem is, that it is not flexible, there is no interface for adding custom devices. I was writing about this, but there is no feedback.

We consider this issue very important. I am sorry you (Woj) received no feedback on your initial posting.

In fact, NAV is meant to be very flexible! New OIDs can be added via the web interface, and NAV will automatically detect which devices support the new OIDs.

Data collection is done by the 'getDeviceData' daemon, which uses a plugin-based architecture. The API for this is resonably well documented in Javadoc, however, it is a fact that familiarity with Java programming is required in order to create new collection plugins. Unfortunately it also seems many system administrators are much more familiar with script languages and the barrier to entry is thus high.

We should also supply a Device Compatibility Matrix equivalent to the netdisco version (http://snmp-info.sourceforge.net/DeviceMatrix.html)

An idea is to adopt a similar/elaborated classification, introduce a wiki page at metanav and have the nav community participate in testing and doumentation. This will be of great value to the community, it will be easy for new users to see what we support, easy for us to see where the current problems are, etc.

Creating a perl binding which focused on easy of development would solve this problem, but it is of now uncertain if resources are available to implement something like this. We will discuss it internally and announce any decision this list.

We should give this serious thought. We definitely need a mechansim which invites contributions from the community.

I will internally (ntnu/uninett) suggest an intense equipment test program where we test variuos new equipment in a structured manner. In the process we should look at improving logging and in the end provide a cookbook / check list for how to test a new switch/router in NAV. A device can be supported in NAV on different levels:

1: basis: only status monitoring of the device. no information on ports (l2 or l3 ports) 2: information on ports but no vlan information. This also includes cricket/rrd statistics 3: physical topology detected. machine tracker capable 4: full topology: vlan information (trunk and none trunk ports)

Variuos log files / web pages should be checked in the process from initial seeding in edit database untill you reach level 4. Worst- and bestcase timeframe should also be dedumentet

- Vidar