cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1149
Views
0
Helpful
6
Replies

LMS 4.0: Fault Monitoring Device Administration stuck in learning

alex.dersch
Level 4
Level 4

Hello Members,

i have a problem with Fault Monitoring Device Administration. i have two devices which stuck in learning mode for almost forever. When the job is done the devices report an error SNMP timeout. I run a credential verfication job and the credentials for the devices are correct.

any ideas?

regards

alex

1 Accepted Solution

Accepted Solutions

Assuming these are the only four devices using SNMPv3 in LMS, then the engineID is a non-issue.  However, if any other device has the same engineID as those two non-working devices, the problem could still be a duped engineID.  Debugging with logs is fairly complex.  The easiest way to identify the problem is to use a sniffer.  Start a sniffer trace filtering on all traffic to one of the failing devices.  Then, rediscover the device in Fault Monitoring under Admin > Collection Settings > Fault > Fault Monitoring Device Administration.  When it goes to a Questioned state, look at the sniffer trace.

If you see SNMP report packets indicating an error of notInWindow, that points to the duplicate engineID problem.  ICMP packets without responses points to problems with ping.

View solution in original post

6 Replies 6

Joe Clarke
Cisco Employee
Cisco Employee

What version of SNMP are you using for these devices?  Confirm that you can ping them from the LMS server.  If this is a Windows server, try disabling the Windows Firewall, then see if you can successfully learn the devices in Fault Monitoring.

I use SNMP version 3 and the devices are in the same subnet as the LMS server. LMS does learn Fault Inventory from Devices outside the subnet, even there there is a firewall in the path.

Make sure the SNMP engineIDs on your devices are unique.  If not, then you will see the problem you're seeing.  To fix it, you will need to assign a unique engineID to each device, unmanage those devices from Fault Monitoring, then re-manage them.

You can use the "show snmp engine" command to show the current engineID value.

i think this is not an issue.

i copied all the information from the machines. is there a log files where i see what's going on?

Catalyst 3560X
10.0.128.253
Local SNMP engineID: 800000090300588D09806A01
Fault Monitoring not working

Router 2911
10.0.128.1
Local SNMP engineID: 8000000903001CDF0F19FA78
Fault Monitoring not working

Router 2911
172.16.2.14
Local SNMP engineID: 8000000903001CDF0F6EEAE0
Fault Monitoring working

Catalyst 3560X
10.12.0.2
Local SNMP engineID: 800000090300588D098D6981
Fault Monitoring working

Assuming these are the only four devices using SNMPv3 in LMS, then the engineID is a non-issue.  However, if any other device has the same engineID as those two non-working devices, the problem could still be a duped engineID.  Debugging with logs is fairly complex.  The easiest way to identify the problem is to use a sniffer.  Start a sniffer trace filtering on all traffic to one of the failing devices.  Then, rediscover the device in Fault Monitoring under Admin > Collection Settings > Fault > Fault Monitoring Device Administration.  When it goes to a Questioned state, look at the sniffer trace.

If you see SNMP report packets indicating an error of notInWindow, that points to the duplicate engineID problem.  ICMP packets without responses points to problems with ping.

Hello Joseph,

thank you for your support. I believe there was a credential missmatch. I deleted the device credentials and created them again. Now it's working. I think there still some issues with SNMP v3, i use SNMP 2 instead now.

regards

alex

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: