On Mon, 28 Sep 2015 20:09:52 +0200 ken.livesey@gmail.com wrote:
I played around with the max-repetitions and timeout options but to no avail.
What combinations did you try? Some devices will have a problem with anything but really small values for max-repetitions. They're just completely unable to build a response that large within the allotted time.
Some devices are just plain slow and cannot be helped.
I did get the inventory to function to complete by commenting out the ciscovlan plugin. Once I did this, the OID populated for all unknown devices and I started to get inventory information.
Just for clarity the "warning" event concerning the typeoid unknown to unknown should be kept as a warning or error as this process did not populate any netbox information.
I assure you that this message has nothing to do with your problem, whatsoever.
Nothing was populated in the database because the job only updates the database when its collection phase finishes successfully - but yours timed out in the ciscovlan plugin.
Anyway I will continue to look into the ciscovlan plugin timeout error. Is there anyway to get additional info from this process?
The relevant MIB implementations don't have much in the way of debug logging, so you would have to get that from the SNMP protocol layer.
You could try running a manual inventory collection for a device, with a log level setting of "root = DEBUG" - if you dare. This will produce huge amounts of log lines, not just from NAV, but from third party libraries. I would recommend sending a copy of stderr to file for later review, and to rememeber resetting the log levels afterwards.
(A slightly more defensive approach is just using "nav = DEBUG" in your `logging.conf`, leaving third party code out of it)