Multicast MAC Transparency Feature

This feature enables MAC transparency for tunneled multicast, which is needed for some clients to receive multicast packets. Multicasting is an advanced feature and can cause subtle changes in your network. By default, multicasting is disabled. To enable it, use either the multicast-enable command (see example below) or Configuration > Wireless > ESS > Add in the Web UI (see example below).

Multicasting is an advanced feature. Enabling multicasting in the WLAN can cause subtle changes in your network. Contact Meru Networks Customer Service Technical Assistance Center before enabling multicasting.

Enable Multicast From the Web UI

To enable multicasting from the Web UI, add or modify an ESS. For directions, see “Add an ESS with the Web UI” on page 137.

Enable Multicast with the CLI

The following example enables multicasting with the CLI: controller(config‐essid)# multicast-enable

For command details, see the FortiWLC (SD) Command Reference.

View Mapping Between VLANs and ESS Profiles

Use the following command to see the VLANs and ESS profiles currently mapped: controller# show vlan ess‐profile

For command details, see the FortiWLC (SD) Command Reference.

Multicast MAC Transparency Feature

Multicast

Multicast is a technique frequently used for the delivery of streaming media, such as video, to a group of destinations simultaneously. Instead of sending a copy of the stream to each client, clients share one copy of the information, reducing the load on the network. Multicast is an advanced feature and can cause subtle changes in your network. By default, multicast is disabled and should be enabled only for specific circumstances. Possible multicast applications include:

• Broadcast via cable or satellite to IPTV (for example, Vbrick or Video Furnace)
• Any broadcast application (for example, CEO address to company)
• Distance learning (live lectures)
• Video surveillance
• Video conferencing

For multicast to work, you need to complete these four tasks:

• Enable Virtual Port on AP400s – see “Configuring Virtual Port Support for AP400 with the CLI” on page 151 and “Configuring Probe Response Threshold” on page 153 for directions.
• Enable IGMP snooping on the controller – see “Configuring IGMP Snooping on Controllers and APs” on page 163
• Enable IGMP snooping on the network infrastructure including intermediary switches. You must do this because Forti WLC do not source multicast group membership queries. We rely (as do most controllers) on the switches to perform that task.
• Map a Virtual Cell enabled ESS with the default VLAN – see “Assigning a VLAN with the CLI” on page 156.

Configuring IGMP Snooping on Controllers and APs

Multicasting is implemented using IGMP snooping. In FortiWLC (SD) release 3.6, IGMP snooping was only done at the controller; the controller knew which clients were subscribed to specific multicast streams and sent the data for the subscribed multicast stream only to the APs with clients currently being serviced. Since the AP didn’t know which clients subscribed to the specific stream, it would send multicast streams to all clients currently being serviced by the AP. (With Virtual Port, there would be N copies, one for each client). This wasted airtime and created unnecessary traffic and contention.

In release 4.0 and later, IGMP snooping is done not only by the controller but also done by AP400s (excluding AP1000) when using Virtual Cell. The controller passes the client subscription list for multicast streams to AP400, which limits the multicast streams to only subscribed clients, reducing wireless traffic and saving time. (There are no changes in sending multicasts for stations connected to non-Virtual Cell ESS profiles.)

Multicast

Commands to Configure IGMP Snooping

The following command is used to enable/disable IGMP snooping on the controller and APs: igmp-snoop state [enable, disable]

Command to show igmp-snoop status: show igmp-snoop

Command to see which multicast groups are currently active: show igmp‐snoop forwarding‐table

Command to see which stations have joined multicast groups: show igmp‐snoop subscription‐table

WAN Survivability

FortiWLC (SD) provides the following support for bridged and tunneled devices during a WAN connection outage.

When a Bridged APs Lose Controller Contact

When a bridged AP loses contact with its host controller, it will provide uptime for a default period of 120 minutes or for the time specified in controller’s Link Probe (1 – 32000 minutes) setting. During this time existing clients will function normally but cannot roam between APs.

New clients cannot join a bridged AP during this time.

In a tunneled mode:

• You can specify a backup ESS for both bridge and tunneled modes. This backup profile is activated with the controller link is down. Backup ESS is not supported on AP1000.
• New devices connecting during the outage will connect using clear and PSK profiles.

The clients will now be serviced until the links up and all new devices that connected during outage will reconnect after the link is up.

Bridging Versus Tunneling

The bridged AP feature allows APs to be installed and managed at locations separated from the controller by a WAN or ISP, for example, in a satellite office. Encryption can be enabled on the bridged connection to provide security over ISP-based connections.

Bridging Versus Tunneling

The controller, through a keep-alive signal, monitors the remote AP. Remote APs can exchange control information, including authentication and accounting information with the controller, but are unable to exchange data. (Remote bridged APs can, however, exchange data with other APs within their subnet.)

Tunneled mode only features

• Mesh
• Mesh Plug and Play
• 5 Hop mesh
• Wired Client on uplink port with Mesh
• Captive Portal on L2 APs
• Captive Portal Exemptions (domain walled garden entries)
• Domain whitelisting for OAuth with MCT (older way of domain whitelisting)
• VLAN Mesh (801.q trunking on wired ports on Mesh APs)
• VLAN pooling
• GRE tunneling
• QoS Rules -Rate-limiting, DSCP marking
• QoS Rules -dynamic flow detection
• CoA -(filter ID)
• DHCP relay
• Proxy ARP
• RAC
• DPI -Application bandwidth throttling

Bridge mode only features

• Remote Radius
• AP survivability Captive Portal, CP bypass on MAC filtering, IP v6 pass-through, Static/Dynamic VLANs – NOT supported in bridged mode on AP300.
• Allow/Deny QoS rule – NOT supported in bridged mode on AP300,433,1000 & 332

Example of Bridged AP Deployment

The following figure is an example of remote bridged AP deployment. Notice that AP1 is configured for L2/local mode, AP2 is configured L2/Remote mode, AP3 is configured L3/local mode, and AP4 is configured for L3/Remote AP mode. The controller, AP1 and AP2 are

Bridging Versus Tunneling

located in the same 10.0.10.x/24 subnet, and AP3 and AP4 are in a different subnet, 192.0.10.x/24. The blue and red lines correspond to L2 and L3 data tunnel, respectively. Also, MS A through D are associated to AP 1 to 4, respectively. Note that the MS C and MS D have different IP addresses, even though they are associated to APs within the same IP subnet. The reason for this is because AP3 is configured in local mode and is tunneled back to the controller at Layer 3. This example demonstrates how a mobile client’s IP domain is changed by the dataplane bridged or tunneled setting. Figure 35: Example Remote AP Topology

Configure a Bridged Profile

For complete UI directions, see “Add an ESS with the Web UI” on page 137 or click Configuration > Wireless > ESS and select an ESS to edit.

To configure a bridged AP for an existing ESSID with the CLI, follow these steps: 1. Enter the ESSID configuration mode and set the dataplane mode to bridged:

Bridging Versus Tunneling

controller# configure terminal controller(config)# essid profile_name controller(config‐ap)# dataplane bridged controller(config‐ap)# exit

After you make the config changes, force the APs to do a hard reboot.

2. If the connection between the controller and the Remote AP should be secured, use the following command to encrypt only an AP connection:

controller# configure terminal controller(config)# ap ap#

controller(config‐ap)# dataplane‐encryption on controller(config‐ap)# exit

The Remote AP feature may require that corporate firewall configuration be updated to permit wireless access over certain Ethernet ports. The affected ports are:

• L2 (Ethernet) L3 (UDP)
• Data 0x4000 9393
• Comm 0x4001 5000
• Discovery 0x4003 9292

When Would I Use Virtual Cell Overflow?

This feature is designed for a high density deployment and provides a solution for bottlenecks caused by transmitting beacons. Virtual Cell Overflow is useful in these situations:

• Beacon overhead has become very high due to the legacy b devices.
• A very dense network is consuming a lot of airtime with beacons.

Be aware that Virtual Cell Overflow has these tradeoffs:

• Trade-off between mobility and performance
• Trade-off between density and performance
• Not a solution to get good performance for overflow clients

Configure Virtual Cell Overflow with the Web UI

To set up Virtual Cell Overflow from the Web UI, follow these steps:

1. Create a Virtual Cell ESS by following the directions “Add an ESS with the Web UI” on page 137. Be sure that the setting for Virtual Cell is set to On.
2. Create a non-Virtual Cell ESS by following the directions “Add an ESS with the Web UI” on page 137. Be sure that the setting for RF Vitualization Mode is not Virtual Cell. Make this an Overflow ESS with the setting Overflow for; select the ESS you created in Step 1. This overflow ESS automatically inherits the remaining parameters of the Virtual Cell ESS.

 

Virtual Cell Overflow Feature

This feature, called Vcell Overflow, works by pairing a Virtual Cell ESS with a non-Virtual Cell ESS. The overflow ESS automatically inherits the parameters of the Virtual Cell ESS (except the setting for Virtual Cell). The non-Virtual Cell ESS is not used unless the Virtual Cell ESS is maxed-out; when this happens, the Virtual Cell ESS overflows into the other ESS as needed. The two ESS Profiles share same SSID so that clients seamlessly move back and forth. The overflow decision is based on the percentage of airtime spent on beacons crossing a threshold; when the percentage reaches 50%, clients start to overflow.

Adding an ESS with the CLI

Assigning an ESSID with the CLI

The ESSID is the ESS name that clients use to connect to the WLAN. An ESSID can be a string of up to 32 alphanumeric characters long. Do not use spaces or special characters.

The following example names an ESS corp-users and enters ESSID configuration mode:

controller# configure terminal controller(config)# essid corp-users controller(config‐essid)#

Enable and Disable

The Enable and Disable field represents all the Enabled and Disabled services of a profile. If a specific ESS profile is Disabled, the NMS deletes all the Services that belong to the ESS profile. If a specific ESS profile is Enabled, the NMS creates all the Services that belong to the ESS profile. A client will not associate to the ESSID profile when its state is disabled.

The “Service” refers to client connectivity. When the ESSID state is disabled, the BSSID is removed from the AP and the client will not be able to view the Disabled SSID on air.

CLI Configuration

default# sh essid

ESS Profile          Enable/Disable            SSID Name Interface Type meru                      enable                     meru meruwpa              enable                     meruwpa meruwpa2psk      enable                     meruwpa2psk ESS Profile(3) default# configure terminal default(config)# essid meru default(config‐essid)# disable default(config‐essid)# end default# sh essid	Security Profile default meruwpa meruwpa2psk	Broadcast on on on	Tunnel none none none
ESS Profile      Enable/Disable   SSID Name Interface Type	Security Profile	Broadcast	Tunnel
corp-wifi                 disable                    corp-wifi	default	on	none
corpwpa                 enable                     corpwpa	corpwpa	on	none
corpwpa2psk        enable                     corpwpa2psk	corpwpa2psk	on	none

ESS Profile(3)

default# sh essid corp‐wifi ESS Profile

ESS Profile                               : corp‐wifi

Enable/Disable                            : enable

SSID                                      : corp‐wifi

Security Profile                          : default Primary RADIUS Accounting Server          : Secondary RADIUS Accounting Server        :

Accounting Interim Interval (seconds)     : 3600 Beacon Interval (msec)                    : 100

SSID Broadcast                            : on

Bridging                                  : none

<‐‐‐snipped ‐‐‐

‐‐‐

‐‐‐

‐‐‐

BGN Supported Transmit Rates (Mbps)       : 1,2,5.5,11,6,9,12,18,24,36,48,54

BGN Base Transmit Rates (Mbps)            : 11

BGN Supported HT Transmit Rates (MCS)     :

0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23

BGN Base HT Transmit Rates (MCS)          : none

AN Supported Transmit Rates (Mbps)        : 6,9,12,18,24,36,48,54

AN Base Transmit Rates (Mbps)             : 6,12,24

AN Supported HT Transmit Rates (MCS)      :

0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23

AN Base HT Transmit Rates (MCS)           : none

Owner                                     : controller

1 Stream VHT Base MCS Set (MCS)           : mcs0‐9 2 Streams VHT Base MCS Set (MCS)          : mcs0‐9

3 Streams VHT Base MCS Set (MCS)          : mcs0‐9 1 Stream VHT Supported MCS Set (MCS)      : mcs0‐9 2 Streams VHT Supported MCS Set (MCS)     : mcs0‐9

3 Streams VHT Supported MCS Set (MCS)     : mcs0‐9 default#

Security Profiles for an ESS

ESS profiles and Security profiles can be configured either from E(z)RF Network Manager or from the controller. You can tell where a profile was configured by checking the read-only field Owner; the Owner is either nms-server or controller. Each ESS must be associated with a security profile. If you do not create additional security profiles, an ESS is automatically associated with the default security profile named default. To use additional security profiles, create them using the security-profile command in global configuration mode (see either this chapter, “Add an ESS with the Web UI” on page 137 or Chapter , “,” for details). Create the security profile before creating the ESS. You cannot alter profiles created in E(z)RF Network Manager from a controller.

The following CLI example associates a security profile named corp-access:

controller(config‐essid)# security-profile corp-access controller(config‐essid)#

Configuring CAC for an ESSID AP with the CLI

If implemented, Call Admission Control (CAC) limits the number of VoIP calls for all BSSIDs with the command qosvars calls-per-bssid (see “Configuring QoS Rules With the CLI” on page 385). If you have special requirements for an ESSID’s AP400, you can set the CAC maximum calls limit specifically for the ESS using the calls-per-bss command from the essid/ ess-ap configuration sublevel. For example, to set a maximum of 10 calls for AP 1, interface 1 in the ESSID, use the following command:

controller(config‐essid)# ess-ap 1 1 controller(config‐essid‐essap)# calls-per-bss 10 controller(config‐essid‐essap)# exit

Configuring Beacon Parameters with the CLI

You can set the following beacon parameters:

• Beacon DTIM period—DTIM affects clients in power save mode. In the DTIM Period field, type the number of beacon intervals that elapse before broadcast frames stored in buffers are sent. This value is transmitted in the DTIM period field of beacon frames.

The DTIM period can be a value from 1 through 255. The default DTIM period is 1. Setting the DTIM period to a higher value decreases the frequency of broadcasts sent by the access point. If power save is enabled on clients that are connected to access points, clients “wake up” less if fewer broadcasts are sent, which conserves battery life for the clients.

Only the behavior of clients currently in power-save mode is affected by the DTIM period value. Because broadcasts are generally wasteful of air resources, the Forti WLAN has devised mechanisms that mitigate broadcasts either with proxy services or with more efficient, limited unicasts. As an example, ARP Layer 2 broadcasts received by the wired side are not relayed to all wireless clients. Instead, the Forti WLC maintains a list of IP-MAC address mappings for all wireless clients and replies with proxy-ARP on behalf of the client.

• Beacon interval—Sets the rate at which beacons are transmitted.

The beacon period setting affects unicasts and broadcasts. The beacon interval must be between 20 through 1000 milliseconds. For AP1000, beacon interval is a multiple of 20, from 20 to 1000ms. Setting the beacon interval to a higher value decreases the frequency of unicasts and broadcasts sent by the access point. If the power-save feature is enabled on clients that are connected to access points, clients “wake up” less if fewer unicasts and broadcasts are sent, which conserves the battery life for the clients. The beacon period setting affects unicasts and broadcasts.

If your WLAN consists mostly of Wi-Fi phones, and you have a low number of ESSIDs configured (for example, one or two), Meru Networks recommends setting the beacon interval to 100.

The following example sets the beacon DTIM period to 10 and beacon interval to 240 TUs:

controller(config‐essid)# beacon dtim-period 10 controller(config‐essid)# beacon period 240

Configuring ESSID Broadcasting with the CLI

By default, an ESSID is broadcast. When an ESSID is broadcast, it is included in the advertised beacon. Clients using passive scanning listen for beacons transmitted by access points. If ESSID broadcasting an is disabled, those clients listening for beacons cannot receive ESSID information.

Clients using active scanning send probe requests and wait for probe responses from access points. If broadcasting an ESSID is disabled, access points do not respond to probe requests, unless the probe request includes the ESSID.

To prevent the ESSID from being broadcast, use the no publish-essid command.

The following example prevents the ESSID from being broadcast: controller(config‐essid)# no publish-essid

Configuring ESSID Joining of Access Points with the CLI

By default, when a new access point is plugged into the WLAN, it joins all ESSIDs that are configured to have new access points automatically join upon discovery and a BSSID is created.

After you are satisfied with your WLAN configuration, you can disable the automatic joining so that new access points do not change your configuration. If you are adding a new ESS that you want to advertise on only a small subset of access points, it is easier to disable joining and add the ESS-AP mappings manually.

The following example prevents access points from automatically joining an ESSID: controller(config‐essid)# no ap-discovery join-ess

After preventing automatic joining, a BSSID must be assigned manually.

The status of this command is only evaluated when new ESS-AP mappings are created. ESS-AP mappings are either created manually with the ess-ap command, or automatically when a new ESS is created, or a new access point is discovered.

Configuring Virtualization Mode

The RF Virtualization Mode drop-down in the ESS Configuration page allows the user to specify the type of virtualization used by the specified ESS profile. This option contains three separate selections:

• Virtual Cell—This is the default setting for all APs except AP400 models.
• Virtual Port—This is the default setting for AP400 models.
• Native Cell—This option disables virtualization on the ESS.

Virtualization is on by default for Fortinet access points. The major benefit of Virtual Cell is infrastructure-controlled handoffs with seamless roaming between access points. Virtual Port enhances Virtual Cell by giving each client its own virtual access point. With Virtual Port, each client has its own access instead of sharing access with other clients. Because each client has its own Virtual Port, you can tailor it to match the client’s needs. For example, different employees can be given different amounts of bandwidth, depending on the applications used in their jobs. A  client can be given limited bandwidth but high quality of service. A guest is given lower priority and restricted access.

There are three types of limits on the number of Virtual Ports per controller:

• Restricted by the number of clients supported by the controller
• Restricted by the number of AP radios On AP400, the theoretical maximum number of Virtual Ports is 128 per radio. Fortinet’s best practices recommendation is to have no more than 64 per radio.
• Restricted by Virtual Cell There is a hard limit of 2007 Virtual Ports per Virtual Cell. This number is set by the standard of having no more than 2007 associations per single BSSID. In Fortinet’s environment, each BSSID represents a Virtual Cell.

Note that AP400 Virtual Port differs from other Virtual Port configurations in these ways: • Virtual Port has to be enabled per AP400 radio interface, in addition to the ESS Profile configuration. Both the radio and the ESS in use have to be set as Virtual Port for RF Virtualization Mode for it to work. Virtual Port is enabled by default on AP400.

• If you configure some APs in a Virtual Port-enabled ESS Profile for Virtual Port and others for non-Virtual Port, only the Virtual Port-configured APs are recognized by the Virtual Port enabled ESS.
• AP400 only supports per-station Virtual Cell.

Configuring Virtual Cell Support for AP400 with Web UI

There are two steps for configuring Virtual Port:

1. Create an ESS with RF Virtualization mode set to Virtual Port.
2. Configure each radio for Virtual Port by following these steps: Click Configure > Wireless > Radio • Select a radio.
   • Set RF Virtualization Mode as Virtual Port.
   • Save the configuration.

Configuring Virtual Port Support for AP400 with the CLI

Virtual Port is enabled by default in AP Radio.

You can see the Virtual Port setting by using the CLI command show interfaces Dot11Radio. For example:

vcell22# show interfaces Dot11Radio 398 1 *************************** Wireless Interface Configuration

AP ID                                  : 398

AP Name                                : AP‐398

Interface Index                        : 1                          AP Model                               : AP400

Interface Description                  : ieee80211‐398‐1

Administrative Status                  : Up                         Operational Status                     : Disabled                   Last Change Time                       : 08/01/2013 09:38:35        Radio Type                             : RF6                        MTU (bytes)                            : 2346

Primary Channel                        : 6

Operating Channel                      : 6                          Short Preamble                         : on                         RF Band Support                        : 802.11abgn

RF Band Selection                      : 802.11bgn                  Transmit Power High(dBm)               : 24

AP Mode                                : Service

Scanning Channels                      : 1,2,3,4,5,6,7,8,9,10,11,12,

13,14,36,40,

44,48,52,56,60,64,100,104,108,112,116,120,124,128,132,136,140,149,15

3,157,161,165                                                                   B/ G Protection Mode                    : auto

HT Protection Mode                     : off

Number of Antennas                     : 1                          Channel Width                          : 20‐mhz

Channel Center Frequency Index         : 42

MIMO Mode                              : 2×2

802.11n only mode                      : off

RF Virtualization Mode                 : VirtualPort

Probe Response Threshold               : 15                         Mesh Service Admin Status              : disable

Uplink Type                            : Downlink                   Transmit Beamforming Support           : off

STBC Support                           : off                        To turn Virtual Port off, use this version of the command:

vcell22# configure terminal vcell22(config)# interfaces Dot11Radio 398 1 vcell22(config‐if‐802)# rf‐virtual‐mode ? <mode> (10) Enter RF Virtualization Mode.

NativeCell Native Cell Mode VirtualPort Virtual Port Mode

vcell22(config‐if‐802)# rf‐virtual‐mode NativeCell

RF-Mode

Channel Width

N-only Mode

Channel and MIMO mode

Configuring Probe Response Threshold

The Probe Response Threshold configures the way in which an AP responds to requests based on its distance from the transmitting device. It is designed to ensure that the AP responds more swiftly to requests sent from stations located nearby. It is configurable through GUI support in addition to the AP CLI. This feature is also configured via bulk update on a perAP interface level. The default probe response threshold on AP is 15.

SNRRange

The GUI must have the SNR value ranging from 0 to 100, zero means probe response threshold disable.

GUI Page:

Figure 34: Wireless Interface Configuration – Update

Configuring Data Transmit Rates with the CLI

The data transmit rate is the data rate that the access points use to transmit data. There are two types of data rates: • Base data transmit rates

Mandatory rates that all connecting clients must support when connecting to access points. For 802.11AN/BGN, the data rate is selected using MCS Index. The actual data rate is computed based on MCS Index, Channel Width, and Guard Interval. When channel width selected is 40MHz Extension above, then the data rate for the client depends on associated clients channel width and guard interval capabilities. Valid rates are as follows:

• 11b valid rates are 1, 2, 5.5, 11 Mbps, or all
• 11g valid rates are 6, 9, 12, 18, 24, 36, 48, 54 Mbps, or all
• 11bg valid rates are 1, 2, 5.5, 11, 6, 9, 12, 18, 24, 36, 48, 54 Mbps, or all
• 11bgn valid rates are 1, 2, 5.5, 11, 6, 9, 12, 18, 24, 36, 48, 54 Mbps, or all
• 11a valid rates are 6, 9, 12, 18, 24, 36, 48, 54 Mbps, or all
• 11an valid rates are 6, 9, 12, 18, 24, 36, 48, 54, or all
• 11an-mcs valid rates are MCS 0, MCS 1, MCS 2, MCS 3, MCS 4, MCS 5, MCS 6, MCS 7, MCS 8, MCS 9, MCS 10, MCS 11, MCS 12, MCS 13, MCS 14, MCS 15, or all
• 11bgn-mcs valid rates are MCS 0, MCS 1, MCS 2, MCS 3, MCS 4, MCS 5, MCS 6, MCS 7, MCS 8, MCS 9, MCS 10, MCS 11, MCS 12, MCS 13, MCS 14, MCS 15, or all • Supported data transmit rates

Rates at which clients can optionally connect, provided the clients and access points support the rates. Valid rates are as follows:

• 11b valid rates are 1, 2, 5.5, 11 Mbps, or all
• 11g valid rates are 6, 9, 12, 18, 24, 36, 48 and 54 Mbps, or all
• 11bg valid rates are 1, 2, 5.5, 11, 6, 9, 12, 18, 24, 36, 48 and 54 Mbps, or all
• 11bgn valid rates are 1, 2, 5.5, 11, 6, 9, 12, 18, 24, 36, 48 and 54 Mbps, or all
• 11a valid rates are 6, 9, 12, 18, 24, 36, 48, and 54 Mbps, or all
• 11an valid rates are 6, 9, 12, 18, 24, 36, 48, and 54 Mbps, or all
• 11an-mcs valid rates are MCS 0, MCS 1, MCS 2, MCS 3, MCS 4, MCS 5, MCS 6, MCS 7, MCS 8, MCS 9, MCS 10, MCS 11, MCS 12, MCS 13, MCS 14, MCS 15, or all
• 11bgn-mcs valid rates are MCS 0, MCS 1, MCS 2, MCS 3, MCS 4, MCS 5, MCS 6, MCS 7, MCS 8, MCS 9, MCS 10, MCS 11, MCS 12, MCS 13, MCS 14, MCS 15, or all All base rates must be entered as supported rates.

The supported data rates are the rates supported by the access points. The basic data rates are a subset of the supported rates. The access point first tries to transmit at the highest data rate set to Basic. If there are problems encountered in the transmission, the access points steps down to the highest rate that allows data transmission.

Use the base-tx-rates command in ESSID configuration mode to configure the basic data rates, for example, for 802.11bg: controller(config‐essid)# base-tx-rates 802.11bg 1|2|5.5|11|9|12|18|24|36|48|54|all

Use the supported-tx-rates command in ESSID configuration mode to configure the supported transmit rates, for example, for 802.11bg:

controller(config‐essid)# supported-tx-rates 802.11bg

1|2|5.5|11|9|12|18|24|36|48|54|all

To remove a base transmit rate, use the no base-tx-rates command with the mode and speed value, for example, for 802.11bg: controller(config‐essid)# no base-tx-rates 802.11bg

1|2|5.5|11|9|12|18|24|36|48|54|all

To remove a supported transmit rate, use the no supported-tx-rates command with the mode and speed value, for example, for 802.11bg: controller(config‐essid)# no supported-tx-rates 802.11bg

1|2|5.5|11|9|12|18|24|36|48|54|all

To display the radio data rates, use the show essid command.

Assigning a VLAN with the CLI

When creating an ESSID, you can assign a VLAN to the ESSID. This allows you isolate an ESSID to a specific part of your network. By default, ESSIDs do not have VLANs assigned to them. You must create a VLAN using the vlan command in global configuration mode before assigning the VLAN to an ESSID.

The following example assigns a vlan named corp:

controller(config‐essid)# vlan corp controller(config‐essid)#

To remove a VLAN assignment from an ESSID, use the no vlan name command. The following example removes the VLAN assignment from the ESSID:

controller(config‐essid)# no vlan corp controller(config‐essid)#

Supported WMM Features

In general, WMM contains these features:

• WMM (for QoS)
• WMM PS (U-APSD) – helps with battery life

FortiWLC (SD) supports WMM packet tagging for QoS on AP400, and AP1000 automatically (if the client is WMM); this feature cannot be turned off. FortiWLC (SD) supports U-APSD on AP400/AP1000; this can be turned on and off.

U-APSD is ideally suited to mobile devices that require advanced power-save mechanisms for extended battery life, and for applications like VoIP where the user experience rapidly degrades as latency increases. WMM Power Save was designed for mobile and cordless phones that support VoIP. See the chart below for defaults and possible configurations of both the WMM QoS and WMM APSD features.

WMM-PS is an enhancement over the legacy power-save mechanisms supported by Wi-Fi networks. It allows devices to spend more time in a “dozing” state, which consumes less power, while improving performance by minimizing transmission latency. Furthermore, UAPSD promotes more efficient and flexible over-the-air transmission and power management by enabling individual applications to control capacity and latency requirements.

If a deployment utilizing AP1000 models has WMM or WMM-APSD VoIP phones in use with DSCP set to Expedited Forwarding, a special QoS rule must be configured to support the deployment. This rule must have a DSCP parameter value of CS6 or CS7 in order to ensure that the AP1000 queues packets properly, ensuring optimal call quality.

U-APSD capable stations download frames buffered from AP400/AP1000s during unscheduled Service Periods (SP); the result is that there is no wait for beacons as there is in the legacy method. For U-APSD capable stations, APs negotiate U-APSD and use it to transmit data for the WMM Access Categories (priority levels) negotiated for U-APSD when a station is in power save mode. When a device is in power-save mode, the uplink data frame triggers AP400/AP1000 to send frames buffered in U-APSD enabled WMM_AC-queues. Pending legacy mode frames are not transmitted. You can configure AP400/AP1000 U-APSD support from the CLI using the ESSID command apsdsupport or you can configure APSD support for an ESSID from the Web UI (Configuration > Wireless > ESSID and then turn on U-APSD).

Configure U-APSD

APSD settings are configured per ESS and APSD support is on by default; this setting only affects AP400/AP1000. To configure APSD from the Web UI, click Configuration > Wireless > ESS > select an ESS from the list > set APSD Support to on.

To turn on/off APSD support with the CLI, use the command apsd-support for the ESSID as shown in this example:

default# configure terminal default(config)# essid apsd default(config‐essid)# no apsd‐support default(config‐essid)# end

When is Virtualization Really on for an AP?

All APs except AP400 is always ready to use Virtual Cell or Native Cell; no configuration at the radio level is necessary. To enable either of them, simply configure the RF Virtualization mode in each ESS profile to Virtual Cell or Native Cell.

When is Virtualization Really on for an AP?

For AP400, the RF Virtualization mode is set to Virtual Port on the radio interface by default, and it can be changed as desired. This setting overrides the RF Virtualization mode configuration at the ESS-level. Both the radio and the ESS in use must be set as Virtual Port for RF Virtualization mode for AP400 to work.

The following table illustrates the three possible configurations for the AP400 Virtual Port:

	Radio Configuration	ESS Configuration	ESSIDs are…
AP400	on	on	Virtualized
	off	off	Not Virtualized
	off	on	Not Virtualized