Hello netdisco developers,
 
At our university we used to be a Cisco-only environment, but now also Juniper Routers ans switches are employed.
So a vendor independent device-tracking tool became a necessity.
Since about 7 years now I developed a pretty sophisticated device-tracking tool based on our physical layer management-tool iTracs,
on Cisco LMS, NCS (for wireless), HPCA (former Radia), Microsoft SCCM ans some more other datasources to be able to
physically locate all ICT-assets (nodes in netdisco-speak) and show it on floor-plans (about 700 in 85 buildings). It daily tracks all moves and changes of all wired devices and every hour it updates also all locations of wireless devices and can show it on maps including many device and connection details.
I am now trying to make use of netdisco to deliver the network-data as one of the datasources of this application to be able to also include the Juniper switches in this discovery-process.
The possibility of ODBC-access to the netdisco-data using the PostgreSQL database to be able to efficiently collect periodically
the allocation of the 'nodes' on the network is still a very promising one.
The ODBC-access to the network-data in netdisco has proved to be very efficient.
It takes some nifty nested queries to accomplish this, but up to now I am very content how fast this works.
There are however some issues that had to be worked around. Only a few features are missing to make the move from LMS to netdisco complete and painless.
 
In the developer-info I read that in the latest prototype 2-release the dns-name is added to the node_ip table and that the dns-resolution will be done in parallel during the arp-nip process.
This would be a very important improvement for us because dns-names are not yet in the netdisco-database.
I am curious when this release becomes available for use.
I think it also could improve the performance of listing switchports within netdisco, because I suppose this now is done by realtime DSN-queries or another less efficient datasource. Retrieving DNS-names on bigger switches within the netdisco user-interface is quite slow now compared to other user-actions.
 
For Juniper switches the voice-vlans for our Avaya phones are now detectable at port-level (used or unused) in the database, but not yet for the Cisco devices.
Only for the active nodes this is detectable also for the Cisco switches. Cisco LMS has the same problem however.
The same is true for the dot1x and portsecurity properties of the switch-ports. I got the impression that at least for these security-properties a standardized MIB is available on Juniper and other vendors.
It would be a great help to be able to see these parameters in netdisco to see the security properties of all ports.
Only some ports (5%) have dot1x-security in our network, so if that's visible for our distributed IT-staff it would be very useful.
Up to now we only can extract this info from cisco configuration-files to be able to show it in our application(s).
 
Another practical issue when using the PostgreSQL odbc interface are the many text type columns used.
They can be filled theoretically with 1Gb of text-data including a lot of columns used with indexes and even primairy keys.
This is a powerful feature of PostgreSQL, but for ODBC-clients like MS-Access it will restrict the use of indexes and base-table connections to snapshot type query's/views of the netdisco-data for tables containing text-fields in stead of varchars with a more limited size. Only varchar fields with up to 255 characters will be presented as normal text-fields in MS-Access. Below 126 characters the size and performance even could be a littlebit better still within PostgreSQL. Above 255 characters all textfields or varchars will become memo-type fields in MS-Access with more restrictions on use and less efficient handling.
May be I am the first user/developer using this interface on netdisco, but if only text fields that really need it could be made bigger than 126 or 255 characters it could improve the usability and performance of this odbc-interface still quite a lot.
 
I also have read that special SQL-view techniques are used within the perl-environment. I already did some attempts to define probably similar views myself (within MS-Access, not PostgreSQL) to be able to extract useful data from the netdisco-tables, but I could imagine that when the most important views are made using PostgreSQL-views it could result into to even more efficient data-access for netdisco itself and also for applications using the odbc-interface.
 
All in all I'm impressed by the quality and vendor-independent applicability of netdisco. For me the netdisco database still remains a very usable datasource, but it will take me quite some workarounds and the use of additional datasources to migrate our data-feeds from Cisco LMS to netdisco.
I think that just a few improvements without many implications for the design of netdisco could make it a much cleaner and easier to support solution for us.
 
Best regards,
 
Marc Hovens Greve
Informatiseringscentrum UvA
systeembeheer telefonie
tel 020-5252387
fax 020-5252084