Aruba Instant Validated
Reference Design
Version 1.0.1
Authors:
Vishal Mann
Sathya Narayana Gopal
Aruba Instant Validated Reference Design
Contributors:
Yan Liu
Naveen Manjunath
|1
Copyright
© Copyright 2016 Hewlett Packard Enterprise Development LP
Open Source Code
This product includes code licensed under the GNU General Public License, the GNU Lesser General Public
License, and/or certain other open source licenses. A complete machine-readable copy of the source code
corresponding to such code is available upon request. This offer is valid to anyone in receipt of this information and
shall expire three years following the date of the final distribution of this product version by Hewlett-Packard
Company. To obtain such source code, send a check or money order in the amount of US $10.00 to:
Hewlett-Packard Company
Attn: General Counsel
3000 Hanover Street
Palo Alto, CA 94304
USA
Please specify the product and version for which you are requesting source code. You may also request a copy of
this source code free of charge at dl-gplquery@arubanetworks.com.
Aruba Instant Validated Reference Design
|2
Contents
About this Guide
9
Intended Audience
9
Scope
9
Related Documents
9
Conventions
9
Introduction to Aruba Instant
11
11
Introduction
11
Aruba Instant
12
Aruba Instant Architecture
12
Management Plane
12
Control Plane
12
Data Plane
13
Virtual Controller
13
Preferred Master
13
Cluster mechanics
14
Virtual Controller IP Address
14
Role of a Virtual Controller
14
Management plane functions of a virtual controller:
14
Instant communications
15
Intra cluster communication
16
Inter cluster communication
17
IAP & AirWave
17
IAP & RADIUS server
17
IAP & XML API
18
IAP & Activate/Provisioning server
18
IAP & VPN end point
18
IAP & Web CC lookup
18
IAP & SNMP/syslog communication
18
Instant Access Points Portfolio
19
How Instant Solution fits into needs of various Enterprises
22
Aruba Instant Solution for Small and Medium Enterprises
22
Aruba Instant Solution for Distributed Enterprises
25
Aruba Instant Solution for Hybrid Deployments
27
Designing Enterprise Networks with Aruba Instant
28
Aruba Instant Solution Basic Concepts
28
VLANs in an Aruba Instant Cluster
28
Client IP assignment with the “Virtual Controller assigned” option
29
Client IP assignment with the “Network assigned” option
30
Aruba Instant Validated Reference Design
|3
Traffic Flows in an Aruba Instant Cluster
31
AP Traffic
31
Client Traffic
31
Dynamic RADIUS Proxy
32
Layer 3 Mobility
33
Physical and Logical Design
33
Wired Infrastructure Design
Recommendations for an Uplink Management VLAN
35
Uplink Management VLAN
35
Client VLAN Design
35
Cluster Design
36
Cluster Design for Single-Building Layout
36
Cluster Design for a Multi-Building Layout within a Contiguous RF Domain
37
Cluster Design for a Multi-Building Layout with a Non-Continuous RF Domain
37
Cluster Design for a K-12 School District
37
Cluster Security Recommendations
38
RF Design
39
Radio Modes on Aruba Instant
40
Scanning of IAPs
40
AP Scanning (Access Mode)
41
AM Scanning (Monitoring Mode)
41
Spectrum Monitoring (Spectrum Monitor mode)
42
Adaptive Radio Management
42
Additional RF Optimization Features
44
Client Match
47
Recommended IAP Settings
48
QoS Design
50
End-to-End QoS
50
QoS on the WLAN
51
QoS on the LAN Edge and Core
51
Aruba QoS Features
51
Stateful Firewall
51
Media Classification
52
Bandwidth Management
52
Application Bandwidth Management
52
User and Network Bandwidth Management
53
Dynamic Multicast Optimization (DMO)
57
ARP Broadcast Filter
58
Design for Plug-and-Play Services
59
Challenges with Multicast DNS
59
The AirGroup Solution
60
AirGroup Capabilities Supported by Aruba Instant
60
AirGroup Solution Architecture
61
AirGroup in a Single IAP Cluster
4|
34
61
Aruba Instant Validated Reference Design
AirGroup in a Single IAP Cluster with ClearPass Policy Manager
61
AirGroup in Multiple IAP Clusters
62
AirGroup Recommendations
64
Configuring AirGroup
65
Enabling AirGroup
65
Filtering Services Based on User Role
66
Filtering Services Based on VLANs
67
Creating a “Personalized” WLAN: Registering Personal and Shared Devices on ClearPass
69
Extending an AirGroup across Instant Clusters
71
Content Filtering using Open DNS
73
Security Design
75
Authentication and Encryption
75
Authentication and Encryption for an Employee SSID
75
Authentication Methods
75
Authentication Recommendations
76
Encryption Levels
77
Encryption Recommendations
78
Authentication and Encryption for a Guest SSID
78
Authentication Methods
78
Authentication Recommendations
79
Encryption Levels
79
Encryption Recommendations
79
Wireless Intrusion Detection and Prevention
Intrusion Detection System (IDS)
80
80
IDS Dashboard
80
IDS Wizard
81
Aruba IDS Recommendations
Intrusion Prevention System (IPS)
81
82
IPS Wizard
82
Aruba IPS Recommendations
83
Designing Distributed Enterprise Networks with Aruba Instant
Branch Office Deployments
84
84
Single AP Branch
85
Multi AP Branch
85
Hierarchical Mode Design
86
Flat Mode Design
87
MPLS-Based Branch Deployments with Aruba Instant
Use Case 1: Wireless Employee Access and Guest Access
88
89
Use Case 2: Wireless Employee Access and Guest Access with the Ability to Tunnel the Guest Traffic to
a Central DMZ
89
VPN-Based Branch Deployments with Aruba Instant
91
Understanding Instant-VPN (Aruba Instant-VPN in a Nutshell)
92
Licensing
92
WLAN Controller Scalability for Instant-VPN deployments
93
Aruba Instant Validated Reference Design
|5
AP Selection for Instant-VPN Deployments
94
Firewall Ports
94
Understanding Instant-VPN Modes
94
Instant-VPN: Local Mode
97
Instant-VPN: Centralized L2 Mode
98
Instant-VPN: Distributed L3 Mode
100
Branch-ID Allocation Algorithm
102
BID Allocation Process Details
102
MAX-BID Calculation Examples
104
Traffic Flow and Uplink Switch Requirements for a Multi-AP Aruba Instant-VPN Network
105
802.1X and RFC 3576 Handling in an Aruba Instant-VPN Network
106
DNS Handling in an Aruba Instant-VPN Network
107
Control Traffic between an Aruba Instant-VPN Branch and the WLAN Controller
108
Redundancy Design for Aruba Instant-VPN Deployments
109
Single Data Center Deployment with Redundancy
110
Multiple Data Center Redundancy (Geographical Redundancy)
110
Designing Instant-VPN Deployments
111
Single-AP Branch with a Single Data Center
112
IAP Setup (Single-AP Branch with a Single Data Center)
113
Data Center Configuration (Single-AP Branch with a Single Data Center)
114
Single-AP Deployment with Multiple Data Centers
115
IAP Setup (Single-AP Branch with Multiple Data Centers)
116
Data Center Configuration (Single-AP Branch with Multiple Data Centers)
118
Multi-AP Deployment with Single Data Center
118
IAP Setup (multi-AP Deployment with a Single Data Center)
120
Data Center Configuration (Multi-AP Deployment with a Single Data Center)
122
Uplink Switch Setup (Multi-AP Deployment with a Single Data Center)
122
Multi-AP Deployment with Multiple Data Centers
IAP Setup (multi-AP Deployment with Multiple Data Centers)
124
Data Center Configuration (Multi-AP Deployment with Multiple Data Centers)
126
Uplink Switch Setup (Multi-AP Deployment with Multiple Data Centers)
126
Designing Home Office Deployments with Aruba Instant
127
Configuring the WLAN Controller for Instant-VPN Deployment
127
Defining the VPN Pool on a WLAN Controller
128
Adding IAPs to RAP Whitelist
130
Configuring VLANs for Layer 2 Modes
131
Configuring OSPF Route Redistribution of Layer 3 Branch Routes
131
Configuring the Controller to Perform Source NATing for 802.1X and RADIUS Traffic from Branches
132
Configuring an IAP for Instant-VPN Deployment
136
Defining the VPN Host Settings
136
Configuring a Routing Profile
138
Controller Redundancy Example 1
139
Controller Redundancy Example 2
139
Configuring DHCP Profiles for Instant-VPN Modes
6|
122
141
Aruba Instant Validated Reference Design
DHCP Profile for Local Mode
142
DHCP Profile for Centralized L2 Mode
144
Network Tab
145
Branch Size Tab
147
Static IP Tab
148
Configuring an SSID or Wired Port for Instant-VPN
149
Enabling Dynamic RADIUS Proxy (DRP)
150
Configuring Enterprise Domains (Split-DNS)
151
Aruba Instant management using Aruba AirWave
152
Communication Concepts
152
Adding IAPs to AirWave
153
Manually Adding an IAP through the VC WebUI
153
Provisioning an IAP through Aruba Activate
154
Add Devices in Activate
154
Create Folders in Activate
155
Create provisioning rules in Activate
156
Assign Devices to Folders in Activate
158
Provisioning an IAP through DHCP Options
160
AirWave prerequisites
162
AirWave whitelist
163
Adding devices to the whitelist
163
Manually on AMP GUI
164
Import through Activate
164
In bulk through CSV file
165
AirWave in DMZ
165
Organization String
167
Setting up Groups, Folders and Roles in AirWave
167
Groups
168
Folders
168
Roles
169
Managing Device Firmware with AirWave
170
Setting up AirWave to Automatically Update Firmware on New Devices
170
Bulk Upgrades of IAPs
171
Monitoring Firmware Upgrade Jobs
172
Managing Device Configurations with AirWave
173
AirWave use cases
175
AirWave for the Distributed Enterprise
175
AirWave for the Small and Medium Enterprise
176
AirWave for a Home Office
178
Network Visibility using AppRF on Aruba Instant
AppRF on Instant Access Points
Introduction
179
179
179
DPI
180
Web Content Filtering
181
Aruba Instant Validated Reference Design
|7
Categories
181
Reputation
181
Configuration
184
Enforcement through policies
184
Visibility in UI
185
Per AP view
185
Per client view
186
Per SSID view
186
App RF tab details
186
Troubleshooting
Show commands
188
Traces
189
Appendix
191
Performance impact due to DPI
191
Custom error page
191
Websites dependency on web category
193
Terminology
8|
188
196
Acronyms and Abbreviations
196
Glossary
197
Aruba Instant Validated Reference Design
Chapter 1
About this Guide
The Aruba Validated Reference Design (VRD) series is a collection of technology deployment guides that include
descriptions of Aruba technology, recommendations for product selections, network design decisions, configuration
procedures, and best practices for deployment. Together these guides comprise a reference model for understanding
Aruba technology and designs for common customer deployment scenarios. Each Aruba VRD network design has
been constructed in a lab environment and thoroughly tested by Aruba engineers. Our customers use these proven
designs to rapidly deploy Aruba solutions in production with the assurance that they will perform and scale as
expected.
This VRD describes Aruba Instant, the easiest way to get enterprise-grade Wi-Fi up and running. Aruba Instant,
delivers a controller-less Wi-Fi solution that is easy to set-up, and loaded with security and smarts needed to
accelerate your business without breaking your budget.This guide provides an overview of Aruba Instant solution,
and describes the different use cases and deployments, as well as configurations and recommendations.
Intended Audience
This guide is intended for administrators who are responsible for deploying and configuring Aruba Instant devices in
customer premises.
Scope
This is a base design guide for Aruba Instant, and hence will not cover the fundamental wireless concepts. Readers
should have a good understanding of wireless concepts and the Aruba technology.
Related Documents
In addition to this document, the IAP product documentation includes the following:
l
Aruba Instant User Guide
l
Aruba Instant CLI Reference Guide
Conventions
The following conventions are used throughout this manual to emphasize important concepts:
Aruba Instant Validated Reference Design
About this Guide | 9
Table 1: Typographical Conventions
Style Type
Description
Italics
This style is used to emphasize important terms and to mark the titles of books.
System items
This fixed-width font depicts the following:
l
Sample screen output
l
System prompts
l
Filenames, software devices, and specific commands when mentioned in the text.
Commands
In the command examples, this style depicts the keywords that must be typed exactly as
shown.
<Arguments>
In the command examples, italicized text within angle brackets represents items that you
should replace with information appropriate to your specific situation. For example:
# send <text message>
In this example, you would type “send” at the system prompt exactly as shown, followed by
the text of the message you wish to send. Do not type the angle brackets.
[Optional]
Command examples enclosed in brackets are optional. Do not type the brackets.
{Item A |
Item B}
In the command examples, items within curled braces and separated by a vertical bar
represent the available choices. Enter only one choice. Do not type the braces or bars.
The following informational icons are used throughout this guide:
Indicates helpful suggestions, pertinent information, and important things to remember.
Indicates a risk of damage to your hardware or loss of data.
Indicates a risk of personal injury or death.
10 | About this Guide
Aruba Instant Validated Reference Design
Chapter 2
Introduction to Aruba Instant
This VRD provides details about the Aruba Instant solution. Table 1 Software Versions lists the software version for
this guide.
Figure 1 Table 1 Software Versions
Product
Version
ArubaOS (Mobility Controller)
6.4
Aruba InstantOS
4.2
Introduction
During the early days of Wi-Fi, wireless networks were designed to be convenience networks and they were not
mission-critical. It was very common even for a large organization to deploy just a few APs in areas such as lobbies,
cafes, and CTO offices. This deployment allowed network administrators to build wireless networks using fat APs
(also known as autonomous APs) because performance, quality of service (QoS), mobility scalability, and
manageability were not critical. To deploy fat APs, the IT staff had to manually configure each and every AP that
was deployed. However, as wireless technology progressed and as organizations discovered the advantages of
wireless networks, the scale of wireless deployment grew. As deployment sizes grew, scalability and manageability
became major issues with the fat AP technology. This demand led to the evolution of controller-based WLANs with
thin APs.
In controller-based WLAN technology with thin APs, the management and control plane functions are centralized at
the controller and the data plane is either centralized or switched locally at the APs, based on the mode of operation.
Controller-based WLANs allow WLANs to scale to thousands of APs and provide a single point of management and
configuration for the entire network. The development of controller-based WLAN technology greatly helped in the
adoption of wireless networks. The controller-based solution could be deployed easily as overlay architecture
without any overhaul to the existing wired network. Today, WLAN-based controller networks are, in fact, the
architecture that is used in these environments:
l
Government, department of defense, and other security conscious organizations that require central encryption
and decryption of wireless data
l
Large campuses such as university and enterprises, which scale to thousands of APs at a single location
l
Organizations with large Layer 2 domains that do not want a major overhaul, such as adding and deleting VLANs,
to their edge network
The Aruba controller-based architecture includes the ArubaOS™, Aruba controllers, and Aruba APs.
In the past few years, the advancements in AP hardware technology (such as chipsets and memory) have opened
up the possibility of a distributed WLAN system. Modern APs allow wireless vendors to distribute the management,
control, and data paths amongst APs without the need for a physical controller. This architecture is suitable for small
and medium-sized WLAN deployments and distributed enterprises that do not require the additional benefits of a
controller-based architecture but still require a feature-rich, enterprise-grade solution that can be managed from a
single interface. The Aruba answer to the controller-less architecture is Aruba InstantOS™ and Aruba Instant™ APs
(IAPs).
Aruba Instant Validated Reference Design
Introduction to Aruba Instant | 11
Aruba understands that the WLAN requirements of organizations vary and that the choice between a controller-less
and controller-based architecture depends on the type of organization and their WLAN requirements. Aruba is the
only WLAN vendor to offer the flexibility of both controller-less and controller-based architecture with no architecture
lock-in. Aruba also recognizes that, as organizations grown in size, they might want to move from a controller-less to
a controller-based architecture. In that respect, Aruba provides investment protection: if the requirements of your
organization change, you can convert Aruba IAPs to controller-based mode, which allows them to function with
ArubaOS controllers.
Aruba Instant
Providing wireless connectivity at remote sites has been a challenge for organizations with distributed locations,
such as retail chains and K-12 school districts. These organizations need robust WLAN functionality, including voice
and video optimization, high reliability, and strong security. They also need a solution that is affordable both to buy
and to operate in a distributed environment. The solution must be able to be deployed rapidly, and configured and
managed centrally. In addition to these requirements, certain organizations, like hotel operators, restaurant owners,
retailers, and other distributed enterprises, must comply with data privacy regulations such as the Payment Card
Industry (PCI), Data Security Standard, and HIPAA for healthcare. In general, these organizations need a featurerich, enterprise-grade WLAN that can be deployed rapidly at geographically-dispersed locations that have limited or
no on-site IT resources.
The Aruba Instant architecture is designed to address these situations. Aruba Instant combines enterprise-grade
WLAN performance, security, and scalability with industry-leading ease-of-use and affordability. With Aruba Instant,
the entire deployment process is automated, including zero-touch provisioning, firmware upgrades, and inventory
management. You can deploy thousands of Aruba IAPs cost-effectively anywhere in the world with unprecedented
speed and ease.
Aruba Instant Architecture
Aruba Instant consists of a family of high-performance controller-less Instant Access Points (IAPs) that run the
Aruba InstantOS to provide a distributed WLAN system. In an Instant deployment, all IAPs on the same Layer 2
domain form a cluster with one dynamically-elected AP that functions as the master. The master AP assumes the
role of virtual controller (VC) within a cluster. Aruba Instant is a distributed WLAN system with a completely
distributed control and data plane. However, certain network functions, such as monitoring, firmware management,
and source Network Address Translation (NAT) require a central entity within a cluster. The VC within a cluster
functions as this central entity. In an Aruba Instant cluster, if the master fails, another AP is elected as the master
and assumes the role of VC.
In general, you can divide the functions of a WLAN system into three planes: the management plane, control plane,
and data plane. Each Aruba Instant cluster handles the management, control, and data plane functions as described
in the following sections.
Management Plane
Aruba Instant has a centralized management plane. At a cluster level, the self-elected VC functions as the single
point of configuration for an IAP cluster. The graphical user interface (GUI) to the VC provides local configuration and
monitoring of an IAP cluster. Centralized configuration and management for multi-cluster networks are available
using AirWave® or Aruba Central™ (public cloud).
Control Plane
The control plane in an Aruba Instant cluster is completely distributed and handled by the individual IAPs. The
distributed control plane functions include:
l
Adaptive Radio Management (ARM)
l
Auto Channel/Power assignment
12 | Introduction to Aruba Instant
Aruba Instant Validated Reference Design
l
Intrusion detection system (IDS)/ intrusion prevention system (IPS)
l
Client handover
l
Deep Packet Inspection
The VC is not responsible for any of these functions. For example, the client database is entirely maintained in the
AP to which the client is connected. When a client roams, the new AP determines the last associated AP for the
client and requests all client information from that AP. The other IAPs send updates to the VC IAP periodically, only
for management plane reporting.
Data Plane
The data plane in an Aruba Instant cluster is also fully distributed, with a few exceptions. Each individual IAP
handles the traffic for the clients that are associated to that IAP. Firewall policies and bandwidth control are also
applied on a per-IAP basis. The flow of user traffic is not centralized to the VC. An exception to this rule is a magic
VLAN (also known as a VC-assigned VLAN). On an SSID that uses a magic VLAN for its clients, all IAPs forward
the traffic on that SSID to the VC, which performs NAT for the traffic. This process allows Layer 2 mobility for the
VC-assigned VLAN. Similarly, any traffic that must be source NATed by the Aruba Instant cluster also flows through
the VC. It is common to source NAT user traffic in remote deployments that have split-tunnel or bridging
requirements. For more information on the traffic flow in an Aruba Instant cluster, see Traffic Flows in an Aruba
Instant Cluster.
Virtual Controller
Aruba IAPs on the same Layer 2 domain form a cluster by electing one AP as the master AP, which functions as the
virtual controller (VC). The master election is based on a master election protocol. The election process to select a
master AP/VC is simple; the first IAP that comes online on the network is elected as the master AP/VC. If a master
AP/VC fails, a new AP is reelected as the master AP of the cluster. The master-reelection algorithm uses these
conditions during a VC failover:
1. An IAP with an alternative uplink (3G or 4G only) receives preference.
2. If an IAP with an alternative uplink is not available, an IAP with the more capable hardware/a newer model
receives preference in the following descending order:
[IAP225 & all the other newer models] > [IAP134/5 = RAP155] > [IAP104/5 = IAP175 = RAP108/9 = RAP3]
This rule is being used to distinguish only between older models & newer models.
3. If both of the previous considerations are not applicable, an IAP with the longest uptime receives preference.
In an Aruba Instant cluster, the master AP/VC failover time varies from 13 seconds to 100 seconds because the VC
election algorithm also takes the CPU load on the IAPs in the network into account.
The criteria for new VC election are used only in case of a VC failover for a new VC election. There is no preemption
if a new IAP is plugged into an existing network and meets any of the above-mentioned criteria.
Preferred Master
The master election and re-election process is the default behavior for IAP clusters. In addition to the default master
election algorithm, Aruba InstantOS 4.0 lets you manually assign the master AP role. Manual assignment works well
in an environment that requires a specific AP with a lower load, an AP with more capable hardware, or an AP with an
alternate uplink to always function as the master. The AP that you manually select as the master is known as the
preferred master. As long as the preferred master is online, it is the cluster master. If the preferred master goes down
because of an uplink failure, the default reelection algorithm elects a new AP as the master. When the preferred
master comes back online, it becomes the cluster master again, and the AP that was automatically elected as the
master through the reelection algorithm reboots to rejoin the cluster as a regular member AP.
Aruba Instant Validated Reference Design
Introduction to Aruba Instant | 13
Cluster mechanics
A preferred master will never lose its configuration or become a slave AP of another master, unless it is on factory
default configuration. It will either take over as master or become a single-AP cluster by itself. An existing AP that is
not a ‘preferred master’ can be pre-empted by a preferred master.
An IAP x, if connected to an active cluster (with an already elected master IAP y):
l
IAP x will have its configuration replaced by the master’s configuration, if the IAP x does not have ‘preferred
master’ enabled.
l
If IAP x, has preferred master enabled, then it will check if the existing cluster’s master AP y, has ‘preferred
master’ enabled or not.
l
If the existing cluster’s master IAP y, does not have ‘preferred master’ set, the new IAP x will take over as the
new master of the cluster & its configuration will be propagated.
l
If the existing cluster’s master IAP y, also has ‘preferred master’ set, then the new IAP x will come up as a singleIAP cluster by itself, if IAP x has a non-default configuration.
l
If the existing cluster’s master IAP y, also has ‘preferred master’ set, then the new IAP x will join the cluster as
slave, if IAP x has factory default configuration. IAP x will download the configuration of IAP y.
Virtual Controller IP Address
Like any other networking device, every AP in an Aruba Instant cluster has its own physical IP address. When an
IAP is connected to a Layer 2 network, the IAP uses a DHCP service to receive an IP address on the default VLAN
of the uplink port. You can also statically assign a physical IP address to individual APs. For information about
assigning IP addresses statically to an IAP, see the Aruba Instant User Guide that is available at the Aruba support
website. Aruba recommends the use of DHCP services to assign IP addresses to APs because it simplifies AP
deployment.
The master AP of the cluster assumes the role of the virtual controller. Every AP in an Aruba Instant cluster,
including the master AP, has its own physical IP address. In addition to the physical IP addresses of APs, an Aruba
Instant cluster also can be assigned a static IP address, known, for management purposes, as the VC IP address.
The VC IP address is a floating IP address (that is, a virtual IP address) that is used by an IAP if it is elected as the
master AP. The VC IP address is different from the physical IP address of the master AP. If an IAP is elected as the
master AP of a cluster, it takes ownership of the VC IP address. The master AP assumes the VC IP address and
updates the ARP cache of the upstream network by sending three gratuitous ARP messages with the VC IP
address and Ethernet MAC address of its uplink port (enet0).
By default, any other traffic from the AP is sent untagged by the IAPs. Examples of this traffic are RADIUS,
Syslog, and SNMP traffic as well as DHCP discover and request messages that are used to obtain the IP address
of the AP. You can modify this behavior in certain environments by changing the setting of the Uplink Management
VLAN feature. Aruba recommends that you set the uplink management to its default value and change it only in
environments that absolutely require it. For more information, see Uplink Management VLAN.
Role of a Virtual Controller
If an AP is selected as the master and it assumes the virtual controller role, the master AP performs the VC function
in addition to all the regular functions that are also performed by the member APs in the cluster. These functions are
the VC functions of a master AP in an Aruba Instant cluster:
Management plane functions of a virtual controller:
l
Aruba Instant cluster configuration synching: In an IAP cluster, you only need to configure the master AP that
functions as the VC. All other APs in the cluster download their configuration from the master AP. Any
14 | Introduction to Aruba Instant
Aruba Instant Validated Reference Design
configuration change that is pushed from the management platform or configured over the GUI of the VC is
synchronized to the other APs in the cluster.
l
Aruba Instant cluster monitoring: In an IAP cluster, the VC assumes the monitoring role. All APs in the cluster
periodically update the VC with their status. The VC consolidates all of this monitoring data, presents the data on
its local WebUI, and pushes the data to management platforms, such as AirWave and Aruba Central.
l
Aruba Instant firmware image management: The VC handles the image management in an IAP cluster. The
VC ensures that all APs in the cluster are upgraded to the correct image version before rebooting the cluster.
l
Communication with management platforms: Management platforms, such as AirWave and Aruba Central,
communicate only with the VC of the cluster. The VC sends periodic updates of cluster monitoring data to the
management platforms. Management platforms also push cluster configuration changes to the VC, which, in
turn, updates the other APs in the cluster.
Control plane functions of a virtual controller:
l
Dynamic RADIUS proxy (DRP): In an Aruba Instant cluster, the initial client authentication is handled by the AP
to which the client is connecting to and not by the master AP. This means that you must add each AP in an Aruba
Instant as a NAS client on a RADIUS server. In certain environments, you might not want to add each AP as a
NAS client. DRP makes the VC the proxy for RADIUS exchanges. When you enable DRP, all APs in a cluster
forward RADIUS exchange messages to the VC, which acts as a RADIUS proxy. For more information, see
Dynamic RADIUS Proxy.
l
Handling Change of Authorization (CoA): The RADIUS protocol, which is defined in RFC 2865, does not
support unsolicited messages that are sent from a RADIUS server to a network access server (NAS). However,
in certain circumstances, session characteristics might need to be changed without requiring the NAS to initiate
the exchange. The extensions that are defined in RFC 3576 allow a RADIUS server to send unsolicited
disconnect or CoA messages to a NAS. In an Aruba Instant cluster, the RADIUS server sends RFC 3576compliant messages to the VC, which then performs the necessary action.
l
DHCP server for client VLANs: When you configure the Aruba Instant cluster as the DHCP server for a specific
client VLAN, the DHCP server functions are handled by the VC.
Data plane functions of a virtual controller:
l
Handling traffic for magic VLANs and VLANs that are local to the Aruba Instant cluster: When you set up
an SSID on an Aruba Instant network, client IP address assignment can be set to the VC-assigned option. (This
configuration is also referred to as a magic VLAN.) If you select this option, the client obtains its IP address from
the magic VLAN of the master AP (that is, the VC). A magic VLAN is a private subnet that is created on the
master AP for client IP address assignment. A magic VLAN differs from a traditional VLAN. The client traffic on a
magic VLAN is always source NATed by the master AP and the master AP functions as the DHCP server for
magic VLAN. For more information about client IP address assignment using the VC-assigned option, see Virtual
Controller-Assigned IP Addresses.
l
Handling traffic for VLANs that are local to the Aruba Instant cluster: The Aruba Instant cluster lets you
define VLANs such as local, centralized Layer 2, distributed Layer 2, centralized Layer 3, and distributed Layer 3
VLANs. (For more information, see Understanding Instant-VPN Modes and Configuring VLANs for Layer 2
Modes.) The DHCP definitions for these VLANs reside on the Aruba Instant cluster. The client traffic on these
VLANs flows through the VC of the cluster. For more information about the traffic flow for these VLANs, see
Traffic Flows in an Aruba Instant Cluster.
l
Handling traffic when source NATing is required: In an Aruba Instant network, the VC performs source
NATing of any client traffic that requires it.
Instant communications
The following are the major entities with which an IAP in cluster communicates:
Aruba Instant Validated Reference Design
Introduction to Aruba Instant | 15
l
Master and Slave APs – Intra cluster
l
Between Master APs in a cluster – Inter cluster
l
IAP and Airwave server
l
IAPs and Radius server
l
IAPs and XML API server
l
IAPs and Provisioning server
l
IAP and VPN end point
l
IAPs and External Web Content classification lookup servers
l
IAPs and Monitoring servers (Syslog/SNMP)
Intra cluster communication
There are two major types of communication between APs in a cluster:
l
L2 Broadcast messages for cluster maintenance and roaming
Master AP sends out a Layer 2 “beacon” message every second to notify that the master AP is currently active. This
helps in new APs discovering the master and join the cluster & existing APs detecting master failover and take over
as master of cluster.
There is also a session request message for Layer 2 roaming. When a client roams between APs in a cluster, a
session request message is used to transfer client session and role data between APs
Sample frame for L2 communication:
l
L3 unicast messages between IAPs (master and slave)
UDP messages on port 8211 between master and slave APs for config sync, firmware upgrade and control-plane
messaging between APs.
Sample frame for L3 unicast communication:
16 | Introduction to Aruba Instant
Aruba Instant Validated Reference Design
Inter cluster communication
With L3 mobility is enabled, the master APs of each cluster communicate with each other to enable roaming of
clients. Mobility messages use a UDP message on port 8211 between the two master APs of the cluster. Following
the initial exchange, the Foreign AP sets up a GRE tunnel with the Home AP.
IAP & AirWave
IAP & RADIUS server
Based on the Radius proxy configuration, either the individual AP or the master AP communicate with Radius
server.
Two specific radius communication messages are possible:
l
Radius authentication requests using a configurable UDP port
l
Radius accounting requests using a configurable UDP port
Aruba Instant Validated Reference Design
Introduction to Aruba Instant | 17
RADSEC is a special type of Radius communication whose primary use case is to interface with Cloud Guest
Server. However, it is also possible to use RADSEC with any servers using a configurable TCP port.
IAP & XML API
l
IAP supports XML API interface to authorize role changes
l
XML API server communicates with IAP using SSL – TCP port 443
l
The communication can be secured using a shared key or can use clear-text
l
The servers allowed to communicate can be controlled by using a list of server IPs/subnets which can authorize
a change using XML API interface
IAP & Activate/Provisioning server
l
IAP communicates with an Aruba owned provisioning server for provisioning, periodic reporting and firmware
checks
l
This uses DNS for resolution of server IP and all communication uses SSL (TCP port 443)
IAP & VPN end point
l
IAP supports VPN termination using either IPSec or GRE
l
GRE termination is supported with both Aruba and Non-Aruba devices supporting standard EoGRE
l
GRE using Aruba GRE uses UDP 4500 for secure control channel establishment with controller and uses GRE
with configurable GRE type for all data connection
l
GRE using Manual GRE uses GRE with configurable GRE type for all data connection
l
IPSec termination is supported using either Aruba controller with Certs or Standard VPN end points for PSK
l
IPSec with Aruba controller uses certs stored in secure TPM of AP for IKEv2 using NATT (UDP 4500)
l
IPSec with Third-party devices only supports PSK based IKEv2
IAP & Web CC lookup
l
AppRF service on IAP uses a third party lookup service.
l
The communication with that service involves DNS resolution to aruba.brightcloud.com and a HTTP lookup for
content classification
IAP & SNMP/syslog communication
l
IAP can be configured to use syslog server which uses UDP port 514 for communication
l
IAP uses UDP ports 161/162 for SNMP services (polling and sending traps)
18 | Introduction to Aruba Instant
Aruba Instant Validated Reference Design
Instant Access Points Portfolio
The Aruba AP product line includes the traditional controlled-based APs, Aruba Instant APs (IAPs), and remote APs
(RAPs). Aruba controller-based APs start with part number AP-xxx, the IAPs with part number IAP-xxx, and RAPs
with part number RAP-xxx. A controller-based AP that has the same model number (that is, the xxx in the part
number) as an Instant-based AP has the same hardware specifications. For example, the controller-based AP with
part number AP-135 has the same hardware specifications as the Instant-based AP with part number IAP-135. The
key difference with an IAP is that it ships with Aruba InstantOS and, if needed, can be converted to a controllerbased AP. All new RAP models also ship with Aruba InstantOS and, if needed, can be converted to controller-based
RAPs.
You cannot convert a controlled-based AP (for example, the AP-135) to an Instant-based AP.
Aruba Instant summarizes the different Aruba Instant AP models.
Table 2: Aruba Instant APs
Radius
RF
Band
(GHz)
802.11
modes
TxR:S
IAP325
2
2.4 & 5
a/b/g/n/ac
4x4:4
Internal Omni
downtilt - Ceiling
Mount
IAP324
2
2.4 & 5
a/b/g/n/ac
4x4:4
IAP225
2
2.4 & 5
a/b/g/n/ac
IAP224
2
2.4 & 5
IAP215
2
IAP214
2
IAP
Model
Ethernet
Ports
USB
Ports
PoE/ PoE+
(3af/3at) or
External
Adapter
2xGE
1
External Antennas Wall, Ceiling, and
Flat Surfaces Mount
PoE/ PoE+
(3af/3at) or
External
Adapter
2xGE
1
3x3:3
Internal Omni
downtilt - Ceiling
Mount
PoE/ PoE+
(3af/3at) or
External
Adapter
2xGE
1
a/b/g/n/ac
3x3:3
External Antennas Wall, Ceiling, and
Flat Surfaces Mount
PoE/ PoE+
(3af/3at) or
External
Adapter
2xGE
1
2.4 & 5
a/b/g/n/ac
3x3:3
Internal Omni
downtilt - Ceiling
Mount
PoE/ PoE+
(3af/3at) or
External
Adapter
2xGE
1
2.4 & 5
a/b/g/n/ac
3x3:3
External Antennas Wall, Ceiling, and
Flat Surfaces Mount
PoE/ PoE+
(3af/3at) or
External
Adapter
2xGE
1
Aruba Instant Validated Reference Design
Antenna and
Mounting Type
Power
Introduction to Aruba Instant | 19
Radius
RF
Band
(GHz)
802.11
modes
TxR:S
Antenna and
Mounting Type
IAP205H
2
2.4 & 5
a/b/g/n/ac
2x2:2
Internal Omni –
IAP205
2
2.4 & 5
a/b/g/n/ac
2x2:2
IAP204
2
2.4 & 5
a/b/g/n/ac
IAP103H
2
2.4 & 5
a/b/g/n
IAP103
2
2.4 & 5
a/b/g/n
2x2:2
IAP228
2
2.4 & 5
a/b/g/n/ac
3x3:3
IAP
Model
Ethernet
Ports
USB
Ports
PoE/ PoE+
(3af/3at) or
External
Adapter
1xGE +
3xGE
1
External Antennas Wall, Ceiling, and
Flat Surfaces Mount
PoE/ PoE+
(3af) or
External
Adapter
2xGE
1
2x2:2
External Antennas Wall, Ceiling, and
Flat Surfaces Mount
PoE/ PoE+
(3af) or
External
Adapter
2xGE
1
2x2:2
Internal Omni –
PoE/ PoE+
(3af) or
External
Adapter
1xGE +
2xFE
No
Internal Omni
downtilt - Ceiling
Mount
PoE/ PoE+
(3af) or
External
Adapter
1xGE
No
External Antennas -
PoE+ (3at)
or External
Power
2xGE
No
PoE+ (3at)
or External
Power
2xGE
No
PoE+ (3at)
or External
Power
2xGE
No
PoE+ (3at)
or External
Power
2xGE
No
External
Power
5xGE
Yes
Desktop & Wall
mount
Wall mount
6xRP-SMA type
connectors
Power
(3 per radio)
IAP274
2
2.4 & 5
a/b/g/n/ac
3x3:3
External Antennas 6xN type
connectors
(3 per radio)
IAP275
2
IAP277
2
RAP155P
2
2.4 & 5
a/b/g/n/ac
3x3:3
Internal Omni –
5dBi
2.4 & 5
a/b/g/n/ac
3x3:3
Internal Omni –
6.5dBi
20 | Introduction to Aruba Instant
2.4 & 5
a/b/g/n
2x2:2
Internal Omni –
Aruba Instant Validated Reference Design
IAP
Model
Radius
RF
Band
(GHz)
802.11
modes
TxR:S
(2.4GHz)
3x3:3
(5GHz)
Antenna and
Mounting Type
Desktop mount
Power
54 VDC
power
interface.
Ethernet
Ports
USB
Ports
802.3af on
E1 & E2.
uplink
OR
802.3at on
E1 or E2.
RAP155
RAP3WNP
2
1
2.4 & 5
2.4
a/b/g/n
b/g/n
2x2:2
(2.4GHz)
3x3:3
(5GHz)
Internal Omni –
2x2:2
(2.4GHz)
Internal Omni –
AC input:
3xFE
Yes
Desktop mount
100-240
volts
AC/0.75 A
802.3af PoE
(15.4 watts)
on the E2
port.
uplink
3xFE
Yes
Desktop mount
External
Power
5xGE
Yes
uplink
12 VDC
power
interface.
DC output:
48 volts
DC/0.75 A
RAP3WN
1
2.4
b/g/n
2x2:2
(2.4GHz)
Internal Omni –
AC input:
Desktop mount
100-240
volts AC/0.5
A
Uplink
DC output:
12 volts
DC/1.5 A
RAP109
2
2.4 & 5
a/b/g/n
2x2:2
Internal Omni and
Desktop & Wall
Mount
PoE or
External
adapter
2
1
RAP108
2
2.4 & 5
a/b/g/n
2x2:2
External Antennas
and Desktop & Wall
and Flat Surfaces
Mount
PoE or
External
adapter
2
1
To prevent inconsistent client connections, Aruba recommends that you do not enable band steering when you
combine single and dual-radio APs in the same area. Dual-radio APs and single radio air monitors (AMs) can be
used in the same area.
Aruba Instant Validated Reference Design
Introduction to Aruba Instant | 21
How Instant Solution fits into needs of various Enterprises
Aruba Instant Solution for Small and Medium Enterprises
An organization with a workforce that ranges from a hundred to a few thousand users is often categorized as a small
or medium enterprise. Although the density of users and devices in these organizations is not as concentrated as in
large enterprises, the demand for a high-performing WLAN is the same as in a large enterprise. Like IT teams of large
enterprise, the IT teams in small or medium enterprises must provide a high performance WLAN that can support the
continuing growth in mobile devices, including bring your own devices (BYODs). Unlike large enterprises, small and medium enterprise are often faced with the challenge of limited IT staff with little
or no expertise in deploying secure WLAN systems. So, the key requirement of small and medium enterprises is an
enterprise-grade WLAN solution that is easy to deploy and maintain. The secure and scalable Aruba Instant solution
with its enterprise-grade features and ease of deployment and management is an ideal choice for these small and
medium enterprises.
The design of an Aruba Instant network for a small or medium enterprise depends on the size and physical layout of
the organization. From a physical layout perspective, most small enterprises are single building campuses that host
a few hundred users. These small enterprises can usually be covered by a single Aruba Instant cluster.
Medium enterprises usually consist of a collection of buildings that are interconnected by dark fiber within the same
geography. The buildings of a medium enterprise are typically within a contiguous RF domain and can be deployed
as a single Aruba Instant cluster or as multiple Aruba Instant clusters, depending on the physical layout, size, and
device density.
Diagram of an Aruba Instant design for a medium enterprise and Aruba Instant show an overview of an Aruba Instant
design for a small and medium enterprise.
Figure 2 Diagram of an Aruba Instant design for a small enterprise
22 | Introduction to Aruba Instant
Aruba Instant Validated Reference Design
Figure 3 Diagram of an Aruba Instant design for a medium enterprise
An Aruba Instant solution for small and medium enterprises includes these key components:
l
Instant Access Points: IAPs are the basis of an Aruba Instant WLAN system. In a campus deployment, IAPs
provide all core functionalities of a WLAN, such as client access for employees and guests, traffic engineering, a
stateful firewall, QoS, mobility, Adaptive Radio Management (ARM), a wireless intrusion prevention system
(WIPS), Airgroup services (for example, plug-and-play services), and spectrum analysis.
l
ClearPass: The ability to support BYOD initiatives and guest services is essential in enterprise deployments. Aruba ClearPass is the only standards-based BYOD solution that integrates every critical aspect of BYOD—
network access control (NAC), mobile device management (MDM), and mobile application management (MAM)—
into a single platform. With ClearPass, IT can manage network policies, onboard and manage devices, admit
guest users, assess device health, and even securely distribute and manage work applications through a single
pane of glass, on any network.
l
AirWave or Aruba Central: You can manage small deployments that are served with a single Aruba Instant
cluster through the local WebUI of a VC. However, when a deployment includes multiple Aruba Instant clusters,
you need a central management platform to manage the different Aruba Instant clusters. Aruba provides two
management options for Aruba Instant deployments: AirWave and Aruba Central. AirWave is an in-house
appliance (much like a private cloud) that that provides monitoring, configuration, firmware management, and
troubleshooting for Aruba Instant networks. Aruba Central is a public cloud-based management platform that
provides monitoring, configuration, firmware management, and troubleshooting for Aruba Instant networks. (For
more information, see Diagram of a K-12 district with Aruba Central management and Aruba Instant.)
l
Aruba Activate: One of the key challenges in deployments that include multiple interconnected buildings is
deployment of APs. Aruba addresses this challenge with Aruba Activate, which is a cloud based, zero-touch
provisioning system. Aruba Activate provides plug-and-play capability to an Aruba Instant cluster, which allows
rapid deployment of Aruba Instant clusters with minimal or no IT expertise.
Aruba Instant Validated Reference Design
Introduction to Aruba Instant | 23
In addition to small and medium enterprises, Aruba Instant is also ideal for certain deployments such as K-12 school
districts that mimic a collection of small or medium enterprises. K-12 school districts include a group of high schools,
middle schools, and elementary schools that are geographically spread within a limited area such as a district. Most
of these schools are interconnected by dark fiber or Metro Ethernet and represent a network that serves several
thousands of users and devices. Schools in a K-12 school district are usually spread out in such a way that they do
not fall under a contiguous RF domain. However, the individual schools themselves often mimic a small or medium
enterprise. In other words, each of these schools can be a single or multi-building site within a contiguous RF
domain, hosting hundreds or a few thousands of users and devices. Similar to small or medium enterprises, K-12
school districts have limited IT staff and require a high performance WLAN that is easy to deploy and manage. The
Aruba Instant solution is well suited for K-12 deployments.
Diagram of a K-12 district with Aruba Central management and Aruba Instant show a K-12 school district with an
AirWave and Aruba Central management deployment.
Figure 4 Diagram of a K-12 district with AirWave management
Figure 5 Diagram of a K-12 district with Aruba Central management
24 | Introduction to Aruba Instant
Aruba Instant Validated Reference Design
Aruba Instant Solution for Distributed Enterprises
A distributed enterprise is an operation with multiple locations that are geographically distributed across a limited
geography or across the entire globe. These days, organizations are more distributed than ever because of the cost
saving and increased productivity that is associated with employing a distributed workforce. A distributed enterprise
might be a collection of branch offices, home offices, or a combination of both. The number of distributed sites and
the user density at these sites vary across organizations. The way in which the remote sites connect to the data
center or headquarters also varies. Some enterprises use services such as MPLS, while others use VPNs. In
general, distributed enterprises can be classified as follows:
l
Branch office deployments
l
Home offices deployments
Because distributed enterprises often include remote sites that have limited or no IT support, the Aruba Instant
solution with its zero-touch provision, multiple uplink options, enterprise features, and VPN capabilities is ideal for
distributed enterprise deployments.
The following figures show Aruba Instant designs for distributed enterprises that use MPLS with AirWave
management (Distributed enterprise that uses MPLS and Aruba Central), MPLS with Aruba Central management
(Distributed enterprise with home or branch offices connecting over VPN), home offices with VPNs (Aruba Instant),
and branch office with VPNs (Figure 9).
Figure 6 Distributed enterprise that uses MPLS and AirWave
Aruba Instant Validated Reference Design
Introduction to Aruba Instant | 25
Figure 7 Distributed enterprise that uses MPLS and Aruba Central
Figure 8 Distributed enterprise with home or branch offices connecting over VPN
An Aruba Instant solution for a distributed enterprise includes the following key components:
l
Instant Access Points: IAPs are the basis of an Aruba Instant WLAN system. In a remote deployment, IAPs
provide all core functionalities such as VPN capabilities, uplink redundancy, client access for employees and
guests, traffic engineering, a stateful firewall, QoS, mobility, Adaptive Radio Management (ARM), a wireless
intrusion prevention system (WIPS), and spectrum analysis.
l
Aruba Controllers: In distributed enterprises that require an Aruba Instant-VPN solution, the Aruba controllers
function as VPN concentrators that terminate VPN tunnels from Aruba Instant clusters at remote sites.
Depending on the Aruba controller platform, each controller can support thousands of Aruba Instant-VPN
branches. For information about controller limits, see WLAN Controller Scalability for Instant-VPN deployments.
l
ClearPass: Depending on the type of distributed enterprise deployment, network administrators must be able to
support employee access, BYOD initiatives, and guest services. Aruba ClearPass is the only standards-based
26 | Introduction to Aruba Instant
Aruba Instant Validated Reference Design
BYOD solution that integrates every critical aspect of BYOD—network access control (NAC), mobile device
management (MDM), and mobile application management (MAM)—into a single platform. With ClearPass,
network administrators of distributed enterprises can manage network policies, onboard and manage devices,
admit guest users, assess device health, and even securely distribute and manage work applications through a
single pane of glass.
l
AirWave or Aruba Central: Most organizations with remote networking have hundreds or even thousands of
remote sites. Managing each of these remote locations using the Local WebUI on a VC is not feasible. Aruba
provides two management options to manage, monitor, and troubleshoot these remote networks: AirWave and
Aruba Central. AirWave is an in-house appliance (much like a private cloud) that that provides monitoring,
configuration, firmware management, and troubleshooting for Aruba instant networks. Aruba Central is a public
cloud-based management platform that provides monitoring, configuration, firmware management, and
troubleshooting for Aruba Instant networks.
l
Aruba Activate: One of the key challenges in deployments with remote networks is the lack of on-site IT
support. The ability to roll out thousands of remote sites with minimal effort is critical to IT teams. Aruba Activate
addresses the deployment challenges of remote networks. Aruba Activate is a cloud-based, zero-touch
provisioning system that provides plug-and-play capability to an Aruba Instant network and allows rapid
deployment of Aruba Instant-based remote sites.
Aruba Instant Solution for Hybrid Deployments
As organizations become more distributed, network administrators might need to support large sites that resemble a
campus network and also remote workers. Organizations that have large campus sites and remote networks are
considered hybrid deployments. Hybrid deployments are becoming common, so network administrators need a
solution that addresses the demands of both campus and remote networks. The Aruba WLAN offering is an ideal
solution for hybrid networks.
Aruba Instant is ideal for hybrid organizations with small-to-medium campuses and thousands of remote sites. If a
campus in a hybrid organization grows to thousands of APs, Aruba Instant can be Distributed enterprise with home
or branch offices connecting over VPN.
Figure 9 Distributed enterprise with home or branch offices connecting over VPN
Aruba Instant Validated Reference Design
Introduction to Aruba Instant | 27
Chapter 3
Designing Enterprise Networks with Aruba Instant
The needs and requirements of small and medium enterprises make Aruba Instant the ideal choice in these
deployments. Design of an enterprise WLAN is influenced by several factors such as the number of users and
devices, types of devices and applications, type of facility and its RF coverage zones, security, QoS requirements,
and so on. Designing and optimizing a WLAN network can easily become a complex assignment. To simplify the
design of an enterprise WLAN, you can apply a phased approach to a WLAN design. In general, you can divide a
WLAN design into the following categories:
l
Physical and logical design: In a distributed architecture, the APs work together to provide the necessary
functionality without a dedicated physical controller. The physical and logical design in a distributed architecture
includes the AP selection process, Layer 2 and Layer 3 design for the end users and APs, and the logical
clustering of APs based on roaming patterns and physical boundaries.
l
RF design: The RF design determines the number of required APs, the optimal AP locations, and how the RF
feature set can be optimized.
l
Authentication and security design: The authentication and security design includes selecting the appropriate
type of authentication for users and devices, integrating the AAA servers, and securing the network against rogue
APs and wireless attacks.
l
Quality of Service (QoS) design: The QoS design includes optimizing the WLAN and underlying infrastructure
for latency-sensitive applications such as voice and video.
l
Design for plug-and-play services: This design includes determining the plug-and-play services such as
Bonjour and optimizing the network for such services.
This chapter describes the Aruba Instant design for small and medium enterprises under these categories.
Aruba Instant Solution Basic Concepts
Before you start a WLAN design with Aruba Instant, you must understand some of the basic concepts of the Aruba
Instant solution.
VLANs in an Aruba Instant Cluster
An Aruba Instant cluster has two basic types of VLANs:
l
AP VLAN: The VLAN to which the APs in a cluster are connected is called the AP VLAN. In most deployments,
this VLAN is the native VLAN of the trunk port to which an AP connects. Aruba recommends that you enable
DHCP services on the AP VLAN to facilitate AP deployment. However, if required, you can assign static IP
addresses to IAPs.
l
Client VLAN: This VLAN is assigned to the clients that connect to the Aruba Instant cluster. These clients
receive their IP address on the client VLAN that is assigned to them. In an Aruba Instant cluster, the client VLAN
and client IP addresses can be assigned in the following ways:
l
Virtual-controller assigned
l
Network-assigned
Aruba Instant Solution Basic Concepts shows the client IP assignment and VLAN assignment options.
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 28
Client IP assignment with the “Virtual Controller assigned” option
In an Aruba Instant network, if a client connects to an SSID that is configured for the “Virtual Controller assigned”
option (see Aruba Instant Solution Basic Concepts), the VLAN that is assigned to the client is called a magic VLAN.
A magic VLAN has the following characteristics:
l
The master AP (virtual controller) is the DHCP server and the default gateway for the clients on the VLAN.
l
DHCP requests on the magic VLAN are forwarded to the master AP of the cluster on the AP VLAN.
l
Unicast packets from the clients are forwarded to the master AP and the master AP performs source NATing.
l
If a client on a magic VLAN is connected to a member AP, the traffic from the clients is forwarded to the master
AP on the AP VLAN. Therefore, do not use a magic VLAN in environments that require VLAN-based segregation
between client traffic and AP traffic.
l
Broadcast and multicast packets from the client are not allowed to go through the uplink port of an IAP. In other
words, the broadcast and multicast traffic on the magic VLAN is not forwarded to the uplink by individual IAPs.
l
Communication between clients on a magic VLAN is through the master AP, that is, clients on the magic VLAN
cannot directly communicate with each other.
l
In an Aruba Instant cluster, you can define only a single DHCP scope for a magic VLAN. In other words, you
cannot use multiple magic VLANs in an Aruba Instant cluster.
29 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
DHCP scope definition for a magic VLAN is a screen shot of the DHCP server options for a magic VLAN.
Figure 10 DHCP scope definition for a magic VLAN
l
You do not need to add a magic VLAN to the uplink switches that connect the IAPs of an Aruba Instant cluster.
A magic VLAN is designed to simplify guest WLAN implementation. When you add a guest WLAN, a magic VLAN
can process the guest traffic on the network without any modification the underlying wired infrastructure (that is,
you do not need to add a VLAN). When you use the “Virtual Controller assigned” option for an SSID, all client
traffic on that SSID is forwarded on the AP VLAN to the master AP and the master AP performs source NATing.
Do not use theVC-assigned IP address option if you need VLAN-based segregation between guest traffic and the
AP VLAN.
Client IP assignment with the “Network assigned” option
The network can also assign a client IP address in an Aruba Instant cluster. Client IP address assignment by the
network includes the following options (see also Aruba Instant Solution Basic Concepts):
l
Default: The default VLAN to which the IAP is connected is also assigned to clients, that is, the AP VLAN is the
same as the client VLAN. Aruba does not recommend this option for an Aruba Instant cluster because user traffic
is forwarded on the same VLAN that is used to manage the IAPs.
l
Static: A specific VLAN ID must be assigned to the clients that connect to the SSID. This VLAN ID can be either
a VLAN that connects to a DHCP server on the wired network or a VLAN for which the Aruba Instant cluster is
the DHCP server. For information about defining a DHCP server and its associated VLANs on an Aruba Instant
cluster, see Understanding Instant-VPN Modes. As part of the static settings, you can also define VLAN pools.
For more information about defining VLAN pools, see the Aruba Instant User Guide that is available at the Aruba
support website.
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 30
l
Dynamic: You can define VLAN derivation rules to assign users dynamically to different VLANs based on
several attributes. For more information about dynamic VLAN assignment, see the Aruba Instant User Guide that
is available at the Aruba support website.
If a client belongs to a VLAN for which the master AP is not the DHCP server or the default gateway, the client
traffic leaves from the IAP to which the client is connected and does not flow through the master AP. However, if a
client belongs to a VLAN for which the master AP is the DHCP server, the client traffic flows through the master
AP. Client traffic from a member AP to the master AP is always bridged and not tunneled.
For recommendations about client IP address assignment, see Physical and Logical Design.
Traffic Flows in an Aruba Instant Cluster
In a WLAN network, two primary types of traffic exist: AP-generated traffic and client-generated traffic.
AP Traffic
In an Aruba Instant cluster, AP-generated traffic includes RADIUS transactions, management traffic,
communications between APs, SNMP traffic, Syslog traffic, and so on. This AP-generated traffic is forwarded on
the AP VLAN. The AP VLAN in an Aruba Instant cluster is the default VLAN of the port (that is, the native VLAN of a
trunk port) to which the AP is connected. Therefore, any AP-generated traffic is untagged. However, certain
environments might require AP traffic to be tagged. The uplink VLAN management feature allows you to tag AP
traffic. For more information, see Uplink Management VLAN.
Client Traffic
Each device in an Aruba Instant cluster is assigned a user role. Client traffic in an Aruba Instant cluster is first
examined by the stateful firewall of the IAP to which the client is connected before being forwarded to the uplink
network with the appropriate client VLAN tag. For example, if a client is assigned an IP address in VLAN 20 using
the static network-assigned IP address option (for more information, see Network-Assigned IP Addresses), the
client traffic is forwarded to the uplink of the AP with VLAN tag 20. The uplink switch that connects the IAPs in an
Aruba Instant cluster must support all client VLANs on that cluster. For example, if VLAN 10, VLAN 20, and VLAN
30 are used as client VLANs in an Aruba Instant cluster, the uplink network that connects the IAPs must support
tagged VLANs 10, 20, and 30. The only exception to this rule is the WLAN configuration, which uses a magic VLAN
for clients (for more information, see Virtual Controller-Assigned IP Addresses).
The client traffic flow in an Aruba Instant cluster also depends on whether the master AP is the DHCP server for the
client VLAN. Aruba Instant deployments typically have these types of client VLANs and traffic:
l
VLAN managed by an uplink network: A VLAN that is managed by the uplink network -For example, if VLAN
20 is managed by the uplink network and is mapped to the “Employee” SSID, the client traffic is examined by the
firewall of the IAP to which the client is connected, bridged to VLAN 20, and does not flow through the master AP
of the cluster.
l
VLAN with a DHCP server on an Aruba Instant network: A VLAN for which the DHCP server is on the master
AP of the Aruba Instant cluster. This type of VLAN includes a VLAN in local mode, centralized Layer 2 mode,
distributed Layer 2 mode, centralized Layer 3 mode, or distributed Layer 3 mode. (For more information about
these modes, see Understanding Instant-VPN Modes.) If an Aruba Instant SSID is mapped to such a VLAN, the
client traffic on that SSID leaves (with the appropriate VLAN tag) from the IAP to which the client is connected,
but the traffic flows through the master AP. The VLAN ID that is used in the DHCP configuration for these
VLANs must be supported on the uplink switch that connects the IAPs.
For more information about traffic flows in an Aruba Instant cluster that is configured for Instant-VPN, see Traffic
Flows in an Aruba Instant Cluster.
The only exception to this behavior is a magic VLAN. The DHCP server for a magic VLAN is on the Aruba Instant
31 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
network and the client traffic on the magic VLAN flows through the master AP. However, the client traffic on the
magic VLAN reaches the master AP on the AP VLAN and not on a specific client VLAN. For more information
about a magic VLAN, see Virtual Controller-Assigned IP Addresses.
Dynamic RADIUS Proxy
In a distributed architecture, each AP functions as a RADIUS authenticator for its clients, which means that you
must configure each AP as a RADIUS client on the authentication server. However, adding all APs as NAS clients
to a RADIUS server might not always be feasible. The dynamic RADIUS proxy (DRP) feature of Aruba Instant
provides an alternative to adding all APs as NAS clients. When DRP is enabled, the master AP becomes a single
anchor for RADIUS requests for all users on an Aruba Instant cluster, regardless of the AP to which a user connects.
The master AP acts as the RADIUS proxy for all RADIUS transactions in an Aruba Instant cluster. When DRP is
enabled, all RADIUS packets that originate form an Aruba Instant cluster are sourced with the virtual controller (VC)
IP address that is assigned to the cluster. You only need to add the VC IP address to the RADIUS client list on the
authentication server.
Virtual Controller IP address for DRP shows the VC IP address and DRP configuration.
Figure 11 Virtual Controller IP address for DRP
By default, when DRP is enabled, all RADIUS packets are sourced with the VC IP address. Using the VC IP
address for RADIUS transactions works well in most environments, but in certain situations the RADIUS server
might be on a network or VLAN that cannot be reached from the AP VLAN. For these situations, Aruba InstantOS
lets you define a DRP VLAN, IP address, and subnet on a per-RADIUS server basis. This capability allows network
administrators to define the VLAN and source IP address for transactions with a specific RADIUS server. If DRP is
enabled and if the RADIUS server on an Aruba Instant network does not include the DRP VLAN and IP configuration
for a RADIUS sever, the transactions with that RADIUS server are sourced with the default VC IP address and
VLAN. For more information about DRP, see the Aruba Instant User Guide that is available at the Aruba support
website.
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 32
DRP options for a RADIUS server shows how you can configure the DRP settings on a per-RADIUS server basis.
Figure 12 DRP options for a RADIUS server
In Aruba Instant VPN deployments, DRP is essential to tunnel the RADIUS traffic to the centralized authentication
server in the data center. For more information on DRP in Aruba Instant-VPN deployments, see 802.1X and RFC
3576 Handling in an Aruba Instant-VPN Network.
Layer 3 Mobility
IAPs within the same Layer 2 domain form a single Aruba Instant cluster. In some situations, because of the
physical building layout or the roaming patterns, Aruba Instant deployments within a contiguous RF domain might
need to be broken up into multiple clusters. The Layer 3 mobility feature lets clients roam away from the Aruba
Instant cluster to which they first connected (home network) to another Aruba Instant cluster (foreign network) that
supports the same WLAN access parameters, and continue their existing sessions.
Layer 3 mobility allows clients to roam without losing their IP address and sessions across IAP clusters within a
contiguous RF domain. If WLAN access parameters are same across the clusters, clients that are connected to
IAPs in an Aruba Instant network can roam to APs in a foreign Aruba Instant network and continue their existing
sessions. Layer 3 mobility enables seamless roaming in a multi-cluster Aruba Instant deployment. For more
information about Layer 3 mobility and how to configure it, see the Aruba Instant User Guide that is available at the
Aruba support website.
Physical and Logical Design
One of the key differences of a distributed architecture when compared to a centralized controller-based architecture
is the need to create wireless user VLANs at the edge of the network. Unlike a centralized controller-based
architecture, in a distributed architecture you must configure the wireless user VLANs on the uplink switches that
connect the APs. This requirement influences the logical design of an Aruba Instant network.
As described in Chapter 1, the physical layout of the small and medium enterprise falls in one of these categories:
l
Single-building layout: This layout is typical for most small enterprises with head-quarters in a single building
with one or more floors.
33 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
l
l
Multi-building layout within a contiguous RF domain: The physical layout of the buildings in this category is
such that the users expect to roam seamlessly across the buildings. The buildings in this type of layout are
usually connected by dark fiber or Metro Ethernet. Examples of this type of layout include:
n
A medium enterprise with a few buildings in close proximity
n
Individual schools of a K-12 school district that has multiple buildings in close proximity
Multi-building layout with a non-continuous RF domain: The physical layout of the buildings in this category
is such that seamless roaming across buildings is not practical. A typical example is a medium enterprise that
has offices in two cities. Another example is a K-12 school district with elementary, middle, and high schools that
are geographically separated in such a way that seamlessly roaming of users across the schools is not practical
without a Metro Wi-Fi solution. The buildings in this type of layout are usually connected by Metro Ethernet or
MPLS.
To select the optimal physical and logical design for any of these environments, you must combine these design
elements:
l
Wired infrastructure design
l
Client VLAN deign
l
Cluster design
Wired Infrastructure Design
There is a fundamental difference in designing a network with a centralized architecture that is controller-based as
opposed to a distributed architecture such as Aruba Instant. In a distributed architecture, the user VLANs and the AP
management VLANs must be configured and extended to the edge (access layer) of the network.
To design the wired infrastructure and VLANs in an Aruba Instant deployment, consider these guidelines:
l
Create a separate VLAN (that is, subnet) to manage the Aruba Instant cluster and ensure that the AP VLAN does
not carry any multicast and user traffic. To simplify IAP deployment, enable DHCP for the AP VLAN. If the AP
VLAN does not support DHCP, stage and configure each AP with a static IP address.
l
Configure all switch ports that are used for IAP connections as trunk ports. Configure the AP VLAN as the native
VLAN of the trunk port and add user VLANs to the allowed VLANs list on the trunk port. All client VLANs, except
magic VLANs, must be tagged VLANs on the trunk port.
l
Ensure that the native VLAN of the trunk port to which the AP connects is functional because all traffic that is
generated by the AP is carried on the native VLAN of the trunk port.
l
Do not modify the uplink management VLAN settings from its default settings. An exception to this guideline is
described in Recommendations for an Uplink Management VLAN.
l
Segregate the wireless VLANs from the wired VLANs. Maintaining separate VLANs for wireless clients
eliminates unnecessary broadcast and multicast traffic from the wired VLAN occupying the airtime.
l
DRP is not required if you can add the entire AP VLAN subnet as a NAS client on the RADIUS server.
l
Enable DRP if your security policy requires a single entity to function as a NAS client for a cluster. If DRP is
enabled, assign a static VC IP address on the same subnet as the AP VLAN and ensure that the RADIUS server
can be reached from that VLAN. If the AP VLAN cannot reach the RADIUS server, enable DRP and configure
the DRP IP address on a VLAN that can reach the RADIUS server. For more information, see Dynamic RADIUS
Proxy.
If an IAP is the DHCP server for a VLAN such as a local-mode VLAN, the uplink switches that connect the IAPs
in a cluster must support the VLAN. The master AP is the DHCP server and gateway for the local VLAN, so if the
uplink switches do not support the VLAN, other IAPs in the cluster cannot forward traffic to the master AP. (For
more information, see Traffic Flows in an Aruba Instant Cluster.) This requirement does not apply to a magic
VLAN.
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 34
Recommendations for an Uplink Management VLAN
By default, traffic that is generated by an AP is untagged. The native VLAN of the trunk port that connects the AP
must be functional. If the native VLAN of the trunk port to which an IAP is connected is a dummy VLAN, you might
have to use a tagged VLAN on the port as the AP VLAN. In such a situation, the AP traffic must be tagged to ensure
that the IAP receives its IP address from the tagged AP VLAN and that all traffic that is generated by the AP is
carried on the tagged AP VLAN. To accommodate this type of configuration, Aruba Instant supports the Uplink
Management VLAN feature.
Uplink Management VLAN
The Uplink Management VLAN feature determines if the AP traffic is tagged or untagged.
By default, the setting for this feature is 0, which means that the AP traffic is untagged. Aruba recommends this
default setting. Aruba also recommends that you make sure that your native VLAN is not a dummy VLAN. However,
in an environment in which you cannot modify the native VLAN to be functional, use the Uplink Management Feature
to tag the AP traffic with the appropriate VLAN tag. For example, if the native VLAN is a dummy VLAN and VLAN 20
must be the management VLAN for APs, set the uplink management VLAN to 20. An uplink management VLAN is a
“per AP” configuration and you must modify it only in an environment in which you cannot modify the native VLAN of
a trunk to be functional. Click on the IAP’s edit link and update the Uplink tab.
Client VLAN Design
As discussed in Traffic Flows in an Aruba Instant Cluster, Aruba Instant provides multiple options to assign client IP
addresses. Below mentioned are some of the guidelines for a client VLAN design:
l
Aruba strongly recommends the network-assigned IP addressing option for client IP assignment.
l
Aruba recommends separating the AP VLAN and client VLANs. Use the “Default-Network Assigned IP Address”
option only in an environment in which a separate AP VLAN and client VLAN are not possible.
l
Use VC-assigned IP addressing only in the following situations:
35 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
l
n
The switch that the IAP connects to is an unmanaged Layer 2 switch on which VLANs cannot be defined.
n
You do not want to configure additional VLANs for guest traffic across all switches.
Do not use the VC-assigned IP option in an environment in which a VLAN-based segregation is required between
a client VLAN (that is, a guest user VLAN) and the AP VLAN. A good example of such a situation is an
environment in which PCI compliance is required.
Cluster Design
By default, all Aruba IAPs on a Layer 2 domain form a cluster. No hard limit exists on the number of APs or clients
that you can support on a single cluster. However, the maximum tested IAP cluster size is 128 IAPs in a cluster.
Guidelines for cluster and mobility design include the following guidelines:
l
Aruba recommends that you use the validated cluster size of 128 APs and 2048 clients per cluster for your cluster
design. To allow for some future growth, design a cluster at 80 to 90 % (about 110 APs) of the validated capacity.
l
If a deployment within a contiguous RF domain requires more than 110 APs, divide the deployment into multiple
clusters and enable Layer 3 mobility between them.
Although the validated cluster size limit applies to a cluster, you can expand a deployment to more than 128 APs
by deploying multiple clusters that have Layer 3 mobility enabled between them.
l
Layer 3 roaming has little to no impact on performance if you enable the Home Agent Load Balancing feature that
is part of the Aruba Instant architecture. If you enable this feature, the VC assigns the home AP for roamed
clients by using a round robin policy. With this policy, the load for the APs acting as home agents for roamed
clients is uniformly distributed across all the IAPs in the cluster.
NOTE: Aruba recommends that you enable the Home Agent Load Balancing feature in deployments in which you expect
a high volume of Layer 3 roaming between clusters.
Cluster Design for Single-Building Layout
A single-building layout might be an office on one level or multiple levels. You must base the cluster design in these
environments on the AP and client density. If you can support the building with fewer than 110 APs, Aruba
recommends a single cluster. Most single-building layouts can be accommodated with a single cluster. However, if
you have a multi-storey building that exceeds the recommended AP and client limit for a single cluster, divide the
deployment into two clusters with Layer 3 mobility enabled between the clusters. If you enable Layer 3 mobility,
Aruba recommends that you also enable the Home Agent Load Balancing feature. By default, Home Agent Load
Balancing is disabled. Go to System>Show advanced options>L3 Mobility to enable it.
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 36
Cluster Design for a Multi-Building Layout within a Contiguous RF Domain
In this layout, users are expected to roam seamlessly across buildings. You must base the cluster design in these
environments on the AP and client density. If the layout includes three buildings that can be covered by fewer than
110 APs, Aruba recommends that you deploy the IAPs as a single cluster. However, if these three buildings require
50 APs per building, deploy the IAPs as two clusters with Layer 3 mobility enabled between them. In a multi cluster
design, take the roaming patterns into consideration.
Cluster Design for a Multi-Building Layout with a Non-Continuous RF Domain
In this layout, the buildings are geographically separated in such a way that seamless roaming across buildings is
not practical. In this case, support each building with a single cluster. The geographical separation means that
seamless roaming across buildings is not required.
Cluster Design for a K-12 School District
A K-12 school district is a combination of high schools, middle schools, and elementary schools. The individual
schools that make up the K-12 school district can represent a single-building layout or a multi-building layout with a
contiguous RF domain. Apply the cluster design for a single-building layout or a multi-building layout with a
contiguous RF domain to the individual schools.
The different schools in a K-12 school district are typically separated geographically such that seamless roaming
across schools is not practical. A typical K-12 school district design has these characteristics:
l
Each individual school is a single or multi-cluster design that is based on the number of APs that are required to
provide a capacity-based RF design.
l
Seamless roaming across schools is not required because of the geographical separation.
l
The entire school district is managed by a single management platform–AirWave or Aruba Central.
37 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
Cluster Security Recommendations
When you add a new IAP to a Layer 2 network that is hosting an Aruba Instant cluster, the new AP joins the cluster
automatically. This behavior is enabled by the Auto-Join feature that is enabled by default on an Aruba Instant
cluster. The Auto-Join feature simplifies the deployment of Aruba Instant networks. However, after the initial
deployment of the network, Aruba recommends that you disable the Auto-Join feature to prevent unauthorized APs
from joining the cluster. If you must add additional authorized APs to the network, you have these options:
l
Manually add new APs to an existing cluster by adding the MAC addresses of the new APs to the Instant cluster
configuration (see Physical and Logical Design).
l
Temporarily enable the Auto-Join feature to allow new authorized APs to be added automatically during the AP
deployment window. By default, Auto Join is enabled. Change it in System>show advanced settings.
Below is the screen shot of the New Access Point pop-up screen that lets you add the MAC address of a new
authorized IAP.
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 38
Figure 13 Manually adding an AP by specifying its MAC address
RF Design
Good RF design is one of the most essential aspects of designing an enterprise WLAN because RF design relates
directly to the user experience. With the proliferation of mobile devices and applications in the network, it is important
to ensure that a WLAN can accommodate them and can provide optimal performance over the air. Good RF design
includes these recommendations:
l
WLANs can be designed as either capacity-based networks or coverage-based networks. Coverage-based
networks have fewer APs deployed and further apart from each other. Capacity-based networks have more
densely deployed APs that are capable of serving a higher number of clients and provide better speeds.
To accommodate the influx of wireless devices in the near future, Aruba highly recommends that you design your
enterprise network for capacity rather than coverage.
l
Before you deploy APs, Aruba recommends that you run a site survey on your floor plan (either a virtual or
physical site survey) to determine the ideal number of APs that can provide a targeted minimum data rate and to
identify where to place the APs for optimal performance.
l
Select the types of APs (2-stream or 3-stream) based on application requirements.
l
Select the types of antennas (internal or external), based on the type of environment (warehouse or cubicles,
presence of concrete walls, metal drawers and cabinets, and so on).
l
After you have placed the APs optimally, fine-tune them with the appropriate channel and power assignments.
For detailed information about RF planning requirements, see the Site Survey and Planning Validated Reference
Design.
One of challenges with RF environments is their ever-changing nature. Even when you follow good design
recommendations to deploy the APs, RF performance can degrade. RF performance can degrade due to many
factors: an RF coverage hole might occur when an AP goes down, Wi-Fi or non-Wi-Fi interference might be present
in the air, legacy 802.11 a/b/g devices might be present in the network, and so on.
It is critical that you have certain mechanisms in place to allow for dynamic adjustment to the constantly changing
RF environment. Adaptive Radio Management (ARM) is such a mechanism. For more information, see Adaptive
Radio Management.
39 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
Radio Modes on Aruba Instant
You can set each AP in an Aruba Instant cluster to one of the below mentioned modes of operation:
l
Access: The AP serves clients while also monitoring for rogue APs in the background.
l
Monitor: The AP functions as a dedicated monitor, scanning all channels for rogue APs and clients. In the
Monitor mode, the AP cannot serve any clients.
l
Spectrum Monitor: The AP functions as a dedicated full-spectrum RF monitor, scanning all channels to detect
interference, whether from neighboring APs or from non-WiFi devices such as microwaves and cordless phones.
In the Spectrum Monitor mode, the AP cannot serve any clients.
You configure the radio mode per individual AP. By default, all APs function in access mode.
RF Design is a screen shot of the radio operation modes for an AP.
Figure 14 Setting the radio operation mode for an AP
Scanning of IAPs
IAPs can work in various modes, on each of its radio 2.4 GHz or 5GHz.
Select the IAP and click on edit to bring the following box:-
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 40
AP Scanning (Access Mode)
The primary duty of an AP is to serve clients. However, an AP also scans the air to perform the following tasks:
l
Looking for better channels
l
Monitoring for Intrusion Detection System (IDS) events
l
Listening for clients
l
Searching for rogue devices
l
Participating in containment of rogue devices
By default, an AP scans its current channel in the normal course of operation and goes off channel to scan every 10
seconds. A small amount of jitter occurs to ensure that a full beacon period is examined. The AP spends 85
milliseconds scanning off-channel, that is, the AP scans the foreign channel for approximately 65 milliseconds (with
20 milliseconds of overhead used as the radio changes channels) and then reverts to its home channel.
The scanning behavior in an IAP is the same as that in a campus AP, which is to perform off-channel scanning
every 10 seconds. The only difference is at boot-up: an IAP scans more aggressively (1 scan per second) during
the first 10 minutes after boot-up.
AM Scanning (Monitoring Mode)
AM scanning is similar to AP scanning, except that the air monitor (AM) constantly scans other networks and does
not serve clients. The AM listens, and transmits only to contain rogue APs or clients. When a rogue device must be
contained, the AM can spend more time containing the rogue device than scanning, which results in more consistent
enforcement.
When you deploy AMs on AP hardware that has only one radio, the AM alternates between the 2.4 and 5 GHz band
on the single radio AP.
41 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
Spectrum Monitoring (Spectrum Monitor mode)
In most WLAN deployments, the primary source of any performance degradation starts at Layer 1, that is, the RF
spectrum or physical layer. Aruba Instant offers integrated spectrum analysis, which adds a layer of visibility into
802.11 WLANs. Visibility into the RF allows you to see what is occurring in the air and is a key requirement for
troubleshooting RF issues.
Spectrum analysis can classify and identify non-802.11 interference sources, providing real-time analysis at the
point where the problem occurs. Spectrum analysis is best utilized when integrated into the WLAN infrastructure,
because hand-held tools are useful only when IT staff are on-site and interference is present – an unlikely
combination in distributed enterprises.
The solution to the problem is a set of integrated tools that enable visibility when using the existing infrastructure.
Instant offers spectrum monitoring in two modes of operation:
l
Hybrid Spectrum (Background Spectrum Monitoring: An AP radio in hybrid AP mode continues to serve
clients as an AP while it analyzes spectrum analysis data for the channel that the radio uses to serve clients. You
can record data for both types of spectrum monitor devices. However, the recorded spectrum is not reported to
the virtual controller (VC).
If a non-Wi-Fi interference device is detected, a spectrum alert is sent to the VC.
l
Dedicated Spectrum Monitor (SM): SMs are IAP radios that gather spectrum data but do not service clients.
Each SM scans and analyzes the spectrum band that is used by the SM radio (2.4 GHz or 5 GHz).
The main difference between Hybrid Spectrum mode and Dedicated Spectrum Monitor mode is that in Hybrid
Spectrum mode, the AP reports only spectrum data for its home channel. In Dedicated Spectrum Monitor mode,
spectrum data for all channels is reported.
For more information about spectrum monitoring, see the Aruba Instant User Guide that is available at the Aruba
support website.
Adaptive Radio Management
If channels and power are updated only when an AP boots up or only every 24 hours, then radio management is
insufficient and based on a snapshot of the RF environment only. Devices, walls, cubes, office doors that open and
close, microwave ovens, and even the human body all have an effect on the RF environment. Generally, you cannot
test and compensate for such a fluid environment in a static channel and power plan. You need a system that can
dynamically adjust to and optimize the ever changing RF environment. Adaptive Radio Management (ARM) is such
a system.
At the most basic level, before ARM configures power and channel settings for APs, it allows the network to
consider Wi-Fi interference, non-Wi-Fi interference, and the presence of other APs. APs and air monitors (AMs)
continuously scan the environment. If an AP goes down, ARM automatically fills in the RF hole and increases the
power on the surrounding APs until the original AP is restored. When the AP is restored, ARM sets the network to a
new optimal setting. If an interfering device (Wi-Fi or non-Wi-Fi) appears on the network, such as a wireless camera
that consumes a channel, ARM adjusts the AP channels appropriately.
Some of the functionalities that ARM provides are shown in RF Design and described in Selected ARM Settings.
(For recommendations about ARM settings, see Recommended IAP Settings.)
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 42
Figure 15 Configuring the ARM settings
Table 3: Selected ARM Settings
ARM Setting
Description
Auto Channel and
Power setting
These settings are enabled by default on IAPs. You also can manually set the
channel or power for APs.
Scanning
When enabled, the APs periodically scan other channels for RF management
and WIPS enforcement.
Client-aware
scanning
When enabled, ARM does not change channels for APs when clients are
active, except for high-priority events such as radar or excessive noise. To
ensure a stable WAN experience, Aruba recommends that you enable clientaware scanning for most deployments.
Supports these four modes:
l
Band steering mode
l
l
43 | Designing Enterprise Networks with Aruba Instant
Prefer mode: If the client supports both the 5 GHz and 2.4 GHz bands,
the AP directs the client to use the 5 GHz band.
Force mode : If the client supports both the 5 GHz and 2.4 GHz bands,
the AP allows the client to use only the 5 GHz band. However, clients
that support only the 2.4 GHz band can still connect to the 2.4 GHz band.
Balance mode : Attempts to balance clients between the two bands
within an approximate ratio of four 5 GHz clients for each single 2.4
GHz client.
Aruba Instant Validated Reference Design
l
Client match
Disabled mode : The client selects which band to use.
Continuously monitors the RF neighborhoods of the clients and provides band
steering and load balancing of the clients while they are associated to the
network. Helps sticky clients roam to better APs.
Supports these three modes:
l
Airtime fairness mode
l
l
Default Access: Airtime fairness algorithms are disabled.
Fair Access: All clients get the same airtime irrespective of their
capabilities.
Preferred Access: 11n/11ac clients get more airtime than 11a/11g
clients, which get more airtime than 11b clients. The ratio is 16:4:1.
Additional RF Optimization Features
In addition to the ARM settings that are described in the previous section, you can enable these features on an IAP
to further optimize the performance over the air. For a complete list of recommendations for ARM settings and each
of these features, see Recommended IAP Settings.
l
Broadcast Filtering: This feature is available in the Network (SSID) settings on the virtual controller and
supports the following settings:
n
All: The APs drop all broadcast and multicast frames except DHCP and ARP.
n
ARP: In addition to dropping all broadcast and multicast frames except DHCP and ARP, the APs convert
ARP requests to unicast and send these packets to the associated clients.
n
Disabled: All broadcast and multicast traffic is forwarded.
Figure 16 Configuring broadcast filtering
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 44
Aruba recommends that you set broadcast filtering to ARP. However, if you run multicast applications on the
network, disable broadcast filtering to prevent multicast traffic from being dropped from the WLAN.
l
Multicast Transmission Optimization: If you enable multicast optimization, the AP selects the optimal rate for
sending broadcast and multicast frames based on the lowest transmission rate that is indicated by the rate
adaptation state of each associated client. (See RF Design.)
l
Dynamic Multicast Optimization (DMO): The 802.11 standard states that multicast traffic over WLAN must be
transmitted at the lowest supported rate so that all clients can decode it. The low transmission rate results in
increased airtime utilization, and therefore decreased overall throughput for transmissions. Because of the slower
speed, it is desirable to transform multicast traffic to unicast traffic when a few clients have subscribed to a
multicast stream. Transforming multicast traffic to unicast traffic increases the speed of wireless transmissions
by using the higher unicast rates. (See RF Design.)
For more information, see Aruba QoS Features.
Figure 17 Configuring multicast optimization
l
Local Probe Request Threshold: A station that is trying to join any WLAN can search for available wireless
networks by performing an active scan or a passive scan. During a passive scan, the client listens to beacon
frames that are sent by the APs on every possible channel to discover the available wireless networks. During a
passive scan, the station must wait until it can detect a beacon from the AP. During an active scan, the client
sends a probe request to detect the presence of an AP on a channel. An AP that detects a probe request must
respond with the probe response. The probe response provides the client with all the required information about
the network that is broadcasted by the AP.
45 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
In dense environments, some clients might join an AP with a lower SNR, even in the presence of APs with a better
SNR. The local probe threshold feature defines the SNR value below which the AP ignores the incoming probe
requests. As a result, the clients get a probe response only from APs that have a good SNR with the client. This
feature encourages proper roaming in dense deployments. The supported range for the SNR value is 0-100 dB. A
value of 0 disables this feature.
Aruba recommends that you enable this feature in dense environments (an AP every 3600 sq. ft) with the value set to
25 dB. (See RF Design).
Figure 18 Configuring the local probe request threshold
l
Interference Immunity Level: If an AP attempts to decode a non-802.11 signal, its ability to receive traffic can
be interrupted momentarily. The noise immunity feature helps improve the network performance in environments
with a high level of non-802.11 noise from devices such as Bluetooth headsets, video monitors, and cordless
phones. You can configure the noise immunity feature form level 0 through level 5. For more information about
interference immunity levels, see the Aruba Instant User Guide that is available at the Aruba support website.
Increasing the immunity level makes the AP slightly “deaf” to its surroundings, that is, it causes the range of the
AP to decrease slightly. The default and recommended immunity level for most deployments is level 2. (See RF
Design).
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 46
Figure 19 Configuring the interference immunity level
Client Match
ARM helps the WLAN to steer clients to the best APs, and it does so during the time of client association. It does not
trigger AP changes for clients that are already associated to an IAP.
The Aruba Client Match feature continually monitors the RF neighborhood of a client to provide ongoing client band
steering and load balancing for associated clients, and enhanced AP reassignment for roaming clients.
When the Client Match feature is enabled on an IAP, the AP measures the RF health of its associated clients. If one
of these three mismatch conditions is met, clients are moved from one AP to another for better performance and
client experience:
l
Dynamic Load Balancing: The Client Match feature balances clients across IAPs on different channels, based
upon the client load on the APs and the SNR levels that the client detects from an underutilized AP. If an AP radio
can support additional clients, the AP participates in Client Match load balancing, and clients are directed to that
AP radio, subject to predefined SNR thresholds.
47 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
As of Instant 6.3.1.1-4.2., spectrum load balancing is integrated with the Client Match feature.
l
Sticky Clients: The Client Match feature helps mobile clients that tend to stay associated to an AP despite low
signal levels. IAPs using the Client Match feature continually monitor the RSSI of a client as it roams between
APs, and move the client to an AP when a better radio match is found. This feature prevents mobile clients from
remaining associated to APs with a less than ideal RSSI, which can cause poor connectivity and reduce
performance for other clients that are associated with that IAP.
l
Band Steering: IAPs that use the Client Match feature monitor the RSSI for clients that advertise a dual-band
capability. If a client is associated to the 2.4 GHz radio and the AP detects that the client has a good RSSI from
the 5 GHz radio, the AP attempts to steer the client to the 5 GHz radio, as long as the 5 GHz RSSI is not
significantly worse than the 2.4 GHz RSSI, and the IAP retains a suitable distribution of clients on each of its
radios.
Aruba recommends that you use the default settings for the Client Match feature.
Recommended IAP Settings
Aruba recommends the IAP settings that are summarized in Recommended Settings for an IAP.
Table 4: Recommended Settings for an IAP
Feature
Default
Setting
Sparse
AP with
Data
only
Dense AP
with Data
Only
Recommended
settings for Video
and Voice
High Interference
Environment
Scanning
Enabled
Default
Default
Default
Default
(Disable scanning on
detecting voice or video
traffic under ACL)
Client Aware
Scanning
Enabled
Default
Default
Default
Disabled
Background
Spectrum
Monitoring
Disabled
Default
Default
Default
Enabled (to show the
sources of interference)
Client Match
Disabled
Default
Default
Default
Default
Band Steering
Prefer
5Ghz
Default
Default
Default
Default
Airtime fairness
Fair
Access
Default
Default
Default
Default
Min Transmit
Power
18
Default
9
Default
12
Broadcast filtering
Disabled
All
ARP
ARP
ARP
(Disabled if running
multicast applications)
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 48
Default
Setting
Sparse
AP with
Data
only
Dense AP
with Data
Only
Recommended
settings for Video
and Voice
High Interference
Environment
Multicast
Optimization
Disabled
Enabled
Enabled
Enabled
Enabled
Dynamic Multicast
Optimization
Disabled
Default
Default
Enabled
Default
Local Probe
Request
Threshold
0=
Disabled
Default
Enabled
(value=25db)
Enabled (value=25db)
Enabled (value=25db)
Interference
Immunity Level
2
Default
Default
Default
Default
Wide Channel
Bands
5 GHz
Default
Default
Default
Default
Beacon Interval
100ms
Default
Default
Default
Default
Dynamic CPU
Management
Automatic
Default
Default
Default
Default
Min Legacy (non11n) Transmit
Rates 2.4 GHz
1
2
11
Default
11
Min Legacy (non11n) Transmit
Rates 5 GHz
6
Default
Default
Default
Default
Feature
Modify this value only if the
Aruba Support Team
advises that you do so.
4.2 is required for IAP Client Match and IAP software 4.2.1 onwards is recommended. On IAP softwares 4.1.1 and
earlier, client match is not recommended.
Band steering requires equal coverage between the 2.4 GHz and 5 GHz bands to be effective. A larger 2.4 GHz
coverage model results in unpredictable results for clients, especially if band steering is set to the “Force 5Ghz”
mode. Examine the network coverage using VisualRF™ Plan before you set band steering to the “Force 5Ghz”
mode. Plan new networks using a
5 GHz coverage model and deploy the network with dual-mode APs at each location. Such a deployment allows
ARM to decrease power in the 2.4 GHz band to compensate for the dense deployment.
49 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
Starting 4.2, you can set different max & minimum level of transmit power, for 2.4 GHz & 5 GHz bands, you can do it
through the following settings:
QoS Design
Depending upon what type of applications are expected in your network, it might be important to have certain
mechanisms in place that treat real-time applications differently than other applications. For example, voice and
video applications that are sensitive to jitter and latency must traverse the network faster, so they are given
precedence over best-effort applications such as email and print jobs.
Quality of service (QoS) is a set of packet markings and queuing mechanisms that prioritize classes of traffic
through the network. Wi-Fi Multimedia (WMM) is based on the 802.11e amendment. WMM is a system for marking
traffic as higher priority and adjusting the packet timers to allow delay-sensitive data to have precedence on the air.
End-to-End QoS
For QoS and WMM to work effectively, they must be deployed end-to-end throughout the network. All components
must recognize the packet marking and must react in the same way to ensure proper handling. Complete
deployment of QoS ensures consistent delivery of data. With proper planning, high-quality voice and video can be
achieved over the WLAN.
QoS Design shows how DSCP, 802.11p, and WMM marking are used in an Aruba Instant deployment.
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 50
Figure 20 DSCP, 802.11p, and WMM marking
Two mechanisms are involved: WMM/802.11e on the wireless side and DiffServ Code Point (DSCP) and 802.1p
tagging on the wired side. WMM handles prioritization, queuing of packets, and servicing of queues. WMM also has
additional power-saving mechanisms to extend battery life. DSCP/802.1p tagging ensures appropriate delivery on
the wired side of the network. To be effective, this tagging must be implemented throughout the network with the
same values at all nodes.
QoS on the WLAN
Aruba Instant uses WMM to provide the correct level of service to wireless clients. WMM specifies four classes of
traffic: voice, video, best effort, and background. WMM also enables shorter wait times for higher-priority traffic by
adjusting the interframe spacing for these packets. The traffic classes map directly to DSCP traffic classes and
marks, which enables traffic to be easily translated between the two mechanisms. When a packet with a DSCP/802.1p marked packet arrives from the wired side of the network, that marking is
translated into a WMM marker. When a wireless frame that is marked with WMM is received from a wireless client,
the IAP includes the marking in the Ethernet frame header before forwarding it on the wired network. The IAP has
queues to ensure that traffic is processed with the proper priority.
The Aruba infrastructure can set the appropriate tagging from the IAP to the WLAN client, and from the IAP into the
access layer. However, the client must also understand WMM and use the proper tagging and sending mechanisms
to ensure that traffic flows appropriately.
QoS on the LAN Edge and Core
The LAN between the IAP and the core must recognize and prioritize DSCP-marked traffic through the network.
Similarly, the core must respect the QoS marks from the LAN edge to any multimedia servers.
Aruba QoS Features
In addition to the standard-based features, Aruba supports features that are specific to the Instant solution.
Stateful Firewall
The Aruba Instant firewall module allows policies to be applied to user traffic sessions.
51 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
In addition to the functions that are typically associated with firewalls, the Aruba firewall can also reclassify traffic.
Firewall policies and Application Layer Gateways (ALGs) allow traffic that is not marked with the correct priority to be
dynamically reclassified for proper prioritization.
Media Classification
Apart from ALG support for applications such as SIP and Vocera, the Classify Media feature can also be enabled
inside the firewall rule of an IAP to classify and prioritize hard-to-detect applications such as Lync voice and video.
These Lync applications use Session Initiation Protocol-Transport Layer Security (SIP-TLS) as the signaling
protocol, which means the signaling traffic is encrypted. Encryption makes it harder to detect the type of the
application and thus apply any markings on encrypted traffic. Using the Classify Media feature enables the firewall
on the IAP to perform a deep packet inspection (DPI) to analyze the packet flows and accurately classify the traffic
as Lync voice or video.
It is critical that all devices in the network are capable of QoS and are configured for QoS. Switches and the
multimedia servers themselves must mark traffic appropriately. Failure to ensure end-to-end prioritization can cause
unpredictable performance for these applications. Bandwidth Management
Bandwidth management, in general, ensures that each traffic class gets the proper prioritization, but consideration
should also be given to the overall bandwidth of the system. Bandwidth management on Aruba Instant can be
loosely divided into two categories listed below:
l
Application bandwidth management
l
User and network bandwidth management
Application Bandwidth Management
Application bandwidth management is based on WMM classification.
Each traffic class (voice, video, best effort, and background) is allocated a certain percentage of the traffic. This
mechanism takes effect during congestion to service queues on a percentage basis. (See QoS Design .)
In the absence of congestion (that is, no traffic queues exist), all four traffic classes are allowed to use the entire
available network bandwidth.
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 52
Figure 21 Configuring WMM for traffic classes
Configure WMM percentages in networks that have special requirements or when Aruba Technical Support
advises you to do so.
User and Network Bandwidth Management
Aruba Instant provides the following user and bandwidth management options:
l
SSID-based bandwidth management: Airtime is allocated to each SSID on the system as a percentage. Each
individual SSID is allowed some percentage with the ability to burst if there is no contention for the medium. (See
QoS Design .)
53 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
Figure 22 Configuring airtime for SSIDs
Configure an airtime percentage only in networks that have special requirements or when Aruba Technical Support
advises you to do so.
l
Radio-based bandwidth management: Each radio is allocated a bandwidth amount, which is the aggregate
throughput that is provided to all clients that are connected to that radio. (See QoS Design ).
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 54
Figure 23 Configuring radio-based bandwidth
Configure radio bandwidth only in networks that have special requirements or when Aruba Technical Support
advises you to do so.
l
User-based bandwidth management: Each user is allocated a portion of the available bandwidth for their use.
(See QoS Design .)
55 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
Figure 24 Configuring user-based bandwidth
Role-based bandwidth management: All users on the Aruba system are assigned a role, and a bandwidth
contract is allocated to all users for that particular role. (See QoS Design ).
Figure 25 Configuring role-based bandwidth
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 56
Dynamic Multicast Optimization (DMO)
The 802.11 standard states that multicast over WLAN must be transmitted at the lowest supported rate so that all
clients can decode it. Also, broadcast and multicast frames are not acknowledged, so these transmission methods
use lower (that is, slower) data rates to provide a better chance of reception. The low transmission rate results in
increased airtime utilization, and therefore decreased overall throughput for transmissions.
Multicast is transmitted at slower speed, so it is beneficial to transform multicast traffic to unicast traffic if a few
clients have subscribed to a multicast stream. Transforming multicast traffic to unicast traffic increases the speed of
wireless transmissions by using the higher unicast rates.
QoS Design shows a non-DMO flow versus a DMO flow. QoS Design is a screen shot of the WLAN settings
screen that lets you configure DMO.
Figure 26 Non-DMO flow (left image) versus DMO flow (right image)
57 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
Figure 27 Configuring DMO
ARP Broadcast Filter
The ARP broadcast filter converts broadcast ARP requests to unicast requests. The ARP request is directed only to
the client that must receive the request. This feature reduces the need to broadcast requests to multiple clients for
data that only one client must receive.
If you run multicast applications on the network, disable ARP broadcast filtering to prevent multicast traffic from
being dropped on the WLAN. (See QoS Design .)
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 58
Figure 28 Configuring ARP broadcast filtering
Design for Plug-and-Play Services
This section describes a particular plug-and-play protocol: Apple Bonjour.
AirGroup is a unique enterprise-class Aruba capability that leverages zero-configuration networking to efficiently
enable Bonjour services such as Apple AirPrint and AirPlay from mobile devices. Apple AirPlay and AirPrint services
are based on the Bonjour protocol and are essential services in campus Wi-Fi networks.
Zero-configuration networking enables, address assignment, service discovery, and name resolution for desktop
computers, mobile devices, and network services. Zero-configuration networking is designed for a flat, single-subnet
IP network such as a wireless home network.
Bonjour is the trade name for the zero-configuration implementation that Apple introduced. Bonjour is supported by
most of the Apple product lines, including the Mac OS X operating system, iPhone, iPod Touch, iPad, Apple TV, and
AirPort Express.
Challenges with Multicast DNS
Multicast DNS (mDNS) is a host name resolution service that is implemented by Apple as an alternative to the
popular DNS service. When mDNS was introduced, it was intended primarily for local shared networks in which
devices could find each other without requiring additional infrastructure on the network such as a DNS server.
The addresses that Bonjour uses are link-scope multicast addresses, so each query or advertisement can be
forwarded only on its respective VLAN, but not across different VLANs.
As Bonjour-capable products such as iPods, iPads, iPhones and MacBooks started penetrating enterprise networks,
they presented certain challenges:
l
In K-12 schools, universities and enterprise networks, it is common for Bonjour-capable devices to connect to the
network across VLANs. As a result, an iPad on one VLAN cannot discover an Apple TV that resides on another
59 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
VLAN because mDNS traffic in its native form is limited to a Layer 2 network and does not propagate across
VLANs.
l
Broadcast and multicast traffic are usually filtered out from a WLAN to preserve the airtime and battery life. This
limitation inhibits the performance of Bonjour services because they rely on multicast traffic.
l
Other users on the same VLAN can discover personal devices, which might not be desirable.
The AirGroup Solution
AirGroup is an Aruba-proprietary solution that helps to address the above-mentioned mDNS challenges as follows:
l
AirGroup maintains seamless connectivity between clients and services across VLANs and SSIDs.
l
Even if broadcast and multicast controls are enabled on an SSID, AirGroup creates special exceptions to send
select mDNS traffic across the WLAN to learn about Bonjour services.
l
AirGroup on an IAP sends unicast mDNS responses to clients requesting mDNS services on the WLAN. The
WLAN carries no downstream multicast traffic, so airtime, and client battery life are significantly improved.
You can also integrate AirGroup with the ClearPass Policy Manager (CPPM) to provide these benefits:
l
Users can register their personal devices on the network in such a way that they have exclusive access to these
devices. They can also define a group of users who can share the registered devices.
l
Administrators can register and manage the shared devices of an organization, such as conference room printers
and classroom Apple TVs. An administrator can grant global access to each device (for example, Apple TV
access for both teachers and students), or restrict access according to the user name, role, or user location.
In Aruba Instant 4.2 release, Digital Living Network Alliance (DLNA)/ Universal Plug and Play (UPnP) devices (that
use Simple Service Discovery Protocol [SSDP] for discovering other DLNA/UPnP based services) are also
supported in their native form, that is, DLNA devices can interconnect on the same VLAN. A future Aruba Instant
release would support AirGroup functionality for DLNA devices on Aruba Instant, in the same way it is currently
supported for mDNS-based Bonjour devices.
AirGroup Capabilities Supported by Aruba Instant
AirGroup Capabilities summarizes some of the AirGroup capabilities. The Integrated column shows whether the
capabilities are supported in Aruba Instant. The Integrated with CCPM column shows capabilities that require
ClearPass Policy Manager.
Table 5: AirGroup Capabilities
Features
Instant Deployment Models
Integrated
Integrated with
CPPM
Allow mDNS to propagate across subnets and
VLANs
Yes
Yes
Limit multicast mDNS traffic on the network
Yes
Yes
VLAN based mDNS service filtering
Yes
Yes
User-role based mDNS service filtering
Yes
Yes
Portal to self-register personal devices
No
Yes
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 60
Features
Instant Deployment Models
Integrated
Integrated with
CPPM
Device owner based policy enforcement
No
Yes
Location based policy enforcement
No
Yes
Shared user list based policy enforcement
No
Yes
Shared role list based policy enforcement
No
Yes
AirGroup Solution Architecture
The distributed AirGroup architecture allows each IAP to handle Bonjour queries and responses individually instead
of overloading a virtual controller with these tasks. This type of traffic handling results in a scalable AirGroup
solution.
AirGroup in a Single IAP Cluster
Below mentioned is a configuration example in which IAP1 discovers Air Printer (P1) and IAP3 discovers Apple TV
(TV1). IAP1 advertises information about P1 to the other IAPs (IAP2 and IAP3). Similarly, IAP3 advertises TV1 to
IAP1 and IAP2. This type of distributed architecture allows any IAP to respond to its connected devices locally. In
this example, the iPad that is connected to IAP2 obtains a direct response from the same IAP about the other
Bonjour-enabled services in the network.
Figure 29 Example of an AirGroup in a single IAP cluster
AirGroup in a Single IAP Cluster with ClearPass Policy Manager
You can use ClearPass Policy Manager (CPPM) in an IAP cluster to provide users with a personalized AirGroup
experience. You can use the device registration portal under CPPM to register AirGroup devices on the network.
These devices can then be used as personal or shared devices on the network.
61 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
Below is a configuration example in which a network administrator registers an AirPrint printer (P1) and an Apple TV
(TV1) on the network through the ClearPass device registration portal, using IT admin credentials. The printer P1 is
visible to both users X and Y, whereas TV1 is visible only to user X.
Figure 30 Example of an AirGroup in a single IAP cluster with CPPM
AirGroup in Multiple IAP Clusters
You can configure AirGroup domains to enable AirGroup users on one cluster to access AirGroup servers on another
cluster. AirGroup server databases are synchronized between IAP clusters every two minutes.
Below Design for Plug-and-Play Services is a configuration example in which clusters (also referred to as swarms) 1
and 2 are configured as members of an AirGroup domain. (You configure this on the VC of each cluster.) An iPad that
is connected to IAP2 not only has access to servers P1 and TV1 within its own cluster (Swarm 1) but also to servers
P2 and TV2 that are connected to IAPs in the neighboring cluster (Swarm 2).
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 62
Figure 31 Example of an AirGroup in multiple IAP clusters
When you enable an AirGroup across multiple clusters, the DNS records in the virtual controller of one cluster can be
shared with all virtual controllers that are configured for Layer 3 Mobility. (By default, Layer 3 Mobility is disabled).
Design for Plug-and-Play Services is a screen shot of the screen that lets you enable an AirGroup and AirGroup
services, and define a ClearPass Policy Manager server.
Figure 32 Configuring AirGroup settings
63 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
AirGroup Recommendations
Aruba has the following recommendations for AirGroup:
l
In large deployments with many wireless and wired users, often many Bonjour services are advertised, which
can consume a significant amount of system resources. In such large deployments, Aruba recommends that you
initially enable only the most commonly used AirGroup services, such as AirPlay and AirPrint, and disable the
“allowall” service.
l
Wired AirGroup devices:
n
All AirGroup devices that are wired on the network must have their VLANs trunked on the access switch to
the IAP on which AirGroup is configured. If you do not follow this recommendation, AirGroup does not detect
mDNS activity from these wired devices.
n
Tag a wired AirGroup server with location-based attributes such as AP name, AP group, or AP FQLN. For
example, if you tag a wired AirGroup server with an AP named AP1, both users that are connected to AP1 and
users that are connected to APs that are in the RF neighborhood of AP1 can detect the wired AirGroup server.
n
Port recommendations: Bonjour uses UDP port 5353 for mDNS discovery, whereas application-specific
traffic for services such as AirPlay can use dynamically selected port numbers. If you configure role-based or
network-based access rules on an SSID, modify these access rules to allow traffic on these ports. Static and
Dynamic Ports for AirPlay Service lists the port numbers for AirPlay service. Static Ports for AirPrint Service
lists the port for AirPrint service.
AirGroup is not supported on a 3G uplink.
Table 6: Static and Dynamic Ports for AirPlay Service
Ports for AirPlay Service
Protocol
Ports
TCP
554
5000
7000
7100
8612
49152-65535
UDP
554
7010
7011
8612
49152-65535
AirPlay operates using dynamic ports, but printing protocols such as AirPrint use static ports.
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 64
Table 7: Static Ports for AirPrint Service
Ports for AirPrint Service
Protocol
Print Service
Port
TCP
Data stream
9100
TCP
IPP
631
TCP
HTTP
80
TCP
Scanner
9500
TCP
HTTP-ALT
8080
Configuring AirGroup
This section provides sample procedures of how you can configure AirGroup, AirGroup services, and associated
features on a Virtual Controller.
Enabling AirGroup
You can enable AirGroup and AirGroup services to advertise services across VLANs:
1. Choose More > Services and then click the Air Group tab.
2. Select the Enable AirGroup check box.
3. Choose the desired AirGroup services (for example, AirPlay and AirPrint) by selecting their check boxes.
4. Click OK.
65 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
Filtering Services Based on User Role
You can filter AirGroup services based on a user role. For example, you can prevent students from seeing any Apple
TVs on the network:
1. Choose More > Services and then click the Air Group tab.
2. Select the Enable AirGroup check box.
3. Select the airplay check box.
4. Next to airplay disallowed roles, click the Edit link.
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 66
5. Select student (which, in this case, is the role to disallow).
6. Click OK.
7. Verify the configuration.
8. Click OK.
Filtering Services Based on VLANs
You can prevent a service such as AirPrint that originates from a particular VLAN from being advertised to other
users on the network:
1. Choose More > Services and then click the Air Group tab.
2. Select the Enable AirGroup check box.
67 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
3. Select the airprint check box.
4. Next to airplay disallowed vlans, click the Edit link.
5. Enter the VLAN ID.
6. Click OK.
7. Verify the configuration.
8. Click OK.
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 68
Creating a “Personalized” WLAN: Registering Personal and Shared Devices on ClearPass
When you enable AirGroup, by default, all users in an Instant cluster can see all services that originate within the
cluster, irrespective of what user role or VLAN they belong to. However, in many environments, users must have
exclusive access to the services that they own.
For example, a student in a campus dorm room might want exclusive access to his Apple TV and AirPrint-enabled
printer. Students from neighboring dorm rooms should not be allowed to see these devices.
The student can register these devices on the ClearPass device registration portal and specify whether the devices
can be shared by other students or not.
To allow such a configuration, ensure that the Instant VC and ClearPass Guest are properly configured to
communicate with each other.
As a network administrator, you can register a classroom Apple TV on the ClearPass “Device Registration Portal” by
first configuring the VC and then the ClearPass settings:
1. Choose More > Services and then click the Air Group tab.
2. Select the Enable AirGroup check box.
3. Select the airplay and airprint check boxes.
4. Add a ClearPass server to exchange AirGroup messages between the VC and the ClearPass server.
In the ClearPass Settings section of the screen, next to CCPM server 1, choose New from the dropdown box.
69 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
5. On the New Server Screen, enter the IP address and shared key for the ClearPass server.
6. To query and receive updates from the ClearPass server, define an RFC 3576-compliant AirGroup server, which
is different from an RFC 3576-complaint authentication server. If a port is already defined for an authentication
server, you cannot use that same port for an AirGroup server.
On the New Server screen, enable RFC 3576, specify the AirGroup CoA port, and click OK.
By default, Aruba Instant and the ClearPass server use port 5999 to communicate with each other. You can use
another port, provided that you specify the same port on both the Instant VC and the ClearPass server.
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 70
7. On the AirGroup screen, in the ClearPass Settings section, select the Enforce ClearPass registration check
box.
8. Click OK.
Essentially, on the ClearPass server, you define the AirGroup controller that ClearPass must communicate with
and assign the correct AirGroup privileges to users. These users can then log in to the device registration portal
and register their devices.
For information about configuring AirGroup settings on ClearPass, including best-practice recommendations, see the
AirGroup Deployment Guide and ClearPass User Guide that are available at http://support.arubanetworks.com.
Extending an AirGroup across Instant Clusters
By default, AirGroup services are advertised among IAPs that belong to the same cluster. An iPad that is connected
to an IAP in one cluster cannot detect an Apple TV that is connected to an IAP in another cluster.
You can enable sharing of AirGroup services across Instant clusters by completing these configuring steps on the
VC of each Aruba Instant cluster:
1. Choose System > Show advanced options and then click the L3 Mobility tab.
71 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
2. Define the VCs of all Instant clusters across which AirGroup must be enabled.
3. Click OK.
4. Choose More > Services and then click the Air Group tab.
5. Select the Enable AirGroup across mobility domains check box.
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 72
6. Click OK.
Make sure that you complete these configuration steps on the VC for each cluster that participates in AirGroup
service sharing.
Content Filtering using Open DNS
The Content Filtering feature lets you create Internet access policies that allow or deny user access to websites
based on website categories and security ratings. With this feature, you can take the following actions:
l
Prevent known malware hosts from accessing your wireless network.
l
Improve employee productivity by limiting access to certain websites.
l
Reduce bandwidth consumption significantly.
Aruba Instant can use the OpenDNS credentials to access OpenDNS and provide enterprise-level content filtering.
You can configure content filtering on an SSID and you can manually configure up to four enterprise domains. When
enabled, all DNS requests to non-corporate domains on this wireless network are sent to the open DNS server. (See
Entering credentials for OpenDNS and Content Filtering using Open DNS.)
73 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
Figure 33 Entering credentials for OpenDNS
Figure 34 Enabling content filtering
To create corporate domain exceptions, ensure that you configure enterprise domains on the VC. When you enable
content filtering, all client DNS requests to non-corporate domains are routed to the OpenDNS server. (See Content
Filtering using Open DNS.)
Figure 35 Configuring enterprise domain names
For information about configuring content filtering, see the Aruba Instant User Guide that is available at the Aruba
support website. You can also create policies using AppRF feature on IAP.
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 74
Security Design
When you design an enterprise WLAN, you must determine the following important security aspects:
l
How are users authenticated on the network and how is data secured over the air?
l
How is the air monitored and how do you protect your infrastructure and users from malicious attacks?
In addition, you also can restrict user access to the network based on their identity. After users are authenticated on
a network, you can assign them different user roles. A user role determines the resources that a user can access on
the network.
You can also combine Aruba Instant with the ClearPass system to enforce more granular security policies across
the network based on the identity and device type of the user.
For information about ClearPass and how to integrate it with Aruba Instant, see the ClearPass User Guide that is
available at the Aruba support website.
Authentication and Encryption
A strong understanding of authentication and encryption is essential to deploy a secure and functional WLAN.
Evaluate the different options against the goals of the organization and the security and operational requirements that
the organization operates under. The number of different authentication and encryption options that must be
supported also influences the design of the WLAN and the number of SSIDs that must be broadcast.
In general, each new authentication type or encryption mode that is required means that you must deploy an
additional SSID. Each SSID that you deploy appears as an individual AP, and it must send beacons, which uses up
valuable airtime. To preserve radio resources, organizations should consider the types of devices to be deployed and
attempt to limit the number of SSIDs.
Depending upon whether you configure an SSID for employee or guest usage, Aruba Instant provides different
authentication and encryption methods:
l
Authentication: Aruba Instant supports multiple authentication methods. Which method you use depends on the
network goals, security requirements, user types, and device types on the network.
Authentication is typically separated into two models, Layer 2 and Layer 3. These models can be combined for
additional authentication.
l
Encryption: In addition to authentication, you must choose an encryption method that protects the over-the-air
transmissions. Aruba strongly recommends using encryption because the wireless transmissions of an
organization can easily be captured or “sniffed” directly in the air during transmission.
Authentication and Encryption for an Employee SSID
This section describes the authentication methods and encryption levels that are available for an SSID for employee
usage and provides recommendations for authentication and encryption.
Authentication Methods
When you configure an SSID for employee usage, select one of the following authentication methods:
l
Open authentication: Open authentication really means no authentication. The network is available for anyone
to join and no keys are required. This form of authentication is often combined with MAC authentication or a Layer
3 authentication method that is used after connection to the network.
Aruba strongly advises against using open authentication in employee networks.
l
MAC authentication: MAC authentication is a legacy form of filtering that requires the MAC address of a
machine to match a manually defined list of addresses. This form of authentication does not scale past a handful
of devices because it is difficult to maintain the list of MAC addresses.
75 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
In addition, never rely on MAC authentication as the primary authentication method. With the help of built-in driver
tools, it is easy to change the MAC address of a station to match one on the accepted list.
l
Personal authentication: Each of the following Layer 2 authentication methods is available as the primary
authentication method on an Aruba Instant network and can be combined with MAC authentication. In the latter
case, all users that are subject to any of these authentication methods must first pass MAC authentication.
n
Wired Equivalent Privacy (WEP): The most common version of WEP is static WEP, for which all stations
share a single key for authentication and encryption. Other versions of WEP have different key lengths and
dynamic key assignments.
As an authentication (and encryption) protocol, WEP was fully compromised in 2001. Aruba recommends that
all organizations discontinue the use of WEP and opt for stronger authentication methods.
n
Pre-Shared Key (PSK): PSK is part of the WPA/WPA2 personal certifications. PSK authentication is the
most common form of authentication for consumer Wi-Fi routers. Like WEP, the key is used both for
authentication and encryption.
In enterprise deployments, PSK is often limited to devices that cannot perform stronger authentication. All
devices share the same network key, which must be kept confidential. This form of authentication is easy to
configure for a small number of devices. However, when more than a few devices must use the key, key
management quickly becomes difficult.
The key usually must be changed manually on devices, which poses more problems if the number of devices
that share a key is very large. When an attacker knows the key, they can connect to the network and decrypt
user traffic. Good security practice mandates that the key should be changed whenever someone with access
to the key leaves the organization. This key should be complex and be rotated on a regular basis.
n
Enterprise authentication: This form of authentication includes 802.1X/EAP, which is part of the
WPA/WPA2 Enterprise certifications.
802.1X was developed to secure wired ports by placing the port in a “blocking” state until authentication is completed
using the Extensible Authentication Protocol (EAP). The EAP framework allows many different authentication types
to be used, the most common being Protected EAP (PEAP), followed by EAP-TLS that uses server- and client-side
certificates.
To secure user credentials, a Transport Layer Security (TLS) tunnel is created and user credentials are passed to the
authentication server within the tunnel. When the authentication is complete, the client and the IAP have copies of
the keys that are used to protect the user session.
Users can be authenticated using the internal server on Aruba Instant or by redirecting client authentication requests
to an external authentication server. Using an external server such as ClearPass provides additional features and
additional granularity. Aruba strongly recommends that you use WPA2 for employee authentication.
Authentication Recommendations
Aruba Authentication Recommendations for an Employee SSID summarizes the authentication methods that Aruba
recommends for an employee SSID.
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 76
Table 8: Aruba Authentication Recommendations for an Employee SSID
Authentication
Method
Recommendation
Open
Not recommended
MAC Auth
Not recommended as the only authentication method. If required, combine with restricted user
role.
WEP
Not recommended.
PSK
Recommended only for devices that do not support stronger authentication.
802.1X/EAP
Recommended for use on all networks. Use TLS if client-side certificate distribution is practical,
and use PEAP for all other deployments.
Encryption Levels
When you configure an SSID for employee usage, the following encryption levels are available:
l
Open: As the name implies, open networks have no encryption and offer no protection from wireless packet
captures. Most hot spot or guest networks are open networks, and the end user is expected to use their own
protection methods to secure their transmissions, such as VPN or SSL.
l
Personal: The same pre-shared key that is used for authentication is also used for encryption. Based on whether
you select WPA Personal or WPA2 Personal for authentication, either TKIP or AES is used for encryption.
l
n
Temporal Key Integrity Protocol (TKIP): The Temporal Key Integrity Protocol (TKIP, part of the WPA
Personal certification) was a stopgap measure to secure wireless networks that previously used WEP
encryption and whose 802.11 adapters were not capable of supporting AES encryption. TKIP uses the same
encryption algorithm as WEP, but TKIP is much more secure and has an additional message integrity check
(MIC). Recently some cracks have begun to appear in the TKIP encryption methods.
Aruba recommends that all users who use TKIP migrate to AES as soon as possible.
n
Advanced Encryption Standard (AES): The Advanced Encryption Standard (AES) encryption algorithm
(part of the WPA2 Personal certification) is now widely supported and is the recommended encryption type for
all wireless networks that contain any confidential data. AES in Wi-Fi leverages 802.1X or PSK to generate
per-station keys for all devices. AES provides a high level of security, similar to what is used by IP Security
(IPSec) clients.
Aruba recommends that all devices are upgraded or replaced so that they are capable of AES encryption.
n
WEP: Though WEP is an authentication method, it is also an encryption algorithm for which all users typically
share the same key. As mentioned previously, WEP is easily broken with automated tools, and should be
considered no more secure than an open network. Aruba recommends against deploying WEP encryption and
strongly encourages organizations that use WEP to migrate to Advanced Encryption Standard (AES)
encryption.
Enterprise: Based on whether you have chosen WPA Enterprise or WPA2 Enterprise for authentication, either
TKIP or AES is used for encryption. Dynamic WEP with 802.1X is also an option but not recommended.
Dynamic WEP with 802.1X was intended as an enhancement to make WEP more secure. However, dynamic
WEP with 802.1X has many security shortcomings and is not secure. Aruba recommends against deploying
dynamic WEP with 802.1X.
77 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
Encryption Recommendations
Aruba Encryption Recommendations for an Employee SSID summarizes the Aruba recommendations for encryption
on Wi-Fi networks. Full 802.11ac and 802.11n rates are available only when you use either open (that is, no
encryption) or AES encryption because WEP and TKIP limit the WLAN connection speed to 54 Mb/s.
Table 9: Aruba Encryption Recommendations for an Employee SSID
Encryption Type
Recommendation
Open
Not recommended for use.
WEP
Not recommended for use.
TKIP
Not recommended for use.
AES
Recommended for all deployments
Authentication and Encryption for a Guest SSID
This section describes the authentication methods and encryption levels that are available for an SSID for guest
usage and provides recommendations for authentication and encryption.
Authentication Methods
When you configure an SSID for guest usage, select one of the following authentication methods:
l
Open authentication: Open authentication actually means no authentication. The network is available for
anyone to join and no keys are required. This form of authentication is often combined with a Layer 3
authentication method (a captive portal) that is used after connection to the network. You can combine MAC
authentication with Layer 3 authentication.
l
PSK authentication: In some guest deployments, PSK is used to provide a minimum amount of protection for
guest sessions, and authentication is performed by a Layer 3 mechanism. The PSK key should also be rotated on
a regular basis.
l
Wireless Internet Service Provider roaming (WISPr) authentication: This type of authentication allows
WISPr-enabled clients to connect to the guest network.
l
Captive portal (splash page): After guest users access the network, they can be presented with a captive
portal on their web browser. The captive portal requires the guest user to register or supply guest login credentials
before allowing them to browse the web. After registration and authentication, guests are usually placed in
limited-access roles that allow basic web browsing but deny access to any of the internal resources of the
enterprise.
As a network administrator, you can choose between the internal captive portal and an external captive portal. Aruba
Instant supports a built-in internal captive portal with limited customization. For advanced guest services and highly
customizable captive portal pages, Aruba recommends that you use an external captive portal server such as
ClearPass Guest.
l
Captive portal plus MAC authentication: When MAC authentication is enabled, MAC authentication will be
performed before captive portal authentication. If MAC authentication passes, captive portal authentication can
be skipped.
The internal captive portal on Aruba Instant is customizable, but Aruba recommends that you use ClearPass
Guest for advanced guest services.
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 78
Authentication Recommendations
Aruba Authentication Recommendations for a Guest SSID summarizes the authentication methods that Aruba
recommends for a guest SSID.
Table 10: Aruba Authentication Recommendations for a Guest SSID
Authentication
Method
Recommendation
Open
Recommended for guest networks in conjunction with a higher-level authentication method, such
as captive portal
PSK
Can be used if you must restrict who connects to the guest network or if you must limit the DHCP
scope exhaustion by drive-by devices. PSK on the guest network increases the management
overhead and does not guarantee security.
WISPr
Used in WISPr deployments, common in public venues such as airports.
Captive Portal
Recommended for guest networks if certain policies must be accepted to use the network or a
common logon page is required.
Encryption Levels
When you configure an SSID for guest usage, select one of the following encryption levels:
l
Open: As the name implies, open networks have no encryption and offer no protection from wireless packet
captures. Most hot spot or guest networks are open networks, and the end user is expected to use their own
protection methods to secure their transmissions, such as VPN or SSL.
l
Personal: The same pre-shared key that is used for authentication is also used for encryption. Based on whether
you select WPA Personal or WPA2 Personal for authentication, either TKIP or AES is used for encryption. You
can also select WEP but this is is not recommended.
Encryption Recommendations
Aruba Encryption Recommendations for a Guest SSID summarizes the Aruba recommendations for encryption on
Wi-Fi networks. Full 802.11ac and 802.11n rates are available only when you use either open (that is, no encryption)
or AES encryption because WEP and TKIP limit the WLAN connection speed to 54 Mb/s.
Table 11: Aruba Encryption Recommendations for a Guest SSID
Encryption
Type
Recommendation
Open
Recommended for guest networks.
PSK
Using PSK on the guest network increases the management overhead and does not guarantee
security.
l
l
l
WPA 2 Personal: Recommended for all deployments that use PSK for guest SSID.
WPA personal: Not recommended for use.
WEP: Not recommended for use
79 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
Wireless Intrusion Detection and Prevention
Intrusion detection and prevention features are built into an Aruba IAP to help monitor the RF spectrum and the
infrastructure network for the presence of unauthorized network devices (intrusion detection) and take appropriate
measures to prevent any security breaches on the network (intrusion prevention).
Wireless security can be a complex topic with many different options, and it can be difficult to manage the wide
range of Intrusion Detection System (IDS) and Intrusion Prevention System (IPS) options that are available. To
make things easier for users, a set of powerful, yet simple-to-use wizards are available in Aruba Instant. These
wizards provide reasonable default values and help you step through the available configuration options.
You can select a default template that provides an acceptable level of security for the network or create a
customized set of options. The wizard simplifies the selection of security options and helps to eliminate errors in the
configuration. For more information about these wizards, see IDS Wizard and IPS Wizard.
Intrusion Detection System (IDS)
The Intrusion Detection System (IDS) on the IAP monitors the network for the presence of unauthorized APs and
clients, logs information about these devices, and generates reports based on the logged information. The IDS lets
you detect rogue APs, interfering APs, and other devices that can potentially disrupt network operations.
The IDS function is divided into the following components:
l
Infrastructure IDS: For the network to function as intended, attacks on the infrastructure must be detected and
mitigated. Aruba considers the infrastructure to consist of authorized APs, the RF medium itself, and the wired
network that the APs attach to.
l
Client IDS: The Aruba system must also monitor the clients that attach to the network. Any client that
associates to the network, passes authentication, and is using encryption is considered a valid station. The
system looks for various attack signatures, such as hotspotter and TKIP replay attacks that are targeted at
clients that are attached to the wireless network. The system can also watch for valid stations that attempt to
attach to rogue or neighboring APs.
IDS Dashboard
The IDS dashboard presents an overview of the security for the whole network. This dashboard provides a view into
the status of APs and clients and provides a classification of rogue and interfering APs.
The built-in IDS scans for APs that are not controlled by the virtual controller (VC). These APs are listed and
classified as either interfering or rogue, depending on whether they are on a foreign network (that is, a different VLAN
or subnet than that of the IAP) or on the same network (that is, the same VLAN or subnet as the IAP):
l
Interfering AP: An AP that is detected in the RF environment but that is not connected to the wired network.
Although an interfering AP can potentially cause RF interference, it is not considered a direct security threat,
because it is not connected to the wired network. However, an interfering AP can be reclassified as a rogue AP.
l
Rogue AP: An unauthorized AP that is connected to the wired side of the network.
For classification to work, all potential VLANs on which a rogue AP could be connected must be trunked to IAPs.
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 80
Figure 36 Detected foreign access point and clients
IDS Wizard
The WIP wizard that is shown Security Design provides the options to enable, define, and change these items:
l
Detection options for infrastructure attacks
l
Detection options for WLAN clienxts attacks
Figure 37 Detection settings of the WIP wizard
The detection setting on the WIP wizard for the infrastructure and the client can be turned off or set to a predefined
high, medium, or low level. The WIP wizard also allows custom settings. The high detection setting enables all
applicable detection mechanisms. The medium setting enables some important detection mechanisms, and the low
setting enables only the most critical detection mechanisms.
Aruba IDS Recommendations
Aruba recommends this WIP wizard setting for detection:
To ensure that most critical attacks are detected, set the detection to “Low” and then customize the settings based
on your needs. Setting the detection to “Medium” or “High” results in false positives or too many alerts.
81 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
Intrusion Prevention System (IPS)
The Intrusion Prevention System (IPS) is the second security function built into the IAP. The IPS determines the
measures that must be taken to mitigate the security breaches that are identified on the Aruba Instant network.
IPS Wizard
The WIP wizard that is shown Security Design provides the options to enable, define, and change these items:
l
Protection options for infrastructure attacks
l
Protection options for WLAN clients attacks
Figure 38 Protection settings of the WIP wizard
The protection setting on the WIP wizard for the infrastructure and the client can be turned off or set to a predefined
high or low level. The WIP wizard also allows custom settings. The high setting enables all applicable protection
mechanisms, and the low setting enables only the most critical protection mechanisms.
Security requirements are specific to each organization. To enable rogue AP containment, you can set the slider bar
under Infrastructure to “Low” or you can enable “rogue-containment” using the custom settings.
Under Advanced Options, these two containment methods are available:
l
Wired containment: When enabled, IAPs generate ARP packets on the wired network to contain wireless
attacks. These ARP packets poison rogue devices.
l
Wireless containment: When enabled, Aruba Instant attempts to disconnect all clients that are connected or
that are attempting to connect to an identified AP. Two wireless containment mechanisms are supported:
n
Deauthentication containment: The AP or client is contained by disrupting the client association on the
wireless interface.
n
Tarpit containment: The AP is contained by luring clients that are attempting to associate with it to a tarpit.
The tarpit can be on the same channel or a different channel as the AP that is being contained.
Aruba Instant Validated Reference Design
Designing Enterprise Networks with Aruba Instant | 82
For containment, you do not need to have a dedicated AM. An IAP that functions in access mode can contain
rogue devices. For wireless containment with an IAP that functions in access mode, the preferred method is tarpit
containment. Deauthentication containment works more effectively for AMs. Wired containment with ARP
poisoning is also effective for wireless clients and works for both AMs and IAPs that functions in access mode.
Aruba IPS Recommendations
Consult an RF security expert and your legal department to determine the security needs and legal implications
before enabling containment.
Aruba recommends this WIP wizard setting for protection:
Enable all critical attacks that are defined in the lowest setting and then customize them to meet the needs of your
network. If you enable all WIP protection features, too many alarms can interfere with the performance of your
network and neighboring WLANs.
83 | Designing Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
Chapter 4
Designing Distributed Enterprise Networks with Aruba Instant
You can broadly classify distributed enterprise deployments into branch office deployments and home office
deployments, both of which differ in design and requirements. This chapter describes in detail how you can use
Aruba Instant to design a branch office deployment and a home office deployment.
Branch Office Deployments
A branch office is a location other than the main office, where business is conducted. The term, ‘branch’ means
different things to different organizations. For a retail chain, the term, ‘branch’ represents all the stores that serve
customers, whereas for a traditional hi-tech enterprise, a branch represents an offsite location where employees and
contractors come to accomplish day-to-day work.
Though the use cases and requirements of branch office networks vary across organizations, the key goal of any
branch office network is to support some or all of the below mentioned tasks:
l
Provide secure employee access
l
Provide guest access
l
Support different applications types such as voice and video
l
Support different device types, from mobile devices to printers, kiosks, and security cameras
l
Comply with standards such as PCI, HIPPA, CALEA, and so on
l
Secure sensitive data
l
Provide high availability
In terms of user and device density, branch office deployments are usually small and can be supported with a few
APs. A key requirement that influences the design of a distributed enterprise is the need to secure sensitive
corporate data that traverses the link between the remote site and the data center. To securely interconnect
branches, organizations have multiple WAN options such as leased lines, MPLS networks, and VPN over public
internet. Connecting branches using leased lines is expensive and it does not justify the cost when compared to
other technologies. Common choices for organizations to interconnect their branches are MPLS networks and VPN
over Internet broadband services, such as DSL, 3G/4G, and cable services.
Though MPLS is a form of VPN, the term VPN in this document refers to the WAN that is created by using
encrypted tunnels over the public internet.
The decision to use VPN versus MPLS for branch connectivity is based on factors such as cost, security policies,
and service availability. To simplify the design discussion, this chapter describes branch office deployments in the
following categories:
l
MPLS-based branch deployments
l
VPN-based branch deployments
The physical design of a branch network, with Aruba Instant is often influenced by the number of IAPs that are
required to support a branch. Depending on the user and device density, and the size of the branch, the number of
IAPs that are required to support a branch office might vary from a single AP to a few IAPs. Typically, any branch
that requires more than 20 IAPs often falls in the realm of small enterprises. This section describes branch office
deployments of 20 or fewer IAPs. You can classify the physical design options that are available with Aruba Instant
for branch office networks as follows:
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 84
l
Single-AP branches
l
Multi-AP branch
Single AP Branch
Single-AP branches are those that are supported by a single AP. These are branches with 30 or less wireless users
and a few wired devices. Examples of a single-AP branch include home offices, home-based call centers, small
retail stores of a coffee or restaurant chain, mobile clinics, offsite offices of law firms, realty groups, and so on.
In addition to wireless access, some single-AP deployments require support for a few wired devices. Therefore, IAP
models with extra wired ports are ideal for these deployments because they simplify the network design and
eliminate the need for additional switching equipment. Select an IAP model based on whether a branch requires
wireless only or wired and wireless access and consider factors such as wireless performance, AP mounting
(ceiling, wall, or table mount), wired port requirements, and uplink type (Ethernet uplink or 3G/4G USB modem). For
information about the available IAP models, see Aruba Instant.
Branch Office Deployments shows a typical single-AP deployment. In a single-AP deployment, the IAP serves both
the wireless and wired clients. The uplink Ethernet port of the IAP is directly plugged into the WAN uplink,
eliminating the need for additional networking infrastructure at the branch.
Figure 39 Typical single-AP deployment
With Aruba Instant, you can choose between multiple uplinks. Aruba Instant supports Ethernet-based WAN uplinks,
3G/4G uplinks, and Wi-Fi uplinks. Being able to choose from multiple uplinks in a single AP deployment allows you
to select the appropriate uplink based on service availability and lets you set up uplink redundancy. For more
information about Aruba Instant uplinks, see the Aruba Instant User Guide that is available at the Aruba support
website.
You can apply a single-AP design to both MPLS and VPN-based branch deployments.
Multi AP Branch
Branches that require more than a single AP to support the end users and devices are considered multi-AP branches.
The number of IAPs that are required by a multi-AP branch depends on the size of the branch, and the user, and
device density. Aruba Instant provides the following physical design options for multi-AP branches:
l
Hierarchical mode design
85 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
l
Flat mode design
Whether you select one option over the other is related to the number of IAPs that are required to support the branch.
Hierarchical Mode Design
Some multi-AP branches are small enough to be covered by four or fewer APs and to be deployed in hierarchical
mode or flat mode. In hierarchical mode, you can use the downlink ports of a multi-port IAP that is connected to the
WAN uplink as an uplink for other IAPs and wired devices in order to extend the network. The IAP that is connected
to the WAN uplink (called the root IAP) functions as the wired device for the network, provides DHCP services, and
provides a Layer 3 connection to the ISP WAN uplink with NAT. The root IAP is always the master of the Aruba
Instant network. The downlink port of the root IAP that connects to other IAPs can be a trunk or an access port that
is configured with a VLAN in local mode without authentication. The local mode VLAN functions as the AP VLAN for
the members IAPs that are connected to the root IAP of the hierarchical mode design. For information about local
mode, see Instant-VPN: Local Mode.
Only one IAP (the root IAP) in the network uses its downlink port to connect to the other IAPs. That is, IAPs in
hierarchical mode should not be deployed in a daisy chain fashion.
For hierarchical mode, the IAP that connects to the branch uplink must be a multi-port IAP like RAP-155. Aruba does
not recommend using hierarchical mode for multi-AP branches that require five or more IAPs. Hierarchical mode is
useful if a managed uplink switch is not available. In hierarchical mode, you can configure the uplink IAP for uplink
redundancy with alternate uplinks such as a secondary Ethernet uplink or a 3G/4G uplink.
If a managed uplink switch is available, Aruba recommends that you deploy the IAPs in flat mode.
In general, hierarchical mode design is more applicable to VPN-based branch deployments than to MPLS-based
deployments. MPLS-based deployments have either a single-AP design or a multi-AP design in flat mode. A typical
hierarchical deployment consists of the following components:
l
A direct wired WAN ISP connection or a 3G/4G uplink to the root IAP.
l
One or more DHCP pools for member IAPs (that is, one or more AP VLANs for member IAPs) and wired and
wireless user VLANs.
l
One or more downlink ports that are configured on a private VLAN (in local mode) without authentication to
connect to member IAPs. Note the following guidelines for downlink ports:
n
If the AP VLAN and wireless user VLANs are different, which is true for many deployments, the downlink port
of the root IAP to which the member IAPs connect must be a trunk port with the AP VLAN as the native
VLAN.
n
You can configure additional downlink ports of the root IAP with an appropriate VLAN and authentication for
wired clients.
n
Ensure that the downlink port that is configured for IAP access is not used for any wired client connection.
Branch Office Deployments and Branch Office Deployments are examples of the hierarchical mode design.
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 86
Figure 40 Hierarchical mode design with IAPs
Figure 41 Hierarchical mode design with IAPs and an unmanaged switch
Flat Mode Design
Flat mode design is a default deployment model for a multi-IAP network. This mode is recommended for all branch
networks that require five or more IAPs. In this mode, all IAPs that support a branch are plugged into an uplink
switch. This physical network design is the same as the design that is used in small and medium enterprises. If the
IAP must support multiple VLANs or if the client VLAN and the AP VLAN are separate, the IAPs must be trunked to
an uplink switch that is VLAN-aware. That is, if the Aruba Instant cluster is required to support multiple VLANs, the
uplink switch must be a managed switch. For example, if the AP VLAN is VLAN 10, the employee VLAN is VLAN
20, and the guest VLAN is VLAN 30, the IAP should be trunked to the uplink switch with native VLAN 10 and tagged
VLANs 20 and 30.
No encapsulation tunnels exist between IAPs in an Aruba Instant cluster. The traffic that is generated by the IAPs
and clients in a cluster is forwarded on the respective AP and client VLANs.
87 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
Flat mode design is applicable to both MPLS-based and VPN-based branch deployments.
Branch Office Deployments shows an example of a flat mode design.
Figure 42 Flat mode design
The logical network design options that are available with Aruba Instant vary for MPLS-based branch deployments
and VPN-based branch deployments and are described in the following sections.
MPLS-Based Branch Deployments with Aruba Instant
MPLS is popular in distributed enterprises such as healthcare that have several critical latency-sensitive
applications. Some key benefits of MPLS are high-availability, security, guaranteed SLAs, and QoS. When
organizations use an MPLS backhaul for branch connectivity, the MPLS backbone is provided by a service provider.
In these deployments, the MPLS service provider is also responsible for securing the customer data traversing the
MPLS network, handling the complex WAN routing issues, and honoring the SLAs, QoS, and high-availability
requirements of the WAN.
Depending on the size of the branch, the physical design of the Aruba Instant network in an MPLS-based branch
deployment can either be a single-AP design or a multi-AP design in flat mode.
Aruba Instant supports VPN functionality. However, VPN functionality is not required in an MPLS-based deployment
because data security over the WAN is handled by the MPLS provider. Therefore, the logic design of an Aruba
Instant network in an MPLS-based branch deployment differs from that of a VPN-based branch deployment. A
typical branch office network that connects to the MPLS backbone has the following network components:
l
Network access devices: Network access devices include WLAN system and switches that provide network
access to IAPs and end-user devices.
l
Customer edge router: The customer edge (CE) router is the router that interfaces with the provider edge (PE)
router. The provider edge router is an interface between the MPLS-based backhaul and the customer branch
network. The CE router at each branch injects the branch routes to the PE router using protocols such as Open
Shortest Path First (OSPF). The PE router connects to the MPLS core of the provider (P) routers and other PE
routers and interconnects the branch networks.
l
Network services: Depending on the type and size of the branch, network services such as DHCP, DNS, and
RADIUS are localized to the branch or centralized at a data center.
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 88
In MPLS-based deployments, the branches are served by a dedicated local or centralized DHCP server and the
Aruba Instant network need not provide any DHCP services. The main function of the Aruba Instant WLAN system
in these types of branches is to provide secure client access and forward the appropriate traffic to the uplink network.
The following use cases describe the most common logical design options for MPLS-based branch deployments.
Use Case 1: Wireless Employee Access and Guest Access
This is a typical use case in MPLS-based branch deployments in which the WLAN system is required to provide
employee and guest access, and forward traffic on the appropriate VLAN to an uplink managed switch.
The following requirements and components are common in this type of design:
l
Dedicated VLAN for employee access (with WPA2 security)
l
Role-based access and BYOD for employees
l
Dedicated VLAN for guests
l
Captive portal for guest authentication and authorization
l
Centralized or local DHCP and RADIUS services (a WLAN system is not required to provide DHCP services)
l
IAPs on a dedicated AP VLAN
l
Uplink managed switch for IAPs and wired clients
l
CE router to interface with the MPLS backbone
The Aruba Instant solution for this type of requirement is as follows:
l
Employee SSID with appropriate authentication (WPA2-Enterprise) that is mapped to the employee VLAN. After
enforcing the appropriate firewall policies, the IAPs bridge the employee traffic to the employee VLAN on the
uplink switch.
l
Role based access and BYOD for employees on the employee SSID. For more information about role-based
access and BYOD on an Aruba Instant network, see the Aruba Instant User Guide that is available at the Aruba
support website.
l
Guest SSID that is mapped to the appropriate VLAN and captive portal authentication. (This applies only to
environments that require guest access) Guests can be supported with the internal captive portal page and guest
management features that are supported by Aruba Instant or a centralized ClearPass server. For information
about guest access, see the Aruba Instant User Guide available at the Aruba support website. After enforcing the
appropriate firewall policies, the IAPs bridge the guest traffic to the guest VLAN on the uplink switch.
l
As an option, dynamic RADIUS proxy in environments in which adding all IAPs as NAS clients to a RADIUS
server is not feasible. For more information about dynamic RADIUS proxy, see Dynamic RADIUS Proxy.
l
Uplink switch and CE router for traffic engineering.
Use Case 2: Wireless Employee Access and Guest Access with the Ability to Tunnel the
Guest Traffic to a Central DMZ
Use case 2 is common if the security policy of an organization requires that all the guest traffic from branches is
handled at a central Demilitarized Zone (DMZ). These requirements and components are common in this type of
design:
l
Employee Access (WPA2 security) with a dedicated VLAN
l
Role-based access and BYOD for employees
l
Guest access on a dedicated VLAN.
l
Captive portal for guess access with a central captive portal server
l
Tunneling of all guest traffic to a DMZ for centralized handling of guest traffic
89 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
l
Dedicated centralized or local DHCP and RADIUS services for employee access
l
Central DHCP service for guest access
l
IAPs on a dedicated AP VLAN
l
Uplink managed switch for IAPs and wired clients
l
CE router to interface with the MPLS backbone
The typical Aruba Instant solution for this type of requirement is as follows:
l
Employee SSID with appropriate authentication (WPA2-Enterprise) that is mapped to the employee VLAN. After
enforcing the appropriate firewall policies, the IAPs bridge the employee traffic to the employee VLAN on the
uplink switch. For example, if all employee traffic on the employee SSID must be forwarded to employee VLAN
20 on the uplink switch, the employee SSID must be mapped to VLAN 20.
l
Role-based access and BYOD for employees on the employee SSID. For more information about role-based
access and BYOD on an Aruba Instant network, see the Aruba Instant User Guide that is available at the Aruba
support website.
l
Uplink switch and CE router for traffic engineering of employee traffic.
l
As an option, dynamic RADIUS proxy in environments in which adding all IAPs as NAS clients to a RADIUS
server is not feasible. For more information about dynamic RADIUS proxy, see Dynamic RADIUS Proxy.
l
Guest SSID with captive portal authentication to tunnel the guest traffic to an Aruba controller in the DMZ, using
the following Generic Routing Encapsulation (GRE) capabilities on Aruba Instant:
n
To tunnel guest traffic using GRE, the guest SSID must be configured with a VLAN in centralized Layer 2
mode and the Aruba Instant cluster must be configured for GRE. For more information about centralized Layer
2 mode, see Instant-VPN: Centralized L2 Mode.
n
Aruba Instant supports either Auto-GRE with Aruba controllers or a manual GRE configuration with Aruba
controllers and other GRE endpoints. Aruba recommends Auto-GRE because it simplifies the network design
by eliminating manual configuration of GRE tunnels for each branch or each individual IAP.
n
Aruba Instant supports either per-AP GRE tunnels or single GRE tunnels (that is, a setup from the master AP
of the cluster) for an Aruba Instant cluster. For information about GRE in Aruba Instant, see Appendix B: GRE
with Aruba Instant. n
If you configure a single GRE for an Aruba Instant cluster, the GRE tunnel is initiated by the master AP of that
cluster. If you use a multi-AP flat mode design with a single GRE tunnel, the guest traffic from the member
IAPs must first reach the master AP before it is tunneled to the DMZ controller. The uplink switch that
connects the IAPs must support the guest VLAN because the guest traffic from the member IAPs to the
master AP is forwarded on the guest VLAN.
n
If a per-IAP GRE tunnel is enabled, each IAP in a cluster forms a GRE tunnel to the DMZ controller and the
uplink switch that connects the IAPs does not need to support the guest VLAN. The IAP to which the guest is
connected tunnels the guest traffic directly to the DMZ controller.
n
All guest traffic can be tunneled to the DMZ controller using a routing profile of “0.0.0.0 0.0.0.0 <GRE tunnel IP
address of the DMZ controller>”. For more information about routing profiles, see Configuring a Routing
Profile.
The routing profile also affects any traffic that is generated by the IAP such as RADIUS and Syslog traffic.
Creating a routing profile of “0.0.0.0 0.0.0.0 <GRE tunnel IP address of the DMZ controller>” allows the
RADIUS traffic for employees to be forwarded through the tunnel. However, in certain deployments, it is not
necessary. Any traffic that should not be tunneled to the DMZ controller must be added to the routing profile
with the gateway IP address field set to 0.0.0.0.
For example, if traffic to the RADIUS server with IP address 10.10.10.10 and the Syslog server with IP
address 10.10.10.11 must be forwarded outside the tunnel by using the gateway of the IAP, the below entries
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 90
should be added to the routing profile:
10.10.10.10 255.255.255.255 0.0.0.0
10.10.10.11 255.255.255.255 0.0.0.0
This will ensure that the traffic to these destinations is forwarded through the default gateway of the IAP and
not through the GRE tunnel. Aruba InstantOS 4.x and greater is required for this configuration.
Since employee traffic is on the branch VLAN that is managed by the uplink infrastructure and not by the IAP,
the routing profile does not affect the employee traffic.
VPN-Based Branch Deployments with Aruba Instant
Connecting branches using MPLS has its advantages but is not the best option for some branch office deployments
because of cost and service availability. With cost savings being a key driver in the adoption of distributed enterprise
strategy, organizations seek a more affordable alternative to MPLS. Internet broadband service with better service
availability and affordability provide an attractive alternative to an MPLS-based WAN. Over the years, both the
consumer grade and business grade broadband services have become faster, more reliable, and more affordable.
Many organizations prefer switching to a broadband service for branch and home office connectivity. Especially for
organizations that support home-based employees, broadband is the only choice because connecting home offices
with an MPLS-based WAN is not a viable solution.
Data security over the WAN which is handled by the service provider in an MPLS-based deployment, is the
responsibility of the corporate IT team when a public Internet is used for branch connectivity. The most common
VPN technologies that provide secure remote access are SSL VPN and IPsec VPN. SSL VPN is suited to provide
remote access to a specific application but is not suitable for connecting networks. Therefore, IPsec VPN is the
most common choice for securely extending corporate networks and resources to remote sites. IPsec VPN protects
sensitive data by interconnecting the remote sites with secure encryption tunnels over the Internet.
Traditional implementation of IPsec VPN was site-to-site. Implementing IPsec VPN requires IPsec-capable
hardware at the remote site and involves complex configurations. Most branch sites have limited or no IT staff
onsite, so interconnecting branches using IPsec VPN can be a challenge.
Complexity is one of the main issues that is associated with the classic site-to-site VPN. To deploy a site-to-site
IPsec VPN, organizations configure and ship a branch router or VPN gateway to each location. To create a site-tosite VPN, the following tasks are involved:
l
Configuring the IPsec tunnel parameters, including the key management protocol (IKEv1 or IKEv2), security
protocol (AH or ESP), IPsec encapsulation mode (tunnel mode or transport mode), encryption key, encryption
algorithm (DES, 3DES, or AES), authentication key or certificates, and authentication algorithm (SHA or MD5)
l
Configuring a routing protocol such as OSPF between the data center and remote branches
l
Configuring a GRE tunnel within the IPsec tunnel to carry the multicast advertisements of routing protocols
In other words, the complexity and cost involved in deploying and managing a classic site-to-site IPsec VPN is a
challenge to IT departments.
Aruba Instant is designed to solve the complexity that is associated with site-to-site IPSec VPN. With the Aruba
Instant built-in VPN capabilities and zero-touch provisioning, VPN deployments are easy. The zero-touch
provisioning capability of Aruba Instant reduces deployment costs and eliminates the complexity that is associated
with traditional IPsec VPN deployments.
91 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
Understanding Instant-VPN (Aruba Instant-VPN in a Nutshell)
This section describes how you can design a branch with Instant-VPN and what the different modes of operation are.
The Aruba Instant-VPN solution has three components:
l
Aruba IAPs at the branch sites
l
Aruba WLAN controller at the data center
l
AirWave and Aruba Central
The master AP (that is, the VC) at the branch functions as the VPN endpoint and the Aruba WLAN controller at the
data center functions as the VPN concentrator. If an Aruba Instant cluster is configured for VPN, the master AP of
the cluster establishes an IPsec tunnel (using IKEv2) with the WLAN controller to secure the sensitive corporate
data. The IPsec authentication and authorization between the WLAN controller and the IAP is based on TPM-based
Aruba certificates and the RAP whitelist in ArubaOS.
Only the master AP in an IAP cluster can establish a VPN tunnel.
From an Aruba WLAN controller perspective, the master AP that establishes the VPN tunnel is considered a VPN
client and not an AP. Therefore, the traditional AP count of a WLAN controller platform does not apply to this
architecture. Instead, the WLAN controller scalability in the Aruba Instant-VPN architecture depends on factors such
as the IPsec tunnel limit and routing table limit. Since the WLAN controller does not count the master AP as an AP,
controller licenses such as the AP capacity license, per-AP PEFNG license, and RFProtect license do not apply to
this architecture.
The function of the WLAN controller in the Aruba Instant-VPN architecture is to terminate VPN tunnels and route or
switch VPN traffic. The WLAN controller is not responsible for configuring, managing, reporting, or monitoring the
IAP networks in remote branches. Instead, these responsibilities are handled by AirWave or Aruba Central. Aruba
Instant uses a distributed architecture, so features and functions such as role-based access control, bandwidth
contracts, ARM, WIPS, mobility, and Application Level Gateways (ALGs) are local to the Aruba Instant network at
the branch and are not the responsibility of the WLAN controller.
Licensing
The WLAN controller considers the master AP that establishes a VPN tunnel a VPN client and not an AP, so
licenses such as the AP capacity license, per-AP PEFNG license, and RFProtect license are not required. When an
IPsec connection is established between the WLAN controller and an IAP, each end of the IPsec tunnel has two IPs
addresses: an inner IP address and an outer IP address. By default, the WLAN controller assigns these two roles to
the inner and outer IP addresses of an IAP that terminates its VPN tunnel on the WLAN controller:
l
Outer IP address: logon role
l
Inner IP address: default VPN role with an “allow all” access control list (ACL)
Although you do not need licenses to terminate an IAP-VPN tunnel on the WLAN controller, you need a PEFV
license in one of the following scenarios:
l
Changing the ACLs in the default VPN role: In this scenario, you need a PEFV license for each WLAN
controller. A common reason to change the ACL is to limit the number of RADIUS client entries in the RADIUS
server. For instance, an organization with 100 branches an 10 IAPs per branch should add all IP addresses that
are used as inner IP addresses for IAP VPN tunnels (that is, the IP addresses that are defined as the VPN
address pool on the WLAN controller) as RADIUS clients to allow 802.1X authentication with the RADIUS server
in the data center. Alternatively, you can modify the default VPN role to include a rule that source NATs all
RADIUS traffic to the IP address of the WLAN controller. With such a source NAT rule, you only need to add the
WLAN controller as a RADIUS client on the RADIUS server.
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 92
l
Changing the role that is applied to the inner IP address and the ACLs within that role: In this scenario,
you need a PEFV license for the WLAN controller.
Aruba Instant-VPN License Requirements summarizes the licensing requirement.
Table 12: Aruba Instant-VPN License Requirements
Licenses
Features
Base
ArubaOS (no
licenses)
IAP can terminate a VPN tunnel and pass VPN traffic.
Roles and policies are not editable.
ArubaOS
with a PEFV
license
(PEFV is a
per-unit
license)
IAP can terminate a VPN tunnel and pass VPN traffic.
The default role in the default IAP VPN authentication profile of a WLAN controller can be edited and a
new user role with custom firewall policies can be applied to the default IAP VPN authentication
profile.
WLAN Controller Scalability for Instant-VPN deployments
The number of Instant-VPN branches that can be supported on a WLAN controller depends on the WLAN controller
model. Choose an appropriate controller model based on the size of your deployment. Instant-VPN scalability for
different Aruba WLAN controller models shows the Instant-VPN scalability for different Aruba WLAN controller
models.
Table 13: Instant-VPN scalability for different Aruba WLAN controller models
Controller
Maximum recommended IAP VPN branches
7240
8192
7220
4096
7210
2048
7205
1024
7030
256
7024
128 (Upcoming)
7010
128
7005
64
M3
2048
3600
512
3400
256
3200-XM
128
93 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
AP Selection for Instant-VPN Deployments
An Aruba Instant network that is configured for Instant-VPN establishes a single IPsec tunnel from the master AP of
the cluster to the WLAN controller. Therefore, it is important to choose the right IAP for your deployment. Although all
IAP models have gigabit uplink ports, the IPsec throughput for each IAP model varies. IAP Models and IPsec
Throughput shows the IPsec throughput for different IAP models.
Table 14: IAP Models and IPsec Throughput
IAP Model
IPsec Throughput (in Mb/s)
IAP-225
150
IAP-224
150
IAP-135
40
IAP-134
40
IAP-105
15
IAP-104
15
RAP -155
80
RAP -109
20
RAP -108
20
RAP-3
20
IAP-175
15
IAP-92
10
IAP-93
10
Firewall Ports
Instant-VPNs connect to the WLAN controller on UDP port 4500 for establishing the IPsec connection. UDP port
4500 must be open on all firewalls that lead up to the WLAN controllers in the DMZ.
Understanding Instant-VPN Modes
The classic RAP architecture has four forwarding modes: tunnel, split-tunnel, decrypt-tunnel, and bridge mode.
These forwarding modes control how user traffic is handled, including where decryption occurs and where role-based
firewall policies are applied. The ability to forward user traffic to corporate and local destinations also depends on the
selected forwarding mode. In tunnel, decrypt-tunnel, and split-tunnel modes, the classic RAP architecture extends
the corporate VLAN to the remote location, that is, the broadcast domain is extended to the branches. The default
gateway resides in the data center for the clients that connect to an SSID or wired port operating in one of these
modes. For clients that connect to a bridge-mode network, the default gateway is the RAP but corporate access is
not available. Forwarding Modes for Classic RAPs provides an overview of the capabilities of the different
forwarding modes that are available for classic RAPs. For more information about the forwarding modes of classic
RAPs, see the Aruba Remote Access Points (RAP) Validated Reference Design.
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 94
Table 15: Forwarding Modes for Classic RAPs
Forwarding
Mode
Firewall
Processing
Traffic Engineering
Site Survivability
Tunnel
802.11
encryption
and
decryption
and firewall
processing
occur on the
WLAN
controller.
User traffic is forwarded to the WLAN
controller through the IPsec tunnel.
Traffic cannot be bridged to a local
destination.
WAN-dependent. If the connection to the
WLAN controller is lost, the SSIDs and
wired ports operating in this mode are shut
down.
Decrypt
tunnel
802.11
encryption
and
decryption
occur at the
AP, but
firewall
processing
occurs on the
WLAN
controller.
User traffic is forwarded to the WLAN
controller through the IPsec tunnel.
Traffic cannot be bridged to a local
destination
WAN-dependent. If the connection to the
WLAN controller is lost, the SSIDs and
wired ports operating in this mode are shut
down.
Split-tunnel
802.11
encryption
and
decryption
and firewall
processing
occur at the
AP.
With appropriate firewall policies, the
user traffic that is destined to
corporate servers can be forwarded
to the WLAN controller through the
IPsec tunnel. The traffic to local and
Internet destinations can be source
NATed by APs to the local network.
WAN-dependent. If the connection to the
WLAN controller is lost, the SSIDs and
wired ports operating in this mode are shut
down.
Bridge
802.11
encryption
and
decryption
and firewall
processing
occur at the
AP.
User traffic is bridged and
source NATed to local destinations.
Traffic cannot be forwarded to the
WLAN controller through the IPsec
tunnel.
Varies based on the operation mode.
Bridge-forwarding mode has four operation
modes (standard, always, persistent, and
backup). For more information about these
operation modes and their capabilities, see
the Aruba Remote Access Points (RAP)
Validated Reference Design .
Do not confuse the classic RAP solution with AP part numbers that start with a RAP prefix (that is, RAP-3, RAP109, and RAP-155). All latest APs with part numbers that start with a RAP prefix can operate in either the classic
RAP mode or the Instant-VPN mode. The RAP part number indicates that the AP is designed for table mount.
95 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
The Instant-VPN architecture differs from the classic RAP architecture in the following ways:
l
The 802.11 encryption and decryption and firewall processing in an Instant-VPN always occur at the IAP in the
branch.
l
Traffic forwarding behavior in an Instant-VPN is similar to that of split-tunnel mode in a classic RAP solution.
User traffic can be forwarded through the IPsec tunnel or bridged locally, based on the destination. If required,
traffic to any destination can be forwarded through the IPsec tunnel or bridged locally. (These options are
comparable to the traffic engineering behavior of tunnel, decrypt-tunnel, and bridge forwarding modes in a classic
a RAP solution).
l
The Instant-VPN architecture has five modes of operation. These modes do not determine how firewall
processing and traffic forwarding occur. Rather, they define whether a branch is a Layer 2 extension, Layer 3
extension, or independent, that is, these modes determine whether the DHCP server and default gateway for
clients reside at the branch or at the data center.
The following modes are available in the Instant-VPN architecture:
l
n
Local mode
n
Centralized L2 mode
n
Distributed L2 mode
n
Distributed L3 mode
n
Centralized L3 mode
Aruba Instant architecture provides site survivability in all modes of operation.
Aruba recommends Centralized L2 & Distributed L3 modes of operation, as they are a better fit for deployments &
traffic engineering objectives.CL3 and DL2 are meant for specialized use cases where there is a need achieved
centralized DHCP, with a routed network and Distributed DHCP with centralized forwarding and are not
discussed in detail, as they are not common use cases. Hence, these modes will not be explained or mentioned in
future sections.
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 96
The table below, summarizes the key features of the different modes in the Instant-VPN architecture.
Table 16: Instant-VPN Modes
InstantVPN
Mode
Firewall
processing
Traffic
Engineering
Site Survivability
Branch Subnet
Local
Mode
802.11 encryption
and decryption
and firewall
processing occur
on the IAP in the
branch.
User traffic can be
forwarded through
the IPsec tunnel or
bridged locally,
based on the
destination.
Supported. (The IAP
authentication
survivability feature even
provides 802.1X
survivability when the
WAN is down.)
The branch subnet is
independent (that is, the
subnet is local to the branch,
similar to a home network
but with VPN capabilities.)
Centralized
L2
802.11 encryption
and decryption
and firewall
processing occur
on the IAP in the
branch.
User traffic can be
forwarded through
the IPsec tunnel or
bridged locally,
based on the
destination.
Supported. (The IAP
authentication
survivability feature even
provides 802.1X
survivability when the
WAN is down.)
The branch is a
Layer 2 extension.
Distributed
L3
802.11 encryption
and decryption
and firewall
processing occur
on the IAP in the
branch.
User traffic can be
forwarded through
the IPsec tunnel or
bridged locally,
based on the
destination.
Supported. (The IAP
authentication
survivability feature even
provides 802.1X
survivability when the
WAN is down.)
The branch is a
Layer 3 extension.
Instant-VPN: Local Mode
Local mode is similar to the local network of a home wireless router but with VPN capabilities and other enterprise
grade features. In this mode, the IAP cluster at the branch has a local subnet (for example, 192.168.200.0 /24) and
the master AP of the cluster functions as the DHCP server and gateway for clients. The local mode provides VPN
capabilities using the inner IP address of the Instant-VPN IPsec tunnel.
Client traffic that must be forwarded to the corporate destinations is source NATed by the master AP using the inner
IP address of the IPsec tunnel. Traffic that is destined for the Internet or local destinations is source NATed using
the local IP address of the master AP. It is essential that the IP addresses that are defined in the VPN address pool
of the WLAN controller (which is used for inner IP addresses of IPsec tunnels) are routable from the upstream router
in the data center. If required, all client traffic can be forwarded through the IPsec tunnel or bridged locally. For
information about VPN address pools, see Defining the VPN Pool on a WLAN Controller.
In local mode, clients in the branch can initiate connections to a server in the data center but the connections cannot
be initiated from the data center to remote clients. (This behavior is similar to that of a NAT device). The WLAN
controller and the upstream routers have no visibility or direct route to the branch subnet. Therefore, you cannot
initiate connections from the data center to remote clients for troubleshooting. The local mode is well suited for
branch guest networks that use a captive portal sever in the data center for guest authentication.
97 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
Below figure shows the traffic flow in local mode.
Figure 43 Packet flow in Instant-VPN local mode
To summarize, the key features of the Instant-VPN local mode are as follows:
l
The master AP in the IAP cluster is the DHCP server for clients.
l
The master AP in the IAP cluster is the default gateway for clients.
l
Traffic to the data center is source NATed with the inner IP address of the IPsec tunnel.
l
Traffic to the Internet or a local destination is source NATed with the local IP address of the master AP in the IAP
cluster.
l
The VPN pool for inner IP addresses of the IPsec tunnel must be routable from the upstream router of the WLAN
controller in the data center.
l
Traffic can be initiated from the branch to the data center, but traffic cannot be initiated from the data center to the
branch.
For an example of a local mode configuration, see Configuring an IAP for Instant-VPN Deployment.
Instant-VPN: Centralized L2 Mode
Centralized L2 mode is analogous to the L2 extension in a classic RAP solution. This mode extends the corporate
VLAN and the broadcast domain to remote branches. The DHCP server and the gateway for the clients reside in the
data center. Either the WLAN controller or an upstream router can be the gateway for the clients. For DHCP services
in centralized L2 mode, Aruba recommends that you use an external DHCP server and not the DHCP server on the
WLAN controller.
Client traffic that is destined for data center resources is forwarded by the master AP through the IPsec tunnel to the
default gateway of the client in the data center. Any traffic that is destined for the Internet or a local destination is
source NATed using the local IP address of the master AP and bridged locally. If required, all client traffic can be
forwarded through the IPsec tunnel or bridged locally. An easier configuration method to, send all client traffic over
IPsec tunnel is introduced, called “Split tunnel mode->disable”.
In centralized L2 mode, you can initiate a connection from the data center to remote clients for troubleshooting.
If the RADIUS traffic is not source NATed at the WLAN controller, you must make the VPN pool for inner IP
addresses routable for RFC 3576-compliance and 802.1X. A routable VPN address pool also allows access to the
local WebUI of the Aruba Instant cluster from the data center. For information about VPN address pools, see
Defining the VPN Pool on a WLAN Controller.
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 98
By default, the ARP messages of a client for its gateway are forwarded to the data center through the IPsec
tunnel. However, if the WAN is down, the master AP of the cluster does proxy ARP for the default gateway in the
data center.
The centralized L2 mode extends the corporate VLAN to remote branches, enabling broadcast and multicast traffic
to traverse the WAN between the branch and data center. However, in centralized L2 mode, broadcast and multicast
traffic might saturate the WAN link. Therefore, when you deploy a branch in centralized L2 mode, Aruba
recommends that you use smaller subnets for user VLANs. For example, use a /24 or /23 network for a user VLAN
instead of a /16 network that spans several thousand branches. If an organization with 1000 branches and a
maximum of 50 clients per branch has a mandate to extend the data center VLAN to remote branches, Aruba
recommends grouping the branches as follows:
l
5 branches per group, with each group sharing a /24 user VLAN, resulting in 200 groups
l
10 branches per group, with each group sharing a /23 user VLAN, resulting in 100 groups
Grouping the branches into smaller subsets increases the number VLANs and the number of groups and folders in
AirWave but minimizes WAN bandwidth consumption.
Aruba recommends the centralized L2 mode only if Layer 2 extension is mandatory for branches. The mode is well
suited for organizations that stream multicast videos to remote branches. Below Understanding Instant-VPN (Aruba
Instant-VPN in a Nutshell) shows the traffic flow in centralized L2 mode.
Distributed L3 mode is the recommended mode of operation for Instant-VPN networks. Use centralized L2 mode
only for organizations that mandate extension of corporate VLANs to branch networks.
Figure 44 Packet flow in instant-VPN centralized L2 mode
You can summarize the key features of the Instant-VPN centralized L2 mode as follows:
99 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
l
The DHCP server for the clients is in the data center.
l
The default gateway for the clients is in the data center.
l
ARP messages for the default gateway are forwarded to the data center, except if the WAN is down.
l
If the WAN is down, the master AP of the cluster does proxy ARP for the gateway of the client.
l
Traffic to the data center is forwarded to the default gateway of the client through the IPsec tunnel.
l
Traffic to the Internet or a local destination is source NATed with the local IP address of the master AP.
l
The split tunnel feature is enabled by default. If the split tunnel feature is disabled, then irrespective of any
configuration under the routing profile, all client traffic, for this VLAN, is sent to the data center over the IPSec
tunnel. This feature was introduced as a centralized L2 mode. This feature is useful when all traffic should be
tunneled over the IPSec tunnel to the data center and no traffic should be split tunneled and source NATed over
VC IP. This feature was introduced to achieve this easily for a particular VLAN.
l
Configuring a routable VPN address pool which is used for inner IP addresses of the IPsec tunnel, allows access
to the local WebUI of the Aruba Instant cluster from the data center.
l
If RADIUS traffic is not source NATed at the WLAN controller, configuring a routable VPN address pool is also
essential for 802.1X. To support RFC-3576, the RADIUS traffic must not be source NATed at the WLAN
controller and a routable VPN address pool is required.
l
Aruba recommends that you use small VLAN subnets as user VLANs to reduce the broadcast and multicast
traffic across the WAN.
Instant-VPN: Distributed L3 Mode
Aruba recommends distributed L3 mode for organizations that do not require Layer 2 extensions. Distributed L3
mode contains all broadcast and multicast traffic to a branch and eliminates any WAN bandwidth consumption
challenges that are associated with classic RAPs and Instant-VPN L2 modes. Distributed L3 mode reduces the cost
and eliminates the complexity that is associated with the classic site-to-site VPN. However, in terms of
functionality, distributed L3 mode is very similar to a classic site-to-site IPsec VPN in which two VPN endpoints
connect individual networks over a public network.
In distributed L3 mode, each branch location is assigned a dedicated subnet. The master AP in the branch manages
the dedicated subnet and functions as the DHCP server and gateway for clients. Client traffic that is destined for
data center resources is routed to the WLAN controller through the IPsec tunnel. The WLAN controller then routes
the traffic to the appropriate corporate destinations.
Any traffic to the Internet or a local destination is source NATed using the local IP address of the master AP and
bridged locally. The WLAN controller in the data center is aware of the Layer 3 subnet at each branch and can
redistribute these routes to upstream routers through OSPF. If required, all client traffic can be forwarded through the
IPsec tunnel or bridged locally.
In distributed L3 mode, you can initiate a connection from the data center to remote clients for troubleshooting.
If RADIUS traffic is not source NATed at the WLAN controller, the VPN pool that is used for inner IP addresses of
the IPsec tunnel must be routable for RFC 3576-compliance and 802.1X. For details about VPN address pools, see
Defining the VPN Pool on a WLAN Controller.
In distributed L2 mode, the BID allocation process is essential for the operation of distributed L3 mode. In distributed
L3 mode, after you configure a large subnet and define the number of clients per branch, the BID allocation algorithm
allocates a dedicated subnet to each branch by dividing the large address space into smaller subnets, based on
client count.
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 100
For example, an organization with a configuration of 10.10.0.0 /16 with 250 clients per branch can support 256
branches with a /24 subnet for each branch. In this example, the BID allocation process determines the /24 network
that is allocated to each branch. The BID allocation algorithm is essential to avoid subnet overlap across branches.
The WLAN controller depends on the BID allocation process to determine the active branches and redistribute the
appropriate routes using OSPF. The WLAN controller redistributes routes through OSPF only for those branches that
are up and running. If a branch goes down, the WLAN controller removes that branch from its OSPF route
redistribution.
Organizations would like to upgrade their existing branch infrastructure while retaining the same address pool
because their branches include devices with static IP addresses. To accommodate this requirement, Aruba Instant
OS 3.3 and greater enables you to assign predefined subnets to branches in the distributed L3 mode. For information
about configuring distributed L3 mode, see Instant-VPN: Distributed L3 Mode.
You must run Aruba Instant OS 3.3 or greater and ArubaOS 6.3 to support the configuration of predefined subnets
per branch. For more information, see Configuring an IAP for Instant-VPN Deployment.
You must run ArubaOS 6.3 or greater to support redistribution of Instant-VPN branch routes through OSPF.
Below figure shows the traffic flow in distributed L3 mode.
Figure 45 Packet flow in instant-VPN distributed L3 mode
To summarize, the key features of the Instant-VPN distributed L3 mode as follows:
l
Contains broadcast and multicast traffic to a branch.
l
The BID allocation process must occur when the branch site comes up for the first time. Until BID allocation is
complete, the master AP cannot lease IP addresses to the clients in the branch.
l
The DHCP server for clients is the master AP in the cluster.
l
If the WAN is down, a client can renew its DHCP lease and a new client can receive an IP address.
l
The master AP in the cluster is the default gateway for the clients in the branch.
l
Traffic to the data center is routed through the IPsec tunnel to the WLAN controller.
101 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
l
Traffic to the Internet or a local destination is source NATed with the local IP address of the master AP.
l
Configuring a routable VPN address pool, which is used for inner IP addresses of the IPsec tunnel, allows
access to the local WebUI of the Aruba Instant cluster from the data center.
l
If RADIUS traffic is not source NATed at the WLAN controller, configuring a routable VPN address pool is also
essential for 802.1X. To support RFC-3576, the RADIUS traffic must not be source NATed at the WLAN
controller and a routable VPN address pool is required.
l
The WLAN controller uses OSPF to redistribute branch routes to the upstream router. (The WLAN controller must
run ArubaOS 6.3 or greater.)
l
In small deployments with a single master WLAN controller and a VRRP backup WLAN controller, the upstream
router can use a static route that points to the VRRP IP address between the WLAN controllers as the next hop
for branch subnets.
l
Static routes cannot be used in multi-WLAN controller environments. OSPF is required in a multi-WLAN
controller environment and for geographical redundancy.
l
Please note that DL3 does not have a split tunnel knob, like CL2. In CL2 deployments, this knob has more
frequent use case. To achieve similar objective in DL3, use routing profiles.
Branch-ID Allocation Algorithm
For branches that are deployed in distributed L3 mode, the master AP in the branch and the WLAN controller must
coordinate the subnet and IP addresses that are used for DHCP services in the branch. The VC and WLAN
controller determine the subnet and IP addresses that are used in a branch through BID allocation process. (The BID
allocation process is not essential for branches that are deployed in local or centralized L2.)
The BID allocation process includes the following key functions:
l
Determination of the IP addresses that are used in a branch for distributed L2 mode
l
Determination of the subnet that is used in a branch for distributed L3 mode
l
Prevention of IP address or subnet overlap (IP address conflicts must be prevented)
l
Allocation of the same subnet or range of IP addresses to a branch, irrespective of which AP in the branch is the
master AP in the cluster
l
Allocation of a branch subnet that remains consistent during failover to a backup WLAN controller
BID Allocation Process Details
The BID allocation process consists of these steps:
When a branch comes up for the first time, one AP in the branch is elected as the master AP through the election
algorithm.
The master AP in a cluster generates and distributes a branch key to all member IAPs in the cluster. This branch key
is generated by hashing the MAC address of the master AP. The branch key plays a significant role in ensuring that a
branch is allocated the same subnet and IP addresses, irrespective of which IAP becomes the master AP of the
cluster at a later stage. The branch key is generated even for IAP clusters that are not configured for Instant-VPN.
The master AP forms an IPsec connection to the primary host (that is, the primary WLAN controller) and obtains an
inner IP address from the VPN address pool that is configured on the WLAN controller.
If the IAP cluster is configured for VPN in distributed L3 mode, the master AP starts the BID allocation process by
sending a registration message to the WLAN controller. This registration message includes these variables:
Inner IP: The inner IP address of the master AP that has established an IPsec tunnel to the WLAN controller.
Branch Key: The branch key that was generated and distributed to all member IAPs by the first master AP of the
cluster.
MAC: The MAC address of the master AP that participates in the BID process.
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 102
MAX_BID and subnet name: The maximum number of subnets or IP address blocks that can be created based on
the subnet size and client count in the distributed L3 and distributed L2 configuration on IAP. For examples on MAX_
BID calculation, see MAX-BID Calculation Examples.
In addition to the MAX_BID, the IAP sends the corresponding subnet name. The subnet name is derived from the
start and end IP address configuration and the client count for each mode. For example, if an organization uses
10.10.0.0 /16 with 250 clients per branch, the IP configuration on the IAP is 10.0.0.0 – 10.10.255.255 instead of
10.10.0.0/16. The subnet name for this distributed L3 subnet is “10.0.0.0 – 10.10.255.255.250”. The subnet name
keeps track which MAX_BID applies to which distributed mode configuration. If a branch is configured for multiple
distributed modes, the IAP sends multiple combinations of MAX_BID and corresponding subnet names to the
WLAN controller. This method allows a branch to have multiple SSIDs that use different distributed modes and
different subnet sizes. For example an organization can have an SSID_1 with distributed L3 mode and a
configuration of "10.10.0.0 /16” with 250 clients per branch and SSID_2 with distributed L3 mode and a configuration
of "10.20.0.0 /16” with 100 clients per branch.
BID: The value that specifies whether a branch is new or already has a BID. A new branch uses a unique value in
this field to specify that it requires a BID from the MAX_BID range. In a branch that has already a BID allocated, the
master AP might go down and a new AP might be elected as the master AP. When the new master AP connects to
the WLAN controller, it uses the previously allocated BID in this field.
Backup: It is the value that specifies whether the master AP is communicating with a backup host. A backup host is
a backup WLAN controller to which the master AP can initiate an IPsec connection. A backup host is similar to a
backup local management switch (BLMS) controller in ArubaOS and it does not represent a VRRP backup to a
WLAN controller.
The BID allocation process occurs only between the primary host and the master AP. So when a branch comes up
for the first time, the WLAN controller that functions as the primary host must be up. That is, any Instant-VPN branch
that comes up from factory defaults and that is configured for distributed L3 mode must exchange its very first BID
process with its primary host for allocation of the address space or subnet that is required for the distributed L3
mode.
Upon receiving the BID registration message, the WLAN controller determines whether a branch is new by
examining the BID field. If the branch is new, the WLAN controller verifies whether the branch key in the registration
message is present in its database (DB). If the branch key is not in the DB, the WLAN controller selects an unused
BID from the MAX_BID range and returns it to the master AP. If the branch key is already present in the WLAN
controller DB, the WLAN controller returns the BID that is already associated with the branch key.
The possibility that a master AP represents itself as a new branch when the branch key is already registered in the
WLAN controller DB is very rare. However, the BID process is designed to prevent an IAP from losing its BID
because of a crash.
When the BID is allocated, the master AP uses the BID to determine the IP subnet or IP addresses that must be
used. The following examples describe how the subnets are determined, based on BID value:
Consider an organization that uses a “10.10.0.0 /16” configuration with 250 clients per branch as the distributed L3
mode configuration on IAPs in 200 branches. This configuration can support 256 branches. If a branch is assigned a
BID of 0, it takes the first available /24 subnet. The subnet for the branch is 10.10.<bid>.0/24 = 10.10.0.0 /24. If a
branch is assigned a BID of 50, the subnet for the branch is 10.10.<bid>.0 /24 = 10.10.50.0 /24.
After determining the IP address or the subnet that must be used, the master AP registers the IP addresses and IP
subnet with the WLAN controller, using the ROUTE ADD and VLAN ADD messages. The ROUTE ADD message
reports to the WLAN controller about the L3 subnet that is used by an IAP in the branch and the VLAN ADD
message reports to the WLAN controller about the L2 VLAN that is used in the branch.
103 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
Even though the BID process is not used for the centralized L2 mode, the VLAN ADD and ROUTE ADD messages
are used by branches in centralized L2 and centralized L3 modes to report to the WLAN controller about the VLAN
and subnet that are in use. This information enables the WLAN controller to forward the traffic to appropriate
branches. The Route ADD and VLAN ADD messages are not part of the BID process. These data path
programming messages are used to add the appropriate VLAN and Route information to the WLAN controller data
path.
The master AP distributes the BID that is allocated to the branch to all member IAPs. If the master AP fails and a
member IAP becomes the new master AP, the branch key and BID do not change, and the branch continues to use
the same subnet and IP addresses. If a new member IAP becomes the master AP, it performs the BID process.
However, instead of registering as a new branch, the new master AP sends the existing BID in the registration
message.
Since the branch key is essential for the BID process, Aruba recommends that you reset an IAP to factory defaults
before you move it from one branch to another.
MAX-BID Calculation Examples
Consider an organization that uses “10.10.0.0 /16” with 250 clients per branch as the distributed L3 mode
configuration on IAPs in 200 branches. The master AP in each branch performs the following math to determine the
MAX_BID:
l
If each branch has 250 clients, in the equation 2^n = 250, n must be 8 (2^8 = 256). The master AP has the n value
that determines the subnet size required for a branch.
l
Subnet size in a branch = (total number of address bits in IPv4 minus the above-mentioned n). The equation is,
32-8 = 24. The master AP determines that it needs a /24 address space for that branch.
l
The MAX_BID is the number of /24 subnets that is possible with a 10.10.0.0 /16 address space. MAX-BID =
(total number of IP addresses in a /16 address space divided by the total number of IP addresses in a /24 address
space). The equation is 65536/256 = 256. So the MAX_BID is 255, because 0 is also considered a BID value.
Below Understanding Instant-VPN (Aruba Instant-VPN in a Nutshell) shows the BID allocation process between a
VC and a WLAN controller.
Figure 46 Allocating the BID
1. In a new branch, the master AP/VC generates a branch key from its mac.
2. Branch key generated by master/VC is distributed, to all member APs in the cluster.
3. VC forms IPSec tunnel to primary controller, and obtains inner IP address for IPSec.
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 104
4. VC starts the BID allocation process, by sending a registration message to primary controller, that it’s a new
branch. The transaction also contains, Max-BID, subnet name, inner IP, mac address of VC, backup & branch
key.
The backup field indicates if the controller is primary or backup.
Max-BID determines the number of possible branches based on subnet size, and clients per branch config.
Subnet name maps Max-BID to a subnet configuration.
5. Controller ensures that the branch key does not already exist in DB. If it does not exist, the controller will send a
new BID. However if a branch key/BID combination exists on the controller, the controller will send the BID
already associated with that branch key.
6. After BID is allocated, the VC calculates the subnet for the branch and register it with the controller. BID plays an
important role in subnet calculation.
7. If the current master AP fails, and a member AP becomes the master, the member AP will have the same branch
key and BID. The member AP, after forming the IPSec connection, informs the controller of branch key and BID,
this ensures that the branch gets the same subnet irrespective of which AP becomes the master.
Aruba recommends that the WLAN controller for Aruba Instant-VPN termination runs 6.3.xx. or greater.
Traffic Flow and Uplink Switch Requirements for a Multi-AP Aruba Instant-VPN Network
In an Aruba Instant cluster that is configured for Instant-VPN, only the master AP establishes the VPN tunnel to the
WLAN controller. In a multi-AP network, traffic from clients that are connected to member IAPs always reaches the
master AP in local, centralized L2 and distributed L3 modes. In local and distributed L3 modes, the VC/master AP is
the default gateway for clients, so the client traffic reaches the master AP. When the traffic reaches the master AP,
the master AP forwards the traffic through the IPsec tunnel or bridges it locally based on the destination.
No GRE tunnels or proprietary tunnels exist between IAPs in an IAP cluster. A switch that connects all IAPs in a
multi-AP Aruba Instant network must be VLAN-aware and tag the traffic appropriately to ensure that the traffic from
clients on member IAPs reaches the master AP.
For example, consider a branch with 10 IAPs that are connected to a switch. The branch has two SSIDs:
l
A guest SSID that is configured in local mode with VLAN 20 to provide captive portal authentication using an
external server
l
An employee SSID that is configured in distributed L3 mode with VLAN 30
In this example, the switch that connects the IAPs must be aware of both VLAN 20 and VLAN 30. All IAPs must be
connected to a dot1q trunk port. Basically, the switch that connects the IAP cluster must be aware of all VLANs that
are used in the IAP configuration.
The only exception to this rule is a magic VLAN. (To configure magic VLAN, use “virtual controller managed” &
“Default Client VLAN assignment” in the VLAN option, while configuring SSID, as shown in figure below).
105 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
The master AP uses an IPsec tunnel to forward the traffic from clients in local and L3 mode. However, in centralized
L2 mode, the master AP uses an IPsec-GRE tunnel for clients. This IPsec-GRE tunnel provides multicast traffic
forwarding capabilities in distributed L2 and centralized L2 modes. Multicast traffic cannot be forwarded from a
WLAN controller to an IAP branch that operates in local or distributed L3 modes.
802.1X and RFC 3576 Handling in an Aruba Instant-VPN Network
In an Instant-VPN branch network, users can be authenticated through a local RADIUS server or a RADIUS server
in the data center. The master AP in an Instant-VPN branch determines whether a RADIUS server is local or located
in the data center by checking its routing profile. For more information about the IAP routing profile, see Configuring
an IAP for Instant-VPN Deployment. If the routing profile indicates that traffic to a subnet is in the data center (for
example, 10.0.0.0 /8) and if the IP address of the RADIUS server that is configured on the IAP belongs to that
address space (for example, the RADIUS server IP address is 10.68.32.40), the master AP forwards the 802.1X
traffic through the IPsec tunnel to the data center.
RADIUS traffic to a RADIUS server in the data center is sourced using the inner IP address of the IPsec tunnel.
Therefore, the VPN address pool that is used for inner IP addresses of IPsec tunnels must be routable from the
upstream router in the data center. If RFC 3576-compliance is not required, you can use a source NAT rule on the
WLAN controller to source NAT all RADIUS traffic with the IP address of that WLAN controller. If a branch network
has a local RADIUS server (for example, 192.168.10.20), and if dynamic RADIUS proxy (DRP) is enabled on the
IAP, the 802.1X traffic is source NATed with the VC IP address.
For RFC 3576-compliance, CoA messages are initiated by the RADIUS server. Therefore, you should not enable
a rule on the WLAN controller to source NAT all RADIUS traffic with the IP address of that WLAN controller. For
RFC 3576-compliance, if the RADIUS server is in the data center, the inner IP addresses of the IPsec tunnels
must be listed as RADIUS clients. If you use RFC 3576-compliance with a local RADIUS server, the VC IP
address must be added as the RADIUS client. DRP must be enabled on multi-AP Aruba Instant networks to
tunnel the RADIUS traffic from the member IAPs to the authentication server in the data center.
Table 17: DRP settings and RFC compliance
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 106
RADIUS
server
location
DRP
VPN pool
routable from
DC
DC
Enabled
Yes
DC
Enabled
Local
Local
ACL source NATs
traffic to controller
IP
RFC 3576
compliant
Source IP
NAS IP
No
Inner IP of
IPSec tunnel
VPN Tunnel
IP
Yes
No
Yes
Controller’s
IP
VPN Tunnel
IP
No
Enabled
N.A.
N.A.
VC/master
AP’s local IP
VC IP
Yes
Disabled
N.A.
N.A.
Each member
AP’s local IP
Master/Slave
AP IP
Yes
(DC/local
In a multi-AP Instant-VPN network, to tunnel the RADIUS traffic from member IAPs to the RADIUS server in the
data center, you must enable DRP. When DRP is enabled, the 802.1X transactions for clients connecting to the
member IAPs are forwarded to the master AP, which functions as a RADIUS proxy. With DRP enabled, the NAS-IP
attribute in RADIUS packets that are destined for the RADIUS server in the data center is set to the inner IP address
of the IPsec tunnel.
DRP is not required for single AP deployments. However, if DRP is disabled in single AP deployments, the NAS-IP
attribute in RADIUS packets that are destined to the RADIUS server in the data center is set to the local IP address
of the IAP and not to the inner IP address of the IPsec tunnel. Therefore, Aruba recommends that you enable DRP in
single AP deployments with RADIUS servers that use the NAS IP attribute as a filter for authentication.
DNS Handling in an Aruba Instant-VPN Network
By default, all DNS requests from a client are forwarded to the clients DNS server. In a typical IAP deployment
without VPN configuration, client DNS requests are resolved by the DNS server of the client. However, this
behavior changes if an IAP is configured for Instant-VPN.
The DNS behavior of an IAP network (with SSIDs or wired ports) that is configured for Instant-VPN is determined by
the enterprise domain settings. The enterprise domain setting on the IAP defines the domains for which the DNS
resolution must be forwarded to the default DNS server of the client. For example, if the enterprise domain is
configured for arubanetworks.com, the DNS resolution for host names in the arubanetworks.com domain is
forwarded to the default DNS server of the client. The DNS resolution for host names in all other domains is source
NATed to the local DNS server of the IAP.
If no configuration is present in enterprise domain section and the client is on an SSID for IAP VPN, all the DNS
traffic will be source NATed to DNS server of IAP. Apart from this VPN SSID, if there is a non VPN SSID, its traffic
will go to client’s DNS server.
If split tunnel knob is set to disabled, all DNS traffic will be sent over IPSec tunnel to DNS server of the client, no
matter what the configuration of enterprise domain is. Configuration is present at IAP GUI>>System>>show
advanced options>>Enterprise domains.
107 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
If you configure an asterisk (*) instead of a domain name in the enterprise domain list, all DNS requests are
forwarded to the default DNS server of the client. If you want all DNS requests to be processed by the DNS server
of the client, configure an asterisk (*) in the enterprise domain setting.
Control Traffic between an Aruba Instant-VPN Branch and the WLAN Controller
The bandwidth consumption on the tunnel between an Aruba Instant branch and the WLAN controller is a sum of all
client data traffic through the tunnel and the control traffic between the Aruba Instant branch and the WLAN
controller. The control traffic between an Aruba Instant branch and the WLAN controller is minimal. By default, the
master AP sends a 56-byte ICMP packet to the WLAN controller every 5 seconds to detect if the tunnel is up. You
can set the frequency of these ICMP packets to any value between 1-3600 seconds. If you set the value higher, the
downside is that the IAP requires more time to detect whether a tunnel is down and failed over to the backup WLAN
controller. Aruba recommends that you keep the ICMP packet frequency value at its default.
If you want to change them, please follow information on the link.
Recommendations for IAP-VPN Modes summarizes the usage recommendations for the IAP-VPN modes.
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 108
Table 18: Recommendations for IAP-VPN Modes
IAP-VPN Mode
Usage Recommendations
Things to Remember
Local
Recommended if you there is no
requirement to access the clients
on remote location, where IAP VPN
is deployed, from Data center.
Any traffic for a corporate destination is source NATed
with the inner tunnel IP address, so the inner IP address
pool that is used for VPN must be routable from the
corporate network, or you can src NAT the traffic again.
Clients on remote location, where IAP VPN is deployed,
can always access resource at Data center. But reverse
way is not true, as all traffic is source NATed over inner IP
of VPN tunnel.
For more information, see Instant-VPN: Local Mode and
DHCP Profile for Local Mode.
Centralized L2
Recommended only if multicast
traffic to a branch is required. If it is
not required, use L3 modes.
The DHCP server is centralized, so DHCP services for
new clients and DHCP renewals fail if the WAN is down.
Aruba recommends a /24 or /23 subnet for user VLANs.
For more information, see Instant-VPN: Centralized L2
Mode and DHCP Profile for Centralized L2 Mode.
Distributed L3
Recommended for all deployments.
You can access the clients on
remote location, where IAP VPN is
deployed, from Data center.
Branch routes must be redistributed using OSPF on the
WLAN controller.
For more information, see Instant-VPN: Distributed L3
Mode and DHCP Profile for Distributed L3 Mode.
Redundancy Design for Aruba Instant-VPN Deployments
To ensure productivity in branch deployments, high availability of data center resources is essential. One of the core
principles of the Aruba Instant solution is redundancy and resiliency. The following data center redundancy options
are available with the Aruba Instant-VPN solution:
l
Single data center with redundancy
l
Multiple data centers with redundancy (geographical redundancy)
In a single data center deployment without redundancy, all Instant-VPNs terminate on a single WLAN controller in a
single data center. If the WLAN controller or the data center is down, the branch network loses access to all
centralized resources. Aruba strongly recommends that you design your Instant-VPN deployments with redundancy.
Below figure is an example of an Instant-VPN network without redundancy.
Figure 47 Instant-VPN network without redundancy
109 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
Single Data Center Deployment with Redundancy
This design provides WLAN controller redundancy within a single data center deployment. All Instant-VPNs
terminate on a pair of redundant WLAN controllers in a data center and WLAN controllers are deployed in a VRRPbased master redundancy topology. The IAP-VPNs in this deployment terminate on the VRRP IP address of the
master redundancy topology. For information about master redundancy between WLAN controllers, see the Aruba
Campus Redundancy Models Validated Reference Design.
Below is an example of an Instant-VPN network with a single data center and redundancy.
Figure 48 Instant-VPN network with a single data center and redundancy
Multiple Data Center Redundancy (Geographical Redundancy)
Organizations that design high availability plan for geographical redundancy to ensure that data center network
problems, natural disasters, or calamities in one region do not affect the productivity of the distributed workforce.
Aruba Instant-VPN supports geographical redundancy with a primary and backup setup. Geographical redundancy
provides these two options:
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 110
l
Geographical redundancy without redundant WLAN controllers at each data center: In this setup,
Instant-VPNs terminate on a primary WLAN controller in one data center with another WLAN controller in a
geographically separate data center functioning as the backup. There is no redundancy for WLAN controllers at
every data center.
l
Geographical redundancy with redundant WLAN controller at each data center: In this setup, InstantVPNs terminate on a pair of redundant primary WLAN controllers in one data center with another pair of redundant
WLAN controllers in a geographically separate data center functioning as the backup.
The BID that is required for distributed L3 mode is allocated only by the primary host. The very first BID process
for an Instant-VPN branch in distributed L2 or distributed L3 mode with geographical redundancy must be
exchanged with the primary host. If the primary host of a branch goes down after the initial BID allocation process,
the branch fails over to the backup host and all modes function as expected. For more information, see Branch-ID
Allocation Algorithm
Below figure is an example of an Instant-VPN network with multiple data centers and redundant WLAN controller at
every data center.
Figure 49 Geographical redundancy with redundant WLAN controller at each data center
Designing Instant-VPN Deployments
Designing a VPN-based branch deployment with Aruba Instant is a combination of the following components:
l
Physical design of the branch (single-AP or multi-AP branch)
l
Data center redundancy (single data center or multiple data centers)
l
Logical design (Instant-VPN mode, traffic engineering, and so on)
To build a sound Instant-VPN deployment, it is critical that you understand the deployment requirements and select
the appropriate physical, logical, and redundancy design. To help you understand the considerations and
recommendations that are involved in designing an Instant-VPN deployment, consider the most common
deployment use cases:
l
Single-AP branch with a single data center
l
Single-AP deployment with multiple data centers
111 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
l
Multi-AP deployment with a single data center
l
Multi-AP Deployment with multiple data centers
These use cases are described in the following sections:
Single-AP Branch with a Single Data Center
For the deployment of a single-AP branch with a single data center, the common components and requirements are
as follows:
l
Small branches supported by single IAP
l
Single data center deployment with no geographical redundancy requirement
l
Secure wireless access for employees and access to corporate resources using VPN
l
Optional guest access in certain deployments
l
Optional support for corporate wired devices such as printers
l
WAN uplink (Ethernet or 3G/4G modem)
The typical Instant-VPN design and configuration for this deployment is as follows:
l
Physical design: The physical design for this deployment is a single-AP design. Uplink redundancy for the
branch network is optional. For information about uplink redundancy, see the Aruba Instant User Guide that is
available at the Aruba support website.
l
Data center redundancy: Based on the total number of branch sites, select the appropriate WLAN controller
platform. Because this deployment is designed for a single data center, Aruba recommends that you deploy
redundant WLAN controllers in the data center using master redundancy to safeguard against controller failure.
For more information, see Redundancy Design for Aruba Instant-VPN Deployments.
l
Logical design: The logical design for this deployment includes the following components and
recommendations:
n
Employee SSIDs with the appropriate authentication. The VLAN that is used for an employee SSID must
belong to the appropriate Instant-VPN mode. Aruba recommends that you use distributed L3 mode for all
deployments except for those that require support for multicast traffic from the data center to the branch. You
can use centralized L2 modes for deployments that require a centralized DHCP server. For more information
about Instant-VPN modes, see Understanding Instant-VPN Modes.
n
Wired ports that are used for corporate devices with the appropriate authentication. The VLAN that is used for
corporate wired devices must belong to the appropriate Instant-VPN mode. Aruba supports role-based
access, so separate VLANs are not required for employees and corporate devices. Both the employee SSID
and the wired ports for corporate devices can use the same VLAN in Instant-VPN mode. You can restrict
access using appropriate user roles.
n
As an option, you can use a separate VLAN in the appropriate Instant-VPN mode for wired clients. For
example, if you use “10.10.0.0 /16” with 50 clients per branch for an employee SSID in Layer 3 mode, you can
set up a separate address range of “10.11.0.0 /16” with 5 clients per branch for wired devices and a separate
VLAN in distributed L3 mode for the wired clients.
n
Split-tunnel traffic. You can use the routing profile to tunnel or split-tunnel traffic from employees and wired
devices. To meet the different traffic engineering requirements, you can use a combination of the routing
profile and source NAT ACLs in user roles.
n
Role-based access for wired and wireless devices.
n
BYOD for employees on the employee SSID with ClearPass.
n
In single-AP deployments, deny corporate access to any rogue clients on the IAP’s uplink device by using the
“Restrict Corporate Access” feature on Aruba Instant.
n
Modify split-DNS behavior according to the requirements. For more information, see DNS Handling in an
Aruba Instant-VPN Network.
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 112
n
As an option, guest access using a guest SSID that is mapped to a local-mode VLAN and captive portal
authentication is supported. Guests can be supported with the internal captive portal page and guest
management features of Aruba Instant or ClearPass Guest Solution. For more information, see the Aruba
Instant User Guide that is available at the Aruba support website.
n
As an option, authentication survivability with ClearPass to address WAN failures.
An Aruba Instant network that is configured for Instant-VPN establishes only a single IPsec tunnel from the
master AP of the cluster to the WLAN controller. That is, an Aruba Instant cluster does not build separate IPsec
tunnels for each SSID or wired port that is configured for Instant-VPN. Below figure is an example of a single-AP deployment with a single data center with WLAN controller redundancy.
Figure 50 Single-AP deployment with a single data center with WLAN controller redundancy
The following sections provide an overview of the basic IAP and data center configurations that are required to
design a single-AP branch with a single data center.
This example uses distributed L3 mode for employees and wired devices.
IAP Setup (Single-AP Branch with a Single Data Center)
The key configurations that are required for the IAP include the following configurations:
1. Set up the VPN primary IP configuration.
2. Define the routing profile. This profile specifies the traffic that must be tunneled to the data center. For
more information about routing profiles, see Configuring an IAP for Instant-VPN Deployment.
3. Configure the enterprise domains on the IAP for split-DNS.
4. Configure the DHCP server for appropriate Instant-VPN mode. For example, set up a distributed L3 mode DHCP
configuration for the employee SSID and corporate wired devices.
5. Configure the authentication servers for user authentication. For example, set up a RADIUS server
configuration for ClearPass for employee authentication, BYOD, and wired device authentication.
DRP is not required in single AP Instant-VPN deployments. In single AP deployments, the RADIUS traffic is
sourced with the inner IP address of the IPsec tunnel or the VC IP address, based on the routing profile definition.
113 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
6. Configure the employee SSID with the appropriate authentication, RADIUS servers, and user roles and map it to
the VLAN in the appropriate Instant-VPN mode. For example, map the employee SSID and the wired ports to the
distributed L3 mode VLAN that you set up in step 4.
7. For some environments, set up a combination of a routing profile and a source NAT ACL in the user roles to meet
the different traffic engineering requirements. For example, if all traffic for corporate wired devices must be
tunneled but employee Internet traffic must be split-tunneled, set up a routing profile with a “0.0.0.0 0.0.0.0
<gateway IP>” configuration and an employee user role that tunnels traffic for corporate destinations but source
NATs traffic for all other destinations (that is, set up an ACL with a permit action for corporate destinations
followed by an ACL with a source NAT action for Internet destinations).
8. In single AP deployments, as part of the Firewall Settings screen, enable the “Restrict Corporate Access” setting
to restrict corporate access to only those devices that are downstream from the IAP. The “Restrict Corporate
Access” setting prevents corporate access to any rogue clients on the APs uplink switch. Do not enable the
“Restrict Corporate Access” setting in a multi-AP flat-mode design. By default, the “Restrict Corporate Access”
setting is disabled.
9. In environments that require guest access, perform the following steps:
n
Set up a DHCP configuration in local mode.
n
Map the configuration to the guest SSID that is set up for captive portal authentication.
10. Configure uplink redundancy in environments that require uplink redundancy.
Data Center Configuration (Single-AP Branch with a Single Data Center)
Aruba recommends that you plan for redundancy. The following procedure describes a redundant WLAN controller
configuration:
The key configurations that are required on the WLAN controller are listed below:
1. Configure the WLAN controllers with the basic settings such as VLANs, IP addresses, and the required license.
2. Configure the WLAN controller pair for master redundancy. For information about configuring master redundancy,
see the Aruba Campus Networks Validated Reference Design or the Aruba User Guide at the Aruba support
website.
3. Define the VPN address pool that is used to assign inner IP addresses to the IPsec tunnel that is established at
the branch.
4. Add IAPs in the branch to the RAP whitelist. This whitelist can be offloaded to a CCPM or other servers that
support authorization. For more information, see Adding IAPs to RAP Whitelist.
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 114
5. Configure the appropriate VLANs for branches that are deployed in Layer 2 mode. (This step is required only if the
branch is configured for centralized L2 mode.) For more information, see Configuring VLANs for Layer 2 Modes.
6. Configure OSPF route redistribution of Layer 3 branch routes. (This step is required only if the branch is
configured for distributed L3 mode.) For more information, see Configuring OSPF Route Redistribution of Layer 3
Branch Routes.
7. As an option, configure the WLAN controller to perform source NATing of 802.1X and RADIUS traffic from IAP
branches. However, if RFC 3576-based CoA is a requirement, RADIUS traffic from the IAP branches must not
be source NATed at the WLAN controller. For CoA capabilities, all IP addresses and subnets that are used in the
VPN address pool must be added to the RADIUS server. For more information, see Configuring the Controller to
Perform Source NATing for 802.1X and RADIUS Traffic from Branches.
Single-AP Deployment with Multiple Data Centers
The requirements of this deployment are similar to those of the single-AP deployment with a single data center,
except that geographical redundancy is required. Below are the common requirements and components of this
deployment:
l
Small branches supported by single IAP
l
Multiple data center deployment with geographical redundancy requirement
l
Secure wireless access for employees and access to corporate resources using VPN
l
Optional guest access in certain deployments
l
Optional support for corporate wired devices such as printers
l
WAN uplink (Ethernet or 3G/4G modem)
The typical Instant-VPN design and configuration for this deployment is as follows:
l
Physical design: The physical design for this deployment is a single-AP design. Uplink redundancy for the
branch network is optional. For information about uplink redundancy, see the Aruba Instant User Guide that is
available at the Aruba support website.
l
Data center redundancy: Based on the total number of branch sites, select the appropriate WLAN controller
platform. Because this deployment requires geographical redundancy, the multi data center redundancy model
applies to this deployment. Aruba recommends that you consider redundant master WLAN controllers in the
individual data centers of a multi data center design to safeguard against controller failure in the individual data
centers. For more information, see Redundancy Design for Aruba Instant-VPN Deployments.
l
Logical design: The logical design for this deployment includes the following components and
recommendations:
n
Employee SSIDs with the appropriate authentication. The VLAN that is used for an employee SSID must
belong to the appropriate Instant-VPN mode. Aruba recommends that you use distributed L3 mode for all
deployments except for those that require support for multicast traffic from the data center to the branch. The
VLAN IP address that is configured in the centralized L3 mode definition is different for each branch, so you
must either modify the AirWave configuration on a per-branch level during the initial deployment, or use a
separate group in AirWave for each branch. For more information about Instant-VPN modes, see
Understanding Instant-VPN Modes.
n
Wired ports that are used for corporate devices with the appropriate authentication. The VLAN that is used for
corporate wired devices must belong to the appropriate Instant-VPN mode. Aruba supports role-based
access, so separate VLANs are not required for employees and corporate devices. Both the employee SSID
and the wired ports for corporate devices can use the same VLAN in Instant-VPN mode. You can restrict
access using appropriate user roles.
n
As an option, a separate VLAN in the appropriate Instant-VPN mode for wired clients. For example, if you use
“10.10.0.0 /16” with 50 clients per branch for an employee SSID in Layer 3 mode, you can set up a separate
115 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
address range of “10.11.0.0 /16” with 5 clients per branch for wired devices and a separate VLAN in distributed
L3 mode for the wired clients.
n
Split-tunnel traffic. You can use the routing profile to tunnel or split-tunnel traffic from employees and wired
devices. To meet the different traffic engineering requirements, you can use a combination of the routing
profile and source NAT ACLs in user roles.
n
Role-based access for wired and wireless devices.
n
BYOD for employees on the employee SSID with ClearPass.
n
In single-AP deployments, deny corporate access to any rogue clients on the IAPs uplink device using the
“Restrict Corporate Access” feature on Aruba Instant.
n
Modify split-DNS behavior according to the requirements. For more information, see DNS Handling in an
Aruba Instant-VPN Network.
n
As an option, guest access using a guest SSID that is mapped to a local-mode VLAN and captive portal
authentication. Guests can be supported with the internal captive portal page and guest management features
of Aruba Instant or ClearPass Guest Solution. For more information, see the Aruba Instant User Guide that is
available at the Aruba support website.
n
As an option, authentication survivability with ClearPass to address WAN failures.
An Aruba Instant network that is configured for Instant-VPN establishes only a single IPsec tunnel from the
master AP of the cluster to the WLAN controller. That is, an Aruba Instant cluster does not build separate IPsec
tunnels for each SSID or wired port that is configured for Instant-VPN.
Below is an example of a single-AP deployment with a multiple data centers with WLAN controller redundancy.
Figure 51 Single-AP deployment with multiple data centers and WLAN controller redundancy
The following sections provide an overview of the basic IAP and data center configurations that are required to
design a single-AP branch with multiple data centers.
This example uses distributed L3 mode for employees and wired devices.
IAP Setup (Single-AP Branch with Multiple Data Centers)
The key configurations that are required for the IAP are listed below:
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 116
1. Set up the VPN primary IP configuration.
2. Set up the VPN secondary IP configuration.
3. Set up a fast failover configuration if the environment requires a fast failover.
4. Define the routing profile. This profile specifies the traffic that must be tunneled to the data center. The routing
profile must have two sets of routes. One points to the primary data center and the other points to the backup data
center. The IAP selects a route based on the data center that it is terminating on. For example, if all 10.0.0.0 /8
networks must be tunneled back to the data center, the routing profile must have two routes: “10.0.0.0 255.0.0.0
<controller in data center 1>” and “10.0.0.0 255.0.0.0 <controller in data center 2>”. For more information about
routing profiles, seeConfiguring an IAP for Instant-VPN Deployment.
5. Configure the enterprise domains on the IAP for split-DNS.
6. Configure the DHCP server for appropriate Instant-VPN mode. For example, set up a distributed L3 mode DHCP
configuration for the employee SSID and corporate wired devices.
7. Configure the authentication servers for user authentication. For example, set up a RADIUS server configuration
for ClearPass for employee authentication, BYOD, and wired device authentication.
DRP is not required in single AP Instant-VPN deployments. In single AP deployments, the RADIUS traffic is
sourced with the inner IP address of the IPsec tunnel or the VC IP address, based on the routing profile definition.
8. Configure the employee SSID with the appropriate authentication, RADIUS servers, and user roles and map it to
the VLAN in the appropriate Instant-VPN mode. For example, map the employee SSID and the wired ports to the
distributed L3 mode VLAN that you set up in step 6.
9. For some environments, set up a combination of a routing profile and a source NAT ACL in the user roles to meet
the different traffic engineering requirements. For example, if all traffic for corporate wired devices must be
tunneled but employee Internet traffic must be split-tunneled, set up a routing profile with a “0.0.0.0 0.0.0.0
<gateway IP>” configuration and an employee user role that tunnels traffic for corporate destinations but source
NATs traffic for all other destinations (that is, set up an ACL with a permit action for corporate destinations
followed by an ACL with a source NAT action for Internet destinations).
10. In single AP deployments, as part of the Firewall Settings screen, enable the “Restrict Corporate Access” setting
to restrict corporate access to only those devices that are downstream from the IAP. The “Restrict Corporate
Access” setting prevents corporate access to any rogue clients on the APs uplink switch. Do not enable the
“Restrict Corporate Access” setting in a multi-AP flat-mode design, which is the most commonly used design. By
default, the “Restrict Corporate Access” setting is disabled.
117 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
11. In environments that require guest access, perform the following steps:
n
Set up a DHCP configuration in local mode.
n
Map the configuration to the guest SSID that is set up for captive portal authentication.
Data Center Configuration (Single-AP Branch with Multiple Data Centers)
In addition to geographical redundancy, Aruba recommends that you consider WLAN controller redundancy in every
data center of a geographically redundant design. If a WLAN controller failure occurs at the primary data center, the
backup WLAN controller in the primary data center takes over, which prevents the branch network from switching
over to the backup data center. This procedure describes a redundant WLAN controller configuration for a data
center.
The key configurations that are required on the WLAN controller are listed below:
1. Configure the WLAN controllers with the basic settings such as VLANs, IP addresses, and the required license.
2. Configure the WLAN controller pair for master redundancy. For information about configuring master redundancy,
see the Aruba Campus Networks Validated Reference Design or the Aruba User Guide at the Aruba support
website.
Define the VPN address pool that is used to assign inner IP addresses to the IPsec tunnel that is established at the
branch. Aruba recommends that you use a routable address space for the VPN address pool. For more information,
see Defining the VPN Pool on a WLAN Controller.
Aruba also recommends that you set up a unique VPN address pool for each WLAN controller in each data center.
3. Add IAPs in the branch to the RAP whitelist. This whitelist can be offloaded to a CCPM or other servers that
support authorization. For more information, see Adding IAPs to RAP Whitelist.
4. Configure the appropriate VLANs for branches that are deployed in Layer 2 mode. (This step is required only if the
branch is configured for centralized L2 or distributed L2 mode). For more information, see Configuring VLANs for
Layer 2 Modes.
5. Configure OSPF route redistribution of Layer 3 branch routes. (This step is required only if the branch is
configured for distributed L3 mode). For more information, see Configuring OSPF Route Redistribution of Layer 3
Branch Routes.
6. As an option, configure the WLAN controller to perform source NATing of 802.1X and RADIUS traffic from IAP
branches. However, if RFC 3576-based CoA is a requirement, RADIUS traffic from the IAP branches must not
be source NATed at the WLAN controller. For CoA capabilities, all IP addresses and subnets that are used in the
VPN address pool must be added to the RADIUS server. For more information, see Configuring the Controller to
Perform Source NATing for 802.1X and RADIUS Traffic from Branches.
Multi-AP Deployment with Single Data Center
For the deployment of a multi-AP branch with a single data center, the following components and requirements are
common:
l
Branches that require more than one IAP
l
Single data center deployment with no geographical redundancy requirement
l
Secure wireless access for employees and access to corporate resources using VPN
l
Optional guest access in certain deployments
l
Optional support for corporate wired devices such as printers
l
WAN uplink (Ethernet or 3G/4G modem)
The typical Instant-VPN design and configuration for this deployment is as follows:
l
Physical design: The physical design for this deployment is a multi-AP design. For branches that require 2 to 4
IAPs, use either hierarchical or flat mode design for AP deployment. In branches with 5 or more IAPs, use flat
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 118
mode design. Flat mode deployment requires a trusted managed switch to connect the IAPs. For more
information about multi-AP design, see Multi AP Branch. Uplink redundancy for the branch network is optional.
For information about uplink redundancy, see the Aruba Instant User Guide that is available at the Aruba support
website.
l
Data center redundancy: Based on the total number of branch sites, select the appropriate WLAN controller
platform. Because this deployment is designed for a single data center, Aruba recommends that you deploy
redundant WLAN controllers in the data center using master redundancy to safeguard against controller failure.
For more information, see Redundancy Design for Aruba Instant-VPN Deployments.
l
Logical design for hierarchical mode design: The logical design for this deployment includes the following
recommendations and components:
n
If deployed in hierarchical mode, the member IAPs connect to the downlink ports of the root IAP. Configure
the wired ports of the root IAP to which the member IAP connect with a VLAN in local mode. These ports
must be in trunk mode with the native VLAN set to the local mode VLAN that is used for member IAPs. This
setup allows the IAPs in hierarchical mode to support multiple VLANs.
n
In hierarchical mode, you can use the wired ports of the root IAP for corporate wired devices.
n
Employee SSIDs with the appropriate authentication. The VLAN that is used for an employee SSID must
belong to the appropriate Instant-VPN mode. Aruba recommends that you use distributed L3 mode for all
deployments except for those that require support for multicast traffic from the data center to the branch. You
can use centralized L3 modes for deployments that require a centralized DHCP server. The VLAN IP address
that is configured in the centralized L3 mode definition is different for each branch, so you must either modify
the AirWave configuration on a per-branch level during the initial deployment, or use a separate group in
AirWave for each branch. For more information about Instant-VPN modes, see Understanding Instant-VPN
Modes.
n
Wired ports that are used for corporate devices with the appropriate authentication. The VLAN that is used for
corporate wired devices must belong to the appropriate Instant-VPN mode. Aruba supports role-based
access, so separate VLANs are not required for employees and corporate devices. Both the employee SSID
and the wired ports for corporate devices can use the same VLAN in Instant-VPN mode. You can restrict
access using appropriate user roles.
n
As an option, a separate VLAN in the appropriate Instant-VPN mode for wired clients. For example, if you use
“10.10.0.0 /16” with 50 clients per branch for an employee SSID in Layer 3 mode, you can set up a separate
address range of “10.11.0.0 /16” with 5 clients per branch for wired devices and a separate VLAN in distributed
L3 mode for the wired clients.
n
Split-tunnel traffic. You can use the routing profile to tunnel or split-tunnel traffic from employees and wired
devices. To meet the different traffic engineering requirements, you can use a combination of the routing
profile and source NAT ACLs in user roles.
n
Role-based access for wired and wireless devices.
n
BYOD for employees on the employee SSID with ClearPass.
n
In hierarchical mode deployments, deny corporate access to any rogue clients on the IAPs uplink device
using the “Restrict Corporate Access” feature on Aruba Instant.
n
Modify split-DNS behavior according to the requirements. For more information see DNS Handling in an
Aruba Instant-VPN Network.
n
As an option, guest access using a guest SSID that is mapped to a local-mode VLAN and captive portal
authentication. Guests can be supported with the internal captive portal page and guest management features
of Aruba Instant or ClearPass Guest Solution. For more information, see the Aruba Instant User Guide that is
available at the Aruba support website.
n
As an option, authentication survivability with ClearPass to address WAN failures.
119 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
An Aruba Instant network that is configured for Instant-VPN establishes only a single IPsec tunnel from the
master AP of the cluster to the WLAN controller. That is, an Aruba Instant cluster does not build separate IPsec
tunnels for each SSID or wired port that is configured for Instant-VPN.
l
Logical design for flat mode design: The logical design for this deployment includes the following
recommendations and components:
n
In a multi-AP flat mode design, the trusted managed switch that connects the IAPs must support all VLANs
that are used by the Aruba Instant network. For example, if the Aruba-Instant network is configured with a
distributed L3 mode VLAN with VLAN ID 100 for corporate access, the trusted uplink switch that connects the
IAPs must support this VLAN.
n
In a multi-AP flat mode design, you can connect the corporate wired devices to the trusted managed switch.
The wired devices that connect to the switch have corporate access as long as the switch port is on the
Instant-VPN mode VLAN. For example, if the Aruba-Instant network is configured with a distributed L3 mode
VLAN with VLAN ID 100 for corporate access, the trusted uplink switch ports that are used for wired devices
must be on VLAN 100.
n
In flat mode deployment, disable the “Restrict Corporate Access” feature.
n
All other logical design elements for flat mode design are same as for the hierarchical mode design.
Designing Instant-VPN Deployments is an example of a multi-AP deployment with a single data center and
redundant WLAN controllers.
Figure 52 Multi-AP deployment with a single data center with WLAN controller redundancy
The following sections provide an overview of the basic IAP, data center, and uplink switch configurations that are
necessary to design a multi-AP deployment with a single data center. The example that is described in the following
sections uses distributed L3 mode for employees and wired devices.
IAP Setup (multi-AP Deployment with a Single Data Center)
The key configurations that are required for the IAP are listed below:
1. Set up the VPN primary IP configuration.
2. Define the routing profile. This profile specifies the traffic that must be tunneled to the data center. For more
information about routing profiles, see Configuring an IAP for Instant-VPN Deployment.
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 120
3. Configure the enterprise domains on the IAP for split-DNS.
4. Configure the DHCP server for appropriate Instant-VPN mode. For example, set up a distributed L3 mode DHCP
configuration for the employee SSID and corporate wired devices.
5. Configure the authentication servers for user authentication. For example, set up a RADIUS server configuration
for ClearPass for employee authentication, BYOD, and wired device authentication.
6. Enable DRP in multi AP Instant-VPN deployments to tunnel the RADIUS traffic from member IAPs. When DRP
is enabled in a multi-AP network, the RADIUS traffic is sourced with the inner IP address of the IPsec tunnel or
the VC IP address, based on the routing profile definition.
7. Configure the employee SSID with the appropriate authentication, RADIUS servers, and user roles and map it to
the VLAN in the appropriate Instant-VPN mode. For example, map the employee SSID and the wired ports to the
distributed L3 mode VLAN that you set up in step 4.
8. For some environments, set up a combination of a routing profile and a source NAT ACL in the user roles to meet
the different traffic engineering requirements. For example, consider an environment that requires all traffic for
corporate wired devices to be tunneled, but employee Internet traffic to be split-tunneled. In this case, set up a
routing profile with a “0.0.0.0 0.0.0.0 <gateway IP>” configuration and an employee user role that tunnels traffic
for corporate destinations but source NATs traffic for all other destinations. (That is, set up an ACL with a permit
action for corporate destinations followed by an ACL with a source NAT action for Internet destinations).
9. In flat mode design, disable the “Restrict Corporate Access” setting that is part of the Firewall Settings screen.
By default, the “Restrict Corporate Access” setting is disabled.However, in hierarchical design, you can enable
the “Restrict Corporate Access” setting to restrict corporate access to only those devices that are downstream
from the root IAP.
10. In environments that require guest access, perform the following steps:
n
Set up a DHCP configuration in local mode.
n
Map the configuration to the guest SSID that is set up for captive portal authentication.
11. As an option for hierarchical mode design, configure uplink redundancy. In hierarchical mode, the redundant
uplink must be on the root IAP.
121 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
Data Center Configuration (Multi-AP Deployment with a Single Data Center)
Aruba recommends that you plan for redundancy. This procedure describes a redundant WLAN controller
configuration.
The key configurations that are required on the WLAN controller are listed below:
1. Configure the WLAN controllers with the basic settings such as VLANs, IP addresses, and the required license.
2. Configure the WLAN controller pair for master redundancy. For information about configuring master redundancy,
see the Aruba Campus Networks Validated Reference Design or the Aruba User Guide at the Aruba support
website.
3. Define the VPN address pool that is used to assign inner IP addresses to the IPsec tunnel that is established at
the branch.
4. Add IAPs in the branch to the RAP whitelist. This whitelist can be offloaded to a CCPM or other servers that
support authorization. For more information, see Adding IAPs to RAP Whitelist.
5. Configure the appropriate VLANs for branches that are deployed in Layer 2 mode. (This step is required only if the
branch is configured for centralized L2 or distributed L2 mode). For more information, see Configuring VLANs for
Layer 2 Modes.
6. Configure OSPF route redistribution of Layer 3 branch routes. (This step is required only if the branch is
configured for distributed L3 mode). For more information, see Configuring OSPF Route Redistribution of Layer 3
Branch Routes.
7. As an option, configure the WLAN controller to perform source NATing of 802.1X and RADIUS traffic from IAP
branches. However, if RFC 3576-based CoA is a requirement, RADIUS traffic from the IAP branches must not
be source NATed at the WLAN controller. For CoA capabilities, all IP addresses and subnets that are used in the
VPN address pool must be added to the RADIUS server. For more information, see Configuring the Controller to
Perform Source NATing for 802.1X and RADIUS Traffic from Branches.
Uplink Switch Setup (Multi-AP Deployment with a Single Data Center)
In a flat mode design, the trusted managed switch that connects the IAPs in the branch must support the client
VLANs that are defined in the Aruba Instant network. This support is required because any client traffic that must be
forwarded from the member IAP to the master AP is tagged with the appropriate client VLAN. For example, if the
Aruba-Instant network is configured with a distributed L3 mode VLAN with VLAN ID 100 for the employee SSID, the
trusted uplink switch must support VLAN 100. This configuration allows for traffic from the clients that are connected
to the employee SSID on the member APs to be forwarded to the master AP with VLAN tag 100. (VPN tunneling or
source NATing of client traffic is performed by the master AP). For more information about traffic forwarding
behavior, see Traffic Flows in an Aruba Instant Cluster.
Multi-AP Deployment with Multiple Data Centers
For the deployment of a multi-AP branch with multiple data centers, the common components and requirements are
as follows:
l
Branches that require more than one IAP
l
Multiple data center deployment with geographical redundancy requirement
l
Secure wireless access for employees and access to corporate resources using VPN
l
Optional guest access in certain deployments
l
Optional support for corporate wired devices such as printers
l
WAN uplink (Ethernet or 3G/4G modem)
The typical Instant-VPN design and configuration for this deployment is as follows:
l
Physical design: The physical design for this deployment is a multi-AP design. For branches that require 2 to 4
IAPs, use either hierarchical or flat mode design for AP deployment. In branches with 5 or more IAPs, use flat
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 122
mode design. Flat mode deployment requires a trusted managed switch to connect the IAPs. For more
information about multi-AP design, see Multi AP Branch. Uplink redundancy for the branch network is optional.
For information about uplink redundancy, see the Aruba Instant User Guide that is available at the Aruba support
website.
l
Data center redundancy: Based on the total number of branch sites, select the appropriate WLAN controller
platform. Since this deployment requires geographical redundancy, the multi data center redundancy model
applies to this deployment. Aruba recommends that you consider redundant master WLAN controllers in the
individual data centers of a multi data center design to safeguard against controller failure in the individual data
centers. For more information, see Redundancy Design for Aruba Instant-VPN Deployments.
l
Logical design for hierarchical mode design: The logical design for this deployment includes the below
recommendations and components:
n
If deployed in hierarchical mode, the member IAPs connect to the downlink ports of the root IAP. Configure
the wired ports of the root IAP to which the member IAP connects with a VLAN in local mode. These ports
must be in trunk mode with the native VLAN set to the local mode VLAN that is used for member IAPs. This
setup allows the IAPs in hierarchical mode to support multiple VLANs.
n
In hierarchical mode, you can use the wired ports of the root IAP for corporate wired devices.
n
Employee SSIDs with the appropriate authentication. The VLAN that is used for an employee SSID must
belong to the appropriate Instant-VPN mode. Aruba recommends that you use distributed L3 mode for all
deployments except for those that require support for multicast traffic from the data center to the branch. You
can use centralized L3 modes for deployments that require a centralized DHCP server. The VLAN IP address
that is configured in the centralized L3 mode definition is different for each branch, so you must either modify
the AirWave configuration on a per-branch level during the initial deployment, or use a separate group in
AirWave for each branch. For more information about Instant-VPN modes, see Understanding Instant-VPN
Modes.
n
Wired ports that are used for corporate devices with the appropriate authentication. The VLAN that is used for
corporate wired devices must belong to the appropriate Instant-VPN mode. Aruba supports role-based
access, so separate VLANs are not required for employees and corporate devices. Both the employee SSID
and the wired ports for corporate devices can use the same VLAN in Instant-VPN mode. You can restrict
access using appropriate user roles.
n
As an option, a separate VLAN in the appropriate Instant-VPN mode for wired clients. For example, if you use
“10.10.0.0 /16” with 50 clients per branch for an employee SSID in Layer 3 mode, you can set up a separate
address range of “10.11.0.0 /16” with 5 clients per branch for wired devices and a separate VLAN in distributed
L3 mode for the wired clients.
n
Split-tunnel traffic. You can use the routing profile to tunnel or split-tunnel traffic from employees and wired
devices. To meet the different traffic engineering requirements, you can use a combination of the routing
profile and source NAT ACLs in user roles.
n
Role-based access for wired and wireless devices.
n
BYOD for employees on the employee SSID with ClearPass.
n
In hierarchical mode deployments, deny corporate access to any rogue clients on the IAPs uplink device
using the “Restrict Corporate Access” feature on Aruba Instant.
n
Modify split-DNS behavior according to the requirements. For more information see DNS Handling in an
Aruba Instant-VPN Network.
n
As an option, guest access using a guest SSID that is mapped to a local-mode VLAN and captive portal
authentication. Guests can be supported with the internal captive portal page and guest management features
of Aruba Instant or ClearPass Guest Solution. For more information, see the Aruba Instant User Guide that is
available at the Aruba support website.
n
As an option, authentication survivability with ClearPass to address WAN failures is supported.
123 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
An Aruba Instant network that is configured for Instant-VPN establishes only a single IPsec tunnel from the
master AP of the cluster to the WLAN controller. That is, an Aruba Instant cluster does not build separate IPsec
tunnels for each SSID or wired port that is configured for Instant-VPN.
l
Logical design for flat mode design: The logical design for this deployment includes the following
recommendations and components:
n
In a multi-AP flat mode design, the trusted managed switch that connects the IAPs must support all VLANs
that are used by the Aruba Instant network. For example, if the Aruba-Instant network is configured with a
distributed L3 mode VLAN with VLAN ID 100 for corporate access, the trusted uplink switch that connects the
IAPs must support this VLAN.
n
In a multi-AP flat mode design, you can connect the corporate wired devices to the trusted managed switch.
The wired devices that connect to the switch have corporate access as long as the switch port is on the
Instant-VPN mode VLAN. For example, if the Aruba-Instant network is configured with a distributed L3 mode
VLAN with VLAN ID 100 for corporate access, the trusted uplink switch ports that are used for wired devices
must be on VLAN 100.
n
In flat mode deployment, disable the “Restrict Corporate Access” feature.
n
All other logical design elements for flat mode design are same as for the hierarchical mode design.
Designing Instant-VPN Deployments is an example of a mulrti-AP deployment with multiple data centers, each of
which include redundant WLAN controllers.
Figure 53 Multi-AP deployment with multiple data centers with WLAN controller redundancy
The following sections provide an overview of the basic IAP and data center configurations that are required to
design a multi-AP deployment with a single data center. The example that is described in the following sections uses
distributed L3 mode for employees and wired devices.
IAP Setup (multi-AP Deployment with Multiple Data Centers)
The key configurations that are required for the IAP are listed below:
1. Set up the VPN primary IP configuration.
2. Set up the VPN secondary IP configuration.
3. Set up a fast failover configuration if the environment requires a fast failover.
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 124
4. Define the routing profile. This profile specifies the traffic that must be tunneled to the data center. The routing
profile must have two sets of routes. One points to the primary data center and the other points to the backup data
center. The IAP selects a route based on the data center that it is terminating on. For example, if all 10.0.0.0 /8
networks must be tunneled back to the data center, the routing profile must have two routes: “10.0.0.0 255.0.0.0
<controller in data center 1>” and “10.0.0.0 255.0.0.0 <controller in data center 2>”. For more information about
routing profiles, see Configuring an IAP for Instant-VPN Deployment.
5. Configure the enterprise domains on the IAP for split-DNS.
6. Configure the DHCP server for appropriate Instant-VPN mode. For example, set up a distributed L3 mode DHCP
configuration for the employee SSID and corporate wired devices.
7. Configure the authentication servers for user authentication. For example, set up a RADIUS server configuration
for ClearPass for employee authentication, BYOD, and wired device authentication.
8. Enable DRP in multi-AP Instant-VPN deployments to tunnel the RADIUS traffic from member IAPs. When DRP
is enabled in a multi-AP network, the RADIUS traffic is sourced with the inner IP address of the IPsec tunnel or
the VC IP address, based on the routing profile definition.
9. Configure the employee SSID with the appropriate authentication, RADIUS servers, and user roles and map it to
the VLAN in the appropriate Instant-VPN mode. For example, map the employee SSID and the wired ports to the
distributed L3 mode VLAN that you set up in step 6.
10. For some environments, set up a combination of a routing profile and a source NAT ACL in the user roles to meet
the different traffic engineering requirements. For example, if all traffic for corporate wired devices must be
tunneled but employee Internet traffic must be split-tunneled, set up a routing profile with a “0.0.0.0 0.0.0.0
<gateway IP>” configuration and an employee user role that tunnels traffic for corporate destinations but source
NATs traffic for all other destinations (that is, set up an ACL with a permit action for corporate destinations
followed by an ACL with a source NAT action for Internet destinations).
11. In flat mode design, disable the “Restrict Corporate Access” setting that is part of the Firewall Settings screen.
By default, the “Restrict Corporate Access” setting is disabled. However, in hierarchical design, you can enable
the “Restrict Corporate Access” setting to restrict corporate access to only those devices that are downstream
from the root IAP.
12. In environments that require guest access, perform these steps:
n
Set up a DHCP configuration in local mode.
n
Map the configuration to the guest SSID that is set up for captive portal authentication.
125 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
13. As an option for hierarchical mode design, configure uplink redundancy. In hierarchical mode, the redundant
uplink must be on the root IAP.
Data Center Configuration (Multi-AP Deployment with Multiple Data Centers)
In addition to geographical redundancy, Aruba strongly recommends that you consider WLAN controller redundancy
in each data center of a geographically redundancy design. If a WLAN controller failure occurs at the primary data
center, the backup WLAN controller in the primary data center takes over, preventing the branch network from
switching over to the backup data center. The following procedure describes a redundant WLAN controller
configuration for a data center.
The key configurations that are required on the WLAN controller are listed below:
1. Configure the WLAN controllers with the basic settings such as VLANs, IP addresses, and the required license.
2. Configure the WLAN controller pair for master redundancy. For information about configuring master redundancy,
see the Aruba Campus Networks Validated Reference Design or Aruba User Guide at theAruba support
website.
3. Define the VPN address pool that is used to assign inner IP addresses to the IPsec tunnel that is established at
the branch. Aruba recommends that you use a routable address space for the VPN address pool. For more
information, see Defining the VPN Pool on a WLAN Controller. Aruba also recommends that you set up a unique
VPN address pool for individual WLAN controllers in every data center.
4. Add IAPs in the branch to the RAP whitelist. This whitelist can be offloaded to a CCPM or other servers that
support authorization. For more information, see Adding IAPs to RAP Whitelist.
5. Configure the appropriate VLANs for branches that are deployed in Layer 2 mode. (This step is required only if the
branch is configured for centralized L2 or distributed L2 mode). For more information, see Configuring VLANs for
Layer 2 Modes.
6. Configure OSPF route redistribution of Layer 3 branch routes. (This step is required only if the branch is
configured for distributed L3 mode). For more information, see Configuring OSPF Route Redistribution of Layer 3
Branch Routes.
7. As an option, configure the WLAN controller to perform source NATing of 802.1X and RADIUS traffic from IAP
branches. However, if RFC 3576-based CoA is a requirement, RADIUS traffic from the IAP branches must not
be source NATed at the WLAN controller. For CoA capabilities, all IP addresses and subnets that are used in the
VPN address pool must be added to the RADIUS server. For more information, see Configuring the Controller to
Perform Source NATing for 802.1X and RADIUS Traffic from Branches.
Uplink Switch Setup (Multi-AP Deployment with Multiple Data Centers)
In a flat mode design, the trusted managed switch that connects the IAPs in the branch must support the client
VLANs that are defined in the Aruba Instant network. This support is required because any client traffic that must be
forwarded from the member IAP to the master AP is tagged with the appropriate client VLAN. For example, if the
Aruba-Instant network is configured with a distributed L3 mode VLAN with VLAN ID 100 for the employee SSID, the
trusted uplink switch must support VLAN 100. This configuration allows for traffic from the clients that are connected
to the employee SSID on the member APs to be forwarded to the master AP with VLAN tag 100 (VPN tunneling or
source NATing of client traffic is performed by the master AP). For more information about traffic forwarding
behavior, see Traffic Flows in an Aruba Instant Cluster.
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 126
Designing Home Office Deployments with Aruba Instant
Employing a home-based work force is becoming common across many verticals. The cost saving on facility
expenses and the ability to source talent from a broad pool of applicants with specialized skill sets is an attractive
proposition. The affordability and availability of high speed broadband services has allowed many companies to take
advantage of the home-based workforce. In addition to employing a home-based work force, many companies want
to increase the productivity of their conventional office-based employees by providing them secure corporate access
from their homes.
One of the key requirements of a work-from-home model is to equip the work-from-home employees with all the
necessary tools and connect them securely to the corporate resources. The key requirement for these types of
deployments is the ability to securely and effortlessly extend the corporate resources to the homes of remote
workers. Aruba Instant with its zero-touch provisioning and VPN feature set is the ideal solution for these
deployments.
A home office deployment has the following requirements:
l
Wired and wireless access to laptops and VDI terminals
l
Wireless access to BYOD devices
l
Wired access for phones
l
Wired access to printers that are provided by the company or the ability to allow users to securely print to a
personal printer on the home network
l
Secure access to corporate resources
The solution and design for this deployment is similar to that of a single-AP branch office deployment. For the design
and recommendations of a single-AP branch office deployment, see Single-AP Branch with a Single Data Center.
Configuring the WLAN Controller for Instant-VPN Deployment
As discussed in Understanding Instant-VPN (Aruba Instant-VPN in a Nutshell), the WLAN controller considers the
IAP that establishes the VPN tunnel as a VPN client and all configurations such as SSIDs, user roles,
authentication servers, and WIPS are local to the Aruba Instant network.
To configure the WLAN controller for Instant-VPN deployments, perform the following steps:
1. Define the VPN address pool to assign inner IP addresses to the IPsec tunnel that is established by the IAP.
2. Add IAPs in the branch to the RAP whitelist. You can offload the whitelist to a CCPM or other server that
supports authorization.
3. Configure the appropriate VLANs for branches that are deployed in Layer 2 mode. (This step is required only if the
branch is configured for centralized L2 mode or distributed L2 mode).
4. Configuring OSPF route redistribution of Layer 3 branch routes (This step is required only if the branch is
configured for distributed L3 mode or centralized L3 mode).
5. As an option, configure the WLAN controller to perform source NATing of 802.1X and RADIUS traffic from an
IAP branch.
Each of these steps is described in detail in the following sections:
In small deployments, with a single master WLAN controller and a VRRP backup WLAN controller, the upstream
router can use a static route that points to the WLAN controller as the next hop for Layer 3 branch subnets.
However, you cannot use static routes in a multi-controller e
For classic RAPs on ArubaOS, the WLAN controller must be configured with the appropriate AP groups, which
define the SSIDs, user roles, WIPS settings, ARM settings, regulatory domain settings, and so on. However, the
AP group settings do not apply to an Instant-VPN.
127 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
Aruba recommends that you run ArubaOS 6.3 or greater for Aruba Instant-VPN deployments.
Defining the VPN Pool on a WLAN Controller
Every IAP (Instant-VPN), RAP (classic), Virtual Intranet Access (VIA) client, and third-party VPN client that
authenticates and successfully terminates an IPsec tunnel on the VPN server module of the WLAN controller is
given a valid inner IP address. This inner IP address is issued from the address pool that is configured in the VPN
server module on the WLAN controller. More than one pool can be configured. Aruba recommends that you use
dedicated controllers for Instant-VPN because terminating a combination of Instant-VPN, classic RAPs, and VIA
clients on the same controller alters the scale limit of the controller and complicates the calculation of scale limits.
However, for testing purposes or during migration from a classic RAP to Instant-VPN architecture, you might prefer
to use the same controller for classic RAPs and Instant-VPNs. In such cases, you can use separate VPN
addresses pools for Instant-VPN and classic RAPs.
If only a single pool is configured, all the VPN clients (Instant-VPN, RAPs, and VIA) are issued an inner IP address
from the same pool. When multiple address pools are available, you can configure the controller to use distinct VPN
pools for Instant-VPN, RAPs, and VIA. You can achieve this configuration by appending a VPN pool to the role that
is assigned to the Instant-VPN, classic RAPs, and VIA clients. For Instant-VPN, the default role is “default-vpn-role”
for the inner IP address.
Aruba recommends that you use a routable IP subnet as the VPN pool because this allows you to access the local
WebUI of Aruba Instant from the data center. Having a routable address pool is also important for RADIUS
authentication. The inner IP address of the IAP is used as the RADIUS packet source IP address for
authentication servers in the data center, unless the WLAN controller is configured to source NAT the RADIUS
traffic from Aruba Instant branches. If RFC 3576-compliant CoA is a requirement, the RADIUS traffic form the
Aruba Instant branch must not be source NATed at the WLAN controller and the IP address space that is used for
the VPN address pool must be added to the NAS client list on the centralized authentication server.
When distinct VPN pools are not defined, the WLAN controller automatically uses the first pool in the VPN address
pool. When this pool expires, the next pool in the list is used, and so on. If the VPN address pool is exhausted, new
IAPs (Instant-VPN), RAPs (classic), or VIA clients cannot establish the IPsec tunnel until the required number of IP
addresses are added to the pool.
The VPN address pools are not synchronized from the active WLAN controller to its VRRP backup WLAN
controller during database synchronization. Create VPN address pools individually on both the active and standby
master WLAN controllers. The VPN pools that are used on the active and the VRRP backup WLAN controller can
be same or different. If the same VPN pool is used on active and the VRRP backup WLAN controller, the
upstream router must use the virtual IP address that is used between the two WLAN controllers as the next hop
address to reach this address pool.
Below figures and the corresponding CLI command examples illustrate how to configure a VPN address pool and
append it to a user role.
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 128
Figure 54 Configuring VPN address pools
The CLI command to configure VPN address pools is as follows:
!
ip local pool "iap-pool-1" "10.68.61.6" "10.68.61.254"
ip local pool "iap-pool-2" "10.68.62.6" "10.68.62.254"
!
Figure 55 Appending a VPN address pool to a user role
The CLI command to configure VPN user roles is as follows:
!
user-role "default-vpn-role"
pool l2tp "iap-pool-2"
!
129 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
Adding IAPs to RAP Whitelist
When an IAP establishes an IPsec tunnel to the WLAN controller, Aruba TPM certificates in the IAP and WLAN
controller are used for IPsec authentication. After authenticating the IAP, the WLAN controller authorizes the IAP by
comparing the CN in the certificate (the CN in the certificate is the MAC address of the IAP) to the MAC address in
the RAP whitelist. If the MAC address is not present in the RAP whitelist, the IAP is not allowed to terminate its
IPsec tunnel on the WLAN controller. This ensures that only an authorized IAP can establish the IPsec tunnel and
not any Aruba AP.
You can offload the RAP whitelist that is used for authorization of the IAPs to ClearPass or to an external server
that supports authorization.
The RAP whitelist on the WLAN controller has the following fields:
l
AP MAC address (required): The MAC address of the IAP that is authorized to establish an IPsec tunnel to the
WLAN controller.
l
User Name (optional): The name of the user or branch to which the IAP belongs.
l
AP Group (required): Although the AP group is not required for IAPs, the RAP whitelist requires that you use this
field to add the IAP to the database. Select the default AP group or any other AP group.
l
AP Name (optional): A name for the IAP.
l
Description (optional): A short description about the IAP.
l
Revoked (optional). You can use this field to revoke the secure status of an IAP.
l
IP address (optional): You can use this field to assign a specific IP address from the VPN address pool to a
specific IAP.
Below figure is a screen shot of the screen that lets you configure the whitelist on the WLAN controller.
Figure 56 Configuring the whitelist on the WLAN controller
The CLI command to configure the whitelist on the WLAN controller is as follows:
whitelist-db rap add mac-address 94:b4:0f:cb:dc:98 ap-group default remote-ip 192.168.100.100
show whitelist-db rap
The ap-group parameter is not used for any configuration, but needs to be configured. It can be any valid string, as it
is not used. If an external whitelist is being used, the AP MAC address needs to be saved in the Radius server as a
lower case entry without any delimiter.
The remote-ip parameter is optional. If you specify an IP here, the particular IP always chooses that IP address as
the inner IP of the IPSec tunnel from the VPN pool.
whitelist-db rap add mac-address 94:b4:0f:cb:dc:98 ap-group default ?
ap-name AP-Name
description Description
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 130
full-name Full Name
remote-ip IP-address assigned to remote peer
Rest of the arguments are present but are optional and do not provide any specific configuration enhancements. This
CLI is used for RAP as well, where these configurations provide additional enhancements, but in context of IAP
VPN, just configure ap-group and that should get the tunnel up.
When you use IAPs that are running Aruba InstantOS 4.0 or greater and Aruba WLAN controllers that are running
ArubaOS 6.4 or greater in a configuration with Auto-GRE, the WLAN controllers allow tunnels only from IAPs that
are configured through AirWave or Aruba Central. Tunnels are not allowed from other IAPs even if they are on the
RAP whitelist. This measure provides additional security. To allow tunnels from IAPs that are configured through
the local WebUI of Aruba Instant, use the WLAN controller CLI to add the IAPs to the “iap trusted-branch-db” list.
For example,
iap trusted-branch-db ? add Configure an IAP trusted branch entry
allow-all Allow all branches as trusted
del Delete an IAP trusted branch entry
del-all Delete all trusted branch entries
Configuring VLANs for Layer 2 Modes
In centralized L2 mode, the master AP adds the appropriate VLAN tag to the client traffic that is destined for the data
center and sends it to the WLAN controller through the IPsec-GRE tunnel. When the WLAN controller receives the
packet, it inspects the tag and forwards the packet accordingly. The VLAN that is defined in the centralized Layer 2
configuration of an IAP must exist on the WLAN controller. The VLAN that is defined on the WLAN controller can be
configured as a Layer 2 VLAN (that is, no IP address is configured on the VLAN interface) or a Layer 3 VLAN (that is,
an IP address is configured on the VLAN interface).
Depending on your network setup, you must enable the inter-VLAN routing between the VLANs on the WLAN
controller.
Configuring OSPF Route Redistribution of Layer 3 Branch Routes
In Layer 3 mode, each branch has a dedicated subnet. Only the WLAN controller can detect the branch each subnet
belongs to. The following example describes the need for OSPF redistribution:
Consider that an organization with 100 branches has designed an Instant-VPN network for geographical redundancy
and fast VPN failover. In such a network, the primary host (WLAN controller) is in data center 1 (DC1) and the
backup host (WLAN controller) is in data center 2 (DC2). Under ideal conditions, all 100 branches terminate on the
primary host in DC1. If branch 10 has WAN problems with DC1, it fails over to DC2. Now, 99 branches terminate on
DC1 but one branch terminates on DC2. This means that 99 branches can be reached through the primary host in
DC1, but the traffic to branch 10 goes through the backup host in DC2. The network that connects the two data
centers must be updated with the appropriate route information that could change dynamically.
Using OSPF and redistributing routes appropriately ensures that routing does not break. When OSPF redistribution
is enabled, the WLAN controller redistributes routes for the branches that are active on that WLAN controller. Even
with fast failover enabled, the OSPF process on the WLAN controller redistributes a branch route only if the IPsec
tunnel is in active state. This is because the master AP exchanges the route Add message, which is used to register
the subnet in the branch, only with the WLAN controller on which the VPN tunnel is active. For information about
configuring OSPF on the Aruba controller, see the ArubaOS User Guide at the Aruba support website.
131 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
By default, a master AP establishes a single IPsec tunnel, either to the primary or to the backup host. If the
communication to one host fails, the master AP establishes an IPsec tunnel to the other host. However, if fast
failover is enabled, the master AP can establish a backup VPN tunnel even while the primary VPN tunnel is still
up. The primary tunnel is in an active state and the backup tunnel is in an idle state. The purpose of fast failover is
to reduce the failover time by eliminating the tunnel setup time during failover.
The CLI command to redistribute Instant-VPN branch routes using OSPF is as follows:
!
router ospf redistribute rapng-vpn
!
Use the show ip route command on the WLAN controller to display the Instant-VPN routes that are redistributed by
the WLAN controller. All the routes with a “V” flag in the command output represent Instant-VPN branch routes. The
below sample output shows Instant-VPN branch routes:
(Aruba-Controller) #show ip route
Codes: C - connected, O - OSPF, R - RIP, S - static
M - mgmt, U - route usable, * - candidate default, V - RAPNG VPN
Gateway of last resort is Imported from DHCP to network 0.0.0.0 at cost 10
Gateway of last resort is Imported from CELL to network 0.0.0.0 at cost 10
Gateway of last resort is Imported from PPPOE to network 0.0.0.0 at cost 10
Gateway of last resort is 10.15.148.254 to network 0.0.0.0 at cost 1
S* 0.0.0.0/0 [1/0] via 10.15.148.254*
V 12.12.2.0/24 [10/0] ipsec map
V 12.12.12.0/25 [10/0] ipsec map
V 12.12.12.32/27 [10/0] ipsec map
V 50.40.40.0/24 [10/0] ipsec map
V 51.41.41.128/25 [10/0] ipsec map
V 53.43.43.32/27 [10/0] ipsec map
V 54.44.44.16/28 [10/0] ipsec map
C 9.9.9.0/24 is directly connected, VLAN9
C 10.15.148.0/24 is directly connected, VLAN1
C 43.43.43.0/24 is directly connected, VLAN132
C 42.42.42.0/24 is directly connected, VLAN123
C 44.44.44.0/24 is directly connected, VLAN125
C 182.82.82.12/32 is an ipsec map 10.15.149.69-182.82.82.12
C 182.82.82.14/32 is an ipsec map 10.17.87.126-182.82.82.14
When an Instant-VPN branch in distributed L3 mode fails over from one data center to another, the time that OSPF
route convergence requires depends on the user idle timeout setting on the WLAN controller. For faster
convergence in Instant-VPN deployments, Aruba recommends that you set the user idle timeout to 30 seconds.
Configuring the Controller to Perform Source NATing for 802.1X and RADIUS Traffic from
Branches
To establish an IPsec connection with the WLAN controller, a VPN client (IAP, RAP, VIA, or third-party VPN client)
submits the appropriate authentication credentials during the IPsec establishment process. The VPN server on the
WLAN controller validates these credentials and assigns a user role to the authenticated VPN clients. This user role
is defined by the VPN authentication profile on the WLAN controller. The four predefined VPN authentication profiles
are:
l
default: For third-party VPN clients
l
default-cap: For campus APs (CAPs)
l
default-rap: For RAPs
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 132
l
default-iap: For IAPs
You cannot add additional VPN profiles. The “default”, “default-iap,” and “default-rap” profiles are configurable, but
the “default-cap” profile cannot be edited.
To bring up the IAP VPN tunnel, no licenses are needed on the controller. However, to bring up the default-vpn-role,
for editing in the controller, PEFV license must be installed:-
Before installing PEFV license:-
After installing PEFV license:-
The “Add” icon to add a new role, and “default-vpn-role” for editing are now available.
The IPsec authentication between the WLAN controller and the IAP is based on Aruba TPM certificates on the
WLAN controller and the IAP. The TPM certificate-based authentication ensures that the IAP that establishes a
VPN connection to the WLAN controller is an Aruba IAP. This process does not guarantee that the authenticated
Aruba IAP is authorized. To ensure that the IAPs that connect to the WLAN controller are authorized, the RAP
whitelist is used. The RAP whitelist ensures that only authorized IAPs can establish a VPN tunnel to the WLAN
controller. After authenticating a RAP using the TPM certificate, the WLAN controller compares the Common Name
(CN) in the certificate to the list of authorized MAC addresses in the RAP whitelist. (The CN is the MAC address of
the IAP that presents the certificate to the WLAN controller.) If a MAC address is not present in the RAP whitelist,
the IAP is not allowed to terminate its IPsec tunnel on the WLAN controller.
ArubaOS 6.3 and greater allow the use of a CPPM or an external RADIUS server to authorize IAPs attempting to
connect to the WLAN controller. By default, the internal RAP whitelist database is used to authorize IAPs.
The “check certificate common name against AAA server” setting must be enabled to allow authorization of the
MAC address in the certificate CN against the RAP whitelist. If this setting is disabled, IAPs are authorized even
if their MAC addresses are not in the RAP whitelist. Aruba recommends that you enable this setting in all
deployments to ensure that only authorized IAPs connect to the WLAN controller.
133 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
After successfully authenticating and authorizing an IAP, the WLAN controller assigns the default role defined in the
“default-iap” VPN authentication profile. The default role defined under the “default-iap” VPN authentication profile is
the predefined “default-vpn-role” that has an “allow-all” firewall policy. All traffic from an IAP-VPN tunnel is forwarded
or routed by the WLAN controller.
In Instant-VPN deployments in which the authentication server is located in the data center, the IAP tunnels all
authentication traffic to the WLAN controller using the inner IP address of the IAPs IPsec tunnel. Because the
source IP address for RADIUS traffic from a master AP in the branch is the inner IP address of the IPsec tunnel, you
must add all IP addresses that are used in the VPN address pool as RADIUS clients on the RADIUS server. In
some environments, a security policy would not allow you to add all addresses in the VPN pool to the NAS client list
on the authentication server. In these situations, you can add a rule that source NATs all RADIUS traffic with the IP
address of the WLAN controller. With this rule, you only need to configure the WLAN controller as the NAS client on
the RADIUS server. Place the source NAT rule above the “allow-all” rule in the “default-vpn-role.”
Enable Dynamic RADIUS Proxy (DRP) on multi-AP Aruba Instant networks to ensure that the IAP tunnels the
authentication traffic to the RADIUS server in the data center. When DRP is enabled, RADIUS traffic that is
destined for a corporate authentication server is sourced with the inner IP address of the IPsec tunnel but RADIUS
traffic that is destined for local authentication servers is forwarded using the VC IP address.
The ArubaOS controller does not require any licenses to terminate IAP-VPN tunnels. However, a PEFV license is
needed to change the firewall policies or the user role that is applied to IAPs. For more information, see Licensing.
Configuring the WLAN Controller for Instant-VPN Deployment figure shows how to set up source NATing for
RADIUS traffic with the IP address of the WLAN controller.
Figure 57 Configuring a firewall policy for source NATing of RADIUS traffic
Configuring the WLAN Controller for Instant-VPN Deployment figure shows how to set up a user role (“iap-role”) with
the appropriate firewall policy to allow source NATing of RADIUS traffic.
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 134
Figure 58 Configuring a user role for source NATing of RADIUS traffic
Below figure shows how you can apply a role to the “default-iap” VPN authentication profile.
Figure 59 Applying a role to the “default-iap” VPN authentication profile
Use the below command on controller CLI to find out IAP to user role mapping:(Aruba7030) #show user
Users
----IP MAC Name Role Age(d:h:m)
----------
------------
------
192.168.200.106 00:00:00:00:00:00
192.168.100.101 00:00:00:00:00:00
----
Auth
----------
----
logon 01:03:48 VPN 94:b4:0f:cb:dc:98 iap-role 135 | Designing Distributed Enterprise Networks with Aruba Instant
00:05:59 VPN Aruba Instant Validated Reference Design
VPN link AP name Roaming
--------
Essid/Bssid/Phy
Profile Forward mode Type Host Name
------- ------- --------------- ------------------ ---- --------N/A tunnel 192.168.200.106 N/A default-iap
tunnel User Entries: 2/2
Curr/Cum Alloc:2/3 Free:0/1 Dyn:2 AllocErr:0 FreeErr:0
In the above scenario, IAP VC’s IPSec’s inner IP, 192.168.100.101 is using the role, “iap-role” and profile is “defaultiap”. 192.168.200.106 is the actual IP of the same VC.
If CoA is a requirement, do not perform source NATing for RADIUS. For RFC 3576-compliance, CoA messages
are initiated by the RADIUS server. Therefore, do not configure a rule on the WLAN controller to source NAT
RADIUS traffic. If the RADIUS server is in the data center, for RFC 3576-compliance, list the inner IP addresses
that are used for the IPsec tunnels as RADIUS clients.
Configuring an IAP for Instant-VPN Deployment
You can configure an IAP network locally through the Instant WebUI, AirWave, or Aruba Central. Irrespective of how
you configure an IAP network, the entire IAP network configuration resides on the IAPs in a cluster. An IAP uses a
distributed architecture, so an IAP network does not require a physical controller to provide the configured WLAN
services. A physical Aruba WLAN controller is required only for terminating VPN tunnels from IAP networks at
branch locations. The WLAN controller in the data center functions only as a VPN concentrator and it is not required
for IAP branches that do not require VPN functionality.
In addition to configuring basic settings such as user roles and SSIDs, an IAP network requires you to perform the
following configuration tasks for Instant-VPN operation:
l
Defining the VPN host settings
l
Configuring the routing profile
l
Configuring DHCP profiles for different Instant-VPN modes
l
Configuring an SSID or wired port for Instant-VPN
l
Enabling Dynamic RADIUS Proxy (DRP)
l
Configuring enterprise domains
The sections below describe these tasks in detail.
Defining the VPN Host Settings
The VPN endpoint on which a master AP terminates its VPN tunnel is considered the host. You can configure a
master AP in an IAP network with two hosts; a primary and a backup. The primary and backup host configuration
provides VPN redundancy. Typically, the primary and backup hosts are WLAN controllers located in geographically
separate data centers. The VPN host controller within each data center can be configured with a VRRP based
backup controller. The primary and backup hosts are analogous to the LMS and BLMS controllers in a classic RAP
architecture.
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 136
Below figure shows an Instant-VPN architecture designed for redundancy.
Figure 60 Instant-VPN architecture designed for redundancy
To configure the VPN settings, select the VPN menu on Instant WebUI, AirWave, or Aruba Central. The controller
tab in the VPN menu includes all the VPN host settings.
The controller tab provides the following settings:
l
Protocol: This setting defines whether the IAP establishes a GRE tunnel or an IPsec tunnel. Since the InstantVPN architecture defines a secure VPN tunnel, this field is set to IPsec.
l
Primary host: This setting defines the IP address of the WLAN controller that functions as the primary host. In
general, most organizations have a public IP address on the corporate firewall, which forwards the packets to the
controller in the DMZ. If two WLAN controllers are deployed as a VRRP redundant pair in the data center, the
firewall must be configured to forward the packets that are destined for the public IP address to the virtual IP
address that is used between the master and the VRRP backup WLAN controller. The only port that is required to
be open on the firewall for Instant-VPN is UDP port 4500 (IPsec NAT-T). The primary host IP address is an IP
address that can be reached through the Internet (that is, a public IP address). In general, an IP network should
be able to reach the primary host IP address without any tunneling.
l
Backup host: This setting defines the IP address of the WLAN controller that functions as the backup host. The
primary and backup hosts are deployed in geographically redundant data centers. Like the primary host IP
address, the backup host IP address must be reachable from an IAP network without any tunneling.
l
Preemption: Even when an IAP is on a backup host, it tests connectivity to the primary host in the background.
If preemption is enabled, an IAP that terminates its tunnel on the backup host switches back to the primary host
when the primary host becomes available again.
l
Hold time: This setting defines the time (in seconds), that an IAP waits before it switches back to the primary
host when preemption is enabled. This setting is visible on the Instant WebUI only if preemption is enabled.
l
Fast failover: By default, a master AP in an IAP cluster establishes only a single IPsec tunnel at any time, either
to the primary or to the backup host. If the communication to one host fails, the master AP establishes an IPsec
tunnel to the other host. However, if fast failover is enabled, the master AP can establish a backup VPN tunnel
even while the primary VPN tunnel is still up. The primary tunnel is in the active state and the backup tunnel is in
an ideal state. The purpose of fast failover is to reduce the failover time by eliminating the tunnel setup time during
failover.
137 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
l
Secs between test packets: This setting defines the frequency at which packets are sent to the controller to
detect the connection status. The unit is seconds per packet and the default value is 5 seconds, which means
that every 5 seconds the IAP sends one packet to the controller.
l
Max allowed test Packet loss: This setting defines the number of lost packets after which the IAP tears down
the tunnel. The default value is 6 packets.
Below is an example IAP configuration with these settings:
l
Protocol:IPsec
l
Primary Host: 199.xx.xx.137 (public IP)
l
Backup Host: 199.xx.xx.138 (public IP)
Figure 61 IAP IPSec configuration with primary and backup hosts
Configuring a Routing Profile
The second tab under the VPN settings menu is the routing profile tab. The routing profile on an IAP determines
whether the traffic that is destined for a subnet is forwarded through an IPsec tunnel or bridged locally. If the routing
profile is empty, the client traffic is bridged locally. If the routing profile is configured to tunnel 10.0.0.0 /8, traffic
destined for 10.0.0.0 /8 is forwarded through the IPsec tunnel and the traffic to all other destinations is bridged
locally.
An IAP network has only one active tunnel even if fast failover is enabled. At any time, traffic can be tunneled only to
one VPN host. (Policy-based routing and load balancing between the primary and backup hosts is currently not
supported).
To configure a route in the routing profile, define these settings:
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 138
l
Destination: This setting defines the IP address or subnet that must be reached through the IPsec tunnel. Traffic
is forwarded through the IPsec tunnel to the IP address or subnet that is defined by this setting.
l
Netmask: This setting defines the network mask to the destination that is defined in the Destination setting.
l
Gateway: This setting defines the WLAN controller to which the traffic must be tunneled. This address is the
actual WLAN controller IP address and not the public IP address that is defined as the VPN host. You can find
the actual IP address of the WLAN controller that functions as the primary or backup host through the controller
CLI in the output of the show controller-ip command or on the “controller IP details” screen on the WebUI of the
WLAN controller. If you have a primary and backup host, configure two routes with the same destination and
netmask, but for the primary route, configure the gateway as the IP address of the primary controller, and for the
backup route, configure the gateway as the IP address of the backup controller. The route that is selected from
the routing profile is based on the WLAN controller with which the VPN tunnel is established.
If a pair of controllers is configured for VRRP-based master-backup redundancy, every controller has a physical IP
address and there is a single virtual IP address. If the VPN host (primary or backup) is represented by a redundant
VRRP controller pair, the routing profile must have routes to the physical IP addresses of the VRRP master and
backup controllers or the virtual IP address of the VRRP redundant controllers. The following examples illustrate this
configuration:
Controller Redundancy Example 1
Consider an organization with two data centers: DC1 and DC2. The WLAN controller in the primary data center
(DC1) has a physical IP address of 10.68.33.6 and the public IP address of the firewall that is assigned to this
controller is 199.xx.xx.137. (The firewall forwards the traffic from 199.xx.xx.137 to 10.68.33.6). The controller in the
backup data center (DC2) has a physical IP address of 10.68.48.6 and the public IP address of the firewall that is
assigned to this controller is 199.xx.xx.138. (The firewall forwards the traffic from 199.xx.xx.138 to 10.68.48.6). In
this situation, the routing profile for an IAP branch that must establish a tunnel to 10.0.0.0 /8 contains these routes:
l
10.0.0.0 255.0.0.0 10.68.33.6
l
10.0.0.0 255.0.0.0 10.68.48.6
The master AP in the IAP cluster selects the route depending on whether the VPN tunnel is terminating on the
primary or backup host. The primary and backup host configurations under the VPN host settings are 199.xx.xx.137
for the primary host and 199.xx.xx.138 for the backup host.
Controller Redundancy Example 2
Consider an organization with two data centers: DC1 and DC2. Each data center has a pair of VRRP-based
redundant controllers.
l
l
l
Primary data center (DC1)
n
The physical IP address of the VRRP master controller in the primary data center is 10.68.33.6.
n
The physical IP address of the VRRP backup controller in the primary data center is 10.68.33.7.
n
The virtual IP address between the VRRP master and backup controller in the primary data center is
10.68.33.8.
n
The public IP address that is used for the primary host configuration is 199.xx.xx.137
Backup data center (DC2)
n
The physical IP address of the VRRP master controller in the backup data center is 10.68.48.6.
n
The physical IP address of the VRRP backup controller in the backup data center is 10.68.48.7.
n
The virtual IP address between the VRRP master and backup controller in the backup data center is
10.68.48.8.
n
The public IP address that is used for the backup host configuration is 199.xx.xx.138.
In this situation, the routing profile for an IAP branch that must establish a tunnel to 10.0.0.0 /8 contains these
routes:
139 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
n
10.0.0.0 255.0.0.0 10.68.33.6
n
10.0.0.0 255.0.0.0 10.68.33.7
n
10.0.0.0 255.0.0.0 10.68.48.6
n
10.0.0.0 255.0.0.0 10.68.48.7
The master AP in the IAP cluster selects the route depending on which controller is terminating the VPN tunnel. The
primary and backup host configurations under VPN host settings are 199.xx.xx.137 for the primary host and
199.xx.xx.138 for the backup host.
An alternative routing profile configuration for the above-mentioned example includes the gateway IP address as the
virtual IP address of the VRRP redundant controllers. In this situation, the routing profile for an IAP branch that must
establish a tunnel to 10.0.0.0 /8 contains these routes:
l
10.0.0.0 255.0.0.0 10.68.33.8
l
10.0.0.0 255.0.0.0 10.68.48.8
Below figure shows controller redundancy example 2 that is described above.
Figure 62 Routing profile configuration with VRRP-based redundant controllers
The routing profile on an IAP allows a total of 32 entries.
The routing profile is universal and applies to all SSIDs and wired ports that you configure in local mode,
centralized L2 mode and distributed L3 mode. For example, a routing profile that is configured to tunnel to 10.0.0.0
/8 applies to both the employee SSID that is configured for L3 mode and a guest SSID that is configured for local
mode. However, you can set up a user role to deny guests access to the 10.0.0.0 /8 network and source NAT all
other traffic locally to the Internet. User roles and firewall policies are applied to client traffic before the routing
profile is applied.
Below figure, is an example of the screen that lets you configure the routing profiles that are associated with
controller redundancy example 2 that is described above:
l
10.0.0.0 255.0.0.0 10.68.33.6
l
10.0.0.0 255.0.0.0 10.68.33.7
l
10.0.0.0 255.0.0.0 10.68.48.6
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 140
Figure 63 Configuring routing profiles
Configuring DHCP Profiles for Instant-VPN Modes
The DHCP server menu of the Instant WebUI lets you create DHCP profiles that determine the Instant-VPN mode
of operation. An Aruba Instant network can have multiple DHCP profiles configured for different modes of InstantVPN. You can create a total of 16 DHCP profiles for each Aruba Instant cluster and the DHCP profile definition
varies, based on the Instant-VPN mode. For information about the different Instant-VPN modes, see Understanding
Instant-VPN Modes.
The DHCP menu in Aruba Instant has three sections:
l
Distributed DHCP Scopes: This section includes the DHCP profile configuration for distributed L2 mode and
distributed L3 mode.
l
Centralized DHCP Scopes: This section includes the DHCP profile configuration for centralized L2 mode and
centralized L3 mode.
l
Local DHCP Scopes: This setting includes the DHCP profile configuration for Local mode.
141 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
Below Configuring an IAP for Instant-VPN Deployment is an example of the screen that lets you configure DHCP
server scopes.
Figure 64 Configuring DHCP server scopes
DHCP Profile for Local Mode
In local mode, the master AP in an IAP cluster is both the default gateway and DHCP server for clients that connect
to an SSID or wired port that operates in this mode. In local mode, the master AP assigns an IP address from a
configured local subnet. The subnet is not a Layer 2 or Layer 3 extension of the corporate subnet and the WLAN
controller in the data center has no visibility to this subnet. Client traffic that must be forwarded to corporate
destinations is source NATed by the master AP using the inner IP address of the IPSec tunnel. Traffic that is
destined for the Internet or local destinations is source NATed using the physical IP address of the master AP.
The following configuration settings are used for a local mode DHCP profile:
l
Name: This setting defines a unique name for the DHCP profile.
l
Type: This setting defines the Instant-VPN mode for the DHCP profile. The available options are Local and Local
L3.
l
VLAN: This setting defines the VLAN ID for the subnet that is used in the DHCP profile. This VLAN ID must be
defined in the VLAN settings of an SSID or wired port to allow it to operate in the appropriate Instant-VPN mode.
This VLAN ID should also be configured on the switches and allowed on the trunk links, between VC/master &
slave IAPs.
l
Network: This setting defines the subnet that is used by the DHCP profile.
l
Netmask: This setting defines the netmask of the subnet that is defined in the Network field.
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 142
l
Excluded Address: This setting defines the IP addresses that must be excluded from the DHCP lease. The
value that you enter in the field determines the exclusion range of the subnet. Specify a range of IP addresses to
exclude. You can add up to two exclusion ranges. Based on the size of the subnet and the value configured for
Excluded Address, the IP addresses either before or after the defined range are excluded. Excluded range should
have either the start IP of the subnet or the last IP of the subnet. For example:
Figure 65 Configuring a DHCP scope for local mode
This configures a DHCP scope of 192.168.12.12 – 192.168.12.199.
l
DNS server: This optional setting defines the DNS server IP address that is provided to the clients by the DHCP
server for this DHCP profile. If you do not configure a DNS server, client DNS requests are resolved by the DNS
server of the IAP (that is, the DNS server information that an IAP receives from the DHCP server in the branch or
from an ISP).
l
Domain name: This optional setting defines the domain name that is provided to the clients by the DHCP server
for this DHCP profile.
l
Lease time: This optional setting defines the lease time for clients.
l
Option: This optional setting defines additional DHCP options. You can configure a total of eight DHCP options.
One IP address from the configured network is used as the default gateway for clients. In most cases, the first
host IP address on the configured subnet is the default gateway. In the above example, the client got a default
gateway of 192.168.12.11.
143 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
DHCP Profile for Centralized L2 Mode
In centralized L2 mode, the DHCP server and gateway for the clients reside in the data center. The subnet that is
used in this mode is a Layer 2 extension of a corporate subnet. The client traffic that is destined for corporate
resources is forwarded to the WLAN controller with the appropriate VLAN tags inside an IPsec-GRE tunnel. Any
traffic that is destined for the Internet or a local resource is source NATed using the physical IP address of the
master AP.
These configuration settings are used for a centralized L2 mode DHCP profile:
l
Name: This setting defines a unique name for the DHCP profile.
l
VLAN: This setting defines the VLAN ID for the subnet that is used in the DHCP profile. The VLAN ID must be
defined in the VLAN settings of an SSID or wired port to allow it to operate in the appropriate Instant-VPN mode.
The VLAN must exist on the WLAN controller. The DHCP broadcasts from the clients are forwarded through the
IPsec-GRE tunnel to the WLAN controller in the data center. Any client traffic that is destined for corporate
resources is tagged with this VLAN ID and forwarded through the IPsec-GRE tunnel. This VLAN ID should also
be configured on the switches and allowed on the trunk links, between VC/master & slave IAPs.
l
Split tunnel: If split tunnel feature is disabled, (enabled by default), then inspite of any configuration under routing
profile, all traffic will be sent to the data center over IPSec tunnel. This feature was introduced as centralized L2
mode, most of the time has use case, where all the traffic needs to be tunneled over IPSec tunnel to the data
center and no traffic should be split tunneled and source NATed over VC IP. To achieve this objective, more
easily for a particular VLAN, this feature was introduced.
l
Option 82: This setting defines a method to enforce more security in the DHCP infrastructure. By default, the
DHCP server is vulnerable to a number of security threats, such as an attacker attempting to exhaust the DHCP
pool addresses by sending fake DHCP client packets. Enabling Option 82 ensures that the DHCP client is
authentic. Also, Option 82 allows the DHCP server to be anywhere in the intranet or cloud, while still assigning
addresses with the local context, that is, centralized control with local address assignment. For Option 82 to take
effect, the DHCP server must also be configured for Option 82.
The DHCP profile definition for centralized L2 mode does not require a network configuration, but the VLAN ID
determines the functionality. The VLAN ID that is defined in the DHCP profile configuration for centralized L2
mode must exist on the WLAN controller as a Layer 2 VLAN (that is, no IP address configured on the VLAN
interface) or a Layer 3 VLAN (that is, an IP address configured on the VLAN interface). In the data center, ensure
that inter-VLAN routing is enabled between the VLAN that is used for centralized L2 mode and other VLANs.
Below figure is an example of a screen that lets you configure a DHCP profile for centralized L2 mode using VLAN
ID 30.
Figure 66 Configuring a DHCP scope for centralized L2 mode
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 144
In distributed L3 mode, the master AP in an IAP cluster is the default gateway and DHCP server for clients. Unlike in
local mode, the subnet that is used in this mode is a Layer 3 extension of a corporate subnet and, therefore, the
WLAN controller and other upstream routers in the data center can reach this subnet. The client traffic that is
destined to corporate resources is routed through the IPsec tunnel to the WLAN controller. The traffic that is destined
to the Internet or local resources is source NATed using the physical IP address of the master AP.
In distributed L3 mode, you usually configure a large network, which is automatically broken down into smaller
subnets based on the client count configuration. The subnet that is dedicated to each branch depends on the client
count and network settings in the DHCP profile configuration. The master AP and WLAN controller use the Branch
ID (BID) process to determine the Layer 3 subnet that is used in a branch. For more information about the BID
process and distributed L3 mode, see Branch-ID Allocation Algorithm and Instant-VPN: Distributed L3 Mode.
Aruba Instant allows you to configure a dedicated Layer 3 subnet for each branch. Instead of configuring a large
subnet that is then divided into smaller subnets based on client count, you can definite a unique Layer 3 subnet for
each branch with the required subnet. However, this process slightly increases the management overhead
because the IP address range configuration must be modified on a per-branch basis.
The distributed scope configuration has three tabs: Network, Branch Size, and Static IP. These tabs are described in
the following three sections.
Network Tab
As part of the configuration of a DHCP profile for distributed L3 mode, the following configuration settings are
available under the Network tab:
l
Name: This setting defines a unique name for the DHCP profile.
l
Type: This setting defines the Instant-VPN mode for the DHCP profile. Available options are Distributed L3 and
Distributed L2. Select Distributed L3 for distributed L3 mode.
l
VLAN: This setting defines the VLAN ID for the subnet that is used in the DHCP profile. The VLAN ID must be
defined in the VLAN settings of an SSID or wired port to allow it operate in the appropriate Instant-VPN mode.
The distributed L3 mode VLAN need not be configured on the WLAN controller. The master AP replies to DHCP
broadcasts from the clients. Any client traffic with a corporate destination is routed through the IPsec tunnel.
l
Netmask: This setting defines the netmask for the DHCP profile.
l
DNS server: This optional setting defines the DNS server IP address that is provided to the clients by the DHCP
server for this DHCP profile. If you do not configure a DNS server, client DNS requests are resolved by the DNS
server of the IAP (that is, the DNS server information that an IAP receives from the DHCP server in the branch or
from an ISP). If you define a corporate DNS server in the data center, the Enterprise domain configuration (under
the Enterprise domain tab) of the IAP WebUI determines whether the DNS traffic is forwarded to this DNS server
or is source NATed to the DNS server of the IAP. For more information, see DNS Handling in an Aruba InstantVPN Network.
l
Domain name: This optional setting defines if the domain name is provided to the clients by the DHCP server for
this DHCP profile.
l
Lease time: This optional setting defines the lease time for clients.
l
IP Address Range: This setting defines the IP address range that is divided into smaller subnets based on the
Clients per branch setting under the Branch Size tab (see Branch Size Tab).
145 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
For example, an organization uses subnet 10.68.0.0 /16 with 250 clients per branch in a distributed L3 mode
configuration to support 256 branches. (250 over here is taken as an example. One /24 subnet can fit in 253 IP
addresses. You can use 253 here as well.) This organization configures the IP Address Range setting as 10.68.0.0 10.68.255.255. In this configuration, if the IP address range is configured as 10.68.0.1 - 10.68.255.254, only 254
branches can be supported because in Layer 3 mode each branch requires a /24 subnet to support 250 clients. With
an IP address range configuration of 10.68.0.1 - 10.68.255.254, subnets 10.68.0.0/24 and 10.68.255.0 /24 cannot be
used because 10.68.0.0 and 10.68.255.255 are not included in the IP address range. Instead of a single contiguous
address space, you can configure multiple address spaces (use the + icon).
If an organization requires a specific subnet at a specific branch, it is not useful to define a large subnet that is
automatically divided into smaller subnets based on client count. For example, an organization wants subnet
10.68.0.0 /24 at Site A and subnet 10.68.1.0 /24 at Site B. If they define a single large subnet that is automatically
allocated to the branches based on the BID algorithm, that configuration cannot guarantee that Site A is assigned
subnet 10.68.0.0 /24 and Site B is assigned subnet 10.68.1.0 /24. This requirement is very common among
organizations that want to upgrade their existing branch infrastructure and keep the same address scope because
those branches contain devices with static IP addresses. Aruba Instant 3.3 and greater support this requirement by
allowing you to define a pre-determined subnet on a per-branch basis. To achieve this subnet configuration, configure
the IP Address Range settings to include only the IP address range and client count for a specific branch. For
example, an organization wants subnet 10.68.0.0 /24 at Site A and subnet 10.68.1.0 /24 at Site B. The IP address
allocation and branch size configuration for the IAP network in Site A must be 10.68.0.0 – 10.68.0.255 with 253
clients per branch and in Site B must be 10.68.1.0 – 10.68.1.255 with 253 clients per branch.
You must include the network and broadcast address in the IP address range configuration for distributed L3 mode.
For example, if Site B is configured as 10.68.1.1 – 10.68.1.254 with 253 clients instead of 10.68.1.0 – 10.68.1.255
with 253 clients, then a /24 subnet cannot be formed and the clients at Site B cannot receive an IP address.
The BID allocation process is essential even if a predefined subnet is configured for a branch. Clients cannot
receive an IP address until the BID allocation process is successful.
The first host IP address in the subnet that is allocated to a branch is used as the default gateway for clients.
l
Option: This optional setting defines additional DHCP options. You can configure a total of eight DHCP options.
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 146
Configuring an IAP for Instant-VPN Deployment figure is an example of the Network tab of the screen that lets you
configure a DHCP profile for distributed L3 mode.
Figure 67 Configuring the network settings for a DHCP scope for distributed L3 mode
Branch Size Tab
The Branch Size tab lets you define the number of client IP addresses that are required for each IAP branch in the
distributed L3 mode. This setting determines the number of distributed L3 branches that the network that you defined
under “Network” tab can support. For example, a configuration of 10.68.0.0 /16 with 250 clients per branch can
support a total of 256 branches. For more information, see Branch-ID Allocation Algorithm.
147 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
Configuring an IAP for Instant-VPN Deployment figure is an example of the Branch tab of the screen that lets you
configure a DHCP profile for distributed L3 mode.
Figure 68 Configuring the branch size settings for a DHCP scope for distributed L3 mode
Static IP Tab
The Static IP tab lets you reserve a set of IP addresses from the subnet that is allocated to a branch for devices that
require static IP addresses. For example, if a branch is assigned a /24 subnet, based on a distributed L3
configuration of 10.68.0.0 /16 with 250 clients per branch, you can reserve a set of IP addresses at the start and at
the end of the subnet that is allocated to that branch.
Below figure is an example of the Static IP tab of the screen that lets you configure a DHCP profile for distributed L3
mode.
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 148
Figure 69 Configuring the static IP settings for a DHCP scope for distributed L3 mode
Configuring an SSID or Wired Port for Instant-VPN
For a client to be able to connect to an Instant-VPN network, you must configure an SSID or wired port on an IAP for
the appropriate Instant-VPN mode of operation. The VLAN configuration for an SSID or wired port determines
whether an SSID or wired port is set up for the Instant-VPN. When you configure an SSID or wired port for a specific
Instant-VPN mode, the VLAN ID that is defined in the configuration of the SSID or wired port must match the VLAN
ID that is defined in the DHCP profile. An Instant-VPN cannot function if the VLAN configuration on an SSID or
wired port is set to Virtual Controller assigned, Default, or Static with a VLAN ID that does not match the VLAN ID in
the DHCP profile. For example, consider an IAP configuration with these DHCP profiles:
l
Distributed L3 DHCP profile with VLAN ID 50
l
Local DHCP profile with VLAN ID 60
l
Centralized L2 DHCP profile with VLAN ID 30
To configure an SSID or wired port for distributed L3 mode on the IAP, set the VLAN configuration on the SSID to
Static with VLAN ID 50. Similarly, to configure an SSID or wired port in local mode, set the VLAN configuration to
Static with VLAN ID 60.
Below are examples of these VLAN configurations on the WebUI of an IAP. Note that once you create appropriate
DHCP profiles in DHCP server section, they come up in the drop down options, under “Custom” field.
149 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
Figure 70 Configuring an SSID for VPN modes
In ArubaOS 6.3 and greater, all Instant-VPN tunnels are considered trusted. Therefore, the users in Instant-VPN
branches do not display in the user table of the WLAN controller. However, the users in the Instant-VPN branches
are always visible on AirWave and the Instant WebUI in each branch.
Enabling Dynamic RADIUS Proxy (DRP)
The location of the RADIUS server that is used to authenticate users in branch locations varies from organization to
organization. Most organizations have a centralized RADIUS server in the data center to authenticate remote users,
but some organizations might use a local RADIUS server at each location. Other organizations might also use a
local RADIUS server for employee authentication and a centralized RADIUS server with a captive portal for guest
authentication.
Enable DRP to ensure that RADIUS traffic is routed to the appropriate RADIUS server. When enabled, DRP also
ensures that the source address for all RADIUS traffic is the VC IP address or the inner IP address of the IPsec
tunnel from the master AP, depending on the IP address of the RADIUS server and the routing profile. If the routing
profile is configured to set up a tunnel to the 10.0.0.0 /8 network and if the RADIUS server has IP address
10.68.32.40, the RADIUS traffic is forwarded through the IPsec tunnel using the inner IP address of the IPsec tunnel
from the master AP. However, if the IP address of the RADIUS server is 192.168.32.40, the RADIUS traffic is
bridged locally using the VC IP address.
If you configure DRP, you must assign a static IP address to the VC. This IP address cannot be 0.0.0.0. In branch
office deployments that do not use local RADIUS resources, it might not be possible to determine the IP address
range that is used locally. In such a situation, configure the IP address of the VC as a random static IP address in
a non-corporate private IP address range (for example, 192.168.137.139, if the corporate network is 10.0.0.0 /8).
Such a configuration enables DRP to tunnel the RADIUS traffic to the central RADIUS server in the data center.
DRP is not required in single-AP Instant-VPN deployments. However, if DRP is disabled in single AP
deployments, the NAS-IP attribute in RADIUS packets that are destined for the RADIUS server in the data center
Aruba Instant Validated Reference Design
Designing Distributed Enterprise Networks with Aruba Instant | 150
is set to the local IP address of the IAP and not to the inner IP address of the IPsec tunnel. Therefore, Aruba
recommends that you enable DRP in single AP deployments with RADIUS servers that use the NAS IP attribute
as a filter for authentication.
Configuring Enterprise Domains (Split-DNS)
By default, all DNS requests from a client are forwarded to the DNS server of the client. In a typical IAP deployment
without VPN configuration, client DNS requests are resolved by the DNS server of the client. However, this
behavior changes if an IAP is configured for Instant-VPN.
The DNS behavior of an IAP network (with SSIDs or wired ports) that is configured for Instant-VPN is determined by
the enterprise domain settings. The enterprise domain setting on the IAP defines the domains for which the DNS
resolution must be forwarded to the default DNS server of the client. For example, if the enterprise domain is
configured for arubanetworks.com, the DNS resolution for host names in the arubanetworks.com domain is
forwarded to the default DNS server of the client. The DNS resolution for host names in all other domains is source
NATed to the local DNS server of the IAP. This configuration can provide faster DNS response times, and extra
privacy.
If you configure an asterisk (*) instead of a domain name in the enterprise domain list, all DNS requests are
forwarded to the default DNS server of the client. If you want all DNS requests to be processed by the DNS server
of the client, configure an asterisk (*) in the enterprise domain setting.
Below is an example of a screen that lets you configure enterprise domains.
Figure 71 Configuring enterprise domains
151 | Designing Distributed Enterprise Networks with Aruba Instant
Aruba Instant Validated Reference Design
Chapter 5
Aruba Instant management using Aruba AirWave
Communication Concepts
Essentially, all communication between Aruba Instant and AirWave occurs through standard HTTPS traffic on port
443 and is always initiated by the virtual controller (VC).This type of communication allows devices to be deployed
quickly and without changing firewall rules. During normal operation, the VC sends updates to AirWave every
minute. While an AirWave user is making configuration changes or running diagnostic commands, the VC checks in
every 5 seconds to improve the responsiveness for the user.
IAP can also communicate with AirWave on a specified port. In IAP side, configure Airwave IP as IP:Port,
meanwhile, set communication port in AMP Setup.
In an environment where the IAPs and data center are all on the same network you can deploy AirWave securely
inside the firewall. Below figure is an example of such a deployment.
Figure 72 IAPs and data center are all on the same network
In a distributed network, the AirWave Management Platform (AMP) needs to be reachable from outside the firewall,
to allow IAPs to communicate with the AMP through HTTPS. Below figure, is an example of such deployment.
The AirWave WebUI can also display data obtained through HTTPS traffic on port 443. Most network administrators
do not want their NMS systems to be exposed outside. To ensure that the WebUI is accessible only to users on a
trusted network, AirWave has an AMP whitelist feature. When you add internal networks to the whitelist and enable
the whitelist, networks that are not on the whitelist are denied access to the AirWave WebUI. Aruba Instant Validated Reference Design
Aruba Instant management using Aruba AirWave | 152
Figure 73 Adding a network to the AMP whitelist
Figure 74 Distributed network with IAPs outside the firewall
Adding IAPs to AirWave
You can add an IAP to AirWave by adding the AirWave communication parameters to the VC. These parameters
include the AirWave IP address, a shared secret, and the organization string, which is a colon-separated list of
strings that define the group and folder in which the device is placed. You can add these parameters through the VC
WebUI, through Aruba Activate, or through DHCP options. These options are described in the following sections.
For more information about the organization string and how it is used to authorize and place devices into groups and
folders in AirWave, see Provisioning an IAP through DHCP Options and Organization String.
Manually Adding an IAP through the VC WebUI You can add the AirWave communication parameters through the VC WebUI. The organization field has
communication parameters for group & folders.
153 | Aruba Instant management using Aruba AirWave
Aruba Instant Validated Reference Design
Figure 75 Adding AirWave communication parameters to the VC WebUI
Provisioning an IAP through Aruba Activate
Aruba Activate is a secure, cloud-based system that enables efficient deployment and maintenance of Aruba
devices, and is available online at https://activate.arubanetworks.com.
There are two key services offered by Aruba Activate:
l
Provisioning Service – Activate Provisioning service helps end users reduce cost and time to successfully deploy
Instant Access Points any place with network access.
l
Firmware Distribution Service – New Firmware are added by Aruba to remote servers for all versions of IAPs.
IAPs once provisioned and connected to the Internet, check in every 7 days to see if a new firmware is available.
Instant Access Points (IAPs) can utilize the remote server to download and automatically upgrade firmware
based on the device type.
Add Devices in Activate
When you order a new device from Aruba Networks, that device is automatically added to your inventory in Aruba
Activate. You need to create an account on activate.arubanetworks.com. You can also add an IAP into activate
using the “add device” option, if it’s not automatically added to your account. It will need you to add your IAP’s mac
address and Cloud activation key, which can be found in the Maintenance tab of IAP:
When a device is in your inventory, it can be automatically or manually associated with a folder and a provisioning
rule.
After a remote technician connects the IAP to the Internet, the IAP securely connects to Aruba Activate, retrieves its
provisioning information, uses the provisioning information to connect to either its AirWave server or to Aruba
Central, and updates its configuration and firmware.
Aruba Instant Validated Reference Design
Aruba Instant management using Aruba AirWave | 154
Key information such as Serial, MAC address, Status, IAP model number, and PO number are all listed in the Home
screen for easy access to users. Devices in the Activate home screen are either listed as shipped or provisioned.
Shipped means the devices have been shipped from Aruba but have not yet made contact with the Activate server.
All IAPs with status “Shipped” are part of the default folder. A device that is provisioned will have it listed under a
different user defined folder.
Figure 76 Provisioning an IAP through Aruba Activate
Create Folders in Activate
In order for the IAPs to receive the appropriate information from Activate, they must be part of a non-default folder
with at least one Provisioning Rule bound to this folder. Once you have your provisioning rules established in their
respective folders, you can start moving IAPs into these folders. When an IAP checks into Activate, the cloud
system will know that it belongs to a certain folder with provisioning rules that need to be applied to the device.
To create a new folder, click on the “Setup” icon and then, you can see three window boxes across the top - Folders,
Rules, and Users. Click on the New link in the “Folder” box and enter the following information:
l
Name - To keep it consistent, enter the same name as defined for the Group in AirWave. However, this does not
need to match.
l
Select parent folder - It can either be the default folder, or you can create a parent folder with customer name or
region and then all different templates that belong to the customer/region can reside under different folders
referenced to the parent folder. For most deployments, the default folder will be the parent folder. However, you
can create users with roles and assign them to certain folders. This could make sense if the customer wants to
delegate Activate responsibility for other regions or administrators.
l
Enter any Notes for future reference.
155 | Aruba Instant management using Aruba AirWave
Aruba Instant Validated Reference Design
Create provisioning rules in Activate
The next step is to create Provisioning Rules and apply them to this new folder. The rule specific to this use case
will be "IAP to AirWave". Note the other types available in Activate for other use cases like MAS wired switches,
IAP to CAP, and IAP to RAP.
To create a new provisioning rule, click on the New link in the middle box labeled Rules and supply the following
information:
l
Under Rule Type, select Provisioning Rule
l
Under Parent Folder, select the new folder that was created in the previous step
l
Under Provisioning type, select IAP to AirWave
l
Under AMP IP, enter the AirWave IP address. This should be a public IP address if provisioning home IAPs
using the RAP-NG architecture (IAP+VPN). If this is an IAP deployment with AirWave accessible from the APs,
then a public IP address on AirWave isn't needed.
l
Under Shared Secret, enter an alphanumeric key that will act as a trust mechanism between the Instant AP and
AMP. There is no requirement to set the same value anywhere in AMP. The first IAP to connect with secret
configured will set the secret on AirWave for all future connections. This cannot be changed (you must contact
TAC to reset the secret).
l
Under Organization, enter the exact same (case sensitive) value that is created (or will be created) on AMP. This
is one of the most important aspects of zero touch provisioning. In addition to this value, you can colon separate
additional values to create subfolders in AMP for further granularity in the AP/Devices tab. For example, if I
would like to create the group "US-East" but then have subfolders for smaller regions, I can do the following in
this field. "US-East:MA:Boston" This would create/provision from the US-East Group in AMP as well as
create/add folders as such in AMP - Top --> US-East --> MA --> Boston.
Aruba Instant Validated Reference Design
Aruba Instant management using Aruba AirWave | 156
From 4.2.0.1 onwards, you can also specify VPN server IP address in the “IAP to AirWave” provisioning rule. IAP
creates an IPSec tunnel to the IP of the controller you provide in VPN server field. Confirm that IAP has got the
VPN server info by, “show vpn config”..
Another rule you can apply to this folder is an email notification when a device gets provisioned. To create this rule,
select New again in the Rules box and provide the following information:
l
Under Rule Type, select Notification
l
Under Email On, select Provisioning
l
Under For Rule, select the provisioning rule from the previous step
l
Under Email to, enter an email address(es)
157 | Aruba Instant management using Aruba AirWave
Aruba Instant Validated Reference Design
We are now at a stage where the provisioning rules are complete. If required, repeat the process above to create
other folders and rules for different groups within AirWave. For RAP-NG, this would logically map to different
functional groups within the company or different regions where RAPs would be deployed. A sample Folder/Group
list may look like the following:
l
US-East
l
US-Central
l
US-West
l
EMEA
l
APAC
l
IT-Group
Folders contain provisioning rules for Instant devices.
Assign Devices to Folders in Activate
After the folders and rules are created, the next step is to return to the Device table on the Activate home screen and
assign devices into their respective folders. If the customer has a large amount of devices, it may help to filter using
the filter icon located to the right of each column header on this screen. For example, if you know the hardware type,
serial number, a portion of the MAC address, and/or a ship date after a specified date or within a date range, these
filters can help narrow down a large list of devices for assigning to folders. If filters are in use, you can easily see that
as the filter icon will change from its default grey color to a navy blue color.
An example of using filters is shown below:
Once you have the specific device you want to move or a list of devices you want to move, you can then assign
them to a folder. There are two methods to accomplish this.
1. If you want to move a single device, select it from the devices table and a Device Detail window will appear in the
bottom left of the screen with one clickable button. Click Edit and you will be able to select a Folder for this one
Aruba Instant Validated Reference Design
Aruba Instant management using Aruba AirWave | 158
device.
2. Most of the time, customers will want to move a whole list of devices. In order to select the right list of devices,
the use of filters is imperative. You use the filters to only display the devices you wish to move. Once you have
the desired list, you can click on the Move to Folder button at the top right and bulk move all devices listed on this
filtered screen.
The Move to Folder button invisible in certain browsers. If you are unable to see it (as shown below), please try
another browser.
Following CLI outputs on the master can show the status of provisioning & information received.
IAP# show log provision
Provisioning Log
---------------Time State Type Log Message
--------------------Tue Oct 13 20:43:20 2015 DHCP Option In progress Performing DHCP discovery
Tue Oct 13 20:43:20 2015 DHCP Option In progress DHCP lease of 192.168.200.106
obtained, lease time 3600 seconds
Tue Oct 13 20:44:55 2015 AirWave Auto Discovery In progress Performing DNS based AirWave
auto discovery, AMP Domain: aruba-AirWave
Tue Oct 13 20:44:55 2015 AirWave Auto Discovery Warning Failed to resolve AMP Domain
aruba-AirWave during AirWave auto discovery
Tue Oct 13 20:44:55 2015 DHCP Option Fail through No DHCP Option-based
provsioning information are present, failing-through to other provisioning options
Tue Oct 13 20:44:55 2015 Activate In progress Attempting provisioning via
Activate server: device.arubanetworks.com
Tue Oct 13 20:44:55 2015 Activate Debug Sent challenge response to
Activate Server: device.arubanetworks.com
Tue Oct 13 20:44:56 2015 Activate Completed Received instruction from
Activate Server to connect to AMP server at aruba using organization '2.2.2.2'
159 | Aruba Instant management using Aruba AirWave
Aruba Instant Validated Reference Design
IAP# show activate status
Activate Server :device.arubanetworks.com
Activate Status :success
Organization :aruba
AirWave Server :2.2.2.2
AirWave Shared Key :9243aeb0e944e53a50f0ad38ae603ecba20c33621b13ab07
Other useful commands on IAP:
l
Show datapath session | include 443
l
Show ap debug AirWave
l
AirWave Server List
------------------Domain/IP Address Type Mode Status
----------------- ---- ---- -----199.127.100.100 Primary Manage Login-done
l
Show ap debug AirWave-data-sent
l
If there is no communication, you will see "cat: /tmp/awc_buf.txt: No such file or directory"
l
Show log ap-debug
Useful tools on AirWave:
l
Check the System --> Event Log for any messages or communication timeouts
l
Check the System --> Status --> /var/log/pound (direct link - [https://]<amp IP>/display_
log?log=%2Fvar%2Flog%2Fpound)
l
This is a log for all HTTP/HTTPS communication into AirWave. Check to see that the IAP's public NAT'ed IP is
seen here and any errors encountered. Very useful to troubleshoot from AirWave if the IAP is even reaching
AirWave if there is no direct access to the IAP remotely.
l
In a working scenario, you should see this every minute or so:
Feb 4 04:02:25 amp pound: <public IP of IAP> POST /swarm HTTP/1.1 - HTTP/1.1 200 OK
Provisioning an IAP through DHCP Options
If a device does not have Internet access during initial provisioning, you can specify AirWave communication
settings to be configured through vendor class identifier (VCI) DHCP options 60 and 43. There can be potential
character limits for option 43 on the DHCP server, please keep them in mind during the deployment. An IAP receives
its AirWave settings from a DHCP server in the following way:
1. The DHCP client on the IAP adds DHCP option 60 to its DHCP request. The value of this option is
ArubaInstantAP. 2. The DHCP server detects DHCP option 60 in the request and checks for DHCP option 43. If the DHCP server
can locate DHCP option 43, the server sends it to the client. The value of this option is the organization string,
AirWave IP address, and shared secret.
3. If the IAP detects DHCP option 43 in the response from the DHCP server, the IAP contacts AirWave at the
supplied IP address and uses the shared secret and organization string.
Use the following values for the DHCP options:
l
For DHCP option 60, use ArubaInstantAP.
l
For DHCP option 43, use <organization string,AirWave IP address,shared secret>
Aruba Instant Validated Reference Design
Aruba Instant management using Aruba AirWave | 160
An example of VCI option 43 is: ArubaRetail:Sunnyvale:Store0001
Adding IAPs to AirWave shows the communication flow between the IAP, DHCP server, and AirWave.
Figure 77 Provisioning an IAP through DHCP options
Below figure shows the configuration of DHCP option 60 in a Microsoft Windows Server 2008.
Figure 78 Configuring DHCP option 60 in a Windows Server 2008
161 | Aruba Instant management using Aruba AirWave
Aruba Instant Validated Reference Design
Below figure shows the configuration of DHCP option 43 in a Microsoft Windows Server 2008.
Figure 79 Configuring DHCP option 43 in a Windows Server 2008
For more about DHCP options, see the Aruba Instant User Guide that is available at the Aruba support website.
AirWave prerequisites
If the devices are communicating from the Internet, AirWave must be visible with a public IP address on the internet.
The only port that needs to be open is 443.
AMP must have the same Group names configured as the provisioning rules in the Organization value in Activate. In
the example above, AMP must have a "US-East" Group. This is assuming that the devices are getting automatically
provisioned using an already established Group configuration.
If this is the first device to check into AirWave, then there are some special caveats to be aware of.
l
The first IAP will automatically create the group in AMP if it's not already created. This Group will be whatever is
the Organization value as entered in Activate.
l
If the first IAP has the desired config, it can be used as a "golden" template for subsequent IAPs following along
in the same group. This would entail configuring the IAP traditionally using the VC GUI on the IAP itself before
communicating with AMP. Then, when it does communicate with AMP for the first time, AMP will create this
group and use the configuration on the IAP as the Group config, which then the subsequent IAPs will get
provisioned with.
l
If the first IAP doesn't have a desired config, a new Group can be created and an existing config copied from an
already established IAP group within AMP. Let's say you already have a known, working IAP group within AMP.
You can create a new Group and then using Instant Config (IAP GUI in AMP), copy the config from the first group
into the newly created second group. This is done in the AirWave --> AirWave Settings screen. Use the field
"Copy Policy from Group" and select the first group with the existing desired config.
Aruba Instant Validated Reference Design
Aruba Instant management using Aruba AirWave | 162
l
If multiple IAPs communicate with AMP at the same time and there is no Group template or config, AMP will use
the first IAP that checked in as the "golden" template for the group. This introduces a bit of chance and a best
practice suggestion would be to have one IAP communicate first into a newly created group before the floodgates
are opened for the other IAPs.
AirWave whitelist
Traditionally, when Instant devices first communicate with AirWave, they have been authenticated using a shared
secret. That's still possible, and is the default behavior. But it's also possible to let them authenticate by whitelisting
them. This adds a level of security beyond what a shared secret provides. More importantly, since devices are
known to AirWave before they ever connect to it, it's possible to define configuration parameters before they are
online, providing a flexible and scalable way to do zero-touch provisioning of Instant.
l
To enable whitelisting, Go to the AMP Setup page and set "Authorize Aruba Instant APs connecting to AirWave"
to "Whitelist". Save the setting.
l
If you plan to use the custom variable feature, all the devices must go into groups using template-based
configuration rather than Instant GUI config.
Adding devices to the whitelist
When you enable Whitelist authorization, the APs/Devices>New page adds the below mentioned buttons:
163 | Aruba Instant management using Aruba AirWave
Aruba Instant Validated Reference Design
Manually on AMP GUI
From APs/Devices>New>Instant AP whitelist, if you choose “Add an Instant AP to the whitelist”, below screen shot
comes up:
For each record, the required fields are:
l
Name
l
Either serial number or MAC address
All other fields are optional.
Import through Activate
From APs/Devices>New>Instant AP whitelist, if you choose “Import Instant whitelist from Activate”, below screen
shot comes up:
Aruba Instant Validated Reference Design
Aruba Instant management using Aruba AirWave | 164
In bulk through CSV file
From the New Devices page, click Import Instant AP Whitelist from CSV. On the subsequent page, upload your csv
file. The file should be in the below format:
Name,LAN MAC Address,Serial Number,Virtual Controller Name,Group Name,Folder Name,custom_variable_
1,custom_variable_9
IAP_Canada_1,ff:c7:c8:c4:21:ff,BD0086086,Canada-Office,Canada,Vancouver:Downtown,abc,456
IAP_US_1,F0:0B:86:CF:93:FF,BE0542245,US-Office,US,San Fancisco:CenterTown:HillTop,cde,789
AirWave in DMZ
With RAP-NG architectures, there is a requirement to have AirWave available to IAPs on the public internet. This
presents some security concerns from our customers. In order to alleviate some of these concerns, there are two
options available to you.
1. Use the AMP Whitelist feature. AirWave 7.7.3 introduced support for AMP whitelists. On the AMP Setup >
Authentication page, you can now include a list of subnets that are able to log in to AMP. If this option is enabled,
then by default, the current client network will appear as the first entry in the list of subnets. Additional entries can
be added, one per line, in the text entry box. A customer would normally add their internal networks to this list.
Any access outside of this list will only be allowed from IAPs. Any user attempting access will get an error
message (see below). This feature effectively allows IAPs access to AirWave while only allowing browser
access to the hosts/subnets in the whitelist.
Do not delete the current client network line from the AMP whitelist. Doing so can result in the loss of access to the
AMP user interface.
165 | Aruba Instant management using Aruba AirWave
Aruba Instant Validated Reference Design
2. Use two AirWave servers. If the security requirements are strict, then there is another alternative to use a
"provisioning" AMP server in the DMZ and the "real" AMP server in the internal network. Here is how that
process would look like:
n
The provisioning AMP server would have the same Group names as the internal AMP server. However, the
provisioning AMP server would only configure the IAPs with the VPN peer address(es) and the internal
AirWave server.
n
The IAPs, when provisioned from Activate would be told where the Provisioning AMP server is located plus
the intended group. n
The Provisioning AMP server would automatically provision and sync firmware but it would only pass along
the VPN information and internal IP address of the internal AirWave server (non-routable on public internet).
Once the IAP comes up with this configuration, it creates a VPN tunnel and communicate with the internal AMP
server for the remainder of its configuration.
In this option, you reduce the risk of a public AMP server with the entire configuration in the DMZ. Since the
controller has to also whitelist the device terminating the VPN tunnel, there is an additional level of authentication
available as well before the IAP gets the rest of its configuration.
If IAP configuration is sending all traffic into the VPN tunnel, this may cause an issue with the firewall located at
datacenter. Consider that before the IAP has its config, it is using the local ISP connection to talk with AirWave.
After it gets its config, it will use the tunnel to talk with AirWave. This may introduce a spoofing error on the firewall
and block the traffic to AirWave. Starting in 4.0, IAP introduced an exception route in the VPN routing profile. For
example, you can have all traffic tunneled except for the AirWave host IP address which will workaround this
design. Below is the screen shot of VPN configuration on the IAP, which can be used to route traffic to
199.127.100.100 outside VPN tunnel.
Aruba Instant Validated Reference Design
Aruba Instant management using Aruba AirWave | 166
When the device is turned on, it communicates with Aruba Activate at https://device.arubanetworks.com, receives
its provisioning settings based on the rules that you defined, and starts to communicate with AirWave. For example:
The rule above will instruct the IAP to create a tunnel to 3.3.3.3. Connect to AirWave on 2.2.2.2, with “aruba” as
organization string.
Organization String
When an IAP is added to AirWave, the device is authorized based on its organization string. The organization string
is a list of colon-separated strings that define the group and folder that the device is placed into. Additionally, a role is
created that gives access only to this folder. This example is a very simple organization string:
US
A device with an organization string of “US” is placed in an AirWave group that is called “US” and in a folder that is
called “US.” The folder is one level beneath the top folder. In addition, a role is created that grants access to devices
in the “US” folder. This example is a slightly more complex organization string:
US:California:Sunnyvale
A device with an organization string of “US:California:Sunnyvale” is placed in an AirWave group that is called “US”
and that has the below mentioned folder hierarchy:
In addition, a role is created that grants access to devices in the “US” group and all its subfolders.
Setting up Groups, Folders and Roles in AirWave
When a device is added to AirWave, it is placed in a group and a folder, each of which has a different purpose.
167 | Aruba Instant management using Aruba AirWave
Aruba Instant Validated Reference Design
Groups
AirWave groups are primarily for configuration. Devices that have the same configuration should be placed in the
same group. In a typical group configuration, you might have one group for IAPs, including the VC and one for thirdparty switches. When AirWave has too many groups for similar devices, managing configurations can become a
challenge. You might have difficulty determining if devices conform to a common standard, which can increase the
chance that you make a configuration error. To simplify configuration management, create as few groups as
possible. Groups within AirWave can be thought of as containers for common configuration profiles or templates.
With IAPs and RAP-NG architectures, each IAP that is part of a Group will have the same configuration minus some
obvious IAP settings that are unique to each device/cluster like virtual controller name and IP address as well as IAP
hostnames. These are accounted for in AirWave's Instant Config. The advantage of this solution is that once a
Group is established, the configuration and any future additions and/or changes are applied seamlessly to all virtual
controllers in that Group. Any new virtual controllers added through Activate or manually will obtain these settings
automatically.
It is recommended that a user configure a VC/IAP first using the IAP UI and once the configuration is certified, add it
manually into AirWave. First ensure that all SSIDs, RF settings, VPN settings, plus anything else you wish to mirror
to other VCs/IAPs are fully configured and working as expected. Once satisfied, navigate to System (top right) >
Admin.
This should look familiar as it's the same information Activate asks for when adding an IAP to AirWave provisioning
rule (see above).
Once you enter the AirWave settings, you should see this IAP contact AirWave in a few minutes. It will show up in
the New Devices List. If the Group is not created yet, the value placed in the Organization field from above will be
used as the Group name. For example, if you entered US-IAP:East, the Group name will be "US-IAP".
When you add this new IAP, the Group and Folder selectable values on this screen shouldn't be altered. Just leave
them at their defaults. The Group and Folder additions will be based on the Organization value entered either through
Activate or manually in the screen shown above. So, click Add and then Apply to fully add this IAP into AirWave.
Folders
AirWave folders are hierarchical and are used for these purposes:
Aruba Instant Validated Reference Design
Aruba Instant management using Aruba AirWave | 168
l
Controlling which AirWave users have access to which devices
l
Reporting
l
Alerting
You can organize folders in any way that makes sense to you. Typically, folders are organized by geography or
business unit as is shown in below figures:
Figure 80 Folder structure organized by geography
Figure 81 Folder structure organized by line of business
Roles
Each AirWave user is assigned a role, which is either created by an administrator, or created automatically based on
the organization string of a new IAP. The role determines the following user capabilities:
l
Devices that the user can view
l
Permissions that the user has, including whether the user can configure devices or reboot them
l
Access that the user has to VisualRF or information about rogue APs
169 | Aruba Instant management using Aruba AirWave
Aruba Instant Validated Reference Design
Below is an example of a role that grants a user read-only access to devices in the Distribution Centers folder and its
subfolders.
Figure 82 Configuring an AirWave role
Managing Device Firmware with AirWave
When you manage a large network, you must maintain common firmware versions for ease of troubleshooting and
maintenance. AirWave can automatically upgrade or downgrade IAP firmware as IAPs are added to AirWave. After
devices have been added, you can upgrade firmware in schedulable, multicluster jobs.
The first step in planning firmware updates is to load the required firmware version to the AirWave server. You can
either pick from the stable, generally available releases that are hosted in the cloud by Aruba Activate, or you can
manually upload any firmware version AirWave. If you select the manual method, you must load the correct firmware
image for each device type in your network.
New firmware images are added to Aruba Activate when Aruba determines that they are stable, typically a few
weeks after they are released. Setting up AirWave to Automatically Update Firmware on New Devices
Click on the Firmware tab on the top menu bar within the Instant Group. On this screen, be sure to toggle "Enforce
Group Firmware Version" to Yes and if desired, allow downgrades of devices. In the Desired Version box, select the
code version that the customer wants to standardize on for this Group. Once AirWave sees the IAPs show up in the
group, it will compare firmware versions, detect that the firmware version is not the same as the desired, and then
designate the next communication from the VC to be an attempt to upgrade firmware. During the upgrade, the VC
and APs will be marked as down (though you may see that you still have access while the APs are downloading the
image – so the down message is somewhat premature). Once all devices in the cluster are upgraded, then AirWave
will get a message to return the devices to up status.
Aruba Instant Validated Reference Design
Aruba Instant management using Aruba AirWave | 170
There are two places where Firmware files are stored - the image server in the cloud and in AirWave's local
database. There currently is a delay when Aruba released a code version until it is shown in the image server list. If
a desired version is not listed but is known to be GA, you must manually download all Instant firmware files related
to the specific release and upload them into AirWave.
If you select a file from the image server, AirWave will grab those files automatically, download them, and place
them in its local database. Any Instant AP that needs an upgrade from AirWave will be handled by AirWave and not
from the cloud service.
Bulk Upgrades of IAPs
Most device lists in AirWave have a Modify Devices feature that allows you to perform actions such as auditing,
rebooting, and reporting on any set of devices. The Modify Devices feature is the best way to perform and schedule
firmware upgrades on an unlimited number of devices, as shown in below figure.
171 | Aruba Instant management using Aruba AirWave
Aruba Instant Validated Reference Design
Figure 83 Configuring AirWave bulk firmware upgrade options
In groups that have the “Instant GUI Config” feature enabled, all devices must run the same firmware version.
Therefore, firmware must be updated on every cluster in a group. When Instant devices are managed by AirWave, each device downloads its own image from the AirWave server. Make sure that each AP in a cluster has access to AirWave through HTTPS or HTTP for firmware updates.
Monitoring Firmware Upgrade Jobs
You can track the status of current and scheduled upgrade jobs on the Firmware Upgrade Jobs screen of the
AirWave WebUI, as shown in below figure.
Figure 84 Displaying AirWave firmware upgrade jobs
Aruba Instant Validated Reference Design
Aruba Instant management using Aruba AirWave | 172
Managing Device Configurations with AirWave
Managing device configurations is one of the biggest challenges in a large network deployment. Nonstandard
configurations make it hard to maintain and troubleshoot the network. To adapt to the complexity of a large network,
a network administrator needs a simple way to configure some devices in a way that deviates from the standard
configuration policy. In addition, when a network administrator must make complicated changes in too many places,
there is always the risk of human error.
AirWave offers a GUI-based tool and a legacy template system for centralized management of Aruba Instant
configurations. This section describes configuration with the GUI-based tool.
First, the Instant Config needs to be enabled. This is done in the per Group Basic Settings. In AirWave, navigate to
Groups, hover over the wrench icon next to the Instant Group, and click "Basic".
Enable the Instant GUI Config. Wait a few minutes for the Instant Config service to start and you should be able to
click on "Instant Config" in the Group to enter the IAP GUI.
Second, on this same page, ensure that the Group Display options are set to "Only Devices in this Group" or
"Selected Device Types" with the selection set to Aruba Instant.
After you add devices to an IGC group, you can no longer use the internal device GUI to change the configuration, all
configuration changes are executed through AirWave.
At this point, AirWave has its first group created and the desired configuration from the first IAP. Subsequent Instant
APs should now automatically provision, sync firmware, and get the needed configuration.
For this AirWave IGC capability, you must run Aruba Instant 3.2 or greater and all devices in a group must be
173 | Aruba Instant management using Aruba AirWave
Aruba Instant Validated Reference Design
running the same firmware version.
IGC has a very similar look and feel to the VC WebUI and includes wizards such as the New Wireless Setup
Wizard. An important addition to IGC is the context. A user in IGC is either in a group context or in a cluster-specific
context. The current context is displayed at the top of the left panel in IGC.
To make configuration changes to every cluster in the group, start in the group context and select the settings that
you want to apply. Managing Device Configurations with AirWave shows how you can make changes to the
AirGroup settings for an entire group.
Figure 85 AirWave IGC: changing AirGroup settings for an entire group
After you made the change, AirWave immediately queues up the appropriate commands to send to each cluster. The
next time a cluster contacts AirWave (which it typically does every minute), the commands are sent, and the
devices start to check in every 5 seconds to speed up the confirmation and subsequent configuration changes.
If one cluster in a group has a different requirement and requires you to make cluster-specific overrides to the group
policy, enter cluster-specific mode by selecting the group name in the left pane and selecting the cluster to modify. Figure 86 AirWave IGC: Overriding a group policy for a cluster
Aruba Instant Validated Reference Design
Aruba Instant management using Aruba AirWave | 174
By dragging the sticky note icon to a field, you can add notes to any setting. (This method works for most fields.)
After you apply and confirm the override of the device, the override is highlighted in group mode with a yellow
asterisk.
Figure 87 AirWave IGC: Override with a sticky note
IGC ignore country code by default, for US/Japan/Israel code IAPs, users do not need to care about country code.
For non-US/Japan/Israel code IAPs, user needs to turn on [Allow Configuration of Country Code] under IGC>Airwave->Airwave Setting, then set correct country code under System->General page.
AirWave use cases
AirWave for the Distributed Enterprise
In a public facing deployment, such as a coffee shop chain or hotspot provider, a large number of users might access
the network. AirWave stores historical data, including usage and signal quality, on a per-user basis. This data is
stored in round-robin database (RRD) files that are created as users are detected. You can configure how many days
the data is stored, which impacts the size of the RDD files. In an environment with many unique users, it is critical
that you do not store the data too long to prevent the RDD files from becoming too large. Aruba recommends a
storage time of 4 weeks or shorter.
The AirWave Rogue Access Point Intrusion Detection System (RAPIDS) lets you to create customized rules to
identify and act upon rogue access points. If users have access to an open or captive-portal wireless network, it is
important to prevent an attacker from spoofing the network. Use a RAPIDS rule to identify such a network and take
action if necessary, as shown in below figure.
175 | Aruba Instant management using Aruba AirWave
Aruba Instant Validated Reference Design
Figure 88 Configuring a RAPIDS classification rule
AirWave for the Small and Medium Enterprise
If IAPs are deployed in clusters rather than as standalone devices, you must be able to receive cluster reports. By
placing each cluster in its own folder, reports and alerts can be generated for each individual folder.
If a user experiences connectivity problems and contacts the IT help desk, the IT engineer can search for the user in
AirWave through many fields, including user name and MAC address fields. Near-real-time information is available
about the status of the user connection, including the status of the user device and the VC. This capability can help
the IT engineer to quickly identify the source of a connectivity problem, as shown in below figure.
Figure 89 AirWave diagnostic capabilities
In a multi-AP environment, you must be able to check on the status of the RF. A common source of user complaints
stems from RF saturation. AirWave can provide reports and alerts that allow you to be informed about the health of
the network and be notified of unusual situations before problems occur.
Aruba Instant Validated Reference Design
Aruba Instant management using Aruba AirWave | 176
Below figure is a screen shot of the RF Health dashboard, which can help you to identify areas with excessive radio
utilization.
Figure 90 AirWave RF Health dashboard
Aruba recommends that you set up triggers to enable AMP to send alerts when a particular radio utilization threshold
is exceeded. Each RF environment is different. One common recommendation is to set up a trigger for interference
of over 50% or a busy time of over 75% for a 15-minute interval.
Figure 91 Setting up alert triggers in AirWave
177 | Aruba Instant management using Aruba AirWave
Aruba Instant Validated Reference Design
AirWave for a Home Office
AirWave can display the VPN IP address of an AP and link to it as well.
Figure 92 Viewing VPN IP addresses in AirWave
The AirWave Run command provides CLI access to remote networks and allows the network administrator to view
detailed network information such as VPN status of a RAP.
Figure 93 Displaying the VPN status with the AirWave Run command
Aruba Instant Validated Reference Design
Aruba Instant management using Aruba AirWave | 178
Chapter 6
Network Visibility using AppRF on Aruba Instant
AppRF on Instant Access Points
Introduction
AppRF is Aruba's custom-built Layer 7 (L7) firewall capability. It is introduced in Instant OS 4.1 and consists of an
on-board Deep Packet Inspection (DPI) and a cloud-based Web Policy Enforcement (WPE) service.
The WPE is hosted by aruba.brightcloud.com and allows creating local firewall policies based on the types of traffic
identified. The WPE capabilities require the IAP to have a WPE subscription.
IAPs with DPI capability analyze data packets to identify applications which are in use and allow creation of access
rules, to determine client access to applications, application categories, web categories, and website URLs based
on security ratings. You can also define traffic shaping policies such as bandwidth control and QoS per application,
for client roles. For example, you can block bandwidth monopolizing applications on a guest role within an enterprise.
In K-12, web-filtering is required for Children’s Internet Protection Act (CIPA) compliance and is a mandate for E-rate
funding.
The AppRF feature provides application visibility for analyzing client traffic flow. IAPs support both, the power
of in-device packet flow identification and dynamically updated cloud-based web categorization.
For application traffic, the initial packets pass through the DPI engine residing on the IAP for classification. Once the
session is classified, firewall actions are applied to that traffic based on the ACLs created by the admin. For web
URL traffic, IAP searches on BrightCloud, and gets the Web Category and Web Reputation information about the
sessions. Once the sessions are classified, we can create an ACL to perform the following actions on traffic:
l
Permit/Deny
l
Bandwidth Contracts
l
Log
l
Blacklist
l
DSCP Tag
l
802.1p priority
l
Disable Scanning
The universal knob to turn on AppRF is on Virtual Controller (VC):IAP UI - System > General > AppRF visibility
Aruba Instant Validated Reference Design
Network Visibility using AppRF on Aruba Instant | 179
IAP
IAP
IAP
IAP
# configure t
(config) # dpi
(config) #end
# commit apply
AppRF visibility configuration is enabled if visibility is required. Enforcement does not require this knob to be
enabled.
DPI
AppRF DPI is supported only on 32 MB platforms like IAP 103, 108, 109, 114, 115, 155, 204, 205, 214, 215, 224,
225, and 275. Due to hardware memory limitation, it is not supported on IAPs with 16 MB flash memory which
includes IAP 104, 105, Rap3, 134, 135 and 175. AppRF DPI engine resides on IAP and supports predefined apps
and app categories. The number of supported apps increases with upgrades. To view the list of applications and
application categories execute the following CLI command:IAP# show dpi app all
IAP# show dpi appcategory all
For mixed-class deployments (web-filtering-only-supported-APs and full-apprf-supported-APs) works as follows.
While configuring, there is no explicit check for AP capabilities. That is, you can configure application rules even on
an AP which supports only web filtering, but enforcement or visualization will take place only for web traffic.
Each AP visualizes and enforces the traffic as per its capability.
On IAPs that support only web filtering, for example, IAP 105, if application classification rules are configured, it is
considered a NO-OP; as if that rule does not exist.
On IAPs that support all AppRF functions, for example, IAP-225, the same application classification rules are
enforced.
For visualization, it is on a per-ap basis. You have to click on per ‘AP or client’ view to see the AppRF charts.
In IAP-105, the AppRF shows only 2 graphs – the web-category and web-reputation
In IAP-225, all the four charts such as Application, Application category, web-category and web-reputation are
shown.
180 | Network Visibility using AppRF on Aruba Instant
Aruba Instant Validated Reference Design
When clients roam, sessions are transferred from old AP to new AP. It works on already classified sessions. If
clients roam before the flow is classified, app classification will take longer because the new AP needs to reclassify
the session.
Web Content Filtering
Web Content Filtering or Web URL filtering is the ability to classify and enforce policies on web based traffic, that is,
all browser based URLs, HTTP, and HTTPS traffic accessed by the users on the network. It is managed on cloud by
BrightCloud, which updates its database real-time.
Categories
Web URLs are classified into one or more categories out of the existing 81 different web categories. For example,
Facebook can be classified into social-media, instant-messaging or gaming depending on what the user does with
the network. Current number of categories can be identified using:
IAP# show dpi webcategory all
Reputation
Web URLs are also classified into 5 web reputation groups based on the web reputation index score:
Reputation
WRI Score
Trustworthy
81-100
Moderate Risk
41-60
Moderate Risk
41-60
Suspicious
21-40
High Risk
1-20
Trustworthy: These are well-known sites with strong security practices and rarely exhibit characteristics that
expose the user to security risks. There is a low probability that a user will be exposed to a malicious payload.
Low Risks: These are benign sites, and rarely exhibit characteristics that expose the user to security risks. There is
a low probability that a user will be exposed to a malicious payload.
Moderate Risks: These sites have exhibited some characteristics that suggest security risk. These is some
probability that user will be exposed to malicious payload.
Suspicious Sites: There is a higher than average probability that the user will be exposed malicious links or
payloads.
High Risks: There is a high probability that the user will be exposed malicious links or payloads.
The current reputation and category of a site can be found out on link.
Aruba Instant Validated Reference Design
Network Visibility using AppRF on Aruba Instant | 181
The current reputation and category of a site can also be found out using IAP CLI:Here, we will try for www.cnn.com, which is already queried by the IAP due to previous traffic.
IAP# show dpi webcategory-lookup www.cnn.com
Input URL: www.cnn.com
Found CACHED RESULT:
URL: cnn.com REP: 81 A1: 0, Serial = 0x200001
Index: 0 Category: news-and-media (63) Confidence level: 99
Now, we will try a new site.
IAP# show dpi webcategory-lookup www.bbc.com
Input URL: www.bbc.com
Request sent for CLOUD LOOKUP, please try again.
Which is cached now.
IAP# show dpi webcategory-lookup www.bbc.com
Input URL: www.bbc.com
Found CACHED RESULT:
URL: bbc.com REP: 96 A1: 0, Serial = 0x200001
Index: 0 Category: news-and-media (63) Confidence level: 99
The high-end 256MB+ memory variant IAPs (115, 135, RAP-155, 215, 225) cache 500k (1/2 Million) entries, and the
low-end 128MB memory variant IAPs (103, 105, RAP-109, 205) cache 100k entries. These entries expire by default
after four days, or are dynamically replaced when under cache pressure.
182 | Network Visibility using AppRF on Aruba Instant
Aruba Instant Validated Reference Design
The web URL database is maintained by BrightCloud. Each IAP in the cluster can independently access the
database on aruba.brightcloud.com and maintain its own cache.
Any classification anomalies can be directly reported on BrightCloud’s online URL categorization and reputation
change request page.
URL categorization change request link.
URL reputation change request link.
Classification failure can happen if:
l
DPI engine fails
l
WAN uplink issues affect web classification
If sessions are not classified, they will follow the default rule specified in your user role. To create a strict
enforcement of unclassified session, you can manually create a rule to deny an "unknown" session.
Aruba Instant Validated Reference Design
Network Visibility using AppRF on Aruba Instant | 183
Configuration
Enforcement through policies
IAP UI-SSID Wizard > Access Tab OR IAP UI > Security > Roles and apply to SSID
The image below shows how to club multiple applications together.
The first image below provides instructions on how to deny Facebook and enable log. The second image provides
instructions on how to deny high risk websites and blacklist the user.
184 | Network Visibility using AppRF on Aruba Instant
Aruba Instant Validated Reference Design
If you enable log, the output of the show log security command displays the logs details as shown in the following
example:IAP# show log security 10
Oct 16 22:30:20 stm[2242]: <124006> <WARN> |AP 94:b4:0f:cb:dc:98@33.33.33.1 stm| TCP
srcip=199.59.149.198 srcport=443 dstip=192.168.200.109 dstport=50925, dpi-dst=facebook, action=deny
The below image provides instructions on how to throttle YouTube traffic and prioritize Lync.
Visibility in UI
Per AP view
Click on AP name and AppRF tab at the bottom right, as shown in the image below.
Aruba Instant Validated Reference Design
Network Visibility using AppRF on Aruba Instant | 185
Per client view
Click on client name and AppRF tab at the bottom right, as shown below.
Per SSID view
Click on SSID and AppRF tab at the bottom right, as shown below.
App RF tab details
Four charts for App, App Category, Web category, Web reputation. See image below.
186 | Network Visibility using AppRF on Aruba Instant
Aruba Instant Validated Reference Design
Hover the mouse over “Category” to see data utilization for a category/app. See image below.
Click on “Chart” to expand and see a table/chart view. See image below.
Click to filter on per-app and to see per-user data. See image below.
Aruba Instant Validated Reference Design
Network Visibility using AppRF on Aruba Instant | 187
Toggle to switch between list and chart view. See image below.
For more configuration examples, refer to the Aruba Instant User Guide that is available at the Aruba support
website.
Troubleshooting
Show commands
“show dpi app” showing a static list of supported apps
IAP# show dpi app all
Pre-defined Application List
---------------------------01net 050plus 0zz0 10050net 10086cn
104com 1111tw 114la 115com 118114cn
:
:
<truncated>
:
:
zol zonealarm-update zoo zoznam zshare
zum zynga
Total applications = 1957
“Show dpi app <app-name>” shows app category for specific apps:IAP# show dpi app facebook
Pre-defined Application
----------------------Name App ID App Category Default Ports
--------- -----------------------facebook 244 social-networking tcp 80 443
IAP# show dpi app bittorrent
Pre-defined Application
----------------------Name App ID App Category Default Ports
--------- ------------ ------------bittorrent 15 peer-to-peer tcp 1024-65535 udp 1024-65535
188 | Network Visibility using AppRF on Aruba Instant
Aruba Instant Validated Reference Design
To analyze the IAP and client traffic data when deep packet inspection is enabled, execute the “show data path
session dpi” command at the IAP CLI. The Show data path session dpi* command displays the flags in output that
allows you to analyze session classification. Use this command in conjunction with the “include” filter to see the
enhanced outputs.
To clear these sessions and see fresh sessions created by client, use:IAP#clear datapath session
You can always use the “Include” command with “Show” command to filter specific outputs.
Traces
Check the current trace settings through:
Show trace info
Turn on the sub components “BCA DATA” and “BCA CONTROL”. You will notice that there are other subcomponents as well.
IAP# trace component DPIMGR sub-component x
Invalid sub-component name(x). Valid sub-components for DPIMGR are:
GENERAL,
CLI,
QOSMOS DATA,
QOSMOS CONTROL,
DPIMGR CONTROL,
FW VISIBILITY,
BCA DATA,
BCA CONTROL,
Aruba Instant Validated Reference Design
Network Visibility using AppRF on Aruba Instant | 189
SYSLOG,
ALL
IAP# trace component DPIMGR sub-component "BCA DATA"
IAP# trace component DPIMGR sub-component "BCA CONTROL"
Perform a lookup as shown below:
IAP# show dpi webcategory-lookup www.time.com
Input URL: www.time.com
Request sent for CLOUD LOOKUP, please try again.
IAP# show trace log DPIMGR 100 Oct 15 19:50:30 trace_on: Tracing to "/var/log/trace/dpimgr.log" started
bcaruba: DPIMGR got trace config: mac(00:00:00:00:00:00), ip(0.0.0.0), level(7), sub_comp_
flag:0x00000000
bcaruba: <358000> <ERRS> |AP 94:b4:0f:cb:dc:98@33.33.33.1 dpimgr| ^[func bca_syslog] [line
209] [msg Upating smart cache to version 0.1]
bcaruba: DPIMGR got trace config: mac(00:00:00:00:00:00), ip(0.0.0.0), level(7), sub_comp_
flag:0x00000040
bcaruba: Tracing enabled for BCA DATA
bcaruba: DPIMGR got trace config: mac(00:00:00:00:00:00), ip(0.0.0.0), level(7), sub_comp_
flag:0x000000c0
bcaruba: Tracing enabled for BCA DATA
bcaruba: Tracing enabled for BCA CONTROL
Oct 15 23:21:24|94:b4:0f:cb:dc:98|---.---.---.---|BCA DATA|dpimgr_handle_brightcloud_
data:416|REQ URI:www.time.com for id = 0x200001
Oct 15 23:21:24|94:b4:0f:cb:dc:98|---.---.---.---|BCA DATA|bca_lookup:211|sent for cloud/cache
lookup.
Oct 15 23:21:25|94:b4:0f:cb:dc:98|---.---.---.---|BCA CONTROL|bca_print_req:123|URL: time.com
REP: 50 A1: 0, Serial = 0x200001
Oct 15 23:21:25|94:b4:0f:cb:dc:98|---.---.---.---|BCA CONTROL|bca_print_req:133|Index: 0
Category: news-and-media(63) Confidence level: 93
If traffic flow is huge, set filters using client mac or IP through:
IAP# trace mac 11:11:11:11:11:11
Got trace config for CLI_2: mac(11:11:11:11:11:11), ip(0.0.0.0), level(7), sub_comp_
flag:0x00000000
IAP# trace ip 1.1.1.1
Got trace config for CLI_2: mac(11:11:11:11:11:11), ip(1.1.1.1), level(7), sub_comp_
flag:0x00000000
Remove the trace filter by:
IAP# trace mac 00:00:00:00:00:00
IAP# trace ip 0.0.0.0
Disable the subcomponent trace through:
IAP# no trace component DPIMGR sub-component "ALL"
190 | Network Visibility using AppRF on Aruba Instant
Aruba Instant Validated Reference Design
Appendix
Performance impact due to DPI
The Virtual Controller shows management information pulled in from each IAP in a cluster. However, the DPI, Web
Policy Enforcement, and firewall policies are independently executed on each IAP in a cluster. Hence, the size of the
IAP cluster does not impact AppRF scalability.
Performance of an IAP is not affected due to its dynamic CPU management. Under normal network load, typical
deployments with 16 clients per AP, DPI module’s CPU utilization is very minimal even while classifying many
sessions. However, DPI processing is tied to IAP’s dynamic CPU management to ensure that this processing in a
loaded system does not affect control plane or management plane traffic. For example, on a heavily loaded IAP,
where IAP CPU becomes 80% busy, dynamic CPU management stops DPI/classifying sessions to allow other high
priority tasks to continue. The stopped sessions are marked as “incomplete”, while enforcement and visibility of
previously classified sessions are not affected. The classification is a function of a new session creation rate and
APs’ CPU capability. Hence, a higher end IAP 225 can classify 50 new sessions per second, while IAP 109 can only
classify 20 new sessions per second.
Custom error page
Using this feature starting 4.2 onwards, we can set redirect URL, when client access URL, which is denied by IAP.
Step 1:
Add a Custom Blocked Page URL “https://www.sohu.com/”
IAP UI - Security > Custom Blocked Page URL
Aruba Instant Validated Reference Design
Appendix | 191
URL must be absolute URL which starts with a scheme “http://” or “https://”.
Step2：binding the URL to a Roles “example”
IAP UI - Security > Roles > Rule type > Blocked Page URL
Step3: Also need to configure DPI ACL deny rule
IAP UI - Security > Roles > Rule type > Access control
192 | Appendix
Aruba Instant Validated Reference Design
If the clients access www.baidu.com, the following redirect URL “www.sohu.com” will happen on the browser as
mentioned below:http://www.sohu.com/?user_ip=%3C192.168.1.105%3E&dest_ip=%3C115.239.210.27%3E&app_
name=%3Cbaidu%3E&web_rep=%3Ctrustworthy-sites%3E&web_cat=%3Csearch-engines%3E
Check redirect URL for packet captured on the client:-
Custom error page feature only works for http sites as follows:
Send HTTP 302 with “Location” redirect URL to clients
Send HTTP 200 with deny page as HTML body to clients
It doesn’t work for https sites.
If the client has a standard browser, it could analyze HTTP 302/200 packets, and perform redirecting or displaying.
If the client has an app, it cannot process HTTP 302/200 as a standard browser.
Websites dependency on web category
A few websites initiate sessions to, many URLs and not just a few, which keep on changing dynamically. Let’s take
an example of bbc. If one wants to block www.bbc.com, using the application DPI rule, one would use the below
configuration:-
Aruba Instant Validated Reference Design
Appendix | 193
However, if the client opens www.bbc.com, it still works. This is because the browser initiates TCP connection to a
number of URLs, which spawn as a result. You can use “show datapath session dpi”, to find out all the TCP
connections initiated by client and how they are classified if blocked.
For example, below is the screen shot of when a client opens www.bbc.com. DNS query gets a resolution answer to
23.235.47.81. As you notice, the TCP connection starts smoothly and not blocked, despite the rules to block app,
bbc, and bbc-player.
If you look at show datapath session dpi for IP 23.235.47.81:
IAP205# show datapath session dpi
Datapath Session Table Entries
------------------------------
Flags: F - fast age, S - src NAT, N - dest NAT
D - deny, R - redirect, Y - no syn
H - high prio, P - set prio, T - set ToS
C - client, M - mirror, V - VOIP
194 | Appendix
Aruba Instant Validated Reference Design
I - Deep inspect, U - Locally destined
s - media signal, m - media mon, a - rtp analysis
E - Media Deep Inspect, G - media signal
A - Application Firewall Inspect
RAP Flags: 0 - Q0, 1 - Q1, 2 - Q2, r - redirect to master, t - time based
Source IP Destination IP Prot SPort Dport App Webcat
WebRep Packets Bytes PktsDpi Flags
---------------- -------------- ---- ----- ----- -------------------------- ------------------------- ------ ------- ----- ------- ----23.235.47.81 192.168.3.100 6 80 50841 http [67 ] news-and-media [63 ] 5 0 0 6 192.168.3.100 23.235.47.81 6 50841 80 http [67 ] news-and-media [63 ] 5 0 0 1 C
If you notice, the session has been classified as an app http and not as bbc or bbc-player. However, Webcategory is
news-and-media. Flags field indicates that this connection is not denied.
DPI signatures are not updated in real time and get updated when IAP code is upgraded. However, the Web content
filtering database, hosted by bright cloud, is a more up-to-date version of it. Hence, to block access to
www.bbc.com, in this case, we identified the other TCP connections that the client created to open up the webpage.
Found out that they were not getting blocked but were resulting in page being opened up on the browser. Also they
are being classified as HTTP in app category but as news-and-media in web category. Ideally it should have been
classified as bbc in app category, but due to limited signatures in inbuilt DPI engine, it could not be so.
These cases would always arise as numerous sites update their IP address and DNS resolutions quickly. To work
around these scenarios, please use web category to identify and block it. In the above scenario, the below rule would
work, and result into the “HTTP status 403 – Access is denied” webpage if client tries to access www.bbc.com:
Aruba Instant Validated Reference Design
Appendix | 195
Terminology
Acronyms and Abbreviations
The following table lists the abbreviations used in this document.
Table 19: List of abbreviations
Abbreviation
Expansion
AMP
AirWave Management Platform
ARM
Adaptive Radio Management
ARP
Address Resolution Protocol
BSS
Basic Server Set
BSSID
Basic Server Set Identifier
CA
Certification Authority
CLI
Command Line Interface
CoA
Change of Authorization
CL3
Centralized Layer 3
CL2
Centralized Layer 2
DL3
Distributed layer 3
DL2
Distributed layer 2
DPI
Deep Packet Inspection
DHCP
Dynamic Host Configuration Protocol
DMO
Dynamic Multicast Optimization
DMZ
Demilitarized Zone
DNS
Domain Name System
DRP
Dynamic Radius Proxy
EAP-TLS
Extensible Authentication Protocol- Transport Layer Security
EAP-TTLS
Extensible Authentication Protocol-Tunneled Transport
Layer Security
GRE
Aruba Instant Validated Reference Design
Generic Routing Encapsulation
Terminology | 196
Table 19: List of abbreviations
Abbreviation
Expansion
IAP
Instant Access Point
IDS
Intrusion Detection System
IGC
Instant GUI Config
IEEE
Institute of Electrical and Electronics Engineers
ISP
Internet Service Provider
LEAP
Lightweight Extensible Authentication Protocol
MX
Mail Exchanger
MAC
Media Access Control
NAS
Network Access Server
NAT
Network Address Translation
NS
Name Server
NTP
Network Time Protocol
PEAP
Protected Extensible Authentication Protocol
PEM
Privacy Enhanced Mail
PoE
Power over Ethernet
QoS
Quality of Service
RADIUS
Remote Authentication Dial In User Service
UI
User Interface
VC
Virtual Controller
VPN
Virtual Private Networks
VSA
Vendor-Specific Attributes
WLAN
Wireless Local Area Network
Glossary
The following table lists the terms and their definitions used in this document.
197 | Terminology
Aruba Instant Validated Reference Design
Table 20: List of Terms
Term
Definition
802.11
An evolving family of specifications for wireless LANs developed by a
working group of the Institute of Electrical and Electronics Engineers
(IEEE). 802.11 standards use the Ethernet protocol and CSMA/CA (carrier
sense multiple access with collision avoidance) for path sharing.
802.11a
Provides specifications for wireless systems. Networks using 802.11a
operate at radio frequencies in the 5GHz band. The specification uses a
modulation scheme known as orthogonal frequency-division multiplexing
(OFDM) that is especially well suited to use in office settings. The
maximum data transfer rate is 54 Mbps.
802.11b
WLAN standard often called Wi-Fi; backward compatible with 802.11.
Instead of the phase-shift keying (PSK) modulation method historically
used in 802.11 standards, 802.11b uses complementary code keying
(CCK), which allows higher data speeds and is less susceptible to
multipath-propagation interference. 802.11b operates in the 2.4 GHz band
and the maximum data transfer rate is 11 Mbps.
802.11g
Offers transmission over relatively short distances at up to 54 Mbps,
compared with the 11 Mbps theoretical maximum of 802.11b. 802.11g
operates in the 2.4 GHz band and employs orthogonal frequency division
multiplexing (OFDM), the modulation scheme used in 802.11a, to obtain
higher data speed. Computers or terminals set up for 802.11g can fall
back to speeds of 11 Mbps, so that 802.11b and 802.11g devices can be
compatible within a single network.
802.11n
Wireless networking standard to improve network throughput over the two
previous standards 802.11a and 802.11g with a significant increase in the
maximum raw data rate from 54 Mbps to 600 Mbps with the use of four
spatial streams at a channel width of 40 MHz. 802.11n operates in the 2.4
and 5.0 bands.
AP
An access point (AP) connects users to other users within the network and
also can serve as the point of interconnection between the WLAN and a
fixed wire network. The number of access points a WLAN needs is
determined by the number of users and the size of the network.
access point mapping
The act of locating and possibly exploiting connections to WLANs while
driving around a city or elsewhere. To do war driving, you need a vehicle,
a computer (which can be a laptop), a wireless Ethernet card set to work in
promiscuous mode, and some kind of an antenna which can be mounted
on top of or positioned inside the car. Because a WLAN may have a range
that extends beyond an office building, an outside user may be able to
intrude into the network, obtain a free Internet connection, and possibly
gain access to company records and other resources.
Aruba Instant Validated Reference Design
Terminology | 198
Table 20: List of Terms
Term
Definition
ad-hoc network
A LAN or other small network, especially one with wireless or temporary
plug-in connections, in which some of the network devices are part of the
network only for the duration of a communications session or, in the case
of mobile or portable devices, while in some close proximity to the rest of
the network.
band
A specified range of frequencies of electromagnetic radiation.
DHCP
The Dynamic Host Configuration Protocol (DHCP) is an auto-configuration
protocol used on IP networks. Computers or any network peripherals that
are connected to IP networks must be configured, before they can
communicate with other computers on the network. DHCP allows a
computer to be configured automatically, eliminating the need for a
network administrator. DHCP also provides a central database to keep
track of computers connected to the network. This database helps in
preventing any two computers from being configured with the same IP
address.
DNS Server
A Domain Name System (DNS) server functions as a phonebook for the
Internet and Internet users. It converts human readable computer
hostnames into IP addresses and vice-versa.
A DNS server stores several records for a domain name such as an
address 'A' record, name server (NS), and mail exchanger (MX) records.
The Address 'A' record is the most important record that is stored in a DNS
server, because it provides the required IP address for a network
peripheral or element.
DST
Daylight saving time (DST), also known as summer time, is the practice of
advancing clocks, so that evenings have more daylight and mornings
have less. Typically clocks are adjusted forward one hour near the start of
spring and are adjusted backward in autumn.
EAP
Extensible authentication protocol (EAP) refers to the authentication
protocol in wireless networks that expands on methods used by the pointto-point protocol (PPP), a protocol often used when connecting a
computer to the Internet. EAP can support multiple authentication
mechanisms, such as token cards, smart cards, certificates, one-time
passwords, and public key encryption authentication.
fixed wireless
Wireless devices or systems in fixed locations such as homes and offices.
Fixed wireless devices usually derive their electrical power from the utility
mains, unlike mobile wireless or portable wireless which tend to be
battery-powered. Although mobile and portable systems can be used in
fixed locations, efficiency and bandwidth are compromised compared with
fixed systems.
frequency allocation
Use of radio frequency spectrum regulated by governments.
frequency spectrum
Part of the electromagnetic spectrum.
199 | Terminology
Aruba Instant Validated Reference Design
Table 20: List of Terms
Term
Definition
hotspot
A WLAN node that provides Internet connection and virtual private
network (VPN) access from a given location. A business traveler, for
example, with a laptop equipped for Wi-Fi can look up a local hot spot,
contact it, and get connected through its network to reach the Internet and
their own company remotely with a secure connection. Increasingly, public
places, such as airports, hotels, and coffee shops are providing free
wireless access for customers.
IEEE 802.11 standards
The IEEE 802.11 is a set of standards that are categorized based on the
radio wave frequency and the data transfer rate.
POE
Power over Ethernet (PoE) is a method of delivering power on the same
physical Ethernet wire used for data communication. Power for devices is
provided in one of the following two ways:
l
Endspan— The switch that an AP is connected for power supply.
l
Midspan— A device can sit between the switch and APs
The choice of endspan or midspan depends on the capabilities of the
switch to which the IAP is connected. Typically if a switch is in place and
does not support PoE, midspan power injectors are used.
PPPoE
Point-to-Point Protocol over Ethernet (PPPoE) is a method of connecting
to the Internet typically used with DSL services where the client connects
to the DSL modem.
QoS
Quality of Service (QoS) refers to the capability of a network to provide
better service to a specific network traffic over various technologies.
RF
Radio Frequency (RF) refers to the portion of electromagnetic spectrum in
which electromagnetic waves are generated by feeding alternating current
to an antenna.
TACACS
Family of protocols that handle remote authentication and related services
for network access control through a centralized server.
TACACS+
Derived from TACACS but an entirely new and separate protocol to
handle AAA services. TACACS+ uses TCP and is not compatible with
TACACS. Because it encrypts password, username, authorization, and
accounting, it is less vulnerable than RADIUS.
VPN
A Virtual Private Network (VPN) network that uses a public
telecommunication infrastructure, such as the Internet, to provide remote
offices or individual users with secure access to their organization's
network. A VPN ensures privacy through security procedures and
tunneling protocols such as the Layer Two Tunneling Protocol ( L2TP ).
Data is encrypted at the sending end and decrypted at the receiving end.
Aruba Instant Validated Reference Design
Terminology | 200
Table 20: List of Terms
Term
Definition
W-CDMA
Officially known as IMT-2000 direct spread; ITU standard derived from
Code-Division Multiple Access (CDMA). Wideband code-division multiple
access (W-CDMA) is a third-generation (3G) mobile wireless technology
that promises much higher data speeds to mobile and portable wireless
devices than commonly offered in today's market.
Wi-Fi
A term for certain types of WLANs. Wi-Fi can apply to products that use
any 802.11 standard. Wi-Fi has gained acceptance in many businesses,
agencies, schools, and homes as an alternative to a wired LAN. Many
airports, hotels, and fast-food facilities offer public access to Wi-Fi
networks.
WEP
Wired equivalent privacy (WEP) is a security protocol specified in 802.11b,
designed to provide a WLAN with a level of security and privacy
comparable to what is usually expected of a wired LAN. Data encryption
protects the vulnerable wireless link between clients and access points;
once this measure has been taken, other typical LAN security
mechanisms such as password protection, end-to-end encryption, virtual
private networks (VPNs), and authentication can be put in place to ensure
privacy.
wireless
Describes telecommunications in which electromagnetic waves (rather
than some form of wire) carry the signal over part or all of the
communication path.
wireless network
In a Wireless LAN (WLAN), laptops, desktops, PDAs, and other computer
peripherals are connected to each other without any network cables.
These network elements or clients use radio signals to communicate with
each other. Wireless networks are set up based on the IEEE 802.11
standards.
WISP
Wireless ISP (WISP) refers to an internet service provider (ISP) that allows
subscribers to connect to a server at designated hot spots (access points)
using a wireless connection such as Wi-Fi. This type of ISP offers
broadband service and allows subscriber computers, called stations, to
access the Internet and the web from anywhere within the zone of
coverage provided by the server antenna, usually a region with a radius of
several kilometers.
wireless service provider
A company that offers transmission services to users of wireless devices
through radio frequency (RF) signals rather than through end-to-end wire
communication.
WLAN
Wireless local area network (WLAN) is a local area network (LAN) that the
users access through a wireless connection.
201 | Terminology
Aruba Instant Validated Reference Design