On Wed, 9 Jul 2014 10:34:49 -0300 Bruno Galindro da Costa bruno.galindro@gmail.com wrote:
See attached files.
There may be another fault lurking in here:
2014-07-09 08:05:27,217 [DEBUG jobs.jobhandler] [topo x.x.251.245] Now calling plugin: nav.ipdevpoll.plugins.lldp.LLDP(u'x.x.251.245') 2014-07-09 08:05:27,234 [DEBUG timestamps.timestampchecker] [topo x.x.251.245] 'lldp': timestamps appear unchanged since last run
As I wrote in another post, NAV will not do LLDP processing on this device until the timestamp of the lldpRemTable changes. If the LLDP neighbors were unidentifiable on the first run, but have become identifiable at a later time, this will not be rectified by NAV until this device changes this timestamp and causes NAV to process it again.
If you search for the MAC addreses using the Machine Tracker and interface reports, as I asked, and found the MAC addresses to be identifiable, you may be able to kickstart a new processing of the LLDP information by deleting NAV's stored timestamps.
Something like this would do it:
sudo -u postgres psql nav \ -c "DELETE FROM netboxinfo WHERE key='poll_times' AND var='lldp'"
It may be a better strategy for NAV here to invalidate these timestamps on set intervals to force reprocessing of the LLDP information; just not on every run of the LLDP collector.