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.
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 morten.brekkevold@uninett.no:
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.
-- Morten Brekkevold UNINETT
Morten,
Good news. The procedure works perfectly!!!
Resuming:
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 <bruno.galindro@gmail.com
:
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 <morten.brekkevold@uninett.no
:
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.
-- Morten Brekkevold UNINETT
-- Att. Bruno Galindro da Costa
On Fri, 11 Jul 2014 17:18:19 -0300 Bruno Galindro da Costa bruno.galindro@gmail.com wrote:
Good news. The procedure works perfectly!!!
Good to hear!
[snip]
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.
Thank you :) We do have an FAQ in the wiki, which I think is really outdated by now, and it should also really be moved to our Sphinx-based documentation. We could probably do with an update of the FAQ; I know I've helped more than one person with these kind of problems :) Some troubleshooting tips in the FAQ would help.
I posted some pointers yesterday, but please don't hesitate to ask if you need help getting started. I'm still in Berlin, so I'll be partially responsive until tomorrow, then I have another 2 weeks of vacation. Same goes for John-Magne, I'm afraid.
Thank you :) We do have an FAQ in the wiki, which I think is really outdated by now, and it should also really be moved to our Sphinx-based documentation. We could probably do with an update of the FAQ; I know I've helped more than one person with these kind of problems :) Some troubleshooting tips in the FAQ would help. I posted some pointers yesterday, but please don't hesitate to ask if you need help getting started. I'm still in Berlin, so I'll be partially responsive until tomorrow, then I have another 2 weeks of vacation. Same goes for John-Magne, I'm afraid.
Ok!
2014-07-24 5:44 GMT-03:00 Morten Brekkevold morten.brekkevold@uninett.no:
On Fri, 11 Jul 2014 17:18:19 -0300 Bruno Galindro da Costa < bruno.galindro@gmail.com> wrote:
Good news. The procedure works perfectly!!!
Good to hear!
[snip]
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.
Thank you :) We do have an FAQ in the wiki, which I think is really outdated by now, and it should also really be moved to our Sphinx-based documentation. We could probably do with an update of the FAQ; I know I've helped more than one person with these kind of problems :) Some troubleshooting tips in the FAQ would help.
I posted some pointers yesterday, but please don't hesitate to ask if you need help getting started. I'm still in Berlin, so I'll be partially responsive until tomorrow, then I have another 2 weeks of vacation. Same goes for John-Magne, I'm afraid.
-- Morten Brekkevold UNINETT
-
Bruno Galindro da Costa -
Morten Brekkevold