Network Management

last person joined: yesterday 

Keep an informative eye on your network with HPE Aruba Networking network management solutions
Expand all | Collapse all

Airwave SNMP problem

This thread has been viewed 18 times
  • 1.  Airwave SNMP problem

    Posted Apr 17, 2018 12:57 PM

    Hello everyone,

     

    I have a problem with Airwave. When I monitor Aruba switches by snmp I get the message "SNMP get failed", I used "Devise Setup -> Discover", discover several switches in the same subnet, but there are others that do not. The configuration of snmp-server in the switches is the same.

     

    Thanks for your help.

     

    Xavier Vazquez



  • 2.  RE: Airwave SNMP problem

    EMPLOYEE
    Posted Apr 17, 2018 02:43 PM

    First thing is check that the device credentials are correct:

     

    What version of AirWave are you using?  If you're on 8.2.6, you can try doing SNMP walks from the AMPCLI to test the credentials in the database.  To do this, you'll need to know the device's ID which is gotten from the URL when you view the device's monitor page.

     

    Example URL:

    https://airwave.lab.com/ap_monitoring?id=2421

    The ID is 2421

     

    In CLI: go to 'Enter Commands' (opt 11)

    $ ?sw
    sw <ap_id> args [-o fname ] ... - snmp walk protocol v1 - see 'man snmpbulkwalk'
    sw2 <ap_id> args [-o fname ] ... - snmp walk protocol v2c - see 'man snmpwalk'
    sw3 <ap_id> args [-o fname ] ... - snmp walk protocol v3 - see 'man snmpbulkwalk'
    With '-o fname' the output will be saved in the CLI user directory.

    $ sw2 2421 sysName
    SNMPv2-MIB::sysName.0 = STRING: jamaica-test-aos65

     

    If you get a valid output like above, then the credentials are correct.  If you're on older code - it might just be easier to go to the device's management page and updating the creds with the correct creds.

     

    If the above didn't resolve your issue, it could also be the version of SNMP you're using.  Are you using the default SNMPv2c?  If not, then you can double check what version AMP is using to communicate from the Group -> select group -> Basic tab.  There is a subsection for each device brand and sometimes another breakout by device type with an SNMP dropdown that lets you choose v1, v2c, v3.



  • 3.  RE: Airwave SNMP problem

    Posted Apr 19, 2018 11:50 AM

    Hi Rob,

     

    The credentials are correct

     

    I did the tests with the following result

     

    $ sw2 215 sysName
    Timeout: No Response from 10.17.254.254:161
    $ ping 10.17.254.254
    PING 10.17.254.254 (10.17.254.254) 56(84) bytes of data.
    64 bytes from 10.17.254.254: icmp_seq=1 ttl=250 time=5.68 ms
    64 bytes from 10.17.254.254: icmp_seq=2 ttl=250 time=12.3 ms
    64 bytes from 10.17.254.254: icmp_seq=3 ttl=250 time=0.977 ms
    ^C
    --- 10.17.254.254 ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2363ms
    rtt min/avg/max/mdev = 0.977/6.330/12.325/4.654 ms

     

    This is a second test for another switch in the same subnet.

     

    $ sw2 28 sysName
    SNMPv2-MIB::sysName.0 = STRING: SW-JL356A-AL-SB-SC
    $ ping 10.17.254.225
    PING 10.17.254.225 (10.17.254.225) 56(84) bytes of data.
    64 bytes from 10.17.254.225: icmp_seq=1 ttl=249 time=31.7 ms
    64 bytes from 10.17.254.225: icmp_seq=2 ttl=249 time=28.4 ms
    64 bytes from 10.17.254.225: icmp_seq=3 ttl=249 time=43.4 ms
    64 bytes from 10.17.254.225: icmp_seq=4 ttl=249 time=99.2 ms
    ^C
    --- 10.17.254.225 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3457ms
    rtt min/avg/max/mdev = 28.473/50.751/99.292/28.575 ms

     

    In this case everything is OK,

     

    In the 2 switches I have the same credentials.

     

    Thank's for your help.}

     

    Xavier



  • 4.  RE: Airwave SNMP problem

    EMPLOYEE
    Posted Apr 19, 2018 11:57 AM

    If you retry the snmp walk to the switch that had a timeout -> does it ever get a good response?  At the same time, from the switch side - is the switch seeing the snmp request?  I'm thinking the switch might have an ACL that's declining communication with AMP, or a firewall rule somewhere might be blocking the snmp traffic to that destination perhaps?