Module - 1 Introduction

This module covers the advantages of IAPs, explains the need of the virtual controller (VC) and clusters. Reviews Instant hardware platforms and features.

 

Module - 2 Aruba Install

This module explores the three methods of installing IAP networks: Instant, Activate with Airwave and Aruba Central. This module also demonstrates the Instant installation method.

 

Module - 3 UI Monitoring

Learn to monitor Wlans, IAPs and Clients with the GUI and CLI demonstrations.

 

Module - 4 Managing IAPS

Explains the procedure for IAPs joining a cluster and the election process for the Virtual Controller. Uplink choices are described. Includes a demonstration of the VC and IAP naming configuration.

 

Module - 5 WLAN Authentication

Explores authentication methods such as 802.1x, Guest access, Mac authentication. Also discusses EAP termination. Includes a configuration methods demonstration.

 

Module - 6 Firewall

Discusses the IAP Statefull firewall along with roles and rules. Firewall extended actions and methods of applying them to a Wlan or doing Role derivation with VSAs is described. Includes a firewall application demonstration.

 

Module - 7 Captive Portal

How captive portal is invoked and the choices in using internal or external captive portals is explored. Includes a captive portal configuration demonstration.

 

Module - 8 ARM

ARM calibration and features in the IAP network such as load aware, voice aware and others are described. Explains how to invoke the spectrum analyzer. Demonstrates RF settings, ARM commands and spectrum analyzer.

 

Module - 9 Mesh

Mesh terminology and setup in a cluster is explained. An IAP joining as a mesh point and mesh commands are demonstrated.

 

Module - 10 Wired Access

Discusses IAP wired capabilities including configuration of a wired port as an access or trunk, and wired authentication with 802.1x or captive portal. Includes how to apply firewall roles. Demonstrates how to configure a wired access port.

 

Module - 11 VPN

IAP wired capabilities including configuration of a wired port as an access or trunk, and wired authentication with 802.1x or captive portal. Includes how to apply firewall roles & configure a wired access port.

 

Module - 12 WIP

This module explores the IAPs rogue detection and classification methods. It also discusses configuration options for intrusion detection and protection. A demonstration of WIP configuration is also provided.

 

Module - 13 Roaming

Cluster roaming is explained along with a detailed explanation of inter cluster roaming. Automatic or manual creation of Home Agent Tables is explored. A demonstration of the roaming configuration is also given.

 

Module - 14 AirGroup

The basics of the Bonjour protocol is explained and how to configure AirGroup with AirPlay or AirPrint. A demonstration of the configuration and a server joining and advertising is included.

 

Module - 15 MAS Integration

MAS POE prioritization for the IAP, coordination of Rogue containment and the GVRP capabilities with VLAN self registration. Includes a IAP configuration demonstration.

 

Module - 16 Hotspots

A basic explanation of 802.11u and hotspot 2.0 is given. Also explains the IAP configuration to advertise and integrate with other 3G/4G or WiFi networks.

 

Module - 17 Administrative Tasks

Discusses Open DNS, firmware upgrades, backup and restore, configuration purge and conversion to CAPs. Demonstrations are included.

 

 

Version History
Revision #:
7 of 7
Last update:
‎06-06-2016 11:34 AM
Updated by:
 
Labels (1)

**PLEASE NOTE: This articles assumes that all devices are already added to Airwave successfully with valid SNMP credentials and are NOT in the "New Devices" list.

 

If you are monitoring your Aruba Controller Network with Airwave, you SHOULD always have AMON turned on.  Here's why:

 

 

- Spectrum information, like discovered non-wifi interferring devices is only transmitted to Airwave over Amon:

interferring.PNG

*Spectrum Information requires that access points are put into Spectrum Mode or Hybrid Spectrum Mode.  Spectrum Analysis requires the RFProtect License http://www.arubanetworks.com/assets/ds/DS_AOS_RFPROTECT.pdf  Also it is advised to only run hybrid spectrum mode during active troubleshooting.. 

 

- Access Point Channel Utilization information like Channel Busy, Interference, Receiving and Transmission time is only transmitted to Airwave over Amon: (search for access point> click on radio and you should see this graph).

utilization.PNG

 

- Client statistics like goodput and client association rate (speed) is only transmitted over Amon. This also allows the latest versions of Airwave to present RF performance statistics by folder.  (in Airwave, click on Home> RF performance to see this graph).

rf-performance.PNG
- Clients associating and leaving the user table are updated to Airwave more frequently via AMON vs. every 5 or 10 minutes via SNMP polling.  In ArubaOS 6.2 and above you can also observe how frquently the station statistics are sent. with the "show mgmt-server message-counters process wms" command.  You will see less lag between when a client associates and when it shows up in Airwave.

 

 

 

 

Okay.  So how do you configure Amon?

 

1.  Configure your Aruba Controller to send Amon statistics to an Airwave server using the "mgmt-server type amp primary <ip address of Airwave Server>" command on the commandline (6.3.0.1 ONLY).

 

EDIT:  Please note, that as of ArubaOS 6.3.1.0 the format of that command has changed and now you have to define a mgmt-server profile first to send that information to airwave:  You need to define a profile, configure what type of stats you want sent and then turn it on:

 

(3600Controller) config t

(3600Controller) (config)mgmt-server profile default-amp <----------Define Profile

(3600Controller) (Mgmt Config profile "default-amp") #?
clone Copy data from another Mgmt Config profile
location-enable Station RSSI/AP Neighbours enable  <----  Send Location Info
misc-enable AP System Stats/Spec Dev/Station Steer Info enable   <------- Send ClientMatch Stats
monitored-info-enable Monitored AP/Station Info enable  <------  AP Station Info
monitored-stats-enable Monitored AP/Station Stats enable <----------  AP Station Stats
no Delete Command
sessions-enable Firewall DNA/App/Aggregate Sessions enable  <----------  Send Firewall Data
stats-enable Radio/VAP/Station Stats enable  <-------  Send AP radio Info
tag-enable Tag enable 
voiceinfo-enable Voice Call Record enable

(3600Controller) (Mgmt Config profile "default-amp") #stats-enable
(3600Controller) (Mgmt Config profile "default-amp") #sessions-enable
(3600Controller) (Mgmt Config profile "default-amp") #misc-enable
(3600Controller) (Mgmt Config profile "default-amp") #location-enable

(3600Controller) (config) mgmt-server type amp primary-server 192.168.1.6 profile default-amp  <------Set the server and attach the profile

 

2. On the Airwave  Under AMP Setup> General> Additional AMP Services, make sure the "Enable AMON Data Collection:" option has a Yes radio button selected next to it.

 

3.  Make sure that if you have a firewall between your controllers and your Airwave Server you are allowing the PAPI protocol or UDP 8211 in both directions between them.

 

 

In addition, in ArubaOS 6.3 if you enable Application Visibility on the controller (config t firewall-visibility) and you are running Airwave 7.7 and above, you will also be able to visualize application traffic in realtime, as weill as historically in Airwave:

pef.png

 

Last but not least, in Airwave 7.7.0 and above, under AMP Setup> General > Additional AMP Options you need to enable the following options:

amp-general.png

 

 

More information on additional settings to get the most out of Airwave is in the AMP AirWave and Aruba Best Practices guide on the support site here:

 

Airwave Documentation

 

 

 

 

Version History
Revision #:
11 of 11
Last update:
‎11-12-2015 10:01 PM
Updated by:
 
Labels (1)
Contributors

The second part of this tutorial will discuss the use of placeholders and variables.

 

Placeholders

 

Placeholders are a convenient method to parametrize commands sent to a controller. By default, placeholder definitions are read from a file named:

"placeholders" or "placeholders.txt". 

You can change the default by using the command line option:

--placeholders <placeholders-file>

 

The placeholders file is a simple text file with a single placeholder specification per line. A placeholder specification takes the form: 

<placeholder>=<value1>,<value2>,...

 

For example:

apname=AP1,AP2

 

A placeholder is later referenced in the commands file by using the following syntax: ${<placeholdername>}. For each placeholder value, AirRecorder will run the specified command with the "${<placeholdername>}” string replaced with its corresponding value.

 

For example, consider an entry like this in your commands file:

0,show ap active ap-name ${apname}

 

and AirRecorder would run two commands once each:

show ap active ap-name AP1

show ap active ap-name AP2

 

NOTE: a placeholder definition can be spread over multiple lines by escaping the end of line with a \

apname3=\

AP6,\

AP7

 

 

Variables

 

Variables offer an additional flexible way of parametrising commands sent to a controller. Whereas placeholders use a predefined set of values, variables work with data that is fetched from the controller at runtime. For example, to run a command for every AP on the controller, one would use the variable: %{ap:name}. 

Out of the box, AirRecorder comes with a pre-defined list of variables:

 

%{ap:name} => all AP names as listed by "show ap active", column Name

%{ap:group} => all AP group names as listed by "show ap active", column Group

%{ap-group:name} => all AP group names as listed by "show ap-group", column Name

%{user:ip} => all IP addresses as listed by "show user-table", column IP

%{user:mac => all MAC addresses as listed by "show user-table", column MAC

%{user:name} => all user names as listed by "show user-table", column Name

 

%{time:hhmm} => outputs current controller time as hours:minutes (i.e. 10:42)

%{time:mmmdd} => outputs current controller time as month day (i.e. Jun 19)

 

Consider following entry in your commands file:

0,show ap active ap-name %{ap:name}

 

would instruct AirRecorder to run the command once for each active AP name.

 

NOTE: while variables offer a powerful way of running the same commands against multiple values, please keep in mind that it potentially generates a high number of commands that are send towards the CLI process of the controller. Use with caution!

 

 

Variables post-processing

 

The data set of a variable can be post-processed using processors. The general syntax is for a processor is:

.processor([argument[,argument]])

 

AirRecorder comes out of the box with following processors:

- .upper(): convert variable values into upper case

- .lower(): convert variable values into lower case

- .droplast(): drop last value from variable values

- .include("include string"): retains only values that contains "include string"

- .exclude("exclude string"): retains only values that do not contain "exclude string"

- .match("regular expression"): retains only values that match the regular expression

- .differ("regular expression"): retains only values that do not match the regular expression

- .replace("regular expression", "replacement"): replaces every variable value 

                                                 matching regular expression 

                                                 with replacement

    

Note that processors can be chained.

%{ap-group:name}.upper()

%{ap-group:name}.match("^DE.*").include("236")

%{time:hhmm}.replace(".$","")

 

NOTE/LIMITATION: when escaping in regular expressions, one needs to use double escape \ with \\: i.e. write \\S+.* for final expression: \S+.*

 

 

Custom variables

 

Custom variable definitions allow for arbitrary data extraction. The syntax is as follows:

#{<command>,<marker>,<column>[,<ttl>]}

 

where

- <command> is the command to run to fetch values, i.e. "show ap active"

- <marker> is the marker line to parse output, i.e. "Active AP Table"

- <column> is the name of the column to extract, i.e. "Name"

- <ttl> is the time-to-live of the variable content:

  -1: variable is loaded once (default)

  0: variable is loaded every time

  x: variable is loaded every x seconds

 

Consider following example, with an entry like this in your commands file:

0,show ap debug radio-stats ap-name #{show ap database group APGROUP status up,,Name}

 

and AirRecorder would run the command once for each active AP in the AP group named APGROUP.

 

NOTES: 

- the variable parser currently understands only the table based output commands

- marker and column are CASE sensitive

- marker can be left empty, i.e. #{<command>,,<column>[,<ttl>]}

 

EXCEPTIONS:

#{show clock,<format>,<N/A>,<always 0>} will output current controller time

  according to <format>. <column> is ignored and <ttl> is always 0.

  <format> patterns are described in 

    http://docs.oracle.com/javase/6/docs/api/java/text/SimpleDateFormat.html

 

Version History
Revision #:
1 of 1
Last update:
‎12-19-2014 02:44 PM
Updated by:
 
Labels (1)
Contributors

Here are the answers to some of the common questions we received in the recent webinar "Unplugging the last cord". If you missed the webinar, you can view the recording here at http://www.arubanetworks.com/resources/webinars/

 

Aruba deployment specific

 

Q: How is QoS management done? Is it by VLAN?
A: In an Aruba mobility infrastructure, granular QoS and access policies can be defined and implemented independent of the underlying VLANs using AppRF technology. AppRF policies are contextual and based on apps, users, devices and locations. See here for more details - http://www.arubanetworks.com/resources/apprf/

 

Q: Was the all-wireless implementation carried out at the HQ only or throughout the whole company?
A: The rollout started at HQ in Sunnyvale, CA in early 2014 with MS Lync and is gradually being deployed globally.

 

Q: How do you handle OS deployment with an all-wireless environment? Do you still have some hard links for this purpose?
A: We use high capacity 802.11ac wireless AP-225 throughout our campus. We find that sufficient for image upgrades and to roll our OS updates too.


Q: What happens when the power fails?
A: We have UPS backup available for our critical infrastructure, including wireless and Lync

 

Q: Are you using WIPS IDS/IPS along side this?
A: Yes, Wireless IDS scanning is always ON and action is taken on the channels that APs operate in for WIPS. During active voice / video sessions, Aruba APs delay their WIDS scanning so that session quality is not impacted. See here for more details - http://www.arubanetworks.com/pdf/products/DS_AOS_RFPROTECT.pdf

 

Q: How do your internal users enroll their user certificate to connect on corporate Wi-Fi?
A: We offer a multi-vendor (your access network can be from any networking vendor) solution to enable this. It is called ClearPass Onboard. Take a look here: http://www.arubanetworks.com/products/clearpass/device-management/

 

 

Q: How do you handle the reduced throughput vs wired network. We have high density of user in a number of our building.
A: We really don't see that, especially with 802.11ac. You can use a monitoring tool like Airwave to check your density and coverage on an on going basis. As long as you setup the right policies to manage the available bandwidth, and monitor is automatically it is not really an issue.

 


Q: Do you use AP uplinks as port channels?
A: Setting up AP uplinks to be port channel is a general network design option. It is completely dependent on the deployment, traffic considerations, applications being used and so on.

 

Q: Can users wirelessly connect to conference room screens?
A: At Aruba we use a combination of Apple TVs and Lync Room Systems to enable users to wirelessly project to conference room screens. Using Aruba AirGroup technology makes it seamless for IT to deploy these services. Read more here http://www.arubanetworks.com/pdf/technology/TB_AirGroupWLANServices.pdf

 

Q: How do you handle wireless security? What are you using?

A: Today, wireless security has evolved a lot and in many cases is probably more secure than your wired network. Who uses 802.1x on wired ports? But it’s very common to use the same on wireless making it very secure. Our main corporate SSID is protected using WPA2-Enterprise, authenticated using ClearPass. See here for additional information - http://www.arubanetworks.com/products/clearpass/

 

Q: Do you have any data or study available that shows how throughput varies over distance for wireless clients?
A: Take a look at our presentation from the last Airheads Conference. https://community.arubanetworks.com/t5/Americas-Airheads-Conference/Breakout-Wi-Fi-Behavior-of-Popular-Mobile-Devices/gpm-p/129135 and this one on RF design: https://community.arubanetworks.com/t5/Americas-Airheads-Conference/Breakout-Advanced-RF-Design-amp-Troubleshooting/gpm-p/129173

 

 

Q: Do you have a rough estimate for how many users you would normally estimate per AP?
A: For an 802.11ac AP we have tested all the way upto 55 mobile devices running different kinds of real time Lync traffic - a mix of voice, video, desktop sharing etc. This number can certainly go up further depending on usage, but you should plan on this based on your deployment - # of devices, applications etc. and leave room for roaming clients too.

 

Q: Within Aruba, do you use AP-225's? Do you use Aruba Instant for your solution or backend controllers?
A: In major offices we have AP-225s with controllers, in smaller offices we use IAP-225s.

 

Q: How fat is the Internet pipe to branch offices? Can you do VPN cleanly?
A: Here is a guideline that we have typed for this use case: http://www.arubanetworks.com/wp-content/uploads/VoiceSupportAppNote_2011-11-14.pdf

 

 

Q: What software do you use for coverage reporting

A: The reports are run on Aruba’s AirWave NMS platform. AirWave talks SNMP and can manage multi-vendor wired and wireless networks. See here for more details

http://www.arubanetworks.com/products/airwave/

 

Q: How you differentiate between internal users phones and tablets and external users mobile devices?
A: We identify mobile devices using various techniques like DHCP fingerprints, MAC OUIs, HTTP user strings etc. to identify device type and classify device as BYOD or corporate

 

Q: How about desktop pc's? Are they still wired or they have a wireless card?
A: Aruba has a laptop environment and all are equipped with wireless.

 

Q: How is the handoff between the AP's accomplished for mobile users with wireless handsets that move around the campus?
A: We support layer 2 and layer 3 roaming to achieve mobility. In addition we support protocols like 11r, 11v and 11k that helps us to proactively make roaming seamless. See here for additional details

http://www.arubanetworks.com/wp-content/uploads/DG_Roaming.pdf

 

Q: How do you deal with access control and network segregation for guests?
A: We have the Guest network and internal network on different vlans and different SSIDs, separated by firewalls.

 

Microsoft Lync related

 

Q: Do you have any best practices recommendations for designing wireless and Lync?

A: Here is a great (very detailed) resource on Lync over Wi-Fi end to end -https://community.arubanetworks.com/t5/Validated-Reference-Design/Lync-Over-Aruba-WiFi/ta-p/199813

 

Q: How do you handle automatic location of callers who dial 911 from their Lync device?


A: E911 is a pretty complex subject that is really best discussed with a PSLP. The Aruba wireless solution integrates with many e911 vendors for emergency services. We calculate location of clients using standard RF triangulation and also use other advanced methods like BLE. This close to accurate location data (x,y cordinate) gets sent to the e911 system. We do have a partnership with RedSky Technologies for e911 services in an all wireless environment. You can see more details here. http://www.arubanetworks.com/partners/ecosystem/voice-over-wlan/#redsky.

 

Q: Can you hand off Lync to 3G i.e. walk out the building away from Wi-Fi?
A: Yes, absolutely

 

Q: With your ability to move clients to better AP's does this affect a call when it is moved to a better AP?
A: Client Match is voice aware. Devices with active calls are not matched to a different AP.

 

Q: Do you support the Asterisk Platform?
A: Microsoft’s SDN API is for integration with the Lync infrastructure. The API does not apply for Asterisk. But the UCC dashboard and all the visibility info you see in Aruba’s Airwave NMS are built to support common voice protocols much beyond Lync.


Q: Is this presentation based on on-premise Lync server or works for an Office 365 implementation?
A: Aruba’s implementation of Lync is on-premise Lync 2013.

                                         

Q: How does the SDN API work? Do you create a link between Lync and Airwave?
A: Microsoft’s SDN API is a communication channel between the Aruba controller and Lync infrastructure. The Aruba controller then passes on the relevant data to AirWave NMS for trending and visibility purposes.

 

Q: Did you deploy Bluetooth headsets to all users to connect to their laptops/desktops?
A: We have a small store of Bluetooth and wired, and DECT headsets. We also have a catalog of Lync approved headsets that employees can choose from and expense to their department. Most people already have Bluetooth devices for their phones that work well with Lync too.

 

Q: Have you evaluated interfacing with other UCC/PBX vendors such as ShoreTel or Jabber or Avaya One-X? Do you have the necessary deployment guides?

A: This was a requirement for Aruba, as we had to coexist with other PBXs during the rollout. Aruba infrastructure supports H.323 and SIP since many years now including support for monitoring and flow QoS for these protocols. We don’t have a vendor specific deployment guide (except Lync), but here are two guides for voice over wireless that will apply for Shortel and other voice vendors: http://www.arubanetworks.com/wp-content/uploads/VoiceSupportAppNote_2011-11-14.pdf

http://www.arubanetworks.com/techdocs/ArubaOS_60/UserGuide/Voice_Video.php

 

 

 

 

Version History
Revision #:
1 of 1
Last update:
‎10-06-2014 01:53 PM
Updated by:
 
Labels (1)
Contributors

Q - I like to know the difference between L2 broadcasting (MAC address FF:FF:FF:FF:FF:FF) and L3 broadcasting (IP address 255.255.255.255).

I know ARP uses L2 BC. In which protocol/situation where L3 broadcast is used?. Anyway as router is going to block all broadcast(both L2 and L3), what is the difference between them.

...I know ARP uses L2 BC. In which protocol/situation where L3 broadcast is used?...

 

A - The most common Network Layer protocol used today is IP but be aware there are others. So in computer networking, a broadcast address is an IP address that allows information to be sent to all machines on a given subnet rather than a specific machine.

So there's your situation. Where you want to send a message to multiple computers in a network you use a broadcast address. There are other types of routing schemes ie. multicast, unicast and anycast but they're outside the scope of your original question.

The second part of your question was what protocols use IP broadcasts. Below I've listed a few but there are many more.

Here are some protocols at the Network Layer that use IP.

  • IPv4/IPv6, Internet Protocol
    • DVMRP, Distance Vector Multicast Routing Protocol
    • ICMP, Internet Control Message Protocol
    • IGMP, Internet Group Multicast Protocol
    • PIM-SM, Protocol Independent Multicast Sparse Mode
    • PIM-DM, Protocol Independent Multicast Dense Mode


There are other protocols like Appletalk DDPand IPX but most of the net runs on IP.

At layer two you are limited to computers that are connected to your direct network. For example Computer A on network 192.168.25.0 could not talk to Computer B on network 192.168.100.0 without using a layer 3 protocol. Layer 2 uses MAC addresses which cannot be routed. For network A(192.168.25.0) and network B(192.168.100.0) to talk to each other you'll need to use Network Layer protocols. The computers in either network would be connected via a switch can talk to each other and have Layer 2 connectivity so no routing is required.

The question your asking is very broad so I hope I helped so how. To really get your head around it all you should understand the encapsulation process.

Version History
Revision #:
1 of 1
Last update:
‎09-26-2014 03:50 AM
Updated by:
 
Contributors

U-APSD is a power-save mechanism that is an optional part of the IEEE amendment 802.11e, QoS. U-APSD is also known as WMM Power Save, and the behaviour and operation is exactly the same, except for coding of some information elements. 

 

U-APSD is working in conjunction with WMM and is tied with usage of the 4 EDCA access categories that is used to differentiate packets and their priorities. U-APSD is very well suited for bi-directional data flows like voice. 

 

The power savings is around 400% with Ascom i62 default settings compared to active mode, and extends the talk time from around 4 hours in active to around 16 hours in U-APSD mode with the standard battery.

 

This attached document aims to explain the logics and behaviour of 802.11 power-save mechanisms and U-APSD as implemented in the Ascom i62. The document will also suggest some methods to debug any anomalies or problems with U-APSD operation.

 

Version History
Revision #:
6 of 6
Last update:
‎07-01-2014 06:59 PM
Updated by:
 
Labels (1)

 

Roles and Policies

 

Every client in an Arubauser-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 Arubacontroller. 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 ArubaOSCLI 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.

This chapter describes the following topics:

 

This chapter describes configuring firewall policies and parameters that relate to IPv4 traffic. SeeChapter 32, “IPv6 Client Support” for information about configuring IPv6 firewall policies and parameters.

 

Policies

A firewall policy identifies specific characteristics about a data packet passing through the Arubacontrollerand takes some action based on that identification. In an Arubacontroller, 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:

  • 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 userin 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 Chapter 32, “IPv6 Client Support” for information about configuring IPv6 firewall policies.

 

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:

  • 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.

ArubaOSprovides 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.

 

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).

Table 56 describes required and optional parameters for a rule.

Table 56 Firewall Policy Rule Parameters (Continued)

Field

Description

Source (required)

Source of the traffic, which can be one of the following:

l        any: Acts as a wildcard and applies to any source address.

l        user: This refers to traffic from the wireless client.

l        host:This refers to traffic from a specific host. When this option is chosen, you must configure the IP address of the host.

l        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.

l        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 > Destinationpage.

Destination (required)

Destination of the traffic, which can be configured in the same manner as Source.

Service (required)

Type of traffic, which can be one of the following:

l        any: This option specifies that this rule applies to any type of traffic.

l        tcp: Using this option, you configure a range of TCP port(s) to match for the rule to be applied.

l        udp: Using this option, you configure a range of UDP port(s) to match for the rule to be applied.

l        serviceUsing 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.

l        protocol: Using this option, you specify a different layer 4 protocol (other than TCP/UDP) by configuring the IP protocol value.

Action (required)

The action that you want the controllerto perform on a packet that matches the specified criteria. This can be one of the following:

l        permit: Permits traffic matching this rule.

l        drop: Drops packets matching this rule without any notification.

l        reject: Drops the packet and sends an ICMP notification to the traffic source.

l        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 theConfiguration >Advanced > Security >Advanced > NAT Pools.)

l        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 Arubacontrolleras used in the pre-defined policy called “captiveportal”.

l        dual-nat: This option performs both source and destination NAT on packets matching the rule.

l        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.

l        redirect to ESI group: This option redirects traffic to the specified ESI server group. You also specify the direction of traffic to be redirected: forward, reverse, or both directions.

Log (optional)

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.

Mirror (optional)

Mirrors session packets to datapath or remote destination.

Queue (optional)

The queue in which a packet matching this rule should be placed.
Select Highfor higher priority data, such as voice, and Low for lower priority traffic.

Time Range (optional)

Time range for which this rule is applicable.

Configure time ranges on the Configuration >Security >Access Control > Time Rangespage.

Pause ARM Scanning (optional)

Pause ARM scanning while traffic is present. Note that you must enable “Voice Aware Scanning” in the ARM profile for this feature to work.

Black List (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.

White List (optional)

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.

TOS (optional)

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.

802.1p Priority (optional)

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.    Click Addto create a new policy.

3.    Enter web-only for the Policy Name.

4.    To configure a firewall policy, select IPv4 Session for Policy Type.

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

ip access-list session web-only

   any any svc-http permit

   any any svc-https permit

 

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 Protocolsection, 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 Typesection, specify whether you want to define the port by a contiguous range of ports, or by a list of non-contiguous port numbers.

  • If you selected Range, enter the starting and ending port numbers in the Starting Portand End Port fields.
  • If you selected list, enter a comma-separated list of port numbers.

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

  • dhcp:  Service is DHCP
  • dns:  Service is DNS
  • ftp:  Service is FTP
  • h323:  Service is H323
  • noe:  Service is Alcatel NOE
  • rtsp:  Service is RTSP
  • sccp:  Service is SCCP
  • sip:  Service is SIP
  • sips:  Service is Secure SIP
  • svp:  Service is SVP
  • 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, access the CLI in config mode and issue the following command:

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 controllerduring traffic session processing by prohibiting traffic from being automatically forwarded to the controllerif 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.

Configuring a White List 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 Ratefield 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 Actiondrop-down list and select Permitor DenyPermitallows session traffic to be forwarded to the controllerwhile Deny blocks session traffic.

4.    In the IP Protocol Number field, enter the number for a protocol used by session traffic.

5.    In the Starting Portsfield, 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.

6.    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.

7.    (Optional) Click the White list Bandwidth Contractdrop-down list and specify the name of a bandwidth contract to apply to the session traffic. For further information on creating Bandwidth Contracts, see “Configuring a Bandwidth Contract in the WebUI”

8.    Click Done. The ACL displays on the white list section.

9.    To delete an entry, click Delete next to the entry you want to delete.

10. Click Apply to save changes.

 

Configuring the White List Bandwidth Contract in the CLI

cp-bandwidth-contract <name> {mbits <1..2000>}|{kbits <256..2000000>}

 

Configuring the ACL White List in the CLI

Use the following CLI command to create ACL White Lists.

(host) (config) #firewall cp {deny|permit} proto <IP protocol number> ports <start port number> <last port number> [bandwidth-contract <name>]

To create a whitelist ACL entry that permits traffic using protocol 6 on ports 5000 through 6000 to be forwarded to the controller:

(host) (config-fw-cp) #firewall cp permit proto 6 ports 5000 6000

To create a a whitelist ACL entry that denies traffic using protocol 2 on port 5000 from being forwarded to the controller:

(host) (config-fw-cp) #firewall cp deny proto 2 ports 5000 5000

 

User Roles

This section describes how to create a new user role. When you create a user role, you specify one or more policies for the role.

Table 57 describes the different parameters you can configure for the user role.

Table 57 User Role Parameters (Continued)

Field

Description

Firewall Policies (required)

One or more policies that define the privileges of a wireless client in this role. There are three ways to add a firewall policy to a user role:

l        Choose from configured policies (see “Creating a Firewall Policy” ): Select a policy from the list of configured policies and click the “Done” button to add the policy to the list of policies in the user role. If this policy is to be applied to this user role only for specific AP groups, you can specify the applicable AP group.

l        Create a new policy from a configured policy: This option can be used to create a new policy that is derived from an existing policy.

l        Create a new policy: The rules for the policy can be added as explained in“Creating a Firewall Policy”.

Re-authentication Interval (optional)

Time, in minutes, after which the client is required to reauthenticate. Enter a value between 0-4096. 0 disables reauthentication.

Default: 0 (disabled)

Role VLAN ID (optional)

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 > VLANspage.

Bandwidth Contract (optional)

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 “Bandwidth Contracts”.

VPN Dialer (optional)

This assigns a VPN dialer to a user role. For details about VPN dialer, seeChapter 14, “Virtual Private Networks”.

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 Chapter 14, “Virtual Private Networks”.

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)

This assigns a PPTP pool to the user role. For more details about PPTP pools, see Chapter 14, “Virtual Private Networks”.

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.

Captive Portal Profile (optional)

This assigns a Captive Portal profile to this role. For more details about Captive Portal profiles, see Chapter 12, “Captive Portal”.

Max Sessions

This configures a maximum number of sessions per user in this role. The default is 65535. You can configure any value between 0-65535.

 

Creating a User Role

The following example creates the user role ‘web-guest’ and assigns the previously-configured ‘web-only’ policy to this user 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 web-guest for Role Name.

4.    Under Firewall Policies, click Add. From Choose from Configured Policies, select the ‘web-only’ session policy from the list. You can click Createto create and configure a new policy.

5.    Click Done to add the policy to the user role.

 

If there are multiple policies for this role, policies can be re-ordered by the using the up and down buttons provided for each policy.

6.    You can optionally enter configuration values as described in Table 57.

7.    Click Apply to apply this configuration. The role is not created until the configuration is applied.

After assigning the user role (see “User Role Assignments” ), you can click the Show Reference button to see the profiles that reference this user role.

 

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.

 

In the CLI

user-role web-guest

   access-list session web-only position 1

After assigning the user role (see “User Role Assignments” ), you can use the show reference user-role <role> command to see the profiles that reference this user role.

 

Bandwidth Contracts

You can manage bandwidth utilization by assigning maximum bandwidth rates, or bandwidthcontracts, to user roles. You can configure bandwidth contracts, in kilobits per second (Kbps) or megabits per second (Mbps), for the following types of traffic:

  • from the client to the controller (“upstream” traffic)
  • from the controller to the client (“downstream” traffic)

You can assign different bandwidth contracts to upstream and downstream traffic for the same user role. You can also assign a bandwidth contract for only upstream or only downstream traffic for a user role; if there is no bandwidth contract specified for a traffic direction, unlimited bandwidth is allowed.

By default, all users that belong to the same role share a configured bandwidth rate for upstream or downstream traffic. You can optionally apply a bandwidth contract on a per-userbasis; each user who belongs to the role is allowed the configured bandwidth rate.

For example, if clients are connected to the controllerthrough a DSL line, you may want to restrict the upstream bandwidth rate allowed for eachuser to 128 Kbps. Or, you can limit the totaldownstream bandwidth used by all users in the ‘guest’ role to 128 Mbps. The following example configures a bandwidth rate of 128 Kbps and applies it to upstream traffic for the previously-configured ‘web-guest’ user role on a per-user basis.

 

Configuring a Bandwidth Contract in the WebUI

In the WebUI, you can first configure a bandwidth contract and then assign it to a user role:

1.    Navigate to the Configuration >Advanced Services >Stateful Firewall > BW Contracts page.

2.    Click Add to create a new contract.

3.    In the Contract Namefield, enter BC512_up.

4.    The Bandwidthfield allows you to define a bandwidth rate in either kbps or Mbps. For this example, enter 512in the Bandwidth field, then click the drop-down list and select kbps.

5.    Click Done.

 

Assigning a Bandwidth Contract to a User Role in the WebUI

Now that you have a defined bandwidth contract, you can assign that contract to a user role.

1.    Navigate to the Configuration >Security >Access Control > User Roles page.

2.    Select Edit for the web-guest user role.

3.    Under Bandwidth Contract, select BC512_up from the drop-down menu for Upstream.

4.    Select Per User.

5.    Scroll to the bottom of the page, and click Apply.

You can also can configure the user role and create the bandwidth contract from the User Roles page:

1.    Navigate to the Configuration >Security >Access Control > User Roles page.

2.    Select Edit for the web-guest user role.

3.    In the Bandwidth Contract section, click the Upstreamdrop-down list and select Add New. The New Bandwidth Contract fields appear.

a.    In the Namefield, enter BC512_up.

b.    In the Bandwidth field, enter 512.

c.    Click the Bandwidth drop-down list and select kbps.

d.    Click Doneto add the new contract and assign it to the role. The New Bandwidth Contractsection closes.

4.    In the Bandwidth Contractsection, select the Per User checkbox.

5.    Scroll to the bottom of the page, and click Apply.

 

Configuring and Assigning Bandwidth Contracts in the CLI

aaa bandwidth-contract BC512_up kbps 512

user-role web-guest

   bw-contract BC512_up per-user upstream

 

Bandwidth Contract Exceptions

Bandwidth contracts on a VLAN can limit broadcast and multicast traffic. ArubaOSincludes 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

 

Viewing the Current Exceptions List

To view the current bandwidth contract exception list, access the command-line interface in enable mode and issue the command show vlan-bwcontract-explist. To view the preconfigured internal bandwidth contract exception list, include the optional internal parameter, as shown in the example below:

 

Configuring Bandwidth Contract Exceptions

To add the MAC address of a protocol to the exception list for bandwidth contracts, access the command-line interface in config mode and issue the command vlan-bwcontract-explist <mac-addr>.

The following example 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

User Role Assignments

A client is assigned a user role by one of several methods. A user role assigned by one method may take precedence over a user role assigned by a different method. The methods of assigning user roles are, from lowest to highest precedence:

1.    The initial user role for unauthenticated clients is configured in the AAA profile for a virtual AP (see Chapter 4, “Access Points”).

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 beforeclient 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 ArubaVendor-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.

 

User Role in AAA Profile

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. To configure user roles in the AAA profile:

 

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 Roledrop-down list and select the desired user role for users who have completed 802.1x authentication.

5.    Click the MAC Authentication Default Roledrop-down list and select the desired user role for clients who have completed MAC authentication.

6.    Click Apply.

 

In the CLI

aaa profile <profile>

   initial-role <role>

   dot1x-default-role <role>

   mac-default-role <role>

For additional information on creating AAA profiles, see “AAA Profile Parameters” .

User-Derived Role

The user role can be derived from attributes from the client’s association with an AP. 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 optionally add a description of the user rule.

 

User-derivation rules are executed before the client is authenticated.

Table 58 describes the conditions for which you can specify a user role.

Table 58 Conditions for User-Derived Role (Continued)

Rule Type

Condition

Value

BSSID of AP to which client is associated

One of the following:

l        contains

l        ends with

l        equals

l        does not equal

l        starts with

MAC address (xx:xx:xx:xx:xx:xx)

User class identifier (option 77) returned by DHCP server

equals

string

Encryption type used by client

One of the following:

l        equals

l        does not equal

l        Open (no encryption)

l        WPA/WPA2 AES

l        WPA-TKIP (static or dynamic)

l        Dynamic WEP

l        WPA/WPA2 AES PSK

l        Static WEP

l        xSec

ESSID to which the client is associated

One of the following:

l        contains

l        ends with

l        equals

l        does not equal

l        starts with

l        value of (does not take string; attribute value is used as role)

string

Location–AP name of the AP to which the client is associated

One of the following:

l        equals

l        does not equal

string

MAC address of the client

One of the following:

l        contains

l        ends with

l        equals

l        does not equal

l        starts with

MAC address (xx:xx:xx:xx:xx:xx)

 

Configuring a User-derived Role

1.    Navigate to the Configuration >Security >Authentication > User Rules page.

2.    Click Addto 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 Addto add a rule. For Set Type, select Role from the drop-down menu. (You can select VLAN to configure derivation rules for setting the VLAN assigned to a client.)

5.    Configure the condition for the rule by setting the Rule Type, Condition, Value parametersand optional description of the rule.See Table 58 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.

 

Configure a User-derived Role in the CLI

aaa derivation-rules user <name>

   set role condition <condition> set-value <role> position <number>

where conditionconsists of rule_type condition valueparameters. See Table 58for descriptions of these parameters.

 

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 Profilestab. 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 Authenticationor L3 Authenticationtab. 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” .

 

In the CLI

To configure the default user role for MAC or 802.1x authentication:

aaa profile <profile>

   mac-default-role <role>

   dot1x-default-role <role>

To configure the default user role for other authentication methods:

aaa authentication captive-portal <profile>

   default-role <role>

aaa authentication stateful-dot1x

   default-role <role>

aaa authentication stateful-ntlm

   default-role <role>

aaa authentication vpn

   default-role <role>

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. 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”.

VSA-Derived Role

Many Network Address Server (NAS) vendors, including Aruba, use VSAs to provide features not supported in standard RADIUS attributes. For Arubasystems, 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 on controllersconform to the format recommended in RFC 2865, “Remote Authentication Dial In User Service (RADIUS)”.

Dictionary files that contain ArubaVSAs are available on the Arubasupport website for various RADIUS servers. Log into the Aruba support website to download a dictionary file from the Tools folder.

Global Firewall Parameters

Table 59describes optional firewall parameters you can set on the controllerfor 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 firewallconfiguration commands.

See Chapter 32, “IPv6 Client Support” for information about configuring firewall parameters for IPv6 traffic.

Table 59 IPv4 Firewall Parameters (Continued)

Parameter

Description

Monitor Ping Attack

Number of ICMP pings per second, which if exceeded, can indicate a denial of service attack. Valid range is 1-255 pings per second. Recommended value is 4.

Default: No default

Monitor TCP SYN Attack rate

Number of TCP SYN messages per second, which if exceeded, can indicate a denial of service attack. Valid range is 1-255 messages per second. Recommended value is 32.

Default: No default

Monitor IP Session Attack

Number of TCP or UDP connection requests per second, which if exceeded, can indicate a denial of service attack. Valid range is 1-255 requests per second. Recommended value is 32.

Default: No default

Monitor/Police CP Attack rate (per sec)

Rate of misbehaving user’s inbound traffic, which if exceeded, can indicate a denial or service attack.

Recommended value is 100 frames per second.

 

Deny Inter User Bridging

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

Deny All IP Fragments

Drops all IP fragments.

Note: Do not enable this option unless instructed to do so by an Arubarepresentative.

Default: Disabled

Prevent L2 Bridging between Wireless users

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

Enforce TCP Handshake Before Allowing Data

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

Prohibit IP Spoofing

Enables detection of IP spoofing (where an intruder sends messages using the IP address of a trusted client). When this option is enabled, 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

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

Log ICMP Errors

Enables logging of received ICMP errors. You should not enable this option unless instructed to do so by an Aruba representative.

Default: Disabled

Disable stateful SIP Processing

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)

Allow Tri-session with DNAT

Allows three-way session when performing destination NAT. This option should be enabled when the controlleris notthe default gateway for wireless clients and the default gateway is behind the controller. This option is typically used for captive portal configuration.

Default: Disabled.

Session Mirror Destination

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:

Ethertype to be mirrored with the Ethertype ACL mirror option.

IP flows to be mirrored with the session ACL mirror option.

MAC flows to be mirrored with the MAC ACL mirror option.

If you configure both an IP address and a port to receive mirrored packets, the IP address takes precedence.

Default: N/A

Session Idle Timeout

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 Arubarepresentative.

Default: 15 seconds

Disable FTP Server

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)

GRE Call ID Processing

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

Per-packet Logging

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 Arubarepresentative, as doing so may create unnecessary overhead on the controller.

Default: Disabled (per-session logging is performed)

Broadcast-filter ARP

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 handsetsin conjunction with increasing the DTIM interval on

clients.

Default: Disabled

Session VOIP Timeout (sec)

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

Disable Stateful H.323 Processing

Disables stateful H.323 processing.

Default: Enabled

Disable Stateful SCCP Processing

Disables stateful SCCP processing.

Default: Disabled

Only allow local subnets in user table

Adds only IP addresses, which belong to a local subnet, to the user-table.

Default: Disabled

Session mirror IPSEC

Configures session mirroring of all frames that are processed by IPsec. Frames are sent to IP address specified by the session-mirror-destination option.

Note: Use this option for debugging or troubleshooting only.

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 (Mbps)

Specifies the untrusted unicast traffic rate limit. Range is 1-200 Mbps.

Default: 10 Mbps

Rate limit CP untrusted mcast traffic (Mbps)

Specifies the untrusted multicast traffic rate limit. Range is 1-200 Mbps.

Default: 2 Mbps

Rate limit CP trusted ucast traffic (Mbps)

Specifies the trusted unicast traffic rate limit. Range is 1-200 Mbps.

Default: 80 Mbps

Rate limit CP trusted mcast traffic (Mbps)

Specifies the trusted multicast traffic rate limit. Range is 1-200 Mbps.

Default: 2 Mbps

Rate limit CP route traffic (Mbps)

Specifies the traffic rate limit that needs ARP requests. Range is 1-200 Mbps.

Default: 1 Mbps

Rate limit CP session mirror traffic (Mbps)

Specifies the session mirrored traffic forwarded to the controller. Range is 1-200 Mbps.

Default: 1 Mbps

Rate limit CP auth process traffic (Mbps)

Specifies the traffic rate limit that is forwarded to the authentication process. Range is 1-200 Mbps.

Default: 1 Mbps

 

 

Version History
Revision #:
1 of 1
Last update:
‎05-28-2014 07:51 AM
Updated by:
 
Contributors
Tags (2)

I thought of starting a string of basic configuration videos to assist new wireless engineers with getting started with Aruba gear. The topics will be very simple at first then grow into more indepth tutorials.

 

This is covering adding a local to a master controller.

 

Version History
Revision #:
4 of 4
Last update:
‎05-02-2014 09:18 AM
Updated by:
 
Labels (1)
Tags (1)

The following solution is available in Aruba Solution Exchange which contains the intelligent wizard to help configure AP fast failover.

 

https://ase.arubanetworks.com/solutions/id/53

 

 

Summary

The Aruba AP Fast Failover feature introduced in Aruba OS (AOS) 6.3 minimizes the failover time in the event of a controller failure.  All controllers in the same redundancy domain need to share the same HA-Group profile.  
 
AP licenses, controller capacity, configuration synchronization between controllers, physical locations and type of networks connection of the controllers, licenses and etc should be considered in designing the HA group membership.
 
The HA roles supported are active, standby and dual. The solution template will build one HA group for a set of controllers deployed in an active / active model

 

Configuration Notes

  • The design of master redundancy is independent of AP fast failover. Master redundancy need to be configured to ensure AP will be able to contact the Master controller upon reboot. Another option would be to configure VRRP between master-local pairs to provide master redundancy.
  • When HA roles of the controllers are set to dual, the active controller will be determine by the LMS-IP setting in the AP system profile and the standby controller will be selected from the list of controllers listed in the HA group in the round-robin fashion.
  • Multiple HA Groups can be defined but each controller can only be assigned to a single HA group.
  • Controller IP or switch IP of the controller must be used when defining the controller in the HA group profile.
  • The "ha group-membership" is a local command and need to be executed on each local controller.
  • HA group membership is independent of the controller role. For example, AP Fast Failover could be setup between two master but the administrator need to make sure that the configuration and relevant networks configuration are similar between the two controllers.
  • AP fast failover feature supports APs in campus mode using tunnel or decrypt-tunnel forwarding modes, but does not support campus APs in bridge mode. This feature is not supported on remote APs and mesh APs in any mode.  Legacy AP‑60 series and AP‑70series APs also do not support this feature.

Sample Lab Topology

 

Platform Tested

Aruba Mobility Controller 3600-US running AOS version 6.3.1.2.

 

Licensing

AP license

 

References

[1] Aruba OS 6.3 User Guide

Version History
Revision #:
3 of 3
Last update:
‎04-29-2014 01:18 PM
Updated by:
 
Labels (1)
Contributors

What is AirRecorder

A Java based tool that will run several common CLI commands for checking controller, AP, and wireless device health. AirRecorder supports ArubaOS, Instant VC (IAP) and MeshOS (MSR). AirRecorder runs on any operating system that supports a Java Platform Standard Edition version 6 or later.

 

Download

Please download latest release from:

Login to support.arubanetworks.com go to Tools> Airrecorder Folder

 

At time of writing this is version 1.2.16.

 

Getting Started

After downloading the distribution ZIP file, unpack it to a directory or folder of choice. On successful unpacking, you should at least find following files:

 AirRecorder-1.2.16-release.jar

 CHANGES.txt

 EULA.txt

 HOWTO.txt

 LICENSE.txt

 README.txt

 samples

 

Please note that "samples" is a folder that contains sample files.

 

To run the tool, please open a DOS command window or Linux/MacOS terminal and type:

java -jar AirRecorder-1.2.16-release.jar

 

You should see an output similar to:

AirRecorder (c)2011-2014 Thomas Bastian, Aruba Networks

usage: AirRecorder [options] [<controllerip>]

 

If you don’t see an output similar to above, then most likely you don’t have Java installed. Please download the proper Java for your system from:

http://www.oracle.com/technetwork/java/javase/downloads/index.html?ssSourceSiteId=otnjp

 

First Use

AirRecorder records the output of CLI commands in a file. By default, the list of commands is read from a file named "commands" or "commands.txt". Please go 

ahead and create a file named "commands.txt" in the distribution directory. Enter a single line into the file:

0,show ap active

and save the file.

 

You are now ready to run your first AirRecorder session. In the Windows command (DOS) window or Linux/MacOS Shell terminal window, please type:

java -jar AirRecorder-1.2.16-release.jar <controller>

 

<controller> is the IP address or hostname of the controller you would like to run the session against.

 

As the session begins, you will be prompted for the username, password and enable password to be used to login into the controller (if you have 

"enable bypass" activated on the controller, just hit RETURN when prompted for enable password).

 

At the end of the session, a new file should have been created:

air-recorder-<controller>-YYYYMMDD-HHMMSS-00.log

 

Please use your favorite editor to look at the contents recorded (it should contain the output from the command “show ap active”).

 

Unattended Use

AirRecorder can read the username, password and enable password for login into the controller: 

- from the command line: -u <username> -p <password> -e <enable password>

  i.e.:

  java -jar AirRecorder-1.2.16-release.jar -u admin -p admin -e enable <controller>

  

- from a file named either "<controller>" or "<controller>.txt" argument provided (i.e. in the above case, a file named: "192.168.0.196" or 

  "192.168.0.196.txt"). In this case, the file should contain the username, password and enable password each on a separate line in the file. If

  "enable bypass" is enabled on the controller, leave the third line blank.

 

Working With Commands

AirRecorder can read commands from any file. Please use the command line argument:

-c <command file>

to specify an alternate commands file to be used.

 

The commands file syntax is as follows:

- one command specification per line

- lines starting with # are skipped

- a command specification takes the form: [<trigger>;]<schedule>,<command>

  i.e.: 0,show ap active

 

<trigger> is an optional field and can be omitted. TRIGGERS will be discussed later.

 

<schedule> is further broken down as:

  <interval>[;<execution count>[;<cycle interval>[;<cycle count>]]]

 

<interval> is the interval in *SECONDS* between consecutive executions. A value of zero will run the command once. Please be cautious when selecting the interval since smaller values may impact controller performance.

 

<execution count> is the optional number of times the command will be executed. When unspecified the command will repeat for ever. Otherwise the command will be executed the specified amount *PER* cycle. Note that if <cycle interval> is not specified, the command will be executed <execution count> number of times, then never again.

 

<cycle interval> is the optional interval between the start of repeating cycles. If this is omitted, the command will be executed just <execution count> times.

 

<cycle count> is the optional number of times to run the cycles.

 

<command> is the command string that is being sent to the controller. The string is sent as is to the controller with the exception of placeholder and variable processing.

 

Both interval and cycle interval are expressed in seconds. However, adding the m or h suffix will provide values in minutes and hours respectively.

 

Examples:

 0,show ap active: will run the command "show ap active" once.

 1;1,show ap active: will run the command "show ap active" just once, i.e. "one shot"

 1m,show ap active: will run the command "show ap active" every minute.

 1m;2,show ap active: will run the command "show ap active" twice spaced by one minute.

 1m;2;1h,show ap active: will run the command "show ap active" twice spaced by one minute every hour.

 1m;2;1h;3,show ap active: will run the command "show ap active" twice spaced by one minute every hour for three times.

Version History
Revision #:
3 of 3
Last update:
‎04-23-2014 01:04 PM
Updated by:
 
Labels (1)
Contributors

Check out this presentation to learn more about the below 5 Steps To A Faster, Smarter Wireless LAN.

 

1. Providing faster and smarter Wi-Fi with 802.11ac

2. Planning your mobility network architecture 

3. Smart policy creation and BYOD enforcement 

4. Device and application management

5. Extending mobile services to visitors and customers

 

Version History
Revision #:
7 of 7
Last update:
‎11-27-2013 02:47 PM
Updated by:
 

Question

Since guests need https access to clearpass nothing is currently stopping them from removing the path from any url (keeping only https://domain.tld/) which gets them automatically redirected to the /tips admin logon prompt.

Is there any way to limit who may access that /tips path whether by blocking access altogether or simply ignoring authentication requests?

 

I found in "Monitoring - Eventviewer" that those CPPM sees the client ip address the user has when logging on so I figured I'd change the  "Copy_of_[Policy Manager Admin Network Login Service]" to have its service include a  "Connection - Client-IP-Address" with a simple "equals - ip address" (for testing), but this still allows any and all ip addresses to logon.

 

 

Answer

You can limit access in the server settings.

 

screenshot

Version History
Revision #:
2 of 2
Last update:
‎08-21-2013 03:46 PM
Updated by:
alc
 
Labels (2)
Contributors

Question

We are using the default options for the sponsor email confirmation.

In the email there is the "Click Here" which brings the sponsor to a page to do the confirmation of the

guest account.

 

The link that is generated is based on the "hostname" of the CPPM. Unfortunately, our commercial cert that is loaded in the Apache of the CPPM is registered with a different domain name so when the link is clicked we get the warning about the cert not being valid.

 

Is there a way that I can modify the auto generated link to use the domain name in our commercial cert and now the hostname of the server?

 

I noticed under the "Sponsorship Confirmation" section there is the "UI Overrides" option. Is this how I would accomplish it?

Answer

The email that is sent to the sponsor for confirmation is a print template.

 

You can edit this link by going to Configuration » Print Templates » Sponsorship Confirmation » Edit.

 

The default is as follows:

 

<a href="{'guest_register_confirm.php'|NwaGetAppUrl:false:$u.require_auth}?{if $u.source}gsr_id={$u.source|rawurlencode}&{/if}token={$u.register_token|rawurlencode}" target="_blank">click here</a> to confirm or reject the request.

 

You can change the highlighted part to specify a different server name:

 

<a href="https://my-cppm-server.example.com/guest/guest_register_confirm.php?{if $u.source}gsr_id={$u.source|rawurlencode}&{/if}token={$u.register_token|rawurlencode}" target="_blank">click here</a> to confirm or reject the request.

 

 

Version History
Revision #:
1 of 1
Last update:
‎08-21-2013 02:36 PM
Updated by:
alc
 
Labels (2)
Contributors

Question

If we terminate on the radius servers, does Aruba allow failover of radius servers for dot1x?

 

Under the server group > AAA settings, we have two radius servers but it appears that it only ever talks to the first one even if it's down it doesn't attempt to talk to the second one.  The failthrough check mark is there but is only availble if we're terminating on the controller.

Answer

If the first server listed in the group is not available, it should go to the second in that scenario.  fail through is not needed for that.   If you wanted fail through to work (go to the second even if the first is up and responding) then you need to terminate on the controller.

 

run the following from the CLI to see if it gives you any insight into whether it is trying to use the other server; and if it sees the other one as down.

 

show aaa authentication-server radius statistics

Version History
Revision #:
1 of 1
Last update:
‎08-21-2013 02:34 PM
Updated by:
alc
 
Contributors

Question

Is it possible to put multiple entries into the SAN field when generating a CSR? I tried entering "DNS:clearpass1.mydomain.org, IP:10.20.100.170" and it threw an error. I'm not sure what the delimiter is between the various SAN entries.

 

I'm trying to create a CSR for a VIP that references the publisher and subscriber IPs and FQDNs. I've been told this is the best way to handle certs in CPPM in case of a failover and / or the promotion / demotion of Publishers and Subscribers.

Answer

I believe there are no spaces

 

DNS:cplab.clearpassdemo.com,IP:10.80.2.200

 

 

Version History
Revision #:
1 of 1
Last update:
‎08-21-2013 02:20 PM
Updated by:
alc
 
Labels (2)

Question

How do I go about putting a custom background for the Amigopod Guest Self registration page?

Answer

Here - just follow the procedure in this doc.

 

Version History
Revision #:
4 of 4
Last update:
‎08-13-2013 12:39 PM
Updated by:
 
Labels (1)

This simple flowchart will guide you through the configuration of OpenDNS. There are two distinct components to setting up OpenDNS on your network. The first is pointing your external DNS traffic to OpenDNS (208.67.222.222, 208.67.220.220), and the second is configuring OpenDNS filtering settings in your OpenDNS dashboard. 

 

In our first few posts, we will focus on configuring your network’s external DNS to point to OpenDNS. Once you’re successfully sending and receiving queries from OpenDNS, we’ll move on to adding networks to your OpenDNS account and configuring your security and acceptable use policies.

 

We’ll have more details on each step in upcoming posts, but we wanted to start with a high-level overview!

 

Version History
Revision #:
5 of 5
Last update:
‎08-13-2013 12:29 PM
Updated by:
 
Labels (1)
Contributors

While deploying OpenDNS is usually as simple as making a small configuration change to your external DNS, there are a few items that you should consider before getting started to ensure a smooth deployment. You’ll find instructions for handling these and other issues in the attached guide.

 

Public IP Address

·      OpenDNS applies filtering settings based on the public IP address of your network. We’ll need to know your network’s public IP address before you can enable filtering settings through OpenDNS.

 

OpenDNS and email

·      Some users worry about the effect OpenDNS may have on email. A common question is “If I send email to a blocked domain, what will happen?” If you run your own mail server, take note to bullet number four in the prelaunch checklist.

 

Flushing DNS Cache

·      DNS cache is a performance-enhancing feature used by Internet browsers, computers and DNS servers to store the results of recent DNS queries in order to increase the speed of future DNS queries. When applying OpenDNS web filtering and security settings to a network, it is often useful to clear the DNS cache immediately afterwards to facilitate the new settings taking effect. Since caches store results (pages) for recent queries, new settings may appear not to work until those cache results expire or are cleared.

 

Version History
Revision #:
7 of 7
Last update:
‎08-13-2013 12:27 PM
Updated by:
 
Labels (1)

The ACMX (Aruba Certified Mobility eXpert) exam allows you to demonstrate your proficiency in provisioning and troubleshooting a multi-controller network from scratch. The exam proctor provides you with a requirements document describing the network you need to build that demonstrate various core features of an Aruba network.  You may be asked to build this network so that it supports latency sensitive traffic in a highly survivable environment.  You may need to do some troubleshooting. You may need to build firewall policies and user roles.

 

In the exam, you have an eight-hour exam window to correctly complete the objectives using the Aruba supplied controllers and APs.  (There is a mandatory lunch break for your beneifit.  The lunch time does not count towards the eight hour exam time.) You do not need to provision any third party equipment, but such equipment will be present for you to test and verify.

 

Additionally, you will need to be proficient with AirWave so it can monitor the Aruba network elements.

 

The exam is not simple.  But anyone who passed can assert that it is rewarding.  

 

See the attached study guide for more details.

 

Version History
Revision #:
4 of 4
Last update:
‎08-13-2013 12:24 PM
Updated by:
 
Labels (1)

Investment in a wireless LAN reflects recognition that mobility is important for day to day business operation. In fact, mobile networking has become business and mission critical in many environments. Physical security of the wireless infrastructure components is more difficult than securing wired infrastructure components. By their very nature, the wireless access points, antennas, and connecting cables are “out in the open” so that they provide the best wireless coverage. Of course securing the access points and antennas is desirable, and in some business verticals, it is mandated.

 

  • In Federal Government – Directive 8100.2 mandates FIPS 140-2 compliance wherein FIPS 140-2 paragraph 4.5 requires “physical security mechanisms” to be applied to wireless networks.

 

  • In Retail – The Payment Card Industry Data Security Standard (PCI-DSS) requirement 9.1.3 states that the operator must “Restrict physical access to wireless access points, gateways, and handheld devices”

 

  • In Healthcare – the TIA -1179 Healthcare facility telecommunications cabling standard specifies that, due to the life and mission critical nature of the network, additional precautions shall be taken to secure telecommunications components.

 

In addition to mandates to physically secure the wireless network, it simply makes sense from the standpoint of protecting the investment. Typically, the wireless LAN represents an investment in design, site survey, antennas, cabling, access points, and installation time. It is imperative to protect this investment, not only from theft or tampering, but also from accidental or unintentional moves and disconnects.  

 

If physical security is mandated, simply concealing the wireless access point above a suspended ceiling or in a closet is not adequate. The access point, antennas, and associated cabling should be locked in place so as to prevent theft, tampering, vandalism, and accidental disruption and disconnects. Chose a locking solution which provides for securing access points and antennas in any environment in which they will be installed, including suspended ceilings, hard lid ceilings, wall mounts, warehouses, and outdoors. The physical security solution should also anticipate moves, adds and changes, and easily permit upgrades to new access points and antennas. Additional information on wireless network infrastructure is available at http://www.oberonwireless.com

/faq-resources.php

 

 

Version History
Revision #:
3 of 3
Last update:
‎08-13-2013 12:20 PM
Updated by:
 
Labels (1)
Contributors

Aruba APs are hybrid APs that can be deployed both at the campus and the remote sites.  As long as there is a WLAN controller that can adopt the APs and push the right operational settings to them, the APs are able to perform similar functions irrespective of their geographical location.

 

The only factor that determines their capabilities are the forwarding mode they are operating in. There are different forwarding modes that can be configured. This is a decision the network engineer has to take depending on what the company requirements are.  There are networks that might want to route all their user traffic back to their datacenter where the WLAN controller resides, inspect it and then distribute them based on their destination; and  there are networks that might not care about what the user traffic; and might terminate  it right at the access layer.

 

The datapath might further change for a remote deployment where you might not want to tunnel all the traffic back to the data center. Understanding the forwarding modes is  key to delivering multicast video as efficiently as possible.

 

There are three different forwarding modes for a Aruba AP deployed at a campus – tunnel, bridge and decrypt-tunnel modes. As the name indicates traffic is either tunneled back to the controller or dropped at the access layer. Aruba leaves the decision of where the encryption/decryption should occur in a network - either at the AP or the WLAN controller.

 

As you may note decrpt-tunnel is a forwarding mode where the decryption happens at the AP; where as for tunnel mode the WLAN controller takes care of the process. Similarly, a remote AP offers a few forwarding modes as follows - tunnel, decrypt-tunnel, split–tunnel and bridge forwarding modes. In the split-tunnel mode Aps route traffic based on the policy configured. Traffic destined to the corporate network is tunneled back the WLAN controller; and generic traffic destined to the internet is routed directly saving WAN bandwidth.

 

Depending on the forwarding mode the AP is operating in – dynamics to deliver multicast video may change. The conversion of multicast to unicast might either happen at the WLAN controller, or at the AP itself. What forwarding mode supports what kind of conversion. When do I enable what? The flowchart below is a step-by-step process that the Aruba reference design team has pt together to help make this decision.

 

The attached flowchart is put together by our reference design team that should help network engineers decide the right architecture for their network.

 

 

Version History
Revision #:
4 of 4
Last update:
‎08-13-2013 12:17 PM
Updated by:
 
Labels (1)
Contributors

ACMP 6.1 Now Available

This week was a busy ACMP week.  We released the ACMP 6.1 exam with Pearson Vue so it is now available to be scheduled.  We also created an ACMP 6.1 study guide which is attached to this article.

 

Although there are many new questions in the exam, three new areas are of particular interest.  We now present questions on Spectrum Monitoring, Visual RF and the S3500.  These topics are all included in the 6.1 course material of the Mobility Boot Camp (MBC) or IAW + SWDI.

 

Exam Specs

The exam presents 75 questions in a 90 minute period.

You have the ability to mark questions for review and to go backwards.  

Passing score for ACMP 6.1 is 75%

 

Which Version Should I Take?

Both ACMP 5.0 and ACMP 6.1 are currently available. If you attended an older version of the IAW/SWDI/MBC classes (such as 5.0 or 6.0) then you should schedule to take the ACMP 5.0 exam.  If you attend a 6.1 version of the class, you should take ACMP 6.1.  This will help to ensure that the exam questions most closely align with your course content.

 

ACMP 5.0 Retires End of January 2012

Finally, we plan to retire ACMP 5.0 at the end of January 2012.  So if you want to take the 5.0 version, you need to schedule that soon.

 

We look forward to your feedback on the new exam.

 

kevin

 

Version History
Revision #:
3 of 3
Last update:
‎08-13-2013 12:15 PM
Updated by:
 
Labels (1)
Tags (1)

I've attached an article that explains how regular multi-vendor wired networks that also include Aruba wireless components can be managed together using the same Network Management suite. This focuses on the use of the Eye of the Storm (EYE) package from Entuity and highlights the fact that Aruba wireless controller based networks are a standard supported feature.

 

Version History
Revision #:
3 of 3
Last update:
‎08-13-2013 12:11 PM
Updated by:
 
Labels (2)
Contributors

What is 802.11ac?
802.11ac is the next evolution of WiFi. First there was 802.11b which provided up to 11 mbps data rates per radio in the 2.4 GHz spectrum. The next evolution was 802.11a which provided  up to 54 mbps data rates per radio in the 5 GHz spectrum. 802.11g came out shortly after  enabling 54 mbps per radio in the 2.4 GHz spectrum. 802.11n was ratified in 2009. The 802.11n spec allows for data rates up to 600 mbps per radio and the current generation of 802.11n allows for up to 450 mbps per radio. 802.11ac builds on 11n and enable wireless speeds over a gigabit per second.


2. When will 802.11ac be ratified into a standard?
The 802.11ac project was approved in September 2008. Draft 1.3 is currently available. The internal working group’s November 2011 ballot did not pass. It required 75% approval and it failed with 74% approval. Efforts are underway to address the comments and get a draft 2.0 standard. Final ratification is expected in 2013.


3. When will enterprise 802.11ac access points be available?
Enterprise 802.11ac access points are expected to hit the market sometime in 2013. Consumer devices may hit earlier. The first generation of 11ac products will likely be based on a draft of the spec similar to 802.11n.

 

For more please see attached FAQ.

 

 

Version History
Revision #:
4 of 4
Last update:
‎08-13-2013 12:08 PM
Updated by:
 
Labels (1)
Contributors

Attached is a slide deck from Airheads Vegas 2012 and Airheads Bangkok 2012. An earlier version was also presented at Airheads Dallas 2011. 

 

Topics covered in the presentation include:

 

  1. Five phase client level troubleshooting: 802.11, Authentication / Encryption, IP Assignment, Security Policy, Network Access
  2. Troubleshooting zones: Controller, Backend Server, Access Point, Wireless Client
  3. Collecting basic information about the problem
Version History
Revision #:
6 of 6
Last update:
‎08-12-2013 09:37 AM
Updated by:
 
Labels (2)
Contributors

Attached presentation from Dallas Airheads 2011 summarizes basic steps on how to start troubleshooting an Aruba remote access point (RAP) connectivity. 

 

Version History
Revision #:
2 of 2
Last update:
‎08-12-2013 09:22 AM
Updated by:
 
Labels (1)
Contributors

Attached is a presentation from Airheads Vegas 2012 and Airheads Bangkok 2012, summarizing 802.11 basics. An earlier version was also presented at Airheads Dallas 2011.  

 

For more details, take a look at the 4 part online video series on RF fundamentals below. 

Components: Transmitter, Antenna, Receiver, Isotropic Radiator, Intentional Radiator, EIRP

Characteristics: Amplitude, Frequency, Wavelength, Polarization

Behavior: Wave Propagation, RF Power, Path Loss, dBm vs. mW, Absorption, Reflection, Scattering, Diffraction, Multipath, In/Out Phase, Attenuation, Amplification

802.11 Overview: 2.4 and 5GHz channels, 802.11h (DFS & TPC), 11a/b/g vs. 11n, MIMO

 

 
 

Version History
Revision #:
5 of 5
Last update:
‎08-12-2013 09:19 AM
Updated by:
 
Labels (1)
Contributors

Attached is the presentation from Airheads Vegas 2012. A similar version was also presented at Airheads Rio 2010 and Airheads Dallas 2011. It is a must for wireless networking engineers who are challenged with supporting environments such as auditoriums, classrooms, meeting rooms where high density of mobile devices need to connect to the wireless network. Topics of discussion will include capacity planning, RF design strategies (floor, side, overhead coverage) and real world examples.

 

Topics covered include: 

 

Why are high density environments so challenging?

  • Shared Medium Access
  • Limited Number of Channels
  • Co-Channel Interference
  • Limited number of 5 GHz capable clients
  • Bad client behavior
  • Application Delivery Throughput Requirements 

How to perform capacity planning?

  • Device count 
  • Channel count
  • Target performance per device
  • Total reserve vs. capacity
  • Validation of capacity goal

What are the RF design strategies?

  • Overhead coverage (ceiling mount APs)
  • Side coverage (wall mount APs)
  • Floor coverage (under the floor APs)
  • Adjacent HD WLANs

How to configure ArubaOS for HD WLANs?

  • Optimal channel distribution
  • Optimal client distribution
  • Optimal power control
  • Optimal airtime management

Real world example

  • University auditorium, 322 seats
  • 8x AP-125s, HT20 11n design
  • ~50 laptops, ~350 iPhones + iPods

 

Version History
Revision #:
7 of 7
Last update:
‎08-12-2013 09:04 AM
Updated by:
 
Labels (2)
Contributors

Attached is the presentation on Wireless Security from 2011 Dallas Airheads conference by Jon Green, aka. jgreenA similar version was also presented at 2010 Rio, 2010 Scottsdale and 2011 Doha conferences.

 

His presentation covers the following topics: 

  • Encryption, Authentication, Access Control - all mandatory on WLANs
  • RF Engineering and myth of SSID cloaking
  • MAC address filtering and WEP - say never!
  • Cisco LEAP, EAP-FAST, WEP cloaking - say no!
  • Security principles, 802.1x, AES, Wireless IPS
  • Authorization, Guest Access

Version History
Revision #:
6 of 6
Last update:
‎08-12-2013 08:58 AM
Updated by:
 
Labels (1)
Contributors
  • OpenDNS can be used across a wide variety of networks. Since DNS is a common layer shared by any type of network, configuration is simple no matter the complexity of your network topology. The attached guide focuses on configuring your VLAN's DHCP settings in Aruba Campus WLAN OS version 6.0.1.x to point to the OpenDNS IPs (209.67.222.222, 208.67.220.220)
  • If you're using an internal DNS server let us know what you're using (BIND, Windows Server, etc.) and we'll put together instructions that are more specific to your deployment.
  • For more information, please visit www.opendns.com

 

Version History
Revision #:
6 of 6
Last update:
‎08-12-2013 08:52 AM
Updated by:
 
Labels (2)
Contributors
  • The advanced features of OpenDNS Enterprise, such as Web filtering and security, are set and managed online through the OpenDNS Dashboard. These settings are applied to your network and are subsequently inherited by all of the desktops, laptops, tablets and other mobile devices connecting to the network.
  • The attached guide explains how to add new networks to your OpenDNS Dashboard and configure your security and filtering settings. Remember, after making any changes to your OpenDNS settings, we recommend that you clear your DNS cache to ensure that the new settings are made effective. To do this, see Clearing the DNSCache.

Version History
Revision #:
5 of 5
Last update:
‎08-12-2013 08:50 AM
Updated by:
 
Labels (1)
Contributors

Attached presentation from 2012 Vegas Airheads and 2012 Bangkok Airheads conferences highlights WLAN design best practices to ensure successful interoperability with highly mobile devices. 

 

Topics covered include:

1. Device Configuration

2. Airtime Optimization

3. Roaming Optimization

4. IP Mobility Configuration

5. IP Multicast Optimization

6. Interference Resistance

 

 

 

Version History
Revision #:
8 of 8
Last update:
‎08-12-2013 08:47 AM
Updated by:
 
Labels (2)
Contributors

Attached, you can find the presentation on the topic by Chuck Lukaszewski (aka. clukas) at Barcelona 2010 Airheads Conference. Presentation highlights the following necessary design steps after summarizing the RF design challenges in stores, warehouses, manufacturing plants and outdoor areas. 

 

  • Inventory wireless devices

  • Quantify facility requirements

  • Develop coverage and client density model

  • Identify pilot sites

  • Perform virtual RF plan and site spectrum clearing walkthrough at pilot sites

  • Document plan for deployment of pilot sites

  • Execute pilot deployment

  • Perform passive site survey post deployment to verify coverage

  • Execute client testing at pilot site

  • Fine tune plan for next site 

     

     

Version History
Revision #:
2 of 2
Last update:
‎08-12-2013 08:38 AM
Updated by:
 
Labels (1)
Contributors
Attached is the presentation from 2010 Barcelona Airheads Conference on the topic.
Jeremy is following a layered approach in his presentation - here are the 6-steps!

 

Layer 0 - Why Security Matters?

Layer 1 - Secure the Environment

Layer 2 - Protect the Data

Layer 3 - Secure the Network

Layer 4 - Secure Management

Layer 5 - Audit and Report

 

 

Version History
Revision #:
5 of 5
Last update:
‎08-12-2013 07:26 AM
Updated by:
 
Labels (1)
Contributors
Attached is a presentation from 2010 Rio Airheads conference, by Chuck Lukaszewski (aka. clukas), on Outdoor WLANs and several successful case studies. Tons of practical knowledge for all interested in learning more about outdoor Wi-Fi deployments. A similar version was also presented at 2010 Washington Airheads conference. 

  • Antenna Radiation Principles & Patterns
  • Mechanical Downtilt
  • 3D Visualization and Outdoor Coverage Strategies
  • Outdoor Physical Installation Basics
  • Case Study – Railyard
  • Case Study – University Campus
  • Case Study – Manufacturing Plant 

 

Version History
Revision #:
3 of 3
Last update:
‎08-12-2013 07:20 AM
Updated by:
 
Labels (1)
Contributors

Attached presentation by Jon Green (aka. jgreen) from 2011 Doha Airheads conference covers the benefits of Aruba's PEF software module for Aruba Mobility Controllers. A similar version was also presented at 2010 Rio Airheads conference.

 

Topics covered include:

 

  • PEF basics and architecture
  • Identifying the user and role derivation
  • Enforcing security policy
  • PEF and centralized crypto
  • Integration with NAC
  • Application aware QoS
  • Policy enforcement for performance
  • Layer 3 mobility and firewall policies

Version History
Revision #:
5 of 5
Last update:
‎08-12-2013 07:07 AM
Updated by:
 
Labels (2)
Contributors

Attached is the presentation from 2012 Airheads Bangkok and 2012 Airheads Vegas on deployment best practices for voice/video over Wi-Fi. An earlier version was also presented at 2010 Airheads Rio.

 

Topics covered include: 

  • Market trends and emerging applications
  • Multimedia over WLAN challenges
  • Aruba technology for Voice and Video
  • Design best practices for multimedia
  • Troubleshooting multimedia over Wi-Fi

Version History
Revision #:
4 of 4
Last update:
‎08-12-2013 07:02 AM
Updated by:
 
Contributors

Attached is the presentation from 2010 Rio Airheads conference, presented by Peter Lane (aka. Plane) and Subbu Ponnuswamy (aka. subbu), on the topic of RF management. Presentation highlights the challenges that a WLAN infrastructure needs to overcome to deliver reliable connectivity to all of its users. Topics covered include:

 

  • Varying wireless capacity
  • Dynamic RF environments
  • RF interference avoidance
  • Channel availability and DFS
  • Client behavior

 

Version History
Revision #:
2 of 2
Last update:
‎08-12-2013 06:50 AM
Updated by:
 
Labels (1)
Contributors

Attached is the presentation by Partha Narasimhan (aka. partha) at 2010 Scottsdale Airheads conference on the topic of deploying video over 802.11n Wi-Fi. Topics covered include:

 

  • Video basics and content delivery
  • Challenges for multicast video over 802.11
  • Techniques for multicast optimization over Wi-Fi
  • Network planning and validation

Version History
Revision #:
3 of 3
Last update:
‎08-12-2013 06:46 AM
Updated by:
 
Labels (1)
Contributors

Attached is the presentation from 2010 Scottsdale Airheads conference on the topic. Starting with a quick overview of 802.11n technology, presentation provides a quick practical overview on how to:

 

  • Ensure ease of deployment and maintenance
  • Maximize network performance
  • Guarantee bandwidth availability for all clients

References to Aruba's RF management feature set are also included in the presentation.

 

 

Version History
Revision #:
2 of 2
Last update:
‎08-12-2013 06:43 AM
Updated by:
 
Labels (2)
Contributors

Attached are the presentations from 2012 Bangkok Airheads and 2012 Vegas Airheads conferences. An earlier version was also presented at 2011 Doha Airheads. 

 

They provide networking engineers and IT professionals the basic knowledge they need to define, design, deploy and operate enterprise wireless LANs. Topics of discussion includes site surveys, virtual survey tools, AP selection criteria, SSID design, wireless security, QoS and policy enforcement, campus and remote deploymets, client and network diagnostics among others. 

 

 

Version History
Revision #:
5 of 5
Last update:
‎08-08-2013 08:14 PM
Updated by:
 
Labels (1)
Contributors

Attached presentation from 2011 Vail Airheads conference provides a detailed step-by-step approach to ensure compliance for PCI 2.0 standard for Wi-Fi communications. Topics covered include:

 

 

PCI DSS 2.0

Why the need for PCI DSS

What’s new with PCI DSS v2.0

 

WLAN Threat Landscape

Rogue Management

Client Protection

Intrusion prevention

 

Mitigation Strategies

No Wireless in your network
No Wireless in Cardholder Data Environment (CDE)

Wireless in Cardholder Data Environment

 

Aruba Solution

WIPS and Policy Enforcement 

 

 

Version History
Revision #:
2 of 2
Last update:
‎08-08-2013 08:03 PM
Updated by:
 
Labels (2)
Contributors

Attached presentation from 2011 Vail Airheads Conference by Cameron Esdaile (aka. -cam-) provides a summary of the Amigopod feature set. Topics covered include:

 

  • Use Cases for WiFi in Retail
  • Quick Amigopod Overview
  • Next Generation Hotspot
  • WiFi Device Provisioning 

 

Version History
Revision #:
3 of 3
Last update:
‎08-08-2013 07:55 PM
Updated by:
 
Labels (1)
Contributors

Attached is the presentation by JeremyHaltom at 2011 Vail Airheads conference. Jeremy provides technical details on AirWave feature set and covers the following topics:

 

  • Role based administrative access
  • Tips for delivering efficient support
  • Multi-vendor wired/wireless management
  • WIPS event detection and correlation
  • VisualRF planning and location tracking

 

Version History
Revision #:
2 of 2
Last update:
‎08-08-2013 07:48 PM
Updated by:
 
Labels (1)
Contributors

The federal government, and the Department of Defense (DoD) in particular, recognizes that standards based wireless networking has become an essential part of conducting business in an efficient manner. Many commercially available products offer the capability of providing the electronic security comparable to wired networks. However, these products must be configured and secured properly to provide the degree of security desired.

 

Unlike a wired network, wherein the active components of the data communications network can be physically secured in a telecom room with restricted access, the wireless network, by its very nature, requires that access points and antennas are distributed throughput the facility, requiring consideration of policies for protecting these assets.  Attached brief provides a guide to Directives, Instructions, and STIGs regarding the wireless LAN infrastructure in federal facilities, with an emphasis on physical security requirements for the access points.

 

Version History
Revision #:
5 of 5
Last update:
‎08-08-2013 07:44 PM
Updated by:
 
Labels (2)
Contributors

Attached are the presentations from 2012 Airheads Vegas, 2012 Airheads Bangkok and 2012 Airheads Nice; they provide networking, security and application engineers with best practice information on how to support large scale BYOD initiatives.

 

Topics of discussion includes BYOD policy definition and enforcement, device onboarding and revoking access, 5-tier device profiling and examples on how to enroll different types of mobile devices namely Windows 7, MacOS, iOS and Android. 

 

 

 

Version History
Revision #:
5 of 5
Last update:
‎08-08-2013 07:37 PM
Updated by:
 
Labels (2)
Contributors

Attached are the presentations from 2012 Airheads Bangkok, 2012 Airheads Vegas and 2012 Airheads Nice; they provide all Aruba customers the latest best practices on deploying and managing an Aruba access network. Put together by Aruba’s support engineering team, presentation topics include Aruba Remote AP firmware upgrade, mesh network troubleshooting, diagnostics for client connectivity and RF performance issues, among others. 

 

 

 

Version History
Revision #:
4 of 4
Last update:
‎08-08-2013 05:06 PM
Updated by:
 
Labels (1)
Contributors

Attached is the presentation from Airheads Bangkok 2012 and Airheads Vegas 2012; it explores how network managers can ensure that enabling wireless networking does not weaken overall network security. Topics of discussion includes centralized security model, protecting against wireless intrusions, user and device level secure authentication methods, data encryption, data authorization with stateful enforcement and network access control.

 

 

 

Version History
Revision #:
3 of 3
Last update:
‎08-08-2013 04:45 PM
Updated by:
 
Labels (2)
Contributors

Attached is the keynote presentation from Airheads Bangkok 2012, by Aruba's co-founder and CSO Keerti Melkote. 

 

Version History
Revision #:
2 of 2
Last update:
‎08-08-2013 04:33 PM
Updated by:
 
Contributors

Attached are the presentations from Airheads Bangkok 2012 and Airheads Vegas 2012; they summarize the tools that IT engineers need to support large number of guest users connecting to the enterprise network. Topics of discussion include guest self-registration, authentication infrastructure design, bulk-provisioning of guest users, compliance and auditing requirements, role based administration, branding and advertising among others. 

 

 

 

Version History
Revision #:
4 of 4
Last update:
‎08-08-2013 04:27 PM
Updated by:
 
Labels (2)
Contributors

Attached is the presentation for Airheads Vegas  and Nice 2012 (please note it is the same preso for both events). It provides networking engineers tools to solve complex design and deployment challenges when it comes to extending wireless LANs to home offices, branch offices and employees on the road. Topics of discussion will include WAN connectivity options and design, different deployment scenarios based on scalability requirements per site, security enforcement for mobile devices among others.

 

 

Version History
Revision #:
5 of 5
Last update:
‎08-08-2013 04:18 PM
Updated by:
 
Labels (2)
Contributors

Attached is the presentation from Airheads Vegas 2012. It highlights the challenges in enabling an integrated management and security policy for wireless and wired access networks, and offer practical solutions to networking engineers. The topics of discussion will include centralized control of wired access switches, extending authentication to wired access ports, enforcing user & device based access rules among others.

 

 

Version History
Revision #:
2 of 2
Last update:
‎08-08-2013 04:13 PM
Updated by:
 
Labels (2)
Contributors

Attached provides a quick step by step instructions on how to provision 802.1x SSID using Aruba Mobility Controller web user interface. 

Version History
Revision #:
3 of 3
Last update:
‎08-07-2013 10:13 AM
Updated by:
 
Labels (1)
Contributors
Tags (1)

Attached document outlines configuration steps within Aruba Mobiity Controller UI to provision MAC authentication with an external server. 

 

Version History
Revision #:
3 of 3
Last update:
‎08-07-2013 10:08 AM
Updated by:
 
Labels (1)
Contributors

Attached is the presentation from 2012 Airheads Nice; this presentation provides mobile device fundamentals topics which include device characteristics such as portability, 802.11 support, etc., WLAN requirements such as roaming, QOS and Access Control, Security, etc., and Aruba design pillars such as device configuration, roaming optimization, IP multicast optimization and more.

 

Version History
Revision #:
2 of 2
Last update:
‎08-07-2013 10:03 AM
Updated by:
 
Contributors

Attached find a quick start guide on getting started with Aruba Instant. If you attended an #AirheadsLocal recently you will be receiving your free Instant AP shortly.

 

 

 

ScreenHunter_45 Jul. 19 17.36.jpg 

Version History
Revision #:
3 of 3
Last update:
‎08-07-2013 09:56 AM
Updated by:
 
Contributors

Attached is the presentation from July 24th webinar with Brad Noblet (president of BN consulting and former CIO of Dartmouth College), Charles Rumford (Network Engineer, Information Resources & Technology team (IRT) at Drexel University) and Matthew Nocifore (Senior Director of Networking, IRT at Drexel). 

 

Brad Noblet kicked off the webinar with a discussion on the challenges and best practice recommendations for the Wi-Fi site survey, AP placement and Wi-Fi capacity planning for residence halls. Charles and Matthew shared their insights, lessons learned and design/deployment best practices for supporting high density of mobile devices in residence halls. A new Wi-Fi design adopted by Drexel IRT returned with more than the double traffic usage and over 50% better student satisfaction. 

 

 

 

You can follow Drexel IRT and Charles on Twitter at Drexel_IRT and @theccr2, respectively. 

 

You can download a recording of this webinar from Aruba's corporate website, here. Aruba's reference design guide for Wi-Fi design at residence halls / dorms can be found here

 

Version History
Revision #:
4 of 4
Last update:
‎08-07-2013 09:41 AM
Updated by:
 
Labels (2)
Contributors

Airplay and Airprint on Campus Networks

An Aruba AirGroup Solution Guide

 

Enter to Win AirGroup Sweepstakes! Download and read the attached guide and submit a use-case on the community blog thread. You could win a trip for 2 to the island of Aruba!

Read Contest Terms & Conditions

 

 

 

ScreenHunter_81 Aug. 01 11.42.jpg

 

 

Version History
Revision #:
7 of 7
Last update:
‎08-07-2013 09:33 AM
Updated by:
 
Labels (2)