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:
- 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).
- 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
- 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