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

[Martin Ermel]

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?

[Joe Clarke]

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.

[Martin Ermel]

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.

[Joe Clarke]

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.

[Martin Ermel]

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

[Martin Ermel]

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

[Joe Clarke]

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.

[Martin Ermel]

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

[Joe Clarke]

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?

[Martin Ermel]

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?

[Joe Clarke]

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.

[Martin Ermel]

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

[Joe Clarke]

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?

[Martin Ermel]

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

[Joe Clarke]

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.