Discovery: SNMP V3 scan fails (either skipped or a timeout in getMACAddresses) or SNMP V3 credential test fails (SNMP request timed out) if two devices have duplicate SNMP V3 Engine IDs

Version 1
    Share This:

    This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.


    PRODUCT:

    BMC Discovery


    COMPONENT:

    BMC Discovery 11.3


    APPLIES TO:

    BMC Discovery



    PROBLEM:

     

    An SNMP v3 scan of a supported network device fails with “Skipped (Device is an unsupported device)”, or possibly a timeout in getMACAddresses. 

    The customer is able to do an snmpwalk from the Discovery command line successfully.

    Other SNMP devices are discovered by the appliance using the same credentials.

    A credential test fails with "SNMP request timed out". Increasing the timeout to 100s does not help.

    After a restart of the Discovery services (or all the services on all cluster members), the credential test succeeds, and the device is discovered successfully.

     


    SOLUTION:

     

    Root cause 1: DRUD1-25505 - Two or more network devices present the same EngineID, which is supposed to be unique. Discovery scans the first one successfully, but then the second one fails until the cache is flushed (by the service restart) - at which point a rescan of the first would fail, and so on. 

    To confirm the root cause:
    - If the scan works with SNMP v2 and fails with SNMP v3, the root cause is probable.
    - If the SNMP v3 scan (or the credential test) fails and then works after an appliance restart, the root cause is confirmed.
    - It is also possible to confirm the problem with the query below:

      
      search NetworkDevice show name, type, vendor, model, #InferredElement:Inference:Associate:DiscoveryAccess.endpoint as 'Scanned via', #InferredElement:Inference:Associate:DiscoveryAccess.end_state as 'End State', #InferredElement:Inference:Associate:DiscoveryAccess.#DiscoveryAccess:DiscoveryAccessResult:DiscoveryResult:DeviceInfo.snmpv3_engine_id as 'SNMP v3 Engine Identifier' 
      
     
    If two NetworkDevices have the same snmpv3_engine_id, the problem is confirmed.  Otherwise, restart the appliance, rescan the network,  then re-execute the query above. This is needed because NetworkDevice nodes are only created after a successful scan (which is not possible until the appliance is restarted in this case).  
     
    This query will only show the snmpv3_engine_id that Discovery was able to find. If workaround #1 below (service restart) was not used, the issue may occur even if the query above does not return anything wrong.   

    - If the following command is executed from the appliance:

       

    sudo tcpdump -i any -s0 host <ipAddress> -w /tmp/snmp_issue.cap

       

    The dump may show the elements below. This is not enough to confirm the cause but it is compatible with it.

       

    - Discovery send get-request
    - Device send report 1.3.6.1.6.3.15.1.1.4.0 (    usmStatsUnknownEngineIDs)
    - Discovery send get-request with EngineID
    - Device send report 1.3.6.1.6.3.15.1.1.5.0 (usmStatsWrongDigests)

      
      
      Workaround 1: 
    1A- Restart the Discovery services of a standalone appliance (or the Discovery services of all members of a cluster) before scanning any of the devices that are using a duplicate engine id. Each restart will allow Discovery to scan a single one of the N devices with duplicate engineIDs. If the services are restarted once or twice a day, it could allow Discovery to scan the devices affected by this issue with a reasonable probability of success.  
    1B- Rescan with SNMP v2.  
     
    Note that workaround 3B below (root cause 3, SNMP_USE_ENGINE_ID_CACHE) will not help if root cause 1 is confirmed.  
     
      Solution 1A: Upgrade to Discovery 12.0 which contains a fix for defect DRUD1-25505. This fix allows the scans and credential tests to succeed even when the SNMP engine ids are duplicated.  
      Solution 1B: Change the SNMP v3 engineID of the scanned device and make it unique. This is recommended for security reasons.  
    For Cisco Devices, it is possible to make it unique using MAC addresses:  see https://supportforums.cisco.com/discussion/11539996/snmp-engineid-same-multiple-routers.  
    It may be possible to execute a similar procedure for other vendors, such as HP.  
    Note this solution is not suitable when pairs of master/standby devices share the same engineid (see root cause 2 below).  
     
     
      Root cause 2: Some devices (such as Cisco firewalls, Brocade load balancers, or Juniper devices) can be configured with an Active/Backup setup (also referred to as master/standby). This means that the active and backup devices are two different physical devices but they share internal configurations to support failover.  As they share configurations, they also share SNMP v3 engineIDs.  It is an SNMP v3 security standard that SNMP v3 engine IDs should be unique per device.  
      Solution 2: Upgrade to Discovery 12.0 which contains a fix for defect DRUD1-25505.  
      Workaround 2: Use the workarounds provided for root cause 1.   
     
     
      Root cause 3:  A new network device was found, then replaced (on the same IP, i.e. was installed with a new MAC address and SNMP v3 EngineID), and rescanned.   
      Workaround 3:  See workarounds 1A and 1B above  
      Solution 3A: Upgrade to Discovery 12.0 which contains a fix for defect DRUD1-25505.  
      Solution 3B: If not already done, upgrade to Discovery version 11.2 or 11.1.0.5 and execute the command below:  
    tw_options SNMP_USE_ENGINE_ID_CACHE=False  
    (enter system password)  
    Please note that this solution could have an impact on appliance performance in theory. 

     


    Article Number:

    000079538


    Article Type:

    Solutions to a Product Problem



      Looking for additional information?    Search BMC Support  or  Browse Knowledge Articles