-
I tried your patch today, but have some problems to see useful output. The discover didn't work from start...
SNMP::Info::AUTOLOAD(agg_ports) Attribute not found in this device class. at ./netdisco line 2388
...but I could solve this after changing C6500.pm. Now I get some more info.
SNMP::Info::_load_attr pagp_group_index : pagpGroupIfIndex
SNMP::Info::_load_attr agg_port_id ...
2007-07-16 14:33:36 UTC in SNMP::Info
-
I had the problem that the nightly db cleanup took more than 4 hours after upgrading from 0.94 to 0.96-cvs (~10 minutes before).
One part of the solution was a change of the sql statement in db_clean. This saved ~1 hour of time. The main time was saved with an full vacuum of the netdisco db. auto vacuum is enabled, and I've no idea why it was not working effective. Maybe because I migrated...
2007-06-18 16:20:36 UTC in Netdisco
-
I just received a couple of mails from the bacula user list. But yet none of the two mails I sent to the list yesterday. I'll wait and see what happens next...
2007-06-12 21:41:48 UTC in SourceForge.net
-
Anything new? It seems that a lot of sf lists are affeced, wouldn't it be a good idea to place some information on the
'SourceForge.net Site Status' page?.
2007-06-12 10:46:37 UTC in SourceForge.net
-
Hi,
last mail I got from the bacula user mailing list is still from: Jun 09 14:08
I sent a new mail to the list a couple of minutes ago, but didn't see the mail reaching the list.
Ralf.
2007-06-11 17:31:19 UTC in SourceForge.net
-
Hi,
it seems that the bacula user mailing list ist dead since 2007-06-09. I don't get any mails anymore. I sent one mail the list today, but the mail never reached the list.
Kern Sibbald (bacula author) confirmed that he doesn't get mails too. sf and gmane archives doesn't show any recent mails too.
2007-06-11 13:04:42 UTC in SourceForge.net
-
seems to work well.
[...]
SNMP::Info::_load_attr c_platform : cdpCachePlatform
[x.62.96.11] Adding x.62.96.3 to discovery queue.
[x.62.96.11] Adding x.62.96.2 to discovery queue.
[x.62.96.11] x.62.96.77 excluded by discover_no_type.
[x.62.96.11] x.62.96.76 excluded by discover_no_type.
[x.62.96.11] 4 Neighbors.
[x.62.96.3] Discover starting
get_device(x.62.96.3)
! x.62.96.3...
2007-05-16 20:28:55 UTC in Netdisco
-
Hm, I'm not sure what this part of the patch is good for, but if I change $ok_to_discover to 1, it's working again. During a discovery netdisco has to follow all devices, regardless if they are already known or not ;) Maybe this part is not needed at all?
unless (defined $Discovered{$remote_ip}) {
$DEBUG and print "[$ip] $remote_ip already seen.\n";...
2007-05-16 07:41:40 UTC in Netdisco
-
Thanks for the patch. It is working, but I think it somehow breaks the network discovery. netdisco is not adding any devices to the discovery queue anymore (already seen, excluded by discover_no_type) and does not junp to next device.
With the unpatched 0.96 it discovers the whole network.
./netdisco -r x.62.96.11
n e t d i s c o
--------------------------------------------------...
2007-05-16 07:26:00 UTC in Netdisco
-
We've ~500 Cisco AIR-LAP1242AG-E-K9 which can't be reached by snmp but show up as cdp neighbors. Netdisco tries to discover them and fails after a timeout. I've listed several hundred IPs in discover_no at the moment.
If I could add the CDP model information to discover_no would help a lot.
This is what I see as connected device is netdisco:
x.x.x.x (FastEthernet0)
(cisco...
2007-05-15 19:06:24 UTC in Netdisco
