Category Archives: Administration Guides

FortiWLC – Installing and Configuring an Enterprise Mesh System

Installing and Configuring an Enterprise Mesh System

Determine Antenna Placement

An Enterprise Mesh uses APs (as repeaters) to extend the range of wireless coverage. An AP in a Enterprise Mesh configuration is directed to look for a signal from a Parent AP. As such, antenna placement and reception is important for the optimum performance of the system.

If there are obstacles in the radio path, the quality and strength of the radio signal are degraded. Calculating the maximum clearance from objects on a path is important and should affect the decision on antenna placement and height. It is especially critical for long-distance links, where the radio signal could easily be lost.

When planning the radio path for a wireless hop, consider these factors:

Be cautious of trees or other foliage that may be near the path between nodes, or ones that may grow to obstruct the path.
Be sure there is enough clearance from buildings and that no building construction may eventually block the path.
Check the topology of the land between the antennas using topographical maps, aerial photos, or even satellite image data (software packages are available that may include this information for your area).
Avoid a path that may incur temporary blockage due to the movement of cars, trains, or aircraft.

Installing the Fortinet Enterprise Mesh

Enterprise Mesh APs are configured in five phases.

These steps assume that the deployment is not being configured via the PlugNPlay functionality. See “Adding Mesh APs Via PlugNPlay” on page 440 for additional details.

Phase 1: Connect Controller and APs with an Ethernet Switch
Phase 2: Create a Mesh Profile
Phase 3: Add APs to the Mesh
Phase 4: Configure the APs for Mesh Operation
Phase 5: Remove the Cables and Deploy the APs

Phase 1: Connect Controller and APs with an Ethernet Switch

In a standard initial mesh setup, the user can configure all mesh APs desired at once via wired connection through a local switch. (This configuration is intended to happen prior to remote deployment.) For an alternative mechanism that allows APs to be deployed remotely prior to them being configured locally, refer to Adding Mesh APs Via PlugNPlay.

Connect all APs directly to a controller through a switch or hub.
Power on the controller.
Connect the APs to a power source using either separate power supplies or Power over Ethernet (PoE) connections.
If the controller does not have an assigned IP address, configure with the following; otherwise, skip to step 5:
- Connect a computer to the controller using a serial cable.
- Using a PC terminal program with the settings 115200 baud, 8 bit, no parity, access the controller and log in with the default admin/admin username/password.
- Use the setup command to assign the controller an IP address. Reboot the controller and log in again as admin.
Log into the controller’s CLI under the admin account (if not already logged in).
For the APs that will be in the Enterprise mesh, verify they are connected to the controller (enabled and online) and ensure that their runtime version is the same version of FortiWLC (SD) as the controller’s:
- Check the FortiWLC (SD) version with the command show controller
- Verify the APs with the command show ap

Phase 2: Create a Mesh Profile

A single controller can manage multiple separate meshes as desired. Follow these steps to create a mesh profile.

From the WebUI (accessed by opening an Internet browser and navigating to your controller’s IP address), navigate to Configuration > Wireless > Mesh. The Mesh Configuration screen appears. (The screen will be empty unless a mesh profile is already present.)
Click Add.
On the Mesh Configuration – Add screen, provide the following details:
- Name: Enter a name for the mesh profile.
- Description: Enter a brief description for the profile (e.g., its location).
- Pre-shared Key: Enter an encryption key for mesh communications. This key will be shared automatically between APs that have been added to the mesh profile; the user will not be required to input it manually later on. This key must be between 8 and 63 characters.
- Admin Mode: Setting this field to Enable activates the mesh profile. If the profile needs to be disabled for any reason, set this field to Disable.
- PlugNPlay Status: This option allows APs to be added to the mesh by eliminating the need to have them wired connected during mesh configuration. See Adding Mesh APs Via PlugNPlay for details.
Click OK when all fields have been configured. The new mesh profile is listed in the mesh table.

Phase 3: Add APs to the Mesh

Now that the mesh has been created, you can add your APs to it. Follow the instructions below.

The mesh APs must exist in the controller’s AP table (i.e., they must be added manually or have been connected to the controller as performed in previous steps) before they can be added to the mesh.

From the Configuration > Wireless > Mesh screen, check the box alongside the mesh profile to be modified and click Settings. A summary of the configured mesh settings will be displayed.

Figure 74: Modifying the Mesh

Click the Mesh AP Table tab provided. Since no APs have been added yet, the table will be blank.
Click Add.
In the resulting page, use the AP ID drop-down to specify the desired AP.
Click OK to add the AP. It will be displayed in the Mesh AP table.

Repeat these steps for all desired APs. Once all APs have been added, they can be configured to utilize mesh operation.

Phase 4: Configure the APs for Mesh Operation

Despite the fact that the APs have been added to a mesh profile, they still must be configured to utilize mesh operation. Follow the steps below.

From the WebUI, navigate to Configuration > Devices > APs.
Check the box alongside one of the mesh APs and click the pencil icon.
Click the Wireless Interface tab to display the available wireless interfaces on the AP.
Check the box alongside one of the interfaces and click Settings. Either interface can be selected, but dual interface mesh is not currently supported.
From the Wireless Interface tab, click the drop-down box for Mesh Service Admin Status and select Enable.

Figure 75: Enabling Mesh Service

Click OK to save the configuration change.

Repeat these steps for all APs that are part of the mesh. Verify that they are all displayed in the Mesh-AP member table, as shown in Figure 76. Figure 76: Mesh AP Member Table

Phase 5: Remove the Cables and Deploy the APs

Phase 5 consists of removing the cables, deploying the APs in their final locations, and turning them on. They will then be picked up by the controller as wireless APs.

To deploy the APs, follow these steps:

Ensure that each AP has a power source; if you are using PoE, you need to provide a power adapter for mesh nodes before they can be activated.
Unplug the APs and physically install them in the desired locations.
Power up the APs in order (i.e., power up the gateway AP first, then any mesh nodes connecting directly to the gateway, etc.). Make sure each AP is online before powering up the next one.
From the controller’s CLI, use the copy running-config startup-config command to save your configuration.
Create ESSIDs for clients and connect clients. Try pinging, browsing, etc. with the clients.

Once deployed, the APs will automatically determine the appropriate parent configurations to provide backhaul access. Provided the APs are in range with each other as per design, they should appear online automatically with no further settings. Your installation is complete.

Adding Mesh APs Via PlugNPlay

As mentioned in “Phase 2: Create a Mesh Profile” on page 437, the PlugNPlay option allows mesh nodes to be connected to an existing mesh, without requiring them to be wired directly to the controller. This function is disabled by default.

With PlugNPlay enabled on an existing mesh, deploying a mesh-capable AP to its intended location allows the AP to automatically seek out a mesh within range and add itself to the controller. In effect, this means that a user can set up a mesh profile with only one AP configured for mesh service (by following the instructions earlier in this chapter) and then install additional mesh-capable APs to their intended locations. Once the new APs are powered up, they will link with the previously-configured mesh AP and add themselves to the controller’s AP database.

This does not mean that the new AP automatically assumes mesh operation. PlugNPlay operation allows it to add itself to the database directly, but it must still be added to the Mesh AP table on the controller and configured for mesh operation. PlugNPlay simply allows the AP to sync with the controller without requiring a physical connection.

Follow the steps below to install a new mesh AP using the PlugNPlay mechanism. Note that this scenario assumes that a mesh profile has already been created and has at least one active mesh AP added to it and configured via the steps detailed in “Phase 2: Create a Mesh Profile” on page 437 and “Phase 3: Add APs to the Mesh” on page 438 above.

Unbox the new mesh-capable AP and install it within range of the existing mesh node.
Connect its power source and allow it to come online. Note that since it will connect to the controller automatically, it may require some time to download new firmware and configurations.
Use a computer to access the controller’s WebUI.
From the web browser, navigate to Configuration > Wireless > Mesh.
Check the box next to your existing mesh and click Settings.
Click the Mesh AP Table tab.
Click Add and select the newly-added AP from the drop-down list. Since it has just been connected, it is likely the most recent (or highest) AP ID number in the list.
Click OK to add the new AP to the table.

Now that the AP is part of the mesh, you can enable mesh service on it by performing the following steps.

Navigate to Configuration > Devices > APs.
Check the box alongside the new mesh AP and click Settings.

Click the Wireless Interface tab to display the available wireless interfaces on the AP.
Check the box alongside one of the interfaces and click Settings. Either interface can be selected, but dual interface mesh is not currently supported.
From the Wireless Interface Configuration – Update screen, click the drop-down box for Mesh Service Admin Status and select Enable as shown in Figure 75
Click OK to save the configuration change.

These steps can be repeated for as many new mesh nodes need to be configured. Once all the desired nodes have been added, it is recommended that PlugNPlay be disabled on the mesh until additional nodes are needed.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

FortiWLC – Mesh Network

Leave a reply

Mesh Network

Enterprise Mesh is an optional wireless alternative for the Ethernet links connecting APs to controllers. Deploy the Enterprise Mesh system to replace a switched wired backbone with a completely wireless 802.11 backbone, while providing similar levels of throughput, QoS, and service fidelity.

The following are Enterprise Mesh features:

Hierarchical bandwidth architecture
Dynamic allocation and balancing of the RF spectrum
Full duplex capability
Extend virtual cell, QoS, and RF coordination over backbone
Wireless DS-to-DS (WDS) encapsulation of the Enterprise Mesh traffic
Dataplane Encryption (affects performance because encryption/decryption is in software)

Mesh deployments are not intended for use in:

Metropolitan or municipal Wi-Fi networks
High throughput, density, or quality video/audio applications

Mesh Restrictions

The following restrictions apply to the design and implementation of Fortinet mesh networks.

Enterprise Mesh APs require L3 connectivity to the controller.
Monitoring of backhaul links via SAM is not supported.
A radio that is not actively used for mesh cannot be used for SAM purposes.
Bridged mode is not supported for wireless clients in Enterprise Mesh—only tunneled mode is supported.
Gateway and mesh APs support a maximum of 4 backhaul links.
From the gateway (i.e., an AP physically connected to the network), a maximum of 3 hops is supported with no more than 16 APs per cloud.
A maximum of 500 stations can be active on a mesh cloud at any given time.
Minimum channel separation guidelines are to use non-overlapping channels.

431

Mesh operation on DFS channels is not recommended.
Aggregation of multiple uplink connections is not supported.
A single AP cannot be assigned to multiple mesh clouds.
A maximum of 64 mesh profiles can be created on a controller. Each mesh profile can contain a maximum 16 APs.
Since OAP832 has only radio 1 in 5GHz, mesh can be established only on that radio.

Enterprise Mesh Design

Enterprise Mesh is typically composed of hub-and-spoke configurations (as shown in Figure 72), chain configurations (as shown in Figure 73), or a variation of these.

In a dense network, hub-and-spoke (all APs point to the gateway) is the best topology, although collisions can occur.

For optimal performance, avoid collisions between adjacent small clouds by creating each cloud on a separate channel. A cloud is defined as a set of APs communicating along a backhaul topology path to/from a gateway AP.

Figure 72: Enterprise Mesh Network – Hub and Spoke Design

Figure 73: Three Hop Enterprise Mesh – Chain Design

Gateway APs

A gateway AP is located at the wired edge of the Enterprise Mesh network, and provides the link between wired and wireless service. The gateway AP is the only AP that has a wired connection to the network.

Mesh APs

Mesh APs refer to all APs that are not acting as gateway APs. They can provide intermediate service between other mesh APs or used as the endpoint in a mesh chain (as shown in Figure 73).Mesh APs can have wired connection to the network.

The unused Ethernet port on a Mesh AP can be configured and used in the same manner as a wired port on an Ethernet switch. As such, users can connect a hub/switch with other wired devices to it in order to access the corporate network. In order to use the port, a Port Profile must be configured for it. Refer to Configuring Port Profiles for details.

Leaf APs

An AP that is connected to the controller via a wireless back haul connection but cannot provide wireless back haul service to other nodes.

Wired Clients

Unused Ethernet port (interface 1) of an AP400, AP332, AP122, AP832, AP832, AP822 and FAP-U421EV, and FAP-U423EV configured as a Mesh AP can be used to connect up to 512 wired clients.

Equipment Requirements

Any controller model can be used for a mesh deployment. The following AP models currently support mesh operation:

AP1000 series
AP332e/i
AP832, AP800
AP433
FAP-U421EV
FAP-U423EV

Mesh Discovery

The following are the various discovery scenarios in a mesh network:

Scenario 1: Regular Discovery

In a regular discovery process, a mesh AP uses the process as mentioned in the “CAPWAP and Legacy Reference” on page 335 .

Scenario 2: L2/L3 discovery failure.

In L2/L3 discovery failure, the AP switches to mesh discovery. In this mode, the AP searches (on 5G for AP122, 822, FAP-U4xx, OAP832 and for other supported APs, on 5G and then followed by 2.4G) for a mesh beacon (a hidden ESS-Id). When it finds this hidden ESS-Id, it creates an association. After the association is complete, the AP starts the DHCP process to get an IP address from the controller. However, this AP (mesh AP) must be in the same mesh cloud in order to establish a connection.

NOTE: Backhaul links are always encrypted.

Refer to the online help for more information on creating mesh cloud

Scenario 3: AP is Unable to find a suitable backhaul service

If the AP is unable to find a suitable backhaul service or if key exchange fails, the AP scans to wireless medium for recovery service.

When a recovery service is found, the AP completes key exchange and 4-way handshake to discover the controller. After the discovery is complete, the configuration is downloaded. However, this AP does not provide any WLAN services.

To enable WLAN services, this AP must be added to a mesh cloud.

NOTE: A mesh AP can be part of only one cloud at a time.

Failover / Re-discovery

In a mesh cloud, if a mesh AP or a leaf AP loses contact with its parent, the AP switches to discovery mode. The discovery process begins with scenario 1-regular AP discovery process..

Parent Selection Mechanism

In a mesh cloud, an AP selects its best parent AP using a match to the following parameters and values.

snr-weight: 3
child-weight: 1
hop-weight: 10

The above are default values and they can be customized to your RF environment using the following AP-CLI commands: mesh {parent_selection | psel}

Set/Get weights for parent selection parameters

To set:

mesh parent_selection [snr|child|hop] <integer>

To get:

mesh parent_selection

To reset:

mesh parent_selection reset

FortiWLC – DSCP Marking for Management Packets

Leave a reply

DSCP Marking for Management Packets

You can apply Differentiated Services Code Point (DSCP) values to management and application traffic (see Application Visibility Enhancements section). DSCP value is a selectable field that can be used to assign various levels of precedence to network traffic.

By default, traffic packets contained an EF value and with the introduction of this feature you can change the priority bit from EF to an appropriate DSCP value that meets your requirements.

Management traffic between the following can be assigned DSCP values:

DSCP Marking for Management Packets

AP to Controller
Controller to AP
Controller to Network Manager

Enable DSCP Value

To configure DSCP from WebUI, go to Configuration > Policies > QoS Settings > Marking Management Packets (tab).

Select the DSCP values for each traffic and click the SAVE button.

DSCP Marking for Management Packets

FortiWLC – Load Balancing for APs in Virtual Cell

Leave a reply

Load Balancing for APs in Virtual Cell

You can configure load balancing to effectively distribute wireless clients to alternate access points. The load balancing is performed by the controller based on two factors; Current Load of the AP and RSSI value of the client.

Current load of an AP – Current load represents the number of clients assigned to an AP. Load Balancing for APs in Virtual Cell
RSSI value of the Client – The RSSI value of the client is received by the controller.

When a new client joins the network, the controller will connect the client to an AP that is running below its maximum load threshold and providing the best RSSI value.

To enable load balancing, configure the Load Threshold for the access point. Go to Configuration > Wireless > Load Balance.

Load Balancing vCell: Select On to activate this functionality.
Load Threshold: Specify the load threshold. This value denotes the number (in percentage) of clients that can connect to an AP. Example, if the optimum capacity of an AP is 80 clients, and the threshold is set to 90%, then a maximum of 72 clients are allowed to connect.
RSSI Threshold- Configurable via CLI (load‐balance‐vcell rssi‐threshold <rssivalue>). Specify the RSSI value of the best and an alternate AP. Load balance is activated for a value below the configured RSSI value. The default value is -65dbm and the configurable range is -75dbm to -45dbm. The following table provides the recommended RSSI threshold for various modes and channel bandwidth:

	20 MHz	40 MHz	80 MHz	160 Mhz / 80+80 Mhz
802.11b	-76 dbm	NA	NA	NA
802.11a/g	-65 dbm	NA	NA	NA

Load Balancing for APs in Virtual Cell

	20 MHz	40 MHz	80 MHz	160 Mhz / 80+80 Mhz
802.11n	-64 dbm	-61 dbm	-58 dbm	NA
802.11ac	-57 dbm	-54 dbm	-51 dbm	-48 dbm

nPlus1 Support: The load balance feature allows the clients to connect to the best available access point during roaming in an nplus1 set up.

The following table illustrates various load balancing scenarios between two APs (AP1 and AP2) and the expected result when a client tries to join the network. :

L1 represents the load on AP1; L2 represents the load on AP2. The value ‘1’ represents AP1 has reached its load threshold.
R1 represents RSSI value on AP1, and R2 represents RSSI value of AP2, The value ‘1’ represents an RSSI value that is higher than the configured value.

Scenario	Expected Result
L1=1, L2=0 and R1=0 and R2=0	Since AP1 is running in full capacity the client will be assigned to AP2.
• L1=0, L2=0 and R1=0 ,R2=0 • L1=0 , L2=0 and R1=-1, R1=-1 • L1=1, L2=1 and R1=1 and R2=1	In these scenarios, the controller will use default association mechanism to assign the client to AP.
• L1=0, L2=1 and R1=1, R2=0 • L1=1, L2=0 and R1=1, R2=0 • L1=1, L2=0 and R1=1, R2=1 • L1=1, L2=1 and R1=1, R2=0	In these scenarios, the client will be assigned to AP2.
For other cases where L1 or L2 =1	The client stay associated with the current AP i.e. AP1

FortiWLC – Application Visibility (DPI)

Leave a reply

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:

Enable Application Visibility
Create Policies
Associate system defined and/or custom applications to policies

Enable Application Visibility

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

Select ON for Enable Application Classification. This is a global settings and enables DPI on all APs.
Export Interval is a non-configurable field that set at 90 seconds.
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
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.

Click the ADD button to view application lists
Select the application from the list and click ADD button
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

To create a custom application, go to Application > Settings > Custom Applications and click the Add
Enter properties for the custom application and click Save. In this simple example, traffic from www.bbc.com will be monitored.
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.

The graph displays a pie chart with the top 10 applications (by usage) that are monitored.
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.
List of APs that are passing traffic for one or more of the top 10 applications
List of ESS profiles that are passing traffic for one or more of the top 10 applications
This table lists the top 10 application and displays numerical (integer) statistics about number of stations, ESS profiles, APs and traffic size in bytes.
This table shows historical data for application traffic in the last 24 hours.

Using CLI

Creating a Policy

In the config mode, use the app‐visibility‐policy <policy‐name> command.
Enable the status using the state enable command
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.

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.

To enable bandwidth throttle, create a policy and select Enable option for Bandwidth Limits.
Select ESSID or Port Profile.
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:

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

In the new Policy enter the following details

Name for the policy.
Select Enable to activate the policy
Select ESS profile
Select AP or AP group
Now click the add icon to view list of applications
Selection applications to be marked with DSCP values
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)

FortiWLC – More QoS Rule Examples

Leave a reply

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

FortiWLC – QoS Statistics Display Commands

Leave a reply

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)

FortiWLC – Configuring Codec Rules

Leave a reply

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