Wireless Access

In a college setting...

Our current AP pool (525 APs) consists mainly of AP-105s and AP-125s with pockets of AP-65 (mainly faculty offices in a separate floors). Our AMs are a mix of AP-105s and AP-93s. Our controllers are M3s in master/local configuration running 6.3.1.6

This summer we will migrate to a pair of 7240s (active and backup/standby) which would run 6.4.1.x code with license pooling.

We would like to start migrating to 802.11ac by installing AP-205s in the new deployment areas, swapping AP-105s with the number of AP-205s budget allows and redeploy the AP-105s to begin phasing out the AP-65s. We will not be able to kill the AP-65s (about 50 short budget wise).

Problem: AP-205s require 6.4.1.x code which do not support the AP-65s (AP-105s and AP-125s are supported in both).

Possible solution: The 7240/6.4.1.x run the license pooling server and support all APs except for the AP-65s and the "old" M3s/6.3.1.8 supporting the leftover AP-65s. This would be for 12 to 18 months, until the next budget year.

Questions before I start breaking things...

- Can the license pooling server support mixed ArubaOS versions ?

- Will users be able to roam from one generation to the next and back ?

- Can the 7240s (active/standby) act as the master to the local M3s ?

TIA

Martin Durand

Infrastructure director

Sainte-Foy College

Questions before I start breaking things...

- Can the license pooling server support mixed ArubaOS versions ? No

- Will users be able to roam from one generation to the next and back ?  Yes, as long as they bridge usersto the same layer 2 network.

- Can the 7240s (active/standby) act as the master to the local M3s ? No, not across major versions of code.

Questions before I start breaking things...

- Can the license pooling server support mixed ArubaOS versions ? No

So I would simply have to reserve (i.e. not migrate to the license pool) an existing license block large enough to cover the number of AP-65s on the M3s ?

- Will users be able to roam from one generation to the next and back ?  Yes, as long as they bridge usersto the same layer 2 network.

All 4 controllers receive and drop their packets to the same vlans and vlan pools LACP linked to our core switches.

- Can the 7240s (active/standby) act as the master to the local M3s ? No, not across major versions of code.

So, after migrating the current configuration to the 7240s and adjusting the 7240s IP configuration to avoid overlaps, I could then keep the current M3/6.3.1.6 configuration, including ssids for the AP-65s ?

The AP-65s are configured and would be updated to the latest 6.3.1.8 (at the moment) before migration so they already have their LMS IPs so it should cover us if one of them needed to reboot ?

And then manually synchronize changes from the 7240s to the M3s until we exterminate the AP-65s ?

TIA

Martin

Let's start with a few basic questions:

- How many AP65s do you have?

- Do you have Airwave?

Currently: 80 AP-65

After the summer oprations : 50 AP-65

They are segregated on separate floors of 2 buildings.

And we have Airwave

Martin

"Possible solution: The 7240/6.4.1.x run the license pooling server and support all APs except for the AP-65s and the "old" M3s/6.3.1.8 supporting the leftover AP-65s. This would be for 12 to 18 months, until the next budget year." ---  That is the answer.

On the 7240s

- Put the 6.3.1.8 code (or whatever your M3s are running) on one of your 7240s

- Make it a local to the M3 (so that it gets its global config)

- Turn the 7240 into a master and upgrade to 6.4.1.x (you will have to create the VLANs locally on the 7240 to make the VLANs from the global configuration useable).

- Upgrade the other 7240 to 6.4.1.x and make it a backup master to the first 7240 (you will have to create the VLANs locally on this 7240, as well to make the global configuration that was copied functional)

- The 7240s should have an identical configuration as the M3s.  Things like the LMS-IP in the ap-groups would need to be fixed or removed if it was pointing at your M3's explicitly.

- Create a new DNS a-record that points to the VRRP between the new 7240s

- Make sure to add new ip addresses to your radius server as radius clients for the 7240s.

On the M3:

- On the M3, under Wireless> AP Installation, provision a test AP on the M3 to point to the new DNS record created above.  The AP should reboot and will now only go to the new DNS address (the VRRP between the 7240s) and will stay there forever:

- Create an AP-Group for the AP65s

- Move all of the AP65s into that ap-group

- Create an ap provisioning profile with the new fqdn as the master.  An ap provisioning profile is used to overwrite AP parameters like the master fqdn, like we did manually above.  You can apply it to an entire ap-group to overwrite the "aruba-master" dns behavior with your new fqdn that points to the 7240.  Test it on a or test ap-group to make sure that it works as desired.  The access points will reboot when you apply the ap provisioning profile, so you should only do it to a test AP-group or during a maintenance window.   http://www.arubanetworks.com/techdocs/ArubaOS_63_Web_Help/Web_Help_Index.htm#ArubaFrameStyles/1CommandList/ap_network_profile.htm

- After you get comfortable with it, you can apply the ap provisioning profile to more ap-groups to point them at the 7240s.

- When you are done with all of the ap-groups besides the one with the AP65s, you will have two separate infrastructures.

Please test all of this in the lab in case something in your environment keeps it from working.

I'll try that in days to come, thanks

Now, bring on the AP-205 and GA 6.4.1.x !

Bonjour Colin,

Sorry for the delay, stuff got in the way !

I adapted your solution a little and it worked like a charm.

- The M3s were on 6.3.1.8, I upgraded the 7220s to that version.

- On the licensing site, I migrated all the licences (minus the minimum to cover the AP-65 and AP-70) to the 7220s with license pooling. Did a license export to save those for later.

- On the M3s, created an "AP-65" AP profile and migrated all the -65 and -70 to that profile.

- I created an "aruba-65" DNS entry pointing to the M3s.

- I modified the "aruba-master" DNS entry to point to the 7220s,

- I provisionned the AP-65s and -70s with the "AP-65" profile, changing the Host-controller name to "aruba-65" as you suggested.

- On the M3s, I did a "flash backup", downloaded it to my laptop, un-gzip-tared it and modified the "default.cfg", changing the controller name and IP addresses (the M3s and 7220s share the same vlans).

- I then re-tared-zipped the folder and uploaded it to the master 7220. After a "flash restore" and "license import", the controller booted fine.

- I did the same procedure for the slave M3 to the slave 7220.

- With everything up, and all the controllers having the same AP profiles, I used a maintenance window to reboot the non -65 and -70 APs which happily attached to the 7220s.

- After testing that everything was working like it should, I upgraded the 7220s the 6.4.1.0 (another maintenance window) and we started provisionning/installing our brand new AP-205s (boy, do they run hot).

- A little housekeeping later (removing the superfluous APs from the respective controller generations, modifications to Airwave...), everything is up and users are happy!

Thank you very much for your guidance.