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.

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.

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

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

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.

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

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?

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?

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.

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

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?

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

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.