Solved: Losing the battle with UT

kjackson74 · ‎02-09-2007

I am hoping that someone will have the answer to my problem so that I can gain the upperhand with User Tracking. Right now, I am just wanting to use it so that I can see which MAC (and therefore pc) is on which port. I don't even care about seeing the actual user. The problem is some switches show up in user tracking and some don't. Here is what I have done:

I have checked Topo Services to make sure the ones that are not showing up in UT are showing up in Topo

I have checked the SNMP community strings

I have debugged and gotten a 20 MB file. I traced the entries for switches that do show up and switches that don't and the only thing that stood out to me was this recurring error "Unable to fetch STP device instance params from device..."

I have checked the switches' IOS/type to see if there was a pattern in those that don't show up and those that do

I am new to this, and the other Network Admin here isn't a big fan of LMS and doesn't have time to mess with it. My problem may be an error in my expectations of UT, in which case I would be grateful for someone to set me straight so that I can quit banging my head against the wall.

Thank you

Kari

Joe Clarke · ‎02-09-2007

Regardless of whether or not other switches work, the '@' sign is the most likely cause of your problem. Change the community string to something without the '@' and your problem should go away.

The STP errors are most likely indicative of the same problem. ANI is trying to get STP data for each instance of spanning tree using community string indexing. The double '@' in the queries are being rejected by the switches, and thus you get an error.

View solution in original post

Joe Clarke · ‎02-09-2007

First, verify that your community strings do not contain an at sign (i.e. '@'). This character is invalid in Cisco community strings since we use it for community string indexing.

Next, the way UT works is that it only acquires users on non-trunk, non-link switch ports. A link port is any port which has another Cisco device connected to it which shows up on the Topology map.

If your community strings are good, you should pick a missing MAC address, enable vmpsadmin debugging under Campus Manager > Admin > Campus Data Collection > Debugging Options, re-run a UT acquisition, then scan the ut.log for entries pertaining to that MAC address.

If the MAC is completely missing from the log, then scan the log for the switch's hostname and IP address. If that is missing, then something may be wrong with the ANI database. We have had some issues in the past which could explain what you're seeing, but they are all fixed in Campus 4.0.7.

kjackson74 · ‎02-09-2007

Okay, the community strings do contain an at sign, but other switches that have the same community string are showing up.

I did do the debugging. I chose a MAC and followed it throughout the log. Saw it on a bunch of links, but none of the ports for certain switches are showing up. I followed the switch that wasn't showing up and that's where I saw the STP error message, which may not even be relevent. I can't find good documentation on making heads or tails of those files, and since the previous admin installed it on a VM, which I understand is not supported by Cisco, I don't feel like I can open a TAC case. I will check to see what version of Campus we have. I told the other admin that we needed to check for updates (I don't have an account that allows me to do that) but like I said, he's not too impressed with LMS.

Thanks!

kari

Joe Clarke · ‎02-09-2007

Regardless of whether or not other switches work, the '@' sign is the most likely cause of your problem. Change the community string to something without the '@' and your problem should go away.

The STP errors are most likely indicative of the same problem. ANI is trying to get STP data for each instance of spanning tree using community string indexing. The double '@' in the queries are being rejected by the switches, and thus you get an error.

kjackson74 · ‎02-13-2007

It worked! Thank you! I changed the snmp string on one of the devices that wasn't showing up in UT and now it sees it. Now I just have about a hundred more to change the strings on:)

martyyates · ‎02-15-2007

good news. Just use RME NetConfig to update the SNMP string on all your remaining devices - rather than manually doing it...

- Marty.