Place Your Feature Requests & Bug Reports Here

[chadd]

Oh, question. I see that the 'serial number oid' field is in the 'device type' page, but there is no column in the device report for the serial numbers... Is this a plan for the future? Just checking. Thanks,

-chadd.

[TheWitness]

Chadd,

Where and the hell did "cacti086" come from. I could have sworn I triple checked that.

As far as the Asset information is concerned, the reason that it is not there currently is because I am belabored to get out 1.0 and I believe strongly that the Asset information that I initially pushed was not ready.

I think, in fact, that we need a "custom" scanning function per device just like we have with both the Ports and IP addresses (now). Wouldn't you think? In any event, it may have to wait till the next release as I don't want to put something out that will hit the wall right away, and I had to swerve as soon as I kicked the dog out da house the last time.

Regards,

Larry

[TheWitness]

Ok, database_upgrade.php is healed now

Larry

[chadd]

Yes, I agree. Thanks a ton!

[cwahlin]

Not sure if this is doable or not, but I figured I should add a comment.

I have tried the released version of mac track and in our network it gives us a problem not being able to resolve the IP adresses from the ARP table. We run MPLS and thus each ARP table is build per routing instans (you need to use "show ip arp vrf <some_dept>"). The regular ARP command gives only the global routing tables ARP table.

Is this easy to get fixed to 1.0, or not doable?

/Carl

[lavermil]

Not sure if this is doable or not, but I figured I should add a comment.

I have tried the released version of mac track and in our network it gives us a problem not being able to resolve the IP adresses from the ARP table. We run MPLS and thus each ARP table is build per routing instans (you need to use "show ip arp vrf <some_dept>"). The regular ARP command gives only the global routing tables ARP table.

Is this easy to get fixed to 1.0, or not doable?

/Carl

I don't see why we couldn't easily put an option in the device configuration portion that says "Cisco VRF support" [x]. That shouldn't be hard. It is just a matter of messing with the SNMP and getting that to return correctly. I know Witness is really tasked with tons of stuff. If you could spear head looking up the SNMP mibs for it and trying to get snmp walks it would be of great help. Also if you have a test environment we/you could test against that. Never really good to be testing against production. Even though most everyone company only has a production network.

P.S. I don't get much time to play with stuff as of late as I have some serious project in the works that need to be done and our lockout period is coming quickly so I need to complete my network changes before I can actually start helping a lot more.

-Lance

[Tramjoe]

Hello,

I just tried the SVN version with a fresh cacti 0.8.6j, and well ... it is all broken. Is this a known state or is it just me ?

If it's just me, then I'd be glad to post more debug info ...

[Tramjoe]

Hello again,

I am currently trying to find a previous release from the svn repo that would be usable (I started fixing some trivial stuff on rev 240, but it is too broken it seems ...).

Is there a recent revision in a working state ?

Regrads,
Jerome

[lavermil]

Is anyone else having issue with mactrack and Cisco 4006 cat switches. It seems to run into a lot of timeouts. I haven't had the time to expand the debug feature so it will print me out the OIDs it is going to attempt to use and possibly the snmpget/snmpwalk equivalent of what is being ran via php-snmp. When I get around to that I will post that update. But for now I will just have it as a wish list. It would assist in debuging issues like this.

Here is an example of what I see. It doesn't matter what version I use. I have the same problem with all the mactrack versions.

DEBUG: VLAN Analysis for VLAN: 1000/Backup_VLAN is complete. ACTIVE PORTS: 2
DEBUG: Processing has begun for VLAN: 1
Timeout: No Response from ops-as-07.abc.com:161
DEBUG: Port number information collected.
DEBUG: No user ports on this network.
DEBUG: Bridge port information about to be collected.
DEBUG: VLAN_ID: 1, VLAN_NAME: default, ACTIVE PORTS: 0

-lance

[lavermil]

Is anyone else having issue with mactrack and Cisco 4006 cat switches. It seems to run into a lot of timeouts. I haven't had the time to expand the debug feature so it will print me out the OIDs it is going to attempt to use and possibly the snmpget/snmpwalk equivalent of what is being ran via php-snmp. When I get around to that I will post that update. But for now I will just have it as a wish list. It would assist in debuging issues like this.

Here is an example of what I see. It doesn't matter what version I use. I have the same problem with all the mactrack versions.

DEBUG: VLAN Analysis for VLAN: 1000/Backup_VLAN is complete. ACTIVE PORTS: 2
DEBUG: Processing has begun for VLAN: 1
Timeout: No Response from ops-as-07.abc.com:161
DEBUG: Port number information collected.
DEBUG: No user ports on this network.
DEBUG: Bridge port information about to be collected.
DEBUG: VLAN_ID: 1, VLAN_NAME: default, ACTIVE PORTS: 0

-lance

Witness,

Off the top of your head, at the point I am dying is it doing a snmpbulkwalk instead of a snmpwalk? I just tried the two via the net-snmp package on a 4006 against the OID '.1.3.6.1.2.1.17.4.3.1.1' aka the MAC provided via Hex-STRING. The snmpbulkwalk reached a timeout but the snmpwalk never reached a timeout. I increased the timeout to 30 seconds and snmpbulkwalk did not timeout. So I conclude snmpbulkwalk needs a lot more time than the default to complete.

To further verify if snmpbulkwalk also creates other problems ('unable to create SNMP sessions' to the device which mactrack is querying) that I see from other SNMP monitoring devices I duplicated a senario assuming snmpbulkwalk is what mactrack uses at the particular point which I timeout.

I opened 2 sessions. Session A and Session B. In session A I did a query as such 'snmpbulkwalk -t 30 -c public@107 -v2c ops-as-07 .1.3.6.1.2.1.17.4.3.1.1' and then switched to session B and did a query of such 'snmpwalk -t 30 -c public@107 -v2c ops-as-07 iftable'. The snmpbulkwalk did finish but that was a rather small set of MAC addresses it would return (140 to be exact), while the snmpwalk was completely crippled by the snmpbulkwalk eating up all the processor and only allow the snmpwalk to return data back about every 1/3 to 1/2 of a second. Normally data returns with a snmpwalk in about 1/8 of a second or less when running along or while running at the same time as other snmpwalks.

##
##Processor when running snmpbulkwalk and snmpwalk
##
CPU utilization for five seconds: 91.36%
one minute: 51.39%
five minutes: 38.89%

##
##Processor when running snmpwalk and snmpwalk
##
CPU utilization for five seconds: 78.63%
one minute: 54.08%
five minutes: 49.50%

Hopefully this will pinpoint the issue. Not sure myself but I am tired and retiring from SNMP work tonight.

-Lance

[TheWitness]

Jerome,

Did you attempt the database_upgrade.php?

Lavermil,

What version of PHP are you running?

TheWitness

[Tramjoe]

Witness,

The install is done properly (even redone from scratch with DB schema source from mactrack.sql).

Here is a little bit more detail about the problems I met/fixed (all with release 246 from CVS), please see the attached patch file :

- mac_track_temp_ports was causing problem when used as a memory table. I converted it (and all other memory tables) to MyISAM. What happened is that the table was populated by the poller processes, but became empty before it could get copied over to mac_track_ports. Now it works.

- given the previous issue, I changed also all other HEAP/MEMORY tables to MyISAM (paranoia setting

- I copied over the generic switch port function to superstackII_switch_ports, and declared it for future modification (I want to add VLANS, trunk detection, etc. to it.)

- added some more debug to places like mactrack_scanner.php

- creation of sites and device_types was buggy, this is fixed in mactrack_functions.php (lack of an argument in mactrack_device_types.php, c.f. patch, and mismatch between site_information and site_info used in setup.php and the rest of the code).

- my first try was with 3com superstack switches, for which get_generic_dot1q_switch_ports is nonfunctionnal. It is working OK with get_generic_switch_port, but lacks VLAN info, trunk info and port name=). I'll investigate/work on that later.

Anyways, thanks for the great tool, keep up the good work

Jerome Martin

[lavermil]

Jerome,

Did you attempt the database_upgrade.php?

Lavermil,

What version of PHP are you running?

TheWitness

Witness,

I was running PHP4, so I upgraded to php5.03 (the latest for suse 9.3 via RPM). I am still getting the timeouts after the upgrade. No different.

PHP 5.0.3 (cli) (built: Nov 7 2006 14:26:08)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.3, Copyright (c) 1998-2004 Zend Technologies

net-snmp-5.2.1-5.2

-Lance

[TheWitness]

Lance,

In order to utilize the snmpbulk functions in PHP, which will speed the polling dramatically and low load average as well, you must be running PHP 5.1.x and above. Also the module PHP_SNMP must be installed.

When I was at my last job, I was able to run 26 concurrent processes at 25% CPU on a 4 way Xeon 3.06GHz box.

Try that and see what happens

TheWitness

[lavermil]

I will look at compiling in 5.1. I am going to have a hell of a time trying to compile in all the crap I need. There is no 5.1 release in RPM for suse 9.3 that I can find. Which means I will have to do a lot of compiling. Hopefully it will all go in just fine. Unfortuantely that is a steep requirement so some. Is there a way to only run smpwalks and not run the snmpbulkwalks? Like maybe a flag or something in the settings.

BTW, the CPU utilization was for the switches, not the server. The server gets beat up too, but that is the least of my worries.

Thankx again.

-Lance