Ok. All are this class:
SNMP::Info::Layer3::IBMGbTor
I'm not 100% sure if that's correct, the non working 2 have MIBs
that
have specific names:
GbTOR-G8264.mib
GbTOR-G8052.mib
These come with the firmware download for the switches.
Here's some data:
(G8124, good)
$ netdisco-do show -d x.x.x.19 -DI -e Layer3::IBMGbTor::os_ver
[3259] 2017-07-12 14:47:15 info show: started at Wed Jul 12
14:47:15
2017
[3259] 2017-07-12 14:47:15 debug [x.x.x.19] try_connect with ver:
2,
class: SNMP::Info::Layer3::IBMGbTor, comm: <hidden>
SNMP::Info::_global uptime : DISMAN-EVENT-MIB::sysUpTimeInstance :
.1.3.6.1.2.1.1.3.0
SNMP::Info::_global layers : SNMPv2-MIB::sysServices.0 :
.1.3.6.1.2.1.1.7.0
SNMP::Info::_global agSoftwareVersion :
IBM-GbTOR-10G-L2L3-MIB::agSoftwareVersion.0 :
.1.3.6.1.4.1.26543.2.7.4.1.1.1.10.0
"7.11.10" <------------- BINGO
[3259] 2017-07-12 14:47:16 info show: finished at Wed Jul 12
14:47:16
2017
[3259] 2017-07-12 14:47:16 info show: status done: Showed os_ver
response from x.x.x.19.
(G8264, bad)
$ netdisco-do show -d x.x.x.18 -DI -e Layer3::IBMGbTor::os_ver
[3441] 2017-07-12 14:47:26 info show: started at Wed Jul 12
14:47:26
2017
[3441] 2017-07-12 14:47:26 debug [x.x.x.18] try_connect with ver:
2,
class: SNMP::Info::Layer3::IBMGbTor, comm: <hidden>
SNMP::Info::_global uptime : DISMAN-EVENT-MIB::sysUpTimeInstance :
.1.3.6.1.2.1.1.3.0
SNMP::Info::_global layers : SNMPv2-MIB::sysServices.0 :
.1.3.6.1.2.1.1.7.0
SNMP::Info::_global agSoftwareVersion :
IBM-GbTOR-10G-L2L3-MIB::agSoftwareVersion.0 :
.1.3.6.1.4.1.26543.2.7.4.1.1.1.10.0
SNMP::Info::_validate_autoload_method(CARP_TRACE) Unable to resolve
method.
SNMP::Info::_global(agSoftwareVersion) NOSUCHOBJECT at
/home/netdisco/bin/netdisco-do line 142.
[3441] 2017-07-12 14:47:27 info show: finished at Wed Jul 12
14:47:27
2017
[3441] 2017-07-12 14:47:27 info show: status error: error running
job: When calling p() without prototypes, please pass arguments as
references at /home/netdisco/bin/netdisco-do line 142.
(G8052, bad)
$ netdisco-do show -d x.x.x.17 -DI -e Layer3::IBMGbTor::os_ver
[4825] 2017-07-12 15:18:45 info show: started at Wed Jul 12
15:18:45
2017
[4825] 2017-07-12 15:18:45 debug [x.x.x.17] try_connect with ver:
2,
class: SNMP::Info::Layer3::IBMGbTor, comm: <hidden>
SNMP::Info::_global uptime : DISMAN-EVENT-MIB::sysUpTimeInstance :
.1.3.6.1.2.1.1.3.0
SNMP::Info::_global layers : SNMPv2-MIB::sysServices.0 :
.1.3.6.1.2.1.1.7.0
SNMP::Info::_global agSoftwareVersion :
IBM-GbTOR-10G-L2L3-MIB::agSoftwareVersion.0 :
.1.3.6.1.4.1.26543.2.7.4.1.1.1.10.0
SNMP::Info::_validate_autoload_method(CARP_TRACE) Unable to resolve
method.
SNMP::Info::_global(agSoftwareVersion) NOSUCHOBJECT at
/home/netdisco/bin/netdisco-do line 142.
[4825] 2017-07-12 15:18:45 info show: finished at Wed Jul 12
15:18:45
2017
[4825] 2017-07-12 15:18:45 info show: status error: error running
job: When calling p() without prototypes, please pass arguments as
references at /home/netdisco/bin/netdisco-do line 142.
I can keep working on this as long as I can figure it out.
Andy
On Wed, Jul 12, 2017 at 7:34 AM, Oliver Gorwits <[email protected]>
wrote:
Hi Andy,
On 2017-07-12 15:09, Andy Ruhl wrote:
Thanks for your help yesterday Oliver.
:-)
I have 2 switches that have always had blank os_ver fields.
Based on yesterday's troubleshooting, I tried the same stuff but
I'm
not getting anywhere.
I would start with the one which is working, and find the Device
Class
which
SNMP::Info is using: either from the device table in the database
or
the
Device Class field shown in Device -> Details tab in the web.
Find the source file for that online somewhere here:
https://metacpan.org/release/SNMP-Info
Look for an os_ver() subroutine, and see what it's doing. Perhaps
it
pulls
agSoftwareVersion which works for that model.
The other thing to do is check which Device Class the *not
working*
devices
are being assigned. Hopefully the same as the working device.
If not, then it may be a case of updating the rules in
SNMP/Info.pm
which
assign the Device Classes. You can force a device class for
testing (we
strip SNMP::Info from the front of the classname):
~netdisco/bin/netdisco-do show -d 1.2.3.4 -e Layer3::HP::os_ver
If the device class is correct for the not-working devices, then
it'll
probably be related to which SNMP leaf to get. As in the JUNOS
software
version example you had before, sometimes we need to fetch a
couple of
leaves and try them in turn.
regards,
oliver.
Here is some psql info:
model | vendor | os_ver
--------------+---------+---------------
G8052 | ibm |
G8264, Stack | ibm |
G8124-E | ibm | 7.11.10
The G8124-E is the only switch that has ever had a populated
os_ver
field, it never worked for the others.
So I did discover with -DISQ and I don't see a version string
anywhere
in the output that looks like "7.11.10".
I did notice this for 8052 and 8264 devices:
SNMP::Info::_global(agSoftwareVersion) NOSUCHOBJECT at
/home/netdisco/perl5/lib/perl5/App/Netdisco/Core/Discover.pm line
186.
Any hints on how to continue for this one?
Thanks.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Netdisco mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Netdisco mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Netdisco mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
