cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1660
Views
0
Helpful
30
Replies

LMS 3.0 Device centre CDP update

mburrell5
Level 1
Level 1

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?

1 Accepted Solution

Accepted Solutions

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.

View solution in original post

30 Replies 30

Joe Clarke
Cisco Employee
Cisco Employee

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

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.

How does the Topology Map look? Is it correct?

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?

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).

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"

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.

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

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.

Ani.log was not updated - have sent anijason43.log instead. Is that ok?

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

One example is GH89HSSW01 (10.76.152.85). If you run sh CDP neigh on the switch you get GHMH3750 (10.76.152.6) which is correct. LMS however gives you GHTUCH01 (10.76.152.10 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

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.

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?

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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco