LMS 3.1 /Snmp Timeout setting on RME

Unanswered Question
Sep 29th, 2009

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.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Joe Clarke Tue, 09/29/2009 - 07:10

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.

richard.tetu Thu, 10/01/2009 - 05:11

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

Attachment: 
Joe Clarke Thu, 10/01/2009 - 11:07

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.

richard.tetu Mon, 10/05/2009 - 07:19

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

Joe Clarke Mon, 10/05/2009 - 08:19

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.

richard.tetu Wed, 10/07/2009 - 06:15

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

Joe Clarke Wed, 10/07/2009 - 08:01

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

richard.tetu Fri, 10/09/2009 - 06:08

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

Joe Clarke Fri, 10/09/2009 - 06:59

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.

richard.tetu Tue, 10/13/2009 - 07:26

Thanks Joe,

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

Richard

Actions

This Discussion