LMS 3.0 Device centre CDP update

Answered Question
Mar 11th, 2008

Using LMS 3.0.1. When devices have been moved to a different core switch the CDP info displayed in the likes of Device centre is incorrect (still shows the old connection). is there a way of forcing a refresh?

I have this problem too.
0 votes
Correct Answer by Joe Clarke about 8 years 8 months ago

If you haven't already opened a TAC service request on this, it looks like this bug has already been discovered. The bug is CSCso55021, and will occur if a device's hostname in DCR is blank. If you do contact the TAC, I can produce a patch to correct his problem. Just have your engineer contact me directly.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Joe Clarke Tue, 03/11/2008 - 17:07

You need to perform a new Campus Manager Data Collection for the device (or the whole network).

mburrell5 Tue, 03/11/2008 - 18:50

I should have mentioned that a Campus Manager Data Collection is run twice daily already and this is not updating CDP. If I manually connect to one of the core switches and run a sh cdp neigh command I get the correct switches showing up but LMS device centre still shows the old core switch.

mburrell5 Tue, 03/11/2008 - 19:08

You just reminded me - Topology services has not run properly since we upgraded to LMS 3.0.1 in Dec. we don't use Topology Services so haven't thought more of it until you mentioned it now. When you click on the label to start Topology a window pops up but stays blank. Would this be related to the CDP issue?

Joe Clarke Tue, 03/11/2008 - 19:13

It could be if ANIServer is not properly running Data Collection. Check to make sure you have the right version of Java Web Start installed on your client (currently, that's 1.5.0_13). Make sure you browser security settings allow for running dynamic content (it's best to trust the LMS server, and set your trusted server policy to Low if you're using IE).

mburrell5 Tue, 03/11/2008 - 20:05

Topology services did once work so it is not my browser or java. I have confirmed that by trying to access on the lms server itself which also used to run topology ok - it now doesn't work either. The ANIServer process is "running with busy flag set"

Joe Clarke Tue, 03/11/2008 - 20:56

The JWS version changed in LMS 3.0.1, so make sure you have the 1.5.0_13 version properly installed. Check the NMSROOT/MDC/tomcat/logs/stdout.log for any other errors.

mburrell5 Wed, 03/12/2008 - 16:48

Ok, the java version was wrong. now all sorted and Topology now runs. So to answer your earlier question the CDP neighbour info is wrong in Topology services also. it is also wrong when looking at the result list of devices on the Campus manager data collection page. So there is definitely an issue with updates in Campus manager - not just CDP info is incorrect. Device names and labels are also not updating correctly

Joe Clarke Wed, 03/12/2008 - 18:16

It could be that Data Collection is not running correctly. Enable Data Collection debugging for core and corex, and re-run it. Then post the ani.log.

Joe Clarke Thu, 03/13/2008 - 05:54

Data Collection appears to be running successfully. What is a device that does not show correct neighbor information?

mburrell5 Thu, 03/13/2008 - 14:21

One example is GH89HSSW01 ( If you run sh CDP neigh on the switch you get GHMH3750 ( which is correct. LMS however gives you GHTUCH01 ( or Gosford Tunnel 6509) which is incorrect. This switch used to connect to the 6509 but for the last 2 weeks or so is connected to the 3750. Other issues are many recently added switches are not coming up with a CDP neighbor at all or with incorrect labels

Joe Clarke Thu, 03/13/2008 - 15:52

There's certainly a problem getting CDP info from this device. At this point, I would ask for a sniffer trace of all SNMP traffic to this device during a Data Collection as well as a show run/show ver from this device. That information may be too sensitive to post in an open forum, so you would need to open a TAC service request with the information.

mburrell5 Tue, 03/18/2008 - 16:18

What should I see in the SNMP communication during a data collection? Some further info - the device discovery has all the correct hostnames and CDP info, and this info is in DCR. Doesn't the Campus Data collection get this info from DCR or does it requery each device? the problem as I see it is getting Data Collection to pick up the updated info from DCR. As a test, the device in my earlier example that had been moved yet still showed its old CDP neighbour was deleted and rediscovered. It now shows 'null" under CDP neighbors. This suggests that the Data collection is not updating correctly from DCR or elsewhere, yet was once working for this particular switch. Does this shed any new light on the problem?

Joe Clarke Tue, 03/18/2008 - 16:53

You should be seeing ANI poll the device for system information, interface and IP information, STP information, VLAN information, and CDP information. Depending on the device type, there can be a lot involved in a proper Data Collection.

Discovery and Data Collection have nothing to do with each other. Just because Discovery looks okay has no bearing on what will be seen in Data Collection. This is especially true in LMS 3.0.1.

Data Collection gets the list of devices and credentials from DCR; nothing more. It then polls the devices for the information I listed above to build the topology.

Again, simply rediscovering a device will not have any effect on Campus Manager. You will need to perform a new Campus Data Collection in order for Campus to reintegrate the device into the Topology, and populate the CDP neighbor info.

mburrell5 Tue, 03/18/2008 - 17:20

Campus Data collection has been run after device was redicovered but info still not updated. I have attached a packet trace of the Data collection on this particular device. from what I can see the correct info is coming back but is not being updated in campus manager. Campus manager still shows no cdp neighbor info

Joe Clarke Tue, 03/18/2008 - 19:00

Yeah, I see that neighbor. Is that switch,, listed in DCR, and allowed by the Data Collection filters?

Joe Clarke Tue, 03/18/2008 - 19:07

Something else I notice is that ANI thinks the hostname for this neighbor is Gosford Mandala 3750. Have you really configured your name resolution system so that the hostname contains spaces? This is most likely not supported as the RFC for hostnames does not permit space characters.

mburrell5 Tue, 03/18/2008 - 19:13

The device is definitely in DCR and is not limited by any data collection filters (there are none set). The hostname is GHMH3750 & the display name in LMS is Gosford Mandala 3750. there are no spaces in any of the hostnames

Joe Clarke Tue, 03/18/2008 - 19:17

This might be fixed by reinitializing the topology portion of the ANI databases using NMSROOT\campus\bin\reinitdb.pl. After that, run a new Data Collection to regenerate the topology. As for more troubleshooting, there appears to be something dying very early on in Data Collection. Enabling frontend and framework debugging in addition to core and corex should show what that is.

mburrell5 Tue, 03/18/2008 - 21:05

After reinitializing the topology and running a new data collection, the problem is bigger than first thought. Now, only 344 devices are found instead of 475. No CDP info has been picked up for any of them. This indicates that although data collection seemed to be working for some devices before it wasn't really. Obviously it did once work. Which log files do you need if I have turned debugging on as you requested?

Joe Clarke Wed, 03/19/2008 - 09:59

There is a problem processing It's not clear as to exactly what that problem is from the log. However, the symptoms look like a bug which should have been fixed in CM 5.0.2. What is the byte size of NMSROOT/campus/lib/classpath/com/cisco/nm/ani/server/core/DcrToCampusMap.class?

Joe Clarke Sun, 03/30/2008 - 22:30

This is correct. Unfortunately, there is no way to pinpoint the cause of the exception given the current code. More debugging code will need to be added. You will need to open a TAC service request and your engineer can get additional help from either development or myself.

Correct Answer
Joe Clarke Sun, 04/06/2008 - 22:32

If you haven't already opened a TAC service request on this, it looks like this bug has already been discovered. The bug is CSCso55021, and will occur if a device's hostname in DCR is blank. If you do contact the TAC, I can produce a patch to correct his problem. Just have your engineer contact me directly.

mburrell5 Sun, 04/06/2008 - 22:40

Hi, I have a TAC call open with Cisco. I have passed your comment on to them


This Discussion