Application Visibility and Control Feature Deployment Guide
Available Languages
Table of Contents
Application Visibility and Control Feature Deployment Guide
Application Visibility and Control Release Update
Application Visibility and Control—Phase 1
Application Visibility and Control–Phase 2
AVC and QoS Interaction on the WLAN
AVC Operation with Anchor/Foreign Controller’s Setup
Loading AVC Protocol Pack–Phase 2
Configure Application Visibility
Configure NBAR NetFlow Monitor
AVC—Phase 3 in CUWN Release 8.0
AAA AVC Profile Override for Clients
Steps to Configure Application Visibility Per User Role
AAA Configuration for AVC Profile
Application Rate Limiting Through AVC
AVC Profiles Attached to Local Policies
Introduction to Profiling and Policy Engine on the WLC
Profiling and Policy Configuration
Creating Policies on the WLAN from the WLC GUI
Application Visibility and Control Release Update
Application Visibility and Control—Phase 1
Network Based Application Recognition (NBAR) provides application-aware control on a wireless network and enhances manageability and productivity. It also extends Cisco’s Application Visibility and Control (AVC) as an end-to-end solution, which gives a complete visibility of applications in the network and allows the administrator to take some action on the same.
NBAR is a deep-packet inspection technology available on Cisco IOS based platforms, which supports stateful L4 - L7 classification. NBAR2 is based on NBAR and has extra requirements such as having a Common Flow Table for all IOS features which use NBAR. NBAR2 recognizes application and passes on this information to other features like QoS, NetFlow and Firewall, which can take action based on this classification.
The key use cases for NBAR are capacity planning, network usage base lining and better understanding of what applications are consuming bandwidth. Trending of application usage helps network admin to plan for network infrastructure upgrade, improve quality of experience by protecting key applications from bandwidth-hungry applications when there is congestion on the network, capability to prioritize or de-prioritize, and drop certain application traffic.
NBAR is supported on 2500, 5500, 7500, 8500 and WiSM2 controllers on Local, Mesh, and Flex Mode APs (for WLANs configured for central switching only).
NBAR Supported Feature
NBAR as a feature can perform the following tasks:
1.
Classification–Identification of Application/Protocol.
2.
3.
Application Visibility and Control–Phase 2
In phase two of the AVC support for Protocol Packs has been added. Protocol packs are software packages that allow update of signature support without replacing the image on the Controller. You have an option to load protocol packs dynamically when new protocol support is being added. There are two kinds of Protocol Packs—Major and Minor:
- Major protocol packs include support for new protocols, updates, and bug fixes.
- Minor protocol packs typically do not include support for new protocols.
- Protocol packs are targeted to specific platform types, software versions and releases separately. Protocol Packs can be downloaded from CCO using the software type “NBAR2 Protocol Pack”.
Protocol packs are released with specific NBAR engine versions. For example, WLC 7.5 has NBAR engine 13, so protocol packs for it are written for engine 13 (pp-unified-wng-152-4.S-13-4.1.1.pack). Loading a protocol pack can be done if the engine version on the platform is same or higher than the version required by the protocol pack (13 in the example above). Therefore for example – PP4.1 for 3.7 (version 13) can be loaded on top of 3.7 (version 13) and 3.8, but PP4.1 for 3.8 cannot be loaded on top of 3.7. It is strongly recommended to use the protocol pack that is the exact match for the engine.
For AVC phase 2, protocol packs can be downloaded directly from CCO–Protocol Pack 4.1.1 for engine XE 3.7. The protocol pack file “pp-AIR-7.5-13-4.1.1.pack” (Format: pp-AIR-{release}-{engine version}-M.m.r.pack) will be located in the same location with the controller code version 7.5. This is the only tested and supported protocol pack released with controller software version 7.5.
Note
Complete list of the protocols supported in the release posted at the link below
http://www.cisco.com/en/US/docs/ios-xml/ios/qos_nbar/prot_lib/config_library/
nbar-prot-pack-library.html
Note
NBAR/AVC Facts
- NBAR/AVC phase 2 on WLC can classify and take action on 1054 different applications.
- Two actions, either DROP or MARK is possible on any classified application.
- Maximum 16 AVC profiles can be created on a WLC.
- Each AVC profile can be configured with a maximum 32 rules.
- Same AVC profile can be mapped to multiple WLANs. But one WLAN can have only one AVC profile.
- Only 1 NetFlow exporter and monitor can be configured on WLC.
- NBAR/AVC stats are displayed only for top 10 applications on GUI. CLI can be used to see all applications.
- NBAR/AVC is supported on WLANs configured for central switching only.
- If AVC profile mapped to WLAN has a rule for MARK action, that application will get precedence as per QOS profile configured in AVC rule overriding the QOS profile configured on WLAN.
- Any application, which is not supported/recognized by NBAR engine on WLC, is captured under the bucket of UNCLASSIFIED traffic.
- IPv6 traffic cannot be classified.
- AAA override of AVC profiles is not supported.
- AVC profile can be configured per WLAN and cannot be applied per user basis.
- NBAR/AVC is not supported in vWLC and SRE WLC.
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:
1.
2.
3.
4.
1.
2.
3.
4.
5.
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.
Loading AVC Protocol Pack–Phase 2
Loading of Protocol Packs is supported only via the command line interface. The command to load a protocol pack is shown in the example below:
(Cisco Controller) >transfer download datatype avc-protocol-pack
(Cisco Controller) >transfer download start
Mode.............................. FTP
Data Type......................... AVC Protocol Pack
FTP Server IP..................... A.B.C.D
FTP Server Port................... 21
FTP Path.......................... /
FTP Filename..................... pp-unified-wng-152-4.S-13-4.1.1.pack
FTP Username...................... cisco
FTP Password...................... *********
Starting transfer of AVC Protocol Pack
Are you sure you want to start? (y/N)
The download process might take some time.
Use the show command to view the currently loaded protocol pack
(Cisco Controller) >show avc protocol-pack version
AVC Protocol Pack Name: Advanced Protocol Pack
AVC Protocol Pack Version: 1.0Use the show command to view the current Nbar2 Engine Version
(Cisco Controller) >show avc engine versionBefore installing the Protocol Pack the default pack will show as follow:
After installing the Protocol Pack the AVC pack will show as version 4.10001:
Configure Application Visibility
1.
2.
To enable Application visibility, click WLAN ID and then click the QOS tab and check the enable option for Application Visibility and click Apply.
3.
As mentioned above Visibility of traffic can be monitored:
4.
Note
5.
Now click the individual WLAN ID and the below screen will be visible which will list aggregate data for the top ten applications running on that particular WLAN.
Note
6.
After clicking on an individual client MAC entry listed on the above page, the client details page will open which will have two tabs; one for general information and another tab with the name AVC Statistics. Click the AVC Statistics tab to see the NBAR statistics for the top ten applications for that particular client.
Note
Configure AVC Profile
1.
a.
b.
2.
Note
3.
4.
5.
6.
7.
Note
8.
9.
As discussed in previous steps 6, 7 and 8, click the AVC profile name to create rules for the profile. Click Add New Rule.
Select Application group from the first drop-down and Application name as Webex from second drop-down. Then, configure Action as MARK and select QOS profile as Platinum and the click Apply.
After Apply is clicked, the action rule will be created and displayed as captured in below screen. Click Add New Rule on same page to create another rule to MARK another application “Http”.
Create another rule in the same profile by just clicking Add New Rule on the same page. Select Application group from the first drop-down and Application name as http from second drop-down. Then, configure Action as Mark with QOS profile as Bronze. Then click Apply.
After Apply is clicked, the action rule will be created and displayed as captured in below screen.
Note
The administrator is also flexible while configuring Action as MARK to choose the Differentiated Services Code Point (DSCP) value as Custom instead of selecting “Platinum/Gold/Silver/Bronze”. Once Custom is selected as DSCP value, a text filed will be visible where admin can enter a custom DSCP value in range of 0 - 63.
10.
11.
Note
12.
13.
Because YouTube is blocked in the AVC profile and AVC profile is been mapped to WLAN, clients will not be able to access YouTube videos via browser or even via YouTube application or from any other website.
Note
14.
15.
16.
Although the WLAN in this example is mapped to the default QOS profile SILVER, the AVC profile has been created and mapped to this WLAN to MARK application WebEx and HTTP with a different QOS profile. Traffic for application WebEx will be marked with PLATINUM profile and traffic for all HTTP application will be marked with BRONZE profile. Rest of the applications that do not match any rules in the AVC profile; will be marked with QOS profile configured on WLAN i.e. SILVER in this example.
17.
After clicking on the individual client MAC entry listed on the above page, the client details page will open which will have two tabs; one for general information and another tab with name AVC Statistics. Click the AVC Statistics tab and further click the UPSTREAM tab to notice the MARKING operation of the AVC profile.
Notice the above output and make sure the WebEx application is getting OUT DSCP value as 46 because the WebEx application is been configured with Platinum QOS profile and HTTP application is getting OUT DSCP value as 10 because the HTTP application is been configured with Bronze profile.
Configure NBAR NetFlow Monitor
A NetFlow monitor can also be configured on the WLC to collect all the stats generated on a WLC and these can be exported to the NetFlow collector. In the following example, Cisco Performance Application Manager (PAM) is shown as being used as a NetFlow collector. PAM is a licensed application running on Cisco Prime Infrastructure.
1.
2.
Note
3.
4.
5.
Note
6.
7.
8.
9.
10.
11.
Note
12.
13.
AVC—Phase 3 in CUWN Release 8.0
In this release, a lot of enhancement has been made on the AVC feature set that includes the following:
- 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 with Protocol Pack 9.0 and NBAR Engine release 3.1.
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
Step 1
Click the Advanced tab and enable “AAA Override” as shown below.
Step 2
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.
Step 1
Step 2
Step 3
Step 4
Note
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.
Step 5
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.
Step 6
Step 7
Step 8
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 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.
For example: Student or Employee
b.
For example: Windows machine, Smart phone, Apple device such as iPad, iPhone and so on.
c.
d.
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
Step 1
Step 2
Creating Policies on the WLAN from the WLC GUI
Step 3
Step 4
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
Step 5
Step 6
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.
Step 7
Step 8
Note
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.
Step 9
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
Step 1
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.
Step 2
Step 3
Step 4
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-AVCTry 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.
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
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)