Wireless Access

Hi there,

we have two different environments in our company.

We have office Wifi in which we have two Aruba Controller working in Master-Backup design.

We have production Wifi in which we have two Aruba Controller working in Master-Backup design as well.

An Access Point discovers the DNS entry aruba-master (VRRP) which is the Aruba Controller in the office environment. So far, OK.

Now I want that AP terminating to the Aruba Controller in the production environment.

For that I have a dummy AP Profile on the Aruba office Controller in which I only configure the AP-System profile with the lms addresses of the production Aruba Controller. After provisioning the AP with that special AP Profile the AP appears at the production controller as an unprovisioned AP because the controller doesn’t have the dummy AP profile. OK, so far.

Now I provision the AP with the final (right) AP Profile on the production controller. After a reboot the AP connects again with the office controller instead the production controller. Seems that the AP ignores the AP Profile and uses aruba-master entry instead.

What am I doing wrong?

I *think* I've understood the issue! Correct me if i'm wrong :) I suspect your problem is the DNS record aruba-master.  the AP boots it will go through the master discovery sequence (

Hi,

maybe I should verify what the AP is doing while booting.

But, when I first provision the AP with my "dummy" AP Profile to direct the AP to the other controller, the AP seems to boot and comes up on the correct contoller. So it seems that the AP use the lms information. But as I explained, the final provision with the desired AP profile (which also include lms information) does not work. The AP boots again and comes up on the first controller.

So what I try to do is:

1. New AP discovers aruba-master

2. Putting the new AP in an AP Group which only contain lms information to terminate the AP to another target controller (it's working already)

3. On the target Controller: Put the AP to the final AP Group. AP should boot and not do an aruba-master discovering. It should use lsm information.

4. In Case of unexpected boot of AP (maybe power loss), it should also not do an aruba-master discovering. It should use lms information and come up to the "right" controller

Hi RR86, zalion0 is correct - the APs only store the ap-name and ap-group in memory - unless you provision it with a static address in memory. APs will always go through the master discovery process mentioned above to pull it's config - this is what I believe is happening.
1. AP discovers Office Master Controller - via DNS aruba-master
2. You provisioned the AP into "Dummy-Group" with "LMS Production-Master IP Address"
3. AP reboots, discovers Office Master Controller, and immediately receives the matching "Dummy-Group" - "LMS Production-Master IP Address" config - and moves over to that master controller.
4. You provision the AP into "Final Group" with "Production-Master IP Address"
5. AP reboots, discovers Office Master Controller via DNS, but the "Final Group" doesn't exist and is flagged as "Unknown Group" and "Unprovisoned" and remains on the Office Master because the config doesn't exist.


#AirheadsMobile

Hi together,

thanks a lot! That makes sence.

What if I create the same AP Groups on both controllers?

On the office side an AP Group which only has the lms information.

On the production (target) side an AP Group with exactly the same name but with more information like vap profile, ssid etc..

1. The AP first comes to the office Controller

2. Provision in the AP Group

3. Reboot: AP comes to the office Controller again

4. Office Controller puts the AP in the AP Group

5. AP gets lms information and swaps to the production Controller

6. Production Controller also knows the AP Group and puts the AP into it.--> Finish

I'm wonderig if that works, I will try today.

---

@RR86 wrote:

Hi together,

 

thanks a lot! That makes sence.

 

What if I create the same AP Groups on both controllers?

On the office side an AP Group which only has the lms information.

On the production (target) side an AP Group with exactly the same name but with more information like vap profile, ssid etc..

1. The AP first comes to the office Controller

2. Provision in the AP Group

3. Reboot: AP comes to the office Controller again

4. Office Controller puts the AP in the AP Group

5. AP gets lms information and swaps to the production Controller

6. Production Controller also knows the AP Group and puts the AP into it.--> Finish

 

I'm wonderig if that works, I will try today.

 

---

Hi RR86,

I believe that may work. I was just curious if the production environment is brand new and these are the first APs you're trying to bring online - of they were an existing production environment that was joined/added to the office environment - and share the same DNS? Any particular reason you have two separate master pairs (Different OS Versions, Region Offices, Different Administrative sites, etc) - instead of one master-backup pair managing separate configs for your office and production controllers - by having a "Office AP-Group" and "Production AP-Group" for a simple example? There are dozens of redundancy options and everyone's infrastructure is completely different - just curious - we've been doing something similar for a couple years (I can elaborate on that later as slightly a long story) and some of the situations we've ran into).

I tried...and it works! Thanks again!

The production environment share the same DNS.

We have a quite complex infrastructure Layer 2 and Layer 3 seperated, VRFs etc... and must strictly seperate between different environments.

To make everything not even more complex we decided to use the master/backup design with fast failover option.

One controller does the work, the other only takes over in case of a failure.Same for other environment.

I think/hope this is the most easiest concept. ;-)