Wireless Access

last person joined: yesterday 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Expand all | Collapse all

Need to find the actually number of live APs on a Controller in our redundant cluster via SNMP

This thread has been viewed 6 times
  • 1.  Need to find the actually number of live APs on a Controller in our redundant cluster via SNMP

    Posted Nov 13, 2015 05:37 AM

    It would be fine if I had one controller, but two (master/local) seems to lead to totals rather than individuals. Presumably because each is the backup for the other.

    E.g. say ewaruba has 10 APs up, and mbaruba has 5 APs up.

     

    If I use either:

    .1.3.6.1.4.1.14823.2.2.1.5.2.1.1

    Total Number of Access Points connected to the controller

    or

    .1.3.6.1.4.1.14823.2.2.1.1.3.1

    Total Number of Access Points Connected to this switch.

     

    The value returned is 15 when querying either ewaruba or mbaruba.

    I want something that tells me 10 and 5.

     

     



  • 2.  RE: Need to find the actually number of live APs on a Controller in our redundant cluster via SNMP

    EMPLOYEE
    Posted Nov 17, 2015 09:39 PM

    Hi Ewan

    What ArubaOS version are you testing on, .1.3.6.1.4.1.14823.2.2.1.5.2.1.1 (aka wlsxWlanTotalNumAccessPoints) seems to work correctly at least on 6.4.2.x

     

    Master running 6.4.2.5 (has 6 locals with 3-10 APs each)

     

    (master) #show ap active | include Num
    Num APs:0
    (master) #
    (master) #show ap database status up | include Total
    Total APs:36
    (master) #

     

     

    One of the locals connected to it

     

    (local1) #show ap active | include Num
    Num APs:11
    (local1) #

     

    another local connected to it

     

    (local2) #show ap active | include Num
    Num APs:6
    (local2) #

     

    snmpwalk

     

    $ snmpwalk -v2c -c public -mALL -M. -O0X <master-ip> .1.3.6.1.4.1.14823.2.2.1.5.2.1.1
    WLSX-WLAN-MIB::wlsxWlanTotalNumAccessPoints.0 = Gauge32: 0
    
    
    $ snmpwalk -v2c -c public -mALL -M. -O0X <local1-ip> .1.3.6.1.4.1.14823.2.2.1.5.2.1.1
    WLSX-WLAN-MIB::wlsxWlanTotalNumAccessPoints.0 = Gauge32: 11
    
    
    $ snmpwalk -v2c -c public -mALL -M. -O0X <local2-ip> .1.3.6.1.4.1.14823.2.2.1.5.2.1.1
    WLSX-WLAN-MIB::wlsxWlanTotalNumAccessPoints.0 = Gauge32: 6
    
    

     

    the other OID you mentioned .1.3.6.1.4.1.14823.2.2.1.1.3.1 (aka wlsxSwitchTotalNumAccessPoints) gives the exact same data as above.

     

    Is it possible you have something like HA standby configured ? that might cause it to report duplicate counts between a master an a local ?

     

    I note that I was only able to test this on a master that had 0 APs up on it, perhaps there is a quirk there too. Let us know about whether you have HA configured.

     

    regards

    -jeff

     

     

     

     



  • 3.  RE: Need to find the actually number of live APs on a Controller in our redundant cluster via SNMP

    Posted Nov 18, 2015 09:19 AM

    Hi Paul,

     

    I did work OK - as you found out, just on a single controller when we were testing, but since we've gone into production with the 2 contrlers ruuning in HA mode, we see that there is a problem with the SNMP stats.

    I should have said in the original post that we are running HA, with the two controllers.

    With 2 AP groups useing the LMP ip and Back UP LMS IP addresses of the 2 controllers.

     

    Regards,

      Ewan



  • 4.  RE: Need to find the actually number of live APs on a Controller in our redundant cluster via SNMP

    EMPLOYEE
    Posted Nov 18, 2015 10:36 AM

    HI Ewan

    It was somewhat inferred after the result was seen. Since you have confirmed, I don't think that behaviour is going to change any time soon/design intent/oversight (since in HA there is an AP in "S" flag on the standby controller and it is essentially up in some ways).

     

    So let's talk workaround - what if you use wlanAPConnectedAsStandby OID (.1.3.6.1.4.1.14823.2.2.1.5.2.1.4.1.41) instead, this will show you active/standby split, you can sum the two types that it shows with a simple shell script. Hacky oneliner below.

     

    regards

    -jeff

     

    snmpwalk -v2c -c public -mALL -M. -O0X 1.2.3.4 wlanAPConnectedAsStandby 2>&1 > a.tmp && a=`cat a.tmp | grep active | wc -l` && echo "active $a" && b=`cat a.tmp | grep standby | wc -l` && echo "standby $b"



  • 5.  RE: Need to find the actually number of live APs on a Controller in our redundant cluster via SNMP

    Posted Nov 18, 2015 10:41 AM

    Hi Jeff,

    that looks like a really good idea.  Give us some time to test it and I'll get back to you.

     

     

    Cheers,

       Ewan.



  • 6.  RE: Need to find the actually number of live APs on a Controller in our redundant cluster via SNMP

    Posted Nov 23, 2015 09:39 AM

    Hi Jeff,

     

    thanks for taking the timne to look at this fpr us. I thibnk that you can call this one closed/solved bnow.

    Thanks again.

     

    here is the feeddback from  the customer - you might find their last comment amusing/interesting.

     

     

    £££££££££££££££££££££££££££££££££££££££££££££££££££££

     

    Thanks for this, but I had a couple of problems with it. The first being that I don’t think my cacti graphing skills are currently up to being able to script results like this before graphing. Secondly, it looks to me like the “active” in this OID actually shows all known “active” APs for the controller, regardless of whether they are actually up or not.

     

    However, “Standby” does look like it could be of use, in that the total “Standby” on each controller will give you the real “Active” on the other controller. So if I was able to count the “Standby”s on controller A, then that would give me that “Active”s on Controller B. And vice versa. I think.

     

    But it doesn’t help me unless I can figure out how to sum a list of “standby” entries in cacti. I will have a look into this though.

     

    Plus it seems a bonkers of a work around to get a simple value of up APs. But at least it’s something.

     

    Thanks,

    Colin