Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

LMS 3.1, CM 5.1.1 - UT on trunk ports also discovery on link ports

platform is Windows VmWare

Perhaps this is yet resolved in a newer version but I could not find any  hint for it...

Customer has configured User Tracking to discover endhosts on trunk  ports. This is set globaly for all devices. Now we observe that switch_1

(2950) reports MAC addresseson one of his uplink-ports (gi0/2).

The switch_1 is connected to other cisco devices on gi0/1 and gi0/2; CDP  is enabled on all devices; I do not see any problem here; Looking on  the topology map I see only one neighbor device for switch_1 (on port  gi0/1).

As far as I could see, the problem here is that the device connected  on gi0/2 is managed by LMS with another IP then CDP reports is has.  This is a known issue and the command "cdp source-interface" could help  here if available in IOS. But it is not....

With debugging enabled for Data Collection, I see that the information  about CDP neighbor devices is read correctly, i.e. neighbors are seen on  both uplink-ports.

As far as I know, this process builts the "portsData.xml" file which is  used by User Tracking to classify how each port needs to be treated. But  in this file

gi0/2 is classified as an access port and not as a link  port which leads to the observed problem.

Couldn't this be easily solved with a patch as Data Collection clearly  sees a CDP neighbor device - so the port could be classified correctly -  no matter if the neighbor device is managed by LMS or not!

Does this patch yet exists ? or istn't it that easy to implement?

15 REPLIES
Cisco Employee

Re: LMS 3.1, CM 5.1.1 - UT on trunk ports also discovery on link

If the topology map does not show a neighbor on this Gi0/2 port, then the port is not a link port according to Campus.  If there really is a CDP neighbor on this port, then the reason Campus is not building a link could be due to a problem on the neighbor device (maybe it's not being Data Collected properly), duplicate sysNames, or some ANI database corruption.  I do not have enough information to conclude that this is a Campus bug.

Re: LMS 3.1, CM 5.1.1 - UT on trunk ports also discovery on link

I checked the cdp information on the devices on both sites of the link, this was ok; I will double check if the device connected to gi0/2 is managed correctly in Campus but I assume it is but with another IP. This behaviour is seen on some devices in the network.

Cisco Employee

Re: LMS 3.1, CM 5.1.1 - UT on trunk ports also discovery on link

It may be a problem with Data Collection not completing.  You could check this by reinitializing the topology portion of the ANI database:

NMSROOT/bin/perl NMSROOT/campus/bin/reinitdb.pl

An upgrade to CM 5.1.4 would eliminate that problem.

Re: LMS 3.1, CM 5.1.1 - UT on trunk ports also discovery on link

I issued the reinitdb, - while it seems that this solved it for most of the devices it is not for at least one. Data Collection finishes in less then 5 min for ~ 550 devices and there is no obvious error in the log. I am still asking myself if it is really necessary to have both ends of a link properly managed in Campus to make the correct decission for UT (portsData.xml). I would say this is unnecessary, because seeing a cdp neighbor on the far end of a link makes a clear decission possible that it is a link port, regardless if the other side is managed by LMS or not.

Currently there is a UT Major Aquistion running - I hope I can follow up this issue in 2 days...

Re: LMS 3.1, CM 5.1.1 - UT on trunk ports also discovery on link

after looking into this in more detail it seems that Data Collection really classifies a port as a "link port" ONLY if both sides of the link are managed devices in CM.
Does Cisco not believe in its own protocol? If a port reports a cdp neighbor this must be enough to decide that this port is a link port! This has a great impact on how User Tracking works (particularly when enabled on trunk ports) and I would account it as bug. Data Collection does have all information to make the correct decission but it makes a wrong one...(-or do I miss something here?)
For other applications relying on this information there could be perhaps a differentiation between "confirmed link ports" which means both sides of a link are managed devices and "unconfirmed link ports" which would mean that the cdp neighbor seen on a port can not be confirmed from the other side...(perhaps an enhancement for LMS 4.0 :-)  )

Cisco Employee

Re: LMS 3.1, CM 5.1.1 - UT on trunk ports also discovery on link

Campus has always wanted to verify both ends of a link to build the topology.  Campus doesn't consider a port to be a link unless that link appears on the map.  For that to happen, both ends need to be on the map.  This means both devices need to be managed.

It would be too late to change this behavior for LMS 4.0.  However, you could get a PERS in the pipe for 4.1.  This would be a huge change to how Campus currently works, though.

Re: LMS 3.1, CM 5.1.1 - UT on trunk ports also discovery on link

Ok, but there is a "new" process that constructs the portsData.xml file, perhaps this could be changed more easily if I am right with the assumption that this file is only used by UT...
perhaps I can discuss this issue in the beta phase of LMS 4.0...

Cisco Employee

Re: LMS 3.1, CM 5.1.1 - UT on trunk ports also discovery on link

While the generation of these XML files is new to Campus 5.x, the data used to generate them is the same data found by Data Collection.  If the ANI database reports that a give port is a non-link access port, then that's how it will be written to portsData.xml.

It sounds like what you really need to do is exclude these ports from trunk port acquisition in UT.  What might facilitate this is if there was an "Exclude trunk ports" option in addition to the "Selected trunk ports" option?

Re: LMS 3.1, CM 5.1.1 - UT on trunk ports also discovery on link

yes, this option would be indeed something that facilitates the configuration!
But would it be such a great change to make the link categorization a parameter with 3 possible values (non-link, unconfirmed-link, confirmed-link)? When Data Collection does its device-specific tasks it can set a port with a cdp neighbor to "unconfirmed-link" and the process that built-up the topology can change these ports to "confirmed-links" if both sides are reporting consistent data - or just leave it as is.

I could see some possible features related with this information:
- adding unconnected devices as shadow devices to the map (to get a complete picture of the network even if device are not completely managed by CM)
- a report to quickly see links where cdp data is missing on the far end
- UT discovery on trunk ports could be adjusted to these settings :-)
- perhaps discrepancy reports could also trigger a process and try to get the config information from the far end by telnet/ssh (ok, this I believe would be rally a design change...)

Do you think this would be useful or just a feature that does not make any real enhancements?
currently link-port is a boolean value isn't it?

Cisco Employee

Re: LMS 3.1, CM 5.1.1 - UT on trunk ports also discovery on link

Anything is possible.  I'm not trying to discourage the feature idea, I just want to impress that what you're describing would be a substantial change to current behavior.  I'm also not convinced this would affect that many users.  This is the first time I am hearing the scenario you describe.

I like the idea of unconnected devices showing up as shadows, though.  I think that would give a nice single-map look of all network devices.  And, as you say, this could also apply to those "missing" CDP neighbors.

Yes, the link port value is a boolean, but internally, Campus knows what a link port is because there are topology end points associated to various interfaces.

Re: LMS 3.1, CM 5.1.1 - UT on trunk ports also discovery on link

I think this could be used by all customers with VOIP implementations other then CCM. In these situations some still use trunks to connect the phone. So enableing trunk port acquistion globally would be a good idea, but if not all cisco devices are in CM you can observe what I did...

Cisco Employee

Re: LMS 3.1, CM 5.1.1 - UT on trunk ports also discovery on link

Oh, no doubt this feature is important to VoIP users.  It's the combination of the two criteria that make it more of a corner case.

I wonder, could you create groups to match access layer switches, and only turn on trunk port acquisition there?  Or is that the problem?  Is it distribution devices which are missing from DC?

Re: LMS 3.1, CM 5.1.1 - UT on trunk ports also discovery on link

good hint! that I have not thought about. I will try this next week.

...but I like the general way so the customer does not need to adjust the settings when the devices change... (that's the lacy way... :-) )

Cisco Employee

Re: LMS 3.1, CM 5.1.1 - UT on trunk ports also discovery on link

Yeah, the trunk port list would be static.  If a new trunk or AL switch was added, the configuration would need to be amended.  I think there is a real possibility of getting an Exclude option in Campus in the short term to help address this.

Cisco Employee

Re: LMS 3.1, CM 5.1.1 - UT on trunk ports also discovery on link

I filed CSCtf29124 to request the "exclude" feature for trunk port acquisition.  I feel this is probably the easiest change to make with no architectural changes.  I encourage you to pursue the other enhancements as PERS.


494
Views
25
Helpful
15
Replies