Wireless Access

Hello,

We are an internatinal company and we are designing to have 2 Mobility Masters and then 2 Local controllers at each site/location.  Each location has a different Network Address Scheme; hence the Wireless VLan IP addresses are different at each site.

I have already deployed 3 different sites(2 local controlelrs at each site).

I have been challenged with configuring as much as I can for another 3 remote site locations (2 local controllers each site) from the main headquarters location.  Then to ship the local controllers to their destinations (will requitre a different local controller IP address and then setup the remaining configurations while at that location.  

In order to keep the local configuration standardized I think it would be best to setup the local controllers to synch with the MM with the "PSKwithIP" option.  Aruba support has stated that they prefer this option over PSK with MAC address.  Otherwise I will have 3 sites with "PSKwithIP" and another 3 with "PSKwithMAC".

My questions are

1).  Is using PSKwithIP to initiallyu connect to the MM and then changing the Local controller's local IP address a good idea?  Or should I use the PSKwithMAC option?

2.  I will write up the basics if my idea to accomlilsh this and I would like feedback regrding if that is a good plan?

Keep in mind that a Man. Device Cluster cannot be created on the Managed Network Group level until the final destination/production IP addresses are in place.  Nor can the local MD VRRP configurations be made until the final/production IP addresses are in place.

My plan is summarized below:

1.  Connect each new local with a temporary IP address when at the HQ Site.  

     a.  Update the version of the MD operating system and join the MD's to the Mobility masters.

2.  Create the appropriate MD-Groups below the Manged Network section.

     a.  Then synch up the the MD's to the Mobilty Master and then afdd each MD to the final destination MD Group.

     b. The Host name will not change but the IP address will eventualy change.

3.  After verifying that the communication works between the new MDs and the Mobility Masters and the licenging is up to date on the Mobility Master I will remove the Local Controllers from the Mobility Master's configuration (Web UI - MM - Configuration - Controllers - Delete the MD).

4.  That should stop communication/synchronization from the mobility Master and those specific MDs.

     a.  At that point the Aruba Web User Interface will display the MAC address of those controlelrs from the Group Level.

5.  Then ship the controllers to their destination and when I arrive at that destination, I will need to logon locally to the MD from the command line.

    a.  I will need to perform a local-confg enable<Enter>.

    b.  Then make configuration changes to the controller's local IP address.

    c.  The make cahnges to the controller's ip-default gateway.

6.  Then connect the local controller and make sure it is accessble on the local network.

7.  Then add the IP-Based IP Sec Key on the MM for the controller's new IP address.  The PSK will remain the same as what it was before.

My opinion:

You can:

- Setup the controller as a standalone controller with temporary ip address, etc at the HQ site using the console.  Reboot.

- Upgrade the ArubaOS code using a usb key plugged into the controller

("dir usb: partition 1" to see the contents of your USB key plugged into the controller.  "copy usb: partition 1 ArubaOS_blahblah system: partition 0")

- Wait for the upgrade to finish successfully.

- Do a write erase all, then type "halt" so that the controller shuts down.

- Ship the Controller to the new site

- Go through the Wizard on the console with the correct ip address/subnet mask/default gateway/PSK with ip, I guess

- Reboot and it should connect to your MM.

- If you don't have the mac address already in the MM, it will be "parked".  (type "show switches debug" on the MM to verify that it has connected to the MM with "UNK" ) on the MM where you can whitelist by mac address and it will move it into the destination folder you specify with a reboot.

- ***Don't use local configuration****  It is only for a last resort and just complicates your configuration.

I have 1 quesitons about your reply.

1).  When will I type 'halt' after the write-erase?  Immidately after the 'Enter' trigger for the write erase?

       a. Or wIll I be prompted to type halt?

       b. WiIl I need to hit the enter key right away after I type 'halt'?

       c. I would hate to type halt and then ship the unit to teh destinatin and the controller does not respond at all.

2).  If I use local-config enable<enter> to change the IP address of the controller will I be able to change the IP address later from the MM side?

Or will I need to change the IP address on the local controller by using the local-config enable command in the future?

1.  You can type "halt" after write erase.  Halt will tell you when you can shut down the controller after.  This is to make sure it shuts down properly.

2.  If the ip address of the controller is not specified in the global config, the controller will take the ip address from the startup wizard and it will "stick".  When you first provision the controller as a standalone, the ip address does not matter, because you are upgrading the AOS code using the usb and you are typing "write erase all" after.  You might ask, why not put the ip address and PSK in when upgrading the code and make it an MD? You can certainly try that.  The global configuration can certainly override the ip address later when the MD connects to the MM, but it is risky.  I would rather program the ip address of the MD with the startup wizard so that there are no issues, and I don't have to use local-config to rescue it, which can be a pain.

OK,

1).  What if I just type >write erase<enter> insterad of write erase all<enter>?

      a.  Then, when prompted type >halt<enter> ?

That way I can setup local database user accounts early on and not have t re-enter them when I am on-site.

2).  For argument, when you use local-config enable and change a configuration, does that prevent any future configuration changes for that area to come from the MM?  Is that one of the ways it is more confusing? 

3).  You mentined the 'Global Configuration' and that it can overide the local configuration.  Do you mean the configurations that are propagated dwon to the MD when the MM are synched up to each other?

OK, my new plan is summarized below.  Thank you Cjoseph for your input and ideas:

1. Connect each new local with a temporary IP address when at the HQ Site.
a. Update the version of the MD operating system and join the MD's to the Mobility masters.

2. Create the appropriate MD-Groups below the Manged Network section.
a. Then synch up the the MD's to the Mobilty Master and then add each MD to the final destination MD Group.
b. The Hostname will not change but the IP address will eventualy change.

3. After verifying that the communication works between the new MDs and the Mobility Masters and the licenging is up to date on the Mobility Master I will remove the Local Controllers from the Mobility Master's configuration.
a. Navigate to Web UI - MM - Configuration - Controllers - Delete the MD.

4. Then, I will execute>wite erase<enter> from the local controllers that weill need ot be shipped elswhere.
a. Then execute >halt<enter> for each controller.
b. This will power off the controller.

5. Then ship the controllers to their destination and when I arrive at that destination, I will need to logon locally to the MD from the console port.
a. Proceed to enter the new full-setup information.
b. verify that the local controllers is correctly on the network.

6. Then navigate to the MM's Web UI - MM - Configuration - Controllers and add the new controllers IPsec tunnel information.
a. The MM will try to synch up with the local controllers and propagate the configurations that were in place earlier.

7. Test, test and test.
a. Restart the controllers and verify that everthing is working as expected.

You are not saving any time staging the controller at HQ.  Most of the time will be consumed by reboots.  You might as well just do it once at the destination, really.  "write erase all" means that you will have to do everything over again, anyways.  Just do it once at the destination (bring up MD, point it to MM, upgrade code, done).

Well a lot of configuration can be entered from the MM side to the Local Controller after they are placed in the Managed Device Group from the MM Web UI.  When we get to the destination location our time is limited every day because of security reasons.  We want to have as much of the little things already configured on the MM side.  Then when the MD re-synchs back up it wll download those configurations.  Our time will be limited.

The only quesiton that I have now is.

1.)  Is the process above basically the same as if one connects an MD to the Mobility Master.  Then removes the MD from the MM IP Sec configuration from both sides (MD and MM) and then re-adds the MD to the MM configuration (on both devices) after a write erase of the MD? 

We needed to do that at another remote site becuase of communication issues and removing the IP Sec tunnel from both the MD and the MM and trying a different IP Sec key worked.  I think it is the same thing.  Hopefully...

The majority of the configuration can be entered at the group (folder) level before the controller even joins.  The rest can be entered after the controller joins (specific ip addresses of vlans, for example).  When you join a controller with a PSK, the controller is listed as "UNK" until you add the controller's wired mac address to a specific folder.  When it is added via it's wired mac address to a folder, the controller will get all the configuration in that folder.  You can then navigate to the controller in the folder structure and configure specific ip addresses and even port configuration.  That configuration will then get pushed to the controller.  The ip address, subnet mask and default gateway that you assign to a controller using the console setup is automatically added to the controller's configuration and you don't need to re-configure that on the MM after the controller is joined.  You would just have to "cd" to the controller's folder on the MM to add all of the other port/ip address configuration for the controller.

There is no real advantage to pre-staging a controller.  You should just do it onsite.

Again, please reach out to your Aruba Sales Engineer so that you can deploy your network in the most efficient manner.  At this point, the strategy to deploy should be fully understood so that deployments at remote sites would be fairly straightforward.

I like that idea of pushing the configuration to the folder.

Some of the required configuration will be done on the MM - MN - Folder/Group - MD level (Such as assigning an IP address for a VLan to this specific MD and a different IP address to another MD in that fsame older).

But a lot can be done from the folder level. 

Then I can bring up the Controllers in stand alone mode instead of MD and upgrade the OS that way.  Then do a >write erase<enter> and >halt<enter>

I still want to add the local user accounts on the controller ahead of time and tht is why I thk the >write erase<enter> may work better fo me instead of >write erase all<enter>. 

This has been a very usefull and benefitial question.

What local user accounts?

Please contact your Aruba SE or a VAR to help you.  I am afraid that I am giving you advice without context that could be harmful instead of helpful in the long run.

You really should ship the controller to the site and provision/upgrade it there.  No need to configure the MD as standalone.  No need to do a wirte erase all. You can add a MD to an MM as long as the MM has newer code than the MD.  You would then upgrade the firmware on the MD and then you would be fine at the remote site.  You would typically add the licenses/license pools to the MM so that another MD would automatically take licenses from the pool on the MD, so no need to install those.  

There is no advantage to staging the MD at HQ.  I apologize for giving you that advice.

You have been helpful Cjoseph,

1.  The user accounts to be used are regarding the 2-factor Authentication that we use with MAC addresses. 

    a.  We have a few deives that are specific to the location and we want to use MAC Authetication in addition to a password.  

    b.  It is working well with our already deployed Aruba wireless sites and it was in place with the previous Wireless system.

2.  If we have limited time to get things done at a location having the controllers already upgrded before hand will help.

     a.  Also having the MAC addresses entered ahead of time will help as well.

3.  My manager is insisting I do this and I do not want to disspoint in my preparation.

This was a valuable discussion and helpful in preparing for the setup.  I will try to verify my plan with a more experience ARuba Engineer that has actually done this before.

Thank you for your time.  My plan now is:

1. It is stated that it would be best not to update the AP's before you arrive at the location.
a. At another lcoation the AP-345's came with version 8.0 and when they connected they were already in Campus mode (not Instant mode) and tehyupdated automatically to the version teh controlelr was on (8.3).

b.  It took about 2 minutes adn 50 seconds per AP.

c.  Only connect the new AP's to the network after the new controllers are on-line on that VLan.

2. Connect each new local Controller and set it up in a Standalone Mode with a temporary IP address when at the HQ Site.
a. Update the version of the MD operating system.
b. I would image that I can use the web UI to do this as well.

3. Setup any local user accounts on the Standalone local controllers that are necessary
a. Setup the guest local user account.
b. Verify that it can boot up correctly and be accessible from the web UI and putty.

4. Document the Aruba controller MAC addresses Assocaited with the HOSTNAME.
a. One will need to refer to that later.

5. Create the appropriate MD-Groups in the MM, below the Manged Network section.
a. Add the necessary onfiguraitons on teh group level.
b. I will not be able to do everything but it wil lbe a good start before arriving at the final location.

6. Then, disconnect the controllers from HQ network and connect to the controller from console connection.
a. Execute>wite erase<enter> from the local controllers.
b. Then execute >reload<enter>.
c. Now enter the Destination Hostname and IP and information.
d. Make sure you have a good record of the Hostname and its MAC address.
e. Verify that all of the local user accounts are still there after the write erase.

7. Then ship the controllers to their final destination.
a. Then when on site, connect to the controller via console port.
b. Power on the controller to verify the IP information or setup the information.
b. Then start continuous pings and plug in the controller to the network and verify lnetwork communciation.
c. Verify that communication works and that you can login locally via putty and web ui.

8. Then navigate to the MM's Web UI - MM - Configuration - Controllers and add the new controllers IPsec tunnel information.
a. Try restarting the MD and verify the communications works as expected.
b. Then add the controller to the correct MD Group.
c. The MM will try to propagate the configurations that were in place earlier.
d. Monitor the progress.

The plan of setting up the controllers initially in 'StandAlone' mode worked very well.

That allowed me to upgrade the firmware version and then I was able to assign the final destination IP address and gateway for teh remote site.

I eventually shipped the controllers to the final desination and verified the IP address while on-site and then racked and connected the controllers while I was on site.

The controllers were immidately on-line and I then configured the MM to synch with the new controllers.  After the MM recongized and was abel to communicate with the local controllers I added the new local controllers to the MD groups from the Mobility Master Web UI.

Then all of the inhertited configurations from the MD grop were saved to the new local controlelrs and I was abel to maek new configuraiton changes to those controllers. 

The above mentione plan provided by Cjospeh worked like a champ and saved some inital setup time when it really mattered.  The main time saved was from updating the firmate on the controllers.