Solved: LMS 3.2 - DFM 3.2.0 - Questioned Devices, SNMP Timeout

tim.davies · ‎08-25-2009

Hi there,

When I try to descover devices in DFM the majority of devices go into the Questioned state as an SNMP Timeout, a few are known and some are stuck in the learning state at 40%. I have tried adjusting the SNMP timeout settings and deleting all Devices and reimporting them again into DFM with no luck!

Any ideas?

Cheers

Tim

Joe Clarke · ‎08-26-2009

Ah, I bet I know the problem. What we have seen is either customers copy the snmp-server engineID from device to device (which is wrong), or they are bitten by a bug where multiple devices come standard with the same engineID. The latter affects mainly Cat4500 switches. If you post the sniffer trace, I can identify which is the problem.

The solution/workaround for both is to make sure the engineID values on each device are unique, then remove the devices from DFM, and re-add them.

View solution in original post

Joe Clarke · ‎08-25-2009

The easiest way to troubleshoot this is to start a sniffer trace filtering on SNMP (udp/161) traffic to one problem device. Then delete this device from DFM, and re-add it. When the device slips into a Questioned state, look at the sniffer output. It should be clear where the problem lies.

As for 40%. This indicates a problem with DFM inventory collection. Since some of the devices are Known, DFM is probably okay, but there could be a device problem. Again, a sniffer trace would be helpful as it will show exactly the objects being polled and their values.

tim.davies · ‎08-26-2009

Thanks for the response.

On the sniffer trace I can see an ICMP ping request and then a few SNMP get-requests and thats it, the device then goes into a questioned state.

I have noticed that the devices that are are known are SNMP V2 devices and the devices that are questioned are SNMP V3. I have checked the SNMP V3 credentials in the DCR and they look ok.

Joe Clarke · ‎08-26-2009

Ah, I bet I know the problem. What we have seen is either customers copy the snmp-server engineID from device to device (which is wrong), or they are bitten by a bug where multiple devices come standard with the same engineID. The latter affects mainly Cat4500 switches. If you post the sniffer trace, I can identify which is the problem.

The solution/workaround for both is to make sure the engineID values on each device are unique, then remove the devices from DFM, and re-add them.

tim.davies · ‎08-27-2009

You've cracked it!

Each device had the same engineID specified. I have remove this configuation and allowed the device to create a unique ID. Everything now appears to be working.

Thank's very much for your help!

v.c.bodenstab · ‎02-21-2011

Hi Joseph,

"The solution/workaround for both is to make sure the engineID values on each device are unique, then remove the devices from DFM, and re-add them."

How would you make sure the EngineID is unique? Is there a command to let the switch generate it? Thanks,

Vincent

Joe Clarke · ‎02-21-2011

Typically the engineID is unique as it is generated automatically based on the first MAC address on the device. However, there have been some bugs where certain device types all configure the same engineID. Additionally, sometimes users copy and paste SNMP configurations from device to device and include the engineID. You must inspect each engineID visually to confirm uniqueness.

v.c.bodenstab · ‎02-21-2011

Hi Joseph,

Eh (sigh), that's what I have. In my switch configs, I got the command:

snmp-server engineID local xxxxxxx

In DFM 3.2.0, I've got devices switching straight to 'Questioned/SNMP Timeout'. The SNMPv3 credentials are correct and I can see SNMP traffic going back and forth. I removed the above command on all the switches. Is that enough to re-generate the engineID?

Thanks,

Vincent

Joe Clarke · ‎02-21-2011

To fix this, you need to remove all of your SNMP configuration, then reboot. Then re-add your SNMP groups and users (do NOT reconfigure the engineID). Then delete your devices from DFM and re-add them.

v.c.bodenstab · ‎02-24-2011

Hi Joseph,

Thanks for the reply! The engineID did the trick. I removed all engineID statements from the switch configurations, removed SNMPv3 users, deleted devices from DFM. Than added the SNMPv3 users again to the switches and added them to DFM. Presto! Working again :-) Thanks again.

Cheers,

Vincent