I enabled MAC-Notification traps on a few switches to check the new "Dynamic Updates" feature in the LMS3.0 User Tracking.
After I changed the port of a PC the User Tracking Report Utility shows me the correct new port but the "Last Seen " timestamp shows a time more then 120 minutes in the future ?
The time on the LMS Server and on the switch is correct. Any ideas wherefrom the false timestamp is caused by ?
Solved! Go to Solution.
Debugging dynamic UT can be a bit painful at this point, so it would be helpful to first figure out how traps are getting to the MACUHIC process. Are they coming directly from the device (i.e. have you configure the device to send traps to udp/1431 on the LMS server), or are they being forwarded to MACUHIC by another NMS?
The traps comes direct from the device ( Port 1431 ) to the LMS Server. DHCP snooping is also enabled on the switches.
Okay, I did some analysis on this, and found that I see a similar problem, though not nearly as bad. My last seens are coming in two minutes in the future. My test switch is a 2960 which has been up for 120 days. The uptime is important because UT uses that when determining the last seen time from a MAC address notification trap.
I suspect there might be a bad base timestamp in your portsData.xml file for your test device. Try running a new Campus Data Collection, then perform your UT tests again to see if the time stamps look more reasonable.
Same problem after a new ''Data Collection''. Seems to be some global problem. I added a few switches ( 2950 and 2940 ) with total different sysuptime, and the timestamps are always more than 120 minutes ahead.
Please post a show ver from one of these switches, the output of a walk of sysUpTime, and the NMSROOT/campus/etc/cwsi/portsData.xml file along with the IP address and hostname of the same switch as the show ver.
My calculation puts a trap received at approximately the time these outputs were taken at:
Tue Nov 13 17:44:50 2007 UTC
This would mean that a last seen at this time would be reported as (assuming CET is UTC+2 currently):
Tue Nov 13 19:44:50 2007 CET
I did some other calculations, and the sysUpTime appears correct. The timestamp in the portsData.xml file, however, is not. It does appear to be about two hours in the future (that timestamp should be the number of milliseconds since the epoch that the device was booted).
That value is computed by taking the server's current time in milliseconds (this value is UTC-based), then subtracting from that the device's sysUpTime in milliseconds (so sysUpTime*10).
I see no problem with the code that makes that calculation, so I have to assume that there is a time discrepancy on your server.
Attached is a Java class file. Copy it to your system's temp directory (/tmp on Solaris or C:\WINDOWS\TEMP on Windows). Then run it:
NMSROOT/bin/cwjava -cw NMSROOT -cp:a TEMP xxx
For example, on Solaris:
/opt/CSCOpx/bin/cwjava -cw /opt/CSCOpx -cp:a /tmp xxx
C:\PROGRA~1\CSCOpx\bin\cwjava -cw C:\PROGRA~1\CSCOpx -cp:a C:\WINDOWS\TEMP xxx
Post the output.
It indicates that the time is correct. But it doesn't tell me where the problem is. I have been under the assumption that you are running Campus 5.0.1. If you have not applied service pack 1 for Campus Manager, please do so.
A few days ago I installed the new Campus Manager service pack 5.0.3 and now the problem is back. The last seen timestamp is 50 min ahead. So it seems the patch isn't working anymore with the new service pack.
Yes, CM 5.0.3 overwrites the patch, and the fix has not yet been integrated into CM. There is currently no patch available for CM 5.0.3.
Yes, this is fixed in Campus 5.1 as well as in the upcoming Campus 5.0.4 release due out this October.