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

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

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

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

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

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.

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