cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1136
Views
0
Helpful
11
Replies

LMS 3.1 /Snmp Timeout setting on RME

richard.tetu
Level 1
Level 1

Hello dears all.

We have set a snmp timeout value on RME for the devices attributes.

I would like to know if the value could be tracked and on which debug and if it's exists.

On which config file the devices attributes has ben registered.

Thanks all.

11 Replies 11

Joe Clarke
Cisco Employee
Cisco Employee

If debug is enabled for ICServer or ArchiveMgmt Server, the SNMP timeout should be seen in the IC_Server.log and dcmaservice.log. However, it's easier just to look at the values in the GUI under RME > Devices > Device Management > RME Devices > Edit Device Attributes.

I have the logs ICServer.log but it seems that the snmp timeout has belonged to the credentials of the equipment for us it's strange..

The icserver.log is posted under the thread but i don't think it's relevant of something.

We have masked the network id of the @IP

.What we can see is that there is an exception.

I would like just remind us what was the purpose of the thread:

- keep an eye under the snmp value and exchange between the snmp request launched from the GUI of the CISCOWORKS.

---------------------------------------

[ Wed Sep 30 17:13:23 GMT 2009 ],DEBUG,[Thread-21],com.cisco.nm.rmeng.util.logger.RMELogger,734,com.cisco.nm.rmeng.util.rmedaa.RMERepository,getAttr,131, Got value for XX.YY.255.1|SNMP_TIMEOUT Value : ***(masked)

[ Wed Sep 30 17:13:23 GMT 2009 ],DEBUG,[Thread-21],com.cisco.nm.rmeng.util.logger.RMELogger,734,com.cisco.nm.rmeng.util.rmedaa.RMERepositoryUtil,fallBacktoSecondary,205,fromCmdSvc false fallBack false

[ Wed Sep 30 17:13:23 GMT 2009 ],DEBUG,[Thread-21],com.cisco.nm.rmeng.util.logger.RMELogger,734,com.cisco.nm.rmeng.util.rmedaa.RMERepositoryUtil,incrementLoginEnableCounters,69,fromCmdSvc false fallBack false

[ Wed Sep 30 17:13:23 GMT 2009 ],DEBUG,[Thread-21],com.cisco.nm.rmeng.util.logger.RMELogger,734,com.cisco.nm.rmeng.util.rmedaa.RMERepository,getAttr,131, Got value for XX.YY.255.1|SNMP_RETRIES Value : ***(masked

---------------------------------------

Thanks

The error here, failure to get sysObjectID due to a timeout, is almost certainly an SNMP credential problem. You should start a sniffer trace filtering on all SNMP traffic to this device, then run a new inventory collection. Then check the packet capture to make sure the SNMP credentials being sent are correct. You should also verify that nothing on the network is blocking SNMP traffic to this device.

It is very rare that you would have a need to increase SNMP timeouts just to be able to fetch the sysObjectID.

In fact the problem who was reported is that the timeout set under the GUI was not dynamic. We have change the value to 5 seconds and it was still staying at 2s .

The Wireshark trace taken shows us that,

it was done when the community string was change on the equipment and so it was unreachable from a snmp point of view

I put it under the attachements folder

Thanks

I don't see any responses in this trace, even after six seconds. If you're certain that the SNMP credentials in DCR are correct, and that the LMS server can really talk to this device via SNMP, you should bump up the SNMP timeout by going to RME > Devices > Device Management > RME Devices > Edit Device Attributes. Do an inline edit, click on the device name, and change the default of 2 seconds to at least 7 seconds. Then save those settings, and click Apply in the previous screen. That will set the timeout for that device.

Thats 's true, there us no response as the community string was changed under the equipement.So, it should never answer to the get request;

If you look the trace, and apply the time reference on the first frame, you can see that the second one is sending after 2 seconds while the value is set to 5 under the GUI.

After, it tooks 3 seconds to send another "get request" frame.

Richard

I have joined another trace. No proxy has blocked the traffic as we can see that there is an answer.

But not after the time expected.

Post a screenshot of the RME > Devices > Device Management > RME Devices > Edit Device Attributes screen for this device.

Thanks Joe,

Please see these following screenshots taken not for a particuliar devices , but it's a setting for all.

We have verified that when it has been changed under this path, it has been changed too under the credentials of the equipment.

Richard

Okay, so the timeout is set to 5 for all these devices. But, since you blocked out the hostname, I have to way of mapping that to the device in the sniffer trace. I recommend you open a TAC service request, so you can provide complete, unfiltered data. Only then will it be possible to troubleshoot this.

Thanks Joe,

I have opened a case to the TAC, i will let you know of the issue given .

Richard

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco