Good news. The procedure works perfectly!!!
1 - My device is a GSW not a SW. So, I changed it to GSW and executed all ipdevpoll's all jobs to get information about vlan interfaces and other missing things.
2 - After that, I removed the lldp information from NAV database because my device doesn't changes the timestamp of the lldpRemTable.
3 - The last step was run all jobs of ipdevpoll in all devices to fix the topology.
This is another procedure that can be inserted in docs to provide a more detailed knowledge base.
I can help with this if you want.
2014-07-11 14:48 GMT-03:00 Bruno Galindro da Costa <firstname.lastname@example.org
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.
I did this right now. Now I'm waiting the completion of the below command to see if neighbors's information are correct.
for i in `sudo -u postgres psql nav -c "SELECT ip FROM netbox" |grep "$MY_NET_PREFIX"`; do for job in `ipdevpolld -j`; do ipdevpolld -J $job -n $i; echo -e '\n'; done done
2014-07-11 11:18 GMT-03:00 Morten Brekkevold <email@example.com
On Wed, 9 Jul 2014 10:34:49 -0300 Bruno Galindro da Costa <
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.
-- Morten Brekkevold UNINETT
-- Att. Bruno Galindro da Costa