Send netdisco-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/netdisco-users
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of netdisco-users digest..."
Today's Topics:
1. Re: Changing default GUI behavior (Andy Ruhl)
2. Re: ND2 Worker configuration and Server Performance problems
(Oliver Gorwits)
3. Question on snmpforce_v3 (Jim Glassford)
4. Re: Question on snmpforce_v3 (Oliver Gorwits)
5. Re: Question on snmpforce_v3 (Oliver Gorwits)
6. Re: [Ext] Re: Question on snmpforce_v3 (Jim Glassford)
7. Re: [Ext] Re: Question on snmpforce_v3 (Oliver Gorwits)
8. Re: ND2 Worker configuration and Server Performance problems
(Tobias Gerlach)
--- Begin Message ---
I set it to -1 in deployments.yml and so far it seems to be working.
Thanks as always Oliver.
Andy
--- End Message ---
--- Begin Message ---
Thanks Tobias.
So it looks like the LLDP implementation on these devices is either not
compliant with standards or else (less likely) tripping up the
SNMP::Info module in some way.
We can investigate further by asking Netdisco to grab just the
problematic data item:
~netdisco/bin/netdisco-do show -d 10.133.107.200 -e lldp_rem_pid_type
-DI
I suspect this will have the same outcome.... it will run for a very
long time.
You could try to disable BULKWALK for this device, which sometimes
causes loops or other strange behaviour in SNMP table walks:
bulkwalk_no:
- 10.133.107.200
Arguably Netdisco should have some constraint for job time (this
reminds me that we didn't implement a master "timout" setting to abort
long-running jobs - I'll open a ticket for that). Equally, SNMP::Info
could implement a timeout at an individual SNMP call level, to abort
problematic calls and return empty data (which Netdisco copes with quite
well).
regards,
oliver.
On 2015-04-30 12:33, Tobias Gerlach wrote:
as you suggested I stopped the netdisco-daemon and run the same
discover job for that particular device 10.133.107.200 from the
command line.
After about 4 hours I stopped the job because the switch still wasn't
fully discovered. It hangs hours in collecting the LLDP information
from the device (at the positions "Looping on: ..." in the debug
log).
I'm wondering that ND is not aborting collecting that information
after a specified timeout and continues with collection rest of the
MIB information. Between each "Looping on: ..." entry about an hour
nothing happend and ND was waiting to get the requested information
from the device.
I also logged the process and memory at the start and close before I
stopped the discovery job. RSS and VSZ are increasing during that
time
by a factor of 5 respectively 3.
Is it a normal behaviour?
Looping on: lldp_rem_pid_type iid:3784541.4.6. at
/usr/local/netdisco/perl5/lib/perl5/App/Netdisco/Core/Discover.pm
line
697
SNMP::Info::_load_attr lldp_rem_sysdesc : LLDP-MIB::lldpRemSysDesc :
.1.0.8802.1.1.2.1.4.1.1.10
^C
netdisco@server:~>
--- End Message ---
--- Begin Message ---
Greetings,
Running 2.032001, this is working excellent, thank-you all for all your
work.
Attempting to move off SNMVv1/v2 and do all v3 now.
Three questions:
1) Do I have snmpforce_v3 correct in deployment.yml, shown below?
2) Would it be a safe and quick way to force v3, maybe write a 3 in to
the db for snmp_ver?
3) If OK to write a 3, should I blank out the snmp_ver?
In deployment.yml I currently have only the following for SNMP, want to
force version 3, is this the correct format?
# SNMP community string(s)
# ````````````````````````
snmp_auth:
*snmpforce_v3:*
- tag: 'v3WriteReadTesting'
user: v3TestingReadTestingWrite
auth:
pass: 'apasswordhere'
proto: SHA
priv:
pass: 'ahashfordeshere'
proto: DES
read: true
write: true
720 devices and most seem to work OK from the CLI for discover, ports
down/up, others I have issues doing writes. I am suspecting it is due to
cached v1 and community strings in the db? Trying to avoid removing a
bunch and re-discovering but can do but thought I would check. I
scripted a bunch for down/up, they work but I do not see the db getting
updated for snmp_ver = 3 for the ones I ran through.
# bin/netdisco-do psql -e 'SELECT dns, snmp_ver, snmp_comm, snmp_class
FROM device'
~sample (almost all are still showing 2)
abc | 2 | OldReadOnly | SNMP::Info::Layer2::HP
def | 3 | OldReadOnly | SNMP::Info::Layer2::HP
ghi | 2 | OldReadOnly | SNMP::Info::Layer3::C6500
jkl | 3 | OldReadOnly | SNMP::Info::Layer3::C6500
xyz | 2 | OldReadOnly | SNMP::Info::Layer3::Nexus
I do still have the OldReadOnly community set on all my devices, still
need for our old management system, around for a couple more months,
disco still seems to try and using it sometimes or public and private.
Sniffing the wire on a problem switch with the above snmp config I see
"private" sent to up/down a port. If I delete the problem switch and
then discover again, I can down/up ports using v3 A OK and do see only
the v3 on the wire.
thanks!
jim
--- End Message ---
--- Begin Message ---
Hi Jim,
On 2015-04-30 16:19, Jim Glassford wrote:
1) Do I have snmpforce_v3 correct in deployment.yml, shown below?
I don't think so. snmpforce_* are simple access control lists, so they
take a list of IPs, prefixes or subnets or even device properties
(model, vendor - but obviously the device must already be known for this
to help SNMP connect).
So you should separate out snmpforce_v3 such as:
snmpforce_v3:
- 192.0.2.1
- 192.0.2.2
snmp_auth:
- tag: v3WriteReadTesting
- ...etc
I need to refresh my memory on how Netdisco behaves in changing the
SNMP version for a known device. Hopefully it's as you want, which is to
enable changing the version without delete+rediscover. If not, I'll open
a ticket!
regards,
oliver.
In deployment.yml I currently have only the following for SNMP, want
to force version 3, is this the correct format?
# SNMP community string(s)
# ````````````````````````
snmp_auth:
SNMPFORCE_V3:
- tag: 'v3WriteReadTesting'
user: v3TestingReadTestingWrite
auth:
pass: 'apasswordhere'
proto: SHA
priv:
pass: 'ahashfordeshere'
proto: DES
read: true
write: true
--- End Message ---
--- Begin Message ---
On 2015-05-01 08:07, Oliver Gorwits wrote:
I need to refresh my memory on how Netdisco behaves in changing the
SNMP version for a known device. Hopefully it's as you want, which is
to
enable changing the version without delete+rediscover. If not, I'll
open
a ticket!
Seems that Netdisco will take into account your snmpforce config and
apply it the next time it needs to connect to a device.
So, please let us know how you get on with the migration (based on my
earlier config example), it'd be good to know.
regards,
oliver.
--- End Message ---
--- Begin Message ---
Hi Oliver,
Thanks, working correctly, I just needed smacked with a larger clue
stick. :-)
Added my prefixes under snmpforce_v3: and now running snmpv3 only now.
Really appreciated!
jim
On 5/1/2015 3:07 AM, Oliver Gorwits wrote:
Hi Jim,
On 2015-04-30 16:19, Jim Glassford wrote:
1) Do I have snmpforce_v3 correct in deployment.yml, shown below?
I don't think so. snmpforce_* are simple access control lists, so they
take a list of IPs, prefixes or subnets or even device properties
(model, vendor - but obviously the device must already be known for this
to help SNMP connect).
So you should separate out snmpforce_v3 such as:
snmpforce_v3:
- 192.0.2.1
- 192.0.2.2
snmp_auth:
- tag: v3WriteReadTesting
- ...etc
I need to refresh my memory on how Netdisco behaves in changing the
SNMP version for a known device. Hopefully it's as you want, which is to
enable changing the version without delete+rediscover. If not, I'll open
a ticket!
regards,
oliver.
In deployment.yml I currently have only the following for SNMP, want
to force version 3, is this the correct format?
# SNMP community string(s)
# ````````````````````````
snmp_auth:
SNMPFORCE_V3:
- tag: 'v3WriteReadTesting'
user: v3TestingReadTestingWrite
auth:
pass: 'apasswordhere'
proto: SHA
priv:
pass: 'ahashfordeshere'
proto: DES
read: true
write: true
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Netdisco mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
--- End Message ---
--- Begin Message ---
On 2015-05-01 12:52, Jim Glassford wrote:
Thanks, working correctly, I just needed smacked with a larger clue
stick. :-)
Added my prefixes under snmpforce_v3: and now running snmpv3 only
now.
Good to hear, thanks for letting us know :).
regards,
oliver.
--- End Message ---
--- Begin Message ---
You are right Oliver, the behavior is the same when I just poll the
LLDP-MIB. The poller runs for a very long time.
I assume that LLDP is not activated on that device. When I deactivate
BULKWALK I got errors like this:
SNMP::Info::_global lldp_sys_cap : LLDP-MIB::lldpLocSysCapEnabled.0 :
.1.0.8802.1.1.2.1.3.6.0
SNMP::Info::_global(lldp_sys_cap) NOSUCHOBJECT at
/usr/local/netdisco/perl5/lib/perl5/App/Netdisco/Core/Discover.pm line
689
The good thing is that then the poller continues discovering the
device and doesn’t suspend the whole discovery process.
I would really appreciate if you could implement a function like a
master "timout" to prevent such long-running jobs.
I currently manage about 5500 devices with one ND2 installation and it
is not surprising me that there are some devices which have a buggy
SNMP configuration or agent running, but that should not affect the
whole network discovery of all other devices.
--- End Message ---
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Netdisco mailing list - Digest Mode
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
