BYOD Design Guide

Cisco Unified Access (UA) and Bring Your Own
Device (BYOD) CVD

Revised: August 28, 2014
Building Architectures to Solve Business Problems
ii
Cisco Validated Design
About the Authors
About the Authors
Zeb Hallock, Technical Marketing Engineer, Systems Development

Unit, Cisco Systems
Zeb Hallock is in the Enterprise Systems Engineering group of Cisco, focusing on digital media systems. He is also pursuing creation and development of future-based collaboration systems, holding two patents in the field. He has been with Cisco for 10
years working on enterprise system testing, system design and testing of H.323 based
video conferencing, and network infrastructure. He has also been a specialist working
on Cisco Unified IP Contact Center Cisco Unified MeetingPlace. Before Cisco he
worked as a consultant designing and implementing local and wide area networks.
Zeb Hallock
John Johnston, Technical Marketing Engineer, Systems Development

Unit, Cisco Systems
John Johnston is a Technical Marketing Engineer in the Systems Development Unit
(SDU) at Cisco. He has been with Cisco for 10 years, with previous experience as a
network consulting engineer in Cisco's advanced services group. Prior to joining
Cisco, he was a consulting engineer with MCI's Professional Managed Services group.
Johnston has been designing or troubleshooting enterprise networks for the past 15
years. In his spare time, he enjoys working with microprocessor-based electronic projects including wireless environmental sensors. Johnston holds CCIE certification
5232. He holds a bachelor of science degree in electrical engineering from the University of North Carolina's Charlotte campus.
John Johnston
Fernando Macias, Solutions Architect, Systems Development Unit,

Cisco Systems
Fernando Macias is a Solutions Architect in the Systems Development Unit (SDU),
focusing on solutions for the enterprise market segment. Fernando has been with
Cisco for over 13 years and has developed networking solutions that include Video,
Security, and Content Delivery products. Fernando was also a member of Cisco's
Advanced Services, where he provided network design support to large enterprise
companies and a Systems Engineer for Cisco's commercial region. Prior to joining
SDU, Fernando focused on Cloud Computing and Security, with the goal of leading
Public Sector customers in their path to Cloud Computing.
Fernando Macias
In addition to Masters Degrees in Technology Management and Software Engineering,

Fernando holds his Cisco CCIE certification in Routing and Switching.
Cisco Validated Design
iii
About the Authors
Roland Saville, Technical Leader, Systems Development Unit, Cisco Systems
Roland Saville
Roland Saville is a technical leader for the Systems Development Unit (SDU) at Cisco,
focused on developing best-practice design guides for enterprise network deployments.
He has more than 15 years of experience at Cisco as a systems engineer, consulting systems engineer, technical marketing engineer, and technical leader. During that time, he has
focused on a wide range of technology areas including the integration of voice and video
onto network infrastructures, network security, wireless LAN networking, RFID, and energy
management. He has also spent time focusing on the retail market segment. Prior to Cisco,
he spent eight years as a communications analyst for Chevron Corporation. Saville holds a
bachelor of science degree in electrical engineering from the University of Idaho and a master of business administration degree from Santa Clara University. He co-authored the book
"Cisco TelePresence Fundamentals" and has eight U.S. patents.
Srinivas Tenneti, Technical Marketing Engineer, Systems Development

Unit, Cisco Systems
Srinivas Tenneti is a Technical Marketing Engineer in the Systems Development Unit (SDU)
at Cisco, responsible for the design and architecture of security components for the BYOD
project. He has more than 11 years of experience at Cisco where has worked in development, System Testing, and in Enterprise design and architecture. In the last 5 years Srinivas
has worked on the design and architecture of GETVPN, DMVPN, Branch Architecture, Internet Edge, and PKI as a service for VPN protocols. Srinivas has co-authored the book PKI
Uncovered: Certificate-Based Security Solutions for Next Generation Networks.
Srinivas Tenneti
iv
About the Authors
Mike Jessup, Technical Lead Engineer/Architect, Systems Development

Unit, Cisco Systems
Mike Jessup
Mike Jessup joined Cisco in 1996 and is a Technical Lead Engineer/Architect within Ciscos
Systems Development Unit (SDU). Mikes primary focus is identifying and qualifying BYOD
system architectures and solutions as well as future trends and working with solutions engineers in incorporating, validating, and documenting these systems in Cisco Validated
Designs. Prior to joining SDU in November of 2011, Mike worked in the US Sales Organization as an Enterprise System Engineer specializing in Routing and Switching, Data Center,
Application Optimization, and Network Management. Prior to joining Cisco, Mike worked in
positions as a Field Engineer and Systems Engineer in various Information Systems companies and Partner organizations since 1982.
Suyog Deshpande, Technical Marketing Engineer, Systems Development

Unit, Cisco Systems
Suyog Deshpande
Suyog Deshpande is a Technical Marketing Engineer within Systems Development Unit

(SDU) at Cisco Systems, focussing on converged wired and wireless access products.
Suyog has been with Cisco for 9 years with previous experience in the Wireless Networking
Business Unit, where he focussed on RF systems and converged access products. Before
Cisco, Suyog held various positions designing and deploying large scale wireless networks
and working with spectrum intelligence and analyzer products.
Tim Szigeti, Technical Leader, Systems Development Unit, Cisco Systems

Tim Szigeti is a technical leader in the Systems Design Unit (SDU) at Cisco Systems, where
his role is to design network architectures for BYOD solutions. He has also specialized in
Quality of Service technologies for over a dozen years, during which he has authored many
technical papers, design guides, as well as the Cisco Press Books: End-to-End QoS Network Design and Cisco TelePresence Fundamentals. Szigeti holds CCIE certification 9794
and holds a bachelor of commerce degree with a specialization in management information
systems from the University of British Columbia.
Tim Szigeti
About Cisco Validated Design (CVD) Program

The CVD program consists of systems and solutions designed, tested, and documented to facilitate faster, more reliable, and more predictable customer deployments. For more information visit
http://www.cisco.com/go/designzone.
ALL DESIGNS, SPECIFICATIONS, STATEMENTS, INFORMATION, AND RECOMMENDATIONS (COLLECTIVELY, "DESIGNS") IN THIS MANUAL ARE PRESENTED "AS IS," WITH ALL FAULTS. CISCO AND ITS SUPPLIERS DISCLAIM ALL WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE WARRANTY OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING
FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS
SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES,
INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF
THE USE OR INABILITY TO USE THE DESIGNS, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED
OF THE POSSIBILITY OF SUCH DAMAGES.
THE DESIGNS ARE SUBJECT TO CHANGE WITHOUT NOTICE. USERS ARE SOLELY RESPONSIBLE FOR
THEIR APPLICATION OF THE DESIGNS. THE DESIGNS DO NOT CONSTITUTE THE TECHNICAL OR
OTHER PROFESSIONAL ADVICE OF CISCO, ITS SUPPLIERS OR PARTNERS. USERS SHOULD CONSULT
THEIR OWN TECHNICAL ADVISORS BEFORE IMPLEMENTING THE DESIGNS. RESULTS MAY VARY
DEPENDING ON FACTORS NOT TESTED BY CISCO.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the
University of California, Berkeley (UCB) as part of UCBs public domain version of the UNIX operating system. All rights reserved. Copyright 1981, Regents of the University of California.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and
other countries. To view a list of Cisco trademarks, go to this URL: http://www.cisco.com/go/trademarks.
Third-party trademarks mentioned are the property of their respective owners. The use of the word partner
does not imply a partnership relationship between Cisco and any other company. (1110R).
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be
actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of
actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
Cisco Bring Your Own Device (BYOD) CVD
2014 Cisco Systems, Inc. All rights reserved.
vi
Contents
PART
Introduction
Preface
CHAPTER
vi
BYOD Solution Overview

Introduction
1-1
1-1
BYOD Market Landscape 1-1

BYOD and the Enterprise Network 1-2
Role of MDM in the Enterprise Network
User Need and Role of IT 1-3
Protecting Data and Loss Prevention
1-3
1-4
Challenges for End Users 1-4

Key Advantages of the Cisco BYOD Solution
PART
1-4
BYOD Design Overview
CHAPTER
Summary of Design Overview
CHAPTER
Cisco BYOD Solution Components
2-1
3-1
Cisco Wireless Infrastructure 3-3

Cisco Aironet Access Points 3-4
Cisco Wireless LAN Controllers 3-5
Cisco Converged Access Switches 3-6
Cisco Mobility Services Engine 3-6
Cisco Identity Services Engine 3-7
Cisco Adaptive Security Appliance 3-7
Cisco AnyConnect Client 3-8
Cisco Integrated Services Routers 3-8
Cisco Aggregation Services Routers 3-8
Cisco Catalyst Switches 3-8
Cisco Nexus Series Switches 3-8
Cisco Prime Infrastructure 3-9
Secure Access to the Corporate Network 3-9
Certificate Enrollment and Mobile Device Provisioning
CHAPTER
BYOD Use Cases
3-10
4-1
Enhanced AccessPersonal and Corporate Devices
4-2
vii
Contents
Limited AccessCorporate Devices

Advanced AccessMDM Posture
Basic AccessGuest-Like
CHAPTER
4-3
4-4
4-5
Campus and Branch Network Design for BYOD
5-1
Campus Network Design 5-1

Centralized (Local Mode) Wireless Design 5-1
Security Group Tag Overview 5-3
ACL Complexity and Considerations 5-4
Security Group Tag 5-4
SGT Deployment Scenarios in this CVD 5-5
Campus Wired Design 5-7
Converged Access Campus Design 5-8
Campus Migration Path 5-11
Initial Overlay Model 5-12
Centralized/Local Mode Only 5-12
Hybrid Converged Access and Local Mode 5-14
Full Converged Access 5-16
Link Aggregation (LAG) with the CT5508 WLC 5-17
Wireless LAN Controller High Availability 5-20
Cisco Unified Wireless Network (CUWN) Controllers 5-22
1:1 Active/Standby Redundancy with AP and Client SSO 5-22
Configuring 1:1 Active/Standby Redundancy with AP and Client SSO
Converged Access Controllers 5-30
Catalyst Switch Stack Resiliency 5-30
Cisco CT 5670 Wireless Controller 1:1 Stack Resiliency 5-31
Branch Wide Area Network Design 5-32
Branch WAN Infrastructure 5-32
Branch WAN Bandwidth Requirements
Encryption Requirement 5-34
Transport 5-34
5-33
Branch LAN Network Design 5-34

FlexConnect Wireless Design 5-35
Branch Wired Design 5-36
Converged Access Branch Design 5-37
CHAPTER
Mobile Device Managers for BYOD
6-1
Cisco ISE 1.2 with MDM API Integration
6-1
MDM Deployment Options and Considerations

viii
6-2
5-26
Contents
On-Premise 6-4
Cloud-Based 6-5
Enterprise Integration Considerations 6-6
Corporate Directory Services Integration 6-6
Corporate Certificates Authority and Public Key Infrastructure Integration
Email Integration 6-6
Content Repository Integration 6-6
Management Integration 6-7
Integration Servers 6-7
CHAPTER
Application Considerations and License Requirements for BYOD
7-1
Quality of Service 7-1

CUWN Wireless LAN Controller QoS 7-2
Rate Limiting on CUWN Wireless Controllers 7-5
Converged Access QoS 7-5
Port-Level QoS Policies 7-8
Catalyst 3850 Series Switch 7-8
Cisco CT5760 Wireless LAN Controller 7-15
SSID-Level QoS Policies 7-18
Campus and Branch Considerations 7-19
Downstream SSID Policy Configuration Examples 7-20
Client-Level QoS Policies 7-26
Classification and Marking Policy 7-31
Classification, Marking, and Policing PolicyCatalyst 3850 Only
Static Application of Client-Level Policy 7-32
Dynamic Application of Client-Level Policy 7-34
Mobility Traffic QoS Policy 7-35
Application Visibility and Control (AVC)
PART
7-31
7-36
Cisco Jabber 7-43

Cisco Jabber Clients and the Cisco BYOD Infrastructure
Use Case Impact on Jabber 7-44
Other Jabber Design Considerations 7-44
License Requirements for BYOD Solution
6-6
7-44
7-45
Configuring the Infrastructure
ix
Contents
CHAPTER
Summary of Configuring the Infrastructure
CHAPTER
BYOD Wireless Infrastructure Design
8-1
9-1
CampusUnified Wireless LAN Design 9-1

Centralized CampusDual SSID Design 9-2
Centralized CampusSingle SSID Design 9-8
Centralized CampusPolicy Enforcement using TrustSec
9-9
BranchUnified Wireless LAN Design 9-9

FlexConnect Wireless LAN Design 9-9
Branch Wireless IP Address Design 9-11
FlexConnect BranchDual SSID Design 9-13
Dual SSIDCentral Switching Provisioning 9-17
Dual SSIDLocal Switching Provisioning 9-19
FlexConnect BranchSingle SSID Design 9-23
FlexConnect Access Point Configuration 9-25
FlexConnect Groups 9-27
FlexConnect VLAN Override 9-31
CampusConverged Access Design 9-31
Campus Converged AccessDual SSID Design 9-32
Campus Converged AccessSingle SSID Design 9-36
Campus Converged AccessMobility 9-37
BranchConverged Access Design 9-40
Branch Converged AccessDual SSID Design 9-40
Branch Converged AccessSingle SSID Design 9-42
CHAPTER
10
Identity Services Engine for BYOD

Identity Certificate for ISE
10-1
10-2
Network Device Definition within ISE

ISE Integration with Active Directory
10-2
10-3
Guest and Self-Registration Portals 10-4

ISE Using Certificates as an Identity Store
Identity Source Sequences 10-6
SCEP Profile Configuration on ISE 10-7
10-6
Authentication Policies 10-8

Authentication Policy for Wireless 10-10
Client Provisioning 10-11
Client Provisioning ResourcesApple iOS and Android 10-12
Client Provisioning PolicyApple iOS and Android Devices 10-13
Contents
Client Provisioning ResourcesMac OS 10-13

Client Provisioning Policy for Mac OS DevicesWireless 10-15
Client Provisioning Policy for Windows DevicesWireless/Wired
Profiling 10-18
Enabling the DHCP and RADIUS Probes
Profiling Android Devices 10-21
Logical Profiles 10-22
10-17
10-19
Authorization Policies and Profiles 10-23

Authorization Profiles 10-24
Wireless CWA Authorization Profile for Dual SSID Provisioning 10-24
Dual SSID Provisioning Authorization Rule 10-27
Wireless NSP Authorization Profile for Single SSID Provisioning 10-28
Single SSID Provisioning Authorization Rule 10-30
Certificate Authority Server 10-31
NDES Server Configuration for SCEP
Certificate Template 10-32
CHAPTER
11
BYOD Wired Infrastructure Design
10-32
11-1
Campus Wired Design 11-1

VLAN Design for Wired Switches at Campus 11-2
IP Address Design for Campus Wired Infrastructure 11-2
Policy Enforcement in the Campus for Wired Devices 11-2
ACL Design for Campus Access Layer Switches 11-3
Provisioning ACL 11-4
802.1X and AAA Configuration for Campus Switches 11-5
Branch Wired DesignNon-Converged Access 11-7
VLAN Design at Branch Locations 11-8
IP Address Allocation at Branch Location 11-8
Policy Enforcement in the Branch for Wired Devices 11-9
ACL Design at Branch Location 11-10
Provisioning ACL 11-11
802.1X and AAA Configuration for Branch Switches 11-12
Branch Wired DesignConverged Access 11-12
VLAN Design at Branch Locations 11-13
IP Address Allocation at Branch Location 11-13
Policy Enforcement at the Branch Using Converged Access Switches 11-14
ACL Design at Branch Location for Converged Access Switches 11-14
802.1X and AAA Configuration for Branch Switches 11-16
MAB Devices at Branch or at Campus Location 11-16
xi
Contents
CHAPTER
12
Security Group Access for BYOD
12-1
Unified Infrastructure Design to Support SGA 12-1

Policy Configuration for SGACLs in Scenario 1 12-3
Policy Configuration in Scenario 2 12-5
TrustSec Summary 12-8
CHAPTER
13
Mobile Device Manager Integration for BYOD
13-1
Establishing IP Connectivity for an On-Premise MDM
13-1
Establishing IP Connectivity for a Cloud-Based MDM
13-2
Configure ISE to Authenticate the MDM API

Creating the MDM API User Account
13-3
13-4
Setting Up the MDM Connection 13-4

Verifying the MDM Connection 13-5
Configuring the MDM 13-7
PART
BYOD Use Cases
CHAPTER
14
Summary of BYOD Use Cases
CHAPTER
15
BYOD Enhanced Use CasePersonal and Corporate Devices

Active Directory Groups
14-1
15-3
Distributing Digital Certificates

Mobile Device On-boarding
15-5
15-6
Provisioning Flows 15-7

Provisioning Apple iOS Devices 15-7
Provisioning Android Devices 15-8
Provisioning Wired Devices 15-10
Key and Certificate Storage
15-12
Network Device Groups 15-13

Policy Enforcement for Security Group Access
Security Group Access Tags 15-15
Security Group ACL 15-15
Authorization Polices for SGT 15-16
15-14
Personal Wireless DevicesFull Access 15-16

Simple and Compound Conditions 15-18
Permissions 15-20
Centralized Campus with SGT 15-21
Converged Access Campus with SGT 15-21
xii
15-1
Contents
Centralized Campus with ACLs 15-21

Branch with FlexConnect 15-22
Converged Access Branch or Campus 15-23
Personal Wireless DevicesPartial Access 15-24
Permissions 15-26
Centralized Campus with SGT 15-26
Converged Access Campus with SGT 15-27
Branches with FlexConnect 15-30
Personal Wireless DevicesInternet Only Access 15-34
Permissions 15-36
Centralized Campus with SGT or ACLs 15-36
Branches with FlexConnect 15-38
Personal Wired DevicesFull Access 15-43
Wired Simple and Compound Conditions 15-45
Permission 15-45
Campus Wired 15-46
Branch Wired 15-47
Personal Wired DevicesPartial Access 15-49
Permissions 15-51
Campus Wired 15-51
Branch Wired 15-52
Converged Access Branch and Campus 15-53
Personal Wired DevicesInternet Only Access 15-54
Permissions 15-56
Wired Campus 15-56
Branch Wired 15-58
Converged Access Branch and Campus 15-59
Android DevicesDeny Access
ISE Authorization Policy
CHAPTER
16
15-59
15-60
BYOD Limited Use CaseCorporate Devices

Whitelist Identity Group
16-1
16-2

Security Group Access Tags 16-4
Security Group ACL 16-5
16-4
xiii
Contents
Authorization Polices for SGT
16-6
Corporate DevicesFull Access 16-6

Simple and Compound Conditions 16-9
Permissions for Wireless Users 16-11
Centralized Campus with SGTs 16-12
Branch with FlexConnect 16-13
Corporate Wired DevicesFull Access 16-15
Wired Simple and Compound Conditions 16-17
Permissions for Wired Users 16-18
Campus Wired 16-18
Branch Wired 16-20
Converged Access Branch or Campus
CHAPTER
17
16-20
16-21
BYOD Advanced Use CaseMobile Device Manager Integration

Supported MDM Functions
17-1
17-3
Integration Process Flow 17-5

ISE Compliance Check 17-6
MDM Compliance Check 17-7
ISE Configuration 17-7
Logical Profile 17-7
Authorization Policy 17-8
MDM Enrollment Rule 17-9
Remediate Non-ISE Compliant Rule 17-13
Remediate Non-MDM Compliant Rule 17-18
MDM Reports
CHAPTER
18
17-21
BYOD Basic Access Use Case
18-1
Extending Guest Wireless Access to Employee Personal Devices 18-1

Allowing Employees to Provision Guest Credentials for Themselves 18-2
Extending Web Auth to Use Microsoft AD when Authenticating Employees with Personal
Devices 18-4
Deploying Guest-Like Wireless Access for Employee Personal Devices
Dedicated SSID for Employee Personal Devices 18-7
Wireless Controller Configuration 18-9
Campus Controller Configuration 18-9
xiv
18-5
Contents
Cisco ISE Policy Configuration 18-14

ASA Firewall Configuration 18-17
Differentiated Quality of Service Treatment
18-19
Accessing Corporate Resources 18-20

Securing Mirror Sites for Personal Devices 18-20
DNS Support 18-23
Outlook Web Access for Employee Devices 18-23
ActiveSync Support 18-24
VPN Client 18-24
Virtual Desktop Client 18-26
Summary
CHAPTER
19
18-27
User ExperienceHow To On-board a BYOD Device

Apple iOS Devices
Android Devices
Windows Devices
19-1
19-6
19-11
Windows Wireless Devices

Windows Wired Devices
Mac OS/X Devices
PART
19-1
19-12
19-14
19-16
BYOD Operations and Services
CHAPTER
20
Summary of Operations and Services
CHAPTER
21
BYOD Guest Wireless Access

Overview
20-1
21-1
21-1
IP Addressing and DNS
21-4
Authentication and Authorization
21-6
Designing Guest Access for Campus and Branch locations

WLC Configuration 21-7
Campus Controller 21-8
Guest Controller 21-13
Cisco ISE Policy Configuration 21-19
Cisco ISE Sponsor Portal 21-23
Configuring the Cisco ISE Sponsor Portal 21-24
Cisco ISE Guest Portal 21-26
Configuring the Cisco ISE Guest Portal 21-27
21-7
xv
Contents
Additional Considerations
21-31
Wireless Guest Access at the Branch 21-32

Rate-Limiting Guest Wireless Access 21-34
Multiple Guest SSIDs and AP Groups 21-37
Managing the Downstream Load 21-38
CHAPTER
22
Managing a Lost or Stolen Device
22-1
Blacklist Identity Group 22-2

Blacklisting Wireless Devices 22-3
Blacklisting Wired Devices 22-8
Creating a Downloadable ACL on ISE 22-8
Creating the URL REDIRECT ACL on the Switch 22-9
Configuring the Authorization Profile 22-9
Creating a Rule in the Authorization Policy 22-10
Employees My Devices Portal 22-11
Reporting a Device as Lost 22-12
Reinstating a Device 22-13
PIN Lock and Device Wipes 22-14
AdministratorsBlacklisting a Device 22-14
MDM Actions 22-16
Endpoint Protection Services (EPS) 22-17
Revocation of Digital Certificate 22-21
Disable the RSA SecurID Token 22-23
CHAPTER
23
BYOD Policy Enforcement Using Security Group Access
23-1
Security Group Tag Overview 23-1

ACL Complexity and Considerations 23-2
Security Group Tag 23-2
Security Group Access Domain Infrastructure 23-3
TrustSec Using 802.1X for Link Encryption 23-3
TrustSec in Manual Mode for Link Encryption 23-4
Security Group Tag Distribution and Forwarding Mechanisms
User Policies with SGT 23-7
SGT Assignment for Data Center Servers 23-8
Migrational Considerations for TrustSec Implementation
Whats New in This CVD 23-14
Description 23-15
Network Topology Diagram 23-15
Terminology 23-16
xvi
23-12
23-5
Contents
Deployment Scenario 1
23-18
23-23
Common Infrastructure for Both Scenarios 23-27

Configuring ISE to Support TrustSec 23-27
Configuring ISE for Network Access Device Authentication 23-30
Configuring Network Access Devices for Authentication at ISE 23-35
RADIUS Server Configuration on the CT-5508 Wireless Controller 23-35
RADIUS and CTS Configuration of the 5760 Switch 23-36
RADIUS and CTS Configuration of the Nexus 7000 23-37
RADIUS and CTS Configuration of the Catalyst 6500 23-38
RADIUS and CTS Configuration of the 3850 Switch 23-39
Configuring Network Devices with a Device SGT 23-39
Configuring Static IP/SGT Bindings on Nexus Switches 23-43
Configuration for Deployment Scenario 1 23-44
Catalyst 6500 Platform Specific Considerations 23-44
Configuring Security Group Tag Exchange Protocol (SXP) for Wireless Controllers 23-45
Wireless Controller Configuration 23-46
Catalyst 6500 SXP Configuration 23-47
Configuring Switching Infrastructure to Support TrustSec with 802.1ae MACsec Encryption 23-48
TrustSec Link Policy 23-50
Catalyst 6500 Commands 23-57
Nexus 7000 Commands 23-57
Catalyst 3850 Commands 23-58
CT-5760 Commands 23-58
Policy Enforcement 23-58
Device On-boarding, Provisioning, Authentication, and Authorization Policies for TrustSec in
ISE 23-66
TrustSec Policy Configuration Using the ASA and Security Group Firewall in the Data
CenterDeployment Scenario 2 23-67
RADIUS Server Configuration on the ASA Firewall 23-70
Configuring Security Group Tag Exchange Protocol (SXP) for Wireless Controllers, Catalyst 3850, and
ASA 23-77
CT-5508 Wireless Controller Configuration 23-79
CT-5760 Wireless Controller Configuration 23-80
Catalyst 6500 SXP Configuration 23-81
3850 SXP Configuration 23-82
6500 VSS Distribution Switch 23-83
Nexus 7000 SXP Configuration 23-84
ASA SXP Configuration 23-85
xvii
Contents
Configuring SG-FW Role-Based Policies at ASA
23-88
Device On-boarding, Provisioning, Authentication, and Authorization Policies for TrustSec in ISE
CHAPTER
24
Mobile Traffic Engineering with Application Visibility and Control (AVC)

Executive Summary
24-1
24-1
Macro Trends and Business Requirements
24-3
Cisco Application Visibility and Control (AVC) for Wireless LAN Controllers
24-4
Challenges and Solutions for Managing Application Quality over Wireless Media
IEEE 802.11 Distributed Coordination Function (DCF) 24-6
Collision Sense Multiple Access/Collision Avoidance (CSMA/CA) 24-7
Short Interframe Space (SIFS) 24-8
DCF Interframe Space (DIFS) 24-8
Contention Window (CW) 24-9
DCF Operation 24-10
IEEE 802.11e/WMM 24-11
802.11e User Priorities 24-12
Access Categories (AC) 24-13
Enhanced Distributed Coordination Function (EDCF) 24-14
Arbitration Interframe Spacing (AIFS) 24-14
Contention Window Enhancements 24-15
Transmission Opportunity (TXOP) 24-16
Call Admission Control (TSpec) 24-16
EDCF Operation 24-16
Ciscos Strategic Approach to Application Quality Management
Cisco's Strategic Application-Class QoS Recommendations
Application-Class Expansion 24-21
Application-Class Mapping to WMM 24-21
24-17
24-18
Cisco 802.11e/802.1p/DSCP Mappings 24-22

Default DSCP-to-CoS/UP Mappings 24-23
Cisco WLC/AP QoS Translation Table 24-23
Residual DSCP-to-WMM Mappings 24-24
WLC AVC/QoS Profile-to-DSCP Mappings 24-24
Cisco Wired-Wireless Mapping Points 24-25
Configuring Downstream QoS Policies for Mobile Applications 24-26
Wireless Controller QoS Profile GUI Configuration 24-27
WLC QoS Profile GUI Configuration 24-27
WLC QoS Profile CLI Configuration 24-29
Wireless Controller AVC QoS Profile Configuration 24-30
AVC Protocol Packs (Featuring Cisco Jabber Support) 24-32
xviii
24-6
23-97
Contents
AVC Applications By Business Use Case 24-33

WLC AVC Profile GUI Configuration 24-35
WLC AVC Profile CLI Configuration 24-39
AP Access Switch Downstream QoS Policies 24-42
Four-Class Enterprise to WMM Mapping Model 24-43
Eight-Class Enterprise to WMM Mapping Model 24-48
Twelve-Class Enterprise to WMM Mapping Model 24-53
Configuring Upstream QoS Policies for Mobile Applications
Wireless Device Marking and WMM Policies 24-56
AP Access Switch Upstream QoS Policies 24-58
Catalyst 3750 Configuration Example 24-58
24-55
Application Visibility and Management 24-60

Centralized WLC Application Visibility and Management 24-60
Global Application Visibility 24-60
Per-WLAN Application Visibility 24-61
Per-Client Application Visibility 24-62
NetFlow Export 24-63
NetFlow Export Configuration-GUI 24-63
NetFlow Export Configuration-CLI 24-64
Converged Access Application Visibility 24-64
Converged Access AVC Configuration via CLI 24-65
Converged Access AVC Configuration via GUI 24-68
Converged Access AVC Monitoring via CLI 24-70
Summary
24-75
Additional Reading
CHAPTER
25
24-76
Managing Bonjour Services for BYOD

Executive Summary
Why Bonjour?
25-1
25-1
25-2
Bonjour Overview 25-2

Bonjour Addressing 25-3
Bonjour Naming 25-3
Bonjour Naming Rules 25-3
Bonjour Service Discovery 25-5
Bonjour Optimization 25-6
Caching 25-6
Suppression of Duplicate Responses
25-6
xix
Contents
Exponential Back-off and Service Announcement

Cisco Bonjour Gateway Solution in WLC 7.4+
25-6
25-7
Bonjour Gateway Service Policy Deployment Options
25-11
Bonjour Gateway BYOD Use Cases and Configuration Examples 25-13

Use Case 1Wireless-to-Wired Bonjour Gateway Service PolicyBYOD Employee AirPrint
Example 25-14
Step 1Enable mDNS Global Snooping 25-14
Step 2Editing the Default mDNS Profile 25-16
Step 3Apply the Default mDNS Profile an Interface (or Interface-Group) 25-19
Use Case 2Wireless-to-Wireless Bonjour Gateway Service PolicyBYOD Guest AirPlay
Example 25-22
Step 1Creating a New mDNS Profile 25-23
Step 2Adding Bonjour Services to the New mDNS Profile 25-24
Step 3Enable mDNS Snooping and the New mDNS Profile on the WLAN 25-26
Verifying Bonjour Gateway Operation
25-28
Advanced Bonjour Gateway Scenario Operation

Guest Anchoring 25-32
Layer 3 Roaming 25-32
FlexConnect 25-33
Summary
References
CHAPTER
26
25-31
25-33
25-34
Mobile and Remote Access Collaboration with Cisco Expressway Series

Overview 26-1
Cisco Expressway Series 26-1
Jabber Client Connectivity without VPN 26-2
Solution Components 26-2
Cisco Expressway-C and Expressway-E 26-3
Cisco Unified Communications Manager 26-3
Cisco Unified CM IM and Presence 26-3
Cisco AnyConnect Secure Mobility Client 26-4
Cisco ASA Firewall 26-4
Cisco Jabber Clients 26-4
Cisco TelePresence Endpoints 26-4
DNS Name Server 26-4
Expressway Traversal 26-4
Use Cases in this Document 26-6
Connecting from the Corporate Network 26-6
Connecting from the Internet 26-6
xx
26-1
Contents
Discovering Available Services via DNS 26-7

Collaboration ServicesInside or Outside the Firewall?
SRV Records 26-10
26-8
Configuring Cisco Expressway Mobile and Remote Access 26-11

Expressway ConfigurationNetwork Topology Diagram 26-11
DNS Configuration 26-12
Unified CM and IM and Presence Configuration 26-13
LDAP Integration 26-14
User Configuration 26-14
Device Configuration 26-17
Certificate Export 26-18
Expressway Configuration 26-19
Importing Certificates for Unified CM and IM&P 26-19
Basic Networking (DNS, Routing) 26-20
Expressway-C to Unified CM + IM&P Configuration 26-23
Expressway-C to Expressway-E Configuration 26-23
Traversal Zone 26-25
Firewall Configuration 26-27
ASA SRV Filtering for AnyConnect Support 26-28
DNS Inspect Map 26-29
Service Policy Rule 26-31
Split-Tunnel Exclude for Expressway-E server 26-31
Connection Scenarios 26-34
From the Internet 26-35
Cisco AnyConnect Secure Mobility Client 26-36
AnyConnect and Expressway Co-existence 26-36
Split Tunneling 26-37
Controlling SRV Records 26-38
From the Corporate Network 26-41
Primary DNS Server 26-41
Alternate DNS Server for Differentiated Access 26-41
CHAPTER
27
BYOD Remote Device Access
27-1
Solution Components 27-2

RSA SecurID 27-2
ISE Integration with RSA 27-3
VPN Design Considerations 27-3
ASA Configuration 27-5
ASAs Identity Certificate 27-5
xxi
Contents
ASA Trust Point to Authenticate Remote Users 27-7

Creating Groups for Different Types of Users 27-7
Connection Profile Configuration 27-8
Enabling AnyConnect VPN on the ASA 27-8
Provisioning a Windows Device to Remotely Connect to the Network
Verifying What ISE Policy Rules Are Applied 27-12
Provisioning an Apple iOS Device to Remotely Connect to the Network
CHAPTER
28
BYOD Network Management and Mobility Services

Key Acronyms and Terminology
27-8
27-14
28-1
28-2
Cisco Mobility Services Engine 28-2

Cisco Base Location Services 28-2
Cisco Connected Mobile Experiences 28-2
Cisco Wireless Intrusion Prevention System 28-3
WSSI 28-3
wIPS 28-4
On-wire Attacks 28-5
Over-the-Air Attacks 28-5
Non-802.11 Threats 28-5
wIPS Deployment Modes 28-6
Enhanced Local Mode (ELM) 28-7
Monitor Mode 28-8
AP3600 with WSSI ModuleThe Evolution of Wireless Security and Spectrum
CleanAir 28-8
Persistent Device Avoidance (PDA) 28-11
Event Driven RRM (ED-RRM) 28-11
ClientLink 28-12
Cisco Prime Infrastructure Overview
28-12
Prime Infrastructure and Supporting Components 28-12

User and Device Tracking 28-13
Components 28-14
Locating Users and Devices 28-16
Interference and IntrusionDetection and Location 28-24
Interference Detection and Location 28-25
wIPS Intrusion Detection and Location 28-27
Template-Based Configuration 28-31
Consistent Configuration of WLCs 28-32
Multiple Templates for Variations of Deployment 28-32
Rapid Deployment of New or Replacement Components 28-32
xxii
28-8
Contents
Staged Rollout of Configuration Changes with Rapid Rollback 28-32

Template Creation and Implementation 28-33
Template Creation 28-33
Detailed Steps for Ensuring WLAN ID Consistency 28-40
PART
Appendices
APPENDIX
BYOD Converged Access Configurations

Converged AccessCampus
A-1
Converged AccessBranch
A-16
APPENDIX
References
APPENDIX
Software Versions
APPENDIX
BYOD System Release Notes
A-1
B-1
C-1
D-1
IOS XE 3.2.2 SE Software ReleaseCatalyst 3850 Series Switches and Cisco 5760 Wireless
Controllers D-1
Additional Observations
APPENDIX
D-2
Airespace ACLs in WLC 7.5+
E-1
Wireless CWA Authorization Profiles for Dual SSID Provisioning
E-2
Wireless NSP Authorization Profile for Single SSID Provisioning
E-4
Authorization Policies
E-6
xxiii
Contents
xxiv
PART
Introduction
Preface
This document is a Cisco Validated Design (CVD) for Cisco Bring Your Own Device (BYOD) Solutions.
It presents system-level requirements, recommendations, guidelines, and best practices for deploying
personal, corporate, and guest devices onto a network to fit your business needs. As Cisco continues to
develop and enhance the technologies required to implement a BYOD solution, this CVD will continue
to evolve and be updated to provide the latest guidelines, recommendations, and best practices for
designing and deploying a BYOD solution.
How to Use this Document

This document is organized into five main parts after the initial Chapter 1, BYOD Solution Overview.

The chapters in this part of the document describe the main components of Cisco BYOD solution and
explain how these components work together to form a complete end-to-end solution:
Chapter 3, Cisco BYOD Solution ComponentsHighlights the different network components

used in the design guide.
Chapter 4, BYOD Use CasesAddresses four different use cases based on the type of network
access allowed by an organization.
Chapter 5, Campus and Branch Network Design for BYODDescribes different campus and
branch designs used to support BYOD, including WAN infrastructure, FlexConnect, and Converged
Access.
Chapter 6, Mobile Device Managers for BYODIntroduces the ISE integration with different
third-party Mobile Device Managers and explores different deployment models.
Chapter 7, Application Considerations and License Requirements for BYODHighlights

different requirements that need to be present to provide the proper network service to applications.

The chapters in this part of the document describe the network infrastructure design and configuration
foundations to deploy a BYOD solution in a customer environment:
Preface
Chapter 9, BYOD Wireless Infrastructure DesignPresents different network designs used to

support BYOD, including Campus and Branch designs.
Chapter 10, Identity Services Engine for BYODFocuses on digital certificates, authentication
and authorization policies, and device profiling and different ways to on-board devices with either
single or dual SSID configurations.
Chapter 11, BYOD Wired Infrastructure DesignHighlights how to on-board wired devices and
how to enforce BYOD policies and network access for wired devices.
Chapter 12, Security Group Access for BYODPresents two different deployment scenarios that
rely on Security Group Tags to enforce BYOD policies.
Chapter 13, Mobile Device Manager Integration for BYODFocuses on how to configure ISE to
integrate with third-party MDM products through an XML-based API.
BYOD Use Cases

The chapters in this part of the document describe the following four BYOD use case examples of access
requirements an organization may enforce as well as a user interaction with ISE during on-boarding:
Chapter 15, BYOD Enhanced Use CasePersonal and Corporate DevicesProvides network
access for personal devices, as well as corporate-issued devices. It allows a business to build a policy
that enables granular role-based application access and extends the security framework on and
off-premises.
Chapter 16, BYOD Limited Use CaseCorporate DevicesEnables access exclusively to

corporate-issued devices.
Chapter 17, BYOD Advanced Use CaseMobile Device Manager IntegrationThis

comprehensive use case also provides network access for personal and corporate-issued devices.
However it includes posture of the device into the network access control decision through
integration with third-party Mobile Device Managers (MDM).
Chapter 18, BYOD Basic Access Use CaseThis use case is an extension of traditional wireless
guest access. It represents an alternative where the business policy is to not on-board/register
employee wireless personal devices, but still provides Internet-only or partial access to the network.
Chapter 19, User ExperienceHow To On-board a BYOD DeviceCaptures a typical user

interaction with ISE during the on-boarding process.

The chapters in this part of the document describe various services in addition to the use cases described
in the previous section:
Chapter 21, BYOD Guest Wireless AccessDescribes a traditional wireless guest access solution
where users do not have to on-board or register a device on the network, but only Internet-only
access is provided to users.
Chapter 22, Managing a Lost or Stolen DeviceDescribes how to deny access to a device that is
reported lost or stolen to prevent unauthorized access to the network.
Chapter 23, BYOD Policy Enforcement Using Security Group AccessDescribes in depth how
to use Security Group Access as an alternative policy enforcement method to access control lists.
Preface
Chapter 24, Mobile Traffic Engineering with Application Visibility and Control
(AVC)Describes in depth how to use application visibility and control techniques to ensure a
seamless user experience.
Chapter 25, Managing Bonjour Services for BYODDescribes a use case where users need to
connect to Bonjour devices.
Chapter 26, Mobile and Remote Access Collaboration with Cisco Expressway SeriesDescribes
a new way for mobile devices to connect from any location without the need for a separate VPN
client, which simplifies the BYOD user experience and complements security policies.
Chapter 27, BYOD Remote Device AccessDescribes how to accommodate devices that attempt
to connect remotely to access internal resources.
Chapter 28, BYOD Network Management and Mobility ServicesDescribes how to configure
and deploy Cisco Prime Infrastructure management suite to manage the BYOD solution.
Appendices
The appendices contain useful information that is not covered in the main chapters of this CVD:
Appendix A, BYOD Converged Access ConfigurationsProvides the configurations required to

deploy Ciscos Converged Access solution presented in the BYOD CVD design.
Appendix B, ReferencesProvides links to references that supplement this design guide.
Appendix C, Software VersionsProvides the software versions and devices leveraged in this
design.
Appendix D, BYOD System Release NotesProvides important information you should be

aware of when designing and implementing this release of the BYOD CVD.
Appendix E, Airespace ACLs in WLC 7.5+Describes a new behavior found in version 7.5+ of
the Wireless LAN Controllers and provides alternate ways to enforce ACLs in different
deployments.
For Experienced Users

Readers who are familiar with previous versions of this CVD or who are experienced at designing a
BYOD solution can use this document as a reference source. Rather than reading every page or every
chapter, this document has been broken into modules that can be easily searched for a particular topic.
Updates to the topics in this CVD will be published periodically.
For New Users

This document is long and contains an extensive amount of complex technical information. It can seem
intimidating, particularly, if you are a first time reader of this document or do not have much
experiencing a BYOD solution.
To orient yourself to the document, we recommend you begin with Chapter 2, Summary of Design
Overview,which provides an overview of the major components required to deploy a BYOD solution
and typical access control use cases. From this section, you can then determine if you need particular
design guidance around the infrastructure, the uses cases, or a set operation such as Remote Access.
Preface
Where to Find Additional Information

Because the document covers a wide spectrum of Cisco Network Infrastructure, Security, and Mobility
products and possible solution designs, it cannot provide all the details of individual products, features,
or configurations. For that type of detailed information, refer to the specific product documentation
available at: http://www.cisco.com.
This document provides general guidance on how to design your own BYOD solution. Cisco has
developed, tested, and documented specific solutions for certain applications and has made those
solutions available for customers to copy and deploy. They are part of the Cisco Validated Design
program described and documented at: http://www.cisco.com/go/designzone.
Revision History
This document may be updated at any time without notice. You can obtain the latest version of this
document online at:
http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns743/ns1050/own_device.html.
Visit this website periodically and check for documentation updates by comparing the revision date of
your copy with the revision date of the online document.
Table 1 lists the revision history for this document.
Table 1
Revision History
Revision Date
Comments
August 7, 2013
Initial version of this BYOD CVD.
September 27, 2013
Added note on potential incompatibilities introduced by Apple iOS

7 to chapters 10, 19, and 21. Corrected table 21-2.
March 6, 2014
Added the following to the CVD: TrustSec/SGT support for

Converged Access campus designs, introduction of the MSE and
location services, Converged Access QoS discussion, enhancements
to High Availability (HA) on WLC platforms, and Application
Visibility (AV) support on Converged Access platforms.
June 20, 2014
Added a new chapter, Chapter 26, Mobile and Remote Access

Collaboration with Cisco Expressway Series, a new appendix,
Appendix E, Airespace ACLs in WLC 7.5+, and added
explanatory notes to several chapters about an issue with ACLs
found in version 7.5+ of the Wireless LAN Controller.
August 28, 2014
The Cisco 3700 and 2700 Series access points, which support
802.11ac, have been validated and added to the Cisco BYOD
solution.
Command Syntax Conventions

Table 2 describes the syntax used with the commands in this document.
Preface
Table 2
Command Syntax Guide
Convention
Description
boldface
Commands and keywords.
italic
Command input that is supplied by you.
Keywords or arguments that appear within square brackets are optional.
{x|x|x}
A choice of keywords (represented by x) appears in braces separated by

vertical bars. You must select one.
^ or Ctrl
Represent the key labeled Control. For example, when you read ^D or
Ctrl-D, you should hold down the Control key while you press the D key.
screen font
Examples of information displayed on the screen.
boldface screen font
Examples of information that you must enter.
<
>
Nonprinting characters, such as passwords, appear in angled brackets.
Default responses to system prompts appear in square brackets.
Preface
CH AP TE R

Introduction
Bring Your Own Device (BYOD) continues to be one of the most influential trends reshaping the
landscape of the mobile enterprise and the evolution of IT organizations. The influx of powerful mobile
devices into the workplace is changing how users access and consume enterprise resources. IT managers
are establishing policies with BYOD access as the norm rather than the exception due to increasing
demands from employees and executives who embrace this megatrend. Enterprises are beginning to see
BYOD as an opportunity rather than a challenge. There is no longer any doubt that enterprise IT
departments are adapting to mobile devices (smartphones, tablets, laptops, etc.) in the corporate
workplace to meet user expectations and leverage new technologies to boost worker productivity.
IT needs to balance productivity with security and coordinate business justification with the various line
of business (LOB) owners to implement BYOD programs within an enterprise. On one hand, employees
are demanding access from devices not only within the corporation, but also beyond the firewall. On the
other hand, risk management dictates that corporate data must remain protected
The Cisco BYOD Smart Solution delivers a unified workspace that increases workforce productivity
with high quality collaboration on any device, anywhere. Cisco BYOD Smart Solution is a complete, yet
flexible and secure BYOD solution that one can easily tailor to meet an enterprises needs. Cisco
customers get proven solution designs that are fully system tested and documented in a Cisco Validated
Design (CVD). The CVD program consists of systems and solutions designed, tested, and documented
to facilitate faster, more reliable, and more predictable customer deployments.
When BYOD is properly implemented, it delivers an uncompromising, work-your-way user experience
and enables organizations to secure data with unified policies and essential controls.
BYOD Market Landscape

Mobile devices are turning into general computing devices with faster components and better integration
and support in connecting to enterprise systems. They are being used by employees to perform their
regular job functions. In many cases, each employee owns multiple devices which they use for personal
as well as business work.
The BYOD market was initially centered on allowing employees, partners, and guests to connect to the
corporate networks and be able to perform a limited number of basic functions, such as access the
Internet, access corporate email, calendar, and contacts, etc. As more and more personal devices become
1-1
Chapter 1
BYOD Market Landscape
prevalent in the enterprise, workers are using these devices to access enterprise resources and
applications to do their daily jobs. With employees using personal devices for mission critical job
functions, mobile device managers (MDM) are becoming increasingly important. Functions such as
ensuring that a device can be locked and wiped remotely in case it gets lost or stolen or when the
employee is terminated are becoming a necessity.
An enterprises BYOD strategy should build momentum towards meaningful infrastructure, security, and
wireless innovation and provide a solid rationale for BYOD investments.
To understand the benefits and the challenges BYOD poses, it is helpful to understand the business
trends that are hindering or driving BYOD adoption.
BYOD and the Enterprise Network

The network is at the heart of all business functions and is a key enabler for service delivery. With the
proliferation of mobile devices, protecting enterprise networks is getting more complex. Inconsistent
management tools and policies across the wired and wireless segments of the network can increase the
burden for network managers and drive up management costs and complexity. An architectural approach
and design can help businesses realize greater levels of manageability, enhance user/customer
experience, provide greater levels of flexibility and performance, and achieve improvements in security
and policy.
Today enterprises have diverse wired and wireless LAN infrastructure implementations. The traditional
workforce model involves a worker going to an office and performing their job functions while tethered
to an IT-provided computer and an IP phone. Hence the focus has been on ensuring that the wired
enterprise infrastructure is robust and secure. The wired network is built for high availability and
performance, with adequate capacity and intelligent features such as QoS to make phone calls, exchange
data and video, etc., within and outside of the enterprise. Communication within the premises is based
on a trust model, protected by firewalls at the perimeter and other security tools.
In contrast, the enterprise wireless infrastructure was built for convenience, at least until the BYOD
phenomenon emerged. With BYOD, users will have three or more mobile/WLAN devices (laptop, tablet,
Smartphone) all connecting to this infrastructure. The devices themselves could be user-owned or
corporate-owned. What is the trust level of these devices that are accessing secure enterprise resources?
How are they accounted for at all times? With all these questions demanding answers, one can expect a
lot more focus on the wireless network. The WLAN needs to become as robust, secure, scalable, and
predictable as the wired network to support BYOD.
BYOD Security and Policy-Many enterprise CIOs and architects cite security as a major inhibitor in
the deployment, adoption, and acceleration of BYOD within their enterprise. It can be overwhelming to
manage security for various applications for a huge set of new BYOD devices with diverse operating
systems and users. Based on each customers environment and business policy, there are many options
for implementing and configuring personal and network firewalls, intrusion prevention, anti-spyware,
data security, device control for smartphones, desktops, and tablets for various user roles such as
employees, guests, partners, and remote workers.
Policy management is critical to a successful BYOD strategy which enables endpoint security for
multiple devices and diverse user roles. Application management and security are on the rise in a BYOD
environment as enterprises seek to manage and secure applications rather than devices, with more
granular policies applied based on worker or application type. More companies want enterprise
application stores that allow for a central deployment method. The security needs of a mobile workforce
include:
Ensuring that the devices used to access the corporate network are safe and are not jail-broken or
rooted. They should not have threatening malware, spam, or applications that can compromise the
corporate network or data.
1-2
Chapter 1

User Need and Role of IT
Making sure users and devices that are accessing the corporate network can be identified and
allowed connectivity only if they are authorized and meet company policy.
Securing access with client-based or clientless access to ensure data loss prevention with encryption
or containerization with VPN optimized for efficient application delivery and capabilities.
Enforcing device-level security functionality such as remote wipe/lock with integrated Network
Access Control (NAC), thus ensuring that an action can be taken on non-compliant devices at any
time (not just during access).
Having visibility into users, devices, and the applications they are running on the corporate network.
MobilityThe hottest segment of the enterprise networking market is wireless LAN equipment to
support enterprise requirements for user mobility and wireless devices. As smartphones and tablets
become more powerful, they are increasingly used by employees to connect to the WLAN and other
enterprise resources to do their normal job functions. It then becomes important for the WLAN to have
same or similar intelligence and feature functionality, such as high availability, QoS, local switching,
application visibility and control, ease of collaboration, etc., that users have become accustomed to on
a wired infrastructure.
Role of MDM in the Enterprise Network

Mobile Device Managers are designed to help an enterprise rapidly and securely deploy mobile devices
and applications with policy, compliance, configuration, and application management to minimize risk.
Large enterprises are extremely interested in delivering general-purpose as well as custom-built
corporate applications to their workforce (for example, mobile sales force automation applications).
BYOD security and device management are the foundations of an enterprise BYOD strategy which must
consider all mobile worker types and functions before deploying solutions. Organizations need to
consider solutions across the security sub-segments that secure endpoints, provide protection for the
corporate network, and protect data as it moves over their infrastructure.
The ability to integrate MDM functionality, coupled with a policy-based network access, ensures that
legitimate devices and users can access the network and attempted violations can be controlled by
prohibiting or limiting access to the network or network resources.
User Need and Role of IT

BYOD connectivity may look like a simple extension of enterprise mobile services, however broad user
expectations and the diversity of devices create unique infrastructure demands and challenges for IT
operations with end-to-end and network optimization and lifecycle management to support BYOD.
Device choice does not mean sacrificing security. IT must establish the minimum security baseline that
any device must meet to be used on the corporate network, including WiFi security, VPN access, and
perhaps add-on software to protect against malware.
In addition, due to the wide range of devices, it is critical to be able to identify each device connecting
to the network and authenticate both the device and the person using it.
1-3
Chapter 1
Challenges for End Users
Protecting Data and Loss Prevention

One of the largest challenges with any BYOD implementation is ensuring protection of corporate data.
If a corporate asset, such as a laptop, is used to access business applications and data, typically that asset
is tightly controlled by IT and likely subject to more restrictive usage policies.
Some industries need to comply with confidentiality regulations like HIPAA, security compliance
regulations like PCI, or more general security practice regulations like Sarbanes-Oxley and others.
Companies need to show compliance is possible with BYOD adoption, which can be more challenging
than with a corporate-owned and managed device.
An employee-owned mobile device is likely being routinely used for personal access and business
applications. Cloud-based file sharing and storage services are convenient for personal data, but can be
potential sources of leakage for confidential corporate data.
IT must have a strategy for protecting business data on all devices whether corporate managed or
employee self-supported and managed. This may include a secure business partition on the device which
acts as a container of corporate data that can be tightly controlled and may also include the need for a
Virtual Desktop Infrastructure (VDI) application to allow access to sensitive or confidential data without
storing the data on the device.
At some point in the lifecycle of a device or employee, it may become necessary to terminate access to
the device or the devices access to the network. This could be due to a lost or stolen device, an employee
termination, or even an employee changing roles within the company. IT needs the ability to quickly
revoke access granted to any device and possibly remotely wipe some or all of the data (and applications)
on the device.

BYOD solutions and technologies are quickly evolving, however one of the largest challenges is how to
make it simple for people to get connected to and use corporate resources and applications to do their
work. The number of device possibilities, the range of connection types and locations, and the lack of
widely adopted approaches can translate to difficulties for users.
Security precautions and steps may also vary depending upon how and where the user is trying to
connect. For example, the corporate WiFi may require credentials, whereas connecting through a public
WiFi hotspot may require credentials, a virtual private network (VPN), and other security steps. If such
security measures are too intrusive, they could erase productivity gains of BYOD.
Key Advantages of the Cisco BYOD Solution
Cisco networks are integrated into one control panel, resulting in greater security and ease of
management.
The Cisco Solution relies on a centralized policy server that integrates tightly with an organizations
Active Directory and PKI infrastructure.
Fully integrated, centralized, single point of visibility and control of users, devices, location,
network, and applications resulting in greater security and ease of management.
Services across end-to-end partner ecosystemPre-integrated and tested solutions with world-class
partners.
1-4
Chapter 1

The Cisco BYOD solution integrates the Cisco products, third-party products, and devices discussed
previously into a comprehensive BYOD approach which is tightly integrated across the network
infrastructure. This offers a unique set of advantages such as flexibility to allow for multiple diverse user
groups, including deskbound workers, mobile workers, customers, guests, etc.
1-5
Chapter 1
1-6
PART
CH AP TE R

This part of the CVD describes design considerations to implement a successful BYOD solution and
different deployment models to address diverse business cases. Other parts of the CVD provide more
details on how to implement unique use cases.
There are numerous ways to enable a BYOD solution based on the unique business requirements of a
specific organization. While some organizations may take a more open approach and rely on basic
authentication, other organizations will prefer more secure ways to identify, authenticate, and authorize
devices. A robust network infrastructure with the capabilities to manage and enforce these policies is
critical to a successful BYOD deployment.
The Cisco BYOD solution builds on the Cisco Borderless Network Architecture and assumes best
practices are followed in network infrastructure designs for campus, branch offices, Internet edge, and
converged access implementations. The solution showcases the critical components to allow secure
access for any device, ease of accessing the network, and centralized enforcement of company usage
policies. This robust architecture supports a multitude of wired or wireless devices, both
employee-owned and corporate-owned, accessing the network locally or from remote locations, as well
as on-premise guest users.
This part of the CVD includes the following chapters:
Cisco BYOD Solution ComponentsThis section highlights the different network components used
in the design guide. These components provide a solid network infrastructure required as the
enforcement point for BYOD policies. Because of the reliance on digital certificates, a discussion
regarding the secure on-boarding of devices is included in this section.
BYOD Use CasesThis CVD addresses four different use cases based on the type of network
access allowed by an organization. These use cases vary from personal, corporate-owned, and guest
access. Permissions are enforced using Active Directory credentials, digital certificates, ISE
identity groups, and other unique identifiers.
Campus and Branch Network Design for BYODPolicy enforcement is effective if and only if there
is a well-designed network infrastructure in place. This section describes different campus and
branch designs used to support BYOD, including WAN infrastructure, FlexConnect, and Converged
Access.
Mobile Device Managers for BYODThe section introduces the ISE integration with different
third-party Mobile Device Managers and explores different deployment models.
Application Considerations and License Requirements for BYODThis section highlights different
requirements that need to be present to provide the proper network service to applications. These
include features such as Quality of Service, Rate Limiting, Application Visibility and Control
(AVC), and others. The chapter also highlights Cisco Jabber and Virtual Desktop (VDI) architecture.
2-1
Chapter 2
2-2
CH AP TE R

Whats New: The Cisco 3700 and 2700 Series access points, which support 802.11ac, have been
validated and added to the Cisco BYOD solution.
Cisco provides a comprehensive BYOD solution architecture, combining elements across the network
for a unified approach to secure device access, visibility, and policy control. To solve the many
challenges described earlier, a BYOD implementation is not a single product, but should be integrated
into an intelligent network.
The following figures show a high-level illustration of the Cisco BYOD solution architecture. The
architecture has been separated into campus and branch diagrams simply for ease of viewing. These
infrastructure components are explained in detail in the following sections.
3-1
Chapter 3
Figure 3-1
HIgh-Level BYOD Solution ArchitectureCampus View
Cisco Unified Wireless

Network (CUWN)
Centralized Design
Data Center
Services
Prime
Infrastructure
NTP
MSE
CAPWAP
Catalyst 3750X
Switch Stack
ISE
RSA
CT5508 and/or
CT5760 WLCs
CA
AD
Core
DNS and
DHCP
Applications
and File
Servers
Campus Building
Internet
Edge
Layer 2 Trunk
Connections
CT5508
Guest WLCs
Converged
Access Design
Wifi Connections
Ethernet Connections
CAPWAP Tunnels
ASA
CAPWAP
Mobility Tunnels
WAN
Catalyst 3850
Switch Stack
Off-Prem
DMVPN
Internet
3-2
MDM
Cloud-Based
MDM
294889
MDM
On-Prem
MDM
Chapter 3

Cisco Wireless Infrastructure
Figure 3-2
High-Level BYOD Branch Solution ArchitectureBranch View
Data Center
Prime
Infrastructure
Branch
Services
MSE
FlexConnect Design
NTP
ISE
RSA
Catalyst 3750X
Switch Stack
Flex7500
WLS
ACL
CAPWAP
CA
Core
AD
DNS and
DHCP
Applications
and File Servers
CAPWAP Tunnel
for FlexConnect
Design
WAN Edge
Old Mobility
Architecture
for FlexConnect
Design
Converged Access Design
Internet
Edge
New (Hierarchical)
Mobility Architecture
for Converged
Access Design
CT5508
Guest
WLCs
WAN
CAPWAP Tunnel
for Converged
Access Design
MPLS
WAN
ASA
CAPWAP
Off-Prem
DMVPN
Internet
Catalyst 3850
Switch Stack
MDM
Layer 2 Trunk Connections

Wifi Connections
Cloud-Based
MDM
294890
MDM
On-Prem
MDM
CAPWAP Tunnels
Mobility Tunnels
Ethernet Connections

The Cisco wireless infrastructure discussed in this design guide consists of Cisco Aironet access points
(APs), Cisco wireless LAN controllers (WLCs), Cisco Converged Access switches, and the Cisco
Mobility Services Engine (MSE). Each is discussed in the following sections.
3-3
Chapter 3
Cisco Aironet Access Points

Cisco Aironet access points provide WiFi connectivity for the corporate network and handle
authentication requests to the network via 802.1X. The Cisco second generation (G2) access points in
this design guide include the Cisco Aironet 3700, 2700, 3600, 2600, and 1600 Series.
Cisco 3700 Series APs are ideal for high-density network environments that use mission-critical,
high-performance applications. They feature the industrys first AP with an integrated 802.11ac Wave 1
radio a supporting a 4x4 multiple input, multiple output (MIMO) design with three spatial streams for
data rates up to 1.3 Gbps. The flexible, modular design of the Cisco 3700 Series provides expansion
capability for a future 802.11ac Wave 2 module and advanced services such as the Wireless Security
Module (WSM).
Cisco 2700 Series APs are non-modular dual band (5 GHz and 2.4 GHz) 802.11ac access points
optimized for adding capacity and coverage to dense Wi-Fi networks. They feature a 3x4 MIMO design
with three spatial streams for a maximum data rate up to 1.3 Gbps.
The Cisco 3700 and 2700 Series APs incorporate the Cisco High-Density Experience (HDX), which
includes among other features Cisco CleanAir with enhanced support for 80-GHz channels and updated
ClientLink 3.0 with support for 802.11a/b/g/n/ac. Cisco CleanAir technology is enabled in hardware
for both the Cisco 3700 and 2700 Series APs. Cisco ClientLink 3.0 helps improve performance of clients
on the wireless LAN (WLAN).
Cisco 3600 Series access points are ideal for customers looking for best-in-class performance in 802.11n
environments with high client density. They feature the industrys first 802.11n 4x4 multiple input
multiple output (MIMO) design with three spatial streams for data rates up to 450 Mbps. The flexible,
modular design of the Cisco 3600 Series provides expansion capability for emerging technologies such
as the 802.11ac module and advanced services such as the Wireless Security Module (WSM).
The 802.11ac module protects the existing investment in wireless infrastructure by extending the
capabilities of the Cisco 3600 Series access point to provide 802.11ac Wave 1 support for wireless
clients. The field-upgradeable 802.11ac module has its own 5 GHz radio with internal antennas which
are separate from the client/data serving 5 GHz and 2.4 GHz radios within the Cisco 3600 Series access
point. The 802.11ac module provides 3x3 MIMO with three spatial streams, extending the maximum
data rate of the Cisco 3600 Series access point to approximately 1.3 Gbps with the 802.11ac module
installed.
The field-upgradeable Wireless Security Module (WSM) has a dedicated 2.4 and 5 GHz radio with its
own antennas enabling 7x24 scanning of all wireless channels in the 2.4 and 5 GHz bands. It offloads
concurrent support for monitoring and security servicessuch as Cisco CleanAir spectrum analysis,
wIPS security scanning, rogue detection, context-aware location, and Radio Resource Management
(RRM)from the internal client/data serving radios within the Cisco 3700 or 3600 Series AP to the
WSM. This not only allows for better client performance, but also reduces costs by eliminating the need
for dedicated monitor mode access points and the Ethernet infrastructure required to connect those
devices into the network.
Note
The Cisco 3600 Series access point requires 18 Watts of power with the 802.11ac module and 17 Watts
of power with the WSM. The Cisco 3700 Series requires 18 Watts of power with the WSM. When
powering the access point from a Cisco Catalyst switch, the switch port must support either IEEE 802.3at
POE+ or Cisco Universal PoE (UPoE). If powered from a switch port which only supports IEEE
802.11af PoE, the Cisco 3600 Series access point will boot up, however the module will not be activated.
3-4
Chapter 3

Cisco 2600 Series access points are dual band (5 GHz and 2.4 GHz) 802.11n access points ideal for
mid-market small, mid-size, or large enterprise customers looking for mission critical performance.
They feature a 3x4 multiple input multiple output (MIMO) design with three spatial streams for a
maximum data rate of approximately 450 Mbps.
Cisco Aironet 1600 Series are entry-level dual band (5 GHz and 2.4 GHz) 802.11n access points,
designed to address the wireless connectivity needs of small and mid-size enterprise customers. They
feature a 3x3 multiple input multiple output (MIMO) design with two spatial streams for a maximum
data rate of approximately 300 Mbps.
The Cisco 3600, 2600, and 1600 Series access points support additional technologies, such as Cisco
ClientLink 2.0, which help improve performance of clients on the wireless LAN (WLAN). The Cisco
3600 with the 802.11ac module also supports IEEE 802.11ac Wave 1 explicit beamforming for 802.11ac
clients which also support the functionality. Cisco CleanAir technology is also enabled in hardware for
both the Cisco 2600 and 3600 Series APs.
Cisco Aironet access points can operate as lightweight or autonomous access points. When functioning
as lightweight access points, a wireless LAN controller is required. In this design, the 802.11 MAC layer
is essentially split between the AP and the WLC. The WLC provides centralized configuration,
management, and control for the access points. All designs in this design guide assume lightweight
access points.
Further information regarding Cisco Aironet access points can be found in the following at-a-glance
document:
http://www.cisco.com/en/US/prod/collateral/wireless/ps5678/ps10981/at_a_glance_c45-636090.pdf
Cisco Wireless LAN Controllers

Cisco Wireless LAN Controllers (WLC) automate wireless configuration and management functions and
provide visibility and control of the WLAN. The WLC extends the same access policy and security from
the wired network core to the wireless edge while providing a centralized access point configuration.
The WLC interacts with the Cisco Identity Services Engine (ISE) to enforce authentication and
authorization policies across device endpoints. Multiple WLCs may be managed and monitored by Cisco
Prime Infrastructure. Wireless LAN Controller functionality can be within standalone appliances,
integrated within Catalyst switch products, or run virtually on Cisco Unified Computing System (UCS).
Integrated controller functionality is discussed in Converged Access Campus Design in Chapter 5,
Campus and Branch Network Design for BYOD.
The Cisco wireless LAN controller platforms discussed within this design guide include the Cisco 5508
wireless LAN controller (CT5508), the Cisco Flex 7510 wireless LAN controller, the Cisco 5760
wireless LAN controller (CT5760), and the Cisco Catalyst 3850 Series switch. The Cisco 5508 and Flex
7510 WLC platforms run Cisco Unified Wireless Network (CUWN) software (also referred as AireOS
software), while the Cisco 5760 WLC and Catalyst 3850 Series switch run Cisco IOS XE software.
The Cisco 5508 wireless LAN controller is targeted for mid-sized and large single-site enterprises.
Within the Cisco BYOD design guide it is deployed within the campus supporting access points
operating in centralized (local) mode. The Cisco 5508 WLC supports up to 500 access points and 7,000
clients per controller with a maximum capacity of approximately 8 Gbps.
The Cisco Flex 7510 wireless LAN controller is targeted for enterprise branch environments. Within the
Cisco BYOD design guide it is deployed as a remote controller supporting access points operating in
FlexConnect mode. The Cisco Flex 7510 WLC supports up to 6,000 access points and 64,000 clients per
controller with up to 2,000 FlexConnect groups, each of which can be configured for a branch location.
3-5
Chapter 3
The Cisco 5760 wireless LAN controller is targeted for large multisite or single-site enterprises or
service providers. Within the Cisco BYOD design guide it is deployed within the campus, either
supporting access points operating in centralized mode or functioning as a Mobility Controller (MC) in
a Converged Access design. The Cisco 5670 WLC supports up to 1,000 access points and 12,000 clients
per controller with a maximum capacity of approximately 60 Gbps.
Cisco Catalyst 3850 Series switches are discussed in Cisco Converged Access Switches.
Further information regarding Cisco wireless LAN controller platforms can be found in the following
at-a-glance document:
http://www.cisco.com/en/US/prod/collateral/modules/ps2706/at_a_glance_c45-652653.pdf
Cisco Converged Access Switches

Cisco Converged Access switch platforms include the Catalyst 3850 Series and Catalyst 3650 Series.
This version of the BYOD design guide only discusses Catalyst 3850 Series switches deployed in both
campuses and branches.
Cisco Catalyst 3850 Series switches provide converged wired and wireless network access for devices.
As a switch, the Catalyst 3850 provides wired access to the network and handles authentication requests
to the network via 802.1X. In addition, the Catalyst 3850 contains wireless LAN controller functionality
integrated within the platform. As a wireless controller, it allows for the termination of wireless traffic
from access points directly attached to the Catalyst 3850 switch rather than backhauling wireless traffic
to a centralized wireless controller. This can provide greater scalability for wireless traffic, as well as
provide increased visibility of wireless traffic on the switch. The Catalyst 3850 Series switch supports
up to 25 access points and 1000 wireless clients on each switching entity (switch or stack) with a
maximum wireless capacity of approximately 40 Gbps (48-port models).
The Catalyst 3850 Series switch interacts with Cisco ISE to enforce authentication and authorization
policies across device endpoints, providing a single point of policy enforcement for wired and wireless
devices. When deployed at the access-layer within a branch location, the Catalyst 3850 can be
configured to function as both a Mobility Controller (MC) and a Mobility Agent (MA), providing full
wireless controller functionality. When deployed within a large campus, the Catalyst 3850 can be
configured to function as an MA, which allows for the termination of wireless traffic directly on the
switch itself. For increased scalability, the MC function, which handles Radio Resource Management
(RRM), Cisco CleanAir, and roaming functions, among other things, can be moved to a dedicated
CT5760 or CT5508 wireless controller. Both the Catalyst 3850 and the CT5760 wireless controller run
IOS XE software, allowing for the full feature richness of Cisco IOS platforms.
Appendix C, Software Versions discusses the feature sets and licensing required for wireless
controller functionality on the Catalyst 3850 Series platform.
Cisco Mobility Services Engine

The Cisco Mobility Services Engine (MSE) is a platform that helps organizations deliver innovative
mobile services and to improve business processes through increased visibility into the network,
customized location-based mobile services, and strengthened wireless security. The Cisco MSE supports
mobility services software in a modular fashion through applications. The following services are
supported along with the required licensing:
Cisco Base Location ServicesRequires Location Services licensing.
Cisco Connected Mobile Experiences (CMX)Requires Advanced Location Services licensing.
Cisco Wireless Intrusion Prevention System (wIPS)Requires wIPS licensing.
3-6
Chapter 3

The Cisco MSE is available as a physical appliance or as a virtual appliance with scalability shown in
Table 3-1. As of MSE software release 7.4 and above, licensing is based the number of access points
supported.
Table 3-1
Mobility Services Engine (MSE) Platforms and Scalability
Platform
Location Services
Licensing
Advanced Location
Services Licensing
Cisco 3355 MSE

Appliance
Up to 2,500 access
points
Up to 2,500 access
points
Up to 5,000 Monitor
Mode (MM) or
Enhanced Local Mode
(ELM) access points
Up to 25,000 devices
Cisco MSE Virtual

Appliance (High-end
Virtual Appliance)
Up to 5,000 access
points
Up to 5,000 access
points
Up to 10,000 MM or
ELM access points
Up to 50,000 devices
wIPS Licensing
Maximum Number of
Tracked Devices
Chapter 28, BYOD Network Management and Mobility Services provides further discussion around
the Mobility Services Engine and Cisco wireless technologies that enable the MSEs capabilities.
Cisco Identity Services Engine

Cisco Identity Services Engine (ISE) is a core component of the Cisco BYOD solution architecture. It
delivers the necessary services required by enterprise networks, such as Authentication, Authorization,
and Accounting (AAA), profiling, posture, and guest management on a common platform. The ISE
provides a unified policy platform that ties organizational security policies to business components.
The ISE also empowers the user to be in charge of on-boarding their device through a self-registration
portal in line with BYOD policies defined by IT. Users have more flexibility to bring their devices to
their network with features such as sponsor-driven guest access, device classification, BYOD
on-boarding, and device registration.
The ISE is able to integrate with third-party Mobile Device Managers (MDM) to enforce more granular
policies based on device posture received from the MDM compliance rules.
Cisco Adaptive Security Appliance

Cisco Adaptive Security Appliance (ASA) provides traditional edge security functions, including
firewall and Intrusion Prevention System (IPS), as well as providing the critical secure VPN
(AnyConnect) termination point for mobile devices connecting over the Internet, including home offices,
public WiFi hotspots, and 3G/4G mobile networks. The ASA delivers solutions to suit connectivity and
mobility requirements for corporate-owned devices as well as employee-owned laptops, tablets, or
mobile devices.
3-7
Chapter 3
Cisco AnyConnect Client

Cisco AnyConnectTM client provides 802.1X supplicant capability on trusted networks and VPN
connectivity for devices that access the corporate network from un-trusted networks, including public
Internet, public WiFi hotspots, and 3G/4G mobile networks. Deploying and managing a single
supplicant client has operational advantages as well as provides a common look, feel, and procedure for
users.
In addition, the AnyConnect client can be leveraged to provide device posture assessment of the BYOD
device, as well as a degree of policy enforcement and enforcing usage policies.
The AnyConnect client can be provisioned centrally with use of a third-party MDM. This enhances the
user experience and reduces the support costs. MDM policy can be configured to manage who is entitled
to use AnyConnect.
Cisco Integrated Services Routers

Cisco Integrated Services Routers (ISR), including the ISR 2900 and ISR 3900 families, provide WAN
and LAN connectivity for branch and home offices. The LAN includes both wired and wireless access.
In addition, ISRs may provide direct connectivity to the Internet and cloud services, application and
WAN optimization services, and may also serve as termination points for VPN connections by mobile
devices.
Cisco Aggregation Services Routers

Cisco Aggregation Services Routers (ASR), available in various configurations, provide aggregate WAN
connectivity at the campus WAN edge. In addition, ASRs may provide direct connectivity to the Internet
and cloud services and may also serve as a firewall. The ASR runs Cisco IOS XE software and offers
Flexible Packet Matching (FPM) and Application Visibility and Control (AVC).
Cisco Catalyst Switches

Cisco Catalyst switches, including the Catalyst 3000, Catalyst 4000, and Catalyst 6000 families,
provide wired access to the network and handle authentication requests to the network via 802.1X. In
addition, when deployed as access switches, they provide power-over-Ethernet (PoE) for devices such
as VDI workstations, IP phones, and access points.
Cisco Nexus Series Switches

Cisco Nexus switches, including the Nexus 7000 and 5000 families, serve as the data center switches
within the CVD. The Nexus 7000 switches provide 10GE Layer 3 connectivity between the Campus
Core, Data Center Core, and Aggregation Layers and 10GE Layer 2 connectivity, utilizing VPC, for the
Nexus 5000 switches in the Data Center Access Layer to which all servers are attached.
3-8
Chapter 3

Secure Access to the Corporate Network
Cisco Prime Infrastructure

Cisco Prime Infrastructure (PI) is an exciting new offering from Cisco aimed at managing wireless and
wired infrastructure while consolidating information from multiple components into one place. While
allowing management of the infrastructure, Prime Infrastructure gives a single point to discover who is
on the network, what devices they are using, where they are, and when they accessed the network.
Cisco Prime Infrastructure 1.2 is the evolution of Cisco Prime Network Control System 1.1 (NCS). It
provides additional infrastructure and wired device management and configuration capabilities while
improving on existing capabilities in NCS 1.1.
Cisco Prime Infrastructure interacts with many other components to be a central management and
monitoring portal. Prime Infrastructure has integration directly with two other appliance-based Cisco
products, the Cisco Mobility Services Engine (MSE) and Identity Services Engine (ISE) for information
consolidation. Prime Infrastructure controls, configures, and monitors all Cisco Wireless LAN
Controllers (WLCs), and by extension, all Cisco access points (APs) on the network. Prime
Infrastructure also configures and monitors Cisco Catalyst switches and Cisco routers.

On-boarding for new devices (certificate enrollment and profile provisioning) should be easy for end
users with minimal intervention by IT, especially for employee owned devices. Device choice does not
mean giving up security. IT needs to establish the minimum security baseline that any device must meet
to access the corporate network. This baseline should include WiFi security, VPN access, and add-on
software to protect against malware. Proper device authentication is critical to ensure secure on-boarding
of new devices and to ensure secure access to other devices on the network. Hence, proper device
authentication protects the entire network infrastructure.
Who is accessing the network, what device they are using, and where they are located need to be
considered before implementing a BYOD solution. The user can initiate the provisioning process from
a campus or a branch location. This design allows the user to provision and access resources from either
location. In the past, a username/password was all that was needed as most employees accessed the
network from a wired workstation. Often a simple server was used to collect and authenticate user
credentials. As organizations implemented wireless into their network, a unique SSID (Wireless
Network name) with a username and password was also needed.
Today, digital certificates and two-factor authentication provide a more secure method to access the
network. Typically the end user must download client software to request a certificate and/or provide a
secure token for access. One of the challenges with deploying digital certificates to client endpoints is
that the user and endpoint may need to access the company's certification authority (CA) server directly
(after being authenticated to the corporate network) to manually install the client certificate. This method
requires the end user manually install the client certificate and ensuring it is installed in the proper
certificate store on the local endpoint.
Deploying digital certificates on non-PC based devices requires a different process as many of these
devices do not natively support all the features and functionality needed to create/download and install
digital client certificates. As users become more and more mobile, authenticating users and devices
accessing the network is an important aspect of BYOD.
3-9
Chapter 3
Certificate Enrollment and Mobile Device Provisioning

Deploying digital certificates to endpoint devices requires a network infrastructure that provides the
security and flexibility to enforce different security policies, regardless of where the connection
originates. This solution focuses on providing digital certificate enrollment and provisioning while
enforcing different permission levels. This design guide covers AndroidTM and Apple iOSTM mobile
devices, in addition to Windows 7 and Mac OS X.
Figure 3-3 highlights the general steps that are followed for this solution when a mobile device connects
to the network:
1.
A new device connects to a provisioning SSID, referred to as the BYOD_Provisioning SSID. This
SSID (open or secured with PEAP) is configured to redirect the user to a guest registration portal.
2.
The certificate enrollment and profile provisioning begins after the user is properly authenticated.
3.
The provisioning service acquires information about the mobile device and provisions the
configuration profile, which includes a WiFi profile with the parameters to connect to a secure SSID,
called the BYOD_Employee SSID.
4.
For subsequent connections, the device uses the BYOD_Employee SSID and is granted access to
network resources based on different ISE authorization rules.
The design guide also covers a single SSID environment, where the same SSID is used for both
provisioning and secure access.
Employee devices that do not go through the provisioning process simply connect to a guest SSID, a or
dedicated guest-like SSID; which may be configured to provide Internet-only or limited access for guests
or employees.
3-10
Chapter 3

Figure 3-3
Enrollment and Provisioning for Mobile Devices
Internet Edge
Internet
Branch
ASA Firewall
CT5508
WLC
Step 1: On-boarding
Data Center and Services Module
Enrollment and
Provisioning
Catalyst 3750X or
Catalyst 3850
Access:
Full, Partial, Internet
CAPWAP
CAPWAP
ISE
Step 2: Secure Access
AD
CA
WAN
Flex 7500
CT5508 or
CT5760 WLC
Campus
Step 1: On-boarding
Catalyst 3750X or
Catalyst 3850
CAPWAP
CAPWAP
293994
3-11
Chapter 3
3-12
CH AP TE R
BYOD Use Cases

An organizations business policies will dictate the network access requirements which their BYOD
solution must enforce. The following four use cases are examples of access requirements an organization
may enforce:
Enhanced AccessThis use case provides network access for personal devices, as well as corporate
issued devices. It allows a business to build a policy that enables granular role-based application
access and extends the security framework on and off-premises.
Limited AccessThis use case enables access exclusively to corporate-issued devices.
Advanced AccessThis comprehensive use case also provides network access and for personal and
corporate issued devices. However it includes the posture of the device into the network access
control decision through integration with third party Mobile Device Managers (MDMs).
Basic AccessThis use case is an extension of traditional wireless guest access. It represents an
alternative where the business policy is to not on-board/register employee wireless personal devices,
but still provides Internet-only or partial access to the network.
ISE evaluates digital certificates, Active Directory group membership, device type, etc. to determine
which network access permission level to apply. ISE provides a flexible toolset to identify devices and
enforce unique access based on user credentials and other conditions.
Figure 4-1 shows the different permission levels configured in this design guide. These access levels may
be enforced using access lists in the wireless controller or Catalyst switches, assigning Security Group
Tags (SGTs) to the device traffic or by relying on dynamic virtual LAN (VLAN) assignment. The design
guide shows different ways to enforce the desired permissions.
Figure 4-1
Permission Levels
4-1
Chapter 4
BYOD Use Cases

This use case builds on the Limited Access use case and provides the infrastructure to on-board personal
devices onto the network by enrolling digital certificates and provisioning configuration files. The use
case focuses on how to provide different access levels to personal devices based on authentication and
authorization rules.
Employees that have registered their devices using the self-registration portal and have received a digital
certificate are granted unique access based on their Active Directory group membership:
Full AccessIf the employee belongs to the BYOD_Full_Access Active Directory group.
Partial AccessIf the employee belongs to the BYOD_Partial_Access Active Directory group.
Internet AccessIf the employee belongs to the Domain Users Active Directory group.
Corporate owned devices are granted full access in this use case.
The use case also explains how to prevent personal owned devices, for example Android devices, from
accessing the network. Some organizations may not be ready to allow employees to connect their
personal devices into the network and may decide to block their access until business or legal
requirements are met. Cisco ISE provides the capability of identifying (profiling) the device type and
preventing those devices from connecting to the network. As an example, this use case includes device
profiling in ISE to deny access to Android devices.
The use of Security Group Tags will be used as an alternative to ACLs for enforcing role-based policies
for campus wireless users and devices. Security Group Tags provide a complimentary technology
offering a scalable approach to enforcing policy and traffic restrictions with minimal and in some cases,
little or no ACLs at all if TCP/UDP port level granularity is not required.
Figure 4-2 highlights the connectivity flow for personal devices.
4-2
Chapter 4
BYOD Use Cases

Figure 4-2
Personal Devices BYOD Access

Personal
Device (Onboarded)
Wireless
EAP_TLS?
Valid
Certificate?
AD
Group?
Deny Access
Full Access
Partial Access
Internet Only
293699
In Active
Directory?
This use case provides an effective way for organizations to embrace a BYOD environment for their
employees and provide differentiated access to network resources.

This use case applies to organizations that decide to enforce a more restrictive policy that allows only
devices owned or managed by the corporation to access the network and denies access to employee
personal devices.
ISE grants devices full access to the network based on the devices certificate and inclusion in the
Whitelist identity group. This use case introduces the use of a Whitelist, a list of corporate devices
maintained by the Cisco ISE that is evaluated during the authorization phase.
Figure 4-3 shows connectivity flow for corporate devices.
4-3
Chapter 4
BYOD Use Cases
Figure 4-3
Corporate Device BYOD Access

Corporate
Device (Onboarded)
In
Whitelist?
Wireless
EAP_TLS?
Deny Access
Full Access
293995
Valid
Certificate?

This use case applies to organizations that have invested in a Mobile Device Manager (MDM) to manage
and secure mobile endpoints. While MDMs are not able to enforce Network Access Control policies,
they provide unique device posture information not available on the ISE. Combining ISE policies with
additional MDM information, a robust security policy may be enforced on mobile endpoints.
The integration between ISE and third-party MDMs is through a REST API, allowing the ISE to query
the MDM for additional compliance and posture attributes.
Figure 4-4 shows the connectivity flow to obtain MDM compliance information and network access.
4-4
Chapter 4
BYOD Use Cases

Figure 4-4
MDM Compliance
Personal
Device (Onboarded)
MDM
Registered?
ISE
Quarantine
ISE
Compliant?
MDM
Quarantine
MDM
Compliant?
API call
API call
API call
Continue AuthZ
Rules
Full Access
Partial Access
Internet Only
293989
Internet
Until MDM
Some organizations may implement a business policy which does not on-board wireless employee
personal devices, yet provides some access to corporate services and the Internet for such devices. Some
of the possible reasons include:
The organization does not have the desire or the ability to deploy digital certificates on employees
personal devices.
The employees may be unwilling to allow the organization to manage their personal device.
The organization does not wish to manage and maintain separate lists of registered devices or
manage a users network access level when using personal devices.
The design for this use case is based around extending traditional guest wireless access and providing
similar guest-like wireless access for employee personal devices. The design guide focuses on two
methods for extending guest wireless access to allow employee personal devices access to the guest
network:
Allowing employees to provision guest credentials for themselves.
Extending guest web authentication (Web Auth) to also utilize the Microsoft Active Directory (AD)
database when authenticating guests or employees using personal devices.
In addition, the design guide discusses another option in which a second guest-like wireless SSID is
provisioned for employee personal devices.
4-5
Chapter 4
BYOD Use Cases
The Basic Access use case builds on traditional wireless guest access. Figure 4-5 shows the typical
method for authenticating a device connecting to the guest wireless network.
Figure 4-5
Guest Wireless Access
Guest Device
Guest Portal
Authentication
Deny Access
Internet Only
293996
User in
Database?
This design guide discusses two approaches for modifying an existing guest wireless access
implementation to enable Basic Access for employee personal devices, as shown in Figure 4-6.
4-6
Chapter 4
BYOD Use Cases

Basic Access
Employee Devices
Share Guest SSID
Employee Devices on
Separate Guest-Like SSID
Guest or
Employee
Personal Device
Guest Portal
Authentication
Employee
Personal Device
User in
Database?
Internet Only
User in
AD?
Internet Only or
Partial Access
User in
AD?
Internet Only or
s
Partial Access
DenyAccess
DenyAccess
293997
Figure 4-6
4-7
Chapter 4
4-8
BYOD Use Cases
CH AP TE R

Revised: March 6, 2014
Whats New: A new section Link Aggregation (LAG) with the CT5508 WLC has been added. Also, the
Wireless LAN Controller High Availability section has been re-written to include 1:1 active/standby
redundancy with AP and client SSO on CUWN platforms, Catalyst 3850 switch stack resiliency, and
Cisco CT5670 wireless controller 1:1 stack resiliency.
Campus Network Design

As with the branch design, policy enforcement is effective if and only if there is a well-designed campus
network infrastructure in place. This section discusses the high-level key design elements of campus
LAN design.
The two wireless LAN designs for the campus which will be discussed within this design guide are
Centralized (Local Mode) and Converged Access designs.
Centralized (Local Mode) Wireless Design

Cisco Unified Wireless Network (CUWN) Local Mode designs, refer to wireless LAN designs in which
all data and control traffic is backhauled from the access point to a wireless controller before being
terminated and placed on the Ethernet network. This type of design is also referred to as a centralized
wireless design or centralized wireless overlay network. A typical recommended design within a large
campus is to place all of the wireless controllers into a separate services module connected to the campus
core.
The potential advantages of this design are:
Centralized access control of all wireless traffic from a single point within the campus network.
Less complexity for wireless roaming, since the wireless controllers can share larger IP address pool
for wireless clients.
The potential disadvantages of this design are:
Potential for scalability bottlenecks at the wireless controllers or the network infrastructure
connecting to the wireless controllers. This is because all wireless traffic is backhauled to a central
point within the campus network where the wireless controllers are deployed, before being
terminated on the Ethernet network. Note however, that this may be alleviated by deploying
5-1
Chapter 5
additional centralized wireless controllers, by upgrading to newer platforms such as the Cisco
CT5760 wireless controller, and/or by moving wireless controllers out to the building distribution
modules.
Less visibility of wireless traffic, since the wireless traffic is encapsulated within a CAPWAP tunnel
as it crosses the campus network infrastructure.
With a Local Mode design, access points that are connected to the access-layer switches within the
building distribution modules are configured and controlled via one or more centralized Wireless LAN
Controllers. In the case of this design guide, these controllers are a set of Cisco CT5508 wireless
controllersdedicated for the campussince they provide greater scalability for supporting Local
Mode access points than Cisco Flex 7500 wireless controllers. As mentioned previously, all data and
control traffic is backhauled from the access points to wireless controllers before being terminated and
placed onto the Ethernet network. Guest wireless traffic is backhauled across the campus infrastructure
to a dedicated CT5508 guest anchor controller located on a DMZ segment within the campus.
In order to implement the BYOD use cases, two separate methods of providing differentiated access
control for campuses utilizing a Local Mode wireless design are examined. These methods are:
Applying the appropriate dynamic ACL after the device is authenticated and authorized.
Applying the appropriate Security Group Tag (SGT) to the device after it is authenticated and
authorized.
When implementing access control via dynamic ACLs, the particular form of dynamic ACL chosen for
the design guide are RADIUS specified local ACLs, otherwise known as named ACLs. These named
ACLs must be configured on each CT5508 wireless controller. For example, a personal device which is
granted full access to the network is statically assigned to the same VLAN as a personal device which is
granted partial access. However different named ACLs are applied to each device, granting different
access to the network.
Figure 5-1 shows at a high level how a centralized (Local Mode) wireless BYOD design using named
ACLs for access control is implemented in the campus.
5-2
Chapter 5

Figure 5-1
High-Level View of the Centralized (Local Mode) Wireless Campus BYOD Design
Data Center
ISE
MSE
Building
Distribution
Prime
RSA
Infrastructure
CA
DNS,
DHCP,
NTP
CAPWAP Tunnel:
Control and Traffic
Applications
and File Servers
AD
Cloud-Based
MDM
Internet Edge
Campus
Core
Mobility Tunnel:
Guest Traffic
MDM
Internet
Services
CAPWAP
IT Devices
(MAB) SSID
Guest
VLAN
CT5508 Guest
Anchor WLCs
CT5508
WLCs
Employee
VLAN
Provisioning
VLAN
(optional)
Guest
SSID
Employee
SSID
Provisioning
SSID
(optional)
294915
Named
ACLs
MDM
On-Prem
MDM
Dynamic ACL (Named ACL) assignment applied at the wireless

controller for differentiated access control for wireless devices.
When implementing access control via Security Group Association (SGA), various source and
destination Security Group Tags (SGTs) must be configured within Cisco ISE. A personal device which
is granted full access to the network is statically assigned to the same VLAN as a personal device which
is granted partial access. However different SGTs are applied to each device, thereby granting different
access to the network.
Security Group Tag Overview

Throughout all versions of the BYOD CVD, policy enforcement has been accomplished through the use
of Access Control Lists and VLANs to restrict user traffic as appropriate upon successful authentication
and subsequent authorization. The use of ACLs can become a daunting administrative burden when
factoring the number of devices upon which they are applied and the continual maintenance required to
securely control network access.
5-3
Chapter 5
This design guide also uses a complimentary technology known as TrustSec and the use of Security
Group Tags (SGT). Security Group Tags offer a streamlined and alternative approach to enforcing
role-based policies with minimal and in some cases, little or no ACLs at all if TCP/UDP port level
granularity is not required.
The use of Security Group Tags are used as an alternative to ACLs for Campus wireless users and devices
where the Cisco Wireless Controllers have been centrally deployed in a shared services block and
configured for operation in local mode.
ACL Complexity and Considerations

To date, variations of named ACLs on wireless controllers, static and downloadable ACLs on various
routing and switching platforms, as well as FlexACLs for FlexConnect wireless traffic in the branch have
been used as a means of enforcing traffic restrictions and policies. In order to configure and deploy these
ACLs, a combination of either command line (CLI) access to each device via Telnet/SSH or network
management such as Prime Infrastructure have been required and used for statically configured ACLS
while the Cisco Identity Services Engine (ISE) has been used to centrally define and push downloadable
ACLs (DACL) to switching platforms.
Unique ACLs may be required for different locations such as branches or regional facilities, where
user permissions may need to be enforced for local resources such as printers, servers, etc.
The operational complexity of ACLs may be impacted by changes in business policies.
The risk of security breaches increases with potential device misconfigurations.
ACL definitions become more complex when policy enforcement is based on IP addresses.
Platform capabilities, such as processor memory, scalability, or TCAM resources may be impacted
by complex ACLs.
Ciscos TrustSec provides a scalable and centralized model for policy enforcement by implementing
Cisco's Security Group Access architecture and the use of Security Group Tags.
Security Group Tag

Security Group Tags, or SGT as they are known, allow for the abstraction of a hosts IP Address through
the arbitrary assignment to a Closed User Group represented by an arbitrarily defined SGT. These tags
are centrally created, managed, and administered by the ISE. The Security Group Tag is a 16-bit value
that is transmitted in the Cisco Meta Data field of a Layer 2 Frame as depicted in Figure 5-2.
Figure 5-2
Layer 2 SGT Frame Format
Authenticated
Encrypted
SMAC
802.1AE Header
CMD EtherType Version

Cisco Meta Data
5-4
Length
802.1Q
CMD
SGT Opt Type
ETYPE
PAYLOAD
SGT Value
ICV
CRC
Other CMD Options
293619
DMAC
Chapter 5

The Security Group Tags are defined by an administrator at Cisco ISE and are represented by an arbitrary
name and a decimal value between 1 and 65,535 where 0 is reserved for Unknown. Security Group
Tags allow an organization to create policies based on a users or devices role in the network providing
a layer of abstraction in security policies based on a Security Group Tag as opposed to IP Addresses in
ACLs.
For a complete overview of the Security Group Access architecture and Security Group Tags and how it
will be incorporated within the CVD, refer to Chapter 23, BYOD Policy Enforcement Using Security
Group Access.
SGT Deployment Scenarios in this CVD

Security Group Tags will be used as a means of policy enforcement in both the Limited and Enhanced
Access Use Case where a campus wireless user/device can either be terminated centrally at a Wireless
Controller in Local Mode or a Converged Access Catalyst 3850 switch and is granted either full or partial
access to the network. Different classes of servers will be defined to which those users may or may not
have access. The CVD also defines a class that has access to the Internet only through the use of an ACL
on the wireless controller to deny access to all internal addresses. The Converged Access products such
as the Catalyst 3850 and CT-5760 are addressed relative to SGT in this CVD as IOS-XE 3.3.0 introduced
support for Security Group Tags and Security Group ACL enforcement. More about SGT and the
Enhanced Use Case is discussed in the ensuing sections discussing the actual authorization policies.
Two deployment scenarios will be depicted within this CVD. The first will make use of Security Group
ACLs (SGACLs) to enforce policies at the Nexus 7000 Data Center switches as well as at a Catalyst 6500
VSS switch in the Services block, Catalyst 3850, and the CT-5760 wireless controller, whereas the
second scenario will enforce policies configured at a Cisco ASA configured as a Security Group Firewall
(SGFW). SGACLs are role-based policies enforced on Catalyst switching platforms and specifically
define whether traffic is permitted or denied based on source and destination SGT values. Again, these
deployment scenarios are not mutually exclusive and can be used together. This first scenario can be seen
in Figure 5-3 and the second scenario in Figure 5-4.
5-5
Chapter 5
Figure 5-3
Policy Enforcement Using SGACL
Aggregation/Access and
Campus Wireless
Data Center
Application
and File
Servers
SGT50
ISE
RSA
AD
CA
DC Agg
DC Agg
STOP
CAPWAP
CAPWAP
CAPWAP
STOP
CAPWAP
ASA HA
Primary
ASA HA
Secondary
DC Core
Catalyst
3750X
SGT12
DNS
and
DHCP
DC Core
Catalyst
STOP 3850
Core
Services
STOP
SGT12
5760
5508
STOP
CAPWAP
5-6
SXP
294916
SGT12
Chapter 5

Figure 5-4
Policy Enforcement Using SG-FW
Campus Wireless
Data Center
SGT50
Application
and File
Servers
ISE
RSA
AD
CAPWAP
CAPWAP
CAPWAP
CA
STOP
CAPWAP
STOP
ASA HA
Primary
SXP
Peering*
Catalyst
3750X
SGT12
DNS
and
DHCP
DC Agg
DC Agg
ASA HA
Secondary
DC Core
DC Core
Catalyst
3850
Core
Services
SGT12
5760
5508
SXP
SXP Connections*
(Only required to ASA HA Primary
294917
SGT12
CAPWAP
Campus Wired Design

Figure 5-5 shows the wired design for a campus which does not implement Converged Access Catalyst
3850 Series switches. In other words, this is the wired design for a campus which implements switches
such as the Catalyst 3750X and 4500 series at the access-layer of building distribution modules, along
with a centralized (Local Mode) wireless design.
5-7
Chapter 5
Figure 5-5
High-Level View of Non-Converged Access Wired Campus Design
Data Center
ISE
Prime
RSA
Infrastructure
CA
DNS,
DHCP,
NTP
Cloud-Based
MDM
Internet Edge
AD
Campus
Core
Building
Distribution
MDM
Internet
Employee
VLAN
Services
Downloadable
ACLs
On-Prem
MDM
Dynamic ACL (Downloadable ACL) applied at the access-layer
switch for differentiated access control for wired devices.
Wired
802.1X
294918
MDM
This design guide assumes Catalyst switches deployed as Layer 2 devices within the access-layer of the
campus building modules. Wired devices authenticate using 802.1X against the ISE server located
within the campus data center. For this design, wired devices are all statically assigned to a single
VLAN, the Employee VLAN. Differentiated access control for wired devices is provided by different
RADIUS downloadable ACLs applied to the access-layer switch, which override a pre-configured static
ACL on each Catalyst switch port.
Converged Access Campus Design

The Converged Access campus BYOD design highlights multiple Catalyst 3850 Series switches or
switch stacks deployed at the access layer of each building distribution module of a large sized campus.
Switch stacks form Switch Peer Groups (SPGs) in which all switches contain the Mobility Agent (MA)
function. Roaming within a SPG is handled through a full mesh of mobility tunnels between MAs within
the SPG. Multiple SPGs exist within the large sized campus.
5-8
Chapter 5

This design guide will assume Catalyst 3850 Series switches deployed as Layer 2 access switches within
the campus location. Layer 3 connectivity within each campus building distribution module is provided
by Catalyst 6500 distribution switches. In keeping with campus design best practices for minimizing
spanning-tree issues, VLANs are assumed not to span multiple Catalyst 3850 Series switch stacks
deployed in separate wiring closets. Future design guidance may address Catalyst 3850 Series switches
deployed as Layer 3 switches within the branch location.
Cisco CT5760 wireless controllers deployed within a centralized service module within the campus
contains the Mobility Controller (MC) function. Multiple SPGs connecting to a single MC form a
Mobility Sub-Domain. Multiple Mobility Sub-Domains exist within the large sized campus. Roaming
between SPGs within a Mobility Sub-Domain is done through the Cisco CT5760 wireless controller.
The CT5760 wireless controllers also manage Radio Resource Management (RRM), WIPs, etc.
Multiple Cisco CT5760 wireless controllers form a Mobility Group. Hence a Mobility Group also
consists of multiple Mobility Sub-Domains. Roaming between Mobility Sub-domains is done through
the Cisco CT5760 wireless controllers within the Mobility Group. The design within this design guide
assumes a single Mobility Group and hence a single Mobility Domain extends across and is entirely
contained within the large campus.
Note
Cisco CT5508 wireless controllers can also implement the Mobility Controller (MC) function within the
Converged Access campus design. However the CT5508, being an older platform has less overall
throughput than the newer CT5760 platform. This version of the design guide only discusses the CT5760
wireless controller functioning as the Mobility Controller within a Converged Access campus
deployment. Future versions of this design guide may include the CT5508 wireless controller deployed
in this manner.
Access points within the campus building distribution modules are configured and controlled via the
wireless controller Mobility Agent (MA) functionality integrated within the Catalyst 3850 Series switch.
Guest wireless traffic is still backhauled to a dedicated CT5508 guest anchor controller located on a
DMZ segment within the campus. Provisioning traffic (i.e., traffic from devices attempting to on-board
with ISE) is terminated locally on the Catalyst 3850 Series switch with the Converged Access campus
design. When implementing a dual-SSID design, provisioning traffic is terminated on a separate VLAN.
All on-boarded devices terminate on a single VLAN with this design.
Note
This design guide only discusses wireless guest access. Wired guest access may be discussed within
future revisions of this design guide.
The potential advantages of this design are as follows:
Increased scalability of the wireless deployment, since wireless traffic is terminated on every
access-layer Catalyst 3850 Series switch within the campus, instead of being backhauled to one or
more centralized wireless controllers.
Increased visibility of the wireless traffic, since wireless traffic is terminated on every access-layer
Catalyst 3850 Series switch within the campus.
The potential disadvantages of this design are as follows:
Less centralized access control of wireless traffic from a single point within the campus network.
Access control is spread out to each Catalyst 3850 Series access switch. Note however, that with
Converged Access designs, traffic from a particular WLAN can still be backhauled to a centralized
CT5760 wireless controller and switched centrally. This is touched upon in Campus Migration Path.
5-9
Chapter 5
Increased potential for more complexity for wireless roaming, since each Catalyst 3850 Series
switch implements the Mobility Agent (MA) functionality, effectively functioning as a wireless
controller.
In order to implement the BYOD use cases, the method adopted in this design guide for a campus
utilizing a Converged Access design is to apply the appropriate named ACL after the device is
authenticated and authorized. This applies to both wired and wireless devices. These named ACLs,
which must be configured on each Catalyst 3850 Series switch, provide differentiated access control.
For example, a personal device which is granted full access to the network is statically assigned to the
same VLAN as a personal device which is granted partial access. However different named ACLs are
applied to each device, granting different access to the network.
Figure 5-6 shows at a high level a simplified Converged Access BYOD design with a single Catalyst
3850 Series switch functioning as a Mobility Agent (MA) and a single CT5760 wireless controller
functioning as a Mobility Controller (MC) in the campus.
Figure 5-6
High-Level View of the Converged Access Campus BYOD Design
Data Center
ISE
MSE
Building
Distribution
Prime
RSA
Infrastructure
CA
DNS,
DHCP,
NTP
CAPWAP Tunnel:
Control and Traffic
Applications
and File Servers
AD
Cloud-Based
MDM
Internet Edge
Campus
Core
Mobility Tunnel:
Guest Traffic
MDM
Internet
Services
CAPWAP
IT Devices
(MAB) SSID
Guest
VLAN
CT5508 Guest
Anchor WLCs
CT5508
WLCs
Employee
VLAN
Provisioning
VLAN
(optional)
Dynamic ACL (Named ACL) assignment applied at the wireless

controller for differentiated access control for wireless devices.
5-10
Guest
SSID
Employee
SSID
Provisioning
SSID
(optional)
294919
Named
ACLs
MDM
On-Prem
MDM
Chapter 5

Note
The Converged Access campus BYOD design may also be referred to as the External Controller Large
Campus BYOD design within this document. Future versions of this design guide may address small
campus and/or large branch Converged Access designs, in which multiple Catalyst 3850 switch stacks
implement both the Mobility Controller (MC) and Mobility Agent (MA) functionality. In such a design,
referred to as the Integrated Controller Small Campus / Large Branch design, no external CT5760
wireless controllers are needed.
Note that in the case of this design guide, on-boarded wired devices are also statically assigned to the
same VLAN as wireless devices. Hence on-boarded wired and wireless devices will share the same
VLAN, and hence the same IP subnet addressing space. It is recognized that customers may implement
separate subnets for wired and wireless devices due to issues such as additional security compliance
requirements for wireless devices. This is not addressed within this version of the design guidance.
Dynamically assigned named ACLs provide differentiated network access for wired devices.
Assuming all campus switches implement the same set of ACLs for access control, RADIUS
downloadable ACLs may alternatively be deployed within the campus. The benefit of implementing a
downloadable ACL within the campus is that changes to the access control entries only have to be
configured once within the Cisco ISE server versus having to touch all campus Catalyst 3850 Series
switches. However this option also requires separate ISE policy rules for campus and branch Converged
Access deployments, assuming named ACLs are still deployed within branch locations.
Implementing downloadable ACLs within branch locations presents scaling issues if access to local
branch servers is required within the ACL. In such scenarios, each branch would require a separate
downloadable ACL and, therefore, a separate Cisco ISE policy rule to identify that ACL for that branch.
This becomes administratively un-scalable as the number of deployed branches increases.
Hence this design guide only discusses the use of named ACLs for access control of on-boarded devices
both within the Converged Access branch and campus designs. Because named ACLs are used for both
designs, the same Cisco ISE policies rules can be used for both Converged Access campus and branch
deployments. Hence one set of policy rules can be used for Converged Access designs regardless of
where the device is located. This reduces the administrative complexity of the Cisco ISE policy; albeit
it at the expense of increased complexity of having to configure and maintain ACLs at each campus
Catalyst 3850 Series switch.
Note
Management applications such as Cisco Prime Infrastructure may ease the burden of ACL administration
by providing a point of central configuration and deployment of named ACLs for the Converged Access
BYOD branch and campus designs.
Campus Migration Path

For large campus designs, a migration path from a traditional CUWN centralized (Local Mode) wireless
overlay network design to a Converged Access design is necessary. It is considered unfeasible for a
customer to simply flash cut a large campus over to a Converged Access design. There are many
potential migration paths from a traditional CUWN centralized design to a Converged Access design.
This section discusses one possible migration path. The steps of the migration path from the initial
overlay model are as follows:
1.
Local/Centralized Mode Only
2.
Hybrid Converged Access and Centralized
3.
Full Converged Access
5-11
Chapter 5
Each is discussed in the following sections.
Initial Overlay Model

Figure 5-7 shows the logical components for the initial state in the migration path - the Initial Overlay
Model.
Figure 5-7
Initial State in the Migration PathInitial Overlay Model
Data Center
Prime
Infrastructure
MSE
Internet Edge
Cisco ISE
Guest
Wireless
Controller
DNS and
DHCP
Services
CA
AD
Internet
Core
ASA
Firewall
CT5508
Campus
Building
CAPWAP Tunnels
Mobility Tunnels
(Old Mobility Architecture)
294920
Catalyst
3750
The initial overlay model consists of access points, operating in Local Mode, connected to Catalyst
3750-X series switches at the access-layer of individual building modules within the campus. The access
points are controlled by a CT5508 wireless controller located within a services module within the
campus. CAPWAP tunnels extend from individual access points to the CT5508 wireless controller. A
second CT5508 wireless controller on a DMZ segment within the Internet edge module functions as a
dedicated wireless guest anchor controller. A mobility tunnel extends from the campus (foreign) CT5508
wireless controller to the guest (anchor) CT5508 wireless controller.
This is the campus BYOD design which is discussed in Centralized (Local Mode) Wireless Design.
Centralized/Local Mode Only

Figure 5-8 shows the logical components for the first step in the migration pathCentralized/Local
Mode Only.
5-12
Chapter 5

Figure 5-8
First Step in Migration PathCentralized/Local Mode Only
Data Center
Prime
Infrastructure
MSE
Internet Edge
Guest
Wireless
Controller
Cisco ISE
DNS and
DHCP
CA
AD
Internet
Services
Core
ASA
Firewall
CT5508
Mobility
Group
CAPWAP Tunnels
Mobility Tunnels
(New Mobility Architecture)
CT5760
Campus
Building
Catalyst
3750
Catalyst
3750
294921
Campus
Building
Note
Note that the term Local Mode is used with CUWN controllers, while the term Centralized Mode is
used with Converged Access controllers within Cisco documentation. Both refer to the same model with
a centralized data and control plane for wireless traffic. In other words, all traffic is backhauled to the
wireless controller before being placed on the Ethernet network.
In this step of the migration path, the customer simply adds more wireless controller capacity. Since the
CT5760 is a newer platform and offers higher aggregate throughput, the customer may decide to begin
transitioning to this platform by adding them to the existing campus wireless overlay design. The
CT5760 supports up to 1,000 access points and up to 12,000 clients with up to 60 Gbps throughput per
wireless controller.
Note
The wireless capabilities of the CT5760 are not identical to Cisco Unified Wireless Network controllers
running software version 7.6. The network administrator must ensure that all the necessary features exist
in the CT5670 before migrating access points from existing CT5508 wireless controllers to CT5760
wireless controllers. For a list of supported features, refer to the CT5760 Controller Deployment Guide
5-13
Chapter 5
at:
http://www.cisco.com/en/US/docs/wireless/technology/5760_deploy/CT5760_Controller_Deployment
_Guide.html.
At this point, it is assumed that the access-layer switches within the building module wiring closets have
not reached their replacement cycle. Hence the access points, operating in local mode, are still connected
to Catalyst 3750-X series switches at the access-layer of individual building modules within the campus.
The access points are controlled by either the CT5508 or the CT5760 wireless controller located within
a services module within the campus. Both are members of the same Mobility Group. CAPWAP tunnels
extend from individual access points to either the CT5508 or CT5760 wireless controller. A mobility
tunnel extends between the CT5508 and CT5760.
A logical choice for migration to the CT5760 wireless controller would initially be at the building level.
In other words, one building of a campus could be migratedpotentially floor by floorfrom an
existing CT5508 to a CT5760 wireless controller.
In order to maintain mobility across the campus, the existing CT5508 wireless controllers need to be
upgraded to CUWN software version 7.5 or higher. CUWN software versions 7.5 and higher support the
new mobility tunneling method, which uses CAPWAP within UDP ports 16666 and 16667, instead of
Ethernet-over-IP. This is compatible with IOS XE 3.2.0 and higher software running on CT5760 wireless
controllers. Note that this includes upgrading the CT5508 wireless controller dedicated for wireless
guest access. Mobility tunnels extend from the foreign CT5508 and CT5760 wireless controllers to the
anchor CT5508 wireless controller.
Note
Centralized management of CT5760 wireless LAN controllers and Catalyst 3850 Series switches
running IOS XE software 3.3.0SE and higher currently requires Cisco Prime Infrastructure 2.0.1.
Centralized management of CUWN wireless LAN controllers running software version 7.6 currently
requires Cisco Prime Infrastructure 1.4.1. In other words, two instances of Cisco Prime Infrastructure
may be required currently if the customer wishes to support a model in which both CUWN and
Converged Access infrastructure is deployed within the network and centralized management via Cisco
Prime Infrastructure is a requirement.
Hybrid Converged Access and Local Mode

Figure 5-9 shows the logical components for the second step in the migration patha Hybrid Converged
Access and Local Mode model.
5-14
Chapter 5

Figure 5-9
Second Step in Migration PathHybrid Converged Access and Local Mode

CAPWAP Tunnels
Data Center
Prime
Infrastructure
Mobility Tunnels
MSE
Internet Edge
Guest
Wireless
Controller
Cisco ISE
DNS and
DHCP
CA
AD
Internet
Services
Core
ASA
Firewall
CT5508
Mobility
Group
MC MA
CT5760
Campus
Building
Campus
Building
Campus
Building
Catalyst
3750
Catalyst
3750
Switch Peer
Group
MA
MA
Catalyst
3850
294922
Catalyst
3850
At this point in the migration path, it is assumed that the access-layer switches within the building
module wiring closets have begun to reach their replacement cycle. In this scenario, the customer has
chosen to deploy Catalyst 3850 Series switches at the access-layer of their building modules and begin
migrating to a converged access model. Again, a logical choice for migration would be at the building
level. In other words, one building of a campus would be migratedpotentially floor by floorfrom
access points operating in centralized mode connected to a Catalyst 3750-X Series switch and controlled
by the CT5760, to access points operating in converged mode connected to and controlled by a Catalyst
3850 Series switch.
With this design, the Catalyst 3850 Series switches function as the Mobility Agent (MA), while the
CT5760 wireless controller functions as the Mobility Controller (MC) and possibly the Mobility Oracle
(MO). However during the migration of floors, the CT5760 wireless controller will still have to function
in centralized mode as well for access points still connected to Catalyst 3750-X series switches. Hence
the design is a hybrid of centralized and converged access designs.
CAPWAP tunnels extend from individual access points which are connected to Catalyst 3750-X Series
switches to either the CT5508 or CT5760 wireless controller. CAPWAP tunnels also extend from
individual access points which are connected to Catalyst 3850 Series switches to the Catalyst 3850
Series switches. Mobility tunnels extend from the MA within the Catalyst 3850 Series switches to the
5-15
Chapter 5
MC within the CT5760 wireless controller. Finally, mobility tunnels extend between MAs within the
Catalyst 3850 Switches which are part of a Switch Peer Group (SPG). SPGs offload mobility traffic for
groups of switches in which a large amount of mobility is expected. When roaming between access
points connected to Catalyst 3850 Series switches which are part of the same SPG, the MC located
within the CT5760 is not involved in the roam. A SPG may extend across part of a floor within a
building, the entire floor, or in some cases multiple floors. A mobility tunnel (using the new mobility
architecture) also extends between the CT5508 and CT5760. Finally, mobility tunnels (using the new
mobility architecture) extend from the foreign CT5508 and CT5760 back to the anchor CT5508 for
wireless guest access.
Full Converged Access

Figure 5-10 shows the logical components for the third step in the migration paththe Full Converged
Access model.
Figure 5-10
Third Step in Migration PathFull Converge Access

CAPWAP Tunnels
Data Center
Prime
Infrastructure
Mobility Tunnels
MSE
Internet Edge
Guest
Wireless
Controller
Cisco ISE
DNS and
DHCP
CA
AD
Internet
Services
Mobility
Group
Core
ASA
Firewall
CT5760
MC MA
MC MA
CT5760
Campus
Building
Campus
Building
Switch Peer
Group
MA
MA
Catalyst
3850
MA
Catalyst
3850
MA
Catalyst
3850
294923
Catalyst
3850
SPG
SPG
5-16
Chapter 5

This design assumes the customer has retired existing CT5508 wireless controllers operating in Local
Mode and moved to a converged access design with CT5670 wireless controllers. At this point in the
migration path, it is assumed that the access-layer switches within the building module wiring closets
have completed their replacement cycle. In this scenario, the customer has chosen to deploy only
Catalyst 3850 Series switches at the access-layer of their building modules and completely migrate to a
converged access model.
Note
We realize that some customers may never fully migrate to a full Converged Access model, while others
may take years to reach a full Converged Access deployment.
With this design, the Catalyst 3850 Series switches function as the Mobility Agent (MA), while the
CT5760 wireless controller functions as the Mobility Controller (MC) and possibly the Mobility Oracle
(MO).
CAPWAP tunnels extend from individual access points which are connected to Catalyst 3850 Series
switches to the Catalyst 3850 Series switches. Mobility tunnels extend from the MA within the Catalyst
3850 Series switches to the MC within the CT5760 wireless controller. Mobility tunnels extend between
MAs within the Catalyst 3850 Switches which are part of a Switch Peer Group (SPG). A mobility tunnel
also extends between the two CT5760 wireless controllers. Finally, mobility tunnels (using the new
mobility architecture) extend from the foreign CT5760 wireless controllers back to the anchor CT5508
for wireless guest access.
Note
Roaming between sub-domains (i.e., roaming between two CT5760 wireless controllers functioning as
MCs) has not been validated with this version of the design guide.
Link Aggregation (LAG) with the CT5508 WLC

Cisco CT5508 wireless controllers have eight Gigabit Ethernet distribution system ports, for a maximum
platform throughput of approximately 8 Gbps. Typically one or more WLANswhich correspond to
SSIDsare mapped to a dynamic interface, which is then mapped to a physical distribution system port.
In a campus centralized (local mode) deployment, wireless traffic is backhauled across the campus
network infrastructure and terminated on the Gigabit Ethernet distribution ports of the CT5508 WLC.
With the use of a single physical distribution system port per WLAN, the throughput of each WLAN is
limited to the throughput of the 1 Gbps physical distribution system port. Hence an alternative is to
deploy link aggregation (LAG) across the distribution system ports, bundling them into a single high
speed interface, as shown in Figure 5-11.
5-17
Chapter 5
Figure 5-11
Link Aggregation (LAG) Between the CT5508 WLC and Attached Catalyst 6500 VSS
Pair
Cisco 5508 WLC
Catalyst 6500 VSS Pair
294924
Single LAG Group:

Distribution Ports 1-8
Management Interface
Dynamic Interfaces
Cisco 5508 wireless controllers support the ability to configure all eight Gigabit Ethernet distribution
system ports into a single LAG group. This is the load-balancing mechanism validated for CT5508
WLCs within the campus deployed as centralized (local mode) controllers within the design guide.
Note
This discussion of LAG does not include CT5508 wireless LAN controllers deployed in a 1:1
active/standby redundancy pair at this time.
An example of the configuration of LAG on a CT5508 wireless controller is shown in Figure 5-12.
Figure 5-12
Configuration of Link Aggregation (LAG) on a CT5508 Wireless LAN Controller
5-18
Chapter 5

When using LAG, the switch or switches (in the case of a VSS group) to which the CT5508 wireless
controller is attached must be configured for EtherChannel support. The following shows an example
configuration on a Catalyst 6500 Series VSS pair in which the eight GigabitEthernet interfaces are split
across both switches within the VSS pair.
!
vlan 2
name BYOD-Employee
!
vlan 3
name BYOD-Provisioning
!
vlan 45
name ua28-wlc5508-3-mgmt
!
vlan 450
name ua28-5508-3-users
!
interface Port-channel45
description LAG to ua28-wlc5508-3
switchport
switchport trunk allowed vlan 2,3,45,450
switchport mode trunk
load-interval 30
!
interface GigabitEthernet1/2/45
description ua28-wlc5508-3
switchport
load-interval 30
channel-group 45 mode on
!
switchport
load-interval 30
!
switchport
load-interval 30
!
switchport
load-interval 30
!
switchport
load-interval 30
5-19
Chapter 5
Wireless LAN Controller High Availability
!
switchport
load-interval 30
!
switchport
load-interval 30
!
switchport
load-interval 30
!
interface Vlan2
description BYOD-Employee VLAN for Functional Testing
ip address 1.231.2.1 255.255.255.0
ip helper-address 1.230.1.61
!
interface Vlan3
description BYOD-Provisioning VLAN for Functional Testing
ip address 1.231.3.1 255.255.255.0
!
interface Vlan45
description AP-Manager IP for ua28-wlc5508-3
ip address 1.225.45.1 255.255.255.0
!
interface Vlan450
ip address 1.228.128.1 255.255.192.0
!

High availability of the wireless infrastructure is becoming increasingly important as more devices with
critical functions move to the wireless medium. Real-time audio, video, and text communication relies
on the corporate wireless network and the expectation of zero downtime is becoming the norm. The
negative impacts of wireless network outages are just as impactful as outages of the wired network.
Implementing high availability within the wireless infrastructure involves multiple components and
functionality deployed throughout the overall network infrastructure, which itself must be designed for
high availability. This section discusses wireless LAN controller platform level high availability specific
to the implementation of wireless controller platforms within the Cisco BYOD design. Platform-level
(box-to-box) redundancy refers to the ability to maintain wireless service when connectivity to one or
5-20
Chapter 5

more physical wireless LAN controller platforms within a site is lost. Figure 5-13 shows the WLC
platforms within the Cisco BYOD design.
Figure 5-13
Wireless LAN Controller Platform High-Availability
CUWN Centralized Campus Building Design
Data Center
Services
Prime
Infrastructure
CAPWAP
Catalyst 3750X
Switch Stack
CUWN Converged Access Campus
Building Design
CAPWAP
MSE
CT5508 WLCs
RSA
Flex 7510 WLCs
ISE
CA
3
AD
Catalyst 3850
Switch Stack
CUWN FlexConnect Design
CT5760 WLCs
DNS,
DHCP, NTP
Applications and
File Servers
WAN Edge
Internet Edge
CAPWAP
CT5508
WLCs
Core
Catalyst 3750X
Switch Stack
ASA
WAN
CAPWAP
Catalyst 3850
Switch Stack
MPLS
WAN
MDM
On-Prem
MDM
DMVPN
Internet
Cloud-Based MDM
MDM
294926
Branch Converged Access Design
The platforms highlighted in Figure 5-13 are as follows:
Cisco CT5508 wireless LAN controllers (Circle 1) servicing campus APs operating in centralized
(local) mode and/or functioning as dedicated guest controllers.
Cisco Flex 7510 wireless LAN controllers (Circle 2) servicing branch APs operating in FlexConnect
mode.
Cisco CT5760 wireless LAN controllers (Circle 3) servicing campus APs operating in centralized
mode and/or functioning as Mobility Controllers (MCs) in a campus Converged Access design.
Catalyst 3850 Series switches (Circle 4) functioning as Mobility Agents (MAs) servicing APs in a
campus converged access design and/or functioning as Mobility Agents (MAs) and Mobility
Controllers (MCs) in a branch Converged Access design.
Table 5-1 shows the methods of providing platform level redundancy of Cisco WLC platforms discussed
within this design guide.
5-21
Chapter 5
Table 5-1
Wireless Controller Platform Redundancy
Platform
Platform (Box-to-Box) Redundancy
Cisco CT5508 Wireless LAN Controller 1:1 Active/Standby Redundancy

with AP & Client SSO
Cisco Flex 7510 Wireless LAN
Controller
1:1 Active/Standby Redundancy

with AP & Client SSO
Cisco CT5760 Wireless LAN Controller 1:1 Stack ResiliencyCisco IOS

Software SSO
Cisco 3850 Series Switch Stack
Stack ResiliencyCisco IOS

Software SSO
The following sections discuss the deployment of platform-level high availability on specific Cisco
wireless LAN controllers as they are deployed within the Cisco BYOD design.
Cisco Unified Wireless Network (CUWN) Controllers

This section discusses platform high availability mechanisms for the following CUWN wireless LAN
controller platforms:
Cisco CT5508 WLC platforms deployed within the campus of the Cisco BYOD design servicing
campus APs operating in centralized (local) mode.
Cisco Flex 7510 WLC platforms deployed within the campus of the Cisco BYOD design servicing
remote branch APs operating in FlexConnect mode.
CUWN platforms support two forms of platform redundancy:
1:1 active/standby redundancy with AP and client SSO
The older form of high availability known as N+1 redundancy
This design guide has not validated N+1 redundancy as a means of achieving platform high availability.
Instead, it utilizes 1:1 active/standby redundancy with AP and client SSO. The N+1 High Availability
Deployment Guide provides guidance around N+1 redundancy:
http://www.cisco.com/en/US/docs/wireless/technology/hi_avail/N1_High_Availability_Deployment_G
uide.pdf
1:1 Active/Standby Redundancy with AP and Client SSO

In CUWN software release 7.3, the ability to have a 1:1 active/standby pair of wireless LAN controllers
with AP stateful switch over (SSO) was introduced. This capability allows access points to perform a
rapid stateful switch over to a hot-standby wireless LAN controllerwith an identical configuration to
the primary WLCin the event of a failure of the active WLC. All unique configuration parameters and
groupings specific to individual APs and AP groups are retained. An example of retained configuration
is FlexConnect grouping, which applies different restrictions and settings to sub-sets of APs based on
branch location.
An example of 1:1 active/standby redundancy (using a single physical distribution system port) with AP
SSO is shown in Figure 5-14.
5-22

Figure 5-14
Example of 1:1 Active/Standby Redundancy with AP SSO
Local HA Pair
Redundant Port
Ethernet Cable
RP: 169.254.147.103
RP: 169.254.147.104
Active
CWN
WLC
Standby
CUWN
WLC
Distribution System Port

Mgmt. Interface: 10.225.147.3
RMI 10.225.147.103
Dynamic Interfaces
Management Interface and
Redundancy Management Interface
(RMI) must be on the same IP subnet
(Layer 2 VLAN connectivity). Last two
octets of the RMI address is used in
the RP address.

RMI 10.225.147.104
Dynamic Interfaces
Network
Infrastructure
CAPWAP
294927
Chapter 5
In CUWN software release 7.5, the ability to have a 1:1 active/standby pair of wireless controllers was
extended to allow both APs and wireless clients to perform a rapid stateful switch over. As with the
previous version of SSO, unique configuration parameters and groupings specific to individual APs and
AP groups are retained. With CUWN software releases 7.5 and higher, wireless clients in the RUN state
also remain associated when a failover occurs.
An example 1:1 active/standby redundancy with AP and client SSO (using a single physical distribution
system port) is shown in Figure 5-15.
5-23
Chapter 5
Figure 5-15
Example of 1:1 Active/Standby Redundancy with AP and Client SSO
Local or Remote HA Pair

Redundant Port
Ethernet Cable or Switch Connection
Active
CUWN WLC
Standby
CUWN WLC
RP: 169.254.147.103
Management Interface and

Redundancy Management Interface
(RMI) must be on the same IP subnet
(Layer 2 VLAN connectivity). Last two
octets of the RMI address is used in
the RP address.
Note

RMI 10.225.147.104
Dynamic Interfaces
Network
Infrastructure
CAPWAP
294928

RMI 10.225.147.103
Dynamic Interfaces
In Figure 5-15, the redundant ports are connected to the same switch as the distribution system ports.
However the redundant ports can be connected via a completely different switch (or switches) depending
on the deployment.
1:1 active/standby redundancy with AP and Client SSO is supported on the following CUWN WLC
platforms:
Note
Cisco 5500 Series
Cisco Flex 7500 Series
Cisco 8500 Series
Cisco WiSM2
1:1 active/standby redundancy with AP SSO is not supported on the virtual wireless LAN controller
(vWLC) platform or the Cisco 2500 Series wireless LAN controller platform. 1:1 active/standby
redundancy with AP and client SSO is also currently not supported by the new (hierarchical) mobility
architecture. Hence 1:1 active/standby with AP and client SSO cannot be supported in the hybrid design
discussed in Hybrid Converged Access and Local Mode.
With 1:1 active/standby redundancy, the active and standby WLCs use a dedicated redundant port (RP).
In CUWN software releases 7.3 and 7.4, it is highly recommended that the redundant ports (RP) of both
WLCs be directly connected by an Ethernet cable. With CUWN software releases 7.5 and higher, the
requirement that the wireless controllers be connected via a dedicated cable between the redundant ports
(RPs) has been removed. The redundant ports (RPs) can now be connected via one or more Layer 2
switches. The following are the requirements for connectivity between WLC when in a 1:1 HA remote
configuration:
5-24
Chapter 5

Note
Redundant Port (RP) round trip time (RTT) must be less than 80 milliseconds if the keepalive timer
is left to its default of 100 milliseconds OR 80% of the keepalive timer if the keepalive timer is
configured within the range of 100-400 milliseconds.
Failure detection time is 3 * 100 = 300 + 60 = 360 + jitter (12 milliseconds) = ~400 milliseconds
Bandwidth between redundant ports (RPs) must be 60 Mbps or higher
MTU: 1500 bytes or larger
Because the direct connectivity requirement has been removed, 1:1 active/standby redundancy with AP
and client SSO could be used for platform (box-to-box) redundancy and/or for site-to-site redundancy,
since both the active and standby controllers no longer need to be in physical proximity to each other.
Site-to-site redundancy, in which the 1:1 active/standby CUWN wireless controllers are located in
separate data centers, has not been validated as part of the Cisco BYOD design guide.
UDP keepalive messages are sent every 100 milliseconds by default from the standby WLC to the active
WLC via the redundant port (RP). Configuration, operational data synchronization, and role negotiation
information are also synchronized between the active and standby WLCs via the redundant port (RP).
The IP address of the RP is not user-configurable. The first two octets are always 169.254. The last
two octets are the same as the redundancy management interface (RMI).
The RMI is an additional interface which must be configured to be on the same IP subnet as the
management interface. The active WLC checks to see if the gateway is available by sending an ICMP
ping on the management interface every second. Likewise, the standby WLC checks to see if the gateway
is available by sending an ICMP ping on the RMI every second. The standby WLC will also check the
health of the active WLC via the RMI if the active WLC stops responding to keepalive messages sent
via the redundant port (RP).
Failovers are triggered by loss of keepalive messages as well as network faults. Hence the rate at which
UDP keepalive messages are sent has a direct influence on how fast failover occurs. The loss of three
UDP keepalive messages (along with three ICMP packets which are immediately sent across the RMI
when packet loss is detected across the RP) causes the standby controller to assume the active role. The
UDP keepalive messages can be sent between every 100 milliseconds to 400 milliseconds, in 50
millisecond increments.
CUWN WLCs implement a 1:1 active/standby model for both the control plane and the data plane. Only
the active WLC is up from a control and data plane perspective until a failure occurs. APs do not go into
the DISCOVERY state and therefore do not need to establish a new CAPWAP connection or download
new configuration before accepting wireless client associations. When the previous active WLC
recovers, it will negotiate with the current active WLC to become the standby WLC. In other words,
there is no preempt functionality.
Within the BYOD campus local mode design, all wireless clients connected to APs managed by a local
Cisco 5508 WLC were de-authenticated and dis-associated upon failover to the standby WLC with
CUWN software releases 7.3 and 7.4. Wireless clients had to re-associate and re-authenticate since client
state information was not maintained. Thus the overall recovery time was dependent upon the number
of wireless clients and the authentication mechanism. With CUWN software releases 7.5 and higher,
existing wireless clients in the RUN state remain authenticated and associated since client state
information is maintained between the active and standby WLCs. Therefore the overall recovery time
can be much faster.
Within the BYOD branch FlexConnect design, APs operating in FlexConnect mode managed by a
remote Flex 7510 wireless controller went into standalone mode when the connection to the wireless
controller was lost with CUWN software releases 7.3 and 7.4. Existing wireless clients were not
de-authenticated and dis-associated, as is the case with wireless clients connected to APs operating in
centralized (local mode) managed by a Cisco 5508 wireless controller. However new wireless clients
5-25
Chapter 5
cannot associate and authenticate to the branch wireless network when centralized authentication is
configured for the WLAN and the access point is in standalone mode. Hence 1:1 active/standby
redundancy with AP and client SSO may also provide benefits to a branch FlexConnect wireless
deployment. However unless the 1:1 active/standby pair of Flex 7510 wireless controllers are deployed
in separate sites with a Layer 2 connection between them, site-to-site redundancy will not be
accomplished. In this case, N+1 redundancy may provide an alternative form of high availability (both
platform and site-to-site) for branch FlexConnect designs.
Configuring 1:1 Active/Standby Redundancy with AP and Client SSO

The steps for configuring 1:1 active/standby redundancy with AP and client SSO are the same as for
configuring 1:1 active/standby redundancy with only AP SSO. There is only a single configuration
option which enables both AP and client SSO. There is no option for enabling one without the other.
Before enabling SSO, the management interfaces of the primary (active) and secondary (hot standby)
wireless LAN controllers must be configured to be on the same subnet. Figure 5-16 shows an example
of the configuration of the IP address of the management interface of a CUWN wireless controller.
The IP address for the management interface in the example in Figure 5-16 is configured to be
10.225.147.3/24. Assuming this is to be the primary (active) wireless controller of the HA pair, the IP
address of the management interface of the secondary (standby) wireless controller would need to be
configured to also be on the 10.225.147.0 subnet. For example the management interface of the
secondary (standby) wireless controller could be configured to be 10.224.147.4/24.
5-26
Chapter 5

Figure 5-16
Configuring the IP Address of the Management Interface
Next, the IP address of the Redundancy Management Interface (RMI) of each wireless LAN controller
(the primary and the secondary) in the HA pair must be configured to be in the same IP subnet as the
Management Interface. This is done through the Redundancy-->Global Configuration screen.
Figure 5-17 shows an example of the configuration of the IP address of the RMI and the IP address of
the peer RMI on the primary CUWN wireless controller.
5-27
Chapter 5
Figure 5-17
Configuring the IP Addresses of the Redundancy Management Interface (RMI) and the
Peer RMI
The IP address for the RMI in the example in Figure 5-17 is configured to be 10.225.147.103. Assuming
this is to be the primary (active) wireless controller of the HA pair (as selected in the figure), the IP
address of the RMI of the peer (standby) wireless controller would need to be configured to also be on
the 10.225.147.0 subnet. For example the RMI of the peer (standby) wireless controller is shown to be
10.224.147.104.
Note that the configuration of the peer RMI shown above simply informs the wireless controller of the
IP address of the RMI of the peer wireless controller. It does not configure the IP address of the RMI of
the peer. The same configuration step needs to be done on the secondary (standby) wireless controller.
However, on the secondary (standby) wireless controller, its RMI would be configured with an IP address
of 10.224.147.104 given the example above. Likewise, the secondary (standby) wireless controller peer
RMI would be configured with an IP address of 10.224.147.103.
After configuring the IP addresses of the RMI and the peer RMI on both wireless controllers and
selecting one unit as the primary (active) wireless controller and the other unit as the secondary (standby)
wireless controller, the network administrator must click the Apply button before enabling SSO.
Note
As of CUWN software release 7.3 and above, a factory ordered HA SKU is orderable. If a factory
ordered HA SKU is part of the HA pair, it will automatically default to the role of the standby wireless
controller when paired with an active wireless controller with a valid AP count license.
After clicking the Apply button the network administrator can then enable SSO by selecting Enabled
from the drop down menu next to the SSO field, as shown in Figure 5-18.
5-28
Chapter 5

Figure 5-18
Enabling AP and Client SSO on CUWN Wireless Controllers
The wireless controllers will reboot upon clicking the Apply button and negotiate their respective HA
roles based upon their configuration. Once the wireless controllers have rebooted, the secondary
(standby) WLC will proceed to download its configuration from the primary (active) WLC. Upon
downloading its configuration, the secondary (standby) WLC will reboot again. Once the secondary
(standby) WLC has rebooted for the second time, it will verify its configuration is synchronized with the
primary (active) WLC, and assume the role of the standby wireless controller. Note that default
information such as the IP address of the Redundancy Port (RP) and the IP address of the peer RP will
be automatically populated once SSO has been enabled.
Finally, Figure 5-19 shows how the keepalive timer can be modified in order to influence the failover
time.
Figure 5-19
Configuring the Keepalive Timer to Influence Failover Time
As mentioned previously, UDP keepalive messages can be sent between every 100 milliseconds to every
400 milliseconds, in 50 millisecond increments.
For more information regarding active/standby redundancy with AP SSO, refer to the High Availability
(AP SSO) Deployment Guide:
http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080bd3504.shtml
5-29
Chapter 5
Converged Access Controllers

This section discusses platform high availability mechanisms for the following Converged Access (IOS
XE based) WLC platforms:
Catalyst 3850 switches functioning as Mobility Agents (MAs) and Mobility Controllers (MCs)
deployed within a branch Converged Access design.
Catalyst 3850 switches functioning as MAs along with Cisco 5760 WLCs functioning as MCs
deployed within a campus Converged Access design.
Cisco 5760 wireless controllers servicing APs operating in local mode within a campus centralized
(non-Converged Access) design.
Catalyst Switch Stack Resiliency

Catalyst 3850 Series switches support StackWise technology along with Cisco IOS software SSO for
providing resiliency within the switch stack. Catalyst switch stack resiliency is the method of providing
high availability for Catalyst 3850 Series switches deployed in a Converged Access branch design. This
is shown in Figure 5-20.
Figure 5-20
Catalyst 3850 Switch Stack Resiliency
Active and Standby

Cisco ISR G2 Routers
Redundant Connections
Across the Switch Stack
Stack Cables
Standby
Stack Master
MA
CAPWAP
Up to nine Catalyst 3850 switches per

stack with IOS XE 3.3.0SE and higher
294933
CAPWAP
MC
Active
Stack Master
In the Converged Access campus design, Catalyst switch stack resiliency also provides high availability
for the Catalyst 3850 Series switches functioning as MAs. Cisco CT5760 wireless controller 1:1 stack
resiliency provides high availability for the MC function. This is discussed in the next section.
Catalyst switch stack resiliency has been supported for Catalyst 3850 Series switches since IOS XE
software release 3.2.0SE. Catalyst 3850 Series switches support Cisco StackWise-480 stacking ports
along with copper-based Cisco StackWise cabling for a stack bandwidth of approximately 480 Gbps.
Note
N+1 platform redundancy is not supported for access points connected to Catalyst 3850 switches
operating in a converged access deployment.
5-30
Chapter 5

With IOS XE software release 3.3.0SE and higher, the number of Catalyst 3850 Series switches which
can be supported in a single switch stack has been increased from four to nine switches. The stack
behaves as a single switching unit that is managed by an active switch elected by the member switches.
The active switch automatically elects a standby switch within the stack. The active switch creates and
updates all the switching/routing/wireless information and constantly synchronizes that information
with the standby switch. If the active switch fails, the standby switch assumes the role of the active
switch and continues to the keep the stack operational. Access points continue to remain connected
during an active-to-standby switchover. Wireless clients are dis-associated and need to re-associate and
re-authenticate. Hence the recovery time is dependent upon how many wireless clients need to be
re-associated and re-authenticated, as well as the method of authentication. No configuration commands
are required in order to enable switch stack resiliency on Catalyst 3850 and/or 3650 Series switches; it
is enabled by default when the switches are connected via stack cables.
Cisco CT 5670 Wireless Controller 1:1 Stack Resiliency

As of IOS XE software release 3.3.0SE and higher, Cisco CT5760 wireless controllers support 1:1 stack
resiliency, similar to that supported by Catalyst 3850 Series switches. However only two CT5760
wireless controllers can be connected in a high availability stack. An example of 1:1 stack resiliency on
the CT5760 is shown in Figure 5-21.
Figure 5-21
Cisco CT5760 WLC 1:1 Stack Resiliency
Centralized Campus Deployment
Converged Access Campus Deployment

Active WLC
Standby WLC
MC
CT 5760 HA Pair
Stack Cable
Stack Cable
Active WLC
CT 5760 HA Pair
Standby WLC
MC
Network Infrastructure
Stack Cable
CT 5760 HA Pair
Network Infrastructure
CAPWAP
MA
CAPWAP
CAPWAP
294934
CAPWAP
1:1 stack resiliency is the method of providing platform-level high availability for CT5760 wireless
controllers servicing APs operating in a centralized campus design within this design guide because it
can provide faster overall recovery for wireless clients. Prior to IOS XE software release 3.3.0SE, N+1
redundancy defined at the access point (which is still supported) was the only method of providing
platform-level redundancy when the CT5760 was operating as a centralized controller within a campus
design.
5-31
Chapter 5
Branch Wide Area Network Design
Note that high availability on the CT 5760 wireless controller is different than high availability on
CUWN wireless controllers. With CT 5760 1:1 stack resiliency, the data planes of both WLCs are active
although the maximum throughput of the stack is still approximately 80 Gbps. The control plane of one
of the CT 5760s is active, while the control plane of the other is in standby. The active WLC creates and
updates all the switching/routing/wireless information and constantly synchronizes that information
with the standby WLC. If the active CT 5760 fails, the standby CT 5760 assumes the role of the active
WLC and continues to the keep the stack operational. Access points continue to remain connected during
an active-to-standby switchover. Wireless clients are dis-associated and need to re-associate and
re-authenticate. Hence the recovery time is dependent upon how many wireless clients need to be
re-associated and re-authenticated, as well as the method of authentication.
1:1 stack resiliency is also the method of providing high availability of CT5760 wireless controllers
which function as Mobility Controllers (MCs) in the Converged Access campus design, as shown in
Figure 5-21. Prior to IOS XE software release 3.3.0SE, the only way of providing high availability of
the MC function in a Converged Access campus design was to manually re-configure each Catalyst 3850
Series switch stack (functioning as an MA) to point to a different CT 5760 wireless controller
(functioning as an MC) upon failure of the original CT5760. Hence IOS XE software release 3.3.0SE
and higher provides a significant step forward in providing high availability in a Converged Access
campus design.
No configuration commands are required in order to enable 1:1 stack resiliency on CT5760 wireless
controllers; it is enabled by default when two WLCs are connected via a stack cable.

Many network administrators will re-examine the wide area network (WAN) prior to deploying a BYOD
solution at the branch. Guest networks in particular have the ability to increase loads to a rate that can
consume WAN bandwidth and compromise corporate traffic. While wired rates have increased from 10
Mbps to 1 Gbps and cellular networks have increase bandwidth from 30 Kbps for GPRS to around 20
Mbps for LTE, traditional branch WAN bandwidths have not experienced the same increase in
performance. Employees and guests expect bandwidth, delay, and jitter on the corporate network to be
at least as good as they experience at home or on the cellular network.
Furthermore, because WiFi access is typically free for corporate users and because most hand held
devices will prefer WiFi over cellular, corporate users will likely continue using the guest or corporate
SSID for Internet access, even when the LTE network offers faster speeds. This is forcing network
administrators to explore new WAN transport mechanisms such as Metro Ethernet and VPN-over-Cable
to meet user expectations. Another approach is to offload guest Internet traffic at the branch in an effort
to preserve WAN bandwidth for corporate traffic. Corporate Security Policy will need to be considered,
however, before providing direct Internet access from the branch. As a result, the WAN is experiencing
increased loads. While there are no new WAN requirements for branch BYOD services, some areas such
as transport technology, access speeds, and encryption should be reviewed.
Branch WAN Infrastructure

The branch WAN infrastructure within this design includes Cisco ASR 1006s as the head-end routers.
Two different WAN connections are terminated on these devices; the first router is configured as a
service provider MPLS circuit and the second router is configured with an Internet connection. These
head-end routers are both placed in a WAN edge block that exists off of the campus core. The ASR
that terminates the Internet connection also makes use of IOS Zone-Based Firewall (ZBFW) and only
tunneled traffic towards the branch is permitted.
5-32
Chapter 5

Within the branch, two different designs have been validated. The first design consists of two Cisco 2921
ISR-G2 routers. One of the two routers terminates the SP MPLS circuit, while the second router
terminates the Internet connection which can be utilized as a branch backup exclusively or as an alternate
path for corporate traffic. The second design consists of a single Cisco 2921 ISR-G2 router that
terminates both circuits.
In both deployment modes, the Cisco IOS Zone-Based Firewall (ZBFW) has been implemented to
protect the branch's connection to the Internet. Although entirely feasible, local Internet access from the
branch is not permitted. For this purpose as well as for corporate data, DMVPN has been implemented
and only tunnel access granted for secure connectivity back to the campus head-end routers. This
provides for access to the data center. Internet access is available through the corporate firewall/gateway.
DMVPN is additionally used to secure traffic across the service provider's MPLS circuit.
It is beyond the scope of this document to provide configuration information and design guidance around
DMVPN, ZBFW configuration, QOS, and other aspects of the WAN infrastructure.
For detailed reference information around Next Generation Enterprise WAN (NGEW) design, refer to
the documentation on Design Zone:
http://www.cisco.com/en/US/netsol/ns816/networking_solutions_program_home.html.
For additional QOS Design Guidance, refer to the Medianet Design Guide at:
http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns819/landing_vid_medianet.html.
Branch WAN Bandwidth Requirements

This design guide presents two branch wireless LAN designsFlexConnect and Converged Access. In
FlexConnect designs, branch access points are managed by a wireless LAN controller in the campus data
center or services module. A CAPWAP tunnel is established between the wireless controller and each of
the access points within the branch locations. This CAPWAP tunnel is used for control traffic and
possibly data traffic during the on-boarding process in some designs. This traffic is transported over the
WAN. Even though devices may use a FlexConnect design to locally terminate traffic onto local VLANs
within the branch, a large percentage of traffic will continue to flow over the WAN to the corporate data
center.
In Converged Access designs, branch access points are managed by the integrated wireless LAN
controller functionality within the Catalyst 3850 Series switch. A CAPWAP tunnel is established
between the Catalyst 3850 Series switch and the access points within the branch locations. This
CAPWAP tunnel is used for all wireless control and data traffic. However, even though devices may use
a Converged Access design to locally terminate traffic onto local VLANs within the branch, a large
percentage of traffic will again continue to flow over the WAN to the corporate data center.
Since both branch wireless LAN designs presented in this document utilizes a centralized AAA server
(such as Cisco ISE), there may be an increase in authentication and authorization traffic as more
employee managed devices are on-boarded. These new endpoints may also generate additional new
traffic. Further, guest Internet access is carried back to an anchor controller in the campus DMZ with
both branch wireless LAN designs. All of this may result in increased loads on the WAN circuit as a
result of the BYOD deployment.
It may be difficult to forecast the additional amount of traffic loading because the level of participation
may not be well known prior to deploying BYOD. Wireless guest traffic in particular can be difficult to
budget and may vary substantially depending on local events. A reasonable design goal is to provision
a minimum of 1.5 Mbps at each branch that offers BYOD. The head-end WAN aggregation circuits
should be provisioned to follow traditional oversubscription ratios (OSR) for data. This will allow
adequate bandwidth for smaller deployments. Larger branch locations will likely need additional
bandwidth, especially if the guest users are likely to expect the use of high bandwidth applications such
as streaming video traffic. The WAN architecture should offer enough flexibility to adjust service levels
5-33
Chapter 5
Branch LAN Network Design
to meet demand. Sub-rate MPLS access circuits or a dedicated WAN router with incremental bandwidth
capabilities can accomplish this. Address space adequate for each branch should also be considered
because both FlexConnect and Converged Access designs can allow wireless DHCP clients to pull from
local scopes. Additional information concerning bandwidth management techniques such as
rate-limiting is discussed in Chapter 21, BYOD Guest Wireless Access.
Encryption Requirement
Another component of both BYOD enabled branch wireless LAN designs is local termination of branch
wireless traffic. This allows branch wireless devices to directly access resources located on the branch
LAN without the need to traverse a CAPWAP tunnel to a centralized wireless controller. This reduces
the amount of traffic that needs to be carried by the WAN by eliminating the hair-pinning of traffic from
the branch location, back to the wireless controller within the campus, and then back to the branch server.
The effect reduces load in both directions-upstream within a CAPWAP tunnel and downstream outside
of the CAPWAP tunnel. The benefits are realized when a wireless branch device is connecting to a server
located in the same branch. If the traffic is destined for the data center, it still transits the WAN but
outside of a CAPWAP tunnel, benefiting from the same level of security and performance as wired
traffic. Depending on the application, it may not be encrypted so additional WAN security might be
needed. If the branch is using a broadband connection as either the primary or backup path, then
obviously encryption technologies such as DMVPN should be deployed. However, even if an MPLS
VPN service is being used, the enterprise may still want to consider encrypting any traffic that passes
off premise.
Transport
With both the FlexConnect and Converged Access designs, not all wireless traffic is terminated locally.
In this design guide guest traffic is still tunneled within a mobility tunnel to a central controller at a
campus location. Also, depending upon the on-boarding design implemented (single SSID versus dual
SSID), traffic from devices which are in the process of being on-boarded may also remain in the
CAPWAP tunnel to the central controller with the FlexConnect design. This traffic may compete for
bandwidth with the corporate traffic also using the WAN link, but not inside a CAPWAP tunnel. These
concerns are addressed with a mix of traditional QoS services and wireless rate-limiting. In some
situations, the transport will determine what is appropriate.
If Layer 2 MPLS tunnels are in place, destination routing can be used to place CAPWAP traffic on a
dedicated path to the wireless controllers. This may be useful as an approach to isolate guest traffic from
the branch towards the campus since FlexConnect with local termination will pass most corporate traffic
outside of a CAPWAP tunnel directly to its destination. Return traffic from the campus towards the
branch is more difficult to manage without more complex route policies, but may be possible with careful
planning.
Figure 3-2 illustrates at a high level a typical WAN architecture.

The anywhere, any device requirement of BYOD implies that employees can use either corporate or
personal devices at either campus or branch locations. When they do, the pertinent component of the
BYOD architecture is the ability to enforce policies on these devices at either the branch or at the campus
5-34
Chapter 5

location. Policy enforcement is effective if and only if there is a well-designed branch network
infrastructure in place. This branch network infrastructure can be categorized into WAN and LAN
components. This section discusses the high level key design elements of branch LAN design.
Cisco access points can currently operate in one of two implementation modes in the Cisco Unified
Wireless Network (CUWN) architecture:
Local mode (also referred to as a centralized controller design)
FlexConnect mode
In addition, Cisco has recently integrated wireless LAN controller functionality directly into the latest
generation access-layer switchesthe Catalyst 3850. Hence there is a now a third implementation
choice:
Converged Access
FlexConnect is a wireless design which primarily applies to branch locations and is discussed in this
section. Local mode is a wireless design which primarily applies to campus locations within this design
guide and is discussed in Campus Network Design. Converged Access designs apply to both wired and
wireless designs within both the branch and campus and hence are discussed in both sections of this
chapter.
Note
Local mode can be deployed within branches which are large enough to justify the requirement for
wireless controllers deployed within the branch itself. In such cases, the BYOD design for the large
branch is similar to the campus design.
FlexConnect Wireless Design

FlexConnect is an innovative Cisco technology which provides more flexibility in deploying a wireless
LAN. For example, the wireless LAN may be configured to authenticate users using a centralized AAA
server, but once the user is authenticated the traffic is switched locally on the access point Ethernet
interface. Alternatively, the traffic may be backhauled and terminated on the wireless controller Ethernet
interface if desired. The local switching functionality provided by FlexConnect eliminates the need for
data traffic to go all the way back to the wireless controller when access to local resources at the branch
is a requirement. This may reduce the Round Trip Time (RTT) delay for access to applications on local
branch servers, increasing application performance. It can also reduce unnecessary hair-pinning of
traffic when accessing resources local to the branch.
Access points connected to the access-layer switches within branch locations are still configured and
controlled via one or more centralized wireless LAN controllers. In the case of this design guide, these
controllers are a set of Cisco Flex 7500 wireless controllersdedicated for branchessince they
provide greater scalability for supporting access points in FlexConnect mode than Cisco CT5508
wireless controllers. Note also that with this design, guest wireless traffic is backhauled across the WAN
to a dedicated CT5508 guest anchor controller located on a DMZ segment within the campus.
Provisioning traffic (i.e. traffic from devices attempting to on-board with ISE) may also be backhauled
across the WAN to the Flex7500 wireless controllers located within the campus.
Figure 5-22 shows at a high level how FlexConnect is implemented in the branch design.
5-35
Chapter 5
Figure 5-22
High-Level View of the FlexConnect Wireless Branch Design
Dynamic VLAN assignment with a FlexConnect ACL applied at

the wireless access point for differentiated access control.
VLAN Name
Description
Wireless_Full
Full Internal and Internet Access for On-Boarded Wireless Devices
Wireless_Partial
Partial Internal Access and Internet Access for On-Boarded Wireless

Devices
Wireless_Internet
Internet Only Access for On-Boarded Wireless Devices
Dynamic Mapping of Employee SSID to Local VLAN Based on

Authentication and Authorization from ISE
CAPWAP: AP Control, Guest and Provisioning Traffic
Flex7500
WLCs
Campus
Network
Infrastructure
ISE
Guest
VLAN
DMZ
CT5508 Guest
Anchor WLCs
Campus
CAPWAP
WAN
FlexConnect
ACLs
Prime
Infrastructure
Internet
IT Devices
(MAB)
SSID
MDM
DMZ
Cloud-Based
MDM
Guest
SSID
Employee
SSID
Provisioning
SSID
(optional)
Branch
MDM
On-Prem
MDM
CAPWAP Tunnels
Mobility Tunnels
(Old Mobility Architecture)
294935
Provisioning
VLAN
(optional)
Mobility Tunnel:
Guest Traffic
MSE
To implement the BYOD use cases for on-boarded devices, the method presented in this design guide
for branch locations utilizing a FlexConnect wireless design is to place the device into an appropriate
VLAN after it is authenticated and authorized. Statically configured FlexConnect ACLs applied per
access point (or access point group) and per VLAN, provide differentiated access control for wireless
devices. For example, a personal device which needs full access to the network is placed into a VLAN
in which a FlexConnect ACL is configured on the access point with the right permissions. Personal
devices that are granted partial access are placed in a different VLAN which has a different FlexConnect
ACL.
Branch Wired Design

Figure 5-23 shows the wired design for a branch which does not implement Converged Access Catalyst
3850 Series switches. In other words, this is the wired design for a branch which implements switches
such as the Catalyst 3750X, along with a FlexConnect wireless design.
5-36
Chapter 5

Figure 5-23
High-Level View of Non-Converged Access Wired Branch Design
Dynamic VLAN assignment and downloadable ACL, which overrides a default static
ACL, applied to the wired switch port. Static ACLs configured on the branch router
Layer 3 sub-interfaces provided differentiated access control.
VLAN Name
Description
Wireless_Full
Full Internal and Internet Access for On-Boarded Wired Devices
Wireless_Partial
Partial Internal Access and Internet Access for On-Boarded Wired Devices
Wireless_Internet
Internet Only Access for On-Boarded Wired Devices
Dynamic Assignment of Wired Device to Local VLAN Based on

Authentication and Authorization from ISE
Campus
Prime
Infrastructure
ISE
Catalyst Switch
WAN
Campus
Network
Infrastructure
Static ACLs
Downloadable
ACLs
Wired 802.1X
MSE
Internet
DMZ
On-Prem
MDM
MDM
Cloud-Based
MDM
294936
MDM
Branch
This design guide assumes that Catalyst switches are deployed as Layer 2 devices within the branch
location. Wired devices authenticate using 802.1X against the ISE server centrally located within the
campus. For this design, wired devices are also dynamically assigned to separate VLANs based on their
access control requirements. A RADIUS downloadable ACL applied to the Catalyst 3750X Series switch
overrides a pre-configured static ACL on each Catalyst switch port. Differentiated access control for the
wired devices is provided by statically configured ACLs applied to the Cisco ISR G2 router Layer 3
sub-interfaces.
Converged Access Branch Design

The Converged Access branch BYOD design assumes a single Catalyst 3850 Series switch or switch
stack deployed within a branch location. Hence this design applies to small to mid-sized branches only.
This is shown in Figure 5-24.
5-37
Chapter 5
Figure 5-24
Converged Access Branch Design Hardware
Active and Standby

Cisco ISR G2 Routers
Gigabit Ethernet Ports
Up to nine Catalyst
3850 Series switches in
a single switch stack
PoE, PoE+, or UPoE
Gigabit Ethernet Ports
CAPWAP
Up to 50 Cisco Aironet 1600, 2600, or

3600 Series Access Points distributed
across the switches
294937
CAPWAP
Up to nine Catalyst 3850 Series switches may be deployed within a switch stack. The maximum number
of access points supported per switch stack is 50, with up to a maximum of 2,000 wireless clients. The
Catalyst 3850 Series supports up to 40 Gbps wireless throughput per switch (48-port models). Note that
wireless performance requirements and physical distance limitations will often dictate the actual number
of wireless access points and clients which can be deployed with this design. When a switch stack is
implemented, APs should be deployed across the switches for wireless resilience purposes. This design
guide will assume Catalyst 3850 Series switches deployed as Layer 2 switches within the branch
location. Layer 3 connectivity within the branch is provided by the ISR routers which also serve as the
WAN connectivity point for the branch. Future design guidance may address Catalyst 3850 Series
switches deployed as Layer 3 switches within the branch location.
Note
The Converged Access branch BYOD design may also be referred to as the Integrated Controller Branch
BYOD design within this document.
As mentioned previously, Cisco has integrated wireless LAN controller functionality directly in the
Catalyst 3850 Series switch. When access to local resources at the branch is a requirement, this allows
for the termination of wireless traffic on the Catalyst 3850 switch itself, rather than backhauling traffic
to a centralized wireless controller. As with FlexConnect designs, Converged Access designs can reduce
Round Trip Time (RTT) delay, increase application performance, and reduce unnecessary hair-pinning
of traffic when accessing resources local to the branch.
For the Converged Access branch BYOD design, the single Catalyst 3850 Series switch stack will
implement the following wireless controller functionality:
Mobility Agent (MA)Terminates the CAPWAP tunnels from the access points (APs), and
maintains the wireless client database.
Mobility Controller (MC)Manages mobility within and across sub-domains. Also manages radio
resource management (RRM), WIPS, etc.
5-38
Chapter 5

Since there is only a single switch stack, there is only a single Switch Peer Group (SPG). The Mobility
Group, Mobility Sub-Domain, and Mobility Domain are entirely contained within the branch. No
additional centralized wireless controllers are needed at the campus location, except for the Cisco
CT5508 wireless controllers which function as the dedicated anchor controllers for wireless guest traffic.
The access points within the branch locations are configured and controlled via the wireless LAN
controller functionality integrated within the Catalyst 3850 Series switch. Guest wireless traffic is still
backhauled to a dedicated CT5508 guest anchor controller located on a DMZ segment within the
campus. Provisioning traffic (i.e., traffic from devices attempting to on-board with ISE) is terminated
locally on the Catalyst 3850 Series switch, with the Converged Access branch design. When
implementing a dual-SSID design, provisioning traffic is terminated on a separate VLAN. All
on-boarded devices terminate on a single VLAN with this design.
Note
When deploying converged access wireless designs in which the Catalyst 3850 Series switch functions
as the Mobility Controller (MC) and Mobility Agent (MA), it should be noted that the mobility tunnel
for wireless guest access initiates from the Catalyst 3850 to the Guest anchor controller located within
the DMZ. Hence, each branch will initiate a mobility tunnel for wireless guest access with this design.
The maximum number of mobility controllers within a mobility domain is 72 for the CT5508 wireless
controller. Therefore the maximum number of mobility anchor tunnels is limited to 71 for the CT5508
wireless controller. Therefore the network administrator may need to deploy additional CT5508 guest
anchor controllers. Alternatively, the network administrator may look at providing direct Internet access
from the branch for guest access. Future versions of this design guide may address such designs.
In order to implement the BYOD use cases, the method adopted in this design guide for branch locations
utilizing a Converged Access design is to apply the appropriate dynamic ACL after the device is
authenticated and authorized. This applies to both wired and wireless devices. The particular form of
dynamic ACL is a RADIUS specified local ACL, otherwise known as a named ACL. These named ACLs,
which must be configured on each Catalyst 3850 Series switch, provide differentiated access control. For
example, a personal device which is granted full access to the network is statically assigned to the same
VLAN as a personal device which is granted partial access. However different named ACLs are applied
to each device, granting different access to the network. Since the named ACL is configured on the
Catalyst 3850 switch specific to the particular branch, a single Cisco ISE policy can be implemented
across multiple branches. However the Access Control Entries (ACEs) within the ACL for each branch
can be unique to the IP addressing of the branch. This reduces the administrative complexity of the Cisco
ISE policy, albeit at the expense of increased complexity of having to configure and maintain ACLs at
each branch Catalyst 3850 Series switch.
Figure 5-25 shows at a high level how a Converged Access BYOD design is implemented in the branch.
5-39
Chapter 5
Figure 5-25
High-Level View of the Converged Access Branch BYOD Design
Dynamic ACL (Named ACL) assignment applied at the switch for

differentiated access control for wired and wireless devices.
Mobility Tunnel:
Guest Traffic
CAPWAP:
Data and Control Traffic
Employee
VLAN
MSE
Campus
Network
Infrastructure
ISE
Guest
VLAN
WAN
Prime
Infrastructure
CAPWAP
Wired
802.1X
Provisioning
Catalyst
VLAN (optional) 3850
Internet
DMZ
IT Devices
(MAB)
SSID
MDM
DMZ
CT5508 Guest
Anchor WLCs
Named ACLs
MC
MA
Cloud-Based
MDM
Branch
Guest
SSID
Employee
SSID
Provisioning
SSID
(optional)
294938
Campus
MDM
On-Prem
MDM
Note that in the case of this design guide, on-boarded wired devices are also statically assigned to the
same VLAN as wireless devices. Hence on-boarded wired and wireless devices will share the same
VLAN, and hence the same IP subnet addressing space. It is recognized that customers may implement
separate subnets for wired and wireless devices due to issues such as additional security compliance
requirements for wireless devices. This will not be addressed within this version of the design guidance.
Dynamically assigned named ACLs provide differentiated network access for wired devices.
The reason for the two methods of providing differentiated access between the FlexConnect and
Converged Access branch designs is that prior to CUWN software version 7.5, FlexConnect did not
allow the dynamic assignment of an ACL to an access point. It only allowed the dynamic assignment of
a VLAN. The FlexConnect wireless design in this design guide is carried forward from the previous
version of the design guide and continues to require a separate VLAN for each separate level of access
control. This can increase the administrative burden of managing the branch network configuration.
Converged access designs are more consistent with the campus wireless designs, requiring a single
VLAN for multiple levels of access control.
5-40
CH AP TE R

Mobile Device Managers (MDMs) secure, monitor, and manage mobile devices, including both
corporate-owned devices as well as employee-owned BYOD devices. MDM functionality typically
includes Over-the-Air (OTA) distribution of policies and profiles, digital certificates, applications, data
and configuration settings for all types of devices. MDM-supported and managed devices include not
only handheld devices, such as smartphones and tablets, but increasingly laptop and desktop computing
devices as well.
Critical MDM functions include-but are not limited to:
PIN enforcementEnforcing a PIN lock is the first and most effective step in preventing
unauthorized access to a device; furthermore, strong password policies can also be enforced by an
MDM, reducing the likelihood of brute-force attacks.
Jailbreak/Root DetectionJailbreaking (on Apple iOS devices) and rooting (on Android devices)
are means to bypass the management of a device and remove SP control. MDMs can detect such
bypasses and immediately restrict a devices access to the network or other corporate assets.
Data EncryptionMost devices have built-in encryption capabilities-both at the device and file
level. MDMs can ensure that only devices that support data encryption and have it enabled can
access the network and corporate content.
Data WipeLost or stolen devices can be remotely full- or partial-wiped, either by the user or by
an administrator via the MDM.
Data Loss Prevention (DLP)While data protection functions (like PIN locking, data encryption
and remote data wiping) prevent unauthorized users from accessing data, DLP prevents authorized
users from doing careless or malicious things with critical data.
Application TunnelsSecure connections to corporate networks are often a mandatory requirement

for mobile devices.
Cisco ISE 1.2 with MDM API Integration

While Cisco ISE provides critical policy functionality to enable the BYOD solution, it has limited
awareness of device posture. For example, ISE has no awareness of whether a device has a PIN lock
enforced or whether the device has been jailbroken or whether a device is encrypting data, etc. On the
other hand, MDMs have such device posture awareness, but are quite limited as to network policy
enforcement capacity.
6-1
Chapter 6
Therefore, to complement the strengths of both ISE and MDMs, ISE 1.2 includes support of an MDM
integration API which allows it to both:
Pull various informational elements from MDM servers in order to make granular network access
policy decisions that include device-details and/or device-posture.
Push administrative actions to the managed devices (such as remote-wiping) via the MDM.
As of the publication date of this CVD, ISE 1.2 supports an API for MDM integration with the following
third-party MDM vendors:
AirWatch
MobileIron
Good Technologies
XenMobile
SAP Afaria
FiberLink Maas360
The following MDM API pull/push capabilities are supported in ISE 1.2 for all third-party MDM
systems:
PIN lock Check
Jailbroken Check
Data Encryption Check
Device Augmentation Information Check
Registration Status Check
Compliance Status Check
Periodic Compliance Status Check
MDM Reachability Check
(Full/Partial) Remote Wipe
Remote PIN lock

With MDM solutions, there are two main deployment models:
On-PremiseIn this model, MDM software is installed on servers in the corporate DMZ or data
center, which are supported and maintained by the enterprise IT staff.
Cloud-basedIn this model-also known as a MDM Software-as-a-Service (SaaS) model-MDM

software is hosted, supported and maintained by a provider at a remote Network Operation Center
(NOC); customers subscribe on a monthly or yearly basis and are granted access to all MDM
hardware/software via the Internet.
Before deploying a MDM, businesses must make the pivotal decision of whether their MDM solutions
should be on premise (on-prem) or cloud-based. Several business and technical factors are involved in
this decision, including:
CostCloud-based MDM solutions often are more cost-effective than on-prem; this is because
these eliminate the need for incremental and ongoing hardware, operating system, database and
networking costs associated with a dedicated MDM server. Also avoided is any additional training
6-2
Chapter 6

that may be required by IT staff to support these servers. From a cloud-providers perspective: since
these fixed infrastructure costs have already been invested, there are very little marginal cost to
provisioning custom-tailored virtual-instances to enterprise subscribers, and as such, these can be
priced attractively.
Note
ControlOn-prem models offer enterprises the greatest degree of control, of not only the MDM
solution, but also the enterprise systems that these integrate with (such as the corporate directory,
certificate authority, email infrastructure, content repositories and management systems-all of which
will be discussed in additional detail below). This is because an on-prem model requires no
transmission or storage of corporate data offsite. Conversely, a cloud-based service requires giving
up a level of control over the overall solution, as confidential information, data and documents will
be required to be transmitted to the provider, and (depending on the details of the service) may also
be stored offsite. Cloud providers may also update the software on the servers without following the
enterprise change control protocol.
SecurityOn-prem MDM models are often perceived as being more secure than cloud-based
models; however, this perceived difference in security-levels may be lessening, especially when
considering that over $14B of business was securely conducted via SaaS in 2012 alone. Ultimately,
the security of a system will principally depend, not only on the technologies deployed, but also on
the processes in place to keep the hardware and software updated and managed properly.
Intellectual PropertyMost MDMs support secure isolation of corporate data on the devices they
manage; however, these systems typically require corporate data to be passed through the MDM in
order to be transmitted OTA to the devices secure and encrypted compartment. This process may
represent an additional security concern in a cloud-based model, as now the enterprise is called on
to trust the MDM SaaS provider with not only device management, but also with intellectual
property and confidential data.
Regulatory ComplianceRegulatory compliance can dictate where and how financial, healthcare
and government (and other) organizations can store their data. Such regulations include PCI,
HIPAA, HITECH, Sarbanes-Oxley, and even the US Patriot Act. Such regulations may preclude
storing sensitive information in the cloud, forcing the choice of an on-prem MDM model.
ScalabilityCloud-based models offer better scalability than on-prem models, as these can
accommodate either small or large deployments (and anything in-between) without any increased
infrastructure costs to the subscriber. Conversely, on-prem models may have difficulty in
cost-effectively accommodating small deployments. For example, consider the cost of deploying an
MDM server that can support 100,000 devices being deployed to support only 100. Additionally,
on-prem models will incrementally require more hardware and infrastructure as the number of
devices increases.
Speed of DeploymentCloud-based solutions are typically faster to deploy (and can often be
enabled the same-day as these are ordered), whereas on-prem solutions often take a couple of weeks
(or more) to plan out, install and deploy.
FlexibilityCloud-based MDM solutions typically have day-one support for new releases of device
hardware and software; alternatively, on-prem solutions will require an upgrade to the MDM
software for each new device/software supported.
Ease of ManagementWith on-prem models, the IT department must ensure the MDM has all the
latest updates; in a cloud-based system, this responsibility rests with the provider.
Cisco is not advocating the use of one MDM deployment model over another, nor does Cisco recommend
any specific third-party MDM solution. These business and technical considerations are included simply
to help draw attention to the many factors that an IT architect may find helpful in reviewing when
evaluating which MDM solution works best to meet their specific business needs.
6-3
Chapter 6
On-Premise
In the on-premise MDM deployment model, the MDM software resides on premises on a dedicated
server (or servers), typically within the Internet Edge or DMZ.
This model is generally better suited to IT staff that have a higher-level of technical expertise (such that
they can configure, periodically-update and manage such a server) or to enterprises that may have stricter
security/confidentiality requirements (which may preclude the management of their devices by a
cloud-based service).
The on-premise model may also present moderate performance benefits to some operational flows (due
to its relative proximity to the devices, as opposed to a cloud-based service). For example, if a network
access policy included the MDM Reachability check, this test would likely be much more responsive
in an on-premise MDM deployment model versus a cloud-based model.
The network topology for a campus BYOD network utilizing an On-Prem MDM deployment model is
illustrated in Figure 6-1.
Figure 6-1
Campus BYOD Network with On-Prem MDM (at the Internet Edge)
Data Center
Internet Edge
Cisco ISE
DNS and
DHCP
Services
Guest
Wireless
Controller
ASA
Firewall
CA
AD
Internet
Core
MDM
Wireless
Controller
On-Prem
MDM
Campus
Building
293992
Access
Switch
6-4
Chapter 6

Cloud-Based
In the Cloud-Based MDM deployment model, MDM functionality is delivered to customers in a SaaS
manner: the software resides wholly within the MDM vendors cloud, with a custom-tailored virtual
instance provided for each customer.
From a customers perspective, this model is greatly simplified (as now they do not have to configure,
update, maintain and manage the MDM software); however, as a trade-off, they relinquish a degree of
control over all their devices (and also some of the data on these devices) to the third-party MDM SaaS
provider, which may pose security concerns. As such, this model may be better suited to small- or
medium-sized businesses that have moderate IT technical expertise and unexceptional security
requirements.
The network topology for a branch BYOD network utilizing a cloud-based MDM deployment model is
illustrated in Figure 6-2.
Figure 6-2
Branch BYOD Network with Cloud-Based MDM
Data Center
Internet Edge
Guest
Wireless
Controller
Cisco ISE
DNS and
DHCP
ASA
Firewall
CA
AD
Services
Core
Wireless
Controller
WAN
Internet
WAN
Edge
Cloud-Based
MDM
MPLS
WAN
MDM
Branch
293993
Access
Switch
6-5
Chapter 6
Enterprise Integration Considerations

In addition to the integrating the corporate network with the MDMwhich is discussed in great detail
in this documentother enterprise services and resources are also important to integrate with the MDM
system, including:
Corporate Directory Services
Certificate Authority (CA) and Public Key Infrastructure (PKI)
Email Infrastructure
Content Repositories
Management Systems
Corporate Directory Services Integration

Corporate directory services (such as LDAP-based directory, Active Directory, etc.) can be leveraged by
MDMs to efficiently organize and manage user access. Administrators can assign device profiles, apps,
and content to users based on their directory-group memberships. Additionally, some MDMs can detect
directory changes and automatically update device-policies. For example, if a user is deactivated in a
directory system, then the MDM can remove device-based corporate network access and selectively
wipe the device.
Corporate Certificates Authority and Public Key Infrastructure Integration

Certificate Authorities (such as Microsoft CA) or SCEP certificate services providers (such as MSCEP
and VeriSign) can be leveraged by MDMs to assign and verify certificates for advanced user
authentication and to secure access to corporate systems. CA integration ensures message integrity,
authenticity and confidentiality. Additionally CA integration enables client authentication, encryption
and message signatures.
Furthermore, MDMs can also integrate with Public Key Infrastructure (PKI) or third-party providers to
configure certificates and distribute these to devices without user interaction.
Email Integration
The corporate email infrastructure can be integrated with the MDM solution to provide security,
visibility and control in managing mobile email. This enables employees to access corporate email on
their mobile devices without sacrificing security. Additionally such integration facilitates the
management of mobile email (such as configuring email settings over-the-air, blocking unmanaged
devices from receiving email, enforcing device encryption, etc.) The MDMs approach to email
management varies among MDM providers and is feature differentiator. Email policy information is not
available to ISE via the API.
Content Repository Integration

Integrating MDM systems with content repositories enables administrators to deliver secure mobile
access to corporate documents while managing document distribution and access permissions (including
the ability to view, view-offline, email, or print on a document). This ensures the right content gets to
6-6
Chapter 6

the right employees without sacrificing the security of the documents themselves, which are distributed
to mobile devices over encrypted connections. Furthermore, files and documents can be synchronized
with corporate file systems and share points, so that the latest version of a document is automatically
updated on employee mobile devices. To ensure security, users can be authenticated with a username,
password, and certificate before they can access corporate content. Additionally, document metadata
(including author, keywords, version, and dates created or modified) can be restricted on a per-user basis.
Management Integration
MDM systems can be integrated with enterprise management systems for enhanced logging, recording
and reporting of device and console events. Event logging settings can be configured based on severity
levels, with the ability to send specific levels to external systems via Syslog integration. Events can
include login events, failed login attempts, changes to system settings and configurations, changes to
profiles, apps and content, etc. Such management systems integration ensures security and compliance
with regulations and corporate policies.
Integration Servers
The integration of these enterprise systems with MDMs in on-premise deployment models is relatively
straightforward, as it is largely a matter of ensuring the proper protocols are configured correctly and the
necessary ports are opened in any firewalls within the paths. However, in cloud-based deployment
models, such integration requires secure transport protocols (such as over HTTPS) from the customer to
the MDM service provider and/or a specialized MDM integration servers (or similar proxy-servers)
located within the client's DMZ.
6-7
Chapter 6
6-8
CH AP TE R
Application Considerations and License

Requirements for BYOD
Whats New: The Quality of Service (QoS) section has been re-written to add a QoS discussion around
Converged Access products, including the Catalyst 3850 Series switch and the Cisco 5760 wireless LAN
controller.
When implementing a BYOD solution, the applications that run on employee-owned devices need to be
considered before selecting which of the particular BYOD use cases discussed above to deploy. The
application requirements for these devices determine the level of network connectivity needed. The
network connectivity requirements in turn influence the choice of the BYOD use case to apply.
Quality of Service
In addition to network connectivity, Quality of Service (QoS) is an important consideration for
applications, especially those delivering real-time media. Device specific hardware, such as dedicated
IP phones which send only voice traffic, allowed for the configuration of dedicated voice wireless
networks. However, with the widespread use of smartphones and tablets which support collaboration
software (such as Ciscos Jabber client), devices are capable of sending voice, video, and data traffic
simultaneously. Hence, QoS is necessary to provide the necessary per-hop behavior as such traffic
traverses the network infrastructure.
QoS can be categorized into the following broad functions:
Classification and Marking-including Application Visibility and Control (AVC)
Bandwidth Allocation/Rate Limiting (Shaping and/or Policing)
Trust Boundary Establishment
Queueing
For a discussion regarding implementing wired QoS, refer to Medianet Campus QoS Design 4.0 at:
http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSCampus
_40.html.
The solution presented within this document supports two different types of WLAN QoStraditional
precious metals QoS implemented by CUWN wireless LAN controller platforms and Converged
Access QoS implemented by IOS XE based wireless LAN controller platforms. The following sections
discuss various aspects of wireless QoS for each of the respective platforms.
7-1
Chapter 7
Quality of Service
CUWN Wireless LAN Controller QoS

As of Cisco Unified Wireless Network (CUWN) software release 7.3 and above, wireless QoS is
configured by applying one of four precious metals QoS ProfilesPlatinum, Gold, Silver, or
Bronzeto the WLAN to which a particular client device is associated. An example of the configuration
is shown in Figure 7-1.
Figure 7-1
Application of a QoS Profile to a WLAN
Note that the QoS settings for the profile can be overridden on a per-WLAN basis from within the QoS
tab of the WLAN configuration.
The DSCP marking of client traffic, as it traverses the network within a CAPWAP tunnel, is controlled
by three fields within the WLAN QoS Parameters field within the QoS Profile:
Maximum PriorityThis is the maximum 802.11 User Priority (UP) value of a packet sent by a
Wi-Fi Multimedia (WMM)-enabled client which will be allowed by the access point. The User
Priority maps to a DSCP value within the outer header of the CAPWAP tunnel as the packet traverses
the network infrastructure. If the WMM-enabled client sends an 802.11 packet with a User Priority
higher than allowed, the access point marks the packet down to the maximum allowed User Priority.
This in turn maps to the DSCP value of the external CAPWAP header as the packet is sent over the
network infrastructure.
Unicast Default PriorityThis is the default 802.11 User Priority (UP) to which a unicast packet
sent by a non-WMM-enabled client is assigned. This User Priority also maps to the DSCP value
within the outer header of the CAPWAP tunnel as the packet traverses the network infrastructure.
7-2
Chapter 7

Quality of Service
Multicast Default PriorityThis is the default 802.11 User Priority (UP) for multicast traffic. This
User Priority maps to a DSCP value within the outer header of the CAPWAP tunnel as the packet
traverses the network infrastructure.
Table 7-1 shows the default WLAN QoS parameter settings in terms of 802.11 access category
designation and corresponding mapped DSCP value.
Table 7-1
Default WLAN QoS Parameter Settings for CUWN Controllers
Maximum Priority, Unicast Default Priority, and Multicast

QoS Profile Name Default Priority (802.11 UP)
DSCP Mapping
Platinum
Voice
EF (DSCP 46)
Gold
Video
AF41 (DSCP 34)
Silver
Best Effort
Default (DSCP 0)
Bronze
Background
AF11 (DSCP 10)
An example of the configuration of the WLAN QoS Parameters is shown in Figure 7-2.
Figure 7-2
Controlling the Marking of Wireless Packets
It should be noted that these settings apply primarily to Local Mode (centralized wireless controller)
designs and FlexConnect designs with central termination of traffic, since the WLAN QoS Parameters
field results in the mapping of the 802.11 User Priority to the DSCP value within the outer header of the
CAPWAP tunnel.
7-3
Chapter 7
Quality of Service
The original DSCP marking of the packet sent by the wireless client is always preserved and applied as
the packet is placed onto the Ethernet segment, whether that is at the wireless controller for centralized
wireless controller designs or at the access point for FlexConnect designs with local termination.
The wireless trust boundary is established via the configuration of the WMM Policy within the QoS tab
of the WLAN configuration. An example was shown in Figure 7-1. The three possible settings for WMM
Policy are:
Note
DisabledThe access point will not allow the use of QoS headers within 802.11 packets from
WMM-enabled wireless clients on the WLAN.
AllowedThe access point will allow the use of QoS headers within 802.11 packets from wireless
clients on the WLAN. However the access point will still allow non-WMM wireless clients (which
do not include QoS headers) to associate to the access point for that particular WLAN.
RequiredThe access point requires the use of QoS headers within 802.11 packets from wireless
clients on the WLAN. Hence, any non-WMM-enabled clients (which do not include QoS headers)
will not be allowed to associate to the access point for that particular WLAN.
Where possible, it is advisable to configure WMM policy to Required. Some mobile devices may
incorrectly mark traffic from collaboration applications when the WMM policy is set to Allowed versus
Required. Note however that this requires all devices on the WLAN to support WMM before being
allowed onto the WLAN. Before changing the WMM policy to Required, the network administrator
should verify that all devices which utilize the WLAN are WMM-enabled. Otherwise,
non-WMM-enabled devices will not be able to access the WLAN.
The configuration of the WMM Policy, along with the WLAN QoS Parameters, together create the
wireless QoS trust boundary and determine the marking of wireless traffic within the CAPWAP tunnel
as it traverses the network infrastructure.
Table 7-2 shows the mapping of the WLANs/SSIDs shown in the BYOD design guide to QoS Profiles
within CUWN wireless LAN controllers.
Table 7-2
Mapping of BYOD WLANs/SSIDs to QoS Profiles
SSID
WLAN/SSID Name
QoS Profile
Employee SSID
BYOD_Employee
Platinum
Personal Devices SSID BYOD_Personal_Device Platinum

Guest SSID
BYOD_Guest
Silver
Provisioning SSID
BYOD_Provisioning
Silver
IT Devices SSID
IT_Devices
Silver
It is assumed that the Employee and Personal Devices SSIDs will need to support wireless clients which
run voice, video, and data applications. Hence these SSIDs are configured for the Platinum QoS profile.
The Guest, Provisioning, and IT Devices SSIDs are assumed to only require data applications which
require a best effort service. However, the business requirements of any organization ultimately
determine what devices and applications are supported over the various SSIDs. The design shown in
Table 7-2 can easily be modified to reflect the needs of a particular deployment.
7-4
Chapter 7

Quality of Service
Rate Limiting on CUWN Wireless Controllers

One additional option to prevent the wireless medium from becoming saturated, causing excessive
latency and loss of traffic, is rate limiting. Rate limiting may be implemented per device or per SSID to
prevent individual devices from using too much bandwidth and negatively impacting other devices and
applications. Rate limiting on CUWN wireless LAN controllers can be particularly useful for guest
access implementations and is discussed in detail in Chapter 21, BYOD Guest Wireless Access.
Converged Access QoS

The CT5760 wireless controller and the Catalyst 3850 Series switches both run Cisco IOS XE software.
QoS configuration for Converged Access products uses the Modular QoS based CLI (MQC), which is in
alignment with other platforms such as Catalyst 4500E Series switches. The Converged Access QoS
design presented in this section discusses the ability to provide the following QoS capabilities to
Converged Access wireless designs discussed within this document:
Egress queuing for wireless Catalyst 3850 switch ports, wired Catalyst 3850 uplink ports, and Cisco
CT5760 distribution system ports at the port-level policy.
Downstream bandwidth management at the SSID-level policy.
Upstream classification and marking at the client-level policy. Optional upstream policing at the
client-level policy for Catalyst 3850 Series switches is also discussed.
Marking of mobility traffic.
QoS policies discussed within this section will be applied for a Converged Access campus design, a
Converged Access branch design, and a Centralized campus design using a Cisco CT5760 wireless
controller.
Figure 7-3, Figure 7-4, and Figure 7-5 provide a high-level overview of where QoS policies will be
applied to each of the designs. Each of the circled policies is discussed in subsequent sections.
7-5
Chapter 7
Quality of Service
Figure 7-3
Converged Access QoS PolicyConverged Access Campus View
Converged Access Campus

Building Design
Catalyst 3850
Switch Stack
Services
NTP
Data Center
6
1
2
2
SSID
Downstream
Rate Limiting
per AP, per
Radio
CT5760
WLCs
CAPWAP
CAPWAP
CA
AD
Core
DNS and
DHCP
Applications
and File
Servers
Guest
SSID
6 Mbps
BW, No
Real-Time
Traffic
Personal
Devices
SSID
No BW
Limit,
Real-Time
Traffic
ISE
RSA
Employee
SSID
No BW
Limit,
Real-Time
Traffic
Provisioning
SSID
No BW
Limit, No
Real-Time
Traffic
IT Devices
SSID
No BW
Limit, No
Real-Time
Traffic
Internet
Edge
CT5508
Guest
WLCs
CAPWAP Tunnels
Mobility Tunnels
ASA
WAN
Off-Prem
Internet
DMVPN
SGT
Capable
7-6
MDM
Cloud-Based
MDM
294877
MDM
On-Prem
MDM
Chapter 7

Quality of Service
Figure 7-4
Converged Access QoS PolicyConverged Access Branch View

CAPWAP Tunnels
Data Center
Mobility Tunnels
ISE
RSA
Converged Access Branch Design

Catalyst 3850
Switch Stack
CA
2
Core
DNS and
DHCP
Applications
and File Servers
WAN
Edge
CT55508
CT5508
Guest WLCs
WAN
MPLS
GETVPN
ASA
SGT
Capable
Off-Prem
Internet
DMVPN
MDM
On-Prem
MDM
Guest
SSID
6 Mbps
BW, No
Real-Time
Traffic
CAPWAP
CAPWAP
Personal
Devices
SSID
No BW
Limit,
Real-Time
Traffic
Employee
SSID
No BW
Limit,
Real-Time
Traffic
Provisioning
SSID
No BW
Limit, No
Real-Time
Traffic
IT Devices
SSID
No BW
Limit, No
Real-Time
Traffic
SGT
Capable
MDM
294878
Internet
Edge
SSID
Downstream
Rate Limiting
per AP, per
Radio
AD
Cloud-Based MDM
7-7
Chapter 7
Quality of Service
Figure 7-5
Centralized Wireless QoS PolicyCisco CT5760 Wireless Controllers

Building Design
Services
NTP
Catalyst 3750
Switch Stack
Data Center
SSID
Downstream
Rate Limiting
per AP, per
Radio
3
CT5760
WLCs
CAPWAP
CAPWAP
CA
AD
Core
DNS and
DHCP
Applications
and File
Servers
Guest
SSID
6 Mbps
BW, No
Real-Time
Traffic
Personal
Devices
SSID
No BW
Limit,
Real-Time
Traffic
ISE
RSA
Employee
SSID
No BW
Limit,
Real-Time
Traffic
Provisioning
SSID
No BW
Limit, No
Real-Time
Traffic
IT Devices
SSID
No BW
Limit, No
Real-Time
Traffic
Internet
Edge
CT5508
Guest
WLCs
CAPWAP Tunnels
Mobility Tunnels
ASA
WAN
Off-Prem
Internet
DMVPN
SGT
Capable
MDM
Cloud-Based
MDM
294879
MDM
On-Prem
MDM
Port-Level QoS Policies

The port-level QoS policies discussed within this section apply to Catalyst 3850 switch wireless ports
(ports directly connected to Cisco Aironet access points), Catalyst 3850 wired uplink ports, and to Cisco
CT5760 wireless controller distribution system ports.
Catalyst 3850 Series Switch

Figure 7-6 shows the Catalyst 3850 port QoS policies.
7-8

Quality of Service
Figure 7-6
Catalyst 3850 Port QoS Policies
1
QoS Trust Boundary
Catalyst 3850
Switch Stack
CAPWAP
294880
Chapter 7
Policy 1: Queuing Wired Uplink Ports (Wired 3850)
Pass DSCP
Enable 2P6Q3T egress queuing for an 8-class QoS model
Policy 2: Queuing Wireless ports (Wireless 3850)
Trust DSCP
Enable 2P2Q egress queuing for an 8-class QoS model
Policy 1 addresses the QoS policy for an uplink port of the Catalyst 3850 Series switch when deployed
either within the campus or branch in a Converged Access infrastructure. By default DSCP values are
preserved upon ingress and egress to a switch port. Ingress queuing is not supported on the Catalyst 3850
switch. Egress queuing will consist of mapping an 8-class QoS model to a 2P6Q3T egress queuing
structure of the Catalyst 3850 switch. The Catalyst 3850 Series switch has the capability to support either
a single priority queue or two priority queues. When defined with two priority queues, the first priority
queue (priority-level 1) is serviced first before the second priority queue (priority-level 2) is serviced.
This design guide only discusses designs which utilize both priority queues.
Figure 7-7 shows the mapping of the 8-class model to the egress queues for a 2P6Q3T model.
7-9
Chapter 7
Quality of Service
Note
2P6Q3T Egress Queuing for an 8-class QoS ModelCatalyst 3850 Uplink Port
Application Classes
DSCP
Voice
EF
EF
Priority Level 1
(Limited to 10% of BW)
Interactive Video
AF4
AF4
Priority Level 2
Network Control
CS6
CS6
Control Queue
(5% BWR)
Signaling
CS3
CS3
Signaling Queue
(5% BWR)
Bulk Data
AF1
AF1
Bulk Data Queue

(20% BWR
+ DSCP-based WTD)
Transactional Data
AF2
AF2
Transactional Data Queue

(34% BWR
+ DSCP-based WTD)
Scavenger
CS1
CS1
Scavenger Queue
(1% BWR)
Best Effort
DF
2P6Q3T
DF
Default Queue
(35% BWR + WTD)
294881
Figure 7-7
The example 8-class QoS model shown in Figure 7-7 implements a Bulk Data class in which traffic is
marked as AF1x, instead of a Multimedia Streaming class in which data is marked as AF3x, as is shown
in some 8-class QoS models. If the particular customer requirements include a Multimedia Streaming
traffic class instead of a Bulk Data traffic class, the model can simply be modified to substitute the
Multimedia Streaming traffic class for the Bulk Data traffic class. Bandwidth ratios (BWRs), which refer
to the allocation of bandwidth within the non-priority queues in Figure 7-7, can also be adjusted as
required. WTD refers to the use of weighted tail drop as a congestion avoidance mechanism for the Bulk
Data and Transactional Date Queues shown in Figure 7-7.
The following provides a configuration example of Policy 1: Queuing Wired Uplink Ports (Wired 3850).
!
class-map match-any
match dscp ef
class-map match-any
match dscp af41
match dscp af42
match dscp af43
class-map match-any
match dscp cs6
class-map match-any
match dscp cs3
class-map match-any
match dscp af11
match dscp af12
match dscp af13
class-map match-any
match dscp af21
match dscp af22
match dscp af23
REALTIME-QUEUE
INTERACTIVE-VIDEO-QUEUE
NETWORK-CONTROL-QUEUE
SIGNALING-QUEUE
BULK-DATA-QUEUE
TRANSACTIONAL-DATA-QUEUE
7-10
Chapter 7

Quality of Service
class-map match-any SCAVENGER-QUEUE

match dscp cs1
!
policy-map 2P6Q3T
class REALTIME-QUEUE
priority level 1
police rate percent 10
class INTERACTIVE-VIDEO-QUEUE
priority level 2
class NETWORK-CONTROL-QUEUE
bandwidth remaining percent 5
queue-buffers ratio 10
class SIGNALING-QUEUE
class BULK-DATA-QUEUE
queue-limit dscp af13 percent 80
class TRANSACTIONAL-DATA-QUEUE
class SCAVENGER-QUEUE
class class-default
!
interface TenGigabitEthernet 1/1/1
service-policy out 2P6Q3T
!
For wired ports, the priority level commands must be defined at the port policy map if the network
administrator wishes to place traffic into the priority queues. Policers defined within the wired port
policy map constrain the amount of traffic (unicast and/or multicast) through the priority queues.
Figure 7-8 shows an Alternative Policy 1 mapping of the 8-class model to the egress queues for a
2P6Q3T model. This model is discussed here for those customers who desire a port-level QoS policy for
the Catalyst 3850 Series switch uplink port, which is consistent with the port-level QoS policy of the
CT5760 wireless controller (discussed in Cisco CT5760 Wireless LAN Controller).
7-11
Chapter 7
Quality of Service
Figure 7-8
Alternative 2P6Q3T Egress Queuing for an 8-class QoS ModelCatalyst 3850 Uplink
Port
Application Classes
DSCP
Voice
EF
Interactive Video
AF4
Network Control
2P6Q3T
EF
CS6
CS3
Priority Level 1
AF4
Priority Level 2
CS6
Unused Queue*
Signaling
CS3
Bulk Data
AF1
Transactional Data
AF2
Scavenger
CS1
Best Effort
DF
AF1
Bulk Data Queue

(25% BWR
+ DSCP-based WTD)
AF2

(35% BWR
+ DSCP-based WTD)
CS1
Scavenger Queue
(5% BWR)
DF
Default Queue
(35% BWR + WTD)
294882
Unused Queue*
*Note only 6 of the 8 potential queues will be used with an 8-class QoS Model
The following provides a configuration example of Alternative Policy 1: Queuing Wired Uplink Ports
(Wired 3850).
!
class-map match-any RT1
match dscp ef
match dscp cs3
match dscp cs6
match dscp af41
match dscp af42
match dscp af43
class-map match-any BULK-DATA-QUEUE
match dscp af11
match dscp af12
match dscp af13
class-map match-any TRANSACTIONAL-DATA-QUEUE
match dscp af21
match dscp af22
match dscp af23
match dscp cs1
!
policy-map 2P6Q3T
class RT1
priority level 1
class RT2
priority level 2
7-12
Chapter 7

Quality of Service
class class-default
!
!
Traffic marked EF, CS6, and CS3 is bundled into a new traffic class called RT1 and placed into the
priority-level 1 queue. Traffic marked as AF4x is placed into a new traffic class called RT2 (instead of
Interactive Video) and placed into the priority-level 2 queue. Hence this model only utilizes six of the
possible eight egress queues of the Catalyst 3850 series uplink port.
Note
Alternative Policy 1 still supports traffic marked with 8 possible different DSCP markings. Hence it will
still be referred to as an 8-class QoS model within this document. However it could also be referred to
as a 6-class QoS model, since traffic is aggregated into six traffic classes before being mapped to the
queues. This is basically due to the way class maps and policy maps are defined for the Cisco Modular
QOS CLI (MQC).
Policy 2 addresses the QoS policy for the wireless port of the Catalyst 3850 switch when deployed either
within the campus or branch in a Converged Access infrastructure. By default DSCP values are
preserved across the wireless SSID boundary with IOS XE 3.3.0SE software release and higher. Ingress
queuing is not supported on Catalyst 3850 switches. Egress queuing will consist of mapping an 8-class
QoS model to a 2P2Q egress queuing structure of the Catalyst 3850 switch. Figure 7-9 shows the
mapping of the 8-class model to the egress queues.
7-13
Chapter 7
Quality of Service
2P2Q Egress Queuing for an 8-class QoS Model
Application Classes
DSCP
Voice
EF
Interactive Video
AF4
2P2Q with AFD

EF
CS6
CS3
AF4
Network Control
CS6
Signaling
CS3
Bulk Data
AF1
AF2
Scavenger
CS1
Best Effort
DF
Q1
Priority Level 2
AF1
AF2
CS1
Transactional Data
Q0
Priority Level 1
Q2
Ucast-NRT
(63% BWR)
DF
Q3
Mcast-NRT
(7% BWR)
294883
Figure 7-9
The following provides a configuration example of Policy 2: Queuing Wireless Uplink Ports (Wireless
3850).
When the Catalyst 3850 switch detects an AP connected to a port, it automatically creates and attaches
a policy-map with a hardcoded name defportafgn to the port. This policy map is not user configurable.
However this hierarchical policy-map has a child policy-map named port_child_policy which can be
modified by the user. There can only be one child-level port policy, which is applied to all wireless
switch ports in a given Catalyst 3850 Series switch or switch stack. An example of the port_child_policy
conforming to the eight class DSCP model placed into four queues (2P2Q) is shown below.
!
match dscp cs6
match dscp cs3
match dscp ef
match dscp af41
match dscp af42
match dscp af43
!
policy-map port_child_policy
class non-client-nrt-class
bandwidth remaining ratio 7
class RT1
priority level 1
conform-action transmit
class RT2
priority level 2
class class-default
!
7-14
exceed-action drop
exceed-action drop
Chapter 7

Quality of Service
Traffic marked EF, CS6, and CS3 is bundled into a traffic class called RT1 and placed into the
priority-level 1 queue. Traffic marked as AF4x is placed into a traffic class called RT2 (instead of
Interactive Video) and placed into the priority-level 2 queue. Switch ports on the Catalyst 3850 are
automatically configured to only support at most four queues when the switch port detects a Cisco
Aironet access point directly attached. The assignment of the priority level 1 command to the
user-defined RT1 class causes traffic which matches the RT1 class to be placed into the first priority
queue. The assignment of the priority level 2 command to the user-defined RT2 class causes traffic
which matches the RT2 class to be placed into the second priority queue. The client non-real-time queue
(also referred to as the Ucast-NRT or unicast non-real-time queue) is assigned all other client unicast
traffic which is not placed into either of the real-time queues. The non-client multicast queue (also
referred to as the Mcast-NRT or multicast non-client non-real-time queue) is for all other non-client
traffic which is not handled by the other three queues.
Note
Policy 2 supports traffic marked with 8 possible different DSCP markings. Hence it is referred to as an
8-class QoS model within this document. However it could also be referred to as a 4-class QoS model,
since traffic is aggregated into four traffic classes before being mapped to the queues. This is basically
due to the way class maps and policy maps are defined for the Cisco Modular QOS CLI (MQC).
The priority level commands must be defined at the child-level of the port policy map if the network
administrator wishes to place traffic into the priority queues. Policers defined within the child-level of
the port policy map apply to multicast priority traffic only.
Cisco CT5760 Wireless LAN Controller

Figure 7-10 shows the Cisco CT5760 distribution system port QoS policy.
Figure 7-10
Cisco CT5760 Port QoS Policy

CAPWAP Tunnels
CT5760
WLCs
Mobility Tunnels
Catalyst 3850
Switch Stack
CAPWAP
CAPWAP
*Note only 6 of the 8 potential

queues of the Cisco 5760 WLC
distribution port will be utilized
with an 8-class QoS model. The
remaining 2 queues will have no
traffic class mapped to them.
294884
Campus Network
Infrastructure
Policy 3: CT5760 Wireless LAN Controller Distribution System Ports
Pass DSCPTrust is enabled for wired-to-wired traffic by default
Enable 2P6Q3T egress queuing for an 8-class QoS model
7-15
Chapter 7
Quality of Service
Policy 3 addresses the QoS policy for the distribution system port of the Cisco CT5760 wireless
controller when deployed either within the campus in a Converged Access infrastructure or as a
centralized wireless controller. By default DSCP values are preserved across the wireless SSID boundary
with IOS XE 3.3.0SE software release and higher. Ingress queuing is not supported on the Cisco CT5760
wireless controller. Egress queuing will consist of mapping an 8-class QoS model to a 2P6Q3T egress
queuing structure of the Cisco CT5760 wireless controller. Figure 7-11 shows the mapping of the 8-class
model to the egress queues.
Figure 7-11
2P6Q3T Egress Queuing for an 8-class QoS ModelCisco CT5760
Application Classes
DSCP
Voice
EF
Interactive Video
AF4
Network Control
2P6Q3T
EF
CS6
CS3
Priority Level 1
AF4
Priority Level 2
CS6
Unused Queue*
Signaling
CS3
Bulk Data
AF1
Transactional Data
AF2
Scavenger
CS1
Best Effort
DF
AF1
Bulk Data Queue

(25% BWR
+ DSCP-based WTD)
AF2

(35% BWR
+ DSCP-based WTD)
CS1
Scavenger Queue
(5% BWR)
DF
Default Queue
(35% BWR + WTD)
294882
Unused Queue*
*Note only 6 of the 8 potential queues will be used with an 8-class QoS Model
The following provides a configuration example of Policy 3: Cisco CT5760 Wireless LAN Controller
Distribution Ports.
!
class-map match-any
match dscp ef
match dscp cs3
match dscp cs6
class-map match-any
match dscp af41
match dscp af42
match dscp af43
class-map match-any
match dscp af11
match dscp af12
match dscp af13
class-map match-any
match dscp af21
match dscp af22
match dscp af23
class-map match-any
RT1
RT2
BULK-DATA-QUEUE
TRANSACTIONAL-DATA-QUEUE
SCAVENGER-QUEUE
7-16
Chapter 7

Quality of Service
match dscp cs1

!
policy-map 2P6Q3T
class RT1
priority level 1
class RT2
priority level 2
class class-default
!
!
Traffic marked EF, CS6, and CS3 is bundled into a traffic class called RT1 and placed into the
priority-level 1 queue. Traffic marked as AF4x is placed into a traffic class called RT2 (instead of
Interactive Video) and placed into the priority-level 2 queue.
Note
Policy 3 still supports traffic marked with 8 possible different DSCP markings. Hence it is referred to as
an 8-class QoS model within this document. However it could also be referred to as a 6-class QoS model,
since traffic is aggregated into six traffic classes before being mapped to the queues. This is basically
due to the way class maps and policy maps are defined for the Cisco Modular QOS CLI (MQC).
The assignment of the priority level 1 command to the user-defined RT1 class causes traffic which
matches the RT1 class to be placed into the first priority queue. The assignment of the priority level 2
command to the user-defined RT2 class causes traffic which matches the RT2 class to be placed into the
second priority queue. The priority level commands must be defined at the child-level of the port policy
map if the network administrator wishes to place traffic into the priority queues. Policers defined within
the child-level of the port policy map apply to multicast priority traffic only.
Note that with an 8-class QoS model, only six of the eight possible queues on the Cisco CT5760
distribution system port are used. This is slightly different from the Policy 1 design shown for the uplink
port of the Catalyst 3850 Series switch since the Catalyst 3850 series switch handles both wired and
wireless traffic, while the CT5760 wireless controller handles only wireless traffic. For wireless ports on
the Catalyst 3850 series switch and distribution system ports on the CT5760 wireless controller, CS3 and
CS6 traffic is mapped to the RT1 queue along with EF traffic in this design. As discussed in SSID-Level
QoS Policies, the mapping of CS3 and CS6 traffic to the RT1 queue is also done at the SSID level for
the Employee and Personal Devices SSIDs. This is in order to ensure that signaling and network control
traffic are not subject to the Approximate Fair Drop (AFD) algorithm within the Unified Access Data
Plane (UADP) ASIC. AFD applies to wireless traffic only. Hence for the uplink port of the Catalyst 3850
7-17
Chapter 7
Quality of Service
series switch, it is not necessary to place CS3 and CS6 traffic into the priority-level 1 queue. However
if a consistent port-level policy map configuration is desired between Catalyst 3850 uplink ports and
CT5760 distribution system ports, then Alternative Policy 1 discussed previously can be implemented.
SSID-Level QoS Policies

The SSID-level QoS policies discussed within this section are the same for the Catalyst 3850 Series
switches deployed in Converged Access campus designs, Cisco CT5760 wireless LAN controllers
deployed in centralized campus designs, and Catalyst 3850 Series switches deployed in Converged
Access branch designs. The overall SSID-level policy consists of downstream bandwidth management
per SSID, along with the ability to support real-time traffic (voice and/or video) in the downstream
direction via the SSID policy map.
The objective of the SSID-level QoS policy in the design presented here is twofold. The first objective
is to constrain the downstream bandwidth usage of specific WLANs/SSIDs. In particular this is shown
for the Guest WLAN/SSID in order to ensure that the amount of wireless bandwidth consumed by
wireless guest traffic does not adversely affect other SSIDs. This assumes that other WLANs/SSIDs have
a higher business priority than the Guest WLAN/SSID. However the design can be easily extended to
constrain downstream bandwidth usage for multiple WLANs/SSIDs as needed, based on the business
requirements of the particular organization.
The second objective is to allow for the support of real-time traffic classes and to constrain the bandwidth
usage of those real-time traffic classes on specific WLANs/SSIDs. In particular this is shown for the
Employee and Personal Devices WLANs/SSIDs. It is anticipated that these WLANs/SSIDs will support
wireless devices which may require real-time applications such as VoIP and video client software. This
design assumes that the other WLANs/SSIDs (Guest, Provisioning, and IT Devices) will not have the
business requirement for supporting real-time traffic classes. Any real-time traffic on these
WLANs/SSIDs is remarked to best effort and treated as non-real-time traffic as it is sent downstream.
However, again the design can easily be modified to add or remove the ability to support real-time traffic
classes on any WLAN/SSID, as business requirements dictate.
Downstream bandwidth utilization constraints for the five BYOD WLANs/SSIDs are as shown in
Figure 7-12.
7-18
Chapter 7

Quality of Service
Figure 7-12
Downstream SSID-Level QoS Policies
Centralized Campus
Converged Access Branch
Cisco CT5780
WLCs
Catalyst 3850
Switch Stack
Campus Network
Infrastructure
CAPWAP
CAPWAP
CAPWAP
Downstream
SSID
Policies
Guest
SSID
6 Mbps
BW, No
Real-Time
Traffic
Personal
Devices
SSID
No BW
Limit,
Real-Time
Traffic
Catalyst 3850
Switch Stack
Employee
SSID
No BW
Limit,
Real-Time
Traffic
Provisioning
SSID
No BW
Limit, No
Real-Time
Traffic
IT Devices
SSID
No BW
Limit, No
Real-Time
Traffic
294885
QoS Trust
Boundary
Policy 4: Downstream SSID Policy
Pass DSCPUntrusted command disabled
Downstream rate limiting of aggregate traffic for Guest SSID
Priority and policing of real-time traffic for Employee and Personal Devices SSIDs
Campus and Branch Considerations

In the campus it is assumed that the wired infrastructure bandwidth exceeds the wireless bandwidth.
Hence the objective is often to simply constrain the downstream bandwidth usage of specific
WLANs/SSIDs, such as the Guest SSID, in order to ensure sufficient wireless bandwidth for more
business critical WLANs/SSIDs, such as the Employee SSID. In the branch, the wireless bandwidth
often exceeds the WAN circuit bandwidth to the branch. Hence the objective of many customers is often
to constrain bandwidth usage of specific branch WLANS/SSIDs so that the overall branch WAN
bandwidth is not oversubscribed. A common design implemented for branch guest wireless access is to
backhaul guest traffic to a dedicated guest wireless LAN controller on a DMZ segment within the
campus Internet edge. This is the guest wireless access design discussed within this design guide. Hence
the objective of branch deployments is often to constrain the guest wireless access so that it does not
utilize all of the branch WAN bandwidth.
7-19
Chapter 7
Quality of Service
The Cisco BYOD solution has two wireless designs for branch locationsa FlexConnect branch design
and a Converged Access branch design. In Chapter 21, BYOD Guest Wireless Access, the wireless
FlexConnect branch design discusses implementing per SSID upstream and downstream rate-limiting.
Rate-limiting is actually done on a per-SSID, per-radio, per access point basis. In other words,
rate-limiting is actually per BSSID. Hence the chapter includes information abut the following issues:
The possibility of oversubscribing the desired bandwidth allocation for guest wireless access if
multiple access points are deployed within the branch and each access point is allowed a certain
amount of bandwidth.
The possibility of oversubscribing the desired bandwidth allocation if multiple radios (2.4 GHz and
5 GHz) are used per SSID within the branch and each SSID is allowed a certain amount of
bandwidth.
The fact that downstream rate limiting relies on the TCP backoff algorithm in order to throttle traffic
by dropping the traffic after it has been sent downstream across the WAN to the branch. Hence the
design may not work effectively for UDP traffic flows.
FlexConnect branch designs are often (but not always) implemented for smaller branch designs in which
only a handful of access points are deployed at the branch. Hence, although this design is not considered
optimal, it may be beneficial to customers with smaller branch deployments.
This section of the design guide focuses only on Converged Access designs. A per-SSID downstream
rate-limiting design (similar to the FlexConnect branch design) is shown in the following sections with
Converged Access Catalyst 3850 switches at the small branch location. The Guest WLAN/SSID is
rate-limited through the use of the shape average command implemented at the parent-level of the
downstream SSID policy. However it should be noted that the Converged Access small branch design is
targeted for branches with up to 50 access points. Without the ability to constrain bandwidth utilization
across the entire SSID (meaning across all access points which implement the SSID within a given
branch branch), the per-BSSID design may not provide as much benefit with larger deployments, if the
objective is protect the amount of bandwidth utilized across the WAN. Further, backhauling the Guest
WLAN/SSID back to a dedicated wireless controller within the campus Internet edge is not a highly
scalable model with the Converged Access design. This is due to limitations on the number of mobility
tunnels (a total of 71) to controllers within a mobility group. Hence, it is recognized that this design may
not necessarily alleviate the issue of WAN bandwidth depletion due to traffic on the Guest WLAN/SSID.
Instead the customer may wish to look into deploying a design where guest wireless access is sent
directly to the Internet from the branch.
Downstream SSID Policy Configuration Examples

Policy 4 addresses the QoS policy for each of the SSIDs when deployed in any of the following
infrastructures:
Within the campus on a Catalyst 3850 Series switch in a Converged Access design
Within the campus on a Cisco CT5760 wireless LAN controller in a centralized design
Within the branch on a Catalyst 3850 Series switch in a Converged Access design
Note that for the CT5760 wireless controller, the SSID policy can differ, depending upon whether a
1P7Q3T or a 2P6Q3T egress port queuing policy has been applied. This is because both real-time queues
cannot be utilized at the child-level of the SSID policy map unless both real-time queues are also defined
at the child-level of the port policy map. For this design guide, only a 2P6Q3T port egress queuing model
is discussed for the CT5760 wireless controller. This is in order to maintain a single downstream SSID
policy for each of the WLANs/SSIDs which can be applied for campus Converged Access designs,
campus CT5760 centralized wireless controller designs, and branch Converged Access designs.
7-20
Chapter 7

Quality of Service
The SSID policies shown in the examples below are applied in the downstream direction (meaning from
the Catalyst switch or CT5760 wireless controller port to the access point) for the WLAN/SSID. This is
accomplished via the service-policy output command under the WLAN configuration. The
service-policy output command specifies the name of the parent-level SSID policy map. The parent-level
SSID policy map, in turn, specifies the name of the child-level SSID policy map via a service-policy
command defined within the policy map.
An example of the policy for each of the WLANs/SSIDs is shown in the configuration examples below.
Employee WLAN/SSID
!
no qos wireless-default-untrust/Default Setting
!
match dscp af41
match dscp af42
match dscp af43
!
match dscp cs6
match dscp cs3
match dscp ef
!
policy-map EMPLOYEE_DOWNSTREAM
class class-default
shape average percent 100
service-policy REALTIME_DOWNSTREAM_CHILD
policy-map REALTIME_DOWNSTREAM_CHILD
class RT1
priority level 1
police 15000000 conform-action transmit exceed-action drop
class RT2
priority level 2
class class-default
!
wlan BYOD_Employee 1 BYOD_Employee
aaa-override
client vlan Employee
nac
service-policy output EMPLOYEE_DOWNSTREAM
session-timeout 300
no shutdown
!
The no qos wireless-default-untrust command is the default setting with IOS XE 3.3.0SE and higher
and will not be visible within the actual configuration. It has been included here simply to point out that
the default setting for IOS XE 3.3.0SE and higher is to trust DSCP markings as traffic crosses the SSID
boundary. In other words, DSCP markings will be preserved by default for downstream
wired-to-wireless traffic and upstream wireless-to-wired traffic with IOS XE 3.3.0SE software release
and higher.
The Employee SSID is allowed to utilize up to all of the remaining downstream wireless
bandwidthafter the RT1 and RT2 traffic which is sent via the two priority queues is serviced. This is
accomplished via the shape average percent 100 command at the parent-level of the downstream SSID
policy map.
7-21
Chapter 7
Quality of Service
Note
The total amount of traffic which can be sent downstream (egress) on the switch port is constrained by
a non-configurable internal static shaper for each radio supported by the attached access point. The 5
GHz radio is statically shaped to 400 Mbps, while the 2.4 GHz radio is statically shaped to 200 Mbps.
The reason the shape average percent 100 command is used in the configuration example above is that
the parent-level of the downstream SSID policy map must have some constraint defined in order to
configure priority queues and policed rates for the RT1 and RT2 traffic defined at the child-level of the
SSID policy map.
Within the configuration above, voice (EF), call signaling (CS3), and network control (CS6) traffic are
classified into the RT1 traffic class. Video (AF4x) traffic is classified into the RT2 traffic class. The
Employee WLAN/SSID is configured to place traffic which matches the RT1 traffic class into the
priority-level 1 egress queue and traffic which matches the RT2 traffic class into the priority-level 2
egress queue. In the example configuration, RT1 traffic is policed to 15 Mbps and RT2 traffic is policed
to 30 Mbps. Hence the Employee WLAN/SSID is configured to support and rate-limit the amount
real-time voice (via the RT1 traffic class) and video (via the RT2 traffic class) traffic sent via the priority
queues.
The specific policed rates for RT1 and RT2 traffic will vary per customer, depending upon how much
voice and video is required per WLAN/SSID. Choosing the policed rates for RT1 and RT2 traffic may
need to take into consideration that the WLAN/SSID policy may apply to both 5 GHz and 2.4 GHz
radios, which may have different physical medium rates, if both radios are enabled for a given
WLAN/SSID. Obviously one method of resolving this issue would be to enable either the 5 GHz or 2.4
GHz radio for each WLAN/SSID and set the RT1 and RT2 policed rates based on a percentage of the
maximum physical medium rate given the radio frequency. An additional factor to consider is type of
application. Voice, for example, is well behaved. Hence the policer rate can be calculated based on the
maximum number of possible of voice calls. However the actual physical medium rate for a given radio
at any given moment depends on many variables, including the number of antennas and spatial streams
supported by the mobile device, as well as the signal strength received at the mobile device and access
point. Hence the network administrator may need to define policed rates for RT1 and RT2 traffic based
on an initial best guess as to the amount of such traffic on the WLAN/SSID, then monitor the policers
to determine if drops are occurring and adjust the policed rates up or down accordingly.
The network administrator should note that the definition of the child-level of the downstream
WLAN/SSID policy map is only needed when the requirement is to rate-limit (via policers) unicast
traffic which matches the RT1 and RT2 (real-time) traffic classes. The definition of the RT1 and RT2
traffic classes at the child-level of the port policy map will already cause traffic which matches these
classes to be placed into the priority queues. Rate-limiting of the priority queues puts a limit on the
amount of downstream real-time traffic on the WLAN/SSID, so that non-real-time traffic will have some
percentage of available bandwidth. The shape average percent command at the parent-level of the
downstream SSID policy map refers to the allocation of remaining bandwidth after real-time traffic has
been serviced. Hence if real-time traffic is not constrained, it could take up all of the available egress
bandwidth of the physical port (up to the non-configurable internal 400 Mbps radio shaped rate for the
5 GHz radio and/or the internal 200 Mbps shaped rate for the 2.4 GHz radio) connecting the Catalyst
3850 switch to the access point.
The shape average command at the parent-level of the downstream SSID policy map is implemented
through the Approximate Fair Drop (AFD) algorithm within the Universal Access Data Plane (UADP)
ASIC. It is not really a shaper as defined under the Cisco Modular QoS CLI (MQC) syntax. More
specifically, the shaper has no buffering capacity and hence no burst (Bc) configuration and no time
constant (Tc) associated with the committed information rate (CIR). This is indicated by the
queue-buffers ratio 0 command, which must be configured when the shape average command is
configured at the parent-level of the downstream SSID policy map.
7-22
Chapter 7

Quality of Service
In the example shown above, signaling (CS3) and network control (CS6) traffic are also classified as part
of RT1 traffic and placed into the priority-level 1 queue. This is to ensure that signaling and control
traffic are not subject to the Approximate Fair Drop (AFD) algorithm within the Unified Access Data
Plane (UADP) ASIC. The AFD algorithm is designed to allocate bandwidth fairly between wireless
clients on a per access point, per radio, per SSID basis. This provides the benefit that no single wireless
client can utilize an excessive amount of downstream wireless bandwidth, degrading the performance
for all other wireless clients. AFD accomplishes this by increasing the drop probability for particular
wireless client traffic when the amount of downstream traffic destined for that client exceeds an
internally calculated fair-share. The fair-share for a wireless client is dynamically calculated based
on the total number of wireless clients per access point, per radio (2.4 GHz or 5 GHz), per SSID, and the
amount of congestion occurring at the non-real-time egress queue of the physical port. The amount of
congestion occurring is directly related to the aggregate amount of traffic being sent downstream per
radio on the SSID. The aggregate effect of AFD operating on all wireless clients per access point, per
radio (2.4 GHz or 5 GHz), per SSID is what actually implements the shape average command within the
parent-level of the downstream SSID policy map. However traffic placed into the priority-level 1 and
priority-level 2 queues are not subject to the AFD algorithm. This is to prevent real-time traffic streams
such as voice and video from being unnecessarily degraded by AFD.
The priority-level 1 (RT1) queue has been utilized for signaling (CS3) traffic in the example. Otherwise
signaling traffic would be in the class-default traffic class and may have a greater chance of being
dropped, affecting voice and video sessions. Traffic in the class-default class includes TCP traffic which
is bursty and prone to packet drops. Real-time traffic such as voice and video are UDP based, are well
behaved in general, and these classes can more easily be engineered to have no traffic drops. Even though
the RT1 and RT2 traffic classes have policers in them, these policing rates can be adjusted so as to ensure
no drops. This is the reason the signaling traffic and (CS3) and network control traffic (CS6) are included
in RT1 in this design. However if the total amount of voice or video traffic sent downstream on the SSID
exceeds the policer defined for the traffic class, then any excess traffic will be dropped. This means that
any signaling (CS3) or network control (CS6) traffic included within the traffic class will also be
dropped. Voice (EF) traffic is generally more well-known and well behaved and call-admission control
(CAC) is more widely deployed for voice calls. Because of this, it is considered less likely that the
policer defined for the RT1 traffic class will be exceeded in actual network implementations. Therefore
the RT1 traffic class was selected for holding signaling (CS3) and network control (CS6) traffic as well
as voice (EF) traffic for the example design.
Personal Devices WLAN/SSID
The configuration of QoS for the Personal Devices WLAN/SSID is very similar to the configuration of
the Employee WLAN/SSID, except that the policing rates are different.
!
!
match dscp af41
match dscp af42
match dscp af43
!
match dscp cs6
match dscp cs3
match dscp ef
!
policy-map PERSONAL_DOWNSTREAM
class class-default
service-policy REALTIME_DOWNSTREAM_CHILD_PERSONAL
policy-map REALTIME_DOWNSTREAM_CHILD_PERSONAL
7-23
Chapter 7
Quality of Service
class RT1
priority level 1
class RT2
priority level 2
class class-default
!
wlan BYOD_Personal_Device 4 BYOD_Personal_Device
client vlan Guest
mobility anchor 10.225.50.36
service-policy output PERSONAL_DOWNSTREAM
session-timeout 1800
no shutdown
!
The Personal Devices WLAN/SSID is also allowed to utilize up to all of the remaining downstream
wireless bandwidthafter the RT1 and RT2 traffic which is sent via the two priority queues is serviced.
This is accomplished via the shape average percent 100 command configured at the parent-level of the
downstream SSID policy map.
The Personal Devices WLAN/SSID is also configured to support voice (via the RT1 traffic class) and
video (via the RT2 traffic class) via the priority queues. However the policed rates are intentionally
configured to be different from the Employee WLAN/SSID in the example configuration in order to
highlight that different real-time traffic rates can be supported per SSID. RT1 traffic is policed to 4.5
Mbps and RT2 traffic is policed to 9 Mbps for the Personal Devices WLAN/SSID.
Guest WLAN/SSID
Unlike the other SSIDs, there is a hard bandwidth limit placed in the example configuration for the Guess
SSID, which is allowed to utilize up to 6 Mbps of downstream wireless bandwidth. The Guest
WLAN/SSID is not configured to support real-time traffic via the RT1 and RT2 traffic classes. Instead,
the Guest WLAN/SSID is configured to place all traffic into the client non-real-time egress queue of the
Catalyst 3850 switch port or non-real-time egress queues of the CT5760 wireless controller port.
!
!
table-map remarkToDefault
default 0
!
policy-map GUEST_DOWNSTREAM
class class-default
shape average 6000000
set dscp dscp table remarkToDefault
set wlan user-priority dscp table remarkToDefault
!
wlan BYOD_Guest 2 BYOD_Guest
aaa-override
client vlan BYOD_Guest
no security wpa
no security wpa akm dot1x
no security wpa wpa2
no security wpa wpa2 ciphers aes
security web-auth
service-policy output GUEST_DOWNSTREAM
no shutdown
!
7-24
Chapter 7

Quality of Service
Note
The examples in this design guide show the same SSID-level policies applied in both campus and branch
designs. In actual deployments, the amount of bandwidth configured for the Guest WLAN/SSID at the
branch may be lower than that configured for the Guest WLAN/SSID within the campus. This is because
the WAN bandwidth connecting the branch to the campus may be the constraining factor for limiting
guest wireless bandwidth utilization at the branch.
In the BYOD design within this document, guest traffic is terminated on a DMZ segment within the
Internet Edge. This allows only Internet access via the ASA firewall. Hence there should only be traffic
with best effort (DSCP 0) markings on the Guest WLAN/SSID. However due to the functioning of QoS
at the child-level of the port policy map, if any traffic which matches the RT1 traffic class (EF, CS3, or
CS6) is sent downstream, it will be placed into the priority level 1 egress queue at the Catalyst 3850
switch port or CT5760 distribution system port. Likewise if any traffic which matches the RT2 traffic
class (AF4x) is sent downstream, it will be placed into the priority level 2 egress queue at the Catalyst
3850 switch port or CT5760 distribution system port. Since there is no child-level of the downstream
SSID policy map for the Guest WLAN/SSID, the RT1 and RT2 traffic would also be unconstrained in
terms of the amount of bandwidth they could utilize. This presents a potential concern, in that it could
result in degradation of actual voice and video calls over other SSIDs. In order to prevent this, a table
map which explicitly remarks all traffic back to best effort (DSCP 0) has been included in the
downstream SSID policy. This is indicated by the set dscp dscp table remarkToDefault command
defined at the parent-level of the downstream SSID policy map. The command applies the table map
named remarkToDefault to downstream traffic on the Guest WLAN/SSID. The remarkToDefault table
map has a single line which re-marks all traffic to 0 (best effort).
Note also that the 802.11e User Priority (UP) marking of the wireless frame as it is sent over the wireless
medium is based upon the DSCP marking of the original IP packet sent downstream. The original
Ethernet frame is converted to an 802.11 frame and encapsulated within the CAPWAP header before
DSCP and/or UP re-marking occurs. Therefore a second table map which marks the User Priority (UP)
of traffic sent over the wireless medium to best effort (UP 0) has also been included in the downstream
SSID policy. This is indicated by the set wlan user-priority dscp table remarkToDefault command
defined at the parent-level of the downstream SSID policy map.
Provisioning WLAN/SSID
!
!
default 0
!
policy-map PROVISIONING_DOWNSTREAM
class class-default
!
wlan BYOD_Provisioning 3 BYOD_Provisioning
aaa-override
client vlan Provisioning
mac-filtering MAC_ALLOW
nac
no security wpa
service-policy output PROVISIONING_DOWNSTREAM
shutdown
!
7-25
Chapter 7
Quality of Service
The Provisioning WLAN/SSID has no constraint on the amount of downstream bandwidth utilization.
The Provisioning WLAN/SSID is not configured to support real-time traffic via the RT1 and RT2 traffic
classes. Instead, it is configured remark all traffic to best effort and to place all traffic into the client
non-real-time egress queue of the Catalyst 3850 switch port or non-real-time egress queues of the
CT5760 wireless controller port.
The Provisioning WLAN/SSID is an optional WLAN/SSID dedicated for BYOD on-boarding when the
customer implements a dual-SSID on-boarding design. Provisioning traffic consists of HTTP/S traffic
to and from ISE, potentially traffic to and from an on-premise or cloud-based Mobile Device Manager
(MDM), and potentially traffic to and from the Google Play store for Android devices. For the purposes
of this design guide, all provisioning traffic is remarked to best effort (DSCP 0) in the downstream
direction at the Catalyst 3850 switch. The customer can choose to modify the SSID policy map if desired
in order to achieve different behavior of provisioning traffic.
IT Devices WLAN/SSID
!
!
default 0
!
policy-map IT_DEVICES_DOWNSTREAM
class class-default
!
wlan IT_Devices 5 IT_Devices
aaa-override
nac
no security wpa
service-policy output IT_DEVICES_DOWNSTREAM
shutdown
!
The IT Devices WLAN/SSID has no constraint on the amount of downstream bandwidth utilization in
this design example. The IT Devices WLAN/SSID is not configured to support real-time traffic via the
RT1 and RT2 traffic classes. Instead, it is configured to remark all traffic to best effort and place all
traffic into the client non-real-time egress queue of the Catalyst 3850 switch port or non-real-time queues
of the CT5760 wireless controller port. For the purposes of this design guide, all IT devices traffic is
remarked to best effort (DSCP 0) in the downstream direction at the Catalyst 3850 switch. The customer
can choose to modify the SSID policy map if desired in order to achieve different behavior of IT devices
traffic.
Client-Level QoS Policies

The overall client-level policy consists of upstream classification and marking of wireless client traffic.
Individual traffic classes may also be optionally policed upstream to rate-limit traffic on a per
wireless-client basis on Catalyst 3850 Series switches. Note that upstream client-level policing is not
supported on Cisco CT5760 wireless controllers as of IOS XE software version 3.3.1SE. The client-level
policies are shown in Figure 7-13 and Figure 7-14.
7-26

Quality of Service
Figure 7-13
Catalyst 3850 Client QoS PoliciesConverged Access Campus or Branch Deployment
Catalyst 3850
Switch Stack
QoS Trust
Boundary
CAPWAP
Guest
SSID
Personal
Devices
SSID
Employee
SSID
Provisioning
SSID
Upstream
Client
Policies
IT Devices
SSID
294886
Chapter 7
Policy 5: Wireless Endpoint Per-Client QoS
Upstream Client Policy
Classify and remark traffic for Employee and Personal Devices SSIDs
Remark all traffic to default (best effort) for Guest, Provisioning and IT Devices SSIDs
Optional upstream policing of traffic classes
QoS policy name can be statically attached to the SSID, or can be pushed from RADIUS server
(Cisco ISE)
For the centralized campus deployment, the upstream client QoS policy is similar to that in that in the
converged access campus and branch deployments, except that there is no per-client policing (Cisco
5760 does not support client level policing as of IOS XE software version 3.3.1SE).
7-27
Chapter 7
Quality of Service
Figure 7-14
Cisco 5760 Client QoS PoliciesCentralized Campus Deployment
Cisco CT5780
WLCs
Campus Network
Infrastructure
QoS Trust
Boundary
CAPWAP
Personal
Devices
SSID
Employee
SSID
Provisioning
SSID
Upstream
Client
Policies
IT Devices
SSID
294887
Guest
SSID
Policy 5: Wireless Endpoint Per-Client QoS
Upstream Client Policy
Classify and remark traffic for Employee and Personal Devices SSIDs
Remark all traffic to default (best effort) for Guest, Provisioning and IT Devices SSIDs
QoS policy name can be statically attached to the SSID, or can be pushed from RADIUS server
(Cisco ISE)
The traffic classes included for specific client level policies will differ based upon the SSID to which the
client device is attached. For the Employee and Personal Devices SSIDs, the assumption is that various
traffic types will be supported. Other SSIDs treat client traffic as best effort traffic. Table 7-3 shows the
application classes and marking for the Employee and Personal Devices SSIDs.
Table 7-3
Traffic Classification for Employee and Personal Devices WLANs/SSIDs
Application Class
Classification Criteria
Marking
Voice
Trust Marking from Client and/or Port Range
EF
Cisco Jabber (UDP/RTP 16384-32767)

Signaling
SCCP (TCP 2000) or SIP (TCP 5060-50610
CS3
Network Control
Network Control
CS6
7-28
Chapter 7

Quality of Service
Table 7-3
Traffic Classification for Employee and Personal Devices WLANs/SSIDs
Interactive Video
Trust Marking from Client and/or Port Range
AF41
Cisco Jabber (UDP/RTP 16384-32767)

Microsoft Lync (TCP 50000-59999)
Transactional Data
AF21
HTTPS (TCP 443)

Citrix (TCP 3389, 5985, 8080)
Oracle (TCP 1521, 1527, 1575, 1630, 6200)
Bulk Data
FTP (TCP 20 & 21) or Secure FTP (TCP 22)
AF11
SMTP (TCP 25) or Secure SMTP (TCP 465)

IMAP (TCP 143) or Secure IMAP (TCP 993)
POP3 (TCP 11) or Secure POP3 (TCP 995)
Connected PC Backup (TCP 1914)
Scavenger
CS1
BitTorrent (TCP 6881-6999)

Apple iTunes (TCP/UDP 3689)
Microsoft Direct X Gaming (TCP/UDP 2300-2400)
Best Effort
Default (All Other Traffic Not Matched by Any Other Traffic Class) Default
The following configuration example shows the access-lists configured in order to map traffic classes as
shown in Figure 7-14.
!
ip access-list extended VOICE
remark - CISCO-JABBER-REDUCED-PORT-RANGE
permit udp any any range 16384 17384
!
ip access-list extended INTERACTIVE-VIDEO
remark CISCO-JABBER-RTP
remark MICROSOFT-LYNC
permit tcp any any range 50000 59999
!
ip access-list extended SIGNALING
remark SCCP
permit tcp any any eq 2000
remark SIP
!
ip access-list extended TRANSACTIONAL-DATA
remark HTTPS
remark CITRIX
remark ORACLE
!
ip access-list extended BULK-DATA
7-29
Chapter 7
Quality of Service
remark
permit
permit
remark
permit
remark
permit
permit
remark
permit
permit
remark
permit
permit
remark
permit
FTP
tcp any any eq ftp
tcp any any eq ftp-data
SSH/SFTP
tcp any any eq 22
SMTP/SECURE SMTP
tcp any any eq smtp
tcp any any eq 465
IMAP/SECURE IMAP
tcp any any eq 143
tcp any any eq 993
POP3/SECURE POP3
tcp any any eq pop3
tcp any any eq 995
CONNECTED PC BACKUP
tcp any eq 1914 any
!
ip access-list extended SCAVENGER
remark BITTORRENT
remark APPLE ITUNES MUSIC SHARING
permit udp any any eq 3689
remark MICROSOFT DIRECT X GAMING
!
The following configuration example shows the class maps defined for the client-level policies.
!
class-map match-any VOICE
match dscp ef
match access-group VOICE
!
class-map match-any INTERACTIVE-VIDEO
match access-group name INTERACTIVE-VIDEO
!
class-map match-any SIGNALING
match dscp cs3
match access-group name SIGNALING
!
class-map match-any NETWORK-CONTROL
match dscp cs6
!
class-map match-any TRANSACTIONAL-DATA
match access-group name TRANSACTIONAL-DATA
!
class-map match-any BULK-DATA
match access-group name BULK-DATA
!
class-map match-any SCAVENGER
match access-group name SCAVENGER
!
Note that the example above intentionally highlights two methods to differentiate voice from video
traffic. First, if the wireless client correctly marks voice traffic to EF and video traffic to anything other
than EF, then voice traffic can be differentiated simply by its ingress DSCP marking, since typically both
voice and video flows utilize the full RTP port range of 16384-32767. However certain applications such
as Cisco Unified Communications Manager (CUCM) also give the network administrator the ability to
define restricted port ranges for voice and video flows under the control of CUCM. The example above
shows Cisco Jabber voice flows being identified by either a DSCP marking of EF or an RTP port range
of 16384-17384. Jabber video flows are identified by an RTP port range of 17385-32767. Note that the
use of restricted port ranges as a method of differentiating voice from video flows should be used with
7-30
Chapter 7

Quality of Service
caution and only when the network administrator has centralized control of the port ranges used by all
voice and video streams, as when CUCM is deployed. Otherwise video flows could be misclassified as
voice flows and vice-versa.
Note
Catalyst 3850 Series switches and CT5760 wireless LAN controllers only support the match-any
command within class-map definitions. The match-all command is not supported as of IOS XE
3.3.1SE.
Classification and Marking Policy

The following configuration example shows the policy map defined for the client-level policies for the
Employee and Personal Devices WLANs/SSIDs when implementing an upstream client-level policy
which includes only classification and marking.
!
policy-map REMARK_UPSTREAM_CLIENT
class VOICE
set dscp ef
class SIGNALING
set dscp cs3
class INTERACTIVE-VIDEO
set dscp af41
class TRANSACTIONAL-DATA
set dscp af21
class BULK-DATA
set dscp af11
class SCAVENGER
set dscp cs1
class class-default
set dscp default
!
Classification, Marking, and Policing PolicyCatalyst 3850 Only

Optionally, the network administrator may choose to police one or more traffic classes per client in the
upstream direction. This is similar to wired ingress port policies where voice and/or video traffic may
be policed more from a security perspective. Ingress policing may be applied in order to ensure an
intentional or unintentional misbehaving device does not consume all available bandwidth allocated for
real-time traffic, which would result in the degradation of all other real-time flows. Note that this policy
is only applicable to Catalyst 3850 Series switches. Upstream policing at the client-level policy is not
supported on the Cisco CT5760 wireless controller as of IOS XE software version 3.3.1SE.
The following configuration example shows the policy map defined for the client-level policies for the
Employee and Personal Devices WLANs/SSIDs, when implementing an upstream client-level policy
which includes classification and marking, as well as policing for the voice and video traffic classes. As
always, the network administrator can choose to police other traffic classes as business requirements
dictate.
policy-map REMARK_POLICE_UPSTREAM_CLIENT
class VOICE
set dscp ef
police cir 128000 bc 4000 conform-action transmit exceed-action drop
class SIGNALING
set dscp cs3
set dscp af41
police cir 768000 bc 24000 conform-action transmit exceed-action drop
7-31
Chapter 7
Quality of Service
class
set
class
set
class
set
class
set
TRANSACTIONAL-DATA
dscp af21
BULK-DATA
dscp af11
SCAVENGER
dscp cs1
class-default
dscp default
Voice and video traffic flows are typically well-known and configurable in terms of their data rates per
client, which lends itself well to implementing ingress policing. In the example client-level policy map
above, voice traffic is policed to 128 Kbps and video traffic is policed to 768 Kbps per wireless client,
with a time constant (Tc) of 250 milliseconds for each policer. The network administrator will need to
take into account the Layer 2 (802.11) and Layer 3 (IP/UDP) protocol overhead when defining the
policed rates for voice and video streams. This is not shown, for simplicity, in the example above.
Note
The actual traffic rates received by a given client have been observed during validation testing to differ
by up to 10-15% from the configured rate. One reason for this may be protocol overhead, since the
configured policers and shapers are implemented on the Catalyst 3850 Series switch, and downstream
WiFi traffic is encapsulated within both a CAPWAP header as well as a Layer 2 Ethernet header, as it is
sent between the Catalyst 3850 Series switch and the Access Point. These headers are stripped off as the
802.11 frame is sent over the WiFi medium and received by the wireless client. Also, the 802.11 WiFi
medium itself is inherently contention-based and half-duplex in nature, requiring acknowledgement of
each frame, or in some cases groups of frames, received.
For the Guest, Provisioning, and IT Devices SSIDs, the assumption is all traffic will be simply re-marked
to the default (Best Effort) traffic class. The following configuration example shows the policy map
defined for the client-level policies for the Guest, Provisioning, and IT Devices WLANs/SSIDs, when
implementing an upstream client-level policy which includes only classification and marking.
!
policy-map DEFAULT_UPSTREAM_CLIENT
class class-default
set dscp default
!
Similar to the client-level policy for the Employee and Personal Devices WLANs/SSIDs, an ingress
policy map which includes a policer can also be applied to the Guest, Provisioning, and IT Devices
WLANs/SSIDs. In this case, since all traffic from any wireless client on these WLANs/SSIDs is
classified and re-marked to default, the policer would rate-limit the total ingress traffic from the wireless
client.
Static Application of Client-Level Policy

An example of the static application of either the REMARK_UPSTREAM_CLIENT or
DEFAULT_UPSTREAM_CLIENT client-level policy maps for each of the WLANs/SSIDs is shown in
the following sections.
Employee WLAN/SSID
!
aaa-override
nac
7-32
Chapter 7

Quality of Service
service-policy client input REMARK_UPSTREAM_CLIENT

session-timeout 300
no shutdown
!
For the Employee WLAN/SSID, the REMARK_UPSTREAM_CLIENT policy is applied as an upstream

client policy.
Personal Devices WLAN/SSID
!
client vlan Guest
no shutdown
!
For the Personal Devices WLAN/SSID, the REMARK_UPSTREAM_CLIENT policy is also applied as
an upstream client policy.
Guest WLAN/SSID
!
aaa-override
no security wpa
security web-auth
service-policy client input DEFAULT_UPSTREAM_CLIENT
no shutdown
!
For the Guest WLAN/SSID, the DEFAULT_UPSTREAM_CLIENT policy, which remarks all traffic to
Best Effort, is applied as an upstream client policy.
Provisioning WLAN/SSID
!
aaa-override
nac
no security wpa
no shutdown
!
For the Provisioning WLAN/SSID, the DEFAULT_UPSTREAM_CLIENT policy, which remarks all
traffic to Best Effort, is also applied as an upstream client policy.
7-33
Chapter 7
Quality of Service
IT Devices WLAN/SSID
!
aaa-override
nac
no security wpa
no shutdown
!
For the IT Devices WLAN/SSID, the DEFAULT_UPSTREAM_CLIENT policy, which remarks all
traffic to Best Effort, is also applied as an upstream client policy.
Dynamic Application of Client-Level Policy

For each of the WLANs/SSIDs, an alternative design is to apply the client-level policy dynamically on
a per-client basis via a Radius attribute-value (AV) pair pushed from ISE during client authorization.
Figure 7-15 shows the configuration of the Employee WLAN/SSID for this.
Figure 7-15
Employee WLAN/SSID Configuration ExampleDynamic Mapping to Client
Catalyst 3850
Switch Stack
QoS Trust
Boundary
CAPWAP
Employee
SSID
AuthZ Policy
AuthZ Profile
Policy
Converged WiFi
Corporate Full and
Converged WiFi
Personal Full
Converged WiFi Full

Access
Cisco:cisco-av-pair= ip:sub-qos-policyin=REMARK_UPSTREAM_CLIENT
Converged WiFi
Personal Partial
Converged WiFi
Partial Access
Converged WiFi
Personal Internet
Converged WiFi
Internet Only
5
294888
Upstream
Client
Policies
!
aaa-override
nac
session-timeout 300
no shutdown
!
On-boarded devices which access the Employee SSID will authenticate against one of the following
authorization policy rules with associated authorization profiles.
Converged WiFi Corporate FullConverged Wifi Full Access
7-34
Chapter 7

Quality of Service
Converged WiFi Personal FullConverged Wifi Full Access
Converged WiFi Personal PartialConverged Wifi Partial Access
Converged WiFi Personal InternetConverged Wifi Partial Access
Since these authorization policy rules and associated authorization profiles are unique to Converged
Access designs within this design guide, the authorization profiles can be modified to add the following
Radius AV pair pushed to the client upon authorization:
cisco:cisco-av-pair=ip:sub-qos-policy-in=REMARK_UPSTREAM_CLIENT
This will dynamically apply the REMARK_UPSTREAM_CLIENT policy to the client upon
authorization to the network. This can similarly be done for the other SSIDs so that the upstream
client-level policy is dynamically applied for all wireless clients regardless of the WLAN/SSID to which
they are connecting.
Note
Client-level policies applied dynamically through AAA Radius attribute-value pairs will override any
existing client-level policies statically assigned to the WLAN/SSID for the particular client.
Consistent naming of upstream client-level policies is necessary in a Converged Access design. QoS
policies are applied at the point-of-attachment (PoA)meaning the Catalyst 3850 Series switch or
CT5760 which controls the access point to which the wireless client is associated. When a wireless client
roams between access points controlled by different Catalyst 3850 Series switches (or CT5760 WLCs
when implementing a hybrid Converged Access design), the point-of-attachment (PoA) of the wireless
client will change. The point-of-attachment (PoA) becomes the current Catalyst 3850 Series switch
which controls the access point to which the wireless client is associated, also known as the foreign
controller. The point-of-presence (PoP) remains the initial Catalyst 3850 Series switch, also known as
the anchor controller. The name of the QoS policy which was pushed down via the Radius AV pair from
ISE and dynamically applied to the wireless client when the client authenticated to the network will be
sent from the original Catalyst 3850 Series switch (initial PoA) to the current Catalyst 3850 Series
switch (current PoA) through the mobility tunnel. This is because the wireless client does not need to
re-authenticate when roaming. If the name of the client-level policy map sent through the mobility tunnel
does not match any policy maps defined on the new Catalyst 3850 Series switch (the foreign controller),
a policy name mismatch occurs, causing the wireless client to be excluded from the foreign controller.
Hence roaming will not function properly unless the names of the client-level policies dynamically
applied to wireless clients are consistent across Converged Access controllers within the deployment.
Note also that when implementing a hybrid Converged Access design, in which CT5760 wireless
controllers also directly support access points, policing within the upstream client-level policy is
currently not supported. Therefore in order to avoid potential roaming issues, it is not recommended to
implement policing in upstream client-level policies which are dynamically applied to wireless clients
in a hybrid Converged Access design, even though the Catalyst 3850 Series switches support it.
Mobility Traffic QoS Policy

Policy 6 in Figure 7-3 through Figure 7-5 indicates the marking of mobility control traffic across the
network infrastructure.
With the older non-hierarchical mobility architecture, UDP port 16666 is used to transport unencrypted
mobility control packets. UDP port 16667 was used to transport IPsec encrypted mobility control
packets, although this protocol is no longer in use as of CUWN 5.x code and higher. Ethernet-over-IP
(IP port 97) is used to tunnel the actual mobility data traffic.
7-35
Chapter 7
With the new (hierarchical) mobility architecture, a CAPWAP header (and hence a CAPWAP tunnel) is
implemented inside UDP port 16666, which is used to transport mobility control packets. The payload
inside the CAPWAP header is also encrypted via DTLS. Hence mobility control packets are encrypted
for security. Mobility data traffic is sent via UDP port 16667. The mobility data traffic is also
encapsulated within a CAPWAP header (and hence a CAPWAP tunnel) inside UDP port 16667. This
replaces the use of Ethernet-over-IP for tunneling mobility data traffic.
Note
Converged Access platforms only support the new (hierarchical) mobility architecture.
For this design guide, mobility control traffic between Catalyst 3850 switches and Cisco 5760 wireless
controllers is configured to be marked with a DSCP value of 48, corresponding to CS6. The following
global configuration command on Catalyst 3860 platforms as well as CT5760 wireless controllers will
cause CAPWAP mobility traffic to be marked as CS6:
!
wireless mobility dscp 48
!
The DSCP marking of wireless mobility data traffic is preserved from the marking the data traffic has as
it traverses the CAPWAP tunnel between the access point and the Catalyst 3850 Series switch. Hence
the QoS marking of wireless client traffic is preserved during client roaming.

Beginning with Cisco Unified Wireless Network (CUWN) software release 7.4, the Application
Visibility and Control set of featuresalready supported on Cisco routing platforms such as ASR 1000s
and ISR G2sbecame available on WLC platforms, including the Cisco 2500, 5500, 7500, 8500 WLCs,
and WiSM2 controllers on Local and FlexConnect Modes (for WLANs configured for central switching
only in 7.4 release).
The AVC feature set increases the efficiency, productivity, and manageability of the wireless network.
Additionally, the support of AVC embedded within the WLAN infrastructure extends Ciscos
application-based QoS solutions end-to-end.
Business use-cases for AVC policies include:
Guaranteeing voice quality from wireless applications meets enterprise VoIP requirements.
Ensuring video applicationsboth interactive and streamingare delivered to/from wireless

devices with a high Quality of Experience, so that users can communicate and collaborate more
efficiently and effectively-regardless of their location or device.
Provisioning preferred services for business-critical applications running on wireless devices, such
as Virtual Desktop applications, sales applications, customer relationship management (CRM)
applications, and enterprise resource planning (ERP) applications, etc.
De-prioritizing background application traffic (i.e., applications that send data to/from servers,
rather than directly to other users and which do not directly impact user-productivity), such as email,
file-transfers, content distribution, backup operations, software updates, etc.
Identifying and de-prioritizing (or dropping) non-business applications, which can include social
networking applications, peer-to-peer file-sharing applications, and type of entertainment and/or
gaming applications so that network resources are always available for business-oriented
applications.
AVC includes these components:
7-36
Chapter 7

Next-generation Deep Packet Inspection (DPI) technology called Network Based Application
Recognition (NBAR2), which allows for identification and classification of applications. NBAR is
a deep-packet inspection technology available on Cisco IOS based platforms, which includes
support of stateful L4-L7 classification.
QoSAbility to remark applications using DiffServ, which can then be leveraged to prioritize or
de-prioritize applications over both the wired and wireless networks.
A template for Cisco NetFlow v9 to select and export data of interest to Cisco Prime or a third-party
NetFlow collector to collect, analyze, and save reports for troubleshooting, capacity planning, and
compliance purposes.
These AVC components are shown in Figure 7-16.

Cisco AVC Components
Inspect Packet
Platinum
Gold
Traffic
Silver
Bronze
NBAR LIBRARY
Deep Packet Inspection
POLICY
Packet Mark and Drop
NetFlow
Key Fields
Source IP address
Destination IP address
Source Port
Destination port
Layer 3 protocol
TOS byte (DSCP)
Input Interface
NetFlow Cache
Flow Information
Packets
Bytes/packets
Address, ports...
...
11000
1528
Create a Flow from the Packet Attributes
NETFLOW (STATIC TEMPLATE)

provides Flow Export
294011
Figure 7-16
AVC on the WLC inherits NBAR2 from Cisco IOS that provides deep packet inspection technology to
classify stateful L4-L7 application classification. This is critical technology for application
management, as it is no longer a straightforward matter of configuring an access list based on the TCP
or UDP port number(s) to positively identify an application. In fact, as applications have
maturedparticularly over the past decadean ever increasing number of applications have become
opaque to such identification. For example, HTTP protocol (TCP port 80) can carry thousands of
potential applications within it and in todays networks seems to function more as a transport protocol
rather than as the OSI application-layer protocol that it was originally designed as. Therefore to identify
applications accurately, Deep Packet Inspection technologiessuch as NBAR2are critical.
Once applications are recognized by the NBAR engine by their discrete protocol signatures, it registers
this information in a Common Flow Table so that other WLC features can leverage this classification
result. Such features include Quality of Service (QoS), NetFlow, and firewall features, all of which can
take action based on this detailed classification.
Thus AVC provides:
Application Visibility on the Cisco WLC by enabling Application Visibility for any WLAN
configured. Once Application Visibility is turned on, the NBAR engine classifies applications on
that particular WLAN. Application Visibility on the WLC can be viewed at an overall network level,
per WLAN, or per client. An example of a per-client application visibility report is illustrated in
Figure 7-17.
Application Control on the Cisco WLC by creating an AVC profile (or policy) and attaching it to a
WLAN. The AVC Profile supports QoS rules per application and provides the following actions to
be taken on each classified application: Mark (with DSCP), Permit (and transmit unchanged), or
Drop. An example of an AVC profile is shown in Figure 7-18, Figure 7-19, and Figure 7-20.
7-37
Chapter 7
A client-based AVC reportsuch as shown in Figure 7-17can show the top applications by device.
AVC reports can also be compiled by WLAN or at the overall network level.
Figure 7-17
Cisco AVC Application Visibility Reports
An AVC profilea collection of individual application policy rulescan be configured via the WLC
GUI or CLI. In Figure 7-18 an AVC application rule is being configured for voice traffic sourced-from
or destined-to Cisco wireless devices. This traffic is identified via an NBAR2 signature named
cisco-phone and is marked as DSCP 46 (EF) and assigned to the Platinum Wireless Multi-Media
(WMM) access-category for the highest level of service over the air.
7-38
Chapter 7

Figure 7-18
Cisco AVC Profile Example 1Creating an AVC Policy Rule
An AVC profile can contain up to 32 individual application rules, as is shown in Figure 7-19, containing
recommended policies for the following classes of application traffic (as based on RFC 4594):
Voice
Video
Multimedia Conferencing
Multimedia Streaming
Transactional Data
Bulk Data
Scavenger applications
7-39
Chapter 7
Figure 7-19
Cisco AVC Profile Example 2Displaying a Comprehensive AVC Policy
Once an AVC profile has been assembled, it can be applied to a WLAN(s), as shown in Figure 7-20. AVC
policies are applied bi-directionallythat is, in the upstream and downstream directions simultaneously.
7-40
Chapter 7

Figure 7-20
Cisco AVC Profile Example 3Applying an AVC Profile to a WLAN
AVC supports over 1000 applications in its initial release for WLCs. Some of these applications-grouped
by business case-are:
To ensure voice quality for wireless devices, the cisco-phone application would typically be assigned to
the Platinum (Voice) WMM access category via AVC. However, additional VoIP applications may
include:
aol-messenger-audio
audio-over-http
fring-voip
gtalk-voip
yahoo-voip-messenger
yahoo-voip-over-sip
Similarly, to protect video and multimedia applications, the following applications might be assigned to
the Gold (Video) WMM access-category via AVC:
cisco-ip-camera
telepresence-media
webex-meeting
ms-lync-media
aol-messenger-video
fring-video
gtalk-video
livemeeting
msn-messenger-video
rhapsody
7-41
Chapter 7
Note
skype
video-over-http
It may be that some of these video conferencing applications may be considered non-business in nature
(such as Skype and gtalk-video), in which case these may be provisioned into the Bronze (Background)
WMM access category.
To deploy AVC policies to protect the signaling protocols relating to these voice and video applications,
the following applications might be marked to the Call-Signaling marking of CS3 (DSCP 24) via AVC:
sip
sip-tls
skinny
telepresence-control
h323
rtcp
To deploy policies to protect business-critical applications, the following applications might be marked
AF21 (DSCP 18) via AVC:
citrix
ms-lync
ms-dynamics-crm-online
salesforce
sap
oraclenames
perforce
phonebook
semantix
synergy
On the other hand, some business applications would be best serviced in the background by assigning
these to the Bronze (Background) WMM access category via AVC:
ftp/ftp-data/ftps-data
cifs
exchange
notes
smtp
imap/secure imap
pop3/secure pop3
gmail
hotmail
yahoo-mail
7-42
Chapter 7

Cisco Jabber
And finally, many non-business applications can be controlled by either being assigned to the Bronze
(Background) WMM access category or dropped via AVC policies:
Note
youtube
netflix
facebook
twitter
bittorrent
hulu
itunes
picasa
call-of-duty
doom
directplay8
It is important to note that these are only example applications and do not represent an exhaustive list of
applications by class. With over a thousand applications to choose from, these lists are simplified for the
sake of brevity and serve only to illustrate AVC policy options and concepts.
For comprehensive design guidance on using the AVC feature for WLCs, see: Chapter 24, Mobile
Traffic Engineering with Application Visibility and Control (AVC).
Cisco Jabber
Ciscos Jabber clients are unified communications (UC) applications that are available for Android and
Apple mobile devices as well as Microsoft Windows and Apple Mac computers. These client
applications provide instant messaging (IM), presence, voice, video, and visual voicemail features.
These features require that the employee-owned device is allowed to establish call signaling flows
between the device itself and the corporate Cisco Unified Communications Manager (Unified CM)
server, typically deployed within the campus data center. Note that the Basic Access use case discussed
above terminates employee-owned devices on a DMZ segment off of the Internet Edge firewall. Cisco
Jabber requires only Internet access to access WebEx cloud-based services like IM, meetings, and
point-to-point voice and video calls. However, to deliver these same services with on-premise corporate
assets such as Unified CM and other back-end UC applications, connectivity through the firewall is
required for Jabber features to function. In addition to signaling, media flows also need to be allowed
between the Jabber client and other IP voice and video endpoints, such as corporate IP phones deployed
throughout the corporate network. This requires the network administrator to allow a range of addresses
and ports inbound from the DMZ segment through the Internet Edge firewall. Given these connectivity
considerations for real time communications and collaboration, the network administrator may instead
decide to implement the Enhanced Access use case discussed above. With this BYOD model, the
employee-owned devices are on-boarded (registered with the Cisco ISE server and provisioned with
digital certificates) and terminated on the inside of the corporate network. This requires no modifications
to the Internet Edge firewall, and potentially fewer security concerns.
7-43
Chapter 7
Cisco Jabber
Cisco Jabber Clients and the Cisco BYOD Infrastructure

Cisco Jabber, a Cisco mobile client application, provides core Unified Communications and
collaboration capabilities, including voice, video, and instant messaging to users of mobile devices such
as Android and Apple iOS smartphones and tablets. When a Cisco Jabber client device is attached to the
corporate wireless LAN, the client can be deployed within the Cisco Bring Your Own Device (BYOD)
infrastructure.
Because Cisco Jabber clients rely on enterprise wireless LAN connectivity or remote secure attachment
through VPN, they can be deployed within the Cisco Unified Access network and can utilize the
identification, security, and policy features and functions delivered by the BYOD infrastructure.
The Cisco BYOD infrastructure provides a range of access use cases or scenarios to address various
device ownership and access requirements. The following high-level access use case models should be
considered:
Enhanced AccessThis comprehensive use case provides network access for corporate, personal,
and contractor/partner devices. It allows a business to build a policy that enables granular role-based
application access and extends the security framework on and off-premises.
Advanced Access This use case introduces MDM integration with Enhanced Access.
Limited AccessEnables access exclusively to corporate issued devices.
Basic AccessThis use case is an extension of traditional wireless guest access. It represents an
alternative where the business policy is to not on-board/register employee wireless personal devices,
but still provides Internet-only or partial access to the network.
Use Case Impact on Jabber

The Enhanced use case allows the simplest path for implementing a Cisco Jabber solution. Cisco Jabber
clients, whether running on corporate or personal devices, require access to numerous back-end,
on-premise enterprise application components for full functionality. The Enhanced Access use case will
allow access from corporate devices with the option of allowing access from personal devices for Jabber
back-end applications.
The Limited Access use case will allow Jabber use only from corporate devices.
Basic Access adds a significant layer of complexity for personal devices, requiring them to have access
to back-end on-premise Jabber applications from the DMZ. Various signal, control, and media paths
must be allowed through the firewall for full functionality.
In the case of cloud-based collaboration services, Cisco mobile clients and devices connect directly to
the cloud through the Internet without the need for VPN or full enterprise network attachment. In these
scenarios, user and mobile devices can be deployed using the Basic Access model because these use
cases require only Internet access.
Other Jabber Design Considerations

When deploying Cisco Jabber clients within the Cisco BYOD infrastructure, consider the following
high-level design and deployment guidelines:
7-44
Chapter 7

The network administrator should strongly consider allowing voice- and video-capable clients to
attach to the enterprise network in the background (after initial provisioning), without user
intervention, to ensure maximum use of the enterprises telephony infrastructure. Specifically, use of
certificate-based identity and authentication helps facilitate an excellent user experience by
minimizing network connection and authentication delay.
In scenarios where Cisco Jabber clients are able to connect remotely to the enterprise network
through a secure VPN:
The network administrator should weigh the corporate security policy against the need for
seamless secure connectivity without user intervention to maximize utilization of the enterprise
telephony infrastructure. The use of certificate-based authentication and enforcement of a
device PIN lock policy provides seamless attachment without user intervention and
functionality similar to two-factor authentication because the end user must possess the device
and know the PIN lock to access the network. If two-factor authentication is mandated, then user
intervention will be required in order for the device to attach remotely to the enterprise.
It is important for the infrastructure firewall configuration to allow all required client
application network traffic to access the enterprise network. Failure to open access to
appropriate ports and protocols at the corporate firewall could result in an inability of Cisco
Jabber clients to register to on-premises Cisco call control for voice and video telephony
services and/or the loss of other client features such as enterprise directory access or enterprise
visual voicemail.
When enterprise collaboration applications such as Cisco Jabber are installed on employee-owned
mobile devices, if the enterprise security policy requires the device to be wiped or reset to factory
default settings under certain conditions, device owners should be made aware of the policy and
encouraged to backup personal data from their device regularly.
When deploying Cisco Jabber, it is important for the underlying network infrastructure to support,
end-to-end , the necessary QoS classes of service, including priority queuing for voice media and
dedicated video and signaling bandwidth, to ensure the quality of client application voice and video
calls and appropriate behavior of all features.
For further information regarding Cisco Jabber clients, see the product collateral and documentation at:
http://www.cisco.com/go/jabber.
For further information regarding Cisco Mobile Unified Communications, see the Cisco Unified
Communications System 9.X SRND at:
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/9x/mobilapp.html.

Cisco ISE comes with several license options, such as Evaluation, Base, Advanced, and Wireless. For
this design to be implemented, ISE requires the Advanced license option. To obtain more information
on licensing, see:
http://www.cisco.com/en/US/products/ps11640/tsd_products_support_series_home.html.
7-45
Chapter 7
7-46
PART
CH AP TE R

This part of the CVD section discusses the different infrastructure components that are critical to the
deployment of the BYOD design and the configuration steps used for this design guide.
critical to a successful BYOD deployment
The following components and the configuration steps are discussed to support different BYOD use
cases:
Wireless Controllers (Unified and Converged Access)
Access Layer Switches
Identity Service Engine
Certification Authority (CA) server
Integration with Mobile Device Managers
BYOD Wireless Infrastructure DesignThis section presents different network designs used to
support BYOD, including Campus and Branch designs. This section presents both Unified Wireless
and Converged Access designs with single or dual SSID configurations.
Identity Services Engine for BYODThe Cisco Identity Services Engine plays a critical role in
enabling the BYOD model and allows for enforcement of centrally-configured policies across wired
and wireless networks. The section focuses on digital certificates, authentication and authorization
policies, device profiling, and different ways to on-board devices with either single or dual SSID
configurations.
BYOD Wired Infrastructure DesignThis section highlights how to on-board wired devices and
how to enforce BYOD policies and network access for wired devices. This section has details for
both campus and branch deployments.
Security Group Access for BYODThis section presents two different deployment scenarios that
rely on Security Group Tags to enforce BYOD policies. These scenarios are not mutually exclusive
and may be used together to implement different business use cases.
8-1
Chapter 8
Mobile Device Manager Integration for BYODThis section focuses on how to configure ISE to
integrate with third party MDM products through an XML-based API. BYOD Advanced Use
CaseMobile Device Manager Integration expands this configuration to receive device posture
information from the MDM.
8-2
CH AP TE R

The Cisco Wireless LAN Controller (WLC) is used to automate wireless configuration and management
functions and to provide visibility and control of the wireless networks. The WLC is able to interact with
the Identity Service Engine to enforce authentication and authorization policies across endpoints.
While designing WLAN networks, the following should be considered:
The role of the WLAN
The authentication mechanism for the WLAN
The number of WLANs present in a network
This design guide logically separates the WLAN into distinct logical functions: device provisioning and
secure network access. These two functions can be provided by two different WLANs or combined into
a single WLAN. This design guide covers both single and dual SSID deployment models for both the
branch and the campus locations. Note that in this design guide wireless guest access is implemented on
a different WLAN.
Some considerations when selecting a single versus dual SSID configuration:
Some organizations prefer having a dedicated SSID for on-boarding devices.
Others see dual SSID as an extra management burden.
A second SSID adds channel overhead.
Enabling too many SSIDs may degrade wireless performance.
The organizations unique requirements and preferences will dictate which model to deploy. The
configurations of both the ISE and WLC may be easily modified to support either single or dual SSID
deployments.
CampusUnified Wireless LAN Design

As mentioned in Centralized (Local Mode) Wireless Design in Chapter 5, Campus and Branch Network
Design for BYOD, the two wireless LAN designs for the campus which are discussed within this design
guide are Centralized (Local Mode) and Converged Access designs. Clients connecting from the campus
wireless infrastructure are served by a dedicated cluster of CT5508 Unified Controllers configured in
local mode (central switching) or served by a combination of Catalyst 3850 series switches which
provide the Mobility Agent (MA) function, while CT5760 wireless controllers provide the Mobility
9-1
Chapter 9
Controller function. This section discusses the Unified Wireless LAN Design, while discussion on
Converged Access follows. The wireless controllers are configured with the proper SSIDs to provide
device on-boarding and secure access. This functionality may be provided via single or dual SSIDs.
Note
The CT5760 wireless controller can also be configured to function as a centralized (Local Mode)
wireless controller. As discussed in Campus Migration Path of Chapter 5, Campus and Branch Network
Design for BYOD, this may be a necessary step in migrating from an existing wireless overlay design
to a converged access design.
Centralized CampusDual SSID Design

In this design there are two SSIDs: one provides enrollment/provisioning and the other provides secure
network access. After connecting to the BYOD_Provisioning SSID and completing the enrollment and
provisioning steps, the user connects to the BYOD_Employee SSID, which provides network access
over a secure EAP-TLS connection.
Figure 9-1 shows the dual SSID design for the campus APs.
Figure 9-1
Campus-Dual SSIDs
Data Center
Campus
Step 1: On-boarding
ISE
BYOD_Provisioning
SSID
CAPWAP
CAPWAP
BYOD_Employee
SSID
Full
Partial
Internet
AD
CA
294076
CT5508 WLC
In a dual SSID design, there are some additional considerations:
The provisioning SSID can be either open or password protected. When the provisioning SSID is
open, any user can connect to the SSID, whereas if it is password protected, then only users that have
credentials, such as AD group membership, are allowed to connect to the SSID. In this design guide,
the provisioning SSID is configured to be open and its only purpose is to provide on-boarding
services.
After the device is provisioned, it is assumed that the user will switch to the second SSID for regular
network access. To prevent the user from staying connected to the provisioning SSID, an access list
that provides only access to ISE, DHCP, and DNS must be enforced on the provisioning SSID. The
details of the ACL_Provisioning_Redirect ACL are shown below.
This design guide makes use of the following SSIDs: BYOD_Provisioning and BYOD_Employee.
The properties of these two SSIDs are highlighted in Table 9-1.
9-2
Chapter 9

Table 9-1
WLAN Parameters
Attribute
BYOD_Provisioning
BYOD_Employee
Description
Used only for device

provisioning
For employees that have completed the

on-boarding process
Layer 2 Security
None (for Open SSID)
WPA+WPA2
MAC Filtering
Enabled (for Open SSID) Disabled
WPA+WPA2 Parameters None
WPA2 Policy, AES, 802.1X
Layer 3 Security
None
None
AAA Server
Select ISE
Select ISE
Advanced
AAA Override Enabled
Advanced
NAC State-RADIUS NAC NAC State-RADIUS NAC
Quality of Service
Best Effort
Platinum
AVC
None
Enabled
To create a WLAN, click WLANs > Create New > Go and provide the SSID and profile details. Starting
with Figure 9-2 the general configuration steps of the BYOD_Provisioning SSID are highlighted. The
steps to configure the BYOD_Employee WLAN are similar, following the settings in Table 9-1.
Note
When implementing BYOD solutions using more than one Wireless LAN Controller, WLAN IDs must
be kept consistent. WLAN ID is used by ISE in determining which WLAN (SSID) clients are using to
connect to the network. Ensuring each WLAN has the same WLAN ID on each WLC is essential for
proper operation and security.
9-3
Chapter 9
Figure 9-2
Creating the BYOD_Provisioning SSID
The Layer 2 security settings are configured as None since BYOD_PROVISIONING is an open SSID.
If the provisioning SSID has to be password-protected, then the Layer 2 security settings must be
configured as WPA+WPA2 Enterprise.
Figure 9-3
Layer 2 Security Settings
The Layer 3 Security is configured as None, as shown in Figure 9-4.
9-4
Chapter 9

Figure 9-4
The main configuration in the security settings is to specify the RADIUS server configuration details.
Figure 9-5 shows how the ISE's IP address is configured for Authentication and Authorization.
Figure 9-5
AAA Security Settings
Figure 9-6 shows the advanced settings, including AAA Override and NAC State.
9-5
Chapter 9
Figure 9-6
Advanced Settings
The Fast SSID Change feature is useful when a device needs to switch from one SSID to another. This
applies to the dual SSID BYOD design. After the user completes registration with BYOD_Provisioning,
the user is switched to BYOD_Employee SSID. By enabling the FAST SSID Change feature, the user
switches immediately to the new SSID without experiencing delays. To enable Fast SSID Change, click
Controller > General > Fast SSID change, as shown in Figure 9-7.
9-6
Chapter 9

Figure 9-7
Fast SSID Change
In the centralized campus model, ACLs are used to restrict access to network resources and ensure
devices are redirected to the guest portal to complete the on-boarding process.
The ACL_Provisioning_Redirect ACL, shown in Figure 9-8, is used for redirecting the client to the guest
portal (for completing the provisioning process) and to restrict access to ISE and basic services only.
9-7
Chapter 9
Figure 9-8
Note
WLC Access List for Provisioning
This ACL and the on-boarding process are explained in more detail in Authorization Policies and
Profiles in Chapter 10, Identity Services Engine for BYOD.
Centralized CampusSingle SSID Design

In a single SSID design the same WLAN (BYOD_Employee) is used for on-boarding and secure network
access. Figure 9-9 shows how this design may be implemented using the 5508 Wireless LAN Controller.
In this case, the controllers are dedicated to manage the APs in the campus.
Figure 9-9
CampusSingle SSID
Data Center
Campus
Step 1: On-boarding
ISE
BYOD_Employee
SSID
CAPWAP
CAPWAP
Full
Partial
Internet
Note
CA
Authorization Policies and Profiles in Chapter 10, Identity Services Engine for BYOD shows the
ACLs and authorization profiles used for dual and single SSID provisioning.
9-8
AD
294083
CT5508 WLC
Chapter 9

BranchUnified Wireless LAN Design
Centralized CampusPolicy Enforcement using TrustSec

As discussed in ACL Complexity and Considerations in Chapter 5, Campus and Branch Network
Design for BYOD, past versions of the CVD utilized Named ACLs pre-configured on the wireless
controllers to enforce role-based policies for access to network and Data Center resources. This CVD
introduces a complimentary technology known as TrustSec and, more specifically, Security Group
Access (SGA) to enforce role-based policies through the use of Security Group Tags (SGT) to control
access to data center resources. This CVD discusses an approach to slowly migrate to the use of SGT as
opposed to, or even in addition to, the use of ACLs through Network Device definitions created in ISE.

FlexConnect Wireless LAN Design
In this design guide, endpoints connecting from branch locations are managed by a cluster of Flex 7500
Wireless LAN Controllers or Virtual Wireless LAN Controllers (vWLCs). The vWLC is software which
can run on industry standard virtualization infrastructure and is more suitable for small- and
medium-sized businesses.
The configuration parameters described in this section apply to both the vWLC and Flex 7500
controllers.
The following link provides more information on how to set up vWLCs using VMware:
http://www.cisco.com/en/US/customer/products/ps12723/products_tech_note09186a0080bd2d04.shtm
l.
FlexConnect (previously known as Hybrid Remote Edge Access Point or H-REAP) is a wireless solution
for branch office and remote office deployments. It enables customers to configure and control access
points in a branch or remote office from the corporate office through a wide area network (WAN) link
without deploying a controller in each office. The FlexConnect access points can switch client data
traffic locally and perform client authentication locally when their connection to the controller is lost.
Distributing client data traffic using the FlexConnect architecture offers some advantages:
A controller is not required at each branch location.
Mobility resiliency within branch during WAN link failures.
Central management and troubleshooting.
The FlexConnect architecture in Figure 9-10 shows different traffic flows originating at the branch.
9-9
Chapter 9
Figure 9-10
FlexConnect Architecture
Internet
Data Center
Branch
ISE
CAPWAP
CAPWAP
WAN
AD
CA
Control Channel/Authentication
Data Center Traffic
User Data Traffic
294084
Flex 7500
When an endpoint associates to a FlexConnect access point, the access point sends all authentication
messages to the controller and either switches the data packets locally (locally switched) or sends them
to the controller (centrally switched), depending on the WLAN configuration.
With respect to data packet flows, the WLAN can be in any one of the following modes:
Central switchingCentral switched WLANs tunnel both the wireless user traffic and all control
traffic to the centralized WLC, where the user traffic is mapped to a dynamic interface or VLAN.
Local switchingIn this mode the FlexConnect access point switches data packets locally by
dropping all traffic locally at the wired interface. Wireless user traffic is mapped to discrete VLANs
via 802.1Q trunking.
The Flex 7500 Wireless Branch Controller Deployment Guide offers more details:
http://www.cisco.com/en/US/products/ps11635/products_tech_note09186a0080b7f141.shtml.
The key strategy for providing differentiated access to users is done by assigning users to different
VLANs dynamically. The AAA Override feature for FlexConnect assigns individual clients to specific
VLANs, based on the returned RADIUS attributes from the ISE.
The access point must be preconfigured with all of the possible VLANs that can be returned by the ISE
server. The VLAN assignment returned by the ISE as part of authorization is applied. If the VLAN that
was returned from the ISE is not present on the AP, the client falls back to the default VLAN configured
for the WLAN.
In this design three VLANs have been configured for wireless connectivity on the BYOD_Employee
SSID. Table 9-2 illustrates those VLANs and their purpose.
Table 9-2
VLANs and Purpose
VLAN Number VLAN Name
Description
10
Wireless_Full
Users assigned to this VLAN get full access to campus and branch
servers.
11
Wireless_Partial
In addition to Internet access, users assigned to this VLAN access

to additional campus and branch resources.
9-10
Chapter 9

Table 9-2
VLANs and Purpose
VLAN Number VLAN Name
Description
12
Wireless_Internet Users assigned to this VLAN get only Internet access.
18
AP_Mgmt_Flex
This is the native VLAN that the user will initially be placed into,
until the authorization policy determines the appropriate VLAN.
Since more than one VLAN is configured for local switching, FlexConnect APs at the branch must be
connected to an 802.1Q trunk link. Both the AP and the upstream switchport need to be configured for
802.1Q trunking. Figure 9-11 shows an example configuration of the access layer switch that connects
to the FlexConnect AP.
Figure 9-11
Trunk Configuration
Internet
Branch
802.1Q Trunk
WAN
description to Branch #1 AP
switchport trunk encapsulation dot1q
switchport trunk native vlan 18
switchport trunk allowed vlan 10-18
spanning-tree portfast trunk
294085
CAPWAP
CAPWAP
Branch Wireless IP Address Design

Once the device has been dynamically assigned to a VLAN, the endpoint must obtain an IP address from
a DHCP server. In the following example the branch routers Layer 3 subinterfaces are configured with
the ip-helper address command, pointing to a DHCP server:
interface GigabitEthernet0/1
description Trunk to branch bn22-3750x-1
no ip address
media-type sfp
!
interface GigabitEthernet0/1.10
encapsulation dot1Q 10
ip address 10.200.10.2 255.255.255.0
standby 10 ip 10.200.10.1
standby 10 priority 110
standby 10 preempt
!
9-11
Chapter 9
ip address 10.200.11.2 255.255.255.0
standby 11 ip 10.200.11.1
standby 11 preempt
!
ip address 10.200.12.2 255.255.255.0
standby 12 ip 10.200.12.1
standby 12 preempt
The diagram in Figure 9-12 shows two branch locations utilizing resources from the data center and
illustrates the following key points:
At the branch, endpoints are placed in different VLANs based on the level of access to which they
are entitled.
The wireless infrastructure from the branches is managed by a single cluster of Flex 7500
controllers.
Endpoints that get assigned to VLAN 10 are granted full access to network resources, VLAN 11 for
partial access and VLAN 12 for Internet access.
Based on the matching authorization profile, a user is assigned to a specific VLAN where predefined
permissions have been defined.
9-12
Chapter 9

Figure 9-12
Branch 1
VLANs Used at the Branches

Permission
Full Access
Partial Access
Internet_Only
Wireless
VLAN10
VLAN11
VLAN12
Local Resources
Native
VLAN16
VLAN18
CAPWAP
CAPWAP
Data Center
ISE
WAN
Branch 2
Permission
Full Access
Partial Access
Internet_Only
Wireless
VLAN10
VLAN11
VLAN12
Local Resources
Native
VLAN16
VLAN18
Flex 7500
AD
CA
294086
CAPWAP
CAPWAP
FlexConnect BranchDual SSID Design

In the Dual SSID design two SSIDs are configured: one SSID provides enrollment/provisioning while
the other provides secure EAP-TLS access. After connecting to the BYOD_Provisioning SSID and
completing the enrollment and provisioning steps, the user connects to the BYOD_Employee SSID,
which provides secure network access.
Figure 9-13 shows the dual SSID design for the branch APs.
9-13
Chapter 9
Figure 9-13
Branch-Dual SSIDs
Data Center
Branch
Step 1: On-boarding
FlexConnect
Group
BYOD_Provisioning
SSID
ISE
CAPWAP
CAPWAP
WAN

Flex 7500
AD
Full
Partial
Internet
CA
294087
BYOD_Employee
SSID
In a dual SSID design, there are some additional considerations:
The provisioning SSID can be either open or password-protected. When the provisioning SSID is
credentials, such as AD group membership, are allowed to connect to the SSID.
After the device is provisioned, the user connects via EAP-TLS to the BYOD_Employee SSID for
network access. To prevent the user from remaining connected to the provisioning SSID, an access
list that provides access only to ISE, DHCP, and DNS must be enforced on the provisioning SSID.
The details of this SSID are discussed in the Client Provisioning section.
Table 9-3 shows the WLAN parameters for the SSIDs used in this design guide.
Table 9-3
WLAN Parameters
Attribute
BYOD_Provisioning
BYOD_Employee
Description
Used for device provisioning
For employees that have

completed the on-boarding
process
Layer 2 Security
WPA+WPA2
MAC Filtering
Enabled (for Open SSID)
Disabled
WPA+WPA2 Parameters
Layer 3 Security
None
None
AAA Server
Select ISE
Select ISE
Advanced
Advanced
NAC State-RADIUS NAC
NAC State-RADIUS NAC
Advanced-FlexConnect Local
Switching
Disabled for Central Switching

Provisioning
Enabled
Enabled for Local Switching

Provisioning
9-14
Chapter 9

Table 9-3
WLAN Parameters
Attribute
BYOD_Provisioning
BYOD_Employee
Quality of Service
Best Effort
Platinum
AVC
Does Not Apply
Does Not Apply
To create a WLAN, click WLANs > Create New > Go and provide the SSID and profile details.
Figure 9-14 shows the general configuration details of the BYOD_Provisioning SSID.
Figure 9-14
Creating the Branch BYOD_Provisioning SSID
Since BYOD_Provisioning is an open SSID, the Layer 2 security settings in are configured as None. If
the provisioning SSID had to be password-protected, the Layer 2 security settings would be configured
as WPA+WPA2 Enterprise.
9-15
Chapter 9
Figure 9-15
The Layer 3 Security is configured as None, as shown in Figure 9-16.

Figure 9-16
Under Security > AAA servers, configure the RADIUS server details. Figure 9-17 shows the ISEs IP
address configured for Authentication and Authorization.
9-16
Chapter 9

Figure 9-17
AAA Security Settings
Within the dual SSID deployment there are two possible ways to direct provisioning traffic:
From the campus or data centerThe endpoint receives an IP address from a DHCP scope at the
data center and the provisioning traffic is directed through the CAPWAP tunnel between the branch
and the Flex 7500 controller.
At the branchThe endpoint receives an IP address from a DHCP scope at the branch and the
provisioning traffic uses the switching and WAN infrastructure for connectivity to data center
resources.
Dual SSIDCentral Switching Provisioning

Figure 9-18 shows how with central switching provisioning, the endpoint communicates with ISE and
data center resources using the CAPWAP tunnel and all traffic is tunneled back to the controller in the
data center.
9-17
Chapter 9
Figure 9-18
Central Switching Provisioning
Branch
Data Center
Step 1: On-boarding
ISE
BYOD_Provisioning
SSID
CAPWAP
CAPWAP
WAN
CAPWAP
Tunnel
Flex 7500
BYOD_Employee
SSID
CA
User Data Traffic
Figure 9-19 shows the advanced settings for BYOD_Provisioning, including the AAA Override and
NAC State. The FlexConnect Local Switching setting is disabled for central switching provisioning.
9-18
294092
AD
Chapter 9

Figure 9-19
Note
Advanced Settings for Central Switching Provisioning
Authorization Policies and Profiles in Chapter 10, Identity Services Engine for BYOD shows the
ACLs and authorization profiles used for dual and single SSID provisioning.
Dual SSIDLocal Switching Provisioning

Figure 9-20 shows provisioning with local switching mode. The user data traffic is sent to the switch
interface and the endpoint relies on the normal router/WAN infrastructure to reach the ISE and other
network resources.
9-19
Chapter 9
Figure 9-20
Local Switching Provisioning
Branch
Data Center
Step 1: On-boarding
ISE
BYOD_Provisioning
SSID
CAPWAP
CAPWAP
WAN
CAPWAP
Tunnel
Flex 7500
BYOD_Employee
SSID
CA
User Data Traffic
Figure 9-21 shows the advanced settings for BYOD_Provisioning, including the AAA Override and
NAC State. The FlexConnect Local Switching is enabled for local switching provisioning.
9-20
294094
AD
Chapter 9

Figure 9-21
Advanced Settings for Local Switching Provisioning
To enforce the redirection to the self-registration portal, a FlexConnect ACL is defined under the Policies
tab for the specific FlexConnect group, as shown in Figure 9-22.
9-21
Chapter 9
Figure 9-22
Policies for FlexConnect Group
The ACL_Provisioning_Redirect FlexConnect ACL shown in Figure 9-23 allows access to ISE, DNS,
the Google Play Store, and denies all other traffic. Android devices require access to the Google Play
Store to download the SPW package.
Figure 9-23
ACL_Provisioning_Redirect FlexConnect ACL
The ACL_Provisioning_Redirect ACL specifies the following access:
Allow IP access to and from the DNS server (10.230.1.45).
Allow IP access to and from the ISE Server (10.225.49.15).
Allow IP access to and from the DHCP server (10.230.1.61).
Access to Google Play.
9-22
Chapter 9

Note
The purpose of the ACL shown above is to provide an example that network administrators can use to
deploy in the network. The Google and Apple app stores may change their addresses, so it is advisable
to validate those addresses before deploying the ACL.
Note
ACL_Provisioning_Redirect must redirect all traffic sent to enroll.cisco.com. The Cisco Configuration
Assistant for Android devices requires this redirect to discover the IP address of the ISE server.
FlexConnect BranchSingle SSID Design

In a single SSID design, the same WLAN is used for certificate enrollment, provisioning (on-boarding
process), and secure network access. There are some considerations that should be taken into
consideration while deploying a Single SSID solution:
1.
Since the authentication method is PEAP, the user is expected to enter the AD credentials before the
registration process can begin. In the PEAP protocol, the server presents its identity certificate to
the end user. In this design, ISE presents its identity certificate to the endpoint. Some endpoints may
reject the certificate if the root certificate is not present in their list of trusted providers. During the
registration process, the root CA certificate is installed on the endpoint, but this can't be done if the
initial dialog itself fails. Hence, this presents a chicken-and-egg problem. To prevent this from
happening the ISE identity certificate must be signed by a third-party trusted provider such as
VeriSign.
2.
If the above cannot be done, then it is better to deploy dual SSID design.
Figure 9-24 shows how this design uses the BYOD_Employee SSID and is implemented using the Flex
7500 Controller cluster, which is dedicated to manage the APs in the branch locations.
Figure 9-24
Branch-Single SSID
Data Center
Branch
Step 1: On-boarding
FlexConnect
Group
BYOD_Employee
SSID
CAPWAP
CAPWAP
ISE
WAN
Flex 7500
AD
CA
294098
Full
Partial
Internet
In this scenario the APs associate with the Flex 7500 controller and the FlexConnect capabilities allow
the on-boarding and secure access capabilities to be handled by the single BYOD_Employee SSID.
9-23
Chapter 9
The steps to configure the BYOD_Employee WLAN are similar, following the parameters outlined in
Table 9-3. It is important to note that FlexConnect Local Switching is enabled on the BYOD_Employee
WLAN, as highlighted in Figure 9-25.
Figure 9-25
FlexConnect Local Switching
To enforce the redirection to the self-registration portal, a FlexConnect ACL is defined under the Policies
tab, as shown in Figure 9-26.
9-24
Chapter 9

Figure 9-26
Policies for FlexConnect Group
The ACL_Provisioning_Redirect ACL is shown in Figure 9-23 above.
FlexConnect Access Point Configuration

Configure the access point in FlexConnect mode by changing the AP Mode to FlexConnect. Click
Wireless > Access Points and select the proper branch AP. Figure 9-27 shows the setting for an access
point in Branch1.
Figure 9-27
FlexConnect AP Mode
Click the FlexConnect tab and specify the Native VLAN for the branch, as shown in Figure 9-28. The
access point relies on the native VLAN for IP connectivity.
9-25
Chapter 9
Figure 9-28
Native VLAN ID
Define the VLAN ID to be used for local switching. In Figure 9-29, clients obtain an IP address from
VLAN 12 (Internet access) when doing local switching. When using the AAA Overrides for
FlexConnect feature, the client is moved to a different VLAN dynamically, based on the matched
authorization profile and will obtain an IP address from the defined VLAN.
This setting can be configured at the AP level or the AP can inherit the settings from the FlexConnect
Group. FlexConnect Groups are explained in the next section.
9-26
Chapter 9

Figure 9-29
BYOD_Employee VLAN ID
FlexConnect Groups
FlexConnect groups provide a convenient way to group access points that share the same configuration
settings. This is particularly helpful when grouping several FlexConnect access points in remote or
branch locations. Instead of configuring each access point separately, FlexConnect groups allow the
configuration parameters to be applied to all access points at once. For example, a FlexConnect ACL can
be applied to a particular VLAN across all access points within a branch simply by adding the access
points to the same FlexConnect group.
For the purpose of this guide, a unique FlexConnect group was defined for each branch, as shown in
Figure 9-30.
9-27
Chapter 9
Figure 9-30
FlexConnect Groups
Figure 9-31 shows the access points that have been added to the Branch1 FlexConnect group.
Figure 9-31
Branch1 FlexConnect Group
The VLAN ID used for local switching can be defined at the AP level,as shown in Figure 9-29, or at the
FlexConnect Group level, as shown in Figure 9-32. In this example, clients will obtain an IP address
from VLAN 12 (Internet access) when doing local switching. When using the AAA Overrides for
FlexConnect feature, the client is moved to a different VLAN dynamically based on the matched
authorization profile and will obtain an IP address from the defined VLAN.
9-28
Chapter 9

Figure 9-32
Local Switching VLANFlexConnect Group Level
Before ISE can enforce an authorization policy, FlexConnect ACLs must be defined and assigned to each
VLAN. By clicking the AAA VLAN-ACL mapping tab, the FlexConnect ACL may be enforced for each
VLAN ID. This assumes that every branch location shares the same VLAN ID numbers:
VLAN 10 for full access
VLAN 11 for partial access
VLAN 12 for Internet only access
Figure 9-33 shows how the different FlexConnect ACLs have been mapped to each VLAN.
Figure 9-33
VLAN-ACL Mapping
The FlexConnect ACLs shown in Figure 9-34 and Figure 9-35 are explained in more detail in
Chapter 15, BYOD Enhanced Use CasePersonal and Corporate Devices.
9-29
Chapter 9
Figure 9-34
Branch1_ACL_Partial_Access FlexConnect ACL
Figure 9-35
ACL_Internet_Only
9-30
Chapter 9

CampusConverged Access Design
FlexConnect VLAN Override

In the current FlexConnect architecture, there is a strict mapping of WLAN to VLAN, so the client
getting associated on a particular WLAN on a FlexConnect AP has to abide by the VLAN which is
mapped to it. This method has limitations because it requires clients to associate with different SSIDs in
order to inherit different VLAN-based policies.
Starting on WLC release 7.2, AAA Override (Dynamic VLAN assignment) of VLANs on individual
WLANs configured for local switching is supported. To assign endpoints dynamically to a VLAN, the
VLAN IDs are pre-created and the corresponding WLAN-VLAN Mapping on a FlexConnect group is
configured, as shown in Figure 9-33.
Figure 9-36 shows the different configuration settings required to dynamically assign endpoints to a
branch VLAN, which include:
Figure 9-36
The WLAN at the branch configured for local switching mode.
802.1Q trunk between the Catalyst switch and the access point.
A native VLAN and allowed VLANs for the trunk.
The ISE authorization profile defines what VLAN is assigned to the endpoint.
The WLAN is configured at the controller to allow AAA Override.
The VLANs are pre-defined and the VLAN-ACL mapping is defined for the FlexConnect group.
FlexConnect VLAN Override
Data Center
Branch
VLAN 11
CAPWAP
CAPWAP
ISE
802.1Q
Trunk
WAN
VLAN 12
Flex 7500
294108
description to Branch #1 AP
switchport trunk encapsulation dot1q
switchport trunk native vlan 18
switchport trunk allowed vlan 10-18
spanning-tree portfast trunk

The converged large campus design looks at the hybrid large campus design model, as discussed in
Campus Migration Path of Chapter 5, Campus and Branch Network Design for BYOD. A hybrid large
campus design consists of multiple Catalyst 3850s switches or switch stacks deployed at the access layer
9-31
Chapter 9
of the network, operating in Mobility Agent (MA) Mode. A centralized Cisco CT5760 controller within
the campus contains the Mobility Controller (MC) function. A Unified Controller CT5508 exists within
the campus controller and forms a mobility group with CT5760s. APs may be connected to the CT5760
or CT5508 controllers via Catalyst 3850 or CT3750 switches. In addition a CT5760 or CT5508 may be
used as guest access anchor at the Internet edge of the campus. In this design guide the CT5508 is
configured as a guest controller.
This design guide will make the following assumptions for the large campus converged access design:
On-boarded wired and wireless devices will share the same VLAN, and hence the same IP subnet
addressing space. It is recognized that customers may implement separate subnets for wired and
wireless devices due to issues such as additional security compliance requirements for wireless
devices. This is not addressed within this version of the design guidance.
Catalyst 3850 Series switches are deployed as Layer 2 access switches within the campus. Layer 3
connectivity will be provided by the Catalyst 6500 building distribution switches. Also, in keeping
with campus best practices, VLANs will be limited to a single wiring closet. In other words, VLANs
will not extend between access-layer switches. Future design guidance may address Catalyst 3850
Series switches deployed as Layer 3 switches or address spanning VLANs across access-layer
switches.
Campus Converged AccessDual SSID Design

In this design there are again two SSIDs: one provides enrollment/provisioning and the other provides
secure network access. After connecting to the BYOD_Provisioning SSID and completing the
enrollment and provisioning steps, the user connects to the BYOD_Employee SSID, which provides
network access over a secure EAP-TLS connection.
Figure 9-37 shows the dual SSID design for the campus APs.
Figure 9-37
CampusDual SSID
Data Center
Campus
Step 1: On-boarding
ISE
CAPWAP
CAPWAP
Catalyst
3850
BYOD_Employee
SSID
Full
Partial
Internet
CT5760
AD
CA
294109
BYOD_Provisioning
SSID
In the converged access dual SSID design, there are some additional considerations:
The provisioning SSID can be either open or password protected. When the provisioning SSID is
credentials, such as AD group membership, are allowed to connect to the SSID. In this design guide,
the provisioning SSID is configured to be open and its only purpose is to provide on-boarding
services.
9-32
Chapter 9

After the device is provisioned, it is assumed that the user will switch to the second SSID for regular
network access. To prevent the user from staying connected to the provisioning SSID, an access list
that provides only access to ISE, DHCP, and DNS must be enforced on the provisioning SSID. The
details of the ACL_Provisioning_Redirect ACL are shown below.
This design guide makes use of the following SSIDs: BYOD_Provisioning and BYOD_Employee.
The properties of these two SSIDs are highlighted in Table 9-4.

Table 9-4
WLAN Parameters
Attribute
BYOD_Provisioning
BYOD_Employee
Description
Used only for device

provisioning
For employees that have completed the

on-boarding process
Layer 2 Security
WPA+WPA2
MAC Filtering
Enabled (for Open SSID) Disabled
WPA+WPA2 Parameters None
Layer 3 Security
None
None
AAA Server
Select ISE
Select ISE
Advanced
Advanced
NAC State- NAC
NAC State- NAC
To configure WLAN BYOD_Provisioning SSID on a CT5760 and Catalyst 3850 follow the steps below.
The security on the BYOD_Provisioning SSID is NONE as this is a provisioning SSID through which
devices are provisioned on the network. The FAST-SSID feature provides a way for a client to directly
switch from BYOD_Provisioning to BYOD_Employee SSID after it has been properly provisioned by
ISE.
aaa new-model
!
!
aaa authentication login default enable
aaa authentication dot1x default group radius
aaa authorization network default group radius
aaa accounting dot1x default start-stop group radius
!
!
!
!
aaa server radius dynamic-author
client 10.225.49.15 server-key 7 032A4802120A701E1D5D4C
!
aaa session-id common
!
ip device tracking
!
!
qos wireless-default-untrust
captive-portal-bypass
!
mac access-list extended MAC_ALLOW
permit any any
!
!
interface Vlan2
description ### BYOD-Employee Vlan ###
9-33
Chapter 9
ip address 10.231.2.7 255.255.255.0

load-interval 30
!
interface Vlan3
description ### BYOD-Provisioning Vlan ###
ip address 10.231.3.7 255.255.255.0
load-interval 30
!
ip http server
ip http authentication local
ip http secure-server
!
wireless management interface Vlan47
wireless client fast-ssid-change
wireless rf-network byod
wireless security dot1x radius call-station-id macaddress
aaa-override
client vlan BYOD-Employee
nac
security web-auth parameter-map global
no shutdown
aaa-override
client vlan BYOD-Provisioning
nac
no security wpa
no shutdown
The example configuration shown above must be configured on both the Catalyst 3850 which functions
as the Mobility Agent (MA), and the CT5760 which functions as the Mobility Controller (MC) in the
campus design. Note that the IP addressing for the VLAN interfaces will be different for the MA and
MC, however, since they are deployed in different parts of the network infrastructure. Mobility is
handled as a separate topic within this chapter, following the WLAN configuration discussion.
Additional configuration lines must be added to the MA and MC, respectively for mobility. These are
discussed shortly.
The BYOD_Provisioning SSID has no Layer 2 security, as this is an SSID through which devices are
provisioned on the network. Instead the wireless client uses MAC-filtering (basically a wireless version
of MAB) to authenticate to the network. A URL re-direction and Centralized Web Authentication
(CWA) policy is pushed down to the client from ISE, upon connecting to the network. Hence, the
configuration for MAC-filtering, NAC, and AAA override are required on the BYOD_Provisioning
SSID.
The security on the BYOD_Employee SSID is WPA2 with AES encryption. Note that this is the default
setting for a WLAN on the Converged Access platforms (CT5760 or Catalyst 3850) and therefore does
not appear within the configuration. The configuration for NAC and AAA override are required on this
SSID in order to support a dynamic ACL assignment to the wireless client. In the case of this design
guide, the dynamic ACL is a named ACL configured locally on the Catalyst 3850 switch.
Note
The administrative level command show wlan name <name_of_wlan> can be used to show the details
regarding the configuration of any WLAN on either the Catalyst 3850 Series switch or the CT5760
wireless controller. This includes any default settings which do not appear within the configuration.
9-34
Chapter 9

Even though a CWA policy is pushed to the wireless client from ISE during on-boarding via the
BYOD_Provisioning SSID, the HTTP and HTTPS server functionality must be globally enabled on the
Catalyst 3850 Series switch. This is in order to support the URL re-direction of web sessions from
wireless clients to the ISE provisioning portal. The RADIUS server group configuration points back to
ISE as the RADIUS server for authentication and authorization of wireless (and wired) clients. The
captive portal bypass functionality must be globally enabled on the Catalyst 3850 Series switch in order
to allow Apple devices to on-board successfully. The fast-ssid-change global configuration provides a
way for client to switch from BYOD_Provisioning to BYOD_Employee SSID after it has been properly
provisioned by ISE.
The wireless mobility configuration commands for the CT5760 which functions as the MC will be
different from the Catalyst 3850 which functions as the MA. An example of the global mobility
configuration lines for the CT5760 wireless controller is shown below.
!
interface Vlan47
description MGMT VLAN
ip address 10.225.47.2 255.255.255.0
load-interval 30
!
wireless mobility controller peer-group 100
wireless mobility controller peer-group 100 member ip 10.203.61.5 public-ip 10.203.61.5
wireless mobility group member ip 10.225.50.36 public-ip 10.225.50.36/Points to CT5508
wireless mobility group name byod
!
As can be seen, the CT5760 is configured as the mobility controller (MC) for two switch peer-groups
(SPGs)100 and 200in the example above. Switch peer-group 100 contains a single Catalyst 3850
switch functioning as a MA. Switch peer-group 200 contains two Catalyst 3850 switches functioning as
MAs. An example of the global mobility configuration lines for the Catalyst 3850 is shown below.
interface Vlan47
description MGMT VLAN
ip address 10.225.61.5 255.255.255.0
load-interval 30
!
wireless mobility controller ip 10.225.47.2 public-ip 10.225.47.2 / IP Address of 5760 MC
The IP address corresponding to the wireless management interface of the Catalyst 3850 series switch
shown in the configuration above appears as a member of SPG 200. SPGs are designed to scale mobility
within a Converged Access design. Roaming between Catalyst 3850 Series switch mobility agents
(MAs) within a single SPG is handled directly by the switches without the involvement of the CT5760
mobility controller (MC). This is done via a full mesh of CAPWAP tunnels between the Catalyst 3850
Series switch mobility agents (MAs) within a single SPG. Roaming between Catalyst 3850 Series switch
mobility agents (MAs) across two SPGs is handled by the CT5760 mobility controller (MC). This is
done via CAPWAP tunnels between each Catalyst 3850 Series switch mobility agent (MA) and the
CT5760 mobility controller (MC).
As discussed previously, a hybrid campus design may consist of CT5508 wireless controllers operating
in Local Mode, alongside the Converged Access infrastructure. This may be necessary during the
migration from a centralized wireless overlay model to a Converged Access deployment model. In order
9-35
Chapter 9
to support mobility between the CT5508 wireless controller and the CT5760 wireless controller, the IP
address of the CT5508 wireless controller has been added as a wireless mobility group member to the
configuration of the CT5760 shown above.
Campus Converged AccessSingle SSID Design

In a single SSID design the same WLAN (BYOD_Employee) is used for on-boarding and secure network
access. Figure 9-38 shows how this design may be implemented using the CT5760 as an MC and
Catalyst 3850 as MA.
Figure 9-38
Campus-Single SSID
Data Center
Campus
Step 1: On-boarding
ISE
CAPWAP
Catalyst
3850
Full
Partial
Internet
CT5760
AD
CA
294110
BYOD_Employee
SSID
CAPWAP
The configuration for a single SSID converged campus design is almost the same as a dual SSID design
but without the use of the BYOD_Provisioning SSID. A snippet of configuration on the CT5760 and the
Catalyst 3850 is shown below. Mobility is handled as separate topic following the WLAN configuration
discussion.
aaa new-model
!
!
!
!
!
!
!
!
ip device tracking
!
!
!
permit any any
!
9-36
Chapter 9

!
interface Vlan2
ip address 10.231.2.7 255.255.255.0
load-interval 30
!
interface Vlan3
ip address 10.231.3.7 255.255.255.0
load-interval 30
!
ip http server
!
aaa-override
nac
no shutdown
The mobility configuration for both the MC and MA will remain the same as discussed above for the
dual SSID Converged Access design.
Campus Converged AccessMobility

For the large campus design it is important to understand mobility and roaming considerations.
This design highlights multiple Catalyst 3850 Series switches or switch stacks deployed at the access
layer of a large sized campus. Switch stacks form Switch Peer Groups (SPGs) in which all switches
contain the Mobility Agent (MA) function. Roaming within a SPG is handled through a full mesh of
mobility tunnels between MAs within the SPG. Multiple SPGs exist within the large sized campus. APs
must be directly connected to MA and not via an intermediate switch (example: a Catalyst 3750 switch).
A Cisco CT5760 wireless controller deployed within a centralized service module within the campus
contains the Mobility Controller (MC) function. Multiple SPGs connecting to a single MC form a
Mobility Sub-Domain. Multiple Mobility Sub-Domains exist within the large sized campus. Roaming
between SPGs within a Mobility Sub-Domain is done through the Cisco CT5760 and/or CT5508
wireless controller. APs connected to a Catalyst 3850 switch register with the CT5760 MC. APs can
also be connected to CT5760 via Catalyst 3750 switches.
Multiple Cisco CT5760 and/or CT5508 wireless controllers form a Mobility Group. Hence, a Mobility
Group also consists of multiple Mobility Sub-Domains. Roaming between Mobility Sub-domains is
done through the Cisco CT5760 and/or CT5508 wireless controllers within the Mobility Group. A single
Mobility Group and hence a single Mobility Domain extends across and are entirely contained within
the large campus within this design.
For hybrid models consisting of both a CUWN local-mode and converged access products, either a Cisco
CT5760 or a CT5508 also serves as a wireless controllers for access points connected to Catalyst 3750-X
Series switches using traditional local mode (centralized switching) wireless connectivity.
Keeping above the considerations in mind, few things should be kept in mind.
9-37
Chapter 9
By default Catalyst 3850 operates as a Mobility Agent and there is no need of any configuration. A
Catalyst 3850 may also operate as a Mobility Controller. This mode is covered as part of Branch Design.
See Appendix C, Software Versions for details about the Catalyst 3850 software licensing.
CT5760 wireless controller operates only as a Mobility Controller. Mobility tunnels should be setup
between CT5760s and Catalyst 3850s for APs connected on Catalyst 3850s to be registered with the MC
(CT5760). A snippet of configuration for MC is as below:
wireless
wireless
wireless
wireless
wireless
mobility
mobility
mobility
mobility
mobility
controller
controller
controller
controller
controller
peer-group
peer-group
peer-group
peer-group
peer-group
100
100 member ip 10.203.61.5 public-ip 10.203.61.5
200
On each Catalyst 3850 acting as an MA, the configuration below is needed to establish a mobility tunnel
with the CT5760 MC or a 5508 MC.
wireless mobility controller ip 10.225.47.2 public-ip 10.225.47.2 / IP Address of MC
The CT5508 and CT5760 can also form a mobility group. The CT5508 should be upgraded to either
7.3.112 or a version above 7.5 of the WLC to support mobility between converged access and unified
access products. The configuration on the CT5508 to enable mobility between the CT5760 and the
CT5508 is shown below. The design guide provides guidance for version 7.5 for CT5508.
wireless mobility controller/ Enables the MC function, by default turned on CT5760
wireless mobility group name byod/ Create mobility group byod
wireless mobility group member ip 10.225.50.36 public-ip 10.225.50.36/ IP of member CT5508
Note
Only WLC versions 7.3.112 or 7.5 and above support mobility between converged access products and
unified access products. Ensure that you have code version running compatible code. This design guide
uses 7.5 release.
To enable mobility between converged access and unified access products, first the New Mobility should
be enabled on the WLC as shown in Figure 9-39.
9-38
Chapter 9

Figure 9-39
Enable New Mobility
After enabling New Mobility and restarting the Wireless LAN Controller, additional options for
configuring switch peer groups as well as mobility groups are enabled. For CT5760 and CT5508 to form
a group and talk to each other, additional configuration as below is required.
Click Mobility Management > Mobility Groups and click New, as shown in Figure 9-40.
Figure 9-40
Create New Mobility Group
The Member IP address above should be the CT5760 IP address that enables mobility messaging and
CAPWAP tunnels to be set up between CT5760 and CT5508.
Other design considerations while deploying a large campus WLAN infrastructure include the
following:
802.1X, WLAN, and VLAN configurations should be replicated on all Catalyst 3850s and CT5760s.
Mobility group name should be the same between CT5760s and CT5508s.
9-39
Chapter 9
BranchConverged Access Design

With a converged access design, a centralized FlexConnect wireless controller can be replaced by a
Catalyst 3850 switch that operates both as a Mobility Agent (MA) and Mobility Controller (MC). Guest
wireless access still utilizes the same model wherein the guest traffic is auto-anchored to a dedicated
guest anchor controller located within the Internet Edge of the campus. The guest controller can be a
CT5508 controller with a 7.5 version of code, or a CT5760 converged wireless LAN controller.
The integrated controller branch BYOD design guide makes the following assumptions:
On-boarded wired and wireless devices will share the same VLAN and hence the same IP subnet
addressing space. It is possible to use different VLAN and addressing space for wireless and wired
clients, however it is not addressed in this design guide.
The Catalyst 3850 switches are deployed as a Layer 2 switches within the branch location. Layer 3
connectivity within the branch will be provided by ISR routers which also serve as the WAN
connectivity point for the branch. (Future design guides may address Catalyst 3850 deployed as
Layer 3 switch within the branch location).
Branch Converged AccessDual SSID Design

In the dual-SSID design, a dedicated open SSID (BYOD_Provisioning) with MAC-filtering (i.e., MAC
Authentication Bypass) will be configured for on-boarding devices. The SSID will be statically mapped
to a separate Provisioning VLAN on the Catalyst 3850 switch. Figure 9-41 shows the branch converged
access for a dual SSID design.
Figure 9-41
Branch Converged AccessDual SSID
Data Center
Branch
Step 1: On-boarding
BYOD_Provisioning
SSID
CAPWAP
CAPWAP
Catalyst
3850
ISE
WAN
Full
Partial
Internet
AD
CA
294113
BYOD_Employee
SSID
Table 9-5 summarizes the VLANs within the branch when utilizing the dual-SSID BYOD on-boarding
design.
9-40
Chapter 9

Table 9-5
VLANs in Branch with Dual-SSID BYOD On-boarding Design
Description
VLAN VLAN Name
Wired and wireless corporate access. IT managed devices.

Employee managed devices with full, partial, or Internet access.
12
BYOD_Employee
Provisioning VLAN for Dual-SSID wireless on-boarding.
13
BYOD_Provisioning
Separate VLAN for branch servers.
16
Server
Dedicated VLAN for management of network infrastructure.
18
Management
Isolated VLAN for pass through of wireless auto-anchor tunnels. Not 777
trunked to Layer 3 router.
BYOD_Guest
The following configuration snippet provides an example of the possible configuration additions to the
Catalyst 3850 in order to support on-boarding of wireless devices in a dual-SSID BYOD implementation
using MAC-filtering.
aaa new-model
!
!
aaa accounting network default start-stop group radius
!
auth-type any
!
!
ip device tracking
!
vtp domain bn
!
permit any any
!
wireless mobility controller
wireless mobility group member ip 10.225.50.36 public-ip 10.225.50.36
wireless broadcast
wireless multicast
aaa-override
client vlan BYOD_Employee
nac
security dot1x authentication-list default
no shutdown
aaa-override
9-41
Chapter 9
no security wpa
security web-auth
no shutdown
aaa-override
client vlan BYOD_Provisioning
nac
no security wpa
no shutdown
!
The following configuration snippet provides a partial example of the possible configuration additions
to the branch router configuration in order to support on-boarding of wireless devices in a dual-SSID
BYOD implementation using MAC-filteringwhen the Catalyst 3850 Series switch is functioning as a
Layer 2 switch.
!
interface GigabitEthernet0/0
description CONNECTION TO CATALYST 3850 SWITCH
no ip address
load-interval 30
duplex auto
speed auto
!
interface GigabitEthernet0/1.13/ Provisioning VLAN
description CATALYST 3850 PROVISIONING VLAN
ip address 10.200.13.2 255.255.255.0
ip helper-address 10.230.1.61/ Relay DHCP to the DHCP server
ip helper-address 10.225.42.15/ Relay DHCP to ISE for profiling
standby 13 ip 10.200.13.1
standby 13 preempt
!
Branch Converged AccessSingle SSID Design

In the single SSID design, the corporate SSID (BYOD_Employee) supports authentication via PEAP for
non on-boarded devices. Once on-boarding is complete, the corporate SSID supports authentication via
EAP-TLS for on-boarded devices. The corporate SSID is statically mapped to a separate Corporate
VLAN on the Catalyst 3850 switch. Figure 9-42 shows the branch converged access for a single SSID
Design.
9-42
Chapter 9

Figure 9-42
Branch Converged AccessSingle SSID
Data Center
Branch
Step 1: On-boarding
BYOD_Employee
SSID
Catalyst
3850
ISE
CAPWAP
WAN
Full
Partial
Internet
AD
CA
294114
CAPWAP
Table 9-6 summarizes the VLANs within the branch when utilizing the single-SSID BYOD on-boarding
design.
Table 9-6
VLANs in Branch when Utilizing Single-SSID BYOD On-boarding Design
Description
VLAN VLAN Name
Wired and wireless corporate access. IT managed devices.

Employee managed devices with full, partial, or Internet access.
12
BYOD_Employee
Separate VLAN for branch servers.
16
Server
Dedicated VLAN for management of network infrastructure.
18
Management
Isolated VLAN for past through of wireless auto-anchor tunnels. Not 777
trunked to Layer 3 router.
BYOD_Guest
The following configuration shows relevant parts of configuration for the Catalyst 3850 when utilizing
a single SSID on-boarding model.
aaa new-model
!
!
!
auth-type any
!
!
ip device tracking
!
!
!
permit any any
!
9-43
Chapter 9

wireless broadcast
wireless multicast
aaa-override
client vlan BYOD_Employee
nac
no shutdown
aaa-override
no security wpa
security web-auth
no shutdown
!
?
9-44
CH AP TE R
10

Revised: July 11, 2014
Whats New: Added notes about how ACL behavior has changed in version 7.5+ of the Wireless LAN
Controller.
The Cisco Identity Services Engine (ISE) allows for enforcement of centrally configured policies across
wired and wireless networks to help organizations provide secure unified access. The Cisco ISE plays a
critical role in enabling the BYOD model, where employees are allowed to connect their personal
devices securely to the network. By integrating with third-party Mobile Device Managers (MDM),
additional device posture may be used to enforce permissions into the network.
Cisco ISE provides a highly scalable architecture that supports both standalone and distributed
deployments. The configuration guidelines shown in this document reflect a distributed architecture with
multiple nodes.
For small BYOD deployments, one or two ISE nodes may be configured in standalone mode. Depending
on how the AAA connections are configured across the access layer switches and Wireless LAN
Controllers, either an active/backup or load balancing of AAA workflows can be enabled across the
redundant standalone ISE nodes.
For larger BYOD deployments, the ISE functionality can be distributed across multiple nodes.
Distributed deployments support the following different ISE personas:
AdministrationThe administration node handles all system level configuration. There can be one
primary and one secondary administration node in a distributed deployment.
MonitoringThe monitoring node handles log collection and provides monitoring and
troubleshooting tools. There can be one primary and one secondary monitoring node in a distributed
deployment.
Policy ServiceThe policy service node provides authentication, authorization, guest access, client
provisioning, and profiling services. There can be multiple policy services nodes in a distributed
deployment.
To support a medium-sized BYOD deployment, both administration and monitoring personas can be
deployed on a single node while dedicated policy services nodes can handle AAA functions. For a large
BYOD deployment, the monitoring persona can be implemented on a dedicated node providing
centralized logging functions.
10-1
Chapter 10

ISE needs an identity certificate that is signed by a CA server so that it can be trusted by endpoints,
gateways, and servers. Figure 10-1 illustrates the steps at a high level.
Figure 10-1
High-Level Steps for Deploying Identity Certificates on ISE
Generate a signing request

and save it as a file
Download the CA server certificate
The issued certificate by the CA server should

be installed on the ISE
292603
Access the CA server and submit the

ISE request
For more details on installing a digital certificate on the Cisco ISE, refer to the TrustSec How-To Guide:
http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns742/ns744/docs/howto_60_byod_certi
ficates.pdf.
Network Device Definition within ISE

A network device is an authentication, authorization, and accounting (AAA) client through which AAA
service requests are attempted, for example, switches, routers, and so on. The network device definition
enables the Cisco Identity Services Engine (Cisco ISE) to interact with the network devices that are
configured. A network device that is not defined cannot receive AAA services from Cisco ISE.
As users/devices connect to network infrastructure such as wireless controllers and switches enabled for
802.1X authentication, the network device serves as an 802.1X Authenticator to the clients Supplicant.
In order for the network device to determine if access is to be granted and what services the device is
authorized for, the network device must be able to communicate with the ISE serving as the
Authentication Server. To enable this communication, the ISE must be configured with information
about that network device as well as credentials to be used to authenticate it.
To configure ISE with this information, refer to Figure 10-2 and the following:
1.
At ISE go to Administration > Network Resources > Network Devices and click Add.
2.
Enter the hostname of the device.
3.
Enter the IP Address of the network device. This must be the address used to source all RADIUS
communications from the device.
4.
Change the Network Device Location or Device Type if a custom location/type has been previously
defined.
5.
Configure the RADIUS Shared Secret. This must match that configured on the network device for
the ISE server.
6.
Click the down arrow next to SNMP Settings and complete as appropriate.
10-2
Chapter 10

Figure 10-2
Network Device Configuration in ISE

While the ISE can maintain an internal list of users for authentication purposes, most organizations rely
on an external directory as the main identity source. By integrating with Microsofts Active Directory,
objects such as users and groups become critical in the authorization process and can be accessed from
a single source.
To integrate with Active Directory, on the ISE click Administration > External Identity Sources >
Active Directory and specify the domain name, as shown in Figure 10-3. To verify that the ISE node
can connect to the Active Directory domain, click Test Connection and authenticate with an AD
username and password, as shown in Figure 10-3. Click Join to join the ISE node to Active Directory.
10-3
Chapter 10
Guest and Self-Registration Portals
Figure 10-3
Note
Active Directory Integration
The Cisco Identity Services Engine User Guide has detailed configuration steps:
http://www.cisco.com/en/US/customer/docs/security/ise/1.2/user_guide/ise_user_guide.html.

The Cisco ISE server has the capability to host multiple portals. The BYOD system design relies on the
Guest Portal to provide wireless guest access and, for provisioning purposes, the redirection of
employees to the Self-Registration portal to on-board their devices. Chapter 21, BYOD Guest Wireless
Access discusses the use of the Guest Portal for guest wireless access. The default ISE portals have
standard Cisco branding that may be customized to identify unique portals for different purposes and
with individual policies.
ISE enables self-provisioning, which allows employees to register their personal devices. The ISE
provisions the device with its native supplicant during device registration.
The BYOD system leads the employee through the following provisioning steps the first time they bring
their personal device to work and register:
1.
The employee connects the device to the open SSID (BYOD_Provisioning SSID for dual SSIDs).
2.
The device is redirected to the Guest Registration portal.
3.
The employee enters credentials and ISE authenticates against Active Directory.
4.
If the device is not yet registered on the network, the session is redirected to the self-registration
portal.
5.
The employee is asked to enter a unique device description and complete the device registration.
To enable Self-Provisioning, configure these portals as follows: click Administration > Web Portal
Management > Settings > Guest > Multi-Portal Configurations, as shown in Figure 10-4.
10-4
Chapter 10

Figure 10-4
Portal SettingsOperations
The DefaultGuestPortal refers to the portal used for self-registrationotherwise known as the
Self-Registration portal in this document.
To specify how the portal authenticates users, select the Authentication tab within the particular portal,
as shown in Figure 10-5, and select the appropriate option:
GuestThe portal authenticates guest user accounts stored in the local database.
Central WebAuthThe user is authenticated against the databases specified in the Identity Store
Sequence.
BothThe user is authenticated against a local guest database first. If the user is not found,
authentication is attempted using additional databases defined in the Identity Store Sequence.
10-5
Chapter 10
Figure 10-5
Authentication Portal Settings
ISE Using Certificates as an Identity Store

To configure ISE to use certificates as an identity store, choose Administration > External Identity
Sources > Certificate Authentication Profile > Add and define the Certificate Authentication Profile,
as shown in Figure 10-6.
Figure 10-6
Certificate Authentication Profile
Identity Source Sequences

Identity Source Sequences define the order in which ISE will look for user credentials in the different
databases. These databases include Internal Users, Active Directory, LDAP, RSA, etc.
10-6
Chapter 10

To add a new Identity Source Sequence, click Administration > Identity Source Sequences > Add.
The configuration shown in Figure 10-7 creates a new Identity Source Sequence named
All_Stores_Sequence. It relies on Active Directory (AD1), a certificate profile named
Certificate_profile and Internal Users.
Figure 10-7
Identity Source Sequence
SCEP Profile Configuration on ISE

Within this design, ISE is acting as a Simple Certificate Enrollment Protocol (SCEP) proxy server,
thereby allowing mobile clients to obtain their digital certificates from the CA server. This important
feature of ISE allows all endpoints, such as iOS, Android, Windows, and MAC, to obtain digital
certificates through the ISE. This feature combined with the initial registration process greatly simplifies
the provisioning of digital certificates on endpoints.
To configure SCEP profile on the ISE, click Administration > Certificates > SCEP RA Profiles > Add.
Define the SCEP profile, as shown in Figure 10-8.
10-7
Chapter 10
Authentication Policies
Figure 10-8
SCEP Profile Configuration
After the configuration is successful, ISE downloads the RA certificate and the root CA certificate of the
CA server, as shown in Figure 10-9.
Figure 10-9
Certificate Store
Authentication policies are used to define the protocols used by the ISE to communicate with the
endpoints and the identity sources to be used for authentication. ISE evaluates the conditions and based
on whether the result is true or false, it applies the configured result. An authentication policy includes:
An allowed protocol service, such as PEAP, EAP-TLS, etc.
An identity source used for authentication
Similar to the way access lists are processed, authentication rules are processed from the top down.
When the first condition is met, processing stops and the assigned identity rule is used.
The rules are evaluated using If, then, else logic:
IF Wired_802.1X
Then
Allow default protocols
Elseif
next condition
Take action
10-8
Chapter 10

Else
Use Default Rule
In BYOD designs discussed throughout this document, ISE authenticates several protocols such as MAB
and dot1x against all the Identity Stores. The Identity Stores could be AD, Certificate_Profile, RSA,
Internal Users, and Internal Endpoints. The network access medium could be wired, wireless, or remote
connection. The network device uses any of the mediums mentioned before, using different protocols to
connect to ISE.
MAC Authentication Bypass (MAB) protocol is used to authenticate devices not configured with dot1x.
When a brand new device accesses the network it communicates via the MAB protocol and uses its own
MAC address as its identity. In a normal scenario, ISE would validate if the MAC address is present in
any of its identity stores; if not, it would reject the connection. However in this BYOD design the MAB
protocol is used by new devices for on-boarding purposes and it may not be feasible to know the MAC
address of the device in advance.
To circumvent this problem, ISE continues the authentication process and redirects the device to the next
stage, even if the devices MAC address is not present in any of its identity stores. Figure 10-10
highlights this configuration.
Figure 10-10
Authentication Rule for MAB
In a normal deployment scenario, the endpoints would primarily use the dot1x protocol to communicate
with ISE. ISE authenticates these endpoints against an Active Directory or authenticates them via digital
certificates. Figure 10-11 depicts the different protocols and how these protocols use different identity
stores for authentication.
10-9
Chapter 10
Figure 10-11
Authentication Policy
Device
connects to the
network
Wireless
MAB?
Use All_Stores
sequence
Continue even if
MAC not found
EAP_TLS
Wireless
Dot1X?
Authenticate
with Certificate_
Profile
Network
Access Type?
Continue to
AuthZ Rules
PEAP
Authenticate
with AD
294124
Deny Access
Table 10-1 explains how these rules are implemented in this design guide.
Table 10-1
Authentication Rules
Rule Name
Network Access
Medium
Allowed
Protocols
Conditions
Identity Store
Wireless MAB AuthC
Wireless MAB
All
Default
All_Stores
Wired MAB AuthC
Wired MAB
All
Default
All_Stores
Wireless Dot1X AuthC
Wireless_8021X
All
Wireless Certificate
EAP_TLS
Certificate_Profile
Wireless Password
PEAP
All_Stores
Wired Certificate
EAP_TLS
Certificate_Profile
Wired Password
PEAP
All_Stores
Wired Dot1X AuthC
Wired_802.1X
All
Default
Deny Access
Authentication Policy for Wireless

The endpoint devices could use either MAB or dot1x protocol when connecting to the wireless network.
The authentication policy for wireless networks using MAB is explained in the previous section. This
section explains the authentication policy for wireless medium using dot1X protocol, as shown in
Table 10-1.
Wireless Dot1X AuthC is the rule name for wireless_dot1x protocol. This rule matches wireless_dot1x
protocol and has two inner rules:
10-10
Chapter 10

Wireless CertificateMatches when the authentication protocol is EAP_TLS and it verifies the
digital certificate using the identity store Certificate_Profile.
Wireless PasswordMatches on the PEAP authentication protocol and uses the All_Stores identity
store, which includes Active Directory.
Figure 10-12 shows how these rules were configured on the ISE for this design guide.
Figure 10-12
Authentication Rules
Client Provisioning
The Cisco ISE looks at various elements when classifying the end users device type, including operating
system version, browser type, etc. Once the ISE classifies the client machine, it uses client provisioning
resource policies to ensure that the client is configured with an appropriate agent version, up-to-date
compliance modules and correct agent customization packages and profiles, if necessary. The ISE
Profiling service is discussed in Enabling the DHCP and RADIUS Probes. It is important to understand
the difference between Client Provisioning Policy and Client Provisioning Resources. Client
Provisioning Resources are basically the resources that are pushed to the end device and assist the end
device in completing the on-boarding process. Client Provisioning Resources are of two types:
Native profiles that can be configured on ISE; for example, iOS profile.
Software Provisioning Wizards that must be downloaded from Cisco site.
Client Provisioning Policy on the other hand links an endpoint device to an appropriate Client
Provisioning Resource. Therefore the Client Provisioning Resources must be added to the ISE before
configuring the Client Provisioning Policy. This section discusses Client Provisioning Resources and
Client Provisioning Policies for iOS, Android, Windows and Mac OS X devices.
The following are considerations for client provisioning on the endpoints:
Based on the endpoint, push an appropriate Software Provisioning Wizard (SPW) to the device. This
Wizard configures the dot1x settings on the endpoint and configures the endpoint to obtain a digital
certificate.
10-11
Chapter 10
In certain endpoints such as iOS devices, there is no need for SPW package because for iOS devices
the native operating system is used to configure the dot1x settings.
For Android devices, the SPW package needs to be downloaded from Google Play Store.
Client Provisioning ResourcesApple iOS and Android

To configure a client provisioning resource for mobile devices, click Policy > Policy Elements >
Results > Client Provisioning > Resources > Add Native Supplicant Profile. Figure 10-13 shows the
configuration details for the Wireless iOS TLS profile used by Apple iOS devices. This profile is used
to configure the parameters required to access to the BYOD_Employee SSID after on-boarding.
Figure 10-13
Wireless iOS TLS Profile
Figure 10-14 shows the configuration details for the Wireless Android TLS profile used by Android
devices.
10-12
Chapter 10

Figure 10-14
Wireless Android TLS
Client Provisioning PolicyApple iOS and Android Devices

Client provisioning policies determine which users receive which version of resources. After defining
the Native Supplicant Profile, the next step is to use the appropriate profile when devices connect to the
network by clicking Policy > Client Provisioning.
The configuration in Figure 10-15 determines the operating system running on the device and defines
which resources to distribute. In this case the previously defined profiles are distributed based on the
appropriate operating system.
Figure 10-15
Client Provisioning Policies
It is important to note that for Android devices the user is also required to download the software from
Google's Play Store, since it cannot be distributed by ISE.
Client Provisioning ResourcesMac OS

For MAC OS workstations, the following is required:
10-13
Chapter 10
A Native Supplicant profile that determines what kind of configuration should be provisioned on the
device, for example the Wireless SSID name. Figure 10-16 shows the native supplicant profile for
Mac OSX devices.
Figure 10-16
Native Supplicant Profile for Mac OSX Devices
A Wizard ProfileThe Supplicant Provisioning Wizard profile is a software agent that may be
downloaded from Cisco.
To define the client provisioning resources, click Policy > Policy Elements > Results > Client
Provisioning > Resources > Add > Agent Resources from the Cisco site and select the
MacOsXSPWizard. Figure 10-17 shows the MacOsXSPWizard profile.
Figure 10-17
Mac OsXSPWizard Profile
10-14
Chapter 10

Client Provisioning Policy for Mac OS DevicesWireless

The previous section discussed the resources needed for provisioning Mac OS devices. Once the
resources have been configured, the next step is to define under what conditions these resources will be
used. The Mac OS X devices can use either MAB or PEAP protocol during the provisioning process.
Therefore different conditions have to be configured to match either one of them.
The MAB protocol is matched by the following two conditions:
RADIUS:NAS-Port-Type EQUALS WirelessIEEE 802.11
RADIUS:Service-Type EQUALS Call Check
Figure 10-18 shows the Client Provisioning Policy to match on the MAB protocol.
Figure 10-18
Client Provisioning Policy for MAB
To match a Mac device using the PEAP protocol, the following conditions are needed:
RADIUS:NAS-Port-Type EQUALS WirelessIEEE 802.11
Network Access:EapTunnel EQUALS PEAP
Figure 10-19 shows the condition to match on MAC devices using the PEAP protocol.
10-15
Chapter 10
Figure 10-19
Client Provisioning Policy for PEAP
To complete a Client Provisioning policy for MAC_OSX_Wireless devices, the following must be
defined:
The Operating System must be selected as Mac OSX.
The Conditions should be used to match either MAB or PEAP protocol.
The result section must contain the Native Supplicant profile and the SPW for Mac OS X devices.
The complete policy is shown in Figure 10-20.

Figure 10-20
Client Provisioning Policy for Mac OS X
10-16
Chapter 10

Client Provisioning Policy for Windows DevicesWireless/Wired

The configuration steps for defining the provisioning policy for Windows devices is very similar to Mac
OS X or iOS devices, so the same configuration steps are not repeated here. The only difference to point
out is that for Windows devices a different SPW package is needed. Figure 10-21 depicts the Client
Provisioning Policy for Windows (wireless or wired) devices using either MAB or PEAP.
Figure 10-21
Client Provisioning Policy for Windows
Figure 10-22 shows the complete client provisioning policy used during testing.
Figure 10-22
Complete Client Provisioning Policy
10-17
Chapter 10
Profiling
Profiling
Profiling is a key service responsible for identifying, locating, and determining the capabilities of
endpoints that attach to the network to deny or enforce specific authorization rules. Two of the main
profiling capabilities include:
CollectorUsed to collect network packets from network devices and forward attribute values to
the analyzer.
AnalyzerUsed to determine the device type by using configured policies that match attributes.
There are two main methods to collect endpoint information:
The ISE acting as the collector and analyzer.
Starting in version 7.3, the WLC can act as the collector and send the required attributes to the ISE,
which acts as the analyzer.
Client profiling from a controller running 7.3 or later is supported on access points that are in Local
mode and FlexConnect mode. Table 10-2 shows the main differences between the WLC and ISE
profiling.
Table 10-2
Note
ISE versus WLC Profiling Support
ISE
WLC
Profiling using a large number of probes,

including RADIUS, DHCP, DHCP SPAN, HTTP,
DNS, etc.
DHCP and HTTP based profiling only
ISE supports as policy action multiple different

attributes
WLC supports VLAN, ACL, session timeout, QoS
Profiling rules may be customized with

user-defined attributes
Only default profiling rules may be used
This design guide uses the profiling capabilities of the ISE and did not test the controller client profiling
capabilities.
The ISE supports a number of sensors to capture endpoint attributes and classify them according to their
profiles. The sensors rely on a number of probes that capture network packets by querying network
access devices. Once the endpoints are profiled, different authentication and authorization policies may
be enforced. Some examples of using different policies based on the device's profile include:
Allow employee-owned iPads to access the network, but only for HTTP traffic.
If the iOS device connecting to the network is a company-owned device, grant full access to the
network.
If an employee-owned iPad has been provisioned with a digital certificate, grant full access to the
network.
Force some devices to register with their Mobile Device Manager.
Deny access to all iPads or Android devices.
10-18
Chapter 10

Profiling
Enabling the DHCP and RADIUS Probes

To enable profiling on the ISE, click Administration > System > Deployment. Click the ISE hostname
and click Profiling Configuration. Enable the appropriated probes to listen to packets forwarded from
the LAN switch or Wireless LAN Controller, as shown in Figure 10-23.
Figure 10-23
Profiling Probes
The Wireless LAN Controller should be configured in DHCP bridging mode to forward DHCP packets
from the wireless endpoints to the ISE. Click Controller > Advanced > DHCP and clear the Enable
DHCP Proxy check box, as shown in Figure 10-24.
10-19
Chapter 10
Profiling
Figure 10-24
Disable DHCP Proxy
Specify the ISEs IP address as the secondary DHCP server in the WLC by clicking Controller >
Interfaces > Secondary DHCP, as shown in Figure 10-25.
Figure 10-25
Secondary DHCP Server
10-20
Chapter 10

Profiling
Profiling Android Devices

To create an identity group based on the Android policy, click Policy > Profiling > Profiling Policies >
Android and enable the Create Matching Identity Group, as shown in Figure 10-26.
Figure 10-26
Android Profiling Policy
The Android profiling policy should be listed under Endpoint Identity Groups > Profiled. Click
Administration > Identity Management > Groups to see a list of Android devices that have been
profiled by the ISE, as shown in Figure 10-27.
Figure 10-27
Android Identity Group
10-21
Chapter 10
Profiling
Logical Profiles
Logical profiles are containers that group different profiles to create an overall category of profiles.
Logical profiles provide additional flexibility to the authorization policies, enhancing the overall
network access policy.
With logical profiles, a single entry in the authorization rule is able to include several profiles. Before
logical profiles were available, a matching identity groups had to be created for each device type.
In this design guide, a logical profile was created to group the mobile devices that are managed by the
MDM. This profile combines some mobile devices into a single logical profile that may be invoked from
the authorization rules.
To create a logical profile, click Policy > Profiling > Profiling > Logical Profiles, as shown in
Figure 10-28.
Figure 10-28
MDM Managed Logical Profile
This logical profile provides the flexibility to add new devices at any time without modifying the
authorization rules. Figure 10-29 shows how the MDM Managed Logical Profile is used to identify
devices supported by the MDM.
This and other authorization rules are explained in more detail later in this design guide.
10-22
Chapter 10

Authorization Policies and Profiles
Figure 10-29
MDM Enrollment Authorization Rule

Authorization policies define the overall security policy to access the network. Network authorization
controls user access to the network and its resources and what each device can do on the system with
those resources. An Authorization Policy is composed of multiple rules.
Authorization rules are defined by three main elements, as shown in Figure 10-30:
Names (1)
Conditions (2)
Permissions (3)
Authorization Profiles (4)
Permissions are enforced by authorization profiles (4). Similar to the authentication rules, authorization
rules are processed from the top down. When the first condition is met, processing stops and the assigned
permission dictates what authorization profile to use.
Figure 10-30
Authorization Policy
10-23
Chapter 10
Authorization Profiles
An authorization profile acts as a container where a number of specific permissions allow access to a set
of network services. The authorization profile is where a set of permissions to be granted is defined and
can include:
An associated VLAN.
An associated downloadable ACL (DACL).
Wireless LAN Controller attributes such as the use of a Named ACL or Security Group Tag for
policy enforcement.
Advanced settings using attributes contained in dictionaries.
In addition to the standard PermitAccess and DenyAccess authorization profiles, the following are some
of the profiles that are defined within this design guide:
Wireless CWAThis profile is used for redirection of wireless devices to the registration portal for
devices using MAB and dual SSIDs.
Wireless NSPThis profile is used to redirect wireless users to the registration portal when they
access the network using dot1x or a single SSID.
Blackhole WiFi AccessUsed to block access to devices reported lost (for more information, see
Chapter 22, Managing a Lost or Stolen Device).
Several other authorization profiles are explained in other chapters of this design guide.
Note
Cisco has been made aware of potential incompatibilities introduced by Apple iOS 7. We are working to
understand the limitations and design updates will be made to this publication.
Wireless CWA Authorization Profile for Dual SSID Provisioning

This policy is used in dual SSID configurations to redirect wireless devices to the Self-Registration
portal upon connecting to the network. This authorization profile restricts access by triggering the
ACL_Provisioning_Redirect access list, which is defined in advance in the Wireless LAN Controller.
When implementing dual SSIDs, the provisioning SSID can be either open or password-protected with
Active Directory credentials. In this design guide, the provisioning SSID is open and relies on MAC
Authentication Bypass (MAB) to grant access to the network.
To configure this authorization policy, click Policy > Policy Elements > Results > Authorization
Profiles, as shown in Figure 10-31.
10-24
Chapter 10

Figure 10-31
Wireless CWA Authorization Profile
To force devices to the self-registration portal, a redirect URL is created with a unique Session ID and
pushed to the device:
https://ip:port/guestportal/gateway?sessionId=SessionIdValue&action=cwa
When the user launches a web browser, the device is redirected to the Self-Registration portal. To prevent
the user from staying connected to the provisioning SSID, the ACL_Provisioning_Redirect ACL only
permits access to the Cisco ISE, DHCP, and Domain Name System (DNS) services.
The Wireless CWA authorization profile relies on two named ACLs previously defined in the Wireless
LAN Controller:
ACL_Provisioning_RedirectApplied to the Centralized Web Auth setting.
ACL_ProvisioningSent to the wireless controller via the Radius:Airespace-ACL-Name attribute

value (AV).
The behavior of the two ACLs is slightly different between wireless controllers:
For CUWN wireless controllers (e.g., CT5508 and Flex 7500), ACL_Provisioning_Redirect
functions as both the ACL which controls web redirection and as the ACL which controls access on
the network. ACL_Provisioning serves simply as an extra security configuration and is not used
when URL redirection is specified. For CUWN wireless controllers the ACL_Provisioning
_Redirect ACL shown in Figure 10-32 can be the same as the ACL_Provisioning.
10-25
Chapter 10
Note
For Cisco IOS XE based wireless controllers (e.g., CT5760 and Catalyst 3850),
ACL_Provisioning_Redirect functions strictly as the ACL which controls web redirection.
ACL_Provisioning functions as the ACL, which controls what the wireless client is allowed to
access on the network. Hence IOS XE based wireless controllers make use of both ACLs when URL
redirection is specified.
The ACL behavior has changed in version 7.5+ of the Wireless LAN Controller. The presence of an
Airespace ACL Name in the authorization profile affects the webauth redirect functionality for access
points operating in FlexConnect mode.
For FlexConnect deployments, the ACL_Provisioning Airespace ACL must be removed from the
configuration. This implies that there needs to be two independent authorization profiles for
provisioning: one for FlexConnect and CUWN wireless controllers and another one for and Converged
Access wireless controllers.
Refer to Appendix E, Airespace ACLs in WLC 7.5+ for sample configurations.
Figure 10-32 displays the configuration for ACL_Provisioning_Redirect on the WLC. This is just an
example, since each organization will have unique business policies and security requirements.
Figure 10-32
WLC Access List for Provisioning
Note
Access to Google Play.
Android devices require access to the Google Play Store to download the SPW package. Modify the ACL
to allow endpoints to download the SPW. Analyzing the DNS transactions between the DNS server and
the device is one approach to develop and troubleshoot ACL_Provisioning_Redirect.
On the Catalyst 3850 or the CT5760 Controller, the ACL_Provisioning_Redirect is defined as follows:
10-26
Chapter 10

ip access-list extended ACL_Provisioning_Redirect

deny
udp any eq bootpc any eq bootps
deny
udp any host 10.230.1.45 eq domain
deny
ip any host 10.225.49.15
deny
ip any 74.125.0.0 0.0.255.255
deny
ip any 173.194.0.0 0.0.255.255
deny
ip any 206.111.0.0 0.0.255.255
permit tcp any any eq www
Deny (do not redirect) IP access to and from the DNS server (10.230.1.45).
Deny (do not redirect) IP access to and from the ISE Server (10.225.49.15).
Deny (do not redirect) DHCP Access (bootpc and bootps).
Permit (redirect) TCP access to any web host.
Permit (redirect) TCP access to any secure web host.
Deny (do not redirect) all other access to the Internet.
Dual SSID Provisioning Authorization Rule

The Dual SSID Provisioning rule links the Wireless CWA authorization profile to the conditions that
authorize MAB devices into the Provisioning SSID, as shown in Figure 10-33. It includes two
conditions: Wireless_MAB and Provisioning_WLAN.
Figure 10-33
Dual SSID Authorization Rule
The Wireless_MAB condition is a predefined condition in ISE, while the Provisioning_WLAN condition
was defined from the menu Policy > Conditions > Simple Conditions, as shown in Figure 10-34.
10-27
Chapter 10
Figure 10-34
Provisioning_WLAN Condition
For the purposes of this CVD, the BYOD_Provisioning SSID number was defined as 3 during testing.
The simple condition Provisioning_WLAN matches when the SSID number is 3. The condition is
created to improve readability of the rules.

The native supplicant flow starts similarly regardless of device type by redirecting employees using a
supported personal device to the Guest portal where they are required to enter their user credentials.
From there, they are redirected to the Self-Provisioning portal to confirm their device information.
The Wireless NSP authorization profile is used in single SSID configurations to redirect devices to the
Guest portal using the PEAP authentication protocol.
To configure this authorization policy, click Policy > Policy Elements > Results > Authorization
Profiles, as shown in Figure 10-35.
10-28
Chapter 10

Figure 10-35
Wireless NSP Authorization Profile
The Wireless NSP authorization profile relies on two named ACLs previously defined in the Wireless
LAN Controller:
ACL_Provisioning_RedirectApplied to the Centralized Web Auth setting.
ACL_ProvisioningSent to the wireless controller via the Radius:Airespace-ACL-Name attribute

value (AV).
The behavior of the two ACLs is slightly different between wireless controllers:
For CUWN wireless controllers (e.g., CT5508 and Flex 7500), ACL_Provisioning_Redirect
functions as both the ACL which controls web redirection and as the ACL which controls access on
the network. ACL_Provisioning serves simply as an extra security configuration and is not used
when URL redirection is specified. For CUWN wireless controllers the ACL_Provisioning
_Redirect ACL shown in Figure 10-32 can be the same as the ACL_Provisioning.
For Cisco IOS XE based wireless controllers (e.g., CT5760 and Catalyst 3850),
ACL_Provisioning_Redirect functions strictly as the ACL which controls web redirection.
ACL_Provisioning functions as the ACL which controls what the wireless client is allowed to
access on the network. Hence IOS XE based wireless controllers make use of both ACLs when URL
redirection is specified.
10-29
Chapter 10
Note
Single SSID Provisioning Authorization Rule

The Single SSID Provisioning rule links the Wireless NSP authorization profile to the conditions that
authorize wireless devices authenticating via PEAP.
To force devices to the self-registration portal, a redirect URL is created with a unique Session ID and
pushed to the device:
https://ip:port/guestportal/gateway?sessionId=SessionIdValue&action=nsp
When the user launches a web browser, the device is redirected to the Self-Registration portal.
Figure 10-36 shows the authorization rule defined under the authorization policies. This rule includes
two conditions: Wireless_PEAP and Employee_WLAN.
Figure 10-36
Single SSID Provisioning Authorization Rule
Figure 10-37 shows the Wireless_PEAP compound condition in ISE, which includes these expressions:
Radius:Service-Type Equals Framed
Radius:NAS-Port-Type Equals WirelessIEEE 802.11
Network Access: EapTunnel Equals PEAP
10-30
Chapter 10

Certificate Authority Server
Figure 10-37
Wireless_PEAP Compound Condition
For the purposes of this CVD, the BYOD_Employee SSID number was defined as 1 during testing. The
simple condition Employee_WLAN matches when the SSID number is 1. The condition is created to
improve readability of the rules.
Figure 10-38
Employee_WLAN Condition

The Certificate Authority server is the central authority for distributing digital certificates. A Windows
2008 CA server was used as the CA server for this solution. This section focuses on:
Network Device Enrollment Service, which is Microsofts implementation of SCEP.
Certificate Templates and how to design them.
10-31
Chapter 10
NDES Server Configuration for SCEP

The Network Device Enrollment Service (NDES) is the Microsoft implementation of the SCEP, a
communication protocol that makes it possible for network devices to enroll for X.509 certificates from
a CA. To distribute and deploy digital x.509 client certificates to users, the Microsoft Network Device
Enrollment Service (NDES) was utilized in conjunction with a Microsoft CA Server. For more details
on how to implement NDES, see:
http://technet.microsoft.com/en-us/library/cc753784%28WS.10%29.aspx.
By default, the NDES service is configured to present one-time enrollment passwords for certificate
enrollment. The use of one-time passwords by the NDES service is typically used to allow network and
IT administrators to enroll certificates for network devices within the IT organization. However, in this
solution this feature is disabled because remote endpoints are authenticated by using their RSA SecurID
tokens.
Disabling the one-time password on the NDES server is configured in the following registry key:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MSCEP\EnforcePasswo
rd.
EnforcePassword value data is set to 0, which ensures no password is requested by NDES.
Note
Windows Server 2003, Microsoft SCEP (MSCEP) required a Resource Kit add-on to be installed on the
same computer as the CA. In Windows Server 2008, MSCEP support has been renamed NDES and is
part of the operating system. NDES may be installed on a different computer than the CA
(http://technet.microsoft.com/en-us/library/cc753784%28WS.10%29.aspx).
The NDES extension to IIS uses the registry to store configuration settings. All settings are stored under
one registry key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\MSCEP
Note
It is possible for the ISE to generate URLs which are too long for the IIS. To avoid this problem, the
default IIS configuration may be modified to allow longer URLs.
The following command should be run on a command line with administrative privileges:
%systemroot%\system32\inetsrv\appcmd.exe set config
/section:system.webServer/security/requestFiltering
/requestLimits.maxQueryString:"6044"
/commit:apphost
Certificate Template
Digital certificates can be used for different purposes like server authentication, secure email, encrypting
the file system, and client authentication. Hence it is important that a client is issued a certificate which
serves its purpose. For example, a web server may need a certificate for server authentication. Similarly,
a normal client needs a certificate mainly for client authentication. Therefore, certificate templates are
needed to properly distribute certificates to users based on their specific needs. In this solution, a security
template has been created on the Microsoft Windows 2008 CA server so that users can obtain the proper
certificate. This section describes important steps to set up the certificate template on the Windows CA
server and specific actions needed by the user.
10-32
Chapter 10

For more information on certificate templates, see:

http://technet.microsoft.com/en-us/library/cc730826%28WS.10%29.aspx.
SCEP is used as a protocol by the endpoints to obtain their digital certificates from the CA server. The
endpoints send the certificate requests to ISE, which forwards the requests to the CA server. ISE is
configured as SCEP Proxy to handle these requests and once the CA server issues the certificates, ISE
sends the certificates back to the clients. The properties of the User template are being used. That is a
default template in the Microsoft Server 2008 R2 CA Server deployment. Default templates in Microsoft
Server 2008 R2 cannot be edited. Therefore, a customized template can be built that gives an
administrator more flexibility in defining the certificate options. This section describes how to create a
customized template named user2 in this example.
The first step is to create a duplicate template from the pre-defined list of templates. Figure 10-39 shows
how to create a duplicate template.
Figure 10-39
Creating a Duplicate Template
The default User template was copied and renamed user2. Then the user2 template was used to
auto-enroll AnyConnect VPN clients with client certificates using this newly created template.
The next step is to configure the extensions of the certificates that are derived from the user2 template.
The EKU extension and extended property specify and limit the valid uses of a certificate. The
extensions are part of the certificate itself. They are set by the issuer of the certificate and are read-only.
Certificate-extended properties are values associated with a certificate that can be set in an application.
To obtain more information about extended properties, see:
http://msdn.microsoft.com/en-us/library/aa380252%28v=vs.85%29.aspx.
Figure 10-40 describes how to configure the extended properties for the certificates.
10-33
Chapter 10
Figure 10-40
Configuring Extended Properties for Certificates
Notice the template named user2. This value must be set in the registry as it correlates to the user2
template, which was copied from the User template in the Certificate Templates Console on the CA
Server.
Figure 10-41 describes how the registry setting must be modified to reflect the newly-created template
user2.
Figure 10-41
Modifying the Registry
Once the template has been duplicated, the permissions are set for the NDES_ServiceAccount on the
user2 template to Read and Enroll. Figure 10-42 displays the Read and Enroll permissions that have
been set for the NDES_ServiceAccount on the user2 template.
10-34
Chapter 10

Figure 10-42
Read and Enroll Permissions
Ensure that the newly created user2 template is available to be issued via the CA. Right click user2
and choose the newly-created User2 Certificate, as shown in Figure 10-43.
Figure 10-43
Ensuring Template is Available From CA
Now the certificate template is fully configured and can be used by users to submit enrollment requests.
Figure 10-44 shows a successful enrollment request to the user2 template that was submitted by a user,
jayrsa.
10-35
Chapter 10
Figure 10-44
Successful Enrollment Request
A successful auto-enrollment request has occurred on the CA Server. Notice that the requester name is
the NDES Service Account that is configured for Read and Enroll permissions and also notice that the
user2 certificate template was chosen.
10-36
11
CH AP TE R

The previous sections discussed how BYOD devices can be on-boarded to the network and also how
different policies can be enforced for mobile devices using wireless medium. This section discusses how
to design and configure on-boarding and enforcing network access policies for wired devices. These
devices can be located at Campus or at Branch location. Moreover, wired devices can connect using
either converged access layer switches or by using non-converged access layer switches. This section
discusses the design and configuration details for following network architectures:
Campus (Both Converged Access and non-Converged Access)
Branch (Both Converged Access and non-Converged Access)
Campus Wired Design

At the campus location there are 802.1X-capable clients that go through the provisioning/enrollment
process and there are other types of devices like printers, cameras, etc. which do not have 802.1X
capabilities and can only provide their MAC address as their source of authentication. These devices also
will need to access the network and this design allows them to authenticate/authorize and obtain their
authorization policy from ISE. Figure 11-1 shows an end-to-end network architecture diagram that
includes wired device access from campus:
Figure 11-1
Network Diagram for Wired Devices at Campus Location
Campus
dot1x Devices
Data Center
Enrollment and
Provisioning
ISE
Core
MAB Devices
Access:
AD
CA
294153
IP
11-1
Chapter 11
Campus Wired Design
VLAN Design for Wired Switches at Campus

In the campus BYOD wired designs presented in this document, the VLAN assignment is same for all
types of accessFull, Partial, or Internet. This means that the VLAN assignment to the port does not
change when the device accessing the port changes. For example, the corporate-owned asset and the
personal device would still use the same VLAN number. The policy enforcement is done by a DACL
which is pushed from the ISE for non-Converged Access switches. On the other hand, policy
enforcement in Converged Access switches is done using a named ACL instead of a DACL. To obtain
more information about the different types of DACLs or named ACLs, refer to Chapter 16, BYOD
Limited Use CaseCorporate Devices or Chapter 15, BYOD Enhanced Use CasePersonal and
Corporate Devices. The following is an example configuration of Layer 2 interface of the access layer
switch and is the same either on centralized campus or a converged access campus switch:
switchport access vlan 42
! VLAN used in this design is 42
switchport mode access
ip access-group ACL-DEFAULT in
authentication event fail action next-method
authentication host-mode multi-auth
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
authentication violation restrict
mab
dot1x pae authenticator
dot1x timeout tx-period 3
spanning-tree portfast
IP Address Design for Campus Wired Infrastructure

In the campus wired network designs discussed in this design guide, the access layer switch performs
Layer 2 functions only. The aggregation switch performs Layer 3 routing. The following is an example
of part of the configuration of the Layer 3 aggregation switch:
ua31-6500-1#show running-config interface vlan 42
Building configuration...
Current configuration : 91 bytes
!
interface Vlan42
ip address 10.207.42.1 255.255.255.0
end
ua31-6500-1#
As seen above, the Layer 3 interfaces are configured with the ip-helper address command, which helps
clients obtain an IP address. For the purposes of this design guide, the DHCP server is located in the data
center.
Policy Enforcement in the Campus for Wired Devices

ACLs are the primary method through which policy enforcement is done at access layer switches for
wired devices within the campus. There are two distinct sets of ACLs used:
11-2
Chapter 11

Campus Wired Design
ACLs for managing the deviceThese ACLs are used for provisioning the device or managing the
device like Blacklisting.
ACLs that are mainly for enforcing the policies.
The policy enforcement method at campus non-Converged Access switches is done by defining DACLs
in the ISE based on the authZ policy and pushing that DACL to the port on the access layer switch. In
Converged Access switches, policy enforcement is done through a named ACL sent by the ISE based on
the authZ policy. The named ACL must be previously configured on the Converged Access Catalyst 3850
switch. To obtain more information on the authZ profiles used in this design guide, refer to either
Chapter 16, BYOD Limited Use CaseCorporate Devices or Chapter 15, BYOD Enhanced Use
CasePersonal and Corporate Devices.
ACL Design for Campus Access Layer Switches

This section discusses the set of ACLs that are used for provisioning devices onto the network, protecting
against unauthorized access, and blacklisting the device. The ACLs discussed in this section apply to
both Converged access layer switches and non-converged access layer switches. Table 11-1 summarizes
these ACLs and their purpose.
Table 11-1
Campus ACLs and Purpose
ACL Name
Where it Applies
Purpose
ACL-DEFAULT
Access Layer Switch
To protect against unauthorized

access through the switch port
ACL_Provisioning
ISE
To allow an endpoint access to

complete on-boarding process
ACL_Provisioning_Redirect
Access Layer Switch
Redirect web traffic initiated by

new devices accessing the
network. This ACL is a named
ACL that is present on the access
layer switch.
ACL_BLACKHOLE_Redirect
Access Layer Switch
Redirect web traffic initiated by

black listed devices
ACL-DEFAULTThis ACL is configured on the access layer switch and used as a default ACL on the
port. Its purpose is to prevent un-authorized access. In an 802.1X authentication/authorization scenario,
after the device is authenticated and authorized, if there is no DACL applied to the port or if there is a
mistake in the syntax of the downloadable ACL and the switch rejects the DACL sent by ISE,
ACL-DEFAULT protects the port in the above mentioned scenarios. In the converged access design, the
ACL is a named ACL and is configured on the Catalyst 3850 switch. The ISE sends the name of the ACL
to be applied at the port. Again, if the switch rejects the named ACL sent by ISE, ACL-DEFAULT
protects the port.
An example of a default ACL on a campus access layer switch is shown below:
Extended IP access list ACL-DEFAULT
10 permit udp any eq bootpc any eq bootps log (2604 matches)
20 permit udp any host 10.230.1.45 eq domain
30 permit icmp any any
40 permit udp any any eq tftp
50 deny ip any any log (40 matches)
11-3
Chapter 11
Campus Wired Design
As seen from the output above, ACL-DEFAULT allows DHCP, DNS, ICMP, and TFTP traffic and denies
everything else.
ACL_Provisioning_RedirectThis ACL is used during on-boarding of wired devices. The ACL
triggers a redirection upon HTTP or HTTPS traffic from the client to anywhere, which means that when
the user opens a web browser and attempts to access any website, that traffic is re-directed. The example
shown below redirects any web traffic initiated by the user. However, this ACL can be modified to allow
only certain traffic to be redirected to ISE portal. The underlying assumption in this design is that all the
devices must be registered with ISE, therefore when an un-registered device accesses the network, it is
redirected to ISE.
An example of ACL_Provisioning_Redirect ACL on a campus switch is shown below:
Extended IP access list ACL_Provisioning_Redirect
10 deny udp any eq bootpc any eq bootps log
20 deny udp any host 10.230.1.45 eq domain (43 matches)
30 deny ip any host 10.225.42.15 (27 matches)
40 permit tcp any any eq www (30 matches)
50 permit tcp any any eq 443 (240 matches)
ACL_BLACKHOLE_RedirectThis ACL is used to redirect devices that have been blacklisted to the
ISE portal to let the user know that the device in use has been blacklisted. This ACL is similar to the
ACL_Provisioning_Redirect ACL.
An example of ACL_BLACKHOLE_Redirect on a campus switch is shown below:
Extended IP access list ACL_BLACKHOLE_Redirect
10 deny udp any eq bootpc any eq bootps
20 deny udp any host 10.230.1.45 eq domain
35 deny ip any host 10.225.49.15
40 permit ip any any
Note
The converged access layer switches use the same ACL_BLACKHOLE_Redirect for redirecting black
listed wired devices.
Provisioning ACL
This ACL is also used during the on-boarding of wired devices. This DACL is downloaded from the ISE
and restricts access to only the ISE, DNS, and DHCP server. This ACL is defined on the ISE, as shown
in Figure 11-2.
11-4
Chapter 11

Campus Wired Design
Figure 11-2
Note
ACL_Provisioning
The ACL_Provisioning ACL is also used for Converged access layer switches.
802.1X and AAA Configuration for Campus Switches

A Cisco Catalyst Switch is used to provide end user Ethernet connectivity into the network in this design
guide. The access layer switch enables 802.1X authentication for the client devices and interacts with
the Identity Services Engine using the RADIUS protocol. Based on the results from the authentication
process, a user may be allowed restricted or full access into the network using a VLAN assignment and
a downloadable Access Control List (DACL). The flex-authentication configuration described below
allows for using both 802.1X and MAC Authentication Bypass (MAB) as a fallback mechanism.
Flex-auth is useful for devices that do not have 802.1X support such as printers.
This section discusses on the configuration details of enabling AAA on the campus access layer
switches, and these switches can be either converged access layer switches non-converged access layer
switches.
The following steps are required to configure the access switch for AAA on the Campus Switch:
Step 1
Enable Authentication, Authorization, and Accounting (AAA):

ACL(config)# aaa new-model
Step 2
Create an authentication method for 802.1X (default use all RADIUS servers for authentication):
ACL(config)# aaa authentication dot1x default group radius
Step 3
Create an authorization method for 802.1X (enables RADIUS for policy enforcement):
ACL(config)# aaa authorization network default group radius
11-5
Chapter 11
Campus Wired Design
Step 4
Create an accounting method for 802.1X (provides additional information about sessions to ISE):
ACL(config)# aaa accounting dot1x default start-stop group radius
The following steps are required to configure the access switch for RADIUS:
Step 1
Add ISE server to the RADIUS group:

ACL(config)# radius-server host 10.225.49.15 auth-port 1812 acct-port 1813 key
shared-secret
Step 2
Configure ISE server dead time ( 15 seconds total-3 retries of 5 second timeout):
ACL(config)# radius-server dead-criteria time 5 tries 3
Step 3
Configure the switch to send Cisco Vendor-Specific attributes:

ACL(config)# radius-server vsa send accounting
ACL(config)# radius-server vsa send authentication
Step 4
Configure the Cisco Vendor-Specific attributes:

ACL(config)# radius-server attribute 6 on-for-login-auth
ACL(config)# radius-server attribute 8 include-in-access-req
ACL(config)# radius-server attribute 25 access-request include
Step 5
Configure IP address to be used to source RADIUS messages:

ACL(config)# ip radius source-interface interface-name Vlan4093
The following steps are required to configure the access switch for 802.1X:
Step 1
Enable 802.1X globally (command by itself does not enable authentication on the switchports):
ACL(config)# dot1x system-auth-control
Step 2
Enable IP device tracking:

ACL(config)# ip device tracking
The following interface level commands enable 802.1X for Flex-Auth:

Step 1
Configure the authentication method priority (dot1x has higher priority over MAB):
ACL(config-if)# authentication priority dot1x mab
Step 2
Configure the authentication method order (dot1x first):

ACL(config-if)# authentication order dot1x mab
Step 3
Enable Flex-Auth:
ACL(config-if)# authentication event fail action next-method
Step 4
Enable support for more than one MAC address on the physical port:
ACL(config-if)# authentication host-mode multi-auth
11-6
Chapter 11

Branch Wired DesignNon-Converged Access
Step 5
Configure the violation action (restrict access for additional devices that may fail authentication):
ACL(config-if)# authentication violation restrict
Step 6
Enable port for 802.1X:

ACL(config-if)# dot1x pae authenticator
Step 7
Enable port for MAB:

ACL(config-if)# mab
Step 8
Configure timers (30 seconds (10x3) until falling back to MAB):

ACL(config-if)# dot1x timeout tx-period 3
Step 9
Turn authentication on:

ACL(config-if)# authentication port-control auto
Step 10
Enable the ACL-DEFAULT to the port

ACL(config-if)# ip access-group ACL-DEFAULT in
Step 11
Enable http and https server:

ACL (config)# ip http-server
ACL (config)# ip http secure-server

At a branch location, there are 802.1X capable clients that go through the provisioning/enrollment
process and there are also other types of devices such as printers, cameras, etc. which do not have 802.1X
need to access the network and this design allows them to authenticate/authorize and obtain their
authorization policy from ISE. This section discusses wired designs for branches which do not deploy
Converged Access (Catalyst 3850) switches. The branch wired design discussed in this section is meant
to accompany FlexConnect-based wireless branch designs. The Converged Access branch wired design
is discussed in Branch Wired DesignConverged Access.
Figure 11-3 shows an end-to-end network architecture diagram that includes wired device access from
the branch.
11-7
Chapter 11
Figure 11-3
Network Diagram for Wired Access at Branch Location
Branch
dot1x Devices
Data Center
Enrollment and
Provisioning
ISE
WAN
MAB Devices
Access:
AD
CA
294155
IP
VLAN Design at Branch Locations

Four VLANs are implemented for wired devices at the non-Converged Access branch location.
Table 11-2 illustrates the names of these VLANs and their purpose.
Table 11-2
VLANs and their Purpose
VLAN Name
VLAN Number Description
Wired_Full
13
Devices placed in this VLAN get full access to corporate resources

and branch local servers.
Wired_Partial
14
Devices placed in this VLAN get restricted access to resources.
Wired_Internet 15
Devices placed in this VLAN get only Internet access only.
Branch_Server 16
Local Servers at branch location are placed in this VLAN.
IP Address Allocation at Branch Location

In the non-converged access branch network design discussed in this design guide, the switch performs
Layer 2 functions only and the branch router performs Layer 3 routing. Hence, all the Layer 3 interfaces
for the VLANs mentioned above are implemented at the branch router. The following is an example
configuration of the branch router:
ip address 10.200.13.2 255.255.255.0
standby 13 ip 10.200.13.1
standby 13 preempt
!
ip address 10.200.14.2 255.255.255.0
ip access-group Branch1_ACL_Partial_Access in
standby 14 ip 10.200.14.1
11-8
Chapter 11

standby 14 preempt
!
ip address 10.200.15.2 255.255.255.0
ip access-group ACL_Internet_Only in
standby 15 ip 10.200.15.1
standby 15 preempt
!
ip address 10.200.16.2 255.255.255.0
standby 16 ip 10.200.16.1
standby 16 preempt
!
branch clients obtain an IP address. For the purposes of this design guide, the DHCP server is in a data
center location.
Policy Enforcement in the Branch for Wired Devices

wired devices within the branch. There are two distinct sets of ACLs used:
When designing the ACLs for branch the following should be considered:
Configuring static ACLs at every branch router in the network.
Configuring the ISE to push downloadable ACLs to access layer switches at every branch location.
Table 11-3 gives the advantages and disadvantages of each approach.

Table 11-3
ACL Policy Enforcement
Method
Advantages
Disadvantages
Static ACLs
Modify the ACL based on

the branchs needs
Hard to manage each branch policy individually
Downloadable ACLs Centralized access control
Creating an individual policy at ISE for every

branch location would make the policy very large
from an administrative perspective.
For example, to manage 500 unique branches,
500 ACLs, 500 authZ profiles, and 500 authZ
policy rules would need to be defined on the ISE.
Each of the above methods has advantages and disadvantages. This design guide focuses on a
combination that includes both methods. The static ACLs are the primary method by which access is
restricted. However, the static ACLs are applied at the router only; to override the ACL called
11-9
Chapter 11
DEFAULT-ACL which is present on every port of the access layer switch, a DACL (permit all traffic)
is downloaded from ISE. This DACL from the ISE allows the traffic to flow upstream from the access
layer switch to the Branch router. The Branch router is pre-configured with the different ACLs that
restrict access. These ACLs either provide full, partial, or Internet access to the users.
Figure 11-4 shows how the authorization policy pushes the VLAN information and the DACL (permit
all traffic) to the port on the access layer switch, thereby allowing the traffic to reach from the access
layer switch up to the router where the traffic will be filtered.
Figure 11-4
Enforcing Permissions
Local VLANs
dACL
293028
Static ACL
ACL Design at Branch Location

ACLs are very important at the branch location, since they are the main method used to enforce policies.
Some ACLs are defined on the Layer 2 switch for provisioning purposes, while others are defined on the
branch router. In addition, some ACLs may be downloaded from the ISE.
Table 11-4 summarizes the various ACLs at branch locations and their purpose.
Table 11-4
Branch ACLs and Purpose
ACL Name
Where it Applies Purpose
ACL_DEFAULT
Switch
ACL_Provisioning_Redirect Switch
Redirect web traffic initiated by new devices

accessing the network.
ACL_Blackhole
Switch
Redirect web traffic initiated by black listed devices
ACL_Internet_Only
Branch Router
Allow only Internet traffic
ACL_Provisioning
ISE
Used during provisioning process
ACL_Partial_Access
Branch Router
Allow partial access to certain resources
11-10
To protect against unauthorized access through the

switch port
Chapter 11

ACL_DEFAULTThis ACL is used as a default ACL on the port and its purpose is to prevent
un-authorized access. In an 802.1X authentication/authorization scenario, after the device is
authenticated and authorized, if there is no DACL applied to the port or if there is a mistake in the syntax
of the downloadable ACL and the switch rejects the DACL sent by ISE, ACL_DEFAULT protects the
port in the above mentioned scenarios. An example of a default ACL is shown below:
bn22-3750x-1#show ip access-lists
Load for five secs: 13%/0%; one minute: 16%; five minutes: 16%
Time source is NTP, 16:24:50.872 EDT Wed Sep 19 2012
Extended IP access list ACL-DEFAULT
10 permit udp any eq bootpc any eq bootps
20 permit udp any any eq domain
50 deny ip any any log
As seen from the output above, ACL_DEFAULT allows DHCP, DNS, ICMP, and TFTP traffic and denies
everything else.
ACL_Provisioning_RedirectThis ACL is used during the on-boarding of wired devices. This ACL
shown below redirects any web traffic initiated by the user. However this ACL can be modified to allow
redirected to ISE.
uasl-3750x-1#show ip access-lists | begin ACL_Provisioning_Redirect
10 deny udp any eq bootpc any eq bootps log
20 deny udp any host 10.230.1.45 eq domain (1865 matches)
50 permit tcp any any eq www (3728 matches)
60 permit tcp any any eq 443 (4140 matches)
uasl-3750x-1#
Provisioning ACL
This ACL is also used during the on-boarding of wired devices. This DACL is downloaded from the ISE
and restricts access to only the ISE, DNS, and DHCP server. This ACL is defined on the ISE, as shown
in Figure 11-5.
11-11
Chapter 11
Branch Wired DesignConverged Access
Figure 11-5
ACL_Provisioning
802.1X and AAA Configuration for Branch Switches

The configuration of 802.1X and AAA for branch non-Converged Access switches is exactly identical
to the campus switches. Refer to 802.1X and AAA Configuration for Campus Switches for details.

At a branch location, there are 802.1X capable clients that go through the provisioning/enrollment
process and there are other types of devices like printers, cameras, etc. which do not have 802.1X
need to access the network and this design allows them to authenticate/authorize and obtain their
authorization policy from ISE. This section discusses wired designs for branches that deploy Converged
Access (Catalyst 3850) switches.
Figure 11-6 shows an end-to-end network architecture diagram that includes wired device access from
the branch.
11-12
Chapter 11

Figure 11-6
Network Diagram for Wired Devices at Branch Location Using Converged Access
Switches
Branch
dot1x Devices
Catalyst 3850
Data Center
Enrollment and
Provisioning
ISE
WAN
MAB Devices
Access:
AD
CA
294157
IP
VLAN Design at Branch Locations

In the Branch BYOD wired designs presented in this document, the VLAN assignment is same for all
types of accessFull, Partial, or Internet. This means that the VLAN assignment to the port does not
change when the device accessing the port changes. For example, the corporate-owned asset and the
personal device would still use the same VLAN number. The policy enforcement in Converged Access
switches is done using a named ACL instead of a DACL. Different named ACLs are applied to each
device granting different access to the network. Since the named ACL is configured on the Catalyst 3850
switch specific to the particular branch, a single Cisco ISE policy can be implemented across multiple
branches. However the Access Control Entries (ACEs) within the ACL for each branch can be unique to
the IP addressing of the branch. This reduces the administrative complexity of the Cisco ISE policy,
albeit at the expense of increased complexity of having to configure and maintain ACLs at each branch
Catalyst 3850 Series switch.
Three VLANs are implemented for wired devices at the Converged Access branch location. Table 11-5
illustrates the names of these VLANs and their purpose.
Table 11-5
VLANs and their PurposeConverged Access
VLAN Name
VLAN Number Description
BYOD_Employee
10
Devices in this VLAN get access to either full, partial or limited

access based on named ACL.
BYOD_Provisioning 11
Provisioning VLAN
Branch_Server
Local Servers at branch location are placed in this VLAN.
16
IP Address Allocation at Branch Location

In the converged access branch network design discussed in this design guide, the Catalyst 3850 switch
performs Layer 2 functions only. There is no branch router, unlike Branch Wired design for
non-Converged Access. The following is an example configuration of a Layer 2 interface of the access
layer switch and is the same on either a centralized campus or a converged access campus switch:
! VLAN used in this design is 42
11-13
Chapter 11

mab
Layer 3 connectivity within the branch is provided by the ISR routers that also serve as the WAN
connectivity point for the branch. The following is an example of part of the configuration of the Layer
3 router:
ua31-6500-1#show running-config interface vlan 42
Building configuration...
Current configuration : 91 bytes
!
interface Vlan42
ip address 10.207.42.1 255.255.255.0
end
branch clients obtain an IP address.
Policy Enforcement at the Branch Using Converged Access Switches

wired devices within the branch. There are two distinct sets of ACLs used:
In Converged Access switches, policy enforcement is done through a named ACL sent by the ISE based
on the authZ policy. The named ACL must be previously configured on the Converged Access Catalyst
3850 switch. To obtain more information on the authZ profiles used in this design guide, refer to either
Chapter 16, BYOD Limited Use CaseCorporate Devices or Chapter 15, BYOD Enhanced Use
CasePersonal and Corporate Devices.
ACL Design at Branch Location for Converged Access Switches

This section discusses both sets of ACLs that are important for a converged access layer switch at a
branch location:
ACL that are used for provisioning.
ACLs that are used for policy enforcement.
Table 11-6 summarizes the various ACLs in the Converged Access branch wired branch design and their
purpose.
11-14
Chapter 11

Table 11-6
Branch ACLs and Purpose
ACL Name
Where it Applies Purpose
ACL_DEFAULT
Switch
To protect the switch port
ACL_Blackhole
Switch
Redirect web traffic initiated by black listed devices
ACL_Internet_Only
Switch
Allow only Internet traffic
ACL_Provisioning
ISE
Used during provisioning process
ACL_Partial_Access Switch
Allow partial access to certain resources
ACL_Full_Access
Allow full access to all resources
Switch
ACL_DefaultThis ACL is used as a default ACL on the port and its purpose is to prevent
un-authorized access. In the Converged Access Design this is done through a named ACL approach. The
ACL_DEFAULT resides on the Catalyst 3850 switch.
Extended IP access list ACL_DEFAULT
10 permit udp any eq bootpc any eq bootps
20 permit udp any any eq domain
50 deny ip any any
As seen from the output above, ACL_DEFAULT allows DHCP, DNS, ICMP, and TFTP traffic and denies
everything else.
ACL_Provisioning_RedirectThis ACL is used during the on-boarding of wired devices. This ACL
shown below redirects any web traffic initiated by the user. However, this ACL can be modified to allow
redirected to ISE.
deny
deny
deny
ip any host 10.225.49.15
ACL_ProvisioningThis ACL is also used during the on-boarding of wired devices. This DACL is
downloaded from the ISE and restricts access to only the ISE, DNS, and DHCP server. This ACL is
defined on the ISE, as shown in Figure 11-7.
11-15
Chapter 11
Figure 11-7
ACL_Provisioning
802.1X and AAA Configuration for Branch Switches

The configuration of 802.1X and AAA for branch switches is exactly identical to the campus switches.
Refer to 802.1X and AAA Configuration for Campus Switches.
MAB Devices at Branch or at Campus Location

This section discusses how to design access for MAB devices using either converged access switches or
traditional access layer switches. MAB devices can be present at either branch or campus locations.
MAB devices are generally those devices that cannot run 802.1X and can only present their mac-address
for authentication. It is important to note that BYOD devices also use the MAB protocol during the
provisioning process. During the provisioning process, BYOD devices are re-directed to the ISE guest
portal to complete the registration process. MAB devices do not need to be registered and therefore do
not need to be re-directed. The requirement for MAB devices is to authenticate the device and apply an
authorization policy. Here are the high level steps that need to be performed for MAB devices:
1.
Configure the access layer switch port or WLC to support the MAB protocol.
2.
Import a MAC-address list of all MAB devices as an Identity group in ISE.
3.
Configure an authentication policy for Wired and Wireless MAB devices. This same policy will be
used to authenticate BYOD devices during provisioning.
4.
Configure authorization policy rules in ISE for wired and wireless devices.
When a MAB device connects, the access layer switch sends the authentication request to the ISE using
the MAC-address of the device as the source of authentication. An example is shown below.
Sep 25 11:09:50.741: %DOT1X-5-FAIL: Authentication failed for client (0050.568f.
1bb2) on Interface Gi1/0/10 AuditSessionID 0AC8130400000221292C2D59
11-16
Chapter 11

Sep 25 11:09:50.741: %AUTHMGR-7-RESULT: Authentication result 'no-response' from

'dot1x' for client (0050.568f.032b) on Interface Gi1/0/10 AuditSessionID 0AC813
0400000221292C2D59
Sep 25 11:09:50.749: %AUTHMGR-7-FAILOVER: Failing over from 'dot1x' for client
0050.568f.032b) on Interface Gi1/0/10 AuditSessionID 0AC8130400000221292C2D59
Sep 25 11:09:50.749: %AUTHMGR-5-START: Starting 'mab' for client (0050.568f.032b
) on Interface Gi1/0/10 AuditSessionID 0AC8130400000221292C2D59
In this design, all the MAC addresses of MAB devices are placed in an internal identity group called
MAB_DEVICES so ISE will know this device in advance. To add new MAC addresses to the
MAB_DEVICES identity group, click Administration > Groups > Endpoint Identity Groups, as
Figure 11-8
MAB_DEVICES Identity Group
Figure 11-9 shows the authentication policy defined on the ISE for wired MAB devices.
Figure 11-9
WIRED MAB AuthC
The authorization policy is different for MAB devices originating in the branch design with FlexConnect
versus in the campus location. In the branch design in a FlexConnect model, every device is placed in
different VLANs, but this is not done in the campus or a branch design with converged access. Hence
there are different rules that are defined in the authZ policy to take care of location of the device-branch
versus campus. Figure 11-10 shows how the policy rules are defined for campus devices.
11-17
Chapter 11
Figure 11-10
Authorization Policy for MAB devices
Campus Wired MAB is an authorization profile that pushes the appropriate settings to the access layer
switch. Figure 11-11 shows the authorization profile details.
Figure 11-11
Campus Wired MAB Authorization Profile
11-18
Chapter 11

The Campus Wired MAB authorization profile does not push VLAN information, but rather applies a
DACL to the port. The Converged Access design uses the same authorization profile as shown in the
Figure 11-11. Also note that in the Converged Access design, for the authorization profile, a DACLs is
used for both Campus and Branch designs.
Conversely, Branch_Wired_MAB authorization profile pushes the VLAN information to the access port
on the wired switch for designs with branch with FlexConnect. Figure 11-12 shows the
Branch_Wired_MAB profile configuration.
Figure 11-12
Branch_Wired_MAB Authorization Profile
The Converged Access Branch Design also uses same authorization profile for MAB devices as shown
in the Figure 11-12.
11-19
Chapter 11
11-20
CH AP TE R
12

Whats New: In the previous version of the BYOD CVD, TrustSec in the use of security group tags was
addressed in a Centralized Unified Wireless Design within a campus, where users attaching to the
wireless network based on authentication credentials in the respective authorization were assigned a
security group tag.
In this version of the BYOD CVD, the use of security group tags as a means for enforcing policy is
expanded to include a Centralized Unified Wireless Design incorporating the Cisco CT 5760 wireless
controller as well as in a Converged Access infrastructure using the Cisco Catalyst 3850. In the CUWN
design both the CT 5508 and the CT 5760 wireless controllers are used in parallel to terminate wireless
devices in the campus. Additionally, policy enforcement for wireless access via the Catalyst 3850 and
its integrated controller, when deployed in the campus access layer, is expanded to include the use of
security group tags in addition to access control lists used in the previous version of the BYOD CVD.
As in the previous version of the BYOD CVD, this version continues to demonstrate the use of security
group tags for policy enforcement in the same two scenarios using both SG ACLs on Nexus and Catalyst
switches for the first scenario and the ASA security appliance in conjunction with the Security Group
Firewall (SG-FW).
The following section describes the infrastructure used in this CVD and provides an outline of the two
deployment scenarios used to enforce policies based on Security Group Tags. These deployment
scenarios are not mutually exclusive and may be used together to satisfy an organizations requirements.
Configuration details for the infrastructure are also provided.
Unified Infrastructure Design to Support SGA

In this current version of the BYOD CVD, Security Group Tags are used as a means to enforce role-based
access policies for Campus wireless users (as in the previous version of this CVD). New to this CVD
however is the introduction of the CT-5760 wireless controller as well as the Catalyst 3850 for campus
wireless access and the ability to natively tag traffic accessing the network through these devices. Two
specific infrastructure deployment scenarios are examined in this CVD. The first use case makes use of
TrustSec Policy defined at the Identity Services Engine and the resulting SGACLs being dynamically
exchanged with the Catalyst 6500 and 3850 switches, the CT-5760 wireless controller, and the Nexus
7000 infrastructure. The second use case once again makes use of the TrustSec Policy defined at the
Identity Services Engine, but policy is enforced through the configuration of Security Group Firewall
(SG-FW) policies defined on an ASA providing secure access to data center resources.
12-1
Chapter 12
The wireless access design using the CT-5508 wireless controller validated in the previous release of this
CVD will continue to be used to support access to data center resources by wireless devices using the
CT-5508 instead of the CT-5760, identical to that demonstrated in the previous release of this CVD.
Figure 12-1 depicts the infrastructure that is used for purposes of SGA validation within the CVD.
Figure 12-1
TrustSec Infrastructure for BYOD v2.5 CVD
Services
Data Center
DNS
DHCP
Nexus
7000 VPC
DC Core
CT5508
WLCs
CA
AD
Nexus
5000 VPC
DC Agg
CT5760
WLCs
Core
Cisco
ASA
Distribution
Switch
Catalyst
3750-X
Application and
File Servers
CTS Man Mode and MACsec

CTS Man Mode without MACsec
Catalyst 3850
Switch Stack
Aggregation/Access and Campus Wireless
294945
3600 AP Module
3600 AP Module
(802.11ac/n)
(802.11ac/n)
CAPWAP
CAPWAP
In Figure 12-1, the links extending between the Catalyst 6500 VSS in Shared Services to the Catalyst
6500 VSS in the core and extending to the Nexus 7000 are 10GE links. On the Catalyst 6500s,
WS-X6904 linecards with the FourX Adapters provide the 10GE interfaces while the N7K-M108X2-12L
and N7K-F248XP-25E linecards (last eight ports) provide the Nexus 7000 interfaces. The links between
the Nexus 7000 and the Nexus 5548 are likewise connected to N7K-M108X2-12L linecards at the Nexus
7000 and 10GE ports on the Nexus 5548. All other network connectivity for wireless controllers, ASA
firewalls, ISE, and the miscellaneous servers depicted are 1GE links.
12-2
Chapter 12

Policy Configuration for SGACLs in Scenario 1

For Deployment Scenario 1, refer to Figure 12-2.
Infrastructure Deployment Scenario 1 SGT Enforcement
Campus Wireless
Data Center
Application
and File
Servers
ISE
RSA
AD
CA
DC Agg
DC Agg
STOP
CAPWAP
CAPWAP
CAPWAP
STOP
CAPWAP
ASA HA
Primary
ASA HA
Secondary
DC Core
Catalyst
3750X
DNS
and
DHCP
DC Core
Catalyst
STOP 3850X
Core
Services
STOP
5760
STOP
5508
294946
Figure 12-2
SXP
CAPWAP
In this first scenario, wireless users, upon successful authentication and authorization, will be associated
with a specific role and an IP to SGT mapping will be created on the wireless controller with the devices
IP Address and the appropriate SGT. In Deployment Scenario 1 wireless device traffic will have the SGT
inserted at different networking devices and this insertion point is dependent on which wireless
controller the device is terminating at for network access.
Table 12-1 summarizes where the SGT will be inserted.
Table 12-1
SGT Insertion
Architecture Wireless Controller Device
Explanation
Converged
3850
3850 switches
3850 Switch supports inline tagging

capability
Centralized
5760
5760 wireless controller 5760 wireless controller supports inline

tagging capability
Centralized
5508
6500 Shared Services
5508 does not support in-line tagging.

Therefore SXP is used between 5508 and
6500. Tags imposed at 6500.
12-3
Chapter 12
In Deployment Scenario 1, CUWN traffic with Security Group Tags will be forwarded from the Shared
Services Catalyst 6500 VSS where the wireless controllers are attached or from the 3850 converged
access switches connected to the Catalyst 6500 Distribution switch. These tags are then propagated
through the Core of the BYOD infrastructure en route to servers located in the data center. In
Figure 12-2, the links depicted in a solid green line will be configured for SGT forwarding as well as
manually configured for 802.1ae MACsec. Links with a dashed green line will be configured to support
SGT forwarding only as they do not support MACsec with current software but will in the future.
Note
As of IOS-XE 3.3.0, the Catalyst 3850 and CT-5760 wireless controller will impose and propagate the
SGT as well as enforce SGACLs. Although these platforms have the necessary ASICs for MACsec
support, the software has yet to be enabled as of the writing of this CVD.
As this traffic traverses the SGT-capable Core, this tag will be propagated hop-by-hop en route to the
Nexus 7000s that compose the data center switching infrastructure within which the various servers are
located. As shown in the Figure 12-3, a wireless user accessing the network using centralized wireless
architecture is assigned a tag value of 12 after successful authentication and authorization; similarly, a
wireless user accessing the network using a converged access medium is assigned a tag value of 10.
As 802.1X is not used to authenticate the servers residing in the Nexus data center infrastructure, the
server IP Address to SGT mapping can either be manually defined on the Nexus 7000 Data Center
Aggregation switch or at the ISE server which would subsequently push that mapping to the Nexus
7000. For purposes of the CVD, specific IP/SGT mappings have been manually defined on the Nexus
7000 data center Aggregation Switches as well as through the use of VLAN to SGT mapping.
As tagged user traffic arrives at the Nexus 7000 data center switch where the manual SGT mappings for
the servers have been created, the traffic will be matched against TrustSec Policy (SGACL) defined
either centrally at ISE or locally and will be either forwarded or dropped as applicable. For example, as
shown in Figure 12-3, the traffic with SGT 10 arriving from converged access wireless user with full
access is permitted by the Nexus aggregation switch and the traffic with SGT12 from a CUWN wireless
user who has partial access is denied access to the servers.
As discussed earlier, all SGT mappings for the servers have been manually created on the Nexus 7000
aggregation switches. As the servers are connected to the Nexus 5548 switches depicted in Figure 12-3,
traffic from the Nexus 5548s egresses untagged as no mappings have been created there. Once this traffic
passes through the Nexus 7000 Aggregation switch, the resident SGT mappings will be examined and
the appropriate SGT imposed upon egress from the aggregation switch. The SGT mappings can be
implemented on the Nexus 7000 via IP/SGT mapping or by VLAN/SGT mapping. The details for this
configuration are covered later in this document. In the event that traffic would be initiated by a server
associated with an SGT in the data center, the tagged traffic would then leave the Nexus 7000 data center
switches traversing the Catalyst 6500 Core and Shared Service infrastructure with the SGT propagated
at each hop towards the destination, the wireless controllers attached to the Shared Services 6500, or
wireless devices accessing the network through the Catalyst 3850s.
If destined for CUWN wireless controllers, upon arrival at the Shared Services 6500, the traffic will be
matched against local TrustSec Policy (SGACL) and will be either forwarded or dropped depending on
the controller to which it is destined. If destined for the CT-5508, SGACL policies will be enforced at
the Shared Services C6500 VSS as the CT-5508 does not support tagging or SGACLs and only advertises
the IP/SGT mappings to the Shared Services C6500 VSS for enforcement. If destined for the CT-5760
with its support for SGT tagging and SGACLs, the IP/SGT mappings for those devices accessing the
network at the CT-5760 will be created and stored at the 5760 and hence the SGACL enforced there as
well.
If destined for the Catalyst 3850 and the converged access wireless users, the SGACL policy will be
enforced on the Catalyst 3850 to which the wireless user is associated.
12-4
Chapter 12

Figure 12-3
Policy Enforcement in Deployment Scenario 1
Campus Wireless
Data Center
Application
and File
Servers
SGT50
ISE
RSA
AD
CA
DC Agg
DC Agg
STOP
CAPWAP
CAPWAP
CAPWAP
STOP
CAPWAP
ASA HA
Primary
ASA HA
Secondary
DC Core
Catalyst
3750X
SGT12
DNS
and
DHCP
DC Core
Catalyst
STOP 3850
Core
Services
STOP
SGT12
5760
5508
STOP
SXP
294916
SGT12
CAPWAP
Policy Configuration in Scenario 2

For the topology used in Deployment Scenario 2, refer to Figure 12-4.
12-5
Chapter 12
Figure 12-4
Deployment Scenario 2 Configuration
Campus Wireless
Data Center
SGT50
Application
and File
Servers
ISE
RSA
AD
CAPWAP
CAPWAP
CAPWAP
CA
STOP
CAPWAP
STOP
ASA HA
Primary
SXP
Peering*
Catalyst
3750X
SGT12
DNS
and
DHCP
DC Agg
DC Agg
ASA HA
Secondary
DC Core
DC Core
Catalyst
3850X
Core
Services
SGT12
5760
5508
SXP
SXP Connections*
294947
SGT12
CAPWAP
With Deployment Scenario 2 an alternate means other than SGACLs will be used to enforce TrustSec
policy. In Scenario 2 an ASA running version 9.0(2) will be used as a Security Group Firewall (SG-FW)
securing data center resources from outside access. Unlike Scenario 1, the 10GE infrastructure between
the Shared Services Catalyst 6500 VSS and the data center does not need to be enabled to support
Security Group Tag forwarding or SGACLs. As the ASA does not presently support native SGT tagging
on its Ethernet interfaces, Security Group Tag Exchange Protocol (SXP) must be used for it to learn
IP/SGT mappings from other areas of the network where they have been dynamically learned or
statically configured. It is by virtue of these SXP advertisements that the ASA is capable of inspecting
the untagged traffic and, through the use of these IP/SGT mappings, that SG-FW policies are enforced
As in the case of the first deployment scenario, wireless users, upon successful authentication and
authorization, will be associated with a specific role and an IP to SGT Binding will be created on the
wireless controller with the devices IP Address and the appropriate SGT.
Once the IP/SGT mappings have been created upon wireless device access to the respective controller,
SXP will be used as the primary method through which these mappings are communicated to the ASA
firewall. As depicted in Figure 12-4, the 3850 converged access switches and both the CT-5760 and
CT-5508 wireless controllers must communicate their respective IP/SGT mappings to the ASA Firewall.
In this design we have chosen the following method to minimize the number of SXP tunnels needed to
the ASA Firewall:
The CT-5760 and CT-5508 wireless controllers have an SXP peering to the Shared Services C6500
VSS, which also has an SXP peering to each of the Nexus 7000 data center aggregation switches.
12-6
Chapter 12

Access layer Catalyst 3850 switches establish an SXP tunnel to the C6500 VSS campus distribution
switch, which then establishes a tunnel to each of the Nexus 7000 data center aggregation switches.
The primary advantage in this approach is to aggregate what may be hundreds of Catalyst 3850s
peering at the respective campus distribution switch(es) and then creating a single SXP peering to
the data center.
All SXP tunnels from the Campus infrastructure are aggregated at each of the Nexus 7000 data
center aggregation switches.
The IP/SGT mapping information is aggregated and sent by each of the Nexus 7000 aggregation
switches to the HA primary ASA Firewall including all of the server mappings created through static
IP/SGT mappings or VLAN/SGT mappings at the Nexus switches. By doing this, the ASA does not
have to maintain numerous SXP peerings to different devices.
Table 12-2 summarizes the SXP peering that is used in the CVD:
Table 12-2
SXP Peering
Device
Role
Intfc
Dst Device
Role
Intfc
CT-5760
Speaker
Lo0
Shared Svcs C6500 VSS
Listener
Lo0
CT-5508
Speaker
Mgmnt.
Listener
Lo0
Shared Svcs C6500 VSS Speaker
Lo0
N7K-Agg-1
Listener
Lo0
Lo0
N7K-Agg-2
Listener
Lo0
Catalyst 3850 Access
Speaker
Lo0
Distribution C6500 VSS
Listener
Lo0
Distribution C6500 VSS Speaker
Lo0
N7K-Agg-1
Listener
Lo0
Lo0
N7K-Agg-2
Listener
Lo0
N7K-Agg-1
Speaker
Lo0
ASA Firewall HA Primary Listener
Out
N7K-Agg-2
Speaker
Lo0
Out
As previously discussed, the ASA firewall that will be used to enforce SG-FW policies must be manually
configured with SGT policies as dynamic updates via ISE is presently not supported in the ASA. The
details regarding these SG-FW policies will be discussed later.
As wireless traffic egresses the Shared Services Catalyst 6500 VSS en route to the data center, the traffic
will be untagged and will simply be propagated through the Core, enter the data center switching
infrastructure, and ultimately arrive at the ASA firewall where the appropriate SG-FW policy will be
enforced. As shown in Figure 12-5 all the traffic going from the user to the server is passing through the
ASA firewall.
In the unlikely event that any traffic would be sourced from a server in the data center, it would likewise
egress the Nexus 7000 aggregation switch untagged and be forwarded to the ASA firewall where any
applicable SG-FW policy will be enforced
Figure 12-5 depicts the infrastructure used in Deployment Scenario 2 and the means by which security
group policies will be enforced.
12-7
Chapter 12
Figure 12-5
SGA Policy Enforcement Using SXP and SG-FW
Campus Wireless
Data Center
Application
and File
Servers
SGT50
ISE
RSA
AD
CAPWAP
CAPWAP
CAPWAP
CA
STOP
CAPWAP
STOP
ASA HA
Primary
SXP
Peering*
Catalyst
3750X
SGT12
DNS
and
DHCP
DC Agg
DC Agg
ASA HA
Secondary
DC Core
DC Core
Catalyst
3850X
Core
Services
SGT12
5760
SGT12
5508
SXP
SXP Connections*
294988
SGT12
CAPWAP
TrustSec Summary
For information regarding the detailed, platform-specific configuration steps, refer to the TrustSec
section in Chapter 23, BYOD Policy Enforcement Using Security Group Access.
Note
Minimally, Patch 1 for ISE 1.2 MUST be installed in order for NDAC (Network Device Admission
Control) to function properly between the network device and ISE. Without Patch 1, the network device
will be unable to authenticate with ISE in order to derive TrustSec environment data, PAC file, and
security group policies when CTS Manual Mode is configured and, additionally, the credentials required
to authenticate peers/TrustSec links when CTS Dot1x Mode is configured. Due to issue between ISE and
new behavior in iOS7 for Apple devices, it is recommended to deploy ISE 1.2 Patch 5. Refer to the ISE
1.2 Release Notes for additional information regarding this very important information.
12-8
CH AP TE R
13

The Cisco ISE can be configured to integrate with third-party Mobile Device Manager (MDM) products
through an XML-based API. This allows network policy decisions based on mobile device posture that
can include PIN lock, storage encryption, or registration status. In this release, both Apple and Android
devices are supported. Configuring the infrastructure to support this functionality involves setting up ISE
to send API requests to the MDM and configuring the MDM to accept these requests. Chapter 6, Mobile
Device Managers for BYOD includes a discussion of the communications between the various
components. Some MDM configurations, including device compliance policy, are discussed in general
terms in this section. Detailed partner specific information can be found in supporting documentation at:
http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns743/ns1050/own_device.html.
An overview of the topology common with the MDM architecture is presented below. The two basic
models that are detailed in this section are an On-Premise model and a Cloud-based SaaS model. The
components are similar except that the cloud model can also include an on-premise component to
facilitate the integration with the enterprise.
Establishing IP Connectivity for an On-Premise MDM

Typically the on-premise MDM resides in the DMZ or some location where mobile devices can establish
inbound connections. This allows the MDM to monitor the devices posture while the device is on the
outside of the firewall. Without this access, the device would need to be placed on the network and
interrogated prior to establishing the posture compliance of the device. The device does not
automatically update the server whenever it joins a new network, therefore this interrogation would need
to be manually initiated by the enterprise. If the MDM is located in the data center, some provision is
required to allow inbound TCP sockets from the Internet. The specific ports vary based on the MDM
partner and are detailed in the supporting documentation on Design Zone.
In addition to inbound sessions from the devices, the MDM needs to establish outbound connections to
the push servers. The MDM uses the push service to locate and notify the device of changes to the MDM
policy. Apple refers their service as the Apple Push Notification Service (APNS) and requires an Apple
signed certificate to authenticate the MDM. Google refers to their service as Google Cloud Messaging
for Android (GCM). This service replaces the older Cloud to Device Messaging Framework (C2DM).
Both Apple and Android incorporate the push service into the devices operating system (OS) to allow
the MDM server to communicate with the MDM client application. Apple devices also allow the MDM
to communicate with the OS MDM API with the appropriate credentials. Both require the end user to
establish an account with either Google or Apple respectively. This account effectively binds a device
list to a user.
13-1
Chapter 13
The MDM will also host a user-centric My Devices Portal to allow users to log into the MDM and
manage some aspects of their device. This is similar but distinct from the My Devices Portal offered by
ISE and serves a different purpose. Users may attach from either the mobile device or their standard
desktop. The MDM web server can be configured with ACLs to restrict access to the My Devices Portal
page from specific source address. For example, it is possible to block Internet access to the portal. The
same is true for the administrator website.
The MDM will also receive inbound HTTPS session on port 443 by default to support the API used by
ISE. In contrast to the MDM placement, ISE should be located in the data center. Firewall policy should
be set to allow TCP 443 sessions that are initiated from ISE towards the MDM server. The MDM will
have a default route pointing towards an outbound firewall and a more specific route to ISE pointing
towards an inbound firewall. The majority of MDM partners support on-premise deployments on VM
servers that may support multiple interfaces. It is possible that the route to ISE may be over a dedicated
link. The topology of the DMZ should match the established corporate policy for servers. Typically the
MDM will also allow the administrator to protect the API with an ACL. In this case, the ACL could be
configured to permit ISE but deny any other connections.
ISE supports the use of a proxy for external connections. Currently the proxy configuration is globally
configured. If ISE is required to use a proxy for the feed service, then it will also direct MDM requests
to the proxy. This could cause connectivity issues between ISE and an on-premise MDM. In this
scenario, the proxy configuration will require careful review to ensure that the ISE can connect to the
MDM via the proxy.

Subscribing to an online MDM service simplifies many of the connectivity issues, especially between
the mobile devices and the device manager. Because personal mobile devices spend the majority of time
connected to the public Internet, choosing this model offers some advantages over a traditional
on-premise model. The Apple APNS or Google GCM are also simplified when a cloud model is in use.
The enterprise will still need to generate a certificate-signing request and present that to Apple prior to
using the APNS service. This is explained in the partner-specific supporting documentation. However
with the advantages realized with a cloud deployment, there are also challenges with respect to
enterprise integration, specifically the corporate directory structure. Without any integration, a separate
and dedicated user database would need to be established and maintained on the MDM servers. Typically
in the cloud model, the enterprise will establish a small integration server that resides in the DMZ and
serves as a proxy to a secure LDAP binding. This is explained in the partner-specific supporting
documentation. With the exception of this additional server, all of the other components found in the
on-premise model are present in a cloud model.
The primary concern is the HTTPS connection between ISE and the cloud-based MDM server, which is
outbound from ISE. Corporate firewalls need to allow the ISE server siting in the data center to establish
outbound HTTPS servers to the MDM server. The MDM partner may be able to provide a range of
destination subnets if outbound sessions are restricted from data center servers such as ISE. Before ISE
will trust the MDM server, the MDM servers certificate should be imported into the local ISE certificate
store (this is explained below). The MDM service will provide the URL of the API. It is this certificate
on this site that should be imported. In addition, users will need to be able to establish outbound HTTPS
connections to the My Devices Portal page on the cloud-based MDM server. This would only be a
concern in environments where users are not allowed access to Internet websites. If WCS or ScanSafe
is in use, then the enterprise should confirm that the MDM site has a reputation score that exceeds the
threshold needed for access or the site should be manually added to the permitted whitelist. Routing is
straightforward. ISE and the user devices will follow the default route towards the Internet. The session
may flow over NAT boundaries without requiring a NAT fix-up.
13-2
Chapter 13

Connectivity must also be provided to mobile clients that have been quarantined to the MDM and to
either the Apple Push Service or Google Cloud Messaging Servers. This allows the MDM to
communicate with the device as needed to update the devices posture information on the server. In some
situations, the mobile client may also need access to Google Play and the Apple AppStore to download
required applications such as the MDM mobile client.

Prior to configuring the MDM, ISE must trust the HTTPS certificate presented by the MDM website. In
either the cloud or on-premise deployment model, this can be accomplished by installing the MDMs
HTTPS certificate in the ISE certificate store. The easiest method is to browse to the MDM server, export
the HTTPS certificate, and then import it into ISE. Figure 13-1 shows this in Firefox, however the
procedure may be different for other browsers.
Figure 13-1
Exporting MDM Certificate
Once the certificate has been saved to the local disk, the user will import it into the local certificate store
on ISE. By default, the browser will save the certificate file with a name based on identity contained in
the certificate, which is typically the FQDN of the site. The file extension could be .com, which is a
well-known MS-DOS extension, making the cert more difficult to locate. While this does not affect
importing the certificate, it could make browsing for the file on the hard drive less obvious. Importing
the certificate into ISE is shown in Figure 13-2.
13-3
Chapter 13
Figure 13-2
Importing Certificate into ISE
If ISE and the MDM are using the same CA, then importing the MDM SSL certificate may not be
required. ISE does not maintain a system list of well-known public root certificates, therefore all trust
relationships must be established by the administrator. Installing the MDM SSL certificate is the
simplest approach and is shown here to ensure success.

In addition to the certificate, ISE will need a user account on the MDM that will allow access to the API.
The previously installed certificate allows ISE to attach to the MDM via HTTPS, which will encrypt all
data exchanges between ISE and the MDM, including the API credentials. All of the MDM partners
support a local user account that can be granted API privileges. Some vendors may allow the account to
be defined in an external data store such as Active Directory. This could be useful if ISE is using the
same account to access AD or other resources and centralized machine account management is in use.
In all cases, the API user account should be protected by strong passwords. For specific guidance on
setting up this account, refer to the partner-specific supporting documentation or the partner MDM
Administrator guide.
There are two account issues that may prevent the API from functioning properly:
Incorrect username or password combination
Defined user has not been granted API access
Setting Up the MDM Connection

ISE will contact the MDM to gather posture information about devices or to issue device commands such
as corporate wipe or lock. The session is initiated from ISE towards the MDM server. The URL for the
MDM server is typically the same as the admin page and will be the same website used to export the
certificate. The directory path is handled automatically by the system and is not specified as part of the
configuration. The instance is used in multi-tenant deployments more commonly found when
subscribing to a cloud service. The field should be left blank unless the cloud provider has instructed
otherwise. The port will typically be TCP 443 for HTTPS. Typically the MDM cannot be configured to
listen on a specific port for API users. Any change will also impact both the admin and user portal pages.
The polling interval specifies how often ISE will query the MDM for changes to device posture. By
default, this is set to 0 minutes, effectively disabling polling. Polling can be enabled to periodically
check the MDM compliance posture of an endpoint. If the device is found to be out of compliance and
the device is associated to the network, then ISE will issue a CoA forcing the device to re-authenticate.
Likely the device will need to remediate with the MDM, although this will depend on how the policy is
13-4
Chapter 13

configured. Note that MDM compliance requirements are configured on the MDM and are independent
of the policy configured on ISE. It is possible, although not practical, to set the polling interval even if
the ISE policy does not consider this dictionary attribute. The advantage of polling is that if a user takes
the device out of MDM compliance, they will be forced to reauthorize that device. The shorter the
window, the quicker ISE will discover the condition. There are some considerations to be aware of before
setting this value to an aggressively low value. The MDM compliance posture could include a wide range
of conditions not specific to network access. For example, the device administrator may want to know
when an employee on a corporate device had exceeded 80% of the data plan to avoid overage charges.
In this case, blocking network access based solely on this attribute would aggravate the MDM
compliance condition and run counter the device administrator intentions. In addition, the CoA will
interrupt the user WiFi session, possibly terminating real-time applications such as VoIP calls. The
recommendation is to leave the polling interval at 0 until a full understanding of the MDMs
configuration is complete. If the polling interval is set, then it should match the device check-in period
defined on the MDM. For example, if the MDM is configured such that devices will report their status
every four hours, then ISE should be set to the same value and not less than half of this value. Over
sampling the device posture will create unnecessary loads on the MDM server and reduced battery life
on the mobile devices.
Finally, the enable check box will be set to active on one MDM server. It is possible to save multiple
configurations, but only one can be active at a time. Figure 13-3 shows a typical configuration.
Figure 13-3
MDM Server Details
Verifying the MDM Connection

The test button will establish a connection to the MDM and attempt to authenticate using the configured
credentials. This should be complete prior to saving the settings. If not, then the save button will validate
the settings. If any errors are encountered, the MDM Enable button will be deselected prior to saving. If
any error messages are presented, the administrator can refer to Table 13-1 for guidance in correcting
the setup. In order to re-run the test on a previously validated server, the user should deselect the Enable
checkbox, save, and then re-enable the checkbox.
13-5
Chapter 13
Table 13-1
Common MDM Connection Error Codes
A routing or firewall problem exists between ISE located in

the data center and the MDM located in either the DMZ or
Cloud. The firewalls configuration should be checked to
confirm HTTPS is allowed in this direction.
The most likely cause of an HTML 404 error code is that an

instance was configured when it was not required, or that the
wrong instance has been configured.
The user account setup on the MDM server does not have
the proper roles associated to it. Validate that the account
being used by ISE is assigned the REST API MDM roles as
shown above.
The user name or password is not correct for the account

being used by ISE. Another less likely scenario is that the
URL entered is a valid MDM site, but not the same site used
to configure the MDM account above. Either of these could
result in the MDM server returning an HTML code 401 to
ISE.
ISE does not trust the certificate presented by the MDM
website. This indicates the certificate was not imported to
the ISE certificate store as described above or the certificate
has expired since it was imported.
The connection has successfully been tested. The

administrator should also verify the MDM dictionary has
been populated with attributes.
After successfully configuring the MDM, the ISE policy dictionary will contain the attributes needed to
create policy. The user can verify the dictionary by clicking Policy > Dictionaries > System > MDM,
13-6
Chapter 13

Figure 13-4
Dictionary Attributes
Configuring the MDM

In addition to the API user account needed for ISE, there are several other administrative tasks that need
to be accomplished on the MDM, such as signing and installing the APNS certificates before ISE can
issue device actions through the API. The partner-specific supporting documentation has additional
details on the minimum requirements. The MDM can also be configured to integrate with the corporate
directory structure through LDAP. The administrator should review the MDM installation and
administration guides to bring the MDM system into a fully functional state.
13-7
Chapter 13
13-8
PART
BYOD Use Cases
CH AP TE R
14

This part of the CVD focuses on implementing the rules previously defined in business policies. These
rules translate into four different use cases that focus in providing differentiated access to corporate,
personal-owned, and guest devices and highlight the network infrastructure as the enforcement point for
BYOD policies.
The following components and configuration steps are discussed to support different BYOD use cases:
Digital Certificates
Microsoft Active Director authentication
Identity Services Engine
API Integration with Mobile Device Managers
BYOD Enhanced Use CasePersonal and Corporate DevicesThis use case provides network
access for personal devices and corporate-issued devices. It provides unique access (Full, Partial,
and Internet Only) based on different conditions analyzed by the ISE. ISE relies on the network
infrastructure to enforce unique permissions.
BYOD Limited Use CaseCorporate DevicesThis use case focuses on identifying

corporate-issued devices and providing Full Access to Network Resources.
BYOD Advanced Use CaseMobile Device Manager IntegrationThe API integration with third
party Mobile Device Managers allows the ISE to query for additional posture information on
endpoints. This information translates into more granular authorization rules and allows for more
visibility into the endpoint.
BYOD Basic Access Use CaseAn extension all the traditional wireless guest access, this use case
presents an alternative where the business policy is not to on-board personal wireless devices but
still provides access to network resources.
14-1
Chapter 14
User ExperienceHow To On-board a BYOD DeviceProviding a positive user experience is

important for any BYOD deployment. Employees should be provided with a simple way to on-board
their devices and enable the necessary security features with minimum manual intervention. This
chapter captures a typical user interaction with ISE during the on-boarding process.
14-2
CH AP TE R
15
BYOD Enhanced Use CasePersonal and

Corporate Devices
Whats New: In the previous version of the BYOD CVD, the authorization policies for a user accessing
the network with a personal device and enforced with the security group tags supported only a
Centralized Unified Wireless Network (CUWN) architecture with CT-5508 as a controller.
In this version of the BYOD CVD, the authorization policies for a user accessing the network with a
personal device and enforced with security group tags support:
CUWN architecture using CT-5508 and CT-5760 controllers
Converged Access wireless design using Catalyst 3850
The BYOD Enhanced use case is a super-set of the BYOD Limited use case, covering both personal and
corporate devices. This chapter defines the design scenarios for deploying BYOD for personal device
access and the design considerations for each scenario. It also highlights how to deny access to personal
devices based on their device type. Chapter 16, BYOD Limited Use CaseCorporate Devices
provides the same design guidance for corporate devices. Hence the design guidance for corporate
devices is not duplicated in this chapter.
One of the main objectives of a BYOD solution is to provide a simple way for employees to on-board
their personal devices without requiring assistance from IT. Since the BYOD needs of the majority of
employees will be met with either simple Internet access or Partial access, the only time an employee
requires assistance from IT is when they may require full access to corporate resources.
Cisco ISE provides different ways to define security policies and determine what network resources each
employee is allowed to access. The security policies are then enforced throughout the network
infrastructure. The ISE feature set is extremely flexible, enabling different business policies to be
enforced. This chapter explains the steps to on-board personal devices and how to apply different
policies.
Figure 15-1 shows how a personal device is profiled and registered by ISE and the different network
components (WLC, AD, CA) that play a role in the process. Different conditions are evaluated to provide
the proper authorization and access to network resources, including digital certificates, Active Directory
groups, etc.
15-1
Chapter 15
Figure 15-1
Provisioning Personal Devices
Provisioning
ISE Policy
Engine
Authorization
User
Full Access
CA
Device
AD
Profile
Partial Access
Internet Only
Guest Portal
CAPWAP
Mobile
Device
Note
Corporate
Resources
Wireless LAN
Controllers
Internet
293696
open
BYOD_Provisioning
SSID
Unless otherwise specified, in the figures throughout this chapter Wireless LAN Controllers refers to
either standalone devices such as the Cisco Flex 7500, CT5508, and CT5760 wireless controller or to
wireless LAN controller functionality integrated within Catalyst 3850 Series converged access switches.
Figure 15-2 shows how a personal device is restricted from accessing the network. Once the device
connects and regardless of user authentication, ISE profiles the device and enforces the DenyAccess
authorization rule.
Figure 15-2
Deny Access
Provisioning
ISE Policy
Engine
Authorization
User
AD
Device
CA
Active Directory
Profile
Deny Access
CAPWAP
BYOD_Employee
SSID
Internet
Wireless LAN
Controllers
293697
Personal
Android
Device
Profile Device
Figure 15-3 shows the different permission levels configured in this chapter. These access levels are
enforced using various mechanisms, including Access Control Lists (ACLs) in the Wireless LAN
Controllers (WLCs) or Catalyst switches, Security Group Tag (SGT) assignment in the WLCs, and
VLAN assignment in the Catalyst switches along with FlexConnect ACLs in access points.
15-2
Chapter 15

Figure 15-3
Permission Levels for Personal Devices

Active Directory groups can be used as an additional way to grant differentiated access to users. This
chapter relies on the following three AD groups:
BYOD_Full_AccessMembers of this group are granted full access to network resources.
BYOD_Partial_AccessMembers of this group are granted partial access to network resources.

With this permission, users are able to access the Internet and a subset of corporate applications,
such as email, corporate directory, travel tools, etc.
Domain UsersAll users are members of this system-generated group by default. Employees that
are not members of the above mentioned groups are granted Internet access.
This model could easily be expanded to include other user groups with similar access requirements. A
good example would be to create a new group and access list to grant access to contractors or partners.
Figure 15-4 highlights the different access policies validated for this chapter, along with the different
requirements and permissions granted by each policy. These policies, along with detailed configurations,
are explained later in this chapter.
Figure 15-4
Note
Access Policies and Permissions
The location SGT refers to a Wireless LAN Controller which is dedicated for the purpose doing SGT
only.
To configure the Active Directory groups that can be available for use in the authorization policy
conditions, click Administration > Identity Management > External Identity Sources > Active
Directory > Groups and check the boxes next to the groups that will be used in the policy conditions
and rules. Figure 15-5 includes the groups used in this design guide.
15-3
Chapter 15
Figure 15-5
This chapter assumes that after employees have on-boarded their devices, they will connect to the
BYOD_Employee SSID. Figure 15-6 highlights the connectivity flow for personal devices.
If the endpoint connected from a wireless 802.1X EAP-TLS SSID and has a valid certificate, based on
their AD group membership, employees will get:
Full Access if they belong to the BYOD_Full_Access group.
Partial Access if they belong to the BYOD_Partial_Access group.
Internet Access if they are a valid Active Directory member (Domain Users group)
15-4
Chapter 15

Figure 15-6
Personal Device BYOD Access

Personal
Device (Onboarded)
Wireless
EAP_TLS?
Valid
Certificate?
Deny Access
Full Access
Partial Access
Internet Only
293699
AD
Group?
In Active
Directory?

Digital signatures, enabled by public key cryptography, provide a means to authenticate devices and
users. In public key cryptography, such as the RSA encryption system, each user has a key pair
containing both a public and a private key. The keys act as complements and anything encrypted with
one of the keys can be decrypted with the other.
A digital signature is encrypted with the senders private key. The signature must be verified to confirm
the senders identity. This is done by the receiver, who decrypts the signature with the senders public
key. If the signature sent with the data matches the result of applying the public key to the data, the
validity of the message is established.
This process relies on the receiver having a copy of the public key of the sender and a high degree of
certainty that this key belongs to the sender, not to someone pretending to be the sender.
Deploying digital certificates on mobile devices requires a unique process, as many of these devices do
not natively support all the features and functionality to create, download, and install digital client
certificates in the same manner as traditional PC-based devices. At the same time, some endpoints do
not support Simple Certificate Enrollment Protocol (SCEP) natively.
For example, for users to install digital client certificates using SCEP on Apple iOS devices, the IT
administrator needs to manually create the configuration profile using the iPhone Configuration Utility
and distribute the profile to user devices via email, USB, or web pages.
15-5
Chapter 15
Traditional full-featured PC-based devices are more apt to take advantage of the many services, such as
Microsofts NDES, to provide certificate enrollment. However, with the onset of many Android and
Apple iOS devices on the market, it cannot be assumed that these devices can natively interoperate with
many of the enterprise services currently deployed.
ISE solves this problem by distributing digital certificates to endpoints using the SCEP Proxy feature,
which allows endpoints to obtain digital certificates through ISE. Moreover, this feature is combined
during the initial registration process, thereby preventing different registration steps. The next section
on mobile devices discusses how the endpoints obtain their digital certificates during the registration
process.

Deploying digital certificates to endpoint devices requires a network infrastructure that provides the
security and flexibility to enforce different security policies. Figure 15-7 highlights the general steps that
are followed when a mobile device connects to the network using dual SSIDs.
1.
A new device connects to a provisioning SSID. This SSID (open or secured with PEAP) is
configured to redirect the user to the Guest Registration portal.
2.
The certificate enrollment and profile provisioning begins once the user is properly authenticated.
3.
The provisioning service requests information from the mobile device user and provisions the
configuration profile, which includes a WiFi profile with the required parameters to connect to the
secured Employee SSID.
4.
For subsequent connections, the device uses the Employee SSID and is granted access to network
resources based on different ISE authorization rules.
Figure 15-7
Enrollment and ProvisioningDual SSID
Step 1: Provisioning
ISE Policy
Engine
Step 2: Authorization
User
Full Access
CA
Device
Profile
AD
Partial Access
Internet Only
Guest Portal
CAPWAP
Mobile
Device
SSIDs
Step 1: open
BYOD_Provisioning
Wireless LAN
Controllers
Internet
293700
Corporate
Resources
Step 2: EAP-TLS
BYOD_Employee
The on-boarding steps may also be configured with a single SSID used for provisioning and secure
access. The general steps followed when the mobile device connects are similar, redirecting the user to
the Guest registration portal and provisioning the device with a digital certificate and configuration
profiles.
15-6
Chapter 15

Provisioning Flows
Provisioning Flows
This section explains the interaction between the endpoints and the Guest Registration portal and the
steps required to enroll the digital certificate and configuration profile. The way Windows and Mac
devices are provisioned is similar. Chapter 8, Summary of Configuring the Infrastructure points to the
chapters with the steps required to configure the different network components.
Provisioning Apple iOS Devices

The following steps take place while provisioning Apple iOS devices:
The device is redirected to the Guest Registration Portal.
After successful authentication, the Over-The-Air (OTA) enrollment begins.
Device sends unique identifier (MAC address) and other information.
Certificate enrollment information is sent to the device.
A SCEP request is made to ISE, which returns a certificate.
Wireless profile for BYOD_Employee is sent to the device.
Once the enrollment is complete, the user manually connects to BYOD_Employee SSID.
15-7
Chapter 15
Provisioning Flows
Figure 15-8
Provisioning Flow for Apple iOS Devices
iOS Device
1
Centralized
Web
Authentication
Registration Portal
Supplicant/Client
Provisioning
ISE Registration
Authority (RA)
CA Server
Register device
Web Redirect
Client Provisioning Policy
Evaluation
Install ISE self-sign cert or CA who signed cert
Start Over The Air enrollment

Send device info (MAC address)
Return certificate enrollment info for device
Send SCEP request for device identity
Validate Request
Forward CSR Request
Device
Enrollment
Return x 509 certificate
Return x 509 cert
Get final configuration/device info
Return BYDO_Employee setting plus Mobile Profile

Return certificate enrollment for identity
Send SCEP request for device identity
Validate Request
Return x 509 certificate
Return x 509 cert
293701
Forward CSR Request

Provisioning
Process
For more details on Over-the-Air Enrollment and configuration for iOS devices, review the iPhone OS
Enterprise Deployment Guide:
http://manuals.info.apple.com/en_US/Enterprise_Deployment_Guide.pdf.
Provisioning Android Devices

The following steps take place while provisioning Android devices:
The device is redirected to the Guest Registration portal.
After successful authentication, the self-registration portal page redirects the user to the Google
Play.
The user installs the Supplicant Provisioning Wizard (SPW).
The SPW is launched to perform provisioning of the supplicant. The SPW performs the following
functions:
15-8
Chapter 15

Provisioning Flows
Discovers the ISE and downloads the profile from the ISE.
Creates a certificate/key pair for EAP TLS.
Makes a SCEP proxy request to ISE and gets the certificate.
Applies the wireless profile to allow connectivity to BYOD_Employee SSID.
The SPW triggers re-authentication and connects to BYOD_Employee SSID automatically.
Note
The Android agent must be downloaded from Google Play and is not provisioned by the ISE. Endpoints
must be able to reach Google Play on the Internet.
Note
ACL_Provisioning_Redirect must redirect all traffic sent to enroll.cisco.com. The Cisco Configuration
Assistant for Android devices requires this redirect to discover the ISE server. This is shown as part of
step 3 in Figure 15-9. This is not a concern if the guidance presented in the CVD is followed since all
Internet traffic except Google Play is redirected back to ISE.
15-9
Chapter 15
Provisioning Flows
Figure 15-9
Provisioning Flow for Android Devices
Andro
Android Device
WLC
ISE
CA Server
Google
Play Stor
CWA Redirect
User opens browser

Redirect to ISE CWA
CWA login
CWA login successful /redirect to NSP Portal

Device
Registration
User clicks Register
CoA to WLC
Return browser to http://play.google.com

Access-Request
NSP Redirect ACL = Allow
Google
Download
SPW
Download Supplicant Provisioning Wizard (SPW) app from Google Play Store
User installs and launches app
App sends request to http://

enroll.cisco.com
Redirect Discovery to ISE
ISE sends device Profile to Android device

CSR sent to ISE
ISE sends User Certificate to Android device
SCEP to MS Cert Authority

Certificate sent to ISE
Access-Accept
293702
Connect to BYOD_Employee using EAP-TLS

Device
Provisioning
Provisioning Wired Devices

BYOD applies to both wired and wireless devices. Wired devices can be provisioned, registered,
authenticated, and authorized in much the same way as wireless devices. The following are some of the
advantages of provisioning wired devices:
Certificate provisioning can be done during the provisioning process, which alleviates the burden on
IT to support another model to provision certificates on the devices.
The native supplicants on the device can be configured with the right protocols during the
provisioning process. If this is left to the user, it may often lead to incorrect configurations and
additional management overhead for IT.
Provides easier methods for IT to obtain visibility into who is accessing the network and also
methods to remove network access for devices that are lost or stolen.
15-10

Provisioning Flows
Figure 15-10 shows a high-level overview of the components used to deploy wired devices. ISE uses
several building blocks, such as AD group membership, the EndPoints:BYODRegistration attribute, and
Digital Certificates to authenticate and authorize devices. Examples on how to construct these polices
are explained in this design guide.
Figure 15-10
Wired Device Deployment
Step 1: Provisioning
ISE Policy
Engine
Step 2: Authorization
User
Full Access
CA
Device
Profile
AD
Partial Access
Internet Only
Guest Portal
Core
Personal
Device
Note
Corporate
Resources
Catalyst
Switch
Internet
293703
Chapter 15
Unless otherwise specified, in the figures throughout this chapter Access Layer Switches refers to
either switches such as the Catalyst 3750X Series and Catalyst 4500 Series or to Catalyst 3850 Series
converged access switches.
The following are high-level steps that occur when a wired device connects to the access layer switch:
1.
The switch must detect that the wired endpoint is not configured for dot1x and should authenticate
using MAB.
2.
The ACL_Provisioning_Redirect ACL is used to match web traffic.
3.
The URL redirect must point to the ISE Guest Registration portal.
4.
The ACL_Provisioning ACL must be downloaded on the port that restricts access in this state.
5.
The user opens a browser and attempts to access any resource.
6.
The switch redirects the user to an ISE self-registration portal.
7.
ISE authenticates the user against AD and pushes the SPW package.
8.
The SPW package helps the user register and obtain a digital certificate from ISE.
9.
CoA occurs and the user reconnects to the network using the obtained digital certificate.
Figure 15-11 illustrates the flow for wired device provisioning.
15-11
Chapter 15
Figure 15-11
Wired Device Provisioning Flow
Wired Device
Access Layer
Switch
DHCP
Server
Active
Directory
ISE
Host connects, presents

MAC address to switch
Switch Detects MAB. Forwards to ISE.
ISE sends URL-redirect, and ACL_Provisioning to switch.
Host obtains IP address
Host opens browser
Switch Detects MAB. Forwards to ISE.
ISE authentication
against AD
ISE pushes SPW package, and the host obtains certificate.
ISE authenticates, and sends authZ policy.
293704
Host connects using dot1x

Being able to store digital certificates and their associated keys safely is critical for every device. Storage
is implemented differently, depending on the operating system or media used. Table 15-1 shows the
different platforms tested in this design guide and their certificate stores.
Table 15-1
Device
Platform and Certificate Storage
Certificate Store
How to Access
Microsoft Windows Machine Certificate Store Use the Certificates snap-in from the mmc.exe utility
Mac OS
Device Certificate Store
Use the Keychain Access application
Apple iPad
Device Certificate Store
Settings > General > Profile
Android
Credential Storage
Settings > Location & Security
Once provisioned, the certificates have the following attributes, which can be used by ISE to enforce
different permissions:
Common Name (CN) of the Subject:
User identity used for authentication
Subject Alternative Name:
MAC address(es) of the endpoint.
15-12
Chapter 15

Network Device Groups

To differentiate between different connections, the ISE relies on Network Device Groups to group WLCs
based on their location or device type. This allows a single ISE to enforce policies across different groups
of devices. Click Administration > Network Resources > Network Device Groups to define locations
for branch, campus, and SGT enabled controllers.
Figure 15-12 shows the different locations used in the authorization policy.
Figure 15-12
ISE Device GroupsLocations
Similarly, Figure 15-13 shows a device type called Converged which can be created for Catalyst 3850
Series switches and CT5760 wireless controllers and used in the authorization policy.
Figure 15-13
Note
ISE Device GroupsDevice Types
One of the reasons a device type is used instead of a location for Converged Access designs is that the
same authorization policy rules are used for Converged Access branch and campus designs within this
design guide. Hence locationcampus versus branchis not particularly relevant from a Cisco ISE
perspective to Converged Access designs presented in this design guide. Note that if location is relevant,
the customer can always modify the design presented here and choose to deploy separate authorization
policy rules for branch and campus Converged Access designs as well.
15-13
Chapter 15
Each Wireless LAN Controller, previously defined as a Network Device, needs to be added to the proper
device group by clicking Administration > Network Resources > Network Devices and specifying the
proper location or device type from the pull-down menu.
Figure 15-14 shows how the dc-wlc-1 Wireless LAN Controller belongs to the Campus_Controllers
Network Device Group.
Figure 15-14
ISE Network DevicesCampus Controller
These device groups will be used in the authorization rules of the following sections to enforce full,
partial, or Internet only access.

Enforcing policies for SGA in BYOD architecture consist of two main components:
Defining tags for the endpoints and the destination servers.
Defining and implementing the Security Group ACL or Security Group Firewall (SG-FW) policy.
In this design, the Security Group ACL is implemented either on the Catalyst and Nexus Data Center
switching infrastructure or on the ASA Firewall as an SG-FW policy. These two choices are discussed
in Chapter 5, Campus and Branch Network Design for BYOD as two different deployment scenarios.
15-14
Chapter 15

Security Group Access Tags

The basic idea of Security Group Access is to associate a device or servers IP address with a Security
Group Tag and then create role-based policies that either permit or deny traffic flows based on these
source and destination SGTs. For example: are devices tagged with an SGT 10 allowed to communicate
with a server tagged with an SGT 40? This flow is either allowed or blocked at the enforcement point.
Using this tagging concept, unique tags have been defined for each device accessing the network as a
client. As explained in Chapter 5, Campus and Branch Network Design for BYOD unique permissions
are granted to personal and corporate devices and hence unique tags have been defined for each use case.
Table 15-2 illustrates how tags are assigned to different devices.
Table 15-2
Source Tags
Device Type
Tag
Corporate device with Full Access
SGT 10
Personal device with Full Access
SGT 11
Personal device with Partial Access SGT 12

Similarly, the destination servers also need to be associated with a particular tag. Table 15-3 illustrates
how based on their role, servers are assigned with a different tag.
Table 15-3
Destination Tags
Destination Server Tag

Open Access
SGT 40
Corporate Server
SGT 50
Security Group ACL

After defining the source tags and destination tags, the next logical step is to define the egress policy
matrix that defines the enforcement policy between a source and destination tag. Table 15-4 illustrates
the egress policy matrix.
Table 15-4
Egress Policy Matrix
Device Type
SGT 40
SGT 50
SGT 10 Corporate device with Full Access
Yes
Yes
SGT 11 Personal device with Full Access
Yes
Yes
SGT 12 Personal device with Partial Access Yes
No
As shown in Table 15-4, corporate or personal devices granted full access will be allowed to reach
servers that have been tagged with SGT 40 or SGT 50. Similarly, a personal device with partial access
is only allowed to connect with a server tagged with SGT 40.
The implementation of the SGACL depends upon the type of the deployment scenario. For the
deployment scenario where Nexus is the enforcement point the SGACL is defined in ISE and pushed to
the Nexus switch whereas when the deployment scenario is using ASA as the enforcement point then an
SGT-based access rule is configured manually on the ASA firewall.
15-15
Chapter 15
Personal Wireless DevicesFull Access

Based on policy matches and authorization profiles, the ISE assigns an SGT tag to endpoints. Centralized
Campus with SGT, found later in this chapter, provides information as to the criteria used to determine
when an ACL versus an SGT should be returned upon successful authorization based on the network
device type of the wireless controller defined in ISE.
For the destination tags assigned to servers, the configuration is done manually at the data center switch,
and the actual enforcement happens based on the deployment scenario. To obtain more information on
how to configure tags for servers and on the ASA, refer to Chapter 12, Security Group Access for
BYOD.

To provide full access to personal devices, the Cisco ISE verifies the following:
The employee has completed the on-boarding process through the Guest Registration portal.
To uniquely identify the device and prevent spoofing, the Calling-Station-ID matches the Subject
Alternative Name of the certificate.
The connection originated using EAP-TLS authentication.
The user is a member of the BYOD_Full_Access Active Directory group.
Since the wireless designs presented in this design guide rely on different WLCs for FlexConnect
branches, centralized controller campuses, and Converged Access campuses and branches; unique
authorization rules are created for connections originating from each design. At a high level,
Figure 15-15 shows how different authorization profiles are selected for connections originating from
different locations with different wireless designs. Each authorization profile in turn enforces a unique
permission.
15-16

Figure 15-15
Full Access Enforcement
Location
Authorization Profile
Policy Enforcement
Centralized Campus
SGT
SGT11_Campus_Pers_Full
SGT 11
Converged Campus
SGT
C_SGT_11_Campus_Pers_Full
SGT 11
Centralized Campus
ACL
Campus WiFi Full Access
ACCESS_ACCEPT
Converged Access
Campus and Branch
Converged WiFi Full Access
ACCESS_ACCEPT
Branch FlexConnect
Branch WiFi Full Access
VLAN: 10
FlexACL: N/A
294939
Chapter 15
To configure the authorization rules in ISE, click Policy > Authorization. Figure 15-16 highlights the
authorization policy to grant full access to personal devices.
Figure 15-16
Authorization Policies for Full Access
Looking at the rules in more detail, ISE evaluates the following conditions:
Wireless_EAP-TLSThe endpoint connected using EAP-TLS (defined as a compound condition).
The endpoint has a valid certificate. The Calling-Station-ID matches the MAC address included in
the certificates Subject Alternative Name (defined as a simple condition).
The user belongs to a specific Active Directory group (defined as a simple condition).
15-17
Chapter 15
Note
The RADIUS authentication originated from a wireless controller which was a member of one of
the following device groupsSGT_Converged_Controller, Campus_Controller, SGT_Controller,
Branch_Controller, or Converged_Access (defined as a simple condition).
A wireless controller which is a member of the Converged_Access device group could be either a
standalone device, such as a Cisco CT5760 wireless controller, or a switch with integrated wireless
controller functionality, such as the Catalyst 3850.
Simple and Compound Conditions

To improve the readability of the authorization policy, simple and compound authorization conditions
were defined to group different conditions. These conditions may be reused and modified without
changing every authorization rule.
Table 15-5 shows the conditions used in the authorization rules:
Table 15-5
Wireless EAP-TLS (Compound)

Wireless_EAP-TLS (See
Figure 15-18)
Radius:Service-Type Equals Framed AND

Radius:NAS-Port-Type Equals Wireless - IEEE 802.11 AND
Network Access:EapAuthentication Equals EAP-TLS
Check for Valid Certificate (Simple)

Valid_Certificate (See
Figure 15-19)
Radius:Calling-Station-ID EQUALS CERTIFICATE:Subject

Alternative Name
Active Directory Group (Simple)

AD_ Full_Access
AD1:ExternalGroups EQUALS sdulab.com/Users/BYOD_Full_Access
AD_ Partial_Access
AD1:ExternalGroups EQUALS
sdulab.com/Users/BYOD_Partial_Access
AD_Domain_users
AD1:ExternalGroups EQUALS sdulab.com/Users/Domain User

WLC Location or Device Type (Simple)
SGT_Controller
Campus_Controller
Branch_Controller
Converged_Access
DEVICE:Location EQUALS All

Locations#Campus_Controllers#SGT_Enabled
DEVICE:Location EQUALS All Locations#Campus_Controllers
DEVICE:Location EQUALS All Locations#Branch_Controllers
DEVICE:Device Type EQUALS All Device Types#Converged
To illustrate the value of using simple/compound conditions, Figure 15-17 shows how much longer and
harder to read a rule can be when simple/compound conditions are not implemented.
15-18
Chapter 15

Figure 15-17
Authorization Rule without Conditions
To define a new compound condition, click Policy > Conditions > Authorization > Compound
Conditions. Figure 15-18 shows how the Wireless_EAP-TLS condition combines several conditions
into one.
Figure 15-18
Wireless_EAP-TLS Condition
Figure 15-19 shows the Valid_Certificate simple condition.

Figure 15-19
Valid_Certificate Condition
Figure 15-20 shows the AD_Full_Access simple condition.
15-19
Chapter 15
Figure 15-20
AD_Full_Access Condition
The remaining conditions mentioned in Table 5 are defined in a similar way.
Permissions
Permission is a result of an authorization policy match, and the permission can be of different types such
as an authorization profile, or a standard result. Table 15-6 explains the permissions used for full access.
Table 15-6
Permissions for Full Access
Permission name
Note
Purpose
C_SGT11_Campus_Pers_Full Standard result
To Assign a SGT for 802.1X wireless devices

connecting from a Converged Access SGT
enabled controller and allowing full access.
Standard result

connecting from an SGT-enabled controller
allowing full access.
Authorization profile Provides Full Access for 802.1X wireless

devices connecting from a centralized campus
controller.
Authorization profile
Authorization profile Provides Full Access for 802.1X wireless

devices connecting from a Converged Access
controller.
To push a VLAN for 802.1X wireless devices

connecting from a FlexConnect branch
controller
A Converged Access infrastructure refers to a branch or campus deployment with Catalyst 3850 Series
switches and/or CT5760 wireless controllers within this design guide.
15-20
Permission type
Chapter 15

Centralized Campus with SGT

As explained in Policy Enforcement for Security Group Access, the personal device with permissions
for full access will be assigned an SGT value of 11. Once the personal device obtains the tag value of
11, it can then connect with all the servers in the data center.
Note
Centralized Campus with SGT refers to a Wireless LAN Controller which is part of Centralized Wireless
LAN Architecture and is enabled with SGT capability.
Figure 15-21 shows how the SGT11_Campus_Pers_Full authorization profile uses SGT 11 for personal
devices granted full access.
Figure 15-21
See Policy Enforcement for Security Group Access for details regarding the SGT egress policy matrix
which defines the permissions for SGT11 allowing full access for a campus which implements a
centralized controller (Local Mode) design with SGTs.
Converged Access Campus with SGT

The authorization result used in this rule is same as the one used in the Centralized Campus with SGT,
but the key difference is that it is initiated by a Converged Access Switch in a Campus network. The
Conditions that are part of this rule match for Converged Access Switches only.
Centralized Campus with ACLs

Figure 15-22 shows how the Campus WiFi Full Access authorization profile is using the
ACCESS_ACCEPT Access Type to allow full access.
15-21
Chapter 15
Figure 15-22
Since full access is allowed with this authorization profile, no Named ACL for access control needs to
be specified by ISE.
Branch with FlexConnect

Endpoints connecting from a branch location which implements FlexConnect dynamically get assigned
to VLAN 10, which has been configured to provide full access. Figure 15-23 shows the Branch WiFi
Full Access authorization profile.
15-22
Chapter 15

Figure 15-23
Since full access is allowed with this authorization profile, no FlexConnect ACL for access control needs
to be associated with VLAN 10 on the access point.

Figure 15-24 shows how the Converged WiFi Full Access authorization profile is using the
15-23
Chapter 15
Personal Wireless DevicesPartial Access
Figure 15-24
Again, since full access is allowed with this authorization profile, no Named ACL for access control
needs to be specified by ISE.

To provide partial access to personal devices, the Cisco ISE verifies the following:
Alternative Name of the certificate, in this case, the MAC address of the endpoint.
The user is member of the BYOD_Partial_Access Active Directory group.
At a high level, Figure 15-25 shows how different authorization profiles are selected for devices
accessing the network from different locations with different wireless designs. Each authorization
profile in turn enforces a unique permission using either VLANs, SGTs, dynamic ACLs, FlexConnect
ACLs, etc.
15-24

Figure 15-25
Partial Access Enforcement
Location
Policy Enforcement
Centralized Campus
SGT
SGT12_Campus_Pers_Partial
SGT 12
Converged Campus
SGT
SGT WiFi Personal Access
SGT 12
Centralized Campus
ACL
Campus WiFi Partial Access
Airespace ACL: ACL_Partial
Converged Access
Campus and Branch
Converged WiFi Partial Access
Radius Filter-ID: ACL_Partial
Branch FlexConnect
Branch WiFi Partial Access
VLAN: 11
FlexACL: BranchX_ACL_Partial
294941
Chapter 15
authorization policy to grant partial access to personal devices.
Figure 15-26
Authorization Policies for Partial Access
15-25
Chapter 15
the following device groupsSGT_Converged_Controller, Campus_Controller, SGT_Controller,
Branch_Controller, or Converged_Access (defined as a simple condition).
Simple and Compound Conditions explains the different conditions used in the rules.
Permissions
Permission is a result of an authorization policy match and the permission can be of different types such
as an authorization profile or a standard result. Table 15-7 explains the permissions used for partial
access.
Table 15-7
Permissions Used for Wireless Partial Access
Permission name
Permission type Purpose
SGT12_Campus_Pers_partial Standard result

connecting from an SGT-enabled controller
granting partial access to some servers in the data
center.
Converged Campus SGT
Standard result

connecting from a Converged Access SGT enabled
controller and allowing partial access.
Authorization
profile
To push a named ACL for 802.1X wireless devices

connecting from a centralized campus controller.
Authorization
profile

connecting from a FlexConnect branch controller
Converged WiFi Partial

Access
Authorization
profile
To push a named ACL for 802.1X wireless devices

connecting from either a campus or branch location
with Converged Access
Centralized Campus with SGT

As explained in Policy Enforcement for Security Group Access, the personal device with permissions
for partial access will be assigned an SGT value of 12. Once the personal device obtains the tag value of
12 it can then connect with only those servers with an SGT of 50 in the data center.
Figure 15-27 shows how the SGT12_Campus_Pers_Partial authorization profile is configured to assign
SGT 12 to personal devices thus allowing partial access.
15-26
Chapter 15

Figure 15-27
See Policy Enforcement for Security Group Access for details regarding the SGT egress policy matrix
which defines the permissions for SGT12 allowing full access for a campus which implements a
centralized controller (Local Mode) design with SGTs.
Converged Access Campus with SGT

This authorization result used in this rule is same as the one used in the Centralized Campus with SGT,
but the key difference is that it is initiated by a Converged Access Switch in a Campus network. The
Conditions that are part of this rule matche for Converged Access Switches only.

For devices connecting from a campus location which implements a centralized (Local Mode) wireless
design, the Campus WiFi Partial Access authorization profile relies on the ACL_Partial_Access access
list, enforced by the WLC. Figure 15-28 shows the authorization profile.
15-27
Chapter 15
Figure 15-28
Cisco Wireless LAN Controllers support named ACLs, meaning that the ACL must be previously
configured on the controller rather than being downloaded from ISE. Using the RADIUS Airespace-ACL
Name attribute-value pair, ISE instructs the WLC to apply the ACL_Partial_Access ACL. Figure 15-29
shows the contents of this ACL, as defined in the CT5508 WLC campus controller.
15-28
Chapter 15

Figure 15-29
ACL_Partial_Access on Wireless Controller
The access-list shown in Figure 15-29 specifies the following access:
Note
Allow IP access to and from the MDM Server (203.0.113.10).
Allow IP access to and from specific subnet (10.230.4.0 /24).
Deny IP access to and from data center subnets (10.230.0.0 /16).
Deny IP access to and from campus subnets (10.225.0.0 /16).
Allow access to and from all other subnets (Internet access).
Note that Access Control Entries (ACEs) for the MDM server are included within the ACLs in this
chapter. These are not used for the Enhanced Access use case discussed within this chapter. The
Advanced Access use case, discussed in Chapter 17, BYOD Advanced Use CaseMobile Device
Manager Integration, makes use of the same authorization policy rules and authorization profiles.
The access list shown in Figure 15-29 is a generic example used to enforce a hypothetical use case and
is not intended to work for every organization. An ACL should be more specific and only allow access
to specific IP addresses and protocols in the required direction. A common practice is to make the ACLs
as detailed as possible and to define every entry down to the port level.
Note
The CT5508 WLC supports a maximum of 64 ACLs with a maximum of 64 lines per ACL.
15-29
Chapter 15
Branches with FlexConnect

For devices connecting from a branch location which implements a FlexConnect wireless design, the
Branch WiFi Partial Access authorization profile dynamically assigns the device to VLAN11, which is
dedicated for devices obtaining Partial Access. Figure 15-30 shows this authorization profile.
Figure 15-30
Deploying ACLs on the branch is slightly different than using ACLs with a centralized WLC. For branch
locations, the Cisco 7500 Flex Wireless Controller relies on FlexConnect ACLs to enforce policy
permissions within this design guide. FlexConnect ACLs are created on the WLC and configured with
the VLAN defined on the AP or the FlexConnect Group using the VLAN-ACL mapping for dynamic or
AAA override VLANs. These FlexConnect ACLs are pushed to the APs when the authorization policy
matches. This design guide relies on FlexConnect groups to enforce Flex ACLs for each VLAN. The
steps are as follows:
1.
Create a FlexConnect ACL for each branch.
2.
Apply the FlexConnect ACL on the FlexConnect group for each branch.
3.
Define the VLAN-ACL mapping for each VLAN.
On the FlexConnect 7500 Controller, click Security > Access Control Lists > FlexConnect ACLs and
define the ACL rules for Partial Access. Figure 15-31 shows the Branch1_ACL_Partial_Access ACL,
which allows access to the Internet and some internal resources.
15-30
Chapter 15

Note
A unique ACL may be needed for each branch since each branch location may have its own local
resources and unique IP address space.
Figure 15-31
Branch1_ACL_Partial_Access
The above ACL specifies the following access:
Note
Allow IP access to and from specific subnet (10.230.4.0 /24). Similar ACL entries could be added
to allow access to Branch1 subnets/servers.
The access list shown is a generic example used to implement an arbitrary use case and not intended to
work for every organization. An ACL should be more specific and only allow access to specific IP
addresses and protocols in the required direction. A common practice is to make the ACLs as detailed
as possible and to define every entry down to the port level.
For the purposes of this design guide, a FlexConnect group is defined for each branch, which allows for
multiple FlexConnect access points in the branch to share configuration parameters.
15-31
Chapter 15
On the FlexConnect 7500 controller, click Wireless > FlexConnect Groups and select the FlexConnect
group for a particular branch location, as shown in Figure 15-32.
Figure 15-32
FlexConnect Groups
In Figure 15-33, the FlexConnect group for Branch1 is applying the Branch1_ACL_Partial_Access ACL
to endpoints connecting to VLAN 11.
Figure 15-33
FlexConnect Group for Branch1

For devices connecting from campus or branch locations which implement a Converged Access design,
the Converged WiFi Partial Access authorization profile relies on the ACL_Partial_Access access list,
enforced by the Catalyst 3850 Series switch. Figure 15-34 shows the authorization profile.
15-32
Chapter 15

Figure 15-34
Converged WiFi Partial Access
Cisco Catalyst 3850 Series switches (and CT5760 wireless controllers) support both named ACLs and
downloadable ACLs. For the Converged Access design a named ACL is implemented, meaning that the
ACL must be configured on the Catalyst 3850 switch rather than being downloaded from ISE. Using the
RADIUS Filter-ID attribute-value pair, ISE instructs the WLC to apply the ACL_Partial_Access ACL.
The following configuration example shows the contents of this ACL, as defined in the Catalyst 3850
switch.
!
ip access-list extended ACL_Partial_Access
permit udp any eq bootpc any eq bootps
permit ip any host 10.230.1.45
permit ip any 10.230.4.0 0.0.0.255
deny
ip any 10.230.0.0 0.0.255.255
deny
ip any 10.225.0.0 0.0.255.255
deny
ip any 10.200.0.0 0.0.255.255
permit ip any any
!
The access list shown in above similar to the access list shown in Figure 15-29, but configured on a
Catalyst switch instead of a wireless controller. Hence the structure of the access list is slightly different.
The access list specifies the following access:
Allow IP access to and from specific servers (10.230.6.2 and 10.225.100.10).
15-33
Chapter 15
Personal Wireless DevicesInternet Only Access
Deny IP access to and from branch subnets (10.200.0.0 /16).
Again, the access list shown in this example is generic and not intended to work for every organization.
An ACL should be more specific and only allow access to specific IP addresses and protocols in the
required direction. A common practice is to make the ACLs as detailed as possible and to define every
entry down to the port level.
Note
This design guide shows the use of the Radius:Airespace-ACL-Name AV pair for specifying a named
ACL on CUWN wireless controller platforms, such as the CT5508 and Flex 7500 wireless controllers.
However, it shows the use of the Radius:Filter-Id AV pair for specifying a named ACL on Cisco
IOS-based wireless controller platforms, such as the CT5760 wireless controller and Catalyst 3850
Series switch. For wireless devices, this is simply to highlight the fact that the network administrator
can utilize the legacy Airespace-ACL-Name AV pair or the RADIUS standard method of the Filter-Id
AV pair within the BYOD implementation. It is recommended that the network administrator standardize
on one of the two methods to specify a named ACL where possible in actual deployments.
Since a single ISE policy rule is defined for partial access of personal wireless devices from either a
branch or campus with a converged access infrastructure, the access list can be customized to the specific
branch or campus location as needed. The specific example ACL shown above is consistent with the ACL
discussed in the campus centralized (Local Mode) controller design previously discussed.

To provide Internet Only access to personal devices, the Cisco ISE verifies the following:
The user is a member of the Domain Users Active Directory group.
At a high level, Figure 15-35 shows how different authorization profiles are selected for devices coming
from different locations with different wireless designs. Each authorization profile in turn enforces a
unique permission using VLANs, SGTs, named ACLs, FlexConnect ACLs, etc.
15-34

Figure 15-35
Internet Only Enforcement
Location
Policy Enforcement
Centralized Campus
SGT
Campus Wifi Internet Only
Airespace ACL:
ACL_Internet_Only
Centralized Campus
ACL
Airespace ACL:
ACL_Internet_Only
Converged Access
Campus and Branch
Radius Filter-ID:
ACL_Internet_Only
Branch FlexConnect
Branch WiFi Internet Only
VLAN: 12
FlexACL: ACL_Internet_Only
293728
Chapter 15
authorization policy to grant Internet Only access to personal devices.
Figure 15-36
Authorization Policies for Internet Only Access
The user belongs to the Domain Users Active Directory group (defined as a simple condition).
the following device groupsCampus_Controller, SGT_Controller, Branch_Controller, or
Converged_Access (defined as a simple condition).
Simple and Compound Conditions explains the different conditions used in the rules.
15-35
Chapter 15
Permissions
When all conditions in the authorization policy rules match, the rule invokes the proper permission. In
the previous sections the permission result was either an authorization profile (non-SGT based access),
or a standard result for SGT based access. However, in this section only the authorization profile will be
used for the reasons explained below.
Campus WiFi Internet Only for 802.1X wireless devices connecting from a SGT_enabled controller
or from a campus location with a centralized (Local Mode) wireless design. Both the campus
controller and the SGT_enabled controller use the same authorization profiles. SGTs are not used
to tag Internet only traffic since SGT relies on source and destination tags and the destination tag
for the Internet is unknown.
Branch Wireless Internet Only for 802.1X wireless devices connecting from a branch location which
implements a Flexconnect wireless design.
Converged WiFi Internet Only for 802.1X wireless devices connecting from either a campus or
branch location which implements a Converged Access infrastructure design.
Centralized Campus with SGT or ACLs

For devices connecting from a campus location which implements a centralized (Local Mode) wireless
design or from a SGT_enabled controller, the Campus WiFi Internet Only authorization profile relies on
the ACL_Internet_Only access list enforced by the WLC. Figure 15-37 shows how the authorization
profile instructs the WLC to apply the ACL.
15-36
Chapter 15

Figure 15-37
Campus WiFi Internet Only
Cisco Wireless LAN Controllers support named ACLs, meaning the ACL must be previously configured
on the controller, rather than being downloaded from ISE. Using the RADIUS Airespace-ACL Name
attribute-value pair, ISE instructs the WLC to apply the ACL_Internet_Only ACL.
Figure 15-38 shows the contents of this ACL, as defined in the CT5508 WLC campus controller.
15-37
Chapter 15
Figure 15-38
ACL_Internet_Only
Deny IP access to and from internal network address space (10.0.0.0/8, 172.16.0.0/12,
192.168.0.0/16).
Once again, the access list is generic and not intended to work for every organization. An ACL should
be more specific and only allow access to specific IP addresses and protocols in the required direction.
A common practice is to make the ACLs as detailed as possible and to define every entry down to the
port level.
Branches with FlexConnect

For devices connecting from a branch location which implements a FlexConnect wireless design, the
Branch WiFi Internet Only authorization profile dynamically assigns the device to VLAN12, which is
dedicated for devices obtaining Internet_Only access.
Figure 15-39 shows this authorization profile.
15-38
Chapter 15

Figure 15-39
Branch WiFi Internet Only
For branch locations which implement FlexConnect wireless designs, the Cisco 7500 Flex Wireless
Controller relies on FlexConnect ACLs to enforce policy permissions. FlexConnect ACLs are created on
the WLC and configured with the VLAN defined on the AP or the FlexConnect Group using the
VLAN-ACL mapping for dynamic or AAA override VLANs. These FlexConnect ACLs are pushed to
the APs when the authorization policy matches.
1.
Create a FlexConnect ACL for each branch.
2.
Apply the FlexConnect ACL on the FlexConnect group for each branch.
3.
Define the VLAN-ACL mapping for each VLAN.
On the FlexConnect 7500 Controller, click Security > Access Control Lists > FlexConnect ACLs and
define the ACL rules for Internet_Only access. Figure 15-40 shows an example of the
Branch_ACL_Internet_Only ACL, which only allows access to the Internet. This ACL is the same for
all branches.
15-39
Chapter 15
Figure 15-40
Branch_ACL_Internet_Only
192.168.0.0/16).
The access list is generic and not intended to work for every organization. An ACL should be more
specific and only allow access to specific IP addresses and protocols in the required direction. A common
practice is to make the ACLs as detailed as possible and to define every entry down to the port level.
For the purposes of this design guide, a FlexConnect group is defined for each branch, which allows for
multiple FlexConnect access points in the branch to share configuration parameters.
On the FlexConnect 7500 controller, click Wireless > FlexConnect Groups and select the FlexConnect
group for a particular branch location, as shown in Figure 15-41.
15-40
Chapter 15

Figure 15-41
FlexConnect Groups
In Figure 15-42, the FlexConnect group for Branch1 is applying the Branch_ACL_Internet_Only ACL
to endpoints connecting to VLAN 12.
Figure 15-42
FlexConnect Group for Branch1 Internet Only

For devices connecting from campus or branch locations which implement a Converged Access design,
the Converged WiFi Internet Only authorization profile relies on the ACL_Internet_Only access list,
enforced by the Catalyst 3850 Series switch. Figure 15-43 shows the authorization profile.
15-41
Chapter 15
Figure 15-43
Converged WiFi Internet Only
Cisco Catalyst 3850 Series switches (and CT5760 wireless controllers) support both named ACLs and
downloadable ACLs. For the Converged Access design a named ACL is implemented, meaning that the
ACL must be configured on the Catalyst 3850 switch rather than being downloaded from ISE. Using the
RADIUS Filter-ID attribute-value pair, ISE instructs the WLC to apply the ACL_Internet_Only ACL.
The following configuration example shows the contents of this ACL, as defined in the Catalyst 3850
switch.
ip access-list extended ACL_Internet_Only
deny
ip any 10.0.0.0 0.255.255.255
deny
ip any 172.16.0.0 0.15.255.255
deny
ip any 192.168.0.0 0.0.255.255
permit ip any any
!
The access-list shown in above is similar to the access list shown in Figure 15-38, but configured on a
Catalyst switch instead of a wireless controller. Hence the structure of the access-list is slightly different.
However the access-list specifies the following access:
Note
Allow DHCP access (bootpc and bootps).
Allow IP access to and from the ISE server (10.225.49.15).
Deny IP access to and from the rest of the internal network IP address space (10.0.0.0 /8, 172.16.0.0
/12, 192.168.0.0 /16).
Allow access to all other addresses (Internet addresses).
The MDM above is shown with private RFC1918 address. In practice, the MDM must be reachable from
the public Internet and may not require a specific line entry in the ACL.
15-42
Chapter 15

Personal Wired DevicesFull Access
Again, the access list shown in this example is generic and not intended to work for every organization.
An ACL should be more specific and only allow access to specific IP addresses and protocols in the
required direction. A common practice is to make the ACLs as detailed as possible and to define every
entry down to the port level.

To provide full access to personal wired devices, the Cisco ISE verifies the following:
The user is a member of the BYOD_Full_Access Active Directory group.
Since the wired designs presented in this design guide rely on slightly different access control
mechanisms for Converged Access campuses and branches, for campuses and branches which do not
implement Converged Access infrastructures, unique authorization rules are created for connections
originating from each design.
Note
For the purpose of clarity within this design guide, Converged Access branches refer to designs in which
Catalyst 3850 Series switches are deployed at the access-layer of the branch network. From a wired
perspective, branches which do not implement Converged Access infrastructures are branches which
deploy other Catalyst access-layer switches, such as the Catalyst 3750X Series. Unless otherwise
specified, these will be referred to simply as branches within the design guide. Similarly, Converged
Access campuses refer to designs in which Catalyst 3850 Series switches are deployed at the
access-layer of building distribution modules within the campus. From a wired perspective, campuses
which do not implement Converged Access infrastructures are campuses which deploy other Catalyst
access-layer switches, such as the Catalyst 3750X Series. Unless otherwise specified, these will be
referred to simply as campuses within this design guide. This is in order to minimize the use of verbose
phrases such as branches which do not implement Converged Access infrastructure and campuses
which do not implement Converged Access infrastructure.
At a high level, Figure 15-44 shows how different authorization profiles are selected for connections
originating from different locations with different infrastructure designs. Each authorization profile in
turn enforces a unique permission using VLANs, dynamic ACLs (either named or downloadable
[DACL]), etc.
15-43
Chapter 15
Full Access Wired Enforcement
Location
Policy Enforcement
Campus
Campus Wired Full Access
DACL: ACL_Full_Access
Branch
Branch Wired Full Access
VLAN: Wired_Full
Converged Wired Full Access
Named ACL: ACL_Full_Access
Converged Access
Campus and Branch
Note
293737
Figure 15-44
Wired assignment of Security Group Tags (SGTs) is not discussed within this version of the design
guide. Hence, there is no wired policy enforcement via SGTs in Figure 15-44. Future versions of this
design guide may address wired SGT assignment.
To differentiate these connections, the ISE relies on Network Device Groups to group Catalyst switches
of devices. Each Catalyst switch needs to be added to the proper device group by clicking
Administration > Network Resources > Network Devices and specifying the proper location or device
type from the pull-down menu.
Figure 15-45 shows the details of authorization profile configured in ISE for wired devices.
Figure 15-45
Authorization Policies for Wired Full Access
Wired_EAP-TLSThe endpoint connected using EAP-TLS (defined as a compound condition).
15-44
Chapter 15

The RADIUS authentication originated from a Catalyst switch which was a member of one of the
following device groupsCampus_Switches, Branch_Switches, or Converged_Access (defined as
a simple condition).
Wired Simple and Compound Conditions

Table 15-8 shows the conditions used in the authorization rules.
Table 15-8
Wired EAP-TLS (Compound)

Wired_EAP-TLS

Radius:NAS-Port-Type Equals Ethernet

Valid_Certificate
Radius:Calling-Station-ID EQUALS CERTIFICATE:Subject

Alternative Name
Active Directory Group (Simple)

AD_ Full_Access
AD1:ExternalGroups EQUALS sdulab.com/Users/BYOD_Full_Access
AD_ Partial_Access
AD1:ExternalGroups EQUALS
sdulab.com/Users/BYOD_Partial_Access
AD_Domain_users
AD1:ExternalGroups EQUALS sdulab.com/Users/Domain User

Campus_Switches
DEVICE:Location EQUALS All Locations#Campus_Switches
Branch_Switches
DEVICE:Location EQUALS All Locations#Branch_Switches
Converged_Access
Permission
When all conditions in the authorization policy rule match, the rule invokes the proper permission. The
permissions can be of different forms such as an authorization profile or a standard result. In this design
guide, for wired access the authorization policy is used as permission to the policy rules match.
Table 15-9 explains the permissions used for the full access for wired users.
15-45
Chapter 15
Table 15-9
Permissions Used for Wired Full Access
Permission name
Permission type
Purpose
Authorization profile Provides Full Access for 802.1X wired devices

connecting from campus location.
To push a VLAN for 802.1X wired devices

connecting from a branch location.
Converged Wired Full Access Authorization profile To push a named ACL for 802.1X wired
devices connecting from either a campus or
branch location with Converged Access.
Campus Wired
Figure 15-46 shows how the Campus Wired Full Access authorization profile is defined in ISE.
Figure 15-46
Note
Campus Wired Full Access Authorization Profile
Cisco Catalyst switches support both downloadable ACLs (DACLs) and named ACLs. This design guide
shows the use of downloadable ACLs for access control of wired devices when implementing a
non-Converged Access infrastructure and the use of named ACLs for access control of wired devices
when implementing a Converged Access infrastructure. This is done to show the range of capabilities
for access control available on Cisco IOS-based platforms. The same wired policy enforcement for
Converged Access and non-Converged Access infrastructure can be achieved if the customer desires,
simply by using either downloadable ACLs (DACLs) or named ACLs for both designs. Both
15-46
Chapter 15

downloadable and named ACLs have advantages and disadvantages, depending upon where they are
deployed within the network. Chapter 5, Campus and Branch Network Design for BYOD discusses
some of these advantages and disadvantages.
The downloadable ACL (dACL), which allows all IP traffic, overrides the default-ACL configured on
the switch port. The default-ACL is used as an additional preventative measure in case the downloadable
ACL is not applied to the switch port for some reason. Figure 15-47 shows the dACL definition which
must be configured in ISE:
Figure 15-47
Note
dACL Definition in ISE that Grants Full Access to the Users
ISE 1.2 has the ability to check the dACL syntax. This feature should be utilized in order to minimize
the possibility that the dACL is not applied due to a syntax error.
Branch Wired
Figure 15-48 shows how a similar authorization profile is constructed for devices connected at a branch
which does not have a Converged Access infrastructure. The authorization profile pushes VLAN
informationin this case the VLAN namealong with the ACL information.
15-47
Chapter 15
Figure 15-48
Branch Wired Full Access Authorization Profile
Once this profile is downloaded to the Catalyst switch, the endpoint gets full access to the network.
Figure 15-49 shows an example of the state of the port when this profile is downloaded by using the
switch command show authentication session interface Gi0/23.
Figure 15-49
Catalyst Switch Port

Figure 15-50 shows how the Converged Wired Full Access authorization profile is defined in ISE.
15-48
Chapter 15

Personal Wired DevicesPartial Access
Figure 15-50
Converged Wired Full Access Authorization Profile
For the Converged Access design a named ACL is implemented, meaning that the ACL must be
configured on the Catalyst 3850 switch rather than being downloaded from ISE. Using the RADIUS
Filter-ID attribute-value pair, ISE instructs the converged access switch to apply the ACL_Full_Access
ACL. The following configuration example shows the contents of this ACL, as defined in the Catalyst
3850 switch.
!
ip access-list extended ACL_Full_Access
permit ip any any
!
This ACL is used to override the default-ACL configured on the switch port. The default-ACL is used
as an additional preventative measure in case ACL_Full_Access is not configured on the switch.

Partial Access grants access to corporate resources, in addition to Internet access. As mentioned in
Personal Wireless DevicesPartial Access, once a device authenticates to ISE, an authorization profile
is applied. For wired devices, the authorization profile is applied to the access layer switch.
To provide partial access to personal wired devices, the Cisco ISE verifies the following:
The user is a member of the AD_Partial_Access Active Directory group.
from different locations with different wired infrastructure designs. Each authorization profile in turn
enforces a unique permission using VLANs, dynamic ACLs (either named or downloadable [DACL]),
etc.
15-49
Chapter 15
Wired Partial Access Enforcement
Location
Policy Enforcement
Campus
Campus Wired Partial Access
DACL: ACL_Partial_Access
Branch
Branch Wired Partial Access
VLAN: Wired_Partial
Converged Wired Partial Access
Named ACL:
ACL_Partial_Access
Converged Access
Campus and Branch
293742
Figure 15-51
Figure 15-52
Authorization Policies for Wired Partial Access
Wired Simple and Compound Conditions explains the different conditions used in the rules.
15-50
Chapter 15

Permissions
Table 15-10 explains the permissions used for the partial access for wired users.
Table 15-10
Permissions Used for Wired Partial Access
Permission name
Permission type
Purpose
Authorization profile To push a dACL for 802.1X wired devices

Branch Wired Partial Access

Converged Wired Partial Access Authorization profile To push a named ACL for 802.1X wired
branch location with Converged Access.
Campus Wired
For devices connecting from a campus location, the Campus Wired Partial Access authorization uses a
DACL named ACL_Partial_Access enforced by the access layer switch, as shown in Figure 15-53.
Figure 15-53
15-51
Chapter 15
The dACL overrides the default-ACL configured on the switch. Figure 15-54 shows an example of this
ACL, which is configured within ISE.
Figure 15-54
ACL_Partial_Access within ISE
Allow DNS access to the DNS server (10.230.1.45).
Allow IP access to and from specific subnet (10.230.4.0 /24).
Allow IP access to and from specific servers (10.230.6.2 and 10.225.100.10).
192.168.0.0/16).
Branch Wired
For devices connecting from a branch location, the Branch Wired Partial Access authorization pushes a
VLAN assignment along with a downloadable ACL.
Figure 15-55 shows the details of the authorization profile configured in ISE.
15-52
Chapter 15

Figure 15-55
Branch Wired Partial Access Authorization Profile
The DACL allows all IP traffic, so that the traffic initiated by the host reaches the branch router where
the router-ACL is applied.
See VLAN Design at Branch Locations in Chapter 11, BYOD Wired Infrastructure Design for details
regarding how this assignment of VLAN 14 is given full access for a branch which does not implement
a Converged Access infrastructure.
Converged Access Branch and Campus

Figure 15-56 shows how the Converge Wired Partial Access authorization profile is defined in ISE.
15-53
Chapter 15
Personal Wired DevicesInternet Only Access
Figure 15-56
Converged Wired Partial Access Authorization Profile
For the Converged Access design a named ACL is implemented. Using the RADIUS Filter-ID
attribute-value pair, ISE instructs the converged access switch to apply the ACL_Partial_Access ACL.
This is the same ACL discussed for converged access infrastructure in Personal Wireless
DevicesPartial Access. For wired devices, the ACL is used to override the default-ACL configured on
the switch port. The default-ACL is used as an additional preventative measure in case
ACL_Partial_Access is not configured on the switch.

To provide Internet Only access to personal devices, the Cisco ISE verifies the following:
The user is a member of the Domain Users Active Directory group.
from different locations with different wired infrastructure designs. Each authorization profile in turn
enforces a unique permission using VLANs, dynamic ACLs (either named or downloadable [DACL]),
etc.
15-54

Figure 15-57
Wired Internet Only Access Enforcement
Location
Policy Enforcement
Campus
Campus Wired Internet Only
DACL: ACL_Internet_Only
Branch
Branch Wired Internet Only
VLAN: Wired_Internet
Converged Wired Internet Only
Named ACL:
ACL_Internet_Only
Converged Access
Campus and Branch
293748
Chapter 15
Figure 15-58 highlights the authorization policy to grant Internet Only access to personal wired devices.
Figure 15-58
Authorization Policies for Wired Internet Only Access
Wired Simple and Compound Conditions explains the different conditions used in the rules.
15-55
Chapter 15
Permissions
Table 15-11 explains the permissions used for Internet access.
Table 15-11
Permissions Used for Wired Internet Access
Permission name
Permission type
Purpose
Campus Wired Internet Only Authorization profile To push a dACL for 802.1X wired devices
connecting from a campus location.
Branch Wired Internet Only
Authorization profile To push a VLAN for 802.1X wired devices

Converged Wired Internet

Only
Authorization profile To push a named ACL for 802.1X wired

branch location with Converged Access
Wired Campus
For devices connecting from a campus location, the Campus Wired Internet Only authorization profile
uses the DACL named ACL_Internet_Only, which is pushed to the access layer switch port.
Figure 15-59 shows the Authorization profile.
15-56
Chapter 15

Figure 15-59
Campus Wired Internet Only Authorization Profile
The DACL overrides the default-ACL configured on the switch. Figure 15-60 shows an example of this
ACL, which is configured within ISE.
Figure 15-60
ACL_Internet_Only DACL
15-57
Chapter 15
Allow DNS access to the DNS server (10.230.1.45).
192.168.0.0/16).
This access list is generic and not intended to work for every organization. An ACL should be more
specific and only allow access to specific IP addresses and protocols in the required direction. A common
practice is to make the ACLs as detailed as possible and to define every entry down to the port level.
Branch Wired
For devices connecting from a branch location, the Branch Wired Internet Only authorization pushes a
VLAN assignment along with a downloadable ACL. Figure 15-61 illustrates the Branch Wired
Internet_Only authorization profile, used to grant Internet_Only access to personal devices connecting
from the branch.
Figure 15-61
Branch Wired Internet Only Authorization Profile
The ACL_Full_Access DACL is pushed to the access-layer switch to override the default-ACL on the
port and allow all IP traffic to flow up to the branch router.
See VLAN Design at Branch Locations in Chapter 11, BYOD Wired Infrastructure Design for details
regarding how this assignment of VLAN 15 is given full access for a branch which does not implement
a Converged Access infrastructure.
15-58
Chapter 15

Converged Access Branch and Campus

Figure 15-62 shows how the Converge Wired Internet Only authorization profile is defined in ISE.
Figure 15-62
Converged Wired Internet Only Authorization Profile
For the Converged Access design a named ACL is implemented. Using the RADIUS Filter-ID
attribute-value pair, ISE instructs the converged access switch to apply the ACL_Internet_Only ACL.
This is the same ACL discussed for converged access infrastructure in Personal Wireless
DevicesInternet Only Access. For wired devices, the ACL is used to override the default-ACL
configured on the switch port. The default-ACL is used as an additional preventative measure in case
ACL_Internet_Only is not configured on the switch.

Rather than allowing differentiated access to the network which was depicted in the previous use cases,
this use case discusses on how to deny access permission for some BYOD devices from connecting to
the network. For example, some organizations may decide to have a more restrictive BYOD environment
and grant access only to a specific type of device (e.g., Android, Apple iOS, etc.).
This example focuses on denying access to Android devices, relying on the profiling capabilities of ISE.
To deny access to Android devices, the Cisco ISE verifies the following:
The employee attempts to connect to the network.
The ISE profiler identifies the device type.
If the device type is Android, deny access.
authorization policy to deny access to Android devices.
15-59
Chapter 15
Figure 15-63
Deny Android Devices
The DenyAccess authorization profile is used to enforce the permissions and deny access to Android
devices. The DenyAccess profile is a standard ISE profile and cannot be edited. This reserved profile
cannot be edited but may be found under Policy > Results> Authorization Profiles.
Figure 15-64 shows an entry from ISEs log, highlighting the fact that the device has been profiled as an
Android device and the DenyAccess authorization rule has been enforced.
Figure 15-64
DenyAccess

For reference purposes, the complete authorization policy used during validation is shown in
Figure 15-65. The figure highlights the following sections:
1.
Used for blacklisting lost or stolen devices.
2.
On-boarding and MDM registration/remediation (required for the advanced use case).
3.
Wireless devices connecting from an access point in a SGT_Enabled location.
4.
Wireless devices connecting from an access point in the campus or branch locations.
5.
Wired devices connecting from a campus or branch locations.
6.
Wired and Wireless devices connecting from a converged location.
7.
Guest and Basic Access.
15-60
Chapter 15

Figure 15-65
Complete Authorization Policy
15-61
Chapter 15
15-62
CH AP TE R
16

Whats New: In the previous version of the BYOD CVD, the authorization policies for a user accessing
the network with a corporate device and enforced with the security group tags supported only a
Centralized Unified Wireless Network (CUWN) architecture with CT-5508 as a controller.
In this version of the BYOD CVD, the authorization policies for a user accessing the network with a
corporate device and enforced with security group tags support:
CUWN architecture using CT-5508 and CT-5760 controllers
Converged Access wireless design using Catalyst 3850
This chapter discusses design considerations and the construction of policy rules for providing network
access to corporate devices, as well as the security policies enforced by the Cisco ISE. A corporate
device is a corporate asset that is provided by the organization and has the approved configuration
profiles and digital certificate to access the network. ISE allows the employee to on-board their
corporate devices in a similar way personal devices are on-boarded, as discussed in Chapter 15, BYOD
Enhanced Use CasePersonal and Corporate Devices.
Cisco ISE provides many ways to enforce security policies and determines what network resources each
device is allowed to access. This chapter focuses on allowing full access to corporate devices. The ISE
feature set is extremely flexible to meet diverse business requirements. The goal of this chapter is to
highlight this flexibility of ISE and explain the steps to restrict access for corporate devices.
Figure 16-1 shows the different authorization rules used by ISE to grant full access to corporate devices.
Different network components play a role in this process, including the wireless infrastructure, Active
Directory, a CA server, etc.
16-1
Chapter 16
Figure 16-1
Provisioning Corporate Devices
Provisioning
ISE Policy
Engine
Authorization
Device Registration
User
CA
Device
Profile
AD
Valid Certificate
Whitelist
Guest Portal
Full Access
CAPWAP
Corporate
Resources
Wireless LAN
Controllers
Internet
294017
Corporate
Device
open
BYOD_Provisioning
SSID

An identity group is a logical list used to group endpoints according to their profiles and is an efficient
way for ISE to enforce different permissions to different types of devices.
For this design guide, the Whitelist identity group was created for the purpose of uniquely identifying
corporate devices. This identity group maintains a list of devices owned by the corporation. The
Whitelist is manually updated by the IT administrator and contains the MAC addresses of devices that
are granted full access. The assumption is that IT has added the devices to the Whitelist in advance.
The identity group provides an additional check when enforcing authorization rules. Endpoints may be
moved to other identity groups, such as the Whitelist identity group or the Blacklist identity group, used
when a device is lost or stolen. Chapter 22, Managing a Lost or Stolen Device has more details on the
Blacklist identity group.
Note
Endpoints can only be members of one identity group at a time.

To update an endpoints identity group, click Administration > Groups > Endpoint Identity Groups.
Figure 16-2 shows endpoints as members of the Whitelist identity group.
16-2
Chapter 16

Figure 16-2
An Active Directory group could be used as an additional check, but for the purpose of this design guide
the Whitelist identity group identifies a device as a corporate device. This model could easily be
expanded to include AD groups to enforce additional policy requirements.
Figure 16-3 highlights the policy tested in this chapter, along with the different requirements and
permissions. This policies, along with detailed configurations, is explained in this chapter.
Figure 16-3
Access Policies and Permissions
This chapter assumes that after employees have on-boarded their devices, they'll connect to the
BYOD_Employee. Figure 16-4 highlights the connectivity flow granting full access to corporate
devices. If the device has been on-boarded, it belongs to the Whitelist identity group and has a digital
certificate, the device is granted full access.
16-3
Chapter 16
Figure 16-4
Corporate Device BYOD Access

Corporate
Device (Onboarded)
In
Whitelist?
Wireless
EAP_TLS?
Deny Access
Full Access
293995
Valid
Certificate?

A new addition to this CVD is the use of Security Group Tags in creating role-based policies in addition
to ACLs to enforce policies for campus wireless users. Enforcing policies for SGA in BYOD architecture
consist of three main components:
Defining tags for the endpoints and the destination servers.
Defining and implementing the Security Group ACL in the switching infrastructure.
Defining firewall policies based on Security Group Tags if Security Group Firewall is implemented.
Depending on the SGA deployment scenario followed, the Security Group Egress Policy can be defined
at the ISE and dynamically pushed to Catalyst 6500 infrastructure switches and the Nexus Data Center
switches as Security Group ACLs (SGACL) or configured at the ASA Firewall as a SGT-based policy.
These two choices are discussed in Chapter 23, BYOD Policy Enforcement Using Security Group
Access as two different deployment scenarios.
Security Group Access Tags

The basic idea of Security Group Access is to define the tags for source and destination traffic flows and
specify what source tags are able to reach other destination tags. For example, are devices tagged with
an SGT 10 allowed to communicate with a server tagged with an SGT 40? This flow is either allowed or
blocked at the enforcement point.
16-4
Chapter 16

Using this tagging concept, unique tags have been defined for different types of source traffic generated
by the endpoints. As explained in Chapter 12, Security Group Access for BYOD, unique permissions
are established for personal and corporate devices and unique tags have been defined for each use case.
Table 16-1 illustrates how tags are assigned to different devices.
Table 16-1
Source Tags
Device Type
Tag
Corporate device with Full Access
SGT 10
Personal device with Full Access
SGT 11
Personal device with Partial Access SGT 12

Similarly, the destination servers also need to be associated with a particular tag. Table 16-2 illustrates
how, based on their role, servers are assigned with a different tag.
Table 16-2
Destination Tags
Destination Server Tag

Open Access
SGT 40
Corporate Server
SGT 50
Security Group ACL

After defining the source and destination tags, the next logical step is to define the egress policy that
establishes the permissions for traffic between those tags. Table 16-3 illustrates the egress policy as an
enforcement matrix.
Table 16-3
Enforcement Matrix
Device Type
SGT 40
SGT 50
SGT 10 Corporate device with Full Access
Yes
Yes
SGT 11 Personal device with Full Access
Yes
Yes
SGT 12 Personal device with Partial Access Yes
No
As shown in Table 16-3, corporate or personal devices granted full access will be allowed to reach
servers that have been tagged with SGT 40 or SGT 50. Similarly, a personal device with a partial access
is only allowed to connect with a server tagged with SGT 40.
The implementation of the SGACL depends upon the type of the deployment scenario. For the
deployment scenario where Nexus is the enforcement point, the SGACL is designed in ISE and pushed
to the Nexus switch. When the deployment scenario is using ASA as the enforcement point, then an
SGT-based access rule is configured manually on the ASA firewall.
16-5
Chapter 16
Corporate DevicesFull Access

Based on policy matches and authorization profiles, the ISE assigns an SGT to campus wireless devices.
Centralized CampusPolicy Enforcement using TrustSec in Chapter 9, BYOD Wireless Infrastructure
Design provides information about the criteria used to determine when, based on the network device
type of the wireless controller defined in ISE, an ACL versus an SGT should be returned upon successful
authorization.
For the destination server tags, the configuration is done manually at the data center switch and the actual
enforcement happens based on the deployment scenario. For more information about configuring tags
for servers and the ASA, see Chapter 23, BYOD Policy Enforcement Using Security Group Access..

To provide full access to corporate devices, the Cisco ISE verifies the following:
The device has been on-boarded and has the right certificate and profile configurations.
The device has been added to the Whitelist identity group.
Alternative Name of the certificate.
Since the wireless designs presented in this design guide rely on different WLCs for FlexConnect
branches, Centralized Controller campuses, and Converged Access campuses and branches, unique
authorization rules are created for connections originating from each design. At a high level, Figure 16-5
shows how different authorization profiles are selected for connections originating from different
locations with different wireless designs. Each authorization profile in turn enforces a unique permission
using VLANs, SGTs, dynamic ACLs (either named or downloadable [DACL]), FlexConnect ACLs, etc.
16-6

Figure 16-5
Full Access Enforcement
Location
Policy Enforcement
Centralized Campus
SGT
SGT10_Campus_Corp
SGT 10
Converged Campus
SGT
SGT10_Campus_Corp
SGT 10
Centralized Campus
ACL
ACCESS_ACCEPT
Converged Access
Campus and Branch
ACCESS_ACCEPT
Branch FlexConnect
VLAN: 10
FlexACL: N/A
294943
Chapter 16
To differentiate these connections, the ISE relies on Network Device Groups to group WLCs based on
their location or device type. This allows a single ISE to enforce policies across different groups of
devices.
Figure 16-6 shows the different locations created for branch and campus devices.
Figure 16-6
ISE Device GroupsLocations
Similarly, Figure 16-7 shows a device type called Converged which can be created for Catalyst 3850
Series switches and CT5760 wireless controllers and used in the authorization policy.
16-7
Chapter 16
Figure 16-7
Note
ISE Device GroupsDevice Types
One of the reasons a device type is used instead of a location for Converged Access designs is that the
same authorization policy rules are used for Converged Access branch and campus designs within this
design guide. Hence locationcampus versus branchis not particularly relevant from a Cisco ISE
perspective to converged access designs presented in this design guide.
Each Wireless LAN Controller needs to be added to the proper device group by clicking Administration
> Network Resources > Network Devices and specifying the proper location or device type from the
pull-down menu.
Figure 16-8 shows how the dc-wlc-1 belongs to the Campus_Controllers location.
Figure 16-8
Campus Controller
16-8
Chapter 16

Wireless LAN Controllers implementing a centralized (Local Mode) campus wireless design are
assigned to the Campus_Controllers group.
authorization policy to grant full access to corporate devices.
Figure 16-9
Authorization Policies for Full Access
Looking at the first rule in more detail, ISE evaluates these conditions:
Note
WhitelistThe endpoint has been added by an IT Administrator to the Whitelist identity group.
the following device groups: Campus_Controller, SGT_Controller, Branch_Controller, or
Converged_Access (defined as a simple condition).
A wireless controller which is a member of the Converged_Access device group could be either a
standalone device, such as a Cisco CT5760 wireless controller, or a switch with integrated wireless
controller functionality, such as the Catalyst 3850.

16-9
Chapter 16
Table 16-4
Wireless Simple and Compound Conditions
Wireless EAP-TLS (Compound)

Wireless_EAP-TLS (See Figure 16-11) Radius:Service-Type Equals Framed
Radius:NAS-Port-Type Equals Wireless - IEEE 802.11
Valid_Certificate (See Figure 16-12)
Radius:Calling-Station-ID EQUALS CERTIFICATE:Subject Alternative Name

SGT_Controller
DEVICE:Location EQUALS All Locations#Campus_Controllers#SGT_Enabled
Campus_Controller
DEVICE:Location EQUALS All Locations#Campus_Controllers
Branch_Controller
DEVICE:Location EQUALS All Locations#Branch_Controllers
Converged_Access

To illustrate the value of using simple/compound conditions, Figure 16-10 shows how much longer and
harder to read a rule can be when simple/compound conditions are not implemented.
Figure 16-10
Authorization Rule without Conditions
To define a new compound condition, click Policy > Conditions > Authorization > Compound
into one.
16-10
Chapter 16

Permissions for Wireless Users
Figure 16-11
Figure 16-12 shows the Valid_Certificate simple condition.

Figure 16-12
Valid_Certificate Condition
The remaining conditions shown in Table 16-4 are defined in a similar way.

When all conditions in the authorization policy rule match, the rule invokes the proper permissions to
provide Full Access, as shown in Table 16-5.
Table 16-5
Permission name
SGT10_Campus_Corp
Standard result
To assign a SGT for 802.1X wireless devices

connecting from an SGT-enabled controller.
Authorization
profile
Provides Full Access for 802.1X wireless devices

connecting from a centralized campus controller.
16-11
Chapter 16
Table 16-5
Note
Permission name
Authorization
profile

connecting from a FlexConnect branch controller.
Converged WiFi Full Access Authorization

profile
Provides Full Access for 802.1X wireless devices

connecting from a Converged Access controller.
A Converged Access infrastructure refers to a branch or campus deployment with Catalyst 3850 Series
switches and/or CT5760 wireless controllers within this design guide.
Centralized Campus with SGTs

Figure 16-13 shows how the SGT10_Campus_Corp authorization profile is pushing the Security Group
Tag whose value is 10 for a user of a corporate device, who is allowed to obtain full access.
Figure 16-13
SGT10_Campus_Corp
See Chapter 23, BYOD Policy Enforcement Using Security Group Access for details regarding how
SGT 10 is given full access for a campus which implements a centralized controller (Local Mode) design
with SGTs.

Figure 16-14 shows how the Campus WiFi Full Access authorization profile is using the
16-12
Chapter 16

Figure 16-14
Since full access is allowed with this authorization profile, no Named ACL for access control needs to
be specified by ISE.
Branch with FlexConnect

Endpoints connecting from a branch location dynamically get assigned to VLAN 10, which has been
configured without an ACLs thus providing full access.
16-13
Chapter 16
Figure 16-15

Within this design guide, a Converged Access infrastructure refers to a branch or campus deployment
with Catalyst 3850 Series switches and/or CT5760 wireless controllers.
Figure 16-16 shows how the Converged WiFi Full Access authorization profile is using the
16-14
Chapter 16

Figure 16-16
Again, since full access is allowed with this authorization profile, no Named ACL for access control
needs to be specified by ISE.
Corporate Wired DevicesFull Access

The authorization policy rules for wired devices follow the same logic as wireless devices. Corporate
approved wired devices are assumed to be pre-configured with the correct configuration profiles after
being on-boarded.
To provide full access to corporate wired devices, the Cisco ISE verifies the following:
The device has been on-boarded and has the right certificate and profile configurations.
The device has been added to the Whitelist identity group.
Since the wired designs presented in this design guide rely on slightly different access control
mechanisms for converged access campuses and branches, for campuses and branches that do not
implement converged access infrastructures unique authorization rules are created for connections
originating from each design.
Note
For the purpose of clarity within this design guide, converged access branches refer to designs in which
Catalyst 3850 Series switches are deployed at the access-layer of the branch network. From a wired
perspective, branches which do not implement converged access infrastructures are branches which
deploy other Catalyst access-layer switches, such as the Catalyst 3750X Series. Unless otherwise
specified, these are referred to simply as branches within the design guide. Similarly, converged access
campuses refer to designs in which Catalyst 3850 Series switches are deployed at the access-layer of
building distribution modules within the campus. From a wired perspective, campuses which do not
implement converged access infrastructures are campuses which deploy other Catalyst access-layer
switches, such as the Catalyst 3750X Series. Unless otherwise specified, these are referred to simply as
16-15
Chapter 16
campuses within this design guide. This is in order to reduce the use of verbose phrases such as
branches which do not implement converged access infrastructure and campuses which do not
implement converged access infrastructure.
At a high level, Figure 16-17 shows how different authorization profiles are selected for connections
originating from different locations with different infrastructure (converged access versus
non-converged access) designs. Each authorization profile in turn enforces a unique permission using
VLANs, dynamic ACLs (either named or downloadable [DACL]), etc.
Full Access Wired Enforcement
Location
Policy Enforcement
Campus
Branch
VLAN: Wired_Full
Converged Wired Full Access
Named ACL: ACL_Full_Access
Converged Access
Campus and Branch
Note
293737
Figure 16-17
Wired assignment of Security Group Tags (SGTs) is not discussed within the design guide. Hence there
is no wired policy enforcement via SGTs in Figure 16-17. Future versions of this design guide may
address wired SGT assignment.
To differentiate these connections, the ISE relies on Network Device Groups to group Catalyst switches
of devices. Each Catalyst switch needs to be added to the proper device group by clicking
Administration > Network Resources > Network Devices and specifying the proper location or device
type from the pull-down menu.
16-16
Chapter 16

Figure 16-18
Authorization Policies for Wired Full Access
WhiteListThe endpoint has been added by an IT Administrator to the WhiteList identity group.
following device groups: Campus_Switches, Branch_Switches, or Converged_Access (defined as a
simple condition).

Table 16-6
Wired EAP-TLS (Compound)

Wired_EAP-TLS

Radius:NAS-Port-Type Equals Ethernet

Valid_Certificate
Radius:Calling-Station-ID EQUALS CERTIFICATE:Subject Alternative Name

Campus_Switches
DEVICE:Location EQUALS All Locations#Campus_Switches
Branch_Switches
DEVICE:Location EQUALS All Locations#Branch_Switches
Converged_Access
16-17
Chapter 16
Permissions for Wired Users

permissions can be of different forms, such as an authorization profile or a standard result. In this design
Table 16-7 explains the permissions used for the full access for wired users.
Table 16-7
Permissions Used for Wired Full Access
Permission Name
Permission Type
Purpose
Authorization profile Provides Full Access for 802.1X wired devices


Converged Wired Full Access Authorization profile To push a named ACL for 802.1X wired devices
connecting from either a campus or branch
location with Converged Access.
Campus Wired
Figure 16-19 shows how the Campus Wired Full Access authorization profile is defined in ISE.
16-18
Chapter 16

Figure 16-19
Note
Campus Wired Full Access Authorization Profile
Cisco Catalyst switches support both downloadable ACLs (DACLs) and named ACLs. This design guide
shows and validates the use of downloadable ACLs for access control of wired devices when
implementing a non-converged access infrastructure and the use of named ACLs for access control of
wired devices when implementing a converged access infrastructure. This is done to show the depth and
range of capabilities for access control available on Cisco IOS-based platforms. Note that the same wired
policy enforcement for converged access and non-converged access designs can be achieved if the
customer desires by simply using either downloadable ACLs (DACLs) or named ACLs for both designs.
Both downloadable and named ACLs have advantages and disadvantages, depending upon where they
are deployed within the network. ACL Complexity and Considerations in Chapter 5, Campus and
Branch Network Design for BYOD discusses some of these advantages and disadvantages.
The downloadable ACL (DACL), which allows all IP traffic, overrides the default-ACL configured on
the switch port. The default-ACL is used as an additional preventative measure in case the downloadable
ACL is not applied to the switch port for some reason.
Note
ISE 1.2 has the ability to check the DACL syntax. This feature should be utilized in order to minimize
the possibility that the DACL is not applied due to a syntax error.
16-19
Chapter 16
Branch Wired
Figure 16-20 shows how a similar authorization profile is constructed for devices connected at a branch
which does not have a Converged Access infrastructure. The authorization profile pushes VLAN
information along with the ACL information.
Figure 16-20
Branch Wired Full Access Authorization Profile
Once this profile is downloaded to the Catalyst switch, the endpoint gets full access to the network.

Figure 16-21 shows how the Converged Access Wired Full Access authorization profile is defined in
ISE.
16-20
Chapter 16

Figure 16-21
Converged Wired Full Access Authorization Profile
For the converged access design, a named ACL is implemented, meaning that the ACL must be
configured on the Catalyst 3850 switch rather than being downloaded from ISE. Using the RADIUS
Filter-ID attribute-value pair, ISE instructs the Catalyst 3850 to apply the ACL_Full_Access ACL. The
following configuration example shows the contents of this ACL as defined in the Catalyst 3850 switch.
!
permit ip any any
!

For reference purposes, the complete authorization policy used during testing is shown in Figure 16-22.
The figure highlights the following sections:
1.
2.
On-boarding and MDM registration/remediation.
3.
4.
5.
16-21
Chapter 16
6.
7.
Figure 16-22
16-22
CH AP TE R
17
BYOD Advanced Use CaseMobile Device

Manager Integration
Whats New: Added notes about how ACL behavior has changed in version 7.5+ of the Wireless LAN
Controller.
This chapter focuses on getting additional posture information from the integration with third-party
Mobile Device Managers (MDMs). While previous chapters focused on on-boarding corporate and
personal devices and providing differentiated access, this chapter makes use of more detailed endpoint
information to enforce authorization policies.
MDM servers secure, monitor, manage, and support mobile devices to secure and control the use of
mobile applications. The network is the only entity that can provide granular access to endpoints based
on VLAN assignment, ACLs (named or downloadable [DACL]), SGTs, FlexConnect ACLs, etc. By
integrating with third-party MDM servers, the Cisco ISE receives the necessary device attributes to
enforce a more granular network access to those endpoints.
Figure 17-1 shows the interoperability between MDMs and the Cisco ISE. Once a device has been
on-boarded with ISE, ISE queries the MDM for additional endpoint information. If the endpoint is
registered and compliant with MDM policies, the device is granted access, based on other attributes, as
described in the previous sections.
Notice that the MDM server can be deployed on-premise or in the cloud.
17-1
Chapter 17
Figure 17-1
MDM Interoperability
Option #1
(Cloud)
Step 1: On-boarding
Internet Edge
Option #2
(On-premise)
MDM
Internet
Step 2: MDM Compliance

CAPWAP
CAPWAP
ASA Firewall
Catalyst 3750X
or
Catalyst 3850
Data Center/Services
ISE

Access:
MDM
AD
CA
WAN
293767
WLC
The following steps take place when checking for device compliance:
1.
The user connects to an on-boarding SSID and is guided through the registration and on-boarding
process with ISE.
2.
Once the user has been on-boarded with the proper certificate/profiles, the user connects to the
secure Employee SSID.
3.
ISE makes an API call to the MDM server. If the device is not registered with the MDM, the user is
presented with the appropriate page to proceed to their MDM enrollment page.
4.
Once the user completes the enrollment with the MDM server, they return to an enrollment redirect
page that includes a continue button. When the user selects the continue option from the page, ISE
will issue a Change of Authorization (CoA), forcing the user to re-authenticate. The API should now
indicate the user has enrolled with the MDM. The MDM API results are cached by ISE for the
duration of the authorization flow.
5.
ISE uses the cached MDM information for the specific MAC address to verify the devices posture
including its MDM compliance status. If the device is not in compliance with the MDM policies,
the user is once again informed and is asked to become compliant.
6.
Once the device becomes compliant, the user is authorized to access the network based on the
assigned permissions (Full, Partial Access, or Internet Access).
7.
ISE can poll the MDM server periodically to get compliance information.
Chapter 13, Mobile Device Manager Integration for BYOD provides more details on how to configure
the integration between ISE and the MDM.
17-2
Chapter 17


Cisco ISE relies on REST API calls to query the external MDM server for additional endpoint
information. The communication between ISE and the MDM is mostly unidirectional, where ISE sends
different commands to the MDM. Some commands query for device information (model, compliance
status, serial number, etc.) while others can invoke an action on the device (Corporate Wipe, Full Wipe,
PIN lock, etc.).
The following are some of the functions that ISE performs in conjunction with an MDM server:
Device registrationUnregistered endpoints connecting to the network are redirected to a web page
hosted on the MDM server to initiate the MDM enrollment process.
Device remediationCisco ISE imposes a captive portal on noncompliant endpoints. The user is
redirected to a web page hosted by ISE but populated with device posture information obtained via
the MDM API. The page informs the user and what actions to take to become compliant.
Periodic compliance checksCisco ISE polls the MDM server periodically for a list of non-MDM
compliant devices. ISE will determine if any device on the list is currently associated with the
network and will issue a CoA against those devices.
Device instructions through the MDM serverRemote actions can be issued for users devices
through the MDM server.
The endpoint database is updated with additional information from the MDM server that cannot be
collected using the Cisco ISE Profiler. The following device attributes can be obtained from the MDM:
MDMManufacturer
MDMModel
MDMOSVersion
MDMPhoneNumber
MDMSerialNumber
MDMIMEI
These attributes can be viewed by clicking Administration > Identity Management > Identities >
Endpoints, as shown in Figure 17-2.
17-3
Chapter 17
Figure 17-2
MDM Attributes
The integration with an MDM server allows the Cisco ISE to configure policies based on additional
MDM attributes. The dictionary attributes can be found under Policy > Dictionaries > MDM >
Dictionary Attributes, as shown in Figure 17-3.
17-4
Chapter 17

Integration Process Flow
Figure 17-3
Dictionary Attributes
Some of these attributes are used in several authorization rules in this design guide.

Figure 17-4 shows the integration process between ISE and the MDM:
1.
The device has been on-boarded and the user connects to the BYOD_Employee SSID.
2.
Cisco ISE makes an API call to the MDM server to verify that the device has been registered with
the MDM.
3.
If the device is not registered and is required to be registered, the user is asked to enroll with the
MDM. This may include installing the appropriate application from the Apple App Store or Google
Play.
4.
ISE enforces some device attributes before allowing network access. If the device is not ISE
Compliant, quarantine the device (explained below).
5.
If the device is not compliant with the MDM policies, quarantine the device.
If the user has been on-boarded and is compliant with ISE and MDM policies, allow the proper
permissions based on different rules.
Note
The previous chapters explained how to grant Full Access, Partial Access and Internet Only access to
personal and corporate devices.
17-5
Chapter 17
Figure 17-4
MDM Compliance Checks

Personal
Device (Onboarded)
MDM
Registered?
ISE
Quarantine
ISE
Compliant?
MDM
Quarantine
MDM
Compliant?
API call
API call
API call
Continue AuthZ
Rules
Full Access
Partial Access
Internet Only
293989
Internet
Until MDM
ISE Compliance Check

Once the device has been registered with the MDM, the ISE checks for certain device attributes before
allowing access to the network. This can serve as an additional check and the first opportunity to verify
some device attributes.
In this design guide, two device attributes were considered as the minimum for devices to obtain access
to the network:
Jailbroken or rooted devicesNot allowed into the network.
PIN lock enforcementDevices without a device PIN lock are denied access.
ISE makes the JailBrokenStatus and PinLockStatus API calls to the MDM to verify these attributes.
A compound condition was defined in the ISE to check for these two attributes. To define this compound
condition click Policy > Policy Elements > Conditions > Compound Conditions, as shown in
Figure 17-5.
17-6
Chapter 17

ISE Configuration
Figure 17-5
ISE_Non_Compliant
Additional dictionary attributes could be added to accommodate the security policies of each
organization.
MDM Compliance Check

For devices that have been on-boarded and have met the ISE compliance check, an additional API call
is made to the MDM to make sure the device has met all the compliance requirements established by the
MDM.
If the device is not fully compliant with the MDM, ISE grants access to the Internet and denies access
to all internal resources. When the user tries to access an internal resource, ISE redirects the session to
a portal, highlighting the steps required to be completed to meet the MDM compliance rules.
ISE makes the DeviceCompliantStatus API call to the MDM to verify compliance. The MDM establishes
what conditions result in a device being non-compliant.
ISE Configuration
Several ISE features play a role in verifying for ISE and MDM compliance before permissions can be
applied. Some of them include Logical Profiles, authorization rules, ACLs, and API calls to the MDM
to receive endpoint attributes.
Logical Profile
The profiling service in the Cisco ISE is able to identify devices connecting to the network to grant the
appropriate access to endpoints based on their device type. By collecting attributes of endpoints and
grouping them according to their profiles, unique policies may be enforced for specific type of devices.
A logical profile is a virtual container of objects that share a common attribute. One example of a logical
profile is a set of devices that includes all tablets or all smartphones. A second example is a set of all
Android or Apple devices. For the purposes of this design guide, a logical profile was created to include
the devices that are managed by the MDM. This allows the administrator to dynamically add or remove
devices managed by the MDM.
17-7
Chapter 17
ISE Configuration
Figure 17-6 shows the MDM Managed logical profile used to group devices allowed and managed or
licensed by the MDM. This logical profile is used when defining the ISE authorization policy and
includes devices profiled as Android, Samsung-Device, and Apple-Device. To configure this logical
profile on the ISE, click Policy > Profiling > Logical Profiles.
Figure 17-6
MDM Managed Logical Profile
The logical profile could be easily expanded to include other devices supported and managed by the
MDM without modifying the ISE authorization policy.
Authorization Policy
Figure 17-7 shows the ISE authorization rules used to enforce MDM and ISE compliance. These
authorization rules are executed after the user has on-boarded the mobile device and before additional
access (e.g., Full, Partial, Internet) to the network is granted.
17-8
Chapter 17

ISE Configuration
Figure 17-7
MDM Compliance Authorization Rules
MDM Enrollment Rule

This rule matches when the following conditions are met:
The endpoint connected via a wireless 802.1X SSID.
Logical Profile equals MDM ManagedThe device is managed and supported by the MDM.
The device has gone through the on-boarding process and registered with ISE.
The device has not registered with the MDM.
If these conditions match, the Internet Until MDM authorization profile is used. This profile is
configured to redirect nonregistered devices to the redirect URL highlighted in Figure 17-8.
17-9
Chapter 17
ISE Configuration
Figure 17-8
Internet Until MDM
The authorization profile relies on two named ACLs previously defined in the Wireless LAN Controller:
ACL_Internet_Redirect and ACL_Internet_Only. ACL_Internet_Redirect is shown as being applied to
the MDM Redirect setting in the figure above. ACL_Internet_Only is shown as being sent to the wireless
controller via the Radius:Airespace-ACL-Name attribute value (AV) pair in Figure 17-8. The behavior
of the two ACLs is slightly different between CUWN wireless controllers, such as the CT5508 and Flex
7500, and IOS XE based controllers, such as the CT5760 and Catalyst 3850.
Note
Within this document, wireless LAN Controller refers to either a standalone appliance such as the Cisco
CT5508, Flex 7500, or CT5760 wireless controllers or to wireless controller functionality integrated
within the Catalyst 3850 Series switch.
For CUWN wireless controllers, ACL_Internet_Redirect functions as both the ACL which controls web
redirection, as well as the ACL which controls what the wireless client is allowed to access on the
network. ACL_Internet_Only serves simply as a extra security configuration. CUWN wireless
controllers do not make use of this ACL when URL redirection is specified. For CUWN wireless
controllers the ACL_Internet_Redirect ACL shown in Figure 17-9 can be the same as the
ACL_Internet_Only ACL discussed in the previous chapters.
17-10
Chapter 17

ISE Configuration
Figure 17-9
ACL_Internet_Redirect
The ACL specifies the following access:
Note
192.168.0.0/16).
For Cisco IOS XE based wireless controllers, ACL_Internet_Redirect functions strictly as the ACL
which controls web redirection. ACL_Internet_Only functions as the ACL which controls what the
wireless client is allowed to access on the network. Hence IOS XE based wireless controllers make use
of both ACLs when URL redirection is specified. An example of the ACL_Internet_Redirect ACL for
Cisco IOS XE based wireless controllers is shown in Example 17-1.
Example 17-1 Internet Redirect ACL for IOS XE Based Controllers
!
ip access-list extended ACL_Internet_Redirect
deny
17-11
Chapter 17
ISE Configuration
deny
deny
permit
permit
permit
deny
ip
ip
ip
ip
ip
ip
any
any
any
any
any
any
host 10.230.1.45
host 10.225.49.15
10.0.0.0 0.255.255.255
172.16.0.0 0.15.255.255
192.168.0.0 0.0.255.255
any
Deny (do not redirect) DHCP access (bootpc and bootps).
Deny (do not redirect) IP access to and from the DNS server (10.230.1.45).
Deny (do not redirect) IP access to and from the ISE server (10.225.49.15).
Allow (redirect) IP access to and from the rest of the internal network IP address space (10.0.0.0 /8,
172.16.0.0 /12, 192.168.0.0 /16).
Deny (do not redirect) all other access to the Internet.
An example of the ACL_Internet_Only ACL for Cisco IOS XE based wireless controllers is shown in
Example 17-2.
Example 17-2 Access ACL for IOS XE Based Controllers
!
deny
ip any 10.0.0.0 0.255.255.255
deny
ip any 172.16.0.0 0.15.255.255
deny
ip any 192.168.0.0 0.0.255.255
permit ip any any
!
The above access-list specifies the following access:
Note
Deny IP access to and from the rest of the internal network IP address space (10.0.0.0 /8, 172.16.0.0
/12, 192.168.0.0 /16).
Allow access to all other addresses (Internet addresses).
The access list shown in Example 17-2 is generic and not intended to work for every organization. An
ACL should be more specific and only allow access to specific IP addresses and protocols in the required
direction. A common practice is to make the ACLs as detailed as possible and to define every entry down
to the port level.
The first time the user tries to browse an internal resource, the session is redirected to a page similar to
the one in Figure 17-10 providing a link to register with the appropriate MDM.
17-12
Chapter 17

ISE Configuration
Figure 17-10
Register with MDM
Remediate Non-ISE Compliant Rule

The connection originated using EAP-TLS authentication (defined as a compound condition, see
below).
The device does not comply with ISE requirements. The ISE_Non_Compliant compound condition
is highlighted in Figure 17-5.
Logical Profile equals MDM ManagedThe device is managed and supported by the MDM and is
If these conditions match, the ISE Quarantine authorization profile is used. This profile is
configured to redirect nonregistered devices to the redirect URL highlighted in Figure 17-11.
17-13
Chapter 17
ISE Configuration
Figure 17-11
ISE Quarantine Authorization Profile
The authorization profile relies on two named ACLs, previously defined in the Wireless LAN Controller:
ACL_ISE_Remediate_Redirect and ACL_ISE_Remediate. ACL_ISE_Remediate_Redirect is shown as
being applied to the MDM Redirect setting in Figure 17-11. ACL_ISE_Remediate is shown as being sent
to the wireless controller via the Radius:Airespace-ACL-Name attribute value (AV) pair in Figure 17-11.
The behavior of the two ACLs is slightly different between CUWN wireless controllers, such as the
CT5508 and Flex 7500, and IOS XE based controllers such as the CT5760 and Catalyst 3850.
For CUWN wireless controllers, ACL_ISE_Remediate_Redirect functions as both the ACL which
controls web redirection, as well as the ACL which controls what the wireless client is allowed to access
on the network. ACL_ISE_Remediate serves simply as a extra security configuration. CUWN wireless
controllers do not make use of this ACL when URL redirection is specified.
For CUWN wireless controllers the ACL_ISE_Remediate and ACL_ISE_Remediate_Redirect ACLs
can be the same. An example of the ACL_ISE_Remediate ACL is shown in Figure 17-12.
17-14
Chapter 17

ISE Configuration
Figure 17-12
ACL_ISE_Remediate
Note
Allow IP access to and from the MDM server (203.0.113.10).
Allow IP access to Apple Push Notification Server (23.0.0.0 /8 and 17.0.0.0 /8).
Allow IP access to Google Cloud Messaging (184.0.0.0 /8, 8.0.0.0 /8, 173.194.0.0 /16, 74.125.0.0
/16, 206.111.0.0 /16).
Deny IP access (redirect) to all other IP addresses.
17-15
Chapter 17
ISE Configuration
For Cisco IOS XE based wireless controllers, ACL_Internet_Redirect functions strictly as the ACL
which controls web redirection. ACL_Internet_Only functions as the ACL which controls what the
wireless client is allowed to access on the network. Hence IOS XE based wireless controllers make use
of both ACLs when URL redirection is specified. An example of the ACL_Internet_Redirect ACL for
Cisco IOS XE based wireless controllers is shown in Example 17-3.
Example 17-3 Remediate Redirect ACL for IOS XE Controllers
!
ip access-list extended ACL_ISE_Remediate_Redirect
deny
deny
ip any host 1.230.1.45
deny
ip any host 1.225.49.15
deny
ip any host 1.230.1.76
deny
ip any 63.128.76.0 0.0.0.255
deny
ip any 23.0.0.0 0.255.255.255
deny
ip any 17.0.0.0 0.255.255.255
deny
ip any 184.0.0.0 0.255.255.255
deny
ip any 8.0.0.0 0.255.255.255
deny
ip any 74.125.0.0 0.0.255.255
deny
ip any 173.194.0.0 0.0.255.255
deny
ip any 206.111.0.0 0.0.255.255
deny
ip any host 1.225.100.10
permit ip any any
!
Deny (do not redirect) DHCP traffic.
Deny IP access (do not redirect) to and from the DNS server (1.230.1.45).
Deny IP access (do not redirect) to and from the ISE server (1.225.42.15).
Deny IP access (do not redirect) to and from MDM servers (host 1.230.1.76 and subnet 63.128.76.0
/24).
Deny IP access (do not redirect) to Apple Push Notification Server (23.0.0.0 /8 and 17.0.0.0 /8).
Deny IP access (do not redirect) to Google Cloud Messaging (184.0.0.0 /8, 8.0.0.0 /8, 74.125.0.0
/16, 173.194.0.0 /16, 206.111.0.0 /16).
Permit IP access (redirect) traffic to all other IP addresses.
An example of the ACL_ISE_Remediate ACL for Cisco IOS XE based wireless controllers is shown in
Example 17-4.
Example 17-4 Remediate Access ACL for Cisco IOS XE Controller
!
ip access-list extended ACL_ISE_Remediate
permit ip any 63.128.76.0 0.0.0.255
permit ip any 23.0.0.0 0.255.255.255
permit ip any 17.0.0.0 0.255.255.255
permit ip any 184.0.0.0 0.255.255.255
17-16
Chapter 17

ISE Configuration
permit
permit
permit
permit
deny
ip
ip
ip
ip
ip
any
any
any
any
any
8.0.0.0 0.255.255.255
74.125.0.0 0.0.255.255
173.194.0.0 0.0.255.255
206.111.0.0 0.0.255.255
any
Note
Allow DHCP traffic.
Allow IP access to and from MDM servers (host 1.230.1.76 and subnet 63.128.76.0 /8).
Allow IP access to Apple Push Notification Server (23.0.0.0 /8 and 17.0.0.0 /8).
Allow IP access to Google Cloud Messaging (184.0.0.0 /8, 8.0.0.0 /8, 74.125.0.0 /16, 173.194.0.0
/16, 206.111.0.0 /16).
Permit IP access to all other IP addresses.
The access list shown in Example 17-4 is generic and not intended to work for every organization. An
ACL should be more specific and only allow access to specific IP addresses and protocols in the required
direction. A common practice is to make the ACLs as detailed as possible and to define every entry down
to the port level.
The Wireless_EAP-TLS compound condition checks for the following conditions:
Radius:NAS-Port-Type Equals Wireless - IEEE 802.11
To define this compound condition, click Policy > Conditions > Authorization > Compound
into one.
Figure 17-13
17-17
Chapter 17
ISE Configuration
Remediate Non-MDM Compliant Rule

The connection originated using EAP-TLS authentication, as defined by the Wireless_EAP-TLS

compound condition highlighted in Figure 17-13.
The device does not comply with MDM policies. The ISE makes the DeviceCompliantStatus API
call to the MDM to obtain this information.
Logical Profile equals MDM ManagedThe device is managed and supported by the MDM.
If these conditions match, the MDM Quarantine authorization profile is used. This profile is configured
to redirect nonregistered devices to the redirect URL highlighted in Figure 17-14.
Figure 17-14
MDM Quarantine Authorization Profile
The authorization profile relies on the same two named ACLs: ACL_Internet_Redirect and
ACL_Internet_Only previously discussed in Remediate Non-ISE Compliant Rule.
When the user tries to browse an internal resource, the session is redirected to page similar to the one in
Figure 17-15, indicating why the device is not compliant with the MDM policies.
17-18
Chapter 17

ISE Configuration
Figure 17-15
MDM Quarantine
For reference purposes, the complete authorization policy used during testing is shown in Figure 17-16.
The figure highlights the following sections:
1.
2.
On-boarding and MDM registration/remediation.
3.
4.
5.
6.
7.
17-19
Chapter 17
ISE Configuration
Figure 17-16
17-20
Chapter 17

MDM Reports
MDM Reports
Cisco ISE provides a logging mechanism that is used for auditing, fault management, and
troubleshooting. Several reports provide information related to endpoints. In Figure 17-17, the Mobile
Device Management report shows the endpoints connected to the ISE, and several attributes collected
from the MDM. Other reports provide additional information that may be used for reporting and
troubleshooting.
Figure 17-17
MDM Report
17-21
Chapter 17
MDM Reports
17-22
CH AP TE R
18

Previous chapters of this design guide have examined on-boarding employee personal devices to provide
full, partial, or Internet only access. The use of digital certificates provides an additional level of
authentication security by preventing the spoofing of device MAC addresses. Additionally, the use of
the guest portal for self-registration and the My-Devices portal streamline the on-boarding and
maintenance of employee personal devices, resulting in lower IT operating costs associated with
providing BYOD services.
Despite these benefits, a subset of organizations may still decide on a business policy which does not
on-board wireless employee personal devices, yet provides some access to corporate services and the
Internet for such devices. This may be because of one or more of the following reasons:
The organization does not have the desire or the ability to deploy digital certificates on employee
personal devices.
The employee may decide to opt-out of having the organization manage their personal device.
The organization does not wish to administratively manage and maintain separate lists of registered
corporate devices and BYOD devices which have full network access.
The organization may wish to simply restrict employee personal devices to outside of the
corporate firewall due to an unknown or un-trusted security posture of such devices.
Because of this, the following sections discuss design options for wireless employee personal devices
which do not involve on-boarding such devices. The designs are based around extending traditional
guest wireless access discussed in Chapter 21, BYOD Guest Wireless Access and providing similar
guest-like wireless access for employee personal devices.
Note
Throughout this chapter, it is assumed that corporate-owned devices will still be on-boarded as discussed
in Chapter 16, BYOD Limited Use CaseCorporate Devices. The use of a whitelist is still necessary
to prevent employee personal devices from getting full access to the corporate network.
Extending Guest Wireless Access to Employee Personal

Devices
The following sections discuss two methods for extending guest wireless access, discussed in
Chapter 21, BYOD Guest Wireless Access, to also allow employee personal devices access to the
guest network:
18-1
Chapter 18
Extending Guest Wireless Access to Employee Personal Devices
Allowing employees to provision guest credentials for themselves.
Extending guest web authentication (Web Auth) to also utilize the Microsoft Active Directory (AD)
database when authenticating guests and employees using personal devices.
Allowing Employees to Provision Guest Credentials for Themselves

Chapter 21, BYOD Guest Wireless Access, discusses provisioning guest credentials with the Cisco
ISE sponsor portal. The most basic form of extending guest wireless access to employee personal devices
is simply to allow employees to sponsor themselves as guests. Employees then manually connect to the
open guest SSID to utilize personal devices on the wireless guest network.
With the Cisco ISE sponsor portal, the sponsor authentication policy can be based on membership within
a particular Microsoft AD group. This was discussed in Configuring the Cisco ISE Sponsor Portal, which
discussed the use of Microsoft AD groups within the ISE sponsor group policy as a means to limit
sponsor access to the Cisco ISE server. This can equally be used to allow broader access to the ISE
sponsor portal simply by adding additional employees to those Microsoft AD groups. Alternatively a
new sponsor group can be created that allows individual employees to configure guest credentials yet
restricts them to being able to only modify credentials that they provisioned. An example is shown in
the figures below.
Figure 18-1
Example ISE Sponsor Group for Employees to Create Self Guest Credentials
Membership to this ISE sponsor group can then be restricted to a Microsoft AD group via the ISE
sponsor group policy, as shown in Figure 18-2.
18-2
Chapter 18

Figure 18-2
Example ISE Sponsor Group Policy for Employees to Create Self Guest Credentials
In this example, access to the sponsor group is limited to those members of the Microsoft Active
Directory domain who are members of the group Users/Domain Users. The exact condition for the
example is of the form:
AD1:ExternalGroups EQUALS uatest.com/Users/Domain Users
The Microsoft Active Directory domain is uatest.com in this example. Note that the Microsoft Active
Directory server must be configured as an external identity source to select this option. In this example
it is known by the name AD1.
One advantage of this design is that an audit trail exists through the ISE Reports for employees
authenticating to the ISE sponsor portal. The ISE Sponsor Mapping report shows when the employee
created a guest credential as well as the guest credential created. The ISE Sponsor Mapping report can
be run over various time ranges from 30 minutes up to 30 days or a custom time range can be requested.
This report can be used to gain a rough idea of which employees are accessing the ISE sponsor portal to
create guest credentials and how often. An example is shown in Figure 18-3.
Figure 18-3
Example of the Audit Trail for an Employee Accessing the ISE Sponsor Portal
Note that this method of allowing employees the ability to create guest credentials for themselves does
not prevent them from creating credentials for true guests who are visiting the organization. Corporate
business policy should dictate that true guest credentials only be added by authorized members of
18-3
Chapter 18
sponsor groups, as discussed in Chapter 21, BYOD Guest Wireless Access. The next design option
eliminates this issue by removing the ability for employees to create guest credentials for themselves
altogether.
Extending Web Auth to Use Microsoft AD when Authenticating Employees with

Personal Devices
The previous section discussed the most basic way of extending guest wireless access to allow
employees with personal devices to access the guest network. That method simply allows employees to
configure guest credentials for themselves via the Cisco ISE sponsor portal. Although this provides
several advantages over methods such as utilizing a shared sponsor account on the guest wireless
controller for adding credentials, it still has several shortcomings. Employees must still provision
temporary guest credentials for themselves. Finally, there is nothing preventing the employee from
sponsoring a true guest, other than corporate business policy.
An alternative means of providing access to the guest wireless network for employee personal devices
is to simply allow the ISE server to check multiple identity sources for credentials when performing web
authentication (Web Auth). For example, the ISE server could first check its internal identity groups
(local database) for guest credentials. If the credentials are not found there, then check the Microsoft AD
external identity store to see if the person accessing the guest network is an employee instead of a guest.
Cisco ISE Policy Configuration in Chapter 21, BYOD Guest Wireless Access discusses the use of a
user-defined identity source sequence called Guest_Portal_Sequence for authenticating guest access via
Web Auth. The Guest_Portal_Sequence uses the Internal Users identity source only. This can easily be
extended by adding a Microsoft Active Directory (AD1) external identity source to the sequence, as
18-4
Chapter 18

Figure 18-4
Example of Guest_Portal_Access Identity Source Sequence Extended to Include AD
This configuration now allows employees who are in the Microsoft Active Directory database to access
the guest wireless network from their personal devices once they have performed web authentication and
accepted the Acceptable Use Policy (AUP) or End User Agreement (EUA).
Note
This allows employees to access the guest wireless network from corporate-owned devices as well, since
the authentication and authorization decision is based on Microsoft Active Directory userid and
password only. The device itself is not considered within the authentication and authorization decision.
Deploying Guest-Like Wireless Access for Employee Personal

Devices
The previous sections discussed options for extending access to the wireless guest network for
employees with personal devices, either by allowing employees to configure guest credentials for
themselves or by extending Web Auth to also check the Microsoft AD database where employee
credentials are kept. With these options, employee personal devices share the same wireless SSID as
guest devices. Employee personal devices also share the same IP subnet address space as guest devices,
since they terminate on the same DMZ segment of the ASA firewall. Essentially the employees personal
device is treated as a guest on the network, which can bring up potential concerns.
18-5
Chapter 18
Since IP subnet space is shared between guest devices and employee personal devices, there can be some
concern that employee personal devices could deplete the IP addressing space, limiting the ability of
guest devices to gain access to the guest network or vice-versa.
The ASA firewall guest DMZ interface ingress policy can be modified to allow certain application flows
inbound from the guest network to a mirror of the company website server, dedicated for employee
personal devices, sitting on other DMZ segments. This is discussed further in Accessing Corporate
Resources. However, the ASA firewall policy would not be able to distinguish between guest devices
and employee personal devices, since they share the same IP subnet address space. Therefore,
application level access control at the mirror web server itself is necessary to prevent guests from
accessing services on it. Likewise, the ASA firewall guest DMZ interface ingress policy could be
modified to allow traffic from a virtual clientsuch as a Citrix or VMware clientinbound to internal
Citrix or VMware servers. Again, the ASA firewall policy would not be able to distinguish between true
guest devices and employee personal devices, since they share the same IP subnet address space.
Application level access control at the Citrix or VMware server would be necessary to prevent guests
from accessing these servers.
Since the guest SSID is typically open with no encryption, traffic from employee personal devices will
be in the clear, unless the devices use either secure applications or some form of VPN tunneling, which
encrypts the traffic. Although web traffic can be made secure simply by requiring the use of HTTPS, not
all applications used by employee personal devices may be encrypted. This leaves some vulnerability
which must be considered by security operations personnel, especially any site that authenticates using
the employee's corporate login and password. If internal company data is being accessed from employee
personal devices via the guest wireless network, then that information should be encrypted to prevent
eavesdropping. Allowing employee devices to launch a VPN client to establish an IPsec VPN
session-either directly to the ASA firewall or out to the Internet and back to another corporate VPN
concentrator-may be one alternative. Another option is the establishment of an SSL VPN tunnel to the
ASA firewall for employee devices. Both of these options may also require per-user authentication.
Note
Ciscos implementation of Web Auth uses HTTPS when redirecting the web session and requesting
credentials.
Because of these concerns, security operations personnel may be hesitant to allow anything but Internet
access for any device accessing the guest network, whether it is a true guest device or an employee
personal device.
As in Chapter 21, BYOD Guest Wireless Access, two distinct terminologies are used in this chapter.
The first pair of terminologies is guest controller and campus controller. The guest controller is a
dedicated controller that is used for dealing with guest and employee personal device traffic. The campus
controller is dedicated for handling internal traffic. Note that the term campus controller is used
somewhat generically here. The campus controller discussed within this chapter may refer to a
standalone wireless controller platform deployed within a campus location or wireless controller
functionality integrated within Catalyst 3850 Series switches deployed within a branch location.
The second set of terminologies is foreign controller and anchor controller. These two terminologies are
used when a user roams from one controller to another controller. The new controller to which the user
associates is the foreign controller. This controller anchors all the traffic to the old controller, which
becomes the anchor controller. These terminologies are used in this document.
18-6
Chapter 18

Dedicated SSID for Employee Personal Devices

This section discusses another option in which a second guest-like wireless SSID is provisioned for
employee personal devices. This SSID is auto-anchored to another DMZ segment off of the ASA
firewall, in a similar fashion as the wireless guest SSID. An example of this design using CUWN
infrastructure is shown in Figure 18-5.
Guest-Like Wireless Access for Employee Personal Devices Using CUWN Infrastructure
Branch
Internet Edge
CAPWAP
CAPWAP
WAN
CAPWAP
Tunnels
Internet
ASA
Firewall
CT5508 Guest
Anchor Controller
BYOD_Personal_Device
SSID
Campus
Building
Personal
Device
VLAN
Flex 7500
WLC
ISE
CAPWAP
CAPWAP
CT5508 WLC
BYOD_Personal_Device SSID
AD
Ethernet-over-IP
Mobility Anchor
Tunnels
Data Center
294060
Figure 18-5
With the auto-anchor mobility feature of Cisco wireless controllers, packets from the wireless client are
encapsulated through a mobility tunnel between the internal wireless controller (known as the foreign
controller) to the guest wireless controller (known as the anchor controller), where they are
de-capsulated and delivered to the wired network.
A similar example of this design using a Converged Access wireless infrastructure is shown in
Figure 18-6.
18-7
Chapter 18
Guest-Like Wireless Access for Employee Personal Devices Using Converged Access Infrastructure
Branch
CAPWAP
CAPWAP
Internet Edge
Catalyst 3850
Series Switch
MC
MA
WAN
Personal
Device
VLAN
CT5508 Guest
Anchor Controller
SSID
CAPWAP
Tunnels
Campus
CAPWAP
CAPWAP
SSID
Internet
ASA
Firewall
ISE
MC
MA
Catalyst 3850
Series Switch
CT5760 or
CT5508 WLC
CAPWAP Mobility
Anchor Tunnels
Data Center
AD
293841
Figure 18-6
The auto-anchor mobility feature also applies to the Converged Access Infrastructure. Note that with the
Converged Access branch design shown in Figure 18-6, the Catalyst 3850 switch within the branch
implements both the Mobility Agent (MA) and Mobility Controller (MC) function. With the Converged
Access campus design, the Catalyst 3850 switch only implements the MA function. The MC function is
implemented by a dedicated CT5760 wireless controller. Since the auto-anchor tunnel is initiated from
the MC within a Converged Access design, traffic is first tunneled from the campus Catalyst 3850 switch
to the CT5760 wireless controller, where it is then auto-anchored to the guest anchor controller within
the DMZ. For additional discussion regarding the MA and MC functionality within Converged Access
infrastructure, see Configuring the Infrastructure.
Note
In this version of the design guide, it is assumed that employees with personal devices would need to
manually associate with this SSID. Future versions may investigate other alternatives that make use of
RADIUS change-of-authentication (CoA) functionality or device profiles.
An advantage of implementing a dedicated SSID for employee personal devices is that the SSID does
not have to be configured with open access and can be encrypted, unlike the guest SSID discussed
throughout this design guide. Instead, the employee personal device SSID can be secured via
mechanisms such as 802.1X authentication and WPA-2/AES encryption to prevent eavesdropping of
traffic from employee personal devices. Employees can be authenticated via the Cisco ISE server using
the external Microsoft AD identity source as they associate with the SSID.
Another advantage of implementing a dedicated SSID for employee personal devices is that the devices
can be isolated from guest devices by provisioning separate VLANs for each SSID. Separate DMZ
segments-implemented as separate physical interfaces off of the ASA firewall or as separate VLAN
sub-interfaces off a single physical interface of the ASA firewall-can be deployed. Each DMZ interface
now has a separate IP subnet address space and a separate access-control policy. This expands the IP
addressing space deployed for guest devices as well as employee personal devices and removes the issue
of employee personal devices causing IP address starvation issues for guest devices and vice-versa. The
guest DMZ can be configured to allow only Internet access for guest devices. The employee personal
18-8
Chapter 18

device DMZ can be configured to allow Internet access, as well as access to a mirror web server sitting
on another DMZ segment. Additional access can be allowed by modifying the ASA firewall personal
device DMZ interface ingress policy to allow traffic from a virtual client-such as a Citrix or VMware
client-inbound to internal Citrix or VMware servers. Access can also be extended by allowing employee
personal devices to launch a VPN client to establish an IPsec VPN session, either directly to the ASA
firewall or out to the Internet and back to another corporate VPN concentrator. Another option is the
establishment of an SSL VPN tunnel to the ASA firewall for employee personal devices.
Wireless Controller Configuration

To deploy this option in which a second guest-like wireless SSID is provisioned for employee personal
devices, both the campus (foreign) wireless controllers and the guest (anchor) controller need to be
configured with a new WLAN for employee personal devices. This WLAN has a unique SSID different
from the corporate WLAN and the guest WLAN.
Campus Controller Configuration

This section discusses configurations when using either CUWN wireless controllers or Converged
Access (IOS XE based) wireless controllers for the campus controller.
CUWN Wireless Controller Configuration

An example of a CUWN campus controller configuration is shown in Figure 18-7, in which the new
WLAN is called the BYOD_Personal_Device WLAN.
Figure 18-7
Example Configuration of a CUWN Campus Wireless Controller for the Employee

Personal Devices WLAN
The WLAN is configured for WPA2 security with AES as the cipher, along with 802.1X authenticated
key management. Next, the WLAN on the campus (foreign) controller needs to be configured with a
mobility anchor pointing at the management interface of the guest (anchor) controller. An example is
shown in Figure 18-8. Note that in branch scenarios which utilize a FlexConnect wireless design, the
controller servicing branch APs will be the foreign controller for the branch personal device WLAN.
18-9
Chapter 18
Figure 18-8
Example Configuration of the Mobility Anchor on a Campus CUWN Wireless

Controllers
Note that the campus controller and the guest controller must be part of the same mobility group before
the mobility anchor can be configured. The mobility anchors establish the mobility tunnel through which
packets from the wireless client are automatically encapsulated and sent from the campus controller to
the guest controller where they are de-capsulated and delivered to the wired network.
The network administrator must also configure the employee personal devices WLAN to use RADIUS
within the campus controller for authentication. This is shown in Figure 18-9.
Figure 18-9
Authentication via RADIUS for the Employee Personal Devices WLAN on the Campus
Controller
18-10
Chapter 18

Since Web Auth is not involved with this option, there is no redirection of web sessions to a guest portal
and hence no configuration required within the guest controller for Web Auth or any requirement for a
pre-authentication ACL. When an employee personal device connects to the SSID, the RADIUS session
is initiated by the campus controller management interface to the Cisco ISE server for authentication and
authorization. Upon successful authentication, the employees personal device is then anchored to the
guest controller.
Converged Access (IOS XE Based) Wireless Controller Configuration

The following partial configuration shows an example of the employee personal devices WLAN along
with part of the AAA server configuration on an IOS XE based wireless controller.
!
aaa new-model
!
!
!
!
dot1x system-auth-control
!
ip http server
!
radius-server attribute 6 on-for-login-auth
radius-server attribute 8 include-in-access-req
radius-server attribute 25 access-request include
radius-server attribute 31 send nas-port-detail
radius-server dead-criteria time 5 tries 3
radius-server host 10.225.49.15 auth-port 1812 acct-port 1813 key 7 1237161E060E5D56797F71
!
/Radius server in the line above points to ISE
!
wlan BYOD_Personal_Device 4 BYOD_Personal_Device/Defines the personal devices WLAN and
SSID
client vlan Guest/Static assignment to non-routed (isolated) VLAN
mobility anchor 10.225.50.35/Creates an anchor tunnel to the guest wireless controller
no shutdown
/Enables the employee devices WLAN
!
By default WPA2 with AES as the cipher is enabled, along with 802.1X authenticated key management.
Hence they do not show up in the configuration. The administrative-level show wlan id <wlan ID
number> command can be used to display additional details regarding the configuration of the WLAN,
including default values which do not appear within the configuration.
The employee devices WLAN must be configured on the device which functions as the Mobility Agent
(MA) and on the device which functions as the Mobility Controller (MC). Therefore the configuration
above is basically the same, regardless of whether a Catalyst 3850 Series switch is deployed as both the
MA and MC within a branch deployment, a Catalyst 3850 Series switch is deployed as only an MA
within a campus deployment, or a CT5760 wireless controller is deployed as an MA and MC within a
campus deployment.
The Guest client VLAN in the configuration above is a VLAN which is isolated on the CT5760 wireless
controller or Catalyst 3850 Series switch. It is not trunked to the adjacent Layer 3 device. This isolates
any guest devices should the CAPWAP tunnel between the foreign and anchor controllers go down.
18-11
Chapter 18
The following partial configuration example shows the configuration of the mobility group and mobility
group members on an IOS XE based wireless controller.
!
wireless mobility group member ip 10.225.50.35 public-ip 10.225.50.35/Guest Controller
wireless mobility group name byod/Mobility group name
!
The mobility group name and mobility group peers must appear on the device which functions as the
Mobility Controller (MC). Therefore, when a Catalyst 3850 Series switch is deployed as both the MA
and MC within a branch deployment, the configuration must include the above two lines. A Catalyst
3850 Series switch deployed as only an MA within a campus deployment would not include the mobility
group configuration. Instead the CT5760 wireless controller deployed as a MA and MC within a campus
would contain the mobility group configuration. Note that since IOS XE based wireless controllers only
support the new hierarchical mobility architecture; no configuration is required to enable it.
Note
Cisco wireless controllers currently support two different mobility architectures. The old mobility
architecture relies on Ethernet-over-IP tunnels between wireless controllers. The new mobility
architecture, also called the hierarchical mobility architecture, relies on CAPWAP tunnels between
wireless controllers. The two mobility architectures are not compatible with each other. If mobility
(including the auto-anchoring function) is required between wireless controllers, all wireless controllers
must be running either the new mobility or the old mobility architecture. The new mobility architecture
is supported on Cisco 5508 and WiSM2 wireless controllers with software release 7.3.112 and on the
Cisco 5508, WiSM2, and 2504 wireless controllers with software release 7.5. The new mobility
architecture is supported on the Cisco 5760 wireless controller and the Catalyst 3850 Series switch with
IOS XE software releases 3.2.0SE and 3.2.2SE. CUWN wireless controller release 7.4 and releases
below 7.3.112 support only the old mobility architecture. The Cisco Flex 7500, 8500, and vWLC do not
support the new mobility architecture. IOS XE based wireless controllers do not support the old mobility
architecture. Hence if a network contains both Flex 7500 wireless controllers and Converged Access
controllers, then separate sets of guest wireless controllers must be deployed with the DMZ to support
both mobility architectures with the guest wireless design discussed in this design guide.
Guest Controller Configuration

The guest controller is the point where all the employee device traffic is terminated. For this version of
the design guide, the discussion only includes a CT5508 CUWN wireless controller as the guest
controller. An example of a guest controller configuration for the employee personal devices WLAN is
Figure 18-10
Example Configuration of a Guest Wireless Controller for the Employee Personal

Devices WLAN
As can be seen, the configuration of the WLAN on the guest controller must match the configuration of
the WLAN on the campus controller.
18-12
Chapter 18

The guest controller needs to be configured with a mobility anchor pointing at itself. An example is
Figure 18-11
Example Configuration of the Mobility Anchor on a Guest CUWN Wireless Controller
Again, this assumes the campus controller and the guest controller are configured to be part of the same
mobility group before the mobility anchor is configured.
The network administrator must also configure the employee personal devices WLAN to use RADIUS
within the guest controller for authentication. This is shown in Figure 18-12.
Figure 18-12
Authentication via RADIUS for the Employee Personal Devices WLAN on the Guest
Controller
18-13
Chapter 18
Finally, in order to support the new mobility architecture (also referred to as the hierarchical mobility
architecture), the network administrator must check the Enable Hierarchical Architecture option within
the global mobility configuration of both the campus and guest controller. An example is shown in
Figure 18-13.
Figure 18-13
Note
Enabling the Hierarchical Mobility Architecture
Since the Flex 7500 wireless controller does not support the new mobility architecture, this step can be
skipped in deployments involving a Flex 7500 as the branch wireless controller.
Cisco ISE Policy Configuration

From a Cisco ISE policy perspective, the existing authentication rulewhich is used to support both the
on-boarding of corporate-owned (IT-managed) devices and the authentication of on-boarded
corporate-owned devices within the Limited Access use casecan also be used to support wireless
employee personal devices for the Basic Access use case. An example of such a policy rule is shown in
Figure 18-14.
18-14
Chapter 18

Figure 18-14
Example of Cisco ISE Authentication Policy Allowing Wireless Employee Personal

Device Access
The logical format of the authentication policy rule for this example is:
IF (Wired_802.1X OR Wireless_802.1X)
THEN (Allow Default Network Access AND
IF Network Access:EapAuthentication EQUALS EAP-TLS USE Certificate_Profile
IF Network Access:EapTunnel EQUALS PEAP USE AD1
ELSE Default EQUALS DenyAccess)
Wired_802.1X is a system-generated compound condition that is used here to match 802.1X-based

authentication requests from switches. It matches the following two standard RADIUS dictionary
attribute-value (AV) pairs:
Service-Type - [6] EQUALS Framed
NAS-Port-Type - [61] EQUALS Ethernet
Wireless_802.1X is a system-generated compound condition that is used here to match 802.1X-based

authentication requests from Cisco wireless controllers. It matches the following two standard RADIUS
dictionary attribute-value (AV) pairs:
NAS-Port-Type - [61] EQUALS Wireless - IEEE 802.11
Default Network Access is a system-generated authentication result, which allows various EAP
protocols to be used for authentication.
Certificate_Profile is a user-defined Certificate Authentication Profile configured under the External
Identity Sources section of the Cisco ISE server.
AD1 corresponds to the Microsoft Active Directory identity store, where employee credentials are
typically held within an organization.
For the Basic Access use case, wireless employee personal devices which use PEAP for authentication
will match on the second conditionIF Network Access:EapTunnel EQUALS PEAP USE
AD1causing these devices to proceed to the authorization phase. Note that the example above works
for employee personal devices which utilize PEAP authentication only. If the customer requires other
authentication or EAP methods, additional conditions would need to be added to the above
authentication policy rule. These conditions could also use the AD1 Microsoft Active Directory identity
store to verify employee user credentials. Alternatively, the default condition could be changed from
denying access to also using the AD1 identity store.
18-15
Chapter 18
From a Cisco ISE policy perspective, an additional authorization rule needs to be added in order to
support the Basic Access use case. This rule permits access for devices using PEAP authentication,
which originate from the SSID corresponding to the employee personal devices WLAN. An example of
the policy rule is shown in Figure 18-15.
Figure 18-15
Example of Cisco ISE Authorization Policy Allowing Wireless Employee Personal

Device Access
The logical format of the authorization policy rule for this example is:
IF (Wireless_PEAP AND Personal_Device_WLAN)
THEN PermitAccess
Wireless_PEAP is a user-defined compound authorization condition that is used here to match

authentication requests from wireless PEAP devices. It matches the following two standard RADIUS
dictionary attribute-value (AV) pairs, along with a Network Access condition which specifies the use of
PEAP.
Network Access:EapTunnel EQUALS PEAP
Personal_Device_WLAN is a user-defined simple authorization condition for employee personal

devices that access the network via the WLAN corresponding to the employee personal devices SSID.
It matches the following RADIUS AV pair from the Airespace dictionary:
Airespace-Wlan-Id - [1] EQUALS 4
The Airespace-Wlan-Id is the identification number (WLAN ID) of the WLAN corresponding to the
employee personal devices SSID. This is shown in Figure 18-16.
18-16
Chapter 18

Figure 18-16
Example Wireless Controller WLAN IDs Showing Employee Personal Devices WLAN
and SSID
Note that this WLAN ID must be consistent across the entire BYOD deployment. This rule allows the
ISE authorization policy to differentiate 802.1X authentication requests coming from the employee
personal devices SSID and simply permit access. A WLAN ID cannot be changed on an existing WLAN.
To change a WLAN ID, the WLAN must be removed and created again.
ASA Firewall Configuration

Figure 18-17 shows an example of the flows that need to pass through the Cisco ASA firewall to support
this option.
18-17
Chapter 18
Figure 18-17
Example of Flows that Need to Pass Through the Cisco ASA Firewall for Employee Personal Devices
Cisco ISE (AAA)
DHCP
Inside
Campus
(Foreign)
Wireless Controller
Internal DNS
Outside
Campus Network
Internet
Sponsor PC
DHCP Flows
Employee
Personal
Devices
DMZ
DNS Flows
Radius Flows
Guest Data Flows
Guest
Wireless
DMZ
Wireless
Guest
Device
DMZ #3
294072
Wireless Employee
Personal Device
Guest Anchor
Wireless
Controller
Management
Interface
DMZ #2
CAPWAP Mobility
Tunnel Flows
External
DNS
Server
The RADIUS session is initiated by the campus (foreign) wireless controller management interface to
the Cisco ISE server for authentication and authorization. Therefore it does not need to be allowed
through the ASA firewall for employees who are authenticating with personal devices. If using the newer
hierarchical mobility architecture (as indicated in Figure 18-17), a CAPWAP auto-anchor mobility
tunnel (UDP ports 5246 and 5247) between the management interfaces of the two wireless controllers
must be allowed through the ASA firewall. If using the older mobility tunnel architecture, an
Ethernet-over-IP (IP protocol 97) auto-anchor mobility tunnel, as well as the WLAN control port (UDP
port 16666) between the management interfaces of the two wireless controllers, must be allowed through
the ASA firewall.
Besides allowing DNS and DHCP (assuming the deployment of an internal DHCP server), the ASA
firewall should be configured to block all other traffic generated from employee personal devices onto
the internal network. Additional ports can be opened to accommodate the access of corporate resources
as discussed in the following section and summarized in Table 21-2.
Note
Additional ASA firewall ports may need to be opened to accommodate guest wireless access, depending
upon the deployment model discussed in Chapter 21, BYOD Guest Wireless Access.
18-18
Chapter 18

Differentiated Quality of Service Treatment

With this deployment model, a separate QoS policy can be applied to employee personal devices,
different from guest wireless devices. This is because wireless employee personal devices are terminated
on a separate WLAN from wireless guest devices. For CUWN wireless controllers, as of software
version 7.2, QoS is applied per WLAN by way of a profile, as shown in Figure 18-18.
Figure 18-18
Note
Example of QoS Profile Applied to a WLAN
IOS XE based wireless controllers support much more extensive QoS capabilities. However they also
have the ability to support similar QoS per WLAN based on the older profiles model of CUWN wireless
controllers. This version of the design guide does not address QoS on IOS XE based wireless controllers.
Future versions will discuss this topic more thoroughly.
This may be desirable if employee personal devices are going to be allowed to run virtual desktop client
applications such as a Citrix client or VMware client or if employee personal devices run collaboration
clients such as Cisco Jabber.
18-19
Chapter 18
Accessing Corporate Resources
Note
Chapter 21, BYOD Guest Wireless Access discusses rate limiting per-SSID and per-User. These
features can be used for employee personal devices as they were for guest devices. Rate limiting is
configured on the campus (foreign) controller and not the guest (anchor) controller.

Because employee devices are associated to the network from a DMZ interface, which is effectively
outside of the corporate firewall, they do not have access to company resources located inside the
firewall. This may be perfectly acceptable and desirable. Employee devices still have access to the public
Internet. This enables them to connect to cloud-based resources such as Cisco WebEx or partner
websites. The employee device is afforded some level of usability, making the device useful as a
productivity tool.
Companies may want to offer access to additional resources but still maintain the security offered by
restricting employee devices to the guest side of the firewall. There are various options available to
accomplish this objective, including:
Setting up a mirror of the company website
Allowing VPN access
Allowing virtual desktop client access
Securing Mirror Sites for Personal Devices

One approach to bringing services to employee personal devices accessing the guest network is to set up
a mirror of the company website in another DMZ segment, referred to as an employee device security
zone (EDSZ) within this section. If employee personal devices connect to the guest wireless network,
the website will only be accessible after the user has completed the Web Auth process and accepted an
Acceptable Use Policy (AUP) or End User Agreement (EUA). This website does not need to be an exact
match of an internal website, but could contain relevant content that employees can use on their personal
devices to make them more effective. In addition, the website could include content optimized for
smaller mobile displays. Examples of applications that could be offered in the EDSZ include access to
email, a team wiki page, or the company news site.
There are several methods available to setup a secure website. In general, the deployment is very similar
to a typical DMZ web service, except that rather than residing in an Internet facing DMZ, the server is
located on a subnet accessible by employee personal devices. The intent of this section is not to provide
detailed guidance on the deployment of a presentation server, application server, and database server.
Site administrators should be familiar with the approach that best fits their security environment. Some
high level considerations when setting up the server include:
Dual attachmentUsually this is considered to be more secure. The client-side NIC should
implement firewall services that allow inbound connections on TCP port 80 or 443. Only session
requests initiated by the client subnets should be allowed towards the server. Session requests
initiated by the server should not be allowed towards the client subnets. If the employee device
wireless network is encrypted, then some organizations may be comfortable allowing users to attach
via HTTP.
18-20
Chapter 18

The back-end NIC should be used to move content between the server and the data store or
application server. It may also be allowed for remote administration of the site. Single-attached
servers are possible although usually a dedicated and secured gateway is setup for the
server-to-server communications that is separate from the server-to-web client gateway.
Content DeliveryGenerally content is either static or dynamic. Static content can be pushed
overnight or as needed to keep the website current. Dynamic content could allow the employee
device to post information to the site. The website could use a local data store that is synchronized
with an external data store or have a secured channel to an application server.
User AuthenticationSome method should be used to ensure only authorized and authenticated
users are able to view site content. Utilizing Microsoft Active Directory or a local user database are
two possible methods. Active Server pages (ASP.NET) can also be used to leverage the login
controls used with Microsoft Internet Information Server (IIS) servers and provide a more
sophisticated authentication model such as single sign-on (SSO). Local databases are easier to setup
but require a high level of administrative overhead and are usually only appropriate in very small
organizations.
Secure SocketsWebsites in the employee device security zone (EDSZ) should implement secure
socket layer (SSL) or transport layer security (TLS) if employees are sending sensitive information,
such as their login credentials. This can be relaxed somewhat if the EDSZ has been implemented
with wireless encryption. On the other hand, if employee devices reside in the traditional guest
network where wireless packets are not typically protected with encryption and are co-mingled with
actual guest traffic, then SSL/TLS websites are needed. This is particularly important if employees
are passing their corporate credentials to a mirror website.
Web Server softwareThere is a wide range of web server software available. Deciding which type
of server to deploy impacts what security features are available. Common choices include Microsoft
IIS, Apple, and Tomcat. Wikipedia has a comparison of web server software that can illustrate the
choices available (http://en.wikipedia.org/wiki/Comparison_of_web_server_software). It is also
possible to host sites on a secure cloud service. This service could be restricted to IP addresses or
require client side certificates. With proper security precautions, a cloud-based site could also allow
mobile employees access to some traditional corporate resources such as payroll or benefits that are
increasingly finding their way to the cloud.
Figure 18-19 illustrates a simple scenario where static content is deployed in a DMZ dedicated for
employees using personal devices. A Windows 2008 server is deployed with Microsoft IIS 7.0 as well
as some other network services specific to the DMZ, such as DNS and Read-Only Directory Services
(RODS). Users are authenticated against the corporate Microsoft Active Directory server. The RODS
service requires DNS to be installed on the same server. The web server is typically a dedicated box.
However, in some situations it may be desirable to run RODS and IIS on the same server to simplify
basic authentication using Microsoft AD. It is more appropriate when supporting a small-to-modest
number of employee devices.
18-21
Chapter 18
Figure 18-19
Example of a Mirror Website for Employee Personal Devices
Outside
Cisco ISE (AAA)
DHCP
Internal DNS
Internal
Wireless
Controller
Internet
Campus
Network
Inside
WebDAV, CIFS, SFTP
DNS Flows
Guest
Wireless
DMZ
HTTP Flows
Guest DMZ Interface
Tunneled Wireless
Guest Device
Wireless
Controller
Management
Interface
DMZ #2
External
Web
DNS RODS Server
Server
DMZ #3
294074
Employee Personal
Device Data Flows
Moving content to the secured server can be done by various means. One approach is to use FTP,
however because FTP is not secured, a better approach is to use either SFTP or FTP over SSL. By
default, Microsoft IIS does not ship with a secure FTP server. Microsoft supports FTP over SSL rather
than SFTP. Administrators must copy the installation package from Microsofts website
(http://learn.iis.net/page.aspx/310/what-is-new-for-microsoft-and-ftp-in-iis-7/) and install the feature
on their server. If FTP is already running, the administrator needs to deselect the FTP feature from the
services manager prior to installing the FTP over SSL server. The improved FTP over SSL server offers
additional tools not available in the standard FTP package that are used to manage access to the FTP site,
Figure 18-20
Example of Tools Available with the FTP over SSL Server
18-22
Chapter 18

Anonymous authentication should be disabled and at least basic authentication should be enabled. There
are other options that may be appropriate from some organizations.
Instead of FTP over SSL, administrators can choose to use Web Distributed Authoring and Versioning
(WebDAV). This method offers more flexibility than FTP because many operating systems allow the
connection to be mounted to the file system. By providing a directory handle, web authoring applications
as well as other applications can directly use the secured pipe. WebDAV is based on HTTP or HTTPS
and provides the ability to authenticate and encrypt data. If employees are placed directly in the guest
SSID, then WebDAV HTTPS should be used since passwords are sent. If employee devices are placed
in an encrypted EDSZ, then WebDAV HTTPS could be used to provide an additional layer of encryption.
The security considerations are detailed in section 20 of RFC4918.
Another option similar to WebDAV is CIFS. This protocol also allows local directory mounts of the
remote site. It is commonly found in Microsoft environments, although Samba is available for
non-Windows servers. Microsoft also supports SMB2 with Vista, Windows 7, and Windows 8, which is
an update to CIFS. There are several other approaches that provide a secure path between either the web
authoring site or the application server. A particular enterprise will likely leverage the same methods as
the web servers located in the traditional DMZ.
DNS Support
The employee devices need access to a DNS server. If the EDSZ web server is using RODS, then DNS
is already available on the Directory Server. It is installed by default when the RODS is setup unless the
administrator explicitly chooses not to. Dynamic updates are secured and zone transfers are not enabled.
If the web server is not using AD for employee authentication, then DNS will be a standalone service.
Outlook Web Access for Employee Devices

Email is a foundational service that can be offered to employee devices. This can be accomplished by
deploying a web interface to the mail server such as Outlook Web Access (OWA) or ActiveSync for
exchange environments. Some enterprises may already be offering this service for employees that need
email while traveling. In this case, the employee devices can continue to use the current Internet facing
OWA server.
Microsoft does not support the OWA server in a DMZ zone. Instead, the OWA server should be behind
the firewall. Holes can be opened for port 443. Another option is to setup Apache in the EDSZ as a
reverse proxy. The Microsoft recommended approach is to run OWA on the client access server (CAS)
and publish the CAS with Microsofts Internet security and acceleration (ISA) server into the EDSZ.
This is a full blown deployment and may not be appropriate as a method to grant employee personal
device access due to the complexity involved versus other methods, such as simply opening a hole in the
EDSZ DMZ firewall for HTTPS to the enterprise CAS.
Another option is subscribing to Office365, which is Microsofts cloud-based Exchange and Office
environment. In this case, employees would use the public Internet service to gain access to their email
or other cloud-based enterprise resources. At this time, there is not a native Office365 application for
either Android or iOS devices and users would be restricted to HTTPS access unless they were using a
Windows 8-based mobile device. This method would also allow Direct-To-Cloud over 3G/4G or
off-premise accesses to the same resources. Microsoft is only one of many cloud based enterprise
environments offering email services.
18-23
Chapter 18
ActiveSync Support
Future versions of this document will discuss mobile device managers (MDM) that are used to manage
the configuration profiles of mobile devices and provide additional security features needed for lost or
stolen devices. Some of the MDM functionality is licensed from Microsoft, including remote-wipe, PIN
lock enforcement, and others. ActiveSync is used to synchronize email, calendar events, and contacts
between the Microsoft Exchange server and the mobile devices email application. Administrators may
be interested in providing ActiveSync to devices in the employee device security zone (EDSZ). When
properly configured and certified, ActiveSync can also provide the MDM security features mentioned
previously. Providing this support is similar to OWA. The firewall policy in the EDSZ can be set to allow
connections to ActiveSync on the CAS that may be published on an ISA server. ActiveSync is supported
by WebDAV and should be used over HTTPS (TCP port 443).
VPN Client
Enterprises that restrict employee devices to a guest or dedicated EDSZ may want to allow a subset of
these users the ability to launch the built-in VPN client to connect to the secured part of the network.
There are two methods that can be employed. First, the device may already have access to the current
Internet-facing VPN concentrator. In this case, the employee device would connect from the guest
network out through the public Internet and then back in to the Internet DMZ where the VPN
concentrator is located. If employee devices are co-mingled with actual guest traffic, then this may be
the best approach. However, if a dedicated and secured SSID is deployed behind an ASA firewall
specifically for employee personal devices, then this firewall could also provide VPN access for some
privileged users. Alternatively, a dedicated VPN concentrator could be located in the EDSZ. After the
device authenticates and joins the secured wireless domain, these users would connect to the VPN
concentrator to gain additional secured access. Only employee devices in the dedicated security zone can
reach the concentrator. The general layout of the network components are shown in Figure 18-21.
18-24

Figure 18-21
Employee Zone VPN Network Components
Outside
Cisco ISE (AAA)
DHCP
Inside
AD
Internal
DS Server DNS
Internet
Internal
Wireless
Controller
AD
Campus Network
VPN NAT Client Traffic
ASA Firewall
ASA VPN
WPA/WPA2 Protected
Non-VPN Client Traffic
IPSec/ESP
VPN Interface
Radius
Employee
Device
DMZ
VPN AD
Authorized
NOT VPN
Authorized
Wireless
Controller
Management
Interface
Web
Mirror
DMZ #2
EDSZ
294075
Chapter 18
Apple iOS devices include a built-in Cisco IPSec client allowing ESP tunnel mode and XAUTH. Both
Apple and Android devices offer L2TP with IPsec and pre-shared key (PSK). The ASA can be setup to
accept both types of VPN clients. For this discussion, the focus is the Cisco VPN client found on Apple
iOS devices.
The employee needs to know the name of the VPN concentrator, group, and group secret to configure
the VPN client. Future version of this document will illustrate how the VPN configuration can be pushed
to the employee device without user intervention. Certificates can also be pushed to the employee device
to further secure access to the VPN concentrator. The use of certificates negates the need for a group and
group secret.
18-25
Chapter 18
Figure 18-22
iOS VPN Client Configuration
When the user connects to the VPN concentrator, they are asked for their Microsoft AD credentials. This
information is passed by the Cisco ASA to the Cisco ISE server, where a policy decision can be made.
This decision can include attributes from Microsoft Active Directory or any of the other parameters
Cisco ISE can use to determine policy. If the user is authenticated and authorized by Cisco ISE, the ASA
completes the VPN connection. Once connected, the ASA can apply additional security and access
restrictions to the tunnel, further controlling what resources the employee device can reach. The ASA
can also be used to monitor who is using the VPN portal, as shown in Figure 18-23.
Figure 18-23
ASA Management for VPN Connections
ASA provides additional information for managing VPN connections.
Virtual Desktop Client

Another available deployment model is to allow a virtual desktop to run on the employee device. The
actual applications and associated data remain on the secured hosting server. Once the device
disconnects from the network, the data is typically no longer available to the user. The enterprise can
control which users are able to launch a virtual desktop and what applications are available on that
desktop. The firewall between the EDSZ and the hosting server can be configured to allow specific
connections.
18-26
Chapter 18

Summary
There are a wide range of possibilities. In its simplest from, the employee could use VNC to connect
back to their desktop or a dedicated server. A VNC client is available for both iOS and Android devices.
This may be adequate for some small environments where availability and manageability are not a top
priority. By default, the connection is not encrypted, which is a concern. Administrators may not have
the necessary control over which applications are available on the hosting server. Employees may be
tempted to attach to their desktop and send sensitive data to an external account via email or cloud file
sharing services such as Dropbox and Google Drive. This temptation only arises as a means to bypass
IT policy and should be considered before allowing remote desktops to attach to employee deployed
VNC servers. The use case for employee devices with virtual VNC desktops needs careful review. The
employee is likely sitting in front of the actual desktop, with a full keyboard and mouse and likely does
not need a remote desktop. The best approach may be to block TCP port 5900 from traversing the firewall
to unknown destinations.
Cisco also partners closely with Citrix in support of both the XenApp and XenDesktop products for
deployment of a Virtual Desktop Infrastructure. Access to VDI for employee devices are best suited in
environments where a centralized UCS server is securing and managing sessions. With VDI in place for
corporate devices, extending access to employee devices may allow productivity gains. This can be done
by opening the firewall to allow a connection to specific and well known servers. Beyond BYOD, virtual
desktops are compelling because of the reduction in IT costs. Adding tablet support maximizes the
benefit because the requirement for employee laptops is reduced. A small and lightweight VDI hardware
appliance replaces the traditional desktop, and mobile device support un-tethers the employee from the
cube. Tablets with virtual desktops can offer much of the same functionality as employee laptops, but at
a reduced cost and with stronger tools to address lost and stolen devices plus centralized data security
inherent in VDI.
Finally AnyConnect provides a centralized virtual desktop that integrates with the ASA firewall. This is
a good approach because security is the foundation of the system. AnyConnect desktops attach to the
ASA firewall via SSL. Virtual desktops are evolving in capabilities and will be covered in more detail
the next release of this document.
Summary
These types of alternate solutions offer a wide range of options to provide employees compute resources
without compromising corporate data. Leveraging the guest environment can serve as part of a migration
path to a fully certificate-based BYOD solution. Guest type deployments can be set up fairly quickly
without the need to touch a large number of third-party devices and yet still meet the basic requirement
of allowing employees to use their personal devices to increase the organizations productivity.
18-27
Chapter 18
Summary
18-28
CH AP TE R
19
User ExperienceHow To On-board a BYOD

Device
Revised: September 27, 2013
The Cisco ISE allows employees to be in charge of on-boarding their own devices through a
self-registration workflow and simplifies the automatic provisioning of supplicants as well as certificate
enrollment for the most common BYOD devices. The workflow supports iOS, Android, Windows, and
Mac OS devices and assists in transitioning these devices from an open environment to a secure network
with the proper access based on device and user credentials.
The simple workflow provides a positive experience to employees provisioning their own device and
allows IT to enforce the appropriate access policies.
Apple iOS Devices

The employee connects to the provisioning SSID and is redirected to the Guest Registration portal for
registration after opening a browser. The employee logs in using their Active Directory credentials.
If the device is not yet registered, the session is redirected to the self-registration portal, where the user
is asked to enter a description for the new device. The employee is not allowed to change the Device ID
(MAC address), which is automatically discovered by ISE.
Note
19-1
Chapter 19
Apple iOS Devices
Figure 19-1
Guest Portal and Self-Registration Portal
The supplicant profile is downloaded and installed on the endpoint.
Keys are generated and the certificate is enrolled.
The Wi-Fi profile required to connect to the BYOD_Employee is installed.
19-2
Chapter 19

Apple iOS Devices
Figure 19-2
Enrollment and Profile Installation
The employee is notified that registration is complete and is reminded to manually connect to the
BYOD_Employee SSID.
19-3
Chapter 19
Apple iOS Devices
Figure 19-3
Note
Device Registration Complete
For iOS devices, the employee is required to connect manually to the BYOD_Employee SSID.
The certificates and profile can be viewed by clicking Settings > General > Profiles and selecting
Mobile Profile. Figure 19-4 highlights the Wi-Fi profile to connect to the BYOD_Employee SSID.
19-4
Chapter 19

Apple iOS Devices
Figure 19-4
Mobile Profile Details
As shown in Figure 19-5, the ISE maintains a detailed log of the authentications as they take place:
The first log shows how the first time the device connects, the MAC address is used for
authentication, and the Wireless CWA profile is used for authorization, enabling the redirection to
the Guest Registration portal.
Once the enrollment and provisioning take place, the user connects to the secure BYOD_Employee
SSID. ISE grants Partial Access to the device.
Figure 19-5
ISE Authentications Log
Figure 19-6 shows in more detail the steps that took place and how the rule was evaluated to grant Partial
Access.
Authentication is dot1x and EAP-TLS.
Username is user2. The Active Directory (AD1) identity store was used.
19-5
Chapter 19
Android Devices
MAC Address is discovered.
The Wireless_Dot1X_AuthC authentication rule was used.
The Campus WiFi Partial Access authorization rule matched. This rule enforces the access list
ACL_Partial_Access in the Wireless LAN Controller.
Figure 19-6
ISE Authentication Details
Android Devices
The user experience is very similar when provisioning Android devices. The employee is redirected to
the Guest Registration portal and is allowed to enter a description for the new device.
19-6
Chapter 19

Android Devices
Figure 19-7
Guest Portal and Self-Registration Portal
The employee is then redirected to Google Play where the Cisco SPW for Android may be downloaded.
19-7
Chapter 19
Android Devices
Figure 19-8
Supplicant Provisioning Wizard from Google Play
The SPW is launched and the provisioning process begins. The SPW discovers the ISE and begins
downloading the profile and installing the certificates.
19-8
Chapter 19

Android Devices
Figure 19-9
Provisioning Process
The employee is allowed to name the certificate and provides a password for the certificate storage for
their device. The Wi-Fi profile to connect to BYOD_Employee is applied.
19-9
Chapter 19
Android Devices
Figure 19-10
Certificate and Profile
Without employee intervention, the provisioning process automatically connects the Android device to
the BYOD_Employee SSID, as shown in Figure 19-11.
19-10
Chapter 19

Windows Devices
Figure 19-11
Automatic Connection to BYOD_Employee
Figure 19-12 shows how the device is automatically connected to the secure BYOD_Employee SSID.
Figure 19-12
BYOD_Employee Secure SSID
Windows Devices
The user experience while provisioning a Windows device is very similar, redirecting the session to the
Guest Registration portal and asking the employee for authentication.
Some Windows devices have multiple network adapters, for example, a laptop with both wired and
wireless adapter. The network security policy checks that the device mac-address (sent using
calling-station-id attribute) matches the SAN field of the device digital certificate before allowing
access. This is done to prevent spoofing. Since each adapter has a unique mac-address, the anti-spoofing
policy check can cause difficulties for devices with multiple adapters. If a device registers with a wired
adapter, it will obtain a digital certificate with the mac-address of the wired adapter. If the same device
attempts to later authenticate to the secure wireless network, most operating systems will attempt to the
19-11
Chapter 19
use the wired adapter certificate for authentication and will fail because the mac-address of the wireless
adapter will not match the SAN field of the digital certificate. To avoid this problem, a device with
multiple adapters must register both the wired and wireless adapter.
There are two methods for provisioning wireless devices:
Dual SSID model, which supports MAB on the provisioning SSID and dot1X on the employee
SSID.
Single SSID model, which supports only the dot1X protocol.
For the Dual SSID method, the wired and wireless adapters may be provisioned in any order. For
example, if the device associates with the provisioning SSID (which supports MAB) and is successfully
provisioned, then subsequently connects with the wired adapter, 802.1X will fail because of the
anti-spoofing check in the policy and the user will be re-directed to complete the provisioning process.
Thereafter, the device can access the network with either adapter.
For the Single SSID method, the order in which the wired and wireless adapters are provisioned matters.
For example, if the device connects using the wired adapter first and is successfully provisioned, then
subsequently connects using the wireless adapter, some operating systems attempt to establish a
EAP-TLS connection using the wired digital certificate instead of undergoing the provisioning process.
This connection attempt will fail because of the anti-spoofing check in the policy. To prevent this from
happening, the user must provision the wireless adapter before connecting with the wired adapter for the
single SSID method.

After authenticating at the portal and entering a description for the new Windows device, the SPW is
downloaded.
19-12
Chapter 19

Figure 19-13
Guest Registration Portal
The SPW is launched to install the profile, the keys are generated, and the certificate enrollment takes
place.
The SPW installs the BYOD_Employee configuration to connect to the secure SSID. The connection is
switched automatically to the BYOD_Employee SSID.
19-13
Chapter 19
Figure 19-14
SPW and Connection to Secure SSID

The user experience is very similar, but instead of configuring access to a secure SSID, the SPW
configures the devices to connect via a wired connection.
19-14
Chapter 19

Figure 19-15
Guest Registration Portal
The SPW is downloaded and the proper configurations are applied to the device.
19-15
Chapter 19
Mac OS/X Devices
Figure 19-16
SPW and Secure Access
Mac OS/X Devices

The user experience while provisioning a Mac OS X wired device is also very similar, redirecting the
session to the Guest Registration portal and asking the employee for authentication.
19-16
Chapter 19

Mac OS/X Devices
Figure 19-17
Guest Registration and Self-Registration Portals
The SPW is downloaded and installed.

Figure 19-18
SPW and Secure Access
The Network Setup Assistant configures the EAP-TLS_MAC profile for secure access.
19-17
Chapter 19
Mac OS/X Devices
Figure 19-19
Network Setup Assistant
The network settings in Figure 19-20 show the new EAP_TLS_MAC configuration.
19-18
Chapter 19

Mac OS/X Devices
Figure 19-20
Network Settings
19-19
Chapter 19
Mac OS/X Devices
19-20
PART
CH AP TE R
20

This part of the CVD describes four services in addition to the use cases described in the earlier parts of
this CVD. This part highlights how to extend access to guest and remote users and how to manage the
BYOD environment and lost or stolen devices.
The following components and configuration steps are discussed to support different BYOD use cases:
Digital Certificates
Microsoft Active Director authentication
API Integration with Mobile Device Managers
BYOD Guest Wireless AccessThis chapter describes a traditional wireless guest access solution
where users do not have to on-board or register their device with ISE. Internet-only access is granted
to guest devices.
Managing a Lost or Stolen DeviceThis chapter describes how to deny access to a device that is
reported lost or stolen to prevent unauthorized access to the network. By connecting to the My
Devices Portal in ISE, users are allowed to manage their devices to prevent unauthorized access or
initiate device wipes through the MDM API integration.
BYOD Policy Enforcement Using Security Group AccessThis chapter highlights Security Group
Tags as an alternative approach to enforcing policy and traffic restrictions addressing the same use
cases addressed in the CVD.
Mobile Traffic Engineering with Application Visibility and Control (AVC)This chapter describes
different designs that benefit from features such as Quality of Service and the Application Visibility
and Control (AVC) on the Cisco WLC. The configuration for different policies is also discussed in
detail.
20-1
Chapter 20
Managing Bonjour Services for BYODThis chapter shows how to use the Bonjour Gateway
feature of the Cisco WLC to manage Apples Bonjour protocol in a BYOD enterprise context.
Mobile and Remote Access Collaboration with Cisco Expressway SeriesThis chapter describes a
new way for mobile devices to connect from any location without the need for a separate VPN client.
This simplifies the BYOD user experience and complements security policies.
BYOD Remote Device AccessThis chapter describes how to accommodate devices that attempt
to connect remotely to access internal resources.
BYOD Network Management and Mobility ServicesThis chapter describes how to configure and
deploy Cisco Prime Infrastructure management suite to manage the BYOD solution.
20-2
CH AP TE R
21

Whats New: Added note about implementing Centralized Web Authentication (CWA) on CUWN
wireless controller platforms.
This chapter discusses traditional network access for wireless guest devices and presents various ways
to accommodate guest wireless devices within a BYOD implementation. It also provides background
information for Chapter 18, BYOD Basic Access Use Case, which discusses how guest wireless access
can be extended to support wireless employee personal devices. Note that within this design guide, guest
access refers to temporary Internet access provided for visitors who are sponsored by a representative of
the organization being visited.
Overview
For guest wireless access, a Cisco recommendation has been to deploy a separate, dedicated wireless
controller off of a DMZ segment of a Cisco ASA firewall located within the Internet edge module. An
example of this design using Cisco Unified Wireless Networking (CUWN) infrastructure is shown in
Figure 21-1.
21-1
Chapter 21
Overview
Figure 21-1
Typical Enterprise Guest Wireless Deployment Using CUWN Infrastructure
Branch
Internet Edge
CAPWAP
CAPWAP
Guest
VLAN
WAN
CT5508
Guest WLC
Guest SSID
CAPWAP
Tunnels
Campus
Building
Internet
ASA
Firewall
Flex 7500
WLC
ISE
CAPWAP
CAPWAP
Guest SSID
293840
AD
CT5508 or
CT5760 WLC
Ethernet-over-IP
Mobility Anchor
Tunnels
Data Center and
Service Module
A similar example of this design using a converged access infrastructure is shown in Figure 21-2.
Figure 21-2
Typical Enterprise Guest Wireless Deployment Using Converged Access Infrastructure
Branch
Internet Edge
Catalyst 3850
Series Switch
CAPWAP
CAPWAP
Guest
VLAN
WAN
CT5508
Guest WLC
Guest SSID
CAPWAP
Tunnels
ASA
Firewall
ISE
CAPWAP
CAPWAP
Guest SSID
Catalyst 3850
Series Switch
CAPWAP Mobility
Anchor Tunnels
CT5508 or
55760 WLC
Data Center and

Service Module
AD
293841
Campus
Building
Internet
Multiple alternatives for deploying guest access may be deployed. However, this design guide discusses
only guest wireless designs based around a dedicated guest SSID configured for open access with no
encryption. This is often done because the organization's IT department usually has no knowledge of, or
control over, the hardware or software capabilities of the guest wireless device. Hence, open access is
the least common denominator applicable to all wireless devices.
21-2
Chapter 21

Overview
Guest wireless traffic from the campus or a branch location is configured to be auto-anchored (tunneled
via Ethernet-over-IP or CAPWAP) from the internal wireless controllers to the guest wireless controller.
This may provide a somewhat higher level of security, in that guest wireless devices are not terminated
on the inside of the corporate network. This is often desirable from a customer perspective because
the security posture of guest devices cannot be determined.
Note
Cisco wireless controllers currently support two different mobility architectures. The old mobility
architecture relies on Ethernet-over-IP tunnels between wireless controllers. The new mobility
architecture, also called the hierarchical mobility architecture, relies on CAPWAP tunnels between
wireless controllers. The two mobility architectures are not compatible with each other. If mobility
(including the auto-anchoring function) is required between wireless controllers, all wireless controllers
must be running either the new mobility or the old mobility architecture. The new mobility architecture
is supported on Cisco 5508 and WiSM2 wireless controllers with software release 7.3.112 and on the
Cisco 5508, WiSM2, and 2504 wireless controllers with software release 7.5. The new mobility
architecture is supported on the Cisco 5760 wireless controller and the Catalyst 3850 Series switch with
IOS XE software releases 3.2.0SE and 3.2.2SE. CUWN wireless controller release 7.4 and releases
below 7.3.112 support only the old mobility architecture. The Cisco Flex 7500, 8500, and vWLC do not
support the new mobility architecture. IOS XE based wireless controllers do not support the old mobility
architecture. Hence if a network contains both Flex 7500 wireless controllers and Converged Access
controllers, then separate sets of guest wireless controllers must be deployed with the DMZ to support
both mobility architectures with the guest wireless design discussed in this design guide.
There are two distinct sets of terminologies used in this chapter. The first pair of terminologies is guest
controller and campus controller. The guest controller is a dedicated controller that is mainly used for
dealing with guest wireless traffic and the campus controller is dedicated for handling internal traffic.
Note that the term campus controller is used somewhat generically here. The campus controller
discussed within this chapter may refer to one or more standalone wireless controller platforms deployed
within a campus location or to wireless controller functionality integrated within one or more Catalyst
3850 Series switches deployed within branch locations.
The second set of terminologies is foreign controller and anchor controller. These terminologies are used
when a user roams from one controller to another controller. The new controller to which the user
associates is the foreign controller and this controller anchors all the traffic to the old controller which
becomes the anchor controller.
This design guide chapter discusses wireless guest access primarily from the perspective of how it
integrates with the network infrastructure and with the Cisco ISE server for AAA services within an
overall BYOD deployment. For details regarding the configuration of wireless controllers for supporting
guest access, see the Cisco Unified Wireless Guest Access Services chapter of the Cisco Enterprise
Mobility 4.1 Design Guide at:
http://www.cisco.com/en/US/docs/solutions/Enterprise/Mobility/emob41dg/emob41dg-wrapper.html.
Note
The method of Web Authentication presented in this design guide is known as Local Web Authentication
(LWA). As mentioned previously, other methods of providing Web Authentication can be configured.
Refer to the following document which discusses how to implement Centralized Web Authentication
(CWA) on CUWN wireless controller platforms:
http://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/115732-central-web-auth
-00.html
21-3
Chapter 21

As with other devices, guest wireless devices require IP addresses and name resolution (DNS) services.
A local DHCP server can be deployed on the subnet which supports guest wireless access. This option
works well if the ASA firewall performs NAT between the inside and guest wireless DMZ interfaces.
Although this may be the most secure option in terms of isolating guest IP addressing from the rest of
the corporate network, it is also somewhat cost prohibitive and more difficult to administratively
maintain. This cost can be offset by implementing an ASA firewall configured with a DHCP pool to hand
back IP addresses directly to wireless clients. The advantage of this option is again the isolation of guest
IP addressing from the rest of the corporate network and the fact that DHCP from guest devices do not
have to be allowed through the ASA firewall. The downside is the management of a separate IP
addressing pool for guest wireless devices within the ASA firewall.
IP addressing for guest wireless devices can also be provided through a DHCP server on the inside of
the corporate network. This option works well if NAT is not implemented between the inside and the
guest wireless DMZ interfaces. The remainder of this chapter assumes no NAT functionality for the guest
wireless DMZ interface. The advantage of implementing a centralized DHCP server is the centralized
control of IP addressing for guest devices. The downside is that DHCP has to be allowed through the
ASA firewall to the internal DHCP server.
Cisco wireless controllers can be configured to proxy for wireless clients to an internal DHCP server.
This is a common deployment model for wireless controllers. With this configuration the DMZ interface
of the ASA firewall needs to allow inbound DHCP packets from the IP address of the wireless controller
associated with the guest WLAN interface through the ASA firewall. Alternatively, instead of the guest
wireless controller acting as a proxy for wireless devices, the ASA firewall can be configured to relay
DHCP to an internal DHCP server. With this configuration, guest wireless clients directly send DHCP
through the wireless controller, which are then relayed to an internal DHCP server by the DMZ interface
of the ASA firewall. Note that DHCP profiling of end devices via a Cisco ISE server can be
accomplished by relaying the DHCP discover to both the internal DHCP server as well as the ISE
profiling server. However, there may be no need or desire to profile guest devices, since they require only
temporary access.
Note
The network administrator should always weigh the benefits achieved from enabling DHCP server or
DHCP relay functionality against the incremental risks of enabling such additional features on the ASA
firewall to determine the appropriate security policy for the organization.
An increasing issue with guest wireless networks is IP address depletion. This may be the result of
opening up the traditional guest network to employee personal devices. It may also be the unintentional
result of having an office in a densely populated area where the general public is connecting to the open
SSID corresponding to the organization's guest WLAN, thinking that it provides hot spot wireless
services. As the proliferation of consumer wireless devices continues and as organizations continue to
adopt BYOD strategies, this problem may become more widespread. If branch locations are offering
guest services, the required address pool can become quite large.
There are a number of methods which can be implemented to help alleviate the issue of IP address
depletion. From a security perspective, the optimal solution is to try to tune the Access Point (AP) radios
such that the SSID corresponding to the guest WLAN-along any of the organizations other wireless
SSIDs for that matter-are not visible outside the physical boundaries of the organization. However, this
is not always possible while still maintaining adequate wireless coverage across the entire floor space.
A second method is to decrease the lease time on the DHCP server for the IP subnet corresponding to
the guest WLAN. This does not prevent the general public from connecting to the open SSID
corresponding to the organizations guest WLAN. However, when end users realize they do not have the
web authentication (Web Auth) credentials needed to access anything, they may reconnect to another
21-4
Chapter 21

SSID. The IP addresses handed-out to these devices are made available to hand-out again more quickly
if the DHCP lease time is decreased. The downside is the additional overhead on the DHCP server and
slightly additional overhead on the wireless device itself from having to renew leases faster.
A third method is to hide the SSID corresponding to the guest WLAN by not broadcasting it in AP
beacons. Cisco Unified Wireless Network (CUWN) controllers provide an easy means of achieving this
by simply un-checking the Broadcast SSID checkbox for the WLAN corresponding to the guest SSID,
Figure 21-3
Disabling the Broadcast of the SSID Corresponding to the Guest WLAN in AP Beacons
Similarly, the following configuration example shows only the part of the configuration of the guest
SSID on a Converged Access (IOS XE based) wireless controller in which broadcasting of the SSID has
been disabled.
!
wlan BYOD_Guest 2 BYOD_Guest/Configuration for the guest SSID
no broadcast-ssid/Disables broadcasting the SSID in AP beacons
!
This is by no means a foolproof method of keeping unwanted devices from connecting to the open SSID
corresponding to the guest WLAN, since it can still be discovered by other means. However, it does make
it harder to find and connect to it, potentially reducing the number of unwanted devices and therefore
the number of IP addresses being issued by the DHCP server. The downside is that guests have to
manually type in the name of the SSID when trying to connect to the organizations guest wireless
network. However, the name of the SSID can also be included with the credentials provided to the guest
either prior to or at the time of arrival to organizations site.
Another option is to provision a larger contiguous IP subnet address space for the guest wireless
network, simply by changing the IP subnet mask of the existing guest IP address space. This works well
if the adjacent IP address space is available and unused. If this cannot be done, a second guest DMZ
interface can be provisioned on the wireless controller to increase the IP address space available to hand
out to devices on the guest WLAN.
Increasing the pool of available IP addresses is the most direct method to ensure guests are not prevented
access due to address depletion. It is worth noting that this approach does not discourage adjacent
wireless clients from associating to the wrong network. Web Auth or some other method is needed to
control access to guest resources. It is also considered good practice to audit the actual number of guest
21-5
Chapter 21
users with the anticipated number. Comparing the number of guest that have passed through the guest
portal with the number of addresses that are leased out from the DHCP server is a good means to
determine how many unintentional wireless clients are associating with the network. The lease time can
be adjusted down if the number of leased addresses far exceeds the anticipated number of guests.
Wireless guest devices also need name translation services (DNS) to reach locations on the Internet.
Also, when Web Auth is implemented, the URL within the guests web browser must resolve to an IP
address. This is necessary for Web Auth to redirect the session to the guest portal to request guest
credentials. Name translation services can be provided by allowing guest devices to reach either an
external DNS server deployed on another DMZ segment off the ASA firewall or an internal DNS server
deployed on the inside of the corporate network. Allowing guest devices access to an external DNS
server provides the advantage that internal sites and services can be hidden from the guest devices.
However, if the wireless guest network is extended to include employee personal devices, as discussed
in Chapter 18, BYOD Basic Access Use Case, the network administrator needs to determine if an
external DNS server can still provide the necessary name translation services.
Note
DHCP packets from client to server utilize UDP source port 68 and destination port 67. DHCP packets
from the server to the client utilize UDP source port 67 and destination port 68. DNS uses UDP port 53.
These ports must be allowed through the firewall when internal DNS and DHCP servers are
implemented.

Most organizations IT departments choose to have guest wireless users authenticate first, before
allowing access to the Internet. This step is sometimes accompanied with the guest user reading and
agreeing to an Acceptable Use Policy (AUP) or End User Agreement (EUA) before accessing the
Internet. Since the organizations IT department typically has no control over the hardware or software
capabilities of guest wireless devices, the authentication and authorization decision is often based on a
guest userid and password only. In other words, from a BYOD perspective, the device with which the
guest is accessing the network may not be considered for the policy decision. A typical way of
implementing guest user authentication, which is shown in Figure 21-4, is through the guest users web
browser, known as web authentication or Web Auth. With this method of authentication, the wireless
guest must first open their web browser to a URL located somewhere within the Internet. The browser
session is re-directed to a web portal which contains a login page which requests login credentials. Upon
successful authentication, the guest user is either allowed access to the Internet or redirected to another
website.
A major requirement of guest access is the ability of a sponsor, such as a lobby administrator, to access
a portal to create temporary guest credentials which are valid for a limited time. Hence, this functionality
is also included within the discussion below.
21-6
Chapter 21

Figure 21-4
Guest Wireless Access with Web Authentication
Interner Edge
ASA
Firewall
Guest (Anchor)
Wireless Controller
4. Guest Allowed
Internet Access
Internet
2. Web Session Redirected at

the Guest Wireless Controller to
a Portal within Cisco ISE Server
Data Center and/or

Service Module
3. RADIUS Authentication
via the Cisco ISE
Guest Database
Cisco ISE
Anchor Mobility Tunnel

Campus (Foreign)
Wireless Controller
CAPWAP Tunnel
Access Point
Guest Device
CAPWAP
1. Sponsor Creates
Guest Credentials
within the Cisco ISE
Sponsor Portal
293843
Campus and/or
Branch Network

Implementing the guest access design discussed within this document is very similar for campus and
branch networks. Typically the same configuration steps can be used for both. Deploying the guest
access solution involves configuring several components such as the wireless controller (WLC), ASA
firewall, and Cisco ISE.
WLC Configuration
For the design shown in this document, redirection of the guest web session and the point of
authentication from the wireless controller is directed to the Cisco ISE server. Other methods of
performing the web authentication are available, but are not discussed in this guide. The guest clients
web session is redirected by the guest wireless controller to a portal containing the login screen located
within the Cisco ISE server.
By positioning the Web Auth login page (and optionally the AUP or EUA) in a central location, the
network administrator can provide one unified login page for all wireless guest access without having to
download the login page to each guest wireless controller.
As discussed in the initial overview, the recommendation from this design is to deploy two different
controllers:
21-7
Chapter 21
A campus controller which handles all internal wireless traffic.
A dedicated guest controller that only handles the guest traffic.
These two controllers have a mobility anchor tunnel established between them. This section discusses
the configuration details for both of the controllers.
Campus Controller
This section discusses the campus controller configuration when using either CUWN wireless
controllers or Converged Access (IOS XE based) wireless controllers.
CUWN Wireless Controllers

The first step is to configure a guest SSID. Figure 21-5 shows the configuration for the BYOD_Guest
SSID. Note that the authentication must be configured for Web Auth.
Figure 21-5
BYOD_Guest SSID Details on the Campus Controller
The next step is to configure the Layer 2 and Layer 3 security parameters for this SSID. Figure 21-6
shows the Layer 2 security parameters.
21-8
Chapter 21

Figure 21-6
Layer 2 Security Details of BYOD_Guest
As mentioned before, the Layer 2 security parameters are set for None, indicating an open SSID. The
Layer 3 security parameters are shown in Figure 21-7.
Figure 21-7
Layer 3 Security Details of the BYOD_Guest WLAN on the Campus Controller
The Layer 3 security parameters enable web authentication (Web Auth). The next step is to configure
the AAA server parameters, which are shown in Figure 21-8.
21-9
Chapter 21
Figure 21-8
AAA Server Configuration for the BYOD_Guest WLAN on the Campus Controller
The AAA server parameters are configured such that Web Auth utilizes the Cisco ISE server for
authenticating guests using RADIUS.
The next step is to configure the mobility tunnel between the campus and the guest controller. The guest
controller must first be added to the campus controller as a mobility group member. Figure 21-9 shows
an example of this.
Figure 21-9
Adding the Guest Controller to the Mobility Group
21-10
Chapter 21

Note
Both the MAC address and the IP address of the management interface of the guest controller are needed
in order to add it as a mobility group member.
Finally, a mobility anchor is created on the BYOD_Guest SSID which points to the IP address of the
management interface of the guest controller. An example is shown in Figure 21-10.
Figure 21-10
Configuring the Mobility Anchor on the Campus Controller
In order to support the new mobility architecture (also referred to as the Hierarchical mobility
architecture) the network administrator must check the Enable Hierarchical Architecture option
within the global mobility configuration of the campus wireless controller. This is shown in
Figure 21-11.
Figure 21-11
Note
Enabling the Hierarchical Mobility Architecture in the Campus Controller
skipped when implementing a Flex 7500 as the branch wireless controller.
21-11
Chapter 21
Converged Access (IOS XE Based) Wireless Controllers

The following partial configuration example shows the configuration of the guest WLAN on a
Converged Access (IOS XE based) wireless controller.
!
vlan 777
/Isolated VLAN for guest devices if anchor tunnel is down
name Guest
!
~
!
wlan BYOD_Guest 2 BYOD_Guest/Guest WLAN, WLAN ID, and SSID on the campus controller
aaa-override
client vlan Guest/Static assignment to non-routed (isolated) VLAN
mobility anchor 10.225.50.35/Creates CAPWAP anchor tunnel to guest wireless controller
no security wpa/Layer 2 security set to none (Open SSID)
security web-auth/Layer 3 security set for web authentication
no shutdown
/Enables the Guest WLAN
!
Note that the Guest client VLAN in the configuration above is a VLAN which is isolated on the CT5760
wireless controller or Catalyst 3850 Series switch. It is not trunked to the adjacent Layer 3 device. This
isolates any guest devices should the CAPWAP tunnel between the foreign and anchor controllers go
down.
The guest WLAN must be configured on the device which functions as the Mobility Agent (MA) and on
the device which functions as the Mobility Controller (MC). For more information regarding the MA
and MC functions, see Chapter 9, BYOD Wireless Infrastructure Design. Therefore, when the
converged access infrastructure consists of a Catalyst 3850 switch configured as the MA with a CT5760
wireless controller configured as the MC within a large campus, the guest WLAN must be configured
on both devices. When the converged access infrastructure consists of just a Catalyst 3850 switch
configured as both the MA and MC within a branch, the guest WLAN is also configured as shown above.
Note that the wireless mobility configuration will differ, depending upon whether a Catalyst 3850 switch
is configured as a MA within a large campus or as both a MA and MC within a branch. This is discussed
in Chapter 9, BYOD Wireless Infrastructure Design.
In order to support guest access, the guest wireless controller must be added as a member of the mobility
group within the MC. The following partial configuration shows an example of the configuration of a
mobility group and a mobility group member which points to a guest wireless controller.
!
Wireless mobility controller/Enables the MC function
wireless mobility group member ip 10.225.50.35 public-ip 10.225.50.35/Guest Controller
wireless mobility group name byod/Mobility group name
!
The mobility group name and mobility group peer configuration must appear on the device which
functions as the Mobility Agent (MA). Therefore, when a Catalyst 3850 Series switch is deployed as
both the MA and MC within a branch deployment, the configuration must include similar lines. A
Catalyst 3850 Series switch deployed as only an MA within a campus deployment would not include the
mobility group configuration. Instead the CT5760 wireless controller deployed as an MA and MC within
a campus would contain the mobility group configuration. Note that since IOS XE based wireless
controllers only support the new hierarchical mobility architecture, no configuration is required to
enable it.
21-12
Chapter 21

Guest Controller
The guest controller is the point where all the guest wireless traffic is terminated. For this version of the
design guide, the discussion only includes a CT5508 CUWN wireless controller as the guest controller.
As explained in Overview, a mobility anchor tunnel is established between the guest controller and the
campus controller. The guest controller authenticates against ISE all guest traffic which is originated
from campus or branch controllers. The first step is to define the guest SSID, named BYOD_Guest. The
name of this SSID must be identical to the BYOD_Guest defined in the campus controller. Figure 21-12
depicts the details.
Figure 21-12
BYOD_Guest Details on the Guest Controller
The next important tab is the Layer 2 Security details of the BYOD_Guest WLAN, which is shown in
Figure 21-13.
Figure 21-13
Layer 2 Security Details of the BYOD-Guest WLAN on the Guest Controller
Layer 2 security is set for None, indicating an open SSID. The authentication must be configured for
Web Auth. Both of these match the configuration of the campus controller.
21-13
Chapter 21
A Web Auth pre-authentication ACL is necessary when utilizing a remote Cisco ISE guest portal for
login and optionally the AUP or EUA. The Web Auth pre-authentication ACL must be configured to
allow all possible IP addresses associated with the guest wireless subnet (which can be handed out to
guest wireless devices) to be redirected to TCP port 8443 of the Cisco ISE guest portal. An example of
a Web Auth pre-authentication ACL is shown in Figure 21-14.
Figure 21-14
Example of a Pre-Authentication ACL for Guest Wireless Access via Web Auth
Allow (do not redirect) traffic from devices on the 10.234.0.0 / 16 network address space to TCP
port 8443 of the ISE server (10.225.49.15).
The ACL implicitly denies (redirects) all other traffic to the ISE guest portal. When specifying an ACL
down to the port level within the guest wireless controller, both inbound (from the wireless guest devices
to the Cisco ISE server) and outbound (from the Cisco ISE server to the wireless guest devices) rules
must be configured. Specifying an inbound rule only does not automatically allow return traffic through
the wireless controller, as is done with a stateful firewall. Also, specifying a single rule of the form above
with a direction of Any does not work. The wireless controller does not reverse the source and
destination IP addresses for the return traffic.
Once the ACL is configured, it must be applied as a Web Auth pre-authentication ACL. This is done in
the Guest WLAN Layer 3 Security policy, as shown in Figure 21-15.
21-14
Chapter 21

Figure 21-15
Applying an ACL as a Web Auth Pre-Authentication ACL
The AAA server configuration details are shown in Figure 21-16.
21-15
Chapter 21
Figure 21-16
AAA Server Configuration for the BYOD-Guest WLAN on the Guest Controller
The AAA server parameters are configured such that Web Auth utilizes the Cisco ISE server for
authenticating guests using RADIUS.
The next step is to configure the anchor mobility tunnel between the guest and the campus controller.
The campus controller must first be added to the guest controller as a mobility group member. An
example is shown in Figure 21-17.
21-16
Chapter 21

Figure 21-17
Adding the Campus Controller to the Mobility Group
Finally, a mobility anchor is created on the BYOD_Guest SSID. For the guest controller, the mobility
anchor points to the local IP address of the management interface of itself. This is different from the
campus controller configuration which points to the guest controller. An example is shown in
Figure 21-18.
Figure 21-18
Configuring the Mobility Anchor on the Guest Controller
In order to support the new mobility architecture (also referred to as the hierarchical mobility
architecture) the network administrator must check the Enable Hierarchical Architecture option
within the global mobility configuration of the wireless controller. This is shown in Figure 21-19.
21-17
Chapter 21
Figure 21-19
Note
Enabling the Hierarchical Mobility Architecture in the Guest Controller
skipped when implementing a guest controller which is auto-anchoring wireless devices from a Flex
7500 foreign controller.
The guest controller authenticates the users against an external server, which is ISE in this design.
Hence, the guest controller must be configured to redirect the guest users to the ISE, which is shown in
Figure 21-20.
Figure 21-20
Configuration for Redirection to an External Server
In Figure 21-20, the External Webauth URL is set to:

https://guest.bntest.com:8443/guestportal/portals/SponsoredGuests/portal.jsp
The name of the server, which in the example above is guest.bntest.com, must resolve via DNS to the
IP address of ISE, which is 10.225.49.15 in the examples shown in this chapter.
21-18
Chapter 21

Table 21-1 shows the IP address information of the guest and the campus controllers used in the screen
captures and configuration examples shown in this section.
Table 21-1
IP Addresses of Campus (Foreign) and Guest (Anchor) Controllers
Device
Local IP
Address
Remote IP Address
Campus CUWN Controller
10.225.44.2
10.225.50.35
Campus Converged Access (IOS XE Based) Controller 10.225.47.2
10.225.50.35
Guest Controller
10.225.50.35 1.225.44.2 and 10.225.47.2
Cisco ISE Policy Configuration

From a Cisco ISE policy perspective, an additional authentication rule needs to be added for guest
authentication. This rule allows wireless controller web authentications, originated from the SSID
corresponding to the guest WLAN, to utilize a separate Cisco ISE user identity sequence for wireless
guest access. An example of such a policy rule is shown in Figure 21-21.
Figure 21-21
Example of Cisco ISE Authentication Policy Allowing Guest Wireless Access
The logical format of the example authentication policy rule is as follows:

IF (WLC_Web_Authentication)
THEN (Allow Default Network Access AND USE Guest_Portal_Sequence)
WLC_Web_Authentication is a system-generated compound condition which is used here to match

Web Auth requests from Cisco Wireless LAN Controllers. It matches the following two standard
RADIUS dictionary attribute-value (AV) pairs:
Service-Type - [6] EQUALS Login
Default Network Access is a system-generated authentication result, which allows various protocols to
be used for the Web Auth. An example is shown in Figure 21-22.
21-19
Chapter 21
Figure 21-22
Example of Allowed Protocols Under Default Network Access
Guest_Portal_Sequence is a user-defined identity source sequence. An example is shown in

Figure 21-23.
21-20
Chapter 21

Figure 21-23
Example of Guest_Portal_Access Identity Source Sequence
Guest_Portal_Sequence in the example above uses the Guest Users identity source as the primary source
and uses the AD1 group as the next source. Guest Users is a system generated identity source, which is
a new feature beginning with ISE 1.2. This identity source is a place where guest credentials are held
when they are configured through the Cisco ISE sponsor portal, which is discussed later in this chapter.
Although an identity source sequence is not strictly needed when only a single identity source is
specified, configuring a sequence allows guest wireless access to be easily extended to include employee
personal devices by adding an additional identity source.
From a Cisco ISE policy perspective, an additional authorization rule also needs to be added for guest
users. This rule permits access for wireless controller web authentications originated from the SSID
corresponding to the guest WLAN. An example of the policy rule is shown in Figure 21-24.
21-21
Chapter 21
Figure 21-24
Example of Cisco ISE Authorization Policy Allowing Guest Wireless Access
The logical format of the example authorization policy rule is:

IF (WLC_Web_Authentication AND Guest_WLAN
THEN Permit Access
WLC_Web_Authentication was discussed with regard to the authentication policy above.

Guest_WLAN is a user-defined simple authorization condition for guests accessing the Internet via web
authentication through the WLAN corresponding to the open guest SSID. It matches the following
RADIUS AV pair from the Airespace dictionary:
Airespace-Wlan-Id - [1] EQUALS 2
The Airespace-Wlan-Id is the identification number (WLAN ID) of the WLAN corresponding to the
Guest SSID, as shown in Figure 21-25.
Figure 21-25
Example Guest Wireless Controller WLAN IDS
This allows the ISE authorization policy to differentiate Web Auth requests coming from the guest
WLAN and permit them.
Note
Simple Conditions such as Guest_WLAN are optionally used to give attribute and value pairs a
descriptive name. This allows the policy to be more readable and easier to support.
21-22
Chapter 21

Cisco ISE Sponsor Portal

The Cisco ISE sponsor portal can be accessed at: https://ISE_server:8443/sponsorportal/, where
ISE_server is either the IP address or the name of the Cisco ISE server. An example of the web page for
creating guest credentials within the Cisco ISE sponsor portal is shown in Figure 21-26.
Figure 21-26
Creating Guest Credentials on the Cisco ISE Sponsor Portal
Information such as guests company name, the guests email address and phone number, as well as
optional user-defined data can be included. Optional data could include the WLAN SSID the guest needs
to connect to (if the SSID is hidden), as well as the name, phone number, and department of the sponsor.
Depending upon the allowed time profiles, the credentials can be configured to become active at a future
date and time and remain active for a period of time. The Cisco ISE sponsor portal also has the capability
to deliver the guest credentials to the guest prior to arrival via email or SMS. Sending credentials via
email helps ensure the guest has provided a valid email address.
Once guest credentials are created, they can be monitored and managed by the sponsor via the Cisco ISE
sponsor portal, as shown in Figure 21-27.
21-23
Chapter 21
Figure 21-27
Monitoring Guest Credentials from the Cisco ISE Sponsor Portal
Note that in Figure 21-27 the guest username was based upon an email address versus just the first and
last name of the guest. Chapter 18, BYOD Basic Access Use Case discusses extending guest wireless
access to allow employee personal devices as well. Use of the email address within the guest username
is one possible way to differentiate between guests and employees who may have the same first and last
names.
Configuring the Cisco ISE Sponsor Portal

Configuration of the Cisco ISE sponsor portal is done through the Web Portal Management section of
the Cisco ISE server. Different levels of sponsor responsibility can be created, ranging from individual
sponsors who can only view and edit guest accounts they have created, to group sponsors who can view
and edit guest accounts for a particular group, to sponsors who can view and edit all guest accounts.
Multiple sponsor groups, each with their own members, can be created through the Sponsor Groups tab
under the Web Portal Management section of the Cisco ISE server. Figure 21-28 shows an example
where a separate group has been added for guests sponsored by the Engineering department.
21-24
Chapter 21

Figure 21-28
Example of Multiple ISE Sponsor Groups
Different authorization parameters can then be configured for each sponsor group by selecting the
particular sponsor group and selecting the Authorization Levels tab, as shown in Figure 21-29.
Figure 21-29
Example of Authorization Levels for an Individual Sponsor Group
This example shows a configuration where any member of the sponsor group is allowed to view, edit,
suspend, and reinstate a guest credential created by any other member of the sponsor group. However,
members of different sponsor groups cannot modify guest credentials created for this group.
The Guest Roles tab is used to select the user identity group (i.e., guest credential database) into which
the guest credentials created by a member of this sponsor group are placed. An example is shown in
Figure 21-30.
21-25
Chapter 21
Figure 21-30
Example of Guest Roles for an Individual Sponsor Group
The Time Profiles tab allows the network administrator to determine which time profiles (either default
or pre-configured within ISE) are applied to the particular sponsor group.
Once the sponsor groups are created, the Sponsor Group Policy tab can be used to create policies
controlling who has access to which sponsor groups. More commonly, the organization may wish to
leverage existing Microsoft Active Directory groups to differentiate among different sponsors.
Figure 21-31 shows an example of this.
Figure 21-31
Example of Microsoft AD for Sponsor Group Membership
In this example, access to the sponsor group is limited to those members of the Microsoft Active
Directory domain who are members of the group called Users/uatest.com. Note that the Microsoft
Active Directory server must be configured as an external identity source to select this option. In this
example it is known by the name AD1.
By tightly controlling members of the Microsoft AD groups which have sponsor access to ISE, the
network administrator can limit the use of the guest wireless network to its original intended
purposeguest wireless accessinstead of employee personal devices, if desired.
21-26
Chapter 21

Cisco ISE Guest Portal

As mentioned previously, Cisco ISE has the capability to support multiple guest portals. The Cisco ISE
server has a system-generated DefaultGuestPortal configuration. This allows the network administrator
to provision a guest portal in order for employees or IT staff to on-board corporate-owned or employee
personal devices, as discussed in Chapter 15, BYOD Enhanced Use CasePersonal and Corporate
Devices and Chapter 16, BYOD Limited Use CaseCorporate Devices.
Configuring the Cisco ISE Guest Portal

An additional guest portal for wireless guest access can be defined through the Guest > Multi-Portal
Configurations. An example is shown in Figure 21-32.
Figure 21-32
Example Multi-Portal BYOD Deployment
When a user-defined guest portal is implemented, the URL which needs to be configured within the guest
wireless controller Web Auth Web Login Page, as shown in Figure 21-20:
http://ISE_server:8443/guestportal/portals/name_of_user-defined_portal/portal.jsp
ISE_server is either the IP address or the name of the Cisco ISE server. Name_of_user-defined_portal is
the name of new user-defined guest portal, which is SponsoredGuests in the example above.
Once the new guest portal is defined, the Operations tab can be used to display an Acceptable Use Policy
(also known as an End User Agreement or EUA), as well as control whether the guest can or must change
the sponsor provisioned password. Note that the Operations tab can also be used to force the guest to
register their devices with the Cisco ISE server before accessing the Internet from the guest wireless
network. This design guide assumes that the guest device itself is not considered in the decision to allow
access to the guest wireless network. Hence, this use case is not discussed. Figure 21-33 shows an
example of the Operations tab.
21-27
Chapter 21
Figure 21-33
Example of Operations Tab
The Authentication tab determines which identity source sequence is used for the guest credentials. An
example is shown in Figure 21-34.
Figure 21-34
Example of Authentication Settings for a User-Defined Guest Portal
For this example the identity source sequence called Guest_Portal_Sequence is chosen. This identity
source sequence utilizes Guest Users when only wireless guest access is deployed, as shown in
Figure 21-23. This allows guests credentials to pass both the guest portal access and the ISE
authentication policy. This configuration also allows guest access to be easily extended to include
employee personal devices by simply adding Microsoft Active Directory identity store, as discussed in
Chapter 18, BYOD Basic Access Use Case.
21-28
Chapter 21

Note
Cisco ISE authentication logs may show the guest user authentication appearing twice with this
configuration, although the guest is only authenticated once via Web Auth.
The Guest Details Policy is used to configure additional global guest parameters, including mandatory
and optional parameters. An example is shown in Figure 21-35.
Figure 21-35
Example of Guest Details Policy
Additional web pages under the Guest folder control other global guest configuration parameters, such
as Username Policy and Password Policy. The Username Policy is where the guest username can be
selected to be based upon their Email address, as shown in Figure 21-36.
Figure 21-36
Example of Guest Username Policy
21-29
Chapter 21
Finally, the Time Profiles folder can be used to select one of the existing time profiles for guest user
access or to create a custom time profile. Time profiles are selected by the sponsor when configuring
guest credentials to control when the guest user has access to the network and for how long.

Figure 21-37 shows an example of the flows that need to pass through the Cisco ASA firewall to support
the design discussed in this chapter.
Figure 21-37
Example of Flows that Need to Pass Through the Cisco ASA Firewall
Cisco ISE (AAA)
DHCP
Internal DNS
Outside
Internal
Wireless
Controller
Inside
Campus Network
Internet
Sponsor PC
DHCP Flows
DNS Flows
Guest Wireless DMZ
Radius Flows
Web Authentication
(HTTP) Flows
Wireless
Controller
Management
Interface
DMZ #2
Guest Data Flows
External
DNS
Server
CAPWAP Flows
DMZ #3
Sponsor Flows for

Managing Guest
Credentials (HTTPS)
Wireless Guest Device
293879
Web Session URL Redirection

to Internal Guest Portal for
Authentication Before
Allowing Internet Access
This design requires a RADIUS session to be allowed through the ASA firewall between the guest
wireless controller and the Cisco ISE server. In addition, this design requires the guest web session to
be re-directed and allowed through the ASA firewall to the inside of the network, where the Cisco ISE
server sits. By default Cisco ISE uses TCP port 8443 for the guest portal. When using the older mobility
architecture, an Ethernet-over-IP (IP protocol 97) auto-anchor mobility tunnel, as well as the WLAN
control port (UDP port 16666) between the management interfaces of the two wireless controllers, must
still be allowed through the ASA firewall. When using the new hierarchical mobility architecture, a
CAPWAP (UDP port 5246 for control and UDP port 5247 for data) auto-anchor mobility tunnel between
the management interfaces of the two wireless controllers must be allowed through the ASA firewall.
Besides allowing DNS, DHCP (assuming the deployment of an internal DHCP server), and TCP port
8443 for the HTTPS redirection, the ASA firewall should be configured to block all other traffic
generated from guest wireless devices onto the internal network.
Table 21-2 summarizes the relevant ports that need to be allowed through the ASA firewall.
21-30
Chapter 21

Table 21-2
Ports to be Allowed through the ASA Firewall
Application
Transport
Port
WLAN Control
IP Protocol 97 UDP
16666
UDP
16666
UDP
16667
ISE Guest Portal
TCP
8443
DNS
UDP
53
BOOTPS (DHCP)
UDP
67
BOOTPC (DHCP)
UDP
68
WLAN Control
CAPWAP Control Channel (new mobility architecture) UDP
5246
CAPWAP Data Channel (new mobility architecture)
5247
UDP
When implementing guest wireless access for devices such as Apple iOS or Mac OS X Lion, the network
administrator should be aware that these devices have implemented a feature which automatically
detects the presence of a captive portal deployment. It does this by generating an HTTP request to an
Apple website and looking for a response. If a redirect is received, then a captive portal deployment is
assumed. This feature only applies to SSIDs which have open access, as is typical with most guest
wireless networks. When a captive portal deployment is detected, the iOS or Mac OS X Lion device
automatically displays a dialog window for authentication without the end user having to launch the web
browser. This feature is intended to make it easier for non-browser based applications to access the
Internet, without the end user having to launch a web browser, by performing Web Auth via the pop-up
window. Many HTML-based mobile applications do not use the browser as the user interface. This is
known as Captive Portal Network Assistance (CPNA) and is effectively a light weight HMTL-based user
interface. Unfortunately the interface is not properly interacting with the iOS profiler manager. The
symptoms are different based on the version of iOS. In iOS5, the user was not allowed to install the WiFi
profile without canceling the CPNA, forcing the device off the provisioning SSID. In iOS6, the user is
automatically brought to the profile manager, but after installing the profile, the user is not returned to
the CPNA to receive the certificate. In both cases, the CPNA is not able to successfully on-board the
device
Cisco wireless controllers have implemented a workaround that bypasses this feature, allowing Apple
iOS or Mac OS X Lion devices to operate within a captive portal deployment with HTTPS connectivity
to a guest portal with a self-signed certificate. For CUWN wireless controllers, the network
administrator needs to establish an SSH session to the guest wireless controller and issue the following
command:
configure network web-auth captive-bypass enable
Note
For IOS XE wireless controllers, the network administrator needs to add the following command to the
global configuration of the CT5760 wireless controller or Catalyst 3850 Series switch:
21-31
Chapter 21
Wireless Guest Access at the Branch
This command causes the wireless controller to answer back the HTTP request, spoofing the iOS or Mac
OS X Lion device into thinking that there is no captive portal deployment. Once the end user opens a
browser and attempts to navigate to any site, they are redirected to the portal and prompted for
credentials using the normal Web Auth process. Note that non-browser based applications are not able
to access the network until the end user opens a web browser and proceeds through the normal Web Auth
process. This includes HTML-based applications such as WebEx.

Branch networks frequently offer wireless guest services. There are two basic architectures that can be
deployed. The first is a centralized model in which all branch wireless guest traffic is tunneled via
CAPWAP to a central controller located within the campus, known as the foreign controller. Wireless
guest traffic is then further tunneled via a mobility anchor tunnel to an anchor controller located in the
DMZ. This is the method presented in this design guide.
An alternate method is to use either FlexConnect or a converged access infrastructure to locally
terminate guest traffic in a secure segment located within the branch. The advantage of the second
approach is that guest traffic does not consume expensive corporate WAN bandwidth. Instead guest
traffic is isolated within the branch and uses a local branch Internet path. Future versions of this design
guide may explore this option. In addition, there are many other possible WAN deployment models that
may be leveraged to provide guest users with access to the Internet. A collection of white papers that
explain various WAN architectures is available at:
http://www.cisco.com/en/US/netsol/ns816/networking_solutions_white_papers_list.html.
The guidance presented here follows a centralized model. For FlexConnect wireless designs, the
FlexConnect wireless controller which services branch locations and which provides on-boarding to
branch BYOD devices is also used as a foreign controller to tunnel wireless guest traffic to a guest
wireless controller within the campus Internet edge. Figure 21-38 shows the various components
required for this model.
Guest Wireless Access at the FlexConnect Branch
FlexConnect
Branch
CAPWAP
CAPWAP
Internet Edge
Guest
VLAN
WAN
CT5508
Guest WLC
Guest SSID
CAPWAP Tunnel
Internet
ASA
Firewall
Flex 7500
WLC
Ethernet-over-IP
Mobility Anchor
Tunnel
Data Center and
Service Module
21-32
ISE
AD
293880
Figure 21-38
Chapter 21

For Converged Access designs, the Catalyst 3850 Series switch which serves as the wireless controller
for the branch locations, and which provides on-boarding to branch BYOD devices, is also used as a
foreign controller to tunnel wireless guest traffic to a guest wireless controller within the campus Internet
edge. Figure 21-39 shows the various components required for this model.
Guest Wireless Access at the Converged Access Branch
Converged Access
Branch
Catalyst 3850
Series Switch
CAPWAP
CAPWAP
Internet Edge
Guest
VLAN
WAN
CT5508
Guest WLC
Guest SSID
CAPWAP
Tunnel
CAPWAP Mobility
Anchor Tunnel
Note
ASA
Firewall
AD
Data Center
Internet
ISE
293881
Figure 21-39
When deploying converged access wireless designs in which the Catalyst 3850 Series switch functions
as the Mobility Controller (MC) and Mobility Agent (MA), it should be noted that the mobility tunnel
for wireless guest access initiates from the Catalyst 3850 to the Guest anchor controller located within
the DMZ. Hence each branch will initiate a mobility tunnel for wireless guest access with this design.
The maximum number of mobility controllers within a mobility domain is 72 for the CT5508 wireless
controller. Therefore the maximum number of mobility anchor tunnels is limited to 71 for the CT5508
wireless controller. Therefore the network administrator may need to deploy additional CT5508 guest
anchor controllers. Alternatively, the network administrator may look at providing direct Internet access
from the branch for guest access. Future versions of this design guide may address such designs.
Because separate wireless controllers are deployed for campus and branch wireless access, the same
guest SSID can be configured on both wireless controllers, but with different characteristics, such as rate
limiting. This is one advantage of deploying separate wireless controllers for branch and campus
locations.
Due to the limited amount of WAN bandwidth available at branches, network administrators often have
the requirement to limit the amount of bandwidth that guest users can utilize below that which guest
users can utilize within a campus. The next section discusses rate limiting of wireless guest traffic at the
branch. Most other aspects of branch wireless guest access are essentially carried over from the campus
wireless guest design. For example, branch wireless guests can continue to use Cisco ISE for the guest
portal. Logically the wireless topology for branch guest traffic is the same as wireless access for campus
guest traffic. The main difference is that the capacity of the transport will vary over the guest SSID to a
larger extent than what would be expected in the campus where the physical path is typically supported
by gigabit Ethernet.
21-33
Chapter 21
Rate-Limiting Guest Wireless Access

Note
This section applies only to CUWN wireless controller platforms. Future versions of this design guide
may extend the discussion to Converged Access (IOS XE based) wireless controllers.
The prevalence of mobile devices and the expectation of universal network access have resulted in a
steady increase in the loads on the guest network. This solution offers rate-limiting tools that can be used
to manage these loads. Rate limiting can be configured in various ways-per-user or per-SSID as well as
upstream and downstream.
Note
Per-SSID rate limiting is actually per-BSSID, since the rate limiting is per SSID per access point per
radio. However this design guide refers to this as per-SSID rate limiting.
Per-user rate limiting applies to each specific wireless device. Per-SSID is an aggregate rate shared by
all devices within a given SSID. In both cases, upstream rate limiting occurs on the radio. Downstream
per-SSID rate limiting also occurs on the radio while downstream per-user rate limiting occurs on the
wireless controller.
Rate-limiting in this context is analogous to policing. Packets determined to be in excess of the
configured rate are dropped and not metered or buffered. Policers implement a token bucket. The bucket
is credited with tokens at a rate that equals CIR. When the bucket is full, no additional tokens are added.
Tokens are removed from the bucket when a packet is transmitted, provided a token is available. If no
tokens are available, the packet is discarded. The size of the token bucket determines the burst rate. As
long as tokens are available, packets are transmitted at line rate. In an effort to keep the configuration
intuitive, users configure the burst rate directly and the algorithm determines the appropriate bucket size.
If the burst rate is set to 0, a default bucket size is used. An example of how to configure rate limiting of
the Guest SSID, by overriding the rate limiting settings of the QoS profile assigned to the SSID, is shown
in Figure 21-40.
One unique characteristic of wireless is that not all transmissions occur at a single rate. Signal strength
and signal-to-noise ratio (SNR) will determine the actual speed of the physical medium for any single
station. Unlike wired networks where the speed is fixed at the port rate, wireless rates can vary for each
host on the subnet and may even change as the station moves closer or further from the access point.
With wireless rate limiting, the time required to drain a full token bucket depends on the access speed of
the wireless client and is not fixed. Stations that associated at 54 Mbps will be able to drain a token
bucket faster than those at 1 Mbps. If per-SSID rate-limiting is in place, all clients on a particular AP
share a single bucket. If per-User rate-limiting is in effect, then each station is assigned a unique bucket.
It is possible to do both per-client and per-SSID rate limiting. In this case a token must be available and
is removed from both the shared SSID bucket and per client bucket before the packet is transmitted.
While this may provide more fairness to a slower user trying to access a shared token, it increases the
amount of state information that must be maintained, increasing processing requirements on the
controller. Because many deployments of guest wireless access simply provide best-effort service levels,
extra processing requirements are not typically merited. As such, only per-SSID shaping is shown here.
There may be other situations where a business case does justify doing both per-user and per-SSID rate
limiting simultaneously.
21-34
Chapter 21

Figure 21-40
Example Configuration for Rate Limiting the Guest SSID
One of the branch designs presented within this design guide uses FlexConnect with local branch
termination for corporate wireless clients and central termination for guest traffic. Corporate-approved
devices may send data to servers located within the central datacenter. Alternatively, they may send data
to a local server. Where access to a local server is required, FlexConnect with local termination can save
WAN bandwidth by eliminating the need to transfer data through a CAPWAP tunnel over the WAN to a
central controller. Locally terminated traffic may still travel over the WAN when access to servers
located within the data center is required, but these packets will not be tunneled within CAPWAP. In this
case, normal QoS techniques can be applied. Hence, wireless packets are classified along with wired
traffic. This common classification for corporate wired and wireless devices applies in both the upstream
and downstream direction. With the design presented within this document, CAPWAP tunnels are used
for all guest traffic-traffic from personal devices which have not on-boarded, as well as wireless control
traffic (traffic from the wireless controller and the branch access points). Therefore, of all the CAPWAP
traffic leaving the branch, the majority of packets will likely belong to guest users. This can help
distinguish guest traffic from corporate traffic.
The example configuration shown in Figure 21-40 allows for two classification rates, the data rate and
the real-time rate. Within the context of this configuration, Data is meant to be all TCP flows and
Real-Time is meant to be all UDP flows. As a best practice for QoS, it is recommended to prevent UDP
21-35
Chapter 21
and TCP from competing directly with each other for bandwidth due to differences in how dropped
packets influence flow. Providing distinct token buckets for each protocol prevents any undesirable
interaction between UDP and TCP.
Rate limiting is configured on the foreign controller. When guest access is offered at both the campus
and branch locations, there will be two foreign controllers tunneling to an anchor controller. The rate
limit configured on each foreign controller can be different and unique for that class of users. Typically
the foreign controller servicing campus guests will have a higher bandwidth contract than the foreign
controller servicing branch guest users because of the higher campus bandwidth available when
compared to the WAN.
There are other caveats to be aware off when rate limiting. Because SSID rate limiting occurs at the radio
itself, each radio will limit the SSID to the configured rate. This means that if Branch A and Branch B
are each members of the BYOD_Guest SSID, each branch will limit guest traffic without regard to the
current load in the Guest SSID at the neighboring branch. However, this means if the Guest SSID is
present on two radios at the same branch and the rate is configured for 1 Mbps, the combined rate could
be as high as 2 Mbps over the WAN at that single branch. Even within a single AP, if the Guest SSID is
using the 2.4 GHz radio and the 5 GHz radio, the total bandwidth could be double the configured guest
rate limit. As stated earlier, the rate limiting feature's primary purpose is to protect the radios. Because
of this, rate limiting may necessitate the over subscription of WAN bandwidth intended for guest use.
One possible method to minimize the extent of oversubscription, is for the Guest SSID not to be enabled
on the 5 GHz radio. In addition, the number of APs participating in this SSID should be the minimum
required to provide adequate coverage. AP groups can be used to manage which APs are participating.
Rate limiting a single BYOD_Guest SSID across all branch locations may result in different WAN rates
at different branches, as illustrated in Figure 21-41.
21-36
Chapter 21

Figure 21-41
Rate-Limiting the Guest SSID
Internet
Ethernet-over-IP Tunnel
CAPWAP Tunnels
Unit of Rate
Limited Load
WAN
Branch 1
CAPWAP
2.4 GHz
Radio
Guest
SSID
CAPWAP
2.4 GHz
Radio
Guest
SSID
293883
CAPWAP
Branch 2
In Figure 21-41 assume the rate limiting of the BYOD_Guest SSID is configured for 1 Mbps. At Branch
1, the local WAN circuit could experience as much as 2 Mbps of guest traffic (due to the two APs), while
the WAN aggregation circuit at the head-end could experience up to 3 Mbps of guest load (due to a total
of three APs). If a single SSID is in use for guest traffic, then the configured rate should be appropriate
for the slowest branch location that will be hosting guest traffic. There are some options available to
better manage guest loads at the branch that are discussed below.
Multiple Guest SSIDs and AP Groups

Because traffic limits are established per SSID and because not all branches have the same bandwidth
available for guest use, the administrator may want to establish multiple Guest SSIDs based on the
configured rate-limit. For example, the GUEST_128 SSID may be rate-limited to 128 Kb/s while the
GUEST_256 SSID may be twice as fast. AP groups must be used to ensure both WLANs are not
available at all branch locations. If the majority of branch locations have more than one AP that will host
guest traffic, then the configured rate limit will be less than the actual desired rate to minimize
oversubscription. AP groups can be used to manage how many radios are contributing to the total guest
load for that location. Multiple Guest SSIDs in conjunction with AP groups can be used to ensure
adequate guest coverage without excessive WAN loads. Creating informative names for the branch APs
will simplify creating AP groups.
21-37
Chapter 21
AP Groups are explained in greater detail in the Flex 7500 Wireless Branch Controller Deployment
Guide at:
http://www.cisco.com/en/US/products/ps11635/products_tech_note09186a0080b7f141.shtml#ap-gr.
Managing the Downstream Load

With the FlexConnect design presented within this document, CAPWAP tunnels are used for all guest
traffic, traffic from personal devices which have not on-boarded, as well as wireless control traffic
(traffic from the wireless controller and the branch access points). Figure 21-40 shows an example where
the Silver (best effort) QoS profile applied to the BYOD_Guest SSID. QoS profiles are used to set QoS
markings for wireless data traffic encapsulated within the CAPWAP tunnel. Note that CAPWAP control
traffic is prioritized separately from the settings within the QoS profile. Figure 21-42 shows an example
of the default settings for the Silver (best effort) QoS profile.
Figure 21-42
Default Settings for the Silver (best effort) QoS Profile
The QoS profile can be used to set the following parameters:
21-38
Chapter 21

Maximum PriorityThis limits the maximum 802.11 User Priority marking which can be sent by a
wireless client which supports WiFi Multimedia (WMM). The use of this parameter implies the
SSID is configured to support WMM.
Unicast Default PriorityThis sets the default 802.11 User Priority marking for traffic sent from
wireless client devices which do not support WMM.
Multicast Default PriorityThis sets the default 802.11 User Priority marking for multicast traffic.
The 802.11 User Priority value is then used to set the outer DSCP value of traffic encapsulated within
the CAPWAP tunnel between the Access Point and the CUWN wireless controller. As can be seen above,
the default User Priority is set for best effort, which maps to DSCP 0. Therefore in this example, of all
the CAPWAP traffic traveling towards the branch, the majority of packets marked with DSCP 0 will
likely belong to guest users. This can help distinguish guest traffic from corporate traffic.
Note
The network administrator should note that the default User Priority settings of the Bronze QoS profile
are set for Background. Therefore, if the network administrator wishes to set guest traffic to a lower User
Priority of Background, which maps to DSCP 8 (corresponding to CS1 which is the Scavenger class),
they can do so by assigning the guest SSID to the Bronze QoS profile. The network administrator should
take into account the business requirements of the organization in order to determine whether guest
traffic should be considered Best Effort or Background. Alternatively, the network administrator could
change the default settings of the Silver QoS profile to background. Changing the default settings may
not necessarily be the optimal solution, however, since there are only four QoS profiles which can be
applied to all SSIDs configured within the CUWN wireless controller.
There are two points in the downstream path where loads imposed by the guest users could impact
corporate traffic. These are the outbound interface on the WAN aggregation router and the outbound
interface on the PE router adjacent to the branch. Figure 21-43 highlights the areas of concern in the
downstream direction.
21-39
Chapter 21
Figure 21-43
Downstream Congestion Points
Campus
Internet
Downstream
Load
WAN
Service
Provider
Cloud
Head-End
Bandwidth
Enterprise
Constraint
Branch 1
Service Provider
CAPWAP
CAPWAP
Contraint
2.4 GHz
Radio
Guest
SSID
2.4 GHz
Radio
Guest
SSID
293885
CAPWAP
Branch 2
The Per-SSID rate limiting discussed in the previous section does not provide direct control of the load
on the WAN aggregation head ends imposed by guest users at the branch. The guest load will be
proportional to the total number of branch APs hosting the Guest SSID times the per-SSID rate limit of
the WLAN. Guest wireless traffic may be distinguishable from other WAN traffic because it will be in
a CAPWAP tunnel and marked with the default DSCP setting. Some traffic from employees on-boarding
personal devices will also be marked the same way if the same QoS Profile is applied to the dedicated
provisioning SSID. However the percentage will be very small. It is possible to construct a policy that
will mark CAPWAP packets with default DSCP values into the scavenger class. This will have the effect
of setting guest traffic below the priority of default corporate traffic. When the bandwidth of the WAN
aggregation circuit begins to saturate, this policy will allow wireless guest traffic to be discarded prior
to corporate traffic. If on-boarding traffic is also dropped along with guest traffic, then employees will
need to wait until the WAN loads are lowered prior to bringing a new device onto the network. This is
implemented with traditional QoS policy maps on the outbound circuits of the WAN Aggregation router.
Incidentally the same approach could be used on the branch uplink to manage situations where the
number of APs at the branch could unreasonably oversubscribe the uplinks.
The service provider local links to the branch may also come under load as a result of the guest traffic.
The per-SSID rate-limiting does benefit the branch WAN links in this direction by limiting the effective
guest bandwidth as a result of application-based flow control. An example is TCP-based applications,
which will manage their flow to minimize drops. Even though per-SSID rate-limiting in the downstream
direction is applied at the radio towards the end station, the client application will throttle down to meet
21-40
Chapter 21

the rate available over the entire path. The last hop interface on the SP PE router also contributes to
application throttling if aggressive policers are used to enforce contracted rates. Assuming wireless
guests are remarked scavenger and appropriate DSCP to EXP mappings are being used, then SP policers
should disproportionately impact wireless guest TCP applications. Although guest Internet traffic rarely
uses UDP, it also generally exhibits the same type of flow control behavior as TCP even though the
protocol itself does not implement feedback as part of the transport layer. This is because UDP is often
transactional based. When UDP is used for bulk transfer, blocks of data are numbered and acknowledged
by the application, for example TFTP. A transmitter will not send a block of data until the receiver has
acknowledged the previous block. If a block of data is dropped, the transmitter will wait for a timeout
period before retransmitting the previous block. Two exceptions to UDP application based flow control
are UDP-based IP video surveillance which may not use RTSP to monitor received data and UDP
multicast. Neither of these are typical applications guest will use on the Internet. In any case, per-SSID
rate limiting is an effective means to manage guest traffic on the SPs PE routers.
21-41
Chapter 21
21-42
CH AP TE R
22

Whats New: Added a note about how ACL behavior has changed in version 7.5+ of the Wireless LAN
Controller.
When a previously provisioned device is reported lost or stolen, the device must be denied access to
prevent unauthorized access to the network.
A first level of defense to protect against a lost or stolen device is to enforce the use of a PIN lock, a
passcode required to access the device that may lock the device automatically after a short period of
inactivity (typically five to ten minutes). This can also be enhanced by erasing all data on the mobile
device after a number of failed passcode attempts or performing a selective wipe. This and other rules
may be enforced by the integration of Cisco ISE with a Mobile Device Manager.
The Cisco ISE offers different ways to prevent a lost or stolen device from connecting to the network.
The My Devices Portal allows the employee to mark a device as lost and prevent others from gaining
unauthorized access with that device. In addition, if the device is connected to the network when the
device is marked as lost, the ISE may issue a Change of Authorization (CoA) to force the endpoint off
the network.
The administrator is also able to blacklist a device and force the endpoint off the network. In addition,
the administrator is able to use Endpoint Protection Services (EPS) to quarantine an endpoint from the
network.
Employees and administrators have different capabilities to block lost or stolen devices:
Employees:
From the My Devices Portal:
Report devices as lost.
Enforce a PIN lock through the MDM.
Initiate a remote device wipe through the MDM.
Reinstate a device to regain access without having to register the device again.
Note
Devices that have been fully wiped cannot be restored by ISE and will need to re-register to
recover the certificate and WiFi profile.
22-1
Chapter 22
Blacklist Identity Group
Administrators:
Add the endpoint to the Blacklist Identity Group.
If the endpoint is connected, force it off the network using the Show Live Sessions screen.
Enforce a PIN lock through the Endpoints screen in ISE.
Initiate a remote device wipe through the Endpoints screen in ISE.
Quarantine the endpoint using the ISEs Endpoint Protection Services feature (employees are not
able to reinstate endpoints quarantined by the administrator).
Revoke the devices digital certificate.
Disable the RSA SecurID token..

The Blacklist identity group is system generated and maintained by ISE to prevent access to lost or stolen
devices. In this design guide, two authorization profiles are used to enforce the permissions for wireless
and wired devices within the Blacklist:
Blackhole WiFi Access
Blackhole Wired Access
The Blacklist Identity Group is displayed by clicking Administration > Identity Management >
Groups > Endpoint Identity Groups. Figure 22-1 shows an empty Blacklist identity group containing
one endpoint.
Figure 22-1
Devices that have been blacklisted are assigned to the Blacklist identity group. Both wired and wireless
devices can be placed into the Blacklist identity group. An authorization profile is used to define the
access granted to the blacklisted devices. Blacklisted device connection requests are redirected to a web
page that informs the user that the device is blacklisted.
22-2
Chapter 22

Blacklisting Wireless Devices

To enforce the blacklist permissions, an authorization rule is defined under Policy > Authorization.
Figure 22-2 shows the Wireless Black List Default rule enforcing the Blackhole WiFi Access
permissions.
Figure 22-2
Wireless Black List Default Authorization Rule
The Blackhole WiFi Access authorization profile is configured under Policy > Policy > Elements >
Results > Authorization Profiles, as shown in Figure 22-3. The Access Type is defined as
ACCESS_ACCEPT and the following cisco-av-pairs are defined:
cisco-av-pair: url-redirect=https://ip:port/blackhole/blackhole.jsp. The user gets redirected to this

page when a device is in the Blacklist identity group.
cisco-av-pair: url-redirect-acl=ACL_BLACKHOLE_Redirect. The Wireless LAN Controller must

have an ACL named ACL_BLACKHOLE_Redirect configured for the redirection to work at the
campus and a FlexConnect ACL at the branch with the same name.
This authorization profile only allows access to the ISE Unauthorized Network Access page to inform
the user that access to the network has been denied for that device.
22-3
Chapter 22
Figure 22-3
Blackhole WiFi Access Authorization Profile
The behavior of the two ACLs in the authorization profile is slightly different between CUWN wireless
controllers, such as the CT5508 and Flex 7500, and IOS XE based controllers such as the CT5760 and
Catalyst 3850. For CUWN wireless controllers, ACL_BLACKHOLE_Redirect functions as both the
ACL which controls web redirection, as well as the ACL which controls what the wireless client is
allowed to access on the network.
Figure 22-4 shows how the ACL_BLACKHOLE_Redirect access list is defined in a CUWN WLC to
only allow access to the ISE and DNS server. By granting access to DNS and ISE, the endpoint is able
to reach the blackhole.jsp web page hosted at the ISE.
22-4
Chapter 22

Figure 22-4
ACL_BLACKHOLE_Redirect ACL
Deny access to and from all other addresses.
Note
ACL_BLACKHOLE serves simply as an extra security configuration. CUWN wireless controllers do

not make use of this ACL when URL redirection is specified. For CUWN wireless controllers the
ACL_BLACKHOLE ACL can be the same as the ACL_BLACKHOLE_Redirect ACL.
Note
For endpoints connecting to the branch, a similar FlexConnect ACL is defined and applied to the
FlexConnect Group. Figure 22-5 shows the ACL_BLACKHOLE_Redirect FlexConnect ACL. This ACL
is similar to the one used for campus devices, shown above, but defined under Security > Access
Control Lists > FlexConnect ACLs.
22-5
Chapter 22
Figure 22-5
ACL_BLACKHOLE_Redirect FlexConnect ACL
To apply this FlexConnect from the branch, select the appropriate FlexConnect Group and click the
Policies tab. Add the ACL_BLACKHOLE_Redirect ACL, as shown in Figure 22-6.
Figure 22-6
Policies for Branch1
On converged access products, namely the CT5760 wireless controller or Catalyst 3850 Series switches,
both the BLACKHOLE_ACL_Redirect and BLACKHOLE_ACL ACLs must be configured. An example
of the BLACKHOLE_ACL_Redirect ACL is shown below.
!
ip access-list extended ACL_BLACKHOLE_Redirect/ Blacklisting Redirection ACL
deny
deny
deny
ip any host 10.225.49.15
permit ip any any
!
Deny DHCP access (bootpc and bootps).
Deny IP access to and from the DNS server (10.230.1.45).
Deny IP access to and from the ISE server (10.225.49.15).
22-6
Chapter 22

Allow (redirect) all other IP access.
The ACL above causes any web traffic (HTTP or HTTPS) from any source to any destination to be
redirected to the blacklisted devices web page within the Cisco ISE.
The authorization profile also applies a second, RADIUS specified local ACL (BLACKHOLE_ACL)
across the WLAN for network access. The CT5760 and Catalyst 3850 Design use named ACLs. The
name of the ACL is sent from the ISE to the Catalyst 3850 Series switch or the CT5760 wireless
controller via the RADIUS Airespace-ACL-Name attribute-value pair within the Airespace dictionary.
The specific form for the example is as follows:
Airespace-ACL-Name = ACL_BLACKHOLE
The WLAN access-control ACL (ACL_BLACKHOLE) determines what traffic is allowed on the WLAN
by the Catalyst 3850 series switch or the CT5760 wireless LAN controller. An example of the
BLACKHOLE_ACL ACL is shown below.
!
ip access-list extended ACL_BLACKHOLE/ Blacklisting Access Control ACL
permit udp any host 10.230.1.45 eq domain
!
Implicitly deny all other IP access.
The ACL above allows traffic from any source to the blacklisted devices webpage within the Cisco ISE.
Once a device is in the Blacklist identity group, future attempts to connect to the network are denied.
When a user opens a web browser on a blacklisted device, the session is redirected to the page shown in
Figure 22-7.
Figure 22-7
Unauthorized Network Access
22-7
Chapter 22
Figure 22-8 shows how a device in the Blacklist attempts to connect to the network and how the
Blackhole WiFi Access authorization profile is applied.
Figure 22-8
Device in Blacklist Identity Group
Blacklisting Wired Devices

The user experience when a wired device is blacklisted is similar to a wireless device that has been
blacklisted. The ISE authorization policy rule for blacklisting of on-boarded wired devices will be the
same for devices connected via Converged Access products and other Catalyst switches for BYOD.
When a device is blacklisted and the user attempts to access any web page, the device is re-directed to
the portal that lets the user know that the device has been identified as lost. The following steps show
how to implement this behavior:
Step 1
Create an ACL_BLACKHOLE downloadable DACL that only allows access to the ISE.
Step 2
Create a URL Redirect ACL called ACL_BLACKHOLE_Redirect on the access layer switch that
matches any HTTP or HTTPS traffic.
Step 3
Create a Blackhole Wired Access authorization profile that pushes the DACL and redirect-link to the
switch.
Step 4
Define a new rule in the Authorization policy that matches on the blacklisted devices and assigns the
authorization profile Blackhole Wired Access.
Creating a Downloadable ACL on ISE

The ACL_BLACKHOLE DACL is created under Policy > Policy Elements > Results > Downloadable
ACLs, as shown in Figure 22-9.
22-8
Chapter 22

Figure 22-9
ACL_BLACKHOLE DACL
The ACL above allows traffic from any source to the blacklisted devices webpage within the Cisco ISE.
Creating the URL REDIRECT ACL on the Switch

The configuration of the URL redirect ACL is the same, regardless of whether the switch is a Converged
Access Catalyst 3850 Series switch, or a Catalyst 3750-X series switch. An example of the configuration
for the ACL_BLACKHOLE_Redirect ACL on the wired switch is shown below.
!
ip access-list extended ACL_BLACKHOLE_Redirect
ip any host 10.225.49.15
permit ip any any
/ Blacklisting Redirection ACL
Note that this is the same URL redirect ACL used for blacklisted wireless devices for the Catalyst 3850
Series switch, discussed above. Bear in mind that the ACL is only required on the Catalyst 3850 and not
on the CT5760 wireless controller because only the Catalyst 3850 supports direct connection of wired
clients through its switch ports.
Configuring the Authorization Profile

Define an authorization profile called Blackhole Wired Access under Policy > Policy Elements >
Results > Authorization Profiles, as shown in Figure 22-10.
22-9
Chapter 22
Figure 22-10
Blackhole Wired Access Authorization Profile
The following cisco-av-pairs are defined:
cisco-av-pair: url-redirect=https://ip:port/mydevices/blackhole.jsp. The user gets redirected to this

page when a device is in the Blacklist identity group.
cisco-av-pair: url-redirect-acl=ACL_BLACKHOLE_Redirect. The access layer switch must have an

ACL named ACL_BLACKHOLE_Redirect configured for the redirection to work.
Creating a Rule in the Authorization Policy

The last configuration step is to create a new rule in the authorization policy that uses the Blackhole
Wired Access authorization profile created above when it matches a dot1x wired device which is
blacklisted. Figure 22-11 displays the rule.
22-10
Chapter 22

Employees My Devices Portal
Figure 22-11
Wired Black List Default
Once the rules are defined, a blacklisted wired device will be denied access to the network.

Using the My Devices Portal, employees are able to mark any of their devices as Lost to prevent further
network access. The portal requires user authentication and displays the devices that have been added or
registered by the employee. The My Devices Portal may be accessed from the following URL:
https://<ISE_IP_Address>:8443/mydevices/
In addition to being able to report a device lost or stolen, the portal is used to enforce MDM Actions,
such as PIN lock and device wipes through MDM integrations. Figure 22-12 shows the My Devices
Portal page.
Figure 22-12
My Devices Portal
22-11
Chapter 22
The portal displays devices assigned to the employee or previously registered using the self-registration
portal.
Reporting a Device as Lost

The employee is able to edit the devices description and report a device as lost, as shown in
Figure 22-13.
Figure 22-13
Lost Device
Before blacklisting a device, ISE displays the warning shown in Figure 22-14.
Figure 22-14
Blacklist Warning
Once the device is marked as lost, the device is added to the Blacklist Identity Group. If the device is
connected to the network at that time, ISE issues a Change of Authorization (CoA) and forces the device
off the network. To verify that the device has been added to the Blacklist Identity group, click
Administration > Identity Management > Groups > Endpoint Identity Groups and review the
Blacklist. Figure 22-15 shows the MAC address added to the Blacklist.
22-12
Chapter 22

Figure 22-15
Reinstating a Device
The My Devices Portal also gives the user the option to reinstate a blacklisted device, allowing the device
to regain access to the network. Figure 22-16 shows the Reinstate option.
Figure 22-16
Reinstate a Device
Before reinstating a device, ISE displays the warning shown in Figure 22-17.
22-13
Chapter 22
AdministratorsBlacklisting a Device
Figure 22-17
Reinstate Warning
PIN Lock and Device Wipes

The integration with an MDM provides additional device control to the user. With the My Devices Portal,
the employee is able to:
Initiate a Corporate WipeRemove settings and applications configured in the MDM policies.
Initiate a Full WipeRemove all information from the device (factory reset).
Enforce a PIN lockLock the device.
Figure 22-18 shows the MDM actions available from the My Devices Portal:
Figure 22-18
MDM Actions from My Devices Portal
Administrators are able to blacklist a device by adding it manually to the BlackList Identity Group. Click
Administration > Groups > Endpoint Identity Groups > Blacklist and add the MAC address of the
device to be blacklisted. Figure 22-19 shows the MAC address added to the identity group.
22-14
Chapter 22

Figure 22-19
Device to be Blacklisted
Note that by adding the device to the Blacklist Identity Group, ISE prevents future attempts to connect
to the network, but if the user is currently connected to the network, an additional step is required to
force the endpoint off the network.
To force a device off the network, click Operations > Authentications > Show Live Sessions, as shown
in Figure 22-20.
Figure 22-20
Show Live Sessions
To terminate the endpoints session, select Session termination from the CoA Action menu, as shown in
Figure 22-21.
22-15
Chapter 22
Figure 22-21
Note
Session Termination
The employee has the option to reinstate a device that was blacklisted by the administrator using the My
Devices Portal.
MDM Actions
The administrator also has the option to initiate MDM actions on the endpoints. To perform an action,
click on Administration > Identities > Endpoints and select the appropriate device, as shown in
Figure 22-22.
Figure 22-22
MDM Actions
22-16
Chapter 22

Endpoint Protection Services (EPS)

Endpoint Protection Services is a service provided by the ISE to extend the monitoring and controlling
capabilities of endpoints. EPS also monitors and changes the authorization state of endpoints. EPS can
be used to change the authorization state of an endpoint without having to modify the overall
authorization policy. EPS allows the administrator to quarantine or limit access to a device and
unquarantine a device or allow full access to the network to reverse the quarantine status.
Note
EPS requires an ISE Advanced license.

To enable EPS, click Administration > System > Settings > Endpoint Protection Services and select
Enabled, as shown in Figure 22-23.
Figure 22-23
Enable EPS
Create an authorization profile to define the permissions to specified network services. Click Policy >
Policy Elements > Results > Authorization > Authorization Profiles and define a new authorization
profile, as shown in Figure 22-24.
22-17
Chapter 22
Figure 22-24
EPS_Quarantine Authorization Profile
Create an EPS Exception policy and rule to be processed before the standard policies are processed.
Click Policy > Authorization > Exceptions > Create a New Rule, as shown in Figure 22-25.
Figure 22-25
EPS Exception Policy
22-18
Chapter 22

Enter a Rule Name and under Conditions create a new condition (Advanced Option). Under Expression
click Select Attribute and select EPSStatus Equals Quarantine, as shown in Figure 22-26.
Figure 22-26
EPS Exception Policy
Under Permissions, select the previously defined EPS_Quarantine Authorization Profile. Figure 22-27
shows the complete Exception policy.
Figure 22-27
EPS Quarantine Permissions
To quarantine a device, click Operations > Endpoint Protection Service and enter the endpoints MAC
Address to be quarantined. Under Operation select Quarantine, as shown in Figure 22-28.
Figure 22-28
EPS
As soon as the administrator clicks Submit, the device is forced off the network and future attempts to
connect are rejected.
22-19
Chapter 22
Figure 22-29 shows the EPS_Quarantine authorization profile being applied and how a device is denied
access.
Figure 22-29
Quarantined Endpoints
EPS provides an extra layer of control to monitor and change the authorization state of endpoints.
Note
Since EPS has higher precedence over blacklisted devices, employees do not have the option to reinstate
devices that have been quarantined by the administrator.
To unquarantine a device, enter the devices MAC address and select Unquarantine from the operation
pull down menu, as shown in Figure 22-30.
Figure 22-30
Unquarantine a Device
The EPS activities are logged by ISE and can be reviewed by clicking Operations > Reports >
Endpoints and Users > Endpoint Session History. Figure 22-31 shows one of the reports that includes
endpoint information.
22-20
Chapter 22

Figure 22-31
EPS Logs
Revocation of Digital Certificate

Administrators also have the option of revoking an employees digital certificate from the CA server to
prevent further use by unauthorized devices. The CA server periodically publishes the Certificate
Revocation List (CRL). ISE is configured to validate the certificate presented by the clients against the
CRL list. If there is a match, the ISE rejects the digital certificate presented by the client.
The first step is to revoke the digital certificate from the CA server. Figure 22-32 shows how to revoke
the digital certificate for username toby.
Figure 22-32
Revoking the Digital Certificate on the CA Server
Once the above process is complete, the certificate serial number is added to the Certificate Revocation
List (CRL). Figure 22-33 displays the CRL information.
22-21
Chapter 22
Figure 22-33
Certificate Revocation List
This information is periodically published by the CA server. Figure 22-34 shows the location of the CRL
where the ISE can download the list.
Figure 22-34
CRL Distribution Point
The next step is for ISE to be configured with CRL distribution location so that it can periodically
download the list and compare it with the certificates presented by the clients. Click Administration >
Certificates > Certificate Authority Certificates and configure the CRL values, as shown in
Figure 22-35.
22-22
Chapter 22

Figure 22-35
CRL Location Information on the ISE
Disable the RSA SecurID Token

When a device that has been previously provisioned is reported lost or stolen, the device must be denied
access to prevent unauthorized access to the network. In addition, the remote users RSA SecurID token
must be disabled at the RSA Server so that the remote user cannot use the network. Figure 22-36 shows
how to disable the RSA SecurID token at the RSA server.
Figure 22-36
Disabling the RSA SecurID Token
22-23
Chapter 22
22-24
CH AP TE R
23
BYOD Policy Enforcement Using Security Group

Access
Whats New: In the previous version of the BYOD CVD, TrustSec in the use of security group tags was
addressed in a Centralized Unified Wireless Design within a campus, where users attaching to the
wireless network based on authentication credentials in the respective authorization were assigned a
security group tag.
In this version of the BYOD CVD, the use of security group tags as a means for enforcing policy is
expanded to include a Centralized Unified Wireless Design incorporating the Cisco CT 5760 wireless
controller as well as in a Converged Access infrastructure using the Cisco Catalyst 3850. In the CUWN
design both the CT 5508 and the CT 5760 wireless controllers are used in parallel to terminate wireless
devices in the campus. Additionally, policy enforcement for wireless access via the Catalyst 3850 and
its integrated controller, when deployed in the campus access layer, is expanded to include the use of
security group tags in addition to access control lists used in the previous version of the BYOD CVD.
As in the previous version of the BYOD CVD, this version continues to demonstrate the use of security
group tags for policy enforcement in the same two scenarios using both SG ACLs on Nexus and Catalyst
switches for the first scenario and the ASA security appliance in conjunction with the Security Group
Firewall (SG-FW).

The previous version of the BYOD CVD relied primarily on Access Control Lists for policy enforcement
to restrict user traffic as appropriate upon successful authentication and authorization. The use of ACLs
can become a daunting administrative burden when factoring the number of devices on which they are
applied and the continual maintenance required to securely control network access.
This version of the BYOD CVD uses a complimentary technology known as TrustSec and the use of
Security Group Tags (SGT). Security Group Tags offer a streamlined and alternative approach to
enforcing policy and traffic restrictions with minimal and, in some cases, little or no ACLs at all if
TCP/UDP port level granularity is not required.
Security Group Tags are used as an alternative to ACLs for enforcing role-based policies for campus
wireless devices where the Cisco Wireless Controllers have been centrally deployed and configured for
operation in local mode (wireless traffic locally switched at the controller).
23-1
Chapter 23
ACL Complexity and Considerations

To date, variations of named ACLs on wireless controllers, static and downloadable ACLs on various
routing and switching platforms, as well as FlexACLs for FlexConnect wireless traffic in the branch have
been used as a means of enforcing traffic restrictions and policies. In order to configure and deploy these
ACLs, a combination of either command line (CLI) access to each device via Telnet/SSH or network
management such as Prime Infrastructure have been required and used for statically configured ACLS
while the Cisco Identity Services Engine (ISE) has been used to centrally define and push downloadable
ACLs (DACL) to switching platforms.
Unique ACLs may be required for different locations such as branches or regional facilities, where
user permissions may need to be enforced for local resources such as printers, servers, etc.
The operational complexity of ACLs may be impacted by changes in business policies.
The risk of security breaches increases with potential device misconfigurations.
ACL definitions become more complex when policy enforcement is based on IP addresses.
Platform capabilities, such as processor memory, scalability, or TCAM resources may be impacted
by complex ACLs.
Ciscos TrustSec provides a scalable and centralized model for policy enforcement by implementing
Cisco's Security Group Access architecture and the use of Security Group Tags.
Security Group Tag

Security Group Tags, or SGT as they are known, allow for the abstraction of a hosts IP Address through
the arbitrary assignment to a Closed User Group, represented by an arbitrarily defined SGT. These tags
are centrally created, managed, and administered by the ISE. The Security Group Tag is a 16-bit value
that is transmitted in the Cisco Meta Data field of a Layer 2 Frame as depicted in Figure 23-1.
Figure 23-1
Layer 2 SGT Frame Format
Authenticated
Encrypted
SMAC
802.1AE Header
CMD EtherType Version
Length
802.1Q
CMD
SGT Opt Type
ETYPE
PAYLOAD
SGT Value
ICV
CRC
Other CMD Options
293619
DMAC
Cisco Meta Data
The Security Group Tags are defined by an administrator at Cisco ISE and are represented by a
user-defined name and a decimal value between 1 and 65,535 where 0 is reserved for Unknown.
Security Group Tags allow an organization to create policies based on a user's or device's role in the
network providing a layer of abstraction in security policies based on a Security Group Tag as opposed
to IP Addresses in ACLs.
The SGT is dynamically assigned, or bound, to user/devices IP Address upon successful AAA
Authentication and subsequent Authorization to the network via Cisco ISE. This SGT mapping is
communicated to and stored at the Network Access Device (NAD) serving as the Authenticator. On
23-2
Chapter 23

Cisco switches, these mappings may be dynamically created through RADIUS Attribute Value (AV)
pairs passed down from ISE; or may optionally be defined at the device for a hosts IP Address, physical
port, VLAN, or subnet, depending on the switching platforms capabilities. In the case of Cisco Unified
Wireless Network (CUWN) wireless LAN controllers such as the WiSM2 or CT5508 however, these IP
to SGT mappings can only be dynamically created at the controller through the information
communicated by ISE. For specific platform capabilities, refer to the appropriate configuration guides
found at http://www.cisco.com or in the Cisco TrustSec Switch Configuration Guide at:
http://www.cisco.com/en/US/docs/switches/lan/trustsec/configuration/guide/sgacl_config.html#wp105
4201.
For additional information regarding the Security Group Access architecture, refer to the TrustSec
Design and Implementation Guide at:
http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns744/landing_DesignZone_TrustSec.html.
Security Group Access Domain Infrastructure

There are two methods of configuring the infrastructure to support TrustSec enabling the forwarding and
policy enforcement of frames with an embedded Security Group Tag.
TrustSec using 802.1X for Link Encryption
TrustSec in Manual Mode for Link Encryption
Common to both of these methods is first the ability to employ MACsec (802.1ae) which provides
encryption, a message integrity check, and data-path replay protection for links between adjacent
network devices thereby protecting the CMD field and the SGT value it contains. Second is configuration
for 802.1X authentication between those network devices that will enforce policies based on the SGT
and the Cisco Identity Services Engine (ISE) acting as an Authentication Server.
TrustSec Using 802.1X for Link Encryption

The first method for configuring an TrustSec infrastructure makes use of 802.1X to establish a domain
of authenticated and trusted network devices. Every networking device in the TrustSec Domain must be
authenticated either directly with ISE, or through its neighbor acting as an authenticator on behalf of the
Supplicant network device.
The first networking device to join a TrustSec Domain is considered to be the Seed Device. When first
powered on, it acts as an 802.1X supplicant joining the TrustSec Domain through an EAP-FAST
exchange with ISE as the Authentication Server. Upon successful authentication with ISE, the network
device will, through the EAP provisioning tunnel, receive a Protected Access Credential (PAC) key and
secure token generated by ISE. This key is used for all future RADIUS Exchanges with ISE.
Seed devices are configured with the list of ISE servers against which it can authenticate. It is not
necessary to provide this list of AAA servers on every device when 802.1X is used and subsequently, as
adjacent networking devices configured for TrustSec come up, the seed device will act as an 802.1X
Authenticator to its neighbor as a Supplicant. As such these neighbors are considered to be non-seed
devices. This process is known as Network Device Admission Control or NDAC. Once the networking
devices have authenticated against ISE, a common Pairwise Master Key (PMK) is derived for use by both
sides during subsequent mutual authentication and MACsec negotiation with optional encryption for
each of the interconnecting interfaces.
Finally each device, using the credentials acquired after successful authentication with ISE, will through
Secure RADIUS exchange, acquire SGT definitions and policies to be enforced in the network.
23-3
Chapter 23
For additional information regarding NDAC and MACsec, please refer to the Cisco TrustSec 3.0
document Introduction to MACSec and NDAC which can be found in Design Zone on Cisco.com at:
TrustSec in Manual Mode for Link Encryption

The second method, depicted in this CVD, does not rely on 802.1X for device link authentication and
encryption. To enable link protection without 802.1X, TrustSec manual mode can be configured such
that a common Pairwise Master Key (PMK) is manually configured on the respective interfaces for use
by both sides during subsequent MACsec negotiation and optional encryption. This is one of the primary
differences with TrustSec with 802.1X wherein this key is dynamically derived from the credentials
acquired from ISE after successful authentication.
Another distinction between 802.1X mode and manual mode lies in how the concept of a TrustSec
domain of trust is established. When using 802.1X for link authentication, the network device credentials
are used during the process of bringing the link up and subsequent authentication with the peer interface;
this establishing a trust state with the adjacent device. As this 802.1X-based mechanism is unavailable
when configuring manual mode, a static policy must be defined establishing a trusted state on both side
of a TrustSec enabled link in addition to the manual PMK configuration.
As in the case of TrustSec with 802.1X link authentication, communication on the links between trusted
devices in the TrustSec domain can be secured with a combination of encryption, message integrity
checks, and data-path replay protection mechanisms through the use of 802.1ae MACsec. This
encryption capability allows the SGT value carried in the Cisco Meta Data (CMD) field of the 802.1q
Header to be protected. Today, there are two keying mechanisms available for use with 802.1ae based
encryption, the first is a Cisco proprietary protocol known as Security Association Protocol or SAP
(similar to 802.1X-2010 MKA) and the second, a standards-based mechanism known as MACsec Key
Agreement or MKA. Both use Galois Message Authentication Code (GMAC) as a mechanism to provide
authentication and 128-bit AES-GCM (Galois/Counter Mode) symmetric encryption, which is capable
of line-rate encryption and decryption for both 1 GB and 10 GB Ethernet interfaces, and provides replay
attack protection of every frame. Within this CVD, SAP is used as the keying mechanism for all 10GE
MACsec links.
SAP, is a key derivation and exchange protocol based on a draft of IEEE 802.11i which performs the
following functions:
Negotiate cipher suite for data traffic.
Derive session keys for data traffic.
Exchange SCIs (Secure Channel Identifier) that will be used by data traffic.
Ensure that the exchange is being performed with the same devices that participated in
authentication.
Perform the exchange with an acceptable degree of security (i.e. confidentiality, protection against
MiM attacks, message integrity, etc.).
SAP supports the following modes:
gcm-encryptGMAC authentication, GCM encryption
gmacGMAC, authentication only, no encryption
no-encapNo encapsulation, no SGT plain Ethernet
nullEncapsulation/SGT present, no authentication, no encryption
23-4
Chapter 23

When configuring the TrustSec infrastructure to make use of Manual Mode on the links as opposed to
802.1X mode, there is no requirement to configure every network device to support 802.1X-based link
authentication. However, the requirement for 802.1X configuration and network device authentication
at ISE still exists for those devices that will require SGT definitions and mappings as well as for
SGT-based policy enforcement.
In order to authenticate, the network device(s) will require a configuration identifying the AAA servers
(ISE) against which they will authenticate. Once a device has successfully authenticated, secure
RADIUS using a PAC key and secure token acquired during authentication is used to communicate with
ISE to acquire TrustSec environmental data such as the Security Group Name and the numeric value
associated with the tag, an optional SGT used by the device to source packets, and SGT/IP mappings
that have been created at ISE. Additionally, policies based on SGTs in the form of SGACLs created at
ISE are pushed out to those devices capable of enforcing them such as certain Catalyst and Nexus
switching platforms.
Note
At the time of this writing, the ASA only receives the SG Name and Tag value and does not support
dynamic policy download; ACEs containing SGTs must be locally defined on the ASA. The ASA
however must store a PAC key/token which is provisioned at the ASA in order to dynamically acquire
Security Group Names and Tag values as created within ISE for later use in defining those policies based
on SGT. Wireless controller platforms such as the WiSM2 and 5508, although defined at ISE to support
802.1X wireless client authentication, do not download any TrustSec environment data but merely
receive SGT mapping information upon successful client authorization to be discussed later.
In the BYOD CVD, this 802.1X configuration for network device authentication will be configured at
several locations in the infrastructure to be discussed later:
A Catalyst 6500 VSS switch in a Shared Services block where the wireless controllers have been
deployed
The CT-5760 wireless controller in Shared Services
Catalyst 3850 Converged Access switches providing access layer connectivity
At two Nexus 7000 Data Center aggregation switches
As discussed later, these will be the locations in the network where policies based on SGTs will be
enforced using dynamically acquired SGACLs. Although it is entirely possible to configure every device
in the path for 802.1X authentication, it is purely optional as SGACLs are enforced upon egress from the
device having a corresponding destination IP Host to SGT mapping matching an SGACL. The devices
that are in the path between source and destination will not have this mapping typically and hence this
TrustSec environment data will not be applicable or enforceable.
Security Group Tag Distribution and Forwarding Mechanisms

In order to impose or forward a frame with an SGT Value, specialized switching ASICs are required for
forwarding on Ethernet Ports. A variety of Cisco switching platforms in the Nexus and Catalyst families
support the inline tagging of an SGT value on 10G Ethernet Ports and, to a lesser extent, 1G Ethernet
depending on the platform. This SGT inline tagging capability is sometimes referred to as
SGToverEthernet or native tagging. In this CVD the following network infrastructure supporting SGT
imposition and forwarding (native tagging) will be used:
Catalyst 6500 with SUP2T and WS-X6904 linecards. 10G interfaces in Shared Services, Core,
Campus Distribution.
23-5
Chapter 23
Nexus 7000 with SUP2 and a combination of F2e and M1 linecards. 10G interfaces in the Data
Center.
Converged Access Catalyst 3850. 10G interfaces in Campus Access.
CT-5760 wireless controller. CUWN (centralized) wireless access 10G interfaces.
For specific information regarding platform support for SGT inline tagging, refer to the appropriate
product documentation at: http://www.cisco.com or the TrustSec Switching Configuration Guide at:
http://www.cisco.com/en/US/docs/switches/lan/trustsec/configuration/guide/trustsec.html.
For the network access devices (NAD) capable of SGT native tagging, when a user or device is
authenticated and a SGT Value has been forwarded as a RADIUS AV to the NAD, this IP to SGT
mapping will be created and stored at the access switch or controller. Frames sourced from that user or
device will be tagged upon egress from the switch or controller on a physical port or, in the case of an
SVI, internally associated with the packet as it egresses the SVI. In either case, if an SGACL is matched
prior to egress from the device or SVI, the action defined in the SGACL will be enforced otherwise the
packet with the imposed SGT will be forwarded.
Note
SGACLs are always enforced upon egress from a device or SVI and only if the network device has a
local mapping for the destination SGT enforced by the SGACL. SGACLs may also be enforced within
a VLAN if configure to do so with SGACL enforcement occurring at the destinations egress port.
In certain Catalyst and Nexus switching products, it is also possible to enable role-based enforcement
within a VLAN, where an SGACL may be enforced between devices with different SGT values. Refer
to Figure 23-2.
Figure 23-2
SXP Advertisement, SGT Imposition, and SGACL Enforcement
Policy Enforced
on Egress
12
Tag
Frame
50
12
SGACL Deny 1250

SXP
12
12
12
MS-AD
PKI
Cisco ISE
10.192.5.100SGT12
SGT-Capable Link
12
Role-Based VLAN
Enforcement
23-6
294948
10
Chapter 23

Packets that have a Security Group Tag applied can be forwarded throughout an infrastructure as long as
those network devices support SGToverEthernet, native tagging, and the link has been configured with
the appropriate policy defining whether those tags should be trusted or re-written through the use of the
<policy static> command on the TrustSec interface. As a packet arrives at a switch that supports
SGToverEthernet for example, the switch will remove and inspect the header to perform forwarding
lookups, apply any QOS treatment, and act upon any security ACLs configured there. Providing the
intermediate device does not have an IP to SGT mapping that is denied in an SGACL at this device, the
packet will be forwarded along with the associated SGT towards the destination where an egress SGACL
will be enforced (permit or deny).
For those platforms that do not support the native SGT tagging capabilities, the SGT eXchange Protocol
or SXP as it is known was created to advertise IP Address to SGT Binding information. On devices that
support SXP only, they are considered to be SGT-Aware, the 802.1X authentication and authorization
of a user is exactly the same as those devices supporting native tagging. On these devices supporting
SXP, the IP to SGT mapping is created and maintained and can be advertised to a device where native
tagging is supported. This advertisement or SXP Peering as it is known can be created to an adjacent
device or one that is multiple Layer 2 or Layer 3 hops away as SXP uses TCP as a communications
transport between peered devices. Refer to Figure 23-2.
As untagged packets sourced from a device advertising IP to SGT mappings via SXP arrive at a switch
that is capable of native tagging, the source IP Address is identified and either the associated SGT can
be added to the packet and forwarded or an applicable SGACL enforced.
In the previous version of this CVD where the CT-5508 was used exclusively as the wireless controller,
it was necessary to advertise the IP/SGT mappings to the Catalyst 6500 VSS Shared Services switch with
the tag being inserted upon egress from the 6500. In the current CVD, the CT-5760 will be highlighted
in addition to the CT-5508 and supports native tagging, so all frames egressing the CT-5760 will carry
the appropriate SGT. Figure 23-2 depicts the tag insertion behavior of CT-5508 and CT-5760.
For a detailed explanation of SXP and SGT, see the TrustSec Design and Implementation Guide at:
User Policies with SGT

When a user/device accesses the network for the first time, whether wired or wireless, as described in
the CVD, the network access device (NAD), wireless controller or switch, serves as an 802.1X
authenticator to start the authentication process. The AAA server against which the user will be
authenticated will be the Cisco Identity Services Engine (ISE). As this is the first time the device has
been seen on the network, it will first be provisioned with the proper credentials for access to the
network. During this provisioning process, access to the network will be restricted though the use of
standard ACLs to those services such as DHCP, DNS, ISE, and the Google PlayStore required for
on-boarding the device as specifically defined in the BYOD CVD.
Once a device has been successfully on-boarded and provisioned, the network access device (NAD) once
again acts as an 802.1X authenticator to start the device/user authentication process with ISE. During
this authentication process, the device/user is identified based on credentials offered such as a Digital
Certificate or Active Directory Group membership. In past versions of the BYOD CVD, once
authenticated, users or devices would have been authorized and based on a matching policy would have
either been granted unrestricted access to the network or perhaps partial access, restrictions enforced by
a suitable ACL either downloaded in the case of switches or associated with a statically configured
(named) ACL on the networking device. As an alternative to this approach, an SGT can be used and upon
identifying the appropriate authorization policy in ISE, the NAD will receive and store the appropriate
SGT to be associated with the user or device's IP Address, commonly referred to as an IP to SGT
Binding.
23-7
Chapter 23
Based on these Security Group Tags, role-based policies can be enforced on supporting hardware
through the use of Security Group ACLs (SGACLs) on Cisco switching infrastructure, policies defined
on Security Group Firewalls (SGFW) such as the ASA, or an SGFW implemented on the IOS
Zone-Based Firewall (ZBFW) on Cisco Routers. These policies may be as simple as a permit or deny an
SGT statement or may include specific IP Port information in addition to source or destination SGT to
identify specific applications or traffic.
It should be apparent, that when an abstraction layer such as the TrustSec architecture and SGTs are
used, device and virtualized server mobility is greatly enhanced as the IP Address of the device is no
longer a consideration in enforcing policies in the network. This is true as long as the SGT value was
dynamically assigned through a port profile when using the Nexus 1000V, by ISE based on authorization
policy, or if the mapping was the result of a VLAN, L3 interface, or IP Subnet to SGT Binding with the
VLAN, L3 interface, or Subnet duplicated on other devices. Now, as an entity moves in the network
either through mobile roaming or server vMotion by virtue of the port profile when using the Nexus
1000V, one need not be concerned with having appropriate address-based ACLs defined on the
destination device. The policy can follow them based on the SGT they have been assigned. If however
the IP Host Address to SGT mapping were statically defined at a networking device, that mapping is only
resident on that device and not shared with other devices in the TrustSec Domain.
Through the use of Security Group Tags, it will be possible to eliminate many of the Downloadable and
named ACLs required in previous BYOD CVDs with a ubiquitous set of tags applicable to an entire
domain and managed centrally at the ISE.
This CVD uses TrustSec as an alternative to named ACLs for campus wireless (centralized) access. As
of Cisco Unified Wireless Networking (CUWN) software release 7.4MR1 and 7.5 for the WiSM2 and
CT5508, sixty-four ACLs can be configured, each having sixty-four Access Control Entries or ACEs
(permit/deny statements) within an ACL. In most organizations this may not be an issue, however in
others, this may be too limited when using ACLs to segment the network based on roles or device types
or if the devices are a Corporate or Personal asset. When using ACLs, a Named ACL is created on the
wireless controller and as a user is authenticated and authorized, ISE pushes down the name of the ACL
to be applied to the user in the RADIUS AV pair returned to the controller. If there are more than
sixty-four unique roles, or more likely more than sixty-four Access Control Entries in an ACL, the use
of named ACLs will not be possible. For these scenarios, TrustSec offers an extremely scalable
alternative where hundreds of roles may be identified for users or devices, thereby eliminating the
requirement for the use of specific IP addresses in an ACL.
The policies demonstrated in this CVD cover the use case where North/South (wireless access to data
center) policies need to be enforced restricting access to resources in the data center. Although entirely
possible, East/West (wireless user to user) policy enforcement using SGT will be considered out of scope
for this version of the CVD. East/West traffic enforcement will be included in a future version of the
BYOD CVD when wired access with SGT is addressed.
SGT Assignment for Data Center Servers

Unlike campus access through Catalyst Switches and Cisco Wireless Controllers where dynamic SGT
mappings are communicated and created through 802.1X and RADIUS exchange, the vast majority of
organizations do not implement 802.1X for server connectivity. As such, data center switches such as
the Cisco Nexus switches provide only limited support for the use of 802.1X and do not specifically
support an SGT RADIUS AV as an option. Although 802.1X support would be available if using Catalyst
Switches in the data center, this use case is not covered. Therefore, IP Address to SGT mappings for
these resources must be either manually defined as in the case of bare metal servers and non-Cisco
virtual switches or within port profiles if the Cisco Nexus 1000V virtual switch is deployed.
For purposes of this CVD, the IP to SGT Bindings have been defined at Nexus 7000 data center
aggregation switches, as depicted in Figure 23-3.
23-8
Chapter 23

Figure 23-3
Server IP to SGT Bindings
Shared Services
IPSGT Bindings Defined
Data Center
Catalyst
6500 VSS
DNS
DHCP
CA
AD
Nexus
5000 VPC
Nexus
7000 VPC
CT5508
Controller
DC Core
DC Agg
Cisco ISE
Cisco
ASA
Application and
File Servers
Campus Core
293621
Catalyst
6500 VSS
In addition to the manual creation of an IP Address to SGT mapping either globally, or within a VLAN
for enforcement of intra-vlan traffic between hosts belonging to different Security Groups, the Nexus
7000 also supports the following:
Assigning an SGT to a port for all data sourced from a host attached to that port.
Support for mapping an SGT to a VLAN such that all traffic from hosts within that VLAN will be
tagged accordingly.
Support for mapping an SGT to an IP Address within a VRF.
The VLAN to SGT mapping feature was first introduced in NX-OS v6.2.2 for the Nexus 7000. The
VLAN to SGT mapping feature binds an SGT to packets from a specified VLAN. This simplifies the
migration from legacy to TrustSec-capable networks as follows:
Supports devices that are not TrustSec-capable but are VLAN-capable, such as legacy switches,
wireless controllers, access points, VPNs, etc.
Provides backward compatibility for topologies where VLANs and VLAN ACLs segment the
network, such as server segmentation in data centers.
When a VLAN is assigned a gateway that is a switched virtual interface (SVI) on a TrustSec-capable
switch and IP Device Tracking is enabled on that switch, then TrustSec can create an IP to SGT binding
for any active host on that VLAN mapped to the SVI subnet.
IP-SGT bindings for the active VLAN hosts are exported to SXP listeners. The bindings for each mapped
VLAN are inserted into the IP-to-SGT table associated with the VRF the VLAN is mapped to by either
its SVI or by a cts role-based l2-vrf cts global configuration command.
VLAN to SGT bindings have the lowest priority of all binding methods and are ignored when bindings
from other sources are received, such as from SXP or CLI host configurations.
23-9
Chapter 23
Note
For VLAN to SGT mappings, the VLAN MUST have an SVI associated with it in order for the mapping
to be created. If an SVI does not exist, the IP Address of the device within the VLAN will not be mapped
to an SGT.
The Nexus 5500, as of this version of the CVD, supports port (interface) to SGT mapping as well as
manual IP to SGT mapping. For local SGACL enforcement on the Nexus 5500, port to SGT mapping
must be used as the intent of IP to SGT mapping is for SXP advertisement.
For the Nexus 1000V, the SGT can be assigned within the port profile definition and subsequently
advertised via SXP to a d Nexus 7000 for SGT imposition or SGACL enforcement. The use of the Nexus
1000V is considered out of scope for this release of the BYOD CVD, however additional information
can be found in Segmenting Clients and Servers in the Data Center at:
Note
The Nexus 5500 family of switches only support SXP speaker mode and not listener mode. As such, it
is not is not possible to advertise Nexus 1000V IP/SGT mappings to the 5500, therefore a Nexus 7000
must be used for this purpose.
Finally, it is also possible to define these SGT host mappings within ISE. These mappings are
subsequently pushed to all SGT-capable network devices authenticated within the TrustSec Domain. An
SGT-capable device by definition can impose and forward the SGT as well as enforce an SGACL. The
exceptions here are the ASA, as its Security Group policies are not dynamically obtained but locally
configured, and devices that are only SGT-Aware (only SXP supported). When defining IP/SGT
mappings at ISE one configuration detail must be noted as if not followed every device within the
TrustSec Domain would receive every server mapping configured at ISE. When defining Advanced
TrustSec Settings for network devices within ISE, a small check box for Include this device when
deploying Security Group Tagging Mapping Updates is by default selected as can be seen in
Figure 23-4. When selected, any IP/SGT Mappings defined at ISE will be pushed to that device. Hence
if plans call for SGT mappings to be created at ISE, as part of the configuration process discussed in
later sections, this box should be unchecked for all those network devices where the static ISE mappings
are undesirable.
23-10
Chapter 23

Figure 23-4
ISE SGT Mapping Update Configuration
Within the CVD, all static mappings are created at the Nexus 7000 Aggregation switches closest to the
server. In the CVD both IP/SGT mappings as well as VLAN to SGT mapping are defined. Note that
VLAN to SGT mapping is currently unavailable for the Nexus 5500.
In implementing TrustSec in a data center several strategies can be used to provide various zones for
policy enforcement or means by which servers can be mapped to the appropriate SGT value. It is beyond
the scope of this document to discuss these strategies in detail as they will vary from one organization
to the next based on server deployment (addressing/physical connectivity), data sensitivity and
role-based policies restricting access, Infosec policies, and switching platforms, whether physical or
virtualized, that are used.
The first step for implementation of TrustSec within the data center should be the creation of a matrix
defining whether access is permitted or denied.
One axis should define the various server roles based on application or database and the type of data
resident relative to security and role-based access restrictions.
The other axis defining the various user/device classifications such as Employee_Corporate,
Employee_Personal_PartialAccess, Contractor, etc.
Once completed it will then be possible to examine where servers presently reside in the data center and
how best to map the respective IP Addresses to SGT values. Depending on current security practices
within the data center, servers may already have been organized in security zones or pods with either
firewalls or ACLs already protecting them. Typically this organization will have been represented
through VLANs and IPv4 subnets associated with them.
When using the Nexus 7000 for direct server connectivity or as a means of aggregating other virtualized
or physical switching infrastructures, the recommended approach for creating IP to SGT bindings would
be to map a VLAN to an SGT value. By default then, all server traffic associated with that VLAN will
23-11
Chapter 23
be encapsulated with the defined SGT. If other servers reside in that VLAN with different access
restrictions, it is entirely possible to statically map the servers IP address to a different SGT value within
the VLAN, thereby overriding the global VLAN to SGT mapping and enabling enforcement to and from
the server not only from hosts external to the VLAN but even between servers within the VLAN.

As the implementation of TrustSec within the data center will most likely be through a migrational
approach, one possible method for implementing TrustSec would be to identify those servers that all user
roles have access to and assign them to a security group allowing open access. This might include
services such as DNS/DHCP, Active Directory, Cisco Identity Services Engine, etc.
The next group of servers to be associated with an SGT could be those servers accessible to users/devices
identified by a specific SGT that have only limited access to these intranet servers, applications,
databases, etc. In doing so, the appropriate SGACLs can be established permitting access to these
servers. By doing this, it then follows that all remaining servers can be assigned an SGT either through
static mapping or assignment to a VLAN which is mapped to the appropriate SGT.
It is strongly recommended that a plan be developed to stage the migration to the use of TrustSec for
policy enforcement in an orderly fashion by first assigning all servers an SGT using VLAN to SGT or
static IP to SGT mapping prior to enabling the Campus Access. This CVD assumes that all servers have
been assigned an SGT prior to enabling TrustSec. Recognizing however that every organization will have
different requirements, it may be necessary to begin implementation of TrustSec for policy enforcement
within at network access at the same time as data center resources. As previously discussed this will
likely be through the use of 802.1X for both wired and wireless access although other methods do exist
in Catalyst switching platforms such as VLAN to SGT mapping, Layer 3 Interface to SGT mapping, etc.
As part of this migration process, TrustSec should be enabled in the campus and data center aggregation
and switching infrastructure prior to enabling the access switches supporting TrustSec.
As areas of the network are migrated to the use of Security Group Tags and propagation of same, the
appropriate SGACLs will be defined through creation of TrustSec policies at ISE discussed later in the
CVD. It is assumed that during this migration period there will be traffic from users and devices that
have not been associated with a tag and as this traffic enters the TrustSec Domain at the campus
aggregation or distribution layer switches where TrustSec and SGT propagation is enabled, the Ethernet
frames will be encapsulated with a CMD header containing an SGT value of 00 or unknown. As this
traffic traverses the Catalyst switching infrastructure, it will be propagated over the CTS links as SGT:00
until it enters the first Nexus switch. The Nexus switches behave differently and based on the interface
configuration for TrustSec, the Nexus will remark the SGT:00 value to one specified on the ingress
interface. This is discussed in much greater detail in TrustSec Link Policy. For purpose of discussion
here, the SGT value used for the Nexus links in the CVD will be 80.
In order to ensure access to data center resources, a TrustSec policy permitting access from SGT:80 will
be required for server access. As there will be traffic both from employee devices with full access and
other restricted traffic with only partial access being remarked to SGT:80 during the migration period,
there will obviously be no way to enforce a policy restricting or denying access on a per user basis and
so SGT:80 will need access to all servers with specific access restricted by other means, such as ACLs,
firewall rules at the edge of the TrustSec Domain, etc.
The task of assigning an SGT to every data center asset will likely prove daunting when first migrating
to the use of Security Group Tags. In the scenario where SGACLs will be used to enforce policy, the
SGACL is defined by permitting or denying access between a specific source and destination SGT and
IP Addresses are not used within these policies. Although the following configuration is not discussed
in this CVD, a concept that can be exploited when granting access to servers in the data center is that of
the SGT value of zero or unknown as it is referred to.
23-12
Chapter 23

If the IP Address of a server or the VLAN in which it resides has not been mapped to an SGT at the point
of enforcement, such as the Nexus 7000 in the data center, that server would be considered unknown and
associated with SGT:00. Unlike ACLs with an implicit deny at the end, SGACLs when implemented on
a switching platform have an implicit permit to unknown or permit all; this is not true on the ASA or
IOS ZBFW acting as a SG-FW where an implicit deny is still maintained. Hence on a switch, if there is
not a specific tag value assigned to a server, the destination is considered Unknown (SGT:00) and as long
as an SGACL denying a specific source SGT to SGT:00 or unknown, the packet is forwarded.
The use of SGT:00, if used cautiously, provides a possible migrational approach to tag assignment in the
data center. By assigning an SGT to all data center resources requiring open access such as DHCP/DNS
as well as those servers that can be accessed by users with only restricted access privileges, a SGACL
can be created granting server access for those restricted users, while denying access to servers that have
yet to be mapped, thus represented by SGT00 or the unknown tag.
The following example depicts one possible use of the unknown tag in a BYOD setting where personal
or contractor assets are permitted on the network and only partial access to data center resources is
permitted through the use of SGACLs on the switching infrastructure. Throughout the campus
infrastructure the default policy permitting any SGT to unknown is left unaltered. However at the
Nexus 7000 Data Center Aggregation switches where policies based on SGACLs are enforced, an
explicit SGACL denying access between a specific source SGT to unknown (SGT:00) can be created.
A policy defining permissions for SGT00 whether as source or destination that is explicitly (manually)
configured on a Nexus 7000 will take precedence over the default policy that implicitly permits traffic
to or from unknown. The following commands configure the SGACL locally on the Nexus 7000 Data
Center Aggregation switches:
cts role-based access-list block12toUnk/Creates an SGACL "block12Unk"
deny ip/Action performed by SGACL "block12Unk"
cts role-based sgt 12 dgt 0 access-list block12toUnk/Manually configure mapping of Cisco
TrustSec Security Group Tags (SGTs) to a security group access control list (SGACL).
Defines source SGT12 to destination SGT0 (Unknown)
To verify the role-based access policy at the Nexus 7000, issue the command sh cts role-based policy.
The following is an excerpt of the entire output showing the previously denied SGACL.
ua33-n7k-1-agg# sh cts role-based policy
sgt:10
dgt:unknown
rbacl:Permit IP
permit ip
sgt:11
dgt:unknown
rbacl:Permit IP
permit ip
sgt:12
dgt:unknown
rbacl:block12toUnk
deny ip
sgt:any
dgt:any rbacl:Permit IP
permit ip
To carry this example further, users and devices with only partial access to the data center are assigned
SGT:12. Within the data center, those servers that SGT12 will have access to are assigned an SGT value
40. Servers that these users should not be able to access have been assigned SGT 50. In doing so we
enforce three policies regarding server access for the SGT12 users:
Permit SGT12 to SGT40
Deny SGT12 to SGT50
Deny SGT12 to Unknown
23-13
Chapter 23
Whats New in This CVD
For users or devices that have full access to data center resources and are assigned a different SGT, the
default, implicit permit to Unknown is left in place and any other SGT-based restrictions can be enforced
as required. An example might be in the case of a web server and its corresponding database where a
corporate device can access the web server but only the web server and DB Admins can access the
database.
When using an ASA firewall to protect data center resources additional flexibility in policy definition is
possible as either a source or destination SGT can be used with a destination or source IP Address in the
ACE. This now allows one to create policies where a tag assigned to users/devices with partial access
can be granted or denied to specific SGTs and or IP Addresses. When using an SG-FW to enforce policy,
an ACE can be defined denying a source SGT access to Unknown as well.
Prior to implementation of a Security Group Access architecture, many organizations may have already
designed their data centers in such a way as to protect those resources by placing them behind a firewall.
Others may simply elect to secure them through the use of access control lists where only specific access
has been granted while general access from all other sources is denied. Both approaches are
demonstrated within this CVD through two separate scenarios where:
Campus Wireless BYOD users and devices have role-based access through the use of Security
Group Access Control Lists (SGACLs) in one scenario.
The Security Group Firewall (SG-FW) capability found in the ASA in the other scenario.
It should be pointed out that these two approaches, SGACLs and SG-FW, are not mutually exclusive and
may be used together.
As previously discussed, it is beyond the scope of this CVD to provide a detailed approach to developing
a migration strategy for the implementation of Security Group Tags in the data center as well as
providing architectural guidance for building secure, containerized data centers. Due to the diverse ways
companies, organizations, educational institutions, and governments have built their networks and data
centers and the underlying security architectures to protect them, it is impractical to define the various
ways TrustSec could be deployed. The only intent of the examples given above is to suggest ways this
may be accomplished. For additional information on these topics, refer to the data center document
repository in Design Zone on Cisco.com at:
http://www.cisco.com/en/US/netsol/ns743/networking_solutions_program_home.html as well as the
TrustSec document repository at:

In this Enterprise Mobility BYOD CVD, Security Group Tags are used as a means to enforce role-based
access policies for Campus wireless users as in the previous version of this CVD. New to this CVD
however is the introduction of the CT-5760 wireless controller as well as the Catalyst 3850 for campus
wireless access and the ability to natively tag traffic accessing the network through these devices. Two
specific infrastructure deployment scenarios are examined within this CVD. The first use case makes use
of TrustSec Policy defined at the Identity Services Engine and the resulting SGACLs being dynamically
exchanged with the Catalyst 6500 and 3850 switches, the CT-5760 wireless controller, and the Nexus
7000 infrastructure. The second use case once again makes use of the TrustSec Policy defined at the
Identity Services Engine, but policy is enforced through the configuration of Security Group Firewall
(SG-FW) policies defined on an ASA providing secure access to data center resources.
The wireless access design using the CT-5508 wireless controller previously validated in the previous
CVD will continue to be used to support access to data center resources by wireless devices using the
CT-5508 instead of the CT-5760, identical to that demonstrated the previous CVD.
23-14
Chapter 23

Description
This BYOD CVD only discusses Security Group Access in conjunction with campus wireless access;
wired access is completely out of scope. The following new capabilities are validated compared to
previous versions of this CVD:
SGT assignment and forwarding for wireless devices connecting via the Catalyst 3850 Converged
Access switch enabled via Darya IOS-XE release.
SGT assignment and forwarding for wireless devices connecting via the CT-5760 wireless controller
enabled via Darya IOS-XE release.
Nexus 7000 support for VLAN to SGT mapping found in Freetown NX-OS 6.2.
The previous BYOD CVD required that Shared Services, Core, Data Center Core, and Data Center
Aggregation all be configured to support SGT forwarding using CTS Manual Mode and MACsec link
encryption. This BYOD CVD requires the addition of the Catalyst 6500 VSS Distribution Layer to
provide connectivity for the Catalyst 3850 Converged Access switches terminating campus wireless
devices in the access layer. As with 2.5 the 10Gb Ethernet links configured for Security Group Tag
propagation on the Calayst 6500 and 3850 switches will make use of CTS Manual Mode. Although the
link between the Catalyst 6500 switches uses MACsec for link encryption, the C3850 10Gb uplink to
the distribution C6500 does not utilize MACsec encryption as although the hardware is capable, software
support will not be available until a future release of IOS-XE for the Catalyst 3850.
In this CVD as previously discussed, the CT-5760 is added to the design along with the CT-5508 for the
centralized CUWN design for the campus. As with the CT-5508, the CT-5760 is connected to the Shared
Services Catalyst 6500 VSS switch. The key difference is that the link from the CT-5760 to the 6500
Shared Services is 10G Ethernet supporting SGT forwarding. As with the C3850, this link is configured
for CTS Manual Mode without MACsec link encryption for the same reasons. As traffic egressing the
CT-5760 can now be tagged appropriately, the requirement for SXP can be eliminated in the SGACL
deployment, but is still required for the second model using the ASA and SG-FW in the data center due
to lack of tagging support on the ASA. The requirement for SXP when deploying the CT-5508 remains
as in the previous CVD and is included in the following sections of this document.
Network Topology Diagram

The BYOD topology is illustrated in Figure 23-5.
23-15
Chapter 23
Figure 23-5
BYOD Topology Diagram

Data Center
Services
Campus Wireless
CAPWAP
3700 AP (802.11ac/n)
CAPWAP
CT5760
ISE
Catalyst
3750X
3600 AP (802.11ac/n)
CAPWAP
CT5508
RSA
CA
2600 & 1600 APs (802.11n)
Core
DNS and
DHCP
Applications and
File Servers
CAPWAP
Distribution
Switch
AD
Catalyst 3850
Switch Stack
CAPWAP
2600 & 1600 APs (802.11n)
Internet
Edge
WAN Edge
Branch
FlexConnect
Branch Design
CAPWAP
3700 AP (802.11ac/n)
CAPWAP
HA pairs of CT5508
Guest WLCs
Catalyst
3750X
3600 AP (802.11ac/n)
CAPWAP
WAN
ASA
MPLS
GETVPN
SGT
Capable
Catalyst
3850
2600 & 1600 APs (802.11n)

CAPWAP
Off-Prem
On-Prem
MDM
SGT
Capable
MDM
Converged Access
Branch Design
Cloud-Based MDM
CAPWAP
3600 AP Module (802.11ac/n)
294950
Internet
DMVPN
MDM
The key items to note in Figure 23-5 include:
At a campus location the wireless design can be deployed either by using Centralized Wireless
Architecture, which can be implemented by either using 5508 WLC or 5760 WLC, or by using
Converged access switches 3850 switches. This design supports combination of both architectures.
The core infrastructure at the campus remains the same as the previous CVD design.
The Campus Wireless Design depicted in the previous CVD is still relevant in this design. This
design shows the additional capabilities of 5760 WLC.
As in the pervious BYOD CVD, two different scenarios are depicted for TrustSec policy enforcement.
The next two sections describe the details of each policy enforcement mechanism.
Terminology
There are several terms that that will be used throughout this document:
Tagging pointsThese are different places in the Campus where the traffic is initally tagged. As
shown in Figure 23-6, the points with this icon:
23-16
Chapter 23

are the devices that tag the traffic. Within the campus, the 5760 WLC for centralized wireless access
design and 3850 for the converged access design are the places where the traffic is initally tagged.
Also, as the CT-5508 is unable to tag traffic, mappings that are learned are advertised to the Catalyst
6500 VSS in Shared Services where the traffic is then tagged. Finally within the data center, the
Nexus 7000 Aggregation switch is responsible for tagging traffic.
Figure 23-6 shows the points where the tags are initially generated.
Figure 23-6
Points Where Tags are Generated
Data Center
Services
Campus Wireless
CAPWAP
3700 AP (802.11ac/n)
CAPWAP
CT5508
WLCs
ISE
SGT
Capable
SGT
Capable
Catalyst
3750X
SGT
Capable
3600 AP (802.11ac/n)
CAPWAP
RSA
CT5760 WLCs
CA
2600 & 1600 APs (802.11n)

SGT
Capable
Core
Applications and
File Servers
CAPWAP
Distribution
Switch
AD
SGT-capable
Non-SGT-links
CAPWAP
SXP
DNS and
DHCP
Catalyst 3850
Switch Stack
SGT
Capable
CAPWAP
2600 & 1600 APs (802.11n)
Internet
Edge
WAN Edge
FlexConnect
Branch Design
Branch
CAPWAP
3700 AP (802.11ac/n)
HA pairs of CT5508
Guest WLCs
CAPWAP
DOT1Q
Catalyst
3750X
3600 AP (802.11ac/n)
CAPWAP
WAN
ASA
MPLS
GETVPN
Catalyst
3850
2600 & 1600 APs (802.11n)

CAPWAP
Off-Prem
On-Prem
MDM
MDM
Cloud-Based MDM
Converged Access
Branch Design
CAPWAP
294951
Internet
DMVPN
MDM
SGT capable linksThese are the links that receive the frames with SGT on the ingress and impose
the tags on the egress. In Figure 23-6, all the links that are marked Green are SGT capable links.
EAST-WEST Traffic enforcementThis is a term that basically describes that enforcement

occuring between access devices/users within the same network at Layer 2 or Layer 3.
North-South TrafficThis is the traditional approach for policy enforcement. Servers that have data
reside in the data center, which is described as North of the devices in the network. Access
policies/restrictions from the campus access layer, whether wired or wireless, are typically enforced
23-17
Chapter 23
at security appliances or infrastructure near to or at which the servers are attached. The next two
sections discusses two distinct scenarios that will be used to enforce this North-South traffic in this
CVD.
In the previous version of the CVD, Deployment Scenario 1 focused completely on restricting access to
data center resources based on Security Group membership of campus-based wireless devices accessing
the network through a CT-5508 wireless controller. This is now expanded to include devices accessing
the network through the Catalyst 3850 and CT-5760. The details of how to configure this policy
enforcement are shown in the following sections.
Deployment Scenario 1 Components:
CT5760; IOS-XE 3.3
CT5508; CUWN 7.6
Catalyst 6500
SUP2-T; 15.1.1-SY1
WS-X6904 Linecard with 10GE Modules (FourX Adapter)
C3850 Converged Access Switches; IOS-XE 3.3
Nexus 7000
SUP2; 6.2(6)
M1 Linecards; N7K-M108X2-12L
F2e Linecard; N7K-F248XP-25E ( only last 8 ports supporting MACsec )
Nexus 5548
ISE 1.2 with Patch 5 installed
Figure 23-7 depicts the infrastructure that is used for purposes of TrustSec validation in this CVD.
23-18

Figure 23-7
TrustSec Infrastructure in this BYOD CVD
Services
Data Center
DNS
DHCP
Nexus
7000 VPC
DC Core
CT5508
WLCs
Nexus
5000 VPC
DC Agg
CT5760
WLCs
Core
Cisco
ASA
Distribution
Switch
Catalyst
3750-X
CA
AD
Application and
File Servers

Catalyst 3850
Switch Stack
3600 AP Module
3600 AP Module
(802.11ac/n)
(802.11ac/n)
CAPWAP
CAPWAP
294945
Chapter 23
In Figure 23-7 the links extending between the Catalyst 6500 VSS in Shared Services to the Catalyst
6500 VSS in the core and extending to the Nexus 7000 are 10GE links. On the Catalyst 6500s,
WS-X6904 linecards with the FourX Adapters provide the 10GE interfaces while the N7K-M108X2-12L
and N7K-F248XP-25E linecards provide the Nexus 7000 interfaces. The links between the Nexus 7000
and the Nexus 5548 are likewise connected to N7K-M108X2-12L linecards at the Nexus 7000 and 10GE
ports on the Nexus 5548. All other network connectivity for wireless controllers, ASA firewalls, ISE,
and the miscellaneous servers depicted are 1GE links.
23-19
Chapter 23
Figure 23-8
Infrastructure Deployment Scenario 1 SGT Enforcement
Services
Data Center
Nexus
7000 VPC
DNS
DHCP
CA
AD
Nexus
5000 VPC
STOP
STOP
DC Core
CT5508
WLCs
DC Agg
CT5760
WLCs
Core
Cisco
ASA
Distribution
Switch
Catalyst
3750-X
Application and
File Servers

Catalyst 3850
Switch Stack
294952
3600 AP Module
3600 AP Module
(802.11ac/n)
(802.11ac/n)
CAPWAP
CAPWAP
In this first scenario, wireless users, upon successful authentication and authorization, will be associated
with a specific role and an IP to SGT mapping will be created on the wireless controller with the devices
IP Address and the appropriate SGT. In Deployment Scenario 1, wireless device traffic will have the
SGT inserted at different networking devices and this insertion point is dependent on which wireless
controller the device is terminating at for network access.
Table 23-1 summarizes where the SGT will be inserted.
Table 23-1
SGT Insertion
Explanation
Converged
3850 Switch support inline tagging

capability
3850
23-20
3850 switches
Chapter 23

Table 23-1
SGT Insertion
Explanation
Centralized
5760
5760 wireless controller 5760 wireless controller supports inline

tagging capability
Centralized
5508
6500 Shared Services
5508 does not support in-line tagging.

Therefore SXP is used between 5508 and
6500. Tags imposed at 6500.
In Deployment Scenario 1, CUWN traffic with Security Group Tags will be forwarded from the Shared
Services Catalyst 6500 VSS, where the wireless controllers are attached, or from the 3850 converged
access switches connected to the Catalyst 6500 Distribution switch. These tags are then propagated
through the Core of the BYOD infrastructure en route to servers located in the data center. In
Figure 23-8, the links depicted in blue will be configured for SGT forwarding as well as manually
configured for 802.1ae MACsec encryption where available.
Note
As of IOS-XE 3.3.0, the Catalyst 3850 and CT-5760 wireless controller will impose and propagate the
SGT as well as enforce SGACLs. Although these platforms have the necessary ASICs for MACsec
support, the software has yet to be enabled as of the writing of this CVD. These links are green dashes
As this traffic traverses the SGT-capable Core, this tag will be propagated hop-by-hop en route to the
Nexus 7000s that compose the data center switching infrastructure within which the various servers are
located. As shown in the Figure 23-8, a wireless user accessing the network using centralized wireless
architecture is assigned a tag value of 12 after successful authentication and authorization; similarly, a
wireless user accessing the network using a converged access medium is assigned a tag value of 10.
As 802.1X is not used to authenticate the servers residing in the Nexus data center infrastructure, the
server IP Address to SGT mapping can either be manually defined on the Nexus 7000 Data Center
Aggregation switch or at the ISE server, which would subsequently push that mapping to the Nexus
7000. For purposes of the CVD, specific IP/SGT mappings have been manually defined on the Nexus
7000 data center Aggregation Switches as well as the use of VLAN to SGT mapping.
As tagged user traffic arrives at the Nexus 7000 data center switch where the manual SGT mappings for
the servers have been created, the traffic will be matched against TrustSec Policy (SGACL) defined
either centrally at ISE or locally and will be either forwarded or dropped as applicable. For example, as
shown in Figure 23-8, the traffic with SGT 10 arriving from converged access wireless user with full
access is permitted by the Nexus aggregation switch and the traffic with SGT12 from a CUWN wireless
user who has partial access is denied access to the servers.
As discussed earlier, all SGT mappings for the servers have been manually created on the Nexus 7000
aggregation switches. As the servers are connected to the Nexus 5548 switches depicted in Figure 23-8,
traffic from the Nexus 5548s egresses untagged as no mappings have been created there. Once this traffic
passes through the Nexus 7000 Aggregation switch, the resident SGT mappings will be examined and
the appropriate SGT imposed upon egress from the aggregation switch. The SGT mappings can be
implemented on Nexus 7000 via IP/SGT mapping or by VLAN/SGT mapping. The details for this
configuration are covered later in this document. In the event that traffic would be initiated by a server
associated with an SGT in the data center, the tagged traffic would then leave the Nexus 7000 data center
switches traversing the Catalyst 6500 Core and Shared Service infrastructure enroute to the destination.
The SGT is propagated at each hop towards the destination, whether that be the wireless controllers
attached to the Shared Services 6500 or wireless devices accessing the network through the Catalyst
3850s.
23-21
Chapter 23
If destined for CUWN wireless controllers, upon arrival at the Shared Services 6500, the traffic will be
matched against local TrustSec Policy (SGACL) and will be either forwarded or dropped depending on
the controller to which it is destined. If destined for the CT-5508, SGACL policies will be enforced at
the Shared Services C6500 VSS as the CT-5508 does not support tagging or SGACLs and only advertises
the IP/SGT mappings to the Shared Services C6500 VSS for enforcement. If destined for the CT-5760
with its support for SGT tagging and SGACLs, the IP/SGT mappings for those devices accessing the
network at the CT-5760 will be created and stored at the 5760 and hence the SGACL enforced there as
well.
If destined for the Catalyst 3850 and the converged access wireless users, the SGACL policy will be
enforced on the Catalyst 3850 to which the wireless user is associated.
Figure 23-9 depicts where SGACLs will be enforced in the Unified Access infrastructure.
Figure 23-9
Policy Enforcement in Deployment Scenario 1
Services
Data Center
DNS
DHCP
12
Nexus
7000 VPC
STOP
Nexus
5000 VPC
STOP
STOP
12
CT5508
WLCs
CA
AD
DC Core
DC Agg
CT5760
WLCs
50
Core
Application and
File Servers

SXP Tunnel
CAPWAP Tunnel
Distribution
Switch
Catalyst
3750-X
Catalyst 3850
Switch Stack
STOP
3600 AP Module
3600 AP Module
(802.11ac/n)
(802.11ac/n)
CAPWAP
CAPWAP
23-22
294953
CAPWAP
10
Chapter 23

In this Enterprise Mobility BYOD CVD, Deployment Scenario 2 focuses on the use of ASA firewalls as
a Security Group Firewall (SG-FW) separating access between Nexus 7000 Core and Aggregation layers
enforcing rules created using a combination of Security Group Tags and IP Addresses as source and
destination. These rules can contain ACEs constructed solely with source and destination SGT or
combined with an IP address as source or destination. In Deployment Scenario 2 the policy enforcement
is executed by firewall rules instead of SGACL s defined in the campus infrastructure or the Nexus
Aggregation switches. Additionally, these firewall rules must be configured locally on the ASA as
opposed to the creation of switch SGACLs created and pushed from within the Cisco Identity Services
Engine.
Wireless Deployment Scenario 2 Components:
CT5760; IOS-XE 3.3
CT5508; CUWN 7.6
Catalyst 6500
SUP2-T; 15.1.1-SY1
WS-X6904 Linecard with 10GE Modules (FourX Adapter)
C3850 Converged Access Switches; IOS-XE 3.3
Nexus 7000
SUP2; 6.2(6)
F2e Linecards; N7K-F248XP-25E ( only last 8 ports supporting MACsec )
Nexus 5548
ASA Firewall, 9.0.2
ISE 1.2 with Patch 5 installed
In the previous BYOD CVD, the CT-5508 was used for all CUWN termination, whereas in this version
of the CVD wireless termination as previously discussed will be expanded to include wireless device
termination centrally at the CT-5760 wireless controller and through converged access design using the
Catalyst 3850 switch. As the ASA Firewall does not support native SGT tagging, SXP will be once again
be used to advertise both campus and data center IP/SGT mappings to the ASA for subsequent policy
enforcement to and from data center resources.
It should be noted that although Scenario 1 and Scenario 2 are dissimilar in how Security Group Tags
are propagated within the network and policies enforced, these two design scenarios are not mutually
exclusive and may be combined. For purposes of this CVD however, Scenario 2 assumes the use of the
ASA SG-FW as the sole means of policy enforcement and SXP as the sole means of advertising IP/SGT
mappings in lieu of SGT propagation configured on the various infrastructure interfaces.
Figure 23-10 depicts the network topology.
23-23
Chapter 23
Figure 23-10
TrustSec Deployment Scenario 2
Data Center
Services
Campus Wireless
CAPWAP
3700 AP (802.11ac/n)
CAPWAP
ISE
SGT
Capable
CT5508
WLCs
Catalyst
3750X
3600 AP (802.11ac/n)
CAPWAP
RSA
CT5760 WLCs
CA
2600 & 1600 APs (802.11n)

SGT
Capable
Core
CAPWAP
AD
Applications and
File Servers
CAPWAP
SXP
DNS and
DHCP
Catalyst 3850
Switch Stack
CAPWAP
2600 & 1600 APs (802.11n)
Internet
Edge
WAN Edge
FlexConnect
Branch Design
Branch
CAPWAP
3700 AP (802.11ac/n)
HA pairs of CT5508
Guest WLCs
CAPWAP
DOT1Q
Catalyst
3750X
3600 AP (802.11ac/n)
CAPWAP
WAN
ASA
MPLS
GETVPN
Catalyst
3850
2600 & 1600 APs (802.11n)

CAPWAP
Off-Prem
On-Prem
MDM
MDM
Converged Access
Branch Design
Cloud-Based MDM
CAPWAP
294954
Internet
DMVPN
MDM
The key items to note in Figure 23-10 include:
The key differences in Scenario 2 as compared to Scenario 1 are:

Tag information is sent mainly by SXP tunnels and there are no CTS enabled links in the Core
part of the network.

ASA, which is the policy enforcer, obtains the information about source and destination tags
through a SXP tunnel from a single Nexus data center switch. This is done to prevent ASA from
maintaining several different SXP tunnels from different peers.
The distribution switch in the campus location initiates a SXP tunnel to the Nexus data center
aggregation switch and communicates the information about the tags that it has obtained through
SXP peering from the Catalyst 3850 access switches.
Shared Services and Distribution Catalyst 6500 VSS switches have SXP tunnels to dual Nexus 7000
aggregation switches and then from those Nexus switches to the ASA.
With Deployment Scenario 2, an alternate means other than SGACLs will be used to enforce TrustSec
policy. In Scenario 2 an ASA running version 9.0(2) will be used as a Security Group Firewall (SG-FW)
securing data center resources from outside access. Unlike Scenario 1, the 10GE infrastructure between
the Shared Services Catalyst 6500 VSS and the data center does not need to be enabled to support
Security Group Tag forwarding or SGACLs. As the ASA does not presently support native SGT tagging
on its Ethernet interfaces, Security Group Tag Exchange Protocol (SXP) must be used for it to learn
23-24
Chapter 23

IP/SGT mappings from other areas of the network where they have been dynamically learned or
statically configured. It is by virtue of these SXP advertisements that the ASA is capable of inspecting
the untagged traffic and, through the use of these IP/SGT mappings, that SG-FW policies are enforced.
As in the case of the first deployment scenario, wireless users, upon successful authentication and
authorization, will be associated with a specific role and an IP to SGT Binding will be created on the
wireless controller with the devices IP Address and the appropriate SGT.
Once the IP/SGT mappings have been created upon wireless device access to the respective controller,
SXP will be used as the primary method through which these mappings are communicated to the ASA
firewall. As depicted in Figure 23-10, the 3850 converged access switches, and both the CT-5760 and
CT-5508 wireless controllers, must communicate their respective IP/SGT mappings to the ASA Firewall.
In this design we have chosen the following method to optimize the number of SXP tunnels needed to
the ASA Firewall:
The CT-5760 and CT-5508 wireless controllers have an SXP peering to the Shared Services C6500
VSS, which also has an SXP peering to each of the Nexus 7000 data center aggregation switches.
Access layer Catalyst 3850 switches establish an SXP tunnel to the C6500 VSS campus distribution
switch, which then establishes a tunnel to each of the Nexus 7000 data center aggregation switches.
The primary advantage in this approach is to aggregate what may be hundreds of Catalyst 3850s
peering at the respective campus distribution switch(es) and then creating a single SXP peering to
the data center.
All SXP tunnels from the Campus infrastructure are aggregated at each of the Nexus 7000 data
center aggregation switches.
The IP/SGT mapping information is aggregated and sent by each of the Nexus 7000 aggregation
switches to the HA primary ASA Firewall, including all of the server mappings created through
static IP/SGT mappings or VLAN/SGT mappings at the Nexus switches. By doing this, the ASA
does not have to maintain numerous SXP peerings to different devices.
Table 23-2 summarizes the SXP peering that will be used in the CVD.
Table 23-2
SXP Peering
Device
Role
Intfc
Dst Device
Role
Intfc
CT-5760
Speaker
Lo0
Listener
Lo0
CT-5508
Speaker
NA
Listener
Lo0
Lo0
N7K-Agg-1
Listener
Lo0
Lo0
N7K-Agg-2
Listener
Lo0
Speaker
Lo0
Listener
Lo0
Lo0
N7K-Agg-1
Listener
Lo0
Lo0
N7K-Agg-2
Listener
Lo0
N7K-Agg-1
Speaker
Lo0
Out
N7K-Agg-2
Speaker
Lo0
Out
As previously discussed, the ASA firewall that will be used to enforce SG-FW policies must be manually
configured with SGT policies as dynamic updates via ISE is presently not supported in the ASA. The
details regarding these SG-FW policies are discussed later.
As wireless traffic egresses the Shared Services Catalyst 6500 VSSs en route to the data center, the traffic
will be untagged and will simply be propagated through the Core, enter the data center switching
infrastructure, and ultimately arrive at the ASA firewall where the appropriate SG-FW policy will be
23-25
Chapter 23
enforced. As shown in Figure 23-11, all traffic going from the user to the server passes through the ASA
firewall.
In the unlikely event that any traffic would be sourced from a server in the data center, it would likewise
egress the Nexus 7000 aggregation switch untagged and be forwarded to the ASA firewall where any
applicable SG-FW policy will be enforced.
Figure 23-11 depicts the infrastructure used in Deployment Scenario 2 and the means by which security
group policies will be enforced.
Figure 23-11
Deployment Scenario 2 and Security Group Policy Enforcement
Services
Data Center
DNS
DHCP
Nexus
7000 VPC
DC Core
CT5508
WLCs
CA
AD
Nexus
5000 VPC
DC Agg
CT5760
WLCs
Core
Cisco
ASA
Distribution
Switch
Catalyst
3750-X
Application and
File Servers

SXP Tunnel
Catalyst 3850
Switch Stack
23-26
294955
3600 AP Module
3600 AP Module
(802.11ac/n)
(802.11ac/n)
CAPWAP
CAPWAP
Chapter 23

Common Infrastructure for Both Scenarios

As explained in the overview section, there are several components that have to be configured to ensure
that the appropriate SGT is assigned to the user, the SGT is propagated in the network or an IP/SGT
mapping is advertised, and policy is enforced.
The following tasks are common to both of the deployment scenarios depicted in this CVD and hence
are discussed prior to addressing the specific tasks required for each of the two deployment scenarios.
Regardless of the deployment scenario, these tasks as outlined in the following sub-sections should be
completed prior to proceeding to those sections discussing specific deployment scenarios:
1.
Configuring ISE to support Security Group Access.
2.
Configuring ISE for network access device authentication.
3.
Configuring the network devices for integration with ISE.
4.
Configuring the network devices with a device SGT.
5.
Configuring static IP/SGT and VLAN/SGT mappings on Nexus data center aggregation switches for
servers.
Configuring ISE to Support TrustSec

For Cisco ISE to function as a TrustSec server and provide TrustSec services, you must define the
following global TrustSec settings. The first step is to define ISE as a TrustSec AAA server as depicted
in Figure 23-12.
1.
Go to Administration > Network Resources > SGA AAA servers and click Add.
2.
Enter the host name of the Identity Services Engine server or Policy Service Node if ISE Roles have
been distributed among dedicated servers.
3.
Enter the IP Address of the ISE server.
4.
Enter the UDP Port number for RADIUS authentication and click Save.
Figure 23-12
ISE TrustSec Server AAA Definition
The next step to be completed is to configure TrustSec Server Protected Access Credential (PAC)
Time-to-Live settings and SGT reservations.
23-27
Chapter 23
The tunnel PAC generates a tunnel for the EAP-FAST protocol and is used for Secure RADIUS
communications with Network Devices for TrustSec environmental data. A new PAC is generated if the
network device re-authenticates for any reason or when the TTL expires.
By default Security Group Tags are dynamically assigned a decimal/hex value in ascending order by ISE.
It is possible to change this behavior such that all tags must be manually defined or to reserve a range
that can be specifically allocated to users, devices, or servers. In the CVD, all tags will be manually
defined as depicted in Figure 23-13.
To complete this step:
1.
Access the Identity Services Engine and follow the path Administration > System > Settings >
Security Group Access.
2.
Configure the Tunnel PAC Time to Live.
3.
Configure the Proactive PAC update time if desired. In Figure 23-13, the PAC will be renegotiated
after 10% of TTL or nine days.
4.
By default the system will automatically assign SGT values. If you wish to reserve a range that can
be specifically allocated to users, devices, or servers, select the check box next to Reserve a range
From and specify the Tag values. In the CVD, all tags will be manually assigned as shown below.
5.
Save the settings.
Figure 23-13
TrustSec Servers Settings in ISE
The next step is to define Security Group Tag names and associate them with a numerical value at the
Identity Services Engine. The SGT names are periodically pushed to the Network Access Device (NAD)
through periodic updates or upon that network devices authentication (NDAC Authentication) with ISE.
They may also be manually pushed as well.
To complete this step as depicted in Figure 23-14:
1.
Go to Policy > Policy Elements > Results >Security Group Access > Security Groups.
2.
Click Add.
3.
Define the SGT Name and add an optional description.
4.
Click the radio button next to Select value from reserved range
5.
Enter the desired SGT value from the range defined in the previous step.
23-28
Chapter 23

Figure 23-14
Security Group Creation
In this CVD, Table 23-3 shows the SGT Names and corresponding Tag Values used.
Table 23-3
SGT Names and Tag Values
SGT Value SGT Name
Description
SGT5_TrustSec_NAD
This is used For TrustSec Network Devices And For Trust

State.
10
SGT10_Campus Corp
Corporate device with full access to the network.
11
Personal device with full access to the network
12
Personal device with restricted access to some resources

on the network.
40
Servers_Services_OpenAccess Servers in data center accessible by all devices.
50
Servers_Corporate
Corporate Servers that only Corporate devices or

approved personal devices have access to.
80
SGT80_Interface
Reserved for us with the <policy static trusted> command

on TrustSec-capable interfaces.
Unknown
System defined/reserved representing a device (IP

Address) not associated with a SGT.
These values will be defined in ISE as can be seen in Figure 23-15.
23-29
Chapter 23
Figure 23-15
Security Groups Used in CVD
Configuring ISE for Network Access Device Authentication

The next configuration task is to define the Network Devices that will be enforcing TrustSec Egress
Policies in ISE and create the necessary AAA configuration on the devices. This is done to create a
secure tunnel for EAP-FAST authentication of the device such that TrustSec environment data such as
SG Names and associated SGT as well as TrustSec Egress Policies or SGACLs can be exchanged
periodically. As discussed in TrustSec Using 802.1X for Link Encryption, this process is known as
Network Device Admission Control or NDAC. As 802.1X will not be used to authenticate network
devices across a link in order to build a trust relationship for SGT forwarding as well as MACsec
encryption, it is only necessary to define those devices enforcing SGT policy, as well as those wireless
controllers serving as an 802.1X Authenticator to Supplicants on wireless devices attempting to Access
the network. Therefore to support Deployment Scenario 1 it will be necessary to create definitions for
minimally six devices and Deployment Scenario 2 will require a seventh device, the ASA Firewall HA
Primary, based on the infrastructure depicted in Figure 23-16.
23-30
Chapter 23

Figure 23-16
Network Devices to be Defined in ISE

Data Center
Services
Campus Wireless
3700 AP (802.11ac/n)
CAPWAP
5
CT5508
WLCs
CAPWAP
ISE
Catalyst
3750X
3600 AP (802.11ac/n)
CAPWAP
CA
CT5760 WLCs
2600 & 1600 APs (802.11n)
7
Core
DNS and
DHCP
CAPWAP
Catalyst 3850
Switch Stack
CAPWAP
2600 & 1600 APs (802.11n)
Internet
Edge
WAN Edge
FlexConnect
Branch Design
Branch
CAPWAP
3700 AP (802.11ac/n)
HA pairs of CT5508
Guest WLCs
CAPWAP
DOT1Q
Catalyst
3750X
3600 AP (802.11ac/n)
CAPWAP
WAN
ASA
MPLS
GETVPN
Catalyst
3850
2600 & 1600 APs (802.11n)

CAPWAP
Off-Prem
On-Prem
MDM
MDM
Cloud-Based MDM
Converged Access
Branch Design
CAPWAP
294959
Internet
DMVPN
MDM
Refering to Figure 23-16, these devices are:

1.
CT5760 Wireless Controller (required for 802.1X wireless device access and TrustSec policy
enforcement)
2.
CT5508 Wireless LAN Controller (required for 802.1X wireless device access)
3.
Catalyst 6500 VSS Shared Services Switch (TrustSec policy enforcement)
4.
Data Center Nexus 7000 Aggregation Switch #1 (TrustSec policy enforcement)
5.
Data Center Nexus 7000 Aggregation Switch #2 (TrustSec policy enforcement)
6.
Cat 3850 switch at Campus ( required for 802.1x wireless device access and TrustSec policy
enforcement)
7.
ASA Firewall HA Primary (TrustSec environment data, specifically security group names)
As SGACLs will not be enforced at the data center Nexus 7000 Core switches nor the Catalyst 6500 VSS
Core in Scenario 1 and as this core infrastructure provides simple transport services in Scenario 2, it is
not mandatory for these devices to be added to the Network Device List in ISE; the network device does
not need to be defined in ISE to simply forward packets with an embedded SGT. It is however
recommended to define these devices to accommodate future network changes or enforcement policies
as well as define a device SGT to be used by traffic sourced by these switches. The following steps must
be taken to define the network devices within ISE as depicted in Figure 23-17:
1.
23-31
Chapter 23
2.
Enter the hostname of the device. This will be the same name as configured at the network device
and documented later with the cts credential command on switches and would be the wireless
controller name.
3.
Enter the IP Address of the network device. This must be the address used to source all RADIUS
communications from the device.
4.
Change the Network Device Location or Device Type if a custom location/type has been previously
defined. Within the CVD the Shared Services, Core, and Data Center switches all make use of the
default setting as seen in Figure 23-17. The exceptions to this are the wireless controllers and
converged access switches. For the controllers we have specified a custom Device Type known as
Campus_Controller:SGT_Enabled and for converged access C3850 switches,
Converged:SGT_Enabled. This custom location is configured under Network Device Groups as
depicted in Figure 23-18. The significance of the use of a custom device type lies in the ability to
use that as an attribute within the Authorization Profile at ISE to determine a result. In this CVD we
use the device type Campus_Controller:SGT_Enabled or Converged:SGT_Enabled to
determine that an SGT Value should be handed back to the wireless controller after a user or devices
successful authorization as opposed to an ACL for policy enforcement. This allows for a migrational
approach to deploying infrastructure that will make use of SGT as opposed to ACLs for policy
enforcement.
5.
Configure the RADIUS Shared Secret. This must match that configured on the network device.
6.
Click the down arrow next to SNMP Settings and complete as appropriate.
7.
Click the down arrow next to Advanced TrustSec Settings. These settings are only used for those
devices supporting SGACLs and Native SG Tagging on SGT-capable hardware requiring the
download of TrustSec environmental and policy data from ISE.
23-32
Chapter 23

Figure 23-17
Network Device Generic Definition at ISE
Figure 23-18
Network Device Group definition
8.
Once the Advanced TrustSec Settings configuration box has been expanded as seen in Figure 23-19,
click the check box next to Use Device ID for TrustSec Identification
9.
Enter the password that will be configured later on the network device in the cts credential
command. This can be the same as the RADIUS Shared Secret.
23-33
Chapter 23
10. Configure the desired settings for TrustSec Notifications and Updates. Note that these are the
settings that determine the frequency of the TrustSec Environment updates to the network device. It
is recommended that aggressive timers not be used here and as such these have been left at the
default value for one day. Note that this is to configure the automated, periodic update of the
pertinent data. In addition to these periodic updates, it is possible to manually push updates for SGT
Names/Values, Network Device SGT, SGT Egress Policy (SGACL), and AAA Server List from
within ISE to those network devices supporting Change of Authorization (CoA). Note that the Nexus
7000 does not support CoA at the time of this document. To support a manual push of environmental
data and policy to the Nexus 7000, it is possible to do so through reissuing the cts credential
command at the Nexus 7000 discussed later. For further information regarding these parameters and
how TrustSec environment data is exchanged, refer to the ISE User Documentation and specifically
the Configuring TrustSec Settings on Switches and TrustSec CoA sections of the chapter
Configuring Cisco Security Group Access Polices located in the ISE 1.2 User Guide at:
http://www.cisco.com/en/US/products/ps11640/products_user_guide_list.html.
11. Enter the credentials to access Exec Mode (if applicable) and the Enable Mode password used by
ISE to access the device to manually push updated information.

12. Complete steps one through seven for every wireless controller providing 802.1X-authenticated
wireless access to users and steps one through eleven for all network devices that will be enforcing
TrustSec Policy requiring SGT Names and SGACL egress policies.
Figure 23-19
Network DeviceAdvanced TrustSec Settings
23-34
Chapter 23

Configuring Network Access Devices for Authentication at ISE

Configuration of the network devices for NDAC support will be outlined in this section. A section will
be devoted to each of the Wireless Controllers, Catalyst 6500 VSS, and the Nexus 7000 switches.
The following configuration tasks will all be completed at the network devices themselves. This
configuration is critical to identify the ISE Primary server as the AAA server from which information
regarding TrustSec will be exchanged. Note that for greater resilience, multiple ISE Policy Service
Nodes can be listed and will be tried in succession. As previously mentioned, it is only necessary to
configure those devices that will provide access for the wireless users and the network devices that will
actually enforce TrustSec policies. It is completely optional whether or not this needs to be configured
on other devices in the path between the enforcement points.
RADIUS Server Configuration on the CT-5508 Wireless Controller

The configuration of RADIUS server information is required in order for the controller to act as a
RADIUS Authenticator for 802.1X-based authentication of wireless clients accessing the network. More
than likely these steps have already been completed as this is a basic requirement for securing wireless
access regardless of the desire to use ACLs or Security Group Tags.
1.
Access the wireless controller either through the local UI or Prime. In Figure 23-20 the controllers
GUI is depicted.
2.
Go to Security > AAA > Radius > Authentication
3.
In the top right of the screen, if the ISE server has not been configured yet, click New.
4.
A new window will open as seen in Figure 23-21.
Figure 23-20
Wireless Controller RADIUS Configuration
23-35
Chapter 23
Figure 23-21
Wireless Controller RADIUS Server Configuration
5.
Use the drop down to enter the correct priority; lower number is higher priority.
6.
Enter the ISE servers IP address.
7.
Enter the Shared Secret which must match that configured for the wireless controller as defined in
the Network Device List in ISE.
8.
Enter the correct RADIUS Authentication UDP port number.
9.
Click Apply.
10. Configure the controllers RADIUS Accounting information as the Authentication information
above. This can be accessed by following Security > AAA > Radius > Accounting.
Configuration of the wireless controller RADIUS server configuration is complete. Repeat these steps if
additional controllers need to be configured.
RADIUS and CTS Configuration of the 5760 Switch

As shown in the network topology diagram (Figure 23-16), the 5760 Wireless LAN Controller in the
campus network supports in-line tagging of SGT frames. The following steps outline those tasks
necessary to configure ISE as a RADIUS server at the 5760 Wireless LAN controller in the campus
network. As discussed, this is to establish a secure connection with ISE for the exchange of TrustSec
Environment Data and Policies. These steps should be performed on all 5760 wireless controllers
regardless of deployment scenario as they will serve as RADIUS Authenticator to wireless devices
accessing the network or propagating Security Group Tags and enforcing policies based on same as in
the case of Scenario 1.
aaa new-model
!
!
// The aaa authorization CTS Configures the switch to use RADIUS authorization for all
network-related service requests.
// cts authorization list Specifies a Cisco TrustSec AAA server group.
23-36
Chapter 23


aaa authorization network CTS group radius
aaa accounting identity default start-stop group radius
!
cts authorization list CTS
!
!
radius server bn14-3495-2
address ipv4 10.230.1.12 auth-port 1812 acct-port 1813 pac key 7 11270A0C03175A5E577E7E
Although the following steps are only required for Scenario 1 and the use of SGACLs,
should a hybrid approach combining SGACLs and SG-FW in Scenarios 1 and 2 be desired, the
<cts role-based enforcement> command will be required.
(config)#cts role-based enforcement/Global command to enable TrustSec
(config)#cts role-based enforcement vlan-list 57/Enable role-based enforcement between
devices in VLAN 57; East/West enforcement.
RADIUS and CTS Configuration of the Nexus 7000

The following steps outline those tasks required to enable TrustSec role-based enforcement and
configure ISE as a RADIUS server at the Nexus 7000. As discussed, this is to establish a secure
connection with ISE for the exchange of TrustSec Environment Data and specifically the SGT Names
for use in creating IP/SGT Bindings at the Nexus 7000 Data Center Aggregation switches. No policies
are available for download as they are configured at the ASA as SGACLs are not used in this deployment
scenario.
Although SGACLs will not be enforced at the Nexus 7000 Data Center Aggregation switches as in the
first deployment scenario, but rather at the ASA configured as a Security Group Firewall, it is still
necessary to define the Nexus 7000 aggregation switches in ISE in order to share TrustSec Environment
Data in order to learn SG Names and IP/SGT mappings defined centrally at ISE.
feature dot1x/Enable dot1x support.
feature cts/Enable cts (TrustSec) support
Although the following steps are required for Scenario 1 and the use of SGACLs, should a hybrid
approach combining SGACLs and SG-FW in Scenarios 1 and 2 be desired, the cts role-based
enforcement command will be required.
TrustSec must be enabled for SGT propagation both globally on the switch as well as for those VLANs
on which SGACLs will be enforced through the use of the following commands:
Global commands
cts role-based enforcement/Enables SGACL enforcement on Nexus 7000
cts role-based counters enable/Enable role-based access control list (SGACL) counters
VLAN Interface commands

(config)# vlan id/Enter VLAN configuration mode.
(config-vlan)# cts role-based enforcement/Enables SGACL enforcement for specified VLAN
Once the features have been enabled, the AAA servers and TrustSec Device credentials must be enabled
through the following commands:
23-37
Chapter 23
cts device-id device-id password password/TrustSec credentials for use with ISE; device ID
and password much be the same as at ISE.
radius-server host 10.225.49.15 key <secret> pac/Specifies the RADIUS authentication
server, shared secret must be same as configured for RADIUS secret at ISE.
aaa group server radius <ise>/Creates a AAA Server Group ISE
server 10.225.49.15/Defines 10.225.49.15 as a member of Group ISE
aaa authentication dot1x default group <ise>/Specifies the 802.1X port-based
authentication method as RADIUS.
aaa accounting dot1x default group <ise>/Enables 802.1X accounting using group ISE
aaa authorization cts default group <ise>/To configure the default authentication,
authorization, and accounting (AAA) RADIUS server groups for Cisco TrustSec authorization
ip radius source-interface loopback0/Matches the IP Address of the device configured in
ISE; uses the IP Address of Lo0 to source all RADIUS.
RADIUS and CTS Configuration of the Catalyst 6500

The following steps outline those tasks necessary to enable TrustSec role-based enforcement and
configure ISE as a RADIUS server at the Catalyst 6500. As discussed, this is to establish a secure
connection with ISE for the exchange of TrustSec Environment Data and Policies. These steps should
be performed on any Catalyst 6500 that will enforce policies based on Security Group Tags. For the
infrastructure depicted in this CVD, configuration must be completed on the Catalyst 6500 VSS in
Shared Services to which the wireless controllers are attached. Although optional when configuring
Scenario 2, defining this provides additional support for a hybrid deployment where both Scenario 1 and
2 may be used, such as in the case of East-West traffic between different wireless controllers relative to
the Shared Services C6500. As the Catalyst 6500 VSS Core and Catalyst 6500 VSS Distribution
switches are merely forwarding tagged packets sourced from either the wireless users or servers
themselves and not enforcing any policies, there is no requirement to configure it within ISE and is
purely optional.
As with the Nexus 7000, although the following steps are required for Scenario 1 and the use of
SGACLs, should a hybrid approach combining SGACLs and SG-FW in Scenarios 1 and 2 be desired,
the cts role-based enforcement command will be required.
TrustSec must be enabled both globally on the switch for SGT propagation as well as for those VLANs
on which SGACLs will be enforced through the use of the following global commands:
cts role-based enforcement/Globally enables SGACL enforcement for CTS-enabled Layer 3
interfaces in the system.
cts role-based enforcement vlan-list {vlan-ids | all}/Enables SGACL enforcement for Layer
2 switched packets and for L3 switched packets on an SVI interface.
Note
SGACL enforcement is not enabled by default on VLANs. The cts role-based enforcement vlan-list
command must be issued to enable SGACL enforcement on VLANs.
The following provides the configuration commands required for ISE as the RADIUS server on the
Catalyst 6500:
cts credentials id device-id password <password>/TrustSec credentials for use with ISE;
device ID and password must be the same as at ISE.
aaa new-model/Enables AAA
aaa group server radius <ise>/Creates a AAA Server Group ISE
server 10.225.49.15 auth-port 1812 acct-port 1813/Defines 10.225.49.15 as a member of
Group ISE.
aaa authentication dot1x default group radius/Specifies the 802.1X port-based
authentication method as RADIUS.
aaa server radius dynamic-author/Enable CoA on the 6500 to enable updates for SG
Names/Tags, Environment Data, and RBACL
client 10.225.49.15 server-key/Identifies ISE as AAA server initiating CoA
23-38
Chapter 23

aaa authorization network <ise> group radius/Configures the switch to use RADIUS
authorization for all network-related service requests using server group <ise>.
aaa accounting dot1x default start-stop group radius/Enables 802.1X accounting using
RADIUS
cts authorization list <ise>/Specifies a Cisco TrustSec AAA server group
ip radius source-interface Loopback0/Matches the IP Address of the device configured in
ISE; uses the IP Address of Lo0 to source all RADIUS.
radius-server host 10.225.49.15 auth-port 1812 acct-port 1813 pac key <secret>/Specifies
the RADIUS authentication server, shared secret must be same as configured for RADIUS
secret at ISE.
radius-server vsa send authentication platform /Configures the switch to recognize and use
vendor-specific attributes (VSAs) in RADIUS Access-Requests generated by the switch during
the authentication phase
dot1x system-auth-control/Globally enables 802.1X port-based authentication
RADIUS and CTS Configuration of the 3850 Switch

Catalyst 3850 switches in the campus network support in-line tagging of SGT frames and will serve as
both the RADIUS authenticator for wireless users as well as enforcing SGACLs. The following steps
outline those tasks necessary to configure ISE as a RADIUS server at the 3850 switch acting as a
Wireless LAN controller in the campus network. As discussed, this is to establish a secure connection
with ISE for the exchange of TrustSec Environment Data and Policies. These steps should be performed
on all Catalyst 3850 switches regardless of deployment scenario as they will serve as RADIUS
Authenticator to wireless devices accessing the network or propagating Security Group Tags and
enforcing policies based on same as in the case of Scenario 1.
aaa
!
!
aaa
aaa
aaa
aaa
aaa
!
cts
new-model
authentication dot1x default group radius

authorization network default group radius
authorization network CTS group radius
accounting dot1x default start-stop group radius
accounting network default start-stop group radius
authorization list CTS
Although the following steps are required for Scenario 1 and the use of SGACLs, should a hybrid
approach combining SGACLs and SG-FW in Scenarios 1 and 2 be desired, the cts role-based
enforcement command will be required.
bnsl-3850-1(config)#cts role-based enforcement/Global command to enable TrustSec
bnsl-3850-1(config)#cts role-based enforcement vlan-list 551/Enable role-based enforcement
between devices in VLAN 551; East/West enforcement.
Configuring Network Devices with a Device SGT

The following outlines the configuration steps required to define a device SGT. Once a network device
is configured with a device SGT, any traffic sourced from that device will use the defined SGT. Note that
assigning a Security Group Tag to a device is purely optional. Network devices in this CVD are assigned
a device SGT of 5. As granular role-based policies using SGTs are defined in the network, the
assignment of an SGT to network devices may provide an additional level of control over whom or what
may access the network infrastructure to poll or modify these devices.
Within this CVD when discussing the specific policies enforced by the SGACLs, it will be seen that
SGT10 for Employees and SGT00 or unknown are both permitted access to SGT 5. Naturally this is for
demonstration purposes only as much more granular policies would be defined for access to network
infrastructure associated with SGT5. For example, it would be assumed that rather than providing all
23-39
Chapter 23
employees (SGT10) access to infrastructure, a group associated with network administrators would be
defined and only those users would have access to SGT5 devices. In the case of unknown, it cannot be
assumed that all network administrators have been migrated to the TrustSec Domain and hence once
entering same via Catalyst switches or wireless networks yet to be migrated will be associated with
SGT00 or unknown. As such, other security measures would naturally be required to restrict access to
these devices such as ACLs or user credentials.
Also note that in the CVD, traffic between SGT 5 and 40 is permitted. This is in order to allow ISE,
identified with SGT40, to be able to communicate with network devices to exchange not only TrustSec
information but all AAA communications as well. Other options would be to assign ISE a unique SGT
other than SGT40 which is used for Open Servers and Services that all can access. In doing this, all user,
server, and network devices with their associated SGT assignments could be allowed to communicate
with the unique SGT for ISE and a policy then established allowing ISE to communicate with the
network devices without opening access to ISE from all servers with SGT40.
Although most likely used when using SGACLs throughout the infrastructure, as in the case of Scenario
1, there may be benefit even if only deploying Scenario 2 and a SG-FW.
1.
At ISE navigate to Policy > Network Device Authorization.
2.
Click the drop down box next to edit at the top right of the screen.
3.
Select Insert new row above as depicted in Figure 23-22.
Figure 23-22
Configuring Network Device Authorization
4.
A new line will be inserted as seen in Figure 23-23. Enter a rule name.
5.
Click the + symbol in conditions and a drop down box will appear.
6.
Click the arrow next to Select Attribute and the Dictionaries drop down box will appear.
23-40
Chapter 23

Figure 23-23
Defining Authorization Policy for the Network Device
7.
Select SGADeviceID and, as can be seen in Figure 23-24, the Expression is populated with
TrustSec:SGADeviceID.
8.
Ensure Equals is displayed in the expression and select the appropriate device, as depicted in
Figure 23-24.
23-41
Chapter 23
Figure 23-24
9.
Defining Network Device ID
Finally, as in Figure 23-25 define the SGT for the device by clicking the arrow next to Select a
Security Group and select the appropriate SG Name; the CVD uses SGT5_TrustSec_NAD. See
the note below.
10. Repeat steps one through nine to define all network devices; as wireless controllers cannot natively
tag packets with an SGT on its interfaces, this procedure is not required for them.
Figure 23-25
Note
Assigning the SGT to a Network Device
In Steps 9 and 10 above the network device ID (typically the hostname) is used to create a Network
Device Authorization Rule. An alternative approach would be to use the Location or Device Type
attribute, as seen in Figure 23-23. By using one of these attributes provided when initially defining a
23-42
Chapter 23

network access device in ISE as previously discussed and as seen in Figure 23-17, potentially hundreds
of rules using device IDs could be replaced by a single rule using the device type attribute to classify a
specific platform such as Campus_Controller:SGT_Enabled. Figure 23-26 shows the alternative way
to configure the device ID.
Figure 23-26
Alternative Configuration of Device ID
Configuring Static IP/SGT Bindings on Nexus Switches

Unlike campus access through Catalyst Switches and Cisco Wireless Controllers where dynamic SGT
mappings are communicated and created through 802.1X and RADIUS exchange, the vast majority of
organizations do not implement 802.1X for server connectivity. As such, data center switches such as
the Cisco Nexus switches provide only limited support for the use of 802.1X and do not specifically
support an SGT RADIUS AV as an option. Therefore, IP Address to SGT mappings will be manually
defined for bare metal and virtual servers.
For purposes of this CVD, we continue to use IP to SGT Bindings at a Nexus 7000 data center
aggregation layer switch, but will also expand the means by which servers can be mapped to an SGT
through the VLAN in which they reside. This new feature, which was previously discussed in SGT
Assignment for Data Center Servers, is VLAN to SGT Mapping and is found in the NX-OS 6.2 release.
In addition to the manual creation of an IP Address to SGT mapping either globally at the switch or
within a VLAN, the servers IP/SGT mapping may also be defined in ISE. Configuration at ISE for use
in the CVD is purely optional as the focus of the CVD is on static IP/SGT mappings or VLAN to SGT
mappings at the Nexus 7000 switches.
For purposes of this CVD, the static IP/SGT Mappings and the VLAN/SGT mappings have been created
at the Nexus 7000 Data Center Aggregation layer switches as depicted below. Note that as there are two
Nexus 7000s composing the aggregation layer in the data center; both must be configured identically for
consistent policy enforcement.
The following commands provide an example of IP/SGT static bindings:
cts role-based sgt-map 10.230.1.2 40/Binds 10.230.1.2 to SGT 40
The following commands provide an example of VLAN/SGT bindings:
23-43
Chapter 23
Configuration for Deployment Scenario 1
vlan 136/Specifies a VLAN and enters VLAN configuration mode.

cts role-based enforcement/Enables SGACL enforcement within the VLAN
40 /Maps all devices within VLAN 136 to SGT 40
vlan 137
cts role-based enforcement
cts role-based sgt 50
cts role-based sgt
To verify the IP/SGT mappings at the Nexus 7000, issue the command sh cts role-based sgt-map.
bn14-n7k-agg# show cts role-based sgt-map
IP ADDRESS
SGT
VRF/VLAN
SGT CONFIGURATION
10.230.6.3
40(Servers_Services_OpenAccess)vlan:136
Learnt through VLAN SGT
configuration
10.230.6.14
40(Servers_Services_OpenAccess)vlan:136
configuration
10.230.7.3
50(Servers_Corporate)vlan:137
configuration
10.230.7.14
50(Servers_Corporate)vlan:137
configuration
10.230.1.12
40(Servers_Services_OpenAccess)vrf:1
CLI Configured
10.230.1.45
CLI Configured
10.230.1.61
CLI Configured
Note
Refer to Migrational Considerations for TrustSec Implementation for a complete discussion of SGT
mapping strategies in the data center.

This section provides detailed information regarding configuration of the necessary components that
compose and are unique to Scenario 1. In addition to the configuration requirements for SGT
propagation through the campus infrastructure, MACsec encryption will be used for link encryption
where possible in the network. In this CVD MACsec will be used to encrypt the 10G links between
Catalyst 6500s and Nexus 7000s. On the 10G links connecting the Catalyst 6500 with the Catalyst 3850s
in distribution and the CT-5760 in Shared Services, MACsec although available in hardware is not
enabled in software on the 3850 and 5760 at the time of writing. This capability will be enabled in a
future release.
Prior to discussing the Scenario 1 configuration specifics, a brief explanation of Catalyst 6500-specific
forwarding behavior with SGT encapsulated frames is required when using a SUP2-T Supervisor in
conjunction with specific linecards. The following section discusses these considerations.
Catalyst 6500 Platform Specific Considerations

Prior to discussing aspects of the TrustSec infrastructure configuration, it is necessary to highlight one
aspect regarding the Catalyst 6500 when configured for Cisco TrustSec and specifically SG Tagging
capability. As previously stated, the SUP2T and WS-X69xx series of linecards are the only SGT-Capable
Supervisor and linecard available today for processing and imposition/removal of Security Group Tags
in the Catalyst 6500. Specialized ASICs are required in order to forward tagged packets and encrypt the
frames using 802.1ae MACsec with 10GE wirespeed performance. This functionality involves changes
in the internal forwarding process. In order to support earlier linecards that do not have these newer
ASICs (i.e., WS-X68xx, WS-X67xx, and WS-X61xx) in the same chassis when TrustSec has been
enabled, two new operating modes have been developed called Ingress and Egress Reflector mode.
Ingress Reflector mode is intended for use when the Catalyst 6500 is providing network access; it does
23-44
Chapter 23

not support linecards with a DFC installed. Egress reflector mode provides compatibility with legacy
line cards by using the SUP2T forwarding engines built-in packet replication ASICs to initiate a second
packet forwarding decision. This second forwarding decision is used to impose the Cisco TrustSec SGT
information on packets egressing the system from an SGT-capable interface. For purposes of this BYOD
CVD, Egress Reflector Mode will be used on the Catalyst 6500 VSS switches containing legacy
linecards.
To enable the Egress Reflector Mode on the Catalyst 6500, it is necessary to perform a reload of the
system. It is recommended for obvious reasons that this be performed off hours and that necessary
precautions have been put in place to ensure that traffic can be forwarded around the reloading system
if required. In the case of Catalyst 6500s configured for VSS, it is recommended that the entire system
be reloaded through the reload command. The command to enable this mode of operation on the Catalyst
6500 is:
platform cts egress
For more detailed information, refer to:

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11-658388.html.
Configuring Security Group Tag Exchange Protocol (SXP) for Wireless

Controllers
Campus wireless users accessing the network upon successfully matching an authorization profile at the
Identity Services Engine will be associated with an SGT. Upon successful authentication and subsequent
authorization to the network, the Identity Services Engine will pass the appropriate SGT value to the
wireless controller through a RADIUS AV. This SGT value is associated with the IP Address of the
wireless user obtained through the 802.1X authentication and an IP/SGT mapping/mapping created at
the wireless controller.
Whereas the CT-5760 wireless controller supports native tagging upon egress from the controller and
will be discussed separately in Scenario 1, wireless controllers such as the CT5508, used in this guide,
and the WiSM2 do not support the tagging of packets sourced from these wireless users out of the
controller through both physical and internal interfaces, in the case of the WiSM2. As such, the Security
Group Tag Exchange Protocol will be used to advertise these SGT mappings to the Shared Services
Catalyst 6500VSS switch, which will impose the appropriate tag upon egress from the switch.
SXP is configured on a device by identifying its peers IP Address and specifying a password for use in
authenticating each side of the connection. SXP supports two modes which can be used either
exclusively or combined. The first mode is that of the Speaker, which as the name suggests advertises
IP/SGT mappings. The other mode is Listener, which also as its name suggests listens for the
Speakers advertisements. It is possible for a device to be both a Speaker and a Listener. The
CT5508 and WiSM2 only support Speaker mode as they do not support SGACLs or SGT Tagging and
hence a Listener mode is not applicable.
Both sides of the SXP connection must be configured and within Deployment Scenario 1 this includes
configuration of both CT5508s as well as the Shared Services Catalyst 6500 VSS switch. Refer to
Figure 23-27.
23-45
Chapter 23
Figure 23-27
SXP Peering
Services
Data Center
DNS
DHCP
Nexus
7000 VPC
DC Core
CT5508
WLCs
CA
AD
Nexus
5000 VPC
DC Agg
CT5760
WLCs
Core
Application and
File Servers
Distribution
Switch
Catalyst
3750-X

SXP Tunnel
Catalyst 3850
Switch Stack
Wireless Controller Configuration

Access the wireless controller via a web UI and follow the following steps:
1.
Navigate to Security > TrustSec SXP.

The screen in Figure 23-28 appears.
2.
Click the drop down arrow for SXP State and select Enabled.
3.
Set the default Password. This must match that configured on its peer.
4.
Click New (top right).
5.
Fill in the IP Address (typically Loopback if possible) of the SXP Peer or the Shared Services
Catalyst 6500VSS switch.
6.
Click Apply.
23-46
294969
3600 AP Module
3600 AP Module
(802.11ac/n)
(802.11ac/n)
CAPWAP
CAPWAP
Chapter 23

Once successfully configured, the screen in Figure 23-29 should be presented upon accessing Security
> TrustSec SXP. The Connection Status will indicate Off until the other device is configured.
Figure 23-28
SXP Configuration at Wireless Controller
Figure 23-29
SXP Configuration Complete
Catalyst 6500 SXP Configuration

The following commands were used at the Shared Services Catalyst 6500 VSS to enable SXP peering
with the CT5508 wireless controllers.
23-47
Chapter 23
cts sxp enable/Enable CTS

cts sxp default source-ip 10.225.100.5/Source SXP connection from 10.225.100.5 (Lo)
cts sxp default password password/Configured password on the 6500 for incoming SXP
connections
cts sxp connection peer 10.225.43.2 source 10.225.100.5 password default mode local
listener hold-time 0 0/Builds an SXP connection to its peer at 10.225.43.2 using source
address of 10.225.100.5 and the default password defined above. Specifies that this
(local) device is in Listener mode. The source IP Address used here is purely optional
as it was specified above.
Issuing the command show cts sxp connection results in the following output.
ua28-6500-1>sh cts sxp connections
SXP:Enabled
Highest Version Supported:4
Default Password :Set
Default Source IP:10.225.100.5
Connection retry open period:120 secs
Reconcile period:120 secs
Retry open timer is not running
---------------------------------------------Peer IP:10.225.43.2<--Wireless Controller
Source IP:10.225.100.5
Conn status:On
Conn version:2
Local mode:SXP Listener
Connection inst#:1
TCP conn fd:1
TCP conn password:default SXP password
Duration since last state change:0:21:49:55 (dd:hr:mm:sec)
Total num of SXP Connections = 1
Configuring Switching Infrastructure to Support TrustSec with 802.1ae MACsec

Encryption
Now that the configuration of ISE and the Network Access Devices ability to communicate with ISE as
the AAA server via RADIUS have been completed, the following steps are required for the configuration
of the 10GE links in the switching infrastructure to support TrustSec, specifically SGT insertion,
removal, and forwarding as well as the encryption of those links using 802.1ae MACsec. In the BYOD
CVD infrastructure depicted in Figure 23-30, it is necessary to configure the blue, 10GE links in the
figure for TrustSec using the Catalyst and Nexus switch cts command.
23-48

Figure 23-30
TrustSec Configuration of 10GE Links
Services
Data Center
DNS
DHCP
Nexus
7000 VPC
DC Core
CT5508
WLCs
CA
AD
Nexus
5000 VPC
DC Agg
CT5760
WLCs
Core
Application and
File Servers
Distribution
Switch
Catalyst
3750-X

Catalyst 3850
Switch Stack
3600 AP Module
3600 AP Module
(802.11ac/n)
(802.11ac/n)
CAPWAP
CAPWAP
294972
Chapter 23
There are two methods, 802.1X Mode and Manual Mode, for configuring 10GE interfaces to support
Security Group Access (TrustSec), enabling the forwarding and policy enforcement of frames with an
embedded Security Group Tag. CTS 802.1X Mode uses a Pairwise Master Key (PMK) derived through
the authentication phase between the network device and ISE for link encryption whereas with CTS
Manual Mode, as its name implies, the PMK is manually configured. In this CVD, the Manual Mode of
configuration is used.
Common to both of these methods is first the ability to employ MACsec (802.1ae) which provides
encryption, a message integrity check, and data-path replay protection for links between adjacent
network devices thereby protecting the CMD field and the SGT value it contains. Second, as previously
discussed is the configuration for 802.1X authentication of the network devices that will enforce policies
based on the SGT with ISE acting as an Authentication Server.
Also common to both CTS Manual and 802.1X Mode is the use of the Security Association Protocol
(SAP) which is an encryption key derivation and exchange protocol based on a draft version of the
802.11i IEEE protocol. In a TrustSec configuration, the keys are used for MACsec link-to-link
encryption between two interfaces.
23-49
Chapter 23
In CTS Manual Mode, the Pairwise Master Key (PMK) will be manually configured on each of the two
interconnecting 10GE interfaces with the sap pmk command. The PMK is a hexadecimal value with an
even number of characters and a maximum length of 32 characters. It is not necessary to specify all 32
characters as the value provided will be padded with zeroes. This value MUST be the same on both sides
of the link between the two switches. The Catalyst 6500s will pad the PMK provided with leading zeroes
by default however the Nexus 7000 will pad the PMK with trailing zeroes by default. It is possible
however, at the Nexus 7000 command line, to alter this behavior which is demonstrated below.
Note
If configuring 10GE links that have not been defined as a member of a port channel, you may proceed
to the commands listed below. If however, these 10GE links are presently active within a port channel,
it will be necessary to first remove them from that port channel as otherwise issuing the cts command
will fail, having not successfully passed a port channel consistency check. Once removed from the Port
Channel, TrustSec, through the cts command can now be configured.
When migrating port channels to enable TrustSec/MACsec, one possible migration option is to remove
the links one at a time, configure TrustSec and MACsec as applicable on both sides of the link and ensure
that the link comes back up. Repeat this on each port channel member until the last one is reached.
Remove the last remaining member from the port channel. Once the port channel has no remaining links,
those configured for TrustSec can then be added sequentially. This type of migrational procedure can be
used on both the Catalyst and Nexus switching platforms.
When configuring the Security Association Protocol as the keying mechanism for use with MACsec
several options are available for authentication and encryption on the link. Table 23-4 provides a
summary of each option. When mode-list is specified as above, the devices on either side of the link will
negotiate via the SAP protocol, the method supported. As defined above, gcm-encrypt will be tried first
and so on.
Table 23-4
Mode
Security Association Protocol Options
Description
gcm-encrypt Authentication and encryption

gmac
no-encap
null
Authentication, no encryption
1
No encapsulation1
Encapsulation (SGT), no authentication or encryption
1. If the interface is not capable of SGT insertion or data link encryption, no-encap is
the default and the only available SAP operating mode.
TrustSec Link Policy

When configuring the 10Gb Ethernet links for the Manual Mode of operation, it is necessary to define
whether tags received from a peer device should be trusted or untrusted and how the tags or lack of
should be propagated by the switch. This Policy is only applicable to traffic entering a switch interface
and not upon egress from the switch. When the interface is configured for the trusted state, the tag
encapsulated in the frame will be propagated as is. For those frames arriving at an interface that have
either 00 (the unknown tag) or no CMD, hence no SGT present, the behavior will vary depending on
the platform and is discussed later in this section. In the case of having defined the peer as untrusted,
the tag present, whether a defined value, unknown, or if CMD is missing altogether, will be overwritten
by the SGT value specified in the policy command. This is accomplished through the use of the policy
static command on a switch ingress interface as follows:
(config-if)#cts manual/Manually enable an interface for Cisco TrustSec Security (CTS)
23-50
Chapter 23

(config-if-cts-manual)# policy static sgt id trusted/Establishes that the peer is

trusted.
Alternatively:
(config-if-cts-manual)# policy static sgt id/Establishes that the peer is untrusted (no
trusted keyword)
The policy definition is required for both the Catalyst 6500 and the Nexus 7000 and if omitted will result
in the frames, whether tagged with a defined SGT value or SGT:00 for unknown, having the CMD header
with the SGT value removed and hence an un-tagged frame. In other words, when omitting the policy
static command any tag is inherently untrusted.
Note
Prior to NX-OS v6.2.2, the omission of the policy static command had a very different behavior than
than v6.2.2 and later. Prior to v6.2.2 if the command were omitted, frames received with an SGT defined
would be forwarded with that value. If the frame carried an SGT of 00 or unknown, it would be
forwarded with 00 and if the frame was untagged it would be forwarded as SGT:00.
Post NX-OS 6.2.2 as mentioned previously, if omitted, the frame will be forwarded without a tag after
having removed the CMD header carrying the SGT.
Catalyst 6500 switches performs consistently regardless of version such that if omitted, the frame will
be forwarded without a tag.
Table 23-5 summarizes the effect of omitting the policy static command from a Nexus 7000 inteface
depending on the NX-OS version used.
Table 23-5
Effect of Omitting policy static Command from Nexus 7000 Interface
Policy static command omitted pre-NX-OS 6.2.2
Nexus 7000
Tagged Frame other than SGT:00
Pass with source tag
Tagged Frame SGT:00 or unknown
Pass with tag SGT:00
Un-Tagged Frame
Pass with tag SGT:00
Policy static command omitted post-NX-OS 6.2.2

Tagged Frame other than SGT:00
Pass without a tag (no CMD in header)
Tagged Frame SGT:00 or unknown
Un-Tagged Frame
Within the CVD, the TrustSec domain will make use of all trusted interfaces, however there are
instances where an architecture or deployment has a requirement for strict policy control, such as at the
edge of the TrustSec domain in order to mark traffic for specific treatment and hence the use of the
untrusted policy state. Figure 23-31 and the subsequent explantion provide an example of the behavior
of the policy static command when a peer is untrusted. This behavior is identical whether used on a
Catalyst 6500 or Nexus 7000 interface.
23-51
Chapter 23
Figure 23-31
Policy Static Untrusted Behavior
Traffic Direction
1
0
0
200
Untrusted
Untagged
2
0
0
200
Untrusted
4
0
0
N7K-1
400
Untrusted
4
0
0
400
Untrusted
2
0
0
0
0
2
5
PC
Untagged
PC
0
0
4
0
0
PC
Untagged = Traffic just entering TrustSec Domain

00 = Unknown; no SGT mapping exists.
4
0
0
294973
2
0
0
6500-1
The following SGT marking behavior can be seen in the previous figure:
1.
Frames having an SGT:100, SGT:00, and no tag (no CMD header present) are entering 6500-1 from
the left.
2.
A PC or Server connected by a non-TrustSec link is attached to 6500-1.
3.
The ingress policy is set to <policy static SGT 200> (untrusted) on the left 10G link while the PC
port is not configured.
4.
Traffic leaving the switch now all have a value of SGT:200 as long as there is not a mapping for the
Src IP Address in 6500-1. If a mapping for that IP exists, it will be marked with that static SGT
value.
5.
Notice that the PC traffic leaving the switch has SGT:00 for the following reasons:
No policy was configured on the PC's Ethernet port.
The policy static command configured on the egress interface has no effect on traffic in the egress
direction. The policy static command only influences ingress traffic.
There is not a mapping for the Src IP Address in 6500-1. If a mapping for that IP had existed, it
would have been marked with that static SGT value.
6.
The Nexus 7000 switch now has traffic from the Catalyst 6500 peer with SGT:200 and the PC traffic
with SGT:00.
7.
The traffic entering N7K-1 is untrusted and thus as the traffic leaves N7K-1 it will be marked with
SGT:400 as specified by the policy static sgt 400 on the ingress (left interface), as long as there is
not a mapping for the Src IP Address in N7K-1for any of the flows. If a mapping for that IP exists,
it will be marked with that static SGT value. Again the egress policy has no effect whatsoever on
the traffic leaving the switch.
When specifying the policy static sgt id trusted command on an interface, any traffic received from a
peer with a valid, pre-defined SGT value will be trusted and propagated with that SGT value intact,
unlike the untrusted behavior where it is overwritten. As of the writing of this CVD there is a discrepancy
between the behavior of a trusted interface in a Catalyst 6500 versus a Nexus 7000 relative to the
propagation of untagged traffic or traffic with an SGT of 00 (unknown). This discrepancy exists with all
versions of IOS for the Catalyst 6500 and NX-OS for the Nexus 7000 up to and including 15.1.2SY for
the 6500 and 6.2.6 for the Nexus 7000. Figure 23-32 and subsequent explantion provide an example of
23-52

the behavior of the policy static trusted command when a peer is trusted for both the Catalyst 6500 and
the Nexus 7000.
Note
In Figure 23-32 it can be seen that the SGT value specified for the ingress interfaces of the two switches
is different. This is depicted in this fashion to demonstrate the behavior more thoroughly. When
assigning the SGT value for the policy static trusted command, it may be the same or unique from one
interface to the next throughout the TrustSec Domain. As a matter of best practice, it is recommended
that a single, unique SGT value be used throughout the TrustSec Domain and not used for any other
purpose than the interfaces.
Figure 23-32
Policy static Trusted Behavior
Traffic Direction
1
0
0
6500-1
1
0
0
Untagged
200
Trusted
0
0
200
Trusted
1
0
0
6500-1
400
Trusted
0
0
400
Trusted
0
0
0
0
PC
0
0
0
0
PC
0
0
PC
Untagged
Traffic Direction
1
0
0
Untagged
0
0
1
0
0
N7K-1
200
Trusted
2
0
0
200
Trusted
1
0
0
N7K-1
400
Trusted
2
0
0
400
Trusted
10
2
0
0
PC
2
0
0
0
0
PC
4
0
0
294974
Chapter 23
PC
Untagged
1.
Frames having an SGT:100, SGT:00, and no tag (no CMD header present) are entering 6500-1on the
top and N7K-1on the bottom from the left interface.
2.
A PC or Server connected by a non-TrustSec link is attached to 6500-1 and N7K-1.
23-53
Chapter 23
3.
The ingress policy is set to policy static SGT 200 trusted on the left 10G link of both the Catalyst
6500 and the Nexus 7000 switches while the PC port is not configured.
4.
Traffic leaving the first Catalyst 6500 in the top half of Figure 23-32 will be propagated as follows:
Tagged traffic will be forwarded with the tag received as in the case of SGT:100.
Untagged traffic from the PC without the CMD present will be forwarded with a tag of 00 or
unknown as long as there is not a mapping for the Src IP Address in 6500-1. If a mapping for that
IP exists, it will be marked with that static SGT value.
Unknown traffic, SGT:00, will be forwarded with 00 as long as there is not a mapping for the Src IP
Address in 6500-1. If a mapping for that IP exists, it will be marked with that static SGT value.
5.
Notice that the PC traffic leaving the Catalyst 6500 has SGT:00 for the following reasons:
No policy was configured on the PCs Ethernet port.
The policy static command configured on an egress interface has no effect on traffic in the egress
There was not a mapping for the Src IP Address in 6500-1. If a mapping for that IP existed, the traffic
6.
Traffic leaving the first Nexus 7000 switch in the bottom half of the diagram will be propagated as
follows:
Untagged traffic from the PC without the CMD present will be forwarded and marked with a tag of
200 as long as there is not a mapping for the Src IP Address in N7K-1. If a mapping for that IP exists,
it will be marked with that static SGT value.
Unknown traffic SGT:00 will be forwarded and re-marked with 200 as long as there is not a mapping
for the Src IP Address in N7K-1. If a mapping for that IP exists, it will be marked with that static
SGT value.
7.
Notice that the PC traffic leaving the Nexus 7000 has SGT:00 for the following reasons:
No policy was configured on the PC's Ethernet port.
The policy static command configured on an egress interface has no effect on traffic in the egress
There was not a mapping for the Src IP Address in N7K-1. If a mapping for that IP existed, the traffic
8.
The second Catalyst 6500 and Nexus 7000 switches are configured with policy static sgt 400
trusted on their ingress interfaces.
9.
Traffic leaving the second Catalyst 6500 in the top half of the diagram will be propagated as follows:
Unknown traffic, SGT:00, will be forwarded with 00 as long as there is not a mapping for the Src IP
Address in 6500-1. If a mapping for that IP exists, the traffic will be marked with that static SGT
value.
10. Traffic leaving the second Nexus 7000 switch in the bottom half of Figure 23-32 will be propagated
as follows:
Tagged traffic will be forwarded with the tag received as in the case of SGT:100 and SGT:200.
Unknown traffic, SGT:00, will be forwarded and re-marked with 400 as long as there is not a
mapping for the Src IP Address in N7K-1. If a mapping for that IP exists, it will be marked with that
static SGT value.
23-54

11. In Figure 23-32, remember that the egress policy has no effect whatsoever on the traffic leaving
either the Catalyst 6500 or Nexus 7000.
Note
In NX-OS 6.2.2, defect CSCul56062 was identified on the Nexus 7000 such that if an egress interface
was configured as Untrusted (sgt policy static sgt id), the frames egressing the switch would be
re-marked to the value specified in the policy static command. This behavior is depicted in
Figure 23-33. This has since been resolved in NX-OS 6.2.6 and as such it is recommended to not use
6.2.2.
Figure 23-33
Policy static untrusted behavior with Defect CSCul56062
Traffic Direction
1
0
0
2
0
0
N7K-1
2
0
0
200
Trusted
Untagged
5
0
0
N7K-1
400
Trusted
5
0
0
500
Trusted
2
0
0
0
0
PC
5
0
0
0
0
PC
5
0
0
294975
Chapter 23
PC
Untagged
The following table summarizes the behavior of the policy static sgt id | trusted command.
Table 23-6
Behavior of policy static sgt id trusted Command
Policy Status
Catalyst 6500
Nexus 7000
State: Trust - Tagged Frame
Pass with Src SGT

received
Pass with Src SGT

received
State: Trust - Un-tagged Frame or SGT:00
Pass with SGT:00

(Unknown)
Pass with SGT:80 as

configured.
State: Un-Trusted - Tagged Frame
Pass with SGT:80 as

configured.
Pass with SGT:80 as

configured.
State: Un-Trusted - Un-tagged Frame or SGT:00
Pass with SGT:80 as

configured.
Pass with SGT:80 as

configured.
Feature (policy static sgt 80 trusted)
Feature (policy static sgt 80)
The recommendation established in this CVD is to configure all interfaces within or at the edge of the
TrustSec Domain as trusted. It is also strongly advised that the SGT value used in the policy static
command is a unique value dedicated to interfaces only and, more specifically, not the Device SGT. The
reason for not specifying the same SGT value as that used for the actual device is discussed later in this
23-55
Chapter 23
section. However suffice it to say based on the behavior of the Nexus 7000 interfaces when configured
as trusted, any unknown traffic will be remarked to the SGT value specified in the interface policy static
command. That said an explicit SGACL will be required denying access to the actual infrastructures
Device SGT from the interface SGT so that only users/devices with a specific SGT have administrative
access to network devices.
Based on the recommendation for a unique SGT value to be used on TrustSec interfaces, SGT 80 has
been reserved and used exclusively in the CVD for this purpose. Figure 23-34 depicts the SGT marking
behavior that can be expected.
Figure 23-34
Recommendation for policy static Command
Traffic Direction
1
0
0
80 Trusted
Untagged
0
0
80 Trusted
1
0
0
N7K-1
80 Trusted
0
0
80 Trusted
0
0
0
0
Untagged = Traffic just entering TrustSec Domain

00 = Unknown; no SGT mapping exists.
1.
Tagged traffic with either a defined value or 00 representative of Unknown as well as traffic
without a CMD header and hence no SGT value whatsoever will enter 6500-1.
2.
Note that the policy static sgt 80 trusted command on 6500-1s right interface has no effect on
traffic egressing the switch whatsoever. Its intent is for either return or sourced traffic from the data
center. Traffic egressing 6500-1 will be marked accordingly:
Traffic with a valid SGT will be trusted and propagated with the original SGT such as 100.
Traffic without a CMD Header and hence no SGT will be encapsulated with a CMD and a value of
00 as long as there is not a mapping for the Src IP Address in 6500-1. If a mapping for that IP exists,
it will be marked with that static SGT value.
Unknown traffic or SGT:00 will be forwarded with SGT:00 as long as there is not a mapping for the
Src IP Address in 6500-1. If a mapping for that IP exists, it will be marked with that static SGT
value.
3.
N7K-1 will be configured with policy static sgt 80 trusted configured on the ingress interface (left).
4.
Note that the policy static sgt 80 trusted command on N7K-1s right interface has no effect on
traffic egressing the switch whatsoever. Its intent is for either return or sourced traffic from the data
center.
5.
Based on the previously discussed differences in behavior between the Catalyst 6500 and Nexus
7000 platform, egress traffic will be marked accordingly:
Tagged traffic will be forwarded with the tag received as in the case of SGT100.
Unknown traffic, SGT00, will be forwarded and re-marked with 80 as long as there is not a mapping
for the Src IP Address in N7K-1. If a mapping for that IP exists, it will be marked with that static
SGT value.
23-56
0
0
294976
1
0
0
6500-1
Chapter 23

Note
In all of the previous examples and regardless of whether the device is a Catalyst 6500 or a Nexus 7000,
there is one behavior that is always consistent. Untagged traffic without a CMD header present, and
hence no SGT, upon egressing that device will always be encapsulated with the CMD header containing
a value of 00. All traffic flowing across a TrustSec-capable link will have some SGT value and if a
mapping for that traffic does not exist, it will always be 00 or Unknown.
One final consideration is around the traffic from users or devices accessing the network through
network infrastructure that has yet to be configured for TrustSec. This was discussed in detail in
Migrational Considerations for TrustSec Implementation. In summary, this traffic entering the data
center with SGT00 will be remarked to SGT80. As such, it will be necessary to have a policy permitting
access to all servers and resources in the data center from traffic with a source tag of 80 as it is impossible
to discern a devices role-based privileges. As such it would be anticipated that existing ACLs or firewall
policies would restrict access based on IPv4 addresses.
Catalyst 6500 Commands

The following section provides configuration details for enabling TrustSec on the Catalyst 6500
interfaces. At the Ten Gigabit Ethernet interface configuration prompt issue the following commands.
Note that the first two commands should have already been completed, however they have been included
here as well.
cts role-based enforcement/Globally enables SGACL enforcement for CTS-enabled Layer 3
interfaces in the system.
cts role-based enforcement vlan-list {vlan-ids | all}/Enables SGACL enforcement for Layer
2 switched packets and for L3 switched packets on an SVI interface.
(config-if-cts-manual)# sap pmk ABC123 mode-list gcm-encrypt gmac null/Manually specify
the Pairwise Master Key (PMK) and the Security Association Protocol (SAP) authentication
and encryption modes to negotiate MACsec link encryption between two interfaces.
(config-if-cts-manual)# policy static sgt 80 trusted/Establishes the trust state of the
peer interface. See note above.
Nexus 7000 Commands

At the Ten Gigabit Ethernet interface configuration prompt issue the following. If this configuration is
being applied to a link interconnecting a Catalyst 6500 and a Nexus 7000, note that it will be necessary
to alter the sap pmk command to change the default method of padding the PMK should less than 32
characters be specified. The first two commands should have already been completed, however they have
been included here as well.
cts role-based enforcement/Enables SGACL enforcement on Nexus 7000
cts role-based counters enable/Enable role-based access control list (SGACL) counters
(config-if-cts-manual)# policy static sgt 80 trusted/Establishes the trust state of the
peer interface. See note above.
Link connecting to another Nexus switch:

(config-if-cts-manual)# sap pmk ABC123 mode-list gcm-encrypt gmac null/Manually specify
the Pairwise Master Key (PMK) and the Security Association Protocol (SAP) authentication
and encryption modes to negotiate MACsec link encryption between two interfaces.
23-57
Chapter 23
Link connecting to a Catalyst switch:

(config-if-cts-manual)# sap pmk ABC123 left-zero-padded mode-list gcm-encrypt gmac null
/Manually specify the Pairwise Master Key (PMK) and the Security Association Protocol
(SAP) authentication and encryption modes to negotiate MACsec link encryption between two
interfaces.
The SAP modes of operation are identical to those of the Catalyst 6500 detailed earlier.
Catalyst 3850 Commands

The Catalyst 3850 commands are almost identical to those used on the Catalyst 6500. As there is no
MACsec support for the Catalyst 3850, the interface sap pmk configuration is not required on the 10G
links used to connect the 3850 to the Distribution Layer switch. Additionally platform reflector mode
configuration on the Catalyst 6500 as previously documented is not applicable to the 3850. The first two
commands should have already been completed, however they have been included here as well.
(config)#cts role-based enforcement vlan-list 551/Enable role-based enforcement between devices
in VLAN 57; East/West enforcement.
(config-if-cts-manual)# policy static sgt 80 trusted/Establishes the trust state of the peer interface.
See note above.
CT-5760 Commands
The CT-5760 supports native SGT tagging on its interfaces and as discussed previously also supports
SGACLs such that all wireless device traffic egressing the CT-5760 will be encapsulated with the
appropriate SGT. Likewise all tagged traffic received at the CT-5760 will inspect the tag on the incoming
traffic and match it against the SGACL policy it received from ISE prior to forwarding to the wireless
devices. Unlike the CT-5508 in Scenario 1, there is no requirement for any SXP configuration.
The CT5760 wireless controller will require the exact same commands as the Catalyst 3850. The
CT-5760 presently does not support MACsec either so the sap pmk commands used on the Catalyst 6500
will not be required on the 10Gb Ethernet interfaces used to connect to the Shared Services Catalyst 6500
VSS switch. The first two commands should have already been completed, however they have been
included here as well.
(config)#cts role-based enforcement vlan-list 2/Enable role-based enforcement between devices in
VLAN 57; East/West enforcement.
(config-if-cts-manual)# policy static sgt 80 trusted/Establishes the trust state of the peer interface.
See note above.
Policy Enforcement
The next step for TrustSec configuration at ISE will be the definition of the actual policy to be enforced.
As discussed previously, the TrustSec Policy will only be created for use as an SGACL on Catalyst and
Nexus switching products. The ASA family of firewalls as of v9.0 do not support dynamic
creation/update of the policies defined in ISE. Only the actual Security Group Names and Tag value are
23-58

dynamically acquired from ISE. The policy used in this CVD is depicted in Figure 23-35.
Figure 23-35
Security Group Tag Egress Policy Matrix
SGT5
SGT10
SGT11
SGT12
SGT40
SGT50
SGT80
Unknown
SGT5
SGT10
SGT11
SGT12
SGT40
SGT50
SGT80
Unknown
Note
294977
Chapter 23
**
demonstration purposes only as much more granular policies would be defined for network access. For
example it would be assumed that rather than providing all employees (SGT10) access to infrastructure,
a group associated with network administrators would be defined and only those users would have access
to SGT5 devices. In the case of unknown, it cannot be assumed that all network administrators have been
migrated to the TrustSec Domain and hence once entering will be associated with SGT00 or unknown.
As such other security measures would naturally be required restrict access to these devices such as
ACLs or user credentials.
information but all AAA communications as well.
Also note from Figure 23-35 that SGT 80 which has been reserved for use with the policy static interface
commands is denied access to network infrastructure with a device SGT 5. Also with regard to SGT80
permissions, refer to TrustSec Link Policy for a detailed explanation and rationale why SGT80 must be
permitted to all other SGT values during migration.
The basic TrustSec Policy that is used permits or denies a specific source SGT to a specific destination
SGT. In addition to this basic policy it is possible to create SGACLs with additional granularity
restricting or permitting access to specific TCP or UDP port numbers. Although not utilized in the CVD,
the procedure for creating this policy is to first create an SGACL at ISE and then when creating a specific
SGT policy, adding the SGACL to the definition. The following steps illustrate the creation of an
optional SGACL to then be used in an SGT Policy. If this level of granularity is not required and only a
basic permit or deny statement is needed, steps one through three below may be skipped.
1.
Go to Policy > Policy Elements > Results > Security Group ACLs and Add an ACL.
2.
Enter the name of the ACL and optionally add a description as depicted in Figure 23-36.
3.
Add the ACL.
23-59
Chapter 23
Figure 23-36
SGACL Creation
The next step is to define the SGT Policy on the ISE server by creating the appropriate entries to enforce
the policy contained in Figure 23-35 earlier in this section. When creating the SGT Egress Policy
definitions, it is possible to do this from three unique views:
Source Tree
Destination Tree
Matrix
Note that although the three views display the policy differently the steps for creating the policy are
essentially the same. Please refer to the steps outlined below and depicted in Figure 23-37 where the
Source Tree view is used.
4.
Go to Policy > Security Group Access > Egress Policy and select a View. This example uses the
Source View.
5.
Click Add.
6.
The following window opens as shown in Figure 23-37.
23-60
Chapter 23

Figure 23-37
7.
TrustSec Egress Policy Creation
Next click the Source Group down arrow and select the appropriate Source Group created earlier as
depicted in Figure 23-38.
23-61
Chapter 23
Figure 23-38
8.
TrustSec Egress Policy Creation Source SGT
Click the Destination Group down arrow and select the appropriate Source Group as depicted in
Figure 23-39.
23-62
Chapter 23

Figure 23-39
9.
TrustSec Egress Policy Creation Destination SGT
Ensure that the policy status is enabled and select an optional SGACL if necessary as in
Figure 23-40.
23-63
Chapter 23
Figure 23-40
Enabling TrustSec Egress Policy with SGACL
10. Finally define whether the traffic is permitted or denied and click Save as shown in Figure 23-41.
This policy denies all traffic between a source associated with SGT12 and a destination with SGT50.
Note that in Figure 23-41 an SGACL has not been defined. Also note that in creating the policy a
like policy for return traffic denying SGT50 to SGT12 is not created automatically.
23-64
Chapter 23

Figure 23-41
TrustSec Egress Policy Creation Denying Traffic
Once the addition of all egress policies is completed, the definitions can be viewed as a matrix as in
Figure 23-42.
Figure 23-42
Egress Policy Matrix View
The following example output from the command show cts role-based permissions may be used to
verify policies at a Catalyst 6500 once AAA configuration tasks have been completed later in this
document.
ua28-6500-1#sh cts role-based permissions
23-65
Chapter 23
IPv4 Role-based permissions default:

Permit IP-00
IPv4 Role-based permissions from group Unknown to group Unknown:
Permit IP-00
IPv4 Role-based permissions from group 10:SGT10_Campus_Corp to group Unknown:
Permit IP-00
IPv4 Role-based permissions from group 11:SGT11_Campus_Pers_Full to group Unknown:
Permit IP-00
IPv4 Role-based permissions from group 12:SGT12_Campus_Pers_Partial to group Unknown:
Permit IP-00
IPv4 Role-based permissions from group 40:Server_Services_OpenAccess to group Unknown:
Permit IP-00
IPv4 Role-based permissions from group 50:Servers_Corporate to group Unknown:
Permit IP-00
IPv4 Role-based permissions from group Unknown to group 40:Server_Services_OpenAccess:
Permit IP-00
IPv4 Role-based permissions from group 10:SGT10_Campus_Corp to group
40:Server_Services_OpenAccess:
Permit IP-00
IPv4 Role-based permissions from group 11:SGT11_Campus_Pers_Full to group
Permit IP-00
IPv4 Role-based permissions from group 12:SGT12_Campus_Pers_Partial to group
Permit IP-00
IPv4 Role-based permissions from group 40:Server_Services_OpenAccess to group
Permit IP-00
IPv4 Role-based permissions from group 50:Servers_Corporate to group
Permit IP-00
RBACL Monitor All for Dynamic Policies : FALSE
RBACL Monitor All for Configured Policies : FALSE
Device On-boarding, Provisioning, Authentication, and Authorization Policies

for TrustSec in ISE
The final steps for configuring the infrastructure to support role-based policy enforcement involve the
configuration within ISE of the various attributes and conditions required to support:
On-boarding a device within the ISE policy server.
Provisioning the device with the appropriate configuration and credentials to access the network.
Defining authentication and authorization profiles granting the appropriate access to the network.
This completes the configuration for Deployment Scenario 1. If there are no requirements to configure
an SG-FW as in Scenario 2, the next steps are to configure the actual user policies as defined in
Chapter 16, BYOD Limited Use CaseCorporate Devices for corporate devices and Chapter 15,
BYOD Enhanced Use CasePersonal and Corporate Devices for personal devices.
23-66
Chapter 23

TrustSec Policy Configuration Using the ASA and Security Group Firewall in the Data CenterDeployment Scenario 2
TrustSec Policy Configuration Using the ASA and Security

Group Firewall in the Data CenterDeployment Scenario 2
This section provides detailed information regarding configuration of the necessary components that are
unique to Scenario 2 using the ASA firewall within the data center to enforce policies bsed on Security
Group Tags and the SG-FW feature of the ASA.

Whereas Catalyst and Nexus switches can import the PAC file from ISE when authenticating for the first
time, The ASA firewall requires that this process be performed manually. Importing the PAC file to the
ASA establishes a secure communication channel with ISE. After the channel is established, the ASA
initiates a PAC secure RADIUS transaction with ISE and downloads Cisco TrustSec environment data;
specifically, the ASA downloads the security group table. As discussed earlier, the ASA firewall does
not download SGT Policies only the SG tables; the SGT policies will be manually defined at the ASA.
The security group table maps SGTs to security group names. Security group names are created on ISE
and provide user-friendly names for security groups.
The first time the ASA downloads the security group table, it walks through all entries in the table and
resolves all the security group names contained in security policies configured on the ASA; the ASA
then activates those security policies locally. If the ASA is unable to resolve a security group name, it
generates a system log message for the unknown security group name.
One special consideration needs to be kept in mind regarding the ASA and that is if PAC expiration
occurs, a new PAC file will not be automatically downloaded as in the case of Catalyst and Nexus
switches and hence updated SGT tables will not be able to be downloaded. At the time of this writing
(v9.0.2), a new PAC file must be imported manually prior to the expiration of the existing one. If the
ASA cannot download an updated security group table, the ASA continues to enforce security policies
based on the last downloaded security group table until a new PAC file is downloaded and the ASA
downloads an updated table.
The following steps must be completed to define the ASA firewall within ISE as depicted in
Figure 23-43:
1.
2.
Enter the hostname of the ASA firewall.
3.
Enter the IP Address of the interface closest to the ISE server. In the case of the CVD, that happened
to be the Outside Interface as ISE was located in a Shared Services block logically separated from
the data center servers located within protected zones on various inside interfaces of the firewall.
4.
Change the Network Device Location if appropriate.
5.
Configure the RADIUS Shared Secret. This must match that configured on the ASA firewall.
23-67
Chapter 23 BYOD Policy Enforcement Using Security Group Access

Figure 23-43
ASA Network Device General Settings in ISE
Next complete the following steps for TrustSec configuration as depicted in Figure 23-44:
6.
Click the arrow next to Advanced TrustSec Settings
7.
Enter the Device ID.
8.
Enter the password.
9.
Note that none of the other settings for TrustSec Notifications and Updates and Device
Configuration Deployment need to be completed. The TrustSec Environment Data and particularly
the Security Group Tables/Names are downloaded to the ASA either manually or periodically based
on the SXP Reconcile Timer configured at the ASA and covered later. Device Configuration
Deployment is used to update Security Group Policies via CoA from ISE to the device. As TrustSec
policies cannot be dynamically learned and must be manually defined on the ASA, these setting are
not applicable as well.
23-68
Chapter 23

Figure 23-44
ASA TrustSec Settings in ISE
The final task at ISE is to generate an Out of Band PAC for subsequent importing at ISE as depicted in
Figure 23-45:
10. Click the arrow next to Out of Band (OOB) TrustSec PAC.
11. Click the Generate PAC button.
A popup will appear as depicted in Figure 23-46.

The device identity will be pre-populated using the Device ID for TrustSec hostname.
12. Define an arbitrary Encryption Key to be used.
13. Set the PAC Time to Live. Notice that this be configured for Days, Weeks, Months, or Years.
14. Click the Generate PAC button.
A PAC File will now be generated and you will be prompted to download and save the PAC file
locally for later import and use by the ASA firewall.
23-69

Figure 23-45
Generating the TrustSec PAC File for the ASA Firewall at ISE
Figure 23-46
TrustSec PAC File Definition for the ASA Firewall at ISE
This completes the Network Device Definition for the ASA firewall in ISE.
RADIUS Server Configuration on the ASA Firewall

The following configuration steps need to be completed in order to establish the ISE server as a AAA
server for the ASA and importing the TrustSec PAC File used for secure RADIUS exchange of TrustSec
Environment Data and the SGT Tables specifically.
1.
Open ASDM.
23-70
Chapter 23

2.
In ASDM, navigate to Configuration > Firewall > Identity by TrustSec as depicted in

Figure 23-47.
3.
Click the Manage button in the Server Group Setup area.
Figure 23-47
AAA Server Configuration in ASA
A popup window will open as can be seen in Figure 23-48.

4.
Click the Add button.
23-71

Figure 23-48
Configuring AAA Server Groups in ASDM
A popup window opens as seen in Figure 23-49.

5.
Enter a name for the AAA server Group.
6.
Click OK.
Figure 23-49
Adding AAA Server Group in ASA
Once OK has been clicked the popup window closes and the Configure AAA Server Groups
window is populated with the new Server Group as seen in Figure 23-50.
7.
Click the Add button next to the box for Servers in the Selected Group.
23-72
Chapter 23

Figure 23-50
Adding AAA Server to Server Group in ASA
A popup window opens as seen in Figure 23-51.

8.
From the Interface drop-down select the interface closest to the ISE server as that interface's IP
Address will serve as the source address for all RADIUS communications with ISE.
9.
Enter the DNS Hostname or IP Address of the ISE server (PSN).
10. Change the Server Authentication Port to 1812 to match that configured at ISE.
11. Change the Server Accounting Port to 1813 to match that configured at ISE.
12. Enter the RADIUS Server Secret Key and Common Password. These will be the same as the
shared secret key used earlier to define the ASA in ISE.

13. Click OK to add the AAA server to the AAA server Group. If more than one ISE Policy Service
Node exist, repeat steps 10 through 15 to add additional AAA servers.
23-73

Figure 23-51
Adding AAA Server to Server Group
Once the AAA Server Group has been defined it will now be necessary to import the TrustSec PAC File
at the ASA firewall. As depicted in Figure 23-52:
14. Down in the Server Group Setup area, select the correct AAA Server Group in the drop-down.
15. Click Import PAC.
A popup window will open as seen in Figure 23-53.

16. Browse to the location where the file was locally stored when generating the PAC at ISE and use the
password used during PAC File generation.
23-74
Chapter 23

Figure 23-52
Importing TrustSec PAC File at ASA
Figure 23-53
Importing TrustSec PAC at ASA
These final steps should be taken to validate that the PAC file was imported correctly at the ASA and
that the SGT Tables have been downloaded from ISE. Issue the show cts pac command at the ASA
firewall. The output should be as shown in Example 23-1.
Example 23-1 ASA show cts pac Output
bn15-asa/pri/act(config)# show cts pac
PAC-Info:
Valid until: Oct 29 2014 20:31:30
AID:
8ccd74a9731e0fa8305afddec90d0c9f
I-ID:
bn15-asa
A-ID-Info:
PAC-type:
Cisco Trustsec
PAC-Opaque:
000200b000030001000400108ccd74a9731e0fa8305afddec90d0c9f00060094000301
007915c1090d4dc78d2d85649ff9c9469200000013526ec63800093a8038a8f595501c
0137c5d6f55b67230bf77ad5d963a31a6c89d0c31c50e738e6e2fd51d2978dde577e2f
d7cef42b509cf02e937596a93d2f4995a5b080a0682745775cd6396549eaf813f5e040
a8f3413973cfc6de0dc5d1bf9535f2424d29a5c468897145cd498e8f2677a5cec82db1
f4903fd0a0
23-75

bn15-asa/pri/act(config)#
Now check that ASA to ISE communications has been successfully established by issuing the show cts
environment-data command at the ASA. The following output should be seen.
bn15-asa/pri/act(config)# show cts environment-data
CTS Environment Data
====================
Status:
Expired
Last download attempt:
Failed
Environment Data Lifetime: 86400 secs
Last update time:
21:15:29 UTC Nov 7 2013
Env-data expired at:
21:15:29 UTC Nov 8 2013
Env-data refreshes in:
0:00:00:33 (dd:hr:mm:sec)
Retry timer (60 secs) is running
bn15-asa/pri/act(config)#
You can also validate that the TrustSec Environment Data and the SGT Tables have been successfully
downloaded using ASDM as can be seen in Figure 23-54:
17. From ASDM go to Monitoring > Properties > Identity by TrustSec > Environment Data.
18. The Security Group names configured earlier in ISE should be present as seen in Figure 23-54.
23-76
Chapter 23

Figure 23-54
TrustSec Environment Data at ASA
Configuring Security Group Tag Exchange Protocol (SXP) for Wireless

Controllers, Catalyst 3850, and ASA
Campus wireless users accessing the network upon successfully matching an authorization profile at the
Identity Services Engine will be associated with an SGT. Upon successful authentication and subsequent
authorization to the network the Identity Services Engine will pass the appropriate SGT value to the
wireless controller through a RADIUS AV. This SGT value is associated with the IP Address of the
wireless user obtained through the 802.1X authentication and an IP/SGT mapping created at the wireless
controller whether CT-5508, CT-5760, or Catalyst 3850.
In this deployment scenario there is no requirement to configure any links for forwarding of Security
Group Tags nor MACsec. Instead SXP will be used to advertise the IP/SGT mappings created
dynamically at the wireless controllers (network access devices) to the ASA configured as a Security
Group Firewall (SG-FW) as well as those IP/SGT mappings statically created at the Nexus 7000 Data
Center Aggregation switch. Refer to Figure 23-55.
23-77

Whereas the CT-5760 in Scenario 1 did not require SXP as it supports native tagging upon egress from
the controller, SXP will be required for advertisement of the IP/SGT mappings to the ASA SG-FW as
the ASA does not support native tagging and hence will use the SXP mappings when enforcing the
SG-FW rules. Hence in Scenario 2, both the CT-5760 and the CT5508 will have an SXP peering
established to the Catalyst 6500VSS Shared Services switch where the IP/SGT mappings will be
aggreagated and the Catalyst 6500VSS Shared Services switch will then peer to the Nexus 7000 Data
Center Aggregation switches, which will serve to aggregate all campus access mappings.
For campus access serviced by the Catalyst 3850, the C3850 switches will establish an SXP peering with
the associated Catalyst 6500 Distribution switch and the C6500 Distribution switch will then peer to the
Nexus 7000 Data Center Aggregation switches.
The Nexus 7000 Data Center Aggregation switches will have IP/SGT mappings either manually defined
or dynamically created through the static VLAN/SGT mapping. All of these SGT mappings as well as
those learned from both the Catalyst 6500VSS Shared Services and the Catalyst 6500 Distribution
switches will be aggregated and advertised to the ASA SG-FW HA Primary.
SXP is configured on a device by identifying its peers IP address and specifying a password for use in
authenticating each side of the connection. SXP supports two modes which can be used either
exclusively or combined. The first mode is that of the Speaker, which as the name suggests advertises
IP/SGT mappings. The other mode is Listener, which also as its name suggests, listens for the
Speakers advertisements. It is possible for a device to be both a Speaker and a Listener. In this
scenario, both the CT-5760 and the CT-5508 will be in speaker mode advertising the mappings they build
upon wireless device access. The Catalyst 6500 VSS Shared Services and Distribution switches as well
as the Nexus 7000 Data Center Aggregation switches will be in both speaker and listener mode. Finally,
the ASA firewall, although capable of both modes, will only be configured for listener mode, receiving
the advertisements for both wireless users and servers in the data center.
Per Figure 23-55, Table 23-7 summarizes the SXP peering that will be used in the CVD.
Table 23-7
SXP Peering
Device
Role
Intfc
Dst Device
Role
Intfc
CT-5760
Speaker
Lo0
Listener
Lo0
CT-5508
Speaker
NA
Listener
Lo0
Lo0
N7K-Agg-1
Listener
Lo0
Lo0
N7K-Agg-2
Listener
Lo0
Speaker
Lo0
Listener
Lo0
Lo0
N7K-Agg-1
Listener
Lo0
Lo0
N7K-Agg-2
Listener
Lo0
N7K-Agg-1
Speaker
Lo0
Out
N7K-Agg-2
Speaker
Lo0
Out
23-78
Chapter 23

Figure 23-55
SXP Configuration in Deployment Scenario 2
Services
Data Center
DNS
DHCP
Nexus
7000 VPC
DC Core
CT5508
WLCs
CA
AD
Nexus
5000 VPC
DC Agg
CT5760
WLCs
Core
Application and
File Servers
Cisco
ASA
Distribution
Switch
Catalyst
3750-X

SXP Tunnel
Catalyst 3850
Switch Stack
294955
3600 AP Module
3600 AP Module
(802.11ac/n)
(802.11ac/n)
CAPWAP
CAPWAP
CT-5508 Wireless Controller Configuration

Access the wireless controller via a web UI and follow these steps:
1.
Navigate to Security > TrustSec SXP.

The screen in Figure 23-56 appears.
2.
Click the drop down arrow for SXP State and select Enabled.
3.
Set the default Password. This must match that configured on its peer.
4.
Click New (top right).
5.
Fill in the IP Address (typically Loopback if possible) of the SXP Peer or the Shared Services
Catalyst 6500VSS switch.
6.
Click Apply.
23-79

Once successfully configured, the screen in Figure 23-57 should be presented upon accessing Security
> TrustSec SXP. The Connection Status will indicate Off until the other device is configured.
Figure 23-56
SXP Configuration at Wireless Controller
Figure 23-57
SXP Configuration Complete
CT-5760 Wireless Controller Configuration

The following is the configuration of the 5760 Wireless LAN Controller for SXP Connection to the
Catalyst 6500 VSS Services switch:
23-80
Chapter 23

cts
cts
cts
cts
sxp
sxp
sxp
sxp
enable
default source-ip 10.225.48.2
default password 7 11270A0C03175A5E577E7E
connection peer 10.225.100.5 password default mode peer listener hold-time 0
Issuing the command show cts sxp connection results in the following output.
bn16-wlc5760-1#show cts sxp connections
SXP
: Enabled
Highest Version Supported: 4
Default Password : Set
Default Source IP: 10.225.48.2
Connection retry open period: 120 secs
Reconcile period: 120 secs
---------------------------------------------Peer IP
: 10.225.100.5
Source IP
: 10.225.48.2
Conn status
: On
Conn version
: 4
Conn capability : IPv4-IPv6-Subnet
Conn hold time
: 120 seconds
Local mode
: SXP Speaker
Connection inst# : 1
TCP conn fd
: 1
TCP conn password: default SXP password
Keepalive timer is running
Duration since last state change: 0:02:07:48 (dd:hr:mm:sec)
Catalyst 6500 SXP Configuration

The following commands are used at the Shared Services Catalyst 6500 VSS to enable SXP peering from
the 6500 to Data Center Core:
cts sxp enable
cts sxp default source-ip 10.225.100.5
cts sxp default password 7 072132455A0C485744465E
cts sxp connection peer 10.225.43.2 password default mode
CT5508
center-agg1
Center Agg2
5760
peer speaker hold-time 0 0 /

peer listener hold-time 0 /Data
peer listener hold-time 0 /Data
peer speaker hold-time 0 0 / CT
Issuing the command show cts sxp connection results in the following output:
bn2-6500-1#show cts sxp connections
SXP
: Enabled
---------------------------------------------Peer IP
: 10.225.100.8
Source IP
: 10.225.100.51
Conn status
: On
23-81

Conn version
: 1
Local mode
: SXP Speaker
TCP conn fd
: 1
---------------------------------------------Peer IP
: 10.225.100.9
Source IP
: 10.225.100.51
Conn status
: On
Conn version
: 1
Local mode
: SXP Speaker
TCP conn fd
: 2
---------------------------------------------Peer IP
: 10.225.101.46
Source IP
: 10.225.100.51
Conn status
: On
Conn version
: 4
Conn hold time
: 120 seconds
Local mode
: SXP Listener
TCP conn fd
: 4
Hold timer is running
---------------------------------------------Peer IP
: 10.225.101.47
Source IP
: 10.225.100.51
Conn status
: On
Conn version
: 4
Conn hold time
: 120 seconds
Local mode
: SXP Listener
TCP conn fd
: 3
3850 SXP Configuration

The following commands are used at the 3850 converged access switch to enable SXP peering to the
6500 Distribution switch:
cts
cts
cts
cts
sxp
sxp
sxp
sxp
enable
default source-ip 10.225.102.186
default password 7 0475180F1B241D1C5A4D50
connection peer 10.225.100.101 password default mode peer listener hold-time 0
23-82
Chapter 23

6500 VSS Distribution Switch

The following commands are used the 6500 VSS Distribution switch to enable SXP peering to the data
center aggregation switches:
cts sxp enable
cts sxp default source-ip 10.225.100.101
cts sxp default password 7 0475180F1B241D1C5A4D50
cts sxp connection peer 10.225.100.8 password default mode peer listener hold-time 0
Center Agg 1
cts sxp connection peer 10.225.100.9 password default mode peer listener hold-time 0
Center Agg2
cts sxp connection peer 10.225.102.186 password default mode peer speaker hold-time
Converged Access switch 1
Converged Access Switch 2
Converged Access Switch 3
/Data
/Data
0 0 /
0 0 /
0 0 /
bn5-6500-1#show cts sxp connections

SXP
: Enabled
---------------------------------------------Peer IP
: 10.225.100.8
Source IP
: 10.225.100.101
Conn status
: On
Conn version
: 1
Local mode
: SXP Speaker
TCP conn fd
: 2
---------------------------------------------Peer IP
: 10.225.100.9
Source IP
: 10.225.100.101
Conn status
: On
Conn version
: 1
Local mode
: SXP Speaker
TCP conn fd
: 1
---------------------------------------------Peer IP
: 10.225.102.186
Source IP
: 10.225.100.101
Conn status
: On
Conn version
: 4
Conn hold time
: 120 seconds
Local mode
: SXP Listener
TCP conn fd
: 4
23-83

---------------------------------------------Peer IP
: 10.225.102.187
Source IP
: 10.225.100.101
Conn status
: On
Conn version
: 4
Conn hold time
: 120 seconds
Local mode
: SXP Listener
TCP conn fd
: 5
---------------------------------------------Peer IP
: 10.225.102.197
Source IP
: 10.225.100.101
Conn status
: On
Conn version
: 4
Conn hold time
: 120 seconds
Local mode
: SXP Listener
TCP conn fd
: 3

bn5-6500-1#
Nexus 7000 SXP Configuration

The following steps are required to configure the SXP connection between the data center aggregation
switches and the ASA firewall:
cts sxp enable/Enables SXP on the Nexus 7000
cts sxp default password 7 Qomyw12345
cts sxp default source-ip 10.225.100.9 / default interface
cts sxp connection peer 10.225.48.2 password default mode speaker vrf default /c5760
cts sxp connection peer 10.225.100.5 password default mode speaker vrf default / c6500 VSS
Shared Service switch
cts sxp connection peer 10.225.100.18 password default mode speaker vrf default
cts sxp connection peer 10.225.100.51 password default mode speaker vrf default /c6500
dist'n switch
cts sxp connection peer 10.225.100.101 password default mode speaker vrf default / c6500
VSS Distribution switch
cts sxp connection peer 10.230.3.4 password default mode listener vrf default /ASA
Firewall
The interesting thing to observe above is the fact that the Nexus aggregation switch has peer relations to
the C5760 Wireless LAN controller, 6500 VSS Distribution switch, and ASA Firewall. The SXP
neighbor type is Speaker for C5760 and 6500 VSS that implies that the Nexus switch is listening to
the tags, whereas the SXP neighbor relationship to ASA is Listener meaning that the Nexus Switch is
a speaker and ASA is in the listener state.
23-84
Chapter 23

ASA SXP Configuration

The following steps are required to configure the SXP connections between the ASA firewall and Nexus
7000 Data Center Aggregation switch and the ASA firewall and Shared Services Catalyst 6500 VSS
switch. Refer to Figure 23-58.
1.
Using ASDM to access the ASA firewall, navigate to Configuration > Firewall > Identity by
TrustSec.
2.
Check the box Enable SGT Exchange Protocol (SXP).
3.
Enter the Default Source IP Address the firewall will use. In the CVD, the Outside Interface is the
one accessible to the Nexus 7000 and so it was chosen. Note that this IP Address must match that
previously configured on the Nexus and Catalyst switches as their peer address on the firewall.
4.
Configure and confirm the password to be used to establish the secure SXP connection. Note that
this password must match that used to configure the SXP connection on the Nexus and Catalyst
switches previously configured.
5.
Click Add.
23-85

Figure 23-58
Configuring SXP on the ASA
The popup window in Figure 23-59 appears when Add is clicked.

Figure 23-59
6.
Adding SXP Peers at the ASA
Enter the Peers IP Address. This must be the same one specified as the source interface at the Nexus
or Catalyst switches.
23-86
Chapter 23

7.
For Password, select Default this is the password configured in Step 4 above.
8.
For Mode select Peer from the drop down box.
9.
For Role select Speaker. This defines the peer as a Speaker and the ASA as a Listener.
10. Add both Shared Services Catalyst 6500 VSS and Nexus 7000 Data Center Aggregation Switches
as SXP Peers.
Once completed, the ASA Identity by TrustSec window should appear as in Figure 23-60. The two
entries that were configured can now be seen in the window.
Figure 23-60
SXP Configured on ASA
In order to check the status of the SXP connections navigate to Monitoring > Properties > Identity by
TrustSec > SXP Connections and the status of the connections can be seen as in Figure 23-61.
Figure 23-61
Checking Status of SXP at ASA
23-87

Configuring SG-FW Role-Based Policies at ASA

In Deployment Scenario 1 Egress Policies created at ISE were used almost exclusively for policy
enforcement via SGACLs dynamically pushed to the Shared Service Catalyst 6500 VSS and Nexus 7000
Data Center Aggregation Switches in the infrastructure. When using an ASA, running v9.0(2) or higher
software as a Security Group Firewall, these policies must be created on the ASA through CLI or ASDM.
In order to create these role-based access policies, the SG Names and Tag Values must be first
downloaded to the ASA prior to use in a policy. This is accomplished through the previous configuration
steps and subsequent importing of the ISE TrustSec PAC file to be used in these exchanges competed
earlier.
The table in Figure 23-62 reflects the policy that will be configured at the ASA firewall. One aspect of
SG-FW configuration on the ASA is that role-based policies can be created that permit or deny
communications between SGT that have been defined or Unknown (SGT 0). Additionally, on the ASA,
it is possible to create policies with IP Addresses or network objects as the source or destination. This
offers an extremely powerful configuration capability that is different than the Catalyst or Nexus
switches where SGACLs are defined using the SGT values for source and destination without support of
IP Addresses.
Very much like the Catalyst and Nexus switches as discussed in the Deployment Scenario 1 section, the
ASA also supports the Unknown SGT value of SGT 0. A key concept to be considered when granting
access to the data center is that of the SGT value of zero or Unknown as it is referred to. If the IP
Address of a server has not been mapped to an SGT at the point of IP/SGT mappings such as the Nexus
7000 in the data center, that server would be considered Unknown and associated with SGT0. Unlike
SGACLs when implemented on a switching platform where an implicit permit to Unknown is permitted,
the ASA or IOS ZBFW acting as a SG-FW still enforces an implicit deny. Policies can however be
created on the ASA SG-FW that permit or deny access to Unknown from any give source SGT. and
thus can be used to support a migrational approach to tag assignment in the data center.
Between the ability to use Unknown and IP Addresses/Network Objects in role-based policies, the
ASA offers an excellent platform supporting a migrational approach to implement TrustSec in the data
center.
Figure 23-62
SGT5
SG-FW Policy to be Configured on ASA Firewall
SGT10
SGT11
SGT12
SGT40
SGT50
SGT80
Unknown
SGT5
SGT10
SGT11
SGT12
SGT40
SGT50
Unknown
23-88
294984
SGT80
Chapter 23

Note
demonstration purposes only as much more granular policies would be defined for network access. For
example, it would be assumed that rather than providing all employees (SGT10) access to infrastructure,
a group associated with network administrators would be defined and only those users would have access
to SGT5 devices. In the case of unknown, it cannot be assumed that all network administrators have been
migrated to the TrustSec Domain and hence once entering will be associated with SGT00 or unknown.
As such other security measures would naturally be required restrict access to these devices such as
ACLs or user credentials.
information but all AAA communications as well.
Also note from Figure 23-62 that SGT 80, which has been reserved for use with the policy static
interface commands, is denied access to network infrastructure with a device SGT 5. Also with regard
to SGT80 permissions, refer to TrustSec Link Policy for the rationale why SGT80 must be permitted to
all other SGT values during migration.
The ASA firewall in Scenario 2 has been configured with three Layer 3 interfaces named Outside,
SGT40, and SGT50. This configuration illustrates that a migration from a policy based on IP Addresses
can easily be migrated to one based on SGT with only the need to add those new policies while still
enforcing existing policies.
To configure role-based policies in the ASA, use ASDM as seen in Figure 23-63.
23-89

Figure 23-63
ASDM Role-based Policy Configuration
1.
Navigate to Configuration > Firewall > Access Rules.
2.
Highlight the desired interface to create the access rule on and click Add. A drop down box will
open as can be seen in Figure 23-64.
3.
Click Add ACL.

A popup window will open up.
4.
From the Interface drop-down box, select the appropriate interface. In this example it will be the
Outside interface as this will demonstrate the creation of a policy for user access to the data center.
23-90
Chapter 23

5.
Click the browse button next to the Source Security Group box.
Figure 23-64
Adding an Access Rule at the ASA
A popup window opens as in Figure 23-65.

6.
Select the appropriate Security Name from the Security Group window.
7.
Click Add and the selected name will populate the Selected Security Group box on the right.
8.
Click OK.
23-91

Figure 23-65
Adding a Source Group to an Access Rule at the ASA
A new window will open as depicted in Figure 23-66.

9.
Select the appropriate action; Permit or Deny.
10. Click the browse button next to the Destination Security Group box.
23-92
Chapter 23

Figure 23-66
Adding Destination Group to Access Rule on ASA
A new popup window opens as in Figure 23-67.

11. Select the destination groups for the policy. In this case three groups have been selected;
Server_Services_OpenAccess, Servers_Corporate, and Unknown.

12. Click Add and the selected name will populate the Selected Security Group box on the right.
13. Click OK.
23-93

Figure 23-67
Adding a Destination Group to an Access Rule at the ASA
You will be returned to the Add Access Rule window and can see that Source and Destination
Security Group boxes have been populated as seen in Figure 23-68.
14. Click OK. You will be returned to the Access Rule main window.
15. Continue adding additional policies as appropriate.
23-94
Chapter 23

Figure 23-68
Finalizing New Access Rule
Having completed the addition of all of the necessary policies, the Access Rules will appear similar to
the example in Figure 23-69, as can be seen from the example below:
1.
Outside InterfaceSGT 10 can access Unknown, Servers_Corporate,

Server_Services_OpenAccess, SGT80_Interface (Web Access), and Any. Obviously, rather than
specifying the SG Names of the servers, ANY would have sufficed.
2.
Outside InterfaceSGT 11 can access Unknown, Servers_Corporate,

Server_Services_OpenAccess, and SGT80_Interface.
3.
Outside InterfaceSGT 12 cannot access 10.230.4.22, which is mapped to SGT 40.
4.
Outside InterfaceSGT 12 can access Server_Services_OpenAccess (SGT 40) and

SGT80_Interface.
5.
Outside InterfaceSGT12 cannot access Unknown and Servers_Corporate.
6.
Outside InterfaceDevices that are not associated with an SGT can get to any server. This may be
undesirable and should be examined closely prior to implementing this rule. Essentially, it permits
any device to access any server internally.
7.
The SGT 40 Layer 3 interface has a higher priority of fifty as opposed to zero for the Outside
interface, therefore an implicit permit exists for traffic sourced from SGT 40 to the Outside by
default.
8.
SGT 50 InterfaceCannot access SGT5 and SGT12 but can access everything else.
23-95

Figure 23-69
SG-FW Access Rules
In Figure 23-70, by navigating to Configuration > Firewall > Advanced > ACL Manager, the Access List
names (access-groups within the CLI configs) can be seen with the associated ACEs assigned. Of
particular interest is the first ACL outside_access_in. This is automatically created when the SXP
peering is defined to allow the session be established to the outside interface.
Figure 23-70
Access Lists with Assigned ACEs
This completes the configuration for Deployment Scenario 2. The next steps will be to configure the
actual user policies as defined in the Limited Use Case in the CVD for corporate devices and the
Enhanced Use Case for personal devices.
23-96
Chapter 23

Device On-boarding, Provisioning, Authentication, and

Authorization Policies for TrustSec in ISE
The final steps for configuring the infrastructure to support role-based policy enforcement involve the
configuration within ISE of the various attributes and conditions required to support:
On-boarding a device within the ISE policy server.
Provisioning the device with the appropriate configuration and credentials to access the network.
Defining authentication and authorization profiles granting the appropriate access to the network.
This completes the configuration for Deployment Scenario 1. If there are no requirements to configure
an SG-FW as in Scenario 2, the next steps are to configure the actual user policies as defined in
Chapter 16, BYOD Limited Use CaseCorporate Devices for corporate devices and Chapter 15,
BYOD Enhanced Use CasePersonal and Corporate Devices for personal devices.
23-97

23-98
CH AP TE R
24
Mobile Traffic Engineering with Application

Visibility and Control (AVC)
Whats New: The following sections have been added to this chapter:
AVC Protocol Packs (Featuring Cisco Jabber Support)
Converged Access Application Visibility
Converged Access AVC Configuration via CLI
Converged Access AVC Configuration via GUI
Converged Access AVC Monitoring via CLI
Executive Summary
Mobile wireless traffic is soon about to exceed wired traffic on a global basis and is comprised mainly
of mobile video applications. Furthermore, the devices generating wireless traffic are shifting away from
traditional laptops towards smartphones and tablets. As such, the volume, composition, and device-shift
of mobile application traffic can pose a challenge to network administrators tasked with ensuring their
quality.
Business use cases for managing mobile applications include:
Improving the quality of wireless voice from cellular-quality to toll-quality
Enhancing the quality of experience for wireless video applications
Expediting the response times for business critical data applications over wireless devices
Managing background application traffic by preventing bulky traffic flows from monopolizing
bandwidth away from more transaction-oriented flows, thus further improving user productivity
Controlling non-business applications on wireless networks, including social networking

applications, video and media-downloading applications, peer-to-peer sharing applications, gaming
applications, etc.
This document presents design considerations relating to wireless (and wired) network quality
management by overviewing the underlying technologies involved and showing how these interact to
create an end-to-end solution.
24-1
Chapter 24
Executive Summary
However, the main theme of this document is detailed design guidance on best-practice Quality of
Service (QoS) configurations for Cisco Wireless LAN Controllers (highlighting the new Cisco
Application Visibility and Control feature) as well as for network switches to achieve the business use
cases for mobile application management.
24-2
Chapter 24


Mobile application traffic is continuing to explode. According to Ciscos Visual Networking Index
Forecast, global mobile data traffic will grow 13-fold from 2012 to 2017.1
Additional key trends relating to mobile devices, applications, and traffic include:
By 2014, wireless IP traffic will exceed wired (and will exceed 60% by 2016).2
By 2016, the number of mobile-connected devices will exceed three-times the worlds population.3
By 2016, non-PC devices (such as smartphones and tablets) will generate 30% of all IP traffic.4
By 2017, tablets will account for more than 12% of global mobile data traffic.5
By 2017, mobile video will represent two-thirds of all mobile data traffic.6
By 2017, 45% of global mobile data traffic will be offloaded to fixed networks via WiFi or
femtocell.7
Therefore (non-PC) mobile devices will generate exponentially more traffic in the coming years, with
the bulk of this traffic traversing wireless networks and with the traffic itself being primarily composed
of video applications.
Since QoS is critical to the overall Quality of Experience (QoE) of video-based applications, network
administrators need to concern themselves with ensuring that the applications traversing their
networksespecially their wireless LANs (where the majority of traffic will be sourced from)is being
adequately provisioned.
1. Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update, 2012-2017
http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/white_paper_c11-520862.
pdf
2. Cisco Visual Networking Index: Forecast and Methodology, 2011-2016
pdf
pdf
pdf
pdf
pdf
pdf
24-3
Chapter 24
Business use-cases for wireless application quality include:
Guaranteeing voice quality from wireless applications meets enterprise VoIP requirements. For
example, independent third-party testing has shown that wireless VoIP quality over congested
wireless networks can be improved from a Mean Opinion Score (MOS) of 3.92 (which is considered
cellular quality) to 4.2 (which is considered toll quality) by applying the recommendations detailed
later in this document.1
Ensuring video applicationsboth interactive and streamingare delivered to/from wireless

devices with a high Quality of Experience, so that users can communicate and collaborate more
efficiently and effectivelyregardless of their location or device. As another example, the same
testing has shown video quality to improve from Good (9 fps) to Excellent (14 fps) after respective
policies were deployed.2
Provisioning preferred services for business-critical applications running on wireless devices, such
as Virtual Desktop applications, sales applications, customer relationship management (CRM)
applications, and enterprise resource planning (ERP) applications, etc. Yet another example has
shown Citrix traffic latency to decrease by a factor or 7 (from 14 ms to 2 ms) when properly
provisioned over the wireless network.3
De-prioritizing background application traffic (i.e., applications that send data to/from servers,
rather than directly to other users and which do not directly impact user-productivity), such as email,
file-transfers, content distribution, backup operations, software updates, etc.
Identifying, de-prioritizing (or dropping) non-business applications, which can include social
networking applications, peer-to-peer file-sharing applications and type of entertainment and/or
gaming applications so that network resources are always available for business-oriented
applications.
A key facilitating technology for identifying and managing application traffic over wireless networks to
meet these business use case requirements is the Cisco Application Visibility and Control (AVC) feature
for Cisco Wireless LAN Controllers, which is discussed next.
Cisco Application Visibility and Control (AVC) for Wireless LAN

Controllers
Beginning with Cisco WLC software release 7.4, the Application Visibility and Control set of
featuresalready supported on Cisco routing platforms, like ASR 1000s and ISR G2sbecame
available on WLC platforms, including the Cisco 2500, 5500, 7500, 8500 WLCs, and WiSM2 controllers
in central switching mode.
The AVC feature set increases the efficiency, productivity, and manageability of the wireless network.
Additionally, the support of AVC embedded within the WLAN infrastructure extends Ciscos
application-based QoS solutions end-to-end.
1. Syracuse University: Network Technology Performance Evaluation Cisco Application Visibility and Control
(AVC) (February 1, 2013)
http://www.cisco.com/en/US/prod/collateral/wireless/cisco_avc_application_improvement.pdf
24-4
Chapter 24

AVC includes these components:
Next-generation Deep Packet Inspection (DPI) technology called Network Based Application
Recognition (NBAR2), which allows for identification and classification of applications. NBAR is
a deep-packet inspection technology available on Cisco IOS based platforms, which includes
support of stateful L4-L7 classification.
QoSAbility to remark applications using DiffServ, which can then be leveraged to prioritize or
de-prioritize applications over both the wired and wireless networks.
A template for Cisco NetFlow v9 to select and export data of interest to Cisco Prime or a third-party
NetFlow collector to collect, analyze, and save reports for troubleshooting, capacity planning, and
compliance purposes.
These AVC components are shown in Figure 24-1.

Cisco AVC Components
Gold
Traffic
Silver
Bronze
NBAR LIBRARY
Deep Packet Inspection
POLICY
Packet Mark and Drop
NetFlow Cache
Inspect Packet
Platinum
NetFlow
Key Fields
Source IP address
Destination IP address
Source Port
Destination port
Layer 3 protocol
TOS byte (DSCP)
Input Interface
Flow Information
Packets
Bytes/packets
Address, ports...
...
11000
1528
Create a Flow from the Packet Attributes
NETFLOW (STATIC TEMPLATE)

provides Flow Export
294011
Figure 24-1
AVC on the WLC inherits NBAR2 from Cisco IOS that provides deep packet inspection technology to
classify stateful L4-L7 application classification. This is critical technology for application
management, as it is no longer a straightforward matter of configuring an access list based on the TCP
or UDP port number(s) to positively identify an application. In fact, as applications have
maturedparticularly over the past decadean ever increasing number of applications have become
opaque to such identification. For example, HTTP protocol (TCP port 80) can carry thousands of
potential applications within it and in todays networks seems to function more as a transport protocol,
rather than as the OSI application-layer protocol that it was originally designed as. Therefore, to identify
applications accurately, Deep Packet Inspection technologiessuch as NBAR2are critical.
Once applications are recognized by the NBAR engine by their discrete protocol signatures, it registers
this information in a Common Flow Table so that other WLC features can leverage this classification
result. Features include QoS, NetFlow, and Firewall features, all of which can take action based on this
detailed classification.
Thus AVC provides:
Application Visibility on the Cisco WLC by enabling Application Visibility for any WLAN
configured. Once Application Visibility is turned on, the NBAR engine classifies Applications on
that particular WLAN. Application Visibility on the WLC can be viewed at an overall network level,
per WLAN or per client.
Application Control on the Cisco WLC by creating a AVC profile (or policy) and attaching it to a
WLAN. The AVC Profile supports QoS rules per application and provides the following actions to
be taken on each classified application: Mark (with DSCP), Permit (and transmit unchanged) or
Drop.
24-5
Chapter 24 Mobile Traffic Engineering with Application Visibility and Control (AVC)
Key business use cases for AVC include:
Classifying and marking wireless mobile device applicationsIdentifying and differentiating

realtime voice, video, or business-critical applications from less important, but potentially
bandwidth-hungry-applications so as to prioritize, de-prioritize, or drop specific application traffic.
Capacity planning and trendingBaselining the network to gain a clearer understanding of what
applications are consuming bandwidth and trending application usage to help network
administrators plan for infrastructure upgrades.
To better understand how AVC works in WLAN scenarios, an overview of the challenges and tools for
managing quality of service over wireless media may be helpful (and is discussed next, along with a
summary of the overall strategic recommendations for deploying quality of service policies across an
enterprise). Network administrators already familiar with these concepts may find it more efficient to
skip the following sections and to proceed directly to Configuring Downstream QoS Policies for Mobile
Applications and Configuring Upstream QoS Policies for Mobile Applications.
Challenges and Solutions for Managing Application Quality

over Wireless Media
To better understand design recommendations available for managing application quality over wireless
media, it is beneficial to lay some context as to the challenges and solutions available for managing
traffic over this media. To begin with, it should be noted that the very nature of wireless as a transmission
media makes it less predictable and controllable from a quality perspective, as compared to wired
networks.
For example, wired campus networks operate at full-duplex mode, with endpoints being able to transmit
data at any time at maximum capacity. For example, a server connected to a switch by a 1 Gbps
full-duplex link can theoretically both send and receive at 1 Gbps of data simultaneously, without having
to contend with other stations for access to the medium.
Wireless networks, on the other hand, operate in half-duplex mode, with endpoints contending among
themselves as well (as with the wireless access point) for the opportunity to transmit data. This is
because in WLANs, every station associated to a particular access point (AP) must share the radio
frequency (RF) with all the other stations; however, only one stationincluding the AP itselfmay
transmit at a given time. The result of this is that each station must contend with all the other stations for
airtime. WLANs are-by definition-a multiple-access, broadcast medium, meaning that if more than one
station transmits at any one time, no other station is able to understand what has been transmitted. Put
another way, if two (or more) stations began transmitting data simultaneously over a WLAN, this would
result in a collision. This limitation means that to avoid RF interference, full-duplex is simply not
possible in WLANs (if both transmitting and receiving are performed on the same channel, as is the case
in most WLAN deployments). Before quality can even be addressed over WLANs, the first requirement
is finding a solution to avoiding collisions over wireless media.
IEEE 802.11 Distributed Coordination Function (DCF)

A baseline understanding of the Distributed Coordination Function (DCF)operating at the 802.11
MAC layer (which is responsible for scheduling and transmitting Ethernet frames onto the wireless
medium)is essential to understanding the subsequent enhancements that allow for wireless quality of
service.
DCF has the following key components, which are briefly described below:
24-6
Chapter 24

Collision Sense Multiple Access/Collision Avoidance (CSMA/CA)
Short Interframe Space (SIFS)
DCF Interframe Space (DIFS)
Contention Window (CW)
Collision Sense Multiple Access/Collision Avoidance (CSMA/CA)

Wi-Fi wireless networks are completely egalitarian, meaning that all wireless stations have equal access
to the medium. In fact, even the AP has no more priority to access the medium than the client stations
do. For example, a wireless IP phone has to abide by exactly the same principles as a wireless laptop,
regardless of the fact that one of them might be transmitting real-time VoIP traffic and the other might
be transmitting peer-to-peer (P2P) traffic. Since each client, and thus each application, has an equal
opportunity to transmit frames at any given time, there must be an orderly system to coordinate the
transmission of packets onto the medium. If no control were implemented, there would be a high
probability of a collision. Additionally, the more clients associated to the AP, the higher the likelihood
of collisions occurring. Furthermore, each time a collision occurs, stations would reattempt their
transmissions, likely causing additional collisions in the process.
A similar problem existed in the early days of wired Ethernet, when half-duplex links and hubs were
common. In half-duplex wired Ethernet environments collisions were a common outcome of multiple
end-stations trying to transmit frames onto the wire at the same time. To address this situation, a system
called Carrier Sense Multiple Access/Collision Detection (CSMA/CD) was developed. CSMA/CD is a
set of rules that all end stations are required to follow when trying to transmit a frame onto the medium.
For example, if a collision occurred, the stations involved in the collision would follow a strict set of
backoff rules, involving random timers that help to reduce the probability of a future collision next time
round. CSMA/CD thus proved a relatively effective mechanism to reduce collisions on half-duplex
Ethernet networks.
Note
While CSMA/CD worked well enough, the problem of collisions was to be obviated altogether in wired
networks by introducing switching technology, which provided dedicated collision domains to each
network segment. In this manner, no endpoint contended for media access with any other endpoint, as
each had a dedicated collision domain between itself and the switch and as such could then operate at
full-duplex capacity.
However while it may seem that CSMA/CD might likewise be applicable to wireless networks, there is
a key difference: wireless stations have no way to detect a collision.
In a wired network, transmissions are sent as bursts of energy on the wire that can be reflected back to
the end stations, thus allowing accurate detection of collisions. In a wireless medium, the RF energy is
shared over the air, meaning reflections of the energy wave do not come back to the sending station, thus
making collision detection impossible; hence CSMA/CD is an impractical approach for WLANs.
Notwithstanding this, the IEEE modified the CSMA/CD mechanism to accommodate wireless networks,
as Carrier Sense Multiple Access/Collision Avoidance (CSMA/CA). The techniques differ in that
CSMA/CD deals with what to do after a collision occurs, whereas CSMA/CA works to prevent a
collision in the first place.
To understand this better, consider a person participating in an audio conference call. If many people are
on the call together, there is a good chance that one person may begin talking at the same time as another,
making both of them unintelligible to everyone else (effectively, a collision). If the parties used a
CSMA/CD approach, they would pause for a few seconds and then try talking again in the hopes that
they would not again talk at the same time, so that at least one of them could be understood. On the other
24-7
hand, if the parties were following a more polite CSMA/CA approach, then instead of simply starting to
talk on the conference call (while hoping that no one else would at the same time), each party would wait
patiently for a quiet period. Then, when they were certain that no one else was talking, they would begin.
Additionally, the other parties would recognize and respect that one party was talking and would remain
silent until they had completed speaking (without interruption).
Thus CSMA/CA opts to listen to the channel first to see if any transmissions are in progress and only
when the channel is free does it attempt to send its frame. If a collision does occur even after listening
and waiting, the wireless station deals with it in a similar way to CSMA/CD, by waiting for a random
backoff period before it tries to resend the frame.
However it is important to note that CSMA/CA can never fully guarantee that a collision wont occur;
rather, it reduces the probability that a collision will occur by trying to avoid a future collision.
CSMA/CA is a bit like arriving in your car at a four-way stop at the same time as three other drivers.
Although you might try very hard to avoid a collision by looking both ways very carefully before driving
into the intersection, you can never fully guarantee what the other driver will do. If you make a decision
to proceed, there is always a slight possibility that the other driver might do the same thing at the same
time and thus there is always the possibility of a collision. The same goes for WLAN stations that operate
using CSMA/CA.
Short Interframe Space (SIFS)

So how does a sending station know that its transmission succeeded? Since, due to the broadcast nature
of the wireless medium, collisions cannot be detected (they can only be avoided with a measure of
probability), there is an obvious need to confirm whether a transmission was successful. To solve this
problem, DCF ensures that each frame is acknowledged once the transmission is successfully received.
Specifically, there is a provision in DCF where all clients keep silent after a transmission finishes so the
receiving station has a chance to send the acknowledgement. This is period is called the Short Interframe
Space (SIFS). This ensures that the transmitting station knows that it does not need to retransmit and it
can move on to its next frame.
DCF Interframe Space (DIFS)

To help control and organize the transmission of frames on the wireless medium, DCF uses some clever
rules whereby the contending stations wait for different periods of time before they can transmit their
frames onto the channel. A central and key concept to how DCF operates is the DCF Interframe Space
(DIFS). DIFS is a pre-established, fixed wait timer observed by all stations before they attempt
transmission of a frame onto the channel.
Note
There are actually several Interframe Space (IFS) types used in 802.11 networks; however, for the
purposes of this discussion attention is focused only on SIFS and DIFS.
As mentioned, CSMA/CA provides a framework of listen before you talk for wireless stations. When
a wireless station wants to transmit a frame, the first thing it does is to wait the appropriate DIFS time.
Once this DIFS countdown has finished, if the medium is still clear, it transmits. DIFS is like a level set
for all stations that want to transmit. If they all just started transmitting as soon as they had a frame in
the queue, collisions would be plentiful. By waiting the DIFS period it gives a chance for the station to
confirm that the channel is indeed clear for transmission.
Figure 24-2 shows the operation of Interframe Spaces (SIFS and DIFS) within DCF.
24-8
Chapter 24

Figure 24-2
Interframe Spaces Operation
DIFS
Contention window
SIFS
Busy medium
Backoff window
Next frame
(t)
Defer access
Select slot and decrement backoff

as long as the medium is idle
294169
Slot time
Contention Window (CW)

However, it may be the case that after waiting for the DIFS period to expire, the DCF process detects the
medium is not idle. If this is the case, the station waits (technically speaking the station will defer) for
a random period of time, called the contention window (CW). The first time a station needs to defer, the
CW random backoff period is set from 0 to a maximum value known as CWmin. There is an obvious
advantage to waiting a random period of time, for if multiple stations are all trying to transmit at the
exact same time because a collision occurred and they all backed off for the same length of time,
collisions would continually occur. After the CW timer expires the station again looks to see if the
medium is free and if it is, it begins transmission.
However, if after the CW timer expires the sending station detects that the medium is still not clear, then
it will:
Defer again until the wireless medium is finally clear.
Wait again for the DIFS period.

Then:
Wait for another (longer) backoff period.
At first, the station doubles the CW value it used previously. However, if the station continually finds
that the medium is not clear, then the station will continue to double the backoff window each time it
tries to send the frame. It keeps on doing this up to a maximum amount of time, known as the CWmax
value. This continues until it either it transmits the frame or the Time to Live (TTL) expires.
The amount of time that the station counts down is not actually measured in seconds, but rather in slot
times. The slot time is a time value derived from the RF characteristics of the radio network and so it is
unique for each network (but the actual length of these times is in microseconds, with 802.11 specifying
about 20 microseconds for a slot time). As an example, in the case of IEEE 802.11n, the CWmin default
is 15 slot times (~300 s or 0.3 ms) and CWmax is 1023 slot times (~20,460 s or 20.46 ms).
Due to the variable nature of contention windows, it is easy to see how significant amounts of delay
variation (jitter) can be introduced into the packet flows. Figure 24-3 illustrates Contention Window
Operation.
24-9
Figure 24-3
Contention Window Operation
1023 1023 1023
511
CWmax
255
63
31
retries
294170
127
CWmin
To illustrate how this works, if the random backoff for a station was initially set to 10 slot times, the
second backoff would be 20. If the channel is still busy, the CW backoff is increased to 40, then 80, then
160, then 320, and finally 640 (as 640 doubled would exceed the CWmax value of 1023 slot times). At
this point, if the frame has not been sent, the process begins again. These retries continue until the packet
TTL is reached. This process of doubling the backoff window is referred to as binary exponential
backoff.
DCF Operation
Consider an example of the DCF process might apply to a real world contention scenario. As illustrated
in Figure 24-4, five stations associated to the same AP and all are trying to send data at approximately
the same time.
24-10
Chapter 24

Figure 24-4
DCF Operation
DIFS
Station A
DIFS
Frame
Station B
Station C
DIFS
Defer
Defer
Station D
Defer
Station E
Frame
Defer
Defer
Frame
Frame
Defer
Defer
Defer
294171
Backoff time
Backoff time remaining
The DCF operation steps illustrated in Figure 24-4 are as follows:

Step 1
Station A successfully sends a frame; three other stations also want to send frames, but must defer to
Station A traffic.
Step 2
After Station A completes the transmission, all the stations must still defer to the DIFS. When the DIFS
is complete, stations waiting to send a frame can begin to decrement the backoff counter, once every slot
time, and can send their frame.
Step 3
The backoff counter of Station B reaches zero before Stations C and D, and therefore Station B begins
transmitting its frame.
Step 4
When Station C and D detect that Station B is transmitting, they must stop decrementing the backoff
counters and defer until the frame is transmitted and a DIFS has passed.
Step 5
During the time that Station B is transmitting a frame, Station E receives a frame to transmit, but because
Station B is sending a frame, it must defer in the same manner as Stations C and D.
Step 6
When Station B completes transmission and the DIFS has passed, stations with frames to send begin to
decrement the backoff counters. In this case, the Station D backoff counter reaches zero first and it
begins transmission of its frame.
Step 7
The process continues as traffic arrives on different stations.
IEEE 802.11e/WMM
As can be seen from the previous sections analysis of the DCF model, there is no provision to
differentiate service levels by traffic types, thus quality assurance is not possible using legacy DCF. To
address this (and other limitations) the IEEE 802.11e task group provided enhancements to the original
802.11 specification that recommended several modifications to the way DCF operates that would
facilitate a differentiated services model. These 802.11e modifications to the DCF model have been
rolled into the wider 802.11-2007 standard (which is essentially a retrofit of the original 802.11
specification). The IEEE 802.11e model was also certified by the Wi-Fi Alliance as the Wireless
Multimedia (WMM) model; as such these terms generally refer to the same mechanisms and are used
interchangeably in this paper.
24-11
The 802.11e task group has provided many enhancements to the overall 802.11 specification, but the key
goal was to introduce an intelligent system of application traffic differentiation on wireless radio
interfaces. Two of the most significant changes proposed by this task group were:
To support marking within wireless frames by supporting a 3 bit marking value known as 802.11e
User Priority (UP); 802.11e UP is essentially the same as 802.1p CoS marking, but for wireless
frames (as opposed to wired Ethernet tagged frames).
To replace DCF with a new MAC layer protocol known as Enhanced Distributed Channel Access
(EDCA), which introduces the concept of relative prioritization by giving different application
traffic varied access levels to the wireless media.
However, a critical point to understand about wireless QoS tools is thatunlike wired QoS toolsthese
can only offer a greater probability of one traffic type being differentiated from another, not an absolute
guarantee of it.
IEEE 802.11e/WMM introduced major enhancements over DCF, which in turn enables a QoS toolset
over Wi-Fi networks. Each of these enhancements is briefly described:
802.11e User Priorities
Access Categories (AC)
Enhanced Distributed Coordination Function (EDCF)
Arbitration Interframe Spacing (AIFS)
Contention Window Enhancements
Transmission Opportunity (TXOP)
Call Admission Control (TSpec)
802.11e User Priorities

IEEE 802.11e/WMM introduced a new frame format, shown in Figure 24-5, which includes support for
a 3 bit marking fieldcompatible with 802.1D priority and 802.1p CoSthat is referred to as 802.11e
User Priority (UP).
WMM Frame Format and 802.11e UP
Frame
control
Dur
0 or 6
0 or 2
A1
A2
A3
Seq
control
A4
QoS
control
15-7
6-5
ack
policy
Acknowledge ------- 00
Do not acknowledge ------- 01
24-12
4
EOSP
End of service
period
Body
3
0
FCS
2-0
UP
802.11e UP
294172
Figure 24-5
Chapter 24

Access Categories (AC)

IEEE 802.11e/WMM specifies four different access categories, which are:
Voice (AC_VO)
Video (AC_VI)
Best-Effort (AC_BE)
Background (AC_BK)
IEEE 802.11e also supports a default mapping of User Priority markings to these access categories; these
mappings are shown in Table 24-1.
Table 24-1
IEEE 802.11e/WMM Access Categories, Mappings and Designations
Relative
Priority 802.11e UP 802.11e Access Category (AC) WMM Designation Cisco WLC Designation
Highest
AC_VO
Voice
Platinum
AC_VI
Video
Gold
AC_BE
Best Effort
Silver
AC_BK
Background
Bronze
6
5
4
3
Default
0
2
Lowest
Note
An important item to note regarding the 802.11e/WMM AC model shown in Table 24-1 is that several
CoS values in this WMM model do not line up with their IETF DSCP counterparts. For example, voice
is mapped to a 802.11e UP value of 6. However, in wired networks, voice is typically marked 802.1p
CoS value of 5, as this corresponds to the three Most Significant Bits (MSB) of the IETF recommended
(six-bit) DSCP marking value for voice traffic of EF/46 (based on RFCs 32461 and 45942). The root
cause of this marking incompatibility is that the IETF defines Layer 3 marking standards (i.e., DSCP),
while the IEEE defines Layer 2 standards (like 802.1p CoS and 802.11e UP). Unfortunately, this
sometimes leads to confusion and inconsistencies with the marking schemes that must be dealt with by
the network engineer. These mapping considerations are discussed in greater detail later.
Note
There is no relative priority between UP or CoS markings assigned to a single access category over the
WLAN; for example, flows marked with either UP or CoS values of 4 and 5 are assigned to the
video/gold WMM access category, but there is no difference in treatment between these flows.
Note
While the WMM uses specific application designations for these access categories (Voice, Video, Best
Effort, and Background), Cisco WLC software uses a more generic designation based on precious
metals: platinum, gold, silver and bronze. Nonetheless each set of names refers to the same underlying
1. An Expedited Forwarding PHB (Per-Hop Behavior) http://www.ietf.org/rfc/rfc3246

2. Configuration Guidelines for DiffServ Service Classes http://www.ietf.org/rfc/rfc4594
24-13
access categories. In this paper, the latter (precious-metal-based) designations are used to simplify
mapping examples and reduce confusion when describing RFC 4594-based application classes versus
WMM access categories.
Enhanced Distributed Coordination Function (EDCF)

Figure 24-6 shows the queuing performed on a WMM client or AP. There are four separate queues, one
for each of the access categories. Each of these queues contends for the wireless channel in a similar
manner to the DCF mechanism described previously, but with each of the queues using different
interframe spaces and with different CWmin and CWmax values. If frames from different access
categories collide internally, the frame with the higher priority is sent and the lower priority frame
adjusts its backoff parameters as though it had collided with a frame external to the queuing mechanism.
This system is called the Enhanced Distributed Coordination Function (EDCF).
Figure 24-6
WMM Queues
Application
Best effort
Video
Voice
294173
Background
Arbitration Interframe Spacing (AIFS)

One of the key limitations of DCF is that the DIFS value is the same for all traffic types. The rule to
remember here is that once the channel is declared available, all stations wanting to transmit must wait
the DIFS time period following the end of the current stations transmission. The problem is that if there
are multiple stations waiting to transmit, they all have to wait the exact same DIFS gap, regardless of
how latency-sensitive their data is, thus giving no preferential treatment to either high or low priority
traffic.
To address this, EDCA introduces a variable interframe spacing (IFS) period for data and management
frames, called the Arbitration Interframe Spacing (AIFS) number. The intention of assigning different
IFS values to each AC is that the higher-priority ACs are assigned shorter wait times as compared to the
lower-priority ACs. This approach thus gives the high-priority traffic a much better probability of being
transmitted first.
While AIFS numbers are configurable, the default values defined in EDCF (as measured in slot times)
are shown in Table 24-2.
24-14
Chapter 24

Table 24-2
EDCA Default AIFS Numbers
Access Category AIFS (Slot Times)

Voice
Video
Best Effort
Background
Contention Window Enhancements

DCF gives no preferential treatment to high-priority traffic during the CW, meaning that all traffic types
have the same statistical probability of being the next one to transmit. Therefore an additional
enhancement EDCA introduced is to give preferential CW random backoff ranges for higher priority
traffic, thus making it much more likely for a voice or video frame to be transmitted before a best-effort
or background frame. This is particularly important for latency sensitive traffic, such as voice and video,
which suffers greatly if they have to wait up to the CWmax interval. Similar to the different AIFSN
values assigned to the different priority queues, different contention window values serve to give higher
priority traffic a better probability of having to wait a shorter period of time before having a chance to
transmit and also limit the impact of long CW wait times. The default EDCA CW values for 801.11a/g/n
are shown in Table 24-3.
Table 24-3
EDCA/WMM Default Contention Window Values
Access Category
CWmin (Slot Times) CWmax (Slot Times)
Legacy DCF (for comparison) 15
1023
Voice
Video
15
Best-Effort
15
1023
Background
15
1023
Table 24-3 shows that voice only backs off between 3-7 slot times compared to background traffic
(which is still the same as the legacy DCF CW backoff period). Of course, since the CW is randomly
generated, there is still a small probability that the lower priority queues might backoff for a shorter
period than a higher priority queue; however, over time the higher-priority queues are statistically
serviced much more often.
Figure 24-7 shows how AIFS and per-AC CW backoff timers work together to improve the overall
handling of the four WMM access categories. In this example, the voice queue waits for five slot times
before attempting to send its data onto the channel (2 AIFS slots + a randomly generated CW of 3 slots),
thus resulting in a significantly improved probability that the voice traffic is sent over the air before
anything else.
24-15
AIFS and CW Operation for Access Category Priority
AISFs
Contention Windows
SIFS
7 slots
CWmin[15]
3 slots
CWmin[15]
2 slots
2 slots
CWmin[7]
CWmin[3]
Background
Best Effort
Video
Voice
294174
Figure 24-7
Transmission Opportunity (TXOP)

EDCF provides contention-free period access to the wireless medium, called the Transmission
Opportunity (TOXP). The TXOP is a set period of time when a wireless station may send as many frames
as possible without having to contend with other stations. In the legacy DCF model once a station has
access to the medium, it is able to keep sending frames as long as it wants. When a low data-rate station
gains access to the medium, it forces all other stations to wait until it is finished its transmission.
With EDCAs TXOP enhancement, each station has a set TXOP time limit where it can transmit. Once
the TXOP limit expires, it must give up access to the medium.
Call Admission Control (TSpec)

One last major enhancement introduced by 802.11e is a mechanism for Call Admission Control (CAC)
called Transmission Specification (TSpec). TSpec allows real-time applications, such as voice calls or
video calls in-progress, to be prioritized over requests for new calls. To use this feature of EDCF, TSpec
must be configured on the AP and optionally on the client stations.
When running TSPec, a client station signals its traffic requirements (mean data rate, power save mode,
frame size, etc.) to the AP. In this way, before a client sends traffic of a certain priority type (AC), it must
first request permission via the TSpec mechanism. For example, a WLAN client device wanting to use
the voice AC must first make a request for use of that AC to see if there is sufficient space on the network
to do so. If the AP decides there is insufficient availability on the network, it denies access for that client
station, thus protecting the currently transmitting stations.
EDCF Operation
With all the elements combined, EDCF operation highlighting application-level QoS over wireless
media, is presented in Figure 24-8. In this example voice traffic is contending with best effort.
24-16
Chapter 24

Figure 24-8
EDCF Operation
AIFS[0]
AIFS[0]
AIFS[0]
AIFS[0]
AIFS[6]
AIFS[6]
AIFS[6]
AIFS[6]
Frame
Best effort
Defer
Frame
Defer
Defer
Frame
Defer
294175
Defer
Voice
The EDCF process follows this sequence:

Step 1
While Station X is transmitting its frame, other stations determine that they must also send a frame. Each
station defers because a frame was already being transmitted, and each station generates a random
backoff.
Step 2
Because the Voice station has a traffic classification of voice, it has an Arbitrated Interframe Space
(AIFS) of 2, and uses an initial CWmin of 3, and therefore must defer 5 slot times total before attempting
to transmit.
Step 3
Best-effort has an AIFS of 3 and a longer random backoff time, because its CWmin value is 15.
Step 4
Voice has the shortest random backoff time, and therefore starts transmitting first. When Voice starts
transmitting, all other stations defer.
Step 5
After the Voice station finishes transmitting, all stations wait their AIFS, then begin to decrement the
random backoff counters again.
Step 6
Best-effort then completes decrementing its random backoff counter and begins transmission. All other
stations defer. This can happen even though there might be a voice station waiting to transmit. This
shows that best-effort traffic is not starved by voice traffic because the random backoff decrementing
process eventually brings the best-effort backoff down to similar sizes as high priority traffic, and that
the random process might, on occasion, generate a small random backoff number for best-effort traffic.
Step 7
The process continues as other traffic enters the system.

Having reviewed the QoS tools and mechanisms available for managing application quality over
WLANs, the administrator is faced with having to make the decisions as to which applications to assign
to each of the four WMM access categories available, as well as how to interconnect the QoS policies
for the WLAN with the rest of the network so as to create an end-to-end solution.
24-17
Chapter 24
When making these decisions, it is best to take a step back from the tools and technical elements of the
equation and examine the business or organization needs. Focusing on the tools exclusively can be
compared to going to a hardware store, coming across a handy tool, and then going home and trying to
decide what to build with it. Conversely, a better approach is to understand what needs to be built and
then finding the right tool(s) to achieve that objective.
Therefore a network administrator needs to first define the business and organizational objectives to be
addressed with QoS policies across their end-to-end network, which includes defining:
Which applications are viewed as critical for achieving business/organizational objectives?
What are the respective service-level requirements of these critical applications?
What applications are present over the network that consume resources away from critical
applications and which could be deprioritized?
How many unique classes of service need to be provisioned in order to meet these per-application
service level requirements and thus the business objectives?
Cisco recommends a strategic approach to application quality management in an end-to-end manner that
encompasses all Places-in-the-Network (PINs), including the WLAN. This approach is based on IETF
RFC 4594.
Cisco's Strategic Application-Class QoS Recommendations

Ciscos strategic approach to application QoS (which is based on IETF RFC 4594) is summarized in
Figure 24-9.1
Ciscos (RFC4594-based) Strategic Application-Class QoS Recommendations
Application Class
Per-Hop
Behavior
Admission
Control
Queuing and Dropping
Application Examples
Voice
EF
Required
Priority Queue (PQ)
Cisco IP Phones (G.711, G.729
Broadcast Video
CS5
Required
(Optional) PQ
Cisco IP Video Surveillance/Cisco Enterprise TV
Realtime Interactive
CS4
Required
(Optional) PQ
Cisco TelePresence
AF4
Required
BW Queue + DSCP WRED
Cisco Jabber, Cisco WebEx
AF3
Recommended
Cisco Digital Media System (VoDs)
Network Control
CS6
BW Queue
EIGRP, OSPF, BGP, HSRP, IKE
Signaling
CS3
BW Queue
SCCP, SIP, H.323
Ops/Admin/Mgmt (OAM)
CS2
BW Queue
SNMP, SSH, Syslog
Transactional Data
AF2
VDI Apps, ERP Apps, CRM Apps, Database Apps
Bulk Data
AF1
E-mail, FTP, Backup Apps, Content Distribution
Best Effort
DF
Default Queue + RED
Default Class
Scavenger
CS1
Min BW Queue (Deferential)
YouTube, iTunes, BitTorrent, Xbox Love
1. Enterprise Medianet Quality of Service Design 4.0-Overview

http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSIntro_40.html
#wp61104
24-18
294176
Figure 24-9
Chapter 24

Note
Cisco has adopted RFC 4594 as its general DiffServ QoS strategy with the following exception: Cisco
has swapped the marking recommendations of the RFC 4594 Broadcast Video class (of CS3) with the
Signaling class (of CS5). Therefore Cisco has decided to mark Broadcast Video traffic as CS5 and
Signaling traffic as CS3. This is primarily because Cisco has been marking Signaling to CS3 for over a
decade (well before RFC 4594 was even drafted) and lacking a compelling business case to change the
defaults on all its voice and video-telephony products, has decided to continue doing so. Furthermore,
such a marking change would correspondingly force their customer base to change all their network QoS
policies relating to the Signaling class as well. Therefore, Cisco has swapped these marking
recommendations. It is important to remember that RFC 4594 is an informational RFC and not a standard
and, as such, compliance-in full or in part-is not mandatory.
As shown in Figure 24-9, an enterprise may be required to support up to twelve application classes of
that have unique service level requirements:
VoiceThis service class is intended for VoIP telephony (audio media only traffic-VoIP signaling
traffic is assigned to the Signaling class). Traffic assigned to this class should be marked EF. This
class is provisioned with an Expedited Forwarding (EF) Per-Hop Behavior (PHB). The EF
PHB-defined in RFC 3246-is a strict-priority queuing service and, as such, admission to this class
should be controlled (admission control is discussed in the following section). Example traffic
includes G.711 and G.729a.
Broadcast VideoThis service class is intended for broadcast TV, live events, video surveillance
flows, and similar inelastic streaming video flows (inelastic refers to flows that are highly drop
sensitive and have no retransmission and/or flow control capabilities). Traffic in this class should be
marked Class Selector 5 (CS5) and may be provisioned with an EF PHB; as such, admission to this
class should be controlled. Example traffic includes live Cisco Digital Media System (DMS) streams
to desktops or to Cisco Digital Media Players (DMPs), live Cisco Enterprise TV (ETV) streams, and
Cisco IP Video Surveillance.
Real-Time InteractiveThis service class is intended for (inelastic) room-based, high-definition

interactive video applications and is intended primarily for voice and video components of these
applications. Whenever technically possible and administratively feasible, data sub-components of
this class can be separated out and assigned to the Transactional Data traffic class. Traffic in this
class should be marked CS4 and may be provisioned with an EF PHB; as such, admission to this
class should be controlled. An example application is Cisco TelePresence.
Multimedia ConferencingThis service class is intended for desktop software multimedia

collaboration applications and is intended primarily for voice and video components of these
applications. Whenever technically possible and administratively feasible, data sub-components of
this class can be separated out and assigned to the Transactional Data traffic class. Traffic in this
class should be marked Assured Forwarding (AF) Class 4 (AF41) and should be provisioned with a
guaranteed bandwidth queue with DSCP-based Weighted-Random Early Detect (DSCP-WRED)
enabled. Admission to this class should be controlled; additionally, traffic in this class may be
subject to policing and re-marking. Example applications include Cisco Jabber and Cisco WebEx.
Multimedia StreamingThis service class is intended for Video-on-Demand (VoD) streaming video
flows which, in general, are more elastic than broadcast/live streaming flows. Traffic in this class
should be marked AF Class 3 (AF31) and should be provisioned with a guaranteed bandwidth queue
with DSCP-based WRED enabled. Admission control is recommended on this traffic class (though
not strictly required) and this class may be subject to policing and re-marking. Example applications
include Cisco Digital Media System Video-on-Demand (VoD) streams.
Network ControlThis service class is intended for network control plane traffic, which is required
for reliable operation of the enterprise network. Traffic in this class should be marked CS6 and
provisioned with a (moderate, but dedicated) guaranteed bandwidth queue. WRED should not be
24-19
Chapter 24
enabled on this class, as network control traffic should not be dropped (if this class is experiencing
drops, then the bandwidth allocated to it should be re-provisioned). Example traffic includes EIGRP,
OSPF, BGP, HSRP, IKE, etc.
SignalingThis service class is intended for signaling traffic that supports IP voice and video
telephony. Traffic in this class should be marked CS3 and provisioned with a (moderate, but
dedicated) guaranteed bandwidth queue. WRED should not be enabled on this class, as signaling
traffic should not be dropped (if this class is experiencing drops, then the bandwidth allocated to it
should be re-provisioned). Example traffic includes SCCP, SIP, H.323, etc.
Operations/Administration/Management (OAM)As the name implies, this service class is

intended for network operations, administration, and management traffic. This class is critical to the
ongoing maintenance and support of the network. Traffic in this class should be marked CS2 and
provisioned with a (moderate, but dedicated) guaranteed bandwidth queue. WRED should not be
enabled on this class, as OAM traffic should not be dropped (if this class is experiencing drops, then
the bandwidth allocated to it should be re-provisioned). Example traffic includes SSH, SNMP,
Syslog, etc.
Transactional Data (or Low-Latency Data)This service class is intended for interactive,
foreground data applications (foreground refers to applications from which users are expecting
a responsevia the networkin order to continue with their tasks; excessive latency directly
impacts user productivity). Traffic in this class should be marked AF Class 2 (AF21) and should be
provisioned with a dedicated bandwidth queue with DSCP-WRED enabled. This traffic class may
be subject to policing and re-marking. Example applications include data components of multimedia
collaboration applications, Virtual Desktop Infrastructure (VDI) applications, Enterprise Resource
Planning (ERP) applications, Customer Relationship Management (CRM) applications, database
applications, etc.
Bulk Data (or High-Throughput Data)This service class is intended for non-interactive
background data applications (background refers to applications from which users are not
awaiting a responsevia the networkin order to continue with their tasks; excessive latency in
response times of background applications does not directly impact user productivity). Traffic in this
class should be marked AF Class 1 (AF11) and should be provisioned with a dedicated bandwidth
queue with DSCP-WRED enabled. This traffic class may be subject to policing and re-marking.
Example applications include: email, backup operations, FTP/SFTP transfers, video and content
distribution, etc.
Best Effort (the default class)This service class is the default class. The vast majority of
applications will continue to default to this Best-Effort service class; as such, this default class
should be adequately provisioned. Traffic in this class is marked Default Forwarding (DF or DSCP
0) and should be provisioned with a dedicated queue. WRED is recommended to be enabled on this
class.
Scavenger (or Low-Priority Data)This service class is intended for non-business related traffic
flows, such as data or video applications that are entertainment and/or gaming-oriented. The
approach of a less-than Best-Effort service class for non-business applications (as opposed to
shutting these down entirely) has proven to be a popular, political compromise. These applications
are permitted on enterprise networks, as long as resources are always available for business-critical
voice, video, and data applications. However, as soon as the network experiences congestion, this
class is the first to be penalized and aggressively dropped. Traffic in this class should be marked CS1
and should be provisioned with a minimal bandwidth queue that is the first to starve should network
congestion occur. Example traffic includes YouTube, Facebook, Xbox Live/360 Movies, iTunes,
BitTorrent, etc.
24-20
Chapter 24

Application-Class Expansion
While there are merits to adopting a 12-class model, Cisco recognizes that not all enterprises are ready
to do so, whether this be due to business reasons, technical constraints, or other reasons. In fact, most
businesses deploying QoS are typically somewhere between a 4 and 8 class model today.
Therefore, rather than considering these QoS recommendations as an all-or-nothing approach, Cisco
recommends considering a phased approach to application class expansion, as illustrated in
Figure 24-10.
Figure 24-10
Application-Class Expansion Models
4-Class Model
8-Class Model
12-Class Model
Voice
Voice
Interactive Video
Realtime
Broadcast Video
Streaming Video
Control
Signaling
Signaling
Network Control
Network Control
OAM
Transactional Data
Transactional Data
Transactional Data
Best Effort
Best Effort
Scavenger
Scavenger
Best Effort
294177
Bulk Data
By considering such a phased approach to application class expansion network administrators can
incrementally implement QoS policies across their infrastructures in a progressive manner, in line with
their evolving business needs. Nonetheless, at each phase of QoS deployment, the enterprise needs to
clearly define their business objectives to determine how many traffic classes will be required at each
phase.
Application-Class Mapping to WMM

As previously mentioned, it is important to base the overall network QoS strategy on business or
organizational requirementsfirst and foremostand not by the number of classes of service supported
on a platform, place-in-the-network, or service provider. This is because platforms, technologies, and
service provider models all change over time, yet the QoS strategy should only change as the business
evolves. Furthermore, any strategic class-of-service model can be mapped to a reduced number of
service classes, as required.
For example, it has already been shown that in the IEEE802.11e/WMM model there are four access
categories supported on the WLAN. This should not be taken to mean that an enterprise should never
deploy more than four application classes. Rather, they should define their overall end-to-end strategy
based on their organizational requirements and then map into these four access categories at the WLAN.
24-21
Chapter 24
Cisco 802.11e/802.1p/DSCP Mappings
Even highly complex modelssuch as an RFC 4594-based 12-class modelcan be mapped into the four
WMM access categories, as illustrated in Figure 24-11.
Figure 24-11
Example Twelve-Class Application-Class Model Mapped into WMM
12-Class Strategic
Application-Class Model
WMM Model
(Cisco WLC Designations)
Voice
Broadcast Video
Platinum
Gold
Network Control
Signaling
OAM
Silver
Transactional Data
Best Effort
Scavenger
Note
Bronze
294178
Bulk Data
Figure 24-11 serves only to illustrate the concept of application class mapping into a reduced set of
traffic classes; additional details are provided later in this document to show best-practice
recommendations in mapping a 4-Class model, an 8-Class model and this same 12-Class enterprise
model into WMM.

At this point, it may be helpful to clarify some terms that will be used extensively throughout the rest of
this paper:
DownstreamUsed to refer to the flow of packets from the wired network infrastructure to the
wireless devices, including:
Network DownstreamRefers to traffic leaving the WLC traveling to the AP; this traffic is
encapsulated within LWAPP. Wired campus QoS policies provision downstream QoS.
Radio DownstreamRefers to traffic leaving the AP and traveling to the WLAN clients. WMM
provides downstream QoS for WLAN clients.
UpstreamUsed to indicate the flow of packets from the mobile wireless device to the wired
network infrastructure, including:
Radio UpstreamRefers to traffic transmitted by the WLAN clients and traveling to the AP.
WMM provides upstream QoS for WLAN clients.

Network upstreamRefers to traffic leaving the AP, traveling to the WLC; this traffic is
encapsulated within LWAPP. Wired campus QoS policies provision upstream QoS.
24-22
Chapter 24

These terms are illustrated in Figure 24-12.

Downstream and Upstream QoS
Radio Downstream
Network Downstream
CAWAP Tunnels
AP
Radio Upstream
802.1Q Trunk
WLC
Network Upstream
294179
Figure 24-12
In order for campus wired networks to interoperate with WLAN networks, their respective markings
need to be translated or mapped in either direction of flow (upstream and downstream).
Default DSCP-to-CoS/UP Mappings

By default, 6-bit DSCP values are mapped to 3-bit 802.1p CoS and 802.11e UP values by taking the three
Most-Significant Bits (MSB) of the DSCP and copying these as the CoS and/or UP values. For example,
DSCP EF/46 (binary 101110) is mapped to CoS or UP 5 (binary 101), by default. For example, by
default, the network switch that connects to the Cisco WLC will generate 802.1p CoS values (for the
802.1Q trunked traffic) by setting these to match the three MSB of the DSCP values.
Conversely, in the reverse direction, the CoS or UP values are simply multiplied by 8 (in order to shift
these three binary bits to the left) to generate a DSCP value. Continuing the example, CoS or UP 5
(binary 101) would be mapped (i.e., multiplied by 8) to DSCP 40 (binary 101000), also known as CS5.
As can be seen in the above pair of examples, because information is being truncated from 6-bits to
3-bits, marking details can get lost in translation. In this example, the original voice packet was sent with
DSCP EF, but was received as DSCP CS5 (based solely on default Layer 3/Layer 2 mapping). This needs
to be taken into account when mapping from wired-to-wireless and vice-versa.
Cisco WLC/AP QoS Translation Table

As has already been pointed out in the consideration of Table 24-1, IEEE 802.11e and 802.1p application
marking values do not always align with IETF-based DSCP-to-CoS mappings. For example, DSCP
EF/46 is recommended by the IETF for use for voice, which would map by default to CoS/UP 5; but the
IEEE designates CoS/UP 6 for voice. Similarly, the IETF recommends DSCP CS4 or AF4 for realtime
or interactive video conferencing, both of which would map by default to CoS 4; but the IEEE designates
CoS/UP 5 for video.
In an effort to reconcile the markings recommendations between these independent and disagreeing
standards bodies, Cisco has implemented an automatic mapping function within WLC software to
automatically convert special marking values to the respective IETF or IEEE marking recommendations,
as shown in Table 24-4.
24-23
Chapter 24
Table 24-4
Cisco WLC/AP DSCP-to-UP Translation Table1
Application Class
IETF DSCP IEEE 802.11e UP WLC QoS Profile
Network control
56 (CS7)
Platinum
Internetwork control
48 (CS6)
Platinum
Voice
46 (EF)
Platinum
Multimedia Conferencing 34 (AF41) 5
Gold
26 (AF31) 4
Gold
Transactional Data
18 (AF21) 3
Silver
Bulk Data
10 (AF11) 2
Bronze
Best Effort
0 (BE)
Silver
1. Cisco Wireless LAN Controller WLAN Configuration Guide, Release 7.4 - Working with
WLANs - Assigning QoS Profiles
http://www.cisco.com/en/US/partner/docs/wireless/controller/7.4/configuration/guides/c
onsolidated/b_cg74_CONSOLIDATED_chapter_01010111.html
Residual DSCP-to-WMM Mappings

The IEEE 802.11e UP value for DSCP values that are not mentioned in the Table 5 are calculated by
considering 3 MSB bits of DSCP. Thus with the exceptions noted in Table 5, DSCP values will map to
the WMM/WLC Access Categories shown in Table 24-5.
Table 24-5
Default DSCP, UP and WLC Access Category Mappings (Excluding the Exceptions
Listed in Table 24-4)
DSCP Range
IEEE 802.11e UP WLC QoS Profile
DSCPs 56-63 7
Platinum
DSCPs 48-55 6
DSCPs 40-47 5
Gold
DSCPs 32-39 4
DSCPs 24-31 3
DSCPs 0-7
DSCPs 16-23 2
DSCPs 8-15
Silver
Bronze
WLC AVC/QoS Profile-to-DSCP Mappings

If QoS or AVC Profiles are created on a Cisco WLC and applied to WLANs, then the packets assigned
to the access-categories within these profiles will be marked to the DSCP values shown in Table 24-6.
For example, if an application is assigned to the Gold profile, then all application traffic will be marked
to DSCP 34.
24-24
Chapter 24

Table 24-6
Default WLC Profile to DSCP Mappings
WLC QoS Profile DSCP

Platinum
EF (DSCP 46)
Gold
AF41 (DSCP 34)
Silver
DF (DSCP 0)
Bronze
AF11 (DSCP 10)
Cisco Wired-Wireless Mapping Points

With the translation-mapping table and default mapping methods in place, the questions that remain are:
where is mapping done between wired and wireless networks? And how?
Figure 24-13 is a very important diagram that identifies the various places where wired-and-wireless
mapping takes place-in both the downstream direction (top of Figure 24-13) and the upstream direction
(bottom of Figure 24-13).
Figure 24-13
Downstream and Upstream Layer 2/Layer 3 Mapping
Downstream
UP
CAPWAP Encapsulated Packet
DSCP
Payload
DSCP
DSCP
802.1p
Payload
DSCP
Payload
AP
CAWAP Tunnels
802.1Q Trunk
WLAN Controller
AP
AP
CAPWAP Encapsulated Packet
4
DSCP
UP
Payload
DSCP
DSCP
Payload
DSCP
802.1p
294180
Payload
Upstream
In Figure 24-13, the following mappings occur in the downstream direction:
Step 1
The network switch maps the DSCP value of an incoming packet (destined to a WLAN via the WLC) to
an 802.1p CoS value as it transits the 802.1Q trunks connecting to the WLC (by default this mapping is
done by taking the three MSBs of the DSCP and copying these to the 802.1p CoS value).
24-25
Chapter 24
Configuring Downstream QoS Policies for Mobile Applications
Step 2
An 802.1Q frame/packet with an 802.1p marking and a DSCP marking arrive at the WLC. The DSCP of
the packet is copied to the inner and outer DSCP fields of the CAPWAP packet on egress as it transits
toward the destination APs and WLANs.
Note
Step 3
An exception will occur if the DSCP exceeds the Maximum Priority (i.e., the maximum DSCP
marking value) defined in the QoS Profile associated with the destination WLAN, in which case
both the inner and outer DSCP values will be marked down to this Maximum Priority value.
The outer DSCP of the CAPWAP packet arriving at the AP will be mapped to an 802.11e UP marking
based on the QoS Translation Table (Table 24-4) or a default mapping (if no explicit mapping is found
for the specific DSCP value in the QoS Translation Table). The inner DSCP value is copied to the
DSCP-field of the 802.11e frame/packet.
Conversely, in Figure 24-13, the following mappings occur in the upstream direction:
Step 1
The 802.11e UP values and DSCP values of a mobile application are marked in the software of the device
as it is transmitted. When the frame/packet arrives at the AP, the UP value will be mapped to the outer
DSCP value of the CAPWAP packet; this mapping is based on the QoS Translation Table (Table 24-4)
or a default mapping (if no explicit mapping is found for the specific DSCP value in the QoS Translation
Table). Additionally, the DSCP value set on the mobile device will be copied to the inner DSCP value
of the CAPWAP packet.
Note
Step 2
As previously, the DSCP value assigned to the CAPWAP packet is subject to any Maximum
Priority value capping that may be configured within the QoS Profile associated with the
WLAN.
The outer DSCP of the CAPWAP packet will be mapped to an 802.1p CoS value as the frame/packet
leaves the WLC towards the wired network (by default this mapping is done by taking the three MSBs
of the DSCP and copying these to the 802.1p CoS value). Additionally, the inner DSCP of the CAPWAP
packet will be copied to the DSCP value of the 802.1Q trunked IP packet.

Provisioning end-to-end mobile application QoS requires policy configuration at the following points in
the wired and wireless networks for downstream flows:
WLC AVC ProfilesAre configured and assigned to WLANs to identify applications and mark
(with DSCP) or drop these packets. Additionally AVC Profiles assign applications to WMM access
categories in the radio-downstream direction. AVC Profiles are applied on WLC ingress and are
shown as point A in Figure 24-14.
WLC QoS ProfilesAre assigned to each WLAN and define the (unicast and multicast) Default
Priority (i.e., default/Best Effort DSCP value and access category) and the Maximum Priority value
for the WLAN. QoS Profiles are applied on WLC egress and are shown as point B in Figure 24-14.
24-26
Chapter 24

AP Access Switch QoS PoliciesThe entire underlying wired-network infrastructure should be

configured with QoS policies in line with the strategic application-class model in use for the given
enterprise. Additionally, the access-switch to which a given wireless access-point connects to may
be used to work-around non-configurable upstream/downstream mapping operations (as is
discussed in detail later); these policies are typically applied on access switch egress and are shown
as point C in Figure 24-14.
Figure 24-14
Downstream QoS Policy Configuration Points in Wired/Wireless Networks
Downstream
AP
802.1Q Trunk
WLC
WLC
Switch
294181
CAWAP Tunnels
AP Access
Switch
Wireless Controller QoS Profile GUI Configuration

QoS Profileslike AVC Profilesare applied to both upstream and downstream flows on WLC egress.
It is recommended to complete these steps to define an appropriate QoS Profile for a given WLAN.
Among many other parameters, the WLAN QoS Profile defines:
Per-User Bandwidth Contracts(Optional) per-user limits for average and peak data and realtime
traffic rates.
Per-SSID Bandwidth Contracts(Optional) per-SSID limits for average and peak data and realtime
traffic rates.
WLAN Maximum PriorityThe highest DSCP marking value that may be used on the WLAN; this
value can override AVC policies as well DSCP-values received from the wired network. As such, in
multiservice WLANs, it is generally recommended to ensure that the Maximum Priority value be set
to voice (i.e., platinum).
Unicast and Multicast Default PriorityThe default DSCP marking value to be used on the WLAN
for all traffic not explicitly classified by an overriding AVC Profile. Typically these values are set as
best effort (i.e., silver), however there may be cases where this default value may be set to
background (i.e., bronze), which is discussed later in the Four-Class Model Mapping Configuration.
Wired QoS ProtocolCan be set to 802.1p and the maximum CoS value can be defined per WLAN.
WLC QoS Profile GUI Configuration

Details of a given QoS Profile can be viewed and modified via the WLC GUI by performing the
following steps:
1.
Open a web browser to the WLC IP address via HTTPS and login.
2.
Click the WIRELESS heading bar and expand the QoS link on the lower left and click Profiles.
3.
Click the profile to be viewed/modified (these are listed in alphabetical order:

bronze/gold/platinum/silver). Details of the Platinum QoS profile are shown in Figure 24-15.
24-27
Chapter 24
Figure 24-15
Viewing/Editing the Platinum WLC QoS Profile
To apply a QoS profile to a WLAN, complete the following steps.

1.
Click the WLANs heading and select an existing WLAN (or click the CREATE NEW button to
create a new one).
2.
Click the QoS tab of the selected WLAN and ensure that:
a. Quality of Service (QoS) is set to PLATINUM (VOICE); this allows for the highest DSCP
markings values to be used for AVC policies that are to be attached to the WLAN (in the
following section).
b. Application Visibility checkbox is ENABLED, as shown in Figure 24-16.
3.
Note
Click Apply.
Applying a QoS policy to a WLAN will momentarily interrupt service.
24-28
Chapter 24

Figure 24-16
Assigning a QoS Profile to a WLAN and Enabling AVC
WLC QoS Profile CLI Configuration

The following CLI commands will apply the Platinum QoS Profile configuration to WLAN as well as
enable AVC Visibility for the WLAN:
Example 24-1 Configuring QoS Profiles for WLANs and Enabling Application Visibility
(Cisco WLC) > config wlan disable 1
! Disables the WLAN so that the QoS profile may be changed
(Cisco WLC) > config wlan qos 1 platinum
! Applies the Platinum QoS profile to the WLAN
(Cisco WLC) > config wlan avc 1 visibility enable
! Enables AVC Visibility on WLAn 1
(Cisco WLC) > config wlan enable 1
! Re-enables WLAN 1
(Cisco WLC) >
This configuration can be verified with:
show wlan (as shown in Example 24-2)
Example 24-2 QoS Profile Verification: show wlan

(Cisco WLC) >show wlan 1
WLAN Identifier..................................
Profile Name.....................................
Network Name (SSID)..............................
Status...........................................
1
BYOD_Employee
BYOD-Employee
Enabled
<snip>
24-29
Chapter 24
Quality of Service............................... Platinum

<snip>
AVC Visibilty.................................... Enabled
(Cisco WLC) >
Wireless Controller AVC QoS Profile Configuration

AVC Profiles are applied to both upstream and downstream flows on WLC ingress. While this may
simplify the QoS policy configuration on the WLC, it has design implications in upstream/downstream
mapping, as has been previously discussed (and which is expanded on in the following sections).
Additionally, each WLAN can have only one AVC profile attached to it to control applications, however
an AVC Profile can be attached to multiple WLANs. Also, an AVC Profile can contain a maximum of
32 application rules and a maximum of 16 AVC profiles can be created on a WLC.
Limitations of AVC on the WLC are as noted below and should be kept in mind while deploying AVC
on WLC:
IPv6 traffic or Multicast traffic cannot be classified.
AVC is not supported on virtual WLC models.
AVC is not supported on WLAN configured for Local Switching.
AVC Profiles cannot be applied on a per controller, VLAN, or client basis (only WLAN).
The AVC profiles do not support AAA override.
NBAR based Rate Limiting per Application is not supported, however AVC will work with wireless
Bi-Directional Rate Limiting (BDRL) per controller/interface/WLAN/user.
Any application which is not classified/supported/recognized by the NBAR2 engine is captured as

UNCLASSIFIED traffic.
As has been previously discussed, it also is important to note that each WLAN can have both a QoS
Profile and an AVC Profile attached to it. The AVC Profile is applied when the packet enters the WLC
and the QoS policy is applied when packet exits the WLC. If an AVC profile is mapped to WLAN with
an explicit rule for a MARK action, that MARK action will override any default QoS Profile marking
configured on the WLAN. However, QoS Profiles may define a Maximum Priority DSCP value for
packet marking, which will override any AVC Profile marking policy. Thus care should be taken that
QoS and AVC Profiles are correctly configured to complement-and not contradict-one another.
It may be helpful to begin by viewing the list of the over 1000 AVC supported applications by performing
the following:
1.
Select the Wireless heading and then expand the Application Visibility and Control link on the
lower left.
2.
Click the AVC Applications link and scroll through the alphabetical application list, as shown in
Figure 24-17.
24-30
Chapter 24

Figure 24-17
AVC Application List
The 1039 AVC applications supported in WLC software version 7.4 are grouped into 16 Application
Groups:
Browsing
Business-and-productivity-tools
Email
File-sharing
Gaming
Industrial-protocols
Instant-messaging
Internet-privacy
Layer3-over-ip
Location-based-services
Net-admin
Newsgroup
Obsolete
Other
24-31
Chapter 24
Trojan
Voice-and-video
Example 24-3 shows how to display a list of these applications via the WLC CLI.
Example 24-3 WLC CLIShow AVC Applications
(Cisco WLC) > show avc applications
Application-Name
================
3com-amp3
3com-tsmux
3pc
914c/g
9pfs
acap
acas
accessbuilder
accessnetwork
acp
acr-nema
App-ID
======
538
977
788
1109
479
582
939
662
607
513
975
Engine-ID
=========
3
3
1
3
3
3
3
3
3
3
3
Selector-ID
===========
629
106
34
211
564
674
62
888
699
599
104
Application-Group-Name
======================
other
obsolete
layer3-over-ip
net-admin
net-admin
net-admin
other
other
other
other
industrial-protocols
AVC Protocol Packs (Featuring Cisco Jabber Support)

WLC software release 7.6 includes the ability to add modular AVC Protocol Packs. Protocol Packs are
a means to distribute protocol updates outside the controller software release trains and can be loaded
on the controller without replacing the controller software.
An AVC Protocol Pack is a single compressed file that contains multiple Protocol Description Language
(PDL) files and a manifest file. A set of required protocols can be loaded, which helps AVC to recognize
additional protocols for classification on your network. The manifest file gives information about the
protocol pack, such as the protocol pack name, version, and some information about the available PDLs
in the protocol pack.
The AVC Protocol Packs are released to specific AVC engine versions. You can load a protocol pack if
the engine version on the controller platform is the same or higher than the version required by the
protocol pack.
The first Protocol Pack to be supported on WLCs is AVC Protocol Pack 6.3 available at:
http://software.cisco.com/download/release.html?mdfid=282600534&flowid=7012&softwareid=28450
9011&release=6.3.0&relind=AVAILABLE&rellifecycle=&reltype=latest
Note
The AVC Protocol Pack feature is not supported on the Cisco 2500 Series Wireless LAN Controllers.
An AVC Protocol Pack can be downloaded to the the controller by entering these commands:
1.
transfer download datatype avc-protocol-pack
2.
transfer download start
Once downloaded, the version of the protocol pack that is used on the controller can be verified by the
show avc protocol-pack version verification command (or within the GUI as shown in Figure 24-18).
One of the most notable applications to be supported in Protocol Pack 6.3 is Cisco Jabber. Various media
subcomponents of the Cisco Jabber application that can be discretely identified by this AVC Protocol
Pack include:
24-32
Chapter 24

Audio (cisco-jabber-audio)
Video (cisco-jabber-video)
Control/Signaling (cisco-jabber-control)
Instant-Messaging (cisco-jabber-im)
File-Transfers (my-jabber-ft)
Figure 24-18
Cisco Jabber Support with AVC Protocol Pack 6.3
AVC Applications By Business Use Case

Sample AVC applications that relate to the business use cases mentioned at the outset of this
documentof provisioning preferential services to protect voice, video, and data applications over
wireless networksare listed below. Additionally applications that might be given a deferential level of
service are also listed. However, it is important to note that these are only example applications and do
not represent an exhaustive list of applications by class. With over a thousand applications to choose
from, these lists are simplified for the sake of brevity and serve only to illustrate the AVC policy
concepts.
To ensure voice quality for wireless devices, the cisco-phone application would typically be assigned to
the Platinum (Voice) access category via AVC, as might cisco-jabber-audio. However, additional VoIP
applications may include:
aol-messenger-audio
audio-over-http
fring-voip
gtalk-voip
yahoo-voip-messenger
24-33
Chapter 24
yahoo-voip-over-sip
Similarly, to protect video and multimedia applications, the following applications might be assigned to
the Gold (Video) access-category via AVC:
Note
cisco-ip-camera
telepresence-media
cisco-jabber-video
webex-meeting
ms-lync-media
aol-messenger-video
fring-video
gtalk-video
livemeeting
msn-messenger-video
rhapsody
skype
video-over-http
It may be that some of these video conferencing applications may be considered non-business in nature
(such as Skype and gtalk-video), in which case these may be provisioned into the Bronze (Background)
access category.
To deploy AVC policies to protect the signaling protocols relating to these voice and video applications,
the following applications might be marked to the Call-Signaling marking of CS3 (DSCP 24) via AVC:
sip
sip-tls
skinny
cisco-jabber-control
h323
rtcp
To deploy policies to protect business-critical applications, the following applications might be marked
AF21 (DSCP 18) via AVC:
cisco-jabber-im
citrix
ms-lync
ms-dynamics-crm-online
salesforce
sap
oraclenames
24-34
Chapter 24

perforce
phonebook
semantix
synergy
On the other hand, some business applications would be best serviced in the background by assigning
these to the Bronze (Background) access category via AVC:
my-jabber-ft
ftp/ftp-data/ftps-data
cifs
exchange
notes
smtp
imap/secure imap
pop3/secure pop3
gmail
hotmail
yahoo-mail
And finally, many non-business applications can be controlled by either being assigned to the Bronze
(Background) access category or dropped via AVC policies:
youtube
netflix
facebook
twitter
bittorrent
hulu
itunes
picasa
call-of-duty
doom
directplay8
WLC AVC Profile GUI Configuration

To configure an AVC Profile (a set of AVC policies to be applied on a per-WLAN basis), perform the
following steps:
1.
Click the AVC Profiles link on the lower right.
2.
Click the NEW button on the upper right to create a new AVC profile.
3.
Name the new AVC profile and click the APPLY button, as shown in Figure 24-19.
24-35
Chapter 24
Figure 24-19
Creating an AVC ProfilePart 1
4.
Click the name of the new AVC profile (which has become a link).
5.
Click the ADD NEW RULE button on the upper right.
6.
Select an Application Group to which the application to be controlled belongs.
7.
Scroll down the Application List to specifically select the application to be controlled, as shown in
Figure 24-20.
Figure 24-20
8.
From the Action drop-down box select either DROP or MARK.
9.
From the DSCP drop-down box select the WMM access category or a Custom DSCP marking for
the application (as shown in Figure 24-21):
Platinum (Voice)Marks packets to DSCP EF/46.
Gold (Video)Marks packets to DSCP AF41/34.
24-36
Chapter 24

Silver (Best Effort)Marks packets to the default DSCP DF/0.

Bronze (Background)Marks packets to DSCP AF11/10.
Custom [DSCP]Allows for custom DSCP packet marking between 0 and 63.
Figure 24-21
10. Click the Apply button.
Note
Applying a QoS policy to a WLAN will momentarily interrupt service.

Steps 4 through 10 can be repeated to add other applications to the AVC profile; up to 32 rules can be
configured within an AVC profile.
Care should be taken to align DSCP marking policies with the enterprise strategic QoS model in use
(4/8/12 class models).
Figure 24-22 shows an extended AVC profile that matches a 12-class models marking scheme and
includes temporary markings for the Signaling class and the Transactional Data class.
24-37
Chapter 24
Figure 24-22
Once the AVC profile has been completed with all the applications to be classified (or the maximum of
32 applications has been reached), then complete the following steps to apply the profile to the WLAN.
1.
Click the WLANS heading again.
2.
Select the WLAN the AVC profile is to be applied to by clicking its WLAN ID link.
3.
Click the QoS tab.
4.
Select the AVC profile to be applied to the WLAN from the AVC Profile drop-down list, as shown
in Figure 24-23.
24-38
Chapter 24

Figure 24-23
Attaching an AVC Profile to a WLAN
A WLAN can only have a single AVC profile applied to it, however AVC profiles may be applied to
multiple WLANs.
WLC AVC Profile CLI Configuration

AVC profiles can also be created via the WLC CLI, as shown in Example 24-4.
Example 24-4 WLC CLIAVC Profile Creation and Definition Example
! This section creates the "AVC-APPS" AVC profile
(Cisco WLC) > config avc profile AVC-APPS create
! This section configures AVC for Voice
! Marking Cisco Phone + Cisco Jabber Audio as DSCP EF and assign to the Platinum WMM AC
(Cisco WLC) > config avc profile AVC-APPS rule add application cisco-phone mark 46
(Cisco WLC) > config avc profile AVC-APPS rule add application cisco-jabber-audio mark 46
! This section configures AVC for Multimedia Conferencing applications
! Marking these as DSCP AF41 and assigning them to the Gold WMM AC
(Cisco WLC) > config avc profile AVC-APPS rule add application cisco-jabber-video mark 34
(Cisco WLC) > config avc profile AVC-APPS rule add application webex-meeting mark 34
! This section configures AVC for Realtime Interactive applications
! Marking these as DSCP CS4 and assigning them to the Gold WMM AC
(Cisco WLC) > config avc profile AVC-APPS rule add application telepresence-media mark 32
24-39
Chapter 24
! This section configures AVC for Signaling protocols

! Marking these to DSCP 24 and assigning them to the Gold WMM
(Cisco WLC) > config avc profile AVC-APPS rule add application
24
24
AC
sip mark 24
sip-tls mark 24
h323 mark 24
telepresence-control mark
cisco-jabber-control mark
! This section configures AVC for Transactional Data applications

! Marking these to DSCP 18 and assigning them to the Gold WMM AC
(Cisco WLC) > config avc profile AVC-APPS rule add application cisco-jabber-im mark 18
(Cisco WLC) > config avc profile AVC-APPS rule add application citrix mark 18
(Cisco WLC) > config avc profile AVC-APPS rule add application salesforce mark 18
(Cisco WLC) > config avc profile AVC-APPS rule add application sap mark 18
! This section configures AVC for Bulk Data applications
! Marking these to DSCP AF11 and assigning them to the Bronze
WMM AC
my-jabber-ft mark 10
ftp mark 10
ftp-data mark 10
ftps-data mark 10
cifs mark 10
exchange mark 10
notes mark 10
imap mark 10
secure-imap mark 10
! This section configures AVC for Scavenger applications

! Marking these to DSCP CS8 and assigning them to the Bronze WMM AC
(Cisco WLC) > config avc profile AVC-APPS rule add application facebook mark 8
(Cisco WLC) > config avc profile AVC-APPS rule add application youtube mark 8
(Cisco WLC) > config avc profile AVC-APPS rule add application netflix mark 8
(Cisco WLC) > config avc profile AVC-APPS rule add application hulu mark 8
(Cisco WLC) > config avc profile AVC-APPS rule add application skype mark 8
(Cisco WLC) > config avc profile AVC-APPS rule add application msn-messenger-video mark 8
(Cisco WLC) > config avc profile AVC-APPS rule add application bittorrent mark 8
(Cisco WLC) > config avc profile AVC-APPS rule add application itunes mark 8
(Cisco WLC) > config avc profile AVC-APPS rule add application call-of-duty mark 8
show avc profile summary (as shown in Example 24-5)
show avc profile detailed (as shown in Example 24-6)
Example 24-5 AVC Profile Verification: show avc profile summary

(Cisco WLC) > show avc profile summary
Profile-Name
Number of Rules
============
==============
AVC-APPS
32
(Cisco WLC) >
Example 24-6 AVC Profile Verification: show avc profile detailed

(Cisco WLC) > show avc profile detailed AVC-APPS
Application-Name
================
24-40
=======================
Action
======
DSCP
====
Chapter 24

cisco-phone
cisco-jabber-audio
webex-meeting
telepresence-media
sip
sip-tls
h323
cisco-jabber-control
cisco-jabber-im
citrix
salesforce
sap
my-jabber-ft
ftp
ftp-data
ftps-data
cifs
exchange
notes
imap
secure-imap
facebook
youtube
netflix
hulu
skype
msn-messenger-video
bittorrent
itunes
call-of-duty
voice-and-video
other
Mark
voice-and-video
voice-and-video
voice-and-video
voice-and-video
voice-and-video
voice-and-video
other
other
Mark
business-and-productivity-tools
other
file-sharing
file-sharing
file-sharing
file-sharing
email
email
email
email
browsing
voice-and-video
voice-and-video
voice-and-video
voice-and-video
voice-and-video
file-sharing
file-sharing
other
Mark
46
Mark
Mark
Mark
Mark
Mark
Mark
Mark
18
Mark
Mark
Mark
Mark
Mark
Mark
Mark
Mark
Mark
Mark
Mark
Mark
Mark
Mark
Mark
Mark
Mark
Mark
Mark
Mark
Mark
46
34
32
24
24
24
24
24
18
18
18
10
10
10
10
10
10
10
10
10
8
8
8
8
8
8
8
8
8
Associated WLAN IDs

:
Associated Remote LAN IDs :
Associated Guest LAN IDs :
(Cisco WLC) >
AVC profiles can also be attached to the WLAN via the WLC CLI, as shown in Example 24-7.
Example 24-7 WLC CLI-Attaching AVC Profiles to WLANs Example
(Cisco WLC) > config wlan avc 1 profile AVC-APPS enable
! This command applies the AVC profile "AVC-APPS" to WLAN ID 1
show avc profile detailed (as shown in Example 24-8)
show wlan (as shown in Example 24-9)
Example 24-8 AVC Profile Verification: show avc profile detailed

(Cisco WLC) > show avc profile detailed AVC-APPS
Application-Name
================
cisco-phone
=======================
voice-and-video
Action
======
Mark
DSCP
====
46
<snip>
Associated WLAN IDs
: 1
Associated Remote LAN IDs :
24-41
Chapter 24
Associated Guest LAN IDs
(Cisco WLC) >
Example 24-9 AVC Profile Verification: show wlan

(Cisco WLC) >show wlan 1
WLAN Identifier..................................
Profile Name.....................................
Status...........................................
1
BYOD_Employee
BYOD-Employee
Enabled
<snip>
Quality of Service............................... Platinum
<snip>
AVC Visibilty.................................... Enabled
AVC Profile Name................................. AVC-APPS
(Cisco WLC) >
AP Access Switch Downstream QoS Policies

The purpose of network QoS policies is to ensure that enterprise application classes will map into the
correct WMM access categories (and vice versa). Since the admission to the WMM access categories is
based on 802.11e UP values, which in turn are based on DSCP-to-UP translations (as covered in Step 3
of Figure 24-13), the packets need to enter the AP with the necessary (outer) DSCP values (of the
CAPWAP packet) to achieve the desired mappings. This requirement is underscored by the fact that the
WLC/AP QoS Translation Table (Table 24-4) is not modifiable and neither is the default
DSCP-to-CoS/UP mapping (Table 24-5). Therefore the final point that an administrator could correctly
set (or reset) DSCP values in packets before handing these off to the AP to ensure the traffic is placed in
the desired WMM access category is at the egress interface of the network access switch to which the
AP is connected (shown as point C in Figure 24-14).
Note
Granted, it would be possible to perform DSCP remarking within the Cisco WLC via an AVC policy.
Such an AVC policy would match on an application type(s) and then set this to a differing DSCP value
as used in the enterprise campus network. However AVC policies apply in both directions
simultaneously (and there is no option to apply these in the downstream or upstream direction only).
Therefore such an AVC policyintended for downstream remarkingwould include the undesired
effect of marking these application types incompatibly with the enterprise models for traffic in the
upstream direction towards the wired network.
The details of the network downstream DSCP remarking policy will vary according to the enterprise
application-class models in use. To illustrate a cross-section of marking-model variationsas well as
Catalyst switching platform variationsthe following mappings examples will be considered in detail:
Four-class enterprise model mapped to WMM on a Catalyst 3750-X series switch (Four-Class
Enterprise to WMM Mapping Model)
Eight-class enterprise model mapped to WMM on a Catalyst 4500E series switch with Supervisor
7-E (Eight-Class Enterprise to WMM Mapping Model)
24-42
Chapter 24

Twelve-class enterprise model mapped to WMM on a Catalyst 6500 series switch with Supervisor
2T (Twelve-Class Enterprise to WMM Mapping Model)
Four-Class Enterprise to WMM Mapping Model

If the enterprise has deployed a four-class strategic model, then this allows for a 1:1 mapping into the
four WMM access categories. The default mapping for a four-class enterprise model to WMM is shown
in Figure 24-24.
Figure 24-24
Default Downstream Four-Class Enterprise Model Mapping to WMM
4-Class Strategic
Enterprise Model
DSCP
WMM Model +
802.11e User Priority
UP 7
Realtime
EF
Control
CS3
Transactional Data
AF2
UP 6
Platinum
UP 5
UP 4
Gold
UP 3
Silver
UP 0
DF
UP 1
Bronze
294190
UP 2
Best Effort
As can be seen in Figure 24-24, if the QoS Translation Table (Table 24-4) and default mappings
(Table 24-5) were applied on these four enterprise QoS classes, these would map to only two access
categories: Platinum (Voice) and Silver (Best Effort). The remaining two access categories would not
even be used. While this default mapping will ensure voice quality, no other application will benefit from
wireless QoS.
An alternative approach would be to perform remarking at the network access switch (connecting to the
wireless AP) at the egress interface in the outbound direction such that the Control/Signaling application
class is remarked to a DSCP value that will map to an UP value (on the AP) that will, in turn, be assigned
to the Gold WMM AC. Similarly, Best Effort traffic may be mapped to a DSCP value that will map to
an UP value that will, in turn, be assigned to the Bronze WMM AC. This re-mapping approach would
then leave the Silver WMM AC to exclusively service Transactional Data applications and thereby
reflect the same overall relative priority of servicing as the original model. The modified four-class
mapping model is shown in Figure 24-26.
Perhaps the question may arise: why not just configure an AVC policy on the WLC to match signaling
traffic and remark it to a DSCP value that will map to the Gold WMM AClike say CS4/DSCP
32rather than configuring mapping policies on the access switch? To answer this, it should be kept in
mind that such an AVC marking policy on the WLCwhich operates both in the upstream and
downstream directionwill interfere with QoS policies on the rest of the wired network (which includes
both the upstream network as well as the transit network between the WLC and the APs). Specifically,
while such a policy may achieve the intended result in the downstream direction, it will include the
24-43
Chapter 24
unintended effect of marking signaling to CS4 (rather than CS3) in the upstream direction also, which
would be incompatible with the rest of the enterprise strategic policy and would have to be remapped at
the WLC upstream switch. Furthermore, Signaling traffic marked on the WLC to CS4 by AVC and
transiting in the downstream direction would have no QoS applied over the wired network between the
WLC and the APs unless the administrator modified all the policies in the path to accommodate.
Therefore, a much simpler approach to achieve the same end result is to include a simple remarking
policy on the final access switch connecting to the AP.
However, rather than remapping signaling traffic to a code-point that may be used for another
application, it may be better to remark signaling to a non-standard codepoint for this one-time operation,
such as DSCP 33. DSCP 33 would map (by default) to the Gold WMM AC and would uniquely identify
this remapped signaling traffic.
Similarly the default Best Effort class could be remapped on the network access switch to a non-standard
codepoint that would be assigned to the Bronze WMM AC-such as DSCP 9. However, some platforms,
such as the Catalyst 3750, do not support egress marking policies and only support
marking/remarking/DSCP-mutation policies on ingress. In such a case, remarking Best Effort traffic on
access switch ingress will affect BE marking on all interfaces and not just the interface connecting to the
access point.
In such a case, a more elegant method would be to modify the QoS Profile for the WLAN so that the
Unicast/Multicast Default Priority for the WLAN is set to Background instead of Best Effort, as shown
in Figure 24-25.
Figure 24-25
Modifying the Platinum WLC QoS Profile-Best Effort 'Background
It bears noting that assigning the default class to the Background WMM category will marginally delay
best effort traffic, however this is the nature of QoS as there is always a tradeoff. In this scenario, this is
the necessary cost of providing superior levels of service to the signaling and transactional data
application classes, thus providing the four levels of service required to meet their strategic business
objectives of QoS.
The modified mapping of a four-class enterprise model to WMM is shown in Figure 24-26.
24-44
Chapter 24

Figure 24-26
Modified Downstream Four-Class Enterprise Model Mapping to WMM
4-Class Strategic
Enterprise Model
DSCP
WMM Model +
UP 7
Realtime
EF
UP 6
Platinum
UP 5
Control
CS3
DSCP 33
UP 4
Gold
UP 3
Transactional Data
AF2
Silver
UP 0
DF
UP 1
Bronze
294192
UP 2
Best Effort
Catalyst 3750 Configuration Example

To highlight platform-specific syntax, features, and limitations, each mapping model is presented on a
different Catalyst switching platform. This four-class enterprise mapping to WMM AC is presented on
the Catalyst 3750 (which will be identical to configuration for the Catalyst 2960 and 3560 switches also).
As noted, the Catalyst 3750 does not support egress remarking; only ingress marking or ingress
DSCP-mutation are supported, as shown in Figure 24-27.
24-45
Chapter 24
Figure 24-27
Catalyst 3750 Four-Class Enterprise to WMM Marking and Mapping Policies
Downstream
CAWAP Tunnels
AP DSCP-to-UP/WMM Mapping
DSCP 33 is mapped to UP 4
and Gold AC
WLC
Catalyst 3750
Access Switch
Catalyst 3750 Egress Queuing

DSCP 33 is mapped to same
egress queue as CS3
802.1Q Trunk
WLC
Switch
AVC Policy
Signaling Protocols are marked
CS3 in both directions
QoS Profile
Best Effort is mapped to
Background WMM AC
Catalyst 3750 Remarking/DSCP-Mutation

CS3 is remarked/mutated to
DSCP 33 on ingress
294193
AP
The Catalyst 3750 employs Multilayer Switch QoS (MLS QoS), and as such DSCP-remarking policies
can be configured in one of two ways:
Class-based marking policy (as shown in Example 24-10)
DSCP-Mutation (as shown in Example 24-11)
Example 24-10 Catalyst 3750 Downstream Four-Class Enterprise Model Mapping Policy to WMM via
Class-Based Marking
! This section configures the class-map
C3750-X(config-cmap)# class-map match-all SIGNALING
C3750-X(config-cmap)# match ip dscp cs3
! Signaling traffic is matched on DSCP CS3
! This section configures the Network Downstream Remarking policy-map

C3750-X(config-cmap)# policy-map DOWNSTREAM-WMM-REMARKING
C3750-X(config-pmap-c)# class SIGNALING
C3750-X(config-pmap-c)# set dscp 33
! Signaling is remarked DSCP 33 to map into WMM Gold downstream
! This section attaches the Downstream policy to the campus-side interface

C3750-X(config)# interface TenGigabitEthernet2/1/1
C3750-X(config-if)# mls qos trust dscp
! Configures the port to statically trust DSCP on ingress
C3750-X(config-if)# service-policy input DOWNSTREAM-WMM-REMARKING
! Attaches the Downstream DSCP remarking policy to the interface on ingress
This configuration can be verified with the commands:
show mls qos interface
show class-map
show policy-map
24-46
Chapter 24

show policy-map interface
Example 24-11 Downstream Four-Class Enterprise Model Mapping Policy to WMM via DSCP-Mutation
! This section configures the Downstream DSCP Mutation map
C3750-X(config)# mls qos map dscp-mutation DOWNSTREAM-WMM-MUTATION 24 to 33
! This section attaches the Downstream policy to the campus-side interface

C3750-X(config)# interface TenGigabitEthernet2/1/1
C3750-X(config-if)# mls qos dscp-mutation DOWNSTREAM-WMM-MUTATION
! Attaches the Downstream DSCP mutation map to the interface on ingress
show mls qos maps dscp-mutation
Additionally, this non-standard DSCP representing signaling traffic should be mapped to the same egress
queue as regular signaling traffic (marked CS3), as shown in Example 24-12.
Example 24-12 Catalyst 3750 Egress Queuing Configuration
! This section configures buffers and thresholds on Q1 through Q4
C3750(config)# mls qos queue-set output 1 buffers 15 30 35 20
! Queue buffers are allocated
C3750(config)# mls qos queue-set output 1 threshold 1 100 100 100 100
! All Q1 (PQ) Thresholds are set to 100%
! Q2T1 is set to 80%; Q2T2 is set to 90%;
! Q2 Reserve Threshold is set to 100%;
! Q2 Maximum (Overflow) Threshold is set to 400%
! Q3T1 is set to 100%, as all packets are marked the same weight in Q3
! Q4T1 is set to 60%; Q4T2 is set to 100%
! This section configures egress CoS-to-Queue mappings (if required)
C3750(config)# mls qos srr-queue output cos-map queue 1 threshold 3 4 5
! CoS 4 and 5 are mapped to egress Q1T3 (the tail of the PQ)
C3750(config)# mls qos srr-queue output cos-map queue 2 threshold 1 2
! CoS 2 is mapped to egress Q2T1
C3750(config)#mls qos srr-queue output cos-map queue 2 threshold 2 3
! CoS 3 is mapped to egress Q2T2
C3750(config)# mls qos srr-queue output cos-map queue 2 threshold 3 6 7
! CoS 6 and 7 are mapped to Q2T3
! CoS 0 is mapped to Q3T3 (the tail of the default queue)
! CoS 1 is mapped to Q4T3 (tail of the less-than-best-effort queue)
! This section configures egress DSCP-to-Queue mappings

C3750(config)# mls qos srr-queue output dscp-map queue 1 threshold 3 32 40 46
! DSCP CS4, CS5 and EF are mapped to egress Q1T3 (tail of the PQ)
C3750(config)# mls qos srr-queue output dscp-map queue 2 threshold 1 16 18 20 22
! DSCP CS2 and AF2 are mapped to egress Q2T1
24-47
Chapter 24
C3750(config)# mls qos srr-queue output dscp-map queue 2 threshold 1 26

! DSCP AF3 and AF4 are mapped to egress Q2T1
! DSCP CS3 and DSCP 33 is mapped to egress Q2T2
! DSCP CS6 and CS7 are mapped to egress Q2T3
! DSCP DF is mapped to egress Q3T3 (tail of the best effort queue)
! DSCP CS1 is mapped to egress Q4T1
! DSCP AF1 is mapped to Q4T3 (tail of the less-than-best-effort queue)
28 30 34 36 38
33
56
12 14
! This section configures interface egress queuing parameters

C3750(config)# interface range GigabitEthernet1/0/1-48
C3750(config-if-range)# queue-set 1
! The interface(s) is assigned to queue-set 1
C3750(config-if-range)# srr-queue bandwidth share 1 30 35 5
! The SRR sharing weights are set to allocate 30% BW to Q2
! 35% BW to Q3 and 5% BW to Q4
! Q1 SRR sharing weight is ignored, as it will be configured as a PQ
C3750(config-if-range)# priority-queue out
! Q1 is enabled as a strict priority queue
Note
show mls qos queue-set
show mls qos maps cos-output-q
show mls qos maps dscp-output-q
show mls qos interface interface x/y queueing
show mls qos interface interface x/y statistics
Additional design recommendations for the Catalyst 3750 can be found in the Medianet Campus QoS
Design 4.0 design chapter at:
_40.html#wp1099462.
Eight-Class Enterprise to WMM Mapping Model

If the enterprise has deployed an eight-class strategic model, then a simple 1:1 mapping is no longer
possible and some additional considerations need to be taken into account.
One such consideration is whether all eight traffic classes will have application traffic generated to
and/or from wireless mobile devices. For example, no mobile clients or devices should be transmitting
or receiving Network Control traffic (as this application class is intended for servicing the control plane
requirements of the network infrastructure).
Note
It also can be argued that no Streaming Video traffic should be sourced from mobile devices (although
these devices might be receivers of such streams). Nonetheless, since traffic for this class may be
presentprimarily in the downstream directionand as such will be included in the mapping model
(albeit with a dashed line to indicate that this application traffic is typically unidirectional in the
downstream direction only).
24-48

The default mapping for a four-class enterprise model to WMM is shown in Figure 24-28.
Figure 24-28
Default Downstream Eight-Class Enterprise Model Mapping to WMM
8-Class Strategic
Enterprise Model
DSCP
Voice
EF
Interactive Video
AF4
Streaming Video
CS4
Network Control
CS0
Signaling
CS3
Transactional Data
AF2
Best Effort
BE
Scavenger
CS1
WMM Model +
UP 7
UP 6
Platinum
UP 5
UP 4
Gold
UP 3
Silver
UP 0
UP 2
UP 1
Bronze
294194
Chapter 24
While this default Eight-Class mapping may be adequate for some environments, it should be noted that
there is no QoS provisioned for Transactional Data traffic (that may include VDI applications like Citrix
XenDesktop or VMware View) nor for Signaling traffic (which is control plane traffic for IP telephone
and/or IP video telephony applications)other than merely protecting these application classes from
Scavenger traffic.
Therefore, it may be desirable to remap these applications to the Gold access-category, using
non-standard codepoints (as in the previous example). In this case, Signaling traffic can again be mapped
to DSCP 33 and Transactional Data can be mapped to DSCP 35 at the AP access switch in the egress
direction,
Note
As both DSCP 33 and 35 map to the same UP value of 4, there is no advantage/disadvantage to marking
these applications to a higher/lower DSCP value, provided these maps to the desired WMM AC. The key
is keeping these values unique and distinct for traffic management purposes.
The modified eight-class mapping model is shown in Figure 24-29.
24-49
Chapter 24
Figure 24-29
Modified Downstream Eight-Class Enterprise Model Mapping to WMM
8-Class Strategic
Enterprise Model
DSCP
Voice
EF
Interactive Video
AF4
Streaming Video
CS4
Network Control
CS0
Signaling
CS3
Transactional Data
AF2
Best Effort
BE
Scavenger
CS1
WMM Model +
UP 7
UP 6
Platinum
UP 5
UP 4
Gold
UP 3
Silver
Note
UP 0
UP 1
Bronze
294195
UP 2
Best Effort traffic is assigned to the default Silver (Best Effort) WMM Access Category in the WLC
WLAN QoS Profile for this mapping model.
Catalyst 4500E Supervisor 7-E Example

This DSCP remarking tactical design adapted for the Catalyst 4500 is illustrated in Figure 24-30. Since
the Catalyst 4500 uses MQC QoS, it supports egress remarking. As such, only a single policy is required
on this switch: namely adapting the final egress queuing policy to remark the Signaling and
Transactional Data application classes to DSCP 33 and 35, respectively.
Note
Incidentally, the remarking policies and enforcement points for an Eight-Class Enterprise to WMM
Mapping Model on a Catalyst 4500 are the same as a Twelve-Class Enterprise to WMM Mapping Model
on a Catalyst 6500. As such, both are shown in a single diagram (Figure 24-30).
24-50

Figure 24-30
Catalyst 4500/6500 Eight-Class/Twelve-Class Enterprise to WMM Marking and

Mapping Policies
Downstream
CAWAP Tunnels
D
AP
AP DSCP-to-UP/WMM Mapping
DSCP 33 is mapped to UP 4
and Gold AC
802.1Q Trunk
WLC
C
Catalyst 4500/6500
Access Switch
WLC
Switch
AVC Policy
Signaling Protocols are marked
CS3 in both directions
Catalyst 4500 Egress Queuing and Remarking

CS3 is mapped to egress queue and remarked DSCP 33
AF21 is mapped to egress queue and remarked to DSCP 35
QoS Profile
Best Effort is mapped to
Silver WMM AC
294196
Chapter 24
This modified eight-class mapping configuration example is presented on the Catalyst 4500-E series
switch (with Supervisor 7-E), as shown in Example 24-13. Since MQC only supports one service-policy
statement attached to a given interface in a single direction, the egress remarking policy must be
combined with the (eight-class) egress queuing policy as a single MQC service-policy in the output
direction, as shown in Example 24-13.
Example 24-13 Catalyst 4500 Downstream Eight-Class Enterprise Model Queuing and Mapping Policy
to WMM
! This section configures the class-maps for the egress queuing policy
C4500(config)# class-map match-any PRIORITY-QUEUE
C4500(config-cmap)# match dscp ef
! VoIP (EF) is mapped to the PQ
C4500(config)# class-map match-all INTERACTIVE-VIDEO-QUEUE
C4500(config-cmap)# match dscp af41 af42 af43
! Interactive-Video (AF4) is assigned a dedicated queue
C4500(config)# class-map match-all STREAMING-VIDEO-QUEUE
! Streaming-Video (AF3) is assigned a dedicated queue
C4500(config)# class-map match-any CONTROL-QUEUE
C4500(config-cmap)# match dscp cs6
! Network Control (CS6) is mapped to a dedicated queue
C4500(config)# class-map match-any SIGNALING-QUEUE
! Signaling (CS3) is mapped to a dedicated queue
C4500(config)# class-map match-all TRANSACTIONAL-DATA-QUEUE
! Transactional Data (AF2) is assigned a dedicated queue
C4500(config)# class-map match-all SCAVENGER-QUEUE
! Scavenger (CS1) is assigned a dedicated queue
! This section configures the 1P7Q1T+DBL egress queuing policy-map

C4500(config)# policy-map 1P7Q1T+DBL+DOWNSTREAM-MAPPING
C4500(config-pmap-c)# class PRIORITY-QUEUE
C4500(config-pmap-c)# priority
24-51
Chapter 24
! Defines a priority queue

C4500(config-pmap-c)# class INTERACTIVE-VIDEO-QUEUE
C4500(config-pmap-c)# bandwidth remaining percent 23
C4500(config-pmap-c)# dbl
! Defines a interactive-video queue with 23% BW remaining + DBL
C4500(config-pmap-c)# class STREAMING-VIDEO-QUEUE
! Defines a streaming-video queue with 10% BW remaining + DBL
C4500(config-pmap-c)# class CONTROL-QUEUE
! Defines a control/management queue with 5% BW remaining
C4500(config-pmap-c)# class SIGNALING-QUEUE
! Defines a signaling queue with 2% BW remaining
C4500(config-pmap-c)# set dscp 33
! Remarks signaling traffic to DSCP 33 for WMM Gold downstream mapping
C4500(config-pmap-c)# class TRANSACTIONAL-DATA-QUEUE
! Defines a transactional data queue with 24% BW remaining + DBL
! Remarks transactional data to DSCP 35 for WMM Gold downstream mapping
C4500(config-pmap-c)# class SCAVENGER-QUEUE
! Defines a (minimal) scavenger queue with 1% BW remaining/limit
C4500(config-pmap-c)# class class-default
! Provisions the default/Best Effort queue with 25% BW remaining + DBL
! This section attaches the egress queuing & mapping policy to AP interface
C4500(config)# interface GigabitEthernet 3/1
C4500(config-if)# service-policy output 1P7Q1T+DBL+DOWNSTREAM-MAPPING
! Attaches the combined egress queuing and egress remarking policy to the int
Note
Additional detail on Catalyst 4500 queuing policy recommendations can be found in Medianet Campus
QoS Design 4.0 design chapter at:
_40.html#wp1100873.
Note
Class-maps defined for egress-queuing policies require unique names from any ingress-policy
class-maps; otherwise classification errors may occur due to overlapping classification-logic. Therefore
the class-maps names in this example have -QUEUE appended to them.
Note
It is recommended to use match dscp and set dscpas opposed to match ip dscp and set ip dscpas
the former will match on both IPv4 and IPv6 packets, whereas the latter will match only on IPv4 packets.
Although AVC does not yet classify IPv6 traffic, these packets can still be properly mapped at this node
to the correct downstream WMM access category.
show class-map
show policy-map
24-52
Chapter 24

Twelve-Class Enterprise to WMM Mapping Model

If the enterprise has deployed a twelve-class strategic model, then further class-pruning and
application-class collapsing needs to take place.
To this end, both the Network Control and the Operations/Administration/Management application
traffic classes can be pruned out of the mapping model, as wireless endpoint devices should not be
generating nor receiving traffic from these classes (as these classes are intended as control plane classes
for the network infrastructure).
It can be argued that neither Broadcast Video nor Streaming Video traffic should be sourced from mobile
devices (although these devices might be receivers of such streams). Nonetheless, since traffic for this
class may be present, it is included in the mapping model (albeit with a dashed line to indicate that this
application traffic is typically unidirectional in the downstream direction).
The default mapping for a twelve-class enterprise model to WMM is shown in Figure 24-31.
Figure 24-31
Default Downstream Twelve-Class Enterprise Model Mapping to WMM
12-Class Strategic
Enterprise Model
DSCP
Voice
EF
Broadcast Video
CS5
AF4
CS4
AF3
Network Control
CS0
Signaling
CS3
OAM
CS2
Transactional Data
AF2
Bulk Data
AF1
Best Effort
BE
Scavenger
CS1
WMM Model +
UP 7
UP 6
Platinum
UP 5
UP 4
Gold
UP 3
Silver
UP 0
UP 2
UP 1
Bronze
294197
Note
As with the previous Eight-Class Model, the default Twelve-Class model provisions no QoS for
Transactional Data traffic (that may include VDI applications like Citrix XenDesktop or VMware View)
nor for Signaling traffic (which is control plane traffic for IP telephone and/or IP video telephony
applications)other than merely protecting these from Scavenger traffic.
Therefore it may be desirable to remap these applications to the Gold WMM access-category, as shown
in Figure 24-32.
24-53
Chapter 24
Modified Downstream Twelve-Class Enterprise Model Mapping to WMM
12-Class Strategic
Enterprise Model
DSCP
Voice
EF
Broadcast Video
CS5
AF4
CS4
AF3
Network Control
CS0
Signaling
CS3
OAM
CS2
Transactional Data
AF2
Bulk Data
AF1
Best Effort
BE
Scavenger
CS1
WMM Model +
UP 7
UP 6
Platinum
UP 5
UP 4
Gold
UP 3
Silver
UP 0
UP 2
UP 1
Bronze
294198
Figure 24-32
Catalyst 6500 Supervisor 2T Example

This modified twelve-class mapping example is presented on the Catalyst 6500 series switch (with
Supervisor 2T). The Catalyst 6500 employs Cisco Common Classification Policy Language (C3PL) QoS
and, as such, supports egress class-based marking. Therefore class-based marking policies are only
applied on the AP-side network interface, as with the Catalyst 4500, and are shown in Figure 24-31.
Unlike IOS MQC, C3PL does not allow for the combining of class-based marking policies with queuing
policies. However both may be simultaneously applied to an interface in a given direction because
queuing policies require the additional keywords type lan-queuing in their respective class-maps and
policy-maps (and class-based marking policies do not).
The Catalyst 6500 supports ingress queuing, but such a policy would technically not be required on an
interface connecting to an AP as this interface would not be oversubscribed (due to the APs capacity
being less than 1 Gbps).
Furthermore, the egress queuing policy applied to the interface would remain unchanged, as queuing
policies on Catalyst 6500 10/100/1000 interfaces are CoS-based and as such remarked Signaling and
Transactional-Data traffic cannot be assigned to the same queues as Signaling. This is because remarked
Signaling (DSCP 33) and remarked Transactional Data (DSCP 35) would map to CoS 4, whereas
Signaling traffic (DSCP CS3/24) maps to CoS 3. These remarked flows will receive a preferential QoS
treatment, but it will be the one ordinarily intended for the video application classes that traditionally
align to CoS 4, rather than the Data and Signaling classes that map to CoS 3.
Thus two policies will be present on the AP interface on the Catalyst 6500:
A class-based marking policy to remap and to restore temporary DSCP values for Signaling and
Transactional Data traffic (as shown in Example 24-14).
An egress C3PL queuing policies to map 12-application classes into a 4 hardware queue (1P3Q8T)
model and provide intra-queue QoS via DSCP-based WRED.
24-54
Chapter 24

Note
Since the egress queuing policy remains unchanged, it is not included here for the sake of brevity, but
can be referenced from the Medianet Campus QoS Design Guide at
_40.html.
Therefore, altogether two separate service-policy statements will be applied to a Catalyst 6500
10/100/1000 interface connecting to an AP, as shown in Example 24-14.
service-policy output DOWNSTREAM-WMM-REMARKING
service-policy type lan-queuing output EGRESS-1P3Q8T
Example 24-14 Catalyst 6500 Downstream Class-Based Marking Mapping Policies for WMM
! This section configures the class-maps
C6500(config-cmap)# class-map match-any SIGNALING
! Signaling from campus is matched on CS3
C6500(config-cmap)# class-map match-all TRANSACTIONAL-DATA
! Transactional Data from campus is matched on AF2
! This section configures the Downstream DSCP-Restoration Policy

C6500(config)# policy-map DOWNSTREAM-WMM-REMARKING
C6500(config-pmap)# class SIGNALING
! Signaling is mapped to DSCP 33 for Downstream WMM Gold AC
C6500(config-pmap-c)# class TRANSACTIONAL-DATA
! Transactional-Data is mapped to DSCP 35 for Downstream WMM Gold AC
! This section applies the downstream remarking policies to AP interface

C6500(config-pmap-c)# interface GigabitEthernet1/10
C6500(config-if)# service-policy output DOWNSTREAM-WMM-REMARKING
! Attaches the DOWNSTREAM-WMM-REMARKING policy to the AP interface
C6500(config-if)# service-policy type lan-queuing output EGRESS-1P7Q4T
! Attaches the EGRESS-1P3Q8T queuing policy to the interface
Note
It is recommended to use match dscp and set dscpas opposed to match ip dscp and set ip dscpas
the former will match on both IPv4 and IPv6 packets, whereas the latter will match only on IPv4 packets.
Although AVC does not yet classify IPv6 traffic, these packets can still be properly mapped at this node
to the correct downstream WMM access category.
show class-map
show policy-map

The following policies are required for upstream flows:
24-55
Chapter 24
Wireless Device Marking and WMM PoliciesQoS policies are embedded within mobile
application software and operating systems which can mark UP and DSCP values as well as assign
application traffic into the respective WMM access categories in the radio-upstream direction. These
policies are shown as point A in Figure 24-33.
AP Access-Switch QoS PoliciesThese policies are typically applied on access switch ingress and
are shown as point B in Figure 24-33.
WLC AVC ProfilesApplied on WLC ingress and are shown as point C in Figure 24-15; when
configured, these policies apply in both directions-therefore no additional configuration is required
to configure AVC QoS in the upstream direction.
WLC QoS ProfilesApplied on WLC egress and are shown as point D in Figure 24-15; when
configured, these policies apply in both directions-therefore no additional configuration is required
to configure QoS in the upstream direction.
Figure 24-33
Upstream QoS Policy Configuration Points in Wired/Wireless Networks
CAWAP Tunnels
A
AP
D
WLC
802.1Q Trunk
WLC
Switch
Upstream
294199
AP Access
Switch
Each of these sets of policies will be covered in detail in the respective following sections.
Wireless Device Marking and WMM Policies

The initial upstream over-the-air WMM policies are up to the mobile application vendor to include
within their application software and the network administrator has no control over these policies.
However, they really only have effect in the upstream first-hop to the AP (whereas the majority of
traffic to wireless devices flows in the downstream direction, which administrators can control via WLC
AVC and QoS profiles).
Nonetheless, it is not a matter of every application on every BYOD device behaving in the same manner.
Consider Figure 24-34, which shows various Cisco, Apple, and Samsung phones and their
corresponding voice and signaling IP and DSCP marking values.
24-56
Chapter 24

Figure 24-34
Mobile Wireless IP Phone/Smartphone 802.11 UP and DSCP Marking Values by

Hardware Vendor1
Additionally, 802.11 UP and DSCP markings are virtually non-existent on tablet devices, as shown by
Figure 24-35.
Figure 24-35
Mobile Wireless Tablet 802.11 UP and DSCP Marking Values by Hardware Vendor2
And finally UP and DSCP markings for laptop applications are shown in Figure 24-36, which are
similarly absent.
Figure 24-36
Mobile Laptop 802.11 UP and DSCP Marking Values by Hardware Vendor3
1. BYOD with QoS http://mrncciew.com/2013/01/08/byod-with-qos/

24-57
Chapter 24
Without WMM markings on these wireless client devices, these multimedia applications have reduced
quality on their radio upstream connections.
AP Access Switch Upstream QoS Policies

As shown in the above tables, most applications do not yet mark media and signaling flows. However
those that do typically mark signaling flows to UP 4 and DSCP CS3. This presents a slight misalignment
in QoS policies, as UP 4 will be mapped to (an outer CAPWAP DSCP value of) AF31 (as shown in
Figure 24-13) as it is received by the access point (refer to Table 24-4). As such, signaling traffic will
not have the proper QoS applied to it in the upstream direction in transit over the wired network between
the AP and the WLC. Only when it exits the WLC in the upstream direction is the original inner DSCP
value (of CS3) going to be used.
Therefore, to correct this, administrators can configure an ingress marking policy on the access switch
interface(s) connecting to wireless access points that receives traffic marked AF31 (which is derived by
the AP mapping for UP 4) and remarking these to DSCP CS3. Such remarking policies will now be
presented for the same access switches as before, specifically, the:
Catalyst 3750
Catalyst 4500
Catalyst 6500

The upstream ingress configuration required on a Catalyst 3750 switch to remap Signaling traffic from
(the AP UP 4 mapped marking of) AF31 to the enterprise marking of CS3 is shown in Example 24-15.
Example 24-15 Catalyst 3750 Upstream Signaling-Marking Restoration
C3750-X(config-cmap)# class-map match-all AP-SIGNALING
C3750-X(config-cmap)# match ip dscp af31
! Signaling traffic from the AP is matched on DSCP AF31
! This section configures the Network Upstream Remarking policy-map

C3750-X(config-cmap)# policy-map UPSTREAM-WMM-REMARKING
C3750-X(config-pmap-c)# class AP-SIGNALING
C3750-X(config-pmap-c)# set dscp cs3
! Signaling is remarked to DSCP 24 to align to enterprise QoS model
! This section attaches the upstream policy to the AP-connected interface

C3750-X(config)# interface GigabitEthernet1/0/10
C3750-X(config-if)# service-policy input UPSTREAM-WMM-REMARKING
! Attaches the upstream DSCP remarking policy to the AP interface on ingress
show class-map
show policy-map
24-58
Chapter 24


C4500(config-cmap)# class-map match-all AP-SIGNALING
C4500(config-cmap)# match dscp af31

C4500(config-cmap)# policy-map UPSTREAM-MAPPING
C4500(config-pmap-c)# class AP-SIGNALING
C4500(config-pmap-c)# set dscp cs3
! This section attaches the upstream and downstream policies to AP interface

C4500(config)# interface GigabitEthernet 3/1
C4500(config-if)# service-policy input UPSTREAM-MAPPING
! Attaches the upstream DSCP remarking policy to the AP interface on ingress
C4500(config-if)# service-policy output 1P7Q1T+DBL+DOWNSTREAM-MAPPING
! Attaches the combined egress queuing and remarking policy to the AP interface
show class-map
show policy-map

C6500(config-cmap)# class-map match-all AP-SIGNALING
C6500(config-cmap)# match dscp af31

C6500(config-cmap)# policy-map UPSTREAM-WMM-REMARKING
C6500(config-pmap-c)# class AP-SIGNALING
C6500(config-pmap-c)# set dscp cs3
! This section applies the upstream & downstream remarking policies to AP interface
C6500(config-pmap-c)# interface GigabitEthernet1/10
C6500(config-if)# service-policy input UPSTREAM-WMM-REMARKING
! Attaches the UPSTREAM-WMM-REMARKING policy to the AP interface on ingress
C6500(config-if)# service-policy output DOWNSTREAM-WMM-REMARKING
! Attaches the DOWNSTREAM-WMM-REMARKING policy to the AP interface on egress
C6500(config-if)# service-policy type lan-queuing output EGRESS-1P7Q4T
24-59
Chapter 24
Application Visibility and Management
! Attaches the EGRESS-1P3Q8T queuing policy to the interface on egress
show class-map
show policy-map

The Cisco AVC feature can be used for application monitoring and management on:
Centralized Wireless LAN controllers
Converged access platforms
Each of these platforms is presented in turn.
Centralized WLC Application Visibility and Management

Cisco AVC for wireless LAN controllers provides application visibility:
Globally
On an WLAN basis
On an individual client basis
Additionally, AVC supports the export of application statistics via Netflow.

Each of these options is presented in turn.
Note
It should be noted that in order to see any application visibility statistics on either a global, WLAN, or
client level, the Application Visibility feature must be enabled on at least one WLAN, as shown in
Figure 24-17.
Global Application Visibility

To see application traffic at a global level for all traffic traversing the WLC, click the MONITOR
heading bar and from the main Summary screen (in the bottom right corner) the Top 10 applications are
summarized by name, as well as by Packet and Byte Count, as shown in Figure 24-37.
24-60
Chapter 24

Figure 24-37
Global Application Visibility Monitoring
This information can also be collected via CLI by issuing the command:
show avc statistics top-apps { upstream | downstream}
Per-WLAN Application Visibility

To see application traffic at a WLAN-level, perform the following steps.
1.
Click the Monitor heading bar.
2.
Select the Applications link on the lower-left.
3.
Select the WLAN ID to be monitored.
Application traffic for the WLAN is summarized in the following tabs:
AggregateIncludes both upstream and downstream application traffic.
UpstreamUpstream-only application traffic.
DownstreamDownstream-only application traffic.
Per-WLAN application visibility monitoring is shown in Figure 24-38.
24-61
Chapter 24
Figure 24-38
Per-WLAN Application Visibility Monitoring
This information can also be collected via CLI by issuing the commands:
show avc statistics wlan [WLAN_Number] top-apps { upstream | downstream}
show avc statistics wlan [WLAN_Number] top-app-groups { upstream | downstream}
show avc statistics wlan [WLAN_Number] application [application_name]
Per-Client Application Visibility

To see application traffic at a client-level, perform the following steps.
1.
Click the Monitor heading bar.
2.
Select the Clients link on the left.
3.
Select the Client MAC Addr of the client to be monitored.
Per-Client application visibility monitoring is shown in Figure 24-39.
24-62
Chapter 24

Figure 24-39
Per-Client Application Visibility Monitoring
This information can also be collected via CLI by issuing the commands:
show avc statistics client [client_mac]
show avc statistics client [client_mac] application [application_name]
NetFlow Export
NetFlow is a protocol that provides information about network users and applications, peak usage times,
and traffic routing. The NetFlow protocol collects IP traffic information from network devices to monitor
traffic. The NetFlow architecture consists of the following components:
CollectorEntity that collects all the IP traffic information from various network elements.
ExporterNetwork entity that exports the template with the IP traffic information. The WLC can
be configured to act as an exporter.
NetFlow Export Configuration-GUI

Netflow Export can be configured on the WLC via the GUI by performing the following steps:
1.
Click the Wireless heading bar and expand the Netflow link and click Exporter.
2.
Click New.
3.
Enter the Exporter name, IP address, and the port number.
4.
Click Apply.
5.
Click Save Configuration.
24-63
Chapter 24
NetFlow Monitoring can be configured by following these steps:

1.
Click the Wireless heading bar and expand the Netflow link and click Monitor.
2.
Click New and enter the Monitor name.
3.
On the Monitor List page, click the Monitor name to open the Netflow Monitor > Edit page.
4.
Choose the Exporter name and the Record name from the respective drop-down lists.
5.
Click Apply.
6.
A NetFlow Monitor can be associated with a WLAN by following these steps:

1.
Click the WLANs heading bar and click the WLAN ID to open the WLANs > Edit page.
2.
In the QoS tab, choose the NetFlow Monitor from the Netflow Monitor drop-down list.
3.
Click Apply.
4.
NetFlow Export Configuration-CLI

Create an Exporter by entering this command:
config flow create exporter exporter-name ip-addr port-number
Create a NetFlow Monitor by entering this command:

config flow create monitor monitor-name
Associate a NetFlow Monitor with an Exporter by entering this command:

config flow add monitor monitor-name exporter exporter-name
Associate a NetFlow Monitor with a Record by entering this command:

config flow add monitor monitor-name record ipv4_client_app_flow_record
Associate a NetFlow Monitor with a WLAN by entering this command:

config wlan flow wlan-id monitor monitor-name enable
NetFlow configurations can be verified with the following show commands:
show flow monitor summary
show flow exporter {summary | statistics}
Converged Access Application Visibility

On the Converged Access platforms, such as the Cisco WLC5760 and Catalyst 3850, the Application
Visibility and Control feature (in its initial release) can only be used for application visibility monitoring
and currently cannot be used to set QoS policies to control network traffic. Therefore this feature
might be more accurately expressed as a truncated acronym AV for Application Visibility; however
for the sake of consistency we will continue to refer to it as AVC.
24-64
Chapter 24

Note
System testing manifested an incompatibility of the AVC feature in conjunction with the TrustSec
feature on the Cisco 5760 wireless LAN controller in Cisco IOS XE Release 3.3SE. However this issue
has been resolved and successfully tested and will be included in the next major software release.
Nonetheless, AVC has important use cases in capacity planning and network usage baselining over
converged access networks. For example, if network administrators are provided visibility into the top
bandwidth-consuming applications and/or are able to trend application-usage, then they can better plan
for network infrastructure upgrades. Additionally, armed with such information, they can elect control
application traffic over the Cisco wired network in the downstream direction (which typically represents
the majority of WLAN traffic anyway).
The AVC feature on converged access platforms performs deep packet inspection via the NBAR2 engine
to identify a wide array of applications on either a per-WLAN basis or on a per-client basis. This would
include the ability to:
Identify the Top Applications on each WLAN (in terms of byte counts and packet counts)
Identify the Top Users on each WLAN (in terms of byte counts and packet counts)
Identify the Top Details on each WLAN (to cross-reference Top Application and Top User traffic
details)
For example, break down Top Applications within a given WLAN on a per-user basis, complete
with byte count and packet count statistics.

Such Top-n reports can be generated on a Per-WLAN basis or a Per-Client basis, as will be shown.
Additionally, such information is available via CLI as well as via the web GUI.
Such statistics can answer questions like:
Which users are contributing to the Top Application usage?
What applications are the Top Users using?
Converged Access AVC Configuration via CLI

The steps to configure AVC on converged access platforms via CLI are:
To configure AVC, follow these general steps:
1.
Create a flow record.
2.
(Optional) Create a flow exporter.
3.
Create a flow monitor.
4.
Apply the flow monitor to a WLAN.
Each of these steps is detailed in turn.
Configure a Flow Record

The first step in configuring AVC for converged access platforms is to configure a flow record. A flow
record specifies the details of a given flow that is to be tracked by matching one or more of the following
parameters:
(IPv4) Source Address
(IPv4) Destination Address
Transport Protocol Source-Port
24-65
Chapter 24
Note
Transport Protocol Destination Port
Flow Direction
Application Name
WLAN SSID
AVC on the converged access platforms only supports IPv4 protocols.

Once the match details are specified so as to identify a discrete flow, then the flow record also specifies
the type of statistics and information that is to collected by the flow record, including:
Bytes
Packets
Access Point (BSSID) MAC address
Client MAC address
The syntax to configure a flow record on a converged access platform is shown in Example 24-18.
Example 24-18 Configuring a Flow Record via CLI
C3850(config)# flow record AVC-FLOW-RECORD
! defines a flow record with name "AVC-FLOW-RECORD"
C3850(config-flow-record)# match ipv4 protocol
! Matches IPv4 protocol
C3850(config-flow-record)# match ipv4 source address
! Matches flows by IPv4 source addresses
C3850(config-flow-record)# match ipv4 destination address
! Matches flows by IPv4 destination addesses
C3850(config-flow-record)# match transport source-port
! Matches flows by TCP/UDP source port
C3850(config-flow-record)# match transport destination-port
! Matches flows by TCP/UDP destination port
C3850(config-flow-record)# match flow direction
! Matches flows by direction
C3850(config-flow-record)# match application name
! Matches flows by AVC application names
C3850(config-flow-record)# match wireless ssid
! Matches flows by WLAN SSIDs
! This section details the statistics and information to be collected

! by the flow record
C3850(config-flow-record)# collect counter bytes long
! Enables a 64-bit counter for all bytes belonging to the flow
C3850(config-flow-record)# collect counter packets long
! Enables a 64-bit counter for all packets belonging to the flow
C3850(config-flow-record)# collect wireless ap mac address
! Captures the MAC of the AP
C3850(config-flow-record)# collect client mac address
! Captures the MAC of the client
Configure a Flow Exporter

An optional second step is to configure a flow exporter. The flow exporter defines the destination and
transport parameters of the management station that the flow details are to be exported to via Flexible
NetFlow (FNF). Application flow information is gathered by the NBAR2 engine on the access point and
sent to the management station using NetFlow version 9 format.
24-66
Chapter 24

The configuration of a flow exporter is shown in Example 24-19.

Example 24-19 Configuring a Flow Exporter via CLI
C3850(config)# flow exporter AVC-FLOW-EXPORTER
! Defines a flow exporter with name "AVC-FLOW-EXPORTER"
C3850(config-flow-exporter)# destination {hostname | ip-address}
! Specifies the hostname or destination IP address of the collector
C3850(config-flow-exporter)# transport udp port-value
! Specifies the UDP port
C3850(config-flow-exporter)# option application-table timeout seconds
! Optional: specifies the timeout value of the application table
C3850(config-flow-exporter)# option usermac-table timeout seconds
! Optional: specifies the timeout value of the client mac table
The configuration of a flow exporter can be verified with the show flow exporter verification command,
as displayed in Example 24-20.
Example 24-20 Verifying a Flow Exportershow flow exporter verification command
C3850# show flow exporter
Flow Exporter AVC-FLOW-EXPORTER:
Description:
User defined
Export protocol:
NetFlow Version 9
Transport Configuration:
Destination IP address: 10.0.1.99
Source IP address:
10.225.102.197
Transport Protocol:
UDP
Destination Port:
100
Source Port:
65353
DSCP:
0x0
TTL:
255
Output Features:
Used
Options Configuration:
usermac-table (timeout 1000 seconds)
application-table (timeout 1000 seconds)
C3850#
Configure a Flow Monitor

The next step in configuring AVC on a converged access platform is to configure a flow monitor. A flow
monitor associates a flow record with an optional flow exporter and can be applied to a WLAN. The
configuration of a flow monitor is shown in Example 24-21.
Example 24-21 Configuring a Flow Monitor via CLI
C3850(config)# flow monitor AVC-FLOW-MONITOR
! Configures a flow monitor with name "AVC-FLOW-MONITOR"
C3850(config-flow-monitor)# record AVC-FLOW-RECORD
! Associates the flow monitor with the "AVC-FLOW-RECORD" flow record
C3850(config-flow-monitor)# exporter AVC-FLOW-EXPORTER
! Associates the flow monitor with the "AVC-FLOW-EXPORTER" flow exporter
C3850(config-flow-monitor)# cache timeout active seconds
! Optional: specifies the active cache timeout in seconds
C3850(config-flow-monitor)# cache timeout inactive seconds
! Optional: specifies the inactive cache timeout in seconds
! Cisco recommends the inactive cache timeout to be greater than 90 seconds
24-67
Chapter 24
Apply the Flow Monitor to a WLAN

Once the flow monitor has been defined, then it can be applied to a given WLAN(s) and the direction of
application can be specified, as shown in Example 24-22.
Example 24-22 Applying a Flow Monitor to a WLAN via CLI
C3850(config)# wlan BYOD-EMPLOYEE
C3850(config-wlan)# ip flow monitor AVC-FLOW-MONITOR
! Applies the "AVC-FLOW-MONITOR" to the WLAN in the
C3850(config-wlan)# ip flow monitor AVC-FLOW-MONITOR
! Applies the "AVC-FLOW-MONITOR" to the WLAN in the
input
input direction
output
output direction
The application of a flow monitor to a WLAN can be verified with the show wlan verification command,
as illustrated in Example 24-23.
Example 24-23 Verifying a WLANshow wlan id verification command
WLC5760# show wlan id 1
WLAN Profile Name
: BYOD_Employee
================================================
Identifier
:
Network Name (SSID)
:
Status
:
Broadcast SSID
:
1
BYOD_Employee
Enabled
Enabled
<output truncated>
AVC Visibility
Netflow Monitor
Direction
Traffic
Netflow Monitor
Direction
Traffic
:
:
:
:
:
:
:
Enabled
AVC-FLOW-MONITOR
Input
IPv4
AVC-FLOW-MONITOR
Output
IPv4
Converged Access AVC Configuration via GUI

Converged access platforms can also be configured via the web GUI. Specifically, the wireless features
of these platforms can be configured via GUI by pointing a browser to
http://{hostname_or_IP_Address}/wireless.
Additionally, to facilitate operation, a default flow record (named wireless avc basic) and a default flow
monitor (named wireless-avc-basic) are preconfigured.
Note
If you are using a user-defined flow record and flow monitor, then the record name and monitor name
should be same. This is specific only for configuring AVC via the GUI (and does not apply for AVC CLI
configuration). You can use the flow monitor you have created either for upstream or downstream, or
both, but ensure that you use the same record name while mapping with the flow monitor.
The steps for configuring AVC via the GUI are detailed below:
Step 1
Choose Configuration > Wireless > WLAN.

The WLAN page appears, as shown in Figure 24-40.
24-68
Chapter 24

Figure 24-40
Step 2
WLAN Configuration Page
Click on corresponding WLAN ID to open WLAN Edit page and click AVC.
The Application Visibility page appears.
a.
Select the Application Visibility Enabled check box to enable AVC on a WLAN.
b.
In the Upstream Profile text box, enter the name of the AVC profile.
c.
In the Downstream Profile text box, enter the name of the AVC profile.
These options are shown in Figure 24-41, where the default flow monitor name (wireless-avc-basic) is
used in both directions.
Figure 24-41
Per-WLAN AVC Configuration Page
To enable AVC, you need to enter the profile names for the upstream and downstream profiles. The
profile names are the flow monitor names. By default, the flow monitor names (wireless-avc-basic)
appear in the Upstream Profile and Downstream Profile text boxes.
You can change the profile names for the upstream and downstream profiles, but ensure that the same
flow records are available for the flow monitors. Additionally, the upstream and downstream profiles can
have different profile names.
Step 3
Click Apply to apply AVC on the WLAN.
24-69
Chapter 24
Converged Access AVC Monitoring via CLI

Once the flow records, (optional exporters) and monitors have been configured and applied to a
WLAN(s), then these can be used to provide application visibility on either a:
Per-Access-Point basis
Per-WLAN basis
Per-client basis
Each of these options is discussed in turn.
CLI-Based Per-Access Point Application Visibility Monitoring

In converged access platform CLI, the command to display application visibility on a per-Access Point
basis is the show avc nbar statistics command, as presented in Example 24-24.
Example 24-24 CLI-Based Per-AP AVC Monitoring Examplesshow avc nbar statistics Verification
Command
ROD.BB01.e10c# show avc nbar statistics
Dumping NBAR2 Statistics :
ID
Protocol Name
=== =============
0
none
1
unknown
3
http
6
icmp
13
dhcp
16
secure-http
31
ntp
48
tftp
65
sip
66
rtcp
72
dns
82
youtube
83
skype
120
audio-over-http
122
video-over-http
461
itunes
1073 gmail
1083 yahoo-accounts
1306 webex-meeting
1312 ssl
1316 netflix
1404 ping
1421 netbios-ns
1434 ms-live-accounts
1440 google-accounts
1444 salesforce
1445 windows-azure
1446 hotmail
1453 twitter
1454 facebook
1456 google-services
1462 yahoo-mail
1469 facetime
================================
24-70
IN
OUT
==
===
14374
0
57905
34933
42202
72505
113
35
789
535
477
1111
244
6
110
21
254
257
31
0
5089
4274
1247
1558
678
800
30369
83941
95751
329352
155529
342414
3220
4635
33
39
872
704
23886
27554
11
9
665
625
35
0
24
28
251
209
2254
2124
1627
4495
489
337
5
5
414
414
18010
20442
6840
5655
60
42
Chapter 24

CLI-Based Per-WLAN Application Visibility Monitoring

In converged access platform CLI, the command to display application visibility on a per-WLAN basis
is the show avc wlan command, which can take the following parameters:
show avc wlan <wlan-id> top <number> application [aggregate | downstream |upstream]
Displays the Top-N Applications by WLAN, where:
wlan-id represents the name of the WLAN.
number (1-30) is the number of Top-N Applications to be displayed.
aggregate displays the upstream and downstream aggregate stats for Top-N applications.
downstream displays the downstream stats (only) for Top-N applications.
upstream displays the upstream stats (only) for Top-N applications.
Example 24-25 CLI-Based Per-WLAN AVC Monitoring Examplesshow wlan id Verification Command
CT5760# show avc wlan BYOD_Employee top 10 app aggregate
Cumulative Stats:
No. AppName
Packet-Count
Byte-Count
AvgPkt-Size usage%
-----------------------------------------------------------------------------------------------------1
itunes
278859
254127765
911
39
2
video-over-http
218949
252675674
1154
38
3
http
52734
41694075
790
6
4
ssl
48555
26677396
549
4
5
audio-over-http
44896
47851856
1065
7
6
google-services
25924
21600740
833
3
7
unknown
14201
1114028
78
0
8
yahoo-mail
12495
11850149
948
2
9
gmail
5530
4473175
808
1
10
salesforce
4248
1826766
430
0
Last Interval(90 seconds) Stats:

No. AppName
Packet-Count
Byte-Count
AvgPkt-Size usage%
-----------------------------------------------------------------------------------------------------1
yahoo-mail
3394
3247526
956
87
2
skype
363
295879
815
8
3
gmail
183
56892
310
2
4
unknown
173
16114
93
0
5
http
126
82495
654
2
6
ssl
106
29181
275
1
7
dns
38
4717
124
0
8
salesforce
16
11923
745
0
9
hotmail
12
4911
409
0
10
dhcp
6
1968
328
0
CLI-Based Per-Client Application Visibility Monitoring

In converged access platform CLI, the command to display application visibility on a per-client basis is
the show avc client command, which can take the following parameters:
show avc client <client_MAC>
top <number> application [aggregate | downstream |upstream]
Displays the Top-N Applications by Client, where:
client_MAC is the clients MAC address in 0.0.0 format.
number (1-30) is the number of Top-N Applications to be displayed.
aggregate displays the upstream and downstream aggregate stats for Top-N applications.
downstream displays the downstream stats (only) for Top-N applications.
24-71
Chapter 24
upstream displays the upstream stats (only) for Top-N applications.
Example 24-26 CLI-Based Per-Client AVC Monitoring Examplesshow avc client Verification Command
CT5760# show avc client b4f0.abd0.28a6 top 10 app aggregate
Cumulative Stats:
No. AppName
Packet-Count
Byte-Count
AvgPkt-Size usage%
-----------------------------------------------------------------------------------------------------1
audio-over-http
51527
55441417
1075
91
2
http
4620
3387144
733
5
3
ssl
4171
2754485
660
4
4
unknown
1534
168533
109
0
5
webex-meeting
311
68094
218
0
6
dns
303
36848
121
0
7
google-services
206
66414
322
0
8
youtube
167
107982
646
0
9
sip
96
36152
376
0
10
google-accounts
50
29192
583
0
Last Interval(90 seconds) Stats:

No. AppName
Packet-Count
Byte-Count
AvgPkt-Size usage%
-----------------------------------------------------------------------------------------------------1
ssl
498
325997
654
44
2
http
327
278764
852
37
3
youtube
167
107982
646
14
4
unknown
108
7571
70
1
5
google-accounts
50
29192
583
4
6
dns
22
2656
120
0
7
audio-over-http
5
260
52
0
Converged Access AVC Monitoring via GUI

You can view AVC information on a WLAN in a single shot via the pie chart on the Home page of the
converged access platform, as shown in Figure 24-42. The pie chart displays the AVC data (Aggregate Application Cumulative usage %) of the first WLAN. Also, the top five WLANs (based on number of
clients) are also listed and can be clicked to view their corresponding pie chart information.
Note
If AVC is not enabled on the first WLAN, then the Home page does not display the AVC pie chart.
24-72
Chapter 24

Figure 24-42
AVC Monitoring from Home Page
Additionally, the GUI can show application visibility statistics by WLAN (in greater detail) or by client,
as isshown in turn.
GUI-Based Per-WLAN Application Visibility Monitoring

The steps to view application statistics on a per-WLAN basis via the GUI are as follows:
Step 1
Choose Monitor > Controller > AVC > WLANs.
Step 2
Click the corresponding WLAN profile.

The Application Statistics page appears, as shown in Figure 24-43.
From the Top Applications drop-down list, choose the number of top applications you want to view and
click Apply. The valid range is between 5 to 30, in multiples of 5.
a.
On the Aggregate, Upstream, and Downstream tabs, you can view the application cumulative and
last 90 seconds statistics and usage percent with the following fields:
Application name
Packet count
Byte count
24-73
Chapter 24
Average packet size

usage (%)
Figure 24-43
Per-WLAN AVC Monitoring GUI
GUI-Based Per-Client Application Visibility Monitoring

The steps to view application statistics on a per-client basis via the GUI are as follows:
Step 1
Choose Monitor > Clients > Client Details > Clients.
Step 2
Click Client MAC Address and then click the AVC Statistics tab.
The Application Visibility page appears, as shown in Figure 24-44.
a.
On the Aggregate, Upstream, and Downstream tabs, you can view the application cumulative and
last 90 seconds statistics and usage percent with the following fields:
Application name
Packet count
Byte count
Average packet size
usage (%)
24-74
Chapter 24

Summary
Figure 24-44
Per-Client AVC Monitoring GUI
Summary
This design document presented the business case for managing applications over wireless networks,
highlighting the macro trends in wireless traffic volume growth and application trends. Benefits of
applying policies to manage application quality were presented, including increasing voice and video
quality, business-critical application responsiveness, as well as controlling background applications and
non-business applications over wireless networks.
Next, to set design context, wireless QoS tools were overviewed to show how these evolved and operate,
highlighting both their capabilities as well as their limitations. Following this, a discussion of how Layer
2 and Layer 3 mapping works over Cisco wired and wireless networks was presented, including a QoS
Translation Table that performs non-default mappings to reconcile IEEE Layer 2 markings with IETF
Layer 3 markings in Cisco WLCs and APs.
Subsequently, the various policies required to ensure QoS in both the downstream and upstream
directions were summarized, including:
QoS Profiles
AVC Profiles
Network switch DSCP-mapping
Mobile Device WMM marking
Each of these main policy elements were then discussed in detail to show how these could be configured.
WLC policies configurationnamely QoS and AVC Profileswere presented both in GUI format and
in CLI commands.
24-75
Chapter 24
Additional Reading
Wired network switch policies for the access switches connecting to Cisco wireless access points were
presented for a Four-Class, Eight-Class, and Twelve-Class enterprise strategic application-class models
mapped to WMM. Additionally, these policies configurations were shown for Catalyst 3750, 4500, and
6500 series switches, highlighting the platform-specific idiosyncrasies in function and CLI relating to
the policy configurations.
Also, administrators were shown how to monitor application visibility on a global level, WLAN level,
and a client level, as well as how to configure NetFlow Export and Monitoring for network management
purposes.
And finally, corresponding CLI-based and GUI-based commands for configuring and monitoring AVC
on converged access platforms were presented.
Additional Reading
Cisco Wireless LAN Controller Configuration Guide, Release 7.6

http://www.cisco.com/en/US/docs/wireless/controller/7.6/configuration/guide/b_cg76.html
Configuring QoS
http://www.cisco.com/en/US/docs/wireless/controller/7.6/configuration/guide/b_cg76_config_
qos.html
Configuring Application Visibility and Control
http://www.cisco.com/en/US/docs/wireless/controller/7.6/configuration/guide/b_cg76_chapter
_01111.html
Working With WLANS-Assigning QoS Profiles
http://www.cisco.com/en/US/docs/wireless/controller/7.6/configuration/guide/b_cg76_chapter
_01010011.html
Consolidated Platform Configuration Guide, Cisco IOS XE 3.3SE (Catalyst 3850

Switches)-Configuring Application Visibility and Control
http://www.cisco.com/en/US/docs/switches/lan/catalyst3850/software/release/3se/consolidated_gu
ide/configuration_guide/b_consolidated_3850_3se_cg_chapter_01110111.html
Medianet QoS 4.0 Design:

Strategic QoS Design Overview 4.0
http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/Qo
SIntro_40.html
Campus QoS Design 4.0
http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/Qo
SCampus_40.html#wp1099462
24-76
CH AP TE R
25

Whats New: Added a note and links to the FlexConnect section to present Bonjour Gateway design
options for wired network infrastructures.
Executive Summary
This chapter focuses on how to use the Cisco Wireless LAN Controller software Bonjour Gateway
feature to manage Apples Bonjour protocol in a BYOD enterprise context.
Bonjour is Apples zero-configuration protocol for advertising, discovering, and connecting to network
services like file sharing, print sharing, media sharing, etc. The Bonjour protocol was originally designed
for home network use and utilizes Multicast Domain Name Services (mDNS) via link-local multicasting
to share network services. While this approach works well in home networks, a limitation of link-local
multicasting is that these network services will only be shared within a single Layer 2 domain (such as
a VLAN or WLAN). In a BYOD enterprise scenario, different WLANs and VLANs are used for different
classes of devices, including corporate devices, employee devices, personal devices, and guest devices
(as well as quarantine WLANs for unapproved devices). As such, basic Bonjour operationssuch as
printing to a wired printer from a wireless LANmay not be natively supported.
To address this limitation and to facilitate the user demand of BYOD for Apple devices within the
enterprise, Cisco has developed the Bonjour Gateway feature for its Wireless LAN Controllers (WLCs).
This feature was introduced in Cisco WLC software version 7.4 and solves the Layer 2 domain limitation
for Bonjour by allowing the WLC to snoop, cache, and proxy-respond to Bonjour service requests that
may reside on different Layer 2 domains. Additionally, these responses may be selectively controlled by
administrative policies, so that only certain Bonjour services will be permitted in specific Layer 2
domains.
This chapter provides an overview of the Bonjour protocol and shows how the Bonjour Gateway feature
functions, as well as how it can be practically deployed in an enterprise BYOD context to manage
Bonjour services. To this end, step-by-step configuration guidance and verification commands are
presented, both for the Cisco WLC GUI as well as the Command Line Interface (CLI).
25-1
Chapter 25
Why Bonjour?
Why Bonjour?
Bonjour is Apples implementation of a suite of zero-configuration networking protocols and is
supported on both Mac OS X devices (such as laptops and desktops), as well as on Apple iOS devices
(such as iPhones and iPads). Bonjour is designed to make network configuration easier for users.
For example, consider enabling IP-based print services. Each printer needs a unique IP address, whether
statically assigned or dynamically assigned (by a DHCP server). Since dynamically-assigned addresses
can change, most printers are manually configured with a static address so that computers on the network
can reach them using the same address every time. In this case, each client device must know the
statically configured IP address of the printer(s) in order to use these. To make the process more user
friendly, network administrators may configure DNS records so that clients can access printers by name,
rather than by specific IP addresses. Even so, the clients must know the specific DNS name of each
printer they are trying to access. Thus, the seemingly minor task of enabling IP-based printing can
require significant client and server configuration. Additionally, in a home network environment, people
who do not fit the traditional role of the network administrator often set up networks (e.g., families
connecting their laptops and personal devices to the Internet over a shared router). As such, this level of
configuration simply is not practical in such a setting.
Consider the same example in a network running Bonjour. Bonjour lets you connect a printer to your
network without assigning it a specific IP address or manually entering that address into each computer.
With zero-configuration networking, nearby computers can discover its existence and automatically
determine the printers IP address. If that address is a dynamically assigned address that changes, they
can automatically discover the new address in the future.
Bonjour functionality is not limited to printing and includes:
File Sharing Services
Remote Desktop Services
Full screen Mirroring (Apple iOS v5.0+ for iPad2, iPhone4S, or later)
iTunes Services:
iTunes File Sharing
iTunes Wireless iDevice Syncing (Apple iOS v5.0+)
Music broadcasting (Apple iOS v4.2+)
Video broadcasting (Apple iOS v4.3+)
Bonjours zero-configuration networking services benefit not only users (who will no longer have to
assign IP addresses or host names to access network services), but also applications (as applications can
leverage Bonjour to automatically detect required services or to interact with other applications to allow
for automatic connection, communication, and data exchange, all without any user configuration).
Bonjour Overview
Bonjour offers zero-configuration solutions for three areas of IP networking:
Addressing (allocating IP addresses to hosts)Bonjour Addressing
Naming (using names to refer to hosts instead of IP addresses)Bonjour Naming
Service discovery (finding services on the network automatically)Bonjour Service Discovery
Each of these areas is discussed in turn, as well as how Bonjour optimizes the delivery of these solutions.
25-2
Chapter 25

Bonjour Overview
Bonjour Addressing
Bonjour solves the addressing problem of allocating IP addresses to hosts by leveraging self-assigned
link-local addressing. Link-local addressing uses a range of addresses reserved for the local network and
is achieved differently by IPv6 and IPv4:
IPv6 includes self-assigned link-local addressing as part of the protocol
IPv4 self-assigned addressing works by picking a random IP address in the link-local range and
testing it. If the address is not in use, it becomes the local address. If it is already in use, the computer
or other device chooses another address at random and tries again.
Any user or service on a computer or iOS device that supports link-local addressing benefits from this
feature automatically. When a host computer joins a local network, it finds an unused local address and
adopts it. No user action or configuration is required.
Bonjour Naming
Bonjour leverages Multicast DNS (mDNS) for name-to-address translation, which sends DNS-format
queries over the local network using an IP multicast address. Because these DNS queries are sent to a
multicast address, no single DNS server with global knowledge is required to answer the queries. Each
service or device can provide its own DNS capabilitywhen it sees a query for its own name, it provides
a DNS response with its own address.
Actually, Bonjour goes a bit further than basic mDNS functionality by including a responder that handles
mDNS queries for any network service on the host computer or iOS device. This relieves an application
of the need to interpret and respond to mDNS messages. Once a service is registered with the Bonjour
process, Bonjour automatically advertises the availability of the service so that any queries for it are
directed to the correct IP address and port number automatically.
Note
Registration is performed using one of the Bonjour APIs. This functionality is available only to services
running on the host OS X computer or iOS device. Services running on other devices, such as printers,
need to implement a simple mDNS responder daemon that handles queries for services provided by that
device (which is included on printers supporting the Apple AirPrint feature).
Bonjour also provides built-in support for the NAT port mapping protocol (NAT-PMP). If the upstream
router supports this protocol, OS X and iOS applications can create and destroy port mappings to allow
hosts on the other side of the firewall to connect to the provided services.
For name-to-address translation to work properly, a unique name on the local network is necessary.
Unlike conventional DNS host names, the local name only has significance on the local network or LAN
segment. A local name can be assigned much the same way as a self-assigned a local address: a name is
chosen and if it is not already in use, it gets used. If it is unavailable, then the name can be modified
slightly and re-tested for availability. For example, if a printer with the default name
XYZ-LaserPrinter.local attaches to a local network with two other identical printers already installed, it
tests for XYZ-LaserPrinter.local, then XYZ-LaserPrinter-2.local, then XYZ-LaserPrinter-3.local, which
is unused and which becomes its name.
Bonjour Naming Rules

This section explains the Bonjour local domain and the naming rules for Bonjour service instances and
service types. These service names are snooped by and presented within the Cisco WLC and as such are
helpful for an administrator to understanding.
25-3
Chapter 25
Bonjour Overview
Bonjour protocols deal primarily with local link service advertisements. A hosts link-local network
includes itself and all other hosts that can exchange packets without IP header data being modified (i.e.,
hosts sharing a single layer 2 domain/VLAN). In practice, this includes all hosts not separated by a
router. On Bonjour systems, local. is used to indicate a name that should be looked up using an mDNS
query on the local IP network.
Note that local. is not really a domain, but rather a pseudo-domain. It differs from conventional DNS
domains in a fundamental way: names within DNS domains are globally unique; link-local domain
names are not. As such, local names are useful only on the local network. In many cases this is adequate,
as these provide a way to refer to network devices using names instead of IP numbers and of course they
require less effort to coordinate and administer as compared to globally unique names.
Locally unique names are particularly useful on networks that have no connection to the global Internet,
either by design or because of interruption, and on small, temporary networks, such as a pair of
computers linked by a crossover cable or a few people playing network games using laptops on the
wireless network of a home or cafe.
Note
If a name collision on the local network occurs, a Bonjour host finds a new name automatically (in the
case of an iOS device) or by asking the user (in the case of an OS X personal computer).
Bonjour service instance names are intended to be user-readable strings with descriptive names.
Figure 25-1 illustrates the organization of the name of a Bonjour service instance. At the top level of the
tree is the domain, such as local. for the local network. Below the domain is the registration type,
which consists of the service type preceded by an underscore (_music) and the transport protocol, also
preceded by an underscore (_tcp). At the bottom of the tree is the human-readable service instance name,
such as Zealous Lizard's Tune Studio. The complete name is a path along the tree from bottom to top,
with each component separated by a dot.
25-4
Chapter 25

Bonjour Overview
Figure 25-1
Bonjour Service Name Hierarchy and Organization
Domain
local
com
edu
org
Service Type
_tcp
_udp
Host-to-host
transport protocol
_music
_http
IANA-registered
application protocol name
dio
. _
mus
ic
. _tc
p
. l
oca
l
root domain (.)
Zea
Joes Music Library

294217
Zealous Lizards Tune Sudio
lous
Liza
rds
Tun
e Su
Human Readable
Service Instance Name
Other Bonjour service name suffixes include:
_ipp._tcp.local. for AirPrint Printers
_printer._tcp.local. for generic IP Printers
_airplay._tcp.local. for AppleTV
Bonjour Service Discovery

The final element of Bonjour is service discovery. Service discovery allows applications to find all
available instances of a particular type of service and to maintain a list of named services and port
numbers. The application can then resolve the service hostname to a list of IPv4 and IPv6 addresses, as
previously described.
The list of named services provides a layer of indirection between a service and its current DNS name
and port number. Indirection allows applications keep a persistent list of available services and resolve
an actual network address just prior to using a service. The list allows services to be relocated
dynamically without generating a lot of network traffic announcing the change.
Service discovery in Bonjour is accomplished by browsing. An mDNS query is sent out for a given
service type and domain, and any matching services reply with their names. The result is a list of
available services to choose from.
This is very different from the traditional device-centric paradigm of network services, which describes
services in terms of physical hardware. In a device-centric view, the network consists of a number of
devices or hosts, each with a set of services. In a device-centric browsing scheme, a client queries the
25-5
Chapter 25
Bonjour Overview
server for what services it is running, gets back a list (FTP, HTTP, print-services and so on), and decides
which service to use. The interface reflects the way the physical system is organized. But this is not
necessarily what the user logically wants or needs.
On the other hand, a service-centric paradigm is typically more logical and efficient from a
user-perspective. Users typically want to accomplish a certain task, not query a list of devices to find out
what services are running. It makes far more sense for a client to ask a single question, What print
services are available? than to query each available device with the question, What services are you
running? and sift through the results looking for printers. The device-centric approach is not only
time-consuming, but it also generates a significant amount of irrelevant network traffic. In contrast, the
service-centric approach sends a single query, generating only relevant replies.
Bonjour takes the service-oriented view. Queries are made according to the type of service needed, not
the hosts providing them. Applications store service instance names, not addresses, so if the IP address,
port number, or even host name has changed, the application can still connect. By concentrating on
services rather than devices, the users browsing experience becomes more relevant and efficient.
Bonjour Optimization
Server-free addressing, naming, and service discovery have the potential to create a significant amount
of excess network traffic, but Bonjour uses several mechanisms to reduce this traffic to a minimum to
avoid unnecessary chattiness, including:
Caching
Exponential Back-Off and Service Announcement
Each of these Bonjour optimization mechanisms is briefly described in the following sections.
Caching
Bonjour uses a cache of mDNS records to prevent hosts from requesting information that has already
been requested. For example, when one host requests, say, a list of print spoolers, the list of printers
comes back via multicast, so all local hosts see it. The next time a host needs a list of print spoolers, it
already has the list in its cache and does not need to reissue the query.

To prevent repeated answers to the same query, Bonjour service queries include a list of known answers.
For example, if a host is browsing for printers, the first query includes no print services and gets, say,
twelve replies from available print servers. The next time the host queries for print services, the query
includes a list of known servers. Print servers already on the list do not respond.
Bonjour also suppresses duplicate responses in another way. If a host is about to respond, and notices
that another host has already responded with the same information, the host suppresses its response.
Exponential Back-off and Service Announcement

When a host is browsing for services, it does not continually send queries to see if new services are
available. Instead, the host issues an initial query and sends subsequent queries exponentially less often,
for example: after 1 second, 3 seconds, 9 seconds, 27 seconds, and so on, up to a maximum interval of
one hour.
25-6
Chapter 25

This does not mean that it can take over an hour for a browser to see a new service. When a service starts
up on the network, it announces its presence a few times using a similar exponential back-off algorithm.
This way, network traffic for service announcement and discovery is kept to a minimum, but new
services are seen very quickly.

As previously discussed, the Bonjour protocol uses mDNS queries. These queries are sent over UDP port
5353 to the reserved group addresses listed below:
IPv4 Group Address: 224.0.0.251
IPv6 Group Address: FF02::FB
However it should be noted that the mDNS addresses used by Bonjour are link-local multicast addresses
and are only forwarded within the local Layer 2 domain, as link-local multicast is meant to stay local by
design. Furthermore, routers cannot even use multicast routing to redirect the mDNS queries, because
the time-to-live (TTL) of these packets is set to 1.
Bonjour was originally developed with home networks in mind. As such, since most home networks
consist of a single Layer 2 domain, this link-local limitation of mDNS rarely posed any practical
deployment constraints. However in an enterprise context, where large numbers of (wired and wireless)
Layer 2 domains exist, this limitation severely handicaps Bonjour functionality, as Bonjour clients
would only see locally-hosted services and would not be able to see or connect to services hosted on
other subnets. This link-local multicast limitation of Bonjour mDNS is illustrated in Figure 25-2.
Figure 25-2
Bonjour Deployment Limitation in Enterprise Networks
Bonjour is Link-Local Multicast

and cant be Routed
224.0.0.251
VLAN X
CAPWAP
VLAN Y
CAPWAP Tunnel
224.0.0.251
294218
VLAN X
Apple TV
To address this limitation and to facilitate BYOD functionality on enterprise networks, Cisco released a
Bonjour Gateway feature in WLC 7.4+ software. The Bonjour Gateway feature (technically speaking a
mDNS gateway feature, but most relevantly applied to Bonjour) snoops and caches all Bonjour service
advertisements across multiple VLANs and can be configured to (selectively) reply to Bonjour queries.
Figure 25-3 through Figure 25-5 illustrate the operation of the Bonjour Gateway.
In Figure 25-3, the Bonjour Gateway listens/snoops all Bonjour advertisements.
25-7
Chapter 25
Figure 25-3
Cisco WLC Bonjour Gateway OperationStep 1Bonjour Service Advertisement

Snooping
Bonjour Advertisement
VLAN 20
AirP
lay
Offe
red
Apple TV
CAPWAP
iPad
Bonjour Advertisement
VLAN 23
AirPrint
294219
VLAN 99
AirPrint Offered
CAPWAP Tunnel
Next, the Bonjour Gateway caches all these service advertisements, as shown in Figure 25-4.
Incidentally, the WLC 7.4 release supports up to 64 services and 100 service providers per service type.
Each service provider is registered in the WLC as its domain name. Additionally, each Bonjour service
has an advertised TTL (which is different from a packets TTL) and the controller asks the device for an
update at 85% of this TTL.
Figure 25-4
Cisco WLC Bonjour Gateway OperationStep 2Service Advertisement Caching
Bonjour Cache:
AirPlay VLAN 20
AirPrint VLAN 23
VLAN 20
AirP
lay
Offe
red
Apple TV
CAPWAP
iPad
VLAN 23
AirPrint
25-8
294220
VLAN 99
AirPrint Offered
CAPWAP Tunnel

In addition to listening to service advertisements, the WLC is always listening for client queries for
services, as illustrated in Figure 25-5.
Figure 25-5
Cisco WLC Bonjour Gateway OperationStep 3Bonjour Query Snooping
Bonjour Cache:
AirPlay VLAN 20
AirPrint VLAN 23
VLAN 20
Apple TV
CAPWAP
CAPWAP Tunnel
d?
ere
iPad
Is A
VLAN 23
la
irP
VLAN 99
ff
yO
Bonjour Query
AirPrint
294221
Chapter 25
Clients that request locally-hosted services will receive unicast replies from the service provider;
however clients that request services that may be hosted on other VLANs will receive unicast responses
from the WLC, as shown in Figure 25-6.
25-9
Chapter 25
Figure 25-6
Cisco WLC Bonjour Gateway OperationStep 4Bonjour Query Response (from

Cache)
Bonjour Response
from Controller
VLAN 20
Bonjour Cache:
AirPlay VLAN 20
AirPrint VLAN 23
20
AN
Apple TV
CAPWAP
lay
P
Air
is
ble
L
nV
ila
ava
CAPWAP Tunnel
VLAN 23
VLAN 99
AirPrint
294222
iPad
And finally, the Bonjour Gateway service can serve to further optimize Bonjour traffic by unicasting
replies directly to clients requesting a given service (as opposed to multicasting replies like some
competitive solutions), making more efficient use of network resources, as shown in Figure 25-7.
Cisco WLC Bonjour Gateway Operation versus Competitive Offering Operation
Optimized Bonjour Delivery
CAPWAP
Responses unicasted to only the

client requesting for the service.
25-10
Competitive Bonjour Delivery
CAPWAP
Responses multicast to all

clients on the WLAN
294223
Figure 25-7
Chapter 25


A key functional advantage of the Bonjour Gateway is that it can be configured to selectively reply to
Bonjour service requests, thus allowing for administrative control of Bonjour services within the
enterprise. Bonjour policies can be applied on the following basis:
Per WLAN
Per VLAN
Per Interface/Interface-Group
Per-User Bonjour policy application is planned for a future release via RADIUS AAA-Override.
These Bonjour service policy options are illustrated in Figure 25-8.
Figure 25-8
Cisco WLC Bonjour Gateway Service Policy Deployment Options
Bonjour Service Policy
AirPrint
AirPlay
File
Share
Enforced via Multiple Methods
Per
WLAN
Per VLAN
(AP Group)
Per Interface
Group
Priority
294224
Note
Consider a few examples of how such Bonjour service policies may be deployed. For instance, in an
BYOD enterprise context, you can configure Bonjour policies such that employees can take advantage
of Bonjour services that enhance productivity (such as AirPrint, AirPlay, and File Sharing), but block
entertainment-oriented Bonjour services (such as iTunes Sharing).
Additionally, stricter limitations could be placed on Guest WLANs. For example, inter-domain Bonjour
services could be limited to AirPlay onlysuch that guest devices may be allowed to connect to (wired
or wireless) AppleTVs that reside on the production networkso that guests could share presentations,
videos, demonstrations, etc.
These example Bonjour service policies for an enterprise BYOD deployment context are illustrated in
Figure 25-9.
25-11
Chapter 25
Figure 25-9
Cisco WLC Bonjour Gateway Service Policy Deployment Example 1A BYOD

Enterprise
Bonjour Services Directory
BYOD Employee Service Policy
BYOD Guest Service Policy
CAPWAP
AirPlay
File
Share
iTunes
Sharing
Guest
Network
AirPrint
Employee
Network
AirPlay
File
Share
iTunes
Music
Sharing
294225
AirPrint
It is important to note that these Bonjour service policy examples are not a one-size-fits-all solution. The
policy-specifics will likely vary according to deployment contexts. As a second example consider a
college/university deployment context. In this example, assume separate WLANs for teachers and
students. Teachers would likely have all Bonjour productivity-oriented services enabled, such as
AirPrint, AirPlay, and File Sharing. However you may wish to limit AirPlay on student networks, as this
may prevent significant volumes of traffic traversing different WLANs as students may host full-length
HD movies on one network while streaming them to devices on another. Similarly, Time Capsule traffic
may be another service to limit from spanning WLANsagain due to the significant traffic loads these
typically entail. However, consideration may be extended students by permitting iTunes Music Sharing
(as music files are significantly smaller than videos or Time-Capsule backups).
These example Bonjour service policies for a university BYOD deployment context are illustrated in
Figure 25-10.
25-12
Chapter 25

Bonjour Gateway BYOD Use Cases and Configuration Examples
Figure 25-10
Cisco WLC Bonjour Gateway Service Policy Deployment Example 2A BYOD

University
Bonjour Services Directory
Teacher Bonjour
Service Policy
Student Bonjour Service Policy
CAPWAP
AirPlay
File
Share
AirPrint
Teacher
Network
Student
Network
AirPlay
File
Share
iTunes
Time
Music Capsule
Sharing Backup
294226
AirPrint
While the specifics of a Bonjour service policy may differ according to deployment context, there are
two broad use cases for Bonjour Gateway deployments that are discussed next.

There are effectively two general use cases for Bonjour Gateway service policy deployments:
Wireless-to-Wired Bonjour Gateway Service PoliciesThe primary use case is enabling wireless
BYOD devices to print to wired AirPrint printers.
Wireless-to-Wireless Bonjour Gateway Service PoliciesEnables Bonjour services to be shared

among devices in separate WLANs; an example use case would be to allow guest devices to access
wireless AppleTVs to share presentations (even though these devices may reside in different
WLANs).
Bonjour service policies on Cisco WLCs can be configured using one of two approaches:
Editing the default mDNS profile
Creating new mDNS profiles
Also, mDNS profiles can be applied directly to:
Interfaces/Interface-Groups
VLANs
WLANs
To highlight deployment options, the examples that follow utilize a variety of these options.
Design configuration are presented both via the Cisco WLC GUI and the Cisco WLC CLI. CLI examples
show both the general syntax of a command (which is highlighted in blue) and the specific variation
needed in the design example (which is highlighted in red).
25-13
Chapter 25
Note
In these design examples, it is assumed that the network infrastructure and WLC have been configured
in accordance with the best-practice BYOD designs presented in this CVD.
Use Case 1Wireless-to-Wired Bonjour Gateway Service PolicyBYOD

Employee AirPrint Example
In this primary Bonjour Gateway use case, wireless BYOD employee devices are permitted to access
AirPrint-enabled printers that are deployed on separate wired networks. Incidentally, this design will
also support wireless printing from wireless clients across separate WLANs.
A prerequisite of this design is that the wired VLANs hosting AirPrint printers must be trunked to the
Cisco WLC controller, as shown in Figure 25-11.
Figure 25-11
Use-Case 1Cisco WLC Bonjour Gateway Wireless-to-Wired Design Example
Bonjour services from a wired VLAN

can be shared across multiple WLANs
VLAN 20
AirPrint
CAPWAP
CAPWAP Tunnel
VLAN 20
VLAN 30
VLAN 40
VLAN 30
AirPrint
294227
VLAN 40
Multiple design and configuration options exist to enable Bonjour service policies. In this example,
Bonjour service policies will be configured by:
Step 1Globally enabling mDNS snooping
Step 2Editing the default mDNS profile
Step 3Applying the default profile to an interface
Each of these steps is detailed in turn (with additional design options being presented in the following
example).
Step 1Enable mDNS Global Snooping

The first step is to globally enable mDNS snooping by doing the following:
1.
Open a web browser to the Cisco WLC IP address via HTTPS and login.
2.
Click the CONTROLLER heading-bar and expand the mDNS link on the lower left and click
General.
3.
Under the Global Configuration heading, select the checkbox to enable mDNS Global Snooping.
25-14
Chapter 25

4.
Optionally the mDNS Snooping Query Interval can be tuned (from 10 min. to 120 min.).
These steps are shown in Figure 25-12.

Figure 25-12
Use-Case 1Step 1Enabling mDNS Global Snooping
The corresponding Cisco WLC CLI for globally enabling mDNS snooping is shown in Example 25-1.
Example 25-1 Enabling mDNS Global Snooping
General command/specific example:
(Cisco Controller) >config mdns snooping enable
! Globally enables mDNS snooping
The mDNS snooping query interval can be tuned with the command shown in Example 25-2 (again the
range is 10 to 120 minutes). Example 25-2 shows both the general version of this command and the
specific syntax to set the mDNS query interval to 10 minutes.
Example 25-2 Tuning the mDNS Query Interval
General command:
(Cisco Controller) >config mdns query interval minutes
Specific example:
(Cisco Controller) >config mdns query interval 10
! Sets the mDNS query interval to 10 minutes
These mDNS configuration commands can be verified by the show network summary command
output, as illustrated in Example 25-3.
Example 25-3 Verifying mDNS Global Snooping and Query Intervalshow network summary
(Cisco Controller) >show network summary
RF-Network Name.............................
Web Mode....................................
Secure Web Mode.............................
Secure Web Mode Cipher-Option High..........
Secure Web Mode Cipher-Option SSLv2.........
byod
Disable
Enable
Disable
Disable
25-15
Chapter 25
Secure Web Mode RC4 Cipher Preference.......

OCSP........................................
OCSP responder URL..........................
Secure Shell (ssh)..........................
Telnet......................................
Ethernet Multicast Forwarding...............
Ethernet Broadcast Forwarding...............
IPv4 AP Multicast/Broadcast Mode............
IGMP snooping...............................
IGMP timeout................................
IGMP Query Interval.........................
MLD snooping................................
MLD timeout.................................
MLD query interval..........................
User Idle Timeout...........................
ARP Idle Timeout............................
Cisco AP Default Master.....................
AP Join Priority............................
Mgmt Via Wireless Interface.................
Mgmt Via Dynamic Interface..................
Bridge MAC filter Config....................
Bridge Security Mode........................
Mesh Full Sector DFS........................
AP Fallback ................................
Web Auth CMCC Support ......................
Web Auth Redirect Ports ....................
Web Auth Proxy Redirect ...................
Web Auth Captive-Bypass
..................
Web Auth Secure Web .......................
Fast SSID Change ...........................
AP Discovery - NAT IP Only .................
IP/MAC Addr Binding Check ..................
CCX-lite status ............................
oeap-600 dual-rlan-ports ...................
oeap-600 local-network .....................
oeap-600 Split Tunneling (Printers).........
WebPortal Online Client ....................
mDNS snooping...............................
mDNS Query Interval.........................
<snip>
Disable
Disabled
Enable
Enable
Disable
Disable
Unicast
Disabled
60 seconds
20 seconds
Disabled
60 seconds
20 seconds
300 seconds
300 seconds
Disable
Disable
Enable
Disable
Enable
EAP
Enable
Enable
Disabled
80
Disable
Enable
Enable
Enabled
Enabled
Enabled
Disable
Disable
Enable
Disable
0
Enabled
10 minutes
Step 2Editing the Default mDNS Profile

Additional Bonjour services may be added to the default mDNS profile (or even removed from it). To
add additional Bonjour services, perform the following:
1.
Select the Bonjour Service to be added from the Master Services Database drop-down list.
2.
Enable the Query Status Checkbox for the service.
3.
Click the Add button.
4.
The added service will subsequently appear under the Service Name bar (in alphabetical order).
Figure 25-13 shows the Apple File Sharing Protocol (AFP) service being added to the default mDNS
profile.
25-16
Chapter 25

Figure 25-13
Use-Case 1Step 2Adding Bonjour Services to the Default mDNS Profile
Bonjour services can be added to the default (or non-default) profiles with the command shown in
Example 25-4. The Profile Name of the default mDNS profile is default-mdns-profile.
Example 25-4 Adding Bonjour Services to a mDNS Profile
General Command:
(Cisco Controller) >config mdns profile service add mdns-profile-name mdns-service-name
Specific example:
(Cisco Controller) >config mdns profile service add default-mdns-profile AirPrint
! Adds the Apple AirPrint service to the default mDNS profile
Conversely, services can be removed from the default mDNS profile by clicking the blue-box at the end
of the row for the service and then selecting Remove.
This is shown in Figure 25-14 where the AirPlay service (the service that allows for iTunes music to be
streamed to a remote Apple Airport Express device, which in turn can supply an audio signal of the
music to speakers) is removed from the default mDNS profile.
25-17
Chapter 25
Figure 25-14
Use Case 1Step 2bRemoving Bonjour Services from the Default mDNS Profile
Bonjour services can also be removed from the default (or non-default) profiles with the command
shown in Example 25-5.
Example 25-5 Removing Bonjour Services from a mDNS Profile
General Command:
(Cisco Controller) >config mdns profile service delete mdns-profile-name mdns-service-name
Specific example:
(Cisco Controller) >config mdns profile service delete default-mdns-profile AirTunes
! Deletes the Apple AirTunes service from the default mDNS profile
The addition/removal of services to a mDNS profile can be verified by the show mdns profile command,
which can either show a summary of configured profiles or a detailed view of a specific profile, as shown
in Example 25-6 and Example 25-7, respectively.
Example 25-6 Verifying mDNS Profilesshow mdns profile summary
(Cisco Controller) >show mdns profile summary
Number of Profiles............................... 1
ProfileName
-------------------------------default-mdns-profile
No. Of Services
--------------6
(Cisco Controller) >
Example 25-7 Verifying mDNS Profilesshow mdns profile detailed Profile-Name

(Cisco Controller) >show mdns profile detailed default-mdns-profile
Profile Name..................................... default-mdns-profile
Profile Id....................................... 2
No of Services................................... 6
25-18
Chapter 25

Services......................................... AirPrint
AppleTV
HP_Photosmart_Printer_1
Printer
Scanner
No. Interfaces Attached.......................... 1
Interfaces....................................... dynamic
No. Interface Groups Attached.................... 0
No. Wlans Attached............................... 4
Wlan Ids......................................... 1
3
4
5
Step 3Apply the Default mDNS Profile an Interface (or Interface-Group)

Bonjour service policies may be applied to interfaces, VLANs, or WLANs. In this example the Bonjour
policies (as represented in the Default mDNS Profile) are attached to an interface.
There are five types of interfaces are available on the Cisco WLC controller. Four of these are static and
are configured at setup time and the fifth type is dynamic and user-defined:
Management interface (static and configured at setup time; mandatory)
AP-manager interface (static and configured at setup time; mandatory)
Virtual interface (static and configured at setup time; mandatory)
Service-port interface (static and configured at setup time; optional)
Dynamic interface (user-defined)
In this case, it is assumed that the ua28-wlc5508-1-v2 interface is applied to the BYOD_Employee
WLAN (in line with the recommendations in Chapter 9, BYOD Wireless Infrastructure Design), as
shown in Figure 25-15. If this is not the case, then the policies should be applied to whatever (static or
dynamic) interface is associated with the WLAN. This association is verified by selecting the WLANs
heading bar and then selecting the WLAN number that corresponds to the BYOD_Employee WLAN.
25-19
Chapter 25
Figure 25-15
Use Case 1Verifying WLAN/Interface Association
To apply the Default mDNS policies to an interface, perform the following:

1.
Click the CONTROLLER heading-bar and then the Interfaces (or Interface Group) link on the
left.
2.
Select the interface that corresponds to the VLAN/WLAN to which the Bonjour service policies are
to be applied.
3.
At the bottom of the Interface > Edit page, select the default-mdns-profile from the mDNS Profile
drop-down list.
4.
Click the Apply button at the top-right of the page.
25-20
Chapter 25

Figure 25-16
Use Case 1Step 3Applying the Default mDNS Profile to an Interface
As Figure 25-16 shows (in this case) the ua28-wlc5508-1-v2 interface corresponds to VLAN 40, which
is where the wired AirPrint printer(s) reside. Bonjour service advertisements from these printers will
now be shared with other WLANs/VLANs.
The Default mDNS profile can be added to the interface associated with the WLAN with the commands
Example 25-8 Adding a mDNS Profile to an Interface
General command:
(Cisco Controller) >config interface mdns-profile {interface-name | all} mdns-profile-name
Specific example:
(Cisco Controller) >config interface mdns-profile ua28-wlc5508-1-v2 default-mdns-profile
! Adds the default mDNS profile to the ua28-wlc5508-1-v2 interface
The mDNS profile attached to an interface can be verified by the command show interface detailed
interface-name, as shown in Example 25-9. Alternatively, if the mDNS profile is attached to an
interface-group, then the show command would be show interface group detailed
interface-group-name.
25-21
Chapter 25
Example 25-9 Verifying Interface mDNS Profilesshow interface detailed interface-name

(Cisco Controller) >show interface detailed ua28-wlc5508-1-v2
Interface Name...................................
MAC Address......................................
IP Address.......................................
IP Netmask.......................................
IP Gateway.......................................
External NAT IP State............................
External NAT IP Address..........................
VLAN.............................................
Quarantine-vlan..................................
Active Physical Port.............................
Primary Physical Port............................
Backup Physical Port.............................
DHCP Proxy Mode..................................
Primary DHCP Server..............................
Secondary DHCP Server............................
DHCP Option 82...................................
IPv4 ACL.........................................
IPv6 ACL.........................................
mDNS Profile Name................................
<snip>
ua28-wlc5508-1-v2
30:f7:0d:31:3b:2f
10.225.43.2
255.255.255.0
10.225.43.1
Disabled
0.0.0.0
40
0
LAG (13)
LAG (13)
Unconfigured
Global
10.230.1.61
Unconfigured
Disabled
Unconfigured
Unconfigured
default-mdns-profile
Use Case 2Wireless-to-Wireless Bonjour Gateway Service PolicyBYOD

Guest AirPlay Example
In this secondary Bonjour Gateway use case, wireless guest devices are permitted to access Apple TV
devices (using AirPlay) so that guests may share presentations, video, or other content with employees.
Incidentally, Apple TVs, like some AirPrint printers, may be connected via wired or wireless
connections; this design supports both options. However in this case, assume the Apple TV is residing
in the BYOD Personal Devices WLAN, as shown in Figure 25-17.
Figure 25-17
Use Case 2Cisco WLC Bonjour Gateway Wireless-to-Wireless Design Example
BYOD
Guest WLAN
Bonjour AirPlay services from one WLAN

can be shared across multiple WLANs
VLAN 20
AirPlay
CAPWAP
CAPWAP Tunnel
VLAN 20
VLAN 30
VLAN 40
VLAN 30
VLAN 40
BYOD Personal
Device WLAN
294233
Apple TV
(Wireless)
To highlight design and deployment options, in this example Bonjour service policies are configured by:
25-22
Chapter 25

Step 1Creating a new mDNS profile.
Step 2Adding Bonjour services to the new mDNS profile.
Step 3Enabling mDNS snooping and the new mDNS profile directly on the WLAN.
Each of these steps is detailed in turn.
Step 1Creating a New mDNS Profile

The first step in this example is to create a new mDNS profile, which can be done by performing the
following:
1.
Click the CONTROLLER heading-bar and expand the mDNS link on the lower left and click
Profiles.
2.
Click the New button at the top-right, as shown in Figure 25-18.
Figure 25-18
3.
Use Case 2Step 1aCreating a New mDNS Profile
Give the new profile a name and click the Apply button, as shown in Figure 25-19.
25-23
Chapter 25
Figure 25-19
Use Case 2Step 1bNaming the New mDNS Profile
The corresponding Cisco WLC CLI for creating a new mDNS profile is shown in Example 25-10, which
creates a new mDNS profile named Guest-mDNS-Profile.
Example 25-10 Creating a New mDNS Profile
General command:
(Cisco Controller) >config mdns profile create mdns-profile-name
Specific example:
(Cisco Controller) >config mdns profile create Guest-mDNS-Profile
! Creates a new mDNS profile named Guest-mDNS-Profile
Newly created mDNS profiles will be displayed by the show mdns profile summary verification
command, as shown in Example 25-11.
Example 25-11 Verifying mDNS Profilesshow mdns profile summary
(Cisco Controller) >show mdns profile summary
Number of Profiles............................... 2
ProfileName
-------------------------------Guest-mDNS-Profile
No. Of Services
--------------0
6
Step 2Adding Bonjour Services to the New mDNS Profile

In this particular use case, only the AirPlay service will be offered to BYOD guest devices. Therefore
the Bonjour AirPlay service needs to be added to the new mDNS Profile, which is done by performing
the following:
1.
Select and click the new mDNS profile.
2.
Select the desired Bonjour service(s) from the Services List drop-down list and click the Add
button, as shown in Figure 25-20.
25-24
Chapter 25

3.
The added service will subsequently appear under the Service Name bar.
Figure 25-20
Use Case 2Step 2Adding Bonjour Services to the New mDNS Profile
The corresponding Cisco WLC CLI for adding Bonjour services to a profile is shown in Example 25-12.
Example 25-12 Adding Bonjour Services to a mDNS Profile
General command:
(Cisco Controller) >config mdns profile service add mdns-profile-name mdns-service-name
Specific example:
(Cisco Controller) >config mdns profile service add Guest-mDNS-Profile AppleTV
! Adds the AppleTV service to the Guest-mDNS-Profile profile
Services within a mDNS profile can be verified by the show mdns profile detailed command, as
presented in Example 25-13.
Example 25-13 Verifying mDNS Profilesshow mdns profile detailed Profile-Name
(Cisco Controller) >show mdns profile detailed Guest-mDNS-Profile
Profile Name.....................................
Profile Id.......................................
No of Services...................................
Services.........................................
Guest-mDNS-Profile
1
1
AppleTV
No. Interfaces Attached.......................... 0

No. Interface Groups Attached.................... 0
No. Wlans & Guest-LANs Attached.................. 0
25-25
Chapter 25
Step 3Enable mDNS Snooping and the New mDNS Profile on the WLAN
Once all the Bonjour services have been added to the new profile, it can be added to the desired WLAN
(in this case, the BYOD_Guest WLAN) by performing the following:
1.
Click the WLANs heading-bar and select the desired WLAN (in this case, the BYOD_Guest
WLAN, as shown in Figure 25-21).
Figure 25-21
Use Case 2Step 3aSelecting the WLAN to which the New mDNS Profile Will Be
Applied
2.
Click the Advanced tab and scroll to the bottom.
3.
Ensure that the mDNS Snooping checkbox is selected.
4.
Select the mDNS Profile from the drop-down list.
5.
Click the Apply button at the top-left.
Figure 25-22
Use Case 2Step 3bEnabling mDNS Snooping on the WLAN and Applying the
New mDNS Profile
The corresponding Cisco WLC CLI for these steps of enabling mDNS snooping and a specific mDNS
profile on a WLAN is shown in Example 25-14 and Example 25-15, respectively.
25-26
Chapter 25

Example 25-14 Enabling mDNS Snooping on a WLAN

General command/specific example:
(Cisco Controller) > config wlan mdns enable
Example 25-15 Adding a mDNS Profile to a WLAN

General command:
(Cisco Controller) >config wlan mdns profile {wlan-id | all } mdns-profile-name
Specific example:
(Cisco Controller) >config wlan mdns profile 2 Guest-mDNS-Profile
! Adds the Guest-mDNS-Profile to WLAN 2 (the BYOD_Guest WLAN, as shown in Figure 21)
The mDNS settings of a WLAN can be verified by the show wlan wlan-id verification command, as
Example 25-16 Verifying WLAN mDNS Settingsshow wlan
(Cisco Controller) >show wlan 2
WLAN Identifier..................................
Profile Name.....................................
Status...........................................
MAC Filtering....................................
Broadcast SSID...................................
AAA Policy Override..............................
Network Admission Control
Client Profiling Status
Radius Profiling ............................
DHCP .......................................
HTTP .......................................
Local Profiling .............................
DHCP .......................................
HTTP .......................................
Radius-NAC State...............................
SNMP-NAC State.................................
Quarantine VLAN................................
Maximum number of Associated Clients.............
Maximum number of Clients per AP Radio...........
Number of Active Clients.........................
Exclusionlist Timeout............................
Session Timeout..................................
User Idle Timeout................................
Sleep Client.....................................
Sleep Client Timeout.............................
User Idle Threshold..............................
NAS-identifier...................................
CHD per WLAN.....................................
Webauth DHCP exclusion...........................
Interface........................................
Multicast Interface..............................
WLAN IPv4 ACL....................................
WLAN IPv6 ACL....................................
WLAN Layer2 ACL..................................
mDNS Status......................................
mDNS Profile Name................................
<snip>
2
BYOD_Guest
BYOD_Guest
Enabled
Disabled
Enabled
Enabled
Disabled
Disabled
Disabled
Disabled
Disabled
Disabled
Disabled
Disabled
0
0
200
0
60 seconds
1800 seconds
Disabled
disable
12 hours
0 Bytes
ua28-wlc5508-1
Enabled
Disabled
ua27-5508-2-guest
Not Configured
unconfigured
unconfigured
unconfigured
Enabled
Guest-mDNS-Profile
25-27
Chapter 25

In addition to the GUI and CLI configuration-verification screenshots and commands that have been
highlighted in the previous sections, Cisco WLC software has some additional options for verifying
Bonjour Gateway operation, which we now discuss.
For instance, a summary of all mDNS records can be shown by clicking the CONTROLLER
heading-bar, expanding the mDNS link on the lower left, and then clicking Domain Names, as shown
in Figure 25-23.
Figure 25-23
Verifying mDNS Domain Names
A summary of mDNS records can also be provided via the CLI with the command show mdns
domain-name-ip summary, as shown in Example 25-17.
Example 25-17 Verifying mDNS Recordsshow mdns domain-name-ip summary
(Cisco Controller) >show mdns domain-name-ip summary
Number of Domain Name-IP Entries................. 3
DomainName
MAC Address
IP Address
Vlan Id
--------------------
----------------
-----------
------- ------
10.10.10.12
10.10.11.11
10.10.10.12
11
11
10
EPSON4FF833.local.
b0:e8:92:4f:f8:33
Office-Apple-TV.local. 2c:b4:3a:02:f8:fb
suyodesh-mbpro-2.local. 14:10:9f:e4:88:43
Type
Wired
Wired
Wireless
TTL Time left

(sec) (sec)
----- ----4725
4725
4725
4354
4712
3753
Also, clicking on any service listed within an mDNS profile will display a mDNS Service>Detail screen
that will display device-level detailsincluding MAC address, VLAN, and network-type (wired or
wireless) for any and all devices providing that Bonjour service. For example, Figure 25-24 shows that
the Apple TV service is available both via the wired and wireless networks.
25-28
Chapter 25

Figure 25-24
Verifying mDNS Service Details
Device-level mDNS service detail is also available via the CLI using the command show mdns service
detailed mdns-service-name, as demonstrated in Example 25-18.
Example 25-18 Verifying mDNS Service Detailsshow mdns service detailed
(Cisco Controller) >show mdns service detailed AppleTV
Service Name.....................................
Service Id.......................................
Service query status.............................
Service LSS status...............................
Service learn origin.............................
Number of Profiles...............................
Profile..........................................
AppleTV
4
Enabled
Disabled
Wireless and Wired
2
Guest-mDNS-Profile
Number of Service Providers ..................... 1

Number of priority MAC addresses ................ 0
ServiceProvider
MAC Address
Vlan Id
Type
TTL
Time left
(sec)
(sec)
-------------------------------
-----
AP Radio MAC
----------------
----------------
2c:b4:3a:02:f8:fa
04:da:d2:b2:47:10
---------
Office Apple TV._airplay._tcp.local.

11
Wireless
4500
4460
Additionally, the CLI allows for a summary of mDNS services to be displayed via the show mdns
service summary command, as shown in Example 25-19.
Example 25-19 Verifying mDNS Service Summaryshow mdns service summary
(Cisco Controller) >show mdns service summary
25-29
Chapter 25
Number of Services............................... 11
Service-Name
-------------------------------AFP
AirPrint
AirTunes
AppleTV
FTP
Printer
Scanner
TimeCapsuleBackup
iTuneHomeSharing
LSS
---No
No
No
No
No
No
No
No
No
No
No
Origin
---------All
All
All
All
All
All
All
All
All
All
All
No SP
----0
1
1
1
1
1
0
1
1
0
0
Service-string
--------------_afpovertcp._tcp.local.
_ipp._tcp.local.
_raop._tcp.local.
_airplay._tcp.local.
_ftp._tcp.local.
_universal._sub._ipp._tcp.local.
_cups._sub._ipp._tcp.local.
_printer._tcp.local.
_scanner._tcp.local.
_adisk._tcp.local.
_home-sharing._tcp.local.
Finally, it bears mentioning that third-party tools are also available to verify mDNS operations. For
example, Figure 25-25 shows Tildesofts Bonjour Browser displaying mDNS details for the Epson
wired AirPrint printer.
25-30
Chapter 25

Figure 25-25
Verifying Bonjour Gateway Operation via Third-Party ToolsTildesoft Bonjour

Browser Example

This section will briefly overview Bonjour Gateway operation in three additional scenarios:
Guest Anchoring
Layer 3 Roaming
FlexConnect
While the configuration and verification of the Bonjour Gateway feature remains the same for these
scenarios, it may be helpful for network administrators to understand how this feature operates in these
contexts.
25-31
Chapter 25
Guest Anchoring
In guest anchoring scenarios, the guest WLAN is able to see Bonjour services advertised to the anchor
controller. This is because the Bonjour queries and advertisements are sent inside the Control and
Provisioning of Wireless Access Points (CAPWAP) tunnel, as shown in Figure 25-26.
Bonjour Gateway Operation in Guest Anchoring Scenarios
Foreign
Controller
AirPlay
CAPWAP
CAPWAP Tunnel
AirPlay
CAPWAP Tunnel
Guest
WLAN
(Anchored)
Apple TV
VLAN
Guest
VLAN
Anchor
Controller
DMZ
AirPlay
Apple TV
(Wired)
294242
Figure 25-26
Layer 3 Roaming
Bonjour Gateway with Layer 3 roaming works across Ethernet over IP (EoIP) tunnels to ensure that users
moving among access points (APs) on different controllers continue to see the devices they saw on the
original controller. The Bonjour services on the anchor controller are displayed to the client, including
both wired and wireless devices, as shown in Figure 25-27.
25-32
Chapter 25

Summary
Figure 25-27
Bonjour Gateway Operation in Layer 3 Roaming Scenarios
Foreign
Controller
AirPlay
CAPWAP
CAPWAP Tunnel
AirPlay
CAPWAP Tunnel
Anchor
Controller
294243
Roaming
Client
Mobility
EoIP Tunnel
AirPlay
CAPWAP
FlexConnect
For centrally-switched WLANs, the behavior for Bonjour is the same as if the AP was in local mode. In
this case, Bonjour queries from the client are sent to the controller and Bonjour responses from the
controller are sent back to the AP in the unicast CAPWAP tunnel. This means FlexConnect APs will not
require Multicast-Unicast mode to support Bonjour.
For locally switched WLANs, the behavior for Bonjour will continue to work for a single subnet only.
Note
Customers running FlexConnect in branches can also run Bonjour Gateway functionality over their
wired network infrastructure (Cisco switches and/or routers). For additional details on such design
options, see: http://www.cisco.com/go/mdns and
http://www.cisco.com/en/US/docs/wireless/controller/technotes/5700/software/release/ios_xe_33/servi
ce_discovery_gateway_DG/b_service_discovery_gateway_DG.html.
Summary
This paper overviewed Apples Bonjour protocola zero-configuration protocol for advertising,
discovering, and connecting to network servicesand how it can be effectively managed within a BYOD
enterprise context.
The design limitation of Bonjours use of link-local multicasting was discussed, showing how it limited
the usefulness of the protocol to only a single Layer 2 domain. To enable the use of Bonjour in
(multi-WLAN/VLAN) BYOD enterprise networks, the Cisco WLC Bonjour Gateway was introduced.
Next, an overview of the operation of the Bonjour Gateway feature was provided, showing how it can be
used to snoop, cache, and proxy-respond to Bonjour service requests. Additionally, it was shown how
these responses could be selectively enabled and disabled, allowing for administrative policy-based
control of Bonjour services.
Following this, deployment details of this feature were presented by considering two main use-case
scenarios:
Printing from wireless devices to wired printers.
25-33
Chapter 25
References
Sharing Bonjour services between wireless devices in different WLANs.
Step-by-step configuration guidance was presented for each scenario, using slightly different approaches
to highlight the various configuration options available. Each step was presented for not only the Cisco
WLC GUI configuration and verification, but also for the Cisco WLC CLI.
Additional verification options were also highlighted, as well as how the Bonjour Gateway operates in
various advanced scenarios, including guest anchoring, Layer 3 roaming, and FlexConnect deployments.
References
Cisco Wireless LAN Controller Configuration Guide, Release 7.4

http://www.cisco.com/en/US/docs/wireless/controller/7.4/configuration/guides/consolidated/b_cg7
4_CONSOLIDATED.html
Cisco Wireless LAN Controller Configuration Guide, Release 7.4Configuring Multicast Domain
Name System
http://www.cisco.com/en/US/docs/wireless/controller/7.4/configuration/guides/consolidated/b_cg7
4_CONSOLIDATED_chapter_01011.html#d75540e531a1635
Cisco WLC Bonjour Gateway Deployment Guide

http://www.cisco.com/en/US/docs/wireless/technology/bonjour/Bonjour_Deployment.html
25-34
CH AP TE R
26
Mobile and Remote Access Collaboration with

Cisco Expressway Series
Whats New: This is a new chapter that describes a new way for mobile devices to connect from any
location without the need for a separate VPN client, which simplifies the BYOD user experience and
complements security policies.
Overview
Cisco Expressway Series
Collaboration should be simple and effective regardless of location. The Cisco Expressway Series helps
ensure that collaboration outside the enterprise is as simple and secure as on-premises collaboration.
Cisco Expressway provides access to collaboration services from anywhere on a range of devices
collaborating with a mix of video, voice, messaging, and presence.
Cisco Expressway provides secure mobile access based on Transport Layer Security (TLS) without the
need for a separate VPN client, simplifying the user experience while complementing BYOD security
policies.
Some of the benefits of Cisco Expressway include:
Simple access to video, voice, content, messaging, and presence outside the enterprise firewall so
employees are as effective and productive as they are inside the office.
Highly secure firewall traversal technology to extend organizational reach.
Improved productivity allowing employees to collaborate with multiple mobile devices.
Enhance workforce mobility with support for a wide range of devices with Cisco Jabber for
smartphones, tablets, and desktops.
Figure 26-1 shows a Cisco Expressway deployment forming a secure traversal link enabling
collaboration from outside the firewall.
26-1
Chapter 26
Overview
Figure 26-1
Expressway Deployment
Inside Firewall
Outside (Public Internet)

Business-toBusiness
Collaboration Services
Expressway Traversal
Internet
Consumer-toBusiness
Remote and
Mobile
Collaboration
297121
Unifed
CM
IM&P
Cisco Expressway Series is a component of the Cisco Collaboration Edge Architecture, which combines
the capabilities of Cisco gateway offerings with the core capabilities of Cisco Collaboration solutions to
break down barriers and enable effective collaboration. The Collaboration Edge Architecture enables
anyone, anywhere, any device collaboration for:
Remote and mobile workers
Business-to-business collaboration
Consumer-to-business collaboration
Intra-enterprise and cloud connectivity
Jabber Client Connectivity without VPN

Cisco Expressway provides a secure connection for Cisco Jabber application traffic without having to
connect to the corporate network over a VPN tunnel. It is device and operating system agnostic for
Windows, Mac, Apple iOS, and Android platforms. It allows Jabber clients that are outside the enterprise
to:
Use instant messaging and presence services.
Make voice and video calls.
Search the corporate directory.
Share content.
Launch a web conference.
Access visual voicemail.
Solution Components
Figure 26-2 shows the components tested in this design guide, including the Expressway and
Collaboration Services components. These components, in combination with DNS name resolution,
allow clients to connect from any location.
26-2
Chapter 26

Overview
Figure 26-2
Solution Components
Inside Firewall
DNS
DNS
C
Expressway-C
Internet
Expressway-E
297122
Unifed
CM
IM&P
Jabber and Video Endpoints
Cisco Expressway-C and Expressway-E

The Expressway solution builds on the firewall traversal capabilities of the Cisco TelePresence Video
Communication Server (VCS) family and explicitly allows mobile and remote access without the need
for a separate VPN client.
Two servers are required to provide the firewall traversal features. These may be in the form of
virtualized applications, bare-metal appliances, or for deployment on the Cisco ISR Routers using Cisco
UCS E-Series. The two servers are:
Expressway-C or CoreActs as the traversal client for Expressway-E and is the SIP Proxy and
communications gateway for Unified CM.
Expressway-E or EdgeResides on the DMZ and is the traversal server that handles incoming calls
and issues call requests to Expressway-C. The Expressway-E has a public network domain name and
is reachable from the public Internet.
Cisco Unified Communications Manager

The Cisco Unified Communications Manager (Unified CM) serves as the software-based call processing
component of the solution.
Endpoint devices register to the Unified CM and the Expressway acts as a Unified Communications
Internet gateway/proxy for a full range of collaboration services including video, voice, IM and
presence, messaging, and mobility on Cisco as well as third-party devices.
Cisco Unified CM IM and Presence

The Cisco Unified Communications Manager IM and Presence (IM&P) provides native enterprise
instant messaging (IM) and network-based presence as part of Cisco Unified Communications Manager.
The service is tightly integrated with Cisco and third-party compatible desktop and mobile clients,
including Cisco Jabber.
26-3
Chapter 26
Overview
Cisco AnyConnect Secure Mobility Client

The Cisco AnyConnect Secure Mobility Client provides a secure connection experience across a broad
set of PC and mobile devices. The client automatically selects the optimal network access point and
adapts its tunneling protocol to the most efficient method and it may be configured so that the VPN
connection remains established during IP address changes or loss of connectivity.
Cisco ASA Firewall

Cisco ASA Adaptive Security Appliances provide a broad span of security technology and solutions to
protect critical assets in enterprise networks. A set of modular security services strengthens a proven
stateful inspection firewall with next-generation firewall capabilities and network-based security
controls for streamlined security operations. The ASA also offers comprehensive endpoint security for
AnyConnect VPN clients.
Cisco Jabber Clients

Cisco Jabber is a collaboration client application that streamlines communications and enhances
productivity. Cisco Jabber provides the best user experience across the broadest range of platforms via
presence, instant messaging (IM), voice, high quality video, voice messaging, and desktop sharing and
conferencing. Cisco Jabber is supported across desktop PCs and mobile devices, such as smartphones
and tablets.
Cisco TelePresence Endpoints

Cisco TelePresence Endpoints create an immersive, in-person experience over the network, allowing
local and remote participants to feel like they are all in the same room. Expressway allows TelePresence
endpoints to register to Unified CM over the Internet without VPN or Virtual Office Routers.
DNS Name Server

The DNS servers are used to perform DNS lookups and resolve network names. The resolution of
specific SRV records influences when the client communicates with Expressway-E.
Expressway Traversal
The Expressway traversal enables video, voice, content and IM&P collaboration outside a firewall. The
solution works with most firewalls and only requires minimal firewall configuration. Figure 26-3 shows
how Expressway-E and Expressway-C allow Jabber clients to connect from the Internet.
26-4

Overview
Figure 26-3
Expressway Firewall Traversal
Inside Firewall
Expressway-C
Unifed
CM
IM&P
Internet
Expressway-E
Call Signaling
Media
297123
In this deployment, Expressway-E acts as the traversal server and resides in the DMZ, while
Expressway-C is the traversal client inside the enterprise network.
Expressway-C initiates traversal connections outbound through the firewall to specific ports on
Expressway-E with secure login credentials and sends keep-alive packets to Expressway-E. This
outbound high-to-low connection serves to further minimize the configuration required on the ASA
and lowers the risks of an unused, unmonitored ACL from outside to inside.
When Expressway-E receives incoming call signaling, it sends the signaling to Expressway-C.
Expressway-C proxies the call signaling to Unified CM, which completes the call process and the
call is established, with media traversing the tunnel between Expressway-E and Expressway-C.
Figure 26-4 shows the signaling and media paths between Jabber clients. Unified CM provides call
control for both mobile and on-premise endpoints.
Media traversalC calls A while A is on-premise. The Expressway solution provides firewall
traversal for the media. Expressway-C de-multiplexes media and forwards to A.
Media RelayC calls B while both are off-premise. Media is relayed via Expressway-C and
the call is established.
Figure 26-4
Signaling and Media Paths
Inside Firewall
B
M
Unifed
CM
IM&P
Expressway-C
C
Internet
Expressway-E
Call Signaling
Media
Media
297124
Chapter 26
26-5
Chapter 26
Overview
Use Cases in this Document

The use cases presented in this document address several deployment scenarios and explore different
combinations of Jabber and TelePresence clients, AnyConnect VPN sessions, and the interaction
between them. The use cases are grouped by the clients original location.
Connecting from the Corporate Network

The section focuses on two different ways to allow clients to collaborate:
Connecting directly to the Unified CMIn this case, the client does not require Expressway
services and signs in directly with on-premise collaboration services.
Providing communication across segmentsIn this case, clients are separated by some form of
segmentation, such as VLANs or Access Control Lists. The BYOD CVD highlights several use
cases that cover different deployment models. For example, in the Enhanced use case wireless
clients are provided differentiated access based on authorization profiles, but the segmentation
enforced on them makes the communication between Jabber clients impossible. This use case
facilitates that communication.
Connecting from the Internet

This use case explores how mobile devices can simultaneously use both the Cisco AnyConnect client
and Cisco Jabber. While both the AnyConnect client and the Cisco Jabber client work well as designed,
their interaction can have a negative impact on collaboration calls between Jabber clients.
This use case focuses on different techniques configured on the ASA, such as split tunneling and filtering
that allows the client to always connect to Expressway-E when the connection originates from the
Internet.
This use case also explores the option of dedicating a DNS server to provide name resolution for clients
connecting from the Internet to guarantee the connection to Expressway-E and reduce the impact to
active voice or video calls.
Figure 26-5 shows two different ways for remote clients to connect to the Collaboration Services
residing on the corporate network.
The first one is by establishing a VPN tunnel with the Cisco AnyConnect client. This full-tunneling
capability allows mobile devices to access collaboration and other enterprise resources and
applications with a consistent LAN-like user experience. This requires installing the Cisco
AnyConnect client on the mobile device.
The second one highlights the firewall traversal capabilities of the Expressway solution to allow
remote clients to access collaboration resources without the need for a separate VPN client, making
the connection transparent to the user, regardless of location.
26-6
Chapter 26

Overview
Figure 26-5
Remote Access Options
Unifed
CM
IM&P
AnyConnect VPN
Expressway
Firewall Traversal
297125
Collaboration
Services
In this use case, the interaction between the Jabber client and AnyConnect VPN client is validated, with
a strong focus on providing a positive user experience for collaboration sessions. Table 26-1 highlights
some considerations for VPN and Expressway solutions.
Table 26-1
Comparing VPN and Expressway
Advantages
VPN
Challenges
Secure access to all

enterprise applications
Supports Dial via Office

Reverse Callback,
Wi-Fi-to-cellular handoff
(hand-out), and CTI as well
as other non-collaboration
work flows.
With VPN all traffic from

connected devices traverses the
enterprise network
No support for Dial via Office

Expressway Mobile and Remote Only collaboration traffic
Access
traverses the enterprise network, Reverse Callback
everything else goes to the
Internet No per-session or user
licensing beyond collaboration
endpoint/client licensing
Connection Scenarios provides more details on these scenarios.
Discovering Available Services via DNS

When a Jabber client gets a network connection, the device also gets the address of a DNS name server
from the DHCP server. Depending on the network connection, the DNS server might be internal or
external to the corporate network.
Cisco Jabber clients rely on domain name servers to:
Automatically discover servers inside the corporate network.
Locate Expressway servers on the public Internet.
Determine whether the client is inside or outside the corporate network.
26-7
Chapter 26
Overview
The Jabber client looks for DNS records from internal name servers inside the corporate network and
external name servers on the public Internet.
The Jabber client relies on the services domain to query the DNS server for resolution. One way to
discover the services domain is by using the users login credentials, which require the users ID and
domain. The example in Figure 26-6 is from user1 connecting from a Windows Jabber client. The user
ID is user1, while emtest.com is used as the services domain to query DNS servers.
Figure 26-6
Services Domain
Collaboration ServicesInside or Outside the Firewall?

To determine whether the client is inside or outside the corporate network and if Expressway is required,
the Jabber client queries the DNS server for specific DNS Service (SRV) records. The client sends
separate, simultaneous requests to the DNS server for the following SRV records:
_cisco-uds
_cuplogin
_collab-edge
If the name server resolves:
_cisco-uds or _cuploginThe client detects it is inside the corporate network and connects to one
or both of the following:
Cisco Unified Communications ManagerIf the name server resolves _cisco-uds.
Cisco Unified IM and PresenceIf the name server resolves _cuplogin.
26-8

Overview
_collab-edge and does not resolve _cisco-uds or _cuploginThe client attempts to connect to the
corporate network through Expressway and discover services.
None of the SRV recordsThe client prompts users to manually enter setup and sign-in details.
In Figure 26-7 the DNS server resolves the _cisco-uds and _cuplogin SRV queries and returns the IP
address/hostname of the collaboration services nodes. In this case, Expressway mobile and remote
access are not required.
Figure 26-7
Connecting to Internal Services
Inside Firewall
DNS
Unifed
CM
IM&P
Internet
_cisco-uds._tcp.emtest.com ? = c-em-cucm-1.emtest.com
_cuplogin._tcp.emtest.com ?
= c-em-im-1.emtest.com
297127
Chapter 26
_collab-edge._tls.emtest.com ? No resolution
If the name server does not resolve _cisco-uds or _cuplogin, but does resolve the _collab-edge SRV
record, the client attempts to connect to internal servers through Expressway. The DNS server in
Figure 26-8 returns the _collab-edge SRV record and the client connects through Expressway.
26-9
Chapter 26
Overview
Figure 26-8
Connecting through Expressway
Inside Firewall
DNS
Unifed
CM
IM&P
Internet
c-em-vcs-e-out.emtest.com
No resolution
_collab-edge._tls.emtest.com ? = c-em-vcs-e-out.emtest.com
297128
_cisco-uds._tcp.emtest.com ? No resolution
SRV Records
Table 26-2 lists the SRV records used by the internal DNS servers to discover internal services.
Table 26-2
Internal SRV Records
Service Record Description

_cisco-uds
Provides the location of Cisco Unified CM version 9.0 and higher.
_cuplogin
Provides the location of Cisco Unified Presence version 8.x. Supports

deployments where all clusters have not yet been upgraded to Cisco Unified
CM version 9.
Table 26-3 lists the SRV record provisioned on external name servers.
Table 26-3
External SRV Record
Service Record Description

_collab-edge
Provides the location of the Cisco Expressway-E server.

Note
The fully qualified domain name (FQDN) must be used in the data
field of the SRV record.
The NSLOOKUP command allows Windows clients to discover what SRV records are used by the Jabber
client. The example in Figure 26-9 shows resolution for only the _collab-edge SRV record and directs
the client to connect from outside the firewall to Expressway-E.
26-10
Chapter 26

Configuring Cisco Expressway Mobile and Remote Access
Figure 26-9
Verifying SRV Records

This section provides an overview and example of a basic configuration of Cisco Expressway Mobile
and Remote Access with Cisco AnyConnect support presented as a stepped example with critical items
highlighted throughout. While multiple deployment scenarios exist for Expressway, only one is
represented in this section. While multiple deployment scenarios exist for Expressway, only the most
common, referred to as Dual NIC with NAT, is represented in this section.
Variations in Expressway deployment have little impact on the core configurations. Alternate
Expressway deployment models, including high availability deployments, may be found in the
Expressway documentation references listed in Appendix B, References.
Expressway ConfigurationNetwork Topology Diagram

The diagram in Figure 26-10 is used as a reference for the rest of this section. The entire configuration
example is based on a working lab as depicted in this figure. All host names and IP addresses are
consistent throughout the example.
26-11
Chapter 26
Figure 26-10
DNS
Expressway ConfigurationNetwork Topology Diagram
c-em-dc-1
10.230.1.10
AD/DNS
Inside
10.230.1.1
ASA
Outside
172.26.137.x
Internet
c-em-cucm-1
10.230.1.30
DMZ MGMT
10.252.1.1
DMZ INET
10.253.1.1
CUCM
IM&P
C
c-em-vcs-c-1
10.230.1.35
LAN 1
LAN 2
c-em-vcs-e-1 E
10.253.1.35
10.252.1.35
Expressway-E
Exrpessway-C
297130
LAN 2
c-em-vcs-e-out
172.26.137.29
c-em-im-1
10.230.1.33
DNS Configuration
Proper DNS implementation is one of the most critical parts of an Expressway implementation. Both the
Expressway basic implementation as well as additional configuration for AnyConnect support relies
heavily on proper DNS implementation. Issues and inconsistencies with DNS may render the
implementation non-functional. Two different DNS systems are utilized to enable Expressway, the
internal corporate DNS system and external, or Internet, DNS system.
Table 26-4 and Table 26-5 show the significant DNS records that are used in this section.
Table 26-4
Internal (Corporate) DNS
Record Name
(emtest.com)
Record Type Record Data
Description
c-em-dc-1
Host (A)
10.230.1.10
AD/DNS
c-em-cucm-1
Host (A)
10.230.1.30
Unified CM
c-em-im-1
Host (A)
10.230.1.33
IM&P
c-em-vcs-c-1
Host (A)
10.230.1.35
Expressway-C
c-em-vcs-e-1
Host (A)
10.252.1.35
Expressway-E inside
c-em-vcs-e-out
Host (A)
172.26.137.29
Expressway-E outside NAT
_cisco-uds._tcp
SRV
c-em-cucm-1.emtest.com
SRV record for Unified CM
_collab-edge._tls SRV
26-12
c-em-vcs-e-out.emtest.com SRV record for Expressway
Chapter 26

Table 26-5
External (Internet) DNS
Record Name
(emtest.com)
Record Type Record Data
Description
c-em-vcs-e-out
Host (A)
Expressway-E outside NAT
_collab-edge._tls SRV
Note
172.26.137.29
c-em-vcs-e-out.emtest.com SRV record for Expressway
The external DNS records must match the internal DNS records exactly! Specifically the
_collab-edge._tls SRV record must reference the same A record and that A record must resolve to the
same IP address internally and externally. Non-matching records may cause significant functionality
issues, especially when using Cisco AnyConnect.
Figure 26-11 shows the creation steps for the _collab-edge DNS SRV record used in this example.
Figure 26-11
DNS SRV Creation Example
Unified CM and IM and Presence Configuration

Very little unique configuration is required for Unified CM and IM&P to have them work with
Expressway. Configuring for an internal deployment of Jabber users is the same as deploying Jabber
externally through Expressway, allowing existing implementations to add the Expressway component
with little alteration of existing Unified CM and IM&P configurations.
For continuity, the basic setup of LDAP, users, and devices in Unified CM is shown in this section. All
references are consistent with the overall example configuration.
26-13
Chapter 26
LDAP Integration
For existing collaboration deployments, LDAP integration is most likely already enabled. Appendix B,
References provides links to documentation that extensively covers LDAP integration. Figure 26-12
is simply a brief summary of the LDAP Active Directory integration enabled for this configuration
example.
Figure 26-12
LDAP Integration
After completing LDAP configuration, be sure to click Perform Full Sync Now, shown in the LDAP
Directory box in Figure 26-12, to ensure all user accounts are synchronized.
User Configuration
Users are synchronized from LDAP and must have a service profile applied and associated with one or
more devices. To begin, two basic UC Services are created, as shown in Figure 26-13.
26-14
Chapter 26

Figure 26-13
Note
UC Services
CTI service is shown being created in the above example. Only desktop Jabber clients support CTI
services and only when not using Expressway. CTI services configuration are ignored by mobile and
Expressway clients, but the same profile may be used for all clients.
Next a Service Profile is created and the three services are associated with it, as shown in Figure 26-14.
Figure 26-14
UC Service Profile
An Access Control Group (ACG) for all Jabber users is created, followed by another ACG for the
Expressway Control server, which is used later in the configuration.
26-15
Chapter 26
Figure 26-15
Access Control Group
The users are then enabled for IM and Presence, associated with the UC Service Profile, and Jabber
Access Control Group created earlier.
Figure 26-16
End User Association
Finally, an application user account is created for Expressway-C to access the Unified CM and IM&P
servers. This account is created locally on Unified CM. The Access Control Group (VCSAdmin-ACG)
created earlier is applied.
26-16
Chapter 26

Figure 26-17
Expressway Admin User
Device Configuration
Devices are created for multiple Jabber types. In the example in Figure 26-18, a Dual Mode for Android
Jabber type is used for the device, but multiple devices such as Android, iPhone, iPad, Windows, and
some other endpoints may all be associated with the same user and directory number/line.
26-17
Chapter 26
Figure 26-18
Device Configuration
When creating a device to be used with IM and Presence as well as with Expressway, associating the
User ID with both the Device and Directory Number/Line is essential for proper operation and is an
easily overlooked item.
Certificate Export
Communication between UC components and Expressway-C requires certificates. This process usually
involves creating unique self-signed certificates. A quick way to get the implementation up initially is
to export the existing Unified CM and IM &P web server certificates to be imported to the
Expressway-C. In this example, one Unified CM and one IM&P server exist. An easy way to quickly
export the cert is to simply use a web browser pointed at the server, as shown in Figure 26-19.
26-18
Chapter 26

Figure 26-19
Public Certificate Export
Using Firefox, the public cert is easily exported and saved locally to be imported into the Expressway
Control server, as described in the next section.
Expressway Configuration
To begin, the basic IP connectivity of the Expressway servers is assumed completed. While part of basic
connectivity, it is worth mentioning that accurate NTP synchronization is essential for proper operation.
Expressway will not function without all components properly synchronized to one or more reliable NTP
sources. The Expressway solution relies heavily on X.509 Certificates for the TLS connections and, if
the time gets out of synchronization, this can have a significantly negative affect on the ability of the
endpoints/Expressway servers to validate the exchanged certificates, greatly increasing the possibility
of an outage.
Importing Certificates for Unified CM and IM&P

As shown in Figure 26-20, the certificates exported from Unified CM and IM&P are imported into the
Expressway-C server as Trusted CA certificates. There is no need to import these certificates into the
Expressway-E server.
26-19
Chapter 26
Figure 26-20
Certificate Import
Basic Networking (DNS, Routing)

Figure 26-21 and Figure 26-22 show the basic IP configuration of Expressway-C and E for reference.
Figure 26-21
Expressway-C IP Configuration
26-20
Chapter 26

Figure 26-22
Expressway-E IP Configuration
Expressway DNS and Domain

Figure 26-23 shows the DNS configuration for Expressway-E. Both Expressway-E and Expressway-C
must have the System Host Name and Domain Name properly assigned in the DNS settings shown
below. The values in these fields are used during the creation of certificates for communication between
Expressway servers and for configuration files sent to Jabber clients.
The system host name for Expressway-E must be the DNS host name of the outside NAT address the
Jabber clients use to communicate with Expressway. In this example c-em-vcs-e-out is the correct
hostname to use here.
26-21
Chapter 26
Figure 26-23
Expressway-E DNS Settings
Expressway-C system host name is c-em-vcs-c-1.
Expressway-C Domain
Expressway-C also needs the domain defined in a separate section, as shown in Figure 26-24. This is not
required for Expressway-E.
Figure 26-24
Expressway-C Domain Configuration
Expressway-E Routing
While basic IP connectivity and routing is defined in the graphical interface shown previously, one piece
must be completed via command line for this deployment model. The Expressway-E has a default route
to 10.253.1.1, but no route back into the internal network through 10.252.1.1. This route must be
statically defined.
Below is the Cisco ip route command, followed by the route statement that would be executed on the
Expressway CLI to accomplish the same.
Cisco route statement as an example:
ip route 10.230.1.0 255.255.255.0 10.252.1.1
Equivalent Expressway static route statement:
26-22
Chapter 26

xCommand RouteAdd Address: "10.230.1.0" PrefixLength: 24 Gateway: "10.252.1.1"
Additional Expressway route statements:

xConfiguration ip route
(list all static routes)
xCommand RouteDelete RouteId: 1
(delete a static route #1)
Expressway-C to Unified CM + IM&P Configuration

With public certificates installed for Unified CM and IM&P, the next step is to configure Expressway-C
to communicate with those servers, as shown in Figure 26-25. The account used is the local user account
vcsadmin created earlier on Unified CM.
Figure 26-25
Expressway-C UC Configuration
Expressway-C to Expressway-E Configuration

Certificate Creation
The first step to establishing communication between Expressway-C and Expressway-E is to generate
certificates used for this communication. Figure 26-26 and Figure 26-27 show the screen for generating
a certificate signing request for Expressway-C and Expressway-E. Refer to the documentation
referenced in Appendix B, References for specific information related to certificate creation.
Note
Before generating the certificate signing request on the Expressway-C server, copy the contents of the
field entitled IM and Presence Chat Node Aliases to the same field on the Expressway-E certificate
signing request page. This value is auto-generated on Expressway-C, but must be manually entered on
Expressway-E.
26-23
Chapter 26
Figure 26-26
Expressway-C Certificate Signing Request
Expressway-E requires the FQDN of the internal interface, c-em-vcs-e-1.emtest.com, to be used as an

alternative name in the CSR to allow communication between Expressway-C and Expressway-E.
26-24
Chapter 26

Figure 26-27
Expressway-E Certificate Signing Request
Traversal Zone
A traversal zone is defined on both the Expressway-C and Expressway-E servers. Expressway-C
establishes a TCP connection to Expressway-E using an account defined locally on Expressway-E. Since
Expressway-E receives the connection, it is shown being configured first.
Expressway-E is shown configured as the receiver of the Traversal Zone connection. The local user
account used to establish this connection may be created from a link within the zone configuration
screen, as shown in Figure 26-28.
26-25
Chapter 26
Figure 26-28
Expressway-E Traversal Zone
Following that, the Expressway-C is configured as the originator of the Traversal Zone connection, as
shown in Figure 26-29, using the same account credentials just created in the previous step.
26-26
Chapter 26

Figure 26-29
Expressway-C Traversal Zone
Once communication is established, the Location field at the bottom of the Traversal Zone screen shows
a reachable message, as shown in Figure 26-30.
Figure 26-30
Expressway-E Traversal Zone Status
Note that this message may display reachable while other issues still exist between Expressway-C and
Expressway-E, such as improper firewall configuration. Also, in certain configurations, this status may
show reachable with the peer address pointing to the incorrect interface on Expressway-E. A status of
reachable does not necessarily mean functional.
Firewall Configuration
The Cisco ASA configuration is the most critical piece for proper AnyConnect compatibility with
Expressway clients running Cisco Jabber. The Cisco ASA is used for termination of AnyConnect tunnels
as well as filtering key DNS records that prevent Jabber clients from consistently connecting through
Expressway when AnyConnect is on the same device.
Port requirements for communication between Expressway-C and Expressway-E, as well as between
clients and Expressway-E, are well documented in the documentation listed in Appendix B,
References. The following section covers how SRV record filtering is enabled on the Cisco ASA used
in the example configuration.
26-27
Chapter 26
ASA SRV Filtering for AnyConnect Support

SRV filtering is achieved through implementation of a regular expression match within the Cisco ASA
firewall. This match will match against key SRV DNS requests coming from the client and drop them,
preventing them from reaching the internal DNS servers. The Jabber client is looking for responses from
three key SRV records:
_cisco-uds._tcpUnified CM
_cuplogin._tcpCisco Unified Presence (CUP) 8.X1
_collab-edge._tlsExpressway-E outside interface
If the Jabber client receives either of the first two SRV records, _cisco-uds or _cuplogin, it does not
attempt to connect to the Expressway server even when the Expressway SRV record, _collab-ege, is
present.
Regular Expressions
Two regular expressions are created, CUCM and IM. These are applied to a Regular Expression Class,
UC_HOSTS.
Figure 26-31
ASA Regular Expression Configuration
1. SRV record _cuplogin._tcp is only used for CUP 8.X implementations. CUP 8.X is not compatible with the
Expressway solution, but the existence of this record could cause issues and should be filtered as a preventative
measure. This record may exist due to a previous implementation of CUP.
26-28
Chapter 26

DNS Class Map

UC_HOSTS is applied as a match condition to a DNS Class Map, CollabEdgeDNSFilter. Also contained
in the Class Map are matches against the Type=33 (SRV) and Class=IN (Internet origin).
Figure 26-32
ASA DNS Class Map Configuration
DNS Inspect Map

DNS Class Map, CollabEdgeDNSFilter, is applied to a DNS Inspect Map, CollabEdge_Filter.
26-29
Chapter 26
Figure 26-33
ASA DNS Inspect Map Configuration1 of 2
Additional default settings under the Filtering tab on the DNS Inspect Map need to be confirmed as
selected, as shown in Figure 26-34.
Figure 26-34
ASA DNS Inspect Map Configuration2 of 2
26-30
Chapter 26

Service Policy Rule

DNS Inspect Map, CollabEdge_Filter, is applied to a Service Policy, inspection_default, which is
applied as a Global Service Policy.
Figure 26-35
ASA Service Policy Rule
Split-Tunnel Exclude for Expressway-E server

The split-tunnel exclude illustrated in Figure 26-36 excludes the external NAT address of the
Expressway-E server, 172.26.137.29, allowing clients to maintain an external connection to
Expressway-E when the Cisco AnyConnect tunnel is active.
26-31
Chapter 26
Figure 26-36
ASA Split-Tunnel Exclude
Note
The AnyConnect client for Android devices that are not Samsung branded does not support split-tunnel
exclude. All other AnyConnect clients, including the Android client for Samsung devices, supports
split-tunnel exclude. Non-Samsung Android devices do support split-tunnel include, so an alternate
group policy may be implemented using split-tunnel include instead of split-tunnel exclude.
Note
For split-exclude to work properly with The AnyConnect client for Samsung Android devices, an
AnyConnect Client Profile may need to be defined on the ASA with Allow Local LAN Access
enabled.
Relevant configuration excerpts from Cisco ASA are shown below:
regex CUCM "_cisco-uds._tcp"
regex IM "_cuplogin._tcp"
!
access-list ExcludeVPN extended permit ip any host 172.26.137.29
!
group-policy Exclude internal
group-policy Exclude attributes
wins-server none
dns-server value 10.230.1.10
vpn-tunnel-protocol ikev2 ssl-client
split-tunnel-policy excludespecified
split-tunnel-network-list value ExcludeVPN
default-domain value emtest.com
26-32
Chapter 26

address-pools value Exclude

webvpn
anyconnect profiles value CollabEdgeScenarios type user
anyconnect ask none default anyconnect
!
class-map type regex match-any UC_HOSTS
description This Regex Class matches the CUCM or IM servers.
match regex IM
match regex CUCM
class-map inspection_default
match default-inspection-traffic
class-map type inspect dns match-all CollabEdgeDNSFilter
description This DNS Class-map will be used to drop CUCM and IM SRV Records
match domain-name regex class UC_HOSTS
match dns-type eq 33
match dns-class eq IN
!
!
policy-map type inspect dns CollabEdge_Filter
parameters
message-length maximum client auto
message-length maximum 512
class CollabEdgeDNSFilter
drop log
policy-map global_policy
class inspection_default
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect ip-options
inspect icmp
inspect dns CollabEdge_Filter
!
service-policy global_policy global
Figure 26-37 shows DNS-SRV filtering configuration excerpts from the ASA with referencing
annotation.
26-33
Chapter 26
Connection Scenarios
Figure 26-37
Note
ASA Configuration Excerpts
Some version of ASDM may not apply the inspect dns command correctly to the global policy-map.
In the example above, inspect dns CollabEdge_Filter may be applied as inspect dns, leaving off
CollabEdge_Filter. It is advisable to check the configuration for this issue if configuring through
ASDM.
When a Jabber client gets a network connection, the device gets the address of a DNS name server from
the DHCP server. Depending on the network connection, the DNS server might be internal or external
to the corporate network.
This Cisco Jabber client uses the DNS name server received from the DHCP server. The users ID and
domain is used to log in to Jabber and to determine the services domain, which is used in combination
with DNS SRV records to query the DNS server. The login screen shown in Figure 26-38, taken from an
Android Jabber client, shows the services domain as emtest.com.
26-34
Chapter 26

Figure 26-38
Jabber Login Screen
From the Internet

Cisco Jabber clients connecting from outside the corporate network (or public Internet) query their
public DNS server for the SRV records. The DNS server resolves the _collab-edge SRV record and
allows the Jabber client to connect through Expressway.
Figure 26-39
Jabber Client Connecting from the Internet
Inside Firewall
DNS
Unifed
CM
IM&P
Internet
_collab-edge._tls.emtest.com
297158
26-35
Chapter 26
In this configuration the client connects to the Collaboration Services servers through Expressway. This
VPN-less service is attractive for users that require seamless Jabber collaboration from any location
without the need for a VPN session.
Cisco AnyConnect Secure Mobility Client

The Cisco AnyConnect Secure Mobility Client provides secure connectivity across a broad set of
desktop and mobile devices. This is ideal for mobile users requiring connectivity from different locations
and the always-on, intelligent VPN offered by the AnyConnect client. The AnyConnect client selects the
optimal network access location and adapts its tunneling protocol to the most efficient method.
The AnyConnect client is designed for mobile users and can be configured so that a VPN connection
remains established during IP address changes or loss of connectivity. It is also able to automatically
connect when the user is at a remote location and disconnect when the user is in the office.
The AnyConnect client provides full-tunneling access to enterprise resources and applications,
providing a consistent LAN-like user experience and is supported in Windows PC, Macs, and Android
and iOS devices.
The Jabber client shown in Figure 26-40 is connecting from the public Internet and has established a
VPN connection that securely tunnels all traffic from the device into the enterprise. This allows the client
to access resources from the enterprise and use the internal DNS name server for resolution.
Figure 26-40
Cisco AnyConnect Client VPN Tunnel
Inside Firewall
Primary
Unifed
CM
IM&P
DNS
Internet
IPse
c Tu
nne
Calls are dropped when

AnyConnect connects/disconnects
297159
_cisco-uds._tcp.emtest.com
_cuplogin._tcp.emtest.com
AnyConnect and Expressway Co-existence

In the scenario shown in Figure 26-40, a Jabber session is established to allow the client to interact via
voice, video, and IM sessions with other Jabber users.
A problem arises when the client disconnects the AnyConnect session, causing an active Jabber session
to drop. This has a negative impact on the users experience, since an active voice or video call is
disconnected. The impact to IM sessions is minimal, since the IM session reconnects shortly after.
26-36
Chapter 26

For AnyConnect and Expressway to coexist, the Jabber client must be able to reach the Expressway-E
without relying on the VPN tunnel. By reaching the Expressway-E server independently from the
AnyConnect tunnel, Jabber calls remain up and the collaboration experience is maintained.
To achieve this configuration, the following must be in place:
Enable split tunneling on the ASA firewall to remove the Expressway-E address from the tunnel.
Control which SRV records are resolved from the client to force the Jabber client to connect through
Expressway.
Split Tunneling
The split tunnel feature on the ASA allows administrators to specify which traffic traverses the VPN
tunnel and which traffic goes in the clear. In this case, all traffic should traverse the VPN tunnel with the
exception of the Expressway server address.
By removing the Expressway IP address from the VPN tunnel, the Jabber client connects through
Expressway even when the AnyConnect client connects or disconnects from the ASA, ensuring that the
Jabber session remains connected.
Figure 26-41 shows how the Expressway address is removed from the VPN tunnel and traverses the
Internet while the rest of the traffic relies on the tunnel to reach corporate resources.
Figure 26-41
Excluding Expressway from Tunnel
Inside Firewall
Unifed
CM
IM&P
Internet
IPse
c Tu
nne
Exclude Expressway
from tunnel
297160
In ASA configuration, the Exclude Network List feature defines a list of networks to which traffic is sent
in the clear. The example shown in Figure 26-42 creates an Exclude Network List with the Expressway-E
IP address, removing the IP address from the tunnel.
Note
Configuring Cisco Expressway Mobile and Remote Access provides more details on the ASA
configuration.
26-37
Chapter 26
Figure 26-42
Excluding Expressway from Tunnel
Controlling SRV Records

Since the Jabber client relies on SRV records to determine its service location, the network elements can
be configured to filter or deliver the appropriate SRV records. When the client receives a resolution for
the _collab-edge SRV record, the client uses the Expressway server to reach the Collaboration Services
servers.
This document explores a way of controlling what SRV records are provided to the client, assuming split
tunneling has been configured on the ASA.
Filtering SRV Records at the ASA

The Cisco ASA may be configured to prevent _cuplogin and _cisco-uds SRV requests from reaching the
DNS server. A regular expression is configured to match the content of certain traffic. In this case, the
ASA looks for the strings _cisco-uds or _cuplogin.
Once the regular expression is defined, a class-map is used to identify traffic based on the regular
expression and prevent DNS SRV requests records from reaching the server. Figure 26-43 shows how
the regular expression is defined on the ASA.
26-38
Chapter 26

Figure 26-43
Note
Regular Expressions in ASA
Configuring Cisco Expressway Mobile and Remote Access provides more details on the ASA
configuration.
Since the Jabber client only receives a response for the _collab-edge SRV record, the client makes use
of Expressway independent of VPN to reach the collaboration services and to communicate with other
Jabber clients. Changes in AnyConnect client do not impact any active Jabber connections.
Figure 26-44 shows how the ASA has filtered the internal SRV records and how the client only receives
the _collab-edge SRV record.
26-39
Chapter 26
Figure 26-44
Filtering SRV Records at ASA
Inside Firewall
Primary
DNS
Internet
_cisco-uds._tcp.emtest.com
IPse
c Tu
nne
297163
Unifed
CM
IM&P
A simple way to verify that the Jabber client is connecting through Expressway is by checking the
Connection Status in the Windows Jabber client. Figure 26-45 shows the Connection Status from a
Windows Jabber client. This information is not available in mobile Jabber clients.
Figure 26-45
Cisco Jabber Status
Filtering DNS SRV records at the ASA leverages existing hardware and software and does not require
additional servers to manage or deploy.
26-40
Chapter 26

From the Corporate Network

A Cisco Jabber connection initiated from inside the corporate network does not require Expressway
services and signs in directly with on-premise collaboration servers (e.g., Cisco Unified
Communications Manager and IM & Presence).
Primary DNS Server

Figure 26-46 shows a Jabber client receiving the two internal SRV records (_cisco-uds and _cuplogin)
that allow the client to reach the collaboration services servers. By getting a valid response from the DNS
server, the client communicates directly with servers and other Jabber clients and does not require
Expressway services.
Figure 26-46
Jabber Client inside the Corporate Network
Inside Firewall
DNS
Unifed
CM
IM&P
Internet
= c-em-im-1.emtest.com
_collab-edge._tls.emtest.com ? No resolution
297165
_cisco-uds._tcp.emtest.com ? = c-em-cucm-1.emtest.com
Alternate DNS Server for Differentiated Access

Internal Cisco Jabber clients segmented by internal VLANs/ACLs or other type of filtering can benefit
from using Expressway to enable communication.
The BYOD CVD highlights several use cases that provide differentiated access to endpoints, e.g., some
clients are granted Partial Access or Internet-Only access based on ISEs authorization profiles. To
enforce this Partial or Internet access, Access Control Lists (ACLs) are used to allow/block access to
internal resources.
In the case of Partial Access, an ACL, named ACL_Partial_Access, provides a way to allow users to
reach only the Internet and some internal resources and denies access to all other resources. This can
have a negative impact on Cisco Jabber clients, since clients may be connecting from many different
segments or VLANs in the network and may need to reach clients on a different VLAN.
26-41
Chapter 26
The Expressway solution provides an attractive solution to allow Cisco Jabber clients to communicate
with each other, bypassing any filtering or network segmentation. By allowing the client to receive only
the _collab-edge SRV record, the client relies on the Expressway solution, which acts as a proxy for
collaboration between two Jabber clients.
A possible way to ensure that the client only gets the _collab-edge SRV record is to introduce an
Alternate DNS server, which only returns the _collab-edge SRV record and not the internal _cuplogin
and _cisco-uds records. Since the DNS server address is provided by the DHCP server, unique DHCP
scopes can be created for clients that deserve Full, Partial Access, or Internet Only access.
Note
In this scenario, it is not necessary to filter SRV records at the ASA.
VLANs
For devices connecting from the campus location, the VLANs in Table 26-6 were assigned. The VLANs
are preconfigured on the switching infrastructure.
Table 26-6
Virtual LANs
VLAN
Access Granted
Full Access
Partial Access
Internet Only
To support the VLAN definition shown in Table 26-6, the Wireless LAN Controller is configured with
a default VLAN (VLAN 2) to which clients originally connect. The ISE may determine that the client
belongs to a different VLAN and can dynamically move the client to a different VLAN.
In addition to an IP address, clients receive the address of a DNS server from the DHCP server.
Figure 26-47 shows how clients connecting to VLAN2 receive the IP address of the internal DNS server
while clients connecting to VLAN 5 receive the IP address of the Alternate DNS server.
26-42

Figure 26-47
DHCP Providing DNS Server
Inside Firewall
DHCP
Unifed
CM
IM&P
Internet
VLAN2
Full
Primary DNS
VLAN5
Partial or
Internet
Alternative DNS
297166
Chapter 26
Figure 26-48 shows how the WLC is configured to assign devices connecting to the BYOD_Employee
SSID to VLAN 2 by default.
Figure 26-48
BYOD_Employee SSID
26-43
Chapter 26
The AAA Override feature (Dynamic VLAN assignment) is used to move clients to specific VLANs
based on the returned RADIUS attributes from the ISE. This feature is already highlighted several times
throughout the CVD.
Partial Access
To grant Partial Access to devices connecting from the campus, the ISE authorization policy shown in
Figure 26-49 was used. If all the conditions in this rule match, the Campus WiFi Partial Access
authorization profile is invoked. More details on this rule can be found in Chapter 15, BYOD Enhanced
Use CasePersonal and Corporate Devices.
Figure 26-49
Campus WiFi Personal Partial
The Campus WiFi Partial Access authorization profile shown in Figure 26-50 has been modified to
dynamically move Partial Access clients to VLAN5 in addition to enforcing the ACL_Partial_Access
permissions.
26-44
Chapter 26

Figure 26-50
Partial Access Authorization Profile
The ACL_Partial_Access ACL shown in Figure 26-51 is configured to allow access to the alternate DNS
server, other internal resources, and the Internet. The ACL is also configured to block access to the
primary DNS server.
26-45
Chapter 26
Figure 26-51
ACL_Partial_Access ACL
The ACL_Partial_Access ACL specifies the following access:
Deny access to the primary DNS server (10.230.1.10).
Allow access to alternate DNS server (10.230.1.14).
Allow access to some internal resources and the Internet.
By moving clients dynamically to VLAN5 and allowing access to the alternate DNS server, endpoints
that have been granted Partial Access query the Alternate DNS server and receive the _collab-edge SRV
record, allowing them to connect through Expressway.
Figure 26-52 shows two Jabber clients connecting from different VLANs.
26-46
Chapter 26

Figure 26-52
Jabber Across SegmentsPartial Access
Inside Firewall
Primary Alternate
DNS
DNS
Unifed
CM
IM&P
Internet
cisco-uds._tcp.emtest.com
VLAN5
Partial
297171
VLAN2
Full
Expressway acts facilitates the communication between clients on VLANs 2 and 5.
Internet Only Access

To grant Internet Only access to devices connecting from the campus, the ISE authorization policy
shown in Figure 26-53 was used. If all the conditions in this rule match, the Campus WiFi Internet Only
authorization profile is invoked. More details on this rule can be found in Chapter 15, BYOD Enhanced
Use CasePersonal and Corporate Devices.
Figure 26-53
Campus WiFi Internet Only
The Campus WiFi Internet Only authorization profile shown in Figure 26-54 has been modified to
dynamically move Internet Only clients to VLAN5 in addition to enforcing the ACL_Internet_Only
permissions.
26-47
Chapter 26
Figure 26-54
Internet Only Authorization Profile
The ACL_Internet_Only ACL shown in Figure 26-55 is configured to allow access to the alternate DNS
server, other internal resources, and the Internet. The ACL is also configured to allow access to the
primary DNS server since access to the DNS server is required for the Advanced Use case for Mobile
Device Management (MDM) remediation rules (see Chapter 17, BYOD Advanced Use CaseMobile
Device Manager Integration).
26-48
Chapter 26

Figure 26-55
ACL_Internet_Only ACL
The ACL_Internet_Only ACL specifies the following access:
Allow access to alternate DNS server (10.230.1.14).
Allow access to some internal resources and the Internet.
By moving clients dynamically to VLAN5 and allowing access to the alternate DNS server, endpoints
that have been granted Internet Only Access query the Alternate DNS server and receive the
_collab-edge SRV record, allowing them to connect through Expressway.
Figure 26-56 shows two Jabber clients connecting from different VLANs.
26-49
Chapter 26
Figure 26-56
Jabber Across SegmentsInternet Only
Inside Firewall
Primary Alternate
DNS
DNS
Unifed
CM
IM&P
Internet
cisco-uds._tcp.emtest.com
VLAN5
Internet
297175
VLAN2
Full
Expressway facilitates the communication between clients on VLANs 2 and 5.
26-50
CH AP TE R
27

A BYOD design should be able to accommodate devices that attempt to connect remotely to access the
internal resources. The device could be a workstation, tablet, smartphone, or any other device which is
allowed to connect securely to the network. In this design, the Cisco ASA is used as a VPN gateway for
establishing an SSL VPN session to the remote endpoints. The ASA authenticates the users digital
certificate. Cisco ISE then authenticates the user via an RSA SecurID token. The combination of both
allows the device onto the network. Figure 27-1 shows the network components involved in remote
device access.
Figure 27-1
Remote Device Network Components
1. AnyConnect Installation
Campus/
Core
2. AnyConnect Installed
ISE
WLC
Internet
CA
RSA
292754
AD
This design assumes the following for providing remote access capability:
Devices that want to connect to the network remotely must be corporate approved devices. The
corporate approved devices are the ones that have been provisioned with a digital certificate by the
IT organization. To understand more about corporate approved devices, see Chapter 16, BYOD
Limited Use CaseCorporate Devices.
Devices must be provisioned at the campus. The provisioning process consists of:
Installing the AnyConnect Client
Configuring the VPN gateway IP address
27-1
Chapter 27
Solution Components
Setting up one-time-password scheme for the user.
These steps must be completed at the campus location before it can be used remotely. This design
does not allow remote provisioning of the devices.
Devices connecting remotely are subjected to two factor authentication, which means the user
should provide two forms of credentials.
Solution Components
The following components play a role in providing connectivity to remote clients:
Cisco Adaptive Security Appliance (ASA)Functions as an SSL VPN concentrator for terminating
VPN sessions.
Cisco AnyConnectActs as a VPN client installed on the remote device.
Cisco Identity Services Engine (ISE)Acts as an intermediary to an external identity source for
authentication between remote endpoints and the RSA Server. The token gets forwarded from the
client to the ASA, from the ASA to the ISE, and then from the ISE to the RSA.
RSA SecurIDActs as the authentication server for tokens generated by the client.
RSA SecurID
VPN security is only as strong as the methods used to authenticate users (and device endpoints) at the
remote end of the VPN connection. Simple authentication methods based on static passwords are subject
to password cracking attacks, eavesdropping, or even social engineering attacks. Two-factor
authentication, which consists of something you know and something you have, is a minimum
requirement for providing secure remote access to the corporate network. For more details, see:
http://www.cisco.com/web/about/security/intelligence/05_08_SSL-VPN-Security.html.
This design includes the RSA SecurID Authentication Server 7.1, along with RSA SecurID hardware
tokens, to provide two-factor authentication. The passcode that the user presents is a combination of their
secret PIN and the one time password (OTP) code that is displayed on their token at that moment in time.
This design utilizes both RSA SecurID (two-factor authentication) in conjunction with the deployment
and use of x.509 client digital certificates. Figure 27-2 shows how RSA is used for two-factor
authentication.
Figure 27-2
RSA Used for Two-Factor Authentication
Client Initiates VPN Session
ASA validates the certificate

and forwards the two-factor
authentication request to ISE
ISE checks against

the RSA Identity Store
Internet
RSA
ASA
Accept/Reject
27-2
Identity Services
Engine
Accept/Reject
Accept/Reject
292312
802.1X Client
RSA Server
Chapter 27

Solution Components
For information on configuring the RSA Secure Authentication Manager, see:

http://www.emc.com/security/rsa-securid.htm.
ISE Integration with RSA

The RSA Identity Store is used primarily to authenticate remote users. The remote users are
authenticated initially by their digital certificates and then they must provide a one-time password using
a RSA SecurID token. To configure the RSA as an identity store, click Administration > Identify
Management > External Identity Sources > RSA SecurID > Add, as shown in Figure 27-3.
Figure 27-3
RSA Server as an Identity Store for ISE
VPN Design Considerations

This section discusses the primary role of the ASA for this design, which is to terminate SSL VPN
connections. The following are some of the many design considerations when implementing the SSL
VPN:
How do remote users trust the VPN gateway?
How does the VPN gateway identify remote users?
How to organize different types of users in groups so that different kinds of services can be
provided?
What kind of mobility client solution is needed for a particular client?
Once the right kind of VPN solution is identified, how will the mobility client be installed on the
remote device?
How to centralize the policy settings for VPN users? It is not always easy or convenient for remote
users to configure a mobile device for VPN functionality.
27-3
Chapter 27
Solution Components
The Cisco ASA coupled with the Cisco AnyConnect client addresses the considerations mentioned
above. The Cisco AnyConnect client 3.0 is used to meet the needs of wired, wireless, and remote users.
The Cisco AnyConnect Secure Mobility client is the next-generation VPN client, providing remote users
with secure IPsec (IKEv2) or SSL VPN connections to the Cisco 5500 Series Adaptive Security
Appliance (ASA). AnyConnect provides end users with a connectivity experience that is intelligent,
seamless, and always-on, with secure mobility across todays proliferating managed and unmanaged
mobile devices.
The Cisco AnyConnect Secure Mobility client integrates new modules into the AnyConnect client
package:
Network Access Manager (NAM)Formerly called the Cisco Secure Services Client, this module
provides Layer 2 device management and authentication for access to both wired and wireless
networks.
Posture AssessmentThe AnyConnect Posture Module provides the AnyConnect Secure Mobility
Client with the ability to identify the operating system, antivirus, antispyware, and firewall software
installed on the host prior to creating a remote access connection to the ASA. Based on this pre-login
evaluation, you can control which hosts are allowed to create a remote access connection to the
security appliance. The Host Scan application is delivered with the posture module and is the
application that gathers this information.
TelemetrySends information about the origin of malicious content detected by the antivirus
software to the web filtering infrastructure of the Cisco IronPort Web Security Appliance (WSA),
which uses this data to provide better URL filtering rules.
Web SecurityRoutes HTTP and HTTPS traffic to the ScanSafe Web Security scanning proxy
server for content analysis, detection of malware, and administration of acceptable use policies.
Diagnostic and Reporting Tool (DART)Captures a snapshot of system logs and other diagnostic
information and creates a .zip file on your desktop so you can conveniently send troubleshooting
information to Cisco TAC.
Start Before Logon (SBL)Forces the user to connect to the enterprise infrastructure over a VPN
connection before logging on to Windows by starting AnyConnect before the Windows login dialog
box appears.
For more information on the Cisco AnyConnect 3.0 client, see:

http://www.cisco.com/en/US/docs/security/vpn_client/anyconnect/anyconnect30/administration/guide/
ac01intro.html.
Figure 27-4 shows the steps to provide VPN connectivity.
Figure 27-4
User installs
AnyConnect
client
Configure
ISE to
authenticate
remote users
Access
the
Network
292757
Configure
ASA to
establish the
VPN session
High Level Steps for Providing VPN Connectivity
27-4
Chapter 27

Solution Components
ASA Configuration
The configuration of the ASA involves many steps. Figure 27-5 shows, at a high level, the steps required
to configure the ASA.
Configuration of ASA
ASA must obtain its

identity certificate
signed by the CA
server.
ASAs Identity
Certificate
Group
Policy
Configure the CA
server location.
Configure the Address
pool.
Split tunnel AC.
Enable authentication
methods for each user
such as AD, CA server.
Connection
Profile
VPN Profile
Editor
Centralizing the policy
remote users.
For example, the policy
can require remote
users to use RSA
SecureID.
292758
Figure 27-5
ASAs Identity Certificate

The ASA needs to present a digital certificate as means of authenticating itself to the clients. The remote
clients validate the digital certificate and if the validation is successful, then they proceed to the next
steps of establishing a VPN connection.
The digital certificate provided by the ASA must be issued by a trusted third-party like VeriSign or it
could be also issued by an internal CA, which is signed by a trusted third-party. Instead, if the ASA
presents a self-signed certificate, then the clients cannot validate the certificate because the signing
authority (ASA for self-signed) is not in the list of trusted CAs in the client browser. Hence for greater
security, it is recommended that the ASAs digital certificate is either issued by a trusted third-party or
by an internal CA which is signed by a trusted third-party. When using a Microsoft CA as internal CA,
it is important to verify that the certificate properties support Server Authentication. Figure 27-6 shows
the certificate that can be used for server authentication. The certificate should contain EKU of Server
Authentication, as indicated in Figure 27-6.
27-5
Chapter 27
Solution Components
Figure 27-6
Certificate for Server Authentication
The ASA can obtain the certificate from the CA server by using SCEP or by a manual cut-and-paste
method. To obtain more information on deploying certificates on the ASA, see:
http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/cert_cfg.html.
The following example shows the ASA configuration for certificate enrollment:
crypto ca trustpoint WIN2K-CA
enrollment terminal
subject-name CN=ASA-remote1
serial-number
ip-address 172.26.185.195
keypair ssl
no client-types
crl configure
The above trust is used by ASA to obtain its own Identity Certificate from the CA server. In this design
the enrollment method is terminal.
The following command shows the digital certificate issued by the CA server to the ASA:
ASA-remote1(config)# show crypto ca certificates
Certificate
Status: Available
Certificate Serial Number: 1594b5d9000000000213
Certificate Usage: General Purpose
Public Key Type: RSA (2048 bits)
Signature Algorithm: SHA1 with RSA Encryption
Issuer Name:
cn=secbn1-WIN-MRL23B7NQO6-CA
dc=secbn1
dc=com
Subject Name:
cn=ASA-remote1
hostname=ASA-remote1.secbn1.com
ipaddress=172.26.185.195
serialNumber=JMX1215L1KF
27-6
Chapter 27

Solution Components
CRL Distribution Points:

[1] ldap:///CN=secbn1-WIN-MRL23B7NQO6-CA,CN=WIN-MRL23B7NQO6,CN=CDP,CN=Publi
c%20Key%20Services,CN=Services,CN=Configuration,DC=secbn1,DC=com?certificateRevo
cationList?base?objectClass=cRLDistributionPoint
[2] http://win-mrl23b7nqo6.secbn1.com/CertEnroll/secbn1-WIN-MRL23B7NQO6-CA.
crl
Validity Date:
start date: 09:29:35 EST May 30 2012
end
date: 09:29:35 EST May 30 2014
Associated Trustpoints: WIN2K-CA
Note
The client must have network connectivity to the CRL distribution point as provided in the certificate.
ASA Trust Point to Authenticate Remote Users

ASA also needs a trust point to authenticate remote users identity certificates. The following is the
configuration of the trust point:
crypto ca trustpoint Validate
enrollment terminal
crl configure
The above trust point Validate is used to copy the root CA certificate. To understand more about how
to cut-and-paste certificates using terminal method, see:
http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/cert_cfg.html.
Creating Groups for Different Types of Users

Group policy is an important building block for designing an effective access mechanism for users. The
needs of specific users can differ. For example, one user might like to have a domain value of xyz.com
and have 1.1.1.1 and 2.2.2.2 as their DNS servers. Another user might have similar requirements, but in
addition might need a proxy server configured for their user name. If you have to attach all these
attributes to each individual user, the configuration might become very large and complex. To solve this
problem, multiple groups can be created, each with its set of individual attributes. In this case you can
simply associate a user with a group name, rather than the large number of attributes, thus minimizing
the configuration complexity when you have multiple users.
By default, the Cisco ASA creates DftGrpPolicy and the other group polices that inherit most of the
common attributes. Only very specific attributes need to be configured explicitly for each group.
For more information about configuring tunnel groups, group policies, and users, see:
http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/vpngrp.html.
In the group policy definition for this design guide, the main attributes needed are vpn-tunnel-protocol,
split-tunnel-network-list, and address pool location. The following example shows how this group policy
was defined:
group-policy SSLClientPolicy internal
!This group policy is defined internally not
downloaded from radius.
group-policy SSLClientPolicy attributes
wins-server value 10.1.6.100
! WINS server IP address
dns-server value 10.1.6.100
! DNS server IP address
vpn-tunnel-protocol ssl-client ssl-clientless
split-tunnel-policy tunnelspecified
split-tunnel-network-list value split_ACL ! split_ACL prevents some local network
traffic from getting into VPN traffic.
default-domain value secbn1.com
27-7
Chapter 27
address-pools value testpool
! The IP address pool value.
Connection Profile Configuration

While group policies define the attributes for a group, the connection profile specifies the attributes
specific to a connection. For example, a connection profile for AnyConnect specifies if the users
belonging to this connection are authenticated by a RADIUS server or locally. The connection profile
also points to the group profile to which it belongs. If no connection profile is defined on the system, the
ASA points to a default connection profile, but to make administration simple it is better to define a
specific group and connection profiles. The following example shows the ASA configuration for the
AnyConnect connection profile:
tunnel-group SSLClientProfile type remote-access
tunnel-group SSLClientProfile general-attributes
authentication-server-group ISE
! The remote sessions are authenticated with ISE.
default-group-policy SSLClientPolicy ! The parent group policy used by this connection
profile.
tunnel-group SSLClientProfile webvpn-attributes
authentication aaa certificate
! The remote users are authenticated by AAA and
Digital Certificate.
group-alias SSLVPNClient enable ! The remote users are presented with this alias name
during the session.
group-url https://172.26.185.195/SSLVPNClient enable
group-url https://192.168.167.225/SSLVPNClient disable
!
The above configuration steps illustrate how to configure SSLVPN sessions with AnyConnect. The same
configuration can also be done using ASDM editor or by another management tool. To obtain more
information about the configuration using other tools, refer to ASA configuration editor at:
http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/vpn_anyconnect.html#wp10
90443.
Enabling AnyConnect VPN on the ASA

After defining the group-policy and connection profile on the ASA, the last step is to enable the
AnyConnect VPN feature on the ASA. After enabling AnyConnect, the administrator can also configure
additional features, such as pointing to the AnyConnect image software, NAM profile, and VPN Profile.
The following example shows the configuration commands to enable AnyConnect modules:
webvpn
enable outside
anyconnect keep-installer installed ! This forces the anyconnect to remain installed on
the endpoint device, after the session is terminated.
anyconnect modules none
Provisioning a Windows Device to Remotely Connect to the

Network
For a corporate approved device to obtain remote access capability, the user must perform the following
steps at the campus location:
27-8
Chapter 27

Step 1
Install the RSA SecurID application on the remote device and, with IT support, provision the software
on the device.
Step 2
It is assumed that before the AnyConnect installation begins, the workstation has successfully completed
the enrollment and provisioning process, which implies that the workstation has a valid digital certificate
issued by the CA server.
The steps shown below are for one time installation. After the installation is completed, the user is never
prompted for these steps.
Step 3
Initiate an SSL VPN session using a web browser to the ASA VPN gateway IP address, which is shown
in Figure 27-7.
Figure 27-7
SSL VPN Session to ASA VPN Gateway IP Address
Note
The certificates presented by the ASA remote endpoints and the identity certificate of the ASA must be
signed by the same root CA server.
Step 4
The user is presented with login screen and the user needs to select the Group to which they belong. The
user is expected to select the group-policy name and the valid credentials, as shown in Figure 27-8.
27-9
Chapter 27
Figure 27-8
Step 5
Selecting Group
After the user credentials are validated, Cisco AnyConnect installation begins, which is depicted in
Figure 27-9.
Figure 27-9
Cisco AnyConnect Installation
Figure 27-10 depicts successful installation of Cisco AnyConnect on the workstation:
27-10
Chapter 27

Figure 27-10
Successful Installation of Cisco AnyConnect
Figure 27-11 shows the Windows workstation establishing a session.

Figure 27-11
AnyConnect Initiates VPN Connection
As explained in the Connection Profile Configuration, when a remote worker connects to the network
both ISE and the ASA authenticate the device. ASA initially validates the digital certificate of the remote
user. If the certificate is valid, then the next step of authentication happens, which is through the RSA
SecurID token. The remote worker is allowed to access the network if both authentications are valid.
The logic flow in Figure 27-12 shows what happens when a remote device accesses the network.
27-11
Chapter 27
Figure 27-12
Logic Flow for a Remote Worker Accessing the Network
Remote Device
Connects to ASA
Valid
Certificate?
Authentication
Method
PAP_ASCII
DenyAccess
ISE Authenticates
using the RSA
Identity Store
Authentication
Successful?
Firewalls
IP Address?
Permit Access
DenyAccess
292765
ASA VPN
Device Type?
Verifying What ISE Policy Rules Are Applied

As shown in Figure 27-12, ISE validates the remote user in the following sequence:
1.
Validate if the Device Type Equals ASA VPN. This is to ensure that only devices that are configured
as VPN Type can initiate the communication with ISE.
2.
Validate if the authentication protocol is PAP_ASCII. This is the protocol used by ASA to send the
RSA Secure ID token passwords to the ISE, which the ISE sends to RSA Secure ID server for
authentication.
3.
In the authorization Rule, ISE validates the Source IP address of the ASA as a means to authorize
the connection. In this design remote VPN users are only authenticated by ASA and ISE, and there
is no authorization taking place. Figure 27-13 and Figure 27-14 detail the authentication and
authorization rules in ISE.
The ISE rule shown in Figure 27-13 uses the RSA SecurID identity store for authentication.
27-12
Chapter 27

Figure 27-13
Authentication Rule
The ISE authorization rule shown in Figure 27-14 matched since a remote device connected and the
Network Access: Device IP Address matches the ASA firewalls address.
Figure 27-14
Authorization Rule
To verify what rules were applied on the ISE, click Monitor > Authentication, as shown in
Figure 27-15.
Figure 27-15
Log Information on ISE for Successful Remote Worker Authentication
27-13
Chapter 27
Provisioning an Apple iOS Device to Remotely Connect to the

Network
Similar to workstations, an Apple iOS device that is provisioned at the campus can establish an SSL VPN
connection to the campus network remotely using Cisco AnyConnect. The following steps must be
completed by the user before establishing SSL VPN connectivity:
Step 1
The iOS device should already have a digital certificate installed. Figure 27-16 shows an example of a
provisioned device.
Figure 27-16
Provisioned Device
Step 2
The user should install the Cisco AnyConnect from Apples App Store.
Step 3
Configure the profile on AnyConnect and select the certificate which is already installed in the device
(Certificate Provisioning must happen before initiation remote VPN communication), as shown in
Figure 27-17.
Figure 27-17
Configure Profile and Select Certificate
27-14
Chapter 27

Step 4
Select the VPN Group, which the Network Administrator must inform the user about the right group to
select, and enter the user credentials. ASA VPN authentication requires the user certificate and the user
credentials. Hence the user credentials have to be entered, as shown in Figure 27-18.
Figure 27-18
User Credentials
Figure 27-19 shows a successfully connected SSL VPN session
27-15
Chapter 27
Figure 27-19
Connected SSL VPN Session
27-16
CH AP TE R
28
BYOD Network Management and Mobility

Services
Whats New: The discussion of how the Cisco Mobility Services Engine (MSE) provides location
context awareness for wireless devices has been updated to also discuss how the MSE enhances rogue
AP and client detection, Cisco CleanAir interference detection and location, and wireless Intrusion
Prevention (wIPS)all managed through Cisco Prime Infrastructure (PI). A discussion of the benefits
of Cisco CleanAir technology has been added to the chapter. Also a discussion around the Wireless
Security and Spectrum Intelligence (WSSI) module for the Cisco 3600 Series AP, which provides a
dedicated radio for features such as Cisco CleanAir, wIPS, rogue detection, location context awareness,
and radio resource management (RRM), has also been added to the chapter.
Network Management for BYOD is separated into five sections:
Cisco Mobility Services EngineA summary of MSE and all the Cisco wireless technologies that
enable MSEs capabilities.
Cisco Prime Infrastructure OverviewA brief overview that covers the basic capabilities of Cisco
Prime Infrastructure. The subsequent sections are focused on specific abilities of Prime
Infrastructure directly related to BYOD.
User and Device TrackingInformation from multiple components is consolidated by Cisco

Mobility Services Engine and displayed by Prime Infrastructure to identify and track end users and
end devices on the network.
Interference and IntrusionDetection and LocationInformation from multiple components is

consolidated by Cisco Mobility Services Engine and displayed by Prime Infrastructure to detect,
identify, and locate interference devices and intrusion attacks.
Template-Based ConfigurationCovers using Cisco Prime Infrastructure as a management tool for

configuring and maintaining the BYOD wireless configurations across Cisco Wireless LAN
Controllers (WLC).
This document does not cover the basic implementation of Prime Infrastructure and assumes the WLCs
are already managed by Prime Infrastructure. For further information on Prime Infrastructure
implementation, refer to the Prime Infrastructure Configuration Guide:
http://www.cisco.com/en/US/products/ps12239/products_installation_and_configuration_guides_list.h
tml.
28-1
Chapter 28

Table 28-1
Acronyms and Terminology
Key Term
Explanation
Prime
Prime refers to Cisco Prime Infrastructure in this document. The Cisco Prime Family
includes other products not covered in this document.
MSE
Mobility Services EngineCaptures and consolidates crucial information about RF

spectrum, sources of RF interference, and devices and users on the network.
wIPS
Wireless Intrusion Prevention SystemProtects the network from penetration attacks,

rogue wireless devices, and denial-of-service (DoS) attacks to improve security and
meet compliance objectives.
WSSI
Cisco Wireless Security and Spectrum Intelligence Module for the Cisco 3600 series
APs that provides always-on security scanning and spectrum intelligence, which helps
avoid RF interference. The module also allows MSE to classify security threats faster
and provide better location accuracy.
End Device
Also referred to as Endpoint. Both wired and wireless devices such as Android and
Apple tablets and smartphones, wired IP phones, and laptops.
End User
Also referred to as User. Identified by username associated to one or more end

devices.
WLC
Also referred to as Controller. Wireless LAN Controller
WLAN/SSID WLAN (Wireless LAN) and SSID have a one-to-one relation and can be thought of as
the same thing in this section.

Cisco Mobility Service Engine (MSE) is a physical or virtual appliance containing a modular set of
applications which deliver the following services.
Cisco Base Location Services

Increase visibility into the network by capturing and consolidating crucial information about RF
spectrum, sources of RF interference, and devices and users on the network. Base Location Services also
help to enable a comprehensive set of real-time location services (RTLS) and include the Mobility
Services API.
Cisco Connected Mobile Experiences

Connected Mobile Experiences (CMX) is a Wi-Fi platform that can enable organizations to deliver
customized, location-based mobile services to end users. The CMX license on the MSE includes:
CMX Connect to provide authentication and onboarding to Wi-Fi networks and a venue-specific,
location-based, mobile landing experience.
CMX Browser Engage to build and measure highly-targeted, location-based, mobile web
campaigns.
28-2
Chapter 28

CMX Analytics for onsite, online, and social analytics to help organizations gain insight into
end-user behavior while inside their venue.
Cisco Wireless Intrusion Prevention System

Wireless Intrusion Prevention System (wIPS) protects the network from penetration attacks, rogue
wireless devices, and denial-of-service (DoS) attacks to improve security and meet compliance
objectives.
WSSI
The Cisco Wireless Security and Spectrum Intelligence (WSSI) module, taking advantage of the flexible
modular design of the Cisco Aironet 3600 Series Access Point, delivers unprecedented, always-on
security scanning and spectrum intelligence, which helps you avoid RF interference so that you get better
coverage and performance on your wireless network.
The WSSI field-upgradeable module is a dedicated radio that off loads all monitoring and security
services from the client/data serving radios to the security monitor module. This not only allows for
better client experience but also reduces costs by eliminating the need for dedicated monitor mode access
points and the Ethernet infrastructure required to connect those devices into their network.
Figure 28-1
WSSI Deployment Mode
The WSSI Module supports the following features concurrently:
CleanAir technology monitoring for spectrum interference

The WSSI module has CleanAir technology built in to provide insight into the RF layer of the
wireless network. In addition CleanAir on the WSSI module provides faster proactive mitigation of
RF layer issues by continuously monitoring the Wi-Fi spectrum for interference sources. In addition
with the Cisco Mobility Services Engine, better location accuracy for interferers can be achieved.
Wireless Intrusion Prevention System (wIPS) scanning for network attacks and malicious behavior
28-3
Chapter 28
With the WSSI module coupled with Mobility Services Engine, there is enhanced level of wIPS
threat detection and mitigation. Without the WSSI module the Access Points can still mitigate and
detect wIPS threats, however, the WSSI module gives additional ability to classify security threats
faster and provide better location accuracy from where the threats are originating from.
Rogue Detection
With the WSSI module faster rogue detection and mitigation is possible.
Location Context-awareness
Because the WSSI module is constantly scanning the spectrum, location accuracy of clients is
enhanced. With higher location accuracy of client location, IT administrators can better diagnose
client connectivity issues or use the location information for better Wi-Fi capacity planning, etc.
Radio Resource Management

With constant-on technology, the WSSI module continuously feeds the Radio Resource
Management on the network and RF health, enhancing RRM functionalities. In addition because the
WSSI module is scanning the entire frequency band, it is constantly aware of various sources of
interference and non-Wi-Fi traffic that can impact Wi-Fi traffic. The RRM subsystem can use this
data for better channel planning.
CleanAir and wIPS are covered in additional detail in the following sections.
wIPS
The Cisco wIPS solution offers a flexible and scalable, 24x7x365-based full time wireless security
solution to meet each customers needs. Security is a huge factorr in todays BYOD deployments and
Cisco wIPS system is designed to meet all layer 1, 2, and 3 security challenges of a BYOD deployment.
Using a Cisco solution of a WLC, PI, and MSE with context aware location services, WIPS can locate,
mitigate, and contain attacks in campus environments. The various types of attacks that WIPS can
support are shown in Figure 28-2.
Figure 28-2
WIPS Attacks and Cisco Solution
28-4
Chapter 28

On-wire Attacks
An Access Point in wIPS-optimized mode will perform rogue threat assessment and mitigation using the
same logic as current Cisco Unified Wireless Network implementations. This allows a wIPS access point
to scan, detect, and contain rogue access points and ad hoc networks. Once discovered, this information
regarding rogue wireless devices is reported to PI where rogue alarm aggregation takes place. However
with this functionality comes the caveat that if a containment attack is launched using a wIPS mode
access point, its ability to perform methodical attack-focused channel scanning is interrupted for the
duration of the containment.
Over-the-Air Attacks
Cisco Adaptive wireless IPS embeds complete wireless threat detection and mitigation into the wireless
network infrastructure to deliver the industry's most comprehensive, accurate, and operationally
cost-effective wireless security solution.
Non-802.11 Threats
Cisco CleanAir technology is an effective tool to monitor and manage your networks RF conditions.
The Cisco MSE extends those capabilities.
For a full list of which attacks can be classified by WiPS system, see the following URL:
http://www.cisco.com/en/US/docs/wireless/technology/wips/deployment/guide/WiPS_deployment_gui
de.html
The basic system components for a Cisco Adaptive wIPS system include:
Access Points in wIPS monitor mode, in enhanced local mode, or with a wireless security and
spectrum intelligence module
Wireless LAN Controller(s)
A Mobility Services Engine running the wIPS Service
A Prime Infrastructure
An integrated wIPS deployment is a system design in which non-wIPS Mode Access Points and wIPS
Mode Access Points are intermixed on the same controller(s) and managed by the same Prime
Infrastructure. This can be any combination of local mode, FlexConnect mode, enhanced local mode,
monitor mode, and 3600 series Access points with the WSSI module. By overlaying wIPS protection and
data shares using WSSI on the Access Points, infrastructure costs can be reduced.
28-5
Chapter 28
Figure 28-3
WIPS Operation with MSE
wIPS Deployment Modes

Beginning with the 7.4 release, Cisco Adaptive Wireless IPS has three options for wIPS mode access
points. To better understand the differences between the wIPS mode access points, we discuss each
mode.
28-6
Chapter 28

Figure 28-4
WIPS Operation Modes
Enhanced Local Mode (ELM)

Enhanced local mode (ELM) provides wIPS detection on-channel, which means attackers will be
detected on the channel that is serving clients. For all other channels, ELM provides best effort wIPS
detection. This means that every frame the radio will go off-channel for a short period of time. While
off-channel, if an attack occurs while that channel is scanned, the attack will be detected.
As an example of enhanced local mode on an AP3600, assume the 2.4GHz radio is operating on channel
6. The AP will constantly monitor channel 6 and any attacks on channel 6 will be detected and reported.
If an attack occurs on channel 11 while the AP is scanning channel 11 off-channel, the attack will be
detected.
The features of ELM are:
Adds wIPS security scanning for 7x24 on- channel scanning (2.4GHz and 5 GHz), with best effort
off-channel support.
The access point is additionally serving clients and with Cisco Aironet 2nd generation (G2) Series
Access Points, CleanAir spectrum analysis is enabled on-channel (2.4GHz and 5GHz).
Adaptive wIPS scanning in the data channel serving local and FlexConnect APs.
Protection without requiring a separate overlay network.
Supports PCI compliance for the wireless LANs.
Full 802.11 and non-802.11 attack detection.
Adds forensics and reporting capabilities.
Flexibility to set integrated or dedicated MM APs.
Pre-processing at APs minimize data backhaul (that is, works over very low bandwidth links).
Low impact on the Access Point serving client data.
28-7
Chapter 28
Monitor Mode
Monitor Mode provides wIPS detection off-channel, which means the access point will dwell on each
channel for an extend period of time, allowing the AP to detect attacks on all channels. The 2.4GHz radio
will scan all 2.4GHz channels, while the 5GHz channel scans all 5GHz channels. An additional access
point would need to be installed for client access.
Some of the features of Monitor Mode are:
The Monitor Mode Access Point (MMAP) is dedicated to operate in Monitor Mode and has the
option to add wIPS security scanning of all channels (2.4GHz and 5GHz).
For Cisco Aironet second generation (G2) Series Access Points, CleanAir spectrum analysis is
enabled on all channels (2.4GHz and 5GHz).
MMAPs do not serve clients.
AP3600 with WSSI ModuleThe Evolution of Wireless Security and Spectrum

A Cisco 3600 series Access point with the WSSI module uses a combination of on-channel and
off-channel operation. This means that the AP3600 2.4GHz and 5GHz internal radios will scan the
channel that they are serving clients with and the WSSI module will additionally operate in monitor
mode and scan all channels.
Some of the features of the WSSI Module are:
The industrys first Access Point enabling the ability to simultaneously Serve clients, wIPS security
scan and analyze the spectrum using CleanAir Technology.
Dedicated 2.4GHz and 5GHz radio with its own antennas enabling 7x24 scanning of all wireless
channels in the 2.4GHz and 5GHz bands.
A single Ethernet infrastructure provides simplified operation with fewer devices to manage and
optimized return on investment of the AP3600 wireless infrastructure and the Ethernet wired
infrastructure.
Note
Additional details on deploying a WiPS solution can be found at:

http://www.cisco.com/en/US/docs/wireless/technology/wips/deployment/guide/WiPS_deployment_gui
de.html
Note
CleanAir technology is supported both on the Cisco Unified Wireless Controllers (CUWN ) and the
Converged Access platforms (Cisco 5760 wireless LAN controllers and Catalyst 3850 Series switches).
While the section below addresses CleanAir technology and CUWN WLCs, the same concepts apply to
Converged Access platforms. Readers are encouraged to look at design and deployment guides for both
CUWN controllers and Converged Access platforms for CleanAir technology.
CleanAir
Cisco CleanAir technology is the integration of Cisco Spectrum Expert Wi-Fi analysis tools with Cisco
access points. Before Cisco CleanAir, operators had to walk around with an instrument to detect signals
of interest and physically locate the device that generated them. Cisco CleanAir helps to automate these
28-8

tasks within the system management function by adding additional intelligence over Cisco Spectrum
Expert, thereby augmenting theoverall experience in proactively reclaiming control over the radio
spectrum.
The components of a basic Cisco CleanAir solution are the Cisco Wireless LAN Controller and Cisco
Aironet 2600 or 3600 Series Access Points. To take advantage of the entire set of Cisco CleanAir
features, Cisco Prime Infrastructure can display in real time the data retrieved from CleanAir. Adding
Cisco Mobility Services Engine further enhances the available features and provides the history and
location of specific interference
devices. To get full value from the information that the CleanAir system will supply, the PI and MSE
together are key to leveraging a wider efficacy of CleanAir, providing user interfaces for advanced
spectrum capabilities like historic charts, tracking interference devices, location services, and impact
analysis.
An AP equipped with Cisco CleanAir technology will collect information about non-Wi-Fi interference
sources, process it, and forward it to the Wireless LANController (WLC). The WLC is an integral core
part of the CleanAir system. The WLC controls and configures CleanAir capable Access Points (AP),
collects and processes spectrum data, and provides it to the PI and/or the MSE (Mobility Services
Engine). The WLC provides local user interfaces (GUI and CLI) to configure basic CleanAir features
and services and display current spectrum information.
The Cisco Prime Infrastructure provides advanced user interfaces for CleanAir including feature
enablement and configuration, consolidated display information, historic Air Quality records, and
reporting engines. The Cisco MSE is required for location and historic tracking of interference devices
and provides coordination and consolidation of interference reports across multiple WLCs.
In the current BYOD CVD, the Mobility Services Engine provides a way to track clients, IT devices, and
non-WiFi interference sources in addition to rogues and wIPS threats. The campus BYOD network with
the addition of MSE is shown in Figure 28-5.
Figure 28-5
MSE in Campus BYOD
Networkm Administrator
Workstation
Cisco Prime
Infrastructure (PI)
HTTP/HTTPS
I
T AP PS
RES P/HTT
TT
er H
HTTP/HTTPS
ov
SOA
r HT P/XML
TP/H
TTP
S
ove
SNMP
Cisco Mobility
Services Engine
(MSE)
W
RADIUS
Cisco Identity
Services Engine
(ISE)
N
S
Network Mobility Services

Protocol (NMSP)
CAPWAP
CAPWAP
CAPWAP
CAPWAP
CAPWAP
Cisco Access
Points (APs)
Over-the-Air
Attack Sources
Rogue APs
and Clients
Interference
Sources
WiFi Tags
WiFi Clients
294905
Chapter 28
28-9
Chapter 28
Figure 28-6 provides a high-level view of how the MSE enhances Cisco CleanAir technology.
Figure 28-6
How the MSE Enhances Cisco CleanAir Technology
Network administrator can receive alerts,
5 view location on floor plans, and/or run

reports regarding interference sources
MSE can determine the
location and provide
historic tracking of
4 interference sources,
and provide correlation
between WLCs
Interference information from CleanAir

aggregated at WLC via Interference
2 Device Reports (IDRs) and Air Quality
Index (AQI) reports generated by the
APs and sent to WLCs via CAPWAP.
N
S
Interference Device
3 Report (IDR) information

sent from WLC to MSE
CAPWAP
CAPWAP
CAPWAP
CAPWAP
Non-802.11
Interference
Source
WiFi
Clients
294906
Cisco 3600 APs with CleanAir

chipset and WSSi modules
1 scan both on and off-channel
for interference
Figure 28-6 assumes the wireless infrastructure and MSE are already installed and operational with
CAS/Basic Location Services enabled.
In Step #1 Cisco 3600 Access Points with the CleanAir chipset scan all channels for interference
sources. These interference sources could be non-802.11devices such as Bluetooth, Microwave
Ovens, Video Cameras, etc.
In Step #2 the interference information from CleanAir is aggregated at the wireless controller via
Interference Device Reports (IDRs) and Air Quality Index (AQI) reports generated by the Access
Points and sent to the wireless controller via CAPWAP. The Interference Device Reports are
generated every time a new interferer is either detected or un-detected. In addition IDR reports for
existing interferers are sent every 90 seconds to the WLC. Air Quality report on the other hand are
sent every 15 minutes to the controller and also contain important information regarding the Air
Quality index of the particular channel (or channels). The higher the AQI index, the better and
cleaner the RF channel and lower the AQI, the more clogged the RF channel.
In Step #3 the WLC aggregates Interference Device Report (IDR) from different APs into device
clusters. It is possible that several APs on the floor detect the same interference source. The WLC
aggregates IDR reports from different APs and makes an intelligent analysis of similar devices and
groups them together. The WLC forwards the information onto the MSE via the Network Mobility
Services Protocol (NMSP).
In Step #4 the MSE can then determine the location of and provide historic tracking of interference
sources. In addition in a campus environment with multiple WLCs and switches, the MSE provides
a secondary level of intelligent analysis on the interference sources and can detect the same
28-10
Chapter 28

interference sources detected by APs in the same geographical location but connected to different
controllers. The MSE to provide a system-wide view (across multiple WLCs) of interference
sources.
In Step #5 the network administrator can receive alerts, view location on floor plans, and run reports
regarding interference sources. The network administrator can also use the PI to view reports on
channel changes related to CleanAir.
In addition to providing location, interference device reports, and air quality index metrics, the CleanAir
system provides the Radio Resource Management RF metrics to mitigate non-WiFi interference threats.
This is primarily done through two featuresthe Persistent Device Avoidance Feature or the Event
Driven RRM feature. Both of them are discussed below.
Persistent Device Avoidance (PDA)

In a campus environment certain 2.4GHz/5GHz non-Wi-Fi devices are present constantly. They are not
intended to harm Wi-Fi networks, but cannot be removed from the premises either (for example,
microwave ovenswhich cause interference in the 2.4GHz frequency bandin break rooms). The
Persistent Device Avoidance feature helps RRM take into consideration these devices when channel
planning. The PDA tells the RRM system about all the devices that are consistently present at all times
(for example microwave ovens). Using this information, RRM will update channel plans to avoid putting
APs on channels near the persistent device channel in the geographical area. This helps in better
coverage and channel planning.
Event Driven RRM (ED-RRM)

Interference by nature is not predictable and also transient in nature. It is possible to have interference
sources that turn on for a short duration of time and shut off after that. Some devices like video cameras
can create havoc on Wi-Fi networks by consuming the entire channel by transmitting 100% of the time.
The ED-RRM feature helps RRM mitigate such sudden extremely strong source of RF interference.
ED-RRM identifies devices with extremely high severity on its channel and alerts the RRM system. The
RRM system uses this information to locally change the impacted APs channel to a cleaner channel
where it can continue to serve clients. If at a future time the severe interference has been located via MSE
and removed from the network, the RRM system can automatically re-plan the network to include the
impacted channel.
CleanAir can be deployed in both Local Mode and Monitor mode of the AP. Local Mode APs serve
clients while also scanning for interference sources. Monitor Mode APs do not serve any clients but
strictly act as a scanning AP not just for CleanAir but other features like wIPS, rogue detection, etc.
However having an overlay monitor mode APs for CleanAir deployment can be costly and prohibitive.
Cisco now offers the Wireless Security and Spectrum Intelligence (WSSI) module for the Cisco 3600
AP. The WSSI module provides a dedicated radio with dedicated antennas which provides continuous
scanning across all channels. Simultaneously the 3600 AP also supports data transport for clients via the
other two integrated radios within the AP.
Fore more information on configuration and management of CleanAir, see:
http://www.cisco.com/en/US/docs/solutions/Enterprise/Borderless_Networks/Smart_Business_Archite
cture/February2012/SBA_Ent_BN_WirelessCleanAirDeploymentGuide-February2012.pdf
28-11
Chapter 28
ClientLink
With bring your own device (BYOD), a proliferation of client devices has started to penetrate the
enterprise wireless landscape. The proliferation of client devices generally refers to the various types
of wireless clients accessing the network: smartphones, laptops, tablets, etc. Across these clients,
different wireless standards are used to access the wireless network: IEEE 802.11a, 802.11g, 802.11n,
and the newest standard, 802.11ac. The 802.11ac standard provides an increase in performance for
devices. The performance can be further increased if the devices support multiple antennas which allow
them to transmit and/or receive one, two, or even three spatial streams. This technology is referred to as
Multiple-Input-Multiple-Output (MIMO). However legacy 802.11a/g clients (which do not support
MIMO) often hinder the networks ability to take advantage of the additional performance gains of
802.11ac. With this mixed environment of legacy clients such as 802.11a/g and 802.11n clients with one,
two, or three spatial streams, network infrastructures must be able to support a varying combination of
different wireless standards.
Cisco ClientLink 2.0 technology specifically focuses on mixed-client networks, optimizing overall
network capacity by helping ensure that 802.11a/n and 802.11ac clients operate at the best possible rates,
especially when they are near cell boundaries. Cisco ClientLink 2.0 technology helps solve the problems
of mixed-client networks by making sure that older 802.11a/n clients operate at the best possible rates.
Cisco ClientLink 2.0 improves performance on both the uplink and the downlink, providing a better user
experience during web browsing, email, and file downloads. ClientLink 2.0 technology is based on
signal processing enhancements to the access point chipset and does not require changes to network
parameters.

Cisco Prime Infrastructure is an exciting new offering from Cisco aimed at managing wireless and wired
infrastructure while consolidating information from multiple components in one place. While allowing
management of the infrastructure, Prime Infrastructure gives a single point to discover who is on the
network, what devices they are using, where they are, and when. The capabilities of Prime Infrastructure
and the other components featured go far beyond the focus of this document. A brief overview of Cisco
Prime Infrastructure and supporting components follows.
Prime Infrastructure and Supporting Components

Cisco Prime Infrastructure interacts with many other components to be a central management and
monitoring portal. Prime Infrastructure has integration directly with two other appliance-based Cisco
products, the Cisco Mobility Services Engine and Identity Services Engine for information
consolidation. Prime Infrastructure controls, configures, and monitors all Cisco Wireless LAN
Controllers (WLCs), and by extension, all Cisco Access Points on the network. Prime Infrastructure also
configures and monitors Cisco Catalyst switches and Cisco routers.
28-12
Chapter 28

Figure 28-7
Prime Infrastructure Component Interaction Summary
ISE
MSE
Prime
Table 28-2
293112
Switch
WLC
Prime Infrastructure Components
Prime
Infrastructure
Cisco Prime Infrastructure is the core component that sends information to and
consolidates information from the other four component types.
ISE
Cisco Identity Services Engine is the core component of BYOD for user and device
authorization and access to the network. ISE provides user information to Prime
Infrastructure.
WLC
Cisco Wireless LAN Controller is configured, controlled, and monitored by Prime

Infrastructure. WLCs provide Prime Infrastructure with a wealth of real-time wireless
environment and client device information.
Switch/Router
Cisco switches and routers are configured, controlled, and monitored by Prime
Infrastructure. Wired device information is provided to Prime Infrastructure to be
consolidated with wireless device information.
MSE
Cisco Mobility Services Engine complements Prime Infrastructure with current and
historical location, usage, and other information for all devices Prime Infrastructure
sees.
The following link has more information about Cisco Prime Infrastructure and the rest of the Cisco
Prime family of products: http://www.cisco.com/go/prime.
User and Device Tracking

The ability to track users and devices on the wired and wireless networks is critical to knowing who is
accessing the network, with what they are accessing it, where are they accessing it, and when they
accessed it.
28-13
Chapter 28
Figure 28-8
Who, What, Where, and When Summary
Who
Username and other attributes of clients
What
Device MAC, IP, and Hostname
Where
Wired: switch and port device is connected to with location
information attached
Wireless: estimated physical location viewable on building
floor plan maps
Historical Access Logs showing when and where devices

and users are connecting and disconnecting
292795
When
Understanding who is accessing the corporate network, what they are using, and where they are
connected allows customers to better understand:
Location and movement of employees and devices on the network
Suspicious or unauthorized access of the network
Location of missing or stolen assets, such as in a college campus environment
Location of unknown devices on the network
Current utilization of the network
Adding historical logging of when users and devices access the network allows:
Persistent records of when users and devices accessed the network and their specific locations
Searchable historical data of user and device access for tracking and troubleshooting issues
Historical port utilization data
Components
Cisco Prime Infrastructure is the central portal for user and device tracking. Prime Infrastructure uses
information from multiple places to give a single, consolidated view of current and historical user and
device access to the network. Figure 28-9 adds to Figure 28-7 showing how the components cover the
Who, What, Where, and When aspects of user and device tracking.
28-14

Figure 28-9
Prime Infrastructure Component Interaction Summary for User and Device Tracking
What/Where
Switch
WLC
Who
ISE
MSE
When
Prime
293113
Figure 28-10 shows a more detailed view of how Prime Infrastructure interacts with the rest of the
architecture. The five main components needed for User and Device tracking of both wired and wireless
users are listed below with brief summaries of each.
Figure 28-10
Prime Infrastructure Interaction with Infrastructure Components
Access
Switch
MSE
Prime
WLC
ISE
AD
AP
293114
Chapter 28
Table 28-3
Prime Infrastructure Interaction with Other Infrastructure Components
Components
Communication
PrimeMSE
Prime receives current and historical location information for

mobile devices
PrimeISE
Prime receives user information including username and

device MAC and authentication history
PrimeSwitch/Router Prime receives wired device information including port and

MAC. Prime sends/receives component configuration.
PrimeWLC
Prime receives wireless user and extensive device information.

Prime sends/receives component configuration.
SwitchISE
RADIUS authentications
WLCISE
RADIUS authentications
28-15
Chapter 28
To locate and track users and devices, Prime Infrastructure pulls information from all of these sources,
consolidating it based mainly on common MAC. Prime Infrastructure is device focused and displays
detailed reports based on a particular device. Prime Infrastructure also has the ability to show all devices
with which a particular user accesses the network, giving the ability to track a particular user across
multiple wireless and wired devices.
Locating Users and Devices

There are two basic ways to display information on users and devices. Both options are considered
Search options, although the abilities to filter and display based on an extensive list of criteria goes
far beyond what most would consider a simple search option.
Figure 28-11
Types of Search
Context Aware Dashboard Search

Simple search of Username, MAC, or IP
Results for single end user or end device
Location focused results
Simple search of Username, MAC, or IP

Advanced Search based on extensive list of criteria
List of results for all end user and end devices that match criteria
Usage focused results
292798
Standard and Advanced Search
Context Aware Dashboard Search

Context Aware search is used to display information on a single device based on current MAC, IP, or
Username of the end user of the device. While limited in how you can search and what is displayed, this
option does give you a slightly different view of location information compared to the standard search.
The Context Aware Dashboard in Figure 28-12 has a search box titled Location Assisted Client
Troubleshooting, which is where the search is executed. The search instantly resolves the MAC, IP, or
Username to the device and display that device only.
28-16
Chapter 28

Figure 28-12
Context Aware Dashboard
The results shown in Figure 28-13 are common to both types of search and give quite a bit of current
information about the device and end user of it, if there is one.
Figure 28-13
Context Aware Search Standard Results
The information in the search results unique to the Context Aware Search is location based. Standard and
Advanced Search show Association History, which includes location, but not in the same format.
Context Aware Search results give you the ability to easily see exactly where a device was at a given time
as well as show historical motion of the device. Using the Play feature, the device location is shown
being updated on a map for a visual representation of movement, which can be accurate down to several
feet in a properly implemented wireless network.
28-17
Chapter 28
Figure 28-14 shows the location results with a blue square showing current location on the floor plan
map adjacent. Pressing Play would show the blue square moving as location references were cycled
through.
Figure 28-14
Context Aware Search Location Results
Standard and Advanced Search

In addition to searching for clients or devices using the Context Aware Dashboard, Standard and
Advanced Search may be performed in the top right corner of the Prime Infrastructure interface, visible
at any time. Much more granular searches may be performed using the Advanced Search option shown
in Figure 28-15. Search results are more device usage focused with the Standard and Advanced Search,
but still contain location information.
Figure 28-15
Standard and Advanced Search Box
With Advanced Search, results for many end users or end devices that meet a particular set of criteria
may be displayed instead of looking for one particular user or device. Parameters such as physical
location, type of user, SSID, and even posture/authentication status may be used. Figure 28-16 shows a
subset of criteria available.
28-18
Chapter 28

Figure 28-16
Advanced Search Criteria
The form above is dynamic, changing as selections are made, which means this image shows only a
subset of the criteria available for the Clients category, which in this case refers to both end devices
and end users.
Additional search criteria and information may be found in the Cisco Prime Infrastructure Configuration
Guide:
tml.
Figure 28-17 shows the search results list, which contains both wired and wireless users unless one type
is filtered out. In this example two devices are shown, the first a wireless device and the second wired.
Figure 28-17
Standard and Advanced Search Results List
An extensive amount of information is available from just the search results screen. The result columns
may be customized and results list sorted by any of those columns. Figure 28-18 shows a list of available
columns.
28-19
Chapter 28
Figure 28-18
Search Results Columns
Figure 28-19 through Figure 28-24 show examples of basic and extended information shown for
individual devices selected from the search list.
Figure 28-19 shows the same basic end user and end device information as the Context Aware Search
discussed earlier.
28-20
Chapter 28

Figure 28-19
General User and Device Details
Figure 28-20 shows association times, durations, and locations, which is similar but not the same as the
location history with the Context Aware Search.
Figure 28-20
Device Association History
Figure 28-21 is pulled directly from ISE and shows recent authentication successes and failures.
28-21
Chapter 28
Figure 28-21
Device Authentication History
Figure 28-22 shows signal quality for various, changeable time frames in graph format.
28-22
Chapter 28

Figure 28-22
Device Signal Quality and Usage History
28-23
Chapter 28
Figure 28-23 shows the device in its current location, along with any additional information chosen. In
this example, only heat map and AP location is selected, but many other items are available for display,
such as interfering devices and other clients.
Figure 28-23
Floor Plan Heat Map with APs and Client Device
Figure 28-24 shows details of any device shown on the heat map.
Figure 28-24
Device Detail Pop-up from Heat Map
Interference and IntrusionDetection and Location

Through the Cisco Prime Infrastructure (PI) interface, interference sources and attackers can be easily
identified and located. Prime Infrastructure works with Cisco Mobility Services Engine (MSE) to
retrieve, consolidate, and provide useable interferer and attacker device detail and location data.
28-24
Chapter 28

Interference Detection and Location

Cisco Mobility Services Engine (MSE) processes data from multiple components to locate and track
interference sources. Cisco Prime Infrastructure (PI) displays interference device history and location
information from MSE including graphical representation on floor maps to show precise location.
Locating interference sources is critical to both optimal wireless performance and network security.
Interference sources range from non-wifi devices that create noise in frequencies used by the corporate
wifi network, to non-corporate wifi devices that may both reduce corporate wifi performance as well as
be a security risk. A rogue AP, for example, is both a security risk as well as a possible source of
performance degradation for the corporate wifi network.
Figure 28-25 is the Interferer display filter showing all interferer types displayed by Prime
Infrastructure. The default is to show all interferers.
Figure 28-25
Prime Infrastructure Interferer Display Filter
Figure 28-26 is an example of a floor map with three types of possible interferers detected and displayed.
Displayed are two non-wifi devices, a WiMAX and Bluetooth device depicted by small lightning bolts.
A Rogue AP, which is classified separately within Prime Infrastructure, is also shown as the skull and
crossbones on the map.
28-25
Chapter 28
Figure 28-26
Prime Infrastructure Interference Device View
Selecting interference devices on the map displays summary information about the device. Figure 28-27
and Figure 28-28 shown an example of the summary information provided when selecting the WiMAX
device and Rogue AP shown above.
Figure 28-27
WiMAX Device Summary Information
28-26
Chapter 28

Figure 28-28
Rogue AP Summary Information
Detailed information may then be accessed via the Details link within the summary display.
wIPS Intrusion Detection and Location

Cisco Mobility Services Engine (MSE) processes wIPS data from the wireless controllers to locate and
track malicious intrusion attacks. Before the MSE has access to this information, wIPS monitoring must
be enabled in the wireless network. The use of Cisco 3600 series APs with WSSI modules installed
greatly enhances wIPS monitoring capability. Information regarding WSSI modules and the types of
wIPS implementations is detailed earlier in this chapter.
Cisco Prime Infrastructure displays wIPS intrusion location and history information from MSE
including graphical representation on floor maps to show precise locations. In addition to detecting and
location malicious attacks, Prime Infrastructure provides information about possible security issues
detected throughout the network. Figure 28-29 is an example of portions of the Security Overview screen
in Prime Infrastructure.
28-27
Chapter 28
Figure 28-29
Security OverviewTop Security Isssues
28-28
Chapter 28

Figure 28-30
Security OverviewwIPS Attacks
Specific wIPS attack information summarized in Figure 28-30 may be selected for more detail. wIPS
attacks may be viewed on a floor map, providing the physical location of the attacker based on
triangulated data from the APs. Figure 28-31 shows an individual attack detected and located by MSE.
28-29
Chapter 28
Figure 28-31
Prime Infrastructure wIPS Attack View
wIPS attack details may be accessed directly from the floor map by selecting the attack icon, displaying
the summary as shown in Figure 28-31. Detailed information of the attack may then be accessed via the
wIPS Attack Details link within the summary display. An example of detailed attack information is
28-30
Chapter 28

Figure 28-32
Detailed Attack Information
This detailed information is accessible via attack and alarm reporting as well, allowing linking back into
the floor maps from the attack details to show precise location. Various types of notifications, such as
auto generated email, may be enabled to allow immediate notification of specific types of attacks within
the network.
Template-Based Configuration
This section covers the use of Cisco Prime Infrastructure to deploy and maintain configurations to Cisco
Wireless LAN Controllers (WLCs) matching the BYOD configurations referenced in this document.
Cisco Prime Infrastructure has the ability to control configuration of Cisco Wireless LAN Controllers
(WLCs) directly or through the use of templates. One template will not configure the entire controller.
Templates are separated out to granularly cover each feature of the controller. Templates exist for just
about every small feature that can be implemented on the controllers and many portions of the templates
can be modified during deployment to accommodate unique settings in WLCs. Templates can be
configured for a common configuration across all WLCs as well as be implemented across a sub-set of
WLCs or individual WLCs.
Note
Each WLAN has exactly one SSID and the two terms may be thought of as being the same thing for
simplicity in understanding this content: WLAN = SSID.
28-31
Chapter 28
Template-based configuration has a number of advantages compared to individual configuration of

WLCs:
Consistent Configuration of WLCs
Multiple Templates for Variations of Deployment
Rapid Deployment of New or Replacement Components
Staged Rollout of Configuration Changes with Rapid Rollback
Consistent Configuration of WLCs

Inconsistencies in configuration can easily occur when configuring multiple WLCs through their local
web-based administrative interfaces. Inconsistencies can have far reaching negative impact on WLAN
functionality, security, and performance.
Inconsistencies in even the order of configuration can sometimes have serious impacts. For example,
configuring multiple WLANs in different orders on different controllers will cause the WLAN IDs (an
integer that uniquely identifies each WLAN) to be inconsistent. WLAN IDs are used by ISE to determine
how the client should be treated. Inconsistent WLAN IDs may result in a client attaching to a particular
SSID and being assigned access as if they were attached to a different SSID.
One important note here, however, is that Prime Infrastructure will have the controller auto-assign the
WLAN ID. If the base configuration of the controllers starts in an inconsistent state, such as a WLAN
existing on one controller that does not exist on another, the WLAN IDs will be set inconsistently when
applied from Prime Infrastructure. Checks should be done to ensure the WLAN IDs are consistent across
all controllers.
Multiple Templates for Variations of Deployment

Variations in deployment may be required for some features of WLCs based on model or location in the
network. If a WLC is being used for dedicated guest access, its configuration for certain features would
differ from other WLCs on the network, requiring some variation of templates.
Prime Infrastructure supports multiple templates for the same feature, allowing templates to be created
with variation for WLCs. Templates may be applied to all WLCs or individually selected WLCs at the
time of application.
Rapid Deployment of New or Replacement Components

By creating templates for WLC configuration, new and replacement WLCs may be rapidly configured
from the latest templates, reducing time to deploy and eliminating errors from misconfigurations.
Staged Rollout of Configuration Changes with Rapid Rollback

Multiple templates for a specific feature can be created allowing an altered configuration to co-exist with
the current configuration in template form. The new configuration template can then be tested on one or
more WLCs with ease of rollback to the previous configuration template should issues arise.
28-32
Chapter 28

Note
The acronym WLC (Wireless LAN Controller) is frequently used in this document while some of the
interfaces shown use the common term Controller. In this document WLC and Controller refer to
the same thing: WLC = Controller.
Template Creation and Implementation

Template creation and implementation is a fairly straightforward process in Prime Infrastructure with a
few caveats. The templates and configurations that follow are specific to the BYOD solution in this
document and are but a tiny subset of the many settings and features that are needed for implementing
an enterprise wireless network.
This section assumes the WLCs are already managed by Prime Infrastructure. For further information
on Prime Infrastructure implementation, refer to the Prime Infrastructure Configuration Guide:
tml.
Template Creation
Template creation for WLC configuration may be handled in one of three ways:
1.
Create new templates directly in Prime Infrastructure.
2.
Configure a WLC through Prime Infrastructure and then create templates from that configuration.
3.
Configure a WLC through the local WLC web interface and then create templates from that
configuration.
The following material focuses on option 2, configuring a WLC through Prime Infrastructure followed
by creation of templates to configure additional WLCs and make changes to the original WLC. This
approach would seem the most logical since it incorporates option 3 as well if the WLC were already
configured.
This approach would also be appealing to someone wanting to learn the interface and operation of Prime
Infrastructure and the WLC at the same time, using a separate WLC to create the configurations and
templates to be deployed in production at a future date. For base template creation, functional trials, and
understanding of the solution, most of the features covered in this document may be deployed using a
relatively inexpensive Cisco 2504 with the base license and a single AP. Two key features the 2504 lacks
as part of the BYOD solution are the ability to act as a DMZ Guest WLC and the ability to rate limit
traffic. Both of those features are covered in Chapter 21, BYOD Guest Wireless Access. All other
features and abilities in the BYOD solution are supported on this platform.
Due to the extensiveness of configuration for a FlexConnect environment, not every step is shown for
the initial configuration. Using the Prime Infrastructure interface instead of the WLC interface directly
should be fairly straightforward. Minor differences in location of options and features in the Prime
Infrastructure interface are shown.
Using option 2 from above (Configure a WLC through Prime Infrastructure and then create templates
from that configuration) the following steps are used. If beginning with a WLC that was directly
configured, just skip steps 1 and 3.
Step 1Configure Base Network Connectivity on the New WLC
Step 2Add the WLC as a Managed Device to Prime Infrastructure
Step 3Using Prime Infrastructure, Directly Configure the WLC
28-33
Chapter 28
Step 4Create Templates from the Configured WLC
Step 5Deploy Templates on One or More WLCs
Step 1Configure Base Network Connectivity on the New WLC
This step should be completed with documentation for the WLC you are implementing. Documentation
for all Cisco WLCs can be found at:
http://www.cisco.com/web/tsweb/redirects/mm/support/wireless.html.
Step 2Add the WLC as a Managed Device to Prime Infrastructure
In Prime Infrastructure, use the Device Work Center and manually add the device, as shown in
Figure 28-33.
Figure 28-33
Device Work CenterAdd a Device
You do not need to specify the WLC type as Prime Infrastructure will determine it during the
synchronization process. Alternatively, the WLC may be added through the discovery process, which is
not shown.
After the WLC is added it will synchronize any existing configuration with Prime Infrastructure. This
process should take only a couple of minutes and show a Device Status of Managed in the Device Work
Center. It will also be placed in the appropriate Device Type folder, which can be expanded on the left
side of the Device Work Center screen shown in Figure 28-33.
28-34
Chapter 28

Step 3Using Prime Infrastructure, Directly Configure the WLC
The WLC may now be directly configured in the Device Work Center, similar to being on the web-based
interface of the WLC itself, by selecting the WLC and then the Configuration tab in the section below.
The configuration interface is very similar, but not exactly the same. Figure 28-34 shows how the WLC
interface main categories map to the Prime Infrastructure categories.
Figure 28-34
Mapping of WLC Interface Categories to Prime Infrastructure Categories
Be aware that one significant feature, AAA Override, is in a different location.

The feature AAA Override is shown in the Advanced tab of the WLAN settings when configuring
through the WLC interface. This same feature is in the Security tab of the WLAN settings when
configuring through Prime Infrastructure, as shown in Figure 28-35.
28-35
Chapter 28
Figure 28-35
AAA Override on Advanced Tab of WLAN Settings
Take note of the WLAN ID caveat at the end of this section as it is important to both the creation of
WLANs initially as well as template-based deployment of WLANs.
Step 4Create Templates from the Configured WLC
Creating templates from a configured WLC is a fairly simple process. An automated process creates
templates of everything in the WLC that can have a template created. To accomplish this, go to the device
in Device Work Center, the same place as the last step. Select the configured WLC and choose
Configure and then Discover Templates from Controller, as shown in Figure 28-36.
Figure 28-36
Discover Templates from Controller
After the template discovery process completes, the templates are found in the Configuration
Templates section in the Design section from the top menu, as shown in Figure 28-37.
Figure 28-37
Configuration Templates
28-36
Chapter 28

The newly discovered templates will be shown under My Templates, then Discovered Templates as
Figure 28-38
Discovered Templates
There will be many templates shown in this section, but only a small number of them are really needed.
Before any customization or deployment of templates occurs, it is highly recommended to organize the
needed templates into a custom folder. First, create a new folder by placing the mouse pointer next to
My Templates, which pops up a box. Click Add Folder, as shown in Figure 28-39.
Figure 28-39
Add Folder
After creating the folder, in this case named BYOD Templates, place the pointer next to each of the
desired templates, one at a time, and click Move to Folder, moving them to the newly created folder, as
shown in .
28-37
Chapter 28
Figure 28-40
Moving Templates
Once complete, all the desired templates will show up in the new folder, ready for editing and
deployment, as shown in Figure 28-41.
Figure 28-41
BYOD Templates
Step 5Deploy Templates on One or More WLCs
It is fairly straightforward to deploy standard templates with no unique settings. Deploying templates
that require unique configurations, such as FlexConnect Groups, is more involved.
A FlexConnect Group has specific APs associated with it, which will be different from WLC to WLC.
A simple static template would not be particularly useful and the deployment must accommodate
customization. The following template deployment is of a FlexConnect Group, showing the most
complex type of deployment as an example.
At the bottom of every template is a button to deploy it, shown in Figure 28-42, which when clicked
shows the deployment screen.
28-38
Chapter 28

Figure 28-42
Deploy Button
When a FlexConnect Group template is launched, the target WLCs must be chosen. In this example two
WLCs of different types are selected, as shown in Figure 28-43.
Figure 28-43
Deployment Screen
When selected, you see the Value Assignment screen, shown in Figure 28-44. This section allows you
to assign values and resources to each WLC independently. In this example APs may be added to the
FlexConnect Group separately for each WLC. The APs are added by clicking Add AP on the far right
of the screen (not shown) which will bring up a list of all APs that are visible to Prime Infrastructure.
Figure 28-44
Value Assignment
After completion of customization, the template can be deployed immediately or scheduled.

Caveat 1WLAN ID
WLAN ID is used by ISE in determining what SSID (WLAN) clients are using to connect to the network.
This ID is unique to each WLAN on each controller, so ensuring each WLAN has the same WLAN ID
on each controller is essential for proper operation and security.
Ensuring this can become complex for large enterprise customers with multiple WLCs. Take note of the
following:
Prime Infrastructure cannot set the WLAN ID and lets the WLC assign the WLAN ID.
WLCs with existing WLANs increment to the next available integer.
Creating a WLAN using the WLC web interface directly allows the WLAN ID to be chosen.
WLAN IDs cannot be changed once the WLAN is created.
28-39
Chapter 28
The following simple example shows the issue:
WLC A has no WLANs defined.
WLC B has WLAN Special-SSID with WLAN ID 1.
Using Prime Infrastructure to create a new WLAN, Employee-SSID, across all WLCs results in it
being assigned WLAN ID 1 on WLC A and WLAN ID 2 on WLC B.
WLC A
WLAN Employee-SSID WLAN ID 1
WLC B
WLAN Special-SSID WLAN ID 1
WLAN Employee-SSID WLAN ID 2
To avoid this potentially serious mismatch, it is essential to audit existing WLCs for WLANs and prepare
the WLCs for template-based WLAN configuration. Using only Prime Infrastructure and not the WLC
interface, the following summarized steps (followed by detailed steps) prevent WLAN ID
inconsistencies.
Detailed Steps for Ensuring WLAN ID Consistency

1.
Add all WLCs to Prime Infrastructure and synchronize their configurations.
2.
Using Prime Infrastructure, look at the WLANs on each WLC to determine the highest WLAN ID
in existence, as shown in the example in Figure 28-45. In this example, two WLANs exist on a
particular WLC.
Figure 28-45
3.
WLAN ID List
Create disabled dummy WLAN templates and apply to WLCs to bring them all up to the same
highest WLAN ID.
The dummy WLAN settings are irrelevant as long as they are created in the disabled state. In this
example, two dummy WLAN templates must be created and applied to all WLCs with no WLANs.
As an alternative to creating the dummy WLANs, the existing WLANs may be deleted and
re-created with higher WLAN IDs manually set directly on the WLC. Deletion and re-creation is the
only method currently available for changing the WLAN ID. Changing the WLAN ID on an existing
WLAN is not possible.
28-40
Chapter 28

Note
4.
Create the new WLAN templates for BYOD configurations and apply to all WLCs.
5.
Check WLCs to ensure WLAN IDs are consistently assigned across all WLCs.
6.
After WLAN templates are applied, dummy WLANs may be deleted if desired.
When adding a new WLC to the network, dummy WLAN templates must be applied to them before
applying BYOD WLAN templates. Since the WLAN ID is assigned sequentially, BYOD WLAN
templates must always be applied in the same order.
28-41
Chapter 28
28-42
PART
Appendices
A P P E N D I X

Whats New: The configurations have been updated to add the QoS configurations discussed in
Converged Access QoS in Chapter 7, Application Considerations and License Requirements for
BYOD and to add the application visibility configurations discussed in Converged Access Application
Visibility in Chapter 24, Mobile Traffic Engineering with Application Visibility and Control (AVC).
The Converged Access Campus consists of CT5760 as the Mobility Controller (MC) and the Catalyst
3850 as the Mobility Agent (MA).
An example configuration of a CT5760 in a campus design acting as a MC is shown below. The QoS
model shown below assumes a 2P4Q4T queueing model for the wired uplink port, an upstream client
QoS policy which shows remarking only, and a static assignment of the upstream client QoS policy.
aaa new-model
!
!
!
!
!
!
!
!
ip device tracking
!
!
!
!
!
default 0
!
A-1
Appendix A
!
permit any any
spanning-tree mode pvst
spanning-tree extend system-id
!
!
class-map match-any REALTIME-QUEUE
match dscp ef
class-map match-any NETWORK-CONTROL-QUEUE
match dscp cs6
class-map match-any SIGNALING-QUEUE
match dscp cs3
match dscp af21
match dscp af22
match dscp af23
match dscp cs1
match dscp af41
match dscp af42
match dscp af43
match dscp ef
match dscp cs6
match dscp cs3
class-map match-any INTERACTIVE-VIDEO-QUEUE
match dscp af41
match dscp af42
match dscp af43
match dscp af11
match dscp af12
match dscp af13
match dscp ef
match access-group name VOICE
class-map match-any non-client-nrt-class
match non-client-nrt
match dscp cs3
match dscp cs6
!
class RT1
priority level 1
police rate percent 10 conform-action transmit exceed-action drop
class RT2
priority level 2
class class-default
A-2
Appendix A


policy-map REALTIME-DOWNSTREAM-CHILD
class RT1
priority level 1
police 15000000
conform-action transmit exceed-action drop
class RT2
priority level 2
police 30000000
exceed-action drop
class class-default
policy-map EMPLOYEE-DOWNSTREAM
class class-default
service-policy REALTIME-DOWNSTREAM-CHILD
class VOICE
set dscp ef
class SIGNALING
set dscp cs3
set dscp af41
set dscp af21
class BULK-DATA
set dscp af11
class SCAVENGER
set dscp cs1
class class-default
set dscp default
class class-default
class class-default
set dscp default
policy-map REALTIME-DOWNSTREAM-CHILD-PERSONAL
class RT1
priority level 1
police 4500000
exceed-action drop
class RT2
priority level 2
police 9000000
exceed-action drop
class class-default
class class-default
service-policy REALTIME-DOWNSTREAM-CHILD-PERSONAL
class class-default
class class-default
policy-map 2P6Q3T
priority level 1
A-3
Appendix A
priority level 2
queue-buffers ratio 10 class BULK-DATA-QUEUE
class class-default
!
!
!interface Vlan2
ip address 10.231.2.7 255.255.255.0
load-interval 30
!
interface Vlan3
ip address 10.231.3.7 255.255.255.0
load-interval 30
!
interface Vlan47
description ### Mgmt Vlan ###
ip address 10.225.47.2 255.255.255.0
load-interval 30
!
!
ip http server
!
ip access-list extended ACL_BLACKHOLE
!
deny
deny
deny
ip any host 10.225.49.15
permit ip any any
!
permit ip any any
!
A-4
Appendix A


permit ip any 63.128.76.0 0.0.0.255
permit ip any 23.0.0.0 0.255.255.255
permit ip any 17.0.0.0 0.255.255.255
permit ip any 184.0.0.0 0.255.255.255
permit ip any 8.0.0.0 0.255.255.255
permit ip any 74.125.0.0 0.0.255.255
permit ip any 173.194.0.0 0.0.255.255
permit ip any 206.111.0.0 0.0.255.255
permit ip any 173.223.0.0 0.0.255.255
deny
ip any any
deny
deny
ip any host 10.230.1.45
deny
ip any host 10.225.49.15
deny
ip any host 10.230.1.76
deny
ip any 63.128.76.0 0.0.0.255
deny
ip any 23.0.0.0 0.255.255.255
deny
ip any 17.0.0.0 0.255.255.255
deny
ip any 184.0.0.0 0.255.255.255
deny
ip any 8.0.0.0 0.255.255.255
deny
ip any 74.125.0.0 0.0.255.255
deny
ip any 173.194.0.0 0.0.255.255
deny
ip any 206.111.0.0 0.0.255.255
deny
ip any host 10.225.100.10
deny
ip any 173.223.0.0 0.0.255.255
permit ip any any
permit ip any 63.128.76.0 0.0.0.255
deny
ip any 10.0.0.0 0.255.255.255
deny
ip any 10.0.0.0 0.255.255.255
deny
ip any 172.16.0.0 0.15.255.255
deny
ip any 192.168.0.0 0.0.255.255
permit ip any any
deny
ip any host 10.230.1.45
deny
ip any host 10.225.49.15
deny
ip any host 10.230.1.76
deny
ip any 63.128.76.0 0.0.0.255
deny
ip any host 10.225.100.10
permit ip any 10.0.0.0 0.255.255.255
permit ip any 10.0.0.0 0.255.255.255
permit ip any 172.16.0.0 0.15.255.255
permit ip any 192.168.0.0 0.0.255.255
deny
ip any any
permit ip any 10.230.4.0 0.0.0.255
deny
ip any 10.230.0.0 0.0.255.255
deny
ip any 10.225.0.0 0.0.255.255
deny
ip any 10.200.0.0 0.0.255.255
permit ip any any
A-5
Appendix A
ip access-list extended ACL_Provisioning

permit ip any 74.125.0.0 0.0.255.255
permit ip any 173.194.0.0 0.0.255.255
permit ip any 206.111.0.0 0.0.255.255
deny
deny
deny
ip any host 10.225.49.15
deny
ip any 74.125.0.0 0.0.255.255
deny
ip any 173.194.0.0 0.0.255.255
deny
ip any 206.111.0.0 0.0.255.255
ip access-list extended BLACKHOLE_ACL
!
!
!
remark SCCP
remark SIP
!
remark HTTPS
remark CITRIX
remark ORACLE
!
remark FTP
permit tcp any any eq ftp
permit tcp any any eq ftp-data
remark SSH/SFTP
remark SMTP/SECURE SMTP
permit tcp any any eq smtp
remark IMAP/SECURE IMAP
remark POP3/SECURE POP3
A-6
Appendix A

permit tcp any any eq pop3

remark CONNECTED PC BACKUP
permit tcp any eq 1914 any
!
remark BITTORRENT
!
radius-server host 10.225.49.15 auth-port 1812 acct-port 1813 key 7 1237161E060E5D56797F71
!
wireless mobility controller peer-group 100 bridge-domain-id 1
wireless exclusionlist 1CB0.9414.9077 description gregg
aaa-override
nac
service-policy output EMPLOYEE-DOWNSTREAM
no shutdown
aaa-override
no security wpa
security web-auth
A-7
Appendix A
no shutdown
aaa-override
nac
no security wpa
no shutdown
no shutdown
aaa-override
nac
no security wpa
no shutdown
An example configuration of Converged Access Catalyst 3850 in a campus design acting as a Mobility
Agent is shown below:
aaa new-model
!
!
!
!
!
!
client 10.225.49.15 server-key 7 0525150635491F5B4A5142
auth-type any
!
!
ip device tracking
!
!
!
!
A-8
Appendix A

!
default 0
!
permit any any
spanning-tree mode pvst
spanning-tree extend system-id
!
vlan 57
name Employee
!
vlan 58
name Provisioning
!
vlan 59-60
!
vlan 61
name Access_Point
!
vlan 777
name Guest
!
!
!
!
match dscp ef
match dscp cs6
match dscp cs3
match dscp af21
match dscp af22
match dscp af23
match dscp cs1
match dscp af41
match dscp af42
match dscp af43
match dscp ef
match dscp cs6
match dscp cs3
match dscp af41
match dscp af42
match dscp af43
match dscp af11
match dscp af12
match dscp af13
!
match dscp ef
A-9
Appendix A

match dscp cs3
match dscp cs6
!
!
class RT1
priority level 1
class RT2
priority level 2
class class-default
class RT1
priority level 1
police 15000000
conform-action transmit exceed-action drop
class RT2
priority level 2
police 30000000
exceed-action drop
class class-default
class class-default
class VOICE
set dscp ef
class SIGNALING
set dscp cs3
set dscp af41
set dscp af21
class BULK-DATA
set dscp af11
class SCAVENGER
set dscp cs1
class class-default
set dscp default
class class-default
class class-default
set dscp default
class RT1
priority level 1
police 4500000
exceed-action drop
class RT2
priority level 2
A-10
Appendix A

police 9000000
exceed-action drop
class class-default
class class-default
class class-default
class class-default
policy-map 2P6Q3T
priority level 1
priority level 2
class class-default
!
!
!
!
mab
A-11
Appendix A

!
!
interface Vlan61
ip address 10.207.61.5 255.255.255.0
!
ip http server
ip http active-session-modules none
!
ip access-list extended ACL-DEFAULT
permit udp any any eq domain
permit icmp any any
permit udp any any eq tftp
deny
ip any any log
deny
deny
deny
ip any host 10.225.49.15
permit ip any any
permit ip any any
permit ip any 63.128.76.0 0.0.0.255
permit ip any 23.0.0.0 0.255.255.255
permit ip any 17.0.0.0 0.255.255.255
permit ip any 184.0.0.0 0.255.255.255
permit ip any 8.0.0.0 0.255.255.255
permit ip any 74.125.0.0 0.0.255.255
permit ip any 173.194.0.0 0.0.255.255
permit ip any 206.111.0.0 0.0.255.255
deny
ip any any
deny
deny
ip any host 10.230.1.45
deny
ip any host 10.225.49.15
deny
ip any host 10.230.1.76
deny
ip any 63.128.76.0 0.0.0.255
deny
ip any 23.0.0.0 0.255.255.255
deny
ip any 17.0.0.0 0.255.255.255
deny
ip any 184.0.0.0 0.255.255.255
deny
ip any 8.0.0.0 0.255.255.255
deny
ip any 74.125.0.0 0.0.255.255
deny
ip any 173.194.0.0 0.0.255.255
deny
ip any 206.111.0.0 0.0.255.255
deny
ip any host 10.225.100.10
permit ip any any
A-12
Appendix A


permit ip any 63.128.76.0 0.0.0.255
deny
ip any 10.0.0.0 0.255.255.255
deny
ip any 10.0.0.0 0.255.255.255
deny
ip any 172.16.0.0 0.15.255.255
deny
ip any 192.168.0.0 0.0.255.255
permit ip any any
deny
deny
ip any host 10.230.1.45
deny
ip any host 10.225.49.15
deny
ip any host 10.230.1.76
deny
ip any 63.128.76.0 0.0.0.255
deny
ip any host 10.225.100.10
permit ip any 10.0.0.0 0.255.255.255
permit ip any 10.0.0.0 0.255.255.255
permit ip any 172.16.0.0 0.15.255.255
permit ip any 192.168.0.0 0.0.255.255
deny
ip any any
permit ip any 10.230.4.0 0.0.0.255
deny
ip any 10.230.0.0 0.0.255.255
deny
ip any 10.225.0.0 0.0.255.255
deny
ip any 10.200.0.0 0.0.255.255
permit ip any any
permit ip any 74.125.0.0 0.0.255.255
permit ip any 173.194.0.0 0.0.255.255
permit ip any 206.111.0.0 0.0.255.255
deny
deny
deny
ip any host 10.225.49.15
deny
ip any 74.125.0.0 0.0.255.255
deny
ip any 173.194.0.0 0.0.255.255
deny
ip any 206.111.0.0 0.0.255.255
!
!
!
remark SCCP
remark SIP
A-13
Appendix A
!
remark HTTPS
remark CITRIX
remark ORACLE
!
remark FTP
remark SSH/SFTP
!
remark BITTORRENT
!
!
ip radius source-interface Vlan61
logging 10.230.1.83
!
!
radius-server host 10.225.49.15 auth-port 1812 acct-port 1813 key 7 153C1805102F7A767B6760
!
!
wireless mobility controller ip 10.225.47.2 public-ip 10.225.47.2
wireless broadcast
wireless multicast
A-14
Appendix A

wireless mgmt-via-wireless
aaa-override
nac
session-timeout 300
no shutdown
aaa-override
client vlan Guest
no security wpa
security web-auth
no shutdown
aaa-override
nac
no security wpa
no shutdown
client vlan Guest
no shutdown
aaa-override
nac
no security wpa
no shutdown
A-15
Appendix A
An example configuration of a Converged Access Catalyst 3850 in a branch design is shown below. Note
that in a branch design, the Catalyst 3850 acts both as a Mobility Controller (MC) and a Mobility Agent
(MA) in a single switch. The configuration also shows the AVC configuration.
aaa new-model
!
!
!
!
!
!
auth-type any
!
switch 1 provision ws-c3850-24p
!
ip device tracking
!
!
!
!
permit any any
!
flow record rodrec_av1
description IPv4flow
match ipv4 protocol
match ipv4 source address
match ipv4 destination address
match transport source-port
match transport destination-port
match flow direction
match application name
match wireless ssid
collect counter bytes long
collect counter packets long
collect wireless ap mac address
collect wireless client mac address
!
!
!
flow monitor rodmon_av1
cache timeout inactive 200
record rodrec_av1
!
!
default 0
!
vlan 10
name BYOD-Employee
!
A-16
Appendix A

vlan 11
name BYOD-Provisioning
!
vlan 17
name AP_Management
!
vlan 18
!
vlan 777
name BYOD_Guest
!
match dscp ef
match dscp cs6
match dscp cs3
match dscp af21
match dscp af22
match dscp af23
match dscp cs1
match dscp af41
match dscp af42
match dscp af43
match dscp ef
match dscp cs3
match dscp cs6
match dscp af41
match dscp af42
match dscp af43
match dscp af11
match dscp af12
match dscp af13
match dscp ef
match dscp cs3
match dscp cs6
!
class RT1
priority level 1
A-17
Appendix A
class RT2
priority level 2
class class-default
class RT1
priority level 1
police cir 15000000 conform-action transmit exceed-action drop
class RT2
priority level 2
class class-default
class class-default
class VOICE
set dscp ef
class SIGNALING
set dscp cs3
set dscp af41
set dscp af21
class BULK-DATA
set dscp af11
class SCAVENGER
set dscp cs1
class class-default
set dscp default
class class-default
class class-default
set dscp default
class RT1
priority level 1
police 4500000
exceed-action drop
class RT2
priority level 2
police 9000000
exceed-action drop
class class-default
class class-default
class class-default
class class-default
policy-map 2P6Q3T
A-18
Appendix A

priority level 1
priority level 2
class class-default
!
!
!
mab
!
...
....
!
!
!
interface Vlan17
ip address 10.200.17.5 255.255.255.0
!
ip http server
!
ip access-list extended ACL-DEFAULT
A-19
Appendix A

permit udp any any eq domain
permit icmp any any
permit udp any any eq tftp
deny
ip any any
deny
deny
deny
ip any host 10.225.49.15
permit ip any any
permit ip any any
permit ip any 63.128.76.0 0.0.0.255
permit ip any 23.0.0.0 0.255.255.255
permit ip any 17.0.0.0 0.255.255.255
permit ip any 184.0.0.0 0.255.255.255
permit ip any 8.0.0.0 0.255.255.255
permit ip any 74.125.0.0 0.0.255.255
permit ip any 173.194.0.0 0.0.255.255
permit ip any 206.111.0.0 0.0.255.255
permit ip any 173.223.0.0 0.0.255.255
deny
ip any any
deny
deny
ip any host 10.230.1.45
deny
ip any host 10.225.49.15
deny
ip any host 10.230.1.76
deny
ip any 63.128.76.0 0.0.0.255
deny
ip any 23.0.0.0 0.255.255.255
deny
ip any 17.0.0.0 0.255.255.255
deny
ip any 184.0.0.0 0.255.255.255
deny
ip any 8.0.0.0 0.255.255.255
deny
ip any 74.125.0.0 0.0.255.255
deny
ip any 173.194.0.0 0.0.255.255
deny
ip any 206.111.0.0 0.0.255.255
deny
ip any host 10.225.100.10
deny
ip any 173.223.0.0 0.0.255.255
permit ip any any
permit ip any 63.128.76.0 0.0.0.255
deny
ip any 10.0.0.0 0.255.255.255
deny
ip any 10.0.0.0 0.255.255.255
deny
ip any 172.16.0.0 0.15.255.255
deny
ip any 192.168.0.0 0.0.255.255
permit ip any any
deny
ip any host 10.230.1.45
deny
ip any host 10.225.49.15
deny
ip any host 10.230.1.76
deny
ip any 63.128.76.0 0.0.0.255
A-20
Appendix A

deny
ip any host 10.225.100.10
permit ip any 10.0.0.0 0.255.255.255
permit ip any 10.0.0.0 0.255.255.255
permit ip any 172.16.0.0 0.15.255.255
permit ip any 192.168.0.0 0.0.255.255
deny
ip any any
permit ip any 10.230.4.0 0.0.0.255
deny
ip any 10.230.0.0 0.0.255.255
deny
ip any 10.225.0.0 0.0.255.255
deny
ip any 10.200.0.0 0.0.255.255
permit ip any any
permit ip any 74.125.0.0 0.0.255.255
permit ip any 173.194.0.0 0.0.255.255
permit ip any 206.111.0.0 0.0.255.255
deny
deny
deny
ip any host 10.225.49.15
deny
ip any 74.125.0.0 0.0.255.255
deny
ip any 173.194.0.0 0.0.255.255
deny
ip any 206.111.0.0 0.0.255.255
ip access-list extended BLACKHOLE_ACL
!
!
!
remark SCCP
remark SIP
!
remark HTTPS
remark CITRIX
remark ORACLE
A-21
Appendix A

!
remark FTP
remark SSH/SFTP
!
remark BITTORRENT
!
ip radius source-interface Vlan17
!
!
radius-server host 10.225.49.15 auth-port 1812 acct-port 1813 key 7 153C1805102F7A767B6760
!
!
wireless exclusionlist 1CB0.9414.9077 description gregg
wireless broadcast
wireless multicast
aaa-override
nac
ip flow monitor wireless-avc-basic input
ip flow monitor wireless-avc-basic output
A-22
Appendix A

no shutdown
aaa-override
no security wpa
security web-auth
no shutdown
aaa-override
ip flow monitor wireless-avc-basic input
ip flow monitor wireless-avc-basic output
nac
no security wpa
no shutdown
no shutdown
aaa-override
nac
no security wpa
no shutdown
end
A-23
Appendix A
A-24
A P P E N D I X
References
Cisco BYOD Smart Solution:

http://www.cisco.com/go/byod/
TrustSec Guides:
http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns744/landing_DesignZone_TrustSec.html
Flex 7500 Wireless Branch Controller Deployment Guide:
http://www.cisco.com/en/US/products/ps11635/products_tech_note09186a0080b7f141.shtml#override
Wireless BYOD for FlexConnect Deployment Guide:
http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080bcb905.shtml
FlexConnect Feature Matrix:
http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080b3690b.shtml
Cisco Identity Services Engine Documentation:
http://www.cisco.com/en/US/customer/products/ps11640/products_user_guide_list.html
Cisco 5700 Series Wireless LAN ControllersConfiguration Guides:
www.cisco.com/en/US/customer/products/ps12598/products_installation_and_configuration_guides_li
st.html
Catalyst 3850 Series Switches Configuration Guides:
http://www.cisco.com/en/US/customer/products/ps12686/products_installation_and_configuration_gui
des_list.html
Catalyst 4500 Series Switch Software Configuration Guide:
http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/15.1/XE_330SG/configuration/guide/dot
1x.html#wp1324657
Catalyst 3750 Switch Software Configuration Guide:
http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/15.0_2_se/configuration
/guide/sw8021x.html#wp1434612
Cisco TrustSec Configuration Guide:
http://www.cisco.com/en/US/customer/docs/ios-xml/ios/sec_usr_cts/configuration/15-sy/sec-cts-15-sy
-book.html
Cisco Medianet Campus QoS Design 4.0:
_40.html
B-1
Appendix B
References
Cisco Borderless Campus 1.0 Cisco Validated Design Guide:

http://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/Borderless_Campus_Network_1.0/Bor
derless_Campus_1.0_Design_Guide.html
Configuring Certificates:
http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/cert_cfg.html
Configuring Tunnel Groups, Group Policies, and Users:
http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/vpngrp.html
Apple iPhone OS Enterprise Deployment Guide:
http://manuals.info.apple.com/en_US/Enterprise_Deployment_Guide.pdf
Cisco Enterprise Mobility 4.1 Design Guide:
http://www.cisco.com/en/US/docs/solutions/Enterprise/Mobility/emob41dg/emob41dg-wrapper.html
Cisco Jabber clientsproduct collateral and documentation:
http://www.cisco.com/go/jabber
Cisco Unified Communications System 9.X SRND:
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/9x/mobilapp.html
Cisco Visual Networking Index:
http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/white_paper_c11-52
0862.html
Cisco Wireless LAN Controller Configuration Guide, Release 7.4:
http://www.cisco.com/en/US/docs/wireless/controller/7.4/configuration/guides/consolidated/b_cg74_C
ONSOLIDATED.html
Cisco Wireless LAN Controller Configuration Guide, Release 7.4Configuring Multicast Domain
Name System:
http://www.cisco.com/en/US/docs/wireless/controller/7.4/configuration/guides/consolidated/b_cg74_C
ONSOLIDATED_chapter_01011.html#d75540e531a1635
Cisco WLC Bonjour Gateway Deployment Guide:
http://www.cisco.com/en/US/docs/wireless/technology/bonjour/Bonjour_Deployment.html
Cisco Unified Communications Manager and IM and Presence documentation
http://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-versi
on-10-0/model.html#ConfigurationGuides
Cisco Expressway Documentation
http://www.cisco.com/c/en/us/support/unified-communications/expressway/model.html
Cisco Unified Communications Manager IM and Presence Configuration and Administration
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/im_presence/configAdminGuide/10_0_1/
CUP0_BK_C318987B_00_config-admin-guide-imp-100.html
Cisco Expressway Mobile and Remote Access Deployment Guide
http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/expressway/config_guide/X8-1/Mobile-Re
mote-Access-via-Expressway-Deployment-Guide-X8-1-1.pdf
Cisco ASA Next-Generation Firewall Services Data Sheet
http://www.cisco.com/c/en/us/products/collateral/security/asa-5500-series-next-generation-firewalls/da
ta_sheet_c78-701659.html
Cisco AnyConnect Secure Mobility Client Data Sheet
http://www.cisco.com/c/en/us/products/collateral/security/asa-5500-series-next-generation-firewalls/da
ta_sheet_c78-527494.html
B-2
A P P E N D I X
Software Versions
Whats New: Updated Cisco ISE software version and the software versions for the Cisco 5508 and Flex
7500 Series WLCs.
The following tables highlight the hardware and software components used for validation testing in this
design guide. While other software versions provide the required BYOD functionality, the Validated
Software Version column indicates the software version used during the validation.
For specific feature support, consult the Cisco Feature Navigator: http://www.cisco.com/go/fn.
Table C-1
Security
Component
Role
Validated Software Version
Microsoft Active Directory
Server
Windows 2008 Server R2
Microsoft Certificate Authority Server
Windows 2008 Server R2
Cisco Identity Services Engine Authentication/Policy Server ISE SW 1.2.0.899 patch 8

Cisco Prime Infrastructure
Table C-2
Management
1.4.1
Wireless Access
Component
Role
Cisco AP3702
Access Point
N/A
Cisco AP2702
Access Point
N/A
Cisco AP3602
Access Point
N/A
Cisco AP2602
Access Point
N/A
Cisco 5508 Wireless Controller
Wireless LAN Controller
AireOS 7.6.122.21
Cisco Flex 7500 Wireless

Controller
AireOS 7.6.122.21
Mobility Services Engine
MSE 7.6
Cisco 5760
IOS XE 3.3.1SE
C-1
Appendix C
Table C-2
Software Versions
Wireless Access
Component
Role
Cisco Catalyst 3850
Campus and Branch Wireless

Access
IOS XE 3.3.1SE
Apple iPad
Wireless Device
iOS 7.0.2
Apple iPhone
Wireless Device
iOS 6.1.4
Samsung Galaxy SIV
Wireless Device
Android 4.3
Samsung Galaxy Tab2
Wireless Device
Android 4.1.1
The document Cisco Identity Services Engine Network Component Compatibility, Release 1.2 provides
a detailed description of which end user devices are supported
(http://www.cisco.com/en/US/docs/security/ise/1.2/compatibility/ise_sdt.html).
Table C-3
TrustSec
Component
Role
CT5760
Centralized Wireless Lan Controller

with support for inline tagging
IOS-XE 3.3.1SE
CT5508
Centralized Wireless Lan Controller

with only SXP support
7.6.122.21
Catalyst 6500 6500 VSS Distributed Switch and

Policy Enforcement point for Scenario
#2
SUP2-T; 15.1.1.-SYI
WS-X6904 Linecard with 10GE Modules
(FourX Adapter)
C3850
Converged Access Switch with support IOS-XE 3.3.1SE

for in line tagging
Nexus 7000
Data Center Switches and policy

enforcement point for Scenario #1
SUP2; 6.2(6)
F2e Linecard; N7K-F248XP-25E (only last
8 ports supporting MACsec)
Nexus 5548
Data Center Switch
Cisco Identity Authentication and Authorization

RADIUS Server
Services
Engine
1.2.0.899 patch 8
ASA Firewall Policy enforcement for Deployment

Scenario 2
9.0.2
Table C-4
Cisco UC and Expressway Components
Component
Role
Cisco Expressway
Expressway Core
X8.1.1
Cisco Expressway
Expressway Edge
X8.1.1
Unified CM
Call Processing
10.0.1
C-2
5.2(1)N1(3)
Appendix C
Software Versions
Table C-4
Cisco UC and Expressway Components
Component
Role
Unified IM and Presence
Instant Messaging, presence
10.0.1
Cisco ASA 5585X
VPN Concentrator
9.2(1)
Cisco Network Registrar
DHCP
8.1.3
Microsoft Active Directory/DNS Directory and Domain Name

Services
Windows 2008 R2
Jabber for Windows
Jabber Client
9.7
Jabber for iPhone and iPad
Jabber Client
9.6.2
Jabber for Mac
Jabber Client
9.6
Jabber for Android
Jabber Client
9.6.1
TelePresence EM/MX Series
Video Endpoint
TC 7.1.4
Component
Role
Catalyst 3560
Wired Access
IOS 15.2(1)E
Catalyst 3850
Campus/Branch
IOS XE 3.3.1SE
Catalyst 3750-X
Wired Access
IOS 15.2(1)E
Catalyst 4500E Sup7-E
Wired Access/Distribution
IOS XE 15.2(1)E
Catalyst 6500 VSS 1400

Catalyst 6500-E VSS4T
Campus Distribution/Core
IOS 15.1(1)SY1
Cisco Nexus 7000 Sup1
Campus Core/Data Center
NX-OS 6.2.6
Apple MacBook Pro
Wired/Wireless Device
OSX 10.9.1 and 10.8.5
Windows Laptop
Wired/Wireless Device
Microsoft Windows 7 (64 bit)
Table C-5
Table C-6
Wired Access
Remote Access
Component
Role
Software Version
ASA 5520
VPN Concentrator
8.4(2)
AnyConnect
VPN Client Software 3.0
The three feature sets available with Cisco Catalyst 3850 Series Switches are:
LAN BaseThe LAN Base feature set offers enhanced intelligent services that include
comprehensive Layer 2 features with up to 255 VLANs. It does not support either the wireless
Mobility Agent (MA) or the Mobility Controller (MC) function.
IP BaseEnterprise access Layer 3 switching features. The IP Base feature set provides entry-level
enterprise services in addition to all LAN Base features with 1000 VLANs. IP Base also includes
the support for wireless controller functionality (Mobility Agent (MA) and Mobility Controller
(MC) role; additional access point license required for Mobility Controller role), routed access,
smart operations, FNF, etc.
C-3
Appendix C
Software Versions
IP ServicesThe IP Services feature set provides full enterprise services that include advanced
Layer 3 features such as EIGRP, OSPF, BGP, PIM, and IPv6 routing such as OSPFv3 and EIGRPv6.
Also supports the wireless controller functionality.
All software feature sets support advanced security and MQC-based QoS.
Customers can transparently upgrade the software feature set in the Cisco Catalyst 3850 Series Switches
through Cisco IOS Software CLI using the right to use (RTU)-based software upgrade process. Software
activation enables the Cisco IOS Software feature sets. Based on the licenses type, Cisco IOS Software
activates the appropriate feature set. License types can be changed, or upgraded, to activate a different
feature set.
An access point license is required for Cisco Catalyst 3850 operating in Mobility Controller (MC) mode.
No access point license is required for 3850 operating in Mobility Agent (MA) mode. This functionality
is included in the IP Base feature set. Access point licenses can be transferred only between two Catalyst
3850 switches or between Catalyst 3850 switches and CT5760 wireless controllers and vice versa.
The Catalyst 3850 and CT 5760 running IOS XE 3.2.2 and higher software is compatible with CUWN
software version 7.3.112 or 7.5 and higherin order to support mobility interoperability.
C-4
A P P E N D I X

This appendix contains information regarding known caveats within Cisco product software revisions
which could impact the Cisco BYOD solution documented in this design guide. The caveats are
organized around product and software releases within this appendix for ease of reference.
IOS XE 3.2.2 SE Software ReleaseCatalyst 3850 Series

Switches and Cisco 5760 Wireless Controllers
Wireless clients associated with Access Points connected to Catalyst 3850 Series switches may
unexpectedly go into an IDLE state. This rare occurrence can happen after a client has been
on-boarded and is connected to the employee SSID with full, partial, or Internet only access, during
on-boarding (using a single or dual-SSID design), while a client is blacklisted, or during MDM or
ISE remediation.
The network administrator can view a wireless client in this state via the show wireless client
summary CLI command. An example is shown below in which the two highlighted wireless clients
are in an IDLE state.
uasl-3850-2# show wireless client summary
Number of Local Clients : 5
MAC Address
AP Name
WLAN State
Protocol
-------------------------------------------------------------------------------38aa.3c44.a224 test_ap
1
UP
11n(2.4)
789e.d0cd.f8ac test_ap
1
Idle
11n(2.4)
8832.9b0d.e554 test_ap
1
WEBAUTH_PEND
11n(2.4)
c860.001a.a77e test_ap
3
WEBAUTH_PEND
11n(2.4)
f0b4.7953.26b8 test_ap
1
Idle
11n(2.4)
Once in this state, the wireless client cannot disconnect and re-connect to the wireless network
without assistance from a network administrator. The network administrator can clear an IDLE
client by issuing the wireless client mac-address <mac-address of the wireless client>
deauthenticate forced CLI command. Note that this command does not appear within the existing
Cisco IOS 3.2.xSE command reference. For example, in order to clear the wireless client with mac
address f0b4.7953.26b8 shown in the example above, the network administrator would issue the
following command:
uasl-3850-2# wireless client mac-address f0b4.7953.26b8 deauthenticate forced
D-1
Appendix D
Blacklisted wireless clients associated with Access Points connected to Catalyst 3850 Series
switches may occasionally require manual intervention in order to regain access to network
resources when attempting to reinstate the client. This rare occurrence happens when the Catalyst
3850 Series switch is unable to process the CoA request to remove the ACL_BLACKHOLE and
ACL_BLACKHOLE_Redirect ACLs applied to a Blacklisted device as part of the Cisco BYOD
solution. The end user can toggle WiFi access on the mobile device in order to regain network
access. Alternatively, the network administrator can de-authenticate the wireless client via the
wireless client mac-address <mac-address of the wireless client> deauthenticate CLI command
and then allow the device to normally reconnect to the network. For example, in order to clear a
wireless client with mac address b4f0.abce.fa66, the network administrator would issue the
following command:
uasl-3850-2# wireless client mac-address f0b4.7953.26b8 deauthenticate
This caveat is documented as bug ID CSCuh66924 within the Cisco Bug Toolkit.
The Release Notes for the Catalyst 3850 Series Switch, Cisco IOS XE Release 3.2.xSE contains
additional caveats specific to the Catalyst 3850 Series Switch and can be found at:
http://www.cisco.com/en/US/docs/switches/lan/catalyst3850/software/release/3.2_0_se/release_notes/
OL28114.html#wp224029
D-2
A P P E N D I X

Whats New: This is a new appendix that describes a new behavior found in version 7.5+ of the Wireless
LAN Controllers and provides alternate ways to enforce ACLs in different deployments.
The ACL behavior in version 7.5+ of the Wireless LAN Controller has changed. The presence of an
Previous to WLC version 7.5+, a single rule was used to on-board devices connecting from multiple
locations, such as Campus, FlexConnect, or Converged Access. For example, Figure E-1 shows the
original Wireless CWA authorization profile used in dual SSID configurations to redirect devices to the
Self-Registration portal.
E-1
Appendix E
Figure E-1
Wireless CWA Authorization Profile
provisioning: one for FlexConnect and CUWN wireless controllers and another one for Converged
Note
The change in behavior between 7.4 and 7.5 for the Airespace ACL on FlexConnect Aps is documented
in CSCuc72705 - NineHills feature, FlexConnnect Client ACL support from AAA.

In dual SSID configurations, wireless devices get redirected to the Self-Registration portal upon
connecting to the network. This authorization profile restricts access by triggering the
Figure E-2 shows the Wireless CWA_CUWN authorization profile, used by CUWN access points, which
include FlexConnect access points. Notice that the Airespace ACL Name is no longer used.
E-2
Appendix E

Figure E-2
Wireless_CWA_CUWN
For devices connecting from access points in a Converged Access environment, the Wireless
CWA_Converged authorization profile shown in Figure E-3 is used. Filter-ID is an IETF attribute used
by the ISE to instruct the WLC which named-ACL should be applied to the session.
E-3
Appendix E
Figure E-3
Wireless CWA_Converged

In single SSID configurations, wireless devices get redirected to the Self-Registration portal upon
connecting to the network. This authorization profile restricts access by triggering the
The Wireless NSP authorization profile is used to redirect devices to the Guest portal using the PEAP
authentication protocol.
Figure E-4 shows the Wireless NSP_CUWN authorization profile used by CUWN access points, which
include FlexConnect access points. Notice that the Airespace ACL Name is no longer used.
E-4
Appendix E

Figure E-4
Wireless NSP_CUWN
For devices connecting from access points in a Converged Access environment, the Wireless
NSP_Converged authorization profile shown in Figure E-5 is used. Filter-ID is an IETF attribute used
by the ISE to instruct the WLC which named-ACL should be applied to the session.
E-5
Appendix E
Figure E-5
Wireless NSP_Converged
Previous to version WLC 7.5+, two on-boarding rules were sufficient to include devices connecting from
different locations. These rules, Wireless CWA and Wireless NSP, are shown in Figure 10-33 and
Figure 10-36.
The authorization profiles created in the previous sections can be linked to the proper authorization
policy. The rules shown in Figure E-6 are dedicated to CUWN/FlexConnect and Converged Access for
both single and dual SSID configurations.
E-6
Appendix E

Figure E-6
The behavior is similar for other cases shown in the CVD, such as:
Blacklisting wireless devices (e.g., Blackhole WiFi Access)
Advanced Use Case and MDM integration (e.g., Internet Until MDM and Quarantine rules)
Those rules need to be divided into different configurations for CUWN/FlexConnect and Converged
Access, each with their respective authorization profiles.
These and other rules affected by the new behavior will be addressed in an upcoming release of the CVD.
E-7
Appendix E
E-8

BYOD Design Guide

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

BYOD Design Guide

Caricato da

Copyright:

Formati disponibili

Cisco Unified Access (UA) and Bring Your Own

Device (BYOD) CVD

Building Architectures to Solve Business Problems

Cisco Validated Design

About the Authors

About the Authors

Zeb Hallock, Technical Marketing Engineer, Systems Development

John Johnston, Technical Marketing Engineer, Systems Development

Fernando Macias, Solutions Architect, Systems Development Unit,

In addition to Masters Degrees in Technology Management and Software Engineering,

Cisco Validated Design

About the Authors

Roland Saville, Technical Leader, Systems Development Unit, Cisco Systems

Srinivas Tenneti, Technical Marketing Engineer, Systems Development

About the Authors

Mike Jessup, Technical Lead Engineer/Architect, Systems Development

Suyog Deshpande, Technical Marketing Engineer, Systems Development

Suyog Deshpande is a Technical Marketing Engineer within Systems Development Unit

Tim Szigeti, Technical Leader, Systems Development Unit, Cisco Systems

About Cisco Validated Design (CVD) Program

About Cisco Validated Design (CVD) Program

About Cisco Validated Design (CVD) Program

BYOD Solution Overview

BYOD Market Landscape 1-1

Challenges for End Users 1-4

BYOD Design Overview

Summary of Design Overview

Cisco BYOD Solution Components

Cisco Wireless Infrastructure 3-3

BYOD Use Cases

Enhanced AccessPersonal and Corporate Devices

Limited AccessCorporate Devices

Campus and Branch Network Design for BYOD

Campus Network Design 5-1

Branch LAN Network Design 5-34

Mobile Device Managers for BYOD

Cisco ISE 1.2 with MDM API Integration

MDM Deployment Options and Considerations

Application Considerations and License Requirements for BYOD

Quality of Service 7-1

Cisco Jabber 7-43

Configuring the Infrastructure

Cisco Bring Your Own Device (BYOD) CVD

Summary of Configuring the Infrastructure

BYOD Wireless Infrastructure Design

CampusUnified Wireless LAN Design 9-1

BranchUnified Wireless LAN Design 9-9

Identity Services Engine for BYOD

Network Device Definition within ISE

Guest and Self-Registration Portals 10-4

Authentication Policies 10-8

Cisco Bring Your Own Device (BYOD) CVD

Client Provisioning ResourcesMac OS 10-13

Authorization Policies and Profiles 10-23

BYOD Wired Infrastructure Design

Campus Wired Design 11-1

Security Group Access for BYOD

Unified Infrastructure Design to Support SGA 12-1

Mobile Device Manager Integration for BYOD

Establishing IP Connectivity for an On-Premise MDM

Establishing IP Connectivity for a Cloud-Based MDM

Configure ISE to Authenticate the MDM API

Setting Up the MDM Connection 13-4

BYOD Use Cases