Wireless Access

Hello all, 

I wanted to see if anyone is running into this issue as is happening more frequently.  Two controllers (cluster or hot standby -it doesn't matter), AP connected to the distribution switch (usually Cisco stack switches), controllers connected to the core, direct layer 2 (port-channel) between the core and distr switch.  It seems that the ap's are having a hard time contacting the controller, ap's get an IP address and controllers and ap's are pingable.  Added option 43, still the same issue.  Some ap's registered right-off the bat, but others don't no matter what I do. 

The fix seems to be to shutdown/unshut the ports on the switch (many times & it should not be a solution because of the time it takes.  Some sites have more than 100 aps)  Unfortunately console to an AP is not an option as they have been already been mounted on the ceiling and I'm doing this remote.  I asked this question to TAC, why some ap's are able to registered some don't?? and do after many shutdowns?? I think is a bug on the code we are running, but I was told there is no reports of it.  Hence my post here...  TAC did recommend to upgrade to 8.3.0.3. and  after yesterday deployment I am really considering.  Anyone running 8.3.0.3? 

Thank you in advance.

Cheers! 

I have used almost every version of 8.x since 8.1. I am on 8.3.0.5 and it is by far the most stable of any 8.x version (I have not tried 8.4 yet).

How are your APs finding the controller... through which means?

We use the DNS record "aruba-master" to allow APs to find our controller.

In a cluster environment, you can change the DNS record to narrow down which controller may be causing you an issue.

On a normal day, we just point it to the VIP in case one controller goes down.

Hope that helps.

iann miller

I have not try using a dns records.  Perhaps it makes it easy, I will research the configuration and maybe try it in my next deployment. 

I'm using the out-of-the-box discovery, putting the controller and aps on the same vlan, also tried option 43, clustering controllers and using LMS - same results.  

BTW - I was told by Aruba SE that running a cluster is not beneficial in our environment because of the amount of AP's.  I guess is better when you have over 500 AP's or so.  But regardless, he also mentioned that it's better for troubleshooting.  The data flow is predictable in a hot-standby scenario, as opposed to a cluster.  Have you ran into an issue like this?  

I have had a Cluster since being on 8.x. I have about 900 APs across 2 7220 controllers and a VM Mobility Master controlling the two hardware controllers.

For the DNS discovery method, you just need to create a DNS record called aruba-master in the DNS space that your APs live in. So, if your APs create DNS records in testcorp.loc when they boot up, then put your DNS record there.

I understand that this may be considered an "older" method by some people's opinions... but I never have an issue with it. Not sure if some of the other methods are being blocked by an ACL or something?

On some older versions of 8.x, the Cluster was a little clunky... but on 8.3.0.4 and 8.3.0.5, it seems great so far.

iann miller

---

@MLG13 wrote:

I have not try using a dns records.  Perhaps it makes it easy, I will research the configuration and maybe try it in my next deployment. 

I'm using the out-of-the-box discovery, putting the controller and aps on the same vlan, also tried option 43, clustering controllers and using LMS - same results.  

BTW - I was told by Aruba SE that running a cluster is not beneficial in our environment because of the amount of AP's.  I guess is better when you have over 500 AP's or so.  But regardless, he also mentioned that it's better for troubleshooting.  The data flow is predictable in a hot-standby scenario, as opposed to a cluster.  Have you ran into an issue like this?  

---

If you have contact with an Aruba SE, get the console cable from him/her so that TAC can get to the bottom of your issue.  We would only be guessing on this forum and I assume TAC has access to all of the data that you do. 

Clustering benefits ANY multicontroller environment, period.  Maybe you should ask the SE specifically what he/she was talking about when they said that.  AP discovery of a controller should not really have anything to do with clustering.  The console cable will allow TAC to understand what the AP is seeing and if it is having any connectivity issues.

I would try to put the access points on the same layer 2 VLAN as the controller to work around your discovery method possibly being misconfigured.  There should not be any discovery issues in 8.2.1.0.

I forgot to mention that the controller and ap's are on the same broadcast domain.  TAC has validated the configuration and found not issues.  They asked to console into the AP, but to me, it doesn't make sense why some ap's register with no issues and other have a hard time? the fix is keep shut & unshut the ports? that makes no sense..  Also, I forgot to mention that the controllers and AP's are still being ship with 6.5 code.  Maybe some AP's have a hard time upgrading from the controller? Maybe that's why TAC wants to see what's going on with the AP's - I understand that.  But this is been happening on every deployment.. We are replacing another wireless vendor with Aruba, so I don't have a lot of experience with it, but I never had an issue this issue with the other vendor..