In december, I stumbled over a short presentation (in german) on netdot and RANCID by Jens Link (cache)
. I've been a fan of RANCID for a long time, but never had heard of netdot, the Network Documentation Tool (cache)
Turns out netdot does a lot of useful things via SNMP::Info (cache)
, from pulling inventory data to reading out VLAN, IP, ARP and forwarding tables, and then puts all that in a neat web interface for further classification. It's possible to document just about everything around network systems in netdot, down to the cabling setup.
On the logical side, netdot can be used for IP address and VLAN management, and to create configurations files for RANCID, ISC bind and dhcpd, and Nagios.
All in all it seems like a pretty nifty tool, and I've only scratched the surface of it's functionality until now - just having the MAC database (and by that the information where each end system is attached) makes setting up netdot worthwhile.
2. basic setup
My installation is based on netdot 0.9.10 on a Debian Squeeze LAMP system.
Setup is quite straightforward, just follwing the available documentation: Dowload, unpack, run make installdeps-apt-get
to install all missing packages, run make installdeps
to fetch anything that might still be missing from CPAN.
Then copy etc/Default.conf to etc/Site.conf and adapt all settings for your installation, especially those for the database connection. A make installdb
will take care of setting up the DB. (I'm not very fond of the way that's done, as the routine needs database admin credentials and fails if you create a database in advance with a user that just has admin rights on that.)
After that, make install
copies everything to /usr/local/netdot. I've used checkinstall to create a basic debian package:
checkinstall --fstrans=no env APACHEUSER=www-data APACHEGROUP=www-data make install
As a last step, netdot needs to be added to the apache configuration, by copying a template: cp /usr/local/netdot/etc/netdot_apache2_local.conf /etc/apache2/conf.d/
3. installation woes
At this point, everything works in principle, including logging in to the web interface. Unfortunately, that's also where the problems start...
3.1. Can't add any system to the database
updatedevice.html produced the following error:
Device::_get_snmp_session: Cannot connect to <Device>. Tried communities: public
Looking at network traffic with tcpdump, no snmp queries go out at all... After tinkering with SNMP::Info internals for two hours, found the unexpected solution in the netdot bugtracker, bug #1622 (cache)
Two debian packages are missing in the installdeps phase: apt-get install snmp-mibs-downloader smistrip
3.2. Alcatel MIBs missing
netdot contains a collection of MIB files that's probably derived from the netdisco-mibs package
. When trying to add Alcatel OmniSwitch systems on our network, SNMP::Info barfs - it has an AlcatelLucent.pm to handle those systems, but that doesn't work without the MIBs. In the end I found a relatively complete set of OmniSwitch MIBs in the Observium SVN (cache)
(because, you know, those files are so secret that you can't download them from the Alcatel-Lucent web site - I'll be so happy when we're rid of the last of these things).
To make things somewhat more fun, Alcatel provides a customized AaIETF_HUBMIB_POWER_ETHERNET_DRAFT.mib that uses the same module name as the official POWER-ETHERNET-MIB. SNMP::Info::Layer3::AlcatelLucent documentation
advises to change it's module name to ALU-POWER-ETHERNET-MIB by editing the file. Which is fine, except that the corresponding error also comes up when there's another problem (like a dependant mib still missing).
3.3. Juniper EX non-obviously not supported
Adding our Juniper EX 4200 and EX 4500 switches to the database seemed to work fine at first, until it turned out that just the data for the system that was added last is in the database.
I did not have a look at netdot's data model, but obviously the problem was caused by IP addresses used on internal interfaces that are identical on all EX systems (128.0.0.x). Fortunately, Site.conf provides a configuration directive to weed out these pseudo interfaces:
-IFRESERVED => "pimd|vt-|tap|pe-|pd-|dsc|rptr|unrouted",
+# bme,pime,mtun,lsi,jsrv: Juniper
+# internal (interface): Alcatel
+IFRESERVED => "bme|pime|mtun|lsi|jsrv|pimd|vt-|tap|pe-|pd-|dsc|rptr|unrouted|internal",
Next I noticed that the VLAN information gathered from Juniper switches was broken: Instead of the VLAN ID, the database just contained sequence numbers.
Obviously EX switches use a different method to provide VLAN information via SNMP than Juniper routers. Someone has already provided an JuniperEX.pm extension to SNMP::Info
, but it's not integrated into the distribution yet.
I ended up reinstalling a current version of SNMP::Info directly from CPAN, and then just copy the JuniperEX.pm file into /usr/local/share/perl/5.10.1/SNMP/Info/Layer3/ (path on my system) and patch SNMP/Info.pm:
--- Info.pm.orig 2012-01-07 15:10:27.000000000 +0100
+++ Info.pm 2012-01-07 15:13:00.000000000 +0100
@@ -1349,6 +1349,10 @@
$objtype = 'SNMP::Info::Layer2::HPVC'
if ( $desc =~ /HP\sVC\s/ );
+ # Juniper EX switch and SRX routers
+ $objtype = 'SNMP::Info::Layer3::JuniperEX'
+ if $desc =~ /\b(ex00-\w+|srx\d+\w+)\b/;
# Generic device classification based upon sysObjectID
if ( ( $objtype eq 'SNMP::Info::Layer3' )
and ( defined($id) )
...except the netdot MIB package doesn't contain JUNIPER-VLAN-MIB and it's dependencies, but that can be solved easily by downloading a complete collection of Juniper MIBs (cache)
4. unsolved problem
After all that, my netdot installation happily crunches data from about 90 switches in our central location, and I'll most probably add our external sites in the coming weeks.
One last problem remains - SNMP::Info doesn't read inventory information from Juniper EX switches, so I'll have a look at exending the existing JuniperEX.pm. More news when that actually works.
At last, a thanks to the developers - got a detailed description on where to look when I posted my various problems to the netdot-users mailing list.