cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4528
Views
0
Helpful
7
Replies

SNMP engine discovery timeout!

Hitesh Thappa
Level 1
Level 1

we get the following error while trying to login to the fabric.

"SNMP engine discovery timeout. It could be

---busy newtwork

---no route from null/0.0.0

---10.64.18.61 snmpd is unresponsive"

but sometimes we are able to login. If we keep on trying to login after several attemps we are able to login but we get Timeout(server, client) error on the core switch and cannot do any zonings or check device manager for that switch.

Other switches in the fabric are working fine.

any suggestions, could this be some issue with ethernet card for the switch?

Attaching screenshots for more clarification on the issue.

7 Replies 7

mitchell.white
Level 1
Level 1

Did this behavior just start recently?  I am having a similar issue that started last week .  Working to resolve it with my vendor.

Yes, for us too this started recently. To me its looks like some ethernet card or ethernet cable issue.

wats the vendor's observsation in your case.

For us like today its working fine with no issues..but noone knows when it will be unavailable howvever we have seen the trend that around 10:30 PM CST it goes down and after midnight its back again.

I haven't received anything back from the vendor (they have a case opened with Cisco).   I was asked to provide the FM logs to them.

If you look at the fms_snmp.log file, it is full of these messages:

2010.11.24 02:50:46  WARN  [snmp.tcp] TIMEOUT 02:50:46 elapsed=21000 tcp 02:50:25 172.27.xx.xx, 1606970293 BULK u=xxxxx maxRptr=13 clmLicenseFlag....


2010.11.24 02:50:57  WARN  [snmp.tcp] Response after timeout (in process packet): 02:50:57 172.27.xx.xx, 1606970293 RESP u=xxxx clmLicenseFlag.....

Of note to mention, I installed Fabric Manager 5.01a on another server and duplicated the timeout behavior.  I uninstalled 5.0.1a and installed Fabric Manager 3.3.4a and it works without any of the issues we are seeing.

It looks like we may have discovered the cause for our timeout issues.    Fabric Manager was attempting to manage two UCS environments for which the SNMPv3 user was not set.   The explanation given was "The UCS authentication failures affect the overall performance of FM due to CPU expensive exception handling". 

The timeouts went away once I established the same SNMPv3 user and password on the UCS's that we have set for the seed switches on the fabrics.

Hi MItchell,

Tried your method but still facing the same issue. Moreover when there is timeout on switches they cant be accessed from CLI as well.

This is wat we get in fabric.

NDCCOR31 10.64.18.61 20:00:00:0d:ec:a2:a5:c0 timeout(Server) Cisco DS-C9513 3.3(5)
NDCEXP01 10.64.18.65 20:00:00:0d:ec:a2:3d:40 timeout(Server,Client) Cisco DS-C9513 3.3(5)

While it's not a bad idea to keep up with recent version of FM i don't think that this is currently the situation: if memory serves me well the switch wwns don't match the issue.

This seems more of an IP issue, especially because of this "they cant be accessed from CLI as well."

My suggestion would be to check if you can connect to the switch from a machine in the same subnet as the mgmt ip.  If that works, It's most probable a routing/firewall issue

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: