FortiWLC – More QoS Rule Examples

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

  1. 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

 

This entry was posted in Administration Guides, FortiWLC on by .

About Mike

Michael Pruett, CISSP has a wide range of cyber-security and network engineering expertise. The plethora of vendors that resell hardware but have zero engineering knowledge resulting in the wrong hardware or configuration being deployed is a major pet peeve of Michael's. This site was started in an effort to spread information while providing the option of quality consulting services at a much lower price than Fortinet Professional Services. Owns PacketLlama.Com (Fortinet Hardware Sales) and Office Of The CISO, LLC (Cybersecurity consulting firm).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.