Phase 1—AVC 7.4	■Application classification and control of 1039 applications with NBAR2 engine. ■Support of 16 AVC profiles with 32 rules per profile. ■One AVC profile support per WLAN; the same profile can be supported on multiple WLANs. ■AVC profile mapped to WLAN has a rule for MARK or DROP action. ■Graphical presentation on the controller for all classified applications ■One NetFlow exporter and monitor can be configured on the WLC. ■AVC NetFlow monitoring on PI with PAM license.
Phase 2— AVC 7.5	■Protocol Pack 4.1 support in AVC Phase 2. ■Additional application support—Total of 1056 applications ■Support for loading protocol pack dynamically to update applications.
Phase 3—AVC 8.0	■Protocol Pack 9.0 ■NBAR Engine Release 3.1 ■AAA AVC Profile override for clients. ■Application rate limiting per-user on WLAN. ■Integration of AVC profiles to the Local Policy classification per user and per device. ■AVC Directional QoS DSCP Marking for Upstream and Downstream traffic. ■Support for 1105 applications
Phase 4-AVC 8.2	■Protocol Pack 14.0 ■NBAR Engine 23 ■Support for 1273 Applications ■Support for 3rd party Netflow Collector ■Support for two Flow Collectors ■Support for 17 Data Flow Records in Flow Collector
Phase 5- AVC 8.3	■Protocol Pack 19.1 ■NBAR Engine version 23 ■Support for 1317 Applications
Phase 6 - AVC 8.8	■Protocol Pack 37 ■NBAR Engine Version 31 ■Support for 1408 applications ■Enhancement to Default DSCP values. ■Support Wi-Fi calling Flex Connect AVC Wave-2 APs ■Protocol Pack 37 ■NBAR2 Engine 31 ■Support for 1408 applications ■Enhancement to Default DSCP values ■Support for Wi-Fi calling

NBAR Supported Feature

NBAR as a feature can perform the following tasks:

1. Classification–Identification of Application/Protocol.

2. AVC–Provides visibility of classified traffic and also gives an option to control the same using Drop or Mark (DSCP) action.

3. NetFlow–Updating NBAR stats to NetFlow collector like Cisco Prime Assurance Manager (PAM).

AVC and QoS Interaction on the WLAN

The AVC/NBAR2 engine on the controller interoperates with the QoS settings on the specific WLAN. The NBAR2 functionality is based on the DSCP setting. The following occurs to the packets in Upstream and Downstream directions if AVC and QoS are configured on the same WLAN:

Upstream

1. Packet comes with or without inner DSCP from wireless side (wireless client).

2. AP will add DSCP in the CAPWAP header that is configured on WLAN (QoS based configuration).

3. WLC will remove CAPWAP header.

4. AVC module on the controller will overwrite the DSCP to the configured marked value in the AVC profile and send it out.

Downstream

1. Packet comes from switch with or without inner DSCP wired side value.

2. AVC module will overwrite the inner DSCP value.

3. Controller will compare WLAN QoS configuration (as per 802.1p value that is actually 802.11e) with inner DSCP value that NBAR had overwritten. WLC will choose the lesser value and put it into CAPWAP header for DSCP.

4. WLC will send out the packet to AP with QoS WLAN setting on the outer CAPWAP and AVC inner DSCP setting.

5. AP strips the CAPWAP header and sends the packet on air with AVC DSCP setting; if AVC was not applied to an application then that application will adopt the QoS setting of the WLAN.

AVC Operation with Anchor/Foreign Controller’s Setup

In the case of Anchor and Foreign controller’s configuration, the AVC has to be configured where the application control essentially is required. In most cases in Anchor/Foreign setups the AVC should be enabled on the Anchor controller. AVC profile enforcement will happen on the WLAN on the Anchor controller. If Anchor controller is release 7.4 or higher the above mentioned setup will work.

AAA AVC Profile Override for Clients

As mentioned above in releases 7.4, 7.5, and 7.6, the AVC Profile is configured on a WLAN and all clients connected to that WLAN inherit the same AVC profile. The value proposition to allow for the AAA AVC profile override is to enable different clients (logging in as different users) to obtain different AVC profiles even though they are connected to the same WLAN.

The AAA attribute for a client or user profile can be configured on AAA servers, for example, Cisco ACS or ISE. The AAA attribute is defined as a generic Cisco AV Pair and can be defined as a string and value pair in AAA. This attribute is processed during L2/L3 Authentication by the WLC and the same is overridden by what is configured on the WLAN.

Steps to Configure Application Visibility Per User Role

Complete these steps:

1. Create/Configure a WLAN with L2 Security set for WPA2/802.1x authentication. Assuming that the user/administrator has already configured the AAA server for dot1x authentication, choose the AAA server from the Authentication Servers drop-down list and click Apply.

Click the Advanced tab and enable “AAA Override” as shown below.

2. To enable Application Visibility, click the WLAN ID and in the QoS tab, check the Enabled check box for Application Visibility. Click Apply.

 

AAA Configuration for AVC Profile

The AAA AVC Profile is defined as a Cisco AV Pair. The string is defined as avc-profile-name and this has to be configured for any AVC profile existing on the WLC.

Complete these steps:

1. To demonstrate the AVC profile being applied per user through AAA server, create AVC profiles by navigating to Wireless > Application Visibility And Control > AVC Profiles and click New. In this setup/example, we created a teacher-AVC and student-AVC. We will mark specific traffic (YouTube and so on) for user/role teacher and block/drop the specific application/traffic (YouTube, Facebook and so on) for user/role student. You can create your own AVC profiles according to your network requirements.

 

2. Enter the AVC profile name and click Apply. Similarly, create another profile.

3. The AVC profile is created and you can view the above created profile, which can be clicked to create rules to take drop/mark/Rate Limit action from the GUI. A maximum of 16 AVC profiles can be created on the WLC.

4. After creating the AVC profiles, you can click any profile name and create rules for individual profiles. A maximum of 32 rules can be configured in each profile. Rules can be configured to take any of the 3 actions, that is, DROP, MARK, and RATE LIMIT. If no rule is configured for any application, the default action will be “Allow” with the QOS policy configured on the WLAN. To create rules for a profile, go to Wireless > Application Visibility And Control > AVC Profiles, and then click any Profile.

 

Note: WLC is capable of classifying 1105 applications with Protocol Pack 11.0 and gives an option to take action. To take an action on any application, the administrator has to select the application group first to which that application belongs, which will filter the list of applications for that application group only. The reason for this implementation is all 1105 applications cannot be displayed in a single drop-down. The administrator is also flexible while configuring Action as MARK to choose the Differentiated Services Code Point (DCSP) value as Custom instead of selecting “Platinum/Gold/Silver/Bronze”. Once Custom is selected as the DSCP value, a text field will be visible where the admin can enter the custom DSCP value in the range of 0 - 63.

Prior to Release 8.0, the DSCP Marking is only applied bi-directionally for traffic. But in Release 8.0, an extra configuration parameter of “Direction” is available where marking can be specified with respect to direction, that is, Upstream or Downstream as shown below.

5. Once the appropriate Marking is selected, click Apply. The action rule will be created and is displayed as captured in the below screen. You can add more rules under the same AVC profile on the same page. A maximum of 32 rules can be configured in a single AVC profile.

Another rule can be configured under the same AVC profile to MARK traffic with a different QoS profile or custom DSCP value with a specific direction.

Here, we configured Netflix and YouTube to be marked for the AVC profile “teacher-AVC” with DSCP 34 (Gold) with the direction set to Bidirectional and Upstream, respectively.

6. Similarly, the following example displays another AVC profile (student-AVC) for a different role type, which is student in our setup and is configured to drop Facebook, YouTube, and BitTorrent traffic.

7. Now, assume that the user/administrator has already configured the AAA server (ISE/ACS/Open Radius) with users (teacher and student), devices (WLC), and Authorization Profiles. To configure the AAA Server to match the profile for the AVC set on the WLC, from ISE main menu bar, go to Policy > Policy Elements > Results > Authorization > Authorization Profiles. Here, you see the configured profiles (Student and Teacher) displayed in the example screenshot below.

8. Click the authorization profile which you created for the role Teacher, and under Advanced Attributes Settings, configure AVC Profile Name by adding cisco-av-pair=avc-profile-name=The AVC profile name created on the WLC, as shown below.

If you are using the Cisco ACS, go to Policy Elements > Authorization and Permissions > Network Access > Authorization Profiles. Add cisco-av-pair to match the string value avc-profile-name=The AVC profile name created on the WLC.

Similarly, configure the Authorization profile for student as well. Once configuration is done, you can connect a wireless client to the 802.1x WLAN with teacher credentials. You will be able to access Netflix and YouTube.

When the wireless client (with role student) connects to the same 802.1x WLAN, the client cannot play any videos on YouTube. Also, if the client tries to access a Facebook page and tries to open any YouTube video from the Facebook account, the YouTube video will not be played.

Because both YouTube and Facebook are blocked in the AVC profile for Student-AVC, therefore clients with student role will not be able to access YouTube videos via a browser or even via a YouTube application or from any other website nor they can access Facebook.

On the other hand, when the client logs in with Teacher credentials, the traffic is just marked and no application is dropped.

To verify if the policy is applied, from the WLC CLI prompt, run the following command:

show client detail mac_address, then scroll down to see the applied profile.

Application Rate Limiting Through AVC

In this release, we can configure only 3 applications for rate limiting which can be done from the WLC CLI through the following command:

(WLC) >config avc profile <prof-name> {add|remove} rule application <app-name> {drop|mark <dscp-value>|ratelimit <avg_rate> <burst_rate>}

Note: The minimum ratelimit value can be set from minimum 0 Kbps to maximum 2147483647 Kbps.

The configuration example below is performed on the profile “student-AVC” when using the BitTorrent application:

(WLC) >config avc profile student-AVC rule add application bittorrent ratelimit 150 500

Similarly, from the WLC GUI, the Rate Limiting can be configured by selecting the application on which the user wants to apply Rate Limit and from the Action drop-down list, choose Rate-Limit.

This brings up an option for the user to configure the average and burst rates for the desired application that the user needs to rate limit. The user can assign any value in Kbps from 0 to 2147483647. Once the Rate-Limit is set, the user can choose the “AVC Name” on which he wants to apply the Rate Limit and click Apply.

In this example, we are rate limiting the BitTorrent application with the average rate set to 150 Kbps and burst rate set to 500 Kbps and applying this to the AVC profile “student-AVC”.

The BitTorrent application displays ratelimit in the Action column with Rate Limit average and burst rate values.

NBAR Facts (AVC Phase 3)

■NBAR Engine 13 and PP 11.0 can support 1105 different applications.

■Three actions DROP, MARK and RATE LIMIT is possible on any classified application.

■A maximum of 16 AVC profiles can be created on the WLC.

■Each AVC profile can be configured with a maximum of 32 rules.

■The same AVC profile can be mapped to multiple WLANs. But one WLAN can have only one AVC profile.

■Only one NetFlow exporter and monitor can be configured on the WLC.

■NBAR statistics are displayed only for the top 30 applications on the GUI. The CLI can be used to see all applications.

■NBAR is supported on WLANs configured for central switching only.

■If the AVC profile mapped to the WLAN has a rule for MARK action, that application will get precedence as per QOS profile configured in the AVC rule overriding the QOS profile configured on the WLAN.

■Directional Marking can only be applied either Bidirectional, Upstream or Downstream on a particular application.

■Currently, Rate Limit can only be applied to three applications.

■Any application that is not supported/recognized by the NBAR engine on the WLC is captured under bucket of UNCLASSFIED traffic.

■IPv6 traffic cannot be classified.

■AAA override of AVC profiles is supported in 8.0 release.

■The AVC profile can be configured per WLAN and applied per user basis.

■NBAR is not supported in vWLC and SRE WLC.

AVC Profiles Attached to Local Policies

In Release 8.0, an AVC profile can be mapped to a local policy for a client with a particular device type. Ensure that each local policy can be configured with a different AVC/mDNS profile name based on the AAA override to restrict the policy from being able to use the services not allowed by the profile on the same WLAN.

Introduction to Profiling and Policy Engine on the WLC

Cisco currently offers a rich set of features which provide device identification, onboarding, posture, and policy, through ISE. This new feature on the WLC does the profiling of devices based on protocols such as HTTP, DHCP, and so on to identify the end devices on the network. The user can configure the device-based policies and enforce per user or per device policy on the network. The WLC will also display statistics based on per user or per device end points and policies applicable per device.

With BYOD (Bring your own device), this feature has an impact on understanding the different devices on the network. With this, BYOD can be implemented on a small scale within the WLC itself.

Scope and Objectives

In this section, the user will be configuring and implementing Profiling and Policy on a Cisco WLC running AireOS 8.0 code.

The profiling and policy enforcement will be configured as two separate components. The configuration on the WLC is based on defined parameters specific to clients joining the network. The policy attributes which are of interest are:

a. Role—Role defines the user type or the user group the user belongs to.

For example: Student or Employee

b. Device—Device defines the type of device.

For example: Windows machine, Smart phone, Apple device such as iPad, iPhone and so on.

c. Time of day—Allows configuration to be defined at what time of the day end-points are allowed on the network.

d. EAP Type—Checks what EAP method the client is getting connected to.

The above parameters are configurable as policy match attributes. Once the WLC has a match corresponding to the above parameters per end-point, the policy enforcement comes into picture. Policy enforcement will be based on session attributes such as:

■VLAN

■ACL

■Session Timeout

■QoS

■Sleeping Client

■Flexconnect ACL

■AVC profile (added in 8.0 release)

■mDNS profile (added in 8.0 release)

The user can configure these policies and enforce end-points with specified policies. The wireless clients will be profiled based on the MAC OUI, DHCP, and HTTP user agent (valid Internet required for successful HTTP profiling). The WLC uses these attributes and predefined classification profiles to identify the device.

Profiling and Policy Configuration

Complete these steps:

1. To configure device profiling on a WLAN, go to the specific WLAN on which you want to implement Native profiling and policy and click the Advanced tab. Disable Allow AAA Override if it is enabled. In the DHCP area, check the Required check box for DHCP Addr. Assignment.

2. After enabling the DHCP required option, scroll down and in the Local Client Profiling area, enable DHCP Profiling and HTTP Profiling if they are not enabled and click Apply.

Creating Policies on the WLAN from the WLC GUI

3. Once Profiling is configured, we can move on to create Local policies and apply them on the WLAN. On the WLC menu bar, go to Security > Local Policies, which will take you to the Policy List.

4. When in the Local Policy List, click New to create a Policy Name. In this example, teacher-LP is used as a policy name, but you can use any name to define your own policy.

Once policy name is configured, you can create policies to match a Role, EAP Type, and Device Type. Also, you can define the required actions related to the Match criteria.

Here, in our setup we use User Role and Device Type to Match Criteria, but you can use any other type if required.

Note: Make sure Match Role string is the same as AAA defined role name. In this example, it is configured as teacher.

5. Enter User Role and click Apply. Here the role name “teacher” is used as an example.

6. To apply the policy based on a user device, in the Device List area, from the Device Type drop-down list, choose the device type on which you want to enforce the policy and then click Add.

Here, we used Apple-iPad as a device type for Match Criteria. You can add Apple-iPhone and other Apple devices as well from the Device Type drop-down list.

Note: If you do not want to match any device type then do not configure the Device Type option.

7. To apply the appropriate action, choose from the parameters under the Action area to enforce the policy. Select the AVC profile that should be defined in the last section.

8. User can create more than one Local policy and apply it for student as “student-LP”.

Note: Ensure that the Match Role String is the same as the defined role name on the AAA/Radius Server.

To apply the policy based on a user device, in the Device List area, from the Device Type drop-down list, choose the device type (Apple-iPad) on which you want to enforce the policy and then click Add.

To apply the appropriate action, choose from the parameters under the Action area to enforce the Policy. Select the AVC profile (student-AVC) that should be defined in the last section.

9. Create a default local policy for any other device.

If no other ACL is applied in the Local policy, then any other device, other than Apple-iPad, will be able to access the applications because the final filter function of all policies is Allow all.

In order to block all applications on all devices except Apple-iPad, create a deny all ACL and apply it on the Local Policy and then apply that policy on the WLAN as the last resort. See the configuration examples in the screenshots below.

Create an ACL to deny all IPv4 flow.

Create a Local Policy Block-all and apply the deny all ACL to it, do not choose any devices roles or profiles.

Mapping Policy on WLAN

1. Go to WLANs from the WLC menu bar and click the WLAN ID on which you want the policy to be implemented. From the WLAN edit menu, click the Policy-Mapping tab.

Set the Priority index to any value from 1-16. From the Local Policy drop-down list, choose the policy which you have already created. To apply the policy on the WLAN, click Add. The policy will be mapped to the WLAN and can be seen under Policy Name.

 

2. Add the appropriate policies to Policy-Mapping under WLAN.

3. In the Advanced tab, disable Allow AAA Override if it is enabled.

4. Check if the AAA role is configured properly, that is, role name on the AAA server should match the role string defined in the local policy. The example below is from the Cisco ISE server and Cisco ACS.

ISE:

 

ACS:

Once the client associates to SSID with teacher credentials through Apple iPad, it should be able to access Internet and different applications per its AVC profile configuration. If the user tries to connect from any device other than Apple iPad, then it will not be able to access the Internet.

To verify if the policy is applied from the WLC GUI, go to Monitor > Clients, and then click the Client MAC address.

 

To verify if the policy is applied from WLC CLI prompt, run the following command:

show client detail mac_address and then scroll down to the end to see the applied profile.

To verify if the AVC policy is applied from the WLC:

AVC Profile Name:............................................. teacher-AVC

Try to connect SSID with student credentials, you should see another policy applied (student-AVC) and if the client device is not an Apple-iPad, the user will not be able to access the network.

Native Profiling Limitations

■Wired clients behind the WGB will not be profiled and policy action will not be done.

■Only 16 policies per WLAN can be configured, and globally 64 policies will be allowed.

■Policy action will be done after L2 authentication is complete or after L3 authentication or when the device sends http traffic and gets the device profiled. Due to which certain scenarios profiling and policy actions will happen more than once per client.

■This release will support only IPv4 clients to be profiled.

■No support for WGB wired clients for profiling because http profiling is not supported on WGB wired clients.

Summary

■By default, profiling is disabled on all WLANs

■Each WLAN can have mapped profiling policies configured.

■Each Policy can have matching Role Type, Device Type, EAP type configured and an associated policy index mapped.

■The policy index signifies which policy needs to be matched first.

■The corresponding policy name will be deduced from the policy Index.

■The policy matching will exit at the first policy match and the corresponding policy action attributes will be set per client.

■The order of applying the policies per client will be based on the security type.

Protocol Pack and NBAR Engine Update

Up to release 8.2, NBAR Engine (16) is integrated in WLC for centralized AVC support, which supports Protocol Pack (PP) up to version-12. In release 8.2, the new and improved NBAR Engine 23 and Protocol Pack 14 are introduced. The new versions allow customers to classify 1273 application like Netflix, Jabber, Bittorrent and YouTube and other a lot more reliably with higher precision and less impact on the controller performance. It is also important to note that Protocol Pack 14 requires NBAR engine 23 and will not work with the previous NBAR released version in the prior WLC releases. When PP version 15 is released and posted on CCO, it will operate with NBAR engine 23.

Netflow Support in release 8.2

An IP traffic flow is a sequence of packets passing through a network device with common attributes like source and destination IP address & transport ports, direction, etc. Additional common attributes for wireless flow are SSID, AP MAC. These packets with common attributes are aggregated into flows and exported to the Netflow Collectors. Prior to relase 8.2, controller exported Netflow data was analyzed only by PI (Prime Infrastructure) and wasn't compatible with any third party Netflow collectors.

In release 8.2 nenhanced Netflow records exporter is introduced. New Netflow v9 is sending 17 different data records ( as defined in RFC 3954) to the External 3rd Party Netflow collector such as Stealthwatch and others. Support for the Enhanced Flow Record Data Export was added on the WLC 5520, 8510 and 8540.

Prior to release 8.2 Netflow feature available on the controller sends only the IP address of the client, SSID and Application statistics. While this helps for compatible Netflow collectors like Cisco Prime to show the application statistics, it does not provide the full 5 tuple flow information and is also not compatible with many 3rd party Netflow collectors who expect 5 tuples.

The current netflow record prior to release 8.2 that WLC exports support only the following fields

■applicationTag

■ipDiffServCodePoint

■octetDeltaCount

■packetDeltaCount

■postIpDiffServCodePoint

■staIPv4Address

■staMacAddress

■wtpMacAddress

The newly introduced flow record exporter in the release 8.2 supports the following flow data records

■Application Tag

■Client Mac Address

■AP Mac address

■WlanID

■Source IP

■Dest IP

■Source Port

■Dest Port

■Protocol

■Flow Start Time

■Flow End Time

■Direction

■Packet count

■Byte count

■VLAN Id – Mgmt/Dyn

■TOS - DSCP Value

■Dot1x username

Netflow Deployment Considerations

■WLC supports only one monitor and exporter.

■WLC will support only one type of Netflow record globally per controller.

■Flow records are exported directly and will not be shown on the controller.

■Application visibility statistics present today will continue on the controller.

■Change to monitor parameters will required the WLAN to be disabled and enabled.

■The new record will be supported on 8510, 5520 and 8540 controllers only.

■2500, 5508, 7500 and WiSM2 controllers will not be supported.

■Netflow statistics are sent at an interval of 30 seconds (Not user configurable. Current value is 90 seconds).

■Netflow record will be sent even for the unclassified applications with new flow record.

■Netflow will be sent on enabling AVC on that WLAN.

■IPv6 traffic is not supported in Netflow in release 8.2.

■Netflow sending initial template will be sent from Control plane.

■Netflow export on service port is not supported.

Obtaining Stealthwatch Software for Evaluation Purposes

The software is available for web download on the URL as indicated below: https://www.Stealthwatch.com/stealthwatch-evaluation-application

1. Sign up for Stealth Watch Evaluation and download the software

Netflow Configuration on the WLC

Prior to release 8.2 Netflow configuration on WLC was done by associating the fixed record ipv4_client_app_flow_record to the Netflow monitor. Now along with this we will support a new fixed record called ipv4_client_src_dst_flow_record the same will be allowed in cli and GUI at the places shown below.

Note: Since only one netflow exporter is present per controller, it has to be between the old and new record formats.

Configuration from CLI

Configuration Change

Configuration steps from CLI

Debug commands

Configuration using WebUI

Screen shots below illustrate examples of the Stealthwatch Netflow Collector VM on the USC box with IP Address 10.10.105.22 and it is listening on UDP port 2055.

1. From WLC main menu configure a Netflow Exporter by going to Wireless> Netflow> Exporter. Click New.

2. Configure an Exporter Name, Exporter IP and Port Number, then click Apply.

3. Now, we will create a Flow monitor for the Netflow Exporter which we created above. Under Netflow, go to Monitor. Click New..

4. Create a monitor with the name "Stealthwatch " and click Apply as shown below.

5. Click on the created Monitor name.

6. Select ' Netflow Collector ' from the Exporter Name drop down menu and choose ' ipv4_client_src_dst_flow_record ' from the Record Name list. Click Apply.

User should see the following under Wireless> Netflow> Monitor

7. Browse to the WLAN on which we need to enable AVC and Netflow Monitor. From the WLAN edit parameters, go to QoS tab and check Application Visibility box. Then select the Netflow Monitor and click Apply.

Netflow Reporting

Stealthwatch Netflow reporting setup comprises of a flow collector and a central management console.

Stealthwatch FlowCollector collects data from various sources (in this case Wireless Lan Controller), analyzes them, creates a profile for normal activity and generates an alarm (to the SMC) for any activity that falls outside of the normal profile.

SMC manages, coordinates, and configures different components of the system through a web browser. It offers centralized management and reporting for up to 25 flow collectors with graphical charts for visualizing traffic.

Examples below illustrate FlowCollector residing at 10.10.105.22 (configured on the WLC above) and SMC at 10.10.105.21.

1. Log into SMC with username and password.

2. Click on "Launch SMC" from the dashboard. It will prompt you to download the Application " launch_512 ".Save it locally and Launch it as shown above.

3. Follow the steps as shown below when pop up window appears.

4. Continue Loading the Stealth Watch Monitor.

5. Finally Login to Stealthwatch Collector Monitor with credentials as per your setup.

6. From the dashboard, right click Exporters-> <Controller IP> -> Flows-> Flow Table to view client flows.

7. You will see multiple client flows here. You can filter the flows on various attributes by right clicking against a column name and selecting parameter/s as shown below. In the example illustrated below, WLC with IP address 10.10.10.2 is selected with Application (NBAR) attribute.

Note: In order to see the flows please make sure the clients are connected to the AVC and Netflow enabled SSID.

If user is connected with dot1x credentials, they will also be visible on the Stealthwatch flow table dashboard

Note: If you are planning to upgrade the Protocol Pack file on the controller the latest Protocol Pack can be found at the link below

https://software.cisco.com/download/home/282600534/type/284509011/release/24.0.0

.

AVC in FlexConnect Mode ver 8.3

In release 8.3,the Protocol Pack and the NBAR engine got upgraded for Flex Connect Applications and now supports Protocol Pack 14 and NBAR engine 23 with a total support of the 1327 applications.

For more information, see http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-1/Flex-7500/Flex_7500_DG.html#pgfId-131717.

Protocol Pack and NBAR Engine Update in rel 8.3

Up to release 8.3 NBAR Engine 23 is integrated in WLC for centralized AVC support, which supports Protocol Pack (PP) version-16. In release 8.3, the new and improved NBAR Engine 23 and Protocol Pack 19.1 are introduced. The new versions allow customers to classify up to1317 application like Skype, Jabber and other a with lot more reliability and higher precision and less impact on the controller performance. It is also important to note that Protocol Pack 19.1 requires NBAR engine 23 and will not work with the previous NBAR released version in the prior WLC releases. When PP version 19.1 is released and posted on CCO, it will operate with NBAR engine 23 or higher.

Configurations Steps for AVC Enhancement

There is really no configuration steps required to load the latest NBAR engine or the protocol pack.

Zoom Calling is now showing in the PP 37.

Wi-Fi Calling is also part of the PP37.

Managing 8.8 AVC Features through CLI

CLI Output :

Default DSCP Value for AVC Profile Feature Overview

Prior to rel 8.8 with AVC enabled, we can no override all applications DSCP values only for Application flows configured on the AVC profile. Furthermore, the AVC profile can contain maximum 32 Applications rules.

For a flow where a rule is not configured in the AVC Profile, NO action is performed & DSCP is left intact. As it is, the AVC can’t be used as PEP (Policy Enforcement Point).

For Managed Service, to control and rewrite DSCP values (example with DSCP 0) for all flows that are not presented on the AVC profile is not possible.

The new AVC enhancement allows a “default-class” rule to override the DSCP values for all application flows where AVC Rule is not configured. It is more like last rule with Any/Any conditions. The goal is to protect the network from all flows with unwanted/controlled DSCP values.

AVC at present supports Marking, Rate Limiting or Drop for any application it recognizes. AVC supports 32 Rules. For any applications which are not configured as part of these rules, no action will be taken.

For local mode, these rules are plumbed down to Data Plane. At the Data Plane, for those applications action will be taken including DSCP marking.

As part of the new feature in rel 8.8, “default rule” can be configured as part of the 32 Rules supported.

For any application which doesn’t match the existing rules, this “default rule” will be applied.

For Flex Connect AVC, we send App Name in the TLV Type TLV_FLEX_AVC_CLASS_MAP_APP_NAME_PAYLOAD along with APP ID in the TLV Type TLV_FLEX_AVC_CLASS_MAP_APP_ID_PAYLOAD.

In rel 8.8 enhancement will be made to support “default-class” Application Name and APP ID while sending to AP. AP also has to handle these values and correspondingly update the class map.

AVC Default DSCP Value Limitations in rel 8.8

■Supported only Marking, Rate Limit or Drop is not supported.

■Default DSCP will work only when AVC is enabled.

■32 Rules per profile supported, including “Default-class” Rule. If default Rule is configured than the user can configure only 31 Rules.

■“default-class" application name configured will not be shown in stats pages/CLI output.

■It will not be supported to Multicast and Broadcast flows.

■At present AVC doesn’t support IPv6

■AVC doesn’t allow cascading for Rules, means for same flow we can’t have Rate Limiting and Marking. Hence if for a flow where Rate Limiting is done, for that flow “default” Marking will not happen.

Note: “default-class” setting will overwrite all DSCP values for all not configured application when the profile is applied to the WLAN.

Configurations Steps for Default DSCP setting

Follow steps for creating, configuring AVC profiles and applying them to the WLAN as desribed in the previous sections of this deployment guide and then after creating AVC profiles please follow the steps below.

1. After creating an AVC profile you should have something as in the example below:

2. To add a default-class application, create a new rule from application group "other" and application name "class-default" and at the same time select a DSCP action desired or configure a custom DSCP value as shown in the example below.

Note: Same applies to the AVC profiles created for the Flex Connect mode.

3. Apply the newly created rule to the Profile and you will see it appear now in the profile.

The existing application list will be appended with “class-default” application.

GUI will automatically show it.

4. Apply the newly created profile to the WLAN, as shown in the example below the profile created applied to the WLAN “avctest”

Default DSCP CLI Configuration command:

Create an AVC profile with application name “class-default”

Show command Changes :

Example Config Command :

 

AVC Facts and Limitations

AVC on the FlexConnect AP can classify and take action on 1000+ different applications.

■The protocol pack running on the FlexConnect APs is different from the one running on the WLC.

■AVC stats on the GUI are displayed for the top 10 applications by default. This can be changed to top 20 or 30 applications as well.

■Intra FlexConnect Group roaming support.

■IPv6 traffic cannot be classified.

■AAA override of AVC profiles is not supported.

■Multicast traffic is not supported by AVC application.

■Netflow export for FlexConnect AVC is not supported

Configuring Application Visibility

To configure the application visibility, perform these steps:

1. Open a web browser on the wired laptop, and then enter your WLC IP Address.

2. Create an OPEN WLAN with naming convention, for example, “FlexDemo”.

3. Enable FlexConnect Local Switching on the WLAN and then click Apply.

4. Make sure that the APs connected to this WLAN are among the list of supported access points for this feature.

5. Convert the AP to FlexConnect mode by selecting FlexConnect in the AP Mode drop-down menu, and then click Apply. The mode changes to FlexConnect without a reboot.

6. Create a FlexConnect Group and add the AP to the FlexConnect Group. In the following example, “FlexGroup” is the FlexConnect Group and the access point AP3600 is added to it.

7. Applications that can be identified, classified, and controlled are listed under Wireless > Application Visibility and Control > FlexConnect AVC Applications. The access points support Protocol Pack version 8.0 and NBAR engine version 16.

8. Create an AVC profile under Wireless > Application Visibility and Control > FlexConnect AVC Profiles > New with name “Drop_youtube”. And then Click Apply.

The AVC profile is created with the new name “Drop_youtube”.

9. Click the Profile name and then click Add New Rule. Select the Application Group, Application Name, and Action, and then click Apply.

10. Verify that the rule is added as shown in the following figure.

The status of the FlexConnect AVC profile at this point is Modified.

11. Select the profile and click Apply for the profile to be applied and to take effect.

12. Select the profile and click Apply for the profile to be applied and to take effect.

The status of the FlexConnect AVC profile is changed to Applied.

13. Enable Application Visibility on the FlexConnect group under Wireless > FlexConnect Group > FlexConnect Group name > WLAN AVC Mapping by selecting the WLAN ID and choosing Enable from the drop-down menu.

14. Apply the FlexConnect AVC profile by selecting the profile created in the previous set from the Flex AVC Profiledrop-down menu. Click Add and then click Apply.

15. Once AVC is enabled on the FlexConnect Group, from the associated wireless client, start different types of traffic using the applications (already installed) such as Cisco Jabber/WebEx Connect, Skype, Yahoo Messenger, HTTP, HTTPS/SSL, Microsoft Messenger, Ping, Trace route, and so on.

Once traffic is initiated from the wireless client, visibility of different traffic can be observed on a per FlexConnect Group and per client basis. This provides the administrator a good overview of the network bandwidth utilization and type of traffic in the network per client and per branch site

16. To check the visibility globally for all WLANs on a FlexConnect Group, click Monitor > Applications > FlexConnect > FlexConnect Groups and then select the FlexConnect group created earlier.

The following screen is visible which lists aggregate data for the top 10 applications running on that particular FlexConnect group.

This page provides more granular visibility per FlexConnect Group and lists the top 10 applications in the last 90 seconds, as well as cumulative stats for the top 10 applications. You can view upstream and downstream statistics individually per FlexConnect Group from the same page by clicking the Upstream and Downstream tabs.

Note: The number of applications that are displayed on this page can be increased to 20 or 30 by modifying the Max Number of Records field on this page. The default value is 10.

17. To have more granular visibility of the top 10 applications per client on a particular locally switched WLAN where AVC visibility is enabled, click Monitor > Applications > FlexConnect Group > FlexConnect Group name > Clients. Then, click any individual client MAC entry listed on that page.

After clicking on an individual client MAC entry, the client details page appears.

This page provides further granular stats per client associated on locally switched WLANs, where AVC visibility is enabled on the WLAN itself or on the FlexConnect Group as in this example. The page lists the top 10 applications in last the 90 seconds as well as cumulative stats for top 10 applications.

18. You can view upstream and downstream stats individually per client from the same page by clicking the Upstream and Downstream tabs

. Note: The number of applications that are displayed on this page can be increased to 20 or 30 by modifying the Max Number of Records Field on this page. The default value is 10.

19. You can clear the AVC stats for the particular client by clicking the Clear AVC Stats button.

Now, if you open YouTube, from wireless clients, you will observe that client cannot play any YouTube videos. Also, if applicable, open your Facebook account and try to open any YouTube video. You will observe YouTube videos cannot be played. Because YouTube is blocked in the FlexConnect AVC profile, and AVC profile is mapped to WLAN on the FlexConnect Group. You cannot access YouTube videos via browser, or even via YouTube application or from any other website.

. Note: If your browser was already open with YouTube, refresh the browser for the AVC profile to take effect.

Appendix

VOD Reference

Cisco AVC - Per User Application Control: http://www.youtube.com/watch?v=ESg53o3ufDQ&feature=youtu.be

Web Links and Terminology

Cisco WLAN Controller Information:

http://www.cisco.com/en/US/products/hw/wireless/products.html

http://www.cisco.com/cisco/web/support/index.html

Cisco Prime Management Software Information:

http://www.cisco.com/en/US/products/ps11686/index.html

Cisco MSE Information:

http://www.cisco.com/en/US/products/ps9742/index.html

Cisco LAP Documentation:

http://www.cisco.com/en/US/products/ps10981/index.html