advertisement
ArubaOS 6.5.3.x
Copyright Information
© Copyright 201
8
Hewlett Packard Enterprise Development LP.
Open Source Code
This product includes code licensed under the GNU General Public License, the GNU Lesser General Public
License, and/or certain other open source licenses. A complete machine-readable copy of the source code corresponding to such code is available upon request. This offer is valid to anyone in receipt of this information and shall expire three years following the date of the final distribution of this product version by Hewlett
Packard Enterprise Company. To obtain such source code, send a check or money order in the amount of US
$10.00 to:
Hewlett Packard Enterprise Company
Attn: General Counsel
3000 Hanover Street
Palo Alto, CA 94304
USA
Revision 04 | August 2018 ArubaOS 6.5.3.x | User Guide
Contents
About this Guide
The Basic User-Centric Networks
Understanding Basic Deployment and Configuration Tasks
Controller Configuration Workflow
Connect the Controller to the Network
7000 Series and 7200 Series Controllers
Configuring a VLAN to Connect to the Network
Enabling Wireless Connectivity
Enabling Wireless Connectivity
Configuring Your User-Centric Network
Control Plane Security
Control Plane Security Overview
Configuring Control Plane Security
Managing Whitelists on Master and Local Controllers
Working in Environments with Multiple Master Controllers
Replacing a Controller on a Multi-Controller Network
Configuring Control Plane Security after Upgrading
Troubleshooting Control Plane Security
Software Licenses
Getting Started with ArubaOS Licenses
ArubaOS 6.5.3.x
| User Guide
Contents
78
54
3
17
33
Contents | 3
4 | Contents
Licensing Best Practices and Limitations
Centralized Licensing Overview
Configuring Centralized Licensing
Monitoring and Managing Centralized Licenses
Network Configuration Parameters
Understanding VLAN Assignments
Configuring the Loopback IP Address
Configuring the Controller IP Address
IPv6 Support
Enabling IPv6 Support for Controller and APs
Filtering an IPv6 Extension Header (EH)
Configuring a Captive Portal over IPv6
Working with IPv6 Router Advertisements (RAs)
Understanding ArubaOS Supported Network Configuration for IPv6 Clients
Understanding ArubaOS Authentication and Firewall Features that Support IPv6
Understanding IPv6 Exceptions and Best Practices
Link Aggregation Control Protocol
Understanding LACP Best Practices and Exceptions
ArubaOS 6.5.3.x | User Guide
129
156
96
OSPFv2
Understanding OSPF Deployment Best Practices and Exceptions
Understanding OSPFv2 by Example using a WLAN Scenario
Understanding OSPFv2 by Example using a Branch Scenario
Sample Topology and Configuration
Tunneled Nodes
Understanding Tunneled Node Configuration
Configuring a Wired Tunneled Node Client
Authentication Servers
Understanding Authentication Server Best Practices and Exceptions
Understanding Servers and Server Groups
Configuring Authentication Servers
Managing the Internal Database
Configuring Authentication Timers
Authentication Server Load Balancing
MAC-based Authentication
Configuring MAC-Based Authentication
Branch Controller Config for Cloud Services Controllers
Scalable Site-to-Site VPN Tunnels
Layer-3 Redundancy for Branch Controller Masters
WAN Failure (Authentication) Survivability
WAN Optimization through IP Payload Compression
Branch Integration with a Palo Alto Networks (PAN) Portal
Branch Controller Routing Features
Using Smart Config to create a Branch Config Group
ArubaOS 6.5.3.x
| User Guide
214
217
160
176
179
Contents | 5
6 | Contents
Preventing WAN Link Failure on Virtual APs
802.1X Authentication
Understanding 802.1X Authentication
Configuring 802.1X Authentication
Enabling 802.1X Supplicant Support on an AP
Performing Advanced Configuration Options for 802.1X
Application Single Sign-On Using L2 Authentication
Device Name as User Name for Non-802.1X Authentication
Stateful and WISPr Authentication
Working With Stateful Authentication
Working With WISPr Authentication
Understanding Stateful Authentication Best Practices
Configuring Stateful 802.1X Authentication
Configuring Stateful NTLM Authentication
Configuring Stateful Kerberos Authentication
Configuring WISPr Authentication
Certificate Revocation
Configuring the Controller as an OCSP Client
Configuring the Controller as a CRL Client
Configuring the Controller as an OCSP Responder
Certificate Revocation Checking for SSH Pubkey Authentication
Captive Portal Authentication
Configuring Captive Portal in the Base Operating System
Using Captive Portal with a PEFNG License
Sample Authentication with Captive Portal
Configuring Captive Portal Authentication Profiles
Enabling Optional Captive Portal Configurations
Personalizing the Captive Portal Page
297
304
265
312
ArubaOS 6.5.3.x | User Guide
Creating and Installing an Internal Captive Portal
Enabling Captive Portal Enhancements
Netdestination for AAAA Records
Virtual Private Networks
Working with VPN Authentication Profiles
Configuring a Basic VPN for L2TP/IPsec
Configuring a VPN for L2TP/IPsec with IKEv2
Configuring a VPN for Smart Card Clients
Configuring a VPN for Clients with User Passwords
Configuring Remote Access VPNs for XAuth
Working with Remote Access VPNs for PPTP
Working with Site-to-Site VPNs
Roles and Policies
Understanding Global Firewall Parameters
ClearPass Policy Manager Integration
Enabling Downloadable Role on a Controller
Virtual APs
Virtual AP Configuration Workflow
Changing a Virtual AP Forwarding Mode
Radio Resource Management (802.11k)
BSS Transition Management (802.11v)
Fast BSS Transition ( 802.11r)
ArubaOS 6.5.3.x
| User Guide
381
352
408
417
Contents | 7
8 | Contents
Changing a Virtual AP Forwarding Mode
Adaptive Radio Management
ARM Coverage and Interference Metrics
Assigning an ARM Profile to an AP Group
Using Multi-Band ARM for 802.11a/802.11g Traffic
Reusing Channels to Control RX Sensitivity Tuning
Configuring Non-802.11 Noise Interference Immunity
Wireless Intrusion Prevention
Working with the Reusable Wizard
Working with Intrusion Detection
Configuring Intrusion Protection
Configuring the WLAN Management System
Understanding Client Blacklisting
Working with WIP Advanced Features
Access Points
479
455
513
ArubaOS 6.5.3.x | User Guide
Understanding AP Configuration Profiles
Enable DHCP to Provide APs with IP Addresses
Optional AP Configuration Settings
Optimizing APs Over Low-Speed Links
Configuring AP Channel Assignments
Link Aggregation Support on 220 Series, 270 Series, 320 Series, and 330 Series
Recording Consolidated AP-Provisioned Information
Secure Enterprise Mesh
Understanding Mesh Access Points
Understanding Remote Mesh Portals (RMPs)
Understanding the AP Boot Sequence
Configuring Mesh Cluster Profiles
Creating and Editing Mesh Radio Profiles
Creating and Editing Mesh High-Throughput SSID Profiles
Configuring Ethernet Ports for Mesh
Configuring Remote Mesh Portals (RMPs)
ArubaOS 6.5.3.x
| User Guide
600
Contents | 9
10 | Contents
Increasing Network Uptime Through Redundancy and VRRP
High Availability Deployment Models
High Availability Inter-Controller Heartbeats
High Availability Extended Controller Capacity
Migrating from VRRP or Backup-LMS Redundancy
RSTP
Understanding RSTP Migration and Interoperability
Working with Rapid Convergence
PVST+
Understanding PVST+ Interoperability and Best Practices
Link Layer Discovery Protocol
IP Mobility
Understanding Aruba Mobility Architecture
Configuring Advanced Mobility Functions
Understanding Bridge Mode Mobility Deployments
External Firewall Configuration
Understanding Firewall Port Configuration Among Aruba Devices
ArubaOS 6.5.3.x | User Guide
668
689
660
662
638
656
Ports Used for Virtual Intranet Access (VIA)
Configuring Ports to Allow Other Traffic Types
PAPI Enhanced Security
Configuring PAPI Enhanced Security
Verifying PAPI Enhanced Security
Palo Alto Networks Firewall Integration
Preconfiguration on the PAN Firewall
Configuring PAN Firewall Integration
Remote Access Points
Configuring the Secure Remote Access Point Service
Deploying a Branch/Home Office Solution
Enabling Remote AP Advanced Configuration Options
Provisioning 4G USB Modems on Remote Access Points
Configuring RAP-3WN and RAP-3WNP Access Points
Converting an IAP to RAP or CAP
Enabling Bandwidth Contract Support for RAPs
Virtual Intranet Access
Spectrum Analysis
Understanding Spectrum Analysis
Creating Spectrum Monitors and Hybrid APs
Connecting Spectrum Devices to the Spectrum Analysis Client
Configuring the Spectrum Analysis Dashboards
Customizing Spectrum Analysis Graphs
Working with Non-Wi-Fi Interferers
Understanding the Spectrum Analysis Session Log
Viewing Spectrum Analysis Data
ArubaOS 6.5.3.x
| User Guide
753
754
701
693
695
Contents | 11
12 | Contents
Recording Spectrum Analysis Data
Troubleshooting Spectrum Analysis
Dashboard Monitoring
Automatic Reporting (PhoneHome)
Sending Reports to Activate vs. SMTP Servers
Configuring PhoneHome Automatic Reporting
Management Access
Configuring Certificate Authentication for WebUI Access
Enabling RADIUS Server Authentication
Connecting to an AirWave Server
Custom Certificate Support for RAP
Implementing a Specific Management Password Policy
Configuring Centralized Image Upgrades
801
839
844
ArubaOS 6.5.3.x | User Guide
Managing Files on the Controller
ClearPass Profiling with IF-MAP
802.11u Hotspots
Hotspot Profile Configuration Tasks
Configuring Hotspot 2.0 Profiles
Configuring Hotspot Advertisement Profiles
Configuring ANQP Venue Name Profiles
Configuring ANQP Network Authentication Profiles
Configuring ANQP Domain Name Profiles
Configuring ANQP IP Address Availability Profiles
Configuring ANQP NAI Realm Profiles
Configuring ANQP Roaming Consortium Profiles
Configuring ANQP 3GPP Cellular Network Profiles
Configuring H2QP Connection Capability Profiles
Configuring H2QP Operator Friendly Name Profiles
Configuring H2QP Operating Class Indication Profiles
Configuring H2QP WAN Metrics Profiles
Configuring H2QP OSU Provider List Profiles
Adding Local Controllers
Moving to a Multi-Controller Environment
Uplink Monitoring and Management
Voice and Video
Voice and Video License Requirements
Working with QoS for Voice and Video
Unified Communication and Collaboration
ArubaOS 6.5.3.x
| User Guide
930
937
904
Contents | 13
14 | Contents
Understanding Extended Voice and Video Features
Advanced Voice Troubleshooting
AirGroup
AirGroup Integrated Deployment Model
Features Supported in AirGroup
ClearPass Policy Manager and ClearPass Guest Features
Auto-association and Controller-based Policy
Best Practices and Limitations
Controller Dashboard Monitoring
Configuring the AirGroup-CPPM Interface
Bluetooth-Based Discovery and AirGroup
mDNS Multicast Response Propagation
Troubleshooting and Log Messages
Instant AP VPN Support
External Services Interface
Understanding the ESI Syslog Parser
Sample Route-Mode ESI Topology
Understanding Basic Regular Expression (BRE) Syntax
External User Management
1048
1056
1080
1004
ArubaOS 6.5.3.x | User Guide
Behavior and Defaults
Understanding Basic System Defaults
Understanding Default Management User Roles
Understanding Default Open Ports
DHCP with Vendor-Specific Options
Configuring a Windows-Based DHCP Server
Enabling DHCP Relay Agent Information Option (Option-82)
802.1X Configuration for IAS and Windows Clients
Configuring Management Authentication using IAS
Window XP Wireless Client Sample Configuration
Glossary of Terms
1097
1113
1120
1127
ArubaOS 6.5.3.x
| User Guide Contents | 15
Revision History
The following table lists the revisions of this document.
Table 1: Revision History
Revision
Revision 04
Revision 03
Revision 02
Revision 01
Change Description n n
Updated
VIA Firewall Port Information .
Documented the correct default value for the Interval between Identity
Requests parameter in the 802.1X authentication profile.
n n n
Smart Rate feature is added under the topic,
.
Removed an invalid limitation from the chapter,
Tunneled Node Client on page 177 .
Updated the description for Transmit EIRP under the topic,
.
Updated acronyms in the
ClearPass Policy Manager Integration on page 408
chapter.
Initial release.
16 | Contents ArubaOS 6.5.3.x | User Guide
About this Guide
This User Guide describes the features supported in ArubaOS 6.5.3.x and provides instructions and examples to configure controllers and access points (APs). This guide is intended for system administrators responsible for configuring and maintaining wireless networks and assumes administrator knowledge in Layer 2 and Layer
3 networking technologies.
This chapter covers the following topics: n n n n n
What's New In ArubaOS 6.5.x on page 17
What's New In ArubaOS 6.5.x
This section lists the new features and enhancements introduced in ArubaOS 6.5.x.
Features in ArubaOS 6.5.3.0
The following features are introduced in ArubaOS 6.5.3.0:
Table 2: New Features in ArubaOS 6.5.3.0
Feature
Description
Starting with ArubaOS 6.5.3.0, users can specify the source IP address of
AMON packets emitted from the controller.
Starting with ArubaOS 6.5.3.0, users can predefine the AP mode using the
AP deployment policy. The AP deployment policy redirects all APs in the specified IP address ranges to the Instant discovery process, ensuring that the APs run only in controller-less mode.
Starting with ArubaOS 6.5.3.0, controllers provide device certificate for APs that do not have a TPM chip. The factory certificate of the AP is validated against the device certificate stored on the controller.
ArubaOS 6.5.3.x
| User Guide About this Guide | 17
Features in ArubaOS 6.5.2.0
The following features are introduced in ArubaOS 6.5.2.0:
Table 3: New Features in ArubaOS 6.5.2.0
Feature
Description
Starting with ArubaOS 6.5.2.0, APs can run in either controller-based mode or controller-less mode. Based on the selected mode, the AP runs a different image: n n
Controller-based APs run an ArubaOS image.
Controller-less APs run an Instant image.
The AP Health check feature uses ping probes to check reachability and latency levels for the connection between the AP and the controller. The recorded latency information appears in the output of the show ap ip health-check command. If the controller IP address becomes unreachable from the AP uplink, this feature records the time that the connection failed, and saves that information in a log file.
Starting with ArubaOS 6.5.2.0, dynamic data for the included attributes in the RADIUS Attribute modifier is supported. Users can configure the dynamic value for each included attribute in the RADIUS modifier.
This feature allows the AP to seamlessly switch between modes where the radio resources are either combined in a single 2x2 radio (2.4 GHz or 5
GHz), or separated in two 1x1 radios (2.4 GHz and 5 GHz).
Starting with ArubaOS 6.5.2.0, inline monitoring feature is supported for
Remote APs.
Starting with ArubaOS 6.5.2.0, the Roaming RADIUS Accounting Service feature offers tracking a wireless client who roams to a different AP.
Starting with ArubaOS 6.5.2.0, a user has the option of specifying the source IP for a TACACS server.
Starting with ArubaOS 6.5.2.0, APs can monitor BLE asset tags to track the location of time-sensitive, high-value assets embedded with BLE tags.
Starting with ArubaOS 6.5.2.0, IPM is supported in AP-303H access points.
When AirMatch monitoring is enabled in the AP system profile, each AP measures its RF environment every 30 minutes by default. The controller uses this information to analyze its RF neighborhood, and can send this information in AMON messages.
The Smart Antenna setting is introduced to support the smart antenna feature on the AP-335, which optimizes the selection of antenna polarization values.
Starting with ArubaOS 6.5.2.0, the centralized licensing feature supports topologies where a licensing master is connected to a standalone master licensing client controller, a redundant licensing server, and a local licensing client controller.
Starting from ArubaOS 6.5.2.0 introduces the option of configuring syslog messages to originate from any IP other than the controller IP.
18 | About this Guide ArubaOS 6.5.3.x | User Guide
Table 3: New Features in ArubaOS 6.5.2.0
Feature Description
Transmit Power Calculation support
Starting with ArubaOS 6.5.2.0, PSK RAPs support IKEv1 SHA-2 cryptographic hash function.
Starting with ArubaOS 6.5.2.0, this feature allows calculation of the transmit power of each outgoing 802.11 packet so that AP adheres to the latest regulatory limits.
A factory-default controller running ArubaOS 6.5.1.4 or ArubaOS 6.5.2.0 or later can use Activate Zero-Touch Provisioning to upgrade its software to the latest version of ArubaOS 8.x as part of the provisioning process.
ArubaOS 6.5.3.x
| User Guide About this Guide | 19
Table 4: New Hardware Platforms in ArubaOS 6.5.2.0
Check with your local Aruba sales representative on new controllers and APs available in your country.
Hardware
AP-203H Access Point
203R Series Remote Access
Points
AP-303H Access Point
Description
The AP-203H access point is an IEEE 802.11ac standard high-performance flex-radio wireless device ideal for hospitality and branch deployments.
The AP is software configurable as either a single radio dual band or dual radio. MIMO technology allows the AP to deliver high-performance
802.11n 2.4 GHz and 802.11ac 5 GHz functionality, while also supporting
802.11a, b, and g wireless services. The AP works in conjunction with a controller.
The AP provides the following capabilities: n n
IEEE 802.11a, b, g, n, or ac operation as a wireless access point
IEEE 802.11a, b, g, n, or ac operation as a wireless air monitor n n
Compatible with IEEE 802.3af PoE
Centralized management configuration
For technical specifications, see the AP-203H Access Point data sheet. For installation instructions, see the AP-203H Access Point Installation Guide .
The 203R Series (AP-203R and AP-203RP) Remote APs are IEEE 802.11ac
standard high-performance Remote APs ideal for home and branch deployments. MIMO technology allows these Remote APs to deliver highperformance 802.11n 2.4 GHz and 802.11ac 5 GHz functionality, while also supporting 802.11a, b, and g wireless services. The Remote APs work in conjunction with a controller.
The Remote APs provides the following capabilities: n IEEE 802.11a, b, g, n, or ac operation as a wireless access point n n n n n n
IEEE 802.11a, b, g, n, or ac operation as a wireless air monitor
Compatible with IEEE 802.3at PoE
Centralized management configuration
Support for PoE-in (E0 port)/PoE-out (E2 port)
Support for selected USB peripherals
Integrated BLE radio
For technical specifications, see the 203R Series Remote Access Points data sheet. For installation instructions, see the 203R Series Remote Access
Points Installation Guide .
The AP-303H access point is an IEEE 802.11ac standard high-performance wireless device ideal for hospitality and branch deployments. MIMO technology allows the AP to deliver high-performance 802.11n 2.4 GHz and 802.11ac 5 GHz functionality, while also supporting 802.11a, b, and g wireless services. The AP works in conjunction with a controller.
The AP provides the following capabilities: n IEEE 802.11a, b, g, n, or ac operation as a wireless access point n n n n
IEEE 802.11a, b, g, n, or ac operation as a wireless air monitor
Compatible with IEEE 802.3af PoE and 802.3at PoE+
Centralized management configuration
Support for PoE-in (E0 port)/PoE-out (E3 port) n n
Support for selected USB peripherals
Integrated BLE radio
For technical specifications, see the AP-303H Access Point data sheet. For installation instructions, see the AP-303H Access Point Installation Guide .
20 | About this Guide ArubaOS 6.5.3.x | User Guide
Table 4: New Hardware Platforms in ArubaOS 6.5.2.0
Check with your local Aruba sales representative on new controllers and APs available in your country.
Hardware
360 Series Outdoor Access
Points
Description
The 360 Series (AP-365 and AP-367) outdoor APs support IEEE 802.11ac
standard for high performance WLAN, and are equipped with two radios, which provide network access and monitor the network simultaneously.
MIMO technology allows these APs to deliver high-performance 802.11n
2.4 GHz and 802.11ac 5 GHz functionality, while also supporting 802.11a, b, and g wireless services. The outdoor APs work in conjunction with a controller.
The outdoor APs provide the following capabilities: n n
IEEE 802.11a, b, g, n, or ac operation as a wireless access point
IEEE 802.11a, b, g, n, or ac operation as a wireless air monitor n n n n
IEEE 802.11a, b, g, n, or ac spectrum monitor
Compatible with IEEE 802.3af PoE
Centralized management configuration
Integrated BLE Radio
For technical specifications, see the 360 Series Outdoor Access Points data sheet. For installation instructions, see the 360 Series Outdoor Access
Points Installation Guide .
Features Introduced in ArubaOS 6.5.1.0
The following features are introduced in ArubaOS 6.5.1.0:
Table 5: New Features in ArubaOS 6.5.1.0
Feature
Description
Starting with ArubaOS 6.5.1.0, any-any selectors are negotiated in IKEv1 to enable the option of having numerous tunnels.
Starting with ArubaOS 6.5.1.0, use the branch office controller Smart
Config feature to enable or disable jumbo Ethernet frames on branch office controller ports.
Clarity Synthetic is supported for the following AP platforms: n AP-207 Series access point n n
300 Series access points
310 Series access points n n
320 Series access points
330 Series access points
Starting with ArubaOS 6.5.1.0, a new management role, Standard role, is supported which has all the root privileges but cannot make changes to the management users.
Starting with ArubaOS 6.5.1.0, Option-82 can be customized to cater to the requirements of any Internet Service Provider (ISP) using the Aruba controller. To facilitate customization using a XML definition, multiple parameters for Circuit ID and Remote ID options of DHCP Option-82 have been introduced.
ArubaOS 6.5.3.x
| User Guide About this Guide | 21
Table 5: New Features in ArubaOS 6.5.1.0
Feature Description
Starting with ArubaOS 6.5.1.0, the High Availability Alerting feature is introduced to enable the controller provide the high availability status information to customers.
High Availability on the Backup
Starting with ArubaOS 6.5.1.0, high availability is supported on the backup
LMS.
The Hotspot feature includes several enhancements.
n n
A new Hotspot 2.0 Query Protocol (H2QP)
defines the list of Online Sign-Up (OSU) providers to be sent in the
ANQP IE. If a customer device cannot find a service from a known operator, the device receives a notification from the hotspot that additional Online Signup services are available.
The
is enhanced to support a service provider's network QoS by
mapping the service provider's Layer-3 QoS priorities
(defined via DHCP ) to an over-the-air Layer 2 priority.
n n
The
is enhanced to send WNM notification requests to clients when the authentication server request it. Those WNM notification requests allow the hotspot feature to send clients the URLs of servers that allow the client to access information about how to
,
correct connection errors , or
.
The Hotspot 2.0 profile also allows network administrators to specify if the hotspot uses
an OSU Server-only authenticated layer 2 Encryption
. This network type is then dedicated to provisioning clients using the OSU functionality.
The users can now configure RADIUS modifier profile to customize the attributes that are included, excluded and modified in the RADIUS request before it is sent to the authentication server. The RADIUS modifier profile can be configured and applied to either Access- Request or Accounting-
Request or both on a RADIUS authentication server.
Frame drop counters are used by APs to track frame loss when sending/receiving data packets. The AP records when the frames are dropped and compiles the stats, allowing clients to monitor frame loss within individual queques.
Intelligent Power Monitoring (IPM) is a feature that actively measures the power utilization of an AP and dynamically adapts to the power resources.
Whenever a new client joins the network, a unicast or a multicast Router
Advertisements (RA) is sent to from the router to the client. If it is a multicast packet then existing clients also receive the RA, which results in increasing the traffic. Starting with ArubaOS 6.5.1.0, this issue is addressed by enabling IPv6 proxy RA to snoop incoming unsolicited Router
Advertisement and Router Solicitations packets.
When an AP identifies a device, randomized MAC addresses advertised by the device will be filtered from those associated with the network. The MAC address associated with the network will be displayed in the RSSI report, while the unassociated addresses are excluded.
Starting with ArubaOS 6.5.1.0, XLP-based controllers are supported with null encryption for IKEv1 as an encryption algorithm. This helps in reducing the load on the local router for internet destined traffic.
22 | About this Guide ArubaOS 6.5.3.x | User Guide
Table 5: New Features in ArubaOS 6.5.1.0
Feature
Description
QoS Enhancements
The PAPI Enhanced Security configuration provides protection to Aruba devices, AirWave, Mobility Access Switches, HP Switches, and ALE against malicious users sending fake messages that results in security challenges.
ArubaOS 6.5.1.0 introduces the following enhanced traffic QoS features: n
QoS for AP Management Traffic : Management traffic on the AP can now
be marked with Differentiated Service Code Point (DSCP) values in the
AP system profile, to apply a priority level to AP management traffic.
n n
DSCP to 802.1P mapping : The AP system profile is also enhanced to
map DSCP QoS priorities to 802.1p priorities at the AP's media access control (MAC) level.
Extensible Authentication Protocol (EAP) traffic can be assigned to a specific Wi-Fi Multimedia (WMM) traffic class via the AP's SSID profile by enabling the WMM Access Class of
EAP traffic parameter in the WLAN SSID profile. By default, EAP traffic is mapped to the default "best effort" traffic class.
The controllers perform load balancing of RADIUS accounting packets that are destined to external RADIUS Servers to ensure accounting load gets distributed.
ArubaOS 6.5.1.0 supports Spectrum Analysis on 300 Series access points.
New RADIUS VSAs are introduced to support the traffic steering and
Hotspot 2.0 features.
The ARM traffic steering feature encourages clients that support both Wi-Fi and 3G/4G cellular connections to move from a Wi-Fi connection to a cellular connection when the device moves out of a Wi-Fi coverage area, or when the Wi-Fi connection supports lower data rates than the cellular connection. ARM traffic steering prevents clients that have been disassociated from the network from reassociating for a customizable blackout interval. ARM traffic steering is disabled by default.
iOS mobile devices such as an iPhone, iPad, or iPod automatically blacklist an SSID if that device receives more than two deauthentication message within a five-minute period. To protect iOS devices from blacklisting an
SSID due to repeated traffic steering attempts, ArubaOS limits the number of traffic steering attempts for these devices to no more than one steering attempt every five minutes.
ArubaOS 6.5.1.0 supports WAN optimization through IP payload compression in 7205 controllers.
If one or more subscription WebCC licenses expire so that a controller has fewer active WebCC subscription licenses than AP licenses, that controller will no longer be able to download WebCC updates from the cloud or perform classification using cloud lookup.
ArubaOS 6.5.3.x
| User Guide About this Guide | 23
Table 6: New Hardware Platforms in ArubaOS 6.5.1.0
Hardware
AP-207 Series
Description
300 Series
APM-210
AP-207 Series access point supports IEEE 802.11ac standards for highperformance WLAN, and is equipped with a dual 2x2 radio. Multiple-Input
Multiple-Output (MIMO) technology allows the AP to deliver highperformance 802.11n 2.4 GHz and 802.11ac 5 GHz functionality, while also supporting 802.11a/b/g wireless services. AP-207 Series access point works in conjunction with a controller.
AP-207 Series access point provides the following capabilities: n Wireless transceiver n n n n n
IEEE 802.11a/b/g/n/ac operation as a wireless access point
IEEE 802.11a/b/g/n/ac operation as a wireless air monitor
Compatibility with IEEE 802.3af Power over Ethernet (PoE)
Centralized management configuration and upgrade
Integrated Bluetooth Low Energy (BLE) radio
For more information, see the AP-207 Series Access Points Installation
Guide .
The 300 Series (AP-304 and AP-305) access points support IEEE 802.11ac
standards for high-performance WLAN, and are equipped with a dual 2x2 radio on 2.4 GHz and 3x3 radio on 5 GHz, which provide network access and monitor the network simultaneously. These APs deliver highperformance 802.11n 2.4 GHz and 802.11ac 5 GHz functionality, while also supporting 802.11a/b/g wireless services. Multi-User Multiple-Input
Multiple-Output (MU-MIMO) is enabled when operating in 5 GHz mode for optimal performance. The 300 Series access points work in conjunction with a controller.
The 300 Series access points provide the following capabilities: n
IEEE 802.11a/b/g/n/ac operation as a wireless access point n n n n
IEEE 802.11a/b/g/n/ac operation as a wireless air monitor
IEEE 802.11a/b/g/n/ac spectrum monitor
Compatible with IEEE 802.3af PoE and IEEE 802.3at PoE+
Centralized management configuration and upgrade n Integrated BLE radio
For more information, see the 300 Series Access Points Installation Guide .
ArubaOS 6.5.1.0 introduces the support for the APM-210, a highperformance dual-radio 3x3:3 MIMO 802.11ac wireless Access Point
Module (APM).
This product enhances the Ericsson Pico Radio Base Station by enabling
Wi-Fi access as an add-on to indoor WCDMA or 3GPP cellular coverage.
24 | About this Guide ArubaOS 6.5.3.x | User Guide
Features Introduced in ArubaOS 6.5.0.0
The following features are introduced in ArubaOS 6.5.0.0:
Table 7: New Features in ArubaOS 6.5.0.0
Feature Description
App and App Category Visibility
Starting with ArubaOS 6.5.0.0, a Branch controller classifies traffic into multiple priorities and shapes the egress traffic to match the actual upstream bandwidth.
Starting with ArubaOS 6.5.0.0, the AppRF page in Dashboard has been renamed to Traffic Analysis .
Blocked Sessions is a newly added tab that displays WebCC and AppRF sessions which are blocked by ACL through system logging or on the WebUI interface.
The cellular handoff assist feature can help a dual-mode, 3G/4G-capable
Wi-Fi device such as an iPhone, iPad, or Android client at the edge of Wi-Fi network coverage switch from Wi-Fi to an alternate 3G/4G radio that provides better network access. This setting can now be applied to individual virtual APs via the wlan virtual-ap profile.
ArubaOS 6.5.0.0 introduces the following enhancements to the centralized licensing feature:
Support for the Web Content Classification (WebCC) license. This license is a subscription-based, per-AP license that supports web content classification features on an AP for the duration of the subscription period
(up to 10 years per license).
Support for multi-version licensing, which allows centralized licensing clients to run a different version of ArubaOS than the primary and backup licensing servers. If a license is introduced in a newer version of ArubaOS, the primary and backup licensing servers set can still distribute licenses to licensing clients running an older version of ArubaOS, even if the licensing client does not recognize the newer license type.
Support for multiple master/local domains; topologies where multiple master controllers have one or more attached local controllers.
Clarity Synthetic enables the controller to select and convert any 200
Series access point to client mode. The converted AP acts like a WiFi client and starts synthetic data transaction within the network to monitor and detect the network health.
Central or any other cloud solution can manage branch controllers, access points, user/device profiles, and/or services (UCC, AppRF, FW and so on) over ZTP or Activate server.
The OCSP configuration for VIA is simplified with four parameters removed: OCSP responder's URL for IKE, OCSP responder's CN for IKE,
OCSP responder's URL for EAP, OCSP responder's CN for EAP. New parameter to enable OCSP responder is added to the aaa authentication via connection-profile command and corresponding change in the WebUI is done.
Starting with ArubaOS 6.5.0.0, if the number of MAC addresses exceeds the maximum limit set for the port, you can configure appropriate options so that the new MAC entries are dropped and a warning message is logged in syslog. The values for level of security and auto-recovery interval (in seconds) can also be set.
ArubaOS 6.5.3.x
| User Guide About this Guide | 25
Table 7: New Features in ArubaOS 6.5.0.0
Feature Description
IP Classification Based Firewall
Remote Telnet or SSH Session from the Controller
ArubaOS 6.5.0.0 introduces the support for customizing authentication
Reply-Message to captive portal users in the log-in page for better user experience. The purpose behind the Reply-Message is to return appropriate information to the captive portal system.
A new parameter is introduced to use the host name of a device as the user name (instead of the MAC address) of the device when a client is authenticated by non-802.1X method of authentication.
A new command is introduced to provide an ability to lock down all console ports, for example, micro USB, mini USB on the controller to enable high level security.
This feature provides capability for ARM to move to another 80 MHz channel or downgrade to 40MHz dynamically.
A new parameter is introduced to enable PortFast/PortFast on Trunk to reduce the time taken for wired clients connected to an AP to detect the link before they send data traffic.
HP TPM based switches can now inter-operate with the Aruba controllers and create the IKE / IPSec tunnels.
ArubaOS supports the functionality where the non- Aruba devices can fragment the large IKE_AUTH packets using the standards described in the RFC 7383 – Internet Key Exchange Protocol Version 2 (IKEv2) message fragmentation when the Aruba device acts as a responder and not as an initiator.
This enhancement is introduced to resolve issues that occur with distributed channel/power algorithm, random channel assignment, and reduction in interference channel.
The IP-Classification Based Firewall has been introduced to block traffic sent or received from those IP addresses classified as malicious. It also helps in identifying the geographical location of the malicious IP address.
This features assists in monitoring bandwidth usage by clients/hosts with
IPv6 addresses, over radius protocol. This information is used for billing purpose.
This features allows Captive Portal whitelist to support IPv6 addresses for netdestination.
This feature enables an Aruba controller to act as an NTP server so that the devices that do not have access to internet can synchronize their clocks.
Starting with ArubaOS 6.5.0.0, the controller stores the consolidated APprovisioned information for all APs connected to the controller in a .txt file.
This information helps troubleshoot any AP that does not come UP after an upgrade from ArubaOS 6.5.0.0 to a later ArubaOS version.
Starting with ArubaOS 6.5.0.0, an administrator can initiate a remote telnet or SSH session from the controller to a remote host. The host can be a controller or a non-Aruba host.
26 | About this Guide ArubaOS 6.5.3.x | User Guide
Table 7: New Features in ArubaOS 6.5.0.0
Feature
Description
The secondary master controller feature in ArubaOS 6.5.0.0 provides seamless connectivity by allowing an access point to terminate on a secondary master controller in the event of the master controller failing.
Starting with ArubaOS 6.5.0.0, the smart config which is used to manage branch controllers has been enhanced to allow a vlan to get an IP address using DHCP. To configure the vlan the dhcp-client and dhcp-pool parameters are introduced in the User VLANs table.
Starting with ArubaOS 6.5.0.0, the ZTP feature is enhanced to support 16
VLANs (Static IP Management) per managed node as against just four in the earlier versions of ArubaOS.
This new feature allows controllers to accept the subnets published by VIA clients. This feature is disabled by default.
ArubaOS 6.5.0.0 supports Wi-Fi Calling in the controller. Wi-Fi calling service allows cellular users to make or receive calls using a Wi-Fi network instead of using the carrier’s cellular network.
ArubaOS 6.5.3.x
| User Guide About this Guide | 27
Table 8: New Hardware Platforms in ArubaOS 6.5.0.0
Hardware
7008
Description
310 Series
330 Series
The 7008 controller is a wireless LAN controller that connects, controls, and intelligently integrates wireless APs and Air Monitors into a wired LAN system. The 7008 controller includes the following specifications: n n
8 Ethernet ports
1 console port n n
1 USB 2.0 port
1 USB 3.0 port
This controller supports up to 16 APs and 1024 users.
The 310 Series (AP-314 and AP-315) wireless access points support IEEE
802.11ac standards for a high-performance WLAN. This device is equipped with two single-band radios that provide network access and monitor the network simultaneously. 310 Series access points deliver high-performance 802.11n 2.4 GHz and 802.11ac 5 GHz functionality, while also supporting 802.11a/b/g wireless services. Multi-User Multiple-
Input Multiple-Output (MU-MIMO) is enabled when operating in 5 GHz mode for optimal performance. The 310 Series wireless access points work in conjunction with a controller and provides the following capabilities: n n n
IEEE 802.11a/b/g/n/ac wireless access point
IEEE 802.11a/b/g/n/ac wireless air monitor
IEEE 802.11a/b/g/n/ac spectrum monitor n n n n
Compatible with IEEE 802.3at and 802.3af PoE
Support for MCS8 and MCS9
Centralized management, configuration, and upgrades
Integrated Bluetooth Low Energy (BLE) radio
For more information, see the 310 Series Wireless Access Point Installation
Guide .
The 330 Series (AP-334 and AP-335) wireless access points support IEEE
802.11ac standards for high-performance WLAN. This device is equipped with two dual-band radios, which provide network access and monitor the network simultaneously. This access point delivers high-performance
802.11n 2.4 GHz and 802.11ac 5 GHz functionality, while also supporting
802.11a/b/g wireless services. Multi-User Multiple-Input Multiple-Output
(MU-MIMO) is enabled when operating in 5 GHz mode for optimal performance. The 330 Series wireless access points work in conjunction with a controller.
The 330 Series wireless access points provides the following capabilities: n IEEE 802.11a/b/g/n/ac wireless access point n n n n n
IEEE 802.11a/b/g/n/ac wireless air monitor
IEEE 802.11a/b/g/n/ac spectrum monitor
Compatible with IEEE 802.3at power sources
Centralized management, configuration, and upgrades
Integrated Bluetooth Low Energy (BLE) radio
For more information, see the 330 Series Wireless Access Point Installation
Guide .
28 | About this Guide ArubaOS 6.5.3.x | User Guide
Table 9: Deprecated Hardware Platforms in ArubaOS 6.5.0.0
Hardware
Hardware Models Not Supported from
ArubaOS 6.5.0.0
120 Series
600 Series controllers
3000 Series controllers
M3 and 6000 controllers
AP-120, AP-121, AP-124, and AP-125 access points
620, 650, and 651 controllers
3200XM, 3400, and 3600 controllers
M3 and 6000 controllers
Last Supported Release
ArubaOS 6.4.4.x
ArubaOS 6.4.4.x
ArubaOS 6.4.4.x
ArubaOS 6.4.4.x
Fundamentals
Configure your controller and AP using either the Web User Interface (WebUI) or the Command Line Interface
(CLI).
WebUI
Each controller supports up to 320 simultaneous WebUI connections. The WebUI is accessible through a standard Web browser from a remote management console or workstation. The WebUI includes configuration wizards that walk you through easy-to-follow configuration tasks. The wizards are: n n n n n n
AP—basic AP configuration
Controller—basic controller configuration
Campus WLAN—create and configure new WLAN(s) associated with the “default” ap-group
Remote AP—basic Remote AP configuration
WIP—define Wireless Intrusion Protection (WIP) policy
AirWave—controllers running ArubaOS 6.3 and later can use the AirWave wizard to quickly and easily connect the controller to an AirWave server.
In addition to the wizards, the WebUI includes a dashboard that provides enhanced visibility into your wireless network’s performance and usage. This allows you to easily locate and diagnose WLAN issues. For details on the WebUI Dashboard, see
CLI
The CLI is a text-based interface accessible from a local console connected to the serial port on the controller or through a Telnet or Secure Shell (SSH) session.
By default, you can access the CLI from the serial port or from an SSH session. You must explicitly enable Telnet on your controller in order to access the CLI via a Telnet session.
When entering commands remember that: n n n n commands are not case sensitive the space bar or tab key completes your partial keyword the backspace key erases your entry one letter at a time the question mark ( ? ) lists available commands and options
Remote Telnet or SSH Session from the Controller
Starting from ArubaOS 6.5, an administrator can initiate a remote telnet or SSH session from the controller to a remote host. The host can be a controller or a non-Aruba host.
ArubaOS 6.5.3.x
| User Guide About this Guide | 29
This feature is supported from the SSH session of the controller.
To initiate a telnet session from the controller to a remote host:
1. Initiate an SSH session to the controller.
2. In the enable mode, execute the telnet <user> <remote-host> [<port-num>] command.
user : User name of the remote host.
remote-host : IPv4 or IPv6 address of the remote host.
port-num : Telnet port number of the remote host. This is an optional parameter.
3. Once successfully connected, the remote host prompts the credentials. Enter the remote host credentials.
To initiate an SSH session from the controller to a remote host:
1. Initiate an SSH session to the controller.
2. In the enable mode, execute the ssh <user-at-host> command.
user-at-host : Username and IPv4 or IPv6 address of the remote host in the user@host format.
Once successfully connected, the remote host prompts the credentials.
3. Enter the remote host credentials.
To end the remote host session, execute the exit command. The remote host displays the following message:
(remote-host) #exit
Connection closed by foreign host.
(host) #
Limitations
This feature has few limitations. They are: n n n
This feature is supported from the SSH session of the controller only.
There is an inactivity timeout for the CLI sessions. When an administrator initiates a remote session (inner) from the controller’s SSH session (outer), and the remote session takes more time than the inactivity timeout session, the outer session times out although the inner session is active. The administrator has to log back in to the outer session once logged off from the inner session.
Designated telnet client control keys do not work for remote telnet sessions. When an administrator initiates a remote telnet session (inner) from the controller’s SSH session (outer), the designated telnet client control keys functions for the outer SSH session only. The administrator should designate unique control keys for each remote telnet sessions.
n n n n n n
Related Documents
The following guides are part of the complete documentation for the Aruba user-centric network:
Aruba Controller Installation Guides
Aruba Access Point Installation Guides
ArubaOS Quick Start Guide
ArubaOS User Guide
ArubaOS CLI Reference Guide
ArubaOS Release Notes
30 | About this Guide ArubaOS 6.5.3.x | User Guide
Conventions
The following conventions are used throughout this document to emphasize important concepts:
Table 10: Typographical Conventions
Type Style italics
Description system items commands
<arguments>
[optional]
This style is used to emphasize important terms and to mark the titles of books.
This fixed-width font depicts the following: n Sample screen output n n
System prompts
Filenames, software devices, and specific commands when mentioned in the text
In the command examples, this bold font depicts text that you must type exactly as shown.
In the command examples, italicized text within angle brackets represents items that you should replace with information appropriate to your specific situation. For example:
# send < text message >
In this example, you would type “send” at the system prompt exactly as shown, followed by the text of the message you wish to send. Do not type the angle brackets.
Command examples enclosed in brackets are optional. Do not type the brackets.
{Item A | Item
B}
In the command examples, items within curled braces and separated by a vertical bar represent the available choices. Enter only one choice. Do not type the braces or bars.
The following informational icons are used throughout this guide:
Indicates helpful suggestions, pertinent information, and important things to remember.
Indicates a risk of damage to your hardware or loss of data.
Indicates a risk of personal injury or death.
ArubaOS 6.5.3.x
| User Guide About this Guide | 31
Contacting Support
Table 11: Contact Information
Main Site
Support Site
Airheads Social Forums and Knowledge
Base
North American Telephone
International Telephone
Software Licensing Site
End-of-life Information
Security Incident Response Team arubanetworks.com
support.arubanetworks.com
community.arubanetworks.com
1-800-943-4526 (Toll Free)
1-408-754-1200 arubanetworks.com/support-services/contact-support/ hpe.com/networking/support arubanetworks.com/support-services/end-of-life/
Site: arubanetworks.com/support-services/security-bulletins/
Email: [email protected]
32 | About this Guide ArubaOS 6.5.3.x | User Guide
Chapter 1
The Basic User-Centric Networks
This chapter describes how to connect an Aruba controller and Aruba AP to your wired network. After completing the tasks described in this chapter, see
for information on configuring
APs.
This chapter describes the following topics: n n n n n n n n n
Understanding Basic Deployment and Configuration Tasks on page 33
Controller Configuration Workflow on page 36
Connect the Controller to the Network on page 37
7000 Series and 7200 Series Controllers on page 38
Using the LCD Screen on page 40
Configuring a VLAN to Connect to the Network on page 43
Enabling Wireless Connectivity on page 47
Configuring Your User-Centric Network on page 47
Replacing a Controller on page 47
Understanding Basic Deployment and Configuration Tasks
This section describes typical deployment scenarios and the tasks you must perform while connecting to a
Aruba controller and Aruba AP to your wired network. For details on performing the tasks mentioned in these scenarios, refer to the other procedures within the Basic User-Centric Networks section of this document.
Deployment Scenario #1: Controller and APs on Same Subnet
Figure 1 Controller and APs on Same Subnet
In this deployment scenario, the APs and controller are on the same subnetwork and will use IP addresses assigned to the subnetwork. The router is the default gateway for the controller and clients.There are no routers between the APs and the controller. APs can be physically connected directly to the controller. The uplink port on the controller is connected to a layer-2 switch or router.
For this scenario, you must perform the following tasks:
1. Run the initial setup wizard.
n n
Set the IP address of VLAN 1.
Set the default gateway to the IP address of the interface of the upstream router to which you will connect the controller.
ArubaOS 6.5.3.x
| User Guide The Basic User-Centric Networks | 33
2. Connect the uplink port on the controller to the switch or router interface. By default, all ports on the controller are access ports and will carry traffic for a single VLAN.
3. Deploy APs. The APs will use the Aruba Discovery Protocol (ADP) to locate the controller.
4. Configure the SSID(s) with VLAN 1 as the assigned VLAN for all users.
Deployment Scenario #2: APs All on One Subnet Different from Controller Subnet
Figure 2 APs All on One Subnet Different from Controller Subnets
In this deployment scenario, the APs and the controller are on different subnetworks and the APs are on multiple subnetworks. The controller acts as a router for the wireless subnetworks (the controller is the default gateway for the wireless clients). The uplink port on the controller is connected to a layer-2 switch or router; this port is an access port in VLAN 1.
For this scenario, you must perform the following tasks:
1. Run the initial setup wizard.
n
Set the IP address for VLAN 1.
34 | The Basic User-Centric Networks ArubaOS 6.5.3.x | User Guide
n
Set the default gateway to the IP address of the interface of the upstream router to which you will connect the controller.
2. Connect the uplink port on the controller to the switch or router interface.
3. Deploy APs. The APs will use DNS or DHCP to locate the controller.
4. Configure VLANs for the wireless subnetworks on the controller.
5. Configure SSIDs with the VLANs assigned for each wireless subnetwork.
Each wireless client VLAN must be configured on the controller with an IP address. On the uplink switch or router, you must configure static routes for each client VLAN, with the controller’s VLAN 1 IP address as the next hop.
Deployment Scenario #3: APs on Multiple Different Subnets from Controllers
Figure 3 APs on Multiple Different Subnets from Controllers
In this deployment scenario, the APs and the controller are on different subnetworks and the APs are on multiple subnetworks. There are routers between the APs and the controller. The controller is connected to a
ArubaOS 6.5.3.x
| User Guide The Basic User-Centric Networks | 35
layer-2 switch or router through a trunk port that carries traffic for all wireless client VLANs. An upstream router functions as the default gateway for the wireless users.
This deployment scenario does not use VLAN 1 to connect to the layer-2 switch or router through the trunk port. The initial setup prompts you for the IP address and default gateway for VLAN 1; use the default values. In later steps, you configure the appropriate VLAN to connect to the switch or router as well as the default gateway.
For this scenario, you must perform the following tasks:
1. Run the initial setup.
n
Use the default IP address for VLAN 1. Since VLAN 1 is not used to connect to the layer-2 switch or router through the trunk port, you must configure the appropriate VLAN in a later step.
n
Do not specify a default gateway (use the default “none”). In a later step, you configure the default gateway.
2. Create a VLAN that has the same VLAN ID as the VLAN on the switch or router to which you will connect the controller. Add the uplink port on the controller to this VLAN and configure the port as a trunk port.
3. Add client VLANs to the trunk port.
4. Configure the default gateway on the controller. This gateway is the IP address of the router to which you will connect the controller.
5. Configure the loopback interface for the controller.
6. Connect the uplink port on the controller to the switch or router interface.
7. Deploy APs. The APs will use DNS or DHCP to locate the controller.
8. Now configure VLANs on the controller for the wireless client subnetworks and configure SSIDs with the
VLANs assigned for each wireless subnetwork.
Controller Configuration Workflow
The tasks in deploying a basic user-centric network fall into two main areas: n n
Configuring and connecting the controller to the wired network (described in this section)
Deploying APs (described later in this section)
The following workflow lists the tasks to configure an Aruba controller. Click any of the links below for details on the configuration procedures for that task.
1. Connect the controller to the network.
2. Set the system clock. For more information, see
Setting the System Clock on page 897 .
3. View current licenses installed on the controller. For more information, see
Installing a License on page 90
.
4. For topologies similar to deploying access points on multiple different subnets from controllers, see
Deployment Scenario #3: APs on Multiple Different Subnets from Controllers on page 35
5. Configure a VLAN to the controller to your network. For more information see,
not need to perform this step if you are using VLAN 1 to connect the controller to the wired network.sasds.
6. The Controller IP address is used by the controller to communicate with external devices such as APs. For more information, see
Configuring the Controller IP Address on page 113
. Optionally, you can configure a loopback address for the controller. For more information, see
Configuring the Loopback IP Address on page 112 . You do
not need to perform this step if you are using the VLAN 1 IP address as the controller’s IP address. Disable spanning tree on the controller if necessary.
7. Specify additional connectivity parameters for the controller to configure a trunk port between the controller and another layer-2 switch as shown in
Deployment Scenario #3: APs on Multiple Different
36 | The Basic User-Centric Networks ArubaOS 6.5.3.x | User Guide
Subnets from Controllers on page 35
For more information, see
Configuring a VLAN to Connect to the
have the redundant cellular link.
8. Configure ports for the controller. For more information, see
.
Connect the Controller to the Network
To connect the controller to the wired network, run the initial setup to configure administrative information for the controller.
Initial setup can be done using the browser-based Setup Wizard or by accessing the initial setup dialog via a serial port connection. Both methods are described in the ArubaOS Quick Start Guide and are referred to throughout this chapter as “initial setup.”
This section describes the steps in detail.
Running Initial Setup
Connecting to the Controller After Initial Setup
After you complete the initial setup, the controller reboots using the new configuration. (See the
ArubaOS
n
for information on how to access the CLI and enter configuration commands.)
You can connect an Ethernet cable from a PC to an Ethernet port on the controller. You can then use one of the following access methods: l l
Use the VLAN 1 IP address to start an SSH session where you can enter CLI commands.
Enter the VLAN 1 IP address in a browser window to start the WebUI.
ArubaOS 6.5.3.x
| User Guide The Basic User-Centric Networks | 37
l
WebUI Wizards.
This chapter and the user guide in general focus on CLI and standard WebUI configuration examples. However, basic controller configuration and WLAN/LAN creation can be completed using the alternative wizards from within the
WebUI. If you wish to use a configuration wizard, navigate to Configuration > Wizards , click on the desired wizard, and follow the imbedded help instructions within the wizard.
7000 Series and 7200 Series Controllers
The 7000 Series and 7200 Series controllers are new controller platforms introduced in conjunction with
ArubaOS 6.4.x and 6.2, respectively. These controllers provide new functionality and improved capabilities over previous controllers. However, a 7000 Series and 7200 Series controller also introduces some changes that you must keep in mind when adding it to your network.
New Port Numbering Scheme
The 7000 Series and 7200 Series controllers use a different port numbering scheme than older model controllers. All other controller platforms use a slot/port numbering scheme. Both the 7000 Series and 7200
Series controllers use slot/module/port instead.
It is important to consider this when migrating an older controller to either the 7000 Series or 7200 Series. If you load a configuration from a controller, that controller will not have network connectivity because any interface configuration will not be recognized. For information about migrating to 7000 Series and 7200 Series controllers, see the ArubaOS 6.2 Release Notes or visit support.arubanetworks.com
.
7200 Series Controllers Individual Port Behavior
The first two ports on the 7200 Series controllers, 0/0/0 and 0/0/1 are dual media ports and can be used for any purpose. Ports 0/0/2 through 0/0/5 are fiber-based ports that can be used for any purpose. If the fiberbased ports are connected with RJ45 or Small Form-factor Pluggable (SFP) transceivers, these ports can function as 1 GBps ports. For accessing the controller, port 0/0/0 to 0/0/5 can be used when 0/0/2 through
0/0/5 are connected with RJ45 or SFP transceivers.
The following table describes the connector and speed supported for each physical interfaces of the 7200
Series controllers.
Table 12: 7200 Series Controllers Ports
Port Type Ports
10/100/1000 BASE-T Dual Media
Ports
0/0/0-0/0/1
Connector Type
RJ45 or SFP
Speed
1 GBps
10G BASE-X 0/0/2-0/0/5
SFP+
RJ45 or SFP
10 GBps
1 GBps
Controller Port-Security MAC Address Limitation
Starting from ArubaOS 6.5, the MAC address limitation, a port-security feature, is enhanced for the 7000 Series and 7200 Series Controllers. You can enable or disable this functionality using the WebUI or the CLI.
In earlier versions of ArubaOS, the option to configure the maximum number of MAC addresses that a port can support is available. The enhancement to this MAC address limitation feature in this release of ArubaOS is that if the number of MAC addresses exceeds the maximum limit set for the port, the new MAC entries are dropped.
38 | The Basic User-Centric Networks ArubaOS 6.5.3.x | User Guide
The switchport port-security command is enhanced to include parameters for setting the levels of security and autorecovery interval time. You can set appropriate values for the level parameter to log a warning message Max bridge entries limit hit on the port # in syslog and/or to shut down the port. For level , the default value is logging.
When a port-security error occurs, the controller shuts down the port so that no traffic is received by the controller on this port. You can use the clear command to resolve the port-security error and bring UP the port.
In the WebUI
To configure the maximum number of MAC addresses for a port, perform the following steps:
1. Navigate to Configuration > NETWORK > Ports .
2. Under the Port Selection group, select a port.
3. Under the Configure Selected Port <slot/module/port> group box, enter a value for the Maximum number of mac address text box. The range of value you can configure for this option must be between
1 and 16,384.
4. Click Apply .
In the CLI
To enable the port-security feature on the controller, execute the following command:
(host) (config) #interface gigabitethernet 0/0/0
(host) (config-if) #switchport port-security maximum <num> where
<num> represents the maximum MAC address range for the port. You can set a value from 1 to 16,384.
You can set the level of security and autorecovery interval using the level and interval parameters, respectively.
(host) (config-if)#switchport port-security maximum 25 level ?
drop The packet will be dropped on crossing the limit logging The packet will be dropped and a message will be logged shutdown The packet will be dropped, message will be logged and the port will be shutdown
(host) (config-if)#switchport port-security maximum 25 level shutdown interval ?
<seconds> Time in seconds. Supported range (1-65535)
The sample command to set the values for maximum MAC addresses, levels of security for packet handling, and the autorecovery interval time is as follows:
(host) (config-if) #switchport port-security maximum 20 level shutdown interval 100
The level of security can be set to drop, logging, or shutdown. The default value for level is logging. The autorecovery interval time (in seconds) to clear the port error must be in the range of 1-65,535.
To disable this port-security feature on the controller, execute the following command:
(host) (config) #interface gigabitethernet 0/0/0
(host) (config-if) #no switchport port-security maximum
To display any port-security error, execute the following command:
(host) #show port status
Port Status
-----------
Slot-Port PortType AdminState OperState PoE Trusted SpanningTree
----------------------------------------------------
0/0/0 GE Enabled Up N/A Yes Forwarding
0/0/1
0/0/2
0/0/3
GE
GE
GE
Enabled
Enabled
Enabled
Down
Down
Down
N/A
N/A
N/A
Yes
Yes
Yes
Disabled
Disabled
Disabled
ArubaOS 6.5.3.x
| User Guide The Basic User-Centric Networks | 39
0/0/4
0/0/5
GE
GE
Enabled
Enabled
Down
Down
N/A Yes
N/A Yes
Disabled
Disabled
PortMode Speed Duplex SecurityError
-------- ----------------------
Access
Access
1 Gbps
Auto
Full
Auto
No
No
Access
Access
Auto
Auto
Auto
Auto
No
No
Access Auto
Access Auto
Auto
Auto
No
No
The SecurityError column in the output displays the error corresponding to the port.
To clear off the port-security error before bringing the port UP, execute the following command:
(host) #clear port-security-error gigabitethernet 0/0/0
Supported Combinations of the Aruba 7000 Series Controllers
A small 7000 Series controllers deployment with controller redundancy can be configured as a single master/single local, master/master-backup/multiple local controllers for very small AP clusters/deployments
(256 APs and under). If the APs managed by a 7000 Series master controller exceeds 256 APs, a 7200 Series controller must be used. In no instance can a 7000 Series controller act as a master for any 7200 Series controller, regardless of total AP count.
Supported Configurations n n n n n n
7005— master/local only up to 16 APs maximum within the master cluster.
7005— master+master-backup and up to 8 local controllers (7005, 7008, and 7010 controllers only) up to
64 APs maximum within the master cluster.
7008— master/local only up to 16 APs maximum within the master cluster.
7008— master+master-backup and up to 16 local controllers (7005, 7008, and 7010 controllers only) up to
64 APs maximum within the master cluster.
7024— master+master-backup and up to 8 local controllers (7005, 7010, and 7024 controllers) up to 64
APs maximum within the master cluster.
7030— master+master-backup and up to 32 local controllers (any 7000 Series controller) up to 256 APs maximum within the master cluster.
Using the LCD Screen
Some controllers are equipped with an LCD panel that displays a variety of information about the controller’s status and provides a menu that allows for basic operations such as initial setup and reboot. The LCD panel displays two lines of text with a maximum of 16 characters on each line. When using the LCD panel, the active line is indicated by an arrow next to the first letter.
The LCD panel is operated using the two navigation buttons to the left of the screen.
n n
Menu: Allows you to navigate through the menus of the LCD panel.
Enter: Confirms and executes the action currently displayed on the LCD panel.
The LCD has four modes: n n n
Boot: Displays the boot up status.
LED Mode: Displays the mode that the STATUS LED is in.
Status: Displays the status of different components of the controller, including Power Supplies and
ArubaOS version.
40 | The Basic User-Centric Networks ArubaOS 6.5.3.x | User Guide
n
Maintenance: Allows you to execute some basic operations of the controller such as uploading an image or rebooting the system.
Table 13: LCD Panel Mode: Boot
Function/Menu Options Displays
Displays boot status "Booting ArubaOS...
Table 14: LCD Panel Mode: LED Mode
Function/Menu Options Displays
Administrative LED MODE: ADM - displays whether the port is administratively enabled or disabled.
Duplex LED MODE: DPX - displays the duplex mode of the port.
Speed
Exit Idle Mode
LED MODE: SPD - displays the speed of the port.
EXIT IDLE MENU
Table 15: LCD Panel Mode: Status
Function/Menu Options Display Output
ArubaOS
PSU
Version ArubaOS X.X.X.X
Status Displays status of the power supply unit.
PSU 0: [OK | FAILED | MISSING]
PSU 1: [OK | FAILED | MISSING]
Fan Tray
Exit Status Menu
Displays fan tray status.
FAN STATUS: [OK | ERROR | MISSING]
FAN TEMP: [OK | HIGH | SHUTDOWN]
EXIT STATUS
Table 16: LCD Panel Mode: Maintenance
Function/Menu Options Display Output
Upgrade Image
Upload Config
Factory Default
Upgrade the software image on the selected partition from a predefined location on the attached USB flash device.
Partition [0 | 1] Upgrade Image [no | yes]
Uploads the controller’s current configuration to a predefined location on the attached USB flash device.
Upload Config [no | yes]
Allows you to return the controller to the factory default settings.
Factory Default [no | yes]
ArubaOS 6.5.3.x
| User Guide The Basic User-Centric Networks | 41
Function/Menu Options Display Output
Media Eject
System Reboot
System Halt
Exit Maintenance Menu
Completes the reading or writing of the attached USB device.
Media Eject [no | yes]
Allows you to reboot the controller.
Reboot [no | yes]
Allows you to halt the controller.
Halt [no | yes]
EXIT MAINTENANCE
Using the LCD and USB Drive
You can upgrade your image or upload a saved configuration by using your USB drive and your LCD commands.
For more information on copying and transferring ArubaOS image and configuration files, see
Upgrading an Image
1. Copy a new controller image onto your USB drive into a directory named /Arubaimage .
2. Insert your USB drive into the controller’s USB slot. Wait for 30 seconds for the controller to mount the
USB.
3. Navigate to Upgrade Image in the LCD’s Maintenance menu. Select a partition and confirm the upgrade
(Y/N) and then wait for controller to copy the image from the USB drive to the system partition.
4. Execute a system reboot either from the LCD menu or from the command line to complete the upgrade.
Uploading a Saved Configuration
1. Make a copy of a controllerconfiguration (with the .cfg file extension), and save the copied file with the name Aruba_usb.cfg
.
2. Move the saved configuration file onto your USB drive into a directory named /Arubaimage .
3. Insert your USB drive into the controller’s USB slot. Wait for 30 seconds for the controller to mount the
USB.
4. Navigate to Upload Config in the LCD’s Maintenance menu. Confirm the upload (Y/N) and then wait for the upload to complete.
5. Execute a system reboot either from the LCD menu or from the command line to reload from the uploaded configuration.
For detailed upgrade and instruction, see the Upgrade chapter in the Release Notes.
Disabling LCD Menu Functions
For security purposes, you can disable all LCD menu functions by disabling the entire menu functionality using the following commands:
(host) (config) #lcd-menu
(host) (lcd-menu) #disable menu
42 | The Basic User-Centric Networks ArubaOS 6.5.3.x | User Guide
To prevent inadvertent menu changes, you can disable individual LCD menu functions using the following commands:
(host) (lcd-menu) #disable menu maintenance ?
factory-default Disable factory default menu media-eject Disable media eject menu on LCD system-halt Disable system halt menu on LCD system-reboot Disable system reboot menu on LCD upgrade-image Disable image upgrade menu on LCD upload-config Disable config upload menu on LCD
To display the current LCD functionality from the command line, use the following command:
(host) (config) #show lcd-menu
Configuring a VLAN to Connect to the Network
You must follow the instructions in this section only if you need to configure a trunk port between the controller and another layer-2 switch (shown in
Deployment Scenario #3: APs on Multiple Different Subnets from Controllers on page 35
).
This section shows how to use both the WebUI and CLI for the following configurations (subsequent steps show how to use the WebUI only): n n
Create a VLAN on the controller and assign it an IP address.
Optionally, create a VLAN pool. A VLAN pool consists of two more VLAN IDs which are grouped together to efficiently manage multi-controller networks from a single location. For example, policies and virtual application configurations map users to different VLANs which may exist at different controllers. This creates redundancy where one controller has to back up many other controllers. With the VLAN pool feature you can control your configuration globally.
VLAN pooling should not be used with static IP addresses.
n n n
Assign to the VLAN the ports that you will use to connect the controller to the network. (For example, the uplink ports connected to a router are usually Gigabit ports.) In the example configurations shown in this section, a controller is connected to the network through its Gigabit Ethernet port 1/25.
Configure the port as a trunk port.
Configure a default gateway for the controller.
Creating, Updating, and Viewing VLANs and Associated IDs
You can create and update a single VLAN or bulk VLANS using the WebUI or the CLI. See
.
In the WebUI configuration windows, clicking the Save Configuration button saves configuration changes so they are retained after the controller is rebooted. Clicking the Apply button saves changes to the running configuration but the changes are not retained when the controller is rebooted. A good practice is to use the Apply button to save changes to the running configuration and, after ensuring that the system operates as desired, click Save
Configuration .
You can view VLAN IDs in the CLI.
(host) #show vlan
ArubaOS 6.5.3.x
| User Guide The Basic User-Centric Networks | 43
Creating, Updating, and Deleting VLAN Pools
VLAN pooling should not be used with static IP addresses.
You can create, update, and delete a VLAN pool using the WebUI or the CLI. See
Creating a Named VLAN on page 106
.
Use the CLI to add existing VLAN IDS to a pool.
(host) (config) #vlan-name <name>
(host) (config) #vlan mygroup <vlan-IDs>
To confirm the VLAN pool status and mappings assignments, use the show vlan mapping command:
(host) #show vlan mapping
Assigning and Configuring the Trunk Port
The following procedures configures a Gigabit Ethernet port as trunk port.
In the WebUI
To configure a Gigabit Ethernet port:
1. Navigate to Configuration > Network > Ports .
2. In the Port Selection section, click the port that will connect the controller to the network. In this example, click port 25.
3. For Port Mode, select Trunk .
4. For Native VLAN, select a VLAN from the scrolling list, then click the left (<--) arrow.
5. Click Apply .
In the CLI
To configure a Gigabit Ethernet port:
(host)(config) #interface gigabitethernet <slot>/<module>/<port>
(host)(config-if) #switchport mode trunk
(host)(config-if) #switchport trunk native vlan <id>
To confirm the port assignments, use the show vlan command:
(host) (config) #show vlan
Configuring the Default Gateway
The following configurations assign a default gateway for the controller.
In the WebUI
To configure the default gateway:
1. Navigate to Configuration > Network > IP > IP Routes .
2. To add a new static gateway, click the Add button below the static IP address list.
a. In the IP Address field, enter an IP address in dotted-decimal format.
b. In the Cost field, enter a value for the path cost.
c. Click Add .
3. You can define a dynamic gateway using DHCP, PPPOE or a cell uplink interface. In the Dynamic section, click the DHCP , PPPoE or Cellular checkboxes to select one or more dynamic gateway options. If you select more than one dynamic gateway type, you must also define a cost for the route to each gateway. The
44 | The Basic User-Centric Networks ArubaOS 6.5.3.x | User Guide
controller will first attempt to obtain a gateway IP address using the option with the lowest cost. If the controller is unable to obtain a gateway IP address, it will then attempt to obtain a gateway IP address using the option with the next-lowest path cost.
4. Click Apply .
In the CLI
To configure the default gateway: ip default-gateway <ipaddr>|{import cell|dhcp|pppoe}|{ipsec <name>} <cost>
Configuring the Loopback IP Address for the Controller
You must configure a loopback address if you are not using a VLAN ID address to connect the controller to the network (see
Deployment Scenario #3: APs on Multiple Different Subnets from Controllers on page 35 ).
After you configure or modify a loopback address, you must reboot the controller.
If configured, the loopback address is used as the controller’s IP address. If you do not configure a loopback address for the controller, the IP address assigned to the first configured VLAN interface IP address. Generally,
VLAN 1 is configured first and is used as the controller’s IP address.
ArubaOS allows the loopback address to be part of the IP address space assigned to a VLAN interface. In the example topology, the VLAN 5 interface on the controller was previously configured with the IP address
10.3.22.20/24. The loopback IP address in this example is 10.3.22.220.
You configure the loopback address as a host address with a 32-bit netmask. The loopback address should be routable from all external networks.
Spanning tree protocol (STP) is enabled by default on the controller. STP ensures a single active path between any two network nodes, thus avoiding bridge loops. Disable STP on the controller if you are not employing STP in your network.
In the WebUI
To configure a loopback IP address:
1. Navigate to Configuration > Network > Controller > System Settings .
2. Enter the IP address under Loopback Interface.
3. On this window, you can also turn off spanning tree. Click No for Spanning Tree Enabled.
4. Click Apply at the bottom of the window (you might need to scroll down the window).
5. At the top of the window, click Save Configuration .
You must reboot the controller for the new IP address to take effect.
6. Navigate to the Maintenance > Controller > Reboot Controller window.
7. Click Continue .
In the CLI
To configure a loopback IP address:
(host)(config) #interface loopback ip address <A.B.C.D>
(host)(config) #no spanning-tree
ArubaOS 6.5.3.x
| User Guide The Basic User-Centric Networks | 45
(host)(config) #write memory
(host)(config) #reload
The controller returns the following messages:
Do you really want to reset the system(y/n):
Enter y to reboot the controller or n to cancel.
System will now restart!
...
Restarting system.
To verify that the controller is accessible on the network, ping the loopback address from a workstation on the network.
Configuring the System Clock
You can manually set the clock on the controller, or configure the controller to use a Network Time Protocol
(NTP) server to synchronize its system clock with a central time source. For more information about setting the controller’s clock, see
Setting the System Clock on page 897
.
Installing Licenses
ArubaOS consists of a base operating system with optional software modules that you can activate by installing license keys. If you use the Setup Wizard during the initial setup phase, you will have the opportunity to install software licenses at that time. Refer to
for detailed information on
Licenses.
Connecting the Controller to the Network
Connect the ports on the controller to the appropriately-configured ports on an L2 switch or router. Make sure that you have the correct cables and that the port LEDs indicate proper connections. Refer to the Installation
Guide for the controller for port LED and cable descriptions.
In many deployment scenarios, an external firewall is situated between various Aruba devices.
describes the network ports that must be configured on the external firewall to allow proper operation of the network.
To verify that the controller is accessible on the network: n n
Subnet Different from Controller Subnet on page 34
and
Deployment Scenario #3: APs on Multiple
network.
If you created and configured a new VLAN (
Enabling Wireless Connectivity
Wireless users can connect to the SSID but because you have not yet configured authentication, policies, or user roles, they will not have access to the network. Other chapters in the ArubaOS User Guide describe how to build upon this basic deployment to configure user roles, firewall policies, authentication, authentication servers, and other wireless features.
46 | The Basic User-Centric Networks ArubaOS 6.5.3.x | User Guide
Enabling Wireless Connectivity
Wireless users can connect to the SSID but because you have not yet configured authentication, policies, or user roles, they will not have access to the network. Other chapters in the ArubaOS User Guide describe how to build upon this basic deployment to configure user roles, firewall policies, authentication, authentication servers, and other wireless features.
n
Configuring Your User-Centric Network
Configuring your controller and AP is done through either the Web User Interface (WebUI) or the command line interface (CLI).
WebUI is accessible through a standard Web browser from a remote management console or workstation.
The WebUI includes configuration wizards that step you through easy-to-follow configuration tasks. Each wizard has embedded online help. The wizards are: l l
AP Wizard—basic AP configurations including LAN, Remote, LAN Mesh and Remote Mesh deployment scenarios
Controller Wizard—basic controller configuration including system settings, Control Plane security, cluster settings and licenses l l
WLAN/LAN Wizard—creating and configuring new WLANs and LANs associated with the “default” apgroup. Includes campus only and remote networking.
License Wizard—installation and activation of software licenses (see
Software Licenses on page 78 )
Clicking Cancel from the Wizards return you to where you launched the wizard. Any configuration changes you entered are not saved.
n
The command line interface (CLI) allows you to configure and manage controllers. The CLI is accessible from a local console connected to the serial port on the controller or through a Telnet or Secure Shell (SSH) session from a remote management console or workstation.
By default, you can only access the CLI from the serial port or from an SSH session. To use the CLI in a Telnet session, you must explicitly enable Telnet on the controller.
Replacing a Controller
The procedures below describe the steps to replace an existing standalone master controller and/or a redundant master controller. Best practices are to replace the backup master controller first, and replace the active master controller only after the new backup controller is operational on the network. When you remove the active controller from the network to replace it, the new backup controller takes over the active controller role. When you add a second controller to the network, that second controller automatically assumes the role of a backup controller.
This procedure assumes that the existing controllers have been upgraded to ArubaOS 6.2.x or later. If your controllers are running earlier version of ArubaOS, upgrade them to 6.2.x or later before attempting to migrate them to a newer controller model, such as a 7000 Series or 7200 Series controller.
Transferring Licenses
To replace a controller with manually added licenses, you will need to transfer those licenses to the new controller as part of the replacement process.
ArubaOS 6.5.3.x
| User Guide The Basic User-Centric Networks | 47
If the controller being replaced was returned to Aruba as an RMA, the license keys on the RMA controller cannot be directly transferred to a new device, and must be regenerated. To generate a new license key for a controller returned as an RMA:
1. Access the My Networking Portal (MNP) at http://hpe.com/networking/mynetworking/ .
2. Log in to MNP using the HPE Passport.
3. Click View licenses or Transfer licenses to new platform . All available licenses are displayed.
4. Select the >> icon at the right end of the record to verify the license details before transferring it.
5. Click Transfer License at the bottom of the page.
6. Select a controller from the AOS Controller Type drop-down list.
7. Enter the serial number of the controller in the Serial number text box; or enter the passphrase of the controller in the PassPhrase text box.
8. Select the license to be transferred.
9. Click Transfer at the bottom of the page. A new license key is generated, which you can apply to the controller.
Procedure Overview
The procedure to replace a backup or active master controller is comprised of the following tasks:
1.
Change the VRRP Priorities for a Redundant Master Pair on page 48
2.
Back Up the Flash File System on page 48
3.
Stage the New Controller on page 49
4.
Add Licenses to the New Controller on page 50
5.
Backup Newly Installed Licenses on page 50
6.
Import and Restore Flash Backup on page 50
7.
8.
Reboot the Controller on page 51
9.
Modify the Host Name on page 51
10.
Modify Topology Settings on page 52
11.
Save your Configuration on page 53
12.
Remove the Existing Controller on page 53
If your controller does not have any manually added licenses, skip steps 3, 4 and 6 of the following procedure.
Change the VRRP Priorities for a Redundant Master Pair
If your deployment uses VRRP to define the primary master in a pair of redundant master controllers, and you are replacing only the primary master controller, and you must change the VRRP priority levels of the controllers so the primary master controller has a lower priority than the backup master controller. This will allow the configuration from the backup master to be copied to the new master controller, and prevent an old or inaccurate configuration from being pushed to the local controllers.
For details on changing VRRP priorities, see
Configuring VRRP Redundancy on page 648
.
Back Up the Flash File System
To start the migration process, access the backup or master controller being replaced and create a backup of the flash file system. You can create a backup file using the WebUI or command-line interfaces.
48 | The Basic User-Centric Networks ArubaOS 6.5.3.x | User Guide
In the WebUI
To back up the flash from the WebUI, log in to the current backup or master controller and create a flash backup using the procedure below.
1. Navigate to Maintenance > File >Backup Flash .
2. Select Create Backup .
3. Select Copy Backup to create a copy of the backup file. By default, the flash backup file is named flashbackup.tar.gz
.
4. Next, move the backup the flash file system to an external server. Navigate to Maintenance>Copy Files .
5. In the Source Selection section, select Flash File System .
6. In the Destination Selection section, select one of the server options to move the flash backup off the controller, and enter the name of the flash backup file to be exported.
In the CLI
To create a flash backup from the command-line interface, access the active master controller and issue the backup flash command, as shown in the example below.
(host) #backup flash
Please wait while we tar relevant files from flash...
Please wait while we compress the tar file...
File flashbackup.tar.gz created successfully on flash.
Please copy it out of the switch and delete it when done.
(active_host) #dir
-rw-r--r-drwxr-xr-x
1 root
4 root root root
17338 Dec
1024 Dec
6 08:34 default.cfg
6 08:34 fieldCerts
-rw-r--r-drwx------
1 root
2 root root root
21760 Dec
1024 Dec
6 09:29 flashbackup.tar.gz
5 08:20 tpm
(host) #copy flash: flashbackup.tar.gz tftp: <your TFTP server IP> flashbackup.tar.gz
Stage the New Controller
The next step in the procedure is to stage the new backup master or active master controller with basic IP connectivity. Power up the new controller, connect a laptop computer to the controller's serial port, and follow the prompts to configure basic settings, as shown below:
Auto-provisioning is in progress. Choose one of the following options to override or debug...
'enable-debug' : Enable auto-provisioning debug logs
'disable-debug' : Disable auto-provisioning debug logs
'mini-setup' : Stop auto-provisioning and start mini setup dialog for branch role
'full-setup' : Stop auto-provisioning and start full setup dialog for any role
Enter Option (partial string is acceptable): full-setup
Are you sure that you want to stop auto-provisioning and start full setup dialog? (yes/no): yes
Reading configuration from factory-default.cfg
***************** Welcome to the Aruba 7210 setup dialog *****************
This dialog will help you to set the basic configuration for the switch.
These settings, except for the Country Code, can later be changed from the
Command Line Interface or Graphical User Interface.
Enter System name [Aruba 7210]:
Enter Switch Role (master|local|standalone) [master]:
Enter VLAN 1 interface IP address [172.16.0.254]: 10.79.100.109
Enter VLAN 1 interface subnet mask [255.255.255.0]:
Enter IP Default gateway [none]: 10.79.100.1
Enter Country code (ISO-3166), <ctrl-I> for supported list: US
You have chosen Country code US for United States (yes|no)?: yes
Enter Time Zone [PST-8:0]:
ArubaOS 6.5.3.x
| User Guide The Basic User-Centric Networks | 49
Enter Time in UTC [02:24:44]: 02:36:44
Enter Date (MM/DD/YYYY) [12/3/2012]:
Enter Password for admin login (up to 32 chars): ******
Re-type Password for admin login: ******
Enter Password for enable mode (up to 15 chars): ******
Re-type Password for enable mode: ******
Do you wish to shutdown all the ports (yes|no)? [no]:
If you accept the changes the switch will restart!
Type <ctrl-P> to go back and change answer for any question
Do you wish to accept the changes (yes|no)yes
Creating configuration... Done.
System will now restart!
Add Licenses to the New Controller
Use the license add command in the command-line interface or navigate to Configuration > Network >
Controller > License Management to add new or transferred licenses to the new controller.
Do not reboot the controller at the end of this step. Do not save the configuration or write it to memory. Reboot only after the flash memory and the licenses have been restored.
(host) #license add <key>
Backup Newly Installed Licenses
Use the license export command in the command-line interface or click Export Database in the
Configuration > Network > Controller > License Management page of the WebUI to back up the newly installed licenses to the backup license database.
Do not reboot the controller at the end of this step. Do not save the configuration or write it to memory. Reboot only after the flash memory and the licenses have been restored.
(host) #license export <filename>
Import and Restore Flash Backup
Import and restore the backup flash file system from the original controller to the new controller,
Do not reboot the controller at the end of this step. Do not save the configuration or write it to memory. Reboot only after the flash memory and the licenses have been restored.
In the WebUI
To import and restore a flash backup using the WebUI:
1. Access the new controller and navigate to Maintenance > File> Copy Files .
2. In the Source Selection section, choose any of the server options or select USB Drive if the flash backup is on USB storage.
3. In the Destination Selection section, choose Flash File System .
4. Enter the filename of the flash backup and click Apply . By default, the flash backup file is named flashbackup.tar.gz
.
5. Next, navigate to Maintenance>File>Restore Flash and select Restore .
In the CLI
To import and restore a flash backup file using the command-line interface, use the copy and restore flash commands. The following example copies a backup file from a USB drive.
50 | The Basic User-Centric Networks ArubaOS 6.5.3.x | User Guide
(host) #copy usb: Partition 1 flashbak2_7200.tar.gz flash: flashbackup.tar.gz
....File flashbak2_7200.tar.gz copied to flash successfully.
(host) #dir
-rw-r--r--
-rw-r--r--
-rw-r--r-drwxr-xr-x
-rwxr-xr-x
-rw-r--r--
-rw-r--r-drwx------
1 root
1 root
2 root
3 root
1 root
1 root
2 root
2 root root root root root root root root root
10182 Dec
10977 Dec
10977 Dec
4096 Dec
2 18:39 default.cfg
9726 Nov 30 21:36 default.cfg.2012-11-30_21-36-23
2 18:39 default.cfg.2012-12-02_18-39-27
4096 Dec 2 18:25 fieldCerts
78205 Dec 2 19:41 flashbackup.tar.gz
1796 Nov 30 19:12 license_backup.db
2 18:39 original.cfg
2 18:25 tpm
(host) #restore flash
Please wait while we uncompress /flash/config/flashbackup.tar.gz...
Please wait while we untar /flash/config/flashbackup.tar.gz...
Flash restored successfully.
Please reload (reboot) the switch for the new files to take effect.
Restore Licenses
Issue the license import command in the command-line interface or click Import Database in the
Configuration > Network > Controller > License Management page of the WebUI to import licenses from the license database to the new controller.
(host) #license import <filename>
Do not save the configuration or write to memory at the end of this step.
Reboot the Controller
Once all the licenses have been restored, issue the reload command in the command-line interface or navigate to Maintenance>Reboot Controller in the WebUI to reboot the new controller. After rebooting, the controller should not be on the network (or a reachable subnet) with the controller it will replace. This is to prevent a possible IP address conflict.
Do not save the configuration or write to memory at the end of this step.
(host) #reload
Do you want to save the configuration(y/n): n
Do you really want to restart the system(y/n): y
System will now restart!
Modify the Host Name
Issue the hostname command in the command-line interface to give the new controller a unique hostname.
(The flash restoration process gave the new controller the same name as the existing controller.)
Do not save the configuration or write to memory at the end of this step.
(host)(config) #hostname <hostname>
ArubaOS 6.5.3.x
| User Guide The Basic User-Centric Networks | 51
Modify Topology Settings
This is required when migrating to a newer controller model. New controller models such as the 7000 Series and 7200 Series controllers use a different port numbering scheme than other Aruba controllers. Ports on the newer controller models are numbered slot/module/port . Older controller ports are numbered slot/port . As a result, flash backup files restored from older controllers onto a newer model controllers can cause the newer controller lose network connectivity, as the imported port settings don't match up with the controller hardware. Additionally, all ports will become untrusted when you import a configuration from an older model controller to a newer model controller.
Use the interface range and switchport commands to reconfigure the VLANs and IP interfaces to match the port scheme of that hardware model. To avoid network conflicts, this process must be completed before the controller is connected to the management network.
If you are replacing a controller with the same controller model, you can skip this step and continue to
The following commands adjust the port configuration on the new controller .
(host) (config) #interface range gigabitethernet <slot>/<module-start>/<port-start>-<moduleend>/<port-end>
(host) (config-range) #switchport access vlan <id>
Because the physical ports don't match, the port trust is removed by default, and needs to be re-enabled. In the example below, the Trusted column shows that the port trust is disabled for all ports.
(host) #show port status
Port Status
-----------
Slot-Port
---------
0/0/0
0/0/1
0/0/2
PortType
--------
GE
GE
GE adminstate
----------
Enabled
Enabled
Enabled operstate
---------
Up
Down
Down poe
---
Trusted SpanningTree PortMode
-------------------------
Enabled No
Enabled No
Enabled No
Disabled
Disabled
Disabled
Access
Access
Access
0/0/3
0/0/4
0/0/5
GE
GE
GE
Enabled
Enabled
Enabled
Down
Down
Down
Enabled No
Enabled No
Enabled No
Disabled
Disabled
Disabled
Access
Access
Access
Use the interface range command to re-apply port trust to all of the gigabit Ethernet ports on the controller.
Then issue the show port status command to verify port trust has been restored.
(host) (config) #interface range gigabitethernet <slot>/<module-start>/<port-start>-<moduleend>/<port-end>
(host) (config-range) #trusted
(host) #show port status
Port Status
-----------
Slot-Port
---------
0/0/0
0/0/1
0/0/2
0/0/3
PortType
--------
GE
GE
GE
GE adminstate
----------
Enabled
Enabled
Enabled
Enabled operstate
---------
Down
Down
Down
Down poe
---
Trusted SpanningTree PortMode
-------------------------
Enabled Yes
Enabled Yes
Enabled Yes
Enabled Yes
Disabled
Disabled
Disabled
Disabled
Access
Access
Access
Access
0/0/4
0/0/5
GE
GE
Enabled
Enabled
Down
Down
Enabled Yes
Enabled Yes
Disabled
Disabled
Access
Access
52 | The Basic User-Centric Networks ArubaOS 6.5.3.x | User Guide
Save your Configuration
Now, you must save the configuration settings on the new controller. Issue the write memory command in the command-line interface, or click the Configuration tab and select the Save Configuration button at the top of the WebUI page.
(host) (config) #write memory)
Remove the Existing Controller
If you are only replacing a backup controller, remove the existing backup controller, then connect the replacement controller to the network. If you are replacing both an active controller and a backup controller, replace the backup controller first.
When the active master controller is removed from the network, the backup master immediately assumes the role of active master, and all active APs associate to the new active master controller within a few seconds.
Therefore, when you add another controller to the network, it will, by default, assume the role of a backup controller.
If you changed the VRRP priorities of your redundant master controllers prior to replacing the primary master controller, you may wish to change them back once the new primary master is active on the network.
ArubaOS 6.5.3.x
| User Guide The Basic User-Centric Networks | 53
Chapter 2
Control Plane Security
ArubaOS supports secure IPsec communications between a controller and campus or remote APs using publickey self-signed certificates created by each master controller. The controller certifies its APs by issuing them certificates. If the master controller has any associated local controllers, the master controller sends a certificate to each local controller, which in turn sends certificates to their own associated APs. If a local controller is unable to contact the master controller to obtain its own certificate, it is not be able to certify its
APs, and those APs cannot communicate with their local controller until master-local communication has been reestablished. You create an initial control plane security configuration when you first configure the controller using the initial setup wizard. The ArubaOS initial setup wizard enables control plane security by default, so it is very important that the local controller be able to communicate with its master controller when it is first provisioned.
Some AP model types have factory-installed digital certificates. These AP models use their factory-installed certificates for IPsec, and do not need a certificate from the controller. Once a campus or remote AP is certified, either through a factory-installed certificate or a certificate from the controller, the AP can failover between local controllers and still stay connected to the secure network, because each AP has the same master controller as a common trust anchor.
Starting with ArubaOS 6.2, the controller maintains two separate AP whitelists; one for campus APs and one for
Remote APs. These whitelists contain records of all campus APs or remote APs connected to the network. You can use a campus or AP whitelist at any time to add a new valid campus or remote AP to the secure network, or revoke network access to any suspected rogue or unauthorized APs.
The control plane security feature supports IPv4 campus and remote APs only. Do not enable control plane security on a controller that terminates IPv6 APs.
When the controller sends an AP a certificate, that AP must reboot before it can connect to its controller over a secure channel. If you are enabling control plane security for the first time on a large network, you may experience several minutes of interrupted connectivity while each AP receives its certificate and establishes its secure connection.
n n n n
HP Platform interoperating with Aruba Controllers
Following HP TPM based switches can now inter-operate with the Aruba controllers and create the IKE / IPSec tunnels.
n n n n n n
2930F
5400R/v3 3810
5400R/v2 (compat. mode)
3800
2920
2530
2620
5400/v2
5400/v1
3500
ArubaOS 6.5.3.x
| User Guide Control Plane Security | 54
n n n
2615
2915
8200
These HP platforms are running version k.16.02.
Topics in this chapter include: n n n n n n n n
Control Plane Security Overview on page 55
Configuring Control Plane Security on page 55
Managing AP Whitelists on page 57
Managing Whitelists on Master and Local Controllers on page 64
Working in Environments with Multiple Master Controllers on page 68
Replacing a Controller on a Multi-Controller Network on page 71
Configuring Control Plane Security after Upgrading on page 75
Troubleshooting Control Plane Security on page 76
Control Plane Security Overview
Controllers using control plane security only send certificates to APs that you have identified as valid APs on the network. If you want closer control over each AP that is certified, you can manually add individual campus and remote APs to the secure network by adding each AP's information to the whitelists when you first run the initial setup wizard. If you are confident that all APs currently on your network are valid APs, then you can use the initial setup wizard to configure automatic certificate provisioning to send certificates from the controller to each campus or remote AP, or to all campus and remote APs within specific ranges of IP addresses.
The default automatic certificate provisioning setting requires that you manually enter each campus AP’s information into the campus AP whitelist, and each remote AP's information into the remote AP whitelist. If you change the default automatic certificate provisioning values to let the controller send certificates to all APs on the network, that new setting ensures that all valid APs receive a certificate, but also increases the chance that you will certify a rogue or unwanted AP. If you configure the controller to send certificates to only those
APs within a range of IP addresses, there is a smaller chance that a rogue AP receives a certificate, but any valid
AP with an IP address outside the specified address ranges will not receive a certificate, and can not communicate with the controller (except to obtain a certificate). Consider both options carefully before you complete the control plane security portion of the initial setup wizard. If your controller has a publicly accessible interface, you should identify the APs on the network by IP address range. This prevents the controller from sending certificates to external or rogue campus APs that may attempt to access your controller through that publicly accessible interface.
Configuring Control Plane Security
When you initially deploy the controller, you create your initial control plane security configuration using the initial setup wizard. These settings can be changed at any time using the WebUI or the command-line interfaces.
If you are configuring control plane security for the first time after upgrading from ArubaOS 5.0 or earlier, see
Configuring Control Plane Security after Upgrading on page 75
for details on enabling this feature using the WebUI or CLI.
55 | Control Plane Security ArubaOS 6.5.3.x | User Guide
In the WebUI
1. Navigate to Configuration > Network > Controller .
2. Select the Control Plane Security tab.
3. Configure the following control plane security parameters:
Table 17: Control Plane Security Parameters
Parameter Description
Control Plane
Security
Auto Cert
Provisioning
Addresses allowed for Auto Cert
Number of AP
Whitelist Entries
Select enable or disable to turn the control plane security feature on or off. This feature is enabled by default.
When you enable the control plane security feature, you can select this checkbox to turn on automatic certificate provisioning. When you enable this feature, the controller attempts to send certificates to all associated campus APs. Auto certificate provisioning is disabled by default.
NOTE: If you do not want to enable automatic certificate provisioning the first time you enable control plane security on the controller, you must identify the valid APs on your network by adding those to the campus AP whitelist. For details, see
Viewing the Master or Local Controller Whitelists on page 66 .
After you have enabled automatic certificate provisioning, you must select either
Auto Cert Allow all or Addresses Allowed for Auto Cert .
The Addresses Allowed for Auto Cert section allows you to specify whether certificates are sent to all associated APs, or just APs within one or more specific IP address ranges. If your controller has a publicly accessible interface, you should identify your campus and Remote APs by IP address range. This prevents the controller from sending certificates to external or rogue campus APs that may attempt to access your controller through that interface.
Select All to allow all associated campus and remote APs to receive automatic certificate provisioning. This parameter is enabled by default.
Select Addresses Allowed for Auto Cert to send certificates to a group of campus or remote APs within a range of IP addresses. In the two fields below, enter the start and end IP addresses, then click Add . Repeat this procedure to add additional IP ranges to the list of allowed addresses. If you enable both control plane security and auto certificate provisioning, all APs in the address list receives automatic certificate provisioning.
Remove a range of IP addresses from the list of allowed addresses by selecting the
IP address range from the list and clicking Delete.
This parameter is the total number of APs in the remote AP and campus AP
Whitelists. This number is also a link to a combined whitelist that displays all campus and remote AP entries.
4. Click Apply .
The master controller generates its self-signed certificate and begins distributing certificates to campus APs and any local controllers on the network over a clear channel. After all APs have received a certificate and have connected to the network using a secure channel, access the Control Plane Security window and turn off auto certificate provisioning if that feature was enabled. This prevents the controller from issuing a certificate to any rogue APs that may appear on your network at a later time.
ArubaOS 6.5.3.x
| User Guide Control Plane Security | 56
Figure 4 Control Plane Security Settings
In the CLI
Use the commands below to configure control plane security via the command line interface on a standalone or master controller. Descriptions of the individual parameters are listed in
(host)(config) #control-plane-security
(host)(Control Plane Security Profile) #auto-cert-allow-all
(host)(Control Plane Security Profile) #auto-cert-allowed-addrs <ipaddress-start> <ipaddressend>
(host)(Control Plane Security Profile) #auto-cert-prov
(host)(Control Plane Security Profile) #cpsec-enable
View the current control plane security settings using the following command:
(host) #show control-plane-security
Managing AP Whitelists
Campus or Remote APs appear as valid APs in the campus or Remote AP whitelists when you manually enter their information into the campus or Remote AP whitelists through the WebUI or CLI of a controller or after a controller sends a certificate to an AP as part of automatic certificate provisioning and the AP connects to the controller over a secure tunnel. APs that are not approved or certified on the network are included in the campus AP whitelists, but these APs appear in an unapproved state.
Use the AP whitelists to grant valid APs secure access to the network or to revoke access from suspected rogue
APs. When you revoke or remove an AP from the campus or remote AP whitelists on a controller that uses control plane security, that AP is not able to communicate with the controller again, except to obtain a new certificate.
If you manually add APs to the AP whitelists (rather than automatically adding the APs as part of automatic certificate provisioning), make sure that the AP whitelists have been synchronized to all other controllers on the network before enabling control plane security.
Adding an AP to the Campus or Remote AP Whitelists
You can add an AP to the campus AP or remote AP whitelists over the WebUI or CLI.
In the WebUI
To add an AP to the campus AP or Remote AP whitelist:
1. Navigate to Configuration > Wireless > AP Installation .
2. Click the Whitelist tab.
3. Select the whitelist to which you want to add an AP. The Whitelist tab displays status information for the
Campus AP Whitelist by default. To add a Remote AP to the Remote AP whitelist, click the Remote AP link before you proceed to
.
57 | Control Plane Security ArubaOS 6.5.3.x | User Guide
Figure 5 Control Plane Security Settings
4. Click Entries in the upper right corner of the whitelist status window.
5. Click New .
6. Define the following parameters for each AP you want to add to the AP whitelist.
Table 18: AP Whitelist Parameters
Parameter Description
Campus AP whitelist configuration parameters
AP MAC Address MAC address of campus AP that supports secure communications to and from its controller.
AP Group
AP Name
Name of the AP group to which the campus AP is assigned. If you do not specify an AP group, the AP uses default as its AP group.
Name of the campus AP. If you do not specify a name, the AP uses its MAC address as AP name.
Description Brief description of the campus AP.
Remote AP whitelist configuration parameters
AP MAC Address
User Name
AP Group
AP Name
MAC address of the remote AP, in colon-separated octets.
Name of the end user who provisions and uses the remote AP.
Name of the AP group to which the Remote AP is assigned.
Name of the Remote AP. If you do not specify a name, the AP uses its MAC address as AP name.
Description
IP-Address
Brief description of the Remote AP.
The static inner IP address to be assigned to the Remote APs.
7. Click Add .
In the CLI
To add an AP to the campus AP whitelist:
(host) #whitelist-db cpsec add mac-address <name> ap-group <ap_group> ap-name <ap_name>
ArubaOS 6.5.3.x
| User Guide Control Plane Security | 58
description <description>
To add an AP to the remote AP whitelist:
(host) #whitelist-db rap add mac-address <mac-address> ap-group <ap-group> ap-name <ap-name> description <description> full-name <name> remote-ip <inner-ip-adr>
Viewing AP Whitelist Status
The WebUI displays either a status of the selected AP whitelist or a table of entries in the selected AP whitelist.
The status page displays the current status of the AP whitelist and for controllers in a master/local controller topology, it displays the AP whitelist synchronization status between controllers. When the status of an entry in the AP whitelist changes, the AP whitelist status is updated automatically. The table of entries page displays the status of each AP on the AP whitelist.
The Configuration > Wireless > AP Installation > Whitelist tab displays the status of the campus AP whitelist by default. To view the status of remote AP whitelist, click the Remote AP link.
The following table describes the contents of the status page.
Table 19: Whitelist Status Information
Status Entry Description
Campus AP whitelist status information
Control Plane Security
Total entries
Shows if the control plane security is enabled or disabled on the controller.
This status entry is also a link to the control plane security configuration tab.
Number of entries in the campus AP whitelist.
Approved entries
Unapproved entries
Number of entries in the campus AP whitelist that have been approved by the controller.
Number of entries in the campus AP whitelist that have not been approved by the controller.
Certified entries
Certified hold entries
Revoked entries
Number of entries in the campus AP whitelist that have an approved certificate from the controller.
Number of entries in the campus AP whitelist that have been certified with a factory certificate but request to be certified again. Such APs are not approved as secure until you manually change the status and verify that it is not compromised.
NOTE: If an AP is in the hold state because of connectivity problems, then the AP recovers and moves out of the hold state when connectivity is restored.
Number of entries in the campus AP whitelist that has been manually revoked.
Marked for deletion entries Number of entries in the campus AP whitelist that has been marked for deletion, but not removed from the Remote AP whitelist.
Remote AP whitelist configuration parameters
59 | Control Plane Security ArubaOS 6.5.3.x | User Guide
Table 19: Whitelist Status Information
Status Entry Description
Total entries
Revoked entries
Marked for deletion entries
Number of entries in the Remote AP whitelist.
Number of entries in the Remote AP whitelist that has been manually revoked.
Number of entries in the Remote AP whitelist that has been marked for deletion, but not removed from the Remote AP whitelist.
The Remote AP whitelist entries page displays only the information you manually configure. The campus AP whitelist entries page displays both user-defined settings and additional information that is updated when the status of a campus AP changes.
Table 20: Additional Campus AP Status Information
Parameter
Cert Type
Description
State
Revoked
Revoked Text
Last Update
The type of certificate used by the campus AP.
n n switch-cert : The campus AP is using a certificate signed by the controller.
factory-cert : The campus AP is using a factory-installed certificate.
The state of a campus AP.
n unapproved-no-cert: The campus AP has no certificate and is not approved.
n n n unapproved-factory-cert: The campus AP has a pre-installed certificate which is not approved.
approved-ready-for-cert: The campus AP is approved as valid and is ready to receive a certificate.
certified-factory-cert : The campus AP already has a factory certificate. If a campus AP has a factory-cert type of certificate and is in certified-factory-cert state, then a new certificate is not reissued to the campus AP when you enable automatic certificate provisioning.
n n certified-switch-cert: The campus AP has an approved certificate from the controller.
certified-hold-factory-cert : The campus AP is certified with a factory certificate but requests to be certified again. Such APs are not approved as secure until you manually change the status and verify that it is not compromised.
NOTE: If an AP is in this state due to connectivity problems, then the AP recovers and leaves this hold state as soon as connectivity is restored.
n certified-hold-switch-cert : An AP is put in this state when the controller thinks the AP has been certified with a controller certificate but the AP requests to be certified again. Because this is not a normal condition, the AP is not approved as a secure AP until a network administrator manually changes the status of the AP to verify that it is not compromised.
NOTE: If an AP is in the hold state because of connectivity problems, then the AP recovers and moves out of the hold state when connectivity is restored.
Shows if the secure status of the AP is revoked.
Brief description for revoking the campus AP.
Time and date of the last AP status update.
To view information about the campus and remote AP whitelists using the CLI, use the following commands:
ArubaOS 6.5.3.x
| User Guide Control Plane Security | 60
(host) #show whitelist-db cpsec ap-group <ap_group> ap-name <ap_name> cert-type {factory-cert|switch-cert} mac-address <name> page <num> start <offset> state {approved-ready-for-cert| certified-factory-cert| unapproved-factory-cert| unapproved-no-cert}
(host) #show whitelist-db cpsec-status
(host) #show whitelist-db rap apgroup <rap-group> apname <rap-name> fullname <rap-fullname> long mac-address <mac-address> page <page-number> start <offset>
(host) #show whitelist-db rap-status
Modifying an AP in the Campus AP Whitelist
Use the following procedures to modify the AP group, AP name, certificate type, state, description, and revoked status of an AP in the campus AP whitelist.
In the WebUI
To modify an AP in the campus AP whitelist:
1. Navigate to Configuration > Wireless > AP Installation .
2. Click the Whitelist tab.
3. Click the Entries>> button.
4. Select the checkbox of the AP that you want to modify, then click Modify .
If your campus AP whitelist is large and you cannot immediately locate the AP that you want to modify, select the Search link. The Whitelist Search tab displays the fields AP Group , Cert Type , AP MAC
Address , AP Name , and State that allow you to search for an AP. Specify the values of the AP that you want to locate in these fields, then click Search . The campus AP whitelist displays a list of APs that match your search criteria. Select the checkbox of the AP that you want to modify, then click Modify .
5. Modify the settings of the selected AP. Some of the following parameters are available when adding an
AP to the campus AP whitelist and are described in
n
AP Group : The name of the AP group to which the campus AP is assigned.
n n
AP Name : The name of the campus AP. If you not specify a name, the AP uses its MAC address as a name.
Cert-type : The type of certificate used by the AP.
n n n l l switch-cert: The campus AP is using a certificate signed by the controller.
factory-cert: The campus AP is using a factory-installed certificate.
State : When you click the State drop-down list to modify this parameter, you may choose one of the following options: l l approved-ready-for-cert: The AP has been approved state and is ready to receive a certificate.
certified-factory-cert: The AP is certified and has a factory-installed certificate.
Description : Brief description of the campus AP.
Revoked : Click the Revoked checkbox to revoke an invalid or rogue AP.
61 | Control Plane Security ArubaOS 6.5.3.x | User Guide
n
Revoke Text : When the Revoked checkbox is selected, enter a brief comment describing why the AP is being revoked.
6. Click Update to update the campus AP whitelist entry with its new settings.
In the CLI
To modify an AP in the campus AP whitelist:
(host) #whitelist-db cpsec modify mac-address <name> ap-group <ap_group> ap-name <ap_name> cert-type {switch-cert|factory-cert} description <description> mode {disable|enable} revoke-text <revoke-text> state {approved-ready-for-cert|certified-factory-cert}
Revoking an AP from the Campus AP Whitelist
You can revoke an invalid or rogue AP either by modifying its revoke status (as described in
parameter. When revoking an invalid or rogue AP, enter a brief description why the AP is being revoked. When you revoke an AP from the campus AP whitelist, the campus AP whitelist retains the information of the AP. To revoke an invalid or rogue AP and permanently remove it from the whitelist, delete that entry (as described in ).
In the WebUI
To revoke an AP from the campus AP whitelist:
1. Navigate to Configuration > Wireless > AP Installation .
2. Click the Whitelist tab.
3. Click the Entries>> button.
4. Select the checkbox of the AP that you want to revoke, then click Revoke .
If your campus AP whitelist is large and you cannot immediately locate the AP that you want to revoke, select the Search link. The Whitelist Search tab displays the fields AP Group , Cert Type , AP MAC
Address , AP Name , and State that allow you to search for an AP. Specify the values of the AP that you want to locate in these fields, then click Search . The campus AP whitelist displays a list of APs that match your search criteria. Select the checkbox of the AP that you want to revoke, then click Revoke .
5. Enter a brief description why the AP is being revoked, then click Update .
In the CLI
To revoke an AP via the campus AP whitelist:
(host) #whitelist-db cpsec revoke mac-address <name> revoke-text <revoke-text>
Deleting an AP from the Campus AP Whitelist
Before deleting an AP from the campus AP whitelist, verify that auto certificate provisioning is either not enabled or enabled only for IP addresses that do not include the AP being deleted. If you enable automatic certificate provisioning for an AP that is still connected to the network, you cannot delete it from the campus
AP whitelist; the controller immediately re-certifies the AP and recreates its whitelist entry.
In the WebUI
To delete an AP from the campus AP whitelist:
1. Navigate to Configuration > Wireless > AP Installation .
2. Click the Whitelist tab.
ArubaOS 6.5.3.x
| User Guide Control Plane Security | 62
3. Click the Entries>> button.
4. Select the checkbox of the AP you want to delete, then click delete .
If your campus AP whitelist is large and you cannot immediately locate the AP that you want to delete, select the Search link. The Whitelist Search tab displays the fields AP Group , Cert Type , AP MAC
Address , AP Name , and State that allow you to search for an AP. Specify the values of the AP that you want to locate in these fields, then click Search . The campus AP whitelist displays a list of APs that match your search criteria. Select the checkbox of the AP that you want to delete, then click Delete .
In the CLI
To delete an AP from the campus AP whitelist:
(host) #whitelist-db cpsec del mac-address <name>
Purging a Campus AP Whitelist
Before adding a new local controller to a network using control plane security, purge the campus AP whitelist on the new controller. After adding the new controller to the hierarchy, the entries in the campus AP whitelist of the new controller merge into the whitelist for all other master and local controllers. If you add any old or invalid AP entries to the campus AP whitelist, all controllers in the hierarchy will trust those APs, creating a potential security risk. For additional information on adding a new local controller using control plane security to your network, see
Replacing a Local Controller on page 71
In the WebUI
To purge a campus AP whitelist:
1. Navigate to Configuration > Wireless > AP Installation .
2. Click the Whitelist tab.
3. Click the Entries>> button.
4. Click Purge .
In the CLI
To purge a campus AP whitelist:
(host) #whitelist-db cpsec purge
Offloading a Controller Whitelist to ClearPass Policy Manager
This feature allows to externally maintain AP whitelist in a ClearPass Policy Manager (CPPM) server. The controller, if configured to use an external server, can send a RADIUS access request to a CPPM server. The
MAC address of the AP is used as a username and password to construct the access request packet. The CPPM server validates the RADIUS message and returns the relevant parameters for the authorized APs.
The following supported parameters are associated with the following VSAs. The CPPM server sends them in the RADIUS access accept packet for authorized APs: n n n ap-group: Aruba-AP-Group ap-name: Aruba-Location-ID ap-remote-ip: Aruba-AP-IP-Address
The following defaults are used when any of the supported parameters are not provided by the CPPM server in the RADIUS access accept response: n n ap-group: The default ap-group is assigned to the AP.
ap-name: The MAC address of the AP is used as the AP name.
63 | Control Plane Security ArubaOS 6.5.3.x | User Guide
There is no change in the RAP role assignment. The RAP is assigned the role that is configured in the VPN default-rap profile.
In the WebUI
To assign a CPPM server to a RAP:
1. Configure a CPPM server using the controller WebUI: a. Navigate to Configuration > Security > Authentication > Servers .
b. Select Radius Server to display the CPPM Server List.
c. To configure a CPPM server, enter the name for the server and click Add .
d. Select the name to configure server parameters. Select the Mode check box to activate the authentication server.
e. Click Apply .
2. Create a server group that contains the CPPM server.
3. Navigate to Configuration > All Profile Management > Wireless LAN > VPN Authentication > default-rap > Server Group .
4. Select the CPPM server from the Server Group drop-down list.
5. Click Apply .
To assign a CPPM server to a RAP that was initially an Instant AP:
1. Make sure that a CPPM server is configured on the controller.
2. Navigate to Configuration > All Profile Management > Wireless LAN > VPN Authentication > default-iap > Server Group .
3. Select the CPPM server from the Server Group drop-down list.
4. Click Apply .
In the CLI
To add a CPPM server to a RAP:
Configure a radius server with CPPM server as host address. In this example cppm-rad is the CPPM server name and cppm-sg is the server group name.
(host)(config) #aaa authentication-server radius cppm-rad
Add this server to a server group:
(host)(config) #aaa server-group cppm-sg
(host) (Server Group "cppm-sg") #auth-server cppm-rad
Add this server group to the default-rap vpn profile:
(host)(config) #aaa authentication vpn default-rap
(host)(VPN Authentication Profile "default-rap") #server-group cppm-sg
Managing Whitelists on Master and Local Controllers
Every controller using the control plane security feature maintains a campus AP whitelist, a local controller whitelist and a master controller whitelist. The contents of these whitelists vary, depending upon the role of the controller, as shown in the table below.
ArubaOS 6.5.3.x
| User Guide Control Plane Security | 64
Table 21: Control Plane Security Whitelists
Controller Role
On a (standalone) master controller with no local controllers:
On a master controller with local controllers:
On a local controller:
Campus AP Whitelist
Master Controller
Whitelist
The campus AP whitelist contains entries for the secure campus
APs associated with that controller.
The master controller whitelist is empty, and does not appear in the
WebUI.
The campus AP whitelist contains an entry for every secure campus AP on the network, regardless of the controller to which it is connected.
The master controller whitelist is empty, and does not appear in the
WebUI.
The campus AP whitelist contains an entry for every secure campus AP on the network, regardless of the controller to which it is connected.
The master controller whitelist contains the
MAC and the IP addresses of the master controller.
Local Controller
Whitelist
The local controller whitelist is empty, and does not appear in the WebUI.
The local controller whitelist contains an entry for each associated local controller.
The local controller whitelist is empty, and does not appear in the WebUI.
Figure 6 Local Controller Whitelist on a Master Controller
If your deployment includes both master and local controllers, then the campus AP whitelist on every controller contains an entry for every secure AP on the network, regardless of the controller to which it is connected. The master controller also maintains a whitelist of local controllers using control plane security.
When you change a campus AP whitelist on any controller, that controller contacts the other connected controllers to notify them of the change.
The master controller whitelist on each local controller contains the IP and MAC addresses of its master controller. If your network has a redundant master controller, then this whitelist contains more than one entry.
You rarely need to delete the master controller whitelist. Although you can delete an entry from the master controller whitelist, you should do so only if you have removed a master controller from the network.
Campus AP Whitelist Synchronization
The current sequence number in the AP Whitelist Sync Status field shows the number of changes to the campus AP whitelist made on that controller. Each controller compares its campus AP whitelist against whitelists on other controllers every two minutes by default. If a controller detects a difference, it sends its changes to the other controllers on the network. If all other controllers on the network have successfully received and acknowledged all whitelist changes made on that controller, every entry in the sequencenumber column in the local controller or master controller whitelists has the same value as the sequence number displayed in the AP Whitelist Sync Status field. If a controller in the master or local controller whitelist has a
65 | Control Plane Security ArubaOS 6.5.3.x | User Guide
lower sequence number, that controller may still be waiting to complete its update, or receive its update acknowledgment. In the example in
, the master controller has a current sequence number of 3, and each sequence number in its local controller whitelist also shows a value of 3, indicating that both local controllers have received and acknowledged all three campus AP whitelist changes made on the master controller. For additional information on troubleshooting whitelist synchronization, see
.
You can view a controller’s current sequence number via the CLI:
(host) #show whitelist-db cpsec-seq
Viewing the Master or Local Controller Whitelists
The following sections describe the commands to view and delete entries in a master or local controller whitelist.
In the WebUI
To view the master or local controller whitelists:
1. Access the controller’s WebUI, and navigate to Configuration > AP Installation.
2. Select the Whitelist tab.
The master and local controller tables each include the following information:
Table 22: Master and Local Controller Whitelist Information
Field
MAC-Address
IP-Address
Sequence Number
Remote Sequence Number
Null Update Count
Description
On a local controller whitelist: MAC address of the master controller.
On a master controller whitelist: MAC address of a local controller.
On a local controller whitelist: IP address of the master controller.
On a master controller whitelist: IP address of a local controller.
The number of times the controller in the whitelist received and acknowledged a campus AP whitelist change from the controller whose
WebUI you are currently viewing.
For deployments with both master and local controllers: n The sequence number on a master controller should be the same as the remote sequence number on the local controller.
n The sequence number on a local controller should be the same as the remote sequence number on the master controller.
The number of times that the controller whose WebUI you are viewing received and acknowledged a campus AP whitelist change from the controller in the whitelist.
For deployments with both master and local controllers: n The remote sequence number on a master controller should be the same as the sequence number on the local controller.
n The remote sequence number on a local controller should be the same as the sequence number on the master controller.
The number of times the controller checked its campus AP whitelist and found nothing to synchronize with the other controller. The controller compares its control plane security whitelist against whitelists on other controllers every two minutes by default. If the null update count reaches five, the controller sends an “empty sync” heartbeat to the remote controller to ensure the sequence numbers on both controllers are the same, then resets the null update count to zero.
ArubaOS 6.5.3.x
| User Guide Control Plane Security | 66
In the CLI
To view the master or local controller whitelists via the command-line interface, issue the following commands:
(host) #show whitelist-db cpsec-master-switch-list [mac-address <mac-address>]
(host) #show whitelist-db cpsec-local-switch-list [mac-address <mac-address>]
Deleting an Entry from the Master or Local Controller Whitelist
You do not need to delete a master controller from the master controller whitelist during the course of normal operation. However, if you remove a local controller from the network, you should also remove the local controller from the local controller whitelist on the master controller. If the local controller whitelist contains entries for controllers no longer on the network, then a campus AP whitelist entry can be marked for deletion but is not physically deleted, as the controller is waiting for an acknowledgment from another controller no longer on the network. This can increase network traffic and reduce memory resources on the controller.
In the WebUI
To delete an entry from the master or local controller whitelist:
1. Navigate to Configuration > Controller.
2. Select the Control Plane Security tab.
3. To delete an entry from the Local Controller Whitelist: In the Local Switch List For AP Whitelist Sync section, click the Delete button by each controller entry you want to remove.
Or,
To delete an entry from the Master Controller Whitelist: In the Master Switch List For AP Whitelist Sync section, click Delete by each controller entry you want to remove.
4. Click Apply .
In the CLI
To delete an entry from the master or local controller whitelist:
(host) #whitelist-db cpsec-master-switch-list del mac-address <mac-address>
(host) #whitelist-db cpsec-local-switch-list del mac-address <mac-address>
Purging the Master or Local Controller Whitelist
There is no need to purge a master controller whitelist during the course of normal operation. If, however, you are removing a controller from the network, you can purge its controller whitelist after it has been disconnected from the network. To clear a local controller whitelist entry on a master controller that is still connected to the network, select that individual whitelist entry and delete it using the delete option.
In the WebUI
To purge a controller whitelist:
1. Navigate to Configuration > Controller .
2. Select the Control Plane Security tab.
3. To clear the Local Controller whitelist: In the Local Switch List For AP Whitelist Sync section, click
Purge.
Or,
4. To clear the Master Controller whitelist: In the Master Switch List For AP Whitelist Sync section, click
Purge .
67 | Control Plane Security ArubaOS 6.5.3.x | User Guide
In the CLI
To purge a controller whitelist:
(host) #whitelist-db cpsec-master-switch-list purge
(host) #whitelist-db cpsec-local-switch-list purge
Working in Environments with Multiple Master Controllers
This section describes the configuration steps required in a multiple master controllers network.
Configuring Networks with Clusters of Master Controllers
If your network includes multiple master controllers each with their own hierarchy of APs and local controllers, you can allow APs from one hierarchy to failover to any other hierarchy by defining a cluster of master controllers. Each cluster has one master controller as its cluster root, and all other master controllers as cluster members. The master controller operating as the cluster root creates a self-signed certificate, then certifies its own local controllers and APs. Next, the cluster root sends a certificate to each cluster member, which in turn certifies its own local controllers and APs. Because all controllers and APs in the cluster have the same trust anchor, the APs can switch to any other controller in the cluster and still remain securely connected to the network.
Figure 7 A Cluster of Master Controllers using Control Plane Security
To create a controller cluster, you must first define the root master controller and set an IPsec key or select a certificate for communications between the cluster root and cluster members.
You must use the command-line interface to configure certificate authentication for cluster members. The WebUI supports cluster authentication using IPsec keys only. If your master and local controllers use a pre-shared key for authentication, they create the IPsec tunnel using IKEv1. If your master and local controllers use certificates for authentication, the IPsec tunnel is created using IKEv2.
Creating a Cluster Root
Use the WebUI to identify a controller as a cluster root, and use an IPsec key to secure communication between the cluster root and cluster members. Use the command-line interface to create a cluster root using an IPsec key, factory-installed certificate, or custom certificate.
In the WebUI
To create a cluster root:
ArubaOS 6.5.3.x
| User Guide Control Plane Security | 68
1. Access the WebUI of the controller you want to identify as the cluster root, and navigate to Configuration
> Controller .
2. Click the Cluster Setting tab.
3. For the cluster role, select Root.
4. In the Cluster Member IPsec Keys section, enter the controller IP address of a member controller in the cluster. If you want to use a single key for all member controllers, use the IP address 0.0.0.0
.
5. In the IPsec Key and Retype IPsec Key fields, enter the IPsec key for communication between the specified member controller and the cluster root.
6. Click Add .
7.
Optional : repeat steps 4-6 to add another member controller to the cluster.
8. Click Apply.
In the CLI
To create a cluster root, access the command-line interface of the controller you want to identify as the root of the controller cluster, then issue one of the following commands: n n n
To authenticate cluster members using a custom certificate:
(host)(config) #cluster-member-custom-cert member-mac <mac> ca-cert <ca> server-cert <cert> suite-b <gcm-128|gcm-256>]
To authenticate cluster members using a factory-installed certificate:
(host)(config) #cluster-member-factory-cert member-mac <mac>
To authenticate cluster members using an IPsec key:
(host)(config) #cluster-member-ip <ip-address> ipsec <key>
The <ip-address> parameter in this command is the IP address of a member controller in the cluster, and the <key> parameter in each command is the IPsec key for communication between the specified member controller and the cluster root. Use the IP address 0.0.0.0
in this command to set a single IPsec key for all member controllers, or repeat this command as desired to define a different IPsec key for each cluster member.
Creating a Cluster Member
Once you have identified the cluster root, you must then identify the member controllers in the cluster.
Use the WebUI to identify a controller as a cluster member, and use an IPsec key to secure communication between the cluster member and the cluster root. Use the command-line interface to create a cluster member and secure communications between that member and the cluster root using an IPsec key, factory-installed certificate, or custom certificate.
In the WebUI
To create a cluster member:
1. Access the WebUI of the cluster member controller, and navigate to Configuration > Controller.
2. Click the Cluster Setting tab.
3. For the cluster role, select Member .
4. In the Controller IP Address field, enter the IP address of the root controller in the cluster.
5. In the IPsec Key and Retype IPsec Key fields, enter the IPsec key for communication between the specified member controller and the cluster root. This parameter must be have the same value as the key defined for the cluster member in
Creating a Cluster Root on page 68
.
6. Click Add .
7. Click Apply .
69 | Control Plane Security ArubaOS 6.5.3.x | User Guide
In the CLI
To create a cluster root via the CLI, access each of the member master controllers and define the IPsec key or certificate for communication between that controller and the cluster root.
(host)(config) #cluster-root-ip <ip-address> ipsec <key> ipsec-custom-cert root-mac-1 <root-mac-address-1> [master-mac2 <mac2>] ca-cert <ca> servercert <cert> [suite-b <gcm-128 | gcm-256>] ipsec-factory-cert root-mac-1 <root-mac-address-1> root-mac-2 <root-mac-address-2>
In this command the <ip-address> parameter is the IP address of the root master controller in the cluster. If you are using an IPsec key, the <key> parameter in this command must be have the same value as the key defined for the cluster member via the cluster-member-ip command.
Viewing Controller Cluster Setting
You can view the controller cluster configuration using the WebUI or CLI.
In the WebUI
To view the current cluster configuration:
1. Navigate to Configuration > Controller .
2. Click the Cluster Setting tab.
n
If you are viewing the WebUI of a cluster root, the output of this command displays the IP address of the
VLAN on the cluster member used to connect to the cluster root.
n
If you are viewing the WebUI of a cluster member, the output of this command displays the IP address of the VLAN on the cluster root used to connect to the cluster member.
In the CLI
To view your current cluster configuration, issue the CLI commands described in
Table 23: CLI Commands to Display Cluster Settings
Command show cluster-switches
Description show cluster-config
When you issue this command from the cluster root , the output of this command displays the IP address of the VLAN the cluster member uses to connect to the cluster root.
If you issue this command from a cluster member , the output of this command displays the IP address of the VLAN the cluster root uses to connect to the cluster member.
When you issue this command from the cluster root , the output of this command shows the cluster role of the controller, and the IP address of each active member controller in the cluster.
When you issue this command from a cluster member , the output of this command shows the cluster role of the controller, and the IP address of the cluster root.
Configuring Networks with a Backup Master Controller
If your network includes a redundant backup master controller, you must synchronize the database from the primary master to the backup master at least once after all APs are communicating with their controllers over a secure channel. This ensures that all certificates, IPsec keys, and campus AP whitelist entries are synchronized to the backup controller. You should also synchronize the database any time the campus AP whitelist changes
(APs are added or removed to ensure that the backup controller has the latest settings).
Master and backup controllers can be synchronized using either of the following methods:
ArubaOS 6.5.3.x
| User Guide Control Plane Security | 70
n n
Manual Synchronization : Issue the database synchronize command in enable mode to manually synchronize databases from your primary controller to the backup controller.
Automatic Synchronization : Schedule automatic database backups using the database synchronize period command in configuration mode.
If you add a new backup controller to an existing controller, you must add the backup controller as the lower priority controller. If you do not add the backup controller as a lower priority controller, your control plane security keys and certificates may be lost. If you want the new backup controller to become your primary controller, increase the priority of that controller to a primary controller after you have synchronized your data.
Replacing a Controller on a Multi-Controller Network
The procedure to replace a controller within a multi-controller network varies, depending upon the role of that controller, whether the network has a single master controller or a cluster of master controllers, and whether or not the controller has a backup.
The following sections describe the steps to replace an existing controller. To add a new local controller to a network, or to permanently remove a local controller without replacing it, see
Viewing the Master or Local Controller
Replacing Controllers in a Single Master Network
Use the procedures in this section to replace a master or local controller in a network environment with a single master controller.
Replacing a Local Controller
Use the following procedure to replace a local controller in a single-master network:
1. Disconnect the local controller from the network.
2. If you plan on moving the local controller to another location on the network, purge the campus AP whitelist on the controller.
Access the command-line interface on the old local controller and issue the whitelist-db cpsec purge command.
or,
Access the local controller WebUI, navigate to Configuration > AP Installation > Campus AP Whitelist and click Purge .
3. Once you purge the campus AP whitelist, you must inform the master controller that the local controller is no longer available using one of these two methods:
This step is very important ; unused local controller entries in the local controller whitelist can significantly increase network traffic and reduce controller memory resources.
n n
Access the command-line interface on the master controller, and issue the whitelist-db cpsec-localswitch-list del mac-address <local--mac> command.
Access the master controller WebUI, navigate to Configuration > Controller > Control Plane
Security , select the entry for the local controller you want to delete from the local controller whitelist, and click Delete .
4. Install the new local controller, but do not connect it to the network yet. If the controller has been previously installed on the network, you must ensure that the new local controller has a clean whitelist.
5. Purge the local controller whitelist using one of the following two methods:
71 | Control Plane Security ArubaOS 6.5.3.x | User Guide
n n
Access the command-line interface on the new local controller and issue the whitelist-db cpsec purge command.
Access the local controller WebUI, navigate to Configuration > AP Installation > Campus AP
Whitelist and click Purge .
6. Now connect the new local controller to the network. It is very important that the local controller be able to contact the master controller the first time it connects to the network, because the master controller certifies the local controller's control plane security certificate the first time the local controller contacts its master.
7. Once the local controller has a valid control plane security certificate and configuration, the local controller receives the campus AP whitelist from the master controller and starts certifying approved APs.
8. APs associated with the new local controller reboots and creates new IPsec tunnels to their controller using the new certificate keys.
Replacing a Master Controller with No Backup
Use the following procedure to replace a master controller that does not have a backup controller:
1. Remove the old master controller from the network.
2. Install and configure the new master controller, then connect the new master to the network. The new master controller generates a new certificate when it first becomes active.
3. If the new master controller has a different IP address than the old master controller, change the master IP address on the local controllers to reflect the address of the new master.
4. Reboot each local controller to ensure the local controllers obtain their certificate from the new master.
Each local controller begins using a new certificate signed by the master controller.
5. APs are now no longer able to securely communicate with the controller using their current key, and must obtain a new certificate. Access the campus AP whitelist on any local controller, and change all APs in a
“certified” state to an “approved” state. The new master controller sends the approved APs new certificates.
The APs reboot and create new IPsec tunnels to their controller using the new certificate key.
If the master controller does not have any local controllers, you must recreate the campus AP whitelist by turning on automatic certificate provisioning or manually reentering the campus AP whitelist entries.
Replacing a Redundant Master Controller
The control plane security feature requires you to synchronize databases from the primary master controller to the backup master controller at least once after the network is up and running. This ensures that all certificates, keys, and whitelist entries are synchronized to the backup controller. Because the AP whitelist may change periodically, you should regularly synchronize these settings to the backup controller. For details, see
Configuring Networks with a Backup Master Controller on page 70 .
When you install a new backup master controller, you must add it as a lower priority controller than the existing primary controller. After you install the backup controller on the network, synchronize the database from the existing primary controller to the new backup controller to ensure that all certificates, keys, and whitelist entries required for control plane security are added to the new backup controller configuration. If you want the new controller to act as the primary controller, you can increase that controller’s priority after the settings have been synchronized.
Replacing Controllers in a Multi-Master Network
Use the following procedures to replace a master or local controller in a network environment with a multiple master controllers.
ArubaOS 6.5.3.x
| User Guide Control Plane Security | 72
Replacing a Local Controller in a Multi-Master Network
The procedure to replace a local controller in a network with multiple master controllers is the same as the procedure to replace a local controller in a single-master network. To replace a local controller in a multi-master network, follow the procedure described in
Replacing a Local Controller on page 71
Replacing a Cluster Member Controller with no Backup
The control plane security feature allows APs to fail over from one controller to another within a cluster.
Therefore, cluster members or their local controllers may have associated APs that were first certified under some other cluster member (or the cluster root). If you permanently remove a cluster member whose APs were all originally certified under the cluster member being removed, its associated APs do not need to reboot in order to connect to a different controller. If, however, you remove a cluster member whose associated APs were originally certified under a different cluster member, those APs need to reboot and be re-certified before they can connect to a different controller. If the cluster member you are removing has local controllers, the local controllers also reboot so they can be updated with new certificates, then pass the trust update to their terminating APs.
To replace a cluster member that does not have a backup controller:
1. On the cluster master to be removed, clear the cluster root IP address by accessing the command-line interface and issuing the no cluster-root-ip <cluster-root-ip> ipsec <clusterkey> command.
2. Remove the cluster member from the network.
3. If the cluster master you removed has any associated APs, you must reboot those APs so they receive an updated certificate.
4. If the cluster member you removed has any associated local controllers, reboot those local controllers so they receive a new certificate and then pass that trust update to their APs.
5. Remove the cluster master from the cluster root’s master controller list by accessing the command-line interface on the cluster root and issuing the whitelist-db cpsec-master-switch-list del mac-address
<cluster-master-mac> command.
This step is very important . Unused local controller entries in the local controller whitelist can significantly increase network traffic and reduce controller memory resources.
6. Remove the old cluster member from the network. Remember, that controller still has campus AP whitelist entries from the entire cluster. You may want to delete or revoke unwanted entries from the campus AP whitelist.
Now, you must install the new cluster member controller according to the procedure described in
. The new cluster member obtains a certificate from the cluster root when it first becomes active.
7. If the new cluster member has any associated APs, reboot those APs so they obtain a trust update.
8. If the new cluster member has any local controllers, reboot the local controllers associated with the new cluster member. The local controllers obtain a new certificate signed by the cluster member, and then pass that trust update to their associated APs.
Replacing a Redundant Cluster Member Controller
The control plane security feature requires you to synchronize databases from the primary controller to the backup controller at least once after the network is up and running. This ensures that all certificates, keys, and whitelist entries are synchronized to the backup controller. Because the AP whitelist may change periodically, you should regularly synchronize these settings to the backup controller. For details, see
Configuring Networks with a Backup Master Controller on page 70
.
73 | Control Plane Security ArubaOS 6.5.3.x | User Guide
When you install a new backup cluster member, you must add it as a lower priority controller than the existing primary controller. After you install the backup cluster member on the network, resynchronize the database from the existing primary controller to the new backup controller to ensure that all certificates, keys, and whitelist entries required for control plane security are added to the new backup controller configuration. If you want the new controller to act as the primary controller, you can increase that controller’s priority after the settings have been resynchronized.
Replacing a Cluster Root Controller with no Backup Controller
If you replace a cluster root controller that does not have a backup controller, the new cluster root controller creates its own self-signed certificate. You then need to reboot each controller in the hierarchy in a specific order to certify all APs with that new certificate:
1. Remove the old cluster root from the network.
2. Install and configure the new cluster root.
3. Connect the new cluster root to the network so it can access cluster masters and local controllers.
4. If necessary, reconfigure the cluster masters and local controllers with their new cluster root IP and master
IP addresses.
5. Reboot every cluster member controller. The cluster member begins using a new certificate signed by the cluster root.
6. Reboot every local controller. Each local controller begins using a new certificate signed by the cluster member.
7. Because the cluster root is new, it does not have a configured campus AP whitelist. Access the campus AP whitelist on any local controller or cluster master, and change all APs in a “certified” state to an “approved” state. The APs get re-certified, reboot, and create new IPsec tunnels to their controller using the new certificate key.
If a cluster root controller does not have any cluster master or local controllers, you must recreate the campus AP whitelist on the cluster root by turning on automatic certificate provisioning or manually reentering the campus AP whitelist entries.
Replacing a Redundant Cluster Root Controller
Best practices is to use a backup controller with your cluster root controller. If your cluster root has a backup controller, you can replace the backup cluster root without having to reboot all cluster master and local controllers, minimizing network disruptions.
The control plane security feature requires you to synchronize databases from the primary controller to the backup controller at least once after the network is up at running. This ensures that all certificates, keys, and whitelist entries are synchronized to the backup controller. Because the AP whitelist may change periodically, you should regularly synchronize these settings to the backup controller. For details, see
Configuring Networks with a Backup Master Controller on page 70
.
When you install a new backup cluster root, you must add it as a lower priority controller than the existing primary controller. After you install the backup cluster root on the network, resynchronize the database from the existing primary controller to the new backup controller to ensure that all certificates, keys, and whitelist entries required for control plane security are added to the new backup controller configuration. If you want the new controller to act as the primary controller, you can increase that controller’s priority after the settings have been resynchronized.
ArubaOS 6.5.3.x
| User Guide Control Plane Security | 74
Configuring Control Plane Security after Upgrading
When you initially deploy a controller running ArubaOS 6.0 or later, create your initial control plane security configuration using the initial setup wizard. However, if you are upgrading to ArubaOS 6.0 from ArubaOS 3.4.x
or earlier releases, or if you are upgrading from ArubaOS 5.0
but did not yet have control plane security enabled before the upgrade , then you can use the strategies described in
to enable and configure control plane security feature.
If you upgrade a controller running ArubaOS 5.0.x to ArubaOS 6.0 or later, then the controller’s control plane security settings do not change after the upgrade. If control plane security was already enabled, then it remains enabled after the upgrade. If it was not enabled previously, but you want to use the feature after upgrading, then you must manually enable it.
Table 24: Control Plane Security Upgrade Strategies
Automatically send Certificates to Campus
APs
Manually Certify Campus APs
1. Access the control plane security window and enable both the control plane security feature and the auto certificate provisioning option. Next, specify whether you want all associated campus APs to automatically receive a certificate, or if you want to certify only those APs within a defined range of IP addresses.
2. Once all APs have received their certificates, disable auto certificate provisioning to prevent certificates from being issued to any rogue APs that may appear on your network at a later time.
1. Identify the campus APs that should receive certificates by entering the campus APs’ MAC addresses in the campus AP whitelist.
2. If your network includes both master and local controllers, wait a few minutes, then verify that the campus AP whitelist has been propagated to all other controllers on the network. Access the WebUI of the master controller, navigate to Configuration
> Controller > Control Plane Security , then verify that the Current Sequence Number field has the same value as the Sequence Number entry for each local controller in the local controller whitelist.
(For details, see
Verifying Whitelist Synchronization on page 76
.)
3. Enable the control plane security feature.
3. If a valid AP did not receive a certificate during the initial certificate distribution, you can manually certify the AP by adding that MAC address of the AP to the campus AP whitelist. You can also use this whitelist to revoke certificates from APs that should not be allowed access to the secure network.
If you upgraded your controller from ArubaOS 5.0 or earlier and you want to use this feature for the first time, you must either add all valid APs to the campus AP whitelist, or enable automatic certificate provisioning before you enable the feature . If you do not enable automatic certificate provisioning, only the APs currently approved in the campus AP whitelist are allowed to communicate with the controller over a secure channel. Any APs that do not receive a certificate will not be able to communicate with the controller except to request a certificate.
75 | Control Plane Security ArubaOS 6.5.3.x | User Guide
Troubleshooting Control Plane Security
Identifying Certificate Problems
If an AP has a problem with its certificate, check the state of the AP in the campus AP whitelist. If the AP is in either the certified-hold-factory-cert or certified-hold-switch-cert states, you may need to manually change the status of that AP before it can be certified.
n n certified-hold-factory-cert : An AP is put in this state when the controller thinks the AP has been certified with a factory certificate, but the AP requests to be certified again. Because this is not a normal condition, the AP is not approved as a secure AP until you manually change the status of the AP to verify that it is not compromised. If an AP is in this state due to connectivity problems, then the AP recovers and is taken out of this hold state as soon as connectivity is restored.
certified-hold-switch-cert : An AP is put in this state when the controller thinks the AP has been certified with a controller certificate yet the AP requests to be certified again. Because this is not a normal condition, the AP is not be approved as a secure AP until a network administrator manually changes the status of the
AP to verify that it is not compromised. If an AP is in this state due to connectivity problems, then the AP recovers and is taken out of this hold state as soon as connectivity is restored.
Disabling Control Plane Security
If you disable control plane security on a standalone or local controller, all APs connected to that controller reboot then reconnect to the controller over a clear channel.
If your disable control plane security on a master controller, APs directly connected to the master controller reboot then reconnect to the master controller over a clear channel. However, its local controllers continue to communicate with their APs over a secure channel until you save your configuration on the master controller.
Once you save the configuration, the changes are pushed down to the local controllers. At that point, any APs connected to the local controllers also reboot and reconnect over a clear channel.
Verifying Whitelist Synchronization
To verify that a network of master and local controllers are correctly sharing their campus AP whitelists, check the sequence numbers on the master and local controller whitelists.
n n
The sequence number value on a master controller should be the same as the remote sequence number on the local controller.
The sequence number value on a local controller should be the same as the remote sequence number on the master controller.
ArubaOS 6.5.3.x
| User Guide Control Plane Security | 76
Figure 8 Sequence numbers on Master and Local Controllers
Rogue APs
If you enable auto certificate provisioning enabled with the Auto Cert Allow All option, any AP that appears on the network receives a certificate. If you notice unwanted or rogue APs connecting to your controller via an
IPsec tunnel, verify that automatic certificate provisioning has been disabled, then manually remove the unwanted APs by deleting their entries from the campus AP whitelist.
77 | Control Plane Security ArubaOS 6.5.3.x | User Guide
Chapter 3
Software Licenses
ArubaOS supports a variety of optional add-on licenses that enhance the base OS, and provide advanced features including as wireless intrusion protection, advanced cryptography, policy-based traffic management and controls, web content classification and stateful user firewalls.
ArubaOS supports a centralized licensing architecture, which allows a group of connected controllers to share a pool of licenses. A primary and backup service controller can share a single set of licenses, eliminating the need for a redundant license set on the backup server. Local licensing client controllers maintain information sent from the licensing server, even if the licensing client controller and the licensing server controller can no longer communicate.
Getting Started with ArubaOS Licenses
This chapter describes ArubaOS license types and licensing features, and lists the procedures to configure a licensing solution.
Learn more about Licenses and Licensing Features
Select any of the links below to view detailed information about ArubaOS license types, licensing features and examples of deployment topologies that support these features.
n n n
License Types and Usage on page 78
Licensing Best Practices and Limitations on page 81
Centralized Licensing Overview on page 82
Configure a Licensing Management Solution
The following sections describe the procedures to configure centralized licensing clusters and licensing pools, and to add, remove, and monitor individual licenses.
n n n n
Configuring Centralized Licensing on page 88
Installing a License on page 90
Monitoring and Managing Centralized Licenses on page 93
License Types and Usage
Licenses are platform independent and can be installed on any controller. Installation of the feature license unlocks that feature’s functionality for the maximum capacity of the controller.
lists the license types, and describe how licenses are consumed on the Controllers.
ArubaOS 6.5.3.x
| User Guide Software Licenses | 78
Table 25: Usage per License
License
AP
Usage Basis
AP
ACR
CSS
PEFNG
PEFV
PoE
RFprotect xSec
WebCC
Client Session
Client Session
AP
Controller
Controller
AP
Client/session
AP
What Consumes One License
An AP license is required for each operational LAN-connected, mesh, or remote AP, or that is advertising at least one BSSID
(virtual-AP)
This license enables ArubaOS Advanced Cryptography (ACR) features. A license is required for each active client termination using Suite-B algorithms or protocols.
The Content Security Service (CSS) license provides cloud-based security for branch offices and teleworkers. This license is administered based on the number of clients using this service.
One operational AP using one or more Policy Enforcement Firewall
(PEF) features, such as intelligent application identification, policybased traffic management and controls, or stateful user firewalls.
The PEFV license allows a network administrator to apply firewall policies to clients using a VPN to connect to the controller. This license is mandatory for the Aruba VIA VPN client, but optional for all other VPN clients. The PEFV license is purchased as a single license that enables the functionality up to the full user capacity of the controller.
This license enables support for Power over Ethernet PoE. Each license enables PoE on a port on the controller.
An RFProtect license is required for each operational AP using one or more RF Protect features, such as spectrum analysis and wireless intrusion protection (WIP).
One active client termination using Extreme Security (xSec), a cryptographically secure, Layer-2 tunneling network protocol implemented over the 802.1X protocol.
The Web Content Classification (WebCC) license is a subscriptionbased, per-AP license that supports web content classification features on an AP for the duration of the subscription period (up to
10 years per license)
Sharable vs Controller-Specific Licenses
Many licenses are consumed on a per-AP or per-user basis. These license types can be shared by a group of controllers using the same centralized licensing server. The licenses that are specific to an individual controller cannot be shared among controllers via centralized licensing.
Table 26: Sharable Licenses vs Controller-Specific Licenses
Sharable via a Licensing Pool Controller-Specific License
AP
ACR
PEFNG
CSS
PEFV
PoE
79 | Software Licenses ArubaOS 6.5.3.x | User Guide
Sharable via a Licensing Pool
RF Protect xSec
WebCC
Controller-Specific License
Evaluation vs Permanent Licenses
Each license can be either an evaluation or permanent license. A permanent license permanently enables the desired software module on a specific Aruba controller. You obtain permanent licenses through the sales order process only. Permanent software license keys are sent to you via email. An evaluation license allows you to evaluate the unrestricted functionality of a software module on a specific controller for 90 days (in three 30day increments). An expired evaluation license will remain in the license database until the controller is reset using the command write erase all where all license keys are removed. An expired evaluation license has no impact on the normal operation of the controller, but it is kept in the license database to prevent abuse.
Evaluation licenses can be added on the services controller and made sharable within a licensing pool. When a sharable evaluation license is locally installed on a client controller, those license limits will be sent to the licensing server and added to the license pool as long as the evaluation period is active. When the evaluation period expires, the client with the expired license sends its revised limits to the license server. The licensing server removes the evaluation licenses from its license table, then sends updated license pool information to other clients on the network.
To determine your remaining time on an evaluation license, select the Alert flag ( )in the WebUI title bar. The
WebUI displays information about evaluation license status.
When an evaluation period expires: l
The controller automatically backs up the startup configuration and reboots itself at midnight (according to the system clock).
l
All permanent licenses are unaffected. The expired evaluation licensed feature is no longer available and is displayed as Expired in the WebUI.
Perpetual vs Subscription Licenses
A perpetual license is a purchased license that has no end date; once installed, it does not expire. Most purchased licenses are perpetual licenses. However, the Web Content and Classification (WebCC) license is a subscription license that enables WebCC features only for the duration of the subscription (1,3,5,7 or 10 years). The subscription time period starts from the time license key is generated from the licensing website.
Thirty days before the license period expires, an alert appears in the banner in the controller WebUI, warning the user that the license is ready to expire. After the license expiration date is passed, the license continues to operate as an active license for an extended grace period of 120 days. After this final grace period elapses, the license permanently expires.
Subscription licenses cannot be renewed, Once a license subscription expires, a new license subscription key must be generated and installed on the controller.
Starting with ArubaOS 6.5.1, if one or more subscription WebCC licenses expire so that a controller has fewer active WebCC subscription licenses than AP licenses, that controller will no longer be able to download WebCC updates from the cloud or perform classification using cloud lookup. The APs associated to that device can, however, continue to use the cached WebCC date currently on the controller. This has been changed from
ArubaOS 6.5.0, where an expired WebCC license did not impact AP or controller behavior.
ArubaOS 6.5.3.x
| User Guide Software Licenses | 80
Controller License Capacity
The controller licenses are variable-capacity (see
In
, the total AP count is a combination of Campus AP count and Remote AP count.
Table 27: Controller AP Capacity
Controller
7210
7220
7240
7240XM
7205
7030
7024
7010
7008
7005
Total AP Count
512
1024
2048
2048
256
64
32
32
16
16 n n n n n
Licensing Best Practices and Limitations
When calculating AP licenses, determine the normal AP load of your controller and add a backup load in case of failure. A reasonable estimate when calculating user licenses is 20 users per AP. Do not forget to consider occasional large assemblies or gatherings, and allow for the maximum quantity required at any given time.
All active APs run AP, PEFNG and RFProtect services (if enabled). If your controller does not have equal amounts of these licenses, the number of active APs are restricted to the lowest number of AP, PEFNG or
RFProtect licenses.
If a Mesh node is configured for client service (for example, it advertises a BSSID ), it consumes one AP license. Mesh nodes with no virtual APs do not consume an RFProtect license.
Back up the controller’s configuration ( backup flash command) and back up the license database ( license export filename ) before making any changes.
(host) # backup flash
Please wait while we tar relevant files from flash...
Please wait while we compress the tar file...
Checking for free space on flash...
Copying file to flash...
File flashbackup.tar.gz created successfully on flash.
Please copy it out of the switch and delete it when done.
(host) # license export licensebackup.db
Successfully exported 1 licenses from the License Database to licensebackup.db
Issuing the write erase all command resets the controller to factory default and deletes all databases on the controller, including the license key management database. You must reinstall all previously-installed license keys. Issuing the write erase command on a controller running software licenses does not affect
81 | Software Licenses ArubaOS 6.5.3.x | User Guide
n n the license key management database on the controller. Rebooting or resetting a controller has no effect on a license.
When you apply evaluation license keys on a controller, abnormal tampering of the device’s system clock
(such as setting back the system clock) results in the disabling of software licensed modules and their supported features. This can affect network services.
The Advanced Cryptography (ACR) license includes the following caveats: l l l l l
On a platform that supports 2048 IPsec tunnels, the maximum number of Suite B IPsec tunnels supported is 2048, even if a larger capacity license is installed.
ACR licenses are cumulative. For example, if you want to support 2048 Suite B connections, you can install two ACR licenses that support 1024 connections each.
If your controller uses an ACR license that allows fewer IPsec tunnels that is supported by that controller platform, that controller can still support IPsec tunnels using non-Suite B modes (for example, AES-CBC), up to the platform maximum.
The ACR license allows a controller to use both IPsec Suite B and 802.11i Suite B connections simultaneously. The combined number of these sessions may not exceed the ACR license maximum.
A single client using both 802.11i Suite B and IPsec Suite B connections will simultaneously consume two
ACR licenses.
ArubaOS provides the ability to move a license from one standalone controller to another, for maximum flexibility in managing an organization’s network and to minimize an RMA impact. Aruba monitors and detects license fraud.
Abnormally high volumes of license transfers for the same license certificate to multiple controllers can indicate a breach of the Aruba end user software license agreement and will be investigated.
Centralized Licensing Overview
In order to configure a license-dependent feature on the local controller, the master controller(s) must be licensed for each of the features configured on the local controllers. Centralized licensing simplifies licensing management by distributing licenses installed on one controller to other controllers on the network. One controller acts as a centralized license database for all other controllers connected to it, allowing all controllers to share a pool of unused licenses. The primary and backup licensing servers can share a single set of licenses, eliminating the need for a redundant license set on the backup server. Local licensing client controllers maintain information sent from the licensing server, even if the licensing client controller and the licensing server controller can no longer communicate. If an AP fails over from one client controller to another, the AP will be allowed to come up even if there aren’t sufficient licenses present on the backup controller. the APs continue to stay active until they reboot. However, if there are not sufficient available licenses to bring up an
AP after it reboots, that AP will not become active.
You can use the centralized licensing feature in a master-local topology with a redundant backup master, or in a multi-master network where all the masters can communicate with each other (for example, if they are all connected to a single AirWave server). In the master-local topology, the master controller acts as the primary licensing server, and the redundant backup master acts as the backup licensing server. In a multi-master network, one controller must be designated as a primary server, and a second controller must be configured as a backup licensing server.
Centralized licensing can distribute the following license types: n n n n n
AP
PEFNG
RFProtect xSec
ACR
ArubaOS 6.5.3.x
| User Guide Software Licenses | 82
This section includes the following topics: n n n n n
Primary and Backup Licensing Servers
Communication between the License Server and License Clients
Configuring Centralized Licensing
Primary and Backup Licensing Servers
Centralized licensing allows the primary and backup licensing server controllers to share a single set of licenses.
If you do not enable this feature, the master and backup master controller each require separate, identical license sets. The two controllers acting as primary and backup license servers must use the same version of
ArubaOS and must be connected on the same broadcast domain using the Virtual Router Redundancy Protocol
(VRRP). Other client controllers on the network connect to the licensing server using the VRRP virtual IP address configured for that set of redundant servers. The primary licensing server uses the configured virtual IP address by default. However, if the controller acting as the primary licensing server becomes unavailable, the secondary licensing server will take ownership of the virtual IP address, allowing licensing clients to retain seamless connectivity to a licensing server.
Only one backup licensing server can be defined for each primary server.
The example below shows a primary and backup license server connected using VRRP. Licenses installed on either the primary or backup server are shared between that pair of servers. If the primary and backup controllers each had 16 AP licenses, 16 PEFNG licenses, and 16 xSec licenses installed, they would share a combined pool of 32 AP, 32 PEFNG, and 32 xSec licenses. Any license client controllers connected to this pair of redundant servers could also use licenses from this license pool.
Figure 9 Shared Licenses on a Primary and Backup Licensing Server
83 | Software Licenses ArubaOS 6.5.3.x | User Guide
Communication between the License Server and License Clients
When you enable centralized licensing, information about the licenses already installed on the individual client controllers are sent to the licensing server, where they are added into the server’s licensing table. The information in this table is then shared with all client controllers as a pool of available licenses. When a client controller uses a license in the available pool, it communicates this change to the licensing server master controller, which updates the table before synchronizing it with the other clients.
Client controllers do not share information about built-in licenses to the licensing server. A controller using the centralized licensing feature will use its built-in licenses before it consumes available licenses from the license pool. As a result, when a client controller sends the licensing server information about the licenses that a client is using, it only reports licenses taken from the licensing pool, and disregards any built-in licenses used. For example, if a controller has a built-in 16-AP license and twenty connected APs, it will disregard the built-in licenses being used and report to the licensing server that it is using only four AP licenses from the license pool.
When centralized licensing is first enabled on the licensing server, its licensing table only contains information about the licenses installed on that server. When the clients contact the server, the licensing server adds the client licenses to the licensing table, then sends the clients information about the total available licenses for each license type. In the following example, the licenses installed on two client controllers are imported into the license table on the license server. The licensing server then shares the total number of available licenses with other controllers on the network.
Figure 10 Licenses Shared by Licensing Clients
When a new AP associates with a licensing client, the client sends updated licensing information to the server.
The licensing server then recalculates the available total, and sends the revised license count back to the clients.
If a client uses an AP license from the license pool, it also consumes a PEFNG and a RFProtect license from the pool, even if that AP has not enabled any features that would require that license. A controller cannot use more licenses than what is supported by its controller platform, regardless of how many licenses are available in the license pool.
ArubaOS 6.5.3.x
| User Guide Software Licenses | 84
Figure 11 License Pool Reflecting Used licenses
Supported Topologies
The following table describes the controller topologies supported by this feature.
85 | Software Licenses ArubaOS 6.5.3.x | User Guide
Table 28: Centralized Licensing Topologies
Topology
All controllers are master controllers .
The master and standby licensing servers must be defined.
Example
A single master controller is connected to one or more local controllers .
Only the master controller can be a license server. A local controller can only be license client, not a license server.
A master and standby master are connected to one or more local controllers .
The master license server will reside on the master controller, and the standby license server will reside on the standby master controller. Local controllers can only be license clients, not license servers.
ArubaOS 6.5.3.x
| User Guide Software Licenses | 86
Table 28: Centralized Licensing Topologies
Topology
A licensing server supports multiple master/local domains.
Starting with ArubaOS 6.5, the centralized licensing feature supports topologies where multiple master controllers have one or more attached local controllers.
NOTE: This topology requires that all local controllers are able to access the licensing server.
Example
A licensing server supports standalone and local licensing clients
Starting with ArubaOS 6.5.2, the centralized licensing feature supports topologies where a licensing master is connected to a standalone master licensing client controller, a standalone master redundant licensing server, and a local licensing client controller.
NOTE: This topology requires additional configuration steps to define the license server
IP address for the local controllers in this topology. For details, see
Multi-Version Licensing
ArubaOS supports multi-version licensing, which allows centralized licensing clients to run a different version of
ArubaOS than the primary and backup licensing servers. If a license is introduced in a newer version of
ArubaOS, the primary and backup licensing servers set can still distribute licenses to licensing clients running an older version of ArubaOS, even if the licensing client does not recognize the newer license type.
This feature is only supported in deployment topologies where all are configured as master controllers. Both the licensing server(s) and licensing clients must be running a version of that supports this feature. The multiversion licensing feature is not supported in a topology where a single licensing server or a pair of primary and backup licensing servers are connected to one or more local controllers.
Replacing a Controller
If you need to replace the controller acting as a license server, the keys installed on the previous license server must be regenerated and added to the new license server. If you need to replace a controller acting as license client, you must regenerate the license keys installed on the client and reinstall them on the replacement client or the licensing server.
Failover Behaviors
If the primary licensing server fails, the controller acting as a backup license server will retain the shared license limits until the backup server reboots. If both the primary and the backup license servers fail, or if the backup controller reboots before the primary controller comes back up, License clients will retain the license limits sent to them by the licensing server for 30 days.
87 | Software Licenses ArubaOS 6.5.3.x | User Guide
Although a client controller retains its licensing information for 30 days after it loses contact with the licensing server, if the client reboots at any time during this 30-day window, the window will restart, and the client will retain its information for another 30 days.
APs that use centralized licensing in conjunction with an ArubaOS high availability feature behave differently than APs that do not use a high availability solution. APs using VRRP redundancy, a backup LMS, or the
ArubaOS fast failover feature can quickly fail over to a backup controller, even if that backup controller does not have any AP licenses at the time of the failover. However, if that AP reboots, it will not obtain its licenses until the backup controller receives the required licenses from the licensing master.
Client is Unreachable
The centralized licensing feature sends keepalive heartbeats between the license server and the licensing client controllers every 30 seconds. If the licensing server fails to receive three consecutive heartbeats from a client, it assumes that the licensing client is down, and that any APs associated with that client are also down or have failed over to another controller . Therefore, the licensing server adds any licenses used by that client back into the available pool of licenses. If the license server fails to contact a license client for 30 consecutive days, any licenses individually installed on that client will be removed from the server’s license database.
The WebUI of the licensing client and the licensing server both display a warning message when a licensing client and licensing server are unable to communicate.
Server is Unreachable
If a licensing client does not receive three consecutive heartbeats from the server, it assumes that the server is down, and that any APs directly associated to the server are also down or have failed over to another controller. The client then adds any licenses used by the licensing server into to the pool of available licenses on that client. When a license client is unable to reach a license server for 30 consecutive days, it removes any shared licenses pushed to it from the licensing server, and reverts to its installed licenses. If the 30-day window has passed and the controller does not have enough installed licenses for all of its associated APs, the controller will nonetheless continue to support each AP. However, when an AP reboots and its controller does not have enough licenses, that AP will not come up.
For more information on replacing a controller using the centralized licensing feature, see
Replacing a Controller on page 47
Configuring Centralized Licensing
The steps to configure centralized licensing on your network vary, depending upon whether you are enabling this feature in a network with a master-local controller topology, or in a network where all controllers are configured as masters. Before you enable this feature, you must ensure that the controllers are able to properly communicate with the licensing master. Once you have identified your deployment type, follow the steps in the appropriate section below.
Pre-configuration Setup in an All-Master Deployment
Follow the steps described below to configure the centralized licensing feature in a network with all master controllers:
1. Ensure that the controllers using this feature are associated with the same AirWave server.
2. Identify a controller you want to designate as the primary licensing server. If that controller already has a redundant backup controller, that backup controller will automatically become the backup license server.
ArubaOS 6.5.3.x
| User Guide Software Licenses | 88
3. (Optional) If your primary licensing server does not yet have a dedicated, redundant backup controller and you want to use a backup server with the centralized licensing feature, you must identify a second controller to use as the backup licensing server, and create a virtual router on the primary licensing server.
4. (Optional) Establish secure IPsec tunnels between the primary licensing server controller and the licensing client controllers by enabling control plane security on that cluster of master controllers or by creating siteto-site VPN tunnels between the licensing server and client controllers. This step is not required, but if you do not create secure tunnels between the controllers, the controllers will exchange clear, unencrypted licensing information. This step is not required for a master-local topology.
Pre-configuration Setup in a Master/Local Topology
The master controller in a master-local topology is the primary licensing server by default. If this master controller already has a redundant standby master, that redundant master will automatically act as the backup licensing server with no additional configuration. If your primary licensing server does not yet have a redundant standby controller and you want to use a backup server with the centralized licensing feature, you must identify a second controller to designate as the backup licensing server and define a virtual router on the primary licensing server.
Enabling Centralized Licensing
The following steps describe the procedure to enable centralized licensing on both the licensing master and the licensing clients.
Using the WebUI
1. Access the WebUI of the primary licensing master controller, navigate to Configuration > Controller and select the Centralized Licenses tab.
2. Select Enable Centralized Licensing .
3. (Optional) If the licensing server already has a dedicated redundant standby controller, that standby controller will automatically become the backup license server. If the primary licensing server in your deployment does not have a dedicated, redundant master controller, but you want to define a backup server for the licensing feature, follow steps a-d below: a. Select the License Redundancy option.
b. In the VRRP ID field, enter the Virtual Router ID for the Virtual Router you configured in the
Preconfiguration Setup task in the section above.
c. In the Peer’s IP address field, enter the IP address of the backup licensing server.
d. In the License Server IP field, enter the virtual IP address for the Virtual Router used for license server redundancy.
4. Click Apply .
If you are deploying centralized licensing in a topology where a licensing master is connected to a standalone master licensing client controller, a redundant licensing server, and a local licensing client controller, you must also access the command-line interface and issue the command license server-ip vrrp-ip <ip-addr> to define a VRRP interface IP address as license server IP address for the local controllers in this topology.
If you are deploying centralized licensing on a cluster of master controllers, you must define the IP address that the licensing clients in the cluster use to access the licensing server.
5. Access the WebUI of a licensing client, navigate to Configuration > Controller and select the Centralized
Licenses tab.
6. Select Enable Centralized Licensing .
7. In the License Server IP field, enter the IP address the client will use to connect to the licensing server. If you have defined a backup licensing server using a virtual router ID, enter the IP address of that virtual router.
89 | Software Licenses ArubaOS 6.5.3.x | User Guide
8. Click Apply .
9. Repeat steps 5-8 on each licensing client in the cluster.
Using the CLI
Access the command-line interface of the licensing server, and issue the following commands in config mode:
(host)(config) #license profile
(host)(License provisioning profile) #centralized-licensing-enable
If the licensing server already has a dedicated redundant standby controller, that standby controller will automatically become the backup license server. If the primary licensing server in your deployment does not have a redundant master controller but you want to define a backup server for the licensing feature, issue the following commands on the licensing server:
(host)(License provisioning profile) #License server-redundancy
(host)(License provisioning profile) #License-vrrp <vrId>
(host)(License provisioning profile) #Peer-ip-address <ip>
If you are deploying centralized licensing in a topology where a licensing master is connected to a standalone master licensing client controller, a redundant licensing server, and a local licensing client controller, you must issue the command license server-ip vrrp-ip <ip-addr> to define a VRRP interface IP address as the license server IP address for the local controllers in this topology.
(host)(License provisioning profile)#License server-ip vrrp-ip <ip-addr>
If you are deploying centralized licensing on a cluster of master controllers, or in a topololgy with multiple master/local domains, access the command-line interface of a licensing client controller, and issue the following commands in config mode:
(host) (config) #license profile
(host) (License provisioning profile) #centralized-licensing-enable
(host) (License provisioning profile) #license server-ip <ip>
If a controller is designated as standby license server, it does not have the license-server-ip value configured.
Installing a License
The Aruba licensing system is controller-based. A license key is a unique alphanumerical string generated using the controller’s serial number and is valid only for that controller only. Licenses can be pre-installed at the factory so all licensed features are available upon initial setup. You can also install license features yourself.
It is recommended that you obtain a user account on the Aruba Software License Management website even if software license keys are preinstalled on your controller.
Enabling a New License on your Controller
The basic steps to installing and enabling a new license feature are listed below, along with references to sections in this document with more detailed information.
1. Obtain a valid Aruba software license from your sales account manager or authorized reseller (see
Requesting a Software License Through Email on page 91
).
2. Locate the system serial number of your controller (see
Locating the System Serial Number on page 91
).
3. Use your system’s serial number to obtain a software license key from the Aruba Software License
Management website: https://hpe.com/networking/support (see
Obtaining a Software License Key on page
4. Enter the software license key using one of the following procedures:
ArubaOS 6.5.3.x
| User Guide Software Licenses | 90
n n
Navigate to the Configuration > Network > Controller > System Settings page of the ArubaOS
WebUI and select the License tab .
Enter the software license key and click Apply (see
Software License Key in the WebUI on page 92 ).
Launch the License Wizard from the Configuration tab of the WebUI and click New . Enter the software license key in the space provided (see
Applying the Software License Key in the License Wizard on page
).
n
Use the license add command in the CLI.
5. Reload the controller to enable the license.
Enabling a New Flexible License on your Controller
1. Obtain a valid Aruba software license with flexible licensing support from your sales account manager or authorized reseller (see
Requesting a Software License Through Email on page 91 ). You will be able to
request a customized license count when ordering your license.
2. A single license certificate will be issued, containing the following information: l l
Part number (e.g., LIC-AP-FLEX)
Quantity (e.g., 450)
3. Follow steps 2–5 of
Enabling a New License on your Controller
to complete installation.
4. The new license limit will take effect immediately.
Requesting a Software License Through Email
To obtain either a permanent or a evaluation software license, contact your sales account manager or authorized reseller. The license details are provided via email with an attached text file. Use the text file to cut and paste the licensing information into the WebUI or command line.
Ensure that you have provided your sales person with a valid email address.
The email also includes: n n n
The orderable part number for the license
A description of the software module type and controller for which it is valid
A unique, 32-character alphanumerical string used to access the license management website, and when in conjunction with the serial number of your controller, generates a unique software license key
Locating the System Serial Number
Each controller has a unique serial number located at the rear of the controller chassis.
You can also find the serial numbers by navigating to the Controller > Inventory page on the WebUI or by executing the show inventory command in the CLI.
Obtaining a Software License Key
To obtain a software license key, you must log in to the Aruba License Management website. If you are a first time user, you can use the software license certificate ID number to log in and request a new user account. If you already have a user account, log in to the site with your login credentials.
Once logged in, you are presented with several options: n
Activate a certificate : Activate a new certificate and create the software license key that you will apply to your controller.
91 | Software Licenses ArubaOS 6.5.3.x | User Guide
n n n
Transfer a certificate : Transfer a software license certificate ID from one controller to another (for example, transferring licenses to a spare system).
Import preloaded certificates : For controllers with licenses pre-installed at the factory, transfer all software license certificate IDs used on the sales order to this user account.
List your certificates : View all currently available and active software license certificates for your account.
Creating a Software License Key
To create a software license key, you must log in to the Aruba License Management website at: https://hpe.com/networking/support
If you are a first time user of the licensing site, you can use the software license certificate ID number to log in and request a new user account. If you already have a user account, log in to the site with your login credentials.
1. Select Activate a Certificate.
2. Enter the certificate ID number and the system serial number of your controller.
3. Review the license agreement and select Yes to accept the agreement.
4. Click Activate it . A copy of the transaction and the software license key is emailed to you at the email address entered for your user account
The software license key is valid only for the system serial number for which you activated the certificate.
Applying the Software License Key in the WebUI
To enable the software module and functionality, you must apply the software license key to your controller.
1. Log in to your controller’s WebUI.
2. Navigate to the Configuration > Network > Controller > System Settings page and select the License tab.
3. Copy the software license key, from your email, and paste it into the Add New License Key field.
4. Click Add .
5. Reload the controller to enable the license.
Applying the Software License Key in the License Wizard
Log in to your controller’s WebUI.
1. Launch the License Wizard from the Configuration tab and click New .
2. The License Wizard helps walk you through the activation process. Click the Help tab within the License
Wizard for additional assistance.
Deleting a License
To remove a license from your system:
1. Navigate to the Configuration > Network > Controller > System Settings page and select the License tab.
2. Scroll down to the License Table and locate the license you want to delete.
3. Click Delete at the far right hand side of the license to delete the license.
If a license feature is under an evaluation license, it will not generate a key when the feature is deleted.
ArubaOS 6.5.3.x
| User Guide Software Licenses | 92
Monitoring and Managing Centralized Licenses
A centralized licensing server displays a wide variety of licensing data that you can use to monitor licenses and license usage. The tables described below are available on the Network > Controller > Centralized License
Management > Information page of the Licensing server WebUI.
License Server Table
This table displays information about the different types of licenses in the license table, and how many total licenses of each type are available and used. This table includes the following information:
Table 29: License Server Table Data
Column Description
Service Type Type of license on the licensing server.
Number of licenses in the licensing table on the licensing server.
Aggregate Licenses
Used Licenses
Remaining Licenses
Total number of licenses of each license type reported as used by the licensing clients or licensing server.
Total number of remaining licenses available in the licensing table.
License Client Table
This table displays centralized license limits applied to each licensing client. This table includes the following information:
Table 30: License Client Table Data
Column Description
Service Type Type of license on the licensing client.
System Limit
Server Licenses
Used Licenses
Contributed Licenses
Remaining Licenses
The maximum number of licenses supported by the controller platform.
Number of licenses sent from the licensing server.
NOTE: This number is limited by the total license capacity of the controller platform. A controller cannot use more licenses than is supported by that controller platform, even if additional license are available.
Total number of licenses of each license type used by the licensing client controller.
Total number of licenses of each license type contributed by the licensing client controller.
Total number of remaining licensing available on this controller. This number is also limited by the total license capacity of the controller platform.
License Client(s) Usage Table
This table displays information about the different types of licenses in the license table, and how many total licenses of each type are available and used.
93 | Software Licenses ArubaOS 6.5.3.x | User Guide
Table 31: License Clients(s) Usage Table Data
Column Description
Hostname
Name of the licensing client controller.
IP address of the licensing client controller.
IP Address
AP
PEF
RF Protect xSec Module
Total number of AP licenses used by a licensing client associated with this controller.
Total number of Policy Enforcement Firewall (PEF) licenses used by a licensing client associated with this controller.
Total number of RFProtect licenses used by a licensing client associated with this controller.
Total number of Extreme Security (xSec) licenses used by a licensing client associated with this controller.
ACR Total number of advanced Cryptography (ACR) licenses used by a licensing client associated with this controller.
Last update (secs. ago) Time, in seconds, that has elapsed since the licensing client received a heartbeat response.
Aggregate License Table
This command is issued from the command-line interface of the centralized licensing server controller to view license limits sent by licensing clients.
Table 32: Aggregate License Table Data
Column Description
Hostname Name of the licensing client controller.
IP address of the licensing client controller.
IP Address
AP
PEF
RF Protect xSec Module
Total number of AP licenses sent from licensing clients associated with this controller.
Total number of Policy Enforcement Firewall (PEF) licenses sent from licensing clients associated with this controller.
Total number of RFProtect licenses sent from licensing clients associated with this controller.
Total number of Extreme Security (xSec) licenses sent from licensing clients associated with this controller.
ACR Total number of advanced Cryptography (ACR) licenses sent from licensing clients associated with this controller.
License Heartbeat Table
This table displays the license heartbeat statistics between the license server and the license client.
ArubaOS 6.5.3.x
| User Guide Software Licenses | 94
Table 33: License Heartbeat Table Data
Column Description
IP address
HB Req
HB Resp
Total Missed
Last Update
IP address of the licensing client.
Heartbeat requests sent from the licensing client.
Heartbeat responses received from the license server.
Total number of heartbeats that were not received by the licensing client.
Number of seconds elapsed since the licensing client last sent a heartbeat request.
95 | Software Licenses ArubaOS 6.5.3.x | User Guide
Chapter 4
Network Configuration Parameters
The following topics in this chapter describe some basic network configuration steps that must be performed on the controller: n n n n n n n n n
Campus WLAN Workflow on page 96
Configuring Static Routes on page 112
Configuring the Loopback IP Address on page 112
Configuring the Controller IP Address on page 113
Configuring GRE Tunnels on page 114
Jumbo Frame Support on page 126
Campus WLAN Workflow
The following workflow lists the tasks to configure a campus WLAN, with a signal SSID, that uses 802.1X
authentication. Click any of the links below for details on the configuration procedures for that task.
Using the WebUI
1.
Configure your authentication servers.
2.
Create an authentication server group,
and assign the authentication servers you configured in step 1 to that server group.
3.
Configure a firewall access policy
for a group of users
4.
and assign the firewall access policy you created in step 3 to that user role.
5.
a. Assign the user role defined in step 4 to the AAA profile's 802.1X Authentication Default Role b. Associate the server group you created in step 2 to the AAA profile.
6.
7.
Create a new virtual AP profile.
8.
Associate the virtual AP profile
to the AAA profile you created in Step 5.
9.
Associate the virtual AP profile
to the SSID profile you created in Step 6.
Using the CLI
The example below follows the suggested order of steps to configure a virtual AP using the command-line interface.
(host)(config) #aaa server-group "THR-DOT1X-SERVER-GROUP-WPA2" auth-server Internal
!
ip access-list session THR-POLICY-NAME-WPA2 user any any permit
!
(host)(config) #user-role THR-ROLE-NAME-WPA2 session-acl THR-POLICY-NAME-WPA2
ArubaOS 6.5.3.x
| User Guide Network Configuration Parameters | 96
!
(host)(config) #aaa server-group "THR-DOT1X-SERVER-GROUP-WPA2" auth-server Internal
!
(host)(config) #aaa profile "THR-AAA-PROFILE-WPA2" dot1x-default-role "THR-ROLE-NAME-WPA2" dot1x-server-group "THR-DOT1X-SERVER-GROUP-WPA2"
!
(host)(config) #wlan ssid-profile "THR-SSID-PROFILE-WPA2" essid "THR-WPA2" opmode wpa2-aes
!
(host)(config) #wlan virtual-ap "THR-VIRTUAL-AP-PROFILE-WPA2" ssid-profile "THR-SSID-PROFILE-WPA2" aaa-profile "THR-AAA-PROFILE-WPA2" vlan 60
!
(host)(config) #ap-group "THRHQ1-STANDARD" virtual-ap "THR-VIRTUAL-AP-PROFILE-WPA2"
Understanding VLAN Assignments
A client is assigned to a VLAN by one of several methods, in order of precedence. The assignment of VLANs are
(from lowest to highest precedence):
1. The default VLAN is the VLAN configured for the WLAN (see
Virtual AP Profiles on page 418
).
2. Before client authentication, the VLAN can be derived from rules based on client attributes (SSID, BSSID, client MAC, location, and encryption type). A rule that derives a specific VLAN takes precedence over a rule that derives a user role that may have a VLAN configured for it.
3. After client authentication, the VLAN can be configured for a default role for an authentication method, such as 802.1X or VPN.
4. After client authentication, the VLAN can be derived from attributes returned by the authentication server
( server-derived rule ). A rule that derives a specific VLAN takes precedence over a rule that derives a user role that may have a VLAN configured for it.
5. After client authentication, the VLAN can be derived from Microsoft Tunnel attributes (Tunnel-Type, Tunnel
Medium Type, and Tunnel Private Group ID). All three attributes must be present as shown below. This does not require a server-derived rule. For example:
Tunnel-Type="VLAN"(13)
Tunnel-Medium-Type="IEEE-802" (6)
Tunnel-Private-Group-Id="101"
6. After client authentication, the VLAN can be derived from Vendor Specific Attributes (VSA) for RADIUS server authentication. This does not require a server-derived rule. If a VSA is present, it overrides any previous VLAN assignment. For example:
Aruba-User-VLAN
Aruba-Named-User-VLAN
VLAN Derivation Priorities for VLAN types
The VLAN derivation priorities for VLAN is defined below in the increasing order:
1. Default or Virtual AP VLAN
2. VLAN from Initial role
3. VLAN from User Derivation Rule (UDR) role
4. VLAN from UDR
5. VLAN from DHCP option 77 UDR role (wired clients)
97 | Network Configuration Parameters ArubaOS 6.5.3.x | User Guide
6. VLAN from DHCP option 77 UDR (wired clients)
7. VLAN from MAC-based Authentication default role
8. VLAN from Server Derivation Rule (SDR) role during MAC-based Authentication
9. VLAN from SDR during MAC-based Authentication
10.VLAN from Vendor Specific Attributes (VSA) role during MAC-based Authentication
11.VLAN from VSA during MAC-based Authentication
12.VLAN from Microsoft Tunnel attributes during MAC-based Authentication
13.VLAN from 802.1X default role
14.VLAN from SDR role during 802.1X
15.VLAN from SDR during 802.1X
16.VLAN from VSA role during 802.1X
17.VLAN from VSA during 802.1X
18.VLAN from Microsoft Tunnel attributes during 802.1X
19.VLAN from DHCP options role
20.VLAN from DHCP options
A VLAN from DHCP options has highest priority for VLAN derivation. Note, however, that DHCP options are not considered for derivation if the Aruba VSA ARUBA_NO_DHCP_FINGERPRINT (14) was sent for the user.
Use the following command to display user VLAN derivation related debug information:
(host) #show aaa debug vlan user [ip | ipv6 | mac]
How a VLAN Obtains an IP Address
A VLAN on the controller obtains its IP address in one of the following ways: n n
You can manually configure it. This is the default method and is described in
Assigning a Static Address to a
VLAN on page 98 . At least one VLAN on the controller must be assigned a static IP address.
Dynamically assigned from a Dynamic Host Configuration Protocol (DHCP) or Point-to-Point Protocol over
Ethernet (PPPoE) server.
Assigning a Static Address to a VLAN
You can manually assign a static IP address to a VLAN on the controller. At least one VLAN on the controller a static IP address.
In the WebUI
1. Navigate to the Configuration > Network > IP > IP Interfaces page on the WebUI. Click Edit for the
VLAN you just added.
2. Select the Use the following IP address option. Enter the IP address and network mask of the VLAN interface. If required, you can also configure the address of the DHCP server for the VLAN by clicking Add .
3. Click Apply .
In the CLI
(host)(config) #interface vlan < id> ip address < address> < netmask>
ArubaOS 6.5.3.x
| User Guide Network Configuration Parameters | 98
Configuring a VLAN to Receive a Dynamic Address
In a branch office, you can connect a controller to an uplink switch or server that dynamically assigns IP addresses to connected devices. For example, you can connect the controller to a DSL or cable modem, or a broadband remote access server (BRAS). The following figure shows a branch office where a controller connects to a cable modem. VLAN 1 has a static IP address, while VLAN 2 has a dynamic IP address assigned via
DHCP or PPPoE from the uplink device.
Figure 12 IP Address Assignment to VLAN via DHCP or PPPoE
Configuring Multiple Wired Uplink Interfaces (Active-Standby)
You can assign up to four VLAN interfaces to operate in active-standby topology. An active-standby topology provides redundancy so that when an active interface fails, the user traffic can failover to the standby interface.
To allow the controller to obtain a dynamic IP address for a VLAN, enable the DHCP or PPPoE client on the controller for the VLAN.
The following restrictions apply when enabling the DHCP or PPPoE client on the controller: n n n
You can enable the DHCP/PPPoE client multiple uplink VLAN interfaces (up to four) on the controller; these
VLANs cannot be VLAN 1.
Only one port in the VLAN can be connected to the modem or uplink switch.
At least one interface in the VLAN must be in the up state before the DHCP/PPPoE client requests an IP address from the server.
Enabling the DHCP Client
The DHCP server assigns an IP address for a specified amount of time called a lease. The controller automatically renews the lease before it expires. When you shut down the VLAN, the DHCP lease is released.
In the WebUI
1. Navigate to the Configuration > Network > IP > IP Interfaces page.
2. Click Edit for a previously-created VLAN.
3. Select Obtain an IP address from DHCP .
4. Enter a priority value for the VLAN ID in the Uplink Priority field. All wired uplink interfaces have the same priority by default. If you want to use an active-standby topology, then prioritize each uplink interfaces by entering a different priority value (1– 4) for each uplink interface.
99 | Network Configuration Parameters ArubaOS 6.5.3.x | User Guide
Figure 13 Assigning VLAN Uplink Priority—Active-Standby Configuration
5. Click Apply .
In the CLI
In this example, the DHCP client has the client ID name myclient , and the interface VLAN 62 has an uplink priority of 2:
(host)(config) #interface vlan 62
(host)(config) #uplink wired vlan 62 priority 2
(host)(config) #interface vlan 62 ip address dhcp-client client-id myclient
Enabling the PPPoE Client
To authenticate the BRAS and request a dynamic IP address, the controller must have the following configured: n n
PPPoE user name and password to connect to the DSL network
PPPoE service name: either an ISP name or a class of service configured on the PPPoE server
When you shut down the VLAN, the PPPoE session terminates.
In the WebUI
1. Navigate to the Configuration > Network > IP > IP Interfaces page.
2. Click Edit for a previously-created VLAN.
3. Select Obtain an IP address with PPPoE.
4. Enter the service name, username, and password for the PPPoE session.
5. Enter a priority value for the VLAN ID in the Uplink Priority field. All wired uplink interfaces have the same priority by default. If you want to use an active-standby topology, then prioritize each uplink interfaces by entering a different priority value (1– 4) for each uplink interface.
6. Click Apply.
ArubaOS 6.5.3.x
| User Guide Network Configuration Parameters | 100
In the CLI
In this example, a PPoE service name, username, and password are assigned, and the interface VLAN 14 has an uplink priority of 3:
(host)(config) #interface vlan 14 ip address pppoe
(host)(config) #interface vlan 14 ip pppoe-service-name < service_name >
(host)(config) #interface vlan 14 ip pppoe-username < username >
(host)(config) #interface vlan 14 ip pppoe-password *****
(host)(config) #uplink wired vlan 14 priority 3
Default Gateway from DHCP/PPPoE
You can specify that the router IP address obtained from the DHCP or PPPoE server be used as the default gateway for the controller.
In the WebUI
1. Navigate to the Configuration > Network > IP > IP Routes & DNS page.
2. For Default Gateway, you can select the following: l l l
DHCP - Use DHCP when available to obtain default gateway.
PPPoE - Use PPPOE when available to obtain default gateway.
Cellular - Use Cell interface when available to obtain default gateway.
3. Click Apply .
In the CLI
(host) (config) #ip default-gateway import
Configuring DNS/WINS Server from DHPC/PPPoE
The DHCP or PPPoE server can also provide the IP address of a DNS server or NetBIOS name server, which can be passed to wireless clients through the controller’s internal DHCP server.
For example, the following configures the DHCP server on the controller to assign addresses to authenticated employees; the IP address of the DNS server obtained by the controller via DHCP/PPPoE is provided to clients along with their IP address.
In the WebUI
1. Navigate to the Configuration > Network > IP > DHCP Server page.
2. Select Enable DCHP Server .
3. Under Pool Configuration, select Add .
4. For Pool Name, enter employee-pool.
5. For Default Router, enter 10.1.1.254.
6. For DNS Servers, select Import from DHCP/PPPoE .
7. For WINS Servers, select Import from DHCP/PPPoE .
8. For Network, enter 10.1.1.0 for IP Address and 255.255.255.0 for Netmask.
9. Click Done .
In the CLI
Use the following commands:
(host)(config) #ip dhcp pool employee-pool default-router 10.1.1.254
101 | Network Configuration Parameters ArubaOS 6.5.3.x | User Guide
dns-server import netbios-name-server import network 10.1.1.0 255.255.255.0
Configuring Source NAT to Dynamic VLAN Address
When a VLAN interface obtains an IP address through DHCP or PPPoE, a NAT pool (dynamic-srcnat) and a session ACL (dynamic-session-acl) are automatically created which reference the dynamically-assigned IP addresses. This allows you to configure policies that map private local addresses to the public address(es) provided to the DHCP or PPPoE client. Whenever the IP address on the VLAN changes, the dynamic NAT pool address also changes to match the new address.
For example, the following rules for a guest policy deny traffic to internal network addresses. Traffic to other
(external) destinations are source NATed to the IP address of the DHCP/PPPoE client on the controller.
In the WebUI
1. Navigate to the Configuration > Security > Access Control > Policies page. Click Add to add the policy guest .
2. To add a rule, click Add .
a. For Source, select any .
b. For Destination, select network and enter 10.1.0.0
for Host IP and 255.255.0.0
for Mask.
c. For Service, select any .
d. For Action, select reject .
e. Click Add .
3. To add another rule, click Add.
a. Leave Source, Destination, and Service as any.
b. For Action, select src-nat .
c. For NAT Pool, select dynamic-srcnat .
d. Click Add .
4. Click Apply.
In the CLI
Use the following commands:
(host)(config) #ip access-list session guest any network 10.1.0.0 255.255.0.0 any deny any any any src-nat pool dynamic-srcnat
Configuring Source NAT for VLAN Interfaces
The example configuration in the previous section illustrates how to configure source NAT using a policy that is applied to a user role. You can also enable source NAT for a VLAN interface to perform NAT on the source address for all traffic that exits the VLAN.
Starting with ArubaOS 6.4.4, all outbound traffic now can enable NAT with the IP address of the VLAN interface as the source address; while the locally routed traffic is sent without any address translation.
Traditionally, ArubaOS supported only IP NAT Inside feature where traffic performs NAT with the desired IP address of the VLAN interface as the source address which was useful for only traffic going out of uplink VLAN interface. However, for traffic which needed local routing was also going through unnecessary address translation. Now, this feature resolves this issue by allowing only outbound traffic to perform NAT.
ArubaOS 6.5.3.x
| User Guide Network Configuration Parameters | 102
Do not enable the NAT translation for inbound traffic option for VLAN 1, as this will prevent IPsec connectivity between the controller and its IPsec peers.
Sample Configuration
In the following example, the controller operates within an enterprise network. VLAN 1 is the outside VLAN, and traffic from VLAN 6 is source NATed using the IP address of the controller. The IP address assigned to
VLAN 1 is used as the controller’s IP address; thus traffic from VLAN 6 would be source NATed to 66.1.131.5:
Figure 14 Example: Source NAT using Controller IP Address
In the WebUI
1. Navigate to the Configuration > Network > VLANs page. Click Add a VLAN to configure VLAN 6 (VLAN 1 is configured through the Initial Setup).
a. Enter 6 for the VLAN ID.
b. Click Apply .
2. Navigate to the Configuration > Network > IP > IP Interfaces page.
3. Click Edit for VLAN 6: a. Select Use the following IP address .
b. Enter 192.168.2.1
for the IP Address and 255.255.255.0
for the Net Mask.
c. Select the Enable source NAT inside for this VLAN checkbox.
d. Click Apply .
4. Click Edit for VLAN 1: a. Select Use the following IP address .
b. Enter 66.1.131.5
for the IP Address and 255.255.255.0
for the Net Mask.
c. Select the Enable source NAT outside for this VLAN checkbox.
5. Click Apply .
In the CLI
Use the following commands:
(host)(config) #interface vlan 1 ip address 66.1.131.5 255.255.255.0
(host)(config) #interface vlan 6
(host)(config) #ip address 192.168.2.1 255.255.255.0
ip nat inside ip default-gateway 66.1.131.1
(host)(config) #interface vlan 1 ip address 66.1.131.5 255.255.255.0
103 | Network Configuration Parameters ArubaOS 6.5.3.x | User Guide
ip nat outside
Inter-VLAN Routing
On the controller, you can map a VLAN to a layer-3 subnetwork by assigning a static IP address and a netmask, or by configuring a DHCP or PPPoE server to provide a dynamic IP address and netmask to the VLAN interface.
The controller, acting as a layer-3 switch, routes traffic between VLANs that are mapped to IP subnetworks; this forwarding is enabled by default.
In
, VLAN 200 and VLAN 300 are assigned the IP addresses 2.1.1.1/24 and 3.1.1.1/24, respectively.
Client A in VLAN 200 is able to access server B in VLAN 300 and vice-versa, provided that there is no firewall rule configured on the controller to prevent the flow of traffic between the VLANs.
Figure 15 Default Inter-VLAN Routing
You can optionally disable layer-3 traffic forwarding to or from a specified VLAN. When you disable layer-3 forwarding on a VLAN, the following restrictions apply: n n
Clients on the restricted VLAN can ping each other, but cannot ping the VLAN interface on the controller.
Forwarding of inter-VLAN traffic is blocked.
IP mobility does not work when a mobile client roams to the restricted VLAN. You must ensure that a mobile client on a restricted VLAN is not allowed to roam to a non-restricted VLAN. For example, a mobile client on a guest VLAN will not be able to roam to a corporate VLAN.
To disable layer-3 forwarding for a VLAN configured on the controller:
In the WebUI
1. Navigate to the Configuration > Network > IP > IP Interface page.
2. Click Edit for the VLAN for which routing is to be restricted.
3. Configure the VLAN to either obtain an IP address dynamically (via DHCP or PPPoE) or to use a static IP address and netmask.
4. Deselect (uncheck) the Enable Inter-VLAN Routing checkbox.
5. Click Apply .
In the CLI
Use the following commands:
(host)(config) #interface vlan <id>
ip address {<ipaddr> <netmask>|dhcp-client|pppoe}
no ip routing
ArubaOS 6.5.3.x
| User Guide Network Configuration Parameters | 104
Configuring VLANs
The controller operates as a layer-2 switch that uses a VLAN as a broadcast domain. As a layer-2 switch, the controller requires an external router to route traffic between VLANs. The controller can also operate as a layer-
3 switch that can route traffic between VLANs defined on the controller.
You can configure one or more physical ports on the controller to be members of a VLAN. Additionally, each wireless client association constitutes a connection to a virtual port on the controller , with membership in a specified VLAN. You can place all authenticated wireless users into a single VLAN or into different VLANs, depending upon your network. VLANs can remain inside the controller, or they can extend outside the controller through 802.1q VLAN tagging.
You can optionally configure an IP address and netmask for a VLAN on the controller. The IP address is up when at least one physical port in the VLAN is up. The VLAN IP address can be used as a gateway by external devices; packets directed to a VLAN IP address that are not destined for the controller are forwarded according to the controller’s IP routing table.
Creating and Updating VLANs
You can create and update a single VLAN or bulk VLANs.
In the WebUI
1. Navigate to the Configuration > Network > VLANs page.
2. Click Add a VLAN to create a new VLAN. (To edit an existing VLAN, click Edit for the VLAN entry.) See
Creating Bulk VLANs In the WebUI on page 105
to create a range of VLANs.
3. In the VLAN ID field, enter a valid VLAN ID. (Valid values are from 1 to 4094, inclusive).
4. To add physical ports to the VLAN, select Port . To associate the VLAN with specific port-channels, select
Port-Channel .
5. (Optional) Click the Wired AAA Profile drop-down list to assign an AAA profile to a VLAN. This wired AAA profile enables role-based access for wired clients connected to an untrusted VLAN or port on the controller.
Note that this profile will only take effect if the VLAN or port on the controller is untrusted. If you do not assign a wired AAA profile to the VLAN, the global wired AAA profile applies to traffic from untrusted wired ports.
6. If you selected Port in step 4, select the ports you want to associate with the VLAN from the Port
Selection window.
or
If you selected Port-Channel in step 4, click the Port-Channel ID drop-down list, select the specific channel number you want to associate with the VLAN, then select the ports from the Port Selection window.
7. Click Apply .
In the CLI
Use the following commands:
(host)(config) #vlan <id>
(host)(config) #interface fastethernet|gigabitethernet <slot>/<module>/<port>
(host)(config-if) #switchport access vlan <id>
Creating Bulk VLANs In the WebUI
1. To add multiple VLANs at one time, click Add Bulk VLANs .
105 | Network Configuration Parameters ArubaOS 6.5.3.x | User Guide
2. In the VLAN Range pop-up window, enter a range of VLANs you want to create at once. For example, to add VLAN IDs numbered 200-300 and 302-350, enter 200-300, 302-350.
3. Click OK .
4. To add physical ports to a VLAN, click Edit next to the VLAN you want to configure and click the port in the
Port Selection section.
5. Click Apply .
In the CLI
Use the following commands:
(host)(config) #vlan
(host)(config) #vlan range 200-300,302-350
Creating a Named VLAN
You can create, update, and delete a named VLAN. Each named VLAN has a name and needs to have one or more VLANs assigned to it. The following configurations create a named VLAN called mygroup . It has the assignment type Even , and VLAN IDs 2, 4 and 12 are assigned to this named VLAN.
ArubaOS supports maximum of 256 VLANs per named VLAN.
In the WebUI
1. Navigate to Configuration > Network > VLANs.
2. Select the VLAN Pool tab to open the VLAN Pool window.
3. Click Add .
4. In the VLAN Name field, enter a name that identifies this named VLAN.
5. In the Assignment Type field, select Hash or Even from the drop-down list. See
Even and Hash Assignment Types on page 106
for information and conditions regarding Hash and Even assignment types.
The Even named VLAN assignment type is only supported in tunnel and decrypt-tunnel modes. It is not supported in split or bridge modes. It is not allowed for named VLANs that are configured directly under a virtual AP (VAP). It must only be used under named VLANs. L2 Mobility is not compatible with the existing implementation of the Even named
VLAN assignment type.
6. In the List of VLAN IDs field, enter the VLAN IDs you want to add to this pool. If you know the ID, enter each ID separated by a comma. You can also click the drop-down list to view the IDs, then select a VLAN ID to add it to the pool.
VLAN pooling should not be used with static IP addresses.
7. You must add a VLAN ID to create a named VLAN.
8. When you finish adding all the IDs, click Add . The VLAN name along with assignment type and VLAN IDs appears on the VLAN Pool window.
9. Click Apply .
10.At the top of the window, click Save Configuration .
Distinguishing Between Even and Hash Assignment Types
The VLAN assignment type determines how the controller handles a VLAN assignment.
ArubaOS 6.5.3.x
| User Guide Network Configuration Parameters | 106
The Hash assignment type means that the VLAN assignment is based on the station MAC address. The Even assignment type is based on an even distribution of named VLAN assignments.
The Even named VLAN assignment type maintains a dynamic latest usage level of each VLAN ID in the named
VLAN . Therefore, as users age out, the number of available addresses increases. This leads to a more even distribution of addresses.
The Even type is only supported in tunnel and decrypt-tunnel modes. It is not supported in split or bridge modes and it is not allowed for named VLAN that are configured directly under a virtual AP. It can only be used under named VLANs.
If a named VLAN is given an Even assignment and is assigned to user roles, user rules, VSA, or server derivation rules, then while applying VLAN derivation for the client “on run time,” the Even assignment is ignored and the
Hash assignment is applied with a message displaying this change.
L2 Mobility is not compatible with the existing implementation of the Even named VLAN assignment type.
Updating a Named VLAN
1. On the VLAN Pool window, click Modify next to the VLAN name you want to edit.
2. Modify the assignment type and the list of VLAN IDs. Note that you can not modify the VLAN name.
3. Click Update .
4. Click Apply .
5. At the top of the window, click Save Configuration.
Deleting a Named VLAN
1. On the VLAN Pool window, click Delete next to the VLAN name you want to delete. A prompt appears.
2. Click OK .
3. Click Apply .
4. At the top of the window, click Save Configuration .
Creating a Named VLAN Using the CLI
Named VLAN should not be used with static IP addresses.
The following example creates named VLAN called mygroup that has assignment type even .
(host)(config) #vlan-name mygroup assignment even
Viewing and Adding VLAN IDs Using the CLI
The following example shows how to view VLAN IDs in a named VLAN:
(host)(config) #show vlan
The following example shows how to add existing VLAN IDs to a named VLAN:
(host)(config) #vlan-name mygroup
(host)(config) #vlan mygroup 2,4,12
To confirm the named VLAN mappings assignments, use the following command:
(host)(config) #show vlan mapping
Role Derivation for Named VLAN Pools
You can configure Named VLANs under user rule, server derivation, user derivation, and VSA in this release.
107 | Network Configuration Parameters ArubaOS 6.5.3.x | User Guide
You cannot modify a VLAN name, so choose the name carefully.
Named VLANs (single VLAN IDs or multiple VLAN IDs) can only be assigned to tunnel mode VAP’s and wired profiles. They can also be assigned to user roles, user rule derivation, server derivation, and VSA for tunnel and bridge mode.
For tunnel mode, named VLANs that have the assignment type “hash” and “even” are supported.
For bridge mode only, named VLANs with the assignment type “hash” are supported. If a named VLAN with
“even” assignment is assigned to a user rule, user role, server derivation or VSA, than the “hash” assignment is applied and the following error message displays:
"named VLAN assignment type EVEN not supported for bridge. Applying HASH algorithm to retrieve vlan-id"
L2 roaming is not supported with an even VLAN assignment.
In the CLI
To apply a named VLAN in a user rule, use the following CLI commands:
(host)(config) #aaa derivation-rules
(host)(config) #aaa derivation-rules user <string>
(host)(config) #aaa derivation-rules user test-user-rule
(host)(user-rule) #set vlan
To apply a named VLAN in a user role, use the following CLI commands:
(host)(config) #user-role test-vlan-name
(user)(config-role) #vlan test-vlan
To apply a named VLAN in server derivation, use the following CLI commands:
(host)(config) #aaa server-group test-vlan-server-group
(user)(Server Group "test-vlan-server-group") set vlan
For a named VLAN derivation using VSA, configure the RADIUS server using these values:
Aruba-Named-UserVLAN 9 String Aruba 14823
In the WebUI
To apply a named VLAN in a user rule, navigate to the WebUI page:
Security > Authentication > User Rules
To apply a named VLAN in a user role, navigate to the WebUI page:
Security > Access Control > User Roles > Add or Edit Role
To apply a named VLAN in a server derivation (server group), navigate to the WebUI page:
Security > Authentication> Servers > Server Group > <server-group_name> >Server Rules
Adding a Bandwidth Contract to the VLAN
Bandwidth contracts on a VLAN can limit broadcast and multicast traffic. ArubaOS includes an internal exception list to allow broadcast and multicast traffic using the VRRP, LACP, OSPF, PVST, and STP protocols. To remove per-VLAN bandwidth contract limits on an additional broadcast or multicast protocol, add the MAC address for that broadcast/multicast protocol to the VLAN Bandwidth Contracts MAC Exception List.
The command in the example below adds the MAC address for CDP (Cisco Discovery Protocol) and VTP (Virtual
Trunking Protocol to the list of protocols that are not limited by VLAN bandwidth contracts.
(host)(config) #vlan-bwcontract-explist mac 01:00:0C:CC:CC:CC
ArubaOS 6.5.3.x
| User Guide Network Configuration Parameters | 108
To show entries in the VLAN bandwidth contracts MAC exception list execute the following command:
(host)(config) #show vlan-bwcontract-explist internal
Optimizing VLAN Broadcast and Multicast Traffic
Broadcast and Multicast (BCMC) traffic from APs, remote APs, or distributions terminating on the same VLAN floods all VLAN member ports. This causes critical bandwidth wastage, especially when the APs are connected to an L3 cloud where the available bandwidth is limited or expensive. Suppressing the VLAN BCMC traffic to prevent flooding can result in loss of client connectivity.
To effectively prevent flooding of BCMC traffic on all VLAN member ports, use the bcmc-optimization parameter under the interface vlan command. This parameter ensures controlled flooding of BCMC traffic without compromising the client connectivity. This option is disabled by default. You must enable this parameter for the controlled flooding of BCMC traffic.
If you enable BCMC Optimization on uplink ports, the controller-generated Layer-2 packets will be dropped.
The bcmc-optimization parameter has the following exemptions: n n
All DHCP traffic will continue to flood VLAN member ports even if you enable the bcmc-optimization parameter.
ARP broadcasts and VRRP (multicast) traffic will still be allowed.
You can configure BCMC optimization using the WebUI or CLI.
In the WebUI
1. Navigate to Configuration > Network > IP .
2. In the IP Interfaces tab, click Edit of the VLAN for configuring BCMC optimization.
3. Select the Enable BCMC check box to enable BCMC Optimization for the selected VLAN.
Figure 16 Enable BCMC Optimization
In the CLI
(host)(config) #interface vlan 1
(host)(config-subif)#bcmc-optimization
(host)(config-subif)#show interface vlan 1
Configuring Ports
Both Fast Ethernet and Gigabit Ethernet ports can be set to access or trunk mode. A port is in access mode enabled by default and carries traffic only for the VLAN to which it is assigned. In trunk mode, a port can carry traffic for multiple VLANs.
109 | Network Configuration Parameters ArubaOS 6.5.3.x | User Guide
For a trunk port, specify whether the port will carry traffic for all VLANs configured on the controller or for specific VLANs only. You can also specify the native VLAN for the port. A trunk port uses 802.1q tags to mark frames for specific VLANs, However, frames on a native VLAN are not tagged.
Classifying Traffic as Trusted or Untrusted
You can classify wired traffic based not only on the incoming physical port and channel configuration, but also on the VLAN associated with the port and channel.
About Trusted and Untrusted Physical Ports
Physical ports on the controller are trusted and usually connected to internal networks by default, while untrusted ports connect to third-party APs, public areas, or other networks to which you can apply access controls. When you define a physical port as untrusted, traffic passing through that port needs to go through a predefined access control list policy.
About Trusted and Untrusted VLANs
You can also classify traffic as trusted or untrusted based on the VLAN interface and port or channel. This means that wired traffic on the incoming port is trusted only when the port’s associated VLAN is also trusted; otherwise the traffic is untrusted. When a port and its associated VLANs are untrusted, any incoming and outgoing traffic must pass through a predefined ACL. For example, this setup is useful if your company provides wired user guest access, and you want guest user traffic to pass through an ACL to connect to a captive portal.
You can set a range of VLANs as trusted or untrusted in trunk mode. The following table lists the port, VLAN and the trust/untrusted combination to determine if traffic is trusted or untrusted. Both the port and the
VLAN have to be configured as trusted for traffic to be considered as trusted. If the traffic is classified as untrusted, then traffic must pass through the selected session access control list and firewall policies.
Table 34: Classifying Trusted and Untrusted Traffic
Port VLAN
Trusted
Untrusted
Untrusted
Trusted
Trusted
Untrusted
Trusted
Untrusted
Traffic Status
Trusted
Untrusted
Untrusted
Untrusted
Configuring Trusted/Untrusted Ports and VLANs
You can configure an Ethernet port as an untrusted access port, assign VLANs and classify them as untrusted, and designate a policy through which VLAN traffic on this port must pass.
In the WebUI
1. Navigate to the Configuration > Network > Ports window.
2. In the Port Selection section, click the port you want to configure.
3. In the Make Port Trusted section, clear the Trusted check box to make the port untrusted. The default is trusted (checked).
4. In the Port Mode section, select Access .
5. From the VLAN ID drop-down list, select the VLAN ID whose traffic will be carried by this port.
ArubaOS 6.5.3.x
| User Guide Network Configuration Parameters | 110
6. In the Enter VLAN(s) section , clear the Trusted check box to make the VLAN untrusted. The default is trusted (checked).
7. In the VLAN Firewall Policy drop-down list, select the policy through which VLAN traffic must pass. You can select a policy for both trusted and untrusted VLANs.
8. From the Firewall Policy section, select the policy from the in drop-down list through which inbound traffic on this port must pass.
9. Select the policy from the out drop-down list through which outbound traffic on this port must pass.
10.To apply a policy to this session’s traffic on this port and VLAN, select the policy from the session dropdown list.
11.Click
Apply .
In the CLI
In this example,
(host)(config) #interface range fastethernet <slot/module/port>
(host)(config-if)#switchport mode access
(host)(config-if)#no trusted
(host)(config-if)#switchport access vlan <vlan>
(host)(config-if)#no trusted vlan <vlan>
(host)(config-if)#ip access-group ap-acl session vlan <vlan>
(host)(config-if)#ip access-group validuserethacl in
(host)(config-if)#ip access-group validuserethacl out
(host)(config-if)#ip access-group validuser session
Configuring Trusted and Untrusted Ports and VLANs in Trunk Mode
The following procedures configure a range of Ethernet ports as untrusted native trunks ports, assign VLANs and classify them as untrusted, and designate a policy through which VLAN traffic on the ports must pass.
In the WebUI
1. Navigate to the Configuration > Network > Ports window.
2. In the Port Selection section, click the port you want to configure.
3. For Port Mode select Trunk .
4. To specify the native VLAN, select a VLAN from the Native VLAN drop-down list.
5. Choose one of the following options to control the type of traffic the port carries: l
Allow All VLANS Except : The port carries traffic for all VLANs except those from this drop-down list.
l l
Allow VLANs : The port carries traffic for all VLANs selected from this drop-down list.
Remove VLANs: The port does not carry traffic for any VLANs selected from this drop-down list.
6. To designate untrusted VLANs on this port, click Trusted except . In the corresponding VLAN field enter a range of VLANs that you want to make untrusted . (In this format, for example: 200-300, 401-500 and so on). Only VLANs listed in this range are untrusted. To designate only one VLAN as untrusted, select a VLAN from the drop-down list.
7. To designate trusted VLANs on this port, click Untrusted except . In the corresponding VLAN field, enter a range of VLANs that you want to designate as trusted . (In this format, for example: 200-300, 401-500 and so on). Only VLANs listed in this range are trusted. To designate only one VLAN as trusted, select a VLAN from the drop-down menu.
8. To remove a VLAN, click the Remove VLANs option and select the VLAN you want to remove from the drop-down list, and click the left arrow to add it back to the list.
9. To designate the policy through which VLAN traffic must pass, click New under the Session Firewall
Policy field.
111 | Network Configuration Parameters ArubaOS 6.5.3.x | User Guide
10.Enter the VLAN ID or select it from the associated drop-down list. Then select the policy, through which the
VLAN traffic must pass, from the Policy drop-down list and click Add . Both the selected VLAN and the policy appear in the Session Firewall Policy field.
11.When you are finished listing VLANs and policies, click Cancel .
12.Click
Apply.
In the CLI
Use the following examples:
(host)(config) #interface fastethernet <slot/module/port>
(host)(config-if)#description <string>
(host)(config-if)#trusted {vlan <word>}
(host)(config-range)#switchport mode trunk
(host)(config-if)#switchport trunk native vlan <vlan>
(host)(config-range)#ip access-group
(host)(config-range)#ip access-group test session vlan <vlan>
Configuring Static Routes
To configure a static route (such as a default route) on the controller, do the following:
In the WebUI
1. Navigate to the Configuration > Network > IP > IP Routes page.
2. Click Add to add a static route to a destination network or host. Enter the destination IP address and network mask (255.255.255.255 for a host route) and the next hop IP address.
3. Click Done to add the entry. Note that the route has not yet been added to the routing table.
4. Click Apply .. The message Configuration Updated Successfully confirms that the route has been added.
In the CLI
Use the following examples:
(host)(config) #ip route <address> <netmask> <next_hop>
Configuring the Loopback IP Address
The loopback IP address is a logical IP interface that is used by the controller to communicate with APs. The loopback address is used as the controller’s IP address for terminating VPN and GRE tunnels, originating requests to RADIUS servers, and accepting administrative communications. You configure the loopback address as a host address with a 32-bit netmask. The loopback address is not bound to any specific interface and is operational at all times. To use this interface, ensure that the IP address is reachable through one of the
VLAN interfaces. It will be routable from all external networks.
You must configure a loopback address if you are not using VLAN1 to connect the controller to the network. If you do not configure the loopback interface address, then the first configured VLAN interface address is selected. Generally, VLAN 1 is the factory default setting and thus becomes the controller IP address.
In the WebUI
1. Navigate to the Configuration > Network > Controller > System Settings page and locate the
Loopback Interface section.
2. Modify the IP Address as required.
ArubaOS 6.5.3.x
| User Guide Network Configuration Parameters | 112
3. Click Apply .
If you are use the loopback IP address to access the WebUI, changing the loopback IP address will result in loss of connectivity. It is recommended that you use one of the VLAN interface IP addresses to access the WebUI.
4. Navigate to the Maintenance > Controller > Reboot Controller page to reboot the controller to apply the change of loopback IP address.
5. Click Continue to save the configuration.
6. When prompted that the changes were written successfully to flash, click OK .
7. The controller boots up with the changed loopback IP address.
In the CLI
Use the following commands:
(host)(config) #interface loopback ip address <address>
(host)(config) #write memory
Enter the following command in Enable mode to reboot the controller :
(host) #reload
Configuring the Controller IP Address
The Controller IP address is used by the controller to communicate with external devices such as APs.
IP addresses used by the controller is not limited to the controller IP address.
You can set the Controller IP address to the loopback interface address or to an existing VLAN ID address. This allows you to force the controller IP address to be a specific VLAN interface or loopback address across multiple machine reboots. Once you configure an interface to be the controller IP address, that interface address cannot be deleted until you remove it from the controller IP configuration.
If the controller IP address is not configured then the controller IP defaults to the current loopback interface address. If the loopback interface address is not configured then the first configured VLAN interface address is selected. Generally, VLAN 1 is the factory default setting and thus becomes the controller IP address.
In the WebUI
1. Navigate to Configuration > Network > Controller > System Settings page.
2. Locate the Controller IP Details section.
3. Select the address you want to set the Controller IP to from the VLAN ID drop-down list. This list contains only VLAN IDs that have statically assigned IP addresses. If you have previously configured a loopback interface IP address, then it will also appear in this list. Dynamically assigned IP addresses such as
DHCP/PPPOE do not display.
113 | Network Configuration Parameters ArubaOS 6.5.3.x | User Guide
4. Click Apply .
Any change in the controller’s IP address requires a reboot.
5. Navigate to the Maintenance > Controller > Reboot Controller page to reboot the controller to apply the change of controller IP address.
6. Click Continue to save the configuration.
7. When prompted that the changes were written successfully to flash, click OK .
8. The controller boots up with the changed controller IP address. of the selected VLAN ID.
In the CLI
(host)(config) #controller-ip [loopback|vlan <valn id>]
Configuring GRE Tunnels
Controllers support Generic Routing Encapsulation (GRE) tunnels between controllers and other network devices that support GRE tunnels.
This section contains the following information: n n n n n n
Configuring a Layer-2 GRE Tunnel
Configuring a Layer-3 GRE Tunnel for IPv4 or IPv6
Directing Traffic into the Tunnel
About Layer-2 GRE Tunnels
Layer-2 GRE tunnels allow you to have the same VLAN in multiple locations (separated by a Layer-3 network) and be connected. The forwarding method for a Layer-2 GRE tunnel is bridging.
However, the drawback of using Layer-2 GRE tunnels is that all broadcasts are flooded through the tunnel, adding traffic load to the network and the controllers.
ArubaOS 6.5.3.x
| User Guide Network Configuration Parameters | 114
Figure 17 Layer-2 GRE Tunnel
The traffic flow illustrated by
is as follows:
1. The frame enters the source controller (Controller-1) on VLAN 101.
The frame is bridged through Controller-1 into the Layer-2 GRE tunnel.
2. The frame is encapsulated in a GRE packet.
3. The GRE packet enters the network on VLAN 10, is routed across the network to the destination controller
(Controller-2), and then exits the network on VLAN 20.
The source IP address of the GRE packet is the IP address of the interface in VLAN 10 in Controller 1.
4. The frame is de-encapsulated and bridged out of the destination controller (Controller-2) on VLAN 101.
About Layer-3 GRE Tunnels
The benefit of Layer-3 GRE tunnels is that broadcasts are not flooded through the tunnel, so there's less wasted bandwidth and less load on the controllers. The forwarding method for a Layer-3 GRE tunnel is routing.
By default, GRE tunnels are in IPv4 Layer-3 mode.
Figure 18 IPv4 Layer-3 GRE Tunnel
Figure 19 IPv6 Layer-3 GRE Tunnel
IPv6 encapsulated in IPv4 and IPv4 encapsulated in IPv6 are not supported. The only Layer-3 GRE modes supported are IPv4 encapsulated in IPv4 and IPv6 encapsulated in IPv6.
115 | Network Configuration Parameters ArubaOS 6.5.3.x | User Guide
Layer-3 Tunnel Traffic FLow
The traffic flow illustrated by
and
is as follows:
1. The frame enters the source controller (Controller-1) on VLAN 101.
The IP packet within the frame is routed through Controller-1 into the Layer-3 GRE tunnel.
2. The IP packet is encapsulated in a GRE packet.
3. The GRE packet enters the network on VLAN 10, is routed across the network to destination controller
(Controller-2), and then exits the network on VLAN 20.
The source IP address of the GRE packet is the IP address of the interface in VLAN 10 in Controller 1.
4. The IP packet is de-encapsulated and routed out of the destination controller (Controller-2) on VLAN 202.
Limitations for Static IPv6 Layer-3 Tunnels
ArubaOS does not support the following functions for static IPv6 Layer-3 GRE tunnels: n n
IPv6 Auto-configuration and IPv6 Neighbor Discovery mechanisms do not apply to IPv6 GRE tunnels.
The tunnel encapsulation limit and Maximum Transmission Unit (MTU) discovery options are not supported on IPv6 GRE tunnels.
Configuring a Layer-2 GRE Tunnel
In the WebUI
To configure a Layer-2 GRE tunnel for Controller-1 and Controller-2 via the WebUI:
1. Log in to Controller-1.
2. Navigate to Configuration > Network > IP > GRE Tunnels .
The GRE Tunnels page is displayed.
Figure 20 GRE Tunnels Page
3. Highlight the line for the tunnel ID of interest and click Edit . The Edit GRE Tunnel screen appears, as shown in
ArubaOS 6.5.3.x
| User Guide Network Configuration Parameters | 116
Figure 21 Layer-2 GRE Tunnel UI Configuration for Controller-1
4. Enter the corresponding GRE tunnel values for this controller to configure Controller-1 based on the network shown in
.
5. (Optional) Select Enable Heartbeats to enable tunnel keepalive heartbeats. For more information on this feature, see
Configuring Tunnel Keepalives on page 122
6. Click Apply .
7. Next, log into Controller-2 and navigate to Configuration > Network > IP > GRE Tunnels .
8. Highlight the line for the tunnel ID of interest and click Edit .
9. Use the Edit GRE Tunnel screen to configure Controller-2 based on the network shown in
.
10.(Optional) Select Enable Heartbeats to enable tunnel keepalive heartbeats.
11.Click
Apply .
In the CLI
The following command example configures a Layer-2 GRE tunnel:
Referring to
Figure 17 , the following are the required configurations to create the Layer-2 GRE tunnel between
controllers named Controller-1 and Controller-2:
Controller-1 Configuration
(Controller-1) (config) # interface tunnel 102 description “IPv4 Layer-2 GRE 102" tunnel mode gre 1 tunnel source vlan 10 tunnel destination 20.20.20.249
tunnel keepalive trusted tunnel vlan 101
Controller-2 Configuration
(Controller-2) (config) # interface tunnel 202
117 | Network Configuration Parameters ArubaOS 6.5.3.x | User Guide
description “IPv4 Layer-2 GRE 202" tunnel mode gre 1 tunnel source vlan 20 tunnel destination 10.10.10.249
tunnel keepalive trusted tunnel vlan 101
Configuring a Layer-3 GRE Tunnel for IPv4 or IPv6
In the WebUI
The following steps describe the procedure configure an IPv4 Layer-3 GRE tunnel for Controller-1 and
Controller-2 via the WebUI.
1. Log into Controller-1.
2. Navigate to Configuration > Network > IP > GRE Tunnels . The GRE Tunnels page is displayed.
Figure 22 GRE Tunnels Page
3. Highlight the line for the tunnel ID of interest and click Edit . The Edit GRE Tunnel screen appears, as shown in
ArubaOS 6.5.3.x
| User Guide Network Configuration Parameters | 118
Figure 23 Layer-3 IPv4 GRE Tunnel UI Configuration for Controller-1
4. Click the IP Version drop-down list and select IPv4 or IPv6.
5. Enter the corresponding GRE tunnel values for the controller.
n n
To configure an IPv4 GRE tunnel , use the values for Controller-1 based on the network shown in
.
To configure an IPv6 GRE tunnel , use the values for Controller-1 based on the network shown in
.
If a VLAN interface has IPv6 addresses configured, one of them is used as the tunnel source IPv6 address. If the selected IPv6 address is deleted from the VLAN interface, then the tunnel source IP address is reconfigured with the next available IPv6 address.
6. (Optional for an IPv4 GRE Tunnel) Click the Route ACL name drop-down list and select the name of a routing access control list (ACL) to attach a route ACL to inbound traffic on the L3 GRE tunnel interface.
When you associate a routing ACL to inbound traffic on a controller terminating a L3 GRE tunnel, that ACL can forward traffic as normal, route traffic to a nexthop router on a nexthop list, or redirect traffic over an
L3 GRE tunnel or tunnel group. For more information on creating a routing ACL, see
7. (Optional for IPv4 or IPv6 GRE Tunnels) Select Enable Heartbeats to enable tunnel keepalive heartbeats.
For more information on this feature, see
Configuring Tunnel Keepalives on page 122
8. Click Apply .
9. Next, log into Controller-2 and navigate to Configuration > Network > IP > GRE Tunnels .
10.Highlight the line for the tunnel ID of interest and click Edit .
11.Enter the corresponding GRE tunnel values for this controller.
n to create an IPv4 L3 GRE tunnel, use the values for Controller-2 as shown in
119 | Network Configuration Parameters ArubaOS 6.5.3.x | User Guide
n
To create an IPv6 L3 GRE tunnel ure an IPv6 GRE tunnel , use the values for Controller-2 as shown in
.
12.(Optional for an IPv4 GRE Tunnel) Click the Route ACL name drop-down list and select the name of a routing access control list (ACL) to attach a route ACL to inbound traffic on the L3 GRE tunnel interface.
13.(Optional for IPv4 or IPv6 GRE Tunnels) Select Enable Heartbeats to enable tunnel keepalive heartbeats.
14.Click
Apply .
In the CLI
The following command examples configure an IPv4 Layer-3 GRE tunnel for IPv4 between two controllers.
Referring to
Figure 18 , the following are the required configurations to create the IPv4 Layer-3 GRE tunnel
between controllers named Controller-1 and Controller-2:
IPv4 Controller-1 Configuration
(Controller-1) (config) # interface tunnel 104 description “IPv4 L3 GRE 104" tunnel mode gre ip ip address 1.1.1.1 255.255.255.255
tunnel source vlan 10 tunnel destination 20.20.20.249
trusted
IPv4 Controller-2 Configuration
(Controller-2) (config) # interface tunnel 204 description “IPv4 L3 GRE 204" tunnel mode gre ip ip address 1.1.1.2 255.255.255.255
tunnel source vlan 20 tunnel destination 10.10.10.249
trusted
The following command example configures a Layer-3 GRE tunnel for IPv6:
IPv6 Controller-1 Configuration
(Controller-1) (config) # interface tunnel 106 description “IPv6 Layer-3 GRE 106" tunnel mode gre ipv6 ip address 2001:1:2:1::1 tunnel source vlan 10 tunnel destination 2001:1:2:2020::1 trusted
IPv6 Controller-2 Configuration
(Controller-2) (config) # interface tunnel 206 description “IPv6 Layer-3 GRE 206" tunnel mode gre ipv6 ip address 2001:1:2:1::2 tunnel source vlan 20 tunnel destination 2001:1:2:1010::1 trusted
Directing Traffic into the Tunnel
You can direct traffic into a GRE tunnel by configuring one of the following: n n
Static route : Redirects traffic to the IP address of the tunnel.
Firewall policy (session-based ACL) : Redirects traffic to the specified tunnel ID.
ArubaOS 6.5.3.x
| User Guide Network Configuration Parameters | 120
About Configuring Static Routes
You can configure a static route that specifies the IP address of a tunnel as the next-hop for traffic for a specific destination. See
Configuring Static Routes on page 112
for detailed information on how to configure a static route.
While redirecting traffic into a Layer-3 GRE tunnel via a static route, be sure to use the controller's tunnel IP address as the next-hop, instead of providing the destination controller's tunnel IP address.
Referring to
Figure 18 , the following are examples of the required static route configurations to direct traffic
into the IPv4 Layer-3 GRE tunnel. for Controller-1 and Controller-2: n n
For the controller named Controller-1:
(Controller-1) (config) # ip route 20.20.202.0 255.255.255.0 1.1.1.1
For the controller named Controller-2:
(Controller-2) (config) # ip route 10.10.101.0 255.255.255.0 1.1.1.2
Configuring a Firewall Policy Rule
You can configure a firewall policy rule to redirect selected traffic into a GRE tunnel.
Traffic redirected by a firewall policy rule is not forwarded to a tunnel that is “down” (see the next section,
Configuring Tunnel Keepalives , for more information on how GRE tunnel status is determined).
From the WebUI
To direct traffic into a GRE tunnel via a firewall policy via the WebUI:
1. On the controller, navigate to the Configuration > Security > Access Control > Policies page.
Figure 24 Firewall Policies Page
2. To create a new firewall policy, click Add.
To edit an existing policy, click Edit .
The Add New Policy screen appears.
121 | Network Configuration Parameters ArubaOS 6.5.3.x | User Guide
Figure 25 Adding a New Firewall Policy
3. Enter the Policy Name .
4. For Policy Type , specify Session (the default).
5. To create a new policy rule, scroll to the Rules section and click Add .
Figure 26 Specifying Firewall Rules a. Specify the IP Version .
b. Configure the Source , Destination , and Service/Application for the rule.
c. For Action , select redirect to tunnel .
d. Enter the Tunnel ID .
e. Configure any additional options.
6. When satisfied with the settings, click Add , then click Apply .
In the CLI
To direct traffic into a GRE tunnel via a firewall policy (session-based ACL) via the CLI, use the following command:
(ControllerController-1)(config) #ip access-list session <name>
<source> <destination> <service> redirect tunnel <id>
Configuring Tunnel Keepalives
The controller determines the status of a GRE tunnel by sending periodic keepalive frames on the Layer-2 or
Layer-3 GRE tunnel. When you enable tunnel keepalives, the tunnel is considered “down” when the keepalives
ArubaOS 6.5.3.x
| User Guide Network Configuration Parameters | 122
fail repeatedly.
If you configure a firewall policy rule to redirect traffic to the tunnel, traffic is not forwarded to the tunnel until it is "up." When the tunnel comes up or goes down, an SNMP trap and logging message is generated. The remote endpoint of the tunnel does not need to support the keepalive mechanism.
The controller sends keepalive frames at 60-second intervals by default and retries keepalives up to three times before the tunnel is considered down. You can change the default values of the intervals: n n n
For the interval , specify a value between 1 and 86400 seconds.
For the retries , specify a value between 0 and 1024.
To interoperate with Cisco network devices, use the cisco option.
In the WebUI
To configure keepalives (Heartbeats) via the WebUI:
1. On the controller, navigate to the Configuration > Network > IP > GRE Tunnels page.
2. Locate the tunnel ID for which you are enabling keepalives, then click Edit . The Edit GRE Tunnel screen appears.
Figure 27 Configuring Heartbeats (Keepalives)
3. To enable tunnel keepalives and display the Heartbeat Interval and Heartbeat Retries fields, click Enable
Heartbeats .
a. Specify a value for Heartbeat Interval.
The default value is 10 seconds.
b. Specify a value for Heartbeat Retries .
The default value is 3 retries.
4. Click Apply .
In the CLI
To configure the keepalive heartbeats, use the following commands:
(host)(config) #interface tunnel id tunnel keepalive [<interval> <retries>] [cisco] n n n n n
Configuring GRE Tunnel Groups
This section contains the following information:
Configuring a Layer-2 or Layer-3 Tunnel Group Using the CLI
Configuring a Layer-2 or Layer-3 Tunnel Group Using the WebUI
123 | Network Configuration Parameters ArubaOS 6.5.3.x | User Guide
About GRE Tunnel Groups
The controller supports redundancy of Generic Routing Encapsulation (GRE) tunnels for both Layer-2 and
Layer-3 GRE tunnels. This feature enables automatic redirection of the user traffic to a standby tunnel when the primary tunnel goes down.
A tunnel group is identified by a name or number. You can add multiple tunnels to a tunnel group.
Tunnel Group Order
The order of the tunnels defined in the tunnel-group configuration specifies their standby precedence. The first member of the tunnel-group is the primary tunnel .
Tunnel Failover
A GRE tunnel group combines two tunnels created in the controller, where one tunnel is active and the other tunnel is the standby. Traffic forwarding can occur on the active tunnel, and the standby tunnel can become active once the active tunnel is down.
When the first tunnel fails, the second tunnel carries the traffic. The third tunnel in the tunnel-group takes over if the second tunnel also fails.
In the meantime, if the first tunnel comes up, it becomes the most eligible standby tunnel.
Preemption
You can also enable or disable preemption as part of the tunnel-group configuration. Preemption is enabled by default. (For CLI examples, see
Enabling Preemption on page 125 .)
The preemptive-failover option automatically redirects the traffic whenever it detects an active tunnel with a higher precedence in the tunnel group.
When preemption is disabled, the traffic gets redirected to a higher precedence tunnel only when the tunnel carrying the traffic fails.
Enabling a Tunnel Group
To enable this tunnel-group functionality, you must complete the following tasks:
1. Configure the member tunnel.
2. Enable tunnel keepalives on the tunnel interface.
3. Configure the tunnel group and set the group type to Layer-2 or Layer-3.
4. Add the member tunnels to the group.
Points to Remember
n n n n
When a tunnel is added to the tunnel group, the tunnel is used for data traffic only if it is the active tunnel in the group.
Standby tunnels do not carry any data traffic. However, all tunnels in the group continue to send and receive keepalive packets.
Only one type of tunnel can be placed into a tunnel group—either Layer-2 or Layer-3. That is, you can't have a tunnel group consisting of both Layer-2 and Layer-3 tunnels.
The default value of tunnel group type is Layer-3.
Regarding Layer-2 Tunnel Groups
When creating a Layer-2 tunnel group, keep in mind the following: n
All tunnels in a Layer-2 tunnel group must be tunneling the same VLAN.
ArubaOS 6.5.3.x
| User Guide Network Configuration Parameters | 124
n n n
A Layer-2 tunnel can only be part of one tunnel group.
An Aruba Layer-2 tunnel-group is not interoperable with other vendors.
You must set up Layer-2 tunnel groups between Aruba devices only.
Configuring a Layer-2 or Layer-3 Tunnel Group Using the CLI
To configure a Layer-2 or Layer-3 tunnel group using the CLI:
(Controller-1) (config) #tunnel-group <tunnel_group_name>
(Controller-1) (config-tunnel-group)#mode {l2|l3}
(Controller-1)(config-tunnel-group)#tunnel <tunnel-id>
Example Configuration
The following is a sample configuration:
(Controller-1) (config) #tunnel-group branch_1
(Controller-1) (config-tunnel-group)#mode l2
Enabling Preemption
Execute the following command to enable preemption:
(Controller-1)(config-tunnel-group)#preemptive-failover
Viewing Operational Status
To view the operational status of all the tunnel groups and their members, issue the following command:
(Controller-1) #show tunnel-group
The following is the sample output of the show tunnel-group command:
(Controller-1) #show tunnel-group
Tunnel-Group Table Entries
--------------------------
Tunnel Group Mode Tunnel Group Id Preemptive Failover Active Tunnel Id Tunnel Members
---------------------------------------------------------------------------branch_1 L2 16385 enabled 1 10 11
Viewing Active and Member Tunnels
To view the active member tunnel and all the member tunnels of the respective tunnel-group, issue the following command:
(Controller-1) #show datapath tunnel-group
Following is the sample output of the show datapath tunnel-group command:
(host) #show datapath tunnel-group
Datapath Tunnel-Group Table Entries
-----------------------------------
Tunnel-Group Active Tunnel Members
------------------------------------------
16385 10 10 11
Viewing the Standby Member Tunnels
To view the standby member tunnels of the tunnel-group, issue the following command:
(host) #show datapath tunnel
The following is sample output of the show datapath tunnel command:
(host) #show datapath tunnel
125 | Network Configuration Parameters ArubaOS 6.5.3.x | User Guide
+----+------+-----------------------------------------------------+
|SUM/| | | |
|CPU | Addr | Description Value |
+----+------+-----------------------------------------------------+
| | |
| G | [00] | Current Entries
| G | [02] | High Water Mark
| G | [03] | Maximum Entries
| G | [04] | Total Entries
|
10 |
10 |
32768 |
31 |
| G | [06] | Max link length 1 |
+----+------+-----------------------------------------------------+
Datapath Tunnel Table Entries
-----------------------------
Flags: E - Ether encap, I - Wi-Fi encap, R - Wired tunnel, F - IP fragment OK
W - WEP, K - TKIP, A - AESCCM, G - AESGCM, M - no mcast src filtering
S - Single encrypt, U - Untagged, X - Tunneled node, 1(cert-id) - 802.1X Term-PEAP
2(cert-id) - 802.1X Term-TLS, T - Trusted, L - No looping, d - Drop Bcast/Unknown Mcast,
D - Decrypt tunnel, a - Reduce ARP packets in the air, e - EAPOL only
C - Prohibit new calls, P - Permanent, m - Convert multicast n - Convert RAs to unicast(VLAN Pooling/L3 Mobility enabled), s - Split tunnel
V - enforce user vlan(open clients only), x - Striping IP
H - Standby (HA-Lite), c - IP Compression, g - PAN GlobalProtect Tunnel
# Source Destination Prt Type MTU VLAN Acls
------------------------------------- ----------------------
10
11
192.0.2.1
192.0.2.1
198.51.100.1
203.0.113.1
47
47
1
1
1100
1100
0
0
0
0
0
0
0
0
0
0
BSSID Decaps Encaps Heartbeats Flags EncapKBytes DecapKBytes
--------------------------------- -------------------------- ------------
00:00:00:00:00:00
00:00:00:00:00:00
0
0
5
0
0 TEFPR
0 LEFPR H
In this example, the member tunnel 11 is a standby tunnel, which is denoted by the H flag.
Configuring a Layer-2 or Layer-3 Tunnel Group Using the WebUI
To configure a Layer-2 or Layer-3 tunnel group using the WebUI:
1. Navigate to the Configuration > Network > IP > GRE Tunnels page.
2. In the Tunnel Group pane, click Add .
3. Specify a name for the tunnel-group in the Tunnel Group Name text box.
4. Under Mode , select the tunnel group type.
5. In the Tunnel Group Member text box, specify the tunnel IDs, separating the IDs with commas.
6. To enable preemption, select the Enable Preemptive-Failover Mode check box. This option is enabled by default.
To disable pre-emption, clear the check box.
7. Click Apply .
Jumbo Frame Support
Jumbo frames are the data frames that are larger than 1500 bytes and includes the Layer 2 header and Frame
Check Sequence (FCS). Jumbo frames functionality can be configured on 7000 Series and 7200 Series controllers to support up to 9216 bytes of payload.
In centralized deployments, frames that are more than 1500 bytes in size are generated from AP to the controller during encryption and enabling AMSDU. Therefore, whenever the AP associates to the controller,
ArubaOS 6.5.3.x
| User Guide Network Configuration Parameters | 126
jumbo frames are used to get the highest network performance. If this functionality is not supported, the data frames gets fragmented, which reduces the overall throughput of the network and makes the network slow.
ArubaOS supports jumbo frames between 11ac APs and both 7000 Series and 7200 Series controllersonly.
You can enable the jumbo frame support in the following scenarios: n n n n
Tunnel node: In a tunneled node deployment, the wired clients connected on the tunneled nodes can send and receive the jumbo frames.
L2/L3 GRE tunnels: When you establish a GRE tunnel between two controllers, the clients on one controller can send and receive jumbo frames from the clients on the other controller on enabling jumbo frames.
Between wired clients: In a network where clients connect to the controller with jumbo frames enabled ports can send and receive the jumbo frames.
Wi-Fi tunnel: A Wi-Fi tunnel can support an AMSDU jumbo frame for an AP (The maximum MTU supported is up to 9216 bytes).
Limitations for Jumbo Frame Support
This release of ArubaOS does not support the jumbo frames for the following scenarios: n n
IPsec, IPIP, and xSec.
IPv6 fragmentation/reassembly.
Configuring Jumbo Frame Support
You can use the WebUI or CLI to configure the jumbo frame support.
In the WebUI
To enable jumbo frame support globally:
1. Navigate to the Configuration > ADVANCED SERVICES > Stateful Firewall > Global Setting page.
2. Select the Jumbo frames processing checkbox to enable the jumbo frames support.
3. Enter the value of the MTU in the Jumbo MTU [1789-9216] bytes textbox.
4. Click Apply .
To enable jumbo frame support on a port:
1. Navigate to Configuration > NETWORK > Ports page.
2. Select the Enable Jumbo MTU checkbox to enable the jumbo frames support.
3. Click Apply .
To enable jumbo frame support on a port channel:
1. Navigate to the Configuration > NETWORK > Ports > Port-Channel page.
2. Select the Enable Jumbo MTU checkbox to enable the jumbo frames support.
3. Click Apply .
In the CLI
To enable the jumbo frame support globally and to configure the MTU value:
(host)(config)#firewall jumbo mtu <val>
You can configure the MTU value between 1,789-9,216. The default MTU value is 9,216.
To disable the jumbo frame support:
127 | Network Configuration Parameters ArubaOS 6.5.3.x | User Guide
(host)(config)#no firewall enable-jumbo-frames
In this case, the MTU value is considered as 9,216 (default).
To enable jumbo frame support on a port channel:
(host)(config)#interface port-channel <id> jumbo
To disable jumbo frame support on a port channel:
(host)(config)#interface port-channel <id> no jumbo
To enable jumbo frame support on a port:
(host)(config) #interface gigabitethernet <slot>/<module>/<port> jumbo
To disable jumbo frame support on a port:
(host)(config) #interface gigabitethernet <slot>/<module>/<port> no jumbo
Viewing the Jumbo Frame Support Status
Execute the following command to view the global status of the jumbo frame support:
(host)#show firewall
Execute the following command to view the jumbo frame status on a port:
(host)#show interface gigabitethernet <slot>/<module>/<port>
Execute the following command to view the jumbo frame status on a port channel:
(host)#show interface port-channel <id>
ArubaOS 6.5.3.x
| User Guide Network Configuration Parameters | 128
Chapter 5
IPv6 Support
This chapter describes ArubaOS support for IPv6 features: n n n n n n n n n n n n n
Understanding IPv6 Notation on page 129
Understanding IPv6 Topology on page 129
Enabling IPv6 Support for Controller and APs on page 130
Filtering an IPv6 Extension Header (EH) on page 138
Configuring a Captive Portal over IPv6 on page 138
Working with IPv6 Router Advertisements (RAs) on page 139
Understanding ArubaOS Supported Network Configuration for IPv6 Clients on page 147
Managing IPv6 User Addresses on page 153
Understanding IPv6 Exceptions and Best Practices on page 154
Understanding IPv6 Notation
The IPv6 protocol is the next generation of large-scale IP networks, it supports addresses that are 128 bits long. This allows 2 128 possible addresses (versus 2 32 possible IPv4 addresses).
Typically, the IP address assigned on an IPv6 host consists of a 64-bit subnet identifier and a 64-bit interface identifier. IPv6 addresses are represented as eight colon-separated fields of up to four hexadecimal digits each.
The following are examples of IPv6 addresses:
2001:0000:0eab:DEAD:0000:00A0:ABCD:004E
The use of the
“::” symbol is a special syntax that you can use to compress one or more group of zeros or to compress leading or trailing zeros in an address. The
“::” can appear only once in an address.
For example, the address,
2001:0000:0dea:C1AB:0000:00D0:ABCD:004E can also be represented as:
2001:0:eab:DEAD:0:A0:ABCD:4E – leading zeros can be omitted
2001:0:0eab:dead:0:a0:abcd:4e – not case sensitive
2001:0:0eab:dead::a0:abcd:4e - valid
2001::eab:dead::a0:abcd:4e - Invalid
IPv6 uses a "/" notation which describes the no: of bits in netmask, similar to IPv4.
2001:eab::1/128 – Single Host
2001:eab::/64 – Network
Understanding IPv6 Topology
IPv6 APs connect to the IPv6 controller over an IPv6 L3 network. The IPv6 controller can terminate both IPv4 and IPv6 APs. IPv4 and IPv6 clients can terminate to either IPv4 or IPv6 APs. ArubaOS supports Router
Advertisements (RA). You do not need an external IPv6 router in the subnet to generate RA for IPv6 APs and clients that depend on stateless autoconfiguration to obtain IPv6 address. The external IPv6 router is the
ArubaOS 6.5.3.x
| User Guide IPv6 Support | 129
default gateway in most deployments. However, the controller can be the default gateway by using static routes. The master-local communication always occurs in IPv4.
The following image illustrates how IPv6 clients, APs, and controllers communicate with each other in an IPv6 network:
Figure 28 IPv6 Topology n n n n
The IPv6 controller ( MC2 ) terminates both V4 AP (IPv4 AP) and V6 AP (IPv6 AP).
Client 1 (IPv4 client) terminates to V6 AP and Client 2 (IPv6 client) terminates to V4 AP .
Router is an external IPv6 router in the subnet that acts as the default gateway in this illustration.
MC1 (master) and MC2 (local) communicates in IPv4.
Enabling IPv6
You must enable the IPv6 option on the controller before using any of the IPv6 functions. You can use the ipv6 enable command to enable the IPv6 packet/firewall processing on the controller. The IPv6 option is disabled by default.
You can also use the WebUI to enable the IPv6 option:
1. Navigate to the Configuration > Advanced Services > Stateful Firewall page.
2. Select the Global Settings tab.
3. Select the IPv6 Enable check box to enable the IPv6 option.
4. Click Apply .
Enabling IPv6 Support for Controller and APs
This release of ArubaOS provides IPv6 support for controllers and access points. You can now configure the master controller with an IPv6 address to manage the controllers and APs. Both IPv4 and IPv6 APs can
130 | IPv6 Support ArubaOS 6.5.3.x | User Guide
terminate on the IPv6 controller. You can provision an IPv6 AP in the network only if the controller interface is configured with an IPv6 address. An IPv6 AP can serve both IPv4 and IPv6 clients.
You must manually configure an IPv6 address on the controller interface to enable IPv6 support.
You can perform the following IPv6 operations on the controller: n n n n n n n n
Configuring IPv6 Addresses on page 132
Configuring IPv6 Static Neighbors on page 133
Configuring IPv6 Default Gateway and Static IPv6 Routes on page 134
Managing Controller IP Addresses on page 134
Configuring Multicast Listener Discovery on page 135
Debugging an IPv6 Controller on page 137
Provisioning an IPv6 AP on page 137
Monitoring Bandwidth Usage on page 138
You can also view the IPv6 statistics on the controller using the following commands: n n n n n n show datapath ip-reassembly ipv6
— View the IPv6 contents of the IP Reassembly statistics table.
show datapath route ipv6
— View datapath IPv6 routing table.
show datapath route-cache ipv6
— View datapath IPv6 route cache.
show datapath tunnel ipv6
— View the tcp tunnel table filtered on IPv6 entries.
show datapath user ipv6
— View datapath IPv6 user statistics such as current entries, pending deletes, high water mark, maximum entries, total entries, allocation failures, invalid users, and maximum link length.
show datapath session ipv6
— View datapath IPv6 session entries and statistics such as current entries, pending deletes, high water mark, maximum entries, total entries, allocation failures, invalid users, and maximum link length.
n n n n n
Additionally, you can view the IPv6 AP information on the controller using the following show commands: show ap database show ap active show user show ap details ip6-addr show ap debug
The following table lists IPv6 features:
Table 35: IPv6 APs Support Matrix
Features
Forward Mode - Tunnel
Forward Mode - Decrypt Tunnel
Forward Mode - Bridge
Forward Mode - Split Tunnel
AP Type - CAP
Supported on IPv6 APs?
Yes
No
No
No
Yes
ArubaOS 6.5.3.x
| User Guide IPv6 Support | 131
Features
AP Type - RAP
AP Type - Mesh Node
IPSEC
CPSec
Wired-AP/Secure-Jack
Fragmentation/Reassembly
MTU Discovery
Provisioning through Static IPv6
Addresses
Provisioning through IPv6 FQDN Master
Name
Provisioning from WebUI
AP boot by Flash
AP boot by TFTP
WMM QoS
AP Debug and Syslog
ARM & AM
WIDS
CLI support for users & datapath
Supported on IPv6 APs?
No
No
No
No
No
Yes
Yes
Yes
Yes
Yes
Yes
No
No
Yes
Yes
Yes (Limited)
Yes
Configuring IPv6 Addresses
You can configure IPv6 addresses for the management interface, VLAN interface, and the loopback interface of the controller. The controller can have up to three IPv6 addresses for each VLAN interface. The IPv6 address configured on the loopback interface or the first VLAN interface of the controller becomes the default IPv6 address of the controller.
If only one IPv6 address is configured on the controller, it becomes the default IPv6 address of the controller. With this release of ArubaOS, you can delete this IPv6 address.
You can configure IPv6 interface address using the WebUI or CLI. As per Internet Assigned Numbers Authority
(IANA), Aruba controllers support the following ranges of IPv6 addresses: n n n
Global unicast—2000::/3
Unique local unicast—fc00::/7
Link local unicast—fe80::/10
132 | IPv6 Support ArubaOS 6.5.3.x | User Guide
In the WebUI
To Configure Link Local Address
1. Navigate to the Configuration > Network > IP page and select the IP Interfaces tab.
2. Edit a VLAN # and select IP version as IPv6.
3. Enter the link local address in the Link Local Address field.
4. Click Apply .
To Configure Global Unicast Address
1. Navigate to the Configuration > Network > IP page and select the IP Interfaces tab.
2. Edit a VLAN # and select IP version as IPv6.
3. Enter the global unicast address and the prefix-length in the IP Address/Prefix-length field.
4. (Optional) Select the EUI64 Format check box, if applicable.
5. Click Add to add the address to the global address list.
6. Click Apply .
To Configure Loopback Interface Address
1. Navigate to the Configuration > Network > Controller page and select the System Settings tab.
2. Under Loopback Interface enter the loopback address in the IPv6 Address field.
3. Click Apply .
You cannot configure the management interface address using the WebUI.
In the CLI
To configure the link local address:
(host)(config)#interface vlan <vlan#>
(host)(config-subif)#ipv6 address <ipv6-address> link-local
To configure the global unicast address:
(host)(config)#interface vlan <vlan#>
(host)(config-subif)#ipv6 address <ipv6-prefix>/<prefix-length>
To configure the global unicast address (EUI 64 format):
(host)(config)#interface vlan <vlan#>
(host)(config-subif)#ipv6 address <ipv6-prefix/prefix-length> eui-64
To configure the management interface address:
(host)(config)#interface mgmt
(host)(config-subif)#ipv6 address <ipv6-prefix/prefix-length>
To configure the loopback interface address:
(host)(config)#interface loopback
(host)(config-subif)#ipv6 address <ipv6-prefix>
Configuring IPv6 Static Neighbors
You can configure a static neighbor on a VLAN interface either using the WebUI or the CLI.
In the WebUI
1. Navigate to the Configuration > Network > IP page and select the IPv6 Neighbors tab.
2. Click Add and enter the following details of the IPv6 neighbor:
ArubaOS 6.5.3.x
| User Guide IPv6 Support | 133
n n
IPV6 Address
Link-layer Addr n
VLAN Interface
3. Click Done to apply the configuration.
In the CLI
To configure a static neighbor on a VLAN interface:
(host)(config)#ipv6 neighbor <ipv6addr> vlan <vlan#> <mac>
Configuring IPv6 Default Gateway and Static IPv6 Routes
You can configure IPv6 default gateway and static IPv6 routes using the WebUI or CLI.
In the WebUI
To Configure IPv6 Default Gateway
1. Navigate to the Configuration > Network > IP page and select the IP Routes tab.
2. Under the Default Gateway section, click Add .
3. Select IPv6 as IP Version , and enter the IPv6 address in the IP Address field.
4. Click Add to add the address to the IPv6 default gateway table.
5. Click Apply .
To Configure Static IPv6 Routes
1. Under the IP Routes section, click Add and select IPv6 as IP Version .
2. Enter the destination IP address and the forwarding settings in the respective fields.
3. Click Done to add the static route to the IPv6 routes table.
4. Click Apply .
In the CLI
To configure the IPv6 default gateway:
(host)(config)#ipv6 default-gateway <ipv6-address> <cost>
To configure static IPv6 routes:
(host)(config)#ipv6 route <ipv6-prefix/prefix-length> <ipv6-next-hop> <cost>
<ipv6-next-hop> = X:X:X:X::X
Managing Controller IP Addresses
You can change the default controller IP address by assigning a different VLAN interface address or the loop back interface address. You can also turn on Syslog messaging for IPv6 (similar to IPv4 logging) using the logging <ipv6 address> command. For more information on logging, see
.You can use the WebUI or CLI to change the default controller IP address.
In the WebUI
1. Navigate to the Configuration > Network > Controller page and select the System Settings tab.
2. Under the Controller IP Details section, select the VLAN Id or the loopback interface Id in the IPv6
Address drop down.
3. Click Apply.
134 | IPv6 Support ArubaOS 6.5.3.x | User Guide
In the CLI
To configure an IPv6 address to the controller:
(host)(config)#controller-ipv6 loopback
(host)(config)#controller-ipv6 vlan <vlanId>
To enable logging over IPv6:
(host)(config)#logging <ipv6 address>
Configuring Multicast Listener Discovery
You can enable the IPv6 multicast snooping on the controller by using the WebUI or CLI and configure
Multicast Listener Discovery (MLD) parameters such as query interval, query response interval, robustness variable, and ssm-range.
The Source Specific Multicast (SSM) supports delivery of multicast packets that originate only from a specific source address requested by the receiver. You can forward multicast streams to the clients if the source and group match the client subscribed source group pairs (S,G).
The controller supports the following IPv6 multicast source filtering modes: n n
Include - In Include mode, the reception of packets sent to a specified multicast address is enabled only from the source addresses listed in the source list. The default IPv6 SSM address range is FF3X::4000:1 –
FF3X::FFFF:FFFF, and the hosts subscribing to SSM groups can only be in the Include mode.
Exclude - In Exclude mode, the reception of packets sent to a specific multicast address is enabled from all source addresses. If there is a client in the Exclude mode, the subscription is treated as an MLDv1 join.
For more information on MLD feature, see RFC 3810 and RFC 4604 ,
Starting with ArubaOS 6.4.2.3, MLD snooping does not add IPv6 Solicited-Node multicast address or groups to the multicast table. A Solicited-Node multicast address is an IPv6 multicast address valid within the local-link
(example, an Ethernet segment or a Frame Relay cloud). Every IPv6 host has at least one such address per interface. Solicited-Node multicast addresses are used in Neighbor Discovery Protocol for obtaining the layer 2 link-layer addresses of other nodes.
In the WebUI
To enable IPv6 MLD Snooping
1. Navigate to the Configuration > Network > IP page and select the IP Interfaces tab.
2. Click the Edit button listed under Actions to edit the required VLAN interface.
3. Select IPv6 from the IP version drop-down list.
4. Check the Enable MLD Snooping check box under MLD section to enable IPv6 MLD snooping.
5. Click Apply.
To Modify IPv6 MLD Parameters
1. Navigate to the Configuration > Network > IP page and select the Multicast tab.
2. Under the MLD section, enter the required values in the following fields: n n
Robustness Variable: default value is 2
Query Interval (second): default value is 125 seconds n
Query Response Interval (in 1/10 second): default value is 100 (1/10 seconds).
3. Click Apply.
To configure the SSM Range:
1. Navigate to Configuration>Network>IP page and select the Multicast tab.
ArubaOS 6.5.3.x
| User Guide IPv6 Support | 135
2. In the MLD section, use the SSM Range Start-IP and SSM Range End-IP fields to configure the
SSM Range.
3. Click Apply to save your changes.
In the CLI
To enable IPv6 MLD snooping:
(host)(config) #interface vlan 1
(host)(config-subif)#ipv6 mld snooping
To view if IPv6 MLD snooping is enabled:
(host)(config-subif)#show ipv6 mld interface
To view the MLD Group information:
(host)(config) #show ipv6 mld group
To modify IPv6 MLD parameters:
(host)(config) #ipv6 mld
(host)(config-mld) # query-interval <time in seconds (1-65535)>|query-response-interval <time in 1/10th of seconds (1-65535)|robustness-variable <value (2-10)>
To view MLD configuration:
(host)(config-subif)#show ipv6 mld config
When you enter the SSM Range ensure that the upstream router has the same range, else the multicast stream would be dropped.
Dynamic Multicast Optimization
When multiple clients are associated to an AP and when one client is subscribed for a multicast stream, all the clients associated to the AP receive the stream, as the packets are directed to the multicast MAC address. To restrict the multicast stream to only the subscribed clients, DMO sends the stream to the unicast MAC address of the subscribed clients. DMO is currently supported for both IPv4 and IPv6.
In the WebUI
You can configure the IPv6 DMO feature using the WebUI or CLI.
Using the WEBUI
To enable this feature using the WebUI:
1. Navigate to Configuration>Wireless>AP Configuration page.
2. Select the AP Group tab, click the AP Group you want to edit.
3. Expand the Wireless LAN menu, then expand the Virtual AP menu.
4. Select the Virtual AP profile for which you want to configure the Dynamic Multicast Optimization.
5. In the Basic tab under Broadcast/Multicast section configure the following parameters to enable multicasting: a. Select the Dynamic Multicast Optimization (DMO) checkbox, b. Use the Dynamic Multicast Optimization (DMO) Threshold field to set the maximum number of high-throughput stations in a multicast group.
6. Click Apply to save your changes.
In the CLI
To verify the DMO configuration, execute the following command:
136 | IPv6 Support ArubaOS 6.5.3.x | User Guide
(host) #show wlan virtual-ap
Limitations
The following are the MLDv2 limitations: n n n n
Controller cannot route multicast packets.
For mobility clients mld proxy should be used.
VLAN pool scenario stream is forwarded to clients in both the VLANs even if the client from one of the
VLANs is subscribed.
Dynamic Multicast Optimization is applicable for wired clients in controllers.
Debugging an IPv6 Controller
ArubaOS provides the following debug commands for IPv6: n n n n n n show ipv6 global
— displays if IPv6 is enabled globally or not show ipv6 interface
— displays the configured IPv6 address, and any duplicate addresses show ipv6 route/show datapath route ipv6
— displays the IPv6 routing information show ipv6 ra status
— displays the Router Advertisement status show Datapath session ipv6
— displays the IPv6 sessions created, and the sessions that are allowed show datapath frame
— displays the IPv6 specific counters
You can also use the debug options such as ping and tracepath for IPv6 hosts. You can either use the WebUI or the CLI to use the ping and tracepath options.
In the WebUI
1. To ping an IPv6 host, navigate to the Diagnostics > Network > Ping page, enter an IPv6 address, and click
Ping .
2. To trace the path of an IPv6 host, navigate to the Diagnostics > Network > Tracepath page, enter an
IPv6 address, and click Trace .
In the CLI
To ping an IPv6 host:
(host)#ping ipv6 <global-ipv6-address>
(host)#ping ipv6 interface vlan <vlan-id> <linklocal-address>
To trace the path of an IPv6 host:
(host)#tracepath <global-ipv6-address>
Provisioning an IPv6 AP
You can provision an IPv6 AP on an IPv6 controller. You can either configure a static IP address or obtain a dynamic IPv6 address via stateless-autoconfig. The controller can act as the default gateway for the IPv6 clients, if static IPv6 routes are set on the controller.
Starting with ArubaOS 6.3, a wired client can connect to the Ethernet interface of an IPv6 enabled AP.
You can provision an IPv6 AP using the WebUI or CLI.
In the WebUI
1. Navigate to the Configuration > AP Installation> Provision page and select the Provisioning tab.
ArubaOS 6.5.3.x
| User Guide IPv6 Support | 137
2. Select an AP and click Provision .
3. Under the Master Discovery section, enter the host controller IP address and the IPv6 address of the master controller.
4. To provision a static IP, select the Use the following IP address check box under the IP Settings section, and enter the following details: n
IPv6 Address/Prefix-lengths n n
Gateway IPv6 Address
DNS IPv6 Address
Ensure that CPSEC is disabled before rebooting the AP.
5. Click Apply and Reboot to bring the IPv6 AP up.
In the CLI
To provision a static IPv6 address:
(host)(config)# provision-ap
Enhancements to IPv6 Support on AP
This release of ArubaOS provides the following IPv6 enhancements on the AP: n n n
DNS based ipv6 controller discovery
FTP support for image upgrade in an IPv6 network
DHCPv6 client support
Monitoring Bandwidth Usage
Starting from ArubaOS 6.5, customers can monitor bandwidth usage by clients/hosts with IPv6 addresses, over radius protocol. The Framed-IPv6-Address attribute is used in accounting start, stop, and interim packets. A host can have multiple IPv6 addresses and all of them are tracked to check the usage, for billing purpose.
Filtering an IPv6 Extension Header (EH)
ArubaOS firewall is enhanced to process the IPv6 Extension Header (EH) to enable IPv6 packet filtering. You can now filter the incoming IPv6 packets based on the EH type. You can edit the packet filter options in the default EH, using the CLI. The default EH alias permits all EH types.
Execute the following commands to permit or deny the IPv6 packets matching an EH type:
(host)(config) #netexthdr default
(host)(config-exthdr) #eh <eh-type> permit | deny
To view the EH types denied:
(host) (config-exthdr) #show netexthdr default
Configuring a Captive Portal over IPv6
IPv6 is now enabled on the captive portal for user authentication on the Aruba controller. For user authentication, use the internal captive portal that is initiated from the controller. A new parameter captive has been added to the IPv6 captive portal session ACL:
(host) (config) #ipv6 user alias controller 6 svc-https captive
138 | IPv6 Support ArubaOS 6.5.3.x | User Guide
This release does not support external captive portal for IPv6. The captive portal authentication, customization of pages, and other attributes are same as IPv4.
You can configure captive portal over IPv6 (similar to IPv4) using the WebUI or CLI. For more information on configuration, see
Configuring Captive Portal in the Base Operating System on page 313 .
Working with IPv6 Router Advertisements (RAs)
ArubaOS enables the controllers to send router advertisements (RA) in an IPv6 network. Each host auto generates a link local address when you enable ipv6 on the host. The link local address allows the host to communicate between the nodes attached to the same link.
The IPv6 stateless autoconfiguration mechanism allows the host to generate its own addresses using a combination of locally available information and information advertised by the routers. The host sends a router solicitation multicast request for its configuration parameters in the IPv6 network. The source address of the router solicitation request can be an IP address assigned to the sending interface, or an unspecified address if no address is assigned to the sending interface.
The routers in the network respond with an RA. The RAs can also be sent at periodic intervals. The RA contains the network part of the Layer 3 IPv6 address (IPv6 Prefix). The host uses the IPv6 prefix provided by the RA; it generates the universally unique host part of the address (interface identifier), and combines the two to derive the complete address. To establish continuous connectivity to the default router, the host starts the neighbor reachability state machine for the router.
ArubaOS uses Radvd, an open source Linux IPv6 Router Advertisement daemon maintained by Litech Systems
Design.
You can perform the following tasks on the controller to enable, configure, and view the IPv6 RA status on a
VLAN interface: n n n
Configure IPv6 RA on a VLAN
Configure Optional Parameters for RA l
Configure neighbor discovery reachable time l l l l
Configure neighbor discovery retransmit time
Configure RA DNS
Configure RA hop-limit
Configure RA interval l l l l
Configure RA lifetime
Configure RA managed configuration flag
Configure RA MTU
Configure RA other configuration flag l l
Configure RA Preference
Configure RA prefix
View IPv6 RA Status
Configuring an IPv6 RA on a VLAN
You must configure the IPv6 RA functionality on a VLAN for it to send solicited/unsolicited router advertisements on the IPv6 network. You must configure the following for the IPv6 RA to be operational on a
VLAN:
ArubaOS 6.5.3.x
| User Guide IPv6 Support | 139
n n n
IPv6 global unicast address enable IPv6 RA
IPv6 RA prefix l l l l
The advertised IPv6 prefix length must be 64 bits for the stateless address autoconfiguration to be operational.
You can configure up to three IPv6 prefixes per VLAN interface.
Each IPv6 prefix must have an on-link interface address configured on the VLAN.
Ensure you configure the upstream routers to route the packets back to Aruba controller.
You can use the WebUI or CLI to configure the IPv6 RA on a VLAN.
Using WebUI
1. Navigate to the Configuration > Network > IP page and select the IP Interfaces tab.
2. Edit a VLAN # and select IP version as IPv6 .
3. To configure an IPv6 global unicast address, follow the steps below: a. Under Details, enter the IPv6 address and the prefix-length in the IP Address/Prefix-length field.
b. (Optional) Select the EUI64 Format check box, if applicable.
c. Click Add to add the address to the global address list.
4. To enable an IPv6 RA on a VLAN, select the Enable Router Advertisements (RA) check box under
Neighbor Discovery .
5. To configure an IPv6 RA prefix for a VLAN, follow the steps below: a. Under Neighbor Discovery , enter an IPv6 prefix in the IPv6 RA Prefix field.
b. Click Add to configure an IPv6 prefix for the VLAN.
You can add up to three IPv6 prefixes per VLAN interface.
6. Click Apply .
Using CLI
Execute the following commands to configure router advertisements on a VLAN:
(host)(config) #interface vlan <vlanid>
(host)(config-subif)#ipv6 address <prefix>/<prefix-length>
(host)(config-subif)#ipv6 nd ra enable
(host)(config-subif)#ipv6 nd ra prefix X:X:X:X::X/64
Configuring Optional Parameters for RAs
In addition to enabling the RA functionality, you can configure the following IPv6 neighbor discovery and RA options on a VLAN: n n n
Neighbor discovery reachable time – the time, in milliseconds, that a node assumes a neighbor is reachable after receiving a reachability confirmation.
Neighbor discovery retransmit time – the time, in milliseconds, between retransmitted Neighbor Solicitation messages.
RA DNS – the IPv6 recursive DNS Server for the VLAN.
l l
On Linux systems, clients must run the open rdnssd daemon to support the DNS server option.
Windows 7 does not support the DNS server option.
n
RA hop-limit – the IPv6 RA hop-limit value. It is the default value to be placed in the Hop Count field of the
IP header for outgoing (unicast) IP packets.
140 | IPv6 Support ArubaOS 6.5.3.x | User Guide
n n n n n n
RA interval – the maximum and minimum time interval between sending unsolicited multicast router advertisements from the interface, in seconds.
RA lifetime – the lifetime associated with the default router in seconds. A value of zero indicates that the router is not a default router and will not appear on the default router list. The router lifetime applies only to the router's usefulness as a default router; it does not apply to information contained in other message fields or options.
RA managed configuration flag (Enable DHCP for address) – a flag that indicates that the hosts can use the
DHCP server for address autoconfiguration besides using RAs.
RA maximum transmission unit (MTU) – the maximum transmission unit that all the nodes on a link use.
RA other configuration flag (Enable DHCP for other information – a flag that indicates that the hosts can use the administered (stateful) protocol for autoconfiguration of other (non-address) information.
RA preference – the preference associated with the default router.
You can use the WebUI or CLI to configure these options.
It is recommended that you retain the default value of the RA interval to achieve better performance.
If you enable RAs on more than 100 VLAN interfaces, some of the interfaces may not send out the RAs at regular intervals.
In the WebUI
1. Navigate to the Configuration > Network > IP page.
2. Select the IP Interfaces tab.
3. Edit the VLAN on which you want to configure the neighbor discovery or RA options.
4. Select IP Version as IPv6 .
5. Under Neighbor Discovery , configure the following neighbor discovery and RA options for the VLAN based on your requirements: a. Enter a value in the Reachable Time field. The allowed range is 0-3,600,000 msec. The default value is zero.
b. Enter a value in the Retransmit Time field. The allowed range is 0-3,600,000 msec.he default value is zero.
c. Enter a DNS server name in the IPv6 Recursive DNS Server field.
d. Enter a hop-limit value in the RA hop-limit field. The allowed range is 1-255. The default value is 64.
e. Enter the maximum interval value in the RA Interval(sec) field. Allowed range is 4-1800 seconds.
Default value is 600 seconds.
f. Enter a value in the RA Minimum Interval(sec) field. Allowed range is 3-0.75 times the maximum RA interval value in seconds. The default minimum value is 0.33 times the maximum RA interval value g. Enter a value in the RA Lifetime field. A value of zero indicates that the router is not a default router.
Apart from a zero value, the allowed range for the lifetime value is the RA interval time to 9,000 seconds.
The default and minimum value is three times the RA interval time.
h. Select the DHCP for address check box to enable the hosts to use the DHCP server for address autoconfiguration apart from any addresses auto configured using the RA.
i.
Enter a value in the RA MTU Option option. The allowed range is 1,280-maximum MTU allowed for the link.
j.
Select the DHCP for Other Address check box to enable the hosts to use the DHCP server for autoconfiguration of other (non-address) information.
ArubaOS 6.5.3.x
| User Guide IPv6 Support | 141
k. Select the router preference as High , Medium , or Low .
6. Click Apply.
In the CLI
Execute the following CLI commands to configure the neighbor discovery and RA options for a VLAN interface:
To configure neighbor discovery reachable time:
(host)(config) #interface vlan <vlan-id>
(host)(config-subif)#ipv6 nd reachable-time <value>
To configure neighbor discovery retransmit time:
(host)(config-subif)#ipv6 nd retransmit-time <value>
To configure IPv6 recursive DNS server:
(host)(config-subif)#ipv6 nd ra dns X:X:X:X::X
To configure RA hop-limit:
(host)(config-subif)#ipv6 nd ra hop-limit <value>
To configure RA interval:
(host) (config-subif)#ipv6 nd ra interval <value> <min-value>
To configure RA lifetime:
(host)(config-subif)#ipv6 nd ra life-time <value>
To enable hosts to use DHCP server for stateful address autoconfiguration:
(host)(config-subif)#ipv6 nd ra managed-config-flag
To configure maximum transmission unit for RA:
(host)(config-subif)#ipv6 nd ra mtu <value>
To enable hosts to use DHCP server for other non-address stateful autoconfiguration:
(host)(config-subif)#ipv6 nd ra other-config-flag
To specify a router preference:
(host)(config-subif)#ipv6 nd ra preference [High | Low | Medium]
To view the IPv6 RA status on the VLAN interfaces:
(host) #show ipv6 ra status
IPv6 Router Advertisement Proxy
An IPv6 network deployment typically has one or more upstream routers to delegate IPv6 prefixes through
Router Advertisements (RA) to clients. When a client connects to the network, it would begin with sending
Router Solicitations or DHCP IPv6 requests. In case of Stateless Address Auto-configuration (SLAAC) using RAs where clients sends Router Solicitations (RS), upstream routers can either respond with unicast (L2/L3) RA or with multicast RA. Whenever a new client joins the network, a unicast or a multicast RA is sent to from the router to the client. If it is a multicast packet then existing clients also receive the RA, which results in increasing the traffic. Starting from ArubaOS 6.5.1.0, this issue is addressed by enabling IPv6 proxy RA to snoop incoming unsolicited Router Advertisement and Router Solicitations packets.
You can enable IPv6 RA proxy using the CLI and WebUI.
In the WebUI
1. Navigate to the Configuration > Advanced Services > Stateful Firewall page and select the Global
Setting tab.
2. Select IPV6 Proxy Router Advertisement Enable check box.
142 | IPv6 Support ArubaOS 6.5.3.x | User Guide
3. Click Apply .
In the CLI
Execute the following command to configure an interval for proxy Router Advertisement:
(host)(config) #ipv6 proxy-ra interval
Execute the following command to enable the proxy Router Advertisement:
(host)(config) #ipv6 proxy-ra
Execute the following command to view the status of the IPv6 proxy Router Advertisement:
(host) #show ipv6 ra proxy
IPv6 RA Proxy status: enabled
IPv6 RA Proxy interval: 600
RADIUS Over IPv6
ArubaOS provides support for RADIUS authentication server over IPv6. You can configure an IPv6 host or specify an FQDN that can resolve to an IPv6 address for RADIUS authentication. The RADIUS server is in IPv4 mode by default. You must enable the RADIUS server in IPv6 mode to resolve the specified FQDN to IPv6 address.
You can only configure the global IPv6 address as the host for the Radius server in IPv6 mode.
You can configure the IPv6 host for the RADIUS server using the WebUI or CLI.
In the CLI
You must enable the enable-ipv6 parameter to configure the RADIUS server in IPv6 mode.
(host)(config) #aaa authentication-server radius IPv6
(host)(RADIUS Server "IPv6") #enable-ipv6
Configure an IPv6 address as the host for RADIUS server using the following command:
(host)(RADIUS Server "IPv6") #host <ipv6-address>
The <host> parameter can also be a fully qualified domain name that can resolve to an IPv6 address.
To resolve FQDN, you must configure the DNS server name using the ip name-server <ip4addr> command.
You can configure an IPv6 address for the NAS-IP parameter using the following CLI command:
(host) (RADIUS Server "Ipv6") #nas-ip6 <IPv6 address>
You can configure an IPv6 address for the Source Interface parameter using the following CLI command:
(host) (RADIUS Server "Ipv6") # source-interface vlan <vland-id> ip6addr <ip6addr>
Use the following CLI command to configure an IPv6 address for the global NAS IP which the controller uses to communicate with all the RADIUS servers:
(host) (config) #ipv6 radius nas-ip6 <IPv6 address>
You can also configure an IPv6 global source-interface for all the RADIUS server requests using the following commands:
(host)(config) #ipv6 radius source-interface loopback
(host)(config) #ipv6 radius source-interface vlan <vlan-id> <ip6addr>
ArubaOS 6.5.3.x
| User Guide IPv6 Support | 143
In the WebUI
To configure an IPv6 host for a RADIUS server:
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select RADIUS Server to display the RADIUS server List.
3. Select the required RADIUS server from the list to go to the Radius server page.
4. To enable the RADIUS server in IPv6 mode select the Enable IPv6 check box.
5. To configure an IPv6 host for the selected RADIUS server specify an IPv6 address or an FQDN in the Host field.
6. Click Apply .
To configure an IPv6 address for the NAS-IP:
1. Select the Advanced tab.
2. Specify an IPv6 address in the NAS IPv6 field.
3. Click Apply .
To configure an IPv6 global source-interface:
1. Select the Advanced tab.
2. To configure the IPv6 loopback interface as the source interface, select loopback from the Source
Interface v6 drop-down list.
3. To configure a VLAN interface as the source interface, specify the VLAN interface and the IPv6 address in the Source Interface v6 field.
4. Click Apply .
Radius Accounting for IPv6 Clients
Starting from ArubaOS 6.5, customers can monitor bandwidth usage by clients/hosts with IPv6 addresses over
Radius Accounting for IPv6 Clients (RADIUS) protocol. The Framed-IPv6-Address attribute is used in accounting start, stop, and interim packets. A host can have multiple IPv6 addresses and all of them are tracked to check the usage for billing purpose.
TACACS Over IPv6
ArubaOS provides support for TACACS authentication server over IPv6. You can configure the global IPv6 address as the host for TACACS authentication using CLI or WebUI.
In the CLI
(host)(config) #aaa authentication-server tacacs IPv6
(host)(TACACS Server "IPv6") #host <ipv6-address>
In the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select TACACS Server to display the Server List.
3. Select the required server from the list to go to the TACACS server page.
4. To configure an IPv6 host for the selected server, specify an IPv6 address in the Host field.
5. Click Apply .
144 | IPv6 Support ArubaOS 6.5.3.x | User Guide
DHCPv6 Server
The DHCPv6 server enables network administrators to configure stateful/stateless options and manage dynamic IPv6 users connecting to a network. You can also configure domain name server using DHCPv6.
You can configure IPv6 pools with various configurations such as lease duration, DNS server, vendor specific options, and user defined options using DHCPv6. You can also exclude IPv6 addresses from subnets.
Controller IPv6 addresses, VLAN interface IPv6 addresses, and DNS server addresses are excluded from use by default.
Similar to DHCPv4, a DHCPv6 server pool is associated with a VLAN only through the IPv6 address configured in that VLAN interface. A VLAN interface can have a maximum of three global unicast addresses, but only one
DHCPv6 pool.
DHCPv6 server supports stateless configuration of clients with options apart from the network addresses described in RFC 3736.
Points to Remember
n n n
Similar to IPv4, the default router configuration is not required for IPv6 pools as IPv6 compliant routers will send RAs. The RA source address will be the default-gateway for the clients.
ArubaOS does not support DHCPv6 relay and Hospitality feature on DHCPv6.
IPv6 clients will not get a global IPv6 address if a previous DHCP binding exists.
DHCP Lease Limit
The following table provides the maximum number of DHCP leases (both v4 and v6) supported per controller platform:
There is a new enforcement to the existing DHCP limit during configuration.
Table 36: DHCP Lease Limits
Platform
7005
7010
7024
7030
7205
7210
7220
7240
DHCP Lease Limit
512
1024
1024
2048
4096
5120
10240
15360
Configuring DHCPv6 Server
You must enable the global DHCPv6 knob for the DHCPv6 functionality to be operational. You can enable and configure DHCPv6 server using the WebUI or CLI.
ArubaOS 6.5.3.x
| User Guide IPv6 Support | 145
In the WebUI
1. Navigate to Configuration > Network > IP page and select the DHCP Server tab.
2. Select the IPv6 DHCP Server check box to enable DHCPv6 globally.
3. If there are addresses that should not be assigned in the subnetwork: a. Under Excluded Address Range , click Add to create a list of IPv6 excluded address.
b. Enter the excluded IPv6 address range in IPv6 Excluded Range and click Done . The specified address range gets added to the IPv6 Excluded Address list box. The starting IP address in the Exclude
Address Range should always contain a unique value, if the IP address is already present, then the existing IP address is replaced with a new one, and a warning is displayed.
c. Click Apply .
4. Under Pool Configuration , click Add to create a new DHCP server pool or click Edit to modify an existing
DHCP server pool.
To enable the DHCPv6 Server functionality on an interface, select the IP Interfaces tab, edit the VLAN interface, and select a DHCP pool from the drop-down list under the DHCP server section. Ensure that the IP version of the VLAN interface is IPv6.
5. Select IP Version as IPv6 to create a DHCPv6 pool.
6. Enter a name in Pool Name to configure an IPv6 pool name.
7. Enter an IPv6 address in DNS Servers to configure an IPv6 DNS server.
To configure multiple DNS servers, enter the IPv6 addresses separated by space.
8. Enter a value in Domain Name to configure the domain name.
9. Enter the number of days, hours, minutes, and seconds in Lease to configure the lease time. The default value is 12 hours.
10.Specify an IPv6 prefix in Network to configure an IPv6 network.
11.Enter the following details under Option to configure client specific DHCPv6 options.
a. Specify the option code in Option .
b. Select IP or text from the IP/Text drop-down list.
c. Enter a value in Value . If you selected IP in step b , then you must enter a valid IPv6 address in this field.
d. Click Add .
12.Click
Apply .
In the CLI
To enable the DHCPv6 service you can use the following command:
(host)(config) #service dhcpv6
To configure a domain name server, execute the following commands:
(host)(config) #ipv6 dhcp pool <pool-name>
(host)(config-dhcpv6)#dns-server <ipv6-address>
To configure a domain name, use the following command:
(host)(config-dhcpv6)#domain-name <domain>
To configure DHCPv6 lease time, use the following command:
(host)(config-dhcpv6)#lease <days> <hours> <minutes> <seconds>
The default value is 12 hours.
146 | IPv6 Support ArubaOS 6.5.3.x | User Guide
To configure a DHCP network, use the following command:
(host)(config-dhcpv6)#network <network-prefix>
To configure a client specific option, use the following command:
(host)(config-dhcpv6)#option <code> [ip <ipv6-address> | text <string>]
To configure DHCP server preference, use the following command:
(host)(config-dhcpv6)#preference <value>
To enable DHCPv6 Server functionality on an interface, use the following command:
(host) (config) #interface vlan <vlan-id>
(host) (config-subif) #ipv6 dhcp server <pool-name>
The configured DHCPv6 pool subnet must match the interface prefix for DHCPv6 Server to be active.
To configure the IPv6 excluded address range for the DHCPv6 server, use the following command:
(host)(config)#ipv6 dhcp excluded-address <low-address> [<high-address>]
You can view the DHCPv6 server settings, statistics, and binding information using the CLI.
To view the DHCPv6 database, use the following command:
(host)#show ipv6 dhcp database
You can also view the DHCPv6 database for a specific pool, use the following command:
(host) (config) #show ipv6 dhcp database [pool <pool-name>]
(host) (config) #show ipv6 dhcp database pool DHCPv6
To view the DHCPv6 binding information, use the following command:
(host)# show ipv6 dhcp binding
To clear all the DHCPv6 bindings, use the following command:
(host)# clear ipv6 dhcp binding
To view the DHCPv6 server statistics, use the following command:
(host)(config) #show ip dhcp statistics
To view the DHCPv6 active pools, use the following command:
(host) #show ipv6 dhcp active-pools
Understanding ArubaOS Supported Network Configuration for
IPv6 Clients
ArubaOS provides wired or wireless clients using IPv6 addresses with services such as firewall functionality, layer-2 authentication, and, with the installation of the Policy Enforcement Firewall Next Generation (PEFNG), identity-based security. The Aruba controller does not provide routing or Network Address Translation to IPv6 clients (see
Understanding IPv6 Exceptions and Best Practices on page 154
).
Supported Network Configuration
Clients can be wired or wireless and use IPv4 and/or IPv6 addresses. An external IPv6 router is recommended for a complete routing experience (dynamic routing). You can use the WebUI or CLI to display IPv6 client information.
On the controller, you can configure both IPv4 and IPv6 client addresses on the same VLAN.
ArubaOS 6.5.3.x
| User Guide IPv6 Support | 147
Understanding the Network Connection Sequence for Windows IPv6 Clients
This section describes the network connection sequence for Windows Vista/XP clients that use IPv6 addresses, and the actions performed by the AP and the controller.
1. The IPv6 client sends a Router Solicit message through the AP. The AP passes the Router Solicit message from the IPv6 client through the GRE tunnel to the controller.
2. The controller removes the 802.11 frame and creates an 802.3 frame for the Router Solicit message.
a. The controller authenticates the user, applies firewall policies, and bridges the 802.3 frame to the IPv6 router.
b. The controller creates entries in the user and session tables.
3. The IPv6 router responds with a Router Advertisement message.
4. The controller applies firewall policies, then creates an 802.11 frame for the Router Advertisement message.
The controller sends the Router Advertisement through the GRE tunnel to the AP.
5. The IPv6 client sends a Neighbor Solicitation message.
6. The IPv6 router responds with a Neighbor Advertisement message.
7. If the DHCP is required to provide IPv6 addresses, the DHCPv6 process is started.
8. The IPv6 client sends data.
9. The controller removes the 802.11 frame and creates an 802.3 frame for the data.
The controller authenticates the user, applies firewall policies and bridges the 802.3 frame to the IPv6 router. The controller creates entries in the user and session tables.
A client can have an IPv4 address and an IPv6 address, but the controller does not relate the states of the IPv4 and the IPv6 addresses on the same client. For example, if an IPv6 user session is active on a client, the controller will delete an IPv4 user session on the same client if the idle timeout for the IPv4 session is reached.
Understanding ArubaOS Authentication and Firewall Features that Support IPv6
This section describes ArubaOS features that support IPv6 clients.
Understanding Authentication
This release of ArubaOS only supports 802.1X authentication for IPv6 clients. You cannot configure layer-3 authentications to authenticate IPv6 clients.
Table 37: IPv6 Client Authentication
Authentication Method Supported for IPv6 Clients?
802.1X
Stateful 802.1X (with non-Aruba
APs)
Local database
Captive Portal
Yes
Yes
Yes
Yes
148 | IPv6 Support ArubaOS 6.5.3.x | User Guide
Authentication Method
VPN xSec
MAC-based
Supported for IPv6 Clients?
No
No (not tested)
Yes
You configure 802.1X authentication for IPv6 clients in the same way as for IPv4 client configurations. For more information about configuring 802.1X authentication on the controller, see
802.1X Authentication on page 265
.
This release does not support authentication of management users on IPv6 clients.
Working with Firewall Features
If you installed a Policy Enforcement Firewall Next Generation (PEFNG) license in the controller, you can configure firewall functions for IPv6 client traffic. While these firewall functions are identical to firewall functions for IPv4 clients, you need to explicitly configure them for IPv6 traffic. For more information about firewall policies, see
Understanding Global Firewall Parameters on page 399
.
Voice-related and NAT firewall functions are not supported for IPv6 traffic.
Table 38: IPv6 Firewall Parameters
Parameter
Monitor Ping Attack (per
30 seconds)
Monitor TCP SYN Attack rate (per 30 seconds)
Monitor IP Session Attack
(per 30 seconds)
Deny Inter User Bridging
Deny All IP Fragments
Description
Number of ICMP pings per 30 second, which if exceeded, can indicate a denial of service attack. Valid range is 1-16384 pings per 30 seconds.
Recommended value is 120.
Default: No default
Number of TCP SYN messages per 30 second, which if exceeded, can indicate a denial of service attack. Valid range is 1-16384 pings per 30 seconds.
Recommended value is 960.
Default: No default
Number of TCP or UDP connection requests per 30 second, which if exceeded, can indicate a denial of service attack. Valid range is 1-16384 requests per 30 seconds.
Recommended value is 960.
Default: No default
Prevents the forwarding of Layer-2 traffic between wired or wireless users. You can configure user role policies that prevent Layer-3 traffic between users or networks but this does not block Layer-2 traffic. This option can be used to prevent traffic, such as Appletalk or IPX, from being forwarded.
Default: Disabled
Drops all IP fragments.
NOTE: Do not enable this option unless instructed to do so by an Aruba representative.
Default: Disabled
ArubaOS 6.5.3.x
| User Guide IPv6 Support | 149
Table 38: IPv6 Firewall Parameters
Parameter Description
Enforce TCP Handshake
Before Allowing Data
Prohibit IP Spoofing
Prohibit RST Replay Attack When enabled, closes a TCP connection in both directions if a TCP RST is received from either direction. You should not enable this option unless instructed to do so by an Aruba representative.
Default: Disabled
Session Mirror
Destination
Destination (IPv4 address or controller port) to which mirrored session packets are sent. You can configure IPv6 flows to be mirrored with the session ACL “mirror” option. This option is used only for troubleshooting or debugging.
Default: N/A
Session Idle Timeout
Prevents data from passing between two clients until the three-way TCP handshake has been performed. This option should be disabled when you have mobile clients on the network, as enabling this option will cause mobility to fail. You can enable this option if there are no mobile clients on the network.
Default: Disabled
Enables detection of IP spoofing (where an intruder sends messages using the IP address of a trusted client). When you enable this option, IP and MAC addresses are checked for each ARP request/response. Traffic from a second MAC address using a specific IP address is denied, and the entry is not added to the user table.
Possible IP spoofing attacks are logged and an SNMP trap is sent.
Default: Disabled
Per-packet Logging
IPv6 Enable
Set the time, in seconds, that a non-TCP session can be idle before it is removed from the session table. Specify a value in the range 16–259 seconds. You should not set this option unless instructed to do so by an Aruba representative.
Default: 30 seconds
Enables logging of every packet if logging is enabled for the corresponding session rule. Normally, one event is logged per session. If you enable this option, each packet in the session is logged. You should not enable this option unless instructed to do so by an Aruba representative, as doing so may create unnecessary overhead on the controller.
Default: Disabled (per-session logging is performed)
Enables IPv6 globally.
The following examples configure attack rates and the session timeout for IPv6 traffic.
To configure the firewall function via the WebUI:
1. Navigate to the Configuration > Advanced Services > Stateful Firewall > Global Setting page.
2. Under the IPv6 column, enter the following: n
For Monitor Ping Attack , enter 15 n n
For Monitor IP Session Attack , enter 25
For Session Idle Timeout , enter 60
3. Click Apply .
To configure firewall functions using the command line interface, issue the following commands in config mode: ipv6 firewall attack-rate ping 15 ipv6 firewall attack-rate session 25 ipv6 firewall session-idle-timeout 60
150 | IPv6 Support ArubaOS 6.5.3.x | User Guide
Understanding Firewall Policies
A user role, which determines a client’s network privileges, is defined by one or more firewall policies. A firewall policy consists of rules that define the source, destination, and service type for specific traffic, and whether you want the controller to permit or deny traffic that matches the rule.
You can configure firewall policies for IPv4 traffic or IPv6 traffic, and apply IPv4 and IPv6 firewall policies to the same user role. For example, if you have employees that use both IPv4 and IPv6 clients, you can configure both IPv4 and IPv6 firewall policies and apply them both to the “employee” user role.
The procedure to configure an IPv6 firewall policy rule is similar to configuring a firewall policy rule for IPv4 traffic, but with some differences.
Table 18 describes the required and optional parameters for an IPv6 firewall policy rule.
Table 39: IPv6 Firewall Policy Rule Parameters
Field Description
Source
(required)
Source of the traffic: n any : Acts as a wildcard and applies to any source address.
n n n user : This refers to traffic from the wireless client.
host : This refers to traffic from a specific host. When this option is chosen, you must configure the IPv6 address of the host. For example,
2002:d81f:f9f0:1000:c7e:5d61:585c:3ab.
network : This refers to a traffic that has a source IP from a subnet of IP addresses.
When you chose this option, you must configure the IPv6 address and network mask of the subnet. For example, 2002:ac10:fe:: ffff:ffff:ffff::.
n alias : This refers to using an alias for a host or network.
NOTE: This release does not support IPv6 aliases. You cannot configure an alias for an IPv6 host or network.
Destination of the traffic, which you can configure in the same manner as Source.
Destination
(required)
Service
(required)
Action
(required)
Log (optional)
NOTE: Voice over IP services are unavailable for IPv6 policies.
Type of traffic: n any : This option specifies that this rule applies to any type of traffic.
n n tcp : Using this option, you configure a range of TCP port(s) to match the rule to be applied.
udp : Using this option, you configure a range of UDP port(s) to match the rule to be applied.
n n service : Using this option, you use one of the pre-defined services (common protocols such as HTTPS, HTTP, and others) as the protocol to match the rule to be applied. You can also specify a network service that you configure by navigating to the
Configuration > Advanced Services > Stateful Firewall > Network Services page.
protocol : Using this option, you specify a different layer 4 protocol (other than
TCP/UDP) by configuring the IP protocol value.
The action that you want the controller to perform on a packet that matches the specified criteria.
n n permit: Permits traffic matching this rule.
drop: Drops packets matching this rule without any notification.
NOTE: The only actions for IPv6 policy rules are permit or deny; in this release, the controller cannot perform network address translation (NAT) or redirection on IPv6 packets. You can specify options such as logging, mirroring, or blacklisting (described below).
Logs a match to this rule. This is recommended when a rule indicates a security breach, such as a data packet on a policy that is meant only to be used for voice calls.
ArubaOS 6.5.3.x
| User Guide IPv6 Support | 151
Table 39: IPv6 Firewall Policy Rule Parameters
Field Description
Mirror
(optional)
Queue
(optional)
Time Range
(optional)
Black List
(optional)
TOS (optional)
802.1p Priority
(optional)
Mirrors session packets to a datapath or remote destination specified in the IPv6 firewall function (see “Session Mirror Destination” in
). If the destination is an IP address, it must be an IPv4 IP address.
The queue in which a packet matching this rule should be placed. Select High for higher priority data, such as voice, and Low for lower priority traffic.
Time range for which this rule is applicable. You configure time ranges in the
Configuration > Security > Access Control > Time Ranges page.
Automatically blacklists a client that is the source or destination of traffic matching this rule. This option is recommended for rules that indicate a security breach where the blacklisting option can be used to prevent access to clients that are attempting to breach the security.
Value of type of service (TOS) bits to be marked in the IP header of a packet matching this rule when it leaves the controller.
Value of 802.1p priority bits to be marked in the frame of a packet matching this rule when it leaves the controller.
The following example creates a policy "ipv6-web-only" that allows only web (HTTP and HTTPS) access for IPv6 clients and assigns the policy to the user role “web-guest."
The user role “web-guest” can include both IPv6 and IPv4 policies, although this example only shows configuration of an IPv6 policy.
Creating an IPv6 Firewall Policy
Following the procedure below to create an IPv6 firewall policy via the WebUI.
1. Navigate to the Configuration > Security > Access Control > Policies page.
2. Click Add to create a new policy.
3. Enter ipv6-web-only for the Policy Name.
4. To configure a firewall policy, select Session for Policy Type.
5. Click Add to add a rule that allows HTTP traffic.
a. Under IP Version column, select IPv6 .
b. Under Source , select network from the drop-down list.
c. For Host IP , enter 2002:d81f:f9f0:1000:: .
d. For Mask , enter 64 as the prefix-length.
e. Under Service , select service from the drop-down list.
f. Select svc-http from the scrolling list.
g. Click Add .
6. Click Add to add a rule that allows HTTPS traffic.
a. Under IP Version column, select IPv6.
b. Under Source, select network from the drop-down list.
c. For Host IP , enter 2002:d81f:f9f0:1000:: .
d. For Mask , enter 64 as the prefix-length.
e. Under Service , select service from the drop-down list.
152 | IPv6 Support ArubaOS 6.5.3.x | User Guide
.
f. Select svc-https from the scrolling list.
g. Click Add .
Rules can be reordered using the up and down arrow buttons provided for each rule.
7. Click Apply . The policy is not created until the configuration is applied.
To create an IPv6 firewall policy using the command-line interface, issue the following commands in config mode: ip access-list session ipv6-web-only
ipv6 network 2002:d81f:f9f0:1000::/64 any svc-http permit
ipv6 network 2002:d81f:f9f0:1000::/64 any svc-https permit
Assigning an IPv6 Policy to a User Role
To assign an IPv6 policy using the WebUI:
1. Navigate to the Configuration > Security > Access Control > User Roles page.
2. Click Add to create a new user role.
3. Enter web-guest for Role Name.
4. Under Firewall Policies, click Add . From Choose from Configured Policies, select the “ipv6-web-only” IPv6 session policy from the list.
5. Click Done to add the policy to the user role.
6. Click Apply .
To assign an IPv6 policy to a user role via the command-line interface, issue the following command in config mode: user-role web-guest
access-list session ipv6-web-only position 1
Understanding DHCPv6 Passthrough/Relay
The controller forwards DHCPv6 requests from IPv6 clients to the external IPv6 router. On the external IPv6 router, you must configure the controller’s IP address as the DHCP relay. You do not need to configure an IP helper address on the controller to forward DHCPv6 requests.
Managing IPv6 User Addresses
Viewing or Deleting User Entries
To view or delete IPv6 user entries via the WebUI:
1. Navigate to the Monitoring > Controller > Clients page.
2. Click the IPv6 tab to display IPv6 clients.
3. To delete an entry in the IPv6 client display, click the radio button to the left of the client and then click
Disconnect .
To view user entries for IPv6 clients using the command line interface, use the show user-table command in enable mode. To delete a user entry for an IPv6 client, access the CLI in config mode and use the aaa ipv6 user delete command. For example:
(host)(config) #aaa ipv6 user delete 2002:d81f:f9f0:1000:e409:9331:1d27:ef44
ArubaOS 6.5.3.x
| User Guide IPv6 Support | 153
Understanding User Roles
An IPv6 user or a client can inherit the corresponding IPv4 roles. A user or client entry on the user table will contain the user or client’s IPv4 and IPv6 entries. After captive-portal authentication, a IPv4 client can acquire a different role. This role is also updated on the client’s IPv6 entry in the user table.
Viewing Datapath Statistics for IPv6 Sessions
To view datapath session statistics for individual IPv6 sessions, access the command-line interface in enable mode and issue the command show datapath session ipv6
. To display the user entries in the datapath, access the command-line interface in enable mode, and issue the command show datapath user ipv6
. For details on each of these commands and the output they display, refer to the ArubaOS Command Line
Reference Guide .
n n n n n n
Understanding IPv6 Exceptions and Best Practices
The IPv6 best practices are provided below:
Ensure that you enable IPv6 globally.
The uplink port must be trusted. This is the same behavior as IPv4.
Ensure that the validuser session ACL does not block IPv6 traffic.
There must not be any ACLs that drop ICMPv6 or DHCPv6 traffic. It is acceptable to drop DHCPv6 traffic if the deployment uses Stateless Address Auto Configuration (SLAAC) only.
If an external device provides RA: l l
It is not recommended to advertise too many prefixes in RA.
The controller supports a maximum of four IPv6 user entries in the user table. If a client uses more than four IPv6 addresses at a time, the user table is refreshed with the latest four active entries without disrupting the traffic flow. However, this may have some performance impact.
Enable BCMC Optimization under interface VLAN to drop any random IPv6 multicast traffic. DHCPv6, ND,
NS, and RA traffic are not dropped when you enable this option.
It is recommended to enable BCMC Optimization only if mDNS traffic is not used in the network, as mDNS traffic gets dropped if this option is enabled.
n n
It is not recommended to enable preemption on the master redundancy model. If preemption is disabled and if there is a failover, the new primary controller remains the primary controller even when the original master is online again. The new primary controller does not revert to its original state unless forced by the administrator. Disabling preemption prevents the master from “flapping” between two controllers and allows the administrator to investigate the cause of the outage.
While selecting a source address, the number of common bits between each source address in the list, is checked from the left most bit. This is followed by selection of the source address that has the maximum number of matching bits with the destination address. If more than one source addresses has the same number of matching bits with the destination address, the kernel selects that source address that is most recently configured on the system. It is essential that the administrator/user configures the network appropriately, if a particular VLAN interface needs to be selected as the source. For example, in case of
Dot1x authentication the administrator/user can configure the source interface appropriately so that it is selected for authentication process. For more information on IPv6 source address selection, see RFC 3848 .
ArubaOS does not support the following functions for IPv6 clients: n n
The controller offers limited routing services to IPv6 clients, so it is recommended to use an external IPv6 router for a complete routing experience (dynamic routing).
VoIP ALG is not supported for IPv6 clients.
154 | IPv6 Support ArubaOS 6.5.3.x | User Guide
n n n n n
Remote AP supports IPv6 clients in tunnel forwarding mode only. The Remote AP bridge and split-tunnel forwarding modes do not support IPv6 clients. Secure Thin Remote Access Point (STRAP) cannot support
IPv6 clients.
IPSec is not supported over IPv6.
IPv6 Auto configuration and IPv6 Neighbor Discovery mechanisms does not apply to IPv6 tunnels.
Tunnel Encapsulation Limit, Tunnel-group, and MTU discovery options on IPv6 tunnels are not supported.
IPSec is not supported in this release, so IPv6 GRE cannot be used for master-local setup.
ArubaOS 6.5.3.x
| User Guide IPv6 Support | 155
Chapter 6
Link Aggregation Control Protocol
The ArubaOS implementation of Link Aggregation Control Protocol (LACP) is based on the standards specified in 802.3ad. LACP provides standardized means for exchanging information with partner systems, to form a
Link Aggregation Group (LAG). LACP avoids port channel misconfiguration.
Two devices (actor and partner) exchange LACP Data Units (DUs) when forming a LAG. Once multiple ports in the system have the same actor system ID, actor key, partner system ID, and partner key, they belong to the same LAG.
The maximum number of supported port-channels is eight. With the introduction of LACP, this number remains the same. A port-channel group (LAG) is created either statically or dynamically through LACP. This chapter contains the following topics: n n n
Understanding LACP Best Practices and Exceptions on page 156
LACP Sample Configuration on page 159
For information on configuring LACP on 220 Series, 270 Series, 320 Series and 330 Series access points, see
Aggregation Support on 220 Series, 270 Series, 320 Series, and 330 Series on page 593
Hashing is done using the source IP and destination IP of the received frame if the received frame is a IP packet. Hashing is done using the source MAC and destination MAC of the received frame if the received frame is a non-IP packet. This hashing algorithm is common for both IP Frames and non-IP Frames as described below:
The XOR operation performed on the source and destination addresses bitwise and the AND operation is performed on the result with the Hash Key size bitwise. Typically, the Hash Key size is 8.
n n n n n n n n n n
Understanding LACP Best Practices and Exceptions
LACP is disabled by default.
LACP depends on periodical Tx/Rx of LACP Data Units (LACPDUs). Any failure is noticed immediately and that port is removed from the LAG.
The maximum LAG supported per system is eight groups; each group can be created statically or through
LACP.
Each LAG can have up to eight member ports.
The LAG group identification (ID) range is 0–7 for both static (port-channel) and LACP groups.
When a port is added to a LACP LAG, it inherits the port-channel’s properties such as, VLAN membership, trunk status, and so on.
When a port is added to a LACP LAG, the port’s property (like speed) is compared to the existing port property. If there is a mismatch, the command is rejected.
The LACP commands cannot be configured on a port that is already a member of a static port-channel.
Similarly, if the group assigned in the command lacp group <number> already contains static port members, the command is rejected.
The port uses the group number as its actor admin key.
All ports use long timeout values (90 seconds) by default.
ArubaOS 6.5.3.x
| User Guide Link Aggregation Control Protocol | 156
n
The output of the command show interface port-channel now indicates if the LAG is created by LACP
(dynamic) or static configuration. If the LAG is created through LACP, you cannot add or delete any ports under that port channel. All other commands are allowed.
Configuring LACP
Two LACP configured devices exchange LACPDUs to form a link aggregation group (LAG). A device is configurable as an active or passive participant. In active mode, the device initiates DUs irrespective of the partner state; passive mode devices respond only to the incoming DUs sent by the partner device. Hence, to form a LAG group between two devices, one device must be an active participant. For detailed information on the LACP commands, see the ArubaOS 6.4.x Command-Line Interface Reference Guide .
In the CLI
LACPDUs exchange their corresponding system identifier/priority along with their port’s key/priority. This information determines the LAG of a given port. The LAG for a port is selected based on its keys. The port is placed in that LAG only when its system ID/key and partner's system ID/key matches the other ports in the
LAG (if the group has ports).
1. Enable LACP and configure the per-port specific LACP. The group number range is 0–7.
lacp group <group_number> mode {active | passive} n n
Active mode—the interface is in an active negotiating state. LACP runs on any link that is configured to be in the active state. The port in an active mode also automatically initiates negotiations with other ports by initiating LACP packets.
Passive mode—the interface is not in an active negotiating state. LACP runs on any link that is configured in a passive mode. The port in a passive mode responds to negotiations requests from other ports that are in an active mode. Ports in passive mode respond to LACP packets.
A port in a passive mode cannot set up a port channel (LAG group) with another port in a passive mode.
2. Set the timeout for the LACP session. The timeout value is the amount of time that a port-channel interface waits for a LACPDU from the remote system before terminating the LACP session. The default long timeout value is 90 seconds; short is 3 seconds.
lacp timeout {long | short}
3. Set the port priority.
lacp port-priority <priority_value>
The higher the priority value the lower the priority. The range is 1-65535 and the default is 255.
4. View your LACP configuration.
The port uses the group number +1 as the “actor admin key”. All the ports use the long timeout value (90 seconds) by default.
(host)#show lacp 0 neighbor
Flags: S - Device is requesting Slow LACPDUs
F - Device is requesting fast LACPDUs
A - Device is in active mode P - Device is in passive mode
Partner's information
---------------------
Port Flags Pri OperKey State Num Dev Id
----------- ----------- ---- ----------------
FE 1/1 SA 1 0x10 0x45 0x5 00:0b:86:51:1e:70
FE 1/2 SA 1 0x10 0x45 0x6 00:0b:86:51:1e:70
157 | Link Aggregation Control Protocol ArubaOS 6.5.3.x | User Guide
When a port in a LAG is misconfigured (the partner device is different than the other ports), or the neighbor timesout or can not exchange LACPDUs with the partner, the port status is displayed as “DOWN” (see the following example):
(host)#show lacp 0 internal
Flags: S - Device is requesting Slow LACPDUs
F - Device is requesting fast LACPDUs
A - Device is in active mode P - Device is in passive mode
Port
----
Flags
-----
FE 1/1 SA
Pri
1
AdminKey
---- --------
0x1
OperKey
-------- ----- ---- -------
0x1
State Num
0x45 0x2
Status
DOWN
FE 1/2 SA 1 0x1 0x1 0x45 0x3 UP
In the WebUI
Access LACP from the Configuration >Network >Port tabs. Use the drop-down list to enter the LACP values.
n n n n
LACP Group— the link aggregation group (LAG) number; the range is 0 to 7.
Mode— active negotiation state or not in an active negotiation state indicated by the passive option.
Priority—the port priority value; the range is 1-65535 and the default is 255.
Timeout— time out value for the LACP session. The long default is 90 seconds; the short default is 3 seconds.
For information on configuring LACP on 220 Series, 270 Series, 320 Series and 330 Series access points, see
Aggregation Support on 220 Series, 270 Series, 320 Series, and 330 Series on page 593
ArubaOS 6.5.3.x
| User Guide Link Aggregation Control Protocol | 158
LACP Sample Configuration
The following sample configuration is for FastEthernet (FE) port/slot 1/0, 1/1, and 1/2: interface fastethernet 1/0 description "FE1/0" trusted vlan 1-4094 lacp group 0 mode active
!
interface fastethernet 1/1 description "FE1/1" trusted vlan 1-4094 lacp timeout short lacp group 0 mode active
!
interface fastethernet 1/2 description "FE1/2" trusted vlan 1-4094 lacp group 0 mode passive
!
159 | Link Aggregation Control Protocol ArubaOS 6.5.3.x | User Guide
Chapter 7
OSPFv2
OSPFv2 (Open Shortest Path First) is a dynamic Interior Gateway routing Protocol (IGP) based on IETF RFC
2328. The OSPF uses the shortest or fastest routing path. Aruba’s implementation of OSPFv2 allows Aruba controllers to deploy effectively in a Layer 3 topology. Aruba controllers can act as default gateway for all clients and forward user packets to the upstream router. An Aruba controller can be used for Instant AP VPN termination from the branch office, and the OSPF on the controller can be used to redistribute branch routes into corporate OSPF domain. The information on this chapter is in the following sections: n n n n n
Understanding OSPF Deployment Best Practices and Exceptions on page 160
Understanding OSPFv2 by Example using a WLAN Scenario on page 161
Understanding OSPFv2 by Example using a Branch Scenario on page 162
Sample Topology and Configuration on page 165
n n n n n n n n
Understanding OSPF Deployment Best Practices and Exceptions
OSPF is a robust routing protocol addressing various link types and deployment scenarios. The Aruba implementation applies to two main use cases; WLAN Scenarios and Branch Scenario.
OSPF is disabled by default.
Aruba controllers support only one OSPF instance.
Convergence takes between 5 and 15 seconds.
All area types are supported.
Multiple configured areas are supported.
An Aruba controller can act as an ABR (Area border router).
OSPF supports VLAN and GRE tunnel interfaces.
To run OSPF over IPSec tunnels, a Layer 3 GRE tunnel is configured between two routers with GRE destination addresses as the inner address of the IPsec tunnel. OSPF is enabled on the Layer 3 GRE tunnel interface, and all of the OSPF control packets undergo GRE encapsulation before entering the IPsec tunnels.
The default MTU value for a Layer 3 GRE tunnel in an Aruba controller is 1100. When running OSPF over a
GRE tunnel between an Aruba controller and another vendor’s router, the MTU values must be the same on both sides of the GRE tunnel.
The following table provides information on the maximum OSPF routes supported for various platforms:
Table 40: Maximum OSPF Routes
Platform Branches
7210 8K
Routes
8K
7220
7240
16K
32K
16K
32K
Below are some guidelines regarding deployment and topology for this release of OSPFv2.
ArubaOS 6.5.3.x
| User Guide OSPFv2 | 160
n n n n n n
In the WLAN scenario, configure the Aruba controller and all upstream routers in totally stub area; in the
Branch scenario, configure as stub area so that the Branch controller can receive corporate subnets.
In the WLAN scenario upstream router, only configure the interface connected to the controller in the same area as the controller. This will minimize the number of local subnet addresses advertised by the upstream router to the controller.
Use the upstream router as the designated router (DR) for the link/interface between the controller and the upstream router.
The default MTU value for a Layer 3 GRE tunnel in an Aruba controller is 1100. When running OSPF over a
GRE tunnel between an Aruba controller and another vendor’s router, the MTU values must be the same on both sides of the GRE tunnel.
Do not enable OSPF on any uplink/WAN interfaces on the Branch Controller. Enable OSPF only on the Layer
3 GRE tunnel connecting the master controller.
Use only one physical port in the uplink VLAN interface that is connecting to the upstream router. This will prevent broadcasting the protocol PDUs to other ports and hence limit the number of adjacencies on the uplink interface to only one.
Understanding OSPFv2 by Example using a WLAN Scenario
In the WLAN scenario, the Aruba controller acts as a default gateway for all the clients, and talks to one or two upstream routers for redundancy. The controller advertises all the user subnet addresses as stub addresses to the routers via LSAs.
Totally stub areas see only default route and to the areas themselves.
n n
WLAN Topology
The controller (
Figure 29 ) is configured with VLAN 10 and VLAN 12 as user VLANs. These VLANs have clients on
the subnets, and the controller is the default router for those clients. VLAN 4 and VLAN 5 both have OSPF enabled. These interfaces are connected to upstream routers (Router 1 and Router 2). The OSPF interface cost on VLAN 4 is configured lower than VLAN 5. The IDs are: n
Aruba controller— 40.1.1.1
Router 1— 50.1.1.1
Router 2— 60.1.1.1
Figure 29 WLAN OSPF Topology
161 | OSPFv2 ArubaOS 6.5.3.x | User Guide
Based on the cost of the uplink interface, the default route from one of the upstream routers is installed in the forwarding information base (FIB) by the routing information base/route table manager (RIB/RTM) module.
WLAN Routing Table
View the controller routing table using the show ip route command:
(host)#show ip route
Codes: C - connected, O - OSPF, R - RIP, S - static
M - mgmt, U - route usable, * - candidate default
Below is the routing table for Router 1:
(router1) #show ip route
O
O
C
10.1.1.0/24 [1/0] via 4.1.1.1
12.1.1.0/24 [1/0] via 4.1.1.1
4.1.1.0 is directly connected, VLAN4
Below is the routing table for Router 2:
(router2) #show ip route
O
O
C
10.1.1.0/24 [2/0] via 5.1.1.1
12.1.1.0/24 [2/0] via 5.1.1.1
5.1.1.0 is directly connected, VLAN5
Understanding OSPFv2 by Example using a Branch Scenario
The branch office scenario has a number of remote branch offices with controllers talking to a central office via a concentrator/controller using site-to-site VPN tunnels or master-local IPsec tunnels. The central office controller is in turn talking to upstream routers (see
). In this scenario, the default route is normally pointed to the uplink router, in many cases the ISP. Configure the area as stub so that inter-area routes are also advertised enabling the branch office controller to reach the corporate subnets.
Branch Topology
All the OSPF control packets exchanged between the Branch and the central office controllers undergo GRE encapsulation before entering the IPsec tunnels. The controllers in the branch offices advertise all the user subnet addresses to the Central office controller as stub addresses in router LSA. The central office controller in turn forwards those router LSAs to the upstream routers.
ArubaOS 6.5.3.x
| User Guide OSPFv2 | 162
Figure 30 Branch OSPF Topology
All the branch office controllers, the Central office controller, and the upstream routers are part of a stub area.
Because the OSPF packets follow GRE encapsulation over IPsec tunnels, the Central office controller can be a controller or any vendor’s VPN concentrator. Regardless, the controller in the branch office will operate with other vendors seamlessly.
In
, the branch office controller is configured using VLAN 14 and VLAN 15. Layer 3 GRE tunnel is configured with IP address 20.1.1.1/24 and OSPF is enabled on the tunnel interface.
In the Central office controller, OSPF is enabled on VLAN interfaces 4, 5, and the Layer 3 GRE tunnel interface
(configured with IP address 20.1.1.2/24). OSPF interface cost on VLAN 4 is configured lower than VLAN 5.
Branch Routing Table
View the branch office controller routing table using the show ip route command:
(host)#show ip route
Codes: C - connected, O - OSPF, R - RIP, S - static
M - mgmt, U - route usable, * - candidate default
The routing table for the central office controller is below:
(host)#show ip route
Gateway of last resort is 4.1.1.2 to network 0.0.0.0
C
C
C
O*
O
O
0.0.0.0/0 [1/0] via 4.1.1.2*
14.1.1.0/24 [1/0] via 30.1.1.1*
15.1.1.0/24 [1/0] via 30.1.1.1*
4.1.1.0 is directly connected, VLAN4
5.1.1.0 is directly connected, VLAN5
20.1.1.0 is directly connected, Tunnel 1
The routing table for Router 1 is below:
(router1) #show ip route
O
O
C
14.1.1.0/24 [1/0] via 4.1.1.1
15.1.1.0/24 [1/0] via 4.1.1.1
4.1.1.0 is directly connected, VLAN4
The routing table for Router 2 is below:
(router2) #show ip route
O 14.1.1.0/24 [1/0] via 5.1.1.1
163 | OSPFv2 ArubaOS 6.5.3.x | User Guide
O
C
15.1.1.0/24 [1/0] via 5.1.1.1
5.1.1.0 is directly connected, VLAN5
Configuring OSPF
To configure general OSPF settings from the OSPF tab, perform the following steps:
1. Navigate to the Configuration >IP page (see
Figure 31 ). The Area and Excluded subnets are displayed in
table format. If not explicitly specified for OSPF, the router ID defaults to the switch IP.
Figure 31 General OSPF Configuration
2. Click Add to add an area (see
).
Figure 32 Add an OSPF Area
3. Configure the OSPF interface settings in the Configuration screen (
). If OSPF is enabled, the parameters contain the correct default values. You can edit the OSPF values only when you enable OSPF on the interface.
ArubaOS 6.5.3.x
| User Guide OSPFv2 | 164
Figure 33 Edit OSPF VLAN Settings
OSPF monitoring is available from an IP Routing sub-section ( Controller > IP Routing > Routing ). Both Static and OSPF routes are available in table format.
OSPF Interfaces and Neighboring information is available from the OSPF tab. The Interface information includes transmit (TX) and receive (RX) statistics.
Exporting VPN Client Addresses to OSPF
You can configure VPN client addresses so that they can be exported to OSPF and be advertised as host routes
(/32). Exporting applies to any VPN client address regardless of how it is assigned.
In the WebUI
1. Navigate to the Configuration > Advanced Services > All Profiles > VPN Authentication > default page.
2. (Optional) Regardless of how an authentication server is contacted, the Export VPN IP address as a route option causes any VPN client address to be exported to OSPF using IPC. Note that the Framed-IP-
Address attribute is assigned the IP address as long as any server returns the attribute. The Framed-IP-
Address value always has a higher priority than the local address pool.
3. Click Apply .
In the CLI
(host) (config) #aaa authentication vpn default
(host) (VPN Authentication Profile "default") #
(host) (VPN Authentication Profile "default") # export-route
Use the show ip ospf database command to show LSA types that are generated.
Sample Topology and Configuration
The figure below displays a sample OSPF topology followed by sample configurations of the Remote Branch 1,
Remote Branch 2, and the Central Office Controller (Active and Backup).
165 | OSPFv2 ArubaOS 6.5.3.x | User Guide
Figure 34 Sample OSPF Topology
Remote Branch 1
controller-ip vlan 30 vlan 16 vlan 30 vlan 31 vlan 32 interface gigabitethernet 1/0 description "GE1/0" trusted switchport access vlan 16
!
interface gigabitethernet 1/1 description "GE1/1" trusted switchport access vlan 30
!
interface gigabitethernet 1/2 description "GE1/2" trusted switchport access vlan 31
!
interface gigabitethernet 1/3 description "GE1/3" trusted switchport access vlan 32
!
interface vlan 16 ip address 192.168.16.251 255.255.255.0
!
ArubaOS 6.5.3.x
| User Guide OSPFv2 | 166
interface vlan 30 ip address 192.168.30.1 255.255.255.0
!
interface vlan 31 ip address 192.168.31.1 255.255.255.0
!
interface vlan 32 ip address 192.168.32.1 255.255.255.0
!
uplink wired priority 202 uplink cellular priority 201 uplink wired vlan 16 interface tunnel 2003 description "Tunnel Interface" ip address 2.0.0.3 255.0.0.0
tunnel source 192.168.30.1
tunnel destination 192.168.68.217
trusted ip ospf area 10.10.10.10
!
ip default-gateway 192.168.16.254
ip route 192.168.0.0 255.255.0.0 null 0
!
router ospf router ospf router-id 192.168.30.1
router ospf area 10.10.10.10 stub router ospf redistribute vlan 30-32
Remote Branch 2
controller-ip vlan 50
!
vlan 20 vlan 50 vlan 51 vlan 52
!
interface gigabitethernet 1/0 description "GE1/0" trusted switchport access vlan 20
!
interface gigabitethernet 1/1 description "GE1/1" trusted switchport access vlan 50
!
interface gigabitethernet 1/2 description "GE1/2" trusted switchport access vlan 51
!
interface gigabitethernet 1/3 description "GE1/3" trusted switchport access vlan 52
!
interface vlan 20 ip address 192.168.20.1 255.255.255.0
!
interface vlan 50 ip address 192.168.50.1 255.255.255.0
167 | OSPFv2 ArubaOS 6.5.3.x | User Guide
!
interface vlan 51 ip address 192.168.51.1 255.255.255.0
!
interface vlan 52 ip address 192.168.52.1 255.255.255.0
!
uplink wired priority 206 uplink cellular priority 205 uplink wired vlan 20 interface tunnel 2005 description "Tunnel Interface" ip address 2.0.0.5 255.0.0.0
tunnel source 192.168.50.1
tunnel destination 192.168.68.217
trusted ip ospf area 10.10.10.10
!
ip default-gateway 192.168.20.254
ip route 192.168.0.0 255.255.0.0 null 0
!
router ospf router ospf router-id 192.168.50.1
router ospf area 10.10.10.10 stub router ospf redistribute vlan 50-52
Central Office Controller—Active
localip 0.0.0.0 ipsec db947e8d1b383813a4070ab0799fa6246b80fc5cfcc3268f controller-ip vlan 225 vlan 68 vlan 100 vlan 225
!
interface gigabitethernet 1/0 description "GE1/0" trusted switchport access vlan 225
!
interface gigabitethernet 1/1 description "GE1/1" trusted switchport access vlan 100
!
interface gigabitethernet 1/2 description "GE1/2" trusted switchport access vlan 68
!
interface vlan 68 ip address 192.168.68.220 255.255.255.0
!
interface vlan 100 ip address 192.168.100.1 255.255.255.0
!
interface vlan 225 ip address 192.168.225.2 255.255.255.0
!
interface tunnel 2003 description "Tunnel Interface" ip address 2.1.0.3 255.0.0.0
tunnel source 192.168.225.2
ArubaOS 6.5.3.x
| User Guide OSPFv2 | 168
tunnel destination 192.168.30.1
trusted ip ospf area 10.10.10.10
!
interface tunnel 2005 description "Tunnel Interface" ip address 2.1.0.5 255.0.0.0
tunnel source 192.168.225.2
tunnel destination 192.168.50.1
trusted ip ospf area 10.10.10.10
!
master-redundancy master-vrrp 2 peer-ip-address 192.168.68.221 ipsec password123
!
vrrp 1 priority 120 authentication password123 ip address 192.168.68.217
vlan 68 preempt tracking vlan 68 sub 40 tracking vlan 100 sub 40 tracking vlan 225 sub 40 no shutdown
!
vrrp 2 priority 120 ip address 192.168.225.9
vlan 225 preempt tracking vlan 68 sub 40 tracking vlan 100 sub 40 tracking vlan 225 sub 40 no shutdown
!
ip default-gateway 192.168.68.1
ip route 192.168.0.0 255.255.0.0 null 0 router ospf router ospf router-id 192.168.225.1
router ospf area 10.10.10.10 stub router ospf redistribute vlan 100,225
!
Central Office Controller—Backup
localip 0.0.0.0 ipsec db947e8d1b383813a4070ab0799fa6246b80fc5cfcc3268f controller-ip vlan 225
!
interface gigabitethernet 1/0 description "GE1/0" trusted switchport access vlan 225
!
interface gigabitethernet 1/1 description "GE1/1" trusted switchport access vlan 100
!
interface gigabitethernet 1/2
169 | OSPFv2 ArubaOS 6.5.3.x | User Guide
description "GE1/2" trusted switchport access vlan 68
!
interface vlan 68 ip address 192.168.68.221 255.255.255.224
!
interface vlan 100 ip address 192.168.100.5 255.255.255.0
!
interface vlan 225 ip address 192.168.225.1 255.255.255.0
!
interface tunnel 2003 description "Tunnel Interface" ip address 2.1.0.3 255.0.0.0
tunnel source 192.168.225.1
tunnel destination 192.168.30.1
trusted ip ospf area 10.10.10.10
!
interface tunnel 2005 description "Tunnel Interface" ip address 2.1.0.5 255.0.0.0
tunnel source 192.168.225.1
tunnel destination 192.168.50.1
trusted ip ospf area 10.10.10.10
!
master-redundancy master-vrrp 2 peer-ip-address 192.168.68.220 ipsec password123
!
vrrp 1 priority 99 authentication password123 ip address 192.168.68.217
vlan 68 tracking vlan 68 sub 40 tracking vlan 100 sub 40 tracking vlan 225 sub 40 no shutdown
!
vrrp 2 priority 99 ip address 192.168.225.9
vlan 225 tracking vlan 68 sub 40 tracking vlan 100 sub 40 tracking vlan 225 sub 40 no shutdown
!
ip default-gateway 192.168.68.1
ip route 192.168.0.0 255.255.0.0 null 0
!
router ospf router ospf router-id 192.168.225.1
router ospf area 10.10.10.10 stub router ospf redistribute vlan 100,225
!
The following figure displays how the controller is configured for Instant AP VPN for different OSPF cases.
ArubaOS 6.5.3.x
| User Guide OSPFv2 | 170
Figure 35 Controller Not-So-Stubby-Area (NSSA) and Normal Area
Topology
n n n n n n
Area-10 is NSSA (Not-So-Stubby Area)
Area-11 is Normal area.
RAPNG AP-1 is configured to have a UP controller as its primary controller and a DOWN as secondary controller.
RAPNG AP-2 is configured to have a DOWN as its primary controller and a UP as secondary controller.
RAPNG AP-1 is configured to have a 201.201.203.0/24 L3-distributed network.
RAPNG AP-2 is configured to have a 202.202.202.0/24 L3-distributed network.
Observation
n n n
UP Controller will send Type-5 LSA (External LSA) of VPN route 201.201.203.0/24 to it’s upstream router,
Cisco-3750.
DOWN Controller will send Type-7 LSA (NSSA) of VPN route 202.202.202.0/24 to it’s upstream router,
Cisco-2950.
UP Controller will send a Type-4 asbr-summary LSA.
Configuring UP Controller
interface vlan 21 ip address 21.21.21.2 255.255.255.0
ip ospf area 0.0.0.11
!
router ospf router ospf area 0.0.0.11
router ospf redistribute rapng-vpn
!
The following commands displays the configuration and run time protocol details on UP Controller:
171 | OSPFv2 ArubaOS 6.5.3.x | User Guide
(host)#show ip route
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
C
C
C
C
C
V
O
S
S
S
S
S
S
S
S
O
O
Codes: C - connected, O - OSPF, R - RIP, S - static
M - mgmt, U - route usable, * - candidate default, V - RAPNG VPN
Gateway of last resort is Imported from DHCP to network 0.0.0.0 at cost 10
Gateway of last resort is Imported from CELL to network 0.0.0.0 at cost 10
O
O
Gateway of last resort is Imported from PPPOE to network 0.0.0.0 at cost 10
Gateway of last resort is 10.15.231.185 to network 0.0.0.0 at cost 1
S*
O
0.0.0.0/0 [1/0] via 10.15.231.185*
10.15.228.0/27 [333/0] via 21.21.21.1*
12.12.12.0/25 [0/0] via 21.21.21.1*
22.22.22.0/24 [3/0] via 21.21.21.1*
23.23.23.0/24 [2/0] via 21.21.21.1*
25.25.25.0/24 [333/0] via 21.21.21.1*
192.100.3.0/24 [1/0] via 192.100.2.1*
192.100.4.0/24 [1/0] via 192.100.2.1*
192.100.5.0/24 [1/0] via 192.100.2.1*
192.100.6.0/24 [1/0] via 192.100.2.1*
192.100.7.0/24 [1/0] via 192.100.2.1*
192.100.8.0/24 [1/0] via 192.100.2.1*
192.100.9.0/24 [1/0] via 192.100.2.1*
192.100.10.0/24 [1/0] via 192.100.2.1*
192.100.11.0/24 [1/0] via 192.100.2.1*
192.100.12.0/24 [1/0] via 192.100.2.1*
192.100.13.0/24 [1/0] via 192.100.2.1*
192.100.14.0/24 [1/0] via 192.100.2.1*
192.168.1.0/24 [1/0] via 192.100.2.1*
192.169.1.0/24 [1/0] via 192.100.2.1*
192.170.1.0/24 [1/0] via 192.100.2.1*
192.171.1.0/24 [1/0] via 192.100.2.1*
192.172.1.0/24 [1/0] via 192.100.2.1*
192.173.1.0/24 [1/0] via 192.100.2.1*
192.174.1.0/24 [1/0] via 192.100.2.1*
192.175.1.0/24 [1/0] via 192.100.2.1*
192.176.1.0/24 [1/0] via 192.100.2.1*
192.177.1.0/24 [1/0] via 192.100.2.1*
192.178.1.0/24 [1/0] via 192.100.2.1*
192.179.1.0/24 [1/0] via 192.100.2.1*
201.201.203.0/26 [10/0] ipsec map
202.202.202.0/29 [0/0] via 21.21.21.1*
192.100.2.0/24 is directly connected, VLAN2
10.15.231.184/29 is directly connected, VLAN1
172.16.0.0/24 is directly connected, VLAN3
21.21.21.0/24 is directly connected, VLAN21
5.5.0.2/32 is an ipsec map 10.15.149.30-5.5.0.2
(host) #show ip ospf database
OSPF Database Table
-------------------
Area ID
-------
LSA Type
--------
0.0.0.11
ROUTER
0.0.0.11
ROUTER
0.0.0.11
NETWORK
Link ID
-------
21.21.21.1
192.100.2.3
21.21.21.1
0.0.0.11
IPNET_SUMMARY 22.22.22.0
0.0.0.11
IPNET_SUMMARY 23.23.23.0
0.0.0.11
ASBR_SUMMARY
0.0.0.11
ASBR_SUMMARY
25.25.25.1
192.100.2.3
N/A
N/A
N/A
N/A
N/A
AS_EXTERNAL
AS_EXTERNAL
AS_EXTERNAL
AS_EXTERNAL
AS_EXTERNAL
Adv Router
----------
21.21.21.1
192.100.2.3
21.21.21.1
21.21.21.1
21.21.21.1
21.21.21.1
192.100.2.3
Age
---
178
178
178
178
1412
Seq#
----
0x80000017
0x80000003
0x80000003
0x80000003
0x80000002
Checksum
--------
0xca50
1406 0x80000007 0x2253
178 0x80000003 0xdf6d
0x7e38
0x5064
0xefbc
0xa85d
10.15.228.0
12.12.12.0
25.25.25.1
25.25.25.1
1014 0x8000000e 0xea43
268 0x80000003 0x433a
25.25.25.0
25.25.25.1
1761 0x80000005 0x3d8d
201.201.203.0
10.15.231.186
3600 0x80000001 0x6690
201.201.203.0
192.100.2.3
1104 0x80000002 0xe4a2
ArubaOS 6.5.3.x
| User Guide OSPFv2 | 172
N/A AS_EXTERNAL 202.202.202.0
25.25.25.1
(host) #show ip ospf neighbor
OSPF Neighbor Table
-------------------
Neighbor ID Pri State
-----------------
21.21.21.1
1
Address
-------
Interface
---------
FULL/DR 21.21.21.1
Vlan
268 0x80000003 0x4385
Configuring DOWN Controller
interface vlan 22 ip address 22.22.22.2 255.255.255.0
ip ospf area 0.0.0.10
!
router ospf router ospf area 0.0.0.10 nssa router ospf redistribute rapng-vpn
!
The following commands displays the configuration and run time protocol details on DOWN Controller:
(host)#show ip route
C
C
C
C
O
O
V
C
V
O
S
O
Codes: C - connected, O - OSPF, R - RIP, S - static
M - mgmt, U - route usable, * - candidate default, V - RAPNG VPN
Gateway of last resort is Imported from DHCP to network 0.0.0.0 at cost 10
Gateway of last resort is Imported from CELL to network 0.0.0.0 at cost 10
Gateway of last resort is Imported from PPPOE to network 0.0.0.0 at cost 10
O 0.0.0.0/0 [1/0] via 22.22.22.1*
10.0.0.0/8 [1/0] via 10.15.231.177*
10.15.228.0/27 [333/0] via 22.22.22.1*
12.12.12.0/25 [10/0] ipsec map
21.21.21.0/24 [3/0] via 22.22.22.1*
23.23.23.0/24 [2/0] via 22.22.22.1*
25.25.25.0/24 [333/0] via 22.22.22.1*
202.202.202.0/29 [10/0] ipsec map
192.100.2.0/24 is directly connected, VLAN2
10.15.231.176/29 is directly connected, VLAN1
22.22.22.0/24 is directly connected, VLAN22
4.4.0.2/32 is an ipsec map 10.15.149.35-4.4.0.2
4.4.0.1/32 is an ipsec map 10.17.87.126-4.4.0.1
(host) #show ip ospf neighbor
OSPF Neighbor Table
-------------------
Neighbor ID Pri State
-----------------
25.25.25.1
1
Address
-------
Interface
---------
FULL/BDR 22.22.22.1
Vlan 22
(host) #show ip ospf database
OSPF Database Table
-------------------
Area ID
-------
LSA Type
--------
0.0.0.10
ROUTER
0.0.0.10
ROUTER
0.0.0.10
NETWORK
Link ID
-------
25.25.25.1
192.100.2.2
22.22.22.2
0.0.0.10
IPNET_SUMMARY 21.21.21.0
0.0.0.10
IPNET_SUMMARY 23.23.23.0
0.0.0.10
NSSA
0.0.0.10
NSSA
0.0.0.0
10.15.228.0
0.0.0.10
NSSA
0.0.0.10
NSSA
12.12.12.0
25.25.25.0
Adv Router
----------
Age
---
Seq#
----
Checksum
--------
25.25.25.1
1736 0x80000021 0xb732
192.100.2.2
500
192.100.2.2
500
0x80000005
0x80000004
0x9ad9
0x8aeb
25.25.25.1
25.25.25.1
25.25.25.1
25.25.25.1
1990
1990
725
1228
0x80000003
0x80000003
0x80000002
0x80000010
0xe7bf
0x950d
0xaab9
0xca5f
192.100.2.2
352
25.25.25.1
1485
0x80000005
0x80000006
0xe8cb
0x1fa8
173 | OSPFv2 ArubaOS 6.5.3.x | User Guide
0.0.0.10
NSSA
N/A AS_EXTERNAL
N/A AS_EXTERNAL
202.202.202.0
192.100.2.2
352
12.12.12.0
192.100.2.2
352
202.202.202.0
192.100.2.2
352
0x80000005 0xe817
0x80000005 0x28d8
0x80000005 0x2824
Viewing the Status of Instant AP VPN
RAPNG AP-1 ipsec ipsec ipsec ipsec ipsec ipsec ipsec ipsec ipsec ipsec ipsec ipsec ipsec ipsec ipsec ipsec
(host)# show vpn status profile name:default
-------------------------------------------------current using tunnel :primary tunnel ipsec is preempt status ipsec is fast failover status
:disable
:disable ipsec hold on period :600 ipsec tunnel monitor frequency (seconds/packet) :5 ipsec tunnel monitor timeout by lost packet cnt :2 primary tunnel crypto type primary tunnel peer address primary tunnel peer tunnel ip primary tunnel ap tunnel ip primary tunnel current sm status primary tunnel tunnel status primary tunnel tunnel retry times primary tunnel tunnel uptime backup tunnel crypto type backup tunnel peer address backup tunnel peer tunnel ip backup tunnel ap tunnel ip backup tunnel current sm status backup tunnel tunnel status backup tunnel tunnel retry times backup tunnel tunnel uptime
:Cert
:10.15.231.186
:192.100.2.3
:5.5.0.2
:Up
:Up
:2
:1 hour 24 minutes 50 seconds
:Cert
:10.15.231.178
:0.0.0.0
:0.0.0.0
:Init
:Down
:0
:0
(host)# show datapath route
Route Table Entries
-------------------
Flags: L - Local, P - Permanent, T - Tunnel, I - IPsec, M - Mobile, A - ARP, D - Drop
IP Mask Gateway Cost VLAN Flags
-----------------------------------------------------
0.0.0.0
0.0.0.0
0.0.0.0
128.0.0.0
10.15.149.25
192.100.2.3
0
0
0
0 T
128.0.0.0
192.168.10.0
201.201.203.0
10.15.149.24
128.0.0.0
255.255.254.0
255.255.255.192
255.255.255.248
192.100.2.3
192.168.10.1
0.0.0.0
10.15.149.30
0 0 T
0 3333 D
0 103 LP
0 1 L
0 0 10.15.231.186
255.255.255.255
10.15.149.25
IPv6 Route Table Entries
------------------------
Flags: L - Local, P - Permanent, T - Tunnel, I - IPsec, M - Mobile, A - ARP, D - Drop
Prefix Gateway Cost VLAN Flags
----------------------------- --------------------- ---- ---- ------
2100::/64
::1/128
2100::5
::
0
0
1 L
0 D
(host)# show clients
Client List
-----------
Name
Signal
IP Address MAC Address
Speed (mbps)
-------------
------
-----------
------------
201.201.203.8
00:26:c6:52:6b:14
(good) 6(poor)
OS
--
149.30
Network
-------
Access Point
------------
00:24:6c:c9:27:a3 48-
Channel
-------
AN
Type
----
149.30
Role
----
43
ArubaOS 6.5.3.x
| User Guide OSPFv2 | 174
Info timestamp :80259
RAPNG AP-3
(host)# show vpn status profile name:default
-------------------------------------------------current using tunnel ipsec is preempt status ipsec is fast failover status ipsec hold on period
:primary tunnel
:disable
:disable
:600 ipsec tunnel monitor frequency (seconds/packet) :5 ipsec tunnel monitor timeout by lost packet cnt :2 ipsec ipsec primary tunnel crypto type primary tunnel peer address
:Cert
:10.15.231.178
ipsec ipsec ipsec ipsec ipsec ipsec ipsec ipsec primary tunnel peer tunnel ip primary tunnel ap tunnel ip primary tunnel current sm status primary tunnel tunnel status primary tunnel tunnel retry times primary tunnel tunnel uptime backup tunnel crypto type backup tunnel peer address
:192.100.2.2
:4.4.0.2
:Up
:Up
:13
:1 hour 55 minutes 6 seconds
:Cert
:10.15.231.186
ipsec ipsec ipsec ipsec ipsec ipsec backup tunnel peer tunnel ip backup tunnel ap tunnel ip backup tunnel current sm status backup tunnel tunnel status backup tunnel tunnel retry times backup tunnel tunnel uptime
:0.0.0.0
:0.0.0.0
:Init
:Down
:0
:0
( host)# show datapath route
Route Table Entries
-------------------
Flags: L - Local, P - Permanent, T - Tunnel, I - IPsec, M - Mobile, A - ARP, D - Drop
IP Mask Gateway Cost VLAN Flags
-----------------------------------------------------
0.0.0.0
0.0.0.0
10.15.149.33
0 0
0.0.0.0
128.0.0.0
192.168.10.0
10.15.149.32
128.0.0.0
128.0.0.0
255.255.254.0
255.255.255.248
192.100.2.2
192.100.2.2
192.168.10.1
10.15.149.35
0
0
0
0
0
0
3333
1
T
T
D
L
202.202.202.0
10.15.231.178
255.255.255.248
255.255.255.255
IPv6 Route Table Entries
------------------------
0.0.0.0
10.15.149.33
0
0
203
0
LP
Flags: L - Local, P - Permanent, T - Tunnel, I - IPsec, M - Mobile, A - ARP, D - Drop
Prefix Gateway Cost VLAN Flags
----------------------------- --------------------- ---- ---- ------
2100::/64 2100::5 0 1 L
::1/128 :: 0 0 D
( host)# show clients
Client List
-----------
Name
Signal
IP Address MAC Address
Speed (mbps)
-------------
------
-----------
------------
202.202.202.6
08:ed:b9:e1:51:7b
(good) 48(poor)
Info timestamp :80748
OS
--
149.35
Network
-------
Access Point
------------
00:24:6c:c0:41:f2 48-
Channel
-------
AN
Type
----
149.35
Role
----
53
175 | OSPFv2 ArubaOS 6.5.3.x | User Guide
Chapter 8
Tunneled Nodes
This chapter describes how to configure an Aruba tunneled node, also known as a wired tunneled node. Aruba tunneled nodes provide access and security using an overlay architecture.
This chapter describes the following topics: n n
Understanding Tunneled Node Configuration on page 176
Configuring a Wired Tunneled Node Client on page 177
Understanding Tunneled Node Configuration
The Aruba tunneled node connects to one or more client devices at the edge of the network and then establishes a secure GRE tunnel to the controlling concentrator server. This approach allows the controller to support all the centralized security features, such as 802.1X authentication, captive-portal authentication, and stateful firewall. The Aruba tunneled node is required to handle only the physical connection to clients and support for its end of the GRE tunnel.
To support the wired concentrator, the controller must have a license to terminate access points (APs). No other configuration is required. To configure the Aruba tunneled node, you must specify the IP address of the controller and identify the ports that are to be used as active tunneled node ports. Tunnels are established between the controller and each active tunneled node port on the tunneled node. All tunneled node units must be running the same version of software. The tunneled node port can also be configured as a trunk port.
This allows customers to have multiple clients on different VLANs that come through the trunk port instead of having clients on a single vlan.
shows how the tunneled node fits into network operations. Traffic moves through GRE tunnels between the active tunneled node ports and the controller or controllers. Policies are configured on a master server and enforced on the local controllers. The master and the local controller can run on the same or different systems. The tunneled node can connect to the master, but it is not required.
On the controlling controller, you can assign the same policy to tunneled node user traffic as you would to any untrusted wired traffic. The profile specified by the aaa authentication wired command determines the initial role, which contains the policy. The VLAN setting on the concentrator port must match the VLAN that will be used for users at the local controller.
ArubaOS 6.5.3.x
| User Guide Tunneled Nodes | 176
Figure 36 Tunneled Node Configuration Operation
Configuring a Wired Tunneled Node Client
ArubaOS does not allow a tunneled-node client and tunneled-node server to co-exist on the same controller at the same time. The controller must be configured as either a tunneled-node client or a tunneled-node server. By default, the controller behaves as a tunneled-node server. However, once tunneled-node-server xxx.xxx.xxx.xxx is configured on the controller, the controller becomes a tunneled-node client. To remove the tunneled-node client function, use the command tunneled-node-server 0.0.0.0
to disable the tunneled-node client on the controller side.
This section describes how to configure a tunneled node client. You can use the WebUI or the CLI to complete the configuration steps.
1. Access the Wired tunneled node CLI according to the instructions provided in the installation guide that shipped with your tunneled node. Console access (9600 8N1) and SSH access are supported.
2. Specify the IP address of the controller and specify tunnel loop prevention.
l
CLI:
(host)(config) # tunneled-node-address ipaddress
(host)(config) # tunnel-loop-prevention l
WebUI a. Navigate to Configuration>Advanced Services>Wired Access page.
b. Locate the Wired Access Concentration Configuration section.
c. T o enable tunneled nodes, click the Enable Wired Access Concentrator checkbox.
177 | Tunneled Nodes ArubaOS 6.5.3.x | User Guide
d. Enter the IP address of the controller in the Wired Access Concentrator Server IP field.
e. To enable tunnel loop prevention, click the Enable Wired Access Concentrator Loop Prevention checkbox.
f. Click Apply .
3. Access each interface that you want to use, and assign it as a tunneled node port.
(host (config) # interface fastethernet n /m
(host (config-if) # tunneled-node port
4. Verify the configuration.
(host) (config-if) # exit
(host) # show tunneled-port config
Configuring an Access Port as a Tunneled Node Port
You can configure any port on any controller as a tunneled node port using the tunneled-node-port command.
Set the tunneled-nod -address as the controller to act as the tunneled node termination point. The tunnelednode-port command tells the physical interface to tunnel that traffic to the controller.
1. Enable portfast on the Wired tunneled node.
(host)(config) # interface fastethernet <slot>/<module>/<port>
(host) (config-if) # spanning-tree portfast
2. Assign a VLAN to the tunneled node port.
(host) (config-if) # switchport mode access
(host) (config-if) # switchport access vlan <vlanid> n n
Configuring a Trunk Port as a Tunneled Node Port
To enable portfast on the Wired tunneled node execute the following commands:
(host) (config-if) # switchport mode trunk
(host) (config-if) # switchport trunk allowed vlan <WORD>
To verify the status of the Wired tunneled node execute the following command: n n
(host) # show tunneled-node state
(host) # show tunneled-node config
To check the current usage on the controller execute the following command. Each tunneled node client uses one AP license. Attaching an additional wired client on the tunneled node client does not increment the AP license usage on the controller.
n (host) # show license-usage ap
The client traffic is dropped when the tunnel node port is tagged to a VLAN other than the tunnel node VLAN.
ArubaOS 6.5.3.x
| User Guide Tunneled Nodes | 178
Chapter 9
Authentication Servers
The ArubaOS software allows you to use an external authentication server or the controller internal user database to authenticate clients who need to access the wireless network.
This chapter describes the following topics: n n n n n n n n
Understanding Authentication Server Best Practices and Exceptions on page 179
Understanding Servers and Server Groups on page 179
Configuring Authentication Servers on page 180
Managing the Internal Database on page 198
Configuring Server Groups on page 201
Assigning Server Groups on page 207
Configuring Authentication Timers on page 212
Authentication Server Load Balancing on page 213
n n
Understanding Authentication Server Best Practices and
Exceptions
For an external authentication server to process requests from the Aruba controller, you must configure the server to recognize the controller. Refer to the vendor documentation for information on configuring the authentication server.
To configure Microsoft’s IAS and Active Directory see the following links: l http://technet2.microsoft.com/windowsserver/en/technologies/ias.mspx
l http://www.microsoft.com/en-us/server-cloud/windows-server/active-directory.aspx
n n n n
Understanding Servers and Server Groups
ArubaOS supports the following external authentication servers:
RADIUS (Remote Authentication Dial-In User Service)
LDAP (Lightweight Directory Access Protocol)
TACACS+ (Terminal Access Controller Access Control System)
Windows (For stateful NTLM authentication)
Starting with ArubaOS 6.4, a maximum of 128 LDAP, RADIUS, and TACACS servers, each can be configured on the controller.
Additionally, you can use the controller’s internal database to authenticate users. You create entries in the database for users, their passwords, and their default role.
You can create groups of servers for specific types of authentication. For example, you can specify one or more
RADIUS servers to be used for 802.1X authentication. The list of servers in a server group is an ordered list.
This means that the first server in the list is always used unless it is unavailable, in which case the next server in the list is used. You can configure servers of different types in one group. For example, you can include the internal database as a backup to a RADIUS server.
ArubaOS 6.5.3.x
| User Guide Authentication Servers | 179
represents a server group named “Radii” that consists of two RADIUS servers, Radius-1 and Radius-2.
The server group is assigned to the server group for 802.1X authentication.
Figure 37 Server Group
Server names are unique. You can configure the same server in multiple server groups. You must configure the server before you can add it to a server group.
If you use the controller’s internal database for user authentication, use the predefined “Internal” server group.
You can also include conditions for server-derived user roles or VLANs in the server group configuration. The server derivation rules apply to all servers in the group.
Configuring Authentication Servers
This section describes how to configure RADIUS, LDAP, TACACS+ and Windows external authentication servers and the internal database on the controller.
This section includes the following information: n n n n n n n n
Configuring a RADIUS Server on page 180
RADIUS Service-Type Attribute on page 183
Enabling Radsec on RADIUS Servers on page 183
Configuring Username and Password for CPPM Authentication on page 194 on page 194
Configuring an LDAP Server on page 194
Configuring a TACACS+ Server on page 195
Configuring a Windows Server on page 198
Configuring a RADIUS Server
Follow the procedures below to configure a RADIUS server using the WebUI or CLI.
180 | Authentication Servers ArubaOS 6.5.3.x | User Guide
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Radius Server to display the Radius Server List.
3. To configure a RADIUS server, enter the name for the server and click Add.
4. Select the name to configure server parameters. Enter the parameters as described in
Mode check box to activate the authentication server.
5. Click Apply .
The configuration does not take effect until you perform this step.
Using the CLI
(host)(config) #aaa authentication-server radius <name> host <ipaddr> key <key> enable
Table 41: RADIUS Server Configuration Parameters
Parameter
Host
Description
Key
Auth Port
Acct Port
Radsec Port
CPPM credentials
Retransmits
Timeout
NAS ID
IP address or fully qualified domain name (FQDN) of the authentication server.
The maximum supported FQDN length is 63 characters.
Default: N/A
Shared secret between the controller and the authentication server. The maximum length is 128 characters.
Default: N/A
Authentication port of this server.
Default: 1812
Accounting port of this server.
Default: 1813
Radsec port number of this server.
Range: 1-65535
Default: 2083
Allows the controller to use configurable username and password instead of a support password.
Maximum number of retries sent to the server by the controller before the server is marked as down.
Default: 3
Maximum time, in seconds, that the controller waits before timing out the request and resending it.
Default: 5 seconds
Network Access Server (NAS) identifier to use in RADIUS packets.
ArubaOS 6.5.3.x
| User Guide Authentication Servers | 181
Table 41: RADIUS Server Configuration Parameters
Parameter
NAS IP
Description
Enable IPv6
NAS IPv6
Source Interface
Use MD5
Mode
Lowercase MAC addresses
MAC address delimiter
Service-type of FRAMED-
USER
Radsec
Radsec Trusted CA Name
The NAS IP address to be sent in RADIUS packets from that server.
NOTE: If you define a local NAS IP using the Configuration > Security >
Authentication > Servers page and also define a global NAS IP using the
Configuration > Security > Authentication > Advanced page, the global
NAS IP address takes precedence.
Enable or disable IPv6 for this server.
Default: Disabled
The NAS IPv6 address to be sent in RADIUS packets.
Enter a VLAN number ID.
Allows you to use source IP addresses to differentiate RADIUS requests.
Associates a VLAN interface with the RADIUS server to allow the serverspecific source interface to override the global configuration.
n n
If you associate a Source Interface (by entering a VLAN number) with a configured server, then the source IP address of the packet is that interface’s IP address.
If you do not associate the Source Interface with a configured server (leave the field blank), the IP address of the global Source Interface is used.
Use MD5 hash of cleartext password.
Default: Disabled
Enables or disables the server.
Default: Enabled
Send MAC address with lowercase in the authentication and accounting requests to this server.
Default: Disabled
Send MAC address with the following delimiters in the authentication and accounting requests of this server: n n colon : Send MAC address as XX:XX:XX:XX:XX:XX dash : Send MAC address as XX-XX-XX-XX-XX-XX n n none : Send MAC address as XXXXXXXXXXXX oui-nic : Send MAC address as XXXXXX-XXXXXX
Default: none
Send the service-type as FRAMED-USER instead of LOGIN-USER. For more information, see
RADIUS Service-Type Attribute on page 183
.
Default: Disabled
Enable or disable RADIUS over TLS for this server.
Default: Disabled
Enter the trusted CA name to be used to verify this server.
182 | Authentication Servers ArubaOS 6.5.3.x | User Guide
Table 41: RADIUS Server Configuration Parameters
Parameter Description
Radsec Server Cert Name Enter the name of the trusted Radsec server certificate.
Radsec Client Cert Enter the name of the Radsec client certificate that the controller should use for Radsec requests.
called-station-id Allows user to send different values for Called Station ID. Configure the following parameters for Called Station ID: n csid_type : Called station ID type.
Default: macaddr n n include_ssid : Enabling this option includes SSID in the Called Station ID along with csid_type .
Default: disabled csid_delimiter : Enabling this option allows to send this delimiter to separate csid_type and ssid in the Called Station ID.
Default: colon
(example: 00-1a-1e-00-1a-b8:dotx-ssid)
RADIUS Service-Type Attribute
The controller sends the following Service-Type attribute values for RADIUS authentication requests.
Table 42: RADIUS Service-Type Attributes
RADIUS Attribute
Service-Type
Authentication Type
MAC
802.1X
Captive Portal
Attribute Value
Call-Check
Framed
Login
The service-type-framed-user configuration of the RADIUS server overwrites all the attribute values to Framed irrespective of the authentication type. Existing deployments that depend upon this attribute for their thirdparty RADIUS integrations should make changes to support these new service types.
Enabling Radsec on RADIUS Servers
Conventional RADIUS protocol offers limited security. This level of limited security is not sufficient for authentication that takes place across unsecured networks such as the Internet. To address this, the
RADIUS over TLS or Radsec enhancement is introduced to ensure RADIUS authentication and accounting data is transmitted safely and reliably across insecure networks. The default destination port for RADIUS over TLS is
TCP/2083. Separate ports are not used for authentication, accounting, and dynamic authorization changes.
In a TLS connection, both the controller (TLS client) and the Radsec server (TLS server) need to authenticate each other using certificates. For the controller to authenticate the Radsec server: n n
Certificate Authority (CA) certificate should be uploaded as a Trusted CA , if the Radsec server uses a certificate signed by a CA.
Self-signed certificate should be uploaded as a PublicCert if the Radsec server uses a self-signed certificate.
If neither of these certificates are configured, the controller will not try to establish any connection with the Radsec server, even if Radsec is enabled.
ArubaOS 6.5.3.x
| User Guide Authentication Servers | 183
The controller also needs to send a TLS client certificate to the Radsec server by uploading a certificate on the controller as ServerCert and configuring Radsec to accept and use the controller's certificate. If a certificate is not configured, the controller will use the device certificate in its Trusted Platform Module (TPM). In this case, the Aruba device CA that signed the controller's certificate, should be configured as a Trusted CA on the Radsec server.
When Radsec support is enabled, the default RADIUS shared key is radsec and remains the same even if the user configures a different shared key.
In the Web UI
1. From Configuration tab, navigate to Security > Authentication > Servers page.
2. Click RADIUS Server .
3. Click the Radsec server from the list displayed.
4. Enter the Radsec-related parameters as described in
.
5. Click Apply .
In the CLI aaa authentication-server radius <rad_server_name> enable-radsec radsec-client-cert-name <name> radsec-port <radsec-port> radsec-trusted-cacert-name <radsec-trusted-ca> radsec-trusted-servercert-name <name>
To upload certificates through the CLI, see
.
To configure a Radsec server as RFC 3576 server for dynamic authorization (CoA), see
RADIUS Server VSAs
Vendor-Specific Attributes (VSAs) are a method for communicating vendor-specific information between
Network Access Servers and RADIUS servers, allowing vendors to support their own extended attributes.
You can use Aruba VSAs to derive the user role and VLAN for RADIUS-authenticated clients on the wired or Wi-
Fi network, or define RTTS VSAs for a Cellular WLAN controller (CWC). The VSAs must be present on your
RADIUS server, which requires that you update the RADIUS dictionary file with the vendor name and/or the vendor-specific code , the vendor-assigned attribute number, and the attribute format (such as string or integer) for each VSA. For more information on VSA-derived user roles, see
Configuring a VSA-Derived Role on page 397
describes Aruba-specific RADIUS VSAs, and
describes RTTS VSAs supported in ArubaOS. For the current and complete list of all VSAs available in the version of ArubaOS currently running on your controller, access the command-line interface and issue the command show aaa radius attributes .
184 | Authentication Servers ArubaOS 6.5.3.x | User Guide
Table 43: Aruba RADIUS VSAs
VSA Type
Aruba-User-
Role
String
Aruba-User-
Vlan
Aruba-Priv-
Admin-User
Aruba-
Admin-Role
Integer 2
Integer 2
String 4
Aruba-Essid-
Name
String
Aruba-
Location-Id
Aruba-Port-
Id
Aruba-
Template-
User
String
String
String
Aruba-
Named-
User-Vlan
Aruba-AP-
Group
Aruba-
Framed-
IPv6-
Address
Aruba-
Device-Type
Aruba-No-
DHCP-
Fingerprint
Aruba-
Mdps-
Device-Udid
String
String
String
String
Integer
String
5
6
7
8
9
10
11
12
14
15
Value Description
1 This VSA returns the role to be assigned to the user post authentication. The user will be granted access based on the role attributes defined in the role.
This VSA returns the VLAN to be used by the client.
Range: 1–4094.
If this VSA is set in the RADIUS accept message, the user can bypass the enable prompt.
This VSA returns the management role to be assigned to the user post management authentication. This role can be seen using the command show mgmt-role in the command-line interface.
String that identifies the name of the ESSID.
String that identifies the name of the AP location.
String that identifies the Port ID.
String that identifies the name of anAruba user template.
Vendor
Name
Aruba
This VSA returns a VLAN name for a user. This
VLAN name on a controller could be mapped to userdefined name or multiple VLAN IDs.
String that identifies the name of anAruba AP Group.
Aruba
Aruba
This attribute is used for RADIUS accounting for IPv6 users.
This VSA prevents the controller from deriving a role and VLAN based on DHCP finger printing.
UDID is unique device identifier which is used as input attribute by the Onboard application while performing the device authorization to the internal
RADIUS server within the ClearPass Policy Manager
(CPPM). The UDID checks against role mappings or enforcement policies to determine if the device is authorized to be onboarded.
Aruba
Aruba
Aruba
Aruba
Aruba
Aruba
Aruba
Aruba
String that identifies anAruba device on the network.
Aruba
Aruba
Aruba
Vendor
ID
14823
14823
14823
14823
14823
14823
14823
14823
14823
14823
14823
14823
14823
14823
ArubaOS 6.5.3.x
| User Guide Authentication Servers | 185
VSA
Aruba-
Mdps-
Device-Imei
Type
String
Aruba-
Mdps-
Device-Iccid
String
Aruba-
Mdps-Max-
Devices
Aruba-
Mdps-
Device-
Name
String
String
Aruba-
Mdps-
Device-
Product
Aruba-
Mdps-
Device-
Version
Aruba-
Mdps-
Device-
Serial
String
String
String
Aruba-
AirGroup-
User-Name
Aruba-
AirGroup-
Shared-Role
String
Aruba-
AirGroup-
Shared-User
String
String
25
26
Value
16
17
18
19
20
21
22
24
Description
Vendor
Name
The Onboard application uses IMEI as an input attribute while performing the device authorization to the internal RADIUS server within the CPPM. IMEI checks against role mappings or enforcement policies to determine if the device is authorized to be onboarded.
The Onboard application uses ICCID as an input attribute while performing the device authorization to the internal RADIUS server within the CPPM. ICCID checks against role mappings or enforcement policies to determine if the device is authorized to be onboarded.
Aruba
Aruba
Used by Onboard as a way to define and enforce the maximum number of devices that can be provisioned by a given user.
The Onboard application uses device name as an input attribute while performing the device authorization to the internal RADIUS server within the CPPM. Device name checks against role mappings or enforcement policies to determine if the device is authorized to be onboarded.
Aruba
Aruba
The device product is used as input attribute by the
Onboard application while performing the device authorization to the internal RADIUS server within the CPPM. Device Product checks against role mappings or enforcement policies to determine if the device is authorized to be onboarded.
Aruba
The device version is used as input attribute by the
Onboard application while performing the device authorization to the internal RADIUS server within the CPPM. Device Version checks against role mappings or enforcement policies to determine if the device is authorized to be onboarded.
Aruba
The device serial number is used as input attribute by the Onboard application while performing the device authorization to the internal RADIUS server within the CPPM. Device Serial checks against role mappings or enforcement policies to determine if the device is authorized to be onboarded.
A device owner or username associated with the device.
Aruba
Aruba
This VSA contains a comma separated list of user names with whom the device is shared.
This VSA contains a comma separated list of user roles with whom the device is shared.
Aruba
Aruba
Vendor
ID
14823
14823
14823
14823
14823
14823
14823
14823
14823
14823
186 | Authentication Servers ArubaOS 6.5.3.x | User Guide
VSA
Aruba-
AirGroup-
Device-Type
Aruba-Auth-
Survivability
Aruba-AS-
User-Name
Aruba-AS-
Credential-
Hash
Aruba-
WorkSpace-
App-Name
String
Aruba-
Mdps-
Provisioning-
Settings
String
Aruba-
Mdps-
Device-
Profile
Type Value
Integer 27
String
String
28
29
Description
Vendor
Name
A value of 1 for this VSA indicates that the device authenticating on the network is a personal device and a value of 2 indicates that it is a shared device.
The Instant AP Auth survivability feature uses the
VSA to indicate that the CPPM server sends the
Aruba-AS-User-Name and Aruba-AS-Credential-
Hash values. This attribute is just used as a flag with no specific value required.
Aruba
Aruba
The Auth survivability feature uses the VSA for
Instant APs. The CPPM sends the actual user name to the Instant AP which can be used by the Instant AP to authenticate the user if the CPPM server is not reachable.
Aruba
String 30
31
The Auth survivability feature uses the VSA for
Instant APs. The CPPM sends the NT hash of the password to the Instant AP which can be used by the
Instant AP to authenticate the user if the CPPM server is not reachable.
Aruba
This VSA identifies an application supported by Aruba
WorkSpace.
Aruba
String
32
33
Used as part of the ClearPass Onboard technology, this attribute allows the CPPM to signal back to the onboard process the context of the device provisioning settings that should be applied to the device based on applied role mappings.
Used as part of the ClearPass Onboard technology, this attribute allows CPPM to signal back to the onboard process the device profile that should be applied to the device based on applied role mappings.
Aruba
Aruba
Vendor
ID
14823
14823
14823
14823
14823
14823
14823
The following table describes the RTTS VSAs supported by ArubaOS. You can view counters for the number of times these attributes were sent and processed using the command show dot1x counters .
ArubaOS 6.5.3.x
| User Guide Authentication Servers | 187
Table 44: RTTS RADIUS VSAs
VSA Type Value Description
RTTS-Estimated-Throughput integer 1
RTTS-Result integer 2
This Attribute can be used to transfer a UE throughput estimation value from a RADIUS authenticator to the cellular WLAN controller (via a RADIUS proxy).
RTTS-Backoff-Time
RTTS-Reestimation-
Period
RTTS-Reest-
Below-
Throughput
RTTS-Reest-
Keepalive-
Num integer 3 integer 4 integer 5 integer 6
Vendor
Name
Vendor
ID
Ericsson 10923
This Attribute can be used by the cellular
WLAN controller to transfer the result of a traffic steering decision to the RADIUS authenticator.
This Attribute can be used by the cellular
WLAN controller in the Access-Accept packet to indicate to the WLAN how long a rejected UE should be ignored before being considered again for entry into the WLAN.
Ericsson 10923
Ericsson 10923
This attribute is included by the cellular
WLAN controller in the Access-Accept packet when
RTTS-Result is True to indicate to the WLAN the required interval of time between RTTS Throughput estimates to be sent to the CWC for the UE.
This Attribute is included by the cellular
WLAN controller in the Access-Accept packet when
RTTS-Result is True to indicate to the WLAN the level below which RTTS Accounting-Request packets should be sent.
Ericsson
Ericsson
10923
10923
This attribute is included by the cellular
WLAN controller when RTTS-Result is True in order to ensure that not too many reestimations are skipped by the WLAN due to the UE Wi-Fi estimated throughput being constantly higher than the RTTS-Reestimate-
When-Below-Tput threshold.
Ericsson 10923
The following table describes the Hotspot 2.0 VSAs supported by ArubaOS.
188 | Authentication Servers ArubaOS 6.5.3.x | User Guide
Table 45: Hotspot 2.0 RADIUS VSAs
VSA
Hotspot2-Subscription-Remediation-URL
String
Hotspot2-AP-Version
Type Value
1 integer 2
Hotspot2-STA-Version integer 2
Description
Vendor
Name
Subscription remediation is a process used by service providers to help clients resolve subscription errors and issues. If a mobile device is unable to authenticate to the network using existing credentials, the device can receive the
URL of a server that describes other available subscription options.
This attribute contains the following message fields: n
Server Method : The provisioning supported by the subscription remediation server.
Supported values are
0 : OMA-DM n
1 : SOAP-XML SSP
Subscription Server URL : Subscription
Remediation Server URL that is sent to a client that is unable to authenticate using its existing credentials.
This attribute indicates the Hotspot release version supported by the AP. Supported values are 0 and 1.
0 = Release 1
1 = Release 2
This attribute indicates the Hotspot release version supported by the mobile device.
Supported values are 0 and 1.
0 = Release 1
1 = Release 2
Wi-Fi-
Alliance
Wi-Fi-
Alliance
Wi-Fi-
Alliance
Vendor
ID
40808
40808
40808
ArubaOS 6.5.3.x
| User Guide Authentication Servers | 189
VSA
Hotspot2-Deauthentication-
Request
Hotspot2-Session-Info-URL
Type
String
String
Value
4
Description
Vendor
Name
This attribute contains the following message fields: n Code : Specify the reason the mobile device is being de-authenticated
0 = User’s subscription does not allow or no longer allows access at this BSS
1 = User’s subscription does not allow or no longer allows access at this ESS n n
Re-auth Delay : Define the delay time (in seconds) that a mobile device waits before attempting re-association to the same BSS,
ESS (as indicated in the Code variable). The supported range is 0- 65535. A value of 0 indicates the Re-auth Delay may be decided by the mobile device.
UI message field : The URL of a server that explains why the mobile device was not authorized. This URL must be defined as a
UTF-8 encoded string.
Wi-Fi-
Alliance
5 Configure this attribute to send a BSS Transition
Management Request frame before the mobile device’s session is terminated, warning the user their session is about to end. The URL provides a link to a webpage that provides the user with information on how to extend their session.
This attribute contains the following message fields: n n
Session Warning Time (SWT) : The Session
Warning Time (SWT) is the number of minutes before the end of a session that the AP warns the mobile device about the upcoming session end. If this value is set to 255 , the AP selects the session warning time value.
Session Information URL : This URL is sent to a mobile device before the end of the session.
The URL can link to a website that describes how users can extend their sessions.
Wi-Fi-
Alliance
Vendor
ID
40808
40808
Customizing the RADIUS Attributes
Starting from ArubaOS 6.5.1, the users can now configure RADIUS modifier profile to customize the attributes that are included, excluded and modified in the RADIUS request before it is sent to the authentication server.
The RADIUS modifier profile can be configured and applied to either Access- Request or Accounting-Request or both on a RADIUS authentication or accounting server.
This profile can contain up to 64 RADIUS attributes with static values that are used either to add or update in the request and another 64 RADIUS attributes to be excluded from the Requests.
Two new parameters have been added in the RADIUS modifier profile : n n auth-modifier : When assigned, it references to a RADIUS modifier profile which is applied to all Access-
Requests sending to this RADIUS authentication server.
acct-modifier : When assigned, it references to a RADIUS modifier profile which is applied to all Accounting-
Requests sending to this RADIUS accounting server.
To create a RADIUS modifier profile to customize the attributes that are included, excluded and modified in the
RADIUS request before it is sent to the authentication or accounting server:
190 | Authentication Servers ArubaOS 6.5.3.x | User Guide
In the WebUI
1. Navigate to Configuration > Advanced Services > All Profiles .
2. Click Wireless LAN .
3. Click Radius Modifier .
4. Under the Radius Modifier Profile , enter the name of the RADIUS modifier and click Add .
5. Click on the name of the Instance added.
6. In +Attr field, enter the Name and Static Value for the attribute you want to include and click Add . The name field should be available in the list of attributes when we execute the command, show aaa radiusattribute command.
7. In the -Attr field, enter the attribute you want to exclude and click Add .
8. Click Save as and enter the name of the Radius Modifier Profile .
9. Click Apply .
In the CLI
(host) (config) #aaa authentication-server radius radius1 acct-modifier acctport auth-modifier authport
…
…
(host) (config) #aaa radius modifier <profile_name> clone exclude include no
(host) #show aaa radius modifier <profile_name>
Dynamic Data Support
Starting from ArubaOS 6.5.2.0, Aruba supports dynamic data for the included attributes in the RADIUS
Attribute modifier. Users can configure the dynamic value for each included attribute in the RADIUS modifier to be one or two data items. Following data items can be picked to form the dynamic value for each included attribute: n n n n
AP-Name : Name of the AP which the client currently associated to.
AP-MAC-Address : MAC-address of the AP which the client currently associated to.
AP-Group : Group-name of the AP which the client currently associated to.
ESSID : ESSID which the client currently associated to.
Field1 and Field2 have the same value but these can be used for different combination with the delimiter. This included attribute are of type ‘String’ and can contain up to 128 bytes.
In the WebUI
1. Navigate to Configuration > Advanced Services > All Profiles .
2. Click Wireless LAN .
3. Click Radius Modifier .
4. Under the Profile details, enter the name of the radius modifier profile and click Add.
5. Click on the name of the instance added.
6. In +Attr field, enter the name of the instance from the Name drop-down list and select the Data Type as
Dynamic .
ArubaOS 6.5.3.x
| User Guide Authentication Servers | 191
7. Select the First Dynamic Field from the drop-down list.
8. Select the Optional Second Dynamic Field from the drop-down list.
9. Select the Delimiter Between Fields from the drop-down list.
10.Click
Add to add the radius modifier.
11.. Click Save as and enter the name of the Radius Modifier profile.
12.. Click Apply .
In the CLI
To configure a RADIUS modifier profile with single-item dynamic data
(host)(config) #aaa radius modifier dynamic-mod
(host) (Radius Modifier Profile "dynamic-mod") #?
clone exclude include no
Copy data from another Radius Modifier Profile
Attribute to be excluded in RADIUS request
Attribute/Value to be included in RADIUS request
Delete Command
(host) (Radius Modifier Profile "dynamic-mod") #include ?
<name> RADIUS Attribute Name
(host) (Radius Modifier Profile "dynamic-mod") #include Aruba-Location-Id ?
dynamic First dynamic field static Static Data
(host) (Radius Modifier Profile "dynamic-mod") #include Aruba-Location-Id dynamic ?
ap-group1 Use AP group as first dynamic field ap-macaddr1 ap-name1 essid1
Use AP mac address as first dynamic field
Use AP name as first dynamic field
Use essid as first dynamic field
(host) (Radius Modifier Profile "dynamic-mod") #include Aruba-Location-Id dynamic ap-name1
To configure a RADIUS modifier profile with two-item dynamic data
(host) (Radius Modifier Profile "dynamic-mod") #include Aruba-Location-Id dynamic ?
ap-group1 Use AP group as first dynamic field ap-macaddr1 ap-name1 essid1
Use AP mac address as first dynamic field
Use AP name as first dynamic field
Use essid as first dynamic field
(host) (Radius Modifier Profile "dynamic-mod") #include Aruba-Location-Id dynamic essid1 ?
with Optional second dynamic field
(host) (Radius Modifier Profile "dynamic-mod") #include Aruba-Location-Id dynamic essid1 with
?
ap-group2 Use AP group as second dynamic field ap-macaddr2 ap-name2 essid2
Use AP mac address as second dynamic field
Use AP name as second dynamic field
Use essid as second dynamic field
(host) (Radius Modifier Profile "dynamic-mod") #include Aruba-Location-Id dynamic essid1 with ap-macaddr2 ?
delimiter Delimiter between fields
(host) (Radius Modifier Profile "dynamic-mod") #include Aruba-Location-Id dynamic essid1 with ap-macaddr2 delimiter ?
at colon
Use '@' as delimiter between fields
Use ':' as delimiter between fields dash dollar
Use '-' as delimiter between fields
Use '$' as delimiter between fields
192 | Authentication Servers ArubaOS 6.5.3.x | User Guide
hash none percent semicolon slash space
Use '#' as delimiter between fields
NULL
Use '%' as delimiter between fields
Use ';' as delimiter between fields
Use '/' as delimiter between fields
Use ' ' as delimiter between fields
(host) (Radius Modifier Profile "dynamic-mod") #include Aruba-Location-Id dynamic essid1 with ap-macaddr2 delimiter at ?
To show a RADIUS modifier profile with mixing of static- and dynamic- data
(host) (config) #show aaa radius modifier dynamic-mod
Radius Modifier Profile
-----------------------
Action
------
Attribute Name
--------------
Data Type Data Value
------------------
+Attr Aruba-Location-Id dynamic
+Attr BW-Area-Code static essid1 with ap-macaddr2 delimiter at
"212"
+Attr
+Attr
BW-City-Name
Aruba-AP-Group
-Attr Aruba-Device-Type static dynamic
"San Jose" ap-group1
RADIUS Server Authentication Codes
A configured RADIUS server returns the following standard response codes.
Table 46: RADIUS Authentication Response Codes
Code
2
3
0
1
4
5
6
Description
Authentication OK.
Authentication failed : user/password combination not correct.
Authentication request timed out : No response from server.
Internal authentication error.
Bad Response from RADIUS server : verify shared secret is correct.
No RADIUS authentication server is configured.
Challenge from server. (This does not necessarily indicate an error condition.)
RADIUS Server Fully Qualified Domain Names
If you define a RADIUS server using the FQDN of the server rather than its IP address, the controller periodically generates a DNS request and caches the IP address returned in the DNS response. To view the IP address that currently correlates to each RADIUS server FQDN, access the command-line interface in config mode and issue the following command:
(host) #show aaa fqdn-server-names
DNS Query Intervals
If you define a RADIUS server using the FQDN of the server rather than its IP address, the controller periodically generates a DNS request and caches the IP address returned in the DNS response. DNS requests are sent every 15 minutes by default.
ArubaOS 6.5.3.x
| User Guide Authentication Servers | 193
You can use either the WebUI or the CLI to configure how often the controller will generate a DNS request to cache the IP address for a RADIUS server identified via its fully qualified domain name (FQDN).
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Advanced page.
2. In the DNS Query Interval (min) field, enter a new DNS query interval, from 1-1440 minutes, inclusive.
3. Click Apply .
Using the CLI
(host)(config) #aaa dns-query-interval <minutes>
Configuring Username and Password for CPPM Authentication
The controller authenticating to CPPM is enhanced to use configurable username and password instead of support password. The support password is vulnerable to attacks as the server certificate presented by CPPM server is not validated.
In the WebUI:
1. Navigate to Configuration > Security> Authentication> Servers .
2. Under RADIUS Server , select the server name.
3. Enter the cppm_username and cppm_password in the CPPM credentials option.
4. Click Apply .
In the CLI:
(host)(config) #aaa authentication-server radius
Configuring an LDAP Server
describes the parameters you configure for an LDAP server.
Table 47: LDAP Server Configuration Parameters
Parameter
Host
Description
Admin-DN
Admin Password
Allow Clear-Text
Authentication Port
Base-DN
IP address of the LDAP server.
Default: N/A
Distinguished name for the admin user who has read/search privileges across all the entries in the LDAP database (the user does need write privileges, but will be able to search the database, and read attributes of other users in the database).
Password for the admin user.
Default: N/A
Allows clear-text (unencrypted) communication with the LDAP server.
Default: disabled
Port number used for authentication.
Default: 389
Distinguished Name of the node that contains the entire user database.
Default: N/A
194 | Authentication Servers ArubaOS 6.5.3.x | User Guide
Parameter Description
Filter
Key Attribute
Timeout
A string searches for users in the LDAP database. The default filter string is:
(objectclass=* ).
Default: N/A
A string searches for a LDAP server. For Active Directory, the value is sAMAccountName.
Default: sAMAccountName
Timeout period of a LDAP request, in seconds.
Default: 20 seconds
Mode Enables or disables the server.
Default: enabled
Preferred Connection
Type
Preferred type of connection between the controller and the LDAP server. The default order of connection type is:
1. ldap-s
2. start-tls
3. clear-text
The controller first tries to contact the LDAP server using the preferred connection type, and only attempts to use a lower-priority connection type if the first attempt is not successful.
NOTE: If you select clear-text as the preferred connection type, you must also enable the allow-cleartext option.
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select LDAP Server to display the LDAP Server List.
3. To configure an LDAP server, enter the name for the server and click Add .
4. Select the name to configure server parameters. Enter parameters as described in
. Select the
Mode checkbox to activate the authentication server.
5. Click Apply .
The configuration does not take effect until you perform this step.
Using the CLI
(host)(config) #aaa authentication-server ldap < name>
Configuring a TACACS+ Server
defines the TACACS+ server parameters.
ArubaOS 6.5.3.x
| User Guide Authentication Servers | 195
Table 48: TACACS+ Server Configuration Parameters
Parameter
Host
Description
Key
TCP Port
Retransmits
Timeout
Mode
Session
Authorization
Source Interface
IP address of the server.
Default: N/A
Shared secret to authenticate communication between the TACACS+ client and server.
Default: N/A
TCP port used by server.
Default: 49
Maximum number of times a request is retried.
Default: 3
Timeout period for TACACS+ requests, in seconds.
Default: 20 seconds
Enables or disables the server.
Default: enabled
Enables or disables session authorization. Session authorization turns on the optional authorization session for admin users.
Default: disabled
Enter a VLAN number ID.
Allows you to use source IP addresses to differentiate TACACS requests.
Associates a VLAN interface with the TACACS server to allow the server-specific source interface to override the global configuration.
n n
If you associate a Source Interface (by entering a VLAN number) with a configured server, then the source IP address of the packet is that interface’s IP address.
If you do not associate the Source Interface with a configured server (leave the field blank), the IP address of the global Source Interface is used.
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select TACACS Server to display the TACACS Server List.
3. To configure a TACACS+ server, enter the name for the server and click Add .
4. Select the name to configure server parameters. Enter parameters as described in
. Select the
Mode checkbox to activate the authentication server.
5. Click Apply .
The configuration does not take effect until you perform this step.
Using the CLI
The following command configures, enables a TACACS+ server and enables session authorization:
(host)(config) #aaa authentication-server tacacs <name>
Source Interface
ArubaOS 6.5.2.0 introduces the Source Interface parameter. This parameter provides a customer the option of specifying the source IP for a TACACS server. The source IP specified in the TACACS server overrides the one in
196 | Authentication Servers ArubaOS 6.5.3.x | User Guide
global TACACS configuration. If neither the global or per-server source interface in the TACACS server is configured, then routable interface is chosen for TACACS server interface for communication. Both IPv4 and
IPv6 are supported while configuring source interface IP addresses.
If there is mismatch in the host IP and source interface IP. For example if the host is IPv6 and source interface is IPv4 or vice-versa in per-server configuration, then the connection doesn’t succeed.
Only VLAN address is allowed.
Changes to host address are allowed only if:
1. Source interface is not configured.
2. Source interface is of same type as the host IP address.
All other combinations require the use of the no command to clear out the host IP and/or source interface for that particular TACACS server.
Using the WebUI
Follow the steps below to configure per-server TACACS source interface:
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select TACACS Server to display the TACACS Server List.
3. Select a TACACS server to enter the source interface details.
4. Enter values for the vlanid/ipv6addr .
5. Click Apply > Save Configuration .
Follow the steps below to configure global TACACS setup:
1. Navigate to the Configuration > Security > Authentication > Advanced page.
2. In the TACACS Setup field select a value for the vlanid from the Source Address v4 drop- down list to configure source interface IPv4 address.
3. Enter values for the vlanid and IPv6 in the Source Address v6 field to configure source interface IPv6 address.
4. Click Apply > Save Configuration .
The configuration does not take effect until you perform this step.
Using the CLI
The following commands configure the global TACACS source interface on IPv4 and IPv6 respectively:
(host) (config) #ip tacacs source-interface vlan <vlan number>
(host) (config) ##ipv6 tacacs source-interface vlan <vlan id> <ip6addr>
The following commands configure per-server TACACS source interface on IPv4 and IPv6 respectively:
(host) (TACACS Server <name>) # source-interface vlan <vlan id>
(host) (TACACS Server <name>) # source-interface vlan <vlan id> ip6addr <ip6addr>
(host) (TACACS Server "<name>") #source-interface vlan
The following commands delete the global TACACS source interface on IPv4 and IPv6 respectively:
(host) (config)#no ip tacacs source-interface vlan <vlan id>
(host) (config)#no ipv6 tacacs source-interface vlan <vlan id> <ip6addr>
The following command deletes per-server TACACS source interface on IPv4:
(host) (TACACS Server <name>) #no source-interface vlan <vlanid>
ArubaOS 6.5.3.x
| User Guide Authentication Servers | 197
Configuring a Windows Server
defines parameters for a Windows server used for stateful NTLM authentication.
Table 49: Windows Server Configuration Parameters
Parameter
Host
Mode
Windows Domain
Description
IP address of the server.
Default: N/A
Enables or disables the server.
Default: enabled
Name of the Windows Domain assigned to the server.
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Windows Server to display the Windows Server List.
3. To configure a Windows server, enter the name for the server and click Add .
4. Select the name of the server to configure its parameters. Enter the parameters as described in
5. Select the Mode checkbox to activate the authentication server.
6. Click Apply .
The configuration does not take effect until you perform this step.
Using the CLI
(host) (config)# aaa authentication-server windows <windows-server-name>
Managing the Internal Database
You can create entries in the controller’s internal database to authenticate clients. The internal database contains a list of clients, along with the password and default role for each client. When you configure the internal database as an authentication server, client information is checked in incoming authentication requests against the internal database.
Configuring the Internal Database
.
The master controller uses the internal database for authentication by default. You can choose to use the internal database in a local controller by entering the CLI command aaa authentication-server internal use-local-switch
. If you use the internal database in a local controller, you need to add clients on the local controller.
defines the required and optional parameters used in the internal database.
198 | Authentication Servers ArubaOS 6.5.3.x | User Guide
Table 50: Internal Database Configuration Parameters
Parameters
User Name
Description
Password
Role
Enabled
Expiration
Static Inner IP
Address (for RAPs only)
(Required) Enter a user name or select Generate to automatically generate a user name. An entered user name can be up to 64 characters in length.
(Required) Enter a password or select Generate to automatically generate a password string. An entered password must be a minimum of 6 characters and can be up to 128 characters in length.
Role for the client.
For this role to be assigned to a client, you need to configure a server derivation rule, as described in
Configuring Server-Derivation Rules on page 205
. (A user role assigned through a server-derivation rule takes precedence over the default role configured for an authentication method.)
(Optional) E-mail address of the client.
Select this check box to enable the user as soon as the user entry is created.
Select one of the following options: n
Entry does not expire: No expiration on user entry.
n
Set Expiry time (mins): Enter the number of minutes the user is authenticated before their user entry expires.
n Set Expiry Date (mm/dd/yyyy) Expiry Time (hh:mm): To select a specific expiration date and time, enter the expiration date in mm/dd/yyyy format, and the expiration time in hh:mm format.
Assign a static inner IP address to a Remote AP. If this database entry is not for a remote AP, leave this field empty.
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Internal DB .
3. Click Add User in the Users section. The user configuration page displays.
4. Enter the information for the client, as described in the table above.
5. Click Enabled to activate this entry on creation.
6. Click Apply . The configuration does not take effect until you perform this step.
7. At the Servers page, click Apply .
The Internal DB Maintenance window also includes a Guest User Page feature that allows you to create user entries for guests only. For details on creating guest users, see
Guest Provisioning User Tasks on page 886
.
Using the CLI
Enter the following command in enable mode:
(host)(config) #local-userdb add {generate-username|username < name> }{ generate-password|password < password> }
Managing Internal Database Files
ArubaOS allows you to import and export user information tables to and from the internal database. These files should not be edited once they are exported. ArubaOS only supports the importing of database files that
ArubaOS 6.5.3.x
| User Guide Authentication Servers | 199
were created during the export process. Note that importing a file into the internal database overwrites and removes all existing entries.
Exporting Files in the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Internal DB .
3. Click Export in the Internal DB Maintenance section. A popup window opens.
4. Enter the name of the file you want to export
5. Click OK .
Importing Files in the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Internal DB .
3. Click Import in the Internal DB Maintenance section. A popup window opens.
4. Enter the name of the file you want to import.
5. Click OK .
Exporting and Importing Files in the CLI
Enter the following command in enable mode:
(host)(config) #local-userdb export <filename>
(host)(config) #local-userdb import <filename>
Working with Internal Database Utilities
The local internal database also includes utilities to clear all users from the database and restart the internal database to repair internal errors. Under normal circumstances, neither of these utilities are necessary.
Deleting All Users
Issue this command to remove users from the internal database after you have moved your user database from the controller’s internal server to an external server.
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Internal DB .
3. Click Delete All Users in the Internal DB Maintenance section. A popup window opens and asks you to confirm that you want to remove all users.
4. Click OK .
Repairing the Internal Database
Use this utility under the supervision of Aruba technical support to recreate the internal database. This may clear internal database errors, but also removes all information from the database. Make sure you export your current user information before you start the repair procedure.
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Internal DB .
3. Click Repair Database in the Internal DB Maintenance section. A popup window opens and asks you to confirm that you want to recreate the database.
4. Click OK .
200 | Authentication Servers ArubaOS 6.5.3.x | User Guide
Configuring Server Groups
You can create groups of servers for specific types of authentication – for example, you can specify one or more RADIUS servers to be used for 802.1X authentication. You can configure servers of different types in one group. For example, you can include the internal database as a backup to a RADIUS server.
Configuring Server Groups
Server names are unique. You can configure the same server in more than one server group. You must configure the server before you can include it in a server group.
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Server Group to display the Server Group list.
3. Enter the name of the new server group and click Add .
4. Select the name to configure the server group.
5. Under Servers, click New to add a server to the group.
a. Select a server from the drop-down list and click Add Server .
b. Repeat the above step to add other servers to the group.
6. Click Apply .
Using the CLI
(host)(config) #aaa server-group <name> auth-server <name>
Configuring Server List Order and Fail-Through
The servers in a server group are part of an ordered list. The first server in the list is always used by default, unless it is unavailable, in which case the next server in the list is used. You can configure the order of servers in the server group through the WebUI using the up or down arrows (the top server is the first server in the list).
In the CLI, the position parameter specifies the relative order of servers in the list (the lowest value denotes the first server in the list).
As mentioned previously, the first available server in the list is used for authentication. If the server responds with an authentication failure, there is no further processing for the user or client for which the authentication request failed. You can also enable fail-through authentication for the server group so that if the first server in the list returns an authentication deny, the controller attempts authentication with the next server in the ordered list. The controller attempts to authenticate with each server in the list until there is a successful authentication or the list of servers in the group is exhausted. This feature is useful in environments where there are multiple, independent authentication servers; users may fail authentication on one server but can be authenticated on another server.
Before enabling fail-through authentication, note the following: n n n
This feature is not supported for 802.1X authentication with a server group that consists of external EAPcompliant RADIUS servers. You can, however, use fail-through authentication when the 802.1X
authentication is terminated on the controller (AAA FastConnect).
Enabling this feature for a large server group list may cause excess processing load on the controller. It is recommended that you use server selection based on domain matching whenever possible (see
Dynamic Server Selection on page 202
).
Certain servers, such as the RSA RADIUS server, lock out the controller if there are multiple authentication failures. Therefore, you should not enable fail-through authentication with these servers.
ArubaOS 6.5.3.x
| User Guide Authentication Servers | 201
In the following example, you create a server group "corp-serv" with two LDAP servers (ldap-1 and ldap-2), each containing a subset of the usernames and passwords used in the network. When you enable fail-through authentication, users that fail authentication with the first server on the list will be authenticated with the second server.
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select LDAP Server to display the LDAP Server List.
3. Enter ldap-1 for the server name and click Add .
4. Enter ldap-2 for the server name and click Add .
5. Under the Servers tab, select ldap-1 to configure server parameters. Enter the IP address for the server.
Select the Mode check box to activate the authentication server. Click Apply .
6. Repeat
to configure ldap-2.
7. Display the Server Group list: Under the Servers tab, select Server Group .
8. Enter corp-serv as the new server group and click Add .
9. Select corp-serv, under the Server tab, to configure the server group.
10.Select
Fail Through .
11.Under Servers, click New to add a server to the group. Select ldap-1 from the drop-down list and click Add
Server .
12.Repeat
to add ldap-2 to the group.
13.Click
Apply .
Using the CLI
(host)(config) #aaa authentication-server ldap ldap-1 host 10.1.1.234
(host)(config) #aaa authentication-server ldap ldap-2 host 10.2.2.234
(host)(config) #aaa server-group corp-serv auth-server ldap-1 position 1 auth-server ldap-2 position 2 allow-fail-through
Configuring Dynamic Server Selection
The controller can dynamically select an authentication server from a server group based on the user information sent by the client in an authentication request. For example, an authentication request can include client or user information in one of the following formats: n n n
<domain>\<user> : for example, corpnet.com\darwin
<user>@<domain> : for example, [email protected]
host/<pc-name>.<domain> : for example, host/darwin-g.finance.corpnet.com (this format is used with
802.1X machine authentication in Windows environments)
When you configure a server in a server group, you have the option to associate the server with one or more match rules. A match rule for a server can be one of the following: n n n
The server is selected if the client/user information contains a specified string.
The server is selected if the client/user information begins with a specified string.
The server is selected if the client/user information exactly matches a specified string.
202 | Authentication Servers ArubaOS 6.5.3.x | User Guide
You can configure multiple match rules for the same server. The controller compares the client/user information with the match rules configured for each server, starting with the first server in the server group. If a match is found, the controller sends the authentication request to the server with the matching rule. If no match is found before the end of the server list is reached, an error is returned, and no authentication request for the client/user is sent.
depicts a network consisting of several subdomains in corpnet.com. The server radius-1 provides
802.1X machine authentication to PC clients in xyz.corpnet.com, sales.corpnet.com, and hq.corpnet.com. The server radius-2 provides authentication for users in abc.corpnet.com.
Figure 38 Domain-Based Server Selection Example
You configure the following rules for servers in the corp-serv server group: n n radius-1 is selected if the client information starts with “host.” radius-2 is selected if the client information contains “abc.corpnet.com.”
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Under the Servers tab, select Server Group to display the Server Group list.
3. Enter corp-serv for the new server group and click Add .
4. Under the Servers tab, select corp-serv to configure the server group.
5. Under Servers, click New to add the radius-1 server to the group. Select radius-1 from the drop-down list.
a. For Match Type, select Authstring .
b. For Operator, select starts-with .
c. For Match String, enter host/ .
d. Click Add Rule >> .
e. Scroll to the right and click Add Server .
6. Under Servers, click New to add the radius-2 server to the group. Select radius-2 from the drop-down list.
a. For Match Type, select Authstring.
b. For Operator, select contains .
c. For Match String, enter abc.corpnet.com.
ArubaOS 6.5.3.x
| User Guide Authentication Servers | 203
d. Click Add Rule >> .
e. Scroll to the right and click Add Server .
The last server you added to the server group (radius-2) automatically appears as the first server in the list. In this example, the order of servers is not important. If you need to reorder the server list, scroll to the right and click the up or down arrow for the appropriate server.
7. Click Apply .
Using the CLI
(host)(config) #aaa server-group corp-serv auth-server radius-1 match-authstring starts-with host/ position 1 auth-server radius-2 match-authstring contains abc.corpnet.com position 2
Configuring Match FQDN Option
You can also use the “match FQDN” option for a server match rule. With a match FQDN rule, the server is selected if the <domain> portion of the user information in the formats <domain>\<user> or
<user>@<domain> matches a specified string exactly . Note the following caveats when using a match FQDN rule: n n
This rule does not support client information in the host/<pc-name>.<domain> format, so it is not useful for 802.1X machine authentication.
The match FQDN option performs matches on only the <domain> portion of the user information sent in an authentication request. The match-authstring option (described previously) allows you to match all or a portion of the user information sent in an authentication request.
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Under the Servers tab, select Server Group to display the Server Group list.
3. Enter corp-serv for the new server group and click Add .
4. Under the Servers tab, select corp-serv to configure the server group.
5. Under Servers, click New to add the radius-1 server to the group. Select radius-1 from the drop-down list.
a. For Match Type, select FQDN .
b. For Match String, enter corpnet.com
.
c. Click Add Rule >> .
d. Scroll to the right and click Add Server .
6. Click Apply .
Using the CLI
(host)(config) #aaa server-group corp-serv auth-server radius-1 match-fqdn corpnet.com
Trimming Domain Information from Requests
Before the controller forwards an authentication request to a specified server, it can truncate the domainspecific portion of the user information. This is useful when user entries on the authenticating server do not include domain information. You can specify this option with any server match rule. This option is only applicable when the user information is sent to the controller in the following formats: n n
<domain>\<user> : the <domain>\ portion is truncated
<user>@<domain> : the @<domain> portion is truncated
204 | Authentication Servers ArubaOS 6.5.3.x | User Guide
This option does not support client information sent in the format host/<pc-name>.<domain>
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Server Group to display the Server Group list.
3. Enter the name of the new server group and click Add .
4. Select the name to configure the server group.
5. Under Servers, click Edit for a configured server or click New to add a server to the group.
n n
If editing a configured server, select Trim FQDN, scroll right, and click Update Server .
If adding a new server, select a server from the drop-down list, then select Trim FQDN, scroll right, and click Add Server .
6. Click Apply .
Using the CLI
(host)(config) #aaa server-group corp-serv auth-server radius-2 match-authstring contains abc.corpnet.com trim-fqdn
Configuring Server-Derivation Rules
When you configure a server group, you can set the VLAN or role for clients based on attributes returned for the client by the server during authentication. The server derivation rules apply to all servers in the group. The user role or VLAN assigned through server derivation rules takes precedence over the default role and VLAN configured for the authentication method.
The authentication servers must be configured to return the attributes for the clients during authentication. For instructions on configuring the authentication attributes in a Windows environment using IAS, refer to the documentation at http://technet2.microsoft.com/windowsserver/en/technologies/ias.mspx
The server rules are applied based on the first match principle. The first rule that is applicable for the server and the attribute returned is applied to the client, and would be the only rule applied from the server rules. These rules are applied uniformly across all servers in the server group.
describes the server rule parameters you can configure.
ArubaOS 6.5.3.x
| User Guide Authentication Servers | 205
Table 51: Server Rule Configuration Parameters
Parameter
Role or VLAN
Description
Attribute
Operation
Operand
Value position
The server derivation rules apply to either user role or VLAN assignment. With
Role assignment, a client can be assigned a specific role based on the attributes returned. In VLAN assignment, the client can be placed in a specific VLAN based on the attributes returned.
This is the attribute returned by the authentication server that is examined for
Operation and Operand match.
This is the match method by which the string in Operand is matched with the attribute value returned by the authentication server.
n contains : The rule is applied if and only if the attribute value contains the string in parameter Operand.
n n starts-with : The rule is applied if and only if the attribute value returned starts with the string in parameter Operand.
ends-with : The rule is applied if and only if the attribute value returned ends with the string in parameter Operand.
n n n equals : The rule is applied if and only if the attribute value returned equals the string in parameter Operand.
not-equals : The rule is applied if and only if the attribute value returned is not equal to the string in parameter Operand.
value-of : This is a special condition. What this implies is that the role or
VLAN is set to the value of the attribute returned. For this to be successful, the role and the VLAN ID returned as the value of the attribute selected must be already configured on the controller when the rule is applied.
This is the string to which the value of the returned attribute is matched.
The user role or the VLAN name applied to the client when the rule is matched.
Position of the condition rule. Rules are applied based on the first match principle. One is the top.
Default: bottom
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Server Group to display the Server Group list.
3. Enter the name of the new server group and click Add .
4. Select the name to configure the server group.
5. Under Servers, click New to add a server to the group.
a. Select a server from the drop-down list and click Add .
b. Repeat the above step to add other servers to the group.
6. Under Server Rules, click New to add server derivation rules for assigning a user role or VLAN.
a. Enter the attribute.
b. Select the operation from the drop-down list.
c. Enter the operand.
d. To set the role, select set role from the Set drop-down list and enter the value to be assigned from the
Value drop-down list.
e. Or, to set the vlan, select set vlan from the Set drop-down list and select the VLAN name or ID from the
Value drop-down list and click the left-arrow.
206 | Authentication Servers ArubaOS 6.5.3.x | User Guide
f. Click Add .
g. Repeat the above steps to add other rules for the server group.
7. Click Apply .
Using the CLI
(host) (config) #aaa server-group <name>
(host) (Server Group name) #set {role|vlan} condition <attribute> contains|endswith|equals|not-equals|starts-with <operand> set-value <set-value-str> position <number>
Configuring a Role Derivation Rule for the Internal Database
When you add a user entry in the controller’s internal database, you can optionally specify a user role (see
Managing the Internal Database on page 198
). The role specified in the internal database entry to be assigned to the authenticated client, you must configure a server derivation rule as shown in the following sections:
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Server Group to display the Server Group list.
3. Select the internal server group.
4. Under Server Rules, click New to add a server derivation rule.
a. For Condition, enter Role .
b. Select value-of from the drop-down list.
c. Select Set Role from the drop-down list.
d. Click Add .
5. Click Apply .
Using the CLI
(host)(config) #aaa server-group internal set role condition Role value-of
Assigning Server Groups
You can create server groups for the following purposes: n n n user authentication management authentication accounting
You can configure all types of servers for user and management authentication (see
). Accounting is only supported with RADIUS and TACACS+ servers when RADIUS or TACACS+ is used for authentication.
Table 52: Server Types and Purposes
User authentication
Management authentication
Accounting
RADIUS
Yes
Yes
Yes
TACACS+ LDAP
Yes
Yes
Yes
Yes
Yes
No
Internal Database
Yes
Yes
No
ArubaOS 6.5.3.x
| User Guide Authentication Servers | 207
User Authentication
For information about assigning a server group for user authentication, refer to the Roles and Policies chapter of the ArubaOS User Guide .
Management Authentication
Users who need to access the controller to monitor, manage, or configure the Aruba user-centric network can be authenticated with RADIUS, TACACS+, or LDAP servers or the internal database.
Only user record attributes are returned upon successful authentication. Therefore, to derive a management role other than the default mgmt auth role, set the server derivation rule based on the user attributes.
Using the WebUI
1. Navigate to the Configuration > Management > Administration page.
2. Under the Management Authentication Servers section, select the following: n n
Enable check box
Server Group
3. Click Apply .
Using the CLI
(host)(config) #aaa authentication mgmt server-group < group> enable
Accounting
You can configure accounting for RADIUS and TACACS+ server groups.
RADIUS or TACACS+ accounting is only supported when RADIUS or TACACS+ is used for authentication.
RADIUS Accounting
RADIUS accounting allows user activity and statistics to be reported from the controller to RADIUS servers:
1. The controller generates an Accounting Start packet when a user logs in. The code field of transmitted
RADIUS packet is set to 4 (Accounting-Request). Note that sensitive information, such as user passwords, are not sent to the accounting server. The RADIUS server sends an acknowledgement of the packet.
2. The controller sends an Accounting Stop packet when a user logs off; the packet information includes various statistics such as elapsed time, input and output bytes, and packets. The RADIUS server sends an acknowledgment of the packet.
The following is the list of attributes that the controller can send to a RADIUS accounting server: n n n n
Acct-Status-Type: This attribute marks the beginning or end of accounting record for a user. Current values are Start, Stop, and Interim Update.
User-Name: Name of user.
Acct-Session-Id: A unique identifier to facilitate matching of accounting records for a user. It is derived from the user name, IP address, and MAC address. This is set in all accounting packets.
Acct-Authentic: This indicates how the user was authenticated. Current values are 1 (RADIUS), 2 (Local), and 3 (LDAP).
208 | Authentication Servers ArubaOS 6.5.3.x | User Guide
n n n n n n n n n
Acct-Session-Time: The elapsed time, in seconds, that the client was logged in to the controller. This is only sent in Accounting-Request records, where the Acct-Status-Type is Stop or Interim Update.
Acct-Terminate-Cause: Indicates how the session was terminated and is sent in Accounting-Request records where the Acct-Status-Type is Stop. Possible values are:
1: User logged off
4: Idle Timeout
5: Session Timeout. Maximum session length timer expired.
7: Admin Reboot: Administrator is ending service, for example prior to rebooting the controller.
l l
NAS-Identifier: This is set in the RADIUS server configuration.
NAS-IP-Address: IP address of the master controller. You can configure a “global” NAS IP address:
In the WebUI, navigate to the Configuration > Security > Authentication > Advanced page.
In the CLI, use the, ip radius nas-ip command.
NAS-Port: Physical or virtual port (tunnel) number through which the user traffic is entering the controller.
NAS-Port-Type: Type of port used in the connection. This is set to one of the following: l l
5: admin login
15: wired user type l
19: wireless user
Framed-IP-Address: IP address of the user.
Calling-Station-ID: MAC address of the user.
Called-station-ID: MAC address of the controller.
The following attributes are sent in Accounting-Request packets when Acct-Status-Type value is Start: n n n n n n n n n n n
Acct-Status-Type
User-Name
NAS-IP-Address
NAS-Port
NAS-Port-Type
NAS-Identifier
Framed-IP-Address
Calling-Station-ID
Called-station-ID
Acct-Session-ID
Acct-Authentic
The following attributes are sent in Accounting-Request packets when Acct-Status-Type value is Stop: n n n n n n n n n
Acct-Status-Type
User-Name
NAS-IP-Address
NAS-Port
NAS-Port-Type
NAS-Identifier
Framed-IP-Address
Calling-Station-ID
Called-station-ID
ArubaOS 6.5.3.x
| User Guide Authentication Servers | 209
n n n n
Acct-Session-ID
Acct-Authentic
Terminate-Cause
Acct-Session-Time
The following statistical attributes are sent only in Interim-Update and Accounting Stop packets (they are not sent in Accounting Start packets): n n n n n n
Acct-Input-Octets
Acct-Output-Octets
Acct-Input-Packets
Acct-Output-Packets
Acct-Input-Gigawords
Acct-Output-Gigawords
Remote APs in split-tunnel mode now support RADIUS accounting. If you enable RADIUS accounting in a splittunnel Remote AP’s AAA profile, the controller sends a RADIUS accounting start record to the RADIUS server when a user associates with the remote AP, and sends a stop record when the user logs out or is deleted from the user database. If interim accounting is enabled, the controller sends updates at regular intervals. Each interim record includes cumulative user statistics, including received bytes and packets counters.
You can use either the WebUI or CLI to assign a server group for RADIUS accounting.
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > AAA Profiles page.
2. Select AAA Profile, then the AAA profile instance.
3. (Optional) In the Profile Details pane, select RADIUS Interim Accounting to allow the controller to send
Interim-Update messages with current user statistics to the server at regular intervals. This option is disabled by default, allowing the controller to send only start and stop messages RADIUS accounting server.
4. In the profile list, scroll down and select the Radius Accounting Server Group for the AAA profile. Select the server group from the drop-down list.
You can add additional servers to the group or configure server rules.
5. Click Apply .
Using the CLI
(host)(config) #aaa profile < profile> radius-accounting < group> radius-interim-accounting
Roaming RADIUS Accounting Service
Starting from ArubaOS 6.5.2, the Roaming RADIUS Accounting Service creates an Accounting session for each wireless client. The records in the session contain the same set of RADIUS attributes as compared to the timerbased RADIUS Interim-Update Accounting record, except the statistics attributes. Whenever a wireless client roams to a different AP, the Roaming triggered RADIUS Interim-Update Accounting record is sent to the configured RADIUS Accounting server. This record is used to track the current location of the wireless client.
Currently this feature is supported only for wireless clients and not for wired, VPN/VIA, and L3-Mobility clients.
You can enable roaming RADIUS accounting services by using the WebUI and CLI:
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > AAA Profiles page.
2. Select AAA Profile , then select the AAA profile instance.
210 | Authentication Servers ArubaOS 6.5.3.x | User Guide
3. Select the RADIUS Roaming Accounting check box.
4. Click Apply .
5. Click Save Configuration .
Using the CLI
To enable roaming RADIUS accounting services, use the following CLI:
(host) (config) # aaa profile <profile_name> radius-accounting <group> radius-roam-accounting
To check if roaming-triggered RADIUS accounting is enabled, use the following CLI:
(host) #show aaa profile <profile_name>
RADIUS Accounting on Multiple Servers
ArubaOS provides support for the controllers to send RADIUS accounting to multiple RADIUS servers. The controller notifies all the RADIUS servers to track the status of authenticated users. Accounting messages are sent to all the servers configured in the server group in a sequential order.
You can enable multiple server account functionality by using the WebUI and CLI:
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > AAA Profiles page.
2. Select AAA Profile , then select the AAA profile instance.
3. Select the Multiple Server Accounting check box.
4. Click Apply .
5. Click Save Configuration .
Using the CLI
To enable RADIUS Accounting on Multiple Servers functionality, use the following CLI:
(host) (config) # aaa profile <profile_name> multiple-server-accounting
TACACS+ Accounting
TACACS+ accounting allows commands issued on the controller to be reported to TACACS+ servers. You can specify which types of commands are reported (action, configuration, or show commands), or report all commands.
You can configure TACACS+ accounting through the CLI:
(host)(config) #aaa tacacs-accounting server-group <group> command
{action|all|configuration|show} mode {enable|disable}
You can configure TACACS+ accounting through the WebUI:
1. Navigate to Configuration > SECURITY > Authentication .
2. In the Servers tab, click Tacacs Accounting Server .
3. In the Tacacs Accounting Server section: a. select an entry from the Server Group drop-down list.
b. select the appropriate Command check boxes to enable accounting for all commands of specified types.
c. select the Mode check box to enable or disable TACACS+ accounting.
4. Click Apply .
5. Click Save Configuration .
ArubaOS 6.5.3.x
| User Guide Authentication Servers | 211
Configuring Authentication Timers
describes the timers you can configure for all clients and servers. These timers can be left at their default values for most implementations.
Table 53: Authentication Timers
Timer
User Idle Timeout
Description
Authentication Server
Dead Time
Logon User Lifetime
User Interim stats frequency
Maximum period after which a client is considered idle if there is no wireless traffic from the client. The timeout period is reset if there is wireless traffic. If there is no wireless traffic in the timeout period, the client is aged out. Once the timeout period has expired, the user is removed. If the keyword seconds is not specified, the value defaults to minutes at the command line.
Range: 1–255 minutes (30–15300 seconds)
Default: 5 minutes (300 seconds)
Maximum period, in minutes, that the controller considers an unresponsive authentication server to be “out of service.”
This timer is only applicable if there are two or more authentication servers configured on the controller. If there is only one authentication server configured, the server is never considered out of service, and all requests are sent to the server.
If one or more backup servers are configured and a server is unresponsive, it is marked as out of service for the dead time; subsequent requests are sent to the next server on the priority list for the duration of the dead time. If the server is responsive after the dead time has elapsed, it can take over servicing requests from a lowerpriority server; if the server continues to be unresponsive, it is marked as down for the dead time.
Range: 0–50 minutes
Default: 10 minutes
Maximum time, in minutes, unauthenticated clients are allowed to remain logged on.
Range: 0–255 minutes
Default: 5 minutes
Sets the timeout value for user stats, reporting in minutes or seconds.
Range: 300–600 seconds, or 5–10 minutes
Default: 600 seconds
Setting an Authentication Timer
To set an authentication timer, complete one of the following procedures:
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Advanced page.
2. Configure the timers as described above.
3. Click Apply before moving on to another page or closing the browser window. If you do not perform this step, you will lose your configuration changes.
Using the CLI
The commands below configure timers you can apply to clients. If the optional seconds keyword is not specified for the idle-timeout and stats-timeout parameters, the value defaults to minutes.
(host)(config) #aaa timers dead-time <minutes>
212 | Authentication Servers ArubaOS 6.5.3.x | User Guide
idle-timeout <time> [seconds] logon-lifetime <0-255> stats-timeout <time> [seconds]
Authentication Server Load Balancing
Load balancing of authentication servers ensures that the authentication load is split across multiple authentication servers, thus avoiding any one particular authentication server from being overloaded.
Authentication Server Load Balancing functionality enables the Aruba Controller to perform load balancing of authentication requests destined for external authentication servers (Radius/LDAP etc). This prevents any one authentication server from having to handle the full load during heavy authentication periods, such as at the start of the business day.
Starting from ArubaOS 6.5.1.0, the ArubaOS controllers perform load balancing of RADIUS accounting packets that are destined to external RADIUS Servers to ensure accounting load gets distributed. Server-load-balancing is enabled for RADIUS accounting packets as well.
Previously, the controller used the first authentication server in the server group list. The remaining servers in that group would be used in sequential order only when an authentication server was down. Thus, the controllers performed fail-over instead of load balancing of authentication servers.
The load balancing algorithm computes the expected time taken to authenticate a new client for each authentication server and chooses that authentication server with the shorted expected authentication time.
The load balancing algorithm maintains re-authentication stickiness, meaning that at the time of reauthentication, the request is forwarded to the same server where it was originally authenticated.
Enabling Authentication Server Load Balancing Functionality
A new load–balancing enable parameter has been introduced in the aaa server-group test command to enable authentication server load balancing functionality.
aaa server-group <sg_name> load-balance auth-server s1 auth-server s2
You can use the following command to disable load balancing: aaa server-group<sg_name> no load-balance
If you configure an internal server in the server group, load balancing is not applicable to the internal server. The
Internal server will be used as a fall-back when all other servers in the group are down.
ArubaOS 6.5.3.x
| User Guide Authentication Servers | 213
Chapter 10
MAC-based Authentication
This chapter describes how to configure MAC-based authentication on the Aruba controller using the WebUI.
Use MAC-based authentication to authenticate devices based on their physical media access control (MAC) address. Although this not the most secure and scalable method, MAC-based authentication implicitly provides an addition layer of security to authenticate devices. MAC-based authentication is often used to authenticate and allow network access through certain devices while denying access to the rest. For example, if clients are allowed access to the network through station A, then one method of authenticating station A is MAC-based.
Clients may be required to authenticate themselves using other methods depending on the network privileges required.
MAC-based authentication can also be used to authenticate Wi-Fi phones as an additional layer of security to prevent other devices from accessing the voice network using what is normally an insecure SSID.
This chapter describes the following topics: n n
Configuring MAC-Based Authentication on page 214
Configuring Clients on page 215
n n
Configuring MAC-Based Authentication
Before configuring MAC-based authentication, you must configure the following options:
User role—The user role that will be assigned as the default role for the MAC-based authenticated clients.
(See
Roles and Policies on page 381
for information on firewall policies to configure roles.)
Configure the default user role for MAC-based authentication in the AAA profile. If derivation rules exist or if the client configuration in the internal database has a role assigned, these values take precedence over the default user role.
Authentication server group—The authentication server group that the controller uses to validate the clients. The internal database can be used to configure the clients for MAC-based authentication. See
Configuring Clients on page 215
for information on configuring the clients on the local database. For information on configuring authentication servers and server groups, see
Authentication Servers on page
Configuring the MAC Authentication Profile
describes the parameters you can configure for MAC-based authentication.
ArubaOS 6.5.3.x
| User Guide MAC-based Authentication | 214
Table 54: MAC Authentication Profile Configuration Parameters
Parameter Description
Delimiter
Case
Max Authentication failures
Delimiter used in the MAC string: n colon specifies the format Xx:XX:XX:XX:XX:XX n n dash specifies the format XX-XX-XX-XX-XX-XX none specifies the format XXXXXXXXXXXX n oui-nic specifies the format XXXXXX:XXXXXX
Default: none
NOTE: This parameter is available for the aaa authentication-server radius command.
The case (upper or lower) used in the MAC string.
Default: lower
Number of times a station can fail to authenticate before it is blacklisted. A value of zero disables blacklisting.
Default: zero (0)
In the WebUI
1. Navigate to the Configuration > Security > Authentication > L2 Authentication page.
2. Select MAC Authentication Profile.
3. Enter a profile name and click Add .
4. Select the profile name to display configurable parameters.
5. Configure the parameters, as described in
.
6. Click Apply .
In the CLI
Execute the following command to configure a MAC authentication profile:
(host)(configure) #aaa authentication mac < profile> case {lower|upper} delimiter {colon|dash|none} max-authentication-failures <number>
Configuring Clients
You can create entries in the controller’s internal database to authenticate client MAC addresses. The internal database contains a list of clients along with the password and default role for each client. To configure entries in the internal database for MAC authentication, you enter the MAC address for both the username and password for each client.
You must enter the MAC address using the delimiter format configured in the MAC authentication profile. The default delimiter is none, which means that MAC addresses should be in the format xxxxxxxxxxxx. If you specify colons for the delimiter, you can enter MAC addresses in the format xx:xx:xx:xx:xx:xx.
In the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Internal DB .
3. Click Add User in the Users section. The user configuration page displays.
215 | MAC-based Authentication ArubaOS 6.5.3.x | User Guide
4. For User Name and Password , enter the MAC address for the client. Use the format specified by the
Delimiter parameter in the MAC Authentication profile. For example, if the MAC Authentication profile specifies the default delimiter (none), enter MAC addresses in the format xxxxxxxxxxxx
.
5. Click Enabled to activate this entry on creation.
6. Click Apply .
The configuration does not take effect until you perform this step.
In the CLI
Enter the following command in enable mode:
(host)(config) #local-userdb add username < macaddr> password < macaddr> ...
ArubaOS 6.5.3.x
| User Guide MAC-based Authentication | 216
Chapter 11
Branch Controller Config for Cloud Services Controllers
Many distributed enterprises with branch and remote offices and locations use cost-effective hybrid WAN connectivity solutions that include low-cost DSL, 4G and LTE technologies, rather than relying solely on traditional E1/T1 or T3/E3 dedicated circuits. 7000 Series Cloud Services Controllers are optimized for these types of locations, which are more likely to use cloud security architectures instead of dedicated security appliances, and where clients are likely to access applications in the cloud, rather than on local application servers.
Throughout this document the term branch controller will refer to a 7000 Series Series Cloud Services controller that has been configured via a branch config group created using the ArubaOS Smart Config WebUI.
ArubaOS supports these distributed enterprises through the following features designed specifically for branch and remote offices: n n n n n n
Authentication survivability allows 7000 Series controllers to store user access credentials and key reply attributes whenever clients are authenticated with external RADIUS servers or LDAP authentication servers, providing authentication and authorization survivability when remote authentication servers are not accessible.
Integration with existing Palo Alto Networks Firewalls, like WildFire™ anti-virus and anti-malware detection services. In deployments with multiple Palo Alto Networks (PAN) firewalls, 7000 Series controllers can select the best PAN firewall based on priority and availability.
Policy-based routing on each uplink interface, which allows you specify the next hop to which packets are routed. ArubaOS supports multiple next-hop lists, to ensure connectivity in the event that a device on the list becomes unreachable.
Uplink and VPN redundancy, and per-interface bandwidth contracts to limit traffic for individual applications (or categories of applications) either sent from or received by a selected interface.
Packet compression between Aruba devices (such as devices at the branch and main office), to maximize the amount of data that can be carried by the network.
A WAN health-check feature that uses ping-probes to measure WAN availability and latency on each uplink.
The following diagram depicts managed node where a branch controller in the branch office learns the address, routing information, and other provisioning information from the master controller.
ArubaOS 6.5.3.x
| User Guide Branch Controller Config for Cloud Services Controllers | 217
This chapter describes the features and functions of a branch controller, and includes the following topics: n n n n n n
Branch Deployment Features on page 218
Zero-Touch Provisioning on page 232
Using Smart Config to create a Branch Config Group on page 239
PortFast and BPDU Guard on page 260
Preventing WAN Link Failure on Virtual APs on page 262
Branch WAN Dashboard on page 263
n n n n n n n n
Branch Deployment Features
This section describes the following branch controller features. For details on the configuration parameters for each of these features, see
Using Smart Config to create a Branch Config Group on page 239
.
Layer-3 Redundancy for Branch Controller Masters on page 219
WAN Failure (Authentication) Survivability on page 220
WAN Optimization through IP Payload Compression on page 226
Interface Bandwidth Contracts on page 227
Branch Integration with a Palo Alto Networks (PAN) Portal on page 228
Branch Controller Routing Features on page 231
Cloud Management on page 232Cloud Management on page 232
218 | Branch Controller Config for Cloud Services Controllers ArubaOS 6.5.3.x | User Guide
Scalable Site-to-Site VPN Tunnels
ArubaOS 6.4.4.0 and later supports site-to-site IPSEC tunnels based on a Fully Qualified Domain Name (FQDN).
When you identify the remote peer for a branch config group using an FQDN, that config group can be applied across multiple branch controllers, as the configured FQDN can resolve to different IP addresses for each local branch, based on local DNS settings.
In ArubaOS 6.4.4.0 and later releases, crypto maps for site-to-site VPNs support a VLAN ID as the identifier for the source network. When the VPN settings are pushed to branch controller, the IKE negotiation process uses the IP address range for the VLAN. This feature allows you to push the same source network configuration to multiple branch controllers, as each branch controller negotiates a different source source network IP for its
VLAN based on the IP pool for that local branch.
Layer-3 Redundancy for Branch Controller Masters
ArubaOS 6.4.4.0 introduces support for a redundant secondary master controller in branch controller deployments. This prevents a scenario where a master controller acts as a single point of failure if the link to the master goes down, or a co-located Master-Standby VRRP controller pair fail due to a network failure or local natural disaster.
Configuring Layer-3 Redundancy
The IP address of a primary master and a secondary, backup master controller can be defined for a branch during the
branch controller during the initial startup dialog, or defined via an Activate server. The primary and secondary master controllers must be manually kept in synchronization by ensuring all the configuration, certificates, and branch controller whitelist, AP whitelist and local user database are the same in both of them.
Database settings are not automatically synchronized from a primary master to a secondary master with Layer-3 redundancy. All database settings, certificates, whitelist settings and profile configurations must be kept in sync manually.
Viewing Controller Connectivity Status
The status of the branch's connection to a primary and secondary master controller appears in the
page of the branch controller WebUI. To display the current status of the branch controller's connectivity to the master and secondary master IP addresses, click the Layer3 Redundancy tab on the
Status section of the dashboard.
Figure 39 Branch Controller Redundancy Status
Failover Behaviors
When a provisioned branch controller detects that its primary master is unreachable, it attempts to reconnect to the primary master for the time period defined by the
Master L3 Redundancy Switchover Timeout
in its branch controller configuration. If the branch controller cannot reconnect to the primary master controller during this switchover timeout period, and the secondary controller is up and reachable, the branch controller
ArubaOS 6.5.3.x
| User Guide Branch Controller Config for Cloud Services Controllers | 219
reloads and associates to the secondary controller as the new master. The branch controller then synchronizes its branch and global configuration settings from the new master, and reloads again to apply those settings.
n n n n n n n n
WAN Failure (Authentication) Survivability
This section contains the following information about the authentication survivability feature. This feature is supported on 7000 Series controllers.
Supported Client and Authentication Types
Trigger Conditions for Critical Actions
Authentication for Captive Portal Clients
Authentication for 802.1X Clients
Authentication for MAC Address-Based Clients
Authentication for WISPr Clients
Authentication survivability allows controllers to provide client authentication and authorization survivability when remote authentication servers are not accessible. It stores user access credentials, as well as key reply attributes, whenever clients are authenticated with external RADIUS servers or LDAP authentication servers.
When external authentication servers are not accessible, the controller uses its local Survival Server to continue providing authentication and authorization functions by using the user access credentials and key reply attributes that were stored earlier.
Authentication survivability is critical to WLANs managed by branch controllers since most branch controllers use geographically remote authentication servers to provide authentication and authorization services. When those authentication servers are not accessible, clients can't access the WLAN because the branch controller can't authenticate them.
This feature can be configured for branch controllers using the Smart Config WebUI, or for master and local controllers using the aaa auth-survivability commands in the command-line interface. For details on configuring this feature using the Smart Config WebUI, see
WAN Configuration on page 256 .
Supported Client and Authentication Types
The following combination of clients and authentication types are supported with the authentication survivability feature (see
):
Table 55: Clients and Supported Authentication Types
Clients
Captive Portal clients
802.1X clients
Authentication Methods
Password Authentication Protocol (PAP) n n
Termination disabled : Extensible Authentication Protocol-Transport
Layer Security (EAP-TLS) with an external RADIUS server
Termination enabled : EAP-TLS with Common Name (CN) lookup with an external authentication server
PAP External Captive Portal clients using the XML-API
MAC-based Authentication clients PAP
220 | Branch Controller Config for Cloud Services Controllers ArubaOS 6.5.3.x | User Guide
Clients
VPN clients
VIA and other VPN clients
Wireless Internet Service Provider roaming (WISPr) clients
Authentication Methods n n
PAP with an external authentication server
CN lookup with an external authentication server
PAP method and CN lookup
PAP
In this initial release, the external authentication server can be either a RADIUS server or an LDAP server.
Supported Key Reply Attributes
The following key reply attributes are supported: n n n n n n n n n
ARUBA_NAMED_VLAN
ARUBA_NO_DHCP_FINGERPRINT
ARUBA_ROLE
ARUBA_VLAN
MS_TUNNEL_MEDIUM_TYPE
MS_TUNNEL_PRIVATE_GROUP_ID
MS_TUNNEL_TYPE
PW_SESSION_TIMEOUT
PW_USER_NAME
Support Restrictions
The authentication survivability feature has the following support restrictions: n n n n n
The Survival Server cache database is station-based (thus, the MAC address is the key), so authentication survivability is not supported for any station with a zero MAC address.
For a client using EAP-TLS, you must install the issuer certificate of the Survival Server certificate as a
TrustedCA certificate in the client station.
For an 802.1X client using EAP-TLS that does not terminate at the controller, the issuer certificate for the client certificate must be imported as a TrustedCA or an intermediateCA certificate at the controller—just as the same certificate must be installed at the terminating External RADIUS server.
The Survival Server does not support the Online Certificate Status Protocol (OCSP) nor the Certificate
Revocation List (CRL) for EAP-TLS.
Authentication survivability will not activate if Authentication Server Dead Time is configured as 0.
To configure Authentication Server Dead Time, on the controller, navigate to: Configuration > SECURITY >
Authentication > Advanced > Authentication Timers > Authentication ServerDeadTime (min) .
Administrative Functions
This section describes the scenarios that illustrate the functionality that the authentication survivability feature provides. For more information, see: n
WAN Failure (Authentication) Survivability on page 220
ArubaOS 6.5.3.x
| User Guide Branch Controller Config for Cloud Services Controllers | 221
Enabling Authentication Survivability on a Local Branch Controller
You can configure each local branch controller to enable or disable Authentication Survivability; by default, this feature is disabled.
When authentication survivability is enabled, the enabled authentication survivability state is published, which instructs the Survival Server to start storing client access credential attributes and Key Reply attributes.
Configuring the Survival Server Certificate
A default server certificate is provided in the controller so that the local Survival Server can terminate EAP-TLS
802.1X requests.
Best practices is to import a customer server certificate into the controller and assign it to the local survival server.
Configuring the Lifetime of the Authentication Survivability Cache
All access credentials and Key Reply attributes that are saved in the local Survival Server remain in the system until they expire. The system-wide lifetime parameter auth-survivability cache lifetime has a range from 1 to 72 hours, and a default value of 24 hours. You must configure this parameter in each controller.
User Credential and Key Reply Attributes Are Saved Automatically
When a station is authenticated by an external authentication server, required access credential attributes and
Key Reply attributes are stored in the local Survival Server RADIUS database in an enabled authentication survivability ArubaOScontroller.
Expired User Credential and Key Reply Attributes Are Purged Automatically
At the controller, a timer task that runs every 10 minutes purges expired user credential attributes and Key
Reply attributes that are stored in the Survival Server cache.
About the Survival Server
A local Survival Server runs on the controller to perform authentication functions, as well as EAP-termination using the RADIUS protocol.
The Survival Server consists of a turn-key FreeRADIUS server, plus MySQL database tables.
When authentication survivability is enabled, a FreeRADIUS server runs on the controller. The Survival Server is configured to accept RADIUS requests from the local host and retrieve the access credential and Key Reply attributes from the MySQL database. The Survival Server supports EAP-TLS, PAP, and Common Name (CN) lookup.
Trigger Conditions for Critical Actions
This section describes the trigger conditions for critical authentication survivability actions.
Storing User Access Credential and Key Reply Attributes to Survival Cache
Aruba OS stores the user access credential and Key Reply attributes under the following conditions:
1. Authentication survivability is enabled
2. The non-zero MAC-address client is authenticated using one of the following options: a. Authenticated with an External RADIUS server using PAP or EAP-TLS b. Authenticated with an External LDAP server using PAP c. Successful query on Common Name (CN) with an External RADIUS or LDAP server
222 | Branch Controller Config for Cloud Services Controllers ArubaOS 6.5.3.x | User Guide
Picking Up the Survival Server for Authentication
The Survival Server performs an authentication or query request when authentication survivability is enabled, and one of the following is true:
1. All servers are out of service in the server group if fail-through is disabled
2. All in-service servers failed the authentication and at least one server is out of service when fail-through is enabled.
Access Credential Data Stored
In addition to the username, the following access credential data is stored: n n n
Password Authentication Protocol (PAP): authmgr receives the password provided by the client and then stores the encrypted SHA-1 hashed value of the password.
When employing 802.1X with disabled termination using EAP-TLS, the EAP indicator is stored.
The CN lookup EXIST indicator is stored.
Authentication for Captive Portal Clients
This section describes the authentication procedures for Captive Portal clients us, both when the branch's authentication servers are available and when they are not available. When the authentication servers are not available, the Survival Server takes over the handling of authentication requests.
This section describes the following authentication scenarios: n n
Captive Portal clients authentication using Password Authentication Protocol (PAP)
External Captive Portal clients authentication using the XML-API
Captive Portal Client Authentication Using PAP
describes what occurs for Captive Portal clients using PAP as the authentication method.
Table 56: Captive Portal Authentication Using PAP
When Authentication Servers Are
Available n n
If authentication succeeds, the associated access credential with an encrypted SHA-1 hash of the password and Key Reply attributes are stored in the Survival Server database.
If authentication fails, the associated access credential and Key Reply attributes associated with the PAP method (if they exist) are deleted from the Survival Server database.
When Authentication Servers Are Not Available
When no in-service server in the associated server group is available, the Survival Server is used to authenticate the Captive portal client using PAP.
The Survival Server uses the previously stored unexpired access credential to perform authentication and, upon successful authentication, returns the previously stored Key Reply attributes.
External Captive Portal Client Authentication Using the XML-API
describes the authentication procedures for External Captive Portal clients using the XML-API, both when the branch's authentication servers are available and when they are not available. When the authentication servers are not available, the Survival Server takes over the handling of authentication requests.
ArubaOS 6.5.3.x
| User Guide Branch Controller Config for Cloud Services Controllers | 223
Table 57: Captive Portal Authentication Using XML-API
When Authentication Servers Are Available
For authentication requests from an External Captive
Portal using the XML-API, PAP is used to authenticate these requests with an external authentication server.
n If authentication succeeds, the associated access credential with an encrypted SHA-1 hash of the password and Key Reply attributes are stored in the
Survival Server database.
n If authentication fails, the associated access credential and Key Reply attributes associated with the PAP method (if they exist) are deleted from the
Survival Server database.
When Authentication Servers Are Not
Available
When no in-service server in the associated server group is available, the Survival Server is used to authenticate the Captive portal client using PAP.
The Survival Server uses the previously stored unexpired access credential to perform authentication and, upon successful authentication, returns the previously stored
Key Reply attributes.
Authentication for 802.1X Clients
This section describes the authentication procedures for 802.1X clients, both when the branch's authentication servers are available and when they are not available. When the authentication servers are not available, the
Survival Server takes over the handling of authentication requests.
For 802.1X clients, the authentication scenarios include two different 802.1X termination modes: n n
802.1X termination disabled at the Wireless LAN Controller
802.1X termination enabled at the Wireless LAN Controller
802.1X Termination Disabled at the Wireless LAN Controller
Table 58: 802.1X Authentication Using EAP-TLS
When Authentication Servers Are Available
For an 802.1X client that terminates at an external RADIUS server using EAP-TLS: n n
If authentication is accepted, the associated access credential with the EAP-TLS indicator, in addition to the
Key Reply attributes, are stored in the Survival Server database.
If authentication is rejected, the associated access credential and Key Reply attributes associated with the
EAP-TLS method (if they exist) are deleted from the
Survival Server database.
When Authentication Servers Are Not
Available
When there is no available in-service server in the associated server group, the Survival Server terminates and authenticates 802.1X clients using
EAP-TLS.
The Survival Server uses the previously stored unexpired access credential to perform authentication and, upon successful authentication, returns the previously stored Key Reply attributes.
In this case, the client station must be configured to accept the server certificate assigned to the Survival
Server.
802.1X Termination Enabled at the Wireless LAN Controller
For an 802.1X client for which termination is enabled at the wireless LAN controllerusing EAP-TLS with
Common Name (CN) lookup, a query request about the Common Name is sent to the external authentication server.
The external authentication server can be either a RADIUS server or an LDAP server.
224 | Branch Controller Config for Cloud Services Controllers ArubaOS 6.5.3.x | User Guide
Table 59: 802.1X Client Authentication Using EAP_TLS with CN Lookup
When Authentication Servers Are Available n n
If the query succeeds, the associated access credential with a returned indicator of EXIST , plus the Key Reply attributes, are stored in the Survival Server database.
If the query fails, the associated access credential and
Key Reply attributes associated with the Query method
(if they exist) are deleted from the Survival Server database.
When Authentication Servers Are Not
Available
When there is no available in-service server in the associated server group, the Survival Server performs CN lookup for 802.1X clients for which termination is enabled at the controller using EAP-
TLS.
The Survival Server returns previously stored Key
Reply attributes as long as the client with the EXIST indicator is in the Survival Server database.
Authentication for MAC Address-Based Clients
This section describes the authentication procedures for MAC address-based clients, both when the branch's authentication servers are available and when they are not available. When the authentication servers are not available, the Survival Server takes over the handling of authentication requests.
Table 60: MAC-Based Client Authentication Using PAP
When Authentication Servers Are Available n n
If authentication succeeds, the associated access credential, along with an encrypted SHA-1 hash of the password and Key Reply attributes, are stored in the
Survival Server database.
If authentication fails, the associated access credential and Key Reply attributes associated with the PAP method (if they exist) are deleted from the Survival
Server database.
When Authentication Servers Are Not
Available
When there is no available in-service server in the associated server group, the Survival Server authenticates the MAC-based authentication client using PAP.
The Survival Server returns previously stored Key
Reply attributes as long as the client with the EXIST indicator is in the Survival Server database.
Authentication for WISPr Clients
This section describes the authentication procedures for Wireless Internet Service Provider roaming (WISPr) clients, both when the branch's authentication servers are available and when they are not available. When the authentication servers are not available, the Survival Server takes over the handling of authentication requests.
The external authentication server can be either a RADIUS server or an LDAP server.
ArubaOS 6.5.3.x
| User Guide Branch Controller Config for Cloud Services Controllers | 225
Table 61: WISPr Authentication Using PAP
When Authentication Servers Are Available
When Authentication Servers Are Not
Available
For a WISPr client authenticated by an external server using
PAP: n If authentication succeeds, the associated access credential, along with an encrypted SHA-1 hash of the password and Key Reply attributes, are stored in the
Survival Server database.
n
If authentication fails, the associated access credential and Key Reply attributes (if they exist) associated with the PAP method are deleted from the Survival Server database.
When there is no available in-service server in the associated server group, the Survival Server authenticates the WISPr client using PAP.
Upon successful authentication, the Survival Server uses the previously stored unexpired credential to perform authentication, and returns the previously stored Key Reply attributes .
WAN Health Check
The health-check feature uses ping-probes to measure WAN availability and latency on selected uplinks. Based upon the results of this health-check information, the controller can continue to use its primary uplink, or failover to a backup link. Latency is calculated based on the round-trip time (RTT) of ping responses. The results of this health check appear in the WAN section of the
For details on configuring this feature using the Smart Config WebUI, see
.
WAN Optimization through IP Payload Compression
Data compression reduces the size of data frames that are transmitted over a network link, thereby reducing the time required to transmit the frame across the network. IP payload compression is one of the key features of the WAN bandwidth optimization solution, which is comprised of the following elements: n n n
IP Payload Compression
Traffic Management and QoS
Caching
Since the branch controller can send traffic to destinations other than the corporate headquarters on the same link, the preferred method is to enable payload compression on the IPsec tunnel between the branch controller and the master controller.
IP payload should be enabled only between Aruba devices. When this hardware-based compression feature is enabled, the quality of unencrypted traffic (such as Skype4b or Voice traffic) is not compromised through increased latency or decreased throughput.
Starting from ArubaOS 6.5.1, WAN optimization through IP payload compression is supported in 7205 controllers.
Distributed Layer 3 Branch Deployment Model
In the branch deployment model shown in
, the IPsec tunnels are terminated on the master controller. IPsec tunnels are treated as master-local tunnels.
226 | Branch Controller Config for Cloud Services Controllers ArubaOS 6.5.3.x | User Guide
Figure 40 Branch Deployment Model with Master Controller in HQ
Modes of Operation
There are three modes of operation for the deflation and inflation compression processes: n n n
Static Compression
For static compression, a predefined Huffman code is used that may not be ideal for the block in question, but it usually achieves acceptable compression. The advantage of static compression is its speed of execution.
Dynamic Compression
The advantage of dynamic compression is a higher compression ratio. However, dynamic compression is slower than static compression, as it requires two passes to complete the process.
No Compression
You can use no compression for data such as an embedded image file that might already be in a compressed format. Such data does not compress well, and may even increase in size.
For details on configuring this feature using the Smart Config WebUI, see
WAN Configuration on page 256 .
n
Interface Bandwidth Contracts
7000 Series controllers have the ability to classify and identify applications on the network. If a 7000
Series controller is configured as a branch office controller, you can create bandwidth contracts to limit traffic for individual applications (or categories of applications) either sent from or received by a selected interface.
There are two basic models for using this feature.
Limiting lower-priority traffic : If there is a lower-priority application or application type that you want to limit, apply a bandwidth contract just to that application, and allow all other application traffic to pass without any limits.
ArubaOS 6.5.3.x
| User Guide Branch Controller Config for Cloud Services Controllers | 227
n
Protecting higher-priority traffic : If you want to guarantee bandwidth for a company-critical application or application group, you can add that application to an exception list, then apply a bandwidth contract to all remaining traffic.
You can apply bandwidth contracts using one or both of these models. Each interface supports up to 64 bandwidth contracts. An interface bandwidth contract is applied to downstream traffic before a user-role bandwidth contract is applied, and upstream traffic, the user-role bandwidth contract is applied before the interface bandwidth contract.
For all traffic using compression and encryption, bandwidth contracts are applied after that traffic is compressed and encrypted. If you apply more than one bandwidth contract to any specific category type, then the bandwidth contracts are applied in the following order.
1. A contract that explicitly excludes an application
2. A contract that explicitly excludes an application category
3. A contract that applies to a specific application
4. A contract that applies to a specific application category
5. A generic bandwidth contract, not specific to any application or application category
For details on configuring this feature using the Smart Config WebUI, see
WAN Configuration on page 256 .
App and App Category Visibility
WAN uplinks are typically of relatively low bandwidth. The actual upstream/downstream bandwidth that a
WAN uplink provides is usually different from what the service provider provides. Hence, ensure that the traffic transmitted by a Branch controller matches the actual rate provided by the service provider. This avoids congestion in the link from the Branch controller to the WAN. Congestion may cause traffic to be dropped and if the uplink has both high and low priority traffic, low priority traffic might not be dropped first. Hence, a
Branch controller classifies traffic into multiple priorities and shapes the egress traffic to match the actual upstream bandwidth.
If there is any unused bandwidth in the downstream direction, a Branch controller allows the users to use the unused bandwidth although this bandwidth exceeds the allocation of the user. A Branch controller ensure this by using an ingress scheduler with minimum-bandwidth guarantees.
Minimum bandwidth guarantees are provided on per traffic class basis. Additional classification is done on the traffic flows and these are assigned newer traffic classes. Use hardware assist or software scheduler to schedule these new traffic classes to achieve minimum-bandwidth guarantees. Maximum bandwidth is enforced with bandwidth contracts.
Allocate higher bandwidth to critical applications and schedule them with higher priority.
Due to the wide range of bandwidth possibilities, percentages are used to provision bandwidth for the interface bandwidth contracts. Use the templates to configure multiple different bandwidth links across all
Branch controllers. For example, 50 % for 500 Mbps for a 1 Gbps link or 50 mbps for a 100 mbps uplink.
On the WAN dashboard, for the AppRF window, currently the statistics/flows are detailed to view the AppRF stats on a per-uplink basis.
Branch Integration with a Palo Alto Networks (PAN) Portal
Branch controller deployments can leverage their networks' existing PaloAlto infrastructure to access more advanced security services, including antivirus services, malware detection and seamless integration with the
Palo Alto Networks WildFire TM cloud-based threat detection.
228 | Branch Controller Config for Cloud Services Controllers ArubaOS 6.5.3.x | User Guide
Enable Palo Alto firewall integration on a master controller to securely redirect internet inbound traffic from branch controllers using the branch config group into the PAN firewall. Although this configuration setting can be used on standalone or local controllers, this feature can only be used on controllers in these types of deployments when used in conjunction with the controller uplink VLAN manager feature.
The uplink VLAN manager is enabled by default on branch controller uplinks. Master or local (non-branch) controllers using the PAN portal feature must enable the uplink VLAN manager using the uplink command in the controller command-line interface.
Figure 41 Branch Controller and PAN Firewall Integration
Integration Workflow
The following steps describes the work flow to integrate a branch controller with a Palo Alto Networks (PAN)
Large-Scale VPN (LSVPN) firewall.
1. Palo Alto Portal certificates are installed on the master controller, and the master controller is configured with the Palo Alto portal IP address or FQDN, Palo Alto certificate, and the username and password for device authentication using the Configuration> Branch > Smart Config > WAN section of the master controller WebUI.
2. The 7000 Series branch controller is provisioned via Aruba Activate and downloads its configuration
(including Palo Alto Networks integration settings).
3. The Palo Alto portal may be configured with the device number (a text string comprised of the device serial number followed by its MAC address) of the branch controller(s) at each remote office site. This allows the branch controller to bypass the username and password challenge to authenticate to the portal.
4. The branch controller initiates a secure connection to the Palo Alto portal. Once the branch controller is authenticated, the Palo Alto portal sends the branch controller a list of PAN gateways and priority levels.
Once the branch controller is authenticated, that device appears in the PAN satellite list, as shown in the figure below.
ArubaOS 6.5.3.x
| User Guide Branch Controller Config for Cloud Services Controllers | 229
Figure 42 Palo Alto Networks Active Satellites List
.
5. The branch controller uses the Palo Alto Networks gateway list and credentials from the portal to contact all
PAN gateways. Each PAN gateway sends the branch controller information that allows the branch controller to automatically create a secure IPsec tunnel and exchange branch subnet routes with each PAN gateway.
6. The branch controller maintains a priority list of IPsec tunnels to each PAN gateway to enable failover in the event a PAN gateway becomes unreachable.
7. Policy-based routing access control lists (ACLs) on the branch controller selectively routes traffic to the PAN gateways.
8. Traffic redirected from the branch controller is inspected via the Palo Alto Networks firewall.
Configuration Prerequisites
The Palo Alto Networks LSVPN framework can integrate with a branch controller by establishing an IPsec tunnels between the firewall and the controller. Integrating a Palo Alto Networks firewall with a 7000
Series controller requires that all user traffic is routed, so it can be managed by a policy-based routing access control list.
The following certificate requirements must be fulfilled before the branch controller can integrate with the Palo
Alto Networks Large-Scale VPN (LSVPN) framework: n n n the LSVPN framework must be installed and active on your network. For more information on configuring
Palo Alto Networks products, refer to the Palo Alto Networks Technical Documentation portal .
The CA certificate used by the Palo Alto portal must be installed on the master controller, so that it can be pushed down to the branch controllers.
On the PAN gateway devices, you must enable the accept published routes option, and the devices must install the server certificates derived from the management portal root CA.
In deployments with multiple PAN firewalls, you must configure the PAN management portal with a list of gateways and the priorities for each PAN gateway. Even if the PAN management portal uses serial number registration with preregistered serial numbers or MAC addresses, best practice is to configure LDAP, Radius,
Kerberos or Local Database authentication as well. This allows a controller to authenticate to the portal even if the portal does not recognize the controller's MAC address.
For details on configuring this feature using the Smart Config WebUI, see
WAN Configuration on page 256 .
230 | Branch Controller Config for Cloud Services Controllers ArubaOS 6.5.3.x | User Guide
Branch Controller Routing Features
The following sections describe some of the features that can be configured using the Smart Config WebUI. For details on configuring these feature using the Smart Config WebUI, see
Routing Configuration on page 249 .
Uplink Routing Using Nexthop Lists
A next-hop IP is the IP address of a adjacent router or device with Layer-2 connectivity to the controller. If the controller uses policy-based routing to forward packets to a next hop device and that device becomes unreachable, the packets matching the policy will not reach their destination.
The nexthop list provides redundancy for the next-hop devices by forwarding the traffic to a backup next hop device in case of failures. If the active next-hop device on the list becomes unreachable, traffic matching a policy-based routing ACL is forwarded using the highest-priority active next-hop device on the list.
If preemptive failover is enabled and a higher priority next hop becomes reachable again, packets are again forwarded to the higher priority next-hop device.
For more information on creating a routing policy that references a nexthop list, see
Configuring Firewall Policies on page 381
.
A maximum of four next-hop device entries can be added to a nexthop list. Each next-hop device can be assigned a priority, which decides the order of selection of the next hop. If a higher priority next-hop device goes down, the next higher priority active next-hop device is chosen for forwarding.
If all the next-hop devices are configured with same priority, the order is determined based on the order in which they are configured. If all the next-hops devices are down, traffic is passed regular destination-based forwarding.
In a typical deployment scenario with multiple uplinks, the default route only uses one of the uplink next-hop devices for forwarding packets. If a next hop device becomes unreachable, the packets will not reach their destination.
If your deployment uses policy-based routing based on a nexthop list, any of the uplink next hop devices could be used for forwarding traffic. This requires a valid ARP entry (route-cache) in the system for all the policybased routing next-hop devices. Each controller supports up to 32 nexthop lists.
In a branch office deployment, the site uplinks can obtain their IP addresses and default gateway using DHCP.
In such deployments, the nexthop list configuration can use the VLAN IDs of uplink VLANs. If the VLAN gets an
IP address using DHCP, and the default gateway is determined by the VLAN interface, the gateway IP is used as the next-hop IP address.
Branch deployments may also require policy-based redirection of traffic to different VPN tunnels. The nexthop list allows you to select an IPsec map to redirect traffic through IPsec tunnels.
Policy-Based Routing
Policy-based routing is an optional feature that allows packets to be routed based on access control lists (ACLs) configured by the administrator. By default, when a controller receives a packet for routing, it looks up the destination IP in the routing table and forwards the packet to the next-hop router. If policy-based routing is configured, the nexthop device can be chosen based on a defined access control list.
In a typical deployment scenario with multiple uplinks, the default route only uses one of the uplink next-hop devices for forwarding packets. If a next-hop device becomes unreachable, the packets will not reach their destination. If your deployment uses policy-based routing based on a nexthop list, any of the uplink next-hop devices can be used for forwarding traffic. This requires a valid ARP entry (Route-cache) in the system for all the policy-based routing next hop devices.
ArubaOS 6.5.3.x
| User Guide Branch Controller Config for Cloud Services Controllers | 231
Inbound Interface Access Lists
In a branch controller environment, where an IPsec map defines the connections between the local branch controllers and a master controller, the global routing ACL master-boc-traffic is applied to all IPsec maps between the master and the branch controllers. If any branch controller requires a different ACL, access the command-line interface of that branch controller and issue the command routing-policy-map branch <macaddr> access-list <acl> to associate a different ACL to the L3 GRE tunnel between that one branch controller and its master. This local setting will override the global settings defined in the master-boc-traffic ACL. For more information on configuring routing ACLs, see
Creating a Firewall Policy on page 382
.
To immediately associate a branch controller to the secondary master without waiting for the switchover timeout period to elapse, navigate to the Network>Controller>System settings page of the branch controller WebUI, and click the Switchover link.
If a branch controller detects that the link to the primary master controller is active but the branch cannot properly connect to the primary master due to a configuration error, the branch controller will wait for 10 minutes, then reboot and attempt to reconnect to the primary master. After 10 failed reboot and reconnect attempts, the branch controller will return to a factory default state and restart the provisioning process.
Cloud Management
ArubaOS enables the 7000 Series controllers to be managed by Aruba Central at a future date.
All communication between the controllers and Central will be secured. The controllers can establish connection with Central even if the controllers are behind NAT servers.
If the topology includes master and local controllers, a single master controller can communicate with Central.
In a master-local cluster topology, a local controller can communicate with both the master controller and
Central. The master controller will be the source for configuration data of the local controllers. Central manages the local configuration on the local controller.
Zero-Touch Provisioning
Traditionally, the deployment of controllers was a multiple step process where the master controller information and local configurations were first pre-provisioned. After the local controller connected to the network, it established a secure tunnel to the master and downloaded the global configuration.
Zero touch provisioning makes the deployment of local controllers plug-n-play. The local controller now learns the required information from the network and provisions itself automatically. A 7000 Series branch controller is a zero-touch provision (ZTP) controller that automatically gets its local and global configuration and license limits from a central controller.
A controller does not need to be configured as a branch controller to be provisioned using ZTP.
ZTP offers the following advantages over a standard local controller: n n n simple deployment reduced operational cost limits to provisioning errors
The main elements of ZTP are: n n auto discovery of the primary master (and optionally, backup master) controller.
configuration download from the master controller
232 | Branch Controller Config for Cloud Services Controllers ArubaOS 6.5.3.x | User Guide
Provisioning a controller includes completing the following: n n n setting the role setting the country code configuring the local configuration
The local configuration is the configuration that is specific to a controller. That is, not the global configuration shared by a network of controllers. This includes, but is not limited to, IP addresses and VLANs.
Once the controller is provisioned, it is ready to obtain its global configuration either by: n n
The administrator entering the global configuration directly from the WebUI or CLI of a master controller
The controller retrieving the global configuration from a master controller
Previously the steps of setting the role, setting the country code, and configuring the local configuration could only be performed manually by an administrator. With ZTP, these steps can be automatically completed.
The local configuration that a branch controller retrieves through ZTP is called as branch config group.
A controller that is deployed using ZTP is called as branch controller.
Only the 7000 Series cloud services controllers may be deployed as branch controllers.
Before you Begin
Before you deploy a 7000 Series branch controller, use the smart config feature on the master controller to a create branch config group. The master controller can push a branch config group configuration to a branch controller when the branch becomes active on the network. The smart config feature is enabled by default. For more information on branch config group settings, refer to
Using Smart Config to create a Branch Config
The parameters of role, country code, and IP address of the master controller are collectively known as the provisioning parameters.
Provisioning Modes for Branch Deployments
The administrator has the choice of several provisioning modes that alter how the branch controller is supplied with its own IP address, role, country code, and branch config group.
During the various provisioning modes, the branch controller is supplied with the IP address of the primary master controller, or, for deployments requiring Layer-3 redundancy, the IP addresses of the primary and backup master controllers. Once the branch controller learns the IP address of the primary master controller, the branch controller contacts the master controller and retrieves its branch config group.
Provisioning a controller means defining the following values for that device: n n n the role of the controller (master or branch) the country code local configuration settings
ArubaOS supports the following provisioning modes for branch controllers: n auto: In this mode, branch controller: l l l obtains its IP address from DHCP obtains its role, country code, and the IP addresses of the primary controller and any defined secondary controller from DHCP Options or a provisioning rule in Activate retrieves its branch config group from the primary master controller
ArubaOS 6.5.3.x
| User Guide Branch Controller Config for Cloud Services Controllers | 233
n n mini-setup: In this mode, the branch controller: l has its role set to branch when mini-setup is initiated l l l obtains its IP address from DHCP is configured through the console with its country code and the IP address of the primary master controller and (optionally) the secondary master controller IP.
retrieves its branch config group from the primary master controller full-setup: In this mode, the branch controller: l is configured with its role set to branch through the console l l l is configured to obtain its IP address through manual configuration of a static IP, DHCP, or PPPoE is configured through the console with its country code and the IP address of the primary master controller and (optionally) the secondary master controller IP retrieves its branch config group from the primary master controller
Automatically Provisioning a Branch Controller
When a factory-default branch controller boots, it starts the auto-provisioning process.
First it will obtain its IP address through DHCP by sending a DHCP discover on the default uplink port. The default uplink port is configured as an access port in VLAN 4094.
Second, it will attempt to retrieve the provisioning parameters from the DHCP options in the DHCP lease it has obtained. If the provisioning parameters could not be obtained from the DHCP options, the branch controller will attempt to retrieve the provisioning parameters from Activate.
If the branch controller is unsuccessful in retrieving the provisioning parameters from Activate, it will retry in 30 seconds. The branch controller keeps trying to retrieve the provisioning parameters from Activate every 30 seconds until it is successful or the administrator interrupts Auto-Provisioning by initiating mini-setup or fullsetup.
To interrupt the auto provisioning process, enter the string mini-setup or full-setup at the initial setup dialog prompt shown below.
Auto-provisioning is in progress. Choose one of the following options to override or debug...
'enable-debug' : Enable auto-provisioning debug logs
'disable-debug': Disable auto-provisioning debug logs
'mini-setup' : Stop auto-provisioning and start mini setup dialog for smart-branch role
'full-setup' : Stop auto-provisioning and start full setup dialog for any role
Enter Option (partial string is acceptable):_
DHCP Options
When the branch controller sends the DHCP discover message to obtain its IP address, it adds a DHCP option
60 b Vendor Class Identifier to that DHCP discover message, where DHCP Option 60 is set to “ArubaMC”.
If the DHCP Offer does have DHCP Option 60 = ArubaMC, the branch controller will accept the DHCP lease and send a DHCP request. It will also look for DHCP Option 43 – Vendor Specific Information in the DHCP Lease. If
DHCP Option 43 is present in the Offer, the branch controller will parse it to learn the provisioning parameters.
The role is not explicitly specified in DHCP Option 43. However, the controller will set its Role to branch if the other provisioning parameters are present in DHCP Option 43.
If the DHCP Offer does not have DHCP Option 60 = ArubaMC, the branch controller will still accept the DHCP lease and send a DHCP request. However, once it is bound to the IP address, it will initiate the next mode of auto-provisioning and query Activate for a provisioning rule.
234 | Branch Controller Config for Cloud Services Controllers ArubaOS 6.5.3.x | User Guide
DHCP Server Provisioning
The branch controller adds ArubaMC as a DHCP option-60 vendor class identifier in its DHCP discovery messages, so the DHCP offer from the server must include ArubaMC as a DHCP option-60 vendor class identifier. The controller gets the master information and country code from the DHCP server, which is configured with the master information corresponding to that identifier. The server may also send vendorspecific information (VSI - option 43) in its response to the controller.
Before you deploy a branch controller using ZTP, configure the DHCP server with the following information: n n
The option-60 vendor class identifier ArubaMC
Option-43 Vendor Specific Information (VSI) with the primary master IP address, the country code, and optionally, a secondary master IP (for deployments requiring Layer-3 redundancy). This VSI must be in one of the following formats, where the IP address of a master controller is in dotted-decimal notation (a.b.c.d) format or a fully qualified domain name format (master.example.com), and the country code contains a valid ISO 3166 country codes, such as US , AU , or IN l
<Master-IP-address> l l
<Master-ip-address>,<Country-code>
<Primary-master-IP-address>, <Country-Code>,<Secondary-master-IP-address>
If the DHCP offer from the server does not include ArubaMC as DHCP option 60, the branch controller will still accept the DHCP Lease and send a DHCP Request. However, once the branch controller is bound to an IP
Address, it will query Activate for additional provisioning information. If the controller does not receive the
ArubaMC identifier through option-60, or if the received IP address is not valid, option-43 is completely discarded and ZTP moves to the next discovery method. For details, refer to
Activate Provisioning on page 235
Activate Provisioning
If the branch controller does not receive its provisioning parameters through DHCP options, it will query
Activate for a provisioning rule that assigns that branch to a master controller.
When a branch controller establishes an HTTPS connection to the Activate server and requests provisioning information, the Activate server authenticates the controller and provides that branch device with provisioning information, including the IP address of its master controller and secondary master, and its country code. If the branch controller is unsuccessful in retrieving the provisioning parameters from Activate, it will retry in 30 seconds. The branch controller will keep trying to retrieve the provisioning parameters from Activate every 30 seconds until it is successful, or the administrator interrupts the auto-provisioning by initiating Mini-Setup or
Full-Setup provisioning.
Before you can use Activate to associate branch controllers with a master controller, you must configure additional device settings on each branch and master controller, create a folder for those branch devices, then assign a provisioning rule to that folder that associates the branch controllers to a specified master. Use the following procedures to configure device details for the master and branch controllers, create folders, and define the provisioning rule.
Upgrading an ArubaOS 6.x Device to ArubaOS 8.x via Activate
Starting with ArubaOS 6.5.2, a factory-default controller running ArubaOS 6.x can use Activate Zero-Touch
Provisioning to upgrade its software to ArubaOS 8.x as part of the provisioning process. If Activate detects that a factory-default branch controller running ArubaOS 6.5.2 or later has been assigned a Managed Device to
Master Controller provisioning rule, Activate will automatically send that branch controller the information it needs to automatically download and upgrade to the latest version of ArubaOS 8.x.
Configuring Device details for a Branch Controller
When you place an order for a controller, that device appears in the Activate Devices list displaying the preconfigured settings for its serial number, MAC address, and software image. Before you can add a branch
ArubaOS 6.5.3.x
| User Guide Branch Controller Config for Cloud Services Controllers | 235
controller to a master controller whitelist, you must use the Activate interface to assign a name to each branch controller, and use the Activate interface to identify a master controller in a branch controller deployment.
Follow the steps below to use Activate to configure branch or master controller device settings
1. Click the Devices icon at the top of the page to display the Devices page.
2. Select a branch or master controller from the Devices list. If the list is very large, you can click the filter icon by any Devices list column heading and choose which entries to display, then select the branch controller from the smaller, filtered list.
3. If the controller will be used as the master controller, select the Master Controller checkbox.
4. In the Device Detail section of the Devices page, enter the following values: n
Device name : (Required) an IP address or fully-qualified domain name for the branch or master controller n n
Full name : (Optional) a user-friendly name for the device
Description : (Optional) a short text string describing the device
5. Click Done to save your settings.
Figure 43 Device Details for a Branch Controller
Creating a New Branch Controller Folder
Associate multiple branch controllers to the same master controller by moving those branch controllers into a single Activate folder.
A folder can contain only one model of branch controller, using the same country code and mapping to the same branch config group. Different folders need to be created for branch controllers of different model types, or that use a different country code or branch config group.
Follow the steps below to add a new folder to the Folders list:
1. Click the Setup icon to display the Setup page.
2. Click the New link in the title bar of the Folders list. The Create a New Folder window appears.
3. Enter the following information for the folder: n n
Name : Name of the new branch controller folder. The folder name must be 100 characters or less, and cannot include the characters ?
, # or & .
Parent : The new folder's parent folder. The new folder will be created under the selected parent.
236 | Branch Controller Config for Cloud Services Controllers ArubaOS 6.5.3.x | User Guide
n
Notes : (Optional) Use this field to add any additional notes about the folder.
4. Click Done to save the new folder.
Configuring the Provisioning Rule
A folder can only have one provisioning profile configured within it and the Provisioning Profile can only reference one branch config group. consequently, it is necessary to create a folder and associate the provisioning rule for each group of branch controllers that share a common branch config group.
Follow the steps below to create a new provisioning rule for the new branch controller folder
1. Click the Setup icon to display the Setup page.
2. In the folders section of the Setup page, select the new branch controller folder.
3. Click the New link in the title bar of the Rules list. The Create a New Rule window appears at the bottom of the page. Enter a value for each required field described in the tables below, then click Done to save your settings.
Figure 44 New Provisioning Rule
Table 62: Provisioning Rule Configuration Settings
Provisioning
Rule Setting
Description
Rule Type Click the Rule Type drop-down list, and select Provisioning Rule .
Parent Folder
Provision Type
Select the folder to which this provisioning rule applies.
Select the Branch to Master Controller rule type.
Primary Controller MAC address of the primary master controller. Activate sends a branch controller whitelist with information about the controllers in this folder to the master controller with this MAC address.
Primary Ctrl IP Enter the IP address of the primary master controller.
ArubaOS 6.5.3.x
| User Guide Branch Controller Config for Cloud Services Controllers | 237
Provisioning
Rule Setting
Backup Controller
Backup Ctrl IP
Country Code
Branch Config
Group
Description
(Optional) MAC address of a backup master controller, for deployments that require Layer-3 redundancy.
(Optional) Enter the IP address of the secondary (backup) master controller.
Select a country code to be assigned to the branch controllers in this folder.
Enter the name of a branch config group to assign that group of branch configuration settings to the branch controllers in this folder.
Moving a Branch Controller to the New Folder
Follow the steps below to assign one or more branch controllers to a folder:
1. Click the Devices icon at the top of the page to display the Devices page.
2. Click the filter icon by any Devices list column heading and choose which entries to display. You can repeat this step and filter the list by multiple criteria types until the Devices list shows only those devices you want to move to a new folder.
3. Click the Move to Folder button at the top of the Devices page. A drop-down window appears, displaying with all folder names.
4. Select the destination folder for the devices.
5. A confirmation window appears, showing the total number of devices that will be moved.
6. Click OK to confirm the change, or click Cancel to cancel the move.
You can also assign an individual device to a new folder by selecting that device from the Devices list and manually changing its parent folder in the Device Details window.
Retrieval of Branch Controller Whitelist from Activate
Activate may be configured to supply the list of branch controllers to the master controller to be added to the whitelist in smart config.
The master controller sends a query to Activate every hour.
The enable mode CLI command “activate sync” may be used to initiate an immediate query to Activate.
When the master controller sends the query to Activate, Activate searches for all provisioning rules of type branch to master controller, that specify the MAC address of this master controller in the primary controller field.
Activate Interface Communication
The branch controller and the master controller interact with the Activate server to receive information about each other. Once the Activate server is properly configured with the appropriate folders and provisioning rules,
Activate automatically manages the relationship between a master controller and all the branch controllers associated with that master.
The master controller regularly contacts the Activate server to get a list of its associated branch controllers.
Branch controllers interact with the Activate server to learn about their role, master controller information, and their regulatory domain. The master controller sends its own information and not branch controller information. Activate reuses information in the AP-information field for controller interactions between master and branch controllers.
The following steps describe the how master controller retrieves the whitelist database from the Activate server.
238 | Branch Controller Config for Cloud Services Controllers ArubaOS 6.5.3.x | User Guide
1. The master controller sends an initial post with a keepalive connection type that includes the following information: n n n n type = Provision update mode = controller a session ID
AP information that includes <serial number>, <mac-address>, <model>
2. Activate responds with the following information: n type = provision update n n an Activate-assigned session ID status n connection = keep alive.
3. The master controller then sends a second POST with ‘close’ connection type with the following information: n n type = provision update, the session ID received from Activate, n n n n
Device information that includes <serial number>, <mac-address>, <model> certificate length signed certificate device certificate
4. Activate then responds with the following information: n type = provision update, n n the same session ID that Activate assigned in the first response status = success or failure n n mode = master the list of branch controllers from the whitelist database, where each list entry contains a <macaddress>,<serial number>,<model>,<mode>,<hostname>, and <config group>
Using Smart Config to create a Branch Config Group
Before you begin to configure a branch config group for individual branch controllers, you must select a master controller to serve as the master for a group of branch controllers on a network. A controller can act either as a master or a branch controller, but not both.
Any change to an active branch controller’s DHCP pool configuration causes the branch controller to reboot.
Only 7200 Series controllers can server as a master controller for a group of branch controllers on a network.
Create and configure a branch config group on a master controller by navigating to the Configuration >
BRANCH > Smart Config section of the master controller WebUI. The Smart Config page contains eight tabs for configuring the branch config group settings.
The BRANCH > Smart Config section of the master controller WebUI is available on the 7200 Series controllers only.
The configuration parameter on each of these tabs are described in the following pages:
ArubaOS 6.5.3.x
| User Guide Branch Controller Config for Cloud Services Controllers | 239
n n n n n n n n
Config Group Management Settings on page 240
System Configuration on page 244
Networking Configuration on page 247
Routing Configuration on page 249
Branch Config Group Summary on page 259
Whitelist Configuration on page 259
Config Group Management Settings
Use this tab to create a new branch config group, select the model of branch controller to which this config group will be applied, and choose either the Static or Dynamic IP address management option for your deployment.
Address Pools
Each branch controller must have a pool of addresses it can dynamically assign to APs or users on each of its
VLANs, and a separate IP address that branch controller uses to create a GRE tunnel to the master controller.
Branch controller VLAN pools and the tunnel pool are defined on the master controller. Branch controller address pools are pushed out to each branch controller when it comes up on the network. If a branch controller is removed from the master, the IP addresses allocated to that branch controller can be reused and reassigned to a new branch controller.
A master controller must have a separate VLAN pool defined for each VLAN used by its branch controller. A
VLAN pool allocates a static, continuous block of multiple IP addresses to each branch controller. The branch controller acts as a DNS proxy server and dynamically assign IP addresses from its allocated pool to each AP or client on the VLAN.
The tunnel pool on a branch controller defines a range of IP addresses that the branch controller uses to create a GRE tunnel within the IPsec tunnel back to the master controller. Unlike VLAN pools, which allocates multiple addresses to each branch controller VLAN, the tunnel DHCP pool assigns a single tunnel IP address to each branch controller.
Static vs Dynamic IP Management
If you choose the dynamic IP management option, you must define one or more IP address pools with a range of sharable addresses. The master controller then divides each IP address pool into unique subnets that can support the required number of clients per branch, and assigns one of these subnet to each branch controller.
If a branch deployment has existing IP addressing that needs to be preserved (for example, the printers at a branch office have static IP addresses), then the branch config group should use static IP addressing. When you create a branch config group that uses static IP addressing, you must export the ArubaOS static IP addressing template from the master controller, define the IP settings for the devices that need a static IP address within that template, then import the template file back into a branch config group.
Starting from ArubaOS 6.5, the ZTP feature is enhanced to support 16 VLANs per branch controller as against just four in the earlier versions of ArubaOS. Except this VLAN enhancement, all the other configurations for the
ZTP feature remain the same as in previous ArubaOS versions.
The Bulk Edit template (in Excel sheet) on the branch controller allows you to specify the static IP assignment for individual branch controller devices. The static IP configuration is maintained in this Bulk Edit CSV file, with each line in the file representing the settings for a specific branch controller device. To support this enhancement, the Bulk Edit Excel sheet (.CSV format) is now expanded to allow for addition of up to 16 VLANs for each branch controller.
240 | Branch Controller Config for Cloud Services Controllers ArubaOS 6.5.3.x | User Guide
The DHCP pools for the VLANs will have settings for the following parameters: pool name, domain name, domain name server, VLAN ID, IP address, mask, and the IP address exclude list.
To create a new branch config group:
1. Navigate to Configuration > Branch > Smart Config and select the Management tab.
2. Click the New button under the branch config group list. You are prompted to enter a name for the new branch config group profile.
3. Click OK .
4. Next, click the Model drop-down list and select the model type of your branch controllers. Each profile can support a single controller model .
5. Click the IP Address Management drop-down list and select the Static or Dynamic option.
6. If you select Dynamic , each branch office controller will get an IP address using DHCP.
7. If you select Static , the WebUI gives you the option to select export and download the static IP address template export-RemoteNode.csv
, or select import and upload a completed static IP address .csv file.
8. Click Apply to save your settings.
The export-RemoteNode.csv
template defines the following settings for each branch controller in the branch config group. Complete the template by adding information for up to 16 IP address pools for each branch controller.
Table 63: Branch Config Group Template Setting
Parameter Description
MAC Address
Description
Time Zone
DST
Pool
Domain
DNS
Vlan
Vlan IP
Mask
Exclude List
IP Helper
MAC address of the controller.
A brief description of the controller
A text string indicating the controller's time zone.
NOTE: This string must contain three or more characters of a supported time zone in any of the formats described in
HongKong or UTC+08 or CCT .
Specify ON or OFF to indicate if the controller's time zone is currently using daylight savings time.
Name of an IP address pool. The template supports up to four different address pools, so different address pools can be used for APs, employees, or guest users.
Name of the branch controller domain.
IP address of the DNS server.
ID of the branch controller VLAN.
IP address of the branch controller
Netmask of the branch controller network.
A comma-separated list of IP addresses or IP address ranges that should not be assigned to clients associated to that branch controller. For example, 15.15.15.11-
15.15.15.20,15.15.15.25,15.15.15.31-15.15.15.40.
DHCP server relay agent IP address.
The new branch config group appears in the Branch Config Group List table. This table displays the branch config group name, validated/not validated status, and reboot status for each branch config group.
ArubaOS 6.5.3.x
| User Guide Branch Controller Config for Cloud Services Controllers | 241
n n
Status : A status of Validated indicates that the branch config group has a complete configuration that can be applied to branch controllers. (For example, a branch config group might have a status of Not Validated if the branch config group does not have a IP address defined for the controller or a controller
VLAN interface.)
Reboot Required : This field indicates that the branch config group includes a configuration change that requires a reboot on the branch controllers using that config group.
The table below describes the time zone formats supported by the export-RemoteNode.csv
template. Each line in the table describes three or more time zone formats for a single location, though only one is required for the template. For example, specify Edinburgh or UTC+00 or UTC or BST .
242 | Branch Controller Config for Cloud Services Controllers ArubaOS 6.5.3.x | User Guide
Table 64: Supported Branch Config Group Time Zone Formats
UTC- Time Zones UTC+ Time Zones n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n
"International-Date-Line-West", "UTC-12",
"American-Samoa", "UTC-11", "SST"
"Hawaii", "UTC-10", "HST"
"Alaska", "UTC-09", "AKST"
"Baja-California", "UTC-08", "PST"
"Pacific-Time", "UTC-08", "PST"
"Arizona", "UTC-07", "MST"
"Chihuahua", "UTC-07", "MST"
"La-Paz", "UTC-07", "MST"
"Mazatlan", "UTC-07", "MST"
"Mountain-Time", "UTC-07", "MST"
"Central-America", "UTC-06"
"Central-Time", "UTC-06", "CST""CDT"
"Guadalajara", "UTC-06", "CST", "CDT"
"Mexico-City", "UTC-06", "CST", "CDT"
"Monterrey", "UTC-06", "CST", "CDT"
"Saskatchewan", "UTC-06", "CST"
"Bogota", "UTC-05", "EST"
"Lima", "UTC-05", "EST"
"Quito", "UTC-05", "EST"
"Eastern-Time", "UTC-05", "EST" "EDT"
"Indiana(East)", "UTC-05", "EST" "EDT"
"Caracas", "UTC-04:30", "VET"
"Asuncion", "UTC-04", "AST" "PYST"
"Atlantic-Time(Canada)", "UTC-04", "AST" "ADT"
"Cuiaba", "UTC-04", "AST","AMST"
"Georgetown", "UTC-04", "AST"
"Manaus", "UTC-04", "AST"
"San-Juan", "UTC-04", "AST"
"Santiago", "UTC-04", "AST", "SAND"
"Newfoundland", "UTC-03:30", "NST", "NDT"
"Brasilia", "UTC-03", "BST" "BRAD"
"Buenos-Aires", "UTC-03", "BST", "ARST"
"Cayenne", "UTC-03", "BST"
"Fortaleza", "UTC-03", "BST"
"Greenland", "UTC-03", "BST", "GRED"
"Montevideo", "UTC-03", "BST," "UYST"
"Salvador", "UTC-03", "BST", "BRST"
"Mid-Atlantic", "UTC-02", "FNT"
"Azores", "UTC-01", "AZOST", "AZOST"
"Cape-Verde-Is", "UTC-01", "CVT"
"Casablanca", "UTC+00", "UTC",
"Coordinated-Universal-Time", "UTC+00", "UTC",
"Dublin", "UTC+00", "UTC", "IST"
"Edinburgh", "UTC+00", "UTC", "BST"
"Lisbon", "UTC+00", "UTC", "WEST"
"London", "UTC+00", "UTC", "BST"
"Monrovia", "UTC+00", "UTC",
"Reykjavik", "UTC+00", "UTC",
"Amsterdam", "UTC+01", "CET", "CEST"
"Berlin", "UTC+01", "CET", "CEST"
"Bern", "UTC+01", "CET", "CEST"
"Rome", "UTC+01", "CET", "CEST"
"Stockholm", "UTC+01", "CET", "CEST"
"Vienna", "UTC+01", "CET", "CEST"
"Belgrade", "UTC+01", "CET", "CEST"
"Bratislava", "UTC+01", "CET", "CEST"
"Budapest", "UTC+01", "CET", "CEST"
"Ljubljana", "UTC+01", "CET", "CEST"
"Prague", "UTC+01", "CET", "CEST" n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n
"Casablanca", "UTC+00", "UTC",
"Coordinated-Universal-Time", "UTC+00", "UTC",
"Dublin", "UTC+00", "UTC", "IST"
"Edinburgh", "UTC+00", "UTC", "BST"
"Lisbon", "UTC+00", "UTC", "WEST"
"London", "UTC+00", "UTC", "BST"
"Monrovia", "UTC+00", "UTC",
"Reykjavik", "UTC+00", "UTC",
"Amsterdam", "UTC+01", "CET", "CEST"
"Berlin", "UTC+01", "CET", "CEST"
"Bern", "UTC+01", "CET", "CEST"
"Rome", "UTC+01", "CET", "CEST"
"Stockholm", "UTC+01", "CET", "CEST"
"Vienna", "UTC+01", "CET", "CEST"
"Belgrade", "UTC+01", "CET", "CEST"
"Bratislava", "UTC+01", "CET", "CEST"
"Budapest", "UTC+01", "CET", "CEST"
"Ljubljana", "UTC+01", "CET", "CEST"
"Prague", "UTC+01", "CET", "CEST"
"Brussels", "UTC+01", "CET", "CEST"
"Copenhagen", "UTC+01", "CET", "CEST"
"Madrid", "UTC+01", "CET", "CEST"
"Paris", "UTC+01", "CET", "CEST"
"Sarajevo", "UTC+01", "CET", "CEST"
"Skopje", "UTC+01", "CET", "CEST"
"Warsaw", "UTC+01", "CET", "CEST"
"Zagreb", "UTC+01", "CET", "CEST"
"West-Central-Africa", "UTC+01", "CET"
"Windhoek", "UTC+01", "CET", "WAST"
"Amman", "UTC+02", "EET", "EEST"
"Athens", "UTC+02", "EET," "EEST"
"Bucharest", "UTC+02", "EET," "EEST"
"Beirut", "UTC+02", "EET", "EEST"
"Cairo", "UTC+02", "EET"
"Damascus", "UTC+02", "EET", "EEST"
"East-Europe", "UTC+02", "EET", "EEST"
"Harare", "UTC+02", "EET"
"Pretoria", "UTC+02", "EET"
"Helsinki", "UTC+02", "EET" "EEST"
"Istanbul", "UTC+02", "EET" "EEST"
"Kyiv", "UTC+02", "EET" "EEST"
"Riga", "UTC+02", "EET" "EEST"
"Sofia", "UTC+02", "EET" "EEST"
"Tallinn", "UTC+02", "EET" "EEST"
"Vilnius", "UTC+02", "EET" "EEST"
"Jerusalem", "UTC+02", "EET" "IST"
"Baghdad", "UTC+03", "MSK"
"Minsk", "UTC+03", "MSK"
"Kuwait", "UTC+03", "MSK"
"Riyadh", "UTC+03", "MSK"
"Nairobi", "UTC+03", "MSK"
"Tehran", "UTC+03:30", "IRST"
"Abu-Dhabi", "UTC+04", "GST"
"Muscat", "UTC+04", "GST"
"Baku", "UTC+04", "GST" "AZST"
"Moscow", "UTC+04", "GST"
"St.Petersburg", "UTC+04", "GST"
"Volgograd", "UTC+04", "GST"
"Port-Louis", "UTC+04", "GST"
"Tbilisi", "UTC+04", "GST"
ArubaOS 6.5.3.x
| User Guide Branch Controller Config for Cloud Services Controllers | 243
Table 64: Supported Branch Config Group Time Zone Formats
UTC- Time Zones UTC+ Time Zones n n n n n n n n n n n n n n n n n n
"Brussels", "UTC+01", "CET", "CEST"
"Copenhagen", "UTC+01", "CET", "CEST"
"Madrid", "UTC+01", "CET", "CEST"
"Paris", "UTC+01", "CET", "CEST"
"Sarajevo", "UTC+01", "CET", "CEST"
"Skopje", "UTC+01", "CET", "CEST"
"Warsaw", "UTC+01", "CET", "CEST"
"Zagreb", "UTC+01", "CET", "CEST"
"West-Central-Africa", "UTC+01", "CET"
"Windhoek", "UTC+01", "CET" "WAST"
"Amman", "UTC+02", "EET" "EEST"
"Athens", "UTC+02", "EET" "EEST"
"Bucharest", "UTC+02", "EET" "EEST"
"Beirut", "UTC+02", "EET" "EEST"
"Cairo", "UTC+02", "EET"
"Damascus", "UTC+02", "EET" "EEST"
"East-Europe", "UTC+02", "EET" "EEST"
"Harare", "UTC+02", "EET" n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n
"Yerevan", "UTC+04", "GST"
"Kabul", "UTC+04:30", "AFT"
"Islamabad" ,"UTC+05", "PKT"
"Karachi" ,"UTC+05", "PKT"
"Tashkent" ,"UTC+05", "PKT"
"Chennai" ,"UTC+05:30", "IST"
"Kolkata" ,"UTC+05:30", "IST"
"Mumbai" ,"UTC+05:30", "IST"
"New-Delhi" ,"UTC+05:30", "IST"
"Sri-Jayawardenepura", "UTC+05:30", "IST"
"Kathmandu", "UTC+05:45", "NPT"
"Astana", "UTC+06", "BTT"
"Dhaka", "UTC+06", "BTT"
"Ekaterinburg", "UTC+06", "BTT"
"Yangon", "UTC+06:30", "MMT"
"Bangkok", "UTC+07", "THA"
"Hanoi", "UTC+07", "THA"
"Jakarta", "UTC+07", "THA"
"Novosibirsk", "UTC+07", "THA"
"Beijing" ,"UTC+08", "CCT"
"Chongqing" ,"UTC+08", "CCT"
"Hong Kong" ,"UTC+08", "CCT"
"Krasnoyarsk" ,"UTC+08", "CCT"
"Kuala-Lumpur", "UTC+08", "CCT"
"Perth", "UTC+08", "CCT"
"Singapore", "UTC+08", "CCT"
"Taipei", "UTC+08", "CCT"
"Urumqi" ,"UTC+08", "CCT"
"Ulaanbaatar", "UTC+08", "CCT"
"Irkutsk", "UTC+09", "JST"
"Osaka", "UTC+09", "JST"
"Sapporo", "UTC+09", "JST"
"Tokyo", "UTC+09", "JST"
"Seoul", "UTC+09", "JST"
"Adelaide", "UTC+09:30", "ACST" "CST"
"Darwin", "UTC+09:30", "ACST"
"Brisbane", "UTC+10", "AEST"
"Canberra","UTC+10", "AEST"
"Melbourne","UTC+10", "AEST"
"Sydney","UTC+10", "AEST"
"Guam", "UTC+10", "AEST"
"Port-Moresby", "UTC+10",
"Hobart" ,"UTC+10", "AEST"
"Yakutsk", "UTC+10", "AEST"
"Solomon-Is.", "UTC+11", "NST"
"New-Caledonia", "UTC+11", "NST"
"Vladivostok", "UTC+11", "NST"
"Auckland", "UTC+12", "NZT"
"Wellington", "UTC+12", "NZT"
"Fiji", "UTC+12", "NZT"
"Magadan", "UTC+12"
"Nukualofa", "UTC+13"
"Samoa", "UTC+13"
System Configuration
Configure general system settings for the branch controllers in a branch config group by navigating to
Configuration > Branch > Smart Config and selecting the System tab. The settings on the System tab are described in the table below.
244 | Branch Controller Config for Cloud Services Controllers ArubaOS 6.5.3.x | User Guide
Figure 45 Branch Config Group System Settings
Parameter Description
General
System Contact An alphanumeric string that specifies the name of the system contact for the controller
The name of a system admin user Admin User
Admin Password The password for the system admin user
Servers
AirWave Server (Optional) IP address of the AirWave server, if the branch office controller is managed or monitored by AirWave.
Syslog Server (Optional) IP address of an external syslog server. You will define syslog facility levels in subsequent configuration fields on this page.
IP address of the domain server.
Domain Name
Server
Domain name (Optional) Default domain name to be used by the branch controllers. The branch controllers use the default domain name to complete hostnames that do not contain domain names.
(Optional) Certificate to be used for captive-portal authentication.
Captive Portal
Server
Certificate
Time Zone
RADIUS interface source
VLAN
Advanced Settings
Time zone for the branch office controller. Click the DST checkbox if the selected timezone is currently using daylight-savings time.
This field identifies the interface for outgoing RADIUS packets. The IP address of the specified interface is included in the IP header of RADIUS packets.
Master L3
Redundancy
Switchover
Timeout
If the branch controller is configured with a primary and a secondary master controller, this switchover period defines the number of minutes that a branch controller will wait before switching its master controller from an unreachable primary controller to the backup controller.
n n
Range: 15 - 60 minutes
Default: 15 minutes
NOTE: This timeout period does not apply if a user manually switches a branch controller from a primary to a secondary master controller by clicking the Switchover link on the Network >
Controller > System settings page of the branch controller WebUI.
firewall-visibility (Optional) Enable or disable the firewall visibility feature. For more information, see
AppRF
URL Filtering
(Optional) Enable or disable the AppRF feature. For more information, see
.
(Optional) Enable Web Content Classification. For more information, see
.
Mark
Management
Frames
(Optional) Enable or disable the marking of IPsec mangement frames. This option is disabled by default.
ArubaOS 6.5.3.x
| User Guide Branch Controller Config for Cloud Services Controllers | 245
Parameter Description
Jumbo
Management
Frames
Skype4B Listen
Port
AirGroup
(Optional) Enable or disable jumbo Ethernet frames on branch office controller ports. If you enable this feature, you must define the Maximum Transmission Unit (MTU) for these frames.
The supported range is 1789 to 9612 bytes.
(Optional) ArubaOS provides value-added services such as prioritization of Lync/Skype for
Business sessions, call quality metrics, and visibility by implementing Lync/Skype for Business
Application Layer Gateway (ALG). Use this parameter to define the Lync/Skype for Business listening port. For more information, see
Configuring the Lync/Skype for Business Listening Port on page 958
.
(Optional) Enable or disable the AirGroup feature on the branch office controller. For more information on AirGroup, see
.
AirGroup MDNS (Optional) Enable or disable support for multicast Domain Name System (mDNS) service records. For more information, see
Zero Configuration Networking on page 1004
.
AirGroup DLNA (Optional) Enable or disable support for DLNA (Digital Living Network Alliance); a network standard that is derived from UPnP (Universal Plug and Play) in addition to the mDNS protocol.
For more information, see
Zero Configuration Networking on page 1004
.
Syslog Facility Levels
Network
Security
System
User
Wireless
(Optional) Click the syslog facility levels drop-down lists to change the severity level at which the different types of syslog messages are logged. By default, all message types are logged at the warnings level. For more information on syslog levels, refer to the ArubaOS Syslog Messages
Guide.
Revocation CheckPoints
CA Cert (Optional) The branch controller can act as an OCSP client and issue OCSP queries to remote
OCSP responders located on the intranet or Internet. If you have uploaded an OCSP responder certificate to the master controller, click Edit to modify the certificates used to sign OCSP for the revocation check point. For more information on configuring a controller as an OCSP client, see
Configuring the Controller as an OCSP Client on page 305
.
SNMP
246 | Branch Controller Config for Cloud Services Controllers ArubaOS 6.5.3.x | User Guide
Parameter
Community
Strings for
SNMPv1 and
SNMPv2
Trap Receiver
Description
Enter community string to authenticate SNMPv1 and SNMPv2 requests. For more information on SNMP settings, see
.
SNMPv3 Users
Enter host information about a SNMP trap receiver that can receive and interpret the traps sent by the controller. Click New , enter the following types of trap information, then click Add .
n n
IP address: Trap receiver IP address
SNMP version: SNMPv1,SNMPv 2c, or SNMPv3.
n n n
Security Name: SNMP security name string
Engine ID: Engine ID of SNMP server in hexadecimal format. (SNMPv3 only)
UDP Port: UDP port on which the trap receiver listens for traps. The default is the UDP port number 162.
n n
Type: Specify whether the controller can send inform messages to the trap receiver to acknowledge traps. (SNMPv2c or SNMPv3 only)
Retry: If the controller is configured to send inform messages, this field specifies the number of times the controller will retry sending inform messages to the trap receiver before giving up.
n Timeout: Estimated round trip time to the trap receiver, in seconds.
For more information on SNMP settings, see
.
Information about SNMPv3 users. Click New to open a message box that allows you to enter the following information types, then click Add .
n n
User: A string representing the name of the SNMP user.
Authentication Protocol: Select either MD5 or SHA authentication n n
Authentication Password: Authentication key for use with the SHA authentication protocol.
Privacy Protocol: Select either AES or DES encryption.
n Privacy Password: Privacy key for encrypted messages.
For more information on SNMP settings, see
.
Networking Configuration
Configure user and uplink VLANs for the branch controllers in a branch config group, map named VLANs to one ore more VLAN IDs, define branch config group port settings and tunnels, and enable or disable the Spanning
Tree Protocol (STP) by navigating to Configuration>Branch>Smart Config and selecting the Networking tab.
Use the configuration settings on the Networking tab to configure the PortFast and BPDU Guard features for a branch config group. For complete details on these features, see
PortFast and BPDU Guard on page 260 .
The settings on the Networking tab are described in the table below.
Figure 46 Branch Controller Networking Settings.
Parameter Description
User VLANs
VLAN ID
Description
Identifier for the VLAN.
Text string describing the VLAN.
ArubaOS 6.5.3.x
| User Guide Branch Controller Config for Cloud Services Controllers | 247
Parameter
NAT Inside
Description
Click this checkbox to enable source NAT for this VLAN. When applied, NAT is applied to both outbound and non-public, inter-VLAN traffic, with the desired IP address of the VLAN interface as the source address.
Nat Outside Starting in ArubaOS 6.4.4.0, click this checkbox to enable destination NAT for this VLAN. With this option, NAT is applied only to outbound traffic with the IP address of the VLAN interface as the source address. Non-public, inter-VLAN traffic which is routed locally remains unaffected.
BCMC Optimization Click this checkbox to effectively prevent flooding of BCMC traffic on all VLAN member ports.
This option ensures controlled flooding of BCMC traffic without compromising the client connectivity.
Operstate Click this checkbox to select the operational state for the VLAN ( Up or Down ).
IP Address Select one of the following parameters from the drop-down list to allow a VLAN to get an
IP address using DHCP: n n dhcp-client - The VLAN to select the IP address from the DHCP server, if this option is selected.
dhcp-pool - A static IP address is assigned to the vlan based on the configured dhcp pools in the Routing tab, if this option is selected.
Named VLAN Mapping
Name Name assigned to an individual VLAN or group of VLANs (a VLAN pool).
VLAN Specify one or more VLAN IDs to associate the VLAN ID(s) to the VLAN name. For more information on configuring named VLANs, see
Configuring VLANs on page 105 .
Uplink VLANs
VLAN ID
Priority
Description
Operstate
IP Address
Ports
Specify the VLAN ID of the wired uplink network connection used by the branch controller.
Specify the priority of the VLAN by selecting a value from 101-255.
(Optional) text string used to describe the VLAN
Identify the VLAN operational state as UP or DOWN.
Specify whether the VLAN will receive its IP address using DHCP or PPPoE.
248 | Branch Controller Config for Cloud Services Controllers ArubaOS 6.5.3.x | User Guide
Parameter n n n n n n n n n n n
Port Settings:
Port Enable
Enable
Description
Trusted
Speed/Duplex
Mode
Native VLAN
Trunk/Access
VLAN
PortFast
BPDU Guard
Tunnels
Description
Click Edit to edit the settings for an individual interface port, or to apply an access control list
(ACL) to inbound traffic, outbound traffic, or session traffic on a selected VLAN.
NOTE: For complete details on the PortFast and BPDU Guard features, see
. For more information on configuring the port settings for branch controllers in a branch config group, see
and
n n n n n n n
Tunnel settings:
Tunnel ID
Source IP
Destination IP
Mode
Keepalive
MTU
Trusted
ArubaOS supports generic routing encapsulation (GRE) tunnels between the branch controller and APs. To define tunnel settings for the branch controllers using this branch config group, click
Spanning Tree Configuration
New , select your tunnel settings, then click vidual GRE tunnel configuration parameters, see
Add . For more information on indi-
Configuring GRE Tunnels on page 114 .
Spanning Tree
Enabled
Spanning Tree Protocol (STP) can ensure a single active path between any two network nodes, thus avoiding bridge loops. Select this checkbox to enable spanning tree if you are employing STP in your network.
Routing Configuration
Use this tab to configure static routes and DHCP pools, policy-based routing, and uplink routing using nexthop lists.
Configuring Routing for a Branch Config Group
To configure the different routing settings for a branch config group, select the Routing sub-tab to configure the controller IP and NAS-IP VLANs, static routes and DHCP pools, then optionally click the PBR sub tab to configure policy-based routing (PBR) settings such as nexthop lists and PBR rules and targets.
Controller IP
A valid branch config group requires a VLAN to be assigned to the controller IP address. To assign an VLAN to a controller IP:
1. Navigate to Configuration>Branch>Smart Config>Routing and select the Routing sub-tab.
2. Click the Controller-IP drop-down list and select a VLAN ID from the list of uplink VLANs configured on the
Branch>Smart Config>Networking tab.
3. Click Apply .
NAS IP
ArubaOS 6.5.x allows you configure a branch controller NAS IP with a VLAN. This setting is optional; if the NAS
IP VLAN is not configured for branch controllers, the controller IP defined in the RADIUS server configuration
ArubaOS 6.5.3.x
| User Guide Branch Controller Config for Cloud Services Controllers | 249
address is used as the NAS IP.
To assign an VLAN to a NAS IP:
1. Navigate to Configuration>Branch>Smart Config>Routing and select the Routing sub-tab.
2. Click the Override NAS-IP drop-down list and select a VLAN ID from the list of uplink VLANs configured on the Branch>Smart Config>Networking tab.
3. Click Apply .
Static Routes
A static route allows the branch controller to connect to an upstream router or switch instead of the default gateway. To define a static route for your branch config group:
1. Select the Routing sub-tab.
2. Click New to open a pop-up window that allows you to configure the following static route settings:
Table 65: Branch Controller Static Route Settings
Parameter Description
Destination IP
Destination Mask
NextHop
IPsec
Destination IP addresses in dotted decimal format.
Destination netmask, in dotted decimal format.
The IP address of the forwarding router in dotted decimal format.
To use a static IPsec route, map click the IPsec drop-down list and select a static
IPsec route map, or click New and enter the name of a new IPsec route map.
DHCP Pools
Client devices within a branch office will obtain their IP addresses from a DHCP pool.
1. Select the Routing sub-tab.
2. Click New to open a pop-up window that allows you to configure the following DHCP pool settings:
Table 66: Branch Controller DHCP Pool Settings
Parameter Description
VLAN
Pool Name
Domain Name
DNS Server
IP Address Range
Lease
Option
VLAN ID. Click the VLAN drop-down list and select a VLAN ID from the list of uplink
VLANs configured on the Branch>Smart Config>Networking tab.
Name that identifies this VLAN pool.
Domain name of the DNS server.
IP address of the DNS server.
IP addresses at the start and end of the branch controller’s address range, in dotted-decimal format and the netmask per branch. The WebUI converts the netmask per branch to hosts count.
Example: If the netmask per branch is /27, WebUI calculates the hosts count as 32.
Similarly, if netmask per branch is /24, the WebUI calculates the hosts count as 256.
Lease time for addresses in the DHCP pool. If unconfigured, the default value is 12 hours.
Use this field assign the client to a VLAN based upon the DHCP signature ID.
250 | Branch Controller Config for Cloud Services Controllers ArubaOS 6.5.3.x | User Guide
Next-Hop Device lists
If the controller uses policy-based routing to forward packets to a next hop device, a next-hop list ensures that if the primary next-hop device becomes unreachable, the packets matching the policy can still reach their destination. For more information on nexthop devices, see
Routing Configuration on page 249 .
To define a next-hop list:
1. Navigate to Configuration>Branch>Smart Config>Routing and select the PBR sub-tab.
2. Click the Add button below the Nexthop Configuration table to open a pop-up window that allows you to configure the following next-hop settings:
Table 67: Branch Controller Next-Hop Settings
Parameter Description
Nexthop-list name Name for the new nexthop list.
Nexthop IP / DHCP
Preemptive-Failover
IP address of the nexthop device or the VLAN ID of the VLAN used by the nexthop device. If the VLAN gets an IP address using DHCP, and the default gateway is determined by the VLAN interface, the gateway IP is used as the nexthop IP address.
When you click Add to define a NextHop IP or DHCP value, a pop-up list appears and field requires you to select either the IP or DHCP option.
n n
IP: In the Nexthop Value and Priority fields, enter the IP address and priority of the nexthop device
DHCP: In the Nexthop Value and Priority fields select the VLAN and priority of the nexthop device.
If preemptive failover is disabled and the highest-priority device on the nexthop list is disabled, the new primary nexthop device remains the primary even when the original device comes back online.
PBR Rules
A policy-based routing (PBR) rule is an ACL that can forward traffic as normal, or route traffic over a VPN tunnel specified by an IPsec map, routed to a nexthop router on a nexthop list, or redirected over an L3 GRE tunnel or tunnel group.
If you modify an existing ACL by adding a new rule with the same position as an existing rule, the previously existing rule will be overwritten. The Smart Config section of the ArubaOS WebUI does not prevent you from creating duplicate rules in different positions, though this is not allowed when creating ACLs using the
Configuration>Security>Firewall Policies section of the ArubaOS WebUI, or when using the ip access-list commands in the ArubaOS command-line interface.
To associate a policy based routing rule with the branch config group,
1. Navigate to Configuration>Branch>Smart Config>Routing , and select the PBR subtab .
2. Click the Route ACL name drop-down list. Select an existing route ACL, or click New to define a new ACL.
3. If you selected New in the previous step, enter a name for the new ACL, then click Add . Next, you must define the rules for the new ACL.
4. Click the Add button below the PBR rules list, and define the following values:
ArubaOS 6.5.3.x
| User Guide Branch Controller Config for Cloud Services Controllers | 251
Table 68: Policy Based Routing ACL Rule Parameters
Field Description
IP version
Source
(required)
Specifies whether the policy applies to IPv4 or IPv6 traffic.
Source of the traffic, which can be one of the following: n n any: Acts as a wildcard and applies to any source address.
user: This refers to traffic from the wireless client.
n n n host: This refers to traffic from a specific host. When this option is chosen, you must configure the IP address of the host.
network: This refers to a traffic that has a source IP from a subnet of IP addresses. When this option is chosen, you must configure the IP address and network mask of the subnet.
alias: This refers to using an alias for a host or network. You configure the alias by navigating to the Configuration > Advanced Services > Stateful Firewall > Destination page.
Destination of the traffic, which can be configured in the same manner as Source.
Destination
(required)
Service
(required)
Action
(required)
Position
Type of traffic, which can be one of the following: n any: This option specifies that this rule applies to any type of traffic.
n application: For session and route policies on a 7000 Series controller, you can create a rule that applies to a specific application type. Click the Application drop-down list and select an application type.
n n application category: For session and route policies on a 7000 Series controller, you can create a rule that applies to a specific application category. Click the Application Category drop-down list and select a category type.
protocol: Using this option, you specify a different layer 4 protocol (other than TCP/UDP) by configuring the IP protocol value.
n n n service: Using this option, you use one of the pre-defined services (common protocols such as
HTTPS, HTTP, and others) as the protocol to match for the rule to be applied. You can also specify a network service that you have manually configured. For details, see
.
tcp: A range of TCP port(s) that must be used by the traffic in order for the rule to be applied.
udp: A range of UDP port(s) hat must be used by the traffic in order for the rule to be applied.
The action that you want the controller to perform on a packet that matches the specified criteria.
This can be one of the following: n Forward Regularly: Packets are forwarded to their next destination without any changes.
n n n n
Forward to ipsec-map: Packets are forwarded through an IPsec tunnel defined by the specified
IPsec map. You must specify the position of the forwarding or routing rule. (1 is first, default is last)
Forward to next-hop-list: packets are forwarded to the highest priority active device on the selected next hop list. You must also specify the position of the forwarding or routing rule (1 is first, default is last). For more information on next-hop lists, see
Forward to tunnel: Packets are forwarded through the tunnel with the specified tunnel ID. You must also specify the position of the forwarding or routing rule (1 is first, default is last). For more information on GRE tunnels, see
Configuring GRE Tunnels on page 114
.
Forward to tunnel group: Packets are forwarded through the active tunnel in a GRE tunnel group. You must also specify the position of the forwarding or routing rule (1 is first, default is last). For more information on tunnel groups, see
Configuring GRE Tunnel Groups on page 123 .
(Optional) Define a position for the rule in the ACL. Rules processed according to their position numbers, and new Rules are added at the end of an ACL by default. A position of 1 puts the rule at the top of the list.
Targets for PBR Rules
A Policy Based Routing (PBR) rule does not become active until it is applied to a VLAN interface or user role. To define a target for a PBR rule:
252 | Branch Controller Config for Cloud Services Controllers ArubaOS 6.5.3.x | User Guide
1. Select the PBR sub-tab.
2. Click the Add button below the Target table.
3. Click the PBR Rule Name drop-down list and select the rule to be applied to the target.
4. Select the target type: VLAN or User Role .
n n
If you selected the VLAN type, click the Target drop-down list and select a VLAN ID to apply the rule to the VLAN interface's inbound traffic.
If you selected the User Role type, click the Target drop-down list and select a user role. The rule will be applied to traffic from clients with the selected user role.
5. Click Done .
6. Click Apply .
VPN Configuration
Configure IPsec crypto maps and DTP settings for the branch controllers in a branch config group by navigating to Configuration>Branch>Smart Config and selecting the VPN tab. The settings on the VPN tab are described in the table below.
Table 69: Branch Config Group VPN Settings
Parameter Description Description
IPSec maps
Name
Name of the IPsec map.
Disable IPsec map Click this checkbox to temporarily disable a configured IPsec map without deleting it from the branch config group.
Priority
Source Network Type
Source Network
Source Network VLAN
Source Subnet Mask
Destination Network
Priority level for the IPsec map, from 1-9998. An IPsec map with a smaller priority number will take precedence over a map with a greater priority number.
Select one of the supported source network identifier types: n IP Address : Identify the source network (the local network connected to the branch controller) using an IP address.
n n
VLAN : Use a VLAN ID as the source network. When the configuration is pushed to the branch, the IP address range assigned for that VLAN in that branch is used during IKE negotiation.
Any : Use any as the source network.
If you selected the IP Address source network type, enter the IP address the source network in the Source Network field
If you selected VLAN as the source network type, click the VLAN drop-down list and select the VLAN ID of the source network VLAN.
Subnet mask for the source network (the local network connected to the branch controller).
Select one of the supported destination network identifier types: n n
IP Address : Identify the destination network (the remote network to which the local branch network communicates).
Any : Use any as the destination network.
ArubaOS 6.5.3.x
| User Guide Branch Controller Config for Cloud Services Controllers | 253
Parameter Description Description
Destination Subnet Mask
Subnet mask for the source network (the remote network to which the local branch network communicates).
Peer Gateway Type
Peer Gateway
Peer Certificate Subject
Name
Select one of the supported peer gateway types: n IP Address : Select this option to identify the remote end point of the VPN tunnel using an IP address.
n
FQDN : This option allows you to use same FQDN across different branches. The FQDN resolves to different IP addresses for each branch, based on its local DNS setting.
Define the peer gateway.
If you selected IP Address for the Peer Gateway Type option, enter the appropriate IP address: n n
If you are configuring an IPsec map for a dynamically addressed remote peer, give the peer gateway a default value of 0.0.0.0
.
If you are configuring an IPsec map for a statically addressed remote peer, enter the IP address of the interface used by the remote peer to connect to the L3 network .
f you selected FQDN for the Peer Gateway Type option, enter the fully qualified domain name for the remote peer.
If you use IKEv2 to establish a site-to-site VPN for a statically addressed remote peer, identify the peer device by entering its certificate subject name in the Peer Certificate Subject Name field.
NOTE: This field is not enabled until you select the Certificate option for authentication at the bottom of the VPN tab. To identify a peer certificate's subject name, issue the show crypto-local pki servercert <certname> subject command in the master controller command-line interface.
Configures the lifetime for the security association (SA), in seconds.
Security Association
Lifetime (seconds)
Security Association
Lifetime (Kilobites)
Specifies the amount of traffic (in kilobytes) that can pass between IPSec peers in the local and remote networks before the security association expires.
Version Click the drop-down list and select None (to create an IPsec map that doesn't use IKE), IKEv1 or IKEv2 .
IKE policies
Factory Certificate
Authentication
VLAN
Select a predefined IKE policy, or a policy manually defined on the Configuration > Advanced > VPN Services > IPsec page of the master con-
troller WebUI. For more information on creating IKE policies, see Configuring
.
Select this option to use factory-installed TPM (Trusted Platform Module) certificates for VPN authentication.
Select the VLAN containing the interface of the local branch controller that connects to the Layer-3 network. This setting determines the source IP address used to initiate IKE. If you select None , the default is the VLAN of the controller’s IP address (either the VLAN where the loopback IP is configured, or VLAN 1 if no loopback IP is configured).
254 | Branch Controller Config for Cloud Services Controllers ArubaOS 6.5.3.x | User Guide
Parameter Description Description
PFS
Pre-Connect
Trusted Tunnel
Enforce NATT
If you enable Perfect Forward Secrecy (PFS) mode, new session keys are not derived from previously used session keys. Therefore, if a key is compromised, that compromised key does not affect any previous session keys. PFS mode is disabled by default. To enable this feature, click the PFS drop-down list and select one of the following Perfect Forward Secrecy modes: n n group1 : 768-bit Diffie–Hellman prime modulus group.
group2 : 1024-bit Diffie–Hellman prime modulus group.
n n n group 14 : 2048-bit Diffie–Hellman prime modulus group.
group19 : 256-bit random Diffie–Hellman ECP modulus group.
group20 : 384-bit random Diffie–Hellman ECP modulus group.
Select Pre-Connect to establish the VPN connection, even if there is no traffic being sent from the local network. If you do not select this, the VPN connection is established only when traffic is sent from the local network to the remote network.
Select Trusted Tunnel if traffic between the networks is trusted. If you do not select this, traffic between the networks is untrusted.
Select the Enforce NATT checkbox to enforce IKE and IPSEC NAT Traversal
(NAT-T) on UDP port 4500. This option is disabled by default.
Transform Sets A transform set defines a specific encryption and authentication type used by the dynamic peer. Click the Transform Set drop-down list to select a predefined transform set or a transform set that was manually defined using the Configuration>Advanced Services > VPN Services > Advanced page of the master controller WebUI, then click the arrow button by the dropdown list to add that transform set to the IPsec map.
Dynamically Addressed
Peer
Pre-shared Key
Certificate
Select either the Pre-shared Key or Certificate options to define security options for a dynamically address peer.
For pre-shared key authentication, select Pre-Shared Key , then enter a shared secret in the IKE Shared Secret and Verify IKE Shared Secret fields. This authentication type is generally required in IPsec maps for a VPN with dynamically addressed peers, but can also be used for a static site-tosite VPN.
For certificate authentication, select Certificate , then click the Server Certificate and CA certificate drop-down lists to select certificates previously imported into the controller.
See
for more information on managing certificates.
DPD Parameters
Enable DPD The DPD Parameters checkbox on the VPN tab enables or disables Dead
Peer Detection. When enabled, DPD uses IPsec traffic patterns to minimize the number of IKE messages required to determine the liveliness of an IKE peer. After a dead peer is detected, the branch controller tears down the
IPsec session. Once the network path or other failure condition has been corrected, a new IPsec session is automatically re-established.
ArubaOS 6.5.3.x
| User Guide Branch Controller Config for Cloud Services Controllers | 255
Table 70: Default IKE Policy Setting
Policy Name
Policy
Number
IKE
Version
Encryption
Algorithm
Default protection suite
10001
Default RAP
Certificate protection suite
10002
Default RAP
PSK protection suite
10003
Default RAP
IKEv2 RSA protection suite
1004
10005 Default Cluster
PSK protection suite
Default IKEv2
RSA protection suite
Default IKEv2
PSK protection suite
1006
10007
Default Suite-B
128bit ECDSA protection suite
10008
IKEv1
IKEv1
IKEv2
IKEv1
IKEv2
IKEv2
IKEv2
3DES-168
AES -256
AES -256
AES -256
AES -256
AES - 128
AES - 128
AES - 128
Hash
Algorithm
Authentica
-tion
Method
SHA 160
SHA 160
Pre-Shared
Key
RSA
Signature
PRF
Method
Diffie-
Hellman
Group
N/A
N/A
2 (1024 bit)
2 (1024 bit)
SHA 160
SSHA160
SHA160
SHA 96
SHA 96
SHA 256-
128
Pre-Shared
Key
RSA
Signature
Pre-Shared
Key
RSA
Signature
Pre-shared key
ECDSA-256
Signature
N/A hmacsha1
Pre-
Shared
Key hmacsha1 hmacsha1
2 (1024 bit)
2 (1024 bit)
2 (1024 bit)
2 (1024 bit)
2 (1024 bit)
Default Suite-B
256 bit ECDSA protection suite
10009
Default RAP
IKEv2 RSA protection suite
10012
IKEv2
IKEv2
AES -256
AES -256
SHA 384-
192
SSHA160
ECDSA-384
Signature
RSA
Signature hmacsha2-256
Random
ECP
Group
(256 bit) hmacsha2-384
Random
ECP
Group
(384 bit) hmacsha1
14 2048bit group
WAN Configuration
Use the WAN tab to define settings for the features described below. For additional information on each of these features, refer also to the following sections of this document: n n n n n n
WAN Failure (Authentication) Survivability on page 220
Branch Controller Routing Features on page 231
WAN Optimization through IP Payload Compression on page 226
Interface Bandwidth Contracts on page 227
Branch Integration with a Palo Alto Networks (PAN) Portal on page 228
256 | Branch Controller Config for Cloud Services Controllers ArubaOS 6.5.3.x | User Guide
To configure WAN survivability, Health Check, Policy-Based Routing, WAN Optimization, Bandwidth
Management and PAN portal settings for the branch controllers in a branch config group ,navigate to
Configuration>Branch>Smart Config and select the WAN tab. The settings on the WAN tab are described in the table below.
Table 71: Branch Config Group WAN Setting
Parameter Description
WAN Failure Survivability
Enable Auth-Survivability
Authentication Server
Certificate
Local Cache Lifetime (hrs)
CA Certificate Assigned for
Auth Survivability
This parameter controls whether to use the Survival Server when no other authentication servers in the server group are in-service.
This parameter also controls whether to store the user access credential in the
Survival Server when it is authenticated by an external RADIUS or LDAP server in the server group. Authentication Survivability is enabled or disabled at each controller. This parameter is disabled by default.
NOTE: Authentication Survivability will not activate if Authentication Server Dead
Time is configured as 0. For more information on configuring Authentication
Server Dead Time, see
Configuring Authentication Timers on page 212
.
This parameter allows you to view the name of the server certificate used by the local Survival Server. The local Survival Server is provided with a default server certificate from ArubaOS . The customer server certificate must be imported into the controller first, and then you can assign the server certificate to the local
Survival Server.
This parameter specifies the lifetime in hours for the cached access credential in the local Survival Server. When the specified cache-lifetime expires, the cached access credential is deleted from the controller.
Configured authentication servers are put into the out-of-service (OOS) state when authentication requests time out. The wireless controller picks the next server from the server group when the previous server times out or fails.
When there are no more servers available from the server group, the local
Survival Server processes the authentication request. When the client is authenticated with the local Survival Server, the previously stored Key Reply attributes are included in the RADIUS response.
The Cache Lifetime range is from 1 to 168 hours. The default is 24 hours.
Select the certificate to be used for client authentication.
WAN Health Check
Health-Check
WAN
Probe Mode
Probe Interval (sec)
Select the health-check option to use ping-probes to measure WAN availability and latency on selected uplinks. Based upon the results of this health-check information, the controller can continue to use its primary uplink, or failover to a backup link.
Select the WAN tab to define ping probe settings for the health-check feature
Click the Probe Mode drop-down list and select ping or udp to enable ip probes of the selected type.
The Probe Interval field specifies the probe interval, in seconds. The WAN health-check feature sends the number of probes defined by the Packet Burst per Probe parameter during each probe interval. To change the default interval of 10 seconds, enter a new value into this field.
ArubaOS 6.5.3.x
| User Guide Branch Controller Config for Cloud Services Controllers | 257
Table 71: Branch Config Group WAN Setting
Parameter Description
Packet Burst Per Probe
Probe Retries
The Pocket Burst per Probe field specifies the number of probes to be sent during the probe interval. To change the default value of 5 probes, enter a new value into this field.
The number of times the controller will attempt to resend a probe.
IP/FQDN of remote host
Jitter Measurement
PBR
Probe Mode
IP address or Fully Qualified Domain Name (FQDN) of the remote host to which the ping probes are sent.
Jitter is a variation in the delay of received packets, which can be worsened by network congestion, improper queueing and configuration errors. The WAN health-check feature measures jitter on the connection to the remote host by sending and measuring packets at fixed intervals.
Select the PBR tab to define ping probe settings for policy-based routing.
Click the Probe Mode drop-down list and select ping to enable ip probes.
Probe Interval (sec)
Packet Burst Per Probe
Probe Retries
The Probe Interval field specifies the probe interval, in seconds. The WAN health-check feature sends the number of probes defined by the Packet Burst per Probe parameter during each probe interval. To change the default interval of 10 seconds, enter a new value into this field.
The Pocket Burst per Probe field specifies the number of probes to be sent during the probe interval. To change the default value of 5 probes, enter a new value into this field.
The number of times the controller will attempt to resend a probe.
WAN Optimization
Compression The Compression/Decompression Engine feature is enabled by default. However, the packets are compressed only if the IP Payload Compression Protocol (IPComp) is successfully negotiated via the Internet Key Exchange (IKE) protocol.
BW Management
Uplink
Service Type
Bandwidth Contract
Select an interface uplink to which you will apply the bandwidth contract.
n n n
Select one of the available service types for this bandwidth contract: n None: The contract applies to all upstream or downstream traffic on the interface.
Application: The contract applies to a specific application.
Category: The contract applies to all applications within a category type.
Exclude: If a bandwidth contract is applied to an entire interface or category of applications, you can create a bandwidth contract that excludes a single application or application category from that contract.
If you chose the None, Application or Category option in the Service Type field, select the name of the bandwidth contract to be applied to the interface.
258 | Branch Controller Config for Cloud Services Controllers ArubaOS 6.5.3.x | User Guide
Table 71: Branch Config Group WAN Setting
Parameter Description
Application
If you chose the Application option in the Service Type field, select the application to which the bandwidth policy will be applied.
Category If you chose the Category option in the Service Type field, select the application category to which the bandwidth contract is applied.
Bandwidth Direction
Apply the bandwidth contract to upstream or downstream traffic.
PAN Portal
Portal IP
Trusted Certificate
User Name
Password
The IP address or fully qualified domain name (FQDN) of the portal.
Specify the name of the self-signed or external certification authority (CA) certificate to establish an SSL connection to the portal.
Username to authenticate to the Palo Alto Networks portal.
Password to authenticate to the Palo Alto Networks portal.
Branch Config Group Summary
The Summary tab on the Configuration>Branch>Smart Config page displays a summary of the branch config group configuration created using the Smart Config WebUI, and a summary of the settings on a specific branch controller.
To view a summary of the branch config group settings:
1. Navigate to Configuration>Branch>Smart Config>Summary .
2. Select the Profile Summary subtab.
3. Click the Profile drop-down list and select the branch config group whose configuration settings you want to review.
To view a summary of the settings specific to an individual branch controller:
1. Navigate to Configuration>Branch>Smart Config>Summary .
2. Select the BOC Summary subtab.
3. Click the Profile drop-down list and select the MAC address of the branch controller whose configuration settings you want to review.
Whitelist Configuration
The branch controller whitelist database links the MAC address of the branch controller to the branch config group. Once you have assigned a branch config group to a branch controller, you cannot edit the config group assigned to the branch controller in the whitelist entry. To assign a different configuration to an unprovisioned branch controller, you must delete the whitelist entry and create a new branch controller whitelist entry with the correct branch config group.
When you remove an entry for an active branch controller from the whitelist on the master controller, that branch controller no longer receives configuration or license updates from the master controller, but continues to operate as previously configured. As the license server is the master controller, any operation related to the licensing does not work after it is detached. If you remove an individual branch controller entry from the
ArubaOS 6.5.3.x
| User Guide Branch Controller Config for Cloud Services Controllers | 259
whitelist before that branch controller is connected to the network, that branch controller is not automatically provisioned as a branch controller, and remains inactive on the network until manually provisioned.
If you are using Activate to associate your branch controllers to a master controller, the master controller contacts the Activate server every hour to query for the latest whitelist. To immediately download the latest whitelist, access the controller command-line interface and execute the command activate sync .
You can manually add branch controllers to the master controller whitelist by navigating to
Configuration>Branch>Smart Config and selecting the Whitelist tab. The settings on the Whitelist tab are described in the table below.
Table 72: Branch Config Group Whitelist Settings
Parameter Description
MAC address
MAC address of the branch controller
Hostname
Remote
Group
Hostname of the master controller
The name of the branch config group whose settings are applied to the branch controller.
PortFast and BPDU Guard
The following section describes some of the Layer-2 Spanning Tree Protocol (STP) features for the branch controller solution. Currently, PortFast and Bridge Protocol Data Unit (BPDU) Guard features are supported, which work along with existing L2 STP feature. These two features enhance network reliability, manageability, and security for the existing L2 STP feature.
Some devices and local stacks running on systems/workstations are capable of generating potential STP
BPDUs that cause Denial of Service (DOS) attacks. PortFast and BPDU Guard features provide stability and security for network topologies to prevent such attacks.
PortFast
The PortFast feature is introduced to avoid network connectivity issues. These issues are caused by delays in
STP enabled ports moving from blocking-state to forwarding-state after transitioning from the listening and learning states. STP enabled ports that are connected to devices such as a single switch, workstation, or a server can access the network only after passing all these STP states. Some applications need to connect to the network immediately, else they will timeout.
Enabling the PortFast feature causes a switch or a trunk port to enter the STP forwarding-state immediately or upon a linkup event, thus bypassing the listening and learning states. The PortFast feature is enabled at a port level, and this port can either be a physical or a logical port. When PortFast feature is enabled on a switch or a trunk port, the port immediately transitions to the STP forwarding state.
Though PortFast is enabled the port still participates in STP. If the port happens to be part of topology that could form a loop, the port eventually transitions into STP blocking mode. PortFast is usually configured on an edge port, which means the port should not receive any STP BPDUs. If the port receives any STP BPDU, it moves back to normal/regular mode and will participate in the listening and learning states.
In most deployments, edge ports are access ports. However, in this scenario there are no restrictions in enabling the PortFast feature. The mode of the port changes from PortFast to non-PortFast when the port receives a STP BPDU. To re-enable this feature on a port, run the shut command followed by a no-shut command at the interface/port level.
260 | Branch Controller Config for Cloud Services Controllers ArubaOS 6.5.3.x | User Guide
Configuring PortFast on a non-edge port can cause instability to the STP topology.
BPDU Guard
BPDU Guard feature protects the port from receiving STP BPDUs, however the port can transmit STP BPDUs.
When a STP BPDU is received on a BPDU Guard enabled port, the port is shutdown and the state of the port changes to ErrDis (Error-Disable) state. The port remains in the ErrDis state until the port status is manually changed by using the configuration command shut followed by a no-shut applied on the interface. In most deployments, BPDU Guard feature is configured over the PortFast enabled STP ports, but in this implementation the BPDU Guard feature can be enabled on any of the STP ports, with or without PortFast feature being enabled on these ports.
It is recommended not to enable the BPDU Guard feature on a trunk port that forms the STP topology.
Scenarios Supported on PortFast and BPDU Guard
PortFast and BPDU Guard features are applied at the port/interface level. These features can also be applied in the following scenarios: n n n
RSTP and PVST modes
Access and Trunk ports
Physical and Logical ports
The PortFast and BPDU Guard features can be applied either independently or together.
In the global RSTP mode there is only one RSTP instance running in the entire controller. If the port that is enabled with PortFast and BPDU Guard receives any STP BPDU it will effect all the ports, as the global RSTP runs on a port basis.
In the PVST mode there can be multiple instances of RSTP running as they are based on per VLAN. Though it is based on per VLAN, it will still behave in the same way as it does in the global RSTP mode. For example, if there are five VLANs and each VLAN has a separate RSTP instance running, then any STP BPDU received on any of these five ports effects all ports.
If an STP BPDU is received from any one of the five RSTP instances running, the port that is enabled with BPDU
Guard shuts down and goes to ErrDis state. In other words both PortFast and BPDU Guard features are applied on a port basis for both global RSTP and PVST modes, even though the PVST runs on a per VLAN basis.
Enabling PortFast and BPDU Guard on a Port
The following section guides you to enable the PortFast and BPDU Guard features on a port.
In the Web UI
Follow the steps below to enable PortFast and BPDU Guard features on a port using the WebUI:
1. Navigate to Configuration>Branch>Smart Config and select the Networking tab.
2. In the Ports table, click the port number for which you want to enable PortFast and BPDU Guard.
3. Click Edit .
4. Select the PortFast and BPDU Guard checkbox.
5. Click Update .
To disable PortFast and BPDU Guard uncheck the PortFast and BPDU Guard checkboxes.
ArubaOS 6.5.3.x
| User Guide Branch Controller Config for Cloud Services Controllers | 261
It is recommended to enable PortFast only on access port types. However, PortFast can be enabled on the trunk ports by selecting the Trunk checkbox in the WebUI.
In the CLI
Execute the following commands at the command prompt to enable PortFast and BPDU Guard:
(host) (config) #interface gigabitinternet 0/0/4
(host) (config-if)#spanning-tree portfast
(host) (config-if)#spanning-tree bpduguard
To disable PortFast
(host) (config-if) #no spanning-tree portfast
(host) (config-if) #no spanning-tree bpduguard
Execute the following command to enable PortFast on trunk ports:
(host) (config) #interface gigabitethernet 0/0/4
(host) (config-if)#spanning-tree portfast trunk
Execute the following show command to display the status of the STP ports in Global RSTP mode.
(host) (config-if) #show spanning-tree interface gigabitethernet 0/0/4
Execute the following show command to display the status of the STP ports in Instance RSTP (PVST) mode.
(host) #show spanning-tree interface gigabitethernet 0/0/4
Execute the following command to display the status of BPDU Guard enabled port that is in ErrDis state. This command is applicable for ports that are in both the Global RSTP and Instance RSTP (PVST) modes.
(host) (config-if) #show spanning-tree interface gigabitethernet 0/0/4
Preventing WAN Link Failure on Virtual APs
In the branch controller deployments, the local controllers are connected across the WAN link from the master controller to the RADIUS server. A WAN link outage will result in service outage as new users cannot be authenticated to 802.1X Virtual APs. This feature provides limited connectivity to branch controllers even when the WAN link is down. To provide connectivity when the WAN link is down, open and PSK SSID Virtual APs
(VAPs) are available at all times and the user can connect to these VAPs instead of the main 802.1X Virtual AP.
Currently, this feature is targeted for Campus APs in branch office deployments.
When all the WAN links are down, an AP management module in the controller updates the link state using the notification it receives from the health check manager. Depending on the link state, the new set of Virtual APs are made available to the users, ensuring minimum service depending on the deployment. The VAPs for WAN link failure feature can be configured using the branch controller WebUI or command-line interface.
In the WebUI
1. Access the WebUI of a 7000 Series controller configured as a branch controller, and navigate to
Configuration> AP Configuration> AP Group Page .
2. Select an AP Group .
3. Navigate to Wireless LAN > Virtual AP .
4. Select an existing virtual AP or add a new virtual AP.
5. Once you select the virtual AP, click Advanced tab.
262 | Branch Controller Config for Cloud Services Controllers ArubaOS 6.5.3.x | User Guide
6. Modify the WAN Operation Mode drop-down menu value to Primary , Always , or Backup . For WAN link failure, this mode should be set to backup .
The three modes are as follows: l always —The virtual AP is permanently enabled. This is the default mode.
l l backup —The virtual AP is enabled when the WAN link is down. If the WAN link is up, the virtual AP is disabled automatically.
primary —The virtual AP is enabled when the WAN link is up. If the WAN link is down, the virtual AP is disabled automatically.
In the CLI
(host)(Virtual AP profile "default") #wan-operation backup
For example:
(host) (config) #wlan virtual-ap default
(host)(Virtual AP profile "default")#?
wan-operation Virtual-AP WAN operation wmm-traffic-managemen.. WMM Traffic Management Profile
(host)(Virtual AP profile "default")#wan-operation ?
always Enable virtual-AP regardless of WAN link state.
backup primary
Enable virtual-AP when WAN link is down.
Enable virtual-AP only when WAN link is present.
(host)(Virtual AP profile "default") #wan-operation backup
Branch WAN Dashboard
The WAN (Wide Area Network) dashboard, in the Dashboard section of the WebUI, is the landing page for the
Branch controller. The WAN dashboard provides the WAN summary details for VLANs.
Following figure shows a snapshot of the WAN summary dashboard:
The WAN Summary page contains the following tables: n
Status : This section of the WAN Dashboard includes tabs that displays information for the status of monitored links, and for deployments using Layer-3 redundancy the status of the branch connectivity to the primary and secondary master controllers.
l
Status : This section displays the link status and WAN status for VLANs monitored using the uplink manager utility. For each VLAN, the green represents an up status and red represents a down status for
ArubaOS 6.5.3.x
| User Guide Branch Controller Config for Cloud Services Controllers | 263
n n n n n the link and WAN. The
is enabled by default on branch controllers. If it is disabled, the WAN status link will appear orange, indicating that this feature is in an error state.
l
Layer3 Redundancy: This section displays the status of the branch controller's connection to the primary master and secondary master controllers defined during the branch controller's provisioning process.
Throughput : Displays the In and Out traffic for VLANs. The Throughput table has four tabs for different uplinks. First tab shows throughput of VLANs having high priority followed by other VLAN data based on its priority. Clicking on each tab loads In and Out traffic throughput data for that particular VLAN.
Latency : Displays Latency data for available VLANs. Each line represents one VLAN.
Alerts : Lists the last five alerts with time stamp and description.
Usage : Displays traffic based on Application Category or Application.
Compression : Displays compression that occurred on all VLANs together.
264 | Branch Controller Config for Cloud Services Controllers ArubaOS 6.5.3.x | User Guide
Chapter 12
802.1X Authentication
802.1X is an Institute of Electrical and Electronics Engineers (IEEE) standard that provides an authentication framework for WLANs. 802.1X uses the Extensible Authentication Protocol (EAP) to exchange messages during the authentication process. The authentication protocols that operate inside the 802.1X framework that are suitable for wireless networks include EAP-Transport Layer Security (EAP-TLS), Protected EAP (PEAP), and EAP-
Tunneled TLS (EAP-TTLS). These protocols allow the network to authenticate the client while also allowing the client to authenticate the network.
This chapter describes the following topics: n n n n
Understanding 802.1X Authentication on page 265
Configuring 802.1X Authentication on page 268
Sample Configurations on page 277
Performing Advanced Configuration Options for 802.1X on page 293
Other types of authentication not discussed in this section can be found in the following sections of this guide: n n n n
Captive portal authentication:
Configuring Captive Portal Authentication Profiles on page 325
VPN authentication:
Planning a VPN Configuration on page 352
MAC authentication:
Configuring MAC-Based Authentication on page 214
Stateful 802.1X, stateful NTLM, and WISPr authentication:
Stateful and WISPr Authentication on page 297
n n n
Understanding 802.1X Authentication
802.1X authentication consists of three components:
The supplicant , or client, is the device attempting to gain access to the network. You can configure the Aruba user-centric network to support 802.1X authentication for wired users a wireless users.
The authenticator is the gatekeeper to the network and permits or denies access to the supplicants.
The Aruba controller acts as the authenticator, relaying information between the authentication server and supplicant. The EAP type must be consistent between the authentication server and supplicant, and is transparent to the controller.
The authentication server provides a database of information required for authentication, and informs the authenticator to deny or permit access to the supplicant.
The 802.1X authentication server is typically an EAP-compliant Remote Access Dial-In User Service (RADIUS) server which can authenticate either users (through passwords or certificates) or the client computer.
An example of an 802.1X authentication server is the Internet Authentication Service (IAS) in Windows (see http://technet.microsoft.com/en-us/library/cc759077(WS.10).aspx
).
In Aruba user-centric networks, you can terminate the 802.1X authentication on the controller. The controller passes user authentication to its internal database or to a “backend” non-802.1X server. This feature, also called AAA FastConnect , is useful for deployments where an 802.1X EAP-compliant RADIUS server is not available or required for authentication.
Supported EAP Types
Following is the list of supported EAP types:
ArubaOS 6.5.3.x
| User Guide 802.1X Authentication | 265
n n n n n n n n n n n n
PEAP—Protected EAP (PEAP) is an 802.1X authentication method that uses server-side public key certificates to authenticate clients with the server. The PEAP authentication creates an encrypted SSL / TLS tunnel between the client and the authentication server. The exchange of information is encrypted and stored in the tunnel to ensure that the user credentials are kept secure.
EAP-GTC—The EAP-GTC (Generic Token Card) type uses clear text method to exchange authentication controls between the client and the server. Since the authentication mechanism uses the one-time tokens
(generated by the card), this method of credential exchange is considered safe. In addition, EAP-GTC is used in PEAP or TTLS tunnels in wireless environments. The EAP-GTC is described in RFC 2284.
EAP-AKA—The EAP-AKA (Authentication and Key Agreement) authentication mechanism is typically used in mobile networks that include Universal Mobile Telecommunication Systems (UMTS) and CDMA 2000. This method uses the information stored in the Subscriber Identity Module (SIM) for authentication. The EAP-
AKA is described in RFC 4187.
EAP-FAST—The EAP-FAST (Flexible Authentication via Secure Tunneling) is an alternative authentication method to PEAP. This method uses the Protected Access Credential (PAC) for verifying clients on the network. The EAP-FAST is described in RFC 4851.
EAP-MD5—The EAP-MD5 method verifies MD5 hash of a user password for authentication. This method is commonly used in a trusted network. The EAP-MD5 is described in RFC 2284.
EAP-POTP—The EAP type 32 is supported. Complete details are described in RFC 4793.
EAP-SIM—The EAP-SIM (Subscriber Identity Module) uses Global System for Mobile Communication (GSM)
Subscriber Identity Module (SIM) for authentication and session key distribution. This authentication mechanism includes network authentication, user anonymity support, result indication, and fast reauthentication procedure. Complete details about this authentication mechanism is described in RFC 4186.
EAP-TLS—The EAP-TLS (Transport Layer Security) uses Public key Infrastructure (PKI) to set up authentication with a RADIUS server or any authentication server. This method requires the use of a clientside certificate for communicating with the authentication server. The EAP-TLS is described in RFC 5216.
EAP-TLV—The EAP-TLV (type-length-value) method allows you to add additional information in an EAP message. Often this method is used to provide more information about an EAP message such as status information or authorization data. This method is always used after a typical EAP authentication process.
EAP-TTLS—The EAP-TTLS (Tunneled Transport Layer Security) method uses server-side certificates to set up authentication between clients and servers. The actual authentication is, however, performed using passwords. Complete details about EAP-TTLS is described in RFC 5281.
LEAP—Lightweight Extensible Authentication Protocol (LEAP) uses dynamic WEP keys and mutual authentication between the client and the RADIUS server.
ZLXEAP—ZoneLabs EAP is an EAP method that has been allocated EAP Type 44 by IANA. For more information, visit http://tools.ietf.org/html/draft-bersani-eap-synthesis-sharedkeymethods-00#page-30 .
Configuring Authentication with a RADIUS Server
See
for an overview of the parameters that you need to configure on authentication components when the authentication server is an 802.1X EAP-compliant RADIUS server.
Figure 47 802.1X Authentication with RADIUS Server
The supplicant and the authentication server must be configured to use the same EAP type. The controller does not need to know the EAP type used between the supplicant and authentication server.
266 | 802.1X Authentication ArubaOS 6.5.3.x | User Guide
For the controller to communicate with the authentication server, you must configure the IP address, authentication port, and accounting port of the server on the controller. The authentication server must be configured with the IP address of the RADIUS client, which is the controller in this case. Both the controller and the authentication server must be configured to use the same shared secret.
Additional information on EAP types supported in a Windows environment, Microsoft supplicants, and authentication servers, is available at http://technet.microsoft.com/en-us/library/cc782851
(WS.10).aspx
.
The client communicates with the controller through a GRE tunnel to form an association with an AP and to get authenticated in the network. Therefore, the network authentication and encryption configured for an ESSID must be the same on both the client and the controller.
Configuring Authentication Terminated on Controller
User authentication is performed either via the controller’s internal database or a non-802.1X server. See
802.1X Authentication Profile Basic WebUI Parameters on page 269
for an overview of the parameters that you need to configure on 802.1X authentication components when 802.1X authentication is terminated on the controller (AAA FastConnect).
Figure 48 802.1X Authentication with Termination on Controller
In this scenario, the supplicant is configured for EAP-Transport Layer Security (TLS) or EAP-Protected EAP
(PEAP).
n n
EAP-TLS is used with smart card user authentication. A smart card holds a digital certificate which, with the user-entered personal identification number (PIN), allows the user to be authenticated on the network. EAP-
TLS relies on digital certificates to verify the identities of both the client and the server.
EAP-TLS requires that you import server and certification authority (CA) certificates onto the controller (see
the controller (the client certificate must be signed by a known CA) before the username is checked on the authentication server.
EAP-PEAP uses TLS to create an encrypted tunnel. Within the tunnel, one of the following “inner EAP” methods is used: l
EAP-Generic Token Card (GTC): Described in RFC 2284, this EAP method permits the transfer of unencrypted usernames and passwords from client to server. The main uses for EAP-GTC are one-time token cards such as SecureID and the use of an LDAP or RADIUS server as the user authentication server. You can also enable caching of user credentials on the controller as a backup to an external authentication server.
l
EAP-Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAPv2): Described in RFC
2759, this EAP method is widely supported by Microsoft clients. A RADIUS server must be used as the backend authentication server.
If you use the controller’s internal database for user authentication, you need to add the names and passwords of the users to be authenticated. If you use an LDAP server for user authentication, you need to configure both the LDAP server and the user IDs and passwords on the controller. If you use a RADIUS server for user authentication, you need to configure the RADIUS server on the controller.
ArubaOS 6.5.3.x
| User Guide 802.1X Authentication | 267
Configuring 802.1X Authentication
On the controller, use the following steps to configure a wireless network that uses 802.1X authentication:
1. Configure the VLANs to which the authenticated users will be assigned. See
.
2. Configure policies and roles. You can specify a default role for users who are successfully authenticated using 802.1X. You can also configure server derivation rules to assign a user role based on attributes returned by the authentication server; server-derived user roles take precedence over default roles. For more information about policies and roles, see
Roles and Policies on page 381 .
The Policy Enforcement Firewall Virtual Private Network (PEFV) module provides identity-based security for wired and wireless users and must be installed on the controller. The stateful firewall allows user classification based on user identity, device type, location, and time of day to provide differentiated access for different classes of users. For information about obtaining and installing licenses, see
.
3. Configure the authentication server(s) and server group. The server can be an 802.1X RADIUS server or, if you use AAA FastConnect, a non-802.1X server or the controller’s internal database. If you use EAP-GTC within a PEAP tunnel, configure an LDAP or RADIUS server as the authentication server (see
Servers on page 179 ). If you use EAP-TLS, import server and CA certificates on the controller (see
Configuring and Using Certificates with AAA FastConnect on page 273 ).
4. Configure the AAA profile: l l
Select the 802.1X default user role.
Select the server group you previously configured for the 802.1X authentication server group.
5. Configure the 802.1X authentication profile. See
6. Configure the virtual AP profile for an AP group or for a specific AP: l l
Select the AAA profile you previously configured.
In the SSID profile, configure the WLAN for 802.1X authentication.
For details on how to complete the above steps, see
Sample Configurations on page 277
.
In the WebUI
This section describes how to create and configure a new instance of an 802.1X authentication profile in the
WebUI or the CLI.
1. Navigate to the Configuration > Security > Authentication > L2 Authentication page.
2. In the Profiles list, select 802.1X Authentication Profile .
3. Enter a name for the profile, then click Add.
4. Click Apply .
5. In the Profiles list, select the 802.1X authentication profile you just created.
6. Change the settings described in
as desired, then click Apply .
The 802.1X authentication profile configuration settings are divided into two tabs— Basic and Advanced .
The Basic tab displays only those configuration settings that often need to be adjusted to suit a specific network. The Advanced tab shows all configuration settings, including settings that do not need frequent adjustment or should be kept at their default values. If you change a setting on one tab, then click and display the other tab without saving your configuration, that setting will revert to its previous value.
268 | 802.1X Authentication ArubaOS 6.5.3.x | User Guide
Table 73: 802.1X Authentication Profile Basic WebUI Parameters
Parameter Description
Basic 802.1X Authentication Settings
Max authentication failures
Number of times a user can try to log in with wrong credentials after which the user is blacklisted as a security threat. Set to 0 to disable blacklisting, otherwise enter a non-zero integer to blacklist the user after the specified number of failures.
Range: 0-5 failures.
Default: 0 failure.
NOTE: This option may require a license.
Enforce Machine
Authentication
Select the Enforce Machine Authentication option to require machine authentication. This option is also available on the
NOTE: This option may require a license.
Basic settings tab.
Default role assigned to the user after completing only machine authentication.
The default role for this setting is the “guest” role.
Machine
Authentication: Default
Machine Role
Machine
Authentication: Default
User Role
Reauthentication
Default role assigned to the user after 802.1X authentication. The default role for this setting is the “guest” role.
Select the Reauthentication checkbox to force the client to do a 802.1X
reauthentication after the expiration of the default timer for reauthentication.
(The default value of the timer is 24 hours.) If the user fails to reauthenticate with valid credentials, the state of the user is cleared. If derivation rules are used to classify 802.1X-authenticated users, then the reauthentication timer per role overrides this setting.
This option is disabled by default.
Termination
Termination EAP-Type
Termination Inner EAP-
Type
Select the Termination checkbox to allow 802.1X authentication to terminate on the controller. This option is disabled by default.
If you enable termination, click either EAP-PEAP or EAP-TLS to select an Extensible
Authentication Protocol (EAP) method.
If you use EAP-PEAP as the EAP method, specify one of the following inner EAP types: n n eap-gtc : Described in RFC 2284, this EAP method permits the transfer of unencrypted usernames and passwords from client to server. The main uses for EAP-GTC are one-time token cards such as SecureID and the use of LDAP or RADIUS as the user authentication server. You can also enable caching of user credentials on the controller as a backup to an external authentication server.
eap-mschapv2 : Described in RFC 2759, this EAP method is widely supported by Microsoft clients.
Configure Suite-B 128 bit or more security level authentication enforcement.
Enforce Suite-B 128 bit or more security level
Authentication
Enforce Suite-B 128 bit or more security level
Authentication
Configure Suite-B 192 bit security level authentication enforcement.
Advanced 802.1X Authentication Settings
ArubaOS 6.5.3.x
| User Guide 802.1X Authentication | 269
Table 73: 802.1X Authentication Profile Basic WebUI Parameters
Parameter Description
Machine Authentication
Cache Timeout
Blacklist on Machine
Authentication Failure
Interval between
Identity Requests
Quiet Period after
Failed Authentication
Reauthentication
Interval
Use Server provided
Reauthentication
Interval
Multicast Key Rotation
Time Interval
The timeout, in hours, for machine authentication. The allowed range of values is
1-1000 hours, and the default value is 24 hours.
Select the Blacklist on Machine Authentication Failure checkbox to blacklist a client if machine authentication fails. This setting is disabled by default.
Interval, in seconds, between identity request retries.
Range: 1-65535 seconds.
Default: 5 seconds.
The enforced quiet period interval, in seconds, following failed authentication.
Range: 1-65535 seconds.
Default: 30 seconds.
Interval, in seconds, between reauthentication attempts.
Range: 60-864000 seconds.
Default: 86400 seconds (1 day).
Select this option to override any user-defined reauthentication interval and use the reauthentication period defined by the authentication server.
Unicast Key Rotation
Time Interval
Authentication Server
Retry Interval
Authentication Server
Retry Count
Framed MTU
Number of times ID-
Requests are retried
Maximum Number of
Reauthentication
Attempts
Interval, in seconds, between multicast key rotation.
Range: 60-864000 seconds.
Default: 1800 seconds.
Interval, in seconds, between unicast key rotation.
Range: 60-864000 seconds. Default: 900 seconds.
Server group retry interval, in seconds.
Range: 5-65535 seconds.
Default: 30 seconds.
Maximum number of authentication requests that are sent to server group.
Range: 0-3 requests.
Default: 2 requests.
Sets the framed Maximum Transmission Unit (MTU) attribute sent to the authentication server.
Range: 500-1500 bytes.
Default: 1100 bytes.
Maximum number of times ID requests are sent to the client.
Range: 1-10 retries.
Default: 3 retries.
Number of times a user can try to log in with wrong credentials after which the user is blacklisted as a security threat. Set to 0 to disable blacklisting, otherwise enter a value from 0-5 to blacklist the user after the specified number of failures.
NOTE: If changed from its default value, this option may require a license.
270 | 802.1X Authentication ArubaOS 6.5.3.x | User Guide
Table 73: 802.1X Authentication Profile Basic WebUI Parameters
Parameter Description
Maximum number of times Held State can be bypassed
Dynamic WEP Key
Message Retry Count
Dynamic WEP Key Size
Interval between
WPA/WPA2 Key
Messages
Delay between EAP-
Success and WPA2
Unicast Key Exchange
Number of consecutive authentication failures which, when reached, causes the controller to not respond to authentication requests from a client while the controller is in a held state after the authentication failure. Before this number is reached, the controller responds to authentication requests from the client even while the controller is in its held state.
(This parameter is applicable when 802.1X authentication is terminated on the controller, also known as AAA FastConnect.) The allowed range of values for this parameter is 0-3 failures, and the default value is 0.
Set the Number of times WPA/WPA2 Key Messages are retried.
Range: 1-5 retries.
Default: 3 retries.
The default dynamic WEP key size is 128 bits, If desired, you can change this parameter to 40 bits.
Interval, in milliseconds, between each WPA key exchanges.
Range: 1000-5000 ms.
Default: 1000 ms.
Interval, in milliseconds, between EAP-Success and unicast key exchanges.
Range: 0-2000 ms.
Default: 0 ms (no delay).
Delay between
WPA/WPA2 Unicast Key and Group Key
Exchange
Time interval after which the PMKSA will be deleted
The time interval after which the PMKSA (Pairwise Master Key Security
Association) cache is deleted. Time interval in Hours.
Range: 1-2000.
Default: 8.
WPA/WPA2 Key
Message Retry Count
Interval, in milliseconds, between unicast and multicast key exchange. Time interval in milliseconds.
Range: 0-2000.
Default: 0 (no delay).
Multicast Key Rotation
Unicast Key Rotation
Opportunistic Key
Caching
Number of times WPA/WPA2 key messages are retried.
Range: 1-5 retries.
Default: 3 retries.
Select this checkbox to enable multicast key rotation. This feature is disabled by default.
Select this checkbox to enable unicast key rotation. This feature is disabled by default.
By default, the 802.1X authentication profile enables a cached pairwise master key (PMK) which is derived through a client and an associated AP. This key is used when the client roams to a new AP. This allows clients faster roaming without a full 802.1X authentication. Uncheck this option to disable this feature.
NOTE: Make sure that the wireless client (the 802.1X supplicant) supports this feature. If the client does not support this feature, the client will attempt to renegotiate the key whenever it roams to a new AP. As a result, the key cached on the controller can be out of sync with the client's key.
ArubaOS 6.5.3.x
| User Guide 802.1X Authentication | 271
Table 73: 802.1X Authentication Profile Basic WebUI Parameters
Parameter
Validate PMKID
Description
Use Session Key
Use Static Key xSec MTU
Token Caching
Token Caching Period
CA-Certificate
Server-Certificate
TLS Guest Access
TLS Guest Role
Ignore EAPOL-START after authentication
Handle EAPOL-Logoff
Ignore EAP ID during negotiation
This parameter instructs the controller to check the pairwise master key (PMK) ID sent by the client. When you enable this option, the client must send a PMKID in the associate or reassociate frame to indicate that it supports OKC or PMK caching; otherwise, full 802.1X authentication takes place.
NOTE: This feature is optional, since most clients that support OKC and PMK caching do not send the PMKID in their association request.
Select the Use Session Key option to use the RADIUS session key as the unicast
WEP key. This option is disabled by default.
Select the Use Static Key option to use a static key as the unicast/multicast WEP key. This option is disabled by default.
Set the maximum transmission unit (MTU) for frames using the xSec protocol.
Range: 1024-1500 bytes.
Default: 1300 bytes.
If you select EAP-GTC as the inner EAP method, you can select the Token Caching checkbox to enable the controller to cache the username and password of each authenticated user. The controller continues to reauthenticate users with the remote authentication server. However, if the authentication server is unavailable, the controller will inspect its cached credentials to reauthenticate users.
This option is disabled by default.
If you select EAP-GTC as the inner EAP method, you can specify the timeout period, in hours, for the cached information. The default value is 24 hours.
Click the CA-Certificate drop-down list and select a certificate for client authentication. The CA certificate needs to be loaded in the controller before it will appear on this list.
Click the Server-Certificate drop-down list and select a server certificate the controller will use to authenticate itself to the client.
Select TLS Guest Access to enable guest access for EAP-TLS users with valid certificates. This option is disabled by default.
Click the TLS Guest Role drop-down list and select the default user role for EAP-
TLS guest users. This option may require a license.
Select Ignore EAPOL-START after authentication to ignore EAPOL-START messages after authentication. This option is disabled by default.
Select Handle EAPOL-Logoff to enable handling of EAPOL-LOGOFF messages.
This option is disabled by default.
Select Ignore EAP ID during negotiation to ignore EAP IDs during negotiation.
This option is disabled by default.
272 | 802.1X Authentication ArubaOS 6.5.3.x | User Guide
Table 73: 802.1X Authentication Profile Basic WebUI Parameters
Parameter
WPA-Fast-Handover
Description
Disable rekey and reauthentication for clients on call
Check certificate common name against
AAA server
Select this option to enable WPA-fast-handover on phones that support this feature. WAP fast-handover is disabled by default.
This feature disables rekey and reauthentication for VoWLAN clients. It is disabled by default, meaning that rekey and reauthentication is enabled.
NOTE: This option may require a license This option may require a license.
If you use client certificates for user authentication, enable this option to verify that the certificate's common name exists in the server. This parameter is enabled by default in the default-cap and default-rap VPN profiles, and disabled by default on all other VPN profiles.
In the CLI
The following command configures settings for an 802.1X authentication profiles. Individual parameters are described in the previous table.
(host)(config) #aaa authentication dot1x {<profile>|countermeasures}
Configuring and Using Certificates with AAA FastConnect
The controller supports 802.1X authentication using digital certificates for AAA FastConnect.
n n
Server Certificate—A server certificate installed in the controller verifies the authenticity of the controller for
802.1X authentication. Aruba controllers ship with a demonstration digital certificate. Until you install a customer-specific server certificate in the controller, this demonstration certificate is used by default for all secure HTTP connections (such as the WebUI and captive portal) and AAA FastConnect. This certificate is included primarily for the purposes of feature demonstration and convenience, and is not intended for long-term use in production networks. Users in a production environment are urged to obtain and install a certificate issued for their site or domain by a well-known certificate authority (CA). You can generate a
Certificate Signing Request (CSR) on the controller to submit to a CA. For information on how to generate a
CSR and how to import the CA-signed certificate into the controller, see
Managing Certificates on page 865 .
Client Certificates—Client certificates are verified on the controller (the client certificate must be signed by a known CA) before the username is checked on the authentication server. To use client certificate authentication for AAA FastConnect, you need to import the following certificates into the controller (see
Importing Certificates on page 867 ):
l l
Controller’s server certificate
CA certificate for the CA that signed the client certificates
In the WebUI
1. Navigate to the Configuration > Security > Authentication > L2 Authentication page.
2. In the Profiles list, select 802.1X Authentication Profile .
3. Select the default 802.1X authentication profile from the drop-down list to display configuration parameters.
4. In the Basic tab, select Termination .
5. Select the Advanced Tab.
6. In the Server-Certificate field, select the server certificate imported into the controller.
7. In the CA-Certificate field, select the CA certificate imported into the controller.
8. Click Save As . Enter a name for the 802.1X authentication profile.
ArubaOS 6.5.3.x
| User Guide 802.1X Authentication | 273
9. Click Apply .
In the CLI
(host)(config) #aaa authentication dot1x <profile>
termination enable
server-cert <certificate>
ca-cert <certificate>
Configuring User and Machine Authentication
When a Windows device boots, it logs onto the network domain using a machine account. Within the domain, the device is authenticated before computer group policies and software settings can be executed; this process is known as machine authentication . Machine authentication ensures that only authorized devices are allowed on the network.
You can configure 802.1X for both user and machine authentication (select the Enforce Machine
Authentication option described in
Table 73 ). This tightens the authentication process further, since both the
device and user need to be authenticated.
Working with Role Assignment with Machine Authentication Enabled
When you enable machine authentication, there are two additional roles you can define in the 802.1X
authentication profile: n n
Machine authentication default machine role
Machine authentication default user role
While you can select the same role for both options, you should define the roles as per the polices that need to be enforced. Also, these roles can be different from the 802.1X authentication default role configured in the
AAA profile.
With machine authentication enabled, the assigned role depends upon the success or failure of the machine and user authentications. In certain cases, the role that is ultimately assigned to a client can also depend upon attributes returned by the authentication server or server derivation rules configured on the controller.
describes role assignment based on the results of the machine and user authentications.
Table 74: Role Assignment for User and Machine Authentication
Machine
Auth
Status
Failed
Failed
Passed
User
Auth
Status
Failed
Passed
Failed
Description Role Assigned
Both machine authentication and user authentication failed. L2 authentication failed.
No role assigned. No access to the network allowed.
Machine authentication failed (for example, the machine information is not present on the server) and user authentication succeeded. Serverderived roles do not apply.
Machine authentication default user role configured in the 802.1X
authentication profile.
Machine authentication succeeded and user authentication has not been initiated. Server-derived roles do not apply.
Machine authentication default machine role configured in the 802.1X
authentication profile.
274 | 802.1X Authentication ArubaOS 6.5.3.x | User Guide
Machine
Auth
Status
Passed
User
Auth
Status
Passed
Description Role Assigned
Both machine and user are successfully authenticated. If there are server-derived roles, the role assigned via the derivation take precedence.
This is the only case where serverderived roles are applied.
A role derived from the authentication server takes precedence. Otherwise, the 802.1X authentication default role configured in the AAA profile is assigned.
For example, if the following roles are configured: n n n
802.1X authentication default role (in AAA profile): dot1x_user
Machine authentication default machine role (in 802.1X authentication profile): dot1x_mc
Machine authentication default user role (in 802.1X authentication profile): guest
Role assignment is as follows: n
If both machine and user authentication succeed, the role is dot1x_user. If there is a server-derived role, the server-derived role takes precedence.
n n n
If only machine authentication succeeds, the role is dot1x_mc.
If only user authentication succeeds, the role is guest.
On failure of both machine and user authentication, the user does not have access to the network.
With machine authentication enabled, the VLAN to which a client is assigned (and from which the client obtains its IP address) depends upon the success or failure of the machine and user authentications. The VLAN that is ultimately assigned to a client can also depend upon attributes returned by the authentication server or server derivation rules configured on the controller (see
Understanding VLAN Assignments on page 97
). If machine authentication is successful, the client is assigned the VLAN configured in the virtual AP profile. However, the client can be assigned a derived VLAN upon successful user authentication.
You can optionally assign a VLAN as part of a user role configuration. Do not use VLAN derivation if you configure user roles with VLAN assignments.
describes VLAN assignment based on the results of the machine and user authentications when VLAN derivation is used.
Table 75: VLAN Assignment for User and Machine Authentication
Machine Auth
Status
Failed
User
Auth
Status
Failed
Description
Failed
Passed
Passed
Failed
Both machine authentication and user authentication failed. L2 authentication failed.
Machine authentication failed (for example, the machine information is not present on the server) and user authentication succeeded.
Machine authentication succeeded and user authentication has not been initiated.
VLAN Assigned
No VLAN.
VLAN configured in the virtual AP profile.
VLAN configured in the virtual AP profile.
ArubaOS 6.5.3.x
| User Guide 802.1X Authentication | 275
Machine Auth
Status
Passed
User
Auth
Status
Passed
Description VLAN Assigned
Both machine and user are successfully authenticated.
Derived VLAN.
Otherwise, VLAN configured in the virtual
AP profile.
The administrator can now associate a VLAN ID to a client data based on the authentication credentials in a bridge mode.
Enabling 802.1X Supplicant Support on an AP
ArubaOS provides 802.1X supplicant support on the Access Point (AP). The AP can be used as a 802.1X
supplicant where access to the wired Ethernet network is restricted to those devices that can authenticate using 802.1X. You can provision an AP to act as an 802.1X supplicant and authenticate to the infrastructure using the PEAP protocol.
Both Campus APs (CAPs) and Remote APs (RAPs) can be provisioned to use 802.1X authentication.
Prerequisites
n n
An AP has to be configured with the credentials for 802.1X authentication. These credentials are stored securely in the AP flash.
The AP must complete the 802.1X authentication before it sends or receives IP traffic such as DHCP.
If the AP cannot complete 802.1X authentication (explicit failure or reply timeout) within 1 minute, the AP will proceed to initiate the IP traffic and attempt to contact the controller. The infrastructure can be configured to allow this. If the
AP contacts the controller it will be marked as unprovisioned so that the administrator can take corrective action.
Provisioning an AP as an 802.1X Supplicant
This section describes how an AP can be provisioned as an 802.1X supplicant using CLI or the WebUI.
In the WebUI
1. Navigate to the Configuration > Wireless > AP Installation > Provisioning window. The list of discovered APs are displayed on this page.
2. Select the AP you want to provision.
3. Click Provision . The provisioning window opens.
4. Select the 802.1X Parameters using PEAP checkbox and enter the following credentials: a. User Name: Enter the username of the AP in the User Name field.
b. Password: Enter the password of the AP in the Password field.
5. Enter the password again in the Confirm Password field and reconfirm it.
6. Click Apply and Reboot (at the bottom of the page).
In the CLI
(host) (config)# provision-ap
(host) (AP provisioning) # apdot1x-username <username>
(host) (AP provisioning) # apdot1x-passwd <password>
276 | 802.1X Authentication ArubaOS 6.5.3.x | User Guide
(host) (AP provisioning) # reprovision ap-name <apname>
To view the 802.1X authentication details on the controller:
(host) # show ap active
Sample Configurations
The following examples show basic configurations on the controller for: n n
Configuring Authentication with an 802.1X RADIUS Server on page 277
Configuring Authentication with the Controller’s Internal Database on page 287
In the following examples: n n
Wireless clients associate to the ESSID WLAN-01 .
The following roles allow different networks access capabilities: l student l l l faculty guest system administrators
The examples show how to configure using the WebUI and CLI commands.
Configuring Authentication with an 802.1X RADIUS Server
n n n
An EAP-compliant RADIUS server provides the 802.1X authentication. The RADIUS server administrator must configure the server to support this authentication. The administrator must also configure the server to all communications with the Aruba controller.
The authentication type is WPA. From the 802.1X authentication exchange, the client and the controller derive dynamic keys to encrypt data transmitted on the wireless network.
802.1X authentication based on PEAP with MS-CHAPv2 provides both computer and user authentication. If a user attempts to log in without the computer being authenticated first, the user is placed into a more limited “guest” user role.
Windows domain credentials are used for computer authentication, and the user’s Windows login and password are used for user authentication. A single user sign-on facilitates both authentication to the wireless network and access to the Windows server resources.
802.1X Configuration for IAS and Windows Clients on page 1120
describes how to configure the Microsoft Internet
Authentication Server and Windows XP wireless client to operate with the controller configuration shown in this section.
Configuring Roles and Policies
You can create the following policies and user roles for: n n n n n
Student
Faculty
Guest
Sysadmin
Computer
ArubaOS 6.5.3.x
| User Guide 802.1X Authentication | 277
Creating the Student Role and Policy
The student policy prevents students from using telnet, POP3, FTP, SMTP, SNMP, or SSH to the wired portion of the network. The student policy is mapped to the student user role.
In the WebUI
1. Navigate to the Configuration > Security > Access Control > Policies page. Select Add to add the student policy.
2. For Policy Name, enter student .
3. For Policy Type, select IPv4 Session .
4. Under Rules, select Add to add rules for the policy.
a. Under Source, select user .
b. Under Destination, select alias .
The following step defines an alias representing all internal network addresses. Once defined, you can use the alias for other rules and policies.
c. Under the alias selection, click New . For Destination Name, enter Internal Network. Click Add to add a rule. For Rule Type, select network . For IP Address, enter 10.0.0.0. For Network Mask/Range, enter
255.0.0.0. Click Add to add the network range. Repeat these steps to add the network range 172.16.0.0
- 255.255.0.0. Click Done . The alias Internal Network appears in the Destination menu. This step defines an alias representing all internal network addresses. Once defined, you can use the alias for other rules and policies.
d. Under Destination, select Internal Network.
e. Under Service, select service . In the Service scrolling list, select svc-telnet .
f. Under Action, select drop .
g. Click Add .
5. Under Rules, click Add .
a. Under Source, select user .
b. Under Destination, select alias and then select Internal Network .
c. Under Service, select service . In the Service scrolling list, select svc-pop3 .
d. Under Action, select drop .
e. Click Add .
6. Repeat steps 4A-E to create rules for the following services: svc-ftp, svc-smtp, svc-snmp, and svc-ssh.
7. Click Apply .
8. Click the User Roles tab. Click Add to create the student role.
9. For Role Name, enter student .
10.Under Firewall Policies, click Add . In Choose from Configured Policies, select the student policy you previously created. Click Done .
11.Click
Apply .
In the CLI
(host)(config) #ip access-list session student
user alias “Internal Network” svc-telnet deny
user alias “Internal Network” svc-pop3 deny
user alias “Internal Network” svc-ftp deny
user alias “Internal Network” svc-smtp deny
user alias “Internal Network” svc-snmp deny
user alias “Internal Network” svc-ssh deny
278 | 802.1X Authentication ArubaOS 6.5.3.x | User Guide
(host)(config) #user-role student
session-acl student
session-acl allowall
Creating the Faculty Role and Policy
The faculty policy is similar to the student policy, however faculty members are allowed to use POP3 and
SMTP for VPN remote access from home. (Students are not permitted to use VPN remote access.) The faculty policy is mapped to the faculty user role.
In the WebUI
1. Navigate to the Configuration > Security > Access Control > Policies page. Click Add to add the faculty policy.
2. For Policy Name, enter faculty .
3. For Policy Type, select IPv4 Session .
4. Under Rules, click Add to add rules for the policy.
a. Under Source, select user .
b. Under Destination, select alias , then select Internal Network .
c. Under Service, select service . In the Service scrolling list, select svc-telnet .
d. Under Action, select drop .
e. Click Add .
f. Repeat steps A-E to create rules for the following services: svc-ftp, svc-snmp, and svc-ssh.
5. Click Apply .
6. Select the User Roles tab. Click Add to create the faculty role.
7. For Role Name, enter faculty .
8. Under Firewall Policies , click Add . In Choose from Configured Policies, select the faculty policy you previously created. Click Done .
In the CLI
(host)(config) #ip access-list session faculty
user alias “Internal Network” svc-telnet deny
user alias “Internal Network” svc-ftp deny
user alias “Internal Network” svc-snmp deny
user alias “Internal Network” svc-ssh deny
(host)(config) #user-role faculty
session-acl faculty
session-acl allowall
Creating the Guest Role and Policy
The guest policy permits only access to the internet (via HTTP or HTTPS) and only during daytime working hours. The guest policy is mapped to the guest user role.
In the WebUI
1. Navigate to the Configuration > Security > Access Control > Time Ranges page to define the time range working-hours. Click Add.
a. For Name, enter working-hours .
b. For Type, select Periodic .
c. Click Add .
d. For Start Day, click Weekday .
ArubaOS 6.5.3.x
| User Guide 802.1X Authentication | 279
e. For Start Time, enter 07:30 .
f. For End Time, enter 17:00 .
g. Click Done .
h. Click Apply .
2. Click the Policies tab. Click Add to add the guest policy.
3. For e Policy Name , enter guest .
4. For Policy Type , select IPv4 Session .
5. Under Rules, click Add to add rules for the policy.
To create rules to permit access to DHCP and DNS servers during working hours: a. Under Source , select user .
b. Under Destination , select host . In Host IP, enter 10.1.1.25
.
c. Under Service , select service . In the Service scrolling list, select svc-dhcp .
d. Under Action , select permit .
e. Under Time Range , select working-hours .
f. Click Add .
g. Repeat steps A-F to create a rule for svc-dns .
To create a rule to deny access to the internal network: a. Under Source, select user .
b. Under Destination, select alias . Select Internal Network .
c. Under Service, select any .
d. Under Action, select drop .
e. Click Add .
To create rules to permit HTTP and HTTPS access during working hours: a. Under Source, select user .
b. Under Destination, select any .
c. Under Service, select service. In the Services scrolling list, select svc-http .
d. Under Action, select permit .
e. Under Time Range, select working-hours .
f. Click Add .
g. Repeat steps A-F for the svc-https service.
To create a rule that denies the user access to all destinations and all services: a. Under Source, select user .
b. Under Destination, select any .
c. Under Service, select any .
d. Under Action, select drop .
e. Click Add .
6. Click Apply .
7. Click the User Roles tab. Click Add to create the guest role.
8. For Role Name, enter guest.
9. Under Firewall Policies , click Add.
In Choose from Configured Policies, select the guest policy you previously created. Click Done .
280 | 802.1X Authentication ArubaOS 6.5.3.x | User Guide
In the CLI time-range working-hours periodic
weekday 07:30 to 17:00
(host)(config) #ip access-list session guest
user host 10.1.1.25 svc-dhcp permit time-range working-hours
user host 10.1.1.25 svc-dns permit time-range working-hours
user alias “Internal Network” any deny
user any svc-http permit time-range working-hours
user any svc-https permit time-range working-hours
user any any deny
(host)(config) #user-role guest
session-acl guest
Creating Roles and Policies for Sysadmin and Computer
The allowall policy, a predefined policy, allows unrestricted access to the network. The allowall policy is mapped to both the sysadmin user role and the computer user role.
In the WebUI
1. Navigate to Configuration > Security > Access Control > User Roles page. Click Add to create the sysadmin role.
2. For Role Name, enter sysadmin .
3. Under Firewall Policies, click Add . In Choose from Configured Policies, select the predefined allowall policy.
Click Done .
4. Click Apply .
In the CLI
(host)(config) #user-role sysadmin
session-acl allowall
Creating a computer role
In the WebUI
1. Navigate to Configuration > Security > Access Control > User Roles page. Click Add to create the computer role.
2. For Role Name, enter computer .
3. Under Firewall Policies, click Add . In Choose from Configured Policies, select the predefined allowall policy.
Click Done .
4. Click Apply.
In the CLI
Use the following command to create a computer role:
(host)(config) #user-role computer
session-acl allowall
Creating an Alias for the Internal Network
In the CLI
(host)(config) #netdestination “Internal Network”
network 10.0.0.0 255.0.0.0
network 172.16.0.0 255.255.0.0
ArubaOS 6.5.3.x
| User Guide 802.1X Authentication | 281
Configuring the RADIUS Authentication Server
Configure the RADIUS server IAS1, with IP address 10.1.1.21 and shared key. The RADIUS server is configured to sent an attribute called Class to the controller; the value of this attribute is set to either “student,” “faculty,” or “sysadmin” to identify the user’s group. The controller uses the literal value of this attribute to determine the role name.
On the controller, you add the configured server (IAS1) into a server group. For the server group, you configure the server rule that allows the Class attribute returned by the server to set the user role.
In the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. In the Servers list, select Radius Server . In the RADIUS Server Instance list, enter IAS1 and click Add .
a. Select IAS1 to display configuration parameters for the RADIUS server.
b. For IP Address, enter 10.1.1.21.
c. For Key, enter |*a^t%183923!.
(You must enter the key string twice.) d. Click Apply .
3. In the Servers list, select Server Group. In the Server Group Instance list, enter IAS and click Add.
a. Select the server group IAS to display configuration parameters for the server group.
b. Under Servers, click New .
c. From the Server Name drop-down list, select IAS1. Click Add Server .
4. Under Server Rules, click New .
a. For Condition, enter Class.
b. For Attribute, select value-of from the drop-down list.
c. For Operand, select set role .
d. Click Add .
5. Click Apply.
In the CLI
(host)(config) #aaa authentication-server radius IAS1 host 10.1.1.21
key |*a^t%183923!
(host)(config) #aaa server-group IAS auth-server IAS1 set role condition Class value-of
Configuring 802.1X Authentication
An AAA profile specifies the 802.1X authentication profile and 802.1X server group to be used for authenticating clients for a WLAN. The AAA profile also specifies the default user roles for 802.1X and MAC authentication.
In the 802.1X authentication profile, configure enforcement of machine authentication before user authentication. If a user attempts to log in before machine authentication completes, the user is placed in the limited guest role.
In the WebUI
1. Navigate to the Configuration > Security > Authentication > L2 Authentication page.
2. Select 802.1X Authentication Profile .
a. At the bottom of the Instance list, enter dot1x , then click Add .
282 | 802.1X Authentication ArubaOS 6.5.3.x | User Guide
b. Select the profile name you just added.
c. Select Enforce Machine Authentication .
d. For the Machine Authentication: Default Machine Role, select computer .
e. For the Machine Authentication: Default User Role, select guest .
f. Click Apply .
3. Select the AAA Profiles tab.
a. In the AAA Profiles Summary, click Add to add a new profile.
b. Enter aaa_dot1x , then click Add .
a. Select the profile name you just added.
b. For MAC Auth Default Role, select computer .
c. For 802.1X Authentication Default Role, select faculty .
d. Click Apply .
4. In the Profiles list (under the aaa_dot1x profile), select 802.1X Authentication Profile .
a. From the drop-down list, select the dot1x 802.1X authentication profile you configured previously.
b. Click Apply .
5. In the Profiles list (under the aaa_dot1x profile), select 802.1X Authentication Server Group .
a. From the drop-down list, select the IAS server group you created previously.
b. Click Apply .
In the CLI
(host)(config) #aaa authentication dot1x dot1x machine-authentication enable machine-authentication machine-default-role computer machine-authentication user-default-role guest
(host)(config) #aaa profile aaa_dot1x d>ot1x-default-role faculty mac-default-role computer authentication-dot1x dot1x d>ot1x-server-group IAS
Configuring VLANs
In this example, wireless clients are assigned to either VLAN 60 or 61 while guest users are assigned to VLAN
63. VLANs 60 and 61 split users into smaller IP subnetworks, improving performance by decreasing broadcast traffic. The VLANs are internal to the Aruba controller only and do not extend into other parts of the wired network. The clients’ default gateway is the Aruba controller, which routes traffic out to the 10.1.1.0
subnetwork.
You configure the VLANs, assign IP addresses to each VLAN, and establish the “helper address” to which client
DHCP requests are forwarded.
In the WebUI
1. Navigate to the Configuration > Network > VLANs page. Click Add to add VLAN 60.
a. For VLAN ID , enter 60 .
b. Click Apply.
c. Repeat steps A and B to add VLANs 61 and 63.
2. To configure IP parameters for the VLANs, navigate to the Configuration > Network > IP > IPInterfaces page.
ArubaOS 6.5.3.x
| User Guide 802.1X Authentication | 283
a. Click Edit for VLAN 60.
b. For IP Address, enter 10.1.60.1
.
c. For Net Mask, enter 255.255.255.0
.
d. Under DHCP Helper Address, click Add.
Enter 10.1.1.25
and click Add .
e. Click Apply .
3. In the IP Interfaces page, click Edit for VLAN 61.
a. For IP Address, enter 10.1.61.1
.
b. For Net Mask, enter 255.255.255.0
.
c. Under DHCP Helper Address, click Add . Enter 10.1.1.25
and click Add.
d. Click Apply .
4. In the IP Interfaces page, click Edit for VLAN 63.
a. For IP Address, enter 10.1.63.1
.
b. For Net Mask, enter 255.255.255.0.
c. Under DHCP Helper Address, click Add . Enter 10.1.1.25
and click Add .
d. Click Apply .
5. Select the IP Routes tab.
a. For Default Gateway, enter 10.1.1.254
.
b. Click Apply .
In the CLI
(host)(config) #vlan 60
(host)(config) #interface vlan 60 ip address 10.1.60.1 255.255.255.0
ip helper-address 10.1.1.25
(host)(config) #vlan 61
(host)(config) #interface vlan 61 ip address 10.1.61.1 255.255.255.0
ip helper-address 10.1.1.25
(host)(config) #vlan 63
(host)(config) #interface vlan 63 ip address 10.1.63.1 255.255.255.0
ip helper-address 10.1.1.25
(host)(config) #ip default-gateway 10.1.1.254
Configuring the WLANs
In this example, default AP parameters for the entire network are: the default ESSID is WLAN-01 and the encryption mode is TKIP. A second ESSID called “guest” has the encryption mode set to static WEP with a configured WEP key.
In this example, the non-guest clients that associate to an AP are mapped into one of two different user VLANs.
The initial AP to which the client associates determines the VLAN: clients that associate to APs in the first floor of the building are mapped to VLAN 60, and clients that associate to APs in the second floor of the building are mapped to VLAN 61. Therefore, the APs in the network are segregated into two AP groups, named first-floor and second-floor. (See
Creating an AP group on page 529
for information about creating AP groups.) The guest clients are mapped into VLAN 63.
284 | 802.1X Authentication ArubaOS 6.5.3.x | User Guide
Configuring the Guest WLAN
You create and configure the virtual AP profile, guest and apply the profile to each AP group. The “guest” virtual
AP profile contains the SSID profile “guest” which configures static WEP with a WEP key.
In the WebUI
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. In the AP Group list, click Edit for first-floor.
3. Under Profiles, select Wireless LAN and then Virtual AP .
4. To create the guest virtual AP: a. Select NEW from the Add a profile drop-down list. Enter guest , and click Add.
b. In the Profile Details entry for the guest virtual AP profile, select NEW from the SSID profile drop-down list. A pop-up window allows you to configure the SSID profile.
c. For the name for the SSID profile enter guest .
d. For the Network Name for the SSID, enter guest .
e. For Network Authentication , select None .
f. For Encryption , select WEP .
g. Enter the WEP Key.
h. Click Apply to apply the SSID profile to the Virtual AP.
i.
Under Profile Details , click Apply .
5. Click on the guest virtual AP name in the Profiles list or in Profile Details to display configuration parameters.
a. Ensure that you select Virtual AP enable .
b. For VLAN , select 63 .
c. Click Apply .
6. Navigate to the Configuration > Wireless > AP Configuration page.
7. In the AP Group list, click Edit for the second-floor.
8. In the Profiles list, select Wireless LAN and then Virtual AP .
9. Select guest from the Add a profile drop-down list. Click Add .
10.Click
Apply .
In the CLI
(host)(config) #wlan ssid-profile guest essid guest wepkey1 aaaaaaaaaa opmode static-wep
(host)(config) #wlan virtual-ap guest vlan 63 ssid-profile guest
(host)(config) #ap-group first-floor virtual-ap guest
(host)(config) #ap-group second-floor virtual-ap guest
Configuring the Non-Guest WLANs
You create and configure the SSID profile “WLAN-01” with the ESSID “WLAN-01” and WPA TKIP encryption. You need to create and configure two virtual AP profiles: one with VLAN 60 for the first-floor AP group and the
ArubaOS 6.5.3.x
| User Guide 802.1X Authentication | 285
other with VLAN 61 for the second-floor AP group. Each virtual AP profile references the SSID profile “WLAN-
01” and the previously-configured AAA profile aaa_dot1x.
In the WebUI
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. In the AP Group list, click Edit for the first-floor.
3. In the Profiles list, select Wireless LAN and then Virtual AP .
4. To configure the WLAN-01_first-floor virtual AP: a. Select NEW from the Add a profile drop-down list. Enter WLAN-01_first-floor , and click Add .
b. In the Profile Details entry for the WLAN-01_first-floor virtual AP profile, select the aaa_dot1x AAA profile you previously configured. A pop-up window displays the configured AAA profile parameters.
Click Apply .
c. From the SSID profile drop-down list, select NEW. A pop-up window allows you to configure the SSID profile.
d. Enter WLAN-01 for the name of the SSID profile.
e. For Network Name , enter WLAN-01 .
f. For Network Authentication , select WPA.
g. Click Apply .
h. At the bottom of the Profile Details page, click Apply .
5. Click on the WLAN-01_first-floor virtual AP name in the Profiles list or in Profile Details to display configuration parameters.
a. Ensure that you select Virtual AP enable .
b. For VLAN , select 60.
c. Click Apply .
6. Navigate to the Configuration > Wireless > AP Configuration page.
7. In the AP Group list, click Edit for the second-floor.
8. In the Profiles list, select Wireless LAN and then Virtual AP .
9. To configure the WLAN-01_second-floor virtual AP: a. Select NEW from the Add a profile drop-down list. Enter WLAN-second-floor , and click Add .
b. In the Profile Details entry for the virtual AP profile, select aaa_dot1x from the AAA profile drop-down list. A pop-up window displays the configured AAA profile parameters. Click Apply .
c. From the SSID profile drop-down list, select WLAN-01 . A pop-up window displays the configured SSID profile parameters. Click Apply .
d. At the bottom of the Profile Details page, click Apply.
10.Click on the new virtual AP name in the Profiles list or in Profile Details to display configuration parameters.
a. Ensure that you select Virtual AP enable .
b. For VLAN , select 61.
c. Click Apply .
In the CLI
(host)(config) #wlan ssid-profile WLAN-01 essid WLAN-01 opmode wpa-tkip
(host)(config) #wlan virtual-ap WLAN-01_first-floor
286 | 802.1X Authentication ArubaOS 6.5.3.x | User Guide
vlan 60 aaa-profile aaa_dot1x ssid-profile WLAN-01
(host)(config) #wlan virtual-ap WLAN-01_second-floor vlan 61 aaa-profile aaa_dot1x ssid-profile WLAN-01
(host)(config) #ap-group first-floor virtual-ap WLAN-01_first-floor ap-group second-floor virtual-ap WLAN-01_second-floor
Configuring Authentication with the Controller’s Internal Database
In the following example: n n
The controller’s internal database provides user authentication.
The authentication type is WPA. From the 802.1X authentication exchange, the client and the controller derive dynamic keys to encrypt data transmitted on the wireless network.
Configuring the Internal Database
Configure the internal database with the username, password, and role (student, faculty, or sysadmin) for each user. There is a default internal server group that includes the internal database. For the internal server group, configure a server derivation rule that assigns the role to the authenticated client.
In the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. In the Servers list, select Internal DB .
3. Under Users, click Add User to add users.
4. For each user, enter a username and password.
5. Select a role for each user (if a role is not specified, the default role is guest).
6. Select the expiration time for the user account in the internal database.
7. Click Apply .
In the CLI
Use the privileged mode in the CLI to configure users in the controller’s internal database.
(host)(config) #local-userdb add username < user> password < password>
Configuring a Server Rule
In the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Server Group to display the Server Group list.
3. Select the internal server group.
4. Under Server Rules , click New to add a server derivation rule.
a. For Condition , enter Role.
b. Select value-of from the drop-down list.
ArubaOS 6.5.3.x
| User Guide 802.1X Authentication | 287
c. Select Set Role from the drop-down list.
d. Click Add .
5. Click Apply .
In the CLI
(host)(config) #aaa server-group internal set role condition Role value-of
Configuring 802.1X Authentication
An AAA profile specifies the 802.1X authentication profile and 802.1X server group to be used for authenticating clients for a WLAN. The AAA profile also specifies the default user role for 802.1X
authentication.
For this example, you enable both 802.1X authentication and termination on the controller.
In the WebUI
1. Navigate to the Configuration > Security > Authentication > L2 Authentication page. In the profiles list, select 802.1X Authentication Profile .
a. In the Instance list, enter dot1x, then click Add .
b. Select the dot1x profile you just created.
c. Select Termination .
The defaults for EAP Method and Inner EAP Method are EAP-PEAP and EAP-MSCHAPv2, respectively.
d. Click Apply .
2. Select the AAA Profiles tab.
a. In the AAA Profiles Summary , click Add to add a new profile.
b. Enter aaa_dot1x , then click Add .
c. Select the aaa_dot1x profile you just created.
d. For 802.1X Authentication Default Role, select faculty .
e. Click Apply .
3. In the Profiles list (under the aaa_dot1x profile you just created), select 802.1X Authentication Profile .
a. Select the dot1x profile from the 802.1X Authentication Profile drop-down list.
b. Click Apply.
4. In the Profiles list (under the aaa_dot1x profile you just created), select 802.1X Authentication Server
Group .
a. Select the internal server group.
b. Click Apply .
In the CLI
(host)(config) #aaa authentication dot1x dot1x termination enable
(host)(config) #aaa profile aaa_dot1x d>ot1x-default-role student authentication-dot1x dot1x d>ot1x-server-group internal
288 | 802.1X Authentication ArubaOS 6.5.3.x | User Guide
Configuring VLANs
In this example, wireless clients are assigned to either VLAN 60 or 61 while guest users are assigned to VLAN
63. VLANs 60 and 61 split users into smaller IP subnetworks, improving performance by decreasing broadcast traffic. The VLANs are internal to the Aruba controller only and do not extend into other parts of the wired network. The clients’ default gateway is the Aruba controller, which routes traffic out to the 10.1.1.0
subnetwork.
You configure the VLANs, assign IP addresses to each VLAN, and establish the “helper address” to which client
DHCP requests are forwarded.
In the WebUI
1. Navigate to the Configuration > Network > VLAN page. Click Add to add VLAN 60.
a. For VLAN ID , enter 60 .
b. Click Apply .
c. Repeat steps A and B to add VLANs 61 and 63.
2. To configure IP parameters for the VLANs, navigate to the Configuration > Network > IP > IP Interfaces page.
a. Click Edit for VLAN 60.
b. For IP Address, enter 10.1.60.1
.
c. For Net Mask, enter 255.255.255.0
.
d. Under DHCP Helper Address, click Add.
Enter 10.1.1.25
and click Add .
e. Click Apply.
3. In the IP Interfaces page, click Edit for VLAN 61.
a. For IP Address, enter 10.1.61.1
.
b. For Net Mask, enter 255.255.255.0
.
c. Under DHCP Helper Address, click Add . Enter 10.1.1.25
and click Add .
d. Click Apply .
4. In the IP Interfaces page, click Edit for VLAN 63.
a. For IP Address, enter 10.1.63.1
.
b. For Net Mask, enter 255.255.255.0
.
c. Under DHCP Helper Address, click Add . Enter 10.1.1.25
and click Add .
d. Click Apply .
5. Select the IP Routes tab.
a. For Default Gateway, enter 10.1.1.254
.
b. Click Apply .
In the CLI
(host)(config) #vlan 60
(host)(config) #interface vlan 60 ip address 10.1.60.1 255.255.255.0
ip helper-address 10.1.1.25
(host)(config) #vlan 61
(host)(config) #interface vlan 61 ip address 10.1.61.1 255.255.255.0
ip helper-address 10.1.1.25
(host)(config) #vlan 63
(host)(config) #interface vlan 63
ArubaOS 6.5.3.x
| User Guide 802.1X Authentication | 289
ip address 10.1.63.1 255.255.255.0
ip helper-address 10.1.1.25
(host)(config) #ip default-gateway 10.1.1.254
Configuring WLANs
In this example, default AP parameters for the entire network are as follows: the default ESSID is WLAN-01 and the encryption mode is TKIP. A second ESSID called guest has the encryption mode set to static WEP with a configured WEP key.
In this example, the non-guest clients that associate to an AP are mapped into one of two different user VLANs.
The initial AP to which the client associates determines the VLAN: clients that associate to APs in the first floor of the building are mapped to VLAN 60, and clients that associate to APs in the second floor of the building are mapped to VLAN 61. Therefore, the APs in the network are segregated into two AP groups, named first-floor and second-floor. (See
Creating an AP group on page 529
for information about creating AP groups.) The guest clients are mapped into VLAN 63.
Configuring the Guest WLAN
You create and configure the virtual AP profile, guest and apply the profile to each AP group. The guest virtual
AP profile contains the SSID profile, guest which configures static WEP with a WEP key.
In the WebUI
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. In the AP Group list, select first-floor .
3. In the Profiles list, select Wireless LAN and then Virtual AP .
4. To configure the guest virtual AP: a. Select NEW from the Add a profile drop-down list. Enter guest for the name of the virtual AP profile, and click Add .
b. In the Profile Details entry for the guest virtual AP profile, select NEW from the SSID profile drop-down list. A pop-up window allows you to configure the SSID profile.
c. Enter guest for the name of the SSID profile.
d. Enter guest for the Network Name.
e. For Network Authentication, select None .
f. For Encryption, select WEP .
g. Enter the WEP key.
h. Click Apply .
i.
Under Profile Details , click Apply.
5. Click on the guest virtual AP name in the Profiles list or in Profile Details to display configuration parameters.
a. Ensure that you select Virtual AP enable .
b. For VLAN , select 63 .
c. Click Apply.
6. Navigate to the Configuration > Wireless > AP Configuration page.
7. In the AP Group list, select second-floor .
8. In the Profiles list, select Wireless LAN and then Virtual AP .
9. Select guest from the Add a profile drop-down list. Click Add .
10.Click
Apply .
290 | 802.1X Authentication ArubaOS 6.5.3.x | User Guide
In the CLI
(host)(config) #wlan ssid-profile guest essid guest wepkey1 aaaaaaaaaa opmode static-wep
(host)(config) #wlan virtual-ap guest vlan 63 ssid-profile guest
(host)(config) #ap-group first-floor virtual-ap guest
(host)(config) #ap-group second-floor virtual-ap guest
Configuring the Non-Guest WLANs
You create and configure the SSID profile “WLAN-01” with the ESSID “WLAN-01” and WPA TKIP encryption. You need to create and configure two virtual AP profiles: one with VLAN 60 for the first-floor AP group and the other with VLAN 61 for the second-floor AP group. Each virtual AP profile references the SSID profile “WLAN-
01” and the previously-configured AAA profile “aaa_dot1x”.
In the WebUI
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. In the AP Group list, select first-floor.
3. In the Profiles list, select Wireless LAN, then select Virtual AP.
4. To configure the WLAN-01_first-floor virtual AP: a. Select NEW from the Add a profile drop-down list. Enter WLAN-01_first-floor , and click Add .
b. In the Profile Details entry for the WLAN-01_first-floor virtual AP profile, select aaa_dot1x from the
AAA Profile drop-down list. A pop-up window displays the configured AAA parameters. Click Apply .
c. From the SSID profile drop-down list, select NEW . A pop-up window allows you to configure the SSID profile.
d. Enter WLAN-01 for the name of the SSID profile.
e. Enter WLAN-01 for the Network Name.
f. Select WPA for Network Authentication.
g. Click Apply .
h. At the bottom of the Profile Details page, click Apply .
5. Click on the WLAN-01_first-floor virtual AP profile name in the Profiles list or in Profile Details to display configuration parameters.
a. Ensure that you select Virtual AP enable .
b. For VLAN, select 60.
c. Click Apply .
6. Navigate to the Configuration > Wireless > AP Configuration page.
7. In the AP Group list, select second-floor.
8. In the Profiles list, select Wireless LAN and then Virtual AP .
9. To create the WLAN-01_second-floor virtual AP: a. Select NEW from the Add a profile drop-down list. Enter WLAN-01_second-floor , and click Add .
b. In the Profile Details entry for the virtual AP profile, select aaa_dot1x from the AAA Profile dropdown list. A pop-up window displays the configured AAA profile parameters. Click Apply .
ArubaOS 6.5.3.x
| User Guide 802.1X Authentication | 291
c. From the SSID profile drop-down list, select WLAN-01 . A pop-up window displays the configured SSID profile parameters. Click Apply .
d. At the bottom of the Profile Details page, click Apply .
10.Click on the WLAN-01_second-floor virtual AP profile name in the Profiles list or in Profile Details to display the configuration parameters.
a. Ensure that you select Virtual AP enable .
b. For VLAN , select 61.
c. Click Apply .
In the CLI
(host)(config) #wlan ssid-profile WLAN-01 essid WLAN-01 opmode wpa-tkip
(host)(config) #wlan virtual-ap WLAN-01_first-floor vlan 60 aaa-profile aaa_dot1x ssid-profile WLAN-01
(host)(config) #wlan virtual-ap WLAN-01_second-floor vlan 61 aaa-profile aaa_dot1x sid-profile WLAN-01
(host)(config) #ap-group first-floor virtual-ap WLAN-01_first-floor
(host)(config) #ap-group second-floor virtual-ap WLAN-01_second-floor
Configuring Mixed Authentication Modes
Use l2-auth-fail-through command to perform mixed authentication which includes both MAC and 802.1X
authentication. When MAC authentication fails, enable the l2-auth-fail-through command to perform
802.1X authentication.
By default the l2-auth-fail-through command is disabled.
Table 76: Mixed Authentication Modes
Authentication 1
Success MAC authentication
802.1X
authentication
Association
Success
Role Assignment dynamicwep
802.1X
2
Success
Fail
No
Association
—
3
Success
— staticwep
MAC
4
Fail
Success dynamicwep
802.1X
describes the different authentication possibilities
5
Fail
Fail
6
Fail
—
No
Association
— staticwep logon
292 | 802.1X Authentication ArubaOS 6.5.3.x | User Guide
In the CLI
(host)(config) #aaa profile test l2-auth-fail-through
Performing Advanced Configuration Options for 802.1X
This section describes advanced configuration options for 802.1X authentication.
Configuring Reauthentication with Unicast Key Rotation
When enabled, unicast and multicast keys are updated after each reauthorization. It is a best practice to configure the time intervals for reauthentication, multicast key rotation, and unicast key rotation to be at least
15 minutes. Ensure that these intervals are mutually prime, and the factor of the unicast key rotation interval and the multicast key rotation interval is less than the reauthentication interval.
Unicast key rotation depends upon both the AP/controller and wireless client behavior. It is known that some wireless
NICs have issues with unicast key rotation.
The following is an example of the parameters you can configure for reauthentication with unicast and multicast key rotation: n n n n n n
Reauthentication: Enabled
Reauthentication Time Interval: 6011 Seconds
Multicast Key Rotation: Enabled
Multicast Key Rotation Time Interval: 1867 Seconds
Unicast Key Rotation: Enabled
Unicast Key Rotation Time Interval: 1021 Seconds
In the WebUI
1. Navigate to the Configuration > Security > Authentication > L2 Authentication page.
2. Select 802.1X Authentication Profile, then select the name of the profile you want to configure.
3. Select the Advanced tab. Enter the following values: l
Reauthentication Interval: 6011 l l
Multicast Key Rotation Time Interval: 1867
Unicast Key Rotation Time Interval: 1021 l l
Multicast Key Rotation: (select)
Unicast Key Rotation: (select) l
Reauthentication: (select)
4. Click Apply .
In the CLI
(host)(config) #aaa authentication dot1x profile reauthentication timer reauth-period 6011 unicast-keyrotation timer ukey-rotation-period 1021 multicast-keyrotation timer mkey-rotation-period 1867
ArubaOS 6.5.3.x
| User Guide 802.1X Authentication | 293
Application Single Sign-On Using L2 Authentication
This feature allows single sign-on (SSO) for different web-based applications using Layer 2 authentication information. Single sign-on for web-based application uses Security Assertion Markup Language (SAML), which happens between the web service provider and an identity provider (IDP) that the web server trusts. A request made from the client to a web server is redirected to the IDP for authentication. If the user has already been authenticated using L2 credentials, the IDP server already knows the authentication details and returns a SAML response, redirecting the client browser to the web-based application. The user enters the web-based application without needing to enter the credentials again.
Enabling application SSO using L2 network information requires configuration on the controller and on the IDP server. The Aruba ClearPass Policy Manager (CPPM) is the only IDP supported. The controller has been optimized to work with CPPM to provide better functionality as an IDP.
Important Points to Remember
n n n n
CPPM is the only supported IDP.
SSO occurs after 802.1X authentication. Therefore, SSO after captive portal authentication is not supported. Roles for captive portal and SSO are mutually exclusive and, therefore, a user in the captive portal role cannot perform SSO and vice-versa.
SSO with VIA is not supported.
There is a limit on the number of concurrent sessions that can be serviced at a given instant. This limit is set at the webserver level using the web-server profile web-max-clients command. The default value is 320 for 7000 Series and 7200 Series controllers platforms and 25 for other controller platforms. The maximum number of concurrent SSO sessions that can be handled is dependent on the other web services being handled and the same time.
Enabling Application SSO
Enabling application SSO using L2 authentication information requires configuration on the controller and
CPPM. This feature is enabled by completing the following steps: n n
Controller: l
Configuring an SSO-IDP Profile l
Applying an SSO Profile to a User Role l
Selecting an IDP Certificate
CPPM (refer to the ClearPass Policy Manager for configuration of the following procedures): l l l l l l l l l
Add the controller’s IP address as a network device
Add the user to the local user DB
Create an enforcement profile to return the Aruba vendor-specific attribute (VSA) SSO token
Create an IDP attribute enforcement profile
Create an enforcement policy binding the Aruba VSA SSO token enforcement profile
Create an enforcement policy binding the IDP enforcement profile
Create a service, allowing the respective authentication types and authentication database, and bind the
Aruba VSA SSO token enforcement policy.
Create a service, allowing the respective authentication types and authentication database, and bind the
IDP enforcement policy.
Configure SSO for the CPPM.
294 | 802.1X Authentication ArubaOS 6.5.3.x | User Guide
Configuring SSO IDP-Profiles
Before SSO can be enabled, you must configure an SSO profile by completing the procedure detailed below.
In the WebUI
1. Navigate to Configuration > Advanced Services > All Profiles > Wireless LANs > SSO .
2. Enter the name of the SSO profile and click Add .
3. Click on the name of the IDP profile in the Instance list to edit the profile.
4. Click New .
5. Enter the name of the IDP URL in the URL Name text box.
6. Enter the IDP URL into the URL text box.
7. Click Add .
8. Repeat steps 4 through 7 for each IDP URL you are adding to the SSO profile.
9. Click Apply when all URLs have been added.
In the CLI sso idp-profile <idp profile name> idp <urlname> <url>
Applying an SSO Profile to a User Role
The newly created SSO profile must be applied to any applicable user rules that require SSO. Apply the SSO profile be completing the steps below.
In the WebUI
1. Navigate to Configuration > Security > Access Control .
2. Select the User Roles tab.
3. Select the User Role that the SSO profile will be linked to and click Edit .
4. Under Misc. Configuration , select an IDP profile from the idp profile name drop-down menu.
5. Click Apply .
In the CLI user-role <role name> sso <idp profile name>
Selecting an IDP Certificate
An SSL certificate is needed for SSL negotiation with browser. The certificate can be imported in PKCS12 format, so that it contains the certificate and private key, or the key pair can be generated and a certificate signing request (CSR) request sent to the enterprise CA server to generate a certificate which can then be uploaded to the controller.
For information about uploading or generating a certificate, see
.
After a certificate is uploaded or generated, the IDP certificate must be selected.
In the WebUI
1. Navigate to Configuration > Management > General .
2. Under IDP Server Certificate , select the IDP certificate from the Server Certificate drop-down menu.
3. Click Apply .
ArubaOS 6.5.3.x
| User Guide 802.1X Authentication | 295
In the CLI
(host)(config) #web-server profile
(host)(Web Server Configuration) #idp-cert <name of the certificate>
Device Name as User Name for Non-802.1X Authentication
When a client is authenticated by non-802.1X method of authentication, the host name of the host device is used as the user name (instead of the MAC address) of the host device. When a host device tries to obtain an IP address by using DHCP, the host name of the host device in the option-12 field of DHCP request is used as the host name of the host device.
A CLI command allows the use of the host name or the MAC address of a host device as the user name of the host device. By default, the MAC address of the host device is used as the user name. If the CLI command is enabled, the host name of the host device is used as the user name.
Using Device Name as User Name
In the CLI
(host) (config) #aaa profile <profile>
(host) (AAA Profile “<profile >”) #username-from-dhcp-opt12
296 | 802.1X Authentication ArubaOS 6.5.3.x | User Guide
Chapter 13
Stateful and WISPr Authentication
ArubaOS supports stateful 802.1X authentication, stateful NTLM authentication, and authentication for
Wireless Internet Service Provider roaming (WISPr). Stateful authentication differs from 802.1X authentication in that the controller does not manage the authentication process directly, but instead monitors the authentication messages between a user and an external authentication server, then assigns a role to that user based upon the information in those authentication messages. WISPr authentication allows clients to roam between hotspots using different ISPs.
This chapter describes the following topics: n n n n n n n
Working With Stateful Authentication on page 297
Working With WISPr Authentication on page 298
Understanding Stateful Authentication Best Practices on page 298
Configuring Stateful 802.1X Authentication on page 298
Configuring Stateful NTLM Authentication on page 299
Configuring Stateful Kerberos Authentication on page 300
Configuring WISPr Authentication on page 301
n n n
Working With Stateful Authentication
ArubaOS supports three different types of stateful authentication:
Stateful 802.1X authentication : This feature allows the controller to learn the identity and role of a user connected to a third-party AP, and is useful for authenticating users to networks with APs from multiple vendors. When an 802.1X-capable access point sends an authentication request to a RADIUS server, the controller inspects this request and the associated response to learn the authentication state of the user. It then applies an identity-based user-role through the Policy Enforcement Firewall.
Stateful Kerberos authentication : Stateful Kerberos authentication configures a controller to monitor the Kerberos authentication messages between a client and a Windows authentication server. If the client successfully authenticates via a Kerberos authentication server, the controller recognizes that the client has been authenticated and assigns that client a specified user role.
Stateful NTLM authentication : NT LAN Manager (NTLM) is a suite of Microsoft authentication and session security protocols. You can use stateful NTLM authentication to configure a controller to monitor the NTLM authentication messages between a client and a Windows authentication server. If the client successfully authenticates via an NTLM authentication server, the controller recognizes that the client has been authenticated and assigns that client a specified user role.
The default Windows authentication method has changed from the older NTLM protocol to the newer
Kerberos protocol, starting with Windows 2000. Therefore, stateful NTLM authentication is most useful for networks with legacy, pre-Windows 2000 clients. Also note that unlike other types of authentication, all users authenticated via stateful NTLM authentication must be assigned to the user role specified in the
Stateful NTLM Authentication profile. Aruba’s stateful NTLM authentication does not support placing users in various roles based upon group membership or other role-derivation attributes.
ArubaOS 6.5.3.x
| User Guide Stateful and WISPr Authentication | 297
n n n n n
Working With WISPr Authentication
WISPr authentication allows a “smart client” to authenticate to the network when roaming between Wireless
Internet Service Providers, even if the wireless hotspot uses an ISP, which the client may not have an account for.
If you are a hotspot operator using WISPr authentication, and a client that has an account with your ISP attempts to access the Internet at your hotspot, your ISP’s WISPr AAA server authenticates that client directly and allows the client to access the network. If, however, the client only has an account with a partner ISP, your
ISP’s WISPr AAA server forwards that client’s credentials to the partner ISP’s WISPr AAA server for authentication. Once the client has been authenticated on the partner ISP, it is authenticated on your hotspot’s own ISP, as per their service agreements. After your ISP sends an authentication message to the controller, the controller assigns the default WISPr user-role to that client.
ArubaOS supports the following smart clients, which enable client authentication and roaming between hotspots by embedding iPass Generic Interface Specification (GIS) redirect , proxy , authentication , and logoff messages within HTML messages to the controller.
iPass
Boingo
Trustive weRoam
AT&T
Understanding Stateful Authentication Best Practices
Before you can configure a stateful authentication feature, you must define a user-role you want to assign to the authenticated users and create a server group that includes a RADIUS authentication server for stateful
802.1X authentication or a Windows server for stateful NTLM authentication. For details on performing these tasks, refer to the following sections of this User Guide: n n n n
Roles and Policies on page 381
Configuring a RADIUS Server on page 180
Configuring a Windows Server on page 198
Configuring Server Groups on page 201
You can use the default stateful NTLM authentication and WISPr authentication profiles to manage the settings for these features, or you can create additional profiles as desired. Note that unlike most other types of authentication, stateful 802.lx authentication uses only a single Stateful 802.1X profile. This profile can be enabled or disabled, but you cannot configure more than one Stateful 802.1X profile.
Configuring Stateful 802.1X Authentication
When you configure 802.1X authentication for clients on non-Aruba APs, you must specify the group of
RADIUS servers that performs the user authentication and select the role to assign to users who successfully complete authentication. When the user logs off or shuts down the client machine, ArubaOS notes the deauthentication message from the RADIUS server and changes the user’s role from the specified authenticated role back to the login role. For details on defining a RADIUS server used for stateful 802.1X
authentication, see
Configuring a RADIUS Server on page 180
.
In the WebUI
To configure the Stateful 802.1X Authentication profile via the WebUI:
298 | Stateful and WISPr Authentication ArubaOS 6.5.3.x | User Guide
1. Navigate to the Configuration > Security > Authentication > L2 Authentication page.
2. In the Profiles list, select Stateful 802.1X Authentication Profile .
3. Click the Default Role drop-down list, and select the role assigned to stateful 802.1X authenticated users.
4. Specify the timeout period for authentication requests, between 1 and 20 seconds. The default value is 10 seconds.
5. Select the Mode checkbox to enable stateful 802.1X authentication.
In the CLI
Use the commands below to configure stateful 802.1X authentication via the command-line interface. The first set of commands defines the RADIUS server used for 802.1X authentication, and the second set assigns that server to a server group. The third set associates the server group with the stateful 802.1X authentication profile, then sets the authentication role and timeout period.
(host)(config)# aaa authentication-server radius <server-name> acctport <port> authport <port> clone <server> enable host <ipaddr> key <psk> nas-identifier <string> nas-ip <ipaddr> retransmit <number> timeout <seconds> use-md5
!
(host)(config)# aaa server-group group <server-group> auth-server <server-name>
!
(host)(config)# aaa authentication stateful-dot1x server-group <server-group> default-role <role> enable timeout <seconds>
Configuring Stateful NTLM Authentication
The Stateful NTLM Authentication profile requires that you specify a server group, which includes the servers performing NTLM authentication, and the role to be assigned to users who are successfully authenticated. For details on defining a windows server used for NTLM authentication, see
Configuring a Windows Server on page
.
When the user logs off or shuts down the client machine, the user remains in the authenticated role until the user ages out, meaning there is no user traffic for the amount of time specified in the User Idle Timeout setting in the Configuration > Security > Authentication > Advanced page.
In the WebUI
To create and configure a new instance of a stateful NTLM authentication profile via the WebUI:
1. Navigate to the Configuration > Security > Authentication > L3 Authentication page.
2. In the Profiles list, expand the Stateful NTLM Authentication Profile .
3. To define settings for an existing profile, click that profile name in the profiles list.
ArubaOS 6.5.3.x
| User Guide Stateful and WISPr Authentication | 299
To create and define settings for a Stateful NTLM Authentication profile, select an existing profile, then click
Save As in the right window pane. Enter a name for the new profile in the entry field at the top of the right window pane.
4. Click the Default Role drop-down list, and select the role to be assigned to all users after they complete stateful NTLM authentication.
5. Specify the timeout period for authentication requests, between 1 and 20 seconds. The default value is 10 seconds.
6. Select the Mode checkbox to enable stateful NTLM authentication.
7. Click Apply .
8. In the Profiles list, select the Server Group entry below the Stateful NTLM Authentication profile.
9. Click the Server Group drop-down list and select the group of Windows servers you want to use for stateful NTLM authentication.
10.Click
Apply .
In the CLI
Use the commands below to configure stateful NTLM authentication via the command-line interface. The first set of commands defines the Windows server used for NTLM authentication, and the second set adds that server to a server group. The third set associates that server group with the stateful NTLM authentication profile, then defines the profile settings.
(host)(config)# aaa authentication-server windows <windows_server_name> host <ipaddr> enable
!
(host)(config)# aaa server-group group <server-group> auth-server <windows_server_name>
!
(host)(config)# aaa authentication stateful-ntlm default-role <role> enable server-group <server-group> timeout <seconds>
Configuring Stateful Kerberos Authentication
The Stateful Kerberos Authentication profile requires that you specify a server group, which includes the
Kerberos servers and the role assigned to authenticated users. For details on defining a windows server used for Kerberos authentication, see
Configuring a Windows Server on page 198 .
When the user logs off or shuts down the client machine, the user remains in the authenticated role until the user ages out, meaning there is no user traffic for the amount of time specified in the User Idle Timeout setting in the Configuration > Security > Authentication > Advanced page.
In the WebUI
To create and configure a new stateful Kerberos authentication profile via the WebUI:
1. Navigate to the Configuration > Security > Authentication > L3 Authentication page.
2. In the Profiles list, expand the Stateful Kerberos Authentication Profile .
3. To define settings for an existing profile, click the profile name in the Profiles list.
300 | Stateful and WISPr Authentication ArubaOS 6.5.3.x | User Guide
To create and define settings for a new Stateful Kerberos Authentication profile, select an existing profile, then click Save As in the right window pane. Enter a name for the new profile in the entry field at the top of the right window pane.
4. Click the Default Role drop-down list, and select the role to be assigned to all users after they complete stateful Kerberos authentication.
5. Specify the timeout period for authentication requests, from 1-20 seconds. The default value is 10 seconds.
6. Click Apply .
7. In the Profiles list, select the Server Group entry below the Stateful Kerberos Authentication profile.
8. Click the Server Group drop-down list and select the group of Windows servers you want to use for stateful Kerberos authentication.
9. Click Apply.
In the CLI
Use the commands below to configure stateful Kerberos authentication via the command-line interface. The first set of commands defines the server used for Kerberos authentication, and the second set adds that server to a server group, and the third set of commands associates that server group with the stateful NTLM authentication profile then defines the profile settings.
(host)(config)# aaa authentication-server windows <windows_server_name> host <ipaddr> enable
(host)(config)# aaa server-group group <server-group> auth-server <windows_server_name>
(host)(config)# aaa authentication stateful-kerberos default-role <role> enable server-group <server-group> timeout <seconds>
Configuring WISPr Authentication
The WISPr authentication profile includes parameters to define RADIUS attributes, default roles for authenticated WISPr users, the maximum number of authentication failures, and login wait times. The WISPr-
Location-ID, sent from the controller to the WISPr RADIUS server, is the concatenation of the ISO Country
Code, E.164 Country Code, E.164 Area Code, and SSID/Zone parameters configured in this profile.
The parameters used to define WISPr RADIUS attributes are specific to the RADIUS server your ISP uses for
WISPr authentication; contact your ISP to determine these values. You can find a list of ISO and ITU country and area codes at the ISO and ITU websites ( www.iso.org
) and http://www.itu.int
.)
In the WebUI
To create and configure a new WISPr authentication profile in the WebUI:
1. Navigate to the Configuration > Security > Authentication > L3 Authentication page.
2. In the Profiles list, expand the WISPr Authentication Profile .
3. To define settings for an existing profile, click that profile name in the Profiles list.
To create and define settings for a new WISPr Authentication profile, select an existing profile, then click
Save As in the right window pane. Enter a name for the new profile in the entry field. at the top of the right window pane.
4. Define values for the parameters below.
ArubaOS 6.5.3.x
| User Guide Stateful and WISPr Authentication | 301
Table 77: WISPr Authentication Profile Parameters
Parameter Description
Default Role
Logon wait minimum wait
Default role assigned to users that complete WISPr authentication.
If the controller’s CPU utilization has surpassed the Login wait CPU utilization threshold value , the Logon wait minimum wait parameter defines the minimum number of seconds a user has to wait to retry a login attempt. Range: 1–10 seconds. Default: 5 seconds.
Logon wait maximum wait
Logon wait CPU utilization threshold
WISPr Location-ID ISO Country
Code
If the controller’s CPU utilization has surpassed the Login wait
CPUutilization threshold value, the Logon wait maximum wait parameter defines the maximum number of seconds a user has to wait to retry a login attempt. Range: 1–10 seconds. Default: 10 seconds.
Percentage of CPU utilization at which the maximum and minimum login wait times are enforced. Range: 1–100%. Default: 60%.
The ISO Country Code section of the WISPr Location ID.
WISPr Location-ID E.164 Country
Code
The E.164 Country Code section of the WISPr Location ID.
WISPr Location-ID E.164 Area Code The E.164 Area Code section of the WISPr Location ID.
WISPr Location-ID SSID/Zone
WISPr Operator Name
WISPr Location Name
The SSID/Zone section of the WISPr Location ID.
A name identifying the hotspot operator.
A name identifying the hotspot location. If no name is defined, the parameter uses the name of the associated AP.
5. Click Apply .
6. In the Profiles list, select the Server Group entry below the WISPr Authentication profile.
7. Click the Server Group drop-down list and select the group of RADIUS servers you want to use for WISPr authentication.
8. Click Apply .
A Boingo smart client uses a NAS identifier in the format <CarrierID>_<VenueID> for location identification. To support Boingo clients, you must also configure the NAS identifier parameter in the Radius server profile for the
WISPr server
In the CLI
Use the CLI commands below to configure WISPr authentication. The first set of commands defines the
RADIUS server used for WISPr authentication, and the second set adds that server to a server group. The third set of commands associates that server group with the WISPR authentication profile, then defines the profile settings.
(host)(config)# aaa authentication-server radius <rad_server_name> host 172.4.77.214
key qwERtyuIOp enable nas-identifier corp_venue1
!
302 | Stateful and WISPr Authentication ArubaOS 6.5.3.x | User Guide
(host)(config)# aaa server-group group <server-group> auth-server <radius_server_name>
!
(host)(config)# aaa authentication wispr default-role <role> logon-wait {cpu-threshold|maximum-delay|minimum-delay} server-group <server-group> wispr-location-id-ac <wispr-location-id-ac> wispr-location-id-cc <wispr-location-id-cc> wispr-location-id-isocc <wispr-location-id-isocc> wispr-location-id-network <wispr-location-id-network> wispr-location-name-location <wispr-location-name-location> wispr-location-name-operator-name <wispr-location-name-location>
ArubaOS 6.5.3.x
| User Guide Stateful and WISPr Authentication | 303
Chapter 14
Certificate Revocation
The Certificate Revocation feature enables the controller to perform real-time certificate revocation checks using the Online Certificate Status Protocol (OCSP), or traditional certificate validation using the Certificate
Revocation List (CRL) client.
Topics in this chapter include: n n n n n n
Understanding OCSP and CRL on page 304
Configuring the Controller as a CRL Client on page 307
Configuring the Controller as an OCSP Responder on page 308
Configuring the Controller as an OCSP Client on page 305
Certificate Revocation Checking for SSH Pubkey Authentication on page 309
Understanding OCSP and CRL
OCSP (RFC 2560) is a standard protocol that consists of an OCSP client and an OCSP responder. This protocol determines revocation status of a given digital public-key certificate without downloading the entire CRL.
CRL is the traditional method of checking certificate validity. A CRL provides a list of certificate serial numbers that have been revoked or are no longer valid. CRLs let the verifier check the revocation status of the presented certificate while verifying it. CRLs are limited to 512 entries.
Both the Delegated Trust Model and the Direct Trust Model are supported to verify digitally signed OCSP responses. Unlike the Direct Trust Model, the Delegated Trust Model does not require the OCSP responder certificates to be explicitly available on the controller.
Configuring a Controller as OCSP and CRL Clients
The controller can act as an OCSP client and issue OCSP queries to remote OCSP responders located on the intranet or Internet. Since many applications in ArubaOS (such as IKE), use digital certificates, a protocol such as
OCSP needs to be implemented for revocation.
An entity that relies on the content of a certificate (a relying party) needs to check before accepting the certificate as valid. Once it is verified that the certificate has not been revoked, the OCSP client retrieves certificate revocation status from an OCSP responder. The responder may be the CA (Certificate Authority) that has issued the certificate in question, or it may be some other designated entity which provides the service on behalf of the CA. A revocation checkpoint is a logical profile that is tied to each CA certificate that the controller has (trusted or intermediate). Also, the user can specify revocation preferences within each profile.
The OCSP request is not signed by the Aruba OCSP client at this time. However, the OCSP response is always signed by the responder.
Both OCSP and CRL configuration and administration is usually performed by the administrator who manages the web access policy for an organization.
In small networks where there are is no Internet connection or connection to an OCSP responder, CRL is preferable to than OCSP.
ArubaOS 6.5.3.x
| User Guide Certificate Revocation | 304
Configuring an OCSP Controller as a Responder
The controller can be configured to act as an OCSP responder (server) and respond to OCSP queries from clients that want to obtain revocation status of certificates.
The OCSP responder on the controller is accessible over HTTP port 8084. You cannot configure this port.
Although the OCSP responder accepts signed OCSP requests, it does not attempt to verify the signature before processing the request. Therefore, even unsigned OCSP requests are supported.
The controller as an OCSP responder provides revocation status information to Aruba applications that use
CRLs. This is useful in small disconnected networks where clients cannot reach outside OCSP server to validate certificates. Typical scenarios include client to client or client to other server communication situations where the certificates of either party need to be validated.
Configuring the Controller as an OCSP Client
When OCSP is used as the revocation method, you need to configure the OCSP responder certificate and the
OCSP URL.
In the WebUI
1. Navigate to the Configuration > Management > Certificates > Upload page .
2. Enter a name in the Certificate Name field. This name identifies the certificate you are uploading.
3. Enter the certificate file name in the Certificate Filename field. Use the Browse button to enter the full pathname.
4. Select the certificate format from the Certificate Format drop-down menu.
5. Select OCSP Responder Cert from the Certificate Type drop-down menu.
A revocation check method (OCSP or CRL) can be chosen independently for every revocation checkpoint. In this example, we are only describing the OCSP check method.
Once this certificate is uploaded it is maintained in the certificate store for OCSP responder certificates.
These certificates are used for signature verification.
305 | Certificate Revocation ArubaOS 6.5.3.x | User Guide
Figure 49 Upload a certificate
6. Click Upload . The certificate appears in the Certificate Lists pane.
7. For detailed information about an uploaded certificate, click View next to the certificate.
Figure 50 View certificate details
8. Select the Revocation Checkpoint tab.
ArubaOS 6.5.3.x
| User Guide Certificate Revocation | 306
9. In the Revocation Checkpoint pane, click Edit next to the revocation checkpoint that you want to configure. The Revocation Checkpoint pane displays.
10.In the Revocation Check field, select ocsp from the Method 1 drop-down list as the primary check method.
11.In the OCSP URL field, enter the URL of the OCSP responder.
12.In the OCSP Responder Cert field, select the OCSP certificate you want to configure from the drop-down menu.
13.Click
Apply .
In the CLI
This example configures an OCSP client with the revocation check method as OCSP for revocation check point
CAroot.
The OCSP responder certificate is configured as RootCA-Ocsp_responder. The corresponding OCSP responder service is available at http://10.4.46.202/ocsp
. The check method is OCSP for revocation check point
CARoot.
(host) (config) #crypto-local pki rcp CARoot
(host) (RCP-CARoot) #ocsp-responder-cert RootCA-Ocsp_responder
(host) (RCP-CARoot) #ocsp-url http://10.4.46.202/ocsp
(host) (RCP-CARoot) #revocation-check ocsp
The show crypto-local pki OCSP ResponderCert
CLI command lists the contents of the OCSP Responder
Certificate store.
The show crypto-local pki revocation checkpoint rcp_name
CLI command shows the entire configuration for a given revocation checkpoint.
Configuring the Controller as a CRL Client
CRL is the traditional method of checking certificate validity. When you want to check certificate validity using a
CRL, import the CRL. You can import CRLs only through the WebUI.
In the WebUI
1. Navigate to the Configuration > Management > Certificates > Upload page .
2. Enter a name in the Certificate Name field. This name identifies the CRL certificate you are uploading.
3. Enter the certificate file name in the Certificate Filename field. Use Browse to enter the full pathname.
4. Select the certificate format from the Certificate Format drop-down menu.
5. Select CRL from the Certificate Type drop-down menu.
A revocation check method (OCSP or CRL) can be chosen independently for every revocation checkpoint. In this example, we are only describing the CRL check method.
Once this CRL is uploaded it is maintained in the store for CRLs. These CRLs are used for signature verification.
6. Click Upload . The CRL appears in the Certificate Lists pane. Select CRL from the Group drop-down list if you want to display only CRLs.
7. For detailed information about an uploaded CRL, click View next to the CRL.
8. Select the Revocation Checkpoint tab.
9. In the Revocation Checkpoint pane, click Edit next to the revocation checkpoint that you want to configure. The Revocation Checkpoint pane displays.
307 | Certificate Revocation ArubaOS 6.5.3.x | User Guide
10.In the Revocation Check field, select crl from the Method 1 drop-down list.
11.In the CRL Location field, enter the CRL you want to use for this revocation checkpoint. The CRLs listed are files that have already been imported onto the controller.
12.Click
Apply .
In the CLI
This example configures an OCSP responder with the check method as CRL for revocation check point ROOTCassh-webui. The CRL location is crl1 and the revocation check method is crl.
(host) (config) #crypto-local pki rcp ROOTCa-ssh-webui
(host) (RCP-CARoot) #crl-location file crl1
(host) (RCP-CARoot) #revocation-check crl
Configuring the Controller as an OCSP Responder
When configured as an OCSP responder, the controller provides revocation status information to ArubaOS applications that use CRLs.
In the WebUI
1. Navigate to the Configuration > Management > Certificates > Upload page .
2. Enter a name in the Certificate Name field. This name identifies the OCSP signer certificate you are uploading.
3. Enter the certificate file name in the Certificate Filename field. Use Browse to enter the full pathname.
4. Select the certificate format from the Certificate Format drop-down menu.
5. Select OCSP signer cert from the Certificate Type drop-down menu. Once this certificate is uploaded, it is maintained in the certificate store for OCSP signer certificates. These certificates are used for signature verification.
The OCSP signer cert signs OCSP responses for this revocation check point. The OCSP signer cert can be the same trusted CA as the check point, a designated OCSP signer certificate issued by the same CA as the check point or some other local trusted authority.
If you do not specify an OCSP signer cert, OCSP responses are signed using the global OCSP signer certificate. If that is not present, than an error message is sent out to clients.
The OCSP signer certificate takes precedence over the global OCSP signer certificate as it is check point specific.
6. Click Upload . The certificate appears in the Certificate Lists pane. Select OCSP signer cert from the Group drop-down list if you want to display only those certificates which are OCSP signer certificates.
7. For detailed information about an uploaded certificate, click View next to the certificate.
8. Select the Revocation Checkpoint tab.
9. Select Enable next to Enable OCSP Responder .
Enable OCSP Responder is a global knob that turns the OCSP responder service on or off on the controller.
The default is disabled (off). Enabling this option automatically adds the OCSP responder port (TCP 8084) to the permit list in the CP firewall so this can be accessed from outside the controller.
10.Select the OCSP signer cert from the OCSP Certificates drop-down menu to be used to sign OCSP responses for this revocation check point.
11.In the Revocation Checkpoint pane, click Edit next to the revocation checkpoint that you want to configure. The Revocation Checkpoint pane displays.
ArubaOS 6.5.3.x
| User Guide Certificate Revocation | 308
12.In the Revocation Check field, optionally select a check method from the Method 1 drop-down list.
Optionally, select a backup check method from the Method 2 drop-down list.
13.Select
Enable next to Enable OCSP Responder .
14.Select
OCSP signer cert from the OCSP Signer Cert drop-down menu.
15.In the CRL Location field, enter the CRL you want used for this revocation checkpoint. The CRLs listed are files that have already been imported onto the controller.
16.Click
Apply .
In the CLI
This example configures the controller as an OCSP responder. The OCSP responder service is enabled, the revocation check point is CAroot, the OCSP signer cert is “oscap_CA1,” and the CRL file location is “Sec1-WIN-
05PRGNGEKAO-CA-unrevoked.crl.”
(host) (config) #crypto-local pki service-ocsp-responder
(host) (config) #crypto-local pki rcp CAroot
(host) (CAroot) #ocsp-signer-cert oscsp_CA1
(host) (CAroot) #crl-location file Sec1-WIN-05PRGNGEKAO-CA-unrevoked.crl
(host) (CAroot) #enable-ocsp-responder
Certificate Revocation Checking for SSH Pubkey Authentication
This feature allows the ssh-pubkey management user to be optionally configured with a Revocation
Checkpoint (RCP). This meets the requirement for a two-factor authentication and integration of device management with PKI for SSH pubkey authentication. The ArubaOS implementation of SSH using Pubkey authentication is designed for integration with smart cards or other technologies that use X.509 certificates.
The RCP checks the revocation status of the SSH user’s client certificate before permitting access. If the revocation check fails, the user is denied access using the ssh-pubkey authentication method. However, the user can still authenticate through a username and password if configured to do so.
For information about configuring a revocation checkpoint, see
.
Configuring the SSH Pubkey User with RCP
You can configure the SSH pubkey user with RCP to check the validity of the user’s x.509 certificate.
In the WebUI
1. Navigate to Configuration > Management > Administration .
2. Under Management Users , click Add . The Add User page displays.
3. Select Certificate Management , then SSH Public Key .
4. When adding an ssh-pubkey user, when revocation check is enabled, perform either of the following tasks : n
To enable the RCP check, select a valid configured RCP from Revocation Checkpoint drop-down menu.
n
Select None if you do not want the RCP check enabled for the ssh pubkey user.
In the CLI
The CLI allows you to configure an optional RCP for an ssh-pubkey user. Users can still be configured without the RCP. In this example, the certificate name is
“client1-rg,”, the username is “test1,” the role name is “root,” and the rcp is “ca-rg:”
(host)(config) #mgmt-user ssh-pubkey client-cert client1-rg test1 root ?
rcp Revocation Checkpoint for ssh user's client certificate
(host)(config) #mgmt-user ssh-pubkey client-cert client1-rg test1 root rcp ca-rg
309 | Certificate Revocation ArubaOS 6.5.3.x | User Guide
In this example, a user is configured without the RCP:
(host)(config) #mgmt-user ssh-pubkey client-cert client2-rg test2 root
Displaying Revocation Checkpoint for the SSH Pubkey User
The RCP checks the revocation status of the SSH user’s client certificate before permitting access. If the revocation check fails, the user is denied access using the ssh-pubkey authentication method. However, the user can still authenticate through a username and password if configured to do so. This feature allows the ssh-pubkey management user to be optionally configured with a Revocation Checkpoint (RCP). This meets the requirement for a two-factor authentication and integration of device management with PKI for SSH pubkey authentication. The ArubaOS implementation of SSH using Pubkey authentication is designed for integration with smart cards or other technologies that use X.50.
Configuring the SSH Pubkey User with RCP
The column REVOCATION CHECKPOINT displays the configured RCP for the ssh-pubkey user. If no RCP is configured for the user, the word none is displayed.
In the WebUI
Navigate to Configuration > Management > Administration .
The column SSH Revocation Checkpoint displays the RCP configured (if any) for the ssh pubkey user.
In the CLI
(host)#show mgmt-user ssh-pubkey
Removing the SSH Pubkey User
In the WebUI
1. Navigate to Configuration > Management > Administration .
2. Click Delete next to the management user you want to delete.
In the CLI
(host) (config) #no mgmt-user ssh-pubkey client-cert <certname> <username>
OCSP Configuration for VIA
In ArubaOS 6.5, the OCSP configuration for VIA is simplified with the following configuration parameters removed: n n n n ocsp-responder ike-url (OCSP responder's URL for IKE) ocsp-responder eap-url (OCSP responder's URL for EAP) ocsp-responder ike-cn (OCSP responder's CN for IKE) ocsp-responder eap-cn (OCSP responder's CN for EAP)
These parameters will be picked up directly from the certificate. The WebUI path and the CLI command to enable OCSP certificate verification are as follows.
In the WebUI
To enable the OCSP certificate verification in the WebUI, perform the following steps:
1. Navigate to Configuration > Advanced Services > All Profiles .
ArubaOS 6.5.3.x
| User Guide Certificate Revocation | 310
2. In the Profiles section (left pane) of the All Profile Management page, click Other Profiles > VIA
Connection > Default.
3. In the Profiles Details section (right pane), select the OCSP Cert verification enabled check box.
In the CLI
To enable the OCSP certificate verification, the ocsp-responder enable subcommand is introduced in the aaa authentication via connection-profile <name> command. It is disabled by default.
You can disable the OCSP certificate verification using the no ocsp-responder enable sub-command.
Example Configuration
(host) (config) #aaa authentication via connection-profile default
(host) (VIA Connection Profile "default") # ocsp-responder enable
Example Verification
The following show command helps view the status of OCSP configuration :
(host) (VIA Connection Profile "default") #show aaa authentication via connection-profile default
VIA Connection Profile "default"
--------------------------------
Parameter
---------
VIA Servers
Client Auto-Login
Value
-----
N/A
Enabled
N/A
.
.
VIA Authentication Profiles to provision
.
.
.
OCSP Cert verification enabled
.
User idle timeout
Disable
N/A
311 | Certificate Revocation ArubaOS 6.5.3.x | User Guide
Chapter 15
Captive Portal Authentication
Captive portal is one of the methods of authentication supported by ArubaOS. A captive portal presents a web page which requires user action before network access is granted. The required action can be simply viewing and agreeing to an acceptable use policy, or entering a user ID and password which must be validated against a database of authorized users.
You can also configure captive portal to allow clients to download the Aruba VPN dialer for Microsoft VPN clients if the VPN is to be terminated on the controller. For more information about the VPN dialer, see
Private Networks on page 352 .
Topics in this chapter include: n n n n n n n n n n n
Understanding Captive Portal on page 312
Configuring Captive Portal in the Base Operating System on page 313
Using Captive Portal with a PEFNG License on page 315
Sample Authentication with Captive Portal on page 318
Configuring Guest VLANs on page 324
Configuring Captive Portal Authentication Profiles on page 325
Enabling Optional Captive Portal Configurations on page 330
Personalizing the Captive Portal Page on page 333
Creating and Installing an Internal Captive Portal on page 336
Creating Walled Garden Access on page 346
Enabling Captive Portal Enhancements
Understanding Captive Portal
You can configure captive portal for guest users, where no authentication is required, or for registered users who must be authenticated against an external server or the controller’s internal database.
While you can use captive portal to authenticate users, it does not provide for encryption of user data and should not be used in networks where data security is required. Captive portal is most often used for guest access, access to open systems (such as public hot spots), or as a way to connect to a VPN.
You can use captive portal for guest and registered users at the same time. The default captive portal web page provided with ArubaOS displays login prompts for both registered users and guests. (You can customize the default captive portal page, as described in
Personalizing the Captive Portal Page on page 333 )
You can also load up to 16 different customized login pages into the controller. The login page displayed is based on the SSID to which the client associates.
Policy Enforcement Firewall Next Generation (PEFNG) License
You can use captive portal with or without the PEFNG license installed in the controller. The PEFNG license provides identity-based security to wired and wireless clients through user roles and firewall rules. You must purchase and install the PEFNG license on the controller to use identity-based security features.
ArubaOS 6.5.3.x
| User Guide Captive Portal Authentication | 312
There are differences in how captive portal functions work and how you configure captive portal, depending on whether the license is installed. Other parts of this chapter describe how to configure captive portal in the base operating system (without the PEFNG license) and with the license installed.
Controller Server Certificate
The Aruba controller is designed to provide secure services through the use of digital certificates. A server certificate installed in the controller verifies the authenticity of the controller for captive portal.
Aruba controllers ship with a demonstration digital certificate. Until you install a customer-specific server certificate in the controller, this demonstration certificate is used by default for all secure HTTP connections such as captive portal. This certificate is included primarily for the purposes of feature demonstration and convenience and is not intended for long-term use in production networks. Users in a production environment are urged to obtain and install a certificate issued for their site or domain by a well-known certificate authority
(CA). You can generate a Certificate Signing Request (CSR) on the controller to submit to a CA. For information on how to generate a CSR and how to import the CA-signed certificate into the controller, see
in
Management Access on page 844 .
The controller can accept wild card server certificates (CN begins with an asterisk). If a wildcard certificate is uploaded (for example, CN=*.domain.com), the asterisk in CN is replaced with 'captiveportal-login' in order to derive the Captive Portal logon page URL (captiveportal-login.domain.com).
Once you have imported a server certificate into the controller, you can select the certificate to be used with captive portal as described in the following sections.
To select a certificate for captive portal using the WebUI:
1. Navigate to the Configuration > Management > General page.
2. Under Captive Portal Certificate, select the name of the imported certificate from the drop-down list.
3. Click Apply .
To select a certificate for captive portal using the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #web-server profile
(host)(Web Server Configuration) #captive-portal-cert <certificate>
To specify a different server certificate for captive portal with the CLI, use the no command to revert back to the default certificate before you specify the new certificate:
(host)(config) #web-server profile
(host)(Web Server Configuration) #captive-portal-cert ServerCert1
(host)(Web Server Configuration) #no captive-portal-cert
(host)(Web Server Configuration) #captive-portal-cert ServerCert2
Configuring Captive Portal in the Base Operating System
The base operating system (ArubaOS without any licenses) allows full network access to all users who connect to an ESSID, both guest and registered users. In the base operating system, you cannot configure or customize user roles; this function is only available by installing the PEFNG license. Captive portal allows you to control or identify who has access to network resources.
When you create a captive portal profile in the base operating system, an implicit user role is automatically created with same name as the captive portal profile. This implicit user role allows only DNS and DHCP traffic between the client and network and directs all HTTP or HTTPS requests to the captive portal. You cannot directly modify the implicit user role or its rules. Upon authentication, captive portal clients are allowed full access to their assigned VLAN.
313 | Captive Portal Authentication ArubaOS 6.5.3.x | User Guide
The WLAN Wizard within the ArubaOS WebUI allows for basic captive portal configuration for WLANs associated with the “default” ap-group: Configuration > Wizards > WLAN Wizard . Follow the steps in the workflow pane within the wizard and refer to the help tab for assistance.
What follows are the tasks for configuring captive portal in the base ArubaOS. The example server group and profile names appear inside quotation marks.
n n n n n
Create the Server Group name. In this example, the server group name is “cp-srv”.
If you are configuring captive portal for registered users, configure the server(s) and create the server group. For more information about configuring authentication servers and server groups, see
Authentication Servers on page 179
.
Create Captive Portal Authentication Profile. In this example, the profile name is “c-portal”.
Create and configure an instance of the captive portal authentication profile. Creating the captive portal profile automatically creates an implicit user role and ACL with the same name. Creating the profile “cportal” creates an implicit user role called “c-portal”. That user role allows only DNS and DHCP traffic between the client and network and directs all HTTP or HTTPS requests to the captive portal.
Create an AAA Profile. In this example, the profile name is “aaa_c-portal”.
Create and configure an instance of the AAA profile. For the initial role, enter the implicit user role that was created in
. The initial role in the profile “aaa_c-portal” must be set to “c-portal”.
Create SSID Profile. In this example, the profile name is “ssid_c-portal”.
Create and configure an instance of the virtual AP profile which you apply to an AP group or AP name.
Specify the AAA profile you created in
Create a Virtual AP Profile. In this example, the profile name is “vp_c-portal”.
Create and configure an instance of the SSID profile for the virtual AP.
The following sections present the procedure for configuring the captive portal authentication profile, the AAA profile, and the virtual AP profile using the WebUI or the command line (CLI). Configuring the VLAN and authentication servers and server groups are described elsewhere in this document.
In ArubaOS 2.5.2 and later 2.5.x releases, captive portal users in the base operating system are placed into the predefined cpbase initial user role before authentication. The cpbase role is not supported in ArubaOS 3.x. You need to create new captive portal profiles in the base operating system, as described in this section, which automatically generates the required policies and roles.
In the WebUI
1. Navigate to the Configuration > Security > Authentication > L3 Authentication page. Select the
Captive Portal Authentication profile.
a. In the Captive Portal Authentication Profile Instance list, enter the name of the profile (for example, cportal ), then click Add.
b. Select the captive portal authentication profile you just created.
c. You can enable user login and/or guest login, and configure other captive portal profile parameters as described in
d. Click Apply .
2. To specify authentication servers, select Server Group under the captive portal authentication profile you just configured.
a. Select the server group (for example, cp-srv ) from the drop-down menu.
b. Click Apply.
3. Select the AAA Profiles tab.
ArubaOS 6.5.3.x
| User Guide Captive Portal Authentication | 314
a. In the AAA Profiles Summary, click Add to add a new profile. Enter the name of the profile (for example, aaa_c-portal ), then click Add .
b. Select the AAA profile you just created.
c. For Initial Role, select the captive portal authentication profile (for example, c-portal ) you created previously.
The Initial Role must be exactly the same as the name of the captive portal authentication profile you created.
d. Click Apply .
4. Navigate to the Configuration > Wireless > AP Configuration page. Select either the AP Group or AP
Specific tab. Click Edit for the applicable AP group name or AP name.
5. Under Profiles, select Wireless LAN, then select Virtual AP.
6. To create a new virtual AP profile, select NEW from the Add a profile drop-down menu. Enter the name for the virtual AP profile (for example, vp_c-portal ), then click Add .
a. In the Profile Details entry for the new virtual AP profile, select the AAA profile you previously created from the AAA Profile drop-down menu. A pop-up window displays the configured AAA profile parameters. Click Apply in the pop-up window.
b. From the SSID profile drop-down menu, select NEW. A pop-up window allows to you configure the SSID profile.
c. Enter the name for the SSID profile (for example, ssid_c-portal ).
d. Enter the Network Name for the SSID (for example, c-portal-ap ).
e. Click Apply in the pop-up window.
f. At the bottom of the Profile Details page, click Apply .
7. Click on the new virtual AP name in the Profiles list or in Profile Details to display configuration parameters.
a. Make sure Virtual AP enable is selected.
b. For VLAN, select the VLAN to which users are assigned (for example, 20 ).
c. Click Apply .
In the CLI
To configure captive portal in the base operating system via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #aaa authentication captive-portal c-portal server-group cp-srv
(host)(config) #aaa profile aaa_c-portal initial-role c-portal
(host)(config) #wlan ssid-profile ssid_c-portal essid c-portal-ap
(host)(config) #wlan virtual-ap vp_c-portal aaa-profile aaa_c-portal ssid-profile ssid_c-portal vlan 20
Using Captive Portal with a PEFNG License
The PEFNG license provides identity-based security for wired and wireless users. There are two user roles that are important for captive portal:
315 | Captive Portal Authentication ArubaOS 6.5.3.x | User Guide
n n
Default user role, which you specify in the captive portal authentication profile, is the role granted to clients upon captive portal authentication. This can be the predefined guest system role.
Initial user role, which you specify in the AAA profile, directs clients who associate to the SSID to captive portal whenever the user initiates a Web browser connection. This can be the predefined logon system role.
The captive portal authentication profile specifies the captive portal login page and other configurable parameters. The initial user role configuration must include the applicable captive portal authentication profile instance.
MAC-based authentication, if enabled on the controller, takes precedence over captive portal authentication.
The following are the basic tasks for configuring captive portal using role-based access provided by the Policy
Enforcement Firewall software module. Note that you must install the PEFNG license before proceeding (see
).
n n
Configure the user role for a default user.
Create and configure user roles and policies for guest or registered captive portal users. (See
for more information about configuring policies and user roles.)
Create a server group.
If you are configuring captive portal for registered users, configure the server(s) and create the server group. (See
Authentication Servers on page 179
for more information about configuring authentication servers and server groups.)
If you are using the controller’s internal database for user authentication, use the predefined “Internal” server group.
You need to configure entries in the internal database, as described in
Authentication Servers on page 179 .
n n n n n
Create the captive portal authentication profile.
Create and configure an instance of the captive portal authentication profile. Specify the default user role for captive portal users.
Configure the initial user role.
Create and configure the initial user role for captive portal. You need to include the predefined captiveportal policy, which directs clients to the captive portal, in the initial user role configuration.
You also need to specify the captive portal authentication profile instance in the initial user role configuration. For example, if you are using the predefined logon system role for the initial role, you need to edit the role to specify the captive portal authentication profile instance.
Create the AAA Profile.
Create and configure an instance of the AAA profile. Specify the initial user role.
Create the SSID Profile “ssid_c-portal”.
Create and configure an instance of the virtual AP profile that you apply to an AP group or AP name. Specify the AAA profile you just created.
Create the Virtual AP Profile “vp_c-portal”.
Create and configure an instance of the SSID profile for the virtual AP.
The following sections present the WebUI and Command Line (CLI) procedures for configuring the captive portal authentication profile, initial user role, the AAA profile, and the virtual AP profile. Other chapters within this document detail the configuration of the user roles and policies, authentication servers, and server groups.
Configuring Captive Portal in the WebUI
To configure captive portal with PEFNG license via the WebUI:
ArubaOS 6.5.3.x
| User Guide Captive Portal Authentication | 316
1. Navigate to the Configuration > Security > Authentication > L3 Authentication page.
2. Select Captive Portal Authentication Profile.
a. In the Captive Portal Authentication Profile Instance list, enter the name of the profile (for example, cportal ), then click Add .
b. Select the captive portal authentication profile you just created.
c. Select the default role (for example, employee ) for captive portal users.
d. Enable guest login and/or user login, as well as other parameters (refer to
).
e. Click Apply .
3. To specify the authentication servers, select Server Group under the captive portal authentication profile you just configured.
a. Select the server group (for example, cp-srv ) from the drop-down menu.
b. Click Apply.
4. Select the AAA Profiles tab.
a. In the AAA Profiles Summary, click Add to add a new profile. Enter the name of the profile (for example, aaa_c-portal ), then click Add .
b. Set the Initial role to a role that you will configure with the captive portal authentication profile.
c. Click Apply .
5. Navigate to the Configuration > Security > Access Control page to configure the initial user role to use captive portal authentication.
a. To edit the predefined logon role, select the System Roles tab, then click Edit for the logon role.
b. To configure a new role, first configure policy rules in the Policies tab, then select the User Roles tab to add a new user role and assign policies.
c. To specify the captive portal authentication profile, scroll down to the bottom of the page. Select the profile from the Captive Portal Profile drop-down menu, and click Change .
d. Click Apply .
6. Navigate to the Configuration > Wireless > AP Configuration page to configure the virtual AP profile.
7. Select either the AP Group or AP Specific tab. Click Edit for the applicable AP group name or AP name.
8. Under Profiles, select Wireless LAN, then select Virtual AP.
9. Select NEW from the Add a profile drop-down menu to create a new virtual AP profile. Enter the name for the virtual AP profile (for example, vp_c-portal ), then click Add.
a. In the Profile Details entry for the new virtual AP profile, select the AAA profile you previously configured. A pop-up window displays the configured AAA profile parameters. Click Apply in the pop-up window.
b. From the SSID profile drop-down menu, select NEW. A pop-up window allows you to configure the SSID profile.
c. Enter the name for the SSID profile (for example, ssid_c-portal ).
d. Enter the Network Name for the SSID (for example, c-portal-ap ).
e. Click Apply in the pop-up window.
f. At the bottom of the Profile Details page, click Apply.
10.Click on the new virtual AP name in the Profiles list or in Profile Details to display configuration parameters.
a. Make sure Virtual AP enable is selected.
b. For VLAN, select the VLAN to which users are assigned (for example, 20 ).
c. Click Apply .
317 | Captive Portal Authentication ArubaOS 6.5.3.x | User Guide
Configuring Captive Portal in the CLI
To configure captive portal with the PEFNG license via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #aaa authentication captive-portal c-portal d>efault-role employee server-group cp-srv
(host)(config) #user-role logon captive-portal c-portal
(host)(config) #aaa profile aaa_c-portal initial-role logon
(host)(config) #wlan ssid-profile ssid_c-portal essid c-portal-ap vlan 20
(host)(config) #wlan virtual-ap vp_c-portal aaa-profile aaa_c-portal ssid-profile ssid_c-portal n n n
Sample Authentication with Captive Portal
In the following example:
Guest clients associate to the guestnet SSID which is an open wireless LAN. Guest clients are placed into
VLAN 900 and assigned IP addresses by the controller’s internal DHCP server. The user has no access to network resources beyond DHCP and DNS until they open a web browser and log in with a guest account using captive portal.
Guest users are given a login and password from guest accounts created in the controller’s internal database. The temporary guest accounts are created and administered by the site receptionist.
Guest users must enter their assigned login and password into the captive portal login before they are given access to use web browsers (HTTP and HTTPS), POP3 email clients, and VPN clients (IPsec, PPTP, and L2TP) on the Internet and only during specified working hours. Guest users are prohibited from accessing internal networks and resources. All traffic to the Internet is source-NATed.
This example assumes a Policy Enforcement Firewall Next Generation (PEFNG) license is installed in the controller.
In this example, you create two user roles: n n guest-logon is a user role assigned to any client who associates to the guestnet SSID. Normally, any client that associates to an SSID will be placed into the logon system role. The guest-logon user role is more restrictive than the logon role.
auth-guest is a user role granted to clients who successfully authenticate via the captive portal.
Creating a Guest User Role
The guest-logon user role consists of the following ordered policies: n n n captiveportal is a predefined policy that allows captive portal authentication.
guest-logon-access is a policy that you create with the following rules: l
Allows DHCP exchanges between the user and the DHCP server during business hours while blocking other users from responding to DHCP requests.
l
Allows ICMP exchanges between the user and the controller during business hours.
block-internal-access is a policy that you create that denies user access to the internal networks.
ArubaOS 6.5.3.x
| User Guide Captive Portal Authentication | 318
The guest-logon user role configuration needs to include the name of the captive portal authentication profile instance. You can modify the user role configuration after you create the captive portal authentication profile instance.
Creating an Auth-guest User Role
The auth-guest user role consists of the following ordered policies: n n n n n cplogout is a predefined policy that allows captive portal logout.
guest-logon-access is a policy that you create with the following rules: l l
Allows DHCP exchanges between the user and the DHCP server during business hours while blocking other users from responding to DHCP requests.
Allows DNS exchanges between the user and the public DNS server during business hours. Traffic is source-NATed using the IP interface of the controller for the VLAN.
block-internal-access is a policy that you create that denies user access to the internal networks.
auth-guest-access is a policy that you create with the following rules: l
Allows DHCP exchanges between the user and the DHCP server during business hours while blocking other users from responding to DHCP requests.
l l
Allows DNS exchanges between the user and the public DNS server during business hours. Traffic is source-NATed using the IP interface of the controller for the VLAN.
Allows HTTP/S traffic from the user during business hours. Traffic is source-NATed using the I interface of the controller for the VLAN.
drop-and-log is a policy that you create that denies all traffic and logs the attempted network access.
Configuring Policies and Roles in the WebUI
Creating a Time Range
To create a time range via the WebUI:
1. Navigate to the Configuration > Security > Access Control > Time Ranges page to define the time range “working-hours”.
2. Click Add .
a. For Name, enter working-hours .
b. For Type, select Periodic .
c. Click Add .
d. For Start Day, click Weekday .
e. For Start Time, enter 07:30.
f. For End Time, enter 17:00 .
g. Click Done .
3. Click Apply .
To create the guest-logon-access policy via the WebUI:
1. Navigate to the Configuration > Security > Access Control > Policies page.
2. Select Add to add the guest-logon-access policy.
3. For Policy Name, enter guest-logon-access.
4. For Policy Type, select IPv4 Session .
5. Under Rules, select Add to add rules for the policy.
a. Under Source, select user .
319 | Captive Portal Authentication ArubaOS 6.5.3.x | User Guide
b. Under Destination, select any .
c. Under Service, select udp . Enter 68.
d. Under Action, select drop .
e. Click Add .
6. Under Rules, click Add .
a. Under Source, select any .
b. Under Destination, select any .
c. Under Service, select service . Select svc-dhcp .
d. Under Action, select permit.
e. Under Time Range, select working-hours.
f. Click Add .
Creating Aliases
The following step defines an alias representing the public DNS server addresses. Once defined, you can use the alias for other rules and policies.
1. Navigate to the Configuration > Security > Access Control > Policies page.
2. Select Add to add the guest-logon-access policy.
3. For Policy Name, enter guest-logon-access.
4. For Policy Type, select IPv4 Session .
5. Under Rules, click Add .
a. Under Source, select user .
b. Under Destination, select alias .
c. Under the alias selection, click New .
l l l l
For Destination Name, enter “Public DNS“.
Click Add to add a rule. For Rule Type , select host .
For IP Addres s, enter 64.151.103.120.
Click Add.
For Rule Type, select host.
l l
For IP Address, enter 216.87.84.209.
Click Add .
l
Click Apply.
The alias “Public DNS” appears in the Destination menu d. Under Destination, select Public DNS.
e. Under Service, select svc-dns.
f. Under Action, select src-nat .
g. Under Time Range, select working-hours .
h. Click Add .
6. Click Apply .
Creating an Auth-Guest-Access Policy
To configure the auth-guest-access policy via the WebUI:
1. Navigate to the Configuration > Security > Access Control > Policies page.
2. Select Add to add the guest-logon-access policy.
3. For Policy Name, enter auth-guest-access .
4. For Policy Type, select IPv4 Session .
ArubaOS 6.5.3.x
| User Guide Captive Portal Authentication | 320
5. Under Rules, select Add to add rules for the policy.
a. Under Source, select user .
b. Under Destination, select any .
c. Under Service, select udp . Enter 68 .
d. Under Action, select drop .
e. Click Add .
6. Under Rules, click Add .
a. Under Source, select any .
b. Under Destination, select any .
c. Under Service, select service . Select svc-dhcp .
d. Under Action, select permit .
e. Under Time Range, select working-hours .
f. Click Add .
7. Under Rules, click Add .
a. Under Source, select user .
b. Under Destination, select alias . Select Public DNS from the drop-down menu.
c. Under Service, select service . Select svc-dns .
d. Under Action, select src-nat .
e. Under Time Range, select working-hours .
f. Click Add .
8. Under Rules, click Add .
a. Under Source, select user .
b. Under Destination, select any .
c. Under Service, select service . Select svc-http .
d. Under Action, select src-nat .
e. Under Time Range, select working-hours .
f. Click Add .
9. Under Rules, click Add .
a. Under Source, select user .
b. Under Destination, select any .
c. Under Service, select service . Select svc-https .
d. Under Action, select src-nat .
e. Under Time Range, select working-hours .
f. Click Add .
10.Click
Apply .
Creating an Block-Internal-Access Policy
To create the block-internal-access policy via the WebUI:
1. Navigate to the Configuration > Security > Access Control > Policies page.
2. Select Add to add the block-internal-access policy.
3. For Policy Name, enter block-internal-access.
4. For Policy Type, select IPv4 Session .
5. Under Rules, select Add to add rules for the policy.
321 | Captive Portal Authentication ArubaOS 6.5.3.x | User Guide
a. Under Source, select user .
b. Under Destination, select alias .
The following step defines an alias representing all internal network addresses. Once defined, you can use the alias for other rules and policies.
c. Under the alias selection, click New . For Destination Name, enter “Internal Network”. Click Add to add a rule. For Rule Type, select network . For IP Address, enter 10.0.0.0. For Network Mask/Range, enter
255.0.0.0. Click Add to add the network range. Repeat these steps to add the network ranges
172.16.0.0 255.240.0.0 and 192.168.0.0 255.255.0.0. Click Apply . The alias “Internal Network” appears in the Destination menu d. Under Destination, select Internal Network.
e. Under Service, select any .
f. Under Action, select drop .
g. Click Add .
6. Click Apply .
Creating a Drop-and-Log Policy
To create the drop-and-log policy via the WebUI:
1. Navigate to the Configuration > Security > Access Control > Policies page.
2. Select Add to add the drop-and-log policy.
3. For Policy Name, enter drop-and-log .
4. For Policy Type, select IPv4 Session .
5. Under Rules, select Add to add rules for the policy.
a. Under Source, select user.
b. Under Destination, select any .
c. Under Service, select any.
d. Under Action, select drop .
e. Select Log .
f. Click Add .
6. Click Apply.
Creating a Guest Role
To create a guest role via the WebUI:
1. Navigate to the Configuration > Security > Access Control > User Roles page.
2. Click Add .
3. For Role Name, enter guest-logon.
4. Under Firewall Policies, click Add .
5. For Choose from Configured Policies, select captiveportal from the drop-down menu.
6. Click Done.
7. Under Firewall Policies, click Add.
8. For Choose from Configured Policies, select guest-logon-access from the drop-down menu.
9. Click Done .
10.Under Firewall Policies, click Add .
11.For Choose from Configured Policies, select block-internal-access from the drop-down menu.
ArubaOS 6.5.3.x
| User Guide Captive Portal Authentication | 322
12.Click
Done .
13.Click
Apply .
Creating an Auth-Guest Role
To create the guest-logon role via the WebUI:
1. Navigate to the Configuration > Security > Access Control > User Roles page.
2. Click Add.
3. For Role Name, enter auth-guest.
4. Under Firewall Policies, click Add .
5. For Choose from Configured Policies, select cplogout from the drop-down menu.
6. Click Done .
7. Under Firewall Policies, click Add .
8. For Choose from Configured Policies, select guest-logon-access from the drop-down menu.
9. Click Done .
10.Under Firewall Policies, click Add.
11.For Choose from Configured Policies, select block-internal-access from the drop-down menu.
12.Click
Done .
13.Under Firewall Policies, click Add.
14.For Choose from Configured Policies, select auth-guest-access from the drop-down menu.
15.Click
Done .
16.Under Firewall Policies, click Add .
17.For Choose from Configured Policies, select drop-and-log from the drop-down menu.
18.Click
Done .
19.Click
Apply .
Configuring Policies and Roles in the CLI
Defining a Time Range
To create a time range via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #time-range working-hours periodic weekday 07:30 to 17:00
Creating Aliases
To create aliases via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #netdestination “Internal Network” network 10.0.0.0 255.0.0.0
network 172.16.0.0 255.255.0.0
network 192.168.0.0 255.255.0.0
(host)(config) #netdestination “Public DNS” host 64.151.103.120
host 216.87.84.209
Creating a Guest-Logon-Access Policy
To create a guest-logon-access policy via the command-line interface, access the CLI in config mode and issue the following commands:
323 | Captive Portal Authentication ArubaOS 6.5.3.x | User Guide
(host)(config) #ip access-list session guest-logon-access user any udp 68 deny any any svc-dhcp permit time-range working-hours user alias “Public DNS” svc-dns src-nat time-range working-hours
Creating an Auth-Guest-Access Policy
To create an auth-guest-access policy via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #ip access-list session auth-guest-access user any udp 68 deny any any svc-dhcp permit time-range working-hours user alias “Public DNS” svc-dns src-nat time-range working-hours user any svc-http src-nat time-range working-hours user any svc-https src-nat time-range working-hours
Creating a Block-Internal-Access Policy
To create a block-internal-access policy via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #ip access-list session block-internal-access user alias “Internal Network” any deny
Creating a Drop-and-Log Policy
To create a drop-and-log policy via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #ip access-list session drop-and-log user any any deny log
Creating a Guest-Logon Role
To create a guest-logon-role via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #user-role guest-logon session-acl captiveportal position 1 session-acl guest-logon-access position 2 session-acl block-internal-access position 3
Creating an Auth-Guest Role
To create an auth-guest role via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #user-role auth-guest session-acl cplogout position 1 session-acl guest-logon-access position 2 session-acl block-internal-access position 3 session-acl auth-guest-access position 4 session-acl drop-and-log position 5
Configuring Guest VLANs
Guests using the WLAN are assigned to VLAN 900 and are given IP addresses via DHCP from the controller.
In the WebUI
1. Navigate to the Configuration > Network > VLANs page.
a. Select the VLAN ID tab.
ArubaOS 6.5.3.x
| User Guide Captive Portal Authentication | 324
a. Click Add .
b. For VLAN ID, enter 900.
c. Click Apply .
2. Navigate to the Configuration > Network > IP > IP Interfaces page.
a. Click the IP Interfaces tab.
a. Click Edit for VLAN 900.
b. For IP Address, enter 192.168.200.20.
c. For Net Mask, enter 255.255.255.0.
d. Click Apply .
3. Click the DHCP Server tab.
a. Select Enable DHCP Server .
b. Click Add under Pool Configuration.
c. In the Pool Name field, enter guestpool .
d. In the Default Router field, enter 192.168.200.20.
e. In the DNS Server field, enter 64.151.103.120.
f. In the Lease field, enter 4 hours.
g. In the Network field, enter 192.168.200.0. In the Netmask field, enter 255.255.255.0.
h. Click Done.
4. Click Apply .
In the CLI
(host)(config) #vlan 900
(host)(config) #interface vlan 900
(host)(config) #ip address 192.168.200.20 255.255.255.0
(host)(config) #ip dhcp pool "guestpool"
(host)(config) #default-router 192.168.200.20
(host)(config) #dns-server 64.151.103.120
(host)(config) #lease 0 4 0
(host)(config) #network 192.168.200.0 255.255.255.0
Configuring Captive Portal Authentication Profiles
In this section, you create an instance of the captive portal authentication profile and the AAA profile. For the captive portal authentication profile, you specify the previously-created auth-guest user role as the default user role for authenticated captive portal clients and the authentication server group (“Internal”).
To configure captive portal authentication via the WebUI:
1. Navigate to the Configuration > Security > Authentication > L3 Authentication page. In the Profiles list, select Captive Portal Authentication Profile.
a. In the Captive Portal Authentication Profile Instance list, enter guestnet for the name of the profile, then click Add .
b. Select the captive portal authentication profile you just created.
c. For Default Role, select auth-guest .
d. Select User Login.
e. Deselect (uncheck) Guest Login.
f. Click Apply .
2. Select Server Group under the guestnet captive portal authentication profile you just created.
325 | Captive Portal Authentication ArubaOS 6.5.3.x | User Guide
a. Select internal from the Server Group drop-down menu.
b. Click Apply .
To configure captive portal authentication via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #aaa authentication captive-portal guestnet d>efault-role auth-guest user-logon no guest-logon server-group internal
Modifying the Initial User Role
The captive portal authentication profile specifies the captive portal login page and other configurable parameters. The initial user role configuration must include the applicable captive portal authentication profile instance. Therefore, you need to modify the guest-logon user role configuration to include the guestnet captive portal authentication profile.
To modify the guest-logon role via the WebUI:
1. Navigate to the Configuration > Security > Access Control > User Roles page.
2. Select Edit for the guest-logon role.
3. Scroll down to the bottom of the page.
4. Select the captive portal authentication profile you just created from the Captive Portal Profile drop-down menu, and click Change.
5. Click Apply .
To modify the guest-logon role via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #user-role guest-logon captive-portal guestnet
Configuring the AAA Profile
In this section, you configure the guestnet AAA profile, which specifies the previously-created guest-logon role as the initial role for clients who associate to the WLAN.
To configure the AAA profile via the WebUI:
1. Navigate to the Configuration > Security > Authentication > AAA Profiles page.
2. In the AAA Profiles Summary, click Add to add a new profile. Enter guestnet for the name of the profile, then click Add .
3. For Initial role, select guest-logon.
4. Click Apply.
To configure the AAA profile via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #aaa profile guestnet initial-role guest-logon
Configuring the WLAN
In this section, you create the guestnet virtual AP profile for the WLAN. The guestnet virtual AP profile contains the SSID profile guestnet (which configures opensystem for the SSID) and the AAA profile guestnet .
To configure the guest WLAN via the WebUI:
1. Navigate to the Configuration > Wireless > AP Configuration page.
ArubaOS 6.5.3.x
| User Guide Captive Portal Authentication | 326
2. Select either AP Group or AP Specific tab. Click Edit for the AP group or AP name.
3. To configure the virtual AP profile, navigate to the Configuration > Wireless > AP Configuration page.
Select either the AP Group or AP Specific tab. Click Edit for the applicable AP group name or AP name.
4. Under Profiles, select Wireless LAN, then select Virtual AP.
5. To create a new virtual AP profile, select NEW from the Add a profile drop-down menu. Enter the name for the virtual AP profile (for example, guestnet ), and click Add .
a. In the Profile Details entry for the new virtual AP profile, select the AAA profile you previously configured. A pop-up window displays the configured AAA profile parameters. Click Apply in the pop-up window.
b. From the SSID profile drop-down menu, select NEW. A pop-up window allows you to configure the SSID profile.
c. Enter the name for the SSID profile (for example, guestnet ).
d. Enter the Network Name for the SSID (for example, guestnet ).
e. For Network Authentication, select None.
f. For Encryption, select Open.
g. Click Apply in the pop-up window.
h. At the bottom of the Profile Details page, click Apply.
6. Click on the new virtual AP name in the Profiles list or in Profile Details to display configuration parameters.
a. Make sure Virtual AP enable is selected.
b. For VLAN, select the ID of the VLAN in which captive portal users are placed (for example, VLAN 900) .
c. Click Apply.
To configure the guest WLAN via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #wlan ssid-profile guestnet essid guestnet opmode opensystem
(host)(config) #aaa profile guestnet initial-role guest-logon
(host)(config) #wlan virtual-ap guestnet vlan 900 aaa-profile guestnet ssid-profile guestnet
Managing User Accounts
Temporary user accounts are created in the internal database on the controller. You can create a user role which will allow a receptionist to create temporary user accounts. Guests can use the accounts to log into a captive portal login page to gain Internet access.
See
Creating Guest Accounts on page 886
for more information about configuring guest provisioning users and administering guest accounts.
Configuring Captive Portal Configuration Parameters
describes configuration parameters on the WebUI Captive Portal Authentication profile page.
In the CLI, you configure these options with the aaa authentication captive-portal commands.
327 | Captive Portal Authentication ArubaOS 6.5.3.x | User Guide
Table 78: Captive Portal Authentication Profile Parameters
Parameter
Default Role
Description
Default Guest Role
Redirect Pause
Login Page
User Logon
Guest Login
Logout popout window
Use HTTP for authentication
Logon wait minimum wait
Logon wait maximum wait
Logon wait CPU utilization threshold
Max Authentication failures
Show FDQN
Role assigned to the Captive Portal user upon login. When both user and guest logon are enabled, the default role applies to the user logon; users logging in using the guest interface are assigned the guest role.
Default: guest
Role assigned to guest.
Default: guest
Time, in seconds, that the system remains in the initial welcome page before redirecting the user to the final web URL. If set to 0, the welcome page displays until the user clicks on the indicated link.
Default: 10 seconds
URL of the page that appears for the user logon. This can be set to any URL.
Default: /auth/index.html
Enables Captive Portal with authentication of user credentials.
Default: Enabled
Enables Captive Portal logon without authentication.
Default: Disabled
Enables a pop-up window with the Logout link for the user to logout after logon. If this is disabled, the user remains logged in until the user timeout period has elapsed or the station reloads.
Default: Enabled
Use HTTP protocol on redirection to the Captive Portal page. If you use this option, modify the captive portal policy to allow HTTP traffic.
Default: disabled (HTTPS is used)
Minimum time, in seconds, the user will have to wait for the logon page to pop up if the CPU load is high. This works in conjunction with the Logon wait CPU utilization threshold parameter.
Default: 5 seconds
Configure parameters for the logon wait interval
Default: 10 seconds
CPU utilization percentage above which the Logon wait interval is applied when presenting the user with the logon page.
Default: 60%
Maximum number of authentication failures before the user is blacklisted.
Default: 0
Allows the user to see and select the fully-qualified domain name (FQDN) on the login page. The FQDNs shown are specified when configuring individual servers for the server group used with captive portal authentication.
Default: Disabled
Authentication Protocol
Select the PAP, CHAP or MS-CHAPv2 authentication protocol.
NOTE: Do not use the CHAP = option unless instructed to do so by anAruba representative.
ArubaOS 6.5.3.x
| User Guide Captive Portal Authentication | 328
Parameter
Logon Page
Welcome Page
Show Welcome
Page
Add switch IP address in redirection URL
Add User VLAN in the Redirection URL
Add a controller interface in the redirection URL
Allow only one active user session
WhiteList
BlackList
Show Acceptable
Use Policy Page
User idle timeout
Description
URL of the page that appears before logon. This can be set to any URL.
Default: /auth/index.html
URL of the page that appears after logon and before redirection to the web URL. This can be set to any URL.
Default: /auth/welcome.html
Displays the configured welcome page before the user is redirected to their original
URL. If this option is disabled, users are redirected to the web URL immediately after they log in.
Default: Enabled
Sends the controller’s IP address in the redirection URL when external captive portal servers are used. An external captive portal server can determine the controller from which a request originated by parsing the ‘switchip’ variable in the URL.
Default: Disabled
Sends the user’s VLAN ID in the redirection URL when external captive portal servers are used.
Sends the controller’s interface IP address in the redirection URL when external captive portal servers are used. An external captive portal server can determine the controller from which a request originated by parsing the ‘switchip’ variable in the
URL.
Allows only one active user session at a time.
Default: Disabled
To add a netdestination to the captive portal whitelist, enter the destination host or subnet, then click Add.
The netdestination will be added to the whitelist. To remove a netdestination from the whitelist, select it in the whitelist field, then click Delete .
If you have not yet defined a netdestination, use the CLI command netdestination to define a destination host or subnet before you add it to the whitelist.
To add a netdestination to the captive portal blacklist, enter the destination host or subnet, then click Add . The netdestination will be added to the blacklist. To remove a netdestination from the blacklist, select it in the blacklist field, then click Delete .
If you have not yet defined a netdestination, use the CLI command netdestination to define a destination host or subnet before you add it to the blacklist.
Show the acceptable use policy page before the logon page.
Default: Disabled
The user idle timeout value for this profile. Specify the idle timeout value for the client in seconds. Valid range is 30-15300 in multiples of 30 seconds. Enabling this option overrides the global settings configured in the AAA timers. If this is disabled, the global settings are used.
Redirect URL
URL Hash Key
URL to which an authenticated user will be directed. This parameter must be an absolute URL that begins with either http:// or https:// .
If a redirection URL is defined, enter a URL Hash Key to hash the redirect URL using the specified key.
This parameter enhances security for the Clearpass Guest login URL so that Clearpass can trust and ensure that the client MAC address in the redirect URL has not been tampered with by anyone. Default: Disabled.
329 | Captive Portal Authentication ArubaOS 6.5.3.x | User Guide
n n n n n
Enabling Optional Captive Portal Configurations
The following are optional captive portal configurations:
Uploading Captive Portal Pages by SSID Association on page 330
Changing the Protocol to HTTP on page 330
Configuring Redirection to a Proxy Server on page 331
Redirecting Clients on Different VLANs on page 332
Web Client Configuration with Proxy Script on page 333
Uploading Captive Portal Pages by SSID Association
You can upload custom login pages for captive portal into the controller through the WebUI (refer to
Creating and Installing an Internal Captive Portal on page 336
). The SSID to which the client associates determines the captive portal login page displayed.
You specify the captive portal login page in the captive portal authentication profile, along with other configurable parameters. The initial user role configuration must include the applicable captive portal authentication profile instance. (In the case of captive portal in the base operating system, the initial user role is automatically created when you create the captive portal authentication profile instance.) You then specify the initial user role for captive portal in the AAA profile for the WLAN.
When you have multiple captive portal login pages loaded in the controller, you must configure a unique initial user role and user role, and captive portal authentication profile, AAA profile, SSID profile, and virtual AP profile for each WLAN that will use captive portal. For example, if you want to have different captive portal login pages for the engineering, business and faculty departments, you need to create and configure according to
Table 79: Captive Portal login Pages
Entity Engineering
Captive portal login page
/auth/eng-login.html
Captive portal user role eng-user
Captive portal authentication profile
Initial user role
AAA profile eng-cp
(Specify /auth/englogin.html and eng-user) eng-logon
(Specify the eng-cp profile) eng-aaa
(Specify the eng-logon user role)
SSID profile
Virtual AP profile eng-ssid eng-vap
Business
/auth/bus-login.html
bus-user bus-cp
(Specify /auth/buslogin.html and bus-user) bus-logon
(Specify the bus-cp profile) bus-aaa
(Specify the bus-logon user role) bus-ssid bus-vap
Faculty
/auth/fac-login.html
fac-user fac-cp
(Specify /auth/buslogin.html and fac-user) fac-logon
(Specify the fac-logon profile) fac-aaa
(Specify the fac-logon user role) fac-ssid fac-vap
Changing the Protocol to HTTP
By default, the HTTPS protocol is used on redirection to the Captive Portal page. If you need to use HTTP instead, you need to do the following: n
Modify the captive portal authentication profile to enable the HTTP protocol.
ArubaOS 6.5.3.x
| User Guide Captive Portal Authentication | 330
n
For captive portal with role-based access only —Modify the captiveportal policy to permit HTTP traffic instead of HTTPS traffic.
In the base operating system, the implicit ACL captive-portal-profile is automatically modified.
To change the protocol to HTTP via the WebUI:
1. Edit the captive portal authentication profile by navigating to the Configuration > Security >
Authentication > L3 Authentication page.
a. Enable (select) “Use HTTP for authentication”.
b. Click Apply.
2. (For captive portal with role-based access only) Edit the captiveportal policy by navigating to the
Configuration > Security > Access Control > Policies page.
a. Delete the rule for “user mswitch svc-https dst-nat”.
b. Add a new rule with the following values and move this rule to the top of the rules list: n n source is user destination is the mswitch alias n n service is svc-http action is dst-nat c. Click Apply.
To change the protocol to HTTP via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #aaa authentication captive-portal profile protocol-http
(For captive portal with role-based access only)
(host)(config) #ip access-list session captiveportal no user alias mswitch svc-https dst-nat user alias mswitch svc-http dst-nat user any svc-http dst-nat 8080 user any svc-https dst-nat 8081
Configuring Redirection to a Proxy Server
You can configure captive portal to work with proxy Web servers. When proxy Web servers are used, browser proxy server settings for end users are configured for the proxy server’s IP address and TCP port. When the user opens a Web browser, the HTTP/S connection request must be redirected from the proxy server to the captive portal on the controller.
To configure captive portal to work with a proxy server: n n
(For captive portal with base operating system) Modify the captive portal authentication profile to specify the proxy server’s IP address and TCP port.
(For captive portal with role-based access) Modify the captiveportal policy to have traffic for the proxy server’s port destination NATed to port 8088 on the controller.
The base operating system automatically modifies the implicit ACL captive-portal-profile .
The following sections describe how use the WebUI and CLI to configure the captive portal with a proxy server.
When HTTPS traffic is redirected from a proxy server to the controller, the user’s browser will display a warning that the subject name on the certificate does not match the hostname to which the user is connecting.
To redirect proxy server traffic using the WebUI:
331 | Captive Portal Authentication ArubaOS 6.5.3.x | User Guide
1. For captive portal with Aruba base operating system, edit the captive portal authentication profile by navigating to the Configuration > Security > Authentication > L3 Authentication page.
a. For Proxy Server, enter the IP address and port for the proxy server.
b. Click Apply .
2. For captive portal with role-based access, edit the captiveportal policy by navigating to the Configuration
> Security > Access Control > Policies page.
3. Add a new rule with the following values: a. Source is user b. Destination is any c. Service is TCP d. Port is the TCP port on the proxy server e. Action is dst-nat f. IP address is the IP address of the proxy port g. Port is the port on the proxy server
4. Click Add to add the rule. Use the up arrows to move this rule just below the rule that allows HTTP(S) traffic.
5. Click Apply .
To redirect proxy server traffic via the command-line interface, access the CLI in config mode and issue the following commands.
For captive portal with Aruba base operating system:
(host)(config) #aaa authentication captive-portal profile proxy host ipaddr port port
For captive portal with role-based access:
(host)(config) #ip access-list session captiveportal user alias mswitch svc-https permit user any tcp port dst-nat 8088 user any svc-http dst-nat 8080 user any svc-https dst-nat 8081
Redirecting Clients on Different VLANs
You can redirect wireless clients that are on different VLANs (from the controller’s IP address) to the captive portal on the controller. To do this:
1. Specify the redirect address for the captive portal.
2. For captive portal with the PEFNG license only, you need to modify the captiveportal policy that is assigned to the user. To do this: a. Create a network destination alias to the controller interface.
b. Modify the rule set to allow HTTPS to the new alias instead of the mswitch alias.
In the base operating system, the implicit ACL captive-portal-profile is automatically modified.
This example shows how to use the command-line interface to create a network destination called cp-redirect and use that in the captiveportal policy:
(host)(config) #ip cp-redirect-address ipaddr
For captive portal with PEFNG license:
(host)(config) #netdestination cp-redirect ipaddr
(host)(config) #ip access-list session captiveportal
ArubaOS 6.5.3.x
| User Guide Captive Portal Authentication | 332
user alias cp-redirect svc-https permit user any svc-http dst-nat 8080 user any svc-https dst-nat 8081
Web Client Configuration with Proxy Script
If the web client proxy configuration is distributed through a proxy script (a
.pac
file), you need to configure the captiveportal policy to allow the client to download the file. Note that in order modify the captiveportal policy, you must have the PEFNG license installed in the controller.
To allow clients to download proxy script via the WebUI:
1. Edit the captiveportal policy by navigating to the Configuration > Security > Access Control >
Policies page.
2. Add a new rule with the following values: l
Source is user l l l l
Destination is host
Host IP is the IP address of the proxy server
Service is svc-https or svc-http
Action is permit
3. Click Add to add the rule. Use the up arrows to move this rule above the rules that perform destination
NAT.
4. Click Apply .
To allow clients to download proxy script via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #ip access-list session captiveportal user alias mswitch svc-https permit user any tcp port dst-nat 8088 user host ipaddr svc-https permit user any svc-http dst-nat 8080 user any svc-https dst-nat 8081
Personalizing the Captive Portal Page
The following can be personalized on the default captive portal page: n n n
Captive portal background
Page text
Acceptance Use Policy
The background image and text should be visible to users with a browser window on a 1024 by 768 pixel screen. The background should not clash if viewed on a much larger monitor. A good option is to have the background image at 800 by 600 pixels, and set the background color to be compatible. The maximum image size for the background can be around 960 by 720 pixels, as long as the image can be cropped at the bottom and right edges. Leave space on the left side for the login box.
You can create your own web pages and install them in the controller for use with captive portal. See “Internal
Captive Portal” on page 265
1. Navigate to the Configuration > Management > Captive Portal > Customize Login Page page.
You can choose one of three page designs. To select an existing design, click the first or the second page design present.
333 | Captive Portal Authentication ArubaOS 6.5.3.x | User Guide
2. To customize the page background: a. Select the YOUR CUSTOM BACKGROUND page.
b. Under Additional options , enter the location of the JPEG image in the Upload your own custom background field.
c. Set the background color in the Custom page background color field. The color code must a hexadecimal value in the format #hhhhhh.
d. To view the page background changes, click Submit at the bottom on the page and then click the View
CaptivePortal link. The User Agreement Policy page appears and displays the Captive Portal page as it will be seen by users
ArubaOS 6.5.3.x
| User Guide Captive Portal Authentication | 334
3. To customize the captive portal background text: a. Enter the text that needs to be displayed in the Page Text (in HTML format) message box.
b. To view the background text changes, click Submit at the bottom on the page and then click the View
CaptivePortal link. The User Agreement Policy page appears.
c. Click Accept.
This displays the Captive Portal page as it will be seen by users.
4. To customize the text under the Acceptable Use Policy: a. Enter the policy information in the Policy Text text box. Use this only in the case of guest logon.
b. To view the use policy information changes, click Submit at the bottom on the page and then click the
View CaptivePortal link. The User Agreement Policy page appears. The text you entered appears in the Acceptable Use Policy text box.
c. Click Accept.
This displays the Captive Portal page as it will be seen by users
.
335 | Captive Portal Authentication ArubaOS 6.5.3.x | User Guide
n n n n n n n n
Creating and Installing an Internal Captive Portal
If you do not wish to customize the default captive portal page, you can use the following procedures to create and install a new internal captive portal page. This section describes the following topics:
Creating a New Internal Web Page on page 336
Installing a New Captive Portal Page on page 338
Displaying Authentication Error Messages on page 338
Reverting to the Default Captive Portal on page 339
Configuring Localization on page 339
Customizing the Welcome Page on page 342
Customizing the Pop-Up box on page 344
Customizing the Logged Out Box on page 345
Creating a New Internal Web Page
In addition to customizing the default captive portal page, you can also create your own internal web page. A custom web page must include an authentication form to authenticate a user. The authentication form can include any of the following variables listed in
ArubaOS 6.5.3.x
| User Guide Captive Portal Authentication | 336
Table 80: Web Page Authentication Variables
Variable Description user password
FQDN
(Required)
(Required)
The fully-qualified domain name (this is dependent on the setting of the controller and is supported only in Global Catalog Servers software.
The form can use either the "get" or the "post" methods, but the "post" method is recommended. The form's action must absolutely or relatively reference https://<controller_IP>/auth/index.html/u .
You can construct an authentication form using the following HTML:
<FORM method="post" ACTION="/auth/index.html/u">
...
</FORM>
A recommended option for the <FORM> element is: autocomplete="off"
This option prevents Internet Explorer from caching the form inputs. The form variables are input using any form control method available such as INPUT, SELECT, TEXTAREA, and BUTTON. Example HTML code follows.
Username Example
Minimal:
<INPUT type="text" name="user">
Recommended Options: accesskey="u" Sets the keyboard shortcut to 'u'
SIZE="25 "Sets the size of the input box to 25
VALUE= ""Ensures no default value
Password Example
Minimal:
<INPUT type="password" name="password">
Recommended Options: accesskey="p" Sets the keyboard shortcut to 'p'
SIZE="25 "Sets the size of the input box to 25
VALUE= ""Ensures no default value
FQDN Example
Minimal:
<SELECT name=fqdn>
<OPTION value="fqdn1" SELECTED>
<OPTION value="fqdn2">
</SELECT>
Recommended Options:
None
Finally, an HTML also requires an input button:
<INPUT type="submit">
337 | Captive Portal Authentication ArubaOS 6.5.3.x | User Guide
Basic HTML Example
<HTML>
<HEAD>
</HEAD>
<BODY>
<FORM method="post" autocomplete="off" ACTION="/auth/index.html/u">
Username:<BR>
<INPUT type="text" name="user" accesskey="u" SIZE="25" VALUE="">
<BR>
Password:<BR>
<INPUT type="password" name="password" accesskey="p" SIZE="25"
<BR>
VALUE="">
<INPUT type="submit">
</FORM>
</BODY>
</HTML>
You can find a more advanced example simply by using your browser’s "view-source" function while viewing the default captive portal page.
Installing a New Captive Portal Page
You can install the captive portal page by using the Maintenance function of the WebUI.
Log into the WebUI and navigate to Configuration > Management > Captive Portal > Upload Custom
Login Pages .
This page lets you upload your own files to the controller. There are different page types that you can choose: n n n
Captive Portal Login (top level): This type uploads the file into the controller and sets the captive portal page to reference the file that you are uploading. Use with caution on a production controller as this takes effect immediately.
Captive Portal Welcome Page: This type uploads the file that appears after logon and before redirection to the web URL. The display of the welcome page can be disabled or enabled in the captive portal profile.
Content: The content page type allows you to upload all miscellaneous files that you need to reference from your main captive portal login page. This can be used for images, scripts or any other file that you need to reference. These files are uploaded into the same directory as the top level captive portal page and thus all files can be referenced relatively.
Uploaded files can be referenced using: https://<controller_IP>/upload/custom/<CP-Profile-Name>/<file>
Displaying Authentication Error Messages
This section contains a script that performs the following tasks: n n
When the user is redirected to the main captive portal login when there is authentication failure, the redirect
URL includes a query parameter "errmsg" which java script can extract and display.
Store the originally requested URL in a cookie so that once the user has authenticated, they are automatically redirected to its original page. Note that for this feature to work, you need ArubaOS release
2.4.2.0 or later. If you don't want this feature, delete the part of the script shown in red.
<script>
{ function createCookie(name,value,days)
{
ArubaOS 6.5.3.x
| User Guide Captive Portal Authentication | 338
if (days)
{ var date = new Date(); date.setTime(date.getTime()+(days*24*60*60*1000)); var expires = "; expires="+date.toGMTString();
} else var expires = ""; document.cookie = name+"="+value+expires+"; path=/";
} var q = window.location.search; var errmsg = null; if (q && q.length > 1) { q = q.substring(1).split(/[=&]/); for (var i = 0; i < q.length - 1; i += 2) { if (q[i] == "errmsg") { errmsg = unescape(q[i + 1]); break;
} if (q[i] == "host") { createCookie('url',unescape(q[i+1]),0)
}
}
} if (errmsg && errmsg.length > 0) { errmsg = "<div id='errorbox'>\n" + errmsg + "\n</div>\n"; document.write(errmsg);
}
}
</script>
Reverting to the Default Captive Portal
You can reassign the default captive portal site using the "Revert to factory default settings" check box in the
"Upload Custom Login Pages" section of the Maintenance tab in the WebUI.
Configuring Localization
The ability to customize the internal captive portal provides you with a very flexible interface to the Aruba captive portal system. However, other than posting site-specific messages onto the captive portal website, the most common type of customization is likely to be language localization. This section describes a simple method for creating a native language captive portal implementation using the Aruba internal captive portal system.
1. Customize the configurable parts of the captive portal settings to your liking. To do this, navigate to the
Configuration > Management > Captive Portal > Customize Login Page in the WebUI:
For example, choose a page design, upload a custom logo and/or a custom background. Also include any page text and acceptable use policy that you would like to include. Put this in your target language or else you will need to translate this at a later time.
Ensure that Guest login is enabled or disabled as necessary by navigating to the Configuration > Security
> Authentication > L3 Authentication > Captive Portal Authentication Profile page to create or edit the captive portal profile. Select or deselect "Guest Login".
2. Click Submit and then click on View Captive Portal.
Check that your customization and text/html is correct, with the default interface still in English and the character set still autodetects to ISO-8859-1.
Repeat steps 1 and 2 until you are satisfied with your page.
339 | Captive Portal Authentication ArubaOS 6.5.3.x | User Guide
3. Once you have a page you find acceptable, click on View Captive Portal one more time to display your login page. From your browser, choose "View->Source" or its equivalent. Your system will display the HTML source for the captive portal page. Save this source as a file on your local system.
4. Open the file that you saved in
, using a standard text editor, and make the following changes: a. Fix the character set. The default <HEAD>...</HEAD> section of the file will appear as:
<head>
<title>Portal Login</title>
<link href="default1/styles.css" rel="stylesheet" media="screen" type="text/css" />
<script language="javascript" type="text/javascript"> function showPolicy()
{win = window.open("/auth/acceptableusepolicy.html", "policy",
"height=550,width=550,scrollbars=1");}
</script>
</head>
In order to control the character set that the browser will use to show the text with, you will need to insert the following line inside the <HEAD>...</HEAD> element:
<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS"/>
Replace the "Shift_JIS" part of the above line with the character set that is used by your system. In theory, any character encoding that has been registered with IANA can be used, but you must ensure that any text you enter uses this character set and that your target browsers support the required character set encoding.
b. The final <HEAD>...</HEAD> portion of the document should look similar to this:
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS"/>
<title>Portal Login</title>
<link href="default1/styles.css" rel="stylesheet" media="screen" type="text/css" />
<script language="javascript" type="text/javascript"> function showPolicy()
{win = window.open("/auth/acceptableusepolicy.html", "policy",
"height=550,width=550,scrollbars=1");}
</script>
</head> c. Fix references: If you have used the built-in preferences, you will need to update the reference for the logo image and the CSS style sheet.
To update the CSS reference, search the text for "<link href" and update the reference to include "/auth/" in front of the reference. The original link should look similar to the following:
<link href="default1/styles.css" rel="stylesheet" media="screen" type="text/css" />
This should be replaced with a link like the following:
<link href="/auth/default1/styles.css" rel="stylesheet" media="screen" type="text/css" />
The easiest way to update the image reference is to search for "src" using your text editor and updating the reference to include "/auth/" in front of the image file. The original link should look similar to the following:
<img src="default1/logo.gif"/>
This should be replaced with a link like this:
<img src="/auth/default1/logo.gif"/> d. Insert javascript to handle error cases:
ArubaOS 6.5.3.x
| User Guide Captive Portal Authentication | 340
When the controller detects an error situation, it will pass the user's page a variable called "errmsg" with a value of what the error is in English. Currently, only "Authentication Failed" is supported as a valid error message.
To localize the authentication failure message, replace the following text (it is just a few lines below the
<body> tag):
<div id="errorbox" style="display: none;">
</div> with the script below. You will need to translate the "Authentication Failed" error message into your local language and add it into the script below where it states: localized_msg="...":
<script>
{ var q = window.location.search; var errmsg = null; if (q && q.length > 1) { q = q.substring(1).split(/[=&]/); for (var i = 0; i < q.length - 1; i += 2) { if (q[i] == "errmsg") { errmsg = unescape(q[i + 1]); break;
}
}
} if (errmsg && errmsg.length > 0) { switch(errmsg) { case "Authentication Failed": localized_msg="Authentication Failed"; break; default: localised_msg=errmsg; break;
} errmsg = "<div id='errorbox'>\n" + localised_msg + "\n</div>\n";
}; document.write(errmsg);
}
</script> e. Translate the web page text. Once you have made the changes as above, you only need to translate the rest of the text that appears on the page. The exact text that appears will depend on the controller settings when you originally viewed the captive portal. You will need to translate all relevant text such as
"REGISTERED USER", "USERNAME", "PASSWORD", the value="" part of the INPUT type="submit" button and all other text. Ensure that the character set you use to translate into is the same as you have selected in part i) above.
Feel free to edit the HTML as you go if you are familiar with HTML.
5. After saving the changes made in step 4 above, upload the file to the controller using the
Configuration > Management > Captive Portal > Upload Custom Login Pages section of the WebUI.
Choose the captive portal profile from the drop-down menu. Browse your local computer for the file you saved. For Page Type, select “Captive Portal Login”. Ensure that the "Revert to factory default settings" box is NOT checked and click Apply . This will upload the file to the controller and set the captive portal profile to use this page as the redirection page.
In order to check that your site is operating correctly, go back to the "Customize Login Page" and click on
"View Captive Portal" to view the page you have uploaded. Check that your browser has automatically detected the character set and that your text is not garbled.
341 | Captive Portal Authentication ArubaOS 6.5.3.x | User Guide
To make any adjustments to your page, edit your file locally and simply re-upload to the controller in order to view the page again.
6. Finally, it is possible to customize the welcome page on the controller, however for language localization it is recommended to use an "external welcome page" instead. This can be a web site on an external server, or it can be a static page that is uploaded to a controller.
You set the welcome page in the captive portal authentication profile. This is the page that the user will be redirected to after successful authentication.
If this is required to be a page on the controller, the user needs to create their own web page (using the charset meta attribute in step 4 above). Upload this page to the designated controller in the same manner as uploading the captive portal login page under " Configuration > Management > Captive Portal >
Upload Custom Login Pages.
For Page Type, select “Captive Portal Welcome Page”.
Any required client side script (CSS) and media files can also be uploaded using the “Content” Page Type, however file space is limited (use the CLI command show storage to see available space). Remember to leave ample room for system files.
The "Registered User" and "Guest User" sections of the login page are implemented as graphics files, referenced by the default CSS styles. In order to change these, you will need to create new graphic files, download the CSS file, edit the reference to the graphics files, change the style reference in your index file and then upload all files as "content" to the controller.
A sample of a translated page is displayed in
.
Figure 51 Sample Translated Page
Customizing the Welcome Page
Once a user is authenticated by the controller, a Welcome page is launched. The default welcome page depends on your configuration, but will look similar to
:
ArubaOS 6.5.3.x
| User Guide Captive Portal Authentication | 342
Figure 52 Default Welcome Page
You can customize this welcome page by building your own HTML page and uploading it to the controller. You upload it to the controller by navigating to Management > Captive Portal > Upload Login Pagesand select
“Captive Portal Welcome Page” from the Page Type drop-down menu. This file is stored in a directory called
"/upload/" on the controller using the file's original name.
In order to actually use this file, you will need to configure the welcome page on the controller. To do this use the CLI command: "aaa captive-portal welcome-page /upload/welc.html" where "welc.html" is the name of the file that you uploaded, or you can change the Welcome page in the captive portal authentication profile in the
WebUI.
An example that will create the same page as displayed in
is shown below. The part in red will redirect the user to the web page you originally setup. For this to work, please follow the procedure described above in this document.
:
<html>
<head>
<script>
{ function readCookie(name)
{ var nameEQ = name + "="; var ca = document.cookie.split(';'); for(var i=0;i < ca.length;i++)
{ var c = ca[i]; while (c.charAt(0)==' ') c = c.substring(1,c.length); if (c.indexOf(nameEQ) == 0) return c.substring
(nameEQ.length,c.length);
} return null;
} var cookieval = readCookie('url'); if (cookieval.length>0) document.write("<meta http-equiv=\"refresh\" content=\"2;url=http://"+cookieval+"\""+">");
}
</script>
</head>
<body bgcolor=white text=000000>
<font face="Verdana, Arial, Helvetica, sans-serif" size=+1>
343 | Captive Portal Authentication ArubaOS 6.5.3.x | User Guide
<b>User Authenticated </b>
<p>In 2 seconds you will be automatically redirected to your original web page</p>
<p> Press control-d to bookmark this page.</p>
<FORM ACTION="/auth/logout.html">
<INPUT type="submit" name="logout" value="Logout">
</FORM>
</font>
</body>
</html>
Customizing Authentication Reply-Message to Captive Portal Users
In ArubaOS 6.4.x and earlier versions, captive portal authentication displayed pre-defined strings such
Authentication Successful and Authentication Failed to users in the log-in page. So, response sent by
RADIUS server through the Reply-Message was not forwarded by Authentication module to the Captive
Portal module.
ArubaOS 6.5 introduces the support for customizing authentication Reply-Message to captive portal users in the log-in page for better user experience. The purpose behind the Reply-Message is to return appropriate information to the captive portal system.
For example, ClearPass can send a RADIUS-reject for various reasons, such as, authentication failed, bandwidth limit exceeded, max. session reached, max. devices used. In ArubaOS 6.4.x, the user returns Authentication failed message for all the reasons. In ArubaOS 6.5, ClearPass can now include the reason why it is rejecting in the Reply-Message. So, ClearPass processes the Reply-Message on the web login form and informs the user that The max. number of sessions has been reached is the reason for authentication failure.
So, another RADIUS attribute is added in the reply message to the Captive Portal module from
Authentication module with the following two restrictions: n n n n
There can be multiple Reply-Message attributes in a packet but only the first attribute is considered.
The length of the reply message is limited to 256 characters.
RADIUS server and Authentication servers are required to be configured accordingly to send the reply message against authentication success or failure scenarios
This feature is implemented in the following ways:
For internal captive portal case l
In case of authentication success: Welcome page with the addition of custom defined Reply-Message is displayed.
l
In case of authentication failure: Log-in page is displayed again with the custom defined Reply-Message.
For external captive portal case: l l
In case of authentication success: Redirected to the welcome page.
In case of authentication failure: Failure reason is mentioned on the initial screen
Customizing the Pop-Up box
In order to customize the Pop-Up box, you must first customize your Welcome page. Once you have customized your welcome page, then you can configure your custom page to use a pop-up box. The default
HTML for the pop-up box is:
<html>
<body bgcolor=white text=000000>
<font face="Verdana, Arial, Helvetica, sans-serif" size=+1>
<b>Logout</b></font>
<p>
ArubaOS 6.5.3.x
| User Guide Captive Portal Authentication | 344
<a href="/auth/logout.html"> Click to Logout </a>
</body>
</html>
If you wish your users to be able to logout using this pop-up box, then you must include a reference to
/auth/logout.html Once a user accesses this URL then the controller will log them out. It is easiest to simply edit the above HTML to suit your users and then upload the resulting file to the controller using the WebUI under
Configuration > Management > Captive Portal > Upload custom pages and choose "content” as the page type.
Once you have completed your HTML, then you must get the clients to create the pop-up box once they have logged into the controller. This is done by inserting the following code into your welcome page text and reuploading the welcome page text to your controller.
Common things to change: n n n n
URL: set the URL to be the name of the pop-up HTML file that you created and uploaded. This should be preceded by "/upload/".
Width: set w to be the required width of the pop-up box.
Height: set h to be the required height of the pop-up box.
Title: set the second parameter in the window.open command to be the title of the pop-up box. Be sure to include the quotes as shown:
<script language="JavaScript"> var url="/upload/popup.html"; var w=210; var h=80; var x=window.screen.width - w - 20; var y=window.screen.height - h - 60; window.open(url, 'logout',
"toolbar=no,location=no,width="+w+",height="+h+",top="+y+",left="+x+",screenX="+x+",screenY
="+y);
</script>
Customizing the Logged Out Box
In order to customize the Logged Out box, you must first customize your Welcome page and also your Pop-Up box. To customize the message that occurs after you have logged out then you need to replace the URL that the pop-up box will access in order to log out with your own HTML file.
First you must write the HTML web page that will actually log out the user and will also display page that you wish. An example page is shown below. The key part that must be included is the <iframe>..</iframe> section.
This is the part of the HTML that actually does the user logging out. The logout is always performed by the client accessing the /auth/logout.html file on the controller and so it is hidden in the html page here in order to get the client to access this page and for the controller to update its authentication status. If a client does not support the iframe tag, then the text between the <iframe> and the </iframe> is used. This is simply a 0 pixel sized image file that references /auth/logout.html. Either method should allow the client to logout from the controller.
Everything else can be customized.
<html>
<body bgcolor=white text=000000>
<iframe src='/auth/logout.html' width=0 height=0 frameborder=0><img src=/auth/logout.html
width=0 height=0></iframe>
<P><font face="Verdana, Arial, Helvetica, sans-serif" size=+1>
You have now logged out.</font></P>
345 | Captive Portal Authentication ArubaOS 6.5.3.x | User Guide
<form> <input type="button" onclick="window.close()" name="close" value="Close
Window"></form>
</body>
</html>
After writing your own HTML, then you need to ensure that your customized pop-up box will access your new logged out file. In the pop-up box example above, you simply replace the "/auth/logout.html" with your own file that you upload to the controller. For example, if your customized logout HTML is stored in a file called
"loggedout.html" then your "pop-up.html" file should reference it like this:
<html>
<body bgcolor=white text=000000>
<font face="Verdana, Arial, Helvetica, sans-serif" size=+1>
<b>Logout</b></font>
<p>
<a href="/upload/loggedout.html"> Click to Logout </a>
</body>
</html>
Creating Walled Garden Access
On the Internet, a walled garden typically controls a user’s access to web content and services. The walled garden directs the user’s navigation within particular areas to allow access to a selection of websites or prevent access to other websites.
The Walled Garden feature can be used with the PEFNG or PEFV licenses.
Walled garden access is needed when an external or internal captive portal is used. A common example could be a hotel environment where unauthenticated users are allowed to navigate to a designated login page (for example, a hotel website) and all its contents.
Users who do not sign up for Internet service can view “allowed” websites (typically hotel property websites).
The website names must be DNS-based (not IP address based) and support the option to define wildcards.
HTTP or HTTPS proxy does not work when walled garden is implemented as a user-role using domain name
ACL. For example, user alias example.com any permit .
When a user attempts to navigate to other websites not configured in the white list walled garden profile, the user is redirected back to the login page. In addition, the black listed walled garden profile is configured to explicitly block navigation to websites from unauthenticated users.
In the WebUI
1. Navigate to Advanced Services > Stateful Firewall > Destination.
2. Click Add to add a destination name.
3. Select the controller IP version, IPv4 or IPv6, from the IP Version drop-down menu.
4. In the Destination Name field, enter a name and click Add .
5. Select name from the Rule Type drop-down menu and add a hostname or wildcard with domain name to which an unauthenticated user is redirected.
6. Click Apply .
7. Navigate to Configuration > Security > Authentication > L3 Authentication.
8. Select Captive Portal Authentication Profile.
ArubaOS 6.5.3.x
| User Guide Captive Portal Authentication | 346
9. To allow users to access a domain, enter the destination name that contains the allowed domain names in the White List field. This stops unauthenticated users from viewing specific domains such as a hotel website.
A rule in the white list must explicitly permit a traffic session before it is forwarded to the controller. The last rule in the white list denies everything else.
10.To deny users access to a domain, enter the destination name that contains prohibited domain names in the Black List field. This prevents unauthenticated users from viewing specific websites.
11.Click
Apply .
In the CLI
This example configures a destination named Mywhite-list and adds the domain names, example.com and example.net to that destination. It then adds the destination name Mywhite-list (which contains the allowed domain names example.com and example.net) to the white list.
(host)(config)# netdestination "Mywhite-list"
(host)(config)#name example.com
(host)(config)#name example.net
(host) (config) #aaa authentication captive-portal default
(host)(Captive Portal Authentication Profile "default")#white-list Mywhite-list n
Enabling Captive Portal Enhancements
ArubaOS introduces the following enhancements in Captive Portal:
Location information such as AP name and AP group name have been included in the Captive Portal redirect
URL. The following example shows a Captive Portal redirect URL that contains the AP name and the AP group name: https://securelogin.example.com/cgibin/login?cmd=login&mac=00:24:d7:ed:84:14&ip=10.15.104.13&essid=example-testtunnel&apname=ap135&apgroup=example&url=http%3A%2F%2Fwww%2Eespncricinfo%2Ecom%2F n n n n n n
A new option redirect-url is introduced in the Captive Portal Authentication profile which allows you to redirect the users to a specific URL after the authentication is complete.
Captive Portal Login URL length has been increased from 256 characters to 2048 characters.
Support for “?” (question mark) inside the Captive Portal login URL has been added.
A new field, description has been introduced in the netdestination and netdestination6 commands to provide a description about the netdestination up to 128 characters long.
Support for configuring Whitelist in Captive Portal has been introduced.
Support for bypassing Captive Portal landing page has been introduced.
The Captive Portal enhancements are available on Tunnel and Split-Tunnel forwarding modes.
Configuring the Redirect-URL
You can configure the Captive Portal redirect URL using the following commands:
(host) (config) # aaa authentication captive-portal REDIRECT
(host) (Captive Portal Authentication Profile "REDIRECT") #redirect-url <absolute-URL>
Example:
(host) (config) # aaa authentication captive-portal REDIRECT
(host) (Captive Portal Authentication Profile "REDIRECT") #redirect-url https://test-login.php
347 | Captive Portal Authentication ArubaOS 6.5.3.x | User Guide
Configuring the Login URL
You can configure a Captive Portal login URL up to 2048 characters using the following commands:
(host) (config) # aaa authentication captive-portal LOGIN
(host) (Captive Portal Authentication Profile "LOGIN")#login-page
"http://10.17.36.100/login.php?isinit=1&mac=00:11:22:33:44:55&loginURL=https://captiveportallogin.test.aero/auth/index.html&originalURL=&statusURL=&error=&logginIn”
You can configure the login URL with “?” (question mark) character in it provided the URL containing the question mark is within the double quotes.
Defining Netdestination Descriptions
You can provide a description (up to 128 characters) for the netdestination using the CLI.
Use the following commands to provide description for an IPv4 netdestination:
(host) (config) #netdestination Local-Server
(host) (config-dest) #description “This is a local server for IPv4 client registration”
Use the following commands to provide description for an IPv6 netdestination:
(host) (config) #netdestination6 Local-Server6
(host) (config-dest) #description “This is a local server for IPv6 client registration”
The following command displays the details of the specified IPv4 netdestination:
(host) (config-dest) #show netdestination Local-Server
1
2
3
Local-Server Description: This is a local server for IPv4 client registration
-------------------------------------------------------------------------------
Position Type IP addr Mask-Len/Range
-----------------------------name name name
0.0.0.1
0.0.0.2
0.0.0.3
yahoomail mycorp cricinfo
The following command displays the details of the specified IPv6 netdestination:
(host) (config-dest) #show netdestination Local-Server6
1
2
3
Local-Server6 Description: This is a local server for IPv6 client registration
-------------------------------------------------------------------------------
Position Type IP addr Mask-Len/Range
-----------------------------name 0.0.0.1
yahoomail name 0.0.0.2
mycorp name 0.0.0.3
cricinfo
Configuring a Whitelist
You can now configure a Whitelist in Captive Portal using the CLI.
Configuring the Netdestination for a Whitelist:
Use the following commands to configure a netdestination alias for Whitelist:
(host) (config) #netdestination whitelist
(host) (config-dest) #description guest_whitelist
(host) (config-dest) #name mycorp
Associating a Whitelist to Captive Portal Profile
Use the following CLI commands to associate a whitelist to the Captive profile:
(host) (config) #aaa authentication captive-portal CP_Profile
ArubaOS 6.5.3.x
| User Guide Captive Portal Authentication | 348
(host) (Captive Portal Authentication Profile "CP_Profile”) #white-list whitelist
Applying a Captive Portal Profile to a User-Role
Use the following commands to apply the Captive Portal profile to a user-role:
(host) (config) # user-role guest_role
(host) (config-role) #session-acl logon-control
(host) (config-role) #session-acl captiveportal
(host) (config-role) #captive-portal CP_Profile
Verifying a Whitelist Configuration
Use the following commands to verify the whitelist alias:
(host) (config) #show netdestination whitelist whitelist Description: guest_whitelist
--------------------------------------
Position Type IP addr Mask-Len/Range
------------------------------
1 name 0.0.0.6
mycorp
Verifying a Captive Portal Profile Linked to a Whitelist
Use the following commands to verify the Captive Portal profile linked to the whitelist:
(host) (config) #show aaa authentication captive-portal CP_Profile
Captive Portal Authentication Profile "CP_Profile"
-----------------------------------------------------------------
Parameter
---------
Value
-----
Default Role
Default Guest Role
Server Group
Redirect Pause guest guest default
10 sec
User Login
Guest Login
Logout popup window
Use HTTP for authentication
Logon wait minimum wait
Logon wait maximum wait logon wait CPU utilization threshold
Max Authentication failures
Enabled
Disabled
Enabled
Disabled
5 sec
10 sec
60 %
0
Show FQDN
Use CHAP (non-standard)
Login page
Welcome page
Disabled
Disabled
/auth/index.html
/auth/welcome.html
Show Welcome Page
Add switch IP address in the redirection URL
Yes
Disabled
Adding user vlan in redirection URL Disabled
Add a controller interface in the redirection URL N/A
Allow only one active user session
White List
Black List
Show the acceptable use policy page
Redirect URL
Disabled whitelist
N/A
Disabled
N/A
Verifying Dynamic ACLs for a Whitelist
Use the following commands to verify the dynamically created ACLs for the whitelist:
(host) (config) #show rights guest_role
349 | Captive Portal Authentication ArubaOS 6.5.3.x | User Guide
Derived Role = 'guest_role'
Up BW:No Limit Down BW:No Limit
L2TP Pool = default-l2tp-pool
PPTP Pool = default-pptp-pool
Periodic reauthentication: Disabled
ACL Number = 79/0
Max Sessions = 65535
Captive Portal profile = CP_Profile access-list List
----------------
Position Name
-----------
1
2
CP_Profile_list_operations logon-control
3 captiveportal
CP_Profile_list_operations
-----------------------------------------
Location
--------
Priority Source Destination Service Action TimeRange Log Expired Queue TOS 8021P
Blacklist Mirror DisScan ClassifyMedia IPv4/6
------------------------------------------------------------
-------------------------------------
1 user whitelist svc-http permit
4
Low
2 user whitelist svc-https permit
4
Low logon-control
-------------
Priority Source Destination Service Action TimeRange Log Expired Queue TOS 8021P
Blacklist Mirror DisScan ClassifyMedia IPv4/6
------------------------------------------------------------
------------------------------------
1 user any udp 68 deny
4
Low
2 any any Low
3
4 any any any any svc-icmp permit
4 svc-dns permit
4 svc-dhcp permit
4
Low
Low
5 any any svc-natt permit
4
Low captiveportal
-------------
Priority Source Destination Service Action
TOS 8021P Blacklist Mirror DisScan ClassifyMedia IPv4/6
----------------------------------
-------------------------------------------
1 user controller svc-https
2 user any svc-http dst-nat 8081
4 dst-nat 8080
4
3 user any
4 user any svc-https dst-nat 8081
4 svc-http-proxy1 dst-nat 8088
4
5
6 user user any any svc-http-proxy2 dst-nat 8088
4 svc-http-proxy3 dst-nat 8088
4
Expired Policies (due to time constraints) = 0
TimeRange
---------
Log
---
Expired
-------
Queue
-----
Low
Low
Low
Low
Low
Low
ArubaOS 6.5.3.x
| User Guide Captive Portal Authentication | 350
Verifying DNS Resolved IP Addresses for Whitelisted URLs
Use the following command to verify the DNS resolved IP addresses for the whitelisted URLs:
(host) #show firewall dns-names ap-name <AP-name>
Example:
(host) #show firewall dns-names ap-name ap135
2
3
0
1
Firewall DNS names
------------------
Index
-----
Name
---bugzilla cricinfo yahoo mycorp
Id
--
10
9
1
6
Num-IP
------
1
0
0
1
List
----
0.0.0.0
1.1.1.1
Bypassing Captive Portal Landing Page
An increasing number of user sessions in Captive Portal pre-authenticated role, repeatedly request the Captive
Portal login page from the controller. This impacts the number of browser-based user login requests handled per second by the controller. This eventually delays the loading of the Captive Portal page and logging into
Captive Portal. Most of the increased activities are from non-browser based applications running on smart phones and tablets.
When this feature is disabled, the controller sends 200 OK status code message to the now-browser based apps so that the apps stop sending repeated requests to the controller. This reduces the load of the httpd process on the controller. This feature is enabled by default.
You can enable this feature from the controller CLI. On enabling this feature, non-browser apps continue to request Captive Portal login page from the controller. This increases the load of the httpd process of the controller.
(host) (config) #web-server profile
(host) (Web Server Configuration) #bypass-cp-landing-page
The landing page contains the meta-refresh tag to reload the page using real browser applications.
Netdestination for AAAA Records
The Captive Portal whitelist supports IPv6 addresses for netdestination. Add an IPv6 netdestination with the domain name that is to be whitelisted and specify this destination as whitelist in Captive Portal profile. This adds the required ACL policies to permit IPv6 traffic to the domain.
In the CLI
(host) (config) #netdestination6 <string> name <host_name>
351 | Captive Portal Authentication ArubaOS 6.5.3.x | User Guide
Chapter 16
Virtual Private Networks
Wireless networks can use virtual private network (VPN) connections to further secure wireless data from attackers. The Aruba controller can be used as a VPN concentrator that terminates all VPN connections from both wired and wireless clients.
This chapter describes the following topics: n n n n n n n n n n
Planning a VPN Configuration on page 352
Working with VPN Authentication Profiles on page 356
Configuring a Basic VPN for L2TP/IPsec on page 358
Configuring a VPN for L2TP/IPsec with IKEv2 on page 362
Configuring a VPN for Smart Card Clients on page 367
Configuring a VPN for Clients with User Passwords on page 368
Configuring Remote Access VPNs for XAuth on page 369
Working with Remote Access VPNs for PPTP on page 370
Working with Site-to-Site VPNs on page 371
Working with VPN Dialer on page 379
n n
Planning a VPN Configuration
You can configure the controller for the following types of VPNs:
Remote access VPNs: These VPNs allow hosts such as telecommuters or traveling employees to connect to private networks (e.g. a corporate network) over the Internet. Each host must run VPN client software, which encapsulates and encrypts traffic, then sends it to a VPN gateway at the destination network. The controller supports the following remote access VPN protocols: l
Layer-2 Tunneling Protocol over IPsec (L2TP/IPsec) l l l l
Point-to-Point Tunneling Protocol (PPTP)
XAUTH IKE/IPsec
IKEv2 with Certificates
IKEv2 with EAP
Site-to-site VPNs: Site-to-site VPNs allow networks, like branch office networks, to connect to other networks like a corporate network. Unlike a remote access VPN, hosts in a site-to-site VPN do not run VPN client software. All traffic for the other network is sent and received through a VPN gateway, which encapsulates and encrypts the traffic.
Before enabling VPN authentication, you must configure the following: n n
The default user role for authenticated VPN clients. See
Roles and Policies on page 381
for information about configuring user roles .
The authentication server group used by the controller to validate clients. See
Authentication Servers on page 179
for configuration details.
A server-derived role, if present, takes precedence over the default user role.
ArubaOS 6.5.3.x
| User Guide Virtual Private Networks | 352
You then specify the default user role and authentication server group in the VPN authentication default profile, as described in the sections below.
ESP Tunnel Mode is the only supported IPsec mode of operation. ArubaOS does not support AH and Transport modes.
Selecting an IKE protocol
Controllers running ArubaOS version 6.1 and later support both IKEv1 and the newer IKEv2 protocol to establish IPsec tunnels. Though both IKEv1 and IKEv2 support the same suite-B cryptographic algorithms,
IKEv2 is a simpler, faster, and more reliable protocol than IKEv1.
If your IKE policy uses IKEv2, you should be aware of the following caveats when you configure your VPN: n n n
ArubaOS does not support separate pre-shared keys for both directions of an exchange; both peers must use the same pre-shared key. ArubaOS does not support mixed authentication with both pre-shared keys and certificates; each authentication exchange requires a single authentication type. For example, if a client authenticates with a pre-shared key, the controller must also authenticate with a pre-shared key.
ArubaOS does not support IKEv2 Authentication Headers (AH) or IP Payload Compression Protocol
(IPComp).
Starting from ArubaOS 6.5, ArubaOS supports the functionality where the non-Aruba devices can fragment the large IKE_AUTH packets using the standards described in the RFC 7383 – Internet Key Exchange
Protocol Version 2 (IKEv2) message fragmentation when the Aruba device acts as a responder and not as an initiator.
Understanding Suite-B Encryption Licensing
Aruba controllers support Suite-B cryptographic algorithms when the Advanced Cryptography (ACR) license is installed.
describes the Suite-B algorithms supported by ArubaOS IKE Policies and IPsec tunnels. For further details on configuring a VPN to use Suite-B algorithms, see
Configuring a VPN for L2TP/IPsec with IKEv2 on page 362 .
Table 81: Suite-B Algorithms Supported by the ACR License
IKE Policies Suite-B for IPsec tunnels hash: SHA-256-128, SHA-384-192
Diffie-Hellman (DH) Groups: ECP-256, ECP-384
Encryption: AES-128-GCM, AES-256-GCM
Perfect Forward Secrecy (PFS): ECP-256, ECP-
384
— Pseudo-Random Function (PRF): HMAC_SHA_256, HMAC_
SHA_384
Suite-B certificates: ECDSA-256, ECDSA-384 —
The ArubaOS hardware supports IKE Suite-B AES-128-GCM and AES-256-GCM encryption. ArubaOS software performs the IKE Suite-B Diffie-Hellman and Certificate-based signature operations, and hash, PFS, and PRF algorithm functions.
The following VPN clients support Suite-B algorithms when establishing an L2TP/IPsec VPN:
353 | Virtual Private Networks ArubaOS 6.5.3.x | User Guide
Table 82: Client Support for Suite-B
Client Operating
System n Windows client
NOTE: Windows client operating system includes
Windows XP and later versions.
Supported Suite-B
IKE Authentication n n
IKEv1 Clients using ECDSA
Certificates
IKEv1/IKEv2 Clients using ECDSA
Certificates with L2TP/PPP/EAP-TLS certificate user-authentication
Supported Suite-B IPsec
Encryption n n
AES-128-GCM
AES-256-GCM
The Suite-B algorithms described in
are also supported by Site-to-Site VPNs between Aruba controllers, or between an Aruba controller and a server running Windows 2008 or StrongSwan 4.3.
Working with IKEv2 Clients
Not all clients support both the IKEv1 and IKEv2 protocols. Only the clients in
support IKEv2 with the following authentication types:
Table 83: VPN Clients Supporting IKEv2
Windows Client StrongSwan 4.3 Client n n n
Machine authentication with Certificates
User name password authentication using EAP-
MSCHAPv2 or PEAP-
MSCHAPv2
User smart-card authentication with EAP-
TLS / IKEv2
NOTE: Windows clients using
IKEv2 do not support preshared key authentication.
NOTE: Windows client operating system includes
Windows 7 and later versions.
n n n
Machine authentication with Certificates
User name password authentication using EAP-
MSCHAPv2
Suite-B cryptographic algorithms
VIA Client n n
Machine authentication with
Certificates
User name password authentication using EAP-MSCHAPv2 n
EAP-TLS using Microsoft cert repository
NOTE: VIA clients using IKEv2 do not support pre-shared key authentication.
Support for VIA-Published Subnets
Starting from ArubaOS 6.5, a new feature is introduced in controllers to support IKEv2 configuration (CFG_SET) payload for VIA clients. This is in conformation with section 3.15 of RFC 5996 applicable for route-based VPNs.
This feature is disabled by default.
When this feature is enabled, controllers can accept CFG_SET message with the INTERNAL_IP4_SUBNET attribute type. When a controller receives this message, which consists of an IP address and netmask, it adds an entry to the datapath route table that points to the VIA’s inner IP address as the next-hop. The datapath route-cache for the VIA’s inner IP will point to the tunnel endpoint associated with the VIA.
Enabling Support for VIA-Published Subnets
In the WebUI
To enable this feature in the controller, perform the following steps in the WebUI:
1. Navigate to Configuration > Advanced Services > VPN Services > IPSEC .
2. Select the Allow VIA to push subnets check box under L2TP and XAUTH Parameters .
3. Click Apply .
ArubaOS 6.5.3.x
| User Guide Virtual Private Networks | 354
In the CLI
To enable this feature in the controller, execute the following command:
(host) (config) #crypto-local isakmp allow-via-subnet-routes
To disable the feature in the controller, execute the following command:
(host) (config)#no crypto-local isakmp allow-via-subnet-routes
Verifying Support for VIA-Published Subnets
To verify if the controller is configured to accept subnet routes from VIA clients, execute the following command:
(host) #show crypto-local isakmp allow-via-subnet-routes
Controller will accept subnet routes from via client
Limitations
The following limitations are applicable to the CFG_SET support feature for controllers: n
This feature supports only IPv4 n
This feature is only applicable with IKEv2
For details about how to configure and run VIA on Linux platform, refer to the VIA 2.3.1 Linux Edition Release
Notes .
Understanding Supported VPN AAA Deployments
If you want to simultaneously deploy various combinations of a VPN client, RAP-psk, RAP-certs, and CAP on the same controller, see
Each row in this table specifies the allowed combinations of AAA servers for simultaneous deployment.
Configuration rules include the following: n n n n
RAP-certs can only use LocalDB-AP.
An RAP-psk and RAP-cert can only terminate on the same controller if the RAP VPN profile’s AAA server uses
Local-db.
If an RAP-psk is using an external AAA server, the RAP-cert cannot be terminated on the same controller.
Clients can use any type of AAA server, regardless of the RAP/CAP authentication configuration server.
Table 84: Supported VPN AAA Deployments
VPN Client RAP psk
External AAA server 1
External AAA server 1
External AAA server 1
LocalDB
LocalDB
LocalDB
External AAA server 1
External AAA server 2
LocalDB
External AAA server 1
RAP certs
LocalDB-AP
Not supported
Not supported
LocalDB-AP
Not supported
CAP
CPSEC-whitelist
CPSEC-whitelist
CPSEC-whitelist
CPSEC-whitelist
CPSEC-whitelist
Working with Certificate Groups
The certificate group feature allows you to access multiple types of certificates on the same controller. To create a certificate group, use the following command:
355 | Virtual Private Networks ArubaOS 6.5.3.x | User Guide
(host) (config) #crypto-local isakmp certificate-group server-certificate server_certificate ca-certificate ca_certificate
You can view existing certificate groups using: show crypto-local isakmp certificate-group
Working with VPN Authentication Profiles
VPN Authentication profiles identify an authentication server, the server group to which the authentication server belongs, and a user-role for authenticated VPN clients. There are three predefined VPN authentication profiles: default , default-rap , and default-cap . These different profiles allow you to use different authentication servers, user-roles, and IP pools for VPN, remote AP, and campus AP clients.
You can configure the default and default-rap profiles, but not the default-cap profile.
Table 85: Predefined Authentication Profile settings
Parameter
Default Role for authenticated users
Description
The role that will be assigned to the authenticated users.
default default-vpnrole
Maximum allowed authentication failures
Check certificate common name against AAA server
The number of contiguous authentication failures before the station is blacklisted.
0 (feature is disabled) disabled default-rap default-cap default-vpnrole enabled sys-ap-role
0
0 (feature is disabled)
0 (feature is disabled) enabled
ArubaOS 6.5.3.x
| User Guide Virtual Private Networks | 356
Parameter
Export VPN IP address as a route
User idle timeout
PAN firewalls Integration
Description default
When enabled, this causes any VPN client address to be exported to
OSPF using IPC.
NOTE: Note that the
Framed-IP-Address attribute is assigned the
IP address as long as the any server returns the attribute. The Framed-IP-
Address value always has a higher priority than the local address pool.
The user idle timeout value for this profile.
Specify the idle timeout value for the client in seconds. Valid range is
30-15300 in multiples of
30 seconds. Enabling this option overrides the global settings configured in the AAA timers. If this is disabled, the global settings are used.
Requires IP mapping at
Palo Alto Networks firewalls.
enabled disabled disabled default-rap enabled
N/A disabled default-cap enabled
N/A disabled
To edit the default VPN authentication profile:
1. Navigate to the Configuration > Advanced Services > All Profiles > Wireless LAN > VPN
Authentication page.
2. In the Profiles list of the left window pane, select the default VPN Authentication Profile.
3. Click the Default Role drop-down list and select the default user role for authenticated VPN users. (For detailed information on creating and managing user roles and policies, see
Roles and Policies on page 381
.)
4. (Optional) If you use client certificates for user authentication, select the Check certificate common name against AAA server checkbox to verify that the certificate's common name exists in the server.
This parameter is enabled by default in the default-cap and default-rap VPN profiles, and disabled by default on all other VPN profiles.
5. (Optional) Set Max Authentication failures to an integer value. The default value is 0, which disables this feature.
6. (Optional) Regardless of how an authentication server is contacted, the Export VPN IP address as a route option causes any VPN client address to be exported to OSPF using IPC. Note that the Framed-IP-
Address attribute is assigned the IP address as long as any server returns the attribute. The Framed-IP-
Address value always has a higher priority than the local address pool.
7. (Optional) Enabling PAN Firewall Integration requires IP mapping at Palo Alto Networks firewalls. (For more information about PAN firewall integration, see
Palo Alto Networks Firewall Integration on page 695
.)
8. Click Apply .
9. In the Default profile menu in the left window pane, select Server Group .
10.From the Server Group drop-down list, select the server group to be used for VPN authentication.
11.Click
Apply .
357 | Virtual Private Networks ArubaOS 6.5.3.x | User Guide
To configure VPN authentication via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #aaa authentication vpn default cert-cn-lookup clone default-role < role> export-route max-authentication-failure < number> pan-integration radius-accounting < server_group_name > server-group < name> user-idle-timeout < seconds >
Configuring a Basic VPN for L2TP/IPsec
The combination of Layer-2 Tunneling Protocol and Internet Protocol Security (L2TP/IPsec) creates a highlysecure technology that enables VPN connections across public networks such as the Internet. L2TP/IPsec provides a logical transport mechanism on which to transmit PPP frames, tunneling, or encapsulation, so that the PPP frames can be sent across an IP network. L2TP/IPsec relies on the PPP connection process to perform user authentication and protocol configuration. With L2TP/IPsec, the user authentication process is encrypted using the Data Encryption Standard (DES) or Triple DES (3DES) algorithm.
L2TP/IPsec using IKEv1 requires two levels of authentication: n n
Computer-level authentication with a preshared key to create the IPsec security associations (SAs) to protect the L2TP-encapsulated data.
User-level authentication through a PPP-based authentication protocol using passwords, SecureID, digital certificates, or smart cards after successful creation of the SAs.
Note that only Windows 7 (and later versions), StrongSwan 4.3, and VIA clients support IKEv2. For additional information on the authentication types supported by these clients, see
Working with IKEv2 Clients on page 354 .
Configuring a Basic L2TP VPN in the WebUI
Use the following procedures in the WebUI to configure a remote access VPN for L2TP IPsec for clients using pre-shared keys, certificates, or EAP for authentication: n n n n n n n n
Defining Authentication Method and Server Addresses on page 363
Defining Address Pools on page 363
Enabling Source NAT on page 363
Selecting Certificates on page 364
Defining IKEv1 Shared Keys on page 360
Configuring IKE Policies on page 364
Setting the IPsec Dynamic Map on page 365
Finalizing WebUI changes on page 366
Defining Authentication Method and Server Addresses
1. Define the authentication method and server addresses.
2. Navigate to Configuration > Advanced Services > VPN Services and click the IPSEC tab.
3. To enable L2TP, select Enable L2TP (this is enabled by default).
4. Select the authentication method for IKEv1 clients. Currently supported methods include: l
Password Authentication Protocol (PAP)
ArubaOS 6.5.3.x
| User Guide Virtual Private Networks | 358
l l
Extensible Authentication Protocol (EAP)
Challenge Handshake Authentication Protocol (CHAP) l l
Microsoft Challenge Handshake Authentication Protocol (MSCHAP)
Microsoft Challenge Handshake Authentication Protocol version 2 (MSCHAPv2)
5. Configure the IP addresses of the primary and secondary Domain Name System (DNS) servers and the primary and secondary Windows Internet Naming Service (WINS) Server that are pushed to the VPN client.
Defining Address Pools
Next, define the pool from which the clients are assigned addresses:
1. In the Address Pools section of the IPSEC tab, click Add to open the Add Address Pool page.
2. Specify the pool name, start address, and end address.
3. Click Done .
RADIUS Framed-IP-Address for VPN Clients
IP addresses are usually assigned to VPN clients from configured local address pools. However, the Framed-IP-
Address attribute that is returned from a RADIUS server can be used to assign the IP address.
VPN clients use different mechanisms to establish VPN connections with the controller, such as IKEv1, IKEv2,
EAP, or a user certificate. Regardless of how the RADIUS server is contacted for authentication, the Framed-IP-
Address attribute is assigned the IP address as long as the RADIUS server returns the attribute. The Framed-IP-
Address value always has a higher priority than the local address pool.
Enabling Source NAT
In the Source NAT section of the IPSEC tab, select Enable Source NAT if the IP addresses of clients must be translated to access the network. If source NAT is enabled, click the NAT pool drop-down list and select an existing NAT pool. To create a new NAT pool:
1. Navigate to Configuration > Network > IP > NAT Pools .
2. Click Add .
3. In the Pool Name field, enter a name for the new NAT pool, up to 63 alphanumeric characters.
4. In the Start IP address field, enter the dotted-decimal IP address that defines the beginning of the range of source NAT addresses in the pool.
5. In the End IP address field, enter the dotted-decimal IP address that defines the end of the range of source
NAT addresses in the pool.
6. In the Destination NAT IP Address field, enter the destination NAT IP address in dotted-decimal format.
If you do not enter an address into this field, the NAT pool will use the destination NAT IP 0.0.0.0
.
7. Click Done.
8. Navigate to Configuration > Advanced Services > VPN Services and click the IPSEC tab to return to the
IPsec window.
9. Click the NAT Pool drop-down list and select the NAT pool you just created.
Selecting Certificates
If you are configuring a VPN to support machine authentication using certificates, define the IKE Server certificates for VPN clients using IKE. Note that these certificates must be imported into the controller, as described in
Management Access on page 844 .
1. Select the server certificate for client machines using IKE by clicking the IKE Server Certificate drop-down list and selecting an available certificate name.
359 | Virtual Private Networks ArubaOS 6.5.3.x | User Guide
2. If you are configuring a VPN to support clients using certificates, you must also assign one or more trusted
CA certificates to VPN clients.
a. Under CA Certificate Assigned for VPN-clients, click Add .
b. Select a CA certificate from the drop-down list of CA certificates imported in the controller.
c. Click Done .
d. Repeat the above steps to add additional CA certificates.
Defining IKEv1 Shared Keys
If you are configuring a VPN to support IKEv1 and clients using pre-shared keys, you can configure a global IKE key or IKE key for each subnet. Make sure that this key matches the key on the client.
1. In the IKE Shared Secrets section of the IPsec tab, click Add to open the Add IKE Secret page .
2. Enter the subnet and subnet mask. To make the IKE key global, specify 0.0.0.0 for both values.
3. Enter the IKE Shared Secret and Verify IKE Shared Secret.
4. Click Done .
Configuring IKE Policies
ArubaOS contains several predefined default IKE policies, as described in
Table 86 . If you do not want to use
any of these predefined policies, you can use the procedures below to edit an existing policy or create your own custom IKE policy instead.
The IKE policy selections, along with any preshared key, must be reflected in the VPN client configuration. When using a third-party VPN client, set the VPN configuration on clients to match the choices made above. In case the Aruba dialer is used, these configurations must be made on the dialer prior to downloading the dialer onto the local client.
1. Scroll down to the IKE Policies section of the IPSEC tab, then click Edit to edit an existing policy or click Add to create a new policy.
2. Enter a number into the Priority field to set the priority for this policy. Enter a priority of 1 for the configuration to take priority over the Default setting.
3. Select the IKE version. Click the Version drop-down list and select V1 for IKEv1 or V2 for IKEv2.
4. Set the Encryption type. Click the Encryption drop-down list and select one of the following encryption types: n n n n
DES
3DES
AES128
AES192 n
AES256
5. Set the HASH function. Click the Hash drop-down list and select one of the following hash types: n n
MD5
SHA n n
SHA1-96
SHA2-256-128 n
SHA2-384-192
6. ArubaOS VPNs support client authentication using pre-shared keys, RSA digital certificates, or Elliptic Curve
Digital Signature Algorithm (ECDSA) certificates. To set the authentication type for the IKE rule, click the
Authentication drop-down list and select one of the following: n
Pre-Share (for IKEv1 clients using pre-shared keys)
ArubaOS 6.5.3.x
| User Guide Virtual Private Networks | 360
n n
RSA (for clients using certificates)
ECDSA-256 (for clients using certificates) n
ECDSA-384 (for clients using certificates)
7. Diffie-Hellman is a key agreement algorithm that allows two parties to agree upon a shared secret, and is used within IKE to securely establish session keys. To set the Diffie–Hellman Group for the ISAKMP policy, click the Diffie–Hellman Group drop-down list and select one of the following groups: n n
Group 1: 768-bit Diffie–Hellman prime modulus group.
Group 2: 1024-bit Diffie–Hellman prime modulus group.
n n n
Group 14: 2048-bit Diffie–Hellman prime modulus group.
Group 19: 256-bit random Diffie–Hellman ECP modulus group.
Group 20: 384-bit random Diffie–Hellman ECP modulus group.
Configuring Diffie–Hellman Group 1 and Group 2 types are not permitted if the controller is operating in FIPS mode.
8. Set the Security Association Lifetime to define the lifetime of the security association in seconds. The default value is 7200 seconds. To change this value, uncheck the default checkbox and enter a value between 300 and 86400 seconds.
9. Click Done .
Setting the IPsec Dynamic Map
Dynamic maps enable IPsec SA negotiations from dynamically addressed IPsec peers. ArubaOS has a predefined IPsec dynamic map for IKEv1. If you do not want to use this predefined map, you can use the procedures below to edit an existing map or create your own custom IPsec dynamic map instead:
1. Scroll down to the IPsec Dynamic Map section of the IPSEC tab, then click Edit by a map name to edit the existing map or click Add to create a new map.
2. In the Name field, enter a name for the dynamic map.
3. In the Priority field, enter a priority number for the map. Negotiation requests for security associations try to match the highest-priority map first. If that map does not match, the negotiation request continues down the list to the next-highest priority map until a match is made.
4. Click the Version drop-down list and select V1 to create an IPsec map for remote peers using IKEv1.
5. (Optional) Configure Perfect Forward Secrecy (PFS) settings for the dynamic peer by assigning a Diffie-
Hellman prime modulus group. PFS provides an additional level of security by ensuring that the IPsec SA key was not derived from any other key, and therefore, cannot be compromised if another key is broken.
Click the Set PFS drop-down list and select one of the following groups: n n n
Group 1: 768-bit Diffie–Hellman prime modulus group.
Group 2: 1024-bit Diffie–Hellman prime modulus group.
Group 14: 2048-bit Diffie–Hellman prime modulus group.
n n
Group 19: 256-bit random Diffie–Hellman ECP modulus group.
Group 20: 384-bit random Diffie–Hellman ECP modulus group.
6. Select the transform set for the map to define a specific encryption and authentication type used by the dynamic peer. Click the Transform Set drop-down list, and select the transform set for the dynamic peer.
To view current configuration settings for an IPsec transform-set, access the command-line interface and issue the command crypto ipsec transform-set tag <transform-set-name> .
361 | Virtual Private Networks ArubaOS 6.5.3.x | User Guide
7. Set the Life Time to define the lifetime of the security association for the dynamic peer in seconds or kilobytes. The default value is 7200 seconds. To change this value, uncheck the default checkbox and enter a value between 300 and 86400 seconds or 1000 and 1000000000 kilobytes.
8. Click Done .
Finalizing WebUI changes
When you have finished configuring your IPsec VPN settings, click Apply to apply the new settings before navigating to other pages.
Configuring a Basic L2TP VPN in the CLI
Use the following procedures to use the command-line interface to configure a remote access VPN for L2TP
IPsec:
1. Define the authentication method and server addresses:
(host)(config) #vpdn group l2tp enable client configuration {dns|wins} <ipaddr1> [<ipaddr2>]
2. Enable authentication methods for IKEv1 clients:
vpdn group l2tp ppp authentication {cache-securid|chap|eap|mschap|mschapv2|pap
3. Create address pools:
(host)(config) #ip local pool <pool> <start-ipaddr> <end-ipaddr>
4. Configure source NAT:
(host)(config) #ip access-list session srcnatuser any any src-nat pool <pool> position 1
5. If you are configuring a VPN to support machine authentication using certificates, define server certificates for VPN clients using IKEv1:
(host)(config) #crypto-local isakmp server-certificate <cert>
6. If you are configuring a VPN to support IKEv1 Clients using pre-shared keys, you can configure a global IKE key by entering 0.0.0.0
for both the address and netmask parameters in the command below, or configure an IKE key for an individual subnet by specifying the IP address and netmask for that subnet: crypto isakmp key < key> address < ipaddr|> netmask < mask>
7. Define IKE Policies:
(host)(config) #crypto isakmp policy <priority> encryption {3des|aes128|aes192|aes256|des} version v1|v2 authentication {pre-share|rsa-sig|ecdsa-256ecdsa-384} group {1|2|19|20} hash {md5|sha|sha1-96|sha2-256-128|sha2-384-192} lifetime <seconds>
Configuring a VPN for L2TP/IPsec with IKEv2
Only clients running Windows 7 (and later versions), StrongSwan 4.3, and Aruba VIA support IKEv2. For additional information on the authentication types supported by these clients, see “
Working with IKEv2 Clients on page 354 ."
Configuring an L2TP VPN with IKEv2 in the WebUI
Use the following procedures to in the WebUI to configure a remote access VPN for IKEv2 clients using certificates.
n n
Defining Authentication Method and Server Addresses on page 363
Defining Address Pools on page 363
ArubaOS 6.5.3.x
| User Guide Virtual Private Networks | 362
n n n n n
Enabling Source NAT on page 363
Selecting Certificates on page 364
Configuring IKE Policies on page 364
Setting the IPsec Dynamic Map on page 365
Finalizing WebUI changes on page 366
Defining Authentication Method and Server Addresses
1. Define the authentication method and server addresses.
2. Navigate to Configuration > Advanced Services > VPN Services and click the IPSEC tab.
3. To enable L2TP, select Enable L2TP (this is enabled by default).
4. Select the authentication method for IKEv1 clients. The currently supported methods include: l l l l
Password Authentication Protocol (PAP)
Extensible Authentication Protocol (EAP)
Challenge Handshake Authentication Protocol (CHAP)
Microsoft Challenge Handshake Authentication Protocol (MSCHAP) l
Microsoft Challenge Handshake Authentication Protocol version 2 (MSCHAPv2)
5. Configure the IP addresses of the primary and secondary Domain Name System (DNS) servers and primary and secondary Windows Internet Naming Service (WINS) Servers that are pushed to the VPN client.
Defining Address Pools
Next, define the pool from which the clients are assigned addresses.
1. In the Address Pools section of the IPSEC tab, click Add to open the Add Address Pool page.
2. Specify the pool name, the start address, and the end address.
3. Click Done .
Enabling Source NAT
In the Source NAT section of the IPSEC tab, select Enable Source NAT if the IP addresses of clients must be translated to access the network. If source NAT is enabled, click the NAT pool drop-down list and select an existing NAT pool. To create a new NAT pool:
1. Navigate to Configuration > Network > IP > NAT Pools .
2. Click Add .
3. In the Pool Name field, enter a name for the new NAT pool, up to 63 alphanumeric characters.
4. In the Start IP address field, enter the dotted-decimal IP address that defines the beginning of the range of source NAT addresses in the pool.
5. In the End IP address field, enter the dotted-decimal IP address that defines the end of the range of source
NAT addresses in the pool.
6. In the Destination NAT IP Address field, enter the destination NAT IP address in dotted-decimal format.
If you do not enter an address into this field, the NAT pool uses the destination NAT IP 0.0.0.0
.
7. Click Done to close the NAT pools tab.
8. Navigate to Configuration > Advanced Services > VPN Services and click the IPSEC tab to return to the
IPSEC window.
9. Click the NAT Pool drop-down list and select the NAT pool you just created.
363 | Virtual Private Networks ArubaOS 6.5.3.x | User Guide
Selecting Certificates
To configure the VPN to support machine authentication using certificates, define the IKE Server certificates for
VPN clients using IKEv2. Note that these certificate must be imported into the controller, as described in
.
1. Select the IKEv2 server certificate for client machines using IKEv2 by clicking the IKEv2 Server Certificate drop-down list and selecting an available certificate name.
2. If you are configuring a VPN to support IKEv2 clients using certificates, you must also assign one or more trusted CA certificates to VPN clients.
a. Under CA Certificate Assigned for VPN-clients, click Add .
b. Select a CA certificate from the drop-down list of CA certificates imported in the controller.
c. Click Done .
d. Repeat the above steps to add additional CA certificates.
Configuring IKE Policies
ArubaOS contains several predefined default IKE policies, as described in
Table 86 . If you do not want to use
any of these predefined policies, you can use the procedures below to delete a factory-default policy, edit an existing policy, or create your own custom IKE policy instead.
The IKE policy selections must be reflected in the VPN client configuration. When using a third-party VPN client, set the VPN configuration on clients to match the choices made above. In case the Aruba dialer is used, these configurations must be made on the dialer prior to downloading the dialer onto the local client.
1. Scroll down to the IKE Policies section of the IPSEC tab, then click Edit to edit an existing policy or click Add to create a new policy.
You can also delete a predefined factory-default IKE policy by clicking Delete .
2. Enter a number into the Priority field to set the priority for this policy. Enter a priority of 1 for the configuration to take priority over the Default setting.
3. Select the IKE version. Click the Version drop-down list and select V2 for IKEv2.
4. Set the Encryption type. Click the Encryption drop-down list and select one of the following encryption types: n
DES n n n n
3DES
AES128
AES192
AES256
5. Set the HASH function. Click the Hash drop-down list and select one of the following hash types: n
MD5 n n
SHA
SHA1-96 n n n
SHA2-256-128
SHA2-384-192
6. ArubaOS VPNs support IKEv2 client authentication using RSA digital certificates or Elliptic Curve Digital
Signature Algorithm (ECDSA) certificates. To set the authentication type for the IKE rule, click the
Authentication drop-down list and select one of the following types: n
RSA
ECDSA-256
ArubaOS 6.5.3.x
| User Guide Virtual Private Networks | 364
n
ECDSA-384
7. Diffie-Hellman is a key agreement algorithm that allows two parties to agree upon a shared secret, and is used within IKE to securely establish session keys. To set the Diffie–Hellman Group for the ISAKMP policy, click the Diffie–Hellman Group drop-down list and select one of the following groups: n n n n
Group 1: 768-bit Diffie–Hellman prime modulus group.
Group 2: 1024-bit Diffie–Hellman prime modulus group.
Group 19: 256-bit random Diffie–Hellman ECP modulus group.
Group 20: 384-bit random Diffie–Hellman ECP modulus group.
Configuring Diffie–Hellman Group 1 and Group 2 types are not permitted if the controller is operating in the FIPS mode.
8. Set the Pseudo-Random Function (PRF) value. This algorithm is an HMAC function to used to hash certain values during the key exchange: n
PRF-HMAC-MD5 n n
PRF-HMAC-SHA1
PRF-HMAC-SHA256 n
PRF-HMAC-SHA384
9. Set the Security Association Lifetime to define the lifetime of the security association in seconds. The default value is 7200 seconds. To change this value, uncheck the default checkbox and enter a value between 300 and 86400 seconds.
10.Click
Done.
Setting the IPsec Dynamic Map
Dynamic maps enable IPsec SA negotiations from dynamically addressed IPsec peers. ArubaOS has predefined
IPsec dynamic maps for IKEv2. If you do not want to use these predefined maps, you can use the procedures below to delete a factory-default map, edit an existing map, or create your own custom IPsec dynamic map instead:
In the WebUI
1. Scroll down to the IPsec Dynamic Map section of the IPSEC tab, then click Edit by a map name to edit an existing map, or click Add to create a new map.
You can also delete a predefined factory-default dynamic map by clicking Delete .
2. In the Name field, enter a name for the dynamic map.
3. In the Priority field, enter a priority number for the map. Negotiation requests for security associations try to match the highest-priority map first. If that map does not match, the negotiation request continues down the list to the next-highest priority map until a match is made.
4. Click the Version drop-down list, and select v2 to create a map for remote peers using IKEv2.
5. (Optional) Configure Perfect Forward Secrecy (PFS) settings for the dynamic peer by assigning a Diffie-
Hellman prime modulus group. PFS provides an additional level of security by ensuring that the IPsec SA key was not derived from any other key, and therefore can not be compromised if another key is broken.
Click the Set PFS drop-down list and select one of the following groups: n n n
Group 1: 768-bit Diffie–Hellman prime modulus group.
Group 2: 1024-bit Diffie–Hellman prime modulus group.
Group 14: 2048-bit Diffie–Hellman prime modulus group.
365 | Virtual Private Networks ArubaOS 6.5.3.x | User Guide
n n
Group 19: 256-bit random Diffie–Hellman ECP modulus group.
Group 20: 384-bit random Diffie–Hellman ECP modulus group.
6. Select the transform set for the map to define a specific encryption and authentication type used by the dynamic peer. Click the Transform Set drop-down list, and select the transform set for the dynamic peer.
To view current configuration settings for an IPsec transform-set, access the command-line interface and issue the command crypto ipsec transform-set tag <transform-set-name>.
7. Set the Life Time to define the lifetime of the security association for the dynamic peer in seconds or kilobytes. The default value is 7200 seconds. To change this value, uncheck the default checkbox and enter a value between 300 and 86400 seconds or 1000 and 1000000000 kilobytes.
8. Click Done .
Finalizing WebUI changes
When you have finished configuring your IPsec VPN settings, click Apply to apply the new settings before navigating to other pages.
Configuring an L2TP VPN with IKEv2 in the CLI
Use the following procedures in the CLI to configure a remote access VPN for L2TP IPsec using IKEv2:
1. Define the server addresses:
(host)(config) #vpdn group l2tp enable client configuration {dns|wins} < ipaddr1> [< ipaddr2> ]
2. Enable authentication methods for IKEv2 clients:
(host)(config) #crypto isakmp eap-passthrough {eap-mschapv2|eap-peap|eap-tls}
3. Create address pools:
(host)(config) #ip local pool <pool> <start-ipaddr> <end-ipaddr>
4. Configure source NAT:
(host)(config) #ip access-list session srcnat user any any src-nat pool <pool> position 1
5. If you are configuring a VPN to support machine authentication using certificates, define server certificates for VPN clients using IKEv2:
(host)(config) #crypto-local isakmp server-certificate <cert>
The IKE pre-shared key value must be between 6-64 characters. To configure a pre-shared IKE key that contains nonalphanumeric characters, surround the key with quotation marks.
For example: crypto-local isakmp key "key with spaces" fqdn-any .
6. Define IKEv2 Policies:
(host)(config) #crypto isakmp policy <priority> encryption {3des|aes128|aes192|aes256|des} version v2 authentication {pre-share|rsa-sig|ecdsa-256ecdsa-384} group {1|2|19|20} hash {md5|sha|sha1-96|sha2-256-128|sha2-384-192} prf PRF-HMAC-MD5|PRF-HMAC-SHA1|PRF-HMAC-SHA256|PRF-HMAC-SHA384 lifetime <seconds>
7. Define IPsec Tunnel parameters:
(host)(config) #crypto ipsec mtu <max-mtu>
ArubaOS 6.5.3.x
| User Guide Virtual Private Networks | 366
transform-set <transform-set-name> esp-3des|esp-aes128|esp-aes128-gcm|esp-aes192|espaes256|esp-aes256-gcm|esp-des esp-md5-hmac|esp-null-mac|esp-sha-hmac
Configuring a VPN for Smart Card Clients
This section describes how to configure a remote access VPN on the controller for Microsoft L2TP/IPsec clients with smart cards, which contain a digital certificate allowing user-level authentication without requiring the user to enter a username and password. As described earlier in this chapter, L2TP/IPsec requires two levels of authentication: IKE SA (machine) authentication and user-level authentication with an IKEv2 or PPP-based authentication protocol.
Microsoft clients running Windows 7 (and later versions) support both IKEv1 and IKEv2. Microsoft clients using
IKEv2 support machine authentication using RSA certificates (but not ECDSA certificates or pre-shared keys) and smart card user-level authentication with EAP-TLS over IKEv2.
Windows 7 (and later version) clients without smart cards also support user password authentication using EAP-
MSCHAPv2 or PEAP-MSCHAPv2.
n n
Working with Smart Card clients using IKEv2
To configure a VPN for Windows 7 (and later version) clients using smart cards and IKEv2, follow the procedure described in
Configuring a VPN for L2TP/IPsec with IKEv2 on page 362 , and ensure that the following settings
are configured: n n
L2TP is enabled
User Authentication is set to EAP-TLS
IKE version is set to V2
The IKE policy is configured for ECDSA or RSA certificate authentication
Working with Smart Card Clients using IKEv1
Microsoft clients using IKEv1, including clients running Windows Vista or earlier versions of Windows, only support machine authentication using a pre-shared key. In this scenario, user-level authentication is performed through an external RADIUS server using PPP EAP-TLS, and client and server certificates are mutually authenticated during the EAP-TLS exchange. During the authentication, the controller encapsulates EAP-TLS messages from the client into RADIUS messages and forwards them to the server.
On the controller, you must configure the L2TP/IPsec VPN with EAP as the PPP authentication and IKE policy for preshared key authentication of the SA.
On the RADIUS server, you must configure a remote access policy to allow EAP authentication for smart card users and select a server certificate. The user entry in Microsoft Active Directory must be configured for smart cards.
To configure an L2TP/IPsec VPN for clients using smart cards and IKEv1, ensure that the following settings are configured:
1. On a RADIUS server, a remote access policy must be configured to allow EAP authentication for smart card users and to select a server certificate. The user entry in Microsoft Active Directory must be configured for smart cards. (For detailed information on creating and managing user roles and policies, see
n n
Ensure that the RADIUS server is part of the server group used for VPN authentication.
Configure other VPN settings as described in
Configuring a VPN for L2TP/IPsec with IKEv2 on page 362
, while selecting the following options:
367 | Virtual Private Networks ArubaOS 6.5.3.x | User Guide
l l l l
Select Enable L2TP
Select EAP for the Authentication Protocol.
Define an IKE Shared Secret to be used for machine authentication. (To make the IKE key global, specify
0.0.0.0 and 0.0.0.0 for both subnet and subnet mask.)
Configure the IKE policy for Pre-Share authentication.
Configuring a VPN for Clients with User Passwords
This section describes how to configure a remote access VPN on the controller for L2TP/IPsec clients with user passwords. As described earlier, L2TP/IPsec requires two levels of authentication: IKE SA authentication and user-level authentication with the PAP authentication protocol. IKE SA is authenticated with a preshared key, which you must configure as an IKE shared secret on the controller. User-level authentication is performed by the controller’s internal database.
On the controller, you must configure the following: n n n n n
AAA database entries for username and passwords
VPN authentication profile, which defines the internal server group and the default role assigned to authenticated clients
L2TP/IPsec VPN with PAP as the PPP authentication (IKEv1 only).
(For IKEv1 clients) An IKE policy for preshared key authentication of the SA.
(For IKEv2 clients) A server certificate to authenticate the controller to clients, and a CA certificate to authenticate VPN clients.
In the WebUI
Use the following procedure to configure L2TP/IPsec VPN for username/password clients through the WebUI:
1. Navigate to the Configuration > Security > Authentication > Servers page.
a. Select Internal DB to view entries for the internal database.
b. Click Add User .
c. Enter the username and password information for the client.
d. Click Enabled to activate this entry on creation.
e. Click Apply .
2. Navigate to the Configuration > Security > Authentication > L3 Authentication window.
a. Under the VPN Authentication profile , select Default > Server Group .
b. Select the internal server group from the Server Group drop-down menu.
c. Click Apply .
3. Navigate to the Configuration > Advanced Services > VPN Services > IPsec window.
a. Select Enable L2TP (this is enabled by default).
b. Select PAP for Authentication Protocols.
4. Configure other VPN settings as described in
Configuring a VPN for L2TP/IPsec with IKEv2 on page 362
, while ensuring that the following settings are selected: n n
In the L2TP and XAUTH Parameters section of the Configuration > VPN Services > IPsec tab, enable L2TP .
In the L2TP and XAUTH Parameters section of the Configuration > VPN Services > IPsec tab, select PAP as the authentication protocol.
ArubaOS 6.5.3.x
| User Guide Virtual Private Networks | 368
In the CLI
The following example uses the command-line interface to configure a L2TP/IPsec VPN for username/password clients using IKEv1:
(host)(config) #vpdn group l2tp enable ppp authentication pap client dns 101.1.1.245
(host)(config) #ip local pool pw-clients 10.1.1.1 10.1.1.250
(host)(config) #crypto isakmp key <key> address 0.0.0.0 netmask 0.0.00
(host)(config) #crypto isakmp policy 1 authentication pre-share
Next, issue the following command in enable mode to configure client entries in the internal database:
(host)(config) #local-userdb add username <name> password <password>
Configuring Remote Access VPNs for XAuth
Extended Authentication (XAuth) is an Internet Draft that permits user authentication after IKE Phase 1 authentication. This authentication prompts the user for a username and password, in which user credentials are authenticated through an external RADIUS or LDAP server or the controller’s internal database.
Alternatively, the user can initiate client authentication using a smart card, which contains a digital certificate to verify the client credentials. IKE Phase 1 authentication can be done with either an IKE preshared key or digital certificates.
Configuring VPNs for XAuth Clients using Smart Cards
This section describes how to configure a remote access VPN on the controller for Cisco VPN XAuth clients using smart cards. Smart cards contain a digital certificate, allowing user-level authentication without the user entering a username and password. IKE Phase 1 authentication can be done with either an IKE preshared key or digital certificates; for XAuth clients using smart cards, the smart card digital certificates must be used for IKE authentication. The client is authenticated with the internal database on the controller.
On the controller, you must configure the following:
1. Add entries for Cisco VPN XAuth clients to the controller’s internal database, or to an external RADIUS or
LDAP server. For details on configuring an authentication server, see
Authentication Servers on page 179 .
For each client, you need to create an entry in the internal database with the entire Principal name (SubjectAltname in X.509 certificates) or Common Name as it appears on the certificate.
2. Verify that the server with the client data is part of the server group associated with the VPN authentication profile.
3. In the L2TP and XAUTH Parameters section of the Configuration > VPN Services > IPsec tab, enable
L2TP .
4. In the L2TP and XAUTH Parameters section of the Configuration > VPN Services > IPsec tab, enable
XAuth to enable prompting for the username and password.
5. The Phase 1 IKE exchange for XAuth clients can be either Main Mode or Aggressive Mode . Aggressive
Mode condenses the IKE SA negotiations into three packets (versus six packets for Main Mode). In the
Aggressive Mode section of the Configuration > VPN Services > IPsec tab, enter the authentication group name for aggressive mode to associate this setting to multiple clients. Make sure that the group name matches the aggressive mode group name configured in the VPN client software.
369 | Virtual Private Networks ArubaOS 6.5.3.x | User Guide
6. Configure other VPN settings as described in
Configuring a VPN for L2TP/IPsec with IKEv2 on page 362
, while ensuring that the following settings are selected: n
In the L2TP and XAUTH Parameters section of the Configuration > VPN Services > IPSEC tab, enable L2TP .
n n
In the L2TP and XAUTH Parameters section of the Configuration > VPN Services> IPSEC tab, enable XAuth to enable prompting for the username and password.
Define an IKE policy to use RSA or ECDSA authentication.
Configuring a VPN for XAuth Clients Using a Username and Password
This section describes how to configure a remote access VPN on the controller for Cisco VPN XAuth clients using passwords. IKE Phase 1 authentication is done with an IKE preshared key; users are then prompted to enter their username and password, which is verified with the internal database on the controller.
On the controller, you must configure the following:
1. Add entries for Cisco VPN XAuth clients to the controller’s internal database. For details on configuring an authentication server, see
Authentication Servers on page 179
For each client, you need to create an entry in the internal database with the entire Principal name (SubjectAltname in X.509 certificates) or Common Name as it appears on the certificate.
2. Verify that the server with the client data is part of the server group associated with the VPN authentication profile.
3. Configure other VPN settings as described in
Configuring a VPN for L2TP/IPsec with IKEv2 on page 362
, while ensuring that the following settings are selected: n n n
In the L2TP and XAUTH Parameters section of the Configuration > VPN Services > IPSEC tab, enable L2TP .
In the L2TP and XAUTH Parameters section of the Configuration > VPN Services > IPSEC tab, enable XAuth to enable prompting for the username and password.
The IKE policy must use pre-shared authentication.
Working with Remote Access VPNs for PPTP
Point-to-Point Tunneling Protocol (PPTP) is an alternative to L2TP/IPsec. Like L2TP/IPsec, PPTP provides a logical transport mechanism using tunneling or encapsulation to send PPP frames across an IP network. PPTP relies on the PPP connection process to perform user authentication and protocol configuration.
With PPTP, data encryption begins after PPP authentication and connection process is completed. PPTP connections are encrypted through Microsoft Point-to-Point Encryption (MPPE), which uses the Rivest-Shamir-
Aldeman (RSA) RC-4 encryption algorithm. PPTP connections require user-level authentication through a PPPbased authentication protocol (MSCHAPv2 is the currently-supported method).
In the WebUI
1. Navigate to the Configuration > Advanced Services > VPN Services > PPTP page.
2. To enable PPTP, select Enable PPTP .
3. Select either MSCHAP or MSCHAPv2 as the authentication protocol.
4. Configure IP addresses of the primary and secondary DNS servers.
5. Configure the primary and secondary WINS Server IP addresses that are pushed to the VPN Dialer.
6. Configure the VPN Address Pool.
a. Click Add . The Add Address Pool window displays.
ArubaOS 6.5.3.x
| User Guide Virtual Private Networks | 370
b. Specify the pool name, start address, and end address.
c. Click Done .
7. Click Apply to apply the changes before navigating to other pages.
In the CLI
(host)(config) #vpdn group pptp enable client configuration {dns|wins} <ipaddr1> [<ipaddr2>] ppp authentication {mschapv2}
(host)(config) #pptp ip local pool <pool> <start-ipaddr> <end-ipaddr> n n n
Working with Site-to-Site VPNs
Site-to-site VPNs allow sites in different locations to securely communicate with each other over a Layer-3 network such as the Internet. You can use Aruba controllers instead of VPN concentrators to connect the sites.
You can also use a VPN concentrator at one site and a controller at the other site.
The Aruba controller supports the following IKE SA authentication methods for site-to-site VPNs:
Preshared key: Note that the same IKE shared secret must be configured on both the local and remote sites.
Suite-B cryptographic algorithms
Digital certificates: You can configure an RSA or ECDSA server certificate and a CA certificate for each siteto-site VPN IPsec map configuration. If you use certificate-based authentication, the peer must be identified by its certificate subject name, distinguished name (for deployments using IKEv2), or by the peer’s IP address (for IKEv1). For more information about importing server and CA certificates into the controller, see
Management Access on page 844 .
Certificate-based authentication is only supported for site-to-site VPN between two controllers with static IP addresses. IKEv1 site-to-site tunnels cannot be created between master and local controllers.
Enable IP compression in an IPsec map to reduce the size of data frames transmitted over a site-to-site VPN between 7200 Series or 7000 Series controllers using IKEv2 authentication. IP compression can reduce the time required to transmit the frame across the network. When this hardware-based compression feature is enabled, the quality of unencrypted traffic (such as Lync or Voice traffic) is not compromised by increased latency or decreased throughput. IP compression is disabled by default.
This feature is only supported in an IPv4 network using IKEv2. This feature cannot be enabled on a 7205 controller or on a site-to-site VPN established using IKEv1.
Working with Third-Party Devices
Aruba controllers can use IKEv1 or IKEv2 to establish a site-to-site VPN with another Aruba controller or thirdparty remote client devices. Devices running Microsoft ® Windows 2008 can use Suite-B cryptographic algorithms and IKEv1 to support authentication using RSA or ECDSA. StrongSwan ® 4.3 devices can use IKEv2 to support authentication using RSA or ECDSA certificates, Suite-B cryptographic algorithms, and pre-shared keys. These two remote clients are tested to work with Aruba controllers using Suite-B cryptographic algorithm.
Working with Site-to-Site VPNs with Dynamic IP Addresses
ArubaOS supports site-to-site VPNs with two statically addressed controllers, or with one static and one dynamically addressed controller. Two methods are supported to enable dynamically addressed peers:
371 | Virtual Private Networks ArubaOS 6.5.3.x | User Guide
n n
Pre-shared Key Authentication with IKE Aggressive Mode: The Aruba controller with a dynamic IP address must be configured as the initiator of IKE Aggressive-mode for Site-Site VPNs, while the controller with a static IP address must be configured as the responder of IKE Aggressive mode. Note that when the controller is operating in FIPS mode, IKE aggressive mode must be disabled.
X.509 certificates: IPsec peers will identify each other using the subject name of X.509 certificates. IKE operates in main mode when this option is selected. This method is preferred from a security standpoint.
Understanding VPN Topologies
You must configure VPN settings on the controllers at both the local and remote sites. In the following figure, a
VPN tunnel connects Network A to Network B across the Internet.
Figure 53 Site-to-Site VPN Configuration Components
To configure the VPN tunnel on controller A, you must configure the following: n n n n
The source network (Network A)
The destination network (Network B)
The VLAN on which controller A’s interface to the Layer-3 network is located (Interface A in
)
The peer gateway, which is the IP address of controller B’s interface to the Layer-3 network (Interface B in
Configure VPN settings on the controllers at both the local and remote sites.
Configuring Site-to-Site VPNs
Use the following procedures to create a site-to-site VPN through the WebUI or CLI.
In the WebUI
1. Navigate to the Configuration > Advanced Services > VPN Services > Site-to-Site page.
2. In the IPsec Maps section, click Add to open the Add IPsec Map window.
3. Enter a name for this VPN connection in the Name field.
4. In the Priority field, enter a priority level for the IPsec map. Negotiation requests for security associations try to match the highest-priority map first. If that map does not match, the negotiation request continues down the list to the next-highest priority map until a match is made.
5. Select a Source Network Type to specify whether the VPN source , the local network connected to the controller, is defined by an IP address or a VLAN ID.
n
If you selected IP , enter the IP address and netmask for the source network. (See controller A in
) n
If you selected VLAN , click the Source Network VLAN drop-down list and select the VLAN ID for the source network.
ArubaOS 6.5.3.x
| User Guide Virtual Private Networks | 372
6. In the Destination Network and Destination Subnet Mask fields, enter the IP address and netmask for the destination , the remote network to which the local network communicates. (See controller B in
7. Select one of the supported peer gateway types: n n
IP Address : Select this option to identify the remote end point of the VPN tunnel using an IP address.
FQDN : This option allows you to use same FQDN across different branches. The FQDN resolves to different IP addresses for each branch, based on its local DNS setting.
8. Define the Peer Gateway using an IP address or FQDN.
n
If you use IKEv1 to establish a site-to-site VPN for a statically addressed remote peer and selected
IP Address in the previous step, enter the IP address of the interface used by the remote peer to connect to the L3 network in the Peer Gateway field (See Interface B in
).
n n
If you are configuring an IPsec map for a dynamically addressed remote peer, and selected IP Address in the previous step, leave the peer gateway set to its default value of 0.0.0.0
.
If you selected FQDN as the peer gateway type in the previous step, enter the fully qualified domain name for the remote peer.
9. If you use IKEv2 to establish a site-to-site VPN for a statically addressed remote peer, identify the peer device by entering its certificate subject name in the Peer Certificate Subject Name field.
To identify the subject name of a peer certificate, issue the following command in the CLI: s how crypto-local pki servercert <certname> subject
10.The
Security Association Lifetime parameter defines the lifetime of the security association in seconds and kilobytes. The default value is 7200 seconds. To change this value, uncheck the default checkbox and enter a value between 300 and 86400 seconds or 1000 and 1000000000 kilobytes.
11.Click the Version drop-down list and select V1 to configure the VPN for IKEv1, or V2 for IKEv2.
12.(Optional) Click the IKEv Policies drop-down list and select a predefined or custom IKE policy to apply to the IPsec map. For more information on default IKE policies, see
.
13.IKEv2 site-to-site VPNs between master and local 7000 Series controllers support traffic compression between those devices. Select the IP Compression checkbox to enable compression for traffic in the siteto-site tunnel.
14.Select the VLAN containing the interface of the local controller that connects to the Layer-3 network. (See
Interface A in
This determines the source IP address used to initiate IKE. If you select 0 or None , the default is the VLAN of the controller’s IP address (either the VLAN where the loopback IP is configured, or VLAN 1 if no loopback
IP is configured).
15.If you enable Perfect Forward Secrecy (PFS) mode, new session keys are not derived from previously used session keys. Therefore, if a key is compromised, that compromised key does not affect any previous session keys. PFS mode is disabled by default. To enable this feature, click the PFS drop-down list and select one of the following Perfect Forward Secrecy modes: n n n n group1 : 768-bit Diffie–Hellman prime modulus group.
group2 : 1024-bit Diffie–Hellman prime modulus group.
group14 : 2048-bit Diffie–Hellman prime modulus group.
group19 : 256-bit random Diffie–Hellman ECP modulus group.
n group20 : 384-bit random Diffie–Hellman ECP modulus group.
16.Click the Route ACL name drop-down list and select the name of a routing access control list (ACL) to attach a route ACL to inbound traffic on the VPN tunnel interface.
373 | Virtual Private Networks ArubaOS 6.5.3.x | User Guide
When you associate a routing ACL to inbound traffic on a controller terminating an L3 GRE tunnel, that ACL can forward traffic as normal, route traffic to a nexthop router on a nexthop list, or redirect traffic over an
L3 GRE tunnel or tunnel group. For more information on creating a routing ACL, see
17.Select
Pre-Connect to establish the VPN connection, even if there is no traffic being sent from the local network. If you do not select this, the VPN connection is established only when traffic is sent from the local network to the remote network.
18.Select
Trusted Tunnel if traffic between the networks is trusted. If you do not select this, traffic between the networks is untrusted.
19.Select the Enforce NATT checkbox to enforce UDP 4500 for IKE and IPSEC. This option is disabled by default.
20.Select the Force Tunnel Mode checkbox to enforce forced-tunnel mode instead of transport mode for site-to-site IPsec SA. This option is disabled by default.
21.Add one or more transform sets to be used by the IPsec map. Click the Transform Sets drop-down list, select an existing transform set, then click the arrow button by the drop-down list to add that transform set to the IPsec map.
22.For site-to-site VPNs with dynamically addressed peers, enable Dynamically Addressed Peers .
a. Select Initiator if the dynamically addressed switch is the initiator of IKE Aggressive-mode for Site-Site
VPNs, or select Responder if the dynamically addressed switch is the responder for IKE Aggressivemode.
b. In the FQDN field, enter a fully qualified domain name (FQDN) for the controller. If the controller is defined as a dynamically addressed responder, you can select all peers to make the controller a responder for all VPN peers, or select Per Peer ID and specify the FQDN to make the controller a responder for one specific initiator.
23.Select one of the following authentication types: a. For pre-shared key authentication, select Pre-Shared Key , then enter a shared secret in the IKE Shared
Secret and Verify IKE Shared Secret fields. This authentication type is generally required in IPsec maps for a VPN with dynamically addressed peers, but can also be used for a static site-to-site VPN.
b. For certificate authentication, select Certificate , then click the Server Certificate and CA certificate drop-down lists to select certificates previously imported into the controller. See
for more information.
24.Click
Done to apply the site-to-site VPN configuration.
25.Click
Apply .
26.Click the IPSEC tab to configure an IKE policy.
a. Under IKE Policies, click Add to open the IPSEC Add Policy configuration page.
b. Set the Priority to 1 for this configuration to take priority over the Default setting.
c. Set the Version type to match the IKE version you selected in Step 10.
d. Set the Encryption type from the drop-down list .
e. Set the HASH Algorithm from the drop-down list.
f. Set the Authentication to PRE-SHARE if you use pre-shared keys. If you use certificate-based IKE, select
RSA or ECDSA .
g. Set the Diffie–Hellman Group from the drop-down list.
h. The IKE policy selections, including any pre-shared key, must be reflected in the VPN client configuration.
When using a third-party VPN client, set the VPN configuration on clients to match the choices made above. If you use the Aruba dialer, you must configure the dialer prior to downloading the dialer onto the local client.
i.
Click Done to activate the changes.
ArubaOS 6.5.3.x
| User Guide Virtual Private Networks | 374
j.
Click Apply.
In the CLI
To configure a site-to-site VPN with two static IP controllers using IKEv1, issue the following commands in the
CLI:
(host)(config) #crypto-local ipsec-map <name> <priority> src-net <ipaddr> <mask> dst-net <ipaddr> <mask> peer-ip <ipaddr> vlan <id> version v1|v2 peer-cert-dn <peer-dn> pre-connect enable|disable trusted enable
For certificate authentication: set ca-certificate <cacert-name> set server-certificate <cert-name>
(host)(config) #crypto isakmp policy <priority> encryption {3des|aes128|aes192|aes256|des} version v1|v2 authentication {rsa-sig|ecdsa-256ecdsa-384} group {1|2|19|20} hash {md5|sha|sha1-96|sha2-256-128|sha2-384-192} lifetime <seconds>
For pre-shared key authentication:
(host)(config) #crypto-local isakmp key <key> address <ipaddr> netmask <mask>
(host)(config) #crypto isakmp policy <priority> encryption {3des|aes128|aes192|aes256|des} version v1|v2 authentication pre-share group {1|2|19|20} hash {md5|sha|sha1-96|sha2-256-128|sha2-384-192} lifetime <seconds>
To configure site-to-site VPN with a static and dynamically addressed controller that initiates IKE Aggressivemode for Site-Site VPN:
(host)(config) #crypto-local ipsec-map <name> <priority> src-net <ipaddr> <mask> dst-net <ipaddr> <mask> peer-ip <ipaddr>local-fqdn <local_id_fqdn> vlan <id> pre-connect enable|disable trusted enable
For the Pre-shared-key:
(host)(config) #crypto-local isakmp key <key> address <ipaddr> netmask 255.255.255.255
For a static IP controller that responds to IKE Aggressive-mode for Site-Site VPN: crypto-local ipsec-map <name2> <priority> src-net <ipaddr> <mask> dst-net <ipaddr> <mask> peer-ip 0.0.0.0
peer-fqdn fqdn-id <peer_id_fqdn> vlan <id> trusted enable
375 | Virtual Private Networks ArubaOS 6.5.3.x | User Guide
For the Pre-shared-key:
(host)(config) #crypto-local isakmp key <key> fqdn <fqdn-id>
For a static IP controller that responds to IKE Aggressive-mode for Site-Site VPN with one PSK for All FQDNs:
(host)(config) #crypto-local ipsec-map <name2> <priority> src-net <ipaddr> <mask> peer-ip 0.0.0.0
peer-fqdn any-fqdn vlan <id> trusted enable
For the Pre-shared-key for All FQDNs:
(host)(config) #crypto-local isakmp key <key> fqdn-any
Supporting Null Encryption for IKEv1
Starting from ArubaOS 6.5.1, XLP based controllers are supported with null encryption for IKEv1 as an encryption algorithm. This helps in reducing the load on the local router for internet destined traffic.
Null encryption does not increase the security of traffic routed but is used only to imply that no encryption method is used over a particular transmission. Null Encryption can now be configured as an encryption algorithm in transform set, which can be used in any crypto map.
Since null encryption is supported only for IKEv1, it should be used only for crypto maps with version 1.
In the WebUI
To create a new transformation set with null encryption as the encryption algorithm, perform the following steps in the WebUI:
1. Navigate to Configuration > Advanced Services > VPN Services > Advanced tab.
2. Under IPSEC Transform Sets click Add .
3. Enter a name in Transform Set Name .
4. Select ESP-NULL from the Encryption drop-down list.
5. Click Done .
6. Click Apply .
To add the transformation set in the crypto map created, perform the following steps in the WebUI:
1. Navigate to Configuration > Advanced Services > VPN Services > Site-To-Site tab.
2. Under IPSec Maps click Add .
3. Enter a Name .
4. Select the name of the transform set created from the Transforms Sets drop-down list and click <-.
5. Click Done .
6. Click Apply .
In the CLI
Execute the following command to create a new transformation set with null encryption as the encryption algorithm:
(host)(config) #crypto ipsec transform-set test esp-null esp-sha-hmac
Execute the following commands to add the transformation set in the crypto map created:
(host)(config) #crypto-local ipsec-map test_map 500
(host)(config-ipsec-map) #set transform-set test
ArubaOS 6.5.3.x
| User Guide Virtual Private Networks | 376
Adding ANY-ANY Crypto Map
Starting from ArubaOS 6.5.1.0, any-any selectors are negotiated in IKEv1 to enable the option of having numerous tunnels. After pre-connect flag is enabled for IPsec map, IKE triggers the tunnel to the peer ip and proposes any-any traffic selector.
Policy Based Routing (PBR) can also be configured to send specific or all traffic on to the ipsec map and can be applied to any vlan, port, or user role.
Policy Based Routing is required for any-any traffic selector and is supported only for IKEv1.
Data traffic trigger is not supported in ArubaOS 6.5.1.0.
In the WebUI
To enable crypto map to allow any any traffic selector, perform the following steps in the WebUI:
1. Navigate to Configuration > Advanced Services > VPN Services > Advanced tab.
2. Under IPSec Maps click Add .
3. Enter a Name .
4. Select Any option from the Source Network Type field.
5. Select Any option from the Destination Network Type field.
6. Click Done .
7. Click Apply .
In the CLI
Execute the following commands to enable crypto map to allow any any traffic selector:
(host) (config-ipsec-map)# src-net any
(host) (config-ipsec-map)# dst-net any
Execute the following commands to configure PBR to send all or specific traffic onto the IPsec map:
(host) (config) #ip access-list route ipsec-pbr
(host) (config-route-ipsec-pbr)#any any any route ipsec-map <ipsec-map-name>
Execute the following command to apply PBR to vlan, port, or user role:
(host) (config) #interface vlan <id>
(host) (config-subif) #ip access-group <name> in
Detecting Dead Peers
Dead Peer Detection (DPD) is enabled by default on the controller for site-to-site VPNs. DPD, as described in
RFC 3706, “A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers,” uses IPsec traffic patterns to minimize the number of IKE messages required to determine the liveliness of an IKE peer.
After a dead peer is detected, the controller tears down the IPsec session. Once the network path or other failure condition has been corrected, a new IPsec session is automatically re-established.
To configure DPD parameters, issue the following commands through the CLI:
(host)(config) #crypto-local isakmp dpd idle-timeout <idle_seconds> retry-timeout <retry_ seconds> retry-attempts <number>
About Default IKE Policies
ArubaOS includes the following default IKE policies. These policies are predefined, but can be edited and deleted. You can do this in the CLI by using the crypto isakmp policy and crypto dynamic-map commands, or the WebUI by navigating to Advanced Services > VPN Services > IPSEC and using the Delete button next to the default IKE policy or IPsec dynamic map you want to delete.
377 | Virtual Private Networks ArubaOS 6.5.3.x | User Guide
Table 86: Default IKE Policy Settings
Policy
Name
Default protection suite
Default RAP
Certificate protection suite
Default RAP
PSK protection suite
Policy
Number
IKE
Version
10001 IKEv1
Encryption
Algorithm
Hash
Algorithm
Authentication
Method
3DES-168 SHA 160
10002 IKEv1 AES -256 SHA 160
Pre-
Shared
Key
RSA
Signature
10003 IKEv1 AES -256 SHA 160 Pre-
Shared
Key
Default RAP
IKEv2 RSA protection suite
Default
Cluster PSK protection suite
1004
10005
Default IKEv2
RSA protection suite
1006
Default IKEv2
PSK protection suite
10007
Default
Suite-B
128bit
ECDSA protection suite
10008
IKEv2
IKEv1
IKEv2
IKEv2
IKEv2
AES -256
AES -256
AES - 128
AES - 128
AES - 128
SSHA160
SHA160
SHA 96
SHA 96
SHA 256-
128
RSA
Signature
Pre-
Shared
Key
RSA
Signature
Preshared key hmacsha1
ECDSA-
256
Signature
PRF
Method
N/A
N/A
N/A hmacsha1
Pre-
Shared
Key hmacsha1
Diffie-
Hellman
Group
2 (1024 bit)
2 (1024 bit)
2 (1024 bit)
2 (1024 bit)
2 (1024 bit)
2 (1024 bit)
2 (1024 bit) hmacsha2-256
Random
ECP
Group
(256 bit)
ArubaOS 6.5.3.x
| User Guide Virtual Private Networks | 378
Policy
Name
Default
Suite-B 256 bit ECDSA protection suite
Default
Suite-B
128bit IKEv1
ECDSA protection suite
Default
Suite-B
256-bit IKEv1
ECDSA protection suite
Policy
Number
IKE
Version
10009
10010
10011
IKEv2
IKEv1
IKEv1
Encryption
Algorithm
Hash
Algorithm
Authentication
Method
AES -256
AES-GCM-
128
AES-GCM-
256
SHA 384-
192
SHA 256-
128
SHA 256-
128
ECDSA-
384
Signature
ECDSA-
256
Signature
ECDSA-
256
Signature
PRF
Method
Diffie-
Hellman
Group hmacsha2-384
Random
ECP
Group
(384 bit) hmacsha2-256
Random
ECP
Group
(256 bit) hmacsha2-256
Random
ECP
Group
(256 bit)
Working with VPN Dialer
For Windows clients, a dialer can be downloaded from the controller to auto-configure tunnel settings on the client.
Configuring VPN Dialer
Use the following procedures to configure the VPN dialer via the WebUI or CLI:
In the WebUI
1. Navigate to the Configuration > Advanced Services > VPN Services > Dialers page. Click Add to add a new dialer or the Edit tab to edit an existing dialer.
2. Enter the Dialer Name that identifies this setting.
3. Configure the dialer to work with PPTP or L2TP by selecting Enable PPTP or Enable L2TP .
4. Select the authentication protocol. This should match the L2TP or PPTP authentication type configured for the VPN in the Configuration > Advanced Services > VPN Services > IPSEC window.
5. (Optional) Select Send Direct Network Traffic In Clear to enable “split tunneling” functionality so that traffic destined for the internal network is tunneled, while traffic for the Internet is not.
This option is not recommended for security reasons .
6. (Optional) Select Disable Wireless Devices When Client is Wired to allow the dialer to shut-down the wireless interface when it detects that a wired network connection is in use.
7. (Optional) Select Enable SecurID New and Next Pin Mode to enable site-to-site VPN support for SecurID new and next pin modes.
8. For L2TP: l l l
Set the IKE Hash Algorithm to the value defined in the IKE policy on the Advanced Services > VPN
Services > IPSEC window.
If a pre-shared key is configured for an IKE Shared Secret in the VPN Services > IPSEC window, enter the key.
The key you enter in the Dialers window must match the pre-shared key configured on the IPsec page.
379 | Virtual Private Networks ArubaOS 6.5.3.x | User Guide
l l
Select the IPsec Mode Group that matches the Diffie–Hellman Group configured for the IPsec policy.
Select the IPsec Encryption that matches the encryption configured for the IPsec policy.
l
Select the IPsec Hash Algorithm that matches the hash algorithm configured for the IPsec policy.
9. Click Done to apply the changes made prior to navigating to another page.
In the CLI
Issue the following commands in the CLI to configure the VPN dialer:
(host(config) #vpn-dialer <name> enable {dnctclear|l2tp|pptp|secureid_newpinmode|wirednowifi} ike authentication {pre-share <key>|rsa-sig} ike encryption {3des|des} ike group {1|2} ike hash {md5|sha} ipsec encryption {esp-3des|esp-des} ipsec hash {esp-md5-hmac|esp-sha-hmac} ppp authentication {cache-securid|chap|mschap|mschapv2|pap}
Assigning a Dialer to a User Role
The VPN dialer can be downloaded using Captive Portal. For the user-role assigned through Captive Portal, configure the dialer by using the dialer name.
For example, if the Captive Portal client is assigned to the guest role after logging in, and the dialer is called mydialer , configure mydialer as the dialer to be used in the guest role.
In the WebUI
1. Navigate to the Configuration > Security > Access Control > User Roles page.
2. Click Edit for the user role.
3. Under VPN Dialer , select the dialer you configured and click Change .
4. Click Apply .
In the CLI
To configure the Captive Portal dialer for a user-role via the CLI, access the CLI in config mode and issue the following commands:
(host) (config) #user-role <role> dialer <name>
ArubaOS 6.5.3.x
| User Guide Virtual Private Networks | 380
Chapter 17
Roles and Policies
The client in an Aruba user-centric network is associated with a user role , which determines the client’s network privileges, how often it must re-authenticate, and which bandwidth contracts are applicable. A policy is a set of rules that applies to traffic that passes through the Aruba controller. You specify one or more policies for a user role. Finally, you can assign a user role to clients before or after they authenticate to the system.
This chapter describes assigning and creating roles and policies using the ArubaOS CLI or WebUI. Roles and policies can also be configured for WLANs associated with the “default” ap-group via the WLAN Wizard:
Configuration > Wizards > WLAN Wizard . Follow the steps in the workflow pane within the wizard and refer to the help tab for assistance.
Topics in this chapter include: n n n n n n n n
Configuring Firewall Policies on page 381
Creating a Firewall Policy on page 382
Creating a Network Service Alias on page 387
Creating an ACL White List on page 388
Assigning User Roles on page 393
Understanding Global Firewall Parameters on page 399
This chapter describes configuring firewall policies and parameters that relate to IPv4 traffic. See
for information about configuring IPv6 firewall policies and parameters.
Configuring Firewall Policies
A firewall policy identifies specific characteristics about a data packet passing through the Aruba controller and takes some action based on that identification. In an Aruba controller, that action can be a firewall-type action such as permitting or denying the packet, an administrative action such as logging the packet, or a quality of service (QoS) action such as setting 802.1p bits or placing the packet into a priority queue. You can apply firewall policies to user roles to give differential treatment to different users on the same network, or to physical ports to apply the same policy to all traffic through the port.
Firewall policies differ from access control lists (ACLs) in the following ways: n n n
Firewall policies are stateful , meaning that they recognize flows in a network and keep track of the state of sessions. For example, if a firewall policy permits telnet traffic from a client, the policy also recognizes that inbound traffic associated with that session should be allowed.
Firewall policies are bi-directional , meaning that they keep track of data connections traveling into or out of the network. ACLs are normally applied to either traffic inbound to an interface or outbound from an interface.
Firewall policies are dynamic , meaning that address information in the policy rules can change as the policies are applied to users. For example, the alias user in a policy automatically applies to the IP address assigned to a particular user. ACLs typically require static IP addresses in the rule.
You can apply IPv4 and IPv6 firewall policies to the same user role. See
for information about configuring IPv6 firewall policies.
ArubaOS 6.5.3.x
| User Guide Roles and Policies | 381
Working With Access Control Lists (ACLs)
Access control lists (ACLs) are a common way of restricting certain types of traffic on a physical port. ArubaOS provides the following types of ACLs: n n n n n n n n
Standard ACLs permit or deny traffic based on the source IP address of the packet. Standard ACLS can be either named or numbered, with valid numbers in the range of 1-99 and 1300-1399. Standard ACLs use a bitwise mask to specify the portion of the source IP address to be matched.
Extended ACLs permit or deny traffic based on source or destination IP address, source or destination port number, or IP protocol. Extended ACLs can be named or numbered, with valid numbers in the range 100-
199 and 2000-2699.
MAC ACLs are used to filter traffic on a specific source MAC address or range of MAC addresses. Optionally, you can mirror packets to a datapath or remote destination for troubleshooting and debugging purposes.
MAC ACLs can be either named or numbered, with valid numbers in the range of 700-799 and 1200-1299.
Ethertype ACLs are used to filter based on the Ethertype field in the frame header. Optionally, you can mirror packets to a datapath or remote destination for troubleshooting and debugging purposes. Ethertype
ACLs can be either named or numbered, with valid numbers in the range of 200-299.These ACLs can be used to permit IP while blocking other non-IP protocols, such as IPX or AppleTalk.
Service ACLs provide a generic way to restrict how protocols and services from specific hosts and subnets to the controller are used. Rules with this ACL are applied to all traffic on the controller regardless of the ingress port or VLAN.
Routing ACLs forward packets to a device defined by an IPsec map, a next-hop list, a tunnel or a tunnel group.
Geolocation ACL assist in identifying the geographical location of the IP address.
Reputation ACL assists in blocking connectivity to IP addresses classified as malicious.
ArubaOS provides both standard and extended ACLs for compatibility with router software from popular vendors, however firewall policies provide equivalent and greater function than standard and extended ACLs and should be used instead.
You can apply MAC and Ethertype ACLs to a user role, however these ACLs only apply to non-IP traffic from the user.
Support for Desktop Virtualization Protocols
ArubaOS supports desktop virtualization protocols by providing preconfigured ACLs for Citrix and VMware clients. You can apply these ACLs to the user-role when using the Virtual Desktop Infrastructure (VDI) clients.
This ensures that any enterprise application that uses the VDI client performs optimally with appropriate QoS.
Disable the voice aware ARM when applying the ACLs for the VDI clients as the virtual desktop sessions may prevent the ARM scanning.
Creating a Firewall Policy
This section describes how to configure the rules that constitute a firewall policy. A firewall policy can then be applied to a user role (until the policy is applied to a user role, it does not have any effect).
describes required and optional parameters for a rule.
382 | Roles and Policies ArubaOS 6.5.3.x | User Guide
Table 87: Firewall Policy Rule Parameters
Field Description
IP version
Source
(required)
Specifies whether the policy applies to IPv4 or IPv6 traffic.
Source of the traffic, which can be one of the following: n n any: Acts as a wildcard and applies to any source address.
user: This refers to traffic from the wireless client.
n n n host: This refers to traffic from a specific host. When this option is chosen, you must configure the IP address of the host.
network: This refers to a traffic that has a source IP from a subnet of IP addresses.
When this option is chosen, you must configure the IP address and network mask of the subnet.
alias: This refers to using an alias for a host or network. You configure the alias by navigating to the Configuration > Advanced Services > Stateful Firewall >
Destination page.
Destination of the traffic, which can be configured in the same manner as Source.
Destination
(required)
Service
(required)
Type of traffic, which can be one of the following: n any: This option specifies that this rule applies to any type of traffic.
n n n n n application: For session and route policies on a 7000 Series controller, you can create a rule that applies to a specific application type. Click the Application dropdown list and select an application type.
application category: For session and route policies on a 7000 Series controller, you can create a rule that applies to a specific application category. Click the
Application Category drop-down list and select a category type.
web category/ Reputation : For session policies on a 7000 Series controller, you can create a rule that applies to a specific web category or application type. For more information on web category classification, see
tcp: Using this option, you configure a range of TCP port(s) to match for the rule to be applied.
udp: Using this option, you configure a range of UDP port(s) to match for the rule to be applied.
n n service: Using this option, you use one of the pre-defined services (common protocols such as HTTPS, HTTP, and others) as the protocol to match for the rule to be applied. You can also specify a network service that you configure by navigating to the Configuration > Advanced Services > Stateful Firewall > Network
Services page.
protocol: Using this option, you specify a different layer 4 protocol (other than
TCP/UDP) by configuring the IP protocol value.
ArubaOS 6.5.3.x
| User Guide Roles and Policies | 383
Field
Action
(required)
Log (optional)
Mirror
(optional)
Queue
(optional)
Description
The action that you want the controller to perform on a packet that matches the specified criteria. This can be one of the following: n n permit: Permits traffic matching this rule.
drop: Drops packets matching this rule without any notification.
n n n n n n n reject: Drops the packet and sends an ICMP notification to the traffic source.
src-nat: Performs network address translation (NAT) on packets matching the rule.
When this option is selected, you need to select a NAT pool. (If this pool is not configured, you configure a NAT pool by navigating to the Configuration >
Advanced > Security > Advanced > NAT Pools ). Source IP changes to the outgoing interface IP address (implied NAT pool) or from the pool configured
(manual NAT pool). This action functions in tunnel/decrypt-tunnel forwarding mode.
dst-nat: This option redirects traffic to the configured IP address and destination port. An example of this option is to redirect all HTTP packets to the captive portal port on the Aruba controller as used in the pre-defined policy called “captiveportal”.
This action functions in tunnel/decrypt-tunnel forwarding mode. User should configure the NAT pool in the controller.
dual-nat: This option performs both source and destination NAT on packets matching the rule. Forward packets from source network to destination; re-mark them with destination IP of the target network. This action functions in tunnel/decrypt-tunnel forwarding mode. User should configure the NAT pool in the controller.
redirect to tunnel: This option redirects traffic into a GRE tunnel. This option is used primarily to redirect all guest traffic into a GRE tunnel to a DMZ router/switch.
redirect to esi: This option redirects traffic to the specified ESI group. You also specify the direction of traffic to be redirected: forward, reverse, or both directions.
Select a NAT Pool from the NAT Pool drop-down list to add a NAT-POOL for ESI policy.
route: Specify the next hop to which packets are routed, which can be one of the following: l Forward Regularly: Packets are forwarded to their next destination without any changes.
l l l l
Forward to ipsec-map: Packets are forwarded through an IPsec tunnel defined by the specified IPsec map.
Forward to next-hop-list: packets are forwarded to the highest priority active device on the selected next hop list. For more information on next-hop lists, see
Next-Hop Device lists on page 251
.
Forward to tunnel: Packets are forwarded through the tunnel with the specified tunnel ID. For more information on GRE tunnels, see
.
Forward to tunnel group: Packets are forwarded through the active tunnel in a GRE tunnel group. For more information on tunnel groups, see
GRE Tunnel Groups on page 123 .
Logs a match to this rule. This is recommended when a rule indicates a security breach, such as a data packet on a policy that is meant only to be used for voice calls.
Mirrors session packets to datapath or remote destination.
The queue in which a packet matching this rule should be placed.
Select High for higher priority data, such as voice, and Low for lower priority traffic.
384 | Roles and Policies ArubaOS 6.5.3.x | User Guide
Field
Time Range
(optional)
Description
Time range for which this rule is applicable.
Configure time ranges on the Configuration > Security > Access Control > Time
Ranges page.
Pause ARM scanning while traffic is present. Note that you must enable “VoIP Aware
Scanning” in the ARM profile for this feature to work.
Pause ARM
Scanning
(optional)
Black List
(optional)
White List
(optional)
TOS (optional)
802.1p Priority
(optional)
Automatically blacklists a client that is the source or destination of traffic matching this rule. This option is recommended for rules that indicate a security breach where the blacklisting option can be used to prevent access to clients that are attempting to breach the security.
A rule must explicitly permit a traffic session before it is forwarded to the controller.
The last rule in the white list denies everything else.
Configure white list ACLs on the Configuration > Advanced Services> Stateful
Firewall> White List (ACL) page.
Value of type of service (TOS) bits to be marked in the IP header of a packet matching this rule when it leaves the controller.
Value of 802.1p priority bits to be marked in the frame of a packet matching this rule when it leaves the controller.
The following example creates a policy ‘web-only’ that allows web (HTTP and HTTPS) access.
In the WebUI
1. Navigate to the Configuration > Security > Access Control > Policies page on the WebUI.
2. To configure a firewall policy, select the policy type from the Policies title bar. You can select Ethernet ,
Extended, MAC, Route, Session , Standard , Geolocation , or Reputation .
3. Click Add to create a new policy.
4. If you selected All in Step 2, then select the type of policy you are adding from the Policy Type drop-down menu.
5. Click Add to add a rule that allows HTTP traffic.
a. Under Service, select service from the drop-down list.
b. Select svc-http from the scrolling list.
c. Click Add .
6. Click Add to add a rule that allows HTTPS traffic.
a. Under Service, select service from the drop-down list.
b. Select svc-https from the scrolling list.
c. Click Add .
Rules can be re-ordered by using the up and down buttons provided for each rule.
7. Click Apply to apply this configuration. The policy is not created until the configuration is applied.
In the CLI
(host)(config) #ip access-list session web-only
ArubaOS 6.5.3.x
| User Guide Roles and Policies | 385
IP-Classification-Based Firewall
In versions prior to ArubaOS 6.5, firewall policy enforcement relied on L3/L4-L7 information with DPI/WebCC support, this feature is now enhanced to support IP classification based firewall.
To support IP-classification-based firewall, a database containing a list of IP addresses with malicious activities is introduced. This helps in rejecting the traffic sent to or received from those IP addresses classified as malicious based on the policy configured. Using this database, the geographical location of the malicious IP address is also determined, and traffic is permitted or denied after scanning the geography-based rules configured by the administrator.
Once a session is IP classified, the datapath subjects the session through IP classification based firewall policies.
If a match is found, the action determines whether the session should be permitted or denied. Else the default role-based firewall policies are applied to the session.
The IP Classification Based Firewall is applied with the following exceptions: n n n
Traffic originating from VPN and RAP users traveling to a country/region which is blocked by location-based firewall policies, can be exempted from policy enforcement.
Traffic to or from certain IP addresses from regions identified as malicious can be permitted by modifying the whitelist rules.
Traffic routed through a proxy server is also subject to geolocation firewall policy. To prevent incorrect policy enforcement, the firewall performs Deep Packet Inspection (DPI) and retrieves a list of IP addresses.
Then an IP classification lookup in the datapath is done to determine the reputation and geographic location of the client. Once the reputation/location of the client is determined, a check is done against the IP classification access policies to determine if the traffic should be permitted or denied.
To implement the IP Classification feature, two new dashboards have been introduced: n n
In the WebUI
To enable IP Classification based firewall globally:
1. Navigate to the Configuration > Advanced Services > Stateful firewall > Global Setting page.
2. Select the Enable IP Classification checkbox to enable the Traffic and Threats tabs of the Traffic
Analysis page.
3. Click Apply .
To enable Geolocation ACL globally:
1. Navigate to the Configuration > Security > Access Control > Firewall Policies > Policies page .
2. Select the Geolocation filter and select Add .
3. Enter the rule to be applied and select Add .
4. Click Apply .
To enable Reputation ACL globally:
1. Navigate to the Configuration > Security > Access Control > Firewall Policies > Policies page.
2. Select the Reputation filter.
3. Select Deny Inbound Connections from Malicious IP Addresses and Deny Outbound Connections from Malicious IP Addresses to block inbound and outbound connections to malicious IP addresses.
4. Click Apply .
In the CLI
To enable IP reputation / geolocation classification based firewall, execute the following command:
386 | Roles and Policies ArubaOS 6.5.3.x | User Guide
(host)(config) #firewall ip-classification
To view the status of the IP (reputation/geolocation) classification, execute the following command:
(host) (config) #show firewall
To add rules to a geolocation ACL, execute the following command:
(host) (config)#ip access-list geolocation global-geolocation-acl
To add IP reputation rule, execute the following commands:
(host) (config) #ip-reputation deny inbound
(host) (config) #ip-reputation deny outbound
To disable a feature based on the user role, execute the following command:
(host) (config-role) #ip-classification disable
To view a list of IPs that are blocked based on geoloctaion, execute the following command:
(host) #show datapath ip-geolocation
To view the counters for a particular AP, execute the following command:
(host) #show datapath ip-geolocation counters
To view the status of the IPs that are trying to access the system, execute the following command :
(host) #show datapath ip-reputation
To view the IP reputation related options, execute the following commands:
(host) #show datapath ip-reputation ?
counters IP reputation statistics rtc IP reputation real time cache
(host) #show datapath ip-reputation counters
(host) #show datapath ip-reputation rtc
To view the IP reputation / geolocation information for session, execute the following command :
(host) #show datapath session ip-classification
To view the details of a particular access-list, execute the following command:
(host) #show ip access-list global-geolocation-acl
Creating a Network Service Alias
A network service alias defines a TCP, UDP or IP protocol and a list or range of ports supported by that service.
When you create a network service alias, you can use that alias when specifying the network service for multiple session ACLs.
In the WebUI
1. Navigate to the Configuration > Advanced Services> Stateful Firewall > Network Services page on the WebUI.
2. Click Add to create a new alias.
3. Enter a name for the alias in the Service Name field.
4. In the Protocol section, select either TCP or UDP, or select Protocol and enter the IP protocol number of the protocol for which you want to create an alias.
5. In the Port Type section, specify whether you want to define the port by a contiguous range of ports, or by a list of non-contiguous port numbers.
n n
If you selected Range , enter the starting and ending port numbers in the Starting Port and End Port fields.
If you selected list, enter a comma-separated list of port numbers.
ArubaOS 6.5.3.x
| User Guide Roles and Policies | 387
6. To limit the service alias to a specific application, click the Application Level Gateway (ALG) drop-down list and select one of the following service types n n n n dhcp: Service is DHCP dns: Service is DNS ftp: Service is FTP h323: Service is H323 n n n n noe: Service is Alcatel NOE rtsp: Service is RTSP sccp: Service is SCCP sip: Service is SIP n n sips: Service is Secure SIP svp: Service is SVP n n tftp: Service is TFTP vocera: Service is VOCERA
7. Click Apply to save your changes.
In the CLI
To define a service alias via the command-line interface, issue the following command:
(host)(config) #netservice <name> <protocol>|tcp|udp {list <port>,<port>}|{<port> [<port>]}
[ALG <service>]
Creating an ACL White List
The ACL White List consists of rules that explicitly permit or deny session traffic from being forwarded to or blocked from the controller. The white list protects the controller during traffic session processing by prohibiting traffic from being automatically forwarded to the controller if it was not specifically denied in a blacklist. The maximum number of entries allowed in the ACL White List is 64. To create an ACL white list, you must first define a white list bandwidth contract, and then assign it to an ACL.
Creating a Bandwidth Contract in the WebUI
1. Navigate to the Configuration > Advanced Services > Stateful Firewall > White List BW Contracts page.
2. Click Add to create a new contract.
3. In the White list contract name field, enter the name of a bandwidth contract.
4. The Bandwidth Rate field allows you to define a bandwidth rate in either kbps or Mbps. Enter a rate value the Bandwidth rate field, then click the drop-down list and select either kbps or Mbps.
5. Click Done .
Configuring the ACL White List in the WebUI
1. Navigate to the Configuration > Stateful Firewall> ACL White List page.
2. To add an entry, click the Add button at the bottom of the page. The Add New Protocol section displays.
3. Click the Action drop-down list and select Permit or Deny. Permit allows session traffic to be forwarded to the controller while Deny blocks session traffic.
4. Click the IP Version drop-down list and select the IPv4 or IPv6 filter. You need to select one of three following choices from the Source drop-down list: l
For a specific IPv4 or IPv6 filter, select IP/Mask . Enter the IP address and mask of the IPv4 or IPv6 filter in the corresponding fields.
388 | Roles and Policies ArubaOS 6.5.3.x | User Guide
l
For a IPv4 or IPv6 host, select Any and enter the source address.
5. In the IP Protocol Number or IP Protocol field, enter the number for a protocol or select the protocol from the drop-down list used by session traffic.
6. In the Starting Port s field, enter a starting port. This is the first port, in the port range, on which permitted or denied session traffic is running. Port range: 1–65535.
7. In the End Ports field, enter an ending port. This is the last port, in the port range, on which permitted or denied session traffic is running. Port range: 1–65535.
8. (Optional) Click the White list Bandwidth Contract drop-down list and specify the name of a bandwidth contract to apply to the session traffic. For further information on creating Bandwidth Contracts, see
9. Click Done . The ACL displays on the white list section.
10.To delete an entry, click Delete next to the entry you want to delete.
11.Click
Apply to save changes.
Creating a Bandwidth Contract in the CLI
(host)(config) #cp-bandwidth-contract
Configuring the ACL White List in the CLI
Use the following CLI command to create ACL White Lists.
(host) (config)firewall cp
Override Local Network Destination
This feature provides a scalable solution to create a local net destination override. To implement this feature, a new sub-command, host vlan – offset under the netdestination configuration command is introduced. An example and description are as follows: netdestination store host vlan 10 offset 5 host vlan 10 offset 8
With the above, select the subnet (for example, 10.1.1.0/24) assigned to vlan 10 for that store and calculate offsets 5 (10.1.1.5) and 8 (10.1.1.8) from it.
Configure the override local netdestination in the WebUI
1. Navigate to the Configuration > Advanced Services > Stateful Firewall and click Destination tab.
2. Click Add to create a new destination.
a. In the Destination Name field, enter the name of the destination.
b. In the Add rule option, enter the Role Type as Override , the VLAN you want to offset and the VLAN offset number which is the Netmask/range.
Figure 54 Net Destination Override
ArubaOS 6.5.3.x
| User Guide Roles and Policies | 389
c. Click Add .
Configure the override local netdestination in the CLI n n n
Configure the local override netdestination
Show the local override netdestination
Local override netdestination used at AOS
To configure the local override netdestination:
(config) #netdestination store
(config-dest) #?
Brief description about this destination (up to 128 characters in description quote) host invert name
Configure a single IPv4 host
Use all destinations EXCEPT this destination
Configure a single host name or domain, Max 63 characters network no range
(config-dest) #host ?
Configure a IPv4 subnet
Delete Command
Configure a range of IPv4 addresses
A.B.C.D
vlan
IPv4 Address of host
IPv4 Address based on VLAN
(config-dest) #host vlan ?
<1-4094> VLAN ID
(config-dest) #host vlan 55 ?
offset Offset in the VLAN subnet
(config-dest) #host vlan 55 offset ?
<1-254> Offset number in the VLAN subnet
(config-dest) #host vlan 55 offset 36
To show the local override netdestination
#show netdestination store
Name: store
Position Type
-----------
1
IP addr
-------
Mask-Len/Range
-------------override vlan 55 offset 36
How to use the local-override netdestination alias in the controller:
(config) #ip access-list session store-override
(config-sess-store-override)#any alias store any permit
(config-sess-store-override)#alias store any any deny
(config-sess-store-override)#!
(config) #show ip interface brief
Interface vlan 1 vlan 55 loopback
IP Address / IP Netmask
172.72.10.254 / 255.255.255.0
55.55.55.1 / 255.255.255.0
unassigned / unassigned
Admin Protocol up up up
(config) #show acl acl-table | include store-override 81 session override 0 up up up
744 2 3 store-
(config) #show acl ace-table acl 81
744: any 55.55.55.36
255.255.255.255
0 0-0 0-0 f80001:permit
745: 55.55.55.36
255.255.255.255 any 0 0-0 0-0 f80000:deny
746: any any 0 0-0 0-0 f180000:deny
Creating an IP Whitelist
This features allow you to whitelist a range of IP addresses.
390 | Roles and Policies ArubaOS 6.5.3.x | User Guide
In the WebUI
1. Navigate to the Configuration > Advanced Services> Stateful Firewall > IP Whitelist page on the
WebUI.
2. Click Add to create a new range of IP Addresses.
3. Enter IP address range in the Start IP Address and End IP Address fields.
4. Click Done to save the new IP address range, add it to the list of whitelisted IP addresses.
5. Click Apply to update the reputation policy with the information provided and navigate to the Firewall
Policies page.
In the CLI
To add a IP Whitelist entry, execute the following command:
(host) (config) #ip-classification whitelist-db add <A.B.C.D> <A.B.C.D>
User Roles
User roles are comprised of user role settings, firewall policies, and bandwidth contracts. This section describes the procedure to create a new user role, and associate a firewall policy with that role.
This section describes how to create a new user role. When you create a user role, you must specify one or more firewall policies for the role.
In the WebUI
1. Navigate to the Configuration > Security > Access Control > User Roles page.
2. Click Add to create and configure a new user role.
3. Enter a user role name.
4. Under Firewall Policies, click Add .
5. Select one of the following three options to add a policy to the role.
n n n
To use an associate an existing policy to the user role, select Choose from Configured Policies then select an existing policy from the drop-down list.
to create a new policy based upon the settings of an existing policy, select Create New Policy from
Existing Policy drop-down list, then select an existing policy from the drop-down list. The Policies page appears, allowing you to configure a new firewall policy.
To create and configure an entirely new policy, select Create New Policy , then click Create . The
Policies page appears, allowing you to configure a new firewall policy.
For more information on creating a firewall policy, see
Configuring Firewall Policies on page 381
.
6. Click Done to add the policy to the user role.
7. (Optional) If the user role contains more than one firewall policy, use the up and down arrows to assign priorities to each role. The higher the policy on the list, the higher its priority.
8. In the Misc. Configuration section, enter configuration values as described in
.
9. Click Apply.
10.Next, you must assign the user role to a AAA profile. After assigning the user role you can use the show reference user-role <role > command to see the profiles that reference this user role. For more information, see
Assigning User Roles on page 393
ArubaOS 6.5.3.x
| User Guide Roles and Policies | 391
Table 88: User Role Parameters
Field Description
Role name
Re-authentication
Interval (optional)
Role VLAN ID
(optional)
Bandwidth Contract
(optional)
Name of the user role
Time, in minutes, after which the client is required to reauthenticate. Enter a value between 0-4096. 0 disables reauthentication.
Default: 0 (disabled)
By default, a client is assigned a VLAN on the basis of the ingress VLAN for the client to the controller. You can override this assignment and configure the VLAN ID that is to be assigned to the user role. You configure a VLAN by navigating to the Configuration >
Network > VLANs page.
You can assign a bandwidth contract to provide an upper limit to upstream or downstream bandwidth utilized by clients in this role. You can select the Per User option to apply the bandwidth contracts on a per-user basis instead of to all clients in the role.
For more information, see
Configuring Bandwidth Contracts for AppRF 2.0 on page 406 .
VPN Dialer (optional) This assigns a VPN dialer to a user role. For details about VPN dialer, see
.
Select a dialer from the drop-down list and assign it to the user role. This dialer will be available for download when a client logs in using captive portal and is assigned this role.
L2TP Pool (optional) This assigns an L2TP pool to the user role. For more details about L2TP pools, see
Private Networks on page 352 .
Select the required L2TP pool from the list to assign to the user role. The inner IP addresses of VPN tunnels using L2TP will be assigned from this pool of IP addresses for clients in this user role.
PPTP Pool (optional)
Captive Portal Profile
(optional)
This assigns a PPTP pool to the user role. For more details about PPTP pools, see
Private Networks on page 352 .
Select the required PPTP pool from the list to assign to the user role. The inner IP addresses of VPN tunnels using PPTP will be assigned from this pool of IP addresses for clients in this user role.
This assigns a Captive Portal profile to this role. For more details about Captive Portal profiles, see
Captive Portal Authentication on page 312 .
Captive Portal Check for Accounting
Max Sessions
This setting is enabled by default. If disabled, RADIUS accounting is done for an authenticated users irrespective of the captive-portal profile in the role of an authenticated user.
If enabled, accounting is not done as long as the user's role has a captive portal profile on it. Accounting will start when Auth/XML-Add/CoA changes the role of an authenticated user to a role which doesn't have captive portal profile.
This parameter configures the maximum number of sessions per user in this role. If the sessions reach the maximum value, any additional sessions from this user that are reaching the threshold are blocked till the session usage count for the user falls back below the configured limit.
The default is 65535. You can configure any value between 0-65535.
To a delete a user role in the WebUI:
1. Navigate to the Configuration > Security > Access Control > User Roles page.
2. Click the Delete button against the role you want to delete.
You cannot delete a user-role that is referenced to profile or server derived role. Deleting a server referenced role will result in an error. Remove all references to the role and then perform the delete operation.
392 | Roles and Policies ArubaOS 6.5.3.x | User Guide
In the CLI
The commands to associate an access control list (ACL) to a user role vary, depending upon the type of access control list being associated to that role. User roles are applied globally across all controllers, so ethertype, MAC and session ACLs can be applied to global user roles. However, routing access lists may vary between locations, so they are mapped to a user role in a local configuration setting.
To associate the user role with an ethertype, MAC or session ACL, use the command user-role <role> accesslist eth|mac|session <acl> . To associate a user role with a routing ACL, use the routing-policy-map command.
Assigning User Roles
A client is assigned a user role by one of several methods. A role assigned by one method may take precedence over one assigned by a different method. The methods of assigning user roles are, from lowest to highest precedence:
1. The initial user role or VLAN for unauthenticated clients is configured in the AAA profile for a virtual AP (see
).
2. The user role can be derived from user attributes upon the client’s association with an AP (this is known as a user-derived role). You can configure rules that assign a user role to clients that match a certain set of criteria. For example, you can configure a rule to assign the role VoIP-Phone to any client that has a MAC address that starts with bytes xx:yy:zz .User-derivation rules are executed before client authentication.
3. The user role can be the default user role configured for an authentication method, such as 802.1X or VPN.
For each authentication method, you can configure a default role for clients who are successfully authenticated using that method.
4. The user role can be derived from attributes returned by the authentication server and certain client attributes (this is known as a server-derived role ). If the client is authenticated via an authentication server, the user role for the client can be based on one or more attributes returned by the server during authentication, or on client attributes such as SSID (even if the attribute is not returned by the server).
Server-derivation rules are executed after client authentication.
5. The user role can be derived from Aruba Vendor-Specific Attributes (VSA) for RADIUS server authentication.
A role derived from an Aruba VSA takes precedence over any other user roles.
The following sections describe the methods of assigning user roles.
Assigning User Roles in AAA Profiles
An AAA profile defines the user role for unauthenticated clients (initial role) as well as the default user role for
MAC and 802.1X authentication. For additional information on creating AAA profiles, see
WLAN Authentication on page 443 .
In the WebUI
1. Navigate to the Configuration > Security > Authentication > AAA Profiles page.
2. Select the default profile or a user-defined AAA profile.
3. Click the Initial Role drop-down list, and select the desired user role for unauthenticated users.
4. Click the 802.1X Authentication Default Role drop-down list and select the desired user role for users who have completed 802.1X authentication.
5. Click the MAC Authentication Default Role drop-down list and select the desired user role for clients who have completed MAC authentication.
6. Click Apply .
ArubaOS 6.5.3.x
| User Guide Roles and Policies | 393
In the CLI
(host)(config) #aaa profile <profile>
Working with User-Derived VLANs
Attributes derived from the client’s association with an AP can be used to assign the client to a specific role or
VLAN, as user-derivation rules are executed before the client is authenticated.
You configure the user role or VLAN to be assigned to the client by specifying condition rules; when a condition is met, the specified user role or VLAN is assigned to the client. You can specify more than one condition rule; the order of rules is important as the first matching condition is applied. You can optionally add a description of the user rule.
describes the conditions for which you can specify a user role or VLAN.
Table 89: Conditions for a User-Derived Role or VLAN
Rule Type Condition
BSSID: Assign client to a role or VLAN based upon the BSSID of AP to which client is associating.
DHCP-Option: Assign client to a role or
VLAN based upon the DHCP signature ID.
One of the following: n contains n n n n ends with equals does not equal starts with
One of the following: n equals n starts with equals DHCP-Option-77: Assign client to a role or
VLAN based upon the user class identifier returned by DHCP server.
Encryption: Assign client to a role or VLAN based upon the encryption type used by the client.
One of the following: n equals n does not equal
Value
MAC address (xx:xx:xx:xx:xx:xx)
DHCP signature ID.
NOTE: This string is not case sensitive.
string n n n n n n n
Open (no encryption)
WPA/WPA2 AES
WPA-TKIP (static or dynamic)
Dynamic WEP
WPA/WPA2 AES PSK
Static WEP xSec
394 | Roles and Policies ArubaOS 6.5.3.x | User Guide
Rule Type
ESSID: Assign client to a role or VLAN based upon the ESSID to which the client is associated
Location: Assign client to a role or VLAN based upon the AP name to which the client is associated
Condition
One of the following: n contains n n ends with equals n n n does not equal starts with value of (does not take string ; attribute value is used as role)
One of the following: n equals n does not equal
Value string string
MAC address of the client One of the following: n n contains ends with n n n equals does not equal starts with
MAC address (xx:xx:xx:xx:xx:xx)
Understanding Device Identification
The device identification feature allows you to assign a user role or VLAN to a specific device type by identifying a DHCP option and signature for that device. If you create a user rule with the DHCP-Option rule type, the first two characters in the Value field must represent the hexadecimal value of the DHCP option that this rule should match, while the rest of the characters in the Value field indicate the DHCP signature the rule should match. To create a rule that matches DHCP option 12 (host name), the first two characters of the in the Value field must be the hexadecimal value of 12, which is 0C. To create a rule that matches DHCP option 55, the first two characters in the Value field must be the hexadecimal value of 55, which is 37.
The following table describes some of the DHCP options that are useful for assigning a user role or VLAN.
DHCP Option values
DHCP Option
12
55
60
81
Description
Host name
Parameter Request List
Vendor Class Identifier
Client FQDN
Hexadecimal Equivalent
0C
37
3C
51
The device identification features in ArubaOS can also automatically identify different client device types and operating systems by parsing the User-Agent strings in the client’s HTTP packets. To enable this feature, select the Device Type Classification option in the AP’s AAA profile. For details, see
.
Configuring a User-derived VLAN in the WebUI
1. Navigate to the Configuration > Security > Authentication > User Rules page.
ArubaOS 6.5.3.x
| User Guide Roles and Policies | 395
2. Click Add to add a new set of derivation rules. Enter a name for the set of rules, and click Add . The name appears in the User Rules Summary list.
3. In the User Rules Summary list, select the name of the rule set to configure rules.
4. Click Add to add a rule. For Set Type , select the VLAN name or ID from the VLAN the drop-down menu.
(You can select VLAN to create d>erivation rules for setting the VLAN assigned to a client.)
5. Configure the condition for the rule by setting the Rule Type, Condition, Value parameters and optional description of the rule. See
for descriptions of these parameters.
6. Select the role assigned to the client when this condition is met.
7. Click Add .
8. You can configure additional rules for this rule set. When you have added rules to the set, use the up or down arrows in the Actions column to modify the order of the rules. (The first matching rule is applied.)
9. Click Apply .
10.(Optional) If the rule uses the DHCP-Option condition, best practices is to enable the Enforce DHCP parameter in the AP group’s AAA profile, which requires users to complete a DHCP exchange to obtain an IP
Configuring a User-derived Role or VLAN in the CLI
(host)(config) #aaa derivation-rules user < name>
User-Derived Role Example
The example rule shown in
below sets a user role for clients whose host name (DHCP option 12) has a value of 6C6170746F70, which is the hexadecimal equivalent of the ASCII string laptop . The first two digits in the Value field are the hexadecimal value of 12 (which is 0C), followed by the specific signature to be matched.
There are many online tools available for converting ASCII text to a hexadecimal string.
Figure 55 DHCP Option Rule
To identify DHCP strings used by an individual device, access the command-line interface in config mode and issue the command logging level debugging network process dhcpd to include DHCP option values for
DHCP-DISCOVER and DHCP-REQUEST frames in the controller’s log files:
Now, connect the device you want to identify to the network, and issue the CLI command show log network to view the DHCP strings.
Be aware that each device type may not have a unique DHCP fingerprint signature. For example, devices from different manufacturers may use vendor class identifiers that begin with similar strings. If you create a DHCP-
396 | Roles and Policies ArubaOS 6.5.3.x | User Guide
Option rule that uses the starts-with condition instead of the equals condition, the rule may assign a role or
VLAN to more than one device type.
RADIUS Override of User-Derived Roles
This feature introduces a new RADIUS vendor specific attribute (VSA) named “Aruba-No-DHCP-Fingerprint,” value 14. This attribute signals the RADIUS Client (controller) to ignore the DHCP Fingerprint user role and
VLAN change post L2 authentication. This feature applies to both CAP and RAP in tunnel mode and for the L2 authenticated role only.
Configuring a Default Role for Authentication Method
For each authentication method, you can configure a default role for clients who are successfully authenticated using that method. To configure a default role for an authentication method:
In the WebUI
1. Navigate to the Configuration > Security > Authentication page.
2. To configure the default user role for MAC or 802.1X authentication, select the AAA Profiles tab. Select the
AAA profile. Enter the user role for MAC Authentication Default Role or 802.1X Authentication Default Role.
3. To configure the default user role for other authentication methods, select the L2 Authentication or L3
Authentication tab. Select the authentication type (Stateful 802.1X or stateful NTLM for L2
Authentication, Captive Portal or VPN for L3 Authentication), and then select the profile. Enter the user role for Default Role.
4. Click Apply .
For additional information on configuring captive portal authentication, see
Captive Portal Authentication on page 312
.
In the CLI
To configure the default user role for MAC or 802.1X authentication:
(host)(config) #aaa profile < profile>
To configure the default user role for other authentication methods:
(host)(config) #aaa authentication captive-portal|stateful-dot1x|stateful-ntlm|vpn
Configuring a Server-Derived Role
If the client is authenticated through an authentication server, the user role for the client can be based on one or more attributes returned by the server during authentication. You configure the user role to be derived by specifying condition rules; when a condition is met, the specified user role is assigned to the client. You can specify more than one condition rule; the order of rules is important as the first matching condition is applied.
You can also define server rules based on client attributes such as ESSID, BSSID, or MAC address, even though these attributes are not returned by the server.
For information about configuring a server-derived role, see
Configuring Server-Derivation Rules on page 205 .
Configuring a VSA-Derived Role
Many Network Address Server (NAS) vendors, including Aruba, use VSAs to provide features not supported in standard RADIUS attributes. For Aruba systems, VSAs can be employed to provide the user role and VLAN for
RADIUS-authenticated clients, however the VSAs must be present on your RADIUS server. This involves defining the vendor (Aruba) and/or the vendor-specific code (14823), vendor-assigned attribute number, attribute format (such as string or integer), and attribute value in the RADIUS dictionary file. VSAs supported
ArubaOS 6.5.3.x
| User Guide Roles and Policies | 397
on controllers conform to the format recommended in RFC 2865, “Remote Authentication Dial In User Service
(RADIUS)”.
For more information on Aruba VSAs, see
RADIUS Server VSAs on page 184
. Dictionary files that contain Aruba
VSAs are available on the Aruba support website for various RADIUS servers. Log into the Aruba support website to download a dictionary file from the Tools folder.
Configuring a Standard Role
Starting from ArubaOS 6.5.1.0, a new management role, Standard role, is supported which has all the root privileges but cannot make changes to the management users. The purpose of creating this new role is to prevent changes to the local account from externally authenticated management user.
In the WebUI
1. Navigate to Configuration > Management > Administration page.
2. Click Add to add a new user.
3. In the Add User section, perform the following steps to set the Standard role: a. Enter the User Name .
a. In Conventional User Account , enter the Password , Confirm Password fields and set the Role as
Standard using the drop-down list.
b. In Certificate Management , select WebUI Certificate , disable the Use external authentication server to authenticate field, set the Role as Standard using the drop-down list, enter the Client
Certificate Serial No.
, and select the Trusted CA Certificate Name .
c. In Certificate Management , select SSH Public Key , set the Role as Standard, the Client
Certificate Name , and Revocation Checkpoint using the respective drop-down lists, d. Click Apply .
For SSH public key and WebUi certificate, the certificates have to be imported prior to setting the role.
In the CLI
To configure a conventional user account with the Standard role:
(host) (config) #mgmt-user <username> standard
To configure a user with the Standard role in the local userdb:
(host) (config) #local-userdb add username <username> password <password> role standard
To configure a user with the Standard role using the webui-cert after importing certificates to the client:
(host) (config) #mgmt-user webui-cacert <certificate name> serial <serial-no> <username>
<rolename>
(host) (config) #mgmt-userssh-pubkey client-cert <certificate> <username> <role> rcp <rcp_ name>
To configure the default user with the Standard role:
(host) (config) #aaa authentication mgmt default-role standard
The Standard user role can also be set using n n
Filter-Id in SDR by setting a rule in the server-group to filter the specified operand and assign the Standard role if the condition match in the filter.
External RADIUS server by configuring the username, password, and Aruba-Admin-Role attribute in the
RADIUS server.
398 | Roles and Policies ArubaOS 6.5.3.x | User Guide
To view the different roles of the mgmt-user:
(host) #show mgmt-role
Understanding Global Firewall Parameters
describes optional firewall parameters you can set on the controller for IPv4 traffic. To set these options in the WebUI, navigate to the Configuration > Advanced Services > Stateful Firewall > Global
Setting page and select or enter values in the IPv4 column. To set these options in the CLI, use the firewall configuration commands.
See
for information about configuring firewall parameters for IPv6 traffic.
Table 90: IPv4 Firewall Parameters
Parameter
Monitor Ping Attack (per 30 seconds)
Monitor TCP SYN Attack rate
(per 30 seconds)
Monitor IP Session Attack (per
30 seconds)
Monitor/Police ARP Attack (non
Gratuitous ARP) rate (per 30 seconds)
Monitor/Police CP Attack rate
(per 30 seconds)
Monitor/Police Gratuitous ARP
Attack rate (per 30 seconds)
Deny Inter User Bridging
Description
Number of ICMP pings per 30 second, which if exceeded, can indicate a denial of service attack. Valid range is 1-16384 pings per 30 seconds.
Recommended value is 120 seconds.
Default: No default
Number of TCP SYN messages per 30 second, which if exceeded, can indicate a denial of service attack. Valid range is 1-16384 pings per 30 seconds.
Recommended value is 960 seconds.
Default: No default
Number of TCP or UDP connection requests per 30 second, which if exceeded, can indicate a denial of service attack. Valid range is 1-16384 requests per 30 seconds.
Recommended value is 960 seconds.
Default: No default
Number of ARP packets (other than Gratuitous ARP packets) per 30 seconds, which if exceeded, can indicate a denial of service attack. Valid range is 1-16384 packets per 30 seconds.
Recommended value is 960 packets.
Default: No default
NOTE: Blacklisting of wired clients is not supported.
Rate of misbehaving user’s traffic, which if exceeded, can indicate a denial or service attack.
Recommended value is 3000 frames per 30 seconds.
Default: No default
Number of Gratuitous ARP packets per 30 seconds, which if exceeded, can indicate denial of service attack. Valid range is 1-16384 packets per
30 seconds.
Recommended value is 50 packets.
Default: 50 packets
NOTE: Blacklisting of wired clients is not supported.
Prevents the forwarding of Layer-2 traffic between wired or wireless users. You can configure user role policies that prevent Layer-3 traffic between users or networks but this does not block Layer-2 traffic. This option can be used to prevent traffic, such as Appletalk or IPX, from being forwarded.
Default: Disabled
ArubaOS 6.5.3.x
| User Guide Roles and Policies | 399
Parameter
Deny Inter User Traffic
Deny Source Routing
Deny All IP Fragments
Enforce TCP Handshake Before
Allowing Data
Prohibit IP Spoofing
Prohibit RST Replay Attack
Log ICMP Errors
Stateful SIP Processing
Allow Tri-session with DNAT
Amsdu Configuration
Description
Denies traffic between untrusted users by disallowing layer-2 and layer-3 traffic. This parameter does not depend on the deny-inter-user-bridging parameter being enabled or disabled.
Default: Disabled
Permits the firewall to reject and log packets with the specified IP options loose source routing, strict source routing, and record route. Note that network packets where the IPv6 source or destination address of the network packet is defined as an “link-local address (fe80::/64) are permitted.
Default: Disabled
Drops all IP fragments.
NOTE: Do not enable this option unless instructed to do so by an Aruba representative.
Default: Disabled
Prevents data from passing between two clients until the three-way TCP handshake has been performed. This option should be disabled when you have mobile clients on the network as enabling this option will cause mobility to fail. You can enable this option if there are no mobile clients on the network.
Default: Disabled
Enables detection of IP spoofing (where an intruder sends messages using the IP address of a trusted client). When this option is enabled, source and destination IP and MAC addresses are checked for each ARP request/response. Traffic from a second MAC address using a specific IP address is denied, and the entry is not added to the user table. Possible
IP spoofing attacks are logged and an SNMP trap is sent.
Default: Enabled
When enabled, closes a TCP connection in both directions if a TCP RST is received from either direction. You should not enable this option unless instructed to do so by an Aruba representative.
Default: Disabled
Enables logging of received ICMP errors. You should not enable this option unless instructed to do so by an Aruba representative.
Default: Disabled
Disables monitoring of exchanges between a voice over IP or voice over
WLAN device and a SIP server. This option should be enabled only when there is no VoIP or VoWLAN traffic on the network.
Default: Disabled (stateful SIP processing is enabled)
Allows three-way session when performing destination NAT. This option should be enabled when the controller is not the default gateway for wireless clients and the default gateway is behind the controller. This option is typically used for captive portal configuration.
Default: Disabled.
Enables handling AMSDU traffic from clients.
Default: Disabled
400 | Roles and Policies ArubaOS 6.5.3.x | User Guide
Parameter
Session Mirror Destination
Session Idle Timeout (sec)
Disable FTP Server
GRE Call ID Processing
Per-packet Logging
Broadcast-filter ARP
Prohibit ARP Spoofing
Prevent DHCP exhaustion
Session VOIP Timeout (sec)
Description
Destination (IP address or port) to which mirrored session packets are sent. This option is used only for troubleshooting or debugging.
Packets can be mirrored in multiple ACLs, so only a single copy is mirrored if there is a match within more than one ACL.
You can configure the following: n
Ethertype to be mirrored with the Ethertype ACL mirror option.
n n
IP flows to be mirrored with the session ACL mirror option.
MAC flows to be mirrored with the MAC ACL mirror option.
n If you configure both an IP address and a port to receive mirrored packets, the IP address takes precedence.
Default: N/A
Set the time, in seconds, that a non-TCP session can be idle before it is removed from the session table. Specify a value in the range 16-259 seconds. You should not set this option unless instructed to do so by an
Aruba representative.
Default: 15 seconds
Disables the FTP server on the controller. Enabling this option prevents
FTP transfers. You should not enable this option unless instructed to do so by an Aruba representative.
Default: Disabled (FTP server is enabled)
Creates a unique state for each PPTP tunnel. You should not enable this option unless instructed to do so by an Aruba representative.
Default: Disabled
Enables logging of every packet if logging is enabled for the corresponding session rule. Normally, one event is logged per session. If you enable this option, each packet in the session is logged. You should not enable this option unless instructed to do so by an Aruba representative, as doing so may create unnecessary overhead on the controller.
Default: Disabled (per-session logging is performed)
Reduces the number of broadcast packets sent to VoIP clients, thereby improving the battery life of voice handsets. You can enable this option for voice handsets in conjunction with increasing the DTIM interval on clients.
Default: Disabled
Detects and prohibits ARP spoofing. When this option is enabled, possible arp spoofing attacks are logged and an SNMP trap is sent.
Default: Disabled
Enable check for DHCP client hardware address against the packet source MAC address. This command checks the frame's source-MAC against the DHCPv4 client hardware address and drops the packet if it does not match. Enabling this feature prevents a client from submitting multiple DHCP requests with different hardware addresses, thereby preventing DHCP pool depletion.
Default: Disabled
Sets the idle session timeout for sessions that are marked as voice sessions. If no voice packet exchange occurs over a voice session for the specified time, the voice session is removed. Range is 16 – 300 seconds.
Default: 300 seconds
ArubaOS 6.5.3.x
| User Guide Roles and Policies | 401
Parameter
Stateful H.323 Processing
Stateful SCCP Processing
Only allow local subnets in user table
Session mirror IPSEC
Description
Disables stateful H.323 processing.
Default: Enabled
Disables stateful SCCP processing.
Default: Disabled
Adds only IP addresses, which belong to a local subnet, to the user-table.
Default: Disabled
Configures session mirroring of all frames that are processed by IPsec.
Frames are sent to IP address specified by the session-mirrordestination option.
NOTE: Use this option for debugging or troubleshooting only.
Default: Disabled
Session-tunnel FIB
Multicast automatic shaping
Stateful VOCERA Processing
Enable session-tunnel based forwarding.
NOTE: Best practices is to enable this parameter only during maintenance window or off-peak production hours.
Enables multicast optimization and provides excellent streaming quality regardless of the amount of VLANs or IP IGMP groups that are used.
Default: Disabled
Disables stateful VOCERA processing.
Default: Disabled
Stateful UA Processing Disables stateful UA processing.
Default: Disabled
Applies bw contracts to local subnet broadcast traffic.
Enforce bw contracts for broadcast traffic
Enforce TCP Sequence numbers Enforces the TCP sequence numbers for all packets.
Default:Disabled
Enforce WMM Voice Priority
Matches Flow Content
If traffic to or from the user is inconsistent with the associated QoS policy for voice, the traffic is reclassified to best effort and data path counters incremented.
Default: Disabled
Rate limit CP untrusted ucast traffic (pps)
Rate limit CP untrusted mcast traffic (pps)
Specifies the untrusted unicast traffic rate limit. Range is 1-65535 packets per seconds (pps).
Default: 9765 pps
Specifies the untrusted multicast traffic rate limit. Range is 1-65535 packets per seconds (pps).
Default: 1953 pps
Rate limit CP trusted ucast traffic
(pps)
Specifies the trusted unicast traffic rate limit. Range is 1-65535 packets per seconds (pps).
Default: 65535 pps
Rate limit CP trusted mcast traffic (pps)
Specifies the trusted multicast traffic rate limit. Range is 1-65535 packets per seconds (pps).
Default: 1953 pps
402 | Roles and Policies ArubaOS 6.5.3.x | User Guide
Parameter
Rate limit CP route traffic (pps)
Rate limit CP session mirror traffic (pps)
Rate limit CP auth process traffic
(pps)
Description
Specifies the traffic rate limit that needs ARP requests. Range is 1-65535 packets per seconds (pps).
Default: 976 pps
Specifies the session mirrored traffic forwarded to the controller. Range is 1-65535 packets per seconds (pps).
Default: 976 pps
Specifies the traffic rate limit that is forwarded to the authentication process. Range is Range is 1-65535 packets per seconds (pps).
Default: 976 pps
Using AppRF 2.0
The AppRF 2.0 feature improves application visibility and control by allowing you to configure access control list (ACL) and bandwidth-control applications and application categories. AppRF 2.0 supports a Deep Packet
Inspection (DPI) engine for application detection for over a thousand applications. All wired and wireless traffic that traverses the controller can now be categorized and controlled by application and application category.
AppRF 2.0 provides the ability to: n n n permit or deny an application or application category for a specific role. For example, you can block bandwidth monopolizing applications on a guest role within an enterprise.
rate limit an application or application category, such as video streaming applications, globally or for a specific role.
mark different L2/L3 Quality of Service (QoS) for an application or application category for a user role. For example, you can mark video and voice sessions that originate from wireless users with different priorities so that traffic is prioritized accordingly in your network.
To configure AppRF 2.0, see the following topics: n n n
Enabling Deep Packet Inspection (DPI) on page 403
Configuring Policies for AppRF 2.0 on page 404
Configuring Bandwidth Contracts for AppRF 2.0 on page 406
Enabling Deep Packet Inspection (DPI)
For application and application category specific configuration to take affect, you must first enable DPI.
You must reboot (reload) the controller after you enable or disable DPI for global classification to take effect.
In the WebUI
1. Navigate to Configuration > Advanced Services > Stateful Firewall > Global Settings .
2. Check the Enable Deep Packet Inspection option. To disable DPI, uncheck the checkbox.
3. Click Apply .
4. Reload the controller.
In the CLI
To enable global DPI:
(host)(config) #firewall dpi
(host) #reload
ArubaOS 6.5.3.x
| User Guide Roles and Policies | 403
To display the application ID, application name, and the ACL/ACE index information for a given session:
(host)(config) # how datapath session dpi
Configuring Policies for AppRF 2.0
Access control lists now contain new application and application category options that let you permit or deny an application or application category on a given role. See the Dashboard Monitoring
topic for details about configuring policies from the Dashboard.
How ACL Works with AppRF
A session entry proceeds through two phases: the application detection phase (phase 1) and the postapplication detection phase (phase 2). A session ACL is applied in phase1 and in phase 2.
In phase1, if the session ACL lookup results in an L3/L4 ACE entry request, the traffic pertaining to the session is guided by this L3/L4 ACE entry. However, if the session ACL lookup results in an application/application category specific ACE entry, the enforcement is postponed until phase 2. Once the application is determined, the session ACL is re-applied with "application/application category" information to determine the final action on the traffic.
Global Session ACL
The Global Session ACL is used to configure ACL rules that span across or are common to all roles. They are applied to all roles. The "global-sacl" rules take precedence over any other ACLs that may be in the user role.
A new session ACL has been added named "global-sacl." This session, by default, is in position one for every user role configured on the controller. The global-sacl session ACL has the following properties: n n n n n
It cannot be deleted.
It always remains at position one in every role and its position cannot be modified.
It contains only application rules.
It can be modified in the WebUI, CLI, and dashboard on a master controller.
Any modifications to it results in the regeneration of ACE’s of all roles.
Role Default Session ACL
You can configure role-specific application configuration using the WebUI and dashboard. For example, you can deny the facebook application on the guest role using the CLI or dashboard without having to change the firewall configuration. This per-user role configuration from WebUI or Dashboard is placed in the Role Default
Session ACL.
A new role session ACL named apprf-“role-name”-sacl has been added. This session, by default, is in position two for every user role configured on the controller.
The string "apprf" is added to the beginning and "sacl" to the end of a role’s name to form a controllerunique name for role default session ACL. This session ACL is in position two of the given user role after the global session ACL and takes the next higher priority after global policy rules.
The predefined role session ACL has the following properties: n n n n n
It cannot be deleted through the WebUI or CLI. It is only deleted automatically when the corresponding role is deleted.
It always remains at position 2 in every role and its position cannot be modified.
It contains only application rules.
It can be modified using the WebUI, CLI, or dashboard on a master controller, however any modification results in the regeneration of ACE’s for that role.
It cannot be applied to any other role.
404 | Roles and Policies ArubaOS 6.5.3.x | User Guide
Each application has an implicit set of ports that are used for communication. In phase 1, if an application ACE entry is hit, the traffic matching this application’s implicit port is allowed (as governed by the application ACE).
The DPI engine can monitor the exchange on these ports and determine the application. Once the application is determined, phase 2 occurs when an evaluation is done to determine the final outcome for the session.
Example
This example shows a DPI rule along with a L3/L4 rule with forwarding action in the same ACL. Both
ACL policies can be applied to a single user role.
n n n n n n
ACL Policy "AppRules", Policy Type: Session
Rule 1 l source: any l l l destination: any service/application: application facebook action: permit l
TOS value: 45
Rule 2: l l source: any destination: any l l service/application: application YouTube action: deny
Rule 3: l source: any l l destination: any service/application: application category peer-to-peer l action: deny
Rule 4: l l l l source: any destination: any service/application: TCP 23 action: permit
Rule 5: l source: network 40.1.0.0/16 l l destination: any service/application: TCP 80 l l action: permit
TOS: 60
Rule 6: l source: network 20.1.0.0/16 l l l destination: any service/application: TCP 80 action: source-nat n
ACL Policy "NetRules", Policy Type: Session
Rule 1
ArubaOS 6.5.3.x
| User Guide Roles and Policies | 405
n n l l l l source: network 80.0.0.0/24 destination: any service/application: TCP 80 action: deny
Rule 2: l source: network 60.0.0.0/24 l l destination: any service/application: TCP 80 l action: dual-nat <nat_pool>
Rule 3: l l source: network 10.0.0.0/24 destination: any l l service/application: TCP 80 action: destination nat
In the WebUI
1. Navigate to Configuration > Access Control > Policies.
2. Click Add/Edit .
3. Click Add under Rules/IP Version.
4. Select application or application category from the Service drop-down menu and select configuration options.
5. Click Apply .
In the CLI
To configure the ACL application-specific parameters using the command-line interface, access the commandline interface in config mode, run the following commands:
(host)(config)#ip access-list
Configuring Bandwidth Contracts for AppRF 2.0
Bandwidth contract configuration lets you configure bandwidth contracts for both the global or applicationspecific levels.
Global Bandwidth Contract Configuration
To configure bandwidth contracts to limit application and application categories on an application or global level, or to show global bandwidth contract configuration output, access the command-line interface and use the commands dpi global-bandwidth-contract and show dpi global-bandwidth-contract .
(host)(config) #dpi global-bandwidth-contract[app|appcategory]
(host) #show dpi global-bandwidth-contract
Role-Specific Bandwidth Contracts
Application-specific bandwidth contracts (unlike "generic" bandwidth-contracts) allow you to control or reserve rates for specific applications only on a per-role basis. An optional exclude list is provided that allows you to exclude applications or application categories on which a generic user/role bandwidth-contract is not applied.
406 | Roles and Policies ArubaOS 6.5.3.x | User Guide
Using an Exclude List
Use an exclude to give specific enterprise mission-critical applications priority over other user traffic. An enterprise may have well known applications such as Microsoft Exchange, SAP, Oracle, accounting and finance applications, and other enterprise resource planning (ERP) or customer relationship management (CRM) applications.
Instead of enumerating bandwidth limits for each application individually on a per-user/per-role basis, you can configure a single bandwidth contract on a per-user/per-role to limit all non-mission critical applications. You can then exclude all mission-critical applications by placing them in an exclude list. This way all mission-critical applications will not be rate-limited. Important points regarding bandwidth contracts include: n n
Application bandwidth contracts are per-role by default.
When an application bandwidth-contract is configured for both a category and an application within the category, always apply the most specific bandwidth contract.
In the WebUI
1. Navigate to Configuration > Security > Access Control > User Roles .
2. Click Add to create a new user role or Edit to modify an existing role.
3. Select the Bandwidth Contracts tab.
4. To exclude an application or application category, click the Add button below the Exceptions section, select an item from the Name drop-down menu and click Done .
5. To add an application or application category to a bandwidth contract, click Add under Application
Bandwidth Contracts .
6. Select the application from the Name drop-down me and whether it is enforced.
7. Enter a name of the new bandwidth contract, the bandwidth in kpbs or mbps, and if downstream is enforced.
8. Select an option from the Downstream drop-down menu and Per Role, Per User, or Per AP Group from the adjacent drop-down menu.
9. Select additional configuration parameters from the Misc. Configuration pane.
Make sure that the Enable Deep Packet Inspection option is checked.
10.Click
Apply .
In the CLI
To configure the bandwidth application-specific parameters using the CLI, access the command-line interface in config mode, and issue the following commands:
(host)config t #user-role <string>
(host)(config-role) #bw-contract exclude
ArubaOS 6.5.3.x
| User Guide Roles and Policies | 407
Chapter 18
ClearPass Policy Manager Integration
ArubaOS and ClearPass Policy Manager (CPPM) include support for centralized policy definition and distribution. ArubaOS now supports downloadable roles. By using this feature, when ClearPass Policy Manager successfully authenticates a user, the user is assigned a role by ClearPass Policy Manager and if the role is not defined on the controller, the role attributes can also be automatically downloaded.
This chapter contains the following sections: l l l l
Important Points to Remember on page 408
Enabling Downloadable Role on a Controller on page 409
Sample Configuration on page 409
n n n
Introduction
In order to provide highly granular per-user level access, user roles can be created when a user has been successfully authenticated. During the configuration of a policy enforcement profile at ClearPass Policy
Manager, the administrator can define a role that should be assigned to the user after successful authentication. In RADIUS authentication, when ClearPass Policy Manager successfully authenticates a user, the user is assigned a role by ClearPass Policy Manager and if the role is not defined on the controller, the role attributes can also be automatically downloaded. This feature supports roles obtained by the following authentication methods:
802.1X (wireless and wired users)
MAC authentication
Captive Portal n n n n
Important Points to Remember
Under
mode, ClearPass Policy Manager does not perform any error checking to confirm accuracy of the role definition. Therefore, it is recommended that you review the role defined in ClearPass Policy
Manager prior to enabling this feature.
Attributes that are listed below, herein referred to as whitelist role attributes, can be defined in ClearPass
Policy Manager.
l netdestination l l l l netservice ip access-list eth ip access-list mac ip access-list session l user-role
The above attributes that are referred to by a role definition must either be defined within the role definition itself or configured on the controller before the policy is downloaded.
In ClearPass Policy Manager, two or more attributes (as listed above) should not have the same name. The example below is considered invalid, as both the attributes have test as the profile/net destination name.
qos-profile test netdestination test
ArubaOS 6.5.3.x
| User Guide ClearPass Policy Manager Integration | 408
n
An instance name (name of a whitelist role attribute as stated above) is case-sensitive. Attributes must adhere to the following rules: l l l l
Should not match any CLI option nested under a command from the whitelist.
Should not contain a number or a combination of numbers.
Should not contain any periods '.'.
Should not contain any spaces.
The example below is considered an invalid configuration and will fail ClearPass Policy Manager role download on a controller: netservice 'tcp' tcp 443
The first instance of tcp is a user-defined field, while the second is an operator of the netservice command. This violates the first rule.
netdestination 'alias'
The user-defined name alias is also a valid operator of the netdestination command. This violates the first rule.
netdestination '10.1.5'
This user-defined name uses both numbers and periods. This violates the second and third rule.
ip access-list stateless '100'
This user-defined name uses numbers. This violates the second rule.
qos-profile emp role
This profile name emp role contains spaces. This violates the fourth rule.
It is recommended that some naming convention similar to the CamelCase (mixture of upper and lower case letters in a single word) be used to avoid collisions with the CLI options in the role description.
Enabling Downloadable Role on a Controller
You can enable role download using the CLI or WebUI.
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > AAA Profiles .
2. Select an AAA profile.
3. Check the Download Role from CPPM check box to enable role download.
Using the CLI
(host) (config) #aaa profile <profile-name>
(host) (AAA profile) #download-role
Sample Configuration
The following example shows the configuration details to integrate a ClearPass Policy Manager server with a controller to automatically download roles.
ClearPass Policy Manager Server Configuration
Adding a Device
1. From the Configuration > Network > Devices page, click the Add Device link.
2. On the Device tab, enter the Name , IP or Subnet Address , and RADIUS Shared Secret fields.
Keep the rest of the fields as default.
409 | ClearPass Policy Manager Integration ArubaOS 6.5.3.x | User Guide
3. Click Add .
The fields are described in
and
Figure 56 Device Tab
Table 91: Device Tab
Container Description
Name
IP or Subnet Address
Specify the name or identity of the device.
Specify the IP address or subnet (example 10.1.1.1/24) of the device.
RADIUS Shared Secret Enter and confirm a Shared Secret for each of the two supported request protocols.
Adding Enforcement Profile
1. From Configuration > Enforcement > Profiles page, click Add Enforcement Profile .
2. On the Profile tab, select Aruba Downloadable Role Enforcement from the Template drop-down list.
3. Enter the Name of the enforcement profile.
4. From the Role Configuration Mode , select Advanced .
Keep the rest of the fields as default.
5. Click Next .
For the rest of the configuration, see
Advanced Role Configuration Mode .
The fields are described in
and
ArubaOS 6.5.3.x
| User Guide ClearPass Policy Manager Integration | 410
Figure 57 Enforcement Profiles Page
Table 92: Enforcement Profiles Page
Container
Template
Description
Name
Role Configuration
Mode
Policy Manager comes pre-packaged with several enforcement profile templates. In this example, select Aruba Downloadable Role Enforcement - RADIUS template that can be filled with user role definition to create roles that can be assigned to users after successful authentication.
Specify the name of the enforcement profile.
Standard—Configure enforcement profile role using standard mode.
Advanced—Configure enforcement profile role using advanced mode.
Advanced Role Configuration Mode
1. On the Attributes tab, select Radius:Aruba from the Type drop-down list.
2. From the Name drop-down list, select Aruba-CPPM-Role .
3. In the Value field, enter the attribute for the downloadable-role.
4. Click the save icon to save the attribute.
5. Click Save to save the enforcement profile.
The fields are described in
and
411 | ClearPass Policy Manager Integration ArubaOS 6.5.3.x | User Guide
Figure 58 Enforcement Profiles Attributes Tab
Table 93: Enforcement Profiles Attributes Tab
Container
Type
Description
Name
Value
Type is any RADIUS vendor dictionary that is pre-packaged with Policy Manager, or imported by the Administrator. This field is pre-populated with the dictionary names.
Name is the name of the attribute from the dictionary selected in the Type field.
The attribute names are pre-populated from the dictionary.
Value is attribute for the downloadable role. You can enter free-form text to define the role and policy.
NOTE: The maximum limit for free form text is 16,000 bytes.
Adding Enforcement Policy
1. From Configuration > Enforcement > Policies page, click Add Enforcement Policy .
2. On the Enforcement tab, enter the name of the enforcement policy.
3. From the Default Profile drop-down list, select [Deny Access Profile] .
Keep the rest of the fields as default.
4. Click Next .
The fields are described in
and
Figure 59 Enforcement Policies Enforcement Tab
ArubaOS 6.5.3.x
| User Guide ClearPass Policy Manager Integration | 412
Table 94: Enforcement Policies Enforcement Tab
Container Description
Name
Default Profile
Specify the name of the enforcement policy.
An Enforcement Policy applies Conditions (roles, health, and time attributes) against specific values associated with those attributes to determine the
Enforcement Profile. If none of the rules matches, Policy Manager applies the
Default Profile.
See
Adding Enforcement Profile on page 410
to add a new profile.
5. On the Rules tab, click Add Rule .
6. On the Rules Editor pop-up, select the appropriate values in the Conditions section and click the save icon.
7. In the Enforcement Profiles section, select the RADIUS enforcement profile that you created in step
Adding Enforcement Profile on page 410
from the Profile Names drop-down list.
8. Click Save .
The fields are described in
and
Figure 60 Enforcement Policies Rules Editor
Table 95: Enforcement Policies Rules Editor
Container
Type
Name
Operator
Value
Profile Names
Description
The rules editor appears throughout the Policy Manager interface. It exposes different namespace dictionaries depending on Service type. When working with service rules, you can select Authentication namespace dictionary
Drop-down list of attributes present in the selected namespace. In this example, select Source .
Drop-down list of context-appropriate (with respect to the attribute) operators. In this example, select EQUALS .
Drop-down list of the Authentication source database. In this example, select [Local
User Repository] .
Name of the RADIUS enforcement profile.
413 | ClearPass Policy Manager Integration ArubaOS 6.5.3.x | User Guide
Adding Services
1. From the Configuration > Services page, click the Add Service link.
2. On the Service tab, select 802.1X Wired from the Type drop-down-list.
3. In the Name field, enter the name of the service.
Keep the rest of the fields as default.
4. Click Next .
The fields are described in
and
Figure 61 Service Tab
Table 96: Service Tab
Container
Type
Name
Description
Select the desired service type from the drop down menu. In this example, select
802.1X Wired .
Specify the name of the service.
5. On the Authentication tab, select [Local User Repository] [Local SQL DB] from the Authentication
Sources drop-down list.
Keep the rest of the fields as default.
6. Click Next twice.
The fields are displayed in
ArubaOS 6.5.3.x
| User Guide ClearPass Policy Manager Integration | 414
Figure 62 Authentication Tab
7. On the Enforcement tab, select the enforcement policy that you created in step
from the Enforcement Policy drop-down list.
Keep the rest of the fields as default.
8. Click Save .
The fields are displayed in
Figure 63 Enforcement Tab
For more configuration details on ClearPass Policy Manager, see the ClearPass Policy Manager User Guide.
Controller Configuration
For additional command parameters, see the ArubaOS 6.4.x CLI Reference Guide .
Configuring a ClearPass Policy Manager Server on Controller
(host) (config) #aaa authentication-server radius cppm_server
(host) (RADIUS Server "cppm_server") #host <ip_address_of_cppm_server>
(host) (RADIUS Server "cppm_server") #key <shared_secret>
(host) (RADIUS Server "cppm_server") #cppm username <username> password <password>
415 | ClearPass Policy Manager Integration ArubaOS 6.5.3.x | User Guide
Configuring Server Group to include a ClearPass Policy Manager Server
(host) (config) #aaa server-group cppm_grp
(host) (Server Group "cppm_grp") #auth-server cppm_server
Configuring 802.1X Profile
(host) (config) #aaa authentication dot1x cppm_dot1x_prof
Configuring AAA Profile
(host) (config) #aaa profile cppm_aaa_prof
(host) (AAA Profile "cppm_aaa_prof") #authentication-dot1x cppm_dot1x_prof
(host) (AAA Profile "cppm_aaa_prof") #dot1x-server-group cppm_grp
(host) (AAA Profile "cppm_aaa_prof") #download-role
Show AAA Profile
(host) #show aaa profile cppm_aaa_prof
ArubaOS 6.5.3.x
| User Guide ClearPass Policy Manager Integration | 416
Chapter 19
Virtual APs
APs advertise WLANs to wireless clients by sending out beacons and probe responses that contain the WLAN’s
SSID and supported authentication and data rates. When a wireless client associates to an AP, it sends traffic to the AP’s Basic Service Set Identifier (BSSID) which is usually the AP’s MAC address.
In the Aruba network, an AP uses a unique BSSID for each WLAN. Thus, a physical AP can support multiple
WLANs. The WLAN configuration applied to a BSSID on an AP is called a virtual AP.
You can configure and apply multiple virtual APs to an AP group or to an individual AP by defining one or more virtual AP profiles.
This chapter describes the following topics: n n n n n n n n n n
Virtual AP Configuration Workflow on page 417
Virtual AP Profiles on page 418
Changing a Virtual AP Forwarding Mode on page 454
Radio Resource Management (802.11k) on page 427
BSS Transition Management (802.11v) on page 434
Fast BSS Transition ( 802.11r) on page 434
WLAN Authentication on page 443
High-Throughput Virtual APs on page 446
Virtual AP Configuration Workflow
The following workflow lists the tasks to configure a virtual AP that uses 802.1X authentication. Click any of the links below for details on the configuration procedures for that task.
Using the WebUI
1.
Configure your authentication servers.
2.
Create an authentication server group,
and assign the authentication servers you configured in step 1 to that server group.
3.
Configure a firewall access policy
for a group of users
4.
and assign the firewall access policy you created in step 3 to that user role.
5.
a. Assign the user role defined in step 4 to the AAA profile's 802.1X Authentication Default Role b. Associate the server group you created in step 2 to the AAA profile.
6.
7.
Create a new virtual AP profile.
8.
Associate the virtual AP profile
to the AAA profile you created in Step 5.
9.
Associate the virtual AP profile
to the SSID profile you created in Step 6.
ArubaOS 6.5.3.x
| User Guide Virtual APs | 417
Using the CLI
The example below follows the suggested order of steps to configure a virtual AP using the command-line interface.
(host)(config) #aaa server-group "THR-DOT1X-SERVER-GROUP-WPA2" auth-server Internal
!
ip access-list session THR-POLICY-NAME-WPA2 user any any permit
!
(host)(config) #user-role THR-ROLE-NAME-WPA2 session-acl THR-POLICY-NAME-WPA2
!
(host)(config) #aaa server-group "THR-DOT1X-SERVER-GROUP-WPA2" auth-server Internal
!
(host)(config) #aaa profile "THR-AAA-PROFILE-WPA2" dot1x-default-role "THR-ROLE-NAME-WPA2" dot1x-server-group "THR-DOT1X-SERVER-GROUP-WPA2"
!
(host)(config) #wlan ssid-profile "THR-SSID-PROFILE-WPA2" essid "THR-WPA2" opmode wpa2-aes
!
(host)(config) #wlan virtual-ap "THR-VIRTUAL-AP-PROFILE-WPA2" ssid-profile "THR-SSID-PROFILE-WPA2" aaa-profile "THR-AAA-PROFILE-WPA2" vlan 60
!
(host)(config) #ap-group "THRHQ1-STANDARD" virtual-ap "THR-VIRTUAL-AP-PROFILE-WPA2"
Virtual AP Profiles
You can configure virtual AP profiles to provide different network access or services to users on the same physical network. For example, you can configure a WLAN to provide access to guest users and another WLAN to provide access to employee users through the same APs. You can also configure a WLAN that offers open authentication and Captive Portal access with data rates of 1 and 2 Mbps, and another WLAN that requires
WPA authentication with data rates of up to 11 Mbps. You can apply both virtual AP configurations to the same AP or an AP group .
As an example, suppose there are users in both Edmonton and Toronto that access the same “Corpnet” WLAN.
If the WLAN required authentication to an external server, users who associate with the APs in Toronto would want to authenticate with their local servers. In this case, you can configure two virtual APs that each reference a slightly different AAA profile; one AAA profile that references authentication servers in Edmonton and the other that references servers in Toronto (see
).
Table 97: Applying WLAN Profiles to AP Groups
WLAN Profiles “default” AP Group
Virtual AP
SSID
AAA
“Corpnet-Ed”
“Corpnet”
“E-Servers”
“Toronto” AP Group
“Corpnet-Tr”
“Corpnet”
“T-Servers”
418 | Virtual APs ArubaOS 6.5.3.x | User Guide
You can apply multiple virtual AP profiles to individual APs. You can also apply the same virtual AP profile to one or more AP groups.
Configuring the Virtual AP Profile
Follow the procedures below to configure a Virtual AP profile using the WebUI or command-line interfaces.
Creating and Configuring a Profile
1. Navigate to Configuration > Advanced Services > All Profiles .
2. In the Profiles pane, expand the Wireless LAN menu.
3. Select Virtual AP . The list of existing Virtual AP profiles appears in the Profile Details pane.
4. Select the virtual AP profile you want to configure: n n
To configure an existing Virtual AP profile, select the name of the profile in the Profile Details pane.
To create a new Virtual AP profile, enter a name for the profile in the entry blank at the bottom of the
Profile Details pane, then click Add . Select the name of the profile in the Profile Details pane.
Whenever you create a new virtual AP profile in the WebUI, the profile automatically contains the “default” SSID profile with the default “Aruba-ap” ESSID. You must configure a new ESSID and SSID profile for the virtual AP profile before you apply the profile.
5. Configure the profile parameters described in
.
The Virtual AP profile is divided into two tabs, Basic and Advanced . The Basic tab displays only those configuration settings that often need to be adjusted to suit a specific network. The Advanced tab shows all configuration settings, including settings that do not need frequent adjustment or should be kept at their default values. If you change a setting on one tab then click and display the other tab without saving your configuration, that setting will revert to its previous value.
Table 98: Virtual AP Profile Parameters
Parameter Description
Basic Configuration Settings
Virtual AP enable
VLAN
Select the Virtual AP enable check box to enable or disable the virtual AP.
The VLAN(s) into which users are placed in order to obtain an IP address. Click the drop-down list to select a configured VLAN, click the arrow button to associate that
VLAN with the virtual AP profile.
NOTE: You must add an existing VLAN ID to the Virtual AP profile.
ArubaOS 6.5.3.x
| User Guide Virtual APs | 419
Table 98: Virtual AP Profile Parameters
Parameter
Forward mode
Description
Allowed band
This parameter controls whether data is tunneled to the controller using generic routing encapsulation (GRE), bridged into the local Ethernet LAN (for remote APs), or a combination thereof depending on the destination (corporate traffic goes to the controller, and Internet access remains local). All forwarding modes support band steering, TSPEC/TCLAS enforcement, 802.11k and station blacklisting.
Click the drop-down list to select one of the following forward modes: n n
Tunnel: The AP handles all 802.11 association requests and responses, but sends all 802.11 data packets, action frames and EAPOL frames over a GRE tunnel to the controller for processing. The controller removes or adds the GRE headers, decrypts or encrypts 802.11 frames and applies firewall rules to the user traffic as usual. Both remote and campus APs can be configured in tunnel mode.
Bridge: 802.11 frames are bridged into the local Ethernet LAN. When a remote
AP or campus AP is in bridge mode, the AP (and not the controller) handles all
802.11 association requests and responses, encryption/decryption processes, and firewall enforcement. The 802.11e and 802.11k action frames are also processed by the AP, which then sends out responses as needed.
n n
An AP in bridge mode does not support captive portal authentication. Both remote and campus APs can be configured in bridge mode. Note that you must enable the control plane security feature on the controller before you configure campus APs in bridge mode.
Split-Tunnel: 802.11 frames are either tunneled or bridged, depending on the destination (corporate traffic goes to the controller, and Internet access remains local).
A remote AP in split-tunnel forwarding mode handles all 802.11 association requests and responses, encryption/decryption, and firewall enforcement. the
802.11e and 802.11k action frames are also processed by the remote AP, which then sends out responses as needed.
Decrypt-Tunnel: Both remote and campus APs can be configured in decrypttunnel mode. When an AP uses decrypt-tunnel forwarding mode, that AP decrypts and decapsulates all 802.11 frames from a client and sends the 802.3
frames through the GRE tunnel to the controller, which then applies firewall policies to the user traffic.
When the controller sends traffic to a client, the controller sends 802.3 traffic through the GRE tunnel to the AP, which then converts it to encrypted 802.11
and forwards to the client. This forwarding mode allows a network to utilize the encryption/decryption capacity of the AP while reducing the demand for processing resources on the controller.
APs in decrypt-tunnel forwarding mode also manage all 802.11 association requests and responses, and process all 802.11e and 802.11k action frames.
APs using decrypt-tunnel mode do have some limitations that not present for
APs in regular tunnel forwarding mode.
You must enable the control plane security feature on the controller before you configure campus APs in decrypt-tunnel forward mode.
NOTE: Virtual APs in bridge or split-tunnel mode using static WEP should use key slots 2–4 on the controller. Key slot 1 should only be used with Virtual APs in tunnel mode.
The band(s) on which to use the virtual AP: n a —802.11a band only (5 GHz).
n n g —802.11b/g band only (2.4 GHz).
all —both 802.11a and 802.11b/g bands (5 GHz and 2.4 GHz). This is the default setting.
420 | Virtual APs ArubaOS 6.5.3.x | User Guide
Table 98: Virtual AP Profile Parameters
Parameter
Band Steering
Description
Steering Mode
Dynamic Multicast
Optimization (DMO)
Drop Broadcast and
Multicast
ARM’s band steering feature encourages dual-band capable clients to stay on the
5GHz band on dual-band APs. This frees up resources on the 2.4GHz band for single band clients like VoIP phones.
Band steering reduces co-channel interference and increases available bandwidth for dual-band clients, because there are more channels on the 5GHz band than on the 2.4GHz band. Dual-band 802.11n-capable clients may see even greater bandwidth improvements, because the band steering feature will automatically select between 40MHz or 20MHz channels in 802.11n networks. This feature is disabled by default, and must be enabled in a Virtual AP profile.
The band steering feature supports both campus APs and remote APs that have a virtual AP profile set to tunnel , split-tunnel or bridge forwarding mode. Note, however, that if a campus or remote APs has virtual AP profiles configured in bridge or split-tunnel forwarding mode but no virtual AP in tunnel mode, those APs will gather information about 5G-capable clients independently and will not exchange this information with other APs that also have bridge or split-tunnel virtual APs only.
Band steering supports the following three different band steering modes.
n n n
Force-5GHz: When the AP is configured in force-5GHz band steering mode, the
AP will try to force 5Ghz-capable APs to use that radio band.
Prefer-5GHz (Default): If you configure the AP to use prefer-5GHz band steering mode, the AP will try to steer the client to 5G band (if the client is 5G capable) but will let the client connect on the 2.4G band if the client persists in
2.4G association attempts.
Balance-bands: In this band steering mode, the AP tries to balance the clients across the two radios in order to best utilize the available 2.4G bandwidth. This feature takes into account the fact that the 5Ghz band has more channels than the 2.4 Ghz band, and that the 5Ghz channels operate in 40MHz while the
2.5Ghz band operates in 20MHz.
Enable/Disable dynamic multicast optimization. This parameter is disabled by default, and cannot be enabled without the PEFNG license.
Select the Drop Broadcast and Multicast check box to filter out broadcast and multicast traffic in the air.
Do not enable this option for virtual APs configured in bridge forwarding mode. This configuration parameter is only intended for use for virtual APs in tunnel mode. In tunnel mode, all packets travel to the controller, so the controller is able to drop all broadcast traffic. When a virtual AP is configured to use bridge forwarding mode, most data traffic stays local to the AP, and the controller is not able to filter out that broadcast traffic.
IMPORTANT: If you enable this option, you must also enable the Broadcast-Filter
ARP parameter on the virtual AP profile to prevent ARP requests from being dropped. You can enable this parameter by checking the Convert Broadcast ARP requests to unicast check box as described in the following parameter description.
ArubaOS 6.5.3.x
| User Guide Virtual APs | 421
Table 98: Virtual AP Profile Parameters
Parameter Description
Convert Broadcast
ARP requests to unicast
If enabled, all broadcast ARP requests are converted to unicast and sent directly to the client. You can check the status of this option using the show ap active and the show datapath tunnel command. If enabled, the output will display the letter a in the flags column.
This configuration parameter is only intended for use for virtual APs in tunnel mode.
In tunnel mode, all packets travel to the controller, so the controller is able to convert ARP requests directed to the broadcast address into unicast.
When a virtual AP is configured to use bridge forwarding mode, most data traffic stays local to the AP, and the controller is not able to convert that broadcast traffic.
Beginning with ArubaOS 6.1.3.2, this parameter is enabled by default. Behaviors associated with these settings are enabled upon upgrade to ArubaOS 6.1.3.2. If your controller supports clients behind a wireless bridge or virtual clients on
VMware devices, you must disable this setting to allow those clients to obtain an IP address. In previous releases of ArubaOS, the virtual AP profile included two unique broadcast filter parameters; the drop broadcast and multicast parameter, which filtered out all broadcast and multicast traffic in the air except DHCP response frames (these were converted to unicast frames and sent to the corresponding client) and the conert ARP requests to unicast parameter, which converted broadcast ARP requests to unicast messages sent directly to the client.
Starting with ArubaOS 6.1.3.2, the Convert Broadcast ARP requests to unicast setting includes the additional functionality of broadcast-filter all parameter, where
DHCP response frames are sent as unicast to the corresponding client. This can impact DHCP discover/requested packets for clients behind a wireless bridge and virtual clients on VMware devices. Disable this option to resolve this issue and allow clients behind a wireless bridge or VMware devices to receive an IP address.
Default: Enabled
Advanced Configuration Settings
Cellular Handoff
Assist
Dynamic Multicast
Optimization (DMO)
Threshold
When both the client match and the cellular handoff assist features are enabled, the cellular handoff assist feature can help a dual-mode, 3G/4G-capable Wi-Fi device such as an iPhone, iPad or Android client at the end of a Wi-Fi network switch from Wi-Fi to an alternate 3G/4G radio that provides better network access.
Maximum number of high-throughput stations in a multicast group beyond which dynamic multicast optimization stops.
Range: 2-255 stations
Default: 6 stations.
Blacklist Time
Authentication Failure
Blacklist Time
Number of seconds that a client is quarantined from the network after being blacklisted. Default: 3600 seconds (1 hour)
Time, in seconds, a client is blocked if it fails repeated authentication. The default setting is 3600 seconds (1 hour). A value of 0 blocks the client indefinitely.
Deny inter user traffic Select this check box to deny traffic between the clients using this virtual AP profile.
The global firewall shown the Configuration>Advanced Services > Stateful
Firewall > Global window also includes an option to deny all inter-user traffic, regardless of the Virtual AP profile used by those clients.
If the global setting to deny inter-user traffic is enabled, all inter-user traffic between clients will be denied, regardless of the settings configured in the virtual
AP profiles. If the setting to deny inter-user traffic is disabled globally but enabled on an individual virtual ap, only the traffic between un-trusted users and the clients on that particular virtual AP will be blocked.
422 | Virtual APs ArubaOS 6.5.3.x | User Guide
Table 98: Virtual AP Profile Parameters
Parameter
Deny time range
Description
DoS Prevention
HA Discovery on-association
Mobile IP
Click the drop-down list and select a configured time range for which the AP will deny access. If you have not yet configured a time range, navigate to
Configuration > Security > Access Control > Time Ranges to define a time range before configuring this setting in the virtual AP profile.
If enabled, APs ignore deauthentication frames from clients. This prevents a successful deauthorization attack from being carried out against the AP. This does not affect third-party APs. Default: Disabled
If enabled, home agent discovery is triggered on client association instead of home agent discovery based on traffic from client. Mobility on association can speed up roaming and improve connectivity for clients that do not send many uplink packets to trigger mobility (VoIP clients). Best practices is to disable this parameter as it increases IP mobility control traffic between controllers in the same mobility domain. Enable this parameter only when voice issues are observed in VoIP clients.
Default: Disabled
NOTE: ha-disc-onassoc parameter works only when IP mobility is enabled and configured on the controller. For more information about this parameter, see
Discovery on Association on page 675
Enables or disables IP mobility for this virtual AP.
Default: Enabled
Preserve Client VLAN If you select this check box, clients retain their previous VLAN assignment if the client disassociates from an AP and then immediately re-associates either with same
AP or another AP on the same controller.
Remote-AP Operation Configures when the virtual AP operates on a remote AP: n always —Permanently enables the virtual AP (Bridge Mode only). This option can be used for non-802.1X bridge VAPs.
n n n backup —Enables the virtual AP if the remote AP cannot connect to the controller (Bridge Mode only). This option can be used for non-802.1X bridge
VAPs.
persistent —Permanently enables the virtual AP after the remote AP initially connects to the controller (Bridge Mode only). This option can be used for any
(Open/PSK/802.1X) bridge VAPs.
standard —Enables the virtual AP when the remote AP connects to the controller. This option can be used for any (bridge/split-tunnel/tunnel/d-tunnel)
VAPs.
Station Blacklisting Select the Station Blacklisting check box to enable detection of denial of service
(DoS) attacks, such as ping or SYN floods, that are not spoofed deauthorization attacks.
Default: Enabled
ArubaOS 6.5.3.x
| User Guide Virtual APs | 423
Table 98: Virtual AP Profile Parameters
Parameter Description
Strict Compliance
VLAN Mobility
If enabled, the AP denies client association requests if the AP and client station have no common rates defined. Some legacy client stations which are not fully 802.11compliant may not include their configured rates in their association requests. Such non-compliant stations may have difficulty associating with APs unless strict compliance is disabled. This parameter is disabled by default.
Enable or disable VLAN (Layer-2) mobility.
Default: Disabled
FDB Update on Assoc This parameter enables seamless failover for silent clients, allowing them to reassociate. If you select this option, the controller will generate a Layer 2 update on behalf of client to update forwarding tables in bridge devices.
Default: Disabled
6. Click Apply .
Selective Multicast Stream
The selective multicast group is based only on the packets learned through Internet Group Management
Protocol (IGMP).
n n n n
When broadcast-filter all parameter is enabled, the controller would allow multicast packets to be forwarded only if the following conditions are met: l l packets originating from the wired side have a destination address range of 225.0.0.0 -
239.255.255.255
a station has subscribed to a multicast group.
When IGMP snooping/proxy is disabled, the controller is not aware of the IGMP membership and drops the multicast flow.
If DMO is enabled, the packets are sent with 802.11 unicast header.
If AirGroup is enabled, mDNS (SSDP) packets are sent to the AirGroup application. The common address for mDNS is 224.0.0.251 and SSDP is 239.255.255.250.
Associating Other Profiles to the Virtual AP
Each Virtual AP profile can be associated with the following profile types.
n n n n n
AAA
802.11K
l l l
Handover Trigger Feature Settings
RRM IE Settings
Beacon Report Request Settings l
TSM Report Request Settings
Hotspot 2.0
SSID l
EDCA Parameters Station l l
EDCA Parameters AP
High-throughput SSID l
802.11r
WMM Traffic Management
424 | Virtual APs ArubaOS 6.5.3.x | User Guide
n
Anyspot
As a part of the virtual AP profile configuration procedure, you must identify which instance of each profile type associates with the Virtual AP profile. By default, each Virtual AP profile is associated with the default versions of the AAA, 802.11k, Hotspot 2.0 and SSID profiles. The Virtual AP profile can also associate with a
WMM traffic management profile, but as no WMM profile is associated by default, one must be manually configured.
To configure Virtual AP profile associations:
1. Navigate to Configuration > Advanced Services > All Profiles .
2. Expand the Wireless LAN menu.
3. Expand the Virtual AP menu.
4. Select the Virtual AP you want to configure. The list of associated profile types appears in the Profiles list.
5. If a plus [+] sign appears beside an associated profile category, there is more than one profile type in that category. Select that profile category to display the associated profiles within that category.
6. To associate a different profile with the Virtual AP profile, click the name of any currently associated profile in the Profiles list.
7. Click the drop-down list at the top of the ProfileDetails pane and select a different profile to associate to the Virtual AP.
8. Click Apply .
Configuring a Virtual AP in the CLI
The following example defines a virtual AP using the command-line interface. For additional information on the suggested order of steps to configure a virtual AP using the command-line interface, see
Configuration Workflow on page 417
.
(host)(config) #wlan virtual-ap "THR-VIRTUAL-AP-PROFILE-WPA2" ssid-profile "THR-SSID-PROFILE-WPA2" aaa-profile "THR-AAA-PROFILE-WPA2" vlan 60
Associating a Virtual AP Profile to an AP or AP Group
Use the following procedures to associate a virtual AP profile to an AP or group of APs.
In the WebUI
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. Do one of the following: n n
To associate the Virtual AP profile to a single AP, click the AP specific tab, and select the AP.
To associate the Virtual AP profile to an AP group, click the AP Group tab, and select the AP Group.
3. In the Profiles list, expand the Wireless LAN menu.
4. Select Virtual AP . The Profile Details window displays the Virtual AP profiles currently associated to the AP or AP group.
5. Click the Add a Profile drop-down list and select a new Virtual AP profile to associate to the AP. You can associate multiple AP profiles to an AP, but each virtual AP profile must reference a SSID profile with a different network name (SSID).
6. Click Apply
Although you can create mutliple Virtual AP profiles that reference a single SSID profile, only one of these profiles can be applied to an AP or AP group.
ArubaOS 6.5.3.x
| User Guide Virtual APs | 425
In the CLI
(host) (config)#ap-group <ap-group> virtual-ap <vap-profile>
Excluding a Virtual AP Profile
You can exclude one or more virtual AP profiles from an individual AP. This prevents a virtual AP, defined at the
AP group level, from being applied to a specific AP. For example, you can apply the virtual AP profile that corresponds to the “Corpnet” SSID to the “default” AP group. If you do not want the “Corpnet” SSID to be advertised on the AP in the lobby, you can specify the virtual AP profile that contains the “Corpnet” SSID configuration be excluded from that AP.
In the WebUI
1. Navigate to the Configuration > Wireless > AP Configuration > AP Specific page.
2. Do one of the following: n n
If the AP you want to exclude is included in the list, click Edit for the AP.
If the AP does not appear in the list, click New.
Either type in the name of the AP, or select the AP from the drop-down list. Then click Add .
3. Select Wireless LAN under the Profiles list, then select Excluded Virtual AP.
4. Select the name of the virtual AP profile you want to exclude from the drop down menu (under Profile
Details ) and click Add.
The profile name appears in the Excluded Virtual APs list. You can add multiple profile names in the same way.
5. To remove a profile name from the Excluded Virtual APs list, select the profile name and click Delete.
6. Click Apply.
In the CLI
(host)(config) #ap-name < name> exclude-virtual-ap < profile>
Changing a Virtual AP Forwarding Mode
When you change the forwarding mode for a Virtual AP actively serving clients, the user table will NOT reflect accurate client information unless the entries for those users are manually cleared.
The following sections describe the procedure to change the forwarding mode on a Virtual AP serving wired or wireless clients.
To change the forwarding mode for wired users connected to the wired port on an AP:
1. Disable the port by issuing the CLI command ap wired-port-profile <ap-wired-port-profile> shutdown .
This will disconnect any wired clients using that port.
2. Issue the command aaa user delete {<ipaddr>|all|mac <macaddr>|name <username>|role
<role>} to remove from the user table the wired users associated with AP wired ports using the <ap-wiredport-profile>.
3. Issue the command ap wired-ap-profile <profile> forward-mode <mode> where <mode> is the new forwarding mode for the wired port
4. Reenable the port using the command ap wired-port-profile <ap-wired-port-profile> no shutdown .
To change the forwarding mode for wireless users associated with a virtual AP:
1. Issue the command ap-name <group> no virtual-ap <vap-profile> or ap-group <group> no virtual-ap
<vap-profile> to disassociate the AP or group of APs from the virtual AP profile.
426 | Virtual APs ArubaOS 6.5.3.x | User Guide
2. Issue the command aaa user delete {<ipaddr>|all|mac <macaddr>|name <username>|role <role>} to remove from the user table the users associated to the virtual-ap specified in the previous step.
3. Issue the command wlan virtual-AP <vap-profile> forward-mode <mode> where <mode> is the new forwarding mode for the virtual AP.
4. Issue the command ap-name <group> virtual-ap <vap-profile> or ap-group <group> virtual-ap <vapprofile> to reassociate the AP or group of APs with the virtual AP profile.
Radio Resource Management (802.11k)
The 802.11k protocol provides mechanisms for APs and clients to dynamically measure the available radio resources. In an 802.11k enabled network, APs and clients can send neighbor reports, beacon reports, and link measurement reports to each other. This allows the APs and clients to take appropriate connection actions.
The handover process is available for voice clients that support the 802.11k standard and have the ability to transmit and receive beacon reports. For information on configuring the handoff trigger feature, see
Detection and Handover for Voice Clients on page 986
This topic includes the following procedures: n n n n
Configuring the 802.11k Profile
Configuring Radio Resource Management Information Elements
Configuring Beacon Report Requests
Configuring Traffic Stream Measurement Report Requests
Configuring the 802.11k Profile
The following procedures outline the steps to configure 802.11k parameters.
In the WebUI
1. Navigate to the Configuration > Wireless > AP Configuration window. Select either the AP Group or AP
Specific tab.
n
If you selected the AP Group tab, click the Edit button by the AP group name for which you want to configure the new 802.11k profile.
n
If you selected the AP Specific tab, click the Edit button by the AP for which you want to create the
802.11k profile.
2. In the Profiles list, expand the Wireless LAN menu, then expand the Virtual AP menu.
3. Select the Virtual AP profile for which you want to configure 802.11k settings.
To edit an existing 802.11k profile, click the 802.11K Profile drop-down list In the Profile Details window pane and select the 802.1X profile you want to edit.
or
To create a new 802.11k profile, click the 802.11K Profile drop-down list and select New . Enter a new
802.11k profile name in the field to the right of the drop-down list.
4. Configure your 802.11k radio settings.
outlines the parameters you can configure in the 802.11k
profile. Click Apply to save your settings.
ArubaOS 6.5.3.x
| User Guide Virtual APs | 427
Table 99: 802.11k Profile Parameters
Parameter Description
Advertise
802.11k
Capability
Forcefully disassociate on-hook voice clients
Channel for
Beacon
Requests in
'BG' band
Select this option to allow Virtual APs using this profile to advertise
802.11k capability.
Default: Disabled
Select this option to allow the AP to forcefully disassociate on-hook voice clients (clients that are not on a call) after period of inactivity.
Without the forced disassociation feature, if an AP has reached its call admission control limits and an on-hook voice client wants to start a new call, that client may be denied. If forced disassociation is enabled, those clients can associate to a neighboring AP that can fulfill their QoS requirements.
Default: Disabled
Measurement
Mode for
Beacon
Reports
Click the Measurement Mode for Beacon Reports drop-down list and specify one of the following measurement modes: n active-all-ch —Enables active beacon measurement mode. In this mode, the client sends a probe request to the broadcast destination address on all supported channels, sets a measurement duration timer, and, at the end of the measurement duration, compiles all received beacons or probe response with the requested SSID and
BSSID into a measurement report.
n n active-ch-rpt —In this mode, the client and returns a report that contains a list of channels in a regulatory class where a client is likely to find an AP, including the AP transmitting the AP channel report.
beacon-table —Enables beacon-table beacon measurement mode.
In this mode, the client measures beacons and returns a report with stored beacon information for any supported channel with the requested SSID and BSSID. The client does not perform any additional measurements.
n passive —Enables passive beacon measurement mode. In this mode, the client sets a measurement duration timer, and, at the end of the measurement duration, compiles all received beacons or probe response with the requested SSID and BSSID into a measurement report.
NOTE: If a station doesn't support the selected measurement mode, it returns a Beacon Measurement Report with the Incapable bit set in the
Measurement Report Mode field.
Default Mode: beacon-table
Channel for
Beacon
Requests in
'A' band
This value is sent in the 'Channel' field of the beacon requests on the 'A' radio. You can specify values in the range 34 to 165. The default value is 36.
This value is sent in the 'Channel' field of the Beacon Requests on the
'BG' radio. You can specify values in the range 1 to 14. The default value is 1.
Channel for
AP Channel
Reports in 'A' band
This value is sent in the 'Channel' field of the AP channel reports on the
'A' radio. You can specify values in the range 34 to 165. The default value is 36.
428 | Virtual APs ArubaOS 6.5.3.x | User Guide
Table 99: 802.11k Profile Parameters
Parameter Description
Channel for
AP Channel
Reports in
'BG' band
Time duration between consecutive
Beacon
Requests
This value is sent in the 'Channel' field of the AP channel reports on the
'BG' radio. You can specify values in the range 1 to 14. The default value is 1.
This option configures the time duration between two consecutive beacon requests sent to a dot11k client. By default, the beacon requests are sent to a dot11k client every 60 seconds. However, if a different value is required, the bcn-req-time option can be used.
This permits values in the range from 10 seconds to 200 seconds. A value of 0 is used to indicate that the generation of Beacon Request frames is turned off.
Handover
Trigger
Feature
Settings
Profile
Beacon
Report
Request
Settings
Profile
TSM Report
Request
Settings
Profile
Time duration between consecutive
Link
Measurement
Requests
This option configures the time duration between two consecutive link measurement requests sent to a dot11k client. By default, link measurement requests are sent to a dot11k client every 61 seconds.
This parameter permits values in the range from 10 seconds to 200 seconds. A value of 0 is used to indicate that the generation of Link
Measurement Request frames is turned off.
Time duration between consecutive
Transmit
Stream
Measurement
Request
This option configures the time duration between two consecutive transmit stream measurement requests sent to a dot11k client. By default, the transmit stream measurement requests are sent to a dot11k client every 90 seconds.
This permits values in the range from 10 seconds to 200 seconds. A value of 0 is used to indicate that the generation of Transmit Stream
Measurement Request frames is turned off.
This command configures a Handover Trigger Profile. This profile consists of the configurable parameters for the ‘Wi-Fi Edge Detection and Handover of Voice Clients’ feature.
Configure a Beacon Report Request Profile to provide the parameters for the Beacon Report Request frames.
This command configures a TSM Report Request Profile which is used to provide values to the Transmit Stream/Category Measurement
Request frame.
In the CLI
Use the following command to configure 802.11k profiles. The available parameters for this profile are described in
.
wlan dotllk <profile-name>
Configuring Radio Resource Management Information Elements
ArubaOS supports the following radio resource management information elements (RRM IEs) for APs with
802.11k support enabled. These settings can be enabled through the WebUI or CLI.
ArubaOS 6.5.3.x
| User Guide Virtual APs | 429
In the WebUI
To select the RRM IEs to be sent in beacons and probe responses using the WebUI:
1. Navigate to Configuration>Advanced Services>All Profile Management .
2. Expand the Wireless LAN menu and select RRM IE .
3. Select the RRM IE profile you want to configure, then select any of the following IE types to enable that information element in beacons and probe responses. (All IE types are sent by default.)
Table 100: RRM IE Parameters
Parameter
Advertise Enabled Capabilities
IE
Advertise Country IE
Advertise Power Constraint IE
Advertise TPC Report IE
Advertise QBSS Load IE
Advertise BSS AAC IE
Advertise Quiet IE
Description
This value is used to determine if the RRM Enabled Capabilities IE should be advertised in the beacon frames. A value of "Enabled" allows the RRM Enabled Capabilities IE to be present in the beacon frames when 802.11k capability is enabled. A value of "Disabled" prevents the advertisement of the RRM Enabled Capabilities IE in the beacon frames when 802.11k capability is enabled.
This value is used to determine if the Country IE should be advertised in the beacon frames. A value of "Enabled" allows the Country IE to be present in the beacon frames when 802.11k capability is enabled. A value of "Disabled" prevents the advertisement of the Country IE in the beacon frames when 802.11k capability is enabled.
This value is used to determine if the Power Constraint IE should be advertised in the beacon frames. A value of "Enabled" allows the Power
Constraint IE to be present in the beacon frames when 802.11k
capability is enabled. A value of "Disabled" prevents the advertisement of the Power Constraint IE in the beacon frames when 802.11k
capability is enabled.
This value is used to determine if the TPC Report IE should be advertised in the beacon frames. A value of "Enabled" allows the TPC
Report IE to be present in the beacon frames when 802.11k capability is enabled. A value of "Disabled" prevents the advertisement of the TPC
Report IE in the beacon frames when 802.11k capability is enabled.
This value is used to determine if the QBSS Load IE should be advertised in the beacon frames. A value of "Enabled" allows the QBSS
Load IE to be present in the beacon frames when 802.11k capability is enabled. A value of "Disabled" prevents the advertisement of the QBSS
Load IE in the beacon frames when 802.11k capability is enabled. The default value is "Enabled".
This value is used to determine if the BSS Available Admission Capacity
IE should be advertised in the beacon frames. A value of "Enabled" allows the BSS Available Admission Capacity IE to be present in the beacon frames when 802.11k capability is enabled. A value of
"Disabled" prevents the advertisement of the BSS Available Admission
Capacity IE in the beacon frames when 802.11k capability is enabled.
This value is used to determine if the Quiet IE should be advertised in the beacon frames. A value of "Enabled" allows the Quiet IE to be present in the beacon frames when 802.11k capability is enabled. A value of "Disabled" prevents the advertisement of the Quiet IE in the beacon frames when 802.11k capability is enabled.
4. Click Apply Changes to save your settings.
430 | Virtual APs ArubaOS 6.5.3.x | User Guide
In the CLI
To use the CLI to configure radio resource management information elements in the RRM IE profile, access the
CLI in config mode and issue the following command:
(host) (config)#wlan rrm-ie-profile <profile>
Configuring Beacon Report Requests
The beacon report requests are sent only to 802.11k-compliant clients that advertise Beacon Report Capability in their RRM Enabled Capabilities IE. The beacon request frames are sent every 60 seconds.
The content of the report requests can be defined in the Beacon Report Request profile using the WebUI or
CLI.
In the WebUI
To select the information to be sent in beacon report requests using the WebUI:
1. Navigate to Configuration>Advanced Services>All Profile Management .
2. Expand the Wireless LAN menu and select Beacon Report Request .
3. Select the Beacon Report Request profile you want to configure.
4. Define the settings described in the table below, then click Apply Changes to save your settings.
Table 101: Beacon Report Request Settings
Parameter
Interface
Description
Regulatory Class
Channel
Randomization
Interval
Measurement
Duration
This field is used to specify the Radio interface for transmitting the Beacon Report Request frame. It can have a value of either 0 or 1. The default value is 1.
This option is used to specify the Regulatory Class field in the Beacon Report Request frame. It can be set to one of the following: n
1 (for 5 GHz band) n
12 (for 2.4 GHz band)
This option is used to set the Channel field in the Beacon Report Request frame. The Channel value can be set to one of the following: - the channel of the AP (when Measurement Mode is set to either 'Passive' or 'Active-All channels') - 0 (when Measurement Mode is set to 'Beacon
Table') - 255 (when Measurement Mode is set to 'Active-Channel Report')
This value is used to set the Randomization Interval field in the Beacon Report Request frame.
The Randomization Interval is used to specify the desired maximum random delay in the measurement start time. It is expressed in units of TUs (Time Units). A Randomization Interval of 0 in a measurement request indicates that no random delay is to be used. This field can be given a value in the range (0, 65535). The default value is 0.
This value is used to set the Measurement Duration field in the Beacon Report Request frame.
The Measurement Duration is set to the duration of the requested measurement. It is expressed in units of TUs. This field can be given a value in the range (0, 65535). The default value is 0.
ArubaOS 6.5.3.x
| User Guide Virtual APs | 431
Table 101: Beacon Report Request Settings
Parameter Description
Measurement
Mode for Beacon
Reports
Reporting
Condition
Click the Measurement Mode for Beacon Reports drop-down list and specify one of the following measurement modes: n active —Enables active beacon measurement mode. In this mode, the client sends a probe request to the broadcast destination address on all supported channels, sets a measurement duration timer, and, at the end of the measurement duration, compiles all received beacons or probe response with the requested SSID and BSSID into a measurement report.
n n beacon-table —Enables beacon-table beacon measurement mode. In this mode, the client measures beacons and returns a report with stored beacon information for any supported channel with the requested SSID and BSSID. The client does not perform any additional measurements.
passive —Enables passive beacon measurement mode. In this mode, the client sets a measurement duration timer, and, at the end of the measurement duration, compiles all received beacons or probe response with the requested SSID and BSSID into a measurement report.
NOTE: If a station doesn't support the selected measurement mode, it returns a Beacon
Measurement Report with the Incapable bit set in the Measurement Report Mode field.
Default Mode: beacon-table
This option is used to indicate the value for the "Reporting Condition" field in the Beacon
Reporting Information sub-element present in the Beacon Report Request frame. It can have a range from 0 to 255. The default value is 0.
ESSID name
Reporting Detail
This option is used to indicate the value for the "SSID" field in the Beacon Report Request frame. It corresponds to the SSID Name for which the Beacon Report Request frame needs to be generated. It is a string with a minimum length of 1 and a maximum length of 32.
This option is used to indicate the value for the "Detail" field in the Reporting Detail subelement present in the Beacon Report Request frame. It is set to "Disabled" by default.
This value is used to set the "Duration Mandatory" bit of the Measurement Request Mode field of the Beacon Report Request frame. The default value is "Disabled".
Measurement
Duration
Mandatory
Request
Information values
This option is used to indicate the contents of the Request Information IE that could be present in the Beacon Report Request frame. The Request Information IE is present for all
Measurement Modes except the 'Beacon Table' mode. It consists of a list of Element IDs that should be included by the client in the response frame.
In the CLI
To select the information to be sent in beacon report requests using the command-line interface, access the
CLI in config mode and issue the following commands.
wlan bcn-rpt-req-profile <profile>
Configuring Traffic Stream Measurement Report Requests
The Traffic Stream Measurement(TSM) report requests are sent only to dot11k compliant clients that advertise a traffic stream report capability. The TSM report request frames are sent every 60 seconds. The content of the report requests can be defined in the TSM Report Request profile using the WebUI or CLI.
In the WebUI
To select the information to be sent in TSM report requests using the WebUI:
1. Navigate to Configuration > Advanced Services > All Profile Management .
2. Expand the Wireless LAN menu and select TSM Report Request .
432 | Virtual APs ArubaOS 6.5.3.x | User Guide
3. Select the TSM Report Request profile you want to configure.
4. Define the settings described in the table below, then click Apply Changes to save your settings.
Table 102: TSM Report Request Settings
Parameter Description
Request Mode for
TSM Report
Request
Number of repetitions
Duration
Mandatory
Randomization
Interval
Measurement
Duration
Traffic ID
Bin 0 Range
Select one of the following request modes: n normal n triggered
This value is used to determine the request mode for the Transmit Stream/Category
Measurement Request frame. A Transmit Stream/Category Measurement Request frame can be sent in either normal mode or triggered mode. There are two options for this parameter normal and triggered . When the triggered option is selected, the Transmit Stream/Category
Measurement Request frame is sent only when the trigger condition occurs. The default value for this field is normal .
This value is used to set the "Number of Repetitions" field in the Transmit Stream/Category
Measurement Request frame. The Number of Repetitions field contains the requested number of repetitions for all the Measurement Request elements in this frame. A value of zero in this field indicates Measurement Request elements are executed once without repetition. A value of 65535 in the Number of Repetitions field indicates Measurement
Request elements are repeated until the measurement is cancelled or superseded. This field has values in the range (0, 65535). The default value is 65535.
This value is used to set the "Duration Mandatory" bit of the Measurement Request Mode field of the Transmit Stream/Category Measurement Request frame. The default value is enabled .
This value is used to set the Randomization Interval field in the Transmit Stream/Category
Measurement Request frame. The Randomization Interval is used to specify the desired maximum random delay in the measurement start time. It is expressed in units of TUs (Time
Units). When the request mode for the Transmit Stream/Category Measurement Request frame is set to "triggered", the Randomization Interval is not used and is set to 0. A
Randomization Interval of 0 in a measurement request indicates that no random delay is to be used. This field can be given a value in the range (0, 65535). The default value is 0.
This value is used to set the Measurement Duration field in the Transmit Stream/Category
Measurement Request frame. The Measurement Duration is set to the duration of the requested measurement. It is expressed in units of TUs. When the request mode for the
Transmit Stream/Category Measurement Request frame is set to triggered , the
Measurement Duration field should be set to 0. This field can be given a value in the range (0,
65535). The default value is 9776.
The value is used to set the Traffic Identifier field in the Transmit Stream/Category
Measurement Request frame. The Traffic Identifier field contains the TID subfield. The TID subfield indicates the TC or TS for which traffic is to be measured. This field can be given a value in the range (0, 255). The default value is 96
This value is used to set the 'Bin 0 Range' field in the Transmit Stream/Category
Measurement Request frame. Bin 0 Range indicates the delay range of the first bin (Bin 0) of the Transmit Delay Histogram, expressed in units of TUs. This field can be given a value in the range (0, 255). The default value is 6.
In the CLI
To select the information to be sent in TSM report requests using the command-line interface, access the CLI in config mode and issue the following command.
(host) (config)#wlan tsm-req-profile <profile>
ArubaOS 6.5.3.x
| User Guide Virtual APs | 433
BSS Transition Management (802.11v)
BSS Transition Management enables an AP to request a voice client to transition to a specific AP, or suggest a set of preferred APs to a voice client, due to network load balancing or BSS termination. This helps the voice client identify the best AP to which that client should transition to as that client roams. ArubaOS supports BSS
Transition Management features defined by the 802.11v standard.
The BSS Transition capability can improve throughput, data rates and QoS for the voice clients in a network by shifting (via transition) the individual voice traffic loads to more appropriate points of association within the
ESS.
Frame Types
BSS Transition Management uses the following frame types: n n n
Query: A Query frame is sent by the voice client that supports BSS transition management requesting a
BSS transition candidate list to its associated AP, if the associated AP indicates that it supports the BSS transition capability.
Request: An AP that supports BSS Transition Management responds to a BSS Transition Management
Query frame with a BSS Transition Management Request frame. The AP may also send an unsolicited BSS
Transition Management Request frame to a voice client at any time, if the client supports the BSS Transition
Management capability. The Request frame also contains a Disassociation flag. If the flag is set, then the AP forcefully disassociates the client after 10 beacon intervals.
Response: A Response frame is sent by the voice client back to the AP, informing whether it accepts or denies the transition.
802.11k and 802.11v Clients
For 802.11k capable clients, the client management framework uses the actual beacon report generated by the client in response to a beacon report request sent by the AP. This beacon report replaces the virtual beacon report for that client. For 802.11v capable clients, the controller uses the 802.11v BSS Transition message to steer clients to the desired AP upon receiving a client steer trigger from the AP.
Enabling 802.11v BSS Transition Management
802.11v BSS transition management is enabled by default. Client match uses this feature to steer devices. The cm-dot11v parameter in the rf arm-profile enables or disables client match to use the 802.11v feature.
(host) (config) #rf arm-profile default
(host) (Adaptive Radio Management (ARM) profile "default") # [no] cm-dot11v
Fast BSS Transition ( 802.11r)
ArubaOS provides support for Fast BSS Transition as part of the 802.11r implementation. Fast BSS Transition mechanism minimizes the delay when a voice client transitions from one BSS to another within the same ESS.
Fast BSS Transition establishes security and QoS states at the target AP before or during a re-association. This minimizes the time required to resume data connectivity when a BSS transition happens.
The following table provides the modes in which Fast BSS Transition is supported:
434 | Virtual APs ArubaOS 6.5.3.x | User Guide
Table 103: Supported VAP Forwarding Modes
VAP Forwarding Mode Support for 802.11r
Tunnel Mode
Decrypt-Tunnel Mode
Split-Tunnel Mode
Bridge Mode
Yes
Yes
No
Beta quality
Important Points to Remember n
Fast BSS Transition is operational only if the wireless client has support for 802.11r standard. If the client does not have support for 802.11r standard, it falls back to normal WPA2 authentication method.
Configuring Fast BSS Transition
You can enable and configure Fast BSS Transition on a per Virtual AP basis. You must create an 802.11r profile and associate that with the Virtual AP profile through an SSID profile. You can create and configure an 802.11r
profile using the WebUI or CLI.
Fast BSS transition is operational only with WPA2-Enterprise or WPA2-Personal.
In the WebUI
1. Navigate to the Configuration > Wireless > AP Configuration window. Select either the AP Group or AP
Specific tab.
a. If you selected the AP Group tab, click the AP group name for which you want to configure the 802.11r
profile.
b. If you selected the AP Specific tab, click the AP for which you want to configure the 802.11r profile.
2. In the Profiles list, expand the Wireless LAN menu, then expand the Virtual AP menu.
3. Select the Virtual AP profile for which you want to configure the 802.11r settings and expand SSID Profile .
4. Select the SSID profile on which you want to configure the 802.11r settings and select 802.11R Profile .
a. To edit an existing 802.11r profile, click the 802.11R Profile drop-down list in the Profile Details window pane and select the 802.11r profile you want to edit.
or b. To create a new 802.11r Profile, click the 802.11R Profile drop-down list and select New . Enter a new
802.11r profile name in the field to the right of the drop-down list.
You cannot use spaces in profile names.
5. Configure the following 802.11r radio settings.
a. Select the Advertise 802.11r Capability option to allow Virtual APs using this profile to advertise
802.11r capability.
b. Enter the mobility domain ID value (1-65535) in the 802.11r Mobility Domain ID field. The default value is 1.
c. Enter the R1 Key timeout value in seconds (60-86400) for decrypt-tunnel or bridge mode in the 802.11r
R1 Key Duration field. The default value is 3600.
ArubaOS 6.5.3.x
| User Guide Virtual APs | 435
6. Click Apply to save your settings.
In the CLI
Create an 802.11r profile using the following command:
(host) (config) #wlan dot11r-profile <profile> dot11r
Troubleshooting Fast BSS Transition
ArubaOS provides various troubleshooting options to verify the Fast BSS Transition functionalities.
In decrypt-tunnel mode and bridge mode, each r0 key generates up to four r1 keys and the controller pushes each r1 key to the corresponding AP. The following commands help verifying the pushing functionality:
Execute the following command to view all the r1 keys that are stored in an AP:
(host)(config) #show ap debug dot11r state
You can use the following command to remove an r1 key from an AP when the AP does not have a cached r1 key during Fast BSS Transition roaming.
(host) #ap debug dot11r remove-key
Execute the following command to view the hit/miss rate of r1 keys cached on an AP before a Fast BSS
Transition roaming. This counter helps to verify if enough r1 keys are pushed to the neighboring APs.
(host)(config) #show ap debug dot11r efficiency <client-mac>
SSID Profiles
A Service Set Identifier (SSID) is the network or WLAN that any client sees. A SSID profile defines the name of the network, authentication type for the network, basic rates, transmit rates, SSID cloaking, and certain WMM settings for the network.
SSID Profile Overview
ArubaOS supports different types of the Advanced Encryption Standard (AES), Temporal Key Integrity Protocol
(TKIP), and wired equivalent privacy (WEP) encryption. AES is the most secure and recommended encryption method. Most modern devices are AES capable and AES should be the default encryption method. Use TKIP only when the network includes devices that do not support AES. In these situations, use a separate SSID for devices that are only capable of TKIP.
Suite-B Cryptography
The Suite-B (bSec) protocol is a pre-standard protocol that has been proposed to the IEEE 802.11 committee as an alternative to 802.11i. The main difference between bSec and standard 802.11i is that bSec implements
Suite-B algorithms wherever possible. Notably, AES-CCM is replaced by AES-GCM, and the Key Derivation
Function (KDF) of 802.11i is upgraded to support SHA-256 and SHA-384. In order to provide interoperability with standard Wi-Fi software drivers, bSec is implemented as a shim layer between standard 802.11 Wi-Fi and a
Layer 3 protocol such as IP. A controller configured to advertise a bSec SSID will advertise an open network, however only bSec frames will be permitted on the network.
This feature requires the ACR license.
436 | Virtual APs ArubaOS 6.5.3.x | User Guide
The bSec protocol requires that you use VIA 2.1.1 or greater on the client device. Consult VIA documentation for more information on configuring and installing VIA.
The bSec protocol is available in 128-bit mode and 256-bit mode. The number of bits specifies the length of the
AES-GCM encryption key. Using United States Department of Defense classification terminology, bSec-128 is suitable for protection of information up to the SECRET level, while bSec-256 is suitable for protection of information up to the TOP SECRET level.
Suite-B AES-128-GCM and AES-256-GCM encryption is supported by the ArubaOS hardware. Note, however, that not all controllers support Suite-B encryption. The table below describes the controller support for Suite-B encryption in ArubaOS.
Controller
7000 Series
7200 Series
Serial Number Prefix
All serial numbers supported
All serial numbers supported
ACR License Support
Yes
Yes
To determine the serial number prefix for your controller, issue the CLI command show inventory and note the prefix before the system serial number. The serial number prefix in the example below appears in bold.
(host) #show inventory
Supervisor Card slot
System Serial#
: 0
: AK 0093676
Wi-Fi Multimedia Protection
Wi-Fi Multimedia™ (WMM®) is a Wi-Fi Alliance® certification program that is based on the IEEE 802.11e
amendment. WMM ensures QoS for latency-sensitive traffic in the air. WMM divides the traffic into four queues or access categories: n n n n voice video best effort background
Management Frame Protection
ArubaOS supports the IEEE 802.11w standard, also known as Management Frame Protection (MFP). MFP makes it difficult for an attacker to deny service by spoofing Deauth and Disassoc management frames.
MFP uses 802.11i (Robust Security Network) framework that establishes encryption keys between the client and AP.
MFP is configured on a virtual AP (VAP) as part of the wlan ssid-profile. There are two parameters that can be configured, mfp-capable and mfp-required. Both are disabled by default.
MFP can only be enabled on SSIDs that support WPA2. MFP is not supported on virtual APs using tunnel forwarding mode.
Configuring the SSID Profile
Follow the procedures below to create a new SSID profile and associate that profile to your Virtual AP.
In the WebUI
1. Navigate to Configuration > ADVANCED SERVICES > All Profiles .
2. In the Profiles list, expand the Wireless LAN menu, then select SSID .
ArubaOS 6.5.3.x
| User Guide Virtual APs | 437
3. Select an existing profile from the Profile Details pane, or enter create a new profile by entering a new name into the entry blank, then clicking Add .
4. Configure the SSID profile parameters described in
, then click Apply .
The SSID profile configuration settings are divided into two tabs, Basic and Advanced.
The Basic tab displays only those configuration settings that often need to be adjusted to suit a specific network. The Advanced tab shows all configuration settings, including settings that do not need frequent adjustment or should be kept at their default values. If you change a setting on one tab then click and display the other tab without saving your configuration, that setting will revert to its previous value.
Table 104: SSID Profile Parameters
Parameter Description
Basic SSID Profile Settings
Network Name
Network Authentication
Encryption
Name that uniquely identifies a wireless network. The network name, or ESSID can be up to 31 characters. If the ESSID includes spaces, you must enclose it in quotation marks.
The layer-2 authentication to be used on this ESSID to protect access and ensure the privacy of the data transmitted to and from the network.
n n
None
802.1X/WEP n n n n
WPA
WPA-PSK
WPA2
WPA2-PSK n n xSec
Mixed
If you select the Mixed authentication option, a drop-down list will appear in the Network Authentication section. Click this drop-down list and select the combination of authentication types supported by APs using this SSID profile.
This field shows the default encryption type used on this ESSID. Unselect the default encryption type if you do not want encryption, or click the Advanced tab to define a new encryption type.
Keys If you selected WPA-PSK or WPA2-PSK authentication or a mixed authentication type that supports pre-shared keys, enter and confirm the Hex Key or PSK passphrase in the PSK Key/Passphrase and Confirm PSK Key/Passphrase fields.
n n
To define a hex key, enter a 64-character hexadecimal string.
To define a PSK passphrase, enter san ASCII string 8-63 characters in length.
Next click the Format drop-down list and select Hex or PSK Passphrase to select the format for the key or passphrase.
Advanced SSID Profile Settings
SSID Enable Click this checkbox to enable or disable the SSID. The SSID is enabled by default.
Encryption Select one of the following encryption types:
438 | Virtual APs ArubaOS 6.5.3.x | User Guide
Table 104: SSID Profile Parameters
Parameter
xSec
Description
opensystem
static-wep
dynamic-wep
wpa-tkip
wpa-aes
wpa-psk-tkip
wpa-psk-aes
wpa2-aes
wpa2-psk-aes
wpa2-psk-tkip
wpa2-tkip
wpa2-aes-gcm-128
wpa2-aes-gcm-256
Encryption and tunneling of Layer-2 traffic between the controller and wired or wireless clients, or between controllers. To use xSec encryption, you must use a
RADIUS authentication server. For clients, you must install the Funk Odyssey client software.
Requires installation of the xSec license. For xSec between controllers, you must install an xSec license in each controller.
No authentication and encryption.
WEP with static keys.
WEP with dynamic keys.
WPA with TKIP encryption and dynamic keys using 802.1X.
WPA with AES encryption and dynamic keys using 802.1X.
WPA with TKIP encryption using a preshared key.
WPA with AES encryption using a preshared key.
WPA2 with AES encryption and dynamic keys using 802.1X.
WPA2 with AES encryption using a preshared key.
WPA2 with TKIP encryption using a preshared key.
WPA2 with TKIP encryption and dynamic keys using 802.1X.
WPA2 with AES GCM-128 (Suite-b) encryption and dynamic keys using 802.1X.
NOTE: This parameter requires the ACR license. For further information on
Suite-B encryption, see
Suite-B Cryptography on page 436 .
WPA2 with AES GCM-256 (Suite-b) encryption and dynamic keys using 802.1X.
NOTE: This parameter requires the ACR license. For further information on
Suite-B encryption, see
Suite-B Cryptography on page 436 .
Enable Management
Frame Protection
Require Management
Frame Protection
DTIM Interval
802.11g Transmit Rates
When selected, the SSID supports MFP-capable and traditional clients.
NOTE: MFP can only be enabled on SSIDs that support WPA2.
When selected, the SSID supports MFP-capable clients only.
NOTE: MFP can only be enabled on SSIDs that support WPA2.
Specifies the interval, in milliseconds, between the sending of Delivery Traffic
Indication Messages (DTIMs) in the beacon. This is the maximum number of beacon cycles before unacknowledged network broadcasts are flushed. When using wireless clients that employ power management features to sleep, the client must revive at least once during the DTIM period to receive broadcasts
Select the set of 802.11b/g rates at which the AP is allowed to send data. The actual transmit rate depends on what the client is able to handle, based on information sent at the time of association and on the current error/loss rate of the client.
ArubaOS 6.5.3.x
| User Guide Virtual APs | 439
Table 104: SSID Profile Parameters
Parameter Description
802.11g Basic Rates
802.11a Transmit Rates
802.11a Basic Rates
Station Ageout Time
Max Transmit Attempts
RTS Threshold
Short Preamble
Max Associations
Wireless Multimedia
(WMM)
Select the set of supported 802.11b/g rates that are advertised in beacon frames and probe responses.
Select the set of 802.11a rates at which the AP is allowed to send data. The actual transmit rate depends on what the client is able to handle, based on information sent at the time of association and on the current error/loss rate of the client.
Select the set of supported 802.11a rates, in Mbps, that are advertised in beacon frames and probe responses.
Time, in seconds, that a client is allowed to remain idle before being aged out.
Maximum number of retries allowed for the AP to send a frame.
Wireless clients transmitting frames larger than this threshold must issue
Request to Send (RTS) and wait for the AP to respond with Clear to Send (CTS).
This helps prevent mid-air collisions for wireless clients that are not within wireless peer range and cannot detect when other wireless clients are transmitting.
The default value is 2333 bytes.
Click this checkbox to enable or disable a short preamble for 802.11b/g radios.
Network performance may be higher when short preamble is enabled. In mixed radio environments, some 802.11b wireless client stations may experience difficulty associating with the AP using short preamble. To use only long preamble, disable short preamble. Legacy client devices that use only long preamble generally can be updated to support short preamble.
Maximum number of wireless clients per radio for the SSID (subject to an AP limit of 255 clients per radio).
The supported range is 0-255 clients. Default value is 64.
Enables or disables WMM, also known as IEEE 802.11e Enhanced Distribution
Coordination Function (EDCF). WMM provides prioritization of specific traffic relative to other traffic in the network.
Wireless Multimedia U-
APSD (WMM-UAPSD)
Powersave
Override DSCP mappings for WMM clients
DSCP mapping for WMM voice AC
Enable Wireless Multimedia (WMM) UAPSD powersave.
WMM TSPEC Min Inactivity
Interval
Specify the minimum inactivity time-out threshold of WMM traffic. This setting is useful in environments where low inactivity interval time-outs are advertised, which may cause unwanted timeouts.
The supported range is 0-3,600,000 milliseconds, and the default value is 0 milliseconds.
Override the default DSCP mappings in the SSID profile with the ToS value. This setting is useful when you want to set a non-default ToS value for a specific traffic.
DSCP used to map WMM voice traffic.
The supported range is 0-63.
DSCP mapping for WMM video AC
Select the DSCP used to map WMM video traffic.
The supported range is 0-63.
440 | Virtual APs ArubaOS 6.5.3.x | User Guide
Table 104: SSID Profile Parameters
Parameter Description
DSCP mapping for WMM best-effort AC
DSCP mapping for WMM background AC
Hide SSID
Select the DSCP value used to map WMM best-effort traffic.
The supported range is 0-63.
Select the DSCP used to map WMM background traffic.
The supported range is 0-63.
Select this checkbox to enable or disable the hiding of the SSID name in beacon frames. Note that hiding the SSID does very little to increase security.
WMM Access Class of EAP traffic
Extensible Authentication Protocol (EAP) traffic can be assigned to one of the following Wi-Fi Multimedia (WMM) traffic classes. By default, EAP traffic is mapped to the default "best effort" traffic class.
n n background best-effort n n n default video voice
Deny_Broadcast Probes When a client sends a broadcast probe request frame to search for all available SSIDs, this option controls whether or not the system responds for this SSID. When enabled, no response is sent and clients have to know the SSID in order to associate to the SSID. When disabled, a probe response frame is sent for this SSID.
Local Probe Request
Threshold (dB)
Disable Probe Retry
Enter the SNR threshold below which incoming probe requests will get ignored.
The supported range of values is 0-100 dB. A value of 0 disables this feature.
Click this checkbox to enable or disable battery MAC level retries for probe response frames. By default this parameter is enabled, which mean that MAC level retries for probe response frames is disabled.
NOTE: This parameter is not supported for 200 Series access points.
Battery Boost
WEP Key 1
WEP Key 2
Converts multicast traffic to unicast before delivery to the client, thus allowing you to set a longer DTIM interval. The longer interval keeps associated wireless clients from activating their radios for multicast indication and delivery, leaving them in power-save mode longer and thus lengthening battery life.
This parameter requires the PEFNG license.
First static WEP key associated with the key index. Can be 10 or 26 hex characters in length.
Second static WEP key associated with the key index. Can be 10 or 26 hex characters in length.
WEP Key 3
WEP Key 4
WEP Transmit Key Index
WPA Hexkey
WPA Passphrase
Third Static WEP key associated with the key index. Can be 10 or 26 hex characters in length.
Fourth Static WEP key associated with the key index. Can be 10 or 26 hex characters in length.
Key index that specifies which static WEP key is to be used. Can be 1, 2, 3, or 4.
WPA pre-shared key (PSK).
WPA passphrase with which to generate a pre-shared key (PSK).
ArubaOS 6.5.3.x
| User Guide Virtual APs | 441
Table 104: SSID Profile Parameters
Parameter Description
Maximum Transmit
Failures
BC/MC Rate Optimization
Rate Optimization for delivering EAPOL frames
Strict Spectralink Voice
Protocol (SVP)
802.11g Beacon Rate
The AP assumes the client has left and should be deauthorized when the AP detects this number of consecutive frames were not delivered because the maximum retry threshold as been exceeded.
Click this checkbox to enable or disable scanning of all active stations currently associated to an AP to select the lowest transmission rate for broadcast and multicast frames. This option only applies to broadcast and multicast data frames; 802.11 management frames are transmitted at the lowest configured rate.
NOTE: Do not enable this parameter unless instructed to do so by your Aruba technical support representative.
Click this checkbox to use a more conservative rate for more reliable delivery of EAPOL frames.
Click this checkbox to enable Strict Spectralink Voice Protocol (SVP)
802.11a Beacon Rate
Video Multicast Rate
Optimization
Click this drop-down list to select the beacon rate for 802.11g (use for
Distributed Antenna System (DAS) only). Using this parameter in normal operation may cause connectivity problems.
Click this drop-down list to select the beacon rate for 802.11a (use for
Distributed Antenna System (DAS) only). Using this parameter in normal operation may cause connectivity problems.
When configured, the controller chooses the rate for video multicast frames.
You can configure Modulation Coding Scheme (MCS) rates as well. MCS is an important setting because it provides for potentially greater throughput.
NOTE: The following information displays the MCS rate if the Short guard interval in 20 MHz mode setting in High-throughput SSID profile is either enabled or disabled:
MCS Streams 20 MHz 20 MHz SGI
-----------------------
0 1 6.5
7.2
3
4
5
1
2
1
1
1
1
1
13.0
19.5
26.0
39.0
52.0
14.4
21.7
28.9
43.3
57.8
8
9
6
7
10 2
11 2
12 2
13 2
2
2
1
1
58.5
65.0
13.0
26.0
39.0
52.0
65.0
72.2
14.4
28.9
43.3
57.8
78.0
86.7
104.0
115.6
14 2
15 2
117.0
130.0
130.0
144.4
NOTE: The MCS rates for video multicast are supported in all 802.11n -capable
APs. This is not supported in 320 Series AP.
442 | Virtual APs ArubaOS 6.5.3.x | User Guide
Table 104: SSID Profile Parameters
Parameter
Advertise QBSS Load IE
Description
Advertise Location
Information
Advertise AP Name
Enforce User VLAN for
Open Stations
Click this checkbox to enable the AP to advertise the QBSS load element. The element includes the following parameters that provide information on the traffic situation: n n
Station count: The total number of stations associated to the QBSS.
Channel utilization: The percentage of time (normalized to 255) the channel is sensed to be busy. The access point uses either the physical or the virtual carrier sense mechanism to sense a busy channel.
n Available admission capacity: The remaining amount of medium time
(measured as number of 32us/s) available for a station via explicit admission control.
The QAP uses these parameters to decide whether to accept an admission control request. A wireless station uses these parameters to choose the appropriate access points.
NOTE: Ensure that WMM is enabled for legacy APs to advertise the QBSS load element. For 802.11n APs, ensure that either wmm or high throughput is enabled.
When this option is enabled, APs broadcast their location within a IE carried in
Beacon frames and Probe Response frames. The AP’s latitude, longitude and altitude can be configured on the Configuration > Wireless> AP Installation page of the controller WebUI, or using the provision-ap command in the controller command-line interface.
If this parameter is enabled, APs will broadcast the AP name configured by the ap-name command. This option is disabled by default.
Select this option to restrict data traffic from open stations to the user's assigned VLAN. This option is disabled by default.
Enable OKC Opportunistic Key Caching (OKC) is a similar technique, not defined by 802.11i, available for authentication between multiple APs in a network where those
APs are under common administrative control. An Aruba deployment with multiple APs under the control of a single controller is one such example. Using
OKC, a station roaming to any AP in the network will not have to complete a full authentication exchange, but will instead just perform the 4-way handshake to establish transient encryption keys.
In the CLI
(host)(config) #wlan ssid-profile <profile>
WLAN Authentication
The AAA profile configures the authentication for a WLAN. The AAA profile defines the type of authentication
(802.1X in this example), the authentication server group, and the default user role for authenticated users.
It is recommended that you assign a unique name to each virtual AP, SSID, and AAA profile that you modify.
Configuring an AAA Profile in the WebUI
1. Navigate to Configuration > Security > Authentication > Profiles , the select the AAA Profiles tab.
2. Scroll down to the bottom of the AAA Profiles Summary pane, then click Add.
An entry blank appears.
3. Enter the AAA profile name, then click Add.
4. In the profiles list, and select the AAA profile you just created.
ArubaOS 6.5.3.x
| User Guide Virtual APs | 443
5. Configure the AAA profile parameters (see
6. Click Apply.
Table 105: AAA Profile Parameters
Parameter
Initial role
Description
MAC Authentication Default
Role
802.1X Authentication Default
Role
Click the Initial Role drop-down list and select a role for unauthenticated users. The default role for unauthenticated users is logon .
Click the MAC Authentication Default Role drop-down list and select the role assigned to the user when the device is MAC authenticated.
The default role for MAC authentication is the guest user role. If derivation rules are present, the role assigned to the client through these rules take precedence over the default role.
NOTE: This feature requires the PEFNG license.
Click the 802.1X Authentication Default Role drop-down list and select the role assigned to the client after 802.1X authentication. The default role for 802.1X authentication is the guest user role. If derivation rules are present, the role assigned to the client through these rules take precedence over the default role.
NOTE: This feature requires the PEFNG license.
User idle timeout Select the Enable checkbox to configure user idle timeout value for this profile. Specify the idle timeout value for the client in seconds. A value of 0, deletes the user immediately after disassociation from the wireless network. Valid range is 30-15300 in multiples of 30 seconds. Enabling this option overrides the global settings configured in the AAA timers. If this is disabled, the global settings are used.
RADIUS Interim Accounting
User derivation rules
Wired to Wireless Roaming
SIP authentication role
Device Type Classification
When this option is enabled, the RADIUS accounting feature allows the controller to send Interim-Update messages with current user statistics to the server at regular intervals. This option is disabled by default, allowing the controller to send only start and stop messages to the RADIUS accounting server.
Click the User derivation rules drop-down list and specify a user attribute profile from which the user role or VLAN is derived.
Enable this feature to keep users authenticated when they roam from the wired side of the network. This feature is enabled by default.
Click the SIP authentication role drop-down list and specify the role assigned to a session initiation protocol (SIP) client upon registration.
NOTE: This feature requires the PEFNG license.
When you select this option, the controller will parse user-agent strings and attempt to identify the type of device connecting to the
AP. When the device type classification is enabled, the Global client table shown in the Monitoring > Network > All WLAN Clients window shows each client’s device type, if that client device can be identified.
444 | Virtual APs ArubaOS 6.5.3.x | User Guide
Table 105: AAA Profile Parameters
Parameter
Enforce DHCP
Description
When you select this option, clients must obtain an IP using DHCP before they are allowed to associate to an AP. Enable this option when you create a user rule that assigns a specific role or VLAN based upon the client device’s type. For details, see
User-Derived VLANs on page 394 .
NOTE: If a client is removed from the user table by the “Logon user lifetime” AAA timer, then that client will not be able to send traffic until it renews it’s DHCP.
NOTE: Enforce DHCP is available on the controller for APs configured for tunnel or decrypt-tunnel forwarding mode only.
PAN firewalls Integration
Open SSID RADIUS Accounting
Requires IP mapping at Palo Alto Networks firewalls. For details, see
Palo Alto Networks Firewall Integration on page 695 .
Initiates RADIUS accounting as soon as the user associates to an
Open SSID without any authentication.
NOTE: Do not enable this parameter for wired users. If enabled, the controller sends RADIUS accounting packets for unauthenticated wired users.
7. In the profiles list, select the AAA profile to expand the list of other profiles associated with that AAA profile.
8. Click 802.1X Authentication.
The 802.1X Authentication Profile appears.
a. Click the 802.1X Authentication Profile drop-down list and select an authentication profile to associate with your AAA profile.
b. Click Apply.
9. Click 802.1X Authentication Server Group.
The 802.1X Authentication Server Group appears.
a. Click the 802.1X Authentication Server Group drop-down list and select the server group to associate with your AAA profile.
b. Click Apply.
10.Click
MAC Authentication.
The MAC Authentication Profile appears.
a. Click the MAC Authentication Profile drop-down list and select a MAC authentication profile to associate with your AAA profile.
b. Click Apply.
11.Click
MAC Authentication Server Group.
The MAC Authentication Server Group appears.
a. Click the MAC Authentication Server Group drop-down list and select the MAC server group to associate with your AAA profile.
b. Click Apply.
12.Click
RADIUS Authentication Server Group.
The RADIUS Authentication Server Group appears.
a. Click the RADIUS Authentication Server Group drop-down list and select the MAC server group to associate with your AAA profile.
b. Click Apply.
Configuring an AAA Profile in the CLI
(host)(config) #aaa authentication dot1x <profile>
(host)(config) #aaa profile <profile>
ArubaOS 6.5.3.x
| User Guide Virtual APs | 445
High-Throughput Virtual APs
With the implementation of the IEEE 802.11ac standard, very-high-throughput can be configured to operate on the 5 GHz frequency band. High-throughput (802.11n) can be configured on both the 5 GHz and 2.4 GHz frequency bands. High-throughput is enabled by default, and can be enabled or disabled in the 802.11a and
802.11g radio profiles. For details, see
802.11a and 802.11g RF Management Profiles on page 563
Two different profiles define settings specific to high-throughput APs. The High-throughput radio profile defines settings for 40 MHz tolerance, is associated to an AP through its 802.11a or 802.11g radio profile. The
High-throughput SSID profile configures the high-throughput SSID settings for 802.11n, and is associated to an AP through its virtual AP profile
Stations are not allowed to use high-throughput with TKIP standalone encryption, although TKIP can be provided in mixed-mode BSSIDs that support high-throughput. High-throughput is disabled on a BSSID if the encryption mode is standalone TKIP or WEP.
De-aggregation of MAC Service Data Units (A-MSDUs) is supported on the 7000 Series and 7220 controllers with a maximum frame transmission size of 4k bytes; however, this feature is always enabled and is not configurable.
Aggregation is not currently supported.
Configuring the High-Throughput Radio Profile
You can configure high-throughput radio profile settings using the WebUI or CLI interfaces
In the WebUI
1. Navigate to Advanced Services > All Profile Management .
2. In the Profiles list, expand the RF Management menu, then select High-throughput radio .
3. Select an existing profile from the Profile Details pane, or enter create a new profile by entering a new name into the entry blank, then clicking Add .
The configuration settings in this profile are divided into two tabs, Basic and Advanced.
The Basic tab displays only those configuration settings that often need to be adjusted to suit a specific network. The
Advanced tab shows all configuration settings, including settings that do not need frequent adjustment or should be kept at their default values. If you change a setting on one tab then click and display the other tab without saving your configuration, that setting will revert to its previous value.
Table 106: High-Throughput Radio Profile Configuration Parameters
Description Parameter
Basic
40MHz intolerance This parameter controls whether or not APs using this radio profile will advertise intolerance of 40 MHz operation. By default, this option is disabled, and 40 MHz operation is allowed. If you do not want to use 40 Mhz operation, select the 40MHz intolerance checkbox to enable this feature.
Advanced
446 | Virtual APs ArubaOS 6.5.3.x | User Guide
Parameter honor 40MHz intolerance
CSD override
Description
When enabled, the radio will stop using the 40 MHz channels if the 40 MHz intolerance indication is received from another AP or station. Uncheck the
Honor 40 Mhz intolerance checkbox to disable this feature.
Default: Enabled
Most transmissions to high throughput (HT) stations are sent through multiple antennas using cyclic shift diversity (CSD). When you enable the CSD
Override parameter, CSD is disabled and only one antenna transmits data, even if they are being sent to high-throughput stations. This enables interoperability for legacy or high-throughput stations that cannot decode
802.11n CDD data. This option is disabled by default, and should only be enabled under the supervision of Aruba technical support.
Use this feature to turn off antenna diversity when the AP must support legacy clients such as Cisco 7921g VoIP phones, or older 802.11g clients (e.g.
Intel Centrino clients). Note, however, that enabling this feature can reduce overall throughput rates.
4. Click Apply .
In order for the settings in this profile to take effect, the profile must be associated with an AP's 802.11a or
802.11g radio profile. For details, see the Associated Profiles section of
Table 129 , 802.11a/802.11g RF
Management Configuration Parameters.
In the CLI
(host)(config) #rf ht-radio-profile <profile>
(host)(config) #rf dot11a-radio-profile|dot11g-radio-profile <profile> high-throughput-enable
Configuring the High-Throughput SSID Profile
You can configure high-throughput SSID profile settings using the WebUI or CLI interfaces
In the WebUI
1. Navigate to Advanced Services > All Profile Management .
2. In the Profiles list, expand the Wireless LAN menu, then select High-throughput SSID .
3. Select an existing profile from the Profile Details pane, or enter create a new profile by entering a new name into the entry blank, then clicking Add .
4. Configure the high-throughput SSID profile settings described in
.
The High-Throughput SSID profile configuration settings are divided into two tabs, Basic and
Advanced . The Basic tab displays only those configuration settings that often need to be adjusted to suit a specific network. The Advanced tab shows all configuration settings, including settings that do not need frequent adjustment or should be kept at their default values. If you change a setting on one tab then click and display the other tab without saving your configuration, that setting will revert to its previous value. Both basic and advanced settings are described in
ArubaOS 6.5.3.x
| User Guide Virtual APs | 447
Table 107: High-Throughput SSID Profile Parameters
Parameter Description
Basic
High throughput enable (SSID)
40 MHz channel usage
Very High throughput enable (SSID)
80 MHz channel usage (VHT)
VHT - Explicit Transmit Beamforming
VHT - Multi User Transmit Beamforming
Determines if this high-throughput SSID allows highthroughput (802.11n) stations to associate.
Enabling high-throughput in an WLAN high-throughput SSID profile enables Wi-Fi Multimedia (WMM) base features for the associated SSID.
Default: Enabled.
Enable or disable the use of 40 MHz channels. This parameter is enabled by default.
Default: Enabled.
Enable or disable support for Very High Throughput
(802.11ac) on the SSID.
Default: Enabled.
Enable or disable the use of 80 MHz channels on Very High
Throughput (VHT) APs.
Default: Enabled.
Enable or disable VHT Explicit Transmit Beamforming for the
802.11ac-capable APs. When this parameter is enabled, the
AP requests information about the Multiple-Input and
Multiple-Output (MIMO) channel and uses that information to transmit data over multiple transmit streams using a calculated steering matrix. The result is higher throughput due to improved signal at the beamforming (the receiving client). If this parameter is disabled, all other transmit beamforming settings will not take effect.
Default: Enabled.
Enable or disable VHT Multi-User Transmit Beamforming. If this parameter is disabled, all other Multi-User Transmit
Beamforming configuration parameters have no effect.
Default: Enabled.
NOTE: This is setting applicable for 320 Series APs only.
Advanced
BA AMSDU Enable
Temporal Diversity Enable
Legacy stations
Enable or disable Receive AMSDU in Block ACK (BA) negotiation. If enabled, AP denies clients from sending
AMSDU using BA agreement.
Default: Enabled.
When this setting is enabled and the client is not responding to 802.11 packets, the AP will launch two hardware retries; if the hardware retries are not successful then it attempts software retries.
Default: Disabled.
Control whether or not legacy (non-HT) stations are allowed to associate with this SSID. By default, legacy stations are allowed to associate. This setting has no effect on a BSS in which HT support is not available.
Default: Enabled.
448 | Virtual APs ArubaOS 6.5.3.x | User Guide
Table 107: High-Throughput SSID Profile Parameters
Parameter
Low-density Parity Check
Description
Maximum number of spatial streams usable for
STBC reception
Maximum number of spatial streams usable for
STBC transmission.
MPDU Aggregation
Max received A-MPDU size
Max transmitted A-MPDU size
Min MPDU start spacing
If enabled, the AP will advertise Low-density Parity Check
(LDPC) support. LDPC improves data transmission over radio channels with high levels of background noise.
Default: Enabled.
Control the maximum number of spatial streams usable for
Space-Time Block Code (STBC) reception. 0 disables STBC reception, 1 uses STBC for MCS 0-7. Higher MCS values are not supported. (Supported on the AP-105, 130 Series, and
170 Series only. The configured value will be adjusted based on AP capabilities.)
Default: 1.
NOTE: If transmit beamforming is enabled, STBC will be disabled for beamformed frames.
Control the maximum number of spatial streams usable for
STBC transmission. 0 disables STBC transmission, 1 uses
STBC for MCS 0-7. Higher MCS values are not supported.
(Supported on AP-105, 130 Series, and 170 Series only. The configured value will be adjusted based on AP capabilities.)
Default: 1.
NOTE: If transmit beamforming is enabled, STBC will be disabled for beamformed frames.
Enable or disable MAC Protocol Data Unit (MPDU) aggregation.
High-throughput APs are able to send aggregated MAC protocol data units (MDPUs), which allow an AP to receive a single block acknowledgment instead of multiple ACK signals.
This option, which is enabled by default, reduces network traffic overhead by effectively eliminating the need to initiate a new transfer for every MPDU.
Default: Enabled.
Control the maximum size, in bytes, of an Aggregated-MAC
Packet Data Unit (A-MPDU) that can be received on this highthroughput SSID.
Default: 65535 bytes.
Control the maximum size, in bytes, of an A-MPDU that can be sent on this high-throughput SSID.
Range: 1576–65535 bytes.
Minimum time between the start of adjacent MPDUs within an aggregate MPDU, in microseconds.
Range: 0 (No restriction on MDPU start spacing), .25 µsec, .5
µsec, 1 µsec, 2 µsec, 4 µsec.
Default: 0.
ArubaOS 6.5.3.x
| User Guide Virtual APs | 449
Table 107: High-Throughput SSID Profile Parameters
Parameter
Short guard interval in 20 MHz mode
Description
Short guard interval in 40 MHz mode
Short guard interval in 80 MHz mode
Supported MCS set
VHT - Supported MCS Map
VHT - Transmit Beamforming Sounding Interval
Enable or disable use of short (400 ns) guard interval in 20
MHz mode.
A guard interval is a period of time between transmissions that allows reflections from the previous data transmission to settle before an AP transmits data again. An AP identifies any signal content received inside this interval as unwanted inter-symbol interference, and rejects that data. The 802.11n
standard specifies two guard intervals: 400 ns (short) and
800 ns (long). Enabling a short guard interval can decrease network overhead by reducing unnecessary idle time on each AP. Some outdoor deployments, may, however require a longer guard interval. If the short guard interval does not allow enough time for reflections to settle in your mesh deployment, inter-symbol interference values may increase and degrade throughput.
Default: Enabled.
Enable or disable use of short guard interval (400 ns) in 40
MHz mode of operation.
Default: Enabled.
Enable or disable use of short guard interval (400 ns) in 80
MHz mode of operation.
Default: Enabled.
A list of Modulation Coding Scheme (MCS) values or ranges of values to be supported on this SSID. The MCS you choose determines the channel width (20 MHz vs. 40 MHz vs. 80
MHz) and the number of spatial streams used by the mesh node.
Range: 0–31.
Default: 0–31.
To specify a smaller range of values, enter a hyphen between the lower and upper values. To specify a series of different values, separate each value with a comma.
Examples:
2–10
1,3,6,9,12
MCS value of 16-23 are supported on 130 Series/RAP-
155/11ac APs only.
MCS value of 24-31 are supported on 320 Series APs only.
Comma separated list of maximum supported MCS for spatial streams 1 through 4. Valid values for maximum MCS are 7, 8, 9, and '-' (if spatial stream is not supported).
Maximum MCS of a spatial stream cannot be higher than the previous streams. If an MCS is not valid for a particular combination of bandwidth and number of spatial streams, it will not be used for Tx and Rx.
Default: 9,9,9,9.
Time interval in milliseconds between channel information updates between the AP and the beamformed client.
Default: 25 msec.
NOTE: This is applicable for 802.11ac-capable APs only.
450 | Virtual APs ArubaOS 6.5.3.x | User Guide
Table 107: High-Throughput SSID Profile Parameters
Parameter
Maximum VHT MPDU size
Description
Maximum number of MSDUs in an A-MSDU on best-effort AC
Maximum number of MSDUs in an A-MSDU on background AC
Maximum number of MSDUs in an A-MSDU on video AC
Maximum number of MSDUs in an A-MSDU on voice AC
Maximum size of a VHT MPDU.
Default: 11454 bytes.
Set the maximum number of MSDUs in a TX A-MSDU on best effort AC.
Default: 2.
NOTE: In tunnel and decrypt-tunnel forwarding mode, TX A-
MSDU is disabled if the value is set to 0. If the value is set to non-zero, TX A-MSDU is enabled and set to this value.
Set the maximum number of MSDUs in a TX A-MSDU on background AC.
Default: 2.
NOTE: TX A-MSDU is disabled if the value is set to 0. In decrypt-tunnel forwarding mode, TX A-MSDU on background
AC is disabled and assigning any value has no effect.
Set the maximum number of MSDUs in a TX A-MSDU on video AC.
Default: 2.
NOTE: TX A-MSDU is disabled if the value is set to 0. In decrypt-tunnel forwarding mode, TX A-MSDU on video AC is disabled and assigning any value has no effect.
Set the maximum number of MSDUs in a TX A-MSDU on voice AC.
Default: 0.
NOTE: TX A-MSDU is disabled if the value is set to 0. In decrypt-tunnel forwarding mode, TX A-MSDU on voice AC is disabled and assigning any value has no effect.
In order for the settings in this profile to take effect, the profile must be associated with an AP's Virtual AP profile. For details on associating a high-throughput SSID profile with a Virtual AP profile, see
Virtual AP Profile on page 419
In the CLI
(host)(config) #wlan ht-ssid-profile <profile-name> n n n n
Guest WLANs
Guest usage in enterprise wireless networks requires the following special consideration:
Guest users must be separated from employee users by VLANs in the network.
Guests must be limited not only in where they may go, but also by what network protocols and ports they may use to access resources.
Guests should be allowed to access only the local resources that are required for IP connectivity. These resources include DHCP and possibly DNS if an outside DNS server is not available. In most cases, a public
DNS is always available.
All other internal resources should be off limits for the guest. This restriction is achieved usually by denying any internal address space to the guest user.
ArubaOS 6.5.3.x
| User Guide Virtual APs | 451
n
A time-of-day restriction policy should be used to allow guests to access the network only during normal working hours, because they should be using the network only while conducting official business. A rate limit can also be put on each guest user to keep the user from using up the limited wireless bandwidth.
Accounts should be set to expire when their local work is completed, typically at the end of each business day.
The procedures in the following example create an guest WLAN that only allows HTTP and HTTPS traffic from
9:00 a.m. to 5 p.m. on weekdays.
n n n
Configuring a Guest Virtual AP
The following sections describe how to do this using the WebUI and the CLI.
Configuring a Guest VLAN
In this example, users on the “Corpnet” WLAN are placed into VLAN 1, which is the default VLAN configured on the controller. For guest users, you need to create another VLAN and assign the VLAN interface an IP address.
Each Virtual AP supports a maximum of 256 VLANs.
In the WebUI
1. Navigate to the Configuration > Network > VLANs page.
2. Click Add to add a VLAN. Enter 2 in the VLAN ID, and click Apply .
3. To assign an IP address and netmask to the VLAN you just created, navigate to the Configuration >
Network > IP > IP Interfaces page. Click Edit for VLAN 2. Enter an IP address and netmask for the VLAN interface, and then click Apply.
In the CLI
(host)(config) #vlan 2 interface vlan 2 ip address < address> <netmask>
Configuring a Guest Role
The guest role allows web (HTTP and HTTPS) access only during normal business hours (9:00 a.m. to 5:00 p.m.
Monday through Friday).
In the WebUI
1. Navigate to the Configuration > Security > Access Control > Time Ranges page.
2. Click Add . Enter a name, such as “workhours”. Select Periodic. Click Add . Under Add Periodic Rule, select
Weekday. For Start Time, enter 9:00. For End Time, enter 17:00. Click Done . Click Apply.
3. Select the Policies tab. Click Add . Enter a policy name, such as “restricted”. From the Policy Type dropdown list, select Session.
4. Click Add .
5.
(Optional) By default, firewall policies apply to IPv4 clients only. To configure a firewall policy for IPv6 clients, click the IP Version drop-down list and select IPv6.
6. Click the Service drop-down list, select service, then select svc-http .
7. Click the Time Range drop-down list and select the time range you previously configured.
8. Click Add .
452 | Virtual APs ArubaOS 6.5.3.x | User Guide
9. Repeat steps 4-8 to add another rule for the svc-https service. Click Apply.
10.Select the User Roles tab. Click Add.
Enter guest for Role Name. Under Firewall Policies, click Add.
Select
Choose from Configured Policies and select the policy you previously configured. Click Done.
11.Click
Apply .
In the CLI
(host)(config) #time-range workhours periodic weekday 09:00 to 17:00
(host)(config) #ip access-list session restricted any any svc-http permit time-range workhours any any svc-https permit time-range workhours
(host)(config) #user-role guest session-acl restricted
Configuring a Guest Virtual AP
In this example, you apply the guest virtual AP profile to a specific AP.
Best practices are to assign a unique name to each virtual AP, SSID, and AAA profile that you modify. In this example, you use the name guest to identify the virtual AP and SSID profiles.
In the WebUI
1. Navigate to Configuration > Wireless > AP Configuration > AP Specific page.
2. Click New . Either enter the AP name or select an AP from the list of discovered APs. Click Add . The AP name appears in the list.
3. Click Edit by the AP name to display the profiles that you can configure for the AP.
4. Expand the Wireless LAN profile menu.
5. Select Virtual AP .
a. Click the Add a profile drop down list in the Profile Details window and select NEW .
b. Enter guest, and click Add .
c. Click Apply .
6. Click the guest virtual AP to display profile details.
a. Make sure Virtual AP Enable is selected.
b. Select 2 for the VLAN.
c. Click Apply .
7. Under Profiles, select the AAA profile under the guest virtual AP profile.
a. In the Profile Details, select default-open from the AAA Profile drop-down list.
b. Click Apply.
8. Under Profiles, select the SSID profile under the guest virtual AP profile.
a. Select NEW from the SSID Profile drop-down menu.
b. Enter guest.
c. In the Profile Details, enter Guest for the Network Name.
d. Select None for Network Authentication and Open for Encryption.
e. Click Apply .
In the CLI
(host)(config) #wlan ssid-profile guest opmode opensystem
(host)(config) #wlan virtual-ap guest
ArubaOS 6.5.3.x
| User Guide Virtual APs | 453
vap-enable vlan 2 deny-time-range workhours ssid-profile guest aaa-profile default-open
(host)(config) #ap-name building3-lobby virtual-ap guest
Changing a Virtual AP Forwarding Mode
When you change the forwarding mode for a Virtual AP actively serving clients, the user table will NOT reflect accurate client information unless the entries for those users are manually cleared.
The following sections describe the procedure to change the forwarding mode on a Virtual AP serving wired or wireless clients.
To change the forwarding mode for wired users connected to the wired port on an AP:
1. Disable the port by issuing the CLI command ap wired-port-profile <ap-wired-port-profile> shutdown .
This will disconnect any wired clients using that port.
2. Issue the command aaa user delete {<ipaddr>|all|mac <macaddr>|name <username>|role
<role>} to remove from the user table the wired users associated with AP wired ports using the <ap-wiredport-profile>.
3. Issue the command ap wired-ap-profile <profile> forward-mode <mode> where <mode> is the new forwarding mode for the wired port
4. Reenable the port using the command ap wired-port-profile <ap-wired-port-profile> no shutdown .
To change the forwarding mode for wireless users associated with a virtual AP:
1. Issue the command ap-name <group> no virtual-ap <vap-profile> or ap-group <group> no virtual-ap
<vap-profile> to disassociate the AP or group of APs from the virtual AP profile.
2. Issue the command aaa user delete {<ipaddr>|all|mac <macaddr>|name <username>|role <role>} to remove from the user table the users associated to the virtual-ap specified in the previous step.
3. Issue the command wlan virtual-AP <vap-profile> forward-mode <mode> where <mode> is the new forwarding mode for the virtual AP.
4. Issue the command ap-name <group> virtual-ap <vap-profile> or ap-group <group> virtual-ap <vapprofile> to reassociate the AP or group of APs with the virtual AP profile.
454 | Virtual APs ArubaOS 6.5.3.x | User Guide
Chapter 20
Adaptive Radio Management
Aruba’s Adaptive Radio Management (ARM) takes the guesswork out of RF management by using automatic, infrastructure-based controls to maximize client performance and enhance the stability and predictability of the entire Wi-Fi network.
ARM Feature Overviews
The following sections provide a general overview of Adaptive Radio Management feature: n n n
ARM Coverage and Interference Metrics on page 459
Configuring ARM Settings
The section below describes the steps to configure the ARM function to automatically select the best channel and transmission power settings for each AP on your WLAN: n n n n n n n n
Configuring ARM Profiles on page 460
Assigning an ARM Profile to an AP Group on page 470
Configuring Non-802.11 Noise Interference Immunity on page 477
Using Multi-Band ARM for 802.11a/802.11g Traffic on page 470
Reusing Channels to Control RX Sensitivity Tuning on page 476
Enabling Traffic Shaping on page 473
Spectrum Load Balancing on page 476
ARM Troubleshooting
n
Troubleshooting ARM on page 477
Understanding ARM
Aruba's Adaptive Radio Management (ARM) technology maximizes WLAN performance even in the highest traffic networks by dynamically and intelligently choosing the best 802.11 channel and transmit power for each Aruba AP in its current RF environment.
Aruba’s ARM technology solves wireless networking challenges such as large deployments, dense deployments, and installations that must support VoIP or mobile users. Deployments with dozens of users per access point can cause network contention and interference, but ARM dynamically monitors and adjusts the network to ensure that all users are allowed ready access. ARM provides the best voice call quality with voice-aware spectrum scanning and call admission control.
With earlier technologies, network administrators would have to perform a site survey at each location to discover areas of RF coverage and interference, and then manually configure each AP according to the results of this survey. Static site surveys can help you choose channel and power assignments for APs, but these surveys are often time-consuming and expensive, and only reflect the state of the network at a single point in time. ARM is more efficient than static calibration, and, unlike older technologies, it continually monitors and adjusts radio resources to provide optimal network performance. Automatic power control can adjust AP
ArubaOS 6.5.3.x
| User Guide Adaptive Radio Management | 455
power settings if adjacent APs are added, removed, or moved to a new location within the network, minimizing interference with other WLAN networks. ARM adjusts only the affected APs, so the entire network does not require systemic changes.
ARM Support for 802.11n
ArubaOS version 3.3.x or later supports APs with the 802.11n standard, ensuring seamless integration of
802.11n devices into your RF domain. The Aruba AP’s 5 Ghz band capacity simplifies the integration of new
APs into your legacy network. You can also replace older APs with newer 802.11n-compliant APs while reusing your existing cabling and PoE infrastructure.
A high-throughput (802.11n) AP can use a 40 MHz channel pair comprised of two adjacent 20 MHz channels available in the regulatory domain profile for your country. When ARM is configured for a dual-band AP, it will dynamically select the primary and secondary channels for these devices. It can, however, continue to scan all changes in the a+b/g bands to calculate interference and detect rogue APs.
Monitoring Your Network with ARM
When ARM is enabled, the Aruba AP dynamically scans all 802.11 channels in its regulatory domain at regular intervals and will report everything it sees to the controller on each channel it scans. (By default,
802.11n-capable APs scan channels in all regulatory domains.) This includes, but is not limited to, data regarding WLAN coverage, interference, and intrusion detection. You can retrieve this information from the controller to get a quick health check of your WLAN deployment without having to walk around every part of a building with a network analyzer. (For additional information on the individual matrix gathered on the AP’s current assigned RF channel, see
ARM Coverage and Interference Metrics on page 459
.)
Maintaining Channel Quality
Hybrid APs and Spectrum Monitors determine channel quality by measuring channel noise, non-Wi-Fi
(interferer) utilization and duty-cycles, and certain types of retries. Regular APs using the ARM feature derive channel quality values by measuring the noise floor for both 802.11 and non-802.11 noise on that channel.
The ARM algorithm is based on what the individual AP hears, so each AP on your WLAN can effectively “self heal” by compensating for changing scenarios like a broken antenna or blocked signals from neighboring APs.
Additionally, ARM periodically collects information about neighboring APs to help each AP better adapt to its own changing environment.
Configuring ARM Scanning
The default ARM scanning interval is determined by the scan-interval parameter in the ARM profile. If the AP does not have any associated clients (or if most of its clients are inactive), the ARM feature will dynamically readjust this default scan interval, allowing the AP obtain better information about its RF neighborhood by scanning non-home channels more frequently. Starting with ArubaOS 6.2, if an AP attempts to scan a nonhome channel but is unsuccessful, the AP will make additional attempts to rescan that channel before skipping it and continuing on to other channels.
The Over the Air Updates feature allows an AP to get information about its RF environment from its neighbors, even the AP cannot scan. If you enable this feature, when an AP on the network scans a foreign
(non-home) channel, it sends an Over-the-Air (OTA) update in an 802.11 management frame that contains information about that AP's home channel, the current transmission EIRP value of the home channel, and onehop neighbors seen by that AP.
Starting with ArubaOS 6.3.1, if ARM reports a high noise floor on a channel within a 40 MHz channel pair or 80
MHz channel set, ARM performs an additional 20 MHz scan on each channel within that channel pair or set, to determine the actual noise floor of each affected channel. This allows ARM to avoid assigning the overused channel, while still allowing channel assignments to the other unaffected channels in that channel pair or set.
456 | Adaptive Radio Management ArubaOS 6.5.3.x | User Guide
Understanding ARM Application Awareness
Aruba APs keep a count of the number of data bytes transmitted and received by their radios to calculate the traffic load. When a WLAN gets very busy and traffic exceeds a predefined threshold, load-aware ARM dynamically adjusts scanning behavior to maintain uninterrupted data transfer on heavily loaded systems.
ARM-enabled APs will resume their complete monitoring scans when the traffic has dropped to normal levels.
You can also define a firewall policy that pauses ARM scanning when the AP detects critically important or latency-sensitive traffic from a specified host or network.
ARM’s band steering feature encourages dual-band capable clients to stay on the 5GHz band on dual-band
APs. This frees up resources on the 2.4GHz band for single band clients like VoIP phones.
The ARM “Mode Aware” option is a useful feature for single radio, dual-band WLAN networks with high density
AP deployments. If there is too much AP coverage, those APs can cause interference and negatively impact your network. Mode aware ARM can turn APs into Air Monitors if necessary, then turn those Air Monitors back into APs when they detect gaps in coverage. Note that an Air Monitor will not turn back into an AP if it detects client traffic (or client traffic increases), but will change to an AP only if it detects coverage holes.
Client Match
The ARM client match feature continually monitors a client's RF neighborhood to provide ongoing client bandsteering and load balancing, and enhanced AP reassignment for roaming mobile clients. This feature is recommended over the legacy bandsteering and spectrum load balancing features, which, unlike client match, do not trigger AP changes for clients already associated to an AP.
Legacy 802.11a/b/g devices do not support the client match feature. When you enable client match on 802.11ncapable devices, the client match feature overrides any settings configured for the legacy bandsteering, station handoff assist or load balancing features. 802.11ac-capable devices do not support the legacy bandsteering, station hand off or load balancing settings, so these APs must be managed on using client match.
When you enable this feature on an AP, that AP is responsible for measuring the RF health of its associated clients. The AP receives and collects information about clients in its neighborhood, and periodically sends this information to the controller. The controller aggregates information it receives from all APs using client match, and maintains information for all associated clients in a database. The controller shares this database with the
APs (for their associated clients), and the APs use the information to compute the client-based RF neighborhood and determine which APs should be considered candidate APs for each client. When the controller receives a client steer request from an AP, the controller identifies the optimal AP candidate and manages the client’s relocation to the desired radio. This is an improvement from previous releases, where the
ARM feature was managed exclusively by APs, without the larger perspective of the client's RF neighborhood.
The following client/AP mismatch conditions are managed by the client match feature: n n n
Load Balancing : Client match balances clients across APs on different channels, based upon the client load on the APs and the SNR levels that the client detects from an underused AP. If an AP radio can support additional clients, the AP will participate in client match load balancing and clients can be directed to that AP radio, subject to predefined SNR thresholds.
Sticky Clients : The client match feature also helps mobile clients that tend to stay associated to an AP despite low signal levels. APs using client match continually monitor the client's RSSI as it roams between
APs, and moves the client to an AP when a better radio match is found. This prevents mobile clients from remaining associated to an APs with less than ideal RSSI, which can cause poor connectivity and reduce performance for other clients associated with that AP.
Band Steering/Band Balancing : APs using the client match feature monitor the RSSI for clients that advertise a dual-band capability. If a client is currently associated to a 2.4 GHz radio and the AP detects that the client has a good RSSI from the 5 Ghz radio, the controller attempts to steer the client to the 5 Ghz
ArubaOS 6.5.3.x
| User Guide Adaptive Radio Management | 457
radio, as long as the 5 Ghz RSSI is not significantly worse than the 2.4 GHz RSSI, and the AP retains a suitable distribution of clients on each of it's radios.
The client match feature is enabled through the AP's ARM profile. Although default client match settings are recommended for most users, advanced client match settings can be configured using rf arm-profile commands in the command-line interface.
BSS Transition Management Support
The BSS Transition Management Support feature allows Client Match to steer devices using 802.11v BSS transition management standards for continuous wireless connectivity. This feature provides a seamless standards compatible method of device steering in wireless networks, as 802.11v BSS transition management support has become increasingly common in wireless devices.
Steering a Client
When Client Match attempts to steer the client to a more optimal AP, it sends out an 802.11v BSS transition management request to the 11v capable station and waits for a response.
1. Client Match begins a timeout session for the BSS transition management response or new association request to the desired AP.
2. If the request is rejected or the timeout session expires, Client Match is notified of the failed attempt and reinitiates the steer using the 802.11v BSS transition management request.
l l
If the client steer fails the maximum number of timeout attempts (default: 5), Client Match marks the client as 11v unsupported and falls back to using deauths to steer.
If the client steer fails due to request rejection, Client Match does not mark the client as 11v unsupported and continues to attempt to steer using the 802.11v BSS transition management request.
MAC Address Filtering
When an AP identifies a device, randomized MAC addresses advertised by the device will be filtered from those associated with the network. The MAC address associated with the network will be displayed in the RSSI report, while the unassociated addresses are excluded.
Multi-Media Sync-Up
Client Match offers a tighter integration with multiple media-aware ALGs to provide better call quality for programs like Skype for Business (Skype4b) and Facetime. With Client Match’s ability to understand various media protocols, clients are not steered to different APs in the middle of an active media session.
When a client participates in a call, the controller learns about the media session and sends this information to the AP that the client is currently associated to, as part of the variable bitrate (VBR) update. When the AP learns that the client is in a call, it will not attempt to steer the client to another AP until the controller indicates that the call has ended, allowing calls to run more smoothly without any disruptions to the ongoing media flow.
Multi-User MIMO Steering
Multi-user MIMO, or MU-MIMO Steering, groups multi-user-capable (MU-capable) clients to maximize the likelihood of MIMO transmissions, which increases downstream throughput performance in 802.11ac Wave 2
(gen 2) APs. MU-MIMO runs on MU-capable clients with traffic flows and PHY channels compatible for multiuser transmissions. Client Match steers and aligns MU-MIMO-capable clients with MU-MIMO-capable radios using SNR values. Multiple MU-MIMO-capable clients can be grouped together on a MU-MIMO-capable radio.
Successful MU-MIMO transmissions depend on the following:
458 | Adaptive Radio Management ArubaOS 6.5.3.x | User Guide
n n
Traffic streams that can be multiplexed for MIMO transmissions. This is dependent on packet length and traffic flow rates (packet arrival rates) from APs to the devices.
MU-MIMO-capable clients associated to the same radio, whose PHY channel matrices are compatible for simultaneous multi-user transmissions
In an 802.11ac AP deployment, clients indicate VHT capabilities for probe requests and association requests, including MU-MIMO support. The APs and controllers use this information to determine whether the client is
MU-MIMO-capable.
After the MU-MIMO-capable clients are located, they are steered to an appropriate MU-MIMO-capable radio.
MU-MIMO Steering ensures that steers are compatible with existing trigger thresholds, such as sticky clients and load-balancing. The multi-user SNR threshold of the target radio must be greater than the sticky client SNR threshold, and radios that exceed the client threshold are avoided to prevent the need for load-balancing.
Removing VBR Dependency on Probe Requests
Client Match has shifted its dependency on probe requests to the AM data feed for virtual beacon report (VBR) data. Instead of relying solely on client background scans during probe requests, which can cause limitations due to low scanning frequency, Client Match uses AM data feeds to gain more continuous, comprehensive client RSSI feeds. Along with probe requests, AM data feeds collect client information during AP scanning using the following frames: n n n n n
Block ACK
Management frames
NULL data frames
Data frames with rates no higher than 36Mbps
Control frames
ARM Coverage and Interference Metrics
ARM computes coverage and interference metrics for each valid channel, and chooses the best performing channel and transmit power settings for each AP’s RF environment. Each AP gathers other metrics on their
ARM-assigned channel to provide a snapshot of the current RF health state.
The following two metrics help the AP decide which channel and transmit power setting is best.
n n
Coverage Index: The AP uses this metric to measure RF coverage. The coverage index is calculated as x/y, where “x” is the AP’s weighted calculation of the Signal-to-Noise Ratio (SNR) on all valid APs on a specified
802.11 channel, and “y” is the weighted calculation of the Aruba AP's SNR the neighboring APs see on that channel.
To view these values for an AP in your current WLAN environment, issue the CLI command show ap arm rf-summary ap-name <ap-name> , where <ap-name> is the name of an AP for which you want to view information.
Interference Index: The AP uses this metric to measure co-channel and adjacent channel interference. The
Interference Index is calculated as a/b//c/d, where: n n
Metric value “a” is the channel interference the AP sees on its selected channel.
Metric value “b” is the interference the AP sees on the adjacent channel.
n n
Metric value “c” is the channel interference the AP’s neighbors see on the selected channel.
Metric value “d” is the interference the AP’s neighbors see on the adjacent channel.
To manually calculate the total Interference Index for a channel, issue the CLI command show ap arm rfsummary ap-name <ap-name> , then add the values a+b+c+d.
ArubaOS 6.5.3.x
| User Guide Adaptive Radio Management | 459
Each AP also gathers the following additional metrics, which can provide a snapshot of the current RF health state. View these values for each AP using the CLI command show ap arm rf-summary ip-addr <ap ip address> .
n n n n n n n n
Amount of Retry frames (measured in %)
Amount of Low-speed frames (measured in %)
Amount of Non-unicast frames (measured in %)
Amount of Fragmented frames (measured in %)
Amount of Bandwidth seen on the channel (measured in kbps)
Amount of PHY errors seen on the channel (measured in %)
Amount of MAC errors seen on the channel (measured in %)
Noise floor value for the specified AP
Starting from ArubaOS 6.5, the following enhancements have been made to resolve issues that occur with the distributed channel/power algorithm: n n
Push random channel assignments to APs: To support the random channel assignment feature, set
Assignment parameter in the ARM profile to maintain . Once this is done, random channels are pushed from the local controller STM/SAPM to APs that belong to a specific ap-group. This helps in replacing the dynamic channel change solution in a high density environment, there by overcoming the issue with convergence. Random channel assignment helps in certain customer deployments where administrators want to control channels assigned and also for initial channel assignment to seed ARM channel computation.
Reduce interference channel change: To reduce the number of interference channel changes and to configure the weight of interfering APs when calculating the interference index, the interfering-ap-weight parameter has been introduced in the rf-arm-profile command. Before this enhancement was introduced, the value of the interfering AP (uncontrollable AP) was similar to the valid AP (controllable AP).
Configuring ARM Profiles
ARM profile settings are divided into two categories: Basic and Advanced.
The Basic ARM settings include
ARM scanning checkbox and general configuration parameters such as channel and power assignments and minimum and maximum allowed EIRP values. Most network environments do not require any changes to the advanced ARM configuration settings. If, however, your network supports a large amount of VoIP or Video traffic, or if you have unusually high security requirements you may want to manually adjust the basic ARM thresholds.
Default Profiles
ArubaOS 6.4.4.0 and later releases include two default ARM profiles, default-a for 5 Ghz radios, and default-g for 2.4 GHz radios. Previous 6.4.x releases support a single default ARM profile applicable to both radio bands.
When you upgrade to ArubaOS 6.4.4.0 or later from a pre-6.4.4.0 release, any changes made to the default
ARM profile will be applied to the new default-a and default-g profiles. If the default profile was not modified, that profile will be removed after the upgrade, when the default-a and default-g profiles are created. Note that any user-created profiles will not be modified during the upgrade, and will retain all their existing values.
Creating and Configuring an ARM Profile
There are two ways to create a new ARM profile. You can create an entirely new profile with all default settings using the WebUI or CLI interfaces, or you can make a copy of an existing profile using the CLI interface.
460 | Adaptive Radio Management ArubaOS 6.5.3.x | User Guide
In the WebUI
To create a new ARM profile with via the WebUI:
1. Select Configuration > Advanced Services > All Profiles . The All Profile Management window opens.
2. Select RF Management to expand the RF Management section.
3. Select Adaptive Radio Management (ARM) Profile . Any currently defined ARM profiles appears in the right pane of the window. If you have not yet created any ARM profiles, this pane displays the default profile only.
4. To create a new profile with all default settings, enter a name in the entry blank. The name must be 1–63 characters, and can be composed of alphanumeric characters, special characters, and spaces. If your profile name includes a space, it must be enclosed within quotation marks.
5. Click Add . The new profile appears in the ARM profile list.
6. Select the name of that profile to display the current configuration settings of that profile.
Table 108: ARM Profile Configuration Parameters
Setting Description
Basic Configuration Settings
Assignment
Allowed bands for
40MHz channels
80MHz support
Activates one of the four ARM channel/power assignment modes.
n disable : Disables ARM calibration and reverts
APs back to default channel and power settings specified by the AP’s radio profile.
n n n maintain : APs maintain their current channel and power settings. This setting is used to maintain AP channel and power levels after ARM has initially selected the best settings.
multi-band : For single-radio APs, this value computes ARM assignments for both 5 GHZ
(802.11a) and 2.4 GHZ (802.11b/g) frequency bands.
single-band : For dual-radio APs, this value enables APs to change transmit power and channels within their same frequency band, and to adapt to changing channel conditions.
The specified setting allows ARM to determine if 40
MHz mode of operation is allowed on the 5 GHz or
2.4 GHz frequency band only, on both frequency bands, or on neither frequency band.
If enabled, this feature allows ARM to assign 80 MHz channels on APs that support VHT. This setting is enabled by default.
Defaults single-band a-only enabled
ArubaOS 6.5.3.x
| User Guide Adaptive Radio Management | 461
Table 108: ARM Profile Configuration Parameters
Setting
160MHz-support
Description
Max Tx EIRP
Min Tx EIRP
The specified setting allows ARM to determine the channel bandwidth on the 160 MHz frequency. The available channel bandwidth modes are: n n n n
Auto : Assigns 160 MHz channel bandwidth. The selection of channel bandwidth is automatic; this can either be contiguous or non-contiguous.
Contiguous-only : Assigns contiguous 160 MHz channel bandwidth.
Non-contiguous-only : Assigns non-contiguous
160 MHz channel bandwidth.
None : Do not assign 160 MHz channel bandwidth. This is the default value.
Maximum effective isotropic radiated power (EIRP) from 3 to 33 dBm in 3 dBm increments. You may also specify a special value of 127 dBm for regulatory maximum. Higher power level settings may be constrained by local regulatory requirements and AP capabilities. In the event that an AP is configured for a Max Tx EIRP setting it cannot support, this value will be reduced to the highest supported power setting.
NOTE: Power settings will not change if the
Assignment option is set to disabled or maintain .
Minimum effective isotropic radiated power (EIRP) from 3 to 33 dBm in 3 dBm increments. You may also specify a special value of 127 dBm for regulatory maximum to disable power adjustments for environments such as outdoor mesh links. Note that power settings will not change if the
Assignment option is set to disabled or maintain .
Higher power level settings may be constrained by local regulatory requirements and AP capabilities. In the event that an AP is configured for a Min Tx EIRP setting it cannot support, this value will be reduced to the highest supported power setting.
Consider configuring a Min Tx Power setting higher than the default value if most of your APs are placed on the ceiling. APs on a ceiling often have good line of sight between them, which will cause ARM to decrease their power to prevent interference.
However, if the wireless clients down on the floor do not have such a clear line back to the AP, you could end up with coverage gaps.
Defaults
None
In 6.4.4.0 and later releases: n n default-a: 18 dBm default-g: 9 dBm
In earlier 6.4.x
releases: n default: 127dBm
In 6.4.4.0 and later releases: n n default-a: 12 dBm default-g: 6 dBm
In earlier 6.4.x
releases: n default: 9dBm
462 | Adaptive Radio Management ArubaOS 6.5.3.x | User Guide
Table 108: ARM Profile Configuration Parameters
Setting
Client Match
Description
Scanning
Multi Band Scan
VoIP Aware Scan
Power Save Aware
Scan
Video Aware Scan
The client match feature helps optimize network resources by balancing clients across channels, regardless of whether the AP or the controller is responding to the wireless clients' probe requests.
If enabled, the controller compares whether an AP has more clients than its neighboring APs on other channels. If an AP’s client load is at or over a predetermined threshold as compared to its immediate neighbors, or if a neighboring Aruba AP on another channel does not have any clients, load balancing will be enabled on that AP. This feature is enabled by default. For details, see
.
The Scanning checkbox enables or disables AP scanning across multiple channels. This checkbox is selected by default. Do not disable scanning unless you want to disable ARM and manually configure AP channel and transmission power. Disabling this option also disables the following scanning features: n n
Multi Band Scan
Rogue AP Aware n n
Voip Aware Scan
Power Save Scan
If enabled, single radio channel APs scans for rogue
APs across multiple channels. This option requires that Scanning is also enabled.
(The Multi Band Scan option does not apply to APs that have two radios, as these devices already scan across multiple channels. If one of these dual-radio devices are assigned an ARM profile with Multi Band enabled, that device will ignore this setting.)
Aruba’s VoIP Call Admission Control (CAC) prevents any single AP from becoming congested with voice calls. When you enable CAC, you should also enable
VoIP Aware Scan in the ARM profile, so the AP will not attempt to scan a different channel if one of its clients has an active VoIP call. This option requires that Scanning is also enabled.
If enabled, the AP will not scan a different channel if it has one or more clients that is in power save mode.
As long as there is at least one video frame every
100 mSec the AP will reject an ARM scanning request. Note that for each radio interface, video frames must be defined in one of two ways: n Classify the frame as video traffic via a session
ACL.
n Enable WMM on the WLAN’s SSID profile and define a specific DSCP value as a video stream.
Next, create a session ACL to tag the video traffic with the that DSCP value.
Defaults
Enabled
Enabled
Enabled
Enabled
Disabled
Enabled
ArubaOS 6.5.3.x
| User Guide Adaptive Radio Management | 463
Table 108: ARM Profile Configuration Parameters
Setting Description
Scan Mode
Client Match Select this checkbox to enable the client match feature, which monitors clients' RF neighborhood to provide ongoing client bandsteering and load balancing, and enhanced AP reassignment for roaming mobile clients. For complete information on this feature, see
.
Advanced Configuration Settings
Assignment
By default, 802.11n-capable APs scan channels within all regulatory domains. To limit the AP scans to just the regulatory domain for that AP, click the
Scan Mode drop-down list and select reg-domain .
NOTE: This setting does not apply to APs that do not support 802.11n; these APs will scan their regulatory domain only.
Allowed bands for
40MHz channels
Client Aware
Activates one of the four ARM channel/power assignment modes: n disable : Disables ARM calibration and reverts
APs back to default channel and power settings specified by the AP’s radio profile.
n n n maintain : APs maintain their current channel and power settings. This setting is used to maintain AP channel and power levels after ARM has initially selected the best settings.
multi-band : For single-radio APs, this value computes ARM assignments for both 5 GHZ
(802.11a) and 2.4 GHZ (802.11b/g) frequency bands.
single-band : For dual-radio APs, this value enables APs to change transmit power and channels within their same frequency band, and to adapt to changing channel conditions.
The specified setting allows ARM to determine if 40
MHz mode of operation is allowed on the 5 GHz or
2.4 GHz frequency band only, on both frequency bands, or on neither frequency band.
If the Client Aware option is enabled, the AP does not change channels if there is an active client associated to that AP. (Activity is defined by the stainactivity-time parameter in the IDS general profile. By default, a client is considered active if it has sent or received traffic within the last 60 seconds.)
If you disable Client Aware , the AP may change to a more optimal channel, but this change may also disrupt current client traffic.
Defaults all-reg-domain
Enabled
Single-band a-only
Enabled
464 | Adaptive Radio Management ArubaOS 6.5.3.x | User Guide
Table 108: ARM Profile Configuration Parameters
Setting
Max Tx EIRP
Description
Min Tx EIRP
Rogue AP Aware
Defaults
Maximum effective isotropic radiated power (EIRP) from 3 to 33 dBm in 3 dBm increments. You may also specify a special value of 127 dBm for regulatory maximum. Higher power level settings may be constrained by local regulatory requirements and AP capabilities. In the event that an AP is configured for a Max Tx EIRP setting it cannot support, this value will be reduced to the highest supported power setting.
NOTE: Power settings will not change if the
Assignment option is set to disabled or maintain .
Minimum effective isotropic radiated power (EIRP) from 3 to 33 dBm in 3 dBm increments. You may also specify a special value of 127 dBm for regulatory maximum to disable power adjustments for environments such as outdoor mesh links. Note that power settings will not change if the
Assignment option is set to disabled or maintain .
Higher power level settings may be constrained by local regulatory requirements and AP capabilities. In the event that an AP is configured for a Min Tx EIRP setting it cannot support, this value will be reduced to the highest supported power setting.
Default: 9 dBm
NOTE: Consider configuring a Min Tx Power setting higher than the default value if most of your APs are on the ceiling. APs on a ceiling often have good line of sight between them, which will cause ARM to decrease their power to prevent interference.
However, if the wireless clients down on the floor do not have such a clear line back to the AP, you could end up with coverage gaps.
In 6.4.4.0 and later releases: n n default-a: 18 dBm default-g: 9 dBm
In earlier 6.4.x
releases: n default: 127dBm
In 6.4.4.0 and later releases: n n n default-a: 12 dBm default-g: 6 dBm
In earlier 6.4.x
releases: default: 9dBm
If you have enabled both the Scanning and Rogue
AP options , Aruba APs may change channels to contain off-channel rogue APs with active clients.
This security features allows APs to change channels even if the Client Aware setting is disabled.
This setting is disabled by default, and should only be enabled in high-security environments where security requirements are allowed to consume higher levels of network resources. You may prefer to receive Rogue AP alerts via SNMP traps or syslog events.
Disabled
ArubaOS 6.5.3.x
| User Guide Adaptive Radio Management | 465
Table 108: ARM Profile Configuration Parameters
Setting
Scan Interval
Description
Active Scan
ARM Over the Air
Updates
Scanning
Multi Band Scan
Defaults
If Scanning is enabled, the Scan Interval defines how often the AP will leave its current channel to scan other channels in the band.
Off-channel scanning can impact client performance.
Typically, the shorter the scan interval, the higher the impact on performance. If you are deploying a large number of new APs on the network, you may want to lower the Scan Interval to help those APs find their optimal settings more quickly. Raise the Scan
Interval back to its default setting after the APs are functioning as desired.
Range: 0–2,147,483,647 seconds.
10 seconds
When you enable Active Scan , an AP initiates active scanning via probe request. This option elicits more information from nearby APs, but also creates additional management traffic on the network.
Active Scan is disabled by default, and should not be enabled except under the direct supervision of Aruba
Support.
Disabled
The ARM Over the Air Updates option allows an AP to get information about its RF environment from its neighbors, even the AP cannot scan. If this feature is enabled, when an AP on the network scans a foreign
(non-home) channel, it sends other APs an Over-the-
Air (OTA) update in an 802.11 management frame that contains information about the scanning AP's home channel, the current transmission EIRP value of its home channel, and one-hop neighbors seen by that AP.
Default: enabled
Enabled
Enabled The Scanning checkbox enables or disables AP scanning across multiple channels. Disabling this option also disables the following scanning features: n n n n
Multi Band Scan
Rogue AP Aware
Voip Aware Scan
Power Save Scan
Do not disable Scanning unless you want to disable
ARM and manually configure AP channel and transmission power.
If enabled, single radio channel APs scans for rogue
APs across multiple channels. This option requires that Scanning is also enabled.
(The Multi Band Scan option does not apply to APs that have two radios, as these devices already scan across multiple channels. If one of these dual-radio devices are assigned an ARM profile with Multi Band enabled, that device will ignore this setting.)
Disabled
466 | Adaptive Radio Management ArubaOS 6.5.3.x | User Guide
Table 108: ARM Profile Configuration Parameters
Setting
VoIP Aware Scan
Description
Power Save Aware
Scan
Video Aware Scan
Ideal Coverage Index
Acceptable Coverage
Index
Free Channel Index
Aruba’s VoIP Call Admission Control (CAC) prevents any single AP from becoming congested with voice calls. When you enable CAC, you should also enable
VoIP Aware Scan in the ARM profile, so the AP will not attempt to scan a different channel if one of its clients has an active VoIP call. This option requires that Scanning is also enabled.
If enabled, the AP will not scan a different channel if it has one or more clients that is in power save mode.
As long as there is at least one video frame every
100 mSec the AP will reject an ARM scanning request. Note that for each radio interface, video frames must be defined in one of two ways: n Classify the frame as video traffic via a session
ACL.
n Enable WMM on the WLAN’s SSID profile and define a specific DSCP value as a video stream.
Next, create a session ACL to tag the video traffic with the that DSCP value.
The Aruba coverage index metric is a weighted calculation based on the RF coverage for all Aruba
APs and neighboring APs on a specified channel. The
Ideal Coverage Index specifies the ideal coverage that an AP should try to achieve on its channel. The denser the AP deployment, the lower this value should be.
Range: 2–20
For additional information on how this the Coverage
Index is calculated, see
Interference Metrics on page 459
For multi-band implementations, the Acceptable
Coverage Index specifies the minimal coverage an
AP it should achieve on its channel. The denser the
AP deployment, the lower this value should be.
Range: 1–6
The Aruba Interference index metric measures interference for a specified channel and its surrounding channels. This value is calculated and weighted for all APs on those channels (including
3rd-party APs).
An AP will only move to a new channel if the new channel has a lower interference index value than the current channel.
Free Channel Index specifies the required difference between the two interference index values before the AP moves to the new channel. The lower this value, the more likely it is that the AP will move to the new channel.
The range of possible values is 10–40.
For additional information on how this the Channel
Index is calculated, see
Interference Metrics on page 459 .
Defaults
Disabled
Disabled
Enabled
In 6.4.4.0 and later releases: n n default-a: 6 default-g: 6
In earlier 6.4.x
releases: n default:10
4
In 6.4.4.0 and later releases: n default-a: 40 n default-g: 25
In earlier 6.4.x
releases: n default: 25
ArubaOS 6.5.3.x
| User Guide Adaptive Radio Management | 467
Table 108: ARM Profile Configuration Parameters
Setting
Backoff Time
Description
Error Rate Threshold
After an AP changes channel or power settings, it waits for the backoff time interval before it asks for a new channel/power setting.
Range: 120–3600 seconds.
The minimum percentage of PHY errors and MAC errors in the channel that will trigger a channel change.
Defaults
240 sec
Error Rate Wait Time Minimum time in seconds the error rate has to exceed the Error Rate Threshold before it triggers a channel change.
Channel Quality Aware
Arm
Enable this feature to base ARM changes upon an internally calculated channel quality metric. When this feature is disabled, ARM initiates channel changes based on thresholds defined in this profile, and chooses the channel based on the calculated interference index value. Default: Disabled
Channel Quality
Threshold
Channel Quality Wait
Time
Minimum Scan Time
Channel quality percentage below which ARM initiates a channel change.
Range: 0-100%
If channel quality is below the specified channel quality threshold for this wait time period, ARM initiates a channel change.
Range:1-3600 seconds
Minimum number of times a channel must be scanned before it is considered for assignment.
Range: 0–2,147,483,647 scans. It is recommended to use a Minimum Scan Time between 1–20 scans.
Load Aware Scan
Threshold
Load aware ARM preserves network resources during periods of high traffic by temporarily halting
ARM scanning if the load for the AP gets too high.
The Load Aware Scan Threshold is the traffic throughput level an AP must reach before it stops scanning.
Range: 0–20,000,000 bytes/second. (Specify 0 to disable this feature.)
In 6.4.4.0 and later releases: n n default-a: 70% default-g: 70%
In earlier 6.4.x
releases: n default: 50%
In 6.4.4.0 and later releases: n n default-a: 90 sec default-g: 90 sec
In earlier 6.4.x
releases: n default: 30 sec
Disabled
70%
120 seconds
8 scans
1250000 Bps
468 | Adaptive Radio Management ArubaOS 6.5.3.x | User Guide
Table 108: ARM Profile Configuration Parameters
Setting
Mode Aware ARM
Description
Scan Mode
Video Aware Scan
If enabled, ARM will turn APs into Air Monitors (AMs) if it detects higher coverage levels than necessary.
This helps avoid higher levels of interference on the
WLAN. Although this setting is disabled by default, you may want to enable this feature if your APs are deployed in close proximity (less than 60 feet apart).
Mode aware ARM turns Air Monitors back into APs when they detect gaps in coverage. Note that an Air
Monitor will not turn back into an AP if it detects client traffic (or client traffic increases), but will change to an AP only if it detects coverage holes.
By default, 802.11n-capable APs scan channels within all regulatory domains. To limit the AP scans to just the regulatory domain for that AP, click the
Scan Mode drop-down list and select reg-domain.
NOTE: This setting does not apply to APs that do not support 802.11n; these APs will scan their regulatory domain only.
As long as there is at least one video frame every
100 mSec the AP will reject an ARM scanning request. Note that for each radio interface, video frames must be defined in one of two ways: n n
Classify the frame as video traffic via a session
ACL.
Enable WMM on the WLAN’s SSID profile and define a specific DSCP value as a video stream.
Next, create a session ACL to tag the video traffic with the that DSCP value.
Defaults
Disabled al-reg-domain
Enabled
In the CLI
You must be in config mode to create, modify or delete an ARM profile using the CLI. Specify an existing ARM profile with the <profile-name> parameter to modify an existing ARM profile, or enter a new name to create an entirely new profile.
To create a new ARM profile or modify an existing profile via the command-line interface, access the CLI in config mode and issue the following command:
(host)(config) #rf arm-profile <profile>
The name must be 1–63 characters, and can be composed of alphanumeric characters, special characters and spaces. If your profile name includes a space, it must be enclosed within quotation marks.
Configuration details and any default values for each of these parameters are described in
. If you do not specify a parameter for a new profile, that profile uses the default value for that parameter. Put the no option before any parameter to remove the current value for that parameter and return it to its default setting.
The ARM profile includes advanced client match settings that can be configured through the command-line interface only. The default values for these settings are recommended for most users, and caution should be used when changing them to a non-default value. For complete details on all client match configuration settings, refer to the
ArubaOS CLI Reference Guide .
ArubaOS 6.5.3.x
| User Guide Adaptive Radio Management | 469
Assigning an ARM Profile to an AP Group
Once you have created a new ARM profile, you must assign it to a group of APs before those ARM settings go into effect. Each AP group has a separate set of configuration settings for its 802.11a radio profile and its
802.11g radio profile. You can assign the same ARM profile to each radio profile, or select different ARM profiles for each radio.
In the WebUI
To assign an ARM profile to an AP group via the Web User Interface:
1. Select Configuration > Wireless > AP Configuration.
2. Click the AP Group tab if it is not already selected.
3. Click the Edit button beside the AP group to which you want to assign the new ARM profile.
4. Expand the RF Management section in the left window pane.
5. Select a radio profile for the new ARM profile.
l l
To assign a new ARM profile to an AP group’s 802.11a radio profile, expand the 802.11a radio profile section.
To assign a new ARM profile to an AP group’s 802.11g radio profile, expand the 802.11g radio profile section.
6. Select Adaptive Radio management (ARM) Profile .
7. Click the Adaptive Radio Management (ARM) Profile drop-down list in the right window pane, and select a new ARM profile.
8. (Optional) repeat steps 6–8 to assign an ARM profile to another 802.11a or 802.11g radio profile.
9. Click Apply .
You can also assign an ARM profile to an AP group by selecting a radio profile, identifying an AP group assigned to that radio profile, and then assigning an ARM profile to one of those groups.
1. Select Configuration > Advanced Services> All Profiles .
2. Select RF Management , and then expand either the 802.11a radio profile or 802.11b radio profile .
3. Select an individual radio profile name to expand that profile.
4. Click Adaptive Radio Management (ARM) Profile , and then use the Adaptive Radio management
(ARM) Profile drop-down list in the right window pane to select a new ARM profile for that radio.
In the CLI
To assign an ARM profile to an AP group via the command-line interface, access the CLI in config mode and issue the following commands where <ap_profile> is the name of the AP group, and <arm_profile> is the name of the ARM profile you want to assign to that radio band.:
(host)(config) #rf dot11a-radio-profile <ap_profile> arm-profile <arm_profile>
(host)(config) #rf dot11g-radio-profile <ap_profile> arm-profile <arm_profile>
Using Multi-Band ARM for 802.11a/802.11g Traffic
It is recommended that you use the multi-band ARM assignment and Mode Aware ARM feature for singleradio APs in networks with traffic in the 802.11a and 802.11g bands. This feature allows a single-radio AP to dynamically change its radio bands based on current coverage on the configured band. This feature is enabled via the AP's ARM profile.
When you first provision a single-radio AP, it initially operates in the radio band specified in its AP system profile. If the AP finds adequate coverage on multiple channels in its current band of operation, the mode-
470 | Adaptive Radio Management ArubaOS 6.5.3.x | User Guide
aware feature allows the AP to temporarily turn itself off and become an AP Air Monitor (APM). In AP Monitor mode, the AP scans all channels across both bands to verify that each channel meets or exceeds its required level of acceptable radio coverage (as defined by the in the ARM profile).
If the AP Monitor detects that a channel on the 802.11g band does not have adequate radio coverage, it will convert back to an AP on that 802.11 channel. If the 802.11g band is adequately covered, the AP Monitor will next check the 802.11a band. If a channel on the 802.11a band lacks coverage, the AP Monitor will convert back to an AP on that 802.11a channel.
Band Steering
ARM’s band steering feature encourages dual-band capable clients to stay on the 5GHz band on dual-band APs, freeing up resources on the 2.4GHz band for single-band clients like VoIP phones. Band steering reduces cochannel interference and increases available bandwidth for dual-band clients, because there are more channels on the 5GHz band than on the 2.4GHz band. Dual-band 802.11n-capable clients may see even greater bandwidth improvements, because the band steering feature will automatically select between 40MHz or
20MHz channels in 802.11n networks. This feature is disabled by default, and must be enabled in a Virtual AP profile.
The band steering feature considers several metrics before it determines if a client should be steered to the
5GHz band, including client RSSI. For example, this feature will only steer a client to the 5GHz band if that client detects an acceptable RSSI value from an 5GHz AP radio, and the signal from the 5Ghz radio is not significantly weaker than the RSSI from the 2.4GHz radio.
This feature also takes into account the current load on each radio of a dual-band AP. The band steering feature will not steer more clients to 5G on that AP if there are many clients associated to the AP, and significantly more 802.11a clients than 80211g clients.
The band steering feature supports both campus APs and remote APs that have a virtual AP profile set to tunnel, split-tunnel, or bridge forwarding mode. Note, however, that if a campus or remote AP has virtual AP profiles configured in bridge or split-tunnel forwarding mode but no virtual AP in tunnel mode , those APs will gather information about 5G-capable clients independently and will not exchange this information with other
APs that also have bridge or split-tunnel virtual APs only. The band steering feature will not proactively disconnect clients that are already associated with a radio. All band steering occurs when a client is trying to associate to a new AP radio.
Best practices are to use either the Band Steering or the Client Match feature to balance client loads, but not both at the same time.
Steering Modes
Band steering supports the following three different band steering modes: n n
Prefer-5GHz (Default) : If you configure the AP to use prefer-5GHz band steering mode, the AP will not respond to 2.4 Ghz probe requests from a client if all the following conditions are met.
l l
The client has already probed the AP on the 5Ghz band and therefore is known to be capable of sending probes on the 5Ghz band.
The client is not currently associated on the 2.4Ghz radio to this AP.
l
The client has sent fewer than 8 probes in the last 10 seconds. If the client has sent more than 8 probes in the last 10 seconds, the client will be able to connect using whatever band it prefers
Force-5GHz: When the AP is configured in force-5GHz band steering mode, the AP will not respond to 2.4
Ghz probe requests from a client if all the following conditions are met.
l
The client has already probed the AP on the 5Ghz band and therefore is known to be capable of sending probes on the 5Ghz band.
ArubaOS 6.5.3.x
| User Guide Adaptive Radio Management | 471
n l
The client is not currently associated on the 2.4Ghz radio of this AP.
Balance-bands: In this band steering mode, the AP uses client load and RSSI information balance the clients across the two radios and best use the available 2.4G bandwidth. This feature takes into account the fact that the 5Ghz band has more channels than the 2.4 Ghz band, and that the 5Ghz channels operate in
40MHz while the 2.4Ghz band operates in 20MHz.
Enabling Band Steering
Band steering is configured in a virtual AP profile. Use the following procedures to enable or disable Band
Steering using the WebUI or command-line interfaces.
In the WebUI
1. Select Configuration > Advanced Services > All Profiles.
The All Profile Management window opens.
2. Select Wireless LAN to expand the Wireless LAN section.
3. Select Virtual AP profile to expand the Virtual AP Profile section.
4. Select the name of the Virtual AP profile for which you want to enable band steering.
(To create a new virtual AP profile, enter a name for a new profile in the Profile Details window, then click
Add . The new profile will appear in the Profiles list. Select that profile to open the Profile Details pane.)
5. In the Profile Details pane, select Band Steering to enable this feature, or uncheck the Band Steering checkbox to disable this feature.
6. Once band steering is enabled, click the steering mode drop-down list and select the desired steering mode.
7. Click Apply.
In the CLI
Use the following commands to enable band steering via the command-line interface.
(host)(config) #wlan virtual-ap <profile> band-steering
(host)(config) #wlan virtual-ap <profile> steering-mode
Dynamic Bandwidth Switch
ARM’s dynamic bandwidth switch feature provides capability for ARM to detect the 20MHz interferer by reading the Clear Channel Assessment (CCA) statistics and other radio statistics. Once the signatures are detected, ARM moves to another 80MHz channel or downgrade to 40MHz. This feature only works when dynamic-bw parameter is enabled and ARM is set to use 80MHz assignment.
Traditionally, when the bandwidth is configured, the operating channel bandwidth is fixed and is not changed.
If ARM decides to downgrade the bandwidth to 40MHz, then it will upgrade back to 80MHz after the clear time based on the volume of the traffic.
Enabling Dynamic Bandwidth Switch
Use the following procedures to enable or disable dynamic bandwidth switch using command-line interfaces.
In the CLI
Use the following commands to enable and set dynamic bandwidth switch:
(host) (config) #rf arm-profile default
(host) (Adaptive Radio Management (ARM) profile "default") #dynamic-bw
(host) (Adaptive Radio Management (ARM) profile "default") #dynamic-bw-beacon-failed-thresh
472 | Adaptive Radio Management ArubaOS 6.5.3.x | User Guide
(host) (Adaptive Radio Management (ARM) profile "default") #dynamic-bw-cca-ibss-thresh
(host) (Adaptive Radio Management (ARM) profile "default") #dynamic-bw-cca-intf-thresh
(host) (Adaptive Radio Management (ARM) profile "default") #dynamic-bw-clear-time
(host) (Adaptive Radio Management (ARM) profile "default") #dynamic-bw-wait-time
Enabling Traffic Shaping
In a mixed-client network, it is possible for slower clients to bring down the performance of the whole network.
To solve this problem and ensure fair access to all clients independent of their WLAN or IP stack capabilities, an
AP can implement the traffic shaping feature. This feature has the following three options: n n n default-access: Traffic shaping is disabled, and client performance is dependent on MAC contention resolution. This is the default traffic shaping setting.
fair-access: Each client gets the same airtime, regardless of client capability and capacity. This option is useful in environments like a training facility or exam hall, where a mix of 802.11a/g, 802.11g and 802.11n
clients need equal to network resources, regardless of their capabilities.
preferred-access: High-throughput (802.11n) clients do not get penalized because of slower 802.11a/g or
802.11b transmissions that take more air time due to lower rates. Similarly, faster 802.11a/g clients get more access than 802.11b clients.
With this feature, an AP keeps track of all BSSIDs active on a radio, all clients connected to the BSSID, and
802.11a/g, 802.11b, or 802.11n capabilities of each client. Every sampling period, airtime is allocated to each client, giving it opportunity to get and receive traffic. The specific amount of airtime given to an individual client is determined by the following factors: n n n n
Client capabilities (802.11a/g, 802.11b or 802.11n).
Amount of time the client spent receiving data during the last sampling period.
Number of active clients in the last sampling period.
Activity of the current client in the last sampling period.
The bw-alloc parameter of a traffic management profile allows you to set a minimum bandwidth to be allocated to a virtual AP profile when there is congestion on the wireless network. You must set traffic shaping to fair-access to use this bandwidth allocation value for an individual virtual AP.
Enabling Traffic Shaping
Traffic shaping is configured in an traffic management profile.
In the WebUI
To configure traffic shaping via the WebUI:
1. Select Configuration > Advanced Services > All Profiles . The All Profile Management window opens.
2. Select QoS to expand the QoS section.
3. Select Traffic management profile .
4. In the Profiles Details window, select the name of the traffic management profile for which you want to configure traffic shaping. (If you do not have any traffic management profiles configured, enter a name for a new profile in the Profile Details pane, click Add , then select the new profile from the profiles list.)
5. In the Profile Details pane, click the Station Shaping Policy drop-down list and select either defaultaccess , fair-access or preferred-access .
6. Click Apply .
The following table describes configuration settings available in the traffic management profile.
ArubaOS 6.5.3.x
| User Guide Adaptive Radio Management | 473
Table 109: Traffic Management Profile Parameters
Parameter Description
Station Shaping
Policy
Define Station Shaping Policy This feature has the following three options: n default-access: Traffic shaping is disabled, and client performance is dependent on
MAC contention resolution. This is the default traffic shaping setting.
n n fair-access: Each client gets the same airtime, regardless of client capability and capacity. This option is useful in environments like a training facility or exam hall, where a mix of 802.11a/g, 802.11g, and 802.11n clients need equal to network resources, regardless of their capabilities. The bw-alloc parameter of a traffic management profile allows you to set a minimum bandwidth to be allocated to a virtual AP profile when there is congestion on the wireless network. You must set traffic shaping to fair-access to use this bandwidth allocation value for an individual virtual AP.
preferred-access: High-throughput (802.11n) clients do not get penalized because of slower 802.11a/g or 802.11b transmissions that take more air time due to lower rates. Similarly, faster 802.11a/g clients get more access than 802.11b clients.
Proportional BW
Allocation
You can allocate a maximum bandwidth, as a percentage of available bandwidth to a virtual AP (VAP).
To assign a percentage of bandwidth to a virtual AP:
1. Click the Virtual AP drop-down list, and select the VAP to which you would like to allocate a bandwidth share.
2. Specify the percentage of bandwidth to be allocated to the VAP in the Share(%) field.
3. Select the Hard Limit checkbox to restrict the bandwidth for the VAP. Do not select the Hard Limit checkbox if you want to restrict the bandwidth for this VAP when there is a congestion on the wireless network.
4. Click Add .
5. Repeat steps 1-4 to assign any remaining bandwidth to additional VAPs, if desired.
To remove a VAP from the list of VAPs with allocated bandwidth, select the VAP from the
Proportional BW Allocation field and click Delete .
Report Interval Number of minutes between bandwidth usage reports.
Range: 1-99 minutes
Default value is 5 minutes.
In the CLI
To enable and configure traffic shaping via the command-line interface, access the CLI in config mode and issue the following commands: wlan traffic-management-profile <profile> shaping-policy default-access|fair-access|preferredaccess
Use the following commands to apply an 802.11a or 802.11g traffic management profile to an AP group or an individual AP.
ap-group <name> dot11a-traffic-mgmt-profile|dot11g-traffic-mgmt-profile <profile>
Enabling or Disabling the Hard Limit Parameter in Traffic Management Profile
You can configure the limit on OTA bandwidth for a virtual AP by enabling or disabling the hard-limit parameter in the Traffic management profile.
Using the WebUI
The following procedure configures the Hard Limit parameter in Traffic management profile:
1. Navigate to the Configuration > Advanced Services > All Profiles page.
2. Under QOS > Traffic management on the Profiles pane, select the profile name.
474 | Adaptive Radio Management ArubaOS 6.5.3.x | User Guide
3. Under the Advanced tab on the Profile Details pane, select the Proportional BW Allocation parameter and follow the steps given in the
4. Click Apply .
Using the CLI
You can configure the traffic management profile using the following command:
(host)(config) #wlan traffic-management-profile <profile>
Traffic Steering
ARM’s traffic steering feature encourages clients that support both Wi-Fi and 3G/4G cellular connections to move from a Wi-Fi connection to a cellular connection when the device moves out of a Wi-Fi coverage area, or when the Wi-Fi connection supports lower data rates than the cellular connection.
Use this feature in deployments where a single operator provides both Wi-Fi and cellular networks, and the user onboarding and accounting for both network types is managed by a common RADIUS server. This feature is disabled by default, and must be enabled for each SSID via the WLAN SSID profile.
Wi-Fi and 3G/4G-compatible devices are steered to a different connection type based upon data in the ARM
Client Match client reports from the APs on the network. When client match is enabled for an AP, that
AP receives and collects information about the RF health of clients in its neighborhood, and periodically sends this information to the WLAN controller. The WLAN controller reports the corresponding estimated throughput value to the cellular controller using the RADIUS accounting messages. If the cellular controller determines that the device's WLAN connection throughput has fallen below a threshold, the cellular controller tells the WLAN controller to disassociate the device from the network and prevent it from reassociating for a customizable blackout interval.
Configuration Requirements
This feature requires that client match is enabled through the ARM profile for your access points (client match is enabled by default). Although the default client match settings are recommended for most users, advanced client match settings for communication intervals and quality thresholds can be configured using the rf armprofile command in the command-line interface.
Each RADIUS authentication server profile on the WLAN controller includes a called-station-id parameter, which is sent with the RADIUS attribute Called Station ID for authentication and accounting requests. By default, the called-station-id parameter is the controller MAC address. If your deployment uses the traffic steering feature, do not change the called-station-id parameter to any other supported value type (such as an AP group or VLAN ID).
Enabling Traffic Steering
Band steering is configured in a WLAN SSID profile. Use the following procedures to enable or disable traffic steering using the WebUI or command-line interface.
In the WebUI
1. Select Configuration > Advanced Services > All Profiles.
The All Profile Management window opens.
2. Expand the Wireless LAN section.
3. Select SSID to expand the SSID Profile section.
4. Select the name of the Virtual AP profile for which you want to enable band steering.
(To create a new SSID AP profile, enter a name for a new profile in the Profile Details window, then click
Add . The new profile will appear in the Profiles list. Select that profile to open the Profile Details pane.)
ArubaOS 6.5.3.x
| User Guide Adaptive Radio Management | 475
5. Under the Advanced tab of the Profile Details pane, select Traffic steering from WLAN to cellular to enable this feature, or uncheck the Traffic steering from WLAN to cellular check box to disable this feature.
6. Click Apply.
In the CLI
Use the following command to enable traffic steering via the command-line interface:
(host)(config) #wlan ssid <profile> traffic-steering
Spectrum Load Balancing
The spectrum load balancing feature helps optimize network resources by balancing clients across channels, regardless of whether the AP or the controller is responding to the wireless clients' probe requests. The controller uses the ARM neighbor update messages that pass between APs and the controller to determine the distribution of clients connected to each AP's immediate (one-hop) neighbors. This feature also takes into account the number of APs visible to the clients in the RF neighborhood, and can factor the client’s perspective on the network into its coverage calculations.
The controller compares whether an AP has more clients than its neighboring APs on other channels. If an AP’s client load is at or over a predetermined threshold as compared to its immediate neighbors, or if a neighboring
Aruba AP on another channel does not have any clients, load balancing will be enabled on that AP.
When an AP has the spectrum load balancing feature enabled, the AP will send an association response with error code 17 to new clients trying to associate. If the client receiving the error code tries to associate to the AP a second time, it will be admitted. If a client is rejected by two APs in a row, it will be admitted by any AP on its third try. Note that the load balancing feature only affects the association of new clients; this feature does not reject or attempt to balance clients that are already associated to the AP.
Spectrum load balancing is disabled by default, and can be enabled for 2.4G traffic through an 802.11g profile or for 5G traffic through an 802.11a RF management profile. The spectrum load balancing feature also requires that the 802.11a or 802.11g RF management profiles reference an ARM profile with ARM scanning enabled.
The spectrum load balancing feature available in ArubaOS 3.4.x and later releases completely replaces the
AP load balancing feature available earlier versions of ArubaOS. When you upgrade from an older release to
ArubaOS 3.4.x or later, you must manually configure the spectrum load balancing settings, as you can lo longer use the AP load balancing feature, and any previous AP load balancing settings will not be preserved.
For details on modifying 802.11a or 802.11g RF management profiles, refer to
.
Reusing Channels to Control RX Sensitivity Tuning
In some dense deployments, it is possible for APs to hear other APs on the same channel. This creates cochannel interference and reduces the overall usage of the channel in a given area. Channel reuse enables dynamic control over the receive (Rx) sensitivity to improve spatial reuse of the channel.
The channel reuse feature applies to non-DFS channels only. It is internally disabled for DFS channels and is does not affect DFS radar signature detection.
You can configure the channel reuse feature to operate in either of the following three modes; static, dynamic or disable . (This feature is disabled by default.)
476 | Adaptive Radio Management ArubaOS 6.5.3.x | User Guide
n n n
Static mode: This mode of operation is a coverage-based adaptation of the Clear Channel Assessment
(CCA) thresholds. In the static mode of operation, the CCA is adjusted according to the configured transmission power level on the AP, so as the AP transmit power decreases as the CCA threshold increases, and vice versa.
Dynamic mode: In this mode, the Clear Channel Assessment (CCA) thresholds are based on channel loads, and take into account the location of the associated clients. When you set the Channel Reuse feature to dynamic mode, this feature is automatically enabled when the wireless medium around the AP is busy greater than half the time, and the CCA threshold adjusts to accommodate transmissions between the AP its most distant associated client.
Disable mode: This mode does not support the tuning of the CCA Detect Threshold.
The channel reuse mode is configured through an 802.11a or 802.11g RF management profile. For details on modifying 802.11a or 802.11g RF management profiles, refer to
.
Configuring Non-802.11 Noise Interference Immunity
When an AP attempts to decode a non-802.11 signal, that attempt can momentarily interrupt its ability to receive traffic. The noise immunity feature can help improve network performance in environments with a high level of non-802.11 noise from devices such as Bluetooth headsets, video monitors and cordless phones.
You can configure the noise immunity feature for any one of the following levels of noise sensitivity. Note that increasing the level makes the AP slightly “deaf” to its surroundings, causing the AP to lose a small amount of range.
n n n n n n
Level 0: no ANI adaptation.
Level 1: Noise immunity only. This level enables power-based packet detection by controlling the amount of power increase that makes a radio aware that it has received a packet.
Level 2: Noise and spur immunity. This level also controls the detection of OFDM packets, and is the default setting for the Noise Immunity feature.
Level 3: Level 2 settings and weak OFDM immunity. This level minimizes false detects on the radio due to interference, but may also reduce radio sensitivity. This level is recommended for environments with a highlevel of interference related to 2.4Ghz, appliances such as cordless phones.
Level 4: Level 3 settings, and FIR immunity. At this level, the AP adjusts its sensitivity to in-band power, which can improve performance in environments with high, constant levels of noise interference.
Level 5: The AP completely disables PHY error reporting, improving performance by eliminating the time the controller would spend on PHY processing.
Only 802.11n-capable APs simultaneously support both the RX Sensitivity Tuning Based Channel Reuse feature and a level-3 to level-5 Noise Immunity setting. Do not raise the noise immunity default setting on APs that do not support
802.11n unless you first disable the Channel Reuse feature.
You can manage Non-802.11 Noise Immunity settings through the Non 802.11 Interference Immunity parameter in the 802.11a or 802.11g RF management profile. For details on configuring this profile, refer to
Troubleshooting ARM
If the APs on your WLAN do not seem to be operating at an optimal channel or power setting, you should first verify that both the ARM feature and ARM scanning have been enabled. Optimal ARM performance requires that the APs have IP connectivity to their master controller, as it is the master controller that gives each AP the
ArubaOS 6.5.3.x
| User Guide Adaptive Radio Management | 477
global classification information required to keep accurate coverage index values. If ARM is enabled but does not seem to be working properly, try some of the troubleshooting tips below.
Too many APs on the Same Channel
If many APs are selecting the same RF channel, there may be excessive interference on the other valid 802.11
channels. Issue the CLI commands show ap arm rf-summary ap-name <ap-name> or show ap arm rfsummary ip-addr <ap ip address> and calculate the Interference index ( intf_idx ) for all the valid channels.
An AP will only move to a new channel if the new channel has a lower interference index value than the current channel. The ARM Free Channel Index parameter specifies the required difference between two interference index values. If this value is set too high, the AP will not switch channels, even if the interference is slightly lower on another channel. Lower the Free Channel Index to improve the likelihood that the AP will switch to a better channel.
Wireless Clients Report a Low Signal Level
If APs detect strong signals from other APs on the same channel, they may decrease their power levels accordingly. Issue the CLI commands s how ap arm rf-summary ap-name <ap-name> or show ap arm rfsummary ip-addr <ap ip address> .
for all APs and check their current coverage index ( cov-idx ). If the AP’s coverage index is at or higher than the configured coverage index value, then the APs have correctly chosen the transmit power setting. To manually increase the minimum power level for the APs using a specific ARM profile, define a higher minimum value with the command rf arm-profile <profile> min-tx-power <dBm >.
If wireless clients still report that they see low signal levels for the APs, check that the AP’s antennas are correctly connected to the AP and correctly placed according to the manufacturer’s installation guide.
Transmission Power Levels Change Too Often
Frequent changes in transmission power levels can indicate an unstable RF environment, but can also reflect incorrect ARM or AP settings. To slow down the frequency at which the APs change their transmit power, set the ARM backoff time to a higher value. If APs use external antennas, check the Configuration > Wireless >
AP Installation > Provisioning window to make sure the APs are statically configured for the correct dBi gain, antenna type, and antenna number. If only one external antenna is connected to its radio, you must select either antenna number 1 or 2.
APs Detect Errors but Do Not Change Channels
First, ensure that ARM error checking is enabled. The ARM Error Rate Threshold should be set to a percentage higher than zero. The suggested configuration value for the ARM Error Rate Threshold is 30–50%.
APs Don’t Change Channels Due to Channel Noise
APs will only change channels due to interference if you enable ARM noise checking. Check to verify that the
ARM Noise Threshold is set to a value higher than 0 dBm. The suggested setting for this threshold is 75 dBm.
478 | Adaptive Radio Management ArubaOS 6.5.3.x | User Guide
Chapter 21
Wireless Intrusion Prevention
n n n n n n
The ArubaOS Wireless Intrusion Prevention (WIP) features and configurations are discussed in this chapter.
WIP offers a wide selection of intrusion detection and protection features to protect the network against wireless threats. Like most other security-related features of the Aruba network, the WIP configuration is done on the master controller in the network.
To use most of the features described in this chapter, you must install a Wireless Intrusion Protection
(RFprotect) license on all controllers in your network. If you install a RFprotect license on a master controller only, an AP or AM terminated on a local controller will not provide the WIP features.
These features do not require an RFprotect license: n n n n
Rogue AP classification techniques other than AP classification rules
Rogue containment
Wired containment
Wireless containment without Tarpit
For details on commands see the ArubaOS 6.5.3.x Command Line Interface Guide .
This chapter contains the following sections: n n n n n n
Working with the Reusable Wizard on page 479
Monitoring the Dashboard on page 482
Detecting Rogue APs on page 483
Working with Intrusion Detection on page 486
Configuring Intrusion Protection on page 498
Configuring the WLAN Management System on page 502
Understanding Client Blacklisting on page 505
Working with WIP Advanced Features on page 508
Configuring TotalWatch on page 508
Administering TotalWatch on page 510
Tarpit Shielding Overview on page 511
Configuring Tarpit Shielding on page 512
Working with the Reusable Wizard
The WebUI’s reusable, intuitive, user-friendly Wizard provides steps to enable, define, or change n n n n n n
Integrated vs Overlay WLAN/WIP options
Rules-based rogue classification
Detection features for attacks against infrastructure
Detection features for attacks against WLAN clients
Protection features for attacks against infrastructure
Protection features for WLAN clients
displays the WIP Wizard layout. Highlighting one of the previously configured rules reveals drop down menus for changing values. Note that the reusable wizard includes robust online Help.
ArubaOS 6.5.3.x
| User Guide Wireless Intrusion Prevention | 479
Figure 64 WIP Wizard
Understanding Wizard Intrusion Detection
Apply the intrusion detection mechanisms for detecting attacks against your infrastructure and clients (see
). You can either set the detection level to automatically enable the appropriate detection mechanisms or customize the settings for infrastructure and client attacks. Use the slider to select one of the detection levels for the infrastructure and clients: n n n n
High—Enables all the detection mechanisms applicable to your infrastructure, including all the options of low and medium level settings.
Medium (Default)—Enables some important detection mechanisms for your infrastructure. This includes all the options of the low level settings.
Low—Enables only the most critical detection mechanisms for your infrastructure.
Off—Disables all the detection mechanisms.
To enable custom settings, click the Allow custom settings link to manually enable or disable the detection mechanisms for your clients. To revert to the standard settings from the custom settings mode, click the Revert to standard settings link.
480 | Wireless Intrusion Prevention ArubaOS 6.5.3.x | User Guide
Figure 65 WIP Wizard’s Intrusion Detection
Understanding Wizard Intrusion Protection
Apply the intrusion protection mechanisms for your infrastructure and clients (see
protection level to automatically enable the appropriate protection mechanisms or customize the settings for your infrastructure and clients.
Protecting Your Infrastructure
Use the slider to select one of the protection levels for the infrastructure: n n n n
High—Enables all the protection mechanisms applicable to your infrastructure including all the options of low and medium level settings.
Medium—Enables some important protection mechanisms for your infrastructure, including all the options of the low level settings.
Low—Enables only the most critical protection mechanisms for your infrastructure.
Off (Default)—Disables all the protection mechanisms.
To enable custom settings, click the Allow custom settings link. You can manually enable or disable the protection mechanisms for your infrastructure. To revert to the standard settings from custom settings mode, click the Revert to standard settings link.
Protecting Your Clients
Use the slider (see
) to select one of the following preset protection levels for your clients: n n n
High—Enables all the protection mechanisms applicable to your clients including all the options of the low level settings.
Low—Enables only the most critical protection mechanisms for your clients.
Off (Default)—Disables all the protection mechanisms.
To enable custom settings, click the Allow custom settings link to manually enable or disable the protection mechanisms for your clients. To revert to the standard settings from custom settings mode, click the Revert to standard settings link.
ArubaOS 6.5.3.x
| User Guide Wireless Intrusion Prevention | 481
Figure 66 WIP Wizard Intrusion Protection
Monitoring the Dashboard
The Security Summary dashboard, in the Monitoring section of the WebUI, allows you to monitor the detection and protection of wireless intrusions in your network.
The dashboard’s two top tables— Discovered APs & Clients and Events —contain data as links. When these links are selected, they arrange, filter, and display the appropriate information in the lower table. For example, if you select the number 10 under the Active APs column (highlighted in yellow in
will filter and arrange information about the ten classified Rogue APs. Use the scroll bar at the right to view all ten Rogue APs.
The term events in this document is meant to include security threats, vulnerabilities, attacks (intrusion or Denial of
Service) and other similarly related events.
The Event table contains data links. Selecting these data links will display information, in the bottom table, related to the Event you selected. Again, remember to use the scroll bar at the right to view all the Events.
482 | Wireless Intrusion Prevention ArubaOS 6.5.3.x | User Guide
Figure 67 WIP Monitoring Dashboard
Detecting Rogue APs
The most important WIP functionality is the ability to classify an AP as a potential security threat. An AP is considered to be rogue if it is both unauthorized and plugged in to the wired side of the network. An AP is considered to be interfering if it is seen in the RF environment but is not connected to the wired network.
While the interfering AP can potentially cause RF interference, it is not considered a direct security threat since it is not connected to the wired network. However, an interfering AP may be reclassified as a rogue AP.
Understanding Classification Terminology
APs and clients are discovered during scanning of the wireless medium, and they are classified into various groups. The AP and client classification definitions are in
and
Table 110: AP Classification Definition
Classification Description
Valid AP
Interfering AP
Neighbor AP
An AP that is part of the enterprise providing WLAN service.
An AP that is seen in the RF environment but is not connected to the wired network.
An interfering AP is not considered a direct security threat since it is not connected to the wired network. For example, an interfering AP can be an AP that belongs to a neighboring office’s WLAN but is not part of your WLAN network.
A neighboring AP is when the BSSIDs are known. Once classified, a neighboring AP does not change its state.
Rogue AP
Suspected-Rogue AP
An unauthorized AP that is plugged into the wired side of the network.
A suspected rogue AP is an unauthorized AP that may be plugged into the wired side of the network.
Manually-contained AP An AP for which DoS is enabled manually.
ArubaOS 6.5.3.x
| User Guide Wireless Intrusion Prevention | 483
Table 111: Client Classification Definitions
Classification
Valid Client
Description
Any client that successfully authenticates with a valid AP and passes encrypted traffic is classified as a valid client.
Any clients for which DoS is enabled manually.
Manually-contained
Client
Interfering Client A client associated to any AP and is not valid.
Understanding Classification Methodology
A discovered AP is classified as a rogue or a suspected rogue by the following methods: n n n
Internal heuristics
AP classification rules
Manually by the user
The internal heuristics works by checking if the discovered AP is communicating with a wired device on the customer network. This is done by matching the MAC address of devices that are on the discovered AP’s network with that of the user’s wired network. The MAC of the device on the discovered AP’s network is known as the Match MAC . The ways in which the matching of wired MACs occurs is detailed in the sections
Understanding Match Methods on page 484
and
Understanding Match Types on page 484
.
Understanding Match Methods
The match methods are: n n n n
Plus One—The match MAC matches a device whose MAC address’ last bit was one more than that of the
Match MAC.
Minus One—The match MAC matches a device whose MAC address’ last bit was one less than that of the
Match MAC.
Equal—The match was against the same MAC address.
OUI—The match was against the manufacturer’s OUI of the wired device.
The classification details are available in the ‘Discovered AP table’ section of the ‘Security Summary’ page of the
WebUI. The information can be obtained by clicking on the details icon for a selected discovered AP. The information is also available in the command show wms rogue-ap .
Understanding Match Types n n n n n n n
Eth-Wired-MAC: The MAC addresses of wired devices learned by an AP on its Ethernet interface.
GW-Wired-MAC: The collection of Gateway MACs of all APs across the master and local controllers.
AP-Wired-MAC: The MAC addresses of wired devices learned by monitoring traffic out of other valid and rogue APs.
Config-Wired-MAC: The MAC addresses that are configured by the user, typically that of well-known servers in the network.
Manual: User-triggered classification.
External-Wired-MAC: The MAC address matched a set of known wired devices that are maintained in an external database.
Mobility-Manager: The classification was determined by the mobility manager, AMP.
484 | Wireless Intrusion Prevention ArubaOS 6.5.3.x | User Guide
n n n n n n
Classification-off: AP is classified as rogue because classification has been disabled, causing all nonauthorized APs to be classified as rogue.
Propagated-Wired-MAC: The MAC addresses of wired devices learned by a different AP than the one that uses it for classifying a rogue.
Base-BSSID-Override: The classification was derived from another BSSID, which belongs to the same AP that supports multiple BSSIDs on the radio interface.
AP-Rule: A user-defined AP classification rule has matched.
System-Wired-MAC: The MAC addresses of wired devices learned at the controller.
System-Gateway-MAC: The Gateway MAC addresses learned at the controller.
Understanding Suspected Rogue Confidence Level
A suspected rogue AP is a potential threat to the WLAN infrastructure. A suspected rogue AP has a confidence level associated with it. An AP can be marked as a suspected rogue if it is determined to be a potential threat on the wired network, or if it matches a user-defined classification rule.
The suspected-rogue classification mechanisms are: n n n n n
Each mechanism that causes a suspected-rogue classification is assigned a confidence level increment of
20%.
AP classification rules have a configured confidence level.
When a mechanism matches a previously unmatched mechanism, the confidence level increment associated with that mechanism is added to the current confidence level (the confidence level starts at zero).
The confidence level is capped at 100%.
If your controller reboots, your suspected-rogue APs are not checked against any new rules that were configured after the reboot. Without this restriction, all the mechanisms that classified your APs as suspected-rogues may trigger again, causing the confidence level to surpass its cap of 100%. You can explicitly mark an AP as “interfering” to trigger all new rules to match against it.
n n
Understanding AP Classification Rules
AP classification rule configuration is performed only on a master controller. If AMP is enabled via the mobility-manager command, then processing of the AP classification rules is disabled on the master controller. A rule is identified by its ASCII character string name (32 characters maximum). The AP classification rules have one of the following specifications: n
SSID of the AP
SNR of the AP
Discovered-AP-Count or the number of APs that can see the AP
Understanding SSID specification
Each rule can have up to 6 SSID parameters. If one or more SSIDs are specified in a rule, an option of whether to match any of the SSIDs or not match all of the SSIDs can be specified. The default is to check for a match operation.
Understanding SNR specification
Each rule can have only one specification of the SNR. A minimum and/or maximum can be specified in each rule, and the specification is in SNR (db).
ArubaOS 6.5.3.x
| User Guide Wireless Intrusion Prevention | 485
Understanding Discovered-AP-Count specification
Each rule can have only one specification of the Discovered-AP-Count. Each rule can specify a minimum or maximum of the Discovered-AP-count. The minimum or maximum operation must be specified if the
Discovered-AP-count is specified. The default setting is to check for the minimum discovered-AP-count.
Sample Rules
If SSID equals xyz AND SNR > 40 then classify AP as suspected-rogue with conf-level-increment of 20
If SNR > 60 and DISCOVERING_APS > 2, then classify AP as suspected-rogue with conf-level increment of 35
If SSID equals ‘XYZ’, then classify AP as known-neighbor
Understanding Rule Matching
A rule must be enabled before it is matched. A maximum of 32 rules can be created with a maximum of 16 rules simultaneously active. If a rule matches, an AP is classified as: n n
Suspected-Rogue: An associated confidence-level is provided (minimum is 5%)
Neighbor
The following mechanism is used for rule matching: n n n n n n n
When all the conditions specified in the rule evaluate to true, the rule matches.
If multiple rules match, causing the AP to be classified as a Suspected-Rogue, the confidence level of each rule is aggregated to determine the confidence level of the classification.
When multiple rules match and any one of those matching rules cause the AP to be classified as a Neighbor, then the AP is classified as Neighbor.
APs classified as either Neighbor or Suspected-Rogue will attempt to match any configured AP rule.
Once a rule matches an AP, the same rule will not be checked for the AP.
When the controller reboots, no attempt to match a previously matched AP is made.
If a rule is disabled or modified, all APs that were previously classified based on that rule will continue to be in the newly classified state.
Working with Intrusion Detection
This section covers Infrastructure and Client Intrusion Detections.
Understanding Infrastructure Intrusion Detection
Detecting attacks against the infrastructure is critical in avoiding attacks that may lead to a large-scale Denial of
Service (DoS) attack or a security breach. This group of features detects attacks against the WLAN infrastructure, which consists of authorized APs, the RF medium, and the wired network. An authorized or valid-AP is defined as an AP that belongs to the WLAN infrastructure. The AP is either an Aruba AP or a third party AP. ArubaOS automatically learns authorized Aruba APs.
presents a summary of the Intrusion infrastructure detection features with their related commands, traps, and syslog identification. Feature details follow the table.
486 | Wireless Intrusion Prevention ArubaOS 6.5.3.x | User Guide
Table 112: Infrastructure Detection Summary
Feature Command
ids dos-profile detect-ht-40mhz-intolerance client-ht-40mhz-intol-quiet-time
ids unauthorized-device-profile detect-ht-greenfield ids unauthorized-device-profile detect-adhoc-network
Detecting Ad hoc Networks on page 491
ids unauthorized-device-profile detect-adhoc-using-valid-ssid adhoc-using-valid-ssid-quiet-time ids dos-profile detect-ap-flood ap-flood-threshold ap-flood-inc-time ap-flood-quiet-time
ids impersonation-profile detect-ap-impersonation beacon-diff-threshold beacon-inc-wait-time ids impersonation-profile detect-ap-spoofing ap-spoofing-quiet-time
Trap wlsxHT40MHzIntoleranceAP wlsxHT40MHzIntoleranceSta wlsxHtGreenfieldSupported wlsxNAdhocNetwork wlsxAdhocUsingValidSSID wlsxApFloodAttack wlsxAPImpersonation wlsxAPSpoofingDetected wlsxClientAssociatingOn
WrongChannel
12603
3,
127033
12606
8,
127068
12603
4,
127034
Syslog
ID
12605
2,
12605
3,
12705
2,
127053
12605
4,
127054
12600
6,
127006
12606
9,
12607
0,
12706
9,
127070
ArubaOS 6.5.3.x
| User Guide Wireless Intrusion Prevention | 487
Feature Command
ids unauthorized-device-profile detect-bad-wep
Trap wlsxRepeatWEPIVViolation wlsxStaRepeatWEPIVViolation wlsxWeakWEPIVViolation wlsxStaWeakWEPIVViolation wlsxMalformedFrameWrongChann el
Detected
Syslog
ID
12601
4,
12601
5,
12601
6,
12601
7,
12701
4,
12701
5,
12701
6,
127017
12608
6,
127086 wlsxClientFloodAttack 12606
4,
127064
ids impersonation-profile detect-beacon-wrong-channel beacon-wrong-channel-quiet-time ids dos-profile detect-client-flood client-flood-threshold client-flood-inc-time client-flood-quiet-time
ids dos-profile detect-cts-rate-anomaly cts-rate-threshold cts-rate-time-interval cts-rate-quiet-time
ids unauthorized-device-profile detect-invalid-mac-oui mac-oui-quiet-time wlsxCtsRateAnomaly 12607
3,
127073
ids dos-profile detect-invalid-address-combination invalid-address-combination-quiettime
ids dos-profile detect-overflow-eapol-key overflow-eapol-key-quiet-time
ids dos-profile detect-overflow-ie overflow-ie-quiet-time wlsxInvalidMacOUIAP wlsxInvalidMacOUISta wlsxInvalidAddressCombination
12602
9,
12603
0,
12702
9,
127030
12607
9,
127079 wlsxMalformedOverflowEAPOLKey
Detected wlsxOverflowIEDetected
12608
2,
127082
12608
4,
127084
488 | Wireless Intrusion Prevention ArubaOS 6.5.3.x | User Guide
Feature Command
(WEP, WPA,
SSID, Channel,
OUI) ids dos-profile detect-malformed-assoc-req malformed-assoc-req-quiet-time ids dos-profile detect-malformed-frame-auth malformed-auth-frame-quiet-time ids dos-profile detect-malformed-htie malformed-htie-quiet-time ids-dos-profile detect-malformed-large-duration malformed-large-duration-quiet-time ids unauthorized-device-profile detect-misconfigured-ap privacy require-wpa valid-and-protected-ssid cfg-valid-11g-channel cfg-valid-11a-channel valid-oui
ids dos-profile detect-rts-rate-anomaly rts-rate-threshold rts-rate-time-interval rts-rate-quiet-time
Trap wlsxMalformedAssocReqDetected
Syslog
ID
12608
0,
127080 wlsxMalformedAuthFrameDetecte d
12608
3,
127083 wlsxMalformedHTIEDetected 12608
1,
127081 wlsxMalformedFrameLargeDuratio n
Detected
12608
5,
127085 wlsxWEPMisconfiguration wlsxWPAMisconfiguration wlsxSSIDMisconfiguration wlsxChannelMisconfiguration wlsxOUIMisconfiguration wlsxRtsRateAnomaly
12601
1,
12602
8,
12601
0,
12600
8,
12600
9,
12701
1,
12702
8,
12701
0,
12700
8,
127009
12607
4,
127074
ArubaOS 6.5.3.x
| User Guide Wireless Intrusion Prevention | 489
Feature Command
ids unauthorized-device-profile detect-windows-bridge
ids unauthorized-device-profile detect-wireless-bridge wireless-bridge-quiet-time
ids signature-matching-profile signature deauth-Broadcast ids general-profile signature-quiet-time
ids signature-matching-profile signature disassoc-Broadcast ids general-profile signature-quiet-time
ids signature-matching-profile signature ‘Netstumbler Generic’ signature ‘Netstumbler Version
3.3.0.x’
ids general-profile signature-quiet-time ids-unauthorized-device-profile detect-valid-ssid-misuse valid-and-protected-ssid ids signature-matching-profile signature Wellenreiter ids general-profile signature-quiet-time
Trap wlsxWindowsBridgeDetectedAP wlsxWindowsBridgeDetectedSta wlsxNAdhocNetworkBridgeDetecte d
AP wlsxNAdhocNetworkBridgeDetecte d
Sta wlsxWirelessBridge
Syslog
ID
12603
9,
12604
0,
12604
1,
12604
2,
12703
9,
12704
0,
12704
1,
127042
12603
6,
127036 wlsxNSignatureMatchDeauthBcast 12604
7,
127047 wlsxNSignatureMatchDisassocBca st
12606
6,
127066 wlsxNSignatureMatchNetstumbler 12604
3,
127043 wlsxValidSSIDViolation wlsxNSignatureMatchWellenreiter
12600
7,
127007
12606
7,
127067
Detecting an 802.11n 40MHz Intolerance Setting
When a client sets the HT capability “ intolerant bit” to indicate that it is unable to participate in a 40MHz BSS, the AP must use lower data rates with all of its clients. Network administrators often want to know if there are devices that are advertising 40MHz intolerance, as this can impact the performance of the network.
490 | Wireless Intrusion Prevention ArubaOS 6.5.3.x | User Guide
Detecting Active 802.11n Greenfield Mode
When 802.11 devices use the HT operating mode, they can not share the same channel as 802.11a/b/g stations. Not only can they not communicate with legacy devices, the way they use the transmission medium is different, which would cause collisions, errors, and retransmissions.
Detecting Ad hoc Networks
An ad-hoc network is a collection of wireless clients that form a network amongst themselves without the use of an AP. As far as network administrators are concerned, ad-hoc wireless networks are uncontrolled. If they do not use encryption, they may expose sensitive data to outside eavesdroppers. If a device is connected to a wired network and has bridging enabled, an ad-hoc network may also function like a rogue AP. Additionally, adhoc networks can expose client devices to viruses and other security vulnerabilities. For these reasons, many administrators choose to prohibit ad-hoc networks.
Detecting an Ad hoc Network Using a Valid SSID
If an unauthorized ad-hoc network is using the same SSID as an authorized network, a valid client may be tricked into connecting to the wrong network. If a client connects to a malicious ad-hoc network, security breaches or attacks can occur.
Detecting an AP Flood Attack
Fake AP is a tool that was originally created to thwart wardrivers by flooding beacon frames containing hundreds of different addresses. This would appear to a wardriver as though there were hundreds of APs in the area, thus concealing the real AP. An attacker can use this tool to flood an enterprise or public hotspots with fake AP beacons to confuse legitimate users and to increase the amount of processing need on client operating systems.
Detecting AP Impersonation
In AP impersonation attacks, the attacker sets up an AP that assumes the BSSID and ESSID of a valid AP. AP impersonation attacks can be done for man-in-the-middle attacks, a rogue AP attempting to bypass detection, or a honeypot attack.
Detecting AP Spoofing
An AP Spoofing attack involves an intruder sending forged frames that are made to look like they are from a legitimate AP. It is trivial for an attacker to do this, since tools are readily available to inject wireless frames with any MAC address that the user desires. Spoofing frames from a legitimate AP is the foundation of many wireless attacks.
Detecting Bad WEP Initialization
This is the detection of WEP initialization vectors that are known to be weak. A primary means of cracking WEP keys is to capture 802.11 frames over an extended period of time and searching for such weak implementations that are still used by many legacy devices.
Detecting a Beacon Frame Spoofing Attack
In this type of attack, an intruder spoofs a beacon packet on a channel that is different from that advertised in the beacon frame of the AP.
Detecting a Client Flood Attack
There are fake AP tools that can be used to attack wireless intrusion detection itself by generating a large number of fake clients that fill internal tables with fake information. If successful, it overwhelms the wireless intrusion system, resulting in a DoS.
ArubaOS 6.5.3.x
| User Guide Wireless Intrusion Prevention | 491
Detecting a CTS Rate Anomaly
The RF medium can be reserved via Virtual Carrier Sensing using a Clear To Send (CTS) transaction. The transmitter station sends a Ready To Send (RTS) frame to the receiver station. The receiver station responds with a CTS frame. All other stations that receive these CTS frames will refrain from transmitting over the wireless medium for an amount of time specified in the duration fields of these frames.
Attackers can exploit the Virtual Carrier Sensing mechanism to launch a DoS attack on the WLAN by transmitting numerous RTS and/or CTS frames. This causes other stations in the WLAN to defer transmission to the wireless medium. The attacker can essentially block the authorized stations in the WLAN with this attack.
Detecting an RTS Rate Anomaly
The RF medium can be reserved via Virtual Carrier Sensing using an RTS transaction. The transmitter station sends a RTS frame to the receiver station. The receiver station responds with a CTS frame. All other stations that receive these RTS frames will refrain from transmitting over the wireless medium for an amount of time specified in the duration fields of these frames.
Attackers can exploit the Virtual Carrier Sensing mechanism to launch a DoS attack on the WLAN by transmitting numerous RTS and/or CTS frames. This causes other stations in the WLAN to defer transmission to the wireless medium. The attacker can essentially block the authorized stations in the WLAN with this attack.
Detecting Devices with an Invalid MAC OUI
The first three bytes of a MAC address, known as the MAC organizationally unique identifier (OUI), is assigned by the IEEE to known manufacturers. Often, clients using a spoofed MAC address do not use a valid OUI and instead use a randomly generated MAC address.
Detecting an Invalid Address Combination
In this attack, an intruder can cause an AP to transmit deauthentication and disassociation frames to all of its clients. Triggers that can cause this condition include the use of broadcast or multicast MAC address in the source address field.
Detecting an Overflow EAPOL Key
Some wireless drivers used in access points do not correctly validate the EAPOL key fields. A malicious EAPOL-
Key packet with an invalid advertised length can trigger a DoS or possible code execution. This can only be achieved after a successful 802.11 association exchange.
Detecting Overflow IE Tags
Some wireless drivers used in access points do not correctly parse the vendor-specific IE tags. A malicious association request sent to the AP containing an IE with an inappropriate length (too long) can cause a DoS and potentially lead to code execution. The association request must be sent after a successful 802.11
authentication exchange.
Detecting a Malformed Frame-Assoc Request
Some wireless drivers used in access points do not correctly parse the SSID information element tag contained in association request frames. A malicious association request with a null SSID (that is, zero length SSID) can trigger a DoS or potential code execution condition on the targeted device.
Detecting Malformed Frame-Auth
Malformed 802.11 authentication frames that do not conform to the specification can expose vulnerabilities in some drivers that have not implemented proper error checking. This feature checks for unexpected values in an Authentication frame.
492 | Wireless Intrusion Prevention ArubaOS 6.5.3.x | User Guide
Detecting a Malformed Frame-HT IE
The IEEE 802.11n HT (High Throughput) IE is used to convey information about the 802.11n network. An
802.11 management frame containing a malformed HT IE can crash some client implementations, potentially representing an exploitable condition when transmitted by a malicious attacker.
Detecting a Malformed Frame-Large Duration
The virtual carrier-sense attack is implemented by modifying the 802.11 MAC layer implementation to allow random duration values to be sent periodically. This attack can be carried out on the ACK, data, RTS, and CTS frame types by using large duration values. This attack can prevent channel access to legitimate users.
Detecting a Misconfigured AP
A list of parameters can be configured to define the characteristics of a valid AP. This feature is primarily used when non-Aruba APs are used in the network, since the Aruba controller cannot configure the third-party APs.
These parameters include WEP, WPA, OUI of valid MAC addresses, valid channels, and valid SSIDs.
Detecting a Windows Bridge
A Windows Bridge occurs when a client that is associated to an AP is also connected to the wired network, and has enabled bridging between these two interfaces.
Detecting a Wireless Bridge
Wireless bridges are normally used to connect multiple buildings together. However, an attacker could place (or have an authorized person place) a wireless bridge inside the network that would extend the corporate network somewhere outside the building. Wireless bridges are somewhat different from rogue APs, in that they do not use beacons and have no concept of association. Most networks do not use bridges – in these networks, the presence of a bridge is a signal that a security problem exists.
Detecting Broadcast Deauthentication
A deauthentication broadcast attempts to disconnect all stations in range. Rather than sending a spoofed deauth to a specific MAC address, this attack sends the frame to a broadcast address.
Detecting Broadcast Disassociation
By sending disassociation frames to the broadcast address (FF:FF:FF:FF:FF:FF), an attacker can disconnect all stations on a network for a widespread DoS.
Detecting Netstumbler
NetStumbler is a popular wardriving application used to locate 802.11 networks. When used with certain NICs,
NetStumbler generates a characteristic frame that can be detected. Version 3.3.0 of NetStumbler changed the characteristic frame slightly.
Detecting Valid SSID Misuse
If an unauthorized AP (neighbor or interfering) is using the same SSID as an authorized network, a valid client may be tricked into connecting to the wrong network. If a client connects to a malicious network, security breaches or attacks can occur.
Detecting Wellenreiter
Wellenreiter is a passive wireless network discovery tool used to compile a list of APs along with their MAC address, SSID, channel, and security setting in the vicinity. It passively sniffs wireless traffic, and with certain version (versions 1.4, 1.5, and 1.6), sends active probes that target known default SSIDs.
ArubaOS 6.5.3.x
| User Guide Wireless Intrusion Prevention | 493
Understanding Client Intrusion Detection
Generally, clients are more vulnerable to attacks than APs. Clients are more apt to associate with a malignant
AP due to the client’s driver behavior or a misconfigured client. It is important to monitor authorized clients to track their associations and to track any attacks raised against the client.Client attack detection is categorized as: n n
Detecting attacks against Aruba APs clients: An attacker can perform an active DOS attack against an associated client, or perform a replay attack to obtain the keys of transmission which could lead to more serious attacks.
Monitoring Authorized clients: Since clients are easily tricked into associating with unauthorized APs, tracking all misassociations of authorized clients is very important.
An authorized client is a client authorized to use the WLAN network. In ArubaOS, an authorized client is called a valid-client . ArubaOS automatically learns a valid client. A client is determined to be valid if it is associated to an authorized or valid AP using encryption; either Layer 2 or IPSEC.
Detection of attacks is limited to valid clients and clients associated to valid APs. Clients that are associated as guests using unencrypted association are included in the attack detection. However, clients on neighboring (interfering) APs are not tracked for attack detection unless they are specified as valid.
presents a summary of the client intrusion detection features with their related commands, traps, and syslog identification. Details of each feature follow the table.
Table 113: Client Detection Summary
Feature Command Trap wlsxBlockAckAttackDetected
Syslog
ID
126087,
127087
ids-dos-profile detect-block-ack-attack block-ack-quiet-time ids-dos-profile detect-chopchop-attack chopchop-quiet-time wlsxChopChopAttackDetected ids dos-profile <name> detect-disconnect-sta disconnect-sta-quiet-time disconnect-sta-assoc-resp-threshold disconnect-deauth-disassoc-threshold wlsxNDisconnectStationAttack
126078,
127078
126035,
127035
ids-dos-profile detect-eap-rate-anomaly eap-rate-threshold eap-rate-time-interval eap-rate-quiet-time ids dos-profile detect-fatajack-attack fatajack-attack-quiet-time wlsxEAPRateAnomaly wlsxFataJackAttackDetected
126032,
127032
126072,
127072
494 | Wireless Intrusion Prevention ArubaOS 6.5.3.x | User Guide
Feature Command Trap
ids impersonation-profile detect-hotspotter-attack hotspotter-quiet-time ids dos-profile detect-power-save-dos-attack power-save-dos-min-frames power-save-dos-quiet-time power-save-dos-threshold
ids dos-profile detect-omerta-attack omerta-attack-threshold omerta-attack-quiet-time ids dos-profile detect-rate-anomalies
assoc-rate-thresholds disassoc-rate-thresholds deauth-rate-thresholds probe-request-rate-thresholds probe-response-rate-thresholds auth-rate-thresholds
ids dos-profile detect-tkip-replay-attack tkip-replay-quiet-time ids unauthorized-device-profile detect-unencrypted-valid-client unencrypted-valid-client-quiet-time ids unauthorized-device-profile detect-valid-client-misassociation wlsxHotspotterAttackDetected wlsxPowerSaveDoSAttack wlsxOmertaAttack wlsxChannelRateAnomaly wlsxNodeRateAnomalyAP wlsxNodeRateAnomalySta wlsxTkipReplayAttackDetected wlsxValidClientNotUsingEncryption wlsxValidClientMisassociation
Syslog
ID
126088,
127088
126109,
127109
126071,
127071
126061,
126062,
126063,
127061,
127062,
127063
126077,
127077
126065,
127065
126075,
127075
ArubaOS 6.5.3.x
| User Guide Wireless Intrusion Prevention | 495
Feature
Command ids signature-matching-profile signature AirJack ids general-profile signature-quiet-time ids signature-matching-profile signature ASLEAP ids general-profile signature-quiet-time ids signature-matching-profile signature Null Probe Response ids general-profile signature-quiet-time
Trap wlsxNSignatureMatchAirjack wlsxNSignatureMatchAsleap
Syslog
ID
126046,
127046
126044,
127044 wlsxNSignatureMatchNullProbeResp 126045,
127045
Detecting a Block ACK DoS
The Block ACK mechanism that was introduced in 802.11e, and enhanced in 802.11nD3.0, has a built-in DoS vulnerability. The Block ACK mechanism allows for a sender to use the ADDBA request frame to specify the sequence number window that the receiver should expect. The receiver will only accept frames in this window.
An attacker can spoof the ADDBA request frame causing the receiver to reset its sequence number window and thereby drop frames that do not fall in that range.
Detecting a ChopChop Attack
ChopChop is a plaintext recovery attack against WEP encrypted networks. It works by forcing the plaintext, one byte at a time, by truncating a captured frame and then trying all 256 possible values for the last byte with a corrected CRC. The correct guess causes the AP to retransmit the frame. When that happens, the frame is truncated again.
Detecting a Disconnect Station Attack
A disconnect attack can be launched in many ways; the end result is that the client is effectively and repeatedly disconnected from the AP.
Detecting an EAP Rate Anomaly
To authenticate wireless clients, WLANs may use 802.1X, which is based on a framework called Extensible
Authentication Protocol (EAP). After an EAP packet exchange, and the user is successfully authenticated, the
EAP-Success is sent from the AP to the client. If the user fails to authenticate, an EAP-Failure is sent. In this attack, EAP-Failure or EAP-Success frames are spoofed from the access point to the client to disrupting the authentication state on the client. This confuses the client’s state, causing it to drop the AP connection. By continuously sending EAP Success or Failure messages, an attacker can effectively prevent the client from authenticating with the APs in the WLAN.
Detecting a FATA-Jack Attack Structure
FATA-Jack is an 802.11 client DoS tool that tries to disconnect targeted stations using spoofed authentication frames that contain an invalid authentication algorithm number.
496 | Wireless Intrusion Prevention ArubaOS 6.5.3.x | User Guide
Detecting a Hotspotter Attack
The Hotspotter attack is an evil-twin attack which attempts to lure a client to a malicious AP. Many enterprise employees use their laptop in Wi-Fi area hotspots at airports, cafes, malls etc. They have SSIDs of their hotspot service providers configured on their laptops. The SSIDs used by different hotspot service providers are well known. This enables the attackers to set up APs with hotspot SSIDs in close proximity of the enterprise premises. When the enterprise laptop Client probes for hotspot SSIDs, these malicious APs respond and invite the client to connect to them. When the client connects to a malicious AP, a number of security attacks can be launched on the client. Airsnarf is a popular hacking tool used to launch these attacks.
Detecting a Meiners Power Save DoS Attack
To save on power, wireless clients will "sleep" periodically, during which they cannot transmit or receive. A client indicates its intention to sleep by sending frames to the AP with the Power Management bit ON. The AP then begins buffering traffic bound for that client until it indicates that it is awake. An intruder could exploit this mechanism by sending (spoofed) frames to the AP on behalf of the client to trick the AP into believing the client is asleep. This will cause the AP to buffer most, if not all, frames destined for the client.
Detecting an Omerta Attack
Omerta is an 802.11 DoS tool that sends disassociation frames to all stations on a channel in response to data frames. The Omerta attack is characterized by disassociation frames with a reason code of 0x01. This reason code is “unspecified” and is not used under normal circumstances.
Detecting Rate Anomalies
Many DoS attacks flood an AP or multiple APs with 802.11 management frames. These can include authenticate/associate frames, which are designed to fill up the association table of an AP. Other management frame floods, such as probe request floods, can consume excess processing power on the AP.
Detecting a TKIP Replay Attack
TKIP is vulnerable to replay (via WMM/QoS) and plaintext discovery (via ChopChop). This affects all WPA-TKIP usage. By replaying a captured TKIP data frame on other QoS queues, an attacker can manipulate the RC4 data and checksum to derive the plaintext at a rate of one byte per minute.
By targeting an ARP frame and guessing the known payload, an attacker can extract the complete plaintext and
MIC checksum. With the extracted MIC checksum, an attacker can reverse the MIC AP to Station key and sign future messages as MIC compliant, opening the door for more advanced attacks.
Detecting Unencrypted Valid Clients
An authorized (valid) client that is passing traffic in unencrypted mode is a security risk. An intruder can sniff unencrypted traffic (also known as packet capture ) with software tools known as sniffers. These packets are then reassembled to produce the original message.
Detecting a Valid Client Misassociation
This feature does not detect attacks, but rather it monitors authorized (valid) wireless clients and their association within the network. Valid client misassociation is potentially dangerous to network security. The four types of misassociation that we monitor are: n n n n
Authorized Client associated to Rogue: A valid client that is associated to a rogue AP.
Authorized Client associated to External AP: An external AP, in this context, is any AP that is not valid and not a rogue.
Authorized Client associated to Honeypot AP: A honeypot is an AP that is not valid but is using an
SSID that has been designated as valid/protected.
Authorized Client in ad hoc connection mode: A valid client that has joined an ad hoc network.
ArubaOS 6.5.3.x
| User Guide Wireless Intrusion Prevention | 497
Detecting an AirJack Attack
AirJack is a suite of device drivers for 802.11(a/b/g) raw frame injection and reception. It was intended to be used as a development tool for all 802.11 applications that need to access the raw protocol. However, one of the tools included allowing users to force all users off an AP.
Detecting ASLEAP
ASLEAP is a tool created for Linux systems used to attack Cisco LEAP authentication protocol.
Detecting a Null Probe Response
A null probe response attack has the potential to crash or lock up the firmware of many 802.11 NICs. In this attack, a client probe-request frame will be answered by a probe response containing a null SSID. A number of popular NIC cards will lock up upon receiving such a probe response.
Configuring Intrusion Protection
Intrusion protection features support containment of an AP or a client. In the case of an AP, we will attempt to disconnect all clients that are connected or attempting to connect to the AP. In the case of a client, the client's association to an AP is targeted. The following containment mechanisms are supported: n n n
Deauthentication containment: An AP or client is contained by disrupting its association on the wireless interface.
Tarpit containment: An AP is contained by luring clients that are attempting to associate with it to a tarpit. The tarpit can be on the same channel as the AP being contained, or on a different channel (see
Shielding Overview on page 511 ).
Wired containment: An AP or client is contained by disrupting its connection on the wired interface.
The WIP feature supports separate enforcement policies that use the underlying containment mechanisms to contain an AP or a client that do not conform to the policy. These policies are discussed in the sections that follow.
Understanding Infrastructure Intrusion Protection
presents a summary of the infrastructure intrusion protection features with their related commands, traps, and syslog identifications. Details of each feature follow the table.
498 | Wireless Intrusion Prevention ArubaOS 6.5.3.x | User Guide
Table 114: Infrastructure Protection Summary
Feature Command
ids unauthorized-device-profile protect-ht-40mhz
ids unauthorized-device-profile protect-high-throughput
ids unauthorized-device-profile protect-adhoc-network protect-adhoc-enhanced
ids impersonation-profile protect-ap-impersonation
ids unauthorized-device-profile protect-misconfigured-ap
ids unauthorized-device-profile protect-ssid
Trap wlsxAPDeauthContainment wlsxClientDeauthContainment wlsxTarpitContainment wlsxAPDeauthContainment wlsxClientDeauthContainment wlsxTarpitContainment wlsxAPDeauthContainment wlsxClientDeauthContainment wlsxTarpitContainment wlsxEhancedAdhocContainment wlsxAPDeauthContainment wlsxClientDeauthContainment wlsxTarpitContainment wlsxAPDeauthContainment wlsxClientDeauthContainment wlsxTarpitContainment wlsxAPDeauthContainment wlsxClientDeauthContainment wlsxTarpitContainment
Syslog ID
106005,
106006,
126102,
126103,
126108,
127102,
127103, 127108
106005,
106006,
126102,
126103,
126108,
127102,
127103, 127108
106005,
106006,
126012,
126102,
126103,
126108,
127102,
127103,
127108, 126114
106005,
106006,
126102,
126103,
126108,
127102,
127103, 127108
106005,
106006,
126102,
126103,
126108,
127102,
127103, 127108
106005,
106006,
126102,
126103,
126108,
127102,
127103, 127108
ArubaOS 6.5.3.x
| User Guide Wireless Intrusion Prevention | 499
Feature
Command ids unauthorized-device-profile detectwireless-hosted-network protect-wireless-hosted-network
ids unauthorized-device-profile suspect-rogue-containment suspect-rogue-conf-level
ids unauthorized-device-profile rogue-containment ids general-profile wired-containment wired-containment-ap-adj-mac wired-containment-susp-l3-rogue
Trap wlsxWirelessHostedNetwork-
Detected wlsxClientAssociatedToHosted-
NetworkDetected wlsxWirelessHostedNetwork-
Containment wlsxHostOfWirelessNetwork-
Containment wlsxAPDeauthContainment wlsxClientDeauthContainment wlsxTarpitContainment wlsxAPDeauthContainment wlsxClientDeauthContainment wlsxTarpitContainment wlsxAPWiredContainment
Syslog ID
126110,
126111,
126112, 126113
106005,
106006,
126102,
126103,
126108,
127102,
127103, 127108
106005,
106006,
106010,
126102,
126103,
126108,
127102,
127103, 127108
126104,126105,
126106, 126107
Protecting 40MHz 802.11 High Throughput Devices
Protection from AP(s) that support 40MHz HT involves containing the AP such that clients can not connect.
Protecting 802.11n High Throughput Devices
Protection from AP(s) that support HT involves containing the AP such that clients can not connect.
Protecting Against Adhoc Networks
Protection from an ad-hoc Network involves containing the ad-hoc network so that clients can not connect to it. The basic ad-hoc protection feature protects against ad-hoc networks using WPA/WPA2 security. The enhanced ad-hoc network protection feature protects against open/WEP ad-hoc networks. Both features can be used together for maximum protection, or enabled or disabled separately
This feature requires that you enable the wireless-containment setting in the IDS general profile.
Protecting Against AP Impersonation
Protection from AP impersonation involves containing both the legitimate and impersonating AP so that clients can not connect to either AP.
Protecting Against Misconfigured APs
Protect Misconfigured AP enforces that valid APs are configured properly. An offending AP is contained by preventing clients from associating to it.
500 | Wireless Intrusion Prevention ArubaOS 6.5.3.x | User Guide
Protecting Against Wireless Hosted Networks
Clients using the Windows wireless hosted network feature can act as an access point to which other wireless clients can connect, effectively becoming a Wi-Fi HotSpot. This creates a security issue for enterprises, because unauthorized users can use a hosted network to gain access to the corporate network, and valid users that connect to a hosted network are vulnerable to attacks or security breaches. This feature detects a wireless hosted network, and contains the client hosting this network.
Protecting SSIDs
Protect SSID enforces that valid/protected SSIDs are used only by valid APs. An offending AP is contained by preventing clients from associating to it.
Protecting Against Rogue Containment
By default, rogue APs are not automatically disabled. Rogue containment automatically disables a rogue AP by preventing clients from associating to it.
Protecting Against Suspected Rogue Containment
By default, suspected rogue APs are not automatically contained. In combination with the suspected rogue containment confidence level, suspected rogue containment automatically disables a suspect rogue by preventing clients from associating to it.
Protection against Wired Rogue APs
This feature enables containment from the wired side of the network. The basic wired containment feature in the IDS general profile isolates layer-3 APs whose wired interface MAC addresses are the same as (or one character off from) their BSSIDs. The enhanced wired containment feature introduced in ArubaOS 6.3 can also identify and contain an AP with a preset wired MAC address that is completely different from the AP’s BSSID. In many non-Aruba APs, the MAC address the AP provides to wireless clients as a ‘gateway MAC’ is offset by one character from its wired MAC address. This enhanced feature allows ArubaOS to check to see if a suspected
Layer-3 rogue AP’s MAC address follows this common pattern.
Understanding Client Intrusion Protection
list the client intrusion protection features with their related commands, traps, and syslog identifications. Details of each feature follow the table.
Table 115: Client Protection Summary
Feature
Command ids unauthorized-device-profile protect-valid-sta
Trap wlsxAPDeauthContainment wlsxClientDeauthContainment wlsxTarpitContainment
ids unauthorized-device-profile protect-windows-bridge wlsxAPDeauthContainment wlsxClientDeauthContainment wlsxTarpitContainment
Syslog ID
106005,
106006,
126102,
126103,
126108,
127102,
127103,
127108
106005,
106006,
126102,
126103,
126108,
127102,
127103,
127108
ArubaOS 6.5.3.x
| User Guide Wireless Intrusion Prevention | 501
Protecting Valid Stations
Protecting a valid client involves disconnecting that client if it is associated to a non-valid AP.
Protecting Windows Bridge
Protecting from a Windows Bridge involves containing the client that is forming the bridge so that it can not connect to the AP.
Warning Message for Containment Features
The feature for enabling wireless containment under the IDS Unauthorized Device profile and IDS
Impersonation profile may be in violation of certain Federal Communications Commission (FCC) regulatory statutes. To address this, a warning message will be issued each time the command is enabled: n n
If enabled through the WebUI, the warning message will appear before the command is executed.
If enabled through the CLI, the warning message will appear after the command is executed
Configuring the WLAN Management System
The WLAN management system (WMS) on the controller monitors wireless traffic to detect any new AP or wireless client station in the RF environment. When an AP or wireless client is detected, it is classified, and its classification is used to determine the security policies that should be enforced on the AP or client.
In the WebUI
1. Navigate to the Configuration > Advanced Services > Wireless page.
2. Configure the parameters, as described in
. Then click Apply .
Table 116: WMS Configuration Parameters
Parameter
Ad-hoc AP Ageout
AP Ageout Interval
AM Poll Interval
Number of AM Poll Retries
Station Ageout Interval
Description
The amount of time, in minutes, that an ad-hoc (IBSS) AP unseen by any problems before it is deleted from the database. Enter 0 to disable ageout.
Default: 30 minutes
The amount of time, in minutes, that an AP is unseen by any probes before it is deleted from the database. Enter 0 to disable ageout.
Default: 30 minutes
Interval, in milliseconds, for communication between the controller and Aruba AMs. The controller contacts the AM at this interval to download AP to STA associations, update policy configuration changes, and download AP and STA statistics.
Default: 60000 milliseconds (1 minute)
Maximum number of failed polling attempts before the polled
AM is considered to be down.
Default: 3
The amount of time, in minutes, that a client is unseen by any probes before it is deleted from the database. Enter 0 to disable ageout.
Default: 30 minutes
502 | Wireless Intrusion Prevention ArubaOS 6.5.3.x | User Guide
Parameter
Enable Statistics Update in DB
Collect Stat
Learn System Wired Mac
Propagate Wired Mac
Mark Neighbor APs as Persistent
Neighbor APs
Learn APs
Description
Enables or disables statistics update in the database.
Default: enabled
Enables collection of statistics (up to 25,000 entries) on the master controller for monitored APs and clients.
Default: disabled
Enable or disable “learning” of wired MACs at the controller.
Default: disabled
Enables the propagation of the gateway wired MAC information.
Default: enabled
Enables or disables APs that are marked as neighbor from being aged out.
Default: enabled
Enables or disables AP learning. Learning affects the way APs are classified.
Default: disabled
In the CLI
Use the following commands to configure WMS via the CLI. The parameters in this command are described in detail in
ids wms-general-profile adhoc-ap-ageout-interval <adhoc-ap-ageout-interval> | ap-ageout-interval <ap-ageoutinterval> | collect-stats {disable|enable} | learn-ap {enable|disable} | learn-systemwired-macs | persistent-neighbor {enable|disable} | persistent-valid-sta {enable|disable} | pollinterval <milliseconds> | poll-retries <number> | propagate-wired-macs {enable|disable} | sta-ageout-interval
<minutes> | stat-update {enable|disable}
Configuring Local WMS Settings
You can also use the CLI to define local WMS system settings for the maximum number of APs and client stations.
Use this command with caution. Increasing the limit will cause an increase in usage in the memory by WMS. In general, each entry will consume about 500 bytes of memory. If the setting is bumped up by 2000, then it will cause an increase in WMS memory usage by 1MB
(host) (config) #ids wms-local-system-profile max-ap-threshold <max-ap-threshold>
(host) (config) #ids wms-local-system-profile max-sta-threshold <max-sta-threshold>
Managing the WMS Database
The WMS process interacts with all the air monitor (AM) processes in the network. When WMS receives an event message from an AM, the WMS process will save the event information along with the BSSID of the AP that generated the event in the WMS database. Use the following commands in Enable mode to manage the
WMS database.
The wms export-db command exports the specified file as an ASCII text file into the WMS database.
(host) #wms export-db <filename>
The wms import-db command imports the specified file into the WMS database:
ArubaOS 6.5.3.x
| User Guide Wireless Intrusion Prevention | 503
(host) #wms import-db <filename>
The wms reint-db command reinitializes the WMS database. Note that this command does not make an automatic backup of the current database.
(host) #wms reint-db
Optimizing Classification Behavior
Starting with ArubaOS 6.4.4.0, APs can be configured to periodically send WMS a list of monitored devices that are still unclassified. Once the WMS receives this list, a classification message is sent from the WMS to the AP, to classify each unclassified device.
In the WebUI
1. Navigate to the Configuration > Advanced Services > All Profiles > IDS > IDS General > Advanced page.
2. Configure the parameters, as described in the following table. Then click Apply .
Table 117: IDS General Profile Parameters
Parameter
Unclassified AP Update
Description
Unclassified Device Update Interval
Unclassified STA Update
Enables or disables classification updates for monitored APs. If this option is enabled, it helps decrease the delay in the speed at which the devices are classified.
Default: Disabled
The time interval for the AP to send the WMS a list of unclassified
APs and clients. The minimum interval is 30 seconds.
Default: 60 seconds
Enables or disables classification updates for monitored clients.
If this option is enabled, it helps decrease the delay in the speed at which the devices are classified.
Default: Disabled
In the CLI
Use the following command to configure IDS General Profile parameters using the CLI.
ids general-profile <profile-name> unclass-ap-update unclass-device-update-interval unclass-sta-update
Managing List of Valid Exempt Clients
Starting with ArubaOS 6.4.4, the administrator can configure clients to be exempted from valid station protection and valid station misassociation detection by adding the mac-address of those devices to the validexempt-list.
Once a client MAC address is added to the valid-exempt list: n n n
If the client exists in the WMS, the classification is set to valid.
If the client does not exist in the WMS, a client entry is created and then the classification is set to valid.
After the classification is done, APs that are seeing the client are notified that the client is added to the validexempt list.
504 | Wireless Intrusion Prevention ArubaOS 6.5.3.x | User Guide
A maximum of 200 MAC addresses can be added to a valid-exempt list and this list is not retained after the controller reboots or a process is restarted.
In the CLI
Use the following commands to add or remove MAC addresses from the valid-exempt list: wms client <macaddr> valid-exempt insert wms client <macaddr> valid-exempt remove
Use the following command to display a list of configured valid-exempt clients: show wms client valid-exempt
Use the following command to display a list of clients that are viewed by the AP and marked as valid-exempt: show ap monitor client-list ap-name <> valid-exempt
Use the following command to view the number of MAC addresses added to the valid-exempt client list: show wms counters
Valid Exempt Station Macs
Understanding Client Blacklisting
When a client is blacklisted in the Aruba system, the client is not allowed to associate with any AP in the network for a specified amount of time. If a client is connected to the network when it is blacklisted, a deauthentication message is sent to force the client to disconnect. While blacklisted, the client cannot associate with another SSID in the network.
The controller retains the client blacklist in the user database, so the information is not lost if the controller reboots. When you import or export the controller’s user database, the client blacklist will be exported or imported as well.
Methods of Blacklisting
There are several ways in which a client can be blacklisted in the Aruba system: n n n n
You can manually blacklist a specific client. See
Blacklisting Manually on page 505
for more information.
A client fails to successfully authenticate for a configured number of times for a specified authentication method. The client is automatically blacklisted. See
Blacklisting by Authentication Failure on page 506
for more information.
A DoS or man in the middle (MITM) attack has been launched in the network. Detection of these attacks can cause the immediate blacklisting of a client. See
Enabling Attack Blacklisting on page 507
for more information.
An external application or appliance that provides network services, such as virus protection or intrusion detection, can blacklist a client and send the blacklisting information to the controller via an XML API server.
When the controller receives the client blacklist request from the server, it blacklists the client, logs an event, and sends an SNMP trap.
See
External Services Interface on page 1056
for more information.
The External Services Interface feature require the Policy Enforcement Firewall Next Generation (PEFNG) license installed in the controller.
Blacklisting Manually
There are several reasons why you may choose to blacklist a client. For example, you can enable different
Aruba intrusion detection system (IDS) features that detect suspicious activities, such as MAC address spoofing
ArubaOS 6.5.3.x
| User Guide Wireless Intrusion Prevention | 505
or DoS attacks. When these activities are detected, an event is logged and an SNMP trap is sent with the client information. To blacklist a client, you need to know its MAC address.
To manually blacklist a client via the WebUI:
1. Navigate to the Monitoring > Controller > Clients page.
2. Select the client to be blacklisted, then click the Blacklist button.
To clear the entire client blacklist using the WebUI:
1. Navigate to the Monitoring > Controller > Clients page.
2. Click Remove All from Blacklist .
To manually blacklist a client via the command-line interface, access the CLI in config mode and issue the following command: stm add-blacklist-client < macaddr>
To clear the entire client blacklist using the command-line interface, access the CLI in config mode and issue the following command: stm purge-blacklist-client
Blacklisting by Authentication Failure
You can configure a maximum authentication failure threshold for each of the following authentication methods: n n n n
802.1X
MAC
Captive portal
VPN
When a client exceeds the configured threshold for one of the above methods, the client is automatically blacklisted by the controller, an event is logged, and an SNMP trap is sent. By default, the maximum authentication failure threshold is set to 0 for the above authentication methods, which means that there is no limit to the number of times a client can attempt to authenticate.
With 802.1X authentication, you can also configure blacklisting of clients who fail machine authentication.
When clients are blacklisted because they exceed the authentication failure threshold, they are blacklisted indefinitely by default. You can configure the duration of the blacklisting; see
Setting Blacklist Duration on page
To set the authentication failure threshold via the WebUI:
1. Navigate to the Configuration > Security > Authentication > Profiles page.
2. In the Profiles list, select the appropriate authentication profile, then select the profile instance.
3. Enter a value in the Max Authentication failures field.
4. Click Apply .
To set the authentication failure threshold via the command-line interface, access the CLI in config mode and issue the following commands: aaa authentication {captive-portal|dot1x|mac|vpn} < profile>
max-authentication-failures < number>
506 | Wireless Intrusion Prevention ArubaOS 6.5.3.x | User Guide
Enabling Attack Blacklisting
There are two types of automatic client blacklisting that can be enabled: blacklisting due to spoofed deauthentication, or blacklisting due to other types of DoS attacks.
Automatic blacklisting for DoS attacks other than spoofed deauthentication is enabled by default. You can disable this blacklisting on a per-SSID basis in the virtual AP profile.
Man in the middle (MITM) attacks begin with an intruder impersonating a valid enterprise AP. If an AP needs to reboot, it sends deauthentication packets to connected clients to enable them to disconnect and reassociate with another AP. An intruder or attacker can spoof deauthentication packets, forcing clients to disconnect from the network and reassociate with the attacker’s AP. A valid enterprise client associates to the intruder’s AP, while the intruder then associates to the enterprise AP. Communication between the network and the client flows through the intruder (the man in the middle), thus allowing the intruder the ability to add, delete, or modify data. When this type of attack is identified by the Aruba system, the client can be blacklisted, blocking the MITM attack. You can enable this blacklisting ability in the IDS DoSprofile (this is disabled by default).
To enable spoofed deauth detection and blacklisting via the WebUI:
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. Select either AP Group or AP Specific tab. Click Edit for the AP group or AP name.
3. In the Profiles list, expand the IDS menu, then select IDS profile .
4. Select the IDS DOS profile .
5. Select (check) Spoofed Deauth Blacklist .
6. Click Apply .
To enabled spoofed deauth detection and blacklisting via the command-line interface, access the CLI in config mode, and issue the following commands: ids dos-profile < profile>
spoofed-deauth-blacklist
Setting Blacklist Duration
You can configure the duration that clients are blacklisted on a per-SSID basis via the virtual AP profile. There are two different blacklist duration settings: n n
For clients that are blacklisted due to authentication failure. By default, this is set to 0 (the client is blacklisted indefinitely).
For clients that are blacklisted due to other reasons, including manual blacklisting. By default, this is set to
3600 seconds (one hour). You can set this to 0 to blacklist clients indefinitely.
To configure the blacklist duration via the WebUI:
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. Select either AP Group or AP Specific tab. Click Edit for the AP group or AP name.
3. In the Profiles list, select Wireless LAN , then Virtual AP . Select the virtual AP instance.
l l
To set a blacklist duration for authentication failure, enter a value for Authentication Failure
Blacklist Time .
To set a blacklist duration for other reasons, enter a value for Blacklist Time .
4. Click Apply .
To configure the blacklist duration via the command-line interface, access the CLI in config mode and issue the following commands: wlan virtual-ap < profile>
auth-failure-blacklist-time < seconds>
blacklist-time < seconds>
ArubaOS 6.5.3.x
| User Guide Wireless Intrusion Prevention | 507
Removing a Client from Blacklisting
You can manually remove a client from blacklisting using either the WebUI or CLI:
To remove a client from blacklisting via the WebUI:
1. Navigate to the Monitoring > Controller > Blacklist Clients page.
2. Select the client that you want to remove from the blacklist, then click Remove from Blacklist .
To remove a client from blacklisting via the command-line interface, access the CLI in enable mode and issue the following command: stm remove-blacklist-client < macaddr>
Working with WIP Advanced Features
Device Classification is the first step in securing the corporate environment from unauthorized wireless access.
Adequate measures that quickly shut down intrusions are critical in protecting sensitive information and network resources. APs and stations must be accurately classified to determine whether they are valid, rogue, or a neighboring AP. Then, an automated response can be implemented to prevent possible intrusion attempts.
TotalWatch™ allows for detecting devices that are running on typical operational channels. Tarpit Shielding provides a better way of containing devices that are deemed unauthorized. Both of these features are discussed in the sections that follow.
n n n n
Configuring TotalWatch on page 508
Administering TotalWatch on page 510
Tarpit Shielding Overview on page 511
Configuring Tarpit Shielding on page 512
Configuring TotalWatch
Aruba 802.11n APs and non-11n APs in AM-mode support for TotalWatch is the ability to scan all channels of the RF spectrum, including 2.4-and 5-GHz bands as well as the 4.9-GHz public safety band. TotalWatch also provides 5-MHz granular channel scanning of bands for rogue devices and dynamic scanning dwell times to focus on those channels with traffic. TotalWatch provides an advanced set of features to detect unauthorized wireless devices and a set of customized rules are used to highlight devices that truly pose a threat to the network.
TotalWatch is supported on APs deployed in the AM-mode only.
TotalWatch provides monitoring support for the entire WLAN spectrum. Aruba APs in the AM-mode can monitor the following frequencies: n n
2412MHz to 2472MHz in the 2.5GHz band
5100Mhz to 5895MHz in the 5GHz band.
Aruba APs in AM-mode can scan the following additional frequencies: n n
2484 MHz and 4900Mhz to 5000MHz (J-channels)
5000 to 5100Mhz
If the AP is HT-capable (High Throughput), these frequencies are scanned in the 40MHz mode.
508 | Wireless Intrusion Prevention ArubaOS 6.5.3.x | User Guide
Understanding TotalWatch Channel Types and Qualifiers
Based on the regulatory characteristics, channels are categorized into the following types: n n n
Reg-domain Channels : A channel that belongs to the regulatory domain of the country in which the AP is deployed. The set of channels that belong to this group is a subset of the channels in the all-reg-domain channel group.
All-reg-domain Channels : A valid non-overlapping channel that is in the regulatory domain of at least one country. The channels in this category belong in the frequency ranges of: l l
2412MHz to 2472MHz in the g-band
5100Mhz to 5895MHz in the a-band.
Rare Channel : Channels that fall into a frequency range outside of the regulatory domain; 2484 MHz and
4900MHz-4995MHz (J-channels), and 5000-5100Mhz. The channels in this group do not belong to any other group.
Each of these channel types can have an associated qualifier: n n
Active Channel : This qualifier indicates that wireless activity is detected on this channel by the presence of an AP or other 802.11 activity such as a probe request.
DOS Channel : A channel where wireless containment is active. This channel should belong to the countrycode channel (regulatory domain).
Understanding TotalWatch Monitoring Features
TotalWatch enables monitoring of all channels including regulatory domain and rare channels. You can select one of the following scanning modes for each radio AP: n n n scan only the channels that belong to the AP’s regulatory domain scan channels that belong to all regulatory domains scan all channels
Understanding TotalWatch Scanning Spectrum Features
TotalWatch scans the following frequencies.
n n n
G-band—2412MHz to 2472MHz
J-band—2484 MHz and 4900-4995MHz
A-band—5000-5100Mhz to 5895MHz
list the frequency-to-channel mapping used by TotalWatch.
Table 118: Frequency to Channel Mapping
Frequency Channel
2412 – 2472MHz (in increments of 5MHz) 1 - 13
2484MHz 14
5100 – 5895MHz (in increments of 5MHz) 20 - 179
4900 – 4995MHz (in increments of 5MHz) 180 - 199
5000 – 5100MHz 200 - 219
ArubaOS 6.5.3.x
| User Guide Wireless Intrusion Prevention | 509
Understanding TotalWatch Channel Dwell Time
When an AP (in am-mode) visits a channel, the amount of time the AP stays on that channel is known as the dwell time . The channel dwell time is a variable value based on the following channel types.
n n n n dwell-time-active-channel : For channels where there is wireless activity. Default setting is 500 ms.
dwell-time-reg-domain channel : For channels that belong to the AP’s regulatory domain group (regdomain) with no wireless activity. The default setting is 250 ms.
dwell-time-other-reg-domain-channel : For channels that belong to the all regulatory domain group (allreg-domain) with no wireless activity The default setting is 250 ms.
dwell-time-rare-channel : For channels in the rare group where no wireless activity is detected. The default value is 100 ms.
Use the rf am-scan-profile command to set the dwell time and scan mode.
Understanding TotalWatch Channel Visiting
The Active and DOS channels are visited more frequently than the other channels. The order of preference in selecting the next channel is:
1. DOS
2. Active
3. reg-domain
4. All-reg-domain
5. Rare
Once a channel is selected, the dwell time for that channel is determined based on the channel type. At the end of the dwell time, a new channel is picked.
n n
Understanding TotalWatch Age out of Devices
ArubaOS uses a combination of inactivity time and unseen time to age out a device. This ensures that the channel is scanned a sufficient number of times before a device ages out. AM module maintains the following parameters: n n
Discovered Time : The absolute time, in seconds, since the device was discovered.
Monitored Time : The number of times the channel was scanned since discovery.
Inactivity Time : The number of times the device was not “seen” when the channel is scanned.
Unseen Time : The absolute time, in seconds, since the device was last “seen.”
Administering TotalWatch
The AM module will initialize the channel list for each of the AP’s radio based on the scan mode setting for the radio. For example, if scan mode is set to rare, then the channel list will contain all possible channels. You can view these channels by using the show ap arm scan-times command.
Configuring Per Radio Settings
For each radio, you can configure the following settings (for detailed information on commands, refer to the
ArubaOS 6.5.3.x Command Line Reference Guide ): n n the dwell times for the various channel types the channel list that should be used for scanning
510 | Wireless Intrusion Prevention ArubaOS 6.5.3.x | User Guide
These settings are configured via the command rfam-scan-profile , which can be attached to the two profiles, dot11a-radio-profile and dot11g-radio-profile .
The am-scan-profile includes the following parameters that can be configured: rf am-scan-profile <name> scan-mode [reg-domain | all-reg-domain | rare]
The default setting is the all-reg-domain. This is consistent with the default functioning of the AM scanning where the radio scans channels belonging to all regulatory domains.
Configuring Per AP Setting
If the AP is a dual-band single radio AP, an option is available to specify which band should be used for scanning in AM-mode. This setting is available in the ap system-profile , via the am-scan-rf-band command.
ap system-profile <name> am-scan-rf-band [a | g | all]
The default value is “all”, which is consistent with the prior behavior. This setting is ignored in the case of a dual radio AP.
There are four parameters that will control the age out of devices in the AM module.
ids general-profile <name> ap-inactivity-timeout sta-inactivity-timeout ap-max-unseen-timeout sta-max-unseen-timeout
The inactivity timeout is the number of times the device was not “seen” when the channel was scanned. The unseen timeout is the time, in seconds, since the device was last “seen.”
The show ap monitor scan-info/channel commands provide details of the channel types, dwell times, and the channel visit sequence.
(host) # show ap monitor scan-info ap-name rb-121
Licensing
The ability to perform rare scanning is available only with the RFprotect license. However, the AP can scan ‘regdomain’ or ‘all-reg-domain’ channels without the RFprotect license.
Tarpit Shielding Overview
The Tarpit Shielding feature is a type of wireless containment. Detected devices that are classified as rogues are contained by forcing client association to a fake channel or BSSID. This method of tarpitting is more efficient than rogue containment via repeated de-authorization requests. Tarpit Sheilding works by spoofing frames from an AP to confuse a client about its association. The confused client assumes it is associated to the AP on a different (fake) channel than the channel that the AP is actually operating on, and will attempt to communicate with the AP in the fake channel.
Tarpit Shielding works in conjunction with the deauth wireless containment mechanism. The deauth mechanism triggers the client to generate probe request and subsequent association request frames. The AP then responds with probe response and association response frames. Once the monitoring AP sees these frames, it will spoof the probe-response and association response frames, and manipulates the content of the frames to confuse the client.
A station is determined to be in the Tarpit when we see it sending data frames in the fake channel. With some clients, the station remains in tarpit state until the user manually disables and re-enables the wireless interface.
ArubaOS 6.5.3.x
| User Guide Wireless Intrusion Prevention | 511
Configuring Tarpit Shielding
Tarpit shielding is configured on an AP using one of two methods: n n
Disable all clients : In this method, any client that attempts to associate with an AP marked for containment is sent spoofed frames.
Disable non-valid clients : In this method, only non-authorized clients that attempt to associate with an
AP are sent to the tarpit.
The choices for disabling Tarpit Shielding on an AP are: n n n
Deauth-wireless-containment
Deauth-wireless-containment with tarpit-shielding (excluding-valid-clients)
Deauth-wireless-containment with tarpit-shielding
Enabling Tarpit Shielding
Use the ids-general-profile command to configure Tarpit Shielding (for detailed information on commands refer to the ArubaOS Command Line Reference Guide ).
ids general-profile default wireless-containment [deauth-only | none | tarpit-all-sta | tarpit-non-valid-sta]
Use the following show commands to view updated Tarpit Shielding status and the spoofed frames generated for an AP: show ap monitor stats … show ap monitor containment-info
Understanding Tarpit Shielding Licensing CLI Commands
Under the ids general-profile default wireless-containment command, the ‘tarpit-non-valid-sta’ and
‘tarpit-all-sta’ options are available only with a RFprotect license. The ‘deauth-only’ and ‘none’ options are available with the Base OS license.
512 | Wireless Intrusion Prevention ArubaOS 6.5.3.x | User Guide
Chapter 22
Access Points
n n n n n n n n n n
In ArubaOS, related configuration parameters are grouped into profiles that you can apply as needed to an AP group or to individual APs. When an AP is first installed on the network and powered on, the AP locates its host controller and the AP’s designated configuration is “pushed” from the controller to the AP. This chapter gives an overview of the basic function of each AP profile, and describes the process to install and configure the APs on your network.
The following topics are included in this chapter: n n n n n n n n n n
Important Points to Remember on page 513
AP Discovery Logic on page 514
Basic Functions and Features on page 527
Understanding AP Configuration Profiles on page 530
Before you Deploy an AP on page 537
Enable Controller Discovery on page 537
Enable DHCP to Provide APs with IP Addresses
Enable Controller Discovery on page 537
Configuring Installed APs on page 542
Optional AP Configuration Settings on page 547
Configuring AP Image Preload on page 860
Optimizing APs Over Low-Speed Links on page 577
AP Scanning Optimization on page 585
Configuring AP Channel Assignments on page 588
Managing AP Console Settings on page 590
Link Aggregation Support on 220 Series, 270 Series, 320 Series, and 330 Series on page 593
Recording Consolidated AP-Provisioned Information on page 596
Intelligent Power Monitoring on page 598
Important Points to Remember
If you modify the configuration of an AP, those changes take effect immediately; you do not need to reboot the controller or the AP for the changes to affect the current running configuration. Certain commands, however, automatically force the AP radio to restart.
AP Settings Triggering a Radio Restart
Changing the following settings triggers the radio to restart on the 200 Series, AP-203H, 203R Series, AP-205H,
210 Series, 220 Series, AP-228, 270 Series, 300 Series, AP-303H, 310 Series, 320 Series, 330 Series, or 360
Series access points. When the radio restarts, wireless services will be briefly interrupted. Clients will automatically reconnect to the network when the radio is again up and running.
ArubaOS 6.5.3.x
| User Guide Access Points | 513
Table 119: Profile Settings in ArubaOS 6.5.x
Profile
802.11a/802.11g Radio Profile
Settings
Virtual AP Profile
SSID Profile
High-throughput SSID Profile
802.11r Profile
Hotspot 2.0 Profile n n n n n n n n n n n
Channel
Enable Channel Switch Announcement (CSA)
CSA Count
High throughput enable (radio)
Very high throughput enable (radio)
TurboQAM enable
Maximum distance (outdoor mesh setting)
Transmit EIRP
Advertise 802.11h Capabilities
Beacon Period/Beacon Regulate
Advertise 802.11d Capabilities n n n
Virtual AP enable
Forward Mode
Remote-AP operation n n n n n n n
ESSID
Encryption
Enable Management Frame Protection
Require Management Frame Protection
Multiple Tx Replay Counters
Strict Spectralink Voice Protocol (SVP)
Wireless Multimedia (WMM) settings l l
Wireless Multimedia (WMM)
Wireless Multimedia U-APSD (WMM-UAPSD) Powersave l l l l l l
WMM TSPEC Min Inactivity Interval
Override DSCP mappings for WMM clients
DSCP mapping for WMM voice AC
DSCP mapping for WMM video AC
DSCP mapping for WMM best-effort AC
DSCP mapping for WMM background AC n n n n
High throughput enable (SSID)
40 MHz channel usage
Very High throughput enable (SSID)
80 MHz channel usage (VHT) n n n n
Advertise 802.11r Capability
802.11r Mobility Domain ID
802.11r R1 Key Duration key-assignment (CLI only) n n n
Advertise Hotspot 2.0 Capability
RADIUS Chargeable User Identity (RFC4372)
RADIUS Location Data (RFC5580)
AP Discovery Logic
In the ArubaOS 6.5.1.x and earlier release trains, APs are predefined as either controller-based campus APs or controller-less Instant APs. Each campus AP is shipped with the ArubaOS manufacturing image and must connect to a controller in order to receive configurations. Campus APs can only run the ArubaOS image and cannot be converted into Instant APs. Each Instant AP is shipped with the Instant manufacturing image and must join an IAP cluster in order to receive configurations from a virtual controller. Instant APs run the Instant image and can also be converted into campus APs.
514 | Access Points ArubaOS 6.5.3.x | User Guide
Starting with ArubaOS 6.5.2.0, select APs can run in both controller-based mode and controller-less mode.
Based on the selected mode, the AP runs a different image: n n
Controller-based APs run an ArubaOS image.
Controller-less APs run an Instant image.
The following APs support both controller-based mode and controller-less mode: n n n n n n n n
203H Series access points
203R/203RP Series access points
303H Series access points
AP-365 and AP-367 access points
Each AP is shipped with a manufacturing image or an Instant image. When the AP is booted up with the manufacturing image, it enters the controller and Instant discovery process to determine if it will be upgraded to the controller-based mode (ArubaOS image) or controller-less mode (Instant image). After the controller,
Instant virtual controller (VC), or Activate/AirWave/Central is discovered, the AP image is upgraded accordingly.
By default, controller discovery has a higher priority than Instant discovery. APs can discover the IP address of a controller through one of the following methods. See
Enable Controller Discovery on page 537
for more details on the different controller discovery options.
Static controller discovery
Aruba Discovery Protocol (ADP)
DHCP server
DNS server
APs can support up to 12 controller IP addresses via DHCP/DNS discovery. APs attempt to connect to each controller
10 times before switching to the next controller.
An AP can only be converted into a controller-based AP if the controller to which it connects is running ArubaOS
6.5.2.0.
If the AP cannot locate any controllers during the controller discovery process, it enters Instant discovery.
Preference Role
Users can predefine the AP mode by configuring the preference role. APs with the default preference role follow the standard discovery logic by attempting controller discovery before initiating Instant discovery. APs with the controller-less preference role bypass controller discovery and immediately initiate Instant discovery.
In the WebUI
To set the AP preference role to controller-less in the WebUI:
1. Navigate to Maintenance > WLAN > Convert to Instant Mode in the WebUI.
2. Select the AP(s) on which you want to set the preference role to controller-less.
3. Click Convert to IAP .
In the CLI
To set the AP preference role to controller-less in the CLI, execute the following commands:
(host) #ap redeploy controller-less all ap-group ap-name ip-addr
ArubaOS 6.5.3.x
| User Guide Access Points | 515
ip6-addr wired-mac
AP Deployment Policy
Starting with ArubaOS 6.5.3.0, users can predefine the AP mode using the AP deployment policy. The
AP deployment policy redirects all APs in the specified IP address ranges to the Instant discovery process, ensuring that the APs run only in controller-less mode. This policy is enforced each time an AP in the specified
IPv4 or IPv6 address range connects to a controller and upgrades to the ArubaOS image. The controller automatically identifies the targeted AP, rejects the AP termination, and redirects the AP to upgrade to controller-less mode.
Users can define up to 128 IPv4 and IPv6 address ranges for the AP deployment policy.
In the CLI
To apply the AP deployment policy to the default AP group, execute the following commands:
(host) (config) #ap deploy-profile
(host) (ap deploy-profile) #default-ap-group
To apply the AP deployment policy to an IPv4 address range, execute the following commands:
(host) (config) #ap deploy-profile
(host) (ap deploy-profile) #ip-range <start> <end>
To apply the AP deployment policy to an IPv6 address range, execute the following commands:
(host) (config) #ap deploy-profile
(host) (ap deploy-profile) #ipv6-range <start> <end>
To remove the IP address range or default AP group from the profile, execute the following command:
(host) (config) #no ap deploy-profile
To view the complete list of IP address ranges to which the AP deployment policy is applied, execute the following command:
(host) #show ap deploy-profile
Discovery Logic Workflow
The following steps describe the AP discovery logic:
516 | Access Points ArubaOS 6.5.3.x | User Guide
Figure 68 AP Discovery Logic
1. The AP boots up with the manufacturing image in unprovisioned mode.
2. The AP enters the controller discovery process using static/DHCP/ADP/DNS based controller discovery. If the preference role is set to controller-less, the AP bypasses controller discovery and immediately enters
Instant discovery (skip to
).
n n n
If a controller is discovered, the AP receives the controller’s IP address or domain assignment. The AP connects to the controller and downloads the ArubaOS image. After the image is downloaded, the AP reboots. The configuration syncs, and the AP runs in controller-based mode.
If a controller is discovered, but the AP deployment policy is applied to this AP, the AP connects to the controller and downloads the ArubaOS image. The controller rejects the AP termination and redirects the
AP to the Instant discovery process.
If the AP cannot locate any controllers (for example, if the controller is powered off or becomes unreachable), it enters Instant discovery.
3. The AP enters the Instant discovery process to locate an Instant VC, Activate, AirWave, or Central.
n
If a VC is discovered, the AP joins the existing IAP cluster and downloads the Instant image from the cluster. After the image is downloaded, the AP reboots. The configuration syncs, and the AP runs in controller-less mode.
n
If the AP cannot locate a VC in an existing IAP cluster, the AP attempts to locate Activate, AirWave, or
Central to upgrade the image and form a new IAP cluster.
APs running the manufacturing image cannot form an IAP cluster.
ArubaOS 6.5.3.x
| User Guide Access Points | 517
n
If the AP locates Activate, it receives pre-configured provisioning rules to connect to AirWave/Central or convert into a campus AP (CAP) or remote AP (RAP).
APs that connect to Activate are automatically upgraded from the manufacturing image to the latest
Instant/ArubaOS image. Refer to the latest Aruba Activate User Guide for details on configuring provisioning rules.
n
If the AP locates AirWave, it can be upgraded to the Instant image. If an enforced image upgrade rule is configured in AirWave, the AP is upgraded to the Instant image configured for the enforced upgrade rule. If no enforced upgrade rule is configured, the AP is upgraded to the latest Instant image in AirWave. After the AP is upgraded, it reboots in controller-less mode and forms a new IAP cluster.
The AP converts into the master, and other un-deployed APs can join the cluster to upgrade to the
Instant image. Refer to the latest AirWave 8.x User Guid e for details on AP image upgrade.
All firmware must be uploaded to AirWave before the AP connects and downloads the Instant image. Refer to the latest AirWave 8.x Aruba Instant Deployment Guide for details on firmware upload.
n
If the AP locates Central, it can be upgraded to the Instant image through the Maintenance >
Firmware page in the Central WebUI. After the AP is upgraded, it reboots in controller-less mode and forms a new IAP cluster. The AP converts into the master, and other un-deployed APs can join the cluster to upgrade to the Instant image. Refer to the latest Aruba Central User Guide for more details on AP image upgrade.
Central syncs with Aruba Activate to retrieve the latest Instant image.
n
If the AP cannot locate Activate, AirWave, or Central, it continues to run in unprovisioned mode until the image is upgraded.
If the AP is not upgraded to the ArubaOS or Instant image, it enters a 15 minute reboot period. If there is no keyboard input or WebUI session (manual upgrade) within the 15 minutes, the AP reboots.
Manual Upgrade
APs running in unprovisioned mode broadcast a special provisioning SSID to which users can connect to upgrade the AP manually. Upon connecting, users can access a local provisioning page in the WebUI to upgrade the AP to an ArubaOS or Instant image. See
Controller-based AP via Manual CAP/RAP Conversion on page 521
and
Controller-less AP via Manual IAP Conversion on page 523
for more details on upgrading APs manually.
Deployment Scenarios
This section describes various AP deployment scenarios in controller, Instant, remote, and hybrid networks.
Controller-based AP Deployments
The following sections describe controller-based AP deployment scenarios.
Controllers and APs are deployed in the same Layer 2 subnet.
Controller-based AP with AP Console Access
Users can deploy controller-based APs with console access, which allows them to modify the AP’s provisioning settings through a direct console connection to the AP. This deployment scenario is typically used for troubleshooting in development/test networks and master controller assignment for static controller
518 | Access Points ArubaOS 6.5.3.x | User Guide
discovery. See
Managing AP Console Settings on page 590
for more information on provisioning APs through a console connection.
To deploy a controller-based AP using an AP console connection:
1. Establish a console connection to the AP. See
Managing AP Console Settings on page 590
for more details.
2. To access the AP console command prompt, press Enter when the AP displays the “Hit <Enter> to stop autoboot” message.
3. Enter the AP console password.
4. Execute one of the following APBoot commands to assign an IP address from which the AP can download the ArubaOS image: n setenv serverip <ipaddr> : IP address of a TFTP server.
a. (Optional) To upgrade the image directly in partition <n> from <file> , execute the os [<n>] <file> command.
b. After the server IP address is assigned, enter saveenv to save your settings.
c. Reboot the AP using the boot or tftpboot command. The AP boots up with the ArubaOS image.
n setenv master <ipaddr> : IP address of a master controller. This option is used for static controller discovery.
a. After the master controller is assigned, enter saveenv to save your settings.
b. Reboot the AP using the boot command. The AP boots up with the manufacturing image.
c. The AP enters the static controller discovery process.
d. If the assigned master controller is discovered, the AP connects to the controller and downloads the
ArubaOS image.
e. After the image is downloaded, the AP reboots.
f. The configuration syncs, and the AP runs in controller-based mode.
Controller-based AP in a Test Network
Users can provision controller-based APs in a test network before deploying the APs in a working network.
Controllers in a test network can only be discovered using the Aruba Discovery Protocol (ADP).
APs are upgraded to the ArubaOS image via ADP through the following steps:
1. The AP boots up with the manufacturing image in unprovisioned mode.
2. The AP enters the controller discovery process using ADP.
3. When a controller is discovered, the AP connects to the controller and downloads the ArubaOS image.
n
If the AP cannot locate a controller, it enters the Instant discovery process. To prevent the AP from upgrading to controller-less mode, you must make sure Instant VCs, Activate, AirWave, and Central are not available to the AP. If the AP is not upgraded and there are no configuration changes with 15 minutes, the AP reboots and restarts the discovery process (
).
4. After the image is downloaded, the AP reboots.
5. The configuration syncs, and the AP runs in controller-based mode.
Controller-based AP in a New Controller-based Network
Users can deploy APs directly into a brand new controller-based network. APs are upgraded to the ArubaOS image using static/ADP/DHCP/DNS based controller discovery. See
Enable Controller Discovery on page 537
for more details on the different controller discovery options.
APs are upgraded to the ArubaOS image via DHCP/DNS through the following steps:
ArubaOS 6.5.3.x
| User Guide Access Points | 519
1. The AP boots up with the manufacturing image in unprovisioned mode.
2. The AP enters the controller discovery process using DHCP/DNS.
3. When a controller is discovered, the AP connects to the controller and downloads the ArubaOS image.
n
APs attempt to connect to each controller 10 times. If the AP fails to reach a controller after 10 attempts, it reboots and restarts the discovery process (
).
4. After the image is downloaded, the AP reboots.
5. The configuration syncs, and the AP runs in controller-based mode.
See
Controller-based AP in a Test Network on page 519
for details on ADP-based controller discovery.
Controller-based AP in an Existing Controller-based Network
Users can replace or add additional APs to existing controller-based networks. Newly deployed APs are be upgraded to the ArubaOS image using static/ADP/DHCP/DNS based controller discovery. See
for more details on the different controller discovery options.
See
Controller-based AP in a Test Network on page 519
for details on ADP-based controller discovery. See
Controller-based AP in a New Controller-based Network on page 519
for details on DHCP/DNS based controller discovery.
Controller-based AP in a Remote Deployment
Users can deploy controller-based APs in remote networks. APs in remote locations (remote APs) connect to the Aruba controller over the Internet using Extended Authentication (XAuth) and Internet Protocol Security
(IPsec). See
Remote Access Points on page 701
for more information on remote APs.
To deploy a controller-based AP in a remote site:
1. Login to the controller to add the AP to the controller’s remote AP whitelist. See
Managing AP Whitelists on page 57
for more details on adding APs to a remote AP whitelist.
2. Place the AP in a remote site. The AP boots up with the manufacturing image in unprovisioned mode.
3. On your device, connect to the following provisioning SSID broadcasted by the unprovisioned AP:
SetMeUp-xx:xx:xx
4. Open a web browser, and then navigate to the following URL: https://setmeup.arubanetworks.com
5. Under Convert to , select RAP .
6. Enter the IP address or host name of the controller to which the remote AP will be connected.
7. Click Save .
After the image is downloaded from the controller, the AP reboots. The configuration syncs, and the AP becomes a RAP.
APs can also be converted into RAPs using Aruba Activate. For more details, see
.
Controller-based AP via Aruba Activate
If the AP cannot locate any controllers during the controller discovery process, the AP enters Instant discovery.
During the Instant discovery process, the AP attempts to connect through Activate if it cannot locate an Instant
VC. If Activate is provisioned to convert APs to controller-based CAPs/RAPs, any AP that connects to Activate is converted into a CAP or RAP. Refer to the latest Aruba Activate User Guide for details on configuring provisioning rules.
APs are upgraded to the ArubaOS image via Activate through the following steps:
1. The AP boots up with the manufacturing image in unprovisioned mode.
520 | Access Points ArubaOS 6.5.3.x | User Guide
2. The AP enters the controller discovery process using static/DHCP/ADP/DNS based controller discovery.
3. If the AP cannot locate any controllers, it enters the Instant discovery process to locate an Instant VC,
Activate, AirWave, or Central.
4. The AP attempts to locate a VC in an existing IAP cluster. If the AP cannot locate any VCs, it attempts to connect through Activate.
5. If the AP connects to Activate, it checks for provisioning rules to convert into a CAP or RAP.
APs that connect to Activate are automatically upgraded from the manufacturing image to the latest ArubaOS image.
Refer to the latest Aruba Activate User Guide for details on configuring provisioning rules.
n n
If the AP converts into a CAP, it retrieves the IP address of the master controller. The AP connects to the master controller and downloads the ArubaOS image. After the image is downloaded, the AP reboots.
The configuration syncs, and the AP becomes a CAP.
If the AP converts into a RAP, it retrieves the IP address of a controller that has included the AP in its remote AP whitelist. The AP connects to the controller through an IPsec tunnel and downloads the
ArubaOS image. After the image is downloaded, the AP reboots. The configuration syncs, and the AP becomes a RAP. For more information on remote APs, see
Remote Access Points on page 701 .
The AP must be added to the controller's remote AP whitelist before it can retrieve the IP address of the controller.
For more details on adding APs to a remote AP whitelist, see
Managing AP Whitelists on page 57
.
Controller-based AP via Manual CAP/RAP Conversion
If the AP cannot be converted into a campus AP or remote AP through Activate, users can connect to a special provisioning SSID broadcasted by the unprovisioned AP to manually convert the AP to a CAP or RAP through the WebUI. See
Controller-based AP via Aruba Activate on page 520
for details on converting an AP into a CAP or RAP through Activate.
To manually convert an AP to a CAP or RAP in the WebUI:
1. On your device, connect to the following provisioning SSID broadcasted by the unprovisioned AP:
SetMeUp-xx:xx:xx
2. Open a web browser. You will automatically be redirected to a special provisioning page in the WebUI to convert the AP.
3. Under Convert to, select CAP or RAP .
4. Enter the IP address or host name of the controller to which the remote AP or campus AP will be connected.
5. Click Save .
After the AP is upgraded, it reboots as a CAP or RAP.
Controller-less AP Deployments
The following sections describe controller-less AP deployment scenarios.
Controller-less AP in an Instant Network
Users can deploy APs directly into a running Instant network, which is comprised of an IAP cluster and a virtual controller that manages the network. A virtual controller must be available before any AP can be upgraded through this deployment scenario. See Customizing IAP Settings > Master Election and Virtual
Controller in the latest Aruba Instant User Guide for more details on electing a master in an Instant network.
APs are upgraded to the Instant image via a virtual controller through the following steps:
1. The AP boots up with the manufacturing image in unprovisioned mode.
2. The AP enters the controller discovery process using static/DHCP/ADP/DNS based controller discovery.
ArubaOS 6.5.3.x
| User Guide Access Points | 521
n
If the preference role is set to controller-less, the AP bypasses controller discovery and immediately enters Instant discovery (skip to
n
If a controller is discovered, but the AP deployment policy is applied to this AP, the AP connects to the controller and downloads the ArubaOS image. The controller rejects the AP termination and redirects the
AP to the Instant discovery process.
3. If the AP cannot locate any controllers, it enters the Instant discovery process to locate an Instant VC,
Activate, AirWave, or Central.
4. The AP attempts to discover a VC in an existing IAP cluster.
5. If a VC is discovered, the AP joins the existing IAP cluster and downloads the Instant image from the cluster.
6. After the image is downloaded, the AP reboots.
7. The configuration syncs, and the AP runs in controller-less mode.
Controller-less AP via Activate, AirWave, or Central
If the AP cannot locate a virtual controller in an existing IAP cluster, the AP attempts to connect to Activate,
AirWave, or Central to upgrade the AP to the Instant image and form a new IAP cluster.
In this deployment scenario, Activate, AirWave, or Central must be accessible to the AP.
APs are upgraded to the Instant image via Activate, AirWave, or Central through the following steps:
1. The AP boots up with the manufacturing image in unprovisioned mode.
2. The AP enters the controller discovery process using static/DHCP/ADP/DNS based controller discovery.
n
If the preference role is set to controller-less , the AP bypasses controller discovery and immediately enters Instant discovery (skip to
n
If a controller is discovered, but the AP deployment policy is applied to this AP, the AP connects to the controller and downloads the ArubaOS image. The controller rejects the AP termination and redirects the
AP to the Instant discovery process.
3. If the AP cannot locate any controllers, it enters the Instant discovery process to locate an Instant VC,
Activate, AirWave, or Central.
4. The AP attempts to discover a VC in an existing IAP cluster.
5. If the AP cannot locate a VC in an existing IAP cluster, the AP attempts to locate Activate, AirWave, or Central to upgrade the image and form a new IAP cluster.
APs running the manufacturing image cannot form an IAP cluster.
n
If the AP locates Activate, it receives pre-configured provisioning rules to connect to AirWave/Central or convert into a campus AP (CAP) or remote AP (RAP).
APs that connect to Activate are automatically upgraded from the manufacturing image to the latest
Instant/ArubaOS image. Refer to the latest Aruba Activate User Guide for more details on configuring provisioning rules.
n
If the AP locates AirWave, it can be upgraded to the Instant image. If an enforced image upgrade rule is configured in AirWave, the AP is upgraded to the Instant image configured for the enforced upgrade rule. If no enforced upgrade rule is configured, the AP is upgraded to the latest Instant image in AirWave.
After the AP is upgraded, it reboots in controller-less mode. Refer to the latest AirWave 8.x User Guid e for details on AP image upgrade.
522 | Access Points ArubaOS 6.5.3.x | User Guide
All firmware must be uploaded to AirWave before the AP connects and downloads the Instant image. Refer to the latest AirWave 8.x Aruba Instant Deployment Guide for details on firmware upload.
n
If the AP locates Central, it can be upgraded to the Instant image through the Maintenance >
Firmware page in the Central WebUI. After the AP is upgraded, it reboots in controller-less mode. Refer to the latest Aruba Central User Guide for more details on AP image upgrade.
Central syncs with Aruba Activate to retrieve the latest Instant image.
After the AP is upgraded to controller-less mode, it forms a new IAP cluster and converts into the master. Other un-deployed APs can join the cluster and upgrade to the Instant image.
Controller-less AP via Manual IAP Conversion
If the AP cannot be upgraded into an IAP through a virtual controller, Activate, AirWave, or Central, users can connect to a special provisioning SSID broadcasted by the unprovisioned AP to manually convert the AP to an
IAP through the WebUI. See
Controller-less AP in an Instant Network on page 521
and
Activate, AirWave, or Central on page 522
for details on upgrading an AP to the Instant image using a VC,
Activate, AirWave, or Central.
To manually convert an AP to an IAP in the WebUI:
1. Login to your virtual controller.
2. Connect to the following provisioning SSID broadcasted by the unprovisioned AP:
SetMeUp-xx:xx:xx
3. Open a web browser. You will automatically be redirected to a special provisioning page in the WebUI to convert the AP.
4. Under Access Point Setup , select Image File or Image URL to upload the Instant image.
n
If you select Image File , click Browse to locate and select an Instant image file from your local file explorer.
n
If you select Image URL , enter the web address of the Instant image under URL .
5. Click Save .
After the AP is upgraded, it reboots in controller-less mode.
AP Deployments in Hybrid Controller-Instant Networks
Users can deploy APs into hybrid networks, which contain both controller-based and controller-less APs. APs in hybrid networks are upgraded to the ArubaOS or Instant image using the same methods as APs in pure controller or Instant networks. However, the following items must be in place before deploying APs in a hybrid network: n n n
Controller-based APs and controller-less APs must run on different subnets (for example, a controller-based
AP subnet and a separate controller-less AP subnet).
Different discovery methods should be used for controller-based APs and controller-less APs, as the controller discovery process and Instant AirWave discovery process share the same DHCP/DNS discovery methods. For example, controller-based APs can use a DHCP server to discover a controller, while controllerless APs can use a DNS server on AirWave.
If the same discovery method must be used for both controller-based APs and controller-less APs, Aruba recommends that you use DHCP-based discovery. DHCP servers can respond to DHCP requests based on the AP’s subnet and vendor ID. DNS servers do not have a subnet limit, which can cause the APs that share a DNS server to be upgraded on the wrong AP subnet.
ArubaOS 6.5.3.x
| User Guide Access Points | 523
Troubleshooting the AP Discovery Logic
The following sections describe troubleshooting scenarios users may encounter in the AP discovery logic.
Identifying the controller discovery method
APs can obtain the IP address of a controller through one of the following methods: n n n n
Static controller discovery
Aruba Discovery Protocol (ADP)
DHCP server
DNS server
Execute the show log provision command on the AP to determine which controller discovery method was used to upgrade the AP to the ArubaOS image.
The AP is unable to upgrade to the ArubaOS image
There are several reasons why an AP may not be able to upgrade to the ArubaOS image, even when a controller is configured.
ADP is disabled
If the Aruba Discovery Protocol (ADP) is disabled on the controller, the AP will not be able to locate any controllers on its own. Execute the adp discovery enable command in the CLI to enable ADP.
The AP preference role is set to controller-less
If the AP preference role is set to controller-less, the AP bypasses controller discovery and immediately initiates
Instant discovery. Use one of the following methods to check if the AP preference role has been set to controller-less: n
Execute the apboot> printenv command on the AP console to view the current environment variable settings. The uap_controller_less field indicates if the preference role is set to controller-less: l l uap_controller_less=1 : The controller-less preference role is enabled.
uap_controller_less=0 : The controller-less preference role is disabled.
See
Managing AP Console Settings on page 590
for more details on APBoot commands.
n n
Check the boot up log from the AP console. If the preference role is set to controller-less, the “ADP is disabled by uap_controller_less” message appears.
Execute the show log provision command on the AP console to view the AP provisioning logs. If the preference role is set to controller-less, the “Controller discovery is disabled by ap-env uap_controller_less” message appears.
The AP is not factory default
If the AP is not set to factory default (manufacturing image in unprovisioned mode), it cannot enter the controller discovery process. Use one of the following methods to check if the AP is factory default: n n n
Check the boot up log from the AP console. If the AP is not factory default, the “Not factory_default ap. Do not run ADP.” message appears.
Execute the show log provision command on the AP. If the AP is not factory default, the “Controller discovery is disabled since UAP is not factory default status” message appears.
APs remain in unprovisioned mode after failing both controller and Instant discovery. If the AP is unable to upgrade to the ArubaOS or Instant image through the controller and Instant discovery process, it can be upgraded manually using the SetMeUp-xx:xx:xx provisioning SSID. Execute the show network command on the AP to check if the AP is connected to the SetMeUp-xx:xx:xx provisioning SSID. If the AP is connected to a different SSID, it is not factory default.
524 | Access Points ArubaOS 6.5.3.x | User Guide
The controller is not running the correct image version
An AP can only be converted into a controller-based AP if the controller to which it connects is running ArubaOS
6.5.2.0. Controllers that run a different version of ArubaOS do not support the AP discovery logic and cannot convert the AP to controller-based mode.
The AP is attempting to connect to a fake controller
If the AP fails to convert into a controller-based AP, the controller to which it attempted to connect may be fake. Execute the show log provision command on the controller to check if the AP failed to connect after 10 attempts.
FTP or TFTP permission is denied on the controller
In order to download the ArubaOS image from the controller, the AP must establish a File Transfer Protocol
(FTP) or Trivial File Transfer Protocol (TFTP) connection to the controller. If FTP or TFTP permission is denied on the controller, the connection attempt is dropped, and the AP cannot download the ArubaOS image.
Use one of the following methods to check if FTP or TFTP permission is denied on the controller: n n
Execute the show log upgrade command on the AP. If FTP or TFTP permission is denied, the AP fails to connect to the controller, and the following messages appear in the upgrade log: l
“Connecting to <controller IP address>… failed: Connection time out.” l l
“Error: failed to retrieve image”
“Info: try with tftp to download the image.”
Access controls can be applied to a controller port to filter traffic between the controller and the APs. Traffic must meet all criteria on the access control list (ACL) in order to reach the controller or AP. If it does not meet the criteria, the connection is dropped.
l l l l l l
Execute the show interface fastethernet <port> access-group command to view the ACLs that have been applied to the port.
Execute the show ip access-list <string> command on the controller to view the detailed configuration for the ACL that has been applied to the port.
Execute the interface fastethernet|gigabitethernet} <port> ip access-group <name>
{in|out|session {vlan <vlanID>}} command to apply an ACL to a port.
Execute the no interface {fastethernet|gigabitethernet} <port> ip access-group <name>
{in|out|session {vlan <vlanID>}} command to remove an ACL from a port.
Execute the ip access-list extended {<number>|<name>} deny <protocol> command to reject traffic for a specific protocol. If you reject traffic for the User Datagram Protocol (UDP), TFTP traffic is dropped. If you reject traffic for the Transmission Control Protocol (TCP), FTP traffic is dropped.
Execute the ip access-list extended {<number>|<name>} permit <protocol> command to allow traffic for a specific protocol. If you allow traffic for the User Datagram Protocol (UDP), TFTP traffic can reach the controller or AP. If you allow traffic for the Transmission Control Protocol (TCP), FTP traffic can reach the controller or AP.
The AP is unable to upgrade to the Instant image
If the AP is marked as CAP-only, it cannot be upgraded to the Instant image. CAP-only APs can only be upgraded to the ArubaOS image.
Execute the show log provision command on the AP to check if your AP is CAP-only. If your AP is CAP-only, the “CAP-only sku” message appears.
ArubaOS 6.5.3.x
| User Guide Access Points | 525
The SetMeUp provisioning SSID is not showing up on the device
The SetMeUp-xx:xx:xx provisioning SSID used for manual AP upgrade only appears on a device if an AP fails to upgrade to the ArubaOS or Instant image during the controller and Instant discovery process.
APs can support up to 12 controller IP addresses for ArubaOS image upgrade. During the controller discovery process, the AP attempts to connect to each controller 10 times until it reaches one successfully. Each connection attempt takes one minute. Depending on the number of controllers that are located by the AP, it can take up to 120 minutes just to complete the controller discovery process.
Execute the show log provision command on the AP to track the progress of the controller discovery process. The provisioning log displays the total number of controller IPv4 and IPv6 addresses that have been detected by the AP, and the current stage of the discovery process.
The AP does not reboot after an upgrade failure
If an AP fails to upgrade to the ArubaOS or Instant image during the controller and Instant discovery process, it enters a 15 minute reboot period. After the AP is rebooted, it restarts the discovery process. However, there are several conditions that can prevent the AP from completing the reboot: n n n n n
Keyboard input from the user.
WebUI session connected to the AP (manual image upgrade).
Pending image upgrade.
Discovery of an AMP server.
Discovery of a Central server.
Execute the show log provision command on the AP to determine why the AP has not rebooted. The provisioning log displays one of the following messages: n n n n n
"Could not reboot- upgrade is pending"
"Could not reboot- keyboard input"
"Could not reboot- airwave is found"
"Could not reboot- UI session"
"Could not reboot- central is found
The operational state of an AP ethernet port goes down while using a PoE injector
Sometimes, while using a PoE injector, the output of the show ap debug port status ap-name <ap-name> command indicates that the operational state of an Ethernet port is down.
(host) #show ap debug port status ap-name test-ap-225
AP "test-ap-225" Port Status
-----------------------------
Port MAC
------
0
Type
----
9c:1c:12:c0:ab:40 GE
Forward Mode
------------
N/A
Admin
----enabled
Oper
---up
Speed
-----
1 Gb/s
Duplex
-----full
802.3az
------disabled
PoE
---
N/A
1 9c:1c:12:c0:ab:41 GE tunnel enabled down N/A N/A N/A N/A
STP Portfast TX-Packets TX-Bytes RX-Packets RX-Bytes
------------------------------------------
N/A N/A
N/A N/A
69707
0
37468577
0
107570
0
11707191
0
Execute the following command to verify if the AP is powered up using an 802.3af Power Sourcing Equipment.
(host) #show ap debug system-status ap-name <ap-name> | include POE
Power Supply : POE-AF
526 | Access Points ArubaOS 6.5.3.x | User Guide
The power supply, POE-AF indicates that a pre-standard PoE injector is being used to power up the AP. This causes the operational state of the Ethernet port to go down. To resolve this issue, enable the ap2xxprestandard-poe-detection parameter from the respective provisioning profile of the AP:
(host) (config) #ap provisioning-profile <profile-name>
(host) (Provisioning profile "<profile-name>") #ap2xx-prestandard-poe-detection
This parameter is applicable only for the 200 Series, 210 Series, 220 Series, 270 Series, or 203R Series access points and AP-203H, AP-205H, or AP-228.
Accessing the CLI after an image upgrade
After the AP image is upgraded, users cannot access the CLI for the first 180 seconds of uptime. The following message appears when a user attempts to login to the CLI during the initial 180 second uptime period: login as: admin
System uptime is 147 seconds and CLI is not ready yet, please try again later.
Basic Functions and Features
You configure APs using the WebUI and the CLI on the controller.
lists the basic configuration functions and features.
Table 120: AP Configuration Function Overview
Features and
Function
Description
Wireless LANs A wireless LAN (WLAN) permits wireless clients to connect to the network. An AP broadcasts the SSID (which corresponds to a WLAN configured on the controller) to wireless clients. APs support multiple SSIDs. WLAN configuration includes the authentication method and the authentication servers by which wireless users are validated for access.
The WebUI includes a WLAN Wizard that provides easy-to-follow steps to configure a new
WLAN.
NOTE: All new WLANs are associated with the ap-group named “default”.
AP operation
Quality of
Service (QoS)
An AP can function as an AP that serves clients, as an air monitor (AM) performing network and radio frequency (RF) monitoring, or as a hybrid AP that serves both clients and performs spectrum analysis a single radio channel. You can also specify the regulatory domain (the country) which determines the 802.11 transmission spectrum in which the AP will operate. Within the regulated transmission spectrum, you can configure 802.11a,
802.11b/g, or 802.11n (high-throughput) radio settings.
NOTE: The 802.11n features, such as high-throughput and 40 MHz configuration settings, are supported on APs that are 802.11n standard compliant.
Configure Voice over IP call admission control options and bandwidth allocation for 5 GHz
(802.11a) or 2.4 GHz (802.11b/g) frequency bands of traffic.
ArubaOS 6.5.3.x
| User Guide Access Points | 527
Features and
Function
RF
Management
Intrusion
Detection
System
Mesh
Description
Configure settings for balancing wireless traffic across APs, detect holes in radio coverage, or other metrics that can indicate interference and potential problems on the wireless network.
Adaptive Radio Management (ARM) is an RF spectrum management technology that allows each AP to determine the best 802.11 channel and transmit power settings. ARM provides several configurable settings.
Configure settings to detect and disable rogue APs, ad-hoc networks, and unauthorized devices, and prevent attacks on the network. You can also configure signatures to detect and prevent intrusions and attacks.
Configure Aruba APs as mesh nodes to bridge multiple Ethernet LANs or extend wireless coverage. A mesh node is either n n a mesh portal: an AP that uses its wired interface to reach the controller a mesh point:an AP that establishes a path to the controller via the mesh portal
Mesh environments use a wireless backhaul to carry traffic between mesh nodes. This allows one 802.11 radio to carry traditional WLAN services to clients and one 802.11 radio to carry mesh traffic and WLAN services.
Secure Enterprise Mesh on page 600
contains more specific information on the Mesh feature.
Naming and Grouping APs
In the Aruba user-centric network, each AP has a unique name and belongs to an AP group.
Each AP is identified with an automatically-derived name. The default name depends on if the AP has been previously configured.
n n
The AP has not been configured—the name is the AP’s Ethernet MAC address in colon-separated hexadecimal digits.
Configured with a previous ArubaOS release—the name is in the format building.floor.location
You can assign a new name (up to 63 characters) to an AP; the new name must be unique within your network.
For example, you can rename an AP to reflect its physical location within your network, such as “building3lobby”.
Renaming an AP requires a reboot of the AP before the new name takes effect. Therefore, wait until there is little or no client traffic passing through the AP before renaming it.
An AP group is a set of APs to which the same configuration is applied. There is an AP group called “default” to which all APs discovered by the controller are assigned. By using the “default” AP group, you can configure features that are applied globally to all APs.
You can create additional AP groups and assign APs to that new group. However, an AP can belong to only one
AP group at a time. For example, you can create an AP group “Victoria” that consists of the APs that are installed in a company’s location in British Columbia. You can create another AP group “Toronto” that consists of the APs in Ontario. You can configure the “Toronto” AP group with different information from the APs in the
“Victoria” AP group (see
).
528 | Access Points ArubaOS 6.5.3.x | User Guide
Figure 69 AP Groups
While you can use an AP group to apply a feature to a set of APs, you can also configure a feature or option for a specific AP by referencing the AP’s name. Any options or values that you configure for a specific AP will override the same options or values configured for the AP group to which the AP belongs.
The following procedures describes how to create an AP group.
Reassigning an AP from an AP group requires a reboot of the AP for the new group assignment to take effect.
Therefore,wait until there is little or no client traffic passing through the AP before reassigning it.
Creating an AP group
You can use the WebUI or the CLI to create a new AP group.
In the WebUI
1. Navigate to the Configuration > Wireless> AP Configuration > AP Group page.
2. Click New . Enter the new AP group name and click Add . The new AP group appears in the Profile list.
In the CLI
Use the following command to create an AP group: ap-group <group>
When you create an AP group with the CLI, you can specify the virtual AP definitions and configuration profiles you want applied to the APs in the group.
Assigning APs to an AP Group
Although you will assign an AP to an AP group when you first deploy the device, you can assign an AP to a different AP group at any time.
Once the ap-regroup command is executed, the AP automatically reboots. If the AP is powered off or otherwise not connected to the network or controller, the executed command is queued until the AP is powered on or reconnected.
Again, the AP will automatically reboot as soon as the command is executed.
In the WebUI
1. Navigate to the Configuration > Wireless> AP Installation page. The list of discovered APs appears in this page (all discovered APs initially belong to the AP group named “default”).
2. Select the AP you want to reassign, and click Provision . From the Provisioning page, select the AP group from the drop-down menu.
ArubaOS 6.5.3.x
| User Guide Access Points | 529
3. Click Apply and Reboot .
In the CLI
Use the following command to assign a single AP to an existing AP group. Use the WebUI to assign multiple APs to an AP group at the same time.
ap-regroup {ap-name <name>|serial-num <number>|wired-mac <macaddr>} <group>
Understanding AP Configuration Profiles
An AP configuration profile is a general name to describe any of the different groups of settings that can defined, saved, and applied to an Access Point. ArubaOS has many different types of profiles that each allow you to configure a different aspect of an AP’s overall configuration. ArubaOS also contains a predefined
“default” profile for each profile type. You can use the predefined settings in these default profiles, or create entirely new profiles that you can edit as required.
n n n n
Each different AP configuration profile type can be managed using the CLI or the WebUI. To see a full list of available configuration profiles using the command-line interface, access the CLI and issue the command show profile-hierarchy . To view available configuration profiles using the WebUI, select the Configuration tab in the and navigate to Advanced Services > All Profiles .
The All Profiles tab arranges the different AP configuration profile types into the following categories: n n n n
The profile types that appear in the All Profiles tab may vary, depending upon the controller configuration and available licenses.
AP Profiles
The AP profiles configure AP operation parameters, radio settings, port operations, regulatory domain, and
SNMP information.
n n n
AP system profile : defines administrative options for the controller, including the IP addresses of the local, backup, and master controllers, Real-time Locating Systems (RTLS) server values and the number of consecutive missed heartbeats on a GRE tunnel before an AP reboots. For details on configuring this profile, see
Optional AP Configuration Settings .
Regulatory domain : defines the AP’s country code and valid channels for both legacy and highthroughput 802.11a and 802.11b/g radios. For examples on figuring a regulatory domain profile, see
Configuring AP Channel Assignments on page 588 .
Wired AP profile : determines if 802.11 frames are tunneled to the controller using Generic Routing
Encapsulation (GRE) tunnels, bridged into the local Ethernet LAN, or configured for a combination of the two (split-mode). In tunnel forwarding mode, the AP handles all 802.11 association requests and responses, but sends all 802.11 data packets, action frames and EAPOL frames over a GRE tunnel to the controller for processing. When a remote AP or campus AP is in bridge mode, the AP handles all 802.11 association
530 | Access Points ArubaOS 6.5.3.x | User Guide
n n n n n n n n requests and responses, encryption/decryption processes, and firewall enforcement. In split-tunnel mode,
802.11 frames are either tunneled or bridged, depending on the destination (corporate traffic goes to the controller, and Internet access remains local). For details, see
Configuring Ethernet Ports for Mesh on page
AP LLDP-MED Network Policy and AP LLDP profiles :link Layer Discovery Protocol (LLDP), is a Layer-2 protocol that allows network devices to advertise their identity and capabilities on a LAN. The LLDP-MED
Network Policy profile defines the VLAN, priority levels, and DSCP values used by a voice or video application. Wired interfaces on Aruba APs support LLDP by periodically transmitting LLDP Protocol Data
Units (PDUs) comprised of selected type-length-value (TLV) elements. The AP LLDP profile identifies which
TLVs will be sent by the AP. For details, see
Understanding Extended Voice and Video Features on page 974
.
Ethernet interface profile :sets the duplex mode and speed of the AP’s Ethernet link. The configurable speed is dependent on the port type, and you can define a separate Ethernet Interface profile for each
Ethernet link. For details on configuring this profile, see
.
Ethernet Interface Port/Wired Port Profile: specifies a AAA profile for users connected to the wired port on an AP.
AP Provisioning profile : defines a group of provisioning parameters for an AP or AP group. For details on configuring this profile, see .
AP Authorization Profile —Allows you to assign an to a provisioned but unauthorized AP to a AP group with a restricted configuration profile. For details see
Configuring Remote AP Authorization Profiles on page
EDCA parameters profile (Station) :client to AP traffic prioritization parameters, including Enhanced
Distributed Channel Access (EDCA) parameters for background, best-effort, voice and video queues. For additional information on configuring this profile, see
Using the WebUI to configure EDCA parameters on page 953 .
EDCA parameters profile (AP): AP to client traffic prioritization, including EDCA parameters for background, best-effort, voice and video queues. For additional information on configuring this profile, see
Using the WebUI to configure EDCA parameters on page 953
.
Spectrum Local Override Profile :configure an individual AP radio as a spectrum monitor, For details, see
Converting an Individual AP to a Spectrum Monitor on page 760
.
RF Management Profiles
The profiles configure radio tuning and calibration, AP load balancing, and RSSI metrics.
n n n
802.11a radio profile: defines AP radio settings for the 5 GHz frequency band, including the Adaptive
Radio Management (ARM) profile and the high-throughput (802.11n) radio profile. For additional information on configuring this profile, see
802.11a and 802.11g RF Management Profiles on page 563 .
802.11g radio profile: defines AP radio settings for the 2.4 GHz frequency band, including the Adaptive
Radio Management (ARM) profile and the high-throughput (802.11n) radio profile. Each 802.11a and
802.11b radio profile includes a reference to an Adaptive Radio Management (ARM) profile.
If you want the ARM feature to dynamically select the best channel and transmission power for the radio, verify that the 802.11a/802.11g radio profile references an active and enabled ARM profile. If you want to manually select a channel for each AP group, create separate 802.11a and 802.11g profiles for each AP group and assign a different transmission channel for each profile. For additional information on configuring this profile, see
802.11a and 802.11g RF Management Profiles on page 563 .
ARM profile: defines the Adaptive Radio Management (ARM) settings for scanning, acceptable coverage levels, transmission power and noise thresholds. In most network environments, ARM does not need any adjustments from its factory-configured settings. However, if you are using VoIP or have unusually high security requirements you may want to manually adjust the ARM thresholds. For complete details on
Adaptive Radio Management, refer to
Adaptive Radio Management on page 455
.
ArubaOS 6.5.3.x
| User Guide Access Points | 531
n n n n
High-throughput radio profile: manages high-throughput (802.11n) radio settings for 802.11n-capable
APs. A high-throughput profile determines 40 Mhz tolerance settings, and controls whether or not the APs using this profile will advertise intolerance of 40 MHz operation. (This option is disabled by default, allowing
40 MHz operation.) For additional information on configuring this profile, see
High-Throughput Virtual APs on page 446
.
RF Optimization profile: enables or disables load balancing based on a user-defined number of clients or degree of AP utilization on an AP. Use this profile to detect coverage holes, radio interference and STA association failures and configure Received signal strength indication (RSSI) metrics.
RF Event Thresholds profile: defines error event conditions, based on a customizable percentage of lowspeed frames, non-unicast frames, or fragmented, retry or error frames. For additional information on configuring this profile, see
RF Event Configuration on page 575
.
AM Scanning : Aruba 802.11n APs and non-11n APs in AM-mode support the TotalWatch scanning feature giving them the ability to scan all channels of the RF spectrum, including 2.4-and 5-GHz bands as well as the
4.9-GHz public safety band. The AM Scanning profile enables this feature, and defines the dwell types for different channel types.
Wireless LAN Profiles
The Wireless LAN collection of profiles configure WLANs in the form of virtual AP profiles. A virtual AP profile contains an SSID profile which defines the WLAN, the high-throughput SSID profile, and an AAA profile that defines the authentication for the WLAN.
Unlike other profile types, you can configure and apply multiple instances of virtual AP profiles to an AP group or to an individual AP.
n n n n n n
802.11k profile: manages settings for the 802.11k protocol. The 802.11k protocol allows APs and clients to dynamically query their radio environment and take appropriate connection actions. For example: In a
802.11k network if the AP with the strongest signal reaches its CAC (Call Admission Control) limits for voice calls, then on-hook voice clients may connect to an under utilized AP with a weaker signal. You can configure the following options in 802.11k profile: n n
Enable or disable 802.11K support on the AP
Forceful disassociation of on-hook voice clients n
Measurement mode for beacon reports.
For more details, see
Radio Resource Management (802.11k) on page 427
.
Handover Trigger profile : configure a handover trigger profile to ensure QoS for voice calls for APs with the 802.11k feature enabled. For more details, see
Enabling Wi-Fi Edge Detection and Handover for Voice
RRM IE profile :configure a Radio Resource Management Information Element (RRM IE) profile to define the information elements advertised by an AP with 802.11k support enabled. For more details, see
Configuring Radio Resource Management Information Elements on page 429
Beacon Report Request profile: APs with the 802.11k feature enabled use request messages to solicit measurements. This profile defines the information an AP can send in beacon report requests. For details, see
Understanding AP Configuration Profiles on page 530
802.11r profile: APs with the 802.11r (Fast BSS Transition) feature enabled minimize the delay when a client transitions from one BSS to another within the same ESS. For more details, see
TSM Report Request profile : APs with the 802.11k feature enabled use request messages to solicit measurements. This profile defines the information an AP can send in traffic stream measurement reports.
For more details, see
Understanding AP Configuration Profiles on page 530
532 | Access Points ArubaOS 6.5.3.x | User Guide
n
SSID profile: Configures network authentication and encryption types. This profile also includes references to the EDCA (enhanced distributed channel access) Parameters Station Profile, the EDCA Parameters AP
Profile and a High-throughput SSID profile.
Use this profile to configure basic settings such as 802.11 authentication and encryption settings, or advanced settings such as DTIM (delivery traffic indication message) intervals, 802.11a/802.11g basic and transmit rates, DHCP settings and WEP keys. The advanced SSID profile settings allows you to deny broadcast probes and hide the SSID. For details on configuring an SSID profile, see
Beacon rates for 802.11a and 802.11g beacons should only be configured on APs with Distributed Antenna Systems
(DAS). Configuring beacon rates during normal operation may cause connectivity problems.
n n n n n n n n
High-throughput SSID profile: high-throughput APs support additional settings not available in legacy
APs. A High-throughput SSID profile enables/disables high-throughput (802.11n) features with 40 MHz channel usage, and define values for aggregated MAC protocol data units (MDPUs) and Modulation and
Coding Scheme (MCS) ranges. If you modify a currently provisioned and running high-throughput SSID profile, your changes take effect immediately; rebooting is not required. For details on configuring a highthroughput SSID profile, see
High-Throughput Virtual APs on page 446
.
Advertisement, ANQP, H2QP and Hotspot profiles :The settings configured in these four profile types help mobile devices identify which access points in your 802.11u hotspot network are suitable for their needs, and authenticate to a remote service provider using suitable credentials. For details on configuring
Advertisement, ANQP, H2QP or Hotspot profiles, see
.
Virtual AP profile: this profile defines your WLAN by enabling or disabling the band steering, fast roaming and DoS prevention features. It defines radio band, forwarding mode and blacklisting parameters, and includes references to an AAA Profile, 802.11K Profile, and a High-throughput SSID profile. You can apply multiple virtual AP profiles to an AP group or to an individual AP; for most other profiles, you can apply only one instance of the profile to an AP group or AP at a time. For details on configuring a Virtual AP profile, see
Virtual AP Profiles on page 418 .
Anyspot profile : Configure this profile to suppress probe requests from clients attempting to locate and connect to other known networks. By reducing the frequency at which these messages are sent, this feature frees up network resources and improves network performance. For details on configuring an anyspot profile, see
Suppressing Client Probe Requests on page 559
.
VIA Client WLAN profile :the VIA client WLAN profile settings are similar to the authentication settings used to set up a wireless network. For details and examples, see
Virtual Intranet Access on page 753 .
AAA profile: This defines authentication settings for the WLAN users, including the role for unauthenticated users, and the different roles that should be assigned to users authenticated via 802.1X,
MAC or SIP authentication. This profile includes references to: n n
MAC Authentication Profile
MAC Authentication Server Group n n
802.1X Authentication Profile
802.1X Authentication Server Group n
RADIUS Accounting Server Group
For details on configuring an AAA profile, see
WLAN Authentication on page 443
.
XML API server profile: specifies the IP address of an external XML API server. For additional information, see
Configuring the XML API Server on page 1087 .
RFC 3576 server: Specifies the IP address of a RFC 3576 RADIUS server. For additional information, see
.
ArubaOS 6.5.3.x
| User Guide Access Points | 533
n n n n n n n n n n n n n
MAC Authentication profile: defines parameters for MAC address authentication, including upper- or lower-case MAC string, the diameter format in the string, and the maximum number of authentication failures before a user is blacklisted. For additional information, see
Configuring the MAC Authentication
.
Captive Portal Authentication profile: this profile directs clients to a web page that requires them to enter a username and password before being granted access to the network. This profile defines login wait times, the URLs for login and welcome pages, and manages the default user role for authenticated captive portal clients.
You can also set the maximum number of authentication failures allowed per user before that user is blacklisted. This profile includes a reference to a Server group profile. For complete information on configuring a Captive portal authentication profile, refer to
Captive Portal Authentication on page 312
.
WISPr authentication profile: WISPr authentication allows a “smart client” to authenticate on the network when they roam between Wireless Internet Service Providers, even if the wireless hotspot uses an
ISP for which the client may not have an account. For more information on configuring WISPr authentication, see
Configuring WISPr Authentication on page 301
.
802.1X authentication profile: defines default user roles for machine or 802.1X authentication, and parameters for 8021.X termination and failed authentication attempts. For a list of the basic parameters in the 802.1X authentication profile, refer to
802.1X Authentication on page 265
SSO : This feature allows single sign-on (SSO) for different web-based applications using Layer 2 authentication information. For more information, see
Application Single Sign-On Using L2 Authentication .
RADIUS server profile: identifies the IP address of a RADIUS server and sets RADIUS server parameters such as authentication and accounting ports and the maximum allowed number of authentication retries.
For a list of the parameters in the RADIUS profile, refer to
Configuring a RADIUS Server on page 180
LDAP server profile: defines an external LDAP authentication server that processes requests from the controller. This profile specifies the authentication and accounting ports used by the server, as well as administrator passwords, filters and keys for server access. For a list of the parameters in the LDAP profile, refer to
Configuring an LDAP Server on page 194
TACACS server profile: specifies the TCP port used by the server, the timeout period for a TACACS+ request, and the maximum number of allowed retries per user. For a list of the parameters in the TACACS profile, refer to
Configuring a TACACS+ Server on page 195
Server group: Tthis profile manages groups of servers for specific types of authentication. Server Groups identify individual authentication servers and let you create rules for clients based on attributes returned for the client by the server during authentication. For additional information on configuring server rules, see
Configuring Server-Derivation Rules on page 205
VPN Authentication profile: this profile identifies the default role for authenticated VPN clients and also references a server group. It also provides a separate VPN AAA authentication for a terminating remote AP
(default-rap) and a campus AP (default-CAP). If you want to simultaneously deploy various combinations of a VPN client, RAP-psk, RAP-certs and CAP on the same controller, see
.
Management Authentication profile: enables or disables management authentication, and identifies the default role for authenticated management clients. This profile also references a server group. For more information on configuring a management authentication profile, see
Management Authentication Profile
.
Wired Authentication profile: This profile merely references an AAA profile to be used for wired authentication.
Stateful NTLM authentication Profile: monitor the NTLM (NT LAN Manager) authentication messages between clients and an authentication server. If the client authenticates via an NTLM authentication server, the controller can recognize that the client has been authenticated and assign that client a specified user role. or details on configuring stateful authentication, see
Stateful and WISPr Authentication on page 297 .
534 | Access Points ArubaOS 6.5.3.x | User Guide
n n
Stateful Kerberos Authentication: use stateful Kerberos authentication to configure a controller to monitor the Kerberos authentication messages between a client and a Windows authentication server. If the client successfully authenticates via an Kerberos authentication server, the controller can recognize that the client has been authenticated and assign that client a specified user role. For more information on stateful Kerberos authentication, see
Configuring Stateful Kerberos Authentication on page 300 .
Stateful 802.1X Authentication Profile: enables or disables 802.1X authentication for clients on non-
Aruba APs, and defines the default role for those users once they are authenticated. This profile also references a server group to be used for authentication. For details on configuring stateful authentication, see
Stateful and WISPr Authentication on page 297 .
Mesh Profiles
You can provision Aruba APs to operate as mesh points, mesh portals or remote mesh portals. The secure enterprise mesh environment routes network traffic between APs over wireless hops to join multiple Ethernet
LANs or to extend wireless coverage. The Mesh profiles are: n n n
Mesh high-throughput SSID profile : enables or disables high-throughput (802.11n) features and 40
Mhz channel usage, and define values for aggregated MAC protocol data units (MDPUs) and Modulation and Coding Scheme (MCS) ranges. If none of the APs in your Mesh deployment are 802.11n-capable, you do not need to configure a mesh high-throughput SSID profile. For additional information on configuring this profile, see
Creating and Editing Mesh High-Throughput SSID Profiles on page 623 .
Mesh radio profile : determines many of the settings used by mesh nodes to establish mesh links and the path to the mesh portal, including the maximum number of children a mesh node can accept, and transmit rates for the 802.11a and 802.11g radios. For additional information on configuring this profile, see
Creating and Editing Mesh Radio Profiles on page 618 .
Mesh cluster profile: contains the mesh cluster name (MSSID), authentication methods, security credentials, and cluster priority. For additional information on configuring this profile, see
Cluster Profiles on page 614 .
QoS Profiles
The QoS profiles configure traffic management and VoIP functions.
n n n
WMM Traffic management profile: the profile for Wi-Fi Multi-Media (WMM) traffic management prioritizes voice and video traffic above other data traffic . For additional information on configuring this profile, see
Traffic management profile: specifies the minimum percentage of available bandwidth to be allocated to a specific Virtual AP when there is congestion on the wireless network, and sets the interval between bandwidth usage reports. For additional information on configuring this profile, see
VoIP call admission control profile: Aruba’s Voice Call Admission Control limits the number of active voice calls per AP by load-balancing or ignoring excess call requests. This profile enables active load balancing and call admission controls, and sets limits for the numbers of simultaneous Session Initiated
Protocol (SIP), SpectraLink Voice Priority (SVP), Cisco Skinny Client Control Protocol (SCCP), Vocera or New
Office Environment (NOE) calls that can be handled by a single radio. For additional information on configuring this profile, see
Scanning for VoIP-Aware ARM on page 982
.
IDS Profiles
The IDS profiles manage settings for wireless intrusion protection (WIP) and The WLAN management system
(WMS) on the controller that monitors wireless traffic to detect any new AP or wireless client station that tries to connect to the network. For details on IDS profile configuration settings, see
Wireless Intrusion Prevention on page 479
ArubaOS 6.5.3.x
| User Guide Access Points | 535
HA Group profiles
This profile defines settings used by the high-availability:fast failover feature. For details, see
n n n n
Other Profiles
The Controller profile and other profiles set the management password policy, define equipment OUIs and configure voice, video or VIA authentication settings.
n n n n n n n n n n
VIA Authentication Profile : define an authentication profile for the VIA feature.
VIA Connection Profile : define authentication and connection settings profile for the VIA feature.
VIA Web Authentication : define a VIA authentication profile to be used for Web authentication.
VIA Global Configuration : select whether or not the controller should allow VIA SSL fallback.
Management Password Policy : define a policy for creating management passwords.
Voip Logging :enable voice logs by for a specific voice client based upon the client's MAC address. For details, see
Advanced Voice Troubleshooting on page 998
SIP settings :define a keep alive mechanism for the SIP sessions using the periodic session refresh request from the user agents. For details, see
Understanding Extended Voice and Video Features on page 974
Dialplan Profile : define SIP dial plans on the controller to provide outgoing PSTN calls.
Configure Real-Time Analysis : enable real -time call quality analysis for voice calls. For details, see
Understanding Extended Voice and Video Features on page 974
License Provisioning : enable the centralized licensing feature. For details, see
AirGroup AAA: configure the AirGroup and ClearPass Policy Manager (CPPM) interface to allow an
AirGroup controller and CPPM to exchange information about the owner, visibility, and status for each mobile device on the network. For details, see
Configuring the AirGroup-CPPM Interface on page 1031
CPPM IF-MAP : use this feature in conjunction with ClearPass Policy Manager to send HTTP User Agent
Strings and mDNS broadcast information to ClearPass so that it can make more accurate decisions about what types of devices are connecting to the network. For details, see
ClearPass Profiling with IF-MAP on page 899 .
Valid Equipment OUI Profile : Set one or more Aruba OUIs for the controller.
Upgrade :configure the software upgrade feature that allows the master controller to automatically upgrade its associated local controllers by sending an image from a image server to one or more local controllers. For details, see
Configuring Centralized Image Upgrades on page 863 .
Profile Hierarchy
The ArubaOS WebUI includes several wizards that allow you to configure an AP, controller, WLAN, or License installation. You can also configure profiles using the WebUI Profile list or via the command line interface. Best practices is to configure the lowest-level settings first. For example, if you are defining a virtual AP profile, you should first define a session policy, then define your server group, then create an AAA profile that references the session policy and your server group.
The output of the show profile-hierarchy CLI command shows how profiles relate to each other, and how some higher-level profiles reference other lower-level profiles. The output of this command will vary, depending upon controller configuration and licenses.
Viewing Profile Errors
To view the list of profile errors using the CLI, use the show profile-errors command. The WebUI displays them with a flag
icon next to the main horizontal menu ( Figure 70
). Click the flag to view the list of errors.
536 | Access Points ArubaOS 6.5.3.x | User Guide
Figure 70 Profile Errors
Before you Deploy an AP
Before you install APs in a network environment, you must ensure that the APs are able to locate and connect to the controller. Specifically, you must configure firewall settings to allow APs to obtain software images and configuration settings from the controller, verify APs are able to locate the controller, and verify each AP is assigned a valid IP address when connected to the network. If you want to provision APs with more than one interface, you can also configure the USB settings and interface priority levels using an AP provisioning profile.
The following steps describe the basic pre-deployment tasks. Click any of the links for more information on these procedures.
1.
2.
3.
4.
(Optional) Define the AP Provisioning Profile
5.
Define a virtual AP profile, and assign that profile to an AP group
Mesh AP Preconfiguration
Mesh APs require the following additional steps to define the mesh networking environment.
n n
Define and configure the mesh cluster profile.
Define and configure the mesh radio profile
Remote AP Preconfiguration
Remote APs require the following additional step to identify valid APs in the remote AP whitelist.
n
Enable Controller Discovery
An AP can discover the IP address of the controller from a DNS server, from a DHCP server, or using the
Aruba Discovery Protocol (ADP).
At boot time, the AP builds a list of controller IP addresses and then tries these addresses in order until it successfully reaches a controller . This list of IP addresses provides an enhanced redundancy scheme for controllers that are located in multiple data centers separated across Layer-3 networks. The AP constructs its list of controller addresses as follows: n n n
If the master provisioning parameter is set to a DNS name, that name is resolved and all resulting addresses are put on the list. If master is set to an IP address, that address is put on the list.
If the master provisioning parameter is not set and a controller address was received in DHCP Option 43, that address is put on the list.
If the master provisioning parameter is not set and no address was received via DHCP option 43, ADP is used to discover a controller address and that address is put on the list.
ArubaOS 6.5.3.x
| User Guide Access Points | 537
n
Controller addresses derived from the server-name and server-ip provisioning parameters and the default controller name aruba-master are added to the list. Note that if a DNS name resolves to multiple addresses, all addresses are added to the list.
Controller Discovery using DNS
When using DNS, AP learns multiple IP addresses to associate with a controller. If the primary controller is unavailable or does not respond, the AP continues through the list of learned IP addresses until it establishes a connection with an available controller. This takes approximately 3.5 minutes per controller.
It is recommended you use a DNS server to provide APs with the IP address of the master controller because it involves minimal changes to the network and provides the greatest flexibility in the placement of APs.
APs are factory-configured to use the host name aruba-master for the master controller. For the DNS server to resolve this host name to the IP address of the master controller, you must configure an entry on the DNS server for the name aruba-master .
Controller Discovery using ADP
ADP is enabled by default on all Aruba APs and controllers. With ADP, APs send out periodic multicast and broadcast queries to locate the master controller. ADP requires that all APs and controllers are connected to the same Layer-2 network. If the devices are on different networks, you must use a Layer-3 compatible discovery mechanism, such as DNS, DHCP, or IGMP forwarding.
To use ADP discovery:
1. Issue the command show adp config to verify that ADP and IGMP join options are enabled on the controller, If ADP is not enabled, you can reenable ADP using the command adp discovery enable and adp igmp-join enable .
2. If the APs are not in the same broadcast domain as the master controller, you enable multicast on the network (ADP multicast queries are sent to the IP multicast group address 239.0.82.11) for the controller to respond to the APs’ queries. You also must make sure that all routers are configured to listen for Internet
Group Management Protocol (IGMP) join requests from the controller and can route these multicast packets. C
Controller discovery using a DHCP Server
You can configure a DHCP server to provide the master controller’s IP address. You must configure the DHCP server to send the controller’s IP address using the DHCP vendor-specific attribute option 43. The APs identify themselves with a vendor class identifier set to ArubaAP in their DHCP requests. When the DHCP server responds to a request, it will send the controller’s IP address as the value of option 43.
When using DHCP option 43, the AP accepts only one IP address. If the IP address of the controller provided by DHCP is not available, the AP can use the other IP addresses provisioned or learned by DNS to establish a connection. For more information on how to configure vendor-specific information on a DHCP server, see
DHCP with Vendor-Specific Options on page 1113
or refer to the documentation included with your server.
Enable DHCP to Provide APs with IP Addresses
Each AP requires a unique IP address on a subnetwork that has connectivity to a controller. It is recommended you use the Dynamic Host Configuration Protocol (DHCP) to provide IP addresses for APs; the DHCP server can be an existing network server or an controller configured as a DHCP server.
If you do not enable DHCP, each AP must be manually configured with an IP address through the AP provisioning profile. For details, see .
538 | Access Points ArubaOS 6.5.3.x | User Guide
You can use an existing DHCP server in the same subnetwork as the AP to provide the AP with its IP information. You can also configure a device in the same subnetwork to act as a relay agent for a DHCP server on a different subnetwork. (Refer to the vendor documentation for the DHCP Server or relay agent for information.)
If an AP is on the same subnetwork as the master controller, you can configure the controller as a DHCP server to assign an IP address to the AP. The controller must be the only DHCP server for this subnetwork.
In the WebUI
1. Navigate to the Configuration > Network > IP > DHCP Server window.
2. Select the Enable DHCP Server checkbox.
3. In the Pool Configuration section, click Add .
4. Enter information about the subnetwork for which IP addresses are to be assigned. Click Done .
5. If there are addresses that should not be assigned in the subnetwork: a. Click Add in the Excluded Address Range section.
b. Enter the address range in the Add Excluded Address section.
c. Click Done .
6. Click Apply at the bottom of the window.
In the CLI
(host)(config)# ip dhcp excluded-address ipaddripaddr2
(host)(config)# ip dhcp pool name
default-router ipaddr
dns-server ipaddr
domain-name name
network ipaddrmask
(host)(config)# service dhcp
AP Provisioning Profiles
AP provisioning profiles allow you to define a set of additional provisioning information for an AP, such as USB modem settings, PPPoE values, or configuration settings to provision an AP as a remote AP. When you create a provisioning profile, you can then apply that profile to an AP group and provision that entire group of campus or remote APs with the settings in that profile.
Defining an AP Provisioning Profile
By default, an AP group does not have a provisioning profile. Make sure that any provisioning profiles you create are complete and accurate before you assign that profile to an AP group. If a misconfigured provisioning profile is assigned to a group of APs, the APs in that group may be automatically provisioned with erroneous parameters and become lost.
1. Navigate to the Configuration > Wireless > AP Installation > Provisioning window.
2. Next, select the Provisioning Profile tab and enter a provisioning profile name in the text box (next to the
Add button).
3. Click the Add button to add the profile name.
4. Select your new provisioning profile name from the list at the left.
5. (Optional) If you are provisioning a remote AP, select the Remote-AP checkbox.
6. Enter the IP address or the fully qualified domain name of the master controller in the Master IP/FQDN field.
ArubaOS 6.5.3.x
| User Guide Access Points | 539
7. If your AP will use Point-to-Point Protocol over Ethernet (PPPoE) to authenticate itself to a service provider, select the PPPoE Parameters checkbox and enter the following PPPoE values: n n
PPPoE User Name: Set the PPPoE User Name for this remote AP.
PPPoE Password: Enter and then confirm the PPPoE password for this remote AP.
n
PPPoE Service Name: Either an ISP name or a class of service configured on the PPPoE server.
8. (Optional) If you want to use this provisioning profile to provision APs with more than one interface, you must also configure the USB settings and priority levels for this profile. The configuration settings in this profile are described in
.
9. Click Apply to save your settings.
Table 121: AP Provisioning Profile parameters
Parameter Description
Remote-AP
Master IP/FQDN
PPPOE User Name :
PPPOE Password :
PPPOE Service Name
USB User Name
USB Password :
USB Device Type
USB Device Identifier
USB Dial String
USB Initialization String
USB TTY device data path
USB TTY device control path
Link Priority Ethernet
Link Priority Cellular
Select this checkbox to provision the group of APs as remote APs.
The fully qualified domain name (FQDN) or IP address of the controller to which the AP is associated.
NOTE: If you configure a master IP/FQDN setting in an AP’s provisioning profile, this setting will override any LMS and backup LMS settings configured in an AP’s AP system-profile. Leave the master IP/FQDN parameter blank if you want the AP to use the LMS or backup LMS values.
Point-to-Point Protocol over Ethernet (PPPoE) password for the AP.
Point-to-Point Protocol over Ethernet (PPPoE) password for the AP.
Configures the PPPoE service name for the AP.
Configures the USB username for the AP.
A USB password, if provided by the cellular service provider.
The USB device type.
The USB device identifier.
The dial string for the USB modem. This parameter only needs to be specified if the default string is not correct.
The initialization string for the USB modem. This parameter only needs to be specified if the default string is not correct.
The TTY device path for the USB modem. This parameter only needs to be specified if the default path is not correct.
The TTY device control path for the USB modem. This parameter only needs to be specified if the default path is not correct.
Set the priority of the wired uplink. Each uplink type has an associated priority; wired ports having the highest priority by default.
Set the priority of the cellular uplink. By default, the cellular uplink is a lower priority than the wired uplink; making the wired link the primary link and the cellular link the secondary or backup link.
Configuring the cellular link with a higher priority than your wired link priority will set your cellular link as the primary controller link.
540 | Access Points ArubaOS 6.5.3.x | User Guide
Parameter Description
Cellular modem network preference
Username of AP so that AP can authenticate to 802.1X using
PEAP
The cellular modem network preference setting allows you to select how the modem should operate.
n n n n auto (default): In this mode, the modem firmware will control the cellular network service selection; so the cellular network service failover and fallback is not interrupted by the remote AP (RAP).
3g_only : Locks the modem to operate only in 3G.
4g_only : Locks the modem to operate only in 4G.
advanced : The RAP controls the cellular network service selection based on the Received Signal Strength Indication (RSSI) thresholdbased approach. Initially the modem is set to the default auto mode.
This allows the modem firmware to select the available network. The
RAP determines the RSSI value for the available network type (for example 4G), checks whether the RSSI is within required range, and if so, connects to that network. If the RSSI for the modem’s selected network is not within the required range, the RAP will then check the
RSSI limit of an alternate network (for example, 3G), and reconnect to that alternate network. The RAP will repeat the above steps each time it tries to connect using a 4G multimode modem in this mode.
Configure the AP username.
Password of AP so that AP can authenticate to 802.1X using
PEAP
Uplink VLAN
Configure the AP password.
AP POE Power optimization
If you configure an uplink VLAN on an AP connected to a port in trunk mode, the AP sends and receives frames tagged with this VLAN on its
Ethernet uplink.
By default, an AP has an uplink vlan of 0, which disables this feature.
If an AP is provisioned with an uplink VLAN, it must be connected to a trunk mode port or the AP’s frames will be dropped. 0 ( disabled) to 4095 0
On enabling this feature, the following events occur on the AP: n
AP draws 13.0 W power.
n n
USB port is disabled if the AP USB Power override parameter is not enabled.
Power Sourcing Equipment (PSE) is disabled.
Enabling this setting will minimize the PoE draw of the AP. In addition, this setting may disable some parts of the AP. If disabled, the controller ensures that all the features on the AP are enabled.
USB power mode Set the USB power mode to control the power to the USB port.
Assigning Provisioning Profiles
Once you have defined a provisioning profile, you must assign that profile to an AP group.
1. Navigate to the Configuration>AP configuration window and select the AP group tab.
2. Click the Edit button by the name of the AP group to which you want to assign the provisioning profile.
3. In the profiles list, expand the AP menu, and select Provisioning Profile.
The Profile Details window appears.
4. Click the Provisioning Profile drop-down list and select the name of the provisioning profile you want to assign to this AP group.
5. Click Apply .
ArubaOS 6.5.3.x
| User Guide Access Points | 541
If you are provisioning remote APs, you must also add the remote APs to the RAP whitelist. For details, see
Remote Access Points on page 701
.
Configuring Installed APs
APs and AMs are designed to require only minimal setup to make them operational in an user-centric network.
Once APs have established communication with the controller, you can apply advanced configuration to individual APs or groups of APs in the network using the WebUI on the controller.
You can either connect the AP directly to a port on the controller, or connect the AP to another switch or router that has layer-2 or layer-3 connectivity to the controller. If the Ethernet port on the controller is an 802.3af
Power over Ethernet (PoE) port, the AP automatically uses it to power up. If a PoE port is not available, you must get an AC adapter for the AP. For more information, see the Installation Guide for the specific AP.
If you are configuring a new AP that has never been provisioned before, you must first connect the AP to the controller according the instructions included with that AP. If you are reprovisioning or reconfiguring existing active APs, this step is not necessary, as the APs are already communicating with the controller.
This section describes the procedure to configure a installed AP with the basic settings it requires to become operational on the network. You can configure an AP using the AP wizard, the provisioning profile in the
WebUI, or the controller command-line interface. using The individual configuration steps vary, depending upon whether the AP is deployed as a campus AP, remote AP (RAP) or a mesh AP.
Configuring an AP using the Provisioning Wizard
The easiest way to provision any AP is to use the AP Wizard in the controller WebUI. This wizard will walk you through the specific steps required to provision a campus, remote or Mesh AP. The Wizard includes a help tab that further describes each of the configuration tasks for that deployment type.
To access the AP wizard to provision a AP:
1. Select Configuration>Wizards>AP Wizard. The Specify Deployment Scenario window appears.
2. Select the deployment for the new AP, then click Next to continue to the next window in the Wizard.
3. Continue working your way through the Wizard to complete the provisioning process.
Configuring an AP using the WebUI
The following basic steps configure a campus AP on a WLAN.
Remote APs and mesh APs require additional configuration steps not required for campus APs. For more information, see
and
1. Navigate to the Configuration > Wireless > AP Installation > Provisioning window.
2. Click the checkbox by the AP you want to provision, then click Provision . The Provisioning page opens.
3. In the AP Parameters section, click the AP Group drop-down list and select the AP group to which this AP should be assigned. The AP group must have at least one virtual AP.
4. (Optional) Some AP models support an external antenna in addition to their internal antenna. If the AP you are provisioning supports an external antenna, the Provisioning window displays an additional Antenna
Parameters section. If you want to use an External antenna for the remote AP you are provisioning, select
External Antenna and define settings for that antenna. Otherwise, the remote AP will use its internal antenna by default.
5. If your AP will use Point-to-Point Protocol over Ethernet (PPPoE) to authenticate itself to a service provider, select the PPPoE Parameters checkbox and enter the following PPPoE values: n
PPPoE User Name: Set the PPPoE User Name for this remote AP.
542 | Access Points ArubaOS 6.5.3.x | User Guide
n n
PPPoE Password: Enter and then confirm the PPPoE password for this remote AP.
PPPoE Service Name: Either an ISP name or a class of service configured on the PPPoE server.
6. (Optional) To allow the remote AP to use PEAP to authenticate to 802.1X networks, enter a user name and password in the 802.1X Parameter using PEAP section.
7. In the Master Discovery section, define how the AP should identify its WLAN controller. For more information on the different controller discovery methods, see
Enable Controller Discovery on page 537
.
8. (Optional) Define the uplink VLAN. If you configure an uplink VLAN on an AP connected to a port in trunk mode, the AP sends and receives frames tagged with this VLAN on its Ethernet uplink. To define the uplink
VLAN, entering a VLAN ID from 1-4095 (inclusive) in the IP Settings section of the Provisioning window,
9. In the IP Settings section, define how the AP should obtain its IP address. If you have configured an DHCP server to allow APs to get addresses using DHCP, select Obtain IP address using DHCP . For more information on configuring a DHCP server, see
Enable DHCP to Provide APs with IP Addresses on page 538
.
Otherwise, select Use the Following IP address and enter the appropriate values in the following fields: n
IP address : IP address for the AP, in dotted-decimal format n n n n
Subnet mask : Subnet mask for the IP, in dotted-decimal format.
Gateway IP address : The IP address the AP uses to reach other networks.
DNS IP address : The IP address of the Domain Name Server.
Domain name : (optional) The default domain name.
10.(Optional) Access points can be configured in single-chain mode, allowing the radios of those APs to transmit and receive data using only legacy rates and single-stream HT and VHT rates on a single radio chain and single antenna or antenna interface. On APs with external antennas, this feature uses the external antenna interface labeled A0 or ANT0 (radio chain 0); the other (one or two) antenna interfaces are left unused. If you are provisioning an 802.11n-capable AP, select the Enable for Radio-0 or Enable for
Radio-1 checkboxes in the Single-Chain Mode section to enable single-chain mode for the selected radio.
AP radios in single-chain mode will transmit and receive data using only legacy rates and single-stream HT rates up to MCS 7. This feature is disabled by default.
11.(Optional) If you are provisioning a campus AP model that support USB modems, you must complete the fields in the USB Settings section. USB settings will not appear in the Provisioning tab unless you are provisioning an AP that support these features. Check the USB Parameters checkbox and configure the additional cellular USB settings described in
12.(Optional) Define the AP name or SNMP location. The AP list section displays current information for an AP, and allows you to define additional parameters for your AP, such as AP Name, SNMP System Location.
13.Click
Apply and Reboot . (Reprovisioning the AP causes it to automatically reboot).
Table 122: USB Settings
Parameter
Device
TTY Device Data Path
TTY Device Control Path
Description
Select the USB modem model from the drop-down list. If the model is not listed, select Other (Any) .
The TTY device path for the USB modem. This parameter only needs to be specified if the default path is incorrect.
The TTY device control path for the USB modem. This parameter only needs to be specified if the default path is incorrect.
ArubaOS 6.5.3.x
| User Guide Access Points | 543
Parameter
Initialization String
Device Identifier
Device Type
Dial String
PPP Username
PPP Password
Confirm PPP Password
Modeswitch
Description
The initialization string for the USB modem. This string configures the
Access Point Name (APN) setting of the USB modem. For the USB modem to understand this string, the value entered should adhere to the following formats: n
Prefix double-quotes with a backslash character. See example below: n
"AT+CGDCONT=1,\"IP\",\"vendor\""
Use single-quote instead of double-quotes. AP translates single-quote into double-quotes. See example below: n
"AT+CGDCONT=1,’IP’,’vendor’"
Do not use double-quotes as a string begin-end pair. This is supported by AP. See example below:
AT+CGDCONT=1,’IP’,’vendor’
This parameter only needs to be specified if the default string is incorrect.
The USB device identifier, if the device is not already supported.
Specify the USB driver type from the following list: n n acm : Use ACM driver airprime : Use Airprime driver n n n n beceem-wimax : Use Beceem driver for 4G-WiMAX ether : Use CDC Ether driver for direct IP 4G device hso : Use HSO driver for newer Option none : Disable 3G or 2G network on USB n n n n n n n n n option : Use Option driver pantech-3g : Same as "pantech-uml290" - to support upgrade pantech-uml290 : Use Pantech USB driver for UML290 device ptumlusbnet : Use Pantech USB driver for 4G device rndis : Use a RNDIS driver for a 4G device sierra-evdo : Use EVDO Sierra Wireless driver sierra-gsm : Use GSM Sierra Wireless driver sierrausbnet :Use SIERRA Direct IP driver for 4G device storage : Use USB flash as storage device for storing RAP certificates
The dial string for the USB modem. This parameter only needs to be specified if the default string is incorrect.
Enter the PPP username provided by the cellular service provider.
Enter the optional PPP password provided by the cellular service provider.
Re-enter the optional PPP password provided by the cellular service provider.
USB cellular devices on remote APs typically register as modems, but may occasionally register as a mass-storage device. If a remote AP cannot recognize its USB cellular modem, use setting to specify the parameters for the hardware model of the USB cellular data-card.
NOTE: You must enclose the entire modeswitch parameter string in quotation marks. Example follows:
"-v <default_vendor> -p <default_product> -V <target_vendor> -P
<target_product> -M <message_content>"
544 | Access Points ArubaOS 6.5.3.x | User Guide
Parameter
Cellular NW Preference
Link Priority Ethernet
Link Priority Cellular
USB storage for CSR/Key
Description
The cellular modem network preference setting allows you to select how the modem should operate.
n auto (default): In this mode, the modem firmware will control the cellular network service selection; so the cellular network service failover and fallback is not interrupted by the remote AP (RAP).
n n n
3g_only : Locks the modem to operate only in 3G.
4g_only : Locks the modem to operate only in 4G.
advanced : The RAP controls the cellular network service selection based on the Received Signal Strength Indication (RSSI) thresholdbased approach. Initially the modem is set to the default auto mode.
This allows the modem firmware to select the available network. The
RAP determines the RSSI value for the available network type (for example 4G), checks whether the RSSI is within required range, and if so, connects to that network. If the RSSI for the modem’s selected network is not within the required range, the RAP will then check the
RSSI limit of an alternate network (for example, 3G), and reconnect to that alternate network. The RAP will repeat the above steps each time it tries to connect using a 4G multi-mode modem in this mode.
Set the priority of the wired uplink. Each uplink type has an associated priority; wired ports having the highest priority by default.
Set the priority of the cellular uplink. By default, the cellular uplink is a lower priority than the wired uplink; making the wired link the primary link and the cellular link the secondary or backup link.
Configuring the cellular link with a higher priority than your wired link priority will set your cellular link as the primary controller link.
Check this box if you want the USB to store CSR and private key files.
Configuring a Remote AP
A remote AP (RAP) is recommended when the network between the AP and controller is an un-trusted/nonroutable network, such as the Internet. Furthermore, a RAP supports an internal DHCP server, while a campus
AP does not.
Remote Authentication
The two most common ways to provision an AP for remote authentication are certificate-based AP provisioning and provisioning using a pre-shared key. Although both options allow for a simple secure setup of your remote network, you should make sure that the procedure you select is supported by your controller, the
AP model type and the end user’s client software. If you must provision your APs using a pre-shared key, you need to know which controller models you have that do not support certificate-based provisioning.
n n
Certificate based authentication allows a controller to authenticate a AP using its certificates instead of a PSK. You can manually provision an individual AP with a full set of provisioning parameters, or simultaneously provision an entire group of APs by defining a provisioning profile which contains a smaller set of provisioning parameters that can be applied the entire AP group. When you manually provision an individual AP to use certificated-based authentication, you must connect that AP to the controller before you can define its provisioning settings.
Use Pre-Shared Key (PSK) authentication to provision an individual remote AP or a group of remote
APs using an Internet Key Exchange Pre-Shared Key (IKE PSK).
RAP Configuration
ArubaOS 6.5.3.x
| User Guide Access Points | 545
1. In the Configuration > Wireless > AP Installation > Provisioning window, select Yes for the Remote
AP option.
2. In the Remote IP Authentication Method section, select either Pre-shared key or certificate authentication type. The Pre-shared key option requires you to perform the following additional steps: a. Enter and confirm the pre-shared key (IKE PSK).
b. In the User credential assignment section, specify if you want to use a Global User Name/password or a Per AP User Name/Password .
l
If you use the Per AP User Names/Passwords option, each RAP is given its own user name and password.
l
If you use the Global User Name/Password option, all selected RAPs are given the same (shared) user name and password.
c. Enter the user name, and enter and confirm the password. If you want the controller to automatically generate a user name and password, select Use Automatic Generation , then click Generate by the
User Name and Password fields.
3. If you are provisioning a remote AP model that support USB modems, you must complete the fields in the
USB Settings section. USB settings will not appear in the Provisioning tab unless you are provisioning an
AP that support these features. Check the USB Parameters checkbox and configure the additional cellular
USB settings described in
.
Configuring a Mesh AP
1.
Define and configure the mesh cluster profile.
2.
Define and configure the mesh radio profile
3. In the AP list section of the Configuration > Wireless > AP Installation > Provisioning window, select one of the following mesh for on the AP: l
Mesh portal—The gateway between the wireless mesh network and the enterprise wired LAN.
l l
Mesh point—APs that can provide traditional Aruba WLAN services (such as client connectivity, intrusion detection system (IDS) capabilities, user roles association, LAN-to-LAN bridging, and Quality of Service
(QoS) for LAN-to-mesh communication) to clients on one radio and perform mesh backhaul/network connectivity on the other radio. Mesh points can also provide LAN-to-LAN bridging through their
Ethernet interfaces and provide WLAN services on the backhaul radio
Remote Mesh Portal: The Remote Mesh Portal feature allows you to configure a remote AP at a branch office to operate as a mesh portal for a mesh cluster.
For detailed provisioning guidelines, caveats, and instructions, see
Secure Enterprise Mesh on page 600 .
Verifying the Configuration
After the AP has been configured, navigate to Monitoring>All Access Points window and verify that the AP has an up status. The AP on your network does not appear in this table, it may have been classified as an inactive AP for any of the following reasons: n n n n n
The AP is configured with a missing or incorrect VLAN. (For example, the AP is configured to use a tunneled
SSID of VLAN 2 but the controller doesn't have a VLAN 2.)
The AP has an unknown AP group.
The AP has a duplicate AP name.
An AP with an external antenna is not provisioned with external antenna gain settings.
Both radios on the AP are disabled.
546 | Access Points ArubaOS 6.5.3.x | User Guide
n n n n
No virtual APs are defined on the AP.
The AP has profile errors. For details, access the command-line interface and issue the command “show profile errors”.
The GRE tunnel between the AP and the controller was blocked by a firewall after the AP became active.
The AP is temporarily down while it is upgrading its software. The AP will become active again after upgrading.
n n n n n n n n n n n n n n n n n n n n
Optional AP Configuration Settings
Once the AP has been installed and provisioned, you can use the WebUI or CLI to configure the optional AP settings described in the following sections:
Changing the AP Installation Mode on page 547
Enabling Flexible Radio on page 549
Enabling Spanning Tree on page 549
Enabling PortFast On Trunk on page 550
QoS for AP Management Traffic on page 551
Frame Drop Counter on page 552
DSCP to 802.1p Priority Mapping on page 552
AP Console Access Using a Backup ESSID on page 553
Defining an RTLS Server on page 553
AP Maintenance Mode on page 555
Optional AP Configuration Settings on page 547
Configuring Energy Efficient Ethernet and Ethernet Link Speed on page 556
Associating Ethernet Interface Link Profile with a Wired Port profile on page 558
Suppressing Client Probe Requests on page 559
BLE Operation Mode on page 560
Changing the AP Installation Mode
By default, all AP models initially ship with an indoor or outdoor installation mode. This means that APs with an indoor installation mode are normally placed in enclosed, protected environments and those with an outdoor installation mode are used in outdoor environments and exposed to harsh elements.
In most countries, there are different channels and power that are allowed for indoor and outdoor operation.
You may want to change an AP’s installation mode from indoor to outdoor or vice versa.
In the WebUI
To configure the installation mode for an AP, follow these steps:
1. Navigate to the Configuration > Wireless> AP Installation page. The list of discovered APs are displayed on this page.
2. Select the AP you want to change.
ArubaOS 6.5.3.x
| User Guide Access Points | 547
3. Click Provision to reveal the Provisioning page.
Locate the AP Installation Mode section. By default, the Default mode is selected. This means that the
AP installation type is based on the AP model.
4. Select the Indoor option to change the installation to Indoor mode. Select the Outdoor option to change the to Outdoor mode.
5. Click Apply and Reboot (at the bottom of the page).
In the CLI
This example displays the AP installation mode options and sets the AP to indoor installation mode.
(host) (config) # provision-ap
(host) (AP provisioning) # installation ?
default indoor
Decide by AP model
Indoor installation outdoor Outdoor installation
(host) (AP provisioning) # installation indoor
This example shows basic information details about the configuration of an AP named “MyAP.” The AP installation mode is indoor.
(host) # show ap details ap-name myAP
AP "MyAP" Basic Information
----------------------------
Item
----
Value
-----
AP IP Address 10.0.0.253
LMS IP Address 10.0.0.1
Group default
Location Name N/A
Status
Up time
Installation
Up; Mesh
9m:55s indoor
Renaming an AP
Each AP on the network should have a unique name. Display information about the APs on your network by executing the show ap database long command. The output will flag an AP that has a duplicate name (N flag).
Follow the steps below to rename an active AP on the network. If an AP with a duplicate name is no longer connected to your network, use the command clear gap-db wired-mac to clear the duplicate entry.
In the WebUI
1. Navigate to the Configuration > Wireless> AP Installation page. A list of discovered APs are on this page.
2. Select the AP you want to rename, and click Provision .
3. On the Provisioning page, scroll to the AP list at the bottom of the page and find the AP you want to rename.
4. In the AP Name field, enter the new unique name for the AP.
5. Click Apply and Reboot .
In the CLI
Execute the following command (from enable mode) only on a master controller. Executing the command causes the AP to automatically reboot.
ap-rename {ap-name <name>|serial-num <number>|wired-mac <macaddr>} <new-name>
548 | Access Points ArubaOS 6.5.3.x | User Guide
If an AP is recognized by the controller but is powered off or not connected to the network or controller when you execute the command, the request is queued until the AP is powered back on or reconnected.
Enabling Flexible Radio
This feature allows the AP to seamlessly switch between modes where the radio resources are either combined in a single 2x2 radio or separated in two 1x1 radios.
You can configure the flex-radio in the following modes: n n n
5 GHz mode: acts as a single radio operating on 5 GHz band
2.4 GHz mode: acts as a single radio operating on 2.4 GHz band
2.4 GHz and 5 GHz mode: acts as two radios interfaces, one operating on 5 GHz band, and the other on the
2.4 GHz band. By default, the flexible radio is set to this mode.
You can enable or disable the Flex Radio Mode parameter using the CLI and WebUI interfaces.
In the WebUI
The following procedure configures the Flex Radio Mode parameter in AP System profile:
1. Navigate to the Configuration > Advanced Services > All Profiles page.
2. Under AP > AP System on the Profiles pane, select the profile name.
3. Under the Basic tab on the Profile Details pane, select the Flex Radio Mode checkbox.
4. Click Apply .
In the CLI
To control the flex-radio in the AP system profile, use the following CLI:
(host) (config) #ap system-profile default
(host) (AP system profile "default") #flex-radio-mode
Enabling Spanning Tree
The Spanning Tree Protocol (STP) can prevent loops in bridged Ethernet local area networks. You can enable or disable the Spanning Tree parameter using the CLI and WebUI interfaces.
In the WebUI
The following procedure configures the Spanning Tree parameter in AP System profile:
1. Navigate to the Configuration > Advanced Services > All Profiles page.
2. Under AP > AP System on the Profiles pane, select the profile name.
3. Under the Basic tab on the Profile Details pane, select the Spanning Tree checkbox.
4. Click Apply .
In the CLI
STP is enabled only on wired ports of an AP. STP works only on downlink ports (eth1-<n>). The spanning Tree is supported in APs with 3 or more ports.
The following example enables spanning tree in default ap-system profile, using the CLI command:
(host) (config) #ap system-profile default
(host) (AP system profile "default") #spanning-tree
The following example displays the spanning tree information of an AP, using the CLI command:
(host) (config) #show ap debug spanning-tree ap-name <ap-name>
ArubaOS 6.5.3.x
| User Guide Access Points | 549
Enabling PortFast
Points to remember: n n
Spanning Tree should be enabled on the access point before enabling PortFast.
If PortFast is configured, it is enabled only on access mode ports and if PortFast-Trunk is configured, it is enabled on trunk-mode ports only. Only one of them can be set based on the port’s switchport mode.
Follow the steps below to enable PortFast/PortFast Trunk through the WebUI and command line.
In the WebUI
1. Navigate to Configuration > Advanced Services > All Profiles .
2. Click profile AP > AP wired port .
3. Select the AP profile to enable PortFast.
4. Select the Portfast checkbox.
Figure 71 Enabling PortFast
Ensure the Switchport mode is access by changing the value in the Basic tab of the AP.
Figure 72 Apply Switchport Mode-Access
5. Click Apply.
Enabling PortFast On Trunk
In the WebUI
1. Navigate to Configuration > Advanced Services > All Profiles .
2. Click profile AP > AP wired port .
3. Select the AP profile to enable PortFast on trunk.
4. Select the Portfast on trunk checkbox.
550 | Access Points ArubaOS 6.5.3.x | User Guide
Figure 73 Enabling PortFast On Trunk
Ensure the Switchport mode is trunk by changing the value in the Basic tab of the AP.
Figure 74 Apply Switchport Mode-Trunk
5. Click Apply .
In the CLI
Execute the following commands in config mode to enable PortFast.
Before enabling PortFast ensure that the switchport mode is set to access using the ap wired-ap-profile command.
(host)(config) #ap wired-port-profile "default"
(host) (AP wired port profile "default") #portfast
To disable PortFast execute the no portfast command in the config mode.
(host) (AP wired port profile "default") #no portfast
The following example displays the spanning tree information of an AP, using the CLI command:
(host) (config) #show ap wired-port-profile <ap-name>
Execute the following commands in config mode to enable PortFast on trunk.
Before enabling PortFast ensure that the switchport mode is set to access using the ap wired-ap-profile command.
(host)(config) #ap wired-port-profile "default"
(host) (AP wired port profile "default") #portfast on trunk
To disable PortFast on trunk execute the no portfast on trunk command in the config mode.
(host) (AP wired port profile "default") #no portfast
Before enabling PortFast on trunk ensure that the switchport mode is set to trunk using the ap wired-approfile command.
QoS for AP Management Traffic
Management traffic on the AP can be marked with Differentiated Service Code Point (DSCP) values to apply a priority level to that traffic.
ArubaOS 6.5.3.x
| User Guide Access Points | 551
In the WebUI
Use the following procedures to configure an RTLS server with station message frequency in the WebUI:
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. Under the AP Group tab, click the desired profile.
3. Under the Profiles list, navigate to the AP > AP system profile menu.
4. Under the Advanced tab of the Profile Details section, enter a DSCP value between 0 and 63 in the
Management DSCP field.
5. Click Apply and Save Configuration to save your changes.
In the CLI
Access the command-line interface and issue the command ap system-profile <profile> mgmt-dscp
<dscp> to apply a DSCP priority level to AP management traffic.
Frame Drop Counter
Frame drop counters are used by APs to track frame loss when sending or receiving packets to or from an AP.
The counter records when frames are dropped and compiles the results, allowing clients to monitor frame loss within individual queues.
In the CLI
From the CLI, execute the show ap debug radio-stats ap-name <apname> radio <radio> advanced | include WMM to display WMM queue utilization and packet drop stats.
DSCP to 802.1p Priority Mapping
Use the AP system profile to map IP DSCP QoS priorities (0-63) to VLAN 802.1p priorities (0-7) at the AP's media access control (MAC) level.
If you configure DSCP and 802.1p values on an APM-210 embedded in Ericsson Pico Radio Base Station, ensure that these values are coordinated with the 3GPP LTE and WCDMA systems. The recommended default
DSCP values and DSCP to 802.1p mapping values for an APM-210 are described in the following table.
Table 123: Default DSCP values and DSCP to 802.1p Mapping
Wi-Fi Traffic Type
Control Signaling (Authentication messages from Wi-Fi client, e.g. EAP messages)
Default DSCP value
14
Default
802.1p
Mapping
2
OAM traffic (TFTP, NTP, Syslog, DNS, DHCP, Telnet,
PAPI)
16
4
User data 14 2
In the WebUI
Use the following procedures to configure an RTLS server with station message frequency in the WebUI:
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. Under the AP Group tab, click the desired profile.
3. Under the Profiles list, navigate to the AP > AP system profile menu.
552 | Access Points ArubaOS 6.5.3.x | User Guide
4. Under the Advanced tab of the Profile Details section, enter a DSCP and 802.1P priority maping pair in the IP DSCP to VLAN 802.1P priority mapping field in the format <DSCP>:<802.1P> . To configure multiple mapping pairs, separate each pair by a comma. For example, 14:2,16:4,40:6,48:6 .
In the CLI
Access the command-line interface and issue the command ap system-profile <profile > dscp-to-dot1ppriority-mapping<DSCP>:<802.1P> to map DCSP priorities (0-63) to an 802.1p priority level (0-7).
AP Console Access Using a Backup ESSID
This failover system allows users to access an AP console after the AP has disconnected from the controller. By advertising backup ESSID in either static or dynamic mode, the user is still able to access and debug the
AP remotely through a virtual AP. Settings for this feature can be changed using the controller's WebUI or CLI.
In the WebUI
Use the following steps to configure the settings for the backup ESSID in the WebUI.
1. Navigate to the Configuration > Advanced > All Profiles page.
2. Under AP > AP System on the Profile pane, select the AP profile name.
3. In the Profile Details pane, select the Advanced tab.
4. To change the password, clear the Password for Backup field and enter the new password.
5. Click Apply .
6. To configure the RF band on which the backup ESSID is advertised, click the drop-down list in the RF Band for Backup field and select the desired RF band.
7. Click Apply .
8. To configure the operation mode, choose one of the following options from the Operation for backup drop-down list.
9. Click Apply .
Table 124: Operation for Backup Configuration Parameters
Parameter Description
Off
Static
Dynamic
No backup ESSID advertised by the AP. The default setting is off.
Virtual AP continuously advertises the backup ESSID, regardless of the connection status between the AP and controller.
Virtual AP advertises the backup ESSID only after the AP disconnects from the controller. Once connection between the AP and controller is available, the backup ESSID is disabled again.
In the CLI
Execute the following commands in config mode to configure the backup ESSID settings.
(host)(config) #ap system profile <profile>
#bkup-password <bkup-password>
#bkup-band all|a|g
#bkup mode static|dynamic|off
Defining an RTLS Server
The RTLS server configuration enables the AP to send RFID tag information to an RTLS server. Currently, when configuring the RTLS server under ap system-profile , the valid range of values for station-messagefrequency was 5-3600 seconds. There are deployments that may require this to be configurable to as
ArubaOS 6.5.3.x
| User Guide Access Points | 553
frequently as 1 per second. Starting with ArubaOS 6.4.2.0, you can set the station-message-frequency parameter in the 1-3600 seconds range. Setting the frequency to 1 means a report would be sent for every station every second. A value of 5 would mean that a report for any particular station would be sent at 5 second intervals.
An AP uses port 1144 to send/receive RTLS messages to/from an external RTLS server. Port 1144 is opened on the AP only when the RTLS feature is enabled.
In the WebUI
Use the following procedure to configure an RTLS server with station message frequency using the WebUI:
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. Under the AP Group tab, click the desired profile.
3. Under the Profiles list, navigate to the AP > AP system profile menu.
4. Under the Advanced tab of the Profile Details section, configure the RTLS Server configuration parameters described in
.
Table 125: RTLS Server Configuration Parameters
Parameter Description
IP or DNS port frequency key includeUnassocSta
IP address or the DNS of the RTLS server to which location reports are sent.
Port number on the server to which location reports are sent.
Indicates how often packets are sent to the server.
Valid range is 1-3600 seconds.
Shared secret key.
Indicates whether to include unassociated stations when sending station reports.
Unassociated stations are stations that are not associated to any AP.
Default value is disabled.
In the CLI
Use the following commands to configure an RTLS server with station message frequency using the CLI:
(host) (config) #ap system-profile default
(host) (AP system profile "default") #rtls-server ip-or-dns <IP or DNS of RTLS server> port
<port> key <key> station-message-frequency <1-3600>
Important Points to Remember n n
Sending more frequent reports to the server can improve the accuracy of the location calculation.
Configuring an AP to send reports more frequently adds additional load in terms of CPU usage.
AP Redundancy
In conjunction with the controller redundancy features described in
Increasing Network Uptime Through
Redundancy and VRRP on page 638
the information in this section describes redundancy for APs. Remote APs also offer redundancy solutions via a backup configuration, backup controller list, and remote AP failback. For more information relevant to remote APs, see
Remote Access Points on page 701 .
The AP failback feature allows an AP associated with the backup controller (backup LMS) to fail back to the primary controller (primary LMS) if it becomes available.
554 | Access Points ArubaOS 6.5.3.x | User Guide
If configured, the AP monitors the primary controller by sending probes every 600 seconds by default. If the
AP successfully contacts the primary controller for the entire hold-down period, it will fail back to the primary controller. If the AP is unsuccessful, the AP maintains its connection to the backup controller, restarts the LMS hold-down timer, and continues monitoring the primary controller.
The following example assumes: n n
You have not configured the LMS or backup LMS IP addresses
Default values unless otherwise noted.
In the WebUI
Follow the procedure below to use the AP system profile to configure a redundant controller. For additional information on AP system profile settings, see
Virtual AP Configuration Workflow .
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. Select either the AP Group or AP Specific tab. Click Edit for the AP group or AP name.
3. Under Profiles, select AP to display the AP profiles.
4. Select the AP system profile you want to modify.
5. Under Profile Details: a. At the LMS IP field, enter the primary controller IP address.
b. At the Backup LMS IP field, enter the backup controller IP address.
c. Click (select) LMS Preemption . This is disabled by default.
6. Click Apply .
In the CLI ap system-profile <profile>
lms-ip <ipaddr>
bkup-lms-ip <ipaddr>
lms-preemption ap-group <group>
ap-system-profile <profile> ap-name <name>
ap-system-profile <profile>
AP Maintenance Mode
You can configure APs to suppress traps and syslog messages related to those APs. Known as AP maintenance mode, this setting in the AP system profile is particularly useful when deploying, maintaining, or upgrading the network. If enabled, APs stop flooding unnecessary traps and syslog messages to network management systems or network operations centers during a deployment or scheduled maintenance. The controller still generates debug syslog messages if debug logging is enabled. After completing the network maintenance, disable AP maintenance mode to ensure all traps and syslog messages are sent. AP maintenance mode is disabled by default.
In the WebUI
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. Select either the AP Group or AP Specific tab. Click Edit for the AP group or AP name.
3. Under Profiles, select AP to display the AP profiles.
4. Select the AP system profile you want to modify.
5. Under Profile Details, do the following:
ArubaOS 6.5.3.x
| User Guide Access Points | 555
n n
To enable AP maintenance mode, check (select) the Maintenance Mode checkbox.
To disable AP maintenance mode, clear (deselect) the Maintenance Mode checkbox.
6. Click Apply .
In the CLI
To enable AP maintenance mode: ap system-profile <profile> maintenance-mode
To disable AP maintenance mode: ap system-profile <profile> no maintenance-mode
To view the maintenance mode status of APs, use the following commands: show ap config {ap-group <name>|ap-name <name>|essid <name>} show ap debug system-status {ap-name <name>|bssid <name>| ip-addr <ipaddr>}
On the local controller, you can also view maintenance mode status using the following commands: show ap active {ap-name <name>|essid <name>|ip-addr <ipaddr>} show ap database show ap details {ap-name <name>|bssid <name>|ip-addr <ipaddr>}
Energy Efficient Ethernet
Starting from ArubaOS 6.5.0.0, Aruba APs support the 802.3az Energy Efficient Ethernet (EEE) standard, which allows the APs to consume less power during periods of low data activity. This setting can be enabled for provisioned APs or AP groups through the Ethernet Link profile. If this feature is enabled for an APs group, any
APs in the group that do not support 803.az will ignore this setting. For more information on configuring
Energy Efficient Ethernet, see
Configuring Energy Efficient Ethernet and Ethernet Link Speed on page 556
.
802.3az is not supported on AP-215, AP-315, and 330 Series access points.
Smart Rate
HPE Smart Rate is a new multi-gigabit (1, 2.5, 5, 10 Gbps) twisted-pair network interface that is interoperable with the NBASE-T ecosystem of 2.5 or 5 Gbps products as well as with existing industry standard 1 GbE or 10
GbE devices. It allows the majority of existing cable installations found in campus LAN environments to provide higher bandwidth connectivity, distribute PoE power to connected devices, and secure the wired-link for nextgeneration 802.11ac applications.
With smart rate configuration enabled, an AP is capable of negotiating more than 1Gbps of link speed with a smart rate capable switch. 330 Series APs are capable of negotiating up to 5 Gbps speed. By default, the
Ethernet interface speed is configured as auto (auto-negotiate) and the eth0 interface of 330 Series access points negotiate a 2.5 Gbps speed. To obtain 5Gbps speed negotiation, enforce the speed value in the AP
Ethernet Link profile. For more information on configuring the link speed, see
Ethernet and Ethernet Link Speed on page 556
.
Configuring Energy Efficient Ethernet and Ethernet Link Speed
You can configure 802.3az or link speed using the WebUI or CLI.
In the WebUI
1. Navigate to the Configuration > Advanced Services> All Profiles page.
2. In the Profiles list, select AP to expand the AP profile menu.
556 | Access Points ArubaOS 6.5.3.x | User Guide
3. Select AP Ethernet Interface Link profile. The list of existing Ethernet Link profiles appears in the Profile
Details window. Select the Ethernet link profile you want to configure to support 803.az from this list, or create a new Ethernet link profile by entering a name for the new profile, then clicking Add .
4. The selected profile appears in the Profile Details window. The configuration parameters for the profile are described in
.
5. Select the 803.az
checkbox to enable energy efficient ethernet.
6. Select the required value from the Speed drop-down list to configure the Ethernet link speed. The speed value can be one of the following values: n n n n
10 — 10 Mbps
100 — 100 Mbps
1000 —1 Gbps
2500 — 2.5 Gbps n n
5000 — 5 Gbps auto — Auto-negotiate. This is the default value.
7. Click Apply to save your changes.
In the CLI
To enable support for 803.az EEE, access the command-line interface in config mode and issue the following commands:
(host) (config) #ap enet-link-profile <profile>
(host) (AP Ethernet Link profile "<profile>") #dot3az
To configure the Ethernet link speed, access the command-line interface in config mode and issue the following commands:
(host) (config) #ap enet-link-profile <profile>
(host) (AP Ethernet Link profile "<profile>") #speed <speed> n n where <speed> can take any of the following values: n n n n
10 — 10 Mbps
100 — 100 Mbps
1000 —1 Gbps
2500 — 2.5 Gbps
5000 — 5 Gbps auto — Auto-negotiate. This is the default value.
Table 126: Ethernet Interface Link Profile Parameters
Parameter Description
Speed
Duplex
802.3az (EEE)
Power over Ethernet
The speed of the Ethernet interface, either 10 Mbps, 100 Mbps, 1000 Mbps
(1 Gbps), 2.5 Gbps, 5 Gbps, or auto-negotiated.
The duplex mode of the Ethernet interface, either full, half, or autonegotiated.
Select this checkbox to enable support for 802.3az Energy Efficient
Ethernet.
Select this checkbox to enable support for PoE on the profile.
ArubaOS 6.5.3.x
| User Guide Access Points | 557
Associating Ethernet Interface Link Profile with a Wired Port profile
By default, AP wired port profiles reference the Default Ethernet interface link profile. If you created a new
Ethernet interface link profile to support 803.az, use the procedure below to associate a AP wired port profile or Ethernet interface port configuration with the new Ethernet Interface link profile.
In the WebUI
To associate a new Ethernet interface link profile with a wired port profile:
1. Navigate to the Configuration > Advanced Services> All Profiles page.
2. In the Profiles list, select AP to expand the AP profile menu.
3. Select AP Wired Port Profile to display a list of existing wired port profiles
4. Select the AP wired port profile you want to support 802.3az. The Ethernet interface link profile currently associated with the port profile appears below the port profile in the Profiles list.
5. Click the Ethernet interface link profile currently associated with the AP wired port profile you want to modify. The settings for the Ethernet interface link profile appear in the Profile Details window.
6. Click the Ethernet interface link profile drop-down list at the top of the Profile Details window, and select a new Ethernet interface link profile.
7. Click Apply to save your changes.
In the CLI
Associate a new Ethernet Interface link profile with an AP wired port profile using the following command:
(host) (config) #ap wired-port-profile <profile> enet-link-profile <profile>
AP LEDs
AP LEDs can be configured in two modes: normal and off . In normal mode, the AP LEDs will light as expected.
When the mode is set to off, all of the LEDs on the affected APs are disabled.
In the WebUI
An AP system profile’s LED operating mode affects LEDS on all APs using that profile.
This option is available on the AP-105 access points.
1. Navigate to the Configuration > Advanced Services> All Profiles page.
2. Select the AP tab and then select the AP system profiles tab.
3. Select the AP system profile you want to modify.
4. Locate the LED operating mode parameter.
5. From the drop-down list, select off .
6. Click Apply.
In the CLI
Use the ap system-profile command to disable LEDs for all APs using a particular system profile.
(host) (config)# ap system-profile <profile-name> led-mode {normal | off}
Use the ap-leds command to make the LEDs on a defined set of APs either blink or display in the currently configured LED operating mode. Note that if the LED operating mode defined in the AP’s system profile is set to “off”, then the normal parameter in the ap-leds command will disable the LEDs. If the LED operating mode
558 | Access Points ArubaOS 6.5.3.x | User Guide
in the AP system profile is set to “normal” then the normal parameter in this command will allow the LEDs light as usual.
(host) (config)# ap-leds {all | ap-group <ap-group> | ap-name <ap-name> | ip-addr <ip address>
| wired-mac <mac address>} {global blink|normal}|{local blink|normal}
Suppressing Client Probe Requests
The anyspot client probe suppression feature decreases network traffic by suppressing probe requests from clients attempting to locate and connect to other known networks. By reducing the frequency at which these messages are sent, this feature frees up network resources and improves network performance.
When an AP is configured to use this feature, the anyspot AP radio hides its configured ESSID in beacons, and compiles a list of other ESSIDs from detected neighboring APs. If the client sends a probe request without a specified ESSID, the anyspot AP will respond with a preconfigured ESSID.
When a client searches for a preferred network, that client sends the SSID of the preferred network in the probe request. The anyspot AP checks to see if there is a neighboring AP using that ESSID that can respond the client's request. If no matching network is found, the anyspot AP sends a response to the client using the SSID from the client request. If the client is authorized to connect to the anyspot AP, that client associates to AP.
Once connected to the anyspot AP, the client recognizes the ESSID to which it is connected as one associated with its preferred network, and does not send out any further probe requests.
An AP radio can only use this feature when encryption is disabled. (That is, when the operation mod e parameter in the AP radio's WLAN SSSID profile is set to opensystem .)
You can define a list of excluded ESSIDs to which the anyspot AP will not respond. If a client sends probe request with an ESSID on the excluded ESSID list, the anyspot AP will not respond to the request, even if there is no neighboring AP using that ESSID. Excluded ESSIDs can be identified by exact name or a matching string.
In the WebUI
Use the following procedure to suppress client probe requests by enabling the anyspot feature.
1. Navigate to the Configuration > Advanced Services > All Profiles page.
2. Expand the Wireless LAN menu
3. Select Anyspot .
4. In the Profile Details window, enter a name for the new anyspot profile then click Add , or select the name of an existing anyspot profile.
5. Configure the anyspot parameters described in Table 127 .
ArubaOS 6.5.3.x
| User Guide Access Points | 559
Table 127: Anyspot Client Probe Suppression Configuration Parameters
Parameter Description
Enable Anyspot Select this checkbox to enable the anyspot feature. Note that you must associate the anyspot profile with a virtual AP profile for the settings to take effect.
Exclude ESSID(s)
(exact match)
An anyspot-enabled radio will not respond to client probe requests using an ESSID in the
Exclude ESSID lists. To add an ESSID to the list, enter the full name of the ESSID, then click Add . To remove an ESSID from the list, select it and click Delete . ESSIDs from neighboring APs will automatically appear in this list as long as the anyspot-enabled AP can detect that ESSID.
Exclude ESSID(s) (containing string(s)
An anyspot-enabled radio will not respond to client probe requests using an ESSID in the
Exclude ESSID list. To exclude ESSIDs that partially match a text string, enter that string then click Add . To remove a matching string from the list, select it and click Delete .
Preset ESSID(s) The anyspot-enabled AP will not send an ESSID in beacons, but if a client sends a probe requests without ESSIDs (that is, the probe request is not looking for a specific network) then the anyspot-enabled AP will respond to the probe request with an ESSID from this list.
In the CLI
Use the following commands to configure the anyspot profile, and associate an anyspot profile with a virtual
AP.
wlan anyspot-profile <anyspot-profile> wlan virtual-ap <virtual-ap-profile> anyspot-profile <anyspot-profile>
BLE Operation Mode
Starting from ArubaOS 6.4.3.3, the BLE Operation Mode setting is introduced. This setting determines how the built-in Bluetooth Low Energy (BLE) chip in the AP functions. You can configure this setting using the controller WebUI or CLI.
In the WebUI
Log in to the controller WebUI and follow the instructions below.
1. Navigate to the Configuration > WIRELESS > AP Configuration page.
2. In the AP Group tab, click the desired profile.
3. In the Profiles list, navigate to the AP > AP system profile menu.
4. In the Advanced tab of the Profile Details section, configure the BLE Operation Mode setting described in
560 | Access Points ArubaOS 6.5.3.x | User Guide
Table 128: BLE Operation Modes
Mode Description
Beaconing
Disabled
DynamicConsole
PersistentConsole
The AP's built-in BLE chip functions as an iBeacon combined with beacon management functionality.
The AP's built-in BLE chip is turned off. This is the default setting.
The AP's built-in chip functions as a regular iBeacon combined with beacon management functionality. However, when the link to the controller is lost, the built-in chip temporarily enables access to the AP console over BLE. This state of the BLE device may be rolled back to any of the other modes if the AP receives a different configuration setting for the BLE Operation Mode setting from the new LMS.
The AP's built-in chip provides access to the AP console over BLE using a mobile application. This functionality is the superset of the Beaconing mode.
BLE is disabled on the ArubaOS FIPS build.
The BLE Operation Mode setting is currently supported in 320 Series access points only.
In the CLI
You can configure the BLE operation mode in the controller CLI as well. A new ble-op-mode parameter is introduced in the ap system-profile command.
ap system-profile
The following new parameter is introduced in the ap system-profile command:
Parameter Description ble-op-mode
Beaconing
Disabled
DynamicConsole
PersistentConsole
Determines how the built-in Bluetooth Low Energy (BLE) chip in the AP functions. BLE chip can be in one of the following four modes: n n n
Beaconing : The AP's built-in BLE chip functions as an iBeacon combined with beacon management functionality.
Disabled : The AP's built-in BLE chip is turned off. This is the default setting.
DynamicConsole : The AP's built-in chip functions as a regular iBeacon combined with beacon management functionality. However, when the link to the controller is lost, the built-in chip temporarily enables access to the AP console over BLE. This state of the BLE device may be rolled back to any of the other modes if the AP receives a different configuration setting for the ble-op-mode parameter from the new LMS.
n PersistentConsole : The AP's built-in chip provides access to the AP console over
BLE using a mobile application. This functionality is the superset of the Beaconing mode.
NOTE: BLE is disabled on ArubaOS FIPS build.
You can verify the configured value by executing the show ap system-profile command.
ArubaOS 6.5.3.x
| User Guide Access Points | 561
show ap system-profile
The following new parameter is introduced as part of the output of the show ap system-profile command:
Parameter Description
BLE Operation Mode Displays the BLE operation mode of the AP.
Example
The following example displays the BLE operation mode.
(host) #show ap system-profile default
AP system profile "default"
---------------------------
Parameter
---------
RF Band
RF Band for AM mode scanning
Native VLAN ID
Tunnel Heartbeat Interval
Session ACL
...
...
...
BLE Endpoint URL
BLE Auth Token
BLE Operation Mode
Value
----g all
1
1 ap-uplink-acl
N/A
N/A
Disabled
562 | Access Points ArubaOS 6.5.3.x | User Guide
Support for BLE-based Asset Tracking
Starting with ArubaOS 6.5.2.0, APs can monitor BLE asset tags to track the location of time-sensitive, highvalue assets embedded with BLE tags.
BLE tags are located through the following steps:
1. AP beacons scan the network for BLE tags.
2. When a tag is detected, the AP beacon sends information about the tag to the AP, including the MAC address and RSSI of the tag. This data is maintained in a list by the BLE daemon process on the AP.
3. The list of tags is sent from the BLE daemon process on the AP to the BLE relay process on the controller.
4. The controller opens a secure websocket connection with the designated websocket endpoint on the management server, such as the Meridian editor.
5. After receiving the list of tags from the controller, the management server calculates the location of each tag by triangulating the tag’s RSSI data on a floor plan.
Each BLE tag must be heard by at least three AP beacons for triangulation.
In the CLI
Execute the following commands in the CLI to view the list of BLE tags discovered and reported by the AP.
(host) #show ap debug ble-table ap-name <ap_name> assettags
(host) #show ap debug ble-tag-report ap-name <ap-name>
Execute the following commands in the CLI to manage BLE tag reporting and logging.
(host) #ble_relay mgmt-server type ws <ws-endpoint>
(host) #ble_relay set-attr tag-logging <tag-logging> ws-connect <ws-connect> ws-loglvl <ws-loglvl>
(host) #show ble_relay disp-attr all
Execute the following command in the CLI to view BLE tag data:
(host) #show ble_relay tag-report
RF Management
802.11a and 802.11g RF Management Profiles
The two 802.11a and 802.11g RF management profiles for an AP configure its 802.11a (5 Ghz) and 802.11b/g
(2.4 GHz) radio settings. You can either use the “default” version of each profile, or create a new 802.11a or
802.11g profile using the procedures below. Each RF management radio profile includes a reference to an
Adaptive Radio Management (ARM) profile. If you would like the ARM feature to dynamically select the best channel and transmission power for the radio, verify that the RF management profile references an active and enabled ARM profile. It can be useful to set the Max Tx EIRP parameter in the ARM profile to 127 (the maximum power level permissible) until it determines the signal-to-noise radio on the links. If ARM is active, the
Max Tx EIRP can also be set to 127 to allow maximum power levels.
If you want to manually select a channel for each AP group, create separate 802.11a and 802.11g profiles for each AP group and assign a different transmission channel for each profile. For example, one AP group could have an 802.11a profile that uses channel 36 and an 802.11g profile that uses channel 11, and another AP group could have an 802.11a profile that uses channel 40 and an 802.11g profile that uses channel 9.
With the implementation of the high-throughput 802.11n standard, 40 MHz channels were added in addition to the existing 20 MHz channel options. Available 20 MHz and 40 MHz channels are dependent on the country
ArubaOS 6.5.3.x
| User Guide Access Points | 563
code entered in the regulatory domain profile. The newer very high-throughput (VHT) 802.11ac standard introduces 80 Mhz channel options.
Changing the country code causes the valid channel lists to be reset to the defaults for the country.
The following channel configurations are available in ArubaOS: n n n
A 20 MHz channel assignment consists of a single 20 MHz channel. This channel assignment is valid for
802.11a/b/g and for 802.11n 20 MHz mode of operation.
A 40 MHz channel assignment consists of two 20 MHz channels bonded together (a bonded pair). This channel assignment is valid for 802.11n 40 MHz mode of operation and is most often utilized on the 5 GHz frequency band.
A 80 Mhz channel group for 5GHz radios. Only APs that support 802.11ac can be configured with 80 MHz channels.
If high-throughput is disabled, a 40 MHz channel assignment can be configured, but only the primary channel assignment is used. The 20 MHz clients can also associate using this configuration, but only the primary channel is used.
APs initially start up with default ack-timeout , cts-timeout and slot-time values. When you modify the maximum-distance parameter in an rf dot11a radio profile or rf dot11g radio profile, new ack-timeout , ctstimeout and slot-time values may be derived, but those values are never less then the default values for an indoor AP.
Mesh radios on outdoor APs have additional constraints, as mesh links may need to span long distances. For mesh radios on outdoor APs, the effect of the default maximum-distance parameter on the ack-timeout , cts-timeout and slot-time values depends on whether the APs are configured as mesh portals or mesh points. This is because mesh portals use a default maximum-distance value of 16,050 meters, and mesh points use, by default, the maximum possible maximum-distance value.
The maximum-distance value should be set correctly to span the largest link distance in the mesh network so that when a mesh point gets the configuration from the network it will apply the correct ack-timeout , ctstimeout and slot-time values. The values derived from the maximum-distance setting depend on the band and whether 20Mhz/40MHz mode of operation is in use.
The following table indicates values for a range of distances:
Timeouts[usec] --- 5GHz radio ----- 2.4GHz radio ---
Distance[m] Ack CTS Slot Ack CTS Slot
--------------------------------------------------------------------------
0 (outdoor:16050m) 128
0 (indoor:600a,6450g) 25
200 (==default)
500
25
25
128
25
25
25
63
9
9
9
128
64
64
64
128
48
48
48
63
9
9
9
600
1050
5100
10050
15000
16050
121
128
58200(5G limit 20M) 409
52650(2.4G limit 20M) -
25
28
55
88
27450(5G limit 40M) 204
24750(2.4G limit 40M) -
25
28
55
88
121
128
409
-
204
-
-
-
9
13
26
43
59
63
203
101
64
64
64
88
121
128
-
372
-
186
48
48
55
88
121
128
-
372
-
186
59
63
-
185
9
31
31
43
-
92
564 | Access Points ArubaOS 6.5.3.x | User Guide
VHT Support on 200 Series, 210 Series, 220 Series, and 270 Series Access Points
This feature enables Very High Throughput (VHT) rates on the 2.4 GHz band, providing 256-QAM modulation and encoding that allows for 600 Mbit/sec performance over 802.11n networks. Maximum data rates are increased on the 2.4 GHz band through the addition of VHT Modulation and Coding Scheme (MCS) values 8 and 9, which support the highly efficient modulation rates in 256-QAM. Starting with ArubaOS 6.4.2.0, VHT is supported on 200 Series, 210 Series, 220 Series, and 270 Series access points on both 20 MHz and 40 MHz channels.
Using the controller’s CLI or WebUI, VHT MCS values 0-9 are enabled, overriding the existing high-throughput
(HT) MCS values 0-7, which have a lower maximum data rate. However, this feature should be disabled if individual rate selection is required.
Transmit Power Calculation support on 200 Series and 300 Series access points
This feature allows calculation of the transmit power of each outgoing 802.11 packet so that AP adheres to the latest regulatory limits. Also, the MIMO gain is considered while calculating the transmit power. MIMO gain refers to effective increase in EIRP of a packet due to usage of multiple antennae (power gain) and various signal processing techniques such as CDD, transmit beamforming etc., (correlation gain).
Starting from ArubaOS 6.5.2.0, the AP transmit power is calculated on each outgoing 802.11 packet to adhere to the latest regulatory limits. The modification in the AP transmit power calculation results in change in the value of the conducted power on an AP. To operate the APs on a similar power level as earlier ArubaOS versions, it is recommended to slightly increase the EIRP value on the APs after upgrading to ArubaOS 6.5.2.0.
You can use the tx-power parameter under the rf dot11a-radio-profile or rf dot11g-radio-profile command to increase the configured EIRP value.
Two new parameters, a-ant-pol and g-ant-pol , are added to configure the antenna polarization for both the radios. A new show command show ap debug power-table is added that displays the following information: n n n
AP hardware limits
Regulatory limits
Transmit power limits (conducted powers and EIRP) as a function of AP hardware limits, regulatory limits, user configured limits and any other override limits.
This feature is supported on the 200 Series and 300 Series access points and the command show ap debug powertable does not display any value for 100 Series access points.
Managing 802.11a/802.11g Profiles Using the WebUI
Use the following procedures to define and manage 802.11a and 802.11g RF management profiles Using the
WebUI.
Creating or Editing a Profile
1. Navigate to the Configuration > Wireless > AP Configuration window. Select either the AP Group or
AP Specific tab.
n
If you selected AP Group , click the Edit button by the AP group for which you want to create or change an RF management profile.
n
If you selected AP Specific , click the Edit button by the AP for which you want to create or change an RF management profile.
2. In the Profiles list, expand the RF Management menu, then select either 802.11a radio profile or
802.11g radio profile .
3. To edit an existing 802.11a or 802.11g radio profile, select the desired profile from the 802.11a radio profile or 802.11g radio profile drop-down list at the top of the Profile Details window. To create a new
ArubaOS 6.5.3.x
| User Guide Access Points | 565
802.11a or 802.11g profile, click the drop-down list at the top of the Profile Details window, select NEW , then enter a name for the new profile.
The 802.11a and 802.11g profiles are divided into two tabs, Basic and Advanced . The Basic tab displays only those configuration settings that often need to be adjusted to suit a specific network. The Advanced tab shows all configuration settings, including settings that do not need frequent adjustment or should be kept at their default values. If you change a setting on one tab then click and display the other tab without saving your configuration, that setting will revert to its previous value. The basic and advanced profile settings are described in
.
4. Make the desired configuration changes, then click Apply to save your settings.
Table 129: 802.11a/802.11g RF Management Configuration Parameters
Parameter Description
Basic 802.11a/802.11g Settings — General
Radio Enable Enable transmissions on this radio band.
Mode
High throughput enable (Radio)
Very high throughput enable
(Radio)
Very high throughput rates enable
(256-QAM)
Access Point operating mode. Available options are: n am-mode : Air Monitor mode n n ap-mode : Access Point mode spectrum-mode: Spectrum Monitor mode
The default settings is ap-mode .
Enable/Disable high-throughput (802.11n) features on the radio. This option is enabled by default.
Enable/Disable very high-throughput (802.11ac) features on the radio. This option is enabled by default.
NOTE: This parameter is only available in the 802.11a radio profile.
Enable/Disable Very High Throughput (VHT) rate on 2.4 GHz band providing 256-QAM modulation and encoding that allows for 600 Mbit/sec performance over 802.11n
networks. For more information, see
VHT Support on 200 Series, 210 Series, 220
Series, and 270 Series Access Points
.
NOTE: This parameter is only available in the 802.11g radio profile.
Channel Transmit channel for this radio. The available channels depend on the regulatory domain (country). This parameter includes the following channel number configuration options for 20 MHz, 40 MHz and 80 MHz modes: n
20 : Select this option to disable 40 MHz mode and 80 Mhz mode and activate 20
MHz mode for the entered channel.
n n
40 : Entering a channel number and selecting the 40 radio button in the WebUI selects a primary and secondary channel for 40 MHz mode. When you use this option, the number entered becomes the primary channel and the secondary channel is determined by increasing the primary channel number by 4. For example, if you entered 157 into the Channel field and selected the above option, radios using that profile would select 157 as the primary channel and 161 as the secondary channel.
80 ; Entering a channel number and selecting the 80 Mhz radio button selects a primary and secondary channel for 80 MHz mode.
If you select the spectrum monitoring checkbox on this profile page, the AP will operate as a hybrid AP and scan the selected channel for spectrum analysis data.
566 | Access Points ArubaOS 6.5.3.x | User Guide
Parameter Description
Non-Wi-Fi
Interference
Immunity
Set a value for non-Wi-Fi Interference Immunity.
The default setting for this parameter is level 2. When performance drops due to interference from non-802.11 interferers (such as DECT or Bluetooth devices), the level can be increased up to level 5 for improved performance. However, increasing the level makes the AP slightly “deaf” to its surroundings, causing the AP to lose a small amount of range.
The levels for this parameter are: n Level 0: no ANI adaptation.
n n
Level 1: noise immunity only.
Level 2: noise and spur immunity.
n n n
Level 3: level 2 and weak OFDM immunity.
Level 4: level 3 and FIR immunity.
Level 5: disable PHY reporting.
NOTE: Only 802.11n-capable APs simultaneously support both the
feature and a level-3 to level-5 Noise Immunity setting.
Do not raise the noise immunity default setting on APs that do not support 802.11n
unless you first disable the Channel Reuse feature.
Spectrum
Monitoring
Select this option to convert APs using this radio profile to a hybrid APs that will continue to serve clients as an Access Point, but will also scan and analyze spectrum analysis data for a single radio channel. For more details on hybrid APs, see
Advanced 802.11a/802.11g Settings
Transmit EIRP Maximum transmit EIRP in dBm from -51 to 51 in 0.1 dBm increments, or 127 for regulatory maximum. Transmit power may be further limited by regulatory domain constraints and AP capabilities.
Spur Immunity Spur Immunity for 5 GHz radio. This parameter fine-tunes the Cyclic Power Threshold
(CPT) of a 5 GHz radio. The value specified here is the offset from the base value of 2 dB (for example, setting the CPT value to 1 corresponds to 2 + 1 = 3 dB. Similarly, setting the CPT value to 10 corresponds to 2+10 = 12 dB).
Use this parameter when high channel utilization is observed in the 5 GHz radio of
130 Series access points in a noise-free environment causing client association or throughput issues.
Adjust the CPT value to eliminate the spur impacts. Range definition is as follows: n n
0: default CPT
1-19: CPT growth from default (3 dBm to 21 dB) n 20: Setting this parameter to 20 sets the cell-size-reduction value to 1. Cell-sizereduction is the receive coverage area of the AP.
NOTE: Configure this parameter under the supervision of Aruba Technical Support.
NOTE: Setting the spur immunity to a higher value may decrease the AP RF coverage.
NOTE: This parameter is applicable for 130 Series access points only. The controller ignores this parameter if configured for non-130 Series access points.
Enable CSA
CSA Count
Channel Switch Announcements (CSAs), as defined by IEEE 802.11h, enable an AP to announce that it is switching to a new channel before it begins transmitting on that channel. This allows clients that support CSA to transition to the new channel with minimal downtime.
Number of channel switch announcements that must be sent prior to switching to a new channel. The default CSA count is 4 announcements.
ArubaOS 6.5.3.x
| User Guide Access Points | 567
Parameter Description
Spectrum
Monitoring
Smart Antenna
Issue this command to turn APs in ap-mode into a hybrid AP. An AP in hybrid AP mode will continue to serve clients as an access point while it scans and analyzes spectrum analysis data for a single radio channel.
For further details on using hybrid APs and spectrum monitors to examine the radio frequency (RF) environment in which the Wi-Fi network is operating, refer to the
Spectrum Analysis chapter of the ArubaOS User Guide.
For a list of APs that can be converted into a spectrum monitor or hybrid AP, refer to the Spectrum Analysis chapter of the ArubaOS 6.5.3.x User Guide.
The AP-335 access point supports the smart antenna feature, which optimizes the selection of antenna polarization values based on data collected from the training of polarization pattern combinations. This feature identifies the clients most likely to benefit from smart antenna polarization, based upon the average RSSI of the received frames, and the number of streams. This feature uses frame-based antenna training, which allows the AP to cycle through training combinations for training and collect statistics without any impact on the client. At the end of training sequence, the
AP selects the best antenna polarization based upon these collected statistics.
The Smart Antenna feature does not support optimized antenna polarization for clients using Single-User (SU) or Multi-User (MU) transmit beamforming, and will use default polarization values for these clients.
Enable the radio to advertise its 802.11d (Country Information) and 802.11h (Transmit
Power Control) capabilities. This option is disabled by default.
Advertise 802.11d
and 802.11h
Capabilities
Spectrum Load
Balancing
Beacon Period
Beacon Regulate
The Spectrum Load Balancing feature helps optimize network resources by balancing clients across channels, regardless of whether the AP or the controller is responding to the wireless clients' probe requests.
If enabled, the controller compares whether or not an AP has more clients than its neighboring APs on other channels. If an AP’s client load is at or over a predetermined threshold as compared to its immediate neighbors, or if a neighboring Aruba AP on another channel does not have any clients, load balancing will be enabled on that AP.
This feature is disabled by default. For details, see
Spectrum Load Balancing on page
.
Beacon Period for the AP in msec. The range is 60-2000 msec, and the default value is 100 msec.
Enable this setting to introduce randomness in the beacon generation so that multiple
APs on the same channel do not send beacons at the same time.
Advertised
Regulatory Max
EIRP
Work around a known issue on Cisco 7921G telephones by specifying a cap for a radio’s maximum equivalent isotropic radiated power (EIRP). When you enable this parameter, even if the regulatory approved maximum for a given channel is higher than this EIRP cap, the AP radio using this profile will advertise only this capped maximum EIRP in its radio beacons.
The supported range is 1-31dBm.
ARM/WIDS Override If selected, this option disables Adaptive Radio Management (ARM) and Wireless IDS functions and slightly increases packet processing performance. If a radio is configured to operate in Air Monitor mode, then the ARM/WIDS functions are always enabled, regardless of whether or not this check box is selected.
568 | Access Points ArubaOS 6.5.3.x | User Guide
Parameter Description
Reduce Cell Size (Rx
Sensitivity)
The cell size reduction feature allows you manage dense deployments and to increase overall system performance and capacity by shrinking an AP’s receive coverage area, thereby minimizing co-channel interference and optimizing channel reuse. This value should only be changed if the network is experiencing performance issues. The possible range of values for this feature is 0-55 dB. The default 0 dB reduction allows the radio to retain its current default Rx sensitivity value.
Values from 1 dB - 55 dB reduce the power level that the radio can hear by that amount. If you configure this feature to use a non-default value, you must also reduce the radio’s transmission (Tx) power to match its new received (Rx) power level. Failure to match a device’s Tx power level to its Rx power level can result in a configuration that allows the radio to send messages to a device that it cannot hear.
Management
Frame Throttle
Interval
Management
Frame Throttle
Limit
Averaging interval for rate limiting management frames from this radio, in seconds. A management frame throttle interval of 0 seconds disables rate limiting.
Maximum number of management frames that can come in from this radio in each throttle interval.
Maximum Distance Maximum client distance, in meters. This value is used to derive ACK and CTS timeout times. A value of 0 specifies default settings for this parameter, where timeouts are only modified for outdoor mesh radios which use a distance of 16km.
The upper limit for this parameter varies from 24km–58km, depending on the radio’s band (a/g) and 20/40 MHz mode. Note that if you configure a value above the supported maximum, the maximum supported value will be used instead. Values below 600m will use default settings.
RX Sensitivity
Tuning Based
Channel Reuse
In some dense deployments, it is possible for APs to hear other APs on the same channel. This creates co-channel interference and reduces the overall utilization of the channel in a given area. Channel reuse enables dynamic control over the receive
(Rx) sensitivity in order to improve spatial reuse of the channel.
This feature is disabled by default. To enable this feature, click the RX Sensitivity
Tuning Based Channel Reuse drop-down list and select either static or dynamic .To disable this feature, click the RX Sensitivity Tuning Based Channel Reuse drop-down list and select disable . For details on each of these modes, see
Channels to Control RX Sensitivity Tuning on page 476
.
NOTE: Do not enable the Channel Reuse feature if
Non-Wi-Fi Interference Immunity on page 567
is set to level 3 or higher. A level-3 to level-4 Noise Immunity setting is not compatible with the Channel Reuse feature. The channel reuse feature applies to non-DFS channels only. It is internally disabled for DFS channels and is does not affect
DFS radar signature detection.
RX Sensitivity
Threshold
RX sensitivity tuning based channel reuse threshold, in - dBm.
If the Rx Sensitivity Tuning Based Channel reuse feature is set to static mode, this parameter manually sets the AP’s Rx sensitivity threshold
(in -dBm). The AP will filter out and ignore weak signals that are below the channel threshold signal strength.
If the value for this parameter is set to zero, the feature will automatically determine an appropriate threshold.
ArubaOS 6.5.3.x
| User Guide Access Points | 569
Parameter Description
Protection for
802.11b Clients
Associated Profiles
ARM profile Aruba's proprietary Adaptive Radio Management (ARM) technology maximizes WLAN performance by dynamically and intelligently choosing the best 802.11 channel and transmit power for each Aruba AP in its current RF environment.
Every RF management profile references an ARM profile. If you specify an active and enabled ARM profile, you do not need to manually configure the Channel and
Transmit Power parameters for this 802.11a or 802.11g profile. For details on referencing an ARM profile, see
Assigning an ARM Profile on page 571 .
The Adaptive Radio Management (ARM) profile associated with this 802.11a or
802.11g radio profile appears beneath the 802.11a/802.11g radio profile name in the profiles list. To change the ARM profile associated with an 802.11a or 802.11g radio profile, select the associated ARM profile in the profiles list then click the drop-down list in the Profile Details section of the page to select a new profile.
High-throughput radio profile
(For 802.11g RF Management Profiles only) Enable or disable protection for
802.11b clients. This parameter is enabled by default. Disabling this feature may improve performance if there are no 802.11b clients on the WLAN.
WARNING: Disabling protection violates the 802.11 standard and may cause interoperability issues. If this feature is disabled on a WLAN with 802.11b clients, the
802.11b clients will not detect an 802.11g client talking and can potentially transmit at the same time, thus garbling both frames.
A high-throughput profile manages 40 MHz tolerance settings, and controls whether or not APs using this profile will advertise intolerance of 40 MHz operation. (This option is disabled by default, allowing 40 MHz operation.)
A high-throughput profile also determines whether an AP radio using the profile will stop using the 40 MHz channels surrounding APs or stations advertise 40 MHz intolerance. This option is enabled by default. For details on referencing a highthroughput radio profile, see
Assigning a High-throughput Profile on page 571 .
The high-throughput radio profile associated with this 802.11a or 802.11g radio profile appears beneath the 802.11a/802.11g radio profile name in the profiles list. To change the high-throughput radio profile associated with an 802.11a or 802.11g radio profile, select the associated high-throughput radio profile in the profiles list then click the drop-down list in the Profile Details section of the page to select a new profile.
Spectrum
Monitoring Profile
The spectrum monitoring profile defines the spectrum band and device ageout times used by a spectrum monitor radio.
The spectrum monitoring profile associated with this 802.11a or 802.11g radio profile appears beneath the 802.11a/802.11g radio profile name in the profiles list. To change the spectrum monitoring profile associated with an 802.11a or 802.11g radio profile, select the associated spectrum monitoring profile in the profiles list then click the drop-down list in the Profile Details section of the page to select a new profile.
AM Scanning Profile The AM scanning profile associated with this 802.11a or 802.11g radio profile appears beneath the 802.11a/802.11g radio profile name in the profiles list. To change the AM scanning profile associated with an 802.11a or 802.11g radio profile, select the associated AM scanning profile in the profiles list then click the drop-down list in the Profile Details section of the page to select a new profile.
Assigning an 802.11a/802.11g Profile to an AP or AP Group
Use the following procedure to assign an 802.11a or 802.11g RF management profile to an AP Group or individual AP using the WebUI.
1. Navigate to the Configuration > Wireless > AP Configuration window. Select either the AP Group or AP
Specific tab.
n
If you selected AP Group , click the Edit button by the AP group name to which you want to assign a new
802.11a or 802.11g RF management profile.
570 | Access Points ArubaOS 6.5.3.x | User Guide
n
If you selected AP Specific , click the Edit button by the AP to which you want to assign a new 802.11a
or 802.11g RF management profile
2. Under the Profiles list, expand the RF management menu, then select either 802.11a radio profile or e 802.11g radio profile .
3. To select a 802.11a radio profile for an AP or AP group, click the 802.11a radio profile drop-down list in the Profile Details window pane and select the desired profile from the list.
-or-
To select a 802.11g radio profile for an AP or AP group, click the 802.11g radio profile drop-down list in the Profile Details window pane and select the desired profile from the list.
4. Click Apply . The profile name appears in the Profile list with your configured settings. If you configure this for the AP group, this profile also becomes the selected 802.11a or 802.11g RF management profile used by the mesh portal for your mesh network.
Assigning a High-throughput Profile
Each 802.11a or 802.11g RF management radio profile references a high-throughput profile that manages the
AP group’s 40Mhz tolerance settings. By default, an 802.11a profile references a high-throughput profile named default-a and an 802.11g profile references a high-throughput profile named default-g. If you do not want to use these default profiles, use the procedure below to reference a different high-throughput profile for your 802.11a or 802.11g RF management profiles.
1. Navigate to the Configuration > Wireless > AP Configuration window. Select either the AP Group or AP
Specific tab.
n
If you selected AP Group , click the Edit button by the AP group name to which you want to assign a new high-throughput profile.
n
If you selected AP Specific , click the Edit button by the AP which you want to assign a new highthroughput profile.
2. In the Profiles list, expand the RF Management menu, then select either 802.11a radio profile or
802.11g radioprofile .
3. Select High-throughput radio profile . The Profile Details pane appears and displays information for the currently referenced high-throughput profile. Use this window pane to select a different high-throughput profile, or to create an entirely new high-throughput profile for that 802.11a or 802.11g radio.
n n
To reference a different high-throughput profile, click the High-throughput Radio Profile drop-down list and select a new profile name from the list. Click Apply to save your changes.
To create a new high-throughput profile, click the High-throughput Radio Profile drop-down list and select NEW .
a. Enter a name for the new high-throughput profile.
b.
(Optional) Select 40 MHz intolerance if you want to enable 40 MHz intolerance. This parameter controls whether or not APs using this high-throughput profile will advertise intolerance of 40 MHz operation. By default, this option is disabled and 40 MHz operation is allowed.
d.
(Optional) Select honor40 MHz intolerance to allow a radio using this profile to stop using the 40
MHz channels if the 40 MHz intolerance indication is received from another AP or station. This option is enabled by default.
d. Click Apply to save your settings.
4. The high-throughput profile appears in the Profile list with your configured settings.
Assigning an ARM Profile
By default, an 802.11a or 802.11g profile references an ARM profile named default . Most network administrators will find that this one default ARM profile is sufficient to manage all the Aruba APs on their
ArubaOS 6.5.3.x
| User Guide Access Points | 571
WLAN. If, however, you do not want to use this default ARM profile, use the procedure below to reference a different ARM profile for your 802.11a or 802.11g RF management profiles.
1. Navigate to the Configuration > Wireless > AP Configuration window. Select either the AP Group or AP
Specific tab.
n n
If you selected AP Group , click the Edit button by the AP group name to which you want to assign a new
ARM profile.
If you selected AP Specific , click the Edit button by the AP which you want to assign a new ARM profile.
2. Under the Profiles list, expand the RF Management menu.
3. To reference an ARM profile for a 802.11a radio profile, expand the 802.11a radio profile menu.
-or-
To reference an ARM profile for a 802.11g radio profile, expand the 802.11g radio profile menu.
4. The Profile Details pane appears and displays information for the currently referenced ARM profile. You can now select a different profile, or create an entirely new ARM profile for that 802.11a or 802.11g radio.
n
To reference a different ARM profile, click the Adaptive Radio Management (ARM) Profile drop-down list and select a new profile name from the list. Click Apply to save your changes.
n
To create a new ARM profile, click the Adaptive Radio Management (ARM) Profile drop-down list and select NEW .
a. Enter a name for your new ARM profile.
b. (Optional) If you are not configuring ARM for a mesh node, select 40 MHz intolerance if you want to enable 40 MHz intolerance. This parameter controls whether or not APs using this high-throughput profile will advertise intolerance of 40 MHz operation. By default, this option is disabled and 40 MHz operation is allowed.
c. (Optional)If you are not configuring ARM for a mesh node, select honor 40 MHz intolerance to allow a radio using this profile to stop using the 40 MHz channels if the 40 MHz intolerance indication is received from another AP or station. This option is enabled by default.
5. Click Apply to save your settings.
The ARM profile name appears in the Profile list with your configured settings. If you configured this profile for the AP group, this ARM profile becomes part of the selected 802.11a or 802.11g RF management profile used by the mesh portal for your mesh network.
Deleting a Profile
You can delete an 802.11a or 802.11g radio profile only if no APs or AP groups are associated with that profile.
To delete a 802.11a or 802.11g radio profile using the WebUI.
1. Navigate to the Configuration > Advanced Services> All Profiles window.
2. Expand the RF Management menu, then select 802.11a radio profile or 802.11g radio profile . A list of profiles of the specified type appears in the Profile Details window pane.
3. Click the Delete button by the name of the profile you want to delete.
Managing 802.11a/802.11g Profiles Using the CLI
You must be in config mode to create, modify or delete a 802.11a or 802.11g RF management radio profile using the CLI. Specify an existing mesh profile with the <profile-name> parameter to modify an existing profile, or enter a new name to create an entirely new profile.
Creating or Modifying a Profile
Configuration details and any default values for each of these parameters are described in
. This CLI command also allows you to reference an ARM profile and high-throughput radio profile for the 802.11a or
572 | Access Points ArubaOS 6.5.3.x | User Guide
802.11g radio. If you do not specify a parameter for a new profile, that profile uses the default value for that parameter. Put the no option before any parameter to remove the current value for that parameter and return it to its default setting. Enter exit to leave the 802.11a or 802.11g profile mode.
rf dot11a-radio-profile|dot11g-radio-profile <profile-name> am-scan-profile arm-profile beacon-period beacon-regulate cap-reg-eirp channel <num|num+|num-> channel-reuse channel-reuse-threshold clone csa csa-count disable-arm-wids-function dot11b-protection (for 802.11g radio profiles only) dot11h high-throughput-enable ht-radio-profile interference-immunity maximum-distance mgmt-frame-throttle-interval mgmt-frame-throttle-limit mode {ap-mode|am-mode|spectrum-mode} no radio-enable slb-mode slb-threshold slb-update-interval smart-antenna spectrum-load-bal-domain spectrum-load-balancing spectrum-monitoring spectrum-profile spur immunity <spur-immunity> tpc-power tx-power
You can also create a new 802.11a or 802.11g RF management profile by copying the settings of an existing profile using the clone parameter. Using the clone command to create a new profile makes it easier to keep constant attributes in common within multiple profiles.
rf dot11a-radio-profile <profile-name> clone <source-profile-name> rf dot11g-radio-profile <profile-name> clone <source-profile-name>
Viewing RF Management Settings
To view a complete list of 802.11a or 802.11g RF management profiles and their status: show rf dot11a-radio-profile|dot11g-radio-profile
To view the settings of a specific RF management profile: show rf dot11a-radio-profile|dot11g-radio-profile <profile-name>
Assigning a 802.11a/802.11g Profile
To assign an 802.11a or 802.11g RF management profile to an AP group: ap-group <group> dot11a-radio-profile <profile-name>
-orap-group <group> dot11g-radio-profile <profile-name>
ArubaOS 6.5.3.x
| User Guide Access Points | 573
To assign an 802.11a or 802.11g RF management profile to an individual AP: ap-name <name> dot11a-radio-profile <profile-name>
-orap-name <name> dot11g-radio-profile <profile-name>
Deleting a Profile
If no AP or AP group is using an RF management profile, you can delete that profile using the no parameter: no rf dot11a-radio-profile <profile-name>
RF Optimization
Each AP includes an RF Optimization profile that allows you to configure settings for detecting interference.
The controller can detect interference near a wireless client station or AP is based on an increase in the frame retry rate or frame receive error rate.
Using the WebUI
1. Navigate to the Configuration > Wireless > AP Configuration window. Select either the AP Group or
AP Specific tab.
n
If you selected the AP Group tab, click the Edit button by the AP group name for which you want to configure the RF Optimization profile.
n
If you selected the AP Specific tab, click the Edit button by the AP for which you want to create the RF
Optimization profile.
2. Expand the RF Management menu, then expand the RF Optimization Profile menu.
3. Select the profile you want to edit from the Profile Details window pane.
or
Enter a new RF Optimization profile name in the field at the bottom of the Profile Details window, then click Add . Next, select that profile name from the profile list to edit its parameters.
4. Configure your RF Optimization radio settings.
describes the parameters. Click Apply to save your settings.
Table 130: RF Optimization Profile Parameters
Parameter
Station Handoff Assist
RSSI Falloff Wait Time
Low RSSI Threshold
RSSI Check Frequency
Description
Allows the controller to force a client off an AP when the RSSI drops below a defined minimum threshold.
Default: Disabled
Time, in seconds, to wait with decreasing RSSI before a de-authorization message is sent to the client.
Maximum value: 8 seconds
Default : 4 seconds
Minimum RSSI above which de-authorization messages should never be sent.
Default: 10
Interval, in seconds, to sample RSSI.
Default: 3 seconds
Using the CLI
Use the following command to configure RF Optimization profiles. The parameters described in
574 | Access Points ArubaOS 6.5.3.x | User Guide
rf optimization-profile <profile> clone <profile> handoff-assist low-rssi-threshold <number> no ...
rssi-check-frequency <number> rssi-falloff-wait-time <seconds>
RF Event Configuration
An AP’s event threshold profile configures Received Signal Strength Indication (RSSI) metrics, including high and low watermarks for frame error rates and frame retry rates. When certain RF parameters are exceeded, these events can signal excessive load on the network, excessive interference, or faulty equipment.
This profile and many of the detection parameters are disabled (value is 0) by default.
The following procedure details the steps to configure RF Event parameters.
Using the WebUI
1. Navigate to the Configuration > Wireless > AP Configuration window. Select either the AP Group or
AP Specific tab.
n
If you selected the AP Group tab, click the Edit button by the AP group name for which you want to configure the RF Event profile.
n
If you selected the AP Specific tab, click the Edit button by the AP for which you want to create the RF
Event profile.
2. In the Profiles list, expand the RF Management menu, then expand the RF Event Profile menu.
3. To edit an existing RF Event profile, select the profile you want to edit from the Profile Details window pane.
-or-
4. To create a new profile, enter a new RF Event profile name in the field at the bottom of the Profile Details window, then click Add . Next, select that profile name from the profile list to edit its parameters.
5. Configure your settings as detailed in
and click Apply to save your settings.
Table 131: RF Event Thresholds Profile Parameters
Parameter Description
Detect Frame Rate
Anomalies
Bandwidth Rate High
Watermark
Bandwidth Rate Low
Watermark
Frame Error Rate High
Watermark
Enable or disables detection of frame rate anomalies. This feature is disabled by default.
If bandwidth in an AP exceeds this value, a bandwidth exceeded condition exists. The value represents the percentage of maximum for a given radio. (For 802.11b, the maximum bandwidth is 7 Mbps. For 802.11 a and g, the maximum is 30 Mbps.) The recommended value is 85%.
After a bandwidth exceeded condition exists, the condition persists until bandwidth drops below this value. The recommended value is 70%.
If the frame error rate (as a percentage of total frames in an AP) exceeds this value, a frame error rate exceeded condition exists. The recommended value is 16%.
ArubaOS 6.5.3.x
| User Guide Access Points | 575
Parameter Description
Frame Error Rate Low
Watermark
Frame Fragmentation Rate
High Watermark
Frame Fragmentation Rate
Low Watermark
After a frame error rate exceeded condition exists, the condition persists until the frame error rate drops below this value. The recommended value is 8%.
If the frame fragmentation rate (as a percentage of total frames in an
AP) exceeds this value, a frame fragmentation rate exceeded condition exists. The recommended value is 16%.
After a frame fragmentation rate exceeded condition exists, the condition persists until the frame fragmentation rate drops below this value. The recommended value is 8%
Frame Low Speed Rate High
Watermark
Frame Low Speed Rate Low
Watermark
Frame Non Unicast Rate
High Watermark
Frame Non Unicast Rate Low
Watermark
Frame Receive Error Rate
High Watermark
After a non-unicast rate exceeded condition exists, the condition persists until the non-unicast rate drops below this value.
If the frame receive error rate (as a percentage of total frames in an AP) exceeds this value, a frame receive error rate exceeded condition exists.
The recommended value is 16%
Frame Receive Error Rate
Low Watermark
If the rate of low-speed frames (as a percentage of total frames in an AP) exceeds this value, a low-speed rate exceeded condition exists. This could indicate a coverage hole. The recommended value is 16%.
After a low-speed rate exceeded condition exists, the condition persists until the percentage of low-speed frames drops below this value. The recommended value is 8%.
If the non-unicast rate (as a percentage of total frames in an AP) exceeds this value, a non-unicast rate exceeded condition exists. This value depends upon the applications used on the network.
Frame Retry Rate High
Watermark
Frame Retry Rate Low
Watermark
After a frame receive error rate exceeded condition exists, the condition persists until the frame receive error rate drops below this value. The recommended value is 8%.
If the frame retry rate (as a percentage of total frames in an AP) exceeds this value, a frame retry rate exceeded condition exists. The recommended value is 16%.
After a frame retry rate exceeded condition exists, the condition persists until the frame retry rate drops below this value. The recommended value is 8%.
Using the CLI
Use the following command to configure RF event profiles. The available parameters for this profile are detailed in
rf event-thresholds-profile <profile> bwr-high-wm <percent> bwr-low-wm <percent> clone <profile> detect-frame-rate-anomalies fer-high-wm <percent> fer-low-wm <percent> ffr-high-wm <percent> ffr-low-wm <percent> flsr-high-wm <percent> flsr-low-wm <percent> fnur-high-wm <percent> fnur-low-wm <percent>
576 | Access Points ArubaOS 6.5.3.x | User Guide
frer-high-wm <percent> frer-low-wm <percent> frr-high-wm <percent> frr-low-wm <percent>
Optimizing APs Over Low-Speed Links
The ArubaOS AP system profile contains multiple configuration settings to help you validate and optimize your
AP connections to a controller.
This section includes the following information about these features: n n
Optimizing AP Connections over Low-Speed Links on page 577
AP Health Checks
The AP Health check feature uses ping probes to check reachability and latency levels for the connection between the AP and the controller. The recorded latency information appears in the output of the show ap ip health-check command. If the controller IP address becomes unreachable from the AP uplink, this feature records the time that the connection failed, and saves that information in a log file (tmp/ap_hcm_log) on the
AP.
This feature is disabled by default, and is enabled by selecting the Health Check option in the AP system profile. For details see
Optional AP Configuration Settings on page 547
Optimizing AP Connections over Low-Speed Links
Depending on your deployment scenario, you may have APs or remote APs that connect to a controller located across low-speed (less than 1 Mbps capacity) or high-latency (greater than 100 ms) links.
With low-speed links, if heartbeat or keep alive packets are not received between the AP and controller during the defined interval, APs may reboot causing clients to re-associate. You can adjust the bootstrap threshold and prioritize AP heartbeats to optimize these types of links. In addition, high bandwidth applications may saturate low-speed links. For example, if you have tunnel-mode SSIDs, use them with low-bandwidth applications such as barcode scanning, small database lookups, and Telnet to avoid saturating the link. If you have traffic that will remain local, deploying remote APs and configuring SSIDs as bridge-mode SSIDs can also prevent link saturation.
With high-latency links, consider the amount and type of client devices accessing the links. Aruba APs locally process 802.11 probe-requests and probe-responses, but the 802.11 association process requires interaction with the controller.
When deploying APs across low-speed or high-latency links, The following best practices are recommended: n n n n n n
Connect APs and controllers over a link with a capacity of 1 Mbps or greater.
Maintain a minimum link speed of 64 Kbps per AP and per bridge-mode SSID. This is the minimum speed required for downloading software images.
Adjust the bootstrap threshold to 30 if the network experiences packet loss. This makes the AP recover more slowly in the event of a failure, but it will be more tolerant to heartbeat packet loss.
Prioritize AP heartbeats to prevent losing connectivity with the controller.
If possible, reduce the number of tunnel-mode SSIDs. Each SSID creates a tunnel to the controller with its own tunnel keep alive traffic.
If most of the data traffic will remain local to the site, deploy remote APs in bridging mode. For more information about remote APs, see
ArubaOS 6.5.3.x
| User Guide Access Points | 577
n n
If high-latency links such as transoceanic or satellite links are used in the network, deploy a controller geographically close to the APs.
If high-latency causes association issues with certain handheld devices or barcode scanners, check the manufacturer of the device for recent firmware and driver updates.
Configuring the Bootstrap Threshold
To configure the bootstrap threshold using the WebUI:
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. Select either the AP Group or AP Specific tab. Click Edit by the AP group or AP name.
The AP system profile configuration settings are divided into two tabs, Basic and Advanced . The Basic tab displays only those configuration settings that often need to be adjusted to suit a specific network. The
Advanced tab shows all configuration settings, including settings that do not need frequent adjustment or should be kept at their default values. If you change a setting on one tab then click and display the other tab without saving your configuration, that setting will revert to its previous value. Both basic and advanced settings are described in
.
3. Under Profiles, select AP , then AP system profile . The profile appears the Profile Details window.
4. In the Bootstrap threshold field, enter 30.
5. Click Apply .
Table 132: AP System Profile Configuration
Parameter Description
Basic AP System Profile Settings—General
RF Band For APs that support both 802.11a and 802.11b/g RF bands, specify the RF band in which the AP should operate: n g = 2.4 GHz n a = 5 GHz
RF Band for AM Mode scanning For Air Monitors that support both 802.11a and 802.11b/g RF bands, specify the RF band which the AM should scan: n a = 5 GHz n n all = both radio bands g = 2.4 GHz
Native VLAN ID Native VLAN for bridge mode virtual APs (frames on the native VLAN are not tagged with 802.1q tags).
Session ACL
Corporate DNS Domain
SNMP sysContact
LED operating mode
Session ACL configured with the ip access-list session command.
NOTE: This parameter requires the PEFNG license.
Name of domain that is resolved by corporate DNS servers. Use this parameter when configuring split-tunnel forwarding.
SNMP system contact information.
The operating mode for the 802.11n-capable AP LEDs.
LED override Override the LED action for normal LED operation mode . If enabled, LED auto-turn-off function will not work. This feature is supported on AP models with a single LED only.
578 | Access Points ArubaOS 6.5.3.x | User Guide
Parameter
Driver log level
Console log level
SAP MTU
RAP MTU
Flex Radio Mode
Secondary Master IP/FQDN
Description
Enable the level of driver log messages sent to the Syslog server.
n alerts n n critical debugging n n n n n emergencies errors informational notifications warnings
Enable the level of driver log messages sent to the AP console.
n alerts n n n n critical debugging emergencies errors n n n informational notifications warnings
MTU, in bytes, on the wired link for the AP. The supported range is 1024-
1578 bytes.
Configures the maximum size of the GRE packets exchanged between a
RAP and the controller. The supported range is 1024-1578 bytes and the default value is 120 bytes.
Enables the flexible radio mode. The flex-radio can be configured in one of the following modes: n n n
5 GHz mode: acts as a single radio operating on 5 GHz band
2.4 GHz mode: acts as a single radio operating on 2.4 GHz band
2 GHz and 5 GHz mode: acts as two radios (interfaces), one operating on 5 GHz band, and the other on the 2.4 GHz band. By default, the flexible radio is set to this mode.
The secondary master controller is configured to be used when a Remote
AP is not able to reach the primary master controller.
Spanning Tree Select this checkbox to enable the Spanning Tree protocol.
AP Multicast Aggregation
AP ARP attack Protection
Enable multicast aggregation at the AP.
Drop ARP packets coming from wired or wireless clients with AP gateway
IP address. In other words, disallow ARP attack from un-trusted ports.
AP multicast aggregation allowed VLANs
Enable a list of VLANs where AP multicast aggregation is allowed.
Basic AP System Profile Settings—LMS
SAP MTU Maximum Transmission Unit, in bytes, on the wired link for the AP.
ArubaOS 6.5.3.x
| User Guide Access Points | 579
Parameter Description
LMS IP
Backup LMS IP
LMS IPv6
In multi-controller networks, this parameter specifies the IP address of the local management switch (LMS)—the Aruba controller—which is responsible for terminating user traffic from the APs, and processing and forwarding the traffic to the wired network. This can be the IP address of the local or master controller.
When using redundant controllers as the LMS, set this parameter to be the VRRP IP address to ensure that APs always have an active IP address with which to terminate sessions.
NOTE: If the LMS-IP is blank, the access point will remain on the controller that it finds using methods like DNS or DHCP. If an IP address is configured for the LMS IP parameter, the AP will be immediately redirected to the controller at that address.
In multi-controller networks, specifies the IP address of a backup to the IP address specified with the lms-ip parameter.
In multi-controller ipv6 networks, specifies the IPv6 address of the local management switch (LMS)—the controller—which is responsible for terminating user traffic from the APs, and processing and forwarding the traffic to the wired network. This can be the IP address of the local or master controller.
When using redundant controllers as the LMS, set this parameter to be the VRRP IP address to ensure that APs always have an active IP address with which to terminate sessions.
Backup LMS IPv6
LMS Preemption
In multi-controller ipv6 networks, specifies the IPv6 address of a backup to the IPv6 address specified with the lms-ipv6 parameter.
When this parameter is enabled, the AP automatically reverts to the primary LMS IP address when it becomes available.
LMS Hold-down Period
GRE Striping IP
Time, in seconds, that the primary LMS must be available before an AP returns to that LMS after failover.
Specify an IPv4 address for the .g radio of the controller to allow LACP enabled switches to send traffic for the 2 radios on different links.
Recommended value is LMS_IP+1.
Basic AP System Profile Settings—Remote AP
Remote-AP DHCP Server VLAN VLAN ID of the remote AP DHCP server used if the controller is unavailable. This VLAN enables the DHCP server on the AP (also known as the remote AP DHCP server VLAN). If you enter the native VLAN ID, the
DHCP server is unavailable.
Remote-AP DHCP Server Id
Remote-AP DHCP Default
Router
IP address used as the DHCP server identifier.
IP address for the default DHCP router.
Remote-AP DHCP DNS Server
Remote-AP DHCP Pool Start
Remote-AP DHCP Pool End
IP address of the DNS server.
Configures a DHCP pool for remote APs. This is the first IP address of the
DHCP pool.
Configures a DHCP pool for remote APs. This is the last IP address of the
DHCP pool.
580 | Access Points ArubaOS 6.5.3.x | User Guide
Parameter Description
Remote-AP DHCP Pool
Netmask
Remote-AP DHCP Lease Time
Configures a DHCP pool for remote APs. This is the netmask used for the
DHCP pool.
The amount of days that the assigned IP address is valid for the client.
Specify the lease in <days>. A value of 0 indicates the IP address is always valid; the lease does not expire.
This is the total reserved uplink bandwidth (in Kilobits per second).
Remote-AP uplink total bandwidth
Remote-AP bw reservation 1
Remote-AP bw reservation 2
Remote-AP bw reservation 3
Session ACLs with uplink bandwidth reservation in kilobits per second. You can specify up to three session ACLs to reserve uplink bandwidth. The sum of the three uplink bandwidths should not exceed the Remote-AP uplink total bandwidth .
Enable or disable local network access across VLANs in a Remote-AP.
Remote-AP Local Network
Access
IPM Configuration
IPM activation
IPM power reduction steps with priorities
Set IPM power reduction steps and specify their priorities. The available power reductions steps are as follows: n cpu_throttle_25 n n cpu_throttle_50 cpu_throttle_75 n n n n n n disable_alt_eth disable_pse disable_usb radio_2ghz_chain_1x1 radio_2ghz_chain_2x2 radio_2ghz_chain_3x3 n n n n n n n radio_2ghz_power_3dB radio_2ghz_power_6dB radio_5ghz_chain_1x1 radio_5ghz_chain_2x2 radio_5ghz_chain_3x3 radio_5ghz_power_3dB radio_5ghz_power_6dB
Advanced AP System Profile Settings
Bootstrap threshold
Enable Intelligent Power Monitoring (IPM) system on 300 Series, AP-303H,
310 Series, and 330 Series access points. IPM is a feature that actively measures the power utilization of an AP and dynamically adapts to the power resources.
Number of consecutive missed heartbeats on a GRE tunnel (heartbeats are sent once per second on each tunnel) before an AP rebootstraps. On the controller, the GRE tunnel timeout is 1.5 x bootstrap-threshold; the tunnel is torn down after this number of seconds of inactivity on the tunnel. The supported range is 1-65535, and the default value is 8.
ArubaOS 6.5.3.x
| User Guide Access Points | 581
Parameter
Double Encrypt
Dump Server
Heartbeat DSCP
Management DSCP
IP DSCP to VLAN 802.1p
priority mapping
Maintenance Mode
Maximum Request Retries
Request Retry Interval
Number of IPSEC retries
Secondary Master IP/FQDN
Root AP
Description
This parameter applies only to remote APs. Use double encryption for traffic to and from a wireless client that is connected to a tunneled SSID.
When enabled, all traffic is re-encrypted in the IPsec tunnel. When disabled, the wireless frame is only encapsulated inside the IPsec tunnel.
All other types of data traffic between the controller and the AP (wired traffic and traffic from a split-tunneled SSID) are always encrypted in the
IPsec tunnel.
(For debugging purposes.) Specifies the server to receive a core dump generated when an AP process crashes.
NOTE: To send the core dump file to the controller flash memory instead of a dump server, access the command-line interface and issue the command ap-crash-transfer .
Assign a DSCP value to AP heartbeats to prioritize heartbeats traveling over low-speed links. The supported range is 0-63, and the default value is
0. For more information, see
Prioritizing AP heartbeats on page 585
.
Management traffic on the AP can be marked with Differentiated Service
Code Point (DSCP) values to apply a priority level to that traffic.
Use this parameter to map IP DSCP QoS priorities to VLAN 802.1p
priorities at the AP's media access control (MAC) level.
To configure multiple mapping pairs, separate each pair by a comma. For example, 14:2,16:4,40:6,48:6 .
Enable or disable AP maintenance mode.
This setting is useful when deploying, maintaining, or upgrading the network.
If enabled, APs stop flooding unnecessary traps and syslog messages to network management systems or network operations centers when deploying, maintaining, or upgrading the network. The controller still generates debug syslog messages if debug logging is enabled.
Maximum number of times to retry AP-generated requests, including keepalive messages. After the maximum number of retries, the AP either tries the IP address specified by the bkup-lms-ip (if configured) or reboots.
Interval, in seconds, between the first and second retries of AP-generated requests. If the configured interval is less than 30 seconds, the interval for subsequent retries is increased up to 30 seconds.
Number of times the AP will try to create an IPsec tunnel with the master controller before the AP will reboot. If you specify a value of 0, and AP will not reboot if it cannot create the IPsec tunnel. The supported range of values is 0-1000 retries, and the default value is 85 retries.
The secondary master controller is configured to be used when a Remote
AP is not able to reach the primary master controller.
Defines a remote AP as the root AP in a branch network with a multi-AP hierarchy.
582 | Access Points ArubaOS 6.5.3.x | User Guide
Parameter
AeroScout RTLS Server
RTLS Server configuration
RTLS Server Compatibility
Mode
Slow Timer Recovery by
Rebooting Itself
Telnet
Disable RAP TFTP Image
Upgrade
Spanning Tree
AP Multicast Aggregation
AP ARP attack Protection
Console Enable
AP Console Protection
AP Console Password
Password for Backup
AP USB power Override
Description
Enables the AP to send AeroScout tag information to an RTLS server. You must specify the IP address or DNS server and port number of the server to which location reports are sent.
RTLS station reporting includes information for APs and the clients that the AP has detected. If you select the Include Unassociated Stations option, the station reports will also include information about clients not associated to any AP. By default, unassociated clients are not included in station reports.
Enables the AP to send RFID tag information to an RTLS server. You must specify the IP address or DNS server and port number of the server to which location reports are sent, a shared secret key, and the frequency at which packets are sent to the server.
RTLS station reporting includes information for APs and the clients that the AP has detected. If you select the Include Unassociated Stations option, the station reports will also include information about clients not associated to any AP. By default, unassociated clients are not included in station reports. For more information on configuring RTLS server configuration, see
Defining an RTLS Server on page 553
.
The compatibility mode controls the format of tag frames forwarded to the RTLS server. Enabling this mode will enable legacy format (which includes a 2 byte padding), and disabling this mode will remove the padding. The tag frame format will be the same across all AP models.
When enabled, the slow timer recovery feature checks to see if the AP
CPU timer is slow. If it is slow, the AP will restart itself and log the reason for the reboot. This feature is only supported on AP-103H, and RAP-108 and RAP-109, which are the only devices that may encounter the slow timer issue.
Select this checkbox to enable telnet to the AP.
Disable TFTP image upgrades for a remote AP.
Select this checkbox to enable the Spanning Tree protocol.
Enable multicast aggregation at the AP.
Drop ARP packets coming from wired or wireless clients with AP gateway
IP address. In other words, disallow ARP attack from un-trusted ports.
Enable the console port on the AP.
Enable the AP console password.
Set the AP console password on the controller. If the user does not set any password, the controller generates a default random password which can be viewed by executing the encrypt disable command followed by the show ap system-profile <profile-name> command.
Set a WPA passphrase to generate a pre-shared key for a backup Virtual
AP.
Enabling override enables the USB port of the AP with POE AT power.
ArubaOS 6.5.3.x
| User Guide Access Points | 583
Parameter
RF Band for Backup
Operation for Backup
BLE Endpoint URL
BLE Auth Token
BLE Operation Mode
Health Check
Health Check Parameter
Description
Band on which the controller broadcasts the backup ESSID.
This parameter allows AP console access using a backup ESSID, allowing users to access an AP console after the AP has disconnected from the controller. When the AP advertises a backup ESSID in either static or dynamic mode, a user is able to access and debug the AP remotely through a virtual AP.
Select dynamic or static to enable this feature and select the mode by which the controller broadcasts the backup ESSID. This feature is disabled by default.
URL of the Meridian server to which the BLE sends monitoring data.
The Bluetooth Low Energy (BLE) endpoint authorization token is a text string of 1-255 characters used by the BLE to authorize to and securely communicate with the Beacon Management Console. This token is unique for each deployment.
Determines how the built-in Bluetooth Low Energy (BLE) chip in the AP functions. BLE chip can be in one of the following four modes: n Beaconing : The AP's built-in BLE chip functions as an iBeacon combined with beacon management functionality.
n n
Disabled : The AP's built-in BLE chip is turned off. This is the default setting.
DynamicConsole : The AP's built-in chip functions as a regular iBeacon combined with beacon management functionality. However, when the link to the controller is lost, the built-in chip temporarily enables access to the AP console over BLE. This state of the BLE device may be rolled back to any of the other modes if the AP receives a different configuration setting for the ble-op-mode parameter from the new
LMS.
n PersistentConsole : The AP's built-in chip provides access to the AP console over BLE using a mobile application. This functionality is the superset of the Beaconing mode.
NOTE: BLE is disabled on ArubaOS FIPS build.
The AP Health check feature configured via the health-check parameters uses ping probes to check reachablility and latency levels for the connection between the AP and the controller. Recorded latency information appears in the output of the show ap ip health-check command. If the controller IP address becomes unreachable from the AP uplink, this feature records the time that the connection failed, and saves that information in a log file (tmp/ap_hcm_log) on the AP.
The following parameters configure the health check feature.
n mode : Ping probe mode is the only mode currently supported by this feature.
n n
Packetsize : Number of probes to be sent during the probe frequency interval defined by the frequency health-check parameter.
burstcnt : Number of probes to be sent during the probe frequency interval defined by the Freq health-check parameter.
n n n
Freq : Probe interval, in seconds. The WAN health-check feature sends the number of probes defined by the burst-size parameter during each frequency interval defined by this frequency parameter.
report : Number of seconds between health check reports sent from the AP to the . usage reports.
packetsize : The size, in bytes, of a ping datagram.
584 | Access Points ArubaOS 6.5.3.x | User Guide
Parameter
AirMatch Report Period
AirMatch Measurement
Duration
AirMatch Report Enabled
Description
Use this parameter to change the frequency period which AirMatch starts measuring the RF environment. The default value is 30 minutes and the supported range of values is 5-180 minutes.
Change the AirMatch RF measurement duration from the default value of five minutes to any value from 5-60 minutes. A value of 0 disables
AirMatch RF environment measurements.
When enabled, each AP measures its RF environment for a duration specified by the AirMatch Measurement Duration parameter, every 30 minutes by default. The controller uses this information to compute an optimal solution.
To configure the bootstrap threshold using the command-line interface, access the CLI in config mode and issue the following command: ap system-profile <profile> bootstrap-threshold 30
Prioritizing AP heartbeats
If the AP heartbeat or keep alive packets sent between the APs and controller are not received during the defined interval, the APs may reboot, causing clients to re-associate. If a high-latency or low-speed link prevents
AP heartbeats from being sent and received correctly, you can assign a DSCP value to AP heartbeats to prioritize the heartbeats.
To prioritize AP heartbeats using the WebUI:
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. Select either the AP Group or AP Specific tab. Click Edit for the AP group or AP name.
3. Under Profiles, select AP , then AP system profile . The configuration settings are displayed in Profile
Details.
4. Under Profile Details: a. In the Heartbeat DSCP field, enter a value greater than zero.
b. Click Apply .
To prioritize AP heartbeats using the command-line interface, access the CLI in config mode and issue the following command: ap system-profile <profile>
heartbeat-dscp <number>
Use the following commands: show ap config {ap-group <name>|ap-name <name>|essid <name>} show ap debug system-status {ap-name <name>|bssid <name>| ip-addr <ipaddr>}
On the local controller, you can also view maintenance mode status using the following commands: show ap active {ap-name <name>|essid <name>|ip-addr <ipaddr>} show ap database show ap details {ap-name <name>|bssid <name>|ip-addr <ipaddr>}
AP Scanning Optimization
The scanning algorithm is enhanced to reduce the delay between visits to some channel types, by changing their scan priority.
ArubaOS 6.5.3.x
| User Guide Access Points | 585
Channel Types and Priority
A channel can belong to one or more channel types, depending on regulatory information and the activity that is detected on the channel. The frequency of visits to a channel depends on the priority of the channel type(s) to which it belongs. The following table describes the priority of channel types.
Table 133: Channel Types and Priority
Channel Priority Channel Type
One DOS Channels
Two
Three
Four
Five
Six
Active Channels
Reg-Domain Channels
All Reg-Domain Channels
Unconventional Scan
Channels
Rare Channels
Description
Channels where the AP is actively containing one more rogue devices in AM mode are marked with an O flag in the
ARM CLI output ( show ap arm scan-times ).
Channels where AP or Station activity has already been detected are marked with an A flag in the ARM CLI output and are visited in all scan-modes.
Channels that are in the AP’s regulatory domain are marked with a C flag in the ARM CLI output and are visited in all scan modes.
Channels that belong to any country’s regulatory domain are marked with a D flag in the ARM CLI output and are visited only if the scan-mode is set to All-Reg or Rare .
This new channel type category contains channels that belong to any country’s regulatory domain, but with an unconventional scan direction. These channels are marked with a J or M flag in the ARM CLI output and are visited only if scan-mode is set to All-Reg or Rare .
Channels that do not belong to any country’s regulatory domain are marked with a Z flag in the ARM CLI output.
Rare channel scanning is done in the AM mode only if the rare scan mode is selected in the AM Scanning profile.
The country code in the AP Regulatory Domain profile determines supported channel and channel pairs for that specific AP. If there is a change in the country code, the valid channel list is reset to the default value for that country.
In the CLI
The show ap arm scan-times ap-name <ap_name> command is used to show scan state and flags for each channel.
(host)(config) #show ap arm scan-times ap-name <ap-name>
Scanning Optimizations
The following optimizations are introduced in ArubaOS 6.4.3, to enable the AP to achieve optimum RF monitoring. Unconventional Scans and Relative Priority of Channel Type Categories optimization apply to all AP types, but Channel Group Scanning optimization applies only to 200 Series models. All optimizations apply to
AP and AM mode scanning.
Unconventional (direction) Scans n
Unconventional scans are 40MHz scans of a channel in the direction away from the channel pair. For example, in the 44-48 channel pair: l
Conventional scans will be 44+ and 48-
586 | Access Points ArubaOS 6.5.3.x | User Guide
n n l
Unconventional scans will be 44- and 48+
Unconventional scans are no longer interspersed with conventional scans. Unconventional scans operate with a lower frequency, because they belong to a new low priority channel type.
Unconventional scans are performed in all-regulatory and rare scan modes. But these scans will not be performed if the scan mode is set to regulatory domain. This modification enables the AP to scan through active channels, regulatory channels, and all-regulatory channels faster.
Currently, 200 Series access points do not support unconventional or rare channel scanning.
Modifications in Scan Frequency
A modification is introduced to increase the frequency of visits to active and regulatory domain channels.
Channel type categories are: n n n n n
DOS
Active
Regulatory domain
All-regulatory domain
Unconventional or rare
Unconventional or rare channels are merged for scanning.
Channel Group Scanning
Since a 11ac AP radio can hear frames sub-channels when it performs an 80MHz wide scan, scanning can be optimized by categorizing channels into scan groups, which are visited sequentially when a new primary channel is selected. This allows the AP scan through the list of channels faster, so that the delay between visits to channels in a group is reduced.
For more information on Channel Group Scanning, see
Channel Group Scanning on page 587
n n n n
Channel Group Scanning
The following section describes channel group scanning:
Channel groups can be 80MHz (4 channels), 40MHz (2 channels), or 20MHz wide (1 channel).
Each channel is mapped to a group depending on the maximum width supported by that channel and the radio’s capability. The maximum width supported by a channel is determined by the channel’s membership in regulatory domain channel pairs or groups.
l l
Channel 36, 40, 44, and 48 belong to 80MHz group
Channel 165 belongs to 20MHz group
Channel groups are visited sequentially and the primary channel is rotated after each visit.
Group scanning behavior is performed for 200 Series access points on A-band channels.
Scanning only once in each 80MHz wide group allows the AP to scan through the channel list faster and also hear frames on sub-channels.
ArubaOS 6.5.3.x
| User Guide Access Points | 587
Configuring AP Channel Assignments
The country code in the AP Regulatory Domain profile determines supported channel and channel pairs for that specific AP. Any changes to the country code causes the valid channel lists to be reset to the defaults for the country.
The example in this section illustrates how to perform the following tasks for an AP group:
1. Configure the “default” regulatory domain profile to use a valid country code. (In this example, the country code US .) This will determine the available channels.
2. Configure a 40 MHz channel (bonded pair) for the AP group’s 802.11a (5 GHz) radio profile.
3. Configure a 20 MHz channel for the AP group’s 802.11g (2.4 GHz) radio profile.
This example uses default ARM profile settings and the recommended high-throughput channel assignments for the
802.11a and 802.11b/g bands. If you want the channel assignments to utilize high-throughput, ensure that highthroughput is enabled within the radio profile. For details, see
802.11a and 802.11g RF Management Profiles on page
.
Using the WebUI
1. Navigate to Configuration > Wireless > AP Configuration > AP Group page.
2. Click the Edit button by the name of the AP group to which you want to assign specific channels.
3. In the Profiles list, expand the AP menu to display the AP profiles used by the AP group.
4. Select the Regulatory Domain profile named default .
5. Click the Country Code drop-down menu and select the US-United States domain if it is not already selected.
The Regulatory Domain’s country code determines which channels are selected in the following fields: n
Valid 802.11g channel n n
Valid 802.11a channel
Valid 802.11g 40MHz channel pair n n
Valid 802.11a 40MHz channel pair
Valid 802.11a 80MHz channel group n
Valid 802.11a 160MHz channel group
If none of the channels supported by the AP have received regulatory approval by the country whose country code you selected, the AP will revert to Air Monitor mode.
6. In the Valid 802.11a 80MHz channel group field, define which 80MHz channels on the 802.11a band are available for assignment by ARM and for the controller to randomly assign if user has not specified a channel. The channel numbers below correspond to channel center frequency.
n n
Possible choices in US: 42, 58, 106, 122, 138, 155
Possible choices in EU: 42, 58, 106, 122 n n
Possible choices in JP: 42, 58, 106, 122
Possible global choices: 42, 58, 106, 122, 138, 155
7. Click Apply .
8. Under the Profiles list, expand the RF Management menu.
9. Select the 802.11a radio profile used by the AP group
10.Enter
36 in the Channel text field and select the Above radio button. In this instance, channel 36 becomes the primary channel and the secondary channel is 40.
11.Click
Apply .
12.Under the Profiles list select the 802.11g radio profile used by the AP group.
588 | Access Points ArubaOS 6.5.3.x | User Guide
13.Enter
1 in the Channel text field and select None . In this instance, channel 1 is the assigned 20 MHz channel and 40 MHz mode is disabled.
14.Click
Apply .
Using the CLI
Country codes are generally specified in ISO 3166 format. To see what channels are available for a given country code, use the show ap allowed-channels <country-code> command can be used.
ap regulatory-domain-profile default
country-code US rf dot11a-radio-profile ht-corpnet-a
channel 36+ rf dot11g-radio-profile ht-corpnet-g
channel 1
Country codes are generally specified in ISO 3166 format. To see what channels are available for a given country code, use the show ap allowed-channels country-code <country-code> command.
Channel Switch Announcement (CSA)
When an AP changes its channel, an existing wireless clients may “time out” while waiting to receive a new beacon from the AP; the client must begin scanning to discover the new channel on which the AP is operating.
If the disruption is long enough, the client may need to reassociate, reauthenticate, and request an IP address.
Channel Switch Announcement (CSA), as defined by IEEE 802.11h, enables an AP to announce that it is switching to a new channel before it begins transmitting on that channel. This allows the clients, who support
CSA, to transition to the new channel with minimal downtime.
When CSA is enabled, the AP does not change to a new channel immediately. Instead, it sends a number of beacons (the default is 4) which contain the CSA announcement before it switches to the new channel. You can configure the number of announcements sent before the change.
Clients must support CSA in order to track the channel change without experiencing disruption.
Using the WebUI
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. Select either the AP Group or AP Specific tab. Click Edit for the AP group or AP name.
3. Select RF Management in the Profile list.
4. Select the 802.11a or 802.11g radio profile.
5. Select Enable CSA . You can configure a different value for CSA Count.
6. Click Apply .
Using the CLI rf radio-profile <profile>
csa
csa-count <number>
Automatic Channel and Transmit Power Selection
To allow automatic channel and transmit power selection based on the radio environment, enable Adaptive
Radio Management (ARM). Note that ARM assignments will override the static channel and power configurations done using the radio profile. For complete information on the Adaptive Radio Management feature, refer to
Adaptive Radio Management on page 455 .
ArubaOS 6.5.3.x
| User Guide Access Points | 589
Managing AP Console Settings
An AP’s provisioning parameters are unique to each AP. These parameters are initially configured on the controller and then pushed out to the AP and stored on the AP itself. Best practices are to configure an AP’s provisioning settings using the controller WebUI. If you find it necessary to alter an AP’s provisioning settings for troubleshooting purposes, you can do so using the controller WebUI and CLI, or alternatively, through a console connection to the AP itself.
To create a console connection to the AP:
1. Connect a local console to the serial port on the AP. You can connect the AP’s serial port to a terminal or terminal server using an Ethernet cable, or connect the serial console port to a DB-9 adapter, then connect the adapter to a laptop using an RS-232 cable. For details on connecting to an AP’s serial console port, refer to the Installation Guide included with the AP.
2. Establish a console communication to the AP, then power-cycle the AP to reboot it.
3. To access the AP console command prompt, press Enter when the AP displays the message “ Hit <Enter> to stop autoboot.
” If the autoboot countdown expires before you can interrupt it, turn the device off and then back on.
4. Once the AP boot prompt appears, enter the AP console password. You can issue any of the AP provisioning commands described in the
. Remember, though these commands may be useful for troubleshooting, they are all optional and are not necessary for normal AP provisioning.
Table 134: AP Boot Commands
The list of AP boot commands may vary based on the APBoot image version.
Command boot clear dhcp factory_reset flash help mfginfo osinfo
Description
Boot the ArubaOS image from flash or USB, using currently saved environment variables. Any unsaved changes to the variables will be lost.
This command has the following sub-parameters: n n ap - Boot the ArubaOS image from flash.
usb:<path> - Boot the ArubaOS image from USB.
Clear the ArubaOS image or other information. This command has the following sub-parameters: n n all - Clear the cache and ArubaOS.
cache - Clear the cache sectors (mesh, RAP, CAP).
n n os <n> - Clear the image from the specified partition (default: 0).
prov - Clear provisioning image from the flash.
Invoke DHCP client to obtain IP/boot parameters.
Reset the AP to factory default.
Upgrade the boot image.
NOTE: Exercise caution when using this command.
Help text for the AP boot commands.
Shows manufacturing information of the AP.
Shows the ArubaOS image information on the AP.
590 | Access Points ArubaOS 6.5.3.x | User Guide
Command Description ping printenv purgeenv reset saveenv setenv ipaddr <ipaddr> setenv netmask <netmaskip> setenv gatewayip <ipaddr> setenv name <ap name> setenv group <group name> setenv master <ipaddr> setenv serverip <ipaddr>
Check network connectivity.
List the environment variables and their current settings. AP boot environment variables are configured using the AP boot setenv command,
Reinstate AP boot configuration to factory default. This includes restoring the default environment variables.
Perform RESET of the AP CPU.
Save environment variables to persistent storage.
IP address to be assigned to the AP.
Netmask to be assigned to the AP.
IP address of the internet gateway used by the AP.
Name of the AP.
Name of the AP group to which the AP should belong.
IP address of the AP’s master controller.
IP address of the TFTP server from which the AP can download its boot image.
setenv dnsip <ipaddr> IP address of the DNS server used by the AP.
setenv domainname <domain> Domain name used by the AP.
tftpboot upgrade version
Boot ArubaOS image over the network using TFTP protocol.
Upgrade the APBoot or ArubaOS image. This command has the following sub-parameters: n boot <file> - Upgrade the APBoot image from <file>.
n os [<n>] <file> - Upgrade the ArubaOS image in partition <n> from
<file>.
n prov - Upgrade provisioning image from <file>.
NOTE: <file> can be a <TFTP-server-IP>:<path> or usb:<path>.
Displays the APBoot image version.
5. When you are finished, type saveenv and then press enter to save your settings
Other AP console commands may be available when accessing an AP directly through its console port, but these commands can cause configuration errors if used improperly and should only be issued under the direct supervision of Aruba technical support.
The example below configures an AP location and domain name using an AP console connection:
Hit <Enter> to stop autoboot: 0 apboot> <INTERRUPT> apboot> setenv group corporate-2 apboot> setenv domainname mycompany.com
apboot> saveenv apboot>boot
ArubaOS 6.5.3.x
| User Guide Access Points | 591
To view current AP settings using the AP console, issue the command printenv <name> where <name> is one of the variable names listed in
ipaddr , dnsip or gatewayip .
apboot> printenv domainname domainname=mycompany.com
AP Console Password Protection
The ArubaOS AP console password feature helps protect systems that manage highly sensitive information, like financial and banking institutions, by requiring users to log in to the AP network with a password. The AP console password is enabled by default. Passwords must be 6 to 32 characters in length, and can include alphanumeric and special characters. If configured, you must enter this password to get AP console access. If not configured, the controller generates a default random password which can be viewed by executing the encrypt disable command followed by the show ap system-profile <profile-name> command.
The timeout feature is also supported as an added level of security. If there is no user input or activity during one timeout interval (default of 30 minutes), the user is logged out of the system. The timeout interval cannot be modified.
Setting an AP Console Password
You can configure an AP console password using the controller WebUI or CLI.
In the WebUI
To set a password in the WebUI:
1. Navigate to Configuration > Advanced Services > All Profiles .
2. Expand the AP tab, then click on AP System .
3. Under the AP System list, select the AP system you want to modify.
4. On the Advanced tab, check the Console Enable checkbox.
5. In the AP Console Password field, enter the desired AP console password. Retype the password to confirm.
6. Click the AP Console Protection check box to enable the AP console password.
Once the console is enabled, you do not need to enable it again. The console access is password protected.
7. Click Apply , then Save Configuration to save your changes.
In the CLI
To set the AP console password in the CLI:
(host) (config) #ap system-profile <profile>
(host) (AP system profile “<profile>") #console-enable
(host) (AP system profile “<profile>”) #ap-console-password <ap-console-password>
(host) (AP system profile “<profile>”) #ap-console-protection
To disable the AP console password in the CLI:
(host) (config) #ap system-profile <profile>
(host) (AP system profile “<profile>”) #no ap-console-password
If the password is lost, and the AP is not connected to a controller, the console can be reset using the reset button on the AP or the factory_reset AP boot command. If it is already connected to a controller, the AP password can be changed under the AP Console Password field of the AP System profile in the WebUI, or using the ap-console-password parameter of the ap system-profile command in the CLI.
592 | Access Points ArubaOS 6.5.3.x | User Guide
Disabling Access to the AP Console
Another way to protect your AP system is to completely disable access to the AP console under enabled mode.
In the WebUI
To disable access to the console in the WebUI:
1. Navigate to Configuration > Advanced Services > All Profiles .
2. Expand the AP tab, then click on AP System .
3. Under the AP System list, select the AP system you want to modify.
4. Click on the Advanced tab, then scroll down to Console Enable .
5. Clear the Console Enable checkbox.
6. Click Apply , then Save Configuration to save your changes.
In the CLI
To disable access to the console in the CLI:
(host) (config) #ap system profile default
(host) (AP system profile “default”) #no console-enable
Link Aggregation Support on 220 Series, 270 Series, 320 Series, and
330 Series
220 Series , 270 Series, 320 Series, and 330 Series access points support link aggregation using either static port channel (configuration based) or Link Aggregation Control Protocol (protocol signaling based). These access points can optionally be deployed with LACP configuration to benefit from higher (greater than 1 Gbps) aggregate throughput capabilities.
The controller uses two different IP addresses for forwarding traffic to wireless clients associated to tunnel mode or decrypt-tunnel mode VAPs. One IP address is controller's IP address and the other is an unassigned IP address called GRE striping IP. Select the GRE striping IP address to ensure that a different physical interface is used by the load-balancing algorithm on the Ethernet switch. This enables the 220 Series , 270 Series, 320
Series, and 330 Series access points achieve greater than 1 Gbps throughput in both upstream and downstream directions.
On 200 Series and 270 Series access points, different IP addresses are used for different GRE tunnels between the AP and the controller. One controller IP address is used for tunnels corresponding to virtual APs using a 5G radio and the other controller IP address is used for tunnels corresponding to virtual APs using a 2.4G radio. By associating clients on both bands you can achieve more than 1 Gbps throughput.
On 320 Series and 330 Series access points, both IP addresses are used for GRE tunnels of virtual APs on 5G radio. By associating one 4x4 802.11ac client or multiple clients on you can achieve more than 1 Gbps throughput.
ArubaOS 6.4.2.0 introduces a local AP LACP LMS map information profile that maps a LMS IP address to a GRE striping IP address. If the AP fails over to a standby or backup controller, the AP LACP LMS map information profile on the new controller defines the striping IP address that the AP uses for link aggregation. This feature allows 220 Series , 270 Series, and 320 Series access points to continue to support link aggregation to a backup controller in the event of a controller failover, even if the backup controller is in a different L3 network.
In previous releases, the GRE striping IP address was defined in the global AP system profile, which did not allow APs to maintain GRE striping tunnels if the AP failed over to a backup controller in a different L3 network.
ArubaOS 6.5.3.x
| User Guide Access Points | 593
Using the WebUI
Follow the procedure to configure the LACP parameters in the AP System profile and AP LACP LMS map information profile.
On a master controller
1. Access the active controller and navigate to the Configuration > Advanced Services > All Profiles page.
2. Expand the AP profiles menu in the Profiles pane.
3. Expand the AP System profiles menu, and select the AP system profile you want to modify.
4. Select the Basic tab on the Profile Details pane, locate the LMS Settings section and specify a unique
IPv4 address in the LMS IP field.
5. Select Profiles and expand the AP profiles menu.
6. Select the AP LACP LMS map information profile.
7. Select the AP LACP Striping IP check box to enable the AP LACP striping IP feature.
8. Enter a GRE striping IP address in the IP field. This IP address must be a in the device's subnet.
9. In the LMS field, enter the LMS IP address specified in the device's AP system profile in the LMS field. This
LMS IP address must match the LMS IP address in the device's AP system profile.
10.Click
Add .
11.Click
Apply .
On an L2-connected High Availability (HA) standby or HA+VRRP controller:
1. Navigate to the Configuration > Advanced Services > All Profiles page.
2. Expand the AP profiles menu in the Profiles pane.
3. Select the AP LACP LMS map information profile.
4. Select the AP LACP Striping IP check box to enable the AP LACP striping IP feature.
5. Enter a GRE striping IP address in the IP field. This IP address must be in the controller's subnet.
6. In the LMS field, enter the LMS IP address specified in the device's AP system profile. This LMS IP address must exactly match the LMS IP address in the AP system profile configuration used by the device.
7. Click Add .
8. Click Apply .
For topologies using L3-connected High Availability (HA) standby controllers, or L2- or L3connected controllers in dual-HA mode:
When using high availability between two L3-connected controllers or two dual-mode HA controllers, you must define two different striping IPs (one in each controller subnet) to ensure that both the controllers will have striping IPs mapped to their corresponding LMS IP address.
When two controllers are both deployed in dual HA mode, each dual-mode controller acts as standby for the APs served by the other dual-mode controller. Each controller must therefore have two striping IPs, one for in each controller subnet. Two striping IP addresses are required for these topologies, even if the dual-HA controllers are located within the same subnet.
1. Navigate to the Configuration > Advanced Services > All Profiles page.
2. Expand the AP profiles menu in the Profiles pane.
3. Select the AP LACP LMS map information profile.
4. Select the AP LACP Striping IP check box to enable the AP LACP striping IP feature.
5. Enter a GRE striping IP address in the IP field. This IP address must be in the controller's subnet.
594 | Access Points ArubaOS 6.5.3.x | User Guide
6. In the LMS field, enter the LMS IP address specified in the device's AP system profile. This LMS IP address must exactly match the LMS IP address in the AP system profile configuration used by the device.
7. Click Add .
8. Enter a second GRE striping IP address in the IP field. This IP address must be in the subnet of the other controller.
9. In the LMS field, enter the LMS IP address specified in the device's AP system profile. This LMS IP address must exactly match the LMS IP address in the AP system profile configuration used by the device.
10.Click
Add .Click
Apply .
Using the CLI
Execute the following commands to configure AP LACP and striping IP on a HA standby or backup LMS.
On the master controller
(host) (config) #ap system-profile LACP
(host) (AP system-profile "LACP") #lms-ip 192.0.2.1
(host) (AP system-profile "LACP") #bkup-lms-ip 192.0.77.1
(host) (AP system-profile "LACP") #exit
(host) (config) #ap-lacp-striping-ip
(host) (AP LACP LMS map information) #striping-ip 192.0.2.2 lms 192.0.2.1
(host) (AP LACP LMS map information) #aplacp-enable
On an L2-connected High Availability (HA) controller that does NOT use dual-mode HA:
(bkup-host) (config) #ap-lacp-striping-ip
(bkup-host) (config) (AP LACP LMS map information) #striping-ip
192.0.2.16 lms 192.0.2.1
(bkup-host) (config)(AP LACP LMS map information) #aplacp-enable
On L3-connected High Availability (HA) standby controllers, or HA controllers in dual HA mode, where each dual-mode controller acts as standby for the APs served by the other dual-mode controller:
(bkup-host) (config) #ap-lacp-striping-ip
(bkup-host) (config) (AP LACP LMS map information) #striping-ip
10.1.1.14 lms 192.0.2.1
(bkup-host) (config) (AP LACP LMS map information) #striping-ip
192.0.2.2 lms 192.0.2.1
(bkup-host) (config)(AP LACP LMS map information) #aplacp-enable
If you are using High Availability between L3-connected or dual-mode controllers, you must configure two different striping IPs (one for each subnet) to ensure that both controllers will have striping IPs mapped to the corresponding
LMS IP address.
Important Points to Remember
n n n
In the upstream direction when the AP transmits GRE frames to the controller, the bonding driver must be in active-active mode and not in the default active-standby mode to allow link aggregation.
If an AP’s uplink access switch ports are configured in static port-channel mode, then the AP will set the
Ethernet bonding mode to static port-channel (xor mode) only if gre-striping-ip is configured. If grestriping-ip is not configured, then the AP goes back to active-standby mode. In this scenario, the AP may go down depending on the behavior of the upstream switch.
If an AP’s uplink access switch ports are configured in dynamic LACP mode, the AP detects LACP-PDUs and automatically sets the Ethernet bonding mode to LACP. If gre-striping-ip is not configured, then the AP’s
Ethernet bonding mode will continue to be in LACP mode, but the AP will send GRE traffic only through one
Ethernet port.
ArubaOS 6.5.3.x
| User Guide Access Points | 595
n n n n n n n n
In AP-324/AP-325 access points, if AP uplink packet capture is taken, the downstream traffic will have sequence number in GRE header. Wireshark Aruba wlan decoder will not be able to decode these packets correctly since it looks for known Aruba GRE tunnel IDs.
Ensure that the gre-striping-ip is unique and not used by any other host on the subnet.
LACP support is limited to a use case where Enet 0 and Enet 1 ports of the AP are connected to a switch, and
LACP is enabled on the two corresponding switch ports.
The port priority is not applicable to the AP as both ports need to be used. This value is always set to the maximum numerical priority (0xFF), which is the lowest priority.
The system priority is not configurable. It is set to the maximum numerical value (0xFFFF), which is the lowest priority. This leaves control of the aggregate to the upstream switch.
The timeout value is not configurable.
The key is not configurable and the default key value is 1.
LACP cannot be enabled if wired AP functionality is enabled on the second port. You cannot enable LACP if the Enet 1 port is shutdown.
Troubleshooting Link Aggregation
The following show commands in the CLI can be used to troubleshoot Link Aggregation on 220 Series , 270
Series, and 320 Series access points: n n n n n n n show ap debug lacp ap-name <ap-name> —Using this command, you can view if LACP is active on an
AP. It displays the number of GRE packets sent and received on the two Ethernet ports. Using this command with verbose option on AP-324/AP-325 access points displays packet re-ordering statistics of each wlan client.
show ap database —Starting with ArubaOS 6.4.2, the output of this command includes an LACP Striping flag (s) to indicate of the AP is configured with a LACP striping IP address, show datapath tunnel —Using this command on 220 Series/270 Series access points, you can verify if the
2.4GHz tunnels are anchored on the gre-striping-ip (The GRE IDs for these tunnels are in a range between
0x8300 and 0x83F0) . On AP-324/AP-325 access points, use the verbose option to verify that 5GHz tunnels have striping IP set in the column StripIP (The GRE IDs for these tunnels are in a range between 0x8200 and
0x82F0).
show datapath station —On AP-324/AP-325 access points, using this command displays the LACP sequence number sent in the GRE header of the last packet to the client. This information is displayed under Seq column.
show ap remote debug anul-sta-entries —On AP-324/AP-325 access points, using this command displays LAG enabled/disabled per station and data drops due to LAG packet reordering.
show datapath user —Using this command, you can verify if the gre-striping-ip has an entry with the ‘L’
(local) flag show datapath route-cache —Using this command, you can verify if the gre-striping-ip has an entry with the controller MAC.
Recording Consolidated AP-Provisioned Information
Starting from ArubaOS 6.5, a new feature that records the consolidated AP-provisioned information is introduced. This is especially handy when you upgrade the APs from ArubaOS 6.x to ArubaOS 8.0 version.
The DNS or the DHCP configuration can change over time in a customer’s network environment and the existing features might not provide adequate information about whether an AP has not rebooted at all. Also, a
DHCP scope change might affect an AP’s connectivity with the controller after the AP reboots. In such situations, where an AP does not come UP after a reboot, it would help troubleshooting when information
596 | Access Points ArubaOS 6.5.3.x | User Guide
about how the AP was provisioned is available. Hence this new feature to have a consolidated record of APprovisioned information is introduced.
This consolidated AP-provisioned information will include the following data: static IP, dynamic IP, DHCP, DNS,
Master information, previous local management switch (LMS) information, and more. The list of directories and files where the consolidated AP-provisioned information will be available is provided in the following table.
Table 135: List of Directories and Files for Consolidated AP-Provisioned Info
Information
DHCPv4
Directory/Location File
/tmp/provision_record_info dynamic_ipv4_info
DHCPv6
Master
Previous LMS
/tmp/provision_record_info static_ipv4_info
/tmp/provision_record_info static_ipv6_info
/tmp/provision_record_info dhcpv6_ipaddr_file
/tmp/provision_record_info dhcpv6_dns_server_file
/tmp/provision_record_info ra_prefix_file
/tmp/provision_record_info ra_dns_server_file
/tmp/master
/tmp/discover_type lms addrs array
Description of File Content
AP dynamic ipaddr, netmask, gateway, IP lease, DHCP server,
DNS server
AP static ipaddr, netmask, gateway, DNS server
AP static IPv6 addr, gatewayip6, dnsip6
AP dynamic IPv6 addr, IPv6 lease got from DHCPv6 Reply packet
DNS serverip got from DHCPv6
Reply packet ipv6 prefix, prefix len, ipv6 lease got from route advertisement dns serverip got from route advertisement master IP info
Information on how master IP is discovered
SAPD resolve master, serverip, servername
Consolidated AP-Provisioned Information from AP
When an AP loses connection with the controller, the AP’s provisioning information can be retrieved through the AP console. The consolidated AP-provisioned information can be accessed by executing the following shell script after logging in to the AP through console or backup-SSID:
/aruba/bin/provision_record_info.sh
Consolidated AP-Provisioned Information from Controller
To get consolidated AP-Provisioned information for a single AP, execute the following CLI command:
(host)#show ap consolidated-provision info ap-name <ap-name>
To get consolidated AP-provisioned information of all active APs, execute the following CLI command:
(host)#ap consolidated-provision info
The controller stores the provisioning information of all active APs in the /flash/config/ap_provision_info.txt
file.
One can retrieve this text file or transfer this file to the TFTP or FTP server by using the copy command.
ArubaOS 6.5.3.x
| User Guide Access Points | 597
Intelligent Power Monitoring
Intelligent Power Monitoring (IPM) is a feature that actively measures the power utilization of an AP and dynamically adapts to the power budget. The static power management method, in contrast to IPM, limits the operation and performance of an AP based on the worst case power usage model.
IPM dynamically limits the power requirement of an AP as per the available power resources. This is in contrast to the existing static power management method where the power profiles (POE-AF/POE-AT/DC or LLDP) are hard-coded for each AP. In order to manage this prioritization, you can define a set of power reduction steps and associate them with a priority. IPM applies a sequence of power reduction steps as defined by the priority definition until the AP is functioning within the power budget. This happens dynamically as IPM constantly monitors the AP power consumption and reacts to over-consumption by applying the next power reduction step in the priority list if the AP exceeds the power threshold.
IPM is supported in 300 Series, AP-303H, 310 Series, and 330 Series access points.
Important Points to Remember
n n
By default, IPM is disabled.
Once enabled, IPM enables all AP functionality initially. IPM then proceeds to shut down or restrict functionality if the power usage of the AP goes beyond the power budget of the AP.
Some functionalities may still be restricted because IPM does not override the pre-existing settings that restrict functionality. For example, USB functionality can be disabled in the provisioning profile regardless of the power source.
n
IPM operates in PoE mode only.
Configuring IPM
A low priority value for a power reduction step reduces the power level sooner than setting a high priority value for a power reduction step. However, if the power reduction step is of the same type but different level, the smallest reduction should be allocated the lowest priority value so that the power reduction step takes place earlier. For example, the cpu_throttle_25 or radio_2ghz_power_3dB parameter should have a lower priority level than the cpu_throttle_50 or radio_2ghz_power_6dB respectively so that IPM reduces the CPU throttle or power usage based on the priority list.
You can configure IPM using the WebUI or CLI.
In the WebUI
To enable IPM, follow the steps below:
1. Navigate to Configuration > ADVANCED SERVICES > All Profiles .
2. Expand AP > AP system and select an existing AP system profile.
3. In the Profile Details section, click the Advanced tab.
4. In the IPM activation field, select the check box.
5. In the IPM power reduction steps with priorities field, select an IPM power reduction step from the
IPM Step drop-down list, set a priority from the Priority field, and click Add .
6. Click Apply and Save Configuration .
In the CLI
To enable IPM, issue the following commands:
(host) (config) #ap system-profile default
(host) (AP system profile "default") #ipm-enable
598 | Access Points ArubaOS 6.5.3.x | User Guide
To alter the IPM priority list, issue the following command:
(host) (AP system profile "default") #ipm-power-reduction-step-prio ipm-step ?
cpu_throttle_25 Reduce CPU frequency to 25% cpu_throttle_50 cpu_throttle_75 disable_alt_eth disable_pse
Reduce CPU frequency to 50%
Reduce CPU frequency to 75%
Disable 2nd Ethernet port
Disable PSE disable_usb radio_2ghz_chain_1x1 radio_2ghz_chain_2x2 radio_2ghz_chain_3x3
Disable USB
Reduce 2GHz chains to 1x1
Reduce 2GHz chains to 2x2
Reduce 2GHz chains to 3x3 radio_2ghz_power_3dB radio_2ghz_power_6dB radio_5ghz_chain_1x1 radio_5ghz_chain_2x2 radio_5ghz_chain_3x3 radio_5ghz_power_3dB radio_5ghz_power_6dB
Reduce 2GHz radio power by 3dB from maximum
Reduce 2GHz radio power by 6dB from maximum
Reduce 5GHz chains to 1x1
Reduce 5GHz chains to 2x2
Reduce 5GHz chains to 3x3
Reduce 5GHz radio power by 3dB from maximum
Reduce 5GHz radio power by 6dB from maximum
To view the IPM configuration, issue the following command:
(host) #show ap system-profile default | include IPM
AP system profile "default"
---------------------------
Parameter
---------
Value
-----
IPM activation Enabled
IPM power reduction steps with priorities disable_usb/priority:2
IPM power reduction steps with priorities cpu_throttle_25/priority:1
ArubaOS 6.5.3.x
| User Guide Access Points | 599
Chapter 23
Secure Enterprise Mesh
The Aruba secure enterprise mesh solution is an effective way to expand network coverage for outdoor and indoor enterprise environments without any wires. Using mesh, you can bridge multiple Ethernet LANs or you can extend your wireless coverage. As traffic traverses across mesh APs, the mesh network automatically reconfigures around broken or blocked paths. This self-healing feature provides increased reliability and redundancy: the network continues to operate if an AP stops functioning or a connection fails.
Aruba controllers provide centralized configuration and management for APs in a mesh environment; local mesh APs provide encryption and traffic forwarding for mesh links.
n n n n n n n
Mesh Overview Information
The following topics in this chapter describes the components of the Aruba secure enterprise mesh architecture and profiles, as well as factors that should be taken into consideration when planning your mesh deployment.
Understanding Mesh Access Points on page 600
Understanding Mesh Links on page 602
Understanding Mesh Profiles on page 604
Understanding Remote Mesh Portals (RMPs) on page 608
Mesh Deployment Planning on page 612
Mesh Deployment Solutions on page 610
Mesh Deployment Planning on page 612
Mesh Configuration Procedures
The following topics describe the procedures required to configure your secure enterprise mesh solution:
1.
Creating and Editing Mesh Radio Profiles on page 618
2.
Creating and Editing Mesh Radio Profiles on page 618
3.
Creating and Editing Mesh High-Throughput SSID Profiles on page 623
4.
Configuring Ethernet Ports for Mesh on page 629
5.
Provisioning Mesh Nodes on page 631
6.
Verifying Your Mesh Network on page 633
Aruba strongly recommends staging mesh APs before deploying them. Identify the physical location of the APs, configure them for mesh, provision the APs and verify connectivity before physically deploying them in a live network.
If you are configuring an AP as both a remote access point and a mesh portal, see also
Mesh Portals (RMPs) on page 635
Understanding Mesh Access Points
Mesh APs learn about their environment when they boot up. Mesh APs are either configured as a mesh portal
(MPP), an AP that uses its wired interface to reach the controller, or a mesh point (MP), an AP that establishes an all-wireless path to the mesh portal. Mesh APs locate and associate with their nearest neighbor, which
ArubaOS 6.5.3.x
| User Guide Secure Enterprise Mesh | 600
provides the best path to the mesh portal. Mesh portals and mesh points are also known as mesh nodes, a generic term used to describe APs configured for mesh.
A mesh radio’s bandwidth can be shared between mesh-backhaul traffic and client traffic. You can, however, configure a radio for mesh services only. If you have a dual-radio AP, a mesh node can be configured to deliver client services on one radio, and both mesh and WLAN services to clients on the other. If you configure a singleradio AP to deliver mesh services only (by disabling the mesh radio in its 802.11a or 802.11g radio profile) that mesh node can not deliver WLAN services to its clients.
For mesh and traditional thin AP deployments, the Aruba controller provides centralized provisioning, configuration, policy definition, ongoing network management, and wireless and security services. However, unlike the traditional thin AP case, mesh nodes also perform network traffic encryption and decryption, and packet forwarding over wired and wireless links.
You configure the AP for mesh on the controller using either the WebUI or the CLI. All mesh related configuration parameters are grouped into mesh profiles that you can apply as needed to an AP group or to individual APs.
APs operate as thin APs by default; their primary function is to receive and transmit electromagnetic signals; other WLAN processing is left to the controller. When planning a mesh network, you manually configure APs to operate in mesh portal or mesh point roles. Unlike a traditional WLAN environment, local mesh nodes provide encryption and traffic forwarding for mesh links in a mesh environment. Virtual APs are still applied to nonmesh radios.
Provisioning mesh APs is similar to thin APs; however, there are some key differences. Thin APs establish a channel to the controller from which they receive the configuration for each radio interface. Mesh nodes, in contrast, get their radio interfaces up and running before making contact with the controller. This requires a minimum set of parameters from the AP group and mesh cluster so the mesh node discovers a neighbor, and creates a mesh link and subsequent channel with the controller. To do this, you must first define and configure the mesh cluster profile before configuring an AP to operate as a mesh node. This chapter first describes how to configure the mesh profile, then describes how to configure APs to operate in mesh mode. If you have already configured a complete mesh profile, continue to “Ethernet Ports for Mesh” or “Provisioning Mesh
Nodes”.
Mesh Portals
The mesh portal (MPP) is the gateway between the wireless mesh network and the enterprise wired LAN. You configure an Aruba AP to perform the mesh portal role, which uses its wired interface to establish a link to the wired LAN. You can deploy multiple mesh portals to support redundant mesh paths (mesh links between neighboring mesh points that establish the best path to the mesh portal) from the wireless mesh network to the wired LAN.
The mesh portal broadcasts the configured mesh service set identifier (MSSID/mesh cluster name), and advertises the mesh network service to available mesh points. Neighboring mesh points that have been provisioned with the same MSSID authenticate to the portal and establish a secure mesh link over which traffic is forwarded. The authentication process requires secure key negotiation, common to all APs, and the mesh link is established and secured using Advanced Encryption Standard (AES) encryption. Mesh portals also propagate channel information, including CSAs.
Mesh Points
The mesh point (MP) is an Aruba AP configured for mesh and assigned the mesh point role. Depending on the
AP model, configuration parameters, and how it was provisioned, the mesh point can perform multiple tasks.
The mesh point provides traditional Aruba WLAN services (such as client connectivity, intrusion detection system (IDS) capabilities, user role association, LAN-to-LAN bridging, and Quality of Service (QoS) for LAN-tomesh communication) to clients and performs mesh backhaul/network connectivity. A mesh radio can be
601 | Secure Enterprise Mesh ArubaOS 6.5.3.x | User Guide
configured to carry mesh-backhaul traffic only. Additionally, a mesh point can provide LAN-to-LAN Ethernet bridging by sending tagged/untagged VLAN traffic across a mesh backhaul/network to a mesh portal.
Mesh points use one of their wireless interfaces to carry traffic and reach the controller. Mesh points are also aware of potential neighbors, and can form new mesh links if the current mesh link is no longer preferred or available.
Mesh Clusters
Mesh clusters are similar to an Extended-Service Set (ESS) in a WLAN infrastructure. A mesh cluster is a logical set of mesh nodes that share the common connection and security parameters required to create mesh links.
Mesh clusters are grouped and defined by a mesh cluster profile, as described in “Mesh Cluster Profile”.
Mesh clusters may enforce predictability in mesh networking by limiting the amount of concurrent mesh points, hop counts, and bandwidth used in the mesh network. A mesh cluster can have multiple mesh portals and mesh points that facilitate wireless communication between wired LANs. Mesh portals in a mesh cluster do not need to be on the same VLAN.
shows two mesh clusters and their relationship to the controller.
Figure 75 Sample Mesh Clusters
Understanding Mesh Links
The mesh link is the data link between a mesh point and its parent. A mesh point uses the parameters defined in the mesh cluster profile, to establish a mesh link with a neighboring mesh point. The mesh link uses a series of metrics to establish the best path to the mesh portal.
Throughout the rest of this chapter, the term “uplink” is used to distinguish the active association between a mesh point and its parent.
The following list describes how mesh links are created: n
Creating the initial mesh link
When creating the initial mesh link, mesh points look for others advertising the same MSSID as the one contained in its mesh cluster profile. The mesh point scans the channels in its provisioned band of operation to identify a list of neighbors that match its mesh cluster profile. The mesh point then selects the from highest priority neighbors based on the least expected path cost.
If no provisioned mesh cluster profile is available, mesh points use the recovery profile to establish an uplink. If multiple cluster profiles are configured, mesh points search, in order of priority, their list of
ArubaOS 6.5.3.x
| User Guide Secure Enterprise Mesh | 602
n n provisioned backup mesh cluster profiles to establish an uplink. If the configured profiles are unavailable after searching for 5 minutes, the recovery profile is used.
Moving to a better mesh link
If the existing uplink quality degrades below the configured threshold, and a lower cost or more preferable uplink is available on the same channel and cluster, the mesh point reselects that link without re-scanning.
In some cases, this invalidates all of the entries that have this mesh point as a next hop to the destination and triggers new learning of the bridge tables.
Using a new mesh link if the current mesh link goes down
If an uplink goes down, the affected mesh nodes reestablish a connection with the mesh portal by rescanning to choose a new path to the mesh portal. If a mesh portal goes down, and a redundant mesh portal is available, the affected mesh nodes update their forwarding tables to reflect the path to the new mesh portal.
Link Metrics
Mesh points use the configured algorithm to compute a metric value, or “path cost,” for each potential uplink and select the one with the lowest value as the optimal path to the mesh portal.
describes the components that make up the metric value: node cost, hop count, link cost and 802.11 capacity.
The link metrics indicate the relative cost of a path to the mesh portal. The best path (lowest metric value) is used to create the uplink.
Table 136: Mesh Link Metric Computation
Component Description
Node cost
Hop count
Link cost
802.11
capacity
Path Cost
Indicates the amount of traffic expected to traverse the mesh node. The more traffic, the higher the node cost. When establishing a mesh link, nodes with less traffic take precedence.
The node cost is dependent on the number of children a mesh node supports. It can change as the mesh network topology changes, for example if new children are added to the network or old children disconnect from the network.
Indicates the number of hops it takes the mesh node to get to the mesh portal. The mesh portal advertises a hop count of 0, while all other mesh nodes advertise a cumulative count based on the parent mesh node.
Represents the quality of the link to an active neighbor. The higher the Received Signal
Strength Indication (RSSI), the better the path to the neighbor and the mesh portal. If the RSSI value is below the configured threshold, the link cost is penalized to filter marginal links. A less direct, higher quality link may be preferred over the marginal link.
The following factors also affect mesh link metrics: n High-throughput APs add a high cost penalty for links to non-high-throughput APs.
n Multi-stream high-through APs add proportional cost penalties for links to highthroughput APs that support fewer streams.
High-throughput APs can send 802.11 information elements (IEs) in their management frames, allowing high-throughput mesh nodes to identify other mesh nodes with a highthroughput capacity. High-throughput mesh points prefer to select other 802.11-capable mesh points in their path to the mesh portal, but can use a legacy path if no high-throughput path is available.
Path cost is calculated by analyzing the other components in this table, and adding the link cost, the mesh parent's path cost, and the parent's node cost.
Mesh portals typically advertise a path-cost of zero, but high-throughput portals add an offset penalty if they are connected to a 10/100mbps port that is too slow for the highthroughput link capacity.
603 | Secure Enterprise Mesh ArubaOS 6.5.3.x | User Guide
Optimizing Links
You can configure and optimize operation of the link metric algorithm via the mesh radio profile. These configurable mesh link trigger thresholds can determine when the uplink or mesh path is dropped and another is chosen, provide enhanced network reliability, and contain flapping links. Although you can modify the behavior of the link metric algorithm, It is recommended to follow the default values for most deployments.
For information, see
Metric algorithm on page 620 .
Understanding Mesh Profiles
Mesh profiles help define and bring-up the mesh network. The following sections describe the mesh cluster, mesh radio, and mesh recovery profiles in more detail.
The complete mesh profile consists of a mesh radio profile, RF management (802.11a and 802.11g) radio profiles, a high-throughput SSID profile (if your deployment includes 802.11n-capable APs), a mesh cluster profile, and a read-only recovery profile. The recovery profile is dynamically generated by the master controller; you do not explicitly configure the recovery profile.
Aruba provides a “default” version of the mesh radio, RF management, high-throughput SSID and cluster profiles with default values for most parameters. You can use the “default” version of a profile or create a new instance of a profile which you can then edit as you need. You can change the values of any parameter in a profile. You have the flexibility of applying the “default” versions of profiles in addition to customizing profiles that are necessary for the AP or AP group to function.
If you assign a profile to an individual AP, the values in the profile override the profile assigned to the AP group to which the AP belongs. The exception is the mesh cluster profile: you can apply multiple mesh cluster profiles to individual APs, as well as to AP groups.
Mesh Cluster Profiles
Mesh clusters are grouped and defined by a mesh cluster profile, which provides the framework of the mesh network. Similar to virtual AP profiles, the mesh cluster profile contains the MSSID (mesh cluster name), authentication methods, security credentials, and cluster priority required for mesh nodes to associate with their neighbors and join the cluster. Associated mesh nodes store this information in flash memory. Although most mesh deployments require only a single mesh cluster profile, you can configure and apply multiple mesh cluster profiles to an AP group or an individual AP. If you have multiple cluster profiles, the mesh portal uses the profile with the highest priority to bring up the mesh network. Mesh points, in contrast, go through the list of mesh cluster profiles in order of priority to decide which profile to use to associate themselves with the network. The mesh cluster priority determines the order by which the mesh cluster profiles are used. This allows you, rather than the link metric algorithm, to explicitly segment the network by defining multiple cluster profiles.
Since the mesh cluster profile provides the framework of the mesh network, you must define and configure the mesh cluster profile before configuring an AP to operate as a mesh node. You can use either the default cluster profile or create your own. If you find it necessary to define more than one mesh cluster profile, you must assign priorities to each profile to allow the Mesh AP group to identify the primary and backup mesh cluster profile(s). The primary mesh cluster profile and each backup mesh cluster profile must be configured to use the same RF channel. The APs may not provision correctly if they are assigned to a backup mesh cluster profile with a different RF channel than the primary mesh cluster profile.
If the mesh cluster profile is unavailable, the mesh node can revert to the recovery profile to bring-up the mesh network until the cluster profile is available. You can also exclude one or more mesh cluster profiles from an individual access point, this prevents a mesh cluster profile defined at the AP group level from being applied to a specific AP.
ArubaOS 6.5.3.x
| User Guide Secure Enterprise Mesh | 604
Do not delete or modify mesh cluster profiles once you use them to provision mesh nodes. You can recover the mesh point if the original cluster profile is still available. It is recommended to create a new mesh cluster profile if needed. If you modify any mesh cluster setting, you must reprovision your AP for the changes to take effect (this also causes the AP to automatically reboot). See “Provisioning Mesh Nodes” for more information.
If you configure multiple cluster profiles with different cluster priorities, you manually override the link metric algorithm because the priority takes precedence over the path cost. In this scenario, the mesh portal uses the profile with the highest priority to bring-up the mesh network. The mesh portal stores and advertises that one profile to neighboring mesh nodes to build the mesh network. This profile is known as the “primary” cluster profile. Mesh points, in contrast, go through the list of configured mesh cluster profiles in order of priority to find the profile being advertised by the mesh portal. Once the primary profile has been identified, the other profiles are considered “backup” cluster profiles. Use this deployment if you want to enforce a particular mesh topology rather than allowing the link metric algorithm to determine the topology.
For this scenario, do the following: n n n n n n
Configure multiple mesh cluster profiles with different priorities. The primary cluster profile has a lower priority number, which gives it a higher priority.
Configure the mesh radio profile.
Create an AP group for 802.11a radios and 802.11g radios
Configure the 802.11a or 802.11g RF management profiles for each AP group.
If your deployment includes high-throughput APs, configure the mesh high-throughput SSID profile. The mesh radio profile uses the default high-throughput SSID profile unless you specifically configure the mesh radio profile to use a different high-throughput SSID profile
Create an AP group for each 802.11a channel.
If a mesh link breaks or the primary cluster profile is unavailable, mesh nodes use the highest priority backup cluster profile to re-establish the uplink or check for parents in the backup profiles. If these profiles are unavailable, the mesh node can revert to the recovery profile to bring up the mesh network until a cluster profile is available. For information about the procedure to configure a mesh cluster profile, see
Mesh Cluster Profiles on page 614
Mesh Radio Profiles
The mesh radio profile allows you to specify the set of rates used to transmit data on the mesh link. This profile also allows you to define a reselection-mode setting to optimize the operation of the link metric algorithm.
The reselection mode specifies the method a mesh node uses to find a better uplink to create a path to the mesh portal. Only neighbors on the same channel in the same mesh cluster are considered.
The mesh radio profile includes the following reselection mode options: n n n reselect anytime : mesh points using the reselect-anytime reselection mode perform a single topology readjustment scan within 9 minutes of startup and 4 minutes after a link is formed. If no better parent is found, the mesh point returns to its original parent. This initial scan evaluates more distant mesh points before closer mesh points, and incurs a dropout of 5–8 seconds for each mesh point. After the initial startup scan is completed, connected mesh nodes evaluate mesh links every 30 seconds. If a mesh node finds a better uplink, the mesh node connects to the new parent to create an improved path to the mesh portal.
reselect-never : connected mesh nodes do not evaluate other mesh links to create an improved path to the mesh portal.
startup-subthreshold : mesh points using the startup-subthreshold reselection mode perform a single topology readjustment scan within 9 minutes of startup and 4 minutes after a link is formed. If no better parent is found, the mesh point returns to its original parent. This initial startup scan evaluates more distant mesh points before closer mesh points, and incurs a dropout of 5–8 seconds for each mesh point. After
605 | Secure Enterprise Mesh ArubaOS 6.5.3.x | User Guide
n that time, each mesh node evaluates alternative links if the existing uplink falls below the configured threshold level (the link becomes a sub-threshold link). It is recommended to use this default startupsubthreshold value.
subthreshold-only : connected mesh nodes evaluate alternative links only if the existing uplink becomes a sub-threshold link.
If a mesh point using the startup-subthreshold or subthreshold-only mode reselects a more distant parent because its original, closer parent falls below the acceptable threshold, then as long as that mesh point is connected to that more distant parent, it seeks to reselect a parent at the earlier, shorter distance (or less) with good link quality. For example, if a mesh point disconnects from a mesh parent 2 hops away and subsequently reconnects to a mesh parent 3 hops away, then the mesh point continues to seek a connection to a mesh parent with both an acceptable link quality and a distance of two hops or less, even if the more distant parent also has an acceptable link quality.
For information about the procedure to configure mesh radio profiles, see
Creating and Editing Mesh Radio
RF Management (802.11a and 802.11g) Profiles
The two 802.11a and 802.11g RF management profiles for an AP configure its 802.11a (5 Ghz) and 802.11b/g
(2.4 GHz) radio settings. Use these profile settings to determine the channel, beacon period, transmit power, and ARM profile for a mesh AP’s 5 GHz and 2.4 Ghz frequency bands. You can either use the “default” version of each profile, or create a new 802.11a or 802.11g profile which you can then configure as necessary. Each RF management profile also has a radio-enable parameter that allows you to enable or disable the AP’s ability to simultaneously carry WLAN client traffic and mesh-backhaul traffic on that radio. This value is enabled by default. For information about configuring RF Management Radio profiles, see
Management Profiles on page 563
.
If you do not want the mesh radios carrying mesh-backhaul traffic to support client traffic, consider using a dedicated
802.11a/80211/g radio profile with the mesh radio disabled. In this scenario, the radio carries mesh backhaul traffic but does not support client Virtual APs.
Mesh nodes operating in different cluster profiles can share the same radio profile. Conversely, mesh portals using the same cluster profile can be assigned different RF Management Radio profiles to achieve frequency separation (for more information, see “Deployments with Multiple Mesh Cluster Profiles”).
Adaptive Radio Management Profiles
Each 802.11a and 802.11g radio profile references an Adaptive Radio Management (ARM) profile. When you assign an active ARM profile to a mesh radio, ARM's automatic power-assignment and channel-assignment features automatically select the radio channel with the least amount of interference for each mesh portal, maximizing end user performance. In earlier versions of this software, an AP with a mesh radio received its beacon period, transmission power, and 11a/11g portal channel settings from its mesh radio profile. Meshaccess AP portals now inherit these radio settings from their dot11a or dot11g radio profiles.
Each ARM-enabled mesh portal monitors defined thresholds for interference, noise, errors, rogue APs and radar settings, then calculates interference and coverage values and selects the best channel for its radio band
(s). The mesh portal communicates its channel selection to its mesh points via Channel Switch Announcements
(CSAs), and the mesh points change their channel to match their mesh portal. Although channel settings can still be defined for a mesh point via that mesh point's 802.11a and 802.11g radio profiles, these settings are overridden by any channel changes from the mesh portal. A mesh point takes the same channel setting as its mesh portal, regardless of its associated clients. If you want to manually assign channels to mesh portals or mesh points, disable the ARM profile associated with the 802.11a or 802.11g radio profile by setting the ARM profile’s assignment parameter to disable .
ArubaOS 6.5.3.x
| User Guide Secure Enterprise Mesh | 606
Mesh points, unlike mesh portals, do not scan channels. This means that once a mesh point has selected a mesh portal or an upstream mesh point, it tunes to this channel, forms the link, and does not scan again unless the mesh link gets broken. This provides good mesh link stability, but may adversely affect system throughput in networks with mesh portals and mesh points. When ARM assigns optimal channels to mesh portals, those portals use different channels. Once the mesh network has formed and all the mesh points have selected a portal (or upstream mesh point), those mesh points are not be able to detect other portals on other channels that could offer better throughput. This type of suboptimal mesh network may form if, for example, two or three mesh points select the same mesh portal after booting, form the mesh network, and leave a nearby mesh portal without any mesh points. Again, this does not affect mesh functionality, but may affect total system throughput. For details about associating an ARM profile with a mesh AP, see
Assigning an ARM Profile on page 571 .
High-Throughput Radio Profiles
Each 802.11a and 802.11g radio profile also references a high-throughput profile that manages an AP or AP group’s 40Mhz tolerance settings. For information about referencing a high-throughput profile, see
High-throughput Profile on page 571
.
Mesh High-Throughput SSID Profiles
High-throughput APs support additional settings not available in legacy APs. A mesh high-throughput SSID profile can enable or disable high-throughput (802.11n) features and 40 MHz channel usage, and define values for aggregated MAC protocol data units (MDPUs), and Modulation and Coding Scheme (MCS) ranges.
Aruba provides a “default” version of the mesh high-throughput SSID profile. You can use the “default” version or create a new instance of a profile which you can then edit as you need. High-throughput mesh nodes operating in different cluster profiles can share the same high-throughput SSID radio profile. For information about configuring mesh high-throughput SSID profiles, see
Creating and Editing Mesh High-Throughput SSID
.
Wired AP Profiles
The wired AP profile controls the configuration of the Ethernet port(s) on your AP. You can use the wired AP profile to configure Ethernet ports for bridging or secure jack operation using the wired AP profile. For details, see
Configuring Ethernet Ports for Mesh on page 629
Mesh Recovery Profiles
In addition to the “default” and user-defined mesh cluster profiles, mesh nodes also have a recovery profile.
The master controller dynamically generates a recovery profile, and each mesh node provisioned by the same master controller has the same recovery profile. The recovery profile is based on a pre-shared key (PSK), and mesh nodes use the recovery profile to establish a link to the controller if the mesh link is broken and no other mesh cluster profiles are available.
The mesh portal advertises the provisioned cluster profile. If a mesh point is unaware of the active mesh cluster profile, but is aware of and has the same recovery profile as the mesh portal, the mesh point can use the recovery profile to connect to the mesh portal.
The mesh point must have the same recovery profile as the parent to which it connects. If you provision the mesh points with the same master controller, the recovery profiles should match. To verify that the recovery profile names match, use the command show ap mesh debug provisioned-clusters {ap-name <name> | bssid<bssid> | ipaddr<ipaddr>} . To view the recovery profile on the controller, use the command show running-config | include recovery .
607 | Secure Enterprise Mesh ArubaOS 6.5.3.x | User Guide
If a mesh point connects to a parent using the recovery profile, it may immediately exit recovery if the parent is actively using one of its provisioned mesh cluster profiles. Once in recovery, a mesh point periodically exits recovery to see if it can connect using an available provisioned mesh cluster profile. The recovery profile is read-only; it cannot be modified or deleted.
The recovery profile is stored in the master controller’s configuration file and is unique to that master controller. If necessary, you can transfer your configuration to another controller. If you do so, make sure your new mesh cluster is running and you have re-provisioned the mesh nodes before deleting your previous configuration. The APs learn the new recovery profile after they are provisioned with the new controller. This is also true if you provision a mesh node with one master controller and use it with a different master controller.
In this case, the recovery profile does not work on the mesh node until you re-provision it with the new master controller.
Understanding Remote Mesh Portals (RMPs)
You can deploy mesh portals to create a hybrid mesh/remote AP environment to extend network coverage to remote locations; this feature is called remote mesh portal, or RMP. The RMP feature integrates the functions of a remote AP (RAP) and the Mesh portal. As a RAP, it sets up a VPN tunnel back to the corporate switch that secures control traffic between the RAP and the switch.
The Remote Mesh Portal feature allows you to configure a remote AP at a branch office to operate as a mesh portal for a mesh cluster. Other mesh points belonging to that cluster get their IP address and configuration settings from the main office via an IPsec tunnel between the remote mesh portal and the main office controller. This feature is useful for deploying an all-wireless branch office or creating a complete wireless network in locations where there is no wired infrastructure in place.
When the client at the branch office associates to a virtual AP in split-tunnel forwarding mode, the client’s
DHCP requests are forwarded over a GRE tunnel (split tunnel) to the corporate network. This communication is done over a secure VPN tunnel. The IPs are assigned from the corporate pool based on the VLAN tag information, which helps to determine the corresponding VLAN. The VLAN tag also determines the subnet from which the DHCP address has assigned.
A mesh point sends the DHCP request with the mesh private VLAN (MPV) parameter. The mesh point learns the MPV value from the response during the mesh association. When the split tunnel is setup for the RMP on the controller, the VLAN of the tunnel should be the MPV.A DHCP pool for the MPV should be setup on the switch. The use of MPV makes it easy for the RMP to decide which requests to forward over the split tunnel. All requests tagged with the MPV are sent over the split tunnel. Hence the MPV should be different from any user
VLAN that is bridged using the mesh network.
The RMP configuration requires an AP license. For more information about Aruba software licenses, see
ArubaOS 6.5.3.x
| User Guide Secure Enterprise Mesh | 608
Figure 76 Working of RMP
By default, the data frames the mesh portal receives on its mesh link are forwarded according to the bridge table entries on the portal. However, frames received on mesh private VLAN (MPV) are treated differently by the remote mesh portal. These frames are treated the same as frames received on a split SSID and are routed rather than bridged. Mesh points obtain DHCP addresses from the corporate network. then register with the controller using these IP addresses. When these mesh points send and receive PAPI control traffic from the main office controller, it controls these mesh points just as if they were on a local VLAN. PAPI traffic containing keys and other secret information receives IPsec encryption and decryption when it is forwarded to the controller through the VPN tunnel.
Not all traffic from a mesh point is sent on the mesh private VLAN. When a mesh point bridges data received via its Ethernet interface or from clients connected to an access radio VAP, the mesh point does not tag the frame with the mesh private VLAN tag when it sends the data through mesh link to the remote mesh portal.
Note that the mesh point may still tag the frame depending on the VLAN of the virtual AP and the native VLAN specified in the system profile. Care must be taken to assign the MPV value so that it does not clash with any local tags assigned in the mesh network. In this scenario, the portal performs the default operation and bridges the frame based on its bridge table. Traffic destined to the Internet is recognized as such by the remote mesh portal based on ACL rules. This traffic is NATed on the remote mesh portal’s Ethernet interface.
For information on the procedure to configure remote mesh portals, see
Configuring Remote Mesh Portals
Understanding the AP Boot Sequence
The section describes the boot sequence for mesh APs in detail. Depending on its configured role, the AP performs a slightly different boot sequence.
Booting the Mesh Portal
When the mesh portal boots, it recognizes that one radio is configured to operate as a mesh portal. It then obtains an IP address from a DHCP server on its Ethernet interface, discovers the master controller on that interface, registers the mesh radio with the controller, and obtains regulatory domain and mesh radio profiles for each mesh point interface. A mesh virtual AP is created on the mesh portal radio interface, the regulatory
609 | Secure Enterprise Mesh ArubaOS 6.5.3.x | User Guide
domain and radio profiles are used to bring up the radio on the correct channel, and the provisioned mesh cluster profile is used to setup the mesh virtual AP with the correct announcements on beacons and probe responses. On the non-mesh radio provisioned for access mode, that radio is a thin AP and everything on that interface works as a thin AP radio interface.
If the 802.11a/802.11g radio profile assigned to the mesh radio is enabled, the radio supports both mesh backhaul and client access Virtual APs. If the mesh radio is to be used exclusively for mesh backhaul traffic, associate that radio to a dedicated 802.11a/802.11g radio profile with the radio disabled so the mesh radios carry backhaul traffic only.
Booting the Mesh Point
When the mesh point boots, it scans for neighboring mesh nodes to establish a link to the mesh portal. All of the mesh nodes that establish the link are in the same mesh cluster. After the link is up, the mesh point uses the DHCP to obtain an IP address and uses the same master controller as their parent. The remaining boot sequence, if applicable, is similar to that of a thin AP. Remember, the priority of the mesh point is establishing a link with neighboring mesh nodes, not establishing a control link to the controller.
In a single hop environment, the mesh point establishes a direct link with the mesh portal.
Air Monitoring and Mesh
Each mesh node has an air monitor (AM) process that registers the BSSID and the MAC address of the mesh node to distinguish it from a thin AP. This allows the WLAN management system (WMS) on the controller and
AMs deployed in your network to distinguish between APs, wireless clients, and mesh nodes. The WMS tables also identify the mesh nodes.
For all thin APs and mesh nodes, the AM identifies a mesh node from other packets monitored on the air, and the AM does not trigger wireless-bridging events for packets transmitted between mesh nodes.
Mesh Deployment Solutions
You can configure the following single-hop and multi-hop solutions: n n n n
Thin AP services with wireless backhaul deployment
Point-to-point deployment
Point-to-multipoint deployment
High-availability deployment
With a thin AP wireless backhaul deployment, mesh provides services and security to remote wireless clients and sends all control and user traffic to the master controller over a wireless backhaul mesh link.
The remaining deployments allow you to extend your existing wired network by providing a wireless bridge to connect Ethernet LAN segments. You can use these deployments to bridge Ethernet LANs between floors, office buildings, campuses, factories, warehouses, and other environments where you do not have access to physical ports, or cable to extend the wired network. In these scenarios, a wireless backhaul carries traffic between the Aruba APs configured as the mesh portal and the mesh point, to the Ethernet LAN.
Thin AP Services with Wireless Backhaul Deployment
To expand your wireless coverage without bridging Ethernet LAN segments, you can use thin AP services with a wireless backhaul. In this scenario, the mesh point provides network access for wireless clients and establishes a mesh path to the mesh portal, which uses its wired interface to connect to the controller. Use the 802.11g
ArubaOS 6.5.3.x
| User Guide Secure Enterprise Mesh | 610
radio for WLAN and controller services and the 802.11a radio for mesh services.
shows the wireless backhaul between the mesh portal to the mesh point that services the wireless clients.
Figure 77 Sample Wireless Backhaul Deployment
Point-to-Point Deployment
In this point-to-point scenario, two Ethernet LAN segments are bridged via a wireless connection that carries both client services traffic and mesh-backhaul traffic between the mesh portal and the mesh point. This provides communication from one LAN to another.
shows a single-hop point-to-point deployment.
Figure 78 Sample Point-to-Point Deployment
Point-to-Multipoint Deployment
In a point-to-multipoint scenario, multiple Ethernet LAN segments are bridged via multiple wireless/mesh backhauls that carry traffic between the mesh portal and the mesh points. This provides communication from the local LAN to multiple remote LANs.
shows a single-hop point-to-multipoint deployment.
611 | Secure Enterprise Mesh ArubaOS 6.5.3.x | User Guide
Figure 79 Sample Point-to-Multipoint Deployment
High-Availability Deployment
In this high-availability scenario, multiple Ethernet LAN segments are bridged via multiple wireless backhauls that carry traffic between the mesh portal and the mesh points. You configure one mesh portal for each remote LAN that you are bridging with the host LAN. This provides communication from the host LAN to multiple remote LANs. In the event of a link failure between a mesh point and its mesh portal, the affected mesh point could create a link to the other mesh portal.
shows a sample single-hop high-availability deployment. The dashed lines represent the current mesh link between the mesh points and their mesh portals. The diagonal dotted lines represent possible links that could be formed in the event of a mesh link or mesh portal failure.
Figure 80 Sample High-Availability Deployment
Mesh Deployment Planning
Following considerations are recommended when planning and deploying a mesh solution:
ArubaOS 6.5.3.x
| User Guide Secure Enterprise Mesh | 612
Pre-Deployment Considerations
n n n n n
Stage the APs before deployment. Identify the location of the APs, configure them for mesh, provision them, and verify connectivity before physically deploying the mesh APs in a live network.
Ensure the controller has Layer-2/3 network connectivity to the network segment where you plan to install the mesh portal.
Keep the AP packaging materials and reuse them to send the APs to the installation location.
Verify the layout of the physical location to determine the appropriate configuration and placement of the
APs. Use this information to avoid problems that would necessitate a physical recovery.
Label the AP before sending it to the physical location for installation.
Outdoor-Specific Deployment Considerations
n n n n n n
Provision the AP with the latitude and longitude coordinates of the installation location. This allows you to more easily identify the AP for inventory and troubleshooting purposes.
Identify a “radio line of sight” between the antennas for optimum performance. The radio line of sight involves the area along a link through which the bulk of the radio signal power travels.
Identify the minimum antenna height required to ensure a reliable mesh link.
Scan your proposed site to avoid radio interference caused by other radio transmissions using the same or an adjacent frequency.
Consider extreme weather conditions known to affect your location, including: temperature, wind velocity, lightning, rain, snow, and ice.
Allow for seasonal variations, such as growth of foliage.
For more detailed outdoor deployment information, refer to the installation guide that came with your outdoor AP.
Configuration Considerations
n n n n n n n n n
On dual-radio APs, you can configure only one of the radio for mesh. If you want a dual-radio AP to carry mesh backhaul traffic and client services traffic on separate radios, it is recommended to use 802.11a
radios for mesh-backhaul traffic and 802.11g radios for traditional WLAN access.
If you configure more than one mesh node in the same VLAN, prevent network loops by enabling STP on the Layer-2 switch used to connect the mesh nodes.
Mesh nodes learn a maximum of 1,024 source MAC addresses; this cannot be changed.
Place all APs for a specific mesh cluster in the same AP group.
Create and keep separate mesh cluster profiles for specific mesh clusters. Do not overwrite or delete the cluster profiles.
Enable bridging on mesh point Ethernet ports when deploying LAN bridging solutions.
APs configured as mesh points support secure jack operation on enet0. APs with multiple Ethernet ports configured as mesh portals support secure jack operation on enet1. If an AP with multiple Ethernet ports is configured as a mesh point , it supports secure jack operation on enet1 and enet0.
Mesh networks forward tagged/untagged VLAN traffic, but do not tag traffic. The allowed VLANS are controlled by the wired ap profile.
Mesh APs provisioned on different controllers can interoperate if those APs are configured with the same country code, cluster name and cluster key. However, the mesh recovery profile created on one controller is not able to recover settings for mesh APs provisioned on another controller unless the recovery profile is on a master controller and the other mesh nodes were provisioned by a local controller connected to that master.
613 | Secure Enterprise Mesh ArubaOS 6.5.3.x | User Guide
Post-Deployment Considerations
n n
Do not connect mesh point Ethernet ports in such a way that causes a network loop.
Have a trained professional install the AP. After installation, check to ensure the AP receives power and boots up, enabling RSSI outputs.
Although the AP is up and operational, it is not connected to the network.
n n n
Align the AP antenna for optimal RSSI.
Do not delete or modify mesh cluster profiles once you use them to provision mesh nodes. You can recover the mesh point if the original cluster profile is still available. It is recommended to create a new mesh cluster profile if needed.
If you create a new mesh cluster profile for an existing deployment, you must re-provision the AP for the new profile to take effect. If you re-provision mesh nodes that are already operating, re-provision the most distant (highest hop count) mesh points first, followed by the mesh portals. If you re-provision the mesh portal first, the mesh points may be unable to form a mesh link. Note that re-provisioning the AP causes it to automatically reboot, which may cause a disruption of service to the network.
Dual-Port AP Considerations
A dual-port AP has two 10/100 Mbps Ethernet ports (enet0 and enet1, respectively). When using these APs in a mesh environment, note the following Ethernet port requirements: n n
If configured as a mesh portal: l
Connect enet0 to the controller to obtain an IP address. The wired AP profile controls enet1.
l
Only enet1 supports secure jack operation.
If configured as a mesh point, enet0 and enet1 can be configured using separate wired-port-profiles
Configuring Mesh Cluster Profiles
The mesh cluster configuration gets pushed from the controller to the mesh portal and the other mesh points, which allows them to inherit the characteristics of the mesh cluster of which they are a member. Mesh nodes are grouped according to a mesh cluster profile that contains the MSSID, authentication methods, security credentials, and cluster priority. Cluster profiles (including the default cluster profile) are not applied until you provision your APs for mesh. For more information on mesh cluster profiles, see
Managing Mesh Cluster Profiles in the WebUI
Use the following procedures to define and manage mesh cluster profiles using the WebUI.
Creating a Profile
1. Navigate to the Configuration > Wireless > AP Configuration window. Select the AP Group or AP
Specific tab.
n
If you selected AP Group , click the AP group name for which you want to create the new mesh cluster profile.
n
If you selected AP Specific , click the AP for which you want to create the new mesh cluster profile.
2. In the Profiles list, expand the Mesh menu, then select Mesh Cluster .
3. In the Profile Details window pane, click the Add a profile drop-down list and select NEW .
4. Enter a name for the new profile.
ArubaOS 6.5.3.x
| User Guide Secure Enterprise Mesh | 614
5. Configure the mesh cluster settings described in
, then click Apply .
Table 137: Mesh Cluster Profile Configuration Parameters
Parameter Description
Profile Name
Cluster Name
RF Band
Encryption
WPA Hexkey
WPA
Passphrase
Priority
Cluster Name
RF Band
Name of the mesh cluster profile. The name must be 1–63 characters.
Default: a mesh cluster profile named “default.”
Indicates the mesh cluster name. The name can have a maximum of 32 characters, and is used as the MSSID for the mesh cluster. When you first create a new mesh cluster profile, the profile uses the default cluster name “Aruba-mesh”. Use the Cluster Name parameter to define a new, unique MSSID before you assign APs or AP groups to the mesh cluster profile.
NOTE: If you want a mesh cluster to use WPA2-PSK-AES encryption, do not use spaces in the mesh cluster name, as this may cause errors in mesh points associated with that mesh cluster.
To view existing mesh cluster profiles, use the CLI command: show ap mesh-clusterprofile.
A mesh portal chooses the best cluster profile and provisions it for use. A mesh point can have a maximum of 16 cluster profiles.
Default: a mesh cluster named “Aruba-mesh.”
Indicates the band for mesh operation for multiband radios. Select a or g .
Important: If you create more than one mesh cluster profile for an AP or AP group, each mesh cluster profile must use the same band.
Configures the data encryption, which can be either opensystem (no authentication or encryption) or wpa2-psk-aes (WPA2 with AES encryption using a preshared key). It is recommended to select wpa2-psk-aes and using the wpa-passphrase parameter to select a passphrase.
Default: opensystem.
Configures a WPA pre-shared key. This key must be 64 hexadecimal characters
Sets the WPA password that generates the PSK. The passphrase must be between 8–63 characters, inclusive.
Indicates the priority of the cluster profile.
The mesh cluster priority determines the order by which the mesh cluster profiles are used. This allows you, rather than the link metric algorithm, to control the network topology by defining the cluster profiles to use if one becomes unavailable
Specify the cluster priority when creating a new profile or adding an existing profile to a mesh cluster. If more than two mesh cluster profiles are configured, mesh points use the priority numbers to identify primary and backup profile(s).
NOTE: The lower the number, the higher the priority. Therefore, the profile with the lowest number is the primary profile. Each profile must use a unique priority value to ensure a deterministic mesh path.
Default: 1 for the “default” mesh cluster profile and all user-created cluster profiles. The recovery profile has a priority of 255 (this is not a user-configured profile). The range is 1–
16.
Indicates the mesh cluster name. The name can have a maximum of 32 characters, which is used as the MSSID. When you create a new cluster profile, it is a member of the “Arubamesh” cluster.
NOTE: Each mesh cluster profile should have a unique MSSID. Configure a new MSSID before you apply the mesh cluster profile.
To view existing mesh cluster profiles, use the command: show ap mesh-cluster-profile .
A mesh portal chooses the best cluster profile and provisions it for use. A mesh point can have a maximum of 16 cluster profiles.
Default: Mesh cluster named “Aruba-mesh.”
Indicates the band for mesh operation for multiband radios. Select a or g.
615 | Secure Enterprise Mesh ArubaOS 6.5.3.x | User Guide
Associating a Mesh Cluster Profile to Mesh APs
Use the following procedure to associate a mesh cluster profile to a group of mesh APs or an individual mesh
AP using the WebUI. If you configure multiple cluster profiles with different cluster priorities, you manually override the link metric algorithm because the priority takes precedence over the path cost. In this scenario, the mesh portal uses the profile with the highest priority to bring-up the mesh network.
1. Navigate to the Configuration > Wireless > AP Configuration window. Select either the AP Group or AP
Specific tab.
n n
If you selected AP Group , click the AP group name to which you want to assign a new mesh cluster profile.
If you selected AP Specific , click the AP to which you want to assign a new mesh cluster profile
2. Under the Profiles list, expand the Mesh menu, then select Mesh Cluster profile .
3. In the Profile Details window pane, click the Mesh Cluster profile drop-down list select New .
n n
To add an existing mesh cluster profile to the selected AP group, click the Add a profile drop-down list and select a new profile name from the list.
To create a new mesh cluster profile to the selected AP group, click the Add a profile drop-down list and select NEW . Enter a name for the new mesh cluster profile.
4. Click the using priority drop-down list to select a priority for the mesh cluster profile. The lower the number, the higher the priority.
5. Click Add to add the mesh cluster profile to the AP group.
6. Click Apply . The profile name appears in the mesh cluster profile list with your configured settings. If you configure this for the AP group, this profile also becomes the mesh cluster profile used by the mesh portal for your mesh network.
Editing a Mesh Cluster Profile
If you modify any mesh cluster profile setting, you must reprovision your AP. For example, if you change the priority of a cluster profile from 5 to 2, you must reprovision the AP before you can assign priority 5 to another cluster profile. Reprovisioning the AP causes it to automatically reboot. For more information, see
1. Navigate to the Configuration > Wireless > AP Configuration window. Select either the AP Group or AP
Specific tab.
n n
If you selected the AP Group tab, click the Edit button by the AP group name with the profile you want to edit.
If you selected the AP Specific tab, click the Edit button by the AP with the profile you want to edit.
2. In the Profiles list, expand the Mesh menu, then select Mesh Cluster profile .
3. In the Profile Details window pane, click the Mesh Cluster profile drop-down list and select the name of the profile you want to edit.
4. Change the desired mesh radio settings as desired.
describes the parameters you can configure in the mesh high-throughput SSID profile.
A mesh cluster profile configured with wpa2-psk-aes encryption must have a defined WPA hexkey or a WPA passphrase (or both). If you have configured one encryption type but not the other, and want switch from a hexkey to a passphrase or vice versa, you must add the new encryption type, click Apply , then remove the encryption type you no longer want and click Apply again. You cannot delete one encryption type and add a different type in a single step.
5. Click Apply to save your changes.
ArubaOS 6.5.3.x
| User Guide Secure Enterprise Mesh | 616
Deleting a Mesh Cluster Profile
You can delete a mesh cluster profile only if no APs or AP groups are associated with that profile.
1. Navigate to the Configuration > Advanced Services> All Profiles window.
2. Expand the Mesh menu, then select Mesh Cluster profile . A list of high-throughput SSID profiles appears in the Profile Details window pane.
3. Click the Delete button by the name of the profile you want to delete.
Managing Mesh Cluster Profiles in the CLI
You must be in config mode to create, modify or delete a mesh cluster profile using the CLI. Specify an existing mesh cluster profile with the <profile-name> parameter to modify an existing profile, or enter a new name to create an entirely new profile.
Configuration details and any default values for each of these parameters are described in
. If you do not specify a parameter for a new profile, that profile uses the default value for that parameter.
Use the no option before any parameter to remove the current value for that parameter and return it to its default setting. Enter exit to leave the mesh cluster profile mode.
(host)(config) #ap mesh-cluster-profile <profile> clone <profile> cluster <name> no ...
opmode [opensystem | wpa2-psk-aes] rf-band {a | g} wpa-hexkey <wpa-hexkey> wpa-passphrase <wpa-passphrase>
The following examples create and configure the mesh cluster profiles cluster1 and cluster2 .
(host)(config) #ap mesh-cluster-profile cluster1 cluster corporate opmode wpa2-psk-aes wpa-passphrase mesh_123 rf-band a
(host)(config) #ap mesh-cluster-profile cluster2 cluster corporate opmode wpa2-psk-aes wpa-passphrase mesh_123 rf-band a
You can also create a new mesh radio profile by copying the settings of an existing profile using the clone parameter. Using the clone command to create a new profile makes it easier to keep constant attributes in common within multiple profiles.
(host)(config) #ap mesh-cluster-profile <profile-name> clone <source-profile-name>
Viewing Mesh Cluster Profile Settings
To view a complete list of mesh cluster profiles and their status:
(host)(config) #show ap mesh-cluster-profile
To view the settings of a specific mesh cluster profile:
(host)(config) #show ap mesh-cluster-profile <profile-name>
Associating Mesh Cluster Profiles
The following commands associate a mesh cluster profile to an AP group or an individual AP. For deployments with multiple mesh clusters, you must also configure the profile’s priority. Remember, the lower the priority
617 | Secure Enterprise Mesh ArubaOS 6.5.3.x | User Guide
number, the high the priority. The mesh cluster priority determines the order by which the mesh cluster profiles are used. This allows you, rather than the link metric algorithm, to control the network topology by defining the cluster profiles to use if one becomes unavailable.
To associate a mesh cluster profile to an AP group in a single-cluster deployment:
(host)(config) #ap-group <group> mesh-cluster-profile <profile-name>
To associate a mesh cluster profile to an individual AP in a single-cluster deployment:
(host)(config) #ap-name <name> mesh-cluster-profile <profile-name>
To associate a mesh cluster profile to an AP group in a multiple-cluster deployment:
(host)(config) #ap-group <group> mesh-cluster-profile <profile-name> priority <priority>
To associate a mesh cluster profile to an individual AP in a multiple-cluster deployment, use the command
(host)(config) #ap-name <name> mesh-cluster-profile <profile-name> priority <priority>
Example:
(host)(config) #ap-group group1 mesh-cluster-profile cluster1 priority 5 mesh-cluster-profile cluster2 priority 10
(host)(config) #ap-group2 mesh-cluster-profile cluster1 priority 10 mesh-cluster-profile cluster2 priority 5 mesh-radio-profile channel2
Excluding a Mesh Cluster Profile from a Mesh Node
To exclude a specific mesh cluster profile from an AP:
(host)(config) #ap-name <name> exclude-mesh-cluster-profile-ap <profile-name>
Deleting a Mesh Cluster Profile
If no APs are using a mesh cluster profile, you can delete that profile using the no parameter:
(host)(config) #no ap mesh-cluster-profile <profile-name>
Creating and Editing Mesh Radio Profiles
The mesh radio profile determines many of the settings used by mesh nodes to establish mesh links and the path to the mesh portal, including the maximum number of children a mesh node can accept, and transmit rates for the 802.11a and 802.11g radios. The attributes of the mesh radio profile are applied to a mesh point upon receiving its configuration from the controller. You can configure multiple radio profiles; however, you select and deploy only one radio profile per AP group. Radio profiles, including the “default” profile, are not active until you provision your APs for mesh.
If you modify a currently provisioned and running radio profile, your changes take effect immediately. You do not need to reboot the controller or the AP to apply the changes.
Managing Mesh Radio Profiles in the WebUI
Use the following procedures to define and manage mesh radio profiles using the WebUI.
Creating or Editing a Mesh Radio Profile
1. Navigate to the Configuration > Wireless > AP Configuration window. Select either the AP Group or AP
Specific tab.
n
If you selected the AP Group tab, click the AP group name for which you want to configure the new mesh radio profile.
ArubaOS 6.5.3.x
| User Guide Secure Enterprise Mesh | 618
n
If you selected the AP Specific tab, click the AP for which you want to create the mesh radio profile.
2. In the Profiles list, expand the Mesh menu, then select Mesh radio profile .
3. The procedure to create a new mesh profile varies slightly from the procedure to edit an existing profile.
n
To create a new mesh profile: in the Profile Details window pane, click the Mesh radio profile dropdown list and select New . Enter a new mesh radio profile name in the field to the right of the drop-down list.
n
To edit an existing mesh profile: in the Profile Details window pane, click the Mesh radio profile dropdown list and select the name of the profile you want to edit.
4. Configure your desired mesh radio settings.
Mesh Radio profile configuration settings are divided into two tabs, Basic and Advanced . The Basic tab displays only those configuration settings that often need to be adjusted to suit a specific network. The
Advanced tab shows all configuration settings, including settings that do not need frequent adjustment or should be kept at their default values. If you change a setting on one tab, then click and display the other tab without saving your configuration, that setting reverts to its previous value. The basic and advanced profile settings are described in
Table 138: Mesh Radio Profile Configuration Parameters
Parameter Description
Basic Mesh Radio Settings
Link Threshold Use this setting to optimize operation of the link metric algorithm.
Indicates the minimal RSSI value. If the RSSI value is below this threshold, the link may be considered a sub-threshold link. A sub-threshold link is one whose average RSSI value falls below the configured link threshold.
If this occurs, the mesh node may try to find a better link on the same channel and cluster
(only neighbors on the same channel are considered).
Default: 12. The supported threshold is hardware dependent, with a practical range of 10–
90.
Advanced Mesh Radio Settings
802.11a
Transmit Rates
802.11g
Transmit Rates
Indicates the transmit rates for the 802.11a radio.
The AP attempts to use the highest transmission rate to establish a mesh link. If a rate is unavailable, the AP goes through the list and uses the next highest rate.
To modify transmit rates, do one of the following: n n
In the WebUI, deselect (uncheck) a specific rate box to use fewer rates when establishing a mesh link.
In the CLI, enter the specific rates to use.
Default: All transmission rates are selected and used. If you do not select 802.11a or
802.11g transmit rates, all rates are selected by default when you click Apply .
Indicates the transmit rates for the 802.11g radio.
The AP attempts to use the highest transmission rate to establish a mesh link. If a rate is unavailable, the AP goes through the list and uses the next highest rate.
To modify transmit rates, do one of the following: n n
In the WebUI, deselect (uncheck) a specific rate box to use fewer rates when establishing a mesh link.
In the CLI, enter the specific rates to use.
Default: All transmission rates are selected and used. If you do not select 802.11a or
802.11g transmit rates, all rates are selected by default when you click Apply .
Allowed VLANs on Mesh Link
List the VLAN ID numbers of VLANs allowed on the mesh link.
619 | Secure Enterprise Mesh ArubaOS 6.5.3.x | User Guide
Parameter
BC/MC Rate
Optimization
Heartbeat threshold
Maximum
Children
Maximum Hop
Count
Mesh Private
VLAN
Mesh
Survivability
Metric algorithm
Description
Broadcast/Multicast Rate Optimization dynamically selects the rate for sending broadcast/multicast frames on any BSS. This feature determines the optimal rate for sending broadcast and multicast frames based on the lowest of the unicast rates across all associated clients.
When you enable the Multicast Rate Optimization feature, the controller scans the list of all associated stations in that BSS and finds the lowest transmission rate as indicated by the rate adaptation state for each station. If there are no associated stations in the BSS, it selects the lowest configured rate as the transmission rate for broadcast and multicast frames.
This feature is enabled by default. Multicast Rate Optimization applies to broadcast and multicast frames only. 802.11 management frames are not affected by this feature and are transmitted at the lowest configured rate. When enabled, this setting dynamically adjusts the multicast rate to that of the slowest connected mesh child. Multicast frames are not sent if there are no mesh children.
NOTE: This feature should only be enabled on a BSS where all associated stations are sending or receiving unicast data. If there is no unicast data to or from a particular station, then the rate adaptation state may not accurately reflect the current sustainable transmission rate for that station. This could result in a higher packet error rate for broadcast/multicast packets at that station. Configuring the Video Multicast Rate
Optimization parameter overrides the configuration of BC/MC Rate Optimization parameter for VI-tagged multicast traffic. Multicast traffic that is not VI-tagged behaves the same with BC/MC as before. If multicast rate is not set, all traffic behaves the same.
Default: Enabled.
Indicates the maximum number of heartbeat messages that can be lost between neighboring mesh nodes.
Default: 10 missed heartbeats.
Range: 1–255.
Indicates the maximum number of children a mesh node can accept.
Default: 64 children.
Range: 1–64
Indicates the maximum hop count from the mesh portal.
Default: 8 hops.
Range: 1–32
A VLAN ID for control traffic between an remote mesh portal and mesh nodes. This VLAN
ID must not be used for user traffic.
Range: 0–4094. Default: 0 (disabled).
For further information on configuring a remote mesh portal, see
Mesh Portals (RMPs) on page 635
This feature is currently not supported and should only be enabled under the supervision of Aruba support.
This parameter specifies the algorithm used by a mesh node to select its parent. Use this setting to optimize operation of the link metric algorithm.
Available options are: n n best-link-rssi: Selects the parent with the strongest RSSI, regardless of the number of children a potential parent has.
distributed-tree-rssi: selects the parent based on link-RSSI and node cost based on the number of children. This option evenly distributes the mesh points over high quality uplinks. Low quality uplinks are selected as a last resort.
Default: distributed-tree-rssi. It is recommended to use the default value.
ArubaOS 6.5.3.x
| User Guide Secure Enterprise Mesh | 620
Parameter
Rate
Optimization for delivering
EAPOL frames and mesh echoes
Reselection mode
Description
When you enable this parameter, EAPOL frames, mesh echo requests and echo responses are sent at a lower rate.
Retry Limit
RTS Threshold
Use this setting to optimize operation of the link metric algorithm.
Available options are: n n reselect-anytime reselect-never n n startup-subthreshold subthreshold-only
For complete information on reselection mode options, see
Indicates the number of times a mesh node can re-send a packet.
Default: 4 times.
Range: 1–15
Defines the packet size sent by mesh nodes. Mesh nodes transmitting frames larger than this threshold must issue request to send (RTS) and wait for other mesh nodes to respond with clear to send (CTS) to begin transmission. This helps prevent mid-air collisions.
Default: 2,333 bytes.
Range: 256– 2,346.
5. Click Apply . The profile name appears in the Mesh Radio Profile list with your configured settings.
If you configure this for the AP group, this profile also becomes the selected radio profile used by the mesh portal for your mesh network.
Assigning a Mesh Radio Profile to a Mesh AP or AP Group
1. Navigate to the Configuration > Wireless > AP Configuration window. Select either the AP Group or
AP Specific tab.
n n
If you selected AP Group , click the AP group to which you want to assign a new mesh radio profile.
If you selected AP Specific, click the AP to which you want to assign a new mesh radio profile.
2. Under the Profiles list, expand the Mesh menu, then select Mesh Radio profile .
3. In the Profile Details window pane, click the Mesh Radio profile drop-down list and select the desired mesh radio profile from the list.
4. Click Apply . The profile name appears in the Mesh Radio Profile list with your configured settings. If you configure this for the AP group, this profile also becomes the selected radio profile used by the mesh portal for your mesh network.
5. Click the Delete button by the name of the profile you want to delete.
Managing Mesh Radio Profiles in the CLI
You must be in config mode to create, modify, or delete a mesh radio profile using the CLI. Specify an existing mesh profile with the <profile-name> parameter to modify an existing profile, or enter a new name to create an entirely new profile.
Creating or Modifying a Mesh Radio Profile
Configuration details and any default values for each of these parameters are described in
. If you do not specify a parameter for a new profile, that profile uses the default value for that parameter. Put the no
621 | Secure Enterprise Mesh ArubaOS 6.5.3.x | User Guide
option before any parameter to remove the current value for that parameter and return it to its default setting. Enter exit to leave the mesh radio profile mode.
(host)(config) #ap mesh-radio-profile <profile-name> a-tx-rates allowed-vlans children <children> clone <source-profile-name> eapol-rate-opt g-tx-rates [1|2|5|6|9|11|12|18|24|36|48|54] heartbeat-threshold <count> hop-count <hop-count> link-threshold <count> max-retries <max-retries> mesh-ht-ssid-profile mesh-mcast-opt mesh-survivability metric-algorithm {best-link-rssi|distributed-tree-rssi} mpv <vlan-id> no reselection-mode rts-threshold <rts-threshold>
You can also create a new mesh radio profile by copying the settings of an existing profile using the clone parameter. Using the clone command to create a new profile makes it easier to keep constant attributes in common within multiple profiles.
(host)(config) #ap mesh-radio-profile <profile-name> clone <source-profile-name>
Assigning a Mesh Radio Profile to a Mesh AP or AP Group
To associate a mesh radio profile with an AP group, use the following commands. When you add the mesh cluster profile to the AP group, you must also define the cluster priority.
(host)(config) #ap-group <group> mesh-radio-profile <profile-name> priority <priority>
To associate a mesh radio profile with an individual AP:
(host)(config) #ap-name <name> mesh-radio-profile <profile-name> priority <priority>
The following examples assign the mesh cluster profiles cluster1 and cluster2 to two different AP groups. In the AP group group1, cluster1 has a priority of 5, and cluster2 has a priority of 10, so cluster1 has the higher priority. In the AP group group2 , cluster1 has a priority of 10, and cluster2 has a priority of 5, so cluster5 has the higher priority.
(host)(config) #ap-group group1
mesh-cluster-profile cluster1 priority 5
mesh-cluster-profile cluster2 priority 10
(host)(config) #ap-group group2 mesh-cluster-profile cluster1 priority 10 mesh-cluster-profile cluster2 priority 5
Deleting Mesh Radio Profiles
You can delete a mesh radio profile only if no other APs or AP groups use that profile.
To delete a mesh radio profile using the WebUI:
1. Navigate to the Configuration > Advanced Services> All Profiles window.
2. Expand the Mesh menu, then select Mesh radio profile . A list of mesh radio profiles appears in the
Profile Details window pane.
ArubaOS 6.5.3.x
| User Guide Secure Enterprise Mesh | 622
3. Click Delete by the name of the profile you want to delete.
The following command deletes a radio profile via the command-line interface.
(host)(config)no ap mesh-radio-profile <profile-name>
Creating and Editing Mesh High-Throughput SSID Profiles
The mesh high-throughput SSID profile defines settings unique to 802.11n and 802.11ac-capable, highthroughput APs. If none of the APs in your mesh deployment are 802.11n or 802.11ac-capable APs, you do not need to configure a high-throughput SSID profile. If you modify a currently provisioned and running highthroughput SSID profile, your changes take effect immediately. You do not need to reboot the controller or the
AP.
Managing Mesh High-Throughput SSID Profiles in the WebUI
Use the following procedures to manage your high-throughput SSID profiles using the WebUI.
Creating a Profile
To create a high-throughput SSID profile:
1. Navigate to the Configuration > Wireless > AP Configuration window. Select either the AP Group or AP
Specific tab.
n
If you selected AP Group , click the AP group for which you want to create the new high-throughput SSID profile.
n
If you selected AP Specific , click the AP for which you want to create the new high-throughput SSID profile.
2. In the Profiles list, expand the Mesh menu, then select Mesh High-throughput SSID profile .
3. In the Profile Details window pane, click the Mesh High-throughput SSID profile drop-down list and select NEW .
4. Enter a name for the new profile.
5. Configure the mesh high-throughput SSID parameters described in
. The Mesh High-Throughput
SSID Profile configuration settings are divided into two tabs, Basic and Advanced . The Basic tab displays only those configuration settings that often need to be adjusted to suit a specific network. The Advanced tab shows all configuration settings, including settings that do not need frequent adjustment or should be kept at their default values. If you change a setting on one tab then click and display the other tab without saving your configuration, that setting reverts to its previous value.
6. Click Apply . The profile name appears in the Mesh High-throughput SSID Profile list with your configured settings.
Table 139: Mesh High-Throughput SSID Profile Configuration Parameters
Parameter Description
Basic Mesh High-Throughput SSID Profile Settings
40 MHz channel usage Enable or disable the use of 40 MHz channels.
Default: enabled
80 MHz channel usage Enable or disable the use of 80 MHz channels.
Default: enabled
623 | Secure Enterprise Mesh ArubaOS 6.5.3.x | User Guide
Parameter
High-throughput Enable
(SSID)
Explicit Transmit
Beamforming
Transmit Beamforming
Compressed Steering
Transmit Beamforming non Compressed Steering
Transmit Beamforming delayed feedback support
Transmit Beamforming immediate feedback support
Transmit Beamforming
Sounding Interval
Description
Enable or disable high-throughput (802.11n) features on the SSID.
Default: enabled
Enable/Disable use of Explicit Transmit Beamforming. (For 130 Series only)
If this parameter is disabled, the other transmit beamforming configuration settings have no effect.
When enabled, the AP can use explicit compressed feedback from clients to obtain a steering matrix. (For 130 Series APs only.)
Default: enabled
When enabled, the AP can use explicit noncompressed feedback from clients to obtain a steering matrix. (For 130 Series only)
Default: enabled
Enable/Disable delayed feedback/report support in Transmit Beamforming.
(For 130 Series only)
Default: enabled
Enable/Disable immediate feedback/report support in Transmit Beamforming.
(For 130 Series only)
Default: enabled
Time interval in seconds between updates of Transmit Beamforming channel estimation. (For 130 Series only)
The supported range is 1-65335 seconds, and the default is 1800 seconds.
Enable or disable very high-throughput (802.11av) features on the SSID.
Default: enabled
Very High throughput enable (VHT)
Advanced Mesh High-Throughput SSID Profile Settings
Temporal Diversity Enable When a client is not responding to 802.11 packets, the AP will launch two hardware retries. If you enable this option and hardware retries are not successful, then the AP will launch and the software retries.
BA AMSDU Enable
Legacy stations
Enable/Disable Receive AMSDU in BA negotiation.
Allow or disallow associations from legacy (non-HT) stations. By default, this parameter is enabled (legacy stations are allowed).
Low-density Parity Check
Maximum number of spatial streams usable for
STBC reception
If enabled, the AP advertises Low-density Parity Check (LDPC) support LDPC improves data transmission over radio channels with high levels of background noise. (For 130 Series only)
Controls the maximum number of spatial streams usable for STBC reception.
0 disables STBC reception, 1 uses STBC for MCS 0-7. Higher MCS values are not supported. (Supported on the 130 Series, 170 Series and AP-105 only. The configured value adjusts based on AP capabilities.)
If transmit beamforming is enabled, STBC is disabled for disabled for beamformed frames.
ArubaOS 6.5.3.x
| User Guide Secure Enterprise Mesh | 624
Parameter Description
Maximum number of spatial streams usable for
STBC transmission.
MPDU Aggregation
Controls the maximum number of spatial streams usable for STBC transmission. 0 disables STBC transmission, 1 uses STBC for MCS 0-7. Higher
MCS values are not supported. (Supported on 170 Series, 130 Series and
AP-105 only. The configured value adjusts based on AP capabilities.)
If you enable transmit beamforming, STBC is disabled for disabled for beamformed frames.
Enable or disable MAC protocol data unit (MPDU) aggregation.
High-throughput APs are able to send aggregated MAC protocol data units
(MDPUs), which allow an AP to receive a single block acknowledgment instead of multiple ACK signals. This option, which is enabled by default, reduces network traffic overhead by effectively eliminating the need to initiate a new transfer for every MPDU.
Max received A-MPDU size Maximum size of a received aggregate MPDU, in bytes. Allowed values: 8191,
16383, 32767, 65535.
Max transmitted A-MPDU size
Maximum size of a transmitted aggregate MPDU, in bytes.
Range: 1576–65535
Maximum number of
MSDUs in an A-MSDU on best-effort AC
Maximum number of
MSDUs in an A-MSDU on background AC
Maximum number of
MSDUs in an A-MSDU on video AC
Maximum number of MSDUs in a TX A-MSDU on best-effort AC. TX-AMSDU disabled if 0.
Range: 0-15
Default: 2
Maximum number of MSDUs in a TX A-MSDU on background. TX-AMSDU disabled if 0.
Range: 0-15
Default: 2
Maximum number of MSDUs in a TX A-MSDU on video AC. TX-AMSDU disabled if 0.
Range: 0-15
Default: 2
Maximum number of
MSDUs in an A-MSDU on voice AC
Maximum VHT MPDU size
Min MPDU start spacing
Maximum number of MSDUs in a TX A-MSDU on voice AC. TX-AMSDU disabled if 0.
Range: 0-15
Default: 0
Maximum size of a VHT MPDU, in bytes.
Range: 3895, 7991, 11454
Minimum time between the start of adjacent MPDUs within an aggregate
MPDU, in microseconds. Allowed values: 0 (No restriction on MDPU start spacing), .25 µsec, .5 µsec, 1 µsec, 2 µsec, 4 µsec.
625 | Secure Enterprise Mesh ArubaOS 6.5.3.x | User Guide
Parameter
Short guard interval in 20
MHz mode
Short guard interval in 40
MHz mode
Short guard interval in 80
MHz mode
Description
Enable or disable use of short (400ns) guard interval in 20 MHz mode. This parameter is enabled by default.
A guard interval is a period of time between transmissions that allows reflections from the previous data transmission to settle before an AP transmits data again. An AP identifies any signal content received inside this interval as unwanted inter-symbol interference, and rejects that data. The
802.11n standard specifies two guard intervals: 400ns (short) and 800ns
(long). Enabling a short guard interval can decrease network overhead by reducing unnecessary idle time on each AP. Some outdoor deployments, may, however require a longer guard interval. If the short guard interval does not allow enough time for reflections to settle in your mesh deployment, intersymbol interference values may increase and degrade throughput.
Enable or disable use of short (400ns) guard interval in 40 MHz mode. This parameter is enabled by default.
A guard interval is a period of time between transmissions that allows reflections from the previous data transmission to settle before an AP transmits data again. An AP identifies any signal content received inside this interval as unwanted inter-symbol interference, and rejects that data. The
802.11n standard specifies two guard intervals: 400ns (short) and 800ns
(long). Enabling a short guard interval can decrease network overhead by reducing unnecessary idle time on each AP. Some outdoor deployments, may, however require a longer guard interval. If the short guard interval does not allow enough time for reflections to settle in your mesh deployment, intersymbol interference values may increase and degrade throughput.
Enable or disable use of short (400ns) guard interval in 80 MHz mode.
A guard interval is a period of time between transmissions that allows reflections from the previous data transmission to settle before an AP transmits data again. An AP identifies any signal content received inside this interval as unwanted inter-symbol interference, and rejects that data.
The 802.11n standard specifies two guard intervals: 400ns (short) and 800ns
(long). Enabling a short guard interval can decrease network overhead by reducing unnecessary idle time on each AP. Some outdoor deployments, may, however require a longer guard interval. If the short guard interval does not allow enough time for reflections to settle in your mesh deployment, intersymbol interference values may increase and degrade throughput.
This parameter is enabled by default.
ArubaOS 6.5.3.x
| User Guide Secure Enterprise Mesh | 626
Parameter
Supported MCS set
VHT - Support MCS Map
Description
A list of Modulation Coding Scheme (MCS) values or ranges of values to be supported on this SSID. The MCS you choose determines the channel width
(20MHz vs. 40MHz) and the number of spatial streams used by the mesh node.
The default value is 1–23; the complete set of supported values. To specify a smaller range of values, enter a hyphen between the lower and upper values.
To specify a series of different values, separate each value with a comma.
Examples:
2–10
1,3,6,9,12
Range: 0–23.
A list of Modulation Coding Scheme (MCS) values or ranges of values to be supported on this SSID. The MCS you choose determines the channel width
(20MHz vs. 40MHz vs 80MHz) and the number of spatial streams used by the mesh node.
The default value is 1–23; the complete set of supported values. To specify a smaller range of values, enter a hyphen between the lower and upper values.
To specify a series of different values, separate each value with a comma.
Examples:
2–10
1,3,6,9,12
Range: 0–23.
Enable/Disable use of VHT Explicit Transmit Beamforming.
vht-txbf-explicit-enable
Assigning a Profile to an AP Group
1. Navigate to the Configuration > Wireless > AP Configuration window. Select either the AP Group or
AP Specific tab.
n
If you selected AP Group , click the AP group name to which you want to assign a new high-throughput
SSID profile.
n
If you selected AP Specific , click the AP to which you want to assign a new high-throughput SSID profile
2. Under the Profiles list, expand the Mesh menu, then select Mesh High-throughput SSID profile .
3. In the Profile Details window pane, click the Mesh High-throughput SSID profile drop-down list and select the desired profile from the list.
4. Click Apply . The profile name appears in the Mesh High-throughput SSID Profile list with your configured settings. If you configure this for the AP group, this profile also becomes the selected high-throughput SSID profile used by the mesh portal for your mesh network.
Editing a Profile
1. Navigate to the Configuration > Wireless > AP Configuration window. Select either the AP Group or AP
Specific tab.
n
If you selected the AP Group tab, click the AP group name with the profile you want to edit.
n
If you selected the AP Specific tab, click the AP with the profile you want to edit.
2. In the Profiles list, expand the Mesh menu, then select Mesh High-throughput SSID profile .
3. In the Profile Details window pane, click the Mesh High-throughput SSID profile drop-down list and select the name of the profile you want to edit.
4. Change the settings as desired.
describes the parameters you can configure in this profile.
5. Click Apply .
627 | Secure Enterprise Mesh ArubaOS 6.5.3.x | User Guide
Deleting a Profile
You can delete a mesh high-throughput SSID profile only if no APs or AP groups are associated with that profile.
1. Navigate to the Configuration > Advanced Services> All Profiles window.
2. Expand the Mesh menu, then select Mesh High-throughput SSID profile . A list of high-throughput SSID profiles appears in the Profile Details window pane.
3. Click Delete by the name of the profile you want to delete.
Managing Mesh High-Throughput SSID Profiles in the CLI
You must be in config mode to create, modify or delete a mesh high-throughput SSID radio profile using the
CLI. Specify an existing high-throughput SSID profile with the <profile-name> parameter to modify an existing profile, or enter a new name to create an entirely new profile.
Creating or Modifying a Profile
Configuration details and any default values for each of these parameters are described in
. If you do not specify a parameter for a new profile, that profile uses the default value for that parameter. Put the no option before any parameter to remove the current value for that parameter and return it to its default setting. Enter exit to leave the high-throughput radio profile mode.
(host)(config) #ap mesh-ht-ssid-profile <profile-name>
40MHz-enable clone high-throughput-enable ldpc legacy-stations max-rx-a-mpdu-size max-tx-a-mpdu-size min-mpdu-start-spacing mpdu-agg no short-guard-intvl-20mhz short-guard-intvl-40mhz stbc-rx-streams stbc-tx-streams supported-mcs-set temporal-diversity
You can also create a new mesh high-throughput SSID profile by copying the settings of an existing profile using the clone parameter. Using the clone command to create a new profile makes it easier to keep constant attributes in common within multiple profiles.
ap mesh-ht-ssid-profile <profile-name> clone <source-profile-name>
Assigning a Profile to an AP Group
To associate a mesh high-throughput SSID profile with an AP group:
(host)(config) #ap-group <group> mesh-ht-ssid-profile <profile-name>
To associate a mesh radio profile with an individual AP:
(host)(config) #ap-name <name> mesh-ht-ssid-profile <profile-name>
Viewing High-throughput SSID Settings
To view a complete list of high-throughput profiles and their status:
(host)(config) #show ap mesh-ht-ssid-profile
To view the settings of a specific high-throughput profile:
ArubaOS 6.5.3.x
| User Guide Secure Enterprise Mesh | 628
(host)(config) #show ap mesh-ht-ssid-profile <profile-name>
Deleting a Profile
If no AP or AP group is using a mesh high-throughput SSID profile, you can delete that profile using the no parameter:
(host)(config) no ap mesh-ht-ssid-profile <profile-name>
Configuring Ethernet Ports for Mesh
If you use mesh to join multiple Ethernet LANs, configure and enable bridging on the mesh point Ethernet port
This section describes how to configure Ethernet ports for bridging or secure jack operation using the wired AP profile. The wired AP profile controls the configuration of the Ethernet port(s) on your AP.
Mesh nodes only support bridge mode and tunnel mode on their wired ports (enet0 or enet1). Split tunnel mode is not supported. Use bridge mode to configure bridging on the mesh point Ethernet port. Use tunnel mode to configure secure jack operation on the mesh node Ethernet port.
When configuring the Ethernet ports on dual-port APs, note the following requirements for the AP configures as a mesh portal: n n
Connect enet0 to the controller to obtain an IP address. The wired AP profile controls enet1.
Only enet1 supports secure jack operation.
Configuring Bridging on the Ethernet Port
Use the following procedure to configure bridging on the Ethernet port via the WebUI.
1. Navigate to the Configuration > Wireless > AP Configuration > AP Group window.
2. Click the AP group name with the wired ap profile you want to edit.
3. Under the Profiles list, expand the AP menu , then select Wired AP profile . The settings for the currently selected wired AP profile appear.
You can use a different wired AP profile by selecting a profile from the Wired AP profile drop-down list.
4. Under Profile Details, do the following: a. Select the Wired AP enable check box. This option is not selected by default.
b. From the Forward mode drop-down list, select bridge .
c. Optionally, from the Switchport mode drop-down list, select access or trunk . These options only apply to bridge mode configurations.
n n
Access mode forwards untagged packets received on the port to the controller and they appear on the configured access mode VLAN. Tagged packets are dropped. All packets received from the controller and sent via this port are untagged. Define the access mode VLAN in the Access mode
VLAN field.
Trunk mode contains a list of allowed VLANs. Any packet received on the port that is tagged with an allowed VLAN is forwarded to the controller. Untagged packets are forwarded to the controller on the configured Native VLAN. Packets received from the controller and sent out the port remain tagged unless the tag value in the packet is the Native VLAN, in which case the tag is removed. Define the
Native VLAN in the Trunk mode native VLAN field and the other allowed VLANs in the Trunk mode allowed VLANs field.
d. Optionally, select Trusted to configure this as a trusted port.
5. Click Apply .
Use the following commands to configure Ethernet port bridging via the CLI.
629 | Secure Enterprise Mesh ArubaOS 6.5.3.x | User Guide
(host)(config) #ap wired-ap-profile <profile> forward-mode bridge wired-ap-enable
Optionally, you can configure the following wired AP profile settings:
(host)(config) #ap wired-ap-profile <profile> switchport mode {access | trunk} switchport access vlan <vlan> switchport trunk native vlan <vlan> switchport trunk allowed vlan <vlan> trusted
Configuring Ethernet Ports for Secure Jack Operation
You can configure the Ethernet port(s) on mesh nodes to operate in tunnel mode. Known as secure jack operation for mesh, this configuration allows Ethernet frames coming into the specified wired interface to be generic routing encapsulation (GRE) tunneled to the controller. Likewise, Ethernet frames coming from the tunnel are bridged to the corresponding wired interface. This allows an Ethernet port on the mesh node to appear as an Ethernet port on the controller separated by one or more Layer-3 domains. You can also enable
VLAN tagging.
Unlike secure jack on non-mesh APs, any mesh node configured for secure jack uses the mesh link, rather than enet0, to tunnel the frame to the controller.
When configuring mesh Ethernet ports for secure jack operation, note the following guidelines: n n
Mesh points support secure jack on enet0 and enet1.
Mesh portals only support secure jack on enet1. This function is only applicable to Aruba APs that support a second Ethernet port and mesh, such as the 130 Series.
You configure secure jack operation in the wired AP profile.
The parameters in the wired AP profile only apply to the wired AP interface to which they are applied. Two wired interfaces can have different parameter values.
In the WebUI
Use the following procedure to configure secure jack operation using the WebUI.
1. Navigate to the Configuration > Wireless > AP Configuration > AP Group window.
2. Click the AP group with the wired AP profile you want to edit.
3. Under the Profiles list, expand the AP menu , then select Wired AP profile . The settings for the currently selected wired AP profile appear.
You can use a different wired AP profile by selecting a profile from the Wired AP profile drop-down list.
4. In the Profile Details window pane, do the following: a. Select the Wired AP enable check box. This option is not selected by default.
b. From the Forward mode drop-down list, select tunnel .
c. Optionally, select Trusted to configure this as a trusted port.
5. Click Apply .
In the CLI
To configure secure jack operation using the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #ap wired-ap-profile <profile> forward-mode tunnel wired-ap-enable
ArubaOS 6.5.3.x
| User Guide Secure Enterprise Mesh | 630
Optionally, you can configure the following wired AP profile settings:
(host)(config) #ap wired-ap-profile <profile> trusted
Extending the Life of a Mesh Network
To prevent your mesh network from going down if you experience a controller failure, modify the following settings in the AP system profile(s) used by mesh nodes to maintain the mesh network until the controller is available:
It is recommended to use the default maximum request retries and bootstrap threshold settings for most mesh networks; however, if you must keep your mesh network alive, you can modify the settings as described in this section. The modified settings are not applicable if mesh portals are directly connected to the controller.
n n
Maximum request retries: maximum number of times to retry AP-generated requests. The default is 10 times. If you must modify this setting, it is recommended to set a value of 10,000.
Bootstrap threshold: number of consecutive missed heartbeats before the AP rebootstraps. (Heartbeats are sent once per second.) The default is 9 missed heartbeats. If you must modify this setting, it is recommended to set a value of 5,000.
When the controller comes back online, the affected mesh nodes (mesh portals and mesh points) rebootstrap; however, the mesh link is not affected and continues to be up.
In the WebUI
Use the following procedure to modify the AP system profile via the WebUI.
1. Navigate to the Configuration > Wireless > AP Configuration > AP Group window.
2. Click the AP group with the AP system profile you want to edit.
3. Under Profiles list, expand the AP menu, then select AP system profile . The settings for the currently selected AP system profile appear in the Profile Details window pane.
4. Make the following changes in the Profile Details window pane.
a. Change the Maximum Request Retries to 10000.
b. Change the Bootstrap threshold to 5000.
5. Click Apply .
In the CLI
To modify the AP system profile via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #ap system-profile <profile> max-request-retries 10000 bootstrap-threshold 5000
Provisioning Mesh Nodes
Provisioning mesh nodes is similar to thin APs; however, there are some key differences. Thin APs establish a channel to the controller from which they receive the configuration for each radio interface. Mesh nodes, in contrast, get their radio interfaces up and running before making contact with the controller. This requires a minimum set of parameters from the AP group and mesh cluster that enables the mesh node to discover a neighbor to create a mesh link and subsequent channel with the controller. To do this, you must first configure mesh cluster profiles for each mesh node prior to deployment. See
Creating and Editing Mesh Radio Profiles
for more information.
631 | Secure Enterprise Mesh ArubaOS 6.5.3.x | User Guide
On each radio interface, you provision a mode of operation: mesh node or thin AP (access) mode. If you do not specify mesh, the AP operates in thin AP (access) mode. If you configure mesh, the AP is provisioned with a minimum of two mesh cluster profiles: the “default” mesh cluster profile and an emergency read-only recovery profile, as described in the section
Configuring Mesh Cluster Profiles . If you create and select multiple mesh
cluster profiles, the AP is provisioned with those as well. If you have a dual-radio AP and configure one radio for mesh and the other as a thin AP, each radio is provisioned as configured.
Each radio provisioned in mesh mode can operate in one of two roles: mesh portal or mesh point. You explicitly configure the role, as described in this section. This allows the AP to know whether it uses the mesh link (via the mesh point/mesh portal) or an Ethernet link to establish a connection to the controller.
During the provisioning process, mesh nodes look for a mesh profile that the AP group and AP name is a member of and stores that information in flash. If you have multiple cluster profiles, the mesh portal uses the best profile to bring-up the mesh network. Mesh points in contrast go through the list of mesh cluster profiles in order of priority to decide which profile to use to associate themselves with the network. In addition, when a mesh point is provisioned, the country code is sent to the AP from its AP name or AP group along with the mesh cluster profiles. Mesh nodes also learn the recovery profile, which is automatically generated by the master controller. If the other mesh cluster profiles are unavailable, mesh nodes use the recovery profile to establish a link to the master controller; data forwarding does not take place.
If you create a new mesh cluster profile for an existing deployment, you must re-provision the AP for the new profile to take effect. If you re-provision mesh nodes that are already operating, re-provision the most distant (highest hop count) mesh points first followed by the mesh portals. If you re-provision the mesh portal first, the mesh points may be unable to form a mesh link. Re-provisioning the AP causes it to automatically reboot. This may cause a disruption of service to the network.
Provisioning Caveats
Remember the following when provisioning APs for mesh: n n n n
You must provision the AP before you install it as a mesh node in a mesh deployment. To provision the AP, it must be physically connected to the local network or directly connected to the controller. When connected and powered on, the AP must also be able to obtain an IP address from a DHCP server on the local network or from the controller.
Make sure the provisioned mesh nodes form a connected mesh network before physically deploying the
APs. For more information, see
.
In multi-controller networks, save your mesh cluster configuration before provisioning the mesh nodes. To save your configuration in the WebUI, at the top of any window click Save Configuration . To save your configuration in the CLI, use the command write memory .
If the same port on the controller is used to provision APs and provide PoE for mesh nodes, you must stop traffic from passing through that port after you provision the AP. To stop traffic, shut down (disable) the port either by using the CLI command interface fastethernet <slot>/<module>/<port> shutdown , or by following the procedure below.
1. Navigate to the Configuration > Network > Ports window.
2. Under Port Selection , click the port to configure.
3. Under Configure Selected Port , deselect (uncheck) Enable Port .
4. Make sure Enable 802.3af Power Over Ethernet is selected.
5. Click Apply .
Provisioning Mesh Nodes
Reprovisioning the AP causes it to automatically reboot. The following procedures describe the process to provision a mesh portal or mesh node via the WebUI or CLI. (The easiest way to provision a mesh node is to
ArubaOS 6.5.3.x
| User Guide Secure Enterprise Mesh | 632
use the Provisioning window in the WebUI.) To provision a remote mesh portal, see
.
In the WebUI
1. Navigate to the Configuration > Wireless > AP Installation > Provisioning window. Select the AP to provision for mesh and click Provision .
2. In the Master Discovery section, set the Master IP address as the controller IP address.
3. In the IP settings section, select Obtain IP Address Using DHCP .
4. In the AP List section, do the following: n
Configure the Mesh Role: n
To configure the AP as the mesh portal, select Mesh Portal .
n n n
To configure the AP as a mesh point, select Mesh Point .
Configure the Outdoor Parameters, if needed. The following parameters are available only if configuring an outdoor AP:
Latitude coordinates (degrees, minutes, seconds, north or south) n n n n
Longitude coordinates (degrees, minutes, seconds, east or west)
Altitude (in meters)
Antenna bearing (horizontal coverage)
Antenna tilt angle (optimum coverage)
The above parameters apply to all outdoor APs, not just outdoor APs configured for mesh.
5. Click Apply and Reboot . After the controller reboots, mesh cluster profiles are extracted from the AP group and the AP name.
In the CLI
When you use the command-line interface to reprovision a mesh node, you may also provision other AP settings.
Access the CLI in config mode and issue the following commands:
(host)(config) #provision-ap read-bootinfo ap-name <name> mesh-role {mesh-point|mesh-portal} reprovision ap-name <name>
If you are provisioning an outdoor AP, you can also configure the following parameters:
(host)(config) #provision-ap read-bootinfo ap-name <name> mesh-role {mesh-point|mesh-portal} a-ant-bearing <bearing> a-ant-tilt-angle <angle> g-ant-bearing <bearing> g-ant-tilt-angle <angle> altitude <altitude> latitude <location> longitude <location> reprovision ap-name <name>
Verifying Your Mesh Network
To view a list of your Mesh APs via the WebUI, navigate to the one of the following windows:
633 | Secure Enterprise Mesh ArubaOS 6.5.3.x | User Guide
n n n n
Monitoring > Network > All Mesh Nodes
Monitoring > Controller > Mesh Nodes
To view mesh APs and the mesh topology tree using the command line interface, access the command-line interface in enable mode and issue the following commands:
#show ap mesh active
#show ap mesh topology
Verification Checklist
After provisioning the mesh APs, follow the steps below to ensure that the mesh network is up and operating correctly.
n n n n n
Issue the command show ap mesh topology to verify all the mesh APs are up and the topology is as expected. (Wait 10 minutes after startup for the topology to stabilize.)
Verify each mesh node has the expected RSSI to its neighboring mesh nodes. The mesh topology is updated periodically, so access the command-line interface and issue the command show ap mesh neighbors for the current status. If the RSSI is low, verify that the tx-power settings in the mesh node’s
802.11a/802.11g radio profiles are correct, or, if ARM is used, verify the correct minimum tx-power setting.
Issue the command show ap mesh debug provisioned-clusters to verify that the mesh clusters are correctly defined and provisioned (with encryption if desired). Issue the show running-config | include recovery command to verify that the cluster’s recovery profile matches the controller's recovery profile.
Verify antenna provisioning by issuing the show ap provisioning command and verify installation parameters for non-default installations (that is, standard indoor APs deployed outside, or outdoor APs deployed inside). Ensure all APs use the same channel list by issuing the show ap allowed-channels command.
If the mesh-radio is to be reserved exclusively for mesh backhaul traffic , issue the command show ap profile-usage to identify the radio’s 802.11a or 802.11g radio profile, then issue the command show rf dot11a-radio-profile <profile> or show rf dot11g-radio-profile <profile> to verify the radio is disabled in the profile. Next, use the show ap bss-table command to that verify no access Virtual APs are up on the mesh radio.
CLI Examples
Use the show ap mesh active command to verify all nodes are present and that EIRP is correct:
(host) #show ap mesh active
Mesh Cluster Name: meshprofile1
------------------------------
Name Group
---- -----
IP Address
---------mp1 mp2 mp3 mpp mp1 mp2
10.3.148.245
10.3.148.250
mp3 10.3.148.253
mpp125 10.3.148.252
BSSID
-----
Band/Ch/EIRP/MaxEIRP MTU Enet 0/1 Mesh Role
-------------------- --- -------- ---------
00:1a:1e:85:c0:30 802.11a/157/19/36 Off/Off Point
00:1a:1e:88:11:f0 802.11a/157/19/36 Bridge/Bridge Point
00:1a:1e:88:01:f0 802.11a/157/19/36 Bridge/Bridge Point
00:1a:1e:88:05:50 802.11a/157/19/36 1578 -/Bridge Portal
Parent #Children
------ --------mp3 0 mpp mp2
-
1
1
1
AP Type
-------
125
125
125
125
Uptime
------
13d:2h:25m:19s
14d:21h:23m:49s
14d:21h:14m:55s
14d:19h:5m:3s
Use the show ap mesh topology command to verify the cluster topology, RSSI in presence of network traffic, and Tx and Rx rates.
ArubaOS 6.5.3.x
| User Guide Secure Enterprise Mesh | 634
(host) #show ap mesh topology
Mesh Cluster Name: sw-ad-GB32
-----------------------------
Name Mesh Role Parent Path Cost Node Cost Link Cost Hop Count RSSI Rate Tx/Rx
---- ---------------------------------------------------------Last
Update Uplink Age #Children
---------------------------
2 0 0 1 61 300/270 6m:12s ad-ap Point (N) mp3
3h:8m:7s 0 msc-1 Point
2h:48m:12s 0 mp3 2 0 0 1 64 54/54 6m:36s
Total APs :2
(R): Recovery AP. (N): 11N Enabled. For Portals 'Uplink Age' equals uptime.
Issue the command show ap mesh neighbors ap-name <name> to verify visibility of other mesh nodes is as expected:(host) #show ap mesh neighbors ap-name portal
Neighbor list
-------------
MAC
Rate Tx/Rx
Portal Channel Age Hops Cost Relation Flags RSSI
---
--------
------------
00:0b:86:e8:09:d1 00:1a:1e:88:01:f0 157
54/54
---
0
----
1
----
11.00
--------
C 3h:15m:42s
-----
-
----
65
--
0 1 4.00
C 3h:35m:30s HL 59 00:1a:1e:88:02:91 00:1a:1e:88:01:f0 157
300/300
00:0b:86:9b:27:78 Yes 157 0 0 12.00
N 3h:22m:46s 26 -
00:0b:86:e8:09:d0 00:1a:1e:88:01:f0 157
00:1a:1e:88:02:90 00:1a:1e:88:01:f0 157+
0
0
1
1
11.00
2.00
N 3h:15m:36s
N 3h:35m:6s
-
HL
65
59
-
-
0
0
1
0
A-Req A-Resp A-Fail HT-Details
------------------------
1 1 0 Unsupported
1
0
0
0
0
0
0
0
HT-40MHzsgi-2ss
Unsupported
Unsupported
Cluster ID
---------sw-ad-GB32 sw-ad-GB322 mc1 sw-ad-GB32
HT-40MHzsgi-2ss sw-ad-GB32
Total count: 5, Children: 2
Configuring Remote Mesh Portals (RMPs)
The following steps describe the procedure to configure a Remote Mesh portal using the WebUI and CLI interfaces.
Creating a Remote Mesh Portal In the WebUI
A remote mesh portal must be provisioned as both a remote access point and a mesh portal. For instructions on provisioning the remote mesh portal as a remote access point, see
Configuring the Secure Remote Access
635 | Secure Enterprise Mesh ArubaOS 6.5.3.x | User Guide
Wired ports on remote mesh portals can be configured in either bridge or split-tunnel forwarding mode.
However, there are limitations to the forwarding modes that can be used by other mesh node types. Do not use bridge or split-tunnel forwarding mode for wired ports on mesh points. Virtual APs on remote mesh portals and remote mesh points also do not support bridge or split-tunnel forwarding mode.
A remote mesh portal does not support bridge mode Virtual APs or offline Virtual APs.
Step 1: Provision the AP
1. Navigate to the Configuration > Wireless > AP Installation > Provisioning window.
2. Select the AP to provision as a remote mesh portal and click Provision . The Provisioning window appears.
3. In the Authentication section, select the Remote AP radio button.
4. In the Remote AP Authentication Method section of this window, select either Pre-shared Key or
Certificate . If you selected Pre-Shared Key , enter and confirm the Internet Key Exchange Pre-Shared Key
(IKE PSK).
5. In the Master Discovery section, set the Master IP address as the controller IP address.
6. In the IP settings section, select Obtain IP Address Using DHCP .
7. In the AP List section at the bottom of the window, click the Mesh Role drop-down list and select Remote
Mesh Portal .
Step 2: Define the Mesh Private VLAN in the Mesh Radio Profile
Follow the procedure below to choose a new, non-zero tag value for the mesh private VLAN. Make sure that the mesh private VLAN so that it does not conflict with any local tags assigned in the mesh network. Once configured, all mesh points come up in that Mesh Private Vlan. This mesh private VLAN must not be used as a
VLAN for any other virtual AP.
1. Edit the Mesh Radio profile for the remote mesh portal according to the procedure described in
Editing a Mesh Radio Profile on page 618
.
2. Set the Mesh Private VLAN parameter to define a VLAN ID (0 – 4094) for control traffic between an remote mesh point and mesh nodes.
3. Click Apply to save your changes.
Next, assign the remote mesh points with the same mesh cluster profile, 802.11a and 802.11g RF management profiles, and mesh radio profile as the remote mesh portal. If you have defined an AP group for all your remote mesh points, you can just assign the required profiles to the remote mesh point AP group.
Otherwise, you must assign the required profiles to each individual remote AP.
Step 3: Assign the Mesh Radio Profile to a Remote Mesh AP
Follow the procedures described in
Assigning a Mesh Radio Profile to a Mesh AP or AP Group on page 621
Step 4: Assign an RF Management Profile to a Remote Mesh AP
Follow the procedures described in
Assigning an 802.11a/802.11g Profile to an AP or AP Group on page 570
to assign an 802.11a or 802.1g RF management profile to the remote mesh AP.
Step 5: Assign a Mesh Cluster Profile
Follow the procedures described in
Configuring Mesh Cluster Profiles on page 614
to assign a mesh cluster profile to the remote mesh AP.
ArubaOS 6.5.3.x
| User Guide Secure Enterprise Mesh | 636
If you configure multiple cluster profiles with different cluster priorities, you manually override the link metric algorithm because the priority takes precedence over the path cost. In this scenario, the mesh portal uses the profile with the highest priority to bring-up the mesh network.
Step 6: Configuring a DHCP Pool
In this next step, you must configure a DHCP pool where the DHCP server is on the subnet associated with mesh private VLAN. Mesh points get their IP address from this subnet pool. To complete this task, refer to the procedure described in
Enabling Remote AP Advanced Configuration Options .
Step 7: Configuring the VLAN ID of the Virtual AP Profile
Follow the procedure described in
to configure the VLAN ID of the remote mesh AP's
SSID profile. The VLAN of this Virtual AP must have the same VLAN ID as the mesh private VLAN.
Provisioning a Remote Mesh Portal In the CLI
Reprovisioning the AP causes it to automatically reboot. When you use the CLI to reprovision a mesh node, you may also provision other AP settings.
(host)(config) #provision-ap read-bootinfo ap-name <name> mesh-role remote-mesh-portal reprovision ap-name <name>
637 | Secure Enterprise Mesh ArubaOS 6.5.3.x | User Guide
Chapter 24
Increasing Network Uptime Through Redundancy and VRRP
A single controller at the core of a network can represent a single point of failure. ArubaOS high availability and
Virtual Router Redundancy Protocol (VRRP) redundancy features allow network administrators to significantly reduce network downtime and client traffic disruption during network upgrades or unexpected failures.
High Availability
When you enable the High Availability WLAN redundancy solution, campus APs that lose contact with their active controller do not need to re-bootstrap when they failover to the standby controller, significantly reducing AP downtime. APs using the High Availability features regularly communicate with the standby controller so the controller has a light workload to process in the event of an AP failover. This results in very rapid failover times and a shorter client reconnect period. Therefore, High Availability is usually preferable to other redundancy solutions (like a backup-LMS) that can put a heavy load on the backup controller during failover, which results in slower failover performance.
High Availability supports failover for campus APs using tunnel, decrypt-tunnel, or bridge forwarding modes. It does not support failover for remote APs.
AP Fast Failover on bridge forwarding mode virtual AP is supported only on the 7200 Series controllers.
For more information on HA Alerting, See
High Availability Alerting on page 645
Pre-Deployment Information
For information to help you plan your high availability solution, refer to the following sections of this document: n n n n
High Availability Deployment Models on page 639
High Availability Extended Controller Capacity on page 642
Client State Synchronization on page 641
High Availability Inter-Controller Heartbeats on page 642
Configuration Procedures
For more information on configuring the high availability feature, refer to the following sections of this document: n n
Configuring High Availability on page 643
Migrating from VRRP or Backup-LMS Redundancy on page 646
VRRP-Based Redundancy
The Virtual Router Redundancy Protocol (VRRP) is used to create various redundancy solutions, including pairs of local controllers acting in an active-active mode or a hot-standby mode, or a master controller backing up a set of local controllers. The master controller owns the configured virtual IP address for the VRRP instance.
ArubaOS 6.5.3.x
| User Guide Increasing Network Uptime Through Redundancy and VRRP | 638
When the master controller becomes unavailable, a backup controller steps in as the master and takes ownership of the virtual IP address. All network elements (APs and other controllers) can be configured to access the virtual IP address, thereby providing a transparent redundant solution to your network.
VRRP eliminates a single point of failure by providing a mechanism to elect a VRRP "master" controller. If VRRP preemption is disabled (the default setting) and all controllers share the same priority, the first controller that comes up becomes the master. However, if VRRP preemption is enabled and all controllers share the same priority, the controller with the highest IP address becomes the master.
For more information on configuring the VRRP-Based Redundancy, refer to
Configuring VRRP Redundancy on page 648
.
n n n n
High Availability Deployment Models
High availability supports the following deployment modes:
Active/Active Deployment Model on page 639
1:1 Active/Standby Deployment Model on page 639
N:1 Active/Standby Deployment Model
Master-Redundancy Deployment Model
The High Availability Fast Failover feature supports APs in campus mode using tunnel, decrypt-tunnel, or bridge forwarding modes. This feature is not supported on remote APs or mesh APs in any mode.
Active/Active Deployment Model
In this model, two controllers are deployed in dual mode. Controller 1 acts as a standby for the APs served by controller 2, and vice-versa. Each controller in this deployment model supports approximately 50% of its total
AP capacity; if one controller fails, all the APs served by that controller failover to the other controller, providing high availability redundancy to all APs in the cluster.
Figure 81 Active-Active HA Deployment
1:1 Active/Standby Deployment Model
In this model, the active controller supports up to 100% of its rated capacity of APs, while the other controller is idle in standby mode. If the active controller fails, all APs served by the active controller failover to the standby controller.
639 | Increasing Network Uptime Through Redundancy and VRRP ArubaOS 6.5.3.x | User Guide
Figure 82 1:1 Active/Standby Deployment
N:1 Active/Standby Deployment Model
In this model, the active controller supports up to 100% of its rated AP capacity, while the other controller is idle in standby mode. If an active controller fails, all APs served by the active controller failover to the standby controller. This model requires that the AP capacity of the standby controller is able to support the total number of APs distributed across all active controllers in the cluster.
In the cluster shown in the example below, the standby controller has enough AP capacity to support the total number of APs terminating at the active controllers ( Controller 1 and Controller 2).
Figure 83 1:1 Active/Standby Deployment
Master-Redundancy Deployment Model
ArubaOS supports VRRP-based LMS redundancy in a deployment with master-master redundancy. In the topology below, when an AP connects to the master controller (M1), the AP receives a standby IP, which it uses to establish a standby connection to the backup master (M2). If the active master becomes unreachable or reboots, the backup master changes its VRRP role to master and accepts active AP connections.
When M1 comes back up, it initially acts as a backup master, and APs associated to M2 establish a standby connection to M1. When the controllers change roles and M1 becomes the active master once again, M2 forces the APs to use M1 as their active master. If an AP has not established a connection to M1 before it disassociates from M2, the AP rebootstraps before it reconnects back to M1.
ArubaOS 6.5.3.x
| User Guide Increasing Network Uptime Through Redundancy and VRRP | 640
Figure 84 Redundancy with a Active-Backup Master Controller Pair
When a VRRP instance is configured on the controller vlan, there is no change in the VRRP state if the failover scenario was tested by shutting down the port or bringing down the vlan. The controller remains in the Master state and sends VRRP advertisements, which do not reach the peer controller. When the port is down, the peer controller becomes the Master. However, when the port on the previous master is enabled, it takes over the Master state. The peer controller moves out of the master state when the original master sends a higher priority advertisement, even when preemption is not enabled. The peer controller will not be preempted if the master controller crashes or reboots.
AP Communication with Controllers
The High Availability features work across Layer-3 networks, so there is no need for a direct Layer-2 connection between controllers in a high availability group.
When the AP first connects to its active controller, the active controller provides the IP address of a standby controller, and the AP attempts to establish a tunnel to the standby controller. If an AP fails to connect to the first standby controller, the active controller selects a new standby controller for that AP, and the AP attempts to connect to that standby controller.
An AP will failover to its backup controller if it fails to contact its active controller through regular heartbeats and keepalive messages, or if the user triggers a failover manually using the WebUI or CLI.
High Availability for bridge mode is supported on Campus APs. In this mode, the controller sends ACL Names to the APs instead of the ACL IDs. These APs generate and maintain the mapping between the ACL Name and
ACL Id. In the event of a failover the ACL Name is sent to the AP from the stand-by controller. Since AP maintains the mapping, the ACL Ids remain intact during a failover.
Client State Synchronization
Client state synchronization allows faster client reauthentication in the event of a controller failure by synchronizing PMK and Key cache entries between active and standby controllers. When this feature is enabled, clients only need to perform a four-way key exchange to reconnect to the network (instead of performing a full authentication to the RADIUS server), dramatically shortening the time required for the client to reconnect.
The following section of this document describes topologies, guidelines, and limitations for this feature. To view the procedure for enabling the client state synchronization feature, see
Configuring High Availability .
641 | Increasing Network Uptime Through Redundancy and VRRP ArubaOS 6.5.3.x | User Guide
Feature Guidelines and Limitations
Note the following guidelines and limitations before enabling this feature in your high availability deployment: n n
Only APs that support 802.11n and 802.11ac can support client state synchronization.
The client state synchronization and standby controller over-subscription features are mutually incompatible and cannot be enabled simultaneously. If your deployment uses the standby controller oversubscription feature, the feature must be disabled before enabling state synchronization.
High Availability Inter-Controller Heartbeats
The high availability inter-controller heartbeat feature allows for faster AP failover from an active controller to a standby controller, especially in situations where the active controller reboots or loses connectivity to the network.
The inter-controller heartbeat feature works independently from the AP mechanism that sends heartbeats from the AP to the controller. If enabled, the inter-controller heartbeat feature supersedes the AP's heartbeat to its controller. As a result, if a standby controller detects missed inter-controller heartbeats from the active controller, it triggers its standby APs to failover to the standby controller, even if those APs have not detected any missed heartbeats between the APs and their active controller . Use this feature with caution in deployments where the active and standby controllers are separated over high-latency WAN links.
When this feature is enabled, the standby controller starts sending regular heartbeats to an AP's active controller as soon as the AP has an UP status on the standby controller. The standby controller initially flags the active controller as unreachable , but changes its status to reachable as soon as the active controller sends a heartbeat response. If the active controller later becomes unreachable for the number of heartbeats defined by the heartbeat threshold (default of 5 missed heartbeats), the standby controller immediately detects this error and informs the APs using the standby controller to failover from the active controller to the standby controller. If, however, the standby controller never receives an initial heartbeat response from the active controller, and therefore never marks the active controller as initially reachable, the standby controller will not initiate a failover.
This feature is disabled by default. It can be used in conjunction with the high availability state synchronization feature only in topologies that use a single active and standby controller, or a pair of dual-mode active controllers that act as standby controllers for each other. High availability inter-controller heartbeats can be enabled and configured in the high-availability group profile using the WebUI or Command-Line interface.
For more details on how to enable and configure inter-controller heartbeats, see
Configuring High Availability on page 643 .
High Availability Extended Controller Capacity
The standby controller over-subscription feature allows a standby controller to support connections to standby APs beyond the controller's original rated AP capacity. This feature is an enhancement to the high availability feature introduced in ArubaOS 6.3.0.0, which requires the standby controller to have an AP capacity equal to or greater than the total AP capacity of all the active controllers it supports.
The following section of this document gives and lists requirements and capacity limitations for this feature.
For more details on enabling the extended standby controller capacity, see
Configuring High Availability on page 643
.
Starting with ArubaOS 6.4.0.0, 7000 Series and 7200 Series controllers that acts as a standby controller can oversubscribe to standby APs by up to four times that controller's rated AP capacity, as long as the tunnels consumed by the standby APs do not exceed the maximum tunnel capacity for that standby controller.
ArubaOS 6.5.3.x
| User Guide Increasing Network Uptime Through Redundancy and VRRP | 642
Feature Requirements
This feature can be enabled on controllers in a master-local topology where centralized licensing is enabled on the active and standby controllers, or on independent master controllers that are not using VRRP-based redundancy. If centralized licensing is disabled, the standby AP over-subscription feature is also disabled.
Standby controller over-subscription and the high availability state synchronization features are mutually incompatible and cannot be enabled simultaneously. If your deployment uses the state synchronization feature, you must disable it before you enable standby controller over-subscription.
Standby Controller Capacity
The following table describes the AP over-subscription capacity maximum supported tunnels and the controllers that support this feature.
To determine the number of standby tunnels consumed by APs on each active controller, multiply the number of APs on the active controllers by the number of BSSIDs per AP. For example, consider a deployment with four active 7210 controllers that each have 512 APs with 8 BSSIDs. The APs on each active controller consume
(512 * 8) tunnels, for a combined total of 16,384 tunnels. A single 7210 controller using the standby controller over-subscription feature can act as the standby controller for all four active controllers in this example because this topology is within the 4x rated AP capacity limit and maximum tunnel limit for the 7210 controller model.
If the network administrator later changed all the APs in this deployment to support 10 BSSIDs, each active controller would use (512 * 10) tunnels, for a combined total of 20,480 tunnels on the four active controllers.
The tunnels required by the APs on the active controllers would then exceed the maximum tunnel limit for the standby controller, so the standby controller can no longer support all APs on the active controllers. Dynamic changes to configuration (such as the addition of BSSIDs to any AP group) causes all the standby APs to disconnect and reconnect back to the standby controller defined by their updated configuration
To view information about the numbers of currently associated APs and supported BSS tunnels, and the remaining capacity for additional APs and BSS tunnels, issue the CLI command show ha oversubscription statistics.
AP Failover
If a standby controller reaches its AP over-subscription capacity or exceeds its maximum BSSID limit, the standby controller drops any subsequent standby AP connections. A dropped AP attempts to reconnect to the standby controller, but after it exceeds the maximum number of request retries, the AP informs the active controller that it is unable to connect to the standby controller. The active controller then prompts the AP to create a standby tunnel to another standby controller, if one is configured.
If an active controller fails, the APs on the active controller failover to the standby controller. Once the standby controller has reached its capacity for active APs, it terminates tunnels to any standby APs that the controller can no longer serve. When these APs detect that there is no longer a heartbeat between the AP and the standby controller, they notify their active controller that they can no longer connect to the standby. The active controller then prompts the APs to establish standby tunnels to another standby controller, if one is configured.
Configuring High Availability
A controller using this feature can have one of three high availability roles: active , standby , or dual . An active controller serves APs, but cannot act as a failover standby controller for any AP except those that it serves as an active controller. A standby controller acts as a failover backup controller, but cannot be configured as the primary controller for any AP. A dual controller can support both roles, acting as the active controller for one set of APs, and a standby controller for another set of APs.
643 | Increasing Network Uptime Through Redundancy and VRRP ArubaOS 6.5.3.x | User Guide
Starting with ArubaOS 6.4, a controller is assigned the dual role if no other role is specified
The high availability feature supports redundancy models with an active controller pair, or an active/standby deployment model with one backup controller supporting one or more active controllers. Each of these clusters of active and backup controllers comprises a high-availability group. All active and standby controllers within a single high-availability group must be deployed in master-local or independent masters topologies. An independent masters topology requires all independent master controllers to have the same WLAN configuration.
Pre-Deployment Information
Refer to the following sections of this document for deployment models and feature details to help you plan your high availability solution: n n n n
High Availability Deployment Models on page 639
High Availability Extended Controller Capacity on page 642
Client State Synchronization on page 641
High Availability Inter-Controller Heartbeats on page 642
Configuring High Availability
Configure the high availability feature in the WebUI or CLI using the high-availability and high-availability group profiles.
In the WebUI
To configure High Availability using the WebUI:
1. Navigate to Configuration > Advanced Services > Redundancy .
2. In the HA Group Configuration section, click Add New . A pop-up window appears.
3. In the Name field, enter a name for the HA group you just created.
4. In the controller IP address field, enter the IP address of a controller in the HA group.
5. Click the IP Version drop-down list and select either IPv4 or IPv6 to identify the IP address version type used by the controller.
6. Click the Role drop-down list to assign a role to the controller. The IP address of each controller must be reachable by APs and must be the IP address that appears in the Configuration > Controller > System settings tab of the controller WebUI, or in the output of the show controller-ip CLI command.
n n
Active : Controller is active and serving APs.
Dual : Controller serves some APs and acts as a standby controller for other APs.
n
Standby : Controller does not serve APs and only acts as a standby in case of failover.
7. Click Add to add the controller to the group.
8. (Optional) The high availability inter-controller heartbeat feature allows for faster AP failover from an active controller to a standby controller, especially in situations where the active controller reboots or loses connectivity to the network. To edit the default heartbeat threshold and interval values: a. Enter a heartbeat threshold in the Heartbeat Threshold field to define the number of heartbeats that must be missed before the APs are forced to failover to the standby controller. This value must be between 3 and 10, inclusive.
b. Enter a heartbeat interval in the Heartbeat Interval field to define how often inter-controller heartbeats are sent. This value must be between 100 and 1000 ms, inclusive.
ArubaOS 6.5.3.x
| User Guide Increasing Network Uptime Through Redundancy and VRRP | 644
9. (Optional) State synchronization improves failover performance by synchronizing client authentication state information from the active controller to the standby controller. To use the state synchronization feature, enter a pre-shared key into the Pre-shared key field. Note, however, that this feature is not enabled until you complete the task in
10.Click
OK . The popup window closes, and the name of the new HA group appears in the HA Group
Configuration field on the Configuration > Advanced Services > Redundancy page.
11.(Optional) Select the Preemption checkbox to require APs that has failed over to a standby to attempt to connect back to its original active controller once the controller is reachable again. When you enable this setting, the AP will wait for the time specified by the lms-hold-down-period parameter in the ap system profile before the AP attempts to switch back from the standby controller to the original controller.
12.(Optional) The standby controller over-subscription feature allows a standby controller to support connections to standby APs beyond the controller's original rated AP capacity. To enable this feature, click the Oversubscription checkbox.
13.(Optional) if you defined a pre-shared key in
, select the State Synchronization checkbox to enable this feature. (For more information about State Synchronization, see
14.(Optional) The inter-controller heartbeat feature allows for faster AP failover from an active controller to a standby controller by enabling regular heartbeats between a standby controller and an active controller
15.Click
Apply .
In the CLI
To configure a High Availability group using the command-line interface, access the CLI in config mode and issue the following commands. The high availability group profile should be configured with a pair of IPv4 controller addresses and pair of IPv6 controller addresses to allow an IPv4 or IPv6 access point to establish a connection to a standby controller.
ha group-profile <profile> clone <profile-name> controller <ipv4-ip-addr> role active|dual|standby controller-v6 <ipv6-ip-addr> role active|dual|standby heartbeat heartbeat-interval <heartbeat-interval> heartbeat-threshold <heartbeat-threshold> no ...
over-subscription pre-shared-key <key> preemption state-sync
A controller using the high availability features must be defined as a member of a high availability group. To add a controller to the new high availability group, issue following CLI command:
(host)(config)#ha group-membership <ha-group>
High Availability Alerting
Starting from ArubaOS 6.5.1.0, new Management Information Bases (MIBs) are introduced to enable the controller provide the high availability status information to customers. MIBs are divided among different
SNMP tables. With this High Availability Alerting feature enabled, customers can get the required information for network monitoring. It is explained in the
section.
This feature ensures that a customer gets the required notification for monitoring the network in the following representational situations: n
When the standby tunnel goes down
645 | Increasing Network Uptime Through Redundancy and VRRP ArubaOS 6.5.3.x | User Guide
n
When HA failover occurs due to AP-intercontroller heartbeat miss
MIBs/SNMP Tables
The following are the new MIBs introduced in ArubaOS 6.5.1.0 for High Availability Alerting: n
High Avalability Config Table: wlsxHighAvalabilityConfigTable —provides HA enabled/disabled status, HA group membership, and parameters configured in HA group profile.
n n
HA AP Table: wlsxHighAvalabilityApTable —provides Active APs count, Standby APs count, and Total APs count.
Intercontroller Heartbeat Table: wlsxIntercontrollerHbtTable —provides Active controller IPs, Reference count, and heartbeat statistics for each active controller.
n n
HA State Sync Table: wlsxStateSyncTable —provides active/replicated/total PMK cache entries and key cache entries count.
HA Tunnel Table: wlsxHighAvalabilityTunnelTable —provides active/standby/total BSS tunnel count and total heartbeat tunnel count.
All the MIBs for the HA Alerting feature are implemented in wlsxHaMIB .
For more information on the MIBs and OIDs, refer to the aruba-ha.my
MIB file, which is available within the aruba-mibs_6.5.1.0_56684.tar.gz
file in the Download Software tab of support.arubanetworks.com
.
SNMP Traps
The new SNMP traps introduced for High Availability Alerting in ArubaOS 6.5.1.0 are as follows: n
HA State Trap: wlsxHaState —indicates that HA state has changed.
n n n n n
Standby IP Sent Failed Trap: wlsxHaStandbyIpSentFailed —indicates that standby IP sent to an AP failed.
HA Standby Connectivity State Trap: wlsxHaStandbyConnectivityState —indicates the standby connectivity status for an AP.
HA Intercontroller Hbt Miss Trap: wlsxHaIntercontrollerHbtMiss —indicates that around half of the threshold intercontroller heartbeat was missed with serving controller.
HA Failover Trigger Trap: wlsxHaFailoverTrigger —indicates that a standby controller has triggered HA failover to APs belonging to a particular serving controller with which intercontroller heartbeat was missed above threshold.
HA Failover Request from AP Trap: wlsxHaFailoverRequestFromAp —indicates that an AP sent failover request to the controller. This could be because of an AP missing heartbeat with the serving controller, on receiving failover request from standby controller, or AP trying to preempt back to active controller.
For more information on the SNMP traps, refer to
https://support.arubanetworks.com
.
Migrating from VRRP or Backup-LMS Redundancy
ArubaOS has a local management switch (LMS) and a backup LMS. In a typical deployment, the AP contacts the master controller and is directed to the controller that handles the AP connection and traffic via the LMS parameter. If the LMS becomes unreachable and a backup LMS is specified, the AP attempts to reconnect to that backup controller. This function provides Layer 3 and site redundancy when this level of redundancy is required.
High Availability: Fast Failover provides redundancy for APs, but not for controllers. Deployments that require master controller redundancy should continue to use an existing VRRP redundancy solution.
ArubaOS 6.5.3.x
| User Guide Increasing Network Uptime Through Redundancy and VRRP | 646
If your deployment currently uses a backup-LMS or VRRP redundancy solution, use the following procedures to migrate to a high availability-based solution. For more information on this topology, see
Redundancy Deployment Model on page 640
.
Configuring a Master Controller for Redundancy and High Availability
Starting with ArubaOS 6.4, a backup master controller can use the high availability feature. However, a backup master controller can only accept standby connections from APs, and will not serve active APs as long as its master redundancy role is backup .
Important Points to Remember
This type of high availability deployment has the following requirements and limitations: n n n n n n
A backup master controller can only form an active-standby pair with the master controller.
The backup master cannot terminate active APs.
Both the backup master and master controllers must be configured with the dual controller role.
The controller IP address defined in the high availability group profile must be the IP address of the VRRP interface.
The inter-controller heartbeat feature is not recommended for backup-master and master controller pairs using the high availability feature .
If the inter-controller heartbeat feature is enabled in a high availability group profile for redundant masters, the inter-controller failover time must be greater than the VRRP failover time. That is, the (heartbeat interval * heartbeat threshold) value should be greater than the (advertisement time * 3 + preemption delay + skew time [which is based on priority]).
In an HA setup, it is recommended not to change the LMS IP in the AP system profile to the IP address of the standby controller when the APs are active on the standby controller.
Perform the following steps to configure controller high availability on a backup-master and master controller pair.
1. Configure the high availability group profile with a dual role for the master controller:
(host)(config) #ha group-profile grp1
(host)(HA group information "grp1"): controller <VRRP interface ipaddress> role dual
2. Configure the high availability group profile with a dual role for the backup-master controller:
(host) (HA group information "grp1"): controller <VRRP interface ipaddress> role dual
Migrating from VRRP Redundancy
Perform the following steps to migrate from VRRP to high availability redundancy:
1. Remove the VRRP IP address as the LMS IP address of the AP:
(host) (AP system profile) #no lms-ip
2. Configure the AP to use the active controller’s IP address (not VRRP the IP address) as the LMS-IP for the AP:
(host) (AP system profile) #lms-ip <ipaddress>
3. Configure the AP to use the standby controller IP address (not VRRP the IP address) as the backup LMS-IP for the AP:
(host) (AP system profile) #bkup-lms-ip <ipaddress>
4. Configure the master controller with a dual role in the high availability group profile:
(host) (config) #ha group-profile grp1
(host) (HA group information "grp1"): controller <ipaddress> role dual
5. Configure the standby controller with a dual role in the high availability group profile:
(host) (HA group information "grp1"): controller <ipaddress> role dual
647 | Increasing Network Uptime Through Redundancy and VRRP ArubaOS 6.5.3.x | User Guide
Migrating from Backup-LMS Redundancy
Perform the following steps to migrate from backup-LMS to high availability redundancy, while maintaining the existing configuration as defined by the lms-ip and bkup-lms-ip parameters in the AP system profile.
1. Configure the controller serving the AP with a dual role in the high availability group profile:
(host) (config) #ha group-profile grp1
(host) (HA group information "grp1"): controller <ipaddress> role dual
2. Configure the AP’s standby controller with a dual role in the high availability group profile:
(host) (HA group information "grp1"): controller <ipaddress> role dual
When an LMS and backup LMS are migrated to the high availability redundancy solution with the dual controller role: n n n n
Each controller has its own standby (backup) controller. See
High Availability Deployment Models
for more details on each deployment scenario.
Newly deployed APs can connect directly to each controller in active mode.
APs can failover to a backup controller in standby mode when their primary controller becomes unavailable.
The backup controller then becomes the active controller for these APs.
LMS preemption is disabled. Under LMS preemption, APs automatically reconnect to the LMS as soon as it comes back up. Under the high availability solution, APs remain connected to an active backup controller until it becomes unavailable. When the backup controller fails, the APs failover to the backup's standby controller, which can be the AP's primary controller or another controller.
If the AP's primary controller is not configured as the backup's standby controller, the APs rebootstrap to their primary controller when both the backup controller and backup's standby controller fail.
Configuring VRRP Redundancy
In an Aruba network, APs are controlled by a controller. The APs tunnel all data to the controller for processing, including encryption/decryption and bridging/forwarding data. Local controller redundancy provides APs with failover to a backup controller if a controller becomes unavailable. Local controller redundancy is provided by running VRRP between a pair of controllers. The APs are then configured to connect to the “virtual-IP” configured for the VRRP instance.
The two controllers must be connected on the same broadcast domain (or Layer-2 connected) for VRRP operation.
The two controllers should be running the same version of ArubaOS.
The following section of this document includes the following procedures: n n n n n n n
Configuring the Local Controller for Redundancy on page 649
Configuring the LMS IP on page 651
Configuring the Master Controller for Redundancy on page 651
Configuring Database Synchronization on page 653
Enabling Incremental Configuration Synchronization (CLI Only) on page 653
Configuring Master-Local Controller Redundancy on page 654
Before you Begin
Before you begin configuring VRRP redundancy, obtain the following network information: n
VLAN ID for the two local controllers on the same Layer-2 network.
ArubaOS 6.5.3.x
| User Guide Increasing Network Uptime Through Redundancy and VRRP | 648
n
Virtual IP address to be used for the VRRP instance.
Before you configure VRRP, ensure that the VRRP VLAN has at least one active physical port. This port is required for the VRRP state to become master.
Configuring the Local Controller for Redundancy
You can use either the WebUI or CLI to configure VRRP on the local controllers. For this topology, it is recommended you use the default priority value.
In the WebUI
1. Navigate to the Configuration > Advanced Services > Redundancy page for each of the local controllers.
2. Under Virtual Router Table , click Add to create a new VRRP instance.
3. Select the IP version.
4. Enter the IPv4\IPv6 Address for the virtual router. Select the VLAN on which VRRP will run. Set the Admin
State to Up .
5. Configure other VRRP parameters as described in the table below.
6. Click Done , then save your configuration.
Table 140: VRRP Parameters
Parameter Description
IP Version
Virtual Router ID
Advertisement Interval
(secs)
Authentication Password
Description
IP \ IPv6 Address
Enable Router Preemption
Select IPv4 \ IPv6 from the drop-down list box.
The ID uniquely identifies this VRRP instance. For ease in administration, you should configure this with the same value as the VLAN ID.
This is the interval, in seconds, between successive VRRP advertisements sent by the current master . The default interval time is recommended.
Default: 1 second
This is an optional password of up to eight characters that can authenticate
VRRP peers in their advertisements. If this is not configured, there is no authentication password.
This is an optional text description to describe the VRRP instance.
Based on the selection made in the IP version field, either IP Address \ IPv6
Address is displayed. This is the virtual IP address that will be owned by the elected VRRP master. Ensure that the same IP address and VRRP ID is used on each member of the redundant pair.
Note: The IP address must be unique and cannot be the loopback address of the controller. A maximum of only two virtual IPv6 addresses can be configured on each VRRP instance. Only IPv6 address format is supported for the v6 instance.
Selecting this option means that a controller can take over the role of master if it detects a lower priority controller currently acting as master.
649 | Increasing Network Uptime Through Redundancy and VRRP ArubaOS 6.5.3.x | User Guide
Table 140: VRRP Parameters
Parameter Description
Delay
Priority
Admin State
VLAN
Tracking
Specifying a value enables the delay timer. The timer is triggered when the
VRRP state moves out of backup or init state to become a master. This is applicable only if you enable router pre-emption.
When the timer is triggered, it forces VRRP to wait for a specified period of time, so that all the applications are ready before coming up. This prevents the APs from connecting to the controller before it can receive them. In the meantime, if there is an advertisement from another VRRP, the VRRP stops the timer and does not transition to master.
Priority level of the VRRP instance for the controller. This value is used in the election mechanism for the master.
Administrative state of the VRRP instance. To start the VRRP instance, change the admin state to UP in the WebUI.
VLAN on which the VRRP protocol runs.
Configures a tracking mechanism that modifies a specified value to the priority after a controller has been the master for the VRRP instance. This mechanism is used to avoid failing over to a backup master for transient failures.
Tracking can be based on one of the following: n
Master Up Time: how long the controller has been the master. The duration is the length of time that the administrator expects will be long enough that the database gathered in the time is too important to be lost. This will vary from instance to instance.
n VRRP Master State Priority: the master state of another VRRP.
Tracking can also be based on the interface states of the controller: n
VLAN and Interface: prevents asymmetric routing by tracking multiple VRRP instances. The priority of the VRRP interface determined by the sub value can increase or decrease based on the operational and transitional states of the specified VLAN or Fast Ethernet/Gigabit Ethernet port. When the VLAN or interface comes up again, the value is restored to the previous priority level.
You can track a combined maximum of 16 interfaces and VLANs.
NOTE: The tracked VLAN is different from the VRRP VLAN.
For example, you can track an interface that connects to a default gateway. In this situation, configure the VRRP priority to decrease and trigger a VRRP master re-election if the interface goes down. This not only prevents network traffic from being forwarded, but reduces VRRP processing.
In the CLI
(host)(config)#vrrp <id> advertise <interval> authentication <password> description <text> ip address <ipaddr> no...
preempt priority <level> shutdown tracking interface {fastethernet <slot>/<module>/<port>|gigabitethernet
<slot>/<module>/<port>}
{sub <value>} tracking master-up-time <duration> add <value> tracking vlan <vlanid> {sub <value>} tracking vrrp-master-state <vrid> add <value> vlan <vlanid>
(host) (config)#vrrp ipv6 <id>
ArubaOS 6.5.3.x
| User Guide Increasing Network Uptime Through Redundancy and VRRP | 650
advertise <interval> description <text> ipv6 address <ipaddr> no...
preempt priority <level> shutdown tracking interface {fastethernet <slot>/<module>/<port>|gigabitethernet
<slot>/<module>/<port>}
{sub <value>} tracking master-up-time <duration> add <value> tracking vlan <vlanid> {sub <value>} tracking vrrp-master-state <vrid> add <value> vlan <vlanid>
Configuring the LMS IP
Configure the APs to terminate their tunnels on the virtual-IP address. To specify the controller to which an AP or AP group tunnels client traffic, you configure the LMS IP in the AP system profile on the master controller.
For information on how to configure the LMS IP in the AP system profile, see
This configuration must be executed on the master controller; the APs obtain their configuration from the master controller.
In the WebUI
1. Navigate to the Configuration > Wireless > AP Configuration page for the master controller.
n
If you select AP Group , select the AP group for which you want to configure the LMS IP.
n
If you select AP Specific , select the name of the AP for which you want to configure the LMS IP.
2. Under the Profiles section, select AP to display the AP profiles.
3. Select the AP system profile you want to modify.
4. In the Profile Details section, enter the controller IP address into the LMS IP field.
5. Click Apply , then save your configuration.
In the CLI
On the master controller:
(host)(config) #ap system-profile < profile> lms-ip < ipaddr>
(host)(config) #ap-group < group> ap-system-profile <profile>
(host)(config) #ap-name < name> ap-system-profile < profile>
Configuring the Master Controller for Redundancy
The master controller in the Aruba user-centric network acts as a single point of configuration for global policies such as firewall policies, authentication parameters, and RF configuration to ease the configuration and maintenance of a wireless network. It also maintains a database related to the wireless network that you can use to make adjustments (automated or manual) in reaction to events that cause a change in the environment
(such as an AP becoming unavailable).
The master controller is also responsible for providing the configuration for any AP to complete its boot process. If the master controller becomes unavailable, the network continues to run without any interruption.
651 | Increasing Network Uptime Through Redundancy and VRRP ArubaOS 6.5.3.x | User Guide
However, any change in the network topology or configuration will require the availability of the master controller.
To maintain a highly redundant network, the administrator can use a controller to act as a hot standby for the master controller. The underlying protocol used is the same as in local redundancy, that is, VRRP.
Collect the following data before configuring master controller redundancy: n n
VLAN ID for the two controllers on the same Layer-2 network.
Virtual IP address that has been reserved to be used for the VRRP instance.
You can use either the WebUI or CLI to configure VRRP on the master controllers (see
). For this topology, the following values are recommended: n n n
For priority: Set the master to 110; set the backup to 100 (the default value)
Enable preemption
Configure master up time or master state tracking with an add value of 20.
The following is a configuration example for the initially-preferred master.
(host)(config) #vrrp 22 vlan 22 ip address 10.200.22.254
priority 110 preempt authentication password description Preferred-Master tracking master-up-time 30 add 20 no shutdown
The following configuration is the corresponding VRRP configuration for the peer controller.
(host)(config) #vrrp 22 vlan 22 ip address 10.200.22.254
priority 100 preempt authentication password description Backup-Master tracking master-up-time 30 add 20 no shutdown
Use the following commands to associate the VRRP instance with master controller redundancy:
Table 141: VRRP Commands
Command Explanation master-redundancy master-vrrp <id>
Enters the master-redundancy context.
Associates a VRRP instance with master redundancy. Enter the virtual router ID of the VRRP instance.
peer-ip-address <ipaddr> ipsec <key> Loopback IP address of the peer controller for master redundancy.
The pre-shared key secures communication between the master controllers. Specify a key of up to 64 characters.
masterip <ipaddr> ipsec <key> Configures the master IP address and pre-shared key on a local controller for communication with the master controller.
Configure this to be the virtual IP address of the VRRP instance used for master redundancy.
ArubaOS 6.5.3.x
| User Guide Increasing Network Uptime Through Redundancy and VRRP | 652
Configure all the APs and local controllers in the network with the virtual IP address as the master IP address. You can configure the master IP address for local controllers during the Initial Setup. The controller will require a reboot after changing the master IP on the controller.
If DNS resolution is the chosen mechanism for the APs to discover their master controller, ensure that the name “aruba-master” resolves to the same virtual IP address configured as a part of the master redundancy.
Configuring Database Synchronization
In a redundant master controller scenario, you can configure a redundant pair to synchronize their WMS and local user databases. You can synchronize the databases manually or automatically.
When manually synchronizing the database, the active VRRP master synchronizes its database with the standby. The command takes effect immediately.
When configuring automatic synchronization, you set how often the two controllers synchronize their databases. To ensure successful synchronization of database events, you should set periodic synchronization to a minimum period of 20 minutes.
In the WebUI
1. On each controller, navigate to the Configuration > Advanced Services > Redundancy page.
2. Under Database Synchronization Parameters , do the following: a. Select the Enable periodic database synchronization check box. This enables database synchronization.
b. Enter the frequency of synchronizing the databases. A minimum value of 20 minutes is recommended.
3. Click Apply .
In the CLI
Use the following commands to configure database synchronization.
Table 142: Database synchronization commands
Command database synchronize database synchronize period <minutes>
Description
This enable mode command manually synchronizes the databases and takes effect immediately.
This config mode command defines the scheduled interval for synchronizing the databases.
To view the database synchronization settings on the controller, use the following command:
(host)#show database synchronize
Enabling Incremental Configuration Synchronization (CLI Only)
When the master and local are synchronized, the complete configuration is typically sent to the local. However, you now have the option to send only the incremental updates to the local using the following CLI commands:
653 | Increasing Network Uptime Through Redundancy and VRRP ArubaOS 6.5.3.x | User Guide
Table 143: Incremental Configuration Synchronization Commands
Command Description cfgm set sync-type <complete> cfgm set sync-type <snapshot> cfgm set sync-command-block <number> show master-configpending clear master-local-session <A.B.C.D>
The master sends the full configuration file to the local.
The master sends only the incremental configuration to the local.
NOTE: This configuration is enabled by default
Configures the number of command-list blocks.
Each block contains a list of global configuration commands for each write-mem operation. The number is 3 by default.
Displays a list of global commands that are not saved but sent to the local.
Manually pushes the full configuration to the local.
Configuring Master-Local Controller Redundancy
This section outlines the concepts behind a redundancy solution where a master can act as a backup for one or more local controllers, and shows how to configure the Aruba controllers for such a redundant solution. In this solution, the local controllers act as the controller for the APs. When any one of the local controllers becomes unavailable, the master takes over the APs controlled by that local controller for the time that the local controller remains unavailable. It is configured such that when the local controller comes back again, it can take control over the APs once more.
This type of redundant solution is illustrated by the following topology diagram:
This solution requires that the master controller have Layer-2 connectivity to all local controllers.
Figure 85 Redundant Topology: Master-Local Redundancy
In the network in
, the master controller is connected to the local controllers on VLANs 1 through n using a Layer-2 network. To configure redundancy as described in the conceptual overview for master-local
ArubaOS 6.5.3.x
| User Guide Increasing Network Uptime Through Redundancy and VRRP | 654
redundancy, configure VRRP instances on each of the VLANs between the master and the respective local controller. The VRRP instance on the local controller is configured with a higher priority to ensure that when available, the APs always choose the local controller to terminate their tunnels.
n n
Configure the interface on the master controller to be a trunk port with 1, 2… n being member VLANs.
Collect the following data before configuring master controller redundancy: n n
VLAN IDs on the controllers corresponding to the VLANs 1, 2… n shown in the topology above.
Virtual IP addresses that have been reserved to be used for the VRRP instances.
You can use either the WebUI or CLI to configure VRRP on the master controllers (see
). For this topology, the following values are recommended: n n
For priority: Set the local to 110; set the master to 100 (the default value)
Enable preemption
The master controller is configured for a number of VRRP instances (equal to the number of local controllers the master is backing up).
To configure the APs, configure the appropriate virtual IP address (depending on which controller is expected to control the APs) for the LMS IP address parameter in the AP system profile for an AP group or specified AP.
Configure these AP settings on the master controller, not the local controller.
As an example, the administrator configures APs in the AP group “floor1” to be controlled by local controller 1,
APs in the AP group “floor2” to be controlled by local controller 2, and so on. All the local controllers are backed up by the master controller. In the AP system profile for the AP group “floor1”, enter the virtual IP address
(10.200.22.154 in the example configuration) for the LMS IP address on the master controller.
Configuration changes take effect only after you reboot the affected APs, allowing them to reassociate with the local controller. After rebooting, these APs appear as local APs to the new local controller.
655 | Increasing Network Uptime Through Redundancy and VRRP ArubaOS 6.5.3.x | User Guide
Chapter 25
RSTP
The ArubaOS implementation of Rapid Spanning Tree Protocol (RSTP) is as specified in 802.1w, with backward compatibility to legacy Spanning Tree (STP) 802.1D. RSTP takes advantage of point-to-point links and provides rapid convergence of the spanning tree. RSTP is enabled by default on all Aruba controllers.
Topics in this chapter include: n n n n
Understanding RSTP Migration and Interoperability on page 656
Working with Rapid Convergence on page 656
Troubleshooting RSTP on page 659
Understanding RSTP Migration and Interoperability
The ArubaOS RSTP implementation interoperates with PVST (Per VLAN Spanning Tree 802.1D) and Rapid-PVST
(802.1w) implementation on industry-standard routers/switches. Aruba only supports global instances of STP and RSTP. Therefore, the ports on industry-standard routers/switches must be on the default or untagged
VLAN for interoperability with Aruba controllers.
ArubaOS supports RSTP on the following interfaces: n n n
FastEthernet IEEE 802.3: fastethernet
Gigabitethernet IEEE 802.3: gigabitethernet
Port Channel ID: port-channel n n
Working with Rapid Convergence
Since RSTP is backwards compatible with STP, it is possible to configure both bridges in the same network.
However, such mixed networks may not always provide rapid convergence. RSTP provides rapid convergence when interfaces are configured as either:
Edge ports: These are the interfaces/ports connected to hosts. These interfaces are immediately moved to the forwarding state. In this mode, an interface forwards frames by default until it receives a BPDU (Bridge
Protocol Data Units), indicating that it should behave otherwise. It does not go through the Listening and
Learning states.
Point-to-Point links: These are the interfaces/ports connected directly to neighboring bridges over a point-to-point link. RSTP negotiates with the neighbor bridge for rapid convergence/transition only when the link is point-to-point.
Table 144: Port State Comparison
STP (802.1d)
Port State
RSTP (802.1w)
Port State
Disabled
Blocking
Listening
Discarding
Discarding
Discarding
ArubaOS 6.5.3.x
| User Guide RSTP | 656
657 | RSTP
STP (802.1d)
Port State
Learning
Forwarding
RSTP (802.1w)
Port State
Learning
Forwarding
In addition to port state, RSTP introduces port roles for all the interfaces (see
).
Table 145: Port Role Descriptions
RSTP (802.1w)
Port Role
Description
Root
Designated
Alternate
Backup
The port that receives the best BPDU on a bridge.
The port can send the best BPDU on the segment to which it is connected.
The port offers an alternate path, in the direction of root bridge, to that provided by bridge’s root port.
The port acts as a backup for the path provided by a designated port in the direction of the spanning tree.
To view the RSTP output, including state and port roles, enter the following command in the CLI:
(host) (config) #show spantree
The show spanning-tree interface command also indicates the state and port roles. See the example below for a partial output:
(host) #show spanning-tree interface fastethernet 1/1
Interface FE 1/7 (port 8) in Spanning tree is FORWARDING
Port path cost 19, Port priority 128 Role DESIGNATED
Edge Port and Point-to-Point
At the interface level, the portfast command specifies an interface as an edge port, and the point-to-point command specifies an interface as a point-to-point link. Since RSTP is enabled by default, all the interfaces are point-to-point links by default.
Configuring RSTP
Use either the CLI or the WebUI to configure RSTP.
In the WebUI
The RSTP port interface is designated as point-to-point, by default, under Configuration > Network > Ports in the WebUI (
ArubaOS 6.5.3.x | User Guide
Figure 86 Configuring RSTP
Since RSTP is enabled by default, the default values appear in the WebUI.
lists the RSTP defaults and ranges (when applicable) in the configuration interface mode (config-if).
Table 146: RSTP Default Values
Feature
Port Cost
Priority
Port Fast
Point-to-Point
Default Value/Range
The RSTP interface path cost.
Range: 1–65536
Default: Based on Interface type:
Fast Ethernet 10Mbs: 100
Fast Ethernet 100Mbs: 19
1 Gigabit Ethernet: 4
10 Gigabit Ethernet: 2
Change the interface’s RSTP priority
Range: 0–255
Default: 128
Change from blocking to forwarding
Default : Disabled
Set the interface as a point-to-point link
Default : Enabled
In the CLI
Change the default configurations using the command line interface:
(host) (config-if)#spanning-tree cost Change an interface's spanning tree path cost point-to-point port-priority portfast
Set interface as point-to-point link
Change an interface's spanning tree priority
Allow a change from blocking to forwarding
ArubaOS 6.5.3.x
| User Guide RSTP | 658
Monitoring RSTP
Statistics for point-to-point, role, BPDU, and other information can be viewed in the WebUI under Monitoring
> Controller > Ports (see
).
Figure 87 Monitoring RSTP
659 | RSTP n n
Troubleshooting RSTP
The following commands can be used to troubleshoot RSTP:
The show spantree command (config mode) displays the root and bridge information, verifying that they are correct. The port/interface information (e.g. state, role, etc.) is also displayed to make sure that the state and role information correspond with each other. For more details and examples on the show spantree command, refer to show spantree in the ArubaOS Command-Line Interface Reference Guide .
The show spanning-tree interface command (config-if mode) displays Tx/Rx BPDU counters. For example, if a port’s role is “designated,” it only transmit BPDUs but does not receive any. In this case, the Tx counter continues to increase in increments while the Rx counter remains the same. This is reversed when a port's role is “root/alternate/backup”. For more details and examples on the show spanning-tree interface command, refer to show spaning-tree in the ArubaOS Command-Line Interface Reference
Guide .
ArubaOS 6.5.3.x | User Guide
Chapter 26
PVST+
PVST+ (Per-VLAN Spanning Tree Plus) provides load-balancing of VLANs across multiple ports, resulting in optimal usage of network resources. PVST+ also ensures interoperability with industry-accepted PVST+ protocols.
PVST+ is disabled by default.
Topics in this chapter include: n n n
Understanding PVST+ Interoperability and Best Practices on page 660
Enabling PVST+ in the CLI on page 660
Enabling PVST+ in the WebUI on page 661
n
Understanding PVST+ Interoperability and Best Practices
Interoperability between RSTP and PVST+ includes:
When the access port on the controller and the trunk port terminate on one Layer 2 switch running PVST+,
PVST+ sends untagged STP BPDUs on the access port; it also transmits untagged STP BPDUs (in addition to the other PVST+ BPDUs) on the native VLAN trunk port. If the Aruba controller is the root, it detects a loop on the native VLAN.
If PVST+ is not on the controller, best practices recommend disabling RSTP on the Aruba controller to avoid a looping issue.
n n
For VLAN load balancing when controllers are connected to armed mode, the VLAN priorities on two ports and bridge priorities must be configured so that one set of VLANs are active on one link, and the other set of VLANs are active on the other link.
64 instances are supported on the 7000 Series and 7200 Series controllers.
Enabling PVST+ in the CLI
PVST+ is disabled by default. Enable PVST+, ensure a VLAN instance is configured, and then configure PVST+.
1. Enable PVST+: spanning-tree mode rapid-pvst
2. Configure PVST+ forward time; the following command sets the time VLAN 2 spends in the listening and learning state (3 seconds): spanning-tree vlan 2 forward-time 3
3. Configure PVST+ hello time; the following command sets the time VLAN 2 waits to transmit BPDUs to four seconds: spanning-tree vlan 2 hello-time 4
4. Configure PVST+ max age; the following command sets the time VLAN 2 waits to receive a hello packet to
30 seconds: spanning-tree vlan 2 max-age 30
ArubaOS 6.5.3.x
| User Guide PVST+ | 660
5. Configure PVST+ priority: the following command sets the VLAN 2 priority to 10, making it more likely to become the root bridge: spanning-tree vlan 2 priority 10
6. Configure PVST+ on a range of VLANs using the VLAN IDs (coma separated or hyphen separated): spanning-tree vlan range 2-6,11
Enabling PVST+ in the WebUI
From the WebUI, add a VLAN instance and enable PVST+ under Configuration > Network > Ports >
Spanning Tree :
Figure 88 Configuring a VLAN with PVST+
661 | PVST+ ArubaOS 6.5.3.x | User Guide
Chapter 27
Link Layer Discovery Protocol
ArubaOS provides support for Link Layer Discovery Protocol (LLDP) on the controllers to advertise identity information and capabilities to other nodes on the network, and store the information discovered about the neighbors.
This chapter contains the following major sections: n n n n
Important Points to Remember on page 662
Monitoring LLDP Configuration on page 664
n n n n n
Important Points to Remember
Inventory-management and Location TLVs are not currently supported.
Aggregation-management and Power-management TLVs are not supported.
SNMP support is currently unavailable for LLDP MIBs.
Cisco Discovery Protocol (CDP) proprietary is not supported.
The maximum number of neighbors that can be learned on the controllers (including all the per port neighbors) is 250.
n n n n n n n n n
LLDP Overview
Link Layer Discovery Protocol (LLDP), defined in the IEEE 802.1AB standard, is a Layer 2 protocol that allows network devices to advertise their identity and capabilities on a LAN. ArubaOS supports a simple one-way neighbor discovery protocol with periodic transmissions of LLDP PDU.
n n n
LLDP frames are constrained to a local link.
LLDP frames are TLV (Type-Length-Value) form.
LLDP Multicast address is 01-80-C2-00-00-0E.
LLDP provides support for a set of attributes used to discover neighbor devices. These attributes are referred to as TLVs, which contain type, length, and value descriptions. LLDP supported devices use TLVs to receive and send information such as configuration information, device capabilities, and device identity to their neighbors.
ArubaOS supports the following optional basic management TLVs that are enabled by default:
MAC Phy configuration TLV
Management address TLV
Maximum frame size TLV
Port-description TLV
Port VLAN ID TLV
System capabilities TLV
System description TLV
System name TLV
VLAN name TLV
ArubaOS 6.5.3.x
| User Guide Link Layer Discovery Protocol | 662
LLDP-MED
LLDP-MED (media endpoint devices) is an extension to LLDP that supports interoperability between VoIP devices and other networking clients. LLDP-MED network policy discovery lets end-points and network devices advertise their VLAN IDs (for example, voice VLAN), priority levels, and DSCP values. ArubaOS supports a maximum of eight LLDP -MED Network Policy profiles.
Creating an LLDP MED network policy profile does not apply the configuration to any AP or AP interface or interface group. To apply the LLDP-MED network policy profile, you must associate it to an LLDP profile, then apply that LLDP profile to an AP wired port profile.
You can use the command, ap lldp med-network-policy-profile to define an LLDP MED network policy profile that defines DSCP values and L2 priority levels for a voice or video application.
Default LLDP Configuration
To display the default LLDP information, use the following command:
(host) #show lldp interface gigabitethernet 1/1
Interface: FE1/1
LLDP Tx: Disabled, LLDP Rx: Disabled
Proprietary Neighbor Discovery: Disabled
LLDP-MED: Disabled
Fast Transmit interval: 1, Fast Transmit message counter: 4
Transmit interval: 30, Transmit hold 4, Hold timer: 120
When you use the default LLDP configuration, the RX and TX parameters are disabled. You must explicitly enable them for LLDP to work.
Configuring LLDP
You can configure LLDP using the CLI. For detailed information on the LLDP commands, refer to interface fastethernet | gigabitethernet in the ArubaOS Command-Line Interface Reference Guide .
(host)(config) #interface gigabitethernet <slot>/<module>/<port>
(host)(config-if) #lldp fast-transmit-counter <1-8> fast-transmit-interval <1-3600> med receive transmit transmit-hold <1-100> transmit-interval <1-3600>
Configuring LLDP-MED
Creating an LLDP MED network policy profile does not apply the configuration to any AP or AP interface or interface group. To apply the LLDP-MED network policy profile, you must associate it to an LLDP profile, then apply that LLDP profile to an AP wired port profile.
The following commands create a LLDP MED network policy profile for streaming video applications and marks streaming video as high-priority traffic.
(host) (config) ap lldp med-network-policy-profile vid-stream
(host) (AP LLDP-MED Network Policy Profile "vid-stream") dscp 48
(host) (AP LLDP-MED Network Policy Profile "vid-stream")l2-priority 6
(host) (AP LLDP-MED Network Policy Profile "vid-stream")tagged
(host) (AP LLDP-MED Network Policy Profile "vid-stream")vlan 10
663 | Link Layer Discovery Protocol ArubaOS 6.5.3.x | User Guide
(host) (AP LLDP-MED Network Policy Profile "vid-stream")!
Next, the LLDP MED network policy profile is assigned to an LLDP profile, and the LLDP profile is associated with an AP wired-port profile.
(host) (config) ap lldp profile video1
(host) (AP LLDP Profile "video1")lldp-med-network-policy-profile vid-stream
(host) (AP LLDP Profile "video1")!
(host) (config)ap wired-port-profile corp2
(host) (AP wired port profile "corp2")lldp-profile video1
Monitoring LLDP Configuration
This section describes commands for monitoring LLDP configurations.
Display LLDP Interface
To display all LLDP information for all interfaces, use the following command:
(host)# show lldp interface
LLDP Interfaces Information
---------------------------
Interface LLDP TX LLDP RX LLDP-MED TX interval Hold Timer
-----------------------------------------------
GE1/3
GE1/4
Enabled Enabled Enabled 30
Enabled Enabled Enabled 30
120
120
Display LLDP Interface <interface>
To display LLDP information for a specific interface, use the following command:
(host) #show lldp interface gigabitethernet <slot>/<module>/<port>
(host) #show lldp interface gigabitethernet 0/0/1
Interface: gigabitethernet0/0/1
LLDP Tx: Enabled, LLDP Rx: Enabled
Proprietary Neighbor Discovery: Disabled
LLDP-MED: Disabled
Fast Transmit interval: 1, Fast Transmit message counter: 4
Transmit interval: 30, Hold timer: 120
Display LLDP Neighbor
(host)#show lldp neighbor
Capability codes: (R)Router, (B)Bridge, (A)Access Point, (P)Phone, (O)Other
LLDP Neighbor Information
-------------------------
Local Intf Chassis ID
-------------------
GE1/3
GE1/4
00:0b:86:6a:25:40
00:0b:86:6a:25:40
Capability
----------
B:R
B:R
Remote Intf
-----------
GE0/0/17
GE0/0/18
Expiry-Time (Secs)
------------------
105
105
System name
-----------
Aruba 7220
Aruba 7220
Number of neighbors: 2
ArubaOS 6.5.3.x
| User Guide Link Layer Discovery Protocol | 664
Display LLDP Neighbor Interface Detail
(host) (gigabitethernet "1/3") #show lldp neighbor interface gigabitethernet 1/3 detail
Interface: gigabitethernet1/3, Number of neighbors: 1
------------------------------------------------------------
Chassis id: 24.1.1.253, Management address: 24.1.1.253
Interface description: SW PORT, ID: 04C5A44C3485:P1
Device MAC: 04:c5:a4:4c:34:85
Last Update: Thu Oct 3 17:01:41 2013
Time to live: 180, Expires in: 179 Secs
System capabilities : Bridge,Phone
Enabled capabilities: Bridge,Phone
System name: SEP04C5A44C3485
System description:
Cisco IP Phone 7962G,V10, SCCP42.9-2-1S
Auto negotiation: Supported, Enabled
Autoneg capability:
100Base-X, HD: no, FD: yes
1000Base-T, HD: yes, FD: yes
Media attached unit type: 100BaseTXFD - 2 pair category 5 UTP, full duplex mode (16)
802.3 Power:
PortID:
PortDescr: local 04C5A44C3485:P1
SW PORT
LLDP-MED:
Device Type: Communication Device Endpoint (Class III)
Capability: LLDP-MED capabilities, Network policy, Extended power via MDI/PD, Inventory
LLDP-MED Network Policy for: AppType: 1, Defined: yes
Descr:
VLAN:
Voice
204
Layer 2 Priority: 5
DSCP Value: 46
LLDP-MED Network Policy for: AppType: 2, Defined: yes
Descr: Voice Signaling
VLAN: 204
Layer 2 Priority: 4
DSCP Value: 32
Extended Power-over-Ethernet:
Power Type & Source: PD Device
Power Source: unknown
Power Priority: unknown
Power Value: 6300
Inventory:
Hardware Revision: 10
Software Revision: SCCP42.9-2-1S
Firmware Revision: tnp62.8-3-1-21a.bin
Serial Number: FCH1529F57D
Manufacturer: Cisco Systems, Inc.
Model: CP-7962G
Display LLDP Statistics
(host)# show lldp statistics
LLDP Statistics
---------------
Interface Received Unknow TLVs Malformed Transmitted
--------------------------------------------
GE1/3
GE1/4
0
0
0
0
0
0
0
0
Display LLDP Statistics Interface
(host)# show lldp statistics interface gigabitethernet 1/3
665 | Link Layer Discovery Protocol ArubaOS 6.5.3.x | User Guide
LLDP Statistics
---------------
Interface
--------gigabitethernet1/3
Received Unknow TLVs Malformed Transmitted
------------------------------------
0 0 0 0
Display LLDP-MED Network Policy profiles
(host) #show ap lldp med-network-policy-profile
AP LLDP-MED Network Policy Profile List
---------------------------------------
Name
----
References
----------
Profile Status
-------------default 0 video voice
Total:2
2
1
ArubaOS 6.5.3.x
| User Guide Link Layer Discovery Protocol | 666
Chapter 28
IP Mobility
A mobility domain is a group of Aruba controllers among which wireless users can roam without losing their IP address. Mobility domains are not tied with the master controller; thus, it is possible for a user to roam between controllers managed by different master controllers, as long as all the controllers belong to the same mobility domain.
You enable and configure mobility domains only on Aruba controllers. No additional software or configuration is required on wireless clients to allow roaming within the domain.
Topics in this chapter include: n n n n n n
Understanding Aruba Mobility Architecture on page 668
Configuring Mobility Domains on page 669
Tracking Mobile Users on page 673
Configuring Advanced Mobility Functions on page 675
Understanding Bridge Mode Mobility Deployments on page 684
Enabling Mobility Multicast on page 684
Understanding Aruba Mobility Architecture
Aruba’s layer-3 mobility solution is based on the Mobile IP protocol standard, as described in RFC 3344, IP
Mobility Support for IPv4. This standard addresses users who need both network connectivity and mobility within the work environment.
Unlike other layer-3 mobility solutions, an Aruba mobility solution does not require that you install mobility software or perform additional configuration on wireless clients. The Aruba controllers perform all functions that enable clients to roam within the mobility domain.
In a mobility domain, a mobile client is a wireless client that can change its point of attachment from one network to another within the domain. A mobile client receives an IP address ( a home address ) on a home network .
A mobile client can detach at any time from its home network and reconnect to a foreign network (any network other than the mobile client’s home network) within the mobility domain. When a mobile client is connected to a foreign network, it is bound to a care-of address that reflects its current point of attachment. A care-of address is the IP address of the Aruba controller in the foreign network with which the mobile client is associated.
The home agent for the client is the controller at which the client appears for the first time upon joining the mobility domain. The home agent is the single point of contact for the client when the client roams. The foreign agent for the client is the controller which handles all Mobile IP communication with the home agent on behalf of the client. Traffic sent to a client’s home address is intercepted by the home agent and tunneled for delivery to the client on the foreign network. On the foreign network, the foreign agent delivers the tunneled data to the mobile client.
shows the routing of traffic from Host A to Mobile Client B when the client is away from its home network. The client’s care-of address is the IP address of the Aruba controller in the foreign network.
The numbers in the
correspond to the following descriptions:
1. Traffic to Mobile Client B arrives at the client’s home network via standard IP routing mechanisms.
ArubaOS 6.5.3.x
| User Guide IP Mobility | 668
2. The traffic is intercepted by the home agent in the client’s home network and tunneled to the care-of address in the foreign network.
3. The foreign agent delivers traffic to the mobile client.
4. Traffic sent by Mobile Client B is also tunneled back to the home agent.
Figure 89 Routing of Traffic to Mobile Client within Mobility Domain
Configuring Mobility Domains
Before configuring a mobility domain, you should determine the user VLAN(s) for which mobility is required.
For example, you may want to allow employees to be able to roam from one subnetwork to another. All controllers that support the VLANs into which employee users can be placed should be part of the same mobility domain.
Aruba mobility domains are supported only on Aruba controllers.
A controller can be part of multiple mobility domains, although it is recommended that a controller belong to only one domain. The controllers in a mobility domain do not need to be managed by the same master controller.
You configure a mobility domain on a master controller; the mobility domain information is pushed to all local controllers that are managed by the same master controller. On each controller, you must specify the active domain (the domain to which the controller belongs). If you do not specify the active domain, the controller will be assigned to a predefined “default” domain.
Although you configure a mobility domain on a master controller, the master controller does not need to be a member of the mobility domain. For example, you could set up a mobility domain that contains only local controllers; you still need to configure the mobility domain on the master controller that manages the local controllers. You can also configure a mobility domain that contains multiple master controllers; you need to configure the mobility domain on each master controller.
The basic tasks you need to perform to configure a mobility domain are listed below. The sections following describe each task in further detail. A sample mobility domain configuration is provided in
.
669 | IP Mobility ArubaOS 6.5.3.x | User Guide
Table 147: Tasks to Configure a Mobility Domain
On a master controller: On all controllers in the mobility domain: n
Configure the mobility domain, including the entries in the home agent table
(HAT) n n
Enable mobility (disabled by default)
Join a specified mobility domain (not required for “default” mobility domain)
You can enable or disable IP mobility in a virtual AP profile (IP mobility is enabled by default). When you enable
IP mobility in a virtual AP profile, the ESSID that is configured for the virtual AP supports layer-3 mobility. If you disable IP mobility for a virtual AP, any clients that associate to the virtual AP will not have mobility service.
Configuring a Mobility Domain
You configure mobility domains on master controllers. All local controllers managed by the master controller share the list of mobility domains configured on the master. Mobility is disabled by default and must be explicitly enabled on all controllers that will support client mobility. Disabling mobility does not delete any mobility related configuration.
In ArubaOS versions before 6.3, the home agent table (HAT) maps a user VLAN IP subnet to potential home agent addresses. Starting from 6.3, when you enable mobility the controller to which the client connects for the first time becomes its home agent. The mobility feature uses the HAT table to locate a potential home agent for each mobile client, and then uses this information to perform home agent discovery. To configure a mobility domain, you must assign a home agent address to at least one controller with direct access to the user
VLAN IP subnet. (Some network topologies may require multiple home agents.)
It is recommended that you configure the switch IP address to match the AP’s local controller, or define the
Virtual Router Redundancy Protocol (VRRP) IP address to match the VRRP IP used for controller redundancy.
Do not configure both a switch IP address and a VRRP IP address as a home agent address, or multiple home agent discoveries may be sent to the controller.
All user VLANs that are part of a mobility domain must have an IP address that can correctly forward layer-3 broadcast multicast traffic to clients when they are away from the home network.
The mobility domain named “default” is the default active domain for all controllers. If you need only one mobility domain, you can use this default domain. However, you also have the flexibility to create one or more user-defined domains to meet the unique needs of your network topology. Once you assign a controller to a user-defined domain, it automatically leaves the “default” mobility domain. If you want a controller to belong to both the “default” and a user-defined mobility domain at the same time, you must explicitly configure the
“default” domain as an active domain for the controller.
In the WebUI
1. Navigate to the Configuration > Advanced Services > IP Mobility page. Select the Enable IP Mobility checkbox.
2. To configure the default mobility domain, select the default domain in the Mobility Domain list.
To create a new mobility domain, enter the name of the domain in Mobility Domain Name and click Add ; the new domain name appears in the Mobility Domain list.
3. Select the newly-created domain name. Click Add under the Subnet column. Enter the subnetwork, mask,
VLAN ID, VRIP, and home agent IP address, and click Add . Repeat this step for each HAT entry.
4. Click Apply .
In the CLI router mobile
ArubaOS 6.5.3.x
| User Guide IP Mobility | 670
ip mobile domain < name> hat <home-agent> description <dscr>
To view currently-configured mobility domains in the CLI, use the show ip mobile domain command.
Ensure that the ESSID to which the mobile client will connect supports IP mobility. You can disable IP mobility for an ESSID in the virtual AP profile (IP mobility is enabled by default). If you disable IP mobility for a virtual
AP, any client that associates to the virtual AP will not have mobility service.
Joining a Mobility Domain
Assigning a controller to a specific mobility domain is the key to defining the roaming area for mobile clients.
You should take extra care in planning your mobility domains and survey the user VLANs and controllers to which clients can roam, to ensure that there are no roaming holes.
All controllers are initially part of the “default” mobility domain. If you use the default mobility domain, you do not need to specify this domain as the active domain on a controller. However, once you assign a controller to a user-defined domain, the default mobility domain is no longer an active domain on the controller.
In the WebUI
1. Navigate to the Configuration > Advanced Services > IP Mobility page.
2. In the Mobility Domain list, select the mobility domain.
3. Select the Active checkbox for the domain.
4. Click Apply .
In the CLI
Use the following command to activate a mobility domain: ip mobile active-domain < name>
To view the active domains in the CLI, use the show ip mobile active-domains command on the controller.
Sample Configuration
The following example (
Figure 90 ) configures a network in a campus with three buildings. An Aruba controller in
each building provides network connections for wireless users on several different user VLANs. To allow wireless users to roam from building to building without interrupting ongoing sessions, you configure a mobility domain that includes all user VLANs on the three controllers. You configure the HAT on the master controller only (A in this example). On the local controllers (B and C), you only need to enable mobility and activate the respective domain.
671 | IP Mobility ArubaOS 6.5.3.x | User Guide
Figure 90 Example Configuration: Campus-Wide
This example uses the “default” mobility domain for the campus-wide roaming area. Since all controllers are initially included in the default mobility domain, you do not need to explicitly configure “default” as the active domain on each controller.
In the WebUI
On controller A (the master controller):
1. Navigate to the Configuration > Advanced Services > IP Mobility page.
2. Select the Enable IP Mobility checkbox.
3. Select the default domain in the Mobility Domain list.
4. Click Add .
5. Enter the home agent IP address, and a description for the first entry and click Add . Repeat this step for each HAT entry.
6. Click Apply .
Table 148: Example entries
Home Agent Address or VRIP
10.1.1.245
10.2.1.245
10.3.1.245
10.4.1.245
On controllers B and C:
1. Navigate to the Configuration > Advanced Services > IP Mobility page.
2. Select the Enable IP Mobility checkbox.
3. Click Apply .
In the CLI
On controller A (the master controller):
ArubaOS 6.5.3.x
| User Guide IP Mobility | 672
(host)(config) #router mobile
(host)(config) #ip mobile domain default
(host)(mobility-domain) #hat 10.1.1.245 description "Corporate mobile entry"
(host)(mobility-domain) #hat 10.2.1.245 description "Local entry"
(host)(mobility-domain) #hat 10.3.1.245 description "Reserved reentry"
(host)(mobility-domain) #hat 10.4.1.245 description "Sales team"
(host)(mobility-domain) #!
(host)(config)# ip mobile active-domain default
On controllers B and C:
(host)(config) #router mobile
(host)(config)# ip mobile active-domain default
Tracking Mobile Users
This section describes how you can view information about the status of mobile clients in the mobility domain.
Location-related information for users, such as roaming status, AP name, ESSID, BSSID, and physical type are consistent in both the home agent and foreign agent. The username, role, and authentication can be different on the home agent and foreign agent, as explained by the following:
Starting with ArubaOS 6.3, L2 GRE tunnels are automatically established between controllers in mobility domain at the time of boot up. Before ArubaOS 6.3, the tunnels were created only when a client was associated to a controller. Whenever a client connects to a controller in a mobility domain, layer-2 authentication is performed and the station obtains the layer-2 (logon) role. When the client roams to other networks, layer-2 authentication is performed and the client obtains the layer-2 role. If layer-3 authentication is required, this authentication is performed on the client’s home agent only. The home agent obtains a new role for the client after layer-3 authentication; this new role appears in the user status on the home agent only.
Even if reauthentication occurs after the station moves to a foreign agent, the display on the foreign agent still shows the layer-2 role for the user.
Mobile Client Roaming Status
You can view the list of mobile clients and their roaming status on any controller in the mobility domain:
In the WebUI
Navigate to the Monitoring > controller > Clients page.
In the CLI
#show ip mobile host
Roaming status can be one of the following:
Table 149: Client Roaming Status
Roaming
Status Type
Home Switch/Home
VLAN
Mobile IP Visitor
Mobile IP Binding
(away)
Description
This controller is the home agent for a station, and the client is on the VLAN on which it has an IP address.
This controller is not the home agent for a client.
This controller is the home agent for a client that is currently away.
673 | IP Mobility ArubaOS 6.5.3.x | User Guide
Roaming
Status Type
Home Switch/Foreign
VLAN
Stale
No Mobility Service
Description
This controller is the home agent for a client, but the client is currently on a different VLAN than its home VLAN (the VLAN from which it acquired its IP address).
The client does not have connectivity in the mobility domain. Either the controller has received a disassociation message for a client, but has not received an association or registration request for the client from another controller, or a home agent binding for the station has expired before being refreshed by a foreign agent.
The controller cannot provide mobility service to this client. The mobile client may lose its IP address if it obtains the address via DHCP and has limited connectivity.
The mobile client may be using an IP address that cannot be served, or there may be a roaming hole due to improper configuration.
Viewing User Roaming Status using the CLI
You can view the roaming status of users on any controller in the mobility domain:
#show user
Roaming status can be one of the following:
Table 150: User Roaming status
Status Type
Wireless
Description
Visitor
Away
Foreign VLAN
Stale
This client is on its home agent controller and the client is on the VLAN on which it has an IP address.
This client is visiting this controller and the controller is not its home agent.
This client is currently away from its home agent controller.
This client is on its home agent controller but the client is currently on a different
VLAN than the one on which it has an IP address.
This should be a temporary state as the client will either recover connectivity or the client’s entry is deleted when the stale timer expires.
In the CLI
#show ip mobile trace < ip-address> |< mac-address>
Mobile Client Roaming Locations
You can view information about where a mobile user has been in the mobility domain. This information can only be viewed on the client’s home agent.
In the WebUI
1. Navigate to the Monitoring > controller > Clients page.
2. Click Status . The mobility state section contains information about the user locations.
In the CLI show ip mobile trail < ip-address >|< mac-address >
ArubaOS 6.5.3.x
| User Guide IP Mobility | 674
HA Discovery on Association
In normal circumstances, a controller performs an HA discovery only when it is aware of the client’s IP address which it learns through the ARP or any L3 packet from the client. This limitation of learning the client’s IP and then performing the HA discovery is not effective when the client performs an inter switch move silently (does not send any data packet when in power save mode). This behavior is commonly seen with various handheld devices, Wi-Fi phones and so on. This delays HA discovery and eventually results in any loss of downstream traffic that is meant for the mobile client.
When HA discovery on association is triggered, the foreign agent controller to which the client is associated, sends a unicast request to all controllers within the mobility domain to find if any one of the controllers has the
IP mobility state information of the client.
With HA discovery on association, a controller can perform a HA discovery as soon as the client is associated.
This feature is enabled by default. This option will also poll for all potential HAs.
In the CLI
To configure the mobility association: wlan virtual-ap default ha-disc-onassoc
Configuring Advanced Mobility Functions
You can configure various parameters that pertain to mobility functions on a controller in a mobility domain using either the WebUI or the CLI.
In the WebUI
1. Navigate to the Configuration > Advanced Services > IP Mobility page.
2. Select the Global Parameters tab.
3. Configure your desired IP mobility settings.
describes the parameters you can configure on the
Global Parameters tab.
Table 151: IP Mobility Configuration Parameters
Parameter Description
General
Encapsulation
Supported
Clear Trail Entries
This parameter shows the type of encapsulation currently supported on the controller.
Clear the station location trail table. You can view entries in this table using the show ip mobile trail command.
Clear Mobility Counters Clear counters for IP mobility statistics.
Foreign Agent lifetime Requested lifetime, in seconds, as per RFC 3344, IP Mobility Support for IPv4.
Range: 10-65534 seconds
Default: 180 seconds
675 | IP Mobility ArubaOS 6.5.3.x | User Guide
Parameter
Max. Visitors Allowed
Registration Requests
Retransmits
Registration Requests
Interval
Description
Set a maximum allowed number of active visitors.
Range: 0-5000 visitors
Default: 5000 visitors
Maximum number of times the foreign agent attempts mobile IP registration message exchanges before giving up.
Range: 0-5 attempts
Default: 3 attempts
Retransmission interval, in milliseconds.
Range: 100-10000 milliseconds
Default: 1000 milliseconds
Home Agent
Replay
Max. Binding Allowed
Time difference, in seconds, for timestamp-based replay protection, as described by RFC 3344, IP Mobility Support for IPv4. 0 disables replay.
Range: 0-5000 seconds
Default: 5000 seconds.
Maximum number of mobile IP bindings. Note that there is a license-based limit on the number of users and a one user per binding limit in addition to unrelated users. This option is an additional limitation to control the maximum number of roaming users. When the limit is reached, registration requests from the foreign agent fail which causes a mobile client to set a new session on the visited controller, which will become its home controller.
Range: 0-300 seconds
Default: 7 seconds
Proxy Mobile IP
Trigger Mobility on
Station Association
Mobility Trail Logging
Roaming for
Authenticated Stations
Only
Max. Station Mobility
Events per Second
Station Trail Timeout
If enabled, mobility move detection is performed when the client associates with the controller instead of when the client sends packets.
This option is enabled by default. Mobility on association can speed up roaming and improve connectivity for devices that do not send many uplink packets out to trigger mobility. The downside to this option is lowered security. An association alone triggers mobility; however, this is irrelevant unless layer-2 security is enforced.
Enables logging at the notification level for mobile client moves.
Allows a client to roam only if has been authenticated. If a client has not been authenticated, no mobility service is offered if it roams to a different VLAN or controller.
Maximum number of mobility events (events that can trigger mobility) handled per second. Mobility events above this threshold are ignored. This helps to control frequent mobility state changes when the client bounces back and forth on APs before settling down.
Range: 1-65535 events
Default: 25 events
Specifies the maximum interval, in seconds, an inactive mobility trail is held.
Range: 120-86400 seconds
Default: 3600 seconds
ArubaOS 6.5.3.x
| User Guide IP Mobility | 676
Parameter Description
Station Trail Max.
Entries
Specifies the maximum number of entries (client moves) stored in the user mobility trail.
Range: 1-100 entries
Default: 30 entries.
Mobility Host Entry Hold
Time
Number of seconds the mobility state is retained after the loss of connectivity.
This allows authentication state and mobility information to be preserved on the home agent controller. The default is 60 seconds but can be safely increased. In many case a station state is deleted without waiting for the stale timeout; user delete from management, foreign agent to foreign agent handoff, and so on. (This is different from the no-service-timeout; no-service-timeout occurs up front, while the stale-timeout begins when mobility service is provided but the connection is disrupted for some reason.)
Mobility Host Entry
Lifetime
Time, in seconds, after which mobility service expires. If nothing has changed from the previous state, the client is given another bridge entry but it will have limited connectivity.
Revocation
Retransmits
Interval
Maximum number of times the home agent or foreign agent attempts mobile IP registration/revocation message exchanges before giving up.
Range: 0-5 retransmissions
Default: 3 retransmissions.
Retransmission interval, in milliseconds.
Range: 100-10000 milliseconds
Default: 1000 milliseconds
4. Click Apply .
In the CLI
To configure foreign agent functionality, use the following command: ip mobile foreign-agent {lifetime <seconds> | max-visitors <number> | registrations {interval <msecs> | retransmits <number>}}
To configure home agent functionality, use the following command: ip mobile home-agent {max-bindings <number>|replay <seconds>}
To configure proxy mobile IP and DHCP functionality, use the following command: ip mobile proxy auth-sta-roam-only | event-threshold <number> | log-trail | no-service-timeout <seconds> | on-association | stale-timeout <seconds> | trail-length <number> |trail-timeout <seconds>
To configure revocation functionality, use the following command: ip mobile revocation {interval <msec>|retransmits <number>
To enable packet trace for a given MAC address, use the following command: ip mobile packet-trace <host MAC address>
Proxy Mobile IP
The proxy mobile IP module in a mobility-enabled controller detects when a mobile client has moved to a foreign network and determines the home agent for a roaming client. The proxy mobile IP module performs the following functions:
677 | IP Mobility ArubaOS 6.5.3.x | User Guide
n n
Derives the address of the home agent for a mobile client from the HAT using the mobile client’s IP address.
If there is more than one possible home agent for a mobile client in the HAT, the proxy mobile IP module uses a discovery mechanism to find the current home agent for the client.
Detects when a mobile client has moved. Client moves are detected based on ingress port and VLAN changes, and mobility is triggered accordingly. For faster roaming convergence between AP(s) on the same controller, it is recommended that you keep the on-association option enabled. This helps trigger mobility as soon as 802.11 association packets are received from the mobile client.
Revocations
A home agent or foreign agent can send a registration revocation message, which revokes registration service for the mobile client. For example, when a mobile client roams from one foreign agent to another, the home agent can send a registration revocation message to the first foreign agent so that the foreign agent can free any resources held for the client.
IPv6 L3 Mobility
ArubaOS supports IPv6 L3 Mobility functionality. The existing L3 mobility solution has been enhanced to support dual stacked (IPv4 and IPv6) and pure IPv6 mobile clients. The IPv6 L3 mobility allows the wireless clients to retain their IPv4 or IPv6 addresses across different VLANs within a controller and between different controllers. In the previous release, the Aruba Controllers supported L3 mobility only for single stacked IPv4 clients.
The following changes in the existing behavior is observed in the Aruba controller when you enable IPv6 L3
Mobility support : n
The controller throttles and proxies Router Advertisements (RAs) if the router mobile command is enabled.
The following command configures the maximum time allowed between sending unsolicited multicast router advertisements from each interface when RA proxy is enabled:
(config)# ipv6 proxy-ra interval <180-1800>
The default value for proxy-ra interval is 600 seconds. If RA is configured on an external router, but not within the controller, the controller stores the RA in cache and replays the RA from the external server and replays them every proxy-ra interval. If RA is configured in both an external router and in the controller, clients serviced by the controller receive RA only from the controller and not from the external router.
n n
L3 mobility support for wired and third-party APs are deprecated.
The HA discovery on association parameter is turned on by default and is not configurable.
By enabling L3 mobility feature, both the solicited RAs and the unsolicited periodic RAs will be converted to L2 unicast and sent to the wireless clients.
It is recommended to reboot the controller when you issue the no router mobile command so that mutlicast RAs do not continue to get converted to unicast RAs.
Multicast Mobility
Multicast mobility ensures a client gets an uninterrupted multicast stream while roaming. ArubaOS provides support for a MLD proxy to enable IPv6 multicast mobility. To achieve multicast mobility, the Home Agent (HA) and the Foreign Agent (FA) must be capable of MLD proxying by exchanging the MLD membership information and process MLD messages. ArubaOS controller supports MLD versions v1 and v2.
ArubaOS 6.5.3.x
| User Guide IP Mobility | 678
Important Points to Remember
n n
ArubaOS does not support the source-based forwarding functionality of MLDv2.
The multicast traffic flow stops for few seconds for roaming clients after enabling or disabling the Dynamic
Multicast Optimization (DMO) option.
In the CLI
Use the following command to enable MLD proxy in the VLAN:
(host)(config)# interface vlan <vlan-id>
(host)(config-subif)# ipv6 mld proxy <gigabitEthernet/fastEthernet> <slot>/<module>/<port>
Use the following command to display the interface-specific MLD proxy group information:
(host) #show ipv6 mld proxy-group
Use the following command to display the MLD proxy mobility database group information for tracking:
(host) #show ipv6 mld proxy-mobility-group
Use the following command to display the statistics of the MLD proxy:
(host) #show ipv6 mld proxy-stats
Use the following command to display the MLD proxy mobility multicast statistics:
(host)# show ipv6 mld proxy-mobility-stats
The following command displays the discovery count table that keeps track of per client home agent discovery:
(host) #show datapath mobility discovery-table
The following command displays the datapath HA table information:
(host) #show datapath mobility home-agent-table
The following command displays the mobility multicast-group table that floods the multicast RA traffic to the roaming clients:
(host) # show datapath mobility mcast-table
The following commands displays the statistics of the datapath mobility:
(host) #show datapath mobility stats
The following command displays the mobility multicast VLAN table information:
(host) #show ip mobile multicast-vlan-table n n n n n n n n n n n n n
The outputs of the following commands are enhanced to support IPv6 L3 mobility: how ip mobile host show ip mobile trace show ip mobile remote show ip mobile binding show ip mobile visitor show ip mobile trail show ip mobile packet-trace clear ip mobile trail <IPv6_addr> show ip mobile traff i c show ip mobile global show ip mobile hat show ip mobile domain ip mobile domain <name> hat <home-agent> description <dscr>
679 | IP Mobility ArubaOS 6.5.3.x | User Guide
Sample Configuration
The following figure provides information on how a client moves from one controller to another, when you enable IPv6 L3 mobility feature:
Figure 91 Sample IPv6 L3 Mobility Configuration
The following commands displays the initial configuration on HA and FA:
(host-HA) #show ip mobile domain
Mobility Domains:, 2 domain(s)
------------------------------
Domain name default
Home Agent Table
Domain name 6.3mobility
Home Agent Table
Home Agent Description
--------------- ----------------
10.15.45.10
10.15.44.60
(host-FA) #show ip mobile domain
Mobility Domains:, 2 domain(s)
------------------------------
Domain name default
Home Agent Table
Domain name 6.3mobility
Home Agent Table
Home Agent Description
--------------- ----------------
ArubaOS 6.5.3.x
| User Guide IP Mobility | 680
10.15.45.10
10.15.44.60
The following commands displays information on the client association to HA:
(host-HA) #show user
Users
-----
IP MAC Name Role Age(d:h:m) Auth VPN l ink AP name Roaming Essid/Bssid/Phy Profile Forward mode
Type Host Name
---------- ------------ ------ ---- ---------- ---- -
------- ------- ------- --------------- ------- --------
---- ---- -
50.50.50.11 24:77:03:9e:dc:4c authenticated 00:00:00
AP124-B11550-Jibin Wireless mobility-test/00:1a:1e:82:b3:10/a-HT default tunnel
2001:5000::2677:3ff:fe9e:dc4c 24:77:03:9e:dc:4c authenticated 00:00:00
AP124-B11550-Jibin Wireless mobility-test/00:1a:1e:82:b3:10/a-HT default tunnel fe80::2677:3ff:fe9e:dc4c 24:77:03:9e:dc:4c authenticated 00:00:00
AP124-B11550-Jibin Wireless mobility-test/00:1a:1e:82:b3:10/a-HT default tunnel
(host-HA) #show ip mobile host
Mobile Host List, 1 host(s)
---------------------------
24:77:03:9e:dc:4c
IPv4: 50.50.50.11
IPv6: fe80::2677:3ff:fe9e:dc4c, 2001:5000::2677:3ff:fe9e:dc4c
Roaming Status: Home Switch/Home VLAN, Service time 0 days 00:00:57
Home VLAN 50
(host-HA) #show datapath bridge table 24:77:03:9e:dc:4c
Datapath Bridge Table Entries
-----------------------------
Flags: P - Permanent, D - Deny, R - Roamed Client, M - Mobile,
X - Xsec, A - Auth, T - Trusted, W – Wifi
MAC VLAN Assigned VLAN Destination Flags Age
----------------- -----------------------------------
00:1A:1E:00:1A:E8 1
00:1A:1E:00:D3:E0 40
1
40
0/0/0 local P
P
0
0
01:80:C2:00:00:0E 4095 4095
01:80:C2:00:00:02 4095 4095
00:0B:86:16:6A:A0 1 1
3C:77:E6:7C:44:09 40 40 local local
0/0/0 tunnel 12
P
W
0
0
0
0
(host-HA) #show datapath station
+----+------+-----------------------------------------------------+
|SUM/| |
|CPU | Addr | Description
| |
Value |
+----+------+-----------------------------------------------------+
| | | |
| G | [03] | Maximum Entries 16383 |
+----+------+-----------------------------------------------------+
Datapath Station Table Entries
------------------------------
Flags: W - WEP, T - TKIP, A - AESCCM, M - WMM N - .11n client
S - AMSDU, G - AESGCM, R - DATA READY, I - INACTIVE, r - ROAMED
MAC BSSID VLAN Bad Decrypts Bad Encrypts RSN cap
----------------- ----------------- ---- ------------ ------------ ---------
24:77:03:9E:DC:4C 00:1A:1E:82:B3:10 50
Aid HomeVlan A-MsduSize A-MsduTxQ
0
Seq Flags
0 0
681 | IP Mobility ArubaOS 6.5.3.x | User Guide
---- -------- ---------- ------------------- --- -----
0 0000 0001 MN
The following commands displays status of the client roaming to FA:
(host-FA) #show ap association
Association Table
-----------------
Name bssid mac auth assoc aid l-int essid vlan-i d tunnel-id phy assoc. time num assoc Flags Band steer moves (T/S)
---- ----- --- ---- ----- --- ----- ----- ------
- --------- --- ----------- --------- ----- ----------------------
Ap_local 6c:f3:7f:3a:ba:d8 24:77:03:9e:dc:4c y y 1 100 mobility-test 60
0x1000f a-HT-40sgi-2ss 3m:20s 1 WA 0/0
ArubaOS 6.4 | User Guide IP Mobility | 594
595 | IP Mobility ArubaOS 6.4 | User Guide
Num Clients:1
(host-FA) #show user
Users
-----
IP MAC Name Role Age(d:h:m) Aut h VPN link AP name Roaming Essid/Bssid/Phy Profile Forward mode T ype Host Name
---------- ------------ ------ ---- ----------
---- -------- ------- ------- --------------- ------- ------------
---- --
50.50.50.11 24:77:03:9e:dc:4c sys_mip_role_649130_9 00:00:03
Ap_local Visitor mobility-test/6c:f3:7f:3a:ba:d8/a-HT default tunnel
Win 7
2001:5000::2677:3ff:fe9e:dc4c 24:77:03:9e:dc:4c sys_mip_role_649130_9 00:00:03
Ap_local Visitor mobility-test/6c:f3:7f:3a:ba:d8/a-HT default tunnel
Win 7
User Entries: 2/2
Curr/Cum Alloc:1/7 Free:1/6 Dyn:2 AllocErr:0 FreeErr:0
(host-FA) #show ip mobile host
Mobile Host List, 1 host(s)
---------------------------
24:77:03:9e:dc:4c
IPv4: 50.50.50.11
IPv6: 2001:5000::2677:3ff:fe9e:dc4c
Roaming Status: Mobile IP Visitor, Service time 0 days 00:03:33
Home VLAN 50, visiting local VLAN 60
(host-FA) #show datapath bridge table 24:77:03:9e:dc:4c
Datapath Bridge Table Entries
-----------------------------
Flags: P - Permanent, D - Deny, R - Roamed Client, M - Mobile, X - Xsec, A - Auth, O - Outer V
LAN, T - Trusted
MAC VLAN Assigned VLAN Destination Flags Age
----------------- ---- ------------- ----------- ----- ---
24:77:03:9E:DC:4C 4095 60
24:77:03:9E:DC:4C 60 60 tunnel 15 PMR 0 tunnel 15 PM 0
(host-FA) #show datapath station
Datapath Station Table Entries
------------------------------
Flags: W - WEP, T - TKIP, A - AESCCM, M - WMM N - .11n client
S - AMSDU, G - AESGCM, R - DATA READY, I - INACTIVE, r - ROAMED
MAC BSSID VLAN Bad Decrypts Bad Encrypts RSN cap
----------------- ----------------- ---- ------------ ------------ ---------
ArubaOS 6.5.3.x
| User Guide IP Mobility | 682
24:77:03:9E:DC:4C 6C:F3:7F:3A:BA:D8 60
Aid HomeVlan A-MsduSize A-MsduTxQ
0
Seq Flags
0
---- -------- ---------- ------------------- --- -----
0 0000 0001 MNr
(host-FA) #show ip mobile visitor
Foreign Agent Visitor list, 1 host(s)
-------------------------------------
24:77:03:9e:dc:4c
IPv4: 50.50.50.11
IPv6: 2001:5000::2677:3ff:fe9e:dc4c
HA Addr 10.15.44.60, Registration id D51BA8BC:856865FC
Lifetime granted 00:00:40 (40), remaining 00:00:36
Tunnel id 9, src 10.15.44.10 dest 10.15.44.60, reverse-allowed
7
The following command displays the status of the client on HA after roaming:
(host-HA) #show user
Users
-----
IP MAC Name Role Age(d:h:m) Auth VPN l ink AP name Roaming Essid/Bssid/Phy Profile Forward mode Type Hos t Name
---------- ------------ ------ ---- ---------- ---- -
------- ------- ------- --------------- ------- ------------ ----
---------
50.50.50.11 24:77:03:9e:dc:4c authenticated 00:00:08
Ap_local Away mobility-test/6c:f3:7f:3a:ba:d8/a-HT default tunnel
2001:5000::2677:3ff:fe9e:dc4c 24:77:03:9e:dc:4c authenticated 00:00:08
Ap_local Away mobility-test/6c:f3:7f:3a:ba:d8/a-HT default tunnel
User Entries: 2/2
Curr/Cum Alloc:1/16 Free:1/15 Dyn:2 AllocErr:0 FreeErr:0
(host-HA) #show ip mobile host
Mobile Host List, 1 host(s)
---------------------------
24:77:03:9e:dc:4c
IPv4: 50.50.50.11
IPv6: 2001:5000::2677:3ff:fe9e:dc4c
Roaming Status: Mobile IP Binding (Away), Service time 0 days 00:08:20
Home VLAN 50
(host-HA) #show datapath bridge table 24:77:03:9e:dc:4c
Datapath Bridge Table Entries
-----------------------------
Flags: P - Permanent, D - Deny, R - Roamed Client, M - Mobile, X - Xsec, A - Auth, O - Outer V
LAN, T - Trusted
MAC VLAN Assigned VLAN Destination Flags Age
----------------- ---- ------------- ----------- ----- ---
24:77:03:9E:DC:4C 4095 50 tunnel 9 PMT 0
24:77:03:9E:DC:4C 50 50 tunnel 9 PMTR 0
(host-HA) #show ip mobile binding
Home Agent Binding list, 1 host(s)
----------------------------------
24:77:03:9e:dc:4c
IPv6: 2001:5000::2677:3ff:fe9e:dc4c
FA Care-of Addr 10.15.44.10, Src Addr 10.15.44.10, HAT HA Addr 10.15.44.60
FA Visiting VLAN 60
Lifetime granted 00:00:40 (40), remaining 00:00:23
683 | IP Mobility ArubaOS 6.5.3.x | User Guide
Flags T, Registration id D51BA8BC:856865FC
Tunnel id 9, src 10.15.44.60 dest 10.15.44.10, reverse-allowed
Understanding Bridge Mode Mobility Deployments
In bridge mode deployments, it is possible to deploy more than one AP in a single location. Therefore, APs in bridge forwarding mode support firewall session synchronization, which allows clients to retain their current session and IP address as they roam between different bridge mode APs on the same layer-2 network.
The bridge mode mobility feature facilitates client mobility on up to 32 layer-2 connected APs by allowing the
APs to communicate and share the user state as the user roams from AP to AP. This mechanism is always enabled when an AP is set to bridge mode, and it requires that all APs be on the same Layer 2 segment where roaming will occur.
Figure 92 Bridge Mode Mobility
The roaming process occurs as follows:
1. A client begins to roam from AP1 and starts an association with AP2.
2. AP2 sends a broadcast message to all APs on the local layer-2 network, asking if any other AP has a current session state for the roaming client.
3. Only AP1 responds to the broadcast, and sends the current session table of the client.
4. AP2 acknowledges receipt of the session table.
5. AP1 deletes the session state of the client.
6. Roaming is complete.
Enabling Mobility Multicast
Internet Protocol (IP) multicast is a network addressing method used to simultaneously deliver a single stream of information from one sender to multiple clients on a network. Unlike broadcast traffic, which is meant for all hosts in a single domain, multicast traffic is sent only to those specific hosts who are configured to receive such
ArubaOS 6.5.3.x
| User Guide IP Mobility | 684
traffic. Clients who want to receive multicast traffic can join a multicast group via IGMP messages. Upstream routers use IGMP message information to compute multicast routing tables and determine the outgoing interfaces for each multicast group stream.
In ArubaOS 3.3.x and earlier, when a mobile client moved away from its local network and associated with a
VLAN on a foreign controller (or a foreign VLAN on its own controller), the client’s multicast membership information would not be available at its new destination, and multicast traffic from the client could be interrupted. ArubaOS 3.4 and later supports mobility multicast enhancements that provide uninterrupted streaming of multicast traffic, regardless of a client's location.
Working with Proxy IGMP and Proxy Remote Subscription
The controller is always aware of the client's location, so the controller can join multicast group(s) on behalf of that mobile client. This feature, called Proxy IGMP, allows the controller to join a multicast group and suppresses the client’s IGMP control messages to the upstream multicast router. (The client's IGMP control messages will, however, still be used by controller to maintain a multicast forwarding table.) The multicast
IGMP traffic originating from the client will instead be sent from the controller’s incoming VLAN interface IP.
The IGMP proxy feature includes both a host implementation and a router implementation. An upstream router sees a controller running IGMP proxy as a host; a client attached to the controller sees the controller as router. When you enable Proxy IGMP, all multicast clients associated with the controller are hidden from the upstream multicast device or router.
The newer IGMP proxy feature and the older IGMP snooping feature cannot be enabled at the same time, as both features add membership information to multicast group table. For most multicast deployments, you should enable the IGMP Proxy feature on all VLAN interfaces to manage all the multicast membership requirements on the controller. If IGMP snooping is configured on some interfaces, there is a greater chance that multicast information transfers may be interrupted.
IGMP proxy must be enabled or disabled on each individual interface. To use the IGMP proxy, ensure that the
VLANs on the controllers are extended to the upstream router. Enabling IGMP proxy enables IGMP on the interface and sets the querier to the controller itself. You must identify the controller port from which the controller sends proxy join information to the upstream router, and identify the upstream router by upstream port so the controller can dynamically update the upstream multicast router information.
IGMPv3 Support
ArubaOS 6.4 supports IGMPv3 functionality that makes Aruba controllers aware of the Source Specific
Multicast (SSM) and is used to optimize bandwidth of the network. The SSM functionality is an extension of IP multicast where the datagram traffic is forwarded to receivers from only those multicast sources to which the receivers have explicitly joined. By default, the multicast group range of 232.0.0.0 through 232.255.255.255
(232/8) is reserved for SSM by IANA (Internet Assigned Numbers Authority).
The IGMPv3 snooping functionality is configured at the edge of the network. The devices that support IGMP snooping listen for the IGMP messages that the host sent to join an IP multicast group. These devices record details of all the hosts and also about the IP multicast group in which a particular host has joined. These devices forward IP multicast traffic to the hosts that have joined the specific multicast group.
The IGMP proxy and IGMP snooping functionalities cannot be enabled on the same VLAN simultaneously.
Configuring SSM Range
You can configure the SSM range by using the CLI and WebUI.
685 | IP Mobility ArubaOS 6.5.3.x | User Guide
In the WebUI
1. Navigate to Configuration > Network > IP > Multicast Routing page of the WebUI.
2. In the IGMP tab, enter values for SSM Range in the SSM Range Start-IP and SSM Range Mask-IP text boxes.
3. Click Apply .
The proxy operation will be downgraded to IGMPv2 if any lower version clients are present and reverts back to v3 mode if the controller finds no lower version client joins (reports) for a specified interval of time. In the downgraded proxy operation the SSM semantics is not applicable for the particular VLAN.
In the CLI
(host)(config) # ip igmp
(host)(config-ip)# ssm-range <startip> <maskip>
Working with Inter Controller Mobility
When a client moves from one controller to another, multicast traffic migrates as follows:
Figure 93 Inter-Controller Mobility
1. The local controller uses its VLAN 10 IP address to join multicast group1 on behalf of a mobile client.
2. The mobile client leaves its local controller and roams to VLAN 50 remote controller A.
Remote controller A locates the mobile client's local controller and learns about the client's multicast groups. Remote controller A then joins group1 on behalf the mobile client, using its VLAN 50 source IP.
Upstream multicast traffic from the roaming client is sent to the local controller over an L2 GRE tunnel. The remote controller will receive downstream multicast traffic and send it to the mobile client.
The L2-GRE Tunnel implementation of the IP mobility functionality is supported only on ArubaOS versions 6.2 or later, and is not backward compatible with the earlier implementation. ArubaOS supports only v4 mobility and does not support IPv6 L3 mobility.
ArubaOS 6.5.3.x
| User Guide IP Mobility | 686
Meanwhile, the local controller checks to see if other local clients require group1 traffic. If no other clients are interested in group1, then the local controller will leave that group. If there are other clients using that group, the controller will continue its group1 membership.
3. Now the mobile client leaves remote controller A and roams to VLAN 100 on remote controller B. Remote controller B locates the mobile client's local controller and learns about the client's multicast groups.
Remote controller B then joins group1 on behalf the roaming mobile client 1, using its VLAN 100 IP address.
Both the local controller and remote controller A will verify if any of their other clients require group1 traffic. If none of their other clients require group1, then that controller will leave the group. (If the local controller leaves the group, it will also notify remote controller A.) If either controller has other clients using that group, that controller it will continue its group1 membership.
Configuring Mobility Multicast
To enable IGMP and/or IGMP snooping on this interface, or configure a VLAN interface for uninterrupted streaming of multicast traffic:
In the WebUI
1. Navigate to the Configuration > Network > IP window.
2. Click Edit by the VLAN interface for which you want to configure mobility multicast. The Edit VLAN window opens.
3. Select Enable IGMP to enable the router to discover the presence of multicast listeners on directly-attached links.
4. Select Snooping to save bandwidth and limit the sending of multicast frames to only those nodes that need to receive them.
5. Select the Interface checkbox, then click the Proxy drop-down list and select the controller interface, port and slot for which you want to enable proxy IGMP.
6. Click Apply .
7. (Optional) Repeat steps 1-6 above to configure mobility multicast for another VLAN interface.
In the CLI interface vlan <vlan> ip igmp proxy [{fastethernet|gigabitethernet} <slot>/<module>/<port>]|[snooping]
Table 152: Command Syntax
Parameter fastethernet
Description
Enable IGMP proxy on the FastEthernet (IEEE 802.3) interface gigabitethernet Enable IGMP proxy on the GigabitEthernet (IEEE 802.3) interface
<slot>/<module>/<port> Any command that references a Fast Ethernet or Gigabit Ethernet interface requires that you specify the corresponding port on the controller in the format <slot>/<module>/<port>.
snooping Enable IGMP snooping.
The IGMP protocol enables an router to discover the presence of multicast listeners on directly-attached links. Enable IGMP snooping to limit the sending of multicast frames to only those nodes that need to receive them.
687 | IP Mobility ArubaOS 6.5.3.x | User Guide
Example
The following example configures IGMP proxy for VLAN 2. IGMP reports from the controller would be sent to the upstream router on fastethernet port 1/3: conf# interface vlan 2 conf-subif# ip igmp proxy fastethernet 1/3
Multicast Group Limit
The following table describes the maximum multicast group limit per controller platform.
Maximum multicast group is the sum of IPv4 IGMP and IPv6 MLD groups.
Table 153: Multicast Group Limits
Platform Multicast Group Limit
7005
7010
7024
7030
7200 Series
128
256
256
512
4096
ArubaOS 6.5.3.x
| User Guide IP Mobility | 688
Chapter 29
External Firewall Configuration
In many deployment scenarios, an external firewall is situated between Aruba devices. This chapter describes the network ports that need to be configured on the external firewall to allow proper operation of the Aruba network. You can also use this information to configure session ACLs to apply to physical ports on the controller for enhanced security. However, this chapter does not describe requirements for allowing specific types of user traffic on the network.
A controller uses both its loopback address and VLAN addresses for communications with other network elements. If the firewall uses host-specific ACLs, those ACLs must specify all IP addresses used on the controller.
Topics in this chapter include: n n n n
Understanding Firewall Port Configuration Among Aruba Devices on page 689
Enabling Network Access on page 690
Ports Used for Virtual Intranet Access (VIA) on page 690
Configuring Ports to Allow Other Traffic Types on page 692
Understanding Firewall Port Configuration Among Aruba Devices
This section describes the network ports that need to be configured on the firewall to allow proper operation of the network.
Communication Between Controllers
Configure the following ports to enable communication between any two controllers: n n n n n n
IPSec (UDP ports 500 and 4500) and ESP (protocol 50). PAPI between a master and a local controller is encapsulated in IPSec.
IP-IP (protocol 94) and UDP port 443 if Layer-3 mobility is enabled
GRE (protocol 47) if tunneling guest traffic over GRE to DMZ controller
IKE (UDP 500)
ESP (protocol 50)
NAT-T (UDP 4500)
Communication Between APs and the Controller
APs use Trivial File Transfer Protocol (TFTP) during their initial boot to grab their software image and configuration from the controller. After the initial boot, the APs use FTP to retrieve their software images and configurations from the controller. In many deployment scenarios, an external firewall is situated between various Aruba devices.
Configure the following ports to enable communication between an AP and the controller: n n n
PAPI (UDP port 8211). If the AP uses DNS to discover the LMS controller, the AP first attempts to connect to the master controller. (Also allow DNS (UDP port 53) traffic from the AP to the DNS server.)
PAPI (UDP port 8211). All APs running as Air Monitors (AMs) require a permanent PAPI connection to the master controller.
FTP (TCP port 21)
ArubaOS 6.5.3.x
| User Guide External Firewall Configuration | 689
n n n n n
TFTP (UDP port 69) all campus APs, if there is no local image on the AP or if the image needs to be upgrade
(for example, a new AP), the AP will use TFTP to retrieve the initial image. For remote APs, upgrade the image only by FTP and not TFTP.
SYSLOG (UDP port 514)
PAPI (UDP port 8211)
GRE (protocol 47)
Control Plane Security (CPSec) uses UDP port 4500
Communication Between Remote APs and the Controller
Configure the following ports to enable communication between a Remote AP (IPSec) and a controller: n n
NAT-T (UDP port 4500)
TFTP (UDP port 69)
TFTP is not needed for normal operation. If the remote AP loses its local image for any reason, it will use TFTP to download the latest image.
Enabling Network Access
This section describes the network ports that need to be configured on the firewall to manage the Aruba network.
For WebUI access between the network administrator’s computer (running a Web browser) and a controller: n n
HTTP (TCP ports 80 and 8888) or HTTPS (TCP ports 443 and 4343).
SSH (TCP port 22 or TELNET (TCP port 23).
n n n
Ports Used for Virtual Intranet Access (VIA)
The following ports are used with Aruba VIA 3.2.x and later releases.
TCP 443 : During the initialization phase, VIA uses HTTPS connections to perform trusted network and captive portal checks. It is mandatory that you enable port 443 on your network to allow VIA to perform these checks.
UDP 4500 : This port is used for the IPsec connection and NAT-Traversal (NAT-T).
Custom Port/Port 8085 : If you have enabled the Client-certificate based authentication feature in the VIA authentication profile, you can define the port used for profile downloads in the Web server
Configuration profile. The supported range is port 1025-65535, and the default value is 8085.
The port configured for VIA client certificate-based authentication must also be added to the ACL whitelist using the firewall cp command or the Configuration > Stateful Firewall> ACL White List page of the controller WebUI. If the port is not configured on the control plane firewall, all packets sent to the controller port will be dropped, and the
HTTPS connection will not be established.
690 | External Firewall Configuration ArubaOS 6.5.3.x | User Guide
Table 154: VIA Features Requiring TCP Port 443 Access
Functionality TCP Port 443
Windows Linux Android Mac
Web Auth
Download VIA client software
Credential based connectionprofile download
Certificate based connectionprofile download
Trusted network check
SSL fallback
Captive portal detect iOS
Table 155: VIA Features Requiring UDP Port 4500 Access
Functionality
Windows Linux
IKE exchange
ESP
VPN Connection
(primary approach)
VPN Connection
(failover)
NAT (controller behind
NAT)
UDP port 4500
Android Mac
Table 156: Features Supporting a Custom Port
Functionality
Windows Linux
Custom Port <1025-65535>
Android Mac
Certificate based connectionprofile download (default, port
8085) iOS iOS
ArubaOS 6.5.3.x
| User Guide External Firewall Configuration | 691
n n n n n n n n n n n n n
Configuring Ports to Allow Other Traffic Types
This section describes the network ports that need to be configured on the firewall to allow other types of traffic in the Aruba network. You should only allow traffic as needed from these ports.
For logging: SYSLOG (UDP port 514) between the controller and syslog servers.
For software upgrade or retrieving system logs: TFTP (UDP port 69) or FTP (TCP ports 21 and 22) between the controller and a software distribution server.
If the controller is a PPTP VPN server, allow PPTP (UDP port 1723) and GRE (protocol 47) to the controller.
If the controller is an L2TP VPN server, allow NAT-T (UDP port 4500), ISAKMP (UDP port 500) and ESP
(protocol 50) to the controller.
If a third-party network management system is used, allow SNMP (UDP ports 161 and 162) between the network management system and all controllers.
For authentication with a RADIUS server: RADIUS (typically, UDP ports 1812 and 813, or 1645 and 1646) between the controller and the RADIUS server.
For authentication with an LDAP server: LDAP (UDP port 389) or LDAPS (UDP port 636) between the controller and the LDAP server.
For authentication with a TACACS+ server: TACACS (TCP port 49) between the controller and the TACACS+ server.
For NTP clock setting: NTP (UDP port 123) between all controllers and NTP server.
For packet captures: UDP port 5555 from an AP to an Ethereal packet-capture station; UDP port 5000 from an AP to a Wildpackets packet-capture station.
For telnet access: Telnet (TCP port 23) from the network administrator's computer to any AP, if “telnet enable” is present in the “ap location 0.0.0" section of the controller configuration.
For External Services Interface (ESI): ICMP (protocol 1) and syslog (UDP port 514) between a controller and any ESI servers.
For XML API: HTTP (TCP port 80) or HTTPS (TCP port 443) between a controller and an XML-API client.
692 | External Firewall Configuration ArubaOS 6.5.3.x | User Guide
Chapter 30
PAPI Enhanced Security
Starting from ArubaOS 6.5.1.0, a minor security enhancement is made to Process Application Programming
Interface (PAPI) messages. With this enhancement, PAPI endpoints authenticate the sender by performing a sanity check of the incoming messages using MD5 (hash).
All PAPI endpoints—access points, Mobility Access Switches, controllers, Analytics and Location
Engine (ALE), HPE-ArubaOS Switch-based switches, and AirWave—must use the same secret key.
The PAPI Enhanced Security configuration provides protection to Aruba devices, AirWave, and ALE against malicious users sending fake messages that results in security challenges.
PAPI Enhanced Security does not solve all the PAPI security issues.
Topics in this chapter include:
Configuring PAPI Enhanced Security on page 693
Verifying PAPI Enhanced Security on page 694
n n n n
Interoperability
The following list of references provides the Aruba devices interoperability information with respect to PAPI
Enhanced security feature:
For information on interoperability with AirWave, refer to the AirWave 8.2.0.3 Release Notes .
For information on interoperability with Analytics and Location Engine (ALE), refer to the Analytics and
Location Engine 2.0.0.6 Release Notes .
For interoperability with Mobility Access Switches, refer to the ArubaOS 7.4.1.5 Release Notes .
For interoperability with HPE-ArubaOS Switch-based switches, refer to HPE's Management Configuration
Guide 16.02
.
AirWave Management Platforms–AMP 8.0.11.2 and AMP 8.2.3–support PAPI Enhanced Security.
Configuring PAPI Enhanced Security
You can configure the PAPI Enhanced Security feature from either the WebUI or the CLI.
In the WebUI
Perform the following steps to enable the PAPI Enhanced Security feature and configure a PAPI key in the
WebUI:
1. Go to Configuration > Network > Controller > System Settings .
2. Under the PAPI Security section, perform the following steps: a. Select Yes for the Enhanced Security Mode Enabled option.
b. Enter a key in the PAPI Key text box.
c. Re-enter the PAPI key in the Retype PAPI Key text box.
3. Click Apply .
ArubaOS 6.5.3.x
| User Guide PAPI Enhanced Security | 693
In the CLI
By default, the PAPI Enhanced Security configuration is disabled. If there is no configured key, the default key is used for authentication.
(config) #papi-security
(host) (PAPI Security Profile) #?
enhanced-security key no
Enable or disable the use of enhanced security mode
Key used to authenticate messages between systems
Delete Command
Verifying PAPI Enhanced Security
To verify the status of the PAPI Enhanced Security configuration, execute the following command:
(host) (config) #show papi-security
PAPI Security Profile
---------------------
Parameter
---------
PAPI Key
Value
-----
********
Enhanced security mode Disabled
To view the statistics of transmitted, received, and denied messages, three additional output parameters are introduced in the show ipc statistics command output.
n n
Tx Sign—the number of messages which were signed before transmitting
Rx Sign—the number of messages validated through digest validation n
Rx Denied—the number of messages denied due to incorrect digest
(host) #show ipc statistics app-ap sapd ap-name <ap-name>
Local Statistics
To application
AP LLDP Service
Tx Msg
0
Tx Blk
0
Tx Ret
0
Tx Fail
0
Rx Ack
0
Rx Msg
186
Rx Drop
0
Rx Err
0
AP STM 31 0 0 0 12 0 0 0
RF Client
BLE Daemon AP
Nanny
2
3
2
0
0
0
.
.
0
0
0
0
Tx Ack
0
Tx Sign
0
0
0
0
0
.
Allocated Buffers 0
Static Buffers 1
Static Buffer Size 1476
0
0
0
0
Rx Sign Rx Denied
0 0
0
0
0
0
0
0
0
0
0
0
2
2
2
1
4
0
0
0
0
0
0
0
694 | PAPI Enhanced Security ArubaOS 6.5.3.x | User Guide
Chapter 31
Palo Alto Networks Firewall Integration
User-Identification (User-ID) feature of the Palo Alto Networks (PAN) firewall allows network administrators to configure and enforce firewall policies based on user and user groups. The User-ID identifies the user on the network based on the IP address of the device which the user is logged into. Additionally, a firewall policy can be applied based on the type of device the user is using to connect to the network. Since the Aruba controller maintains the network and user information of the clients on the network, it is the best source to provide the information for the User-ID feature on the PAN firewall.
The procedures in this chapter describe the steps to integrate a Palo Alto Networks firewall with a master or local controller.
For details on configuring PAN firewall integration with a branch office controller , see
Integration with a Palo Alto Networks (PAN) Portal on page 228
This feature introduces the following interactions with PAN firewall servers running PAN-OS 5.0 or later:: n n
Send logon events to the PAN firewall for the client with its IP address user name, device type, when classified.
Send logout events to PAN firewalls for the client with its IP address.
The following must be configured on the PAN Firewall: n n
An Admin account must be created on the PAN firewall to allow the controller to send data to the PAN firewall. This account must match the account added in the PAN profile on the controller. The built-in Admin account can be used for this purpose, but that is not recommended. It is better to create a new Admin account used solely for the purpose of communications between the controller and PAN firewall.
Preconfiguration of PAN Host Information Profile (HIP) objects and HIP-profiles on the PAN Firewall to support a device-type based policy.
To enable these features, the following must be configured on the controller: n n n n
The system-wide PAN profile must be properly configured and made active on the controller.
The pan-integration parameter in the AAA profile which the client is associated with must be enabled.
For VPN clients, enable the pan-integration parameter in the VPN authentication profile which the client is associated.
For VIA clients, enable the pan-integration parameter in the VIA authentication profile to which the client is associated.
Limitation
Keep the following limitation in mind when configuring PAN Firewall Integration. PAN Firewall Integration does not support bridge forwarding mode.
Preconfiguration on the PAN Firewall
Before PAN Firewall configuration is completed on the controller, some configuration must be completed on the PAN Firewall.
ArubaOS 6.5.3.x
| User Guide Palo Alto Networks Firewall Integration | 695
Certificate Management
The issuer certificate of the x509 server certificate used by the Palo Alto Networks firewall must be imported into all master and local controllers as a trusted CA in order to establish a secure HTTPS connection between the firewall and that controller.
User-ID Support
The administrator must configure firewall policies based on user-name and/or user-group. Additionally, correct configuration of connection to directory servers is needed for user-group based policies on the PAN firewall.
Device-Type Based Policy Support
The controller supports a limited number of device types. The identified device type associated with each IP user will be sent to the PAN in the client-version field with the host-info category of the HIP-report.
PAN administrators must create these HIP objects, which filter the HIP-reports sent from the controller to support device-type based firewall policies.
lists the HIP objects with a specified Is Value in the Client Version field, which must be preconfigured on the PAN firewall.
Table 157: HIP Objects
Client Version Is Value
Android
Apple
AppleTV
BlackBerry
Chrome OS iPad iPhone iPod
Kindle
Linux
Nintendo
Nintendo 3DS
Nintento Wii
Nook
OS X
696 | Palo Alto Networks Firewall Integration ArubaOS 6.5.3.x | User Guide
Client Version Is Value
PlayStation
PS Vita
PS3
PSP
RIM Tablet
Roku
Symbian webOS
Win 7
Win 8
Win 95
Win 98
Win 2000
Win CE
Win ME
Win NT
Win Server
Win Vista
Win XP
Windows
Windows Mobile
Windows Phone 7
Configuring PAN Firewall Integration
A PAN profile must be created on the controller. Multiple PAN profiles can be configured and saved on the controller, but only one profile can be active at a time. These profiles can be configured and applied using the
ArubaOS WebUI or CLI.
ArubaOS 6.5.3.x
| User Guide Palo Alto Networks Firewall Integration | 697
The procedures in this chapter describe the steps to integrate a Palo Alto Networks firewall with a master or local controller.
For details on configuring PAN firewall integration with a branch office controller , see
Integration with a Palo Alto Networks (PAN) Portal on page 228
Creating PAN Profiles
The first step in configuring PAN firewall integration is to create PAN Profiles. This profile provides the controller with the information required for connecting to and interacting with the specified PAN firewall. The
PAN profile can be created using the WebUI or CLI.
This configuration is done and available on the master controller only. The configuration will be pushed to all connected local controllers.
Using the WebUI
To configure a new PAN profile, complete the following steps:
1. Navigate to Configuration > Advanced Services > All Profiles > Other Profiles > Palo Alto
Networks Servers .
2. Type the name of the PAN profile and click Add .
3. Click on the name of the name PAN profile to open the Profile Details window.
4. Enter the Host (IP address or hostname) of the PAN firewall
5. Enter the Port (1 – 65535) of the PAN Firewall.
6. Enter the Username of the PAN firewall. The user name is between 1 and 255 bytes in length. The username must match the Admin account previously created on the PAN firewall.
7. Enter the Password of the username in PAN Firewall. The password is between 6 and 100 bytes in length.
The password must match the Admin account previously created on the PAN firewall.
8. Re-enter the Password entered in the previous step.
9. Click Add .
10.Click
Apply .
Up to twenty (20) PAN firewalls are supported.
Table 158: PAN Profile Parameters
Parameter Description
Host (IP or hostname) The hostname or IP address of the PAN firewall.
Port (1 - 65535) The port number of the PAN firewall.
Username
Password
Retype Password
The username in the PAN firewall (1 - 255 bytes in length).
Enter the password of the PAN firewall.
Retype the password of the PAN firewall.
Using the CLI
(host)(config) #pan profile <profile-name> firewall host <host> port <port> username <username> passwd <password>
698 | Palo Alto Networks Firewall Integration ArubaOS 6.5.3.x | User Guide
Activating a PAN Profile
Once a PAN profile has been created, the profile must be activated. Select profile you want to activate from the list of configured profiles.
This configuration must be completed on each local controller.
Using the WebUI
To apply a PAN profile, complete the following steps:
1. Navigate to Configuration > Advanced Services > All Profiles > Other Profiles > Palo Alto
Networks Active .
2. Select Active Palo Alto Networks . To the right of this link, the name of the active profile is displayed.
3. Another configured profile can be selected from the Active Palo Alto Networks Profile > drop-down menu. Additionally, a new profile can be configured by selecting --NEW-and completing the configuration details.
4. Once a profile is selected from the drop-down menu or a new profile is created, click Apply .
Using the CLI
(host)(config) #pan active-profile profile <profile- name>
Enabling PAN Firewall Integration
PAN firewall integration must be enabled on the AAA profile that the client is associated with.
Using the WebUI
To enable PAN firewall integration in the AAA profile:
1. Navigate to the Configuration > Security > Authentication > AAA Profiles page.
2. In the AAA Profiles Summary , select the desired profile.
3. Check the PAN Firewalls Integration check box.
4. Click Apply .
Using the CLI
(host)(config) #aaa profile <aaa profile-name> pan-integration
Enabling PAN Firewall Integration for VIA Clients
For VIA clients, PAN firewall integration must be enabled on the VIA authentication profile that the client is associated with.
Using the WebUI
To enable PAN firewall integration for VIA clients:
1. Navigate to the Security > Authentication > L3 Authentication page.
2. In the profiles list on the left, click VIA Authentication and select the desired profile.
3. Check the PAN Firewalls Integration check box.
4. Click Apply .
ArubaOS 6.5.3.x
| User Guide Palo Alto Networks Firewall Integration | 699
Using the CLI
(host)(config) #aaa authentication via auth-profile <profile-name> pan-integration
Enabling PAN Firewall Integration for VPN Clients
For VPN clients, PAN firewall integration must be enabled on the VPN authentication profile that the client is associated with.
Using the WebUI
To enable PAN firewall integration for VPN clients:
1. Navigate to the Security > Authentication > L3 Authentication page.
2. In the profiles list on the left, click VPN Authentication and select the default profile.
3. Check the PAN Firewalls Integration check box.
4. Click Apply .
Using the CLI
(host)(config) #aaa authentication vpn default pan-integration
700 | Palo Alto Networks Firewall Integration ArubaOS 6.5.3.x | User Guide
Chapter 32
Remote Access Points
The Secure Remote Access Point Service allows AP users, at remote locations, to connect to an Aruba controller over the Internet. Because the Internet is involved, data traffic between the controller and the remote AP is
VPN encapsulated. That is, the traffic between the controller and AP is encrypted. Remote AP operations are supported on all of Aruba’s APs.
Topics in this chapter include: n n n n n n n n n n n n n
About Remote Access Points on page 701
Configuring the Secure Remote Access Point Service on page 703
Deploying a Branch/Home Office Solution on page 709
Enabling Remote AP Advanced Configuration Options on page 714
Understanding Split Tunneling on page 728
Understanding Bridge on page 734
Provisioning Wi-Fi Multimedia on page 739
Reserving Uplink Bandwidth on page 739
Provisioning 4G USB Modems on Remote Access Points on page 740
Configuring RAP-3WN and RAP-3WNP Access Points on page 745
Converting an IAP to RAP or CAP on page 746
Enabling Bandwidth Contract Support for RAPs on page 747
About Remote Access Points
Remote APs connect to a controller using Extended Authentication and Internet Protocol Security
(XAuth/IPSec). AP control and 802.11 data traffic are carried through this tunnel. Secure Remote Access Point
Service extends the corporate office to the remote site. Remote users can use the same features as corporate office users. For example, voice over IP (VoIP) applications can be extended to remote sites while the servers and the PBX remain secure in the corporate office.
For both RAPs and CAPs, tunneled SSIDs will be brought down eight seconds after the AP detects that there is no connectivity to the controller. However, RAP bridge-mode SSIDs are configurable to stay up indefinitely
(always-on / persistent). For CAP bridge-mode SSIDs, the CAP will be brought down after the keepalive times out (default 3.5 minutes).
Secure Remote Access Point Service can also be used to secure control traffic between an AP and the controller in a corporate environment. In this case, both the AP and controller are in the company’s private address space.
The remote AP must be configured with the IPSec VPN tunnel termination point. Once the VPN tunnel is established, the AP bootstraps and becomes operational. The tunnel termination point used by the remote AP depends upon the AP deployment, as shown in the following scenarios: n
Deployment Scenario 1: The remote AP and controller reside in a private network which secures AP-tocontroller communication. (This deployment is recommended when AP-to-controller communications on a private network need to be secured.) In this scenario, the remote AP uses the controller’s IP address on the private network to establish the IPSec VPN tunnel.
ArubaOS 6.5.3.x
| User Guide Remote Access Points | 701
Figure 94 Remote AP with a Private Network n
Deployment Scenario 2: The remote AP is on the public network or behind a NAT device and the controller is on the public network. The remote AP must be configured with the tunnel termination point, which must be a publicly-routable IP address. In this scenario, a routable interface is configured on the controller in the
DMZ. The remote AP uses the controller’s IP address on the public network to establish the IPSec VPN tunnel.
Figure 95 Remote AP with Controller on Public Network n
Deployment Scenario 3: The remote AP is on the public network or behind a NAT device and the controller is also behind a NAT device. (This deployment is recommended for remote access.) The remote AP must be configured with the tunnel termination point, which must be a publicly-routable IP address. In this scenario, the remote AP uses the public IP address of the corporate firewall. The firewall forwards traffic to an existing interface on the controller. (The firewall must be configured to pass NAT-T traffic (UDP port 4500) to the controller.)
Figure 96 Remote AP with Controller Behind Firewall
In any of the described deployment scenarios, the IPSec VPN tunnel can be terminated on a local controller, with a master controller located elsewhere in the corporate network (
Figure 97 ). The remote AP must be able to
communicate with the master controller after the IPSec tunnel is established. Make sure that the L2TP IP pool configured on the local controller (from which the remote AP obtains its address) is reachable in the controller network by the master controller.
702 | Remote Access Points ArubaOS 6.5.3.x | User Guide
Figure 97 Remote AP in a Multi-Controller Environment n n n
Configuring the Secure Remote Access Point Service
The tasks for configuring an Aruba Access Points as a Secure Remote Access Point Service are:
Configure a public IP address for the controller.
You must install one or more AP licenses in the controller. There are several AP licenses available that support different maximum numbers of APs. The licenses are cumulative; each additional license installed increases the maximum number of APs supported by the controller.
Configure the VPN server on the controller. The remote AP will be a VPN client to the server.
Provision the AP with IPSec settings, including the username and password for the AP, before you install it at the remote location. You can also provision the RAP using the zero touch provisioning method. For more information, see
Provisioning 4G USB Modems on Remote Access Points on page 740 .
Configure a Public IP Address for the Controller
The remote AP requires an IP address to which it can connect to establish a VPN tunnel to the controller. This can be either a routable IP address you configure on the controller, or the address of an external router or firewall that forwards traffic to the controller. The following procedure describes how to create a DMZ address on the controller.
In the WebUI
1. Navigate to the Configuration > Network > VLANs page.
2. Click Add to add a VLAN.
3. Enter the VLAN ID.
4. Select the port that belongs to this VLAN.
5. Click Apply .
6. Navigate to the Configuration > Network > IP page.
7. Click Edit for the VLAN you just created.
8. Enter the IP Address and Net Mask fields.
9. Click Apply .
In the CLI
(host) (config) #vlan <id>
(host) (config) #interface fastethernet <slot/module/<port> switchport access vlan <id>
(host) (config) #interface vlan <id> ip address <ipaddr> <mask>
ArubaOS 6.5.3.x
| User Guide Remote Access Points | 703
Configure the NAT Device
Communication between the AP and the secure controller uses the UDP 4500 port. When both the controller and the AP are behind NAT devices, configure the AP to use the NAT device’s public address as its master address. On the NAT device, you must enable NAT-T (UDP port 4500 only) and forward all packets to the public address of the NAT device on UDP port 4500 to the controller to ensure that the remote AP boots successfully.
Configure the VPN Server
This section describes how to configure the IPSec VPN server on the controller. For more details, see
Private Networks on page 352 .
The remote AP will be a VPN client that connects to the VPN server on the controller .
In the WebUI
1. Navigate to the Configuration > Advanced Services > VPN Services > IPSec page.
2. Select Enable L2TP .
3. Make sure that PAP (Password Authentication Protocol) is selected for Authentication Protocols.
4. To configure the L2TP IP pool, click Add in the Address Pools section. Configure the L2TP pool from which the APs will be assigned addresses, then click Done .
The size of the pool should correspond to the maximum number of APs that the controller is licensed to manage.
5. To configure an Internet Security Association and Key Management Protocol (ISAKMP) encrypted subnet and preshared key, click Add in the IKE Shared Secrets section and configure the preshared key. Click
Done to return to the IPSec page.
6. Click Apply .
In the CLI
(host) (config) # vpdn group l2tp ppp authentication PAP
(host) (config) #ip local pool <pool> <start-ipaddr> <end-ipaddr>
(host) (config) #crypto isakmp key <key> address <ipaddr> netmask <mask>
CHAP Authentication Support over PPPoE
RAPs can now establish a PPPoE session with a PPPoE server at the ISP side and get authenticated using the
Challenge Handshake Authentication Protocol (CHAP). The PPPoE client running on a RAP is capable of handling the CHAP authentication requests from the PPPoE server.
The PPPoE client selects either the PAP or the CHAP credentials for the RAP authentication depending upon the request from the PPPoE server.
You can use the WebUI or the CLI to configure CHAP.
In the WebUI
1. Navigate to the Configuration > Wireless > AP Installation page. The list of discovered APs are displayed on this page.
2. Select the AP you want to configure using CHAP and click Provision button.
3. Enter the CHAP Secret in the text box under Authentication Method .
704 | Remote Access Points ArubaOS 6.5.3.x | User Guide
You can use all the special characters except question mark (?) and the space can be used within double quotes (“ “).
4. Enter the CHAP Secret again in the Confirm CHAP Secret text box for confirmation.
Figure 98 CHAP Authentication Using CHAP Secret
5. Click Apply and Reboot.
In the CLI
(host) (config) #provision-ap pppoe-chap-secret <KEY> reprovision ap-name <name>
Configuring Certificate RAP
You can configure the remote AP to use the internal certificate for authentication. You can use the WebUI or
CLI to configure the certificate RAP.
In the WebUI
1. Navigate to Configuration > AP Installation (under Wireless.)
2. Select the required remote AP under the Provisioning tab and then click Provision .
3. Select Yes for Remote AP and Certificate for Remote AP Authentication Method.
4. Click Apply and Reboot to apply the configuration and reboot the AP as certificate RAP.
In the CLI
(host) (config) #local-userdb-ap whitelist-db rap add <mac-address>
Creating a Remote AP Whitelist
If you use the Zero Touch provisioning method to provision the certificate RAP, then you must create a remote
AP whitelist. For more information on Zero Touch Provisioning of the RAP, see
Provisioning 4G USB Modems on Remote Access Points on page 740 .
Remote AP whitelist is the list of approved APs that can be provisioned on your controller.
In the WebUI
1. Navigate to Configuration > AP Installation (under Wireless) and then click the RAP Whitelist tab on the right side.
2. Click New and provide the following details: n n n
AP MAC Address —mandatory parameter. Enter the MAC address of the AP.
Username —enter a username that is used when the AP is provisioned.
AP Group —select a group to add the AP.
ArubaOS 6.5.3.x
| User Guide Remote Access Points | 705
n n n
AP Name —enter a name for the AP. If you do not enter an AP name, the MAC address will be used instead.
Description —enter a text description for the AP
IP-Address —enter an IP address for the AP.
3. Click Add to add the remote AP to the whitelist.
Configuring PSK RAP
You can use Pre-Shared Key (PSK) authentication to provision an individual remote AP or a group of remote
APs using an Internet Key Exchange Pre-Shared Key (IKE PSK).
Starting with ArubaOS 6.5.2.0, PSK RAPs support IKEv1 SHA-2 cryptographic hash function.
In the WebUI
1. Navigate to the Configuration > Wireless > AP Installation > Provisioning window.
2. Click the checkbox by the AP you want to provision, then click Provision . The Provisioning window opens.
3. Select Yes for the Remote AP option
4. In the Remote IP Authentication Method section, select Pre-shared key .
5. Enter and confirm the pre-shared key (IKE PSK).
6. In the User credential assignment section, specify if you want to use a Global User Name/password or a Per AP User Name/Password .
a. If you use the Per AP User Names/Passwords option, each RAP is given its own username and password.
b. If you use the Global User Name/Password option, all selected RAPs are given the same (shared) username and password.
7. Enter the user name, and enter and confirm the password. If you want the controller to automatically generate a user name and password, select Use Automatic Generation , then click Generate by the
User Name and Password fields.
Add the user to the internal database
You can add the user to the internal database using the WebUI or CLI.
In the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Internal DB .
3. Click Add User in the Users section. The user configuration page displays.
4. Enter the username and password.
5. Click Enabled to activate this entry on creation.
6. Click Apply . Note that the configuration does not take effect until you perform this step.
7. At the Servers page, click Apply .
In the CLI
(host) (config) #local-userdb add username rapuser1 password <password>
706 | Remote Access Points ArubaOS 6.5.3.x | User Guide
RAP Static Inner IP Address
The RAP static inner IP address feature assigns a static inner IP address to a remote access point (RAP). A new remote-IP address parameter is added to the existing configuration commands.
In the WebUI
To view IP address parameter in the local database, navigate to the Configuration > Security >
Authentication > Servers > Internal DB page.
Figure 99 IP-Address parameter in the local database
To view IP-address parameter in the RAP Whitelist, navigate to the Wireless > AP Installation > RAP
Whitelist page.
Figure 100 IP-Address parameter in the RAP Whitelist
In the CLI
(host) (config) #local-userdb add {generate-username|username <name>} {generatepassword|password
<password>} {remote-ip <remote-ip>}
(host) (config) #local-userdb modify {username < name>} {remote-ip <remote-ip>}
(host) (config) #local-userdb-ap whitelist-db rap add {mac-address <address>}{ap-group <ap_ group>}{remote-ip <remote-ip>}
(host) (config) #local-userdb-ap whitelist-db rap modify {mac-address <address>} {remoteip<remote-ip>}
You cannot configure the IP-Address parameter using the WebUI.
Provision the AP
You need to configure the VPN client settings on the AP to instruct the AP to use IPSec to connect to the controller. You can provision the remote AP and give it to users and allow remote users to provision AP at their home. This method of provisioning is referred as Zero Touch Provisioning. See
Provisioning 4G USB Modems on Remote Access Points on page 740
for more information about Zero Touch Provisioning of remote AP.
You must provision the AP before you install it at its remote location. To provision the AP, the AP must be physically connected to the local network or directly connected to the controller. When connected and powered on, the AP must also be able to obtain an IP address from a DHCP server on the local network or from the controller.
If your configuration has an internal LMS IP address, remote APs may attempt to switch over to the LMS IP address, which is not reachable from the Internet. For remote APs, ensure that the LMS IP address in the AP system profile for the AP group has an externally routable IP address.
ArubaOS 6.5.3.x
| User Guide Remote Access Points | 707
Reprovisioning the AP causes it to automatically reboot. The easiest way to provision an AP is to use the
Provisioning page in the WebUI, as described in the following steps:
1. Navigate to the Configuration > Wireless > AP Installation > Provisioning page. Select the remote AP and click Provision .
2. Under Authentication Method , select IPSec Parameters . Enter the Internet Key Exchange (IKE) Pre-
Shared Key (PSK) , username , and password .
The username and password you enter must match the username and password configured on the authentication server for the remote AP.
3. Under Master Discovery, set the Master IP Address as shown below:
Deployment Scenario
Deployment 1
Deployment 2
Deployment 3
Master IP Address Value
Controller IP address
Controller public IP address
Public address of the NAT device to which the controller is connected
The username and password you enter must match the username and password configured on the authentication server for the remote AP.
4. Under IP Settings , make sure that Obtain IP Address Using DHCP is selected.
5. Click Apply and Reboot .
Secondary Master Controller
The backup Local Mobility Switch (LMS) provides reliability and redundancy; however the functionality of a backup LMS is initiated only after an AP terminates on a controller successfully and retrieves the configuration.
If the AP boots up and fails to connect to the master controller the AP cannot be managed. To address this
ArubaOS 6.5.0.0 introduces the secondary master controller feature.
In a scenario where the master controller is not reachable, the AP will try to reach the secondary master controller and if successful will terminate on the secondary master. The secondary master details are not stored in the system flash when the AP is deployed for the first time, but only after a successful configuration.
An AP can use the secondary master controller feature after the AP reboots.
If an AP has not been configured to a controller after deployment the secondary master feature will not be applicable.
In the WebUI
To enable the secondary master controller feature:
1. Navigate to Configuration > Advanced services > All Profiles .
2. Click AP > AP System .
3. Select the AP profile for which the secondary master controller feature is to be enabled. The Profile Details section is displayed.
4. Navigate to the Basic > General tab.
5. Enter an IP or FQDN value for the secondary master controller in the Secondary Master IP/FQDN field.
708 | Remote Access Points ArubaOS 6.5.3.x | User Guide
Figure 101 Profile Details
In the CLI
Execute the following command to enable the secondary master controller feature.
(host) (config) #ap system-profile <profile name>
(host) (AP system profile "profile name")#secondary-master <value>
Deploying a Branch/Home Office Solution
In a branch office, the AP is deployed in a separate IP network from the corporate network. Typically, there are one or two NAT devices between the two networks. Branch office users need access to corporate resources such as printers and servers, but traffic to and from these resources must not impact the corporate head office.
is a graphic representation of a remote AP in a branch or home office, with a single controller providing access to both a corporate WLAN and a branch office WLAN.
Figure 102 Remote AP with Single Controller
ArubaOS 6.5.3.x
| User Guide Remote Access Points | 709
Branch office users want continued operation of the branch office WLAN, even if the link to the corporate network goes down. The branch office AP solves these requirements by providing the following capabilities on the branch office WLAN: n n n n
Local termination of 802.11 management frames which provides survivability of the branch office WLAN.
All 802.1X authenticator functionality is implemented in the AP. The controller is used as a RADIUS passthrough when the authenticator has to communicate with a RADIUS server (which also supports survivability).
802.11 encryption/decryption is in the AP to provide access to local resources.
Local bridging of client traffic connected to the WLAN or to an AP 70 enet1 port to provide access to local resources.
Provisioning the Branch AP
You can provision the remote AP either using the controller or using the Zero Touch Provisioning method. For more information on controller provisioning, see
Configuring Installed APs on page 542
. For more information on Zero Touch Provisioning, see
Provisioning 4G USB Modems on Remote Access Points on page 740 .
Configuring the Branch AP
n n n n n n
Specify forward mode for the Extended Service Set Identifier (ESSID) in the virtual AP profile
Specify remote AP operation in the virtual AP profile (The remote AP operates in standard mode by default.)
Set how long the AP stays up after connectivity to controller has gone down in the SSID profile
Set the VLAN ID in the virtual AP profile
Set the native VLAN ID in the AP system profile
Set forward mode for enet1 port
Remote APs support 802.1q VLAN tagging. Data from the remote AP will be tagged on the wired side.
Troubleshooting Remote AP
The following WebUI options are available to troubleshoot issues with remote AP: n n n n
Using local debugging feature
Viewing the remote AP summary report
Viewing remote AP connectivity report
Using remote AP diagnostic options
Local Debugging
Local debugging is a WebUI feature that allows end users to perform diagnostics and view the status of their remote AP through a wired or wireless client. This feature is useful for troubleshooting connectivity problems on remote APs and performing throughput tests. There are three tabs in the Local Debugging WebUI window; Summary , Connectivity , and Diagnostics . Each tab displays different information for the AP, but all three tabs include a Generate & save support file link that, when clicked, will automatically generate a support.tgz
file that can be sent to a corporate IT department for additional analysis and debugging.
A snapshot of the bridge, acl, session, user, and arp tables, current processes, memory, and kernel debug messages are captured in a single rap_debug.txt
file which is bundled along with support.tgz
file.
710 | Remote Access Points ArubaOS 6.5.3.x | User Guide
Remote AP Summary
The Summary tab has two views; basic and advanced. Click the basic or advanced links at the top of this tab to toggle between the two views. The table below shows the information displayed for both the basic and advanced views of the Summary tab.
Table 159: RAP Console Summary Tab Information
Summary
Table Name
Wired Ports
Status
Basic View Information n n
Port : port numbers of the wired ports on the AP
Status : current status of each port
( Connected , LinkDown or Disabled ).
Advanced View Information
Wireless SSIDs
Wired Users n n n
SSID : Name of the SSID.
Status : SSID Status (up, down, or disabled).
Band : Radio band available on the
SSID.
n n
MAC Address : MAC address of the wired user.
IP address : IP address of the wired user.
The advanced view of the Wired Access
Ports table displays the following data: n n n
Port : port numbers of the wired ports on the AP
Status : current status of each port
( Connected , LinkDown or Disabled )
MAC Address: MAC address of the wired port n n
Speed : speed of the link
Duplex Type : duplex mode of the link, full or half n n n n
Forwarding mode : forwarding mode for the port: Bridge , Tunnel or Split Tunnel
Users : number of users accessing each port
Rx Packets : number of packets received on the port
Tx packets : number of packets transmitted via the port n n n n n n n n n n n
SSID : name of the SSID
Status : SSID Status (up, down, or disabled).
Band : radio band available on the SSID
Channel : channel used on the radio band
BSSID : BSSID of the wireless SSID
Forwarding Mode : forwarding mode used by the Wireless SSID (Bridge,
Tunnel or Split-Tunnel)
EIRP : equivalent Isotropic Radiated
Power, in dBm
Noise floor : residual background noise detected by an AP. Noise seen by an AP is reported as -dBm Therefore, a noise floor of -100 dBm is smaller (lower) than a noise floor of -50 dBm.
Users : number of users on the radio band
Rx Packets : number of packets received on the BSSID
Tx packets : number of packets transmitted via the BSSID n n n MAC Address : MAC address of the wired user.
IP address : IP address of the wired user.
Port : AP port used by the wired user.
ArubaOS 6.5.3.x
| User Guide Remote Access Points | 711
Summary
Table Name
Wireless User
Device Info
Uplink Info
Basic View Information Advanced View Information n n
MAC Address : MAC address of the wireless user.
IP address : IP address of the wireless user.
n n n n n n n n n
Type : AP device/model type.
Name : Name assigned to the AP.
Wired MAC address : MAC address of the wired port.
Serial # : AP serial number.
Tunnel IP address : IP address of the tunnel between the AP and controller.
Software Version : Software version currently running on the AP.
Uptime : Amount of time the AP has been active since it was last reset.
Master : IP address of the master controller.
lms : IP address of the local controller.
N/A
The Uplink Info table can display some or all of the following information for your remote AP, depending upon whether a link is active and the number of links supported by the AP.
Active uplink information, including: n
Interface name n n
Port speed
IP address
Standby link information, including: n Name (3G) n n n n n n
Device connected (yes/no)
Provisioned (yes/no)
IP address
Device
User
Password n n n n n n n n n
MAC Address : MAC address of the wired user
IP address : IP address of the wired user
SSID : name of the SSID
BSSID : BSSID of the wireless user
Assoc State : shows if the user is associated or just authorized
Auth : Type of authentication: WPA,
802.1X, none, open, or shared
Encryption : encryption type used by the wireless user
Band : radio band used by the wireless client
RSSI : Receive Signal Strength Indicator
(RSSI) value displayed in the output of this command represents signal strength as a signal to noise ratio.
N/A
Multihoming on remote AP (RAP)
You can uplink a RAP as an Ethernet or a USB based modem. These uplinks can be used as a backup link if the primary link fails. The uplink becomes active based on the order of priority configured on the RAP. The RAP switches back to the primary link when the primary connection is restored.
712 | Remote Access Points ArubaOS 6.5.3.x | User Guide
For information on provisioning the RAP using the USB based modem, see
Remote Access Points on page 740
.
Seamless failover from backup link to primary link on RAP
RAPs can failover from a backup link to a primary link without much disruption to traffic. Also the failover is performed only if the controller is reachable via the primary link.
Remote AP Connectivity
The information shown on the Connectivity tab will vary, depending upon the current status of the remote
AP. If a remote AP has been successfully provisioned and connected, it should display some or all of the information in
Table 160: RAP Console Connectivity Tab Information
Data
Uplink status
IP Information
Gateway Connectivity
TPM Certificates
Master Connectivity
LMS Connectivity
Description
Shows if the link connected failed. If the link is connected, the Uplink status also displays the name of the interface.
If the AP has successfully received an IP address, this data row will show the AP’s IP address, subnet mask, and gateway IP address.
If successful, this item also shows the percentage of packet loss for data received from the gateway.
If successful, the AP has a Trusted Platform Module (TPM) certificate.
Shows if the AP was able to connect to the master controller. This item also shows the IP address to which the AP attempted to connect, and, if the AP did connect successfully, the link used to connect to that controller.
Shows if the AP was able to connect to a local controller. This item also shows the IP address to which the AP attempted to connect, and, if the AP did connect successfully, the link used to connect to that controller.
The top of the Connectivity tab has a Refresh link that allows users to refresh the data on their screen.
Additional information at the bottom of this tab shows the date, time, and reason the remote AP last rebooted. The Reboot RAP Now button reboots the remote AP.
Remote AP Diagnostics
Use the Diagnostics tab to view log files, or run diagnostic tests that can help the IT department troubleshoot errors. Use the Reboot AP Now button at the bottom of the Diagnostic window to reboot the remote AP.
To run a diagnostic test on a remote AP:
1. Access the RAP console, and click the Diagnostics tab.
2. Click the Test drop-down list and select Ping , Traceroute, NSLookup , or Throughput .
The ping and traceroute tests require that you enter a network destination in the form of an IP address or fully-qualified domain name, and select either bridge or tunnel mode for the test.
The NSLookup diagnostic test requires that you enter a destination only. The throughput test checks the throughput of the link between the AP and the controller, and does not require any additional test configuration settings.
3. Click OK to start the test. The results of the test will appear in the Diagnostics window.
ArubaOS 6.5.3.x
| User Guide Remote Access Points | 713
To display log files in a separate browser window, click the logs drop-down list at the upper right corner of the
Diagnostics window, and select any of the log file name. The type of log files available will vary, depending upon your remote AP configuration.
n n n n n n n n
Enabling Remote AP Advanced Configuration Options
This section describes the following features designed to enhance your remote AP configuration:
Understanding Remote AP Modes of Operation on page 714
Working in Fallback Mode on page 716
Specifying the DNS Controller Setting on page 724
Backup Controller List on page 725
Configuring Remote AP Failback on page 726
Working with Access Control Lists and Firewall Policies on page 728
Understanding Split Tunneling on page 728
Provisioning Wi-Fi Multimedia on page 739
The information in this section assumes you have already configured the remote AP functionality, as described in
Configuring the Secure Remote Access Point Service on page 703
.
Understanding Remote AP Modes of Operation
summarizes the different remote AP modes of operation. You specify both the forward mode setting (which controls whether 802.11 frames are tunneled to the controller using GRE, bridged to the local
Ethernet LAN, or a combination thereof) and the remote AP mode of operation (when the virtual AP operates on a remote AP) in the virtual AP profile.
The column on the left of the table lists the remote AP operation settings. The row across the top of the table lists the forward mode settings. To understand how these settings work in concert, scan the desired remote AP operation with the forward mode setting, and read the information in the appropriate table cell.
The “all” column and row lists features that all remote AP operation and forward mode settings have in common regardless of other settings. For example, at the intersection of “all” and “bridge,” the description outlines what happens in bridge mode regardless of the remote AP mode of operation.
714 | Remote Access Points ArubaOS 6.5.3.x | User Guide
Table 161: Remote AP Modes of Operation and Behavior
Remote AP
Operation
Setting
Forward Mode Setting all always all bridge
Management frames on the AP.
Frames are bridged between wired and wireless interfaces.
No frames are tunneled to the controller.
Station acquires its IP address locally from an external DHCP server.
split-tunnel
Management frames on the AP.
Frames are either
GRE tunneled to the controller to a trusted tunnel or
NATed and bridged on the wired interface according to user role and session
ACL.
Typically, the station obtains an
IP address from a
VLAN on the controller.
Typically, the AP has ACLs that forward corporate traffic through the tunnel and source
NAT the noncorporate traffic to the Internet.
Not supported Provides an SSID that is always available for local access.
ESSID is always up when the AP is up regardless of whether the controller is reachable.
Supports PSK
ESSID only.
SSID configuration stored in flash on AP.
all bridge split-tunnel tunnel
Frames are GRE tunneled to the controller to an untrusted tunnel.
100% of station frames are tunneled to the controller.
Not supported tunnel decrypt-tunnel
Management frames on the
AP.
Frames are always GRE tunneled to controller.
Not supported
ArubaOS 6.5.3.x
| User Guide Remote Access Points | 715
Remote AP
Operation
Setting backup
Forward Mode Setting persistent standard
ESSID is only up when the controller is unreachable.
Supports PSK
ESSID only.
SSID configuration stored in flash on AP.
ESSID is up when the AP contacts the controller and stays up if connectivity is disrupted with the controller.
SSID configuration obtained from the controller.
Designed for
802.1X SSIDs.
Provides a backup SSID for local access only when the controller is unreachable.
Same behavior as standard, described below, except the ESSID is up if connectivity to the controller is lost.
ESSID is up only when there is connectivity with the controller.
SSID configuration obtained from the controller.
Behaves like a classic Aruba branch office AP.
Provides a bridged ESSID that is configured from the controller and stays up if there is controller connectivity.
Not supported
Not supported
Split tunneling mode
Not supported
Not supported
Not supported
Not supported
Classic Aruba thin AP operation
Decrypt tunnel mode
Working in Fallback Mode
The fallback mode (also known as backup configuration) operates the remote AP if the master controller or the configured primary and backup LMS are unreachable. The remote AP saves configuration information that allows it to operate autonomously using one or more SSIDs in local bridging mode, while supporting open association or encryption with PSKs. You can also use the backup configuration if you experience network connectivity issues, such as the WAN link or the central data center becoming unavailable. With the backup configuration, the remote site does not go down if the WAN link fails or the data center is unavailable.
You define the backup configuration in the virtual AP profile on the controller. The remote AP checks for configuration updates each time it establishes a connection with the controller. If the remote AP detects a change, it downloads the configuration changes.
The following remote AP backup configuration options define when the SSID is advertised (refer to
for more information): n n
Always—Permanently enables the virtual AP. Recommended for bridge SSIDs.
Backup—Enables the virtual AP if the remote AP cannot connect to the controller. This SSID is advertised until the controller is reachable. Recommended for bridge SSIDs.
716 | Remote Access Points ArubaOS 6.5.3.x | User Guide
n n
Persistent—Permanently enables the virtual AP after the remote AP initially connects to the controller.
Recommended for 802.1X SSIDs.
Standard—Enables the virtual AP when the remote AP connects to the controller. Recommended for
802.1X, tunneled, and split-tunneled SSIDs. This is the default behavior.
While using the backup configuration, the remote AP periodically retries its IPSec tunnel to the controller. If you configure the remote AP in backup mode, and a connection to the controller is re-established, the remote AP stops using the backup configuration and immediately brings up the standard remote AP configuration. If you configure the remote AP in always or persistent mode, the backup configuration remains active after the IPSec tunnel to the controller has been re-established.
Backup Configuration Behavior for Wired Ports
If the connection between the remote AP and the controller is disconnected, the remote AP will be exhibit the following behavior: n n n
All access ports on the remote AP will be moved to bridge forwarding mode ,irrespective of their original forwarding mode..
Clients will receive an IP address from the remote AP's DHCP server.
Clients will have complete access to Remote AP's uplink network. You cannot enforce or modify any access control policies on the clients connected in this mode.
This section describes the following topics: n n n
Configuring Fallback Mode on page 717
Configuring the DHCP Server on the Remote AP on page 719
Configuring Advanced Backup Options on page 721
Configuring Fallback Mode
To configure the fallback mode, you must: n n
Configure the AAA profile
Configure the virtual AP profile
Configuring the AAA Profile for Fallback Mode
In the WebUI
The AAA profile defines the authentication method and the default user role for unauthenticated users:
1. Navigate to the Security > Authentication > AAA Profiles page. From the AAA Profiles Summary list, click Add .
2. Enter the AAA profile name, then click Add .
3. Select the AAA profile that you just created: a. For Initial role , select the appropriate role (for example, “logon”).
b. For 802.1X Authentication Default Role , select the appropriate role (for example, “default”), then click Apply .
c. Under the AAA profile that you created, locate 802.1X Authentication Server Group , and select the authentication server group to use (for example “default”), then click Apply .
If you need to create an 802.1X authentication server group, select new from the 802.1X Authentication Server
Group drop-down list, and enter the appropriate parameters.
ArubaOS 6.5.3.x
| User Guide Remote Access Points | 717
d. Under the AAA profile that you created, locate 802.1X Authentication Profile, and select the profile to use (for example, “default”), then click Apply .
If you need to create an 802.1X authentication profile, select new from the 802.1X Authentication Profile dropdown list, and enter the appropriate parameters.
In the CLI
(host) (config) #aaa profile <name> initial-role <role> authentication-dot1x <dot1x-profile> dot1x-default-role <role> dot1x-server-group <group>
Configuring the Virtual AP Profile for Fallback Mode
In the WebUI l l
Set the remote AP operation to always , backup , or persistent .
Create and apply the applicable SSID profile.
The SSID profile for the backup configuration in always, backup, or persistent mode must be a bridge
SSID. When configuring the virtual AP profile, specify forward mode as bridge .
The SSID profile for the backup configuration in standard mode can be a bridge, tunnel, or split tunnel
SSID. When configuring the virtual AP profile, specify forward mode as bridge , tunnel , or split tunnel .
When creating a new virtual AP profile In the WebUI, you can also configure the SSID at the same time. For information about AP profiles, see
Understanding AP Configuration Profiles on page 530 .
1. Navigate to the Configuration > Wireless > AP Configuration page. Select either the AP Group or AP
Specific tab. Click Edit for the AP group or AP name.
2. Under Profiles, select Wireless LAN , then Virtual AP .
3. To create a new virtual AP profile in the WebUI, select New from the Add a profile drop-down menu. Enter the name for the virtual AP profile, and click Add .
Whenever you create a new virtual AP profile in the WebUI, the profile automatically contains the “default” SSID profile with the default ESSID. You must configure a new ESSID and SSID profile for the virtual AP profile before you apply the profile.
a. In the Profile Details entry for the new virtual AP profile, go to the AAA Profile drop-down list and select the previously configured AAA profile (for example, logon ). The AAA Profile pop-up window appears.
b. To set the AAA profile and close the pop-up window, Click Apply.
c. In the Profile Details entry for the new virtual AP profile, select NEW from the SSID Profile drop-down menu. The SSID Profile pop-up window displays to allow you to configure the SSID profile.
d. Enter the name for the SSID profile (for example, backup ).
e. Under Network, enter a name in the Network Name (SSID) field (for example, backup-psk ).
f. Under Security, select the network authentication and encryption methods (for example, wpa-psk-tkip, with the passphrase remote123 ).
g. To set the SSID profile and close the pop-up window, click Apply .
4. At the bottom of the Profile Details window, Click Apply .
5. Click the new virtual AP name in the Profiles list or the Profile Details to display configuration parameters.
6. Under Profile Details, do the following: a. Make sure Virtual AP enable is selected.
718 | Remote Access Points ArubaOS 6.5.3.x | User Guide
b. From the VLAN drop-down menu, select the VLAN ID to use for the virtual AP profile.
c. From the Forward mode drop-down menu, select bridge .
d. From the Remote-AP Operation drop-down menu, select always , backup , or persistent . The default is standard. Click Apply .
In the CLI
(host) (config) #wlan ssid-profile <profile> essid <name> opmode <method> wpa-passphrase <string> (if necessary)
(host) (config) #wlan virtual-ap <name> ssid-profile <profile> vlan <vlan> forward-mode bridge aaa-profile <name> rap-operation {always|backup|persistent}
(host) (config) #ap-group <name> virtual-ap <name> or
(host) (config) #ap-name <name> virtual-ap <name>
Configuring the DHCP Server on the Remote AP
You can configure the internal DHCP server on the remote AP to provide an IP address for the backup SSID if the controller is unreachable. If configured, the remote AP DHCP server intercepts all DHCP requests and assigns an IP address from the configured DHCP pool.
To configure the remote AP DHCP server: n n n n n
Enter the VLAN ID for the remote AP DHCP VLAN in the AP system profile. This VLAN enables the DHCP server on the AP (also known as the remote AP DHCP server VLAN). If you enter the native VLAN ID, the
DHCP server is not configured and is unavailable.
Specify the DHCP IP address pool and netmask. The AP assigns IP addresses from the DHCP pool
192.168.11.0/24 by default, with an IP address range from 192.168.11.2 through 192.168.11.254. You can manually define the DHCP IP address pool and netmask based on your network design and IP address scheme.
Specify the IP address of the DHCP server, DHCP router, and the DHCP DNS server. The AP uses IP address
192.168.11.1 for the DHCP server, the DHCP router, and the DHCP DNS server by default.
Enter the amount of days the assigned IP address is valid (also known as the remote AP DHCP lease). The lease does not expire by default, which means the IP address is always valid.
Assign the VLAN ID for the remote AP DHCP VLAN to a virtual AP profile. When a client connects to that virtual AP profile, the AP assigns the IP address from the DHCP pool.
The following is a high-level description of the steps required to configure the DHCP server on the remote AP. The steps assume you have already created the virtual AP profile, AAA profile, SSID profile, and other settings for your remote AP operation (for information about the backup configuration, see
Configuring Fallback Mode on page 717 ).
In the WebUI
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. Select either the AP Group or AP Specific tab. Click Edit for the AP group or AP name.
3. Under Profiles , select AP to display the AP profiles.
ArubaOS 6.5.3.x
| User Guide Remote Access Points | 719
4. Select the AP system profile you want to modify.
5. Under Profile Details: a. At the LMS IP field, enter the LMS IP address.
b. At the Master controller IP address field, enter the master controller IP address.
c. At the Remote-AP DHCP Server VLAN field, enter the VLAN ID of the backup configuration virtual AP
VLAN.
d. At the Remote-AP DHCP Server ID field, enter the IP address for the DHCP server.
e. At the Remote-AP DHCP Default Router field, enter the IP address for the default DHCP router.
f. At the Remote-AP DHCP DNS Server list, enter an IP address in the field to right and click Add . You can add multiple IP addresses the same way. To delete an IP address, select an IP address from the list and click Delete .
g. Specify the DHCP IP address pool. This configures the pool of IP addresses from which the remote AP uses to assign IP addresses.
- At the Remote-AP DHCP Pool Start field, enter the first IP address of the pool.
- At the Remote-AP-DHCP Pool End field, enter the last IP address of the pool.
- At the Remote-AP-DHCP Pool Netmask field, enter the netmask.
h. At the Remote-AP DHCP Lease Time field, specify the amount of time the IP address is valid.
6. Click Apply .
7. Under Profiles , select Wireless LAN , then Virtual AP , then the virtual AP profile you want to configure.
8. Under Profile Details , at the VLAN drop-list, select the VLAN ID of the remote AP DHCP VLAN, click the left arrow to move the VLAN ID to the VLAN field, and click Apply .
In the CLI
Use the following commands:
(host) (config) #ap system-profile <name> lms-ip <ipaddr> master-ip <ipaddr> rap-dhcp-default-router <ipaddr> rap-dhcp-dns-server <ipaddr> rap-dhcp-lease <days> rap-dhcp-pool-end <ipaddr> rap-dhacp-pool-netmask <netmask> rap-dhcp-pool-start <ipaddr> rap-dhcp-server-id <ipaddr> rap-dhcp-server-vlan <vlan>
(host) (config) #wlan virtual-ap <name> ssid-profile <profile> vlan <vlan> forward-mode bridge aaa-profile <name> rap-operation {always|backup|persistent}
(host) (config) #ap-group <name> ap-system-profile <name> virtual-ap <name> or
(host) (config) #ap-name <name> ap-system-profile <name> virtual-ap <name>
720 | Remote Access Points ArubaOS 6.5.3.x | User Guide
Configuring Advanced Backup Options
You can also use the backup configuration (fallback mode) to allow the remote AP to pass through a captive portal, such as network access in a hotel, airport, or other public network, to access the corporate network. For this scenario: n n
Define a session ACL for the bridge SSID to source NAT all user traffic, except DHCP. For example, use any any svc-dhcp permit followed by any any any route src-nat . Apply the session ACL to a remote AP user role.
Configure the AAA profile. Make sure the initial role contains the session ACL previously configured.
The AAA profile defines the authentication method and the default user role.
802.1X and PSK authentication is supported when configuring bridge or split tunnel modes.
n n n
Configure the virtual AP profile for the backup configuration: l l
Set the remote AP operation to always or backup .
Create and apply the applicable SSID profile.
l
Configure a bridge SSID for the backup configuration. In the virtual AP profile, specify forward mode as bridge .
For more information about the backup configuration, see
Configuring Fallback Mode on page 717
.
Enter the remote AP DHCP server parameters in the AP system profile. For more information about the parameters, see
Configuring the DHCP Server on the Remote AP on page 719
.
If you use a local DHCP server to obtain IP addresses, you must define one additional ACL to permit traffic between clients without source NATing the traffic. Using the previously configured ACL, add user alias internal-network any permit before any any any route src-nat .
Connect the remote AP to the available public network (for example, a hotel or airport network).
The remote AP advertises the backup SSID so the wireless client can connect and obtain an IP address from the available DHCP server.
The client can obtain an IP address from the public network, for example a hotel or airport, or from the DHCP server on the remote AP.
After obtaining an IP address, the wireless client can connect and access the corporate network and bring up the configured corporate SSIDs.
The following is a high-level description of what is needed to configure the remote AP to pass through a captive portal and access the corporate controller. This information assumes you are familiar with configuring session
ACLs, AAA profiles, virtual APs, and AP system profiles and highlights the modified parameters.
Configuring the Session ACL
In the WebUI
1. Navigate to the Configuration > Security > Access Control > Policies page.
2. Click Add to create a new policy.
3. Enter the policy name in the Policy Name field.
4. From the Policy Type drop-down list, select IPv4 Session .
5. To create the first rule: a. Under Rules , click Add .
b. Under Source , select any .
ArubaOS 6.5.3.x
| User Guide Remote Access Points | 721
c. Under Destination , select any .
d. Under Service , select service . In the service drop-down list, select svc-dhcp .
e. Under Action , select permit .
f. Click Add .
6. To create the next rule: a. Under Rules , click Add .
b. Under Source , select any .
c. Under Destination , select any .
d. Under Service , select any .
e. Under Action , select route , and select the src-nat checkbox.
f. Click Add .
.
7. Click Apply .
If you use a local DHCP server to obtain IP addresses, you must define one additional ACL to permit traffic between clients without source NATing the traffic. Add user alias internal-network any permit before any any any route src-nat .
8. Click the User Roles tab.
a. Click Add .
b. Enter the Role Name.
c. Click Add under Firewall Policies.
d. In the Choose from Configured Policies menu, select the policy you just created.
e. Click Done .
In the CLI
Use the following commands:
(host) (config) #ip access-list session <policy> any any svc-dhcp permit any any any route src-nat
If you use a local DHCP server to obtain IP addresses, you must define one additional ACL to permit traffic between clients without source NATing the traffic. Add user alias internal-network any permit before any any any route src-nat:
(host) (config) #user-role <role> session-acl <policy>
Configuring the AAA Profile
In the WebUI
1. Navigate to the Security > Authentication > AAA Profiles page. From the AAA Profiles Summary list, click Add .
2. Enter the AAA profile name, then click Add .
3. Select the AAA profile that you just created: a. For Initial role, select the user role you just created.
b. For 802.1X Authentication Default Role, select the appropriate role for your remote AP configuration, then click Apply .
722 | Remote Access Points ArubaOS 6.5.3.x | User Guide
c. Under the AAA profile that you created, locate 802.1X Authentication Server Group , and select the authentication server group to use for your remote AP configuration, then click Apply .
If you need to create an 802.1X authentication server group, select new from the 802.1X Authentication Server
Group drop-down list, and enter the appropriate parameters.
d. Under the AAA profile that you created, locate 802.1X Authentication Profile , select the profile to use for your remote AP configuration, then click Apply .
In the CLI
(host) (config) #aaa profile <name> initial-role <role>
You can define other parameters as needed.
Defining the Backup Configuration
In the WebUI
1. Navigate to the Configuration > Wireless > AP Configuration page. Select either the AP Group or AP
Specific tab. Click Edit for the AP group or AP name.
2. Under Profiles , select Wireless LAN , then Virtual AP .
3. To create a new virtual AP profile in the WebUI, select New from the Add a profile drop-down menu. Enter the name for the virtual AP profile, and click Add .
Whenever you create a new virtual AP profile in the WebUI, the profile automatically contains the “default” SSID profile with the default ESSID. You must configure a new ESSID and SSID profile for the virtual AP profile before you apply the profile.
a. In the Profile Details entry for the new virtual AP profile, go to the AAA Profile drop-down list and select the previously configured AAA profile. The AAA Profile pop-up window appears.
b. To set the AAA profile and close the pop-up window, Click Apply.
c. In the Profile Details entry for the new virtual AP profile, select NEW from the SSID Profile drop-down menu. The SSID Profile pop-up window displays to allow you to configure the SSID profile.
d. Enter the name for the SSID profile.
e. Under Network , enter a name in the Network Name (SSID) field.
f. Under Security , select the network authentication and encryption methods.
g. To set the SSID profile and close the pop-up window, click Apply .
4. At the bottom of the Profile Details window, Click Apply .
5. Click the new virtual AP name in the Profiles list or the Profile Details to display configuration parameters.
6. Under Profile Details, do the following: a. Make sure Virtual AP enable is selected.
b. From the VLAN drop-down menu, select the VLAN ID to use for the Virtual AP profile.
c. From the Forward mode drop-down menu, select bridge .
d. From the Remote-AP Operation drop-down menu, select always or backup .
e. Click Apply .
7. Under Profiles , select AP , then AP system profile .
8. Under Profile Details , do the following: a. Select the AP system profile to edit.
b. At the LMS IP field, enter the LMS IP address.
ArubaOS 6.5.3.x
| User Guide Remote Access Points | 723
c. At the Master controller IP address field, enter the master controller IP address.
d. Configure the Remote-AP DHCP Server fields.
e. Click Apply .
In the CLI
Use the following commands:
(host) (config) #wlan ssid-profile <profile> essid <name> opmode <method> wpa-passphrase <string> (if necessary)
(host) (config) #wlan virtual-ap <name> ssid-profile <profile> vlan <vlan> forward-mode bridge aaa-profile <name> rap-operation {always|backup}
(host) (config) #ap system-profile <name> lms-ip <ipaddr> master-ip <ipaddr> rap-dhcp-default-router <ipaddr> rap-dhcp-dns-server <ipaddr> rap-dhcp-lease <days> rap-dhcp-pool-end <ipaddr> rap-dhacp-pool-netmask <netmask> rap-dhcp-pool-start <ipaddr> rap-dhcp-server-id <ipaddr> rap-dhcp-server-vlan <vlan>
(host) (config) #ap-group <name> virtual-ap <name> ap-system-profile <name> or
(host) (config) #ap-name <name> virtual-ap <name> ap-system-profile <name>
Specifying the DNS Controller Setting
In addition to specifying IP addresses for controllers, you can also specify the master DNS name for the controller when provisioning the remote AP. The name must be resolved to an IP address when attempting to set up the IPSec tunnel. For information on how to configure a host name entry on the DNS server, refer to the vendor documentation for your server. It is recommended to use a maximum of 8 IP addresses to resolve a controller name.
If the remote AP gets multiple IP addresses responding to a host name lookup, the remote AP can use one of them to establish a connection to the controller. For more detailed information, see the next section
Specifying the name also lets you move or change remote AP concentrators without reprovisioning your APs.
For example, in a DNS load-balancing model, the host name resolves to a different IP address depending on the location of the user. This allows the remote AP to contact the controller to which it is geographically closest.
The DNS setting is part of provisioning the AP. The easiest way to provision an AP is to use the Provisioning page in the WebUI. These instructions assume you are only modifying the controller information in the Master
Discovery section of the Provision page.
724 | Remote Access Points ArubaOS 6.5.3.x | User Guide
Reprovisioning the AP causes it to automatically reboot.
In the WebUI
1. Navigate to the Configuration > Wireless > AP Installation > Provisioning page. Select the remote AP and click Provision .
2. Under Master Discovery enter the master DNS name of the controller.
3. Click Apply and Reboot .
For more information, see
.
Backup Controller List
Using DNS, the remote AP receives multiple IP addresses in response to a host name lookup. Known as the backup controller list, remote APs go through this list to associate with a controller. If the primary controller is unavailable or does not respond, the remote AP continues through the list until it finds an available controller.
This provides redundancy and failover protection.
The remote AP loses the IP address information received through DNS when it terminates and receives the system profile configuration from the controller. If the remote AP loses connectivity on the IPSec tunnel to the controller, the RAP fails over from the primary controller to the backup controller. For this scenario, add the IP address of the backup controller in the backup LMS and the IP address of the primary controller in the LMS field of the ap-system profile. Network connectivity is lost during this time. As described in the section
controller when it becomes available. To complete this scenario, you must also configure the LMS IP address and the backup LMS IP address.
For example, assume you have two data centers, data center 1 and data center 2, and each data center has one master controller in the DMZ. You can provision the remote APs to use the controller in data center 1 as the primary controller, and the controller in data center 2 as the backup controller. If the remote AP loses connectivity to the primary, it will attempt to establish connectivity to the backup. You define the LMS parameters in the AP system profile.
Figure 103 Sample Backup Controller Scenario
ArubaOS 6.5.3.x
| User Guide Remote Access Points | 725
Configuring the LMS and backup LMS IP addresses
In the WebUI
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. Select either the AP Group or AP Specific tab. Click Edit for the AP group or AP name.
3. Under Profiles, select AP to display the AP profiles.
4. Select the AP system profile you want to modify.
5. Under Profile Details : a. At the LMS IP field, enter the primary controller IP address.
b. At the Backup LMS IP field, enter the backup controller IP address.
6. Click Apply .
In the CLI
(host) (config) #ap system-profile <profile> lms-ip <ipaddr> bkup-lms-ip <ipaddr>
(host) (config) #ap-group <group> ap-system-profile <profile>
(host) (config) #ap-name <name> ap-system-profile <profile>
Configuring Remote AP Failback
In conjunction with the backup controller list, you can configure remote APs to revert back (failback) to the primary controller if it becomes available. If you do not explicitly configure this behavior, the remote AP will keep its connection with the backup controller until the remote AP, controller, or both have rebooted or some type of network failure occurs. If any of these events occur, the remote AP will go through the backup controller list and attempt to connect with the primary controller.
In the WebUI
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. Select either the AP Group or AP Specific tab. Click Edit for the AP group or AP name.
3. Under Profiles , select AP to display the AP profiles.
4. Select the AP system profile you want to modify.
5. Under Profile Details : a. Click LMS Preemption . This is disabled by default.
b. At the LMS Hold-down period field, enter the amount of time the remote AP must wait before moving back to the primary controller.
6. Click Apply .
In the CLI
Use the following commands:
(host) (config) #ap system-profile <profile> lms-preemption lms-hold-down period <seconds>
726 | Remote Access Points ArubaOS 6.5.3.x | User Guide
Enabling RAP Local Network Access
You can enable local network access between the clients (from same or different subnets and VLANs) connected to a RAP through wired or wireless interfaces in split-tunnel/bridge forwarding modes. This allows the clients to effectively communicate with each other without routing the traffic via the controller. You can use WebUI or CLI to enable the local network access.
In the WebUI
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. Select the AP Group tab. Click Edit for the AP group or AP name.
3. Under Profiles , expand the AP menu, then select AP system profile .
4. To enable remote network access, select the Remote-AP Local Network Access check box.
Figure 104 Enable Remote AP Local Network Access
5. Click Apply .
In the CLI n
To enable, enter the following command: ap system-profile <ap-profile> rap-local-network-access n
To disable, enter the following command: ap system-profile <ap-profile> no rap-local-network-access
See the ArubaOS Command Line Reference Guide for detailed information on the command options.
Configuring Remote AP Authorization Profiles
Remote AP configurations include an authorization profile that specifies which profile settings should be assigned to a remote AP that has been provisioned but not yet authenticated at the remote site. These yetunauthorized APs are put into the temporary AP group authorization-group by default and assigned the predefined profile NoAuthApGroup . This configuration allows the user to connect to an unauthorized remote
AP via a wired port, then enter a corporate username and password. Once a valid user has authorized the AP, and it will be marked as authorized on the network. The remote AP will then download the configuration assigned to that AP by its permanent AP group.
In the WebUI
Adding or Editing a Remote AP Authorization Profile
To create a new authorization profile or edit an existing authorization profile via the WebUI:
1. Select Configuration > All Profiles . The All Profile Management window opens.
2. Select AP to expand the AP profile menu.
ArubaOS 6.5.3.x
| User Guide Remote Access Points | 727
3. Select AP Authorization Profile . The Profile Details pane appears and displays the list of existing AP authorization profiles.
n
To edit an existing profile, select a profile from the Profile Details pane.
n
To create a new authorization profile, enter a new profile name in the entry blank on the Profile Details pane, then click Add .
4. The Profile Details window will display the AP group currently defined for that authorization profile. To select a new AP group, click the drop-down list and select a different AP group name.
5. Click Apply .
In the CLI
To create a new authorization profile or edit an existing authorization profile via the command-line interface, access the command-line interface in enable mode, and issue the following commands.
(host) (config) #ap authorization-profile <profile> authorization-group <ap-group>
Working with Access Control Lists and Firewall Policies
Remote APs support the following access control lists (ACLs); unless otherwise noted, you apply these ACLS to user roles: n n n n
Standard ACLs—Permit or deny traffic based on the source IP address of the packet.
Ethertype ACLs—Filter traffic based on the Ethertype field in the frame header.
MAC ACLs—Filter traffic on a specific source MAC address or range of MAC addresses.
Firewall policies (session ACLs)—Identifies specific characteristics about a data packet passing through the
Aruba controller and takes some action based on that identification. You apply these ACLs to user roles or uplink ports.
To configure firewall policies, you must install the PEFNG license.
For more information about ACLs and firewall policies, see
Configuring Fallback Mode on page 717 .
Understanding Split Tunneling
The split tunneling feature allows you to optimize traffic flow by directing only corporate traffic back to the controller, while local application traffic remains local. This ensures that local traffic does not incur the overhead of the round trip to the controller, which decreases traffic on the WAN link and minimizes latency for local application traffic. This is useful for sites that have local servers and printers. With split tunneling, a remote user associates with a single SSID, not multiple SSIDs, to access corporate resources (for example, a mail server) and local resources (for example, a local printer). The remote AP examines session ACLs to distinguish between corporate traffic destined for the controller and local traffic.
728 | Remote Access Points ArubaOS 6.5.3.x | User Guide
Figure 105 Sample Split Tunnel Environment
displays corporate traffic is GRE tunneled to the controller through a trusted tunnel and local traffic is source NATed and bridged on the wired interface based on the configured user role and session ACL.
Configuring Split Tunneling
The procedure to configure split tunneling requires the following steps. Each step is described in detail later in this chapter.
The split tunneling feature requires the PEFNG license. If you do not have the PEFNG license on your controller, you must install it before you configure split tunneling. For details on installing licenses, see
.
1. Define a session ACL that forwards only corporate traffic to the controller.
a. Configure a net destination for the corporate subnets.
b. Create rules to permit DHCP and corporate traffic to the corporate controller.
c. Apply the session ACL to a user role.
2. (Optional) Configure an ACL that restricts remote AP users from accessing the remote AP local debugging homepage.
3. Configure the remote AP’s AAA profile.
a. Specify the authentication method ( 802.1X
or PSK ) and the default user role for authenticated users.
The user role specified in the AAA profile must contain the session ACL defined in the previous step.
b. (Optional) Use the remote AP’s AAA profile to enable RADIUS accounting.
4. Configure the virtual AP profile: a. Specify which AP group or AP to which the virtual AP profile applies.
b. set the VLAN used for split tunneling. Only one VLAN can be configured for split tunneling; VLAN pooling is not allowed.
c. When specifying the use of a split tunnel configuration, use “split-tunnel” forward mode.
d. Create and apply the applicable SSID profile.
When creating a new virtual AP profile In the WebUI, you can also configure the SSID at the same time. For information about AP profiles, see
Understanding AP Configuration Profiles on page 530 .
5. (Optional) Create a list of network names resolved by corporate DNS servers.
ArubaOS 6.5.3.x
| User Guide Remote Access Points | 729
Configuring the Session ACL Allowing Tunneling
First you need to configure a session ACL that “permits” corporate traffic to be forwarded (tunneled) to the controller, and that routes, or locally bridges, local traffic.
In the WebUI
1. Navigate to the Configuration > Security > Access Control > Policies page.
2. Click Add to create a new policy.
3. Enter the policy name in the Policy Name field.
4. From the Policy Type drop-down list, select Session .
5. From the IP Version drop-down list, select IPv4 or IPv6 .
6. To create the first rule: a. Under Rules, click Add .
b. Under Source, select any .
c. Under Destination, select any .
d. Under Service, select service . In the service drop-down list, select svc-dhcp .
e. Under Action, select permit forIPv4 or captive for IPv6.
f. Click Add .
7. To create the next rule: a. Under Rules, click Add .
b. Under Source, select any .
c. Under Destination, select alias .
The following steps define an alias representing the corporate network. Once defined, you can use the alias for other rules and policies. You can also create multiple destinations the same way.
8. Under the alias section, click New . Enter a name in the Destination Name field.
a. Click Add .
b. For Rule Type, select Network .
c. Enter the public IP address of the controller.
d. Enter the Network Mask/Range.
e. Click Add to add the network range.
f. Click Apply . The new alias appears in the Destination menu.
9. Under Destination , select the alias you just created.
10.Under
Service , select any .
11.Under
Action , select permit for IPv4 or captive for IPv6.
12.Click
Add .
13.To create the next rule: a. Under Rules , click Add .
b. Under Source , select user .
c. Under Destination , select any .
d. Under Service , select any .
e. Under Action , select route and check src-nat .
f. Click Add .
14.Click
Apply .
15.Click the User Roles tab.
730 | Remote Access Points ArubaOS 6.5.3.x | User Guide
a. Click Add to create and configure a new user role.
b. Enter the desired name for the role in the Role Name field.
c. Under Firewall Policies , click Add .
d. From the Choose from Configured Policies drop-down menu, select the policy you just configured.
e. Click Done .
16.Click
Apply .
In the CLI
(host) (config) #ap system-profile <profile> lms-preemption lms-hold-down period <seconds>netdestination <policy> network <ipaddr> <netmask> network <ipaddr> <netmask>
(host) (config) #ip access-list session <policy> any any svc-dhcp permit any alias <name> any permit user any any route src-nat
(host) (config) #user-role <role> session-acl <policy>
When defining the alias, there are a number of other session ACLs that you can create to define the handling of local traffic, such as:
(host) (config) #ip access-list session <policy> user alias <name> any redirect 0 user alias <name> any route user alias <name> any route src-nat
Configuring an ACL to Restrict Local Debug Homepage Access
A user in split or bridge role using a remote AP (RAP) can log on to the local debug (LD) homepage (for example,
( http://rapconsole.arubanetworks.com
) and perform a reboot or reset operations. The LD homepage provides various information about the RAP and also has a button to reboot the RAP. You can now restrict a RAP user from resetting or rebooting a RAP by using the localip keyword in the in the user role ACL.
You will require the PEFNG license to use this feature. See
for more information on licensing requirements.
Any user associated to that role can be allowed or denied access to the LD homepage. You can use the localip keyword in the ACL rule to identify the local IP address on the RAP. The localip keyword identifies the set of all local IP addresses on the system to which the ACL is applied. The existing keywords controller and mswitch indicate only the primary IP address on the controller.
This release of ArubaOS provides localip keyword support only for RAP and not for controller.
In the WebUI
1. Navigate to the Configuration > Security > Access Control > Policies page.
2. Click Add to create a new policy.
3. Enter the policy name in the Policy Name field.
4. From the Policy Type drop-down list, select IPv4 Session .
5. To create the first rule:
ArubaOS 6.5.3.x
| User Guide Remote Access Points | 731
a. Under Rules , click Add .
b. Under Source , select localip .
c. Under Destination , select any .
d. Under Action , select permit .
e. Click Apply .
Figure 106 Enable Restricted Access to LD Homepage
In the CLI
Use the localip keyword in the user role ACL.
All users have an ACL entry of type any any deny by default. This rule restricts access to all users. When the
ACL is configured for a user role, if a user any permit
ACL rule is configured, add a deny ACL before that for localip for restricting the user from accessing the LD homepage.
Example:
(host) (config) #ip access-list session logon-control user localip svc-http deny user any permit
Configuring the AAA Profile for Tunneling
After you configure the session ACL, you define the AAA profile used for split tunneling. When defining the AAA parameters, specify the previously configured user role that contains the session ACL used for split tunneling.
If you enable RADIUS accounting in the AAA profile, the controller sends a RADIUS accounting start record to the RADIUS server when a user associates with the remote AP, and sends a stop record when the user logs out or is deleted from the user database. If you enable interim accounting, the controller sends updates at regular intervals. Each interim record includes cumulative user statistics, including received bytes and packets counters. For more information on RADIUS accounting, see
In the WebUI
1. Navigate to the Security > Authentication > AAA Profiles page. From the AAA Profiles Summary list, click
Add .
2. Enter the AAA profile name, then click Add .
3. Select the AAA profile that you just created.
a. For 802.1X Authentication Default Role , select the user role you previously configured for split tunneling, then click Apply .
b. Under the AAA profile that you created, locate 802.1X Authentication Server Group , and select the authentication server group to use, then click Apply .
4. (Optional) To enable RADIUS accounting:
732 | Remote Access Points ArubaOS 6.5.3.x | User Guide
a. Select the AAA profile from the profile list to display the list of authentication and accounting profiles associated with the AAA profile.
b. Select the Radius Accounting Server Group profile associated with the AAA profile. Click the RADIUS
Accounting Server Group drop-down list to select a RADIUS server group. (For more information on configuring a RADIUS server or server group, see
Configuring a RADIUS Server on page 180 .)
c. To enable RADIUS Interim Accounting, select the AAA profile name from the profile list, then click the
RADIUS Interim Accounting checkbox. This option is disabled by default, allowing the controller to send only start and stop messages to the RADIUS accounting server.
5. Click Apply .
If you need to create an authentication server group, select new and enter the appropriate parameters.
In the CLI
(host) (config) #aaa profile <name> authentication-dot1x <dot1x-profile> dot1x-default-role <role> dot1x-server-group <group> radius-accounting <group> radius-interim-accounting
Configuring the Virtual AP Profile
In the WebUI
1. Navigate to Configuration > Wireless > AP Configuration page. Select either the AP Group or AP
Specific tab. Click Edit for the applicable AP group name or AP name.
2. Under Profiles , select Wireless LAN , then Virtual AP .
3. To create a new virtual AP profile in the WebUI, select New from the Add a profile drop-down menu. Enter the name for the virtual AP profile, and click Add .
Whenever you create a new virtual AP profile in the WebUI, the profile automatically contains the “default” SSID profile with the default ESSID. You must configure a new ESSID and SSID profile for the virtual AP profile before you apply the profile.
a. In the Profile Details entry, go to the AAA Profile drop-down list and select the previously configured
AAA profile. The AAA Profile pop-up window appears.
b. To set the AAA profile and close the window, click Apply .
c. In the Profile Details entry for the new virtual AP profile, select NEW from the SSID Profile drop-down menu. A pop-up window displays to allow you to configure the SSID profile.
d. Enter the name for the SSID profile.
e. Under Network , enter a name in the Network Name (SSID) field.
f. Under Security , select the network authentication and encryption methods.
g. To set the SSID profile and close the window, click Apply .
4. Click Apply at the bottom of the Profile Details window.
5. Click the new virtual AP name in the Profiles list or the Profile Details to display configuration parameters.
6. Under Profile Details : a. Make sure Virtual AP enable is selected.
b. From the VLAN drop-down menu, select the VLAN ID for the VLAN to be used for split tunneling.
c. From the Forward mode drop-down menu, select split-tunnel .
d. Click Apply .
ArubaOS 6.5.3.x
| User Guide Remote Access Points | 733
In the CLI
(host) (config) #wlan ssid-profile <profile> essid <name> opmode <method>
(host) (config) #wlan virtual-ap <profile> ssid-profile <name> forward-mode <mode>
(host) (config) # vlan <vlan id> aaa-profile <profile>
(host) (config) #ap-group <name> virtual-ap <profile> or
(host) (config) #ap-name <name> virtual-ap <profile>
Defining Corporate DNS Servers
Clients send DNS requests to the corporate DNS server address that it learned from DHCP. If configured for split tunneling, corporate domains and traffic destined for corporate use the corporate DNS server. For noncorporate domains and local traffic, other DNS servers can be used.
In the WebUI
1. Navigate to Configuration > Wireless > AP Configuration page.
2. Select either the AP Group or AP Specific tab. Click Edit for the AP group or AP name.
3. Under Profiles, select AP , then AP system profile .
4. Under Profile Details : a. Enter the corporate DNS servers.
b. Click Add .
The DNS name appears in Corporate DNS Domain list. You can add multiple names the same way.
5. Click Apply .
In the CLI
(host) (config) #ap system-profile <profile> dns-domain <domain name>
Understanding Bridge
The bridge feature allows you to route the traffic flow only to the internet and not to the corporate network.
Only the 802.1X authentication request is sent to the corporate network. This feature is useful for guest users.
ArubaOS does not support Wired 802.1X authentication in bridge mode for RAP and CAP. 802.1X authentication is supported only in tunnel and split modes.
734 | Remote Access Points ArubaOS 6.5.3.x | User Guide
Figure 107 Sample Bridge Environment
displays the local traffic being routed to the internet and the 802.1X authentication request sent to the corporate network.
Configuring Bridge
To configure a bridge, perform the following steps. Each step is described in detail later in this chapter.
The bridge feature requires the PEFNG license. If you do not have the PEFNG license on your controller, you must install it before you configure bridge. For details on installing licenses, see
Software Licenses on page 78 .
1. Define a session ACL that routes the traffic.
a. Create rules to permit DHCP and local data traffic.
b. Apply the session ACL to a user role. For information about user roles and policies, see
Roles and Policies on page 381
.
2. Configure the remote AP’s AAA profile.
a. Specify the authentication method ( 802.1X
or PSK ) and the default user role for authenticated users.
The user role specified in the AAA profile must contain the session ACL defined in the previous step.
b. (Optional) Use the remote AP’s AAA profile to enable RADIUS accounting.
3. Configure the virtual AP profile: a. Specify the AP group or ap-name to which the virtual AP profile applies.
b. Set the VLAN in the virtual AP.
c. When specifying the use of a bridge configuration, use bridge forward mode.
d. Create and apply the applicable SSID profile.
e. (Optional) Under AP system profile, configure the RAP DHCP pool. RAP DHCP VLAN must be same as
VAP's VLAN. If the client needs to obtain from the RAP DHCP Server.
When creating a new virtual AP profile In the WebUI, you can simultaneously configure the SSID. For information about AP profiles, see
Understanding AP Configuration Profiles on page 530
.
Configuring the Session ACL
First you need to configure a session ACL that “permits” corporate traffic to be forwarded to the controller and that routes, or locally bridges, local traffic.
In the WebUI
1. Navigate to the Configuration > Security > Access Control > Policies page.
ArubaOS 6.5.3.x
| User Guide Remote Access Points | 735
2. Click Add to create a new policy.
3. Enter the policy name in the Policy Name field.
4. From the Policy Type drop-down list, select Session .
5. From the IP Version drop-down list, select IPv4 or IPv6 .
6. To create the first rule: a. Under Rules , click Add .
b. Under Source , select any .
c. Under Destination , select any .
d. Under Service , select service . In the service drop-down list, select svc-dhcp .
e. Under Action , select permit for IPv4 or captive for IPv6.
f. Click Add .
7. To create the next rule: a. a. Under Rules, click Add .
b. b. Under Source, select any .
c. c. Under Destination, select alias .
The following steps define an alias representing the corporate network. Once defined, you can use the alias for other rules and policies. You can also create multiple destinations the same way.
8. Under the alias section, click New . Enter a name in the Destination Name field.
a. Click Add .
b. For Rule Type, select Network .
c. Enter the public IP address of the controller.
d. Enter the Network Mask/Range.
e. Click Add to add the network range.
f. Click Apply . The new alias appears in the Destination menu.
9. Under Destination , select the alias you just created.
10.Under
Service , select any .
11.Under
Action , select permit for IPv4 or captive for IPv6.
12.Click
Add .
13.To create the next rule: a. Under Rules , click Add .
b. Under Source , select user .
c. Under Destination , select any .
d. Under Service , select any .
e. Under Action , select any and check src-nat .
f. Click Add .
14.Click
Apply .
15.Click the User Roles tab.
a. Click Add to create and configure a new user role.
b. Enter the desired name for the role in the Role Name field.
c. Under Firewall Policies , click Add .
d. From the Choose from Configured Policies drop-down menu, select the policy you just configured.
e. Click Done .
736 | Remote Access Points ArubaOS 6.5.3.x | User Guide
16.Click
Apply .
In the CLI
If dhcp server in ap system profile is enabled
(host) (config) #ip access-list session <policy> any any svc-dhcp permit
(host) (config) #user any any route src-nat
If dhcp server in ap system profile is disabled
(host) (config) #ip access-list session <policy>
(host) (config) #any any any permit
(host) (config) #user-role <role> session-acl <policy>
To configure an ACL to Restrict Local Debug Homepage Access, see
Configuring an ACL to Restrict Local Debug
Configuring the AAA Profile for Bridge
After you configure the session ACL, you define the AAA profile used for bridge. When defining the AAA parameters, specify the previously configured user role that contains the session ACL used for bridge.
If you enable RADIUS accounting in the AAA profile, the controller sends a RADIUS accounting start record to the RADIUS server when a user associates with the remote AP, and sends a stop record when the user logs out or is deleted from the user database. If you enable interim accounting, the controller sends updates at regular intervals. Each interim record includes cumulative user statistics, including received bytes and packets counters. For more information on RADIUS accounting, see
.
In the WebUI
1. Navigate to the Security > Authentication > AAA Profiles page. From the AAA Profiles Summary list, click Add .
2. Enter the AAA profile name, then click Add .
3. Select the AAA profile that you just created.
a. For 802.1X Authentication Default Role , select the user role you previously configured for split tunneling or bridge, then click Apply .
b. Under the AAA profile that you created, locate 802.1X Authentication Server Group , and select the authentication server group to use, then click Apply .
4. (Optional) To enable RADIUS accounting: a. Select the AAA profile from the profile list to display the list of authentication and accounting profiles associated with the AAA profile.
b. Select the Radius Accounting Server Group profile associated with the AAA profile. Click the RADIUS
Accounting Server Group drop-down list to select a RADIUS server group . (For more information on configuring a RADIUS server or server group, see
Configuring a RADIUS Server on page 180 .)
c. To enable RADIUS Interim Accounting , select the AAA profile name from the profile list, then click the RADIUS Interim Accounting checkbox. This option is disabled by default, allowing the controller to send only start and stop messages RADIUS accounting server.
5. Click Apply .
If you need to create an authentication server group, select new and enter the appropriate parameters.
In the CLI
Use the following command:
(host) (config) #aaa profile <name>
ArubaOS 6.5.3.x
| User Guide Remote Access Points | 737
(host) (config) #authentication-dot1x <dot1x-profile>
(host) (config) #dot1x-default-role <role>
(host) (config) #dot1x-server-group <group>
(host) (config) #radius-accounting <group>
(host) (config) #radius-interim-accounting
Configuring Virtual AP Profile
In the WebUI
1. Navigate to Configuration > Wireless > AP Configuration page . Select either the AP Group or AP
Specific tab. Click Edit for the applicable AP group name or AP name.
2. Under Profiles , select Wireless LAN , then Virtual AP .
3. To create a new virtual AP profile in the WebUI, select New from the Add a profile drop-down menu. Enter the name for the virtual AP profile, and click Add .
Whenever you create a new virtual AP profile in the WebUI, the profile automatically contains the “default” SSID profile with the default ESSID. You must configure a new ESSID and SSID profile for the virtual AP profile before you apply the profile.
a. In the Profile Details entry, go to the AAA Profile drop-down list and select the previously configured
AAA profile. The AAA Profile pop-up window appears.
b. To set the AAA profile and close the window, click Apply .
c. In the Profile Details entry for the new virtual AP profile, select NEW from the SSID Profile drop-down menu. A pop-up window displays to allow you to configure the SSID profile.
d. Enter the name for the SSID profile.
e. Under Network , enter a name in the Network Name (SSID) field.
f. Under Security , select the network authentication and encryption methods.
g. To set the SSID profile and close the window, click Apply .
4. Click Apply at the bottom of the Profile Details window.
5. Click the new virtual AP name in the Profiles list or the Profile Details to display configuration parameters.
6. Under Profile Details : a. Make sure Virtual AP enable is selected.
b. From the VLAN drop-down menu, select the VLAN ID for the VLAN to be used for bridge.
c. From the Forward mode drop-down menu, select Bridge .
d. Click Apply .
In the CLI
Use the following command:
(host) (config) #wlan ssid-profile <profile> essid <name>
(host) (config) #opmode <method>
(host) (config) #wlan virtual-ap <profile>
(host) (config) #ssid-profile <name>
(host) (config) #forward-mode bridge
(host) (config) #vlan <vlan id>
(host) (config) #aaa-profile <profile>
(host) (config) #ap-group <name>
(host) (config) #virtual-ap <profile> or
738 | Remote Access Points ArubaOS 6.5.3.x | User Guide
(host) (config) #ap-name <name>
(host) (config) #virtual-ap <profile>
Provisioning Wi-Fi Multimedia
Wi-Fi Multimedia (WMM) is a Wi-Fi Alliance specification based on the IEEE 802.11e wireless Quality of Service
(QoS) standard. WMM works with 802.11a, b, g, and n physical layer standards. The IEEE 802.11e standard also defines the mapping between WMM access categories (ACs) and Differentiated Services Codepoint (DSCP) tags. Remote APs support WMM.
WMM supports four ACs: voice, video, best effort, and background. You apply and configure WMM in the SSID profile.
When planning your configuration, make sure that immediate switches or routers do not have conflicting
802.1p or DSCP configurations/mappings. If this occurs, your traffic may not be prioritized correctly.
Reserving Uplink Bandwidth
You can reserve and prioritize uplink bandwidth traffic to provide higher QoS for specific applications, traffic, or ports. This is done by applying bandwidth reservation on existing session ACLs. Typically, the bandwidth reservation is applied for uplink voice traffic.
Note the following before you configure bandwidth reservation: n n n n n n
You must know the total bandwidth available.
The bandwidth reservation are applicable only on session ACLs.
Bandwidth reservation on voice traffic ACLs receives higher priority over other reserved traffic.
You can configure up to three unique priority for bandwidth reservation.
The bandwidth reservation must be specified in absolute value (kbps).
Priorities for bandwidth reservation are optional, and bandwidth reservations without priorities are treated equal.
Understanding Bandwidth Reservation for Uplink Voice Traffic
The voice ACLs are applicable on the voice signaling traffic used to establish voice call through a firewall. When a voice ACL is executed, a dynamic session is introduced to allow voice traffic through the firewall. This prevents the re-use of voice ACLs for bandwidth reservation. However, you can create bandwidth reservation rules that can be applied on voice signaling traffic and ports used for voice data traffic. This mechanism filters traffic as per the security requirements.
Configuring Bandwidth Reservation
You can configure bandwidth reservation ACLs using the WebUI or the CLI.
In the WebUI
To configure bandwidth reservation
1. Navigate to Configuration > Advanced Services > All Profiles
2. Under Profiles , navigate to AP > AP System Profile . You can create a new AP system profile to configure bandwidth reservation or edit an existing AP system profile. Under the Profiles Details page, specify bandwidth reservation values.
ArubaOS 6.5.3.x
| User Guide Remote Access Points | 739
Figure 108 Uplink Bandwidth Reservation
In the CLI
(host) (config)#ap system-profile remotebw
(host) (AP system profile "remotebw") #rap-bw-total 1024
(host) (AP system profile "remotebw") #rap-bw-resv-1 acl voice 128 priority 1
To view bandwidth reservations:
(host) #show datapath rap-bw-resv ap-name remote-ap-1
Provisioning 4G USB Modems on Remote Access Points
ArubaOS provides support for 4G networks by allowing you to provision 4G USB modems on the RAP. You can also provision the RAP to support both 4G and 3G USB modems. This enables the RAP to choose the available network automatically. 4G takes precedence over 3G when the RAP tries to auto select the network. You can also configure the RAP to work exclusively on a 3G or 4G network. It is recommended that you provision the
USB modems for the RAP based on your network requirements.
4G USB Modem Provisioning Best Practices and Exceptions
n n n
RAP does not support dynamic plug-and-play for the 4G USB modems. You must provision a RAP with the
4G USB parameters on the controller manually based on its type and family (4G-WiMAX/4G-LTE).
When a RAP connects to a 4G network, it appears as a Remote AP (R) and Cellular (C) on the controller.
For a 3G/4G network switch, using the UML290 modem with the firmware version L0290VWB522F.242 or later is recommended. Using a lower version of the firmware auto-selects the network mode based on the network availability. The latest version allows the RAP to lock the modem in a particular network mode (for example, 3G only).
The 4G-WiMAX family of modems do not support the 3G-4G network switch-over functionality.
ArubaOS 6.3 includes a new method of provisioning multimode USB modems (such as a Verizon UML290,
Verizon MC551L, or AT&T 313u) for a remote AP. These changes simplify modem provisioning for both 3G and
4G networks. The modem configuration procedure in ArubaOS 6.2.0.x and earlier versions required that you define a driver for a 3G modem in the USB modem field under the AP provisioning profile, or define a driver for a 4G modem in the 4G USB type field. Starting with ArubaOS 6.3, you can configure drivers for both a 3G or a
4G modem using the USB field, and the 4G USB Type field is deprecated.
740 | Remote Access Points ArubaOS 6.5.3.x | User Guide
Provisioning RAP for USB Modems
To enable 3G/4G network support, you must provision the RAP with the USB parameters on the controller.
You can use the WebUI or CLI to provision the USB parameters.
In the WebUI
1. Navigate to the Configuration > Wireless > AP Installation page.
2. Select the Provisioning tab.
3. Select an AP and click Provision .
4. Select the Yes option by Remote AP .
5. Under USB Settings , select the USB Parameters check box.
6. Click the Device drop-down list and select a USB modem device.
7. Click the Cellular NW Preferences drop-down list and select one of the following provisioning options.
Table 162: Cellular Network Preference Parameters
Parameter Description auto (default) In this mode, the modem firmware will control the cellular network service selection; so the cellular network service failover and fallback is not interrupted by the remote AP (RAP).
3g_only
4g_only advanced
Locks the modem to operate only in 3G .
Locks the modem to operate only in 4G .
The RAP controls the cellular network service selection based on an Received Signal
Strength Indication (RSSI) threshold-based approach.
n n n
Initially the modem is set to the default auto mode. This allows the modem firmware to select the available network.
The RAP determines the RSSI value for the available network type (for example 4G), checks whether the RSSI is within required range, and if so, connects to that network.
If the RSSI for the modem’s selected network is not within the required range, the RAP will then check the RSSI limit of an alternate network (for example, 3G), and reconnect to that alternate network. The RAP will repeat the above steps each time it tries to connect using a 4G multimode modem in this mode.
8. Click Apply and Reboot to reboot the RAP with the new configuration.
In the CLI
To enable 4G-exclusive network support on the RAP, execute the following commands:
(host) (config) #ap provisioning-profile <profile-name>
(host) (Provisioning profile "<profile-name>") usb-type <USB modem type>
(host) (Provisioning profile "<profile-name>") #usb-type none
(host) (Provisioning profile "<profile-name>") #cellular_nw_preference 4g_only
To enable 3G-exclusive network support on the RAP, execute the following commands:
(host) (config) #ap provisioning-profile <profile-name>
(host) (Provisioning profile "<profile-name>") usb-type <USB modem type>
(host) (Provisioning profile "<profile-name>") #usb-type none
(host) (Provisioning profile "<profile-name>") #cellular_nw_preference 3g_only
To enable 3G/4G network switch support, execute the following commands:
(host) (config) #ap provisioning-profile <profile-name>
(host) (Provisioning profile "<profile-name>") usb-type <USB modem type>
(host) (Provisioning profile "<profile-name>") #usb-type none
ArubaOS 6.5.3.x
| User Guide Remote Access Points | 741
(host) (Provisioning profile "<profile-name>") #cellular_nw_preference auto
RAP 3G/4G Backhaul Link Quality Monitoring
The RAP is enhanced to support link monitoring on 2G, 3G, and 4G modems to provide information about the state of USB modem and cellular network.
The USB modem has the following four states: n n n n
Active - The USB modem is used as the primary path for connecting VPN to the controller
Standby or Backup - The network is available but the USB modem is not used for connecting VPN to the controller
Error - The USB modem is available but the modem is faulty
Not Plugged - The USB modem is unavailable
To view the USB modem details on the RAP, execute the following command:
(host) #show ap debug usb ap-name <ap-name>
Provisioning RAPs at Home
The following section provides information on provisioning your remote AP (RAP) at home using a static IP address, PPPoE connection, or USB modem.
Prerequisites
Follow the steps below to acquire a static IP address before provisioning the RAP at home:
1. Connect the RAP at the site of deployment and ensure that it has connectivity to the Internet to reach the controller.
2. Connect a laptop to Port 1 of the RAP to get an IP address from the RAP's internal DHCP pool.
Provisioning RAP Using Zero Touch Provisioning
You provision the RAP using provisioning wizard:
1. Navigate to the RAP configuration URL: http://rapconsole.arubanetworks.com
.
2. Enter the IP address or hostname of the controller.
3. Click the Show Advanced Settings link, shown in
Figure 109 Show Advanced Settings
4. In the Advanced Settings wizard, you can select one of the following: a.
Static IP —Select this tab to provision your RAP using a static IP address.
b.
PPPoE —Select this tab to provision your RAP on a PPPoE connection.
c.
USB —Select this tab to provision your RAP using 3G/EVDO USB modem.
742 | Remote Access Points ArubaOS 6.5.3.x | User Guide
Provisioning the RAP using a Static IP Address
Select the Static IP tab and enter the required details. See
for information on parameters.
Figure 110 Provision RAP using Static IP
Table 163: Provision using Static IP
Parameter Description
IP Address
Netmask
Gateway
Primary DNS
Domain
Enter the static IP address that you want to configure for your remote access point.
Enter the network mask.
Enter the default gateway IP address of your network.
Enter the IP address of your primary DNS server. This is an optional parameter.
Enter your domain name. This is an optional parameter.
Click Save after you have entered all the details.
Provision the RAP on a PPPoE Connection
Select the PPPoE tab and enter the required details. See
for information on parameters.
Figure 111 Provision RAP on a PPPoE Connection
ArubaOS 6.5.3.x
| User Guide Remote Access Points | 743
Table 164: Provision using PPPoE Connection
Parameter
Service Name
Description
Username
Password
Enter the PPPoE service name provided to you by your service provider. This parameter is optional.
Enter the user name for the PPPoE connection.
Enter your PPPoE password.
Click Save after you have entered all the details.
Using 3G/EVDO USB Modems
The following procedure illustrates provisioning your RAP using a 3G/EVDO USB modem.
1. Select the USB tab and select your modem from the drop down list. Configuration details automatically appear for some common modems.
Figure 112 Provision using a preconfigured USB Modem
2. If your modem name is not listed, select Other and manually enter the following details. These are available from the manufacturer of your modem or from your IT administrator:
744 | Remote Access Points ArubaOS 6.5.3.x | User Guide
Figure 113 Provision using a USB Modem with Custom Settings n n n n n n
Device Type
Initializing String
PPP Username
PPP Password
TTY Device Path
Device Identifier n n
Dial String
Link Priority Cellular—This is a number that identifies the priority of the connection. If the Link Priority
Cellular has a higher number than Link Priority Ethernet , then cellular connection is used.
n
Link Priority Ethernet—This is a number that identifies the priority of the connection. If the Link Priority
Ethernet has a higher number than Link Priority Cellular , then Ethernet connection is used.
3. Click Save after you have entered all the details and click Continue to complete provisioning of your RAP.
Configuring RAP-3WN and RAP-3WNP Access Points
The ArubaRAP-3WN and RAP-3WNP are single-radio, single-band wireless APs that support the IEEE 802.11n
standard for high-performance WLAN. These APs use MIMO (Multiple-In, Multiple-Out) technology and other high-throughput mode techniques to deliver high-performance, 802.11n 2.4 GHz functionality while simultaneously supporting existing 802.11 b/g wireless services.
See the Aruba RAP-3WN Installation Guide for more information.
These access points require Aruba Instant 3.0 or later to operate as an Instant AP, or ArubaOS 6.1.4.0 or later to operate as a Remote AP.
The Power Sourcing Equipment (PSE) functionality is available only for RAP-3WNP APs, as the PoE itself provides the PSE functionality for RAP-3WN APs. You can use the WebUI or CLI to enable or disable the PSE functionality on the RAP-3WNP APs.
ArubaOS 6.5.3.x
| User Guide Remote Access Points | 745
In the WebUI
1. Navigate to the Configuration > Advanced Services > All Profiles page.
2. Select the AP tab, then the AP Ethernet Link profile tab.
3. Select the default tab .
4. Select the Power over Ethernet checkbox.
5. Click Apply . Support for RAP-3WN and RAP-3WNP access points (APs)
In the CLI n
To enable, enter:
(host)(config) #ap enet-link-profile <name> poe n
To disable, enter:
(host)(config) #ap enet-link-profile <name> no poe
Use the following command to view the PoE port status on an AP:
(host) #show ap enet-link-profile default
Converting an IAP to RAP or CAP
For IAP to RAP or CAP conversion, the virtual controller sends the convert command to all the other IAPs. The virtual controller along with the other slave IAPs then set up a VPN tunnel to the remote controller, and download the firmware by FTP. The Virtual Controller uses IPsec to communicate to the controller over the internet.
A mesh point cannot be converted to RAP because mesh does not support VPN connection.
An IAP can be converted to a Campus AP and Remote AP only if the controller is running ArubaOS 6.1.4 or later.
The following table describes the supported IAP platforms and minimal AOS version for IAP to CAP/RAP conversion.
Converting IAP to RAP
To convert an IAP to RAP, follow the instructions below:
1. Navigate to the Maintenance tab in the top right corner of the Instant UI.
2. Click the Conver t tab.
3. Select Remote APs managed by a Controller from the drop-down list.
4. Enter the hostname (fully qualified domain name) or the IP address of the controller in the Hostname or
IP Address of Controller text box. This information is provided by your network administrator.
Ensure the Controller IP Address is reachable by the IAPs.
5. Click Convert Now to complete the conversion.
6. The IAP reboots and begins operating in RAP mode.
7. After conversion, the IAP is managed by the Aruba controller which has been specified in the Instant UI.
746 | Remote Access Points ArubaOS 6.5.3.x | User Guide
In order for the RAP conversion to work, ensure that you configure the Instant AP in the RAP white-list and enable the
FTP service on the controller.
If the VPN setup fails and an error message pops up, please click OK, copy the error logs and share them with your
Aruba support engineer.
Converting an IAP to CAP
To convert an IAP to a Campus AP, do the following:
1. Navigate to the Maintenance tab in the top right corner of the Instant UI.
2. Click the Convert tab.
3. Select Campus APs managed by a Controller from the drop-down list.
4. Enter the hostname (fully qualified domain name) or the IP address of the controller in the Hostname or
IP Address of Controller text box. This is provided by your network administrator.
Ensure that the Controller IP Address is reachable by the APs.
5. Click Convert Now to complete the conversion.
Enabling Bandwidth Contract Support for RAPs
This release of ArubaOS provides Bandwidth Contract support on remote APs. This is achieved by extending the Bandwidth Contract support on split-tunnel and bridge modes.
You can apply Bandwidth Contract for a RAP on a per-user or per-role basis. Bandwidth Contract is applied on a per-role basis by default. This implies that all the users belonging to the same role will share the bandwidth pool. When Bandwidth Contract configured on the controller is attached to a user-role, it automatically gets pushed to the RAPs terminating on it.
The following show commands have been enhanced in this release to retrieve the Bandwidth Contract information from the RAP: show datapath user ap-name <ap-name> show datapath bwm ap-name <ap-name>
Configuring Bandwidth Contracts for RAP
You can configure bandwidth contracts for RAP on a per-role or per-user basis. The following examples illustrate how to configure, apply, and verify the Bandwidth Contracts on the RAPs.
Defining Bandwidth Contracts
Use the following command to define a 256 Kbps contract:
(host) (config) #aaa bandwidth-contract 256k kbits 256
Use the following command to define a 512 Kbps contract
(host) (config) #aaa bandwidth-contract 512k kbits 512
Applying Contracts
You can apply the contract on a per-role or per-user basis.
Applying Contracts Per-Role
Use the following commands to apply the contracts on a per-role basis for upstream and downstream:
ArubaOS 6.5.3.x
| User Guide Remote Access Points | 747
For upstream contract of 512 Kbps:
(host) (config) #user-role authenticated bw-contract 512k upstream
For downstream contract of 256 Kbps:
(host) (config) #user-role authenticated bw-contract 256k downstream
Applying Contracts Per-User
Use the following commands to apply the contracts on a per-user basis for upstream and downstream:
For upstream contract of 512 Kbps:
(host) (config) #user-role authenticated bw-contract 512k per-user upstream
For downstream contract of 256 Kbps:
(host) (config) #user-role authenticated bw-contract 256k per-user downstream
Verifying Contracts on AP
The following example displays the bandwidth contracts on AP for per-role configuration:
(host) #show datapath bwm ap-name rap5-2
Datapath Bandwidth Management Table Entries
-------------------------------------------
Flags: Q - No drop, P - No shape(Only Policed),
T - Auto tuned
--------------------------------------------------------------------
Rate: pps - Packets-per-second (256 byte packets), bps - Bits-per-second
--------------------------------------------------------------------
Cont Avail Queued/Pkts
Id Rate Policed Bytes Bytes Flags
---- --------- ---------- ------- ------------ -----
1
2
512000
256000
0
0
16000
8000
0/0
0/0
P
P
The following example displays the bandwidth contracts on AP for per-user configuration (contract IDs 3 and 4 are per-user contracts):
(host) #show datapath bwm ap-name rap5-2
Datapath Bandwidth Management Table Entries
-------------------------------------------
Flags: Q - No drop, P - No shape(Only Policed),
T - Auto tuned
--------------------------------------------------------------------
Avail Queued/Pkts
Id Rate Policed Bytes Bytes Flags
---- --------- ---------- ------- ------------ -----
3
4
1
2
512000
256000
512000
256000
300
277
0 16000
0
16000
8000
8000
0/0
0/0
0/0
0/0
P
P
P
P
Verifying Contracts Applied to Users
You can verify if the contracts are applied to the user after the user connects to the AP using CLI.
The following is a sample output for a per-role configuration:
(host) #show datapath user ap-name rap5-2
Datapath User Table Entries
---------------------------
748 | Remote Access Points ArubaOS 6.5.3.x | User Guide
Flags: P - Permanent, W - WEP, T- TKIP, A - AESCCM, G - AESGCM, V - ProxyArp to/for MN
(Visitor),
N - VPN, L - local, Y - Any IP user, R - Routed user, M - Media Capable,
S - Src NAT with VLAN IP, E - L2 Enforced, F - IPIP Force Delete, O - VOIP user, I - Interim stats,
C - Inactive, D - Suppress Idle TMO, m - IP mobile user anchor, H - 1st DHCP sent to AUTH
FM(Forward Mode): S - Split, B - Bridge, N - N/A
IP MAC ACLs Contract Location Age Sessions Flags Vlan
------------------------------------- ---------------------------------
10.15.72.50
10.15.72.253
00:0B:86:61:12:AC
00:18:8B:A9:A8:DF
2703/0
52/0
0/0
1/2
0
0
16
1
1/65535
0/65535
P 0
1
192.168.11.1
10.15.196.249
FM IdleTMO
---------
00:0B:86:66:03:3F 2700/0
00:0B:86:66:03:3F 2700/0
0/0
0/0
0
0
20024 0/65535
3 1/65535
P
P
177
1
N 300
S 300
N 300
N 300
The following is a sample output for a per-user configuration:
(host) #show datapath user ap-name rap5-2
Datapath User Table Entries
---------------------------
Flags: P - Permanent, W - WEP, T- TKIP, A - AESCCM, G - AESGCM, V - ProxyArp to/for MN
(Visitor),
N - VPN, L - local, Y - Any IP user, R - Routed user, M - Media Capable,
S - Src NAT with VLAN IP, E - L2 Enforced, F - IPIP Force Delete, O - VOIP user, I - Interim stats,
C - Inactive, D - Suppress Idle TMO, m - IP mobile user anchor, H - 1st DHCP sent to AUTH
FM(Forward Mode): S - Split, B - Bridge, N - N/A
FM IdleTMO
---------
N 300
S 300
N 300
N 300
Verifying Bandwidth Contracts During Data Transfer
You can verify the Bandwidth Contracts that are in use during data transfer using CLI.
The following is a sample output for a per-role configuration:
(host) #show datapath session ap-name rap5-2 table 10.15.72.99
Datapath Session Table Entries
------------------------------
Flags: F - fast age, S - src NAT, N - dest NAT
D - deny, R - redirect, Y - no syn
H - high prio, P - set prio, T - set ToS
C - client, M - mirror, V - VOIP
Q - Real-Time Quality analysis
I - Deep inspect, U - Locally destined
E - Media Deep Inspect, G - media signal
ArubaOS 6.5.3.x
| User Guide Remote Access Points | 749
r - Route Nexthop
A - Application Firewall Inspect
B - Permanent, O - Openflow
RAP Flags: 1 - Class 1, 2 - Class 2, 3 - Class 3
Source IP Destination IP Prot SPort DPort Cntr Prio ToS Age Destination
-------------- -------------- ---- ----- -------- ---- --- --- -----------
10.15.72.253
10.15.72.99
6
10.15.72.253
10.15.72.99
10.15.72.99
10.15.72.253
6
6
10.15.72.99
10.15.72.253
6
5001 36092 1/1 0 0 0 dev12
3488 5001 1/1 0 0 0 dev5
5001 3488 1/2 0 0 0 dev5
36092 5001 1/2 0 0 0 dev12
TAge Packets Bytes Flags
---- ---------------------
6 --
6 --
6 --
6 --
--
--
--
--
C
C
C
The following is a sample output for a per-user configuration:
(host) #show datapath session ap-name rap5-2 table 10.15.72.99
Datapath Session Table Entries
------------------------------
Flags: F - fast age, S - src NAT, N - dest NAT
D - deny, R - redirect, Y - no syn
H - high prio, P - set prio, T - set ToS
C - client, M - mirror, V - VOIP
Q - Real-Time Quality analysis
I - Deep inspect, U - Locally destined
E - Media Deep Inspect, G - media signal r - Route Nexthop
A - Application Firewall Inspect
B - Permanent, O - Openflow
RAP Flags: 1 - Class 1, 2 - Class 2, 3 - Class 3
Source IP Destination IP Prot SPort DPort Cntr Prio ToS Age Destination
-------------- ----------------- ----- -------- ---- --- --- -----------
10.15.72.253
10.15.72.99
10.15.72.99
10.15.72.253
6
6
3489
5001
5001
3489
1/3
1/4
0
0
0
0
0
0 dev5 dev5
10.15.72.99
10.15.72.253
10.15.72.253
6
10.15.72.99
6
36096 5001 1/4 0 0 0 dev12
5001 36096 1/3 0 0 0 dev12
TAge Packets Bytes Flags
---- ---------------------
37
37
--
--
--
--
FC
F
37
37
--
--
--
--
C
RAP TFTP Image Upgrade
Starting from ArubaOS 6.5, you can enable or disable the TFTP image upgrade on a RAP. This feature does not impact the campus APs. You can enable or disabled this feature using the WebUI or the CLI.
In the WebUI
The following WebUI procedure enables or disables the TFTP image upgrade on a RAP:
1. Navigate to Configuration > ADVANCED SERVICES > All Profiles .
2. In the Profiles section, expand AP > AP system .
3. Select the default ap system-profile.
750 | Remote Access Points ArubaOS 6.5.3.x | User Guide
4. In the Profile Details section, click the Advanced tab.
5. Select the Disable RAP Tftp Image Upgrade check box.
Note: Selecting the check box disables the TFTP image upgrade. Clearing the check box enables the TFTP image upgrade.
6. Click Apply .
In the CLI
The following commands enables or disables the TFTP image upgrade on a RAP:
(host) (config) #ap system-profile default
(host) (AP system profile "default") #[no] disable-tftp-image-upgrade
(host) (AP system profile "default") #write memory
The following command displays if the TFTP image upgrade is enabled or disabled in the AP system profile:
(host) #show ap system-profile default
AP system profile "default"
---------------------------
Parameter
---------
RF Band
RF Band for AM mode scanning
Native VLAN ID
Tunnel Heartbeat Interval
Session ACL
Corporate DNS Domain
Value
----g all
10
1 ap-uplink-acl
N/A
SNMP sysContact N/A
LED operating mode (11n/11ac APs only) normal
LED override
Driver log level
Disabled warnings
Console log level
SAP MTU
RAP MTU
LMS IP emergencies
N/A
1200 bytes
N/A
Backup LMS IP
LMS IPv6
Backup LMS IPv6
LMS Preemption
LMS Hold-down Period
LMS ping interval
Remote-AP DHCP Server VLAN
Remote-AP DHCP Server Id
Remote-AP DHCP Default Router
Remote-AP DHCP DNS Server
Remote-AP DHCP Pool Start
Remote-AP DHCP Pool End
Remote-AP DHCP Pool Netmask
Remote-AP DHCP Lease Time
Remote-AP uplink total bandwidth
Remote-AP bw reservation 1
Remote-AP bw reservation 2
Remote-AP bw reservation 3
Remote-AP Local Network Access
Bootstrap threshold
Double Encrypt
Dump Server
Heartbeat DSCP
Maintenance Mode
Maximum Request Retries
Request Retry Interval
N/A
N/A
N/A
Disabled
600 sec
20
N/A
192.168.11.1
192.168.11.1
N/A
192.168.11.2
192.168.11.254
255.255.255.0
0 days
0 kbps
N/A
N/A
N/A
Disabled
8
Disabled
N/A
0
Disabled
10
10 sec
ArubaOS 6.5.3.x
| User Guide Remote Access Points | 751
Number of IPSEC retries
Secondary Master IP/FQDN
AeroScout RTLS Server
RTLS Server configuration
85 exit
N/A
N/A
RTLS Server Compatibility Mode Enabled
Slow Timer Recovery by rebooting itself Disabled
Telnet
Disable RAP Tftp Image Upgrade
Enabled
Disabled
Spanning Tree
AP multicast aggregation
Enabled
Disabled
AP ARP attack protection Enabled
AP multicast aggregation allowed VLANs none
Console enable
AP Console Protection
AP Console Password
Password for Backup
AP USB Power override
RF Band for Backup
Operation for Backup
BLE Endpoint URL
BLE Auth Token
BLE Operation Mode
Enabled
Disabled
********
********
Disabled all off
N/A
N/A
Disabled
752 | Remote Access Points ArubaOS 6.5.3.x | User Guide
Chapter 33
Virtual Intranet Access
Virtual Intranet Access (VIA) is part of the Aruba remote networks solution intended for teleworkers and mobile users. VIA detects the network environment (trusted and untrusted) of the user and connects the users to the enterprise network. Trusted networks refers to a protected office network that allows users to directly access the corporate intranet. Untrusted networks are public Wi-Fi hotspots such as airports, cafes, or home network.
The VIA solution includes the VIA client and controller configuration.
n n
VIA client– Remote workers and mobile users can install VIA on their computers and smart devices (iOS and
Android) to connect to their enterprise network from remote locations.
Controller configuration– To setup VIA for remote users, configure the controller with user roles, authentication profile, and connection profile. Use either the WebUI or CLI to configure the controller.
VIA requires the PEFV license and is supported on 7000 Series and 7200 Series controllers.
Figure 114 VIA Topology
For more details on configuring, installing, and using VIA, refer to the latest version of the Aruba VIA 2.0 User
Guide .
ArubaOS 6.5.3.x
| User Guide Virtual Intranet Access | 753
Chapter 34
Spectrum Analysis
Wireless networks operate in environments with electrical and radio frequency devices that can interfere with network communications. Microwave ovens, cordless phones, and even adjacent Wi-Fi networks are all potential sources of continuous or intermittent interference. The spectrum analysis software modules on APs that support this feature examine the radio frequency (RF) environment in which the Wi-Fi network is operating, identify interference and classify its sources. An analysis of the results quickly isolate issues with packet transmission, channel quality, and traffic congestion caused by contention with other devices operating in the same band or channel.
AP radios that gather spectrum data but do not service clients are called spectrum monitors, or SMs. Each SM scans and analyzes the spectrum band used by the SM's radio (2.4Ghz or 5Ghz). An AP radio in hybrid AP mode continues to serve clients as an access point while analyzing spectrum analysis data for the channel the radio uses to serve clients. You can record data for both types of spectrum analysis devices, save that data, and then play it back for later analysis.
Topics in this chapter include: n n n n n n n n n n
Understanding Spectrum Analysis on page 754
Creating Spectrum Monitors and Hybrid APs on page 759
Connecting Spectrum Devices to the Spectrum Analysis Client on page 761
Configuring the Spectrum Analysis Dashboards on page 764
Customizing Spectrum Analysis Graphs on page 767
Working with Non-Wi-Fi Interferers on page 793
Understanding the Spectrum Analysis Session Log on page 795
Viewing Spectrum Analysis Data on page 795
Recording Spectrum Analysis Data on page 796
Troubleshooting Spectrum Analysis on page 799
Understanding Spectrum Analysis
The table below lists the AP models that support the spectrum analysis feature. Single-radio mesh APs do not support the spectrum analysis feature; if an AP radio has a virtual AP carrying mesh backhaul traffic, no other virtual AP on that radio can be configured as a spectrum monitor. However, dual-radio mesh APs can have the client access radio configured as a Spectrum monitor or hybrid AP while the other radio supports mesh backhaul traffic.
ArubaOS 6.5.3.x
| User Guide Spectrum Analysis | 754
Table 165: Device Support for Spectrum Analysis
Device
Configurable as a
Spectrum
Monitor?
Configurable as a
Hybrid AP?
AP-103
AP-104
AP-105
130 Series
170 Series
RAP-3WN
RAP-155
RAP-108
RAP-109
300 Series
310 Series
320 Series
330 Series
200 Series
210 Series
220 Series
270 Series
AP-114
AP-115
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
The radios on groups of APs can be converted to dedicated spectrum monitors or hybrid APs via the AP group’s dot11a and dot11g radio profiles. Individual APs can also be converted to spectrum monitors through the AP’s spectrum override profile.
The spectrum analysis feature requires the RF Protect license. To convert an AP to a spectrum monitor or hybrid AP, you must have an AP license and an RFProtect license for each AP on that controller.
The Spectrum Analysis section of the Monitoring tab in the WebUI includes the Spectrum Monitors ,
Session Log , and Spectrum Dashboards windows.
n
Spectrum Monitors : this window displays a list of active spectrum monitors and hybrid APs streaming data to your client, the radio band the device is monitoring, and the date and time the SM or hybrid AP was
755 | Spectrum Analysis ArubaOS 6.5.3.x | User Guide
n n connected to your client. This window allows you to select the spectrum monitors or hybrid APs for which you want to view information, and release the connection between your client and any device you no longer want to view.
Session Log : this tab displays activity for spectrum monitors and hybrid APs during the current browser session, including timestamps showing when the devices were connected to and disconnected from the client, and any changes to a hybrid APs monitored channel.
Spectrum Dashboards : this window shows different user-customizable data charts for 2.4 Ghz and 5
GHz spectrum monitor or hybrid AP radios.
below gives a basic description of each of the spectrum analysis graphs that can appear on the spectrum dashboard.
For more detailed information on these graphs, refer to
Customizing Spectrum Analysis Graphs on page 767
.
Table 166: Spectrum Analysis Graphs
Graph Title
Active Devices
Table
Active Devices
Trend
Channel
Metrics
Channel
Metrics Trend
Channel
Summary
Table
Channel
Utilization
Trend
Description
Update
Interval
N/A A pie chart showing the percentages and total numbers of each device type for all active devices. This graph has no set update interval; the graph automatically updates when values change.
For details, see
A line chart showing the numbers of up to five different types of
Wi-Fi and non-Wi-Fi devices seen on selected channels during a specified time interval. This chart can show devices on multiple channels for a spectrum monitor, or the single monitored channel for a hybrid AP. For details, see
Active Devices Trend on page 772
.
This stacked bar chart shows the current relative quality, availability or utilization of selected channels in the 2.4 GHz or 5
GHz radio bands. This chart can show multiple channels for a spectrum monitor, or the single monitored channel for a hybrid
AP. For details, see
A line chart showing the relative quality or availability of selected channels in the 2.4 GHz or 5 GHz radio bands over a specified time interval. Spectrum monitors can show channel data for multiple channels, while a hybrid AP shows information only for its one monitored channel. For details, see
The Channel Summary table displays the number of devices found on each channel in the spectrum monitor’s radio band, the percentage of channel utilization, and AP power and interference levels. Spectrum monitors can show data for multiple channels, while a hybrid AP shows a channel summary only for its one monitored channel. For details, see
Channel Summary Table on page 777
.
A line chart that shows the channel utilization for one or more radio channels, as measured over a defined time interval.
Spectrum monitors can show data for multiple channels, while a hybrid AP shows utilization levels for its one monitored channel only. For details, see
Channel Utilization Trend on page 780 .
5 seconds
5 seconds
5 seconds
5 seconds
5 seconds
ArubaOS 6.5.3.x
| User Guide Spectrum Analysis | 756
Graph Title
Device Duty
Cycle
Devices vs
Channel
FFT Duty Cycle
Interference
Power
Quality
Spectrogram
Real-Time FFT
Swept
Spectrogram
Description
Update
Interval
A stacked bar chart showing the percent of each channel in the spectrum monitor radio’s frequency band used by a Wi-Fi AP or any other device type detected by the spectrum monitor. The
Device Duty Cycle chart for a hybrid AP only shows data for the one channel monitored by the hybrid AP. For details, see
.
A stacked bar chart showing the total numbers of each device type detected on each channel in the spectrum monitor radio’s frequency band. The Devices vs Channel chart for a hybrid AP only shows data for the one channel monitored by the hybrid AP.
For details, see
Devices vs Channel on page 781
.
Fast Fourier Transform, or FFT , is an algorithm for computing the frequency spectrum of a time-varying input signal. This line chart shows the FFT duty cycle, which represents the percent of time a signal is broadcast on the specified channel or frequency.
Spectrum monitors can show data for multiple channels, while a hybrid AP shows information only for its one monitored channel.
For details, see
5 seconds
5 seconds
1 second
This chart shows information about Wi-Fi interference, including the Wi-Fi noise floor, and the amount of adjacent channel interference from cordless phones, bluetooth devices and microwaves. Spectrum monitors can show interference power data for multiple channels, while a hybrid AP shows information only for its one monitored channel. For details, see
.
This plot shows quality statistics for selected range of channels or frequencies as determined by the current noise floor, non-Wi-
Fi (interferer) utilization and duty-cycles and certain types of retries. This chart can also be configured to show channel availability, the percentage of each channel that is unused and available for additional traffic. Spectrum monitors can show data for multiple channels, while a hybrid AP shows information only for its one monitored channel. For details, see
5 seconds
5 seconds
Fast Fourier Transform, or FFT , is an algorithm for computing the frequency spectrum of a time-varying input signal. This line chart shows the power level of a signal on the channels or frequencies monitored by a spectrum monitor radio. Spectrum monitors can show data for multiple channels, while a hybrid AP shows information only for its one monitored channel. For details, see
.
This plot displays FFT power levels For details, see or the FFT duty cycle for a selected channel or frequency, as measured during each time tick. Spectrum monitors can show data for multiple channels, while a hybrid AP shows information only for its one monitored channel. For details, see
.
1 second
1 second
Spectrum Analysis Clients
The maximum number of spectrum monitor radios and hybrid AP radios on a controller is limited only by the number of APs on that controller. If desired, you can configure every radio on an AP that supports the
757 | Spectrum Analysis ArubaOS 6.5.3.x | User Guide
Spectrum Analysis feature as a spectrum device. A dual-radio AP can operate as two spectrum devices, because each radio can be individually configured as a spectrum monitor (SM) or hybrid AP.
A spectrum analysis client can simultaneously access data from up to four individual spectrum device radios.
Each spectrum device radio, however, can only be connected to a single client WebUI.
When you select a specific spectrum monitor or hybrid AP radio to stream data to your client, the controller first verifies the device is not subscribed to some other client. Once the SM or hybrid AP radio has been verified as available, the SM or hybrid AP establishes a connection to the client and begins sending spectrum analysis data either every second or every five seconds, depending on the type of data being requested. Each client may select up to twelve different spectrum analysis charts and graphs to appear in the spectrum dashboard.
A controller can support up to 22 active WebUI connections. If spectrum analysis clients are simultaneously viewing data for than 22 WebUI connections, any additional WebUI requests are refused until some clients close their WebUI browser sessions.
When you finish reviewing data from an SM or hybrid AP, you should disconnect the device from your spectrum client. Do not forget this important step—no other user can access data from that spectrum monitor or hybrid AP until you release your subscription. Note, however, that when you disconnect a spectrum monitor from your client, the AP continues to operate as a spectrum monitor until you return it to AP mode by removing the local spectrum override, or by changing the mode parameter in the AP’s 802.11a or 802.11g radio profile from spectrum-mode back to AP-mode.
A spectrum monitor or hybrid AP automatically disconnects from a client when you close the browser window you used to connect the spectrum monitor to your client. However, if you use Internet Explorer and have multiple instances of an Internet Explorer browser open, the data-streaming connection to the spectrum monitor or hybrid
AP is not released until 60 seconds after you close the spectrum client browser window. During this 60-second period, the spectrum monitor is still connected to the client.
When a spectrum monitor or hybrid AP is not subscribed to any client, it still performs all classification tasks and collect all necessary channel lists and device information. You can view classification, device, and channel information for any active spectrum monitor or hybrid AP via the controller's command-line interface, regardless of whether or not that device is sending real-time spectrum data to another client WebUI.
Individual spectrum analysis graphs and charts are explained in detail in
Customizing Spectrum Analysis Graphs on page 767 .
Hybrid AP Channel Changes
By default, a hybrid AP only monitors the channel specified in its 802.11a or 802.11g radio profile for spectrum interference. If you want to change the channel monitored by a hybrid AP, you must edit the channel setting in those profiles. However, there are other ArubaOS features that may automatically change the channels on hybrid APs. APs using Dynamic Frequency Selection (DFS) perform off-channel scanning to detect the presence of satellite and radar transmissions, and switch to a different channel if it detects that satellite or radar transmissions are present. APs using the Adaptive Radio Response (ARM) feature constantly monitor the network and automatically select the best channel and transmission power settings for that AP. If you manually change a channel monitored by a hybrid AP, best practices are to temporarily disable the ARM feature, as ARM may automatically return the channel to its previous setting.
If a hybrid AP is using ARM or DFS, that hybrid AP may automatically move to a different channel in response to changes in the network environment. If a hybrid AP changes channels while it is connected to a spectrum analysis client, the hybrid AP updates the graphs in the spectrum dashboard to start displaying spectrum data for the new channel, and sends a log message to the session log. For details on changing the channel monitored by a hybrid AP, see
802.11a and 802.11g RF Management Profiles on page 563 .
ArubaOS 6.5.3.x
| User Guide Spectrum Analysis | 758
Hybrid APs Using Mode-Aware ARM
If a radio is configured as a hybrid AP and that AP is enabled with mode-aware ARM, the hybrid AP can change to an Air Monitor (or AM ) if too many APs are detected in the area. If the ARM feature changes a hybrid AP to an
Air Monitor, that AM does not provide spectrum data after the mode change. The AM unsubscribes from any connected spectrum analysis client, and sends a log message warning about the change. If mode-aware ARM changes the AM back to an AP, the hybrid AP does not automatically resubscribe back to the spectrum analysis client. The hybrid AP must manually resubscribed before it can appear in the client’s spectrum monitors page.
Creating Spectrum Monitors and Hybrid APs
Each controller can support up to 22 active WebUI connections to spectrum monitor or hybrid AP radios. If you plan on using spectrum monitors or hybrid APs as a permanent overlay to constantly monitor your network, you should create a separate AP group for these devices. If you plan on temporarily converting campus APs to spectrum monitors, best practices are to use the spectrum local override profile to convert an
AP to a spectrum monitor.
This section describes the following tasks for converting regular APs into hybrid APs or spectrum monitors.
n n n
Converting APs to Hybrid APs on page 759
Converting an Individual AP to a Spectrum Monitor on page 760
Converting a Group of APs to Spectrum Monitors on page 761
Converting APs to Hybrid APs
You can convert a group of regular APs into a hybrid APs by selecting the spectrum monitoring option in the
AP group’s 802.11a and 802.11g radio profiles. Once you have enabled the spectrum monitoring option, all
APs in the group that support the spectrum monitoring feature start to function as hybrid APs. If any AP in the group does not support the spectrum monitoring feature, that AP continues to function as a standard AP, rather than a hybrid AP.
The spectrum monitoring option in the 802.11a and 802.11g radio profiles only affects APs in ap-mode. Devices in am-mode (Air Monitors) or sm-mode (Spectrum Monitors) are not affected by enabling this option.
If you want to convert an individual AP (and not an entire AP group) to a hybrid AP, you must create a new
802.11a or 802.11g radio profile, enable the spectrum monitoring option, then reassign that AP to the new profile. For additional information see
Creating and Editing Mesh High-Throughput SSID Profiles on page 623
for details on how to create a new 802.11a/g radio profile, then assign an individual AP to that profile.
If the spectrum local-override profile on the controller that terminates the AP contains an entry for a hybrid AP radio, that entry overrides the mode selection in the 802.11a or 802.11g radio profile, and the AP operates as a spectrum monitor, not as a hybrid AP. You must remove any spectrum local override for an AP to allow the device to operate as a hybrid AP. For further details on editing a spectrum local override, see
Converting an Individual AP to a Spectrum
.
In the WebUI
Follow the procedure below to convert a group of APs to hybrid mode via the WebUI.
1. Navigate to the Configuration > Wireless > AP Configuration window. Select the AP Group tab.
2. Click Edit by the name of the AP group you want to convert to hybrid APs.
3. Under the Profiles list, expand the RF Management menu.
4. To enable a spectrum monitor on the 802.11a radio band, select the 802.11a radio profile menu.
759 | Spectrum Analysis ArubaOS 6.5.3.x | User Guide
-or-
To enable a spectrum monitor on the 802.11g radio band, select the 802.11g radio profile menu.
5. The Profile Details pane appears. Select the Spectrum Monitor checkbox.
6. Click Apply .
In the CLI
To convert a group of APs via the command-line interface, access the CLI in config mode and issue the following commands, where
<profile> is the name of the 802.11a or 802.11g radio profile used by the group of APs you want to convert to hybrid APs: rf dot11a-radio-profile <profile> spectrum-monitoring rf dot11g-radio-profile <profile> spectrum-monitoring
Converting an Individual AP to a Spectrum Monitor
There are two ways to change a radio on an individual AP or AM into a spectrum monitor. You can assign that
AP to a different 802.11a and 802.11g radio profile that is already set to spectrum mode, or you can temporarily change the AP into a spectrum monitor using a local spectrum override profile. When you use a local spectrum override profile to override an AP’s mode setting, that AP begins to operate as a spectrum monitor, but remains associated with its previous 802.11a and 802.11g radio profiles. If you change any parameter (other than the overridden mode parameter) in the spectrum monitor’s 802.11a or 802.11 radio profiles, the spectrum monitor immediately updates with the change. When you remove the local spectrum override, the spectrum monitor reverts back to its previous mode, and remains assigned to the same 802.11a
and 802.11 radio profiles as before.
The spectrum local override profile overrides the mode parameter in the 802.11a or 802.11g radio profile, changing it from ap-mode or am-mode to spectrum-mode, while allowing the spectrum monitor to continue to inherit all other settings from its 802.11a/802.11g radio profiles. When the spectrum local override is removed, the AP automatically reverts to its previous mode as defined it its 802.11a or 802.11g radio profile settings. If you use the local override profile to change an AP radio to a spectrum monitor, you must do so by accessing the WebUI or CLI of the controller that terminates the AP. This is usually a local controller, not a master controller.
In the WebUI
To convert an individual AP using the local spectrum override profile in the WebUI:
1. Select Configuration > All Profiles . The All Profile Management window opens.
2. Select AP to expand the AP profiles section.
3. Select Spectrum Local Override Profile . The Profile Details pane displays the current Override Entry settings.
4. In the AP name entry blank, enter the name of an AP whose radio you want to configure as a spectrum monitor. Note that AP names are case-sensitive. Any extra spaces before or after the AP name prevents the
AP from being correctly added to the override list.
5. If your AP has multiple radios or a single dual-band radio, click the band drop-down list and select the spectrum band you want that radio to monitor: 2-ghz or 5-ghz . Click Add to add that radio to the
Override Entry list.
6. (Optional) Repeat steps 4-6 to convert other AP radios to spectrum monitors, as desired. To remove a spectrum monitor from the override entry list, select that radio name in the override entry list, then click
Delete .
7. Click Apply .
ArubaOS 6.5.3.x
| User Guide Spectrum Analysis | 760
In the CLI
To convert an individual AP spectrum monitor using the spectrum local override profile in the command-line interface, access the CLI in config mode and issue the following command: ap spectrum local-override override ap-name <ap-name> spectrum-band 2ghz|5ghz
Converting a Group of APs to Spectrum Monitors
When you convert a group of APs to spectrum monitors using their 802.11a/802.11g radio profiles, all AP radios associated with that profile stop serving clients and act as spectrum monitors only. Therefore, before you convert an entire group of APs to spectrum monitors, be sure that none of the APs are currently serving clients, as that may temporarily interrupt service to those clients.
If you use an 802.11a or 802.11g radio profile to create a group of spectrum monitors, all APs in any AP group referencing that radio profile are set to spectrum mode. Therefore, best practices are to create a new 802.11a or
802.11g radio profile just for spectrum monitors, using the following CLI commands: ap-name <ap name> dot11a-radio-profile <profile-name>ap-name <ap name> dot11g-radio-profile
<profile-name>
If you want to set an existing 802.11a or 802.11g radio profile to spectrum mode, verify that no other AP group references that radio profile, using the following CLI commands: show references rf dot11a-radio-profile <profile-name>show references rf dot11g-radioprofile <profile-name>
In the WebUI
Follow the procedure below to convert a group of APs to Spectrum mode via the WebUI.
1. Navigate to the Configuration > Wireless > AP Configuration window. Select the AP Group tab.
2. Click Edit by the name of the AP group you want to convert to spectrum monitors.
3. Under the Profiles list, expand the RF Management menu.
4. To enable a spectrum monitor on the 802.11a radio band, select the 802.11a radio profile menu.
-or-
To enable a spectrum monitor on the 802.11g radio band, select the 802.11g radio profile menu.
5. The Profile Details pane appears. Click the Mode drop-down list, and select spectrum-mode .
6. Click Apply .
In the CLI
To convert a group of APs via the command-line interface, access the CLI in config mode and issue the following commands, where <profile> is the 80211a or 80211g radio profile used by the AP group.
rf dot11a-radio-profile <profile> mode spectrum-mode rf dot11g-radio-profile <profile> mode spectrum-mode
Connecting Spectrum Devices to the Spectrum Analysis Client
A spectrum analysis client is any laptop or desktop computer that can access the controller WebUI and receive streaming data from individual spectrum monitors or hybrid APs. Once you have configured one or more APs to operate as a spectrum monitor or hybrid AP, use the Spectrum Monitors window to identify the spectrum devices you want to actively connect to the spectrum analysis client. To connect one or more spectrum devices to your client:
1. Navigate to Monitoring > Spectrum Analysis .
2. Click the Spectrum Monitors tab.
761 | Spectrum Analysis ArubaOS 6.5.3.x | User Guide
3. Click Add . A table appears, displaying a list of spectrum analysis devices, sorted by name. Single-radio spectrum devices have a single entry in this table, and dual-radio spectrum devices have two entries: one for each radio. This table displays the following data for each radio.
Table 167: Spectrum Device Selection Information
Table
Column
AP
Description
Name of the AP whose radio you want to convert to a spectrum monitor. AP names are case sensitive.
This column includes the following icons:
Radio is operating as a spectrum monitor.
Band
Model
AP Group
Mode
Availability for
Connection
Radio is operating as a hybrid AP with spectrum enabled.
The frequency band currently used by the radio. This value can be either 2.4 GHz or 5
GHz .
AP model type.
Name of the AP group to which the spectrum monitor is currently associated.
This column indicates the type of spectrum analysis device: n Spectrum Monitor : AP is in spectrum monitor mode.
n Access Point : AP is configured as an access point but with spectrum monitoring enabled (Hybrid AP).
Indicates if the AP is available to send spectrum analysis data to the client. Possible options are: n n
Available, 2.4GHz
: the radio is available to send spectrum analysis data on the
2.4GHz frequency band.
Available, 5GHz : the radio is available to send spectrum analysis data on the 5GHz frequency band.
n n n
Available, Dual Band : the radio is available and is capable of sending spectrum analysis data on either the 2.4 GHz or the 5 GHz frequency bands.
Available, current channel - <channel> : the AP radio is in hybrid mode and can display spectrum analysis data for the single specified channel only.
Not available: an AP may not be available because it is currently sending spectrum analysis data to another client.
4. Click the table entry for a spectrum monitor radio, then click Connect .
5. Repeat steps 3-4 to connect additional devices, if desired.
View Connected Spectrum Analysis Devices
Once you have connected one or more spectrum monitors or hybrid APs to your Spectrum Analysis client, the
Monitoring > Spectrum Analysis > Spectrum Monitors window displays a table of currently connected spectrum devices. This table includes the name of each spectrum monitor or hybrid AP and its current radio band (2GHz or 5GHz):
ArubaOS 6.5.3.x
| User Guide Spectrum Analysis | 762
Figure 115 Viewing a list of Connected Spectrum Monitors
To view a list of connected spectrum devices via the command-line interface, issue the show ap spectrum monitors command:
Disconnecting a Spectrum Device
A spectrum monitor or hybrid AP can send spectrum analysis data to only one client at a time. When you are done viewing data for a spectrum device, you should release your client’s subscription to that spectrum device and allow other clients to view data from that device. A spectrum monitor or hybrid AP automatically disconnects from your client when you close the browser window used to connect the spectrum device your client.
To manually disconnect a spectrum monitor or hybrid AP:
1. Click the Spectrum Monitors tab.
2. Each table entry in the Currently Connected table includes a Disconnect link to release the client’s connection to that spectrum monitor. Identify the table entry for the spectrum monitor you want to release then click Disconnect .
3. A pop up window asks you to confirm that you want to disconnect the spectrum monitor from the spectrum analysis client. Click OK . The spectrum monitor disconnects from the client and the device’s entry is removed from the Currently Connected table.
When you disconnect a spectrum device from your client, the AP continues to operate as a spectrum monitor or hybrid AP until you return the device to AP mode by removing the local spectrum override, or by changing the mode parameter in the AP’s 802.11a or 802.11g radio profile from spectrum-mode to AP-mode.
If you are use Internet Explorer with multiple instances of the Internet Explorer browser open, and you close the spectrum browser window without manually disconnecting the spectrum device, the controller does not release the data streaming connection to a spectrum monitor until 60 seconds after you close the spectrum client browser window. During this 60-second period, the spectrum monitor is still connected to the client.
763 | Spectrum Analysis ArubaOS 6.5.3.x | User Guide
Configuring the Spectrum Analysis Dashboards
Once you have connected spectrum monitors to your spectrum analysis client, you can begin to monitor spectrum data in the spectrum analysis dashboards. There are three predefined sets of dashboard views, View
1 , View 2 and View 3 . View 1 displays the Real-Time FFT, FFT Duty-Cycle and Swept Spectrogram graphs by default, and Views 2 and 3 display the Swept Spectrogram and Quality Spectrogram charts, and the Channel
Summary and Active Devices tables.
Each chart in the dashboard can be replaced with other chart types, or reconfigured to show data for a different spectrum monitor. Once you have configured a dashboard view with different settings, you can rename that dashboard view to better reflect its new content.
The following sections explain how to customize your Spectrum Analysis dashboard to best suit the needs of your individual network: n n n n n
Selecting a Spectrum Monitor on page 764
Changing Graphs within a Spectrum View on page 765
Renaming a Spectrum Analysis Dashboard View on page 765
Saving a Dashboard View on page 766
Resizing an Individual Graph on page 767
Selecting a Spectrum Monitor
When you first log into the Spectrum Analysis dashboard, it displays blank charts. You must identify the spectrum monitor whose information you want to view before the graphs display any data.
To identify the spectrum monitor radio whose data you want to appear in the Spectrum Analysis dashboard:
1. Access the Monitoring > Spectrum Analysis window in the WebUI.
2. Click the Spectrum Dashboards tab.
3. In the graph title bar, click the down arrow by the Please select a spectrum monitor heading, as shown in
. A drop-down list appears with the name of all spectrum monitor and hybrid AP radios currently connected to the client.
Figure 116 Selecting a Spectrum Monitor
4. Select a spectrum monitor from the list. The spectrum monitor or hybrid AP name appears in the chart title bar and the chart starts displaying data for that spectrum monitor.
ArubaOS 6.5.3.x
| User Guide Spectrum Analysis | 764
After you have selected the initial spectrum monitor or hybrid AP for a graph, you can display data for a different spectrum device at any time by clicking the down arrow by the device name in the chart titlebar and selecting a different connected spectrum monitor or hybrid AP.
Changing Graphs within a Spectrum View
To replace an existing graph with any other type of graph or chart:
1. Access the Monitoring > Spectrum Analysis window in the WebUI.
2. Click the Spectrum Dashboards tab.
3. From Spectrum Dashboards window, click one of the view names at the top of the window to select the dashboard layout with the graph you want to change.
4. Click the down arrow at the far right end of the graph title bar to display a drop-down menu of chart options.
5. Click Replace With to display a list of available graphs.
6. Click the name of the new graph you want to display.
Figure 117 Replacing a Graph in the Spectrum Analysis Dashboard
Renaming a Spectrum Analysis Dashboard View
You can rename any of the three spectrum analysis dashboard views at any time. Note, however, that simply renaming a view does not save its settings. (For details on saving a spectrum dashboard view, refer to
.)
To rename a Spectrum Analysis Dashboard view:
1. From the Monitoring > Spectrum Analysis > Spectrum Dashboards window, click the down arrow to the right of the dashboard view you want to rename.
2. Select Rename .
765 | Spectrum Analysis ArubaOS 6.5.3.x | User Guide
Figure 118 Renaming a Spectrum Dashboard View
3. The Dashboard Name popup window appears. Enter a new name for the dashboard view, then click OK .
Saving a Dashboard View
You can select different graphs to display in a dashboard view, but these changes are not saved unless you save that view. Dashboard views, (like the spectrum analysis profile and spectrum local-override profile) are all local configurations that must be configured on each controller. None of these settings are synchronized between controllers.
To save a dashboard view:
1. After selecting the graphs you want to appear in the view, click Save Spectrum View at the top of the window.
Figure 119 Save a Spectrum Analysis Dashboard Layout
2. The Spectrum View Saved confirmation window appears when the spectrum view has been saved. The selected graphs now appear by default whenever you log in to view the spectrum dashboard.
If you change graphs in a spectrum view but do not save your settings, you are prompted to save or cancel your changes when you close the spectrum dashboard browser window
ArubaOS 6.5.3.x
| User Guide Spectrum Analysis | 766
Resizing an Individual Graph
The left side of the title bar for each graph includes a resizing button on that allows you to expand a graph for easier viewing. Click this button as shown in
to expand the selected graph to the size of the full window and display the Options pane, which allows you to change the current display options for that graph.
(Configuration options are described in
Spectrum Analysis Graph Configuration Options on page 768
). To close the options pane if you have not made any changes to the graph, click Close at the bottom of the Options pane or click the resize button again to return the graph to its original size. To save any changes to the graph, click OK to save your settings and close the Options pane.
Figure 120 Resizing a Spectrum Analysis Graph
Customizing Spectrum Analysis Graphs
Each Spectrum Analysis graph can be customized to display or hide selected data types. To view the available options for a graph type:
1. From the Monitoring > Spectrum Analysis > Spectrum Dashboards window, click the down arrow at the end of the title bar for the graph you want to configure.
2. Select Options . The Options window appears to the right of the graph.
Figure 121 Viewing Spectrum Analysis Graph Options
767 | Spectrum Analysis ArubaOS 6.5.3.x | User Guide
3. From the Options window, configure graph settings described in
Spectrum Analysis Graph Configuration
.
4. When you are done, click OK at the bottom of the Options window to hide the options window.
5. (Optional) Click Save Spectrum View at the top of the window to save your new settings.
Spectrum Analysis Graph Configuration Options
The following sections describe the customizable parameters and the default settings for each spectrum analysis graph.
Active Devices
This graph appears as a pie chart showing the percentages and total numbers of each device type for all active devices seen by the spectrum monitor or hybrid AP radio. This chart is useful for determining which types of devices are sending signals on the specified radio band or channel. The Active Devices graphs for spectrum monitors can be configured to show data for several different device types on a single radio channel or range of channels. Active Devices graphs for hybrid APs can show data for the single monitored channel only.
When you hover your mouse over any section of the pie chart, a tooltip displays the percentage and number of active devices classified into that device type. The example in
shows that 99% of the active devices a spectrum monitor radio sees in the 2.4 GHz band are Wi-Fi APs.
Figure 122 Active Devices Graph
Click the down arrow in the upper right corner of this chart then click the Options menu to access the configuration settings for the Active Devices graph. Once you have configured the desired parameters, click OK at the bottom of the Options menu to save your settings and return to the spectrum dashboards.
ArubaOS 6.5.3.x
| User Guide Spectrum Analysis | 768
Table 168: Active Devices Graph Options
Parameter
Band
Description
Radio band displayed in this graph (2.4 GHz or 5 GHz)
Channel numbering
Channel Range
Show
This parameter is not configurable for graphs created by hybrid APs or spectrum monitor radios that use the 2.4 GHz radio band. A hybrid AP on a 20 MHz channel sees 40
MHz Wi-Fi data as non-Wi-Fi data. For spectrum monitors using the 5 GHz radio band, click the Channel Numbering drop-down list and select either 20 MHz or 40 MHz channel numbering to identify a channel numbering scheme for the graph. Graphs for
AP radios that support 802.11ac include an additional 80MHz option for very-highthroughput channels.
For graphs created by spectrum monitors, specify a channel range to determine which channels appears in this graph. Click the first drop-down list to select the lowest channel in the range, then click the second drop-down list to select the highest channel to appear in the graph.
This graph displays all channels within the spectrum monitor’s radio band by default.
NOTE: This parameter is not configurable for graphs created by hybrid APs.
Click the checkbox by any of these device categories to include that device type in the graph.
n n
WiFi (AP)
Microwave (This option is only available for 2.4 GHz radios) n n n n
Bluetooth (This option is only available for 2.4 GHz radios)
Fixed Freq (Others)
Fixed Freq (Cordless Phones)
Fixed Freq (Video) n n n n
Fixed Freq (Audio)
Freq Hopper (Others)
Freq Hopper (Cordless Network)
Freq Hopper (Cordless Base) n n
Freq Hopper Xbox (This option is only available for 2.4 GHz radios)
Microwave (Inverter) (This option is only available for 2.4 GHz radios) n Generic Interferer
NOTE: For more information on non-Wi-Fi device types detected by a spectrum monitor, see
Working with Non-Wi-Fi Interferers on page 793
.
Active Devices Table
This table lets you view, sort, and search for data about the devices that are sending signals on the specified radio band or channel. The Active Devices table for a spectrum monitor displays data for all channels on the selected band. The Active Devices table for a hybrid monitor displays data for the single monitored channel only. Click any of the column headings to sort the information in the table by that column criteria. Make a column wider or narrower by clicking the border of a column heading and dragging the border to a new position.
Figure 123 Active Devices Table
769 | Spectrum Analysis ArubaOS 6.5.3.x | User Guide
You can save the data in the Active Devices table for later analysis by exporting it as data file in .csv format, which can be viewed by spreadsheet and database management applications like Microsoft Excel. To export this table, click the down arrow in the upper right corner of this chart and select Export . A window opens and lets you browse to the location to which you want to save the file. Once you have identified the location where you want to save the file, click Save .
You can also filter table entries by signal strength, duty cycle, discovery time, activity duration, channels affected and device ID number by clicking the icon below any column heading and specifying the values or value ranges that should appear in the table.
describes each of the columns in the table and the filters that can be applied to the table output.
Table 169: Active Devices Table Options
Parameter
Device Type
Description
BSSID
SSID
Signal (dBm)
Duty Cycle
This column shows the type of active device detected by the spectrum monitor or hybrid AP. This column may display any of the following values: n n
WiFi (AP)
Microwave (This option is only available for 2.4 GHz radios) n n n n
Bluetooth (This option is only available for 2.4 GHz radios)
Fixed Freq (Others)
Fixed Freq (Cordless Phones)
Fixed Freq (Video) n n n n
Fixed Freq (Audio)
Freq Hopper (Others)
Freq Hopper (Cordless Network)
Freq Hopper (Cordless Base) n n n
Freq Hopper Xbox (This option is only available for 2.4 GHz radios)
Microwave (Inverter) (This option is only available for 2.4 GHz radios)
Generic Interferer
NOTE: For more information on non-Wi-Fi device types detected by a spectrum monitor, see
Working with Non-Wi-Fi Interferers on page 793
.
The Basic Service Set Identifier of the device. An AP’s BSSID is usually its MAC address.
The service set identifier of the device’s 802.11 wireless LAN.
The current transmission power for this device, in dBm.
To filter the output of this table to show only specific device types, click the icon in the column heading then select one of the following options: n Select Any to display entries for all signal strength levels.
n To display entries within a specific range of power strength levels, enter the minimum signal strength level in the Min field and enter the maximum signal strength level in the Max field.
Click OK to save your settings and return to the Active Devices table.
The percentage of time that the device is actively sending a signal on the radio band or channel.
To filter the output of this table to show only specific duty cycle values or a range of values types, click the icon in the column heading then select one of the following options: n n
Select Any to display all entries, regardless of duty cycle value.
To display entries within a specific range of duty cycles, enter the minimum duty cycle percentage in the Min field and enter the maximum duty cycle percentage in the Max field.
Click OK to save your settings and return to the Active Devices table.
ArubaOS 6.5.3.x
| User Guide Spectrum Analysis | 770
Parameter
Discovered
Activity Duration
Channels Affected
Description
The time at which the device was first discovered by the spectrum monitor or hybrid
AP.
To filter the output of this table to show devices discovered within a specific time, click the icon in the column heading.
Select Any to display all entries, regardless of when the device was discovered.
To display entries for devices discovered within a specific time range:
1. Select the button by the Less than drop down list.
2. Click the Less than drop-down list and select either Less than or More than to limit the output of this table to devices discovered earlier or after a specified number of hours or minutes.
3. Enter the number of hours or minutes in the time range you want apply to this filter.
4. Click the min.
drop down list and select either min.
or hrs.
to define the time range in minutes or hours.
5. Click OK to save your settings and return to the Active Devices table.
Amount of time that the device has been active.
To filter the output of this table to show devices that have been active within a specific time range, click the icon in the column heading.
Select Any to display all entries, regardless of how long the device has been active.
To display entries for devices active for a specific time range:
1. Select the button by the > symbol.
2. Click drop-down list with the > symbol and select either > (greater than), < (less than), <= (less than or equal to), or >= (more than or equal to) to limit the output of this table to devices that have been active for a specified time range.
3. Enter the number of hours or minutes in the time range you want apply to this filter.
4. Click the min.
drop down list and select either min.
or hrs.
to define the time range in minutes or hours.
5. Click OK to save your settings and return to the Active Devices table.
Radio channels affected by the device’s transmission. The Active Devices table for a spectrum monitor shows entries for all devices by default, regardless of the channels their transmissions may affect.
To filter the output of this table to show devices that affect a specific channel or range of channels, click the icon in the column heading.
n n
Select Any to display all entries, regardless of the channels that device may affect.
Select Single Channel , then enter the channel value to only display devices that affect the specified channel.
n n
Select Range of Channels , then enter the lower and upper channels in the channel range to filter the output to show only those devices whose transmissions affect the specified channel range. This option is only available for tables created by spectrum monitors, not hybrid APs.
Select Specified Channels to show only those devices whose transmissions affect selected channels. If you choose this option, you can click the none checkbox to show only those devices whose transmissions do not affect any other channels, select all to show devices whose transmissions affect any channel, or click the check boxes by individual channel numbers to show only those devices whose output affect those selected channels. This option is only available for tables created by spectrum monitors, not hybrid APs.
n Click OK to save your settings and return to the Active Devices table.
NOTE: This option is not available for Active Devices tables created by a hybrid AP, because each hybrid AP monitors a single channel only.
771 | Spectrum Analysis ArubaOS 6.5.3.x | User Guide
Parameter
Device ID
Description
The spectrum monitor or hybrid AP applies a unique device ID per device type to each device it detects on the radio channel.
To display the entry for a device that matches a single device ID, click the icon in the column heading and enter the device ID. Click OK to save your settings and return to the Active Devices table.
Center Frequency
(MHz)
Signals from a wireless device can spread beyond the boundaries of an individual
802.11 channel. This table column shows the center frequency for the device’s transmission, in megahertz.
Occupied Bandwidth Channel bandwidth used by the device, in megahertz.
Active Devices Trend
The Active Devices Trend chart is a line chart that shows the numbers of Wi-Fi and non-Wi-Fi devices seen on each radio channel during the displayed time interval. When you hover your mouse over any line in the chart, a tooltip displays the number of active devices for the selected device type. The example in
shows that there are 27 active Wi-Fi APs on channel 157 of the 5 GHz radio band.
Figure 124 Active Devices Trend Graph
An Active Devices Trend chart created by a hybrid AP displays data for the single channel monitored by that device. For spectrum monitors, the Active Devices Trend chart can display values for up to five different channels and device types. These graphs show the following data by default: n n
For SMs on the 2.4 GHz radio band, Wi-Fi APs on channel 1, 6, and 11.
For SMs on the 5 GHz band, Wi-Fi APs on channel 36, 40, and 44.
describes the other values that can be displayed in the Active Devices Trend chart. Click the down arrow in the upper right corner of this chart, then click the Options menu to access the Active Devices Trend
ArubaOS 6.5.3.x
| User Guide Spectrum Analysis | 772
configuration settings. Once you have configured the desired parameters, click OK at the bottom of the
Options menu to save your settings and return to the spectrum dashboards.
Table 170: Active Devices Trend Options
Parameter
Band
Show Trend for Last
Channel Numbering
Show lines for these channels
Description
Radio band displayed in this graph (2.4 GHz or 5 GHz).
Amount of elapsed time for which this chart should display data.
This parameter is not configurable for graphs created by hybrid APs or spectrum monitor radios that use the 2.4 GHz radio band. A hybrid AP on a 20 MHz channel sees 40 MHz Wi-Fi data as non-Wi-Fi data. For spectrum monitors using the 5 GHz radio band, click the Channel Numbering drop-down list and select either 20 MHz or 40 MHz channel numbering to identify a channel numbering scheme for the graph. Graphs for AP radios that support 802.11ac include an additional 80MHz option for very-high-throughput channels.
The Active Devices Trend chart can display values for up to five different device types on different channels for a spectrum monitor, or a single device type for a hybrid AP.
To choose which type of data each line should represent, click the channel number drop-down list and select a channel within the radio band, then click the device type drop-down list and select one of the following device types.
n n n n
WiFi (AP)
Microwave (This option is only available for 2.4 GHz radios)
Bluetooth (This option is only available for 2.4 GHz radios)
Fixed Freq (Others) n n n n n n n n
Fixed Freq (Cordless Phones)
Fixed Freq (Video)
Fixed Freq (Audio)
Freq Hopper (Others)
Freq Hopper (Cordless Network)
Freq Hopper (Cordless Base)
Freq Hopper Xbox (This option is only available for 2.4 GHz radios)
Microwave (Inverter) (This option is only available for 2.4 GHz radios) n Generic Interferer
Select the checkbox beside each channel and device entry to show that information on the chart, or deselect the checkbox to hide that information. For more information on non-Wi-Fi device types detected by a spectrum monitor, see
Working with Non-Wi-Fi Interferers on page 793 .
Channel Metrics
This stacked bar chart can show one of three different types of channel metrics; channel utilization , channel availability , or channel quality .
This chart displays channel utilization data by default, showing both the percentage of each monitored channel that is currently being used by Wi-Fi devices, and the percentage of each channel being used by non-Wi-Fi devices and 802.11 adjacent channel interference (ACI).
ACI refers to the interference on a channel created by a transmitter operating in an adjacent channel. A transmitter on a nonadjacent or partially overlapping channel may also cause interference, depending on the transmit power of the interfering transmitter and the distance between the devices. In general, ACI may be caused by a Wi-Fi transmitter or a non-Wi-Fi interferer. However, whenever the term ACI appears in Spectrum Analysis graphs, it refers to the ACI caused by Wi-Fi transmitters. The channel utilization option in the Channel Metrics Chart shows the percentage of the channel utilization due to both ACI and non-Wi-Fi interfering devices. Unlike the ACI shown in the
Interference Power chart, the ACI shown in this graph indicates the percentage of channel time that is occupied by
ACI or unavailable for Wi-Fi communication due to ACI.
773 | Spectrum Analysis ArubaOS 6.5.3.x | User Guide
The Channel Metrics graph can also show channel availability, the percentage of each channel that is available for use, or display the current relative quality of selected channels in the 2.4 GHz or 5 GHz radio bands.
Spectrum monitors can display data for all channels in their selected band. Hybrid APs display data for their one monitored channel only.
In the spectrum analysis feature, channel quality is a relative measure that indicates the ability of the channel to support reliable Wi-Fi communication. Channel quality, which is represented as a percentage in this chart, is a weighted metric derived from key parameters that can affect the communication quality of a wireless channel, including noise, non-Wi-Fi (interferer) utilization and duty-cycles, and certain types of retries. Note that channel quality is not directly related to Wi-Fi channel utilization, as a higher quality channel may or may not be highly used.
When you hover your mouse over any bar in the chart, a tooltip displays the metric value for that individual channel. The example below shows that 61% of channel 3 is being consumed by non-Wi-Fi devices and 802.11
adjacent channel interference.
Figure 125 Channel Metrics Graph
describes the parameters that can be displayed in the Channel Metrics graph. Click the down arrow in the upper right corner of this chart then click the Options menu to access these configuration settings.
Once you have configured the desired parameters, click OK at the bottom of the Options menu to save your settings and return to the spectrum dashboards.
ArubaOS 6.5.3.x
| User Guide Spectrum Analysis | 774
Table 171: Channel Metrics Options
Parameter
Band
Description
Channel
Numbering
Channel Range
Display Mode
Radio band displayed in this graph.
For spectrum monitor radios using the 5 GHz radio band, click the Band drop-down list and select 5 GHz upper , 5GHz middle or 5Ghz lower to display data for that portion of the 5 Ghz radio band. This parameter is not configurable for graphs created by hybrid APs or spectrum monitor radios that use the 2.4 GHz radio band.
This parameter is not configurable for graphs created by hybrid APs or spectrum monitor radios that use the 2.4 GHz radio band. A hybrid AP on a 20 MHz channel sees 40 MHz Wi-Fi data as non-Wi-Fi data. For spectrum monitors using the 5 GHz radio band, click the Channel Numbering drop-down list and select either 20 MHz or
40 MHz channel numbering to identify a channel numbering scheme for the graph.
Graphs for AP radios that support 802.11ac include an additional 80MHz option for very-high-throughput channels.
For graphs created by spectrum monitors, specify a channel range to determine which channels appear in this graph. Click the first drop-down list to select the lowest channel in the range, then click the second drop-down list to select the highest channel to appear in the graph.
This graph displays all channels within the spectrum monitor’s radio band by default.
NOTE: This parameter is not configurable for graphs created by hybrid APs.
Select Channel Quality to show the relative quality of the channel. Channel Quality is a weighted metric derived from key parameters which include noise, non-Wi-Fi
(interferer) utilization and duty-cycles, and certain types of retries.
Select Channel Availability to show the percentage of the channel that is unused and available for additional Wi-Fi traffic.
Select Channel Utilization to show both the percentage of the channel that is currently used by Wi-Fi devices, and the percentage of each channel that is being used by non-802.11 devices or 802.11 adjacent channel interference (ACI).
Channel Metrics Trend
By default, this line chart shows the current relative quality of selected channels in the 2.4 GHz or 5 GHz radio bands over a period of time. The Channel Metrics Trend chart can also be configured to display trends for the current availability of selected channels, or the percentage of availability for those channels. Spectrum monitors can display data for up to five different channels. Hybrid APs display data for their one monitored channel only.
For more information on how the spectrum analysis feature determines the quality of a channel, see
When you hover your mouse over any line in the chart, a tooltip displays channel quality or availability data for that individual channel at the selected time.
775 | Spectrum Analysis ArubaOS 6.5.3.x | User Guide
Figure 126 Channel Metrics Trend Chart
describes the other parameters that can be displayed in the Channel Metrics Trend output. Click the down arrow in the upper right corner of this chart then click the Options menu to access these configuration settings. Once you have configured the desired parameters, click OK at the bottom of the Options menu to save your settings and return to the spectrum dashboard.
Table 172: Channel Metrics Trend Options
Parameter Description
Band
Show Trend for Last
Channel numbering
Show Lines for These
Channels
Radio band displayed in this graph (2.4 GHz or 5 GHz).
The Channel Quality Trend chart shows channel quality or channel availability for the past 10 minutes by default. To view data for a different time range, click the
Show Trend for Last drop-down list and select one of the following options: n n n
10 minutes
30 minutes
1 hour
This parameter is not configurable for graphs created by hybrid APs or spectrum monitor radios that use the 2.4 GHz radio band. A hybrid AP on a 20 MHz channel sees 40 MHz Wi-Fi data as non-Wi-Fi data. For spectrum monitors using the 5
GHz radio band, click the Channel Numbering drop-down list and select either
20 MHz or 40 MHz channel numbering to identify a channel numbering scheme for the graph. Graphs for AP radios that support 802.11ac include an additional
80MHz option for very-high-throughput channels.
The Channel Quality Trend chart for a spectrum monitor can display channel quality, channel availability, or channel utilization values for up to five different channels on the selected radio band. Charts for hybrid APs can display data for the one channel monitored by that hybrid AP radio.
To choose which type of data each line should represent on a chart for a spectrum monitor, click the channel number drop-down list and select a channel within the radio band, then click the second drop-down list and select either Channel Quality , or Channel Availability .
Select the checkbox beside each channel entry to show that information on the chart, or deselect the checkbox to hide that information.
ArubaOS 6.5.3.x
| User Guide Spectrum Analysis | 776
Channel Summary Table
The channel summary table provides a summarized or aggregated view of key statistics. Spectrum monitors display spectrum analysis data seen on all channels in the selected band, and hybrid APs display data from the one channel they are monitoring. The example in
below shows that a spectrum monitor sees 44
Valid APs and 52% channel utilization on channel 40 in the 5GHz radio band.
Figure 127 Channel Summary Table
Spectrum monitor radios using the 5 GHz radio band can display channels using either 20 MHz or 40 MHz channel numbering. Spectrum monitor radios that support 802.11ac can also display 80MHz channels. To toggle between these channel numbering modes, click the down arrow in the upper right corner of the graph titlebar, then click either Show 20 MHz Channels , Show 40 MHz Channels or Show 80 MHz Channels .
Click any of the column headings to sort the information in the table by that column criteria. Make a column wider or narrower by clicking the border of a column heading and dragging the border to a new position.
describes the output of the Channel Summary table.
Table 173: Channel Summary Table Parameters
Parameter Description
Channel
Valid APs
Not Valid APs
Non Wi-Fi Devices
Center Freq. (GHz)
Channel Util. (%)
Radio channel being monitored by the spectrum monitor or hybrid AP
Number of known APs seen on the network.
Number of unknown or invalid APs seen on the network.
Number of Non-Wi-Fi (interfering) devices detected/classified by the spectrum monitor.
Center frequency of the Wi-Fi signals sent on that radio channel.
Percentage of the channel currently being used by devices on the network.
777 | Spectrum Analysis ArubaOS 6.5.3.x | User Guide
Parameter
Max AP Power (dBm)
Max Interference (dBm)
SNIR (dB)
Description
Signal strength of the AP that has the maximum signal strength on a channel.
Signal strength of the non-Wi-Fi device that has the highest signal strength.
The Signal-to-Noise-and-Interference Ratio (SNIR) is the ratio of signal strength to the combined levels of interference and noise on that channel.
This value is calculated by determining the maximum noise-floor and interference-signal levels, and then calculating how strong the desired signal is above this maximum.
Device Duty Cycle
The Device Duty Cycle Chart is a stacked bar chart that shows the duty cycle of each device type on a channel.
The duty cycle is the percentage of time each device type operates or transmits on that channel. Though Wi-Fi devices do not transmit if there is another Wi-Fi or non-Wi-Fi device active at that time, most non-Wi-Fi devices do not follow such a protocol for transmissions. Because these devices operate independently without regard to any other devices operating on the same channel, the total duty cycle of all device types may add up to more than 100% on a channel. For example, one or more video bridges may be active on a channel, each with a
100% duty cycle. The same channel may have a cordless transmitter with a 10% duty cycle and a microwave oven with a 50% duty cycle. In this example, the Device Duty Cycle chart shows all three device types with their respective duty cycle percentages.
A hybrid AP on a 20 MHz channel will see 40 MHz Wi-Fi data as non-Wi-Fi data.
Spectrum monitors display spectrum analysis data seen on all channels in the selected band, and hybrid APs display data from the one channel they are monitoring. The example below shows data from a spectrum monitor monitoring all channels in the 2.4 Ghz band.
ArubaOS 6.5.3.x
| User Guide Spectrum Analysis | 778
Figure 128 Device Duty Cycle
describes the parameters you can use to customize the Device Duty Cycle chart. Click the down arrow in the upper right corner of this chart, then click the Options menu to access these configuration settings. Once you have configured the desired parameters, click OK at the bottom of the Options menu to save your settings and return to the spectrum dashboards.
779 | Spectrum Analysis ArubaOS 6.5.3.x | User Guide
Table 174: Device Duty Cycle Options
Parameter Description
Band
Channel
Numbering
Channel
Range
Show
Radio band displayed in this graph.
For spectrum monitor radios using the 5 GHz radio band, click the Band drop-down list and select 5 GHz upper , 5 GHz middle or 5 Ghz lower to display data for that portion of the
5 Ghz radio band. This parameter is not configurable for graphs created by hybrid APs or spectrum monitor radios that use the 2.4 GHz radio band.
This parameter is not configurable for graphs created by hybrid APs or spectrum monitor radios that use the 2.4 GHz radio band. A hybrid AP on a 20 MHz channel sees 40 MHz Wi-Fi data as non-Wi-Fi data. For spectrum monitors using the 5 GHz radio band, click the Channel
Numbering drop-down list and select either 20 MHz or 40 MHz channel numbering to identify a channel numbering scheme for the graph. Graphs for AP radios that support
802.11ac include an additional 80 MHz option for very-high-throughput channels.
For graphs created by spectrum monitors, specify a channel range to determine which channels appear in this graph. Click the first drop-down list to select the lowest channel in the range, then click the second drop-down list to select the highest channel to appear in the graph.
This graph displays all channels within the spectrum monitor’s radio band by default.
NOTE: This parameter is not configurable for graphs created by hybrid APs.
This graph can display values for up to five different device types on different channels for a spectrum monitor, or a single device type for a hybrid AP monitoring a single channel.
To choose which type of data each line should represent, click the channel number dropdown list and select a channel within the radio band, then click the device type drop-down list and select one of the following device types n WiFi (AP) n n n n
Microwave (This option is only available for 2.4 GHz radios)
Bluetooth (This option is only available for 2.4 GHz radios)
Fixed Freq (Others)
Fixed Freq (Cordless Phones) n n n n n n n
Fixed Freq (Video)
Fixed Freq (Audio)
Freq Hopper (Others)
Freq Hopper (Cordless Network)
Freq Hopper (Cordless Base)
Freq Hopper Xbox (This option is only available for 2.4 GHz radios)
Microwave (Inverter) (This option is only available for 2.4 GHz radios) n Generic Interferer
NOTE: For more information on non-Wi-Fi device types detected by a spectrum monitor, see
Working with Non-Wi-Fi Interferers on page 793 .
Channel Utilization Trend
The Channel Utilization Trend chart is a line chart that shows the percentage of total utilization on each channel over a time interval. The channel utilization includes the utilization due to Wi-Fi as well as utilization due to non-
Wi-Fi interferers and Adjacent Channel Interference (ACI).
For additional information on how the spectrum analysis feature measures ACI, see
.
This graph can show data recorded for the last ten, thirty, or sixty minutes. Spectrum monitors display spectrum analysis data seen on all channels in the selected band, and hybrid APs display data from the one channel they are monitoring. When you hover your mouse over any line in the chart, a tooltip shows the percentage of the channel being utilized at the specified time. The example in
shows that channel 1 was 70% used at the selected time in the chart.
ArubaOS 6.5.3.x
| User Guide Spectrum Analysis | 780
Figure 129 Channel Utilization Trend
describes the parameters you can use to customize the Channel Utilization Trend chart. Click the down arrow in the upper right corner of this chart, then click the Options menu to access these configuration settings. Once you have configured the desired parameters, click OK at the bottom of the Options menu to save your settings and return to the spectrum dashboards.
Table 175: Channel Utilization Trend Options
Parameter
Intervals
Description
Band
Channel Numbering
Show
The Channel Utilization Trend chart shows channel quality or channel availability for the past 10 minutes by default. To view data for a different time range, click the
Intervals drop-down list and select one of the following options: n
10 minutes n n
30 minutes
1 hour
Radio band displayed in this graph (2.4 GHz or 5 GHz).
This parameter is not configurable for graphs created by hybrid APs or spectrum monitor radios that use the 2.4 GHz radio band. A hybrid AP on a 20 MHz channel sees 40 MHz Wi-Fi data as non-Wi-Fi data. For spectrum monitors using the 5 GHz radio band, click the Channel Numbering drop-down list and select either 20 MHz or 40 MHz channel numbering to identify a channel numbering scheme for the graph. Graphs for AP radios that support 802.11ac include an additional 80MHz option for very-high-throughput channels.
To select individual channels you want to display on this chart, click the checkbox by a channel entry, then click the channel drop-down list to select the channel to display. To hide a channel, uncheck the checkbox by that channel number.
Devices vs Channel
This stacked bar chart shows the current number of devices using each channel in the radio’s frequency band.
This chart can show separate per-channel statistics for the numbers of Wi-Fi devices, cordless phones, bluetooth devices, microwaves, and other non-Wi-Fi devices.
781 | Spectrum Analysis ArubaOS 6.5.3.x | User Guide
If a device affects more than one channel, it is recorded as a device on all channels it affects. For example, if a
20Mhz Wi-Fi AP has a center frequency of 2437 Mhz (channel 6) it is counted as a device on channels 3-9 because it affects all those channels. Similarly, if a channel-hopping device uses all channels within a frequency band, it is counted as a device on all channels in that band.
When you hover the mouse over any part of the chart, a tooltip shows the numbers of the device type currently using that channel. The example in
shows that the spectrum monitor can detect 42 APs on channel 5.
Figure 130 Devices vs Channel
describes the parameters you can use to customize the Devices vs Channel chart. Click the down arrow in the upper right corner of this chart, then click the Options menu to access these configuration settings. Once you have configured the desired parameters, click OK at the bottom of the Options menu to save your settings and return to the spectrum dashboards.
ArubaOS 6.5.3.x
| User Guide Spectrum Analysis | 782
Table 176: Devices vs Channel Options
Parameter
Band
Description
Channel
Numbering
Channel Range
Show
Radio band displayed in this graph.
For spectrum monitor radios using the 5 GHz radio band, click the Band drop-down list and select 5 GHz upper , 5GHz middle or 5Ghz lower to display data for that portion of the 5 Ghz radio band. This parameter is not configurable for graphs created by hybrid APs or spectrum monitor radios that use the 2.4 GHz radio band.
This parameter is not configurable for graphs created by hybrid APs or spectrum monitor radios that use the 2.4 GHz radio band. A hybrid AP on a 20 MHz channel sees
40 MHz Wi-Fi data as non-Wi-Fi data. For spectrum monitors using the 5 GHz radio band, click the Channel Numbering drop-down list and select either 20 MHz or 40
MHz channel numbering to identify a channel numbering scheme for the graph.
Graphs for AP radios that support 802.11ac include an additional 80MHz option for very-high-throughput channels.
For graphs created by spectrum monitors, specify a channel range to determine which channels appear in this graph. Click the first drop-down list to select the lowest channel in the range, then click the second drop-down list to select the highest channel to appear in the graph.
This graph displays all channels within the spectrum monitor’s radio band by default.
NOTE: This parameter is not configurable for graphs created by hybrid APs.
This graph can show data for up to five different device types. To show how many devices of a specific type are sending a signal on the selected channel range, click the show checkbox by that device, then click the device drop-down list and select one of the following device types.
n WiFi (AP) n n
Microwave (This option is only available for 2.4 GHz radios)
Bluetooth (This option is only available for 2.4 GHz radios) n n n n n n
Fixed Freq (Others)
Fixed Freq (Cordless Phones)
Fixed Freq (Video)
Fixed Freq (Audio)
Freq Hopper (Others)
Freq Hopper (Cordless Network) n n n n
Freq Hopper (Cordless Base)
Freq Hopper Xbox (This option is only available for 2.4 GHz radios)
Microwave (Inverter) (This option is only available for 2.4 GHz radios)
Generic Interferer
NOTE: For more information on non-Wi-Fi device types detected by a spectrum monitor, see
Working with Non-Wi-Fi Interferers on page 793 .
FFT Duty Cycle
The FFT Duty Cycle chart is a line chart that shows the duty cycle for each frequency bin. The width of the each frequency bin depends on the resolution bandwidth of the spectrum monitor. The spectrum analysis feature considers a frequency bin to be used if the detected power in that bin is at least 20 dB higher than the nominal noise floor on that channel. The FFT Duty Cycle provides a more granular view of the duty cycle per bin as opposed to the aggregated channel utilization reported in the Channel Metrics chart.
A hybrid AP on a 20 MHz channel will see 40 MHz Wi-Fi data as non-Wi-Fi data.
This chart can show the duty cycle over the last second, the maximum FFT duty cycle measured for all samples taken over the last N sweeps, and the greatest FFT duty cycle recorded since the chart was last reset.
783 | Spectrum Analysis ArubaOS 6.5.3.x | User Guide
Figure 131 FFT Duty Cycle
This chart shows the current duty cycle for devices on all channels being monitored by the spectrum monitor radio by default.
describes the other optional parameters you can use to customize the FFT Duty
Cycle table. Click the down arrow in the upper right corner of this chart, then click the Options menu to access these configuration settings. Once you have configured the desired parameters, click OK at the bottom of the
Options menu to save your settings and return to the spectrum dashboards.
Table 177: FFT Duty Cycle Options
Parameter
Band
Description
Channel Numbering
X-Axis
Channel Range
Radio band displayed in this graph.
For spectrum monitor radios using the 5 GHz radio band, click the Band drop-down list and select 5 GHz upper , 5GHz middle or 5Ghz lower to display data for that portion of the 5 Ghz radio band. This parameter is not configurable for graphs created by hybrid APs or spectrum monitor radios that use the 2.4 GHz radio band.
This parameter is not configurable for graphs created by hybrid APs or spectrum monitor radios that use the 2.4 GHz radio band. A hybrid AP on a 20 MHz channel sees 40 MHz Wi-Fi data as non-Wi-Fi data. For spectrum monitors using the 5 GHz radio band, click the Channel Numbering drop-down list and select either 20 MHz or 40 MHz channel numbering to identify a channel numbering scheme for the graph. Graphs for AP radios that support 802.11ac include an additional 80MHz option for very-high-throughput channels.
Select either Channel or Frequency to show the duty cycle for a range of channels or frequencies.
If you selected Channel in the X-Axis parameter, you must also specify a channel range to determine which channels appear in the x-axis of this chart. Click the first drop-down list to select the lowest channel in the range, then click the second dropdown list to select the highest channel to appear in the chart.
NOTE: This parameter is not configurable for graphs created by hybrid APs.
ArubaOS 6.5.3.x
| User Guide Spectrum Analysis | 784
Parameter
Center Frequency
Span
Show
Description
If you selected Frequency in the X-Axis parameter, enter the frequency, in MHz, that you want to appear in the center of the x-axis of this chart.
If you selected Frequency in the X-Axis parameter, specify the size of the range of frequencies around the selected center frequency. If you set a frequency span of
100 MHz, for example, the chart shows the FFT duty cycle for a range of frequencies from 50MHz lower to 50 MHz higher than the selected center.
Select a checkbox to display that information on the FFT Duty Cycle chart.
n Duty Cycle: The percentage of duty cycle the channel or frequency was actively used.
n n
Max Hold: The maximum recorded percentage of active duty cycles for the channel frequency since the chart was last reset. To clear this setting, click the down arrow at the end of the title bar for this graph and select Reset MaxHold .
Max of last sweeps: This chart shows the maximum percentage of active duty cycles for the channel of frequency recorded during the last 10 sweeps, by default. To change the number of sweeps used to determine this value, enter a number from 2 to 20, inclusive. To clear this setting, click the down arrow at the end of the title bar for this graph and select Reset MaxNSweep .
Interference Power
The Interference Power chart displays various power levels of interest, including the Wi-Fi AP with maximum signal strength, noise, and interferer types with maximum signal strength. The ACI displayed in the Interference
Power Chart is the ACI power level based on the signal strength(s) of the Wi-Fi APs on adjacent channels. A higher ACI value in Interference Power Chart does not necessarily mean higher interference, because the AP that is contributing to the maximum ACI may or may not be very actively transmitting data to other clients at all times. The ACI power levels are derived from the signal strength of the beacons.
This chart displays the noise floor of each selected channel in dBm. The noise floor of a channel depends on the noise figure of the RF components used in the radio, temperature, presence of certain types of interferers or noise, and the width of the channel. For example, in a clean RF environment, a 20 MHz channel has a noise floor around -95 dBm and a 40 MHz channel has a noise floor around -92 dBm. Certain types of fixedfrequency continuous transmitters such as video bridges, fixed-frequency phones, and wireless cameras typically elevate the noise floor seen by the spectrum monitor. Other interferers such as frequency-hopping phones, Bluetooth, and Xbox may not affect the noise floor of the radio. A Wi-Fi radio can only reliably decode
Wi-Fi signals that are a certain dB above the noise floor. Therefore estimating and understanding the actual noise floor of the radio is critical to understanding the reliability of the RF environment.
The chart also includes information about the AP on each channel with the highest power level. You can hover your mouse over an AP on the chart to view the AP’s name, SSID, and current power level. The example below shows that the AP with the maximum power on channel 157 has the SSID qa-ss , and a power level of -55dBm.
785 | Spectrum Analysis ArubaOS 6.5.3.x | User Guide
Figure 132 Interference Power
describes the other optional parameters you can use to customize the interference power chart.
Click the down arrow in the upper right corner of this chart then click the Options menu to access these configuration settings. Once you have configured the desired parameters, click OK at the bottom of the
Options menu to save your settings and return to the spectrum dashboards.
Table 178: Interference Power Options
Parameter
Band
Description
Channel
Numbering
Radio band displayed in this graph.
For spectrum monitor radios using the 5 GHz radio band, click the Band drop-down list and select 5 GHz upper , 5GHz middle or 5Ghz lower to display data for that portion of the 5 Ghz radio band. This parameter is not configurable for graphs created by hybrid APs or spectrum monitor radios that use the 2.4 GHz radio band.
This parameter is not configurable for graphs created by hybrid APs or spectrum monitor radios that use the 2.4 GHz radio band. A hybrid AP on a 20 MHz channel sees
40 MHz Wi-Fi data as non-Wi-Fi data. For spectrum monitors using the 5 GHz radio band, click the Channel Numbering drop-down list and select either 20 MHz or 40
MHz channel numbering to identify a channel numbering scheme for the graph. Graphs for AP radios that support 802.11ac include an additional 80MHz option for very-highthroughput channels.
ArubaOS 6.5.3.x
| User Guide Spectrum Analysis | 786
Parameter
Show
Channel Range
Description
By default, this chart displays data for the current noise floor, adjacent channel interference (ACI), and the maximum AP power level for each channel. To display interference power levels form other devices, click the show checkbox then click the show drop-down list and select one of the following device types.
n
Microwave (This option is only available for 2.4 GHz radios) n n
Bluetooth (This option is only available for 2.4 GHz radios)
Fixed Freq (Others) n n n n n n
Fixed Freq (Cordless Phones)
Fixed Freq (Video)
Fixed Freq (Audio)
Freq Hopper (Others)
Freq Hopper (Cordless Network)
Freq Hopper (Cordless Base) n n
Freq Hopper Xbox (This option is only available for 2.4 GHz radios)
Microwave (Inverter) (This option is only available for 2.4 GHz radios) n Generic Interferer
For more information on non-Wi-Fi device types detected by a spectrum monitor, see
Working with Non-Wi-Fi Interferers on page 793 .
For graphs created by spectrum monitors, specify a channel range to determine which channels appear in this graph. Click the first drop-down list to select the lowest channel in the range, then click the second drop-down list to select the highest channel to appear in the graph.
This graph displays all channels within the spectrum monitor’s radio band by default.
NOTE: This parameter is not configurable for graphs created by hybrid APs.
Quality Spectrogram
This plot shows the channel quality statistics for selected range of channels or frequencies. This chart can also be configured to show channel availability, the percentage of each channel that is unused and available for additional traffic.
Channel Quality is a weighted metric derived from key parameters which include noise, non-Wi-Fi (interferer) utilization and duty-cycles and certain types of retries. Quality levels are indicated by a range of colors between dark blue, which represents a higher channel quality, and red, which represents a lower channel quality.
Channel availability is indicated by a range of colors between dark blue, which represents 100% channel availability, and red, which represents 0% availability.
For additional information on interpreting an Aruba Spectrogram plot, see
.
The Spectrum Analysis Quality Spectrogram chart measures channel data each second, so after every 5-second sweep, the newest data appears as a thin colored line on the bottom of the chart. Older data is pushed up higher on the chart until it reaches the top of the spectrogram and ages out. The example below shows the
Aruba Quality Spectrogram chart after it has recorded over 1,500 seconds of FFT data.
787 | Spectrum Analysis ArubaOS 6.5.3.x | User Guide
Figure 133 Quality Spectrogram
When you hover your mouse over any part of the spectrogram, a tooltip shows the devices the spectrum monitor detected on that frequency, the BSSID of the device (if applicable), the power level of the device in dBm, the time the device was last seen by the spectrum monitor, and the channels affected by the device.
The following table describes the other optional parameters you can use to customize the Quality
Spectrogram. Click the down arrow in the upper right corner of this chart, then click the Options menu to access these configuration settings. Once you have configured the desired parameters, click OK at the bottom of the Options menu to save your settings and return to the spectrum dashboards.
Table 179: Quality Spectrogram Options
Parameter Description
Band
Channel
Numbering
Channel
Range
Radio band displayed in this graph.
For spectrum monitor radios using the 5 GHz radio band, click the Band drop-down list and select 5 GHz upper , 5GHz middle or 5Ghz lower to display data for that portion of the
5 Ghz radio band. This parameter is not configurable for graphs created by hybrid APs or spectrum monitor radios that use the 2.4 GHz radio band.
This parameter is not configurable for graphs created by hybrid APs or spectrum monitor radios that use the 2.4 GHz radio band. A hybrid AP on a 20 MHz channel sees 40 MHz Wi-Fi data as non-Wi-Fi data. For spectrum monitors using the 5 GHz radio band, click the
Channel Numbering drop-down list and select either 20 MHz or 40 MHz channel numbering to identify a channel numbering scheme for the graph. Graphs for AP radios that support 802.11ac include an additional 80MHz option for very-high-throughput channels.
Specify a channel range to determine which channels appear in the x-axis of this chart. Click the first drop-down list to select the lowest channel in the range, then click the second dropdown list to select the highest channel to appear in the chart.
NOTE: This parameter is not configurable for graphs created by hybrid APs.
Real-Time FFT
The Real-time FFT chart displays the instantaneous Fast Fourier Transform (FFT) signature of the RF signal seen by the radio. The Fast Fourier Transform (FFT) converts an RF signal from time domain to frequency domain.
The frequency domain representation divides RF signals into discrete frequency bins; small frequency ranges whose width depends on the resolution bandwidth of the spectrum monitor (that is, how many Hz are represented by a single signal strength value). Each frequency bin has a corresponding signal strength value.
ArubaOS 6.5.3.x
| User Guide Spectrum Analysis | 788
Because there may be a large number of FFT signatures received by the radio every second, an algorithm selects one FFT sample to display in the Real-time FFT chart every second.
A hybrid AP on a 20 MHz channel will see 40 MHz Wi-Fi data as non-Wi-Fi data.
This chart can show an average for all samples taken over the last second, the maximum FFT power measured for all samples taken over ten channel sweeps, and the greatest FFT power recorded since the chart was last reset. When you hover your mouse over any line, a tooltip shows the power level and channel or frequency level represented by that point in the graph. When you hover your mouse over a frequency level (within the blue brackets on the graph), a tooltip shows the types of devices seen on that frequency, and each device’s
BSSID, power level, channels affected and the time the device was last seen by the spectrum monitor.
Figure 134 Real-TIme FFT
This chart shows the maximum power level recorded for any device on all channels or frequencies monitored by the spectrum monitor radio by default.
describes the other parameters you can use to customize the Real-time FFT chart. Click the down arrow in the upper right corner of this chart, then click the Options menu to access these configuration settings. Once you have configured the desired parameters, click OK at the bottom of the Options menu to save your settings and return to the spectrum dashboards.
Table 180: Real-Time FFT Options
Parameter Description
Band
Channel
Numbering
Radio band displayed in this graph.
For spectrum monitor radios using the 5 GHz radio band, click the Band drop-down list and select 5 GHz upper , 5GHz middle or 5Ghz lower to display data for that portion of the
5 Ghz radio band. This parameter is not configurable for graphs created by hybrid APs or spectrum monitor radios that use the 2.4 GHz radio band.
This parameter is not configurable for graphs created by hybrid APs or spectrum monitor radios that use the 2.4 GHz radio band. A hybrid AP on a 20 MHz channel sees 40 MHz Wi-Fi data as non-Wi-Fi data. For spectrum monitors using the 5 GHz radio band, click the Channel
Numbering drop-down list and select either 20 MHz or 40 MHz channel numbering to identify a channel numbering scheme for the graph. Graphs for AP radios that support
802.11ac include an additional 80MHz option for very-high-throughput channels.
789 | Spectrum Analysis ArubaOS 6.5.3.x | User Guide
Parameter Description
X-Axis
Channel
Range
Center
Frequency
Span
Y-axis
Show
Select either Channel or Frequency to show FFT power for a range of channels or frequencies. If you select Frequency , you must select the radio frequency on which this chart should center, and determine the span of frequencies for the graph.
If you selected Channel in the X-Axis parameter, you must also specify a channel range to determine which channels appear in the X-axis of this chart. Click the first drop-down list to select the lowest channel in the range, then click the second drop-down list to select the highest channel to appear in the chart.
NOTE: This parameter is not configurable for graphs created by hybrid APs.
If you selected Frequency in the X-Axis parameter, enter the frequency, in MHz, that you want to appear in the center of the x-axis of this chart.
If you selected Frequency in the X-Axis parameter, specify the size of the range of frequencies around the selected center frequency. If you set a frequency span of 100 MHz, for example, the chart shows the FFT duty cycle for a range of frequencies from 50MHz lower to 50 MHz higher than the selected center.
Select the range of power levels, in -dBm, to appear in the y-axis of this chart. Enter the lower value in the right field, and the higher value in the left field.
Select the checkbox by the following items to display that information on the FFT Power chart.
n
Average: the average power level of all samples recorded during the last 10 sweeps.
n n
Maxthe The highest power recorded during the last 10 channel sweeps.
Max Hold: the highest maximum power level recorded since the chart data was reset. To clear this setting, click the down arrow at the end of the title bar for this graph and select
Clear Max Hold .
Swept Spectrogram
A spectrogram is a chart that shows how the density of the quantity being plotted varies with time. The spectrum analysis Swept Spectrogram chart plots real-time FFT Maximums, real-time FFT Averages, or the FFT
Duty Cycle. In this swept spectrogram, the x-axis represents frequency or channel and the y-axis represents time. Each line in the swept spectrogram corresponds to the data displayed in the Real-Time FFT or FFT Duty
Cycle chart.
A hybrid AP on a 20 MHz channel will see 40 MHz Wi-Fi data as non-Wi-Fi data.
The power or duty cycle values recorded in each sweep are mapped to a range of colors. In the average or maximum FFT power Swept Spectrogram charts, the signal strength levels are indicated by a range of colors between dark blue, which represents -90 dBm, and red, which represents a higher -50 dBm. The duty cycle
Swept Spectrogram chart shows the percentage of the time tick interval that the selected channel or frequency was broadcasting a signal. These percentages are indicated by a range of colors between dark blue, which represents a duty cycle of 0% percent, and red, which represents a duty cycle of 100%.
A spectrogram plot is a complex chart that can display a lot of information. If you are not familiar with these types of charts, they may be difficult to interpret. The following illustrations can help explain how FFT power data is rendered in a spectrogram format.
The example in
shows how an FFT Power chart could appear if a single data measurement was plotted as a simple line graph.
ArubaOS 6.5.3.x
| User Guide Spectrum Analysis | 790
Figure 135 Simple Line Graph of FFT Power Data
Now, suppose that each channel’s FFT power level was also represented by a color that corresponded to that specific FFT power level. In the example below, channel 12 has a FFT power level of -50 dBm, represented by the color red. Channel 1 has a FFT power level of -85 dBm, represented by dark blue.
Figure 136 FFT Power Line Graph with Color
If the graph was then flattened so each channel’s FFT power for that single1-second sweep was represented only by a color (and not by a value on the y-axis), the graph could then appear as follows:
Figure 137 FFT Power Spectrogram Sample
791 | Spectrum Analysis ArubaOS 6.5.3.x | User Guide
The spectrum analysis Swept Spectrogram measures FFT power levels or duty cycle data each second, so after every 1-second sweep, the newest data appears as a thin colored line on the bottom of the chart. Older data is pushed up higher on the chart until it reaches the top of the spectrogram and ages out. The example below shows the Swept Spectrogram chart after it has recorded over 300 seconds of FFT data.
Figure 138 Swept Spectrogram
describes the parameters you can use to customize the Swept Spectrogram chart. Click the down arrow in the upper right corner of this chart, then click the Options menu to access these configuration settings. Once you have configured the desired parameters, click OK at the bottom of the Options menu to save your settings and return to the spectrum dashboards.
Table 181: Swept Spectrogram Options
Parameter
Band
Channel Numbering
X-Axis
Description
Radio band displayed in this graph.
For spectrum monitor radios using the 5 GHz radio band, click the Band drop-down list and select 5 GHz upper, 5GHz middle , or 5Ghz lower to display data for that portion of the 5 Ghz radio band. This parameter is not configurable for graphs created by hybrid APs or spectrum monitor radios that use the 2.4 GHz radio band.
This parameter is not configurable for graphs created by hybrid APs or spectrum monitor radios that use the 2.4 GHz radio band. A hybrid AP on a 20 MHz channel sees 40 MHz Wi-Fi data as non-Wi-Fi data. For spectrum monitors using the 5 GHz radio band, click the Channel Numbering drop-down list and select either 20 MHz or 40 MHz channel numbering to identify a channel numbering scheme for the graph. Graphs for AP radios that support 802.11ac include an additional 80MHz option for very-high-throughput channels.
Select either Channel or Frequency to show FFT power or duty cycles for a range of channels or frequencies. If you select Frequency , you must select the radio frequency on which this chart should center, and determine the span of frequencies for the graph.
ArubaOS 6.5.3.x
| User Guide Spectrum Analysis | 792
Parameter
Channel Range
Center Frequency
Span
Color-Map Range
Show
Description
If you selected Channel in the X-Axis parameter, you must also specify a channel range to determine which channels appear in the x-axis of this chart. Click the first drop-down list to select the lowest channel in the range, then click the second dropdown list to select the highest channel to appear in the chart.
NOTE: This parameter is not configurable for graphs created by hybrid APs.
If you selected Frequency in the X-Axis parameter, enter the frequency, in MHz, that you want to appear in the center of the x-axis of this chart.
If you selected Frequency in the X-Axis parameter, specify the size of the range of frequencies around the selected center frequency. If you set a frequency span of
100 MHz, for example, the chart shows the swept spectrogram for a range of frequencies from 50MHz lower to 50 MHz higher than the selected center.
If this chart is configured to show average or maximum FFT values, the default color range on this chart represents values from -50dBm (red) to -90dBm (blue). If you would like the color range on this chart to represent a different range of FFT power levels, enter this range in the from and to entry blanks.
For example, if you defined a color-map range from -60 to -80, then any FFT power level at or above -60 dBm appears as red, and any FFT power level at or below -80 appears blue. Only the channel or frequency qualities between -60 dBm and -80 dBm would be represented by gradiented colors within the color range.
If this chart is configured to show the FFT duty cycle , the default color range on this chart represents duty cycles from 0% (red) to 100% (blue). If you would like the color range on this chart to represent a different range of FFT duty cycle percentages, enter this range in the from and to entry blanks.
For example, if you defined a color-map range from 25 to 75, then any FFT duty cycle at or below 25% appears as red, and any FFT duty cycle at or below 75% appears blue. Only the duty cycle levels between 25% and 75% would be represented by gradiented colors within the color range.
NOTE: If your swept spectrogram is showing a single color only, you may need to increase the color map range to display a greater range of values.
Select FFT Avg , FFT Max or FFT Duty Cycle to select the type of data you want to appear in this chart.
n n n n n n
Working with Non-Wi-Fi Interferers
The following table describes each type of non-Wi-Fi interferer detected by the spectrum analysis feature.
These devices appear in the following charts:
Active Devices
Active Devices Table
Active Devices Trend
Device Duty Cycle
Device vs Channel
Interference Power
793 | Spectrum Analysis ArubaOS 6.5.3.x | User Guide
Table 182: Non-Wi-Fi Interferer Types
Non-Wi-Fi
Interferer
Description
Bluetooth
Fixed
Frequency
(Audio)
Fixed
Frequency
(Cordless
Phones)
Fixed
Frequency
(Video)
Frequency
Hopper (Xbox)
Frequency
Hopper (Other)
Any device that uses the Bluetooth protocol to communicate in the 2.4 GHz band is classified as a Bluetooth device. Bluetooth uses a frequency hopping protocol.
Some audio devices such as wireless speakers and microphones also use fixed frequency to continuously transmit audio. These devices are classified as frequency video devices). These devices are classified as
Phones) .
Fixed Frequency (Audio)
Some cordless phones use a fixed frequency to transmit data (much like the fixed
Fixed Frequency (Cordless
.
Fixed
Frequency
(Other)
Frequency
Hopper
(Cordless Base)
Frequency
Hopper
(Cordless
Network)
Video transmitters that continuously transmit video on a single frequency are classified as
Fixed Frequency (Video ). These devices typically have close to a 100% duty cycle. These types of devices may be used for video surveillance, TV or other video distribution, and similar applications.
All other fixed frequency devices that do not fall into one of the above categories are classified as Fixed Frequency (Other ). Note that the RF signatures of the fixed frequency audio, video and cordless phone devices are very similar, and that some of these devices may be occasionally classified as Fixed Frequency (Other).
Frequency hopping cordless phone base units transmit periodic beacon-like frames at all times. When the handsets are not transmitting (i.e., no active phone calls), the cordless base is classified as Frequency Hopper (Cordless Base ).
When there is an active phone call and one or more handsets are part of the phone conversation, the device is classified as Frequency Hopper (Cordless Network ). Cordless phones may operate in 2.4 GHz or 5 GHz bands. Some phones use both 2.4 GHz and 5
GHz bands (for example, 5 GHz for Base-to-handset and 2.4 GHz for Handset-to-base).
These phones may be classified as unique Frequency Hopper devices on both bands.
The Microsoft Xbox device uses a frequency hopping protocol in the 2.4 GHz band. These devices are classified as Frequency Hopper (Xbox ).
When the classifier detects a frequency hopper that does not fall into one of the above categories, it is classified as Frequency Hopper (Other ). Some examples include IEEE
802.11 FHSS devices, game consoles, and cordless/hands-free devices that do not use one of the known cordless phone protocols.
ArubaOS 6.5.3.x
| User Guide Spectrum Analysis | 794
Non-Wi-Fi
Interferer
Microwave
Microwave
(Inverter)
Generic
Interferer
Description
Common residential microwave ovens with a single magnetron are classified as a
Microwave . These types of microwave ovens may be used in cafeterias, break rooms, dormitories and similar environments. Some industrial, healthcare or manufacturing environments may also have other equipment that behave like a microwave and may also be classified as a Microwave device.
Some newer-model microwave ovens have inverter technology to control the power output and may have a duty cycle close to 100%. These microwave ovens are classified as
Microwave (Inverter) . Dual-magnetron industrial microwave ovens with higher duty cycle may also be classified as Microwave (Inverter). As in the Microwave category described above, there may be other equipment that behave like inverter microwaves in some industrial, healthcare or manufacturing environments. Those devices may also be classified as Microwave (Inverter).
Any non-frequency hopping device that does not fall into one of the other categories described in this table is classified as a Generic Interferer . For example, a Microwave-like device that does not operate in the known operating frequencies used by the Microwave ovens may be classified as a Generic Interferer. Similarly, wide-band interfering devices may be classified as Generic Interferers.
Understanding the Spectrum Analysis Session Log
The spectrum analysis Session Log tab displays times the spectrum monitors and hybrid APs connected to or disconnected from the spectrum client during the current browser session. This tab also shows changes in a hybrid AP’s scanning channel caused by changes to the hybrid AP’s 802.11a or 802.11g radio profile or automatic channel changes by the DFS or ARM features. The latest entry in the session log is also displayed in a footer at the bottom of the Spectrum Monitors and Spectrum Dashboard window. When you close the browser and end your spectrum analysis session, the session log is cleared.
The example in
shows that a 2.4 GHz radio on hybrid AP was connected to the spectrum analysis client, its channel changed twice, then was disconnected from the spectrum client.
Figure 139 Spectrum Analysis Session Logs
Viewing Spectrum Analysis Data
You can use the command-line interface to view spectrum analysis data from any spectrum monitor, even if that spectrum monitor is currently sending data to another spectrum monitor client’s WebUI.
795 | Spectrum Analysis ArubaOS 6.5.3.x | User Guide
shows the commands that display spectrum analysis data in the CLI interface.
Table 183: Spectrum Analysis CLI Commands
Command Description show ap spectrum ap-list show ap spectrum channel-metrics show ap spectrum channel-summary show ap spectrum client-list show ap spectrum debug show ap spectrum device-duty-cycle show ap spectrum device-history show ap spectrum device-list show ap spectrum device-log
Shows spectrum data seen by an access point that has been converted to a spectrum monitor.
Shows channel utilization information for a 802.11a or
802.11g radio band, as seen by a spectrum monitor
Displays a summary of the 802.11a or 802.11g channels seen by a spectrum monitor.
Shows details for Wi-Fi clients seen by a specified spectrum monitor.
Sub-commands under this command save spectrum analysis channel information to a file on the controller.
Shows the current duty cycle for devices on all channels being monitored by the spectrum monitor radio.
Displays spectrum analysis history for non-interfering devices.
Shows summary table and channel information for non-Wi-Fi devices currently seen by the spectrum monitor.
Shows a time log of add and delete events for non-Wi-Fi devices.
show ap spectrum device-summary Shows the numbers of Wi-Fi and non-Wi-Fi device types on each channel monitored by a spectrum monitor.
show ap spectrum interference-power Shows the interference power detected by a 802.11a or
80211g radio on a spectrum monitor.
show ap spectrum monitors Shows a list of APs currently configured as spectrum monitors.
show ap spectrum technical-support Saves spectrum data for later analysis by your Aruba technical support representative.
Recording Spectrum Analysis Data
The spectrum analysis tool allows you to record up to 60 continuous minutes (or up to 10 Mb) of spectrum analysis data. By default, each spectrum analysis recording displays data for the Real-Time FFT, FFT Duty Cycle,
Interference Power and Swept Spectrogram charts, however, you can view recorded device data for any the spectrum analysis charts supported by that spectrum monitor radio. Configurable recording settings allow you to start a recording session immediately, or schedule a recording to begin at a later date and time. Each recording can be scheduled to end after a selected amount of time has passed, or continue on until the recorded data file reaches a specified size. You can save the file to your spectrum monitor client, then play back that data at a later time.
Creating a Spectrum Analysis Record
To record spectrum analysis data for later analysis:
ArubaOS 6.5.3.x
| User Guide Spectrum Analysis | 796
1. Navigate to the Monitoring > Spectrum Analysis > Spectrum Dashboards window.
2. Click Record at the top of the window. The New Recording popup window appears.
3. Click the Record From link, and select the spectrum monitor whose data you want to record.
4. Next, decide whether you want the recording to start immediately, or at a later scheduled time. If you want the recording to start immediately, select When the OK button is clicked . To schedule a different starting time for the recording, click the date and time drop-down lists to select a starting month, day, year and time.
5. The recording continues until either the specified amount of time has passed, or until the recording files reaches a selected size. Click the Length of recording reaches drop down list and select the amount of time the recording should last, or click the Data file reaches drop down list and select the maximum file size for the recording.
6. Click OK to save your settings. If you selected the When the OK button is clicked in step 5, the recording begins.
Figure 140 Recording Spectrum Analysis Data
While the recording is in progress, a round, red recording icon and recording status information appears at the top of the spectrum dashboard. You can view data for other spectrum monitors and charts while the recording is in progress. If you want to stop the recording before recording period has finished, click Stop by the recording status information. When you the Stop , a popup window appears and allows you to stop and delete the current recording, stop and save the recording in its current state (before it has completed), or continue recording again.
Saving the Recording
After the recording has ended, either because the recording period has elapsed, the recording maximum file size has been reached, the Spectrum Monitor Recording Complete window appears and displays information for the current recording.
Figure 141 Saving Spectrum Analysis Data
797 | Spectrum Analysis ArubaOS 6.5.3.x | User Guide
To save the recording file:
1. From the Spectrum Monitor Recording Complete window, click Continue .
2. A Save As window appears and prompts you to select a file name for the recording and a location to save the file.
3. Click Save .
Playing a Spectrum Analysis Recording
There are two ways to play back a spectrum recording. You can use the playback feature in the spectrum dashboard, or view recordings using the Aruba RFPlayback tool downloaded from the Aruba website.
Playing a Recording in the Spectrum Dashboard
The spectrum monitor does not have to be subscribed to your spectrum analysis client in order to play back a recording in the spectrum dashboard. However, you cannot play back an existing recording in the spectrum dashboard while another recording session is currently in progress.
To play a spectrum analysis recording in the spectrum dashboard:
1. Navigate to Monitoring > Spectrum Analysis > Spectrum Dashboards window.
2. Click the Recording View/Play link at the top of the window.
3. Click Load File For Playback .
4. An Open dialog box appears and prompts you to browse to and select the file you want to open.
5. Click Open .
6. Click the triangular play icon at the top of the window to start playing back the recording.
Recorded data for the selected spectrum monitor and dashboard view appears in the spectrum analysis dashboard. You can replace any of the graphs in the playback window with a different graph type while replaying the recording. A playback progress bar at the top of the window shows what part of the recording currently appears on the dashboard. If you pause the recording, you can click and drag the red slider on this progress bar to advance to or replay any part of the current record.
Playing a Recording Using the RFPlayback Tool
The Aruba RFPlayback tool can play spectrum recordings created in this and earlier versions of ArubaOS. Aruba uses the Adobe AIR application to display spectrum recording information. If you have not done so already, follow the steps below to download and install the free Adobe AIR application and the Aruba spectrum playback tool.
1. Download the Adobe Air application from http://get.adobe.com/air/ and install it on the client on which you want to play spectrum recordings.
2. Next, download the spectrum playback installation file from the Aruba website.
3. Open the folder containing the spectrum installation file, and double-click the spectrum.air icon to install the spectrum playback tool. You will be prompted to select the folder in which you want to install this tool.
Once you have installed the Aruba RFPlayback tool, follow the steps below to load and view a spectrum recording.
1. Start the Spectrum playback application.
2. Click Load File for Playback . An Open dialog box appears and prompts you to browse to and select the file you want to open.
3. Click the triangular play icon at the top of the window play the recording.
The RFPlayback tool also allows you to select and display different graph types while the recording playback is in progress. A playback progress bar at the top of the window shows what part of the recording is displayed in
ArubaOS 6.5.3.x
| User Guide Spectrum Analysis | 798
the playback tool. If you pause the recording, you can click and drag the red slider on this progress bar to advance to or replay any part of the current record.
Figure 142 Playing a Recording with the Spectrum Playback Tool
Troubleshooting Spectrum Analysis
Verifying Spectrum Monitors Support for One Client per Radio
Each spectrum monitor radio can only send information to one client at a time. If you log into a controller and the spectrum monitor dashboard does not display any data for the selected radio, another user may be logged in to the controller at that time. Note that dual-radio spectrum monitors may be accessed by two clients; one client for each radio.
Converting a Spectrum Monitor Back to an AP or Air Monitor
If want to convert a spectrum monitor radio back to AP or AM mode but the radio still comes up as a spectrum monitor, access the command-line interface and see if that spectrum monitor appears in the output of the show ap spectrum local-override command. If the spectrum monitor does appear in the local override profile table, issue the command ap spectrum local-override no override ap-name <apame> spectrumband <spectrum-band> to remove the local override for that spectrum monitor and return the radio to AP or
AM mode.
Troubleshooting Browser Issues
If you access the spectrum analysis dashboard using the Safari 5.0 browser, clicking the backspace button may return you to the previous browser screen. Avoid using the backspace button when changing dashboard view names or chart options.
799 | Spectrum Analysis ArubaOS 6.5.3.x | User Guide
If you are recording spectrum analysis data or playing back a spectrum analysis recording using a Mac client, do not minimize the browser window while the recording is in progress, as that may cause the Adobe Flash player to pause.
Loading a Spectrum View
Saved spectrum view preferences may not be backwards compatible with the spectrum analysis dashboard in earlier versions of ArubaOS. If you downgrade to an earlier version of ArubaOS and your client is unable to load a saved spectrum view in the spectrum dashboard, access the CLI in enable mode and issue the command ap spectrum clear-webui-view-settings to delete the saved spectrum views and display default view settings in the spectrum dashboard.
Troubleshooting Issues with Adobe Flash Player 10.1 or Later
Removing focus from the browser window displaying the spectrum analysis dashboard may cause Adobe Flash
10.1 or later to stop updating the spectrum charts to reduce CPU usage. When you restore focus to the spectrum analysis dashboard, you may see the spectrum charts update rapidly as the display catches up.
Recorded data may be inaccurate if you navigate away from the spectrum window during a recording. Flash
10.0 does not have this issue.
Understanding Spectrum Analysis Syslog Messages
The spectrum analysis feature can send four different types of syslog messages: wifi add, wifi delete, non-wifi add, and non-wifi delete. All messages are in the wireless category at the syslog severity level NOTICE.
The four syslog message types appear in the following formats: n n n n
AM: Spectrum: new wifi device found = [addr:%s] SSID = [ssid:%s] BSSID [bssid_str:%s] DEVICE ID [did:%d]
AM: Spectrum: deleting wifi device = [addr:%s] SSID = [ssid:%s] BSSID [bssid_str:%s] DEVICE ID [did:%d]
AM: Spectrum: new non-wifi device found = DEVICE ID [did:%u] Type [dytpe:%s] Signal [sig:%u] Freq
[freq:%u]KHz Bandwidth [bw:%u]KHz
AM: Spectrum: deleting non-wifi device = DEVICE ID [did:%d] Type [dtype:%s]
Playing a Recording in the RFPlayback Tool
The Aruba RFPlayback tool is periodically updated to support improvements to the ArubaOS Spectrum Analysis feature. The RFPlayback tool can play spectrum recordings created in the same version of ArubaOS or earlier releases. If the RFPlayback tool cannot load a newer recording, you may need to download a more recent version of the tool from the Aruba website.
ArubaOS 6.5.3.x
| User Guide Spectrum Analysis | 800
Chapter 35
Dashboard Monitoring
The ArubaOS dashboard monitoring functionality provides an enhanced visibility into your wireless network performance and usage within a controller. This allows you to easily locate and diagnose WLAN issues in the controller.
The dashboard monitoring is available in the WebUI. To monitor and troubleshoot RF issues in the WLAN, click the Dashboard tab. The following pages in the Dashboard page allows you to view various performance and usage information: n n n n n n n n n n n n
Additionally, you can view the context sensitive help for each field in the Dashboard UI by clicking the help link at the top-right corner of the UI. The field for which the help has been defined appears as green. You can turn off the help by clicking Done .
You can use the Search functionality to find the matched results for clients, APs, and WLANs. Click the count on the search results of clients, APs, and WLANs to navigate the related summary page with the filters applied.
WAN
The WAN page displays the Wide Area Network (WAN) summary details for VLANs.
The WAN page is available only in branch controllers.
displays a snapshot of the WAN summary dashboard:
ArubaOS 6.5.3.x
| User Guide Dashboard Monitoring | 801
Figure 143 WAN Summary Dashboard
The WAN summary dashboard page contains the following tables: n n n n n n
Status : Displays the Link status and WAN Status for VLANs. For each VLAN, the green represents an up status and red represents a down status for the Link and WAN.
Throughput : Displays the In and Out traffic for VLANs. The Throughput table has four tabs for different uplinks. First tab shows throughput of VLANs having high priority followed by other VLAN data based on its priority. Clicking on each tab loads In and Out traffic throughput data for that particular VLAN.
Latency : Displays Latency data for available VLANs. Each line represents one VLAN.
Alerts : Lists the last five alerts with time stamp and description.
Usage : Displays traffic based on Application Category or Application.
Compression : Displays compression that occurred on all VLANs together.
Performance
The Performance page displays the performance details of the wireless clients and APs connected to the controller.
Clients
This section displays the total number of wireless clients connected to the controller. You can view the distribution of clients in different client health ranges, SNR ranges, associated data rate ranges, and data transfer speed ranges using the histograms and distributed charts. You can click on the hyperlinked number to view the data in different screens with histograms.
An AP’s client health is the efficiency at which that AP transmits downstream traffic to a particular client. This value is determined by comparing the amount of time the AP spends transmitting data to a client to the amount of time that would be required under ideal conditions, that is, at the maximum Rx rate supported by client, with no data retries.
A client health metric of 100% means the actual airtime the AP spends transmitting data is equal to the ideal amount of time required to send data to the client. A client health metric of 50% means the AP is taking twice as long as is ideal, or is sending one extra transmission to that client for every packet. A metric of 25% means the AP is taking four times longer than the ideal transmission time, or sending 3 extra transmissions to that client for every packet.
To understand histogram information, see
Using Dashboard Histograms on page 803
.
802 | Dashboard Monitoring ArubaOS 6.5.3.x | User Guide
APs
This section displays the following performance details of the APs on the controller: n n n n n
Overall goodput
Frame rate distribution of the APs
Channel quality
To client or from client frame rates
Percentage of frames dropped
You can click the hyperlinked text and histograms to view the AP specific performance information as a trend chart. Additionally, you can view the distribution of the APs in different noise floor ranges, channel utilization ranges, and non-Wi-Fi interference ranges using the histograms. To understand histogram information, see
Using Dashboard Histograms on page 803
.
Using Dashboard Histograms
Dashboard histograms are a visual representation of the distribution of the wireless clients, access points, and radios across different performance parameters in the controller. Histograms help you to quickly identify any performance issues in the network from the color of the distribution. For example, critical ranges of the distribution are highlighted in red and normal ranges are highlighted in green.
You can view the number of clients or APs falling in each range of the distribution with a hyperlink. You can also perform the following tasks on the histograms to get additional information on the clients and APs in the distribution: n n n n
View Client or AP details —Click the hyperlinked number to view the details of the clients or APs in a popup window.
Sort —Click a column header of the clients or APs table to sort the complete list based on the entries on the active column. You can also use the sort icon that appears when you click on a column for sorting.
Filter —Click the filter icon and select the filter criterion on any column to filter the entries.
Close pop-up window —Click on the close icon to close the client or AP details pop-up window.
n n n n n n
Usage
The Usage page displays the usage summary of the following on the controller:
Clients & APs : The active wireless clients, status of APs, and its usage.
Top APs : The list of APs with the number of clients on the controller. The list of APs is in the descending order based on the number of clients associated with an AP. You can filter the APs for the 2.4 GHz and 5
GHz radio band options.
Radios : The radios and clients connected to an AP, usage, and frame types transmitted and received by the radio.
Devices : The pie chart of the clients based on the device type. Clicking on the pie chart segment opens the client details page filtered on the device type.
AirGroup : All the AirGroup services available and number of servers offering the service. It is aggregated by the total number of AirGroup servers sorted by the services they advertise. For more information, see
Controller Dashboard Monitoring on page 1028
.
Overall Usage : The total number of clients and APs that have the low usage and throughput data in the last 15 minutes.
ArubaOS 6.5.3.x
| User Guide Dashboard Monitoring | 803
n n n n n n
Usage by WLANs : The total number of clients per WLAN and throughput data in the last 15 minutes. You can view only three WLANs in a graph and the remaining WLANs are displayed in other graph. Click the graph to view the blown up chart and information on the Clients page.
Apps by Usage: The charts with the list of application based on the usage. You can click on the specific chart to view the application details in the Firewall Application page.
Apps by Sessions : The list of top five applications with the session information in descending order.
Call Quality vs. Client Health : This is a new graph added in ArubaOS 6.4. This graph displays the corelation between the VoIP call quality and the VoIP client health of every Unified Communication and
Collaboration (UCC) call. For more information, see
UCC Dashboard in the WebUI on page 964 .
Top Sessions : The top five sessions by user with usage details.
Collaboration Apps : The list of applications with sessions and usage details.
You can click the hyperlinked text in the sections above to view the lists and trend chart in the last 15 minutes and summary of the APs and clients in the new windows. For more information on the columns, you can view the context sensitive help for each field in the Dashboard UI by clicking the help link at the top right corner of the UI.
Potential Issues
The Potential Issues page displays the total number of radios and wireless clients that may have potential issues in the network. You can click on the total number to view the trend of the clients and radios with potential issues in the last 15 minutes. You can also view the number of clients or radios that have a specific potential issue in each radio band.
The potential issues that a client may have are: n n n
Low SNR : clients that have signal to noise ratio of 30 dBm or lower.
Low speed : clients that have a connection speed of 36 Mbps or lower.
Low goodput : clients that have an average data rate of 24 Mbps or lower.
The potential issues that a radio may have are: n n n n n
High noise floor : radios that have a noise floor of -85 dB or greater.
Busy channel : radios that have a channel utilization of 80% or greater.
High non-Wi-Fi interference : radios that have a non-Wi-Fi interference of 20% or greater.
Low goodput : radios that have an average data rate of 24 Mbps or lower.
High client association : radios that have 15 or more clients connected.
You can click on the hyperlinked number to view the details of the respective clients or radios in the bottom pane of the page. You can perform the following tasks on the details table: n n
Sort : click a column header of the table to sort the complete list based on the entries on the active column.
You can also use the sort icon that appears when you click on a column for sorting.
View or hide columns : click the drop-down menu on the top right corner of the table header and select
Custom Columns ; choose the Edit Current View option to select the columns that you want to view.
n n
Traffic Analysis
Starting from ArubaOS 6.5, the AppRF page has been renamed to Traffic Analysis . This page has the following tabs:
804 | Dashboard Monitoring ArubaOS 6.5.3.x | User Guide
n n n
This feature is supported only in 7000 Series and 7200 Series controllers, and requires the PEF-NG license.
AppRF
AppRF is an application visibility and control feature and was introduced in ArubaOS 6.4.2. AppRF performs deep packet inspection (DPI) of local traffic and detects over 1500 applications on the network. AppRF allows you to configure both application and application category policies within a given user role.
This tab displays the summary of all traffic in the controller. This is the default page.
Figure 144 AppRF Page
The AppRF page displays the PEF summary of all the sessions in the controller aggregated by users, devices, destinations, applications, WLANs, and roles.The applications, application categories, and other containers are represented in box charts instead of pie charts.
Enable DPI to enhance the benefit of the existing visualization or dashboard, To enable DPI, see the
section.
To view the AppRF dashboard in the WebUI:
1. Navigate to the Dashboard > Traffic Analysis .
2. Click on the link To enable this feature, click here to enable firewall visibility. To disable, click the
Disable Firewall Visibility link at the bottom the page.
The AppRF page is displayed.
Action Bar
The Action bar displays the total traffic depending on the filters applied, allows the user to configure per
Application, per Role, and Global Policy, and includes Action buttons namely, Block/Unblock, Throttle, and QoS.
Figure 145 Action Bar
ArubaOS 6.5.3.x
| User Guide Dashboard Monitoring | 805
Filters
You can click on any rectangle tile in a container and that filter is applied across all the containers.
For example: If you click on the Web rectangle in the Application Categories container, Application
Categories == Web filter is applied to all other containers (Roles, WLANs, Application, Destination and Devices).
See the following figure.
Figure 146 Single Filter Applied
You can apply multiple filters from different containers by clicking on multiple rectangle tiles in various containers.
For example: If you click on the Web rectangle in the Application Categories container and the https rectangle under Application , the remaining containers (Roles, WLANs, Destination and Devices) will be filtered on Application categories == web and Application == https. See the following figure.
Figure 147 Multiple Filters Applied
The action bar reflects the total traffic based on the filter applied. For example, see
and
Figure 148 Total traffic with Web Filter
806 | Dashboard Monitoring ArubaOS 6.5.3.x | User Guide
Figure 149 Total traffic with Web and https Filter
The action buttons are disabled if the applied filter contains anything apart from Role and Application or Role and
Application category.
To remove filters, click on Remove filter in the container that filter is removed across all the containers.
Details
Clicking on Details navigates you to the corresponding details page with data filtered by all selected rectangle when a filter is applied, The Details link changes to User filtered by <filter> in that container. See
and
In the WLANs rectangle tile, wired indicates the traffic initiated by wired users and traffic from uplink ports.
Figure 150 Details
Figure 151 User filtered by <filter>
Clicking on Details or User filtered by <filter> shows the user table, See
and
ArubaOS 6.5.3.x
| User Guide Dashboard Monitoring | 807
Figure 152 Details View
Figure 153 User filtered by <filter>- Details View
Block/Unblock, Throttle, and QoS Action Buttons
The pop-up window that is displayed for block/unblock, throttle, or QoS depends on the filters applied.
Upon clicking OK , the corresponding CLI commands are executed and the pop-up window closes retaining the filters in the AppRF main page. When filters are not applied, all the pop-up windows allow the user to configure global or per –role configuration.
The following table shows the pop-up window with respect to the Action button and the filter applied:
808 | Dashboard Monitoring ArubaOS 6.5.3.x | User Guide
Table 184: Pop-up Window with Respect to the Action Button and the Filter Applied
Action Button
Block/Throttle/QoS
Block
Block
Block
Block
Block
Throttle
Throttle
Throttle
Throttle
Throttle
QoS
QoS
Filter
Non-application/role ex: WLANS
No Filters
Application
Application Category
Application and Role
Application category and Role
No
Application
Application Category
Application and Role
Application category and Role
Application
Application Category
Config Level
No pop-up
Global and per role
Global
Global
Global and per role
Global and per role
Global and per role
Global
Global
Global and per role
Global and per role
Global
Global
Block/Unblock
This button allows you to permit/deny an application or an application category for a given role. You can create global and per-role rules.
For example, you can block the YouTube application, which belongs to the Streaming application category for the guest role within the enterprise.
Applying a New Rule Using AppRF
1. Click on Block/Unblock on the Action bar.
The Block/Unblock button changes to the Block button if a filter is applied. The pop-up window appears based on
the filters applied is shown in Table 184 . Click on
Show policy tables .
Block allows only permit action and priority setting.
2. To create a new Global rule: a. Click on the Global Policy tab, the following pop-up window appears:
ArubaOS 6.5.3.x
| User Guide Dashboard Monitoring | 809
Figure 154 Global Policy Tab b. Click on New.
The following pop-up window appears:
Figure 155 New Rule Pop-up Window c. Select an Application category , Application , Action , and Priority .
3. To create a new per-role rule: a. Click on the Per-role policies tab, the following pop-up window appears:
Figure 156 Per-role Policies Tab b. Select a role from the list, or click on New below the role pane to create a new role and select the newly created role.
810 | Dashboard Monitoring ArubaOS 6.5.3.x | User Guide
c. Select a policy from the list, or click on New below they policy pane to create a new policy and select the newly created policy.
d. Select an Application category , Application , Action , and Priority from the New Rule pop-up window, as shown in
.
4. Click on OK.
Throttle
This button allows you to limit the bandwidth usage of an application or an application category on a given role. So, you can set the upstream limit and downstream limit for an application or an application category on a given role.
For example, you can rate limit applications video streaming applications like YouTube, Netflix.
You can also view the bandwidth contract table and create a new bandwidth contract. See the following figure.
Figure 157 Throttle Application and New Bandwidth Contract
QoS
This button allows you to set the priority for a given application or an application category on a given role. For example, you can set the video/voice sessions originating from wireless users with a different priority to that of other web applications so that traffic would be prioritized accordingly in the your network.
ArubaOS 6.5.3.x
| User Guide Dashboard Monitoring | 811
Figure 158 QoS for Application Category Streaming
Web Content
Many applications are moving to the web and web being so dynamic in nature, ArubaOS 6.4.2.0 introduces web content control through the Web Content Classification (WebCC) feature. WebCC uses a cloud-based service to dynamically determine the types of websites being visited, and their safety.
ArubaOS 6.5.0.0 introduces support for the WebCC license; a subscription-based, per-AP license that supports web content classification features on an AP for the duration of the subscription period (up to 10 years per license). This license is mandatory for the WebCC feature to work in ArubaOS 6.5.0.0.
The implementation of WebCC feature can be viewed on this new web page.
When the WebCC feature is enabled, all web traffic (http and https) is classified. The classification is done in data path as the traffic flows through the controller and updates dynamically.
Aruba has partnered with Webroot ® , and uses the Webroot's URL database and the cloud look-up service to classify the web traffic. Aruba uses Webroot classified categories and score for web categories and reputation for WebCC.
The current policy enforcement model in Aruba relies on L3/L4 information of the packet or L7 information with Deep Packet Inspection (DPI) support to apply rules. WebCC complements this as the user is allowed to apply firewall policies based on web content category and reputation.
Benefits of WebCC:
1. Prevention of malicious malware, spyware, or adware by blocking known dangerous websites
2. Visibility into web content category-level
3. Visibility into web sites accessed by the user
To view the web content page from the WebUI, navigate to Dashboard > Traffic Analysis . Click on Web
Content tab. The following figure shows the Web Content page.
812 | Dashboard Monitoring ArubaOS 6.5.3.x | User Guide
Figure 159 Web Contents Page
The web content page includes the following containers: n
Web Categories: This chart shows traffic for web categories in tree chart presentation. All boxes in this chart is click-able. Clicking on a box filters rest of page data with the clicked web category as filter, and this chart is locked until the filter is removed by clicking on Remove filter on <web category> . For example, see the following figure.
Figure 160 Filter by Web Category n
Roles: This chart shows the for Roles using the web traffic in tree chart presentation. All role boxes are In this chart is click-able. Clicking on box filters rest of page data with the clicked Role as filter, and this chart is locked until the filter is removed by clicking on Remove filter on <role name> . For example, see the following figure.
ArubaOS 6.5.3.x
| User Guide Dashboard Monitoring | 813
Figure 161 Filter by Role n
All traffic by Reputation: The reputation traffic light chart shows the percentage of traffic based on reputation or score of web traffic in the controller. The reputation levels are Trustworthy, Low-Risk,
Moderate-Risk, Suspicious, and High-Risk. If there is no traffic on a specific reputation, then the corresponding reputation does not appear in the chart. The circles in this chart are click-able. Clicking on circle filters rest of page data with the selected reputation as filter and this chart is locked until the filter is removed by clicking on Remove filter on <reputation> . For example, see the following figure.
Figure 162 Filter by Reputation n
Category Views : A drop-down at the extreme right of reputation traffic lights allows selecting the category view. The view options are Top 9 and Top 6. Top 9 is the default view and displays predefined set of categories that need to be listed in categories by reputation chart. This also list the top 6 or top 9 categories based on traffic usage. The list updates automatically when filters are applied. The following figure shows an for Top 9 category view with reputation chart.
Figure 163 Category View- Top 9 n
Details Table: Click on the web category link above the Category view chart to display the details table as shown in the following figure.
814 | Dashboard Monitoring ArubaOS 6.5.3.x | User Guide
Figure 164 Category Views and Details n
The details table of the selected web category includes the following four columns: l
Website : Lists the website l l l
Risk : Reputation score of the website with image presentation
Traffic : Traffic of the website in total traffic of the selected category
User : The number of users using that website
User Table: Click on the number in the User column in the details table as shown in the following figure:
Figure 165 User Table
The user table includes the following columns: l l
User : Lists the users of the website
Traffic : Traffic of the user on the website
Web Content Filters
Web content tree chart filter behaves in the same way described in
. Filters can be applied to
Web Categories, Roles, and Reputation containers.
ArubaOS 6.5.3.x
| User Guide Dashboard Monitoring | 815
Following are the properties of container filters: n n n n
Clicking on any box in the tree chart or reputation traffic light chart will update whole page with the selected box as filter.
On clicking, the tree chart will freeze that chart and update rest of the page.
Filter will be applied only to non-freeze chart.
Reputation chart color won’t change upon selection.
The following figure shows an example with multiple filters:
Figure 166 Multiple Filters
WebCC Configuration in the WebUI
Configurations of policies from web content dashboard can be done with the help of the following
Block/Unblock, Throttle, and QoS Action Buttons. These buttons behave the same way as described in
Block/Unblock, Throttle, and QoS Action Buttons .
Block / Unblock
To permit or deny a rule for global policy or per-role policies for a web category, role, or reputation. To apply a policy, click on a on a web category, role, reputation, or a combination of these three container and click block.
Click OK . For example, the following two figures show applying a policy on web category filter and on Role +
Category + Reputation filter:
Figure 167 Policy on Web Category Filter
816 | Dashboard Monitoring ArubaOS 6.5.3.x | User Guide
Figure 168 Policy on Web Category + Reputation + Role Filter
Throttle
To apply bandwidth contract for a web category, role, or reputation. For example, the following figure shows the throttle applied to a category filter:
Figure 169 Throttle on Category Filter
When multiple bandwidth contracts exist, the precedence is as follows: n n n
WebCC Global bandwidth contract
Application bandwidth exception List
Application Category bandwidth exception List
ArubaOS 6.5.3.x
| User Guide Dashboard Monitoring | 817
n n n n n
App bandwidth contract
Application Category bandwidth contract
Web category bandwidth contract
Web reputation bandwidth contract
User bandwidth contract
QoS
To set the priority of the web category and reputation. For example, the following figure shows QoS on category and reputation filter:
Figure 170 QoS on Web Category + Reputation Filter
Additionally rules can be added in any of the following combination: n n n
Rules for Web category only
Rules for Reputation only
Rules for Web Category and Web Reputation combination
WebCC Configuration in the CLI
Enabling WebCC
Use the following command to enable WebCC using the CLI:
(host) (config) #firewall web-cc
Use the following command to configure WebCC per-role using the CLI:
(host) (config-role) #web-cc
New policy configuration
The new CLI extends the existing policy configuration to take web category or reputation or both. Use the following command to configure a new policy to create ACL rule with web category and reputation:
818 | Dashboard Monitoring ArubaOS 6.5.3.x | User Guide
(host) (config-sess-acl) #source destination proto-port/service/app/app-group <name> webcccategory <ctgry> webcc-reputation <score> action [log | mirror | time-range]
The following actions are supported when web category/reputation is selected: n n n n n n n n n n n
Deny
Permit
Blacklist
Classify-media
Disable-scanning
Dot1q-priority
Log
Mirror
Queue
Time-range
TOS
Example for WebCC policy configuration is as follows: ip access-list session url-filter any any web-cc-category educational-institutions permit any any web-cc-reputation suspicious deny any any any deny
Assuming that webcc categorization was done only for http traffic running on TCP 80, the above ACL is converted as follows in datapath for pre-classification ACL scan: ip access-list session url-filter any any tcp {80} permit any any tcp {80} deny any any any deny
Post-classification, ACL look-up will have the ACL as follows: ip access-list session url-filter any any tcp {80} WebCCCtgID 40 WebCCRep 1-100 permit any any tcp {80} WebCCRep 1-100 deny any any any deny
In case there exists an ACL rule to deny/permit a specific web category but is required to make an exception to allow/deny a specific URL or website, then this can be accomplished by configuring in the following manner:
1. First define a netdestination with one or more URLs to whitelist or blacklist
(config) #netdestination search
(config-dest) #name www.google.com
(config-dest) #name www.bing.com
(config-dest) #exit
2. Apply this netdestination to an ACL
(config) #ip access-list session whitelist
(config-sess-whitelist)#any alias search tcp 80 permit
(config-sess-whitelist)#any alias search tcp 443 permit
3. Apply this ACL to an user-role. The position of this ACL should be at the top. However, with global or rolespecific default ACLs this wouldn’t be possible.
(config) #user-role guest2
(config-role) #access-list session whitelist
If there a web-cc/app rule that is applicable globally across user-roles, then there is no way to override such behavior. This is a limitation.
ArubaOS 6.5.3.x
| User Guide Dashboard Monitoring | 819
WebCC Bandwidth Contract Configuration
With this feature, ArubaOS supports configuring WebCC category and reputation based bandwidth contract configuration/enforcement. This can be enforced globally for all user-roles, or can be enforced per user-role.
Use the following command to apply global WebCC based bandwidth contracts using the CLI:
(host) (config) #web-cc global-bandwidth-contract webcc-category/webcc-reputation <name> upstream/downstream mbits/kbits <value>
Use the following command to apply AAA bandwidth contracts using the CLI:
(host) (config) #aaa bandwidth-contract webcc mbits <value> n n
Use the following command to apply role-specific web-cc based bandwidth contracts using the CLI:
(host) (config) #user-role webcc
(host) (config-role) #bw-contract webcc-category/webcc-reputation <name> <contract> upstream/downstream
Debugging— The following show commands are introduced as part of this feature: n n n n n n n n n show web-cc category all : Displays all WebCC categories show web-cc reputation: Displays WebCC reputation show web-cc stats: Displays the statistics of WebCC module in CP show web-cc status: Display the status of Web-CC module in CP show web-cc global-bandwidth-contract: Displays configured WebCC bandwidth contract show datapath web-cc: Displays md5, web category, reputation, and age for each URL show datapath web-cc counters: Displays the number of URLs in cache, Classified and Unclassified sessions.
show datapath session web-cc: Displays Internal Flags, Pre Classification ACE Index, and Post
Classification ACE Index show gsm debug channel web_cc_info : Lists md5, Category, and Reputation for each URL. GSM entries are populated as and when URL cache entry is learned, and it is used for reporting the actual URLs being associated with user session entries.
The following clear command are introduced as part of this feature: n clear web-cc cache <md5_1> <md5_2> : Clears the WebCC cache entry from both data plane and GSM.
clear web-cc stats : Clears all WebCC statistics.
clear datapath web-cc counters : Clears configuration values and statistics in the WebCC datapath module.
Blocked Sessions
ArubaOS 6.5 introduces the support for system administrator to have the ability to look at blocked sessions for AppRF and WebCC on the controller dashboard. System administrators can see blocked sessions belonging to specific web-category (like news / sports / gambling) ,session belonging to specific app category.
This tab displays WebCC and AppRF sessions which are blocked by ACL through system logging or on the
WebUI interface.
Blocked session feature support in Firewall-Visibility process is enabled by default .Once the management server is configured, AMON feed generation is enabled by default. Only for system logging , enable blk-session option of firewall visibility CLI command.
In the controller WebUI, navigate to Dashboard > Traffic Analysis > Blocked Sessions to view blocked sessions. You can view this page for the following information:
820 | Dashboard Monitoring ArubaOS 6.5.3.x | User Guide
n n n n
Blocked by App Category : Blocked session data is seen in controller for AppRF ACLs. You can filter by clicking on any box in this container tree chart and the information in other containers update accordingly.
Blocked by Web Category : Blocked session data is seen in controller for WebCC ACLs. You can filter by clicking on any box in this container tree chart and the information in other containers update accordingly.
Blocked by Role : Blocked session data is seen in controller for role ACLs. You can filter by clicking on any box in this container tree chart and the information in other containers update accordingly.
Blocked Sessions table with filters: Displays data in the controller based on ACLs applied in WebCC,
AppRF, and role . However, you can filter the data in this table to list only Application Rules, Web Content
Rules, or Forwarding Rules.
To know more details on blocking an App category, see
and for Web Category, see
This following figure shows the Blocked Sessions tab:
Figure 171 Blocked Sessions Tab
Traffic
This dashboard displays the geolocation traffic map indicating the top countries/regions from where the traffic has originated (Inbound) or to which the traffic is destined (Outbound). A separate map is displayed for
Inbound and Outbound traffic. Traffic can be blocked/permitted by clicking on a specific region/country on the map.
To view the Traffic dashboard in the WebUI:
1. Navigate to the Dashboard > Traffic Analysis page.
2. Click Traffic tab, and select Inbound Traffic / Outbound Traffic to view the traffic in various countries.
ArubaOS 6.5.3.x
| User Guide Dashboard Monitoring | 821
Figure 172 Traffic tab
The Traffic tab is displayed only if the WebCC license is installed and the IP Classification option is enabled in the
Configuration > Advanced Services > Stateful Firewall > Global Settings tab, in the WebUI.
Details
The + icon zooms in to the region that you click on, and the icon restores the map to the size prior to zoom in.
The home icon resets the map to the original size. When you place the cursor on a particular country and depending on whether Inbound/Outbound traffic is selected, the relevant details are displayed. See
.
Figure 173 Traffic - Country Level Details
Click Block to block all outbound traffic destined to the selected country, this button is enabled only if all outbound traffic destined to the selected country is not currently blocked. Click Unblock to unblock all inbound traffic coming from the selected country.
Threats
This dashboard displays the geolocation threat map indicating the top countries/regions from where virus/spyware/malware/botnet attacks originated or are destined to.
822 | Dashboard Monitoring ArubaOS 6.5.3.x | User Guide
To view the Threats dashboard in the WebUI:
1. Navigate to the Dashboard > Traffic Analysis page.
2. Click Threats tab.
Figure 174 Threat tab
Support for geolocation based access policies for IPv6 addresses is not available.
Action Bar
The action bar includes Action buttons namely, Threats Map View , Threats List View , and Threats
Distribution View .
Figure 175 Action Bar
The Threats Map View displays a map of the world with countries color-coded to illustrate the number of threats detected. Following is a sample of the threat map and the number of threats that each color indicates.
ArubaOS 6.5.3.x
| User Guide Dashboard Monitoring | 823
Figure 176 Threat Map View
Details
The + icon zooms in to the region that you click on, and the icon restores the map to the size prior to zoom in.
The home icon resets the map to the original size. When you place the cursor on a particular country, the threats detected and the distribution is displayed.
Threat Map List
The Threats Map List displays a list of countries, the type of threat, and the source and destination IP.
Following is a sample of the threat map list.
824 | Dashboard Monitoring ArubaOS 6.5.3.x | User Guide
Figure 177 Threats Map List
Threats Distribution View
The Threats Distribution View displays Threats by Country and Threats by Type.
Figure 178 Threats Distribution View
Threats by Country
The Threats by Country treemap displays the threat count for the country selected. Click Details link under the Threats by Country treemap to view the Threats List View filtered for the selected country.
Threats by Type
The Threats by Type treemap displays a treemap with the number of threats grouped by type. Click Details link under the Threats by Type treemap to view the Threats List View filtered for the selected threat type.
ArubaOS 6.5.3.x
| User Guide Dashboard Monitoring | 825
AirGroup
The AirGroup page displays the information about AirGroup clients and servers. By default, these tables contain information for all active AirGroup clients and servers. You can filter the information in these tables by clicking the filter icon on any column heading and entering a string in the filter field.
The Dashboard >AirGroup page contains the following information for AirGroup Users and Servers:
Table 185: AirGroup Monitoring Information
Column
AirGroup Users
Service
IP address
MAC
Role
Wired/Wireless
AP Name
VLAN ID
Group(s)
AirGroup Type
Host Name
User Name
IP address
Role
AP Name
VLAN ID
Group(s)
AirGroup Type
Host name of the AirGroup server
User name given to a client that completed 802.1X authentication
Device IP address
Role assigned to the device’s user
Name of the AP to which the device is associated
ID of the VLAN to which the device is assigned
Displays the Group of the AirGroup user
Displays the type of the device
Wired/Wireless Type of connection between the device and the LAN
AirGroup Servers
Host Name Host name of the AirGroup server
Service(s) running on the server
AirGroup Server’s IP address
AirGroup Server’s MAC address
Role assigned to the AirGroup server
Type of connection between the device and the LAN
Name of the AP to which the device is associated
ID of the VLAN to which the server is assigned
Displays the Group of the AirGroup user
Displays the type of the device
For more information on the AirGroup feature, see
826 | Dashboard Monitoring ArubaOS 6.5.3.x | User Guide
Security
The Security page allows you to monitor the detection and protection of wireless intrusions in your network.
The two top tables— Discovered APs & Clients and Events —contain data as links. When these links are selected, they arrange, filter, and display the appropriate information in the lower table.
The term events in this document refers to security threats, vulnerabilities, attacks (intrusion or Denial of Service), and other related events.
UCC
The Unified Communication and Collaboration (UCC) Dashboard Aggregated Display shows an aggregated view of the UCC calls made in the controller. The administrator can see a top level view of the call quality assessment, and further drill down into a specific view based on the analysis required.
The UCC feature requires the PEFNG license.
Chart View
A new UCC tab is introduced under the Dashboard tab. Navigate to the Dashboard > UCC page to view UCC dashboard. Clicking the UCC hyperlink displays the following characteristics (in graphical format) of the UCC deployment.
Figure 179 UCC Dashboard l l
Call Volume – This graph displays the total number of calls made based on the UCC application type.
For example, SIP, Lync, SCCP, H.323, NOE, SVP, VOCERA, Wi-Fi calling, and FaceTime.
Call Quality – This graph displays the AP-to-Client call quality under the WLAN tab and the end-to-end quality including wired and wireless legs of the call under the End-to-End tab. The number of UCC calls are categorized by the following call quality: l
Good l l
Fair
Poor
ArubaOS 6.5.3.x
| User Guide Dashboard Monitoring | 827
l
Not Available : Under WLAN tab, short duration voice calls (less than 60 seconds), video calls, and file-transfer session are categorized as Not Available . Under End-to-End tab, short duration voice calls (less than 60 seconds), video calls, file-transfer, and desktop-sharing sessions are categorized as
Not Available .
When VoIP calls are prioritized using media classification, the End-to-End call quality is not available.
l
Call Quality vs. Client Health - This graph displays the co-relation between the VoIP call quality and the VoIP client health of every UCC call. This graph displays the UCC score under the WLAN tab and MOS under the End-to-End tab.
When VoIP calls are prioritized using media classification, the End-to-End call quality is not available.
l l l
Calls Per Device Type – This graph displays the calls made per device type. For example, Windows 7,
Mac OS X, iPhone, or Android.
Roaming – Roaming status of UCC clients. The status can be: l l
No – Number of calls where the client did not roam to a new AP.
Yes - Number of calls where the client has roamed to a new AP.
QoS Correction – If the DSCP value of the Real-time Transport Protocol (RTP) packets sent by the client differs from the recommended QoS setting, the call is classified as QoS Corrected. This graph displays the number of UCC calls where the controller has corrected the DSCP QoS value for such calls. The QoS correction is categorized as: l l l
No – No UCC QoS call correction.
Yes – DSCP QoS value corrected by the controller.
Not Available – WLAN short duration voice calls (less than 60 seconds), video calls, and file-transfer session are categorized as Not Available .
Details View
Navigate to the Dashboard > UCC page. To display an aggregated list of all the UCC call data metrics in the controller, click any of the following hyperlinks: l l l l l l
Call Volume Details
Call Quality Details
Client Health Details
Device Details
Roaming Details
QoS Details
displays an aggregated list of all the UCC call data metrics in the controller.
Figure 180 Wireless Call List
828 | Dashboard Monitoring ArubaOS 6.5.3.x | User Guide
VoIP calls made to/from clients outside the local controller are displayed in the External Call List pane. This pane lists all the external and wired client call CDRs. See
Figure 181 External Call List
Controller
The Controller page displays details of the controller and its health related information, such as CPU usage, memory usage, temperature, and fan speed.
This page is divided into three sections: n n n
Info panel
Gauges panel
Ports panel
Figure 182 Controller Dashboard
ArubaOS 6.5.3.x
| User Guide Dashboard Monitoring | 829
Details View
Info Panel
This panel displays all the information related to the controller such as name, model, serial number, MAC address start, MAC address end, up time, system time, software, ROM, Partition details, country, the type of deployment, IP addresses, and license information.
Gauges Panel
This panel displays the various gauges like CPU, memory, temperature, and fans. CPU and memory gauges indicate the memory and CPU usage by the controller. Click the Temperature and Fans gauge to view the details.
If temperature is high, then that data will be shown in red color. Each color represents the percentage of usage where red is high, yellow is moderate, and green is low.
Figure 183 Temperature Tab
Figure 184 Fan Tab
Ports Panel
This panel displays the status of all the ports in the controller.
Controller Events
Click the events link to view the list of events and the timestamps for each event.
830 | Dashboard Monitoring ArubaOS 6.5.3.x | User Guide
Figure 185 Events Tab
WLANs
The WLANs page displays the WLAN details such as the number of associated APs, radios, wireless clients, and the WLAN usage in the controller. You can also view the details of the associated APs and clients as tables.
The following sections are available in the WLANs page: n n
WLANs : The unique SSID of the WLAN, clients connected in the network, APs connected to the WLAN,
Radios that are enabled on the AP, Goodput, usage, and the frames transmitted and received by the AP.
All WLANs : The clients, usage, and device distribution information in graphs.
Click the hyperlinked text in the WLANs page to view the following menus with the summary: n n n n n
Info : The summary of the WLAN details, frames transmitted and received from and to the client, air quality, and Tx/Rx statistics.
Clients : The summary of WLANs and clients.
Radios : The summary of APs and clients, channel, and its utilization.
Charts : The summary of WLAN details in graphs.
Firewall : The summary of users, destination, applications, devices and its roles.
You can perform the following tasks on this page: n n n n n
Sort : Click a column header of the WLAN table to sort the complete list based on the entries on the active column. You can also use the sort icon that appears when you click on a column for sorting.
Filter : Click the filter icon and select the filter criterion on any column of the details table to filter the entries.
Customize column view : Click the drop-down menu on the top right corner of the table header and select
Custom Columns ; choose the Edit Current View option to select the columns that you want to view. You can also choose one of the following system defined views that have the appropriate pre-selected columns.
l l
Default Columns: you cannot edit this view.
To/From Client Stats: you can customize this view using the Edit Current View option.
View WLAN trends : The trends of the clients connected in the WLAN and the WLAN usage in the last 15 minutes.
View client summary : Click on the hyperlinked client name on the client details table to view the Client
Summary page. In this page, you can view the client details summary (air quality metrics and from and to clients statistics), bandwidth of the client usage, trend of the client frame loss in the last 15 minutes, and the frame rate distribution of the client.
ArubaOS 6.5.3.x
| User Guide Dashboard Monitoring | 831
n
View AP or radio summary : Click on the hyperlinked AP name or the radio band on the AP details table to view the Access Points page. In this page you can view the summary of the AP details such as air quality metrics, from and to clients statistics, and the number of clients associated with the AP under different SNR ranges. Additionally, you can view the details of the associated clients and WLANs.
Access Points
The Access Points page displays the details of all the radios and APs associated with the controller by selecting the specific section. You can also view the trends of the connected wireless clients and the client usage under the 2.4 Ghz and 5 Ghz radio bands in the last 15 minutes.
The Access Points page has the following three sections: n n n
Access Points —Displays the AP name, status, uptime, mode, and model details.
Radios —Displays the AP name, band, radio mode, goodput, usage, and the frames transmitted and received by the AP.
All Clients —Displays the clients and usage trend in charts for the last 15 minutes.
You can click the hyperlinked text on the Access Points page to view the following menus with the summary: n n n n
Info —Displays the summary of the AP details, frames transmitted and received from and to the client, air quality, and Tx/Rx statistics.
WLANs & Clients —Displays the summary of WLANs and clients.
Charts —Displays the summary of clients and its usage in graphs for different bands.
History —Displays the history of channel utilization, frame drops, and frame rates for every minute with histograms for the last 15 minutes.
You can perform the following tasks on this page: n n n n n
Sort : Click a column header of the AP table to sort the complete list based on the entries on the active column. You can also use the sort icon that appears when you click on a column for sorting.
Filter : Click the filter icon and select the filter criterion on any column of the details table to filter the entries.
Customize column view : Click the drop-down menu on the top right corner of the table header and select
Custom Columns ; choose the Edit Current View option to select the columns that you want to view. You can also choose one of the following system defined views that have the appropriate pre-selected columns.
l
Default Columns—You cannot edit this view.
l l
Air Quality Metrics—You can customize this view using the Edit Current View option.
To/From Client Stats—You can customize this view using the Edit Current View option.
View client details : Click on the number of clients associated with the AP to view the details of the clients on the Clients page.
View AP or radio summary : Click on the hyperlinked AP name or the radio band on the AP details table to view the summary of the AP details such as air quality metrics, from and to clients statistics, and the number of clients associated with the AP under different SNR ranges. Additionally, you can view the details of the associated clients and WLANs.
Clients
The Clients page displays the details of all the wireless clients on the controller. You can also view the trends of the connected clients and the client usage under the 2.4 Ghz and 5 Ghz radio bands in the last 15 minutes.
The Clients page displays the following sections:
832 | Dashboard Monitoring ArubaOS 6.5.3.x | User Guide
n n
Clients: The connectivity type, radios, client health, goodput, channel, and the frames transmitted and received.
All Clients : The clients and its usage for 2.4 GHz and 5 GHz bands.
Click the hyperlinked text on the Clients page to view the following menus with the summary: n n n n n
Info : The summary of the client details, frames transmitted and received from and to the client, air quality, and Tx/Rx statistics.
Charts : The summary of the client details in graphs.
AirGroup : A list of all the far and near end devices that are either accessible or not accessible by the specific client. For more information, see
Controller Dashboard Monitoring on page 1028
.
Firewall : The summary of traffic in the clients, applications and its roles, and protocols.
UCC : This tab displays an aggregated list of UCC call data metrics of a client. For more information, see
Dashboard in the WebUI on page 964 .
You can perform the following tasks on this page: n n n n n n
Sort : Click a column header of the AP table to sort the complete list based on the entries on the active column. You can also use the sort icon that appears when you click on a column for sorting.
Filter : Click the filter icon and select the filter criterion on any column of the details table to filter the entries.
Customize column view : Click the drop-down menu on the top right corner of the table header and select
Custom Columns ; choose the Edit Current View option to select the columns that you want to view. You can also choose one of the following system defined views that have the appropriate pre-selected columns.
l l l
Default Columns: you cannot edit this view.
Air Quality Metrics: you can customize this view using the Edit Current View option.
To/From Client Stats: you can customize this view using the Edit Current View option.
View client summary : Click on the hyperlinked client name on the client details table to view the Client
Summary page. In this page, you can view the client details summary (air quality metrics and from or to clients statistics), bandwidth of the client usage, trend of the client frame loss in the last 15 minutes, and the frame rate distribution of the client.
View AP details : Click on the hyperlinked AP name to view the Access Points page.
View WLAN details : Click on the hyperlinked SSID of the WLAN to view the WLANs page.
Firewall
The ArubaOS Policy Enforcement Firewall (PEF) module provides identity-based controls to enforce applicationlayer security and prioritization. With PEF, network administrators can enforce network access policies that specify who may access the network, with which mobile devices, and which areas of the network they may access. The Aruba AppRF technology integrated with PEF delivers mobile application traffic visibility through a simple dashboard that shows the applications in use by user and device. It gives network administrators insights on the applications that are running on their network, and the users using them.
The Firewall page on the Dashboard tab displays the PEF summary of all the sessions in the controller aggregated by users, devices, destinations, applications, WLANs, and roles.
Firewall visibility is disabled on the controller by default. To enable this feature, use the following procedures:
In the WebUI
1. Navigate to the Dashboard > Firewall page.
2. Click the link on the Element View section to enable firewall visibility. To disable, click the Disable Firewall link at the bottom of the Element View section.
ArubaOS 6.5.3.x
| User Guide Dashboard Monitoring | 833
In the CLI
Use the following command:
(host)(config) #firewall-visibility
To disable this setting, include the no parameter: no firewall-visibility
Element View
Navigate to the Dashboard > Firewall page to view Element View section. This section displays a summary of all the sessions in the controller and includes six categories of monitoring data, or elements, that display traffic statistics aggregated by the following elements:
Table 186: Element View
Element
User
Description
Indicates a wireless or wired user associated to the controller.
Traffic that is not generated by a user is aggregated as non-user traffic .
Devices
Destinations
Applications
WLANs
Roles
Specifies the client device type.
for example: Windows 7, Mac OS X, iPhone, or Android.
Destination hostname, or IP address if the hostname is unavailable.
Common advertising and file sharing services on the Internet are categorized under special destinations called ad networks and file share networks respectively.
Application name, protocols, and ports. For example: n n n n
Web applications : YouTube, Twitter, Facebook, Gotomeeting,
Webex, Amazon, Saleforce, and more.
Stateful applications : FTP, Lync, SIP, and more.
Custom applications : using the netservice command, you can define custom applications if the application uses well-known port numbers (0 - 1023).
Peer-to-Peer : all peer-to-peer traffic is classified under peer to peer .
n
Lync applications : Lync-desktop-sharing, Lync-file-transfer,
Lync-voice, and Lync-video.
If a session does not map to any of the above, the destination port is classified as application .
The service set identifier (SSID) that uniquely identifies the WLAN.
Wired connection is shown as wired .
Determines the user's network privileges based on the assigned user role.
The Element View section has two views: Chart and Table . Click Chart or Table at the top-right corner of an element to toggle between the two views. Each chart container shows the top five sessions with respect to traffic bandwidth and the rest are shown as Others . Click Others within the chart to view the rest of the
834 | Dashboard Monitoring ArubaOS 6.5.3.x | User Guide
sessions in the chart. Click any entry on the chart legend to view more usage details. The figure below shows the Chart view:
Figure 186 Chart View
In addition to the element, the Table view shows the common fields displayed in the table below:
Table 187: Table View Fields
Column
Bytes
Description
Total number of bytes transmitted and received by an element.
Tx Bytes
Rx Bytes
Total number of bytes transmitted by an element.
Total number of bytes received by an element.
You can perform the following tasks in the Table view: n n
Sort : click a column header of the table to sort the list by column. You can also use the sort icon that appears when you click on a column.
Filter : click the filter icon on the first column and select the filter criterion to filter the entries.
Details View
Navigate to the Dashboard > Firewall page. Click the All <element> link to view the Details View page.
There are four sections on this page.
Element Tab
The Element Tab shows the available usage detail elements. Click an element to view more usage details:
Figure 187 Element Tab
Element Summary View
The Element Summary View displays a detailed view of all the six elements and their corresponding fields:
ArubaOS 6.5.3.x
| User Guide Dashboard Monitoring | 835
Figure 1a Element Summary View
Figure 1b Element Summary View (continued)
See the following table for more information on Element Summary View fields:
Table 188: Element Summary View Fields
Column Description
User
Indicates a wireless or wired user associated to the controller.
Click a User IP address to view details of the connected client.
Bytes Total number of bytes transmitted and received by an element.
Packets Total number of data packets transmitted and received by an element.
Device
Destination
Application
WLAN
Role
Specifies the client device type.
Click the number to view details of the device type identification.
Total number of destination hostnames or IP addresses.
Click the number to view details of the destination hosts.
Total number of application name, protocols, and ports.
Click the number to view details of the application ports.
The service set identifier (SSID) that uniquely identifies the WLAN.
Click the number to view details of the WLAN SSID.
Determines the user's network privileges based on the assigned user role.
Click the number to view details of the role.
You can perform the following tasks in the Element Summary View :
836 | Dashboard Monitoring ArubaOS 6.5.3.x | User Guide
n n
Sort : click a column header of the table to sort the list by column. You can also use the sort icon that appears when you click on a column.
Filter : click the filter icon on the first column and select the filter criterion to filter the entries.
Usage Breakdown
In the Usage Breakdown, section you can apply any of the filters that are listed under each element to customize the output. To apply a filter, click any row under each element. The selected row turns yellow. The filtered output is displayed in the Element Summary View and Aggregated Sessions sections of the page.
Click the row again to deselect it and remove the filter. For example, if you click autodiscover.arubanetworks.com
under Destination , and salesforce.com
under Application , the
Element Summary View and Aggregated Sessions sections display session information based on the selected rows. The following figure shows the selected row in each element:
Figure 188 Usage Breakdown
Aggregated Sessions
The Aggregated Sessions displays a list of all user and non-user sessions on the controller.
ArubaOS 6.5.3.x
| User Guide Dashboard Monitoring | 837
Figure 2a Aggregated Sessions
Figure 2b Aggregated Sessions (continued)
See the following table for more information on Aggregated Sessions fields:
Table 189: Aggregated Sessions Fields
Column Description
Source IP Indicates the IP address of the wireless or wired user associated to the controller.
Destination Name/IP Destination hostname, or IP address if the hostname is unavailable.
IP Protocol
Application
Tx Bytes
RX Bytes
User
Device
Role
WLAN
Destination Alias
Type of IP protocol traffic: for example, TCP or UDP.
Application name, protocols, and ports.
Total number of bytes transmitted in a session.
Total number of bytes received in a session.
Indicates a wireless or wired user associated to the controller.
Specifies the client device type.
Determines the user's network privileges based on the assigned user role.
The service set identifier (SSID) that uniquely identifies the WLAN.
Fully Qualified Domain Name (FQDN) or the URL of the destination network or host.
You can perform the following tasks in the Aggregated Sessions section: n n
Sort : click a column header of the table to sort the list by column. You can also use the sort icon that appears when you click on a column.
Filter : click the filter icon on the first column and select the filter criterion to filter the entries.
838 | Dashboard Monitoring ArubaOS 6.5.3.x | User Guide
Chapter 36
Automatic Reporting (PhoneHome)
The automatic reporting feature, also known as PhoneHome, allows a controller to send report events such as hardware failures, software malfunctions, and other critical events. The PhoneHome automatic reporting is disabled by default. When you enable the PhoneHome automatic reporting feature, the controller sends Aruba support weekly reports about the controller’s configuration, licenses, software and hardware status, and any software malfunctions via Aruba Activate or a secure email. In the event that you need to contact Aruba support with a question about your controller, you can use this feature to generate and immediately send a status report, so that Aruba support can diagnose the issue with the most current controller data.
The PhoneHome feature can send reports to Aruba support through the Aruba Activate server using the HTTPS protocol (recommended for most deployments), or send reports to a local SMTP server in email messages.
Pre-Deployment Information
For information to help you determine whether you should send PhoneHome reports to Aruba support via the
Activate server or an SMTP server, see
Sending Reports to Activate vs. SMTP Servers on page 839
n n
Configuration Procedures
For procedures to configure this feature to send an reports or to view your controller's report history, refer to the following topics.
Configuring PhoneHome Automatic Reporting on page 840
Viewing Report Status on page 842
Sending Reports to Activate vs. SMTP Servers
By default, controllers running ArubaOS 6.4 or later releases send PhoneHome reports to the Activate server using HTTPS. Earlier versions of ArubaOS allow the PhoneHome feature to send reports to an SMTP server only.
Most deployments should retain the default behavior introduced in ArubaOS 6.4 and send PhoneHome reports via Activate. However, if the controller is behind proxy server and does not have direct access to
Internet, PhoneHome should be configured to send reports using SMTP. The following section of this document describes the benefits of each of these configurations options.
Sending Phonehome Reports using Activate
PhoneHome integration with Activate offers following benefits: n n
Simpler configuration: Phonehome only requires you to configure the email ID of the network administrator managing the device, as Activate already has information to accurately identify your controller. If a DNS server is not configured on the controller, PhoneHome will query the public DNS service
(8.8.8.8) to resolve the Activate server IP address.
Smaller bandwidth requirements: When the PhoneHome feature sends the report to the Activate server, the PhoneHome report is zipped into a smaller package, then divided into smaller 1MB pieces before being sent to the server using secure HTTPS. Only reports sent to Activate are zipped before they are sent, so reports sent to Activate use less bandwidth than a report sent to a SMTP server.
ArubaOS 6.5.3.x
| User Guide Automatic Reporting (PhoneHome) | 839
n n n
Enhanced error management: If any individual portion of the report is not successfully received by the
Activate server, PhoneHome makes up to three attempts to resend just that portion of the file rather than resending the entire report. Reports sent via SMTP must be resent in their entirety if any portion is not received by the SMTP server.
Automatic removal of old reports: Once the entire report has been sent to the Activate server, Activate sends an acknowledgment to the controller, prompting the controller to delete its local copy of the report.
The PhoneHome feature can be enabled or disabled using the Maintenance > File > Aruba TAC Server option in the WebUI. The same can also be done through phonehome [enable | disable] option in the
CLI.
Sending Reports using SMTP
If you configure the PhoneHome feature to use SMTP, the PhoneHome status reports are sent via email. When the controller generates the report email with the PhoneHome data file attachment, it forwards the email to the local SMTP server configured on your local network, which then relays the message to Aruba technical support. If your email server requires the sender to be authenticated before message delivery, the controller can connect to the SMTP server by supplying the sender’s user name and password.
When PhoneHome reports are sent using SMTP, the PhoneHome report attachment is encrypted before it is transmitted to the SMTP server. It is then decrypted by Aruba support when it is received. If the PhoneHome status report email is larger than the maximum email size supported by your SMTP server, the controller divides the PhoneHome attachment into smaller attachments and sends the report to Aruba in multiple emails. If any individual portion of the report is not successfully received by the SMTP server, PhoneHome resends the entire report.
Configuring PhoneHome Automatic Reporting
Use the WebUI or the command-line interface to configure the controller to send weekly status reports. When you enable this feature, the controller sends report every week by default..
The procedure to configure PhoneHome automatic reporting varies, depending upon whether you want to send reports via Aruba Activate or an SMTP email server. The following procedures describe the tasks to configure automatic reporting using Activate or SMTP.
Configuring PhoneHome Using Activate
To use the WebUI to configure PhoneHome automatic reporting using Aruba Activate:
1. Navigate to Maintenance > File > Aruba TAC Server .
2. Click enable to enable this feature.
3. In the Protocol field, select HTTPS.
4. In the Email-ID field, enter a valid email address with a domain name associated with your controller. This field is used in the SMTP header and used to validate ownership with PhoneHome data.
5. Use the Report Type checkboxes to specify whether you want automatic reporting to send regular weekly reports, or a single individual report.
n n
Click Auto Report to schedule weekly status reports to be sent to Aruba.
Click Report Now to immediately send a single status report to Aruba.
6. Click Apply . If you selected the Report Now option in the Report Type field, the Report Now checkbox clears, indicating that no additional reports are scheduled to be sent.
840 | Automatic Reporting (PhoneHome) ArubaOS 6.5.3.x | User Guide
Configuring PhoneHome Using SMTP
To use the WebUI to configure PhoneHome automatic reporting to send reports through an SMTP email server:
1. Navigate to Maintenance >File >Aruba TAC Server .
2. Click enable to enable this feature.
3. In the Protocol field, select SMTP .
4. In the Server IP Address field, enter the IP address of your SMTP server.
5. (Optional) In the Server Port field, enter the port the controller should use to access the server.
6. In the User Name field, enter the user name of the user from whose email account the reports should be sent.
7. (Optional) If your SMTP server requires the sender to be authenticated, enter a valid sender’s user name and password in the User Name and Password fields.
8. In the Email ID field , enter the email address from which the reports should be sent.
9. (Optional) If your SMTP server has limits on email attachment sizes, enter this attachment size in the Max size of attachment field. Any status reports larger than this size is divided into multiple emails.
10.Use the Report Type checkboxes to specify whether you want automatic reporting to send regular weekly reports, or a single individual report.
n n
Click Auto Report to schedule weekly status reports to be sent to Aruba.
Click Report Now to immediately send a single status report to Aruba.
11.Click
Apply .
You can disable automatic reporting at any time by returning to the Maintenance > File > Aruba TAC Server window and either unchecking the Auto Report checkbox, or clicking disable .
Configuring PhoneHome Using the CLI
Issue the following commands to enable or disable automatic reporting, or to identify the Aruba Activate or
SMTP server you want to use to send these messages: phonehome auto-report enable|disable smtp <server ip> email <from_addy> [user <username> password <password>] [<server port>]
[size <max attachment size>] https <from-addr>
Your SMTP and Activate server settings are preserved even when automatic reporting is disabled.
Sending an Individual Report
If you are currently experiencing a problem and have contacted Aruba about the issue, Aruba technical support may ask you to generate and send an individual report which describes the controller’s current status, and reports any software or hardware errors. Once this report has been successfully uploaded, you may receive an email that contains a unique reference number you can use to track your recently opened ticket.
If you have not yet enabled automatic reporting feature or defined an SMTP server for this feature, follow steps 1-9 of the WebUI procedure described in
Configuring PhoneHome Automatic Reporting on page 840
ArubaOS 6.5.3.x
| User Guide Automatic Reporting (PhoneHome) | 841
In the WebUI
To generate and send a PhoneHome status report using the WebUI:
1. Navigate to Maintenance > File > Aruba TAC Server .
2. Click the Report Now checkbox.
3. Click App l y .
In the CLI
To generate and send a PhoneHome status report using the command-line interface, access the CLI in enable mode and issue the command phonehome now .
Viewing Report Status
Both the WebUI and CLI can show the status of the automatic reporting feature since the controller was last reset, including whether this feature is enabled, and the number of report messages that were sent successfully or failed to reach Activate or the SMTP server.
In the WebUI
To view report status using the WebUI:
1. Navigate to Maintenance > File > Aruba TAC Server .
2. Click the View PhoneHome Report Status checkbox to view statistics for sent reports in this window.
3. The Statistics and Transaction tables appear. These tables contain the following information:
Table 190: Automatic Reporting Statistics
Report Statistic
Manual Phonehome
Description
Number of reports generated by the controller because the Report Now setting was enabled.
Auto-Report
Success
Failed
Retry
Number of weekly reports generated by the controller because the Auto
Report setting was enabled
Number of reports successfully sent to Activate or the SMTP server.
Number of reports that failed to reach Activate or the SMTP server after one or more retry attempts.
Number of times the controller attempted to retry sending a report to
Activate or the SMTP server.
Table 191: Transaction History
Report Statistic
Transaction ID
Status
Description
An ID number for a specific report transaction. This transaction ID includes a timestamp showing when the transaction was first attempted.
This field indicates whether or not a report transaction was successfully sent. If the report failed, this table describes the reason for the failure.
842 | Automatic Reporting (PhoneHome) ArubaOS 6.5.3.x | User Guide
In the CLI
Use the following commands to display statistics for Automatic Reporting settings and report status
(host)(config) #show phonehome global history
Display Phonehome global settings
Display a history of phonehome transactions report-status
Server
Display status of reports uploaded to Aruba TAC stats PhoneHome Statistics
PhoneHome-Lite
PhoneHome-Lite is an HTTPS-based tracking tool used to monitor WebCC feature usage on each controller.
Arubacontrollers communicate with Activate servers over a secure HTTPS SSL layer through the PhoneHome infrastructure to send information about which users have enabled WebCC. This usage data can then be analyzed to determine the scope of future WebCC feature licensing.
You can enable this feature using the controller's WebUI or CLI.
In the WebUI
To enable PhoneHome-Lite in the WebUI:
1. Navigate to Configuration > ADVANCED SERVICES > Stateful Firewall >Global Setting .
2. In the Global Setting tab, check the Enable Web Content Classification check box.
On enabling web-cc, the web-cc feature usage information will be sent to Aruba at every 7 days interval.
3. Click Apply .
In the CLI
To enable PhoneHome-Lite using the CLI:
(host) (config) #firewall web-cc
You can also view the WebCC configuration using the following command:
(host) (config) #show firewall
Global firewall policies
------------------------
Policy
Prohibit RST replay attack
.....
Action
-----------
Enforce TCP handshake before allowing data Disabled
Disabled
Web Content Classification
....
Enabled
Rate
----
Port
----
ArubaOS 6.5.3.x
| User Guide Automatic Reporting (PhoneHome) | 843
Chapter 37
Management Access
This chapter describes management access and tasks for a user-centric network and includes the following topics: n n n n n n n n n n n n n n n n n n n
Configuring Certificate Authentication for WebUI Access on page 844
Secure Shell (SSH) on page 845
WebUI Session Timer on page 846
Enabling RADIUS Server Authentication on page 847
Connecting to an AirWave Server on page 853
Custom Certificate Support for RAP on page 856
Implementing a Specific Management Password Policy on page 858
Configuring AP Image Preload on page 860
Configuring Centralized Image Upgrades
Managing Certificates on page 865
Enabling Capacity Alerts on page 873
Configuring Logging on page 874
Enabling Guest Provisioning on page 878
Managing Files on the Controller on page 894
Setting the System Clock on page 897
ClearPass Profiling with IF-MAP on page 899
Whitelist Synchronization on page 900
Downloadable Regulatory Table on page 901
Configuring Certificate Authentication for WebUI Access
The controller supports client certificate authentication for users accessing the controller using the WebUI. (The default is for username/password authentication.) You can use client certificate authentication only, or client certificate authentication with username/password (if certificate authentication fails, the user can log in with a configured username and password).
Each controller can support a maximum of ten management users.
To use client certificate authentication, you must do the following:
1. Obtain a client certificate and import the certificate into the controller. Obtaining and importing a client certificate is described in
Managing Certificates on page 865
.
2. Configure certificate authentication for WebUI management. You can optionally also select username/password authentication.
3. Configure a user with a management role. Specify the client certificate for authentication of the user.
ArubaOS 6.5.3.x
| User Guide Management Access | 844
In the WebUI
1. Navigate to the Configuration > Management > General page.
2. Under WebUI Management Authentication Method , select Client Certificate . You can select
Username and Password as well; in this case, the user is prompted to manually enter the username and password only if the client certificate is invalid.
3. Select the Server Certificate to be used for this service.
4. Click Apply .
5. To configure the management user, navigate to the Configuration > Management > Administration page.
a. Under Management Users , click Add .
b. Select Certificate Management .
c. Select WebUI Certificate .
d. Enter the username.
e. Select the user role assigned to the user upon validation of the client certificate f. Enter the serial number for the client certificate.
g. Select the name of the CA that issued the client certificate.
h. Click Apply .
In the CLI
(host)(config) #web-server profile
(host)(Web Server Configuration) #mgmt-auth certificate
(host)(Web Server Configuration) #switch-cert <certificate>
(host)(Web Server Configuration) #!
(host)(config) #mgmt-user webui-cacert <certificate-name> serial <number> <username>
<rolename>
Secure Shell (SSH)
SSH is enabled by default in ArubaOS, and thus lets you log in using a username and password. You can enable
SSH login by using public key authentication while leaving username/password authentication enabled, or you may disable the username/password authentication and leave only the public key authentication enabled. In the FIPS mode of operation, SSH is pre-configured to only use Diffie-Hellman Group 14 with AES-CBC-128 and
AES-CBC-256 and HMAC-SHA1/HMAC-SHA1-96. These settings are not configurable.
When you import an X.509 client certificate into the controller, the certificate is converted to SSH-RSA keys.
When you enable public key authentication for SSH, the controller validates the client’s credentials with the imported public keys. You can specify public key authentication only, or public key authentication with username/password (if the public key authentication fails, the user can login with a configured username and password).
Enabling Public Key Authentication
The controller allows public key authentication of users accessing the controller using SSH. (The default is for username/password authentication.)
To use public key authentication, you must do the following:
1. Import the X.509 client certificate into the controller using the WebUI, as described in
Importing Certificates on page 867
2. Configure SSH for client public key authentication. You can optionally also select username/password authentication.
845 | Management Access ArubaOS 6.5.3.x | User Guide
3. Configure the username, role and client certificate.
In the WebUI
1. Navigate to the Configuration > Management > General page.
2. Under SSH (Secure Shell) Authentication Method , select Client Public Key . You can optionally select
Username/Password to use both username/password and public key authentication for SSH access.
3. Click Apply .
4. To configure the user, navigate to the Configuration > Management > Administration page.
a. Under Management Users, click Add .
b. Select Certificate Management .
c. Select SSH Public Key .
ArubaOS recommends that the username and role for SSH be the same as for the WebUI Certificate. You can optionally use the checkbox to copy the username and role from the Web Certificate section to the SSH Public Key section.
d. Select the management role assigned to the user upon validation of the client certificate.
e. Select the client certificate.
f. Click Apply .
In the CLI ssh mgmt-auth public-key [username/password] mgmt-user ssh-pubkey client-cert <certificate> <username> <role>
Disabling Console Access for Controllers
A new command is introduced to disable the console-login. The purpose of this command is to introduce an ability to lock down all console ports, for example, micro USB, mini USB on the controller to enable high level security. This also ensures that no SSH access is allowed at the remote branch office. The SSH is only allowed from the headquarters via the IPSEC tunnel.
With this command, only console access over serial port, USB, and mini USB will be blocked. SSH/ telnet are still allowed.
In the CLI
To disable the console:
(host) (config) #mgmt-user console-block
PLEASE SAVE THE CONFIGURATION. CONSOLE WILL BE BLOCKED ONCE USER LOGS OUT FROM SERIAL-
CONSOLE.
To re-enable the console:
(host) (config) #no mgmt-user console-block n
WebUI Session Timer
The controller supports two types of WebUI session timer. They are:
Idle Session Timeout : This setting specifies the time of inactivity after which the WebUI session times out and requires login for continued access.
ArubaOS 6.5.3.x
| User Guide Management Access | 846
n
Absolute Session Timeout : This setting specifies the absolute time after which the WebUI session times out post a successful authentication.
You can configure these settings from either the controller WebUI or CLI.
In the WebUI
To configure the WebUI session timer using the WebUI, follow the procedure below.
1. Navigate to the Configuration > Management > General page.
2. Under WebUI Session Timer , configure the settings described in
.
Table 192: WebUI Session Timer Settings
Parameter Description
Idle session timeout This setting specifies the time of inactivity after which the WebUI session times out and requires login for continued access.
Default: 900 seconds
Range: 30-3600 seconds
Absolute session timeout
This setting specifies the absolute time after which the WebUI session times out post a successful authentication.
Default: Disabled
Range: 30-3600 seconds
In the CLI
To configure the WebUI session timer using the CLI, execute the following commands.
(host) (config) #web-server profile
(host) (Web Server Configuration) #session-timeout 900
(host) (Web Server Configuration) #absolute-session-timeout 300
To view the configuration using the CLI, execute the following command.
(host) #show web-server profile
Web Server Configuration
------------------------
Parameter
---------
Cipher Suite Strength
SSL/TLS Protocol Config
Switch Certificate
Captive Portal Certificate
IDP Certificate
Value
----medium tlsv1 tlsv1.1 tlsv1.2
default default default
Management user's WebUI access method username/password
User absolute session timeout <30-3600> (seconds) 300
User session timeout <30-3600> (seconds)
Maximum supported concurrent clients <25-320>
900
75
Enable WebUI access on HTTPS port (443)
Web Skype4B Listen Protocol/Port Config
Enable bypass captive portal landing page false
N/A true
Enabling RADIUS Server Authentication
This section include many different types of RADIUS server configuration and related procedures.
847 | Management Access ArubaOS 6.5.3.x | User Guide
Configuring RADIUS Server Username and Password Authentication
In this example, an external RADIUS server is used to authenticate management users. Upon authentication, users are assigned the default role root.
In the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select RADIUS Server to display the Radius Server List.
a. To configure a RADIUS server, enter the name for the server (for example, rad1) and click Add .
b. Select the name to configure server parameters, such as IP address. Select the Mode checkbox to activate the server.
c. Click Apply .
3. Select Server Group to display the Server Group list.
a. Enter the name of the new server group (for example, corp_rad) and click Add .
b. Select the name to configure the server group.
c. Under Servers, click New to add a server to the group.
d. Select a server from the drop-down menu and click Add Server .
e. Click Apply .
4. Navigate to the Configuration > Management > Administration page.
a. Under Management Authentication Servers, select a management role (for example, root) for the
Default Role.
b. Select (check) Mode.
c. For Server Group, select the server group that you just configured.
d. Click Apply .
In the CLI aaa authentication-server radius rad1
host < ipaddr >
enable aaa server-group corp_rad
auth-server rad1 aaa authentication mgmt
default-role root
enable
server-group corp_rad
Configuring RADIUS Server Authentication with VSA
In this scenario, an external RADIUS server authenticates management users and returns to the controller the
Aruba vendor-specific attribute (VSA) called Aruba-Admin-Role that contains the name of the management role for the user. The authenticated user is placed into the management role specified by the VSA.
The controller configuration is identical to the
Configuring RADIUS Server Username and Password
. The only difference is the configuration of the VSA on the RADIUS server. Ensure that the value of the VSA returned by the RADIUS server is one of the predefined management roles.
Otherwise, the user will have no access to the controller.
ArubaOS 6.5.3.x
| User Guide Management Access | 848
Configuring RADIUS Server Authentication with Server Derivation Rule
Aruba controllers do not make use of any returned attributes from a TACACS+ server.
A RADIUS server can return to the controller a standard RADIUS attribute that contains one of the following values: n n
The name of the management role for the user
A value from which a management role can be derived
For either situation, configure a server-derivation rule for the server group.
In the following example, the RADIUS server returns the attribute Class to the controller. The value of the attribute can be either “root” or “network-operations” depending upon the user; the returned value is the role granted to the user.
Ensure that the value of the attribute returned by the RADIUS server is one of the predefined management roles.
Otherwise, the management user will not be granted access to the controller.
In the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select RADIUS Server to display the Radius Server List.
a. To configure a RADIUS server, enter the name for the server (for example, rad1) and click Add .
b. Select the name to configure server parameters, such as IP address. Select the Mode checkbox to activate the server.
c. Click Apply .
3. Select Server Group to display the Server Group list.
a. Enter the name of the new server group (for example, corp_rad) and click Add .
b. Select the name to configure the server group.
c. Under Servers, click New to add a server to the group.
d. Select a server from the drop-down menu and click Add Server .
e. Under Server Rules, click New to add a server rule.
f. For Condition, select Class from the scrolling list. Select value-of from the drop-down menu. Select Set
Role from the drop-down menu.
g. Click Add .
h. Click Apply .
4. Navigate to the Configuration > Management > Administration page.
a. Under Management Authentication Servers, select a management role (for example, read-only) for the
Default Role.
b. Select (check) Mode.
c. For Server Group, select the server group that you just configured.
d. Click Apply .
In the CLI aaa authentication-server radius rad1
host < ipaddr >
enable aaa server-group corp_rad
849 | Management Access ArubaOS 6.5.3.x | User Guide
auth-server rad1
set role condition Class value-of aaa authentication mgmt
default-role read-only
enable
server-group corp_rad
In the following example, the RADIUS server returns the attribute Class to the controller; the value of this attribute can be “it”, in which case, the user is granted the root role. If the value of the Class attribute is anything else, the user is granted the default read-only role.
Configuring a set-value server-derivation rule
In the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select RADIUS Server to display the Radius Server List.
a. To configure a RADIUS server, enter the name for the server (for example, rad1) and click Add .
b. Select the name to configure server parameters, such as IP address. Select the Mode checkbox to activate the server.
c. Click Apply .
3. Select Server Group to display the Server Group list.
a. Enter the name of the new server group (for example, corp_rad) and click Add .
b. Select the name to configure the server group.
c. Under Servers, click New to add a server to the group.
d. Select a server from the drop-down menu and click Add Server .
e. Under Server Rules, click New to add a server rule.
f. For Condition, select Class from the scrolling list. Select equals from the drop-down menu. Enter it .
Select Set Role from the drop-down menu. For Value, select root from the drop-down menu.
g. Click Add .
h. Click Apply .
4. Navigate to the Configuration > Management > Administration page.
a. Under Management Authentication Servers, select a management role (for example, read-only) for the
Default Role.
b. Select (check) Mode.
c. For Server Group, select the server group that you just configured.
d. Click Apply .
In the CLI aaa authentication-server radius rad1
host < ipaddr >
enable aaa server-group corp_rad
auth-server rad1
set role condition Class equals it set-value root aaa authentication mgmt
default-role read-only
enable
server-group corp_rad
ArubaOS 6.5.3.x
| User Guide Management Access | 850
For more information about configuring server-derivation rules, see
Configuring Server-Derivation Rules on page 205
.
Disabling Authentication of Local Management User Accounts
You can disable authentication of management user accounts in local switches if the configured authentication server(s) (RADIUS or TACACS+) are not available.
You can disable authentication of management users based on the results returned by the authentication server. When configured, locally-defined management accounts (for example, admin) are not allowed to log in if the server(s) are reachable and the user entry is not found in the authentication server. In this situation, if the
RADIUS or TACACS+ server is unreachable, meaning it does not receive a response during authentication, or fails to authenticate a user because of a timeout, local authentication is used and you can log in with a locallydefined management account.
In the WebUI
1. Navigate to the Configuration > Management > Administration page.
2. Under Management Authentication Servers, uncheck the Local Authentication Mode checkbox.
3. Click Apply .
In the CLI mgmt-user localauth-disable
Verifying the configuration
To verify if authentication of local management user accounts is enabled or disabled, use the following command: show mgmt-user local-authentication-mode
Resetting the Admin or Enable Password
This section describes how to reset the password for the default administrator user account ( admin ) on the controller. Use this procedure if the administrator user account password is lost or forgotten.
1. Connect a local console to the serial port on the controller.
2. From the console, login in the controller using the username password and the password forgetme!
.
3. Enter enable mode by typing in enable , followed by the password enable .
4. Enter configuration mode by typing in configure terminal .
5. To configure the administrator user account, enter mgmt-user admin root . Enter a new password for this account. Retype the same password to confirm.
6. Exit from the configuration mode, enable mode, and user mode.
This procedure also resets the enable mode password to enable . If you have defined a management user password policy, make sure that the new password conforms to this policy. For details, see
Specific Management Password Policy on page 858
.
is an example of how to reset the password. The commands in bold type are what you enter.
851 | Management Access ArubaOS 6.5.3.x | User Guide
Figure 189 Resetting the Password
(host)
User: password
Password: forgetme!
(host) > enable
Password: enable
(host) # configure terminal
Enter Configuration commands, one per line. End with CNTL/Z
(host) (config) # mgmt-user admin root
Password: ******
Re-Type password: ******
(host) (config) # exit
(host) # exit
(host) >exit
After you reset the administrator user account and password, you can login to the controller and reconfigure the enable mode password. To do this, enter configuration mode and type the enable secret command. You are prompted to enter a new password and retype it to confirm. Save the configuration by entering write memory .
details an example reconfigure the enable mode password. Again, the command you enter displays in bold type.
Figure 190 Reconfigure the enable mode password
User: admin
Password: ******
(host) > enable
Password: ******
(host) # configure terminal
Enter Configuration commands, one per line. End with CNTL/Z
(host) (config) # enable secret
Password: ******
Re-Type password: ******
(host) (config) # write memory
Bypassing the Enable Password Prompt
The bypass enable feature lets you bypass the enable password prompt and go directly to the privileged commands (config mode) after logging on to the controller. This is useful if you want to avoid changing the enable password due to company policy.
Use the enable bypass
CLI command to bypass the enable prompt an go directly to the privileged commands
(config mode). Use the no enable bypass
CLI command to restore the enable password prompt.
Setting an Administrator Session Timeout
You can configure the number of seconds after which an administrator’s WebUI or CLI session times out.
In the WebUI
To define a timeout interval for a WebUI session, use the command:
(host)(config) #web-server profile
(host)(Web Server Configuration) #session-timeout <session-timeout>
In the above command, <session-timeout> can be any number of seconds from 30 to 3600, inclusive.
ArubaOS 6.5.3.x
| User Guide Management Access | 852
In the CLI
To define a timeout interval for a CLI session, use the command:
(host)(config) #loginsession timeout <value>
In the above command, <val> can be any number of minutes from 5 to 60 or seconds from 1 to 3600, inclusive. You can also specify a timeout value of 0 to disable CLI session timeouts.
Connecting to an AirWave Server
AirWave is a powerful and easy-to-use network operations system that manages Arubawireless, wired and remote access networks, as well as wireless and wired infrastructures from and a wide range of third-party manufacturers.
Controllers running ArubaOS 6.3 and later can use the AirWave wizard in the Configuration > Wizards >
AirWave section of the controller WebUI to quickly and easily connect the controller to an AirWave server. The following checklist lists the information you will need to use this wizard. Determine each of these values for your deployment and AirWave server before you start the wizard process.
Table 193: AirWave Wizard Checklist
Information Description
AirWave
IP address
SNMP version
IP address of the AirWave server.
Specify if the controller and AirWave serer should communicate using SNMP v2 or SNMPv3. SNMPv3 communications between a controller and an AirWave server use SHA authentication and AES encryption.
For SNMPv2 If you select SNMPv2, you must enter an SNMP community string.
For SNMPv3
Syslog n n n n
If you select SNMPv3, you must enter values for the following parameters:
User name : A string representing the name of the SNMP user.
Authentication password : Authentication key for use with the
SHA authentication protocol.
privacy password : Privacy key for encrypted messages.
NTP serve r: If the controller is not already configured to use an
NTP server, enter the IP address of an NTP server.
Syslog messages are disabled by default. Use the Syslog section of the wizard to enable syslog messages, and define the syslog category, syslog facility levels (local0-local7) and syslog severity levels
(debug-emergency) for messages from the controller. By default,
AirWave syslog messages sent at the error severity level.
n n n n n n n n
The possible syslog categories are as follows: ap-debug arm-user-debug network security system user user-debug wireless
My Values
853 | Management Access ArubaOS 6.5.3.x | User Guide
AMON Message Size Changes on the Controller
Data communication between Aruba controllers and AirWave servers has shifted from the SNMP model to the faster, more reliable, and scalable AMON model. Though the SNMP model can still be used to communicate data, users generally encounter delayed AirWave updates and high controller and process CPU usage.
The AMON packet size has been capped at a default value of 1400 bytes to reduce the amount of fragmentation and message loss that typically occurs in larger packet sizes, which can force customers to fall back to the SNMP model. Message size has been capped at 1400 bytes to allow for the addition of AMON headers and PAPI/UDP/IP headers. Each packet only contains one message to further reduce the amount of overall message loss, as the loss of even a single fragment can render an entire message invalid.
The AMON packet size can be modified using the following CLI command:
(host)(config) #amon msg-buffer-size <msg-buffer-size>
With the additional message load due to the smaller packet size and 1:1 message to packet ratio, output has also been increased from 10 second intervals to 1 second intervals to distribute packets more evenly, helping maintain a more stable and less congested traffic flow.
AMON Source IP Address
Starting with ArubaOS 6.5.3.0, users can specify the source IP address of AMON packets emitted from the controller. The source IP address is set globally, meaning all management servers configured on the controller receive AMON packets from the same source VLAN interface.
The source IP address can only be set to the IPv4 address of a VLAN interface. IPv6 addresses are not supported.
n n
The default source IP address is used in the following scenarios: n
The VLAN interface is not defined.
The VLAN interface is deleted.
The VLAN interface is a Layer-2 VLAN.
In the CLI
To configure the IP address of a VLAN interface, execute the following commands:
(host)(config) #interface vlan <vlan> ip address <ipaddr>
To verify that the VLAN interface is configured properly, execute the following command:
(host)(config) #show running-config | begin “interface vlan <vlan>”
To set the source VLAN interface of the AMON feed, execute the following command:
(host)(config) #amon source-interface <vlan-num>
To verify that the source VLAN interface is set correctly, execute the following command:
(host)(config) #show running-config | include mgmt
To verify that the AMON feed is using the correct source IP address, execute tcpdump on the controller.
To remove the source VLAN interface of the AMON feed, execute the following command:
(host)(config) #no amon source-interface
To verify that the source VLAN interface is configured, execute the following command:
(host) #show amon source-interface
ArubaOS 6.5.3.x
| User Guide Management Access | 854
Inline Monitoring
Inline Monitoring helps diagnose client connectivity issues. It provides the network administrator or engineers with more information regarding the exact stage at which the client connectivity fails or provides data where the dhcp or radius server is slow.
The controller collects all information related to user transitions like association, authentication, and dhcp.
Then, the controller sends these records to a management server like AirWave. The management server analyzes the data and concludes which dhcp or radius server was not working efficiently causing user connectivity issues. This enhancement allows the management server to isolate WLAN issues caused by external servers such as dhcp or radius.
Currently, inline monitoring data will not be displayed or available for bridge mode RAP users.
Following are the advantages of inline monitoring: n n n
Improves user serviceability.
Provides network administrator and engineers information on the client connectivity failures.
Easier DHCP debugging.
Enabling Inline Monitoring Statistics
You can enable the Inline Monitoring statistics using the mgmt-server profile command in the CLI interface.
Execute the following command to enable the Inline Monitoring statistics from the AP:
(host) (config) #mgmt-server
(host) (config) #mgmt-server profile default-amp
(host) (Mgmt Config profile "default-amp") #inline-ap-stats
Execute the following command to enable Inline Monitoring statistics related to authentication:
(host) (Mgmt Config profile "default-amp") #inline-auth-stats
Execute the following command to enable inline monitoring statistics of DHCP
(host) (Mgmt Config profile "default-amp") #inline-dhcp-stats
Execute the following command to enable inline monitoring statistics of DNS
(host) (Mgmt Config profile "default-amp") #inline-dns-stats
Clarity Synthetic
Controllers provide support for Clarity Synthetic, a feature introduced in AirWave 8.2.3 which helps determine network health using synthetic transaction from a Wi-Fi client. The controller can convert one or both AP radios from AP mode to station mode based on instructions from the AirWave server. When the radio of the AP is in station mode, it starts a synthetic data transaction within the network.
The following table provides a list of AP platforms that support Clarity Synthetic:
Table 194: Supported AP-Platforms for Clarity
Synthetic
Supported AP-Platforms
200 Series access points
AP-207 Series access point
210 Series access points
855 | Management Access ArubaOS 6.5.3.x | User Guide
Supported AP-Platforms
220 Series access points
300 Series access points
310 Series access points
320 Series access points
330 Series access points
The network health is determined based on the response from the network and the time taken for the synthetic data transaction. The results captured as part of these transactions appear in the Home > Clarity page of the AirWave WebUI, and are used for the following purposes: n n n n
Troubleshoot a live network
Provide whole network overview (WLAN and Wired)
Support Wi-Fi and Internet Protocol Service Level Agreement (IP SLA)
Troubleshoot Remote network using client traffic (Synthetic)
For more information, refer to the Clarity chapter of the AirWave 8.2.3 User Guide.
Custom Certificate Support for RAP
As Suite-B mandates using the AES-GCM encryption and ECDSA certificates for security, this feature allows you to upload custom RSA and ECDSA certificates to a RAP. This allows custom certificates to be used for IKEv2 negotiation which establishes a tunnel between the RAP and the controller. Feature support includes the ability to: n n n n n
Upload a single CA certificate and RAP certificate which have either elliptical crypto key parameters with
ECDSA or RSA parameters for signing and verification.
Store the certificate in the flash of the RAP
Store CSR and private key files in a USB
Delete certificates
Generate a CSR paired with a private key generation for the RAP. The private key is stored in the flash and the CSR can be exported out of the RAP to get it signed by the CA.
If there is a custom certificate present in the flash when rebooting, this feature creates a suite B tunnel with the controller if the certificates uploaded are using EC algorithms. Otherwise it creates a tunnel using standard RAP
IPSec parameters.
Suite-B Support for ECDSA Certificate
If a custom ECDSA certificate is present in the flash of a certificate-based RAP, it is automatically designated as a
Suite-B RAP. On the controller side, tunnel creation uses the server certificate as a default VPN server certificate.
Administering Suite-B support for a RAP includes these steps which are described in the following sections:
1. Setting the Default Server Certificate
2. Import a custom certificate
3. Generate a Certificate Signing Request (CSR)
4. Upload the certificate
ArubaOS 6.5.3.x
| User Guide Management Access | 856
Setting the Default Server Certificate
In the CLI
To set the default server certificate that is presented to the RAP as the default VPN server certificate:
(host) (config) #crypto-local isakmp server-certificate
<server_certificate_name>
To add the CA certificate to verify the RAP certificate:
(host) (config) #crypto-local isakmp ca-certificate <trusted CA>
Importing a Custom Certificate
Certificates can only be imported to the controller using the WebUI.
In the WebUI
1. Navigate to Configuration > Management > Certificates and upload the certificate.
2. To use imported certificates to create a tunnel, navigate to Configuration > Advanced Services >
Emulate VPN Services .
Generating a CSR
The RAP console page allows you to generate a CSR. This is done through a private key which can be generated and saved to the RAP flash. A corresponding CSR is exported so it can be signed by the required CA to use as the RAP certificate. This RAP certificate can then be uploaded using the Upload button on the RAP Console page.
The subject of the RAP certificate needs to be the MAC address of the RAP, and nothing more. Note that this is case insensitive.
If you create a CSR on the RAP and then have a certificate issued by a CA, you must have the certificate in PEM format before uploading it to the RAP.
Uploading the Certificate
When using the “rapconsole.arubanetworks.com” page on a bridge/split-tunnel RAP to manage certificates on the
RAP, a blank page or a page that does not have the Certificates tabs on it may display. The RAP provisioning page that is standard on the RAP may conflict with the “rapconsole” page and thus confuse the browser. If this occurs, clear your browser cache first or use two different browsers.
The Upload button on the RAP console page that lets you upload the certificates to the RAP flash. The certificate needs to be in PEM format and uploading the RAP certificate requires that the corresponding private key is present in the RAP flash. Or, use the PKCS12 bundle where the chain includes the RAP private key with the RAP and CA certificates are optionally password protected.
Storing CSR and Private Key Files in a USB
To provision a RAP to store the CSR and private key in a USB, use one of the following options:
AP Boot Prompt
At the AP boot prompt, issue the setenv usb_csr 1 and setenv usb_type 100 commands.
If this option is used to provision the RAP to store the files in the USB device, after the files are saved in the USB, enter the AP boot prompt to issue the setenv usb_csr 0 command. This is mandatory.
In the WebUI
1. Navigate to Configuration > Wireless > AP Installation > Provisioning .
857 | Management Access ArubaOS 6.5.3.x | User Guide
2. Select the RAP, click Provision .
3. Under USB Settings , select the USB Parameters check box.
4. Select the USB storage for CSR/Key check box.
5. Select Device Type as storage .
6. Click Apply and Reboot .
In the CLI
(host) (config) #provision-ap
(host) (AP provisioning) #read-bootinfo ap-name <ap name>
(host) (AP provisioning) #usb-csr
(host) (AP provisioning) #usb-type storage
RAP Console
1. Navigate to Configuration > Management > Certificates .
2. For Store CSR and key in USB/Flash , select USB from the drop-down list.
After the RAP is provisioned to store the CSR and private key in a USB, log in to the RAP console, export the CSR and private key files to the USB. A .p12
certificate file format must be manually created as the RAP certificate in the USB to bring up the IKE/IPSEC connection.
Implementing a Specific Management Password Policy
By default, the password for a new management user has no requirements other than a minimum length of 6 alphanumeric or special characters. However, if your company enforces a best practices password policy for management users with root access to network equipment, you may want to configure a password policy that sets requirements for management user passwords.
Defining a Management Password Policy
To define specific management password policy settings through the WebUI or the CLI, complete the following steps:
In the WebUI
1. Navigate to Configuration>All Profiles .
2. Expand Other Profiles .
3. Select Mgmt Password Policy .
4. Configure the settings described in
.
ArubaOS 6.5.3.x
| User Guide Management Access | 858
Table 195: Management Password Policy Settings
Parameter Description
Enable Password Policy
Minimum password length required
Minimum number of Upper
Case characters
Minimum number of Lower
Case characters
Minimum number of Digits
Select this checkbox to enable the password management policy. The password policy will not be enforced until this checkbox is selected.
The minimum number of characters required for a management user password
Range: 6-64 characters. Default: 6.
The minimum number of uppercase characters required in a management user password.
Range: 0-10 characters. By default, there is no requirement for uppercase letters in a password, and the parameter has a default value of 0.
The minimum number of lowercase characters required in a management user password.
Range: 0-10 characters. By default, there is no requirement for lowercase letters in a password, and the parameter has a default value of 0.
The minimum number of numeric digits required in a management user password.
Range: 0-10 digits. By default, there is no requirement for numerical digits in a password, and the parameter has a default value of 0.
Minimum number of Special characters (!, @, #, $, %, ^, &, *,
<, >, {, }, [, ], :, ., comma, |, +, ~,
`)
The minimum number of special characters.
Range: 0-10 characters.
Username or Reverse of username NOT in Password
Maximum consecutive character repeats
When you select this checkbox, the password cannot be the management users’ current username or the username spelled backwards.
The maximum number of consecutive repeating characters allowed in a management user password.
Range: 0-10 characters. By default, there is no limitation on the numbers of character that can repeat within a password, and the parameter has a default value of 0 characters.
Maximum Number of failed attempts in 3 minute window to lockout user
Time duration to lock out the user upon crossing the "lockout" threshold
The number of failed attempts within a 3 minute window that causes the user to be locked out for the period of time specified by the Time duration to lockout the user upon crossing the "lock-out" threshold parameter.
Range: 0-10 attempts. By default, the password lockout feature is disabled, and the default value of this parameter is 0 attempts.
The duration in time that locks out the user upon crossing the lock out threshold.
Range: 0-60 in minutes.
5. Click Apply to save your settings.
In the CLI aaa password-policy mgmt
Management Authentication Profile Parameters
describes configuration parameters on the Management Authentication profile page.
859 | Management Access ArubaOS 6.5.3.x | User Guide
In the CLI, you configure these options with the aaa authentication mgmt and aaa-server-group commands.
Table 196: Management Authentication Profile Parameters
Parameter Description
Enable
Default Role
Root guestprovisioning
Enables authentication for administrative users.
Select a predefined management role to assign to authenticated administrative users.
Default superuser role.
Guest provisioning role.
location-apimgmt
Location API role.
Standard Role A role that has all the root privileges but cannot make changes to the management users.
networkoperations
Network operations role.
no-access No commands are accessible for this role.
read-only no access
Server Group
Read-only role.
Negates any configured parameter.
Name of the group of servers used to authenticate administrative users. See the CLI command aaa-server-group , in the CLI Command Reference Guide for more information.
Configuring AP Image Preload
The AP image preload feature minimizes the downtime required for a controller upgrade by allowing the APs associated to that controller to download the new images before the controller actually starts running the new version.
This feature is supported only on the 7000 Series and 7200 Series controllers.
This feature allows you to select the maximum number of APs that are allowed to preload the new software image at any one time, thereby reducing the possibility that the controller may get overloaded or that network traffic may be impacted by all APs on the controller attempting to download a new image at once.
APs can continue normal operation while they are downloading their new software version. When the download completes, the AP sends a message to the controller, informing it that the AP has either successfully downloaded the new software version, or that the preload has failed for some reason. If the download fails, the AP will retry the download after a brief waiting period.
You can allow every AP on a controller to preload a new software version, or also create a custom list of AP groups or individual APs that can use this feature. If a new AP associates to the controller while the AP image download feature is active, the controller will check that AP’s name and group to see if it appears in the preload list. If an AP is on the list, (and does not already have the specified image in its Flash memory) that AP will start preloading its image.
ArubaOS 6.5.3.x
| User Guide Management Access | 860
Once a software version has been downloaded, another version cannot be downloaded until the AP reboots.
Enable and Configure AP Image Preload
Use the following procedures to enable and configure the AP Image Preload feature on the 7000 Series and
7200 Series controllers using the WebUI or CLI.
In the WebUI
1. Navigate to Maintenance > WLAN > Preload AP Image . If this feature has not yet been enabled, the window will display the message “AP Image Preload status is Inactive. Click here to activate AP Image
Preload .” Click the link in the warning message to enable this feature and display the AP Image Preload settings.
2. Configure the settings described in the table below, then click Apply to save your changes.
Table 197: AP Image Preload Settings
Setting Description
AP Image Preload
Partition
Software Version
Select Enable to enable this feature, or Disable to disable AP image preload. AP image preload is disabled by default.
NOTE: This feature can also be enabled and disabled with its current configuration settings in the Maintenance > Controller > Image Management window.
Select the controller partition from which the APs should download their images. By default, the APs will preload images from the controller’s default boot partition.
This field shows the image on the partition that will be preloaded onto eligible APs, and is not editable.
Maximum Number of Simultaneous downloads
APs to Preload
Specify the maximum number of APs that can simultaneously download their image from the controller. A higher number will decrease the time it takes for many APs to preload their new image, but will increase the workload on the controller.
In this field, select All APs if you want to preload images on all registered APs that are eligible for preload and that support this feature, or select Specific APs to preload images on a list of selected APs.
If you selected Specific APs , you must create a list of APs allowed to preload images.
You can preload images to a group of APs, or specify APs that can use this feature by identifying those APs by AP name.
To preload images to a group of APs:
1. In the AP Groups field, click Add .
2. Type the AP Group Name, or select the AP Group from the list.
3. Click OK . (To remove AP groups from this list of APs using this feature, select an AP group name in the list, then click Delete .)
To preload images to APs with specific name:
1. In the AP Names field, click Add.
2. Type the AP Name, or select the AP Name from the list
3. Click OK . (To remove an AP from this list of APs using this feature, select an AP name in the list, then click Delete .)
In the CLI
To configure the AP image preload feature using the command-line interface, enter the following commands in enable mode.
ap image-preload
861 | Management Access ArubaOS 6.5.3.x | User Guide
The command ap image preload clear-all deletes all AP groups and AP names from the list of APs eligible for preloading. This command may be executed either before or after preloading is activated. If it is executed after preloading has already been activated, any APs waiting to preload the new software version will be removed from the list. APs that have already begun the preloading process will continue to download their image and will not be affected.
The ap image-preload cancel command deletes all AP groups and AP names from the list of APs eligible for preloading and cancels the preloading process for any APs on the list that have already begun to download the new image. This command then disables the image preload feature.
View AP Preload Status
You can monitor the current preload status of APs using the image preload feature using the show ap imagepreload-status and show ap image-preload-status-summary commands in the command-line interface, or in the Maintenance > WLAN > Preload AP Image window in the WebUI.
The output of the show ap image-preload-status CLI command and the AP Image Preload Status and AP
Image Preload Status Summary tables in the WebUI contain the following information:
Table 198: AP Image Preload Status Settings
Column
AP Image Preload
State/Count
Count
AP Name
AP Group
AP IP
AP Type
Preload State
Start Time
End Time
Failure Count
Failure Reason
Description
These two columns list the different possible preload states for APs eligible to preload a new software image, and the total number of APs in each state.
n
Preloaded : Number of APs that have finished preloaded a new software image.
n n
Preloading : Number of APs that are currently downloading the new image.
Waiting : Number of APs that are waiting to start preloading the new image from the controller.
This column lists the number of eligible APs currently in each preload state.
Name of an AP eligible to preload a new software image.
AP group of an AP eligible to preload a new software image.
IP address of the AP.
AP model type.
Current preload state for the AP n Preloaded : The AP is finished preloading a new software image.
n n
Preloading : The AP is currently downloading the new image.
Waiting : The AP is waiting to start preloading the new image from the controller.
Time the AP starting preloading an image.
Time the AP completed the image preload.
Number of times that the AP failed to preload the new image.
In the event of an image preload failure, this column will display the reason that the image download failed.
ArubaOS 6.5.3.x
| User Guide Management Access | 862
Configuring Centralized Image Upgrades
The centralized image upgrade feature introduced in ArubaOS 6.3 allows the master controller to automatically upgrade its associated local controllers by sending an image from an image server to one or more local controllers. If your master controller supports different local controller models, you can upload different image types to the server, and the centralized image upgrade feature will send the local controller only the type of image that controller supports.
Configuring Centralized Image Upgrades
This feature can be configured on a master controller only, and supports up to 100 simultaneous downloads.
You can configure a centralized image upgrade using the WebUI or command-line interfaces.
Using the WebUI
1. Navigate to Maintenance > Controller > Image Management .
2. Click the Local Configuration tab.
3. Click the Enable checkbox to enable this feature. When this option is selected, the WebUI displays the following centralized image configuration parameters.
Table 199: Centralized Image Upgrade Configuration Parameters
Parameter Description
Protocol Specify the protocol used to send the software upgrade from the image server to the local controller.
n TFTP n n
FTP
SCP
IP address of the image server.
Server IP address
Username
Password
If you selected the FTP or SCP protocol in the Protocol field, enter the username that
ArubaOS uses to connect to the image server
If you selected the FTP or SCP protocol in the Protocol field, enter the password that
ArubaOS uses to connect to the image server
Location on the image server where the image file(s) are located Relative
Filepath
Max downloads
Reboot automatically
Maximum number of local controllers that can simultaneously download a file from a file server. The centralized image downloading feature supports up to 100 simultaneous downloads. If this field is left blank, ArubaOS will use its default value of 10 downloads.
Select this checkbox to allow the local controllers to reboot after they download their new images.
NOTE: If you enable this option, local controllers will reboot without saving any changes to their current configuration. If you have any unsaved configuration changes on your local controller that you want to retain, do not enable this option
4. Configure the image server settings described in the table above, then click Apply to save your changes.
5. Click the Verify button at the bottom of the Maintenance > Controller > Image Management > Local
Configuration page. When you verify the upgrade profile, the master controller attempts to connect to the file server, download the different images for each unique local controller (for example, ArubaOS_MMC,
ArubaOS_6xx or ArubaOS_72xx) and verify the validity of the image. Once controller images are “verified”
863 | Management Access ArubaOS 6.5.3.x | User Guide
by the master controller, the local controllers that are in the upgrade target list connect to the file server, download the appropriate image, and upgrade their software to the downloaded version.
Next, specify which local controllers should download the image from the image server. You can allow all local controllers on the master to download an image from the upgrade server, or configure this feature to allow only controllers with a specified IP address or subnet to download the image. The upgrade target controllers are configured in the Upgrade Target section of the Maintenance > Controller > Image Management >
Local Configuration page.
n n
Allow All Targets : To allow all local controllers associated with that master to download an image from the image server, select the all option in the Upgrade Target section.
Select Targets by IP address/Subnet : To allow local controllers with a specific IP address or subnet mask to download the image:
1. Click New .
2. Enter the IP address of a controller or the subnet mask of a group of local controllers.
3. Click Add .
4. (Optional) Repeat steps 1-3 to add a new target.
5. Click Apply to save your changes.
To remove a controller from the list of upgrade targets, click Delete by the IP address or subnet entry in the
Upgrade Targets table. To clear the entire list of controllers in the Upgrade Targets table, click the Purge the entire target list checkbox.
In the CLI
Access the command-line interface of the master controller in config mode, and issue the following command: upgrade-profile
The following commands are available in enable mode on master controllers: upgrade verify upgrade target
Viewing Controller Upgrade Statistics
The Maintenance > Controller > Image Management > Upgrade Status page in the WebUI and the output of the show upgrade status and show upgrade configuration commands in the command-line interface display current controller upgrade statistics.
Table 200: All Controllers Table Data
Column Description
IP Address
Hostname
Type
IP address of a controller that can download images from the image file server.
Name of the controller.
Controller type (local or master)
ArubaOS 6.5.3.x
| User Guide Management Access | 864
Column
Model
Version
Upgrade Status
Description
Controller model.
Version of software currently running on the controller.
A controller configured to use the centralized image update feature can have one of the following upgrade status types: n
N/A : Not applicable. Only the master controller has this status type. (Or the active master if a standby controller is configured.) n n n
Rebooting : The local controller upgraded its image and is rebooting.
Up-to-date : The local or standby controller is running the same image as the master controller.
Waiting, image not verified : The local controller is waiting for the master controller to verify the images are present in the file server.
n n n
Not Supported : The local controller version is lower than ArubaOS 6.3 and does not support the upgrade feature.
Upgraded, reboot required : The local controller upgraded its image and a reboot is needed. A controller can have this status if the auto-reboot setting is not enabled in the upgrade profile.
Not part of target : The local controller image version does not match with the master and requires an upgrade, but is not part of the target upgrade list.
Managing Certificates
The controller is designed to provide secure services through the use of digital certificates. Certificates provide security when authenticating users and computers and eliminate the need for less secure password-based authentication.
There is a default server certificate installed in the controller to demonstrate the authentication of the controller for captive portal and WebUI management access. However, this certificate does not guarantee security in production networks. Aruba strongly recommends that you replace the default certificate with a custom certificate issued for your site or domain by a trusted Certificate Authority (CA). This section describes how to generate a Certificate Signing Request (CSR) to submit to a CA and how to import the signed certificate received from the CA into the controller.
The controller supports client authentication using digital certificates for specific user-centric network services, such as AAA FastConnect, VPN (see
Virtual Private Networks on page 352 ), and WebUI and SSH management
access. Each service can employ different sets of client and server certificates.
During certificate-based authentication, the controller provides its server certificate to the client for authentication. After validating the controller’s server certificate, the client presents its own certificate to the controller for authentication. To validate the client certificate, the controller checks the certificate revocation list (CRL) maintained by the CA that issued the client certificate. After validating the client’s certificate, the controller can check the user name in the certificate with the configured authentication server (this action is optional and configurable).
When using X.509 certificates for authentication, if a banner message has been configured on the controller, it displays before the user can login. Click on a “login” button after viewing the banner message to complete the login process.
About Digital Certificates
Clients and the servers to which they connect may hold authentication certificates that validate their identities.
When a client connects to a server for the first time, or the first time since its previous certificate has expired or been revoked, the server requests that the client transmit its authentication certificate. The client’s certificate is then verified against the CA which issued it. Clients can also request and verify the server’s authentication
865 | Management Access ArubaOS 6.5.3.x | User Guide
certificate. For some applications, such as 802.1X authentication, clients do not need to validate the server certificate for the authentication to function.
Digital certificates are issued by a CA which can be either a commercial, third-party company or a private CA controlled by your organization. The CA is trusted to authenticate the owner of the certificate before issuing a certificate. A CA-signed certificate guarantees the identity of the certificate holder. This is done by comparing the digital signature on a client or server certificate to the signature on the certificate for the CA. When CAsigned certificates are used to authenticate clients, the controller checks the validity of client certificates using certificate revocation lists (CRLs) maintained by the CA that issued the certificate.
Digital certificates employ public key infrastructure (PKI), which requires a private-public key pair. A digital certificate is associated with a private key, known only to the certificate owner, and a public key. A certificate encrypted with a private key is decrypted with its public key. For example, party A encrypts its certificate with its private key and sends it to party B. Party B decrypts the certificate with party A’s public key.
Obtaining a Server Certificate
Best practices is to replace the default server certificate in the controller with a custom certificate issued for your site or domain by a trusted CA. To obtain a security certificate for the controller from a CA:
1. Generate a Certificate Signing Request (CSR) on the controller using either the WebUI or CLI.
2. Submit the CSR to a CA. Copy and paste the output of the CSR into an email and send it to the CA of your choice.
3. The CA returns a signed server certificate and the CA’s certificate and public key.
4. Install the server certificate, as described in
Importing Certificates on page 867.
There can be only one outstanding CSR at a time in the controller. Once you generate a CSR, you need to import the
CA-signed certificate into the controller before you can generate another CSR.
In the WebUI
1. Navigate to the Configuration > Management > Certificates > CSR page.
2. Enter the following information:
Table 201: CSR Parameters
Parameter
CSR Type
Curve name
Description
Type of the CSR.
You can generate a certificate signing request either with an Elliptic curve (EC) key, or with a Rivest-
Shamir-Aldeman (RSA) key .
Length of the private/public key for ECDSA. This is applicable only if CSR Type is ec .
Key Length
Common Name
Length of the private/public key for RSA.
This is applicable only if CSR Type is rsa .
NOTE: RSA-1024 is not permitted if the controller is operating in the FIPS mode.
Typically, this is the host and domain name, as in www.example.com.
Range ec/rsa secp256r1/secp384r1
1024/2048/4096
—
ArubaOS 6.5.3.x
| User Guide Management Access | 866
Parameter
Country
State/Province
City
Organization
Unit
Email Address
Description
Two-letter ISO country code for the country in which your organization is located.
State, province, region, or territory in which your organization is located.
City in which your organization is located.
Name of your organization.
Optional field to distinguish a department or other unit within your organization.
Email address referenced in the CSR.
Range
3. Click Generate New .
4. Click View Current to display the generated CSR. Select and copy the CSR output between the BEGIN
CERTIFICATE REQUEST and END CERTIFICATE REQUEST lines, paste it into an email and send it to the CA of your choice.
In the CLI
1. Run the following command: crypto pki csr {rsa key_len <key_val> |{ec curve-name <key_val>} common_name <common_val> country <country_val> state_or_province <state> city <city_val> organization <organization_ val> unit <unit_val> email <email_val>
RSA-1024 is not permitted if the controller is operating in the FIPS mode.
2. Display the CSR output with the following command: show crypto pki csr
3. Copy the CSR output between the BEGIN CERTIFICATE REQUEST and END CERTIFICATE REQUEST lines, paste it into an email and send it to the CA of your choice.
Obtaining a Client Certificate
You can use the CSR generated on the controller to obtain a certificate for a client. However, since there may be a large number of clients in a network, you typically obtain client certificates from a corporate CA server. For example, in a browser window, enter http://<ipaddr>/crtserv, where <ipaddr> is the IP address of the CA server.
Importing Certificates
Use the WebUI or the CLI to import certificates into the controller.
You cannot export certificates from the controller.
You can import the following types of certificates into the controller: n n
Server certificate signed by a trusted CA. This includes a public and private key pair.
CA certificate used to validate other server or client certificates. This includes only the public key for the certificate.
867 | Management Access ArubaOS 6.5.3.x | User Guide
n n n
Client certificate and client’s public key. (The public key is used for applications such as SSH which does not support X509 certificates and requires the public key to verify an allowed certificate.)
Certificates can be in the following formats: n n n
X509 PEM unencrypted
X509 PEM encrypted with a key
DER
PKCS7 encrypted
PKCS12 encrypted
In the WebUI
1. Navigate to the Configuration > Management > Certificates > Upload page.
2. For Certificate Name , enter a user-defined name.
3. For Certificate Filename , click Browse to navigate to the appropriate file on your computer.
4. If the certificate is encrypted, enter the passphrase.
5. Select the Certificate Format from the drop-down menu.
6. Select the Certificate Type from the drop-down menu.
7. Click Upload to install the certificate in the controller.
In the CLI
Use the following command to import CSR certificates: crypto pki-import {der|pem|pfx|pkcs12|pkcs7} {PublicCert|ServerCert|TrustedCA} <name>
The following example imports a server certificate named cert_20 in DER format: crypto pki-import der ServerCert cert_20
Viewing Certificate Information
In the WebUI, the Certificate Lists section of the page lists the certificates that are currently installed in the controller. Click View to display the contents of a certificate.
To view the contents of a certificate with the CLI, use the following commands:
Table 202: Certificate Show Commands
Command Description show crypto-local pki trustedCAs [<name>]
[<attribute>] show crypto-local pki serverCerts [<name>]
[<attribute>]
Displays the contents of a trusted CA certificate. If a name is not specified, all CA certificates imported into the controller are displayed. If name and attribute are specified, then only the attribute in the certificate are displayed. Attributes can be CN, validity, serial-number, issuer, subject, public-key.
Displays the contents of a server certificate. If a name is not specified, all server certificates imported into the controller are displayed.
show crypto-local pki publiccert [<name>]
[<attribute>]
Displays the contents of a public certificate. If a name is not specified, all public certificates imported into the controller are displayed.
ArubaOS 6.5.3.x
| User Guide Management Access | 868
Imported Certificate Locations
Imported certificates and keys are stored in the following locations in flash on the controller:
Table 203: Imported Certificate Locations
Location
/flash/certmgr/trustedCAs
/flash/certmgr/serverCerts
/flash/certmgr/CSR
/flash/certmgr/publiccert
Description
Trusted CA certificates, either for root or intermediate CAs. Best practices is to import the certificate for an intermediate CA, you also import the certificate for the signing CA.
Server certificates. These certificates must contain both a public and private key (the public and private key must match). You can import certificates in PKCS12 and X509 PEM formats, but they are stored in
X509 PEM DES encrypted format.
Temporary certificate signing requests (CSRs) that have been generated on the controller and are awaiting a CA to sign them.
Public key of certificates. This allows a service on the controller to identify a certificate as an allowed certificate.
Checking CRLs
A CA maintains a CRL that contains a list of certificates that have been revoked before their expiration date.
Expired client certificates are not accepted for any user-centric network service. Certificates may be revoked because certificate key has been compromised or the user specified in the certificate is no longer authorized to use the key.
When a client certificate is being authenticated for a user-centric network service, the controller checks with the appropriate CA to make sure that the certificate has not been revoked.
The controller does not support download of CRLs.
Certificate Expiration Alert
The certificate expiration alert sends alerts when installed certificates, which correspond to trust chains, OCSP responder certificates, and any other certificates installed on the device. By default, the system sends this alert
60 days before the expiration of the installed credentials. This alert is then repeated periodically on a weekly or biweekly basis. This alerts consist of two SNMP traps: n n wlsxCertExpiringSoon wlsxCertExpired
Chained Certificates on the RAP
Chained certificates on the RAP (that is, certificates from a multi-level PKI) need to be in a particular order inside the file. The RAP’s certificate must be first, followed by the certificate chain in order, and then followed by the private key for the certificate. For example, with a root CA, a single intermediate CA, and a root CA, the PEM or
PKCS12 file must contain the following parts, in this order:
1. RAP Certificate
2. Intermediate CA
3. Root CA
4. Private key
869 | Management Access ArubaOS 6.5.3.x | User Guide
If this order is not followed, certificate validation errors occur. This order also applies to server certificates.
Support for Certificates on USB Flash Drives
This release now supports storing RAP certificates in a USB device. This ensures that the RAP certificate is activated only when the USB with the corresponding certificate is connected to the RAP. If the USB is removed from the RAP, the RAP certificate is deactivated and when the USB is connected to the RAP it acts a storage device and not as a 3G/4G RAP.
The RAP supports only PKCS12-encoded certificates that are present in the USB. This certificate contains all the information that is required for creating the tunnel including the private key, RAP certificate with the chain of certificates, and the trusted CA certificate. There is a limit of three supported intermediate CAs.
Ensure you adhere to the following file naming guidelines when you are saving the certificate: n n n
The first twelve characters of the certificate file name should be the RAP's MAC address. For example, if
RAP’s eth0 MAC address is 00:0b:86:c2:00:6c, then the file name will be 000B86C2006C.P12 or
000B86C2006C_rap155.p12
All alphabets of the MAC address in the file name should be in upper case.
The file name can have additional characters after the MAC address separated by "_" for the purpose of identification.
If this naming convention is not followed an error will occur during certificate validation.
Follow the steps below to configure the USB certificate store:
1. Copy the PKCS12 certificate bundle to a USB device.
2. Enter a name for the certificate using the correct naming convention as mentioned above.
In the USB connected to the RAP, delete any duplicate <mac-address>.p12
certificate file. Only one such file must be present in the USB.
If you unplug the USB device the RAP will become unresponsive. Reboot the RAP to bring it up with a custom certificate, if the USB device was unplugged.
Marking the USB Device Connected as a Storage Device
If the AP provisioning parameter “usb-type” contains the value “storage,” this indicates that the RAP will retrieve certificates from the connected USB flash drive.
RAP Configuration Requirements
The RAP needs to have one additional provisioning parameter, the pkcs12_passphrase, which can be left untouched or can store an ACSII string. The string assigned to this parameter is used as the passphrase for decoding the private key stored.
If you have an activated RAP that is using USB storage for the certificate, and you remove the USB storage, the RAP drops the tunnel. This is by design. However, for the RAP to re-establish the tunnel it has to be power cycled. It does not matter if you reinsert the USB storage before or after the power cycle as long as you power cycle it.
When the RAP successfully extracts all the information including the CA certificate, the RAP certificate and the
RAP private key using the passphrase from the provisioning parameter, it successfully establishes the tunnel.
ArubaOS 6.5.3.x
| User Guide Management Access | 870
Certificate Support for Non-TPM Devices
Most of the Aruba devices contain a TPM chip that securely stores keys and performs cryptographic operations. However, some devices do not have a TPM chip. So, the unique private keys for those devices are stored in flash. Therefore, the level of protection for the device reduces.
To overcome this challenge, ArubaOS 6.5.3.0 introduces a new PKI which issues device certificates for non-TPM devices. Non-TPM devices are low-assurance devices. The device certificates for non-TPM devices consist of a policy OID indicating that they are issued by the PKI.
A 256-bit random number generated by non-TPM devices is used to encrypt a private key that is unique to each device. The key is encrypted by AES encryption. Non-TPM devices compress and store the encrypted private key file and the certificate files in Flash. The private key is maintained in an encrypted format. APIs are provided to applications that use the private key.
Enabling Low-Assurance Devices
By default, the controllers do not allow the low-assurance devices to connect. To enable low-assurance devices to connect to a controller, a new parameter, allow-low-assurance-devices is introduced under the cryptolocal pki command. This parameter is disabled by default.
Execute the following command to enable low-assurance devices on a controller:
(host) (config) #crypto-local pki allow-low-assurance-devices
After the low-assurance devices are enabled on the controller, the factory certificate presented by the device is validated against the device certificate stored on the controller.
Configuring SNMP
Aruba controllers support versions 1, 2c, and 3 of Simple Network Management Protocol (SNMP) for reporting purposes only. In other words, SNMP cannot be used for setting values in an Aruba system in the current
ArubaOS version.
MIB Reference Guide for information about the Aruba MIBs and SNMP traps..
Aruba-specific management information bases (MIBs) describe the objects that can be managed using SNMP. See the ArubaOS MIB Reference Guide for information about the Aruba MIBS and SNMP traps.
SNMP Parameters for the Controller
You can configure the following SNMP parameters for the controller.
Table 204: SNMP Parameters for the Controller
Field
Host Name
System Contact
System Location
Read Community Strings
Description
Host name of the controller.
Name of the person who acts as the System Contact or administrator for the controller.
String to describe the location of the controller.
Community strings used to authenticate requests for SNMP versions before version 3.
NOTE: This is needed only if using SNMP v2c and is not needed if using version 3.
871 | Management Access ArubaOS 6.5.3.x | User Guide
Field Description
Enable Trap Generation
Trap receivers
If you are using SNMPv3 to obtain values from the controller, you can configure the following parameters:
User name A string representing the name of the user.
Authentication protocol An indication of whether messages sent on behalf of this user can be authenticated, and if so, the type of authentication protocol used. This can take one of the two values: n
MD5: HMAC-MD5-96 Digest Authentication Protocol n
SHA: HMAC-SHA-96 Digest Authentication Protocol
Authentication protocol password
Enables generation of SNMP traps to configured SNMP trap receivers.
Refer to the list of traps in the “SNMP traps” section below for a list of traps that are generated by the controller.
Host information about a trap receiver. This host needs to be running a trap receiver to receive and interpret the traps sent by the Aruba controller.
Configure the following for each host/trap receiver: n n
IP address
SNMP version: can be 1, 2c, or 3.
n n n n
Type: Trap or Inform (SNMPv2c or SNMPv3 only)
Engine ID: (SNMPv3 only)
Security string
UDP port on which the trap receiver is listening for traps. The default is the UDP port number 162. This is optional, and will use the default port number if not modified by the user.
Privacy protocol
Privacy protocol password
If messages sent on behalf of this user can be authenticated, the (private) authentication key for use with the authentication protocol. This is a string password for MD5 or SHA depending on the choice above.
An indication of whether messages sent on behalf of this user can be protected from disclosure, and if so, the type of privacy protocol which is used. This takes the value DES (CBC-DES Symmetric Encryption Protocol).
If messages sent on behalf of this user can be encrypted/decrypted with
DES, the (private) privacy key for use with the privacy protocol.
Follow the steps below to configure a controller’s basic SNMP parameters.
In the WebUI
1. Navigate to the Configuration > Management > SNMP page.
2. If the controller will be sending SNMP traps, click Add in the Trap Receivers section to add a trap receiver.
3. If you are using SNMPv3 to obtain values from the controller, click Add in the SNMPv3 Users section to add a new SNMPv3 user.
4. Click Apply .
In the CLI hostname name syscontact name syslocation string snmp-server community string snmp-server enable trap snmp-server engine-id engine-id snmp-server host ipaddr version {1|2c|3} string [udp-port number ] snmp-server trap source ipaddr snmp-server user name [auth-prot {md5|sha} password priv-prot DES password
ArubaOS 6.5.3.x
| User Guide Management Access | 872
Earlier versions of ArubaOS supported SNMP on individual APs. This feature is not supported by this version of
ArubaOS.
Enabling Capacity Alerts
Use the capacity alert feature to set controller capacity thresholds which, when exceeded, will trigger alerts. The controller will send a wlsxThresholdExceeded SNMP trap and a syslog error message when the controller has exceeded a set percentage of the total capacity for that resource. A wlsxThresholdCleared SNMP trap and error message will be triggered if the resource usage drops below the threshold once again.
The following table describes the thresholds that can be configured with this feature.
Table 205: Capacity Alert Thresholds
Threshold Description controlpath-cpu controlpath-memory Set an alert threshold for controlpath memory consumption. The <percentage> parameter is the percentage of the total memory capacity that must be exceeded before the alert is sent. The default threshold for this parameter is 80%.
datapath-cpu
Set an alert threshold for controlpath CPU capacity. The <percentage> parameter is the percentage of the total controlpath CPU capacity that must be exceeded before the alert is sent. The default threshold for this parameter is 80%.
no-of-APs
Set an alert threshold for datapath CPU capacity. The <percentage> parameter is the percentage of the total datapath CPU capacity that must be exceeded before the alert is sent. The default threshold for this parameter is 30%.
The maximum number of APs that can be connected to a controller is determined by that controller’s model type and installed licenses. Use this command to trigger an alert when the number of APs currently connected to the controller exceeds a specific percentage of its total AP capacity. The default threshold for this parameter is 80%.
no-of-locals Set an alert threshold for the master controller’s capacity to support branch and local controllers. A master controller can support a combined total of 256 branch and local controllers. The <percentage> parameter is the percentage of the total master controller capacity that must be exceeded before the alert is sent. The default threshold for this parameter is 80%.
total-tunnel-capacity Set an alert threshold for the controller’s tunnel capacity. The <percentage> parameter is the percentage of the controller’s total tunnel capacity that must be exceeded before the alert is sent. The default threshold for this parameter is 80% user-capacity Set an alert threshold for the controller’s user capacity. The <percentage> parameter is the percentage of the total resource capacity that must be exceeded before the alert is sent. The default threshold for this parameter is 80%.
In the WebUI
1. Navigate to the Configuration > Management > Threshold page.
2. Modify the capacity percentages for any of the thresholds described in
.
3. Click Apply to save your settings.
In the CLI
4. To configure this feature, access the command-line interface in config mode and issue the following commands:
873 | Management Access ArubaOS 6.5.3.x | User Guide
threshold
Sample Configuration
The following command configures a new alert threshold for datapath memory consumption:
(host) (config) #threshold datapath-cpu 90
If this threshold is exceeded then subsequently drops below the 90% threshold, the controller would send the following two syslog error messages.
May 14 13:13:58 nanny[1393]: <399816> <ERRS> |nanny| Resource 'Control-Path Memory' has gone above 90% threshold, value : 93
May 14 13:16:58 nanny[1393]: <399816> <ERRS> |nanny| Resource 'Control-Path Memory' has come below 90% threshold, value : 87
Configuring Logging
This section outlines the steps required to configure logging on a controller.
For each category or subcategory of message, you can set the logging level or severity level of the messages to be logged.
Table 206: Categories or Subcategories
Category/Subcategory Description ap-debug arm network security system user user-debug wireless
AP debug messages
ARM messages
Network messages
Security messages
System messages
User messages
User debug system messages
Wireless messages
lists the logging levels:
Table 207: Logging Levels
Category/Subcategory
Network all packet-dump mobility dhcp
Description
Network messages
All network messages
Protocol packet dump messages
Mobility messages
DHCP messages
ArubaOS 6.5.3.x
| User Guide Management Access | 874
Category/Subcategory mapc pan gp reg-tbl ap-config
Security all aaa firewall packet-trace mobility vpn dot1x ike webserver sdn gp
System all configuration messages snmp webserver ap amon amon-ale amon-amp ha
Description
SDN messages
GP messages
System messages
All system messages
Configuration messages
Messages
SNMP messages
Web server messages
AP messages
AMON messages
AMON ALE messages
AMON AMP messages
HA messages
MAPC messages
PAN messages
GB messages
Reg-table messages
AP-config messages
Security messages
All security messages
AAA messages
Firewall messages
Packet trace messages
Mobility messages
VPN messages
802.1X messages
IKE messages
Web server messages
875 | Management Access ArubaOS 6.5.3.x | User Guide
Category/Subcategory all captive-portal vpn dot1x radius voice client-match mapc pan
ARM all client-match radio-match ntlm kerberos ids ids-ap cpsec db certmgr wl-sync
HA auth-amon
Wireless all
User
Description
NTLM messages
Kerberos messages
IDS messages
IDS-AP messages
CPsec messages
Databse messages
CertMgr messages
WL-Sync messages
HA messages
Auth-AMON messages
Wireless messages
All wireless messages
User messages
All user messages
Captive portal user messages
VPN messages
802.1X messages
RADIUS messages
Voice messages
Client-match messages
MAPC messages
PAN messages
ARM messages
All ARM messages
Client-match messages
Radio-match messages
For each category or subcategory, you can configure a logging level.
ArubaOS 6.5.3.x
| User Guide Management Access | 876
Table 208: Logging Levels
Logging Level
Emergencies
Alerts
Critical
Errors
Warnings
Notifications
Informational
Debugging
Description
Panic conditions that occur when the system becomes unusable.
Any condition requiring immediate attention and correction.
Any critical conditions such as a hard drive error.
Error conditions.
Warning messages.
Significant events of a non-critical and normal nature.
Messages of general interest to system users.
Messages containing information useful for debugging.
The default logging level for all categories is Warning. You can also configure IP address of a syslog server to which the controller can direct these logs.
In the WebUI
1. Navigate to the Configuration > Management > Logging > Servers page.
2. To configure logging server, select the Servers tab.
3. To add a logging server, click New in the Logging Servers section.
4. Click Add to add the logging server to the list of logging servers. Ensure that the syslog server is enabled and configured on this host.
5. Select the IP address type (IPv4 address or IPv6 address) of the logging server.
6. Type the IPv4 address or IPv6 address of the logging server.
7. Select the category or subcategory to log.
8. Select the logging facility.
9. Select the severity level.
10.Choose the logging format (CEF or RFC3164).
The ArcSight Common Event Format (CEF) is a log management standard that uses a standardized logging format so that data can easily be collected and aggregated for analysis by an enterprise management system.
11.Click
Add .
12.Click
Apply .
13.To select the types of messages you want to log, select the Levels tab.
14.Select the category or subcategory to be logged.
15.To select the severity level for the category or subcategory, scroll to the bottom of the page. Select the level from the Logging Level drop-down menu. Click Done .
16.Click
Apply to apply the configuration.
In the CLI
logging <ipaddr> logging level <level> <category> [subcat <subcategory>]
877 | Management Access ArubaOS 6.5.3.x | User Guide
Syslog operates over UDP and is connectionless. Therefore, it is not possible for the controller to recognize a failure of the syslog server or the network path to the syslog server. By establishing an IPsec tunnel between the controller and the syslog server, (see
Planning a VPN Configuration ) it is possible to indirectly track the
status of the syslog server link.
After a failure occurs, the network administrator has to manually re-synchronize log files by copying them from the controller to the syslog server. Use the tar logs CLI command to create an archive of all local logs, then use the copy CLI command to copy this archive to an external server. Log space is limited on the controller, and depending on how long the outage lasted some local logs may be overwritten.
Syslog Logging Enhancement
Currently, syslog messages originate from the controller IP. Starting from ArubaOS OS 6.5.2 a new config knob is introduced for syslog messages to originate from any IP other than the controller IP. Users now have the option of setting the source interface vlan through which syslog messages are sent to the remote server. The IP address associated with the source-interface vlan specified by the user is set as the source IP to send the syslog messages to the remote server.
The source-interface enhancement is only available for IPv4 remote server addresses.
In the WebUI
1. Navigate to Configuration > MANAGEMENT > Logging .
2. Select the Servers tab.
3. Click Edit in the Logging Servers table.
4. Select a value for the Source Interface Vlan from the drop-down menu.
5. Click Update > Apply .
In the CLI
(host) (config) #logging 1.1.1.1
(host) (config) #logging 1.1.1.1 source-interface 55 n n n
Enabling Guest Provisioning
The Guest Provisioning feature lets you manage guests who need access to your company’s wireless network.
This section describes how to:
Design and configure the Guest Provisioning page – Using the WebUI, the network administrator designs and configures the Guest Provisioning page that is used to create a guest account.
Configure a guest provisioning user – The network administrator configures one or more guest provisioning users. A guest provisioning user, such as a front desk receptionist, signs in guests at your company.
Using the Guest Provisioning page – The Guest Provisioning page is used by the guest provisioning user to create guest accounts for people who are visiting your company.
Configuring the Guest Provisioning Page
Use the Guest Provisioning Configuration page to create the Guest Provisioning page. This configuration page consists of three tabs: Guest Fields, Page Design and Email. You configure the information on all three tabs to create a Guest Provisioning page.
n
Guest Fields tab—lets you select the fields that appear on the Guest Provisioning page.
ArubaOS 6.5.3.x
| User Guide Management Access | 878
n n
Page Design tab—lets you specify the company banner, heading, and text and background colors that appear on the Guest Provisioning page.
Email tab—lets you specify an email to be sent to the guest or sponsor (or both). Email messages can be sent automatically at account creation time and also may be sent manually by the administrator from the
Guest Provisioning page.
In the WebUI
You can only create and design the Guest Provisioning page in the WebUI.
This section describes how to design a Guest Provisioning page using all three tabs.
Configuring the Guest Fields
1. Navigate to the Configuration > Management > Guest Provisioning page. The Guest Provisioning configuration page displays with the Guest Fields tab on top. This tab contains the following columns: l
Internal Name—The unique identifier that is mapped to the label in the UI.
l l
Label in UI—A customizable string that displays in both the main listing pane and details sheet on the
Guest Provisioning page.
Display in Details—Fields with selected checkboxes appear in the Show Details popup-window.
If the guest_category, account_category, sponsor_category and optional_category fields are not checked, their respective sections do not appear on the Guest Provisioning page.
l
Display in Listing—Fields with selected checkboxes appear as columns in the management user summary page.
Figure 191 Guest Provisioning Configuration Page—Guest Fields Tab
879 | Management Access ArubaOS 6.5.3.x | User Guide
2. Select the checkbox next to each field, described in
, that you want to appear on the Guest
Provisioning page. Optionally, you can customize the label that displays in the UI.
3. Click Preview Current Settings to view what the Guest Provisioning page looks like while you are designing it.
4. To save changes, click Apply .
Best practices is to check the Display in Listing field for only the most essential fields, so that the Guest
Provisioning user does not have to scroll the guest listing horizontally to see all the columns.
Table 209: Guest Provisioning—Guest Field Descriptions
Guest Field guest_category
Description guest_username guest_password guest_fullname guest_company guest_email guest_phone comments account_category creation-date start_date end_date grantor grantor_role sponsor_category
A guest is the person who needs guest access to the company’s wireless network. This is the label on the Guest Provisioning page for the guest information.
Username for the guest.
Password for the guest. (Must contain at least 1-6 characters and at least one digit.)
Full name of the guest.
Name of the guest's company.
Guest's Email address.
Guest's phone number
Optional comments about the guest's account status, meeting schedule and so on.
This is the label on the Guest Provisioning page for the account information.
Date the account is created.
Date the guest account begins.
Date the guest account ends.
The username of the person of who created the guest account.
The authentication role of the grantor.
A sponsor is the guest's primary contact for the visit. This is the label in the Guest Provisioning page for the sponsor information.
sponsor_username
Sponsor's work department sponsor_email Sponsor's Email address.
ArubaOS 6.5.3.x
| User Guide Management Access | 880
Guest Field optional_category optional_field_1 optional_field_2 optional_field_3 optional_field_4
Description
This is the label in the Guest Provisioning page for the information in the optional fields that follow.
NOTE: The optional_category field can be used for another person, for example a “Supervisor.” You can enter username, full name, department and Email information into the optional fields. Or, you can use this category for some other purpose.
optional_field_1 description optional_field_2 description optional_field_2 description optional_field_2 description
Configuring the Page Design
The Page Design tab lets you specify the company banner, heading, and text and background colors that appear on the Guest Provisioning page.
1. Navigate to the Configuration > Management > Guest Provisioning page and select the Page Design tab.
Figure 192 Guest Provisioning Configuration Page—Page Design Tab
2. Enter the filename which contains the company banner in the Banner field. Or, click Browse to search for the filename
Best practices is to use a logo or banner image that is 600 x 100 pixels (width x height). The WebUI does not apply the size restrictions when you upload an image file, but the image is resized to 600 x 100 pixels when it displays or is printed.
3. Enter the label for the guest listing (the one you used in the Guest Fields tab) in the Text field.
4. Enter the hex value for the color of the text in the Text Color field. The text in the header of the guest listing displays in this color.
881 | Management Access ArubaOS 6.5.3.x | User Guide
5. Enter the hex value for the color of the background in the Background color field. This determines the color of the header of the guest listing.
6. Click Preview Current Settings to preview the Guest Provisioning page while you are designing it.
7. To save changes, click Apply .
Configuring Email Messages
You can specify an email to be sent to the guest or sponsor (or both). Email messages can be sent automatically at account creation time or sent manually by the network administrator or guest provisioning user from the
Guest Provisioning page at any time.
1. Specify the SMTP server and port that processes the guest provisioning (also known as guest access) email.
You can complete this step using the WebUI or CLI commands: l l
Configuring the SMTP Server and Port in the WebUI on page 882
Configuring an SMTP server and port in the CLI on page 882
2. Create the email messages. Complete this step using the WebUI:
Creating Email Messages in the WebUI on page 882
Configuring the SMTP Server and Port in the WebUI
1. Navigate to the Configuration > Management > SMTP page .
2. Enter the IP address of the SMTP server to which the controller sends the guest provisioning email in the IP
Address of SMTP server field.
3. Enter the number of the port through which the guest provisioning email passes in the Port field.
4. Click Apply and then Save Configuration .
Configuring an SMTP server and port in the CLI
The following command creates a guest-access email and sends guest user email through SMTP server IP address 1.1.1.1 on port 25.
(host) (config) #guest-access-email
(host) (Guest-access Email) #smtp-port 25
(host) (Guest-access Email) #smtp-server 1.1.1.1
Creating Email Messages in the WebUI
After you configured the SMTP server and port, follow these steps:
1. Navigate to the Configuration > Management > Guest Provisioning page and select the Email tab.
ArubaOS 6.5.3.x
| User Guide Management Access | 882
Figure 193 Guest Provisioning Configuration Page—Email Tab
2. To create a message for a guest or sponsor, customize the text in the Subject , From , and Body fields as needed for both the Guest message and Sponsor message .
3. Optionally, select the Send automatically at account creation time checkbox when you want an email message to be sent to the guest and/or sponsor alerting them that a guest account has just been created.
Regardless of whether you select this option, the person responsible for managing the Guest Provisioning page may choose to send this email message manually at any time.
shows a sample email message that is sent to the guest after the guest account is created.
Figure 194 Sample Guest Account Email – Sent to Sponsor
4. To save changes, click Apply .
Configuring a Guest Provisioning User
The guest provisioning user has access to the Guest Provisioning Page (GPP) to create guest accounts within your company. The guest provisioning user is usually a person at the front desk who greets guests and creates guest accounts. Depending upon your needs, there are three ways to configure and authenticate a guest provisioning user:
883 | Management Access ArubaOS 6.5.3.x | User Guide
n n
Username and Password authentication — Allows you to configure a user in a guest provisioning role.
Smart Card authentication l l
Static authentication —Uses a configured certificate name and serial number to derive the user role. This authentication process uses a previously configured certificate name and serial number to derive the user role. This method does not use and external authentication server.
Authentication server — Uses an external authentication server to derive the management role. This is helpful if there is a large number of users who need to be deployed as guest provisioning users.
You can use the WebUI or CLI to create a Guest Provisioning user.
In the WebUI
This section describes how to configure a guest provisioning user. All three methods are described.
Username and Password Authentication Method
1. Navigate to the Configuration > Management > Administration page.
2. In the Management Users section, click Add .
3. In the Add User page select Conventional User Accounts .
4. In the User Name field, enter the name of the user who you want to configure as a guest provisioning user.
5. In the Password and Confirm Password fields, enter the user’s password and reconfirm it.
6. From the Role drop-down menu, select guest-provisioning .
7. Click Apply .
Static Authentication Method
Before using this method, make sure that the correct CA certificate is uploaded to the controller.
1. Navigate to the Configuration > Management > Administration page.
2. In the Management Users section, click Add .
3. In the Add User page, select Certificate Management .
4. Make sure that the Use external authentication server to authenticate check box is unchecked.
5. In the Username field, enter the name of the user who you want to configure as a guest provisioning user.
6. In the Role field, select guest-provisioning from the drop-down list.
7. Enter client certificate serial number in the Client Certificate Serial No.
field.
8. Select the CA certificate you want to use from the Trusted CA Certificate Name drop-down menu.
9. Click Apply .
Smart Card Authentication Method
1. Navigate to the Configuration > Management > General page.
2. In the WebUI Management Authentication Method section, select Client Certificate .
3. Click Apply .
4. Navigate to the Configuration > Management > Administration page.
5. In the Management Authentication Servers section, select guest-provisioning from the Default
Role drop-down menu.
6. Select the Mode checkbox.
7. Select the server group from the Server Group drop-down menu.
ArubaOS 6.5.3.x
| User Guide Management Access | 884
8. Click Apply .
9. In the Management Users section, click Add to display the Configuration > Management > Add User page.
10.Select
Certificate Management , WebUI Certificate and Use external authentication server to authenticate.
11.Select the trusted CA certificate you want to use from the Trusted CA Certificated Name drop-down menu.
12.Click
Apply and Save Configuration .
In the CLI
Username and Password Method
This example creates a user named Alex and assigns her the role of guest provisioning.
(host) (config)# mgmt-user Alex guest-provisioning
Static Authentication Method
This example uses the CA certificate mycertificate with the serial number 1234 to authenticate user Laura in the guest provisioning role.
(host) (config)# mgmt-user webui-cacert mycertificate serial 1234 Laura guest-provisioning
Smart Card Authentication Method
This example shows that using previously configured certificate (1234), authentication and authorization are automatically configured using an authentication server.
(host) (config) #web-server profile
(host)(Web Server Configuration) #mgmt-auth username/password certificate
(host)(Web Server Configuration) #!
(host) (config) #mgmt-user webui-cacert <certificate_name>
(host) (config) #aaa authentication mgmt
(host) (config) #server-group "internal"
(host) (config) #mgmt-user webui-cacert default
(host) (config) #mgmt-user webui-cacert 1234
Customizing the Guest Access Pass
In the WebUI, you can customize the pop-up window that displays the guest account information. You may want to do this before the Guest Provisioning user creates guest accounts.
1. Navigate to the Configuration > Security > Access Control > Guest Access page.
2. Click Browse to insert a logo or other banner information on the window.
Best practices is to use a logo or banner image that is 600 x 100 pixels (width x height). The WebUI does not apply the size restrictions when you upload an image file, but the image is resized to 600 x 100 pixels when it displays or is printed.
3. You can enter text for the Terms and Conditions portion of the window.
4. Click Submit to save your changes. Click Preview Pass to preview the window. (See
885 | Management Access ArubaOS 6.5.3.x | User Guide
Figure 195 Customized Guest Account Information Window
Creating Guest Accounts
After the Guest Provisioning user is created, that person can log in to the controller using the preconfigured username and password. The Guest Provisioning page displays. (See
Figure 197 .) This is a sample page as the
fields may differ based on how the network administrator designed the page.
Starting with ArubaOS 3.4 release, a guest user account that is created by a guest provisioning user can only be viewed, modified or deleted by the guest provisioning user who created the account or the network administrator. A guest user account that is created by the network administrator can only be viewed, modified or deleted by the network administrator.
Figure 196 Creating a Guest Account—Guest Provisioning Page
If you do not want multiple guest users to share the same guest account concurrently, navigate to the Captive Portal
Authentication and select the “Allow only one active user session” option. If a guest user authenticates successfully but the controller detects there is already a guest session with the same guest username, the second login is rejected.
Guest Provisioning User Tasks
The Guest Provisioning user creates guest accounts by filling in information on the Guest Provisioning page.
Tasks include creating, editing, manually sending email, enabling, printing, disabling and deleting guest accounts. The Guest Provisioning user can also manually send emails to either the guest or sponsor.
To create a new guest account, the Guest Provisioning user clicks New to display the New Guest window. (See
.) After filling in information into the fields, click Create . The guest account now displays on the
Guest Provisioning page.
If you manually configure the user name and password, note the following:
ArubaOS 6.5.3.x
| User Guide Management Access | 886
n n n
User name entries support alphanumeric characters, however the percent sign (%) and trailing the back slash are not allowed.
Passwords must have a minimum of six characters. You can use special characters for the password.
Click on the Account Start and End fields to change the account start and end times. The default account start to end time setting is eight hours.
Figure 197 Creating a Guest Account—New Guest Window
To see details about an existing user account, highlight an existing account and select the Show Details checkbox. The Show Details popup-window displays. (See
Figure 198 .) The Guest Provisioning user can send
out Email from this window to either the guest or the sponsor. When you send an email from the Details popup window, a pop-up message confirming that the email was successfully processed displays
887 | Management Access ArubaOS 6.5.3.x | User Guide
Figure 198 Creating a Guest Account—Show Details Pop-up Window
Importing Multiple Guest Entries
The Guest Provisioning user can manually create individual guest entries, as previously described, or import multiple guest entries into the database from a CSV file. This is useful and more efficient if you want to enter multiple guest entries at once. To import multiple guest entries, you need to:
1. Create a CSV file that contains the guest entries
2. Import the CSV file into the database
Creating Multiple Guest Entries in a CSV File
Create a CSV file that contains multiple guest entries. Each field in an entry needs to be separated by a comma and each entry needs to end with a carriage return. The order of the fields is: n n n n n n n n n
Guest’s first name (required)
Guest’s last name (required)
Guest’s email address (optional)
Guest’s phone number (optional)
Guest’s user ID (optional)
Guest’s password (optional)
Sponsor’s first name (optional)
Sponsor’s last name (optional)
Sponsor’s email address (optional)
See
for an example of how guest entries need to be formatted in a CSV file.
ArubaOS 6.5.3.x
| User Guide Management Access | 888
Figure 199 CVS File Format—Guest Entries Information
Note the following limitations when creating guest entries in a CVS file: n n n n n n
None of the field values can have a comma
There is no format checking on field. Only the local-userdb-guest CLI command will validate proper format.
Any extra columns, beyond the 9th column, are discarded.
The WebUI only supports characters that the CLI supports.
If a guest’s user ID is not provided, then it is automatically generated based on the numeric suffix in the
Import Guest List window. See
We recommend a maximum of 250 entries per CSV file.
Importing the CSV File into the Database
To import a CSV file that contains multiple guest entries, the Guest Provisioning user must follow these steps:
1. Log in to the WebUI using the username and password assigned to the Guest Provisioning user.
2. Click on Import . The Import Guest List pop-up window displays. See
889 | Management Access ArubaOS 6.5.3.x | User Guide
Figure 200 Importing a CSV file that contains Guest Entries
3. Click Browse to locate for the CSV file you want to import.
4. Click Import . A window displays that lets you open CSV file in text format. (See
file to see a summary of the number of users and error messages if users are not imported.
ArubaOS 6.5.3.x
| User Guide Management Access | 890
Figure 201 Displaying the Guest Entries Log File
5. Click Import . A window displays that lets you open CSV file in text format. (See
6. Open the text file. (See
.) Note that because no user ID is entered in the CSV file, a guest ID
(username) is automatically generated based on the default value in the Suffix for auto-generated field.
Make changes or corrections to the guest entry information in text file. A user can also change the start time and end time from this window. Save and exit the file.
891 | Management Access ArubaOS 6.5.3.x | User Guide
Figure 202 Viewing and Editing Guest Entries in the Log File
7. Click Cancel to close the Import Guest List window. Guest entries are now displayed in the Guest
Provisioning page.
Figure 203 Viewing Multiple Imported Guest Entries—Guest Provisioning Page
Printing Guest Account Information
To print guest account information:
1. Highlight the guest account you want to print and click Print . The Print info for guest window displays.
2. Click Print password if you want to print the guest password on the badge. Then enter or generate a new password for the guest. This modifies the existing guest password. (See
.)
3. Optionally, click Print policy text if you want your company policy text to appear on the print out.
4. Click Show preview to view the information before it is printed.
5. Click Print to print the guest account information.
ArubaOS 6.5.3.x
| User Guide Management Access | 892
Figure 204 Printing Guest Account Information
Optional Configurations
This section describes guest provisioning options that the administrator can configure.
These options are not configurable by the guest provisioning user.
Restricting one Captive Portal Session for each Guest
You can restrict one captive portal session for each guest. When a new captive portal request is received and passes authentication, all users are checked and compared with user names. If a user with the same name already exists and this option is enabled, the second login is denied.
If a guest logs in from one system (and does not log out) and tries to log in again from another system, that guest has to wait for the initial session to expire.
1. Navigate to the Configuration > Advanced Services> All Profiles page.
2. Select Wireless LAN .
3. Under Wireless LAN , select and open Captive Portal Authentication .
4. Add a new or select and existing
5. Select the Allow only one active user session check box.
6. Click Apply .
Using the CLI to restrict one Captive Portal session for each guest
(host)(config)# aaa authentication captive-portal <> single-session
Setting the Maximum Time for Guest Accounts
You can set the maximum expiration time (in minutes) for guest accounts. If the guest-provisioning user attempt to add a guest account that expires beyond this time period, an error message is displayed and the
893 | Management Access ArubaOS 6.5.3.x | User Guide
guest account is created with the maximum time you configured.
If you set the maximum expiration time, it applies to all users in the internal database whether they are guests or not.
Using the WebUI to set the maximum time for guest accounts
1. Navigate to the Configuration > Security > Authentication page.
2. Select Internal DB .
3. Under Internal DB Maintenance, enter a value in Maximum Expiration .
4. Click Apply .
Using the CLI to set the maximum time for guest accounts
(host)# local-userdb maximum-expiration <minutes> n n
Managing Files on the Controller
You can transfer the following types of files between the controller and an external server or host:
ArubaOS image file
A specified file in the controller’s flash file system, or a compressed archive file that contains the entire content of the flash file system.
You back up the entire content of the flash file system to a compressed archive file, which you can then copy from the flash system to another destination.
n n
Configuration file, either the active running configuration or a startup configuration.
Log files.
You can use the following protocols to copy files to or from a controller: n n n
File Transfer Protocol (FTP): Standard TCP/IP protocol for exchanging files between computers.
Trivial File Transfer Protocol (TFTP): Software protocol that does not require user authentication and is simpler to implement and use than FTP.
Secure Copy (SCP): Protocol for secure transfer of files between computers that relies on the underlying
Secure Shell (SSH) protocol to provide authentication and security.
You can use SCP only for transferring image files to or from the controller, or transferring files between the flash file system on the controller and a remote host. The SCP server or remote host must support SSH version 2 protocol.
The following table lists the parameters that you configure to copy files to or from a controller.
ArubaOS 6.5.3.x
| User Guide Management Access | 894
Table 210: File Transfer Configuration Parameters
Server Type Configuration
Trivial File Transfer Protocol (TFTP)
File Transfer Protocol (FTP) n n n n n n tftphost - tftp host IPv4 / IPv6 address filename - absolute path of filename flash: - copy to the flash file system destination: - destination file name system: - system partition partition - partition 0 / partition 1 n n n n n n ftphost - ftp server host name or IPv4/IPv6 address username - user name to log into server filename - absolute path of filename flash: - copy to the flash file system system: - system partition partition - partition 0 / partition 1
Secure Copy (SCP)
You must use the CLI to transfer files with
SCP.
n n n n n n n scphost - scp host of IPv4 / IPv6 address username - user name to secur to log into the server filename - absolute path of filename (otherwise, SCP searches for the file relative to the user’s home directory) flash: - copy to the flash file system destfilename: - destination file name system: - system partition partition - partition 0 / partition 1
For example, you can copy an ArubaOS image file from an SCP server to a system partition on a controller or copy the startup configuration on a controller to a file on a TFTP server, You can also store the contents of a controller’s flash file system to an archive file which you can then copy to an FTP server. You can use SCP to securely download system image files from a remote host to the controller or securely transfer a configuration file from flash to a remote host.
Transferring ArubaOS Image Files
You can download an ArubaOS image file onto a controller from a TFTP, FTP, or SCP server. In addition, the
WebUI allows you to upload an ArubaOS image file from the local PC on which you are running the browser.
When you transfer an ArubaOS image file to a controller, you must specify the system partition to which the file is copied. The WebUI shows the current content of the system partitions on the controller. You have the option of rebooting the controller with the transferred image file.
In the WebUI
1. Navigate to the Maintenance > Controller > Image Management page.
2. Select TFTP, FTP, SCP, or Upload Local File.
3. Enter or select the appropriate values for the file transfer method.
4. Select the system partition to which the image file is copied.
5. Specify whether the controller is to be rebooted after the image file is transferred, and whether the current configuration is saved before the controller is rebooted.
6. Click Upgrade .
In the CLI copy tftp: <tftphost> <filename> {flash: <destfilename> | system: partition [0|1]} copy ftp: <ftphost> <user> <filename> {flash: <destfilename> | system: partition [0|1]} copy scp: <scphost> <username> <filename> {flash: <destfilename> | system: partition [0|1]}
895 | Management Access ArubaOS 6.5.3.x | User Guide
Backing Up and Restoring the Flash File System
You can store the entire content of the flash file system on a controller to a compressed archive file. You can then copy the archive file to an external server for backup purposes. If necessary, you can restore the backup file from the server to the flash file system.
Backup the Flash File System in the WebUI
1. Navigate to the Maintenance > File > Backup Flash page.
2. Click Create Backup to back up the contents of the flash system to the flashbackup.tar.gz
file.
3. Click Copy Backup to enter the Copy Files page where you can select the destination server for the file.
4. Click Apply .
Backup the Flash File System in the CLI backup flash copy flash: flashbackup.tar.gz tftp: <tftphost> <destfilename> copy flash: flashbackup.tar.gz scp: <scphost> <username> <destfilename>
Restore the Flash File System in the WebUI
1. Navigate to the Maintenance > File > Copy Files page.
a. For Source Selection, specify the server to which the flashbackup.tar.gz
file was previously copied.
b. For Destination Selection, select Flash File System.
c. Click Apply .
2. Navigate to the Maintenance > File > Restore Flash page.
3. Click Restore to restore the flashbackup.tar.gz
file to the flash file system.
4. Navigate to the Maintenance > Switch > Reboot Switch page.
5. Click Continue to reboot the controller.
Restore the Flash File System in the CLI copy tftp: <tftphost> <srcfilename> flash: flashbackup.tar.gz
copy scp: <scphost> <username> <srcfilename> flash: flashbackup.tar.gz
restore flash
Copying Log Files
You can store log files into a compressed archive file which you can then copy to an external TFTP or SCP server. The WebUI allows you to copy the log files to a WinZip folder which you can display or save on your local PC.
In the WebUI
1. Navigate to the Maintenance > File > Copy Logs page.
2. For Destination, specify the TFTP or FTP server to which log files are copied.
3. Select Download Logs to download the log files into a WinZip file on your local PC,
4. Click Apply .
In the CLI tar logs copy flash: logs.tar tftp: <tftphost> <destfilename> copy flash: logs.tar scp: <scphost> <username> <destfilename>
ArubaOS 6.5.3.x
| User Guide Management Access | 896
Copying Other Files
The flash file system contains the following configuration files: n n startup-config: Contains the configuration options that are used the next time the controller is rebooted. It contains all options saved by clicking the Save Configuration button in the WebUI or by entering the write memory CLI command. You can copy this file to a different file in the flash file system or to a TFTP server.
running-config: Contains the current configuration, including changes which have yet to be saved. You can copy this file to a different file in the flash file system, to the startup-config file, or to a TFTP or FTP server.
You can copy a file in the flash file system or a configuration file between the controller and an external server.
In the WebUI
1. Navigate to the Maintenance > File > Copy Files page.
2. Select the source where the file or image exists.
3. Select the destination to where the file or image is to be copied.
4. Click Apply .
In the CLI copy startup-config flash: <filename> copy startup-config tftp: <tftphost> <filename> copy running-config flash: <filename> copy running-config ftp: <ftphost> <user> <filename> [<remote-dir>] copy running-config startup-config copy running-config tftp: <tftphost> <filename>
Setting the System Clock
You can set the clock on a controller manually or by configuring the controller to use a Network Time Protocol
(NTP) server to synchronize its system clock with a central time source.
Manually Setting the Clock
You can use either the WebUI or CLI to manually set the time on the controller’s clock.
In the WebUI
1. Navigate to the Configuration > Management > Clock page.
2. Under Controller Date/Time , set the date and time for the clock.
3. Under Time Zone , enter the name of the time zone and the offset from Greenwich Mean Time (GMT).
4. To adjust the clock for daylight savings time, click Enabled under Summer Time. Additional fields appear that allow you to set the offset from UTC, and the start and end recurrences.
5. Click Apply .
In the CLI
To set the date and time, enter the following command in privileged mode: clock set <year> <month> <date> <hour> <minutes> <seconds>
To set the time zone and daylight savings time adjustment, enter the following commands in configure mode: clock timezone < WORD > <-23 - 23> clock summer-time < zone > [recurring]
< 1-4 > < start day > < start month > < hh:mm >
first < start day > < start month > < hh:mm >
last < start day > < start month > < hh:mm >
< 1-4 > < end day > < end month > < hh:mm >
897 | Management Access ArubaOS 6.5.3.x | User Guide
first < end day > < end month > < hh:mm >
last < end day > < end month > < hh:mm >
[<-23 - 23>]
Clock Synchronization
You can use NTP to synchronize the controller to a central time source. Configure the controller to set its system clock using NTP by configuring one or more NTP servers.
For each NTP server, you can optionally specify the NTP iburst mode for faster clock synchronization. The iburst mode sends up ten queries within the first minute to the NTP server. (When iburst mode is not enabled, only one query is sent within the first minute to the NTP server.) After the first minute, the iburst mode typically synchronizes the clock so that queries need to be sent at intervals of 64 seconds or more.
The iburst mode is a configurable option and not the default behavior for the controller, as this option is considered
“aggressive” by some public NTP servers. If an NTP server is unresponsive, the iburst mode continues to send frequent queries until the server responds and time synchronization starts.
In the WebUI
1. Navigate to the Configuration > Management > Clock page.
2. Under NTP Servers, click Add .
3. Enter the IP address of the NTP server.
4. Select (check) the iburst mode, if desired.
5. Click Add .
In the CLI ntp server ipaddr [iburst]
Configuring NTP Authentication
The Network Time Protocol adds security to an NTP client by authenticating the server before synchronizing the local clock. NTP authentication works by using a symmetric key which is configured by the user. The secret key is shared by both the controller and an external NTP server. This helps identify secure servers from fraudulent servers.
In the WebUI
1. Navigate to the Configuration > Management > Clock page.
2. Under NTP Authentication , make sure Enable is selected. Enable is the default option.
3. Under NTP Servers , enter the NTP server IP address (IPv4/IPv6) in the Server IP field.
4. Under NTP Identification Keys , enter an identification key (a number between 1 and 65535) in the
Identification Key field. Then add a secret string in the MD5 Secret field. The MD5 ID key must be an
ASCII string up to 31 characters.
5. Click Add .
6. The identification key along with its corresponding MD5 secret string is displayed in the Identification
Keys section.
7. Under NTP Trusted Keys , enter a string in the Trusted Key field. This is a subset of keys which are trusted. The trusted key value must be numeric values between 1 to 65535.
8. Click Apply .
ArubaOS 6.5.3.x
| User Guide Management Access | 898
In the CLI
This example enables NTP authentication, add authentication secret keys into the database, and specifies a subset of keys which are trusted. It also enables the iburst option.
(host) (config) #ntp authenticate
(host) (config) #ntp authentication-key <key-id> md5 <key-secret>
(host) (config) #ntp trusted-key <key-id>
(host) (config) #ntp server <ipaddr> <iburst> <key>
(host) (config) #ntp server < server IP > < iburst key > < key >
Configuring NTP Standalone
NTP standalone feature enables an Aruba controller to act as an NTP server so that the devices that do not have access to internet can synchronize their clocks. Enabling this feature eliminates the need to provision and maintain another virtual machine on the network.
In the CLI
To enable the NTP standalone feature, execute the following commands:
(host) (config) #ntp standalone
(host) (config) #ntp standalone vlan-range
Timestamps in CLI Output
The timestamp feature can include a timestamp in the output of each show command issued in the commandline interface, indicating the date and time the command was issued. Note that the output of show clock and show log do not include timestamps, even when this feature is enabled.
To enable this feature, access the command-line interface in config mode and issue the command clock append .
(host) (config) #clock append
ClearPass Profiling with IF-MAP
This feature is used in conjunction with ClearPass Policy Manager. It sends HTTP User Agent Strings and mDNS broadcast information to ClearPass so that it can make more accurate decisions about what types of devices are connecting to the network.
In the WebUI
To enable and configure this feature:
1. Navigate to Configuration >All Profiles>Other Profiles .
2. Click the CPPM IF-MAP profile.
3. Configure this profile according to the following parameters:
899 | Management Access ArubaOS 6.5.3.x | User Guide
Table 211: CPPM IF-Map Configuration Parameters
Parameter Description
CPPM IF-Map Interface
Host IP address
Username
Password
Enables the feature
IP address or hostname of the CPPM IF-MAP server
Username for the user who performs actions on the CPPM IF-MAP server. Range must be between 1-255 bytes in length.
Password of the user who performs actions on the CPPM IF-MAP server. Range between 6-100 bytes in length.
In the CLI
To configure this feature using the CLI:
(host) (config) #ifmap
(host) (config) #ifmap cppm
(host) (CPPM IF-MAP Profile) #server host <host>
(host) (CPPM IF-MAP Profile) #port <port>
(host) (CPPM IF-MAP Profile) #passwd <psswd>
(host) (CPPM IF-MAP Profile) #enable
This show ifmap cppm command shows if the CCPM interface is enable and the CPPM server IP address, username and password.
(host) (CPPM IF-MAP Profile) #show ifmap cppm
CPPM IF-MAP Profile
-------------------
Parameter
---------
Value
-----
CPPM IF-MAP Interface Enabled
CPPM IF-MAP Server 10.4.191.32:443 admin/********
This show command shows if state of all enabled CPPM servers.
(host) (CPPM IF-MAP Profile) #show ifmap state cppm
CPPM IF-MAP Connection State [Interface: Enabled]
-------------------------------------------------
Server State
----------
10.4.191.32:443 UP
Whitelist Synchronization
ArubaOS allows controllers to synchronize their remote AP whitelists with the Aruba Activate cloud-based services. When you configure Activate whitelist synchronization, the controller will securely contact the Activate server and download the contents of the whitelist on the Activate server to the whitelist on the controller. The controller and the Activate server must have layer-3 connectivity to communicate.
By default, this feature will both add new remote AP entries to the controller whitelist and delete any obsolete entries on the controller whitelist that were not on the Activate server whitelist. Select the add-only option to allow this feature to add or modify entries, but not delete any existing entries.
In the WebUI
To enable this feature using the WebUI,
1. Navigate to Configuration > Network > Controller > Sync Whitelist Service .
ArubaOS 6.5.3.x
| User Guide Management Access | 900
2. Select Enable sync service .
3. In the Activate user field, enter the user name for your Activate account.
4. In the Activate password field, enter the password for your Activate account.
5. (Optional) Click the Frequency drop-down list and configure how frequently the controller should synchronize its remote AP whitelist with the whitelist on the Activate server.
6. Click Apply to save your settings.
In the CLI
The following example enables the Activate whitelist service on the controller. The add-only parameter allows only the addition of entries to the Activate remote AP whitelist database. This parameter is enabled by default.
If this setting is disabled, the activate-whitelist-download command can both add and remove entries from the
Activate database.
(host)(config)# activate-service-whitelist
(host)(activate-service-whitelist) #username user2 password pA$$w0rd whitelist-enable
(host)(activate-service-whitelist)add-only
The following command is available in enable mode, and prompts the controller to synchronize its remote AP whitelist with the associated whitelist on the Activate server:
(host)# activate whitelist download
Downloadable Regulatory Table
The downloadable regulatory table feature allows for the update of country domain options without upgrading the ArubaOS software version. A separate file, called the Regulatory-Cert, containing AP regulatory information will be released periodically on the customer support site. The Regulatory-Cert file can then be uploaded to a controller and pushed to deployed APs.
The Regulatory-Cert includes the following information for each AP: n n n n
All countries supported in the current release of ArubaOS (not just United States or Rest of World or any subset of countries)
Allowed channels for each country
Max EIRP for each channel and each country in the allowed list. The max values are specified for each PHYtype at which the AP is allowed to transmit on. The classified PHY-types are l
802.11 OFDM rates (802.11a/g mode) l l
802.11b rates (CCK rates)
802.11n HT20 and 802.11ac VHT20 rates (MCS0-7) l l
802.11n HT20 and 802.11ac VHT40(MCS0-7)
802.11ac VHT80 rates
DFS functionality for each channel and each country in the allowed list
Important Points to Remember
n
When a Regulatory-Cert is activated, the new file is checked against the default file built into ArubaOS. If the file is of a newer version, the activation is allowed. If the file is of a lower version, then the activation is not completed. The controller's CLI displays the following message upon failure:
(host0) #ap regulatory activate reg-data-1.0_00002.txt
Failed to activate regulatory file reg-data-1.0_00002.txt. File Version should be greater than 1.0_43859
n
APs do not rebootstrap or reboot on activation.
901 | Management Access ArubaOS 6.5.3.x | User Guide
n n n n
If there is change in channel list or power level, APs will change the channel/power level. Impact is same as that of ARM channel/power change in that case.
Clients are not disconnected upon regulatory file activation. Max latency impact during activation (with no channel changes) is less than 1s (applies to power change too).
With channel change, the impact is similar to ARM channel change (depends on client behavior and if CSA is enabled or not).
If support for the AP (Country) is added, the AP will move from AM to AP mode (if the AP is configured in AP mode of operation).
Copying the Regulatory-Cert
You can use the following protocols to copy the regulatory file to a controller: n n n
FTP
TFTP
SCP
Additionally, regulatory files saved to a USB drive can be uploaded to a controller equipped with a USB port.
You can copy the Regulatory-Cert to the controller using the WebUI or CLI.
In the WebUI
1. Navigate to the Maintenance > File > Copy Files page.
2. Select the source (TFTP, FTP, SCP, or USB) where the file exists.
3. The controller WebUI will automatically select Flash File System under the Destination Selection menu.
4. Click Apply .
In the CLI
Use one of the following copy commands to download the regulatory file to the controller: copy ftp: <ftphost> <user> <filename> {flash: <destfilename> | system: partition [0|1]} scp: <scphost> <username> <filename> flash: <destfilename> tftp: <tftphost> <filename> flash: <destfilename> usb: partition <partition-number> <filename> flash: <destfilename>
To view the current regulatory and the content of the file, use the following commands: show ap regulatory show ap allowed-channels country-code <country-code> ap-type <ap-type show ap allowed-max-eirp ap-name <ap-name> country-code <country-code> show ap debug received-reg-table ap-name <ap-name>
Activating the Regulatory-Cert
Once the Regulatory-Cert has been added to the controller, the new regulatory information must be activated and pushed to the APs.
In the WebUI
To activate a specific regulatory file using the WebUI:
1. Navigate to Maintenance > File > Regulatory Files .
2. Select a regulatory file from the File List .
3. Click Activate .
ArubaOS 6.5.3.x
| User Guide Management Access | 902
In the CLI
To activate a specific regulatory file loaded on the controller, use the following command: ap regulatory activate <filename>
To return to the factory default regulatory-cert, use the following command: ap regulatory reset
In a master-local-standby deployment, the file syncing profile can be enabled to ensure that the regulatory-cert that is stored on the master is shared with its subordinate controllers. File syncing is enabled by default, with a default sync time of 30 minutes. The sync time can be set between 30 to 180 minutes, To configure the file syncing profile, use the following commands
(host) (config) #file syncing profile
(host) (File syncing profile) #file-syncing-enable
(host) (File syncing profile) #sync-time 30
Related Show Commands
To view the version of Regulatory Cert currently active on all controllers, execute the following command:
(host) #show switches regulatory
To view the file synching profile settings, execute the following command:
(host) #show file syncing profile
903 | Management Access ArubaOS 6.5.3.x | User Guide
Chapter 38
802.11u Hotspots
Hotspot 2.0 R2 is a Wi-Fi Alliance Passpoint specification based upon the 802.11u protocol that provides wireless clients with a streamlined mechanism to discover and authenticate to suitable networks, and allows mobile users the ability to roam between partner networks without additional authentication.
ArubaOS incorporates Passpoint technology from the Wi-Fi Alliance Hotspot 2.0 R2 Specification to simplify and automate access to public Wi-Fi networks. Follow the procedures in this chapter to help mobile devices identify which access points in your hotspot network are suitable for their needs, and authenticate to a remote service provider using suitable credentials.
For an overview of Hotspot enhanced network discovery and selection technology, and a description of each of the hotspot profile types, see
Hotspot 2.0 Overview on page 904
n n n n n n n n n n n n n n
Hotspot Profile Configuration Tasks
The following sections describe the procedure to configure the profiles for the hotspot feature.
Configuring Hotspot 2.0 Profiles on page 907
Configuring Hotspot Advertisement Profiles on page 911
Configuring ANQP Venue Name Profiles on page 913
Configuring ANQP Network Authentication Profiles on page 915
Configuring ANQP Domain Name Profiles on page 916
Configuring ANQP IP Address Availability Profiles on page 917
Configuring ANQP NAI Realm Profiles on page 918
Configuring ANQP Roaming Consortium Profiles on page 921
Configuring ANQP 3GPP Cellular Network Profiles on page 921
Configuring H2QP Connection Capability Profiles on page 922
Configuring H2QP Operator Friendly Name Profiles on page 924
Configuring H2QP Operating Class Indication Profiles on page 925
Configuring H2QP WAN Metrics Profiles on page 926
Configuring H2QP OSU Provider List Profiles on page 927
Hotspot 2.0 Overview
ArubaOS supports Hotspot 2.0 with enhanced network discovery and selection. Clients can receive general information about the network identity, venue and type via management frames from the Aruba AP. Clients can also query APs for information about the network’s available IP address type (IPv4 or IPv6), roaming partners, and supported authentication methods, and receive that information in Information Elements from the AP.
ArubaOS Hotspot Support for GAS Queries
An Organization Identifier (OI) is a unique identifier assigned to a service provider when it registers with the
IEEE registration authority. An Aruba AP can include its service provider OI in beacons and probe responses to
ArubaOS 6.5.3.x
| User Guide 802.11u Hotspots | 904
clients. If a client recognizes an AP’s OI, it will attempt to associate to that AP using the security credentials corresponding to that service provider.
If the client does not recognize the AP’s OI, that client can send a Generic Advertisement Service (GAS) query to the AP to request more information more about the network before associating.
GAS is a generic protocol that includes multiple sub-protocols. The ArubaOS hotspot feature supports only ANQP information elements.
ANQP Information Elements
ANQP Information Elements (IEs) are additional data that can be sent from the AP to the client to identify the
AP’s network and service provider. If a client requests this information via a GAS query, the hotspot AP then sends the ANQP Capability list in the GAS Initial Response frame indicating support for the following IEs. If the client responds with a request for a specific IE, the AP will send a GAS response frame with the configured
ANQP IE information.
n n n n n n n n n n n n n
Venue Name: the Venue Name IE defines the venue group and venue type.
Domain Name: this IE specifies the AP’s domain name.
Network Authentication Type: if the network has Additional Steps required for Access (ASRA), this profile defines the authentication type being used by the hotspot network.
Roaming Consortium List: roaming Consortium Information Elements (IEs) contain information identifying the network and service provider, whose security credentials can then be used to authenticate with the AP transmitting this element.
IP address Availability: this IE provides clients with information about the availability of IP address versions and types which could be allocated to those clients after they associate to the hotspot AP.
NAI Realm: an AP’s NAI Realm profile identifies and describes a NAI realm accessible using the AP, and the method that this NAI realm uses for authentication.
3GPP Cellular Network Data: defines information for a 3rd Generation Partnership Project (3GPP) Cellular
Network for hotspots that have roaming relationships with cellular operators.
Connection Capability: define hotspot protocol and port capabilities to be sent in an ANQP IE.
Operating Class: use this profile to define the channels on which the hotspot is capable of operating.
Operator Friendly Name: a free-form text field that can identify the operator and also something about the location.
WAN Metrics: provides hotspot clients information about access network characteristics such as link status and the capacity and speed of the WAN link to the Internet.
OSU provider list: This profile defines a list of Online Sign Up (OSU) service providers available from the hotspot. When you configure an OSU provider list, if a customer device cannot find a service from a known operator, the device receives a notification from the hotspot that additional Online Sign Up services are available.
Icon Request element: If this special element is queried, it can return an icon response element. For more information on uploading an icon file, see
Uploading an Icon file on page 929
Hotspot Profile Types
ArubaOS supports several different ANQP and H2QP profile types for defining Hotspot data. The following table describes the profiles in the Hotspot profile set.
905 | 802.11u Hotspots ArubaOS 6.5.3.x | User Guide
Table 212: ANQP and H2QP Profiles referenced by an Advertisement Profile
Profile Description
Hotspot Advertisement profile
ANQP 3GPP Cellular Network profile
ANQP Domain Name profile
ANQP IP Address Availability profile
ANQP NAI Realm profile
ANQP Network Authentication profile
ANQP Roaming Consortium profile
ANQP Venue Name profile
H2QP Connection Capability profile
H2QP Operating Class
Indication profile
An advertisement profile defines a collection of ANQP and H2QP profiles. Each hotspot 2.0 profile is associated with one advertisement profile, which in turn references one of each type of
ANQP and H2QP profile.
For more information on configuring this profile, refer to
Configuring Hotspot Advertisement Profiles on page 911
Use this profile to define priority information for a 3rd Generation
Partnership Project (3GPP) Cellular Network used by hotspots that have roaming relationships with cellular operators.
For more information on configuring this profile, refer to
Configuring ANQP 3GPP Cellular Network Profiles on page 921
Use this profile to specify the hotspot operator domain name.
For more information on configuring this profile, refer to
Configuring Hotspot Advertisement Profiles on page 911
Use this profile to specify the types of IPv4 and IPv6 IP addresses available in the hotspot network.
For more information on configuring this profile, refer to
Configuring ANQP IP Address Availability Profiles on page 917
An AP’s NAI Realm profile identifies and describes a Network
Access Identifier (NAI) realm accessible using the AP, and the method that this NAI realm uses for authentication.
For more information on configuring this profile, refer to
Configuring ANQP NAI Realm Profiles on page 918
Use the ANQP Network Authentication profile to define the authentication type used by the hotspot network.
For more information on configuring this profile, refer to
Configuring ANQP Network Authentication Profiles on page 915 .
Name of the ANQP Roaming Consortium profile to be associated with this WLAN advertisement profile.
For more information on configuring this profile, refer to
Configuring ANQP Roaming Consortium Profiles on page 921
Use this profile to specify the venue group and venue type information be sent in an Access network Query Protocol (ANQP) information element in a Generic Advertisement Service (GAS) query response.
For more information on configuring this profile, refer to
Configuring ANQP Venue Name Profiles on page 913
.
Use this profile to specify hotspot protocol and port capabilities.
For more information on configuring this profile, refer to
Configuring H2QP Connection Capability Profiles on page 922
Use this profile to specify the channels on which the hotspot is capable of operating
For more information on configuring this profile, refer to
Configuring H2QP Operating Class Indication Profiles on page 925
ArubaOS 6.5.3.x
| User Guide 802.11u Hotspots | 906
Profile Description
H2QP Operator Friendly Name profile
H2QP WAN Metrics profile
Use this profile to define the operator-friendly name sent by devices using this profile.
For more information on configuring this profile, refer to
Configuring H2QP Operator Friendly Name Profiles on page 924
Use this profile to specify the WAN status and link metrics for your hotspot.
For more information on configuring this profile, refer to
Configuring H2QP WAN Metrics Profiles on page 926
H2QP OSU Provider List profile This profile defines a list of OSU service providers available from the hotspot.
For more information on configuring this profile, refer to
Configuring H2QP OSU Provider List Profiles on page 927
AP Prerequisites for Hotspot Support
lists configuration requirements for virtual APs using ArubaOS hotspot features:
Table 213: AP Requirements
Hotspot 1.0
Hotspot 2.0
n WPA AES
Enterprise
(Not a preshared key [PSK]) n n n n
WPA AES Enterprise (Not a pre-shared key [PSK])
Protected management frames
A Virtual-AP forwarding mode that supports protected managed frames.
(For example, tunnel forwarding mode does not support protected management frames)
An external authentication server or Clearpass server that supports
Hotspot 2.0
OSEN n n
WPA AES
Enterprise
(Not a preshared key
[PSK])
An external authentication server or
Clearpass server that supports
Hotspot 2.0
Configuring Hotspot 2.0 Profiles
Use this profile to enable support for Hotspot 2.0 R2 and define venue and OI settings for roaming partners.
Each hotspot 2.0 profile also references an advertisement profile, which defines a set of ANQP or H2QP profiles that define other values for the hotspot feature. By default, Hotspot 2.0 profiles reference the default advertisement profile.
For information on associating a different advertisement profile with a Hotspot 2.0 profile, see
H2QP OSU Provider List Profiles on page 927
.
In the WebUI
To configure a Hotspot 2.0 profile from the controller WebUI:
1. Navigate to Configuration > Advanced Services > All Profiles .
2. In the Profiles list, expand the Wireless LAN section.
3. Select Hotspot 2.0
.
4. Select an existing profile from the Profile Details pane or create a new profile by entering a profile name into the entry blank, and then clicking Add .
5. Configure the parameters described in
as desired, and then click Apply.
907 | 802.11u Hotspots ArubaOS 6.5.3.x | User Guide
Table 214: Hotspot 2.0 Profile Settings
Parameter Description
Advertise Hotspot 2.0
Capability
Enable Hotspot 2.0 OSEN
OSU NAI
Use GAS Comeback
Request/Response
Additional Steps required for Access Enabled
Network Internet Access
GAS Query Response
Length Limit
This check box enables or disables the hotspot. When this feature is enabled, the Information Elements (IEs) for this hotspot are included in beacons and probe responses from the AP.
This setting is disabled by default.
Select this option to indicate that the hotspot uses a OSU Server-only authenticated layer 2 Encryption Network (OSEN) network type. This network can provision clients using the OSU functionality. If this option is enabled, you must also configure a hotspot OSU provider list profile. See
Configuring H2QP OSU Provider List Profiles .
NOTE: Although the hotspot 2.0 specification defines the OSEN authentication method, A virtual AP configured to use OSEN can not be used as a hotspot 2.0 AP. OSEN and hotspot 2.0 networks are related in their usage, but cannot be used simultaneously by an AP.
A Network Access Identifier (NAI) realm for a Online Sign Up (OSU) service provider available from the hotspot. This parameter is used to configure an
OSU provider or an OSEN network type. Before you can use this OSU NAI, you must also configure a hotspot OSU provider list profile. See
Configuring H2QP OSU Provider List Profiles .
By default, ANQP Information is obtained from a GAS Request and
Response. If you enable the Use GAS Comeback Request/Response option, advertisement information is obtained using a GAS Request and Response.
as well as a Comeback-Request and Comeback-Response. This option is disabled by default.
Select this check box if any additional steps are required for network access. If this parameter is enabled, the AP will send the following
Information Elements (IEs) in response to the client’s the ANQP query.
n n
Venue Name
Domain Name List n n
Network Authentication Type
Roaming Consortium List n NAI Realm List
NOTE: If this parameter is enabled, the advertisement profile for this hotspot must reference an enabled network authentication type profile.
If you select this check box, the AP sends an Information Element (IE) indicating that the network allows internet access. By default, a hotspot profile does not advertise network internet access.
Generic Advertisement Service (GAS) enables advertisement services that lets clients query multiple 802.11 networks at once, while also allowing the client to learn more about a network’s 802.11 infrastructure before associating.
If a client transmits a GAS Query using a GAS Initial Request frame, the responding AP will provide the query response (or information on how to receive the query response) in a GAS Initial Response frame.
This parameter sets the maximum length of the GAS query response, in octets. The supported range is 1-255 octets.
ArubaOS 6.5.3.x
| User Guide 802.11u Hotspots | 908
Parameter
Access Network Type
Roaming Consortium OI
Entry 1
Roaming Consortium OI
Entry 2
Roaming Consortium OI
Entry 3
HESSID
Venue Group Type
Venue Type
PAME BI
Description
Specify the 802.11u network type. The default setting is public-chargeable.
n emergency-services : emergency services only network n n personal-device : personal device network private : private network n n n n n private-guest : private network with guest access public-chargeable : public chargeable network public-free : free public network test : test network wildcard : wildcard network
Roaming consortium OI assigned to one of the service provider’s top three roaming partners. This additional OI will only be sent to a client if the
Additional Roaming Consortium OI's parameter is set to1 or higher.
Roaming consortium OI assigned to one of the service provider’s top three roaming partners. This additional OI will only be sent to a client if the
Additional Roaming Consortium OI's parameter is set to 2 or higher.
Roaming consortium OI assigned to one of the service provider’s top three roaming partners. This additional OI will only be sent to a client if the
Additional Roaming Consortium OI's parameter is set to 3.
This optional parameter devices an AP’s homogenous ESS identifier
(HESSSID), which is that device’s MAC address in colon-separated hexadecimal format.
Specify one of the following venue groups to be advertised in the IEs from
APs associated with this hotspot profile. The default setting is unspecified.
n assembly n n n n business educational factory-or-industrial institutional n n n n n n mercantile outdoor reserved residential storage unspecified n n
Utility-Misc
Vehicular
NOTE: This parameter only defines the venue group advertised in the IEs from hotspot APs.
Specify a venue type to be advertised in the IEs from APs associated with this hotspot profile. The complete list of supported venue types is described in
.
This parameter only defines the venue type advertised in the IEs from hotspot APs.
This option enables the Pre-Association Message Exchange BSSID
Independent (PAME-BI) bit, which is used by an AP to indicate whether the
AP indicates that the Advertisement Server can return a query response that is independent of the BSSID used for the GAS Frame exchange.
909 | 802.11u Hotspots ArubaOS 6.5.3.x | User Guide
Parameter
Downstream Group
Frames Forwarding
Blocked
Time Zone Format
Time Advertisement
Capability
Time Error Value
P2P Device Management
P2P Cross Connect
GAS comeback delay in milliseconds
RADIUS Chargeable User
Identity(RFC4372)
RADIUS Location Data
(RFC5580)
Subscription Remediation
Server URL
Deauth Imminent Reason
URL
Description
This option configures the Downstream Group Addressed Forwarding
(DGAF) Disabled Mode. If this feature is enabled, it ensures that the AP does not forward downstream group-addressed frames. It is disabled by default, allowing the AP to forward downstream group-addressed frames.
The time zone in which the AP is operating, in the format
<std><offset>[dst[offset],[start[/time],end[/time]]
Where the <std> string specifies the abbreviation of the time zone, <dst> is the abbreviation of the timezone in daylight savings time, and the <offset> string specifies the time value you must add to the local time to arrive at
UTC.
NOTE: For complete details on configuring the timezone format, refer to section 8.3 of IEEE Std 1003.1, 2004 Edition.
This parameter specifies the AP’s source of external time and the current condition of its timing estimator.
n n no-std-ext-time-src : The AP using this profile has no standardized external time source.
timestamp-offset-utc : The AP has a timestamp offset based on UTC.
n reserved : This setting is reserved for future use, and should not be used.
The standard deviation of error in the time value estimate, in milliseconds.
The default value is 0 milliseconds, and the supported range is 0-
2,147,483,647 milliseconds.
Issue this command to advertise support for P2P device management. This setting is disabled by default.
Issue this command to advertise support for P2P Cross Connections. This setting is disabled by default.
At the end of the GAS comeback delay interval, the client may attempt to retrieve the query response using a Comeback Request Action frame. The supported range is 100-2000 milliseconds, and the default value is 500 milliseconds.
Include this parameter to enable the Chargeable-User-Identity RADIUS attribute defined by RFC 4372. Home networks can use this attribute to identify a user for the roaming transactions that take place outside of that home network.
Include this parameter to enable the Location Data RADIUS attribute defined by RFC 5580. Enabling this parameter allows the RADIUS server to use user location data and adds the operator-name RADIUS attributes, which are defined by the first ANQP NAI Realm profile.
Subscription remediation is a process used by service providers to help clients resolve subscription errors and issues. If a mobile device is unable to authenticate to the network using existing credentials, the device can receive the URL of a server that describes other available subscription options. This URL must be in the format http://www.example.com.
If a mobile device's credentials are about to expire or the device has become unauthorized, it can receive the URL of a server that explains how to correct any errors. This URL must be in the format http://www.example.com.
ArubaOS 6.5.3.x
| User Guide 802.11u Hotspots | 910
Parameter
Re-auth delay
Session Information URL
802.11u QoS Map DSCP
Exceptions
802.11u QoS Map DSCP
Ranges
Description
Define the delay time (in seconds) that a mobile device waits before attempting re-association to the same BSS or ESS. The supported range is
0- 65535. A value of 0 indicates that the re-auth delay may be decided by the mobile device.
Configure this attribute to allow the AP to send a BSS Transition
Management Request frame before the mobile device’s session is terminated, warning the user that their session is about to end. The URL provides the location of a server with information on how to extend the session. This URL must be in the format http://www.example.com.
If you use the 802.11u QoS Map DSCP Ranges parameter to map DSCP ranges for each 802.11 User Priority (UP), you can configure this optional parameter to define up to 21 exceptions to those DSCP ranges.
DSCP values 0-63 and 255 must be defined in hexadecimal format (0-3F or
FF), and the UP level in a value from 0-7. Multiple exceptions must be separated by a comma. For example: wlan hotspot hs2-profile <profilename> dscp-ranges 35:2,16:6
NOTE: You can configure 802.11u QoS Map DHCP Exceptions even if you are using the default 802.11u QoS Map DSCP Ranges.
Hotspot 2.0 can ensure the connection quality for a mobile client that roams from a cellular to a Wi-Fi connection by mapping a service provider's over-the-air QoS policies to the WLAN's DHCP markers. This parameter defines eight ranges of DSCP values that map to 802.11 User
Priority (UP) levels 0-7.
Each value range includes a low and high DHCP value for that UP level.
Each of the eight ranges, corresponding to UP levels 0-7, must be separated by a comma. DHCP values 0-63 and 255 must be defined in hexadecimal format (0-3F or FF), and values for each range must not overlap.
The following example defines a range of DSCP values for each of the seven UP levels: wlan hotspot hs2-profile <profile-name> dscp-ranges
08-0F,00-07,FF-FF,10-1F,20-27,FF-FF,28-2F,30-3F
NOTE: If the 802.11u QoS Map DSCP Ranges are not configured, the hotspot feature uses a value of FF-FF,FF-FF,FF-FF,FF-FF,FF-FF,FF-FF,FF-FF,FF-
FF for the 802.11u DSCP ranges.
In the CLI
To configure a Hotspot 2.0 profile from the controller CLI, access the CLI in config mode and issue the following command:
(host) (config) #wlan hotspot hs2-profile <profile-name>
Configuring Hotspot Advertisement Profiles
An advertisement profile defines a set of ANQP and H2QP profiles for the hotspot feature. Advertisement profiles can reference multiple instances of some ANQP and H2QP profile types, but only a single instance of other ANQP and H2QP profiles. The table below shows how the different ANQP and H2QP profile types can be associated to a single advertisement profile.
911 | 802.11u Hotspots ArubaOS 6.5.3.x | User Guide
Table 215: Hotspot Advertisement Profile Associations
One Instance per Advertisement
Profile
Multiple Instances per Advertisement Profile n n n
ANQP IP address availability profile
H2QP WAN metrics profile
H2QP connection capability profile n n n n n n n n n
ANQP venue name profile
ANQP network authentication profile
ANQP foaming consortium profile
ANQP NAI realm profile
ANQP 3GPP cellular network profile
H2QP operator friendly name profile
H2QP operating class indication profile
ANQP domain Name profile
H2QP OSU Providers List Settings
For more information on each of these profile types, see
Hotspot Profile Types on page 905
Configuring an Advertisement Profile
The steps below describe the procedure to associate an advertisement profile to a set of ANQP and H2QP profiles. Note that the procedure to associate an ANQP or H2QP profile to an advertisement profile varies, depending upon whether the advertisement profile can reference just one instance or many instances of that profile type
In the WebUI
To configure an advertisement profile from the controller WebUI:
1. Navigate to Configuration>Advanced Services>All Profiles .
2. In the Profiles list, click Wireless LAN expand the Wireless LAN profiles section.
3. Select Advertisement.
4. Select an existing advertisement profile from the list of profiles in the Profiles list. pane or create a new advertisement profile by entering a profile name into the entry blank on the Profile Details pane, then clicking Add . The ANQP and H2QP profiles associated with the selected advertisement profile appear below the advertisement profile in the Profiles list.
5. Define the OSU SSID. This is the SSID of the OSEN AP or any other AP that will be used for the sign-up process.
6. For an ANQP or H2QP profile type that can have only one instance associated with the advertisement profile: a. In the Profiles list, select the ANQP or H2QP profile type.
b. Click the drop-down list in the Profile Details pane and select a profile name.
7. For an ANQP or H2QP profile type that can have multiple instances associated with the advertisement profile: a. In the Profiles list, select the ANQP or H2QP profile type.
b. In the Profile Details pane, click the Add a Profile drop down list.
c. Select the name of the profile to associate with the advertisement profile.
d. click Add .
e. (Optional) To remove an existing reference to an ANQP or H2QP profile, select the profile name in the
Profile Details pane, then click Delete .
8. Click Apply .
ArubaOS 6.5.3.x
| User Guide 802.11u Hotspots | 912
In the CLI
To configure a advertisement profile from the controller CLI, access the CLI in config mode and issue the following commands: wlan hotspot advertisement profile <profile-name> anqp-3gpp-nwk-profile <profile-name> anqp-domain-name-profile <profile-name> anqp-ip-addr-avail-profile <profile-name> anqp-nai-realm-profile <profile-name> anqp-nwk-auth-profile <profile-name> anqp-roam-cons-profile <profile-name> anqp-venue-name-profile <profile-name> clone <profile-name> h2qp-conn-cap-profile <profile-name> h2qp-op-cl-profile <profile-name> h2qp-operator-friendly-profile <profile-name> h2qp-osu-prov-list-profile <profile-name> h2qp-wan-metrics-profile <profile-name> no ...
osu-ssid <osu-ssid>
Associating the Advertisement Profile to a Hotspot 2.0 Profile
The settings in the ANQP and H2QP profiles referenced by the Advertisement profile will not be sent to clients until you associate the advertisement profile with an active hotspot 2.0 profile. By default, all hotspot 2.0
profiles reference the default advertisement profile.
In the WebUI
To associate a different advertisement profile to a hotspot 2.0 profile:
1. Navigate to Configuration>Advanced Services>All Profiles .
2. In the Profiles list, click Wireless LAN expand the Wireless LAN profiles section.
3. Select Hotspot 2.0
. The list of available hotspot 2.0 profiles appears in the Profiles list.
4. In the Profiles list, select a hotspot 2.0 profile.
5. Click the Advertisement link that appears below the selected hotspot 2.0 profile.
6. In the Profile Details list, click the Advertisement Profile drop-down list and select a different advertisement profile name.
7. Click Apply .
In the CLI
To associate a different advertisement profile to a hotspot 2.0 profile from the controller CLI, access the CLI in config mode and issue the following commands: wlan hotspot hs2-profile <hotspot-profile-name> advertisement-profile <advertisement-profile-name>
Configuring ANQP Venue Name Profiles
Use this profile to define the venue group and venue type information be sent in an Access network Query
Protocol (ANQP) information element in a Generic Advertisement Service (GAS) query response. If a client uses the Generic Advertisement Service (GAS) to post an ANQP query to an Access Point, the AP will return ANQP
Information Elements with the values configured in this profile.
913 | 802.11u Hotspots ArubaOS 6.5.3.x | User Guide
To send the values configured in this profile to clients, you must associate this profile with an advertisement profile, then associate the advertisement profile with a hotspot 2.0 profile. For details, see
Advertisement Profiles on page 911
.
In the WebUI
To configure an ANQP venue name profile from the controller WebUI:
1. Navigate to Configuration>Advanced Services>All Profiles .
2. In the profiles list, expand the Wireless LAN section.
3. Select ANQP Venue Name.
4. Select an existing profile from the list of profiles on the profile details pane or create a new profile by entering a profile name into the entry blank, then clicking Add .
5. Configure the following parameters as desired, then click Apply to save your settings.
Table 216: ANQP Venue Name Profile Parameters
Parameter Description
Venue Group
Venue Language
Code
Specify one of the following venue groups to be advertised in the ANQP Information
Elements (IEs) from APs associated with this profile. The default setting is unspecified.
n n n n n n n n n n n n n assembly business educational factory-or-industrial institutional mercantile outdoor reserved residential storage unspecified
Utility-Misc
Vehicular
An ISO 639 language code that identifies the language used in the Venue Name field.
Venue Name
Venue Type
Venue name to be advertised in the ANQP IEs from APs associated with this profile. If the venue name includes spaces, the name must be enclosed in quotation marks, e.g.
“Midtown Shopping Center”.
Specify a venue type to be advertised in the IEs from APs associated with this hotspot profile. The complete list of supported venue types is described the table below
Venue Types
The following list describes the different venue types that may be configured in a Hotspot 2.0 or ANQP Venue
Name profile:
ArubaOS 6.5.3.x
| User Guide 802.11u Hotspots | 914
n n n n n n n n n n n n n n n n n n assembly-amphitheater assembly-amusementpark assembly-arena assembly-bar assembly-coffee-shop assembly-conventioncenter assembly-emer-coordcenter assembly-library assembly-museum assembly-passengerterminal assembly-restaurant assembly-stadium assembly-theater assembly-worship-place assembly-zoo business-attorney business-bank business-doctor n n n n n n n n n n n n n n n n n n business-fire-station business-police-station business-post-office business-professional-office business-research-anddevelopment educational-primary-school educational-secondary-school educational-university industrial-factory institutional-alcohol-or-drugrehab institutional-group-home institutional-hospital institutional-prison institutional-terminal-care mercantile-automotive-servicestation mercantile-gas-station mercantile-grocery mercantile-retail n n n n n n n n n n n n n n n n n n n mercantile-shopping-mall outdoor-bus-stop outdoor-city-park outdoor-kiosk outdoor-muni-mesh-nwk outdoor-rest-area outdoor-traffic-control residential-boardinghouse residential-dormitory residential-hotel residential-privateresidence unspecified vehicular-airplane vehicular-automobile vehicular-bus vehicular-ferry vehicular-motor-bike vehicular-ship vehicular-train
In the CLI
To configure an ANQP venue name profile from the controller CLI, access the CLI in config mode and issue the following commands: wlan hotspot anqp-venue-name-profile <profile-name> clone <profile-name> no ...
venue-group outdoor|reserved|utility-misc|vehicular|assembly|business educational|factoryor-industrial|institutional|mercantile|residential| storage|unspecified venue-language <language> venue-name <venue-name> venue-type <venue-type>
Configuring ANQP Network Authentication Profiles
Use the ANQP Network Authentication profile to define the authentication type used by the hotspot network.
To send the values configured in this profile to clients, you must associate this profile with an advertisement profile, then associate the advertisement profile with a hotspot 2.0 profile. For details, see
Advertisement Profiles on page 911
.
In the WebUI
To configure an ANQP network authentication profile from the controller WebUI:
1. Navigate to Configuration>Advanced Services>All Profiles .
2. In the profiles list, expand the Wireless LAN section.
915 | 802.11u Hotspots ArubaOS 6.5.3.x | User Guide
3. Select ANQP Network Authentication.
4. Select an existing profile from the list of profiles on the profile details pane or create a new profile by entering a profile name into the entry blank, then clicking Add .
5. Configure the following parameters as desired, then click Apply to save your settings.
Table 217: ANQP Network Authentication Profile Parameters
Parameter Description
Type of Network Authentication
Network Authentication URL
Network Authentication Type being used by the hotspot network.
n n acceptance : Network requires the user to accept terms and conditions. This option requires you to specify a redirection URL string as an IP address, FQDN or URL.
dns-redirection : Additional information on the network is provided through DNS redirection. This option requires you to specify a redirection URL string as an IP address, FQDN or URL.
n n http-https-redirection : Additional information on the network is provided through HTTP/HTTPS redirection.
online-enroll : Network supports online enrollment.
URL, IP address, or FQDN used by the hotspot network for the acceptance or dns-redirection network authentication types.
In the CLI
To configure an ANQP network authentication profile from the controller CLI, access the CLI in config mode and issue the following commands: wlan hotspot anqp-nwk-auth-profile <profile-name> clone <profile-name> no ...
nwk-auth-type acceptance|dns-redirection|http-https-redirection|online-enroll url <url>
Configuring ANQP Domain Name Profiles
This profile defines the hotspot operator domain name to be sent in an Access Network Query Protocol (ANQP) information element in a Generic Advertisement Service (GAS) query response.
To send the values configured in this profile to clients, you must associate this profile with an advertisement profile, then associate the advertisement profile with a hotspot 2.0 profile. For details, see
Advertisement Profiles on page 911
.
In the WebUI
To configure an ANQP domain name profile from the controller WebUI:
1. Navigate to Configuration>Advanced Services>All Profiles .
2. In the profiles list, expand the Wireless LAN section.
3. Select ANQP Domain Name.
4. Select an existing profile from the list of profiles on the profile details pane or create a new profile by entering a profile name into the entry blank, then clicking Add .
5. In the Domain Name field, enter the domain name of the hotspot operator. This alphanumeric text string must be 255 characters or less.
6. Click Apply .
ArubaOS 6.5.3.x
| User Guide 802.11u Hotspots | 916
In the CLI
To configure an ANQP domain name profile from the controller CLI, access the CLI in config mode and issue the following commands: wlan hotspot anqp-domain-name-profile <profile-name> clone <profile-name> domain-name <domain-name> no ...
Configuring ANQP IP Address Availability Profiles
Use this profile to specify the types of IPv4 and IPv6 IP addresses available in the hotspot network. This information is sent in an Access network Query Protocol (ANQP) information element in a Generic
Advertisement Service (GAS) query response.
To send the values configured in this profile to clients, you must associate this profile with an advertisement profile, then associate the advertisement profile with a hotspot 2.0 profile. For details, see
Advertisement Profiles on page 911
.
In the WebUI
To configure an ANQP IP address availability profile from the controller WebUI:
1. Navigate to Configuration>Advanced Services>All Profiles .
2. In the profiles list, expand the Wireless LAN section.
3. Select ANQP IP Address Availability
4. Select an existing profile from the list of profiles on the profile details pane or create a new profile by entering a profile name into the entry blank, then clicking Add .
5. Configure the following parameters as desired, then click Apply to save your settings.
917 | 802.11u Hotspots ArubaOS 6.5.3.x | User Guide
Table 218: ANQP IP Address Availability Profile Parameters
Parameter Description
IPv4 Address
Availability
Type
Indicate the availability of an IPv4 network by clicking the IPv4 Address Availability Type dropdown list and selecting one of the following options: n n n n n n n n availability-unknown: Network availability cannot be determined.
not-available: Network is not available.
port-restricted: Some ports are restricted (e.g., the network blocks port 110 to restrict POP mail).
port-restricted-double-nated: Some ports are restricted and multiple routers perform network address translation.
port-restricted-single-nated: Some ports are restricted and a single router performs network address translation.
private-double-nated: Network is a private network with multiple routers doing network address translation.
private-single-nated: Network is a private network a single router doing network address translation.
public: Network is a public network.
IPv6 Address
Availability
Type n n n
Indicate the availability of an IPv6 network by clicking the IPv6 Address Availability Type dropdown list and selecting one of the following options: available: An IPv6 network is available.
availability-unknown: Network availability cannot be determined.
not-available: Network is not available.
In the CLI
To configure an ANQP IP address availability profile from the controller CLI, access the CLI in config mode and issue the following commands: wlan hotspot anqp-ip-addr-avail-profile <profile-name> clone <profile-name> ipv4-addr-avail availability-unknown|not-available|port-restricted|port-restricted-doublenated|port-restricted-single-nated|private-double-nated|private-single-nated ipv6-addr-avail available|availability-unknown|not-available no ...
Configuring ANQP NAI Realm Profiles
An AP’s NAI Realm profile identifies and describes a Network Access Identifier (NAI) realm accessible using the
AP, and the method that this NAI realm uses for authentication. These settings configured in this profile determine the NAI realm elements that are included as part of a GAS Response frame.
To send the values configured in this profile to clients, you must associate this profile with an advertisement profile, then associate the advertisement profile with a hotspot 2.0 profile. For details, see
Advertisement Profiles on page 911
.
In the WebUI
To configure an ANQP NAI Realm profile from the controller WebUI:
1. Navigate to Configuration>Advanced Services>All Profiles .
2. In the profiles list, expand the Wireless LAN section.
3. Select ANQP NAI Realm
4. Select an existing profile from the list of profiles on the profile details pane or create a new profile by entering a profile name into the entry blank, then clicking Add .
ArubaOS 6.5.3.x
| User Guide 802.11u Hotspots | 918
5. Configure the following parameters as desired, then click Apply .
Table 219: ANQP NAI Realm Profile Parameters
Parameter Description
NAI Realm name Name of the NAI realm. The realm name is often the domain name of the service provider.
NAI Realm Encoding Issue this command if the NAI realm name is a UTF-8 formatted character string that is not formatted in accordance with IETF RFC 4282.
NAI Realm EAP Method n n n n n n n n n n n
Select one of the options below to identify the EAP authentication method supported by the hotspot realm.
crypto-card: Crypto card authentication eap-aka: EAP for Universal Mobile Telecommunications System
(UMTS) Authentication and Key Agreement eap-sim: EAP for GSM Subscriber Identity Modules eap-tls: EAP-Transport Layer Security eap-ttls: EAP-Tunneled Transport Layer Security generic-token-card: EAP Generic Token Card (EAP-GTC) identity: EAP Identity type notification: The hotspot realm uses EAP Notification messages for authentication.
one-time-password: Authentication with a single-use password peap: Protected Extensible Authentication Protocol peap-mschapv2: Protected Extensible Authentication Protocol with
Microsoft Challenge Handshake Authentication Protocol version 2
919 | 802.11u Hotspots ArubaOS 6.5.3.x | User Guide
Parameter
NAI Realm Authentication 1
NAI Realm Authentication 2
Description
Use the NAI Realm Authentication 1 and NAI Realm Authentication
2 parameters to send the one of the following authentication methods for the primary NAI realm ID.
Supported authentication methods: n credential-type: The specified authentication ID uses credential authentication.
n n n expanded-eap: The specified authentication ID uses the expanded EAP authentication method.
expanded-inner-eap: The specified authentication ID uses the expanded inner EAP authentication method.
inner-auth-eap: The specified authentication ID uses inner EAP authentication type.
n non-eap-inner-auth: The specified authentication ID uses non-EAP inner authentication type.
Supported authentication values: n n n n n n n n n n n n n n n n n n n n n n n n n n n cred-cert: Credential - Certificate cred-hw-token: Credential - Hardware Token cred-nfc: Credential - NFC cred-none: Credential - None cred-rsvd: Credential - Reserved cred-sim: Credential - SIM cred-soft-token: Credential - Soft Token cred-user-pass: Credential - Username/password cred-usim: Credential - USIM cred-vendor-spec: Credential - Vendor-specific eap-crypto-card: EAP Method - Crypto-card eap-generic-token-card: EAP Method - Generic-Token-Card eap-identity: EAP Method - Identity eap-method-aka: EAP Method - AKA eap-method-sim: EAP Method - SIM - GSM Subscriber Iden eap-method-tls: EAP Method - TLS - Transport Layer Sec eap-method-ttls: EAP Method - TTLS - Tunneled Transport Security eap-notification: EAP Method - Notification eap-one-time-password: EAP Method - One-Time-Password eap-peap: EAP Method - PEAP eap-peap-mschapv2: EAP Method - PEAP MSCHAP V2 non-eap-chap: Non-EAP Method - CHAP non-eap-mschap: Non-EAP Method - MSCHAP non-eap-mschapv2: Non-EAP Method - MSCHAPv2 non-eap-pap: Non-EAP Method - PAP non-eap-rsvd: Non-EAP Method - Reserved for future use reserved: Reserved for Future use
Mark the realm in this profile as the NAI Home Realm NAI Home Realm
In the CLI
The following example configures two ANQP NAI realm profiles from the controller CLI wlan hotspot anqp-nai-realm-profile home enable nai-realm-name corp-hotspot.com
nai-realm-auth-param-1 id credential-type value cred-cert nai-home-realm
!
wlan hotspot anqp-nai-realm-profile non-home nai-realm-name corp-hotspot-roam.com
nai-realm-eap-method eap-sim nai-realm-auth credential-type
ArubaOS 6.5.3.x
| User Guide 802.11u Hotspots | 920
Configuring ANQP Roaming Consortium Profiles
Organization Identifiers (OIs) are assigned to service providers when they register with the IEEE registration authority. You can specify the OI for the hotspot’s service provider in the ANQP Roaming Consortium profile using the ANQP Roaming Consortium Profile. The Hotspot 2.0 profile also allows you to define and send up to three additional roaming consortium OIs for the service provider’s top three roaming partners.
To send the values configured in this profile to clients, you must associate this profile with an advertisement profile, then associate the advertisement profile with a hotspot 2.0 profile. For details, see
Advertisement Profiles on page 911
.
In the WebUI
To configure an ANQP roaming consortium profile from the controller WebUI:
1. Navigate to Configuration>Advanced Services>All Profiles .
2. In the profiles list, expand the Wireless LAN section.
3. Select ANQP Roaming Consortium.
4. Select an existing profile from the list of profiles on the profile details pane or create a new profile by entering a profile name into the entry blank, then clicking Add .
5. Configure the following parameters as desired, then click Apply to save your settings.
Table 220: ANQP Roaming Consortium Profile Parameters
Parameter Description
Roaming consortium OI
Len
Length of the OI. The value of the Roaming consortium OI Len parameter must equal upon the number of octets of the Roaming Consortium OI field.
n
0 : 0 Octets in the OI (Null) n n
3 : OI length is 24-bit (3 Octets)
5 : OI length is 36-bit (5 Octets)
In the CLI
To configure an ANQP roaming consortium profile from the controller CLI, access the CLI in config mode and issue the following commands: wlan hotspot anqp-roam-cons-profile <profile-name> clone <profile-name> no ...
roam-cons-oi <roam-cons-oi>
Configuring ANQP 3GPP Cellular Network Profiles
Use this profile to define priority information for a 3rd Generation Partnership Project (3GPP) Cellular Network used by hotspots that have roaming relationships with cellular operators.
To send the values configured in this profile to clients, you must associate this profile with an advertisement profile, then associate the advertisement profile with a hotspot 2.0 profile. For details, see
Advertisement Profiles on page 911
.
In the WebUI
To configure an ANQP 3GPP cellular network profile from the controller WebUI:
921 | 802.11u Hotspots ArubaOS 6.5.3.x | User Guide
1. Navigate to Configuration>Advanced Services>All Profiles .
2. In the profiles list, expand the Wireless LAN section.
3. Select ANQP 3GPP Cellular Network.
4. Select an existing profile from the list of profiles on the profile details pane or create a new profile by entering a profile name into the entry blank, then clicking Add .
5. Configure the following parameters as desired, then click Apply to save your settings.
Table 221: ANQP 3GPP Cellular Network Profile Parameters
Parameter Description
3GPP PLMN1
3GPP PLMN2
3GPP PLMN3
3GPP PLMN4
3GPP PLMN5
3GPP PLMN6
The Public Land Mobile Networks (PLMN) value of the highest-priority network.
The PLMN is comprised of a 12-bit Mobile Country Code (MCC) and the 12-bit Mobile
Network Code (MNC).
The Public Land Mobile Networks (PLMN) value of the second-highest priority network.
The PLMN is comprised of a 12-bit Mobile Country Code (MCC) and the 12-bit Mobile
Network Code (MNC).
The Public Land Mobile Networks (PLMN) value of the third-highest priority network.
The PLMN is comprised of a 12-bit Mobile Country Code (MCC) and the 12-bit Mobile
Network Code (MNC).
The Public Land Mobile Networks (PLMN) value of the fourth-highest priority network.
The PLMN is comprised of a 12-bit Mobile Country Code (MCC) and the 12-bit Mobile
Network Code (MNC).
The Public Land Mobile Networks (PLMN) value of the fifth-highest priority network.
The PLMN is comprised of a 12-bit Mobile Country Code (MCC) and the 12-bit Mobile
Network Code (MNC).
The Public Land Mobile Networks (PLMN) value of the sixth-highest priority network.
The PLMN is comprised of a 12-bit Mobile Country Code (MCC) and the 12-bit Mobile
Network Code (MNC).
In the CLI
To configure an ANQP 3GPP network profile from the controller CLI, access the CLI in config mode and issue the following commands: wlan hotspot anqp-3gpp-nwk-profile <profile-name>
3gpp_plmn1 <3GPP PLMN1 data>
3gpp_plmn2 <3GPP PLMN2 data>
3gpp_plmn3 <3GPP PLMN3 data>
3gpp_plmn4 <3GPP PLMN4 data>
3gpp_plmn5 <3GPP PLMN5 data>
3gpp_plmn6 <3GPP PLMN6 data> clone <profile-name> enable no ...
Configuring H2QP Connection Capability Profiles
Use this profile to specify hotspot protocol and port capabilities. This information is sent in a Access Network
Query Protocol (ANQP) information element in a Generic Advertisement Service (GAS) query response.
ArubaOS 6.5.3.x
| User Guide 802.11u Hotspots | 922
To send the values configured in this profile to clients, you must associate this profile with an advertisement profile, then associate the advertisement profile with a hotspot 2.0 profile. For details, see
Advertisement Profiles on page 911
.
In the WebUI
To configure a H2QP connection capability profile from the controller WebUI:
1. Navigate to Configuration>Advanced Services>All Profiles .
2. In the profiles list, expand the Wireless LAN section.
3. Select H2QP Connection Capability.
4. Select an existing profile from the list of profiles on the profile details pane or create a new profile by entering a profile name into the entry blank, then clicking Add .
5. Configure the following parameters as desired, then click Apply to save your settings.
Table 222: ANQP Connection Capability Profile Parameters
Parameter Description
H2QP Connection Capability
ICMP Port
Select this option to enable the ICMP port. (port 0)
H2QP Connection Capability FTP port (TCP Protocol)
Select this option to enable the FTP port. (port 20)
H2QP Connection Capability SSH port (TCP Protocol)
Select this option to enable the SSH port. (port 22)
H2QP Connection Capability
HTTP port (TCP Protocol)
Select this option to enable the HTTP port. (port 80)
H2QP Connection Capability TLS
VPN port (TCP Protocol)
H2QP Connection Capability TLS VPN port(TCP Protocol)
H2QP Connection Capability PPTP
VPN port (TCP Protocol)
Select this option to enable the PPTP port used by IPSec VPNs. (port
1723)
H2QP Connection Capability VOIP port (TCP Protocol)
Select this option to enable the TCP VoIP port. (port 5060)
H2QP Connection Capability VOIP port (UDP Protocol)
Select this option to enable the UDP VoIP port. (port 5060)
H2QP Connection Capability
IKEv2 port for IPSec VPN
Select this option to enable the IPsec VPN port. (ports 500, 4500 and 0)
923 | 802.11u Hotspots ArubaOS 6.5.3.x | User Guide
Parameter
H2QP Connection Capability May be used by IKEv2 port for IPSec
VPN
Description
Select this option to enable the IKEv2 port 4500.
H2QP Connection Capability
IKEv2 port for IPSec VPN
Select this option to enable the IKEv2 port 500.
H2QP Connection Capability ESP port(Used by IPSec VPN)
Include this parameter to enable the Encapsulating Security Payload
(ESP) port used by IPSec VPNs. (port 0)
In the CLI
To configure a H2QP connection capability profile from the controller CLI, access the CLI in config mode and issue the following commands: wlan hotspot h2qp-conn-capability-profile <profile> clone <profile-name> esp icmp no ...
tcp-ftp tcp-http tcp-pptp-vpn tcp-ssh tcp-tls-vpn tcp-voip udp-ike2-4500 udp-ike2-500 udp-ipsec-vpn udp-voip
Configuring H2QP Operator Friendly Name Profiles
This profile defines an operator-friendly name sent by devices using this profile.
To send the values configured in this profile to clients, you must associate this profile with an advertisement profile, then associate the advertisement profile with a hotspot 2.0 profile. For details, see
Advertisement Profiles on page 911
.
In the WebUI
To configure a H2QP operating class profile from the controller WebUI:
1. Navigate to Configuration>Advanced Services>All Profiles .
2. In the profiles list, expand the Wireless LAN section.
3. Select H2QP Operator Friendly Name.
4. Select an existing profile from the list of profiles on the profile details pane or create a new profile by entering a profile name into the entry blank, then clicking Add .
5. Configure the following parameters as desired, then click Apply to save your settings.
ArubaOS 6.5.3.x
| User Guide 802.11u Hotspots | 924
Table 223: H2QP Operator Friendly Name Profile Parameters
Parameter Description
Operator Friendly Name Language Code
Operator Friendly Name
An ISO 639 language code that identifies the language used in the Operator Friendly Name field
An operator-friendly name sent by devices using this profile. The name can be up to 64 alphanumeric characters, and can include special characters and spaces. If the name includes quotation marks (“), include a backslash character (\) before each quotation mark. (e.g. \"example\")
In the CLI
To configure a H2QP operator friendly name profile from the controller CLI, access the CLI in config mode and issue the following commands: wlan hotspot h2qp-operator-friendly-name-profile <profile> clone <profile-name> no ...
op-fr-name <op-fr-name> op-lang-code <op-lang-code>
Configuring H2QP Operating Class Indication Profiles
The values configured in this H2QP Operating Class Indication profile list the channels on which the hotspot is capable of operating. It may be useful where, for instance, a mobile device discovers a hotspot in the 2.4 GHz band but finds it is dual-band and prefers the 5 GHz band.
To send the values configured in this profile to clients, you must associate this profile with an advertisement profile, then associate the advertisement profile with a hotspot 2.0 profile. For details, see
Advertisement Profiles on page 911
.
In the WebUI
To configure a H2QP operating class indication profile from the controller WebUI:
1. Navigate to Configuration>Advanced Services>All Profiles .
2. In the profiles list, expand the Wireless LAN section.
3. Select H2QP Operating Class Indication.
4. Select an existing profile from the list of profiles on the profile details pane or create a new profile by entering a profile name into the entry blank, then clicking Add .
5. In the H2QP Operating Class field, enter a valid operating class value. (For a definition of these global operating classes refer to Table E-4 of IEEE Std 802.11-2012, Annex E.)
6. Click Apply .
In the CLI
To configure a H2QP operating class profile from the controller CLI, access the CLI in config mode and issue the following commands: wlan hotspot h2qp-op-cl-profile <profile> clone <profile-name> op-cl <1-255>
925 | 802.11u Hotspots ArubaOS 6.5.3.x | User Guide
Configuring H2QP WAN Metrics Profiles
Use this profile to specify the WAN status and link metrics for your hotspot.
To send the values configured in this profile to clients, you must associate this profile with an advertisement profile, then associate the advertisement profile with a hotspot 2.0 profile. For details, see
Advertisement Profiles on page 911
.
In the WebUI
To configure an ANQP venue name profile from the controller WebUI:
1. Navigate to Configuration>Advanced Services>All Profiles .
2. In the profiles list, expand the Wireless LAN section.
3. Select H2QP WAN Metrics.
4. Select an existing profile from the list of profiles on the profile details pane or create a new profile by entering a profile name into the entry blank, then clicking Add .
5. Configure the following parameters as desired, then click Apply to save your settings.
Table 224: H2QP WAN Metrics Profile Parameters
Parameter Description
H2QP WAN metrics link status
Define the status of the WAN Link by clicking the H2QP WAN metrics link status drop-down list, and selecting one of the following values. The default link status is reserved , which indicates that the link status is unknown or unspecified n n link down: WAN link is down.
link test : WAN link is currently in a test state.
n n link up : WAN link is up.
reserved : This parameter is reserved by the Hotspot 2.0 specification, and cannot be configured.
Default: reserved
H2QP WAN metrics symmetric WAN link
Select this checkbox to indicate that the WAN Link has same speed in both the uplink and downlink directions.
H2QP WAN metrics link at capacity
WAN Metrics uplink speed
WAN Metrics downlink speed
Select this checkbox to indicate that the WAN Link has reached its maximum capacity.
If this parameter is enabled, no additional mobile devices will be permitted to associate to the hotspot AP.
This parameter defines the current WAN uplink speed in Kbps. If no value is set, this parameter will show a default value of 0 to indicate that the uplink speed is unknown or unspecified.
Range: 0 - 2147483647, Default: 0
This parameter defines the current WAN backhaul downlink speed in Kbps. If no value is set, this parameter will show a default value of 0 to indicate that the downlink speed is unknown or unspecified.
Range: 0 - 2147483647, Default: 0
ArubaOS 6.5.3.x
| User Guide 802.11u Hotspots | 926
Parameter Description
WAN Metrics uplink load
This parameter defines the percentage of the WAN uplink that is currently utilized. If no value is set, this parameter will show a default value of 0 to indicate that the downlink speed is unknown or unspecified.
Range: 0-100; Default: 0
WAN Metrics downlink load
This parameter defines the percentage of the WAN downlink that is currently in use. If no value is set, this parameter will show a default value of 0 to indicate that the downlink speed is unknown or unspecified.
Range: 0-100; Default: 0
WAN Metrics load measurement duration
Duration over which the downlink load is measured, in tenths of a second.
Range: 0-65535; Default: 0
In the CLI
To configure a H2QP WAN metrics profile from the controller CLI, access the CLI in config mode and issue the following commands: wlan hotspot h2qp-wan-metrics-profile <profile-name> at-capacity clone <profile-name> downlink-load downlink-speed load-dur no ...
symm-link uplink-load uplink-speed wan-metrics-link-status link_down|link_test|link_up|reserved
Configuring H2QP OSU Provider List Profiles
This profile defines a list of Online Sign Up (OSU) service providers available from the hotspot. When you configure an OSU provider list, if a customer device cannot find a service from a known operator, the device receives a notification from the hotspot that additional OSU services are available. If the customer elects to sign up, they are presented with a list of up to two Online Sign Up providers.
To send the values configured in this profile to clients, you must associate this profile with an advertisement profile, then associate the advertisement profile with a hotspot 2.0 profile. For details, see
Advertisement Profiles on page 911
.
ArubaOS supports up to two icon files per OSU provider. These files need to be uploaded to the controller as part of the OSU provider configuration. When a Hotspot AP reboots, the AP downloads these icon files from the controller.
In the WebUI
To configure an H2QP OSU Provider List profile from the controller WebUI:
1. Navigate to Configuration > Advanced Services > All Profiles .
2. In the Profiles list, expand the Wireless LAN section.
3. Select H2QP OSU Provider List Profiles
4. Select an existing profile from the list of profiles on the Profile Details pane or create a new profile by entering a profile name into the entry blank, then clicking Add .
927 | 802.11u Hotspots ArubaOS 6.5.3.x | User Guide
5. Configure the following parameters as desired, and then click Apply .
Table 225: H2QP OSU Provider List Profile Parameters
Parameter Description
Number of friendly names in the OSU providers list (1 or 2).
Number of Friendly Name
Configured
OSU Friendly Name Language
Code1
OSU Friendly Name1
OSU Friendly Name1 in HEX
OSU Friendly Name Language
Code2
OSU Friendly Name2
OSU Friendly Name2 in HEX
OSU Server URI
Number of Iconfile Configured
Icon1 width
Icon1 height
Icon1 Language Code
Icon1 type
Icon1 filename
Icon2 width
Icon2 height
Icon2 Language Code
Icon2 type
Icon2 filename
An ISO 639 language code that identifies the language used in the frndname1 field.
User-friendly name of a service provider in the OSU providers list.
Configure this parameter only if the associated language code is eng
(English), and the service provider name does not include special characters.
Hexadecimal string describing the name of a service provider in the OSU providers list. Configure this string for service provider names that require special characters.
An ISO 639 language code that identifies the language used in the frndname2 field.
User-friendly name of a second service provider in the OSU providers list.
Configure this parameter only if the associated language code is eng
(English), and the service provider name does not include special characters.
Hexadecimal string describing the name of a second service provider in the OSU providers list. Configure this string for service provider names that require special characters.
Uniform Resource Identifier (URI) of the OSU server, for example, osuserver.corp.example.com
Number of icon files in the OSU provider list. (1- 2)
Width of the first icon, in pixels. (1-256 pixels)
Height of the first icon, in pixels. (1-256 pixels)
An ISO 639 language code that identifies the language used in the Icon1 filename field.
Icon file type. This value can be IANA MIME media types image/png , image/jpg or image/jpeg.
File name of an icon for the second OSU in the list.
Width of the second icon, in pixels. (1-256 pixels)
Height of the second icon, in pixels. (1-256 pixels)
An ISO 639 language code that identifies the language used in the Icon2 filename field.
Icon file type. This value can be IANA MIME media types image/png , image/jpg or image/jpeg.
File name of an icon for the second OSU in the list.
ArubaOS 6.5.3.x
| User Guide 802.11u Hotspots | 928
Parameter
Number of Service Description
Configured
OSU Service Description 1
Language Code
OSU Service Description 1
OSU Service Description 1 in
HEX
OSU Service Description 2
Language Code
OSU Service Description 2
OSU Service Description 2 in
HEX
HS 2.0 OSU Provider Method
Description
Number of service descriptions in the OSU provisioning list.
An ISO 639 language code that identifies the language used in the srvcdesc1 field.
Text string describing an Online Sign-Up (OSU) service. If the description includes spaces, enclose the description in quotation marks (").
Configure this parameter only if the associated language code is eng
(English).
Description of an Online Sign-Up (OSU) service in hexadecimal characters. Configure this string for a service description that requires special characters, or if the language code is set to any language other than eng .
An ISO 639 language code that identifies the language used in the srvcdesc2 field.
Text string describing a second Online Sign-Up (OSU) service. If the description includes spaces, enclose the description in quotation marks
(").
Configure this parameter only if the associated language code is eng
(English).
Description of a second Online Sign-Up (OSU) service, in hexadecimal characters. Configure this string for a service description that requires special characters, or if the language code is set to any language other than eng .
Select one of the OSU provider provisioning methods: n OMA-DM : Open Mobile Alliance (OMA) Device Management (DM) n SOAP-XML : Simple Object Access Protocol/Extensible Markup
Language
In the CLI
To configure an OSU provider list profile in the command-line interface, access the CLI in config mode and issue the following command:
(host) (config) # wlan hotspot h2qp-osu-prov-list-profile <profile>
Uploading an Icon file
To upload a OSU provider icon into the controller flash drive using the WebUI:
1. Navigate to Maintenance > File > Copy Files
2. In the Source Selection field, select the method you will use to upload the source file. If you are uploading the icon file from an external source, you are prompted to enter details such as the external Host IP address.
3. In the Destination Selection section, select Flash File System , and enter a name for the icon file.
4. Click Apply .
To copy an OSU icon file to the controller using the CLI, access the CLI in config mode and issue the following command:
(host)(config) # copy {tftp: <tftphost> <destfilename>}|{usb: partition {0|1} <destfilename>}|
{ftp: <ftphost> <user> <filename>}flash: <destfilename>
929 | 802.11u Hotspots ArubaOS 6.5.3.x | User Guide
Chapter 39
Adding Local Controllers
This chapter explains how to expand your network by adding a local controller to a master controller configuration. Typically, this is the first expansion of a network with just one controller (which is a master controller). This chapter is a basic discussion of creating master-local controller configurations. More complicated multi-controller configurations are discussed in other chapters.
This chapter describes the following topics: n n n
Moving to a Multi-Controller Environment on page 930
Configuring Local Controllers on page 933
Uplink Monitoring and Management on page 935
Moving to a Multi-Controller Environment
For a single WLAN configuration, the master controller is the controller which controls the RF and security settings of the WLAN. Additional controllers to the same WLAN serve as local switches to the master controller.
The local controller operates independently of the master controller and depends on the master controller only for its security and RF settings. You configure the layer-2 and layer-3 settings on the local controller independent of the master controller. The local controller needs to have connectivity to the master controller at all times to ensure that any changes on the master are propagated to the local controller.
Some of the common reasons to move from a single to a multi-controller-environment include: n n n
Scaling to include a larger coverage area
Setting up remote Access Points (APs)
Network setup requires APs to be redistributed from a single controller to multiple controllers
You can use a pre-shared key (PSK) or a certificate to create IPSec tunnels between a master and backup master controllers and between master and local controllers. These inter-controller IPsec tunnels carry management traffic such as mobility, configuration, and master-local information.
An inter-controller IPsec tunnel can be used to route data between networks attached to the controllers if you have installed PEFV licenses in the controllers. To route traffic, configure a static route on each controller specifying the destination network and the name of the IPsec tunnel.
There is a default PSK to allow inter-controller communications, however, for security you need to configure a unique PSK for each controller pair. You can use either the WebUI or CLI to configure a 6-64 character PSK on master and local controllers. To configure a unique PSK for each controller pair, you must configure the master controller with the IP address of the local and the PSK, and configure the local controller with the IP address of the master and the PSK.
You can configure a global PSK for all master-local communications, although this is not recommended for networks with more than two controllers. On the master controller, use 0.0.0.0
for the IP address of the local.
On the local controller, configure the IP address of the master and the PSK.
The local controller can be located behind a NAT device or over the Internet. On the local controller, when you specify the IP address of the master controller, use the public IP address for the master.
If your master and local controllers use PSK for authentication, the IPsec tunnel will be created using IKEv1. If they use a factory-installed or custom certificate, they will use IKEv2 to create the IPsec tunnel. Controllers
ArubaOS 6.5.3.x
| User Guide Adding Local Controllers | 930
using IKEv2 and custom-installed certificates can optionally use Suite-B encryption for IPsec encryption. For details and requirements for Suite-B encryption, see
Suite-B Cryptography on page 436
.
Configuring a PSK
Leaving the PSK set to the default value exposes the IPsec channel to serious risk, therefore you should always configure a unique PSK for each controller pair.
Sharing the same PSK between more than two controllers increases the likelihood of compromise. If one controller is compromised, all controllers are compromised. Therefore, best security practices include configuring a unique PSK for each controller pair
Do not use the default global PSK on a master or stand-alone controller. If you have a multi-controller network then configure the local controllers to match the new IPsec PSK key on the master controller.
Weak keys are susceptible to offline dictionary attacks, meaning that a hostile eavesdropper can capture a few packets during connection setup and derive the PSK, thus compromising the connection. Therefore the PSK selection process should be the same process as selecting a strong passphrase: n n n the PSK should be at least ten characters in length the PSK should not be a dictionary word the PSK should combine characters from at least three of the following four groups: l lowercase characters l l l uppercase characters numbers punctuation or special characters, such as !~‘@#$%^&*()_-+=\|//.[]{}
The following sections describe how to configure a PSK using the WebUI or CLI.
Configuring a Master Controller PSK
Use the procedure below to configures the IP address and preshared key for the master controller.
In the WebUI
To configure a master controller PSK:
1. Navigate to the Configuration > Network > Controller > System Settings page.
2. In the IPSEC Key (IKE PSK) field, enter the IPSec key. Reenter this key in the Retype IPSEC Key (IKE PSK) field.
3. (Optional) In the FQDN field, enter a fully qualified domain name used in IKE.
4. (Optional) Click the Source IP address field and select the VLAN ID of Vlan interface to initiate IKE. The controller IP address will be used if the VLAN is not specified.
5. Click Apply .
In the CLI
On the master controller you can configure a specific IPsec PSK for a local controller and use the localip
0.0.0.0 ipsec <secret_key> command:
You need to change the secret key to a non-default PSK value even if you use a per-local controller PSK configuration.
To configure a master controller PSK:
(host)(config) #localip 0.0.0.0 ipsec <secret_key>
931 | Adding Local Controllers ArubaOS 6.5.3.x | User Guide
(host)(config) #localip <ipaddr> ipsec <secret_key>
Configuring a Local Controller PSK
Use the procedure below to configure the IP address and PSK for the local controller.
In the WebUI
To configure a local controller PSK:
1. Navigate to Configuration > Network > Controller > System Settings .
2. The procedure to configure a local PSK varies, depending upon whether it is configured using a local controller or a master controller.
n n
On a local controller, enter the IPsec key in the IPSec Key (IKE PSK) and Retype IPSec Key (IKE PSK) fields.
On a master controller, click New under Local Controller IPSec Keys . then enter the local controller IP address and then enter and retype the IPsec key. Click Add .
3. Click Apply .
In the CLI
To configure a local controller PSK:
On the local controller the PSK must match the master controller’s PSK.
(host)(config) #masterip <ipaddr> ipsec <secret_key> [fqdn <fqdn>][uplink][vlan <id>]
Configuring a Controller Certificate
The following sections describe how to use the command-line interface to select a factory-installed or custom certificate for secure inter-controller communication.
Configuring a Local Controller Certificate n
Issue the following command on a master controller to configure the factory-installed certificate for secure communication between that master and a local controller.
(host)(config) #local-factory-cert local-mac <mac> n
In this command, <mac> is the MAC address of the local controller’s factory-installed certificate.
Issue the following command on a master controller to configure a custom certificate for secure communication between that master and a local controller.
(host)(config) #local-custom-cert local-mac <mac> ca-cert <ca> server-cert <cert> suite-b
<gcm-128 | gcm-256>
In this command, <mac> is the MAC address of the local controller’s custom certificate.
Configuring a Master Controller Certificate
Issue the following command on a local controller to configure the preshared key or certificate for the master controller.
(host)(config) #masterip <ipaddr> ipsec <key> [interface uplink|{vlan <id>}] [fqdn <fqdn>] ipsec-custom-cert master-mac1 <mac1> [master-mac2 <mac2>] ca-cert <ca> server-cert <cert>
[interface uplink|{vlan <id>}] [fqdn <fqdn>] [suite-b gcm-128|gcm-256] ipsec-factory-cert master-mac1 <mac1> [master-mac2 <mac2>] [interface uplink|{vlan <id>}]
[fqdn <fqdn>]
ArubaOS 6.5.3.x
| User Guide Adding Local Controllers | 932
Configuring Local Controllers
The steps involved in migrating from a single to a multi-controller environment are:
1. Configure the role of the local controller to local and specify the IP address of the master.
2. Configure the layer-2 / layer-3 settings on the local controller (VLANs, IP subnets, IP routes).
3. Configure as trusted ports the ports the master and local controller use to communicate with each other.
4. For those APs that need to boot off the local controller, configure the LMS IP address to point to the new local controller.
5. Reboot the APs that are already on the network, so that they now connect to the local controller.
These steps are explained below.
You configure the role of a controller by running the initial setup on an unconfigured controller, or by using the
WebUI, Controller Wizard, or CLI on a previously-configured controller.
Using the Initial Setup
Initial setup can be done using the browser-based Setup Wizard or by accessing the initial setup dialog via a serial port connection. Both methods are described in the ArubaOS Quick Start Guide and are referred throughout this section as "initial setup".
The initial setup allows you to configure the IP address of the controller and its role, in addition to other operating parameters. You perform the initial setup the first time you connect to and log into the controller or whenever the controller is reset to its factory default configuration (after executing a write erase , reload sequence).
When prompted to enter the controller role in the initial setup, select or enter local to set the controller operational mode to be a local controller. You are then prompted for the master controller IP address. Enter the IP address of the master controller for the WLAN network. Enter the preshared key (PSK) that is used to authenticate communications between controllers.
You need to enter the same PSK on the master controller and on the local controllers that are managed by the master.
In the WebUI
For a controller that is up and operating with layer-3 connectivity, configure the following to set the controller as local:
1. Navigate to Configuration > Network > Controller > System Settings .
2. Set the Controller Role to Local.
3. Enter the IP address of the master controller. If master redundancy is enabled on the master, this address should be the VRRP address for the VLAN instance corresponding to the IP address of the controller.
4. Enter the PSK that is used to authenticate communications between controllers.
You need to enter the same PSK on the master controller and on the local controllers that are managed by the master.
In the CLI
For a controller that is up and operating with layer-3 connectivity, configure the following to set the controller as local:
(host)(config) #masterip <ipaddr> ipsec <key>
933 | Adding Local Controllers ArubaOS 6.5.3.x | User Guide
Configuring Layer-2/Layer-3 Settings
Configure the VLANs, subnets, and IP address on the local controller for IP connectivity.
Verify connectivity to the master controller by pinging the master controller from the local controller.
Ensure that the master controller recognizes the new controller as its local controller. The local controller should be listed with type local in the Monitoring > Network > All WLAN Controllers page on the master.
It takes about 4–5 minutes for the master and local controllers to synchronize configurations.
Configuring Trusted Ports
On the local controller, navigate to the Configuration > Network > Ports page and make sure that the port on the local controller connecting to the master is trusted. On the master controller, check this for the port on the master controller that connects to the local controller.
n n
Configuring Local Controller Settings
Many controller settings are unique to that device and therefore are not replicated from a master controller to a local controller. The following settings must be manually configured on a local controller that synchronizes with the master controller.
n n n
Time zone and daylight savings time settings
VPN pools for remote APs and other VPN clients.
Controller and IP interfaces. (Note that these values may need to be set before synchronization with the master so the synchronization can properly complete.)
IP routing and spanning-tree configurations
Remote AP whitelist and local-user database values
By default, the local controllers forward the authentication requests for the RAP whitelist and the local user database to the master controller. Therefore, this data does not have to be manually replicated unless the default behavior has been altered. The user table is NOT synchronized, so if an AP fails over to a master from a local or vice versa, that AP will have to re-authenticate.
n n n n n n n n n
DHCP pools
NAT pools
SNMP and syslog settings
Hostnames, DNS and SMTP servers
ACLs applied to ports
Certificates
RADIUS client details and RADIUS source interfaces
Stateful firewall settings
Customized captive portal pages and images, and the captive portal redirect address.
If you want to configure GRE tunnel between master and local controllers, you should use controller-IPs as tunnel endpoints.
Configuring APs
APs download their configurations from a master controller. However, an AP or AP group can tunnel client traffic to a local controller. To specify the controller to which an AP or AP group tunnels client traffic, you configure the LMS IP in the AP system profile on the master controller.
ArubaOS 6.5.3.x
| User Guide Adding Local Controllers | 934
Configuration changes take effect only after you reboot the affected APs; this allows them to reassociate with the local controller. After rebooting, these APs appear to the new local controller as local APs.
In the WebUI
To configure the LMS IP:
1. Navigate to Configuration > Wireless > AP Configuration .
l
If you select AP Group, click Edit for the AP group name for which you want to configure the LMS IP.
l
If you select AP Specific, select the name of the AP for which you want to configure the LMS IP.
2. Under the Profiles section, select AP to display the AP profiles.
3. Select the AP system profile you want to modify.
4. Enter the controller IP address in the LMS IP field.
5. Click Apply .
In the CLI
To configure the LMS IP:
(host)(config) #ap system-profile <profile-name>
(host) (AP system profile "default") #lms-ip <ipaddr>
(host)(config) #ap-group <group-name>
(host) (AP group "default") #ap-system-profile <profile>
(host)(config) #ap-name <profile-name>
(host) (AP name "default") #ap-system-profile <profile>
Uplink Monitoring and Management
The ArubaOS Uplink Manager prioritizes cellular and wired uplinks, and monitors the availability and quality of the connection to a remote host with specified FQDN or IP address. The status of these monitored uplinks appears on the
WAN section of the controller dashboard
.
By default, the cellular uplink is a lower priority than the wired uplink; making the wired link the primary link and the cellular link the secondary or backup link.
The uplink manager is enabled by default on branch controller uplinks. Use the procedures below to manually enable and configure this feature on a master or local (non-branch) controller.
For details on configuring the uplink management settings on a branch controller see
In the WebUI
1. Navigate to Configuration> Network > Controller and select the System Settings tab.
2. In the Uplink section, click Yes to enable the uplink manager.
3. (Optional) Define a non-default priority for a wired and cellular connections in the Default Wired Priority and Default Cellular Priority fields. The default priority for a wired connection is 200, and the default priority for a cellular connection is 100.
4. (Optional) In the Uplink Health-Check Enabled field, select Yes to monitor the availability and quality of the connection to a remote host specified in the IP/FQDN of remote host field.
5. (Optional) Click New in the Uplink Type field to define a VLAN ID and priority level for each uplink interface on the controller. The Uplink table on this page displays the state, status and reachability of each defined link.
935 | Adding Local Controllers ArubaOS 6.5.3.x | User Guide
6. (Optional) If you enabled the Uplink Health-Check feature in step 4, you can use the Health Check
Settings parameters to modify the health-check ping probe settings described in the table below.
7. Click Apply .
Table 226: WAN Health Check Settings
Parameter Description
Probe Mode Click the Probe Mode drop-down list and select ping to enable this feature.
Probe Interval (sec)
Packet Burst Per Probe
Probe Retries
The Probe Interval field specifies the probe interval, in seconds. The WAN health-check feature sends the number of probes defined by the Pocket Burst per Probe parameter during each probe interval. To change the default interval of 10 seconds, enter a new value into this field.
The Pocket Burst per Probe field specifies the number of probes to be sent during the probe interval. To change the default value of 5 probes, enter a new value into this field.
The number of times the controller attempts to resend a probe.
In the CLI
(host) (config) #uplink enable
(host) (config) #uplink wired priority 200
(host) (config) #uplink cellular priority 100
(host) (config) #uplink health-check enable
(host) (config) #uplink health-check ip '192.0.2.2'
ArubaOS 6.5.3.x
| User Guide Adding Local Controllers | 936
Chapter 40
Voice and Video
n n
This chapter outlines the steps required to configure voice and video services on the Aruba controller for Voice over IP (VoIP) devices, including Session Initiation Protocol (SIP), Spectralink Voice Priority (SVP), H323, SCCP,
Vocera, Wi-Fi calling, Alcatel NOE phones, clients running Microsoft Lync Server, and Apple devices running the
Facetime application. As video and voice applications are more vulnerable to delay and jitter, the network infrastructure must be able to prioritize video and voice traffic over data traffic.
This chapter includes the following topics: n n n n
Voice and Video License Requirements on page 937
Configuring Voice and Video on page 937
Working with QoS for Voice and Video on page 946
Unified Communication and Collaboration on page 955
Understanding Extended Voice and Video Features on page 974
Advanced Voice Troubleshooting on page 998
Voice and Video License Requirements
The voice and video services require PEFNG licenses on the controller. For complete details on the required licenses, see
Software Licenses on page 78 .
Configuring Voice and Video
This section describes the steps required to set up and configure voice features on a controller:
1. Set up net services
2. Configure roles
3. Configure firewall settings for voice and video ALGs
4. Configure other parameters depending on the need and environment
Assigning voice traffic to the high priority queue is recommended when deploying voice over WLAN networks.
Voice ALG and Network Address Translation
Voice ALGs do not support Network Address Translation (NAT). This is due to the way NAT functions and the way IP addresses are embedded in the signaling messages. In a typical customer deployment, a call server is deployed within an internal network which eliminates the need for NAT.
In short, voice ALGs should not be enabled when voice clients are behind a NAT.
Setting up Net Services
You can either use the default net services and ports or you can create or modify net services.
Using Default Net Services
The following table lists the default net services and their ports:
ArubaOS 6.5.3.x
| User Guide Voice and Video | 937
Table 227: Default Voice Net Services and Ports
Net Service
Name
Protocol Port svc-sccp svc-sip-tcp svc-sip-udp
TCP
TCP
—
2000
5060
— svc-sips svc-noe svc-h323-udp svc-h323-tcp svc-vocera svc-svp
—
UDP
UDP
TCP
—
—
—
32512
1718, 1719
1720
—
None
ALG
SCCP
SIP
SIP
SIP
NOE
H.323
H.323
VOCERA
SVP
Creating Custom Net Services
You can use CLI to create or modify net services.
(host)(config)# netservice [service name] [protocol] [port] [alg]
To create an svc-noe service on UDP port 32522, enter:
(host) (config)# netservice svc-noe udp 32522 alg noe
Configuring User Roles
In the user-centric network, the user role of a wireless client determines its privileges and the type of traffic that it can send or receive in the wireless network. You can configure roles for clients that use mostly data traffic, such as laptops, and roles for clients that use mostly voice traffic, such as VoIP phones. Although there are different ways for a client to derive a user role, in most cases the clients using data traffic are assigned a role after they are authenticated through a method such as 802.1X, VPN, or captive portal. The user role for VoIP phones is derived from the OUI of their MAC addresses or the SSID to which they associate. Refer to
for details on how to create and configure a user role.
This section describes how to configure voice user roles with the required privileges and priorities. Aruba controller provides default user roles for all voice services. You can do one of the following: n n n
Use default user roles
Create or modify user roles
Use user-derivation roles
Using the Default User Role
The controller is configured with the default voice role. This role has the following settings: n n n
No limit on upload or download bandwidth
Default L2TP and PPTP pool
Maximum sessions: 65535
The following ACLs are associated with the default voice role:
938 | Voice and Video ArubaOS 6.5.3.x | User Guide
n n n n n n n n n n
SIP-ACL
NOE-ACL
SVP-ACL
VOCERA-ACL
SKINNY-ACL
H323-ACL
DHCP-ACL
TFTP-ACL
DNS-ACL
ICMP-ACL
For more details on the default voice role, enter the following command in the config mode on your controller:
(host)(config) #show rights voice
Creating or Modifying Voice User Roles
You can create roles for NOE, SIP, SVP, Vocera, SCCP, and H.323 ALGs. Use the WebUI or CLI to configure user roles for any of the ALGs.
In the WebUI
To configure user roles for ALGs:
1. Navigate to Configuration > Security > Access Control .
2. Select the Policies tab. Click Add to create a new policy.
3. For Policy Name , enter a name here.
4. For Policy Type , select Session .
5. Under Rules , click Add .
a. For IP Version , select IPv4 .
a. For Source , select any .
b. For Destination , select any .
c. For Service , select service, then the correct voice or video ALG service. See
and
for service names for all ALGs:
Table 228: Services for ALGs
ALG
NOE
Service Name
SIP
SVP
VOCERA
SCCP n n svc-noe sip-noe-oxo n n n svc-sips svc-sip-tcp svc-sip-udp svc-svp svc-vocera svc-sccp
ArubaOS 6.5.3.x
| User Guide Voice and Video | 939
ALG
H.323
DHCP
TFTP
ICMP
DNS
Service Name n n svc-h323-tcp svc-h323-udp svc-dhcp svc-tftp svc-icmp svc-dns
Table 229: Other Mandatory Services for the ALGs
ACL Service Name
DHCP
TFTP
ICMP
DNS svc-dhcp svc-tftp svc-icmp svc-dns d. For Action , select permit .
e. For Queue , select High .
f. Click Add . Repeat steps 1 to 5e to add more ALG services.
6. Click Apply .
7. Select the User Roles tab. Click Add to add a user role.
a. For Role Name , enter a name for the user role.
b. Under Firewall Policies , click Add .
c. Select the previously-configured policy name from the Choose from Configured Policies drop-down menu.
d. Click Done .
e. Under Firewall Policies , click Add .
f. Select control from the Choose from Configured Policies drop-down menu.
g. Click Done .
8. Click Apply .
In the CLI
To configure user roles for ALGs:
(host)(config) #ip access-list session <policy-name>
(host)(config-sess-<policy-name>) #any any <service-name> permit queue high
To map the policy name to the user role:
(host)(config) #user-role <role-name>
(host)(config-role) #session-acl <policy-name>
Replace the following strings: n n policy-name with a string that you want to identify the roles policy role-name with the name you want to identify the voice user role
940 | Voice and Video ArubaOS 6.5.3.x | User Guide
n service-name with any of the service names from
Using the User-Derivation Rules
The user role can be derived from attributes from the client’s association with an AP. For VoIP phones, you can configure the devices to be placed in their user role based on the SSID or the Organizational Unit Identifier
(OUI) of the client’s MAC address.
User-derivation rules are executed before the client is authenticated.
In the WebUI
To derive a role based on SSID:
1. Navigate to Configuration > Security > Authentication > User Rules .
2. Click Add to add a new set of derivation rules. Enter a name for the set of rules, and click Add . The name appears in the User Rules Summary list.
3. In the User Rules Summary list, select the name of the rule set to configure rules.
4. Click Add to add a rule. For Set Type , select Role from the drop-down menu.
5. For Rule Type , select ESSID .
6. For Condition , select equals .
7. For Value , enter the SSID used for the phones.
8. For Roles , select the user role you previously created.
9. Click Add .
10.Click
Apply .
In the CLI
To derive a role based on SSID:
(host)(config) #aaa derivation-rules user <name of rule-set>
(host) (user-rule) #set role condition essid equals <ssid-name> set-value <The value that the role/VLAN should be set to>
In the WebUI
To derive a role based on MAC OUI:
1. Navigate to Configuration > Security > Authentication > User Rules .
2. Click Add to add a new set of derivation rules. Enter a name for the set of rules, and click Add . The name appears in the User Rules Summary list.
3. In the User Rules Summary list, select the name of the rule set to configure rules.
4. Click Add to add a rule. For Set Type , select Role from the drop-down menu.
5. For Rule Type , select MAC Address .
6. For Condition , select contains .
7. For Value , enter the first three octets (the OUI) of the MAC address of the phones (for example, the
Spectralink OUI is 00:09:7a).
8. For Roles , select the user role you previously created.
9. Click Add .
10.Click
Apply .
ArubaOS 6.5.3.x
| User Guide Voice and Video | 941
In the CLI
To derive a role based on MAC OUI:
(host)(config) #aaa derivation-rules user <name of rule-set>
(host) (user-rule) #set role condition macaddr contains <xx:xx:xx:xx:xx:xx> set-value <The value that the role/VLAN should be set to>
Configuring Firewall Settings for Voice and Video ALGs
After configuring the user roles, you must configure the firewall settings for the voice and video Application-
Level Gateways (ALGs) to pass traffic securely through the Aruba devices.
In the WebUI
To enable the firewall settings for the ALGs:
1. Navigate to Configuration > Advanced Services > Stateful Firewall .
2. Enable the firewall settings for the ALGs: a. Select the Stateful SIP Processing check box for the SIP ALG.
b. Select the Stateful H.323 Processing check box for the H.323 ALG.
c. Select the Stateful SCCP Processing check box for the SCCP ALG.
d. Select the Stateful Vocera Processing check box for the Vocera ALG.
e. Select the Stateful UA Processing check box for the NOE ALG.
In the CLI
To enable the firewall settings for the SIP ALG:
(host) (config) #no firewall disable-stateful-sip-processing
To enable the firewall settings for the H.323 ALG:
(host) (config) #no firewall disable-stateful-h323-processing
To enable the firewall settings for the SCCP ALG:
(host) (config) #no firewall disable-stateful-sccp-processing
To enable the firewall settings for the Vocera ALG:
(host) (config) #no firewall disable-stateful-vocera-processing
To enable the firewall settings for the NOE ALG:
(host) (config) #no firewall disable-stateful-ua-processing
Additional Video Configurations
You can configure ArubaOS to reliably and efficiently stream video traffic over WLAN. This new method allows you to stream video traffic reliably without much distortion. To ensure that video data is transmitted reliably, dynamic multicast optimization techniques are used.
Although the dynamic multicast optimization conversion generates more traffic, that traffic is buffered by the
AP and delivered to the client when the client emerges from power-save mode.
Configuring Video over WLAN enhancements
To configure video over WLAN enhancements: n
Enable WMM on the SSID profile.
n n
Enable IGMP proxy or IGMP snooping.
Configure an ACL to set a DSCP value same as the wmm-vi-dscp value in the SSID profile for prioritizing the multicast video traffic.
942 | Voice and Video ArubaOS 6.5.3.x | User Guide
n n n
Enable dynamic multicast optimization under VAP profile .
Configure the dynamic multicast optimization threshold—The maximum number of high throughput stations in a multicast group. The optimization will stop if the number exceeds the threshold value.
Enable multicast rate optimization to support higher data rate for multicast traffic in the absence of dynamic multicast optimization. Dynamic multicast optimization takes precedence over multicast rate optimization up to the configured threshold value.
Configuring the Video Multicast Rate Optimization parameter overrides the configuration of BC/MC Rate
Optimization parameter for VI-tagged multicast traffic. Multicast traffic that is not VI-tagged behaves the same with
BC/MC as before. If multicast rate is not set, all traffic behaves the same.
n n n
Enable video aware scan on ARM profile —This ensures that AP does not scan when a video stream is active.
Optionally, you can configure and apply the WMM bandwidth management profile —The total bandwidth share should not exceed 100 percent.
Enable multicast shaping to shape the sudden traffic from the source.
Prerequisites n n
You will need the Policy Enforcement Firewall Next Generation (PEFNG) license to enable dynamic multicast optimization.
This feature is available only on 7000 Series and 7200 Series platforms.
In the WebUI
To configure video over WLAN enhancements:
1. Enable IGMP proxy or IGMP snooping on the controller.
To enable IGMP proxy: a. Navigate to Configuration > Network > IP . Under the IGMP settings, select the Enable IGMP checkbox.
b. Select the Proxy check box and then the appropriate value from the Interface drop down menu.
c. Click Apply .
To enable IGMP snooping: a. Navigate to Configuration > Network > IP . Under the IGMP settings, select the Enable IGMP check box.
b. Select the Snooping check box.
c. Click Apply .
2. Enable wireless multimedia and set a DSCP value for video traffic: a. Navigate to Configuration > Advanced Services > All Profiles .
b. Under the Profiles column, expand Wireless LAN > SSID Profile and select the profile name.
This example uses the default profile.
c. Click the Advanced tab and select the Wireless Multimedia (WMM) check box.
d. Enter the DSCP value (integer number) in the DSCP mapping for WMM video AC field .
e. Click Apply .
3. Create an ACL on the controller with the values equivalent to the DSCP mappings to prioritize the video traffic: a. Navigate to Configuration > Security > Access Control and click the Policies tab.
b. Click Add to create a new policy.
ArubaOS 6.5.3.x
| User Guide Voice and Video | 943
c. Enter the appropriate values under Rules to match the DSCP mapping values.
You can also add this ACL to any user role or port.
To apply the ACL to a user role: a. Navigate to Configuration > Security > Access Control page and click the User Roles tab.
b. Edit the user role and click Add under Firewall Policies .
c. Select the ACL from the Choose From Configured Policies drop-down menu and click the Done button.
d. Click Apply to save the configurations.
To apply the ACL to a port: a. Navigate to Configuration > Network > Port and select the upstream port.
b. Under the Firewall Policy drop-down menu, select the ACL.
c. Click Apply .
4. Configure dynamic multicast optimization for video traffic on a virtual AP profile:
Under the Profiles column, expand Wireless LAN > Virtual AP Profile and select the profile name. This example uses the default profile. In the Profile Details section, select the Dynamic Multicast
Optimization (DMO) option and enter the threshold value.
5. Configure multicast rate optimization for the video traffic: a. Navigate to Configuration > Advanced Services > All Profiles .
b. Under the Profiles column, expand Wireless LAN > SSID Profile and select the profile name.
c. Click the Advanced tab and select the BC/MC Rate Optimization check box.
d. Select an option from the Video Multicast Rate Optimization drop-down menu.
e. Click Apply .
Configuring the Video Multicast Rate Optimization parameter overrides the configuration of BC/MC Rate
Optimization parameter for VI-tagged multicast traffic. Multicast traffic that is not VI-tagged behaves the same with
BC/MC as before. If multicast rate is not set, all traffic behaves the same.
6. Configure ARM scanning for video traffic:
Under the Profiles column, expand RF Management > Adaptive Radio Management (ARM) Profile and select the profile name. This example uses the default profile. Select the Video Aware Scan option and click Apply .
7. Configure and apply bandwidth management profile:
Under the Profiles column, expand Virtual AP > [profile-name] > WMM Traffic Management Profile . In the Profile Details section, select the profile name from the drop down list box. Select the Enable
Shaping Policy option and enter the bandwidth share values. Click Apply .
This step is optional.
Ensure that you configure the WMM traffic management profile to the virtual AP profile, if you have configured the virtual AP traffic management profile.
After you configure the WMM bandwidth management profile, apply it to the virtual AP profile.
8. Enable multicast shaping on the firewall: a. Navigate to Configuration > Advanced Services > Stateful Firewall .
b. Click the Global Setting tab and select the Multicast automatic shaping check box.
c. Click Apply .
944 | Voice and Video ArubaOS 6.5.3.x | User Guide
In the CLI
To configure the video over WLAN enhancements:
1. Enable IGMP proxy or IGMP snooping on the controller.
To enable IGMP proxy:
(host) (config) #interface vlan <id>
(host) (config-subif)#ip igmp proxy gigabitethernet <slot/module/port>
To enable IGMP snooping:
(host) (config) #interface vlan <id>
(host) (config-subif)#ip igmp snooping
2. Enable wireless multimedia and set a DSCP value for video traffic:
(host) (config)#wlan ssid-profile default
(host) (ssid-profile “default”)#wmm
(host) (ssid-profile “default”)#wmm-vi-dscp <value>
Example:
(host) (ssid-profile “default”)#wmm-vi-dscp 40
Setting the DSCP value tags the content as video stream that the APs can recognize.
3. Create an ACL on the controller with the values equivalent to the DSCP mappings to prioritize the video traffic.
Example: The following ACL prioritizes the multicast traffic from the specified multicast group on the controller. You can also add this ACL to any user role or port:
(host) (config-sess-mcast_video_acl)#any network 224.0.0.0 255.0.0.0 any permit to 40 queue high 802.1p 5 a. To apply the ACL to a user role:
This example uses the user role authenticated .
(host) (config) #user-role authenticated access-list session mcast_video_acl b. To apply the ACL to a port:
(host) (config) #interface gigabitethernet <slot/module/port>
(host) (config-if)#ip access-group mcast_video_acl session
4. Configure dynamic multicast optimization for video traffic on a virtual AP profile:
(host) (config)#wlan virtual-ap default
(host) (Virtual AP Profile “default”)#dynamic-mcast-optimization
5. Configure the dynamic multicast optimization threshold value:
(host) (config) #dynamic-mcast-optimization-thresh 6
6. Configure multicast rate optimization for video traffic:
(host) (config) #wlan ssid-profile default
(host) (SSID Profile "default") #mcast-rate-opt
7. Configure ARM scanning for video traffic:
In the default RF ARM profile, enable the video aware scan option. This prevents APs from scanning when a video traffic is active:
(host) (config) #rf arm-profile default
(host) (Adaptive Radio Management (ARM) profile "default") #video-aware-scan
8. Configure and apply a bandwidth management profile.
Ensure that you configure the WMM traffic management profile to the virtual AP profile, if you have configured the virtual AP traffic management profile.
a. Enable a bandwidth shaping policy so that the allocated bandwidth share is appropriately used:
(host) (config) #wlan wmm-traffic-management-profile default
(host) (WMM Traffic management profile "default") # enable-shaping
ArubaOS 6.5.3.x
| User Guide Voice and Video | 945
b. Set a bandwidth percentage for the following categories:
(host) (WMM Traffic management profile "default") # background 10
(host) (WMM Traffic management profile "default") # best-effort 20
(host) (WMM Traffic management profile "default") # video 50
(host) (WMM Traffic management profile "default") # voice 20
After you configure the WMM bandwidth management profile, apply it to the virtual AP profile:
(host) (config) #wlan virtual-ap default
(host) (Virtual AP profile "default") #wmm-traffic-management-profile default
9. Enable multicast shaping on the firewall:
(host) (config) #firewall shape-mcast
Working with QoS for Voice and Video
QoS settings for voice and video applications are configured when you configure firewall roles and policies.
Understanding VoIP Call Admission Control Profile
VoIP call admission control prevents any single AP from becoming congested with voice calls. You configure call admission control options in the VoIP Call Admission Control profile, which you apply to an AP group or a specific AP.
In the WebUI
To configure a VoIP Call Admission Control profile:
1. Navigate to Configuration > WIRELESS > AP Configuration . Select either AP Group or AP Specific .
n n
If you select AP Group , click Edit for the AP group name for which you want to configure VoIP CAC.
If you select AP Specific , select the name of the AP for which you want to configure VoIP CAC.
2. In the Profiles list, expand the QoS menu, then select the VoIP Call Admission Control profile.
3. In the Profile Details window pane, click the VoIP Call Admission Control profile drop-down list and select the profile you want to edit.
-or-
To create a new profile, click the VoIP Call Admission Control profile drop-down list and select New . Enter a new profile name in the field to the right of the drop-down list. You cannot use spaces in VoIP profile names.
4. Configure your desired VoIP Call Admission Control profile settings.
describes the parameters you can configure in this profile:
Table 230: VoIP Call Admission Control Configuration Parameters
Parameter
VoIP Call Admission Control
Description
VoIP Bandwidth based CAC
VoIP Call Capacity
Select the Voip Call Admission Control check box to enable Wi-Fi VoIP
Call Admission Control features.
Select the VoIP Bandwidth based CAC check box to enable call admission controls based upon bandwidth. If this option is not selected, call admission controls are based on call counts.
The maximum number of simultaneous calls that the AP radio can handle.
You can use the bandwidth calculator in the WebUI to calculate the call capacity. To access the bandwidth calculator, navigate to Configuration >
Management > Bandwidth Calculator . Default value: 10.
946 | Voice and Video ArubaOS 6.5.3.x | User Guide
Parameter Description
VoIP Bandwidth Capacity (kbps) Enter a rate from 1 to 600000 (inclusive) to specify the maximum bandwidth rate that a radio can handle, in kbps. Default value is 2000 kbps.
VoIP Call Handoff Reservation Specify the percentage of call capacity reserved for mobile VoIP clients on an active call. Default value is 20%.
VoIP Send SIP 100 Trying
VoIP Disconnect Extra Call
The SIP invite call setup message is time-sensitive, as the originator retries the call as quickly as possible if it does not proceed. You can direct the controller to immediately reply to the call originator with a “SIP 100 trying” message to indicate that the call is proceeding and to avoid a possible timeout. This is useful in conditions where the SIP invite may be redirected through a number of servers before reaching the controller.
Select the VoIP Send SIP 100 Trying check box to send "SIP 100-trying" messages to a call originator to indicate that the call is proceeding. This is a useful option when the SIP invite is directed through many servers before reaching the controller.
In the VoIP Call Admission Control (CAC) profile, you can limit the number of active voice calls allowed on a radio. This feature is disabled by default.
When you enable the disconnect extra call feature, the system monitors the number of active voice calls, and if the defined threshold is reached, any new calls are disconnected. The AP denies association requests from a device that is on call.
To enable this feature, select the VoIP Disconnect Extra Call check box.
You also need to enable call admission control in this profile.
VOIP TSPEC Enforcement
VOIP TSPEC Enforcement
Period
A WMM client can send a Traffic Specification (TSPEC) signaling request to the AP before sending traffic of a specific AC type, such as voice. You can configure the controller so that the TSPEC signaling request from a client is ignored if the underlying voice call is not active. This feature is disabled by default. If you enable this feature, you can also configure the time duration within which the station should start the voice call after sending the TSPEC request (the default is one second).
Select the VoIP TSPEC Enforcement check box to validate TSPEC requests for CAC.
Select the maximum time, in seconds, for the station to start the call after the TSPEC request.
ArubaOS 6.5.3.x
| User Guide Voice and Video | 947
Parameter
VoIP Drop SIP Invite and send status code (client)
VoIP Drop SIP Invite and send status code (server)
Allow Idle VOIP Client
Description
Click the VoIP Drop SIP Invite and send status code (client) dropdown list and select one of the following status codes to be sent back to the client: n n n n
480 : Temporary Unavailable
486 : Busy Here
503 : Service Unavailable none : Don't send SIP status code
Click the VoIP Drop SIP Invite and send status code (client) drop-down list and select one of the following status codes to be sent back to the server: n
480 : Temporary Unavailable n n n
486 : Busy Here
503 : Service Unavailable none : Don't send SIP status code
If enabled, the AP allows idle voice clients to associate even if the AP reaches its call capacity limit.
If disabled, the AP rejects idle voice clients to associate if the AP reaches its call capacity limit. However, the AP continues to allow active (in-call) and non-voice clients to associate.
This setting is disabled by default.
5. Click Apply .
In the CLI
To configure a VoIP Call Admission Control profile:
(host)(config) #wlan voip-cac-profile <profile> allow-idle-voip-client bandwidth-cac bandwidth-capacity <bandwidth-capacity> call-admission-control call-capacity call-handoff-reservation <percent> disconnect-extra-call send-sip-100-trying send-sip-status-code client|server <code> wmm-tspec-enforcement wmm-tspec-enforcement-period <seconds>
Understanding Wi-Fi Multimedia
Wi-Fi Multimedia (WMM), is a Wi-Fi Alliance specification based on the IEEE 802.11e wireless Quality of Service
(QoS) standard. WMM works with 802.11a, b, g, n, and ac physical layer standards.
WMM supports four access categories (ACs): voice, video, best effort, and background.
shows the mapping of the WMM access categories to 802.1p priority values. The 802.1p priority value is contained in a two-byte QoS control field in the WMM data frame.
948 | Voice and Video ArubaOS 6.5.3.x | User Guide
Table 231: WMM Access Category to 802.1p Priority Mapping
Priority
Lowest
Highest
0
3
4
1
2
5
6
7
802.1p Priority WMM Access Category
Background
Best effort
Video
Voice
In non-WMM, or hybrid environments where some clients are not WMM-capable, Aruba uses voice and best effort to prioritize traffic from these clients.
Unscheduled Automatic Power Save Delivery (U-APSD) is a component of the IEEE 802.11e standard that extends the battery life on voice over WLAN devices. When enabled, clients trigger the delivery of buffered data from the AP by sending a data frame.
For the environments in which the wireless clients support WMM, you can enable both WMM and U-APSD in the SSID profile.
Enabling WMM
You can use the WebUI or CLI to enable WMM for wireless clients.
In the WebUI
To enable WMM for wireless clients:
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. Select either the AP Group or AP Specific tab. Click Edit for the AP group or AP name.
3. In the Profiles list, select Wireless LAN , then Virtual AP , then the applicable virtual AP profile. Select the
SSID profile.
4. In the Profile Details , select the Advanced tab.
5. Select the Wireless Multimedia (WMM) option. Or, select the Wireless Multimedia U-APSD (WMM-
UAPSD) Powersave option if you want to enable WMM in power save mode.
6. Click Apply .
In the CLI
To enable WMM for wireless clients:
(host)(config) #wlan ssid-profile <pr ofile> wmm wmm-uapsd
Configuring WMM AC Mapping
The IEEE 802.11e standard defines the mapping between WMM ACs and Differentiated Services Code Point
(DSCP) tags. The WMM AC mapping commands allow you to customize the mapping between WMM ACs and
ArubaOS 6.5.3.x
| User Guide Voice and Video | 949
DSCP tags to prioritize various traffic types. You apply and configure WMM AC mappings to a WMM-enabled
SSID profile.
Ensure that you enable WMM for legacy APs for the mapping to take effect. For 802.11n APs, ensure that you enable either WMM or high throughput.
DSCP classifies packets based on network policies and rules, not priority. The configured DSCP value defines per hop behaviors (PHBs). The PHB is a 6-bit value added to the 8-bit Differentiated Services (DS) field of the IP packet header. The PHB defines the policy and service applied to a packet when traversing the network. You configure these services in accordance with your network policies.
shows the default WMM AC to
DSCP decimal mappings and the recommended WMM AC to DSCP mappings.
Table 232: WMM Access Category to DSCP Mappings
DSCP Decimal Value
8
16
0
24
32
40
48
56
WMM Access Category
Background
Best effort
Video
Voice
By customizing WMM AC mappings, both the controller and AP maintain a customized WMM AC mapping table for each configured SSID profile. All packets received are matched against the entries in the mapping table and prioritized accordingly. The mapping table contains information for upstream (client to AP) and downstream
(AP to client) traffic.
In earlier releases, the default mappings exist for all SSIDs. After you customize a WMM AC mapping and apply it to the SSID, the controller overwrites the default mapping values and uses the configured values . If a controller is upgraded to 6.2 from an older version, the default and the user configured WMM-DSCP mappings in the existing SSID profiles are retained. There are no default mappings for a newly created SSID profile and for a factory default controller running 6.2 image.
When planning your mappings, make sure that any immediate switch or router does not have conflicting
802.1p or DSCP configurations/mappings. If this occurs, your traffic may not be prioritized correctly.
To view the mapping settings, use the following command:
(host) #show wlan ssid-profile <profile>
In the WebUI
To map WMM AC with DSCP:
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. Select either the AP Group or AP Specific tab. Click Edit for the AP group or AP name.
950 | Voice and Video ArubaOS 6.5.3.x | User Guide
3. In the Profiles list, select Wireless LAN , then Virtual AP , then the applicable virtual AP profile. Select the
SSID profile.
4. In the Profile Details , select the Advanced tab.
5. Scroll down to the Wireless Multimedia (WMM) option. Select this option.
6. Modify the DSCP mapping settings, as needed: l
DSCP mapping for WMM voice AC—DSCP used to map voice traffic l l
DSCP mapping for WMM video AC—DSCP used to map video traffic
DSCP mapping for WMM best-effort AC—DSCP used to map best-effort traffic l
DSCP mapping for WMM background AC—DSCP used to map background traffic
7. Click Apply .
In the CLI
To map WMM AC with DSCP:
(host)(config) #wlan ssid-profile <profile> wmm-be-dscp <best-effort> wmm-bk-dscp <background> wmm-vi-dscp <video> wmm-vo-dscp <voice>
The following enhancements have been made to the WMM-DSCP mapping functionality: n n n n n n n
When a controller is upgraded to the 6.2 version from an older version, the default and the user configured
WMM-DSCP mappings in the existing SSID profiles are retained.
Default mappings are not there for a newly created SSID profile and for a factory default controller a running 6.2 image.
If the mapping has no value, the original DSCP for upstream traffic is retained.
The maximum number of values that can be configured for WMM-DSCP is 8.
For the upstream traffic, if the mapping exists and incoming DSCP value matches one of the mapped values, then the DSCP value is retained.
For the upstream traffic, if the mapping exists and incoming DSCP value does not match any of the mapped values, then the DSCP value is overwritten with the first value in the WMM- DSCP list
For Wireless to Wireless Traffic: If the AC of the incoming packet has no mapping and the incoming DSCP value is mapped to a different AC, then the DSCP value is retained and WMM priority is changed to the corresponding AC where incoming DSCP is mapped.
Configuring DSCP Priorities
You can configure DSCP priorities for WMM packets in the following ways: n n n configure the DSCP mappings in the SSID profile set a ToS value in the ACL set the ToS value and the 802.1p priority in the ACL
Setting a ToS value in the ACL overrides the default DSCP mappings configured in the SSID profile. Configuring a DSCP priority in both the L2 and L3 header prioritizes the WMM packets with the higher value.
For example, you can have different ToS values set for different voice traffic in a network. To prioritize all of them in the voice queue, we can set the 802.1p priority to voice.
Consider a deployment where Cisco Softphone, Lync, and Scopia are configured with the following DSCP : n n
Cisco Softphone - DSCP 46
Lync - DSCP 44
ArubaOS 6.5.3.x
| User Guide Voice and Video | 951
n
Scopia - DSCP 42
In the absence of doing anything, all of the DSCP above would map into the Video queue. To map all the traffic into voice queue, you can use the following ACL configuration: wlan ssid-profile VOICE wmm-vo-dscp 46 ip access-list session VOICE any destination [LYNC_SERVER] [LYNC_PORTS] permit tos 44 dot1p-priority 6 any destination [SCOPiA_SERVER] [SCOPIA _PORTS] permit tos 42 dot1p-priority 6
You must know the ports on which each traffic is sent so that the correct traffic is identified.
Configuring Dynamic WMM Queue Management
Traditional wireless networks provide all clients with equal bandwidth access. However, delays or reductions in throughput can adversely affect voice and video applications, resulting in disrupted VoIP conversations or dropped frames in a streamed video. Thus, data streams that require strict latency and throughput need to be assigned higher traffic priority than other traffic types.
The Wi-Fi Alliance defined the Wi-Fi Multimedia (WMM) standard in response to industry requirements for
Quality of Service (QoS) support for multimedia applications for wireless networks. This is defined as per the
IEEE 802.11e standards.
WMM requires: n n n the access point be Wi-Fi Certified and has WMM enabled the client device be Wi-Fi Certified the application support WMM
Enhanced Distributed Channel Access
WMM provides media access prioritization through Enhanced Distributed Channel Access (EDCA). EDCA defines four access categories (ACs) to prioritize traffic: voice, video, best effort, and background. These ACs correspond to 802.1p priority tags, as shown in
.
Table 233: WMM Access Categories and 802.1p Tags
WMM Access Category Description
Voice
Video
Best Effort
Background
Highest priority
Prioritize video traffic above other data traffic
Traffic from legacy devices or traffic from applications or devices that do not support QoS
Low priority traffic (file downloads, print jobs)
802.1p Tag
7, 6
5, 4
0, 3
2, 1
While the WMM ACs designate specific types of traffic, you can determine the priority of the ACs. For example, you can choose to give video traffic the highest priority. With WMM, applications assign data packets to an AC.
In the client, the data packets are then added to one of the transmit queues for voice, video, best effort, or background.
WMM is an extension to the Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) protocol’s
Distributed Coordination Function (DCF). The collision resolution algorithm responsible for traffic prioritization depends on the following configurable parameters for each AC: n arbitrary inter-frame space number (AIFSN)
952 | Voice and Video ArubaOS 6.5.3.x | User Guide
n minimum and maximum contention window (CW) size
For each AC, the backoff time is the sum of the AIFSN and a random value between 0 and the CW value. The AC with the lowest backoff time is granted the opportunity to transmit (TXOP). Frames with the highest-priority AC are more likely to get TXOP, because they tend to have the lowest backoff times (a result of having smaller
AIFSN and CW parameter values). The value of the CW varies through time as the CW doubles after each collision up to the maximum CW. The CW is reset to the minimum value after successful transmission. In addition, you can configure the TXOP duration for each AC.
On the controller, you configure the AC priorities in the WLAN EDCA parameters profile. There are two sets of
EDCA profiles you can configure: n n
AP parameters affecting traffic from the AP to the client.
STA parameters affecting traffic from the client to the AP.
Using the WebUI to configure EDCA parameters
Use the following procedure to define an Enhanced Distributed Channel Access (EDCA) profile for APs or for clients (stations).
1. Navigate to the Configuration > AP Configuration page. Select either the AP Group tab or AP Specific tab: n
If you selected AP Group , click Edit for the AP group name for which you want to configure EDCA parameters.
n
If you selected AP Specific , select the name of the AP for which you want to configure EDCA parameters.
2. Under Profiles , select the Wireless LAN , then Virtual AP . In the Virtual AP list, select the appropriate virtual AP.
3. Expand the SSID profile. Select the EDCA Parameters Station or EDCA Parameters AP profile.
4. Configure your desired EDCA Profile Parameters.
describes the parameters you can configure in this profile.
ArubaOS 6.5.3.x
| User Guide Voice and Video | 953
Table 234: EDCA Parameters Station and EDCA Parameters AP Profile Settings
Parameter
Best Effort
Description
Background
Video
Voice
Set the following parameters to define the best effort queue: n aifsn : arbitrary inter-frame space number. Range: 1-15.
n n n n ecw-max : the exponential (n) value of the maximum contention window size, as expressed by 2 n -1. A value of 4 computes to 2 4 -1 = 15. Range: 1-15.
ecw-min : the exponential (n) value of the minimum contention window size, as expressed by 2 n -1. A value of 4 computes to 2 4 -1 = 15. Range: 0-15.
txop : transmission opportunity, in units of 32 microseconds. Divide the desired transmission duration by 32 to determine the value to configure. For example, for a transmission duration of 3008 microseconds, enter 94 (3008/32). Range: 0-2047.
acm : this parameter specifies mandatory admission control. With a value of 1 , the client reserves the access category through traffic specification (TSPEC) signaling.
A value of 0 disables this option.
Set the following parameters to define the background queue: n aifsn : arbitrary inter-frame space number. Range: 1-15.
n n n n ecw-max : the exponential (n) value of the maximum contention window size, as expressed by 2 n -1. A value of 4 computes to 2 4 -1 = 15. Range: 1-15.
ecw-min : the exponential (n) value of the minimum contention window size, as expressed by 2 n -1. A value of 4 computes to 2 4 -1 = 15. Range: 0-15.
txop : transmission opportunity, in units of 32 microseconds. Divide the desired transmission duration by 32 to determine the value to configure. For example, for a transmission duration of 3008 microseconds, enter 94 (3008/32). Range: 0-2047.
acm : this parameter specifies mandatory admission control. With a value of 1 , the client reserves the access category through traffic specification (TSPEC) signaling.
A value of 0 disables this option.
Set the following parameters to define the background queue: n n n aifsn : trbitrary inter-frame space number. Range: 1-15.
ecw-max : The exponential (n) value of the maximum contention window size, as expressed by 2 n -1. A value of 4 computes to 2 4 -1 = 15. Range: 1-15.
ecw-min : the exponential (n) value of the minimum contention window size, as expressed by 2 n -1. A value of 4 computes to 2 4 -1 = 15. Range: 0-15.
n n txop : transmission opportunity, in units of 32 microseconds. Divide the desired transmission duration by 32 to determine the value to configure. For example, for a transmission duration of 3008 microseconds, enter 94 (3008/32). Range: 0-2047.
acm : this parameter specifies mandatory admission control. With a value of 1 , the client reserves the access category through traffic specification (TSPEC) signaling.
A value of 0 disables this option.
Set the following parameters to define the background queue: n aifsn : trbitrary inter-frame space number. Range: 1-15.
n n ecw-max : the exponential (n) value of the maximum contention window size, as expressed by 2 n -1. A value of 4 computes to 2 4 -1 = 15. Range: 1-15.
ecw-min : the exponential (n) value of the minimum contention window size, as expressed by 2 n -1. A value of 4 computes to 2 4 -1 = 15. Range: 0-15.
n n txop : transmission opportunity, in units of 32 microseconds. Divide the desired transmission duration by 32 to determine the value to configure. For example, for a transmission duration of 3008 microseconds, enter 94 (3008/32). Range: 0-2047.
acm : this parameter specifies mandatory admission control. With a value of 1 , the client reserves the access category through traffic specification (TSPEC) signaling.
A value of 0 disables this option.
5. Click Apply .
Using the CLI to configure EDCA parameters
Use the following commands: wlan edca-parameters-profile {ap|station} <profile>
{background | best-effort | video | voice}
954 | Voice and Video ArubaOS 6.5.3.x | User Guide
[acm][aifsn <number>] [ecw-max <exponent> [ecw-min <exponent>] [txop <number>]
To associate the EDCA profile instance to a SSID profile: wlan ssid-profile <profile> edca-parameters-profile {ap|sta} <profile>
Enabling WMM Queue Content Enforcement
WMM queue content enforcement is a firewall setting that you can enable to ensure that the voice priority is used for voice traffic. When you enable this feature, if traffic to or from the user is inconsistent with the associated QoS policy for voice, the traffic is reclassified to best effort and data path counters incremented. If
TSPEC admission were used to reserve bandwidth, then TSPEC signaling informs the client that the reservation is terminated.
You can use the WebUI or CLI to enable WMM queue content enforcement.
In the WebUI
1. Navigate to the Configuration > Advanced Services > Stateful Firewall page.
2. Select Enforce WMM Voice Priority Matches Flow Content .
3. Click Apply .
In the CLI
Use the following command: firewall wmm-voip-content-enforcement
Unified Communication and Collaboration
This section describes the Unified Communication and Collaboration (UCC) feature. The Unified
Communications Manager (UCM) is the core solution component of this feature. UCC addresses the onslaught of mobile devices that use voice, video, and collaboration applications. UCC solution reduces the cost of infrastructure for enterprise communication and collaboration.
The UCC feature requires the PEFNG license.
UCC continues to support all existing functionality provided by ArubaOS 6.3.x. This section includes the following sub-sections: n n n n n n n n
Microsoft® Lync/Skype for Business Visibility and Granular QoS Prioritization on page 955
UCC Dashboard in the WebUI on page 964
Viewing UCC Information on page 968
UCC-AirWave Integration on page 969
UCC Call Quality Metrics on page 971
Changes to Call Admission Control on page 973
Troubleshooting and Log Messages on page 973
Microsoft® Lync/Skype for Business Visibility and Granular QoS Prioritization
ArubaOS provides a seamless user experience for Microsoft® Lync/Skype for Business users using voice or video calls, desktop sharing, and file transfer in a wireless environment. Microsoft Lync/Skype for Business is an enterprise solution for UCC. It provides support for voice, video, desktop-sharing, and file-transfer.
ArubaOS 6.5.3.x
| User Guide Voice and Video | 955
Microsoft Lync/Skype for Business uses SIP over TLS for call signaling.
n n n n
ArubaOS provides value added services such as prioritization of Lync/Skype for Business sessions, call quality metrics, and visibility by implementing Lync/Skype for Business Application Layer Gateway (ALG). This solution also provides a dedicated visibility and troubleshooting framework that allows network administrators to finetune and troubleshoot Lync/Skype for Business traffic flow in the network.
As Microsoft Lync/Skype for Business deployments are more widely implemented on wireless networks, it is important to provide Quality of Service (QoS) for Lync/Skype for Business voice or video calls, desktop sharing, and file transfer so that there is no visible difference in the user experience between wireless and wired networks. Lync/Skype for Business ALG offers an enriched solution in terms of QoS, scalable voice, video, desktop-sharing, and file-transfer. The ALG based solution provides the following value-added services: n n n n n
Call Quality Metrics : Call quality details such as Mean Opinion Score (MOS), delay, jitter, and packet loss.
Call Priority : Call priority is provided for all Lync/Skype for Business sessions irrespective of Call Admission
Control (CAC) limit. Starting from ArubaOS 6.4.x, Lync/Skype for Business sessions are prioritized based on session-specific requirements. Voice calls get highest priority, followed by video and desktop sharing. Filetransfer gets the least priority.
Call and Client information : Details about Lync/Skype for Business call types and statistics through CLI.
The commands are discussed later in this section.
Deterministic Solution : A dedicated visibility and troubleshooting framework that allows network administrators to fine-tune and troubleshoot Lync/Skype for Business traffic flow in the network. This solution provides an enriched performance which uses Deep Packet Inspection (DPI).
Call Admission Control : Starting from ArubaOS 6.4.x, Lync/Skype for Business sessions do not come under the purview of call count based CAC and bandwidth based CAC. For more information, see
Changes to Call Admission Control on page 973
.
To take advantage of ArubaOS 6.4.x UCC Lync/Skype for Business ALG, it is recommended to use the
Microsoft Lync/Skype for Business SDN Interface. ArubaOS supports all versions of Lync SDN Interface up to version 2.4.1. Microsoft Lync/Skype for Business SDN Interface works with Microsoft Lync/Skype for Business server to export details about voice or video calls, desktop-sharing, and file-transfer to Aruba controller’s Web server. The communication between the Lync/Skype for Business SDN Interface and Web server occurs over
HTTP or HTTPS.
This section includes the following sub-sections: n n n n n n
Lync/Skype for Business ALG Compatibility Matrix on page 957
Configuration Prerequisites on page 957
Skype For Business SDN Interface 2.4.1 Support on page 957
Skype For Business SDN Interface 2.2 Support on page 957
Lync SDN API 2.1 Support on page 957
Lync/Skype for Business SDN Interface - ArubaOS Compatibility Matrix on page 958
Configuring Lync/Skype for Business ALG on page 958
Viewing Lync/Skype for Business ALG Statistics using the CLI
Unified Communication and Collaboration on page 955
Troubleshooting Lync/Skype for Business ALG Issues on page 963
956 | Voice and Video ArubaOS 6.5.3.x | User Guide
Lync/Skype for Business ALG Compatibility Matrix
The following table displays the Lync/Skype for Business clients that support voice, video, desktop sharing, and file transfer applications in ArubaOS 6.4.x:
Table 235: Compatibility Matrix
Lync/Skype for
Business Client
Android iOS
OS X (Mac)
Windows
Lync Server 2010
No
No
Yes
Yes
Lync Server 2013
Yes
Yes
Yes
Yes
Skype for Business
2015
Yes
Yes
Yes
Yes
Configuration Prerequisites n n
Microsoft Lync/Skype for Business server supporting Lync/Skype for Business SDN Interface versions up to
2.4.1.
Aruba controller running ArubaOS 6.4.x. If you are running Lync/Skype for Business Interface 2.2, the controller must run ArubaOS 6.4.4.0 or later.
If your setup does not have a Lync/Skype for Business SDN Interface, use Media Classification as described in
Understanding Extended Voice and Video Features on page 974 .
Skype For Business SDN Interface 2.4.1 Support
In ArubaOS 6.5.0.0, the controller supports Skype For Business SDN Interface 2.4.1. There is no significant changes that impact the controller.
Skype For Business SDN Interface 2.2 Support
In ArubaOS 6.4.4.0, the controller supports Skype For Business SDN Interface 2.2. This API provides an interface to the controller to access network diagnostic data in order to monitor Lync/Skype for Business traffic and optimize the quality of service. This API applies to Lync Server 2010, 2013, and Skype for Business
2015.
Lync SDN API 2.1 Support
In ArubaOS 6.4.3.0, the controller supports Lync SDN API version 2.1. As part of Lync SDN API 2.1, Lync SDN
Manager (LSM) sends In-Call quality update messages to the controller. The In-Call quality update message provides visibility on the end-to-end delay, jitter, packet loss, and MOS periodically for VoIP calls that are active.
In earlier versions of Lync SDN API, LSM sent end-to-end quality updates to the controller at the end of a VoIP call.
Certain Lync/Skype for Business clients can generate in-call quality reports that can be processed by the Lync SDN server and forwarded to the controller for further processing. For a list of Lync/Skype for Business clients that support In-Call quality report, contact Microsoft® support.
Some characteristics of the In-Call quality reports are as follows: n
Lync/Skype for Business client supporting this enhancement sends an InCallQuality message every 35 seconds (by default). Lesser messages are sent for stable VoIP calls.
ArubaOS 6.5.3.x
| User Guide Voice and Video | 957
n n n
InCallQuality message provides cumulative values of call quality metrics like delay, jitter, packet loss, MOS, and more while the VoIP call is active.
In a good call quality, the controller receives only a single InCallQuality message after the first period. No further InCallQuality messages are sent until the end of call QualityUpdate message.
If the call quality fluctuates and crosses the threshold, these events are collected and the sent message is delayed until the least period of time has passed since the last InCallQuality message is sent.
Lync/Skype for Business SDN Interface - ArubaOS Compatibility Matrix
The following table displays the version compatibility matrix between Lync/Skype for Business SDN Interface and ArubaOS.
Table 236: Lync/Skype for Business SDN Interface - ArubaOS Compatibility Matrix
Lync/Skype for Business SDN
Interface Version
2.0
2.1.1
2.2
2.4.1
Backward Compatibility
True
False
NA
NA
NA
ArubaOS
Version
6.3.1.x, 6.4.1.x,
6.4.2.x, and 6.5.x
6.4.3.x
6.4.3.x, 6.4.4.x, and 6.5.x
6.4.3.x, 6.4.4.x, and 6.5.x
6.4.3.x, 6.4.4.x, and 6.5.x
Configuring Lync/Skype for Business ALG
This section describes the procedures to configure Lync/Skype for Business ALG on the controller: n n n n n
Configuring the Lync/Skype for Business Listening Port on page 958
Configuring Lync/Skype for Business ALG Status on page 959
Dynamically Open Firewall for UCC Clients using STUN on page 959
Configuring Per User Role Lync/Skype for Business Call Prioritization on page 960
Disable Media Classification on page 962
When upgrading from ArubaOS 6.x to 6.4: n n
Lync/Skype for Business ALG is enabled by default.
If media classification is configured before upgrading to ArubaOS 6.4, disable media classification.
Configuring the Lync/Skype for Business Listening Port
Configure the port number on which Microsoft Lync/Skype for Business SDN Interface sends HTTP or HTTPS call information (XML) messages to Aruba controller.
Before you configure Lync/Skype for Business listening port, disable classify-media . To disable classify-media , see
Disable Media Classification on page 962
.
In the WebUI
1. Navigate to the Configuration > Management > General page.
958 | Voice and Video ArubaOS 6.5.3.x | User Guide
2. Under the Configure Skype4B section, select the HTTP or HTTPS protocol from the drop-down list and enter the port number in the Web Skype4B listening port text box.
The port range is from 1024 to 65535.
The Web Skype4B listening port is automatically permitted by the firewall. The user does not have to explicitly define a firewall policy to permit this port.
3. Click Apply .
In the CLI
Use the following command:
(host) (config) #web-server profile
Listen Lync XML messages on HTTP:
(host) (Web Server Configuration) #web-skype4b-listen-port http <listen-port>
Or
Listen Lync XML messages on HTTPS:
Before configuring the controller to receive Lync/Skype for Business SDN Interface messages using HTTPS, a server certificate must be generated and installed on the controller. Server certificate can be generated either by the controller or Certificate Authority (CA). For more information, see
Obtaining a Server Certificate on page 866 .
(host) (Web Server Configuration) #web-skype4b-listen-port https <listen-port>
To verify if the port is automatically permitted by the firewall, use the following command:
(host) #show firewall-cp
Configuring Lync/Skype for Business ALG Status
Configure the controller to read Secure SIP signaling messages sent by the Lync/Skype for Business clients on port 5061. You can enable or disable Stateful SIPS processing using the following CLI commands. This is enabled by default.
Before you configure Lync/Skype for Business ALG status, disable classify-media . To disable classify-media , see
Disable Media Classification on page 962
.
Enabling Lync/Skype for Business ALG
(host) (config) #no firewall disable-stateful-sips-processing
Disabling Lync/Skype for Business ALG
(host) (config) #firewall disable-stateful-sips-processing
Dynamically Open Firewall for UCC Clients using STUN
Prior to ArubaOS 6.4, the administrator explicitly added ACLs in the user role to allow Lync/Skype for Business traffic on the controller. Starting with ArubaOS 6.4, the controller automatically allows firewall sessions for
Lync/Skype for Business voice and video calls. Firewall sessions for Lync/Skype for Business desktop-sharing and file-transfer are not allowed. The administrator should manually open a range of TCP ports under the user role to allow Lync/Skype for Business desktop-sharing and file-transfer traffic. To allow a specific range of ports in the user role, refer the Microsoft Technet article which describes the port ranges used by Lync/Skype for
Business clients and servers.
Before media transmission, a Lync/Skype for Business client initiates a Session Traversal Utilities for NAT
(STUN) connectivity check. Sessions created by STUN are subjected to media classification that classifies the media as Real-time Transport Protocol (RTP) or non-RTP. The firewall automatically allows the RTP session on
ArubaOS 6.5.3.x
| User Guide Voice and Video | 959
the controller and denies the non-RTP sessions. For the controller to accept STUN messages, you must allow
ICE-STUN based firewall traversal on the controller and allow UDP 3478 and TCP 443 ports in the user role.
Allowing ICE-STUN
To allow ICE-STUN based firewall traversal, issue the following CLI command:
(host) (config) #firewall allow-stun
Allowing UDP Port 3478
STUN uses UDP port 3478. To allow UDP port 3478 in the user role, issue the following CLI commands.
(host) (config) #user-role <STRING>
(host) (config-role) #ip access-list session stun
(host) (config-sess-stun)#any any udp 3478 permit
Allowing TCP Port 443
HTTP Secure (HTTPS) uses TCP port 443. To allow TCP port 443 in the user role, issue the following CLI commands.
(host) (config) #user-role <STRING>
(host) (config-role) #ip access-list session https-acl
(host) (config-sess-stun)#any any svc-https permit
Configuring Per User Role Lync/Skype for Business Call Prioritization
In ArubaOS 6.3.x, you can configure the UCC call prioritization system-wide only. For example, Lync/Skype for
Business voice, video, and collaboration applications can be configured system-wide on the controller. Starting with ArubaOS 6.4, an administrator can configure Lync/Skype for Business call prioritization on a per user-role basis. With this feature, you can have one set of users have priority on real-time media traffic over another set of users. An administrator can configure the per user-role Lync/Skype for Business call prioritization based on the deployment needs.
Important Points to Remember
If two clients in an active call are in different user-roles and traffic prioritization, the traffic prioritization is based on the following order:
1. Voice
2. Video
3. Best-effort
4. Background
The above is applicable for both; the caller and called parties.
Example
Client 1 (C1) is assigned user-role 1 with voice priority enabled. Client 2 (C2) is assigned user-role 2 with voice priority disabled. When C1 makes a voice call to C2, both parties have prioritized voice call.
Traffic prioritization may not apply if it is a conference call or the caller and called parties are in multiple controllers.
You can configure the per user-role UCC call prioritization for Lync/Skype for Business ALG using the WebUI or
CLI.
In the WebUI
Configure the Lync/Skype for Business traffic control profile:
1. Navigate to the Configuration > Advanced Services > All Profiles page.
2. Select Other Profiles to expand the Other Profiles section.
960 | Voice and Video ArubaOS 6.5.3.x | User Guide
3. Click the Traffic Control Prioritization profile.
4. Under the Traffic Control Prioritization Profile section, enter the profile name and click Add .
5. Click the newly created profile.
6. Select the appropriate check box to prioritize Lync/Skype for Business traffic. See
By default, Lync/Skype for Business ALG prioritizes all the four application types.
Table 237: Lync/Skype for Business ALG Traffic Priority Parameters
Traffic
Control
Parameter
Description
Prioritize voice
Prioritizes voice sessions by Lync/Skype for Business ALG.
Prioritize video
Prioritize desktopsharing
Prioritize file-transfer
Prioritizes video sessions by Lync/Skype for Business ALG.
Prioritizes desktop sharing sessions by Lync/Skype for Business ALG.
Prioritizes file transfer sessions by Lync/Skype for Business ALG.
Link the newly created Lync/Skype for Business traffic control profile to the user-role:
1. Navigate to the Configuration > Security > Access Control > User Roles page.
2. Select an existing user role, and click Edit .
3. Under the Misc. Configuration section, select the newly created Lync/Skype for Business traffic control profile from the Traffic Control Profile drop-down list.
In the CLI
Configure the Lync/Skype for Business traffic control profile:
(host) (config) #app skype4b traffic-control <profile-name>
(host) (Traffic Control Prioritization Profile "default") #prioritize-voice
(host) (Traffic Control Prioritization Profile "default") #prioritize-video
(host) (Traffic Control Prioritization Profile "default") #prioritize-desktop-sharing
(host) (Traffic Control Prioritization Profile "default") #prioritize-file-transfer
To verify the configuration, use the following command:
(host) #show ucc configuration traffic-control skype4b <profile-name>
Link the newly created Lync/Skype for Business traffic control profile to the user-role.
(host) (config) #user-role <STRING>
(host) (config-role) #traffic-control-profile <STRING>
Recommended DSCP Mapping for Lync/Skype for Business Traffic in Aruba Controller
The following DSCP values for Lync/Skype for Business ALG are recommended:
ArubaOS 6.5.3.x
| User Guide Voice and Video | 961
Table 238: DSCP Values
Lync/Skype for
Business
Application
DSCP Mapping
Voice
Video and desktop sharing
File transfer
56
40
24 (Best-effort)
You can configure the DSCP mappings in the SSID profile using the following CLI command:
(host)(config) #wlan ssid-profile Skype4b_ALG
(host) (SSID Profile "Skype4b_ALG") #wmm
(host) (SSID Profile "Skype4b_ALG") #wmm-vo-dscp 56
(host) (SSID Profile "Skype4b_ALG") #wmm-vi-dscp 40
(host) (SSID Profile "Skype4b_ALG") #wmm-be-dscp 24
Disable Media Classification
Media classification is not supported when clients are accessed through a network address translation (NAT).
Media classification should not be configured on session ACL for Secure SIP used by Lync/Skype for Business clients. The following example verifies if media classification is configured on session ACL that is associated with the user-role, "employee":
(host) #show rights employee
Derived Role = 'employee'
Up BW:No Limit Down BW:No Limit
L2TP Pool = default-l2tp-pool
PPTP Pool = default-pptp-pool
Periodic reauthentication: Disabled
ACL Number = 64/0
Max Sessions = 65535 access-list List
----------------
Position Name Type
-----------
1 employee
---session
Location
-------employee
---------
Priority Source Destination Service
-----------------------------
1 any any svc-sips
Action TimeRange Log
---------------permit
Expired Queue TOS 8021P Blacklist Mirror DisScan ClassifyMedia
------------------------------------------------
High Yes
IPv4/6
------
962 | Voice and Video ArubaOS 6.5.3.x | User Guide
4
Expired Policies (due to time constraints) = 0
Under ClassifyMedia column, Yes indicates media classification is configured. To disable it, you must first delete the ACL. Use the following commands:
(host) (config) #ip access-list session employee
(host) (config-sess-employee) #no any any svc-sips permit
You must add the rule any any svc-sips permit back to the ACL without the classify-media parameter:
(host) (config-sess-employee) #any any svc-sips permit
Viewing Lync/Skype for Business ALG Statistics using the CLI
This section describes the procedures to view Lync/Skype for Business ALG statistics using the CLI.
For detailed command parameters, see the ArubaOS 6.4.x CLI Reference Guide .
n n n n
Viewing the list of Lync/Skype for Business Clients on page 963
Viewing Call Detail Record for Lync/Skype for Business Calls on page 963
Viewing Call Quality for Lync/Skype for Business Calls on page 963
Viewing Lync/Skype for Business Call Trace Buffer on page 963
Viewing the list of Lync/Skype for Business Clients
Use the following command to display details of clients that are actively using Lync/Skype for Business. An entry is created for clients that have actively participated in voice, video, desktop-sharing, or file-sharing sessions.
(host) #show ucc client-info app skype4b
Viewing Call Detail Record for Lync/Skype for Business Calls
Use the following command to view the Call Detail Record for Lync/Skype for Business calls on the controller.
This command displays the last 512 call records for all the controller platforms.
(host) #show ucc call-info cdrs app skype4b
Viewing Call Quality for Lync/Skype for Business Calls
Use the following command to view the call quality information for Lync/Skype for Business voice and video calls.
(host) #show ucc call-info cdrs detail
Viewing Lync/Skype for Business Call Trace Buffer
Use the following command to display the Lync/Skype for Business message trace buffer for the first 256 events. Events such as establishing voice, video, desktop sharing, and file transfer are recorded.
(host) #show ucc trace-buffer skype4b
Troubleshooting Lync/Skype for Business ALG Issues
The following sections describe the CLI commands to troubleshoot Lync/Skype for Business ALG issues.
Enabling Lync/Skype for Business ALG Debug Logs
Lync/Skype for Business ALG related debug logs are available under logs. Use the following command to enable this:
(host) (config) #logging level debugging user process stm subcat voice
ArubaOS 6.5.3.x
| User Guide Voice and Video | 963
Viewing Lync/Skype for Business ALG Debug Logs
To view the Lync/Skype for Business ALG debug logs, use the following command:
(host) (config) #show log user all
Jul 18 15:33:09 :503188: <DBUG> |stm| |voice| vm_lync_create_call: mac(1c:ab:a7:2d:75:6b) num_ sessions(0) curr_session(0x1064f144)
Jul 18 15:33:09 :503188: <DBUG> |stm| |voice| VM: vm_lync_create_call:1001 LYNC INFO: Headers are 2b00b11f-71e3-40a5-a1bf-386dc9d49eb6 sip:[email protected] sip:[email protected]
Jul 18 15:33:09 :503188: <DBUG> |stm| |voice| vm_lync_update_session_sdp:1869 -- vc
(1c:ab:a7:2d:75:6b)
Jul 18 15:33:09 :503188: <DBUG> |stm| |voice| VM: vm_lync_update_session_sdp:1961 LYNC INFO: copied 1 staus to call_info
Jul 18 15:33:09 :503162: <DBUG> |stm| |voice| VM: vm_lync_update_session_sdp 1963: Tx params changed
Jul 18 15:33:09 :503188: <DBUG> |stm| |voice| vm_lync_update_session_sdp:1869 -- vc
(1c:ab:a7:2d:75:6b)
Jul 18 15:33:09 :503188: <DBUG> |stm| |voice| VM: vm_lync_update_session_sdp:1961 LYNC INFO: copied 1 staus to call_info
Jul 18 15:33:09 :503162: <DBUG> |stm| |voice| VM: vm_lync_update_session_sdp 1963: Tx params changed
Jul 18 15:33:09 :503126: <DBUG> |stm| |voice| VM: vm_lync_create_call 1023: Session created and inserted successfully for call id 2b00b11f-71e3-40a5-a1bf-386dc9d49eb6, 10.XX.XX.208
Jul 18 15:33:09 :503188: <DBUG> |stm| |voice| VM: vm_lync_idle_startdialog_req:301 LYNC INFO: vm_lync_create_call is success..
Jul 18 15:33:09 :503188: <DBUG> |stm| |voice| VM: vm_lync_idle_startdialog_req:309 LYNC INFO: vm_lync_create_call() is success..
UCC Dashboard in the WebUI
The UCC dashboard gives a complete view of the UCC deployment in the controller. The UCC dashboard has two levels of displaying statistics: n n
UCC Dashboard Aggregated Display
UCC Dashboard Per Client Display
UCC Dashboard Aggregated Display
The UCC Dashboard Aggregated Display shows an aggregated view of the UCC calls made in the controller. The administrator can see a top level view of the call quality assessment, and further drill-down into a specific view based on the analysis required.
Chart View
Navigate to Dashboard > UCC . The UCC page displays the overall health (in graphical format) of the UCC deployment in the controller as shown in
.
964 | Voice and Video ArubaOS 6.5.3.x | User Guide
Figure 205 UCC Dashboard
Each graphical section of the UCC dashboard is explained below: l l
Call Volume – This graph displays the total number of calls made based on the UCC application type.
For example, SIP, Skype4B, SCCP, H.323, NOE, SVP, VOCERA, Wi-Fi calling, and FaceTime.
Call Quality – This graph displays the AP-to-Client call quality under the WLAN tab and the end-to-end quality including wired and wireless legs of the call under the End-to-End tab. The number of UCC calls are categorized by the following call quality: l l
Good
Fair l l
Poor
Not Available : Under WLAN tab, short duration voice calls (less than 60 seconds), video calls, and file-transfer session are categorized as Not Available . Under End-to-End tab, short duration voice calls (less than 60 seconds), video calls, file-transfer, and desktop-sharing sessions are categorized as
Not Available .
When VoIP calls are prioritized using media classification, the End-to-End call quality is not available.
l
Call Quality vs. Client Health - This graph displays the co-relation between the VoIP call quality and the VoIP client health of every UCC call. This graph displays the UCC score under the WLAN tab and MOS under the End-to-End tab.
When VoIP calls are prioritized using media classification, the End-to-End call quality is not available.
l l l
Calls Per Device Type – This graph displays the calls made per device type. For example, Windows 7,
Mac OS X, iPhone, or Android.
Roaming – Roaming status of UCC clients. The status can be: l
No – Number of calls where the client did not roam to a new AP.
l
Yes - Number of calls where the client has roamed to a new AP.
QoS Correction – If the DSCP value of the Real-time Transport Protocol (RTP) packets sent by the client differs from the WMM-DSCP configured in the corresponding
SSID profile definition , the controller
corrects this value as per the SSID profile definition and classifies the call as QoS corrected. This graph
ArubaOS 6.5.3.x
| User Guide Voice and Video | 965
displays the number of UCC calls where the controller has corrected the WMM-DSCP value for such calls.
The QoS correction is categorized as: l l l
No – No WMM-DSCP value correction.
Yes – WMM-DSCP value corrected by the controller.
Not Available – WLAN short duration voice calls (less than 60 seconds), video calls, and file-transfer session are categorized as Not Available .
Details View
To display an aggregated list of all the UCC call data metrics in the controller, navigate to the Dashboard > UCC page of the WebUI and click any of the following hyperlinks: l l l l l l
Call Volume Details
Call Quality Details
Client Health Details
Device Details
Roaming Details
QoS Details
displays an aggregated list of all the UCC call data metrics in the controller.
Figure 206 Wireless Call List
VoIP calls made to/from clients outside the local controller are displayed in the External Call List pane. This pane lists all the external and wired client call CDRs. See
Figure 207 External Call List
966 | Voice and Video ArubaOS 6.5.3.x | User Guide
UCC Dashboard Per Client Display
On the Dashboard > Clients page of the WebUI, clicking the client IP hyperlink displays the details page of the client. Click the UCC tab. This tab displays an aggregated list of UCC call data metrics of a client. See
.
Figure 208 UCC Client Page
displays all the VoIP call statistics made by a particular client. This graph displays the AP-to-Client metrics under the WLAN tab and the end-to-end quality including wired and wireless legs of the call under the
End-to-End tab.
When VoIP calls are prioritized using media classification, the End-to-End call quality is not available.
Figure 209 All Calls
displays the VoIP call summary for a selected call of a client.
ArubaOS 6.5.3.x
| User Guide Voice and Video | 967
Figure 210 Selected Call Summary
displays the VoIP call details for a selected call of a client.
Figure 211 Selected Call Details
On the Dashboard > Usage page of the WebUI, the Call Quality vs. Client Health graph displays the corelation between the VoIP call quality (UCC-Band) and the VoIP client health of every UCC call. See
.
Figure 212 Call Quality vs. Client Health
Viewing UCC Information
This section describes the commands to view UCC clients, calls, and configuration information in the controller.
For detailed command parameters, see the ArubaOS 6.4.x CLI Reference Guide .
968 | Voice and Video ArubaOS 6.5.3.x | User Guide
n n n n n
Viewing the list of Lync/Skype for Business Clients on page 963
Viewing UCC Client Information on page 969
Viewing UCC Configuration on page 969
Viewing UCC Statistics on page 969
Viewing UCC Trace Buffer on page 969
Viewing UCC Call Detailed Record
Use the following command to display the CDR statistics for UCC:
(host) #show ucc call-info cdrs [ap | app | cid | detail]
Viewing UCC Client Information
Use the following command to display the UCC client status and CDR statistics:
(host) #show ucc client-info [app | detail | sta]
Viewing UCC Configuration
Use the following command to display the UCC configuration in the controller:
(host) #show ucc configuration [cac-alg | dialplan | logging | midcall-timeout | realtimeanalysis | rtcp-inactivity | sip | traffic-control]
Viewing UCC Statistics
Use the following command to display the UCC call statistics in the controller:
(host) #show ucc statistics {counter | dial-plan | remote | tspec-enforcement | wmm-flow}
Viewing UCC Trace Buffer
Use the following command to display the UCC call message trace buffer for Skype4B, SCCP, and SIP ALGs.
Events such as establishing voice, video, desktop sharing, and file transfer are recorded:
(host) #show ucc trace-buffer {skype4b | sccp | sip}
UCC-AirWave Integration
The UCC-AirWave integration provides a multi-controller visibility into the UCC solution across deployments.
The controller sends raw UCC data using Application MONitoring (AMON) periodically. AirWave Management
Platform (AMP) receives these AMON messages and uses this data to display user-friendly aggregated and perclient UCC statistics in AirWave. This helps the administrator to assess the overall health and troubleshoot UCC deployments in a multi-controller environment. The UCC dashboard is supported in AirWave 8.0 onwards.
Follow these steps to get UCC data in AirWave from the controller:
Enabling UCC Data Collection in AirWave
To enable UCC data collection in the AirWave WebUI:
1. Navigate to the AMP Setup > General tab of the AirWave WebUI.
2. In the Additional AMP Services section, change the Enable UCC Data Collection radio button to Yes .
Note: To enable this setting, the controller must run ArubaOS 6.4 and above.
Adding AMP as a Management Server in the Controller
You can view and add the default AMP management server profile using the controller WebUI or CLI.
In the WebUI
To view the default AMP management server profile:
ArubaOS 6.5.3.x
| User Guide Voice and Video | 969
1. Navigate to the Configuration > ADVANCED SERVICES > All Profiles page of the controller WebUI.
2. In the Profiles section, expand Controller and click Mgmt Config .
The Profile Details section displays a list of management configuration profiles in the controller.
To add AMP as a management server in the controller:
1. Navigate to the Configuration > MANAGEMENT > General page of the controller WebUI.
2. In the AirWave Servers section, click New .
3. In the Primary Server text-box, enter the primary AirWave server IP.
4. From the Profile List drop-down list, choose the default-amp profile.
5. Click Add and Apply .
In the CLI
Execute the following command in the controller CLI to view the default AMP management server profile:
(host) #show mgmt-server profile
Mgmt Config profile List
------------------------
Name
----
References
---------default-ale 0 default-amp 0
Profile Status
--------------
Predefined (editable)
Predefined (changed)
Total:2
Execute the following command in the controller CLI to add AMP as a management server in the controller:
(host)(config) #mgmt-server type amp primary-server <primary-server-ip> profile default-amp
Enabling UCC Monitoring in the Controller
By default, UCC Monitoring is disabled in the controller. You can enable this setting using the controller
WebUI or CLI.
In the WebUI
To enable UCC Monitoring in the controller:
1. Navigate to the Configuration > ADVANCED SERVICES > All Profiles page of the controller WebUI.
2. In the Profiles section, expand Controller and click Mgmt Config .
The Profile Details section displays a list of management configuration profiles in the controller.
3. Click an instance of the management configuration profile.
4. In the Profile Details section, check the UCC Monitoring check box.
5. Click Apply .
In the CLI
Execute the following command in the controller CLI to enable UCC Monitoring :
(host)(config) #mgmt-server profile default-amp
(host)(Mgmt Config profile “default-amp”)#uccmonitoring-enable
Verifying the Configuration
Execute the following command in the controller CLI to view the management server configuration profile:
(host) #show mgmt-server profile default-amp
Mgmt Config profile "default-amp" (Predefined (changed))
--------------------------------------------------------
970 | Voice and Video ArubaOS 6.5.3.x | User Guide
Parameter
---------
Stats
Tag
Sessions
Monitored Info
Misc
Location
UCC Monitoring
Value
-----
Enabled
Enabled
Enabled
Disabled
Enabled
Enabled
Enabled
AirGroup Info Disabled
Inline DHCP stats Enabled
Inline AP stats Enabled
Inline Auth stats Enabled
Inline DNS stats Enabled
Execute the following command in the controller CLI to view the current controller configuration with respect to the management server configuration profile:
(host) #show running-config | include mgmt-server
Building Configuration...
mgmt-server type amp primary-server 192.0.2.1 profile default-amp mgmt-server profile "default-amp"
The UCC-AirWave integration is complete.
UCC Call Quality Metrics
Computing the call quality metrics is an important aspect of troubleshooting. The metrics enable administrators to get an idea of the quality of service on the network and troubleshoot network congestion whenever required. ArubaOS 6.3.x provides UCC call quality metrics for Lync/Skype for Business voice calls only at the end of the call. In addition to capturing call quality metrics at the end of the call, ArubaOS 6.4.x
captures call quality metrics for active calls. The call quality metrics are extended to voice, video, desktopsharing, and file-transfer applications.
A new metric, UCC score is introduced in ArubaOS 6.4. UCC score computes the quality of voice calls. It takes delay, jitter, and packet loss of RTP packets into account. UCC score is computed on a scale of 0 to 100. This feature works in tunnel, decrypt-tunnel, and split-tunnel forward modes. To compute the UCC score, you must enable RTP Analysis on the master controller. Issue the following CLI commands:
(host) (config) #voice real-time-config
(host) (Configure Real-Time Analysis) #config-enable
shows the call quality parameters displayed on the controller for various UCC ALGs.
ArubaOS 6.5.3.x
| User Guide Voice and Video | 971
Table 239: Voice and Video Call Quality Parameters
UCC
Application
Media Type
Lync/Skype for Business
Audio
Call Quality Parameters
SIP
SCCP
NOE
Vocera
H.323
Video
Audio
Video
Audio
Audio
Audio
Audio
Video n n n n n
Mean Opinion Score (MOS)
UCC Score
Delay
Jitter
Packet Loss
Following end-to-end call quality parameters are available: n Delay n n
Jitter
Packet Loss n n n n
UCC Score
Delay
Jitter
Packet Loss n n n
Delay
Jitter
Packet Loss n n n n
UCC Score
Delay
Jitter
Packet Loss n n n n
UCC Score
Delay
Jitter
Packet Loss n n n n
UCC Score
Delay
Jitter
Packet Loss n n n n
UCC Score
Delay
Jitter
Packet Loss n n n
Delay
Jitter
Packet Loss
shows the quality parameters displayed for Lync/Skype for Business collaborative services.
972 | Voice and Video ArubaOS 6.5.3.x | User Guide
Table 240: Quality Parameters for Collaborative Services
Lync/Skype for Business
Collaborative Services
Lync/Skype for Business
Desktop-sharing
Lync/Skype for Business Filetransfer
Quality Parameters n n n n n n n n
UCC Score
Quality band
Delay (msec)
Jitter (msec)
Signal to Noise Ratio (SNR)
Avg Tx Rate (Mbps)
Tx Drop (%)
Tx Retry (%) n n
Avg Rx Rate (Mbps)
Rx Retry (%)
NOTE: Delay and Jitter call quality parameters are measured end-to-end.
n n n n
SNR
Avg Tx Rate (Mbps)
Tx Drop (%)
Tx Retry (%) n n
Avg Rx Rate (Mbps)
Rx Retry (%)
NOTE: The quality parameters are computed by the AP and does not have any dependency on the quality update message from the Microsoft Lync/Skype for
Business server.
Changes to Call Admission Control
In ArubaOS 6.4.x,CAC is not applied for Lync/Skype for Business calls. Lync/Skype for Business calls are allowed to flow with high priority irrespective of the call count or bandwidth based CAC limit. This applies to calls prioritized by both media classification and SDN API based Lync/Skype for Business ALG. CAC configured under wlan voip-cac-profile and Virtual AP (VAP) based bandwidth limitation under wlan trafficmanagement-profile does not apply to Lync/Skype for Business calls.
Troubleshooting and Log Messages
When you report any UCC related issues, collect the STM, UCM, and tech-support logs.
To enable VoIP ALG related debug logs:
(host) (config) # logging level debugging user process stm subcat voice
To enable UCM related debug logs:
(host) (config) #logging level debugging user process ucm
(host) (config) #logging level debugging system process ucm n n
Collect the output of the following commands: n n n n n show datapath session table
The RTP sessions are tagged with the Q flag indicating real time analysis is computed for the session.
show datapath application show datapath user show rights show datapath acl <id> show datapath session show voice real-time-config
ArubaOS 6.5.3.x
| User Guide Voice and Video | 973
Verify the RTP analysis for an active call by issuing the following command:
(host) #show voice real-time-analysis
While a Lync/Skype for Business call is active, the output of this command displays the current delay, jitter, packet loss, and UCC score of the client. This command displays any data only if the client is on an active call.
UCC Limitations
n n n n n n n n n
Voice ALGs should not be enabled when voice clients are behind a NAT.
Media classification does not work when user VLAN has IP NAT configured.
When using media classification, UCC score, jitter, delay, and packet loss is calculated only for voice RTP streams. These metrics are not available for video streams.
Media classification does not work in split-tunnel forwarding mode.
When VoIP calls are prioritized using media classification, end-to-end call quality metrics such as Mean
Opinion Score (MOS), delay, jitter, and packet loss are not available.
UCC score is calculated for voice calls and desktop-sharing sessions only.
For Lync/Skype for Business calls, MOS is generated only for voice calls. Lync/Skype for Business server does not generate MOS for video calls, desktop-sharing, and file-transfer sessions.
When SIP messages are sent over UDP and the packet size is large such that it gets IP fragmented, the controller does not prioritize SIP ALG or provide any visibility to such calls.
A client device may run multiple UCC applications such as SIP and Skype for Business. ArubaOS 6.x supports only one UCC application per client device. ArubaOS provides firewall, prioritization, and visibility services for media sessions belonging to the UCC application that was registered first using the client device.
Understanding Extended Voice and Video Features
This section describes the other voice and video-related functionalities that are available on the controller.
Understanding QoS for Microsoft® Lync/Skype for Business and Apple FaceTime
Voice and video devices use a signaling protocol to establish, control, and terminate voice and video calls. These control or signaling sessions are usually permitted using pre-defined ACLs. If, however, the control signaling packets are encrypted, the controller cannot determine which dynamic ports are used for voice or video traffic.
In these cases, the controller has to use an ACL with the classify-media option enabled to identify the voice or video flow based on a deep packet inspection and analysis of the actual traffic.
Microsoft® Lync/Skype for Business
Lync and Skype for Business (Skype4b) uses SIPS to establish, control, and terminate voice and video calls. The following example creates an ACL named skype4b acl for Skype4b traffic that identifies port 5061 as the reserved SIP-TLS port.
(host) (config) #ip access-list session skype4b-acl
(host) (config-sess-skype4b-acl)#any any tcp 5061 permit position 1 queue high classify-media
(host) (config-sess-skyper4b-acl)#any any udp 1025-65535 permit position 2 queue low
UCC Score for Lync/Skype4b Media Classification
The controller supports UCC score for Lync/Skype4b calls prioritized using media classification. As part of this feature, Unified Communication Manager (UCM) supports the following: n n
Real-time quality analysis for Lync/Skype4b voice and video calls (voice RTP streams only)
Real-time computation of UCC score (delay, jitter, and packet loss) for Lync/Skype4b VoIP calls prioritized using media classification. The UCC score is computed by the AP in the downstream direction.
974 | Voice and Video ArubaOS 6.5.3.x | User Guide
n
Call Quality vs. Client Health chart in the UCC dashboard of the controller.
When VoIP calls are prioritized using media classification, end-to-end call quality metrics such as Mean Opinion
Score (MOS), delay, jitter, and packet loss are not available.
UCC score computes the quality of voice calls. It takes delay, jitter, and packet loss of Real-time Transport
Protocol (RTP) packets into account. UCC score is computed on a scale of 0 to 100. To compute the UCC score, you must enable RTP Analysis on the master controller.
In the CLI
To enable RTP analysis in the CLI:
(host) (config) #voice real-time-config
(host) (Configure Real-Time Analysis) #config-enable
In the WebUI
To enable RTP Analysis in the WebUI:
1. Navigate to Configuration > Advanced Services > All Profiles .
2. In Profiles section, expand Other Profiles > Configure Real-Time Analysis .
3. In Profile Details section, check the Real-Time Analysis of voice calls check box.
4. Click Apply .
Available Call Quality Metrics
Following call quality metrics are available for Lync/Skype4b calls prioritized by media classification:
Client IP, Client Mac, ALG, Duration(approximate), Orig time(approximate), Status, Reason, Call Type
(voice/video), Client Health, UCC Score, UCC Band, Source port, Destination port, Originated and modified
DSCP & WMM values, delay, jitter, and packet loss.
As the RTP packets are encrypted, following call quality metrics are not available for Lync/Skype4b calls prioritized by media classification:
Client Name, Direction, Called to, MOS, MOS band, End-to-end Delay, jitter and packet loss.
File transfer and desktop sharing CDRs are also not available. WLAN delay, jitter, and packet loss are not available for video sessions.
The show ucc commands are extended to media classification based Lync/Skype4b ALG. For more information on the list of commands, see
Viewing UCC Information on page 968
.
The UCC dashboard is extended to media classification based Lync/Skype4b ALG. For more information on
UCC dashboard, see
UCC Dashboard in the WebUI on page 964 .
Important Points to Remember n n n n n
You must disable Lync/Skype4b ALG if you use the classify-media option. For more information on Lync
ALG, see
Unified Communication and Collaboration on page 955 .
When using media classification, UCC score, jitter, delay, and packet loss is calculated only for voice RTP streams. These metrics are not available for video streams.
Media classification does not work in split-tunnel forwarding mode.
When VoIP calls are prioritized using media classification, end-to-end call quality metrics such as Mean
Opinion Score (MOS), delay, jitter, and packet loss are not available.
Media classification is not supported when clients are behind a Network Address Translation (NAT) device.
ArubaOS 6.5.3.x
| User Guide Voice and Video | 975
n
Consider a scenario where all clients on a voice call are in mute state for more than 20-30 seconds from the beginning of the call. The subsequent RTP/RTCP packets from these clients will be prioritized but CDRs may not be available for these calls.
Microsoft Lync/Skype4b Support for Mobile Devices
Microsoft Lync/Skype4b supports the mobile devices that are running on the following operating systems: n n n
Windows
Android iOS
You can configure the following ACLs to support the media classification: n n n
TCP Port 5061 for SIPS signaling sessions initiated by the Lync/Skype4b clients
TCP Port 443 for signaling sessions initiated by Lync/Skype4b application running on mobile devices
UDP and TCP traffic on port range 1024 to 65535 for sessions initiated by the Lync/Skype4b applications
The following example shows how to configure an ACL to identify and monitor the mobile devices supported by Lync/Skype4b:
(host) (config) #ip access-list session Skype4b-Smart-Device
(host) (config-sess-Skype4b-Smart-Device)#any alias Skype4b-Servers ?
(host) (config-sess-Skype4b-Smart-Device)#any alias Skype4b-Servers tcp 443 permit classifymedia
(host) (config-sess-Skype4b-Smart-Device)#any any udp 1025-65535 permit position 3 queue low
Apple FaceTime
When an Apple device starts a FaceTime video call, it initiates a TCP session to the Apple FaceTime server over port 5223, then sends SIP signaling messages over a non-default port. When media traffic starts flowing, audio and video data are sent through the same port using RTP. (The audio and video packets are interleaved in the air, though individual sessions can be uniquely identified using their payload type and sequence numbers.) The
RTP header and payload also get encapsulated under the TURN ChannelData Messages. The FaceTime call is terminated with a SIP BYE message that can be sent by either party.
lists the ports used by Apple FaceTime. FaceTime users need to be assigned a role where traffic is allowed on these ports:
Table 241: Ports used by the Apple FaceTime Application
Port
80
443
3478-3497
5223
16384-
16387
16393-
16402
Packet
Type
TCP
TCP
UDP
TCP
UDP
UDP
Additional Information
HTTP
HTTPS
NAT-STUN Port for FaceTime and
Game Center
Apple Push Notification
RTP and RTCP for iChat Audio and
Video
RTP and RTCP for FaceTime and Game
Center
976 | Voice and Video ArubaOS 6.5.3.x | User Guide
In the CLI
The example below shows how to configure ACLs to identify and monitor Apple FaceTime traffic.
(host) (config) #ip access-list session facetime-acl
(host) (config-sess-facetime-acl) #any any svc-http permit position 1 queue low
(host) (config-sess-facetime-acl) #any any svc-https permit position 2 queue low
(host) (config-sess-facetime-acl) #any network 17.0.0.0 255.0.0.0 tcp 5223 permit classifymedia position 3 queue low
(host) (config-sess-facetime-acl) #any any udp 3478 3498 permit position 4 queue low
(host) (config-sess-facetime-acl) #any any udp 16384 16387 permit position 5 queue low
(host) (config-sess-facetime-acl) #any any udp 16393 16402 permit position 6 queue low
You can use the WebUI or CLI to enable the classify-media option for the Apple Push Notification service over
TCP 5223.
In the WebUI
The example below shows how to configure ACLs to identify and monitor Apple FaceTime traffic.
1. Navigate to the Configuration > Security > Access Control page.
2. Click the Policies tab.
3. Click Add to create a new policy.
4. Enter a name for the policy in the Policy Name field and choose Session in the Policy Type drop down menu.
5. Under Rules , click Add . Configure the settings described in
.
Table 242: Session Rule Parameters
Parameter
IP Version
Source
Destination
Service/Application
Description
IP version of the rule. The version can be IPv4 or IPv6.
Match any IPv4 or IPv6 source traffic. The values can be: n alias n n any host n n n localip network user
Match any IPv4 or IPv6 destination traffic. The values can be: n alias n n any host n n n localip network user
Match any service or application. The values can be: n any n n
Application
Application category n n n n n protocol service tcp udp
Web category/Reputation
ArubaOS 6.5.3.x
| User Guide Voice and Video | 977
Table 242: Session Rule Parameters
Parameter
Action
Description
Queue
Classify Media
Action to be taken when the filter matches the traffic pattern. The values can be: n drop n n dst-nat dual-nat n n n n n n n permit redirect to esi redirect to tunnel reject route route dst-nat src-nat
Queue priority of the flow. The values can be: n Low n High
Enable this setting to identify the voice or video flow based on a deep packet inspection and analysis of the actual traffic.
NOTE: Enable this setting only for voice or video signaling/control session as it causes deep packet inspection of all UDP flows to and from the user.
6. Click Apply .
Apple FaceTime Session Identification
The controller can determine if the media session is a FaceTime session by searching the presence of a pattern in the User-Agent field of the SIP signaling message header. Apple refers the internal name of FaceTime session as "Viceroy". "Viceroy" is the User-Agent string of the SIP signaling message header. A provision to configure this string is available in the controller in case a new version of Apple FaceTime uses a different User-Agent string other than "Viceroy".
Do not configure this feature unless a new version of the Apple FaceTime uses a different User-Agent string other than "Viceroy". Contact Aruba Technical Support for more information.
In the WebUI
The following procedure configures a pattern to recognize FaceTime sessions using the WebUI.
1. Navigate to Configuration > Advanced Services > All Profiles .
2. Expand Other Profiles and click Apple Facetime Config .
3. In the Profile Details section, enter a string in the Pattern to recognize Facetime field.
4. Click Save .
In the CLI
The following commands configures a pattern to recognize Apple FaceTime sessions using the CLI.
(host) (config) #voice facetime
(host) (Apple Facetime Config) #pattern <pattern>
The following command displays the pattern configured using the CLI.
(host) #show voice facetime
Apple Facetime Config
---------------------
Parameter Value
978 | Voice and Video ArubaOS 6.5.3.x | User Guide
-------------
Pattern to recognize Facetime <pattern>
Wi-Fi Calling
Wi-Fi calling service allows cellular users to make or receive calls using a Wi-Fi network instead of using the carrier’s cellular network. Wi-Fi calling allows users to place, receive calls, and text messages even when they are beyond a cellular coverage but having a Wi-Fi network coverage. Major carriers around the world support Wi-Fi calling service.
Wi-Fi Calling Support in ArubaOS
ArubaOS provides QoS for voice calls made using Wi-Fi calling. ArubaOS can identify and prioritize calls made using Wi-Fi calling. UCM provides visibility for all voice calls made using Wi-Fi calling.
Wi-Fi Calling Operation
At a high level, this is how Wi-Fi calling operates:
1. Wi-Fi calling capable handset initiates a DNS query to locate the carrier’s evolved Packet Data Gateway
(ePDG).
2. The handset establishes a persistent IPsec tunnel with ePDG.
3. Calls, text, and traffic for other services offered by the carrier are then carried over this IPsec tunnel.
Some carriers use a standard FQDN format for ePDG that includes their Mobile Network Code (MNC) and
Mobile Country Code (MCC). For example, T-mobile uses ss.epdg.epc.mnc260.mcc310.pub.3gppnetwork.org.
Others follow a different standard format. For example, AT&T uses epdg.epc.att.net.
Wi-Fi Calling Configuration
The Wi-Fi Calling ALG can be using the controller WebUI or CLI. The ALG is enabled by default.
In the WebUI
The following procedure configures the Wi-Fi Calling ALG using the WebUI.
1. Navigate to Configuration > Advanced Services > All Profiles .
2. Expand Other Profiles and click WiFi Calling Configuration .
3. In the Profile Details section, configure the settings described in
.
4. Click Save .
Table 243: Wi-Fi Calling Configuration Parameters
Parameter Description
WiFi Calling Support Enable the Wi-Fi Calling ALG. The ALG is enabled by default.
DNS Pattern dns-pattern –Configure the DNS pattern for the carrier. A maximum of 10 DNS patterns can be configured.
DNS patterns for known carriers are configured by default. Default built-in patterns are: n SmarTone - epdg.epc.mnc006.mcc454.pub.3gppnetwork.org
n n n n
T-mobile - ss.epdg.epc.mnc260.mcc310.pub.3gppnetwork.org
Sprint - primgw.vowifi2.spcsdns.net
Verizon - wo.vzwwo.com
3 HK - wlan.three.com.hk
n n
ATT - epdg.epc.att.net
Rogers - epdg.epc.mnc720.mcc302.pub.3gppnetwork.org
If the ePDG FQDN of the carrier does not match with the default patterns, use this option to configure the DNS pattern for the carrier.
service-provider –Add the service provider name for enhanced visibility.
ArubaOS 6.5.3.x
| User Guide Voice and Video | 979
In the CLI
The following commands configure the Wi-Fi Calling ALG using the CLI.
(host)(config) #voice wificalling
(host) (WiFiCalling Configuration) #enable
(host) (WiFiCalling Configuration) #dns-pattern <dns-pattern> service-provider <serviceprovider>
The following commands display the Wi-Fi Calling ALG configuration using the CLI.
(host) #show voice wificalling
WiFiCalling Configuration
-------------------------
Parameter
---------
Value
-----
WiFiCalling Support Enabled dns pattern att.net ATT
Wi-Fi Calling Troubleshooting
The following section describes the step-by-step procedure to troubleshoot Wi-Fi Calling ALG.
1. Ensure that the global prerequisites to enable Wi-Fi Calling is configured. For more information, see
Calling Configuration on page 979
.
2. Connect the Wi-Fi Calling capable handset to the SSID.
3. Once the handset establishes a persistent IPsec tunnel with ePDG, it displays the Wi-Fi Calling icon.
4. Execute the show ucc dns-ip-learning command to verify if the ePDG IP address is learned.
(host) #show ucc dns-ip-learning
DNS IP Learning:
----------------
IP Address
----------
Service Provider
----------------
208.54.85.108
T-Mobile
208.54.73.77
T-Mobile
208.54.70.110
T-Mobile
208.54.77.253
T-Mobile
208.54.75.2
T-Mobile
208.54.85.64
T-Mobile
208.54.73.76
T-Mobile
208.54.83.96
T-Mobile
208.54.85.111
T-Mobile
Total Entries:9
5. If the ePDG IP address is not learned, identify the FQDN of ePDG and add the DNS pattern of the carrier.
FQDN may not be matching with any of the default, built-in DNS patterns.
6. Place a few calls and execute the show ucc client-info and show ucc call-info cdrs commands or access the Dashboard > UCC page on the WebUI to view Wi-Fi call statistics and prioritization.
(host) # show ucc client-info
Client Status:
--------------
Client IP
---------
Client MAC
----------
Client Name
-----------
10.15.17.208
fc:c2:de:6c:01:9c Client
10.15.17.206
d8:bb:2c:51:16:b2 Client
ALG
---
WiFi-Calling
WiFi-Calling
Server(IP)
----------
T-Mobile
T-Mobile
Registration State
------------------
REGISTERED
REGISTERED
Call Status AP Name Flags Device Type
-------------------------------
In-Call 4-105-2 Android
980 | Voice and Video ArubaOS 6.5.3.x | User Guide
In-Call 2-105-1 Apple
Total Client Entries:2
Flags: V - Visitor, A - Away, W - Wired, R - Remote, E - External
(host) # show ucc call-info cdrs
Help: [C] - Metric calculated at the Controller
[A] - Metric calculated at the AP
CDR:
----
CDR ID UCC Call ID Client IP
Called to
Client MAC Client Name ALG Dir
------------------------
----
20 NA
--------------------
10.15.17.206
d8:bb:2c:51:16:b2 NA
---
WiFi-Calling
---
NA
-----
NA
19
18
17
NA
NA
NA
10.15.17.208
10.15.17.208
10.15.17.206
fc:c2:de:6c:01:9c fc:c2:de:6c:01:9c d8:bb:2c:51:16:b2
NA
NA
NA
WiFi-Calling
WiFi-Calling
WiFi-Calling
NA
NA
NA
NA
NA
NA
Dur(sec) Orig Time
----------------
82
88
Nov 24 23:21:31
Nov 24 23:21:25
Status
------
ACTIVE
ACTIVE
Reason
------
NA
NA
93
228
Nov 24 23:16:19 SUCC
Nov 24 23:14:32 SUCC
Call Type
---------
Voice
Voice
Terminated Voice
Terminated Voice
Client Health
-------------
44
78
71
51
UCC Score UCC-Band MOS MOS-Band
--------------------------------
NA NA NA NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
Total Entries:4
UCC Score and MOS values are not available for Wi-Fi Calling calls.
7. Execute the show datapath session table command on the managed node to ensure that media classification flags ( I & E ) are set for IPsec session destined to the ePDG IP address.
8. When a Wi-Fi Calling call is identified, the I and E flags are removed from the IPsec session and appropriate
ToS and 802.1p values are set for this session, along with other flags like V , H , P , T .
9. When the call ends, ToS and 802.1p values are removed for the IPsec session along with the V , H , P , T flags, and I and E flags are set. For a list of flags, execute the show datapath session table command.
Wi-Fi Calling Limitations
The following are the list of limitations in Wi-Fi Calling.
n
UCC Score and MOS values are not available.
n n n
Client Health vs Call Quality metrics are not available.
Wi-Fi Calling does not work in split and bridge-tunnel forwarding mode.
After clients failover from one controller to another, subsequent calls may not get prioritized.
ArubaOS 6.5.3.x
| User Guide Voice and Video | 981
Enabling WPA Fast Handover
In the 802.1X Authentication profile, the WPA fast handover feature allows certain WPA clients to use a preauthorized PMK, significantly reducing handover interruption. Check with the manufacturer of your handset to see if this feature is supported. This feature is disabled by default.
This feature supports WPA clients, while opportunistic key caching (also configured in the 802.1X Authentication profile) supports WPA2 clients.
In the WebUI
1. Navigate to the Configuration > AP Configuration page. Select either AP Group or AP Specific .
n n
If you select AP Group , click Edit for the AP group name for which you want to enable WPA fast handover.
If you select AP Specific , select the name of the AP for which you want to enable WPA fast handover.
2. Under Profiles , select Wireless LAN , then Virtual AP . In the Virtual AP list, select the appropriate virtual
AP instance.
3. Select AAA profile. Select the 802.1X Authentication Profile to display in the Profile Details section.
4. Scroll down to select the WPA-Fast-Handover check box.
5. Click Apply .
In the CLI
Use the following commands: aaa authentication dot1x <profile> wpa-fast-handover
For deployments where there are expected to be considerable delays between the controller and APs (for example, in a remote location where an AP is not in range of another Aruba AP) you can increase the value for the bootstrap threshold in the AP System profile to minimize the chance of the AP rebooting due to temporary loss of connectivity with the Aruba controller.
Enabling Mobile IP Home Agent Assignment
When you enable IP mobility in a mobility domain, the proxy mobile IP module determines the home agent for a roaming client. An option related to voice clients that you can enable allows on-hook phones to be assigned a new home agent to load balance voice client home agents across controllers in the mobility domain. See
for more information about mobility.
Scanning for VoIP-Aware ARM
ARM scanning on an AP during a call affects the voice quality. You can pause the ARM scanning on the AP when a call is active by turning on the VoIP-Aware ARM Scanning support to avoid voice quality issues.
You can use the WebUI or CLI to enable VoIP-aware ARM scanning in the ARM profile.
In the WebUI
1. Navigate to the Configuration > AP Configuration page. Select either the AP Group or AP Specific .
n
If you selected the AP Group tab, click Edit by the name of the AP group with the ARM profile you want to configure.
n
If you selected the AP Specific tab, click Edit by the name of the AP with the ARM profile you want to configure.
2. In the Profiles list, Expand the RF Management section.
3. Select Adaptive Radio Management (ARM) Profile .
982 | Voice and Video ArubaOS 6.5.3.x | User Guide
4. Select a profile instance from the drop-down menu to edit that profile.
5. Select the VoIP Aware Scan option.
6. Click Apply .
For additional information on configuring an Adaptive Radio Management profile, see
Configuring ARM Profiles on page 460 .
In the CLI rf arm-profile < profile-name> voip-aware-scan
Disabling Voice-Aware 802.1X
The Voice-Aware 802.1X support is deprecated for ArubaOS 5.0 and later releases.
Although reauthentication and rekey timers are configurable on a per-SSID basis, an 802.1X transaction during a call can affect voice quality. If a client is on a call, 802.1X reauthentication and rekey are disabled by default until the call is completed. You disable or re-enable the “voice aware” feature in the 802.1X authentication profile.
In the WebUI
1. Navigate to the Configuration > AP Configuration page. Select either AP Group or AP Specific.
n
If you select AP Group , click Edit for the AP group name for which you want to disable voice awareness for 802.1X.
n
If you select AP Specific , select the name of the AP for which you want to disable voice awareness for
802.1X.
2. Under Profiles, select Wireless LAN , then select Virtual AP . In the Virtual AP list, select the appropriate virtual AP instance.
3. Select AAA profile . Select the 802.1X Authentication Profile to display in the Profile Details section.
4. Scroll down and deselect the Disable rekey and reauthentication for clients on call check box.
5. Click Apply .
In the CLI
Use the following commands: aaa authentication dot1x <profile> no voice-aware
Configuring SIP Authentication Tracking
The controller supports the stateful tracking of session initiation protocol (SIP) authentication between a SIP client and a SIP registry server. Upon successful registration, a user role is assigned to the SIP client. You specify a configured user role for the SIP client in the AAA profile.
In the WebUI
1. Navigate to the Configuration > AP Configuration page. Select either AP Group or AP Specific .
n
If you select AP Group , click Edit for the AP group name for which you want to configure the SIP client user role.
n
If you select AP Specific , select the name of the AP for which you want to configure the SIP client user role.
ArubaOS 6.5.3.x
| User Guide Voice and Video | 983
2. Under Profiles , select Wireless LAN, then Virtual AP . In the Virtual AP list, select the appropriate virtual
AP instance.
3. Select the AAA profile. Enter the configured user role for SIP authentication role.
4. Click Apply .
In the CLI aaa profile <profile> sip-authentication-role <role>
Use the show voice client-status command to view the state of the client registration.
Enabling Real Time Call Quality Analysis
Real Time Call Quality Analysis (RTCQA) enables the controller to compute the call quality parameters such as jitter, delay, packet loss, and call quality score (R-value) directly from the RTP media stream. Additionally, the controller saves the periodic samples of the quality parameters for detailed analysis of the results. You can monitor up to 30 active calls that are initiated after enabling RTCQA. You can avail the full benefits of RTCQA by setting the AP in tunnel, decrypt-tunnel, or split-tunnel forwarding mode.
Enabling RTCQA is helpful in cases where the VOIP clients do not use RTP Control Protocol (RTCP) or use encrypted RTCP (in the case of Lync) which the controller cannot get the quality information from the RTCP frames.
Important Points to Remember
RTCQA for voice calls is supported only in the following cases: n n n when the signaling messages are not encrypted.
when the signaling messages are encrypted for Lync.
when the voice client does not roam from one controller to another controller. In other words, when a client moves to a foreign agent controller, RTCQA does not take effect.
You can use the WebUI or CLI to enable RTCQA and view the call quality reports based on the analysis.
To generate Lync UCC score, you must enable RTCQA. For more information on UCC score, see
In the Web UI
1. Navigate to the Configuration > Advanced services > All Profiles page.
2. Expand Other Profiles under the Profiles section and click Configure Real-Time Analysis .
3. Enable Real Time call quality analysis for the voice calls by selecting the Real-Time Analysis of voice calls check box.
Figure 213 Enable Real Time Analysis
4. Click Apply .
984 | Voice and Video ArubaOS 6.5.3.x | User Guide
Viewing Real Time Call Quality Reports
1. To view the average Real Time analysis reports, navigate to the Monitoring > Voice > Real-Time Quality
Analysis page.
2. To view the detailed Real Time analysis report of a specific client, select the client and click View Details .
Real Time analysis report is not available for clients in tunnel or bridge mode.
In the CLI
To configure Real Time analysis on voice calls:
(host) (config) #voice real-time-config
(host) (Configure Real-Time Analysis) #config-enable
To view the average Real Time analysis reports for the voice clients:
(host) #show voice real-time-analysis
Real-Time Analysis Call Quality Report
--------------------------------------
Client(IP) Client(MAC) Client(Name) ALG Jitter(D)(usec) Pkt-loss(D)(%)
------------------------------------------------------------
10.16.33.251
00:1f:6c:7a:d4:fd 6005 sccp 16.980
0.625
10.15.16.201
1c:ab:a7:2d:75:6b 7129 Lync 10.934
0.120
Delay(D)(usec) UCC Score(D) Forward mode
------------------------------------
421.125
454.163
78.985
86.250
decrypt-tunnel tunnel
Num Records:2
To view the detailed Real Time analysis report for a specific client:
(host) #show voice real-time-analysis sta 1c:ab:a7:2d:75:6b
WARNING: This command will be deprecated, please use show ucc commands instead
Real-Time Analysis Detailed Report
----------------------------------
Time Jitter(D)(usec) Pkt-loss(D)(%) Delay(D)(usec) UCC Score(D) Forward mode
---------------------------------------------------------------------------
Mar 15 17:05:34 2.000
Mar 15 17:05:32 2.000
Mar 15 17:05:30 3.000
Mar 15 17:05:28 2.000
1.000
5.000
7.000
2.000
255.000
211.000
203.000
271.000
88.360
78.360
73.360
86.360
tunnel tunnel tunnel tunnel
Enabling SIP Session Timer
SIP session timer is implemented in the SIP ALG as per RFC 4028.
SIP session timer defines a keep alive mechanism for the SIP sessions using the periodic session refresh requests from the user agents. The interval for the session refresh requests is determined through a negotiation mechanism. If a session refresh request is not received within the negotiated interval, the session is assumed to be terminated.
For more information on the SIP session timer support, See section 8.0, Proxy Behaviour in the RFC 4028.
This release of ArubaOS does not support the configurable Min-SE parameter for SIP ALG. Therefore, the ALG will not generate the 422 responses for the session refresh requests.
ArubaOS 6.5.3.x
| User Guide Voice and Video | 985
You can use the WebUI or CLI to enable the SIP session timer and set the session-expiry timer value using the
WebUI and CLI.
SIP Session Timer can be configured only for SIP over UDP.
In the WebUI
1. Navigate to the Configuration > Advanced services > All Profiles page.
2. Expand Other profiles under the Profiles section and click SIP Settings .
3. Enable the session timer by selecting the Session Timer check box under the Profile Details section.
4. Specify a timeout value in seconds in the Session Expiry field. The range is 240- 1200 seconds. The default value is 300 seconds.
Figure 214 Enabling SIP Session Timer
5. Click Apply .
In the CLI
To configure the session timer and the timeout value:
(host) #configure terminal
(host) (config) #voice sip
(host) (SIP settings) #session-timer
(host) (SIP settings) #session-expiry 400
To view the SIP settings on the controller:
(host) #show voice sip
SIP settings
------------
Parameter
---------
Value
-----
Session Timer Enabled
Session Expiry 400 sec
Dialplan Profile N/A
Enabling Wi-Fi Edge Detection and Handover for Voice Clients
Voice clients in an infrastructure can be switched to an alternate carrier or connection when they leave their active Wi-Fi coverage or roam to an area with poor Wi-Fi coverage. The controller uses the best Wi-Fi signal strength (dbm value) reported by the voice clients (received from all APs) to determine if the voice clients are within or leaving their active Wi-Fi connection. If the signal strength is weak, the controller will trigger the handover process to switch the voice client to an alternate carrier or connection. This process ensures QoS for voice calls.
986 | Voice and Video ArubaOS 6.5.3.x | User Guide
l The handover process is available for voice clients supporting the 802.11K standard and with the ability to transmit and receive beacon reports.
l
The voice clients should have dual mode capabilities to ensure that they can switch to an alternate network in case of a loss in Wi-Fi coverage.
The handover process can be configured using the wlan handover-trigger-profile command. Use the handover-threshold parameter to specify the threshold value (dbm) and enable the handover-trigger parameter. If the best signal strength reported by a voice client is equal to or less than the threshold value, the handover process is initiated.
In the WebUI
1. Navigate to the Configuration > Advanced Services > All Profiles page.
2. Expand Wireless Lan under the Profiles section.
3. Expand 802.11 K profile under Wireless Lan .
4. Select the default profile.
5. Select Advertise 802.1k Capability .
6. In the profiles list, note which Handover Trigger Feature Settings profile is associated with the selected
802l11k profile.
7. Expand Handover Trigger under Wireless Lan .
8. Select the handover trigger profile associated with the default 802.11k profile.
9. Select the Enable Handover Trigger feature checkbox
10.Specify the handover threshold value in the Threshold signal strength value at which handover
Trigger should be sent to the client field. The handover threshold value should be within the range 20 to 70 dbm. The default threshold value is -60 dbm.
11.Click
Apply .
In the CLI
The following command enables the dot11k profile and sets the handover threshold at -60dbm.
(host) (config) #wlan handover-profile default
(host) (802.11K Profile "default") #dot11k-enable
(host) (802.11K Profile "default") #handover-trigger-profile default
(host) (802.11K Profile "default") #exit
(host) (config) #wlan handover-trigger-profile default
(host) (Handover Trigger Profile) #handover-trigger
(host) (Handover Trigger Profile) #handover-threshold 60
The handover threshold value is a negative dbm value. In the CLI, enter the value without the negative (-) sign.
Working with Dial Plan for SIP Calls
A PSTN call from a SIP device usually requires the user to prefix 9 or 0 before the destination number. You can configure dial plans (prefix codes) on the controller that are required by the local EPABX system to provide outgoing PSTN call facility from a SIP device. After the dial plan is configured, a user can make SIP calls by dialing the destination number without any prefixes.
Dial plan can be configured only for SIP over UDP.
ArubaOS 6.5.3.x
| User Guide Voice and Video | 987
Understanding Dial Plan Format
The format of a SIP dial plan is
<sequence> <pattern> <action>
.
n n n sequence—is a number between 100 and 65535. The sequence number positions the dial plan in the list of dial plans configured in the controller.
pattern—is the digit pattern or the number of digits that will be dialed by the user. You can specify digit pattern using ‘X’, ‘Z’, ‘N’, ‘[]’, and ‘.’.
l l
X is a wild card that represents any character from 0 to 9.
Z is a wild card that represents any character from 1 to 9.
l l
N is a wild card that represents any character from 2 to 9.
. (period) is a wild card that represents any-length digit strings.
action—is the prefix code that is automatically prefixed to the dialed number. This is specified as <prefixcode>%e . Examples of prefix codes are: l l
9%e: The number 9 is prefixed to the dialed number.
91%e: The number 91 is prefixed to the dialed number.
Table 244: Examples of Dial Plans
Dialplan
Pattern
XXXX
Action Description
XXXXXXX
XXXXXXXXXX
+1XXXXXXXXXX
+.
%e
9%e
91%e
When the user dials a four digit number, no action is taken and the call is allowed.
When the user dials a seven digit number, a nine ( 9 ) is prefixed to that number and the call is executed.
Example, if the user dials 2274500, the call is executed by adding 9 to the number, 92274500.
This dial plan prefixes 91 to the dialed number.
Example, call to 4082274500 will be executed as 914082274500.
9%e This dial plan replaces ‘ + ’ with 9 and executes the call.
Example, call to +14082274500 is executed as 914082274500.
9011%e This dial plan removes ‘+’ and prefixes 9011 for an international call.
Example, call to +886212345678 is executed as 9011886212345678.
Configuring Dial Plans
You can configure a maximum of two dial plan profiles and maximum of 20 dial plans per profile. The dial plan must be associated to a SIP ALG configuration.
To configure a dial plan for SIP devices:
1. Create a voice dial plan.
2. Associate the dial plan with SIP ALG.
In the WebUI
1. In the WebUI, navigate to Configuration > Advanced Services > All Profiles > Controller > Dialplan
Profile . Enter a name for the dial plan profile and click Add .
988 | Voice and Video ArubaOS 6.5.3.x | User Guide
Figure 215 Dialplan Profile
2. Under Profiles , expand Controller and select the newly created dial plan profile. Enter the following dial plan details and click Add .
n n n
Sequence number: the dial plan position in the list of dial plans
Pattern: the number that the user will dial
Action: prefix to be added by the controller before forwarding the call to the EPABX
Figure 216 Dialplan Details
3. Click Apply .
4. Under Profile , navigate to Controller > SIP settings and select Dialplan Profile.
In the Profile Details section, select the Dialplan Profile from the drop-down list and click Apply .
ArubaOS 6.5.3.x
| User Guide Voice and Video | 989
Figure 217 Select Dialplan Profile
The Dialplan Profile displays the dial plan details:
Figure 218 View Dialplan Details
In the CLI
To create a voice dial plan profile:
(host) (config) #voice dialplan-profile local
(host) (Dialplan Profile "local") #dialplan 100 XXXXXXX 9%e
(host) (Dialplan Profile "local") #!
To associate the dial plan with SIP ALG:
(host) (config) #voice sip
(host) (SIP settings) #dialplan-profile local
(host) (SIP settings) #!
To view the SIP dial plan profile:
(host) (config) #show voice sip
SIP settings
------------
Parameter
---------
Value
-----
Dialplan Profile local
To view the dial plan details:
(host) (config) #show voice dialplan-profile local
Dialplan Profile "local"
990 | Voice and Video ArubaOS 6.5.3.x | User Guide
---------------------------
Parameter Value
------------dialplan 100 XXXXXXX 9%e
Enabling Enhanced 911 Support
ArubaOS provides seamless support for emergency calls in the Aruba network by interoperating with RedSky emergency call server. The controller uses SNMP to interoperate with RedSky call handling system.
This release of ArubaOS supports only RedSky emergency call server.
You must configure the RedSky server as an SNMP host and enable SNMP traps to activate the E911 feature on the controller. For more information on configuring the RedSky server as SNMP host, see
Configuring SNMP on page 871 .
The E911 support has the following basic functions: n n n location tracking call handling caller identification and callback capability
For information on call handling, caller identification and callback capability, see the RedSky documentation.
The controller tracks the location of the voice clients and notifies the emergency call server using SNMP traps.
The controller notifies the location of a voice client to the emergency server: n n n n when it identifies a voice client when a voice client roams from one access point to another access point in the same controller when a voice client roams from one access point to another access point in a different controller when a voice client registers with a PBX system
The notification process ensures that the emergency call server is notified whenever a voice client is identified or the location of the client is updated. If a voice client roams outside of a WLAN coverage, the controller does not send any notifications to the emergency call handling system. This may happen when there is a sudden loss of WLAN coverage due to extreme conditions such as fire accident. In such cases, the last associated access point will be the location of the voice client.
The controller tracks the location only for voice clients. To track the location of a remote voice client, the administrator must configure the location of the remote access point in the controller or emergency call server.
The emergency call server queries the controller using the SNMP :get: request to get the location of a specific emergency caller. In response to the location query, the controller sends the following parameters to the emergency server: n n n n n n n
Client IP Address
Client Mac Address
AP Name
AP Wired MAC
AP Location
AP Mode
Controller IP Address
ArubaOS 6.5.3.x
| User Guide Voice and Video | 991
The controller also supports location queries for the clients that are not identified as voice clients on the controller.
Working with Voice over Remote Access Point
Voice traffic support is enhanced on split tunnel mode over a remote access point. The voice traffic management for remote and local users are done on the controller. However, the sessions are created differently for both users. For remote users, the sessions are created on the remote access point and for local users, the sessions are created on the controller. This enhancement provides the following support for the voice traffic in the split tunnel over remote access point: n n n voice traffic QoS is consistent for both local and remote users all voice ALGs work reliably in split tunnel mode when the PBX traffic is destined to flow through the corporate network.
provides voice statistics and counters for remote voice clients in the split tunnel mode
The flag parameter in the show voice client-status command is updated to indicate remote users:
(host) #show voice client-status
Voice Client(s) Status
----------------------
AP Name BSSID ESSID Client(MAC)
Registration State Call Status ALG Flags
Client(IP) Client Name Server(IP)
--------------- -----------
-------------------------------
-------------------moscato 00:0b:11:5c:d6:80 home 00:00:5c:04:b3:10 10.20.1.100
Client
REGISTERED Idle h323 R
----------
10.13.8.1
--
Num Clients:1
Flags: R - Remote user
Understanding Battery Boost
Battery boost is an optional feature that can be enabled for any SSIDs that support voice traffic. This feature converts all broadcast and multicast traffic to unicast before delivery to the client. Enabling battery boost on an SSID allows you to set the DTIM interval from 10 to 100 (the previous allowed values were 1 or 2), equating to 1,000 to 10,000 milliseconds. This longer interval keeps associated wireless clients from activating their radios for multicast indication and delivery, leaving them in power-save mode longer, and thus lengthening battery life. The DTIM configuration is performed on the WLAN, so no configuration is necessary on the client.
An associated parameter available on some clients is the Listening Interval (LI). This defines the interval (in number of beacons) after which the client must wake to read the Traffic Indication Map (TIM). The TIM indicates whether there is buffered unicast traffic for each sleeping client. With battery boost enabled, the
DTIM is increased but multicast traffic is buffered and delivered as unicast. Increasing the LI can further increase battery life, but can also decrease client responsiveness.
Do not enable battery boost if your network includes Polycom SpectraLink devices that use the Push-to-Talk feature.
You can use the WebUI or CLI to enable the battery boost feature and set the DTIM interval in the SSID profile.
In the WebUI
1. Navigate to the Configuration > AP Configuration page. Select either the AP Group tab or AP Specific tab.
992 | Voice and Video ArubaOS 6.5.3.x | User Guide
l l
If you selected AP Group , click Edit by the AP group name for which you want to enable battery boost.
If you selected AP Specific , select the name of the AP for which you want to enable battery boost.
2. Under Profiles , select Wireless LAN , then Virtual AP . In the Virtual AP list, select the appropriate virtual
AP instance.
3. In the Profile Details section, select the SSID profile you want to configure.
4. Click the Advanced tab.
5. Scroll down the Advanced options and select the Battery Boost check box.
6. Scroll up to change the DTIM Interval to a longer interval time.
7. Click Apply .
In the CLI
Use the following commands: wlan ssid-profile <profile>
battery-boost
dtim-period <milliseconds>
Enabling LLDP
Link Layer Discovery Protocol (LLDP), is a Layer-2 protocol that allows network devices to advertise their identity and capabilities on a LAN. Wired interfaces on Aruba APs support LLDP by periodically transmitting
LLDP Protocol Data Units (PDUs) comprised of selected type-length-value (TLV) elements. For a complete list of supported, see
and
.
LLDP-MED (media endpoint devices) is an extension to LLDP that supports interoperability between VoIP and video streaming devices and other networking clients. LLDP-MED network policy discovery lets end-points and network devices advertise the VLAN, priority levels, and DSCP values used by a voice or video application.
In the WebUI
Use the procedure below to configure the LLDP and LLDP-MED profiles and select the TLVs to be sent by the
AP.
1. Navigate to the Configuration > AP Configuration page. Select either the AP Group or AP Specific .
l
If you selected AP Group , click Edit by the AP group name for which you want to enable LLDP.
l
If you selected AP Specific , select the name of the AP for which you want to enable LLDP.
2. In the Profiles window, expand AP , then expand the Ethernet interface port configuration profile for the port for which you want to configure LLDP.
3. Select the AP LLDP Profile .
Figure 219 AP LLDP Profile Details
4. The AP LLDP profile is divided into two tabs, Basic and Advanced . The Basic tab displays only those configuration settings that often need to be adjusted to suit a specific network. The Advanced tab shows
ArubaOS 6.5.3.x
| User Guide Voice and Video | 993
all configuration settings, including settings that do not need frequent adjustment or should be kept at their default values. If you change a setting on one tab, then click and display the other tab without saving your configuration, that setting will revert to its previous value. Both basic and advanced settings are described in
5. Configure the LLDP profile parameters as desired then click
Table 245: LLDP Profile Configuration Parameters
Parameter Description
Basic Settings
PDU Transmission
Reception of LLDP PDUs
Select this checkbox to enable LLDP PDU Transmission. PDU Transmission is enabled by default.
Select this checkbox to enable LLDP PDU Reception. PDU Reception is enabled by default.
Advanced Settings
Transmit Interval (seconds)
Transmit hold multiplier
Optional TLVs
The interval between LLDP TLV transmission seconds. Range: 1-3600, seconds and Default: 30 seconds.
The Transmit hold multiplier is a value that is multiplied by the transmit interval to determine the number of seconds to cache learned LLDP information before that information is cleared.
If the Transmit hold multiplier value is set at its default value of 4, and the
Transmit interval is at its default value of 30 seconds, then learned LLDP information will be cached for 4x30 seconds, or 120 seconds.
Click the checkboxes in this section to select the optional TLVs the AP interface sends in LLDP PDUs. The AP will send all optional TLVs by default.
n port-description: transmit a TLV that gives a description of the AP’s wired port in an alphanumeric format.
n n system-description : transmit a TLV that describes the AP’s model number and software version.
system-name : transmit a TLV that sends the AP name or wired MAC address.
n n capabilities : transmit the system capabilities TLV to indicate which capabilities are supported by the AP.
management-address : transmit a TLV that indicates the AP’s management IP address, in either IPv4 or IPV6 format.
994 | Voice and Video ArubaOS 6.5.3.x | User Guide
Parameter
802.1 TLVs
802.3 TLVs
LLDP-MED TLVs
Description
Click the checkboxes in this section to select the 802.1 TLVs the AP interface sends in LLDP PDUs. The AP will send all 802.1 TLVs by default: n port-vlan : transmit the LLDP 802.1 port VLAN TLV. If the native VLAN is configured on the port, the port-vlan TLV will send that value, otherwise it will send a value of “0”.
n vlan-name : transmit the LLDP 802.1 VLAN name TLV. The AP sends a value of "Unknown" for VLAN 0, or "VLAN <number>" for all non-zero
VLAN numbers.
Click the checkboxes in this section to select the 802.3 TLVs the AP interface sends in LLDP PDUs. The AP will send all 803.2 TLVs by default: n mac : transmit the 802.3 MAC/PHY Configuration/Status TLV to indicate the AP interface’s duplex and bit rate capacity and current duplex and bit rate settings.
n n n link-aggregation : transmit the 802.3 link aggregation TLV to indicate that link aggregation is not supported.
mfs : transmit the 802.3 Maximum Frame Size (MFS) TLV to show the
AP’s maximum frame size capability.
power :transmit the 802.3 Power Via media dependent interface (MDI)
TLV to show the power support capabilities of the AP interface.
This parameter is supported by the RAP-3WNP and 130 Series only.
Once you have associated an LLDP-MED Network policy profile with this
LLDP profile, you can click the checkboxes in this section to select the
LLDP-MED TLVs the AP interface sends in LLDP PDUs. The AP does not send any LLDP-MED TLVs by default: n capabilities : transmit the LLDP-MED capabilities TLV. The AP will automatically send this TLV if it sends any other LLDP-MED TLVs.
n n inventory : transmit the LLDP-MED inventory TLV.
network-policy : transmit the LLDP-MED network-policy TLV.
NOTE: The TLVs in this section cannot be enabled unless you have associated an LLDP-MED Network policy profile
6. Click Apply .
7. To associate an LLDP-MED network policy profile with the LLDP profile and select the LLDP-MED TLVs to be sent by the AP interface, click the LLDP-MED network policy profile that appears below the AP LLDP profile in the profile list:
Figure 220 AP LLDP Profile Details
8. If the LLDP profile does not currently reference an LLDP-MED profile, you must associate an LLDP-MED profile with the LLDP profile before you can configure any LLDP-MED settings. Click the Add a profile drop-down list in the Profile Details window.
n
To associate an existing LLDP-MED network policy, click an LLDP-MED policy name, then click Add .
ArubaOS 6.5.3.x
| User Guide Voice and Video | 995
n
To create a new LLDP-MED policy, click NEW, enter a name for the LLDP-MED network policy, then click
Add .
9. Click Apply .
10.Next, expand the LLDP-MED network policy profile in the Profiles list, and select the profile you want to configure.
11.The LLDP-MED network policy profile is divided into two tabs, Basic and Advanced . The Basic tab displays only those configuration settings that often need to be adjusted to suit a specific network. The Advanced tab shows all configuration settings, including settings that do not need frequent adjustment or should be kept at their default values. If you change a setting on one tab, then click and display the other tab without saving your configuration, that setting will revert to its previous value. Both basic and advanced settings are described in
.
12.Configure the LLDP-MED profile parameters as desired then click
Table 246: LLDP-MED Profile Configuration Parameters
Parameter Description
Basic Settings
LLDP-MED application type
LLDP-MED application VLAN
LLDP-MED application VLAN tagging
Click the LLDP-MED application type drop-down list and select the application type managed by this profile.
n guest-voice : if the AP services a separate voice network for guest users and visitors.
n n n guest-voice-signaling : if the AP is part of a network that requires a different policy for guest voice signaling than for guest voice media. Do not use this application type if both the same network policies apply to both guest voice and guest voice signaling traffic.
softphone-voice : if the AP supports voice services using softphone software applications on devices such as PCs or laptops.
streaming-video : if the AP supports broadcast or multicast video or other streaming video services that require specific network policy treatment. This application type is not recommended for video applications that rely on TCP with buffering.
n n n n video-conferencing : of the AP supports video conferencing equipment that provides real-time, interactive video/audio services.
video-signaling : if the AP is part of a network that requires a different policy for video signaling than for the video media. Do not use this application type if both the same network policies apply to both video and video signaling traffic.
voice : if the AP services IP telephones and other appliances that support interactive voice services. This is the default application type.
voice-signaling : Select this application type if the AP is part of a network that requires a different policy for voice signaling than for the voice media. Do not use this application type if both the same network policies apply to both voice and voice signaling traffic.
Specify a VLAN by VLAN ID (0-4094) or VLAN name.
Click this checkbox if the LLDP-MED policy applies to a to a VLAN that is tagged with a VLAN ID or untagged. The default value is untagged.
NOTE: When an LLDP-MED network policy is defined for use with an untagged VLAN, then the L2 priority field is ignored and only the DSCP value is used.
996 | Voice and Video ArubaOS 6.5.3.x | User Guide
Parameter
Advanced Settings
LLDP-MED application Layer-2 priority
LLDP-MED application
Differentiated Services Code
Point
Description
Specify a 802.1p priority level for the specified application type, by entering a value from 0 to 7, where 0 is the lowest priority level and 7 is the highest priority.
Select a Differentiated Services Code Point (DSCP) priority value for the specified application type by specifying a value from 0 to 63, where 0 is the lowest priority level and 63 is the highest priority.
13.Click
Apply .
In the CLI
Use the following command: ap lldp profile <profile> clone <profile> dot1-tlvs port-vlan|vlan-name dot3-tlvs link-aggregation|mac|mfs|power lldp-med-network-policy-profile <profile> lldp-med-tlvs capabilities|inventory|network-policy no ...
optional-tlvs capabilities|management-address|port-description|system-description|systemname receive transmit transmit-hold <transmit-hold> transmit-interval <transmit-interval> ap lldp med-network-policy-profile <profile> application-type guest-voice|guest-voice-signaling|softphone-voice|streaming-video|videoconferencing|video-signaling|voice|voice-signaling clone <profile> dscp <dscp> l2-priority <l2-priority> no ...
tagged vlan <vlan>
The following commands create a LLDP MED network policy profile for streaming video applications and marks streaming video as high-priority traffic:
(host) (config) ap lldp med-network-policy-profile vid-stream
(host) (AP LLDP-MED Network Policy Profile "vid-stream") dscp 48
(host) (AP LLDP-MED Network Policy Profile "vid-stream")l2-priority 6
(host) (AP LLDP-MED Network Policy Profile "vid-stream")tagged
(host) (AP LLDP-MED Network Policy Profile "vid-stream")vlan 10
(host) (AP LLDP-MED Network Policy Profile "vid-stream")!
Next, the LLDP MED network policy profile is assigned to an LLDP profile, and the LLDP profile is associated with an AP wired-port profile:
(host) (config) ap lldp profile video1
(host) (AP LLDP Profile "video1")lldp-med-network-policy-profile vid-stream
(host) (AP LLDP Profile "video1")!
(host) (config)ap wired-port-profile corp2
(host) (AP wired port profile "corp2")lldp-profile video1
ArubaOS 6.5.3.x
| User Guide Voice and Video | 997
Advanced Voice Troubleshooting
ArubaOS enables you to debug voice issues more efficiently and quickly by providing detailed information about the voice calls, voice client status, and Call Detail Records (CDR). You can obtain the advanced troubleshooting information such as time of failure of the call, status of the client during the call failure, signal strength of the call, AP handoff information, and signaling message issues.
The following options allow you to easily troubleshoot voice call issues: n n n n n
View troubleshooting information on voice client status
View troubleshooting information on voice call CDRs
Debug voice logs
View voice traces
View voice configuration details
Viewing Troubleshooting Details on Voice Client Status
ArubaOS enables you to view the status of the voice clients. Additionally, it allows you to view more details such as AP handoff information and AP station report of an active call based on the client's IP address, or the
MAC address.
The AP handoff information includes the AP events such as association request, re-association request, and deauthentication request with timestamps. The AP station report includes the AP MAC address, association time, average RSSI value, and retries count.
You can use the WebUI or CLI to view up to 60 entries of AP events and 30 entries of AP station reports for a voice client.
In the WebUI
1. Navigate to the Monitoring > Voice > Voice Clients page and select the voice client.
2. Click HandOff Information to view the AP station report and AP handoff information of the selected voice client.
In the CLI
To view the details of a voice client based on its IP address:
(host) #show voice client-status ip 10.15.20.63
Voice Client(s) Status
----------------------
Client(IP) Client(MAC)
Status BSSID ESSID
Client Name ALG Server(IP)
AP Name Flags
Registration State Call
--------------------
----------
----------------------
-----------
------------------
10.15.20.63
00:00:f0:05:c9:e3 7812 h323 10.3.113.239
REGISTERED
00:0b:86:b7:83:91 st-voice-raj RAP2-Lab R
---------
In-Call
Num Clients:1
Flags: V - Visitor, W - Wired, R - Remote
AP Events
---------
Timestamp
---------
BSS Id
------
Category
--------
Aug 13 09:22:57 00:0b:86:b7:83:91 Call
Event
-----
Call Start
Aug 13 11:29:34 00:0b:86:b7:83:91 Call
Aug 13 11:29:41 00:0b:86:b7:83:91 Call
Aug 13 11:30:29 00:0b:86:b7:83:91 Call
Aug 13 11:30:39 00:0b:86:b7:83:91 Call
Call End
Call Start
Call End
Call Start
998 | Voice and Video ArubaOS 6.5.3.x | User Guide
AP Station Reports
------------------
Timestamp
Bytes
BSS Id
Tx-Data-Time Rx
RSSI Tx
Rx-Retry
Tx-Drop Tx-Data Tx-Data-Retry Tx-Data-
---------
--
0
------------
Aug 13 12:35:05
------
---------
-----
00:0b:86:b7:83:91
55171662 0
61
-------
253845 6904
-------
253469
-------------
59805
-----------
22945603
Current Active Calls
--------------------
Session Information Peer Party Dir Status value Codec Band Setup Time(sec) Re-Assoc
-----------------------------------
---------------------------------
10.15.20.56:3034 - 10.15.20.63:3140
NA NA NA 0
-
Dur(sec)
--------
IC CONNECTED 3925
Orig time
---------
Aug 13 11:30:39
R-
--
NA
To view the details of a voice client based on its MAC address:
(host) #show voice client-status sta 00:00:f0:05:c9:dc
Voice Client(s) Status
----------------------
Client(IP) Client(MAC)
Status BSSID
--------------------
----------
-----------
-----------
------------
10.15.20.56
Client Name ALG Server(IP)
ESSID AP Name Flags
00:00:f0:05:c9:dc 7811
00:1a:1e:a8:2d:80 legap AP-Test
Registration State
-----------------sh323 10.3.113.239
REGISTERED
Call
---------
In-Call
Num Clients:1
Flags: V - Visitor, W - Wired, R - Remote
AP Events
---------
Timestamp BSS Id Category Event
-------------------------
Aug 13 09:22:54 00:1a:1e:a8:2d:80 Call Call Start
Aug 13 09:22:58 00:1a:1e:a8:2d:80 Call
Aug 13 09:26:22 00:1a:1e:a8:2d:80 Call
Aug 13 11:29:33 00:1a:1e:a8:2d:80 Call
Aug 13 11:29:39 00:1a:1e:a8:2d:80 Call
Aug 13 11:30:29 00:1a:1e:a8:2d:80 Call
Aug 13 11:30:36 00:1a:1e:a8:2d:80 Call
Call End
Call Start
Call End
Call Start
Call End
Call Start
AP Station Reports
------------------
Timestamp
Bytes
BSS Id
Tx-Data-Time Rx
RSSI Tx
Rx-Retry
Tx-Drop Tx-Data Tx-Data-Retry Tx-Data-
---------
--
0
------------
Aug 13 12:38:03
------
---------
-----
00:1a:1e:a8:2d:80
58366710 0
44
-------
795216 44158
-------
794838
-------------
147824
-----------
78010395
Current Active Calls
--------------------
Session Information Peer Party Dir Status value Codec Band Setup Time(sec) Re-Assoc
Dur(sec) Orig time R-
ArubaOS 6.5.3.x
| User Guide Voice and Video | 999
-----------------------------------
---------------------------------
10.15.20.63:3140 - 10.15.20.56:3034
NA GREEN NA
-
0
--------
OG CONNECTED 4079
---------
Aug 13 11:30:36
--
93
Viewing Troubleshooting Details on Voice Call CDRs
ArubaOS allows you to view the voice CDRs for the completed calls. Additionally, it enables you to view more details such as AP handoff information and AP station reports for a specific terminated call based on the CDR
Id.
The AP handoff information includes the AP events such as association request, re-association request, and deauthentication request with timestamps. The AP station report includes the AP MAC address, association time, average RSSI value, and retries count.
ArubaOS pushes the generated CDRs to the syslog server to retain the older CDR data for a later analysis. The CDR data pushed to the syslog server do not contain the details of the AP stats and AP events.
You can use the WebUI or CLI to view the troubleshooting information on a voice call based on the CDR Id.
In the WebUI
1. Navigate to the Monitoring > Voice > Call Detail Report page.
This page displays the CDRs of the completed calls.
2. Click the CDR Id of a call to view the AP station reports, and the AP handoff information of the call.
In the CLI
To view the details of a completed call based on the CDR Id:
(host) #show voice call-cdrs cid 4
Voice Client(s) CDRs (Detail)
-----------------------------
CDR Id Client IP Client Name ALG Dir Called/Calling Party Status Dur(sec) Orig time
R-value Reason Codec Band Setup Time(sec) Re-Assoc Initial-BSSID Initial-
ESSID Initial-AP Name
-------------------------------------------------------------------
------------------------------------------------------------
------------------
4 10.15.20.62
06:48:44 77
AP-Test
3011 sccp IC 3042
G711 YELLOW 0 1
SUCC 34 Aug 14
00:1a:1e:a8:2d:80 legap
AP Events
---------
Timestamp
---------
BSS Id
------
Category
--------
Event
-----
Aug 14 06:48:53 00:1a:1e:a8:2d:80 AP Management Assoc Req
Aug 14 06:48:53 00:1a:1e:a8:2d:80 AP Management Assoc Resp
AP Station Reports
------------------
Timestamp BSS Id
Bytes Tx-Data-Time Rx
--------------
-------------
Rx-Retry
RSSI Tx
-----
--------
Tx-Drop Tx-Data Tx-Data-Retry Tx-Data-
------------------------------------
1000 | Voice and Video ArubaOS 6.5.3.x | User Guide
Aug 14 06:49:08 00:1a:1e:a8:2d:80 27
0 26245 0
20466 6154 20460 2522 2310190
Enabling Voice Logs
ArubaOS allows you to debug voice logs. Additionally, it allows you to debug the voice logs for a specific voice client based on the client's MAC address.
You can use the WebUI or CLI to set the voice logging level to debugging.
In the WebUI
1. Navigate to the Configuration > Management > Logging page.
2. Click Levels .
3. Select the voice check box under the User Logs category.
4. Select Debugging from the Log Level drop down menu and click the Done button.
Figure 221 Enable Voice Logging
5. Click Apply .
Enabling Logging for a Specific Client
1. Navigate to the Configuration > Advanced Services > All Profiles page.
2. Expand Other Profiles under the Profiles section and click VoIP Logging .
3. Enter the MAC address of the voice client in the Client's MAC address for logging field.
Figure 222 Enable Logging for a Voice Client
4. Click Apply .
To enable logging on a specific voice client, you must enable voice logs.
In the CLI
To set the voice logging level to debugging:
(host) #configure terminal
(config) #logging level debugging user subcat voice
To debug voice logs for a specific client:
(config) #voice logging
ArubaOS 6.5.3.x
| User Guide Voice and Video | 1001
(VoIP Logging) #client-mac 11:22:33:44:55:67
To view the client's MAC address for logging:
(host) #show voice logging
VoIP Logging
------------
Parameter Value
-------------
Client's MAC Address for Logging 11:22:33:44:55:67
Viewing Voice Traces
ArubaOS enables you to view the voice signaling message traces. You can view up to 8000 entries of trace messages. The trace message displays the ALG, client name, client's IP, event time, and the message direction.
Additionally, it displays the BSSID information to help troubleshooting roaming issues.
You can use the WebUI or CLI to view the trace messages.
In the WebUI
1. Navigate to the Monitoring > Voice > Voice Clients page and select the voice client.
2. Click Troubleshooting to view the voice traces.
In the CLI
To view the voice signaling message traces:
(host)#show voice trace sip count 5
SIP Voice Client(s) Message Trace
---------------------------------
ALG Client Name Client(MAC)
BSSID
Client(IP) Event Time Direction Msg
-----------------------
-----
SIP 6202 00:03:2a:02:75:cc
00:0b:86:b7:83:91
----------
10.15.20.123
----------
Aug 14 13:14:32
---------
Server-To-Client
---
200_OK
SIP 6202
SIP
SIP
6202
6202
00:03:2a:02:75:cc 10.15.20.123
Aug 14 13:14:32 Client-To-Server REGISTER
00:0b:86:b7:83:91
00:03:2a:02:75:cc 10.15.20.123
Aug 14 13:14:31 Server-To-Client 200_OK
00:0b:86:b7:83:91
00:03:2a:02:75:cc 10.15.20.123
Aug 14 13:14:31 Client-To-Server REGISTER
00:0b:86:b7:83:91
SIP 6202 00:03:2a:02:75:cc 10.15.20.123
Aug 14 13:14:29 Server-To-Client 4XX_
REQUEST_FAILURE 00:0b:86:b7:83:91
Num of Rows:5
Viewing Voice Configurations
ArubaOS allows you to view the details of the voice related configurations on your controller such as firewall policies, AP group profiles, SSID profiles, virtual AP group profiles, VoIP Call Admission Control profiles, 802.11k
profiles, and SIP settings. Additionally, you can view the status of RTCP analysis, and SIP mid-call request timeout.
This release of ArubaOS does not support viewing the voice configuration details using the WebUI.
In the CLI
To view the voice configuration details on your controller:
1002 | Voice and Video ArubaOS 6.5.3.x | User Guide
(host) #show voice configurations
Voice firewall policies
-----------------------
Policy
------
Stateful SIP Processing
Broadcast-filter ARP
Action
------
Enabled
Disabled
SSID Profiles
-------------
Profile Name
EDCA AP prof Strict SVP
WMM
------------
--------------------
---
WMM-UAPSD
---------
Enabled Enabled
TSPEC Min Inactivity(msec)
--------------------------
100000
...
...
...
EDCA STA prof
------------default
default default qa-ma-vocera default
Disabled
Disabled
Enabled Enabled 0 default
AP Group Profiles
-----------------
Profile Name VoIP CAC Profile
--------------------------default local default default
Virtual AP Group Profiles
-------------------------
Profile Name 802.11K Profile HA Discovery on-assoc.
Drop Broadcast/Multicast
Broadcast ARP to Unicast
------------
------------------
-------------------------------------------------------------abcd
Disabled default Disabled Disabled
VoIP Call Admission Control Profiles
------------------------------------
Profile Name VoIP CAC
-------------------default Disabled
802.11K Profiles
----------------
Profile Name Advertise 802.11K Capability
--------------------------------------default Disabled
SIP settings
------------
Parameter
---------
Value
-----
Session Timer
Session Expiry
Disabled
300 sec
Dialplan Profile N/A
Voice rtcp-inactivity:disable
Voice sip-midcall-req-timeout:disable
ArubaOS 6.5.3.x
| User Guide Voice and Video | 1003
Chapter 41
AirGroup
AirGroup is a unique enterprise-class capability that leverages zero configuration networking to allow mobile device technologies, such as the AirPrint™ wireless printer service and the AirPlay™ mirroring service, to communicate over a complex access network topology.
Zero Configuration Networking
Zero configuration networking is a technology that enables service discovery, address assignment, and name resolution for desktop computers, mobile devices, and network services. It is designed for flat, single-subnet IP networks such as the home network of a user.
The suite of protocols introduced by Apple® for zero configuration networking over IP is referred to as
Bonjour®. Bonjour is supported by most of the Apple product lines including the Mac OS X® operating system, iPhone®, iPod®, iPad®, Apple TV® and AirPort Express®. Bonjour is also included within popular software programs such as Apple iTunes®, Safari, and iPhoto®. Bonjour® can be installed on computers running Microsoft Windows® and is supported by most new network-capable printers.
Bonjour locates devices such as printers, other computers, and the services offered by these devices by using multicast Domain Name System (mDNS) service records. Bonjour uses the link-scope multicast addresses, so each query or advertisement is limited to a specific VLAN. In large universities and enterprise networks,
Bonjour capable devices connect to the network using different VLANs. As a result, an iPad on one enterprise
VLAN will not be able to discover the Apple TV that resides on another VLAN. Broadcast and multicast traffic is filtered out of a wireless LAN network in an effort to reduce network traffic. This inhibits Bonjour (mDNS) services, which rely on multicast traffic.
ArubaOS supports DLNA (Digital Living Network Alliance); a network standard that is derived from UPnP
(Universal Plug and Play) in addition to the mDNS protocol. DLNA uses the Simple Service Discovery Protocol
(SSDP) for service discovery on the network. DLNA provides the ability to share digital media between multimedia devices, like Windows and Android, similar to how mDNS supports Zero Configuration Networking to Apple devices and services. ArubaOS ensures that DLNA seamlessly works with the current mDNS implementation. All the features and policies that are applicable to mDNS are extended to DLNA. This ensures full interoperability between compliant devices.
AirGroup Solution
AirGroup leverages key elements of Aruba’s solution portfolio including the ArubaOS software for Aruba controllers and Aruba ClearPass Policy Manager (CPPM).
AirGroup performs the following functions: n n n n
Enables users to discover network services across IP subnet boundaries in enterprise wireless and wired networks.
Enables users to access the available AirGroup services such as AirPrint and AirPlay.
Permits users to access conference room Apple TV during presentations, based on group-based access privileges.
Provides and maintains seamless connectivity of clients and services across VLANs and SSIDs. It minimizes the mDNS traffic across the wired and wireless network, thereby preserving wired network bandwidth and
WLAN airtime.
With AirGroup:
ArubaOS 6.5.3.x
| User Guide AirGroup | 1004
n n n n n n
An AirGroup operator—an end user such as a student can register personal devices. The devices registered by the operator can then automatically be shared with each other.
Each user can create a user group, such as friends and roommates with whom the user can share the registered devices.
AirGroup administrators can register and manage an organization’s shared devices such as printers or conference room Apple TV. The administrator can grant global access to each device, or limit access based on user name, role, or location.
This chapter provides configuration information for network administrators to enable AirGroup on an Aruba controller and CPPM and to register devices with ClearPass Guest.
AirGroup also enables context awareness for services across the network:
AirGroup is aware of personal devices. An Apple TV in a dorm room, for example, can be associated with the student who owns it.
AirGroup is aware of shared resources, such as an Apple TV in a meeting room, a printer available to multiple users, or AirPlay in a classroom where a laptop screen is projected on HDTV monitor.
AirGroup is aware of the location of services—for example, an iPad is presented with the closest printer location instead of all the printers in the building. If a user in a conference room wants to use an Apple TV receiver to project a MacBook screen on an HDTV monitor, the location-aware controller shows the Apple
TV that is closest to that user.
AirGroup Services
The AirGroup supports zero configuration services. The services are pre configured and are available as part of the factory default configuration. The administrator can also enable or disable individual services by using the controller WebUI.
The following services are enabled by default on the controller: n n n
AirPlay — Apple AirPlay allows wireless streaming of music, video, and slide shows from your iOS device to
Apple TV and other devices that support the AirPlay feature.
AirPrint — Apple AirPrint allows you to print from an iPad, iPhone, or iPod Touch directly to any AirPrint compatible printers.
DIAL — Wi-Fi-enabled streaming devices like Google Chromecast, Roku, Amazon FireTV, and more advertise the Discovery and Launch (DIAL) protocol for clients to search for an available device on a wireless network.
Once a device is discovered, the protocol synchronizes information on how to connect to the device. The streaming device connects to a television through an HDMI port to wirelessly stream video and music content to the TV screen from smart phone (both Android and Apple iOS), tablet, laptop or desktop computer devices.
The following services are disabled by default on the controller: n n n n n iTunes — iTunes service is used by iTunes Wi-Fi sync and iTunes home-sharing applications across all Apple devices. For best practices, see the
Apple iTunes Wi-Fi Synchronization and File Sharing on page 1016 .
RemoteMgmt — Use this service for remote login, remote management, and FTP utilities on Apple devices.
Sharing — Applications such as disk sharing and file sharing, use the service ID that are part of this service on one or more Apple devices. For best practices, see the
Apple iTunes Wi-Fi Synchronization and File
.
Chat — The iChat (Instant Messenger) application on Apple devices uses this service.
GoogleCast — Google Chromecast uses this service to stream video and music content from a smart phone to a TV screen using a wireless network. If this service is manually configured before the controller is upgraded to ArubaOS 6.4.1, the service continues to remain in the existing state.
1005 | AirGroup ArubaOS 6.5.3.x | User Guide
n n
DLNA Media — Applications such as Windows Media Player use this service to browse and play media content on a remote device.
DLNA Print — This service is used by printers which support DLNA.
AirGroup also supports custom and allowall services. For more information, see
Integrated Deployment Model on page 1020
and
Enabling the allowall Service on page 1025
.
AirGroup Solution Components
AirGroup leverages key elements of Aruba’s solution portfolio that includes the ArubaOS software for Aruba controllers, CPPM, and ClearPass Guest.
describes the supported versions for each portfolio.
Table 247: AirGroup Solution Component Supported
Version
Component Minimum Version
ArubaOS ( Controller) 6.4
CPPM and ClearPass Guest 6.0.2
It is recommended to use CPPM and ClearPass Guest version 6.3.
AirGroup and ClearPass Policy Manager
The AirGroup feature and CPPM work together to allow users to share personal devices.
n n n
An AirGroup administrator uses ClearPass Policy Manager to authorize end users to register their personal devices.
An AirGroup operator, an end user, registers devices (such as an Apple TV).
Aruba controllers query ClearPass Policy Manager to associate the access privileges of each mobile device to its allowed services.
shows the AirGroup workflow that allows a user to register personal devices and use AirPlay to send an image from an iPhone to an Apple TV.
ArubaOS 6.5.3.x
| User Guide AirGroup | 1006
Figure 223 AirGroup Enables Personal Device Sharing
AirGroup enables context awareness for services across the network and supports a typical customer environment with shared, local, and personal services available to mobile devices. For example, in
an AirGroup administrator registers the shared devices in ClearPass, and AirGroup operators register their personal devices in the ClearPass Guest portal. The AirGroup-enabled controller sends AirGroup queries to
ClearPass for the registered devices' information. ClearPass sends the Change of Authorization (CoA) to notify the controller about the registered devices.
Figure 224 AirGroup in a Typical Wireless Deployment
AirGroup deployments that include both CPPM and an AirGroup controller support features that are described in
AirGroup Services on page 1005
.
1007 | AirGroup ArubaOS 6.5.3.x | User Guide
AirGroup Integrated Deployment Model
In the integrated deployment model, AirGroup features are integrated with WLAN controllers that terminate
APs and provide WLAN services. This deployment model also supports optional integration with ClearPass
Policy Manager. If AirGroup is deployed in an integrated environment, you should upgrade all the controllers in your network to ArubaOS 6.4. For more information, see
Integrated Deployment Model on page 1020 .
ArubaOS 6.4 supports a multi-controller AirGroup cluster. An AirGroup cluster consists of multiple controllers in various possible configuration combinations such as master-master, master-local, and local-local. If you are deploying AirGroup in a master-local topology with multiple local controllers that share the same user VLANs, use AirGroup in an integrated mode.
shows an example of a master-local topology with shared, local, and personal services that are available to mobile devices. With AirGroup, the context-based policies determine the services visible to the end-user devices.
Figure 225 Integrated AirGroup Network Topology
ArubaOS 6.5.3.x
| User Guide AirGroup | 1008
Table 248: Sample policies for AirGroup mDNS
Services
Faculty Student Visitor
Apple TV in the lab, registered to user role
“Faculty”
User X's iPad
Yes
User B's
MacBook
No
Windows Laptop
No
Yes No Apple TV in the dorm room, registered to User B
No
Apple TV in a lecture hall accessible to
Faculty
Yes
Printer located in a lab accessible to faculty and students
Yes
No
Yes
No
No
AirGroup with ClearPass Policy Manager
CPPM delivers identity and device-based network access control across any wired, wireless, and VPN infrastructure. AirGroup can be deployed with Aruba ClearPass Policy Manager (recommended for large
WLANs), or without ClearPass in smaller networks. If your deployment does not include ClearPass Policy
Manager, features described in
AirGroup Services on page 1005
are not available.
Features Supported in AirGroup
The following AirGroup features are supported in ArubaOS:
Multi-Controller AirGroup Cluster
ArubaOS supports multiple controllers running AirGroup to form a cluster. This feature enables iPad users on one controller to discover Apple TV available on another controller, if both controllers are part of the same cluster.
1009 | AirGroup ArubaOS 6.5.3.x | User Guide
Multi-Controller AirGroup Cluster—Terminologies
AirGroup Domain
An AirGroup domain is a set of controllers that are part of an AirGroup cluster. An administrator can configure multiple AirGroup domains for a site-wide deployment. Individual local controllers can independently select relevant multiple AirGroup domains to form a multi-controller AirGroup cluster.
AirGroup Cluster
One or several AirGroup domains can form an AirGroup cluster. AirGroup cluster can have 100 AirGroup domains. An AirGroup domain can include a list of likely controllers which may participate in the multicontroller AirGroup cluster.
shows the AirGroup cluster and domain relationship:
Figure 226 AirGroup cluster and domain relationship
Active-Domain
AirGroup allows one or more AirGroup domains to be a part of the AirGroup active-domain list on a controller.
A master or local controller may participate in one or more AirGroup clusters based on its active-domain list.
The controller must set the corresponding domain as active for the controller to be part of the AirGroup cluster.
In
, Controller 1, 2, and 3 belong to AirGroup Domain 1 .
Sample AirGroup Cluster Topology
shows a typical master-local multi-controller deployment. In this topology, four local controllers terminate on a single master controller.
ArubaOS 6.5.3.x
| User Guide AirGroup | 1010
Figure 227 Typical Master-Local Multi-Controller Deployment
Depends on the need, the administrator can configure the following topology:
Domain Definition
The administrator can define two domains with the following controllers in each domain: n n
Domain 1 : Local 1 (L1), Master (M), Local 3 (L3)
Domain 2 : Local 2 (L2), M, Local 4 (L4)
To configure an AirGroup domain, see
Configuring an AirGroup Domain on page 1026
.
Active-Domain Definition
Based on the domain definition, each controller belongs to the following active-domain lists: n n
Active-Domain 1 : L1, M, L3
Active-Domain 2 : L2, M, L4
To configure an active domain, see
Configuring an AirGroup active-domain on page 1027
.
AirGroup Controller Communication
Based on the domain and active-domain definitions, the AirGroup controller communication takes place in the following manner: n n n n
L1, M, and L3 can communicate with each other as they are part of active-domain 1.
L2, M, and L4 can communicate with each other as they are part of active-domain 2.
M can communicate with L1, L2, L3, and L4 as M is part of active-domain 1 and 2.
L1 and L3 cannot communicate with L3 and L4, because they do not have a common active-domain and they do not share the same VLAN.
AirGroup Server Discovery n iPad users in L1, M, and L3 can discover any Apple TV or AirPrint Printer in L1, M, and L3.
1011 | AirGroup ArubaOS 6.5.3.x | User Guide
n n n iPad users in L2, M, and L4 can discover any Apple TV or AirPrint Printer in L2, M, and L4.
iPad users in M can discover any Apple TV or AirPrint printer in L1, L2, L3, and L4 and vice-versa.
iPad users in L1 and L3 cannot discover any Apple TV or AirPrint printer in L2 and L4 and vice-versa.
Scalability
In a multi-controller deployment, there is a scaling limit of 2,000 AirGroup servers and 16,000 AirGroup users for all controllers in a cluster. If you require more servers and users than the prescribed limit, configure multiple clusters so that each cluster is within the prescribed limit. For detailed scalability information, see
Scalability Limits on page 1018
.
An AirGroup domain can include a list of controllers, which may participate in the multi-controller AirGroup cluster. Depending on the deployment setup, the IP address in the AirGroup domain could either be the controller IP or VRRP IP address. The configuration elements are defined by the administrator on a master controller and its associated local controllers that share the same configuration. The actual AirGroup multicontroller cluster may include one or several local controllers, and this cluster is defined by including one or several relevant AirGroup domains, on the respective local controller, in the active-domain list. As a result, a master or local controller may participate in one or more AirGroup clusters based on its active-domain list.
Incorrect or incomplete configuration of the controllers participating in an AirGroup cluster can lead to disjoint clusters. In a disjoint cluster, an AirGroup user will not have a seamless view of the AirGroup servers spanning multiple controllers. Therefore ensure that the participating controllers in an AirGroup cluster are configured appropriately.
The AirGroup domain configurations are restricted to the master controller. This ensures all local controllers in a master-local setup have unique AirGroup domain names. If duplicate AirGroup domain names on multiple master controllers are encountered, ensure that the duplicate AirGroup domain names have the same values to participate in a single AirGroup cluster.
Any controller that shares VLANs with another controller must be part of the same AirGroup multi-controller cluster.
When an AirGroup controller has the list of all the controllers in the multi-controller table, it uses an Aruba proprietary protocol called Process Application Programming Interface (PAPI) to communicate with other controllers in the table. The PAPI control channel carries AirGroup specific packets only. For configuration details, see
Configuring an AirGroup Domain on page 1026
.
Master-Local Controller Synchronization
Administrators can configure AirGroup from the master controller to ease deployment. The master controller then synchronizes the AirGroup configuration elements with all the local controllers it manages. For more information, see
Master-Local Controller Synchronization on page 1020 .
Pre-configured AirGroup Services
The following services are pre-configured and available as part of the factory default configuration: n n n n n n n
AirPlay
AirPrint iTunes
RemoteMgmt
Sharing
Chat
GoogleCast
ArubaOS 6.5.3.x
| User Guide AirGroup | 1012
n n n
DIAL
DLNA Print
DLNA Media
DIAL is enabled by default. DLNA Print and DLNA Media are disabled by default.
For more information, see
Integrated Deployment Model on page 1020 .
AirGroup IPv6 Support
A controller supports IPv6 enabled users (for example, iPad) and servers (Apple TV, AirPrint printers). All the
AirGroup features are available for both IPv4 and IPv6 clients. On any dual stack client, you must restart the client if the IPv4 interface is disabled.
Limitations
IPv6 support is limited to AirGroup users and servers only. The IPv4 addresses are supported only in the following scenarios: n n
When forming an AirGroup cluster, only IPv4 controller addresses are supported.
AirGroup supports IPv4 RADIUS clients only.
The controller can identify any IPv6 AirGroup servers, only when they proactively advertise their services.
To enable or disable AirGroup IPv6 support on the controller, see
Enabling or Disabling AirGroup Global Setting on page 1021 .
DLNA UPnP Support
AirGroup supports DLNA (Digital Living Network Alliance); a network standard that is derived from UPnP
(Universal Plug and Play) in addition to the mDNS protocol. For more information, see
AirGroup mDNS Static Records
AirGroup provides the ability for an administrator to create mDNS static records as group and individual records and add them to cache. For more information, see
AirGroup mDNS Static Records on page 1039 .
Group Based Device Sharing
AirGroup supports User Group and this is an add-on to the existing device sharing mechanisms such as username, user-role, and location based device sharing using CPPM. For more information, see
.
Dashboard Monitoring Enhancements
n n n
The AirGroup service names in the AirGroup row are clickable in the AirGroup section of the Dashboard >
Usage page of the WebUI. If you click the service name, you are redirected to the Dashboard > AirGroup page which displays a list of AirGroup servers filtered by Service Name.
In the Dashboard > Clients page, the AirGroup column is added to display the devices that are listed as mDNS, DLNA or both. If a device does not support both mDNS and DLNA, this field is blank.
The following enhancements are added in the Dashboard > AirGroup page of the WebUI:
1013 | AirGroup ArubaOS 6.5.3.x | User Guide
l l
A new AirGroup type column is added and this column specifies if the type of the AirGroup device is mDNS, DLNA or both.
The MAC address of each AirGroup user and server is now clickable. If you click MAC link, you are redirected to the Dashboard > Clients > Summary page > AirGroup tab. If an AirGroup user or
AirGroup server is a wired trusted client, the MAC address is not clickable.
ClearPass Policy Manager and ClearPass Guest Features
With CPPM portal for WLAN administrators, you can register shared device such as conference room Apple TV and printers. The ClearPass Guest portal for WLAN users allows end users to register their personal devices. For more information on AirGroup configuration on CPPM, see the ClearPass Policy Manager User Guide and
ClearPass Guest Deployment Guide .
Auto-association and Controller-based Policy
Auto-association allows AirGroup users to discover nearby AirGroup servers. Auto-association ensures that all the AirGroup users associated to an AP-group, AP-FQLN, or AP and its neighbors discover the AirGroup servers.
By default, auto-association is disabled on all AirGroup servers. An administrator can enable auto-association for each AirGroup server separately and configure AP-name, AP-group, or AP-FQLN for auto-association. Autoassociation can be enabled for a complete service, which allows all the AirGroup servers who advertise that service to be auto-associated with the configured parameter. If auto-association is enabled, other locationbased policy configuration for the AirGroup server on CPPM or CLI is not honored. Auto-association is applicable only for wireless AirGroup servers.
By default, all AirGroup servers are visible to every AirGroup user. AirGroup allows an administrator to configure controller-based policies for AirGroup servers to limit the visibility of AirGroup servers to destined
AirGroup users. To limit the AirGroup server’s visibility to intended AirGroup users, administrator can configure shared user-list, shared role-list, and shared group-list for each AirGroup server.
Administrator can also configure location-based policies for AirGroup devices. For example, administrator can configure if an AirGroup server is visible over a broader area than auto-association configuration. In locationbased configuration, administrator can configure AP names, AP groups, and AP FQLNs. Location-based policy configuration limits the AirGroup server’s visibility to AirGroup users who are associated to configured APs, its neighbors, AP-groups, or AP-FQLNs. Administrator can choose whether to consider the neighborhood of the configured AP names.
Controller-based policy configuration is available only on standalone controller and does not synchronize to local or other AirGroup controllers. If a policy for an AirGroup device is configured on CPPM and CLI, then CLI configuration takes precedence over CPPM configuration. Controller-based policy configuration is persistent when controllerrestarts.
Configuring Auto-association and Controller-based Policy
Configuring Mac Address-based Policy
(host)(config) #airgroup policy <mac>
(host)(config-airgroup-policy) #
Configuring Shared Group-list
(host) (config-airgroup-policy) #grouplist
Adding Role to Shared Group-list
(host) (config-airgroup-policy) #grouplist add <name-string>
ArubaOS 6.5.3.x
| User Guide AirGroup | 1014
Deleting Role from Shared Group-list
(host) (config-airgroup-policy) #grouplist remove <name-string>
Deleting Shared Group-list
(host) (config-airgroup-policy) #no grouplist
Configuring Shared Role-list
(host) (config-airgroup-policy) #rolelist
Adding Role to Shared Role-list
(host) (config-airgroup-policy) #rolelist add <name-string>
Deleting Role from Shared Role-list
(host) (config-airgroup-policy) #rolelist remove <name-string>
Deleting Shared Role-list
(host) (config-airgroup-policy) #no rolelist
Configuring Shared User-list
(host) (config-airgroup-policy) #userlist
Adding User to Shared User-list
(host) (config-airgroup-policy) #userlist add <name-string>
Deleting User from Shared User-list
(host) (config-airgroup-policy) #userlist remove <name-string>
Deleting Shared User-list
(host) (config-airgroup-policy) #no userlist
Configuring Shared Location
(host) (config-airgroup-policy) #location {ap-fqln|ap-group|ap-name}
Adding Shared Location
(host) (config-airgroup-policy) #location ap-fqln add <string>
(host) (config-airgroup-policy) #location ap-group add <string>
(host) (config-airgroup-policy) #location ap-name add <string>
Deleting Shared Location
(host) (config-airgroup-policy) #location ap-fqln remove <string>
(host) (config-airgroup-policy) #location ap-group remove <string>
(host) (config-airgroup-policy) #location ap-name remove <string>
Enabling Location Auto-association
(host) (config-airgroup-policy) #location ap-fqln autoassociate
(host) (config-airgroup-policy) #location ap-group autoassociate
(host) (config-airgroup-policy) #location ap-name autoassociate
This command returns an error message for wired devices.
Disabling Location Auto-association
(host) (config-airgroup-policy) #no location ap-fqln autoassociate
(host) (config-airgroup-policy) #no location ap-group autoassociate
(host) (config-airgroup-policy) #no location ap-name autoassociate
1015 | AirGroup ArubaOS 6.5.3.x | User Guide
This command returns an error message for wired devices. The error message indicates that auto location configuration for a wired device is unfeasible. The ap-fqln and ap-name use the same syntax as ap-group.
Configuring Service Level-based Auto-association
(host) (config) #airgroupservice airplay
(host) (config-airgroupservice) #autoassociate
(host) (config-airgroupservice) #autoassociate apfqln
(host) (config-airgroupservice) #autoassociate apgroup
(host) (config-airgroupservice) #autoassociate apname
Best Practices and Limitations
Apple iTunes Wi-Fi Synchronization and File Sharing
When the controller receives mDNS response for a service, the controller caches such records and does not propagate to other users. But for services like iTunes Wi-Fi synchronization and File Sharing to work seamlessly, such mDNS responses must be propagated to other users on the controller even if they do not query for it.
To ensure that applications such as iTunes Wi-Fi synchronization and File Sharing work seamlessly, ArubaOS selectively forwards these mDNS responses to AirGroup users, based on the user-name CPPM policy of the
AirGroup server. Hence, for a customer to use these services, it is necessary to configure user-name based
CPPM policies for the AirGroup devices.
Firewall Configuration
The following firewall configuration settings are recommended:
Disable Inter-User Firewall Settings
Some firewall settings can prevent the untrusted clients from communicating with each other. When these settings are enabled, an untrusted client such as an iPad may not be able to send its image to an Apple TV on the same controller.
Use the following commands to disable the virtual AP global firewall options and allow Bonjour services to use
AirGroup.
n n n no firewall deny-inter-user-bridging no firewall deny-inter-user-traffic no ipv6 firewall deny-inter-user-bridging
Valid User ACL Configuration
The ValidUser Access Control list (ACL) must allow mDNS packets with the source IP as a link local address. Do not use a ValidUser ACL if the user VLAN interfaces of the AirGroup controller are not configured with an IP address.
Allow GRE and UDP 5353 mDNS discovery uses the predefined port UDP 5353. If there is a firewall between the AirGroup controller and
WLAN controller, ensure that your firewall policies allow GRE and UDP 5353. DLNA uses the predefined port
UDP 1900.
ArubaOS 6.5.3.x
| User Guide AirGroup | 1016
Recommended Ports
The ArubaOS role-based access controls for wireless clients use ACLs to allow or deny user traffic on specific ports. Even though mDNS discovery uses the predefined port UDP 5353, application-specific traffic for services like AirPlay may use dynamically selected port numbers. As a best practice, add or modify ACLs to allow traffic on the ports as described in
and
AirPlay operates using dynamic ports, however, printing protocols like AirPrint use fixed ports.
Ports for AirPlay Service
Enable the following ports for the AirPlay services.
Table 249: Ports for AirPlay Service
Protocol Ports
TCP n n n n n
5000
7000
7100
8612
49152-65535
UDP n n n n
7010
7011
8612
49152-65535
TCP
TCP
TCP
TCP
Ports for AirPrint Service
Enable the following ports to allow AirGroup devices to access AirPrint services.
Table 250: Ports for AirPrint Service
Protocol Print Service
TCP Datastream
Port
9100
IPP
HTTP
Scanner
HTTP-ALT
631
80
9500
8080
AirGroup Services for Large Deployments
All Bonjour services are enabled in AirGroup by default. Large deployments with many wireless and wired users often support a large number of advertised Bonjour services, which can consume a significant amount of system resources. For large scale deployments, enable the AirPlay and AirPrint services, disable the allowall service, and then block all other Bonjour services. See
Integrated Deployment Model on page 1020
for a complete list of AirGroup configuration options.
1017 | AirGroup ArubaOS 6.5.3.x | User Guide
AirGroup Scalability Limits
displays the total number of AirGroup servers (Apple TV, AirPrint printer) and users (iPad) supported in individual controllers:
Table 251: AirGroup Server and User Limits in Controller
Controller Model
Number of
AirGroup
Servers
Number of
AirGroup Users
7240 10000 20000
7024
7010
7005
7008
7220
7210
7205
7030
600
500
300
200
7000
5000
2000
1000
1400
1500
700
800
15000
10000
6000
3000
In a multi-controller deployment, there is a scaling limit of 2,000 AirGroup servers and 16,000 AirGroup users for all controllers in a cluster. If you require more servers and users than the prescribed limit, configure multiple clusters, so that each cluster is within the prescribed limit.
The ArubaOS scaling limits are based on the following metrics: n n
Memory Utilization
The memory utilization is affected by the number of AirGroup servers and users in an AirGroup cluster. In an
AirGroup cluster, the total number of AirGroup servers and users cannot exceed the limit defined by the topend controller. Based on the memory utilization,
summarizes the maximum number of AirGroup servers and users for all supported controller platforms.
CPU Utilization
The CPU utilization is measured by the rate at which the controller receives mDNS packets. The rate of mDNS packets in the cluster depends on the number of AirGroup servers, users, and number of applications installed on these devices. The rate of mDNS packets handled by the supported controller platform varies.
displays the total number of mDNS packets received per second by supported the controller platforms:
ArubaOS 6.5.3.x
| User Guide AirGroup | 1018
Table 252: mDNS Packet Limits in Controller
Controller Model mDNS packets per second (pps)
7240 100
7220
7210
7205
7030
7024
7010
7005
7008
60
60
40
50
50
30
30
70
Use the following command to determine the number of mDNS packets received per second by the controller: show airgroup internal-state statistics
Issue this command multiple times to measure the time difference and the mDNS packet count.
General AirGroup Limitations
The AirGroup feature has the following limitations: n n n n n n n n
AirGroup is supported only in tunnel and decrypt-tunnel forwarding modes.
If you use CPPM to define AirGroup users, the shared user and role lists, and location attributes cannot exceed 1000 characters.
The RTSP protocol does not support AirPlay on an Apple TV receiver if you enable NAT on the user VLAN interface.
The location-based access feature only supports AP FQLNs (Fully Qualified Location Names) configured in the format <ap name>.floor <number>.<building>.<campus> . The AP names cannot contain periods.
AirGroup’s DLNA discovery works across VLANs, however, media streaming from Windows Media Server does not work across VLANs. This limitation is because of Digital Rights Management (DRM) support in
Windows Media Server, which restricts media sharing across VLANs. Media streaming works only when both client and server are connected to the same VLAN.
Android devices cannot discover media server while using the native music and video player applications and when they are connected across VLANs. For example, Samsung Tab 3 cannot discover the media server on Samsung Galaxy S4 while using the native music and video player applications. Android devices can discover media server when they are connected in the same VLAN. This restriction is forced by Samsung devices.
Xbox cannot be added as an extender to the Windows clients using the Windows Media Center application with the AirGroup feature enabled. You need to disable the AirGroup feature to add Xbox as an extender.
Wireless Clients such as iPad and iPhone running the Sonos Controller application cannot discover Sonos music system with the AirGroup is enabled.
1019 | AirGroup ArubaOS 6.5.3.x | User Guide
Integrated Deployment Model
In the integrated deployment model, AirGroup features are integrated with the WLAN controller that terminates all APs and provides WLAN services. This deployment model also supports optional integration with
CPPM. When you implement AirGroup in an integrated deployment, upgrade the controller to ArubaOS 6.4 or later, and trunk all VLANs with wired devices (such as printers) to the AirGroup controller.
If your deployment requires ClearPass Policy Manager integration, complete the procedures described in ClearPass
Policy Manager User Guide and ClearPass Guest Deployment Guide before performing the steps described in this section.
Master-Local Controller Synchronization
You can configure AirGroup from the master controller to ease the deployment. The master controller then synchronizes the AirGroup configuration elements on all associated local controllers it manages. AirGroup configurations can belong to any of the following categories:
Master — These commands must be configured from a master controller. The master controller pushes the
AirGroup configurations to all the applicable local controllers.
n n n n n n n
AirGroup custom service definition. For more information, see
Integrated Deployment Model on page
AirGroup disallow user-role (service filtering) definition. For more information, see
Configuring the disallowrole for an AirGroup Service on page 1024
.
AirGroup disallow VLAN (service filtering) definition. For more information, see
Restricting AirGroup Servers on a VLAN based on an AirGroup Service on page 1025 .
AirGroup CPPM enforce registration. For more information, see
Configuring CPPM to Enforce Registration on page 1036
.
AirGroup controller-CPPM Interface definition. For more information, see
.
AirGroup multi-controller domain definition. For more information, see
Configuring an AirGroup Domain on page 1026 .
AirGroup CPPM query interval definition. For more information, see
Configuring the CPPM Query Interval on page 1031
.
Local — There are a few configuration limitations on the local controller. The local controller can only include the existing AirGroup domains in the AirGroup active-domain list, applicable for this controller. The local controller cannot define or edit an AirGroup domain.
These configuration commands are applicable to both master and local controllers. The master controller does not push the following AirGroup configuration commands to all applicable local controllers.
n n n n n
AirGroup enable/disable parameter. For more information, see
Enabling or Disabling AirGroup Global
AirGroup service enable/disable parameter. For more information, see
Enabling or Disabling an AirGroup
AirGroup allowall service status. For more information, see
Enabling the allowall Service on page 1025
.
AirGroup disallow VLAN (global) definition. For more information, see
Restricting AirGroup Servers for a
AirGroup multi-controller active-domain definition. For more information, see
Configuring an AirGroup active-domain on page 1027
.
ArubaOS 6.5.3.x
| User Guide AirGroup | 1020
Configuring an AirGroup Integrated Deployment Model
Use the following procedures to enable the AirGroup feature and configure AirGroup services.
Enabling or Disabling AirGroup Global Setting
Starting with ArubaOS 6.4, AirGroup is disabled by default. To configure AirGroup global parameters, use the following procedure:
In the WebUI
To enable or disable the AirGroup global setting using the controller WebUI:
1. Navigate to Configuration > Advanced Services > AirGroup .
2. Select the AirGroup Settings tab.
3. Under Global Setting > AirGroup Status , select enable from the drop-down list to enable the AirGroup feature.
4. Under Global Settings > AirGroup MDNS Status , select enabled from the drop-down list to enable the
MDNS.
5. Under Global Settings > AirGroup DLNA Status , select enabled from the drop-down list to enable the
DLNA.
6. Under Global Setting > AirGroup CPPM enforce registration , select enable from the drop-down list to register an AirGroup server on a CPPM server.
For more information on AirGroup CPPM enforce registration, see
.
7. Under Global Setting > AirGroup IPV6 Support , select enable from the drop-down list.
The global AirGroup status must be enabled on the controller to enable AirGroup IPv6 support. For more information, see
AirGroup IPv6 Support on page 1013 .
8. Under Global Setting > AirGroup CPPM query interval , enter a value in the range of 1 to 24 hours.
The default value is 10. For more information on AirGroup CPPM query interval, see
.
9. Under Global Setting > AirGroup location discovery , select enable from the drop-down list.
If enabled, AirGroup user can discover shared devices based on the user’s proximity to the AirGroup server.
If disabled, location based filtering does not apply. Users can discover far servers. For more information on location attributes in CPPM, see
.
10.Under
Global Setting > AirGroup Active Wireless Discovery , select enable from the drop-down list.
If enabled, AirGroup controller actively sends refresh requests to discover wireless servers. If disabled, the controller sends refresh requests to wired AirGroup servers only.
11.Click
Apply .
AirGroup CPPM enforce registration , AirGroup CPPM query interval , AirGroup location discovery , and
AirGroup Active Wireless Discovery parameters are available on the master controller only. The master controller pushes these configurations to all the applicable local controllers.
shows the location attributes a device can register with CPPM and the corresponding behavior on the controller:
1021 | AirGroup ArubaOS 6.5.3.x | User Guide
Table 253: Location Attributes in CPPM
Location Attribute Tag=Value Format
AP-Name based ap-name=<name>
AP-Group based
AP-FQLN based ap-group=<group> fqln=<fqln>
Description
When the location is set to ap-name , all AirGroup users connected to this AP and other APs that are in the same RF neighborhood can access the shared device.
When the location attribute is set to ap-group , all
AirGroup users associated to the APs in the specified
AP group can access the shared device.
When the location attribute is set to ap-FQLN , all
AirGroup users connected to APs on the same floor, and to the APs on a floor above or below the configured APs can access the shared device.
In the CLI
Access the controller’s command-line interface and use the following command to enable or disable the
AirGroup Global Setting:
(host) (config) #airgroup {enable | disable}
(host) (config) #airgroup cppm-server enforce-registration
(host) (config) #airgroup ipv6
(host) (config) #airgroup query-interval <1..24>
(host) (config) #airgroup location-discovery {enable | disable}
(host) (config) #airgroup active-wireless-discovery {enable | disable}
Enabling or Disabling mDNS and DLNA
You can enable and disable mDNS and DLNA using CLI commands and WebUI.
In the CLI
Use the following command to enable or disable the mDNS or DLNA for an AirGroup service: airgroup [mdns|dlna] enable|disable
Both mDNS and DLNA are disabled by default.
Use the following command to view the status of mDNS and DLNA features:
#show airgroup status
Viewing AirGroup Global Setting on Controller
In the WebUI
To view the global setting of AirGroup in the controller WebUI:
1. Navigate to Configuration > Advanced Services > AirGroup .
2. Select the AirGroup Settings tab to view the AirGroup Global Setting in the controller.
In the CLI
Use the following command to view the global settings of the AirGroup configuration and AirGroup services configured in your WLAN controller.
(host) #show airgroup status
For more information, see ArubaOS 6.4 Command-Line Interface Reference Guide .
ArubaOS 6.5.3.x
| User Guide AirGroup | 1022
Defining an AirGroup Service
The AirGroup solution defines the concept of configurable AirGroup services. One or more mDNS and DLNA services can be configured on the controller. When you define an mDNS service as an AirGroup service, you can implement policies to restrict its availability to a specific user role or VLAN.
The following services are preconfigured and available as part of the factory default configuration: n n n n n n n n n n
AirPlay
AirPrint iTunes
RemoteMgmt
Sharing
Chat
GoogleCast
DIAL
DLNA Media
DLNA Print
In the WebUI
An administrator can configure and use up to 100 AirGroup services, and each AirGroup service can support up to 100 service elements. To define an AirGroup service using the controller WebUI:
1. Navigate to Configuration > Advanced Services > AirGroup .
2. On the AirGroup service details tab, click Add New .
3. Enter the name of the AirGroup profile in the Name field.
4. Enter the description for the AirGroup profile in the Description field.
5. Select Enable to enable this service.
6. Enter the VLANs that need to be restricted in the Disallow VLANs field.
7. Enter the roles that need to be restricted in the Disallow Roles field.
8. Enter the Service ID of the AirGroup service in the Services IDs field.
9. Click OK and then click Apply .
describes the configuration parameters of an AirGroup service:
Table 254: AirGroup Service Parameters
Parameter Description
Name
Description
Name of the AirGroup Service.
Enter the description for the AirGroup Service.
Enable Enables the AirGroup service.
1023 | AirGroup ArubaOS 6.5.3.x | User Guide
Parameter
Disallow VLANs
Disallow Roles
Service IDs
Description
User VLANs restricted from accessing the service.
User Roles restricted from accessing the service.
Specifies the mDNS or DLNA service IDs.
An AirGroup mDNS service ID is the name of a Bonjour service offered by a Bonjour-enabled device or application. Bonjour defines mDNS service ID strings using the following format
<underscore>servicename<period><underscore>protocol.local
Example: _airplay._tcp.local
The mDNS service ID string is case sensitive and must be entered as is without any modification, with the exception of the .local portion of the service ID which is optional.
When you add an existing mDNS service ID to a new service, Airgroup automatically deletes the mDNS service ID from the old service and displays a warning message. A sample warning message is as follows: service id <_ssh._tcp> removed from <remotemgmt> and added to <remotelogin>
The DLNA service IDs are colon separated and the service ID should have the following format to discover DLNA server or devices with the maximum label size of 128 characters: urn:domain-name:device:deviceType:ver urn:domain-name:service:serviceType:ver
For example, you can use the following service ID to support DLNA media server under AirGroup: urn:schemas-upnp-org:device:MediaServer:1
NOTE: Cache refresh mechanism is not required for DLNA, as the DLNA devices advertise their service periodically.
In the CLI
Use the airgroupservice command to define an AirGroup service using the command-line interface.
airgroupservice <name>
Sample Configuration
The following example configures the iPhoto service with access to the _dpap._tcp
service ID to share photos across MacBooks:
(host) (config) #airgroupservice iPhoto
(host) (config-airgroupservice) #description "Share Photos"
(host) (config-airgroupservice) #id _dpap._tcp
Configuring the disallow-role for an AirGroup Service
An AirGroup service is accessible to all user devices associated to your controller by default. The disallow-role parameter prevents devices with the specified user roles from accessing AirGroup services.
airgroupservice <string> disallow-role <string>
Sample Configuration
(host) (config) #airgroupservice iPhoto
(host) (config-airgroupservice) #disallow-role guest
Restricting AirGroup Servers for a VLAN
ArubaOS 6.5.3.x
| User Guide AirGroup | 1024
An AirGroup service is accessible to user devices in all VLANs configured on your controller by default. Use the following command to enable or disable AirGroup access to devices in a specific VLAN: airgroup vlan <VLAN ID> {allow | disallow}
Sample Configuration
(host) (config) #airgroup vlan 5 disallow
Restricting AirGroup Servers on a VLAN based on an AirGroup Service
To prevent user devices on a specific VLAN from accessing a specific AirGroup service, use the disallow-vlan option.
airgroupservice <string> disallow-vlan <string>
Sample Configuration
(host) (config) #airgroupservice airplay
(host) (config-airgroupservice) #disallow-vlan 5
Viewing AirGroup Disallowed VLAN Policy Details
Use the following command to view the status of a disallowed VLAN policy.
show airgroupservice [dlna|mdns] [verbose]
Viewing An AirGroup Disallowed VLAN
Use the following command to view the status of the disallowed AirGroup VLANs: show airgroup vlan
For more information, see ArubaOS 6.4 Command-Line Interface Reference Guide .
Enabling the allowall Service
The allowall service is a preconfigured AirGroup service that enables the controller to permit all AirGroup services by default, without requiring an administrator to configure an AirGroup service.
In the WebUI
Use the following steps to enable the allowall service using the controller WebUI:
1. Navigate to Configuration > Advanced Services > AirGroup .
2. In the AirGroup service details tab, select the checkbox next to the allowall service and click Enable .
To disable this service, select the allowall checkbox and click Disable .
3. Click Apply .
In the CLI
Use the following command to enable or disable the allowall service: airgroup service allowall {enable | disable}
Sample Configuration
(host) (config) #airgroup service allowall enable
Enabling or Disabling an AirGroup Service
In the WebUI
To enable or disable an AirGroup service using the controller WebUI:
1. Navigate to Configuration > Advanced Services > AirGroup .
2. On the AirGroup service details tab, select the AirGroup service and click Enable or Disable .
3. Click Apply .
1025 | AirGroup ArubaOS 6.5.3.x | User Guide
In the CLI
Use the following command to enable or disable an AirGroup service: airgroup service <string> {enable | disable}
Sample Configuration
(host) (config)#airgroup service airplay disable
Viewing AirGroup Service Status
In the WebUI
Use the following steps to view the status of AirGroup services using the controller WebUI:
1. Navigate to Configuration > Advanced Services > AirGroup .
2. Under the AirGroup service details tab, view the status of all the AirGroup services.
In the CLI
Use the following command to verify the status of an AirGroup Service: show airgroup status
Sample Configuration
For sample configuration, see
.
Viewing Blocked Services
The airgroup service <servicename> disable command blocks an AirGroup service by blocking the service
IDs for that service. When you enable an AirGroup service, service IDs of that service are enabled automatically. To view the list of blocked services, use the show airgroup blocked-service-id command.
In the CLI show airgroup blocked-service-id [mdns|dlna]
Viewing AirGroup Service Details
In the WebUI
To view the AirGroup service details using the controller WebUI:
1. Navigate to Configuration > Advanced Services > AirGroup service details .
2. Under AirGroup service details tab, click on any of the service name to view the service details.
In the CLI
Use the following command to view the service details of all AirGroup services: show airgroupservice
Sample Configuration
For sample configuration, see
Viewing AirGroup Disallowed VLAN Policy Details on page 1025 .
Configuring an AirGroup Domain
An administrator can configure multiple AirGroup domains for a site-wide deployment. Individual local controller can independently choose relevant multiple AirGroup domains to form a multi-controller AirGroup cluster.
An administrator can configure and use up to 100 AirGroup domains, and each AirGroup domain can support up to
100 IP addresses.
ArubaOS 6.5.3.x
| User Guide AirGroup | 1026
A domain can be configured only on a master controller only. However, active domains can be added/removed on any controllers.
The following procedure configures a cluster of controllers for a domain:
In the WebUI
1. Navigate to Configuration > Advanced Services > AirGroup .
2. Select the AirGroup Settings tab.
3. Under the AirGroup Domains section, click Add New .
4. In the Name field, enter the domain name.
5. In Description field, enter a short description of the domain name.
6. Select the Active checkbox to enlist the domain in the active-domain list of a controller.
7. Under the IP Address section, enter the controller or VRRP IP to be a part of this domain and click Add .
If the deployment includes master or local redundancies, use the VRRP IP address in the domain definition. Else, use the controller IP address.
8. Click Ok and Apply .
In the CLI
[no] airgroup domain <string>
[no] ip-address <A.B.C.D>
[no] description <string>
Sample Configuration
(host) (config) #airgroup domain Campus1
(host) (config-airgroup-domain) #ip-address 10.10.10.1
(host) (config-airgroup-domain) #ip-address 11.11.11.1
(host) (config-airgroup-domain) #description AirGroup_campus1
Viewing an AirGroup Domain
The following procedure displays a list of AirGroup domains configured:
In the WebUI
1. Navigate to Configuration > Advanced Services > AirGroup .
2. Select the AirGroup Settings tab. The list of AirGroup domains are displayed under the AirGroup
Domains section.
In the CLI show airgroup domain
Configuring an AirGroup active-domain
AirGroup allows one or more AirGroup domains to be a part of the AirGroup active-domain list of a controller.
A master or local controller may participate in one or more AirGroup cluster based on its active-domain list. The controller must set the corresponding domain as active for the controller to be part of the AirGroup cluster.
The following procedure configures an AirGroup active-domain for AirGroup cluster:
In the WebUI
For the WebUI procedure, see
Configuring an AirGroup Domain on page 1026
.
1027 | AirGroup ArubaOS 6.5.3.x | User Guide
In the CLI
[no] airgroup active-domain <string>
Sample Configuration
(host) (config) #airgroup active-domain campus1
(host) (config) #airgroup active-domain campus2
Viewing an AirGroup active-domains
The following procedure displays a list of AirGroup active-domains configured:
In the WebUI
1. Navigate to Configuration > Advanced Services > AirGroup .
2. Select the AirGroup Settings tab. The Active-Domain and Status column displays a list of AirGroup active-domains under the AirGroup Domains section.
In the CLI show airgroup active-domains
Viewing AirGroup VLAN Table
The following procedure displays the disallowed AirGroup VLANs.
In the WebUI
1. Navigate to Configuration > Advanced Services > AirGroup .
2. Select the AirGroup Settings tab. The list of disallowed AirGroup VLANs are displayed under the VLAN
Table section.
In the CLI
For the CLI command, see
Viewing An AirGroup Disallowed VLAN on page 1025
Viewing AirGroup Multi-Controller Table
All controllers communicate with each other based on the multi-controller table in an AirGroup cluster. This table is a combination of controllers specified in each domain, as part of active-domains.
The following command displays the IP address of all the controllers participating in an AirGroup multicontroller environment:
In the CLI show airgroup multi-controller-table
Controller Dashboard Monitoring
The Dashboard > Usage page of the WebUI has an additional AirGroup section, which displays all the
AirGroup services available and number of servers offering the service. It is aggregated by the total number of
AirGroup servers sorted by the services they advertise.
ArubaOS 6.5.3.x
| User Guide AirGroup | 1028
Figure 228 AirGroup Dashboard Usage
Table 255: AirGroup Dashboard Usage
Column Description
Service Displays the services advertised by AirGroup servers discovered by the controller.
Devices Displays the number of AirGroup servers advertising a particular service.
Click the IP link to view the client details in the Dashboard > Clients page of the WebUI. The client details page has a tab called AirGroup . The AirGroup tab in the details page displays a list of all the far and near end devices that are either accessible or not accessible by the specific client.
In a multi-controller topology, only AirGroup clients and servers that are connected to the same controller are listed under the near or far devices categories. AirGroup does not fetch this information from other controllers that are part of the same multi-controller domain.
n n n
A device is classified as a Near Device if it is registered with CPPM and the location is set to any one of the following: l
AP-Group same as the client l l l l
AP-FQLN same as the client
AP-FQLN corresponding to adjacent floors of the client
AP-Name same as the client
AP-Name which is an RF neighbor of the client
For more information on location, see
A device is classified as a Far Device if none of the above criteria is met. Devices that are neither registered nor have a location defined in CPPM are classified as Far Devices by default.
A device is classified as Accessible or Non Accessible based on the CPPM policies and
1029 | AirGroup ArubaOS 6.5.3.x | User Guide
Figure 229 Near and Far Accessible Devices
Table 256: Near and Far Accessible Devices
Column Description
MAC Address Displays the MAC address of the near or far AirGroup server that is accessible by an AirGroup client.
Name
Service
Displays the hostname of the near and far AirGroup server that is accessible by an AirGroup client.
Displays the AirGroup service advertised by an AirGroup server.
ArubaOS 6.5.3.x
| User Guide AirGroup | 1030
Figure 230 Near and Far Non Accessible Devices
Table 257: Near and Far Non Accessible Devices
Column Description
MAC Address Displays the MAC address of the near or far AirGroup server that is not accessible by an AirGroup client.
Name
Service
Why Not Accessible
Displays the hostname of the near and far AirGroup server that is not accessible by an AirGroup client.
Displays the AirGroup service advertised by an AirGroup server.
Displays the reason for not accessing the AirGroup server.
n n n n n n
Configuring the AirGroup-CPPM Interface
Configure the AirGroup and ClearPass Policy Manager (CPPM) interface to allow an AirGroup controller and
CPPM to exchange information about the owner, visibility, and status for each mobile device on the network.
The following procedures configure the AirGroup-CPPM interface:
Configuring the CPPM Query Interval on page 1031
Defining a CPPM and RFC3576 Server on page 1032
Assigning CPPM and RFC 3576 Servers to AirGroup on page 1035
Viewing the CPPM Server Configuration on page 1036
Configuring CPPM to Enforce Registration on page 1036
Group-Based Device Sharing on page 1037
Configuring the CPPM Query Interval
The AirGroup CPPM query interval refreshes the CPPM entries at periodic intervals. The minimum value is 1 hour and the maximum value is 24 hours. The default value is 10 hours.
1031 | AirGroup ArubaOS 6.5.3.x | User Guide
In the WebUI
1. Navigate to the Configuration > Advanced Services > AirGroup page.
2. Select the AirGroup Settings tab.
3. Under Global Setting > AirGroup CPPM query interval , enter a value in the range of 1 to 24 hours.
4. Click Apply .
In the CLI
[no] airgroup cppm-server query-interval <1..24>
Sample Configuration
(host) (config) #airgroup cppm-server query-interval 9
Viewing the CPPM Query Interval
The following procedure displays the configured CPPM query interval value.
In the WebUI
1. Navigate to the Configuration > Advanced Services > AirGroup page.
2. Select the AirGroup Settings tab. The AirGroup CPPM query interval displays the value in hours under the Global Setting section.
In the CLI show airgroup cppm-server query-interval
Sample Configuration
(host) #show airgroup cppm-server query-interval
CPPM Server Query Interval
--------------------------
Timer Value Unit
--------------
9 hours
The output of this command includes the following information:
Table 258: show airgroup cppm-server query-interval
Column Description
Timer Value Displays the number of hours.
Unit Displays the unit in hours.
Defining a CPPM and RFC3576 Server
You must define one or more CPPM servers to be used by the AirGroup RADIUS client, and an RFC 3576
(dynamic authorization) server. If multiple CPPM servers are defined, the servers are listed in a sequential order. The AirGroup RADIUS client will use the first available server on this list.
describes the configuration parameters for a CPPM server.
ArubaOS 6.5.3.x
| User Guide AirGroup | 1032
Table 259: CPPM Server Configuration Parameters
Parameter Description
Host
Key
IP address or fully qualified domain name (FQDN) of the authentication server. The maximum supported FQDN length is 63 characters.
Shared secret between the controller and the authentication server. The maximum length is 128 characters.
Authentication Ports
Accounting Ports
Retransmits
Timeout
NAS ID
Authentication port on the server.
Default: 1812
Accounting port on the server.
Default: 1813
Maximum number of retries sent to the server by the controller before the server is marked as down.
Default: 3
Maximum time, in seconds, that the controller waits before timing out the request and resending it.
Default: 5 seconds
Network Access Server (NAS) identifier to use in RADIUS packets.
NAS IP
Source Interface
Use MD5
NAS IP address to send in RADIUS packets.
You can configure a “global” NAS IP address that the controller can use for communications with all CPPM servers. However, that the controller will only use this global NAS IP if you do not configure a server-specific NAS IP.
To set the global NAS IP in the WebUI, navigate to the Configuration >
Security > Authentication > Advanced page.
To set the global NAS IP in the CLI, use the ip radius nas-ip <A.B.C.D> command.
Enter a VLAN number ID.
This value allows you to use source IP addresses to differentiate RADIUS requests, and associates a VLAN interface with the RADIUS server to allow the server-specific source interface to override the global configuration.
n n
If you associate a Source Interface (by entering a VLAN number) with a configured server, the source IP address of the packet will be the same as the IP address of the interface.
If you do not associate the Source Interface with a configured server
(leave the field blank), the IP address of the global Source Interface will be used.
Use a MD5 hash of the cleartext password.
Use IP address for calling station ID
Select this checkbox to use an IP address instead of a MAC address for the calling station ID.
Mode Enables or disables the server.
Configuring a CPPM Server
You can configure a CPPM server for AirGroup using the WebUI or CLI.
Server-derived user roles or VLANs configured in this server group are not applicable to AirGroup.
1033 | AirGroup ArubaOS 6.5.3.x | User Guide
In the WebUI
To configure a CPPM server using the controller WebUI:
1. Navigate to Configuration > Security > Authentication > Servers .
2. Select Radius Server to display the CPPM Server List.
3. To configure a CPPM server, enter the name for the server and click Add .
4. Select the name to configure server parameters. Select the Mode checkbox to activate the authentication server.
5. Click Apply .
In the CLI
Use the following commands to configure a CPPM server using the CLI: aaa authentication-server radius <name> host <ipaddr> key <key> enable
Sample Configuration
(host)(config) #aaa authentication-server radius emp_accounts
(host)(RADIUS Server "emp_accounts") #host 10.100.8.32
(host)(RADIUS Server "emp_accounts") #key employee123
(host)(RADIUS Server "emp_accounts") #enable
Configuring the CPPM Server Group
In the WebUI
To configure a CPPM server group using the controller WebUI:
1. Navigate to Configuration > Security > Authentication > Servers .
2. Select Server Group to display the Server Group list.
3. Enter the name of the new server group and click Add .
4. Select the name to configure the server group.
5. Under Servers , click New to add a server to the group.
a. Select a server from the drop-down list and click Add Server .
b. Repeat the above step to add other servers to the group.
6. Click Apply .
In the CLI
Use the following commands to configure a CPPM server group using the CLI: aaa server-group <name> auth-server <name>
Sample Configuration
(host) (config) #aaa server-group employee
(host) (Server Group "employee") #auth-server emp_accounts
Configuring an RFC 3576 Server
In the WebUI
To configure an RFC 3576 server by using the controller WebUI:
1. Navigate to Configuration > Security > Authentication > Servers .
2. Select RFC 3576 Server .
ArubaOS 6.5.3.x
| User Guide AirGroup | 1034
3. Enter the IP address and click Add .
4. Select the IP address to enter the shared secret key in the Key text box.
5. Retype the shared secret key in the Retype text box.
In the CLI
Use the following commands to configure an RFC 3576 server using the CLI: aaa rfc-3576-server <server_ip> key <string>
Sample Configuration
(host) (config) #aaa rfc-3576-server 10.100.8.32
(host) (RFC 3576 Server "10.100.8.32") #key employee123
Assigning CPPM and RFC 3576 Servers to AirGroup
Use the following procedures to assign CPPM and RFC 3576 servers to AirGroup.
An AirGroup RFC 3576 server cannot use the same port as an authentication module RFC 3576 server. To avoid conflicts, use a non-standard port for the AirGroup RFC 3576 server.
In the WebUI
Use the following procedure to configure the AirGroup AAA profile by using the controller WebUI:
1. Navigate to Configuration > Advanced Services > All Profiles .
2. Expand the Other Profiles menu and select AirGroup AAA Profile .
3. In the Configure dead time for a down Server text box in the Profile Details window, enter a maximum period in minutes, so that a client that does not send user traffic for the given period is considered idle.
4. Enter the UDP port number in the Configure UDP port to receive RFC 3576 server requests field. If your network uses an RFC 3576 server for authentication, select a different port for the AirGroup 3576 server. The default in ClearPass Guest is 5999.
In this release of ArubaOS, the user-defined UDP port number for RFC3576 server is automatically permitted by the firewall. The administrator does not have to explicitly define a firewall policy to permit this port.
5. Identify the AirGroup CPPM server group. In the Profiles list, select the Server Group under the AirGroup
AAA Profile menu.
6. In the Profile Details window, click the Server Group drop-down list to select the desired CPPM server group.
7. Click Apply .
8. Identify the RFC 3576 server. In the Profiles list, select RFC 3576 Server under the AirGroup AAA Profile menu.
9. Enter the IP address of the RFC 3576 server in the Add a profile text box.
10.Click
Add and Apply .
In the CLI
Execute the following commands to configure the AirGroup AAA profile using the CLI: airgroup cppm-server aaa rfc-3576-server <ip address> rfc-3576_udp_port <port number> server-dead-time <time>
1035 | AirGroup ArubaOS 6.5.3.x | User Guide
server-group <server group name>
If your network uses an RFC 3576 server for authentication, select a different port for the AirGroup 3576 server. The default port in ClearPass Guest is 5999.
Sample Configuration
(host) (config) # airgroup cppm-server aaa
(host) (Airgroup AAA profile) #rfc-3576-server 10.15.16.25
(host) (Airgroup AAA profile) #rfc3576_udp_port 21334
(host) (Airgroup AAA profile) #server-dead-time 10
(host) (Airgroup AAA profile) #server-group employee
Viewing the CPPM Server Configuration
In the WebUI
To view the CPPM server configuration by using the controller WebUI:
1. Navigate to Configuration > Advanced Services > AirGroup .
2. Under the AirGroup Settings tab, the AirGroup CPPM server aaa section displays the CPPM Server configuration.;
In the CLI
Use the following CLI command to view data for the ClearPass Policy Manager servers:
(host) #show airgroup cppm-server aaa
Config-cppm-server-aaa
----------------------
Parameter
---------
Server Group
RFC 3576 server
Value
-----
RADIUS_4
Test1
Configure dead time for a down Server 10
Configure UDP port to receive RFC 3576 server requests N/A
The output of this command includes the following information:
Table 260: show airgroup cppm-server aaa
Column Description
Parameter Displays the AAA parameters for AirGroup.
Value Displays the value entered for each AAA parameter.
Verifying CPPM Device Registration
Use the following command to display information for devices registered in ClearPass Policy Manager.
(host) #show airgroup cppm entries
For more information, see ArubaOS 6.4 Command-Line Interface Reference Guide .
Configuring CPPM to Enforce Registration
The AirGroup solution allows the users to view all mDNS devices by default. AirGroup provides a set of policy definitions to allow or disallow one of more AirGroup servers from being visible to specific AirGroup users.
ArubaOS 6.5.3.x
| User Guide AirGroup | 1036
If an AirGroup server is not registered on a CPPM server, by default, the server will be visible to all AirGroup users. The administrator must register an AirGroup server to allow or disallow this server from being visible to specific AirGroup users.
The following procedure registers an AirGroup server on a CPPM server:
In the WebUI
To configure using the controller WebUI:
1. Navigate to Configuration > Advanced Services > AirGroup .
2. Select the AirGroup Settings tab.
3. Under Global Setting > AirGroup CPPM enforce registration , select Enabled from the drop-down list.
4. Click Apply .
In the CLI
Use the following command to force AirGroup servers to register with CPPM. This option is disabled by default:
(host) (config) #airgroup cppm-server enforce-registration
To verify the CPPM Registration Enforcement status, use the following command:
(host) #show airgroup status
For more information, see ArubaOS 6.4 Command-Line Interface Reference Guide .
Group-Based Device Sharing
ArubaOS 6.5.3.x AirGroup supports sharing AirGroup devices such as AppleTV, Printer, and so on to a User
Group using CPPM. This is an add-on to the existing device sharing mechanisms such as username, user-role, and location based device sharing. A User Group is a logical association of users.
A user can be a part of groups that are defined in Active Directory. User group attribute for each user in a controller is learnt, when a user is associated to wireless network. In ArubaOS, this is initially learnt in auth module (authentication process). Auth module sends RADIUS request to RADIUS server as a part of 802.1X
authentication and the RADIUS server fetches the user group attribute in the form of vendor specific attribute
(VSA) from the Active Directory. Subsequently, AirGroup obtains this information from Auth module. This is similar to user’s role, however, a user can be a part of more than one groups.
When AirGroup learns about a new device, it interacts with ClearPass Guest to obtain the shared attributes.
The shared group(s) attribute is also obtained along with the following attributes: n n n n
Device owner
Shared location(s)
Shared user(s)
Shared role(s)
The group based device sharing feature is supported in CPPM 6.3 and higher versions.
A user can be a part of maximum 32 user groups. This needs to be defined as comma separated string in Active directory. Each group name can contain a maximum of 63 characters and the entire group name strings cannot exceed 320 characters.
The AirGroup policy engine is enhanced to compare the user’s group membership (obtained using auth module) and shared groups to determine if a user can discover the specific AirGroup server or not.
1037 | AirGroup ArubaOS 6.5.3.x | User Guide
Sample Configuration
The following example displays the status of the AirGroup server (Apple TV, AirPrint Printer, Google
ChromeCast, and so on) in a controller:
(host) #show airgroup servers
AirGroup Servers
----------------
MAC
---
IP
--
Type
----
5c:3c:27:14:6e:01 10.15.121.240
mDNS
Host Name
---------
Service
------airplay
VLAN Wired/Wireless
-----------------
2 wireless
Role
----
Group
-----
Username
-------authenticated Mathematics Mike
AP-Name
-------
104_AP105
Num Servers: 1, Max Servers: 2000.
The following example displays the shared group information for devices registered in ClearPass Guest:
(host) #show airgroup cppm entries
ClearPass Guest Device Registration Information
-----------------------------------------------
Device
-----device-owner
------------
00:1e:65:2d:ae:44 N/A shared location-id AP-name
-------------------------shared location-id AP-FQLN
-------------------------shared location-id AP-group shared user-list shared group-list shared role-list
-------------------------------------------------------------------------
Physics
CPPM-Req CPPM-Resp
----------------
1 1
Num CPPM Entries:1
The following example describes the user Alice is the member of Mathematics group and hence cannot discover the 00:1e:65:2d:ae:44 appleTv (specified in the example above) as it is not shared with the
Mathematics group. Similarly, the user Bob can view the appleTv as it is shared with the Physics group.
(host) #show airgroup users
AirGroup Users
--------------
MAC
AP-Name
---
-------
IP
--
Type
----
Host Name
---------
VLAN
----
74:e1:b6:15:25:7e 10.15.121.240
mDNS iPad-358 2
104_AP105 b0:65:bd:09:b6:79
104_AP105
10.15.121.240
mDNS 2
Role
---authenticated authenticated
Group
-----
Mathematics
Physics
Username
--------
Alice
Bob
Num Users: 2, Max Users: 6000.
Bluetooth-Based Discovery and AirGroup
Apple devices support Bluetooth-based device discovery mechanism, which allows an Apple device to discover an Apple TV that is within the Bluetooth range.
ArubaOS 6.5.3.x
| User Guide AirGroup | 1038
AirGroup supports only mDNS-based device discovery and does not support Bluetooth-based device discovery mechanism.
n n
AirGroup mDNS Static Records
AirGroup processes mDNS packets advertised by servers and creates the relevant cache entries. When a query comes from a user, AirGroup responds with the appropriate cache entries with the relevant policies applied.
Starting with ArubaOS 6.4, AirGroup provides the ability for an administrator to add the mDNS static records to cache, when a server is: not mDNS compliant.
connected to a VLAN that is not trunked to the AirGroup supported controller.
The administrator can add these records manually to the cache using CLI commands for the servers that adhere to the above conditions.
Important Points to Remember
Remember the following points when you create mDNS static records and add them to the cache: n n n n
The mDNS static records do not expire as there is no cache refresh for static records. These static records can be deleted by an administrator.
The Administrator needs to ensure that the relevant records are updated manually, when the IP address of a server is changed.
The Disallow role policy configured on the CLI is accepted for static records. The Disable service policy is accepted while responding to a query. Administrator has the privilege to configure static records of a disabled service.
Disallow vlan is not applicable for static records.
ClearPass Policy Manager policies work with static servers.
Creating mDNS Static Records on a Controller
The Administrator can create the static records using the following methods: n n
Group mDNS static records
Individual mDNS static records
Group mDNS Static Records
You can create a group of mDNS records for a device. This section describes how to create static records of a server as a group using the CLI.
Creating a PTR Record
Use the following command to create a PTR record:
(config) # airgroup static mdns-record ptr <mac_addr> <mdns_id> <domain_name> [server_ipaddr]
(config-airgroup-record) #
After creating a PTR record, controller displays the (config-airgroup-record) # prompt and you can create SRV, A,
AAAA, and TXT records under this prompt.
After creating a PTR, SRV, TXT, A, and AAAA static record, you can use the show airgroup cache entries command to view and verify the records created. You can view only the static records in the output of the show airgroup cache entries static command.
1039 | AirGroup ArubaOS 6.5.3.x | User Guide
Creating an SRV Record
Use the following command to create an SRV record:
(config-airgroup-record) # srv <port> <priority> <weight> <host_name>
Creating an A Record
Use the following command to create an A record:
(config-airgroup-record) #a <ipv4addr>
You can create/delete an A record if a corresponding SRV record is available.
Creating an AAAA Record
Use the following command to create an AAAA record:
(config-airgroup-record) #aaaa <ipv6addr>
You can create/delete an AAAA record if a corresponding SRV record is available.
Creating a TEXT Record
Use the following command to create a TEXT record:
(config-airgroup-record) #txt <text>
Individual Static mDNS Records
You can create individual static records independently for each record type.
Creating an Individual SRV Record
Use the following command to configure an individual SRV record: airgroup static mdns-record srv <mac_addr> <domain_name> <port> <priority> <weight> <host_ name> [ server_ipaddr]
Creating an Individual TEXT Record
Use the following command to configure an individual TEXT record: airgroup static mdns-record txt <mac_addr> <domain_name> <text> [server_ipaddr]
Creating an Individual A Record
Use the following command to configure an individual A record: airgroup static mdns-record a <mac_addr> <host_name> <ipv4addr> [server_ipaddr]
Creating an Individual AAAA Record
Use the following command to configure an individual AAAA record: airgroup static mdns-record aaaa <mac_addr> < host_name> <ipv6addr> [server_ipaddr]
You can delete the mDNS records by appending no at the beginning of the command. Ensure that the [server_ ipaddr] parameter is not added while deleting mDNS records.
For more information, see ArubaOS 6.4 Command-Line Interface Reference Guide .
ArubaOS 6.5.3.x
| User Guide AirGroup | 1040
n n n n n n n
mDNS AP VLAN Aggregation
In the AirGroup solution, all mDNS/SSDP packets are terminated in a controller. The AirGroup solution works as a unicast querier and responder on behalf of mDNS/SSDP devices and eliminates the propagation of multicast mDNS/SSDP traffic in the WLAN.
When a wired mDNS/SSDP device is part of a VLAN which is not trunked in a controller, L2 connectivity does not exist between the wired mDNS/SSDP device and the controller. In such a scenario, the mDNS/SSDP packets from the wired mDNS/SSDP device does not reach the controller or from the controller to the wired mDNS/SSDP device. Hence, AirGroup does not discover these wired mDNS/SSDP devices.
The mDNS AP VLAN aggregation allows the discovery of wired mDNS/SSDP devices which do not have L2 connectivity with the controller or which do not trunk in the controller. An AP, which is in the same VLAN as the wired mDNS/SSDP device which does not trunk in the controller, receives and forwards the mDNS/SSDP packets from the wired mDNS/SSDP devices to the controller and from the controller to the wired mDNS/SSDP device. The AP forms a separate split tunnel (0x8000) with the controller and aggregates all mDNS/SSDP traffic to and from the controller.
The split tunnel is formed only when both AP Multicast Aggregation (under AP System Profile ) and
AirGroup parameters are enabled. If either AP Multicast Aggregation or AirGroup parameter is disabled, the split tunnel is not formed.
The AP Multicast Aggregation parameter is disabled by default.
When AP Multicast Aggregation parameter is enabled from disabled state, an mDNS/SSDP device discovery packet is sent to the VLAN in which the split tunnel is created if the AirGroup parameter is also enabled.
If an AP is provisioned with an uplink VLAN, then the split tunnel between the AP and the controller is formed with the uplink VLAN, otherwise the native VLAN is used.
When the native VLAN is changed, the tunnel is recreated.
Irrespective of which VLAN (uplink VLAN or native VLAN) is used, the split tunnel is in the same VLAN as the wired mDNS/SSDP devices.
Configure the VLAN in which the wired mDNS/SSDP device terminates in the controller. Do not create an
SVI or attach a port to the VLAN.
Configuring mDNS AP VLAN Aggregation
Use the following procedures to configure mDNS AP VLAN aggregation:
In the WebUI
Following different network topologies are possible to configure AP multicast aggregation for allowed VLANs:
1. If AP uplink is an access port with access VLAN x, the AP performs mDNS aggregation for VLAN x. Perform following configuration: l
Create VLAN on controller using command vlan x.
l l
Configure native VLAN ID in system profile as vlan x.
Enable parameter AP Multicast Aggregation in ap-system profile.
2. If AP uplink is a trunk port with native VLAN as x (that is, uplink-VLAN is not configured for AP), the AP performs mDNS aggregation for VLAN x. Perform following configuration: l l l
Create VLAN on controller using command vlan x.
Configure native VLAN ID in system profile as vlan x.
Enable parameter AP Multicast Aggregation in ap-system profile.
1041 | AirGroup ArubaOS 6.5.3.x | User Guide
3. If AP uplink is a trunk port with native VLAN as x, allowed VLANs as x, y, and z, and if the uplink-VLAN is configured as VLAN y for AP, the AP performs mDNS aggregation for VLAN y. Perform following configuration: l
Configure uplink-VLAN as VLAN y in the provisioning parameters of the AP and reboot the AP.
l l l
Create VLAN on controller using command vlan y.
Configure native VLAN in system profile as VLAN x.
Enable parameter AP Multicast Aggregation in ap-system profile.
In the CLI
1. Create VLAN for AP on the controller by using the following command:
(host) (config) #vlan <vlan id>
If an AP is connected on the trunk port, then configure the native VLAN of the trunk port using this command. If uplink-VLAN is configured for the AP, then use this VLAN.
2. Configure the native VLAN ID for AP by using the following command:
(host) (config) #ap system-profile <profile-name>
(host) (ap system-profile "<profile-name>") #native-vlan-id <vlan-id>
If an AP is connected on the trunk port, then configure the native VLAN of the trunk port using this command.
3. Enable mDNS aggregation feature.
(host) (config) #ap system-profile <profile-name>
(host) (ap system-profile "<profile-name>") #mcast-aggr
4. Map the AP system-profile to AP name.
(host) (config) #ap-name <ap-name>
(host) (ap-name "<ap-name>") #ap-system-profile <profile-name>
In the WebUI
To enable AirGroup using the controller WebUI:
1. Navigate to Configuration > Advanced Services > AirGroup .
2. Select Settings tab.
3. Under Global Setting > AirGroup Status , select Enabled from the drop-down list.
4. Click Apply .
To enable mDNS AP VLAN aggregation using the controller WebUI:
1. Navigate to Configuration > Advanced Services > All Profiles .
2. Under Profiles , select AP > AP System > <Profile-Name> .
3. Under Basic > General , select the checkbox next to AP multicast aggregation .
4. Click Apply .
In the CLI
To enable AirGroup using the controller CLI:
(host) (config) #airgroup enable
To enable mDNS AP VLAN aggregation using the controller CLI:
(host) (config) #ap system-profile <profile-name> mcast-aggr
ArubaOS 6.5.3.x
| User Guide AirGroup | 1042
Disable AirGroup using WebUI
To disable AirGroup using the controller WebUI:
1. Navigate to Configuration > Advanced Services > AirGroup .
2. Select Settings tab.
3. Under Global Setting > AirGroup Status , select Disabled from the drop-down list.
4. Click Apply .
Disable mDNS AP VLAN aggregation using WebUI
To disable mDNS AP VLAN aggregation using the controller WebUI:
1. Navigate to Configuration > Advanced Services > All Profiles .
2. Under Profiles , select AP > AP System > <Profile-Name> .
3. Under Basic > General , deselect the checkbox next to AP multicast aggregation .
4. Click Apply .
Disable AirGroup using CLI
To disable AirGroup using the controller CLI:
(host) (config) #airgroup disable
Disable mDNS AP VLAN Aggregation using CLI
To disable mDNS AP VLAN aggregation using the controller CLI:
(host) (config) #ap system-profile <profile-name> no mcast-aggr
mDNS Multicast Response Propagation
In the AirGroup solution, all mDNS packets are terminated on the controller. The AirGroup solution works as a unicast querier and responder on behalf of mDNS capable devices and eliminates the propagation of multicast mDNS traffic in the WLAN.
For some services, terminating the mDNS packets at the controller does not allow the initial advertisement to reach other devices. For example, the iChat or Messages Application uses mDNS response packet to announce the arrival of a new user. The new user entry does not reach the existing users if the announcement or response packet is not multicast. The exiting users get to know about the new user only after they send a periodic query.
mDNS multicast response propagation allows services to multicast the response packet. This allows the existing users to instantly see a new user when a new user logs in.
The mDNS response packet for iChat or Messages Application is multicast across all VLANs that are trunked in the controller except: n n
If the VLAN is globally disallowed.
If the iChat service is disallowed for a VLAN.
In both scenarios, the mDNS response message is not propagated and: n n n n mDNS queries for iChat records from a disallowed VLAN are dropped.
mDNS responses are not propagated to a disallowed VLAN.
When an allowed VLAN is disallowed, users disappear from the buddy list of other users when they query for the service next time. This may take a maximum of one hour.
When a disallowed VLAN is allowed, wildcard queries are sent to all users for discovery.
1043 | AirGroup ArubaOS 6.5.3.x | User Guide
The AirGroup cache is updated with iChat records thus ensuring that the cache of the existing users is also updated. CPPM/CLI policies are not applied to iChat records because the mDNS response is multicast. The mDNS response messages are multicast whenever the status of a user changes and similar messages are also multicast.
The response for mDNS iChat queries is L2 unicast back to the sender from the AirGroup cache while the mDNS response packets are L3 multicast.
When the iChat service is disabled from enabled state, new messages are neither propagated nor responded until they query for the service again. After an hour, the existing users disappear because query and responses are not honored. When the iChat service is enabled, discovery packets are sent to determine all iChat users.
The performance of an iChat server is not the same as the performance of an AirGroup server. The number of iChat servers supported is less than the number of AirGroup servers supported.
Maximum Number of iChat Users
The maximum number of iChat users is limited to 2000. Each iChat user is an mDNS server and their announcement messages are L2 multicast. The following table lists the number of mDNS servers supported in different controller models:
Table 261: Controller model and number of supported mDNS servers
Controller Model Number of mDNS Servers
7240 10000
7220
7210
7205
7030
7024
7010
7005
600
500
300
7000
5000
2000
1000
In a multi-controller deployment with AirGroup solution: n n n
The local controller sends the response from an mDNS device for iChat service to other controllers in the cluster. This is in addition to local controller performing L2 multicast of the message to all VLANs.
The corresponding controller multicasts the message to all the VLANs that are trunked in it.
When a user moves from one controller to another controller, two user entries exist in the user cache for the same user until the user entry is deleted from the first controller. The two user entries exist because the
IP address, which is part of the mDNS payload, changes when a user moves from one controller to another controller. If IP mobility is enabled, only one user entry exists because the user retains the IP address across the controllers.
Configuring mDNS Multicast Response Propagation
Use the following procedures to enable or disable mDNS multicast response propagation:
ArubaOS 6.5.3.x
| User Guide AirGroup | 1044
In the WebUI
To enable iChat using the controller WebUI:
1. Navigate to Configuration > Advanced Services > AirGroup .
2. Under Services , select the checkbox next to chat .
3. Click Enable .
4. Click Apply .
In the CLI
To enable iChat using the controller WebUI:
(host) (config) #airgroup service chat enable
Troubleshooting and Log Messages
Controller Troubleshooting Steps
Use the following procedure to prevent potential errors in a controller:
1. Execute the show airgroup internal-state statistics CLI command and ensure that the Sibyte
Messages Sent/Recv counters increment over a period of time.
2. Enable mDNS logs using the logging level debugging system process mdns command, and capture the output of show log system all when the issue occurs. Review any obvious error print statements.
3. Save the output of show airgroup cache entries and show airgroup cppm entries and look for any discrepancies.
ClearPass Guest Troubleshooting Steps
ClearPass Guest includes AirGroup-related events in the application log files. You can configure logging levels to provide debugging information.
To show debugging information in event logs:
1. In ClearPass Guest, go to Administration > AirGroup Services and click the Configure AirGroup
Services command link. The Configure AirGroup Services form opens.
2. In the AirGroup Logging drop-down list, select either Debug—log debug information or Trace—log all debug information . When one of these options is selected, debugging information is provided in the events log.
3. Click Save Configuration .
For up-to-date information, see the ClearPass Guest Deployment Guide .
ClearPass Policy Manager Troubleshooting Steps
Monitoring and reporting services in ClearPass Policy Manager provide insight into system events and performance.
To show incoming AirGroup requests from the controller:
1. In ClearPass Policy Manager, navigate to Monitoring > Live Monitoring > Access Tracker . The Access
Tracker list view opens.
2. Click an event’s row to view details. The Summary tab of the Request Details view opens. Additional details may be viewed on the Input , Output , or Alerts tabs, or you can click Show Logs to view logging details.
For up-to-date information, see the ClearPass Policy Manager User Guide .
1045 | AirGroup ArubaOS 6.5.3.x | User Guide
Log Messages
Display AirGroup logs by issuing the following commands in the controller CLI: n n n n show log all show log system all show log user all show log user-debug all
The log debug messages for the mDNS process are not enabled by default. To enable specific logging levels, use the following CLI commands in configuration mode:
To enable high level mDNS debug messages:
(host)(config) #logging level debugging system process mdns
To enable mDNS packet processing messages:
(host)(config) #logging level debugging system process mdns subcat messages
To enable mDNS CLI configuration messages:
(host)(config) #logging level debugging system process mdns subcat configuration
To enable mDNS Auth and CPPM user messages:
(host)(config) #logging level debugging user process mdns
Show Commands
Use the following show commands to view AirGroup configuration data and statistics in the controller:
Viewing AirGroup mDNS and DLNA Cache show airgroup cache entries [mdns|dlna|static]
Viewing AirGroup mDNS and DLNA Statistics show airgroup internal-state statistics [mdns|dlna]
Viewing AirGroup VLANs
(host) #show airgroup vlan
Viewing AirGroup Servers
Use the following command to view the AirGroup server (Apple TV, AirPrint Printer, Google ChromeCast, and so on) status in the controller: show airgroup servers [dlna|mdns] [verbose]
Viewing AirGroup Users show airgroup users [mdns|dlna] [verbose]
Viewing Service Queries Blocked by AirGroup
This command displays the service ID that was queried but not available in the AirGroup service table.
show airgroup blocked-queries [mdns|dlna]
Viewing Blocked Services
The airgroup service <servicename> disable command disables an AirGroup service by blocking the service IDs for that service. When you enable an AirGroup service, service IDs of that service are enabled automatically. To view the list of blocked services, use the following command: show airgroup blocked-service-id [mdns|dlna]
ArubaOS 6.5.3.x
| User Guide AirGroup | 1046
AirGroup Global Tokens
In an AirGroup network, AirGroup devices generate excess mDNS query and response packets. Using airgroup global-credits command, the AirGroup controller restricts these packets by assigning tokens. The controller processes these mDNS packets based on this token value. The controller rejects any packets beyond this token limit. The token renews every 15 seconds. The renewal interval is not a configurable parameter.
In the following example, the AirGroup controller restricts the number of query packets to 450 and response packets to 90 from AirGroup devices in a time frame of 15 seconds.
(host)(config) #airgroup global-credits 450 90
The following command displays tokens assigned to query and response packets. It displays the current and user configured global tokens.
(host) #show airgroup global-credits
For more information, see ArubaOS 6.4 Command-Line Interface Reference Guide .
1047 | AirGroup ArubaOS 6.5.3.x | User Guide
Chapter 42
Instant AP VPN Support
ArubaOS is the companion controller release for the Aruba Instant release. This release provides an ability to terminate VPN and GRE tunnels from Instant AP (IAP) and provide corporate connectivity to the branch IAP network. For more details, see the Aruba Instant User Guide .
VPN features are ideal for: n n n enterprises with many branches that do not have a dedicated VPN connection to the Head Quarter.
branch offices that require multiple APs.
individuals working from home, connecting to the VPN.
This new architecture and form factor seamlessly adds the survivability feature of Instant APs with the VPN connectivity of RAPs — providing corporate connectivity to branches.
This section includes the following topics: n n n
VPN Configuration on page 1053
Viewing Branch Status on page 1054
Overview
This section provides a brief summary of the new features included in ArubaOS to support VPN termination from IAP.
Improved DHCP Pool Management
IAP allows you to configure the DHCP address assignment for the branches connected to the corporate network through VPN. In distributed DHCP mode, ArubaOS 6.3 allows designated blocks of IP addresses for static IP users by excluding them from the DHCP scope. In addition, it allows creation of scope of any required size, thereby enabling more efficient utilization of IP address across branches. For detailed information on
Distributed DHCP for IAP-VPN, see Aruba Instant User Guide .
Termination of Instant AP VPN Tunnels
You can configure IAPs to terminate VPN tunnels on controllers. When configured, the IAP cluster creates a tunnel from the Virtual Controller (VC) to an Aruba controller. However, the controller only acts as a VPN endpoint and does not configure the IAP. For more information on how to create a VPN tunnel from a VC to an
Aruba controller, see Aruba Instant User Guide .
Termination of IAP GRE Tunnels
IAPs have the ability to terminate GRE tunnels on controllers. The IAP cluster creates a tunnel from the VC to the controller in your corporate office. The controller only acts as a GRE end-point and does not configure the
IAP. For more information on how to create a GRE tunnel from VC to the controller, see the Aruba Instant
Guide .
L2/L3 Network Mode Support
The IAP functioning as a VC enables different DHCP pools (various deployment models) in addition to allocating IP subnets to each branch.
ArubaOS 6.5.3.x
| User Guide Instant AP VPN Support | 1048
IAPs support the following DHCP configuration modes: n
L2 Switching Mode: In this mode, IAP supports distributed L2 and centralized L2 switching modes of connection to the corporate network. When an IAP registers with the controller and has a L2 mode DHCP pool configured, the controller automatically adds the GRE or VPN tunnel associated to this IAP into the
VLAN multicast table. This allows the clients connecting to this L2 mode VLAN to be part of the same L2 domain on controller.
n
L3 Routing Mode: In this mode, IAP supports L3 routing mode of connection to the corporate network. The
VC assigns an IP addresses from the configured subnet and forwards traffic to both corporate and noncorporate destinations. The IAP handles the routing on the subnet and also adds a route on the controller after the VPN tunnel is set up during the registration of the subnet. When the IAP registers with a L3 mode
DHCP pool, the controller automatically adds a route to this DHCP subnet enabling routing of traffic from the corporate network to clients on this VLAN in the branch.
Instant AP VPN Scalability Limits
ArubaOS provides enhancements to the scalability limits for the IAP VPN branches terminating on the controller. The following table provides the IAP VPN scalability information for various controller platforms:
Table 262: Instant AP VPN Scalability Limits
Platforms Branches Routes
7210
7220
8000
16000
8000
16000
7240 32000 32000
L3 Mode Users NAT Users Total L2 Users
64000
128000
128000 n n n n
Branches —The number of IAP VPN branches that can be terminated on a given controller platform.
Routes —The number of L3 routes supported on the controller.
L3 mode and NAT mode users —The number of trusted users supported on the controller. There is no scale impact on the controller. They are limited only by the number of clients supported per Instant AP.
L2 mode users —The number of L2 mode users are limited to 128000 for 7220 and 7240 and 64000 across all other platforms.
Instant AP VPN OSPF Scaling
ArubaOS allows each IAP VPN to define a separate subnet derived from a corporate intranet pool to allow IAP
VPN devices to work independently. For information on sample topology and configuration, see
.
To redistribute IAP VPN routes into the OSPF process, use the following command :
(host)(config) # router ospf redistribute rapng-vpn
To verify if the redistribution of the IAP VPN is enabled, use following command:
(host) #show ip ospf redistribute
Redistribute RAPNG
To configure aggregate route for IAP VPN routes, use the following command:
(host) (config) # router ospf aggregate-route rapng-vpn
1049 | Instant AP VPN Support ArubaOS 6.5.3.x | User Guide
To view the aggregated routes for IAP VPN routes, use the following command:
(host) #show ip ospf rapng-vpn aggregate-routes
RAPNG VPN aggregate routes
--------------------------
Prefix Mask Contributing routes Cost
------ ---- ------------------- ----
201.201.200.0 255.255.252.0 5 268779624
100.100.2.0 255.255.255.0 1 10
To verify the details of configured aggregated route, use the following command:
(host) # show ip ospf rapng-vpn aggregated-routes <net> <mask>
ArubaOS 6.5.3.x
| User Guide Instant AP VPN Support | 1050
(host) #show ip ospf rapng-vpn aggregate-routes 100.100.2.0 255.255.255.0
Contributing routes of RAPNG VPN aggregate route
------------------------------------------------
Prefix Mask Next-Hop Cost
------ ---- -------- ----
100.100.2.64 255.255.255.224 5.5.0.10 10
To view all the redistributed routes:
(host) #show ip ospf database
OSPF Database Table
-------------------
Area ID LSA Type
--------------
0.0.0.15
ROUTER
Link ID
-------
9.9.9.9
0.0.0.15
ROUTER
0.0.0.15
NETWORK
0.0.0.15
NSSA
0.0.0.15
NSSA
10.15.148.12
10.15.148.12
12.12.2.0
12.12.12.0
Adv Router
----------
9.9.9.9
10.15.148.12
10.15.148.12
9.9.9.9
9.9.9.9
Age Seq#
------
Checksum
--------
159 0x80000016 0xee92
166
167
29
164
0x80000016
0x80000001
0x80000003
0x80000008
0x4c0d
0x9674
0x7b54
0x63a
0.0.0.15
NSSA
0.0.0.15
NSSA
0.0.0.15
NSSA
0.0.0.15
NSSA
12.12.12.32
50.40.40.0
9.9.9.9
9.9.9.9
51.41.41.128
9.9.9.9
53.43.43.32
9.9.9.9
0.0.0.15
NSSA
N/A AS_EXTERNAL
54.44.44.16
12.12.2.0
N/A
N/A
AS_EXTERNAL
AS_EXTERNAL
12.12.12.0
12.12.12.32
9.9.9.9
9.9.9.9
9.9.9.9
9.9.9.9
N/A
N/A
N/A
N/A
AS_EXTERNAL 50.40.40.0
9.9.9.9
AS_EXTERNAL 51.41.41.128
9.9.9.9
AS_EXTERNAL 53.43.43.32
AS_EXTERNAL 54.44.44.16
9.9.9.9
9.9.9.9
164
164
164
164
164
29
0x80000008
0x80000007
0x80000007
0x80000007
0x80000007
0x80000003
0x7b8
0x8ed4
0x68f6
0x2633
0x353
0x8c06
169 0x80000001 0x25e4
169 0x80000001 0x2663
169
169
169
169
0x80000001
0x80000001
0x80000001
0x80000001
0xab80
0x85a2
0x43de
0x20fe
To verify if the redistributed routes are installed or not.
C
C
C
C
C
C
C
V
V
V
V
V
V
S*
V
(host) #show ip route
Codes: C - connected, O - OSPF, R - RIP, S - static
M - mgmt, U - route usable, * - candidate default, V - RAPNG VPN
Gateway of last resort is Imported from DHCP to network 0.0.0.0 at cost 10
Gateway of last resort is Imported from CELL to network 0.0.0.0 at cost 10
Gateway of last resort is Imported from PPPOE to network 0.0.0.0 at cost 10
Gateway of last resort is 10.15.148.254 to network 0.0.0.0 at cost 1
0.0.0.0/0 [1/0] via 10.15.148.254*
12.12.2.0/24 [10/0] ipsec map
12.12.12.0/25 [10/0] ipsec map
12.12.12.32/27 [10/0] ipsec map
50.40.40.0/24 [10/0] ipsec map
51.41.41.128/25 [10/0] ipsec map
53.43.43.32/27 [10/0] ipsec map
54.44.44.16/28 [10/0] ipsec map
9.9.9.0/24 is directly connected, VLAN9
10.15.148.0/24 is directly connected, VLAN1
43.43.43.0/24 is directly connected, VLAN132
42.42.42.0/24 is directly connected, VLAN123
44.44.44.0/24 is directly connected, VLAN125
182.82.82.12/32 is an ipsec map 10.15.149.69-182.82.82.12
182.82.82.14/32 is an ipsec map 10.17.87.126-182.82.82.14
Branch-ID Allocation
For branches deployed in distributed L3 and distributed L2 modes, the master AP in the branch and the controller must agree upon a subnet and IP addresses to be use for DHCP services in the branch. The process or protocol used by the master AP and the controller to determine the subnet and IP addresses used in a
1051 | Instant AP VPN Support ArubaOS 6.5.3.x | User Guide
branch is called BID allocation. If the branches are deployed in local only or centralized l2 only modes, the BID allocation process is not required.
The BID allocation process performs the following functions: n
Determines the IP addresses used in a branch for distributed L2 mode n n n
Determines the subnet used in a branch for distributed L3 mode
Avoids IP address or subnet overlap (that is, avoids IP conflict)
Ensures that a branch is allocated the same subnet or range of IP addresses irrespective of which AP in the branch assumes the role of the master in an IAP cluster
BID Allocation in a Master-Local Topology
In a master-local controller setup, the master controller runs the BID allocation algorithm and allocates BID to the branches terminating on it and the Local controllers. The IAP sends the new branch registration requests to the Local controller (branch coming for the first time with BIDs as -1 ), which in turn forwards the request to the master controller. After receiving the registration request, the master controller allocates BIDs to the local controller and local controller sends the BID details to the IAP. The master controller saves the BIDs in its memory and the IAP database to avoid the collision of BID (per subnet), whereas the local controller saves the
BIDs only in its memory.
Trusted Branch Validation
The branch registration requests sent by the IAP indicates whether the IAP is managed by AirWave or Central, and provides information about the IAP configuration modes on AirWave (managed or monitored modes).
Based on the information received in the registration request and the status of trusted branch configuration, controller allows the IAP to register the branch.
maps the IAP configuration scenario to the branch registration and trusted branch validation process.
Table 263: Branch Registration and Trusted Branch Validation
IAP Configuration Mode on
AirWave or Central
Trusted Branch DB validation Enabled on
Controller
Monitor mode Yes
Branch Registration
Allowed?
No
Monitor mode No Yes
Managed mode Yes Yes
Managed mode No Yes
Not managed by AirWave or
Central
Not managed by AirWave or
Central
Yes
No
No
Yes
To enable trusted branch DB validation: n n
Ensure that the IAPs are running Instant 4.0 or later.
Ensure that the controller is upgraded to ArubaOS 6.4 or later.
ArubaOS 6.5.3.x
| User Guide Instant AP VPN Support | 1052
If you have a master-local setup, upgrade the master controller first, and then the Local controller.
n
Ensure that the IAP-VPN branches are configured through the AirWave or Central management interfaces. If the IAP VPN branches are not managed by AirWave or Central, or if your network has IAPs running Instant
3.4 or lower release versions, execute the following command to ensure that all branches are in the trusted list: iap trusted-branch-db allow-all or iap trusted-branch-db add mac-address <mac-address>
VPN Configuration
The following VPN configuration steps on the controller enable IAPs to terminate their VPN connection on the controller:
Whitelist DB Configuration
Controller Whitelist DB
You can use the following CLI command to configure the whitelist DB if the controller is acting as the whitelist entry:
(host) #whitelist-db rap add mac-address 00:11:22:33:44:55 ap-group test
The ap-group parameter is not used for any configuration, but needs to be configured. The parameter can be any valid string. If an external whitelist is being used, the MAC address of the AP needs to be saved in the
Radius server as a lower case entry without any delimiter.
External Whitelist DB
The external whitelist functionality enables you to configure the RADIUS server to use an external whitelist for authentication of MAC addresses of RAPs.
If you are using Windows 2003 server, perform the following steps to configure external whitelist on it. There are equivalent steps available for Windows Server 2008 and other RADIUS servers.
1. Add the MAC addresses for all the RAPs in the Active Directory of the Radius server: a. Open the Active Directory and Computers window, add a new user and specify the MAC address
(without the colon delimiter) of the RAP for the user name and password.
b. Right-click the user that you have just created and click Properties .
c. In the Dial-in tab, select Allow access in the Remote Access Permission section and click OK .
d. Repeat Step a through Step b for all RAPs.
2. Define the remote access policy in the Internet Authentication Service: a. In the Internet Authentication Service window, select Remote Access Policies .
b. Launch the wizard to configure a new remote access policy.
c. Define filters and select grant remote access permission in the Permissions window.
d. Right-click the policy that you have just created and select Properties .
e. In the Settings tab, select the policy condition, and Edit Profile...
.
f. In the Advanced tab, select Vendor Specific , and click Add to add new vendor specific attributes.
g. Add new vendor specific attributes and click OK .
h. In the IP tab, provide the IP address of the RAP and click OK .
1053 | Instant AP VPN Support ArubaOS 6.5.3.x | User Guide
VPN Local Pool Configuration
The VPN local pool is used to assign an IP Address to the IAP after successful XAUTH VPN.
(host) # ip local pool "rapngpool" <startip> <endip>
Role Assignment for the Authenticated IAPs
Define a role that includes a source NAT rule to allow connections to the RADIUS server and for the Dynamic
Radius Proxy in the IAP to work. This role is assigned to IAPs after successful authentication.
(host) (config) #ip access-list session iaprole
(host) (config-sess-iaprole) #any host <radius-server-ip> any src-nat
(host) (config-sess-iaprole) #any any any permit
(host) (config-sess-iaprole) #!
(host) (config) #user-role iaprole
(host) (config-role) #session-acl iaprole
VPN Profile Configuration
The VPN profile configuration defines the server used to authenticate the IAP (internal or an external server) and the role assigned to the IAP after successful authentication.
(host) (config) #aaa authentication vpn default-iap
(host) (VPN Authentication Profile "default-iap") #server-group default
(host) (VPN Authentication Profile "default-iap") #default-role iaprole
The default role parameter of the aaa authentication vpn command requires Policy Enforcement Firewall for
VPN users (PEFV) license.
By default, the controller uses the default IAP role. If the administrator changes the IAP role name when the IAP's status is UP, then the controller or the IAP must be rebooted.
For more information on VPN profile configuration, see the VPN Configuration chapter of the Aruba Instant
User Guide .
Viewing Branch Status
To view the details of the branch information connected to the controller, execute the show iap table command.
Sample Configuration
This example shows the details of the branches connected to the controller:
(host) #show iap table long
IAP Branch Table
----------------
Name
----
VC MAC Address
--------------
Status Inner IP
-------------
Tokyo-CB:D3:16 6c:f3:7f:cc:42:f8 DOWN
Paris-CB:D3:16 6c:f3:7f:cc:3d:04 UP
0.0.0.0
10.15.207.140
Assigned Subnet
---------------
10.15.206.99/29
Assigned Vlan
-------------
2
LA
Munich
London-c0:e1
Instant-CB:D3
Delhi
Singapore
6c:f3:7f:cc:42:25 d8:c7:c8:cb:d3:16
6c:f3:7f:c0:e1:b1
6c:f3:7f:cc:42:1e
6c:f3:7f:cc:42:ca
6c:f3:7f:cc:42:cb
UP
DOWN
UP
DOWN
DOWN
UP
10.15.207.111
0.0.0.0
10.15.207.120
0.0.0.0
0.0.0.0
10.15.207.122
10.15.206.24/29
10.15.206.64/29
2
2
10.15.206.120/29 2
Key
---
Bid(Subnet Name)
----------------
ArubaOS 6.5.3.x
| User Guide Instant AP VPN Support | 1054
b3c65c...
b3c65c...
b3c65c...
2(10.15.205.0-10.15.205.250,5),1(10.15.206.1-10.15.206.252,5) a2a65c...
0 b3c65c...
7(10.15.205.0-10.15.205.250,5),8(10.15.206.1-10.15.206.252,5) b3c65c...
b3c65c...
1(10.15.205.0-10.15.205.250,5),2(10.15.206.1-10.15.206.252,5) b3c65c...
14(10.15.205.0-10.15.205.250,5),15(10.15.206.1-10.15.206.252,5)
The output of this command includes the following parameters:
Table 264: IAP Table Parameters
Parameter
Name
Description
Displays the name of the branch.
VC MAC Address
Status
Inner IP
Assigned Subnet
Displays the MAC address of the Virtual Controller of the branch.
Displays the current status of the branch (UP/DOWN).
Displays the internal VPN IP of the branch.
Displays the subnet mask assigned to the branch.
Assigned Vlan
Key
Displays the VLAN ID assigned to the branch.
Displays the key for the branch, which is unique to each branch.
Bid(Subnet Name) Displays the Branch ID (BID) of the subnet.
n
In the example above, the controller displays bid-per-subnet-per-branch i.e., for
"LA" branch, BID "2" for the ip-range "10.15.205.0-10.15.205.250" with client count per branch "5"). If a branch has multiple subnets, it can have multiple BIDs.
n Branches that are in UP state and do not have a Bid(Subnet Name) means that the IAP is connected to a controller which did not assign any bid for any subnet. In the above example, "Paris-CB:D3:16" branch is UP and does not have a Bid
(Subnet Name) information. This means that either the IAP is connected to a backup controller or connected to a primary controller without any distributed L2 or L3 subnets.
For more information on bid-per-subnet-per-branch and distributed L2 and L3 subnets, see the DHCP Configuration chapter of the Aruba Instant Access Point 6.2.1.0-
3.3 User Guide .
Executing the show iap table command does not display the Key and Bid(Subnet Name) parameters.
1055 | Instant AP VPN Support ArubaOS 6.5.3.x | User Guide
Chapter 43
External Services Interface
The External Services Interface (ESI) provides an open interface that is used to integrate security solutions that solve interior network problems such as viruses, worms, spyware, and corporate compliance. ESI allows selective redirection of traffic to external service appliances such as anti-virus gateways, content filters, and intrusion detection systems. When “interesting” traffic is detected by these external devices, it can be dropped, logged, modified, or transformed according to the rules of the device. ESI also permits configuration of different server groups—with each group potentially performing a different action on the traffic.
You can configure ESI to do one or more of the following for each group: n n n n
Redirect specified types of traffic to the server
Perform health checks on each of the servers in the group
Perform per-session load balancing between the servers in each group
Provide an interface for the server to return information about the client that can place the client in special roles such as “quarantine"
ESI cannot function or send information across an IPSec tunnel.
ESI also provides the ESI syslog parser, which is a mechanism for interpreting syslog messages from third-party appliances such as anti-virus gateways, content filters, and intrusion detection systems. The ESI syslog parser is a generic syslog parser that accepts syslog messages from external devices, processes them according to userdefined rules, and then takes configurable actions on system users.
Topics in this chapter include: n n n n n n
Sample ESI Topology on page 1056
Understanding the ESI Syslog Parser on page 1058
Sample Route-Mode ESI Topology on page 1067
Sample NAT-mode ESI Topology on page 1072
Understanding Basic Regular Expression (BRE) Syntax on page 1077
The ESI feature requires that the Policy Enforcement Firewall Next Generation (PEFNG) license is installed on the controller.
Sample ESI Topology
In the example shown in this section, ESI is used to provide an interface to the AntiVirusFirewall (AVF) server device for providing virus inspection services. An AVF server device is one of many different types of services supported in the ESI.
In ArubaOS 3.x, the only AVF server supported is Fortinet.
ArubaOS 6.5.3.x
| User Guide External Services Interface | 1056
Figure 231 ESI-Fortinet Topology
In the ESI–Fortnet topology, the clients connect to access points (both wireless and wired). The wired access points tunnel all traffic back to the controller over the existing network.
The controller receives the traffic and redirects relevant traffic (including but not limited to all HTTP/HTTPS and email protocols such as SMTP and POP3) to the AVF server device to provide services such as anti-virus scanning, email scanning, web content inspection, etc. This traffic is redirected on the “untrusted” interface between the controller and the AVF server device. The controller also redirects the traffic intended for the clients coming from either the Internet or the internal network. This traffic is redirected on the “trusted” interface between the controller and the AVF server device. The controller forwards all other traffic (for which the AVF server does not perform any of the required operations such as AV scanning). An example of such traffic would be database traffic running from a client to an internal server.
The controller can also be configured to redirect traffic only from clients in a particular role such as “guest” or
“non-remediated client” to the AVF server device. This might be done to reduce the load on the AVF server device if there is a different mechanism such as the Aruba-Sygate integrated solution to enforce client policies on the clients that are under the control of the IT department. These policies can be used to ensure that an anti-virus agent runs on the clients and the client can get access to the network only if this agent reports a
“healthy” status for the client. Refer to the paper (available from Sygate) on Sygate integrated solutions for more details on this solution.
The controller is also capable of load balancing between multiple external server appliances. This provides more scalability as well as redundancy by using multiple external server appliances. Also, the controller can be configured to have multiple groups of external server devices and different kinds of traffic can be redirected to different groups of devices with load balancing occurring within each group (see
for an example).
1057 | External Services Interface ArubaOS 6.5.3.x | User Guide
Figure 232 Load Balancing Groups
Understanding the ESI Syslog Parser
The ESI syslog parser adds a UNIX-style regular expression engine for parsing relevant fields in messages from third-party appliances such as anti-virus gateways, content filters, and intrusion detection systems.
The user creates a list of rules that identify the type of message, the username to which this message pertains, and the action to be taken when there is a match on the condition.
ESI Parser Domains
The ESI servers are configured into ESI parser domains (see
) to which the rules will be applied. This condition ensures that only messages coming from configured ESI parser domains are accepted, and reduces the number of rules that must be examined before a match is detected (
Syslog Parser Rules on page 1059
).
messages. When a syslog message is received, it is checked against the list of defined ESI servers. If a server match is found, the message is then tested against the list of predefined rules.
Figure 233 ESI Parser Domains
ArubaOS 6.5.3.x
| User Guide External Services Interface | 1058
The ESI syslog parser begins with a list of configured IP interfaces which listen for ESI messages. When a syslog message is received, it is checked against the list of defined ESI servers. If a server match is found, the message is then tested against the list of predefined rules.
Within the rule-checking process, the incoming message is checked against the list of rules to search first for a condition match (see
Syslog Parser Rules on page 1059
). If a condition match is made, and the user name can be extracted from the syslog message, the resulting user action is processed by first attempting to look up the user in the local user table. If the user is found, the appropriate action is taken on the user. The default behavior is to look for users only on the local controller. If the user is not found, the event is meaningless and is ignored. This is the typical situation when a single controller is connected to a dedicated ESI server.
Peer Controllers
As an alternative, consider a topology where multiple controllers share one or more ESI servers.
Figure 234 ESI Peer Controllers
In this scenario, several controllers (master and local) are defined in the same syslog parser domain to act as peers . From the standpoint of the ESI servers, because there is no accurate way of determining from which controller a given user came. Thus, the event is flooded out to all controllers defined as peers within this ESI parser domain. The corresponding controller holding the user entry acts on the event, while other controllers ignore the event.
Syslog Parser Rules
The user creates an ESI rule by using characters and special operators to specify a pattern (regular expression) that uniquely identifies a certain amount of text within a syslog message. (Regular expression syntax is described in
Understanding Basic Regular Expression (BRE) Syntax on page 1077
.) This “condition” defines the type of message and the ESI domain to which this message pertains. The rule contains three major fields: n n n
Condition: The pattern that uniquely identifies the syslog message type.
User: The username identifier. It can be in the form of a name, MAC address, or IP address.
Action: The action to take when a rule match occurs.
Once a condition match has been made, no further rule-matching will be made. For the rule that matched, only one action can be defined.
After a condition match has been made, the message is parsed for the user information. This is done by specifying the target region with the regular expression (REGEX) regex() block syntax. This syntax generates
1059 | External Services Interface ArubaOS 6.5.3.x | User Guide
two blocks: The first block is the matched expression; the second block contains the value inside the parentheses. For username matching, the focus is on the second block, as it contains the username.
Condition Pattern Matching
The following description uses the Fortigate virus syslog message format as an example to describe condition pattern matching. The Fortigate virus syslog message takes the form:
Sep 26 18:30:02 log_id=0100030101 type=virus subtype=infected src=1.2.3.4
This message example contains the Fortigate virus log ID number 0100030101 (“log_id=0100030101”), which can be used as the condition—the pattern that uniquely identifies this syslog message.
The parser expression that matches this condition is “log_id=0100030101”. This is a narrow match on the specific log ID number shown in the message, or “log_id=[0–9]{10}[ ]” ,which is a regular expression that matches any Fortigate log entry with a ten-digit log ID followed by a space.
User Pattern Matching
To extract the user identifier in the example Fortigate virus message shown above (“src=1.2.3.4”), use the following expression, “src=(.*)[ ]” to parse the user information contained between the parentheses. The () block specifies where the username will be extracted. Only the first block will be processed.
More examples:
Given a message wherein the username is a MAC address:
Sep 26 18:30:02 log_id=0100030101 type=virus subtype=infected mac 00:aa:bb:cc:dd:00
The expression “mac[ ](.{17})” will match “mac 00:aa:bb:cc:dd:00” in the example message.
Given a message wherein the username is a user name:
Sep 26 18:30:02 log_id=0100030101 type=virus subtype=infected user<johndoe>
The expression “user<(.*)>” will match “user<johndoe>” in the example message.
n n
Configuring ESI
You can use the following interfaces to configure and manage ESI and ESI syslog parser behavior:
The Web user interface (WebUI), which is accessible through a standard Web browser from a remote management console or workstation.
The command line interface (CLI), which is accessible from a local console device connected to the serial port on the controller or through a Telnet or Secure Shell (SSH) connection from a remote management console or workstation.
By default, you can access the CLI only from the serial port or from an SSH session. To use the CLI in a Telnet session, you must explicitly enable Telnet on the controller. The general configuration descriptions in the following sections include both the WebUI pages and the CLI configuration commands. The configuration overview section is followed by several examples that show specific configuration procedures.
n
The Aruba Management System, which is a suite of applications for monitoring multiple master controllers and their related local controllers and APs. Each application provides a Web-based user interface. The Aruba
Management System is available as an integrated appliance and as a software application that runs on a dedicated system. See the Mobility Manager User Guide for more information.
In general, there are three ESI configuration “phases” on the controller as a part of the solution:
ArubaOS 6.5.3.x
| User Guide External Services Interface | 1060
n n n
The first phase configures the ESI ping health-check method , servers , and server groups . The term server here refers to external server devices, for example, an AVF.
The second phase configures the redirection policies instructing the controller how to redirect the different types of traffic to different server groups.
The final phase configures the ESI syslog parser domains and the rules that interpret and act on syslog message contents.
The procedures shown in the following sections are general descriptions. Your application might be broader or narrower than this example, but the same general operations apply.
Configuring Health-Check Method, Groups, and Servers
To configure the ESI health-check method, servers, and server groups, navigate to the Configuration >
Advanced Services > External Services view on the WebUI.
In the WebUI
1. Navigate to the Configuration > Advanced Services > External Services page.
2. Click Add in the Health Check Configuration section.
(To change an existing profile, click Edit .)
3. Provide the following details: a. Enter a Profile Name .
b.
Frequency (secs) —Indicates how often the controller checks to see if the server is up and running.
Default: 5 seconds.
c.
Timeout (secs) —Indicates the number of seconds the controller waits for a response to its health check query before marking the health check as failed. Default: 2 seconds.
d.
Retry count —Is the number of failed health checks after which the controller marks the server as being down. Default: 2.
4. Click Done.
5. Click Apply .
In the CLI esi ping profile_name frequency seconds retry-count count timeout seconds
Defining the ESI Server
The following sections describe how to configure an ESI server using the WebUI and CLI.
In the WebUI
1. Navigate to the Configuration > Advanced Services > External Services page on the WebUI.
2. Click Add in the External Servers section.
3. Provide the following details: a.
Server Name .
b.
Server Group . Use the drop-down list to assign this server to a group from the existing configured groups.
c.
Server Mode . Use the drop-down list to choose the mode (bridge, nat, or route) your topology requires.
Refer to the description above to understand the differences between these modes.
1061 | External Services Interface ArubaOS 6.5.3.x | User Guide
For routed mode, enter the Trusted IP Address (the IP address of the trusted interface on the external server device) and the Untrusted IP Address (the IP address of the untrusted interface on the external server device). (You can also choose to enable a health check on either or both of these interfaces.)
For bridged mode, enter the Trusted Port number (the port connected to the trusted side of the ESI server) and the Untrusted Port number (the port connected to the untrusted side of the ESI server).
For NAT mode, enter the Trusted IP Address (the trusted interface on the external server) and the
NAT Destination Port number (the port a packet is redirected to rather than the original destination port in the packet). You can also choose to enable a health check on the trusted IP address interface.
4. Click Done .
5. Click Apply .
In the CLI esi server server_identity dport destination_tcp/udp_port mode {bridge | nat | route} trusted-ip-addr ip-addr [health-check] trusted-port slot/port untrusted-ip-addr ip-addr [health-check] untrusted-port slot/port
Defining the ESI Server Group
The following sections describe how to configure an ESI server group using the WebUI and CLI.
In the WebUI
1. Navigate to the Configuration > Advanced Services > External Services page.
2. Click Add in the Server Groups section.
(To change an existing group, click Edit .)
3. Provide the following details: a. Enter a Group Name .
b. In the drop-down list, select a health check profile.
4. Click Done .
5. Click Apply .
In the CLI esi group name ping profile_name server server_identity
Policies and User Role
The following sections describe how to configure the redirection policies and user role using the WebUI and
CLI.
In the WebUI
1. To configure user roles to redirect the required traffic to the server(s), navigate to the Configuration >
Access Control > User Roles view.
2. To add a new role, click Add .
To change an existing role, click Edit for the firewall policy to be changed. The WebUI displays the User
Roles tab on top.
3.
Role Name . Enter the name for the role.
ArubaOS 6.5.3.x
| User Guide External Services Interface | 1062
4. To add a policy for the new role, click Add in the Firewall Policies section. The WebUI expands the Firewall
Policies section.
Choose from existing configured policies, create a new policy based on existing policies, or create a new policy.
a. If you elect to create a new policy, click on the radio button for Create New Policy and then click
Create . The WebUI displays the Policies tab.
b. In the Policies tab:
Policy Name . Provide the policy name and select the IPv4 Session policy type from the drop-down list.
The WebUI expands the Policies tab.
c. In the drop-down lists, choose parameters such as source, destination, service in the same way as other firewall policy rules. For certain choices, the WebUI expands and adds drop-down lists.
d. In the Action drop-down menu, select the redirect to ESI group option.
e. In the Action drop-down menu, select the appropriate ESI group.
f. Select the traffic direction.
Forward refers to the direction of traffic from the (untrusted) client or user to the (trusted) server (such as the HTTP server or email server).
g. To add this rule to the policy, click Add .
h. Repeat the steps to configure additional rules.
i.
Click Done to return to the User Roles tab. The WebUI returns to the User Roles tab.
5. Click Apply .
6. Refer to
Roles and Policies on page 381 , for directions on how to apply a policy to a user role.
In the CLI ip access-list session policy any any any redirect esi-group group direction both blacklist
//For any incoming traffic, going to any destination,
//redirect the traffic to servers in the specified ESI group.
any any any permit
//For everything else, allow the traffic to flow normally.
user-role role access-list {eth | mac | session} bandwidth-contract name captive-portal name dialer name pool {l2tp | pptp} reauthentication-interval minutes session-acl name vlan vlan_id
ESI Syslog Parser Domains and Rules
To configure the ESI syslog parser, navigate to the Configuration > Advanced Services > External Services view on the WebUI. The following sections describe how to manage syslog parser domains using the WebUI and CLI.
In the WebUI
Click on the Syslog Parser Domains tab to display the Syslog Parser Domains view.
This view lists all the domains by domain name and server IP address, and includes a list of peer controllers
(when peer controllers have been configured—as described in
Understanding the ESI Syslog Parser on page
).
1063 | External Services Interface ArubaOS 6.5.3.x | User Guide
Adding a new syslog parser domain
1. Click Add in the Syslog Parser Domains section. The system displays the add domain view.
2. In the Domain Name text box, type the name of the domain to be added.
3. In the Server IP Address text box, type a valid IP address.
You must ensure that you type a valid IP address, because the IP address you type is not automatically validated against the list of external servers that has been configured.
4. Click Add .
5. Click Apply .
Deleting an existing syslog parser domain
1. Identify the target parser domain in the list shown in the Domain section of the Syslog Parser Domains view.
2. Click Delete on the same row in the Actions column.
Editing an existing syslog parser domain
1. Identify the target parser domain in the list shown in the Syslog Parser Domains view .(see
)
2. Click Edit on the same row in the Actions column. The system displays the edit domain view.
You cannot modify the domain name when editing a parser domain.
3. To delete a server from the selected domain, highlight the server IP address and click Delete , then click
Apply to commit the change.
4. To add a server or a peer controller to the selected domain, type the server IP address into the text box next to the Add button, click Add , then click Apply to commit the change, or click Cancel to discard the changes you made and exit the parser domain editing process.
When you make a change in the domain, you can click the View Commands link in the lower right corner of the window to see the CLI command that corresponds to the edit action you performed.
In the CLI
Use these CLI commands to manage syslog parser domains.
Adding a new syslog parser domain esi parser domain name peer peer-ip server ipaddr
Showing ESI syslog parser domain information show esi parser domains
Deleting an existing syslog parser domain no esi parser domain name
Editing an existing syslog parser domain esi parser domain name no peer peer-ip server ipaddr
ArubaOS 6.5.3.x
| User Guide External Services Interface | 1064
Managing Syslog Parser Rules
The following sections describe how to manage syslog parser rules using the WebUI and CLI.
In the WebUI
Click on the Syslog Parser Rules tab to display the Syslog Parser Rules view. This view displays a table of rules with the following columns: n n n n n n n n n
Name— rule name
Ena—where “y” indicates the rule is enabled and “n” indicates the rule is disabled (not enabled)
Condition—Match condition (a regular expression)
Match—Match type (IP address, MAC address, or user)
User—Match pattern (a regular expression)
Set—Set type (blacklist or role)
Value—Set value (role name)
Domain—Parser domain to which this rule is to be applied
Actions—The actions that can be performed on each rule.
Adding a new parser rule
To add a new syslog parser rule:
1. Click Add in the Syslog Parser Rules view. The system displays the new rule view.
1. In the Rule Name text box, type the name of the rule you want to add.
2. Click the Enable checkbox to enable the rule.
3. In the Condition Pattern text box, type the regular expression to be used as the condition pattern.
For example, “log_id=[0–9]{10}[ ]” to search for and match a 10-digit string preceded by “log_id=” and followed by one space.
4. In the drop-down Match list, use the drop-down menu to select the match type (ipaddr, mac, or user).
5. In the Match Pattern text box, type the regular expression to be used as the match pattern.
For example, if you selected “mac” as the match type, type the regular expression to be used as the match pattern. You could use “mac[ ](.{17})” to search for and match a 17-character MAC address preceded by the word “mac” plus one space.
6. In the drop-down Set list, select the set type (blacklist or role).
When you select role as the Set type, the system displays a second drop-down list. Click the list to display the possible choices and select the appropriate role value. Validation on the entered value will be based on the Set selection.
7. In the drop-down Parser Group list, select one of the configured parser domain names.
Deleting a syslog parser rule
To delete an existing syslog parser rule:
1. Identify the target parser rule in the list shown in the Syslog Parser Rules view.
2. Click Delete on the same row in the Actions column.
Editing an existing syslog parser rule
To change an existing syslog parser rule:
1. Identify the target parser rule in the list shown in the Syslog Parser Rules view.
2. Click Edit on the same row in the Actions column. The system displays the attributes for the selected rule
1065 | External Services Interface ArubaOS 6.5.3.x | User Guide
You cannot modify the rule name when editing a parser rule.
3. Change the other rule attributes as required: a. Click the Enable checkbox to enable the rule.
b. In the Condition Pattern text box, type the regular expression to be used as the condition pattern.
c. In the drop-down Match list, select the match type (ipaddr, mac, or user).
d. In the Match Pattern text box, type the regular expression to be used as the match pattern.
e. In the drop-down Set list, select the set type (blacklist or role).
f. When you select role as the Set type, the system displays a second drop-down list. Click the list to display the possible choices and select the appropriate role value. Validation on the entered value will be based on the Set selection.
g. In the drop-down Parser Group list, select one of the configured parser domain names.
At this point, you can test the rule you just edited by using the Test section of the edit rule view. You can also test rules outside the add or edit processes by using the rule test in the Syslog Parser Test view (accessed from the
External Services page by clicking the Syslog Parser Test tab, described in
Testing a Parser Rule on page 1066 .
4. Click Apply to apply the configuration changes.
Testing a Parser Rule
You can test or validate enabled Syslog Parser rules against a sample syslog message, or against a syslog message file containing multiple syslog messages. Access the parser rules test from the External Services page by clicking the Syslog Parser Test tab, which displays the Syslog Parser Rule Test view.
To test against a sample syslog message: n a. In the drop-down Test Type list, select Syslog message as the test source type.
b. In the Message text box, type the syslog message text.
c. Click Test to start the test.
The test results are displayed in a box in the area below the Test button. The test results contain information about the matching rule and match pattern.
To test against a syslog message file: a. In the drop-down Test Type list, select Syslog file as the test type.
b. In the Filename text box, type the syslog file name.
c. Click Test to start the test.
The test results are displayed in a box in the area below the Test button. The test results contain information about the matching rule and match pattern.
In the CLI
Use these CLI commands to manage syslog parser rules.
Adding a new parser rule esi parser rule rule-name condition expression domain name enable match {ipaddr expression | mac expression | user expression} position position set {blacklist | role role}
ArubaOS 6.5.3.x
| User Guide External Services Interface | 1066
Showing ESI syslog parser rule information show esi parser rules
Deleting a syslog parser rule no esi parser rule rule-name
Editing an existing syslog parser rule esi parser rule rule-name condition expression domain name enable match {ipaddr expression | mac expression | user expression} no position position set {blacklist | role role}
Testing a parser rule esi parser rule rule-name test {file filename | msg message}
Monitoring Syslog Parser Statistics
The following sections describe how to monitor syslog parser statistics using the WebUI and CLI.
In the WebUI
You can monitor syslog parser statistics in the External Servers monitoring page, accessed by selecting
Monitoring > Switch > External Services Interface > Syslog Parser Statistics .
The Syslog Parser Statistics view displays statistics such as the number of matches and number of users per rule, as well as the number of respective actions fired by the syslog parser.
The Syslog Parser Statistics view also displays the last refresh time stamp and includes a Refresh Now button, to allow the statistics information to be refreshed manually. There is no automatic refresh on this page.
In the CLI show esi parser stats
Sample Route-Mode ESI Topology
This section introduces the configuration for a sample route-mode topology using the controller and Fortinet
Anti-Virus gateways. In route mode, the trusted and untrusted interfaces between the controller and the
Fortinet gateways are on different subnets. The following figure shows an example route-mode topology.
ESI with Fortinet Anti-Virus gateways is supported only in route mode.
1067 | External Services Interface ArubaOS 6.5.3.x | User Guide
Figure 235 Example Route-Mode Topology
In the topology shown, the following configurations are entered on the controller and Fortinet gateway:
ESI server configuration on controller n n n
Trusted IP address = 10.168.172.3 (syslog source)
Untrusted IP address = 10.168.171.3
Mode = route
IP routing configuration on Fortinet gateway n n
Default gateway (core router) = 10.168.172.1
Static route for wireless user subnet (10.168.173.0/24) through the controller (10.168.171.2)
Configuring the Example Routed ESI Topology
This section describes how to implement the example routed ESI topology shown in . The description includes the relevant configuration—both the WebUI and the CLI configuration processes are described—required on the controller to integrate with a AVF server appliance.
The ESI configuration process will redirect all HTTP user traffic to the Fortinet server for examination, and any infected user will be blacklisted. The configuration process consists of these general tasks: n n n n n n
Defining the ESI server.
Defining the default ping health check method.
Defining the ESI group.
Defining the HTTP redirect filter for sending HTTP traffic to the ESI server.
Applying the firewall policy to the guest role.
Defining ESI parser domains and rules.
There are three configuration “phases” on the controller as a part of the solution.
n n
The first phase configures the ESI ping health-check method , servers , and server groups . The term server here refers to external AVF server devices.
In the second phase of the configuration task, the user roles are configured with the redirection policies
(session ACL definition) instructing the controller to redirect the different types of traffic to different server groups.
ArubaOS 6.5.3.x
| User Guide External Services Interface | 1068
n
In the final phase, the ESI parser domains and rules are configured.
The procedures shown in the following sections are based on the requirements in the example routed ESI topology.
Your application might be broader or narrower than this example, but the same general operations apply.
Health-Check Method, Groups, and Servers
To configure the ESI health-check method, servers, and server groups, navigate to the Configuration >
Advanced Services > External Services view on the WebUI.
Defining the Ping Health-Check Method
In the WebUI
1. Navigate to the Configuration > Advanced Services > External Services page on the WebUI.
2. Click Add in the Health Check Configuration section.
To change an existing profile, click Edit .
3. Provide the following details: a. Enter enter the name default for the Profile Name.
b.
Frequency (secs) —Enter 5 .) c.
Timeout (secs) —Indicates the number of seconds the controller waits for a response to its health check query before marking the health check as failed. Default: 2 seconds. (In this example, enter 3 .) d.
Retry count —Is the number of failed health checks after which the controller marks the server as being down. Default: 2. (In this example, enter 3 .)
4. Click Done when you are finished.
5. Click Apply .
In the CLI esi ping profile_name frequency seconds retry-count count timeout seconds
Defining the ESI Server
The following sections describe how to configure an ESI server using the WebUI and CLI.
In the WebUI
1. Navigate to the Configuration > Advanced Services > External Services page on the WebUI.
2. Click Add in the External Servers section.
3. Provide the following details: a.
Server Name . (This example uses the name forti_1 .) b.
Server Group . Use the drop-down list to assign this server to a group from the existing configured groups. (This example uses fortinet .) c.
Server Mode . Use the drop-down list to choose the mode (bridge, nat, or route) your topology requires.
Refer to the description above to understand the differences between the modes. (This example uses route mode.) d.
Trusted IP Address . Enter 10.168.172.3
.) e.
Untrusted IP Address . Enter 10.168.171.3
.)
4. Click Done when you are finished.
1069 | External Services Interface ArubaOS 6.5.3.x | User Guide
5. Click Apply to apply the configuration changes.
In the CLI esi server server_identity dport destination_tcp/udp_port mode {bridge | nat | route} trusted-ip-addr ip-addr [health-check] trusted-port slot / port untrusted-ip-addr ip-addr [health-check] untrusted-port slot / port
Defining the ESI Server Group
The following sections describe how to configure an ESI server group using the WebUI and CLI.
In the WebUI
1. Navigate to the Configuration > Advanced Services > External Services page.
2. Click Add in the Server Groups section.
3. Provide the following details: a. Enter a Group Name.
Enter fortinet .) b. In the drop-down list, select default as the health check profile.
4. Click Done when you are finished.
5. Click Apply to apply the configuration changes.
In the CLI esi group name ping profile_name server server_identity
Redirection Policies and User Role
The following sections describe how to configure the redirection policies and user role using the WebUI and
CLI.
In the WebUI
1. To configure user roles to redirect the required traffic to the server(s), navigate to the Configuration >
Access Control > User Roles view (see
).
2. To add a new role, click Add .The WebUI displays the Add Role view.
Role Name . Enter “guest” as the name for the role.
3. To add a policy for the new role, click Add in the Firewall Policies section. The WebUI expands the Firewall
Policies section.
Choose from existing configured policies, create a new policy based on existing policies, or create a new policy.
a. If you elect to create a new policy, click on the radio button for Create New Policy and then click
Create . The WebUI displays the Policies tab.
b. In the Policies tab:
Policy Name . Enter the policy name fortinet and the IPv4 Session policy type.) Click Add to proceed.
The WebUI expands the Policies tab.
ArubaOS 6.5.3.x
| User Guide External Services Interface | 1070
In the drop-down lists, choose parameters such as source, destination, service in the same way as other firewall policy rules. This example uses any source, any destination, service type svc-http (tcp 80) . For certain choices, the WebUI expands and adds drop-down lists.
c. In the Action drop-down menu, select the redirect to ESI group option.
Select fortinet as the appropriate ESI group.
The three steps above translate to “for any incoming HTTP traffic, going to any destination, redirect the traffic to servers in the ESI group named fortinet.”)
Select both as the traffic direction.
Forward refers to the direction of traffic from the untrusted client or user to the trusted server, such as the HTTP server or email server.
To add this rule to the policy, click Add .
d. Repeat the steps to configure additional rules. This example adds a rule that specifies any, any, any, permit .
e. Click Done to return to the User Roles tab.
4. Click Apply to apply the configuration changes.
5. Refer to
Roles and Policies on page 381 , for directions on how to apply a policy to a user role.
In the CLI
Use these commands to define the redirection filter for sending traffic to the ESI server and apply the firewall policy to a user role in the route-mode ESI topology example.
ip access-list session policy any any any redirect esi-group group direction both blacklist
//For any incoming traffic, going to any destination,
//redirect the traffic to servers in the specified ESI group.
any any any permit
//For everything else, allow the traffic to flow normally.
user-role role access-list {eth | mac | session} bandwidth-contract name captive-portal name dialer name pool {l2tp | pptp} reauthentication-interval minutes session-acl name vlan vlan_id
Syslog Parser Domain and Rules
The following sections describe how to configure the syslog parser domain and rules for the route-mode example using the WebUI and CLI.
In the WebUI
Adding a New Syslog Parser Domain
To add a new syslog parser domain for the routed example:
1. Click Add in the Syslog Parser Domains tab ( Advanced Services > External Services > Syslog Parser
Domain ).
The system displays the new domain view.
2. In the Domain Name text box, type the name of the domain to be added.
3. In the Server (IP Address) text box, type a valid IP address.
1071 | External Services Interface ArubaOS 6.5.3.x | User Guide
You must ensure that you type a valid IP address, because the IP address you type is not automatically validated against the list of external servers that has been configured.
4. Click << Add .
5. Click Apply .
Adding a New Parser Rule
To add a new syslog parser rule for the route-mode example:
1. Click Add in the Syslog Parser Rules tab ( Advanced Services > External Services > Syslog Parser
Rule ).
The system displays the new rule view.
2. In the Rule Name text box, type the name of the rule to be added (in this example, “forti_virus”).
3. Click the Enable checkbox to enable the rule.
4. In the Condition Pattern text box, type the regular expression to be used as the condition pattern. (In this example, the expression “log_id=[0–9]{10}[ ]” searches for and matches a 10-digit string preceded by “log_ id=” and followed by one space.)
5. In the drop-down Match list, use the drop-down menu to select the match type (in this example, ipaddr).
6. In the Match Pattern text box, type the regular expression to be used as the match pattern (in this example, “src=(.*)[ ]”).
7. In the drop-down Set list, select the set type (in this example, blacklist).
8. In the drop-down Parser Group list, select one of the configured parser domain names (in this example,
“forti_domain”).
9. Click Apply .
In the CLI
Use these CLI commands to define a syslog parser domain and the rule to be applied in the route-mode example shown in
.
esi parser domain name peer peer-ip server ipaddr esi parser rule rule-name condition expression domain name enable match {ipaddr expression | mac expression | user expression } position position set {blacklist | role role }
Sample NAT-mode ESI Topology
This section describes the configuration for a sample NAT-mode topology using the controller and three external captive-portal servers. NAT mode uses a trusted interface for each external captive-portal server and a different destination port to redirect a packet to a port other than the original destination port in the packet.
An example topology is shown below in
.
ArubaOS 6.5.3.x
| User Guide External Services Interface | 1072
Figure 236 Example NAT-Mode Topology
Figure 237
In this example, all HTTP traffic received by the controller is redirected to the external captive portal server group and load-balanced across the captive portal servers. All wireless client traffic with destination port 80 is redirected to the captive portal server group, with the new destination port 8080.
The external servers do not necessarily have to be on the subnet as the controller. The policy that redirects traffic to the external servers for load balancing is routed to the external servers if they are on a different subnet.
In the topology shown, the following configurations are entered on the controller and external captive-portal servers:
1073 | External Services Interface ArubaOS 6.5.3.x | User Guide
ESI server configuration on the controller n n n n n n
External captive-portal server 1: l
Name = external_cp1 l l
Mode = NAT
Trusted IP address = 10.1.1.1
l
Alternate destination port = 8080
External captive-portal server 2: l l
Name = external_cp2
Mode = NAT l
Trusted IP address = 10.1.1.2
External captive-portal server 3: l l
Name = external_cp3
Mode = NAT l
Trusted IP address = 10.1.1.3
Health-check ping: l l
Name = externalcp_ping
Frequency = 30 seconds l l
Retry-count = 2 attempts
Timeout = 2 seconds (2 seconds is the default)
ESI group = external_cps
Session access control list (ACL) l l
Name = cp_redirect_acl
Session policy = user any svc-http redirect esi-group external_cps direction both
Configuring the Example NAT-mode ESI Topology
This section describes how to implement the example NAT-mode ESI topology shown in using both the WebUI, then the CLI.
The configuration process consists of these general tasks: n n n n n
Configuring captive portal (see the “Configuring Captive Portal” chapter).
Configuring the health-check ping method.
Configuring the ESI servers.
Configuring the ESI group.
Defining the redirect filter for sending traffic to the ESI server.
Configuring the NAT-mode ESI Example in the WebUI
Navigate to the Configuration > Advanced Services > External Services view on the WebUI (see ).
In the WebUI
Configuring a Health-Check Ping
1. Click Add in the Health-Check Configuration section External Services view on the WebUI.
2. Provide the following details: a.
Profile Name . This example uses externalcp_ping .
b.
Frequency seconds. This example uses 30 .
ArubaOS 6.5.3.x
| User Guide External Services Interface | 1074
c.
Retry Count . This example uses 3 .
If you do not specify a value for a parameter, the WebUI assumes the default value. In this example, the desired timeout value is two seconds; therefore, not specifying the timeout causes the WebUI to use the default value of two seconds.
3. Click Done when you are finished.
To apply the configuration (changes), you must click Apply in the External Services view on the WebUI. In this example, you can wait until you finish configuring the servers and groups, or you can apply after each configuration portion.
Configuring the ESI Group
1. Click Add in the Server Groups section External Services view on the WebUI.
2. Provide the following details: a.
Group Name . This example uses external_cps .
b.
Health-Check Profile . Select the health-check ping from the drop-down list. This example uses externalcp_ping .
3. Click Done when you are finished.
To apply the configuration (changes), you must click Apply in the External Services view on the WebUI. In this example, you can wait until you finish configuring the servers and groups, or you can apply after each configuration portion.
Configuring the ESI Servers
1. Click Add in the External Servers section.
2. Provide the following details: a.
Server Name .
b.
Server Group . Use the drop-down list to assign this server to a group from the existing configured groups.
c.
Server Mode . Use the drop-down list to choose NAT mode.) d.
Trusted IP Address . For nat mode, enter the IP address of the trusted interface on the external captive portal server.
e.
NAT Destination Port . Enter the port number (to redirect a packet to a port other than the original destination port in the packet).
3. Click Done when you are finished.
4. Repeat Step 1 through Step 3 for the remaining external captive portal servers.
5. Click Apply to apply the configuration changes.
Configuring the Redirection Filter
To redirect the required traffic to the server(s) using the WebUI, navigate to the Configuration > Access
Control > User Roles view on the WebUI (see
1. Click the Policies tab.
2. Click Add in the Policies section of the Policies view on the WebUI.
3. Provide the following details: a.
Policy Name . (This example uses cp_redirect_acl .) b.
Policy Type . Select IPv4 Session from the drop-down list.
4. Click Add in the Rules section of the Policies view.
1075 | External Services Interface ArubaOS 6.5.3.x | User Guide
a.
Source . Select user from the drop-down list.
b.
Destination . Accept any .
c.
Service . Select service from the drop-down list; select svc-http (tcp 80) from the secondary dropdown list.
d.
Action . Select redirect to ESI group from the drop-down list; select external_cps from the secondary drop-down list; click <-to add that group.
e. Click Add .
5. Click Done when you are finished.
6. Click Apply to apply the configuration changes.
In the CLI
The CLI configuration process consists of these general tasks: n n n n n
Configuring captive portal (see
Captive Portal Authentication on page 312 ).
Configuring the health-check ping method.
Configuring the ESI servers.
Configuring the ESI group.
Defining the redirect filter for sending traffic to the ESI server.
Configuring a Health-Check Ping
The health-check ping will be associated with an ESI group, along with servers, so that controller will send ICMP echo requests to each server in the group and mark the server down if the controller does not hear from the server. The health-check parameters used in this example are: n n n
Frequency—30 seconds. (The default is 5 seconds.)
Retry-count—3. (The default is 2.)
Timeout—2 seconds. (The default is 2 seconds.)
Use these CLI commands to configure a health-check ping method: esi ping profile_name frequency seconds retry-count count timeout seconds
Configuring ESI Servers
Here are the ESI server CLI configuration tasks: n n n
Configure server mode to be NAT.
Configure the trusted IP address (the server IP address to which packets should be redirected).
To redirect to a different port than the original destination port in the packet, configure an alternate destination port.
Use these CLI commands to configure an ESI server and identify its associated attributes: esi server server_identity dport destination_tcp/udp_port mode {bridge | nat | route} trusted-ip-addr ip-addr [health-check]
Configuring an ESI Group, Add the Health-Check Ping and ESI Servers
Use these CLI commands to configure an ESI server group, identify its associated ping health-check method, and associate a server with this group: esi group name
ArubaOS 6.5.3.x
| User Guide External Services Interface | 1076
ping profile_name server server_identity
Using the ESI Group in a Session Access Control List
Use these CLI commands to define the redirection filter for sending traffic to the ESI server.
ip access-list session policy user any svc-http redirect esi-group group direction both
Understanding Basic Regular Expression (BRE) Syntax
The ESI syslog parser supports regular expressions created using the Basic Regular Expression (BRE) syntax described in this section. BRE syntax consists of instructions—character-matching operators (described in
Table 265 ), repetition operators (described in
Table 266 ), or expression anchors (described in Table 267
)—used to defined the search or match target.
This section contains the following topics: n n n n
“Character-Matching Operators” on page 512
“Regular Expression Repetition Operators” on page 513
“Regular Expression Anchors” on page 513
“References” on page 514
Character-Matching Operators
Character-matching operators define what the search will match.
Table 265: Character-matching operators in regular expressions
.
Operator Description
Match any one character.
Sample grep .ord sample.txt
[ ]
[^]
Match any one character listed between the brackets grep [cng]ord sample.txt
Match any one character not listed between the brackets grep [^cn]ord sample.txt
grep [a-zA-Z]ord sample.txt
grep [^0-9]ord sample.txt
Result
Matches ford , lord , 2ord , etc. in the file sample.txt.
Matches only cord , nord , and gord
Matches lord , 2ord , etc., but not cord or nord
Matches aord , bord , Aord ,
Bord , etc.
Matches Aord , aord , etc., but not 2ord , etc.
Regular Expression Repetition Operators
Repetition operators are quantifiers that describe how many times to search for a specified string. Use them in conjunction with the character-matching operators in
to search for multiple characters.
1077 | External Services Interface ArubaOS 6.5.3.x | User Guide
Table 266: Regular expression repetition operators
Operator Description
?
*
+
{n}
{n,}
{n,N}
Sample
Match any character one time if it exists
Match declared element multiple times if it exists egrep “n.*rd” sample.txt
Match declared element one or more times egrep “[n]+erd” sample.txt
Match declared element exactly n times
Match declared element at least n times
Match declared element at least n times, but not more than N times egrep “?erd” sample text egrep “[a-z]{2}erd” sample.txt
egrep “.{2,}erd” sample.txt
egrep “n[e]{1,2}rd” sample.txt
Result
Matches berd , herd , etc., erd
Matches nerd , nrd , neard , etc.
Matches nerd , nnerd , etc., but not erd
Matches cherd , blerd , etc., but not nerd , erd , buzzerd , etc.
Matches cherd and buzzerd , but not nerd
Matches nerd and neerd
Regular Expression Anchors
Anchors describe where to match the pattern, and are a handy tool for searching for common string combinations. Some of the anchor examples use the vi line editor command :s , which stands for substitute .
That command uses the syntax: s/pattern_to_match/pattern_to_substitute .
Table 267: Regular expression anchors
Operator Description
^
$
Match at the beginning of a line
Match at the end of a line
\< Match at the beginning of a word
Sample s/^/blah / s/$/ blah/ s/\</blah/
Result
Inserts “blah” at the beginning of the line
Inserts “ blah” at the end of the line
Inserts “blah” at the beginning of the word
Matches blahfield , etc.
\> Match at the end of a word egrep “\<blah” sample.txt
s/\>/blah/ Inserts “blah” at the end of the word
Matches soupblah , etc.
\b
\B
Match at the beginning or end of a word
Match in the middle of a word egrep “\>blah” sample.txt
egrep “\bblah” sample.txt
egrep “\Bblah” sample.txt
Matches blahcake and countblah
Matches sublahper , etc.
References
This implementation is based, in part, on the following resources:
ArubaOS 6.5.3.x
| User Guide External Services Interface | 1078
n n n n
Lonvick, C., “The BSD syslog Protocol”, RFC 3164, August 2001
Regular expression (regex) reference: http://en.wikipedia.org/wiki/Regular_expression
Regex syntax summary: http://www.greenend.org.uk/rjk/2002/06/regexp.html
Basic regular expression (BRE) syntax: http://builder.com.com/5100-6372-1050915.html
1079 | External Services Interface ArubaOS 6.5.3.x | User Guide
Chapter 44
External User Management
This chapter introduces the ArubaOS XML API interface and briefly discusses how you can use simple API calls to perform external user management tasks. Sample scripts are listed at the end of the chapter to help you get started with using the XML API.
Topics in this chapter include: n n n n n
How the ArubaOS XML API Works on page 1080
Creating an XML Request on page 1080
Overview
ArubaOS allows you to set up customized external captive portal user management using its native XML API interface. The XML API interface allows you to create and execute user management operations on behalf of the clients or users. You can use the XML API interface to add, delete, authenticate, blacklist, query, or log out a user.
Before you Begin
n n
Enable the External Services Interface software module. This is available in the PEFNG license.
Ensure that you have connectivity between your XML API server and the controllers via HTTPS.
How the ArubaOS XML API Works
The typical interaction between your XML API server and the controller happens using an HTTPS POST command. A typical communication process using the XML API interface happens as follows:
1. An API command is issued from your server in XML format to the controller. The XML request can be composed using a language of your choice using the format described in the
command. See the
2. The XML request is sent using an HTTPS POST command. The common format of the HTTPS POST is https://<controller-ip>/auth/command.xml
. See
Creating an XML Request on page 1080
for more information.
3. The controller processes the XML API request and sends the response to the XML API server. You can use the response and take appropriate action that suits your requirement. The response from the controller is returned using predefined formats. See the
for more information.
Creating an XML Request
You can create XML request to add, delete, authenticate, blacklist, query, or logout a user. This section provides
XML request formats that you can use for each task.
ArubaOS 6.5.3.x
| User Guide External User Management | 1080
The XML API functions such as addition, deletion, authentication, blacklisting, querying, and logout have been extended to support IPv6 users in addition to IPv4 users. However, the XML API server must be configured with an
IPv4 address for communication with the controller.
Adding a User
This XML request uses the user_add command to create a new user entry in the controllers user table. If the user entry is already present in the user table, the command will modify the entry with the values defined in the XML request, with an exception of IP and MAC address. Session time-out is only applicable to captive portal users.
xml=<aruba command="user_add">
<ipaddr>IP-address_of_the_user</ipaddr>
<macaddr>MAC-address_of_the_user</macaddr>
<name>User_Name</name>
<role>Role_Name</role>
<session_timeout>Session_timeout</session_timeout>
<key>Shared_Key</key>
<authentication>MD5|SHA-1|cleartext</authentication>
<version>1.0</version>
</aruba>
The following options are mandatory when you execute the user_add command: n n n n n
IP Address
MAC Address (a valid wireless or wired client on the controller)
Key
Authentication
Version
Deleting a User
Do not use the user_delete command if the intention is to clear the association from the controller user table. If the client is dual-stack, it re-inherits the authentication state from the IPv6 address. If not dual-stack, the client reverts to the initial role.
This XML request uses the user_delete command to delete an existing user from the controllers user table.
xml=<aruba command="user_delete">
<ipaddr>IP-address_of_the_user</ipaddr>
<macaddr>MAC-address_of_the_user</macaddr>
<name>User_Name</name>
<key>Shared_Key</key>
<authentication>MD5|SHA-1|cleartext</authentication>
<version>1.0</version>
</aruba>
The following options are mandatory when you execute the user_delete command: n n n n
IP Address
Key
Authentication
Version
Passing the MAC address or username serves only to perform additional validation against the mandatory IP address. For example, if the IP address is 1.2.3.4 and the MAC address passed is 00:11:22:33:44:55 but the real MAC address is 66:77:88:99:aa:bb then the XML request will fail with response code 1, " unknown user " message.
1081 | External User Management ArubaOS 6.5.3.x | User Guide
Authenticating a User
This XML request uses the user_authenticate command to authenticate against the server group defined in the captive portal profile. This is only applicable to captive portal users.
xml=<aruba command="user_authenticate">
<ipaddr>IP-address_of_the_user</ipaddr>
<macaddr>MAC-address_of_the_user</macaddr>
<name>User_Name</name>
<password>Password_for_the_user</password>
<key>Shared_Key</key>
<authentication>MD5|SHA-1|cleartext</authentication>
<version>1.0</version>
</aruba>
The following options are mandatory when you execute the user_authenticate command: n n n n n n
IP Address
Name
Password
Key
Authentication
Version
Passing the MAC address serves only to perform additional validation against the mandatory IP address. For example, if the IP address is 1.2.3.4 and the MAC address passed is 00:11:22:33:44:55 but the real MAC address is
66:77:88:99:aa:bb then the XML request will fail with response code 1, " unknown user " message.
Blacklisting a User
This XML request uses the user_blacklist command to blacklist a user from connecting to your network. This command uses the default blacklist timeout of 3600 seconds. There is no corresponding clear command. You can use the controller CLI to clear the blacklisted clients. Refer the show ap blacklist-clients , stm removeblacklist-client , and stm purge-blacklist-clients commands in the ArubaOS CLI Reference Guide to clear the blacklisted clients.
xml=<aruba command="user_blacklist">
<ipaddr>IP-address_of_the_user</ipaddr>
<macaddr>MAC-address_of_the_user</macaddr>
<name>User_Name</name>
<key>Shared_Key</key>
<authentication>MD5|SHA-1|cleartext</authentication>
<version>1.0</version>
</aruba>
The following options are mandatory when you execute the user_blacklist command: n n n n
IP Address
Key
Authentication
Version
Passing the MAC address or username serves only to perform additional validation against the mandatory IP address. For example, if the IP address is 1.2.3.4 and the MAC address passed is 00:11:22:33:44:55 but the real MAC address is 66:77:88:99:aa:bb then the XML request will fail with response code 1, " unknown user " message.
ArubaOS 6.5.3.x
| User Guide External User Management | 1082
Querying for User Status
This XML request uses the user_query command to get the status and details of a user connected to your network. A dual-stack client can be queried by any of its IPv4 or IPv6 addresses, but only the queried IP address is displayed in the output.
xml=<aruba command="user_query">
<ipaddr>IP-address_of_the_user</ipaddr>
<macaddr>MAC-address_of_the_user</macaddr>
<name>User_Name</name>
<key>Shared_Key</key>
<authentication>MD5|SHA-1|cleartext</authentication>
<version>1.0</version>
</aruba>
The following options are mandatory when you execute the user_query command: n n n n
IP Address
Key
Authentication
Version
Passing the MAC address or username serves only to perform additional validation against the mandatory IP address. For example, if the IP address is 1.2.3.4 and the MAC address passed is 00:11:22:33:44:55 but the real MAC address is 66:77:88:99:aa:bb then the XML request will fail with response code 1, " unknown user " message.
Logging Out a User
This XML request uses the user_logout command to revert the user to the initial role. This is only applicable to captive portal users. For dual-stack clients, all user-table entries will be reverted to the initial role.
xml=<aruba command="user_logout">
<ipaddr>IP-address_of_the_user</ipaddr>
<macaddr>MAC-address_of_the_user</macaddr>
<name>User_Name</name>
<key>Shared_Key</key>
<authentication>MD5|SHA-1|cleartext</authentication>
<version>1.0</version>
</aruba> n n
The following options are mandatory when you execute the user_logout command: n n
IP Address
Key
Authentication
Version
XML Response
For every successful XML request the controller will return the processed information as an XML response.
There are two types of responses: Default response and Query response.
Default Response Format
The format of a default XML response from the controller is:
<aruba>
<status>Ok | Error</status>
<code>response_code</code>
<reason>response_message</reason>
1083 | External User Management ArubaOS 6.5.3.x | User Guide
</aruba>
In which, n n n the status specifies if the XML response succeeds or fails. If the request succeeds, the status tag will contain the Ok string. If the request fails, the status tag will contain the Error string.
the code is an integer number that represents the error in the request. This tag is populated only if there is an error in the request.
the reason is a message that contains descriptive information about the error.
Response Codes
The following response codes are returned if the XML request returns an Error string.
Table 268: XML Response Codes
Code Reason message
1
2
3 unknown user
The user specified in the XML request does not exist or is incorrect.
If the MAC address or username is specified in the query, the controller restricts the supplied IP address, i.e., the requested user
IP address together with any MAC address and username will not be found.
unknown role
The specified role in the XML request does not exist in the controller.
unknown external agent
Description
Returned by the user_ authenticate , user_delete , user_ blacklist , user_logout , and user_ query commands.
Returned by the user_add command.
4
5 authentication failed
This error string is returned due to an unknown source IP (i.e. not configured as an XML server).
Or,
In case of an user_add command, it is likely to be due to the defaultxml-api AAA profile missing from the AAA authentication wired profile.
Indicates an authentication failure during user_authenticate .
This is only applicable to captive portal users.
—
6
7 invalid command
The XML request contains a command not supported by ArubaOS
XML API interface.
invalid message authentication method
The authentication method specified in the XML request is not supported by the ArubaOS XML API interface.
invalid message digest
Returned by commands that contain the authentication method in the XML request.
This is due to a mismatch in secret between the XML server and the controller XML API profile.
If using non cleartext, this could be an error in the calculation of the hashed secret.
ArubaOS 6.5.3.x
| User Guide External User Management | 1084
Code
8
9
10
12
13
14
Reason message missing message authentication
The authentication method is not specified in the XML request.
Description
Returned by all commands that require the authentication method in the XML request.
Returned by all commands.
missing or invalid version number
The XML request does not contain the version number or the version number is incorrect.
internal error can't use vlan ip invalid ip
The XML request contains invalid IP address of the user or client.
can't use switch ip
The XML request contains the controllers IP address instead of the client IP address.
—
Indicates the supplied IP matches a
VLAN IP on the controller.
Returned by all commands that required IP address to be specified in the XML request.
Returned by all commands that required IP address to be specified in the XML request.
15
16
17 missing MAC address
The XML request does not contain the MAC address of the user or client.
unsupported command for this user socket failed or timed out waiting for operation to complete
Returned by all commands that required MAC address to be specified in the XML request.
Returned when the requested operation is invalid for the specified user.
Returned when the status of the requested operation is unavailable; usually signifies a socket communication failure or timeout.
Query Command Response Format
The response of the XML request with the user_query command contains detailed information about the status of the user or client.
The status , code and reason values are similar to the default response. The following responses are returned only if the status code returns the Ok string.
Table 269: Query Response Code
Response
Code
Description status Displays the status of the XML response.
code macaddr
Displays the code as an integer number that represents the error in the request. This tag is populated only if there is an error in the request.
Displays the MAC address of the client.
1085 | External User Management ArubaOS 6.5.3.x | User Guide
Response
Code ipaddr name role type vlan location age auth_status auth_server auth_method essid bssid phy_type mobility_state in_packets in_octets out_packets out_octets
Description
Displays the IPv4 or IPv6 address of the client.
Displays the hostname of the user or client.
Displays the current role of the authenticated client.
Displays if the client is wired or wireless .
Displays the VLAN ID of the client.
Displays the name of the AP to which the client is associated.
Displays the age of the client in the controller. The age is displayed in DD:HH:MM format
(Day:Hours:Minutes).
Displays the authentication status of the client. Available values are: authenticated or unauthenticated .
Displays the name of the authentication server used for authenticating the client. This information is available only if the client is authenticated by the controller.
Displays the authentication mechanism used to authenticate the client. This information is available only if the client is authenticated by the controller.
Displays the ESSID to which the client is associated.
Displays the BSSID of the AP to which the client is associated.
Displays the physical connection type. Available values are: a , b , g , a-HT , g-HT , and a-
VHT .
Displays the roaming state of the client. Available values are: Wired (Visitor) , Visitor ,
Wired (Away) , Away , Wired (Foreign VLAN) , Foreign VLAN , Wired (Remote) , Associated (Remote) , Wired , and Wireless .
Displays the total number of incoming packets received by the client.
Displays the incoming packets (in bytes) received by the client.
Displays the total number of outgoing packets received by the client.
Displays the outgoing packets (in bytes) received by the client.
Using the XML API Server
Follow the steps below to use the XML API:
1. Configure an XML API server.
2. Associate the XML API server to an appropriate AAA profile.
3. Configure a user role to direct non-authenticated users to the external captive portal server.
4. Configure captive portal profile and associate that to an initial role (example logon ).
5. Create an XML request with the appropriate API call.
6. Process XML response appropriately.
ArubaOS 6.5.3.x
| User Guide External User Management | 1086
The default logon role of a client or user must have captive-portal enabled.
Configuring the XML API Server
Configure an external XML API server in your AAA infrastructure. In this example, 10.11.12.13 is your server.
The XML API interface on the controller will receive requests from this server.
Define the XML API server and specify the key for verifying requests from your server:
(host) (config) #aaa xml-api server 10.11.12.13
(host) (XML API Server “10.11.12.13”) #key aruba123
Verify the XML API server configuration:
(host) #show aaa xml-api server
XML API Server List
-------------------
Name References Profile Status
----
10.11.12.13
-----------------------
0
Total:1
Associating the XML API Server to a AAA profile
After you define the XML API server profile associate it to the appropriate AAA profile. If the XML API server is not correctly configured in the appropriate profile, the controller will respond with the client not authorized error message. You can add XML API server references to the following AAA profile depending on your requirement:
For wireless users, associate the XML API server to the AAA profile of the virtual AP profile:
(host) (config) #aaa profile wirelessusers
(host) (AAA Profile "wirelessusers") #xml-api-server 10.11.12.13
(host) (AAA Profile "wirelessusers") #exit
(host) (config) #show aaa profile wirelessusers
AAA Profile "wirelessusers"
---------------------------
Parameter
---------
Initial role
MAC Authentication Profile
MAC Authentication Default Role
MAC Authentication Server Group
Value
----logon
N/A guest default
802.1X Authentication Profile N/A
802.1X Authentication Default Role guest
802.1X Authentication Server Group N/A
RADIUS Accounting Server Group N/A
XML API server
RFC 3576 server
User derivation rules
Wired to Wireless Roaming
SIP authentication role
10.11.12.13
N/A
N/A
Enabled
N/A
(host) (config) #wlan virtual-ap wireless-vap
(host) (Virtual AP profile "wireless-vap") #aaa-profile wirelessusers
(host) (AAA Profile "wirelessusers") #exit
(host) (config) #show wlan virtual-ap wireless-vap
Virtual AP profile "wireless-vap"
---------------------------------
1087 | External User Management ArubaOS 6.5.3.x | User Guide
Parameter
---------
Virtual AP enable
Allowed band
AAA Profile
Value
-----
Enabled all wirelessusers
802.11K Profile
SSID Profile
VLAN
Forward mode
Deny time range
Mobile IP
HA Discovery on-association
DoS Prevention
Station Blacklisting
Blacklist Time default default
N/A tunnel
N/A
Enabled
Disabled
Disabled
Enabled
3600 sec
Dynamic Multicast Optimization (DMO) Disabled
Dynamic Multicast Optimization (DMO) Threshold 6
Authentication Failure Blacklist Time
Multi Association
3600 sec
Disabled
Strict Compliance
VLAN Mobility
Remote-AP Operation
Drop Broadcast and Unknown Multicast
Disabled
Disabled standard
Disabled
Convert Broadcast ARP requests to unicast
Band Steering
WMM Traffic Management Profile
Enabled
Disabled
N/A
For wired users, associate the XML API server to the AAA profile of the appropriate wired profile:
(host) (config) #aaa profile wiredusers
(host) (AAA Profile "wiredusers") #xml-api-server 10.11.12.13
(host) (AAA Profile "wiredusers") #exit
(host) (config) #aaa authentication wired
(host) (Wired Authentication Profile) #profile wiredusers
(host) (Wired Authentication Profile) #exit
(host) (config) #show aaa authentication wired
Wired Authentication Profile
----------------------------
Parameter
---------
Value
-----
AAA Profile wiredusers
For unknown wired users, associate the XML API server to the default-xml-api AAA profile:
The default-xml-api AAA profile is used only to add or authenticate new users.
The following example illustrates using the default-xml-api AAA profile.
(host) (config) #aaa profile default-xml-api
(host) (AAA Profile "default-xml-api") #xml-api-server 10.11.12.13
(host) (AAA Profile "default-xml-api") #exit
(host) (config) #show aaa profile default-xml-api
AAA Profile "default-xml-api" (Predefined (changed))
----------------------------------------------------
Parameter Value
---------
Initial role
MAC Authentication Profile
----logon
N/A
ArubaOS 6.5.3.x
| User Guide External User Management | 1088
MAC Authentication Default Role
MAC Authentication Server Group guest default
802.1X Authentication Profile N/A
802.1X Authentication Default Role guest
802.1X Authentication Server Group N/A
RADIUS Accounting Server Group N/A
XML API server
RFC 3576 server
User derivation rules
Wired to Wireless Roaming
SIP authentication role
10.11.12.13
N/A
N/A
Enabled
N/A
Your controller is now ready to receive API calls from your XML API server.
Setting up the Captive Portal Profile
Set up a Captive Portal profile with a login page that will redirect users to the external Captive Portal server.
(host) (config-role) #aaa authentication captive-portal captive-portal-auth
(host) (Captive Portal Authentication Profile "captive-portal-auth") #default-role authenticated
(host) (Captive Portal Authentication Profile "captive-portal-auth") #login-page https://10.11.12.13/cgi-bin/login.pl
(host) (Captive Portal Authentication Profile "captive-portal-auth") #switch-in-redirectionurl
The login-page https://10.11.12.13/cgin-bin/login.pl
is for illustration purposes where the login.pl
is a Perl script on the external server that handles the external captive portal.
Associating the Captive Portal Profile to an Initial Role
(host) (Captive Portal Authentication Profile "captive-portal-auth") #user-role logon
(host) (config-role) #captive-portal captive-portal-auth
(host) (config-role) #session-acl captiveportal
(host) (config-role) #!
You can either create a new ACL or append specific rules to an existing ACLs. To create session ACL for the logon role do the following:
(host) (config) #ip access-list session captiveportal
(host) (config-sess-captiveportal)#user alias xCP svc-https permit
(host) (config-sess-captiveportal)#user alias xCP svc-http permit
(host) (config-sess-captiveportal) #!
(host) (config) #netdestination xCP
(host) (config-dest) #host 10.11.12.13
(host) (config-dest) #!
Creating an XML API Request
You can now create an XML request with an XML API command and send it to the controller via HTTPS POST.
The format of the URL to send the XML request is: https://<controller-ip/auth/command.xml
n n controller-ip : The IP address of the controller that will receive the XML API request command.xml
: The XML request that contains the XML API command.
The format of the XML API request is: xml=<aruba command="<XML API command>">
<options>Value</options>
...
1089 | External User Management ArubaOS 6.5.3.x | User Guide
<options>Value</options>
</aruba>
You can specify any of the following commands in the XML request:
Table 270: XML API Command
XML API Command user_add user_delete user_authenticate user_blacklist user_query user_logout
Description
This command creates a new user entry in the controllers user table. If the user entry is already present in the user table, the command will modify the entry with the values defined in the XML request. For an existing user, this command will update any value that is supplied, with an exception of
IP and MAC address. Session time-out is only applicable to captive portal users.
This command deletes an existing user from the controllers user table.
NOTE: Do not use the user_delete command if the intention is to clear the association from the controller user table. If the client is dual-stack, it re-inherits the authentication state from the IPv6 address. If not dualstack, the client reverts to the initial role.
This command authenticates against the server group defined in the captive portal profile. This is only applicable to captive portal users.
This command blacklists a user from connecting to your network. This command uses the default blacklist timeout of 3600 seconds. There is no corresponding clear command. You can use the controller CLI to clear the blacklisted clients. Refer the show ap blacklist-clients , stm removeblacklist-client , and stm purge-blacklist-clients commands in the
ArubaOS CLI Reference Guide to clear the blacklisted clients.
This command fetches the status and details of a user connected to your network. A dual-stack client can be queried by any of its IPv4 or IPv6 addresses, but only the queried IP address is displayed in the output.
This command reverts the user to the initial role. This is only applicable to captive portal users. For dual-stack clients, all user-table entries will be reverted to the initial role.
Each XML API command requires certain mandatory options to successfully execute the task. The list of all available options are:
Table 271: XML API Command Options
Options ipaddr macaddr user role password
Description
IP address of the user in IPv4 or IPv6 format.
MAC address of the user in aa:bb:cc:dd:ee:ff format.
Name of the user.
The role to apply to a newly created user, or change of role for an existing user. This option applies to user_add and user_delete commands only.
The password of the user for authentication.
Range / Defaults
—
Enter MAC address with colon.
64 character string
64 character string
—
ArubaOS 6.5.3.x
| User Guide External User Management | 1090
Options session_timeout authentication key version
Description
Session time-out in seconds. User will be disconnected after this time.
Authentication method used to authenticate the message and the sender. You can use any of MD5,
SHA-1 or clear text methods of authentication. This option is ignored if shared secret is not configured.
It is, however, mandatory if it is configured.
This is the encoded SHA1/MD5 hash of shared secret or plaintext shared secret.
This option is ignored if shared secret is not configured on the switch.
The actual MD5/SHA-1 hash is 16/20 bytes and consists of binary data. It must be encoded as an
ASCII based HEX string before sending. It must be present when the controller is configured with an xml-api key for the server. Encoded hash length is
32/40 bytes for MD5/SHA-1.
The version of the XML API interface available in the controller. This field is mandatory in all XML API requests.
Range / Defaults
—
—
Current version 1.0
Monitoring External Captive Portal Usage Statistics
To check the external captive portal authentication statistics use the show aaa xml-api statistics command.
This command displays the number of times an authentication command was executed per client. The command also displays the number of times an authentication event occurred and the number of new authentication events that occurred since the last status check.
(host) # show aaa xml-api statistics
Sample Scripts
You can download the sample scripts from support.arubanetworks.com
. Before downloading the scripts, you must read the following disclaimer.
The sample scripts are examples and provided for illustration purposes only. If you plan to use this script in your environment, ensure that the script meets your IT guidelines. By running this script, you acknowledge that Aruba, a
Hewlett Packard Enterprise company is in no way liable for any loss, damage, problems arising from running this script.
The following scripts are available for download:
Python 2.7 Script n
ArubaXMLDemo.py
: This is a Python 2.7 script. This script demonstrates the basic functionality of the XML
API. Using this script, you can send XML requests to add, delete, authenticate, blacklist, query, or log out a user.
Bourne Shell Scripts n n xml_user_add.sh
: This script adds a user using the user_add command.
xml_user_del_or_logout.sh
: The user_delete part of the script deletes an existing user from the controller user table. The user_logout part of the script reverts an existing user to the initial role in the AAA profile.
1091 | External User Management ArubaOS 6.5.3.x | User Guide
n xml_user_query.sh
: This script fetches the status and details of a user connected in the network using the user_query command.
The Bourne Shell scripts work on most Unix, Linux, and Mac operating systems. To run on Windows, you can install
Cygwin.
All scripts require cURL to be installed on the XML API server. cURL is an open source command line tool and library for transferring data with URL syntax. You can download cURL from http://curl.haxx.se/download.html
.
XML API using Python 2.7
The information covered in the following section is based on running the ArubaXMLDemo.py
script on a
Windows 8.1 64-bit and Python 2.7.
Understanding Request and Response
The controller processes the XML API request and sends the response to the XML API server. The XML response contains the status of the request and a code in case of an error.
Request format: <script_name> <controller-ip> <secret_key> <command> [options]
Understanding XML API Request Parameters
The
lists all parameters that you can use in a request.
Table 272: XML API Request Parameters and Descriptions
Parameter Description script_name controller-ip secret_key
The name of the script executable.
The IP address of the controller that will receive the XML requests.
The password used to validate the authentication request from your authentication server. See
Configuring the XML API Server on page 1087
for more information.
ArubaOS 6.5.3.x
| User Guide External User Management | 1092
Parameter command
Options
Description
The XML API command sent to the controller. You can send one of the following commands per request: n use_add : Creates a new user entry in the controllers user table. If the user entry is already present in the user table, the command will modify the entry with the values defined in the XML request. For an existing user, this command will update any value that is supplied, with an exception of IP and MAC address. Session time-out is only applicable to captive portal users.
n n user_delete : Deletes an existing user from the controllers user table.
NOTE: Do not use the user_delete command if the intention is to clear the association from the controller user table. If the client is dual-stack, it re-inherits the authentication state from the IPv6 address. If not dual-stack, the client reverts to the initial role.
user_authenticate : Authenticates against the server group defined in the captive portal profile. This is only applicable to captive portal users.
n user_blacklist : Blacklists a user from connecting to your network. This command uses the default blacklist timeout of 3600 seconds. There is no corresponding clear command. You can use the controller CLI to clear the blacklisted clients. Refer the show ap blacklist-clients , stm remove-blacklist-client , and stm purge-blacklistclients commands in the ArubaOS CLI Reference Guide to clear the blacklisted clients.
n n user_query : Fetches the status and details of a user connected to your network. A dual-stack client can be queried by any of its IPv4 or IPv6 addresses, but only the queried IP address is displayed in the output.
user_logout : Reverts the user to the initial role. This is only applicable to captive portal users. For dual-stack clients, all user-table entries will be reverted to the initial role.
n n n n n n n n n
-i <ip_addr> : Specify the IP address of the user in IPv4 or IPv6 format.
-m <mac_addr> : Specify the MAC address of the user in aa:bb:cc:dd:ee:ff format.
-n <name> : Specify the name of the user.
-p <password> : Specify the password of the user for authentication.
-r role : Specify the role to apply to a newly created user, or change of role for an existing user. This option applies to user_add and user_delete commands only.
-t timeout : Specifies the session time-out in seconds. User will be disconnected after this time.
-v version : Specifies the version of the XML API interface available in the controller.
This field is mandatory is all requests. Default version is 1.0.
-a method : Specifies the encryption method to send the secret key. You can specify
MD5 or SHA-1 or cleartext as the encryption method. By default, cleartext method is used to send the key.
-s sessid : Specifies the active session ID.
Understanding an XML API Response
The response message from the controller is sent in an XML format. The default format of the response is:
[Message header]
Displays the request parameters and other standard header details.
...
...
...
<response>
<status>Status Message</status>
<code>Code in case of an error</code>
</response>
The following section describes few of the XML API requests and responses from the controller.
Adding a User
This XML request uses the user_add command to create a new user entry in the controllers user table.
C:\Python27>python ArubaXMLDemo.py --switch-ip=192.0.2.1 --secret=aruba123 --command=user_add
--ip=192.0.2.2 --mac=a4:e:60:c3:10:59 --role=logon
1093 | External User Management ArubaOS 6.5.3.x | User Guide
The command sends the following information in the XML request to the controller: n n n n n n
--switch-ip : IP address of the controller
--secret : Shared secret key (sent as plain text)
--command : XML API command
--ip : IP address of the user
--mac : MAC address of the user
--role : User role
Controller Response
The controller processes using an XML format and sends the following response to the XML API server.
Warning: The specified mac address *must* match the user specified by --ip or the command will fail.
Prepared XML buf
--------------------------------xml=<aruba command="user_add">
<ipaddr>192.0.2.2</ipaddr>
<macaddr>a4:5e:60:c3:10:59</macaddr>
<role>logon</role>
<authentication>cleartext</authentication>
<key>aruba123</key>
<version>1.0</version>
</aruba>
---------------------------------
Sending XML request to https://192.0.2.1/auth/command.xml
Controller response status: 200
Response XML
-----------------------------------
<aruba>
<status>Ok</status>
<code>0</code>
</aruba>
-----------------------------------
Controller CLI
You can view the updated details of the user in the controller CLI.
(host) #show user-table
Users
-----
IP MAC Name Role Age(d:h:m) Auth VPN link AP name Roaming
Essid/Bssid/Phy Profile Forward mode Type Host Name
-------------------------------------------------------- -----
-----------------------------------------
192.0.2.2 a4:5e:60:c3:10:59 logon 00:00:00
User Entries: 1/1
Querying a User
This XML request uses the user_query command to get the status and details of a user connected to your network.
C:\Python27>python ArubaXMLDemo.py --switch-ip=192.0.2.1 --secret=aruba123 --command=user_ query --ip=192.0.2.2
The command sends the following information in the XML request to the controller: n
--switch-ip : IP address of the controller
ArubaOS 6.5.3.x
| User Guide External User Management | 1094
n n n
--secret : Shared secret key (sent as plain text)
--command : XML API command
--ip : IP address of the user
Controller Response
The controller processes using an XML format and sends the following response to the XML API server.
Prepared XML buf
--------------------------------xml=<aruba command="user_query">
<ipaddr>192.0.2.2</ipaddr>
<authentication>cleartext</authentication>
<key>aruba123</key>
<version>1.0</version>
</aruba>
---------------------------------
Sending XML request to https://192.0.2.1/auth/command.xml
Controller response status: 200
Response XML
-----------------------------------
<aruba>
<status>Ok</status>
<code>0</code>
<macaddr>a4:5e:60:c3:10:59</macaddr>
<ipaddr>192.0.2.2</ipaddr>
<name>John</name>
<role>authenticated</role>
<type>Wireless</type>
<vlan>1034</vlan>
<location>ap225-sales</location>
<age>00:03:51</age>
<auth_status>Authenticated</auth_status>
<auth_server>clearpass-hq1</auth_server>
<auth_method>802.1X</auth_method>
<essid>ethersphere-wpa2</essid>
<bssid>9c:1c:12:92:2e:f1</bssid>
<phy_type>a-VHT-80</phy_type>
<mobility_state>Wireless</mobility_state>
<in_packets>93400</in_packets>
<in_octets>24947332</in_octets>
<out_packets>89042</out_packets>
<out_octets>79397284</out_octets>
</aruba>
Controller CLI
The output of the show user command displays the client information.
(host) #show user
Users
-----
IP MAC
---------------------
192.0.2.2
Name Role
--------a4:5e:60:c3:10:59 John
Age(d:h:m)
---------authenticate 00:03:51
Auth
----
Authenticated
VPN link
--------
Profile Forward mode
------------------
AP name
------ap225-sales
Type Host Name
------------
Roaming Essid/Bssid/Phy
----------------------
Wireless ethersphere-wpa2/9c:1c:12:92:2e:f1/a-VHT-80
1095 | External User Management ArubaOS 6.5.3.x | User Guide
User Entries: 1/1
Logging Out a User
This XML request uses the user_logout command to revert the user to the initial role. This is only applicable to captive portal users.
C:\Python27>python ArubaXMLDemo.py --switch-ip=192.0.2.1 --secret=aruba123 --command=user_ logout --ip=192.0.2.2
The command sends the following information in the XML request to the controller: n n n n
--switch-ip : IP address of the controller
--secret : Shared secret key (sent as plain text)
--command : XML API command
--ip : IP address of the user
Controller Response
The controller processes using an XML format and sends the following response to the XML API server.
Prepared XML buf
--------------------------------xml=<aruba command="user_logout">
<ipaddr>192.0.2.2</ipaddr>
<authentication>cleartext</authentication>
<key>aruba123</key>
<version>1.0</version>
</aruba>
---------------------------------
Sending XML request to https://192.0.2.1/auth/command.xml
Controller response status: 200
Response XML
-----------------------------------
<aruba>
<status>Ok</status>
<code>0</code>
</aruba>
Controller CLI
The output of the show user command displays the client information.
(host) #show user
Users
-----
IP MAC
---------------------
192.0.2.2
Name a4:5e:60:c3:10:59 John
Role
--------initial
AP name
------ap225-sales
Roaming
--------
Wireless
Essid/Bssid/Phy
---------------
Age(d:h:m)
----------
00:00:06
Auth
----
Unauthenticated ethersphere-wpa2/9c:1c:12:92:2e:f1/a-VHT-80
Profile
-------
VPN link
--------
Forward mode
------------
Type Host Name
------------
User Entries: 1/1
ArubaOS 6.5.3.x
| User Guide External User Management | 1096
Chapter 45
Behavior and Defaults
Topics in this chapter include: n n n n
Understanding Mode Support on page 1097
Understanding Basic System Defaults on page 1099
Understanding Default Management User Roles on page 1107
Understanding Default Open Ports on page 1110
Understanding Mode Support
Most ArubaOS features are supported in all forwarding modes. However, there are a some features that are not supported in one or more forwarding modes. Campus APs do not support split-tunnel forwarding mode and the decrypt-tunnel forwarding mode does not support TKIP Counter measure management on campus
APs or remote APs.
describes the features that are not supported in each forwarding mode.
ArubaOS 6.5.3.x
| User Guide Behavior and Defaults | 1097
Table 273: Features not Supported in Each Forwarding Mode
Forwarding Mode
Split Tunnel Mode on Remote APs
Feature Not Supported
AirGroup
AppRF
Bandwidth based CAC
Broadcast-filter
DHCP Fingerprinting
Dynamic Multicast Optimization
IGMP Proxy Mobility
Layer-2 Mobility
Layer-3 Mobility
Mobile IP
Named VLAN
Station blacklist by ACL action
TKIP countermeasure management
Video over Mesh
VLAN pooling
Voice over Mesh
WebCC
1098 | Behavior and Defaults ArubaOS 6.5.3.x | User Guide
Forwarding Mode
Bridge Mode on Campus APs or Remote APs
Feature Not Supported
AirGroup
AppRF
Automatic Voice Flow Classification
Bandwidth based CAC
Broadcast filter
Captive Portal
DHCP enforcement
DHCP fingerprint
Dynamic Multicast Optimization
Firewall – Alcatel NOE Support
Firewall – SIP / SCCP / RTP / RTSP Voice Support
H.323 ALG
IGMP Proxy Mobility
Layer 3 Mobility
Lync SDN API
Management: Voice client statistics
Management: Voice client troubleshooting
Management: Voice-specific views
Mobile IP
Named VLAN
NOE ALG
Power save: Drop wireless multicast traffic
Power save: Proxy ARP (global)
Power save: Proxy ARP (per-SSID)
Power save: Wireless battery boost
RADIUS CoA
Rate Limiting for broadcast / multicast
SCCP ALG
SIP ALG
SIP: CAC enforcement enhancements
SIP: Delay measurement
SIP: Phone number awareness
SIP: R-Value computation
SIP: SIP authentication tracking
Station blacklist
Station blacklist by an ACL action
SVP ALG
TKIP countermeasure management
Video over Mesh
Vocera ALG
Voice over Mesh
Voice protocol monitoring / reporting
WebCC
XML-API
Understanding Basic System Defaults
The default administrator user name is admin , and the default password is also admin . The ArubaOS software includes several predefined network services, firewall policies, and roles.
Network Services
lists the predefined network services and their protocols and ports.
ArubaOS 6.5.3.x
| User Guide Behavior and Defaults | 1099
Table 274: Predefined Network Services
Name Protocol Port(s) svc-pop3 svc-adp svc-noe svc-noe-oxo svc-dns svc-msrpc-tcp svc-rtsp svc-http svc-vocera svc-nterm svc-sip-udp svc-papi svc-ftp svc-natt svc-svp svc-dhcp svc-snmp-trap svc-smb-tcp svc-https svc-ike svc-l2tp svc-syslog svc-pptp svc-telnet svc-sccp svc-tftp svc-sip-tcp svc-kerberos tcp udp
119 udp tcp udp udp udp tcp tcp tcp tcp udp udp udp tcp udp tcp udp udp udp tcp tcp udp udp tcp tcp udp
110
8200
32512
5000
53
135 139
554
80
5002
1026 1028
5060
8211
21
4500
0
2000
69
5060
88
1701
514
1723
23
67 68
162
445
443
500
1100 | Behavior and Defaults ArubaOS 6.5.3.x | User Guide
Name svc-gre svc-smtp svc-smb-udp svc-esp svc-bootp svc-snmp svc-icmp svc-ntp svc-msrpc-udp svc-ssh svc-h323-tcp svc-h323-udp svc-http-proxy1 svc-http-proxy2 svc-http-proxy3 svc-sips svc-v6-dhcp svc-v6-icmp any
Protocol tcp tcp udp tcp udp icmp udp udp gre tcp udp esp udp tcp tcp tcp udp icmp any
Policies
The following are predefined policies.
Table 275: Predefined Policies
Predefined Policy ip access-list session allowall any any any permit
Port(s)
0
0
8080
8888
5061
546 547
0
25
445
0
67 69
161
0
123
135 139
22
1720
1718 1719
3128
Description
An "allow all" firewall rule that permits all traffic.
ArubaOS 6.5.3.x
| User Guide Behavior and Defaults | 1101
Predefined Policy ip access-list session control user any udp 68 deny
any any svc-icmp permit
any any svc-dns permit
any any svc-papi permit
any any svc-cfgm-tcp permit
any any svc-adp permit
any any svc-tftp permit
any any svc-dhcp permit
any any svc-natt permit
Description
Controls traffic - Apply to untrusted wired ports in order to allow Aruba APs to boot up.
NOTE: In most cases wired ports should be made
"trusted" when attached to an internal network.
ip access-list session captiveportal user alias mswitch svc-https dst-nat 8081 user any svc-http dst-nat 8080 user any svc-https dst-nat 8081 user any svc-http-proxy1 dst-nat 8088 user any svc-http-proxy2 dst-nat 8088 user any svc-http-proxy3 dst-nat 8088
Enables Captive Portal authentication.
1. Any HTTPS traffic destined for the controller will be
NATed to port 8081, where the captive portal server will answer.
2. All HTTP traffic to any destination will be NATed to the controller on port 8080, where an HTTP redirect will be issued.
3. All HTTPS traffic to any destination will be NATed to the controller on port 8081, where an HTTP redirect will be issued.
4. All HTTP proxy traffic will be NATed to the controller on port 8088.
NOTE: In order for captive portal to work properly, DNS must also be permitted. This is normally done in the
"logon-control" firewall rule.
ip access-list session cplogout user alias mswitch svc-https dst-nat 8081 ip access-list session vpnlogon any any svc-ike permit any any svc-esp permit any any svc-l2tp permit any any svc-pptp permit any any svc-gre permit
Used to enable the captive portal "logout" window. If the user attempts to connect to the controller on the standard HTTPS port (443) the client will be NATed to port
8081, where the captive portal server will answer. If this rule is not present, a wireless client may be able to access the controller's administrative interface.
This policy permits VPN sessions to be established to any destination. IPsec (IKE, ESP, and L2TP) and PPTP (PPTP and GRE) are supported.
ip access-list session ap-acl any any udp 5000 any any udp 5555 any any svc-gre permit any any svc-syslog permit any user svc-snmp permit user any svc-snmp-trap permit user any svc-ntp permit
This is a policy for internal use and should not be modified. It permits APs to boot up and communicate with the controller.
1102 | Behavior and Defaults ArubaOS 6.5.3.x | User Guide
Predefined Policy ip access-list session validuser any any any permit ip access-list session vocera-acl any any svc-vocera permit queue high ip access-list session icmp-acl any any svc-icmp permit ip access-list session sip-acl any any svc-sip-udp permit queue high any any svc-sip-tcp permit queue high ip access-list session https-acl any any svc-https permit ip access-list session dns-acl any any svc-dns permit ip access-list session logon-control user any udp 68 deny any any svc-icmp permit any any svc-dns permit any any svc-dhcp permit any any svc-natt permit ip access-list session srcnat user any any src-nat ip access-list session skinny-acl any any svc-sccp permit queue high ip access-list session tftp-acl any any svc-tftp permit ip access-list session guest ip access-list session dhcp-acl any any svc-dhcp permit ip access-list session http-acl any any svc-http permit ip access-list session svp-acl any any svc-svp permit queue high user host 224.0.1.116 any permit
Description
This firewall rule controls which users will be added to the user-table of the controller through untrusted interfaces.
Only IP addresses permitted by this ACL will be admitted to the system for further processing. If a client device attempts to use an IP address that is denied by this rule, the client device will be ignored by the controller and given no network access. You can use this rule to restrict foreign IP addresses from being added to the user-table.
This policy should not be applied to any user role, it is an internal system policy.
Use for Vocera VoIP devices to automatically permit and prioritize Vocera traffic.
Permits all ICMP traffic.
Use for SIP VoIP devices to automatically permit and prioritize all SIP control and data traffic.
Permits all HTTPS traffic.
Permits all DNS traffic.
The default pre-authentication role that should be used by all wireless clients. Prohibits the client from acting as a
DHCP server. Permits all ICMP, DNS, and DHCP. Also permits IPsec NAT-T (UDP 4500). Remove NAT-T if not needed.
This policy can be used to source-NAT all traffic. Because no NAT pool is specified, traffic that matches this policy will be source NATed to the IP address of the controller.
Use for Cisco Skinny VoIP devices to automatically permit and prioritize VoIP traffic.
Permits all TFTP traffic.
This policy is not used.
Permits all DHCP traffic. If DHCP is not allowed, clients will not be able to request or renew IP addresses.
Permits all HTTP traffic.
Use for Spectralink VoIP devices to automatically permit and prioritize Spectralink Voice Protocol (SVP).
ArubaOS 6.5.3.x
| User Guide Behavior and Defaults | 1103
Predefined Policy ip access-list session noe-acl any any svc-noe permit queue high ip access-list session h323-acl any any svc-h323-tcp permit queue high any any svc-h323-udp permit queue high ipv6 access-list session v6-control user any udp 68 deny any any svc-v6-icmp permit any any svc-v6-dhcp permit any any svc-dns permit any any svc-tftp permit ipv6 access-list session v6-icmp-acl any any svc-v6-icmp permit ipv6 access-list session v6-https-acl any any svc-https permit ipv6 access-list session v6-dhcp-acl any any svc-v6-dhcp permit ipv6 access-list session v6-dns-acl any any svc-dns permit ipv6 access-list session v6-allowall any any any permit ipv6 access-list session v6-http-acl any any svc-http permit ipv6 access-list session v6-tftp-acl any any svc-tftp permit ipv6 access-list session v6-logon-control user any udp 68 deny any any svc-v6-icmp permit any any svc-v6-dhcp permit any any svc-dns permit
Description
Use for Alcatel NOE VoIP devices to automatically permit and prioritize NOE traffic.
Use for H.323 VoIP devices to automatically permit and prioritize H.323 traffic.
Provides equivalent functionality to the "control" policy, but for IPv6 clients.
Permits all ICMPv6 traffic.
Permits all IPv6 HTTPS traffic.
Permits all IPv6 DHCP traffic.
Permits all IPv6 DNS traffic.
Permits all IPv6 traffic.
Permits all IPv6 HTTP traffic.
Permits all IPv6 TFTP traffic.
Provides equivalent functionality to the "logon-control" policy, but for IPv6 clients.
Validuser and Logon-control ACLs
Default firewall rules for both the validuser and logon-control ACLs prevent malicious users from ip spoofing source addresses the default firewall rule in the validuser ACL causes the packet to be dropped.
A client with the correct source address can send traffic to the below networks as a destination IP address. To deny traffic, the default firewall rule added to logon-control ACL denies traffic to the reserved addresses from user with the logon role.
The following networks can be blocked by the default firewall rules in both the validuser and logon-control
ACLs: n n
Network packets where the source address of the network packet is defined as being on a broadcast network (source address == 255.255.255.255)
Network packets where the source address of the network packet is defined as being on a multicast network (source address = 224.0.0.0 – 239.255.255.255)
1104 | Behavior and Defaults ArubaOS 6.5.3.x | User Guide
n n n n
Network packets where the source address of the network packet is defined as being a loopback address
(127.0.0.1 through 127.255.255.254)
Network packets where the source or destination address of the network packet is a link-local address
(169.254.0.0/16)
Network packets where the source or destination address of the network packet is defined as being an address “reserved for future use” as specified in RFC 5735 for IPv4; (240.0.0.0/4)
Network packets where the source or destination address of the network packet is defined as an
“unspecified address”(::/128) or an address “reserved for future definition and use”(addresses other than
2000::/3) as specified in RFC 3513 for IPv6. The IPv6 “an unspecified address”(::/128) is currently being checked in datapath and the packet is dropped. This is the default behavior and you can view the logs by enabling firewall enable-per-packet-logging configuration.
Roles
The following are predefined roles.
If you upgrade from a previous ArubaOS release, your existing configuration may have additional or different predefined roles. The information in this section only describes the predefined roles for this release.
Table 276: Predefined Roles
Predefined Role system-role ap-role
session-acl control
session-acl ap-acl system-role stateful-dot1x system-role sys-ap-role user-role authenticated
session-acl allowall
ipv6 session-acl v6-allowall user-role cpbase user-role default-iap-userrole user-role default-via-role user-role default-vpn-role
session-acl allowall
ipv6 session-acl v6-allowall user-role denyall
Description
This is an internal role and should not be edited.
Can This Role be
Deleted? (Yes/No)
No
This is an internal role used for Stateful 802.1X. It should not be edited.
This is a limited role applied to Aruba APs to allow the AP to boot up and terminate on the controller.
This is a default role that can be used for authenticated users. It permits all IPv4 and IPv6 traffic for users who are part of this role.
No
No
No
This is a role for cpbase.
Yes
This is a default user role for IAPs. This role is applied to GRE tunnel between IAP and controller, thus also applied to all CL2 users, which are created in the controller.
No
No This is a default user role for VIA users.It is referenced as default in the default VIA
Authentication profile.
This is the default role used for VPN-connected clients. It is referenced in the default "aaa authentication vpn" profile.
No
This role blocks all traffic to and from the user.
Yes
ArubaOS 6.5.3.x
| User Guide Behavior and Defaults | 1105
Predefined Role user-role guest
session-acl http-acl
session-acl https-acl
session-acl dhcp-acl
session-acl icmp-acl
session-acl dns-acl
ipv6 session-acl v6-http-acl
ipv6 session-acl v6-https-acl
ipv6 session-acl v6-dhcp-acl
ipv6 session-acl v6-icmp-acl
ipv6 session-acl v6-dns-acl user-role guest-logon captive-portal default session-acl logon-control session-acl captiveportal user-role <ssid>-guest-logon captive-portal default session-acl logon-control session-acl captiveportal user-role logon session-acl logon-control session-acl captiveportal session-acl vpnlogon
ipv6 session-acl v6-logoncontrol user-role <ssid>-logon session-acl control session-acl captiveportal session-acl vpnlogon
Description
Can This Role be
Deleted? (Yes/No)
This is a default role for guest users. It permits only HTTP, HTTPS, DHCP, ICMP, and DNS for the guest user. To increase security, a "deny" rule for internal network destinations could be added at the beginning.
No
This role is used as the pre-authentication role for guest SSIDs. It allows control traffic such as
DNS, DHCP, and ICMP, and also enables captive portal.
No
This role is only generated when creating a new
WLAN using the WLAN Wizard. The WLAN Wizard creates this role when captive portal is enabled.
This is the initial role that a guest will be placed in prior to captive portal authentication. By using a different guest logon role for each SSID, it is possible to enable multiple captive portal profiles with different customization.
Yes
This is a user role that is normally applied to a user prior to authentication. This applies to wired users and non-802.1X wireless users.
The role allows certain control protocols such as
DNS, DHCP, and ICMP, and also enables captive portal and VPN termination/pass through. The logon role should be edited to provide only the required services to a pre-authenticated user.
For example, VPN pass through should be disabled if it is not needed.
No
This role is only generated when creating a new
WLAN using the WLAN Wizard. The WLAN Wizard creates this role when captive portal is enabled and a PEFNG license is installed. This is the initial role that a client will be placed in prior to captive portal authentication. By using a different logon role for each SSID, it is possible to enable multiple captive portal profiles with different customization.
Yes
1106 | Behavior and Defaults ArubaOS 6.5.3.x | User Guide
Predefined Role user-role <ssid>captiveportal-profile
Description
Can This Role be
Deleted? (Yes/No)
When utilizing the WLAN Wizard and you do not have a PEF NG installed and you are configuring an Internal or Guest WLAN with captive portal enabled, the controller creates an implicit user role with the same name as the captive portal profile, <ssid>-captiveportal-profile.
This implicit user role allows only DNS and DHCP traffic between the client and network and directs all HTTP or HTTPS requests to the captive portal.
You cannot directly modify the implicit user role or its rules. Upon authentication, captive portal clients are allowed full access to their assigned
VLAN. Once the WLAN configuration is pushed to the controller, the WLAN wizard will associate the new role with the initial user role that you specify in the AAA profile. This role will not be visible to the user in the WLAN wizard.
This role can be applied to voice devices in order to automatically permit and prioritize all VoIP protocols.
Yes
Yes user-role voice
session-acl sip-acl
session-acl noe-acl
session-acl svp-acl
session-acl vocera-acl
session-acl skinny-acl
session-acl h323-acl
session-acl dhcp-acl
session-acl tftp-acl
session-acl dns-acl
session-acl icmp-acl
Understanding Default Management User Roles
The ArubaOS software includes predefined management user roles.
If you upgrade from a previous ArubaOS release, your existing configuration may have different management roles.
The information in this section only describes the predefined management roles for this release.
Table 277: Predefined Management Roles
Predefined Role root
Permissions
This role permits access to all management functions (commands and operations) on the controller.
read-only This role permits access to CLI show commands or WebUI monitoring pages only.
guest-provisioning This role permits access to configuring guest users in the controller’s internal database only. This user only has access via the WebUI to create guest accounts; there is no CLI access.
Guest-provisioning tasks include creating or generating the user name and password for a guest account as well as configuring when the account expires.
ArubaOS 6.5.3.x
| User Guide Behavior and Defaults | 1107
Predefined Role location-api-mgmt
Permissions
This role permits access to location API information and the CLI; however, you cannot use any CLI commands. This role does not permit access to the WebUI.
Using a third-party location appliance, you can gather information about the location of 802.11 stations.
To log in to the controller using a third-party location appliance, enter: http[s]://<ipaddress>[:port]/screens/wms/wms.login.
You are prompted to enter your username and password (for example, the username and password associated with the location API management role). Once authenticated, you can use an API call to request location information from the controller, for example: http[s]://<ipaddress>[:port]/screens/wms/wms.cgi?opcode=wlm-getspot&campus-name=<campus id>&building-name<building id>&mac=<client1>,<client2>....
network-operations
1108 | Behavior and Defaults ArubaOS 6.5.3.x | User Guide
Predefined Role network-operations
(continued)
Permissions
Monitoring > Network > All Access PointsMonitoring
> Network > All Wired Access Points
You can view the reports created by the following CLI commands: n DB:opcode=monitor-summary n n
DB:opcode=cr-load
DB:opcode=wlm-search&class=probes&start n n
DB:opcode=wlm-search&class=amii
DB:opcode=monitor-get-all-gps&status=any n show ap-group n show vlan status
Monitoring > Controller > Controller Summary
You can view the reports created by the following CLI commands: n show switches n show switches summary
Monitoring > Controller > Air Monitors
You can view the reports created by the following CLI commands: n show wlan-ap start *
Monitoring > Controller > Clients
You can view the reports created by the following CLI commands: n show ip mobile host n n n n n n n n show ip mobile trail {<ipaddr> | <macaddr>}
<span class="CLI">show ap essid</span> show esi servers show esi ping show esi parser stats show private port status * show vlan show port stats n n n show spanning-tree interface fastethernet
<slot>/<module>/<port> show interface fastethernet <slot>/<module>/<port> counters clear counters fastethernet <slot>/<module>/<port> n show snmp trap-queue <page>
Monitoring > Controller > Clients > Packet CaptureMonitoring
> Controller > Clients > LocateMonitoring
> Controller > Clients > Debug
You can view the reports created by the following CLI commands: n aaa user debug mac
Monitoring > Controller > Clients > Disconnect
You can view the reports created by the following CLI commands: n stm kick-off-sta <macaddr> n aaa user logout <ipaddr>
ArubaOS 6.5.3.x
| User Guide Behavior and Defaults | 1109
Predefined Role network-operations
(continued) standard
Permissions
Monitoring > Controller > Clients > Blacklist
You can view the reports created by the following CLI commands: n stm add-blacklist-client <macaddr> n aaa user delete {<ipaddr> | all | mac <macaddr> | name
<username> | role <role>}
Monitoring > Controller > Blacklist Clients
You can view the reports created by the following CLI commands: n stm remove-blacklist-client <macaddr>
Monitoring > Controller > External Services Interface
You can view the reports created by the following CLI commands: n show esi groups n n show esi servers show esi ping n show esi parser stats
Monitoring > Controller > Ports
You can view the reports created by the following CLI commands: n show model-switch-internal * n n show slots show private port status * n show vlan
Monitoring > Controller > Inventory
You can view the reports created by the following CLI commands: n show keys
Monitoring > WLAN
You can view the reports created by the following CLI commands: n DB:opcode=get-permissions n n n show switches summary
Monitoring > Voice
You can view the reports created by the following CLI commands: n show ap association voip-only n show ap active voip-only n n show voice call-counters show voice client status n
DB:opcode=cr-load show switches n n n show voice call-quality show voice call-density show voice call-cdrs show voice call-perf
This role has root privileges but cannot make changes to the management users.
The purpose of creating this new role is to prevent changes to the local account from externally authenticated management user.
Understanding Default Open Ports
By default, Aruba controllers and access points treat ports as untrusted. However, certain ports are open by default only on the trusted side of the network. These open ports are listed in
1110 | Behavior and Defaults ArubaOS 6.5.3.x | User Guide
Table 278: Default (Trusted) Open Ports
Port
Number
17
21
22
23
53
67
68
69
80
123
161
443
500
514
1144
1701
Protocol
TCP
TCP
TCP
TCP
UDP
UDP
UDP
UDP
TCP
UDP
UDP
TCP
UDP
UDP
RTLS
UDP
Where Used controller
Description
This is used for certain types of VPN clients that accept a banner (QOTD). During normal operation, this port will only accept a connection and immediately close it.
controller controller
AP and controller controller
AP (and controller if
DHCP server is configured)
AP (and controller if
DHCP server is configured) controller
AP and controller controller
AP and controller controller
SSH
Telnet is disabled by default but the port is still open.
Internal domain.
DHCP server.
DHCP client.
TFTP
Used for remote packet capture where the capture is saved on the access point. Provides access to the WebUI on the controller.
NTP
SNMP. Disabled by default.
controller controller
Access points controller
Used internally for captive portal authentication (HTTPS) and is exposed to wireless users. A default self-signed certificate is installed in the controller. Users in a production environment are urged to install a certificate from a well known CA such as Verisign. Self-signed certs are open to man-in-the-middle attacks and should only be used for testing.
Required for VIA : During the initializing phase, VIA uses
HTTPS connections to perform trusted network and captive portal checks against the controller. It is mandatory that you enable port 443 on your network to allow VIA to perform these checks.
ISAKMP
Syslog
Open only when the RTLS feature is enabled
L2TP
ArubaOS 6.5.3.x
| User Guide Behavior and Defaults | 1111
Port
Number
1723
2300
Protocol
TCP
TCP
3306
4343, 443
TCP
TCP
4500
8080
8081
8082
8083
8088
8200
8211
8888
UDP
TCP
TCP
TCP
TCP
TCP
UDP
UDP
TCP
Where Used controller controller controller controller controller controller controller controller controller controller controller controller controller
Description
PPTP
Internal terminal server opened by telnet soe command.
Remote wired MAC lookup.
HTTPS.Both port 4343 and 443 are supported. If port
4343 is used it redirects to port 443. If port 443 is used it continues to connect using this port. A default self-signed certificate is installed in the controller. Users in a production environment are urged to install a certificate from a well known CA such as Verisign. Self-signed certs are open to man-in-the-middle attacks and should only be used for testing sae-urn
Required for VIA : During the initializing phase, VIA uses
HTTPS connections to perform trusted network and captive portal checks against the controller. It is mandatory that you enable port 4500 on your network to allow VIA to perform these checks.
Used internally for captive portal authentication (HTTPproxy). This port is not exposed to wireless users.
Used internally for captive portal authentication (HTTPS).
Not exposed to wireless users. A default self-signed certificate is installed in the controller. Users in a production environment are urged to install a certificate from a well known CA such as Verisign. Self-signed certs are open to man-in-the-middle attacks and should only be used for testing.
Used internally for single sign-on authentication (HTTP).
Not exposed to wireless users.
Used internally for single sign-on authentication (HTTPS).
Not exposed to wireless users.
For internal use.
The Aruba Discovery Protocol (ADP)
For internal use.
Used for HTTP access.
1112 | Behavior and Defaults ArubaOS 6.5.3.x | User Guide
Chapter 46
DHCP with Vendor-Specific Options
n n
This chapter describes how to configure several DHCP vendor-specific options.
Topics in this chapter include: n
Configuring a Windows-Based DHCP Server on page 1113
Enabling DHCP Relay Agent Information Option (Option-82) on page 1116
Enabling Linux DHCP Servers on page 1118
Configuring a Windows-Based DHCP Server
Configuring a Microsoft Windows-based DHCP server to send option 43 to the DHCP client on an Aruba AP consists of the following two tasks: n n
Configuring Option 60
Configuring Option 43
DHCP servers are a popular way of configuring clients with basic networking information such as an IP address, a default gateway, network mask, DNS server, and so on. Most DHCP servers have the ability to also send a variety of optional information, including the Vendor-Specific Option Code, also called option 43.
When a client or an AP requests for option 43 (Vendor Specific Information), the controller responds with the value configured by administrator in the DHCP pool.
Configuring Option 60
This section describes how to configure the Vendor Class Identifier Code (option 60) on a Microsoft Windowsbased DHCP server.
As mentioned in the overview section, option 60 identifies and associates a DHCP client with a particular vendor. Any DHCP server configured to take action based on a client’s vendor ID should also have this option configured.
Since option 60 is not a predefined option on a Windows DHCP server, you must add it to the option list for the server.
Configuring Option 60 using the Windows DHCP Server
1. On the DHCP server, open the DHCP server administration tool by clicking Start > AdministrativeTools >
DHCP .
2. Find your server and right-click on the scope to be configured under the server name. Select Set
Predefined Options .
3. In the Predefined Options and Values dialog box, click Add.
4. In the Option Type dialog box, enter the following information
ArubaOS 6.5.3.x
| User Guide DHCP with Vendor-Specific Options | 1113
Table 279: Configuring Option 60 using the Windows DHCP
Server
Field
Name
Data Type
Code
Description
Information
Aruba Access Point
String
60
Aruba AP vendor class identifier
5. Click OK to save this information.
6. In the Predefined Options and Values dialog box, make sure 060 Aruba Access Point is selected from the
Option Name drop-down list.
7. In the Value field, enter the following information:
String : ArubaAP
8. Click OK to save this information.
9. Under the server, select the scope you want to configure and expand it. Select Scope Options , then select
Configure Options .
10.In the Scope Options dialog box, scroll down and select 060 Aruba Access Point . Confirm the value is set to ArubaAP and click OK .
11.Confirm that the option 060 Aruba Access Point is listed in the right pane.
Configuring Option 43
Configuring Option 43 returns the IP address of the Aruba master controller to an Aruba DHCP client. This information allows Aruba APs to auto-discover the master controller and obtain their configuration.
Configuring Option 43 using the Windows DHCP Server:
1. On the DHCP server, open the DHCP server administration tool by clicking Start > Administration Tools
> DHCP .
2. Find your server and right-click on the scope to be configured under the server name. Click on the Scope
Options entry and select Configure Options .
3. In the Scope Options dialog box ( Figure 238
), scroll down and select 043 Vendor Specific Info .
1114 | DHCP with Vendor-Specific Options ArubaOS 6.5.3.x | User Guide
Figure 238 Scope Options Dialog Box.
4. In the Data Entry field, click anywhere in the area under the ASCII heading and enter the following information:
ASCII : Loopback address of the master controller
5. Click the OK to save the configuration.
Option 43 is configured for this DHCP scope. Note that even though you entered the IP address in ASCII text, it displays in binary form.
ArubaOS 6.5.3.x
| User Guide DHCP with Vendor-Specific Options | 1115
Figure 239 DHCP Scope Values
Enabling DHCP Relay Agent Information Option (Option-82)
The DHCP Relay Agent Information option (Option-82) allows the DHCP Relay Agent to insert circuit specific information into a request that is being forwarded to a DHCP server.
The controller, when acting as a DHCP relay agent, inserts information about the AP and SSID through which a client connects to the DHCP request. Many service providers use this mechanism to make access control decisions.
Starting from ArubaOS 6.5.1, Option-82 can be customized to cater to the requirements of any Internet
Service Provider (ISP) using the Aruba controller. To facilitate customization using a XML definition, multiple parameters for Circuit ID and Remote ID options of DHCP Option-82 have been introduced. The XML file is used as the input from the user and is validated against an XSD file in the controller. The format in the XML file is parsed and stored in the DHCP relay which is used to insert Option-82 related values in the DHCP request packets sent from the client to the server.
DHCP Option-82 is supported only for IPv4, and applies only to AP Tunnel and D-Tunnel modes.
DHCP Option-82 on L2 VLAN can now be enabled without the helper address.
Sample XML Format
The following is a sample XML file which specifies DHCP Option-82 circuit and remote IDs.
<?xml version="1.0" encoding="UTF-8"?>
<dhcpopt82>
<circuit_id>
<param>
<type>var</type>
<val>apmac</val>
<delim>-</delim>
</param>
1116 | DHCP with Vendor-Specific Options ArubaOS 6.5.3.x | User Guide
</circuit_id>
<remote_id>
<param>
<type>var</type>
<val>cmac</val>
<delim>:</delim>
</param>
</remote_id>
</dhcpopt82>
The table below lists the elements introduced in the param sub-options of the Circuit ID and Remote ID fields:
XML File Parameters
Parameter
Type
Val
Delim
Description
Listed below are the types available: n var - A DHCP option-82 allowed keyword n n hex - A hexadecimal string with a maximum of 60 characters str - An ASCII string that with a maximum of 60 characters
This field contains either a hexadecimal string or ASCII string limited to 60 characters, if the type is hex or str. If the type is var then one of the following
DHCP option-82 keywords: n n apname - AP name apmac - AP MAC n n n cmac - Client MAC essid - ESSID broadcasted by the AP bssid - BSSID of the AP
The delim option is available only for mac based keywords - apmac, cmac, and bssid. The delim field is used if mac addresses are required to be in ASCII format with octets separated with specified ASCII character in the val part of delim field.
By default the ASCII MAC separated by a delimiter, will be in lower case. If the user wants to use upper case then the respective mac based val keywords should be written in upper case in XML file. For example:
<param>
<type>var</type>
<val>CMAC</val>
<delim>:</delim>
</param>
Configuring XML Based DHCP Option-82 Information
Listed below is the sequence of steps to be followed if a user wants to use XML based DHCP option-82:
1. Upload the XML file containing Option-82 information to flash using the copy command. For example:
(host) #copy scp: 10.20.22.42 piddalagi /home/piddalagi/my_dhcp_option_82.xml flash: my_ dhcp_option_82.xml
Password:**********
Secure File Copy:....
2. In the configuration terminal execute the following command:
#ip dhcp option-82 <xml-file-name-in-flash>
For example:
(host) (config) #ip dhcp option-82 my_dhcp_option_82.xml
ArubaOS 6.5.3.x
| User Guide DHCP with Vendor-Specific Options | 1117
3. After the ip dhcp option-82 <xml-file-name-in-flash> command is executed successfully, in the WLAN interface configuration execute option-82 command to apply option-82 configuration to the DHCP packets that need to be relayed from that interface.
For example:
(host) (config) #interface vlan 25
(host) (config-subif)#option-82
4. Execute the following command if the user wants to remove option-82 configuration:
(host) (config) #no ip dhcp option-82
This command is not successful if there is a WLAN VLAN interface configured with option-82 command. To remove option-82 configuration, go to the respective VLAN interface and execute no option-82 command and then execute the no ip dhcp option-82 command.
Configuring Option-82
You can configure option-82 using the WebUI or the CLI.
In the WebUI
1. Navigate to Configuration > Network > IP > IP Interfaces tab.
2. Click Edit next to the VLAN ID for which you want to configure Option-82.
3. Select the Option-82 check-box to enable option-82.
4. Click Apply .
In the CLI
Execute the following command to configure DHCP Option-82:
(host) (config) #ip dhcp option-82 finalxml.xml
Execute the following command to enable DHCP Option-82 on VLAN with helper address:
(host) (config) #interface vlan 25
(host) (config-subif) #option-82
Execute the following command to enable Option-82 on L2 VLAN:
(host) (config) #vlan 25 option-82
Execute the following command to check if Option-82 is enabled:
(host) #show vlan
VLAN CONFIGURATION
------------------
VLAN
----
1
25
Description
-----------
Default
VLAN0025
Ports
-----
AAA Profile Option-82
-------------------
GE0/0/0-0/1 GE0/0/2-0/5 Pc0-7 N/A
N/A
Disabled
Enabled
Execute the following command to remove Option-82 configuration:
(host) (config) #no ip dhcp option-82
Execute the following command to remove DHCP option-82 configuration on L3 VLAN:
(host) (config) #interface vlan
(host) (config) #no vlan option-82
Enabling Linux DHCP Servers
The following is an example configuration for the Linux dhcpd.conf file. After you enter the configuration, you must restart the DHCP service.
1118 | DHCP with Vendor-Specific Options ArubaOS 6.5.3.x | User Guide
option serverip code 43 = ip-address; class "vendor-class" {
match option vendor-class-identifier;
}
.
.
.
subnet 10.200.10.0 netmask 255.255.255.0 {
default-lease-time 200;
max-lease-time 200;
option subnet-mask 255.255.255.0;
option routers 10.200.10.1;
option domain-name-servers 10.4.0.12;
option domain-name "vlan10.aa.mycorpnetworks.com";
subclass "vendor-class" "ArubaAP" {
option vendor-class-identifier "ArubaAP";
#
# option serverip <loopback-IP-address-of-master-controller>
#
option serverip 10.200.10.10;
}
range 10.200.10.200 10.200.10.252;
}
ArubaOS 6.5.3.x
| User Guide DHCP with Vendor-Specific Options | 1119
Chapter 47
802.1X Configuration for IAS and Windows Clients
This chapter provides examples of how to configure a Microsoft Internet Authentication Server, and a Windows
XP wireless client for 802.1X authentication with the controller (see
802.1X Authentication on page 265
). for information about configuring the controller
For more information about configuring computers in a Windows environment for PEAP-MS-CHAPv2 and EAP-
TLS authentication, see the Microsoft document Step-by-Step Guide for Setting Up Secure Wireless Access in a
Test Lab , available from Microsoft’s Download Center (at www.microsoft.com/downloads .
Additional information on client configuration is available at http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/wificomp.mspx#EQGAC .
This chapter describes the following topics: n n n
Configuring Microsoft IAS on page 1120
Configuring Management Authentication using IAS on page 1122
Window XP Wireless Client Sample Configuration on page 1124
Configuring Microsoft IAS
Microsoft Internet Authentication Server (IAS) provides authentication functions for the wireless network. IAS implements the RADIUS protocol, which is used between the Aruba controller and the server. IAS uses Active
Directory as the database for looking up computers, users, passwords, and group information.
RADIUS Client Configuration
Each device in the network that needs to authenticate to a RADIUS server must be configured as a RADIUS client. You must configure the Aruba controller as a RADIUS client.
The steps to perform this task may very depending on the version of Windows currently running on your server. For complete details on configuring Windows IAS, refer to the Windows documentation available (at www.microsoft.com/download s).
To configure a RADIUS client:
1. From your windows server, navigate to Start > Settings > Control Panel > Administrative
Tools>Internet Authentication Service .
2. In the Internet Authentication Service window, select RADIUS Clients .
3. To configure a RADIUS client, select Action > New RADIUS Client from the menu at the top of the window.
4. In the New RADIUS Client dialog window, enter the name and IP address for the controller. Click Next .
5. In the next window that appears, enter and confirm a shared secret. The shared secret is configured on both the RADIUS server and client, and ensures that an unauthorized client cannot perform authentication against the server.
6. Click Finish .
Remote Access Policies
The IAS policy configuration defines all policies related to wireless access, including time of day restrictions, session length, authentication type, and group-related policies. See Microsoft product documentation for
ArubaOS 6.5.3.x
| User Guide 802.1X Configuration for IAS and Windows Clients | 1120
detailed descriptions and explanations of IAS policy settings.
Active Directory Database
The Active Directory database serves as the master authentication database for both the wired and wireless networks. The IAS authentication server bases all authentication decisions on information in the Active
Directory database. IAS is normally used as an authentication server for remote access and thus looks to the
Active Directory “Remote Access” property to determine whether authentication requests should be allowed or denied. This property is set on a per-user or per-computer basis. For a user or computer to be allowed access to the wireless network, the remote access property must be set to “Allow access”.
The authentication policy configured in IAS depends on the group membership of the computer or user in
Active Directory. These policies are responsible for passing group information back to the controller for use in assigning computers or users to the correct role, which determines their network access privileges. When the
IAS server receives a request for authentication, it compares the request with the list of remote access policies.
The first policy to match the request is executed; additional policies are not searched.
Configuring Policies
The policies in this 802.1X authentication example are designed to work by examining the username portion of the authentication request, searching the Active Directory database for a matching name, and then examining the group membership for a computer or user entry that matches. For example, the following policies would operate with the controller configuration shown in
Configuring Authentication with an 802.1X RADIUS Server on page 277 :
n n n n
The Wireless-Computers policy matches the “Domain Computers” group. This group contains the list of all computers that are members of the domain. This group is used for all computers to authenticate to the network.
The Wireless-Student policy matches the “Student” group. This group is used for all student users.
The Wireless-Faculty policy matches the “Faculty” group. This group is used for all faculty users.
The Wireless-Sysadmin policy matches the “Sysadmin” group. This group is used for system administrators.
In addition to matching the respective group, the policy also specifies that the request must be from an 802.11
wireless device. The policy instructs IAS to grant remote access permission if all the conditions specified in the policy match, a valid username/password is supplied, the user’s or computer’s remote access permission is set to “Allow”.
To configure a policy:
1. In the Internet Authentication Service window, select Remote Access Policies .
2. To add a new policy, select Action > New Remote Access Policy . This launches a wizard that steps you through configuring the remote access policy.
3. Click Next on the initial wizard window to proceed.
4. Enter the name for the policy, for example, “Wireless Computers” and click Next .
5. In the Access Method window, select the Wireless option, then click Next .
6. in the User or Group Access window, select Group and click Add to add the group of users to which this policy applies (for example, “Domain Computers”). Click Next .
7. For Authentication Methods, select either Protected EAP (PEAP) or Smart Card or other certificate .
8. Click Configure to select additional properties.
9. Select a server certificate. The list of available certificates is taken from the computer certificate store on which IAS is running. In this case, a self-signed certificate was generated by the local certificate authority and installed on the IAS system. On each wireless client device, the local certificate authority is added as a trusted certificate authority, thus allowing this certificate to be trusted.
1121 | 802.1X Configuration for IAS and Windows Clients ArubaOS 6.5.3.x | User Guide
10.For PEAP, select the “inner” authentication method. The authentication method shown is MS-CHAPv2.
(Because password authentication is being used on this network, this is the only EAP authentication type that should be selected.)
You can also enable fast reconnect in this screen. If you enable fast reconnect here and also on client devices, additional time can be saved when multiple authentications take place (such as when clients are roaming between APs frequently) because the server will keep the PEAP encrypted tunnel alive.
11.Click
OK .
Configuring RADIUS Attributes
In the configuration example for 802.1X, the controller restricts network access privileges based on the group membership of the computer or user. In order for this to work, the controller must be told to which group the user belongs. This is accomplished using RADIUS attributes returned by the authentication server.
To configure RADIUS attributes:
1. In the Internet Authentication Service window, select Remote Access Policies .
1. Open the remote access policy you want to configure, and select the Advanced tab.
2. Click Add to configure an attribute.
3. Select the Class attribute.
4. Enter the value for this attribute. For example, for the Wireless-Computers policy, the Class attribute returned to the controller should contain the value “computer”.
5. Click OK .
6. Click OK .
Another example of a Class attribute configuration is shown below for the “Wireless-Student” policy. This policy returns the RADIUS attribute Class with the value “student” upon successful completion.
Configuring Management Authentication using IAS
Before you can configure the controller for management authentication using Windows IAS, you must perform the following steps to configure a Windows IAS RADIUS server on your Windows client.
The steps to perform this task may very depending on the version of Windows currently running on your server. For complete details on configuring Windows IAS, refer to the Windows documentation available at www.microsoft.com/downloads ).
1. From your windows server, navigate to Start > Settings > Control Panel > Administrative
Tools>Internet Authentication Service . The Internet Authentication Service window opens.
2. Verify that the Internet Authentication Service is running. If it is running, a green arrow icon will appear at the top of this window. If it has stopped, a red stop icon will appear. If the service is not active, click the green arrow icon to restart the service.
3. From the Internet Authentication Service window, right click the Radius Clients folder and select New
Radius Client . The New RADIUS Client window opens.
4. Define a friendly name for the RADIUS client and enter the controller’s IP address or DNS name. Click Next .
5. Enter and confirm the Shared Secret key for the controller then click Finish .
Next, create a remote policy for your new RADIUS client.
ArubaOS 6.5.3.x
| User Guide 802.1X Configuration for IAS and Windows Clients | 1122
Creating a Remote Policy
1. From the Internet Authentication Service window, right click the Remote Access Policies folder and select New Remote Access Policy .
2. The New Remote Access Policy Wizard opens. Click Next on the first window to start the wizard.
3. Select Use the wizard to set up a typical Policy for a common scenario and enter a name for the policy, for example, Remote-Policy. Click Next .
4. In the Access Method window of the wizard, select the method you will use to gain management access to the network. Click Next .
5. In the User or Group Access window of the wizard, select either user or group , depending upon how your user permissions are defined. Click Next .
6. In the Authentication Method window, click the Type drop-down list and select Protected EAP (PEAP) .
Click Next .
7. Click Finish .
Now you must define properties for the remote policy you just created.
Defining Properties for Remote Policy
1. In the Internet Authentication Service window, click the Remote Access Policy icon. All configured remote access policies will appear in the right window pane.
2. Right-click the policy you just created, and select Properties . The Properties window opens.
3. Select the Grant remote access permission radio button, and click Edit Profile . The Edit Profile window opens.
4. Click the Authentication tab and select the authentication methods that include MS-CHAP, MS-CHAP V2 and PAP .
5. Click Apply .
6. Click the Advanced tab.
7. Click Add . The Add Attribute window opens.
8. Scroll down the list of attributes and select Vendor-Specific , then click Add . The MultiValued Attribute
Information window appears.
9. Click Add again.
10.Enter the vendor code 14823 and select the option Yes, It conforms .
11.Click
Configure Attribute . The Configure VSA window opens.
12.In the Vendor-assigned attribute number field, enter 3 .
13.In the Attribute value field, enter 7 .
14.Click
OK to save your settings.
15.Click
Apply .
16.Click
Apply .
Now that you have defined your remote policy properties, you must create a user entry in the Windows active directory. The steps to complete this process will vary, depending on the version of Windows currently running on your server. The procedure below should be used only as a guideline.
Creating a User Entry in Windows Active Directory
1. Open the “Active Directory Users and Computers” tool on your Windows server.
2. Create a new user entry on the Windows Active directory.
3. Once you have created the new user, right-click the user name and select Properties .
1123 | 802.1X Configuration for IAS and Windows Clients ArubaOS 6.5.3.x | User Guide
4. Click the Dial-in tab and select “Allow access” for the user.
5. Click Ok to save your settings.
Configure the Controller to use IAS Management Authentication
The following procedure describes the steps to configure the controller to user IAS management authentication.
1. Access the controller WebUI and navigate to Configuration>Authentication .
2. Select the Servers tab.
3. Select RADIUS Server.
4. Enter a name for the RADIUS server in the entry field in the right window pane, then click Add .
5. Select the RADIUS server you just created from the list of servers in the left window pane to display configuration details for that server.
6. In the Host field, enter the IP address of the RADIUS server you want to use for Management
Authentication.
7. Enter and then retype the shared key for the server.
8. Click Apply
9. Select Server Group from the server list on the left window pane.
10.In the entry blank on the right window pane, enter the name of a new server group (for example,
“Management_group”), then click Add .
11.Click
Apply.
12.Select the server group you just created from the list of server groups in the left window pane.
13.In the Servers section, click New .
14.Click the Server Name drop-down list and select your RADIUS server.
15.Click
Apply .
Verify Communication between the Controller and the RADIUS Server
After you have configured your Windows Server and the Aruba controller for Windows IAS Management
Authentication, you can verify that the controller and server are communicating.
1. Navigate to Diagnostics>AAA Test Server .
2. Click the Server Name drop-down list and select the RADIUS server.
3. Select either MSCHAP-V2 or PAP as the authentication method.
4. Enter the user name and password in the Username and Password fields.
5. Click Begin Test .
6. If the controller displays the words Authentication Successful , then the controller is able to communicate with the RADIUS server.
Window XP Wireless Client Sample Configuration
This section shows an example of how to configure a Windows XP wireless client using Windows XP’s Wireless
Zero Configuration service.
The following steps apply to a computer running Windows XP Professional Version 2002 with Service Pack 2. To configure a wireless client on other Windows platforms, see your Microsoft Windows documentation.
1. On the desktop, right-click My Network Places and select Properties .
ArubaOS 6.5.3.x
| User Guide 802.1X Configuration for IAS and Windows Clients | 1124
2. In the Network Connections window, right-click on Wireless Network Connection and select Properties .
3. Select the Wireless Networks tab. This screen displays the available wireless networks and the list of preferred networks. Windows connects to the preferred networks in the order in which they appear in the list.
4. Click the Advanced button to display the Networks to access window.
This window determines what types of wireless networks the client can access. By default, Windows connects to any type of wireless network. Make sure that the option Computer-to-computer (ad hoc) networks only is not selected. Click Close .
5. In the Wireless Networks tab, click Add to add a wireless network.
6. Click the Association tab to enter the network properties for the SSID.
This tab configures the authentication and encryption used between the wireless client and the Aruba user-centric network. Therefore, the settings for the SSID that you configure on the client must match the configuration for the
SSID on the controller.
n n n n n
For an SSID using dynamic WEP, enter the following: l
Network Authentication: Open l l
Data Encryption: WEP
Select the option “The key is provided for me automatically”. Each client will use a dynamicallygenerated WEP key that is automatically derived during the 802.1X process.
For an SSID using WPA, enter the following: l l l l
Network Authentication: WPA
Data Encryption: TKIP
For an SSID using WPA-PSK, enter the following: l
Network Authentication: WPA-PSK
Data Encryption: TKIP
Enter the pre-shared key.
For an SSID using WPA2, enter the following: l
Network Authentication: WPA2 l
Data Encryption: AES
For an SSID using WPA2-PSK, enter the following: l l l
Network Authentication: WPA2-PSK
Data Encryption: AES
Enter the pre-shared key
Do not select the option “This is a computer-to-computer (ad hoc) network; wireless access points are not used”.
7. Click the Authentication tab to enter the 802.1X authentication parameters for the SSID. This tab configures the EAP type used between the wireless client and the authentication server.
Configure the following: n n n
Select Enable IEEE 802.1X authentication for this network.
Select Protected EAP (PEAP) for the EAP type.
Select Authenticate as computer when computer information is available. The client will perform computer authentication when a user is not logged in.
1125 | 802.1X Configuration for IAS and Windows Clients ArubaOS 6.5.3.x | User Guide
n n n n n
Do not select Authenticate as guest when user or computer information is unavailable. The client will not attempt to authenticate as a guest.
Select Validate server certificate. This instructs the client to check the validity of the server certificate from an expiration, identity, and trust perspective.
Select the trusted Certification Authority (CA) that can issue server certificates for the network.
Select Secured password (EAP-MSCHAP v2) — the PEAP “inner authentication” mechanism will be an MS-
CHAPv2 password.
Select Enable Fast Reconnect to speed up authentication in some cases.
8. Under Select Authentication Method, click Configure to display the EAP-MSCHAPv2 Properties window.
Select the option Automatically use my Windows logon name and password (and domain if any). This option specifies that the user’s Windows logon information is used for authentication to the wireless network. This option allows the same logon credentials to be used for access to the Windows domain as well as the wireless network.
ArubaOS 6.5.3.x
| User Guide 802.1X Configuration for IAS and Windows Clients | 1126
Appendix A
Glossary of Terms
The following table provides a brief description of the terminology used in this guide.
3DES
Triple Data Encryption Standard. 3DES is a symmetric-key block cipher that applies the DES cipher algorithm three times to each data block.
3G
Third Generation of Wireless Mobile Telecommunications Technology. See W-CDMA.
3GPP
Third Generation Partnership Project. 3GPP is a collaborative project aimed at developing globally acceptable specifications for third generation mobile systems.
4G
Fourth Generation of Wireless Mobile Telecommunications Technology. See LTE.
802.11
802.11 is an evolving family of specifications for wireless LANs developed by a working group of the Institute of Electrical and Electronics Engineers (IEEE). 802.11 standards use the Ethernet protocol and Carrier Sense
Multiple Access with collision avoidance (CSMA/CA) for path sharing.
802.11 bSec
802.11 bSec is an alternative to 802.11i. The difference between bSec and standard 802.11i is that bSec implements Suite B algorithms wherever possible. Notably, Advanced Encryption Standard-Counter with CBC-
MAC is replaced by Advanced Encryption Standard - Galois/Counter Mode, and the Key Derivation Function
(KDF) of 802.11i is upgraded to support SHA-256 and SHA-384.
802.11a
802.11a provides specifications for wireless systems. Networks using 802.11a operate at radio frequencies in the 5 GHz band. The specification uses a modulation scheme known as orthogonal frequency-division multiplexing (OFDM) that is especially well suited to use in office settings. The maximum data transfer rate is
54 Mbps.
802.11ac
802.11ac is a wireless networking standard in the 802.11 family that provides high-throughput WLANs on the
5 GHz band.
802.11b
802.11b is a WLAN standard often called Wi-Fi and is backward compatible with 802.11. Instead of the Phase-
Shift Keying (PSK) modulation method used in 802.11 standards, 802.11b uses Complementary Code Keying
(CCK) that allows higher data speeds and makes it less susceptible to multipath-propagation interference.
802.11b operates in the 2.4 GHz band and the maximum data transfer rate is 11 Mbps.
802.11d
802.11d is a wireless network communications specification for use in countries where systems using other standards in the 802.11 family are not allowed to operate. Configuration can be fine-tuned at the Media
Access Control (MAC) layer level to comply with the rules of the country or district in which the network is to be used. Rules are subject to variation and include allowed frequencies, allowed power levels, and allowed signal bandwidth. 802.11d facilitates global roaming.
ArubaOS 6.5.3.x
| User Guide Glossary of Terms | 1127
802.11e
802.11e is an enhancement to the 802.11a and 802.11b specifications that enhances the 802.11 Media
Access Control layer with a coordinated Time Division Multiple Access (TDMA) construct. It adds errorcorrecting mechanisms for delay-sensitive applications such as voice and video. The 802.11e specification provides seamless interoperability between business, home, and public environments such as airports and hotels, and offers all subscribers high-speed Internet access with full-motion video, high-fidelity audio, and
VoIP.
802.11g
802.11g offers transmission over relatively short distances at up to 54 Mbps, compared with the 11 Mbps theoretical maximum of 802.11b standard. 802.11g employs Orthogonal Frequency Division Multiplexing
(OFDM), the modulation scheme used in 802.11a, to obtain higher data speed. Computers or terminals set up for 802.11g can fall back to speed of 11 Mbps, so that 802.11b and 802.11g devices can be compatible within a single network.
802.11h
802.11h is intended to resolve interference issues introduced by the use of 802.11a in some locations, particularly with military RADAR systems and medical devices. Dynamic Frequency Selection (DFS) detects the presence of other devices on a channel and automatically switches the network to another channel if and when such signals are detected. Transmit Power Control (TPC) reduces the radio frequency (RF) output power of each network transmitter to a level that minimizes the risk of interference.
802.11i
802.11i provides improved encryption for networks that use 802.11a, 802.11b, and 802.11g standards. It requires new encryption key protocols, known as Temporal Key Integrity Protocol (TKIP) and Advanced
Encryption Standard (AES).
802.11j
802.11j is a proposed addition to the 802.11 family of standards that incorporates Japanese regulatory extensions to 802.11a; the main intent is to add channels in the radio frequency (RF) band of 4.9 GHz to 5.0
GHz.
802.11k
802.11k is an IEEE standard that enables APs and client devices to discover the best available radio resources for seamless BSS transition in a WLAN.
802.11m
802.11m is an Initiative to perform editorial maintenance, corrections, improvements, clarifications, and interpretations relevant to documentation for 802.11 family specifications.
802.11n
802.11n is a wireless networking standard to improve network throughput over the two previous standards,
802.11a and 802.11g. With 802.11n, there will be a significant increase in the maximum raw data rate from 54
Mbps to 600 Mbps with the use of four spatial streams at a channel width of 40 MHz.
802.11r
802.11r is an IEEE standard for enabling seamless BSS transitions in a WLAN. 802.11r standard is also referred to as Fast BSS transition.
802.11u
802.11u is an amendment to the IEEE 802.11 WLAN standards for connection to external networks using common wireless devices such as smartphones and tablet PCs. The 802.11u protocol provides wireless clients with a streamlined mechanism to discover and authenticate to suitable networks, and allows mobile users to roam between partner networks without additional authentication. An 802.11u-capable device
1128 | Glossary of Terms ArubaOS 6.5.3.x | User Guide
supports the Passpoint technology from the Wi-Fi Alliance Hotspot 2.0 R2 Specification that simplifies and automates access to public Wi-Fi.
802.11v
802.11v is an IEEE standard that allows client devices to exchange information about the network topology and RF environment. This information is used for assigning best available radio resources for the client devices to provide seamless connectivity.
802.1Q
802.1Q is an IEEE standard that enables the use of VLANs on an Ethernet network. 802.1Q supports VLAN tagging.
802.1X
802.1X is an IEEE standard for port-based network access control designed to enhance 802.11 WLAN security.
802.1X provides an authentication framework that allows a user to be authenticated by a central authority.
802.3af
802.3af is an IEEE standard for Power over Ethernet (PoE) version that supplies up to 15.4W of DC power. See
PoE.
802.3at
802.3at is an IEEE standard for PoE version that supplies up to 25.5W of DC power. See PoE+.
AAA
Authentication, Authorization, and Accounting. AAA is a security framework to authenticate users, authorize the type of access based on user credentials, and record authentication events and information about the network access and network resource consumption.
ABR
Area Border Router. ABR is used for establishing connection between the backbone networks and the Open
Shortest Path First (OSPF) areas. ABR is located near the border of one or more OSPF areas.
AC
Access Category. As per the IEEE 802.11e standards, AC refers to various levels of traffic prioritization in
Enhanced Distributed Channel Access (EDCA) operation mode. The WLAN applications prioritize traffic based on the Background, Best Effort, Video, and Voice access categories. AC can also refer to Alternating Current, a form of electric energy that flows when the appliances are plugged to a wall socket.
ACC
Advanced Cellular Coexistence. The ACC feature in APs enable WLANs to perform at peak efficiency by minimizing interference from 3G/4G/LTE networks, distributed antenna systems, and commercial small cell/femtocell equipment.
Access-Accept
Response from the RADIUS server indicating successful authentication and containing authorization information.
Access-Reject
Response from RADIUS server indicating that a user is not authorized.
Access-Request
RADIUS packet sent to a RADIUS server requesting authorization.
Accounting-Request
RADIUS packet type sent to a RADIUS server containing accounting summary information.
ArubaOS 6.5.3.x
| User Guide Glossary of Terms | 1129
Accounting-Response
RADIUS packet sent by the RADIUS server to acknowledge receipt of an Accounting-Request.
ACE
Access Control Entry. ACE is an element in an ACL that includes access control information.
ACI
Adjacent Channel Interference. ACI refers to interference or interruptions detected on a broadcasting channel, caused by too much power on an adjacent channel in the spectrum.
ACL
Access Control List. ACL is a common way of restricting certain types of traffic on a physical port.
Active Directory
Microsoft Active Directory. The directory server that stores information about a variety of things, such as organizations, sites, systems, users, shares, and other network objects or components. It also provides authentication and authorization mechanisms, and a framework within which related services can be deployed.
ActiveSync
Mobile data synchronization app developed by Microsoft that allows a mobile device to be synchronized with either a desktop or a server running compatible software products.
ad hoc network
An ad hoc network is a network composed of individual devices communicating with each other directly. Many ad hoc networks are Local Area Networks (LANs) where computers or other devices are enabled to send data directly to one another rather than going through a centralized access point.
ADO
Active X Data Objects is a part of Microsoft Data Access Components (MDACs) that enables client applications to access data sources through an (Object Linking and Embedding Database) OLE DB provider.
ADO supports key features for building client-server and Web-based applications.
ADP
Aruba Discovery Protocol. ADP is an Aruba proprietary Layer 2 protocol. It is used by the APs to obtain the IP address of the TFTP server from which it downloads the AP boot image.
AES
Advanced Encryption Standard. AES is an encryption standard used for encrypting and protecting electronic data. The AES encrypts and decrypts data in blocks of 128 bits (16 bytes), and can use keys of 128 bits, 192 bits, and 256 bits.
AIFSN
Arbitrary Inter-frame Space Number. AIFSN is set by the AP in beacon frames and probe responses. AIFS is a method of prioritizing a particular category of traffic over the other, for example prioritizing voice or video messages over email.
AirGroup
The application that allows the end users to register their personal mobile devices on a local network and define a group of friends or associates who are allowed to share them. AirGroup is primarily designed for colleges and other institutions. AirGroup uses zero configuration networking to allow Apple mobile devices, such as the AirPrint wireless printer service and the AirPlay mirroring service, to communicate over a complex access network topology.
AirWave Management Client
AirWave Management Client is a Windows software utility that enables client devices (such as a laptop) to act as passive RF sensors and augments the AirWave RAPIDS module.
1130 | Glossary of Terms ArubaOS 6.5.3.x | User Guide
ALE
Analytics and Location Engine. ALE gives visibility into everything the wireless network knows. This enables customers and partners to gain a wealth of information about the people on their premises. This can be very important for many different verticals and use cases. ALE includes a location engine that calculates associated and unassociated device location periodically using context streams, including RSSI readings, from
WLAN controllers or Instant clusters.
ALG
Application Layer Gateway. ALG is a security component that manages application layer protocols such as SIP,
FTP and so on.
AM
Air Monitor. AM is a mode of operation supported on wireless APs. When an AP operates in the Air Monitor mode, it enhances the wireless networks by collecting statistics, monitoring traffic, detecting intrusions, enforcing security policies, balancing wireless traffic load, self-healing coverage gaps, and more. However, clients cannot connect to APs operating in the AM mode.
AMON
Advanced Monitoring. AMON is used in Aruba WLAN deployments for improved network management, monitoring and diagnostic capabilities.
AMP
AirWave Management Platform. AMP is a network management system for configuring, monitoring, and upgrading wired and wireless devices on your network.
A-MPDU
Aggregate MAC Protocol Data Unit. A-MPDU is a method of frame aggregation, where several MPDUs are combined into a single frame for transmission.
A-MSDU
Aggregate MAC Service Data Unit. A-MSDU is a structure containing multiple MSDUs, transported within a single (unfragmented) data MAC MPDU.
ANQP
Access Network Query Protocol. ANQP is a query and a response protocol for Wi-Fi hotspot services. ANQP includes information Elements (IEs) that can be sent from the AP to the client to identify the AP network and service provider. The IEs typically include information about the domain name of the AP operator, the IP addresses available at the AP, and information about potential roaming partners accessible through the AP. If the client responds with a request for a specific IE, the AP will send a Generic Advertisement Service (GAS) response frame with the configured ANQP IE information.
ANSI
American National Standards Institute. It refers to the ANSI compliance standards for products, systems, services, and processes.
API
Application Programming Interface. Refers to a set of functions, procedures, protocols, and tools that enable users to build application software.
app
Short form for application. It generally refers to the application that is downloaded and used on mobile devices.
ARM
Adaptive Radio Management. ARM dynamically monitors and adjusts the network to ensure that all users are allowed ready access. It enables full utilization of the available spectrum to support maximum number of
ArubaOS 6.5.3.x
| User Guide Glossary of Terms | 1131
users by intelligently choosing the best RF channel and transmit power for APs in their current RF environment.
ARP
Address Resolution Protocol. ARP is used for mapping IP network address to the hardware MAC address of a device.
Aruba Activate
Aruba Activate is a cloud-based service that helps provision your Aruba devices and maintain your inventory.
Activate automates the provisioning process, allowing a single IT technician to easily and rapidly deploy devices throughout a distributed enterprise network.
ASCII
American Standard Code for Information Interchange. An ASCII code is a numerical representation of a character or an action.
band
Band refers to a specified range of frequencies of electromagnetic radiation.
BGP
Border Gateway Protocol. BGP is a routing protocol for exchanging data and information between different host gateways or autonomous systems on the Internet.
BLE
Bluetooth Low Energy. The BLE functionality is offered by Bluetooth® to enable devices to run for long durations with low power consumption.
BMC
Beacon Management Console. BMC manages and monitors beacons from the BLE devices. The BLE devices are used for location tracking and proximity detection.
BPDU
Bridge Protocol Data Unit. A BPDU is a data message transmitted across a local area network to detect loops in network topologies.
B-RAS
Broadband Remote Access Server. A B-RAS is a server that facilitates and converges traffic from multiple
Internet traffic resources such as cable, DSL, Ethernet, or Broadband wireless.
BRE
Basic Regular Expression. The BRE syntax standards designed by the IEEE provides extension to the traditional Simple Regular Expressions syntax and allows consistency between utility programs such as grep, sed, and awk.
BSS
Basic Service Set. A BSS is a set of interconnected stations that can communicate with each other. BSS can be an independent BSS or infrastructure BSS. An independent BSS is an ad hoc network that does not include
APs, whereas the infrastructure BSS consists of an AP and all its associated clients.
BSSID
Basic Service Set Identifier. The BSSID identifies a particular BSS within an area. In infrastructure BSS networks, the BSSID is the MAC address of the AP. In independent BSS or ad hoc networks, the BSSID is generated randomly.
BYOD
Bring Your Own Device. BYOD refers to the use of personal mobile devices within an enterprise network infrastructure.
1132 | Glossary of Terms ArubaOS 6.5.3.x | User Guide
CA
Certificate Authority or Certification Authority. Entity in a public key infrastructure system that issues certificates to clients. A certificate signing request received by the CA is converted into a certificate when the
CA adds a signature generated with a private key. See digital certificate.
CAC
Call Admission Control. CAC regulates traffic volume in voice communications. CAC can also be used to ensure or maintain a certain level of audio quality in voice communications networks.
CALEA
Communications Assistance for Law Enforcement Act. To comply with the CALEA specifications and to allow lawful interception of Internet traffic by the law enforcement and intelligence agencies, the telecommunications carriers and manufacturers of telecommunications equipment are required to modify and design their equipment, facilities, and services to ensure that they have built-in surveillance capabilities.
Campus AP
Campus APs are used in private networks where APs connect over private links (LAN, WLAN, WAN or MPLS) and terminate directly on controllers. Campus APs are deployed as part of the indoor campus solution in enterprise office buildings, warehouses, hospitals, universities, and so on.
captive portal
A captive portal is a web page that allows the users to authenticate and sign in before connecting to a publicaccess network. Captive portals are typically used by business centers, airports, hotel lobbies, coffee shops, and other venues that offer free Wi-Fi hotspots for the guest users.
CCA
Clear Channel Assessment. In wireless networks, the CCA method detects if a channel is occupied or clear, and determines if the channel is available for data transmission.
CDP
Cisco Discovery Protocol. CDP is a proprietary Data Link Layer protocol developed by Cisco Systems. CDP runs on Cisco devices and enables networking applications to learn about the neighboring devices directly connected to the network.
CDR
Call Detail Record. A CDR contains the details of a telephone or VoIP call, such as the origin and destination addresses of the call, the start time and end time of the call, any toll charges that were added through the network or charges for operator services, and so on.
CEF
Common Event Format. The CEF is a standard for the interoperability of event or log-generating devices and applications. The standard syntax for CEF includes a prefix and a variable extension formatted as key-value pairs.
CGI
Common Gateway Interface. CGI is a standard protocol for exchanging data between the web servers and executable programs running on a server to dynamically process web pages.
CHAP
Challenge Handshake Authentication Protocol. CHAP is an authentication scheme used by PPP servers to validate the identity of remote clients.
CIDR
Classless Inter-Domain Routing. CIDR is an IP standard for creating and allocating unique identifiers for networks and devices. The CIDR IP addressing scheme is used as a replacement for the older IP addressing
ArubaOS 6.5.3.x
| User Guide Glossary of Terms | 1133
scheme based on classes A, B, and C. With CIDR, a single IP address can be used to designate many unique IP addresses. A CIDR IP address ends with a slash followed by the IP network prefix, for example, 192.0.2.0/24.
ClearPass
ClearPass is an access management system for creating and enforcing policies across a network to all devices and applications. The ClearPass integrated platform includes applications such as Policy Manager,
Guest, Onboard, OnGuard, Insight, Profile, QuickConnect, and so on.
ClearPass Guest
ClearPass Guest is a configurable ClearPass application for secure visitor network access management.
ClearPass Policy Manager
ClearPass Policy Manager is a baseline platform for policy management, AAA, profiling, network access control, and reporting. With ClearPass Policy Manager, the network administrators can configure and manage secure network access that accommodates requirements across multiple locations and multivendor networks, regardless of device ownership and connection method.
CLI
Command-Line Interface. A console interface with a command line shell that allows users to execute text input as commands and convert these commands to appropriate functions.
CN
Common Name. CN is the primary name used to identify a certificate.
CNA
Captive Network Assistant. CNA is a popup page shown when joining a network that has a captive portal.
CoA
Change of Authorization. The RADIUS CoA is used in the AAA service framework to allow dynamic modification of the authenticated, authorized, and active subscriber sessions.
CoS
Class of Service. CoS is used in data and voice protocols for classifying packets into different types of traffic
(voice, video, or data) and setting a service priority. For example, voice traffic can be assigned a higher priority over email or HTTP traffic.
CPE
Customer Premises Equipment. It refers to any terminal or equipment located at the customer premises.
CPsec
Control Plane Security. CPsec is a secure form of communication between a controller and APs to protect the control plane communications. This is performed by means of using public-key self-signed certificates created by each master controller.
CPU
Central Processing Unit. A CPU is an electronic circuitry in a computer for processing instructions.
CRC
Cyclic Redundancy Check. CRC is a data verification method for detecting errors in digital data during transmission, storage, or retrieval.
CRL
Certificate Revocation List. CRL is a list of revoked certificates maintained by a certification authority.
cryptobinding
Short for cryptographic binding. A procedure in a tunneled EAP method that binds together the tunnel protocol and the tunneled authentication methods, ensuring the relationship between a collection of data
1134 | Glossary of Terms ArubaOS 6.5.3.x | User Guide
assets. Cryptographic binding focuses on protecting the server; mutual cryptographic binding protects both peer and server.
CSA
Channel Switch Announcement. The CSA element enables an AP to advertise that it is switching to a new channel before it begins transmitting on that channel. This allows the clients, which support CSA, to transition to the new channel with minimal downtime.
CSMA/CA
Carrier Sense Multiple Access / Collision Avoidance. CSMA/CA is a protocol for carrier transmission in networks using the 802.11 standard. CSMA/CA aims to prevent collisions by listening to the broadcasting nodes, and informing devices not to transmit any data until the broadcasting channel is free.
CSR
Certificate Signing Request. In PKI systems, a CSR is a message sent from an applicant to a CA to apply for a digital identity certificate.
CSV
Comma-Separated Values. A file format that stores tabular data in the plain text format separated by commas.
CTS
Clear to Send. The CTS refers to the data transmission and protection mechanism used by the 802.11
wireless networking protocol to prevent frame collision occurrences. See RTS.
CW
Contention Window. In QoS, CW refers to a window set for access categories based on the type of traffic.
Based on the type and volume of the traffic, the minimum and maximum values can be calculated to provide a wider window when necessary.
DAI
Dynamic ARP inspection. A security feature that validates ARP packets in a network.
DAS
Distributed Antenna System. DAS is a network of antenna nodes strategically placed around a geographical area or structure for additional cellular coverage.
dB
Decibel. Unit of measure for sound or noise and is the difference or ratio between two signal levels.
dBm
Decibel-Milliwatts. dBm is a logarithmic measurement (integer) that is typically used in place of mW to represent receive-power level. AMP normalizes all signals to dBm, so that it is easy to evaluate performance between various vendors.
DCB
Data Center Bridging. DCB is a collection of standards developed by IEEE for creating a converged data center network using Ethernet.
DCE
Data Communication Equipment. DCE refers to the devices that establish, maintain, and terminate communication network sessions between a data source and its destination.
DCF
Distributed Coordination Function. DCF is a protocol that uses carrier sensing along with a four-way handshake to maximize the throughput while preventing packet collisions.
ArubaOS 6.5.3.x
| User Guide Glossary of Terms | 1135
DDMO
Distributed Dynamic Multicast Optimization. DDMO is similar to Dynamic Multicast Optimization (DMO) where the multicast streams are converted into unicast streams on the AP instead of the controller, to enhance the quality and reliability of streaming videos, while preserving the bandwidth available to non-video clients.
DES
Data Encryption Standard. DES is a common standard for data encryption and a form of secret key cryptography, which uses only one key for encryption and decryption.
designated router
Designated router refers to a router interface that is elected to originate network link advertisements for networks using the OSPF protocol.
destination NAT
Destination Network Address Translation. Destination NAT is a process of translating the destination IP address of an end route packet in a network. Destination NAT is used for redirecting the traffic destined to a virtual host to the real host, where the virtual host is identified by the destination IP address and the real host is identified by the translated IP address.
DFS
Dynamic Frequency Selection. DFS is a mandate for radio systems operating in the 5 GHz band to be equipped with means to identify and avoid interference with RADAR systems.
DFT
Discrete Fourier Transform. DFT converts discrete-time data sets into a discrete-frequency representation.
See FFT.
DHCP
Dynamic Host Configuration Protocol. A network protocol that enables a server to automatically assign an IP address to an IP-enabled device from a defined range of numbers configured for a given network.
DHCP snooping
DHCP snooping enables the switch to monitor and control DHCP messages received from untrusted devices that are connected to the switch.
digital certificate
A digital certificate is an electronic document that uses a digital signature to bind a public key with an identity—information such as the name of a person or an organization, address, and so forth.
Digital wireless pulse
A wireless technology for transmitting large amounts of digital data over a wide spectrum of frequency bands with very low power for a short distance. Ultra Wideband radio can carry a huge amount of data over a distance up to 230 ft at very low power (less than 0.5 mW), and has the ability to carry signals through doors and other obstacles that tend to reflect signals at more limited bandwidths and a higher power.
Disconnect-Ack
Disconnect-Ack is a NAS response packet to a Disconnect-Request, which indicates that the session was disconnected.
Disconnect-Nak
Disconnect-Nak is NAS response packet to a Disconnect-Request, which indicates that the session was not disconnected.
Disconnect-Request
Disconnect-Request is a RADIUS packet type sent to a NAS requesting that a user or session be disconnected.
1136 | Glossary of Terms ArubaOS 6.5.3.x | User Guide
distribution certificate
Distribution certificate is used for digitally signing iOS mobile apps to enable enterprise app distribution. It verifies the identity of the app publisher.
DLNA
Digital Living Network Alliance. DLNA is a set of interoperability guidelines for sharing digital media among multimedia devices.
DMO
Dynamic Multicast Optimization. DMO is a process of converting multicast streams into unicast streams over a wireless link to enhance the quality and reliability of streaming videos, while preserving the bandwidth available to non-video clients.
DN
Distinguished Name. A series of fields in a digital certificate that, taken together, constitute the unique identity of the person or device that owns the digital certificate. Common fields in a DN include country, state, locality, organization, organizational unit, and the “common name”, which is the primary name used to identify the certificate.
DNS
Domain Name System. A DNS server functions as a phone book for the intranet and Internet users. It converts human-readable computer host names into IP addresses and IP addresses into host names. It stores several records for a domain name such as an address 'A' record, name server (NS), and mail exchanger (MX) records. The Address 'A' record is the most important record that is stored in a DNS server, because it provides the required IP address for a network peripheral or element.
DOCSIS
Data over Cable Service Interface Specification. A telecommunication standard for Internet access through cable modem.
DoS
Denial of Service. DoS is any type of attack where the attackers send excessive messages to flood traffic and thereby preventing the legitimate users from accessing the service.
DPD
Dead Peer Detection. A method used by the network devices to detect the availability of the peer devices.
DPI
Deep Packet Inspection. DPI is an advanced method of network packet filtering that is used for inspecting data packets exchanged between the devices and systems over a network. DPI functions at the Application layer of the Open Systems Interconnection (OSI) reference model and enables users to identify, categorize, track, reroute, or stop packets passing through a network.
DRT
Downloadable Regulatory Table. The DRT feature allows new regulatory approvals to be distributed for APs without a software upgrade or patch.
DS
Differentiated Services. The DS specification aims to provide uninterrupted quality of service by managing and controlling the network traffic, so that certain types of traffic get precedence.
DSCP
Differentiated Services Code Point. DSCP is a 6-bit packet header value used for traffic classification and priority assignment.
ArubaOS 6.5.3.x
| User Guide Glossary of Terms | 1137
DSL
Digital Subscriber Line. The DSL technology allows the transmission of digital data over telephone lines. A DSL modem is a device used for connecting a computer or router to a telephone line that offers connectivity to the
Internet.
DSSS
Direct-Sequence Spread Spectrum. DSSS is a modulation technique used for reducing overall signal interference. This technique multiplies the original data signal with a pseudo random noise spreading code.
Spreading of this signal makes the resulting wideband channel more noisy, thereby increasing the resistance to interference. See FHSS.
DST
Daylight Saving Time. DST is also known as summer time that refers to the practice of advancing clocks, so that evenings have more daylight and mornings have less. Typically clocks are adjusted forward one hour near the start of spring and are adjusted backward in autumn.
DTE
Data Terminal Equipment. DTE refers to a device that converts user information into signals or re-converts the received signals.
DTIM
Delivery Traffic Indication Message. DTIM is a kind of traffic indication map. A DTIM interval determines when the APs must deliver broadcast and multicast frames to their associated clients in power save mode.
DTLS
Datagram Transport Layer Security. DTLS communications protocol provides communications security for datagram protocols.
dynamic authorization
Dynamic authorization refers to the ability to make changes to a visitor account’s session while it is in progress. This might include disconnecting a session or updating some aspect of the authorization for the session.
dynamic NAT
Dynamic Network Address Translation. Dynamic NAT maps multiple public IP addresses and uses these addresses with an internal or private IP address. Dynamic NAT helps to secure a network by masking the internal configuration of a private network.
EAP
Extensible Authentication Protocol. An authentication protocol for wireless networks that extends the methods used by the PPP, a protocol often used when connecting a computer to the Internet. EAP can support multiple authentication mechanisms, such as token cards, smart cards, certificates, one-time passwords, and public key encryption authentication.
EAP-FAST
EAP – Flexible Authentication Secure Tunnel (tunneled).
EAP-GTC
EAP – Generic Token Card. (non-tunneled).
EAP-MD5
EAP – Method Digest 5. (non-tunneled).
EAP-MSCHAP
EAP Microsoft Challenge Handshake Authentication Protocol.
1138 | Glossary of Terms ArubaOS 6.5.3.x | User Guide
EAP-MSCHAPv2
EAP Microsoft Challenge Handshake Authentication Protocol Version 2.
EAPoL
Extensible Authentication Protocol over LAN. A network port authentication protocol used in IEEE 802.1X
standards to provide a generic network sign-on to access network resources.
EAP-PEAP
EAP–Protected EAP. A widely used protocol for securely transporting authentication data across a network
(tunneled).
EAP-PWD
EAP-Password. EAP-PWD is an EAP method that uses a shared password for authentication.
EAP-TLS
EAP–Transport Layer Security. EAP-TLS is a certificate-based authentication method supporting mutual authentication, integrity-protected ciphersuite negotiation and key exchange between two endpoints. See RFC
5216.
EAP-TTLS
EAP–Tunneled Transport Layer Security. EAP-TTLS is an EAP method that encapsulates a TLS session, consisting of a handshake phase and a data phase. See RFC 5281.
ECC
Elliptical Curve Cryptography or Error correcting Code memory. Elliptical Curve Cryptography is a public-key encryption technique that is based on elliptic curve theory used for creating faster, smaller, and more efficient cryptographic keys. Error Correcting Code memory is a type of computer data storage that can detect and correct the most common kinds of internal data corruption. ECC memory is used in most computers where data corruption cannot be tolerated under any circumstances, such as for scientific or financial computing.
ECDSA
Elliptic Curve Digital Signature Algorithm. ECDSA is a cryptographic algorithm that supports the use of public or private key pairs for encrypting and decrypting information.
EDCA
Enhanced Distributed Channel Access. The EDCA function in the IEEE 802.11e Quality of Service standard supports differentiated and distributed access to wireless medium based on traffic priority and Access
Category types. See WMM and WME.
EIGRP
Enhanced Interior Gateway Routing Protocol. EIGRP is a routing protocol used for automating routing decisions and configuration in a network.
EIRP
Effective Isotropic Radiated Power or Equivalent Isotropic Radiated Power. EIRP refers to the output power generated when a signal is concentrated into a smaller area by the Antenna.
ESI
External Services Interface. ESI provides an open interface for integrating security solutions that solve interior network problems such as viruses, worms, spyware, and corporate compliance.
ESS
Extended Service Set. An ESS is a set of one or more interconnected BSSs that form a single sub network.
ESSID
Extended Service Set Identifier. ESSID refers to the ID used for identifying an extended service set.
ArubaOS 6.5.3.x
| User Guide Glossary of Terms | 1139
Ethernet
Ethernet is a network protocol for data transmission over LAN.
EULA
End User License Agreement. EULA is a legal contract between a software application publisher or author and the users of the application.
FCC
Federal Communications Commission. FCC is a regulatory body that defines standards for the interstate and international communications by radio, television, wire, satellite, and cable.
FFT
Fast Fourier Transform. FFT is a frequency analysis mechanism that aims at faster conversion of a discrete signal in time domain into a discrete frequency domain representation. See also DFT.
FHSS
Frequency Hopping Spread Spectrum. FHSS is transmission technique that allows modulation and transmission of a data signal by rapidly switching a carrier among many frequency channels in a random but predictable sequence. See also DSSS.
FIB
Forwarding Information Base. FIB is a forwarding table that maps MAC addresses to ports. FIB is used in network bridging, routing, and similar functions to identify the appropriate interface for forwarding packets.
FIPS
Federal Information Processing Standards. FIPS refers to a set of standards that describe document processing, encryption algorithms, and other information technology standards for use within non-military government agencies, and by government contractors and vendors who work with these agencies.
firewall
Firewall is a network security system used for preventing unauthorized access to or from a private network.
FQDN
Fully Qualified Domain Name. FQDN is a complete domain name that identifies a computer or host on the
Internet.
FQLN
Fully Qualified Location Name. FQLN is a device location identifier in the format:
APname.Floor.Building.Campus.
frequency allocation
Use of radio frequency spectrum as regulated by governments.
FSPL
Free Space Path Loss. FSPL refers to the loss in signal strength of an electromagnetic wave that would result from a line-of-sight path through free space (usually air), with no obstacles nearby to cause reflection or diffraction.
FTP
File Transfer Protocol. A standard network protocol used for transferring files between a client and server on a computer network.
GARP
Generic Attribute Registration Protocol. GVRP is a LAN protocol that allows the network nodes to register and de-register attributes, such as network addresses, with each other.
1140 | Glossary of Terms ArubaOS 6.5.3.x | User Guide
GAS
Generic Advertisement Service. GAS is a request-response protocol, which provides Layer 2 transport mechanism between a wireless client and a server in the network prior to authentication. It helps in determining a wireless network infrastructure before associating clients, and allows clients to send queries to multiple 802.11 networks in parallel.
gateway
Gateway is a network node that allows traffic to flow in and out of the network.
Gbps
Gigabits per second.
GBps
Gigabytes per second.
GET
GET refers HTTP request method or an SNMP operation method. The GET HTTP request method submits data to be processed to a specified resource. The GET SNMP operation method obtains information from the
Management Information Base (MIB).
GHz
Gigahertz.
GMT
Greenwich Mean Time. GMT refers to the mean solar time at the Royal Observatory in Greenwich, London.
GMT is the same as Coordinated Universal Time (UTC) standard, written as an offset of UTC +/- 00:00.
goodput
Goodput is the application level throughput that refers to the ratio of the total bytes transmitted or received in the network to the total air time required for transmitting or receiving the bytes.
GPS
Global Positioning System. A satellite-based global navigation system.
GRE
Generic Routing Encapsulation. GRE is an IP encapsulation protocol that is used to transport packets over a network.
GTC
Generic Token Card. GTC is a protocol that can be used as an alternative to MSCHAPv2 protocol. GTC allows authentication to various authentication databases even in cases where MSCHAPv2 is not supported by the database.
GVRP
GARP VLAN Registration Protocol or Generic VLAN Registration Protocol. GARP is an IEEE 802.1Q-compliant protocol that facilitates VLAN registration and controls VLANs within a larger network.
H2QP
Hotspot 2.0 Query Protocol.
hot zone
Wireless access area created by multiple hotspots that are located in close proximity to one another. Hot zones usually combine public safety APs with public hotspots.
hotspot
Hotspot refers to a WLAN node that provides Internet connection and virtual private network (VPN) access from a given location. A business traveler, for example, with a laptop equipped for Wi-Fi can look up a local hotspot, contact it, and get connected through its network to reach the Internet.
ArubaOS 6.5.3.x
| User Guide Glossary of Terms | 1141
HSPA
High-Speed Packet Access.
HT
High Throughput. IEEE 802.11n is an HT WLAN standard that aims to achieve physical data rates of close to
600 Mbps on the 2.4 GHz and 5 GHz bands.
HTTP
Hypertext Transfer Protocol. The HTTP is an application protocol to transfer data over the web. The HTTP protocol defines how messages are formatted and transmitted, and the actions that the w servers and browsers should take in response to various commands.
HTTPS
Hypertext Transfer Protocol Secure. HTTPS is a variant of the HTTP that adds a layer of security on the data in transit through a secure socket layer or transport layer security protocol connection.
IAS
Internet Authentication Service. IAS is a component of Windows Server operating systems that provides centralized user authentication, authorization, and accounting.
ICMP
Internet Control Message Protocol. ICMP is an error reporting protocol. It is used by network devices such as routers, to send error messages and operational information to the source IP address when network problems prevent delivery of IP packets.
IDS
Intrusion Detection System. IDS monitors a network or systems for malicious activity or policy violations and reports its findings to the management system deployed in the network.
IEEE
Institute of Electrical and Electronics Engineers.
IGMP
Internet Group Management Protocol. Communications protocol used by hosts and adjacent routers on IP networks to establish multicast group memberships.
IGMP snooping
IGMP snooping prevents multicast flooding on Layer 2 network by treating multicast traffic as broadcast traffic. Without IGMP snooping, all streams could be flooded to all ports on that VLAN. When multicast flooding occurs, end-hosts that happen to be in the same VLAN would receive all the streams only to be discarded without snooping.
IGP
Interior Gateway Protocol. IGP is used for exchanging routing information between gateways within an autonomous system (for example, a system of corporate local area networks).
IGRP
Interior Gateway Routing Protocol. IGRP is a distance vector interior routing protocol used by routers to exchange routing data within an autonomous system.
IKE
Internet Key Exchange. IKE is a key management protocol used with IPsec protocol to establish a secure communication channel. IKE provides additional feature, flexibility, and ease of configuration for IPsec standard.
1142 | Glossary of Terms ArubaOS 6.5.3.x | User Guide
IKEv1
Internet Key Exchange version 1. IKEv1 establishes a secure authenticated communication channel by using either the pre-shared key (shared secret), digital signatures, or public key encryption. IKEv1 operates in Main and Aggressive modes. See RFC 2409.
IKEv2
Internet Key Exchange version 2. IKEv2 uses the secure channel established in Phase 1 to negotiate Security
Associations on behalf of services such as IPsec. IKEv2 uses pre-shared key and Digital Signature for authentication. See RFC 4306.
IoT
Internet of Things. IoT refers to the internetworking of devices that are embedded with electronics, software, sensors, and network connectivity features allowing data exchange over the Internet.
IPM
Intelligent Power Monitoring. IPM is a feature supported on certain APs that actively measures the power utilization of an AP and dynamically adapts to the power resources.
IPS
Intrusion Prevention System. The IPS monitors a network for malicious activities such as security threats or policy violations. The main function of an IPS is to identify suspicious activity, log the information, attempt to block the activity, and report it.
IPsec
Internet Protocol security. IPsec is a protocol suite for secure IP communications that authenticates and encrypts each IP packet in a communication session.
IPSG
Internet Protocol Source Guard. IPSG restricts IP address from untrusted interface by filtering traffic based on list of addresses in the DHCP binding database or manually configured IP source bindings. It prevents IP spoofing attacks.
IrDA
An industry-sponsored organization set up in 1993 to create international standards for the hardware and software used in infrared communication links. In this special form of radio transmission, a focused ray of light in the infrared frequency spectrum, measured in terahertz (THz), or trillions of hertz (cycles per second), is modulated with information and sent from a transmitter to a receiver over a relatively short distance.
ISAKMP
Internet Security Association and Key Management Protocol. ISAKMP is used for establishing Security
Associations and cryptographic keys in an Internet environment.
ISP
Internet Service Provider. An ISP is an organization that provides services for accessing and using the
Internet.
JSON
JavaScript Object Notation. JSON is an open-standard, language-independent, lightweight data-interchange format used to transmit data objects consisting of attribute–value pairs. JSON uses a "self-describing" text format that is easy for humans to read and write, and that can be used as a data format by any programming language.
Kbps
Kilobits per second.
KBps
Kilobytes per second.
ArubaOS 6.5.3.x
| User Guide Glossary of Terms | 1143
keepalive
Signal sent at periodic intervals from one device to another to verify that the link between the two devices is working. If no reply is received, data will be sent by a different path until the link is restored. A keepalive can also be used to indicate that the connection should be preserved so that the receiving device does not consider it timed out and drop it.
L2TP
Layer-2 Tunneling Protocol. L2TP is a networking protocol used by the ISPs to enable VPN operations.
LACP
Link Aggregation Control Protocol. LACP is used for the collective handling of multiple physical ports that can be seen as a single channel for network traffic purposes.
LAG
Link Aggregation Group . A LAG combines a number of physical ports together to make a single highbandwidth data path. LAGs can connect two switches to provide a higher-bandwidth connection to a public network.
LAN
Local Area Network. A LAN is a network of connected devices within a distinct geographic area such as an office or a commercial establishment and share a common communications line or wireless link to a server.
LCD
Liquid Crystal Display. LCD is the technology used for displays in notebook and other smaller computers. Like
LED and gas-plasma technologies, LCDs allow displays to be much thinner than the cathode ray tube technology.
LDAP
Lightweight Directory Access Protocol. LDAP is a communication protocol that provides the ability to access and maintain distributed directory information services over a network.
LDPC
Low-Density Parity-Check. LDPC is a method of transmitting a message over a noisy transmission channel using a linear error correcting code. An LDPC is constructed using a sparse bipartite graph.
LEAP
Lightweight Extensible Authentication Protocol. LEAP is a Cisco proprietary version of EAP used in wireless networks and Point-to-Point connections.
LED
Light Emitting Diode. LED is a semiconductor light source that emits light when an electric current passes through it.
LEEF
Log Event Extended Format. LEEF is a type of customizable syslog event format. An extended log file contains a sequence of lines containing ASCII characters terminated by either the sequence LF or CRLF.
LI
Lawful Interception. LI refers to the procedure of obtaining communications network data by the Law
Enforcement Agencies for the purpose of analysis or evidence.
LLDP
Link Layer Discovery Protocol. LLDP is a vendor-neutral link layer protocol in the Internet Protocol suite used by network devices for advertising their identity, capabilities, and neighbors on an IEEE 802 local area network, which is principally a wired Ethernet.
1144 | Glossary of Terms ArubaOS 6.5.3.x | User Guide
LLDP-MED
LLDP–Media Endpoint Discovery. LLDP-MED facilitates information sharing between endpoints and network infrastructure devices.
LMS
Local Management Switch. In multi-controller networks, each controller acts as an LMS and terminates user traffic from the APs, processes, and forwards the traffic to the wired network.
LNS
L2TP Network Server. LNS is an equipment that connects to a carrier and handles the sessions from broadband lines. It is also used for dial-up and mobile links. LNS handles authentication and routing of the IP addresses. It also handles the negotiation of the link with the equipment and establishes a session.
LTE
Long Term Evolution. LTE is a 4G wireless communication standard that provides high-speed wireless communication for mobile phones and data terminals. See 4G.
MAB
MAC Authentication Bypass. Endpoints such as network printers, Ethernet-based sensors, cameras, and wireless phones do not support 802.1X authentication. For such endpoints, MAC Authentication Bypass mechanism is used. In this method, the MAC address of the endpoint is used to authenticate the endpoint.
MAC
Media Access Control. A MAC address is a unique identifier assigned to network interfaces for communications on a network.
MAM
Mobile Application Management. MAM refers to software and services used to secure, manage, and distribute mobile applications used in enterprise settings on mobile devices like smartphones and tablet computers. Mobile Application Management can apply to company-owned mobile devices as well as BYOD.
Mbps
Megabits per second
MBps
Megabytes per second
MCS
Modulation and Coding Scheme. MCS is used as a parameter to determine the data rate of a wireless connection for high throughput.
MD4
Message Digest 4. MD4 is an earlier version of MD5 and is an algorithm used to verify data integrity through the creation of a 128-bit message digest from data input.
MD5
Message Digest 5. The MD5 algorithm is a widely used hash function producing a 128-bit hash value from the data input.
MDAC
Microsoft Data Access Components. MDAC is a framework of interrelated Microsoft technologies that provides a standard database for Windows OS.
MDM
Mobile Device Management. MDM is an administrative software to manage, monitor, and secure mobile devices of the employees in a network.
ArubaOS 6.5.3.x
| User Guide Glossary of Terms | 1145
mDNS
Multicast Domain Name System. mDNS provides the ability to perform DNS-like operations on the local link in the absence of any conventional unicast DNS server. The mDNS protocol uses IP multicast User Datagram
Protocol (UDP) packets, and is implemented by the Apple Bonjour and Linux NSS-mDNS services. mDNS works in conjunction with DNS Service Discovery (DNS-SD), a companion zero-configuration technique specified. See RFC 6763.
MFA
Multi-factor Authentication. MFA lets you require multiple factors, or proofs of identity, when authenticating a user. Policy configurations define how often multi-factor authentication will be required, or conditions that will trigger it.
MHz
Megahertz
MIB
Management Information Base. A hierarchical database used by SNMP to manage the devices being monitored.
microwave
Electromagnetic energy with a frequency higher than 1 GHz, corresponding to wavelength shorter than 30 centimeters.
MIMO
Multiple Input Multiple Output. An antenna technology for wireless communications in which multiple antennas are used at both source (transmitter) and destination (receiver). The antennas at each end of the communications circuit are combined to minimize errors and optimize data speed.
MISO
Multiple Input Single Output. An antenna technology for wireless communications in which multiple antennas are used at the source (transmitter). The antennas are combined to minimize errors and optimize data speed.
The destination (receiver) has only one antenna.
MLD
Multicast Listener Discovery. A component of the IPv6 suite. It is used by IPv6 routers for discovering multicast listeners on a directly attached link.
MPDU
MAC Protocol Data Unit. MPDU is a message exchanged between MAC entities in a communication system based on the layered OSI model.
MPLS
Multiprotocol Label Switching. The MPLS protocol speeds up and shapes network traffic flows.
MPPE
Microsoft Point-to-Point Encryption. A method of encrypting data transferred across PPP-based dial-up connections or PPTP-based VPN connections.
MS-CHAP
Microsoft Challenge Handshake Authentication Protocol. MS-CHAP is Password-based, challenge-response, mutual authentication protocol that uses MD4 and DES encryption.
MS-CHAPv1
Microsoft Challenge Handshake Authentication Protocol version 1. MS-CHAPv1 extends the user authentication functionality provided on Windows networks to remote workstations. MS-CHAPv1 supports only one-way authentication.
1146 | Glossary of Terms ArubaOS 6.5.3.x | User Guide
MS-CHAPv2
Microsoft Challenge Handshake Authentication Protocol version 2. MS-CHAPv2 is an enhanced version of the
MS-CHAP protocol that supports mutual authentication.
MSS
Maximum Segment Size. MSS is a parameter of the options field in the TCP header that specifies the largest amount of data, specified in bytes, that a computer or communications device can receive in a single TCP segment.
MSSID
Mesh Service Set Identifier. MSSID is the SSID used by the client to access a wireless mesh network.
MSTP
Multiple Spanning Tree Protocol. MSTP configures a separate Spanning Tree for each VLAN group and blocks all but one of the possible alternate paths within each spanning tree.
MTU
Maximum Transmission Unit. MTU is the largest size packet or frame specified in octets (eight-bit bytes) that can be sent in networks such as the Internet.
MU-MIMO
Multi-User Multiple-Input Multiple-Output. MU-MIMO is a set of multiple-input and multiple-output technologies for wireless communication, in which users or wireless terminals with one or more antennas communicate with each other.
MVRP
Multiple VLAN Registration Protocol. MVRP is a Layer 2 network protocol used for automatic configuration of
VLAN information on switches.
mW milliWatts. mW is 1/1000 of a Watt. It is a linear measurement (always positive) that is generally used to represent transmission.
NAC
Network Access Control. NAC is a computer networking solution that uses a set of protocols to define and implement a policy that describes how devices can secure access to network nodes when they initially attempt to connect to a network.
NAD
Network Access Device. NAD is a device that automatically connects the user to the preferred network, for example, an AP or an Ethernet switch.
NAK
Negative Acknowledgement. NAK is a response indicating that a transmitted message was received with errors or it was corrupted, or that the receiving end is not ready to accept transmissions.
NAP
Network Access Protection. The NAP feature in the Windows Server allows network administrators to define specific levels of network access based on identity, groups, and policy compliance. The NAP Agent is a service that collects and manages health information for NAP client computers. If a client is not compliant, NAP provides a mechanism to automatically bring the client back into compliance and then dynamically increase its level of network access.
NAS
Network Access Server. NAS provides network access to users, such as a wireless AP, network switch, or dialin terminal server.
ArubaOS 6.5.3.x
| User Guide Glossary of Terms | 1147
NAT
Network Address Translation. NAT is a method of remapping one IP address space into another by modifying network address information in Internet Protocol (IP) datagram packet headers while they are in transit across a traffic routing device.
NetBIOS
Network Basic Input/Output System. A program that lets applications on different computers communicate within a LAN.
netmask
Netmask is a 32-bit mask used for segregating IP address into subnets. Netmask defines the class and range of IP addresses.
NFC
Near-Field Communication. NFC is a short-range wireless connectivity standard (ECMA-340, ISO/IEC 18092) that uses magnetic field induction to enable communication between devices when they touch or are brought closer (within a few centimeters of distance). The standard specifies a way for the devices to establish a peerto-peer (P2P) network to exchange data.
NIC
Network Interface Card. NIC is a hardware component that allows a device to connect to the network.
Nmap
Network Mapper. Nmap is an open-source utility for network discovery and security auditing. Nmap uses IP packets to determine such things as the hosts available on a network and their services, operating systems and versions, types of packet filters/firewalls, and so on.
NMI
Non-Maskable Interrupt. NMI is a hardware interrupt that standard interrupt-masking techniques in the system cannot ignore. It typically occurs to signal attention for non-recoverable hardware errors.
NMS
Network Management System. NMS is a set of hardware and/or software tools that allow an IT professional to supervise the individual components of a network within a larger network management framework.
NOE
New Office Environment. NOE is a proprietary VoIP protocol designed by Alcatel-Lucent Enterprise.
NTP
Network Time Protocol. NTP is a protocol for synchronizing the clocks of computers over a network.
OAuth
Open Standard for Authorization. OAuth is a token-based authorization standard that allows websites or thirdparty applications to access user information, without exposing the user credentials.
OCSP
Online Certificate Status Protocol. OCSP is used for determining the current status of a digital certificate without requiring a CRL.
OFDM
Orthogonal Frequency Division Multiplexing. OFDM is a scheme for encoding digital data on multiple carrier frequencies.
OID
Object Identifier. An OID is an identifier used to name an object. The OIDs represent nodes or managed objects in a MIB hierarchy. The OIDs are designated by text strings and integer sequences and are formally defined as per the ASN.1 standard.
1148 | Glossary of Terms ArubaOS 6.5.3.x | User Guide
OKC
Opportunistic Key Caching. OKC is a technique available for authentication between multiple APs in a network where those APs are under common administrative control. Using OKC, a station roaming to any AP in the network will not have to complete a full authentication exchange, but will instead just perform the 4-way handshake to establish transient encryption keys.
onboarding
The process of preparing a device for use on an enterprise network, by creating the appropriate access credentials and setting up the network connection parameters.
OpenFlow
OpenFlow is an open communications interface between control plane and the forwarding layers of a network.
OpenFlow agent
OpenFlow agent. OpenFlow is a software module in Software-Defined Networking (SDN) that allows the abstraction of any legacy network element, so that it can be integrated and managed by the SDN controller.
OpenFlow runs on network devices such as switches, routers, wireless controllers, and APs.
Optical wireless
Optical wireless is combined use of conventional radio frequency wireless and optical fiber for telecommunication. Long-range links are provided by using optical fibers; the links from the long-range endpoints to end users are accomplished by RF wireless or laser systems. RF wireless at Ultra High
Frequencies and microwave frequencies can carry broadband signals to individual computers at substantial data speeds.
OSI
Open Systems Interconnection. OSI is a reference model that defines a framework for communication between the applications in a network.
OSPF
Open Shortest Path First. OSPF is a link-state routing protocol for IP networks. It uses a link-state routing algorithm and falls into the group of interior routing protocols that operates within a single Autonomous
System (AS).
OSPFv2
Open Shortest Path First version 2. OSPFv2 is the version 2 of the link-state routing protocol, OSPF. See RFC
2328.
OUI
Organizationally Unique Identifier. Synonymous with company ID or vendor ID, an OUI is a 24-bit, globally unique assigned number, referenced by various standards. The first half of a MAC address is OUI.
OVA
Open Virtualization Archive. OVA contains a compressed installable version of a virtual machine.
OVF
Open Virtualization Format. OVF is a specification that describes an open-standard, secure, efficient, portable and extensible format for packaging and distributing software for virtual machines.
PAC
Protected Access Credential. PAC is distributed to clients for optimized network authentication. These credentials are used for establishing an authentication tunnel between the client and the authentication server.
ArubaOS 6.5.3.x
| User Guide Glossary of Terms | 1149
PAP
Password Authentication Protocol. PAP validates users by password. PAP does not encrypt passwords for transmission and is thus considered insecure.
PAPI
Process Application Programming Interface. PAPI controls channels for ARM and Wireless Intrusion Detection
System (WIDS) communication to the master controller. A separate PAPI control channel connects to the local controller where the SSID tunnels terminate.
PBR
Policy-based Routing. PBR provides a flexible mechanism for forwarding data packets based on polices configured by a network administrator.
PDU
Power Distribution Unit or Protocol Data Unit. Power Distribution Unit is a device that distributes electric power to the networking equipment located within a data center. Protocol Data Unit contains protocol control
Information that is delivered as a unit among peer entities of a network.
PEAP
Protected Extensible Authentication Protocol. PEAP is a type of EAP communication that addresses security issues associated with clear text EAP transmissions by creating a secure channel encrypted and protected by
TLS.
PEF
Policy Enforcement Firewall. PEF provides context-based controls to enforce application-layer security and prioritization.
PFS
Perfect Forward Secrecy. PFS refers to the condition in which a current session key or long-term private key does not compromise the past or subsequent keys.
PHB
Per-hop behavior. PHB is a term used in DS or MPLS. It defines the policy and priority applied to a packet when traversing a hop (such as a router) in a DiffServ network.
PIM
Protocol-Independent Multicast. PIM refers to a family of multicast routing protocols for IP networks that provide one-to-many and many-to-many distribution of data over a LAN, WAN, or the Internet.
PIN
Personal Identification Number. PIN is a numeric password used to authenticate a user to a system.
PKCS#n
Public-key cryptography standard n. PKCS#n refers to a numbered standard related to topics in cryptography, including private keys (PKCS#1), digital certificates (PKCS#7), certificate signing requests (PKCS#10), and secure storage of keys and certificates (PKCS#12).
PKI
Public Key Infrastructure. PKI is a security technology based on digital certificates and the assurances provided by strong cryptography. See also certificate authority, digital certificate, public key, private key.
PLMN
Public Land Mobile Network. PLMS is a network established and operated by an administration or by a
Recognized Operating Agency for the specific purpose of providing land mobile telecommunications services to the public.
1150 | Glossary of Terms ArubaOS 6.5.3.x | User Guide
PMK
Pairwise Master Key. PMK is a shared secret key that is generated after PSK or 802.1X authentication.
PoE
Power over Ethernet. PoE is a technology for wired Ethernet LANs to carry electric power required for the device in the data cables. The IEEE 802.3af PoE standard provides up to 15.4 W of power on each port.
PoE+
Power over Ethernet+. PoE+ is an IEEE 802.3at standard that provides 25.5W power on each port.
POST
Power On Self Test. An HTTP request method that requests data from a specified resource.
PPP
Point-to-Point Protocol. PPP is a data link (layer 2) protocol used to establish a direct connection between two nodes. It can provide connection authentication, transmission encryption, and compression.
PPPoE
Point-to-Point Protocol over Ethernet. PPPoE is a method of connecting to the Internet, typically used with DSL services, where the client connects to the DSL modem.
PPTP
Point-to-Point Tunneling Protocol. PPTP is a method for implementing virtual private networks. It uses a control channel over TCP and a GRE tunnel operating to encapsulate PPP packets.
private key
The part of a public-private key pair that is always kept private. The private key encrypts the signature of a message to authenticate the sender. The private key also decrypts a message that was encrypted with the public key of the sender.
PRNG
Pseudo-Random Number Generator. PRNG is an algorithm for generating a sequence of numbers whose properties approximate the properties of sequences of random numbers.
PSK
Pre-shared key. A unique shared secret that was previously shared between two parties by using a secure channel. This is used with WPA security, which requires the owner of a network to provide a passphrase to users for network access.
PSU
Power Supply Unit. PSU is a unit that supplies power to an equipment by converting mains AC to low-voltage regulated DC power.
public key
The part of a public-private key pair that is made public. The public key encrypts a message and the message is decrypted with the private key of the recipient.
PVST
Per-VLAN Spanning Tree. PVST provides load balancing of VLANs across multiple ports resulting in optimal usage of network resources.
PVST+
Per-VLAN Spanning Tree+. PVST+ is an extension of the PVST standard that uses the 802.1Q trunking technology.
QoS
Quality of Service. It refers to the capability of a network to provide better service and performance to a specific network traffic over various technologies.
ArubaOS 6.5.3.x
| User Guide Glossary of Terms | 1151
RA
Router Advertisement. The RA messages are sent by the routers in the network when the hosts send multicast router solicitation to the multicast address of all routers.
RADAR
Radio Detection and Ranging. RADAR is an object-detection system that uses radio waves to determine the range, angle, or velocity of objects.
RADIUS
Remote Authentication Dial-In User Service. An Industry-standard network access protocol for remote authentication. It allows authentication, authorization, and accounting of remote users who want to access network resources.
RAM
Random Access Memory.
RAPIDS
Rogue Access Point identification and Detection System. An AMP module that is designed to identify and locate wireless threats by making use of all of the information available from your existing infrastructure.
RARP
Reverse Address Resolution Protocol. RARP is a protocol used by a physical machine in a local area network for determining the IP address from the ARP table or cache of the gateway server.
Regex
Regular Expression. Regex refers to a sequence of symbols and characters defining a search pattern.
Registration Authority
Type of Certificate Authority that processes certificate requests. The Registration Authority verifies that requests are valid and comply with certificate policy, and authenticates the user's identity. The Registration
Authority then forwards the request to the Certificate Authority to sign and issue the certificate.
Remote AP
Remote AP. Remote AP extends the corporate network to users working from home, or at temporary work sites.
REST
Representational State Transfer. REST is a simple and stateless architecture that the web services use for providing interoperability between computer systems on the Internet. In a RESTful web service, requests made to the URI of a resource will elicit a response that may be in XML, HTML, JSON or some other defined format.
RF
Radio Frequency. RF refers to the electromagnetic wave frequencies within a range of 3 kHz to 300 GHz, including the frequencies used for communications or RADAR signals.
RFC
Request For Comments. RFC is a commonly used format for the Internet standards documentss.
RFID
Radio Frequency Identification. RFID uses radio waves to automatically identify and track the information stored on a tag attached to an object.
RIP
Routing Information Protocol. RIP prevents the routing loops by limiting the number of hops allowed in a path from source to destination.
1152 | Glossary of Terms ArubaOS 6.5.3.x | User Guide
RJ45
Registered Jack 45. RJ45 is a physical connector for network cables.
RMON
Remote Monitoring. RMON provides standard information that a network administrator can use to monitor, analyze, and troubleshoot a group of distributed LANs.
RoW
Rest of World. RoW or RW is an operating country code of a device.
RSA
Rivest, Shamir, Adleman. RSA is a cryptosystem for public-key encryption, and is widely used for securing sensitive data, particularly when being sent over an insecure network such as the Internet.
RSSI
Received Signal Strength Indicator. RSSI is a mechanism by which RF energy is measured by the circuitry on a wireless NIC (0-255). The RSSI is not standard across vendors. Each vendor determines its own RSSI scale/values.
RSTP
Rapid Spanning Tree Protocol. RSTP provides significantly faster spanning tree convergence after a topology change, introducing new convergence behaviors and bridge port roles to do this.
RTCP
RTP Control Protocol. RTCP provides out-of-band statistics and control information for an Real-Time Transport
Protocol session.
RTLS
Real-Time Location Systems. RTLS automatically identifies and tracks the location of objects or people in real time, usually within a building or other contained area.
RTP
Real-Time Transport Protocol. RTP is a network protocol used for delivering audio and video over IP networks.
RTS
Request to Send. RTS refers to the data transmission and protection mechanism used by the 802.11 wireless networking protocol to prevent frame collision occurrences. See CTS.
RTSP
Real Time Streaming Protocol. RTSP is a network control protocol designed for use in entertainment and communications systems to control streaming media servers.
RVI
Routed VLAN Interface. RVI is a switch interface that forwards packets between VLANs.
RW
Rest of World. RoW or RW is an operating country code of a device.
SA
Security Association. SA is the establishment of shared security attributes between two network entities to support secure communication.
SAML
Security Assertion Markup Language. SAML is an XML-based framework for communicating user authentication, entitlement, and attribute information. SAML enables single sign-on by allowing users to authenticate at an identity provider and then access service providers without additional authentication.
ArubaOS 6.5.3.x
| User Guide Glossary of Terms | 1153
SCEP
Simple Certificate Enrollment Protocol. SCEP is a protocol for requesting and managing digital certificates.
SCP
Secure Copy Protocol. SCP is a network protocol that supports file transfers between hosts on a network.
SCSI
Small Computer System Interface. SCSI refers to a set of interface standards for physical connection and data transfer between a computer and the peripheral devices such as printers, disk drives, CD-ROM, and so on.
SDN
Software-Defined Networking. SDN is an umbrella term encompassing several kinds of network technology aimed at making the network as agile and flexible as the virtualized server and storage infrastructure of the modern data center.
SDR
Server Derivation Rule. An SDR refers to a role assignment model used by the controllers running ArubaOS to assign roles and VLANs to the WLAN users based on the rules defined under a server group. The SDRs override the default authentication roles and VLANs defined in the AAA and Virtual AP profiles.
SDU
Service Data Unit. SDU is a unit of data that has been passed down from an OSI layer to a lower layer and that has not yet been encapsulated into a PDU by the lower layer.
SD-WAN
Software-Defined Wide Area Network. SD-WAN is an application for applying SDN technology to WAN connections that connect enterprise networks across disparate geographical locations.
SFP
The Small Form-factor Pluggable. SFP is a compact, hot-pluggable transceiver that is used for both telecommunication and data communications applications.
SFP+
Small Form-factor Pluggable+. SFP+ supports up to data rates up to 16 Gbps.
SFTP
Secure File Transfer Protocol. SFTP is a network protocol that allows file access, file transfer, and file management functions over a secure connection.
SHA
Secure Hash Algorithm. SHA is a family of cryptographic hash functions. The SHA algorithm includes the SHA,
SHA-1, SHA-2 and SHA-3 variants.
SIM
Subscriber Identity Module. SIM is an integrated circuit that is intended to securely store the International
Mobile Subscriber Identity (IMSI) number and its related key, which are used for identifying and authenticating subscribers on mobile telephony devices.
SIP
Session Initiation Protocol. SIP is used for signaling and controlling multimedia communication session such as voice and video calls.
SIRT
Security Incident Response Team. SIRT is responsible for reviewing as well as responding to computer security incident reports and activity.
SKU
Stock Keeping Unit. SKU refers to the product and service identification code for the products in the inventory.
1154 | Glossary of Terms ArubaOS 6.5.3.x | User Guide
SLAAC
Stateless Address Autoconfiguration. SLAAC provides the ability to address a host based on a network prefix that is advertised from a local network router through router advertisements.
SMB
Server Message Block or Small and Medium Business. Server Message Block operates as an applicationlayer network protocol mainly used for providing shared access to files, printers, serial ports, and for miscellaneous communications between the nodes on a network.
SMS
Short Message Service. SMS refers to short text messages (up to 140 characters) sent and received through mobile phones.
SMTP
Simple Mail Transfer Protocol. SMTP is an Internet standard protocol for electronic mail transmission.
SNIR
Signal-to-Noise-Plus-Interference Ratio. SNIR refers to the power of a central signal of interest divided by the sum of the interference power and the power of the background noise. SINR is defined as the power of a certain signal of interest divided by the sum of the interference power (from all the other interfering signals) and the power of some background noise.
SNMP
Simple Network Management Protocol. SNMP is a TCP/IP standard protocol for managing devices on IP networks. Devices that typically support SNMP include routers, switches, servers, workstations, printers, modem racks, and more. It is used mostly in network management systems to monitor network-attached devices for conditions that warrant administrative attention.
SNMPv1
Simple Network Management Protocol version 1. SNMPv1 is a widely used network management protocol.
SNMPv2
Simple Network Management Protocol version 2. SNMPv2 is an enhanced version of SNMPv1, which includes improvements in the areas of performance, security, confidentiality, and manager-to-manager communications.
SNMPv2c
Community-Based Simple Network Management Protocol version 2. SNMPv2C uses the community-based security scheme of SNMPv1 and does not include the SNMPv2 security model.
SNMPv3
Simple Network Management Protocol version 3. SNMPv3 is an enhanced version of SNMP that includes security and remote configuration features.
SNR
Signal-to-Noise Ratio. SNR is used for comparing the level of a desired signal with the level of background noise.
SNTP
Simple Network Time Protocol. SNTP is a less complex implementation of NTP. It uses the same , but does not require the storage of state over extended periods of time.
SOAP
Simple Object Access Protocol. SOAP enables communication between the applications running on different operating systems, with different technologies and programming languages. SOAP is an XML-based messaging protocol for exchanging structured information between the systems that support web services.
ArubaOS 6.5.3.x
| User Guide Glossary of Terms | 1155
SoC
System on a Chip. SoC is an Integrated Circuit that integrates all components of a computer or other electronic system into a single chip.
source NAT
Source NAT changes the source address of the packets passing through the router. Source NAT is typically used when an internal (private) host initiates a session to an external (public) host.
SSH
Secure Shell. SSH is a network protocol that provides secure access to a remote device.
SSID
Service Set Identifier. SSID is a name given to a WLAN and is used by the client to access a WLAN network.
SSL
Secure Sockets Layer. SSL is a computer networking protocol for securing connections between network application clients and servers over the Internet.
SSO
Single Sign-On. SSO is an access-control property that allows the users to log in once to access multiple related, but independent applications or systems to which they have privileges. The process authenticates the user across all allowed resources during their session, eliminating additional login prompts.
STBC
Space-Time Block Coding. STBC is a technique used in wireless communications to transmit multiple copies of a data stream across a number of antennas and to exploit the various received versions of the data to improve the reliability of data transfer.
STM
Station Management. STM is a process that handles AP management and user association.
STP
Spanning Tree Protocol. STP is a network protocol that builds a logical loop-free topology for Ethernet networks.
subnet
Subnet is the logical division of an IP network.
subscription
A business model where a customer pays a certain amount as subscription price to obtain access to a product or service.
SU-MIMO
Single-User Multiple-Input Multiple-Output. SU-MIMO allocates the full bandwidth of the AP to a single highspeed device during the allotted time slice.
SVP
SpectraLink Voice Priority. SVP is an open, straightforward QoS approach that has been adopted by most leading vendors of WLAN APs. SVP favors isochronous voice packets over asynchronous data packets when contending for the wireless medium and when transmitting packets onto the wired LAN.
SWAN
Structured Wireless-Aware Network. A technology that incorporates a Wireless Local Area Network (WLAN) into a wired Wide Area Network (WAN). SWAN technology can enable an existing wired network to serve hundreds of users, organizations, corporations, or agencies over a large geographic area. SWAN is said to be scalable, secure, and reliable.
1156 | Glossary of Terms ArubaOS 6.5.3.x | User Guide
TAC
Technical Assistance Center.
TACACS
Terminal Access Controller Access Control System. TACACS is a family of protocols that handles remote authentication and related services for network access control through a centralized server.
TACACS+
Terminal Access Controller Access Control System+. TACACS+ provides separate authentication, authorization, and accounting services. It is derived from, but not backward compatible with, TACACS.
TCP
Transmission Control Protocol. TCP is a communication protocol that defines the standards for establishing and maintaining network connection for applications to exchange data.
TCP/IP
Transmission Control Protocol/ Internet Protocol. TCP/IP is the basic communication language or protocol of the Internet.
TFTP
Trivial File Transfer Protocol. The TFTP is a software utility for transferring files from or to a remote host.
TIM
Traffic Indication Map. TIM is an information element that advertises if any associated stations have buffered unicast frames. APs periodically send the TIM within a beacon to identify the stations that are using power saving mode and the stations that have undelivered data buffered on the AP.
TKIP
Temporal Key Integrity Protocol. A part of the WPA encryption standard for wireless networks. TKIP is the nextgeneration Wired Equivalent Privacy (WEP) that provides per-packet key mixing to address the flaws encountered in the WEP standard.
TLS
Transport Layer Security. TLS is a cryptographic protocol that provides communication security over the
Internet. TLS encrypts the segments of network connections above the Transport Layer by using asymmetric cryptography for key exchange, symmetric encryption for privacy, and message authentication codes for message integrity.
TLV
Type-length-value or Tag-Length-Value. TLV is an encoding format. It refers to the type of data being processed, the length of the value, and the value for the type of data being processed.
ToS
Type of Service. The ToS field is part of the IPv4 header, which specifies datagrams priority and requests a route for low-delay, high-throughput, or a highly reliable service.
TPC
Transmit Power Control. TPC is a part of the 802.11h amendment. It is used to regulate the power levels used by 802.11a radio cards.
TPM
Trusted Platform Module. TPM is an international standard for a secure cryptoprocessor, which is a dedicated microcontroller designed to secure hardware by integrating cryptographic keys into devices.
TSF
Timing Synchronization Function. TSF is a WLAN function that is used for synchronizing the timers for all the stations in a BSS.
ArubaOS 6.5.3.x
| User Guide Glossary of Terms | 1157
TSPEC
Traffic Specification. TSPEC allows an 802.11e client or a QoS-capable wireless client to signal its traffic requirements to the AP.
TSV
Tab-Separated Values. TSV is a file format that allows the exchange of tabular data between applications that use different internal data formats.
TTL
Time to Live. TTL or hop limit is a mechanism that sets limits for data expiry in a computer or network.
TTY
TeleTypeWriter. TTY-enabled devices allow telephones to transmit text communications for people who are deaf or hard of hearing as well as transmit voice communication.
TXOP
Transmission Opportunity. TXOP is used in wireless networks supporting the IEEE 802.11e Quality of Service
(QoS) standard. Used in both EDCA and HCF Controlled Channel Access modes of operation, TXOP is a bounded time interval in which stations supporting QoS are permitted to transfer a series of frames. TXOP is defined by a start time and a maximum duration.
UAM
Universal Access Method. UAM allows subscribers to access a wireless network after they successfully log in from a web browser.
U-APSD
Unscheduled Automatic Power Save Delivery. U-APSD is a part of 802.11e and helps considerably in increasing the battery life of VoWLAN terminals.
UCC
Unified Communications and Collaboration. UCC is a term used to describe the integration of various communications methods with collaboration tools such as virtual whiteboards, real-time audio and video conferencing, and enhanced call control capabilities.
UDID
Unique Device Identifier. UDID is used to identify an iOS device.
UDP
User Datagram Protocol. UDP is a part of the TCP/IP family of protocols used for data transfer. UDP is typically used for streaming media. UDP is a stateless protocol, which means it does not acknowledge that the packets being sent have been received.
UDR
User Derivation Rule. UDR is a role assignment model used by the controllers running ArubaOS to assign roles and VLANs to the WLAN users based on MAC address, BSSID, DHCP-Option, encryption type, SSID, and the location of a user. For example, for an SSID with captive portal in the initial role, a UDR can be configured for scanners to provide a role based on their MAC OUI.
UHF
Ultra high frequency. UHF refers to radio frequencies between the range of 300 MHz and 3 GHz. UHF is also known as the decimeter band as the wavelengths range from one meter to one decimeter.
UI
User Interface.
1158 | Glossary of Terms ArubaOS 6.5.3.x | User Guide
UMTS
Universal Mobile Telecommunication System. UMTS is a third generation mobile cellular system for networks.
See 3G.
UPnP
Universal Plug and Play. UPnp is a set of networking protocols that permits networked devices, such as personal computers, printers, Internet gateways, Wi-Fi APs, and mobile devices to seamlessly discover each other's presence on the network and establish functional network services for data sharing, communications, and entertainment.
URI
Uniform Resource Identifier. URI identifies the name and the location of a resource in a uniform format.
URL
Uniform Resource Locator. URL is a global address used for locating web resources on the Internet.
USB
Universal Serial Bus. USB is a connection standard that offers a common interface for communication between the external devices and a computer. USB is the most common port used in the client devices.
UTC
Coordinated Universal Time. UTC is the primary time standard by which the world regulates clocks and time.
UWB
Ultra-Wideband. UWB is a wireless technology for transmitting large amounts of digital data over a wide spectrum of frequency bands with very low power for a short distance.
VA
Virtual Appliance. VA is a pre-configured virtual machine image, ready to run on a hypervisor.
VBR
Virtual Beacon Report. VBR displays a report with the MAC address details and RSSI information of an AP.
VHT
Very High Throughput. IEEE 802.11ac is an emerging VHT WLAN standard that could achieve physical data rates of close to 7 Gbps for the 5 GHz band.
VIA
Virtual Intranet Access. VIA provides secure remote network connectivity for Android, Apple iOS, Mac OS X, and Windows mobile devices and laptops. It automatically scans and selects the best secure connection to the corporate network.
VLAN
Virtual Local Area Network. In computer networking, a single Layer 2 network may be partitioned to create multiple distinct broadcast domains, which are mutually isolated so that packets can only pass between them through one or more routers; such a domain is referred to as a Virtual Local Area Network, Virtual LAN, or
VLAN.
VM
Virtual Machine. A VM is an emulation of a computer system. VMs are based on computer architectures and provide functionality of a physical computer.
VoIP
Voice over IP. VoIP allows transmission of voice and multimedia content over an IP network.
VoWLAN
Voice over WLAN. VoWLAN is a method of routing telephone calls for mobile users over the Internet using the technology specified in IEEE 802.11b. Routing mobile calls over the Internet makes them free, or at least much
ArubaOS 6.5.3.x
| User Guide Glossary of Terms | 1159
less expensive than they would be otherwise.
VPN
Virtual Private Network. VPN enables secure access to a corporate network when located remotely. It enables a computer to send and receive data across shared or public networks as if it were directly connected to the private network, while benefiting from the functionality, security, and management policies of the private network. This is done by establishing a virtual point-to-point connection through the use of dedicated connections, encryption, or a combination of the two.
VRD
Validated Reference Design. VRDs are guides that capture the best practices for a particular technology in field.
VRF
VisualRF. VRF is an AirWave Management Platform (AMP) module that provides a real-time, network-wide views of your entire Radio Frequency environment along with floor plan editing capabilities. VRF also includes overlays on client health to help diagnose issues related to clients, floor plan, or a specific location.
VRF Plan
VisualRF Plan. A stand-alone Windows client used for basic planning procedures such as adding a floor plan, provisioning APs, and generating a Bill of Materials report.
VRRP
Virtual Router Redundancy Protocol. VRRP is an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN.
VSA
Vendor-Specific Attribute. VSA is a method for communicating vendor-specific information between NASs and
RADIUS servers.
VTP
VLAN Trunking Protocol. VTP is a Cisco proprietary protocol for propagating VLANs on a LAN.
walled garden walled garden is feature that allows blocking of unauthorized users from accessing network resources.
WAN
Wide Area Network. WAN is a telecommunications network or computer network that extends over a large geographical distance.
WASP
Wireless Application Service Provider. WASP provides a web-based access to applications and services that would otherwise have to be stored locally and makes it possible for customers to access the service from a variety of wireless devices, such as a smartphone or Personal Digital Assistant (PDA).
WAX
Wireless abstract XML. WAX is an abstract markup language and a set of tools that is designed to help wireless application development as well as portability. Its tags perform at a higher level of abstraction than that of other wireless markup languages such as HTML, HDML, WML, XSL, and more.
W-CDMA
Wideband Code-Division Multiple Access. W-CDMA is a third-generation (3G) mobile wireless technology that promises much higher data speeds to mobile and portable wireless devices.
web service
Web services allow businesses to share and process data programmatically. Developers who want to provide integrated applications can use the API to programmatically perform actions that would otherwise require
1160 | Glossary of Terms ArubaOS 6.5.3.x | User Guide
manual operation of the user interface.
WEP
Wired Equivalent Privacy. WEP is a security protocol that is specified in 802.11b and is designed to provide a
WLAN with a level of security and privacy comparable to what is usually expected of a wired LAN.
WFA
Wi-Fi Alliance. WFA is a non-profit organization that promotes Wi-Fi technology and certifies Wi-Fi products if they conform to certain standards of interoperability.
WIDS
Wireless Intrusion Detection System. WIDS is an application that detects the attacks on a wireless network or wireless system.
Wi-Fi
Wi-Fi is a technology that allows electronic devices to connect to a WLAN network, mainly using the 2.4 GHz and 5 GHz radio bands. Wi-Fi can apply to products that use any 802.11 standard.
WiMAX
Worldwide Interoperability for Microwave Access. WiMAX refers to the implementation of IEEE 802.16 family of wireless networks standards set by the WiMAX forum.
WIP
Wireless Intrusion Protection. The WIP module provides wired and wireless AP detection, classification, and containment. It detects Denial of Service (DoS) and impersonation attacks, and prevents client and network intrusions.
WIPS
Wireless Intrusion Prevention System. WIPS is a dedicated security device or integrated software application that monitors the radio spectrum of WLAN network for rogue APs and other wireless threats.
WISP
Wireless Internet Service Provider. WISP allows subscribers to connect to a server at designated hotspots using a wireless connection such as Wi-Fi. This type of ISP offers broadband service and allows subscriber computers called stations, to access the Internet and the web from anywhere within the zone of coverage provided by the server antenna, usually a region with a radius of several kilometers.
WISPr
Wireless Internet Service Provider Roaming. The WISPr framework enables the client devices to roam between the wireless hotspots using different ISPs.
WLAN
Wireless Local Area Network. WLAN is a 802.11 standards-based LAN that the users access through a wireless connection.
WME
Wireless Multimedia Extension. WME is a Wi-Fi Alliance interoperability certification, based on the IEEE
802.11e standard. It provides basic QoS features to IEEE 802.11 networks. WMM prioritizes traffic according to four ACs: voice (AC_VO), video (AC_VI), best effort (AC_BE) and background (AC_BK). See WMM.
WMI
Windows Management Instrumentation. WMI consists of a set of extensions to the Windows Driver Model that provides an operating system interface through which instrumented components provide information and notification.
ArubaOS 6.5.3.x
| User Guide Glossary of Terms | 1161
WMM
Wi-Fi Multimedia. WMM is also known as WME. It refers to a Wi-Fi Alliance interoperability certification, based on the IEEE 802.11e standard. It provides basic QoS features to IEEE 802.11 networks. WMM prioritizes traffic according to four ACs: voice (AC_VO), video (AC_VI), best effort (AC_BE), and background (AC_BK).
WPA
Wi-Fi Protected Access. WPA is an interoperable wireless security specification subset of the IEEE 802.11
standard. This standard provides authentication capabilities and uses TKIP for data encryption.
WPA2
Wi-Fi Protected Access 2. WPA2 is a certification program maintained by IEEE that oversees standards for security over wireless networks. WPA2 supports IEEE 802.1X/EAP authentication or PSK technology, but includes advanced encryption mechanism using CCMP that is referred to as AES.
WSDL
Web Service Description Language. WSDL is an XML-based interface definition language used to describe the functionality provided by a web service.
WSP
Wireless Service Provider. The service provider company that offers transmission services to users of wireless devices through Radio Frequency (RF) signals rather than through end-to-end wire communication.
WWW
World Wide Web.
X.509
X.509 is a standard for a public key infrastructure for managing digital certificates and public-key encryption.
It is an essential part of the Transport Layer Security protocol used to secure web and email communication.
XAuth
Extended Authentication. XAuth provides a mechanism for requesting individual authentication information from the user, and a local user database or an external authentication server. It provides a method for storing the authentication information centrally in the local network.
XML
Extensible Markup Language. XML is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable.
XML-RPC
XML Remote Procedure Call. XML-RPC is a protocol that uses XML to encode its calls and HTTP as a transport mechanism. Developers who want to provide integrated applications can use the API to programmatically perform actions that would otherwise require manual operation of the user interface.
ZTP
Zero Touch Provisioning. ZTP is a device provisioning mechanism that allows automatic and quick provisioning of devices with a minimal or at times no manual intervention.
1162 | Glossary of Terms ArubaOS 6.5.3.x | User Guide
advertisement
Related manuals
advertisement