Application Visibility (DPI)

You can monitor and/or block specific application traffic in your network. FortiWLC (SD) can monitor and restrict access applications/services, as listed in the Configuration > Access Control > Application

Limitations and Recommendations

• To export DPI status to an FortiWLM server, the export destination port must be set to 4739.
• If the total number of ESS profiles and the total number APs in the controller are the maximum allowed, then a policy cannot be created. When configuring each policy:
• The total number of ESS that can be applied to is 64. Tip: To support this maximum, ensure that an ESS name is 15 characters or less.
• The total number APs that can be applied are 186. To support this maximum, the AP IDs need to between the 1 to 500 AP ID range. Tip: to maximize the coverage of APs, you can create AP groups and use this instead of listing individual APs.
• Bittorent downloads can be monitored but cannot be blocked.
• In a custom app, Bittorent traffic cannot be monitored or blocked.
• Advanced detection of sub-protocol traffic is a resource intensive task, so we recommend that you use it in moderation.
• It is recommended that you do not delete custom application (under the Settings > Custom Application tab in Application). Deleting a custom application can result in incorrect status display of top 10 applications in the dashboard.
• A custom application is by default monitored even if it is not mapped to a policy. But for it to be blocked, it must be added to a policy
• Setting up application monitoring or blocking requires you to enable DPI and creating appropriate policies.

To set up and use the application monitoring:

1. Enable Application Visibility
2. Create Policies
3. Associate system defined and/or custom applications to policies

Enable Application Visibility

To enable DPI, go to Configuration > Applications > Settings tab

1. Select ON for Enable Application Classification. This is a global settings and enables DPI on all APs.
2. Export Interval is a non-configurable field that set at 90 seconds.
3. Export Destination: Specify or edit (if automatically pushed by Network Manager) the IP address of the correct Network Manager server. This is used to export stats to Network Manager server
4. To export values to Fortinet Network Manager, select Enable Netflow Export and specify the Fortinet Network Manger server IP (Export Destination).

Creating a Policy

You can create policies to monitor and block one or more application traffic. This can be done for one of the following condition:

• All ESS profiles
• Per ESS profile
• All APs
• Per AP
• Per AP Group
• ESS and AP Combination

Example

The following screen-shots illustrate the procedure to create a policy to block Yelp traffic by clients that are connected to sdpi-832-t ESS profile via AP-3.

3. Click the ADD button to view application lists
4. Select the application from the list and click ADD button
5. Select Block from the dropdown list and click SAVE button

List of policies

• Policy: The status of the policy
• Advanced Detection: Select enable to view sub-protocols for a system defined application and protocols.
• Application ID List: List of system defined application and /or custom applications that are blocked or monitored by the policy. Blocked applications are shown in red colour and applications that are only monitored are shown in green colour.
• ESSID List: The name of the ESS profile configured for this policy. Clients that connect using this ESSID profile and accessing the monitored application.
• AP Groups or APs: The list of APs that are configured for this policy. Clients that connected via these APs or AP groups and accessing the monitored application.
• Owner: The owner is either controller or NMS. If the policy is created in the controller the owner is listed as controller.
• Search: To locate a specific policy by Name, AP, ESS, or owner, enter the keyword in the search box and hit the Enter key. This will highlight the corresponding row that matches the keyword. To filter the display based on Status, select the status (from the dropdown) to highlight the corresponding rows.
• Policy Reordering: Policies are executed in the order they are displayed. To reorder policy priority, click the Reorder button and use the arrows in the action column to move them up or down the listing order. You must save this for the reorder changes to take effect.

In the following illustration, the ESSID MTS and APID AP-8 appear in both corporate-1 and corporate-2 policies. The corporate-1 policy allows Facebook traffic and corporate-2 blocks Facebook traffic. Since corporate-1 is higher in the order than corporate-2, Facebook will be allowed and not blocked. However, for AP-10 Facebook will be blocked as per corporate-2 policy.

Custom Applications

Custom applications are user-defined applications that are not part of the system defined applications. You can add a maximum of 32 applications in the controller and a maximum of 32 applications on Network Manager.

A custom application is a combination of one or more of the following:

• Predefined L4 and L7 protocols
• Source and/or Destination Ports
• User Agents
• Any HTTP/HTTPS URL
• Destination IP

Creating a Custom Application and assigning it to a Policy

1. To create a custom application, go to Application > Settings > Custom Applications and click the Add
2. Enter properties for the custom application and click Save. In this simple example, traffic from www.bbc.com will be monitored.
3. Add custom application to a policy. Use the same steps mentioned in See “Example” on page 408. But in the sub-step 4 of the figure, scroll down to very end to location the custom application. Select the custom application and then select policy setting.

DPI Dashboard

The DPI dashboard shows applications that are configured for monitoring (detect) only. Applications that are blocked are not displayed in the dashboard as they are dropped by the AP.

1. The graph displays a pie chart with the top 10 applications (by usage) that are monitored.
2. The list of top 10 stations that are connected to one or more of the top 10 applications. This does not represent the usage of a specific application by the station.
3. List of APs that are passing traffic for one or more of the top 10 applications
4. List of ESS profiles that are passing traffic for one or more of the top 10 applications
5. This table lists the top 10 application and displays numerical (integer) statistics about number of stations, ESS profiles, APs and traffic size in bytes.
6. This table shows historical data for application traffic in the last 24 hours.

Using CLI

Creating a Policy

1. In the config mode, use the app‐visibility‐policy <policy‐name> command.
2. Enable the status using the state enable command
3. Specify the application id and the policy type using appids <application‐ID>:<type> Use A, to allow and monitor the traffic usage

• Use B, to block traffic.

4. In a single policy you can add rules to monitor and block application traffic.

mc1500(15)(config)# app‐visibility‐policy  CorpNet mc1500(15)(config‐app‐visibility‐policy)# description  “” mc1500(15)(config‐app‐visibility‐policy)# state  enable mc1500(15)(config‐app‐visibility‐policy)# appids  6:B mc1500(15)(config‐app‐visibility‐policy)# essids  stability mc1500(15)(config‐app‐visibility‐policy)# apids  “5:A” mc1500(15)(config‐app‐visibility‐policy)# owner  controller mc1500(15)(config‐app‐visibility‐policy)# version  0 mc1500(15)(config‐app‐visibility‐policy)# exit

To View the list of policies and type configured for a specific AP, use the show applicationvisibility policy‐config‐service <app‐id> command.

mc1500(15)# show application‐visibility policy‐config‐service 5

AP      ESSID           APPID           Action

5       1               2               Allow

5       1               5               Allow

5       1               6               Block

5       1               8               Allow

5       1               24              Allow

5       1               32              Allow

5       1               41              Allow

5       1               70              Allow

        Application Visibility Policy Service(8)

Legends

Figure 71: DPI Config Option Legends

Label                                                                 Description

• When used for an application, it means to allow, detect, and monitor the application traffic.
• Used to detect and block the application traffic

A                  When use as an AP-ID, refers to adding an individual AP.

L                  Used to add an ap-group to a policy.

Monitoring Policies

mc1500(15)# sh service‐summary Application‐Visibility

Feature                 Type            Name                    Value   ValueStr

Application‐Visibility  Application     myspace                 100     {“util”:3006.76,”tx”:6943001576,”rx”:257651566}

Application‐Visibility  Application     amazon_cloud            0       {“util”:474.84,”tx”:1093389603,”rx”:43774451}

Application‐Visibility  Application     facebook                0       {“util”:184.00,”tx”:421673492,”rx”:18973696}

Application‐Visibility  Application     twitter                 0       {“util”:164.58,”tx”:358628579,”rx”:35513363}

Application‐Visibility  Application     unknown                 0       {“util”:97.92,”tx”:221291109,”rx”:13202213}

Application‐Visibility  Application     amazon_shop             0       {“util”:77.81,”tx”:162324404,”rx”:24026568}

Application‐Visibility  Application     linkedin                0      

{“util”:48.60,”tx”:109814218,”rx”:6565367}

Application‐Visibility  Application     youtube                 0       {“util”:

1.34,”tx”:2910287,”rx”:292302}

Application‐Visibility  Station         58:94:6b:b5:ca:c4       100     {“util”:591.86,”tx”:1364192275,”rx”:53208638}

Application‐Visibility  Station         00:27:10:cb:90:40       0       {“util”:571.51,”tx”:1317000065,”rx”:51657115}

Application‐Visibility  Station         10:0b:a9:44:f6:ac       0      

{“util”:297.04,”tx”:681777356,”rx”:29579769}

Application‐Visibility  Station         24:77:03:80:4c:60       0       {“util”:294.30,”tx”:676177538,”rx”:28620457}

Application‐Visibility  Station         84:3a:4b:48:1e:c0       0       {“util”:291.67,”tx”:668985331,”rx”:29513381}

Application‐Visibility  Station         24:77:03:80:2e:48       0       {“util”:287.46,”tx”:660217415,”rx”:28188180}

Application‐Visibility  Station         08:11:96:7d:cf:80       0       {“util”:286.78,”tx”:657504303,”rx”:29271859}

Application‐Visibility  Station         24:77:03:80:a4:40       0       {“util”:281.94,”tx”:646183947,”rx”:29009375}

Application‐Visibility  Station         24:77:03:80:5f:54       0       {“util”:280.23,”tx”:645624714,”rx”:25475052}

Application‐Visibility  Station         24:77:03:85:b4:50       0       {“util”:279.89,”tx”:641592459,”rx”:28689908}

Application‐Visibility  EssId           stability               100     {“util”:4055.84,”tx”:9313033268,”rx”:399999526}

Application‐Visibility  AP              AP‐109                  100     {“util”:4055.84,”tx”:9313033268,”rx”:399999526}         Service Data Summary(20 entries) mc1500(15)# sh ap

ap                      ap‐certificate          ap‐discovered           ap‐onlinehistory       ap‐reboot‐event         ap‐redirect             applicationvisibility

ap‐assigned             ap‐connectivity         ap‐neighbor             ap‐rebootcount         ap‐reboot‐top10         ap‐swap mc1500(15)# sh application‐visibility application‐summary

APPID           Name                    Station Counts  AP Counts       ESS Counts      Tx Bytes        Rx Bytes        TxRx Bytes

5               myspace                 12              1               1               7274981850      269918317       7544900167

24              amazon_cloud            13              1               1               1149026229      45994062        1195020291

2               facebook                13              1               1               443832821       19962877        463795698

8               twitter                 13              1               1               375850987       37259491        413110478

0               unknown                 20              1               1               233565871       13899667        247465538

70              amazon_shop             13              1               1               170637983       25318821        195956804

41              linkedin                12              1               1               115430025       6896689         122326714

32              youtube                 13              1               1               3022484         304784          3327268         Application Visibility Statistics Summary(8) mc1500(15)#

mc1500(15)# sh service‐summary‐trend Application‐Visibility

Feature                 Type            Name                    StartTime           

EndTime              Value     ValueStr

Application‐Visibility  Application     myspace                 01/17/2009

01:00:00  01/17/2009 02:00:00  370191907

{“util”:254501.59,”tx”:3561906268,”rx”:140012805}

Application‐Visibility  Application     amazon_cloud            01/17/2009

01:00:00  01/17/2009 02:00:00  523131985

{“util”:35964.57,”tx”:502700232,”rx”:20431753}

Application‐Visibility  Application     twitter                 01/17/2009

01:00:00  01/17/2009 02:00:00  221967525

{“util”:15259.95,”tx”:202733592,”rx”:19233933}

Application‐Visibility  Application     facebook                01/17/2009

01:00:00  01/17/2009 02:00:00  220636588

{“util”:15168.45,”tx”:210304218,”rx”:10332370}

Application‐Visibility  Application     unknown                 01/17/2009

01:00:00  01/17/2009 02:00:00  113502079

{“util”:7803.10,”tx”:106412520,”rx”:7089559}

Application‐Visibility  Application     amazon_shop             01/17/2009

01:00:00  01/17/2009 02:00:00  106703142

{“util”:7335.69,”tx”:93322094,”rx”:13381048}

Application‐Visibility  Application     linkedin                01/17/2009

01:00:00  01/17/2009 02:00:00  58696435 

{“util”:4035.30,”tx”:55165018,”rx”:3531417}

Application‐Visibility  Application     youtube                 01/17/2009

01:00:00  01/17/2009 02:00:00  1454576  

{“util”:100.00,”tx”:1315107,”rx”:139469}

Application‐Visibility  Application     myspace                 01/17/2009

02:00:00  01/17/2009 03:00:00  781850640

{“util”:264335.11,”tx”:7508697893,”rx”:309808509}

Application‐Visibility  Application     amazon_cloud            01/17/2009

02:00:00  01/17/2009 03:00:00  112454581

{“util”:38019.66,”tx”:1078606475,”rx”:45939338}

Application‐Visibility  Application     facebook                01/17/2009

02:00:00  01/17/2009 03:00:00  472612999

{“util”:15978.53,”tx”:448955762,”rx”:23657237}

Application‐Visibility  Application     twitter                 01/17/2009

02:00:00  01/17/2009 03:00:00  442033093

{“util”:14944.65,”tx”:401239344,”rx”:40793749}

Application‐Visibility  Application     amazon_shop             01/17/2009

02:00:00  01/17/2009 03:00:00  229558452

{“util”:7761.12,”tx”:202329371,”rx”:27229081}

Application‐Visibility  Application     unknown                 01/17/2009

02:00:00  01/17/2009 03:00:00  215482783

{“util”:7285.24,”tx”:200402948,”rx”:15079835}

Application‐Visibility  Application     linkedin                01/17/2009

02:00:00  01/17/2009 03:00:00  125984872

{“util”:4259.41,”tx”:118235346,”rx”:7749526}

Application‐Visibility  Application     youtube                 01/17/2009

02:00:00  01/17/2009 03:00:00  2957801  

{“util”:100.00,”tx”:2659330,”rx”:298471}

Application‐Visibility  Application     myspace                 01/17/2009

03:00:00  01/17/2009 04:00:00  859492100

{“util”:269614.13,”tx”:8269499897,”rx”:325421104}

Application‐Visibility  Application     amazon_cloud            01/17/2009

03:00:00  01/17/2009 04:00:00  116518953

{“util”:36550.84,”tx”:1119128571,”rx”:46060960}

Application‐Visibility  Application     facebook                01/17/2009

03:00:00  01/17/2009 04:00:00  461844358

{“util”:14487.60,”tx”:440897736,”rx”:20946622}

Application‐Visibility  Application     twitter                 01/17/2009

03:00:00  01/17/2009 04:00:00  408573605

{“util”:12816.55,”tx”:369504893,”rx”:39068712}

Application‐Visibility  Application     unknown                 01/17/2009

03:00:00  01/17/2009 04:00:00  237048541

{“util”:7435.98,”tx”:221824322,”rx”:15224219}

Application‐Visibility  Application     amazon_shop             01/17/2009

03:00:00  01/17/2009 04:00:00  204090068

{“util”:6402.10,”tx”:178965615,”rx”:25124453}

Application‐Visibility  Application     linkedin                01/17/2009

03:00:00  01/17/2009 04:00:00  121917540

{“util”:3824.43,”tx”:114827231,”rx”:7090309}

Application‐Visibility  Application     youtube                 01/17/2009

03:00:00  01/17/2009 04:00:00  3187860  

{“util”:100.00,”tx”:2879796,”rx”:308064}

        Service Data Summary Trend(24 entries)

Additional capabilities in Application Visibility include the following:

• Blocked traffic statistics
• Support for wired clients using port profile
• Bandwidth throttling
• DSCP Markings

Blocked Statistics

The dashboard now provides detailed statistics on blocked traffic.

The BLOCKED APPLICATIONS section provides the following statistics:

• Application Name: The application traffic set to be blocked.
• # of Active Users: The number of users requesting access to the application.
• # of Active APs: The APs that block the traffic.
• # of ESSIDs / Port: The ESSID and Port profile connected to the wireless and wired clients.
• Utilization: Shows how much traffic is blocked.

Support for Wired Clients

You can add port profiles to enable adding wired clients to detect, block, or bandwidth control traffic. The new policy page is updated to list port profiles created in the controller. A policy can be created with a mix of both ESSID and Port Profiles or only with ESS profiles or only with port profiles. The following is an example to create a policy and view policy details for wired ports via CLI. default(15)# configure terminal default(15)(config)# default(15)(config)# app‐visibility‐policy wiredPorts default(15)(config‐app‐visibility‐policy)#             default(15)(config‐app‐visibility‐policy)# port‐profiles wired‐profile default(15)(config‐app‐visibility‐policy)# state enable default(15)(config‐app‐visibility‐policy)# appids * default(15)(config‐app‐visibility‐policy)# advanced‐detection enable

You can use comma separated values to add multiple port profiles.

Example:  default(15)(config‐app‐visibility‐policy)# port‐profiles wiredprofile,default

View Policy Details

default(15)# sh application‐visibility policy wiredPorts

Application Visibility Policy Policy Name         : wiredPorts

Policy Order        : 2

Description         :

Policy              : enable

Advanced Detection  : enable

Bandwidth Limiting  : disable

Application ID List : *

ESSID List          :

AP Groups or APs    :

Owner               : controller Port Profile List   : wired‐profile default(15)#

Bandwidth Throttling

You can enforce bandwidth usage limits on selected applications.

1. To enable bandwidth throttle, create a policy and select Enable option for Bandwidth Limits.
2. Select ESSID or Port Profile.
3. Specify maximum bandwidth limits for clients and SSID/Port.

Minimum        Maximum

Client                               150 kbps         1 Gbps

ESSID / Port Profile        150 kbps 12 Gbps Limitations:

• Bandwidth throttle can be implemented on a maximum of 10 applications (individually or cumulatively across policies).
• When enabled the bandwidth throttling policy is applicable to all APs. AP and AP group selection is not available.
• The maximum bandwidth value configured for a client usage must be less than or equal to the value configured in ESSID or port traffic usage.
• Supported only for client traffic with tunnelled profile.

DSCP Markings

You can now add a DSCP value to application traffic (upstream: AP to controller and downstream: AP to station) to change its priority. The DSCP value for the selected application is used to mark the detected application traffic (to wireless or wired STA).

When a DSCP value is applied to application traffic, this value and the associated priority is maintained till the next node in the traffic. If the traffic carrying the DSCP value encounters a QoS-aware switch, then the DSCP value may be overridden by a QoS value specified by the switch.

In a downstream traffic, the DSCP value is applied by the controller before forwarding to the AP. This is supported for ESSID’s in tunnelled mode only.

 NOTE: DSCP markings can be added to a maximum of 10 applications (includes all policies).

To assign DSCP value to application traffic, do the following:

1. Go to Configuration > Access Control > Application > Policies tab.
2. Click the Add button to add a new Policy.

In the new Policy enter the following details

1. Name for the policy.
2. Select Enable to activate the policy
3. Select ESS profile
4. Select AP or AP group
5. Now click the add icon to view list of applications
6. Selection applications to be marked with DSCP values
7. For the listed application, you can specify individual DSCP values from the dropdown under DSCP Marking column.

Valid DSCP value strings

• af11
• af12 af13            • af21            • af22            • af23            • af31            • af32            • af33            • af41            • af42
• af43
• cs0     cs1             • cs2             • cs3             • cs4             • cs5             • cs6
• cs7
• no
• ef

For more details about DSCP values, see: https://tools.ietf.org/html/rfc4594

 

CLI Commands

To enable DSCP marking for downstream traffic, use the following command: default(15)(config)# app‐visibility‐config controller‐dscp‐marking‐state enable

The following command format configures DSCP marking and specifies bandwidth restrictions:

<app‐id>:A or B|C:<per‐client‐bw‐value>:<bw‐unit>|E:<per‐ess‐bw‐value>:<bwunit>|D:<dscp‐string>

• Application Id – <app-id:>
• Rule type (A- allow, B – block) – < A or B>
• Per client bandwidth limit – C:<bw-value>:<bw-unit> [Supported units K, M, G]
• Per ESSID bandwidth limit – E:<bw-value>:<bw-unit> [Supported units K, M, G]
• DSCP value – D:<dscp-value-string> [Supported values]

Example:

2:A|C:150:K|E:1:M|D:af11

The above command will allow traffic for application with id 2, limit bandwidth for client and ESS profile accessing this application traffic to 150 kilobits and 1 Megabits respectively, and set the DSCP for upstream traffic to af11.

Best Practices

The following is a recommended best practice while create application visibility policies. • While it is possible to create a single policy that can detect, block, or enforce bandwidth limits, it is recommended that you create individual policies that independently detect, block, or enforce bandwidth limits.

• Policies are prioritized in the following order
• Block
• Bandwidth Throttling
• Detect (General)

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