Send netdisco-users mailing list submissions to
netdisco-users@lists.sourceforge.net
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
netdisco-users-requ...@lists.sourceforge.net
You can reach the person managing the list at
netdisco-users-ow...@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of netdisco-users digest..."
Today's Topics:
1. Re: Netdisco 2 - port name problem (Edward Vopata)
2. Scheduling SSHCollector (Steven Xu)
3. Re: Scheduling SSHCollector (Oliver Gorwits)
4. Serial number on Nexus 9372 and Cisco 4500X (Caines, Max)
5. Serial number on Nexus 9372 (Caines, Max)
--- Begin Message ---
Yes. ND1 and ND2 are on separate host, separate databases.
The SNMP versions are fairly consistent between the list of hosts.
Primarily SNMP version 2, some version 1.
The timeout values are probably different between ND1 and ND2.
I've tired adjusting the timeout values, but I haven't had much success.
ND1:
snmptimeout = 1000000
ND2:
## Timeout = -t 20 ??
snmptimeout: 20000000
snmpretries: 3
snmpver: 2
Bulkwalk:
snmpbulkwalk -v2c -t 1 -c {comm} {host} .1
-- Timeout
snmpbulkwalk -v2c -t 2 -c {comm} {host} .1
-- Completes
snmpbulkwalk -v2c -t 10 -c {comm} {host} .1
-- Completes
But what really bothers me is that, if the query fails or times-out,
then it should fail <PERIOD>
and NOT write write bad data to the database.
On 04/22/16 04:21, Jeroen van Ingen wrote:
Hi Edward,
Even though ND1 works fine, there must be a reason why you're having
these issues with ND2. The core logic hasn't really changed, so I'm
trying to figure out what the root cause may be and what could be
different between your ND1 and ND2 setup.
I'm assuming that you're running ND1 and ND2 on two separate hosts,
each with their own database. Is that correct? Would you mind
comparing a few devices between your ND1 and ND2 database to see
whether both use the same SNMP version?
The timeouts during bulkwalk shouldn't happen, so that's worth further
investigation. Do you have the same timeout values configured in ND1
and ND2? When doing consecutive snmpbulkwalks from the CLI, can you
experiment with higher timeout values (-t option for snmpbulkwalk) and
see what timeout is needed to get full results each time?
Regards,
Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands
--- End Message ---
--- Begin Message ---
Hi all,
What's the conventional way of scheduling SSHCollector? Right now, I think scheduling it as a cron job seems to be the only way, and it doesn't look like there's a configuration option.
Steven
--- End Message ---
--- Begin Message ---
Hi Steven,
On 2016-04-26 20:01, Steven Xu wrote:
What's the conventional way of scheduling SSHCollector? Right now, I
think scheduling it as a cron job seems to be the only way, and it
doesn't look like there's a configuration option.
You're right, it's just cron.
regards,
oliver.
--- End Message ---
--- Begin Message ---
Hi
I've been having problems for a while with missing serial numbers on the
details of our switches of these types. I had a bit of time, so I did some
investigation. This what I found:
Nexus 9372PX
These are running 7.0(3)I2(2a). The problem here is that an SNMP walk on the
table entPhysicalContainedIn (.1.3.6.1.2.1.47.1.1.1.1.4) shows that it does not
contain a zero value at all. This should not be possible, as the MIB says there
has to be a root entry whose value is zero, but actually the lowest value is 1.
So I guess it's a Cisco bug. I've no idea whether it's a known one, but I'll
try to get it submitted. The result is that when the serial() routine in
SNMP::Info::Nexus looks for the root module (whose parent is 0), it can't find
one, and returns a null string. For my own benefit I've kludged this by
changing line 90 from:
if ( $parent eq '0' ) {
to
if ( $parent le '1') {
On all our 9372s this gives the right result, and it doesn't seem to break
things on our 5010 or 3524 Nexus switches, so I guess the 9372s are using 1 as
the root module number, and the other two don't use that value at all, but one
couldn't rely on this. Another effect which is probably linked to this is that
selecting the "Modules" tab for a 9372 switch gives a blank page, presumably
because the code can't find the root module to start from.
Cisco 4500X
These are running 3.7.1E. What I'm finding here is that the serial() routine in
SNMP::Info::Layer3 looks at the root module, whose entPhysicalContainedIn value
is zero, and if it has a value for "serial", uses that in preference to the one
on the chassis (.1.3.6.1.4.1.9.3.6.3.0, which is in fact correct). However,
although the serial attribute of the root module exists, it's blank. This is
the code:
my $parent = $e_parent->{$iid};
if ( $parent eq '0' ) {
my $serial = $l3->e_serial($iid);
if ( $serial ) {
return $serial->{$iid};
}
I've fixed it by changing:
if ( $serial ) {
to
if ( $serial && $serial->{iid} ) {
to ensure that a serial number is only taken from the root module if it has a
value.
I suspect the problem here is that this switch is in a VSS pair, and the root
module in a VSS pair is:
Cisco Systems, Inc. Virtual Switch Device (Virtual Stack) /
cevStackCat4xxxVirtualSwitchStack
according to Netdisco itself, so it won't have a serial number. So I think this
could do with a fix to SNMP::Info.
Hope this is of use to someone
Regards
Max
Max Caines | Network Design Consultant | IT Services | Directorate of Academic
Support | University of Wolverhampton | 01902 322245 | 07976 841874
For contact details and general information on IT Services please visit en the
serial() <http://www.wlv.ac.uk/its> This email, together with any attachment,
is for the exclusive and confidential use of the addressee(s) and may contain
legally privileged information. If you receive this email in error, please
visit http://www.wlv.ac.uk/ITS-disclaimer . Please consider the environment
before printing this e-mail.
--- End Message ---
--- Begin Message ---
Hi
I have now had it confirmed that there is a bug in a the Nexus 9000 series
software that causes the entPhysicalContainedIn (.1.3.6.1.2.1.47.1.1.1.1.4)
table to contain 1 in the row that refers to the root fabric rather than 0.
This causes Netdisco to fail to find the serial number for the switch. The
Cisco bug is CSCuy20251, and it's fixed in 7.0(3)I2(3)
Regards
Max
Max Caines | Network Design Consultant | IT Services | Directorate of Academic
Support | University of Wolverhampton | 01902 322245 | 07976 841874
For contact details and general information on IT Services please visit en the
serial() This email, together with any attachment, is for the exclusive and
confidential use of the addressee(s) and may contain legally privileged
information. If you receive this email in error, please visit
http://www.wlv.ac.uk/ITS-disclaimer . Please consider the environment before
printing this e-mail.
--- End Message ---
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Netdisco mailing list - Digest Mode
netdisco-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/netdisco-users
