More QoS Rule Examples

The following are in addition to the previous examples in this chapter, “QoS Rule CLI Configuration Example” on page 387 and “Rate Limiting Examples” on page 393:

• “Rate-Limit a Certain Client” on page 400
• “Wireless Peer-to-Peer Qos Rules” on page 401

Rate-Limit a Certain Client

To rate-limit the client 10.11.31.115 from any source, 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).
2. Create the following qosrule to rate-limit a particular client from any source:

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 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 around 3Mbps on Chariot. As a result of this QoS rule, when the client 10.11.31.115 receives traffic, it will be rate-limited to approximately 3mbps.

Wireless Peer-to-Peer Qos Rules

In general, to create a priority QoS rule for a particular protocol between two IP addresses, specify the network protocol and then select the match flow for the protocol. This creates QoS priority for a particular protocol between the IP’s.

Prioritize Peer-to-Peer

This particular IP-Based QoS rule prioritizes peer-to-peer traffic generated from 172.18.85.11 and destined to 172.18.85.12.

Testing# show qosrule 11

QoS and Firewall Rules

ID : 11

Id Class flow class : on

Destination IP : 172.18.85.12

Destination IP match : on

Destination IP flow class : none

Destination Netmask : 255.255.255.255

Destination Port : 0

Destination Port match : none

Destination Port flow class : none

Source IP : 172.18.85.11

Source Netmask : 255.255.255.255

Source IP match    : on

Source IP flow class : none

Source Port : 0

Source Port match : none

Source Port flow class : none Network Protocol : 0

Network Protocol match : none Network Protocol flow class : none 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 : none

Average Packet Rate : 100

Action : forward

Drop Policy : head

Token Bucket Rate : 1000000

Priority : 0

Traffic Control : off

DiffServ Codepoint : disabled

Qos Rule Logging : on

Qos Rule Logging Frequency : 31

Peer-to-Peer Blocking

In this peer-to-peer blocking example, rules 60 and 61 apply to an isolated WLAN for guest internet access where the DNS server is actually on that network. Rules 60 and 61 are only needed if the DNS server for the wireless clients is on the same subnet as the clients themselves.

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

• 0.0.0 0.0.0.0         53    0.0.0.0         0.0.0.0         0     0                    none  forward  tail
• 0.0.0 0.0.0.0         0     0.0.0.0         0.0.0.0         53   

0                    none  forward  tail

100   192.168.2.0     255.255.255.0   0     192.168.2.0     255.255.255.0   0     0                    none  drop     tail

qosrule  60 netprotocol  0 qosprotocol  none firewall‐filter‐id  “” id‐flow  on dstip  0.0.0.0 dstmask  0.0.0.0 dstport  53 dstport‐match on dstport‐flow on srcip  0.0.0.0 srcmask  0.0.0.0 srcport  0 action  forward droppolicy  tail priority  0 avgpacketrate  0 tokenbucketrate  0

dscp  disabled qosrulelogging  off qosrule‐logging‐frequency  60 packet‐min‐length  0 packet‐max‐length  0 no  trafficcontrol exit qosrule  61 netprotocol  0 qosprotocol  none firewall‐filter‐id  “” id‐flow  on dstip  0.0.0.0 dstmask  0.0.0.0 dstport  0 srcip  0.0.0.0 srcmask  0.0.0.0 srcport  53 srcport‐match on srcport‐flow on action  forward droppolicy  tail priority  0 avgpacketrate  0 tokenbucketrate  0 dscp  disabled qosrulelogging  off qosrule‐logging‐frequency  60 packet‐min‐length  0 packet‐max‐length  0 no  trafficcontrol exit qosrule  100 netprotocol  0 qosprotocol  none firewall‐filter‐id  “” id‐flow  on dstip  192.168.2.0 dstip‐match on dstip‐flow on dstmask  255.255.255.0 dstport  0 srcip  192.168.2.0 srcip‐match on srcip‐flow on srcmask  255.255.255.0 srcport  0 action  drop droppolicy  tail priority  0 avgpacketrate  0 tokenbucketrate  0 dscp  disabled

qosrulelogging  off qosrule‐logging‐frequency  60 packet‐min‐length  0 packet‐max‐length  0 no  trafficcontrol

802.11n Video Service Module (ViSM)

Video streaming has the low latency and loss requirements of  with the high-throughput requirements of data. The Fortinet Video Service Module™ (ViSM) is an optional licensed software module that delivers predictable 802.11 video performance with minimal delay, latency and jitter. Sustainable high data rates, even in mixed traffic, are supported along with synchronization of video and audio transmissions.

ViSM also introduces additional mechanisms for optimizing unicast and multicast video such as application aware scheduling, /video synchronization, and client-specific multicast group management. Features include the following:

• High throughput with low burstiness offers predictable performance and consistent user experience
• Application-aware prioritization synchronizes the and video components of a video stream, adapting the delivery of each frame based on its importance to the application.
• Multicast group management optimizes delivery to only those Virtual Ports whose clients are members of the multicast group.
• Seamless video-optimized handoff proactively reroutes the multicast delivery tree to prevent lost video frames during a transition between access points and ensures zero loss for mobile video.
• User and role based policy enforcement provides granular control over application behavior.
• Visualization reveals which clients are running which applications.

Implementing ViSM

Virtual Port already changes multicast to unicast transmissions (for non-U-APSD clients). ViSM adds per-client IGMP Snooping to the transmission. Therefore, to implement ViSM, turn on IGMP Snooping. CLI commands control IGMP snooping (see FortiWLC (SD) Command Reference). At this time, ViSM licensing is not enforced. ViSM is not recommended for AP1000 access points.

Configuring Call Admission Control and Load Balancing with the CLI

To help shape a global Quality of Service for calls and traffic, Call Admission Control (CAC) and client load balancing can be set per AP or BSSID.

CAC commands can set threshold levels for the number of new SIP connections (calls) that can exist per AP or BSSID to ensure a global amount of bandwidth is available. The result is that existing calls maintain a consistent level of service, even if new calls have to be temporarily denied. When CAC is enabled, as the set call level threshold is neared for the AP or BSSID, the admin can configure actions to occur such as having the system send a 486_BusyHere response, a modified INVITE message to the ipPathfinder, or alternatively, sending a 802.11 De-authentication message the originator of the call. If an existing call moves to another AP without sufficient bandwidth, the call is classified as Pending/Best-effort until the needed resources are available.

A unique CAC value can be configured for an ESSID, that affects only only that ESSID. Setting CAC at the ESSID level takes precedence over the global settings described in this section. To configure CAC for an ESSID, see “Configuring CAC for an ESSID AP with the CLI” on page 147.

Enabling client load balancing implements round-robin load balancing of client associations for an AP or BSSID. When the maximum number of stations are associated, new stations are allowed to join in a round-robin fashion.

The following commands enable CAC and limits the number of calls per AP to 12:

controller (config)# qosvars cac-deauth on controller (config)# qosvars calls-per-ap 12

The following commands enable client load balancing overflow protection and sets the maximum number of stations per AP to 15:

controller (config)# qosvars load-balance-overflow on controller (config)# qosvars max-stations-per-radio 15

The following commands limits the number of calls per BSSID to 14 and sets the maximum number of stations per BSSID to 30:

controller (config)# qosvars calls-per-bssid 14 controller (config)# qosvars max-stations-per-bssid 30

 

QoS Statistics Display Commands

Displaying Phone/Call Status

To display the active SIP phones that have registered with a SIP server, use the show phones command.

Controller(15)# show phones

MAC                 IP               AP ID AP Name         Type Username            Server           Transport  

00:01:3e:12:24:b5   172.18.122.21    3     QoS‐Lab         sip  100

172.18.122.122   udp 

        Phone Table(1 entry)

Controller(15)#

To display the active SIP phone calls, use the show phone‐calls command. controller# sh phone‐calls

From MAC            From IP          From AP From AP Name    From Username       From Flow Pending   To MAC              To IP            To AP   To AP Name      To Username         To Flow   Pending   Type State  

00:0f:86:12:1d:7c   10.0.220.119     1       AP‐1            5381                100       off       00:00:00:00:00:00   10.0.220.241     0                      

69                  101       off       sip  connected    

        Phone Call Table(1 entry) controller#

Displaying Call Admission Details

To view the current calls supported by APs, use the show statistics call-admission-control ap command.

controller# show statistics call‐admission‐control ap

AP ID Current Calls Cumulative Rejected Calls

6     0             0                         Call Admission Control AP Statistics(1 entry)

To show calls in relation to specific BSSIDs, use the show statistics call-admission control bss command.

controller# show statistics call‐admission‐control bss

BSSID             Current Calls Cumulative Rejected Calls

00:0c:e6:13:00:da 0             0                  

00:0c:e6:52:b3:4b 0             0                   

00:0c:e6:f7:42:60 0             0                        

QoS Statistics Display Commands

 

        Call Admission Control BSS Statistics(3 entries)

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

Command	Purpose
configure terminal	Enter global configuration mode.
qoscodec rule-id codec <codec-type>  qosprotocol {H323v1|sip} tokenbucketrate tbr maxdatagramsize maxdg minpolicedunit minpol samplerate sr	Enter QoS Codec configuration for the specified rule ID. Use show qoscodec to obtain a list of rule IDs. The following are the required parameters: codec. Enter the Codec type after at the Codec keyword. The acceptable Codec types are given below. qosprotocol. The QoS protocol. This can be one of the following: H323 (H.323); sip (SIP – Session Initiation Protocol) tokenbucketrate. Token bucket rate, from 0 to 1000 Kbps or 164 Mbps, depending on the box checked. maxdatagramsize. Maximum datagram size. From 0 to 1,500 bytes. minpolicedunit. Minimum policed unit. From 0 to 1,500 bytes. samplerate. Sample rate. From 0 to 200 packets per second.
… commands …	Enter the QoS CODEC configuration commands here.
end	Return to privileged EXEC mode.
copy running-config startup-config	This is an optional step to save your entries in the configuration file.

The Codec type can be one of the following

TABLE 28: QoS Codec Type

Type	Description
1016	1016 Audio: Payload Type 1, Bit Rate 16 Kbps
default	Contains the default TSpec/ RSpec for unknown codecs or codecs for which there is no entry in the codec translation table
dv14	DV14 Audio: Payload Type 5, Bit Rate 32 Kbps
dv14.2	DV14.2 Audio: Payload Type 6, Bit Rate 64Kbps
g711a	G711 Audio: Payload Type 8, G.711, A-law, Bit Rate 64 Kbps

Configuring Codec Rules

TABLE 28: QoS Codec Type

Type	Description
g711u	G711 Audio: Payload Type 0, G.711, U-law, Bit Rate 64 Kbps
g721	G721 Audio: Payload Type 2, Bit Rate 32 Kbps
g722	Audio: Payload Type 9, Bit Rate 64 Kbps, 7KHz
g7221	G7221 Audio: Payload Type *, Bit-Rate 24 Kbps, 16KHz
g7221-32	G7221 Audio: Payload Type *, Bit-Rate 32 Kbps, 16KHz
g723.1	G7231 Audio: Payload Type 4, G.723.1, Bit Rate 6.3Kbps
g728	G728 Audio: Payload Type 15, Bit Rate 16Kbps
g729	G729 Audio: Payload Type 16, Bit Rate 8Kbps
g7red	Proprietary MSN Codec Audio: Payload Type *
gsm	GSM Audio: Payload Type 3, Bit Rate 13Kbps
h261	H.261 Video
h263	H.263 Video
lpc	IPC Audio: Payload Type 7, Bit Rate 2.4 Kbps
mpa	MPA Audio: Payload Type 14, Bit Rate 32 Kbps
siren	Proprietary MSN Audio: Payload Type *, Bit Rate 16Kbps, 16KHz

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

TABLE 29: QoS CODEC Configuration Mode Commands

Command	Purpose
tokenbucketsize size	Token bucket size in bytes. From 0 to 16,000 bytes. Defaults to 8.
peakrate rate	Traffic spec peak rate. From 0 to 1,000,000 bytes/second. Defaults to 0.
rspecrate rate	Reservation spec rate. From 0 to 1,000,000 bytes/second. Defaults to 0.
rspecslack slack	Reservation spec slack. From 0 to 1,000,000 microseconds. Defaults to 0.

Configuring Codec Rules

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

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

Command	Purpose
qosvars admission { admitall | pending | reject }	Admission control. Valid values are admitall, pending, and reject.
qosvars ttl ttl-value	Default time-to-live in seconds for all other protocols besides TCP and UDP.
qosvars tcpttl ttl-value	Time-to-live for TCP protocol, in seconds.
qosvars udpttl ttl-value	Time-to-live for UDP protocol, in seconds.
qosvars bwscaling value	Scale factor for Tspec bandwidth, in percent. May range from 1% to as high as 100% ; 100% is typical
qosvars cac-deauth {on | off}	Configures the optional 802.11 de-authentication behavior.
qosvars calls-per-ap max	Configures the maximum number of calls per AP.
qosvars calls-per-bssid max	Configures the maximum number of calls per BSSID.
qosvars drop-policy {head|tail}	Configures the drop policy. Valid values are head or tail respectively.
qosvars load-balance overflow {on | off}	Enables and disables load balancing across BSSIDs.
qosvars max-stations-per-radio max	Configures the maximum stations (0-128) allowed to associate with a single radio. 128 is the default. Recommendation: •  14 voice clients per radio for all AP models •  40 data clients per radio for all AP models except AP122, and 20 data clients for AP122
qosvars max-stations-per-bssid max	Configures the maximum stations (0-1023) allowed to associate with an BSSID.

Global QoS Settings

TABLE 27: Global Quality-of-Service Parameters

Command	Purpose
qosvars no enable	Turns off QoS.
SIP Idle Timeout	Sets the time period after which an idle SIP connection will time out.
Station Assignment Aging Time (s)	Sets the time period after which stations will begin aging out.
Maximum Calls Per Interference Region	Specifies the number of calls that are permitted in a given interference area.

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.

Command	Purpose
configure terminal	Enter global configuration mode.
qosrule rule-id netprotocol {6|17|protocolnumber} qosprotocol {H323|sip|none|other|sccp}	Enter QoS Rule configuration for the specified rule ID. Use show qosrules to obtain a list of rule IDs. The required parameters are: netprotocol: The network protocol is a standard network protocol number such as 6 for TCP or 17 for UDP. It can be any valid protocol number such as 119 for the SVP protocol, used with Spectralink phones. [Full listing at: http://www.iana.org/ assignments/ protocol-numbers] qosprotocol: The QoS protocol. This can be one of the following: H.323 sip (SIP – Session Initiation Protocol) none (Used to denote all other protocols)
… commands …	Enter the QoS rule configuration commands here (see the following table).
end	Return to privileged EXEC mode.
copy running-config startup-config	This is an optional step to save your entries in the configuration file.

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

Command	Purpose
dstip ip	Destination IP in the format 255.255.255.255.
dstmask ipmask	Destination netmask in the format 255.255.255.255
dstport port	Destination port number from 0 to 65535.
srcip ip	Source IP in the format 255.255.255.255.
srcmask ipmask	Source netmask in the format 255.255.255.255.
srcport port	Source port number from 0 to 65535.
action {forward | capture | drop}	Action to take for packets matching the rule. This can be one of the following: 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 flow is passed through the QoS protocol detector, using the specified QoS protocol. This is the recommended action for static QoS rules that are H.323/SIP based. drop—The flow is dropped.
dscp class	The DiffServ codepoint class. This lets you choose a per-hop forwarding behavior for the packets in the flow. It is recommended that you be familiar with RFCs 2475 and 2597 before changing these values.
priority rate	The number (0-8) that specifies best effort priority queue, where 0 is default (best-effort) and 8 is highest priority. Priority may be turned on (non-zero) or the average packet rate and TSpec token bucket rate may be specified, but not both. Defaults to 0.
avgpacketrate rate	Average packet rate: from 0 to 200 packets per second. If this is a nonzero value, then the TSpec token bucket rate must also be a non-zero value, and priority cannot be set to a non-zero value. Defaults to 0.
tokenbucketrate rate	TSpec token bucket rate, from 0 to 1000 Kbps or 1-64 Mbps, depending on the box checked. If this is a non-zero value, then the average packet rate must also be non-zero, and the priority cannot be set to a non-zero value. Defaults to 0.
trafficcontrol-enable	Turns traffic control policing on. When traffic control is on, traffic assigned a priority will travel at the assigned rate and no faster.
no trafficcontrol	Turns traffic control policing off. This is the default setting.

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