We are utilizing user tracking to monitor/manager switch port usage on our Cisco switches. In one part of our network we have a pair of Cat 6513's that have a few hundred servers attached to them. Firewalls sit in front of the 6513's, so the default gateway for all the servers is the firewall's IP address. The router in the 6513 is basically not being utilized as a gateway for the servers. None of the servers are showing up in User Tracking.
We have other Cat 6500's in our environment that are being tracked properly by User Tracking.
I am trying to understand why we are not seeing any of the servers mac and/or ip addresses in User Tracking. If there is a reason, what are my alternatives to getting this working. I believe this configuration must be a common configuration with switches sitting behind firewalls.
Using firewalls as gateways will mean that you will not see IP addresses or hostnames in UT. However, you should see the servers' MAC addresses provided these switches have been Data Collected by Campus Manager, and showing up with green switch icons on the topology map. What version of Campus Manager are you using? Are the switches properly data collected?
We are using version 5.1.3. When I view the device in topology services it lists it as reachable. Both devices are listed as reachable and on the map it the icons for the devices are green. When I look at the device attributes, I see all the modules that are installed.
Enable user tracking debugging under Campus Manager > Admin > Debugging Options > User Tracking Server, run a new full User Tracking acquisition, then post the ut.log as well as a sample missing MAC address, show run from the switch to which that MAC directly connects, the output of "show mac" from that switch, and the output of "show int status" from that switch.
After working with TAC on this issue, I found that the problem with user tracking not showing information for this switch was because our community string included an @ sign. When the queries are done for the CAM table from Ciscoworks, the query appends the @ sign with the VLAN number. By having an @ sign in the community string, it breaks the user tracking application, as well as other management tools like SPectrum.
This is not a bug, but rather a design of SNMP on IOS. SNMP was not designed to supported multiple instances of a MIB. In order to workaround this, Cisco chose to use the '@' to distinguish instances. SNMPv3 added contexts which allows for a standard way to access multiple instances of the same MIB. But if you need to use v1 or v2c, you must make sure your community strings do not contain '@'.