On Thu, 15 Oct 2009 13:06:20 +0200 "Istvan Bernath" ibe@life.ku.dk wrote:
Topology right now is totally missing, but luckily I've cached a hint of topology with a single 2824 in the middle and one 2626 one 2650 and a 2510 as the neighbors before my colleague, sorry to say, have updated to the latest firmware. The magic surely was, that the 2824 had a complete CDP and LLDP implementation in the old firmware, while all the new HP firmware has only a crippled Receive Only CDP implementation.
The switches' forwarding tables are collected by the getBoksMacs program (nav start mactrace). Do you see any error messages in your getBoksMacs.log file? It might also help to make sure that getBoksMacs is logging at debug level (level 6, see nav.conf).
NAV builds a table of neighbor candidates. It would be nice to know some statistics from this table. Could you access the PostgreSQL database (sudo -u postgres psql nav) and show the output of the following queries:
SELECT COUNT(*) FROM swp_netbox; SELECT COUNT(DISTINCT netboxid) FROM swp_netbox;
Right now we are monitoring DNS, HTTP, IMAP, SMB, SMTP with success. The only service we are missing, for the time beeing, is the RADIUS.
Thinking about it now, I remember discovering a while back that there are some complicated issues surrounding the RADIUS service checker.
I remember discussing this with the original author of the service checker plugin. He also happens to be the Debian maintainer for the python-pyrad package.
The RADIUS service checker uses python-pyrad to talk to a RADIUS server. pyrad is dependent on a RADIUS service dictionary to have any meaningful conversation with a RADIUS server. Unfortunately, a default dictionary isn't provided with the python-pyrad package.
Dictionaries are usually provided by your radius server. I see the freeradius Debian package provides a multitude of dictionary files, linked together by a single one in /etc/freeradius/dictionary .
The location of a dictionary file needs to be specified in the options when setting up the RADIUS service checker. I see the plugin itself documents the following:
Arguments: ---------- hostname : Accessible from self.getAddress() as pure FQDN hostname port : Remote udp-port where radius authentication is living. Port 1812 is default for authentication. username : A valid radius-username password : Clear-text password associated with the username above. identifier: Each "client-source" connects to radius with a given identity and secret. rad_secret: Password associated with 'identifier' dictionary: Path to filename which holds the dictionary for this radius-daemon. The default-dictionary can be used, or a specific dictionary for a specific implementation of the radius-server.
I hope this information will help you to get it working.