Ciscoworks not detecting a device

Unanswered Question
May 7th, 2008

We replaced a switch at one of our sites. It was configured the same as all our other switches.

It can ping the CiscoWorks server, however, the CiscoWorks server will not discover it as a device.

The ip is in the discovery range and I verified the SNMP strings.

Any ideas?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
d.metheny Wed, 05/07/2008 - 11:17

Was the original device in the CW database? If so, did you try deleting the original device from the database and rediscovering the new one?

scootertgm Thu, 05/08/2008 - 05:57

LMS 3.01 and the switch is a WS-C3750G-12S.

I can telnet into the switch, and the segments it is connected to are working just fine, it is just this device.

Joe Clarke Thu, 05/08/2008 - 06:47

If it is not too sensitive, please post your NMSROOT/conf/csdiscovery/CSDiscovery-config.xml file as well as the running config for this switch.

scootertgm Thu, 05/08/2008 - 07:28

The config.xml would have to be edited to the point I'm not sure how much you would be able to read. Is there something specific to look for in that file?

Attached is the switch config. I edited out user ID's, PW's and SNMP strings.

I have confirmed the SNMP strings matched and the user ID's and password matches that CiscoWorks is using.

Our TACACS went down a couple days ago, I will be reloading it next week. Could that be related?

Joe Clarke Thu, 05/08/2008 - 07:33

I will need to see the whole config. I assume your LMS server is one of or No, the AAA server would not affect this. Assuming Discovery is properly configured, the device should be added to DCR. Only then, and only if LMS is integrated with ACS, would AAA come into play.

scootertgm Thu, 05/08/2008 - 07:40

The LMS server is, 96 is our MARS box. The LMS is not integrated into the ACS.

When you say the whole config you are referring to the config.xml file or the switch config?

Joe Clarke Thu, 05/08/2008 - 07:41

The CSDiscovery-config.xml file. I need to see the whole configuration for Discovery.

scootertgm Thu, 05/08/2008 - 07:59

Here it is. I **** through the first two octets of any public addresses. I also removed any SNMP strings that were in the clear (They were only on a couple of routers that were not at the site in question). The "A" on the end means it is the edited version.

Joe Clarke Thu, 05/08/2008 - 08:39

Since is not listed as a seed device, it much be a CDP neighbor of one of the other seed devices, or devices already in DCR. Is this the case? Can you trace CDP back from this switch to another seed device or device in DCR?

scootertgm Thu, 05/08/2008 - 08:41

79.70 is a neighbor to 79.1. It can be seen on a show cdp nei from 79.1

Device ID: ****_FiberSwitch

Entry address(es):

IP address:

Platform: cisco WS-C3750G-12S, Capabilities: Switch IGMP

Interface: GigabitEthernet3/3, Port ID (outgoing port): GigabitEthernet1/0/5

Holdtime : 141 sec

Version :

Cisco IOS Software, C3750 Software (C3750-IPBASE-M), Version 12.2(35)SE5, RELEA)

Copyright (c) 1986-2007 by Cisco Systems, Inc.

Compiled Thu 19-Jul-07 19:15 by nachen

advertisement version: 2

Protocol Hello: OUI=0x00000C, Protocol ID=0x0112; payload len=27, value=0000000

VTP Management Domain: '****'

Native VLAN: 1

Duplex: full

Unidirectional Mode: off

Joe Clarke Thu, 05/08/2008 - 08:49

What would be useful now if to collect a sniffer trace of SNMP traffic to 79.70 and 79.1 during a Discovery. This will confirm that 79.1 is reporting 79.70 as a CDP neighbor via SNMP. This will also show if there is any SNMP communication problem with 79.70. Additionally, enable NGD debugging will help. Unfortunately, enabling this debugging is not straightforward, and the sniffer trace will not be something you can post to this forum. Therefore, I recommend you open a TAC service request with this information.

scootertgm Thu, 05/08/2008 - 08:50

Will do, I'll open up a TAC. Thank you for trying to help me get this resolved.


This Discussion