This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

UDT: Workstations connect to Cisco Phones show up as indirect connections

UDT v1.0 integrated with our NPM (v10.1.3) deployment.  Did a port discovery on a few nodes (switches+routers) already in the NPM database. 

So far, all the workstations that I have looked for via the Device Tracker Search that are plugged in to Cisco IP Phones or Cisco 3560G-8PC switches show up as indirect connections to their switch port.  Also, the IP Phones themselves and IP printers show up as indirect connections to their directly connected port.

Workstations devices not plugged in to IP phones, as well as IP Security Cameras and non-VMware servers, in other Cisco 3560, 3750 and 4510 switches show up as direct connections where expected.

How does UDT differentiate MACs that are directly connected from indirectly connected?

  • We're a small shop - less than 1500 ports.  So, I removed all the Nodes from NPM, re-discovered via Network Discovery.  Then, discovered ports on all routers and switches in UDT.  No change to the symptoms previously described, but a saw something new and weird. 

    All the PCs plugged in to IP Phones show as direct connections to the same switch port, Gi1/22, on one of our 3560 switches.  Weird. 

    If someone can provide insight in to how it decides whether a discovered MAC address is directly or indirectly connected, maybe I can figure out what I have that is confusing it. 

    I didn't do any filtering when I did my port discovery.

  • I think that will be because we are not actually pulling info from the switch in the phone.  So were are reading it from the point of view of something else.  So we know its there and we know its MAC but we also know that it is not plugged into us directly.

  • I am curious how it determines that it isn't plugged directly in to it.  The MAC shows up in the local MAC table on a port that is a non-trunk port.  Although the aforementioned port does have more than one MAC address. 

    I thought maybe it just assumed that if it saw multiple MACs on a single port, then it would consider all MACs on that port as indirect connections.  That assumption can't be correct, though, because ALL the PCs connected through IP Phones at our main site show they are directly connected to a single switchport on one of our access layer 3560s.  Feel like I am missing a piece of logic that keeps me from troubleshooting the problem. 

    Hopefully, this missing piece will also explain why the three 3560G-8PC switches we have don't show any directly connected devices.

  • I am also seeing things like this. With 2000 phones on my wire, it would be nice to be able to tell how this info gets polled.  From a Cisco standpoint, at least in my world, we have a seperate data vlan and voice vlan. The switch knows which mac is on which vlan, but UDT doesnt.

    Sometimes, I get pc addresses showing up in voice vlans, and sometimes phones in data vlans. always as a indirect connection.  The phones, at the least, should be a direct connection.

  • In my testing UDT sees the IPs and MAcs of the pc and Cisco IP phone correctly, however the DNS resolution of the IPs only works for the PC, not the phone.  I opened a case for this.

  • Wonder if my switchport configuration (?) is causing the issue.  This is the config for an interfaces with an IP phone+Desktop.  Is yours substantively different?

    interface GigabitEthernet3/1
     switchport access vlan 101
     switchport voice vlan 2
     auto qos voip cisco-phone
     qos trust device cisco-phone
     spanning-tree portfast
     service-policy input AutoQos-VoIP-Input-Cos-Policy
     service-policy output AutoQos-VoIP-Output-Policy

  • We identified some issues with this scenario in the original beta and fixed them. However, we found a few more after we released the product. Those should be fixed in the  upcoming service release.