Extreme Networks Wirelles Student Guide

Extreme Networks
ExtremeWireless
Student Guide
Version 5.7
1
Terms & Condition of Use:
Extreme Networks, Inc. reserves all rights to its materials and the content of the
materials. No material provided by Extreme Networks, Inc. to a Partner (or
Customer, etc.) may be reproduced or transmitted in any form or by any means,
electronic or mechanical, including photocopying and recording, or by any
information storage or retrieval system, or incorporated into any other published
work, except for internal use by the Partner and except as may be expressly
permitted in writing by Extreme Networks, Inc.
This document and the information contained herein are intended solely for
informational use. Extreme Networks, Inc. makes no representations or warranties of
any kind, whether expressed or implied, with respect to this information and assumes
no responsibility for its accuracy or completeness. Extreme Networks, Inc. hereby
disclaims all liability and warranty for any information contained herein and all the
material and information herein exists to be used only on an "as is" basis. More
specific information may be available on request. By your review and/or use of the
information contained herein, you expressly release Extreme Networks from any and
all liability related in any way to this information. A copy of the text of this section is
an uncontrolled copy, and may lack important information or contain factual errors.
All information herein is Copyright ©Extreme Networks, Inc. All rights reserved. All
information contain in this document is subject to change without notice.
For additional information refer to:
http://www.extremenetworks.com/company/legal
© 2016 Extreme Networks, Inc. All rights reserved 2

Table of Contents
Configuring the Wireless Controller 6
Controller Maintenance 27
Access Point Configuration & Management 55
ExtremeCloud 101
ExtremeControl Integration 112
Virtual Network Service (VNS) Configuration 142
Hotspot 2.0 192
ExtremeAnalytics Integration 203
Authentication / RFC3580 Support 218
Radar 239
Remote Site APs 285
Captive Portal 295
Guest Portal 321
Mobility 343
Availability 359
OneView Maps 386
Mesh Networks 410

The Extreme Wireless solution includes a wide variety of access points, controllers,
management capabilities, security, as well as a unique open platform for application
integration.
The Wireless Controller, Access Points and Convergence Software solution consists
of the following components:
Wireless Controllers
Wireless APs
Wireless Manager
ExtremeControl and ExtremeAnalytics
Depending on your deployment the solution may require three other components, all
of which are standard for enterprise and service provider networks:
RADIUS Server (Remote Access Dial-In User Service) or other authentication

server
DHCP (Dynamic Host Configuration Protocol) Server for address assignment
Network Time Protocol (NTP) Server

VNS = Virtual Network Services

The Wireless Controller, Access Points, and Convergence Software system provides
a scalable solution based on the license and capacity of the controller. The Wireless
Controller Data Sheet is available on the Extreme Networks website at the following
url:
The wireless architecture allows a single Wireless Controller to control many

Wireless APs, making the administration and management of large wireless
networks much easier.
There can be several Wireless Controllers in the network, each with a set of
registered Wireless APs. The Wireless Controllers can also serve as backups to
each other, providing highly available wireless networks.
The virtual Controller comes in two versions:

V2110, used with VMWare
HV2110, used with Hypervisor

Elastic Hyper-V is TBD

The Wireless Assistant GUI is the Web-based interface for configuring, managing,
logging and monitoring of each individual controller. Because the Wireless AP does
not have a user interface the Wireless Assistant interface is used to configure and
manage each AP.
To access the EWC connect a laptop directly to the management port using a cross-
over Ethernet Cable. Set a static IP address in the 192.168.10.0/24 subnet on the
Ethernet port of your Laptop. Launch a web browser and make a secured http
connection to the Wireless Controller using the factory default IP address of
192.168.10.1 and port 5825 (https://192.168.10.1:5825).
In the User Name box type the default username of admin and password abc123 and
click the Login button.

Once you log into the Wireless Assistant the Home Screen will appear. The home
screen heading or top menu bar displays across each page within the Wireless
Assistant. Using the top menu bar, you can access Wireless Logs (Events), Reports,
Wireless Controller, Wireless APs, VNS Configuration, Radar, and online help.
The graphical view of the home screen provides real-time status information of the
current health of the wireless network from the controller’s perspective. For ease of
use, the live graphs and interactive links provide a quick launch point to reports and
configuration parameters for in-depth troubleshooting, access to logs, reports, and
configuration components.
At the foot of the Wireless Assistant home screen, important information about the
controller can be seen including error and configuration messages.
[host name | product name | up time], for example, [EWC | V2110 | 12 days, 21:16]. If
the Wireless Assistant is running the V2110 license, the footer will display V2110.
Port Status is the connectivity state of the ports.
M represents the Management interface and the numbered lights reflect the data port
interfaces on the system.
Green indicates the interface is up and running.
Red indicates the interface is down.
F icon represents the flash drive status: green if the flash drive is mounted and red if
the flash drive is not mounted

The Topologies screen on the Wireless Controller displays both physical network
port and VNS topologies.
For the Virtual Controllers physical interfaces (topologies) must be created. Once
created topologies cannot be deleted while they are active either as a Physical port
on the controller or a Virtual Network Services (VNS) that is, referenced by a Role.
Topologies can be modified by selecting and clicking the desired physical or VNS
interface.
Note: the 172.31.0.0/24 Network should NOT be used because of the internal WC
usage.

VLAN ID is used as a Controller wide identification of the topologies, however the
VLAN ID is only used for tagged topologies.
Bridge Locally at EWC (B@AC)

Bridge Locally at AP (B@AP)

The native and routed traffic on this interface is comprised of those packets which
either originate on the port itself (i.e. ARP, SSH or HTTPS management) or are the
result of a Layer 3 forwarding decision through that port (i.e. routed VNS topologies).
Excluded are the packets of VNS topologies which are configured as B@AC, these
bridged packets will have a VLAN ID tag of their own.
For traffic to properly to transfer onto the Enterprise Network, the Switch port must be
configured to egress the configured VLAN tagged traffic, i.e. vlan egress 20 ge.1.13
tagged.
VLAN ID is used as a Controller wide identification of the topologies, however the

VLAN ID is only used for tagged topologies.

The Layer 3 (L3) section of the Topology screen allows you to configure and modify
IP address and DHCP options parameters.
The Layer 3 IP address definition is only required for Physical port configuration and
Routed topologies. It is optional for B@AC topologies. L3 configuration is necessary
if services such as DHCP, captive portal, etc., are required over the configured
network segment or if you intend to manage the controller through the interface.
B@AP topologies do not require the definition of a corresponding IP address since

all traffic for WLAN clients in that VNS will be directly bridged by the Wireless AP at
the local network point of attachment.

To allow management access (SNMPv2/v3, SSH or HTTPS) on a topology select
Management Traffic to enable this feature. Once selected, the Internal Exception
Filters will be populated to allow traffic destined for the system’s management
configuration framework to enter this Port.
AP Registration is used by the Wireless APs as part of the discovery method. Ensure
that AP Registration is enabled so that Wireless APs can use this port for discovery
and registration as part of the Service Location Protocol (SLP). A Wireless
Controller configured as a Mobility Manager should also enable AP Registration
since SLP will be used by the Mobility Agents to discover the Mobility Manager.

A default route enables the Wireless Controller to forward packets to destinations
that are not present in the OSPF routing table. Dynamic routes take precedence over
static routes unless "Override Dynamic Routes" is checked when adding a static
route.

Open Shortest Path First (OSPF, version 2) (RFC2328) – Use OSPF to allow the
Extreme Networks Wireless Controller to participate in dynamic route selection.
OSPF is a protocol designed for medium and large IP networks with the ability to
segment routes into different areas by routing information summarization and
propagation. Static Route definition and OSPF dynamic learning can be combined,
and the precedence of a static route definition over dynamic rules can be configured
by selecting or clearing the Override dynamic routes option checkbox.
Enable OSPF by selecting the ON parameters from the OSPF Status pull down
menu and ensure that each interface that will be participating in the OSPF exchange
has the Port Status field set to Enabled. Although the Area Type, Default is selected
or backbone area, you can also configure the interface to belong in a Stub or Not-so-
stubby area.
Note: Only clear text authentication is supported for OSPF.

Synchronizing the Controller to a universal clock will ensure accuracy in WLAN client
session information when you are using Fast Failover, Mobility Services and usage
logs. Network time is synchronized in one of two ways: Using System Time by
manually setting the time on your Wireless Controller or using Network Time Protocol
(NTP), an Internet standard protocol that synchronizes client workstation clocks. You
can specify up to 3 different Time Servers to use or configure your Wireless
Controller to be the local NTP server on your network. The Wireless Controller
automatically adjusts for any time change due to Daylight Savings time.
Note: Changes to the NTP screen may cause the controller to reboot.

Support for static LAGs at the distribution layer (controller or virtual gateway) extends
high-availability and load balancing to the distribution/core physical connection.
Grouping one or more network interfaces into a single LAG between the controller
and the distribution/core switch, increases bandwidth capacity for centralized
deployments. LAGs also provide physical redundancy in case of a hardware failure
at the link layer on the network.
Only ports that are not assigned to a topology can be added to a LAG, QoS
scheduling is applied per port, not per LAG. When a LAG is disabled no traffic is
forwarded on the port, if the port Admin status is down, the port remains a member of
the LAG but no traffic is forward and the physical link status is down. The LAG MAC
address is the MAC address of the second physical port on the system.

Link Aggregation L2 ports are configured via the L2 Ports screen or the CLI. To a
create LAG, assign Physical ports to LAG.

The Ping and Trace Route tools are available on the Wireless Controller Utilities
section. This allows you to test the connection to a target IP address from the
controller.

The TCPdump management utility allows you to capture exception traffic that is sent
to the management plane. Exception traffic is defined as traffic that is sent to the
management plane from the data/control plane for special handing (i.e. DHCP,
OSPF and TFTP traffic). The TCP dump utility allows you to determine if packets
are being dropped in the data/control plane.
The captured traffic is stored in a binary tcpdump-format file on local hard-drive. The
captured file can be exported to a local machine for packet analysis (Wireshark,
etc.).
There are some limitations. Only one traffic capture is allowed on the system at a
single time and the controller does not permit the capture of any data plane traffic.
Lastly, WDS, Mesh and Bridge-at-AP captures are not supported.

After a capture has completed you have the ability to Export it to a file on your
desktop that can be opened by a traffic analyzer.

You can upgrade the Wireless Convergence Controller Software via the Wireless
Assistant GUI. Upgrading the WC will also update the Access Point images that are
stored on the Controller.
The Wireless Convergence Software provides two upgrade options: locally using the
image file that is located either on the local drive or flash or remotely by using an
image file that is located on an external FTP/SCP server.
If you choose to upgrade remotely you have the choice of running the upgrade
directly from the FTP /SCP server via the GUI or downloading the image file from a
remote server to the local drive of the Wireless Controller, or the flash, and then run
the upgrade locally.
Note: If the controller file does not exist the upgrade will not succeed.

You can also perform the upgrade as a scheduled task, by selecting Schedule
upgrade for: and then selecting the Month, Day, Hour and Min of the scheduled
upgrade. Once you select Schedule Upgrade you will be prompted to verify the
selection.
Once the upgrade process is completed the Controller will reboot.
Note: When you upgrade the Wireless Software, the previous SSL configuration file
is replaced with a new one. Therefore any manual edits that were made in the
previous SSL configuration files are lost.

Note: You need to install the “.ova” file when you first install the V2110. All
subsequent upgrades can be performed using the standard controller upgrade
procedure to apply a “.bge” file to the V2110.
When you install the HV2100, you must first deploy the “.ize” file. All subsequent
upgrades can be performed using the standard controller upgrade procedu4re to
apply a “.vhd” file to the HV2110.

Controllers shipped from the factory will have the “Demo Mode” license installed, the
“Demo Mode” license has limited functionality.
New activation keys are not necessary when upgrading to a minor release within the
same major version

Enables management of any 39XX from any controller, anywhere in the world

If you are upgrading to V10 from V9, you will be given a grace period of seven days
to license the software with the permanent activation key.
During the grace period, you will be able to use all the features and connect as many
Wireless APs to the Wireless Controller as you want, subject to the controller’s limit.
If you do not install the appropriate license after the expiration of the grace period,
the Wireless Controller will start generating event logs every 15 minutes, indicating
that the permanent license key is required. In addition, you will not be able to edit the
Virtual Network System (VNS) parameters.

Radar and AP capacity licenses are pooled for an Availability Pair and will work
regardless of the model or regulatory domain differences. This allows for
redistribution of licenses between appliances. Administrators can switch an AP from
Foreign to Local or Local to Foreign) without releasing the AP. The Licenses can be
installed on either member of an availability pair.
User will be able to redistribute AP capacity and Radar licenses when AP Capacity
or Radar key is installed. The granularity of distribution will be a license key;
therefore if a controller has two keys of 25 APs each, then user will be allowed to
transfer, 25 or 50 APs the former peer controller

Backing up the Wireless Controller database only involves creating a backup of
specific content in the Wireless Controller database. You can choose to back up the
whole contents of the database or specific components such as: configuration, logs,
or audit information. When a Wireless Controller database backup is processed, a
.zip file is created. The contents of the .zip file will vary depending on what type of
database backup you process.
When you back up the Wireless Controller database, you can choose to do the
following: Back up the Wireless Controller database now (the file is written directly to
the disk and the Available Backups list is updated) or Initiate a scheduled backup.
This feature gives you more flexibility in the storage as well as the time of when to
initiate a backup.
You can upload an existing backup file to an FTP server. When an existing backup is
uploaded to an FTP server for storage, the files can be viewed.

When you schedule a backup, you can either choose to save the backup to an FTP
or SCP server or have the scheduled backup saved on your system.
Schedule Backups only in a non busy hour. If backups are scheduled then the page
will show what will be backed up, the schedule on which it will occur and when the
next backup is scheduled to occur. Press the “Schedule Backups” button to configure
scheduled backups. You can run a “Backup Now” job and a scheduled backup
concurrently but this is inadvisable. Changing a scheduled backup has no impact on
a backup in progress. Only full backups are supported.
Note: If you do not specify a server in the Schedule Backups window when you
define the backup schedule, the backup is added to the Available Backups list on the
Backup tab.

Only local Backups can be restored. Therefore, backups that have been stored on a
remote server need to be copied to the Wireless controller before proceeding.

The Rescue Mode is available through console access. During the boot prompt you
can make the selection either 0: Main Mode – Starts up normal system partition or 1:
Rescue Mode – Starts system into Rescue framework.
Using the Rescue Mode from the Console you have a choice of restoring the image
from the local drive, restoring from an FTP server or using an external device like the
USB.
In order to use Rescue Mode with virtual controllers the controllers console port must
first be mapped to that of the Appliance the controller is installed in, the process is as
follows
1. You will need both a windows client with putty, and a V2110 controller both in the
“powered off” state during this setup (connected to the same host)
2. Right click V2110 in vSphere Client connection and click edit settings
3. Click Add button at the top and select Serial Port, then click next
4. Select Connect via Network option then click next
5. Select server option and in the Port URL box put telnet://192.168.0.2:888 where
the IP address is that of your ESXi Host IP address and the port is an unused
port on the Server. Leave the other options as defaults and click next then finish.
6. Go through the same steps 1-4 but do so on the windows client and select
“Client” instead of server (using the same Port URL as well).
7. Open up putty on the windows machine and start a console session using the
local com1 port (using a detached console window in ESXi makes for easier use)
8. Power on the V2110 controller and be ready to use the arrow keys in the
windows putty session to get into the recovery menu.

By selecting Force system recovery, you will get a list of backup images on the local
drive. Select the backup image you want to restore and start the process. Once the
procedure is started it is irreversible. Once the recovery completes reboot the
Wireless Controller. After the reboot, the Wireless Controller restores the backed up
image with its original configuration.
The Wireless Convergence Software enables you to recover the Wireless Controller
via the Rescue mode if you have lost its login password or if you need to change the
Radius Authentication back to Local Authentication.
Your Authentication Service Management Menu options are:

1. Set Login Mode to Local – Type 1 if the login authentication mode was set to
RADIUS based authentication, and you want to revert to the local login
authentication mode.
2. Reset Accounts and Passwords to Factory Default – Type 2 if you want to reset
the login accounts and password to factory defaults.
3. Change administrator password – Type 3 if you want to change the
administrator’s password.
4. Return back to main menu – Type B if you want to return to the main menu.

The Wireless Controller allows customers to store upgrade and rescue backup
images to USB Storage. The flash memory is hot-pluggable, i.e. user can plug in a
USB device at any time, and it will be recognized as additional storage for the
Controller. Detection may take up 5 seconds and automatically mounts the device
i.e. /mnt/flash.
To protect the Flash file system, removal must be preceded by explicitly un-mounting
the Flash card through the GUI or the CLI. This is similar to “Safely Remove
Hardware” for un-mounting USB devices in Windows systems.
If there is a USB present, the GUI or the CLI will be able to access and utilize this
extra space for controller upgrade images as well as rescue backups.

The system stores configuration data and log files for both the Controller and the AP.
These files include event and alarm logs (triggered by events), trace logs (triggered
by component activity for system debugging, troubleshooting and internal monitoring
of the software), and accounting files (created every 30 minutes, to a maximum of six
files). The files are stored in the operating system and have a maximum size of 1
GB. The accounting files are stored in flat files in a directory that is created every
day. Eight directories are maintained in a circular buffer (when all are full, the most
recent replaces the oldest). The System Log Level for the Wireless Controller and
AP are configurable in the System Maintaince Screen.
The administrator will have the option of enabling the streaming of mobile station
(MU) events to the EWC event log and to ExtremeControl regardless of the event
reporting severity level setting in the EWC GUI. Today many customers are setting
the log level to INFO to collect this MU information and as a result are having their
logs flooded with largely uninteresting events.
The Wireless Controller generates three types of log messages:
Application Logs (including alarms) – Messages that are triggered by events
Audits – Files that record administrative changes made to the system (the
GUI Audit displays changes to the Graphical User Interface on the Wireless
Controller)
Services Logs (including alarms) – Messages that are triggered by events
If SNMP is enabled on the Wireless Controller, alarm conditions will trigger a trap an
SNMP trap. An SNMP trap is an event notification sent by the managed agent (a
network device) to the management system to identify the occurrence of conditions.

The Log messages contain the time of event, severity, source component, and any
details generated by the source component. The messages are classified at four
levels of severity:
Informational - the activity of normal operation
Minor (alarm)
Major (alarm)
Critical (alarm)
The alarm messages (minor, major or critical log messages) are triggered by
activities that meet certain conditions that should be known and dealt with.
Examples of events on the Wireless Controller that generate an alarm message are:
Reboot due to failure, Software upgrade failure on the Wireless Controller, Software
upgrade failure on the Wireless AP, and Detection of rogue access point activity
without valid ID.

The “Tech Support“ function rolls up a collection of logs and system data into a
single compressed file. The process takes several minutes and may affect system
performance.
Note: Because this will create additional system load, it is advised to run this only
when needed or requested by Extreme Networks technical support.

There are multiple reports that can display Statistics and Configuration for the
controller configuration and clients that are associated to individual APs and VNSs.
The information presented in these report can help you monitor the overall status of
your wireless network.

The Reports Section contains the OSPF Neighbor table and OSPF LinkState table.
OSPF Neighbor – Displays the current neighbors for OSPF (routers that have
interfaces to a common network)
OSPF LinkState – Displays the Link State Advertisements (LSAs) received by the
currently running OSPF process. The LSAs describe the local state of a router or
network, including the state of the router’s interfaces and adjacencies.

The Extreme Networks Wireless solution optimizes distribution of the processing
load between Access Points (APs) and Wireless controllers to deliver exceptional
performance while providing ease of management. Complex, time-sensitive functions
such as QoS, encryption, policy enforcement and dynamic channel selection are
handled by the AP, while global functions like configuration, roaming, security
management, and policy control are centralized at the wireless controller.
The 3801 can achieve the following data rates but only has 1 radio.
5GHz (Radio 1) is 2x2:2 802.11ac radio (up to 866 Mbps per radio)
2.4GHz (Radio 2) is 2x2:2 802.11n radios (up to 300 Mbps per radio)
The AP3965 weighs 2.99 Kg

Once the Wireless AP is registered with a Controller can be configured. Since the
first process of the of the Wireless AP is to register, we need to configure the
Wireless AP Registration options. These options define the properties that are used
for the AP discovery Process.
The approval process by the Controller is defined by the Security Mode, which
defines how the controller will handle all unknown AP devices: Allow all Wireless
APs to connect or Allow only approved Wireless APs to connect (also referred as
secure mode).
• Allow all – If the Controller does not recognize the serial number of the AP, a new
registration record is automatically created for the AP (if it is within the license
limit), then the Controller will download a default configuration to the AP. If it
recognizes the serial number, it uses the existing registration record to
authenticate the AP and existing configuration record to configure the AP.
• Allow approved - If the Wireless Controller does not recognize the serial number
of the AP, the AP’s registration record is placed in the pending state (if within
license limits) until it is manually approved by the administrator. If the Controller
recognizes the serial number, it automatically approves the AP and downloads the
configuration for that Wireless AP. Once a pending AP is approved the default
configuration will be downloaded to the AP.
Note: During the initial setup of a large network, it is recommended to select the
Allow all Wireless APs to connect option. This option is the most efficient way to get
a large number of APs registered with the Controller.

If the Wireless Controller is configured for the security mode (Allow only approved
Wireless APs to connect) and it does not recognize the serial number of the AP, the
AP’s registration record is placed in pending state. The administrator is required to
select the pending AP individually or by type and then manually approve it.
The pending AP receives minimum configuration, which only allows it to maintain an

active link with the controller for future state change. The AP’s radios are not
configured or enabled and pending APs are not eligible for configuration operations
(WLAN Service Assignments, default configuration, radio parameters) until
approved.

If an AP does not get an IP address via DHCP upon boot up it will use 192.168.1.20.
Once the Access Point obtains its IP address it will then attempt to discover
Controllers to which it can register and authenticate or if the AP was previously
configured, it will check its configuration file for a known Controller and attempt the
connection.
If this fails it will try to obtain a Controller’s IP Address using the following methods in
parallel:
DHCP Option 78 (SLP Unicast)
Domain Name Service (DNS),
DHCP Option 60/43
Layer 2 Multicast (SLP) if L2 has Multicast enabled (Multicast and IGMP
snooping should be enabled on the switch).
The discovery process will be repeated until an IP Address of a EWC is found and
the AP is approved and authenticated. (3 minute cycle)
Once the Wireless AP has discovered the controller addresses, it sends out
connection requests to each of them. These requests are sent simultaneously. The
Wireless AP will attempt to register only with the first which responds to its request.
When the Wireless AP obtains the IP address of the Wireless Controller, it connects
and registers, sending its serial number identifier to the Wireless Controller, and
receiving from the Wireless Controller a port IP address and binding key.

The Static Configuration settings assist in the setup of branch office wireless APs,
which are typically installed in remote sites, while the Wireless Controller is in a
central office.
For IP Address Assignment, the DHCP option is enabled by default. This can be
change to a static configuration once the AP has been approved by the Controller.
The Wireless Controller Search List defines the static list of Controllers that will
manage this Wireless AP. The Wireless AP attempts to connect to the IP addresses
in the order in which they are listed during the discovery process.
Note: Once the IP Address Assignment (Static Values) or Wireless Controller Search
List is modified on the AP, this will interfere with the default discovery process. If it is
necessary to recover from this situation, you will need to reset the AP to its factory
default settings.

If the Controller is configured to Allow only approved Wireless APs to connect, when
the Controller receives AP registration requests the first two requests are ignored.
This is to allow the AP to try other controllers in the network in order to be accepted
by another controller.
When an AP is in the discovery process it will send registration requests to all

controllers that it is aware of (obtained either by DHCP, DNS, or Multicast). A
controller needs to receive 3 registration requests in order to proceed with
acceptance. In the logs above you can see that the controller received 3 registration
requests and then it authenticates and approves the AP.
When the AP goes into the pending mode it will wait for 5 minutes for approval and
then it reboots automatically. Once the AP is approved and authenticated the
software version is checked and the AP configuration is sent to the AP.

An alternative to the automatic discovery and registration process is to manually add
a Wireless AP to the Controller database. This allows you to configure an AP prior to
the approval process. When the AP connects to the Controller for approval, its
configuration will be downloaded including radio and WLAN Assignment.

An Access Point is connected to Controller for the purpose of receiving configuration,
sending back statistics and logs, forwarding authentication (EAP) traffic, DHCP
requests and performing software upgrades.
Port: 13910: Management and Data Tunnel between AP and Controller

Port: 13907: AP Registration to Controller
The connection between the Wireless Controller and AP is a User Datagram

Protocol (UDP) based tunneling protocol, called WASSP (Wireless Access Station
Session Protocol) aka CAPWAP Tunnel Protocolv2 (CTP), RFC 5415, to
encapsulate the packets and forward them to the Wireless Controller except when
the Virtual Network Services (VNS) is topology is configured for B@AP.
The CTP is also created between Wireless Controllers in a Mobility domain to allow
wireless clients to roam to Wireless APs on different Wireless Controllers.

Secure Tunnel, when enabled, provides encryption, authentication, and key
management for data traffic between the AP and/or controllers.
You have three options:
1. Encrypt control traffic between AP & Controller - Supports encryption

between an AP and Controller and/or between APs.
2. Encrypt control and data traffic between AP & Controller – All control and
data traffic is encrypted and the AP skips the registration and
authentication Phases when selected. Deployments without tunneled
topologies or Sites have no benefit by enabling Data Traffic Encryption.
3. Debug Mode – An IPSEC tunnel is established from the AP to Controller,
however traffic is not encrypted.

Extreme Wireless allows you to secure the CTP tunnel between the AP and the
Controller by using IKEv2 and IPSEC. This allows a connection to traverse the
public internet for use cases such as remote/cloud site controller operation or
management of remote branch sites.

IKEv2 does not have a mechanism for fragmenting large messages (in the case of
X.509 certificates).

Wireless AP models that support external antenna configuration required selecting
the Antennas Type for the AP. The model of the selected Wireless AP determines
the available antenna options. If an antenna type is not selected the AP will not
transmit data on any Radio.
A table of approved certified external antennas are listed in each of the Wireless
Access Point Datasheets. Additional information can be found in the Extreme
Networks Wireless External Antenna Site Preparation and Installation Guide.
Note: The antenna you select determines the available channel list and the
maximum transmitting power for the country in which the Wireless AP is deployed.

To ease the installation process, the Transmission Power Compliance table has
been incorporated into the Controller’s GUI. The installer selects the country,
antenna model, and frequency, and the Controller automatically references its built-in
Compliance Table to generate the allowable maximum transmission power for the
regulatory domain in which the Controller is deployed.

The AP Default Settings will allow modification of default values for any APs that are
initially registered to the Controller to simplify the process of adding new APs to an
existing deployment. The values that can be set as default include the WLAN
assignments, static wireless configuration options common to all Wireless APs, and
then setting for specific APs, like the Wireless Outdoor AP.
Once an Access Point is approved, default values can be modified for that specific
AP by selecting the specific AP or using the Multi-Edit function. Any AP settings that
are explicitly configured override the default values. After an AP is registered, any
changes to the default values do not affect those APs that have been configured.
The Default Common Configuration and AP Specific Configuration may play a

significant role in Availability/Mobility.

Once a particular AP has been configured with all the settings that it needs to be
deployed system-wide, these settings can be used as the default settings that are
downloaded to newly registered Access Points by using the Copy to Defaults feature
on an individual AP Properties tab. The Reset to Defaults function enables APs that
are already registered to use the new default settings.
This feature allows you to configure your first AP, test to ensure that the settings are
appropiate, then copy the settings to the default values when satisfied. Each new AP
registered to that controller will receive these same settings. APs that are already
registered can be deleted, so when they re-register they can pickup the new default
settings.

The Multi-edit function allows you to configure multiple Wireless APs simultaneously.
To configure multiple APs simultaneously you need to select the Wireless APs by
Hardware Type, and then select the Wireless APs that match the hardware type
individually. You can also select multiple hardware type and individual Wireless APs
by pressing the Ctrl Key and selecting the hardware types and specific Wireless APs.
When setting values any box or option that is not explicitly modified or attributes that
are not common to a specific AP will not be applied.
Multi-edit becomes extremely useful for configuring the Poll-Timeout value on all APs
that are involved with Fast Failover Availability.

The Access Approval screen displays all the registered Wireless APs and their
status. Actions can be performed on Wireless APs in specific states, such as
Pending, Delete, Reboot, Release or Approve.
Change Status to Pending– AP is removed from the Active list, and is forced into
discovery
Release – Release foreign Wireless APs after recovery from a failover
Reboot – Reboot the AP without using Telnet or SSH to access it
Delete – Releases the Wireless AP from the Wireless Controller and deletes the
Wireless AP’s entry in the Wireless Controller’s database

In order to protect your wireless network, add a wireless device's MAC address to a
Blacklists of WLAN clients that will not be allowed to associate with the Wireless AP.
The Blacklist is maintained by the WC but pushed to the Access Points (AP) to block
the client at the edge. The Extreme Networks controller also allows you to manage
the Blacklist by providing the Import or Export function for a list of MAC addresses in
text format.
Note: Blacklist are not shared between Controllers. In an Availability or Mobility

Configuration you must use the Import/Export feature to exchange Blacklist
information.

Enabling Use broadcast for disassociation in the Advanced AP Settings will cause an
AP to broadcast a message when disconnecting all clients instead of disassociating
each client one by one.
This will happen if the following conditions are met: If the AP is preparing to reboot,
fails over to another Controller when using Availability without Fast Failover, enters
one of the special modes [(DRM initial channel selection), or Auto Selection (ACS)]
or if a BSSID is deactivated or removed from an AP.
The benefits to this option is that it improves roaming time for the clients, provides
better broadcast/multicast performance and enhances the overall user experience.
The feature also solves the problem where clients stay associated with an AP even if
there is no true data connectivity with the AP.
This is disabled by default.

The LEDs can be configured to provide a visual indication of status: Normal (default
settings), Off, Identify (active blinking), and WDS signal strength. The WDS signal
strength enables installers to adjust the antennas to obtain an ideal alignment to
maximize signal strength. The setting defined for the AP are also persistent when
an AP is in Guardian mode.

Extreme Networks Real Capture allows on-demand collection of over-the-air traffic
for troubleshooting and problem resolution. RF performance or connectivity
problems are very dynamic and Real Capture gives administrators additional visibility
into the RF environment for quicker problem resolution and improved customer
satisfaction. Real Capture provides this functionality on servicing APs eliminating the
need to deploy dedicated sensors for this purpose.

Click Start to start real capture server on the AP. This feature can be enabled for
each AP individually. Statistics are captured using an external connection to a
Windows Wireshark client. The default capture server timeout is set for 300 seconds
and the maximum configurable timeout is 1 hour.
Captures statistics are found on the Active Wireless APs reports.

When enabled and active, Real Capture runs a daemon on the AP to allow
interfacing with WireShark. Real Capture uses ports 2002 and 2003 and puts the AP
radio into promiscuous mode (receives all packets on wireless).
Once the Real Capture has started on the Access Point, open the Wireshark
application on the PC. In Wireshark, select the Capture Options. Enter the remote
AP IP address and Port and the remote daemon port of 2002. and Null
Authentication and then select OK.
Click Start in the Wireshark Capture Options window, the AP wireless information will
be displayed.

Once saved the Remote interface information will be populated.
The AP captures all the wireless traffic except for management traffic originating from
the AP (Beacons, Probe Resp, ACK, Data Frame Retries).
Note: The captured traffic is decrypted.

The primary function of Client Balancing and Load Balancing is to distribute clients
across multiple APs covering an open area, typical deployment scenarios are
classrooms, conference halls, and other densely populated wireless user areas.
This feature is AP centric. Therefore, the load balancing process is transparent to the
client.

An AP’s response to a client request is determined by the load state of the AP and the
roaming state of the client. An AP radio can be in one of the following load states: Under-
Loaded, Balanced, Loaded or Over-Loaded.
Load Balance Group Association Rules:

AP always responds to, and accepts clients that are currently associated with that AP
regardless of the load balance state.
In a Under-Loaded State, an AP radio will respond to all Probe Requests, and accept
associating clients that are new to the group or are roaming.
In a Balanced State, an AP radio will not respond to probe requests from roaming clients, and
will reject association requests from roaming clients by responding with a unsuccessful
reason code of 17 (AP is unable to handle associated STA’s) in the Association Response. It
will only respond to probes and accept associations from clients new to the group.
In an Loaded (max load reached) or Over-Loaded state, the AP does not respond to any
Probe Request, and will reject (reason code 17) all association requests from new or roaming
clients. It will continue to reject the client until the 5 minutes timer has expired then it will treat
the AP as a new Client. It is possible a Radio may go into an Over-Loaded state, if the
average load for the group drops. This can occur when one or more radios is brought on-line
and added to the group. In an Over-Loaded state, a radio reduces its load by disassociating
some clients. The number of clients removed is the amount that will bring the radio down to
the Loaded state. The selection of clients to disassociate is based on the following rules:
First remove any inactive clients
Then remove clients with the lowest signal strength
Once a client is removed, it will not be allowed to re-associate with the same radio for a period
of 30 seconds. This will cause it to roam to another radio with a lower load.
Note: A client is considered to be roaming if it is associated with a load group member and is
probing or attempting to associate with another member of the same group

A load group is created by providing: the type of Load Group (Client Balancing or
Radio Reference), a unique name for the group, Radio and a WLAN assignment.
Radio Assignment Rules:

Radio are assigned by clicking the Radio Assignment tab, and selecting the radios
from a list
Radios already assigned to a different load group than the one being
configured will be indicated with an asterisk.
Selection of this radio is possible. If selected, the radio will be
automatically removed from the group it was previously assigned to
Each radio can be assigned to at most one load balance group
Multiple radios on the same AP do not have to belong to the same group

When you are configuring WLAN assignments in a load group, every radio in the
load group must carry every WLAN assigned to the group. Thus, when you assign a
WLAN to a load group the Controller will automatically assign that WLAN to every
radio in the group. Similarly, When you assign a radio to a load group, the controller
will automatically assign every WLAN in the group to that radio. As long as a radio is
a member of a load group, it will carry all the WLANs assigned to the group. You can
test this by deleting the WLAN from the radio on the WLAN Services page, saving,
and then refreshing. The controller will automatically reassign the WLAN to the radio.
Beginning with version 9.12, you can assign additional WLANs to radios that are
participating in either a Client Balancing or a Radio Preference load group. The
controller does NOT populate WLANs you assign to an individual radio into the rest
of the load group.
Removing an radio from a load group will result in the WLAN assignment being un-
affected. i.e., left as it was configured while a member of the load group. After the
radio is removed, WLAN assignment will be re-enabled from all WLAN assignment
pages.
For a Radio Preference load group the WLAN must be assigned to both the 11a/n
and 11b/g/n radios.

Radio Preference load group – performs both Radio band preference steering and
Radio load control. Band preference steering is a mechanism to move 11a‐capable
clients to the 11a radio on the AP, relieving congestion on the 11g radio.
Load control is disabled by default. A radio load group executes band preference
steering and/or load control across the radios on each AP in the group. Each AP
balances in isolation from the other APs, but all APs in the load group have the same
configuration related to the band preference and load control.

Load control is disabled by default. A radio load group executes band preference
steering and/or load control across the radios on each AP in the group. Each AP
balances in isolation from the other APs, but all APs in the load group have the same
configuration related to the band preference and load control.
Radio preference can now enforce # of max clients in strict mode, once the limit is
reached no additional clients will connect.

Configure your password for SSH access to your APs in the AP>AP Registration
window.
The defaults for connecting to the AP via SSH are Username = admin / password =
new2day.

Periodically, the software used by the Wireless APs is altered for reasons of upgrade
or security. The new version of the AP software is installed from the Wireless
Controller. Part of the Wireless AP boot sequence is to discover and install its
software from the Wireless Controller. The Controller has a build-in TFTP Server
that is used for software upgrade of the APs.
The Wireless AP keeps a backup copy of its software image. When a software
upgrade is sent to the Wireless AP, the upgrade becomes the Wireless AP's current
image and the previous image becomes the backup. In the event of failure of the
current image, the Wireless AP will run the backup image.
The AP Maintenance section allows you to configure how the APs will install their
software either using the software from the controlled upgrade or by a specific image,
which overrides the controlled software.
Always upgrade AP to default image allows for the selection of a default revision
level (firmware image) for all APs in the domain. As the AP registers with the
controller, the firmware version is verified. If it does not match the same value as
defined for the default-image, the AP is automatically requested to upgrade to the
default-image.
To retrieve images not currently stored on the controller use the Download AP
Images to retrieve an image from a FTP/SCP server.
Note: The choice of upgrade method is important when running in an availability
scenario. Failover response time can be delayed if an AP is required to be upgraded
when it registers on the foreign controller.

The Controlled Upgrade tab is displayed in the AP Maintenance tab only when the
Upgrade Behavior is set to Upgrade when AP connects using settings from
Controlled Upgrade. Administrators decide the version of software release that the
Access Point should be running.
The Controlled upgrade allows you to individually select and control the state of an
AP image upgrade: which APs to upgrade, which image to upgrade to or downgrade
to and when the upgrade should be performed. When performing a bulk upgrade of
Access Points the controller will perform the upgrade in groups of 10-15 Access
Points at a time.
This is usual for when upgrading controllers in an availability pair and where APs to
drop will dropped their clients when AP are downloaded with the new firmware.
Note: The system will prevent the wrong software being applied to the wrong
platform. In the case of forced upgrade, the correct image will be sent to the
appropriate hardware platform.

Access Point Tracing under the Logs and Reports allows messages to be displayed
by component for system debugging, troubleshooting, and internal monitoring of
software.
Traces are combined into a single .tar.gz file and can only be viewed by saving the
file to a directory on your computer.

The AP Inventory Report provides will a consolidated summary of all Wireless APs
registered and configured in your domain. The AP Inventory report can be exported
and save as an XML file.

Powered by Amazon Web Services
No Controller, ExtremeControl or ExtremeAnalitics are part of the offering.
Services re-implemented from the ground-up to provide a refreshed and easy-to-use
management infrastructure.
3.1 focus on Management of APs. Future releases will expand to support
management for Switches as well.
• The new subscription service is perfect for customers looking to deploy an
enterprise-grade Wi-Fi solution using the latest Wave 2 technology while
minimizing up-front costs for software, controllers and licenses.
• The subscription service scales linearly as customers’ needs for greater
coverage and density grow, network expansion is pay as you grow, only
buy what you need

Each AP can be assigned it’s own site
Accounts will allow management of several sites
Customer can apply Services across a list of sites and sub-customize
parameters according to site-specific constraints:
AP Assignment
Authentication Infrastructure
Authentication infrastructure (Radius) may be local to the site
or network reachable

There is no AP Poll interval in connectivity with the cloud
APs interact with ExtremeCloud to provide statistics reports and request
configuration changes on a 5 minute interval
If 6 minutes elapses between reports, ExtremeCloud declares the device
unreachable (until new Statistics record or registration received for that
device)

ERP = Enterprise Resource Planning

For ExtremeControl to be able to completely manage the Wireless Controller, it
requires three different simultaneous connections:
A Langley connection, which allows the Wireless Manager component of
ExtremeControl to poll the Controller for information
An SNMP connection, which allows:
The Inventory Manager application of ExtremeControl to manage the
Controller’s configurations and images
The Policy Manager application of ExtremeControl to create Policies/Roles
on the Controller
The NAC Manager application of ExtremeControl to provide Network Access
Control functions to the Controller
A CLI credential, which allows the Wireless Manager component of ExtremeControl
to push VNS configuration information to the Controller, and for the Controller to
provide Client and Threat Reports.
Langley is an encryption algorithm that requires the use of a shared secret to verify a
connection during connection setup. The Wireless Manager component of
ExtremeControl will try to connect to the Controller using Wireless Manager’s global
default Langley shared secret. By default, every Controller and every instance of
ExtremeControl ship with the same Langley shared secret.
If the shared secrets don’t match then Wireless Manager will display an event log
indicating that the shared secret must be configured before ExtremeControl can fully
manage the Controller.

For ExtremeControl management, the WC must have the appropriate SNMP
configuration.
The Wireless Controller supports Simple Network Management Protocol (SNMP)
Version 1/2c or 3, for retrieving Wireless Controller statistics and setting
configuration parameters. The Simple Network Management Protocol, a set of
protocols for managing complex networks, is used by an SNMP manager to send
messages to different devices in an IP network. Devices on the network that are
SNMP-compliant, running an SNMP agent, store data about themselves in
Management Information Bases (MIBs) and return this data to the SNMP requesters.
SNMPv3 uses a User-based Security Module (USM), therefore before access is

granted a security user and its authentication and privacy keys must be verified by
the device’s SNMP engine based on the Security Level. Every controller should have
its own unique engine id.
Use the Add User Account to create users with the Security Level, Authentication
Protocol, Privacy Protocol and related passwords to match the device.
Note: Modification of the SNMP engine will cause all SNMPv3 users keys to be reset
and will need to be reconfigured.

The controller supports Local or RADIUS Authentication mode to authenticate users
that will have access to the GUI and CLI. Local Authentication mode is enabled by
default. ExtremeControl uses the controller’s CLI to retrieve required information,
such as Client Reports and to configure the managed controllers.
The Controller supports three user groups:

Full Administrator (full administrator access rights to the user)
Read-only Administrator (user allowed to see but cannot modify settings)
GuestPortal Manager (allows the user to manage Guest accounts only)
Note: Rescue mode (covered in the Controller Maintance Module) allows you to deal
with forgotten passwords and to make Authentication mode changes outside of the
Wireless Assistant GUI/CLI.

The RADIUS Server that is configured via the VNS Global Setting page for clients on
the wireless network is the same Radius Server that can be used to authenticate
users to access the Wireless Controller Configurator.
Note: That once Radius authentication access has been configured and enabled, if
the Radius Server is unavailable or not configured properly you may not be able to
login to the Controller. To ensure that the Radius Server is configured properly use
the Test command.

Dual Authentication methods are supported on the Wireless Controller. By default
Local Authentication is configured. To configure Radius Authentication or a
combination of authentication modes select the Configure button. Administrator
users will be authenticated based on the order in the table.

The first step to integrating Wireless Controller into ExtremeControl is to Launch
ExtremeControl and integrate the existing infrastructure device into ExtremeControl
Console via SNMP V3. It is critical that ExtremeControl Console is able to
management all network devices involved in the lab network.
Begin by launching the ExtremeControl Console application. Open a WEB browser

directed to the following URL:
http://<ExtremeControl_Server_IP_Address>:8080
Select the Console link from the launch page to start ExtremeControl Console and
login.

Once the Device is added it will be displayed in the Details View, a green alarm icon
next to the device indicates that ExtremeControl has been able to contact the WC
(via SNMP).
ExtremeControl Console provides a collection of software tools that can help you
manage networks of varying complexity. Each is designed to facilitate specific
network management tasks while sharing data and providing common controls and a
consistent user interface. ExtremeControl is a family of products comprised of the
ExtremeControl Console and a suite of plugin applications. Together, they provide
comprehensive remote management support for all Extreme Networks intelligent
network management devices as well as any SNMP MIB-I or MIB-II manageable
devices.

Authorization/Device Access window where you can define users and groups and
configure their access to features available in ExtremeControl applications.

If you select SNMPv1 or SNMPv2, the window lets you enter a community name as
the password for this credential. If you select SNMPv3, you can specify passwords
for Authentication and Privacy.
To create a credential:
Click or choose authorization/Device Access from the Tools menu.
Select the Profiles/Credentials tab in the authorization/Device Access window.
In the lower half of the tab, click Add Credential. The Add Credential window opens.
Type a name (up to 32 characters) for your new credential and select a SNMP
version.

The CLI credentials are also used when executing scripts from ExtremeControl to the
managed devices. This is required for Extreme Wireless Controllers and XOS
switches. For EOS devices the CLI credentials can be used for scripts or you can
access the device directly from ExtremeControl.
Profiles are assigned to device models in the ExtremeControl database. They
identify the credentials that are used for the various access levels when
communicating with the device. When configuring profiles for Extreme Networks
Wireless Controllers, you must make sure that controllers are discovered using an
SNMPv2c or SNMPv3 profile. This profile must also contain SSH CLI credentials for
the controller. Wireless Manager uses the controller's CLI to retrieve required
information and to configure managed controllers.
When configuring CLI Credentials for Extreme Networks Wireless Controllers, you
must add the username and password Login credentials for the controller to the
Add/Edit Credential window in order for Wireless Manager to properly connect (SSH)
to the controller and read device configuration data. The Login password must be
added to the Configuration password field instead of the Login password field. The
username and Configuration password specified here must match the username and
Login password configured on the controller.

Profiles are assigned to device models in the ExtremeControl database. They
identify the credentials that are used for the various access levels when
communicating with the device. When configuring profiles for devices, the profile
may also contain CLI credentials. ExtremeControl uses these credentials for scripting
and management of specific devices. For example, Inventory Manager use scripting
to perform task on the XOS devices and Wireless Manager uses the controller's CLI
to retrieve and configured the devices.
To create a Profile:
Click or choose authorization/Device Access from the Tools menu.
Select the Profiles/Credentials tab in the authorization/Device Access window.
In the upper half of the tab, click Add Profile. The Add Profile window opens.
Type a name (up to 32 characters) for your new credential and select a SNMP
version.
If you select SNMPv1 or SNMPv2, you can select credentials for Read,
Write, and Max Access.
If you select SNMPv3, you can select credentials and security levels for
Read, Write, and Max Access.
Click Apply.
You can add another profile or click Close to dismiss the Add Profile window. Your
new profile(s) appears in the Device Access Profiles table.
The Read credential of the ExtremeControl Administrator profile is used for device
Discovery and status polling. All other SNMP communications will use the profiles
specified here.

When adding a single new device it may not make sense to use the Discovery tool,
either Add Device from any of the ExtremeControl Application including OneView.

When a device or device group is selected from the left panel, the Properties tab
shows a table listing information about your selection. Columns included here display
IP Address, Display Name, Device Type, Status, Firmware, BootPROM, Base MAC,
Chassis ID, Location, Contact, System Name, Nickname, and Description.
Additionally, User Data 1, User Data 2, User Data 3, User Data 4, and Notes
columns can be edited to provide extra information about the device.

ExtremeControl OneView is a separately licensed application that provides access to
web-based reporting, network analysis, troubleshooting, and helpdesk tools.
ExtremeControl OneView provides access to critical network information: web-based

reporting, network analysis, troubleshooting, and helpdesk tools.
The OneView wireless dashboard streamlines network monitoring with consolidated

status of all the devices and drill down ability for more details. State-of-the-art
reporting provides historical and real-time data for high level network summary
information and/or details. The reports and other views are interactive allowing users
to choose the specific variables they need when analyzing data. Web-based
FlexViews enable real-time diagnostics.
OneView’s search functionality is a powerful diagnostic tool. End systems are

searchable by port, MAC address and IP or IP/Port. The results page provides an
interactive topology map consolidating all the data sources available for that location
such as performance data and network access control data.

OneView can be launched directly from the ExtremeControl launch page of from any
ExtremeControl Component by select OneView from the Applications menu bar.

The Devices tab provides you with device details for all the devices in your network
that you are managing with ExtremeControl. You can sort and filter relevant
information for network troubleshooting.
You can also access FlexViews, view your interface and VLAN information, and
access DeviceView from this screen.

The Access Points tab display summary information for all the Access Points on your
wireless network. Click on a single AP name link to open an in-depth AP Summary
view for the selected AP. Click on an AP status Icon to open a table listing the
current alarms for the AP. Right-click on a single AP to access a menu of AP
reports.

You must tell OneView which of your network devices to collect information on. To
do so, right-click on the device(s) and choose Collect Device Statistics. Select the
Controller statistics you wish to track.
Wireless Controller statistic collection is configured differently from other devices.
When enabled the collection will include Wireless Controller, WLAN, Topology, AP
wired and wireless statistics and/or wireless client statistics.

You must also enable tracking at the interface level. To do so, right-click on your
devices and choose View Interfaces to open the Interface Summary Flexview. The
Interface Summary provides access to PortView, alarms and alarm history, interface
statistic connection and other editable values for an interface.
Note: PortView interface statistics will only be displayed if enabled.

Right-click on the interfaces upon which you want to collect statistics, and select
Collect Interface Statistics. The Collection modes can be Historical, where the
statistics are saved to the database and aggregated over time. These statistics can
be used for threshold alarms configured in the Console Alarms Manager. The other
option is Monitor Mode, where the statistics are saves to a Monitor cache for one
hour and then dropped. These are used for threshold alarms but not for OneView
reporting.

The OneView Wireless tab provides details, dashboards, Individual Reports, Client Event
History and Rogue APs, information to help you monitor the overall status and trends of your
wireless network. For example, if there is a sudden spike of traffic, dip in users or saturation
of an AP, there is often an indication that there is something occurring on network.
The Wireless Dashboard displays a selection of reports that provide highly summarized
information about the wireless network. Use the Dashboard to get a quick overview of
wireless data including associated clients by controller, bandwidth by controller, top 10 APs by
aggregate bandwidth, top 10 SSIDs by client count, Wireless Manager events, and a
controller summary report. Interactive charts allow administrators to display data over various
time periods using various data rollups.
Controllers by Associated Clients - This report shows the average number of associated
clients and the percentage of total clients per controller, on an hourly and daily basis.
Controllers by Bandwidth - This report shows the average bandwidth (in bytes) and the
percentage of total bandwidth per controller, on an hourly and daily basis.
Use the drop-down menus to select the date, and whether to display Daily, Hourly, or
Daily to Raw data. Rest your mouse on the different pie slices to see a rollover that
presents chart data. Click a pie slice to see hourly data (for the Daily option) or raw
data (for the Hourly and Daily to Raw options) in graph format.
Wireless Manager Events - This report shows the last ten Wireless Manager Events. Click on
the column headings to filter and sort the events.
Controllers Summary - This report lists summary information for each controller. Click on the
Controller link to open a more detailed Controller Summary report in a new browser tab.
APs by Aggregate Bandwidth - This report lists the top ten APs by aggregate bandwidth, on
an hourly or daily basis.
SSIDs by Client Count - This report lists the top ten SSIDs by client count, on an hourly or
daily basis.
Use the drop-down menus to select the date, and whether to display Daily or Hourly
data.

Wireless AP History can show Client History, Wired and Wireless Bandwidth. From
the AP History window the gear in the right hand corner will give you access to more
information, as well as the ability to start a Real Capture trace.
Wired Statistics especially Error packets can also be compared to the switch that the
AP is connected to this will validate if the why the errors that are seen on the AP.

Information such as bandwidth, RSS (signal strength) and packet statistic for the
client will be displayed.
Click on a client MAC address link to open a Client History report displaying
bandwidth, RSS, and packet statistics for that client. From the Client History window,
you can click a button to launch PortView for that client. A spike in dropped packets
with the low RSS value could indicate RF interference during that particular time
frame. Some RF devices such as a microwave will operate intermittently for brief
periods, where others are continues, e.g. analog video cameras. Interference can
also occur from other Wi-Fi devices operating on the same or adjacent channels.

The Client Event tab shows useful information when troubleshooting Wireless
performance:
Events are triggered by:

Client session start and end
Inter-AP roaming
IP address change
Authentication state change
Information such as bandwidth, RSS (signal strength) and packet statistic for the
client will be displayed.
Click on a client MAC address link to open a Client History report displaying
bandwidth, RSS, and packet statistics for that client. From the Client History window,
you can click a button to launch PortView, AP Summary or AP PortView for that
client. Portview will show the Overview, Wireless Details, AP History, Client History
and End-System Details is implemented.
Note: In order for OneView to populate Client Event History, client data collection
must be enabled.

The Threats tab shows devices that have been detected by the Radar WIDS-WIPS system as threats to
the wireless network. The recognized threat types include:
• Ad Hoc Device - A device in ad hoc mode can participate in direct device-to-device wireless
networks. Devices in ad hoc mode are a security threat because they are prone to leaking
information stored on file system shares and bridging to the authorized network.
• Cracking - This refers to attempts to crack a password or network passphrase (such as a WPA-
PSK). The Chop-Chop attack on WPA-PSK and WEP is an example of an active password cracking
attack.
• Denial of Service (DoS) attacks
• External Honeypot - An AP that is attempting to make itself a man-in-the-middle by advertising a
popular SSID, such as an SSID advertised by a coffee shop or an airport.
• Internal Honeypot - An AP that is attempting to make itself a man-in-the-middle by advertising an
SSID belonging to the authorized network.
• Performance - Performance issues pertain to overload conditions that cause a service impact.
Performance issues aren't necessarily security issues, but many types of attacks do generate
performance issues.
• Prohibited Device - A MAC address or BSSID is detected that matches an address entered manually
into the Radar database.
• Spoofed AP - An AP that is not part of the authorized network is advertising a BSSID (MAC address)
that belongs to an authorized AP on the authorized network.
• Client Spoof - A device that uses the MAC address of another typically authorized station.
• Surveillance - A device or application that is probing for information about the presence and services
offered by a network.
• Chaff - An attack that overloads a WIDS-WIPS causing it to miss more serious attacks or to go out
of service. FakeAP is an example of a chaff attack.
• Unauth Bridge - A device that forwards packets between networks without
authorization to do so.
• Injection - The attacker inserts packets into the communication between two devices so that the
devices believe the packet is coming from an authorized device.
The data collection options for the Threats report are access from the Console OneView collector
options, under Client History and Threat options.

The search feature in OneView allows you to search for any MAC or IP address,
Hostname of an appliance or Serial Number of a device.
By doing the search you can get a pictorial view of where the host is connected to
your network.

OneView lets you create maps of the devices and wireless access points (APs) on
your network. Begin by selecting background image to serve as a map, such as a
building or floor plan, and then position your managed devices and wireless APs on
the map.
The Maps tab Search Field can be used to locate a wireless client, if the client is
connected to an AP that has been added to a map. Enter a MAC Address, IP
address, hostname, user name in the map Search box and press Enter to start a
search for a wireless client. The search uses RSS-based (Received Signal Strength)
location services to locate the wireless client and display the approximate location of
the client on the map. The map containing the AP will be displayed centered on the
AP.

A Virtual Network Service (VNS) provides a binding between Topologies, Class of
Service, Roles and WLAN Services for WLAN devices. These unique set of
components can be created independently but are only applied to the WLAN
connection when defined in an active VNS configuration.
These unique sets of policies that are applied to the WLAN connection include but
are not limited to the following:
Topology (Routed, B@AC, B@AP, Multicast filtering, Exception Filtering, Layer 3
addressing and Layer 3 services; DHCP, Next Hop Routing)
Class of Service: Ingress / Egress Rate Profiles, 802.1p, IP DSCP/TOS , Transmit
Queues
Roles (Policy Rules, CoS, and Access Control – Allow, Deny, Contain to VLAN)
WLAN Services (Authentication (802.11i/802.1x, PSK, open, CP, external CP),
Encryption Methods (802.11i/AES, WPA, WEP), Radio Information (SSID name, IE
types, .11h, suppression), QoS (802.11e/WMM, U-APSD and Flexible Client Access)

With the Wireless Bridge Locally at EWC (B@AC) or Routed topology, the WLAN
client traffic is encapsulated and transmitted over the CTP tunnel between the AP
and the Controller. The Controller enforces system policies and filtering on the
packets. Once the filtering is enforced the value that is defined for the VLAN ID is
assigned to that packet, and the packet is bridged or routed through the configured
interface.
To support this configuration, you must define which VLAN the VNS should bridge
the traffic to. The network port on which the VLAN is assigned must be configured on
the switch, and the corresponding Wireless Controller interface must match the
correct VLAN.
A VNS port/virtual interface is created automatically on the Wireless Controller when

a new L3 IP address is defined for a topology and selected in a Role.
If OSPF routing protocol is enabled, the Wireless Controller advertises the VNS
(Layer 3) subnet as a routable network segment to the wired network and will route
traffic between the wireless devices and the wired network.

Bridged Traffic Locally at the AP (B@AP) – WLAN client traffic is directly bridged to
a VLAN at the AP network point of access (switch port). B@AP VNSes provide link
persistence in the event of loss of connectivity to the controller.
In the Multiple tagged environment where one or more Bridged Locally at AP VNS
topologies with VLAN tagging are configured, the Wireless AP has to be connected
to a VLAN aware L2 switch Trunk Port that is segmenting the network.
Configuring two untagged VNSes to the same AP but on different radios is permitted.
Note: Extreme Networks Wireless supports IPv6 wireless communications, IPv6

wireless clients communicating natively to IPv6 servers in B@AP mode
configurations. This first phase of IPv6 support addresses basic IPv6 connectivity
requirements for early adopters of IPv6 communications and provides the foundation
for future expanded IPv6 network services support.

In event of a link loss with the controller, the AP that has a B@AP topology VNS
configured will remain active and continue to provide bridged services to existing
associated WLAN clients. However, AP logging, software upgrades and
configuration changes will be unavailable until the link is re-established.
During this state the AP will stop sending Poll_Req messages and it will stop
checking for replies, but it will try to re-discover the Wireless Controller in the
background.
The user‘s EAP packets request for network access along with login identification or
a user profile is forwarded by the Wireless Controller to a Radius Server, therefore
roaming is not allowed in a 802.1x environment.
* 802.1x support for Roaming and new Client Association are only supported when
the APs are grouped in a Sites Configuration.

Maintain client session in event of poll failure – Selecting this option in the AP
Properties tab will ensure that the Wireless AP will remain active in the event of a link
loss with the controller. This option is enabled by default on all APs.
The Restart services in the absence of the controller should also be checked in case
the AP reboots and the controller is still unavailable. When enabled the AP will
maintain the Bridge at AP VNS even if the controller is still down.

VLAN tagging a VNS topology refers to the action of assigning a VLAN-ID to all
using this particular VNS topology before leaving the interface (either the Controller
or the AP).
ARP Proxy is enabled by default for the B@AC topology, ARP Proxy capabilities are
configurable for B@AP topologies. This feature minimizes the need of sending ARP
requests over the air to improved performance. The AP will respond to ARP request
for the particular MAC if it is known on the behalf of the client. This will include any
VLAN on which the request was received include the Static Egress Untagged VLAN
or any VLAN that is used for containment by the default action or rule.

A mechanism that supports multicast traffic can be enabled as part of a topology
definition; this will allow multicast traffic to be. This mechanism is provided to
support the demands of VoIP and IPTV network traffic, while still providing the
network access control.

By default, all physical ports are set with multicast support disabled. Only one non-
management plane port can be enabled for the multicast when you are supporting
VoIP (i.e. Vocera), Apple Bonjour, IPTV network traffic on Routed VNS topologies.
Otherwise, the Controller will drop the multicast traffic.
In a Routed Topology this feature is tied to the physical interface for the use of
multicast relay, therefore you need to enable multicast on the physical interface.

Multicast filters control egress of multicast received by the controller or AP.
Note: Wireless Replication allows Multicast/Broadcast messages to be sent between

Wireless Clients. If you leave Wireless Replication unchecked, multicast clients can
only communicate to devices on the wired network.
Note: The multicast packet size should not exceed 1450 bytes.

Next-hop routing – Use next-hop routing to specify a unique gateway to which
(unicast/broadcast) traffic on a VNS is forwarded. Defining a next-hop for a VNS
forces all the traffic in the VNS to be forwarded to the indicated network device,
bypassing any routing definitions of the controller's route table similar to Policy
Based Routing (PBR). In a switching environment the 802.1Q tagging can be set by
the Switch/Router.

The Next Hop Feature can be configured under the Advanced Settings in the
Topology Tab of the DHCP Configuration for a Routed Mode VNS.

Topology defines the traffic behavior for the VNS, answering the question of how the
data is going to be transferred between the Wireless Client or Mobile Unit (MU) and
the rest of the network. The topology (Routed, B@AC, B@AP) decision will depend
on the current network.
Consideration must be taken when implementing a VNS. For example, Guest

Network access via a routed or B@AC topology allows traffic to be tunneled to a
single controller to by-pass the core network and be deposited in the DMZ. Another
consideration is the location of the users and the number of controllers in the
deployment. For example, for wireless access in a remote site it does not make
sense to tunnel all the traffic to a central controller and then back to a remote site. A
bridged at AP topology makes more sense in this situation.

This is useful in places like university campus’ or large enterprise businesses where
there is a large broadcast domain.
When you create a Topology Group the controller will use an algorithm (located in
VNS/Global) to decide which VLAN to use for each client, thereby reducing the
broadcast domain.
As this can only be done at the controller you cannot use a “Bridged at AP” topology.

As stated above, if you delete a topology group that is the only thing that is deleted,
the individual topologies that were members of the group remain unaffected.
In Reports in the Topology group there is an additional column in the “Topology
Statistics” and Wired Topology Statistics” reports giving details on the Topology
Groups configured

Class of Service (CoS) refers to a set of attributes that define the importance of a
frame while it is forwarded through the network relative to other packets, and to the
maximum throughput per time unit that a station or port assignment to a specific role
is permitted.
The system limit for the number of CoS profiles on a controller is identical to the
number of policies. For example, the maximum number of CoS profiles on a C5210
is 1024.

The CoS defines actions to be taken when rate limits are exceeded.
The EWC is pre-populated with 9 Class of Service configurations similar to the Class
of Service Configurations defined in Policy Manager.
All incoming packets may follow these steps to determine a CoS:

1. Classification ‐ identifies the first matching rule that defines a CoS.
2. Marking ‐ modifies the L2 802.1p and/or L3 ToS based on CoS definition
3. Rate limiting (drop) is set.

Rate Control is part of CoS definition, the user can specify (default) role that includes
Ingress and Egress rate control. Ingress rate control applies to traffic generated by
wireless clients and Egress rate control applies to traffic targeting specific wireless
clients.
Bandwidth control limits the amount of bidirectional traffic from a mobile device. A
bandwidth control profile provides a generic definition for the limit applied to certain
wireless clients' traffic. A bandwidth control profile is assigned on a per role basis. A
bandwidth control profile is not applied to multicast traffic.
For the purpose of Rate Control, the frames are classified as being associated to
different flows that are determined by the actual wireless client session. The meter
checks compliance to a defined traffic profile and passes results to policer to trigger
appropriate actions for in- and out-of-profile packets. The policer drops the out-of-
profile packets, so that traffic maintains compliance with a defined traffic role. In-
profile frames are forwarded to the network.
Note: EWC does not perform rate shaping.

The bit-rates can be configured as part of globally available profiles which can be
used by any particular configuration. A global default is also defined.
Bandwidth control limits the amount of traffic from a mobile device. A bandwidth
control profile provides a generic definition for the limit applied to certain wireless
clients' traffic. A bandwidth control profile is assigned on a per role basis. A
bandwidth control profile is not applied to multicast traffic.
Committed Information Rate (CIR) – Rate at which the network supports data
transfer under normal operations. It is measured in kilo bytes per second(Kbps).
The Global VNS setting Bandwidth Control (traffic control) allows the configuration of
Rate Profiles which determine the amount of bidirectional traffic allowed to be
transmitted to/from a client on a VNS. Multiple Profiles can be created, each with
their own unique Committed Information Rate (CIR). Once these Profiles are created
they can be associated to individual roles.

A Role can reference up to 64 different VLANs through any combination of Default
Action, VLAN containment rules, static untagged egress VLAN list and RFC 3580
hybrid mode response.

Role configuration defines the Default Access Control, Class of Service and Policy
Rules applied to the traffic of a WLAN client. The VLAN & Class of Services
component of a Policy is created by selecting the Access Control from the drop-down
list, which includes the Global Default Access Control or “no change” and the Class
of Service. When the Containment VLAN option is selected the VLAN drop-down
box is visible and you may pick the VLAN/Topology to contain the default traffic.
Note that allow is the same as Allow.
From the Role screen both new Topologies and Class of Service configurations can
be created from the Role screen by selecting the New button.
Role can also be created using the ExtremeControl Policy Manager and pushed to
the Wireless Controller for use by VNSes.

A Role’s default Access Control is applied in the ingress direction only (into the
Bridge/AP). More information on the WLAN Service is discussed further in the
Module.

The VNS provides a technique to apply a role to allow different network access to
different groups of users based on packet Filtering/Policy Rules. The EWC supports
up to 2048 filters, 64 filters per Role.
Wireless APs obtain filter information from the Wireless Controller. Applying Policy
Rules at the Wireless AP helps restrict unwanted traffic at the edge of your network.
The 3600, 3700 and 3800 Wireless APs will support up to 64 rules.
When a filter is added to the list it is placed as the first rule. The filtering rule
sequence must be arranged in the order that you want them to take effect.
Filtering at the Wireless AP is automatic when at least one Access Control, Egress
VLAN or Rule references a Bridged at AP topology (VLAN). Therefore the Role is
automatically enforced to the AP.
AP Filtering is optional if role uses only routed or Bridged at Controller topologies.

Filtering provides the ability to create bidirectional filters. As traffic enters either the
AP or Controller parts of the IP header are examined for a match.

The Wireless Controller is pre-populated with a number of Ethertype, Port and
Protocol selections to ease the configuration of creating Classification rules.
Note: Do not use MAC address rules as alternative to MAC blacklist/whitelist,

blacklist/whitelist processing is more efficient and blocks access sooner and more
thoroughly.

The Controller gives you the ability to filter Bonjour traffic advertisements.
With Bonjour, every service automatically advertises itself. For example, if a student
has an iPhone that is running iTunes, part of the process is for iTunes to advertise
itself as a service using Bonjour. In a classroom this can result in a lot of bandwidth
consumption: 25 students advertise iTunes, which consumes airtime on that access
point; the AP forwards the advertisement into the wired network, which forwards
those advertisements out all the other APs on the VLAN.
Filtering Bonjour traffic advertisements can conserve all of that backend bandwidth.

mDNS-SD – Multicast Domain Name System – Service Discovery, this is used to
resolve host names to IP addresses within small networks.
Simple Service Discovery Protocol - is a network protocol based on the Internet
Protocol Suite for advertisement and discovery of network services and presence
information. It accomplishes this without assistance of server-based configuration
mechanisms, such as DHCP or the DNS.
Local Link Multicast Name Resolution - Allows both IPv4 and IPv6 hosts to perform
name resolution for hosts on the same local link
The mDNS-SD Query refers to the service advertisement. Configure a filter on this
Application to limit which devices can advertise services.
The mDNS-SD Response refers to the request for service. Configure a filter on this
application to limit which devices can access services.

Splitting a single station’s IPv4 traffic across multiple VLANs needs to be done with
extreme care. In the worst case it could cause a forwarding loop or duplicate delivery
of multicast & broadcast traffic.
This use of policy only makes sense in the context of a carefully planned network.
This is not something that can be “dropped into” an existing network without careful
network engineering.
Stations and Apple TVs don’t have to be “on” the same subnet to permit discovery;
each lecture room or building could contain a distinct VLAN to limit scope of multicast
discovery to what is available locally.
Multicast Rules can be used to Contain Bonjour traffic to a specific VLAN/Topology,

therefore in a Education Environment each Classroom can have it’s own Apple TVs.

Note: In the out direction Allow and Contain to VLAN mean to forward to the
station/mobile unit untagged. The Contain to VLAN can be used for traffic analysis
and to separate local multicast protocols.

The WLAN service represents unique RF, authentication, encryption and QOS
attributes of a wireless access service (802.11) for the VNS. Using the SSIDs as a
service differentiation for wireless client to connect to, APs have the ability to
advertise several SSIDs. Each AP supports up to 16 SSIDs per Access Point, 8 per
Radio.
The WLAN Service can be one of four basic types. Once the Service Type is
selected and Saved the other tabs for this WLAN Service will be displayed based on
the Service Type selected.
• Standard – A conventional service. Only APs running Wireless software can be
part of this WLAN Service. This type of service is useable as B@AC, B@AP, or
Routed VNS.
• WDS/Mesh – This represents a group of APs organized into a hierarchy for
purposes of providing a Wireless Distribution Service/Mesh Network. This type of
service is in essence a wireless trunking service rather than a service that
provides access for stations. As such this type of service cannot have policies
attached to it. It allows APs to use RF to provide both network access and data
backhaul to locations without cable or fiber.
• Third Party AP – A wireless service offered by third party APs.
• Remote - A service that resides on the edge (foreign) Wireless Controller. This
service is paired with a remotable service on the home Wireless Controller and
should have the same SSID name and privacy as the home remotable service.

A WLAN service uses the topology and CoS assigned to the VNS. There may be
cases where a default topology or CoS will be used for a specific SSID by-passing
the “Authenticated” Role or CoS assigned by the Radius Server. This allows Roles
(Filters/Cos) to be applied without assigning a topology. This provides a better
integration with ExtremeControl Policy Manager, therefore the topology is assigned
based on the WLAN Service or SSID that the end-system associates to.
Since the WLAN Service is treated like a port it is reasonable to assume that the
WLAN Service has a VLAN ID. The VLAN ID of a WLAN Service is the VLAN
assigned by the WLAN Service’s Default Topology. IF the WLAN Service does not
have an explicitly assigned default topology then its VLAN ID is the VLAN assigned
by the Global Default Role.

The Service Set Identifier (SSID) will be the name of the Broadcast Service Set
Identifier (BSSID). The BSSID is a 48-bit binary identifier that distinguishes it from
other BSSes throughout the network. The BSSID is the MAC address of the wireless
interface in the access point creating the BSS.
The WLAN Services tab displays the list of APs that have been registered and
approved on the Wireless Controller. If two controllers have been paired for
availability, each EWC’s registered Wireless APs are displayed as foreign in the
other EWC’s AP list. This list is used for the assignment of WLAN services to
individual APs, as well as to radios on each AP (Individual BSSIDs).
The following characters are not supported in the WLAN/VNS fields \, ', "

Once the configuration has been written to the AP, the VNS SSID (BSSID) assigned
to an AP Radio is displayed in the Wireless AP Radio settings.
N/A: indicates that the WLAN Service has been created however it has not been
assigned to a VNS or the Radio is not enabled.
BSSID: indicates that the WLAN Service and VNS has been created and it assigned
to that particular Radio.

The Advanced Settings of the WLAN Services for Timeout parameters define the
following components:
Idle: (pre) – The amount of time in minutes that a WLAN client can have a session on
the controller in pre-authenticated state but no active traffic is passed. The session
will be terminated if no active traffic is passed within this time. The default value is 5
minutes.
Idle: (post) –The amount of time in minutes that a WLAN client can have a session
on the controller in authenticated state but no active traffic is passed. The session
will be terminated if no active traffic is passed within this time. The default value is 30
minutes. This value also represents the amount of time the PKMID is cached on the
AP.
Session – The maximum number of minutes of service to be provided to the user

before termination of the session. Once terminating the user will re-authenticate on
the network.

802.11k allows the Mobile User (MU) to quickly identify nearby APs that are
available as roaming targets. When the signal strength of the current AP
weakens and your device needs to roam to a new AP, it already knows which
AP is the best choice.

The Wireless Controller provides basic standard wireless network security
authentication methods for WLAN clients for protection such as IEEE 802.1x,
Captive Portal, MAC Authentication or Guest Portal. Authentication method will
depend on multiple criteria, such as roaming, Availability, Mobility, ExtremeControl or
Guest Access Services.
The Auth & Acct defines the parameters to setup the Authentication and Accounting
for a WLAN Service. If the network assignment is 802.1x authentication, the user’s
request for network access along with login identification and a user profile are
forwarded by the Wireless Controller to a RADIUS Server. The following types of
authentication methods are supported: Extensible Authentication Protocol–Transport
Layer Security (EAP-TLS), EAP with Tunneled Transport Layer Security (EAP-
TTLS), and Protected EAP (PEAP).
Note: The RADIUS server must support RADIUS extension (RFC2869) for 802.1x
Authentication.

You can select various combinations of privacy and authentication on any WLAN.
However, 802.1x authentication combined with WPA2 encryption provides you the
greatest level of security.

As part of a proactive approach to Wireless Security, WLAN Service password or
network passphrases and SSID’s are evaluated when saved. If the password or
SSID does not meet the recommended security criteria a warning box will be
displayed.

Privacy is a mechanism that protects data over wireless and wired networks, usually by
encryption techniques. Wireless Controller, Access Points and Software supports:
• Static Wired Equivalent Privacy (WEP)
• Dynamic Keys (WEP) –
Note: WEP Encryption has been deprecated, and should only be used for privacy if
client devices do not support stronger privacy method
• Wi-Fi Protected Access Privacy (WPA v.1 and v.2) - Encryption is by Advanced Encryption
Standard (AES) or by Temporal Key Integrity Protocol (TKIP).
Two modes are available:
Enterprise - Specifies 802.1x authentication and requires an authentication server
• Pre-Shared Key (PSK) – Privacy in PSK mode, using a Pre-Shared Key (PSK), or shared
secret for authentication. WPA-PSK is a security solution that adds authentication to
enhanced WEP encryption and key management. WPA-PSK mode does not require an
authentication server. It is suitable for home or small office.
The PSK is a shared secret (pass-phrase) that must be entered in both the Wireless AP or
router and the WPA clients.
When you select WPA, the Controller chooses WPAv2 by default. This is the strongest
encryption method available on the Controller.
Note: Regardless of the Wireless AP model or VNS type, a maximum of 112 simultaneous
clients, per radio, are supported by all of the data protection encryption techniques listed
above.
WLAN Service configuration now receives additional validations to ensure that SSIDs and
pre-shared keys do not suffer from security weaknesses. The administrator will be allowed to
configure services with weak keys and SSIDs but will be warned that stronger ones should be
considered.

802.11r
When the Mobile User roams from one AP to another on the same network, 802.11r
streamlines the authentication process using a feature called Fast Transition (FT).
FT allows MUs to associate with APs faster. FT works with both Pre-Shared Key
(PSK) and 802.1X authentication methods.
The main application for 802.11r is VOIP so that the call will not drop due to lengthy
re-negotiation of EAP packets.

This only applies to the 37xx and later APs.

Voice over Internet Protocol (VoIP) and other WLAN devices using 802.11 wireless
local area networks require constant transmission rates and timely packet
transmission.
The Extreme Networks wireless solution provides end to end packet prioritization
using Quality of Service (QoS) capabilities in order to provide voice data or time
sensitive traffic types priority over all other traffic. Examples of this include: Wireless
QOS mode WMM (Wi-Fi Multimedia), 802.11e, 802.1p or DSCP (DiffServ
Codepoint).
QoS policies are configured for each WLAN Service and it can be applied to most all
VNS topology types. That means that every WLAN client is treated with unique QoS
settings based on the WLAN Service to which they associate even from the same
AP.

The WLAN distinguishes between two levels of QoS treatment applied to the client
traffic: wireless and wired. Wireless QoS is applied at the APs, while the wired QoS
is applied at both the APs and the Wireless Controller. QoS definition and
configuration are part of the WLAN Services specifications.
On the wired side, a class of service can define DSCP and IP/TOS markings that can
overwrite the markings in the ingress frame. A class of service can specify the
transmission queuing behavior that is applied to frames. Rate limiting can also be
considered part of overall QoS specification. Rate limiting/control is applied to all
traffic assigned to a role.
QoS is configured for each VNS and it can be applied to Routed, B@AP and B@AC
topologies. Therefore every user associated with the VNS there will be a different
behavior on the wireless traffic depending on the client that is connected.
Quality of Service (QoS) management is also provided by: Assigning high priority to
an SSID, Adaptive QoS and support for legacy devices that use SpectraLink Voice
Protocol (SVP) to prioritizing voice traffic.

Packet Fairness is the default 802.11 QoS setting, whereby clients are provided with
equal opportunity to send a packet, regardless of their bit rate capabilities. Therefore
slower clients will occupy the RF channel for longer durations than faster clients,
causing the throughput on faster clients (802.11n) to be reduced.
Flexible Client Access ensures equal airtime for all clients, as opposed to equal
number of packets. This is essential for achieving the best performance of 802.11n
client on a VNS WLAN Service that supports both 802.11n and legacy clients on the
same network.
Once enabled, Flexible Client Access (FCA) comes into play once traffic/load
exceeds the medium capacity on an 11n AP.
Airtime Fairness 802.11n clients will see the same throughput that they would if it
they were connected to an 802.11n only network and legacy clients will behave as if
connected to a legacy network because client are provided with equal channel
usage.

Flexible Client Access (FCA) can adjust the client QoS in multiple steps between
packet fairness and airtime fairness. FCA can be enabled or disabled for any given
WLAN Service in its QoS Settings tab. The level at which it is applied (between
100% Airtime Fairness and 100% Packet Fairness) is a global parameter that is set
under VNS Configuration -> Global -> Wireless QoS.
FCA should not be enabled on WLAN services that is configured to use

802.11e/WMM voice queue to preserve the quality of Voice over WLAN.

The VNS binds the WLAN Service and Role. When creating a VNS, a single overall
filtering policy applies to all the wireless devices within that specific VNS
configuration. The filtering selection will depend on the type of filtering that will be
applied to that VNS and at what state (Non-Authenticated or Authenticated). For
example, with Guest Portal and Captive Portal (Internal/External) the Non-
Authenticated Role will be applied to the users before authentication. Once the user
has been authenticated the user will be assigned the Authenticated Role that is
assigned to the VNS or a Role that is returned in the Filter-ID from a RADIUS server.
When the Wireless Controller creates this VNS, it also creates a virtual IP subnet for
that VNS where user traffic is tunneled to the Wireless Controller. Packets will
undergo the enforcement of system policies or filtering before finally being VLAN
tagged and bridged through the configured interface. In a Routed VNS, this will be
the address that the controller will advertise to the network, so that packets can be
routed to the network.

The Global Default Role definition provides a placeholder for completion of
incomplete policies for initial default assignment. If a role attribute is defined as “no
change,” the attributes are inherited from Global Default Role definitions.
The Wireless Controller ships with a Global Default Role that specifies a default
Access Control, Policy Rules and Rate Profile.
The Global Default Role parameter values are:

Default Action/Access Control = “Bridged at AP untagged”
Rate Profile = “Unlimited” or no rate control
Filter Rules = “Allow All” filter
The attributes of the Default Global Role can be modified to define more permissive
filter sets or a more restrictive Rate Control profile or a different topology.

The All Active Client, Active Clients by Wireless AP and Active Clients by VNS
reports show similar information about the clients that have been associated to the
AP via the SSID.
The Clients by AP will show your active Clients and the number of Clients associated
to that AP.

ANQP = Access Network Query Protocol - is a query and response protocol that
defines services offered by an access point, typically at a Wi-Fi hot spot
HS2 = Hotspot 2.0
RFC 5227 = IPv4 Address Conflict Detection
Online SignUp is where a customer does not have access to a HotSpot can create
their own credentials to the HotSpots in there area. Obviously the AAA servers for
the HotSpots would have to be available

Depending what option is selected from the Venue Info drop down shown in the slide
there will be different options on the second drop down menu to the right
Example:
If you selected Institutional on the left the options on the right are
• Hospital
• Long-Term Care Facility
• Alcohol and Drug Rehabilitation Centre
• Group Home
• Prison or Jail
If you selected Vehicular on the left the options on the right are
• Automobile or Truck
• Airplane
• Bus
• Ferry
• Ship or Boat
• Train
• Motor Bike

Traffic received at the controller (Controller to wireless client) if received with VLAN
tags, will retain VLAN on mirroring.
Traffic received from devices (wireless client to Controller) will be mirrored without
VLANs.
Flow Manager is used on the AP when using a Bridged@AP topology and is there to
relay either just the N-Mirror packets or the N-Mirror packets and the NetFlow
records to the Wireless Controller via the WASSAP tunnel, depending on
Configuration
Flow Manager on the Wireless Controller is used to relay the N-Mirror packets and
the NetFlow records to the ExtremeAnalytics appliance.

Flow counts considered only in relation to N-Mirroring and Flow Reporting. Flow
counts do not impact data forwarding.

Policy Role Assignments defines how the WLAN client traffic is handled (topology,
filtering rules and Class of Service (CoS)). Each VNS is configured with two Role
assignments, the Non-Authenticated and the Authenticated. When a WLAN client
associates to an SSID, it will be assigned the Non-Authenticated Role associated to
that VNS until it is Authenticated by the Controller. Once the WLAN client is
authenticated it will receive either the same Policy/Role or a different role based on
the Authenticated Role assignment defined for the VNS. The WLAN client will
maintain the same authentication/privacy and QOS parameters that were defined in
the WLAN service for that VNS.
If a RADIUS Server is used for authentication (such as in 802.1x, MAC

Authentication or Captive Portal) the Filter ID value defined in the Remote Access
Dial-in User Service (RFC2865) response from the RADIUS Server can be used to
override the default Authenticated Role assignment. If a Filter-ID value is returned
with the RADIUS Access-Message to the Controller and matches a configured Role,
the controller will assign the specified role to that user.

Authentication controls the access of connecting end systems to the network based
on supplied credentials. For Extreme Networks Wireless, the controlling of access to
the network is more than authenticating users that are connected based on the
passing or failing of authentication by an end system. Authentication methods vary in
order to cater to the types of devices that may connect to the network. For example,
although PCs allow humans to input personal credentials such as username and
password through a keyboard (Captive Portal, 802.1x (PEAP)), an IP Phone may not
provide the same interface for a human to input personal credentials, i.e. 802.1x
w/Certificate or MAC based Authentication.
Upon passing authentication, Extreme Networks Controllers and APs (V8.11) have
the capability to properly allocate network resources to authenticated users/devices
aligned with their business role. Therefore, authentication is used in conjunction with
the granular control of network resources supported through Extreme Networks
Policy implementation to automatically allocate network resources to an
authenticated user/device independent of their location.
Captive Portal and 802.1x authentication has evolved from a means to authenticate
a user onto the network to provide dynamic network assignments (Topology/VLAN)
and packet filtering (Role). RFC 3580 specifies the standard attributes currently
used for VLAN assignment (tunnel-type, tunnel-medium-type, private-tunnel-group-
id) and for Role (filter-id) and Quality of Service information.

A high level overview of how Extreme Networks Wireless Devices accomplish this
goal is explained as follows:
An authentication method is implemented between the user device connecting to the
network and the Network Access Server (NAS) in order to acquire credentials from
the user/device for validation on the network.
The Wireless Controller or the Access Point (when configured using Sites) acts as
the NAS. The NAS is responsible for communicating via a RADIUS Access-
Request, the authentication credentials from the user device along with a number of
RADIUS Attribute Value Pairs (AVP) and Vendor-Specific Attributes (VSAs) that
can be used to help the RADIUS server with its decision on how to handle the
authentication. The RADIUS server authenticates/validates the credentials, the
Server contains a database of valid users and corresponding credentials, it can
either accept or reject the based on the comparison of the credentials. If the
credentials are correct, a RADIUS Access-Accept is returned to the NAS, and if the
credentials are invalid, a RADIUS Access-Reject is returned to the NAS.

The Authentication component includes the definition of the RADIUS servers on the
enterprise network. The controller will contact up to 3 RADIUS Servers. The servers
defined here will appear as available choices when you set up the authentication
mechanism for a WLAN Service and when you create a Site. During the
configuration a Hostname (FQDN) for a RADIUS server is allowed. However, you
must configure the Host Attributes setting for your reachable DNS server.
When using MAC Authentication, the MAC Address Format can be selected to match
how the entry is created on the RADIUS Server.
Strict Mode enables the ability to change the RADIUS server setting per WLAN
service.
Note: The Wireless Controller must be configured properly via ExtremeControl, i.e.
SNMPv3 and CLI access.

This can include to allow Service-Type attributes in the Client Request Messages,
permits these attributes to be sent to the RADIUS server. (e.g. RFC3580).
If you have multiple RADIUS servers, how will they be utilized, options are:
1. 1st option is use primary RADIUS server until it fails, then only use the backup
until that fails.
2. 2nd option if the RADIUS server fails use the backup but when the primary comes
back on line requests will go back to it.
Enable RADIUS Accounting.

MAC-based authentication enables network access to be restricted to specific
devices by MAC address. The Wireless Controller queries a RADIUS server for a
MAC address when a wireless client attempts to connect to the network.
To set up a RADIUS server for MAC-based authentication, you must set up a user
account with UserID=<MAC address> and Password=MAC (or a password defined
by the administrator) for each user configured on your RADIUS Server. If the
Password box is left empty, the MAC address will act as the default password.
MAC-based authentication responses may indicate to the Wireless Controller what

VNS role should be assigned to the user when used with the Filter-ID RADIUS
attribute.
Enable MAC-based authorization on roam, if you want your clients to be authorized

every time they roam to another AP. If this feature is not enabled, and MAC-based
authentication is in use, the client is authenticated only at the start of a session.

The RADIUS Attribute Value Pairs (AVP) and Vendor-Specific Attributes (VSA) carry
data in both the request and the response for the authentication, authorization, and
accounting transactions. These Attributes can determine: a) how the user is
authenticated, i.e. authentication method supported; and b) Attributes returned via
the authentication process, i.e. Filter-ID, VLAN attributes, and the Organization
Group that the end-system is defined as belonging to in the Active Directory
database.
Mobile IAM/NAC gateways require that the SSID Attribute be selected if the
ExtremeControl Rule uses the “Location SSID”.
If the Zone is configured for either Sites or Location-Based Policy, the Zone name
can be used as the Called Station ID attribute that is sent with the Radius Access
Request message. Normally, the Controller uses the BSSID that the client connects
to as the Called Station ID attribute.
Session-Timeout (RADIUS Standard option 27) – the session timeout variable can
be returned by the RADIUS server to place an absolute time limit on the status of
“authenticated” on the WLAN client. After time (in minutes) has expired the client
session is automatically marked as non-authenticated; their filter set changes back to
“Non-Authenticated” and they are subject to captive portal authentication again.

In Microsoft IAS/Network Policy Server (NPS) the Radius Attributes can be used for
Conditions that must be matched for a particular Policy. For example, the Wireless
Controller sends the Access-Request Message to the RADIUS server, the Attribute
Value Pairs are specified including the Vendor Attributes or VSA. In the Network
Policies defined in the Network Policy Server, this particular request is going to
match the Authorized Wireless Users Policy , where the conditions are the User
Groups (Locally defined on the RADIUS Server, the Attribute User-Name is
compared to the Employees User Group), and the NAS Port Type is equal to
Wireless – IEEE 802.11. Based on the match, the Settings are further defined and
returned to the NAS; this includes the Authentication that is supported as well as
Attributes such as Filter-ID and VLAN-ID attributes. If this same user attempted to be
authenticated by a Switch or Wired Network device this Policy would not be used.

RFC 3580 Attributes can be returned in the RADIUS Access-Accept packet to the
NAS during the authentication process. Therefore, each user configured on the
RADIUS server can be associated to a NSP policy that is configured with either a
RADIUS Filter-Id that matches the name of the Role on the Controller that the user
will be assigned for the proper allocation of network resources or VLAN Attributes to
defined the network or Topology or both.
VLAN assignment allows an end-user device to be dynamically placed on a VLAN

based on the response from the RADIUS server. The Extreme Networks Controller
supports the Tunnel-Private-Group-ID (81) which defines the topology name of the
VLAN, i.e. Engineering. When the Controller or AP receives this response it will tag
all incoming traffic to that particular VLAN defined in the Topology.

The RFC3580 (ACCESS_ACCEPT) Options defined how the Controller or AP (Sites
configuration) will assign the Role and Topology for the Controller. This is a Global
Setting, therefore it is applied to all VNSes that are created.
The RADIUS Filter-ID attribute is the default value and the VLAN ID Role Mapping
table will not be displayed. If both RADIUS Filter-ID and Tunnel-Private-Group-ID
attributes are selected the VLAN ID Role Mapping table should not contain any
entries, otherwise the VLAN ID returned from the RADIUS server will be matched to
the VLAN ID Role Mapping table and not the Filter-ID that is returned in the RADIUS-
Access-Accept message.
Note: Topology (PVID) is set either Default Global Role/WLAN Default Topology or
Role Access Control (VLAN Containment).

Zones are used to define APs to a specific area. The Zone identifies a logical AP
group, which in turn can be used for area-based policy/Role assignments. Area-
Based policy allows existing Wired customers using RFC3580 assignment to extend
into the Wireless Environment, as well as to deploy the same roles across all sites,
while maintaining the specific topology.
When you check “Replace Called Station ID with Zone name in RADIUS requests”,
the Controller uses the Zone Name you’ve assigned the AP, instead of the BSSID
the user connects to, as the Called Station ID in the RADIUS Access Request. You
can configure your RADIUS server to assign either Role, or Role and topology,
based on that Called Station ID value.

For example, say that you want to give User A access to the Inventory network when
they are working in the Warehouse, but not when they are working in the office. You
would place all of the APs in the warehouse in a zone called “BuildingA”.
When User A connects to the “ProdWireless” SSID in the office, the Controller
forwards User A’s login credentials along with the Basic Service Set ID (BSSID) of
ProdWireless to the RADIUS server. You configure the server in that case to return
a Filter-ID of “Employee”, which does not give User A access to the Inventory
network.
On the other hand, when User A connects to the same SSID - “ProdWireless” in the
warehouse, the Controller forwards User A’s credentials along with the BSSID of
“BuildingA” to the RADIUS server. You configure the server in that case to return a
Filter-ID of “Warehouse Employee”, which does give User A access to the Inventory
network.

The Operator Name attribute allows the Controller to use RADIUS to authenticate a
user that does not belong to your network; that is, a user whose authentication
information is housed in a server maintained by another access provider. It carries
the operator namespace identifier and the operator name in the RADIUS Access
Request message to that provider. The operator name is combined with the
namespace identifier to uniquely identify the owner of an access network.
The Controller supports the four standard protocols for exchanging Operator
information:
TADIG, the Transferred Account Data Interchange Group codes, are defined by the
GSM. TADIG codes are assigned by the TADIG Working Group within the Global
System for Mobile Communications (GSM) Association. The TADIG code consists
of two fields, with a total length of five ASCII characters consisting of a three-
character country code and a two-character alphanumeric operator (or company) ID.
TADIG is used to test a roaming agreement between two providers, typically
for a cell service. It allows a provider to test the billability of calls to/from a
Mobile Station that is using a visited network.
REALM can be used to indicate operator names based on any registered domain
name. This operator is limited to ASCII, so any registered domain name that contains
non-ASCII characters must be converted to ASCII.
REALM is used when you have multiple domains with users in each domain
needing access to the same devices.

E212 can be used to indicate operator names based on the Mobile Country Code
(MCC) and Mobile Network Code (MNC) defined in ITU212. The MCC/MNC values
are assigned by the Telecommunications Standardization Bureau (TSB) within the
ITU-T and by designated administrators in different countries. The E212 value
consists of three ASCII digits containing the MCC, followed by two or three ASCII
digits containing the MNC.
ICC can be used to indicate operator names based on International

Telecommunication Union (ITU) Carrier Codes (ICC) defined in ITU1400. ICC
values are assigned by national regulatory authorities and are coordinated by the
Telecommunication Standardization Bureau (TSB) within the ITU
Telecommunication Standardization Sector (ITU-T). When using the ICC
namespace, the attribute consists of three uppercase ASCII characters containing a
three-letter alphabetic country code, followed by one to six uppercase alphanumeric
ASCII characters containing the ICC itself.

During the Authentication Process the RADIUS server may return a role for the user
that is not configured on the Controller. The Controller considers this an “Invalid
Role.” When the Controller receives an Invalid Role, your options are:
Have the Controller apply the Default Role (Authenticated Role)
Deny all traffic
Allow all traffic
This is a global decision on the Controller.
When you are using Authentication types that do not require RADIUS access, i.e.
WPA-PSK or Guest Portal, use the default “Apply VNS Default Role”

Note: The 3705, 3801 and 3805 entry-level APs may be limited in the maximum
throughput it can process in conjunction with Radar compared to the rest of the
product line.

Roles:
Guardian – An AP that is dedicated to performing Extreme Wireless Radar WIDS-
WIPS
Forwarder – An AP that is dedicated to forwarding traffic between wired and wireless
media
Forwarder + in-service Radar – A forwarder that simultaneously performs Radar
WIDS-WIPS on the channels that it is using for forwarding
AP role is visible on: Single AP edit page, Active APs report & Radar / Maintenance
/ Scanning APs List

Radar requires that a single controller must be delegated to host the Analysis
Engine. A data collector application, installed on each controller, receives and
manages the RF scan messages sent by each AP. The data collector forwards to the
Analysis Engine lists of all connected Wireless APs, third-party APs and RF scan
information collected from participating APs.
The Analysis Engine processes the scan data from the data collectors through
algorithms that make decisions about whether any of the detected APs or clients are
threats or are running in an unsecure environment (for example, ad-hoc mode).
APs must be part of a Radar scan profile to participate in WIDS-WIPS activity. A
scan profile is a collection of WIDS-WIPS configuration options that can be assigned
to appropriate APs. The actual configuration options depend on whether the profile is
an In-Service, Guardian or Legacy scan profile.
The Analysis Engine relies on a database of connected devices on the Extreme
Wireless Wireless system. The database is basically a compiled list of all APs and
clients connected to the controller. The Analysis Engine compares the data from the
data collector with the database of known devices.

APs are labeled as belonging to one of the following categories when they are added
to the Analysis Engine database:
• Scanning APs ‐ This is the subset of authorized APs configured to provide
WIDS‐WIPS services.
• Friendly APs ‐ These are APs that are not part of the authorized network, but they
operate in the vicinity of the authorized network. Friendly APs are operated by a
neighboring enterprise for their own use. Authorized APs based on the AP37xx,
AP 38xx, 39xx architecture can prevent authorized devices from using friendly
APs.
• Uncategorized APs ‐ APs discovered by scanning APs and which do not fall into
any other category.
• Authorized APs ‐ APs that can be used by devices authorized to use the network.
APs can be added to the list automatically (for example, if the APs are active on
the current host or the host’s availability partner) or manually.
• Prohibited APs ‐ These are APs that have been manually added to the Radar
database so that the Radar WIDS‐WIPS system will detect them and, if so
configured, protect against them. An example of manually prohibited APs might be
APs that were stolen from the authorized network and now could be used to
generate a security breach.
• Friendly or uncategorized APs can be reclassified as Authorized APs or

Prohibited APs.
• Uncategorized, Authorized or Prohibited APs can be reclassified as Friendly APs.

A station is considered “Defendable”, if it meets at least 1 of the following criteria:
• Successfully completed association to a BSSID of a WLAN Service that has WEP

or Dynamic WEP
• Successfully completed the WPA-PSK (v1 or v2) exchange
• Successfully completed 802.1x, WPA (v1 or v2) authentication
• Successfully completed MAC-based authentication, IF MAC-based authentication
(MBA) is the only authentication for the WLAN OR the RADIUS response for
MAC-based authentication sets login-lat-port =1 (fully authenticated)
• Successfully completed any form of captive portal authentication, excluding
Guest-splash
• Controller has received a CoA (Change of Authorization) request or an
approval.php request that declares the station authorized (login-lat-port or
equivalent set)
• Stations with sessions managed by the Home Controller or availability partner that
meet the above criteria and only when Fast Failover is enabled

Radar identifies and deals with threats to the EWC’s APs and their stations. For
example, rather than implementing a mechanism to detect spoofing of any AP in the
area, Radar concentrates on detecting spoofing of the EWC’s APs.
• Encryption Cracking – Attempts to recover an encryption key or encryption key

stream. Allowing transmission of messages into the authorized network.
• Denial of Service - Sending a flood of de-authentication messages to a station or
AP. These attacks prevents the victim from giving or getting service.
• Ad-Hoc Networks – Device forwards unauthorized packets between networks,
wireless to wired or wireless and wireless.
• Surveillance – Surveyor, like Radar, that listens (Passive) and transmits (Active)
802.11 frame to discovers network.
• Honeypot – AP that advertises an SSID belonging to the authorized network
without authorization (Internal) or an AP that advertises a popular SSID that
stations have a high probability of searching for and associating to (External), e.g.
default SSID “Linksys” or a HotSpot SSID.
• Rogue – AP attached to your wired network that advertises a non-approved SSID.
For example, an AP attached to your network that advertises the same
“Coffeeshop” SSID as the café across the street.
• Spoofing – Where a device pretends to be another, by advertising a BSSID (MAC
address) of an authorized AP, or another authorized station or Client.

It is important to understand that a station’s network access will only be removed
automatically in the event that removing access thwarts the attack. This is most
effective against active encryption cracking since it can prevent the station from
discovering the encryption key. In most cases blacklisting the attacker is not done
because doing so would not mitigate the attack.

Many DoS attacks consist of flooding a specific type of frame to an AP or station. Not
only can this result in an AP being put out of service but it could result in a back end
server (such as a RADIUS server) being overwhelmed and being put out of service.
Note: It is possible that some frames of the same type sent by authorized
stations will be dropped in the interest of reducing the overall load on the
network.

Channels to Monitor:
• Lists all possible 2.4GHz & 5 GHz channels.
• AP automatically skips over the prohibited channels.
• Must select at least 1 channel or assigned APs will not scan.
• No channels are selected by default.
• Tradeoff: The more channels selected the less time can be spent on each
one.
Guardians can’t defend DFS channels:

• Must listen continuously for 1 minute before transmitting.
• Guardians are likely to be jumping around channels very many times per
minute.
Guardians will not monitor prohibited channels regardless of whether they are
selected in its profile.
Configuration changes for a Guardian can only be activated on the Guardian when it
is connected to its home controller.

The List of Assigned APs is a complete list of APs local to the controller and
automatically appear once a scan profile is created. You can select the APs and
each individual Radio that will be part of the scan profile.
Note: If a Wireless AP is part of a WDS/Mesh you cannot configured it to act as a

scanner in Radar.

Switch to Guardian
• Stops it from participating in Load Groups
• Stops it from exchanging site protocol with other
site-based APs at its location
• Stops it from serving VNSs
• Dialog box lists the APs that will stop service and
lists some of the services that will be affected by
the change to Guardian
• Can cancel or allow
Mirror warning for APs being removed from
Guardian role
• Controller remembers the pre-Guardian
configuration (plus changes made to
configuration while AP was a Guardian) and
immediately applies these settings to the selected
APs

Discovered APs are displayed in the Uncategorized APs table, where they can be
reclassified as Authorized, Friendly or Prohibited.

Log messages will be generated when the threat is first detected and when the threat
stops or it is aged.

A Site can use any Role or CoS defined on the Extreme Wireless Wireless
Appliance. A Site can also use any Bridged at AP, Bridged at Controller or Routed
Topology defined in the controller. Once an AP is assigned to a Site, the controller
will preload the AP with Topologies, Roles, CoS and RADIUS server configuration
used by the Site. The AP will then be able to use these configuration items
even when the controller is unreachable.
The following guidelines are recommended to configure a secure and

easy‐to‐maintain Site:
• Use 802.1x and WPA2 Enterprise authentication and privacy.
• Do not use MAC‐based authentication (MBA) unless absolutely required.
• Do not use more than 32 policy rules within a single AP filter.
• Do not configure a Sites AP Session Availability function without an
AP‐to‐controller link.
• Do not configure the following features in a Sites configuration since they rely on a
consistent AP‐to‐controller link:
• Tunneled/Routed topologies
• RADIUS accounting
• Captive Portal

Sites is also supported in ExtremeCloud with 39xx APs and
We are now in a position to draw distinctions between Sites, and Zones. This table
identifies their major differences.
Sites are also a way for a building management company to offer wireless access to
its tenants.
Zones are a standard RADIUS attribute; use Zones when you are having the client
authenticate against RADIUS.
Use Locations when you want to apply different policies to the same user based
upon where that user connects, and you want to track each user’s location on an
ongoing basis.

• Site Name Enter a name to assign to this Site. The name is unique among Sites
on the controller. AP load group names and Site names are part of the same
space so a load group and a Site cannot have the same name.
• Local Radius Authentication: Select this checkbox to choose a local RADIUS
Server for login credentials and authentication.
• Default DNS Server: This field is used to resolve RADIUS server names to IP
addresses if necessary.
• Roles to download to member APs: Select roles that will be applied to APs with
this specific Site configuration. Physical topologies and third party AP enabled
topologies cannot be assigned to a Site.
• CoS to download to member APs: Displays the Class of Service that will be
applied to APs with this specific Site configuration.
• RADIUS Server used: Displays the list of available RADIUS servers used for this
Site. The RADIUS servers assigned to a Site override the list of RADIUS servers
in the WLAN Service definition for APs that are part of the Site.

All options selected and configured in the Sites will be applied to all APs defined
within the Sites.

Advanced Features such as Load Control and Tunnel Encryption are also defined on
a per Sites basis. When you assign an AP to a Site, it inherits the Load Control and
Tunnel Encryption configurations of the Site itself.
Secure Tunnel, when enabled, provides encryption, authentication, and key
management for data traffic between the AP and/or controllers. You have three
options:
Encrypt control traffic between AP & Controller - Supports encryption between an AP
and Controller and/or between APs.
Encrypt control and data traffic between AP & Controller – All control and data traffic
is encrypted and the AP skips the registration and authentication Phases when
selected. Deployments without tunneled topologies or Sites have no benefit by
enabling Data Traffic Encryption.
Debug Mode – An IPSEC tunnel is established from the AP to Controller, however
traffic is not encrypted.
AP registration and authentication messages (UPD13907) are merged with the IKE
negotiation when Debug Mode and Encrypt control and data traffic between AP &
Controller modes are selected.
Note: When enabled, Secure tunnel has performance degradation of 5% on the

WASSP Data Throughput and Secure Tunnel does not increase significantly AP
registration time, i.e. a 5210 Controller with 500 APs will take less than 5 minutes to
register all APs.

WLAN Assignments define the VNS that will be broadcasted by the Site; the details
of the VNS are configured using the individual tabs on the left pane.

Captive Portal deployments enable WLAN clients by allowing them to obtain an IP
address and to associate to their respective AP. Upon initial AP association, the
client session is said to be in a non-authenticated state, and the client receives the
treatment specified by the Non-Authenticated Role. While in this state, users are
typically allowed to browse a small subset of sites that advertise products or services
local to that area. This is referred to as the client being in a ‘walled garden’ since it is
an area that users are forced to ‘play’ in what is considered safe from the point of
view regarding the security of the network. Once the user attempts to access an
area outside of the ‘walled garden’, the user is then redirected to another site that
forces the user to authenticate to the network in order to move outside the secure
environment.
The Extreme Networks Wireless Controller (EWC) ships with an 802.1x, Internal and
External Captive Portal service.

If you use Internal or External Captive portal, the Controller must be in
communication with a RADIUS server. The RADIUS Server configuration
information is found under the Global Settings of the VNS Configuration.
There are four authentication types supported for Captive Portal authentication:
Password Authentication Protocol (PAP)
Challenge Handshake Authentication Protocol (CHAP – RFC2484)
Window-specific version of CHAP (MS-CHAP – RFC2433)
MS-CHAP v2 (Windows-specific version of CHAP, version 2 – RFC 2759)
The Shared Secret or key on the client (Controller) must be the same as the one
configured on the RADIUS server. The shared secret consists of up to 15 printable,
non-space, ASCII characters. The key itself is used to encrypt data within the
RADIUS packets.

There are some topology restrictions with Captive Portal. Regardless of the type of
Captive Portal you configure, the topology on your Non-Authenticated role must pass
through the Controller, so it can apply the redirect to present the log-in webpage.
When the server authenticates the user, you have the option of configuring the
server to return a user role. This allows you the same flexibility for placing users in
different topologies that you get using 802.1x authentication.

The initial mechanism used by the internal captive portal solution is a component
called the ‘redirector’. The job of this component is to evaluate data streams
originating from unauthenticated client sessions and watch for HTTP GET
commands from the WLAN client. For the redirector component to function properly
the client’s original destination site needs to be blocked by the filter set for non-
authenticated sessions.
Further, since most user homepages are stored as URLs and not IP addresses, the
WLAN client also requires the ability to resolve DNS names. If the internal captive
portal uses external html links, then the server hosting those files must also be
available in the filter set.

The Internal Captive Portal feature utilizes an integrated web server, including
several options customizable by the system administrator, that provides simple
authentication against an existing external RADIUS database. Complex portal
requirements that utilize multiple RADIUS attributes or heavy customization are best
handled by the External Captive Portal feature.
Authentication is performed to collect user information, have the user agree to a set
of terms and conditions, or to gather payment for the service. Attempts to direct
traffic outside the “walled garden” results in traffic being dropped or web sessions
returning to the login/payment page. The walled garden may also provide a series of
help pages to assist the user in signing up for or paying for the service. Once the
user has passed whatever criteria is established for access to the service they are
moved to the authenticated state.

The Authenticated Role will define the Filters/Rules that the WLAN client will obtain
once authenticated on the Network. A different Authenticated role can also be
defined by the Filter-ID returned by the RADIUS authentication request message.
The Filter-ID must match a Role that is pre-defined on the Controller.
Note: When applying CoS to a filter, AP Filtering must also be enabled.

When the WLAN client associates to the network it receives an IP address according to
the topology of the Captive Portal VNS. The user’s initial filter set is called “non-
authenticated”. This filter set is defined in such a way to allow the WLAN client access
to the portal page and to DNS resolution but little else. By default, all non-authenticated
users that are participating in a network that are using either the internal or external
captive portal have their blocked traffic checked by a module called the “redirector”. This
component reads the client’s stream of data, specifically looking for a HTTP GET
request to a resolvable IP address. When this is located, the client is redirected to the
web server that will be used for authentication.
In the case of the internal captive portal, once at the redirected site the WC integrated
web server will present the user with a form that is accessed through either HTTPS or
HTTP, depending on how you configure it. If you use HTTPS, the user will receive a
certificate error. The user is prompted to enter their credentials and submits them to the
web server, where they are then passed to a Network Access Server (NAS) located
within the WC. In turn, the NAS sends a RADIUS Access Request (which includes the
WLAN client’s credentials) message to the primary RADIUS server configured on the
Controller. The RADIUS server validates the credentials and in response it sends either
a RADIUS Access-Reject message or RADIUS Access-Accept message to the NAS.
The client is then bound by the “Default” authenticated Role (Access Control/Filter
Rules) defined for the VNS. At this point the client is typically sent to their original
destination or to a Redirection URL.
The RADIUS server could potentially return the RADIUS FILTER-ID attribute in the
Access-Accept message back to the WC, which would when specify a different Role
(access control/filter rules) that would be applied to the WLAN client.

In the Auth & Acct tab screen the RADIUS server that was created under the VNS
Global setting, will be used as part of the authentication process. Selecting the
Configure button will display the information that will be used to contact the RADIUS
Server, such as the authentication type, Authentication port and NAS information.
The NAS information can be used in the RADIUS server as attributes to determine
how the RADIUS Server processes the RADIUS Accept message.

Encryption Select the data encryption to use. Options are:
• None
• Legacy
• AES
Shared Secret Type the password common to both the Extreme Wireless Appliance
and the external Web server if you want to encrypt the information passed between
the Extreme Wireless Appliance and the external Web server.
Redirection URL Type the URL to which the wireless device user will be directed to
after authentication.
Note: The Redirection URL does not support IPv6.
Add EWC IP & Port to redirection URL Select the checkbox to enable redirection.

Firewall Friendly External Captive Portal is designed for situations where you wish to
authenticate the client against a server that is on the other side of a firewall from the
Controller.
Firewall Friendly Captive Portal Use Cases:

• Social login: verifying users against their already-existing social media
accounts
• Pay-per-use
• Marketing analytics
• Location tracking

The Redirection URL options allow you to configure which options will be included in
both the URL the Controller sends the client, and the encrypted URL the server sends
the client.
The options in the Redirect to External Captive Portal field are:
• Identity: the name of this Controller on the External Captive Portal server
• Shared Secret: the key the two devices use in the signature process, should be
between 16 and 64 characters long
• Redirection URL: the URL of the External Captive Portal server
• EWC IP and Port: necessary if the ECP interacts with more than one Controller; it
specifies the IP address the ECP will redirect the client to. Use the IP address the
Controller has on the Captive Portal VNS.
• Replace EWC IP with EWC FQDN: enter the FQDN of the EWC if you use
this option
• AP name and serial number: include this if the ECP server needs it to establish the
correct role for the user according to location
• Associated BSSID: include this if the ECP server needs it to establish the correct role
for the user; fulfills the same function as the Called-Station ID RADIUS TLV
• VNS Name: include this if the ECP server needs it to establish the correct role for the
user
• Station’s MAC address: include this if the ECP server needs it to establish the correct
role for the user; fulfills the function of the Calling Station-ID RADIUS TLV
• Currently assigned role: contains the name of the clients current (unauthorized) role
• Containment VLAN (if any) of assigned role: included if the current role has a default
action of “Contain to VLAN”
• Timestamp: required to avoid Controller interaction with RADIUS server
• Signature: required to avoid Controller interaction with RADIUS server

The options in the Redirect From External Captive Portal field are:
• Enable https support: check this box if you want to use https in your
communication with your clients. This is the default, and the most secure option.
The Controller will use a self-signed certificate by default; most browsers will warn
the user of this fact. If this service is to be used by large numbers of users or by
casual users it is best to obtain a certificate from a CA that is trusted by all
browser vendors, and install it on the topology that stations have direct access to.
• Send Successful Login to: choose where you want the client to land. You can
send the client to the Captive Portal Session Page, a custom URL, or the client’s
originally requested page.

The Firewall Friendly Captive Portal option allows you to minimize the need to open
firewall ports when your Controller and the portal server are on opposite sides of the
firewall. Configure your portal according to the fields below.
Identity: Type the name common to both the Extreme Wireless Appliance and the
external Web server if you want to encrypt the information passed between the
Extreme Wireless Appliance and the external Web server.
Shared Secret: Type the password common to both the Extreme Wireless Appliance
and the external Web server if you want to encrypt the information passed between
the Extreme Wireless Appliance and the external Web server.
EWC Connection: In the drop-down list, click the IP address of the external Web
server. and then enter the port of the Extreme Wireless Appliance. If there is an
authentication server configured for this VNS, the external Captive Portal page on
the external authentication server will send the request back to the Extreme Wireless
Appliance to allow the Extreme Wireless Appliance to continue with the RADIUS
authentication and filtering.
Select Enable https support if you want to enable HTTPS support (TLS/SSL) for this
external captive portal.

On the Auth & Acct tab select Configure after selecting Internal in the Authentication
Mode drop-down box. Select either to upload the Captive Portal content or select
Manual Setting for the Web Page formatting. The Captive Portal Settings page
prepares the Web Page that will be presented to the WLAN client for authentication.
Some important configuration requirements include:
References to images within an external html files need to be formatted like this:
<img src=”http://10.170.1.15/mypicture.gif”> in order for them to operate correctly
when used in conjunction with the captive portal page. The html file must only
contain html code. Javascript, redirects or dynamic CS is not permitted.
Note: If Fully Qualified Domain Names (FQDN’s) are used within the external html
file then the WC’s primary and/or secondary DNS settings must be set under the
Wireless Controller Host Attributes Settings or the WC will not be able to resolve the
hostnames.

Configuration informational and error messages can be customized. All URLs
referenced in the Captive Portal setup must also be specifically identified and be
allowed in the VNS default non-authenticated Role.

The elements that make up the Captive Portal Web Page (Login and Index,
Topology Changes), allow administrators to customize the internal Captive Portal
page, this same Editor can be used for Guest Portal and Guest Splash.
Note: The Captive Portal Editor page supports one administrator editing a captive
portal page at one time. The total storage for all portal data is 25MB.

Once the Captive Portal configuration has been completed, it can be displayed to
view how the Captive Portal web page will look to users by clicking on the Preview
button in the Design Management section.
The Message Box will be displayed above the Login box to greet the user. The
message could explain why the Captive portal page is appearing, and provide
instructions for the user or support information.

Create the VNS, which pulls together all the components that make up this Captive
Portal VNS. Once the WLAN Service, Non-Authenticated Role, and Authenticated
Role are selected from the down-down boxes, Save the configuration. Once the
VNS is saved the configuration will be propagated to the selected APs configured
within the WLAN Server. The SSID will then be broadcasted to available WLAN
clients and the Virtual Interface will be created and assigned the Layer 3 IP address
which was defined in the topology section.
As part of the RADIUS Accept message there are several standard attributes that
can be returned which can assist in altering a WLAN client’s behavior after the
authentication process has concluded.
Filter-ID (RADIUS standard option 11) – the Filter ID attribute can be returned by the
RADIUS server to assign the authenticated session a filter/role other than ‘Default’.
The return value is an ASCII string that matches a Role Name defined in the VNS
configuration. For example, the Filter-ID:Employee or Filter-ID: Extreme
Networks:version-1:policy=Employee will assign the Access Control and Filter Rules
that correspond to the Employee role.

In the example above, the WLAN client had requested a web site outside of the non-
authenticated filter and has been redirected to the Internal Captive Portal page for
authentication where the WLAN client credentials are entered for authentication
purposes.
Reports: Active Clients by VNS shows that the WLAN client was given an IP Address
and assigned the Non_Authenticated Role, the non-authenticated filter.
Note: If DNS is not able to resolve the requested Web site the redirection will not
occur.

As displayed within this example, the Extreme Networks WC: Events Logs display
user “Student was properly authenticated and was assigned the Default
Authenticated Role “Student” therefore the user will be able to access the network
with restrictions. The Report: Active Clients by VNS shows that the Auth/Priv is equal
to Int. Captive Portal (CP), the authenticated user “Student” and the Role “Student”,
the Default Authenticated role defined for the Captive Portal VNS.
As displayed within this example, the WC: Events and Report: Active Clients by VNS
show that the user “Faculty” was authenticated successfully and the Filter-ID “Guest”
was returned from the RADIUS server during the authentication process therefore
the Faculty was assigned the Guest Role.

GuestPortal is similar to internal Captive Portal, where it provides WLAN clients
temporary guest network services, except that User Account information is stored in
a database on the Controller instead of an external authentication server. The
database is administered through a simple, user-friendly graphical user interface that
can be used by a non-technical staff member.

When the WLAN client associates to the network it receives an IP address according
to the topology of the Guest Portal VNS. The user’s initial filter set is called “non-
authenticated”. This filter set is defined in such a way to allow the WLAN client
access to the portal page and to DNS resolution but little else. By default, all non-
authenticated users that are participating in a network that are using either the
internal or external captive portal have their blocked traffic checked by a module
called the “redirector”.
This component reads the client’s stream of data looking specifically for a HTTP GET
request to a resolvable IP address. When this is found the client is redirected to the
web server that will be used for authentication.
In the case of Guest Portal, once at the redirected site the WC integrated web server
will present the user with a form that is accessed through HTTPS or HTTP,
depending on how you configure it. If you use HTTPS, the user will receive a
certificate error. The user enters their credentials and submits them to the web
server, which passes them to the WC for authentication. If the WLAN client
credentials are successfully authenticated, the client is then bound by the “Default”
authenticated role (access control/filter rules) defined for the VNS. At this point the
client is typically sent to their original destination or to a Redirection URL.

The GuestPortal administrator is assigned to the GuestPortal Manager login group
by the Administrator. The GuestPortal administrator can only create and manage
guest user accounts. Any user who logs on to the Wireless Controller and is
assigned to this group will only be allowed access to the GuestPortal Guest
Administration page of the Wireless Assistant if there is a GuestPortal WLAN Service
configured.

A GuestPortal administrator cannot access any areas of the Wireless Assistant and
CLI other than the GuestPortal User Administration Page. From the GuestPortal
Guest Administration page of the Wireless Assistant you can add, edit, configure,
and import and export Guest Accounts.

GuestPortal account ticket can be viewed and printed from the GuestPortal Guest
Administration screen. A GuestPortal account ticket is a print-ready form that
displays the guest account information, system requirements, and instructions on
how to log on to the guest account.
The Extreme Networks WC is shipped with a default template for the GuestPortal
account ticket. The template is an html page that is augmented with system
placeholders that display information about the user.

The GuestPortal Virtual Network Service (VNS) can be created as a new VNS or can
be configured from an already existing VNS. The Wireless Controller is allowed only
one GuestPortal-dedicated VNS at a time. Under the Guest Portal configuration
section of the VNS you can perform the following functions outside of configuring the
page itself:
Manage Guest Users - allows you to add and configure guest user accounts,
this can only be done after the full creation of the GuestPortal VNS
Configure Ticket Page - allows you to upload a custom GuestPortal ticket
template, which is the ticket that is printed and given to the guest.

You can configure a Guest portal limit for concurrent sessions per account. The
option is configured globally for the guest portal. You can define between 1-10 or
unlimited concurrent sessions, defined as the number of sessions established using
the same user name. If you are having all your guests use the same account, leave
this value set to 0.
This option allows you to reduce the number of non-authenticated portal connections
on the Guest Portal, a symptom with Apple devices that have multiple connections
before authentication. HTTP requests coming from non-authenticated clients are
redirected to the internal/external/guest portal page if and only if the HTTP "User-
Agent" header data field in the request contains a keyword.
The Maximum Concurrent Session setting can also limit the number of devices a
Guest can authenticate onto the network.

By selecting the Add Guest Account button the Add Guest User screen is displayed.
Create the credentials for the user including the Username, User ID, Password and
description. A User ID prefix is added to all guest account user IDs. The default is
Guest and the password is auto-generated; however, the default password and User
ID prefix can be modified.
Other values of interest include the Account Lifetime, which specifies the number of
days that the account will be active. Maximum Session Lifetime is the allowed
cumulative total in hours spent on the network during the account lifetime (0
indicates there is no session lifetime restriction).
Lastly, specify a Start time for the session for the new guest account and the End
Time. For example, in a Hotel environment this would be the check-in date and the
check-out date for a guest.

A Guest Account must be enabled in order for a wireless device to use the guest
account to obtain guest network services. When a guest account is disabled, the
account will continue to remain in the database. However, the account will not
provide access to the network.

When creating the .csv file for importing use the format above, Columns A – D are
the User Credentials (User ID, User Name, Password and Description), Column E
specifies the Account Activation Date, and Columns F and G are reserved for the
Account Lifetime (Days) and Session Lifetime (Hours). The data in Column H will
enable or disable the account and other parameters also include the (I) Time of Day,
start time, and (J) Time of Day, duration.
The Values of Column K to L are reserved for the Controller, so these values should
be left as (0).

To help administrators manage large number of guest accounts, you can import and
export .csv (comma separated value) guest files with the Wireless Controller. To
import the .csv files select the Import Guest File from the GuestPortal Guest
Administration screen. In the File Management Section, click to Import Guest files.
The Import Guest File dialog will be displayed; browse to navigate to the location of
the .csv file and select it to Import.

To export a guest file, select File Management, Export, select the location and file
name then save .
The default, exported file is named “exportguest.csv”.

Once you select the Auth and Acct tab, in the Authentication Mode drop-down list,
select GuestPortal, then Save the configuration. Once the settings have been saved
you can then Configure the Captive Portal/GuestPortal setting for access.

The configuration screen allows the administrator to create the Web Page using the
Captive Portal editor or a .zip file can be updated.
When uploading custom Captive Portal content via a .zip file, the contents of the zip
must adhere to the following file format and structure.
• The zip file must have a flat structure and cannot contain any sub-
directories.
• The Captive portal login page must be in a file named login.htm
• The Captive portal index page must be in a file named index.htm
• The number of graphics and the size of the graphics is unlimited, and can
be either .gif, .jpg, or .png.
Once the zip file has been Save, remember to Save the setting on the Auth and Acct
page to save the information that was applied in the Captive Portal Settings screen
to the WLAN Service.

Create the GuestPortal VNS by specifying the VNS Name, WLAN Service, the Non-
Authenticated Role, and the Authenticated Role. Enabling the VNS will add the VNS
to the database and VNS information will be pushed down to the APs you specified
when you configured the WLAN service.
A Wireless Controller is allowed only one GuestPortal dedicated VNS at a time.

The WLAN client in this example has selected a website
(http://www.ExtremeNetworks.com). A FQDN can be used if DNS is properly
configured in your environment, otherwise the Controller will not redirect to the login
screen. The default certificate installed on the Wireless Controller will display a
security warning. To avoid this install a customized certificate on the Controller.

Guest Splash provides minimal authorization. Login information is not required,
however an email address can be collected to provide identify information about the
user, when the user is re-directed to the authorization Web page. The user is only
required to select a button to agree to the terms and conditions to be allowed access
to the network.

The Authentication request is logged by the Controller. Here you can see that the
user Guest-Student has authenticated successfully. GuestPortal start and end
sessions are logged. The logs are only available to Controller administrators; Guest
Manager administrators do not have access to this information. The GuestPortal
login events are displayed in chronological order.

The Active Clients report shows the User that has been authenticated.

The wireless system allows multiple Wireless Controllers (up to 12) to discover to
each other and exchange information about a client session for true mobility. This
feature enables a wireless device to roam seamlessly between different wireless APs
on different Wireless Controllers. Mobility is especially important in a routed
environment where the user will be able to roam and continue to use the original IP
address that it received from its Home Controller.
The wireless device retains its Role assignment (access control, IP address, rate
profiles and filtering rules) it received from its home Wireless Controller - the
Wireless Controller that it first connected to. The VNS components on each Wireless
Controller must have the same SSID and RF privacy parameter settings so that it
can be supported in a Local or Branch Office Setting and it easy to deploy on an
existing IP network.
The goal of Mobility is to provide the user with a seamless mobility experience in a
Multiple Controller deployments by sharing session registration information.

The solution introduces the concept of a Mobility Manager and Mobility Agents. One
Wireless Controller within the network is designated as the Mobility Manager and all
others are designated as Mobility Agents.
The Mobility Manager is a single system identified by the administrator that will
manage the state of the mobility domain. Once identified, the Manager will accept
Mobility Control session connection attempts from Mobility Agents. The Manager is
responsible for the management, aggregation and distribution of client session
information to all Agents.
Once configured, the Mobility Agent will locate the Manager either using SLP Unicast
or a static configuration and will establish a Mobility Control session (TCP port
60606) with the Manager. The Agent also processes the client session updates
provided in the regular heartbeat messages sent by the controller so that it can build
a complete list of controllers in the mobility domain by membership/location. The
Backup Mobility Manager runs as an agent, but monitors the Mobility Control
Session to the manager status.
Once the Mobility Session is established the Agent will then retrieve the list of all
other controllers in the domain and proceed to set up the mobility data network by
initiating a Data Tunnel (13910/UDP) to each one of its peers. This data network will
become a full-mesh once the mobility domain is up and will be used as a tunnel to
forward a roaming client’s packets between the foreign and home controller.

In addition to managing roaming activity across APs associated to a single controller,
mobility extends this service to multi-Controller deployments or the Inter-Controller
Mobility scenario.
When a MU (MU1) starts a new session with a mobility domain, the first controller it
connects to is identified as its “Home” Controller (Controller1).
When an Mobility Agent (Controller 2) receives a new MU/wireless association

request, it will first check in its local table to determine if the MU already has a
session and then determines whether this client belongs to a controller within the
mobility domain and determines its Home Controller. If a session does exist, the
Mobility Agent accepts the client and then updates the Mobility Manager with the
new whereabouts over the Mobility Control Session tunnel and begins tunneling the
client’s data to and from its Home Controller over the CTP tunnel that is established
between the Controllers.
The WLAN client/MU will continue to maintain its network point of presence and all of
its session properties (VNS, IP, authentication state) and all traffic will flow through
the Home Controller.

If an Agent fails, the Manager drops its wireless clients from the Mobility Information
Tables and updates the remaining Agents. Since there is no longer a Home
Controller where to tunnel the clients’ data, these clients will be disassociated by
their current Controller. The dropped clients will have to associate again and
become local on that new Controller.
If the Manager fails, the Backup Manager, if defined will assume the role of the
Mobility Manager. The TCP control tunnels will be renegotiated between the Backup
Manager and the Agents. Once the Primary Manager comes back online, the
Backup Manager will go back to it’s Agents role.
If there is not Backup Manager, the Agents will freeze their current copies of the
Mobility Information Tables and proceed to drop/disassociate the clients homed on
the Manager. The remaining clients included in the mobility tables will continue to
have roaming capabilities since the data tunnels between the agents are still
operational even though the control tunnels to the manager are down. Any new
client received from this point will only be local to that Controller’s domain and not be
able to roam within the mobility domain.

Because of the tight interaction between the Mobility Controllers, different versions of
software are NOT supported. This means that all Wireless Controllers in the mobility
domain must be running the same Wireless Convergence Software release and the
Controllers in the Mobility Domain should also be using a common source for time
synchronization (an NTP server).

At least two controllers at a minimum are needed to set up a mobility domain. One of
them should be setup as the Mobility Manager and the other a as Mobility Agent.
The Mobility settings in the GUI are found under the Wireless Controller > Mobility
Manager. To enable Mobility check the Enable Mobility checkbox on the potential
Mobility Manager.
On the Mobility Manager, select This Wireless Controller is a Mobility Manager
option. Select the Port through which to listen for Agent connections. Select the
Security Mode to Allow all mobility agents to connect, then save your settings.
Mobility will be activated.
In a protected domain, select Allow only approved mobility agents to connect. When
new Agents attempt to connect to the Mobility Manager they are placed in the
pending state until they are approved by the administrator; you can also add new
Agents manually during configuration time. Administrators may also remove any
controllers from the domain by deleting the record from the Permission List.
Note: Care should be taken to load balance the Wireless APs and Mobility through
the same port. For large deployments, balancing Wireless AP/Client traffic, Mobility
Tunnel traffic, gateway/internet traffic through the different available esa/PC ports
requires the analysis of network usage forecasts (or current traffic statistics) against
port line rates in order to determine the best configuration.

To enable Mobility check the Enable Mobility checkbox on the potential Agent. On
the Mobility Agent check the Enable Mobility checkbox, select This Wireless
Controller is a Mobility Agent option. Select the Port through which to reach the
mobility Manager. Then select the Discovery Method to be Static Configuration and
enter the Mobility Manager Address. Save your settings. The Mobility Subsystem
will be activated and a tunnel will be created between the Manager and Agent. If a
Backup Manager is configured by the Mobility Manager it will be displayed.

Centralized mobility is a means of ensuring that a single specific controller in a
mobility zone hosts the sessions of all stations accessing the network via a specific
WLAN Service/SSID. This is useful in cases in which you do not want to offer the
back-end portion of the service on multiple controllers in the mobility zone or when
you can’t do so. Centralized mobility is particularly useful for guest portal services in
a mobility zone, since you only have to maintain the guest registrations on one
controller.
Centralized mobility and standard mobility both work with bridged at AP, bridged at
controller and routed topologies. The choice between centralized and standard
mobility has no effect on whether a station’s traffic is tunneled back to the controller,
only the choice of topology determines that.
Note: If using any type of Captive Portal with centralized mobility, be sure that the
number of concurrent sessions expected on the remotable WLAN Service is no
greater than the controller’s session system limit.

An administrator designates one or more WLAN Services on one or more controllers
as “remotable”, thereby making a VNS available for centralized mobility instead of for
standard mobility.
The Mobility Manager in the mobility zone gets the list of remotable WLAN Services
(SSIDs) from each controller in the mobility zone. The Mobility Manager
pushes/updates the consolidated list to each Mobility Agent in the mobility zone.
The administrator will then define a “remote” WLAN service on each Mobility Agent
that will provide APs for the remotable service:
• Administrator assigns privacy & QoS settings to the WLAN Service locally
• Privacy settings MUST match across all WLAN services on which the
service is “remote”
• QoS settings should match across all WLAN services on which the service
is “remote”
You must also configure a VNS and assign the WLAN service to it

The Remotable VNS Information list all SSID exported as remotable by any
controller in the mobility zone.

The administrator then picks the SSID for the remote WLAN Service from the list of
remotable WLAN Services maintained by Mobility Manager.
After saving, configure the remote settings, the settings must match those of the
remoteable WLAN Service on the host WC.
• Assign APs
• QoS
• Privacy
• Advanced Settings RF Settings (Suppress SSID, Enable 11h support,
Process client IE requests or Energy Save Mode)
Auth & Acct options are not available, since they can only be configured on the home
controller.
A Remote WLAN Service can be in an active or inactive state, a service becomes

inactive when the connection to the mobility zone is lost. When the service is
inactive, it is removed from APs to avoid creating a “black hole” for roaming clients.
When a tunnel becomes available the service is re-activated at the WC and APs.

Mobility Tunnel Matrix provides a cross-connection view of the state of inter-
controller tunnels, as well as relative loading for user distribution across mobility
domain.
Green – The mobility manager is in communication with an Agent and the

data tunnel has been successfully established
Yellow – The mobility manager is in communication but the data tunnel is not
yet successfully established.
Red – The mobility manager has no communication with an Agent and there
is no data tunnel.
This report also provides a view of the tunnel uptime, the number of the clients
roamed and the Mobility membership list.

In a typical failure AP to WC communication is interrupted, by either the failure of the
network or by WC failure. Depending on the topology of the VNS configuration,
once the connection has been determined to be down the AP will start the discovery
process. The discovery process will continue for 5 minutes and if there is no success
in connecting to the controller the Wireless AP will reboot and all WLAN client
sessions will terminate, as shown in the case of AP1.
If the AP is configured for a VNS with a B@AP topology associated to it, and if the
Maintain client sessions in event of poll failure option is enabled in the Advanced AP
Properties or AP Default Settings screen, all client sessions will be maintained and
traffic will continue to flow for that specific AP; in this case AP2.
If the AP is configured for a VNS with either a B@AC topology or a Routed topology
associated to it, all client sessions in those VNSs will fail.

The purpose of the Availability feature is to provide a controlled means for Access
Points to find an alternate controller in the event of controller or network failure. The
Access Point will connect to the alternate controller and restore the service with
minimal disruption to a WLAN client.
All thin APs monitor the status of their CTP tunnel connection to their home/local
controller. However, if the connection to the controller fails the AP will establish a
new data channel or CTP tunnel to the secondary or foreign controller.

The two Controllers in an Availability Pair provide backup for each other’s Access
Points (APs). One controller is defined as the Primary and the other as the
Secondary or Backup Controller. The Primary controller is the owner of the
Availability tunnel and is responsible for establishing communication to the
Secondary Controller. This tunnel is used to pass control and configuration
information (information on all registered APs and about each interface that is
active), thereby synchronizing Wireless AP membership information between the two
controllers. Heartbeat messages are also communicated over the tunnel. As
Wireless APs are added or deleted from each Controller, updates are synchronized
between the controllers.
The Availability tunnel connection is usually established through one of the routable
interfaces but the management interface can also be used.
Note: The port selected should be chosen based on the most reliable link between
the two controllers. The Availability protocol is light on the use of bandwidth with an
average load of 1 packet/sec and will not affect a load-sharing network design.

During the failover event, Foreign APs and Sensors do not count as Active APs in
regards to the WC license. The maximum number of failover APs the secondary
controller can accommodate is equal to the maximum number of APs supported by
the hardware platform, not the value of the installed license for the Local Controller.
Controller Deployments with un-matched controller attributes (Max AP capacities)
may cause problems.
Software versions on controllers and AP must match, otherwise, failovers may result
in automatic AP firmware upgrades which will introduce a significant service
interruption.
For maximum deployment flexibility and lower deployment costs, cross-regulatory

domain redundancy is supported. Allowing a controller deployed in the US with an
FCC regulatory domain license the ability to back up a controller located in Germany
with an ETSI regulatory domain license. This flexibility allows for disaster recovery
designs that can expand across the globe while reducing CAPEX/OPEX costs by as
much as 50%.
Note: Foreign Aps cannot be reconfigured and continue to operate with the
powers/channels prescribed from the home controller.

Using a B@AC topology with the same VLAN ID on both Local and Foreign
controller reduces the impact of a fail-over event. WLAN clients will retain their IP
addresses as their DHCP scope is the same.
To ensure that Failover will work properly without impacting users you will need to
ensure network accessibility for the Availability tunnel (UDP 13911) between the two
Controllers. Also, to ensure that the failover performs seamlessly, configure the
DHCP server in the environment with the DHCP Option 78 (SLP) configured to
include the IP addresses of the physical interfaces on both the local and foreign
Wireless Controllers.

Setting the Wireless APs setting Registration Mode to Allow only approved wireless
APs to connect creates a secured environment so that no Wireless APs can register
unless they are approved by the administrator and it allows you to select the APs for
each controller.
Note: If two Wireless Controllers are paired and one has the Allow all wireless AP to
connect option set for Wireless AP registration, all Wireless APs will register with that
Wireless Controller.

In Fast Failover Scenario the AP stores the configuration from the Home Controller
and the Foreign Controller. The Wireless APs connect to both the primary and
secondary Wireless Controllers. The connectivity to the primary Wireless Controller
is via the “active” tunnel; the connectivity to the secondary Wireless Controller is via
the “backup” tunnel.
The Wireless AP establishes the active tunnel to connect to the primary Wireless
Controller. The Wireless Controller sends the configuration to the Wireless AP. This
configuration also contains the port information of the secondary Wireless Controller.
On the basis of the secondary Wireless Controller’s port information, the Wireless AP
connects to the secondary controller via the backup tunnel. After the connection is
established via the backup tunnel, the secondary Wireless Controller sends the
backup configuration to the Wireless AP. The Wireless AP receives the backup
configuration and stores it in its memory to use it for failing over to the secondary
controller. All the while, the Wireless AP is connected to the primary Wireless
Controller via the ‘active’ tunnel. The deployment is designed in such a way that the
services provided to the Wireless Client (such as DHCP services) should not be
dependent on the Wireless Controller the APs associate with. Therefore service
downtime can be reduced significantly, independent of the number of APs. This
deployment will provide a failover fast enough to preserve voice calls.
Note: When Secure Tunnel enabled the tunnel key information is not shared
between the Primary and Foreign Controller.

Fast failover works equally well in network and controller failures. If the Primary or
Local Controller goes down, the Foreign controller detects the loss (Link Timeout) of
its Availability Peer and sends a WASSP-PEER-DOWN packet to the AP.
If the Link between the Primary and Local Controller goes down, the AP will wait until
the Poll Timeout expires. The AP will then initiate the Failover without the help of the
Foreign Controller.
In both cases once the AP receives the WASSP-TNL-ACTIVATE-RESP the AP

applies the backup configuration and starts sending data.
After a loss of three CTP polls the Wireless AP will move into the failover state and
attempt to connect automatically to one of the interfaces that were exchanged by the
Availability Tunnel.

Session Availability feature preserves client sessions (e.g. voice calls) through a
failure of the controller in an availability pair. In session availability, users do not
have to have to re-authenticate after the failover and they retain their IP addresses.
Session availability is enabled automatically when Fast Failover is enabled between

the primary and backup controller. The Session Availability feature is an attribute of
a VNS; therefore it is configured in the topology section of the VNS. Only the
Bridged VLAN configuration is recommended for use Session Availability because
during a failover scenario the client will not have to obtain a new IP address. DHCP
addresses should be provided by the external DHCP server and both VNS
topologies must be mapped to the same VLAN on both controllers.
You must always use the following authentication mechanism for the fast failover w/
session availability configuration:
Wired Equivalent Privacy (WEP)

Wi-Fi Protected Access Privacy-Pre-Shared Key (WPA-PSK)

The Availability Screen allows the administrator to manually configure availability or
to use the Availability Wizard. On the Availability screen under the Wireless AP tab,
set the Controller settings to Paired. This will enable the availability pair and create
the availability tunnel between this Controller and the IP Address specified in the
Wireless Controller IP Address. Selecting the Current Wireless Controller is primary
connection point and indicates that this controller will send a connection request to
the non-primary Controller.
Availability can be configured by using the Availability Wizard or by manually

creating the availability pair. Start the Availability Wizard on the Controller that will be
the primary connection point in the Availability Tunnel.
GuestPortal and Availability are both supported to allow guests to access the
network when the home controller fails. The guest accounts are synced automatically
between the availability pair if Synchronize Guest Portal Account is enabled.
The GuestPortal VNS and accounts must be similar to prevent overwriting of account
records. If on one controller the GuestPortal VNS is removed it will be removed on
both Controllers when Synchronized Guest Portal Account is enabled.

The Global Synchronize Option Synchronization System Configuration, if enabled,
will push the VNS components from the primary controller to the peer controller when
VNSs are configured. To change this default behavior on a per VNS definition basis
uncheck the Synchronize box in the individual VNS component.
The Synchronize Guest Portal Accounts will synchronize Guest Portal Accounts
when modifications are made to the User database (Add, Edit, Delete).

VNS components on the Controller Peer and modified the Layer 3 IP addresses to
match the unique controller, using the Availability Wizard will update automatically.

The Global VNS Sync Summary screen provides an overview of the synchronization
status of paired controllers. The screen is divided into 4 sections: Virtual Networks,
WLAN services, Policies and Topologies. Each section lists the name of the
corresponding configuration object, its synchronization mode, and the status of last
synchronization attempt.
Sync Summary option is only displayed in the Global VNS Configuration when
Availability is enabled.
The Synchronize Status Field can have one of the following options: Synchronized,
Not Synchronized, Failed, Conflict (with a button called “Resolved”).
Conflict status will be displayed if there was an update on a controller, but the
availability link was down between the controllers. The “Resolve” button lets you
choose which version of the object should be taken, local or remote, once the
availability link is active.
The Administrator can also change the global Synchronize System Configuration
parameter and the Synchronize option on a per VNS component.

Availability relies on the Poll Timeout configured on the AP Properties. When the
Poll Timeout expires the AP will then re-attempt to establish a link to the primary
Wireless Controller.
The Detect link failure value specifies the time period within which the system
detects Availability link failure after the link has failed.
To obtain the optimum results in Failover, the timeout used for APs should be in
range of 1.5-2 times of Availability Detect link failure timeout.
If the Poll Timeout value is less than 1.5 to 2 times the Detect link failure value, the
Wireless AP failover will not succeed because the secondary controller will not be
'ready' to accept the failover APs.
On the other hand, if the Poll Timeout value is more than 1.5 to 2 times of Detect link
failure value, the Wireless AP’s failover will be unnecessarily delayed, because the
Wireless APs will continue polling the primary controller even though the secondary
controller is ready to accept them as failover APs.

The quick deployment and matching of APs to VNS Assignments can be
accomplished through the use of AP Default Settings to ensure the same set of
corresponding VNSs on both controllers. The default AP Settings template is used to
provide initial configurations for APs.
If a system default AP configuration does not exist for the controller (and the
administrator has not assigned the failover Wireless APs to any VNS), the APs will
not be assigned to any VNS during the failover.

When the failed Wireless Controller recovers, each Wireless Controller in the pair
goes back to normal mode. The exchange information includes the latest lists of
registered Wireless APs. The WC administrator controls the fail-back You must
release the Wireless APs manually on the secondary/backup Wireless Controller, so
that they may re-register with their home Wireless Controller. Wireless users will
experience a short interruption while their session is reestablished on the Local
Controller.
Foreign APs can be released at once by using the Foreign button on the Access
Approval screen to select all foreign APs, and then clicking Release. In a load
balancing situation, Foreign APs may also go back to the Local Controller if there
was a failover situation that occurs on the Foreign controller.
Note: The Controller system has been optimized to react quickly in the event of a
failover. The release of APs after the fail-over is expected to be a supervised
operation and may take noticeably longer time than the fail-over.
At start-up both Wireless Controllers will move into failover mode temporarily while
the systems finish booting and all application services are started. The primary
Wireless Controller periodically re-polls the secondary Wireless Controller and will
re-establish the connection when both systems become operational. However, if
Wireless APs have roamed to a foreign controller during this brief interval manual
intervention is required to send them back to their home connection point Wireless
Controller.

You can switch an AP from foreign to local (or local to foreign) to help you balance
your AP deployment as the system grows. The AP will continue providing service
without interruption while you re-balance the deployment.
Both conversions can be performed even when the connection between controllers
in your availability pair is down. If the availability link is down at the time you click the
button, the conversion will be completed when link is established.
The conversion is always done in the background.

The controller displays a rehoming in progress indicator until the process completes.
You must manually refresh your screen to see the results.

To verify the Availability feature is configured correctly: From the main menu of either
of the two controllers, click Reports and Displays. The Reports & Displays screen is
displayed. From the Reports and Displays menu, click Wireless AP Availability. The
Wireless Availability Report is displayed.
When looking at the Report if the statement reads Availability Link is Up, the
availability feature is configured correctly and both Controller are active. If a
Controller goes down the status will change to Availability Link is Down. Information
about each AP that is connected to the Primary and Secondary Controller is
displayed, as well as the AP Name, Serial Number, MAC Address, IP Address and
Uptime of the AP.
Fast Failover maintains an active and backup tunnel. Therefore, when Fast Failover
is enabled tunnel connections are displayed in the reports. The larger pane of the
box respresents the state of the tunnel that is established to the current WC (local).
For example, the Wireless AP Availability report is showing that all APs are currently
being managed by their Local Controllers and have connected backup tunnels. In a
non-failover situations Foreign APs should have a Blue box; a Green box would
indicated a Failover situation.
If the Availability Link is Down then the status to the backup/secondary conntroller
will display no info.

Keeping in mind that only Controllers that have “active” tunnels to the AP can display
the statistics of APs and their WLAN connections. During a failover situation the
Active Wireless APs Report will display statistics from both the Local and Foreign
Access Points and their client connections.

If one of the Wireless Controllers in a pair fails, the connection between the two
Wireless Controllers is lost. This triggers a failover mode condition, and a critical
message appears in the information log of the remaining Wireless Controller:
Availability: Moving into failover mode.

OneView Maps lets you create maps of the devices (wired and wireless) on your
network. The typical map represents an office or building floor map.
A OneView or NMS-XXX license provides access to basic map creation and allows
the addition of devices and APs to a map. No additional editing capabilities are
provided. A NMS-ADV license provides access to the advanced map features. This
includes the ability to create floor plans with drawing tools, display of client location
by triangulation and wireless coverage.

OneView lets you create maps of the devices and wireless access points (APs) on
your network. Begin by selecting background image to serve as a map, such as a
building or floor plan, and then position your managed devices and wireless APs on
the map.
The Maps tab Search Field can be used to locate a wireless client, if the client is
connected to an AP that has been added to a map. Enter a MAC Address, IP
address, hostname, user name in the map Search box and press Enter to start a
search for a wireless client. The search uses RSS-based (Received Signal Strength)
location services to locate the wireless client and display the approximate location of
the client on the map. The map containing the AP will be displayed centered on the
AP.
Time-lapse location provides the historical time point for a particular device on the
map. You can use time-lapse location to go back in time and see where a device
has been. It does not provide a full path of travel, but you can see where the device
was at each time point in which the device’s location was reported. Time-lapse
location requires you to enable location tracking on your Wireless Controller.

The AP collects Probe Requests from the clients, once the information is received it
will average the RSS value obtained from the Client and then pass the RSS values
to the Location Engine located in the Controller. The Location Engine processes all
the RSS values from APs (home and foreign) and estimates the client location. The
location engine analyzes the data using the Heatmaps for AP (placement of the AP
by location), triangulates the Client position based on 3 separate AP readings for a
single Client or if only a single AP reports it will estimate based on only that single
AP. Results are sent to the ExtremeControl or transferred to ExtremeControl during
a Location Query for a single MAC address.
Note: Using a single AP for location services is not accurate, there is no accounting
for any obstacle or other interference.
For each tracked MAC Location engine collects RSS reading from the APs, in run-
time execute the location estimation based on the reading and off-line prepared RF
maps. RF maps are created based on the provided floor plan and AP
location/orientation.

Precision of the RSS based location depends greatly on the number of APs that
report the RSS and number of AP that have line of site to the station. To locate a
particular MAC, the location algorithm requires RSS of the packets received from that
source MAC address reported by multiple APs, within a short time window. For
reasonable location accuracy, RSS values need to be reported by 3 or 4 APs,
additional AP reporting does not significantly improve the accuracy.
The process of determining the area of wireless coverage essentially utilizes the
same data and logic as that to determine client location. A client’s location is
determined by the computing the intersection of the probable client location relative
to multiple access points. Coverage is determined by computing the approximate
radio signal strength (RSS) at fixed distances from the access point. Again, the wall
information in the floor plan is used to provide accuracy in the signal strength
computation, because radio signal strength is affect by obstacles (i.e. reflections and
absorption of materials), interference and antenna type. Furthermore if less than 3
APs see the wireless devices the location will be shown as a circle.

The map import function gives you the ability to import Ekahau maps into OneView
floor plan maps, as well as the ability to import floor plan maps that have been
previously exported from OneView maps. When Ekahau maps are exported, all the
maps in the system are combined into a single Zip file. When the Ekahau Zip file is
imported into OneView, each Ekahau map is recreated into an individual map again.
When a map is imported, it is added as a child map of the World map. If the map's
name is not unique, a number will be added after the name. After the map is
imported it can be moved and renamed, if desired.
Selecting “Create New Map” from either the right-click menu of a node adds a new
empty map object to the tree.

Once you have created you new map, you can add information to it. Click on the
new map, click File, and click Properties to open up the Map Properties window. In
the Map Properties window, specify your map type.

For example, if you want to create a map based upon a floor plan, choose Floorplan
as your map type, then browse to the floorplan image you wish to use.

Once you have imported your map, open your editing options by clicking File>Edit.

The map scale is displayed in the lower left corner of a map and it should be
changed to accurately reflect your map image. To open the Set Scale window click
Select Items>Set Scale.

To set the scale, you must measure something in the map using the scaling line, and
then set the measurement for the line. For example, in an office floor plan you could
measure a scaling line on the opening or wall of an office.
Click one on the map to mark the start of the scaling line. Move the cursor and click
again to mark the end of the scaling line. Once the Starting and Ending Position
values are populated in the Set Map Scale window select the Line Length and Users,
in this example the back wall of the office was 10 feet. When completed the map
scale is automatically adjusted.

Floor plan design allows the user to create a floor plan using map editing tools. These
tools can be used to draw walls over an existing map image or on a blank canvas. The
tools allow the user to specify wall thickness, wall material and to customize the
appearance of the floor plan using Colors.
A floor plan can be created with or without a reference background image. However, it is
much easier to use the drawing features with an existing image. A user can use either
menus or buttons to access specific drawing tools for creating lines and shapes and to
apply styles to those drawings.
Once the drawing tool is enabled, the user clicks on a point to start editing, then moves
the cursor to the next point in the line. The user clicks again to create a new line point.
This typically occurs at a wall intersection when the user needs to change the direction
of the line. If the user needs to move to different area of the map to draw a new,
disconnected line segment, the user ends editing by either double clicking or pressing
the escape key.
The line tool creates a multi-segment line. The user starts a line by enabling the tool
then clicking on the map. Segments are created by clicking on the map. When the line
drawing is complete, it can be ended by double-clicking for the last point or pressing the
escape key.
The square and triangle tools allow creation of regularly shaped polygons with a fixed
number of sides. To draw a square or triangle, the user enables drawing by clicking on
the appropriate button. Then the user clicks on the map to start drawing and, while still
holding the left mouse button, drags away from the starting point. When the shape
reaches the desired size, the user releases the left mouse button.

Triangulated client location detection passes the information from a user defined
floor plan to the location engine on the server. Based on floor plan data, a single
client’s location can be triangulated based on the client’s contact with multiple
access points in the covered area. The wall information from the floor plan is used to
help determine the degradation of signal strength that occurs as a wireless radio
signal passes through the walls. This, in turn, helps define the probable distance of
a client from a given access point. OneView will display the client’s location and, in
the small box on the right hand side of the display, specify the part of the map it is
showing you.
If only one access point can see the client, as in this example, OneView will give you
its best estimate of the client’s location.

The Location Engine needs to be enabled on the Controller to complete the
ExtremeControl OneView Maps functionality.

All area changes are subject to a 5 second smoothing period
• Once an area change is detected a timer starts
• Multiple area changes can occur while the timer is active
• If the client returns to the original area before the timer expires, the timer is
stopped and no update is sent
• When the timer expires an update is sent containing the clients current
area

Here is the encoding of the RADIUS request
Encoding of Area Object into Access-Request:
Location-Info.Code = 0 (civic location profile)
Location-Info.Entiry = 0 (describes the location of the user's client
device)
Location-Info.SightingTime = now() - TS (sec)
Location-Info.Time-To-Live = 300sec (fixed value)
Location-Info.method=“triangulation” | “802.11”
Location-Data.location.Catype=22
Location-Data.location.Cvalue=Floor.Name+Area.Name ("location",
CAtype 22 is an unstructured string specifying additional information
about the location, such as the part of a building or other
unstructured information)
For the Location-Info.method:
Triangulation means Location Engine Area Notification
802.11 mean Roaming Area Notification

Wireless coverage is a selectable display mode for the map. When the feature is
activated, the map will display color information for radio signal strength based on
distance from APs included on the map. That is, the map is divided into squares that
will be assigned a color based on the radio signal strength at that location. The
exact color that will be assigned to a square will be determined by the wireless
controller based on the AP location and the material of any walls between the square
and the AP.

Dynamic Mesh, a proprietary solution aligned with 802.11s Hybrid Wireless Mesh
Protocol (HWMP) , non-register, proactive mode but is not fully 802.11s compliant, is
extension of the WDS capabilities.
Static Mesh or Wireless Distribution System (WDS) is part of the IEEE 802.11
specification that allows APs to use RF to provide both network access and data
backhaul, making it possible to extend the traditional network to less traditional
locations without installing additional cable or fiber.
The AP supports links on either the 5 GHz or 2.5 GHz frequency bands. Therefore
they can be leveraged, yielding better overall performance and creating a far more
scalable network. The Mesh network is secure as it automatically negotiates pair-
wise master keys to encrypt data using AES and to secure links between each node
so that data is never transmitted in the clear. Lastly, it is completely integrated into
Wireless framework (VNS, Availability, etc.)
Note: Dynamic Mesh is supported on all AP3xxx models, excluding the AP3x05
models.

A Simple Mesh configuration is used when a Wireless AP is installed in a remote
location and can’t be wired to the distribution system (DS). A Root or Mesh Portal
Wireless AP is connected to the distribution system via an Ethernet link. This
intermediate Wireless AP forwards and receives the user traffic from the remote
Wireless AP, also called a Satellite or Mesh AP, over a radio link.
If there is a Wireless AP between the Root/Mesh Portal and Satellite/Mesh AP, it is used
to relay the user traffic; this AP acting as a Repeater. A Repeater AP relays the user
traffic between the Root/Mesh Portal and the destination Mesh AP/ Satellite AP is acting
as both a child and a parent, thus increasing the WLAN range. When configuring WDS in
a Wireless Repeater configuration, you should limit the number of repeaters to 3 for
optimum performance.
In the Wireless Bridge configuration, the traffic between wireless APs that are connected
to two separate wired LAN segments is bridged via a Mesh link; this is also referred to
Workgroup Bridge. To avoid loops, make sure that it the remote wired LAN is a truly
isolated segment with no other connections to the wired network since the Mesh solution
does not offer protection from loops.
Mesh AP is connected only to one parent/Root AP at a time, a Repeater and Satellite AP
may connect an isolated Ethernet segment to the wired network, limiting the number of
hops in the tree reduces the latency and provides better performance because packets
are duplicated on each hop.
Note: For WDS it is recommended to limit 8 AP’s per tree (including the root) for DATA
and use only 2 APs per tree (including the root) for VOICE.
Note: The limit of APs participating in a Mesh tree is 50.

The Wireless APs in a Mesh Network configuration form a tree-like structure. The
tree builds in a top down manner with the Root / Mesh Portal Wireless AP being the
tree root, the Mesh AP / Satellite Wireless or Repeaters being the tree leaves. The
Wireless AP that provides the Mesh service to the other Wireless APs in the
downstream direction is called a parent. The Wireless APs that establish a link with
the Wireless AP in the upstream direction for Mesh service are children. The
Controller can be set up with either a single WDS/Mesh VNS or multiple WDS/Mesh
VNSs. If a VNS shares a single WDS/Mesh, it uses the same SSID and a single pre-
shared key for the links. The tree can have multiple roots. In a multi-Mesh
environment two independent WDS/MESH trees will be created and each tree will
operate on separate SSIDs and use separate pre-shared keys.
The Parent AP enables WDS IE in the beacon once it is connected to the Controller
and announces its AP Name using a proprietary IE (SSID is not suppressed). The
child AP scans for the preferred parent and/or backup parent on the radio defined in
the WLAN Service. When found it will connect to the parent AP using a proprietary
protocol and establish a WDS/Mesh link.
When an AP starts the discovery process in a Mesh environment the AP will obtain
its IP address using a DHCP Request that is broadcasted through the link until it
reaches the controller. The DHCP response will be transmitted down through the
Mesh link until it reaches the AP. The AP will register to the Controller over the Mesh
link and then the Controller manages the Mesh AP as any other AP. The Repeater
AP tunnels traffic through the Mesh bridge, not through its own tunnel to the
Controller.

Once the Mesh/WDS link has been established between the parent and client, the
link is monitored.
In a WDS environment, heartbeat messages are exchanged in the form of Poll_Req

messages are sent from the client AP to the parent AP. The parent is responsible for
responding to the polls with a Poll_Resp. The parent AP will disconnect the WDS link
if no traffic or no Poll_Requests are received for 20 seconds. Once the link is broken
between the parent and child the child will attempt to automatically discover its
backup parent by performing a full scan of the (2.4 or 5GHz) band. In the Static Mesh
configuration or WDS, if a backup parent is not defined, the child AP will be left
stranded.
Mesh AP uses the Beacons from the parent to detect its presence. Mesh AP
monitors other potential parents while connected to the current parent. Mesh AP
changes to another parent either because parent is lost (Consecutive Beacon loss)
or there is a parent with significantly better link quality (self-healing). In the both
cases, the Mesh AP transfers to the new parent without a need for a full scan. The
Mesh AP does a full scan if there is no other available parent or on the startup.
During the transition from parent to backup parent service to clients is lost.
Mesh can co-exist with WDS WLAN (used with statically defined).

The Mesh tree operates on the channel determined by the Root/Mesh Portal AP
radio. Therefore, the Mesh/Satellite AP channel is determined by parent radio. A
Wireless AP may connect to its parent Wireless AP and children Wireless APs on the
same radio or on different radios. Similarly, a Wireless AP can have two children
operating on two different radios.
Dynamic Frequency Selection (DFS) should be avoided when using radio A (region
and country dependent) in a Mesh environment. When DFS is enabled prior to
establishing a Mesh link and transmitting over any channel, the child AP will perform
a 60 second scan to check for the presence of radar signals on the channel. During
operation, the WDS AP continues to monitor for radar and if radar is detected on an
AP, the AP dissociates clients and signals radar to its parent and child APs.
Changes to the radio channel or power on the child AP may cause the AP to become
inaccessible. During deployment, if the child AP rejects changes to a channel or
power for the radio used for the link connection to the parent AP, an alarm will be
generated.
To reduce interference, radio hopping may be used where neighboring links are on
different radio; however, channel planning is difficult. WDS (only) backhaul can co-
exist with client VNSs on same radio. However, the best performance is achieved
when client VNSs are on a different radio than the WDS backhaul..

To achieve a balance of stability, throughput, and latency the 5.2 GHz band should
be used for the Mesh backhaul, using a non-DFS channel for the Mesh Portal (Root).
Other guidelines that are recommended are:
40Mhz Channel Width

ATPC disabled
Beacon Period should be 100 msec
DCS disabled
Disable Optimized for Power Save
Short Guard Interval
Disable Aggregate MSDUs
Enable Aggregate MPDUs
Enable ADDBA support
The settings on the Radio configuration page should be all the same for all
APs in the Mesh
DFS – Dynamic Frequency Selection

MSDU – MAC Service Data Unit
MPDU – MAC Protocol Data Unit
ADDBA – Add Block Acknowledgement
ATPC – Automatic Transmit Power Control
DCS – Dynamic Channel Selection

You must connect the Mesh Wireless APs to the enterprise network so they are
active on the Controller, once they have obtained their configuration they can be
disconnected and placed in there location.
Once the backhaul radio is selected and saved, you cannot change it. It must be
deleted and re-added.

Similar to the Mesh Service Type, you must connect the Wireless APs to the
enterprise network in order for them to obtain their configuration from the Wireless
Controller. There is no manual process supported to initially configure the AP over
the Wireless link.
When configuring the WDS deployment you first define the WDS subnet in WLAN
Services and specify the topology as Service Type: WDS. Once the type is selected,
the screen allows the user to set the pre-shared key and assign the Wireless AP’s
roles.
WDS is secure as it automatically negotiates pair-wise master keys (PMK) used to

encrypt using AES and to secure links between each node so that data is never
transmitted in the clear. Changing the pre-shared key after the WDS is deployed is
not encouraged due to its lengthy process in forming the tree.
Note: If a Wireless AP is configured as a Guardian, it cannot be used in a WDS/Mesh

tree.

A wireless AP in WDS mode can be configured to provide parent and/or child
service. Wireless AP services are configured on a per radio basis. Radio a and
Radio b/g can be configured independently. Each child AP must have at least one
mandatory parent AP (preferred parent or Any Parent) and an optional backup
parent. Enabling WDS bridge indicates that the Satellite Wireless AP will be
connected to the wired network. A Repeater is configured as both parent and child,
because it is a child of a parent and a parent to a child.
Auto Parent Selection:
WDS Auto Parent Selection allows Child WDS APs to select the best parent out of
the all available parents based on the Rx strength and number of hops. A child WDS
AP that needs to do parent auto selection is configured with “ANY Parent” in the
preferred parent selection. Auto Selection is in addition to static defined primary and
backup parent.
This feature is applicable to user cases when the parent AP is not known or the child
WDS AP is frequently relocated but stationary during usage (as in cart based
operation). Only child WDS APs are allowed to be configured with “Any Parent” in
the Primary Parent / Backup Parent Name.
Note that if you want a WDS AP to function in Work Group mode - that is, to use its
radio to bridge traffic it receives on its wired Ethernet port - check the WDS Bridge
checkbox.

Maximum Distance is used to configured the maximum link distance between APs
that participate in WDS backhaul on a per radio basis. By default the ACK packet
between APs is designed for links up to 100m/300ft. This value allows the Atheros
chipset to be modified in order to accommodates links/coverage beyond the
100m/300ft to the maximum distance up to 150,000m/4990ft.
Note: Do not change the default setting for the radio that provides service to 802.11
clients only.

Once the tree is defined, the Wireless AP’s radios need to be assigned to VNS
service unless you are configuring a Mesh bridge. In Bridged at Controller or
Routed VNS mode the data traffic from the client is encapsulated and de-capsulated
at the Satellite AP and at the Controller. In Bridged at AP VNS mode traffic from the
clients is VLAN marked on the Satellite AP; this marking is preserved through the
repeater AP and Parent/Root/Mesh Portal AP.

Once the Configuration has been saved and each AP has received its configuration
you can disconnect the Wireless APs from the enterprise network and move them to
the target location. Once the Wireless APs are connected to a power source they will
start the discovery and registration process. As the APs connect to their parent APs
(Mesh Portal) a tree is established; you can monitor the tree using the Mesh
Statistics report.
The Wireless reports for APs will display the Wireless APs in the domain, the WDS
Children and the number of clients associated to each child. The Mesh Statistics
report will show only the active members of the Mesh and their roles. The backup
root bridge (AP2) is shown in the table, but is not active.
Mesh statistics are collected every 30 sec; the Mesh Report shows uplink Mesh
statistics and the Mesh AP roles. The Quality of the link is reflected by the Average
Tx and Rx rate and Tx Errors.
Note: The Rx RSSI value on the Mesh Statistics display represents the received
signal strength. The minimum value is 1 and maximum value is 60. The higher the
RSSI value, the stronger the received signal.


Extreme Networks Wirelles Student Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Extreme Networks Wirelles Student Guide

Uploaded by

Copyright:

Available Formats

Extreme Networks

For additional information refer to:

© 2016 Extreme Networks, Inc. All rights reserved 2

Configuring the Wireless Controller 6

Access Point Configuration & Management 55

ExtremeControl Integration 112

Virtual Network Service (VNS) Configuration 142

Hotspot 2.0 192

ExtremeAnalytics Integration 203

Authentication / RFC3580 Support 218

Remote Site APs 285

Captive Portal 295

Guest Portal 321

OneView Maps 386

Mesh Networks 410

© 2016 Extreme Networks, Inc. All rights reserved 3

RADIUS Server (Remote Access Dial-In User Service) or other authentication

© 2016 Extreme Networks, Inc. All rights reserved 9

© 2016 Extreme Networks, Inc. All rights reserved 10

The wireless architecture allows a single Wireless Controller to control many

The virtual Controller comes in two versions:

© 2016 Extreme Networks, Inc. All rights reserved 11

© 2016 Extreme Networks, Inc. All rights reserved 12

© 2016 Extreme Networks, Inc. All rights reserved 14

© 2016 Extreme Networks, Inc. All rights reserved 15

© 2016 Extreme Networks, Inc. All rights reserved 16

Bridge Locally at EWC (B@AC)

© 2016 Extreme Networks, Inc. All rights reserved 17

VLAN ID is used as a Controller wide identification of the topologies, however the

© 2016 Extreme Networks, Inc. All rights reserved 18

B@AP topologies do not require the definition of a corresponding IP address since

© 2016 Extreme Networks, Inc. All rights reserved 19

© 2016 Extreme Networks, Inc. All rights reserved 20

© 2016 Extreme Networks, Inc. All rights reserved 21

Note: Only clear text authentication is supported for OSPF.

© 2016 Extreme Networks, Inc. All rights reserved 22

© 2016 Extreme Networks, Inc. All rights reserved 23

© 2016 Extreme Networks, Inc. All rights reserved 24

© 2016 Extreme Networks, Inc. All rights reserved 25

© 2016 Extreme Networks, Inc. All rights reserved 29

© 2016 Extreme Networks, Inc. All rights reserved 30

© 2016 Extreme Networks, Inc. All rights reserved 31

© 2016 Extreme Networks, Inc. All rights reserved 32

Once the upgrade process is completed the Controller will reboot.

© 2016 Extreme Networks, Inc. All rights reserved 33

© 2016 Extreme Networks, Inc. All rights reserved 34

© 2016 Extreme Networks, Inc. All rights reserved 35

© 2016 Extreme Networks, Inc. All rights reserved 36

© 2016 Extreme Networks, Inc. All rights reserved 38

© 2016 Extreme Networks, Inc. All rights reserved 42

© 2016 Extreme Networks, Inc. All rights reserved 43

© 2016 Extreme Networks, Inc. All rights reserved 44

© 2016 Extreme Networks, Inc. All rights reserved 45

© 2016 Extreme Networks, Inc. All rights reserved 46

Your Authentication Service Management Menu options are:

© 2016 Extreme Networks, Inc. All rights reserved 47

© 2016 Extreme Networks, Inc. All rights reserved 48

© 2016 Extreme Networks, Inc. All rights reserved 49

© 2016 Extreme Networks, Inc. All rights reserved 50

© 2016 Extreme Networks, Inc. All rights reserved 51

© 2016 Extreme Networks, Inc. All rights reserved 52

© 2016 Extreme Networks, Inc. All rights reserved 53

The AP3965 weighs 2.99 Kg

© 2016 Extreme Networks, Inc. All rights reserved 57