When “multicast to unicast” conversion is enabled, multicast/broadcast packets will be restricted to respective VLANs only.
Supported in: AP110, AP122, AP332, AP822, AP832, OAP832, AP1020, FAP-U4231V, FAPU423EV
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.
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.
The following example enables multicasting with the CLI: controller(config‐essid)# multicast-enable
For command details, see the FortiWLC (SD) Command Reference.
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 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:
For multicast to work, you need to complete these four tasks:
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
FortiWLC (SD) provides the following support for bridged and tunneled devices during a WAN connection outage.
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:
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.
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.)
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
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.
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:
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:
Be aware that Virtual Cell Overflow has these tradeoffs:
Configure Virtual Cell Overflow with the Web UI
To set up Virtual Cell Overflow from the Web UI, follow these steps:
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.
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)#
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#
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)#
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
You can set the following beacon parameters:
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.
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
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
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.
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:
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:
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.
Configuring Virtual Cell Support for AP400 with Web UI
There are two steps for configuring Virtual Port:
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
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
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:
Rates at which clients can optionally connect, provided the clients and access points support the rates. Valid rates are as follows:
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.
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)#
In general, WMM contains these features:
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