Virtual Branch Networks

Virtual Branch Networks
Version 3.3.2-rn3.0


Validated Reference Design

Copyright
© 2009 Aruba Networks, Inc. AirWave®, Aruba Networks®, Aruba Mobility Management System®, Bluescanner, For Wireless That
Works®, Mobile Edge Architecture®, People Move. Networks Must Follow®, RFProtect, The All Wireless Workplace Is Now Open For
Business, Green Island, and The Mobile Edge Company® are trademarks of Aruba Networks, Inc. All rights reserved. All other
trademarks are the property of their respective owners.

Open Source Code
Certain Aruba products include Open Source software code developed by third parties, including software code subject to the GNU
General Public License (“GPL”), GNU Lesser General Public License (“LGPL”), or other Open Source Licenses. The Open Source code
used can be found at this site:
http://www.arubanetworks.com/open_source

Legal Notice
The use of Aruba Networks, Inc. switching platforms and software, by all individuals or corporations, to terminate other vendors' VPN
client devices constitutes complete acceptance of liability by that individual or corporation for this action and indemnifies, in full, Aruba
Networks, Inc. from any and all legal actions that might be taken against it with respect to infringement of copyright on behalf of those
vendors.

www.arubanetworks.com
1344 Crossman Avenue
Sunnyvale, California 94089
Phone: 408.227.4500
Fax 408.227.4550

Aruba Networks, Inc.

2



Contents
Chapter 1:

Introduction

9

About the Aruba Virtual Branch Network

9

Aruba Validated Reference Designs

9

Design Validation and Testing
Reference Documents

16
16
20
24
25

The Network Technology Lifecycle

27


27

Defining Requirements for Remote Networks

31

Step 1 – Quantify Facility Requirements

31

Step 2 – Quantify Device Connectivity Requirements

32

Step 3 – Define RAP Equipment Requirements

36

Physical Design

39

Aruba Physical Architecture for Remote Networks
Remote Site Physical Architectures
Data Center Physical Architecture

39
41
45

Required Equipment
Access Points
Local Controllers
Master Controllers
AirWave Appliance

46
47
48
50
52

Required Licenses
Local Controllers
Master Controllers
AirWave Appliance


13
13
14
14

Remote Networks Key Benefits

Chapter 5:

13

Design Considerations for Remote Networks

Chapter 4:

Virtual Branch Theory of Operations

Understanding the Aruba Virtual Branch Network Architecture
Components of the Architecture
Operation of the Architecture

Chapter 3:

11

Virtual Branch Network Overview
The Fixed Telecommuter—A One-Person Branch
Medium and Small Branch Offices
The Aruba Virtual Branch Network Solution

Chapter 2:

11

52
52
52
53

Contents | 3



3G Modem Selection
Wide-Area Network Considerations
Bandwidth Constraints
Latency Constraints
3G Wireless Constraints
Recommendations for Minimizing Constraints

Logical Design

59
59
60
62
63

Forwarding Modes
Split-Tunnel Mode
Tunnel Mode
Bridge Mode
Operating Modes
Combined Forwarding and Operating Modes

64
64
66
68
69
70

AP/AM Data and Control Tunnels
AP Tunnels
AM Tunnels
IP Ports Used by Aruba Devices
Establish a Routable IP Subnet to the Master Controller

71
71
72
72
72

RAP Bootstrapping and Load Balancing

73

Controller High Availability
Master Controller Redundancy
Local Controller Redundancy (VRRP Layer 2 Method)
Local Controller Redundancy (LMS-IP Layer 3 Method)

75
76
78
80

VLAN Design
Choosing the Default Router

82
83

Authentication and Security Design

85

Authentication Methods (Wired and Wireless)
Authenticating with 802.1X
Authenticating with Captive Portal
MAC Address Authentication

85
86
88
88

Authentication Methods (Wireless Only)

89

SSIDs for Secure WLANs

56
56
57

Aruba Logical Architecture for Remote Networks
Fixed Telecommuter Logical Design
Branch Office Logical Design
Data Center Logical Design

Chapter 7:

54
54
55
55
55

Regulatory Compliance for International Deployments
Access Point Compliance
Controller Compliance

Chapter 6:

53

89
Contents | 4



SSIDs

89

Role Derivation

90

Configuring Roles for Different Users
Secure Role for Mobile Wireless Data Terminals
Secure Role for Stationary Wired Devices
Voice Handset Role
Guest Access Role

92
92
92
92
93

Putting It All Together: Building an Authentication Design
What Is A Profile?
Aggregating Profiles into a Complete Configuration
Planning AAA and SSID Profiles
Example 802.1X Profile Configuration
Best Practices for Profiles

94
94
96
97
98
99

Wireless Intrusion Detection System Operation and Design
Detection of Rogue APs
Classification of Rogue APs

103
103
103
104
105
106
107
107

Recommended Provisioning Methods
Zero Touch Provisioning
Pre-Provisioning

108
109
109

Site Procedure for Zero Touch Method
Pre-Installation Checklist
Site Installation
Provisioning the RAPs

109
110
110
110

Site Procedure for Pre-Provisioning Method
Pre-Installation Checklist
Provisioning the RAPs
Site Selection
Site Installation

111
111
111
111
111

Site Validation Considerations
Cabling and RAP Validation
Client Device Validation


Deploying Aruba Remote Networks
Aruba Deployment Process for Remote Networks
Step 1 – Deploy Data Center
Step 2 – Install Pilot Sites
Step 3 – Provision Backhaul Circuits
Step 4 – Train the Help Desk
Step 5 – Stage Site Equipment
Step 6 – Execute Full Deployment

Chapter 8:

100
100
101

112
112
112

Contents | 5


Chapter 9:


Example Configuration for the Branch Office Scenario

159
159

Configuring the Aruba Branch Office Solution
Configure the Master Controller
Configure the Local Controller
Provision and Deploy RAPs

162
162
175
176

Reporting and Management

177

Remote Management
Managing Both Legacy and New Network Elements
Role-Based Management
Planning and Location Services for Wireless Clients
Scalability
Trend Reporting
Diverse WAN Environments

177
180
180
182
184
185
186

Troubleshooting Remote Access Points

187

Troubleshooting Categories

187

Troubleshooting Zero Touch Provisioning Problems

188

Troubleshooting Basic Connectivity Problems
Working from the RAP
Working from the Controller
Troubleshooting the IPsec Tunnel
Checking the IP Address Pool and Usage

189
189
191
192
206

Troubleshooting RAP Bootstrapping Problems
Checking the VPN Role Policies
Checking the RAP Role Transition
Common Problem Symptoms

207
207
208
210

Troubleshooting Wired Port Configuration Problems
Checking for an Enabled Wired Port
Checking the Port Profile
Checking the Authentication Profile

212
213
214
215

Troubleshooting Split-Tunnel Mode Problems
Is the RAP Configured in Split-Tunnel Mode?

116
116
141
154

Simplified Design for the Branch Office

Chapter 12:

113

Configuring the Aruba Fixed Telecommuter Solution
Configure the Master Controller
Configure Local Controllers
Deploy RAP(s)

Chapter 11:

113

Simplified Design for the Fixed Telecommuter

Chapter 10:

Example Configuration for the Fixed Telecommuter Scenario

216
217
Contents | 6



Is the Split-Tunnel SSID Active on the AP?
Does the Split-Tunnel SSID Have a GRE Tunnel with 802.1X?
Has the Client Succeeded with 802.1X Authentication?
Has the Client Received a DHCP IP Address from the Local LAN?
Does Split-Tunneling Work at the Client End?
Troubleshooting Bridge Mode Problems
Checking the Configured Mode
Bridge Mode with Dynamic Encryption
Troubleshooting Tips
Bridge Mode with Static Encryption (Pre-Shared Key)

218
218
219
221
224
225
227
227
229
232

Appendix A: Forwarding Mode Feature Matrix

235

Appendix B: Provisioning Parameters for Verified USB Modems

237

Appendix C: Requirements Worksheets

239

Appendix D: Sample Configuration Files for Fixed Telecommuter Example

243

Design Summary

243

Annotation Conventions
Active-Master Configuration
Active-Local Configuration

244
245
245

Appendix E: Aruba Contact Information

257

Contacting Aruba Networks


257

| 7




| 8



Chapter 1: Introduction
Aruba Networks delivers secure enterprise networks wherever users work or roam. Our mobility
solutions bring the network to you—reliably, securely, and cost-effectively—whether you work in a
sales area, at home, in a branch office, or in an enterprise office. Aruba Remote Networks products
facilitate data center consolidation and virtualization initiatives, providing lower operating costs.
Remote Network technology brings the network to fixed or temporary remote work locations with plugand-play simplicity—all the heavy lifting stays at the data center. Our AirWave multi-vendor
management tool allows seamless management of old and new networks from a single console.

About the Aruba Virtual Branch Network
With the wide variety of remote locations and devices other than PCs used by today’s users IT
departments find it increasingly difficult and expensive to deliver full-featured and secure network
access and services to all the locations where users work. Aruba addresses the complexity, security,
compliance, and management challenges of these deployments, enabling IT to cost-effectively
support today's highly distributed workforce.
The Aruba Virtual Branch Network solution virtualizes the complex security, configuration, software
management, and troubleshooting operations within the data center and then transparently extends
those services to each branch office and teleworker. This provides the control and seamless user
experience associated with dedicated network infrastructure hardware, but with the security and price
point of client VPN. Remote deployments become simple for IT to set up, secure, and manage.

Aruba Validated Reference Designs
An Aruba Validated Reference Design is a package of product selections, network decisions,
configuration procedures, and deployment best practices that comprise a reference model for typical
customer deployment scenarios. Each Aruba VRD has been constructed in a lab environment and
thoroughly tested by Aruba engineers. By using these proven designs, customers can deploy Aruba
solutions rapidly, with the assurance that they will perform and scale as expected.


Introduction | 9



Aruba publishes two types of validated reference designs, Base Designs and Incremental Designs.
Figure 1 illustrates the relationship between these two types of documents in the Aruba Validated
Reference Design library.

Optimizing
Aruba WLANs
for Roaming
Devices

Retail
Wireless
Networks

High Density
Wireless
Networks

Incremental
Designs

Virtual
Branch
Networks

Base
Designs
RNSG_190

Campus
Wireless
Networks

Wired
Multiplexer
(MUX)

Figure 1

Aruba Validated Reference Design Library

A Base Design is a complete, end-to-end reference design for common customer scenarios. Aruba
publishes the following Base Design validated reference architectures:
 Campus Wireless Networks VRD: This design guide describes the best practices for
implementing a large campus wireless LAN (WLAN) serving thousands of users spread across
many different buildings joined by SONET, MPLS, or any other high-speed, high-availability
backbone.
 Retail Wireless Networks VRD: This design guide describes the best practices for
implementing retail networks for merchants who want to deploy centrally managed and secure
WLANs with wireless intrusion detection capability across distribution centers, warehouses, and
hundreds or thousands of stores.
 Virtual Branch Networks VRD (this guide): This design guide describes the best practices for
implementing small remote networks serving fewer than 100 wired and wireless devices that are
centrally managed and secured in a manner that replicates the simplicity and ease of use of a
software VPN solution.
An Incremental Design provides an optimization or enhancement that can be applied to any Base
Design. Aruba publishes the following Incremental Design validated reference architectures:
 Optimizing Aruba WLANs for Roaming Devices VRD: This design guide describes best
practices for implementing an Aruba 802.11 wireless network that supports thousands of highly
mobile devices (HMDs) such as Wi-Fi phones, handheld scanning terminals, voice badges, and
computers mounted to vehicles.
 Wired Multiplexer (MUX) VRD: This design guide describes the best practices for implementing
a wired network access control system that enables specific wired Ethernet ports on a customer
network to benefit from Aruba role-based security features.
 High Density Wireless Networks VRD: This design guide describes the best practices for
implementing coverage zones with high numbers of wireless clients and access points (APs) in
a relatively small geographic area such as classrooms, lecture halls and auditoriums, and in
ultra-dense spaces such as financial trading floors.


Introduction | 10



Design Validation and Testing
The VRD presented in this document provides best-practices architectures for two broad categories of
remote network deployments:
 Small or medium branch office
 “Fixed telecommuter” deployment for customers with hundreds or thousands of remote workers
Test cases for this Virtual Branch Networks VRD were executed against the physical architecture
recommended in this Guide using a mix of client devices and interconnect methods. ArubaOS release
3.3.2.11-rn3.0 was used to conduct these tests.

Reference Documents
The following reference documents provide an in-depth review of the key products described in this
guide.
Document Title

Version

ArubaOS User Guide

3.3.2

ArubaOS CLI Guide

3.3.2

ArubaOS Release Note

3.3.2.x-rn3.0

ArubaOS Quick Start Guide

3.3.2

AMP QuickStart Guide

6.2

AMP User Guide

6.2

AMP Release Notes

6.2

RAP-5 Installation Guide

n/a

RAP-5WN Installation Guide

n/a

RAP-2WG Installation Guide

n/a


Introduction | 11




Introduction | 12



Chapter 2: Virtual Branch Theory of Operations
Virtual Branch Network Overview
Enterprises today support the technology needs of two broad categories of remote network users.
Remote users are those who work at a location other than an organization’s primary headquarters or a
large regional office. One remote network category is the small branch office or retail store, typically
with up to 100 employees. The other category is the “fixed telecommuter,” an individual who works
from his or her home 8 hours or more a day during the workweek. A fixed telecommuter may be
thought of as a “branch of one.”
Traditionally, IT organizations have used very different remote network architectures to serve each of
these categories. The small branch typically utilized a branch office router to interconnect an IP subnet
at the remote site to the enterprise network core. Telecommuters, who had only a single PC or laptop
and limited needs, have been served with a software Virtual Private Network (VPN) client.
These solutions are no longer satisfactory. The complexity of remotely configured and managed
branch office router solutions is too high. To reduce operating costs, IT needs the simplicity and
centralized management offered by the VPN solution. Meanwhile, the telecommuter increasingly
needs a full IT network footprint including an IP phone and wireless service with appropriate security
policies. The VPN client does not meet this requirement. The requirements of each of these remote
user populations are converging. A completely new remote networking architecture from Aruba
Networks offers a single solution that blends the simplicity of a centralized network-based VPN with
the flexibility of sophisticated role-based access control for all users at a remote site.
The Fixed Telecommuter—A One-Person Branch
Most telecommuters access the data center through a software VPN client connection via Internet
Protocol Security (IPsec)/Secure Sockets Layer (SSL) protocols from remote locations. These
locations can include customer offices, employee homes, and wireless LAN hotspots or anywhere that
3G wireless service is available. In these cases the VPN connection effectively “virtualizes” data center
services to wherever the user is located. From the user’s perspective, the data and applications
appear exactly as they would on their enterprise network. Because they are centrally managed, VPN
solutions are well known for their low operating costs.
This access methodology met the requirements of enterprise users when most applications were
accessed from a single PC-based device—a desktop or a laptop. The recent explosion of device types
and operating systems such as VoIP phones, video conferencing terminals, and smartphones with
enterprise applications renders the VPN solution incompatible. In addition to the growth of the number
of devices for a single user, there is also a growing need for distributed, temporary, and mobile
business offices. In all of these remote settings, it is more important than ever to equip distributed
workers with the same productivity tools as their LAN or WLAN-connected counterparts.


Virtual Branch Theory of Operations | 13



Medium and Small Branch Offices
Historically, most branch offices have received less-sophisticated and lower-performance network
technology and IT services than enterprise core network workers. Paradoxically, the configuration and
management costs are much higher as a whole for remote sites. Three reasons for this cost elevation
are:
1. The networks servicing these remote environments are tethered to a WAN, which—until
recently—has been inherently slower and more latency-prone than local area networks.
2. This slow WAN performance drove a network architecture employing discrete IP subnetworks at
each branch office. This architecture in turn created a requirement for a scaled-down site router,
firewall, and other network elements, which router manufacturers are only too happy to
reinforce.
3. Remote work environments have evolved incrementally during periodic field technology
refreshes. As a result, they contain inconsistent equipment and service sets across many
locations.
These factors add a layer of complexity for new services deployment, particularly in organizations
without IT staff to service remote workers. Evolving business conditions make it necessary to elevate
remote workers’ network experience to be equivalent to that of employees connected directly to the
enterprise core LAN.
Existing network infrastructure vendors have often taken the approach of attempting to retrofit the
existing network infrastructure equipment and downscale it for these small branch offices and home
offices. This practice leads to an architecture in which a new network is created for every new location
and connected back to the enterprise core network. These new networks then replicate all network
services that have already been created in the core network for every remote location. This replication
tends to include routing, switching, firewalls, and other security services. These remote networks are
then inter-connected using various WAN technologies—including frame relay, MPLS, and dedicated
circuits. Network administrators are faced with the increased costs and complexities of deploying,
operating, and maintaining these networks and their complicated interconnections.
The Aruba Virtual Branch Network Solution
The Aruba virtual branch network (VBN) architecture paradigm focuses on maintaining the simplicity
and ease of a software VPN solution while delivering full IP network services to multi-device/user
offices. This paradigm leverages two technologies for which Aruba is well known:
 Secure Data Tunnels: In this architecture, a remote access point (RAP) provides similar
functionality to a VPN client but allows for shared access to multiple devices through wired and
wireless LAN interfaces. The controller acts in an analogous manner to a VPN concentrator.
Each RAP communicates with the controller over one or more secure, encrypted IPsec VPN
tunnels. This communication provides access to the devices/users connecting through the RAPs
to the enterprise core network and to the applications and services that exist there.
 Role-Based Access Control (RBAC): The Aruba controller has an integrated, ICSA-certified
stateful firewall capable of up to 20 Gbps (cleartext) or 8 Gbps (encrypted) performance. Each
RAP also includes the same firewall functionality. With the firewall, each user is assigned a “role”
with associated policies. Policies follow the wired or wireless user and are centrally managed for
simplicity. Deep packet inspection makes sure that roles are strictly enforced on a per-packet,
per-flow basis. Devices violating a policy are automatically blacklisted.





The Aruba secure data tunnel and RBAC technologies work together to deliver the VBN experience,
as shown in a logical diagram in Figure 2:

Branch Office /
Telecommuter Home
Internet
Services

Enterprise LAN

Guest / Family

Voice
Enterprise
Network

Split
Tunnel

VL

AN

C

Guest /
Family
Bridge VLAN

Enterprise

Controller

Remote Access
Point

Internet or WAN

Firewall/
NAT-T

RNSG_066

VL

AN

A

VLAN B

Voice

Figure 2

Virtual Branch Network and Role-Based Access Control

This architecture shatters the cost and complexity barriers that exist today in establishing new remote
offices for multiple devices and users, providing businesses with the following advantages:
 Greater flexibility and agility in business operations
 Lower total cost of ownership to establish new branch offices
 Justification for a “branch of one,” making “work from home” initiatives viable
 Ability to embrace “going green” by supporting initiatives that allow employees to work from
home





Understanding the Aruba Virtual Branch Network Architecture
Components of the Architecture
The Aruba Virtual Branch Network architecture consists of the following logical components:
 Remote Access Point (RAP): Aruba RAPs serve as on-ramps to aggregate user traffic onto the
enterprise LAN and direct this traffic to Aruba controllers. When provisioned as a RAP, APs
extend the enterprise LAN to any remote location by enabling seamless wired or wireless data
and voice wherever a user finds an Internet enabled Ethernet port or 3G cellular connection.
RAPs are ideally suited for small to medium remote offices, home offices, telecommuters,
mobile executives, and for business continuity applications. The major modules of the RAP are
shown in Figure 3.
Internet

rnet

Inte

Enterprise
Enterprise
Wi-Fi
& WIPS

LAN

Dynamic
Role
Assignment

PEF

Internet
Enterprise

Ethernet

Secured
Wired
“NAC”

(Per-User Stateful
Policy Forwarding)

VPN
Client

Enterprise
To Controller
USB Modem

LAN

RNSG_064

LAN

Figure 3

RAP Modules



VPN client: Included with the RAP software license, this feature provides VPN client capability
to securely communicate with the VPN server located in the local controller on the enterprise
DMZ.



PEF (Policy Enforcement Firewall): Provides a stateful policy enforcement firewall for
restricting access to enterprise core network resources. A role-based access rights policy is
configured on the controller and then applied upon completion of RAP authentication and
establishment of an IPsec connection. This policy contains control traffic protocol, traffic type
within GRE tunnels, the types of traffic permitted from the RAP to the controller (L2TP, TFTP,
FTP, for example), and NTP and syslog protocol and ports.
Wireless LAN interface(s): Provide Wi-Fi enterprise features supporting single and dual radio
802.11 b/g, 802.11 b/g/n, 802.11 a/b/g, and 802.11 a/b/g/n, depending on model selection.
Wired LAN interface(s): Provide Network Access Control (NAC) capable 10/100 Mbps or 100/
1000 Mbps RJ-45 Ethernet ports, depending on model selection.









WAN Interface(s): Provide wide-area connectivity including EVDO/HSDPA 3G USB modems
or Ethernet, depending on model selection.
Controller: Aruba Networks high-performance controllers are built specifically to scale ArubaOS
software module capabilities for enterprise networks of all sizes. All Aruba controllers share a
common hardware architecture that includes a dedicated control processor, a high-performance
programmable network processor unit, and a unique programmable encryption engine.
Controllers aggregate network traffic from APs, process it using Aruba software, and deliver it to
the network.
The controller resides in the data center or the DMZ, depending on the network design. RAPs
connect to the controller using secure tunnels. The data is transmitted from the remote locations
to the enterprise LAN through these secure tunnels. After the controller receives the data, it
processes it and routes the data into the core network. In other words, the controller is the
“gateway to the enterprise LAN” for the remote users and devices connecting to the RAP. The
major modules within the controller are shown in Figure 4.




Management

RADIUS / Active Directory / LDAP

Mobility Controller
Encryption

To RAPs

Authentication

VPN
Server

Policy Definition
and
System Management
To Enterprise
Network

Central
Wireless
& WIPS

PEF
(Policy
Enforcement
Firewall)

Central
Wireless &
Wired NAC

Redundancy

QoS

Rich Networking

Figure 4


Integrate with Network
RNSG_065

VRRP for Controller
High Availability

Controller Modules

VPN server: Included with the RAP software license, this feature provides VPN server
functionality to communicate with RAP VPN clients. The Aruba controller must have VPN
server functionality configured to terminate the secure RAPs. The configuration consists of
authentication protocols, an address pool for RAPs, DNS information, shared secret for
RAPs, and a policy governing the shared secret including priority, encryption, hash algorithm,
authentication, group and life time.









PEF (Policy Enforcement Firewall): Aruba is currently the only vendor to integrate an ICSAcertified stateful firewall into its wireless LAN, ensuring that parameters such as security,
suitability for a task, default configuration, and logging/audit trails have been validated.
Authentication/Encryption modules: Work with the PEF module to authenticate users and
enforce roles. Provide an internal authentication (AAA) server that is enabled by default on
each controller; external authentication can be configured for enterprise authentication
servers (RADIUS, Active Directory—AD or Lightweight Directory Access Protocol—LDAP).
The encryption module supports WEP, dynamic WEP, TKIP, WPA, WPA-2, DES, 3DES,
AES-CCMP, AES-CBC, EAP, PEAP, TLS, TTLS, LEAP, EAP-FAST, and xSec-L2 AES.
ArubaOS uniquely supports AAA FastConnect™, which allows the encrypted portions of
802.1X authentication exchanges to be terminated on the controller where the Aruba
hardware encryption engine dramatically increases scalability and performance. Supported
for PEAP-MSCHAPv2, PEAP-GTC, and EAP-TLS, AAA FastConnect™ removes the
requirement for external authentication servers to be 802.1X-capable and minimizes
authentication latency, which is advantageous when leveraging centralized AAA
infrastructure for remote network deployments.

Centralized Wired NAC services: Provides centralized secure-jack capability for tunneling of
wired Ethernet traffic.
 Redundancy: To scale to large networks where multiple controllers are required, Aruba
supports the concept of a master controller-local controller cluster hierarchy among
controllers. This hierarchy allows the administrators to use the master controller as the central
point of all policy configurations while the local controllers are used to scale the “data plane”
by terminating active connections from RAPs and users.
AirWave Management Platform (AMP): The AMP is a management server that provides highly
scalable and centralized total solution management. This multi-vendor management tool can
monitor some versions of branch office routers, wired switches, and other devices. An AMP
implementation provides IT administrators full visibility into the remote networks—including
users, activity, and helpdesk operations.




Role-Based Security

Aruba customers use a role-based security model that facilitates extending a trusted IP footprint into a
home or branch office.
The Aruba controller authenticates a user or device, rather than the port or VLAN. For wired users,
multiple profiles and roles can be configured for a single port so that user/device security granularity is
provided.
For wireless devices, role-based security generally begins by offering several Service Set Identifiers
(SSIDs) simultaneously from the same AP. Each SSID has its own authentication and encryption
settings based on the capabilities of the clients and the services that each client needs.





A typical fixed telecommuter home has three wireless SSIDs available for association via the RAP
(Figure 5):
 Enterprise, for the employee’s PC and data devices
 Family, for non-employee users and devices to route directly to the Internet using specific
protocols (for example, HTTP, HTTPS), and to access local family resources such as servers
and printers
 Voice, for enterprise voice devices, which receive a restricted role

Enterprise
SSID

RNSG_145

Family/Guest
SSID
Voice/Video
SSID

Figure 5

Fixed Telecommuter SSIDs

A typical branch office will also have four SSIDs. The Family SSID is replaced with a Guest SSID,
which can utilize a Captive Portal feature to direct guests to a log-in page that is user name and/or
password protected. A pre-shared key SSID is added for legacy devices that are not capable of
modern encryption methods.

High Security
SSID

Figure 6


Voice/Video
SSID

RNSG_144

Pre-Shared Key
SSID

Guest
SSID

Branch Office SSIDs




For detailed examples of both the fixed telecommuter scenario and the branch office scenario, refer to
Chapter 6: Logical Design on page 59.
All users connect to the RAP and authenticate with the RADIUS server that already exists in the
network. The stateful firewalls in the controller and RAPs enforce the role and policy associated with
each user and device. Users are only able to access those resources they have permissions for, and
only after they have successfully authenticated to the network.
Operation of the Architecture
To understand the mechanisms employed in branch network virtualization, the following steps explain
how a RAP connects to a controller and then how users and devices connect to the enterprise LAN
through the RAP.
Connection Establishment

In this architecture, the RAP, using any of four standard discovery mechanisms (Aruba Discovery
Protocol-ADP, Domain Name Service-DNS, Dynamic Host Configuration Protocol-DHCP, or statically
configured IP or host name), initiates an IPsec connection to the controller over any public or private IP
network. This connection is analogous to the VPN connection initiated by a VPN client on a laptop or
desktop to a VPN concentrator. However, in the case of a RAP, there is no single user to be
authenticated. Instead, the RAP itself is authenticated on the controller—either by using a preprovisioned user name and password on the RAP or by using certificates that are installed on the
RAP.
Bootstrap Protocol Between Controller and RAP

A key difference between the Aruba virtual branch network (VBN) solution and branch router networks
is that all configuration is centralized and uploaded to the RAP in real time. No remote configuration is
required. After RAP authentication is completed by the controller and the IPsec tunnel has been
established, all communication between the controller and the RAP occurs through this secure
channel. This encrypted tunnel is now used to upgrade the image on the RAP (if there is an image
mismatch with the controller image version) and then to push the RAP configuration from the controller
to the RAP. This configuration includes all security settings, firewall roles and policies, wired port
policies, and wireless LAN policies. This process is referred to as “bootstrapping” the RAP in this
architecture. For more information about this process, refer to Chapter 6: Logical Design on page 59.
Network Access Control

Once the RAP has successfully bootstrapped to a controller, the RAP applies the configuration it has
received to the wired ports and wireless interfaces. Users and devices can now connect to the wired
ports and wireless SSIDs as provided for in the bootstrapped policies.
Administrators can control the exact access provided to the users and devices through these ports and
SSIDs by using authentication mechanisms such as 802.1X or MAC address authentication. Using
WPA or WPA2 on wireless SSIDs also provides an additional level of security by encrypting all frames
in the wireless medium.





When 802.1X authentication is used to authenticate wired or wireless users, the authentication frames
are sent through the IPsec tunnel to the controller, which then authenticates and authorizes the user/
device credentials by using RADIUS or LDAP protocols to communicate to the existing AAA server
infrastructure. Depending on the result of the authentication the user/device is placed in the
appropriate “user role.” Aruba enforces the principle of least privilege by identifying users or devices,
placing them into separated roles, and permitting or denying access to network resources or protocols
based on those roles. The user role is mapped to a series of firewall policies that define the network
access that the user is provided.
For detailed information about network access control, refer to Chapter 7: Authentication
and Security Design on page 85.
Associate
Associate response

EAP request identity
EAP response
EAP exchange

Key1
Station

Key2

RAP

Key3

802.11 Association

Figure 7

802.1X Authentication

4-way Handshake

RNSG_057

Key4

802.1X Authentication Handshake

IP Routing

The IP address management and routing design for the RAP solution is one of the major differentiators
from a traditional branch office solution. Similar to the manner in which a VPN client is “assigned” an IP
address from an enterprise pool by the VPN concentrator, all enterprise users connecting to a RAP
may be assigned IP addresses from the controller. This mechanism extends the simple IP routing
model of a software VPN solution to the virtual branch network, making the client device connecting to
a RAP a part of the enterprise LAN. Guest or family devices are assigned an IP address from a local
address pool on the RAP.
This design is in contrast to a branch office router model that uses separate IP subnets for every
branch office network and then interconnects these subnets to the enterprise LAN for access to
business applications and data. This traditional model introduces a set of issues that includes:





Complicated VPN routing protocols
Complicated IP address management
Application issues related to going through NAT (for example, VoIP)
Requirement for special protocols for enabling multicast over these connections





The Aruba virtual branch network architecture avoids all these concerns and provides centrally
managed enterprise LAN application functionality, thereby reducing the cost and complexity of
deploying and managing branch and home offices.
Firewall

The firewall service in the RAP provides flexible policy-based forwarding access control list (ACL) for
split-tunnel forwarding mode. Split-tunnel is the recommended and the most flexible mode for
interconnecting RAPs with their local controller. The benefits of split-tunnel mode include:




Enterprise traffic is tunneled to the controller over an encrypted IPsec tunnel.
The IPsec tunnel is trusted and shared by all wireless Virtual APs (VAPs) and wired ports.
All other traffic is locally source routed (NATed) and forwarded on wired uplink and downlink
ports according to user roles and session ACLs.

The RAP firewall implementation also provides a bridge forwarding mode that restricts local traffic
locally but permits split-tunnel users access to selected resources. Access and trunk modes are
supported on RAP wired ports.
For remote voice applications, minimizing latency is critical. A low latency tunnel forwarding mode is
supported where all traffic is tunneled to the enterprise network. For this forwarding mode, wireless
encryption is performed on the wireless client as usual and these encrypted frames are sent directly to
the local controller, where decryption is performed and forwarding policies are applied. This feature is
also of value to customers who have a compliance requirement to see all traffic from their employees.
Refer to Chapter 7: Authentication and Security Design on page 85 for detailed information about
these features,
Redundancy

The Aruba virtual branch network architecture was designed from the ground up for high availability.
Redundancy may be configured at either the controller or the Remote Access Point or both. Controller
redundancy is achieved through standards-based Virtual Router Redundancy Protocol (VRRP) in
which controllers share a virtual IP address so that planned and unplanned outages are transparent to
remote users. RAP redundancy is achieved by configuring both an active and a standby master
controller IP address during the provisioning process. If for any reason the active master becomes
unreachable, the RAP can automatically failover to the standby master.
These configuration options provide network administrators with significant flexibility to design virtual
branch networks that leverage existing data center and WAN investments while fitting within available
budgets. From simple RAP failover between two standalone controllers at a single data center, to fully
redundant controller pairs at geographically diverse data centers, Aruba enables customers to meet
high service level expectations. Redundancy is considered fully in Chapter 6: Logical Design on
page 59.
Scaling to Multiple Controllers

For RAPs operated as a production IT service that must meet uptime and availability Service Level
Agreements (SLAs), there may be a requirement to deploy more than one controller to accept the RAP
connections. Aruba supports “clustering” controllers using the “master/local” concept.
In a master/local design, one of the controllers is configured to be the “master” controller. This
controller is responsible for providing centralized configuration and coordination for the entire network.





The “local” controller is the aggregation point where RAP tunnels terminate, and where security
policies are applied. All global settings (such as authentication profiles, firewall policies, and WLAN
policies) can be configured on the master controller. These settings are then automatically propagated
to all the local controllers. Aruba supports full 1+1 redundancy via VRRP for both the master and the
local controller levels.
The master controller can be viewed as the “control and management plane” of the network. RAPs
initially connect to the master controller and receive their configuration as described above. The local
controllers can be viewed as the “data plane” of the network, where the policies are actually applied
and all user traffic flows through these controllers.
Designing large-scale networks using these concepts is explained further in Chapter 6: Logical Design
on page 59.
Licensing and Software Updates

One of the ways that Aruba reduces the IT labor requirement associated with managing remote
networks is by centralizing licensing and software updates for all branch locations at the controller. As
we have seen, traditional branch network solutions create mini-enterprise networks at each location
with separate routing, firewall, VPN and other equipment. Many of these devices must have software
licenses installed. Also, their operating software must be kept up to date, which can require careful
planning and consume significant IT resources.
The Aruba virtual branch network architecture eliminates these requirements by overlaying the
enterprise network securely across the WAN, managed by controllers located in the data center.
Software license keys are installed only on the controllers, and the controller automatically upgrades
RAPs any time they authenticate to the network if a code change has taken place. Remote Access
Point licenses can be purchased in increments from 1 through 512, and there is no need to purchase
more than are needed. Additional remote sites can be added at any time. Choosing the right software
licenses is addressed in Chapter 5: Physical Design on page 39.
Deployment

The virtual branch network architecture dramatically reduces deployment costs through its Zero Touch
provisioning capability. Provisioning refers to the process of programming the APs to find their
controller and optionally assigning their physical location on an electronic floor plan in order to show
real-time heat maps on a controller.
The Aruba RAP-5, RAP-5WN, and RAP-2WG products are preloaded with a unique security certificate
at the factory. When combined with the 3000-series standalone controller or the M3-series blade that
also include a factory-installed certificate, a low-cost provisioning model becomes possible. This model
is particularly attractive for telecommuter deployments.
Aruba calls this feature zero touch provisioning, meaning that the IT organization simply pre-programs
the MAC address of each authorized RAP into a white list on the master controller before shipping it to
the end user. The IT professional can do this without having to plug the AP into the controller, and the
AP remains in its packaging untouched. Once received at the site, the end user simply enters the IP
address/hostname of the local controller into the provisioning screen on the RAP. The RAP exchanges
keys automatically with the controller and completes the provisioning process with no further manual
intervention.
For customers who prefer to stage equipment in advance, Aruba supports a pre-provisioning model.
Pre-provisioning refers to the process of staging the APs before they arrive at a site. This staging is




most often done when an IT team or system integrator will be traveling to each location to install or
refresh multiple pieces of equipment, and it is not possible or not desirable for site employees to
perform IT tasks themselves. With pre-provisioning, a staging center is required to prepare equipment
to be delivered to the remote locations. The Aruba RAPs are unpacked, configured, and verified at the
staging center prior to final delivery. The staging center should have secure LAN connectivity to the
data center where the controllers are housed so that RAPs can connect to the controller.
The choice of deployment methodology is generally determined by two factors: the cost to send
installers onsite, and whether the end user can or should be expected to perform a few simple tasks to
activate an Aruba RAP. For detailed information on deploying an Aruba virtual branch network, see
Chapter 8: Deploying Aruba Remote Networks on page 103.

Design Considerations for Remote Networks
The following are general considerations when designing an Aruba virtual branch network for
scenarios discussed in this chapter. Typically in a branch office environment, the majority of devices
will be enterprise owned. These may include:







Employee wireless laptops
Wired and wireless VoIP phones
Employee wired desktops and servers
Handheld scanning terminals
Shared wired and wireless printers
Local application server and network attached storage (NAS)

In the telecommuter home environment, in addition to the employee laptop and desktop and wired and
wireless VoIP phone, there may be:
 Wired family desktops
 Wireless family laptops
 Family multimedia devices (XBox, Media Center, TiVo, for example)
 Shared wired and wireless printers
 Shared wired and wireless network attached storage (NAS)
Planning appropriate connectivity and security for these devices is easily accomplished with inventory
design worksheets and example configurations, the details of which are covered in subsequent
chapters.
VLANs and IP Addressing

For both the fixed telecommuter and branch office solutions presented in this VRD, the following IP,
VLAN, and routing configurations are implemented:
 A single VLAN can be configured for wired and wireless access.
 Separate VLANs are configured for enterprise access and for family and guest access.
 A separate VLAN is configured for enterprise voice access.
 For enterprise users and devices, IP addresses are obtained from the enterprise DHCP server
regardless of the device type (wired or wireless) or the tunnel forwarding mode configuration.









For family and guest users and devices, IP addresses are obtained from the DHCP service
provided locally by the RAP.
For the fixed telecommuter solution, enterprise users are permitted unidirectional access to local
family devices such as printers via policy settings pushed down to the RAP.

Remote Networks Key Benefits
In summary, the Aruba virtual branch network architecture centralizes access control, authentication,
encryption, and management, thereby simplifying network management and enhancing security while
providing remote workers and their multiple network devices with access to centralized services. Key
features of this architecture include:
 Operational simplicity. The RAP provides a similar functionality to a software VPN client but
allows for shared access to multiple devices through standard wired and wireless Ethernet
interfaces. The centralized controller acts in an analogous manner to a VPN concentrator for
multiple RAPs and provides access to the devices/users connecting through the RAPs to the
enterprise network and to the applications and services that exist there.
 Flexibility and agility. The unique combination of security mechanisms and Aruba Role-Based
Access Control (RBAC) gives an Aruba Remote Network far greater granularity of control over
wired and wireless user traffic than traditional port-based approaches.
 Scalability. The Aruba remote network architecture accommodates the needs of a single
teleworker all the way up to a medium size branch office. This solution offers flexible
configurations and price points that meet the needs of remote networks regardless of size, while
delivering high-performance throughput and transparent enterprise application access.
 Low total cost of ownership. The Aruba Remote Network architecture requires just one device
at the remote location to service many remote devices/users, allowing the organization to
reduce the IT footprint and associated management cost for each remote location.





Chapter 3: The Network Technology Lifecycle
Successive generations of wired and wireless voice and data communications systems have been
deployed by a wide variety of organizations over many years. Early generations of Ethernet LANs
used coaxial cable, which subsequently gave way to layer 1 (L1) hubs for aggregating wired ports over
standard inside wiring. The development of Ethernet switches greatly reduced forwarding latency and
the processing load on the network device. Switching also provided the capability for collision domain
segmentation into Virtual LANs (VLANs). VLANs have since become the cure-all for moves, adds, and
changes as well as providing segmentation in an otherwise flat network.
In a similar way, early generations of WLANs used autonomous or “fat” access points (APs) with
Frequency-Hopping Spread Spectrum (FHSS) or Direct Sequence Spread Spectrum (DSSS) radios.
Until very recently, deployments were based on 802.11a/b/g technology. The current widespread
rollout of the latest 802.11n technology is being driven by its capacity to deliver wire-speed
performance and increased reliability.
With a new generation of remote access points (RAPs) supporting combined wired and wireless
connectivity for small branch offices and employee homes, Aruba is poised once again to deploy a
new wave of technology that promises to reduce costs and improve efficiencies for remote networking
environments.

The lifecycle of an enterprise network typically moves through four distinct phases over a period of 4 to
5 years. The organization of this guide’s contents follows this lifecycle, beginning with the Define
phase and moving sequentially through the Design, Deploy, and Operate phases.

Define

Operate
Design

RNSG_110

Deploy

Figure 8


Network Technology Lifecycle

The Network Technology Lifecycle | 27



Each new evolution of the lifecycle begins by defining the objectives, requirements,
and constraints facing the organization. The Define phase may also include predeployment wired/wireless site surveys.
The requirements definition process addresses the broad project-level,
infrastructure-level, and application-level drivers and dependencies for the network. Common
examples (explored in depth in Chapter 4: Defining Requirements for Remote Networks on page 31)
include:
 Remote site types, locations, and regulatory domains
 WAN backhaul speeds, latencies, and redundancy options
 User populations, authentication modes and device types
 Quantification of key design or scale parameters
 Financial, technical, and scheduling design constraints
Centralized controller-based remote network architectures offer significant security,
self-healing, performance, and flexibility advantages. They also offer vital
automation features that greatly reduce the workload for shorthanded IT
organizations. These capabilities require new types of design and architectural
decisions that are different from legacy branch router or software VPN solutions.
Aruba recommends segmenting the Design phase for a remote network into the following parts, each
of which is described in a separate chapter in this guide:
 Physical Network Design. In a RAP architecture, controllers and APs work together as a
system that is overlaid on the existing wired LAN and WAN infrastructure. The network architect
must choose where to physically locate controllers and APs within that infrastructure, identify the
equipment and software licenses required, perform capacity planning for controllers and WAN
links, and make sure that optional AP radios comply with local laws. For more information, see
Chapter 5: Physical Design on page 39.
 Logical Network Design. The network architect must determine how the network endpoints will
communicate logically at layer 2 (L2) and layer 3 (L3), choose how to configure controller and
AP redundancy, and complete a VLAN design. For more information, see Chapter 6: Logical
Design on page 59.
 Authentication and Security Design. The network architect must determine how to integrate
the centralized controller with the existing Authentication, Authorization, and Accounting (AAA)
infrastructure. He or she must also decide how to detect, classify, and potentially contain
unauthorized or ‘rogue’ devices in both the wired and wireless spaces. For more information,
see Chapter 7: Authentication and Security Design on page 85.
Large organizations face deployment challenges when migrating network
technology and refreshing network software. Hundreds or thousands of locations
must be accommodated, typically in narrow pre-scheduled time windows,
sometimes by remote technicians with limited IT skills, and usually at the lowest
possible cost. Project management and logistics excellence are required.
Aruba offers system administrators a choice of provisioning methods specifically designed to enable
customers to successfully undertake rollouts with thousands of remote locations. The choice of
method is driven by the number of locations, geography, and WAN link characteristics of each site. For





detailed information about deployment methods, refer to Chapter 8: Deploying Aruba
Remote Networks on page 103.
To reduce the workload of network administrators who must manage far-flung
equipment and respond promptly to alerts and notifications, the Aruba controllerbased architecture is able to independently manage all authenticated wired and
wireless devices, user sessions, and roaming states. When the Aruba WIP module
is deployed, the controllers will automatically blacklist rogue devices. If the RAPs
include optional radios, Aruba provides for automated dynamic RF management of settings for
wireless devices and users.
Rapid resolution of remote user and device issues is a basic function of any IT support desk. Support
personnel must obtain actionable information about the health of specific client device connections in
order to resolve problems. Long-term trending is necessary for accurate capacity planning. The Aruba
Remote Networks architecture provides the tools required for supporting short-term troubleshooting
and long-term trend analysis.
Finally, automated operational and compliance reporting is a key requirement for many organizations
because their IT groups must support large numbers of users and devices with very limited personnel.
Remote networking potentially increases site counts by an order of magnitude. The AirWave Wireless
Management Suite offers powerful centralized reporting, management, and forensic tools that enable
customers to support tens of thousands of RAP locations. See Chapter 11: Reporting and
Management on page 177 for a discussion of AirWave capabilities. See Chapter 12: Troubleshooting
Remote Access Points on page 187 for detailed information about troubleshooting a remote network
deployment.





Chapter 4: Defining Requirements for Remote Networks
This chapter presents a three-step process that can be used by organizations to
define the business and technical requirements that drive the design and rollout
of an Aruba remote network solution. The information gathered in the Define
phase will be used in subsequent chapters to successfully design and deploy the
remote network solution.

Step 1 – Quantify Facility Requirements
Begin by determining what kind of remote sites will be served by the deployment. To generate the
equipment bill of materials, you need to know the number, location, and type of facilities that will be
covered.
Remote Network facility types fall roughly into these categories:
 Fixed telecommuters
 Remote call center agents
 Medium branch offices and stores
 Small branch offices and stores
Some organizations may have only one type of remote site, while others may have all of these. In
addition, global organizations may vary their site types and distributions on a country-by-country basis.
For each facility type, answer the following questions:









How many of each type of facility exists?
In how many separate country and regulatory domains does this facility type exist?
Is guest access required?
How many wired devices need to be supported at each facility?
What is the minimum and maximum WAN backhaul link speed for each facility type?
What WAN technologies (for example, frame relay, point-to-point, and VSAT) are in use for each
facility type?
What is the associated WAN link latency for each link type?

In addition, you must plan which of two possible provisioning methods will be used—Zero touch
provisioning or pre-provisioning. With zero touch provisioning, the MAC address of the RAP is entered
on a whitelist on the controller. The RAP is drop-shipped directly to the user, who installs the RAP and
initiates an automatic provisioning process using the web GUI. With pre-provisioning, the RAP is
connected to a controller at a staging site and programmed with required provisioning parameters. It is
then shipped “ready to go” to the installation site. For more information about selecting a provisioning


Defining Requirements for Remote Networks | 31



method, refer to Recommended Provisioning Methods on page 108. Be sure to plan for anticipated
usage four or five years into the future, and not just for today’s requirements. These requirements
apply both to the number of individual sites and to the number of devices at each one. Construct a
worksheet similar to the following sample to capture the answers to these questions.
Table 1

Facility Inventory Worksheet Example
Usage Requirements

Facility Type

WAN Link Requirements

Provisioni
ng

Max
Devices
per Site

Guests

Family

Existing or
New Link

Type

Speed

Latency

Provisioning
Method

100

20

n/a

Yes

Existing

Cable

2 Mbps

< 25 ms

Zero Touch

 Canada

50

20

n/a

Yes

New

DSL

1 Mbps

< 25 ms

Zero Touch

 Mexico

20

20

n/a

No

New

DSL

768 Kbps

< 25 ms

Zero Touch

10

2

n/a

No

New

DSL

2 Mbps

< 25 ms

Zero Touch

 Canada

2

2

n/a

No

New

DSL

1 Mbps

< 25 ms

Zero Touch

 Mexico

2

2

n/a

No

New

DSL

768 Kbps

< 25 ms

Zero Touch

302

10

No

n/a

Existing

Frame

256 Kbps

< 50 ms

Pre-Provision

 Canada

47

5

No

n/a

New

Frame

256 Kbps

< 50 ms

Pre-Provision

 Mexico

22

5

No

n/a

New

3G

512 Kbps

< 100 ms

Pre-Provision

Site
Count
Fixed Telecommuters
 USA

Remote Call Center Agents
 USA

Small Branch Offices
 USA

Medium Branch Offices
 USA

56

35

Yes

n/a

Existing

Frame

768 Kbps

< 25 ms

Pre-Provision

 Canada

21

15

Yes

n/a

Existing

Frame

768 Kbps

< 25 ms

Pre-Provision

 Mexico

11

15

Yes

n/a

Existing

Frame

768 Kbps

< 25 ms

Pre-Provision

This information is used to construct the logical and physical architecture discussed in Chapter 5:
Physical Design on page 39 and in , “Logical Design” on page 59. This information is also used to plan
the logistics of the deployment covered in Chapter 8: Deploying Aruba Remote Networks on page 103.

Step 2 – Quantify Device Connectivity Requirements
Completing an inventory of present and future applications and the devices on which those
applications run is the second step in the planning process. The inventory assists you in properly
forecasting device populations and RAP hardware capabilities, and in developing the network design.





For each facility or site type, complete a worksheet that captures all current and future networked
application use. Use the following example application summaries as a tool to facilitate planning
meetings between IT, department managers, and executive management.
 For each application and device identified, estimate the average number of users in each
location today, as well as several years into the future.
 Note whether each device is wired or wireless, along with the relevant interfaces. All RAPs have
the ability to broadcast multiple virtual Service Set Identifiers (SSIDs) from a single physical AP.
Each SSID may have different encryption and traffic flow (forwarding mode) settings. In addition
to wireless devices, Aruba RAPs support wired devices for which specific profiles and user roles
can be created and applied, providing a uniform, managed, and secure remote network solution
for branch offices and fixed telecommuter implementations.
 Define the different authentication modes by interface and device type required in the remote
location. Choose the strongest authentication supported by the device class. For wireless
devices, SSIDs can be used to further segment devices based on security requirements:
 A high security SSID (WPA2/802.1X) for employees with individual login IDs and devices
such as PDAs. This requires an external AAA server to integrate with the Aruba controller.
 A voice SSID (WPA/WPA2 with PSK) to support voice handsets optimized for QoS and
battery conservation.
 In branch offices, a guest SSID (captive portal authentication with no encryption) for vendors or
customers to access the Internet. This SSID has explicit firewall access control lists (ACLs)
applied to limit access to unauthorized networks and has bandwidth contracts to limit airtime
usage.
 In fixed telecommuter homes, a family SSID (WPA/WPA2 with Pre-shared Key).
The following examples show the user authentication and device type requirements for a generic
medium branch office and a fixed telecommuter site to help you determine your particular
requirements. Aruba recommends completing worksheets separately for each category of branch
office and fixed telecommuter site.





For detailed information about the different forwarding modes and their respective benefits and
limitations, refer to , “Logical Design” on page 59.
Table 2

Site Template Example—Medium Branch Office
Forecast

Description

Max
Devices
(Today)

Connection Method
Wireless

Max
Devices
(5 Years)

Wired

2.4
GHz

5 GHz

Logical & Security Design

Interface

Auth
Mode

Forwarding
Mode

Operating
Mode

DHCP
Source

Enterprise Devices
Local Server

1

1

X

fe/2

MAC

Bridge

Always

RAP

Local Printer

2

2

X

fe/1
(L2 switch)

MAC

Bridge

Always

RAP

Wired POS*

5

1

X

fe/1
(L2 switch)

MAC

Bridge

Always

RAP

Voice
Handset

1

5

Voice SSID

MAC

Tunnel

n/a

Enterprise

Scan
Terminal

3

9

X

Pre-shared
Key SSID

PSK

Bridge

Always

RAP

Manager
Laptop

1

2

X

High
Security
SSID

802.1X

Split-Tunnel

n/a

Enterprise

Wired PCs

2

5

fe/3
(L2 switch)

Captive
Portal

Split-Tunnel

n/a

Enterprise

Wireless
Laptops

2

10

Guest SSID

Captive
Portal

Split-Tunnel

n/a

Enterprise

Total
Devices

17

35

X

Guest Devices
X
X

X

*Over time, wired devices transition to wireless.





The following is an example of an application worksheet for the fixed telecommuter site.
Table 3

Site Template Example— Fixed Telecommuter
Forecast

Description

Max
Devices
(Today)

Connection Method

Logical & Security Design

Wireless

Max
Device
(5 years)

Wired

2.4
GHz

Interface

Auth
Mode

Forwardin
g Mode

Operating
Mode

DHCP
Source

5 GHz

Enterprise Devices
Wired PCs*

1

0

X

fe/1

802.1X

Split-Tunnel

n/a

Enterprise

Wired IP
Phone

1

0

X

fe/2

MAC

Tunnel

n/a

Enterprise

Employee
Laptop

0

1

Enterprise
SSID

802.1X

Split-Tunnel

n/a

Enterprise

Voice
Handset

0

1

Voice SSID

MAC

Tunnel

n/a

Enterprise

Shared
Printers

1

3

X

fe/3
(L2 switch)

Open

Bridge

Always

RAP

Wired
Devices

2

5

X

fe/3
(L2 switch)

Open

Bridge

Always

RAP

Wireless
Devices

2

10

Family
SSID

Open

Bridge

Always

RAP

Total
Devices

7

20

X
X

Family Devices

X

X

*Over time, wired devices transition to wireless.





Step 3 – Define RAP Equipment Requirements
With completed templates for each type of remote facility, the final step is to itemize the hardware and
software requirements for each one. This information is needed in order to select the best RAP model.
In most cases, the same model will be used for all sites in a given category in order to keep
management as simple as possible. Sometimes, it is desirable to deploy different RAP models for
different user classes. For example, if wireless is not supported at a given location, it may be more
economical to deploy APs that do not include radios but support the number of wired ports required.
Construct a table similar to the one in Table 4 on page 37 to capture these items.
In determining the model of AP that is required for each site, consider the following important factors:
 Are any wired devices to be supported at the site?
 The RAPs can support layer 1 (L1) hubs downstream
 The RAPs can support a PC downstream connected to a wired IP phone (802.1Q trunk)


Does the site require support for wireless devices?
 Which bands need to be supported (2.4 GHz or 5 GHz or both)?

Follow the decision tree in Figure 9 to select the optimal AP model for each class of remote site.

Start

Is
Wireless
Required?

Yes

No

Is
Dual-Radio
Required?

Yes

No

Is
802.11n
Required?

Yes

No

Over 5
Users Per
AP?

Yes

No
Select
AP-125

Select
Power Supply
(US or ROW)

Figure 9


Select
RAP-2WG

Select
RAP-5WN

Select
Power Supply
(US, EU or
ROW)

Select
Power Supply
(US or ROW)

RNSG_155

Select
RAP-5

RAP Selection Decision Tree



Table 4


RAP Requirements Worksheet Example

Facility Type

Local
Wired Ports

USB
Required

Wireless
Required

Radio
Regulatory
Domain

AP Model
(with
Power Supply)

WIPS
Required

Medium Branch Offices
USA

3

No

Yes

USA

RAP-5WN-US

Yes

Canada

3

No

Yes

Canada

RAP-5WN

Yes

Mexico

3

No

Yes

Mexico

RAP-5WN

Yes

USA

3

No

No

n/a

RAP-5-US

No

Canada

3

No

No

n/a

RAP-5

No

Mexico

3

Yes

No

n/a

RAP-5

No

USA

3

No

Yes

USA

RAP-5WN-US

No

Canada

3

No

Yes

Canada

RAP-5WN

No

Mexico

3

No

Yes

Mexico

RAP-5WN

No

Small Branch Offices

Fixed Telecommuter

Remote Call Center Agents
USA

1

No

No

n/a

RAP-2WG-US

No

Canada

1

No

No

n/a

RAP-2WG

No

Mexico

1

No

No

n/a

RAP-2WG

No





Chapter 5: Physical Design
Aruba remote wireless networks are designed to support users at large numbers
of sites with high reliability and security levels. To enable IT network architects to
successfully plan deployments, Aruba has developed a Virtual Branch Networks
Validated Reference Design (VRD) that leverages the experience of customer
deployments, peer review by Aruba engineers, and extensive laboratory
performance testing. This VRD leverages and extends the familiar enterprise wired core/distribution/
access model so prevalent in most enterprises today.
A complete Aruba VRD base design typically consists of three major elements:
 Physical network design
 Logical network design
 Authentication and security design
In this chapter, we discuss the first element, physical network design. This element encompasses
selecting the appropriate access points (APs) and controllers, choosing software licenses, WAN link
capacity planning, and regulatory compliance for international networks. Aruba recommends the
general architecture shown in this chapter as a best practice for remote networks. This architecture
presents the optimal combination of cost savings, performance, and reliability.

Aruba Physical Architecture for Remote Networks
As we have seen, organizations increasingly deliver IP network services to remote workplaces that do
not have local IT support. It is common for these sites to have private, untrusted WAN connectivity to a
central data center. Remote sites may have varying redundancy requirements, depending on their
size, geography, and whether a local server exists. Therefore, any remote networking physical
architecture must be flexible enough to accommodate multiple site requirement categories.
The diagram shown in Figure 10 depicts a high level view of the physical architecture recommended
by Aruba and embodied in this VRD. This architecture is intended to serve a variety of branch office
and fixed telecommuter scenarios, such as:
 Medium branch office (10-50 wired or wireless client devices with wired WAN link)
 Small branch office (1-10 wired or wireless client devices with 3G wireless or wired WAN link)
 Fixed telecommuter (1-10 enterprise and family devices with a broadband Internet link)
 Remote call center agent (one data and one voice device via broadband Internet)


Physical Design | 39



Each remote site communicates over an untrusted WAN link that is directly connected to a remote
access point (RAP). There is no need for an intermediate router or firewall device between the RAP
and the wide-area customer-premises equipment (CPE) device. These links all home to the enterprise
DMZ where redundant Aruba controllers are located.
AirWave Management
Platform

Master
active

Master
standby

Application
DHCP/
DNS

PBX
RADIUS

Data Center
DMZ
Local
active

Internet or
WAN
Local
active

Branch Office Sites

Fixed Telecommuter Sites
3G
EVDO/GSM
Carrier

Broadband
Carrier

Cable
Provider

RAP-5

3G
EVDO/GSM
Carrier

RAP-2WG
RAP-5WN

Medium Branch

Figure 10


Small Branch

Remote Call
Center Agent

Fixed Telecommuter

RNSG_120

RAP-5WN

Aruba Remote Network Physical Architecture




The key components of the physical architecture are:
 Master Controllers. Two Aruba controllers located at the data center are configured to use
master redundancy. Each controller has redundant gigabit Ethernet links into the data center
distribution switches, and shares a Virtual Router Redundancy Protocol (VRRP) address.
 Local Controllers. Local controllers are managed by master controllers. They are installed
inside the data center DMZ. An Aruba recommended best practice is for two local controllers to
run in “active-active” redundancy, with two VRRP addresses shared between them. Very large
RAP deployments may require clusters of local controllers. All Aruba controllers share a
common hardware architecture that includes a dedicated control processor, a high-performance
programmable network processor unit, and a unique programmable encryption engine. Local
controllers aggregate network traffic from APs, process it using Aruba software, and deliver it to
the network based on defined security polices.




Remote Access Points. Aruba APs serve as on-ramps to aggregate user traffic onto the
enterprise network and direct this traffic to Aruba local controllers. APs extend the enterprise
network to any remote location by enabling seamless wired or wireless data and voice wherever
a user finds an Internet-enabled Ethernet port or cellular connection. While all Aruba AP models
support the RAP service, this VRD assumes the exclusive use of Aruba dedicated RAP models.
RAPs are selected based on the required number of wired ports, wireless service band (5 GHz/
2.4GHz), and 802.11 mode (a/b/g/n).
RAPs operate in “hybrid mode” to provide intrusion detection services. This means that the AP
performs security and air monitoring functions on a part-time basis between serving client traffic.
Hybrid APs are used in the physical design for this Virtual Branch Networks VRD.
AirWave Management Platform. The AirWave console provides a single user interface that
enables administrators, help desk staff, security analysts, and other IT staff to have full visibility
into and control over the wireless network and users. For more information, see Chapter 11:
Reporting and Management on page 177.

Remote Site Physical Architectures
The physical designs of the fixed telecommuter and branch office deployment scenarios have many
similarities. For maximum clarity, we consider them separately in each of the design chapters in this
VRD.
Fixed telecommuter implementations generally fall into one of two categories:
 Fixed telecommuter home environment
 Fixed telecommuter call center environment





The Fixed Telecommuter Home Environment

The fixed telecommuter home environment includes two facets: the employee accessing enterprise
resources, the Internet, or shared family resources such as printers; and the family accessing personal
resources or the Internet. The following diagram shows an Aruba RAP-5WN AP providing all of these
services.

Data
Center

Internet or
WAN

Enterprise
LAN
3G
WWAN
Enterprise
IP Address Pool
(Remote DHCP)

Roles
Enterprise

Voice
SSID

DSL
MPLS
Frame Relay

Voice
Guest

Internet
Services

Family SSID

Remote Access
Point
IP Address Pool
(Local DHCP)

Enterprise
SSID

Enterprise
Wired Access
IP Phone

Game Console/
DVR

Shared
Printer
Family PC

Wired PC

Figure 11

RNSG_108

Family
Wired Access

Fixed Telecommuter Home Network

To create enterprise and family access from the home environment, customers deploy an Aruba RAP
that is plugged directly into the WAN via a Digital Subscriber Line (DSL) or cable modem. The RAP is
configured to support both secure enterprise access and shared family access using the role-based
access control capability inherent in ArubaOS. Wired devices are connected directly to one or more
secure jacks on the AP and wireless devices associate to one of three secure SSIDs.
Employee PC and laptop devices are assumed to use 802.1X whether wired or wireless, while
enterprise voice devices use the strongest authentication mode that they are capable of using. The
security design will be explored in greater detail in Chapter 7: Authentication and Security Design.
Family wireless users access the family SSID and family wired devices are connected directly to or via
a hub or switch that is uplinked to a secure jack on the RAP that is statically configured for family and
Internet access. The built-in firewall inside the RAP is configured with unidirectional ACLs so that the





family printer can be accessed from the employee devices. Internet access is implemented via splittunnel for both employee and family devices.

NOTE

In this VRD, it is assumed that each wired port is preconfigured for the specific
device that will be plugged into it. Aruba calls this “Per Port” configuration.

For family devices, a third-party hub (e.g. a layer 1 repeater) or layer 2 switch may be installed on a
wired RAP port to aggregate traffic from multiple devices. Identical authentication methods and roles
must be in use on each of the devices, however, because all users sharing the same wired port will
also share the same role, policies, and VLAN settings.
A layer 2 switch must never be used for enterprise wired devices if 802.1X authentication is in use,
because 802.1X EAPOL frames are processed by the switch rather than forwarded.

NOTE

Do not use a layer 2 switch in front of a RAP wired port if 802.1X
authentication is in use.

The Fixed Telecommuter Call Center Environment

The Aruba remote networking solution offers great flexibility to the enterprise with respect to the
services it wishes to offer to its employees. To illustrate this flexibility, we present as part of the
reference design a remote call center agent with a restricted configuration.
Home-based agents can be implemented as a special case of the home environment with two
important differences:
 Very low cost AP with only two wired ports
 No family access
The Aruba RAP-2WG is recommended for this scenario. To create wired access to the call center
environment, the RAP is configured so that the IP phone connects to a second secure jack on the AP
via an 802.1Q trunk. The wired PC then connects to the phone. Internet access for the employee PC is
allowed via split-tunnel, as seen in Figure 12. The RAP-2WG includes a 802.11b/g radio that can be
enabled if the organization wishes.

Enterprise
Access

RAP
Data
Center

IP Phone

Internet
Services

Figure 12


Wired PC
Roles
Enterprise
Voice

RNSG_109

802.1Q Trunk

Internet or
WAN

Fixed Telecommuter Call Center Application




Figure 12 shows how the versatility of the Aruba RAP solution can support various enterprise postures
with respect to providing home Internet connectivity to employees, at low cost to the organization.
The Branch Office Solution

The Aruba remote network solution provides an extension of the enterprise LAN into the branch office
without the complexity of enterprise LAN routing, firewall, and VPN equipment. In this use case, an
Aruba RAP is wire-connected to a Frame Relay, DSL, MPLS, or other service provider premise device
for its WAN uplink. On the downlink side, three devices are connected to the RAP:
 Branch office employee wired devices are connected to a hub or switch that is uplinked to a
secure jack configured for enterprise and Internet access
 Guest (vendors and customers, for example) wired devices are connected to a second hub or
switch that is uplinked to another secure jack configured for controlled Internet access
 A local server is connected to a third secure jack, which allows for convenient traffic control via
locally enforced security policies
This reference design requires an Aruba RAP-5WN access point to provide the number of secure
jacks required for this application. This design is illustrated in the following drawing.
Roles
Enterprise

Data
Center
Enterprise
LAN
3G
WWAN

Enterprise
IP Address Pool
(Remote DHCP)

Voice

Internet or
WAN

Guest

DSL
MPLS
Frame Relay

Internet
Services

Remote Access
Point
IP Address Pool
(Local DHCP)

Voice
SSID

Guest
SSID
Enterprise
SSID
Guest
Wired Access

RNSG_107

Enterprise
Wired Access

HTTPS
Application
Server

Figure 13

Remote Branch Office Network

Wireless services can be offered on either the 2.4 GHz or 5 GHz bands for maximum compatibility and
performance; Aruba offers a flavor of the RAP5 that does not include any radio for wired-only
deployments. Aruba also offers dual-radio access points to meet requirements for simultaneous
802.11 a/b/g/n deployments.




Data Center Physical Architecture
Production remote networking deployments are IT services that are expected to maintain high
availability and performance levels. Therefore, Aruba recommends deploying two master controllers in
the data center. These master controllers are configured in an “active-standby” configuration that
provides 1:1 redundancy. In the Virtual Branch Networks VRD, the master controllers do not terminate
APs. The redundant local controllers are located on the DMZ and terminate the RAPs in the remote
network. The AirWave appliances are also located in the data center.
Colocating Remote Network and Campus Controllers

Aruba offers special-purpose code trains such as Remote Networking (RN) and Federal Information
Processing Standard 140-2 (FIPS) in addition to our mainline releases. This VRD is based on the RN
code train. The RN release is required to manage the RAP-5WN, RAP-5, and RAP-2WG hardware, as
well as to provide many of the remote networking features described in this VRD such as zero touch
provisioning. Controllers running the RN code train are not intended to manage locally-connected, or
“campus” access points. Therefore, separate controller clusters are required for remote network and
campus deployments.
Adding a new Aruba master/local cluster to a data center with an existing master/local cluster serving
campus APs is very simple. Two pairs of master controllers should have redundant connections to the
core network. One pair runs the RN code train, and the other runs mainline ArubaOS.
The local controller pair that manages the remote access points must run the RN code train and
should be located in the DMZ with one-armed connections to DMZ switches. The other pair of local
controllers is typically connected to distribution layer switches via one-armed connections. This
controller pair runs mainline ArubaOS.
Data Center
AirWave Management
Platform

Remote Network

Campus Network

Master
active

Master
standby

Master
active

Master
standby

Application
DHCP/
DNS
PBX
RADIUS

Distribution Layer

DMZ

Campus

RAP

Local
active

Local
active

RAP

Local
active

Local
active

Internet
or WAN

Figure 14


RNSG_114

Campus

Aruba Remote Network Physical Architecture




During the staging process, RAPs must communicate with a master controller running RN code in
order to be provisioned. Aruba customers that are already using DNS autodiscovery of “aruba-master”
for bootstrapping of campus APs must use DHCP Option 43 for RAPs to discover the proper master
controller. The simplest method is to use a private IT testing subnet with a local DHCP server that is
configured to offer the IP address of the RN master controller. This is only required if you plan to use
the pre-provisioning deployment method described in Chapter 8. By contrast, zero touch provisioning
uses either a static public IP address or an externally-resolvable FQDN that is entered by the remote
user after plugging the RAP into a broadband WAN link.

Required Equipment
To adapt the general physical design shown in Figure 10 on page 40 for your organization, you must
make a series of hardware selections. Aruba recommends that you proceed from the AP level inward
to the local controller and then to the master controller levels. Follow this decision tree as you work
through the process.
Branch Office
Select
RAP Model(s)

Select
RAP Model(s)

Estimate
Client Device Count
(using Table 2)

Estimate
Client Device Count
(using Table 3)

Multiply
Client Device Count
by Site Count
(using Table 1)

Remote
Sites

Fixed Telecommuter

Multiply
Client Device Count
by Site Count
(using Table 1)

Select
Local Controller Model
equal to 150% of Total
Client Device Count
(each)

DMZ

Select
Master Controller Model
(using Table 3)

Multiple
Masters
required?

Data
Center

Yes

Assign all Locals
to separate
Master/Local clusters

Select
AirWave Server Appliance
equal to 150% of
All APs & Controllers

Figure 15


RNSG_153

No

Equipment Decision Tree




Access Points
This VRD assumes the use of Aruba dedicated RAP models for large-scale, production deployments.
We also assume the use of APs that offer at least two Ethernet ports to provide for a secure wired jack.
This use provides maximum flexibility and allows for local wired bridging applications. As of this
writing, these APs include:

Aruba RAP-5 Remote Access Point
4 Wired Ports + 1 Uplink Port
No Wireless Radio
Up to 256 users/devices
1 USB Port
PoE or 12V DC Powered

Aruba RAP-2WG Remote Access Point
1 Wired Port + 1 Uplink Port
Single 802.11 b/g Radio
12V DC Powered

Figure 16

Aruba RAP-5WN Remote Access Point
4 Wired Ports + 1 Uplink Port
Single 3x3 MIMO Radio, 802.11a/b/g/n
1 USB Port

Aruba AP-125 Access Point
1 Wired Port + 1 Uplink Port
Dual 3x3 MIMO Radios, 802.11/a/b/g/n

Aruba Dedicated Remote Access Point Product Family

These models include features specifically designed and tested for remote deployments such as
certificate-based zero touch provisioning. These AP models are not intended or supported for local
campus deployments.

NOTE


All Aruba campus AP models can be deployed in a RAP. However, campus
APs such as the AP-AP70 and AP-120 series do not contain certificates and do
not support zero touch provisioning.




With Aruba Software-Defined Radio (SDR) technology, APs can be used anywhere in the world. It is
not necessary to stock different AP models on a per-country basis for regulatory reasons. Regulatory
compliance on Aruba products is managed at the controller level, as we will discuss later in this
chapter.
Please note that RAPs can be ordered as US and ROW (Rest of World) models based on electrical
requirements. The available SKUs are:
Table 5

RAP-5 and RAP-2 SKUs

SKU

Description

RAP-2WG-US

Aruba Remote Access Point Model 2WG, US power supply

RAP-2WG-EU

Aruba Remote Access Point Model 2WG, EU power supply

RAP-2WG

Aruba Remote Access Point Model 2WG, International power adapter kit

RAP-5WN-US

Aruba Remote Access Point Model 5WN (Wired and Wireless), US power supply

RAP-5WN

Aruba Remote Access Point Model 5WN (Wired and Wireless), International power kit

RAP-5-US

Aruba Remote Access Point Model 5 (Wired Only), US power supply

RAP-5

Aruba Remote Access Point Model 5 (Wired Only), International power kit

Local Controllers
To build the Aruba VRD as shown in (Figure 10 on page 40) appropriately sized local controllers are
deployed in the enterprise DMZ. Local controllers terminate AP tunnels and serve as an enforcement
point for security policies. The reference design assumes full 1+1 redundancy, which requires a pair of
identically configured local controllers in support of failover.

Aruba 3600 Controller
Up to 512 RAPs (2,048 Users)
4 Gigabit Ethernet (1000Base-T or 1000Base-X SFP)

Figure 17


Aruba M3 Blade
Up to 2,048 RAPs (8,192 users)
10 1000Base-X Ethernet ports (SFP)
2 10GBase-X Ethernet ports (XFP)
1 1000Base-T Ethernet port (RJ-45)

Aruba Controller Blades for MMC-6000 Chassis




In order to utilize zero touch provisioning and/or certificate-based authentication, it is necessary to use
either an Aruba 3000-series controller or M3-series blade. Like the RAP-2 and RAP-5 access points,
these controllers include an integrated security certificate.
Controller Sizing

This Virtual Branch Networks VRD assumes that local controllers to reside in the DMZ will be sized
according to the number of RAPs they terminate, as well as the total number of client devices on all the
RAPs. As we will discuss later in this chapter, in full 1+1 redundancy deployments, each controller
must be capable of assuming the entire load of APs in remote sites that are assigned to it. Therefore,
local controllers should be sized and licensed so that 50% of the RAP population terminates on each
unit during normal operation.
For large RAP deployments, the VRD assumes the use of either the MMC-3600 standalone controller
or M3-series controller blade in an A6000-series chassis with redundant 400W power supplies. Two
identically configured chassis are installed in the DMZ in a 1+1 redundancy model. Up to 4 M3 blades
can be installed in a single chassis to serve up to 8,192 remote sites and 32,768 users or devices.
Certificate-based provisioning and zero touch provisioning are only supported
on the M3 Blade and 3000 series controllers.

NOTE

Table 6

Controller Product Line Matrix
MMC-3000 Series

MMC-6000 Series

Features
MMC-3200

MMC-3400

MMC-3600

M3 Blade

Chassis
(4 Blades)

Max number of campus-connected APs per
controller

32

64

128

512

2,048

Max number of RAPs per controller

128

256

512

2,048

8,192

Max number of users or devices per controller

512

1,024

2,048

8,192

32,768

64,000

64,000

64,000

64,000

256,000

Maximum number of concurrent tunnels

128

256

512

2,048

8,192

Maximum number of VLANs

128

256

512

2048

8,192

Zero touch provisioning supported

Yes

Yes

Yes

Yes

Yes

MAC addresses





The user and RAP limits from Table 6 can be combined in matrix form. Use the following table to select
the appropriate model and quantity of controller for your deployment. Use the same model for both
active local controllers.
Table 7

Local Controller Sizing by License Count
RAP Site Count

Devices per Site

50

100

250

500

1,000

2,000

1

MMC-3200

MMC-3200

MMC-3400

MMC-3600

1xM3

1xM3

5

MMC-3200

MMC-3200

MMC-3600

1xM3

1xM3

2xM3

10

MMC-3200

MMC-3400

1xM3

1xM3

2xM3

3xM3

MMC-3400

MMC-3600

1xM3

1xM3

2xM3

4xM3

15

A quantity of the appropriate SFP and/or XFP modules may also be required; Aruba offers a complete
line of modules on its price list.
International Regulatory Compliance

The United States and Israel restrict the Aruba controller to managing only APs that are located within
those countries. Aruba offers country-specific SKUs for these two areas. All other countries in an
international deployment can be managed from a single Rest of World (ROW) controller. When
ordering Aruba controller SKUs, be careful to order the appropriate country SKU for the location where
the controller will be installed. For additional information, see the Regulatory Compliance section later
in this chapter or consult your Aruba representative.
Master Controllers
Master controllers serve as a central point of configuration for the system. Masters also offload
network management, wireless IDS (WIDS), and RF decision making from the local controllers. This
VRD assumes either the MMC-3600 standalone controller or M3-series controller blade in its 6000series chassis with redundant 400W power supplies.

NOTE

Certificate-based provisioning and zero touch provisioning are only supported
on the M3 Blade and 3000 series controllers.

Figure 18

Aruba MMC-6000 Chassis with 4 M3 Blades



Controller Sizing

The proper size of a master controller is determined by both the number of connected or associated
wired and wireless user devices as well as the number of APs managed by all of the downstream
locals. Even though AP tunnels do not terminate on the master, each RAP transmits WIDS and RF
telemetry directly to the master. Aruba has thoroughly tested all of its controller models in a master role
supporting various AP and local controller loads.
Table 8

Maximum Number of APs and Users or Devices per Master Controller Model
Maximum APs

Maximum Users
or Devices

M3 Blade/MMC-3600

4,500

15,000

MMC-3400

2,250

7,500

MMC-3200

1,500

4,500

Master

The user or device and AP limits from these tables can be combined in a matrix form. Use the
following table to select the appropriate controller model for your deployment. Use the same model for
both the active master and the standby master.
Table 9

Master Controller Sizing by Client Device Count
Number of RAP Sites

Devices per Site

50

100

250

500

1,000

2,000

1

MMC-3200

MMC-3200

MMC-3200

MMC-3200

MMC-3200

MMC-3200

5

MMC-3200

MMC-3200

MMC-3200

MMC-3200

MMC-3400

MMC-3600

10

MMC-3200

MMC-3200

MMC-3200

MMC-3400

MMC-3600

M3 Blade

15

MMC-3200

MMC-3200

MMC-3200

MMC-3400

M3 Blade

M3 Blade

Very large deployments that require more than one M3 blade for a master should be divided into
clusters of locals, each with its own master. Use one M3 blade configured as the active master for
each cluster, with a second M3 blade configured as a standby master. Up to four active masters or
standby masters can be installed in a single A6000 chassis. Aruba does not recommend collocating
active and standby masters in the same chassis.
International Regulatory Compliance

The United States and Israel restrict master controllers to managing only local controllers that are
located within those countries. Aruba offers country-specific SKUs for these two areas. All other
countries in an international deployment can be managed from a single Rest of World (ROW)
controller. When ordering Aruba controller SKUs, be careful to order the appropriate country SKU for
the location where the controller will be installed. For additional information, see the Regulatory
Compliance section later in this chapter or consult your Aruba representative.





AirWave Appliance
AirWave offers two different hardware appliance models. They are sized based on the number of APs
and controllers being managed. For large deployments, you purchase and deploy multiple AirWave
appliances, and the software will automatically cluster the controllers together and distribute the
processing workload appropriately. The SKUs are: AMP-HW-ENT, AirWave Management Platform for
managing up to 2,500 devices, and AMP-HW-PRO, AirWave Server Appliance for managing up to
1,000 devices.

Required Licenses
To support RAPs, the local controllers must have RAP licenses to provide IPsec encryption and splittunnel or local bridging features. All controllers in a Master/Local cluster must be running the same
version of software.

NOTE

Aruba has released a dedicated code train for Remote Networking
deployments. This VRD is based on ArubaOS 3.3.2.11-rn3.0. The mainline
ArubaOS code train does not include many of the remote networking features
discussed in the VRD and should not be used.

Local Controllers
To build this Aruba VRD as depicted, the following licenses are required on each of the local
controllers, assuming that there are a total of 2,048 Aruba RAPs being managed, with an MMC-6000
Multiservice Aruba Controller acting as a backup to a second MMC-6000:




LIC-2048-RAP Remote Access Point License (2048 RAPs)
LIC-WIP-2048 Wireless Intrusion Protection Module License (2,048 AP Support)
LIC-PEF-4096 Policy Enforcement Firewall Module License (4,096 Users, 2:1 PEF users to
RAPs)

The ratio of PEF users to RAPs is 2:1 and is determined by the number of devices accessing the
network through each RAP.
Master Controllers
The following licenses should be applied to the master controllers, assuming a MMC-3600 controller
with no APs terminating and not acting as a backup for any local controller:
 LIC-1-RAP Remote Access Point License (1 RAP)
 LIC-WIP-8 Wireless Intrusion Protection Module License (8 AP Support)


LIC-PEF-128 Policy Enforcement Firewall Module License (128 Users1)

It should be noted that each RAP counts towards the RAP License count, while each SSID on a radio
plus each wired port in use counts as one (1) tunnel against the total concurrent tunnel capacity of the
controller serving as the local. Concurrent tunnel capacity is indicated on the datasheet for each Aruba
controller.
1. Users on a tunnel in bridge forwarding mode need not be added to the total user count for a controller PEF license.





AirWave Appliance
The AirWave Management Platform (AMP) is licensed using the same sizing criteria as the hardware
appliance:
 AMP-ENT, AirWave Management Platform software for a single server with no limit on
processor cores. Recommended for managing up to 2,500 devices such as controllers, wireless
access points, or switches.
 AMP-PRO, AirWave Management Platform software for a single server with up to four processor
cores. Recommended for managing up to 1,000 devices such as controllers, wireless access
points, or switches.
Both SKUs include the full selection of AirWave modules, including the AirWave Management Platform
(AMP), Visualization and mapping software module (Visual RF), and RAPIDS (Rogue detection
software).

3G Modem Selection
3G service providers supply lists of wireless modems that are supported in their networks. The
availability of 3G service from wireless carriers continues to increase rapidly, and more modems are
being introduced by a variety of manufacturers.
USB cellular modems are supported via the USB port on the AP-70, RAP-5, and RAP5-WN. ArubaOS
3.3.2.0-rn3.0 supports several EVDO (Evolution Data Optimized, up to 3.1 Mbps, CDMA) and 3G
HSPA (High-Speed Packet Access, 3G data service) modems. This software release, with its built-in
flexibility, can support future USB modems and protocols without a software code change. 3G HSPA is
provided by AT&T in the United States and by numerous other 3G providers worldwide. The following
USB modems are verified in this release:
Manufacturer

Model

AT&T

USBConnect 881 (Sierra 881U)
Mercury (Sierra Compass 885)
Quicksilver (Globetrotter ICON 322)
Huawei E272, E170, E220

Sprint

Compass 597 (Sierra)
USB 598 (Sierra)
Ovation U727 (Novatel)
U300 (Franklin wireless)

Verizon

USB U727 (Novatel)
USB U720 (Novatel/Qualcomm)
UM175 (Pantech)
UM150 (Pantech)
U597 (Sierra)



Virtual Branch Networks

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Virtual Branch Networks

Similar a Virtual Branch Networks (20)

Más de Content Rules, Inc.

Más de Content Rules, Inc. (20)

Último

Último (20)

Virtual Branch Networks