Mod15MBC Master Local Operation 6.3 v1.3

Aruba Bootcamp – Master-Local Operation

y l n O l Use

a n r e t In

y l n O e s U l a n r e t In

CONFIDENTIAL © Copyright 2014. Aruba Networks, Inc. All rights reserved

15-1


y l n O l Use

a n r e t In



15-2


y l n O l Use

a n r e t In


You may choose to deploy multiple controllers to scale your network to support the number of users or the amount of bandwidth that you may require. When deploying multiple controllers, there is usually a master controller (maybe a backup) and local controllers. There may be only one local, or many, depending upon your network requirements. When you have a master/local architecture, you create global configurations on the master. When you save the config on the master, the global settings such as firewall, VAP and others, get pushed to the local controllers.


15-3


y l n O l Use

a n r e t In


Masters and locals communicate with each other over a secure connection. PAPI traffic is carried through this IPSec tunnel. The tunnel is not used to carry user data. The tunnel parameters must be provisioned on both the local and master controllers. But the local controllers instantiate the tunnel.


15-4


y l n O l Use

a n r e t In


You can use a common key between your master and all locals, or you can define unique keys. Unique keys are highly recommended for security.


15-5


y l n O l Use

a n r e t In


Centralized licensing allows licenses to be shared among multiple controllers with a master/local relationship, Here are some best practices for Centralized Licensing in a Master/Local Topology

•  The entire cluster should be upgraded to a release supporting centralized licensing (6.3). •  Any controller that is not running the 6.3 release will not be a part of centralized licensing. •  The master controller should be upgraded before the local. •  Enable centralized licensing on the master controller.


6

15-6


y l n O l Use

a n r e t In


Using centralized licensing licenses can also be shared between master controllers. Enabling the centralized license feature will not result in IPSEC tunnels being established between the master controllers. (Optional) Establish secure IPsec tunnels between the primary licensing server controller and the licensing client controllers by enabling control plane security on that cluster of master controllers, or by creating site-to-site VPN tunnels between the licensing server and client controllers. This step is not required, but if you do not create secure tunnels between the controllers, the controllers will exchange clear, unencrypted licensing information. This step is not required for a master-local topology.


7

15-7


y l n O l Use

a n r e t In


Centralized licenses are configured and controlled using a license pool from which the controllers can draw their licenses. Additional licenses can be installed directly on a controller and not as part of the centralized license pool. These additional licenses do not go into the pool and are only used by the single controller where they are installed.


8

15-8


y l n O l Use

a n r e t In



9

15-9


y l n O l Use

a n r e t In


A standby license sever can be configured in the event of a failure on the master license server.


10

15-10


y l n O l Use

a n r e t In

y l n O e s U l rna to operate with the tecontinue LocalsIn will

If a master license server fails with no standby server present the local controllers will continue to use licenses from the pool for a limited period of time.

1. 

last received pool capacity for 30 days

2.  After 30 days, any shared licenses will be deleted and the box will revert to whatever licenses were originally installed on the CONFIDENTIAL © Copyright 2014. Aruba Networks, Inc. All rights reserved

11

15-11


y l n O l Use

a n r e t In



12

15-12


y l n O l Use

a n r e t In


WebUI configuration for centralized image upgrade is under the Maintenance page.


13

15-13


y l n O l Use

a n r e t In


The upgrade status can be seen on the maintenance page.


14

15-14


y l n O l Use

a n r e t In



15-15


y l n O l Use

a n r e t In


Prior to AOS 6.3, when the image on the controller is upgraded, the APs associated to this controller download their images AFTER the controller reboots and comes up with the new image. Once the AP downloads the new image, it needs to reboot and complete the AP boot process (network discovery, connect to LMS IP, check image and config, build PAPI/GRE tunnels to LMS) before it can become operational and start serving WLAN clients.

With AOS 6.3, the AP Image Preload feature minimizes the down=me required for a controller upgrade by allowing the APs associated to that controller to download the new images BEFORE the controller actually boots with the new image. NOTE: Only supported on 3600, M3, and 72x0 series controllers.


16

15-16


y l n O l Use

a n r e t In


Start by upgrading a partition on the controller to the desired SW version but do not reboot. To Enable AP Image Preload:

1. 

Navigate to Maintenance-‐>Preload AP Image

2. 

Click on “here” to Ac=vate AP Image Preload.

3. 

Point to the correct par==on.

4.  Select APs: It is possible to choose selec=ve APs for Image Preload. APs can be speciﬁed as follows: •  All APs associated to the controller •  A list of AP Groups •  Individual APs (by 'ap-‐name') 5.  Based on the exis=ng load on the controller, it is possible to specify how many APs can


17

15-17


y l n O l Use

a n r e t In


Multiple controllers implies that you will have APs terminating on more than one controller. In order to do this, you need to create multiple AP groups. Each group will have a unique LMS-IP address setting defining where the AP should terminate its GRE. There may be other settings you will want to change as well. These choices will depend upon your network’s requirements.


15-18


y l n O l Use

a n r e t In


When you configure AP groups on the master, all of the group settings get pushed to all local controllers. This occurs when the configuration is saved on the master controller. Each controller may not actually need to use every group. But all groups are pushed to all controllers to support AP provisioning.


15-19


y l n O l Use

a n r e t In


In this illustration, only the highlighted AP Groups are used on each of the controllers. Yet each controller knows about ALL AP Groups to assist in the AP boot provisioning process.


15-20


y l n O l Use

a n r e t In


When you have multiple controllers, you need to specify where the APs should build their GREs. You do that by setting the LMS-IP address under the AP system profile. Remember, this affects all APs assigned to this group.


15-21


y l n O l Use

a n r e t In


The New York and the Miami controllers have multiple differences in this case beyond LMS-IP. They also advertise different SSIDs and use different vlans. These changes require different AP groups to ensure the settings are localized to that group of APs or that geography.


15-22


y l n O l Use

a n r e t In


VLAN pooling assists in larger deployments within a single building by allowing multiple VLANs to support a single SSID. Users will be assigned to their VLAN based upon their MAC address. When the client associates to the AP, the controller looks at the client MAC, hashes the value, and assigns the VLAN. The VLAN will remain constant within the building as long as the MAC address and the number of VLANs remain the same. This provides a client distribution across the different broadcast domains within the VLAN pool. It does not guarantee load distribution though.


15-23


y l n O l Use

a n r e t In


Here we wish to segment the users across multiple vlans to provide broadcast domain segmentation for a single SSID.


15-24


y l n O l Use

a n r e t In



15-25


y l n O l Use

a n r e t In


To create a VLAN pool, simply add multiple VLANs to the VAP profile.


15-26


y l n O l Use

a n r e t In


Named VLANs provide an efficient way of creating VAPs by associating the VAP to a VLAN by name rather than a VLAN number. This simplifies configuration and helps when configuring redundancy where backup VAPs on different controllers are supported by different VLAN IDs. Named VLANs can also be used in a RADIUS server VSA.


15-27


y l n O l Use

a n r e t In


As a simple example of using Named VLANs, consider this case where we have three controllers. Each of them needs to advertise the same SSIDs. By using named VLANs the VAP configuration for each group is constant. Without Named VLANs, you would need to create 3 VAPs to identify the VLAN settings.


15-28


y l n O l Use

a n r e t In


Named VLANs can be used in a limited set of configurations. Reference this chart for details.


15-29


y l n O l Use

a n r e t In


Named VLANs can be created in the CLI as illustrated on this page.

Hash type Even: Sets the assignment type as even.The Even assignment type is based on an even distribution of VLAN pool assignments. Hash type Hash: Sets the assignment type as hash. The hash type means that the VLAN assignment is based on the station MAC address.


15-30


y l n O l Use

a n r e t In


You can also create Named VLANS in the WebUI. It is actually done under the VLAN Pool Tab.


15-31


y l n O l Use

a n r e t In



15-32


y l n O l Use

a n r e t In



15-33


y l n O l Use

a n r e t In



15-34


y l n O l Use

a n r e t In



15-35


y l n O l Use

a n r e t In



15-36

Mod15MBC Master Local Operation 6.3 v1.3

Recommend Documents