13 Replies Latest reply on Jul 17, 2018 3:10 AM by Arne Kaj Winther

    scaning Oracle ILOM's with snmp v3

    Arne Kaj Winther

      Hi Community

      Got a question about why I get this Oracle ILOM's scanned filly with snmp v3, the access is OK but getIPAddresses and getNetworkinterfaces fails. I'v some there is scanned with snmp v2, and they do fail with this ??. Is there something I have to configure on the one scanned with snmp v3 ??

       

      snmp v3:

      snmp v2:

        • 1. Re: scaning Oracle ILOM's with snmp v3
          Saurabh Thuse

          You need to turn on debug logging. Then scan device again to check what is in the tw_svc_discovery.log

          2 of 2 people found this helpful
          • 2. Re: scaning Oracle ILOM's with snmp v3
            Arne Kaj Winther

            Hi Saurabh

             

            OK, I’ll copy in the result on the DEBUG scan of one of the ILOM’s:

             

            Best regards,

            Arne

             

            140716173903616: 2018-07-13 13:01:38,256: discovery.pool: DEBUG: No pool data for 10.190.172.89 - nothing to clear

            140716173903616: 2018-07-13 13:01:38,256: discovery.pool: DEBUG: 10.190.172.89: No directory /usr/tideway/var/pool/10/190/172/89 therefore no data in pool

            140716173903616: 2018-07-13 13:01:38,256: discovery.nmap: DEBUG: preScan: scanning 1 address

            140716320761600: 2018-07-13 13:01:38,257: discovery.nmap: DEBUG: preScan: command

            140716320761600: 2018-07-13 13:01:38,277: common.process: DEBUG: Adding process 7250 to timeout thread, timeout = 900

            140716320761600: 2018-07-13 13:01:40,589: common.process: DEBUG: Removing process 7250 from timeout thread

            140716320761600: 2018-07-13 13:01:48,283: discovery.servants: INFO: Main_i::getDevice() for 10.190.172.89

            140716320761600: 2018-07-13 13:01:48,283: discovery.servants: DEBUG: Main_i::getDevice() - try cache lookup for 10.190.172.89

            140716320761600: 2018-07-13 13:01:48,283: discovery.servants: DEBUG: Main_i::getDevice() - get new device for 10.190.172.89

            140716320761600: 2018-07-13 13:01:48,283: discovery.device: INFO: 10.190.172.89: Try to get device

            140716320761600: 2018-07-13 13:01:48,283: discovery.device: DEBUG: 10.190.172.89: device hints = {'last_access_method': 'snmp', 'credentials_used': KVPDict({'snmp': '18440c365ab8a57627fa0a4c896709ca'}), 'last_credential': '18440c365ab8a57627fa0a4c896709ca'}

            140716320761600: 2018-07-13 13:01:48,284: discovery.device: INFO: 10.190.172.89: Try pool heuristic

            140716320761600: 2018-07-13 13:01:48,284: discovery.heuristics.pool: DEBUG: Pool Heuristic: 10.190.172.89: Checking pool state

            140716320761600: 2018-07-13 13:01:48,284: discovery.heuristics.pool: DEBUG: Pool Heuristic: :10.190.172.89: Pool state OK to continue

            140716320761600: 2018-07-13 13:01:48,284: discovery.device: INFO: 10.190.172.89: Try lastvsphere heuristic

            140716320761600: 2018-07-13 13:01:48,284: discovery.heuristics.lastvsphere: DEBUG: Last vSphere Heuristic: 10.190.172.89: Last vSphere not possible: last access was not via vSphere

            140716320761600: 2018-07-13 13:01:48,284: discovery.device: INFO: 10.190.172.89: Try lastvcenter heuristic

            140716320761600: 2018-07-13 13:01:48,284: discovery.heuristics.lastvcenter: DEBUG: Last vCenter Heuristic: 10.190.172.89: Last vCenter not possible: last access was not via vCenter

            140716320761600: 2018-07-13 13:01:48,284: discovery.device: INFO: 10.190.172.89: Try lastlogin heuristic

            140716320761600: 2018-07-13 13:01:48,285: discovery.heuristics.lastlogin: DEBUG: Last Login Heuristic: 10.190.172.89: Last Login not possible: last access was not a login

            140716320761600: 2018-07-13 13:01:48,285: discovery.device: INFO: 10.190.172.89: Try lastslave heuristic

            140716320761600: 2018-07-13 13:01:48,285: discovery.heuristics.lastslave: DEBUG: Last Windows Proxy Heuristic: 10.190.172.89: not via a Windows Proxy

            140716320761600: 2018-07-13 13:01:48,285: discovery.device: INFO: 10.190.172.89: Try lastwebapi heuristic

            140716320761600: 2018-07-13 13:01:48,285: discovery.heuristics.lastwebapi: DEBUG: Last Web API Heuristic: 10.190.172.89: Last Web API not possible: last access was not Web API

            140716320761600: 2018-07-13 13:01:48,285: discovery.device: INFO: 10.190.172.89: Try lastsnmp heuristic

            140716320761600: 2018-07-13 13:01:48,298: discovery.heuristics.lastsnmp: DEBUG: Last SNMP Heuristic: 10.190.172.89: Try Last SNMP Heuristic

            140716320761600: 2018-07-13 13:01:48,299: discovery.snmp.peer: DEBUG: 10.190.172.89: get 1.3.6.1.2.1.1.1.0, 1.3.6.1.2.1.1.2.0

            140716320761600: 2018-07-13 13:01:48,299: discovery.snmp.peer: DEBUG: 10.190.172.89: GET via SNMP++: OIDs = 1.3.6.1.2.1.1.1.0, 1.3.6.1.2.1.1.2.0

            140716320761600: 2018-07-13 13:01:48,365: discovery.heuristics.snmp: DEBUG: identifyDevice: 10.190.172.89: Got sysObjectID=1.3.6.1.4.1.42.2.200

            140716320761600: 2018-07-13 13:01:48,365: discovery.heuristics.snmp: DEBUG: identifyDevice: 10.190.172.89: modelinfo => {'sysObjectID': '1.3.6.1.4.1.42.2.200', 'capability_ids': , 'vendor': 'Oracle', 'branch': 'ilom', 'snmp': <discovery.devices.engine.EngineConfiguration object at 0x7ffb02e681d0>, 'kind': 'ManagementController', 'module': 'oracle', 'testing_status': 'EXACT', 'internal': {'allow_zero_mac_addresses': True, 'custom': False}, 'device_type': 'Chassis Management Controller', 'model': 'Sun Blade 6000 ILOM'}

            140716320761600: 2018-07-13 13:01:48,365: discovery.heuristics.snmp: DEBUG: identifyDevice: 10.190.172.89: classification {'kind': 'ManagementController', 'capability_ids': , 'vendor': 'Oracle', 'device_type': 'Chassis Management Controller', 'snmp': , (), {})

            140716320761600: 2018-07-13 13:01:48,368: discovery.servants: DEBUG: Main_i::_updateDeviceCache() - using new device; total devices now 1

            140716320761600: 2018-07-13 13:01:48,368: discovery.servants: INFO: finished Main_i::getDevice() for 10.190.172.89

            140716320761600: 2018-07-13 13:01:48,368: discovery.device: INFO: ManagementController_i::getDeviceInfo() for 10.190.172.89

            140716320761600: 2018-07-13 13:01:48,369: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: OracleIlom::getDeviceInfo()

            140716320761600: 2018-07-13 13:01:48,369: api.audit: DEBUG: 10.190.172.89: getDeviceInfo(): Try pool

            140716320761600: 2018-07-13 13:01:48,369: discovery.pool: DEBUG: 10.190.172.89: No directory /usr/tideway/var/pool/10/190/172/89 therefore no data in pool

            140716320761600: 2018-07-13 13:01:48,369: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: getDeviceInfo(): execute queries

            140716320761600: 2018-07-13 13:01:48,369: discovery.devices.engine: DEBUG: 10.190.172.89: getDeviceInfo(): query scalars

            140716320761600: 2018-07-13 13:01:48,369: discovery.devices.engine: DEBUG: 10.190.172.89: getDeviceInfo(): have 10 scalars to query

            140716320761600: 2018-07-13 13:01:48,369: discovery.snmp.peer: DEBUG: 10.190.172.89: get 1.3.6.1.2.1.1.1.0, 1.3.6.1.2.1.1.2.0, 1.3.6.1.2.1.1.4.0, 1.3.6.1.2.1.1.5.0, 1.3.6.1.2.1.1.6.0, 1.3.6.1.4.1.42.2.175.102.15.2.14.0, 1.3.6.1.4.1.42.2.175.102.15.2.15.0, 1.3.6.1.4.1.42.2.175.102.16.1.0, 1.3.6.1.4.1.42.2.175.102.16.2.0, 1.3.6.1.4.1.42.2.175.102.6.2.0

            140716320761600: 2018-07-13 13:01:48,370: discovery.snmp.peer: DEBUG: 10.190.172.89: GET via SNMP++: OIDs = 1.3.6.1.2.1.1.1.0, 1.3.6.1.2.1.1.2.0, 1.3.6.1.2.1.1.4.0, 1.3.6.1.2.1.1.5.0, 1.3.6.1.2.1.1.6.0, 1.3.6.1.4.1.42.2.175.102.15.2.14.0, 1.3.6.1.4.1.42.2.175.102.15.2.15.0, 1.3.6.1.4.1.42.2.175.102.16.1.0, 1.3.6.1.4.1.42.2.175.102.16.2.0, 1.3.6.1.4.1.42.2.175.102.6.2.0

            140716373206784: 2018-07-13 13:01:48,395: common.delayedPerform: DEBUG: waiting for 9.971463

            140716320761600: 2018-07-13 13:01:48,437: discovery.devices.engine: DEBUG: OID 1.3.6.1.2.1.1.1.0 is ORACLE SERVER X5-2, ILOM v4.0.2.26.b, r125868

            140716320761600: 2018-07-13 13:01:48,438: discovery.devices.engine: DEBUG: OID 1.3.6.1.2.1.1.2.0 is 1.3.6.1.4.1.42.2.200

            140716320761600: 2018-07-13 13:01:48,438: discovery.devices.engine: DEBUG: OID 1.3.6.1.2.1.1.4.0 is BNPPIP IT UNIX

            140716320761600: 2018-07-13 13:01:48,438: discovery.devices.engine: DEBUG: OID 1.3.6.1.2.1.1.5.0 is r-be-s2380-c1a

            140716320761600: 2018-07-13 13:01:48,438: discovery.devices.engine: DEBUG: OID 1.3.6.1.2.1.1.6.0 is AB

            140716320761600: 2018-07-13 13:01:48,438: discovery.devices.engine: DEBUG: OID 1.3.6.1.4.1.42.2.175.102.15.2.14.0 is None

            140716320761600: 2018-07-13 13:01:48,438: discovery.devices.engine: DEBUG: OID 1.3.6.1.4.1.42.2.175.102.15.2.15.0 is None

            140716320761600: 2018-07-13 13:01:48,438: discovery.devices.engine: DEBUG: OID 1.3.6.1.4.1.42.2.175.102.16.1.0 is None

            140716320761600: 2018-07-13 13:01:48,438: discovery.devices.engine: DEBUG: OID 1.3.6.1.4.1.42.2.175.102.16.2.0 is None

            140716320761600: 2018-07-13 13:01:48,438: discovery.devices.engine: DEBUG: OID 1.3.6.1.4.1.42.2.175.102.6.2.0 is None

            140716320761600: 2018-07-13 13:01:48,438: discovery.devices.engine: DEBUG: 10.190.172.89: getDeviceInfo(): got 10 scalar values

            140716320761600: 2018-07-13 13:01:48,438: discovery.devices.engine: DEBUG: 10.190.172.89: getDeviceInfo(): query tables

            140716320761600: 2018-07-13 13:01:48,438: discovery.devices.engine: DEBUG: 10.190.172.89: getDeviceInfo(): have 1 tables to query

            140716320761600: 2018-07-13 13:01:48,439: discovery.snmp.peer: DEBUG: 10.190.172.89: getTable 1.3.6.1.2.1.47.1.1.1.1, columns .2, .3, .4, .5, .6, .7, .10, .11, .12, .13

            140716320761600: 2018-07-13 13:01:48,439: discovery.snmp.peer: DEBUG: 10.190.172.89: getTable: Using GETBULK, size 10

            140716320761600: 2018-07-13 13:01:48,439: discovery.snmp.peer: DEBUG: 10.190.172.89: GETBULK WALK via SNMP++: OIDs = 1.3.6.1.2.1.47.1.1.1.1.2, 1.3.6.1.2.1.47.1.1.1.1.3, 1.3.6.1.2.1.47.1.1.1.1.4, 1.3.6.1.2.1.47.1.1.1.1.5, 1.3.6.1.2.1.47.1.1.1.1.6, 1.3.6.1.2.1.47.1.1.1.1.7, 1.3.6.1.2.1.47.1.1.1.1.10, 1.3.6.1.2.1.47.1.1.1.1.11, 1.3.6.1.2.1.47.1.1.1.1.12, 1.3.6.1.2.1.47.1.1.1.1.13

            140716320761600: 2018-07-13 13:01:49,291: discovery.snmp.peer: DEBUG: 10.190.172.89: getTable: got 206 rows

            140716320761600: 2018-07-13 13:01:49,291: discovery.devices.engine: DEBUG: 10.190.172.89: getDeviceInfo(): got 206 rows for ENTITY-MIB::entPhysicalEntry

            140716320761600: 2018-07-13 13:01:49,291: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: getDeviceInfo(): process data

            140716320761600: 2018-07-13 13:01:49,291: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: getDeviceInfo(): have data for sysname

            140716320761600: 2018-07-13 13:01:49,292: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: getDeviceInfo(): have data for sysobjectid

            140716320761600: 2018-07-13 13:01:49,292: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: getDeviceInfo(): no value for system_hostname

            140716320761600: 2018-07-13 13:01:49,292: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: getDeviceInfo(): no value for hostname

            140716320761600: 2018-07-13 13:01:49,292: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: getDeviceInfo(): have data for syslocation

            140716320761600: 2018-07-13 13:01:49,292: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: getDeviceInfo(): no value for hypervisor_version

            140716320761600: 2018-07-13 13:01:49,292: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: getDeviceInfo(): no value for firmware_version

            140716320761600: 2018-07-13 13:01:49,292: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: getDeviceInfo(): no value for os_build

            140716320761600: 2018-07-13 13:01:49,292: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: getDeviceInfo(): have data for sysdescr

            140716320761600: 2018-07-13 13:01:49,292: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: getDeviceInfo(): have data for syscontact

            140716320761600: 2018-07-13 13:01:49,292: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: getDeviceInfo(): classify 'Oracle ORACLE SERVER X5-2, ILOM v4.0.2.26.b, r125868'

            140716320761600: 2018-07-13 13:01:49,292: api.classifier: DEBUG: classify(): processing 'Oracle ORACLE SERVER X5-2, ILOM v4.0.2.26.b, r125868'

            140716320761600: 2018-07-13 13:01:49,294: api.classifier: DEBUG: classify(): Add result from OS Oracle ILOM

            140716320761600: 2018-07-13 13:01:49,294: api.classifier: DEBUG: classify(): Strongest match is {'kind': 'ManagementController', 'weight': 1.0, 'os_version': '4.0.2.26.b', 'os_class': 'Embedded', 'device_type': 'Service Processor', 'os_type': 'Oracle ILOM', 'os_vendor': 'Oracle'}

            140716320761600: 2018-07-13 13:01:49,294: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: getDeviceInfo(): post process data

            140716320761600: 2018-07-13 13:01:49,295: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: getDeviceInfo(): remove transient values

            140716320761600: 2018-07-13 13:01:49,322: discovery.device: INFO: finished ManagementController_i::getDeviceInfo() for 10.190.172.89

            140716320761600: 2018-07-13 13:01:49,355: discovery.device: INFO: ManagementController_i::getMACAddresses() for 10.190.172.89

            140716320761600: 2018-07-13 13:01:49,356: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: OracleIlom::getMACAddresses()

            140716320761600: 2018-07-13 13:01:49,356: api.audit: DEBUG: 10.190.172.89: getMACAddresses(): Try pool

            140716320761600: 2018-07-13 13:01:49,356: discovery.pool: DEBUG: 10.190.172.89: No directory /usr/tideway/var/pool/10/190/172/89 therefore no data in pool

            140716320761600: 2018-07-13 13:01:49,356: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: getMACAddresses(): execute queries

            140716320761600: 2018-07-13 13:01:49,356: discovery.devices.engine: DEBUG: 10.190.172.89: getMACAddresses(): query scalars

            140716320761600: 2018-07-13 13:01:49,356: discovery.devices.engine: DEBUG: 10.190.172.89: getMACAddresses(): no scalars to query (all cached or lazy)

            140716320761600: 2018-07-13 13:01:49,356: discovery.devices.engine: DEBUG: 10.190.172.89: getMACAddresses(): query tables

            140716320761600: 2018-07-13 13:01:49,356: discovery.devices.engine: DEBUG: 10.190.172.89: getMACAddresses(): have 1 tables to query

            140716320761600: 2018-07-13 13:01:49,356: discovery.snmp.peer: DEBUG: 10.190.172.89: getTable 1.3.6.1.4.1.42.2.175.102.3.1.1, columns .1, .2, .4, .6, .12, .13, .15

            140716320761600: 2018-07-13 13:01:49,357: discovery.snmp.peer: DEBUG: 10.190.172.89: getTable: Using GETBULK, size 10

            140716320761600: 2018-07-13 13:01:49,357: discovery.snmp.peer: DEBUG: 10.190.172.89: GETBULK WALK via SNMP++: OIDs = 1.3.6.1.4.1.42.2.175.102.3.1.1.1, 1.3.6.1.4.1.42.2.175.102.3.1.1.2, 1.3.6.1.4.1.42.2.175.102.3.1.1.4, 1.3.6.1.4.1.42.2.175.102.3.1.1.6, 1.3.6.1.4.1.42.2.175.102.3.1.1.12, 1.3.6.1.4.1.42.2.175.102.3.1.1.13, 1.3.6.1.4.1.42.2.175.102.3.1.1.15

            140716320761600: 2018-07-13 13:01:49,432: discovery.snmp.peer: DEBUG: 10.190.172.89: getTable: got 0 rows

            140716320761600: 2018-07-13 13:01:49,433: discovery.devices.engine: DEBUG: 10.190.172.89: getMACAddresses(): got 0 rows for SUN-ILOM-CONTROL-MIB::ilomCtrlNetworkEntry

            140716320761600: 2018-07-13 13:01:49,433: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: getMACAddresses(): process data

            140716320761600: 2018-07-13 13:01:49,433: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: getMACAddresses(): Got 0 addresses

            140716320761600: 2018-07-13 13:01:49,433: discovery.device: INFO: finished ManagementController_i::getMACAddresses() for 10.190.172.89

            140716320761600: 2018-07-13 13:01:49,495: discovery.device: INFO: ManagementController_i::getNetworkInterfaces() for 10.190.172.89

            140716320761600: 2018-07-13 13:01:49,496: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: OracleIlom::getNetworkInterfaces()

            140716320761600: 2018-07-13 13:01:49,496: api.audit: DEBUG: 10.190.172.89: getNetworkInterfaces(): Try pool

            140716320761600: 2018-07-13 13:01:49,496: discovery.pool: DEBUG: 10.190.172.89: No directory /usr/tideway/var/pool/10/190/172/89 therefore no data in pool

            140716320761600: 2018-07-13 13:01:49,496: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: getNetworkInterfaces(): execute queries

            140716320761600: 2018-07-13 13:01:49,496: discovery.devices.engine: DEBUG: 10.190.172.89: getNetworkInterfaces(): query scalars

            140716320761600: 2018-07-13 13:01:49,496: discovery.devices.engine: DEBUG: 10.190.172.89: getNetworkInterfaces(): no scalars to query (all cached or lazy)

            140716320761600: 2018-07-13 13:01:49,496: discovery.devices.engine: DEBUG: 10.190.172.89: getNetworkInterfaces(): query tables

            140716320761600: 2018-07-13 13:01:49,496: discovery.devices.engine: DEBUG: 10.190.172.89: getNetworkInterfaces(): value for SUN-ILOM-CONTROL-MIB::ilomCtrlNetworkEntry is cached

            140716320761600: 2018-07-13 13:01:49,496: discovery.devices.engine: DEBUG: 10.190.172.89: getNetworkInterfaces(): no tables to query (all cached or lazy)

            140716320761600: 2018-07-13 13:01:49,496: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: getNetworkInterfaces(): process port data

            140716320761600: 2018-07-13 13:01:49,496: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: getNetworkIntefaces(): Got 0 interfaces

            140716320761600: 2018-07-13 13:01:49,497: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: getNetworkInterfaces(): process aggregated port data

            140716320761600: 2018-07-13 13:01:49,497: discovery.device: DEBUG: ManagementController_i::getNetworkInterfaces() for 10.190.172.89 - Expected exception raised (this is for tracing purposes only)

            Traceback (most recent call last):

              File "./device.py", line 146, in callProxy

              File "./network.py", line 1159, in getNetworkInterfaces

              File "./network.py", line 265, in metaDataWrapper

            NoAccessMethod: DiscoveryCORBA.NoAccessMethod(meta=DiscoveryCORBA.MetaData(data=[ModelCORBA.KeyValuePair(key='method_failure_list', value=CORBA.Any(orb.create_sequence_tc(bound=0, element_type=CORBA.TC_any), [])), ModelCORBA.KeyValuePair(key='access_results', value=CORBA.Any(orb.create_sequence_tc(bound=0, element_type=CORBA.TC_any), [])), ModelCORBA.KeyValuePair(key='processing_messages', value=CORBA.Any(orb.create_sequence_tc(bound=0, element_type=CORBA.TC_any), [])), ModelCORBA.KeyValuePair(key='method_info_SNMP Queries', value=CORBA.Any(orb.create_sequence_tc(bound=0, element_type=CORBA.TC_any), )), ModelCORBA.KeyValuePair(key='cmd_status', value=CORBA.Any(orb.create_sequence_tc(bound=0, element_type=CORBA.TC_any), []))]))

            140716320761600: 2018-07-13 13:01:49,513: discovery.device: INFO: finished ManagementController_i::getNetworkInterfaces() for 10.190.172.89

            140716320761600: 2018-07-13 13:01:49,514: discovery.device: INFO: ManagementController_i::getIPAddresses() for 10.190.172.89

            140716320761600: 2018-07-13 13:01:49,514: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: OracleIlom::getIPAddresses()

            140716320761600: 2018-07-13 13:01:49,514: api.audit: DEBUG: 10.190.172.89: getIPAddresses(): Try pool

            140716320761600: 2018-07-13 13:01:49,514: discovery.pool: DEBUG: 10.190.172.89: No directory /usr/tideway/var/pool/10/190/172/89 therefore no data in pool

            140716320761600: 2018-07-13 13:01:49,514: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: getIPAddresses(): execute queries

            140716320761600: 2018-07-13 13:01:49,514: discovery.devices.engine: DEBUG: 10.190.172.89: getIPAddresses(): query scalars

            140716320761600: 2018-07-13 13:01:49,514: discovery.devices.engine: DEBUG: 10.190.172.89: getIPAddresses(): no scalars to query (all cached or lazy)

            140716320761600: 2018-07-13 13:01:49,514: discovery.devices.engine: DEBUG: 10.190.172.89: getIPAddresses(): query tables

            140716320761600: 2018-07-13 13:01:49,515: discovery.devices.engine: DEBUG: 10.190.172.89: getIPAddresses(): value for SUN-ILOM-CONTROL-MIB::ilomCtrlNetworkEntry is cached

            140716320761600: 2018-07-13 13:01:49,515: discovery.devices.engine: DEBUG: 10.190.172.89: getIPAddresses(): no tables to query (all cached or lazy)

            140716320761600: 2018-07-13 13:01:49,515: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: getIPAddresses(): process data

            140716320761600: 2018-07-13 13:01:49,515: discovery.devices.oracle.ilom: DEBUG: 10.190.172.89: getIPAddresses(): Got 0 addresses

            140716320761600: 2018-07-13 13:01:49,515: discovery.device: DEBUG: ManagementController_i::getIPAddresses() for 10.190.172.89 - Expected exception raised (this is for tracing purposes only)

            Traceback (most recent call last):

              File "./device.py", line 146, in callProxy

              File "./network.py", line 545, in getIPAddresses

              File "./network.py", line 265, in metaDataWrapper

            NoAccessMethod: DiscoveryCORBA.NoAccessMethod(meta=DiscoveryCORBA.MetaData(data=[ModelCORBA.KeyValuePair(key='method_failure_list', value=CORBA.Any(orb.create_sequence_tc(bound=0, element_type=CORBA.TC_any), [])), ModelCORBA.KeyValuePair(key='access_results', value=CORBA.Any(orb.create_sequence_tc(bound=0, element_type=CORBA.TC_any), [])), ModelCORBA.KeyValuePair(key='processing_messages', value=CORBA.Any(orb.create_sequence_tc(bound=0, element_type=CORBA.TC_any), [])), ModelCORBA.KeyValuePair(key='method_info_SNMP Queries', value=CORBA.Any(orb.create_sequence_tc(bound=0, element_type=CORBA.TC_any), )), ModelCORBA.KeyValuePair(key='cmd_status', value=CORBA.Any(orb.create_sequence_tc(bound=0, element_type=CORBA.TC_any), []))]))

            140716320761600: 2018-07-13 13:01:49,515: discovery.device: INFO: finished ManagementController_i::getIPAddresses() for 10.190.172.89

            140716320761600: 2018-07-13 13:01:49,546: discovery.device: DEBUG: Device::clearCache() for 10.190.172.89

            140716320761600: 2018-07-13 13:01:49,546: discovery.servants: DEBUG: Main_i::_removeDevice() for 10.190.172.89

            140716320761600: 2018-07-13 13:01:49,546: common.delayedPerform: DEBUG: 7893:unregister

            140716320761600: 2018-07-13 13:01:49,546: discovery.servants: DEBUG: Main_i::_removeDevice() - total devices now 0

            140716373206784: 2018-07-13 13:01:58,369: common.delayedPerform: DEBUG: 7893:Skipping cancelled

            140716373206784: 2018-07-13 13:01:58,369: common.delayedPerform: DEBUG: waiting for 28.555425

            140716247332608: 2018-07-13 13:02:09,303: common.configuration: USEFUL: Setting loglevel to INFO

            • 3. Re: scaning Oracle ILOM's with snmp v3
              Saurabh Thuse

              From the logs its clear that SNMP queries to get IP Addresses and Network Interfaces are not timing out.

               

              Discovery is trying to query SNMP table "1.3.6.1.4.1.42.2.175.102.3.1.1" ( name ilomCtrlNetworkEntry ) and within that table it could not find appropriate match for IP and Interfaces and hence these methods are returning 0 results.

               

              You can try to do SNMP Walk from discovery command line to table 1.3.6.1.4.1.42.2.175.102.3.1.1 to check output from device.

              2 of 2 people found this helpful
              • 4. Re: scaning Oracle ILOM's with snmp v3
                Arne Kaj Winther

                This is the result of the snmpGet with the MIP: 1.3.6.1.4.1.42.2.175.102.3.1.1

                 

                SNMP++ Get to 10.76.64.43 SNMPV3 Retries=1 Timeout=1000ms

                securityName= addm, securityLevel= 3, securityModel= 3

                contextName= , contextEngineID=

                **************************

                VB nr: 0

                Oid = 1.3.6.1.4.1.42.2.175.102.3.1.1

                Value =

                Syntax = 128

                Exception: 128 occured.

                 

                Can you tell me what Exception: 128 occured. mean ?

                • 5. Re: scaning Oracle ILOM's with snmp v3
                  Saurabh Thuse

                  Rather than snmpGet do snmpWalk which will loop over every OID from 1.3.6.1.4.1.42.2.175.102.3.1.1

                   

                  Attach that output so that I will be able to see actual table output for each OID in it.

                  2 of 2 people found this helpful
                  • 6. Re: scaning Oracle ILOM's with snmp v3
                    Arne Kaj Winther

                    Hi Saurabh

                     

                    OK, the result is:

                     

                    ./snmp++/bin/snmpWalk 10.190.172.89 1.3.6.1.4.1.42.2.175.102.3.1.1 -v3 -sl3 -snuser  -authSHA -uaPW -privDES -upPW

                    SNMP++ snmpWalk to 10.190.172.89 SNMPV3 Retries=1 Timeout=1000ms

                    securityName= addm, securityLevel= 3, securityModel= 3

                    contextName= , contextEngineID=

                    1.3.6.1.6.3.1.1.6.1.0 = 1440523883

                    1.3.6.1.6.3.10.2.1.1.0 =   80 00 1F 88 80 5B 48 9B 29 43 AA DF 56             .....[H.)C..V

                     

                    1.3.6.1.6.3.10.2.1.2.0 = 13

                    1.3.6.1.6.3.10.2.1.3.0 = 346483

                    1.3.6.1.6.3.10.2.1.4.0 = 1500

                    End of MIB Reached

                    Total # of Requests = 1

                    Total # of Objects  = 6

                     

                    Best regards,

                    Arne

                    • 7. Re: scaning Oracle ILOM's with snmp v3
                      Saurabh Thuse

                      I think the main table ilomCtrlNetworkEntry (1.3.6.1.4.1.42.2.175.102.3.1.1) is empty and hence you are getting this.

                       

                      You can try to dump OIDs from 1.3.6.1.4.1 to a file and then check if that walk gives you any result for table (1.3.6.1.4.1.42.2.175.102.3.1.1). If you cant find any information for the table then Discovery is showing you exact same thing that it is not finding that information.

                       

                      Try running below command once : I have redirected its output to a file. If you are allowed to then you can try to attach output file here so that I can confirm it:

                      /snmp++/bin/snmpWalk 10.190.172.89 1.3.6.1.4.1 -v3 -sl3 -snuser  -authSHA -uaPW -privDES -upPW > /usr/tideway/test.txt

                      2 of 2 people found this helpful
                      • 8. Re: scaning Oracle ILOM's with snmp v3
                        Arne Kaj Winther

                        Hello Loiseaux

                         

                        I’ve made that file you was asking for an it’s attach to this mail.

                         

                        Best regards,

                        Arne

                        • 9. Re: scaning Oracle ILOM's with snmp v3
                          Arne Kaj Winther

                          Hi Loiseaux

                           

                          Just got a list of the MIP’s on  ILOMs for the ZS3-2, hope it can help☺

                           

                          Best regards,

                          Arne

                          • 10. Re: scaning Oracle ILOM's with snmp v3
                            Saurabh Thuse

                            If you look at Oracle Doc : Oracle ILOM SNMP MIBs - Oracle Integrated Lights Out Manager (ILOM) 3.1 Documentation Collection , this will tell you that "SUN-ILOM-CONTROL-MIB" contains all network related information and its OID starts with 1.3.6.1.4.1.42.2.175.102.

                             

                            If you look your attached walk output it does not contain any OID which starts with 1.3.6.1.4.1.42.2.175.102 and hence when Discovery is trying to get data from this table it is getting 0 results. As it gets no data those particular DDD methods showing error.

                             

                            You said for other ILO you get all the results, so you can check what is the difference between working ILO configuration and non-working ILO configuration. May be on this device you have not loaded "SUN-ILOM-CONTROL-MIB"? Can you check that?

                            3 of 3 people found this helpful
                            • 11. Re: scaning Oracle ILOM's with snmp v3
                              Arne Kaj Winther

                              Hi Saurabh

                               

                              The link you send to me was for ILOM ver. 3….,

                              I did look and it looks good, but they are for ILOM’s version  I can scan:

                              OS Class

                               

                              Embedded

                               

                              OS Type

                               

                              Oracle ILOM

                               

                              OS Version

                               

                              3.2.9.22

                               

                              OS Vendor

                               

                              Oracle

                               

                              https://docs.oracle.com/cd/E24707_01/html/E24528/z4002eb91392027.html

                               

                               

                              But the one I only can scan half is ver. 4…, and I like to scan is:  and the MIB - SUN-ILOM-CONTROL-MIB – is not a part of the MIB’s for ver. 4 ???

                              OS Class

                               

                              Embedded

                               

                              OS Type

                               

                              Oracle ILOM

                               

                              OS Version

                               

                              4.0.2.26.a

                               

                              OS Vendor

                               

                              Oracle

                               

                              https://docs.oracle.com/cd/E81115_01/html/E86151/z4002eb91392027.html#scrolltoc

                               

                              Best regards,

                              Arne

                              • 12. Re: scaning Oracle ILOM's with snmp v3
                                Saurabh Thuse

                                So it seems for ILO version 4, Oracle has changed their SNMP MIBs.

                                 

                                As per link : Oracle ILOM SNMP MIBs - Oracle® ILOM Protocol Management Reference SNMP and IPMI Firmware Release 4.0.x

                                 

                                Network related information has been moved to standard MIB-2 tables and hence SUN-ILOM-CONTROL-MIB is not part. e.g:

                                 

                                 

                                MIB Name

                                 

                                 

                                Description

                                 

                                 

                                MIB Object ID

                                 

                                IF-MIB

                                This MIB module describes generic objects for network interface sub-layers. This MIB is an updated version of MIB-II's ifTable, and incorporates the extensions defined in RFC 1229.

                                1.3.6.1.2.1.31

                                IP-MIB

                                This MIB module is for managing IP and ICMP implementations, but excluding their management of IP routes.

                                1.3.6.1.2.1.4.

                                 

                                Currently Discovery does not look into above tables and hence it is not getting this information.

                                 

                                We will need full device capture ( Capturing SNMP devices - BMC Discovery 11.3 - BMC Documentation  )  in order to change code to look at all possible SNMP tables to get missing information.

                                 

                                You can either open a support case to submit device capture or you can send it to my email address directly. Once we have device capture we will then do appropriate code changes and will fix this in future TKUs.

                                 

                                Thanks,

                                Saurabh Thuse

                                3 of 3 people found this helpful
                                • 13. Re: scaning Oracle ILOM's with snmp v3
                                  Arne Kaj Winther

                                  Hi Saurabh

                                   

                                  Thanks, I’ve created this case Case 00555441, if you has any comment to this please correct the case or if you think that something missing please tell me.

                                   

                                  Best regards,

                                  Arne

                                  1 of 1 people found this helpful