DX NetOps

 View Only
  • 1.  Problem with snmp v3

    Posted Jan 18, 2017 09:59 AM

    Hello communities !

    Today I have a curious problem trying to discover a wireless device with SNMP V3.  

    The SNMP v3 configuration is with MD5 and DES, if I execute a snmpwalk the devices respond. (directly from poller )

     

    [spectrum@spec04 Spectrum]$ snmpwalk -v 3 -a md5 -A 123456 -x des -X 123456 -u USERV3 -lauthPriv w116
    SNMPv2-MIB::sysDescr.0 = STRING: RouterOS RB911G-5HPnD
    SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.14988.1
    DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (200991400) 23 days, 6:18:34.00
    ^C

     

    But from oneclick, mibtools, discovery console, I cannot discover it. The SNMP configuration is the same from command line. 

     

    The error is "SNMP Request timed out"

     

    I increase the values for Timeout and Retrys, but same error appear.

     

    Any idea how could I debug this ?

     

    Thanks

    Diego Pereyra

     

    pd, the device is a MikroTikRT Wireless



  • 2.  Re: Problem with snmp v3

    Broadcom Employee
    Posted Jan 18, 2017 10:12 AM
      |   view attached

    Does the device have the same engineid as another device?  Spectrum doesn’t support multiple devices with the same engineid, so it may be due to that.

     

    Are you trying to manually discover this (by using new model by IP or new model by type)?  You can try creating the model by v1 (using new model by type) and then change the community string to be the v3 string.  Running a sniffer trace will give you more info as well if you are still not able to model it…

     

    Cheers

    Jay



  • 3.  Re: Problem with snmp v3

    Posted Jan 18, 2017 10:48 AM

    Hi Jason, the "engineid" field in snmpv3 configuration of wireless is not configured, is empty. If I add ir manually the device stays in initial condition. (blue) never respond to polls.

    And I will sniffer the net to see what happend when I try to discover it.

    Thanks.

    Diego.



  • 4.  Re: Problem with snmp v3
    Best Answer

    Broadcom Employee
    Posted Jan 18, 2017 09:43 PM

    Because of non-unique snmpEngineId you will see 1.3.6.1.6.3.15.1.1.2.0 (usmStatsNotInTimeWindows) report packet from the device. Please find below figure.

    usmStatsNotInTimeWindows packet 



  • 5.  Re: Problem with snmp v3

    Posted Jan 19, 2017 08:05 AM

    Thanks a lot for reply Widjaja Sangtoki, Im looking the pcap capture between poller and device (captured with nqobserver). And open it with wireshark.

     

    There are others OIDs in pcap about EngineTime, is ok ?

    Thanks for your time.

    Diego.   



  • 6.  Re: Problem with snmp v3

    Broadcom Employee
    Posted Jan 20, 2017 01:22 AM

    Hi Diego,

    You got 1.3.6.1.6.3.15.1.1.1.0 (usmStatsUnsupportedSecurityLevel).

    This is set when the security level specified is not supported by the agent (device). This error is reported by the agent with its first varbind containing the OID ".1.3.6.1.6.3.15.1.1.1.0" and the value is a Counter giving the number of packets that have been dropped because of this error.



  • 7.  Re: Problem with snmp v3

    Posted Jan 20, 2017 09:26 AM

    Hi
    I have an issue with SNMP v3 and CAPC/DA which shows some similarities to what I’ve read here. Hopefully someone here can help me with my issue.

     

    Our client has a number of Cisco Nexus devices configured for snmp v2c and v3. The devices are modelled in Spectrum using v3 and that works fine. However in CAPC the devices will not communicate using v3. They will use v2c ok, but not v3. I have tested using sapwalk on the Data Collector and the device responds fine to that using v3, so it is not a problem between the DC and the device.

     

    After reading here I believe the issue is the difference in the EngineTime values, but I have no idea how to fix that. Maybe somebody could confirm this is the issue and also how to fix it.

     

    This first screenshot shows the request from the DC, showing EngineTime of 63526292.

     

    The second screenshot shows the response (report), showing EngineTime of 20578459.

    Clearly the difference is greater than 150 so it seems the request will fail.

     

    Does anyone know where the issue here lies? Should the DC synchronise to the EngineTime of the device? If so how?

     

    Any help would be appreciated.

     

    Thanks, John