Configuring an AP’s Radio Channels

AP channel configuration is configurable for 802.11bg which consists of 11 overlapping channels in United States deployments. Channel configuration for 802.11a is not an issue because there are no overlapping channels within the 802.11a spectrum.

In the 802.11b/g standard, there are 14 channels. As a result of FCC rules, there are 11 channels: channels 1 through 11 are used in the USA. Other countries may also use channels 12, 13, and 14. These channels represent the center frequency of the wireless transmission wave.

In practice, 802.11bg has only three operational frequencies in a given area, and most deploy-

Configuring an AP’s Radio Channels

ments use channels 1, 6, and 11, for which there is no overlap.

Figure 66: Channel 1, 6, and 11

To assign a channel, use the Dot11Radio interface command channel. With the Web UI, configure a channel by clicking Configuration > Wireless > Radio, select a radio and then select a Channel from the drop-down list.

Sitesurvey

Fortinet sitesurvey is a simple tool that aids in network planning to find the right placement (mounting location) of APs such that clients connected to these APs receive high throughput, excellent coverage. To find the right placement of your AP, connect your Wi-Fi client to the AP that is in the sitesurvey mode and move around the deployment perimeter to identify areas that provide good connectivity (based on the results from the sitesurvey tool) to the Wi-Fi client. You can adjust the placement of the AP depending on the sitesurvey results.

Pre-requisites

• Sitesurvey is supported only on AP832, AP822, FAP-U421, and FAP-U423.
• The AP must be running FortiWLC (SD) 6.1-2 or higher and can connect only in Open Clear mode.

Configuring Sitesurvey Options

Sitesurvey configuration and monitor options are available via CLI (AP boot console) and GUI. To access sitesurvey options, Connect to AP CLI from a controller or use a serial port.

Using the CLI

After the normal AP boot process, enter the sitesurvey enable command at the AP boot prompt to restart AP into the sitesurvey mode. In the sitesurvey mode the AP displays the sitesurvey prompt (ss >).

Sitesurvey commands always begin with the sitesurvey keyword or alternatively you can use the ss (alias) instead of the sitesurvey keyword. Sitesurvey provides the following additional commands to configure and monitor sitesurvey features.

Enabling Sitesurvey

sitesurvey enable

This command enables the sitesurvey mode. The AP will reboot into sitesurvey mode and display the sitesurvey prompt. ss > _

Disabling Sitesurvey

sitesurvey disable

This command disables the sitesurvey mode. AP will reboot into normal mode of operation.

Setting Country Code and Channel

sitesurvey countrycode set <country code>

By default the country code is set to US. When you set a country code, the first valid channel and the max supported Tx power for radio 0 and radio 1 for that country code is automatically set. To override the default channel for a country code, enter the following command sitesurvey channel set <radio_index> <channel>

Where,

• radio_index refers to the AP radios.
• Enter 1 for radio 1 (2.4 Ghz).
• Enter 2 for radio 2 (5Ghz).

To get the list of supported country codes, use the ss countrycode help command.

Setting Inactivity Time

sitesurvey inactivitytime <itime>

This command sets the time (in seconds) the AP will remain in the sitesurvey mode before a client associates with it. The time is specified in seconds and by default the AP will remain in the sitesurvey mode for 3600s. After the period of inactivity, the AP will reboot into normal AP mode.

When using the GUI, the browser window will reset after 3600 seconds of inactivity, irrespective of the time set for inactivity. The browser refresh time cannot be changed.

Setting IP Address

sitesurvey ipconfig <ip_address> <netmask>

This command configures the sitesurvey AP with an IP address. You can use this IP address to access the sitesurvey GUI page via a browser. By default, the IP address and netmask are set to 192.168.0.1 and 255.255.255.0.

Configuring SSID

sitesurvey ssid <radio_index> [<ssid>]

Where,

• radio_index can be 0, 1, or 3
• Enter 0 for radio 1 (2.4 Ghz)
• Enter 1 for radio 2 (5 Ghz)
• Enter 3 to specify SSID for both the radios

This command configures SSID for the specified radio. By default, SSID for radio 1 (2.4Ghz) is set to Meru_Site_Survey_2.4 and SSID for radio 2 (5 Ghz) is set to Meru_Site_Survey_5.

Examples ss > sitesurvey ssid 3

MERU_SITE_SURVEY SSID is assigned for both radio1 and radio2 as MERU_SITE_SURVEY

ss > sitesurvey ssid 1 <‐‐ if SSID is not specified SSID is assigned to radio1 as MERU_SITE_SURVEY_2.4 by default

ss > sitesurvey ssid 2 <‐‐ if SSID is not specified SSID is assigned to radio2 as MERU_SITE_SURVEY_5 by default

ss > sitesurvey ssid 3 <‐‐ if SSID is not specified MERU_SITE_SURVEY_2.4 is assigned as SSID for radio1

MERU_SITE_SURVEY_5 is assigned as SSID for radio2.

After configuring SSID on AP radios, you can use the following command to selectively (per radio) enable or disable broadcasting SSID. sitesurvey publishssid <radio_index> [on|off] By default, SSID for both radios are broadcast.

Enable or Disable Radio

sitesurvey {radio | r} <radio_index> [on|off]

Where,

• radio_index can be 0, 1, or 3
• Enter 0 for radio 1 (2.4 Ghz)
• Enter 1 for radio 2 (5 Ghz)
• Enter 3 for both the radios

This command enables or disables AP radio. Wi-fi clients connecting to the sitesurvey AP must use the same radio that is enabled in the AP. By default, both the radios are enabled.

Configure Sitesurvey Refresh Rate

sitesurvey statsrefrate [<rate>]

This command configures the time interval (specified in milliseconds) at which the AP will collect and send (display) sitesurvey results. By default, the refresh rate is set to 1000ms. The sitesurvey results can be viewed from the sitesurvey GUI page or the CLI.

Setting the Tx Power

sitesurvey txpwr set <radio_index> [<tx_power>]

Where,

• radio_index can be 0, 1, or 3
• Enter 0 for radio 1 (2.4 Ghz)
• Enter 1 for radio 2 (5 Ghz)
• Enter 3 for both the radios

Use this command to selectively set the transmit power for AP radios. By default, Tx power is set to maximum possible Tx power based on the country code, channel and the hardware capabilities. The sitesurvey txpwr set 3 command (without the power value) will set the max Tx power supported for the selected country to both the radios.

Save Sitesurvey Configuration

sitesurvey save

After you have configured all sitesurvey options, enter this command to save your sitesurvey configuration. This command creates an ESSID with all configured parameters. Your Wi-Fi can now associate to this AP using the ESSID.

Using GUI

To access the sitesurvey GUI page, enter the IP address of the AP. If not previously set, enter the default IP address (192.168.0.1) of the AP. By default, the GUI page shows the sitesurveyresults page. Click the Configure button to access the sitesurvey configuration options.

Figure 67: Sitesurvey Configuration Options:

TABLE 24: Sitesurvey Configuration Parameters using GUI

TABLE 24: Sitesurvey Configuration Parameters using GUI

After configuring the above parameters click the Apply button to save the configuration.

Viewing Sitesurvey Results

Sitesurvey results can be viewed from CLI and using the GUI.

Using GUI

By default, the Sitesurvey page (Figure 2) is displayed when you connect to the AP via browser. The Sitesurvey page among other pre-configured values displays key information about the connectivity experience of your Wi-Fi client.

The GUI page shows Sitesurvey results of only ONE client (the last connected client) connected to the AP. To view Sitesurvey results from all connected clients, use options from CLI.

Figure 68: Viewing Sitesurvey Results

Connectivity Experience Parameters

The Sitesurvey parameters that include RSSI, S/N Ratio, Tx Power, 802.11 Tx Rate, and

802.11 Rx Rate illustrate the connection experience of the Wi-Fi client at the given location.

Troubleshooting Parameters

The parameters, Tx Retry count and Tx Failure illustrate issues or errors in connection between the Wi-Fi client and the AP at the given location.

Network Parameters

Tx Packets and Rx Packets indicate the network data traffic between the AP and the Wi-Fi client.

NOTE : As you move with your Wi-Fi client, the survey results are updated as per configured refresh rate.

Disable Site Survey

To disable Sitesurvey on the AP, click the Disable Sitesurvey button. This button will reboot the AP into normal AP mode.

Using CLI

Viewing Sitesurvey Configuration

sitesurvey showconfig

This command displays the current sitesurvey configuration.

Sample Output ss > sitesurvey showconfig

Site Survey                          : 1

Country Code                         : US

AP IP address                        : 192.168.0.1

AP Netmask                           : 255.255.255.0

SSID for radio0                      : MERU_SITE_SURVEY_2.4

SSID for radio1                      : MERU_SITE_SURVEY_5

Broadcast SSID for radio0            : 1

Broadcast SSID for radio1            : 1 radio0 <2.4G>                        : 1 radio1 <5G>                          : 1 Channel for radio0                   : 6

Channel for radio1                   : 36

Tx Power for radio0             : 25

Tx Power for radio1             : 23

Basic Tx Rate for radio0       : 1 2 5.5 11

Basic Tx Rate for radio1       : 1 2 5.5 11

Stats Refresh Rate            : 1000

Inactivity Timeout             : 3600 ss >

Viewing Sitesurvey Results (Statistics)

sitesurvey showstatistics

This command displays sitesurvey results of all the Wi-Fi clients connected to the AP.

Sample Output

ss > sitesurvey showstatistics ss >

      AP MAC         STATION MAC                 ESSID              Ch  ChWd SNR RSSI TxPwr TxRate RxRate TxRetry TxFail  TxPkts  RxPkts

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐  ‐‐‐ ‐‐‐‐ ‐‐ ‐‐‐‐ ‐‐‐‐‐ ‐‐‐‐‐‐ ‐‐‐‐‐‐ ‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐

00:0c:e6:12:28:1f 6c:88:14:f3:a8:04                       survey51   36   20  42  ‐45    23    144    130       0       1      65     68 ss stats ss >

      AP MAC         STATION MAC                 ESSID              Ch  ChWd SNR RSSI TxPwr TxRate RxRate TxRetry TxFail  TxPkts  RxPkts

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐  ‐‐‐ ‐‐‐‐ ‐‐ ‐‐‐‐ ‐‐‐‐‐ ‐‐‐‐‐‐ ‐‐‐‐‐‐ ‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐

00:0c:e6:12:28:1f 6c:88:14:f3:a8:04                       survey51   36   20  42  ‐45    23    144    130       0       1      66     68 ss stats ss >

      AP MAC         STATION MAC                 ESSID              Ch  ChWd SNR RSSI TxPwr TxRate RxRate TxRetry TxFail  TxPkts  RxPkts

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐  ‐‐‐ ‐‐‐‐ ‐‐ ‐‐‐‐ ‐‐‐‐‐ ‐‐‐‐‐‐ ‐‐‐‐‐‐ ‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐

00:0c:e6:12:28:1f 6c:88:14:f3:a8:04                       survey51   36   20  42  ‐45    23    144    123       0       1      68     68 ss stats ss >

      AP MAC         STATION MAC                 ESSID              Ch  ChWd SNR

RSSI TxPwr TxRate RxRate TxRetry TxFail  TxPkts  RxPkts

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐  ‐‐‐ ‐‐‐‐ ‐‐ ‐‐‐‐ ‐‐‐‐‐ ‐‐‐‐‐‐ ‐‐‐‐‐‐ ‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐

00:0c:e6:12:28:1f 6c:88:14:f3:a8:04                       survey51   36   20  42  ‐45    23    144    104       0       1      69     691 ss >

Automatic Radio Resource Provisioning (ARRP)

By using the ARRP feature, each AP scans all channels and provides the scan details to the controller. The controller uses this information to select and allocate the best available channel per radio. By default, this feature is disabled.

• Supported only on 11ac APs.
• Once enabled, the virtual cell is not available for 11ac APs.
• Non-11ac APs will continue to work as configured and will not be affected by auto channel feature.
• The APs will reboot to the newly allocated channel after both initial planning and dynamic channel change.
• If the ARRP is disabled, all 11ac APs will reboot to default channels.

Automatic Radio Resource Provisioning (ARRP)

Configuring Using WebUI

To enable this feature, go to Configuration > Wireless > ARRP and in the configuration tab, enable the Auto Channel option.

• Planning Channel: Once enabled, the respective radios of all APs are set to the channels selected for radio 1 and radio 2. In the above screenshot, the planning channel is set to 1 / 20MHz for radio 1 and 149/40MHz for radio 2. Based on the report received by all APs, the controller allocates the optimum channel. DFS channels are not available to be set as planning channel.
• Auto Power: The auto power functionality is applied only after channel allocation irrespective of when the auto power option was enabled. When enabled, the controller will determine the optimum power level between neighbouring (by channel) 11ac APs. The auto power option can be enabled and applied only when ARRP feature is enabled.
• Freeze: The option is applied after the initial planning phase. When this option is disabled, the 11ac APs perform a periodic scan (at the end of every minute) on their allocated channels. This is used to determine the quality of the channel. If the quality of the channel crosses the threshold limit (based on three consecutive scans), it sends a request for change of channel. If enabled, the periodic scan is disabled and the 11ac APs remain in allocated channels irrespective of the channel quality.
• If this option is disabled, the radio interface settings cannot be modified.
• Timer State and Timer: This option is available only when the Freeze option is disabled. If Timer State is Off, channel scanning occurs every one minute continuously. To avoid frequent channel change, you can set the channel scan interval to happen at the end of 15

Automatic Radio Resource Provisioning (ARRP)

minutes. With this, channel scan is scheduled for once in 15 mins. In each scan cycle sampling is done for 10 iterations i.e. for 10 mins.

• DFS: By default scanning and allocation of DFS channel is disabled during the planning phase. If enabled, the APs can scan DFS channels and they can be allocated DFS channels.
• DFS option must be selected when the ARRP is enabled. Enabling DFS after enabling Auto RF will require re-planning of channel allocation for all APs
• REPLAN: This option is to be used if a new AP is added to the network after the initial planning is complete.

The AP-Radio Interfaces tab lists all APs with its operating frequency and transmit-power respectively.

Configuring Using CLI

• Use the show arrp‐config command to view the current settings

MC‐4200‐AC‐MCA(15)# show arrp‐config MCA Global Settings

Enable/Disable Auto Channel : enable Radio 1 Channel             : 11 Radio 1 Channel Width       : 20‐mhz Radio 2 Channel             : 48 Radio 2 Channel Width       : 20‐mhz

Auto Power on/off           : off

Freeze yes/no               : No

Timer State on/off          : on

Timer                       : 15

Dfs on/off                  : on

• Use the show arrp‐ap‐radio‐interface command to view the list of APs and their operating frequency and power values.

MC‐4200‐AC‐ARRP(15)# show arrp‐ap‐radio‐interface

AP ID AP Name Radio1 oper ch Radio2 oper ch Radio1 Transmit Power (dBm) Radio2 Transmit Power (dBm)

• AP‐3 6              36             24                            23

Automatic Radio Resource Provisioning (ARRP)

• AP‐4 1              36             24                            23 6     AP‐6     6              40             24                            23 13    AP‐13    1              36             24                            23 17    AP‐17    1              36             24                            23 19    AP‐19    6              36             10                            13 20    AP‐20    6              36             24                            23

ARRP radio interfaces(7 entries)

• Use the arrp global command followed by one of the following options to configure and use the ARRP feature

‐auto‐power ‐ To enable or disable auto allocation of transmit power

‐dfs ‐ To enable or disable the use of DFS channels in planning

‐disable ‐ To disable ARRP   

‐Enable ‐ To enable ARRP

‐Freeze‐ To enable or disable dynamic channel scanning

‐radio1‐channel‐planning‐ To specify channel for initial planning

‐radio2‐channel‐planning‐ To specify channel for initial planning

‐replan‐ To perform re‐planning if a new AP has joined network

‐timer‐state‐ Enable or disable to avoid frequent channel change

‐timer‐value‐ To specify the time interval for the dynamic channel scan

Limitations

• If disabled, existing vCell profiles will be pushed to all 11ac APs irrespective of whether the AP was part of the vCell profile before auto channel feature was enabled. Native cell profiles will remain unchanged.
• As part of auto power functionality, the Tx power levels on the AP is not increased back to default values if the neighboring AP which this AP earlier reported as having high power goes down.

Hotspot 2.0

Hotspot 2.0 is a specification by the Wi-Fi Alliance that specifies a framework for seamless roaming between WiFi networks and Cellular networks. The specification is based on the IEEE802.11u standard; a Generic Advertisement Service (GAS) that provides over-the-air

Hotspot 2.0

transportation for frames of higher layer advertisements between stations APs and external information servers. This feature will allow users to configure hotspot profiles that can (optionally) be connected to existing ESS Profiles as desired. An ESS-profile connected to a hotspot profile will advertise 802.11u capabilities in its beacons.

FAP-U42x and FAP-U32x are Passpoint R2 certified.

Adding a Hotspot 2.0 Profile

The Hotspot Profiles can be created from the Configuration > Wireles > Hotspot 2.0 page. By default, the page shows the following details about a Hotspot profile.

• Hotspot Profile Name – Displays the name of the Hotspot Profile.
• Description – Displays the Description provided for the Hotspot profile.
• Venue Type – Displays the Venue Type.
• Access Network Type – Select the Access Network Type from the list. The default selection is displayed as Private Network. The types are as follows:
• Private Network
• Private Network with Guest Access
• Chargeable Public Network
• Free Public Network
• Personal Device Network
• Emergency Services Only Network
• Test or Experimental Network
• Wildcard Network
• IPv6 Availability – Select the IPv6 Availability from the list. The default selection is displayed as Address type not available. The types are as follows:
• Address type available
• Address type not available
• Availability of the Address type not known
• IPv4 Availability – Select the IPv4 Availability from the list. The default selection is displayed as Address type not available. The types are as follows:
• Address type available
• Address type not available
• Availability of the Address type not known
• Port-restricted IPv4 address available
• Single NATed private IPv4 address available
• Double NATed private IPv4 address available

Hotspot 2.0

Port-restricted IPv4 address and single NATed IPv4 address available

• Port-restricted IPv4 address and double NATed IPv4 address available
• Roaming Consortium – Enter the roaming ORG ID for the Hotspot profile. The valid range is 0-10 characters.
• Operators – Enter multiple network operators. Select a language and enter a name. The valid range is 0 – 256 characters.
• Venue – Enter multiple hotspot venues. Select a language and enter a name. The valid range is 0 – 512 characters.
• 3GPP Cell Network – Provide the following details:
• Country code of the operator.
• Provide the 3GPP Cell Network MCC. The default value is displayed is 0. The Valid range is [0-999]. Provide the 3GPP Cell Network MNC. The default value is displayed is 0. The Valid range is [0-999].
• Domain Name – Provide the Domain Name. The valid range is [0-128] chars.
• NAI Realm from 1-10 – Provide the NAI Realm [1-10] from the list. The valid range is [0-50] chars.
• NAI Realm Auth Method from 1-10 – Select the NAI Realm Auth Method [1-10] from the list. The valid range is [0-50] chars. The types are as follows:
• EAP TLS Certificate
• EAP TTLS MSCHAPv2 Username/Password
• EAP SIM
• EAP AKA
• EAP AKA`
• Advanced Settings – Provide the following configuration details for advanced settings: HESSID – A globally unique identifier, used to give a single identifier for a group of APs connected to the same SP or other destination network(s).
• GTK Per Station – Enables the Group Temporal Key (GTK) to be assigned per station.
• Gas Come Back Flag – Enables the Generic Advertisement Service (GAS) comeback request/response option.
• Gas Come back Delay (millisecs) – At the end of the GAS comeback delay interval, the client can attempt to retrieve the query response using the comeback request action frame.
• ASRA Flag – Enable the Additional Step Required for Access (ASRA) to indicate that the network requires one more step for access. Authentication type – Configure the network authentication type required as per ASRA. Supported values are, Acceptance of terms and conditions, On line enrolment supported, http/https redirection, and DNS redirection.

Hotspot 2.0

Redirect URL – Specify the Redirect URL in case of http/https redirection and DNS Redirection.

• WAN Metrics – Provide the following configuration details for WAN metrics:
• Link Status State – Select the status of the WAN link.
• Symmetric Link – Enable symmetric bandwidth. At Capacity – Select whether the WAN link is at capacity and no additional mobile devices will be allowed to associate with the AP.
• Down Link speed/Up Link speed – The WAN Backhaul link for current downlink/uplink speed in KBPS.
• Down Link load/Up Link load – The current percentage load of the downlink/uplink connection, measured over an interval the duration of which is reported by the Load Measurement Duration.
• Load Measurement Duration – The duration over which the downlink/uplink load is measured in KBPS.
• Connection CapabilityThe Connection Capability enables filtering of protocols, allowing or restricting traffic on some protocols and ports. A set of system defined protocols as listed. Additionally, you can also create rules for custom protocols.
• QoS Map – Create a Quality of Service (QoS) policy by configuring the following DSCP ranges and DSCP exceptions.
• DSCP Ranges – For a given DSCP range, specify the User Priority (valid range: 0 -7), DSCP High Priority (valid range: 0 – 255), and DSCP Low Priority (valid range: 0-255). DSCP Exceptions – For a given DSCP exception, specify the User Priority (valid range: 0 -7) and the DSCP Value (valid range: 0 – 255).
• OSU Settings – The Online Sign Up (OSU) Service settings configures one or more Hotspot providers offering OSU service.
• Online Sign Up Support – Select to enable OSU.
• OSEN Enable – Enable OSU Server-only authenticated layer-2 Encryption Network (OSEN) to indicate that the hotspot uses a OSEN network type. This network provisions clients using the OSU functionality.
• OSU/OSEN ESSID – Specify the OSU ESSID.

OSU Server URL – Specify the URL of the OSU server.

• OSU NAI – Specify the OSU NAI for authentication.

Click Settings to configure the OSU provider settings.

• OSU Provider Friendly Names
• OSU Provoder Icons
• OSU Provider Method – Select one of the OSU provider provisioning methods, OMADM or SOAP-XML.

Hotspot 2.0

OSU Provider Description – The description of the OSU Provider.

Select OK. The Hotspot Profile is added and displayed on the Hotspot Profile screen.

The following operations can be performed on the Hotspot 2.0 profile.

• Delete – Select a Hotspot Profile and click Delete. The selected Hotspot Profile gets deleted from the Hotspot Profile screen.
• Edit – Select a Hotspot Profile and click Edit.
• View – Allows to view the details of the Hotspot Profile. Select a Hotspot Profile and click View.

Introduction

This document provides the following information for FortiOS 6.0.2 build 0163:

Supported models

FortiOS 6.0.2 supports the following models.

Special Notices

WAN optimization and web caching functions

WAN optimization and web caching functions are removed from 60D and 90D series platforms, starting from 6.0.0 due to their limited disk size. Platforms affected are: l FGT-60D l FGT-60D-POE l FWF-60D l FWF-60D-POE l FGT-90D l FGT-90D-POE l FWF-90D l FWF-90D-POE l FGT-94D-POE

Upon upgrading from 5.6 patches to 6.0.0, diagnose debug config-error-log read will show command parse error about wanopt and webcache settings.

FortiGuard Security Rating Service

Not all FortiGate models can support running the FortiGuard Security Rating Service as a Fabric “root” device. The following FortiGate platforms can run the FortiGuard Security Rating Service when added to an existing Fortinet Security Fabric managed by a supported FortiGate mode:

• FGR-30D-A l FGR-30D l FGR-35D l FGR-60D l FGR-90D l FGT-200D l FGT-200D-POE l FGT-240D l FGT-240D-POE l FGT-280D-POE l FGT-30D l FGT-30D-POE l FGT-30E l FGT-30E-MI l FGT-30E-MN l FGT-50E Special Notices 7
• FGT-51E l FGT-52E l FGT-60D l FGT-60D-POE l FGT-70D l FGT-70D-POE l FGT-90D l FGT-90D-POE l FGT-94D-POE l FGT-98D-POE l FWF-30D l FWF-30D-POE l FWF-30E l FWF-30E-MI l FWF-30E-MN l FWF-50E-2R l FWF-50E l FWF-51E l FWF-60D l FWF-60D-POE l FWF-90D l FWF-90D-POE l FWF-92D

Built-in certificate

FortiGate and FortiWiFi D-series and above have a built in Fortinet_Factory certificate that uses a 2048-bit certificate with the 14 DH group.

FortiGate and FortiWiFi-92D hardware limitation

FortiOS 5.4.0 reported an issue with the FG-92D model in the Special Notices > FG-92D High Availability in Interface Mode section of the release notes. Those issues, which were related to the use of port 1 through 14, include:

• PPPoE failing, HA failing to form. l IPv6 packets being dropped. l FortiSwitch devices failing to be discovered. l Spanning tree loops may result depending on the network topology.

FG-92D and FWF-92D do not support STP. These issues have been improved in FortiOS 5.4.1, but with some side effects with the introduction of a new command, which is enabled by default:

config global set hw-switch-ether-filter <enable | disable>

Special Notices

When the command is enabled:

• ARP (0x0806), IPv4 (0x0800), and VLAN (0x8100) packets are allowed. l BPDUs are dropped and therefore no STP loop results. l PPPoE packets are dropped. l IPv6 packets are dropped. l FortiSwitch devices are not discovered. l HA may fail to form depending the network topology.

When the command is disabled:

• All packet types are allowed, but depending on the network topology, an STP loop may result.

FG-900D and FG-1000D

CAPWAP traffic will not offload if the ingress and egress traffic ports are on different NP6 chips. It will only offload if both ingress and egress ports belong to the same NP6 chip.

FortiClient (Mac OS X) SSL VPN requirements

When using SSL VPN on Mac OS X 10.8, you must enable SSLv3 in FortiOS.

FortiClient profile changes

With introduction of the Fortinet Security Fabric, FortiClient profiles will be updated on FortiGate. FortiClient profiles and FortiGate are now primarily used for Endpoint Compliance, and FortiClient Enterprise Management Server (EMS) is now used for FortiClient deployment and provisioning.

The FortiClient profile on FortiGate is for FortiClient features related to compliance, such as Antivirus, Web Filter, Vulnerability Scan, and Application Firewall. You may set the Non-Compliance Action setting to Block or Warn.

FortiClient users can change their features locally to meet the FortiGate compliance criteria. You can also use FortiClient EMS to centrally provision endpoints. The EMS also includes support for additional features, such as VPN tunnels or other advanced options. For more information, see the FortiOS Handbook – Security Profiles.

Use of dedicated management interfaces (mgmt1 and mgmt2)

For optimum stability, use management ports (mgmt1 and mgmt2) for management traffic only. Do not use management ports for general user traffic.

Upgrade Information

Upgrading to FortiOS 6.0.2

Supported upgrade path information is available on the Fortinet Customer Service & Support site.

To view supported upgrade path information:

1. Go to https://support.fortinet.com.
2. From the Download menu, select Firmware Images.
3. Check that Select Product is FortiGate.
4. Click the Upgrade Path tab and select the following:

l Current Product l Current FortiOS Version l Upgrade To FortiOS Version 5. Click Go.

If you are upgrading from version 5.6.2 or 5.6.3, this caution does not apply.

Before upgrading, ensure that port 4433 is not used for admin-port or admin-sport (in config system global), or for SSL VPN (in config vpn ssl settings). If you are using port 4433, you must change admin-port, admin-sport, or the SSL VPN port to another port number before upgrading.

Physical interface inclusion in zones

Upgrading from 5.6.3 or later removes all of the members of a zone if the zone contains a physical interface and at least one of that physical interface’s VLAN interfaces is removed. For example:

Before Upgrade:

config system zone edit “Trust”

set interface “port1” “Vlan01” “Vlan02” “Vlan03”

next

After Upgrade:

config system zone edit “Trust”

next

Remove “port1” from the list and the upgrade will retain the VLANs.

Conditions when physical zone members are removed: l If a physical interface has a VLAN associated (regardless of whether they are in the same zone or any zone) Conditions when VLAN zone members are removed: l If the parent physical interface is also set on a zone

You can use the following options to prepare for the upgrade:

• Use only physical interfaces that have no VLAN associations Or:
• Create new VLANs in place of current physical interface zone members, and remove all physical zone members from zones using only the associated, new VLAN entries.

Fortinet Security Fabric upgrade

FortiOS 6.0.2 greatly increases the interoperability between other Fortinet products. This includes:

l FortiAnalyzer 6.0.0 l FortiClient 6.0.0 l FortiClient EMS 6.0.0 l FortiAP 5.4.4 and later l FortiSwitch 3.6.4 and later

Upgrade the firmware of each product in the correct order. This maintains network connectivity without the need to use manual steps.

Before upgrading any product, you must read the FortiOS Security Fabric Upgrade Guide.

Minimum version of TLS services automatically changed

For improved security, FortiOS 6.0.2 uses the ssl-min-proto-version option (under config system global) to control the minimum SSL protocol version used in communication between FortiGate and third-party SSL and TLS services.

When you upgrade to FortiOS 6.0.2 and later, the default ssl-min-proto-version option is TLS v1.2. The following SSL and TLS services inherit global settings to use TLS v1.2 as the default. You can override these settings.

• Email server (config system email-server) l Certificate (config vpn certificate setting) l FortiSandbox (config system fortisandbox) l FortiGuard (config log fortiguard setting) l FortiAnalyzer (config log fortianalyzer setting)

• LDAP server (config user ldap) l POP3 server (config user pop3)

Downgrading to previous firmware versions

Downgrading to previous firmware versions results in configuration loss on all models. Only the following settings are retained:

l operation mode l interface IP/management IP l static route table l DNS settings l VDOM parameters/settings l admin user account l session helpers l system access profiles

If you have long VDOM names, you must shorten the long VDOM names (maximum 11 characters) before downgrading:

1. Back up your configuration.
2. In the backup configuration, replace all long VDOM names with its corresponding short VDOM name. For example, replace edit <long_vdom_name>/<short_name> with edit <short_name>/<short_ name>.
3. Restore the configuration.
4. Perform the downgrade.

Amazon AWS enhanced networking compatibility issue

With this new enhancement, there is a compatibility issue with older AWS VM versions. After downgrading a 6.0.2 image to an older version, network connectivity is lost. Since AWS does not provide console access, you cannot recover the downgraded image.

When downgrading from 6.0.2 to older versions, running the enhanced nic driver is not allowed. The following AWS instances are affected:

• C3 l C4 l R3
• I2 l M4 l D2

FortiGate VM firmware

Fortinet provides FortiGate VM firmware images for the following virtual environments:

Citrix XenServer and Open Source XenServer

• .out: Download the 64-bit firmware image to upgrade your existing FortiGate VM installation.
• .out.OpenXen.zip: Download the 64-bit package for a new FortiGate VM installation. This package contains the QCOW2 file for Open Source XenServer.
• .out.CitrixXen.zip: Download the 64-bit package for a new FortiGate VM installation. This package contains the Citrix XenServer Virtual Appliance (XVA), Virtual Hard Disk (VHD), and OVF files.

Linux KVM

• .out: Download the 64-bit firmware image to upgrade your existing FortiGate VM installation.
• .out.kvm.zip: Download the 64-bit package for a new FortiGate VM installation. This package contains QCOW2 that can be used by qemu.

Microsoft Hyper-V

• .out: Download the 64-bit firmware image to upgrade your existing FortiGate VM installation.
• .out.hyperv.zip: Download the 64-bit package for a new FortiGate VM installation. This package contains three folders that can be imported by Hyper-V Manager on Hyper-V 2012. It also contains the file vhd in the Virtual Hard Disks folder that can be manually added to the Hyper-V Manager.

VMware ESX and ESXi

• .out: Download either the 64-bit firmware image to upgrade your existing FortiGate VM installation.
• .ovf.zip: Download either the 64-bit package for a new FortiGate VM installation. This package contains Open Virtualization Format (OVF) files for VMware and two Virtual Machine Disk Format (VMDK) files used by the OVF file during deployment.

Firmware image checksums

The MD5 checksums for all Fortinet software and firmware releases are available at the Customer Service & Support portal, https://support.fortinet.com. After logging in select Download > Firmware Image Checksums, enter the image file name including the extension, and select Get Checksum Code.

FortiGuard update-server-location setting

The FortiGuard update-server-location default setting is different between hardware platforms and VMs. On hardware platforms, the default is any. On VMs, the default is usa.

On VMs, after upgrading from 5.6.3 or earlier to 5.6.4 or later (including 6.0.0 or later), update-server-location is set to usa.

If necessary, set update-server-location to use the nearest or low-latency FDS servers.

To set FortiGuard update-server-location:

config system fortiguard set update-server-location [usa|any] end

Product Integration and Support

FortiOS 6.0.2 support

The following table lists 6.0.2 product integration and support information:

Language support

The following table lists language support information.

Language support

Language	GUI
English
Chinese (Simplified)
Chinese (Traditional)
French
Japanese
Korean
Portuguese (Brazil)
Spanish

SSL VPN support

SSL VPN standalone client

The following table lists SSL VPN tunnel client standalone installer for the following operating systems.

Operating system and installers

Other operating systems may function correctly, but are not supported by Fortinet.

SSL VPN web mode

The following table lists the operating systems and web browsers supported by SSL VPN web mode.

Supported operating systems and web browsers

Other operating systems and web browsers may function correctly, but are not supported by Fortinet.

SSL VPN host compatibility list

The following table lists the antivirus and firewall client software packages that are supported.

Supported Microsoft Windows XP antivirus and firewall software

Product	Antivirus		Firewall
Symantec Endpoint Protection 11
Kaspersky Antivirus 2009
McAfee Security Center 8.1
Trend Micro Internet Security Pro
F-Secure Internet Security 2009

Supported Microsoft Windows 7 32-bit antivirus and firewall software

Product	Antivirus	Firewall
CA Internet Security Suite Plus Software
AVG Internet Security 2011
F-Secure Internet Security 2011
Kaspersky Internet Security 2011
McAfee Internet Security 2011
Norton 360 Version 4.0
Norton Internet Security 2011
Panda Internet Security 2011
Sophos Security Suite
Trend Micro Titanium Internet Security
ZoneAlarm Security Suite
Symantec Endpoint Protection Small Business Edition 12.0

Resolved Issues

The following issues have been fixed in version 6.0.2. For inquires about a particular bug, please contact Customer Service & Support.

AntiVirus

Application Control

Authentication & User

Connectivity

DLP

Firewall

FortiView

HA

IPS

IPsec VPN

Log & Report

Proxy

Router

SSL VPN

Switch

System

Upgrade

VM

VoIP

Web Filter

Web Proxy

WiFi

Common Vulnerabilities and Exposures

Visit https://fortiguard.com/psirt for more information.

Known Issues

The following issues have been identified in version 6.0.2. For inquires about a particular bug or to report a bug, please contact Customer Service & Support.

Application Control

FortiGate 3815D

FortiSwitch-Controller/FortiLink

FortiView

GUI

HA

IPS

IPsec VPN

Log & Report

Security Fabric

SSL VPN

System

Upgrade

Web Filter

Limitations

Citrix XenServer limitations

The following limitations apply to Citrix XenServer installations:

• XenTools installation is not supported.
• FortiGate-VM can be imported or deployed in only the following three formats:
• XVA (recommended)
• VHD l OVF
• The XVA format comes pre-configured with default configurations for VM name, virtual CPU, memory, and virtual NIC. Other formats will require manual configuration before the first power on process.

Open source XenServer limitations

When using Linux Ubuntu version 11.10, XenServer version 4.1.0, and libvir version 0.9.2, importing issues may arise when using the QCOW2 format and existing HDA issues.

Configuring 802.11k/r

Devices can now benefit from the 802.11r implementation to fast roam between best available access points within a controller domain. Additionally, with implementation of 802.11k specifications you can now calculate 802.11k neighbor and radio measurement reports.

The fast roaming capability and 802.11k is configurable in ESS profile.

Supported Access Points: AP122, AP822, AP832, OAP832

Limitations

• Supported only for clients that are compliant with 802.11k/v/r specifications • Fast roaming is not available in inter-controller roaming.

Enabling 802.11k

Using WebUI

• Go to Configuration > Wireless > ESS and in the ESS Profile tab, change the following:
• For 802.11r, select On.
• For 802.11r Mobility Domain, enter an integer value.
• For 802.11k, select On to perform radio measurements.

Configuring 802.11k/r

Using CLI

default(15)# configure terminal default(15)(config)# essid fastroam‐1 default(15)(config‐essid)# 802.11r on default(15)(config‐essid)# 802.11k on default(15)(config‐essid)# 802.11r‐mobility‐domain‐id 100

Decided to make a video discussing my lack of videos and the things we have coming down the pipe. Pretty stoked about them and excited to get you guys some fresh content. Keep an eye out for more videos as I am making them a priority now.

Roaming Across Controllers (RAC)

Clients can roam between access points connected to two different controllers in same subnet or different subnets. FortiWLC (SD) allows you to specify static or dynamic roaming.

Things to consider before enabling RAC

• IP PREFIX validation has to be OFF in the RAC enabled ESS profile.
• RAC can be enabled on more than one ESSID
• If any parameter of an ESSID profile is changed, then RAC must be stopped and the changes made in the ESSID must be updated to all controllers in the roaming domain. Ensure that the controller IP is reachable before adding its IP address to the roaming domain.
• In the output of show roaming-domain all command, the -1 value in the VLAN column depicts tunnelling to another controller in the roaming domain.

In static DHCP home configuration, you specify one of the controllers (in the roaming domain) as the home controller. A client associating with any controller in the roaming domain will receive an IP address from this home controller. Once a controller is set has the home controller, it applies to all the native VLAN, configured VLAN and dynamic VLAN configurations of that controller as per the “tunnel interface type” set in the ESS profile.

In dynamic DHCP home configuration, a client associating with a controller for the first time will continue to receive IP address from that controller and will be the clients the home controller. To allow dynamic roaming, set the home controller IP address as 0.0.0.0.

Roaming Time-out

In a dynamic roaming scenario, if a client leaves the coverage area and returns after the configured timeout value, a fresh association happens and the client may get associated with a different controller as its home controller. The roaming time-out value (in minutes) for clients can be configured via CLI:

default(15)(config)# roaming‐domain roam‐time‐out 70

Roaming Across Controllers (RAC)

Default and minimum timeout value is 60 minutes and maximum is 240 minutes. The roaming timeout countdown starts as soon as the client leaves the coverage area.

NOTE: When RCA is stopped all the existing clients are forcefully de-authenticated and forced to reconnect. Irrespective of the client has roamed or not, this process is applied to all clients in the roaming domain.

Setting up RAC requires the following steps

Static Roaming

1. Specify an ESSID for the roaming domain.
2. Add your controller’s IP address as the member controller.
3. Add your controller’s IP address as the Home controller.
4. Repeat the above steps for adding peer controllers. Ensure that you keep the same ESSID name and the home controller IP address.

Dynamic Roaming

1. Specify an ESSID for the roaming domain.
2. Add your controller’s IP address as the member controller.\
3. Add 0.0.0.0 as the IP address of the home controller.
4. Repeat the above steps for adding peer controllers. Ensure that you keep the same ESSID name and the home controller IP address as 0.0.0.0.

Configuring Using WebUI

1. Go to Configuration > Wired > RAC.
2. In the Peer Controllers tab add the following:

• ESSID: This should be replicated as-is across in all controllers in the roaming domain.
• Peer Controller IP address

Roaming Across Controllers (RAC)

• Home DHCP controller IP address: IP address of the home controller in the roaming domain. All the DHCP packets from the visiting client will be forwarded to this home controller and will be delivered locally in the home controller.

Roaming Across Controllers (RAC)

Configuring Using CLI

A new CLI command roaming-domain with the following options is available to set up RAC • essid – Specify the name of the common ESSID that is available in all 6 controllers in the roaming domain

• start – To start RAC.
• stop – To stop RAC
• peer-controller – To specify the IP address of the peer controller in the roaming domain
• homedhcp-controller – To specify the home controller in the roaming domain.

Example default(15)(config)# roaming‐domain start

default(15)(config)# roaming‐domain essid Roaming1 peer‐controller 10.10.1.20 homedhcp‐controller 10.10.12.100

Dynamic DHCP home

default(15)(config)# roaming‐domain essid Roaming1 peer‐controller 10.10.1.20 homedhcp‐controller 0.0.0.0.

Where, essid is the name of the “ESS profile” string displayed in the show essid command.

Replacing Access Points

You can replace APs in one of the following conditions:

• If you have a faulty AP, you can replace that with a new AP of the same model as the faulty AP.
• Migrate from an older AP model to a newer AP model.

Before Replacing Access Points

The following are important points to remember before you replace your access points: • Replacing one AP model with another usually preserves the settings of the original configuration. A newer AP may have settings that the older one does not; those settings will be set to the default.

• Despite the fact that some AP settings and configurations can be carried over when replacing an AP, users cannot simply replace an AP400 with a different model (such as an AP1000). The two models have very different capabilities and configuration specifications and should not be considered synonymous.

Replacing Access Points

How to Replace Access Points

If you are replacing existing APs with a newer model of APs, use the ap‐swap command to ease the task of updating your site’s AP settings. To use the ap‐swap command, you need the MAC addresses of the new and old APs. You can check MAC addresses of the APs to be replaced with the show ap command.

The ap‐swap command equates the MAC address of an AP that you want to replace with the MAC address of the new AP. By linking the numbers to an AP ID in the replacement table, the system can assign the configured settings from the old AP to the new AP. The settings that are tracked are the channel number, preamble, and power settings. After inputting the swap information, use the show ap‐swap command to double check the AP MAC settings before physically swapping the APs.

Once you have double-checked the MAC addresses, take the old APs off-line by disconnecting them from the system. Replace the APs. When the APs are discovered, the replacement table is checked, and the changes are applied to the new APs. Once the new AP has been updated, the entry is removed from the replacement table.

To summarize the steps to replace the APs:

meru‐wifi (config)# show ap (gets the serial numbers of the APs you are replacing) meru‐wifi (config)# swap ap 00:oc:e6:00:00:66 00:CE:60:00:17:BD meru‐wifi (config)# exit meru‐wifi# show ap‐swap

 AP Serial Number        New AP Serial Number 00:0c:e6:00:00:66       00:ce:60:00:17:bd

AP Replacement Table(1 entry) meru‐wifi# show ap

After you completed the commands for replacing APs, disconnect the old APs and make sure they show Disconnect/off-line status) and then replace the old APs with the new APs

Replacing Access Points

Configuration Updates After AP Replacements

TABLE 25: Configuration Updates After AP Replacement

Supported Modes of Operation for APs

AP332/AP400/AP832 and AP1000 with two radios can have both set to 5.0 GHz, but both radios cannot be set to 2.4 GHz. If you want to use both radios on 2.4 GHz, put the radios on separate channels.

AP1000 radios default to the following bands:

Supported Modes of Operation for APs

Security Modes

Although AP400/AP1000 support all security modes supported by the 802.11i security standard (WEP, WPA, WPA2 and mixed mode), 802.11n supports only clear and WPA2 security. Even though you can configure any security mode for 802.11n, you only gain 11n benefits using WPA2 or clear. Because of this, any 11n client connected to an SSID configured for WEP or WPA will behave like a legacy ABG client. An 802.11n ESSID configured for either

WEP or WPA has no 802.11n rates for that ESSID. If you configure an ESSID for Mixed Mode, 802.11n rates are enabled only for the WPA2 clients; WPA clients behave like a legacy ABG client. See the chart below for details.

Had my surgery….didn’t go to well…

When APs are in a Virtualization

All APs on the same channel in a Virtualization must have the same setting for these values:

• RF-Mode
• Channel Width
• N-only Mode
• Channel and MIMO mode

Configure Gain for External Antennas

The total power that an AP produces must not exceed 30dbi; this number includes any antenna gain. Therefore, if an antenna produces 2dbi, the radio can produce 28dbi. FortiWLC

(SD) automatically sets antenna gain; in the case of an AP400, it assumes an antenna with 5dbi and therefore sets the AP400 to 25dbi. This may or may not be correct for your antenna.

To check and change antenna gain, follow these steps from FortiWLC (SD):

1. Click Configuration > APs (under Devices).
2. Select an AP ID.
3. Click the Antenna Property tab.
4. Select an Interface (1/2).
5. Change the gain if needed.
6. Click OK.

Automatic AP Upgrade

The automatic AP upgrade features is enabled by default. It allows an AP’s firmware to be automatically upgraded by the controller when the AP joins the WLAN. An AP cannot provide service (and consequently be part of the WLAN) if its firmware is at a different level than that of the controller.

When an AP initiates its discovery phase, the controller checks the firmware version and initiates an upgrade if the version is not at the same level as that of the controller. This feature simplifies the process of adding and maintaining a group of APs on an existing WLAN.

When the automatic AP upgrade feature is enabled, you can check the upgrade status of affected APs through syslog messages and SNMP traps that warn of an AP/controller software version mismatch. An alarm is dispatched to an SNMP manager if a mismatch exists. After the firmware is downloaded to the AP, the AP boots, attempts discovery, is checked, and after upgrading, runs the new software version. Once the match is confirmed, another set of syslog messages and SNMP traps are sent notifying that the AP/controller software versions match. Alarms are then cleared.

To disable this feature:

default# auto‐ap‐upgrade disable default# show controller

Global Controller Parameters

Configure Gain for External Antennas

Controller ID                                         : 1

Description                                           : 3dot4dot1 Controller

Host Name                                             : DC9

Uptime                                                : 03d:01h:17m:33s

Location                                              : Qa scale testbed near IT room

Contact                                               : Raju

Operational State                                     : Enabled

Availability Status                                   : Online

Alarm State                                           : No Alarm

Automatic AP Upgrade                                  : off

Virtual IP Address                                    : 192.168.9.3

Virtual Netmask                                       : 255.255.255.0

Default Gateway                                       : 192.168.9.1

DHCP Server                                           : 10.0.0.10

Statistics Polling Period (seconds)/0 disable Polling : 60

Audit Polling Period (seconds)/0 disable Polling      : 60

Software Version                                      : 3.7‐49

Network Device Id                                     : 00:90:0b:07:9f:6a

System Id                                             : 245AA7436A21

Default AP Init Script                                :

DHCP Relay Passthrough                                : on

Controller Model                                      : mc3200

Country Setting                                       : United States Of America

Manufacturing Serial #                                : N/A

Management by wireless stations                       : on

Controller Index                                      : 0

Topology Information Update                           : off Viewing AP Status

From the Web UI, view AP radio status by clicking Monitor > Dashboard > Radio or Monitor > Diagnostics > Radio. Click Help for descriptions of the charts. The icons at the bottom of all screens include a green AP (enabled) and a red AP (disabled); you can also see the same information at Monitor > Dashboard > System.

There are several CLI commands you can use to view AP status:

Automatic AP Upgrade

TABLE 26: Commands to View System Status

Automatic AP Upgrade

Configuring Quality of Service

Quality of Service rules evaluate and prioritize network traffic types. For example, you can prioritize phone calls (VoIP) or prioritize traffic from a certain department (group, VLANs) in a company. This chapter describes QoS settings for Wireless LAN System.

Configuring QoS Rules With the Web UI

To configure QoS rules from the GUI, follow these steps:

1. Click Configuration > QoS Settings > QoS and Firewall Rules (tab).
2. Click Add. The screen below appears.

Figure 69: Add a QoS Rule — change..

3. In the ID field, type a unique numeric identifier for the QoS rule. The valid range is from 0 to 6000.
4. In the Destination IP fields, type the destination IP address to be used as criteria for matching the QoS rule. The destination IP address is used with the destination subnet mask to determine matching.
5. In the Destination Netmask fields, type the subnet mask for the destination IP address.
6. In the Destination Port field, type the TCP or UDP port to be used as criteria for matching the QoS rule. To specify any port, type 0 (zero).
7. In the Source IP fields, type the source IP address to be used as the criteria for matching the QoS rule. The source IP address is used with the source subnet mask to determine matching.
8. In the Source Netmask fields, type the subnet mask for the source IP address.
9. In the Source Port field, type the TCP or UDP port to be used as criteria for matching the QoS rule. To specify any port, type 0 (zero).

10.In the Network Protocol field, type the protocol number of the flow protocol for the QoS rule. The protocol number can be a number 0 through 255. The protocol number of TCP is 6, and the protocol number for UDP is 17. For a list of protocol numbers, see http:// www.iana.org/assignments/protocol-numbers.

If you are also using a QoS protocol detector, you must match the network protocol with the type of QoS protocol. Use the following network protocol and QoS protocol matches:

• UDP: SIP
• TCP: H.323 or SIP

11.In the Firewall Filter ID field, enter the filter-ID to be used (per-user or per-ESS), if Policy Enforcement Module configuration is enabled (optional feature). This ID must be between 1 and 16 alphanumeric characters.

12.In the Packet minimum length field, specify the size of the minimum packet length needed to match the rule. (Valid range: 0-1500.)

13.In the Packet maximum length field, specify the size of the maximum packet length needed to match the rule. (Valid range: 0-1500.)

14.In the QoS Protocol dropdown list, select one of the following:

• SIP
• 323
• Other
• None

For capture rules, the QoS protocol determines which QoS protocol detector automatically derives the resources needed for the flow (implicitly). Select Other if you want to specify the resource requirements for matched flows explicitly. The QoS protocol value is ignored for non-capture rules.

15.In the Average Packet rate box, type the average flow packet rate. The rate can be from 0 through 200 packets/second.

16.In the Action list, select the action the rule specifies: • Forward: A flow is given an explicit resource request, bypassing the QoS protocol detector and regardless of whether a QoS protocol was specified.

• Capture: The system, using a QoS protocol detector, analyzes the flow for its resource requirements.
• Drop: The flow is dropped.

17.In the Token Bucket Rate box, type the rate (in Kbps or Mbps, depending on the option checked) at which tokens are placed into an imaginary token bucket. Each flow has its own bucket, to which tokens are added at a fixed rate. To send a packet, the system must remove the number of tokens equal to the size of the packet from the bucket. If there are not enough tokens, the system waits until enough tokens are in the bucket.

18.In the Priority box, type the priority at which the flow is placed in a best-effort queue. Packets in a higher priority best-effort queue are transmitted by access points before packets in lower-priority queues, but after packets for reserved flows.

Priority can be a value from 0 through 8, with 0 specifying no priority and 8 specifying the highest priority. The default value is 0. If you enable priority (specify a non-zero value), you cannot specify an average packet rate or token bucket rate.

19.In the Traffic Control list, select one of the following:

• On
• Off

For all types of flows (explicit, detected, and best-effort), selecting On for traffic control restricts the flow to the rate you specified. Packets above that rate are dropped.

20.In the DiffServ Codepoint list, select the appropriate DiffServ setting, if applicable.

21.In the QoS Rule Logging list, select whether to enable or disable logging activity for this QoS rule:

• On Off

22.In the QoS Rule Logging Frequency field, change the default collection interval in which packets related to this rule are logged, if QoS Logging is enabled. The interval must be a number between 30 and 60 (seconds).

23.Match Checkbox: For any field with the corresponding Match checkbox selected, the action mentioned in the ACTION field is performed on the matched packets. If the match checkbox is not checked, packets with any value are matched regardless of the data in the field and the action mentioned in the ACTION field is not performed on the packets. Also see “More About the Match Checkbox and Flow Class Checkbox” on page 383.

24.Flow Class Checkbox: Flow Class options are relevant only for Flow Control rules (rules with Traffic Control enabled and Token Bucket Rate specified) and Firewall rules. This is typically rate limiting. When Flow Class is checked for a field, if a packet has matched a rule (either Flow Control or Firewall types), these fields are stored in the Flow Class entry. A Flow Class entry is used by the system for aggregating a set of flows so that they can be subjected to similar behavior, be it dropping the packets, or rate limiting them.

For example, if a rule has a Src IP address of 0.0.0.0 and the Flow Class box checked, and Token Bucket Rate set to 10 kbytes/sec, all packets passing through the system must match this rule, and each flow will be allowed a maximum throughput of 10000 bytes/sec. If the rule were to have Src IP address of 10.0.0.10 and the Flow Class box checked, with a Token Bucket Rate of 10 kbytes/sec, all packets coming from a machine with IP address 10.0.0.10, must match this rule, and the cumulative throughput allowed for this machine shall be no more than 10000bytes/sec. Also see “More About the Match Checkbox and Flow Class Checkbox” on page 383.

25.To add the QoS rule, click OK.

QoS Rules for Bridge Mode Traffic

QoS rules support bridge mode traffic (IPv4). For bridge mode traffic the following conditions are matched to either Forward or Drop packets.

• Destination IP
• Destination Port
• Source IP
• Source Port
• Network Protocol: A QoS rule for bridge mode traffic must mandatorily include the network protocol if the destination or source port is specified.

The following are some points to consider while creating QoS rules for bridge mode traffic: • You can specify ports only for the protocols that support specifying ports. Protocols that do not have port specifications (example, ICMP etc.,) will be ignored by the AP.

• QoS rules with firewall filter-ID are ignored.
• Any rule with match value set to ‘0’ will be considered as a wildcard and will match ANY traffic.
• The QoS rules for bridge mode traffic do not support any other conditions including the Capture action. If application visibility is enabled, and if either QoS rule OR the app-visibility policy dictates a DROP action for a packet, the packet is going to be dropped. Packet is forwarded only if BOTH QoS and app-visibility allow it.

NOTES:

• Any rules that block traffic between controller and AP will cause AP – controller dis-connectivity and such rules should not be created.
• If the number of QoS rules exceed 50, it may affect overall system performance.

More About the Match Checkbox and Flow Class Checkbox

The two checkboxes Match and Flow Class operate independently from each other; they perform two different functions. Match will almost always be used because checking this box indicates that the setting on the left must match – this sets the matching criteria for the QoS rule. You can check more than one matching criteria. Matching is the first phase of QoS rule execution – see the green box in Figure 70.

After criteria are matched, the action phase of the QoS rule is executed. This phase is enclosed in the orange box in Figure 70. Here are the directions that describe what to do with the matched packet from phase 1, Matching. For example, the rule can capture the packet from a named source and drop it. Action is phase 2 of QoS rule execution.

The Flow Class column is all about rate limiting. If a rule involves rate limiting, the actions Traffic Control and Token Bucket Rate must have been turned on. When the QoS rule executes traffic control, it looks at the check marks in the flow class column. If there are no check marks at all, the rate limiting is applied to everything. If Destination, Source, or Network Protocol have Flow Class checked, the following happens:

• Destination Flow Class – Each destination flow is limited to the rate.
• Source Flow Class – All source flows combined must be less than or equal to the rate.
• Network Protocol Flow Class – Any data transported using this protocol is limited to the rate.

Figure 70: How QoS Rules Work — change

Configuring QoS Rules With the CLI

To configure QoS rules with the CLI, you need to be in QoS Rule configuration mode. Enter configure terminal, then specify a QoS rule with the command qosrule <rule-id>. See the chart below for the options for these two commands.

Commands for QoS Rule CLI Configuration

Once you are in QoS rule configuration mode (see directions above), you can issue any of these QoS rule configuration commands:

Configuring QoS Rules With the CLI

Configuring QoS Rules With the CLI

QoS Rule CLI Configuration Example

The following commands configure QoS rule 10 for the set of IP phones whose server is at the IP address 10.8.1.1:

controller (config)# qosrule 10 netprotocol 17 qosprotocol none controller (config‐qosrule)# srcip 10.8.1.1 controller (config‐qosrule)# srcmask 255.255.255.0 controller (config‐qosrule)# srcport 0 controller (config‐qosrule)# dstip 10.8.1.1 controller (config‐qosrule)# dstmask 255.255.255.0 controller (config‐qosrule)# dstport 0 controller (config‐qosrule)# action forward controller (config‐qosrule)# tokenbucketrate 9400 controller (config‐qosrule)# avgpacketrate 35 controller (config‐qosrule)# end

When SCCP phones are used, we recommend that you create a separate VLAN for the SCCP phones and create the following qosrules for G.711 (20ms) codec to handle qosflow traffic:

controller (config)# qosrule 123 netprotocol 17 qosprotocol none controller (config‐qosrule)# srcmask subnet_mask (for example, 255.255.192.0) controller (config‐qosrule)# srcip subnet_IP_addr (for example,172.27.128.0) controller (config‐qosrule)# action forward controller (config‐qosrule)# avgpacketrate 50 controller (config‐qosrule)# tokenbucketrate 10000  controller (config‐qosrule)# exit

controller (config)# qosrule 124 netprotocol 17 qosprotocol none

controller (config‐qosrule)# dstip subnet_IP_addr  (for example,172.27.128.0) controller (config‐qosrule)# dstmask subnet_mask (for example, 255.255.192.0) controller (config‐qosrule)# action forward controller (config‐qosrule)# avgpacketrate 50 controller (config‐qosrule)# tokenbucketrate 10000 controller (config‐qosrule)# exit

The following example configures a QoS rule for a 1 Mbps CBR-encoded video streamed from Windows Media Server 9 over UDP transport.

The following lists the example’s configuration parameters:

• Rule ID: 11
• Network protocol: 17 (UDP)
• QoS protocol: None
• Source IP address: 0.0.0.0
• Source subnet mask: 0.0.0.0
• Source port: 0

Configuring QoS Rules With the CLI

• Destination IP address:10.10.43.100 (This is the IP address of the wireless station receiving the video stream.)
• Destination subnet mask: 255.255.255.255
• Destination port: 5004
• Action to take if packets match rule: Forward
• Drop policy: Head
• Token bucket rate: 128 kbytes/second
• Average packet rate: 10 packets/second

The following commands configure the QoS rule for the video streamed from Windows Media Server 9 over UDP transport:

controller (config)# qosrule 11 netprotocol 17 qosprotocol none controller (config‐qosrule)# srcip 0.0.0.0 controller (config‐qosrule)# srcmask 0.0.0.0 controller (config‐qosrule)# srcport 0 controller (config‐qosrule)# dstip 10.10.43.100 controller (config‐qosrule)# dstmask 255.255.255.255 controller (config‐qosrule)# dstport 0 controller (config‐qosrule)# action forward controller (config‐qosrule)# tokenbucketrate 128000 controller (config‐qosrule)# avgpacketrate 10 controller (config‐qosrule)# end

Optimizing Voice Over IP

Transmitting voice over IP (VoIP) connections is, in most senses, like any other network application. Packets are transmitted and received from one IP address to another. The voice data is encoded into binary data at one end and decoded at the other end. In some sense, voice is just another form of data. However, there are a few special problems.

The requirements for quality voice traffic are not exactly the same as the requirements for most data traffic:

• If a data packet arrives a second late, it is usually of no consequence. The data can be buffered until the late packet is received. If a voice packet arrives a second late, it is useless and might as well be thrown away.
• If a data packet takes a third of second to arrive at the destination, that is usually fast enough. If voice packets routinely take a third of a second to arrive, the users will begin to take long pauses between sentences to make sure that they don’t interfere with the other person’s speech.

Optimizing Voice Over IP

Quality VoIP calls need data to be delivered consistently and quickly. Meeting the requirements of VoIP data requires either a connection with plenty of bandwidth all along the data route or a means of ensuring a certain quality of service (QoS) for the duration of the call.

Even if the bandwidth is available, setting up the phone call can be a non-trivial task. When a phone call is initiated, the destination of the call might be a standard telephone on the public switched network (PSTN) or an IP-to- device at a particular IP number, or one of several computers (for example, a computer at home or office). If the destination device is a phone on the public network, the initiation protocol must locate a gateway between the Internet and the telephone network. If the destination device is in the local network, the initiation protocol must determine which computer or device to call.

After the destination device has been found, the initiating and the destination devices must negotiate the means of coding and decoding the data. This process of finding a destination device and establishing the means of communication is called session initiation.

The two main standards for initiating sessions are:

• Session Initiation Protocol, or SIP, used for most VoIP telephone calls.
• 323, used for multimedia communication, for example by Microsoft NetMeeting.

In both cases, the initiating device queries a server, which then finds the destination device and establishes the communications method.

After the two devices have been matched and the communication standards chosen, the call is established. The VoIP server may remain in the communication loop or it may step out of the loop depending on the server configuration.

Using QoS Rules for VoIP

The Wireless LAN System is designed to automatically provision voice traffic with a level of QoS appropriate for voice calls. Incoming traffic are matched against the pre-defined QoS rules and depending on the match, the traffic is assigned with appropriate prioritization.

The port numbers monitored for incoming traffic are:

• 5060 for SIP service (UDP or TCP)
• 1720 for H.323 service (TCP)
• 5200 for Vocera (UDP)

If your VoIP devices and servers are configured to use different ports, modify the QoS rules on the controller to match the ports your system uses. Change QoS rules with either the Web UI or the CLI.

Optimizing Voice Over IP

Modifying QoS Rules for Nonstandard Ports

The controller is pre-configured to detect the bandwidth requirements for a SIP or H.323 call and make a bandwidth reservation. Change QoS rules with either the Web UI or the CLI. The following default QoS rules are configured at the factory:

default(15)# show qosrule

ID    Dst IP          Dst Mask        DPort Src IP          Src Mask        SPort Prot Firewall Filter Qos   Action

• 0.0.0 0.0.0.0         1720  0.0.0.0         0.0.0.0         0     6                    h323  capture
• 0.0.0 0.0.0.0         0     0.0.0.0         0.0.0.0         1720  6                    h323  capture
• 0.0.0 0.0.0.0         5060  0.0.0.0         0.0.0.0         0    

17                   sip   capture

• 0.0.0 0.0.0.0         5060  0.0.0.0         0.0.0.0         0    
• sip capture
• 0.0.0 0.0.0.0         5200  0.0.0.0         0.0.0.0         0     17                   other forward
• 0.0.0 0.0.0.0         0     0.0.0.0         0.0.0.0         5200  17                   other forward
• 0.0.0 0.0.0.0         80    0.0.0.0         0.0.0.0         0     17                   other capture
• 0.0.0 0.0.0.0         0     0.0.0.0         0.0.0.0         5060  6                    other capture

        QoS and Firewall Rules(8 entries)

The first two pre-configured QoS rules give priority to H.323 traffic sent to and from TCP port 1720 respectively. The next two QoS rules give priority to SIP traffic sent to and from UDP/ TCP port 5060 respectively. Rules 7 and 8 are for Vocera badges and use port 5200 with UDP.

You normally do not need to configure QoS rules in the controller, unless you have special requirements in your configuration. For example:

• You want to drop packets coming from certain ports or IP addresses.
• You want to configure the controller to give priority to traffic other than H.323 and SIP traffic.

You can configure rules to provide priority-based or reserved QoS. QoS is applied with reserved traffic being allocated the first portion of total bandwidth, followed by fixed priority levels, and finally by the best-effort (default) traffic class. You can configure reserved QoS for new applications using the average packet rate and token bucket rate parameters together as the traffic specification (also called TSpec in IETF IntServ RFCs).

Optimizing Voice Over IP

Global QoS Settings

Global QoS parameters configure settings that determine call quality on a global level. These settings allow you to fine tune Call Admission Control (CAC), client load balancing, bandwidth scaling, and time-to-live settings.

You can configure the following global quality-of-service parameters:

TABLE 27: Global Quality-of-Service Parameters

Global QoS Settings

TABLE 27: Global Quality-of-Service Parameters

Rate Limiting QoS Rules

Rate limiting controls the overall traffic throughput sent or received on a network interface. A specific bandwidth limit can be set for a network or device; then, if the actual traffic violates that policy at any time, the traffic is shaped in some way. In this implementation, packets are dropped until the traffic flow conforms to the policy with some queuing (delaying packets in transit) applied.

Rate Limiting with the CLI

You can rate limit traffic by turning on Traffic Control and using the Token Bucket Rate as the token bucket limiter. Follow these steps to rate limit the client 10.11.31.115 to approximately 3Mbps and then run a quick test to verify functionality.

1. Determine the token bucket rate to achieve the desired rate limit. In the example below, we’ll limit it to 3Mbps (3Mbps = 3000000bps. 3000000/8/8=46875).
2. Create a qosrule that does rate limiting for a client.

Controller1# sh qosrule 23

QoS and Firewall Rules

ID : 23

Id Class flow class : on

Destination IP : 10.11.31.115 (this is the client to be rate limited)

Destination IP match : on

Destination IP flow class : on

Destination Netmask : 255.255.255.255

Destination Port : 0

Destination Port match : none

Destination Port flow class : none

Source IP : 0.0.0.0

Source IP match : none

Source IP flow class : none

Source Netmask : 0.0.0.0

Rate Limiting QoS Rules

Source Port : 0

Source Port match : none

Source Port flow class : none

Network Protocol : 6

Network Protocol match : on Network Protocol flow class : on

Firewall Filter ID :

Filter Id match : none

Filter Id Flow Class : none

Packet minimum length : 0

Packet Length match : none

Packet Length flow class : none

Packet maximum length : 0

QoS Protocol : other

Average Packet Rate : 0

Action : forward

Drop Policy : head

Token Bucket Rate : 46875

Priority : 0

Traffic Control : on

DiffServ Codepoint : disabled

Qos Rule Logging : on

Qos Rule Logging Frequency : 31

Rate Limiting QoS Rules with the GUI

You can rate limit traffic for a single user by turning on Traffic Control and using the Token Bucket Rate as the token bucket limiter. Follow these steps to rate limit the traffic:

1. Click Configure > QoS Settings > QoS and Firewall rules tab > Add. The QoS and Firewall rules Add window displays.
2. Scroll down to the lower half of the QoS and Firewall rules Add window.
3. Set Traffic Control On.
4. Set the token bucket rate to achieve the desired rate limit. This can be entered in either Kbps (from 0-1000) or Mbps (from 0-64), depending on the needs of your deployment.
5. Click OK.

The rate limit is now set.

Rate Limiting Examples

Rate-Limit Clients in the Same Subnet for TCP

To rate-limit clients from the subnet 10.11.31.0, follow these steps:

1. Determine the token bucket rate to achieve the desired rate limit. In the example below, we’ll limit it to 3Mbps (3Mbps = 3000000bps. 3000000/8/8=46875).

Rate Limiting QoS Rules

2. Create the following qosrule to rate-limit clients from a particular subnet:

Controller1# sh qosrule 23

QoS and Firewall Rules

ID: 23

ID Class flow class : on

Destination : 10.11.31.0 (this is the subnet to be rate limited)

Destination IP match : on

Destination IP flow class : on

Destination Netmask : 255.255.255.0

Destination  Port  : 0

Destination  Port  match : none

Destination  Port  flow class : none

Source IP : 0.0.0.0

Source Netmask : 0.0.0.0

Source  Port  : 0

Source  Port  match : none

Source  Port  flow class : none

Network Protocol : 6

Network Protocol match : on Network Protocol flow class : on

Firewall Filter ID :

Filter Id match : none

Filter Id Flow Class : none

Packet minimum length : 0

Packet Length match : none

Packet Length flow class : none

Packet maximum length : 0

QoS Protocol : other

Average Packet Rate : 0

Action : forward

Drop Policy : head

Token Bucket Rate : 46875

Priority : 0

Traffic Control : on

DiffServ Codepoint : disabled

Qos Rule Logging : on

Qos Rule Logging Frequency : 60

3. Configure Chariot to send a TCP downstream to the client 10.11.31.115 using the throughput script. You should see throughput averaging around3Mbps on Chariot.

As a result of this QoS rule, each client in the 10.11.31.xxx network will get approximately get 3 mbps from each individual source in the same subnet.

Rate-Limit Clients From Different Subnets for TCP

To rate-limit clients from any subnet other than the one that those clients are currently using, follow these steps:

Rate Limiting QoS Rules

1. Determine the token bucket rate to achieve the desired rate limit. In the example below, we’ll limit it to 3Mbps (3Mbps = 3000000bps. 3000000/8/8=46875).
2. Create the following qosrule to rate-limit clients from a particular subnet:

Controller1# sh qosrule 23

QoS and Firewall Rules

ID : 23

Id Class flow class : on

Destination IP : 10.11.31.0 (this is the subnet to be rate limited)

Destination IP match : on

Destination IP flow class : none

Destination Netmask : 255.255.255.0

Destination  Port  : 0

Destination  Port  match : none

Destination  Port  flow class : none

Source IP : 0.0.0.0

Source Netmask : 0.0.0.0

Source  Port  : 0

Source  Port  match : none

Source  Port  flow class : none

Network Protocol : 6

Network Protocol match : on Network Protocol flow class : on

Firewall Filter ID :

Filter Id match : none

Filter Id Flow Class : none

Packet minimum length : 0

Packet Length match : none

Packet Length flow class : none

Packet maximum length : 0

QoS Protocol : other

Average Packet Rate : 0

Action : forward

Drop Policy : head

Token Bucket Rate : 46875

Priority : 0

Traffic Control : on

DiffServ Codepoint : disabled

Qos Rule Logging : on

Qos Rule Logging Frequency : 60 

3. Configure Chariot to send a TCP downstream to the different clients in 10.11.31.xxx using the throughput script.

All the clients in 10.11.31.xxx network should now share the 3 Mbps from each individual source.

Rate Limiting QoS Rules

Configuring Codec Rules

Codec rules are configurable and can be specified with the commands in this section.

If your SIP phones support “ptime” then you will not need to configure any codec rules. Otherwise, you should configure QoS rules and ensure the rule you set is based on the packetization/sample rate that the phone uses.

The SIP ptime attribute is an optional part of the SIP Specification. It allows a SIP media device to advertise, in milliseconds, the packetization rate of the RTP media stream. For example, if ptime is set to the value “20” the SIP device sends 1 RTP packet to the other party every 20 milliseconds. With this specification, the Wireless LAN System can accurately reserve QoS bandwidth based on the Codec and Packetization rate.

The following is a sample of the “ptime” attribute included as part of an SDP media attribute:

m=audio 62986 RTP/AVP 0  a=rtpmap:0 PCMU/8000 a=ptime:20

If the ptime attribute is not present when the media is negotiated in SDP between the SIP devices, the Wireless LAN System uses the default value of the codec type specified with the qoscodec command.

The proper packetization rate must be configured to match the actual media traffic or the QoS reservation will be inaccurate. A spreadsheet, qoscodec_parameters.xls, is available from the Customer Support FTP site that can help you to determine the correct values for the relevant parameters. Please contact Customer Support for details and access.

To configure QoS Codec rules, you need to enter Codec configuration mode. To do this, follow these steps:

Configuring Codec Rules

The Codec type can be one of the following

TABLE 28: QoS Codec Type

Configuring Codec Rules

TABLE 28: QoS Codec Type

The following commands are used in the QoS Codec configuration mode:

TABLE 29: QoS CODEC Configuration Mode Commands

Configuring Codec Rules