Ad blocker detected: Our website is made possible by displaying online advertisements to our visitors. Please consider supporting us by disabling your ad blocker on our website.
disH wrote:charles, import that .sql file again and do a database_upgrade.
it doesnt over write the data but it did help...
although currently i moved this machine to another spec machine SunSparc Linux to an intel Ubuntu and mac track isnt working for half of my devices.. .
i hope we can squash this problem with v2.0, im very excited TheWitness
Since I don't have access to a 3750, I need a sponsor to work with me to fix that specific problem. Anyone? Remote access is essential. It does not have to be unescorted, it could be monitored (aka we work things out together on the phone). It would also have to be after hours as I do have a full time job.
TheWitness
True understanding begins only when we realize how little we truly understand...
I had the same problem. For all 3750 stacks with more than 4 switches (more than 48*4). When your timeout for this device is under 1000ms the switch send back only the macs seen on the vlan 1 (but the network is quick 1Gbs,10Gbs) !!! and in my case the devices where on an other data vlan and voice.
A another strange phenomenon is some the macs of the vlandata and voice where seen on the vlan1 but naturally mactrac know there was neither gateway nor active interface on this vlan1, so for him there was no port.
Give a SNMP timeout 1000ms or above!!!!! for such big devices!
PS: it would be good to have a another method as snmp to gather MACS (telnet/ssh). It would be quicker when there is a lot of ports and will not use so much cpu.
TheWitness wrote:All,
We were bake to solve the problem. It was a version to version net-snmp setting change. The fix is stickied in this forum.
Hi
which post ?
I have tried "MacTrack Issues Obtaining Ports"-mactrac_lib too. Always the same; mactrac functions only with a timeout at least 1000ms for big stacks of 3750.
Thanks.