UA SE Bootcamp - Student - Part 1

UASEBC
Unified Access SE
Boot Camp
Student Guide
Version 1.0
DISCLAIMER WARRANTY: THIS CONTENT IS BEING PROVIDED “AS IS.” CISCO MAKES AND YOU RECEIVE NO WARRANTIES IN
CONNECTION WITH THE CONTENT PROVIDED HEREUNDER, EXPRESS, IMPLIED, STATUTORY OR IN ANY OTHER PROVISION OF
THIS CONTENT OR COMMUNICATION BETWEEN CISCO AND YOU. CISCO SPECIFICALLY DISCLAIMS ALL IMPLIED
WARRANTIES, INCLUDING WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR
PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE. This learning product may contain early release
content, and while Cisco believes it to be accurate, it falls subject to the disclaimer above.
Unified Access SE Boot Camp (UASEBC) v1.0 © 2013 Cisco Systems, Inc. CONFIDENTIAL
Table of Contents
Course Introduction .......................................................................................................... 1
Overview ................................................................................................................................................1
Learner Skills and Knowledge ...............................................................................................................2
Course Goal and Objectives ..................................................................................................................3
What is Unified Access ..........................................................................................................................4
Class Scenario – HTA Hospitals............................................................................................................7
Course Flow ...........................................................................................................................................8
General Administration ....................................................................................................................... 10
Student Introductions .......................................................................................................................... 11
One Network—Building the Wired Foundation ........................................................... 1-1
Wired Unified Access Infrastructure and Advanced Features .......................................... 1-3
Overview ............................................................................................................................................ 1-3
Objectives .................................................................................................................................... 1-4
Cisco Unified Access Architecture ..................................................................................................... 1-5
Cisco Unified Access Wired Architecture High Availability Features .............................................. 1-12
Virtual Switch Identifiers ............................................................................................................ 1-20
Virtual Switch Link ..................................................................................................................... 1-20
Virtual Switch Roles .................................................................................................................. 1-20
Control and Data Plane ............................................................................................................. 1-20
Router MAC Address ................................................................................................................ 1-21
Cisco Catalyst Smart Operations ..................................................................................................... 1-31
Cisco Auto-QoS ............................................................................................................................... 1-34
Cisco Auto Smartports ..................................................................................................................... 1-37
Cisco Smart Install ........................................................................................................................... 1-43
Cisco Easy Virtual Network ............................................................................................................. 1-52
Summary.......................................................................................................................................... 1-62
Module Self-Check .......................................................................................................................... 1-63
Module Self-Check Answer Key................................................................................................ 1-65
One Management Foundation—Basic Prime Infrastructure Setup ............................ 2-1
Prime Infrastructure Setup for Wired and Wireless Clients .............................................. 2-3
Overview ............................................................................................................................................ 2-3
Objectives .................................................................................................................................... 2-3
Prime Infrastructure Overview, Direction, and Roadmap .................................................................. 2-4
Lifecycle Management of Wired and Wireless Devices .................................................................. 2-13
Assurance Management .................................................................................................................. 2-23
Operationalizing the Cisco Advantage ............................................................................................ 2-30
Cisco Prime Infrastructure Field Resources .................................................................................... 2-40
Summary.......................................................................................................................................... 2-44
References ................................................................................................................................ 2-44
One Policy Foundation .................................................................................................. 3-1
Basic Cisco ISE AAA and Guest Server Setup for Wired and Wireless Networks .......... 3-3
Overview ............................................................................................................................................ 3-3
Objectives .................................................................................................................................... 3-3
Cisco ISE Solution Overview and Positioning ................................................................................... 3-4
Secure Access ................................................................................................................................. 3-21
Cisco Setup Assistant ...................................................................................................................... 3-62
Guest Portal ..................................................................................................................................... 3-64
Summary.......................................................................................................................................... 3-89
References ................................................................................................................................ 3-89
One Network—Building the Wireless Network ............................................................ 4-1
Wireless Network Architecture ........................................................................................... 4-3
Overview ............................................................................................................................................ 4-3
Objectives ................................................................................................................................... 4-3
HTA Hospital Use Case ..................................................................................................................... 4-4
Cisco Wireless LAN Deployment Architectures ................................................................................ 4-5
Cisco Wireless LAN Portfolio of Products ......................................................................................... 4-7
Access Points .............................................................................................................................. 4-8
Controllers ................................................................................................................................... 4-9
Cisco Mobility Services Engine ................................................................................................. 4-10
Cisco Wireless LAN Compatibility Matrix ........................................................................................ 4-11
Cisco Wireless LAN Roadmap ........................................................................................................ 4-12
IOS Controllers .......................................................................................................................... 4-14
Summary ......................................................................................................................................... 4-15
Basic Wireless Connectivity and Functionality ............................................................... 4-17
Overview .......................................................................................................................................... 4-17
Objectives ................................................................................................................................. 4-17
Maintaining Optimum RF Conditions in a Changing Environment .................................................. 4-18
Band Select ..................................................................................................................................... 4-24
Cisco ClientLink ............................................................................................................................... 4-26
Cisco CleanAir Technology ............................................................................................................. 4-28
High Availability Solutions ............................................................................................................... 4-31
Summary ......................................................................................................................................... 4-36
Wireless Network Security ................................................................................................ 4-37
Overview .......................................................................................................................................... 4-37
Objectives ................................................................................................................................. 4-37
Traffic Segmentation Needs and Methods ...................................................................................... 4-38
One Network—Cisco Prime Infrastructure and ISE Integration ...................................................... 4-44
Adaptive wIPS ................................................................................................................................. 4-45
Summary ......................................................................................................................................... 4-49
References ................................................................................................................................ 4-49
Wireless Network QoS ....................................................................................................... 4-51
Overview .......................................................................................................................................... 4-51
Objectives ................................................................................................................................. 4-51
Where and When QoS Is Applied.................................................................................................... 4-52
802.11e Metal Profiles ..................................................................................................................... 4-56
Alloy QoS and Traffic Control Techniques ...................................................................................... 4-64
Summary ......................................................................................................................................... 4-72
References ................................................................................................................................ 4-72
Additional Wireless Features ............................................................................................ 4-73
Overview .......................................................................................................................................... 4-73
Objectives ................................................................................................................................. 4-73
Cisco VideoStream .......................................................................................................................... 4-74
Cisco Bonjour Gateway ................................................................................................................... 4-81
Mobility Services .............................................................................................................................. 4-85
Summary ......................................................................................................................................... 4-92
Module Summary............................................................................................................................. 4-93
References ................................................................................................................................ 4-94
Module Self-Check Answer Key ............................................................................................... 4-98
Converged Access Solution Design Overview ............................................................ 5-1
Converged Access Solution................................................................................................ 5-3
Overview ............................................................................................................................................ 5-3
Objectives ................................................................................................................................... 5-3
Solutions and Platforms Overview..................................................................................................... 5-4
ii Unified Access SE Boot Camp (UASEBC) v1.0 © 2013 Cisco Systems, Inc.
Architecture and Components Review ............................................................................................ 5-16
Roaming........................................................................................................................................... 5-26
Features and Licensing Overview ................................................................................................... 5-40
Quality of Service ............................................................................................................................. 5-50
Security ............................................................................................................................................ 5-59
Multicast ........................................................................................................................................... 5-68
Design Options and Migration ......................................................................................................... 5-80
Wrap-up and Final Thoughts ........................................................................................................... 5-92
Summary.......................................................................................................................................... 5-94
Securing Any Access .................................................................................................... 6-1
Securing AnyAccess with ISE ............................................................................................. 6-3
Overview ..................................................................................................................................... 6-3
Objectives .................................................................................................................................... 6-3
Securing BYOD Access Overview ..................................................................................................... 6-4
Implementing Authentication and Authorization for BYOD through ISE............................................ 6-7
BYOD On-boarding through ISE...................................................................................................... 6-11
ISE BYOD with MDM Eco-System .................................................................................................. 6-18
Profiler Service Overview ................................................................................................................ 6-20
Summary.......................................................................................................................................... 6-30
References ................................................................................................................................ 6-30
Setting Up Secure Group Access for a BYOD Environment ........................................... 6-33
Overview .......................................................................................................................................... 6-33
Objectives .................................................................................................................................. 6-33
Security Group Access Overview .................................................................................................... 6-34
Security Group Tagging in the Wired and Wireless Infrastructure .................................................. 6-39
Transporting SGT and the SGT eXchange Protocol ....................................................................... 6-41
ISE Security Groups, SG-ACLs, and Security Group Matrix ........................................................... 6-47
Implementing SGT for Employee BYOD ......................................................................................... 6-52
Implementing MACsec Encryption for Employee BYOD ................................................................. 6-55
Summary.......................................................................................................................................... 6-59
SmartOperations ............................................................................................................ 7-1
SmartOperations Overview Including EEM with GOLD and IP SLA ................................. 7-3
Overview ............................................................................................................................................ 7-3
Objectives .................................................................................................................................... 7-3
HTA Hospital Case Study .................................................................................................................. 7-4
EEM Overview ................................................................................................................................... 7-5
EEM Configuration on Catalyst Series Switches ............................................................................. 7-18
Automated Diagnostic Features ...................................................................................................... 7-24
Cisco GOLD Overview ..................................................................................................................... 7-27
Understanding IP SLA Benefits ....................................................................................................... 7-37
Best Practices .................................................................................................................................. 7-44
Summary.......................................................................................................................................... 7-45
References ................................................................................................................................ 7-45
Application Visibility and Control ................................................................................. 8-1
Application Visibility and Control Overview and Configuration ....................................... 8-3
Overview ............................................................................................................................................ 8-3
Objectives .................................................................................................................................... 8-3
Cisco Application Visibility and Control ............................................................................................. 8-4
Cisco Medianet ................................................................................................................................ 8-15
© 2013 Cisco Systems, Inc. Unified Access SE Boot Camp (UASEBC) v1.0 iii
Cisco Mediatrace ............................................................................................................................. 8-20
Cisco Medianet Auto Configuration via Auto Smartports ................................................................ 8-28
Cisco Media Service Interface and Media Service Proxy ............................................................... 8-34
Cisco Flexible NetFlow .................................................................................................................... 8-39
Cisco Packet Capture Technologies ............................................................................................... 8-46
Summary ................................................................................................................................... 8-53
References ................................................................................................................................ 8-53
Monitoring, Reporting, and Troubleshooting with PI and ISE .................................... 9-1
Monitoring, Reporting, and Troubleshooting with PI and ISE .......................................... 9-3
Overview ............................................................................................................................................ 9-3
Objectives ................................................................................................................................... 9-3
Troubleshooting Overview with PI and ISE ....................................................................................... 9-4
PI and ISE Integration ....................................................................................................................... 9-6
ISE Monitoring ................................................................................................................................. 9-22
PI Reporting ..................................................................................................................................... 9-29
ISE Reporting and Logging ............................................................................................................. 9-31
ISE Troubleshooting ........................................................................................................................ 9-35
Leveraging Advanced Device Capabilities under the Hood ............................................................ 9-45
Summary ......................................................................................................................................... 9-49
Student Guide Supporting Material.................................................................................. S
One Network—Building the Wired Foundation Supporting Material .............................. S1-1
Overview .......................................................................................................................................... S1-1
Cisco Unified Access Architecture................................................................................................... S1-2
Cisco Unified Access Wired Architecture High Availability Features .............................................. S1-4
Cisco AutoQoS .............................................................................................................................. S1-26
Configuring AutoQoS for Catalyst 3850 Switch ...................................................................... S1-29
Verifying AutoQoS for Catalyst 3850 Switch........................................................................... S1-29
Cisco Smartports ........................................................................................................................... S1-30
Cisco Smart Install ......................................................................................................................... S1-33
Cisco EVN ..................................................................................................................................... S1-41
One Policy Foundation Supporting Material .................................................................... S3-1
Overview .......................................................................................................................................... S3-1
One Network—Building the Wireless Network Supporting Material .............................. S4-1
Overview .......................................................................................................................................... S4-1
Supporting Material for Lesson 1: Wireless Network Architectures ................................................ S4-2
Mobility Services Engine ........................................................................................................... S4-4
Supporting Material for Lesson 2: Basic Wireless Connectivity and Functionality .......................... S4-5
Supporting Material for Lesson 3: Wireless Network Security ........................................................ S4-7
Cisco AP SSO Implementation ................................................................................................. S4-7
Adaptive wIPS Scalability........................................................................................................ S4-24
3600 AP Monitor module......................................................................................................... S4-26
Supporting Material for Lesson 4: Wireless Network QoS ............................................................ S4-27
QoS Rate Limiting additional information................................................................................ S4-27
Securing Any Access Supporting Material ...................................................................... S6-1
Overview .......................................................................................................................................... S6-1
TrustSec Guides .............................................................................................................................. S6-2
TrustSec Planned Releases ............................................................................................................ S6-3
SGT Access Layer Functions .......................................................................................................... S6-6
Support Matrix for IOS Routers ....................................................................................................... S6-7
SGT/SGACL Platform ...................................................................................................................... S6-8
SGFW Platform................................................................................................................................ S6-9
iv Unified Access SE Boot Camp (UASEBC) v1.0 © 2013 Cisco Systems, Inc.
SmartOperations Supporting Material .............................................................................. S7-1
Overview .......................................................................................................................................... S7-1
EEM Overview ................................................................................................................................. S7-2
Event Detector: Syslog .............................................................................................................. S7-2
Event Detector: SNMP .............................................................................................................. S7-2
Event Detector: Timer ............................................................................................................... S7-3
Event Detector: Counter ............................................................................................................ S7-3
Event Detector: Interface .......................................................................................................... S7-4
Event Detector: CLI ................................................................................................................... S7-4
Event Detector: OIR .................................................................................................................. S7-4
Event Detector: RF .................................................................................................................... S7-6
Event Detector: IOSWDSYSMON ............................................................................................. S7-6
Event Detector: GOLD .............................................................................................................. S7-6
Event Detector: APPL ............................................................................................................... S7-7
Event Detector: SNMP-Notification ........................................................................................... S7-7
Event Detector: RPC ................................................................................................................. S7-7
Event Detector: Track................................................................................................................ S7-8
Event Detector: None ................................................................................................................ S7-9
Routing Event Detector ............................................................................................................. S7-9
Flexible NetFlow Event Detector ............................................................................................... S7-9
IP SLA Event Detector .............................................................................................................. S7-9
Enhanced CLI Event Detector ................................................................................................... S7-9
EEM Configuration on Catalyst Series Switches ........................................................................... S7-12
Event Register Keyword .......................................................................................................... S7-12
Importing Namespaces ........................................................................................................... S7-13
Tcl Script ................................................................................................................................. S7-13
Tcl Script Elements ................................................................................................................. S7-13
Cisco Generic Online Diagnostics (GOLD) Overview ................................................................... S7-17
Understanding IP SLA Benefits ..................................................................................................... S7-22
Application Visibility and Control Supporting Material ................................................... S8-1
Overview .......................................................................................................................................... S8-1
Cisco Medianet ................................................................................................................................ S8-2
Cisco Mediatrace ............................................................................................................................. S8-4
Cisco IOS Flexible NetFlow ............................................................................................................. S8-7
Cisco Auto Smartports ................................................................................................................... S8-16
Cisco MSI and MSP ....................................................................................................................... S8-19
Cisco Packet Capture Technologies.............................................................................................. S8-24
© 2013 Cisco Systems, Inc. Unified Access SE Boot Camp (UASEBC) v1.0 v
vi Unified Access SE Boot Camp (UASEBC) v1.0 © 2013 Cisco Systems, Inc.
UASEBC
Course Introduction
Overview
UA SE Boot Camp (UASEBC) v1.0 is a five-day instructor-led course. The UASEBC course
presents concepts, wired and wireless platforms, technologies and services that are required for
a comprehensive approach to effectively design, manage, and control the access of a Unified
Access Architecture network. The reference network selected as a case study in this course is
the fictitious Health To All (HTA) Hospital.
This complete solution starts with Cisco design guides and professional services that lead you
from planning and design to day-to-day operations at HTA Hospital. This Unified Access
solution also provides the necessary infrastructure, including Wireless Access points, Wireless
LAN Controllers, Security Appliances, and Network Management Tools.
This infrastructure supports a highly secure, high-performing network that is accessible to a
wide range of devices. HTA Hospital users include guests, corporate users, employees and
patients. Users have personal computers and VoIP phones at their desks as well as mobile
computers, tablets, and smartphones. The network is used for accessing critical patient data, for
voice and video traffic, accessing different servers as well as for web browsing. The Cisco
solution addresses all the aspects of the HTA Hospital and meets all the requirements for
building a secure, scalable BYOD network.
The course will introduce the concept of One Network, One Policy and One Management.
Learner Skills and Knowledge
This topic lists the skills and knowledge that learners must possess to benefit fully from the
course. The topic also includes recommended Cisco learning offerings that learners should first
complete to benefit fully from this course.
The prerequisite knowledge and skills that a learner must have before
attending this course are as follows:
• Good understanding of networking protocols and 802.1X
• Cisco CCNA Certification, or equivalent work experience
• Cisco CCNA Wireless Certification, or equivalent work experience
• Attended the Unified Access Roadshow
© 2013 Cisco and/or its affiliates. All rights reserved. CONFIDENTIAL UACBC v1.0—0-2
2 Unified Access SE Boot Camp (UASEBC) v1.0 © 2013 Cisco Systems, Inc. CONFIDENTIAL
Course Goal and Objectives
This topic describes the course goal and objectives.
• Provide training that will lead to

increased sales of the Unified
Access solution components
• Demonstrate, through hands-on
labs and lecture, the One Policy,
One Management, One Network
Unified Access Solution
• Identify the key differentiators of
the Cisco Unified Access solution
*This is not a 3850 • Instill confidence by building, from
Converged Access the ground up, a complete UA
design with all components
bootcamp working together
Upon completing this course, you will be able to meet these objectives:
 Design and configure the wired network foundation upon which the Unified Access
solution will be built.
 Implement Cisco Best Practices for the initial configuration of PI as design references for
implementing the Unified Access Architecture.
 Utilize the Cisco Identity Services Engine (ISE) authentication, authorization, and
accounting (AAA) setup and guest server setup for wired and wireless networks.
 Implement a wireless network that comprises APs, CUWN WLCs, switches, Cisco Prime
Infrastructure, and MSE.
 Design and configure a Converged Access solution using Cisco Catalyst 3850 Series
Switches and Cisco 5700 Series Wireless LAN Controllers.
 Design and configure any access security using 802.1x and ISE.
 Utilize Cisco IOS Embedded Event Manager (EEM) with Cisco Generic Online
Diagnostics (GOLD) and IP SLA to assess health and readiness of a Unified Access
Architecture.
 Configure the AVC features Medianet and Mediatrace, Cisco Modular QoS, Cisco IOS
Flexible NetFlow Traffic Records and Wireshark to ensure proper allocation of resources to
high priority applications.
 Utilize PI and ISE to Monitor and troubleshoot a Unified Access Network
 Implement ISE on-boarding, Secure AnyConnect, ISE Device Registration Procedures,
802.1x, and ISE Profile for a secure BYOD solution.
© 2013 Cisco Systems, Inc. CONFIDENTIAL Course Introduction 3

What is Unified Access
ONE Network
• Converged wired and ONE Policy
wireless • Central policy
• Consistent Network Wide platform for
Intelligence and Operations Secure wired/wireless/VPN
• Integrated into Cisco Open
Network Environment (ONE) Consistent User • Context-aware:
Experience Who, What, Where,
ONE Management When, How
• Single platform for Simplified • BYOD & MDM
wired/wireless integration
• Lifecycle management,
assurance, compliance
• 360 degree user experience
The Intelligent Platform for a Connected World
One Policy
Cisco Identity Services Engine (ISE)
Define network policy as an
Product
Bookings extension of business goals
Corporate Customer
issued laptop Data
Policy extends to all access
X
Finance types (wired, wireless, VPN)
Manager
SalesForce
.com Lifecycle services integration –
Personal iPad
guest, BYOD, profiling, posture
to support compliance
Distributed enforcement: wireless,
switches, router, firewalls, remote
access
ISE
© 2012 Cisco and/or its affiliates. All rights reserved.
Unified Policy Cisco Confidential 5
Prime
• A single integrated solution for
comprehensive lifecycle
management of wired/wireless
access, campus, and branch
networks
• Utilizes rich performance data for
end-to-end network visibility to
assure application delivery and
optimal end-user experience
• Single Pane of Glass

• Consolidation, Convergence, Cisco Advantage
© 2010 Cisco and/or its affiliates. All rights reserved. 6
Converged
Access Infrastructure Controller Infrastructure
Catalyst 3850 Catalyst 4500-E w/ For Large Campus For SP
Sup. 8-E 5508 WISM2 5760 8500
For Branch / Small Campus

WLC on ISR G2 2500 Virtual Controller
One Management and Policy with Prime and ISE
Access Switches
3750x Series 4500E 6500 Series
3850 Series Series
Converged Backbone & Instant

Access Stackable Converged
Access Access
Access
Modular
© 2013 Cisco and/or its affiliates. All rights reserved. Stackable Cisco Confidential 7

Cisco Cisco Wireless
Access Point LAN Controller Branch
Application
Unified Unified Unified
Visibility & Control
Access Services Access
Edge
Router
Corporate WA
Network N
Catalyst AP
WAAS
Switch
Firewall WAN Path
& VPN Control
LAN Mgmt Access

Solution Control
Wireless Control Identity NAC Guest
Server
Server
One Management System Mgmt
One Policy
Profiler
Prime ISE
© 2012 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 8
Class Scenario – HTA Hospitals
Customer: Health to All Hospitals

Your role: Lead IT engineer for HTA
Background: HTA is building a new hospital. You, as their IT
engineer, are tasked with building the network from scratch.
Design Guidance: In general, HTA wants a Cisco best of
breed, very reliable network that is BYOD enabled and easy to
manage.
Specific HTA design objectives will be provided in each lab.
You will build the foundation of the network first and then
enable several Cisco differentiating features.
One Policy, One Management, One Network Realized

Core, distribution and wired & wireless access design enhanced with smart
operations features.
• Increased resiliency, scalability, adaptability and visibility
• Improved ease of troubleshooting with quicker problem resolution
• Ready for the future, simple migration to new technologies like Converged Access
Prime Infrastructure provides One Management, central pane of glass for

wired and wireless Unified Access
• Comprehensive network lifecycle management including user access visibility,
inventory, configuration management, radio frequency planning, 360 view, and reporting
• End-to-end application and service assurance visibility leveraging flexible NetFlow,

Network Based Application Recognition (NBAR), and Medianet Performance Agent
• Greatly enhances the visibility and troubleshooting capabilities of IT
Identity Services Engine provides centralized One Policy for Unified Access
• HTA UA Network is Guest and BYOD ready
• Policy convergence with wired and wireless, all campus ingress points are secured
• The SGA enabled UA network simplifies the security policy for HTA

Course Flow
This topic presents the suggested flow of the course materials.
UASEBC Program
DAY ONE DAY TWO DAY THREE DAY FOUR DAY FIVE
Mod 6 Labs Module 9 Labs

Class Introductions (Lab 6-2) (Lab 9-2)
Module 3 Labs
Module 1 - Module 5 - Module 7 - Module 10 -
(3-3 & 3-4)
MORNING Network Foundation
Module 4 -
Converged Access SmartOperations BYOD &Wrap-up
Intro to Labs Module 5 Labs Module 7 Labs dCloud Enablement
Wireless Foundation
Module 1 Labs Module 8 - Exam Review
AVC UASEBC Exam
LUNCH LUNCH LUNCH LUNCH LUNCH
Module 2 -
Network Management Module 8 Labs
Module 6 -
Module 2 Labs Module 4 Labs Module 9 -
Security/TrustSec
AFTERNOON Module 3 - Module 5 -
Module 6 Labs
Troubleshooting
Policy Foundation Converged Access Module 9 Labs
(Lab 6-1)
Module 3 Labs (Lab 9-1)
(3-1 & 3-2)
The schedule reflects the recommended structure for this course. This structure allows enough
time for the instructor to present the course information and for you to work through the lab
activities. The exact timing of the subject materials and labs depends on the pace of your
specific class. This course has been created as a ‘Boot Camp’ and therefore the agenda for these
tasks and the length of each day is set accordingly.
The first six modules in the course implement the Health to All network. While the remaining
modules in the course describe advanced features which may be implemented in a Unified
Access network as well as how to maintain and troubleshooting the network, which can be
characterized as maintaining network health.
This course has been written as a “boot camp’ to empower Cisco Pre-Sales engineers, through
the hands-on learning activities of the course, to speak with confidence to their clients when
selling Cisco Unified Access and BYOD solutions.
During the initial modules of the course you will be guided through building the HTA Hospital
Network. You will gain practical and valuable hands-on experience by building this network
from the ground up.
In the course of Modules 1-3, you will build the ‘One Network’ infrastructure, to which you
will then add a ‘One Management’ server through the implementation of Cisco Prime
Infrastructure. You will then add a “One Policy’ server with the inclusion Cisco ISE as the
central policy server for that network.
You will also gain first-hand experience deploying a wireless access network as part of the
‘One Network” architecture to learn how to transition a customer from a traditional Wired /
Wireless solution to the Unified Access Solution Architecture. During the lab you will
demonstrate the ability for network users to access resources regardless of where or how they
connect based upon centralized authentication policies managed through ISE.
During the second part of the course you will modify the network you have built and
implement advanced networking features such as Converged Access and QoS in support of
multimedia traffic. You will migrate user policies to this new portion of the network
architecture to demonstrate that the same resources are available to end users.
You will also gain insight into deploying Cisco Unified Architecture Solution Differentiators
such as: Security with Cisco TrustSec, Smart Operations and Application Visibility and
Control.
You will also experience onboarding of end user devices to the network you have configured in
preparation for BYOD.
As a final wrap-up to the course you will be given additional tools in the form of a dCloud
Walkthrough and 819 Router presentation to allow you to effectively demonstrate to your
clients the features you have worked with.

General Administration
This topic presents the general administration for this course.
Class-related: Facilities-related:
• Sign-in sheet • Course materials
• Length and times • Site emergency procedures
• Break and lunch room locations • Restrooms
• Attire • Telephones and faxes
Student Introductions
This topic presents the student introduction for this course.
• Your name
• Your company
• Job responsibilities
• Skills and knowledge
• Brief history
• Objective

Module 1
One Network—Building the

Wired Foundation
1-2 Unified Access SE Boot Camp (UASEBC) v1.0 © 2013 Cisco Systems, Inc.
Lesson 1
Wired Unified Access

Infrastructure and Advanced
Features
Overview
This lesson will guide you through the wired reference architecture foundation, which is
applied to the HTA Hospital. HTA Hospital employees have many wired clients including
servers (video streaming and data), personal computers, wired VoIP phones, medical
instruments, and other devices that are connected to LANs.
Topics that are covered will include the requirements that are needed to build the wired
network that will become the basis for this course. This module will showcase features
applicable to the Unified Architecture network for the HTA Hospital. The HTA Hospital
requires 24/7 availability of the network, minimal downtime of the services, and a scalable
solution for managing many wired and wireless network devices and clients. These features
will include wired resiliency features, Smart Operations features, and Cisco Easy Virtual
Network (EVN) features, which will be implemented in a Cisco Unified Access network.
Configuration examples will be provided for all features. Use cases from HTA Hospital will
provide examples for how each of the highlighted features is implemented.
This module features a hands-on lab that will require you to build the required reference
architecture for HTA Hospital. This reference architecture will be used in future labs.
The lab challenge for this module will be to establish a reliable wired network and achieve
connectivity between wired clients and guest accessible servers that are attached to the wired
network infrastructure of the HTA Hospital.
Objectives
Upon completing this lesson, you will be able to explain the resiliency features implemented in
the Cisco Unified Access solutions architecture of the HTA Hospital network. You will be able
to meet the following objectives:
 Identify Cisco Unified Access as an intelligent network platform supporting bring your
own device (BYOD)
 Describe Cisco Unified Access wired architecture high availability features
 Identify Cisco Catalyst SmartOperations technologies and features
 Describe Cisco Auto Smartports operation
 Describe Cisco Smart Install operation
 Describe Cisco Auto-QoS deployment on the access ports on the campus switches
 Describe Cisco EVN, an IP-based network virtualization solution
Cisco Unified Access Architecture
This topic describes Cisco Unified Access architectures and the concept of One Network, One
Management, and One Policy.
© 2013 Cisco and/or its affiliates. All rights reserved. CONFIDENTIAL One Network-Building the Wired Foundation UASEBC v1.0—1-5
Today’s networks are facing several challenges in order to support technology advancement.
Faced with the major trends of Internet of Everything (IoE), BYOD, and mobility, businesses
are confronted with the inevitable proliferation of devices at the workplace. Businesses must
meet growing demands for bandwidth and network performance, as well as mitigate the
security risks of company data on mobile devices. In addition, they must maintain control of
and visibility into mobile users and devices accessing their networks. When addressing these
technological trends, enterprises must meet the following challenges:
 Securing any access
 Managing complexity and scale
 Delivering a high-quality experience
The Cisco Borderless Network Architecture is the technical architecture that allows
organizations to connect anyone, anywhere, anytime, and on any device—securely, reliably,
and seamlessly. It is the foundation for the Cisco Intelligent Network, providing optimization,
scale, and security to collaboration and virtualization. The architecture is built on an
infrastructure of scalable and resilient hardware and software. Components of the architecture
come together to build network systems that span your organization from network access to the
cloud.
Borderless network services are the advanced, differentiated capabilities that Cisco Borderless
Networks deliver across its routing, switching, security, wireless, and WAN optimization
portfolios. Based on One Policy, One Management, and One Network, the Cisco Unified
Access solution delivers an integrated and simplified intelligent network platform.
© 2013 Cisco Systems, Inc. One Network—Building the Wired Foundation 1-5
Identity Services
Engine and
Cisco Prime TrustSec
Infrastructure Good
MDM
Manager
Cisco
Catalyst
Switches Cisco WLAN
Controller
Wireless One
Wired Network Policy
Network
One
Management
AnyConnect VPN
One
Network
Traditionally, companies looked at themselves as isolated enterprises within a perimeter. These

companies had external facing applications, internal operations, and everything was secured.
Today, company borders are shifting. Networks are becoming borderless. As the number of
mobile and remote workers continues to rise, it is necessary to overcome the location border so
work can be performed from anywhere. At the same time, the increasingly broad range of
devices being used (MACs, PCs, iPhones, smartphones, tablets, and so on) in the office, at
home, or on the go require a reconsideration of the device border. Another shift is the
application border. Applications must work everywhere, regardless of device or location.
Cisco Unified Access is wired, wireless, and offers virtual private network (VPN) access with
Cisco Prime and Cisco Identity Services Engine (ISE).
Cisco Unified Access brings together the security and mobility you need to deliver a consistent
access experience to your organization regardless of location or device. By being able to
identify devices and their users, people easily access the information that they need, based on
policy settings, from anywhere at any time on any device which is an approach that protects
critical assets while empowering the workforce.
Cisco Unified Access solutions give IT the unified policy, management, and network platform
it needs to adapt to rapidly changing business needs, technologies, and user expectations. It
does this by employing a single network infrastructure with central policy and management
across wired and wireless networks and VPNs.
The three pillars of Cisco Unified Access are as follows:
 One Policy: World-class unified policy platform and distributed enforcement
 One Management: Single solution for comprehensive life-cycle management and
visibility
 One Network: Wired and wireless networks that converge into a single unified
infrastructure
Cisco One Policy is delivered by the Cisco ISE. Cisco ISE simplifies design and
implementation of policy and security with one policy across the entire wired and wireless
network and VPN infrastructure. Cisco ISE allows consistent enforcement of context-aware
policies and control with comprehensive input information, including information about the
user, device, location, time, and applications. Cisco ISE improves the user experience with self-
service on-boarding, guest handling, and location-based services.
New enhancements that are offered by Cisco ISE 1.2 include the following:
 Third-party mobile-device management integration, enabling the flexibility to choose a
mobile-device management vendor and simplified single-pane access for policy
management
 Device profiler feed service to provide dynamic new device information updates
 International language support and greater scalability, up to 250,000 endpoint devices
Cisco One Management is delivered by Cisco Prime Infrastructure. Cisco Prime Infrastructure
provides comprehensive Cisco Unified Access life-cycle management, end-user connectivity,
and application performance visibility to enable IT departments to deliver services that meet
today’s business demands.
Coupling client awareness with application performance visibility and network control, Cisco
Prime Infrastructure enables an uncompromised end-user experience and makes BYOD a
reality.
New enhancements that are offered by Cisco Prime Infrastructure 2.0 include the following:
 Cisco Prime 360-degree views for devices, applications, and users, simplifying
management and troubleshooting to improve the end-user experience and service assurance
 Enhanced automated workflows and integrated best practices for easy deployment and
management of Cisco advanced technologies and services, including Cisco Adaptive
Wireless Intrusion Prevention System (wIPS), Cisco CleanAir Technology, VPN, zone-
based firewall, Cisco ScanSafe, and application visibility and control
Cisco One Management is further enhanced with the Cisco Mobility Services Engine (MSE).
Cisco MSE provides advanced spectrum analysis and Cisco Adaptive wIPS Software to detect,
track, and trace the following:
 Rogue devices
 Interferers
 Wi-Fi clients
 Radio frequency ID (RFID) tags
 Over-the-air threats with location and mitigation capabilities
Advanced location services within the Cisco Mobile Concierge (part of the Cisco Connected
Mobile Experiences Solution) allow wireless LAN monetization and location analytics.
Mobility Services Engine
Physical or Virtual Access Points
Indoor Teleworker
3310 and 3355
Wireless LAN Controllers 1600 600 Series
Outdoor
Identity and Policy
Data Integration 2500 WLC on 2600
Series SRE
NCS 1550 Series
5500 WiSM2 3500 Density

Physical Series
or Virtual ISE
vWLC
Distribution 3600 3500p Series
Switches 8500 7500
Access Switches
6500 Series
Compact 2960-S 3750-X/3560-X 3850 4500E
This figure shows the borderless network architecture which provides Cisco customers the
power of choice.
Cisco One Network is the convergence of the wired and wireless networks into one physical
infrastructure with greater intelligence and performance. The network offers an open interface
that enables software-defined networking, providing an industry-leading network solution.
The foundation of Cisco One Network includes the following:
 Converged wired and wireless infrastructure: One physical infrastructure that increases
business agility and scalability and delivers greater operation efficiency.
 Consistent networkwide intelligence and operations: One common set of network
capabilities and context-aware intelligence for policy, visibility, analytics, and detailed
control of quality of service (QoS) across the entire wired and wireless network
infrastructure. This feature provides simplicity and a consistent user experience.
 Integration with Cisco Open Network Environment (ONE): The industry’s first
common interface across wired and wireless networks, providing a blueprint for delivery of
a programmable data plane with the Cisco ONE Platform Kit (onePK) for the enterprise
campus, support for software-defined networking, and enhanced business agility.
• Differentiating capabilities at • WLC 5760
FCS
- Optimized for 802.11ac
deployments - 60 Gbps wireless throughput
- Distributed forwarding and - Up to 1000 APs
services
- Up to 12,000 clients
- 802.11n Gen2 access points
- Common IOS and feature set • Catalyst 3850
- Granular QoS
- Downloadable ACLs
- EEM/TCL scripting, secure copy - 40 Gbps wireless throughput
- Flexible NetFlow v9 - Up to 50 APs per stack
- Multiple LAGs - Up to 2000 clients per
switch/stack
- Right-to-use license model
Cisco One Network includes the following core products:
Cisco Catalyst 3850 Series Switch

The Cisco Catalyst 3850 Series Switch is a converged access switch for wired and wireless
networks. This series brings the best of wired and wireless together by supporting wireless
tunnel termination and full wireless LAN controller capabilities.
The main features of the Cisco Catalyst 3850 Series include the following:
 Converged wired and wireless access: The Cisco Catalyst 3850 Series brings the excellence
of Cisco IOS Software to wireless networking by extending wired infrastructure features,
resiliency, detailed QoS control, and scalability to wireless networks. This series can
provide one common set of network capabilities and context-aware intelligence across
wired and wireless access for operation simplicity, accelerated service deployment, and
easier change management. The Cisco Catalyst 3850 Series provides integrated wireless
controller capabilities with 40-Gb/s wireless throughput, support for 50 access points and
2000 wireless clients per switch and stack, and support for IEEE 802.11ac.
 Distributed intelligent services: The Cisco Catalyst 3850 Series delivers rich common
intelligent services across wired and wireless networks for security and policy, application
visibility and control, network resiliency, smart operations, and more. Only the Cisco
Catalyst 3850 Series enables multilevel QoS based on detailed information such as the
service set ID (SSID), client, radio, and application and fair share policies for wireless
networks.
 The Cisco Catalyst 3850 Series currently offers the industry’s highest 480-Gb/s stacking
bandwidth, meeting network demand, including the demands of gigabit desktop and IEEE
802.11ac wireless technologies. The series delivers advanced capabilities such as high-
performance 24- and 48-port Gigabit Ethernet switching, 480-Gb/s stacking, full Enhanced
Power over Ethernet Plus (PoE+), and Cisco Flexible NetFlow on all ports as well as many
other features.
 Foundation for Cisco ONE with programmable ASIC: The core of the Cisco Catalyst 3850
Series is the new ASIC with programmability for future features and intelligence, providing
investment protection. The new ASIC provides a foundation for converged application
programming interfaces (APIs) across wired and wireless networks, software-defined
networking support, and Cisco onePK.
Cisco 5760 Wireless LAN Controller

Cisco 5760 Wireless LAN Controller (WLC) is an industry leading, standalone appliance that
supports both centralized and converged wireless infrastructure. It is designed for 802.11ac
networks with maximum performance and services at scale, which is combined with high
availability for mission-critical wireless networks.
The Cisco 5760 is the first controller that is based on Cisco IOS Software. It provides the
industry’s highest wireless throughput (60 Gb/s) and consistent networkwide intelligence and
operations. The Cisco 5760 supports highly scalable mobility architecture and a large Layer 3
roaming domain, with up to 72,000 access points and 864,000 wireless clients.
Cisco Catalyst 6500 Series WiSM2 Software Enhancements

Cisco Catalyst 6500 Series Wireless Services Module 2 (WiSM2) is an integrated switch blade
for Cisco Catalyst 6500 Series Switch chassis. This module is an optional alternative to the
Cisco 5760 to support the scalable Cisco Unified Access mobility architecture.
FCS
Q4 CY13
• Catalyst 6880-X • Catalyst 6807-XL

- Semi-modular fixed form factor - High-density modular form factor
- Only 4.5 RU height (smaller than - Only 10 RU height (smaller than
6504-E) 6506-E)
- 80 to 220 Gbps per half slot - 220 to 880 Gbps per slot capable
capable - Compatible with Sup2T, 6900,
- 16 to 80 x 1/10GE Ethernet port 6800, 6700, and latest service
density modules
- The most feature-rich platform in - 100% Catalyst 6500 IOS feature-
fixed class with all 3000+ Catalyst compatible
6500 features - Next gen. ASIC-compatible for
- Highest 1G/10G port density with unified campus switching (future)
rich BGP and MPLS in Cisco’s
entire switching portfolio
This figure describes the capabilities of the new Catalyst 6880-X and 6807-XL.
Note the highlighted items as they are the two most important things to make sure that
customers understand when discussing the new hardware.
Cisco Unified Access Wired Architecture High
Availability Features
This topic describes the purpose and use of the redundancy features.
• Cisco StackPower technology provides power stacking among stack

members for power redundancy.
• Dual redundant, modular power supplies and three modular fans provide
redundancy.
• Uses stacking technology called Cisco StackWise-480, supporting SSO.
Cisco StackPower Technology

The Cisco Catalyst 3850 Series uses the Cisco StackPower technology present on the Cisco
Catalyst 3850 Series. StackPower is innovative powers interconnect system that allows the
power supplies in a stack to be shared as a common resource among all the switches. Cisco
StackPower unifies the individual power supplies installed in the switches and creates a pool of
power, directing that power where it is needed. Up to four switches can be configured in a
StackPower stack with the special connector at the back of the switch using the StackPower
cable, which is different from the StackWise-480 cables.
StackPower can be deployed in either power-sharing mode or redundancy mode. In power-
sharing mode, the power of all the power supplies in the stack is aggregated and distributed
among the switches in the stack. In redundant mode, when the total power budget of the stack is
calculated, the wattage of the largest power supply is not included. That power is held in
reserve and used to maintain power to switches and attached devices when one power supply
fails, enabling the network to operate without interruption. Following the failure of one power
supply, the StackPower mode becomes power-sharing. StackPower allows customers to simply
add one extra power supply in any switch of the stack and either provide power redundancy for
any of the stack members or simply add more power to the shared pool. StackPower eliminates
the need for an external redundant power system or installation of dual power supplies in all of
the stack members. StackPower is available in LAN Base license level (or higher). For LAN
Base, cables need to be purchased separately.
Dual Redundant Modular Power Supplies

The Cisco Catalyst 3850 Series Switches support dual redundant power supplies. The switch
ships with one power supply by default. The second power supply can be purchased when
ordering the switch or later. If only one power supply is installed, it should always be in power
supply bay 1. The switch also ships with three field-replaceable fans.
Different power supplies available in these switches provide different available PoE power (no
PoE power, 435W, and 800W).
Cisco StackWise-480 Technology

Cisco StackWise-480 technology is built on the highly successful industry-leading StackWise
technology, which is a premium stacking architecture. StackWise-480 has a stack bandwidth of
480 Gb/s. StackWise-480 uses Cisco IOS Software Stateful Switchover (SSO) for providing
resiliency within the stack. The stack behaves as a single switching unit that is managed by an
active switch that is 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, and 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. A working stack can accept new members or
delete old ones without service interruption. StackWise-480 creates a highly resilient single
unified system of up to four switches, providing simplified management using a single IP
address, single Telnet session, single CLI, autoversion checking, autoupgrading, auto-
configuration, and more. StackWise-480 also enables local switching in Cisco Catalyst 3850
Series Switches.
In addition to StackWise-480 and StackPower, the Cisco Catalyst 3850 Series supports high-
availability features including but not limited to the following:
 Cross-Stack EtherChannel provides the ability to configure Cisco EtherChannel technology
across different members of the stack for high resiliency.
 Flexlink provides link redundancy with convergence time less than 100 ms.
 IEEE 802.1s/w Rapid Spanning Tree Protocol (RSTP) and Multiple Spanning Tree
Protocol (MSTP) provide rapid spanning-tree convergence independent of spanning-tree
timers and also offer the benefit of Layer 2 load balancing and distributed processing.
Stacked units behave as a single spanning-tree node.
 Per-VLAN Rapid Spanning Tree Plus (PVRST+) allows rapid spanning-tree reconvergence
on a per-VLAN spanning-tree basis, without requiring the implementation of spanning-tree
instances.
 Switch-port autorecovery (Err-disable) automatically attempts to reactivate a link that is
disabled because of a network error.
Stacking is 3 x 40 Gb/s in each direction, giving 240 Gb/s of total bandwidth. By employing
spatial reuse, Cisco states 480 Gb/s can be achieved in optimal circumstances by using two
parallel sections of the ring simultaneously. The spatial-reuse technology enables multipath
parallel switching across each stack ring to double the throughput.
• Redundant supervisor configurations
increase system availability
- Increase the system MTBF
- Reduce MTTR
- Reduce downtime associated with software
upgrades
- Deterministic convergence independent of
the route table size
• SSO and Cisco NSF technologies avoid
network convergence events
• ISSU and EFSU reduce downtime
associated with software upgrade
Catalyst 6500 Supervisor 2T
Availability is the degree to which a system resists degradation or interruption of service as a

consequence of the failure of one or more components. Different statistical models exist to
measure the availability of a given system. One method calculates availability by amortizing
the mean time to repair (MTTR) over the mean time between failures (MTBF). This method
can be expressed mathematically as a fraction of the MTBF divided by the sum of MTBF and
MTTR. With this model, 99.999 percent availability equates to five minutes of downtime per
year and 99.9999 percent availability equates to 30 seconds of downtime per year. Although the
definition of high availability changes depending on customer requirements and deployment
scenarios, the accepted benchmark for availability has become 99.999 percent, also known as
five 9s.
Catalyst 4500 and 6500 Series Switches are deployed in many of the most critical parts of
enterprise and service provider networks. Therefore, a Catalyst 4500 or 6500 Series Switch
must achieve close to 100 percent availability. The platforms have evolved over the years to
achieve higher levels of availability by providing more advanced resiliency mechanisms.
Examples of high-availability device level redundancy include redundant supervisors,
redundant switches, redundant power supplies, redundant fans, and virtual switching systems.
Examples of high-availability networkwide redundancy mechanisms include redundant links,
EtherChannel technology, Spanning Tree Protocol (STP), UniDirectional Link Detection
(UDLD) protocol, and First Hop Redundancy Protocol (FHRP).
When two supervisors are installed in the Catalyst 4500 or 6500, one will act as the active
supervisor and the other acts as the standby supervisor. The active supervisor is running the
active control plane and is running the data plane as well, running all the switching
components. The standby supervisor is waiting to take over if needed. It is not used in the
active forwarding path. There is no load balancing of the switch fabrics. It is true 1:1
redundancy.
When a supervisor switchover occurs and Cisco Nonstop Forwarding (NSF) is enabled, SSO
maintains all the directly connected routes through the out-of-band synchronization, so the
neighbors are not even aware of the switchover. The Cisco NSF-capable router signals Cisco
NSF-aware routing peers of a routing protocol restart. Cisco NSF-aware routers detect the
restarting router and assist in re-establishing full adjacency as well as maintain forwarding to
and from the restarting router.
Cisco IOS In-Service Software Upgrade (ISSU) enables a Catalyst 4500 with dual supervisors
to virtually eliminate planned outages for full feature software upgrades. It provides the means
to upgrade or, if needed, downgrade the Cisco IOS Software in a redundant Cisco Catalyst
4500 supervisor system without incurring a service outage. ISSU adds additional functionality
to the Cisco Catalyst 4500 high-availability capabilities that are already provided by SSO and
Cisco NSF. Since the underlying technology supporting ISSU is based on the SSO architecture,
the downtime that is associated during a switchover is less than 200 ms. ISSU is a user-initiated
and user-controlled process through a set of executive-level CLI commands that are issued in a
specific order to upgrade or downgrade a Cisco IOS Software image running on a Cisco
Catalyst 4500 dual-supervisor configuration. This process differs from “hitless” software
upgrades in that it provides the ability to do a hitless “full feature” upgrade rather than just a
system patch.
Enhanced Fast Software Upgrade (eFSU) enables an increase in network availability by
reducing the downtime that is caused by software upgrades. eFSU reduces the downtime by
bringing up the standby supervisor engine in SSO mode even when the active and the standby
supervisor engines have different software versions, or with Virtual Switching System (VSS)
configured, when the supervisor engines in the two chassis have different software versions.
Keep in mind that during an eFSU upgrade, modules are restarted or reset after the switchover
that occurs between the supervisor engines. In VSS mode, the effect of the module restart is
minimized when devices are dual homed to the VSS.
• SSO allows redundant supervisor engines to run a stateful IOS and
stateful applications to exchange state to minimize outage at the time of
a switchover from active to standby supervisor.
- The redundant supervisor engine is fully initialized.
- Upon switchover, physical links stay up
and protocols do not reset.
- Traffic interruption is sub second
(less than 200 ms).
- IOS images need to be identical.
Functions like Cisco IOS ISSU depend on the facilities that are provided by SSO. Catalyst
4500 E-Series Switches allow a redundant supervisor engine to quickly take over operation of
the switch if the active supervisor engine fails. Supervisor engine redundancy is enabled by
running the redundant supervisor engine in SSO operating mode. With supervisor engine
redundancy enabled, if the active supervisor engine fails, Cisco IOS ISSU commands are
issued, or a manual switchover is performed, and the redundant supervisor engine becomes the
active supervisor engine. The redundant supervisor engine is automatically initialized with the
startup configuration of the active supervisor engine. This automatic initialization shortens the
switchover time from 30 seconds or longer in Route Processor Redundancy (RPR) mode to less
than 200ms in SSO mode.
When a redundant supervisor engine runs in SSO mode, the engine starts up in a fully
initialized state. The engine then synchronizes with the persistent configuration and the running
configuration of the active supervisor engine. The engine subsequently maintains the state of
SSO client protocols. All changes in hardware and software states for features that support SSO
are kept in sync. Consequently, the engine offers almost zero interruption to Layer 2 sessions in
a redundant supervisor engine configuration.
Because the redundant supervisor engine recognizes the hardware link status of every link,
ports that were active before the switchover remain active, including the uplink ports. However,
because uplink ports are physically on the supervisor engine, the ports are disconnected if the
supervisor engine is removed. If the active supervisor engine fails, the redundant supervisor
engine becomes active. This newly active supervisor engine uses Layer 2 switching information
that exists to continue forwarding traffic. Unless Cisco NSF is configured, Layer 3 forwarding
is delayed until the routing tables have been repopulated in the newly active supervisor engine.
• Packet forwarding is not disrupted during Cisco NSF/SSO failover.
• Routing adjacencies stay up.
• Routing converges while packet forwarding continues.
X
Forwarding table
Standby (SSO synched)
Graceful restart Graceful restart
Routing updates Routing updates
Forwarding table
Standby (SSO synched)
Cisco NSF works with SSO to minimize the amount of time that the network is unavailable
following a supervisor engine switchover.
When switching from the active supervisor engine to the standby supervisor engine, the switch
loses connectivity to its routing peers.
Since the routing peers are Cisco NSF-aware and the interfaces to the Cisco NSF-capable
switch are still up, they keep sending data packets to the Cisco NSF-capable switch.
When the supervisor switchover is done, the new supervisor engine will conduct a graceful
restart for all of the configured routing protocols and therefore receive all of the routing
information from its peers. After that, the forwarding information base (FIB) will be updated
and normal routing operation continues.
Cisco NSF uses capabilities of Layer 3 routing protocols and Cisco Express Forwarding to
prevent disruption of traffic forwarding. The Border Gateway Protocol (BGP), Open Shortest
Path First (OSPF), and Enhanced Interior Gateway Routing Protocol (EIGRP) routing protocols
have been enhanced with Cisco NSF capability and awareness. That enhancement means that
routers running these protocols can detect a switchover and take the necessary actions to
continue forwarding network traffic and to recover route information from the peer devices.
The Intermediate System-to-Intermediate System (IS-IS) protocol can be configured to use
state information that has been synchronized between the active and the redundant supervisor
engine. The protocol can recover route information following a switchover instead of
information that was received from peer devices.
Traditional Campus Design VSS Campus Design VSS Campus Design
Optimized Simplified
Network Operation
• Complex network design • Optimized network design • Simplified system

and operation • Double switching capacity operation
• Underutilize network • Deterministic application • Single neighbor and
resources and network performance network per layer
• Suboptimal application and • Simplified and highly
network performance redundant network
topologies
* MEC is used to eliminate the loops
Network operators increase network reliability by configuring redundant pairs of network

devices and links. Redundant network elements and redundant links can add complexity to
network design and operation. Virtual switching simplifies the network by reducing the number
of network elements and hiding the complexity of managing redundant switches and links.
A VSS combines a pair of Catalyst 4500 or 6500 Series Switches into a single network
element. The VSS manages the redundant links, which externally act as a single port channel.
The VSS simplifies network configuration and operation by reducing the number of Layer 3
routing neighbors and by providing a loop-free Layer 2 topology.
VSS functionality is used to combine two Catalyst 4500 or 6500 Series Switches into a single
network element using the Supervisor Engine 7-E, Supervisor Engine 720-10G (VSS 1440), or
Supervisor Engine 2T (VSS 4T). This functionality is achieved by forming a virtual switch link
(VSL) between two chassis, each containing this supervisor engine.
Cisco Catalyst 4500 or 6500 that operates Defines two Cisco Catalyst 4500s or 6500s that are
as the active control plane for the VSS participating together as a VSS
Virtual Switch Domain

Virtual Switch Primary Virtual Switch Secondary
Active Control Plane Hot Standby Control Plane

Active Data Plane Active Data Plane
Virtual Switch Link
Special link bundle joining two Cisco Catalyst

4500s or 6500s, allowing them to operate as Cisco Catalyst 4500 or 6500 that operates as the
a single logical device hot standby control plane for the VSS
Virtual Switch Identifiers

 A virtual switch domain ID is allocated during the migration process and represents the
logical grouping of the two physical chassis within a VSS. It is possible to have multiple
virtual switch domains throughout the network. The configurable values for the domain ID
are 1 to 255. It is always recommended to use a unique virtual switch domain ID for each
virtual switch domain throughout the network.
 A switch identifier is a unique number (1 or 2) for each switch to determine the role within
the VSS.
Virtual Switch Link

The VSL is the special link bundle that binds the two chassis of a VSS together. With the
Catalyst 4500, the VSL can be either multi-1G or multi-10G EtherChannel. With the Catalyst
6500, the VSL must be a multi-10G EtherChannel.
Virtual Switch Roles

When a VSS is created or restarted, the peer chassis negotiate their roles. One chassis becomes
the active chassis and the other chassis becomes the standby.
The active chassis controls the VSS and runs the Layer 2 and Layer 3 control protocols for the
switching modules on both chassis. The active chassis also provides management functions for
the VSS, such as line card online insertion and removal (OIR) and the console interface. The
active and standby chassis perform packet forwarding for ingress data traffic on their locally
hosted interfaces. However, the standby chassis sends all control traffic to the active chassis for
processing.
Control and Data Plane

In virtual switch mode, while there is a unified control plane, both data planes are active.
Therefore, each can actively participate in the forwarding of data.
Since both data planes are active, each forwarding engine has a full copy of the forwarding
tables and security and QoS policies in hardware so that each can make a fully informed local
forwarding decision.
Router MAC Address

In a VSS, since there is only a single routing entity, there is also only one single router MAC
address. The MAC address that is allocated to the VSS is negotiated at system initialization.
Regardless of either switch being brought down or up, the same MAC address will be retained
so that neighboring network nodes and hosts do not need to resubmit an Address Resolution
Protocol (ARP) request (gratuitous ARP) for a new address.
• MEC is a Layer 2 multipathing technology.
• MEC and VSS bring powerful and very effective changes to the campus
topology. The following are three key benefits:
- Eliminates loops in multilayer design.
- Doubles the available bandwidth for forwarding.
- Improves availability of delay-sensitive applications.
Active Standby
VSL
MEC
Physical Topology Logical Topology
Traditional EtherChannel aggregates multiple physical links between two switches.

Multichassis EtherChannel (MEC) is a Layer 2 multipathing technology. This form of
EtherChannel allows a connected node to terminate the EtherChannel across the two physical
Cisco Catalyst 6500 Series Switches that make up the VSS leading to creating simplified loop-
free Layer 2 topology. VSS allows for distributed forwarding and a unified control plane so that
the MEC appears as a single port channel interface existing on both the active and hot-standby
switches. Even though the access layer is connected to a distinct physical chassis via two
physical links, from an access-layer switch perspective, this port-channel connection enables a
single logical link that is connected to a single logical switch (referred to as VSS with MEC).
The MEC and VSS bring powerful and very effective changes to the campus topology. The
following are two key benefits:
 Eliminates loops in multilayer design. Traditionally, spanning VLANs over multiple closets
would create an STP-looped topology because one of the uplinks would be blocked by
STP. MEC with VSS eliminates loops in the campus topology which is because STP now
operates on the EtherChannel logical port and each physical switch appears to be connected
via a single logical link to a single logical switch.
 Doubles the available bandwidth for forwarding. MEC replaces spanning tree as the means
to provide link redundancy. This means that all physical links under the MEC are available
for forwarding traffic. The STP can no longer block individual links since its database does
not have those links available to calculate a loop-free path. For the network with a looped
topology, the total forwarding capacity is half the available bandwidth of physical links.
VSS with MEC makes all links available for forwarding and thus doubles the bandwidth
available.
Note MEC configuration is only possible in the VSS. However, access-layer switches requiring
connectivity to the VSS are configured with traditional EtherChannel interfaces.
• There is a default redundancy mechanism between the two VSS chassis
and their associated supervisor is NSF/SSO.
• Cisco NSF and SSO must be enabled on both for Catalyst 4500 VSS to
work.
• A mismatch of information between the active and standby results in the
following:
- For the Catalyst 4500, the standby does not boot.
- For the Catalyst 6500, the standby boots in RPR mode; RPR is the
predecessor to SSO.
Switch1 VSL Switch2
Code Version 1 Code Version 2
NSF/SSO
Active Standby
VSS functionality is used to combine two Catalyst 4500 or 6500 Series Switches into a single
network element which is achieved by forming a VSL between two chassis, each containing the
supervisor engine.
From a redundancy point of view, it does not matter whether the supervisor engines are in one
or two chassis. The redundancy mechanism is, as discussed before, SSO with Cisco NSF. The
keepalives being sent over the fabric when two supervisor engines are installed in one chassis
are sent now over the VSL. Cisco NSF works the same way as in a single chassis and has to be
configured the same way.
RPR was the first feature that was introduced in IOS Software for the Catalyst 6500 Series
Switch. RPR manages the redundant supervisor hardware to provide redundant network
services through automatic failover to a standby supervisor if the active supervisor fails. RPR
failover times vary based on the configuration of the Catalyst 6500 Series Switch. At the
conclusion of the failover time interval, the standby supervisor is fully activated and switching
operations can continue.
In RPR mode, the startup configuration and boot registers are synchronized between the active
and standby supervisors, but the standby supervisor is not yet fully initialized. When a failover
occurs, the standby supervisor automatically becomes active, but must first complete the boot
process. Additionally, all line cards are reloaded and the hardware is reprogrammed.
Note RPR mode is not supported with Catalyst 4500 VSS.
SSO establishes one supervisor engine as the active supervisor and designates the other
supervisor as the hot standby supervisor. SSO synchronizes the information between the two
supervisors. When the active supervisor fails, is removed from the switch, or is manually shut
down for maintenance, a switchover occurs from the active to the redundant supervisor. In
networking devices running SSO, the FIB and adjacency entries are preserved during an SSO
switchover, so that Layer 2 and Layer 3 forwarding can continue after a switchover has
occurred.
Cisco NSF works with SSO to minimize the amount of time a network is unavailable to its
users following a switchover. The main objective of Cisco NSF is to continue forwarding IP
packets following a route processor (RP) switchover.
Usually, when a networking device restarts, all routing peers of that device detect that the
device went down and then came back up. This transition results in what is called a routing
flap. Cisco NSF helps to suppress routing flaps in SSO-enabled devices, thus reducing network
instability. Cisco NSF allows for the forwarding of data packets to continue along known routes
while the routing protocol information is being restored following a switchover. The ability of
line cards to remain up through a switchover and to be kept current with the FIB on the active
RP is the key to Cisco NSF operation. The Cisco NSF feature has several benefits, including
the following:
 Improved network availability: Cisco NSF continues forwarding network traffic and
application state information so that user session information is maintained after a
switchover.
 Overall network stability: Network stability may be improved with the reduction in the
number of route flaps that had been created when routers in the network failed and lost
their routing tables.
 Neighboring routers do not detect link flapping: Because the interfaces remain up across
a switchover, neighboring routers do not detect a link flap (that is, the link does not go
down and come back up).
 Prevents routing flaps: Because SSO continues forwarding network traffic in the event of
a switchover, routing flaps are avoided.
 No loss of user sessions: User sessions are established before the switchover is maintained.
Note Cisco NSF and SSO must be configured for Catalyst 4500 VSS to work.
• Redundant supervisors fully boot Cisco IOS to ICHS redundancy mode.
• All information is in sync between VSS active and VSS hot-standby as
well as between in-chassis active and in-chassis hot standby
supervisors.
• All uplinks on all supervisors are active.
• After active supervisor failure, the hot-standby supervisor takes over.
• If VSS active supervisor fails, the VSS hot-standby becomes the VSS
active.
Switch 1 Switch 2
VSL
VSS Active VSS Hot-Standby
In-Chassis Hot Standby In-Chassis Hot Standby
SSO Sync
SSO SSO
Sync Sync
VSS Quad-Supervisor Uplink Forwarding

Cisco IOS Software Release 15.1(1) SY1 introduces support for VSS quad supervisor SSO
with the Supervisor 2T.
When a VSS with quad-supervisor SSO is used, the In-Chassis Hot-Standby (ICHS) supervisor
engine acts the same as a hot-standby supervisor in a standalone chassis. During the bootup,
once the chassis level role is resolved, the ICHS downloads the image from the In-Chassis
Active (ICA) supervisor engine.
These ICHS supervisors can also be used to forward traffic on the uplink ports, therefore
enabling all four supervisors in a VSS system to actively forward traffic under normal
conditions. Furthermore, the additional supervisors can act as hot-standby supervisors within
each chassis which provides resilient network connectivity to single-homed devices and
maximum bandwidth availability to both upstream and downstream connected devices.
From a control plane point of view there is only one supervisor engine active. Between the
chassis, the high availability mechanism is the same as with dual supervisor engines. From a
data plane perspective, all of the uplink ports on all four supervisor engines are active and
forwarding.
The switchover mode of the supervisor engines can be verified by entering the show module
command.
The procedure when the active VSS supervisor fails is as follows:
1. Active VSS supervisor in switch 1 incurs a hardware failure.
2. SSO fails over to the hot-standby supervisor in switch 2, making it the new VSS active.
3. SSO fails over to the ICHS supervisor in switch 1, making it the new VSS hot-standby.
4. All bandwidth is available during the SSO switchover.
• Software maintenance windows
are significant causes of
downtime.
• On redundant systems, the IOS
ISSU process allows the running
IOS software to be upgraded
while packet forwarding
continues. 03.01.00.SG
• The IOS ISSU mechanism 03.02.00.SG
leverages architecture for high
availability—NSF/SSO <200 ms.
• Cisco Catalyst 4500 uses full
image upgrades for the addition of
new features, defects, and
PSIRTs.
• IOS ISSU increases network
availability and reduces downtime
caused by planned upgrades. Targets Planned Downtime
• There is an 18-month rolling Due to Software Upgrades
window.
Cisco IOS ISSU is available on the Catalyst 4500 Series and allows customers to virtually
eliminate planned outages for full feature software upgrades. ISSU provides the means to
upgrade or, if needed, downgrade the Cisco IOS Software in a redundant Catalyst 4500
supervisor system without incurring a service outage.
IOS ISSU adds functionality to the Catalyst 4500 high-availability capabilities that are already
provided by SSO and Cisco NSF. Since the underlying technology supporting IOS ISSU is
based on the SSO architecture, the downtime that is associated with a switchover is less than
200 ms.
IOS ISSU is a user-initiated and user-controlled process that is executed through a set of
executive-level CLI commands. Those commands are issued in a specific order to upgrade or
downgrade a Cisco IOS Software image running on a Catalyst 4500 dual-supervisor
configuration. The process differs from hitless software upgrades in that it provides the ability
to do a hitless full feature upgrade rather than just a system patch.
1. Standby supervisor in slot
issu changeversion bootflash:New_Image quick 6 is reset.
2. Boots with new image.
3. Initiate SSO between
active supervisor in slot 5
and standby supervisor in
slot 6.
4. Active supervisor in slot 5
Slot 5 New Image resets.
Slot 6 New Image 5. Standby supervisor in slot
6 takes over as active
supervisor.
6. Supervisor in slot 5 boots
up as a standby supervisor
with the new image.
7. Completes the IOS ISSU
Active Standby
process.
Supervisor Supervisor
The IOS ISSU process in Cisco IOS XE is a single-line command. The process starts with
rebooting the standby supervisor with the new image and performing an SSO, which means that
SSO mode is required for performing a Cisco IOS ISSU. Also, there is no PoE loss during this
switchover. The data loss is expected to be less than 200 ms.
Once the standby supervisor assumes the active role, the other supervisor engine reboots with
the new image. Both supervisors come up in SSO mode. In case there is any failure during the
process, then the IOS ISSU process automatically reverts to the old IOS image and alerts the
user via syslog.
Use changeversion Command to Automate an IOS ISSU Upgrade

You can use the issu changeversion command to perform a one-step IOS ISSU upgrade.
The following are prerequisites:
 Ensure that the new Cisco IOS XE Software image is present in the file system of both the
active and standby supervisor engines. Also, ensure that appropriate boot parameters
(BOOT string and config-register) are set for the active and standby supervisor engines.
 Optionally, perform additional tests and commands to determine the current state of peers
and interfaces for later comparison.
 Ensure the system (both active and standby supervisor engines) is in SSO redundancy
mode. If the system is in RPR mode, you can still upgrade the system using the IOS ISSU
CLI commands, but the system will experience extended packet loss during the upgrade.
Refer to the section in this document on SSO for more details on how to configure SSO
mode on supervisor engines.
 For IOS ISSU to function, the IOS XE Software image file names on the active and
standby supervisor engines must match.
The following example shows how to initiate an ISSU upgrade process using the issu
changeversion command on slot number 5, the slot for the current active supervisor engine.
The show issu state detail and show redundancy command output is included to show the
supervisor state before and after the upgrade procedure.
Note The success messages included in the output below are displayed after some delay
because the IOS ISSU upgrade procedure progresses through the IOS ISSU states.
Switch# show issu state detail

Slot = 5
RP State = Active
ISSU State = Init
Operating Mode = Stateful Switchover
Current Image = bootflash:x.bin
Pre-ISSU (Original) Image = N/A
Post-ISSU (Targeted) Image = N/A
Slot = 6
RP State = Standby
ISSU State = Init
Current Image = bootflash:x.bin
Switch# show redundancy
Redundant System Information :
------------------------------
Available system uptime = 12 minutes
Switchovers system experienced = 0
Standby failures = 0
Last switchover reason = none
Hardware Mode = Duplex
Configured Redundancy Mode = Stateful Switchover
Operating Redundancy Mode = Stateful Switchover
Maintenance Mode = Disabled
Communications = Up
Current Processor Information :
------------------------------
Active Location = slot 5
Current Software state = ACTIVE
Uptime in current state = 9 minutes
Image Version = Cisco IOS Software, IOS-XE
Software, Catalyst 4500 L3
Switch Software (cat4500e-UNIVERSALK9-M), Version
03.00.00.1.68 CISCO UNIVERSAL
DEVELOPMENT K10 IOSD TEST VERSION
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Sun 29-Aug-10 03:57 by gsbuprod
Configuration register = 0x2920
Peer Processor Information :
------------------------------
Standby Location = slot 6
Current Software state = STANDBY HOT
Switch# issu changeversion bootflash:y.bin
% 'issu changeversion' is now executing 'issu loadversion'
% issu loadversion executed successfully, Standby is being
reloaded
% changeversion finished executing loadversion, waiting for
standby to reload and reach
SSO ...
Note Standby reloads with the target image.
.....
.....
*Feb 25 20:41:00.479: %INSTALLER-7-ISSU_OP_SUCC: issu
changeversion is now executing
'issu runversion'
changeversion successfully executed
'issu runversion'
Note Switchover occurs.
......
Look at the console of new active supervisor engine.
*Feb 25 20:47:39.859: %RF-5-RF_TERMINAL_STATE: Terminal state
reached for (SSO)
changeversion is now executing
'issu commitversion'
.....
Note The new standby supervisor engine reloads with the target image. The command
changeversion is successful when SSO terminal state is reached.
*Feb 25 20:54:16.092: %HA_CONFIG_SYNC-6-BULK_CFGSYNC_SUCCEED:

Bulk Sync succeeded
*Feb 25 20:54:16.094: %RF-5-RF_TERMINAL_STATE: Terminal state
reached for (SSO)
Switch#
Switch# show issu state detail
Slot = 6
RP State = Active
ISSU State = Init
Current Image = bootflash:y.bin
Slot = 5
RP State = Standby
ISSU State = Init
Current Image = bootflash:y.bin
Switch# show redundancy
Redundant System Information :
------------------------------
Available system uptime = 12 minutes
Switchovers system experienced = 0
Standby failures = 0
Last switchover reason = none
Hardware Mode = Duplex
Configured Redundancy Mode = Stateful Switchover
Operating Redundancy Mode = Stateful Switchover
Maintenance Mode = Disabled
Communications = Up
Current Processor Information :
------------------------------
Active Location = slot 6
Current Software state = ACTIVE
Peer Processor Information :
------------------------------
Standby Location = slot 5
Current Software state = STANDBY HOT
Cisco Catalyst Smart Operations
This topic describes Cisco Catalyst Smart Operations.
Smart Install
Flexible NetFlow
Auto Smartports
IP SLAs
Auto-QoS
Cisco Catalyst
SmartOperations
Mediatrace
ERSPAN Flexible NetFlow
Smart Call Home IP SLAs
Protocol Analyzer EEM
TDR, GOLD
Organizations today are looking for ways to increase productivity and efficiency. Industries
such as health care, education, government, manufacturing, financial, and banking are all facing
the same challenge of reduced budgets. As a result, new and innovative practices are needed to
run and grow the business.
As networks evolve to better support data, voice, video, and building control, they become
critical to operation and innovation. The goal for all business is nonstop, constant
communications and maximum uptime for network services. Yet downtime risks exist,
stemming from a range of causes that includes human error such as incorrect design,
misconfigurations, planned software and hardware upgrades, and unplanned hardware or
software faults. When outages occur, companies suffer lost business, lowered customer
satisfaction, and lower productivity.
Ultimately, implementing the right intelligence in your network can enable your organization to
meet your business goals.
In this topic the focus will be on the deployment phase of lifecycle management representing
the following:
 Cisco Smart Install is a zero-touch deployment solution that allows new or replacement
switches to be automatically imaged and configured over the network.
 Cisco Auto Smartports automatically configures switch ports that are based on the
connected device type, eliminating the need to allocate fixed ranges of switch ports for
specific device types or manually reconfiguring ports each time a device is added or
removed.
 Cisco Auto-QoS simplifies generating and applying quality of service configurations
across the network, ensuring priority treatment of voice, video, and real-time applications.
The following features are part of the planning, monitoring, and troubleshooting phases:
 Cisco Flexible NetFlow provides detailed network traffic statistics, which allows
administrators to identify anomalies, intelligently manage capacity, and plan upgrades.
 Cisco IP Service-Level Agreements (SLAs) assess network performance and readiness to
deploy new IP services such as voice, video, or virtual desktop infrastructure (VDI).
 Cisco Embedded Event Manager (EEM) is a scripting system that can detect network
events and automatically take a customized action, for example executing commands or
sending an email.
 Cisco Smart Call Home communicates network status information to the Cisco Technical
Assistance Center (TAC) to enable proactive service interventions.
 Cisco Generic Online Diagnostics (GOLD) runs diagnostic tests to detect preliminary
warnings of hardware failure, allowing network administrators to prevent potential outages.
 Cisco Mediatrace monitors voice, video, and other real-time traffic as it traverses the
network allowing administrators to pinpoint bottlenecks that degrade performance.
 Cisco Encapsulated Remote Switched Port Analyzer (ERSPAN) captures traffic on
switch ports or VLANs and sends it across a Layer 3-routed network for remote analysis
and diagnostics. The port can be configured to be monitored and then the traffic that is sent
or received on that port can be redirected on the port on the same switch Switched Port
Analyzer (SPAN) or on a different switch Remote Switched Port Analyzer (RSPAN) or can
be directed to different switches, which provide remote monitoring of multiple switches
across your network (ERSPAN). ERSPAN uses a Generic Routing Encapsulation (GRE)
tunnel to carry traffic between switches.
 Protocol Analyzer leverages the Wireshark open-source packet capture platform to collect
and interpret traffic on an interface, enabling sophisticated protocol analysis and
debugging.
 Time Domain Reflectometer (TDR) uses switch hardware to test the integrity, length, and
connectivity of Ethernet cables to enable rapid debugging of wiring issues.
Director Catalyst 6K
Access
Switches
Auto-QoS Auto Smartports Smart Install

Automatically Creates Relevant Plug and Play for End Devices Zero-Touch Deployments
QoS Configuration and Maintenance
New Configuration New Device Attached New Switch Connected
No in-depth QoS knowledge Port configuration: Applied Software image downloaded

needed QoS policy: Enforced Configuration automatically
VoIP feature simplifies QoS applied
Security policy: Enforced
implementation
Can use existing Cisco
commands to modify the
automatically generated
configuration
Smart Install
Smart Install can deliver substantial IT cost savings by providing zero-touch deployment,
replacement, and automatic configuration backup for Cisco Catalyst switching products. Smart
Install uses a director device, which can be a 6500 Series Sup 2T, 4500E Sup 7-E, 4500E Sup
7L-E, 4500 Sup 6-E, 4500 Sup 6L-E, 3850, 3750-X, 3750-E, 3750-G, 3750V2-24FS, 3560-X,
3560-E, 3560-G, 3560V2-24S, 3560C, or Cisco Integrated Services Router (ISR). Optionally,
Smart Install uses an external server to store configurations and appropriate Cisco IOS
Software images for client switch groups. When a new or replacement switch is added to the
group, the director discovers it and pushes the appropriate configuration and software image to
it. This action eliminates manual configuration of new hardware and creates a single point of
management. Smart Install also helps with configuration backup of all switches in the network.
Auto Smartports
Auto Smartports enables true plug-and-play deployment of Cisco endpoint devices by
automatically applying port configuration policies, QoS policies, and security policies that are
based on Cisco best practices. Users can create their own Auto Smartports macros to extend
this functionality more broadly and to customize settings to meet their specific needs. By
combining Auto Smartports with Smart Install, users can enable zero-touch deployment of both
their switching infrastructure and endpoints.
Cisco Catalyst 4500 and 3850 Series Switches feature Auto Smartports. The feature is expected
to be added for the Catalyst 6500.
Auto-QoS
Cisco Auto-QoS for the enterprise provides automation for deployment of QoS policies in a
general business environment, particularly for mid-size companies and branch offices of larger
companies. It can be used to generate and deploy suggested Modular QoS CLI (MQC) policies
and also to deploy those policies. Auto-QoS is supported with Catalyst 3000, 4000, and 6000
Series of switches.
Cisco Auto-QoS
This topic describes Cisco Auto-Qos as it implemented on the supervisor engine.
• Strengthens integration of voice and video

- Protects voice and video traffic from congestion
• Simplifies deployment of QoS policies
- Minimal configuration needed to deploy policies
• Automates QoS policy creation and application
- Creates class and policy maps and attaches to interfaces automatically
• Accelerates voice and video deployments
- Simplified QoS configuration provides faster deployment and easier support
Cisco Auto-QoS employs the MQC model. Instead of using certain global configurations (like
mls qos and QoS DBL), Cisco Auto-QoS applied to any interface configures several global
class maps and policy maps.
Cisco Auto-QoS matches traffic and assigns each matched packet to QoS groups. This
matching allows the output policy map to put specific QoS groups into specific queues,
including into the priority queue.
QoS is needed in both directions, on inbound and outbound. Inbound, the switch port needs to
trust the differentiated services code point (DSCP) in the packet (done by default). Outbound,
the switch port needs to give voice packets “front of line” priority. If voice or video is delayed
too long by waiting behind other packets in the outbound queue, the end host drops the packet.
This packet dropping happens because the packet arrives outside of the receive window for that
packet.
Note Cisco Auto-QoS cannot be applied to EtherChannel interfaces or VLANs.
Unconditionally Trusted
Endpoints Example:
Trust Boundary Catalyst 4500E
IP Phone + PC
Trust COS from Phone

Trust DSCP from PC
qos trust device cisco-phone
Trust Boundary
qos trust extend
Conditionally Trusted
Endpoints Example:
IP Phone + PC
Trust COS from IP Phone
Trust DSCP from PC
COS 0 written by IP Phone

In the first example that is shown in the figure, the Cisco Auto-QoS VoIP trusts the marked
frames and datagrams from the telephone. Auto-QoS tells the phone not to change any marked
DSCP values of the IP datagrams sent from the PC to the switch.
In the second example that is shown in the figure, the Cisco Auto-QoS VoIP also trusts the QoS
values of the phone, but the phone changes the DSCP value of the IP datagrams sent by the
switches to zero.
Device Trust Override Example:
Trust Boundary Catalyst 4500E
IP Phone + PC
Trust COS from IP-Phone

Trust DSCP from PC
COS 2 written by IP Phone for PC

qos trust extend cos 2
Untrusted Example:
PC DSCP/COS
rewritten to 0 by switch
In the figure, the phone at the top is again trusted and the phone marks the traffic of the
connected device to a class of service (CoS) of two.
In the bottom example that is shown, the traffic from the PC will be rewritten to the default
CoS that is configured on the interface of the switch.
Cisco Auto Smartports
This topic describes Cisco Auto Smartports macros.
Challenges Solution Provided by ASP

Manual configuration of every port Configuration moves with device
-Devices move Interfaces in ready state waiting for a device to
Wasted ports – preconfigured dedicated attach
interfaces and no device -More efficient use of valuable ports
Unsure how to mix multiple features together Best Practices for mixing interface level
Not knowing what is connected configurations
-Which interface has the printer? Device classification
-What is attached on every interface
Switches in the network
Auto
Smartports
Endpoint devices connected to the network

Auto Smartports provides automatic configuration as devices connect to the switch port,
allowing auto detection and plug-and-play of the device onto the network.
Auto Smartports uses triggers to map macros to the source port of the event. Triggers are events
that tell the switch that a known device is detected. Macros are a set of device-specific interface
CLIs that get applied to a port. The most common triggers are based on Cisco Discovery
Protocol and Link Layer Device Protocol (LLDP) messages that are received from a connected
device. A Cisco Discovery Protocol event trigger occurs when the following devices are
detected:
 Cisco switch
 Cisco router
 Cisco IP phone
 Cisco wireless access point including autonomous and lightweight access points
 Cisco IP video surveillance camera
Additional event triggers for Cisco and third-party devices are user-defined MAC address
groups, MAC authentication bypass (MAB) messages, IEEE 802.1X authentication messages,
and LLDP messages.
LLDP supports a set of attributes that are used to discover neighbor devices. These type, length,
and value attributes and descriptions are referred to as TLVs. LLDP-supported devices use
TLVs to receive and send information. This protocol advertises details such as device
configuration information, capabilities, and identity. Auto Smartports uses the LLDP system
capabilities TLVs as the event trigger. Use the event trigger control feature to specify if the
switch applies a macro that is based on the detection method, device type, or configured trigger.
You can also create user-defined macros by using the Cisco IOS Shell scripting capability,
which is a Bourne again shell (bash)-like language syntax for command automation and
variable replacement.
Static Smartports macros provide port configurations that you apply manually based on the
device that is connected to the port. When you apply a static macro, the macro CLI commands
are added to the existing port configuration. When there is a link-down event on the port, the
switch does not remove the static macro configuration.
You can designate a remote server location for user-defined macro files. You can then update
and maintain one set of macro files for use by multiple switches across the network.
The macro persistence feature causes macro configurations to remain applied on the switch
ports regardless of a link-down event which eliminates multiple system log and configuration
change notifications when the switch has link-up and link-down events or is a domain member
or an endpoint in a Cisco EnergyWise network.
Auto Smartports and Cisco Medianet

Cisco Medianet enables intelligent services in the network infrastructure for a variety of video
applications. A service of Medianet is autoprovisioning for Cisco Digital Media Players
(DMPs) and Cisco IP video surveillance cameras through Auto Smartports. The switch
identifies Cisco and third-party video devices by using Cisco Discovery Protocol, 802.1X,
MAB, LLDP, and MAC addresses. The switch applies the applicable macro to enable the
appropriate VLAN, standard QoS, and auto-QoS settings for the device. The switch also uses a
built-in MAC address group to detect the legacy Cisco DMP, based on an Organizationally
Unique Identifier (OUI) of 4400 or 23ac00. You can also create custom user-defined macros
for any video device.
• Order of events for IP Phone attachment and configuration applied
PoE
CDP/LLDP
1 Attach IP phone to interface Gig 1/0/4 Attach IP phone to interface Gig 1/0/4
2 Power up via PoE Apply power to Gig 1/0/4
3 Exchange CDP/LLDP with switch Exchange CDP/LLDP with device
4 Get voice VLAN config Detects if device is an IP phone
5 Register with Call Manager Apply CISCO_IP_PHONE_MACRO to Gig 1/0/4
Contents of macro
Voice and data VLAN applied
QoS applied
Cisco best practice security applied to IP
Phone interface
Enable Auto Smartports macros globally on a switch using the macro auto global processing
global configuration command.
Once the device has powered on and is able to pass information, the application service
provider (ASP)-enabled switch snoops incoming packets for the following:
 Source MAC address
 Cisco Discovery Protocol
 LLDP
 DHCP discover from end device
If the source MAC address is matched to a MAC OUI configured on the switch, then that takes
precedent. Then Cisco Discovery Protocol and LLDP are used to determine device type. If
none of the above work, then DHCP options are used to determine the device.
Once the device type is determined, a predefined macro (in this case,
CISCO_IP_PHONE_MACRO) is applied to the interface to which the device connected. That
macro contains a set of CLI commands that can execute any number of configurations for the
port. In this example, the macro applies voice and data VLANs, QoS, and best practice security
features.
There are a number of built-in macros for well-known devices:
 Access-point
 IP-camera
 Lightweight-ap
 Media-player
 Phone
 Router
 Switch
The content of these macros can be seen with the show macro auto device name command.
There are some optional steps that can be taken when configuring ASP:
 Use your switch-specific values to replace macro default parameter values.
 Configure MAC address groups.
 Configure macro persistence.
 Configure built-in macro options.
 Create user-defined event triggers.
 Configure user-defined macros.
• Enable Auto Smartports macros globally on a switch using macro auto
global processing global configuration command.
• Additionally disable the Auto Smartports macro per interface using no
macro auto processing interface configuration command.
Switch# configure terminal Catalyst 3850
Switch(config)# macro auto global processing
Switch(config)# interface gigabitethernet0/4
Switch(config-if)# no macro auto processing
Gi 0/1
Gi 0/4
Use the macro auto global processing global configuration command to globally enable
macros on the switch. To disable macros on a specific port, use the no macro auto processing
command in interface mode.
Use the macro auto processing interface configuration command to enable macros on a
specific interface. To disable macros on a specific interface, use the no macro auto processing
interface configuration command.
The figure shows an example where Auto Smartports macros are globally enabled on a switch.
Additionally macros are disabled on the Gigabit Ethernet interface.
• Use show macro auto command to verify Auto Smartports macro
information.
Switch# show macro auto device
<output omitted>
Device:access-point
Default Macro:CISCO_AP_AUTO_SMARTPORT
Current Macro:CISCO_AP_AUTO_SMARTPORT
Configurable Parameters:NATIVE_VLAN
Defaults Parameters:NATIVE_VLAN=1
Current Parameters:NATIVE_VLAN=1
Device:phone
Default Macro:CISCO_PHONE_AUTO_SMARTPORT
Current Macro:CISCO_PHONE_AUTO_SMARTPORT
Configurable Parameters:ACCESS_VLAN VOICE_VLAN
Defaults Parameters:ACCESS_VLAN=1 VOICE_VLAN=2
Current Parameters:ACCESS_VLAN=1 VOICE_VLAN=20
<output omitted>
Use the show macro auto device privileged EXEC command to display the configurable Auto
Smartports macro parameters for a device.
Cisco Smart Install
This topic describes Cisco Smart Install.
Challenges Solution Provided by Smart Install

Branch office locations with not-so-technical Zero touch so anyone can install a client
staff -No need to travel for switch
Hard to maintain IOS and configuration installs/replacements
consistency across large number of switches Automated image and configuration
Upgrading code on a large number of clients management ensures consistency across
is cumbersome and time consuming clients
Automated upgrades can be pushed from the
director to all clients in a group
Catalyst 6500 Supervisor 2T Smart

Install
Switches in the network
Endpoint devices connected to the network
Smart Install is a plug-and-play configuration and image-management feature that provides

zero-touch deployment for new switches. You can ship a switch to a location, then place it in
the network, and then power it on with no configuration required on the device.
A network using Smart Install includes clients that are served by the director. Director acts as a
single point of management and provides image and configuration downloads for any client
switch. The figure shows the Catalyst 6500 Series Sup 2T switch acting as director in the
campus network. This setup shows positioning of the Catalyst 6500 as the lead backbone
switch.
Supported switch platforms as of December 2012 are as follows:
 Director Cisco Catalyst Switches
— 6500 Series Supervisor Engine 2T, 4500E Supervisor Engine 7-E,
— 4500E Supervisor Engine 7L-E, 4500 Supervisor 6-E, 4500 Supervisor 6L-E,
— 3850, 3750-X, 3750-E, 3750-G, 3750V2-24FS, 3560-X, 3560-E, 3560-G, 3560V2-
24S, 3560C
 Client Cisco Catalyst switches:
— Cisco Catalyst 3000 Series: 3850, 3750V2, 3750-E, 3750-X, 3560V2, 3560-E, 3560-
X, 3560-C
— Cisco Catalyst 2000 Series: 2960, 2960-S, 2960-C, 2960-SF, 2360
Recommended Software Versions for Director Roles
Smart Install Director Model Software Version
Cisco Catalyst 6500 Supervisor Engine 2T 15.1.1-SY
Cisco Catalyst 4500 15.1.2-SG or 3.4.0SG
Cisco Catalyst 3850 3.2.0SE
Cisco Catalyst 3750 or 3560 15.0(2)SE1

The Cisco Smart Install solution supports Cisco ISRs as Smart Install directors too. Supported
ISR platforms as of December 2012 are as follows:
 G1 series of Cisco ISRs: 1841, 2801, 2811, 2821, 2851, 3825, 3845
 G2 series of Cisco ISRs: 1921, 1941, 2901, 2911, 2921, 2951, 3925, 3945, 3925E, 3945E
For additional information About Cisco Smart Install supported hardware, refer to
http://www.cisco.com/en/US/docs/switches/lan/smart_install/configuration/guide/supported_de
vices.html.
• Director: Configures client providing switch plug-and-play
• Client: Gets the image and configuration from the director
• Groups: Classification of client switches based on switch model and
other parameters for better management
• DHCP and TFTP Server: Serves IP addresses, image, and
configuration files to client switches
Central TFTP, DHCP
Server
Catalyst 3850
Director Switch
Client Switches Client Switches
Clients Group 1 Clients Group 2
A network using Smart Install includes a group of networking devices that are known as
clients. A common Layer 3 switch or router that acts as a director serves these clients. The
director provides a single management point for images and configuration of client switches.
When a client switch is first installed into the network, the director automatically detects the
new switch and identifies the correct Cisco IOS image and the configuration file for
downloading. It can allocate an IP address and hostname to a client. If a standalone switch in
the network is replaced by another switch of the same model, meaning a switch with the same
product ID, it automatically gets the same configuration and image as the previous one. The
director can also perform on-demand configuration and software image updates of a switch or a
group of switches in the network.
The director can act as a DHCP and TFTP server and can store the configuration and image
files. These files can also be stored on a third-party TFTP server for the director to use. This
type of storage is recommended when the topology has client switches of different models,
requiring different IOS images. The client can download the image and configuration files from
the director TFTP server or from a remote server.
In a typical Smart Install network, a client switch uses DHCP to get an IP address and the
director snoops DHCP messages. For a client to participate in Smart Install zero-touch upgrade,
it must use DHCP, and all DHCP communication must pass through the director so that it can
snoop all DHCP packets from clients. The most automatic operation is when all switches in the
Smart Install network use DHCP and are Smart Install-capable. However, any client switch that
supports the archive download-sw privileged EXEC command to download a software image
can be used in a zero-touch Smart Install network.
A client switch can participate in Smart Install even if not directly connected to the director.
The Smart Install network supports up to seven hops. Intermediate switches or clients that are
connected to the director through an intermediate switch in a multihop environment can be, but
do not have to be, Smart Install-capable switches.
The figure shows a Smart Install network with external DHCP and TFTP servers. There can be
only one director in any Smart Install network. The director can also serve as the DHCP and
TFTP server.
TFTP, DHCP
servers
Director discovers
1. client via CDP
LAN/WAN
New switch issues
2. DHCP discover
~20
Minutes
Director adds options
3. to DHCP offer
Director
TFTP
Client retrieves image, CDP
4. config via TFTP DHCP
Client reboots with

new configuration
5. and image
Client group 1 Client group 2
The figure describes the steps that are taken when a client is first connected to a Smart Install
Director. Before connecting the client, there are some configuration steps that must be taken on
the director:
1. Configure the switch as the Smart Install director using the vstack director command and
enable Smart Install on the director using the vstack basic command.
Director# configure terminal
Director(config)# vstack director 10.0.0.33
Director(config)# vstack basic
2. Configure the DHCP scope for Smart Install client switches (if an external DHCP server is
not used).
Director(config)# vstack dhcp-localserver pool1
Director(config-vstack-dhcp)# address-pool 10.0.1.0
255.255.0.0
Director(config-vstack-dhcp)# default-router 10.0.0.33
Director(config-vstack-dhcp)# file-server 10.0.0.33
Director(config-vstack-dhcp)# exit
Director(config)# ip dhcp remember
3. Configure the default image using the vstack image command and default configuration
using the vstack configuration command. This example shows local storage of these files,
but an external TFTP server can be used as well.
Director(config)# vstack image flash:c2960-lanbase-tar.122-
53SE.tar
Director(config)# vstack configuration
flash:2960lanbase_configuration.txt
4. Configure assignment of the last three bytes of a switch MAC address in addition to a
common name (such as Client_Switch) for all new switch clients.
Director(config)# vstack hostname-prefix Client_Switch
5. Use the write erase and reload commands to start Zero Touch startup process for
preconfigured switches.
Director# write erase
Director# reload
Proceed with reload? [confirm]
Once these steps are complete, the director is ready to have clients attach to it. When the client
attaches to the director, the following happens in the background:
 The director discovers the client through DHCP snooping.
 The client gets IP on VLAN 1 from the DHCP pool on the director (if an external DHCP is
not used).
 The download starts on the client, which takes 5 to 8 minutes. The steps of the download
include the following:
— The client downloads client_cfg.txt.
— The client downloads the configuration file.
— The client downloads the image file.
— The client switch reboots.
Note Do not press any key on the client switch at this time as it will terminate the Smart Install
operation.
• Client switches belong to multiple models.
- External TFTP server, new management VLAN, and EtherChannels
• Before you begin, copy image tar files for all client switch platforms to
the TFTP server.
Catalyst 3850
Director Switch
Central TFTP, DHCP

Client Switches Server
Clients Group 1
- 3560e Series
Client Switches Client Switches
Clients Group 2 - 3750e Series Clients Group 3 – 2960 Series
The variety of client switches means that each client switch model will have its own unique
IOS image or configuration. In the example that is shown in the figure, an external TFTP server
is being used to meet the scalability requirements of multiple client switch IOS images,
configuration files, and so on. The external server also helps in a scenario where a topology has
multiple director switches.
Note When using external TFTP servers, write permissions can cause issues when the director
tries to copy image lists and backed up versions of the configuration. To overcome this
issue, create a subfolder in the TFTP server that allows complete read/write access to the
director.
To configure multiple client groups on the director, you must use either the vstack group
built-in or vstack stack group custom commands. The built-in groups are currently shipping
products, and the options for these shipping products can be seen by entering a question mark
(?) after built-in.
This example shows how to identify a group as Catalyst 3560 8-port Power over Ethernet (PoE)
switches and to enter Smart Install group configuration mode. It identifies the image to be
obtained through TFTP for the group as c3560-ipbase-mz.122-52.SE.tar, which contains the
3560 IP base image for 12.2(52)SE and identifies the configuration file as the 3560 IP Base
image.
Director(config)# vstack group built-in 3560 8poe
Director(config-vstack-group)# image tftp://1.1.1.10/c3560-
ipbase-mz.122-52.SE.tar
Director(config-vstack-group)# config tftp://1.1.1.10/c3560-
24-ipbase-config.txt
The custom option allows for the creation of a user-defined Smart Install group. There are four
options for custom groups:
 Connectivity: Matches a custom group that is based on connectivity or network topology.
All clients have the same upstream neighbor. If a client matches more than one group
characteristic, a connectivity match will take precedence over a stack match or product-ID
match, but not over a MAC address match.
 Mac: Matches a custom group consisting of switch MAC addresses. If a client matches
more than one group characteristic, a MAC address match takes precedence.
 Product ID: Matches a custom group that is based on the product ID.
 Stack: Matches a custom group that is based on switch stack membership. If a switch
matches more than one group characteristic, a stack match takes precedence over product
ID.
The following example shows how to identify a custom group named test that is based on
matching connectivity and to enter Smart Install group configuration mode. It specifies that the
group includes clients that are connected to the host with the IP address 2.2.2.2 with an
interface name of finance, and identifies the image and configuration to be obtained through
TFTP for the group:
Director(config)# vstack group custom test connectivity
Director(config-vstack-group)# match host 2.2.2.2 interface
finance
Director(config-vstack-group)# image tftp://1.1.1.10/c3560-
ipbase-mz.122-52.SE.tar
Director(config-vstack-group)# config tftp://1.1.1.10/3560-24-
ipbaseconfig.txt
Director switch (6509) Hardened TFTP
Segment Smart Install Functions running DHCP server for server for client-
switch images and
Smart Install VLAN 10
config
 Create and utilize dedicated VLAN/DHCP scope only VLAN 10 not routed
for Smart Install operation
 Configure Smart Install DHCP scope on director
switch
 Eliminate or severely restrict outside traffic into
Smart Install VLAN PACL: permit vlan10
 Enable Catalyst security features on every tftp-server tftp
switchport in the Smart Install VLAN
 DHCP Snooping, DAI, IP SRC Guard, Port
Security max macs
3750X • Switchport VLAN 10
• Catalyst security
features enabled
Segment Smart Install Functions
 Utilize Join Window on Director
 Schedule a time window for zero-touch image
and config upgrades 3750X Smart Install Client
Zero-Touch Install
 Clients cannot download image or config
outside the window
 Disable TFTP server switchport or TFTP service
outside of Join Window
 Configure PACL on TFTP server that only allows
TFTP from Smart Install VLAN DHCP scope
 Prune Smart Install VLAN from trunks when not in
use
There are several recommendations for securing an infrastructure using Smart Install.
Join Window CLI:
Director(config)#vstack join-window start [date] hh:mm
[interval] [end date] [recurring]}
Port security max macs allowed CLI
(config-if)# switchport port-security maximum
number_of_addresses {number greater than 10 is fine in most
situations}
Dhcp snooping and other switchport security info
http://www.cisco.com/en/US/partner/docs/switches/lan/catalyst6
500/ios/15.0SY/configuration/guide/dhcp_snooping.html
Smart Install Directors Smart Install Clients
Catalyst 6500 Catalyst 3K

Sup 2T (software version
15.1.1-SY) 3850
Catalyst 4500 3750, 3750v2, 3750E, 3750G, 3750X,
Sup 7 and Sup 6 3560, 3560v2 3560E, 3560G, 3560X
(software version 3.4.0SG
15.1.2-SG)
Catalyst 3K
Catalyst 2K
3850 (software version 3.2.0SE)
3750, 3750G, 3750v2, 3750E,
3560, 3560v2, 3560E, 3560G 2960, 2960S, 2960G, 2960SF
3750X, 3560X
Recommended: 12.2.(58)SE2
ISR Branch Router Catalyst 2K/3K Compact

G1: 1841, 2801, 2811, 2821, 2851, 3825, 3845
G2: 1921, 1941, 2901, 2911, 2921, 2951, 3925, 3945, 2960C, 3560C
3925E, 3945E, NM-16-ESW
Min release: : 15.1.(3)T1
The left side of the figure shows Cisco devices capable of acting as Smart Install directors.
The right side of the figure shows Cisco devices that are supported as Smart Install clients.
The Catalyst 3000 series, when stacked, can act as director.
The latest additions to the Smart Install Director are 6500 Sup 2T, and the 4500 Sup 7 and Sup
6.
Cisco Easy Virtual Network
This topic describes the capabilities and characteristics of the Cisco EVN.
One Physical Network Many Access Devices

VRF A–F Personal Devices
40GE Corporate Desktops
Guest Laptops
Video Surveillance
TelePresence Units
Corporate Voice
Simplified Network Design via MPLS, VRF-Lite and EVN
Enhanced Security, Group Segregation, and Shared Services via Virtualized Firewalls
Better Monitoring and Operations with VRF-Aware Services

A scalable solution is needed for keeping groups of users totally separate and centralizing
services and security policies. This separation must be kept while preserving the high
availability, security, and scalability benefits of the campus design. To address this solution, the
network design needs to effectively solve the following challenges:
 Access control: Help ensure that legitimate users and devices are recognized, classified,
and have authorized entry to their assigned portions of the network.
 Path isolation: Help ensure that the substantiated user or device is mapped to the correct
secure set of available resources—effectively, to the right VPN.
 Services edge: Help ensure that the right services are accessible to the legitimate set or sets
of users and devices, with centralized policy enforcement.
Network virtualization, which can be achieved in several ways, solves these challenges.
Virtualization technologies enable a single physical device or resource to act like it is multiple
physical versions of itself and to be shared across the network. Network virtualization is a
crucial element of the Cisco Unified Access architecture. One physical infrastructure can be
configured to support multiple different organizations or roles, helping enterprises optimize
resources and security investments. Other virtualization strategies include centralized policy
management, load balancing, and dynamic allocation. The use of virtualization enhances agility
and improves network efficiency, reducing both capital and operational expenses.
• It is a device virtualization technique to virtualize Layer 3 routing and
forwarding.
• It allows the switch to maintain multiple routing and forwarding tables.
• Each VRF has its own interfaces.
• It allows overlapping address spaces, and complete Layer 2 and Layer 3
traffic isolation: virtual networks.
VRF GREEN
192.168.1.0/32 is subnetted, 1 subnets
C 192.168.1.102 is directly connected, Loopback12
VRF BROWN
GLOBAL TABLE
Multivirtual routing and forwarding (VRF) Customer Edge (CE) is a feature that allows a
service provider to support two or more VPNs, where IP addresses can be overlapped among
the VPNs. Multi-VRF CE uses input interfaces to distinguish routes for different VPNs and
forms virtual packet-forwarding tables by associating one or more Layer 3 interfaces with each
VRF. Interfaces in a VRF can be either physical, such as Ethernet ports, or logical, such as
VLAN switch virtual interfaces (SVIs). An interface cannot belong to more than one VRF at
any time.
Multi-VRF CE includes these devices:
 CE devices provide customers access to the service-provider network over a data link to
one or more provider edge (PE) routers. The CE device advertises the local routes of a site
to the router and learns the remote VPN routes from it. A Catalyst 3750-X or 3560-X
switch can be a CE.
 PE routers exchange routing information with CE devices by using static routing or a
routing protocol such as BGP, Routing Information Protocol version 2 (RIPv2), OSPF, or
EIGRP. The PE is only required to maintain VPN routes for those VPNs to which it is
directly attached. This limit eliminates the need for the PE to maintain all of the service-
provider VPN routes. Each PE router maintains a VRF for each of its directly connected
sites. Multiple interfaces on a PE router can be associated with a single VRF if all of these
sites participate in the same VPN. Each VPN is mapped to a specified VRF. After learning
local VPN routes from CEs, a PE router exchanges VPN routing information with other PE
routers by using Internal BGP (IBPG).
 Provider routers or core routers are any routers in the service provider network that do not
attach to CE devices.
With multi-VRF CE, multiple customers can share one CE, and only one physical link is used
between the CE and the PE. The shared CE maintains separate VRF tables for each customer
and switches or routes packets using its own routing table for each customer. Multi-VRF CE
extends limited PE functionality to a CE device. This design gives it the ability to maintain
separate VRF tables to extend the privacy and security of a VPN to the branch office.
Routing and VRF-Lite
In order to propagate route information within each VRF instance, the routing protocol needs to
be instantiated by using either a separate routing process (OSPF, IS-IS) or address family
(EIGRP, RIPv2). This feature is often referred to as the “VRF awareness” of the routing
protocol. All IPv4 routing protocols are VRF-aware, including static routes and policy-based
routing (PBR).
VRF-Lite Design Consideration

VRF-Lite transport is based on either IPv4 or IPv6 and does not require any additional
protocol. The drawback of this technology is that any addition of a new VRF requires either the
creation of a new tunnel interface or a new IEEE 802.1Q subinterface. As such, VRF-Lite is
manageable for networks with fewer numbers of VPNs and fewer numbers of hops in a VPN
path.
The Catalyst 4500E Series Switches do not support per-packet dynamic-path maximum
transmission unit (MTU) checking based on the IP destination address. It propagates the Don’t
Fragment (DF) bit to the outer header when packets are sent over a tunnel. If the original packet
is equal to or smaller than the tunnel MTU, the original packet is encapsulated. The resulting
tunneled packet may be subsequently fragmented if it exceeds the MTU of the physical output
interface. The fragmentation process will be performed by the software.
If the encapsulated traffic is fragmented at the output physical interface or within the tunnel
path, the fragments will not be reassembled by the forwarding engine. Rather, they will be
punted to the control plane for reassembly.
Multi-VRF Network
R1 R2
802.1q 802.1q 802.1q
Easy Virtual Network

Edges R1 R2
Trunk Edges
Interfaces Interface Interfaces
vnet
802.1q tag 802.1q
Network virtualization is an economical way to provide traffic separation. Multiple virtualized

networks can be overlaid on a single physical infrastructure. A corporation may need to provide
traffic separation between different user groups. Traffic separation may be based on user role or
user group policies. For example, traffic separation may be required between different
departments in an organization. Third-party vendors may need to share selected network
resources. Due to corporation acquisitions and mergers, network access may need to be
partially restricted. Deploying a separate physical network for each user group increases capital
expenditures (CapEx) and operating expenses (OpEx) and may not be a viable way to provide
traffic separation. Many virtual networks with different security and routing polices can be built
over a single physical infrastructure without affecting the ability of end users to access needed
network resources.
EVN is a simplified LAN virtualization solution that helps enable network managers to provide
service separation on a shared network infrastructure. EVN uses existing technology to increase
the effectiveness of VRFs. Existing enterprise network architecture and protocols, as well as
concepts such as trunk and access interface, are preserved in the EVN architecture. In addition
to reutilizing Multi-VRF features, new components such as virtual network (VNET) trunk,
VNET tag, route replication, and management tools are introduced to provide a comprehensive,
pure-IP network segmentation solution.
Multi-VRF offers Multiprotocol BGP (MP-BGP) and label-free network segmentation
solutions, but requires a setup of hop-by-hop path isolation. Separate interfaces or subinterfaces
must be provisioned for each virtual network on core-facing interfaces on an end-to-end
virtualized path as shown in the top image in the figure. Network provisioning and management
could become repetitive and complex depending on the numbers of virtual networks and
numbers of hops that traffic needs to cross.
There are three virtual networks—Blue, Yellow, and Green—shown in the figure. Notice that
there are three separate interfaces that are dedicated for each between R1 and R2. Blue virtual
network traffic is forwarded over the interface and subinterface that is provisioned for the Blue
virtual network. This forwarding guarantees traffic separation in the forwarding plane. Virtual
network devices peer over separate routing instances providing control plane separation. For
example, the Blue VRF table holds Blue virtual network routes and the Yellow VRF table
holds Yellow virtual network routes.
Multi-VRF is manageable for networks with fewer numbers of virtual networks and fewer
numbers of hops in a virtual network path. As the numbers of virtual networks grow, new
interfaces and subinterfaces will need to be added, and the need for IP addresses and routing
will increase. This demand increases planning and provisioning overhead.
Traffic Separation in EVN

Path isolation can be achieved by using a unique tag for each virtual network. This tag is called
the VNET tag. Each virtual network carries throughout the same tag value that was assigned by
a network administrator. An EVN device in the virtual path uses the tags to provide traffic
separation among different virtual networks. This tag removes the dependency on physical and
logical interfaces to provide traffic separation. As illustrated in the figure, only a single trunk
interface is required to connect a pair of EVN devices. A trunk interface provides connectivity
between a pair of EVN devices and transports multiple virtual network traffic, whereas edge
interfaces connect to specific virtual network users. An edge interface is mapped to a specific
virtual network and is the point in the network where the VNET tag is applied to incoming
traffic from virtual network users. Traffic traversing from an EVN device to virtual network
users is untagged. Midpoint EVN devices do not remove, add, or swap tags.
Network virtualization solution EVN provides a pure IP alternative to Multiprotocol Label
Switching (MPLS) in enterprise networks for up to 32 virtual networks. It has the following
features:
 Uses an existing enterprise design, architecture, and protocols.
 Uses existing technology to increase the effectiveness of VRFs
 Provides either an Interior Gateway Protocol (IGP)-only (OSPF, EIGRP) or IGP/Exterior
Gateway Protocol (EGP)-based alternative.
 Reintroduces familiar concepts for access and trunks to Layer 3.
 Can be deployed with traditional MPLS VPNs or MPLS VPNs over Multipoint Generic
Routing Encapsulation (mGRE).
 Can coexist with Multi-VRF deployments.
 Supports non-IP and IPv6 traffic through the EVN global table.
 Supports Protocol Independent Multicast (PIM) and Internet Group Management Protocol
(IGMP) with sparse mode (SM) and Source Specific Multicast (SSM) modes for Multicase
VPN (MVPN).
 Supports shared services using route replication.
 Includes enhanced troubleshooting and usability tools, which includes routing context,
traceroute, debug condition, cisco-vrf-mib, and simplified VRF-aware SNMP
configuration.
GE0/0/2 GE0/0/3 GE0/0/2
R1 R2 GE0/0/1 R3
GE0/0/0 GE0/0/0
GE0/0/1 GE0/0/0 GE0/0/3 GE0/0/1
R1 Before EVN R1 After EVN

Interface GigabitEthernet0/0/3.101 vrf definition yellow
description GE Connection to R2 vnet tag 101
encapsulation dot1Q 101 address-family ipv4
ip vrf forwarding yellow
ip address 10.1.10.1 255.255.255.0 vrf definition green
ip pim query-interval 333 msec
ip pim sparse-mode vnet tag 102
address-family ipv4
interface GigabitEthernet0/0/3.102
description GE Connection to R2 vrf definition blue
encapsulation dot1Q 102 vnet tag 103
ip vrf forwarding green address-family ipv4
ip address 10.1.10.1 255.255.255.0
ip pim query-interval 333 msec Interface GigabitEthernet0/0/3
ip pim sparse-mode description GE Connection to R2
vnet trunk
interface GigabitEthernet0/0/3.103 ip address 10.1.10.1 255.255.255.0
description GE Connection to R2
encapsulation dot1Q 103
ip pim query-interval 333 msec
ip vrf forwarding blue ip pim sparse-mode
ip address 10.1.10.1 255.255.255.0
ip pim query-interval VRF
333 1003
msec
ip pim sparse-mode
Simplified operations with VNET Trunk

The configuration in the figure shows that Multi-VRF does not have a trunk interface. Each
subinterface for each VRF has to be configured manually. EVN automatically generates
subinterfaces for each EVN that does not expand in the configuration to keep the configuration
concise.
To configure EVN, use the vrf definition command to configure the VNET, the vnet tag
command to assign an EVN tag, and the address-family ipv4 command to declare carrying the
IPv4 prefixes.
Switch# configure terminal
Switch(config)# vrf definition Blue
Switch(config-vrf)# vnet tag 1003
Switch(config-vrf)# address-family ipv4
Note Notice that the virtual network name is case sensitive.
To set up a client facing edge interface connecting to Blue VN users, use the vrf forwarding
command.
Switch(config)# interface gigabitethernet 0/0/2
Switch(config-if)# vrf forwarding Blue
Switch(config-if)# ip address 10.1.3.1 255.255.255.0
Note that a single trunk interface transporting multiple EVN traffic doesn’t require the vrf
forwarding command.
To set up the core facing trunk interface, use the vnet trunk command.
Switch(config)# interface gigabitethernet 0/0/3
Switch(config-if)# vnet trunk
Switch(config-if)# ip address 10.1.10.1 255.255.255.0
BEFORE EVN AFTER EVN
Switch# routing-context vrf green

Switch# show ip route vrf green Switch%green#
Routing table output for green
Switch%green# show ip route
Switch# ping vrf green 10.1.10.1 Routing table output for green
Ping result using VRF green
Switch%green# ping 10.1.10.1
Switch# telnet 10.1.10.1 /vrf green Ping result using VRF green
Telnet to 10.1.1.1 in VRF green
Switch%green# telnet 10.1.10.1
Switch# traceroute vrf green Telnet to 10.1.1.1 in VRF green
10.1.10.1
Traceroute output in VRF green Switch%green# traceroute 10.1.10.1
Traceroute output in VRF green
Simplified context-aware operations

Use the routing-context vrf command to select the virtual network and use various show
commands inside the routing context to verify virtual network-specific configuration, which is
isolated within a specified VRF.
Use this command to set the VRF context before entering several privileged EXEC commands
that you want to apply to the same VRF. This command saves you from repeatedly entering a
VRF name in several commands while entering EXEC commands that apply to a single VRF.
When in a routing context, the system prompt changes to indicate the routing context being
used. Commands that can be used in a routing context are ping, show ip route, telnet, and
traceroute.
The routing-context vrf green command enters routing context green.
ip vrf SHARED vrf definition SHARED
rd 3:3 address-family ipv4
route-target export 3:3 route-replicate from vrf RED unicast
route-target import 1:1 all route-map red-map
route-target import 2:2 route-replicate from vrf GREEN unicast
! all route-map grn-map
ip vrf RED
rd 1:1 vrf definition RED
route-target export 1:1 address-family ipv4
B route-target import 3:3 route-replicate from vrf SHARED
! A unicast all
E ip vrf GREEN
rd 2:2 F vrf definition GREEN
F route-target export 2:2 address-family ipv4
route-target import 3:3 T route-replicate from vrf SHARED
O ! unicast all
router bgp 65001 E
R bgp log-neighbor-changes
! R
E address-family ipv4 vrf SHARED
redistribute ospf 3 Shared Services Benefits
no auto-summary
no synchronization E with EVN
E exit-address-family
! V
V address-family ipv4 vrf RED • No BGP required
redistribute ospf 1
N • No Route Distinguisher required
N no auto-summary
no synchronization
• No Route Targets required
exit-address-family • No Import/Export required
! • Simple Deployment
address-family ipv4 vrf GREEN
redistribute ospf 2
• Supports both Unicast and Multicast
no auto-summary
no synchronization
exit-address-family Simplified shared services
There are some common services (such as database servers and application servers) that
multiple virtual networks need to access. Shared services are beneficial for the following
reasons:
 Services are usually not duplicated for each group.
 Sharing services is economical.
 Sharing services is efficient and manageable.
 Policies can be centrally deployed.
To achieve route separation, you could replicate the service, either physically or virtually, one
service for each virtual network. However, that solution might not be cost effective or feasible.
For a router that supports EVN, the solution is to perform route replication and route
redistribution, which is a simple deployment. Route replication requires no BGP, no route
distinguishers (RDs), no route targets, and no import or export. Route replication allows shared
services because when routes are replicated between virtual networks, clients who reside in one
virtual network can reach prefixes that exist in another virtual network.
In VRF-Lite, route leaking is achieved, via BGP, by using the route import/export feature. In
fact, the BGP import and export method of copying routes between VRFs works with both
VRF-Lite and EVN. However route replication is the simpler alternative to enable sharing of
common services across multiple virtual networks.
The following are best practice guidelines for customers to follow when
using the features discussed in this module:
1. When using Cisco NSF, all attached neighbors must be Cisco NSF-aware.
2. When using VSS, dual-home devices with MEC, to achieve the highest level of
resiliency.
3. When using Quad Supervisor VSS SSO, use all four supervisor uplinks to form the
VSL.
4. Cisco NSF and SSO must be enabled for VSS to work with Catalyst 4500
switches.
5. Use Auto Smartports to ensure best practice configurations are deployed
consistently across the infrastructure.
6. When using Smart Install, use a dedicated TFTP server for a large number of
clients. Otherwise, the TFTP function can be hosted on the Director.
7. Use the Catalyst Integrated Security Toolkit (CIST) and Join Window functions to
secure Smart Install.
8. Eliminate or severely restrict outside traffic into the Smart Install VLAN.
9. Do not touch the Smart Install Client until Smart Install completes or else the
operation will fail.
10. Utilize EVN in VRF-Lite environments to simplify deployment and management.
The figure describes some of the best practice recommendations when deploying a Cisco
Unified Access wired infrastructure.
Feature Catalyst 3850 Catalyst 4500E/X Catalyst 6500/6800

Stacking Stackwise-480 No No
Redundant Supervisors N/A Yes Yes
NSF/SSO Yes Yes Yes
VSS No Yes Yes
ISSU/EFSU No ISSU with 4500-E only EFSU (not with 6880-X)
Auto-QoS Yes Yes Yes
Auto Smartports Yes Yes Roadmap
Smart Install Yes (Client and Yes (Director) Yes (Director)

Director)
VRF-Lite/EVN VRF-Lite – Yes Yes Yes
EVN - Roadmap
For Roadmap information please check with your respective product

management team for the most current release timeframe.
* Operating systems running on LAB devices are supporting these features.
The figure shows a per-platform support matrix for all of the major features that are discussed
in this module.
VLAN3
UA Champions Boot Camp TRUNK (VLAN5 Mgmt.)
TRUNK (VLAN5 Mgmt.)
HTA Network Design VLAN3
Ten 2/4
G1 1/2
Gi 1/3
Gi 1/2
VLAN/SVI VLAN3
VLAN 10
· 3 – Wired Mgmt G1 1/2
G1 1/2
Eth0/Gi0
· 5 – Wireless Mgmt LAB Eth0/Gi0
· 10 – HTA Servers eth0 Ten1/0/1
Gi0/0/1
· 200 – hta-employee-wlan Po1
(Ten1/5,Ten 2/5)
· 220 – hta-guest-wlan
· 230 – hta-voice-wlan ROUTED
· 240 – BYOD-WLAN hta-mse hta5508 hta5760
AD1 hta6503 ISE Primehta
· 245 – BYOD-REGISTER 10.1.3.110 10.1.5.50 10.1.5.55
10.1.10.10* 10.1.1.1 10.1.3.20 10.1.3.101
Po1 (Ten1/1,Ten 1/2)

Layer 2 Trunk Single Link VLAN/SVI
· 22 – hta-ap2 · 202 – hta-employee2-wlan TRUNK
· 23 – hta-ap3 · 222 – hta-guest2-wlan TRUNK
Layer 2 Port Channel · 52 – hta-voice2 · 232 – hta-voice2-wlan Ten2/3
· 53 – hta-voice3 · 502 – hta-backbone2 ROUTED
Layer 3 Port Channel · 102 – hta employee2 · 503 – hta-backbone3
· 103 – hta-employee3 hta4503
· 122 – hta-guest2 10.1.1.2
· 123 – hta-guest3
Po1 (Gi1/0/24,Gi2/0/24) Po2 (Ten2/4,Ten 2/5)

Bldg. 1 Bldg. 2 Gi1/0/4 Bldg. 3 Gi1/0/2 LAB
Gi1/0/4 Gi1/0/3
Gi1/0/1
Gi1/0/1
Gi1/0/1
hta3850-standalone W7-PC1
10.1.2.2
LAB VLAN 22
LAB
hta3850-stack Gi0 hta3750-stack
VLAN 21 VLAN 23
10.1.1.3 10.1.2.130
W7-PC3
VLAN/SVI VLAN/SVI VLAN/SVI
· 21 – hta-ap1 · 22 – hta-ap2 W7-PC2
· 23 – hta-ap3
· 51 – hta-voice1 Gi0 · 52 – hta-voice2 · 53 – hta-voice3 Gi0
· 101 – hta-employee1 · 102 – hta-employee2 AP2 · 103 – hta-employee3
· 121 – hta-guest1 · 122 – hta-guest2 · 123 – hta-guest3
· 201 – hta-employee1-wlan · 202 – hta-employee2-wlan
· 221 – hta-guest1-wlan · 222 – hta-guest2-wlan
· 231 – hta-voice1-wlan AP1 · 232 – hta-voice2-wlan AP3
This figure represents the HTA Hospital’s network infrastructure. It will be used as a lab
topology in this course.
Summary
This topic summarizes the key points that were discussed in this lesson.
• Cisco Unified Access is an intelligent network platform, which is the

business foundation to support the BYOD trend and the Internet of
Everything.
• Cisco Unified Access wired architecture provides several high
availability features like Stackwise-480, dual supervisor engines, Cisco
NSF and SSO, VSS, and ISSU.
• Cisco Catalyst Smart Operations is a set of technologies and features to
simplify network planning, deployment, monitoring, and troubleshooting.
• Auto Smartports macros dynamically configure ports based on the
device type detected on the port.
• Smart Install is a plug-and-play configuration and image-management
feature that provides zero-touch deployment for new switches.
• Cisco Auto-QoS is used to easily deploy QoS on the access ports on the
campus switches.
• An IP-based network virtualization solution, EVN takes advantage of
VRF-Lite technology to simplify Layer 3 network virtualization.
Module Self-Check
Use the questions here to review what you learned in this module. The correct answers and
solutions are found in the Module Self-Check Answer Key.
Q1) Resiliency is a key feature needed to support BYOD and other critical Cisco Unified
Access wired infrastructures. Choose three platforms that support SSO, which provides
subsecond failovers. (Source: Wired Unified Access Infrastructure and Advanced
Features)
A) Catalyst 6500 series switches
B) Catalyst 4500E series switches
C) Catalyst 3850 series switches
D) Catalyst 3750-X series switches
E) Catalyst 3560-X series switch
Q2) Cisco NSF can provide hitless service continuity in the case of a control plane failure.
When designing a network to use Cisco NSF, what is the most important thing to
remember if Cisco NSF is to function as expected? (Source: Wired Unified Access
Infrastructure and Advanced Features)
A) When using Cisco NSF, all attached neighbors must be Cisco NSF-aware
B) VSS must be enabled for NSF and SSO to work with Catalyst 4500 switches
C) The IOS ISSU mechanism must be enabled
D) Smart Install functionality can not be used in the network
E) EIGRP routing protocol must be used in order to utilize all Cisco NSF benefits
Q3) What feature should customers use if they want to automate and simplify the
deployment of QoS to support voice and video? (Source: Wired Unified Access
A) Cisco Smart Install
B) Cisco Auto Smartports
C) Cisco AutoQoS
D) Cisco Easy Virtual Network
Q4) A customer tells you that they want to roll out a BYOD-capable network that will
support voice, video, and multiple other types of users and applications, but they need
to use the same infrastructure to support all of it. What are you going to recommend
and why? (Source: Wired Unified Access Infrastructure and Advanced Features)
Q5) A customer with multiple branch locations and a relatively large centralized campus is
about to install all new Catalyst 3850s to take advantage of the converged wired and
wireless capability. They have limited manpower due to budget and are looking for a
way to automate as much as possible. What would you recommend that can meet their
requirements? (Source: Wired Unified Access Infrastructure and Advanced Features)
Q6) A customer comes to you and says that they are having problems with the network
support team and its inability to roll out policies consistently across their infrastructure.
What will you suggest to help them solve this problem? (Source: Wired Unified Access
Q7) Both the Catalyst 4500 and Catalyst 6500 support ISSU, which allows for 200 ms or
less of downtime during a code upgrade. (Source: Wired Unified Access Infrastructure
and Advanced Features)
A) true
B) false
Q8) A customer wants to deploy VSS in their campus distribution, but they want to have
one chassis in one building and the other chassis in another building. The VSL will run
500 feet between the two chassis, and all attached devices will connect to both chassis.
Would you tell them that this is a good idea? Why or why not? (Source: Wired Unified
Access Infrastructure and Advanced Features)
Q9) A customer is looking to roll out 3850s in their branches so they can take advantage of
the wireless termination locally. They have ISR G2s connecting to their corporate
campus and will use Smart Install to automate and simplify deployment and
management of the 3850s. They are asking for guidance on where to host the DHCP
and TFTP functions required by Smart Install. Would you recommend to host it locally
on the ISR G2 or remotely in the corporate offices? Why? (Source: Wired Unified
Access Infrastructure and Advanced Features)
Q10) A customer wants to deploy the new Catalyst 6880-X in their campus so that they can
save space in their racks. They want to use it as a Smart Install Director while running
VSS. Can they do this immediately or must they wait for these features to come in a
later code release? (Source: Wired Unified Access Infrastructure and Advanced
Features)
Module Self-Check Answer Key
Q1) A, B, C
Q2) A
Q3) C
Q4) The use of Unified Access (UA) Architecture - One Policy (Cisco ISE), One Management (Cisco Prime),
and One Network (wired, wireless, VPN access). UA brings together the security and mobility to deliver a
consistent access experience for users regardless of location or device.
Q5) The use of Cisco Catalyst Smart Operations Tools – Cisco Smart Install and Cisco Auto Smartports.
Q6) The use of One Policy (with Cisco Identity Services Engine (ISE) and TrustSec) as a world-class unified
policy platform and distributed enforcement.
Q7) A
Q8) Flexible deployment options are one of the benefits of the VSS. The underlying physical switches do not
have to be collocated. The two physical switches are connected with standard 10 Gigabit Ethernet
interfaces and as such can be located any distance based on the distance limitation of the chosen 10 Gigabit
Ethernet optics. For example, with X2-10GB-ER 10 Gigabit Ethernet optics, the switches can be located
up to 40 km apart.
Q9) When using Smart Install, use a dedicated TFTP and DHCP server for a large number of clients or many
different client platforms. Otherwise, the TFTP and DHCP function can be hosted on the Director.
Q10) Yes.
Module 2
One Management
Foundation—Basic Prime
Infrastructure Setup
2-2 Unified Access SE Boot Camp (UASEBC) v1.0 © 2013 Cisco Systems, Inc. CONFIDENTIAL
Lesson 1
Prime Infrastructure Setup for

Wired and Wireless Clients
Overview
This lesson describes the process of adding Cisco Prime Infrastructure (PI) to the HTA
Hospital’s wired network architecture, illustrating the concept of One Management. This
process will include implementing Cisco best practices for the initial configuration of PI as
design references for implementing PI to support the bring your own device (BYOD) use case.
Described in this lesson are features available in PI to support Cisco Unified Access
architecture in HTA Hospital network. These features include the following:
 User and device visibility features
 Service assurance features
 Readiness assessment for VoIP
 Best practice wizards for implementing features in Prime Infrastructure.
The lab builds upon the basic HTA Hospital network infrastructure from Module 1, adding PI
as the management foundation from which other labs will follow. You will configure a basic
setup of PI following best-practice guidelines and implementing features compatible with the
BYOD use case referenced in the lessons.
Objectives
Upon completion of this lesson, you will be able to explain and implement the best practices for
setting up PI to support a wired and wireless network. You will be able to meet these
objectives:
 Describe Prime Infrastructure
 Describe the advantages of having one management for both wired and wireless networks
 Describe the Prime Infrastructure workflow
 Describe PI lifecycle and assurance capabilities
 Describe how PI can help in operationalizing the Cisco advantage
Prime Infrastructure Overview, Direction, and
Roadmap
This topic describes Cisco Prime Infrastructure, its key concepts and benefits.
• A single integrated solution for

comprehensive lifecycle
management of wired and
wireless access, campus, and
branch networks.
• Utilizes rich performance data
for end-to-end network visibility
to assure application delivery
and optimal end-user
experience.
Prime Infrastructure
Convergence Consolidation Cisco Advantage
© 2013 Cisco and/or its affiliates. All rights reserved. CONFIDENTIAL One Management Foundation—Basic Prime Infrastructure Setup UASEBC v1.0—2-5
Networks are being transformed and IT departments must be empowered to effectively manage
this transformation. Managing this transformation includes managing these issues:
 End-user demands for anywhere, anytime network access that is changing traditional
workplace borders.
 The use of intelligent mobile devices like Smartphones and tablets in the workplace is
changing the profile of end-user devices.
 Use of real-time video, multimedia, and Cisco TelePresence for collaboration and
communication.
 Business imperatives to save costs and implement green best practices.
Converged lifecycle and assurance management accelerate the rollout of unified access
services. These services provide highly secure access and tracking of mobile devices, while
assuring application performance and end-user network experience. Cisco Prime Infrastructure
couples end-user awareness and performance visibility with lifecycle management of wired and
wireless networks for a powerful unified solution that is called One Management. One
Management is a single pane of glass for your entire wired and wireless network infrastructure,
a single point of visibility for users and devices.
Cisco Prime Infrastructure provides the following benefits:
 Converged management of wired and wireless access, branch, and wide area networks.
 Comprehensive network lifecycle management, including user access visibility, inventory,
configuration management, plug and play, radio frequency planning, and best practices
reporting.
 End-to-end application and service assurance visibility to quickly isolate and troubleshoot
performance issues, leveraging technologies, such as Flexible NetFlow, Network-Based
Application Recognition (NBAR), and Medianet Performance Agent.
 Prime 360 Experience providing a relational, multidimensional view of users, applications,
and the network to simplify the diagnostics and remediation of network- and service-
impacting issues.
 Day zero/day one support.
 Easy deployment and management of Cisco advanced technologies, such as Cisco Adaptive
Wireless Intrusion Prevention System (wIPS), Cisco CleanAir, virtual private network
(VPN), zone-based firewall, ScanSafe, and the Cisco Application Visibility and Control
(AVC) solutions.
 Getting started and plug-and-play wizards for fast deployment.
 Faster troubleshooting.
The vision of One Management is realized through two key concepts:
 Lifecycle: Lifecycle provides day to day management of the entire network infrastructure
along with monitoring and troubleshooting functions.
 Assurance: Assurance provides network and application visibility to improve overall user
experience by leveraging embedded intelligence in the network.
© 2013 Cisco Systems, Inc. CONFIDENTIAL One Management Foundation—Basic Prime Infrastructure Setup 2-5
• Converged wired and wireless,
campus, and branch management
• Centralized discovery, inventory,
configuration management,
SWIM, and proactive/reactive
monitoring
• Accelerated troubleshooting of
wired and wireless infrastructure
issues
• Customizable out-of-the-box
Cisco best practices and validated
design configuration templates for
wired and wireless devices
• Unified access management and
client tracking
• Infrastructure lifecycle reports—
EoX, Contract, PSIRT
• Plug and play for automated
deployment
• Third-party device support
Prime Infrastructure provides end-to-end lifecycle management which incorporates a unified,

single pane of glass view across both wired and wireless networks. Prime Infrastructure
lifecycle capabilities cover required day-to-day operation tasks. These tasks include the
following:
 Network and device discovery: PI uses various protocols to discover the existence of
devices in the network. This is followed by a deep device discovery, which covers the
device’s inventory, health, configuration, and image.
 Software Image Management (SWIM): PI provides a central console for managing the
network element’s IOS images, including software distribution and backup.
 Monitoring: PI collects network events (syslogs and traps) from the network elements and
provides processed alarming information.
 Cisco best practices: PI includes pre-built configuration templates for deploying
networking capabilities, which are based on recommendations from Cisco.
 Client and user tracking: PI provides granular visibility into network clients and users,
including location, connectivity, policy, and user experience.
 Plug and play: PI simplifies the deployment of new network elements and provides
automated, zero-touch device deployment capabilities.
• End-to-end visibility for service-aware
networking
- By applications, services, and end users
• Out-of-the-box support for Cisco
advanced instrumentation
- NetFlow, Flexible NetFlow, AVC, NBAR,
PA, Medianet, and so on
• Simplified end-to-end visibility for faster
troubleshooting
- Normalizes, correlates, and aggregates
data sources
• Automated baselining with dynamic
thresholds
• NBAR2 custom application support
• Multi-NAM management
• Service health dashboard
The Assurance capabilities in Prime Infrastructure provide end-to-end application and service
assurance visibility to quickly isolate and troubleshoot performance issues. PI leverages
technologies such as the following:
 AVC
 Flexible NetFlow
 NBAR
 Medianet Performance Agent.
Prime Infrastructure Assurance receives network traffic information from the various data-
sources (routers, switches, wireless controllers, Network Analysis Modules [NAMs]), removes
duplicates, correlates, and aggregates the data to provide seamless end-to-end visibility.
Note Customers with multiple NAMs in their environment were not able to manage them globally.
Prime Infrastructure offers one console to manage all NAMs from one place. Customers can
manage their data and also management their NAMs themselves (their configuration).
New for version 2.0, PI Assurance creates dynamic baselines for critical application behavior,
which are based on actual traffic patterns over time. This feature provides a proactive approach
for identifying application behavior discrepancies.
WCS NCS 1.1 PI 2.0 PI 2.1
PI 1.2 PI 1.3 PI 1.4
LMS 4.2
Version WLC Issue Recommendation Exception

NCS 1.1 7.2 Remain until 2.0 Require WLC 7.3+
PI 1.2 7.3 CSAT Issue Upgrade to PI 1.3
PI 1.3 7.4 Remain until 2.0 Require 802.11ac module or
AP-700
PI 1.4 7.5 No path to 2.0 By exception only Only for customers moving
to 7.5
LMS 4.2 N/A Review LMS to PI LMS feature parity will occur
migration doc here throughout the PI 2.x release
train
The figure shows the recommended paths for migrating between the various Prime
Infrastructure components.
 Legacy Wireless Control System (WCS) customers need to migrate to Network Control
System (NCS) 1.1 before upgrading to PI 2.0.
 PI 1.2 has experienced some customer satisfaction issues. Cisco does not recommend
running the 1.2 version.
 PI 1.3 customers would benefit from migrating to PI 2.0 because it has many enhancements
and better quality.
 PI 1.4 should only be used by customers that need specific wireless controller 7.5 version
support. There is no migration between PI 1.4 to PI 2.0, which would require 1.4 customers
to upgrade to PI 2.1 when available.
Note If customers are not using WLC version 7.5, there is no need to go to PI version 1.4.
Customers can go directly to PI version 2.1, which will be able to support new controllers as
well. PI version 2.1 will have different updates where there will be no need to upgrade the
whole product. For example, you will be able to add additional technology packages to
support new WLC.
• Decouple device/technology support from platform
- Prime support aligned to hardware FCS
- Non-disruptive new-hardware support with fewer customer upgrades
- Fewer, more impactful platform releases
- Identify and address problem areas and “soft spots”
- Test product via customer use cases
Q2 CY13 Q3 CY13 Q4 CY13 Q1 CY14 Q2 CY14

Low-touch updates
PI 1.4 Less frequent
TP upgrades
PI 2.0
Upgrade
PI 2.1 .
HW Features Upgrade
PI
Platform Release Platform Release
Tech Pack Independent release May require reboot

Platform NMTG 9-12 month train Requires upgrade
At present, Prime Infrastructure requires a version upgrade when there is a need to support a
new network hardware, version, or technology. This version upgrade often leads to a complex
migration process that results in customer satisfaction issues.
The next platform release of Prime Infrastructure 2.1 will include enhancements that will
decouple the technology and device support modules from the core framework. This
decoupling will allow the introduction of technology and device packs that are independent of
the platform release. Technology and device packs would be installed inline without disturbing
PI functionality.
• Long-term roadmap, the path to One Management
UNIFICATION
Customer Consolidation One Management Unified IT Operations
Wired / Wireless Bundle One wired/wireless/routing Integrated Management Stack
• Introduce PI as bundle Product • Network, DC, Security, Collab
• Unified purchase and • New and NCS customers use PI • EMS, assurance,
entitlement • LMS migrates over time orchestration…
• Large Enterprise and SP Scale
Shipping Development Radar
Prime Prime Prime
Infrastructure Infrastructure Infrastructure
1.x 2.0 CY13/14
PI Lifecycle
PI Lifecycle PI Lifecycle
LMS 4.2
PI Assurance PI Assurance PI Assurance
PI DC/Cloud
Assurance
Wired and Wireless Unified Access Data Center

TECHNOLOGY
TECHNOLOGY
• Wired/wireless endpoint visibility • Converged Access Architecture • E2E assurance from user to DC
• ISE policy system integration • Unified wired/wireless/WAN • DCNM integration
• ISE policy system integration
AVC for Branch and Edge • User application experience One Firewall
• ISR/ASR/branch • One Firewall in ASR/ISR
• Assurance and app visibility with • PrSM integration
Prime NAM integration
• Prime Site and Device 360`
Cisco started announcing the Prime Infrastructure as a bundle to bring together Prime NCS,
Prime LMS, and some new Branch/Assurance functionality in Prime Infrastructure version 1.1.
This bundle simplified ordering for customers as well as converged licensing. The goal was for
customers to order one device license and split it across a mix of wired and wireless devices for
Prime LMS and Prime NCS respectively. Additionally, Prime Assurance was introduced as a
separate product. Although the bundle was available, Prime NCS Branch/WAN and Assurance
Manager were different installs and different virtual machines (VMs).
In Prime Infrastructure version 1.2, the product becomes a single install for converged wired
and wireless management. Cisco combines all of these components and converges them into a
single product and single install.
Prime Infrastructure version 2.0 evolved into the true converged platform for Next Generation
Wiring Closet (NGWC) and other next generation platforms. Prime LMS migration was done
in phases and the basic Fault, Configuration, Accounting, Performance, and Security (FCAPS)
type management functions are available in Prime Infrastructure 1.2.
Future Prime Infrastructure releases will focus on broadening the domain support, adding data
center technologies, integrating with security solutions, and increasing the scale.
• The following deployment platforms are used for Cisco Prime
Infrastructure and cover both Lifecycle and Assurance licenses:
- Virtual Appliance: Open Virtualization Appliance (OVA) image installed in a
VMware ESX 4.1 & 5.x environment with Virtual Machine File System (VMFS)
3.1 and 5.0.
• Available in three deployment sizes:
- Express: Up to 1000 devices, 1000 LWAPs
- Standard: Up to 11,000 devices, 15,000 LWAPs
- Professional: Up to 18,000 devices, 15,000 LWAPs
- Physical Appliance: Prime Infrastructure appliance with Cisco Prime
Infrastructure preinstalled using the following hardware:
• 16 processors, 16-GB RAM, 400-GB hard disk
• Field upgradeable
Cisco Prime Infrastructure is available in two deployment platforms:

 Virtual Appliance: In this platform, the Open Virtualization Appliance (OVA) is installed
in a VMware ESX 4.1 and 5.x environment with Virtual Machine File System (VMFS) 3.1
and 5.0.
 Physical Appliance: In this platform, the Prime Infrastructure appliance comes with Cisco
Prime Infrastructure preinstalled using 16 processors, 16-GB RAM, and 400-GB hard disk
as the basic configuration. This system is also field-upgradable.
Minimum hardware requirements are as follows:
 4 CPU @ 2.93 GHz
 8 GB RAM
 200 GB hard drive
Recommended hardware requirements are as follows:
 Cisco UCS C-Series with two quad-core Xeon processors
 12 GB RAM
 300 GB hard drive
• Prime Infrastructure high availability is active/passive.
- Secondary server is not running unless activated, therefore there is no need to
synchronize in-memory state.
- Database state is replicated using DB high availability syncing.
- Some files are also copied over HTTP (fileSync.properties).
• Health Monitor checks whether server is up.
- Deployed in the PI high availability setup to monitor the state of the primary
and secondary instances.
• In the event of a failure, secondary server is brought up.
- Secondary DB server is made primary—actually “secondary active.”
- Trap receivers are redirected to secondary.
• Once primary is available, user can initiate a “fail back.”
High availability is an embedded capability in Prime Infrastructure and does not require any
additional software components. It is enabled during the system’s installation process, where
one PI instance is installed and configured in a standard way to become the primary instance. A
second PI instance is installed in a standard way, but configured as secondary during the initial
configuration wizard.
During operation, the two system’s databases are replicated and synchronized. System health
and availability is monitored for ensuring the primary system’s operation. In a case of a failure,
the secondary system becomes active.
Once the primary system becomes available again, the user can order the system to fail back to
the normal state. This fail back might be done during a maintenance window to ensure
undisrupted IT operations.
Note If the secondary server is not running that means the Prime Infrastructure system processes
(applications) are not running but the Prime Infrastructure server is up and the VM is up as
well. The database is running and the replication between the two databases is running. The
secondary system (secondary Prime Infrastructure) comes up when the primary Prime
Infrastructure server fails.
Lifecycle Management of Wired and Wireless
Devices
This topic describes the lifecycle management of both wired and wireless devices.
• Welcome screen for Lifecycle view.

• Getting Started allows for accelerated deployment of your Cisco Prime
Infrastructure. This is accomplished through recommended workflows
for system setup and network management.
Cisco Prime Infrastructure is a network management tool that supports lifecycle management
from one graphical interface. PI provides network administrators with a single solution for
provisioning, monitoring, optimizing, and troubleshooting both wired and wireless devices.
Detailed graphical interfaces make device deployments and operations simple and cost-
effective.
Prime Infrastructure provides two different GUIs.
 Lifecycle view, which is organized according to home, design, deploy, operate, report, and
administer menus.
 Classic view, which closely corresponds to the GUI in Cisco Prime NCS 1.1 or Cisco
WCS.
Classic view is out of the scope of this training.
Tip You can switch back and forth between interfaces by clicking the down arrow next to your
login name.
After initial login, Prime Infrastructure opens with a welcome screen offering an optional
Getting Started screen for rapid deployment. Network operators can check the “Do not show
this on startup” checkbox in order to skip the Getting Started option in the future.
Note After the initial login, you may see a request to add a license file. If you are running a
demonstration license, this screen will show you how many days remain on the license.
Prime Infrastructure Workflows
The Prime Infrastructure web interface is organized into a lifecycle workflow that includes the
following high-level task areas:
 Home: This tab is used to view the dashboard, which gives a quick view of devices,
performance information, and various incidents.
 Design: The Design tab displays features, device patterns, or templates. Under Design, the
network operator creates reusable design patterns, such as configuration templates.
Predefined templates can be used or the operator can create unique ones. Patterns and
templates are used in the deployment phase of the lifecycle.
 Deploy: The Deploy tab is used by the operator to deploy previously defined designs or
templates into the network. Templates that are created in the design phase are used to
specify how to deploy features. The deploy phase allows operator to push configurations
that are defined in templates to one or many devices.
 Operate: The Monitor tab is used by the operator to run the network on a daily basis and
perform other day-to-day or ad hoc operations that are related to network device inventory
and configuration management. The Operate tab contains the dashboards, the Device Work
Center, and the tools that are needed for day-to-day monitoring, troubleshooting,
maintenance, and operations.
 Report: The Report tab is used to create reports, view saved report templates, and run
scheduled reports.
 Administration: The Administration tab is used to specify system configuration settings
and data collection settings, and manage access control.
• Discover or add (bulk/single) devices
• Work with configurations and images (SWIM)
• Check the status of your plug-and-play devices
• Network audit
• Launch Device Work Center from Operate menu or Getting Started view.
The Device Work Center provides a single screen overview and control of your network
devices. You can launch Device Work Center from the Operate menu or from the Getting
Started view after initial login. This screen allows you to view the device inventory and device
configuration information. The Device Work Center contains general administrative functions
at the top and configuration functions at the bottom of the screen.
The main tasks that network operators can perform in the Device Work Center are as follows:
 Device discovery
 Manual device addition (bulk/single device)
 Working with configurations and images
 SWIM
 Status verification of the plug-and-play devices
 Network audit
• Ways to add devices:
- Bulk import or single device addition
- Device discovery
Groups Discovery Add Device and Bulk Import
To view and manage the devices in the network, they must be added manually or discovered.
After Prime Infrastructure installation and initial login, the network operator can start adding
the devices. One of the ways to add a new device is from a Device Work Center.
The Device Work Center also displays device grouping. Device groups allow the network
operator to group devices based on location, type, or user-defined variables.
• Launch Device Discovery view from Device Work Center and click Add.
Fill in the following

parameters:
• Device IP
address
• SNMPv2/v3
credentials
• Telnet/SSH
credentials
• HTTP/HTTPS
credentials (if the
device is a NAM,
WAAS)
Prime Infrastructure must first discover the devices and, after obtaining access, collect
information about them. Prime Infrastructure uses both Simple Network Management Protocol
(SNMP) and Secure Shell (SSH)/Telnet to connect to supported devices and collect inventory
data.
Devices can be added manually, as shown in the figure. This is helpful if the network operator
wants to add a single device. In order to add all of the devices in your network, Cisco
recommends running discovery.
• Launch Device Discovery view from Device Work Center
• Click Discovery Settings and select New
Hover or click on the

button to view
settings.
Click + to expand
the setting option.
Enable the setting

and then choose
Add Row to add
entries.
Follow the format

guidelines.
Prime Infrastructure uses SNMP polling to gather information about your network devices
within the range of IP addresses you specify. If you have Cisco Discovery Protocol enabled on
your network devices, Prime Infrastructure uses the seed device that you specify to discover the
devices in your network.
Before running discovery, complete the following tasks:
 Configure SNMP credentials on devices: Prime Infrastructure uses SNMP polling to
gather information about your network devices. You must configure SNMP credentials on
all devices that you want to manage using Prime Infrastructure.
 Set syslog and trap destinations on devices: Specify the Prime Infrastructure server
(using the Prime Infrastructure server IP address and port) as the syslog and trap destination
on all devices you want to manage using Prime Infrastructure.
 Configure discovery email notifications: You will then receive email notification when
Prime Infrastructure has completed discovering the devices in your network.
• Launch the Jobs Dashboard from the Administration menu.
When discovery has completed, a network operator can verify if the process was successful. In
order to verify the discovery, check the Discovery type job from the Jobs Dashboard.
You can launch the Jobs Dashboard from the Administration menu by selecting the Jobs
Dashboards option. Additionally, you can launch the Jobs Dashboard from the Tools menu
under the Task Manager option.
In the Jobs Dashboard, network operators can verify job details for user-defined or system-
defined jobs. Device discovery is an example of a user-defined job. Interface, CPU, and
Memory poller jobs are additional examples of system-defined jobs.
• Configuration Archives provides stored configurations.
• Organized by device type, site groups, user-defined parameters.
• Use Schedule Archive to back up selected configurations.
Prime Infrastructure attempts to collect and archive the following device configuration files:
 Startup configuration
 Running configuration
 Virtual LAN (VLAN) configuration, if configured
Network operators can specify how Prime Infrastructure archives the configurations. Archiving
options are as follows:
 On demand: Prime Infrastructure collects the configurations of selected devices when the
network operator selects the Configuration Archives option from the Operate menu.
 Scheduled: Prime Infrastructure can schedule collection of the configurations of selected
devices and specify recurring collections. Recurring collections can be selected by clicking
Schedule Archive in the Configuration Archives option from the Operate menu.
 During inventory: Prime Infrastructure can collect device configurations during the
inventory collection process.
 Based on syslogs: If the device is configured to send syslogs when there is any device
configuration change, Prime Infrastructure collects and stores the configuration.
By default, Prime Infrastructure has the following configuration settings:
 It does not back up the running configuration before pushing configuration changes to a
device.
 It does not have Prime Infrastructure attempt to roll back to the previously saved
configuration in the archive if the configuration deployment fails.
 When pushing CLI to a device, it uses five thread pools.
• SWIM is the repository for device images.
• From SWIM you can back up, upgrade, import, and analyze your device
images.
Manually upgrading your devices to the latest software version can be error prone and time
consuming. Prime Infrastructure simplifies the version management and routine deployment of
software updates to your devices by helping you plan, schedule, download, and monitor
software image updates. You can also view software image details, view recommended
software images, and delete software images.
Prime Infrastructure stores all the software images for the devices in your network. The images
are stored according to the image type and version. Before you can upgrade software images,
your devices must be configured with SNMP read-write community strings that match the
community strings that were entered when the device was added to Prime Infrastructure.
You can specify image management preferences. These preferences can include whether to
reboot devices after successfully upgrading a software image, and whether images on
Cisco.com should be included during image recommendation of the device. Because collecting
software images can slow the data collection process, by default, Prime Infrastructure does not
collect and store device software images when it gathers inventory data from devices.
It can be helpful to have a baseline of your network images by importing images from the
devices in your network. You can also import software images from the Cisco web page and
store them in the image repository. By default, Prime Infrastructure does not automatically
retrieve and store device images when it collects device inventory data.
Prime Infrastructure can generate an Upgrade Analysis report to help you determine
prerequisites for a new software image deployment. These reports analyze the software images
to determine the hardware upgrades (boot ROM, Flash memory, RAM, and boot Flash, if
applicable) required before you can perform the software upgrade. The Upgrade Analysis
report answers the following questions:
 Does the device have sufficient RAM to hold the new software?
 Is the device’s Flash memory large enough to hold the new software?
 Do I need to add Telnet access information for the device?
• Image Dashboard shows top software images used in deployment of the
network.
The software image dashboard displays the top software images that are used in your network
and allows you to do the following:
 Change image requirements.
 See the devices on which an image is running.
 Distribute an image.
Assurance Management
This topic provides an overview of assurance management as a function of network
availability.
SNMP/CLI
Polling
ERSPAN
End-User Experience
SPAN/
Cisco Catalyst 3750-X
• Wired/wireless user experience

Cisco ASR • User 360
• Voice quality experience
Netflow
FNF
Cisco ISR
Visibility
WAAS
Wireless Controller
• Application traffic analysis and reporting
• Multi-NAM: Packet level debugging and troubleshooting
• WAN optimization visibility
PA
Netflow Generation
Application (Prime NGA)
Network Performance
MEDIA-
NET
• Device availability and Interface polling

• Event/alarm generation
Cisco 6509 • Configuration of devices for data and flow collection: NetFlow,
Medianet, PA, NBAR
NBAR
Network Analysis
Modules (Prime NAM)
NBAR
2
Assurance is a function for network and application availability as it relates to end-user

experience. Prime Infrastructure divides the problem of assurance into three sections:
 Network performance
 Application visibility
 End-user experience
Network performance management is a standard part of element management and relates to
device availability, interface polling, and an event and alarm generation from various parts of
the network. One very important aspect of the network performance in Prime Infrastructure is
how it relates assurance to lifecycle. It supports monitoring templates whereby you can
configure devices for data and flow collection, for example, NetFlow, NBAR, Flexible
NetFlow, and so on. This is unique to the Cisco solution. It not only supports intelligent
instrumentation in the network but also the ability to enable it.
Application visibility involves application classification and traffic analysis by leveraging
intelligent instrumentation in the network. This instrumentation includes packet analytics from
the NAMs deployed at various points in the network. Embedded instrumentation, such as
NetFlow, NAM, NBAR/NBAR2, AVC, and so on is what makes a Cisco network unique.
Once network and application visibility is provided, Prime Infrastructure correlates this
information with end user information it has from lifecycle management. Using this combined
data, Prime Infrastructure constructs a picture of the end-user experience of applications, such
as voice and video. With User 360 view, the network operator can interrogate users and see
how they are accessing the network. Operators can also see switch interfaces or wireless
controller information along with all the applications the users are running.
Prime Infrastructure acts as a collector for all information flows and, correlating them with the
client IP address information, it can then construct a total picture of assurance. The figure
provides a graphical representation of how flow and application data is collected from across
different sources in the network. Prime Infrastructure is leveraging NBAR2/PA/AVC for
branch visibility, NetFlow and Medianet in campus, NBAR2 for wireless, NGA for data center,
and so on.
• The Operate tab provides tools for the following:
- Monitoring the network on a daily basis.
- Performing other day-to-day or ad hoc operations relating to network device
inventory and configuration management.
• The Operate tab contains dashboards, the Device Work Center, tools for
day-to-day monitoring, troubleshooting, maintenance, and operations.
Under the Operate tab, Prime Infrastructure provides tools to help network operators monitor
their network on a daily basis. Tools are also available to perform other day-to-day or ad hoc
operations relating to network device inventory and configuration management. The Operate
tab contains the dashboards, the Device Work Center, and the tools you need for day-to-day
monitoring, troubleshooting, maintenance, and operations.
Prime Infrastructure automatically displays monitoring data in dashboards and dashlets. You
can choose one of the following dashboards by selecting the Monitoring Dashboard option in
the Operate menu to view summary information:
 Overview: Displays overview information about your network such as device counts and
the top five devices by CPU and memory utilization. From the Overview dashboard, you
can click device or interface alarms counts to view detailed dashboards and alarms and
events in order to help troubleshoot and isolate issues.
 Incidents: Displays a summary of alarms and events for your entire network, for a
particular site, or for a particular device. By clicking an item in the dashboard, you can
view details about the alarm or event and troubleshoot the problem.
 Performance: Displays CPU and memory utilization information.
 Detail Dashboards: Displays network health summaries for sites, devices, or interfaces.
• The Detail Dashboards provide many options for rich application visibility
and analysis: Site, Device, Interface, Application, Voice/Video, End User
Experience.
Experience
Server
Analysis
Detail dashboards display network health summaries for sites, devices, or interfaces. Many
different views are provided including Site, Device, Interface, Application, Voice/Video, and
End User Experience. These views allow network operators to see congestion in the network
and gather detailed site, device, and interface information. For example, you can view detailed
dashboards for a particular site to determine which devices have the most alarms, device
reachability status for the site, and so on.
Cisco Prime Assurance lets network operators investigate performance issues including any of
the following parameters:
 Raw server performance
 Competition for bandwidth from other applications and users
 Connectivity issues
 Device alarms
 Peak traffic times
This flexibility shortens troubleshooting time and provides quicker solutions. In the figure
below, a network administrator is responding to scattered complaints from multiple branches
about poor performance for a newly deployed application. The administrator suspects a
malfunctioning edge router at the application server site to be the problem, but needs to see if
other factors are contributing to the issue.
Several portlets are available out of the box for the dashboard.
• Troubleshoot the RTP
conversations using
key metrics like jitter,
loss, or MOS score.
• Identify worst site

by MOS scores.
To successfully diagnose and resolve problems with application service delivery, network
operators must be able to link user experiences of network services with the underlying
hardware devices, interfaces, and device configurations that deliver these services. This linking
is especially challenging with Real-Time Transport Protocol (RTP)-based services like voice
and video, where service quality, rather than gross problems like outages, impose special
requirements.
Cisco Prime Assurance makes this kind of troubleshooting easy. The following workflow is
based on a typical scenario:
1. A user complains to the network operations desk about poor voice quality or choppy video
replay at a branch office.
2. The operator first confirms that the user is indeed having a problem with jitter and packet
loss that will affect the RTP application performance.
3. The network operator further confirms that other users at the same branch are also having
the same problem.
4. The operator next confirms that there is congestion on the WAN interface on the edge
router that connects the local branch to the central voice/video server in the main office.
5. Further investigation reveals that an unknown HTTP application is using a high percentage
of the WAN interface bandwidth and causing the dropouts.
6. The operator can then change the unknown application’s differentiated services code point
(DSCP) classification to prevent it from stealing bandwidth.
• Add NAMs to Prime Infrastructure via Device Work Center using:
- Bulk device import or adding NAMs individually
- Discovering the NAMs and editing them to include the HTTP credentials
- To enable NAM data collection:
• Open the Data Sources view from the Administration menu.
• Expand the NAM Data Collector list.
• Select all of the NAMs for which you want to enable data collection and click
Enable.
• Manage NTP server configuration to synchronize the clock between
Prime Infrastructure and NAMs.
• Enabling Flexible NetFlow data collection.
If Prime Infrastructure implementation includes Assurance licenses, the network operator needs
to enable data collection via NAMs and NetFlow configurations. This enabling is necessary to
populate the additional dashlets, reports, and other features that are supplied with Assurance.
Prime Infrastructure provides multi-NAM management, centralizing data collection from
multiple NAMs. Simultaneous packets captured on multiple NAMs are stitched together and
shown in a unified view.
In order to collect data from NAMs, NAM data collection must be enabled. The network
operator can enable data collection for each discovered or added NAM, or for all NAMs at
once. Open Data Sources view from the Administration menu and expand NAM Data
Collector list. Select all of the NAMs for which you want to enable data collection and click
Enable.
In order to start collecting NetFlow and Flexible NetFlow data, the network operator must
configure NetFlow-enabled switches, routers, and other devices to export this data to Prime
Infrastructure. Prime Infrastructure provides an out-of-the-box configuration template that
allows you to set this export up quickly. You can apply it to all or just a subset of your
NetFlow-enabled devices.
The use of templates for the configuration of Flexible NetFlow assumes that the network
operator wants to configure all types of NetFlow-enabled devices in the same way. Different
templates can be used for the following tasks:
 Create a separate configuration for each type of device.
 Vary exporter or monitor names.
 Set up multiple flow exporters or monitors on the same device type.
 Set up data export for multiple interfaces on a particular type of device.
Select from one of the
data sources:
• NetFlow
• Flexible NetFlow
• NAM NetFlow
• NAM Data Port
Select:
• Number of rows
to present
• Traffic types
• Apply filters
Several views within Detail Dashboards are contributing to a wide set of information that is
provided by Prime Infrastructure. Site view of the detailed dashboards provides the possibility
to see the right information from the right source.
Various filters and options allow the user to customize the view and focus on the required data.
Multiple dashlets of the same type can be added to one dashboard, while applying different
settings to each one.
Operationalizing the Cisco Advantage
This topic describes how the Cisco advantage automates and drives efficiencies in the use of
customer equipment.
Simplify the deployment and

management of Cisco differentiated
technologies and platforms.
Use Cisco expertise and best

practices to improve network design
and troubleshooting.
Integrate with Cisco knowledgebase

to automate key tasks and make
more informed decisions.
Support new Cisco platforms and

technologies the day they ship.
One of the goals of Prime Infrastructure is to accelerate the time to value for customers using
Cisco equipment. This will make the design and fulfillment of network services fast and
efficient thus accelerating deployment.
Another goal of PI is to drive efficiencies, optimizing the use of customer equipment for
managing their networks. PI will also lower capital expenditures through an architecture that is
designed to drive out costs and drive up efficiencies.
Currently many networks are operated by highly skilled and high-cost operators that use a
manual approach (such as CLI scripts) to manage their networks. With PI, the goal is to
automate core processes making it much faster to provision services, diagnose, and repair
problems, and so on.
Without good instrumentation, determining the root cause of a network service outage can be
very time consuming. Faults can occur for a variety of reasons and are often caused by human
error due to highly manual processes. With PI the quality of service improves through the
monitoring and management of network events. A common problem for technology
organizations is that of taking a compartmentalized approach to managing services. Often,
specific teams will manage areas of technology. The result can be a lack of complete visibility
into the network services. As a result, when outages occur they can take longer to resolve.
The Cisco point of view is that service providers need to transition from managing the network
to managing the subscriber experience lifecycle. This approach means automating key aspects
of the lifecycle and encouraging the technology functions to work together with a common
understanding of the business impact of the network services they provide.
• Day 0 ZTD for switches and routers
- Plug and play gateway embedded in PI 2.0.
- Includes Apple iOS plug and play app allowing anyone to
stage and push a configuration.
• Day 0/day 1 deployment of unified access devices
- Deployment workflow for tier 1/tier 2 engineers, with multi-
tabbed template mode for advanced engineers.
- Optimized deployment based on best practices.
- Cisco recommended mobility domain configurations based on
number of APs to be deployed.
- Simplified guided guest access configuration.
Prime Infrastructure allows quick and easy deployment of new devices, using simple day 0/day
1 deployments workflows. These wizard-based workflows guide the network operator through
the process of configuring a new device in a simplified way.
Examples of areas that are covered in the workflows are as follows:
 Device credentials
 VLAN creation
 Trunking, uplinks
 Wireless (3850, 5760)
 Site association
Note Devices that are configured with the day 0/day 1 deployment workflows are automatically
added to Prime Infrastructure’s Device Work Center and then managed by the system. This
eliminates the need to add or discover the devices separately.
• Prime Infrastructure 2.0 includes the following:
- A powerful templating engine, allowing customers to build
templates for efficiency and automation.
- Templates reflecting best practices that are used to turn on
IOS features.
- Including One-Click AVC, Zone-Based Firewall, Medianet,
and so on.
• Readiness assessments are used to prepare networks
for specific technologies, including TrustSec 2.0 and
IPv6.
Configuring and deploying updates to the network has been made easier with the built-in
feature templates. These templates incorporate Cisco Smart Business Architecture (SBA)
templates that are based on Cisco validated designs, simplifying platform and technology
rollout and reducing the chance for errors.
Prime Infrastructure 2.0 adds AVC-dedicated templates that allow the user to deploy a
validated AVC configuration in one click, or configure a customized AVC template.
Prime Infrastructure 2.0 also adds a new TrustSec deployment environment. This environment
provides TrustSec network readiness assessment, simplified configuration, and reporting.
• Simplify
troubleshooting
and remediation
by correlating
various sources Context Policy
of information.
• Brings together
multiple sources
of information for
effective
problem
isolation.
• Uses 360 views Applications Connectivity
for:
- Users
- Devices
- Interfaces
- Applications
User 360
The concept of a 360-degree view in Prime Infrastructure was designed to simplify the
consumption of data for a specific object, while gathering information from various sources.
A Device 360 view was previously introduced with PI 1.2. User, Application and Interface 360
views were added to Prime Infrastructure 2.0.
One of the main advantages of the 360 views is that they are overlaid on an existing screen.
This allows the PI user to receive important information about the relevant object (User,
Device, Application, Interface) without the need to migrate to another screen or separate view.
• Real-time contextual user
details:
- Context, location
- Client device type
- Session
- Connectivity
- Visibility of application traffic
- Alarms
New for Prime Infrastructure 2.0, the User 360 view provides information on a specific user,
which includes all of the user’s clients.
This unique view is available from nearly any screen where a username is shown, or by using
the search capability for finding the various users in PI’s database.
The User 360 view gathers information from sources, including ISE- and MSE-sourced data.
This provides a single location for the following different type of data:
 Location, through MSE integration
 Client device type, through ISE profiling
 Connectivity, wired or wireless, which is based on WLC and switch data
 Visibility of application traffic such as AVC or NAM
 Alarms, based on the device to which the user is connected
 Policy, through ISE integration
• Real-time contextual device
details from the device
perspective:
- Device name
- Location, type
- System uptime
- Operating system version and
status
- CPU and memory utilization
- Interface status type
- Visibility of application traffic
• Take actions
- Open TAC
The Prime Infrastructure Device 360 view provides real-time contextual detailed device
information from the device perspective. These details include the following:
 Device name, location, type with system uptime, and device status
 Operating system version and status
 CPU and memory utilization
 Interface status type and visibility of application traffic
Device status indicates whether the device is reachable, is being managed, and is synchronized
with the Prime Infrastructure database.
The second half of the device 360 view provides access to several tabs as follows:
 Modules tab lists the device modules and their name, type, state, and ports.
 Alarms tab lists alarms on the device, including the alarm status, time stamp, and category.
 Interfaces tab lists the device interfaces and the top three applications for each interface.
 Neighbors tab lists the device neighbors, including their index, port, duplex status, and
sysname.
You can see the Device 360 view from nearly all screens in which device IP addresses are
displayed. It provides a quick snapshot to isolate and troubleshoot device-related issues.
Additional tool icons are available on the top right of the Device 360 view and provide access
to the following additional Prime Infrastructure views:
 Alarm Browser: Launches the Alarm Browser.
 Support Community: Launches the Cisco Support Community.
 Support Request: Allows you to open a support case.
 Ping: Allows you to ping the device.
 Traceroute: Allows you to perform a traceroute on the device.
To launch the 360 view of any device, mouse over a device IP address, and then click the icon
that appears.
Note The features that appear on the 360 view differ depending on the device type.
• Interface 360 views show the
following:
- Interface status, speed, and type
- Interface alarms
- Interface utilization, errors, and
discards
- Interface application traffic
New for Prime Infrastructure 2.0, the Interface 360 view provides information on a specific
Interface.
Interface 360 includes the following information:
 Status information
 Alarms
 Utilization, errors
 Interface application traffic
• Prime Infrastructure integrates with Cisco backend systems for
increased visibility into impact analysis.
• PSIRT (Security Advisories) reports provide an analysis on which
devices are impacted based on:
- IOS version running on the device.
- How the device is configured.
• EoX reports provide a lifecycle management analysis on the devices.
- Shows devices that are or will be “End-of-Sales” or “End-of-Support.”
- Allows customers to budget for upcoming refresh.
• One-click access to related posts and discussions on Cisco forums.
• One-click creation of TAC case.
- Device and SmartNet contract number automatically populated.
- Common supporting documents automatically forwarded to TAC.
Tight integration between Prime Infrastructure and Cisco’s online knowledge base allows PI to
offer unique capabilities in reporting. PI also offers the following support “lifelines” when
needed:
 PSIRT and EoX reports are available based on Cisco’s security advisories and End-of-Life
announcements. Prime Infrastructure combines the discovered network inventory data
available in the system’s database with the EoX/PSIRT information available on
Cisco.com. This combination allows PI to provide these unique reports immediately when
needed.
 Consult and view information at the Cisco Support Community by launching it from
various screens.
 Open a Cisco Technical Assistance Center (TAC) Support Request quickly with minimal
effort. The user chooses the device for which the case will be opened. Prime Infrastructure
adds the serial number, contract number, show tech (if needed), alarm history, and more.
• Many reports can be generated to run on an immediate and scheduled
basis.
• Report Launch Pad is the hub for all Prime Infrastructure reports.
Cisco Prime Infrastructure reporting is necessary to monitor the system and network health as
well as troubleshoot problems. A number of reports can be generated to run on an immediate
and scheduled basis. Each report type has a number of user-defined criteria to aid in the
defining of the reports. The reports are formatted as a summary, tabular, or combined (tabular
and graphical) layout. Once defined, the reports can be saved for future diagnostic use or
scheduled to run and report on a regular basis.
Reports are saved in either comma separated value (CSV) or PDF format and are either saved
to a file on Prime Infrastructure for later download or emailed to a specific email address.
The Reports menu provides access to all Prime Infrastructure reports as well as currently saved
and scheduled reports. The Reports menu has the following options:
 Report Launch Pad: The hub for all Prime Infrastructure reports. From this page, you can
access specific types of reports and create new reports.
 Scheduled Run Results: Allows you to access and manage all currently scheduled runs in
Prime Infrastructure. In addition, allows you to access and manage on-demand export as
well as emailed reports.
 Saved Report Templates: Allows you to access and manage all currently saved report
templates in Prime Infrastructure.
The reporting types include the following:
 Current: This type provides a snapshot of the data that is not dependent upon time.
 Historical: This type retrieves data from the device periodically and stores it in the Prime
Infrastructure database.
 Trend: This type generates a report using aggregated data. Data can be periodically
collected based from devices on user-defined intervals, and a schedule can be established
for report generation.
With Prime Infrastructure, you also have the ability to export any report. You can then view
reports, sort reports into logical groups, and archive reports for long-term storage.
Cisco Prime Infrastructure Field Resources
This topic covers the Cisco Prime Demo series and other resources useful for customers,
partners , and employees.
http://nmtg/pyc
By exception For extensions or existing:
Need Evaluation Licenses? Download evaluations
ask-prime-infrastructure
Need Information on Competitive analyses; By exception Send an email to ask-prime-

Competitors systems infrastructure
By exception
Technical Issues Review FAQ Open a TAC Case
Commercial/Licensing By exception Send an email to ask-prime-

Review FAQ
Issues infrastructure
Need Customer-Facing Go to the Field Enablement

Collateral/OGs Kit
By exception
Leverage global Prime Send an email to ask-prime-
Customer Demos
Demo Series infrastructure
Want to Influence Your

Access our RFx template
Customer?
By exception
Send an email to ask-prime-
Need RFQ/RFP Help? Leverage TSN
infrastructure
Access Demo
View demo servers here
Servers/Scripts
By exception
Send an email to ask-prime-
Need Training/VoDs View full inventory
infrastructure
Field Team Updates Contact Theater BDM Lead
The figure describes optimal ways to communicate with the business unit for a variety of
issues.
Americas Edition
Every Week* Prime Demo Series Topic Time Place
Every Monday Cisco Prime LMS 11 a.m. PT www.tinyurl.com/primedemo
(90 mins.) No registration required
Every Tuesday Cisco Prime Collaboration Assurance and Provisioning
San Jose
Every Wednesday Cisco Prime NAM and NGA Time
Every Thursday Cisco Prime Infrastructure (including Assurance)
Every Wednesday Cisco Prime Data Center Network Management (DCNM) 9 a.m. PT www.tinyurl.com/primedcnm
(60 mins.) Password: dcnmdemo
*Exceptions: US public holidays and Cisco shutdown
APJC Edition
Every Week* Prime Demo Series Topic Time Place
Every 2nd Thursday Cisco Prime Infrastructure Lifecycle Management and 12 p.m. www.tinyurl.com/prime-APJC
Assurance SGT No registration required
(90 mins.)
Every 2nd Thursday Cisco Prime Collaboration Assurance and Provisioning
Singapore
(alternating week)
Time
*Exceptions: Indian public holidays and Cisco shutdown
EMEAR Edition
Day Prime Demo Series Topic Time Place
See schedule Cisco Prime Infrastructure (including Assurance) 9:30 a.m. www.tinyurl.com/prime-emear
(biweekly) GMT Registration is required
Cisco Prime Collaboration Assurance and Provisioning
(90 mins.)
Free trial software: www.cisco.com/go/nmsevals

Customers, partners, and Cisco employees who are looking for more information on the various
Prime products are invited to participate in the Cisco Prime Demo Series. This series is an
interactive demo of Cisco’s various Prime applications. Each demo is 90 minutes in length with
a 30 minutes introduction and slides, and 60 minute demo.
During these sessions, you will hear from product experts on how Cisco’s various Prime
applications can help with the following:
 Efficiently manage and troubleshoot Cisco networks (wired and wireless) and network
services (video and voice).
 Optimize the configuration of IOS features and instrumentations.
 Gain end-to-end visibility across the network right down to applications and end-user
clients.
The Cisco team of experts covers a different solution each weekday. The time and place
(WebEx ID) are the same for all four weekly sessions. Each of the four weekly sessions covers
a different Prime application. You are encouraged to ask questions throughout the session.
Similar sessions are available for APJC and cover Prime Infrastructure and Prime Collaboration
every second week. Prime Demo Series also cover the EMEAR region, which is based on a
published schedule.
• Detailed, 18-segment quick-start
videos on demand cover
essentials of how to download,
deploy, configure, and
customize Prime Infrastructure.
• Available on Cisco’s YouTube
Channel and PEC
• http://www.youtube.com/playlist
?list=PL7406F0EF2BC7DED8
Cisco makes available several videos for Prime Infrastructure 2.0 and its installation. They are
available on You Tube on the Cisco channel.
Tip Cisco recommends viewing the following two videos before starting the lab for this module:
- Getting Started VOD available at http://www.youtube.com/watch?v=sFrPLfykj6Y
- Deploying the Virtual Environment VOD available at

http://www.youtube.com/watch?v=BBgX9-UvL2w
• Single pane of glass for true converged wired/wireless
lifecycle and assurance management. No other vendor
does this.
• Centralized policy integration (Prime and ISE) is
unique in the industry.
• Deploy and configure Cisco devices more efficiently
and rapidly.
• Easy to enable Cisco best practices engineered into
IOS and instrumentation.
• Power of embedded intelligence inherent in a Cisco
network improves application delivery and end-user
experience by using Prime NAM, Medianet, AVC,
NetFlow, and NBAR2.
The figure summarizes the key features of Cisco Prime Infrastructure.
Summary
• The Cisco Prime Infrastructure provides converged management of

wired and wireless network infrastructure.
• The Cisco Prime Infrastructure is a network management tool that
supports lifecycle management of your entire network infrastructure from
one graphical interface.
• The device 360 view provides real-time contextual detailed device
information from the device perspective.
• The Cisco Prime Infrastructure supports an assurance as a function for
network and application availability and relates to end user experience.
• Detailed dashboards contribute to a abundance of information provided
by Prime Infrastructure and provide the right information from the right
source.
• Several best practices can optimize the operation of Prime
Infrastructure: Limiting collection of data, aggregated data, Shorter
retention, and off loading of backups and reports are used to save
storage space.
References
For additional information, refer to http://www.cisco.com.
Module Self-Check
Q1) Which of the following modules are available in Prime Infrastructure? (Choose two.)
(Source: Prime Infrastructure Overview)
A) Assurance
B) Classic
C) Lifecycle
D) NAM
E) Design
Q2) Which two legacy management systems were replaced by Prime Infrastructure?
(Choose two.) (Source: Prime Infrastructure Overview)
A) WCS
B) NCS
C) LMS
D) Cisco Works
E) Prime Management System
Q3) Prime Infrastructure integrates with which three of the following? (Choose three.)
(Source: Operationalizing the Cisco Advantage)
A) ISE
B) LMS
C) NAM
D) MSE
E) NCS
Q4) Which three types of data does PI consolidates in a unique way? (Choose three.)
(Source: Operationalizing the Cisco Advantage)
A) Location
B) Policy
C) NetFlow
D) Configuration archive
E) End user experience for wired and wireless
Q5) Which three types of 360 views are available with PI 2.0? (Choose three.) (Source:
Operationalizing the Cisco Advantage)
A) Network
B) Device
C) User
D) Mediatrace
E) Application and Interface 360 views
© 2013 Cisco Systems, Inc. CONFIDENTIAL Converged Access Solution Design Overview 2-45
Q6) Name the two installation options available for PI? (Choose two.) (Source: Prime
Infrastructure Overview, Direction, and Roadmap)
A) Physical appliance
B) Distributed
C) Web-based installation
D) Virtual appliance
E) Windows installer installation
Q7) Which screen is used to add/remove/discover network elements? (Source: Lifecycle
Management of Wired/Wireless Devices)
A) Plug and Play Status
B) Device Work Center
C) Data Sources
Q8) Which five of the following are sources of PI assurance data? (Choose five.) (Source:
Assurance Management)
A) NAM
B) WLC AVC
C) NetFlow
D) Catalyst 6500 series MPA
E) ASR/ISR AVC
F) NGA
Q9) How does PI help to leverage the Cisco Advantage? (Source: Assurance Management)
Q10) What is the easiest way to learn how to install and set up PI? (Source: Cisco Prime
Infrastructure Field Resources)
Q1) A,D
Q2) B,C
Q3) A,C,D
Q4) A,B,E
Q5) B,C,E
Q6) A,D
Q7) B
Q8) A,B,C,E,F
Q9) PI provides a single pane of glass for true converged wired and wireless lifecycle and assurance
management as well as centralized policy integration (Prime and ISE.)
Q10) Watch the quick start VoDs
Module 3
One Policy Foundation

Lesson 1
Basic Cisco ISE AAA and

Guest Server Setup for Wired
and Wireless Networks
Overview
Upon completion of this module, the learner will be able to describe the basic Cisco Identity
Services Engine (ISE) authentication, authorization, and accounting (AAA) setup and guest
server setup for wired and wireless networks.
Objectives
Upon completing this lesson, you will be able to meet the following objectives:
 Explain and configure Cisco ISE in the HTA Hospital network to authenticate users
 Explain and configure the setup of authorization rules in Cisco ISE using Microsoft Active
Directory and downloadable access control list (dACL)
 You will understand the process of setting up access to a guest server using Cisco ISE
 You will explain the process, requirements, and implementation of authentication and
authorization rules in compliance with HTA Hospital policies
Cisco ISE Solution Overview and Positioning
This topic provides an overview of the Cisco ISE solution and describes its position in the
marketplace.
• End-user expectations • IT trends

- There will be more - 50% of workloads are
than 15 billion devices virtualized
by 2015 to increase efficiency
- The average worker - 2/3 of workloads will
has 3 devices be in the cloud by
- New workspace: 2016
anywhere, anytime - 71% of the world’s
- 71% of Gen Y mobile data traffic will
workforce does not be video in 2016
obey policies - Mobile malware has
- 60% will download doubled (2010 to
sensitive 2011)
data onto a personal
device
Reduce Security Risk Improve End User Increase Operational

Productivity Efficiencies
© 2013 Cisco and/or its affiliates. All rights reserved. CONFIDENTIAL One Policy Foundation UASEBC v1.0—3-6
According to a 2012 report by Gartner, by 2014 the personal cloud will have replaced the
personal computer as the center of the user’s digital life.
Currently, the average number of devices per user is three.
The following are additional interesting statistics:
 70 percent of organizations have a formalized bring your own device (BYOD) program or
plan to have one.
 50 percent of organizations allow executives to bring their own device with or without
restrictions
 88 percent of organizations believe that the use of personal devices increases employee
satisfaction
This has led to an explosion of new, uncontrolled devices showing up on the secure network.
You need a solution that can support these devices without impairing the efficiency and
efficacy of IT staff.
• BYOD provides improved productivity, lower cost, and added security
- Challenge: Support BYOD without increasing IT operational costs
- Solutions: Zero-touch portal automates device registration, application
containerization, device posture.
• Secure access control leads to device visibility (profiling), posture,
contextual control, and AAA.
- Challenge: Identifying what is on the network
- Solutions: Device fingerprinting (identifying “things”), posture analysis
• Consistent network wide policy control means differentiated access
control
- Challenge: Ensure consistent E2E policy that is topology independent
- Solutions: Cisco TrustSec and policy management
TECHNOLOGY UTILITY ENERGY HEALTHCARE HIGHER ED SECONDARY ED
Data is merging. By 2015, 60% of data will be moved to virtualized environment. How will
you manage this merge?
The workplace is segmenting and changing. You have to keep up and understand how to give
the right type of access to the right person. How can you assure the correct access?
The answer that Cisco provides is One Policy, One Management, One Network.
The work of putting the device on the network, registering the device, putting the device in the
right container, checking the health of the device—all needs to be pushed back to the user but
seem relatively seamless to the user.
You also need a way to identify the type of device. Is it an iPad, is it Mac or Windows?
Profiling will be discussed later in the course. You also need a way to look for additional
details on the device, like process and applications registries. If there is something on the
device that is contrary to corporate policies, can you shut down that device or application?
Security posture will be discussed later in this course.
All of these functions have to be deployed in a centralized end-to-end policy over both the
wired and wireless networks of the entire organization. This need is not tied to just one industry
or environment. The figure shows just a few of the Cisco partnerships that Cisco has made
across various and diverse industries.
© 2013 Cisco Systems, Inc. One Policy Foundation 3-5

• Policy management solution Gartner 2013 NAC MQ
- Unified network access control
- Turn-key BYOD solution
- First system wide solution
- Deep network integration
- System wide policy control
from one screen
- Award-winning product
• 2012 Cisco Pioneer Award
- Over 400 trained and
trusted ATP partners
- Over 1000 wins in year 1
In 2012, Cisco ISE won the 2012 Pioneer Award which is the first systemwide integration.
Cisco ISE provides a single screen to manage wired employees, wireless guests, as well as
remote VPN employees.
Access control is an architecture. Cisco offers a program to certify and train partners. The
partners go through one week of extensive training, and then pass an exam, and their first three
designs must be approved by Cisco or someone in their organization who is fully trained. To
sell a stock-keeping unit (SKU) with advanced wired or wireless features, you must be a
certified Cisco Authorized Technology Provider (ATP). Partners who are not ATP certified can
work with Cisco or select specialists who are certified.
Secure Access on Wired,
Wireless, and VPN BYOD
Control with one policy across wired, Users get on the Internet
wireless, and remote infrastructure safely, fast, and easy
Guest Access Cisco TrustSec Network Policy

It’s easy to provide Rules written in business terms
guests limited time and resource access controls access
Cisco ISE addresses some core secure access use cases. Those use cases include BYOD where
personal devices come onto the network and guest services to offer safe and seamless network
access to nonemployees. Cisco ISE helps to simplify secure access policy across wired,
wireless, and remote networks for users and devices.
A policy-based networking approach helps IT staff to accomplish business goals. For example,
staff may give authorized users, such as doctors and nurses, access to sensitive data when they
are in certain locations or using specific devices, while restricting access from other locations
or from other devices. For a more precise example, a policy might permit a doctor to access
data from anywhere using a hospital laptop, but restrict access to a specific resource from a
personal device outside the office. In regards to HTA Hospital, the network administrator has
decided to take this approach for managing the access and authorization requirements for the
hospital staff and guests by establishing policies to allow them to access to resources they need.
A policy is broadly defined as “a definite course or method of action to guide and determine
both present and future decisions.”
As an administrator, ask the following questions:
1. How are you currently managing BYOD?
2. Can you enforce security policy consistently across wired, wireless, and remote access
networks?
3. How do you expect to control security all the way into a virtual data center?
4. Can you enforce secure access with efficiency?
5. What scenarios are critical to your organization?
There is an entire guest life cycle process that is built into Cisco ISE. As an example, a sponsor
securely logs in and creates guest user accounts for patients to get to a select internal server, yet
Cisco ISE can still allow visitors to log in, and create their own self registered accounts to get
to the Internet. This ability includes reporting, auditing and a way to suspend and reinstate
accounts through a single pane.

Within Cisco ISE, you can write policies that are business relevant and that pertain to your
organizational needs.
WHO
Identity Security Policy

Context WHAT Attributes
Business-Relevant
WHERE
Policies
ISE
WHEN
Wired VPN
HOW Wireless
VM client, IP device, guest, employee, remote user
Replaces AAA and RADIUS, NAC, guest management, and device identity servers
You can address multiple attributes that Cisco ISE combines to form a context to which a
policy is applied. As the context changes, the policy being applied can change as well.
Users will have a seamless experience with all forms of access, whether wired, wireless, or
VPN (remote).
This product will improve security while improving the user’s quality of experience and while
reducing IT hassles and errors.
It is important to remember that device identity and BYOD is not just about iPads and iPhones.
There are many types of devices that may need to access the network, including the following:
 Cisco access points (APs) (basic IT operations)
 Lenel door access or badge reader (Physical security)
 Rockwell manufacturing programmable logic controller (PLC) (manufacturing)
 Draeger infusion pump (healthcare)
 Microsoft Xbox 360 (higher education)
 Video surveillance cameras (which are currently being moved from isolated analog
networks to the IP infrastructure, and their numbers are increasing to $2.4 billion market in
2017 with compound annual growth rate [CAGR] of 31.5 percent)

Policy
Management
Cisco ISE Cisco Prime Infrastructure
Policy
Information
User Directory Profiling from Cisco Infrastructure Posture from End-Point Agents
Policy
Enforcement
Cisco Infrastructure: Switches, Wireless Controllers, Firewalls, Routers
Today’s networks must accommodate an ever-growing array of consumer IT devices while

providing user-centric policy and enabling global collaboration. The Cisco TrustSec
architecture addresses this shift by using identity- based access policies to tell you who and
what is connecting to your network, allowing IT to enable appropriate services without
sacrificing control.
The first release of Cisco ISE focused on the pervasive service enablement of Cisco TrustSec
for Cisco Borderless Networks.
The TrustSec portfolio is enhanced with the introduction of the new policy manager, Cisco ISE.
Cisco ISE delivers all the necessary services that are required by enterprise networks—AAA,
profiling, posture, and guest management—in single appliance platform. Cisco ISE can be
integrated in Cisco Prime Infrastructure as well, which will be discussed later in the course.
Policy information points and the platform for delivery of services is Cisco ISE. This layer is
where the information that ISE needs is stored or collected. The external identity sources could
be Microsoft Active Directory and or Lightweight Directory Access Protocol (LDAP)
directories. Cisco ISE collects profiling information from sensors on the network access
devices (NADs) and posture information from Network Admission Control (NAC) agents
pushed out to or installed in Cisco AnyConnect on the endpoints.
Policy enforcement is provided by Cisco infrastructure. This layer includes the network devices
that will actually carry and control the traffic. The policy enforcement points are the switches,
wireless LAN controllers (WLCs), firewalls, and routers. In Cisco ISE, they are configured as
the network devices and referred to as NADs.
• Centralized Policy
ACS
• RADIUS Server
Profiler • Posture Assessment
• Guest Access Services
Guest
Server
• Device Profiling
ISE
NAC
Manager • Monitoring
NAC • Troubleshooting
Server
• Reporting
Cisco ISE consolidates the following servers into a single server:

 Access Control Server (ACS) used as the RADIUS server for authentication and
authorization
 NAC profiler that is used for device fingerprinting
 NAC guest server that is used for guest services
 NAC manager and NAC servers that are used to manage and control services for wireless
and VPN users
Cisco ISE provides the following services as well as monitoring, reporting, and troubleshooting
from a single pane of glass:
 Consolidates services and software packages, which includes simplification of deployment
and administration tasks.
 Provides a session directory to track active users and devices
 Offers flexible Cisco ISE service deployment to optimize where Cisco ISE services run
 Delivers extensibility of applied policies for linked policy information points
 Manages security group access to keep the existing logical design
 Systemwide monitoring and troubleshooting capabilities, to consolidate data and give a
“three click” drill in capability for troubleshooting

Policy Administration Node (PAN)
• Interface to configure policies and manage ISE deployment
• Writeable access to the database
Policy Service Node (PSN)

• Makes policy decisions
• RADIUS server and destination for profiling data
Monitoring and Troubleshooting Node (MnT)

• Interface to reporting and logging
• Destination for syslog from NADs
Inline Posture Node (IPN)

• Enforces policy
A Cisco ISE node is a running installation of the Cisco ISE software. This installation can be
on a physical appliance or on a virtual machine (VM) within a VMware environment.
There are three major collections of Cisco ISE services that are organized into personas. These
personas are responsible for different functions within the Cisco ISE architecture. They may be
collocated on a single node or distributed across multiple nodes.
The three personas include the following:
 Policy administration persona: This persona is the interface for configuring policies. This
persona is the control center in the Cisco ISE deployment, controls the licensing, and
contains the user interface. The administration persona is also responsible for pushing the
configurations out to other nodes in a distributed deployment. Nodes that implement the
policy administration persona are often referred to as policy admin nodes (PAN).
 Policy service persona: This persona is an engine that makes policy decisions. This
persona is the main run-time engine that processes the entire network messaging that
pertains to Cisco ISE deployment. This messaging includes DHCP, Cisco Discovery
Protocol, NetFlow, and RADIUS, among others. Nodes that implement the policy service
persona are often referred to as policy service nodes (PSN).
 Monitoring persona: This persona is the interface for logging and reporting data. This
engine collects all logs and correlates them. In addition, this persona generates reports and
any alarms for the Cisco ISE system. Nodes that implement the monitoring persona are
often referred to as monitoring nodes (MnT).
Finally there is an inline posture node (IPN). Adaptive security appliances (ASAs) currently do
not support RADIUS Change of Authorization (CoA) for profiling and posturing of VPN
tunnels. You need an IPN to act as the proxy RADIUS policy enforcement point between the
ASA firewalls and the PSN. The IPN could also be used between Cisco APs and the PSN as a
RADIUS Proxy. It should be noted that the IPN cannot run on the same hardware as any of the
other personas.
Network Monitoring and Policy Service Policy Admin
Access Device Troubleshooting Node, The “Work- Administration
Access-Layer Logging and Horse” Node: All
Device Reporting Data RADIUS, Profiling, Management UI
Enforcement WebAuth, Posture, Activities and
Point for All Sponsor Portal Synchronizing
Policy Client Provisioning All ISE Nodes
NAD MnT PSN PAN
Policy Sync
RADIUS from NAD to PSN
RADIUS response from PSN to NAD PSN queries

User RADIUS Accounting external
database
syslog directly
syslog
How do all these personas work together?

First, the administrators will log in to the PAN where they will configure Cisco ISE with the
deployment infrastructure and deployment policies. Once the policies are completed, the
policies are synced to the PSNs and audited to the MnT.
The user connects to the NAD, which is the switch or WLC, which generates a RADIUS
Authentication request from the NAD, which is the RADIUS client, to the PSN, and the
RADIUS server.
The PSN checks the authentication rules and queries the appropriate user database, internal
Active Directory or LDAP, to verify the authentication credentials.
Based upon the response for the user database, the PSN will locate the correct authorization
profile that is to be applied to the user. These policies, which may include downloadable ACLs
(dACLs), virtual LANs (VLANs), voice domains, and even security group tags (SGTs) via
RADIUS response to the NADs.
The NADs will action the policies by applying the dACLs, VLAN, or SGT to the users’ traffic
via session numbers. The NAD will also send RADIUS accounting messages to the PSN. The
PSN will correlate the messages and forward all the session audit and syslogs to the MnT.

ISE Node
Standalone Distributed Deployment

Deployment
Primary Secondary
PAN Admin PAN PAN Admin
Secondary Primary
MnT MnT MnT
Monitoring Monitoring
PSN PSN PSN
Maximum endpoints – Maximum endpoints – 10,000 (platform dependent)***

(platform dependent) Redundant sizing – 10,000 (platform dependent)
•2000 for 33x5
•5000 for 3415
•10,000 for 3495 ***
Cisco ISE can be installed on both hardware and VMs (ESXi or ESX). Standalone deployment
keeps all three personas on a single node which will support up to 2000 endpoints on the Cisco
ISE 33x5 platforms or 5000 and 10,000 endpoints on the new Cisco ISE 3415 and Cisco ISE
3495 platforms respectively.
In a distributed deployment, you will need a minimum of two nodes with the primary PAN on
one node and the secondary PAN on the other node. For performance and load splitting, it is
recommended that the primary PAN and the secondary MnT be collocated as the well as the
secondary PAN and the primary MnT. It should be noted that even though you now have two
PSNs the maximum endpoints remains at 2000, 5000, or 10,000.
Platform Cisco ISE Appliance Cisco ISE Appliance Cisco ISE Appliance
3315 (Small) 3355 (Medium) 3395 (Large)
Process 1 x QuadCore 1 x QuadCore 2 x QuadCore Intel
Intel Core 2 CPU Intel Xeon CPU Xeon CPU E5504
Q9400 E5504 @ 2.00 GHz
@ 2.66 GHz @ 2.00 GHz (8 total cores)
(4 total cores) (4 total cores)
Memory 4 GB 4 GB 4 GB
Hard Disk 2 x 250-GB SATA 2 x 300-GB SAS 4 x 300-GB SFF SAS
HDD drives drives
(250 GB total disk (600 GB total disk (600 GB total disk
space) space) space)
RAID No Yes (RAID 0) Yes (RAID 0 + 1)
Ethernet NICs 4x Integrated Gigabit 4x Integrated Gigabit 4x Integrated Gigabit
NICs NICs NICs
Concurrent 3000 maximum 6000 maximum 10,000 maximum
Endpoints
http://www.cisco.com/en/US/docs/security/ise/1.0.4/install_guide/ise104_ovr.html#wp1103032
In a fully distributed deployment, the policy service persona would be running on its own node
with no other persona running and be referred to as a PSN. Before Cisco ISE 1.2, the software
was a 32-bit operating system. The maximum number of concurrent sessions is limited to 3000,
6000, and 10,000 respectively on the 3315, 3355, and 3395.

• Cisco Secure Network Servers
- Based on the Cisco UCS C220 Server, but designed for the following:
• Cisco Identity Services Engine (ISE)
• Network Admission Control (NAC)
• Access Control Server (ACS)
SNS-3415-K9 and SNS-3495-K9
With Cisco ISE 1.2, there is a new 64-bit software that runs on the new platforms. What’s new
in 1.2? What is new is 64-bit software running on the new platforms.
Cisco secure network servers are based on the Cisco UCS C220 Server, but designed for Cisco
ISE, NAC, and ACS.
Secure Network Services Secure Network Services
Appliance SNS-3415-K9 Appliance SNS-3495-K9
Processor 1 - QuadCore Intel Xeon 2 - QuadCore Intel Xeon
2.4 GHz 2.4 GHz
CPU Model E5-2609 E5-2609
# Cores per CPU 4 (4 total cores) 4 (8 total cores)
# Threads per CPU 1 (no hyperthreading) 1 (no hyperthreading)
Memory 16 GB DDR3-1066 (4 x 4 GB) 32 GB DDR3-1066 (8 x 4 GB)
Hard Disk 1 - 2.5 Inch 2 - 2.5 Inch
600 GB SAS 10K RPM 600 GB SAS 10K RPM
RAID No Yes - RAID 1 (600 GB total
storage)
LSI 2008 SAS RAID mezzanine
card
Ethernet NICs 4 (2 on board; 2 on NIC) 4 (2 on board; 2 on NIC)
Power Supplies 1 x 650 W 2 x 650 W
Trusted Platform Module Yes Yes
SSL Acceleration Card No Yes
Concurrent Endpoints 5000 (PSN function) (20,000 PSN function)
The SNS-3415 running the 64-bit Cisco ISE 1.2 will support up to 5000 concurrent sessions.
The SNS-3495 running the same software has maximum concurrent sessions of 20,000.
The numbers that are shown are for hardware. If Cisco ISE is installed in the VM ESXi or
ESX, the VM must be provisioned with the same resources as a particular hardware appliance
to get the same concurrent sessions. For instance, if you provision the VM with the resources of
an SNS-3415, then the VM will support up to 5000 concurrent sessions.

Cisco ISE Cisco ISE Cisco ISE
Base License Advanced License Wireless License
Are My Endpoints Are My Endpoints
Base + Advanced
Authorized? Compliant?
The Cisco ISE Base License will support authentication, authorization, and guest services for
both wired and wireless access. This license will allow the organization to manage the who,
what, where, when and how users or devices access the network, based upon user names and
MAC addresses.
If the organization also wants to know dynamically what types of devices are accessing the
network, like Android, iPad, Mac, or Windows, that would require profiling. It would also
require knowing the health of the devices, as well as use of posturing or mobile device
management (MDM) by applications that are used by the device. These advanced services
require the Cisco ISE Advanced License for both wired and wireless.
If the organization needs advanced services but only for wireless access, then there is a Cisco
ISE Wireless ISE License that supports both Base and Advanced services.
ATP
Wireless Advanced
Wireless
Base Advanced Advanced
Wireless
Base Advanced
Advanced
Base Advanced
More Wireless
More Advanced
ATP Wireless
Base Advanced ATP
Base
Base
Full ISE (Wired, Wireless, VPN) Base
Base Advanced
More Base
Wireless to Full ISE Upgrade
The Wireless License which includes both base and advanced service does not require ATP
certification or the ATP process. It only supports wireless NADs. Should you attempt to
connect a wired NAD to ISE, then the wired NAD configuration will be rejected.
Upgrading from wireless to full ISE wired, wireless VPN will require ATP.
The Base License will require ATP and, of course, adding the Advanced License to Base will
also require ATP.

Wired/Wireless/VPN Deployment Wireless Deployment Followed by Wired/VPN
Base (ATP) Advance (ATP) Wireless (No ATP) Upgrade (ATP)
Endpoints Perpetual New PID 3-yr term/ New PID 3-yr term/ New PID 3-yr term/
5-yr term 5-yr term 5-yr term
100 L-ISE-BSE-100= L-ISE-ADV-S-100= ISE-ADV- L-ISE-W-S-100= ISE-W- L-ISE-WU-S-100= ISE-WU-
250 L-ISE-BSE-250= L-ISE-ADV-S-250= 3YR-n/ISE- L-ISE-W-S-250= 3YR-n/ISE- L-ISE-WU-S-250= 3YR-n/ISE-
500 L-ISE-BSE-500= L-ISE-ADV-S-500= ADV-5YR-n L-ISE-W-S-500= W-5YR-n L-ISE-WU-S-500= WU-5YR-n
(for (for (for
1000 L-ISE-BSE-1K= L-ISE-ADV-S-1K= L-ISE-W-S-1K= L-ISE-WU-S-1K=
example, n example, n example, n
1500 L-ISE-BSE-1500= L-ISE-ADV-S-1500= = 100, 250, L-ISE-W-S-1500= = 100, 250, L-ISE-WU-S-1500= = 100, 250,
2500 L-ISE-BSE-2500= L-ISE-ADV-S-2500= 500, and so L-ISE-W-S-2500= 500, and so L-ISE-WU-S-2500= 500, and so
3500 L-ISE-BSE-3500= L-ISE-ADV-S-3500= on) L-ISE-W-S-3500= on) L-ISE-WU-S-3500= on)
5000 L-ISE-BSE-5K= L-ISE-ADV-S-5K= L-ISE-W-S-5000= L-ISE-WU-S-5000=
10,000 L-ISE-BSE-10K= L-ISE-ADV-S-10K= L-ISE-W-S-10K= L-ISE-WU-S-10K=
Appliance Platforms
Physical Virtual
ISE-3315-K9 ISE-3415-K9 1xVM ISE-VM-K9=

ISE-3355-K9 ISE-3395-K9 5xVM ISE-5VM-K9=
ISE-3395-K9 10xVM ISE-10VM-K9=
Small 3315/ 3415 | Medium 3355 | Large 3395/ 3495 | Virtual Appliance
The Advanced License sits on top of the Base License.
Appliance Migration SKUs Base Migration SKUs Advanced Migration SKUs

Physical Appliance SKUs Base Migration SKUs Advanced Migration SKUs
ISE-3315-M-K9 L-ISE-BSE-100-M= (Provides 3-year term;
ISE-3395-M-K9 L-ISE-BSE-250-M= includes Base License)
ISE-3355-M-K9 L-ISE-BSE-500-M= L-ISE-ADV-100-M=
ISE-3415-M-K9 L-ISE-BSE-1K-M= L-ISE-ADV-250-M=
ISE-3495-M-K9 L-ISE-BSE-1500-M= L-ISE-ADV-500-M=
L-ISE-BSE-2500-M= L-ISE-ADV-1K-M=
Virtual Appliance (VM) L-ISE-BSE-3500-M= L-ISE-ADV-1500-M=
SKUs L-ISE-BSE-5K-M= L-ISE-ADV-2500-M=
ISE-VM-M-K9= L-ISE-BSE-10K-M= L-ISE-ADV-3500-M=
ISE-5VM-M-K9= L-ISE-BSE-25K-M= L-ISE-ADV-5K-M=
ISE-10VM-K9= L-ISE-BSE-50K-M= L-ISE-ADV-10K-M=
L-ISE-VM-M-K9= L-ISE-BSE-100K-M= L-ISE-ADV-25K-M=
L-ISE-5VM-M-K9= L-ISE-ADV-50K-M=
L-ISE-10VM-M-K9= L-ISE-ADV-100K-M=
Applicable to NAC/ACS Under ATP , Applicable to Under ATP , Applicable to

Deployments ACS and NGS NAC and Profiler
Deployments Deployments
Note: When migrating from ACS or NAC to Cisco ISE, the number of appliances can vary so do not assume
1:1 migration logic.
The figure describes various Cisco ISE migration SKUs.
Secure Access
This topic describes secure access.
Policy-governed Cisco Unified Access

Dependable anywhere access
Enforcement embedded in the network
Automated onboarding and device security
The Cisco BYOD Smart Solution transforms the workspace by providing the most secure,
comprehensive endpoint to network lifecycle management system for the enterprise, resulting
in a productive end-user and IT experience. Cisco empowers organizations to go beyond
BYOD to deliver an uncompromised experience with seamless security. The Smart Solution
also offers policy-governed unified infrastructure and simplified management to ensure
compliance and IT operational efficiency which are the cornerstones to securing BYOD.

Secure Access: Authentication
Secure access has the following components: authentication, authorization, profiling, and
posturing. This topic discusses authentication.
Sample Authentication
Policy
Authorization
Posture
Profiling
Proceed through the configuration in the following order:

1. Configure the authentication rules that define how the user or endpoints connect and the
protocols which lead to which database to authenticate against.
2. The authorization rules are built. These rules define user groups and which profiles the user
groups will use.
3. Profiling is a separate, independent operation that collects data and determines the types of
endpoints that are connecting to your network. Profiling can occur at any time but generally
you will want to know if the user is allowed to connect before wasting resources to
determine the type of device that is connecting.
4. You will need to know the type of device that wants to access the network so posturing
follows profiling. This step tells you which NAC agent to provision out to the device, such
as a Windows NAC agent versus a Mac NAC versus a web agent.
Authentication
Rule-based authentication policies consist of attribute-based conditions that determine the
allowed protocols and the identity source or identity source sequence to be used for processing
the requests. In a simple authentication policy, you can define the allowed protocols and
identity source statically. In a rule-based policy, you can define conditions that allow Cisco ISE
to dynamically choose the allowed protocols and identity sources. You can define one or more
conditions using any of the attributes from the Cisco ISE dictionary.
Cisco ISE allows you to create conditions as individual, reusable policy elements that can be
referenced from other rule-based policies. You can also create conditions from within the
policy creation page. There are two types of conditions:
 Simple condition: A simple condition consists of three components that include attribute,
operand, and value. The condition can be saved and reused in other rule-based policies.
You can use any attribute from the Cisco ISE dictionary and specify any value that fits the
attribute.
 Compound condition: A compound condition is made up of one or more simple
conditions with an AND or OR relationship. These conditions are built in addition to
simple conditions and can be saved and reused in other rule-based policies.

Examples: Printers, Misc Devices with no supplicant
Primary Auth Methods: MAB
Examples: Redirect Users to WebAuth if MAB Fails
You can authenticate devices that do not have an IEEE 802.1X supplicant. You can use MAC
Authentication Bypass (MAB) over both wired and wireless networks to authenticate printers,
cameras, scanners, and other such devices that generally do not have users behind them, to the
network based on their MAC address. By default the MAC address table is an internal
endpoints database in ISE. If you need to allow users to connect, even though they do not have
an 802.1X supplicant and the MAC address of their device is not in the tables, you will have a
user that is not found, but you will continue on to authorization so that you can authorize the
traffic to be redirected to a WebAuth portal on the ISE PSN. You will see this action when you
get to guest services.
Authenticator RADIUS Server
00.0a.95.7f.de.06
EAPOL: EAP Request-Identity
Time until endpoint

• IEEE 802.1X times out
sends first packet after
• MAB starts Unknown
IEEE 802.1X timeout
MAC address
Any Packet
RADIUS Access-Request
[AVP: 00.0a.95.7f.de.06]
Limited Network Access RADIUS Access-Accept
How does MAB work? The device connects to the access switch, which is the authenticator and
Cisco ISE, which is the RADIUS Server.
The port on the access switch or NAD comes up. The switch, which is configured with 802.1X
authentication, will issue three Extensible Authentication Protocols over LAN: Extensible
Authentication Protocol (EAPOL: EAP) Request-Identity messages. These messages will fail
as the device does not have a supplicant or the supplicant is disabled.
Once the 802.1X timer times out, for any other packet encapsulated in a frame, the source
MAC address of the device will be forwarded in a Radius Access-request by the NAD to the
Radius server, being the ISE PSN.
If the MAC address is found in the Cisco ISE internal database, then the device will be issued
that appropriate access profile.
If the MAC Address is unknown, if the user is not found, the continuation of the process will
cause a WebAuth Profile to be pushed to the NAD, which will allow limited access for the
device to be redirected to a web authentication portal.

Examples: Employees/Staff, Faculty/Students, Extended Access Partners/Contractors
Primary Auth Methods: 802.1X or Agent-based
Managed wired or wireless users will be authenticated with 802.1X authentication. These
managed users will have their credentials stored generally in external databases so you can tell
Cisco ISE to use an identity source sequence database, which will be reviewed later in this
course.
Identity Store OS Version

Cisco ISE Internal endpoints, internal users
RADIUS RFC 2865-compliant RADIUS servers
Active Directory Microsoft Windows Active Directory 2003, 32-bit only
Microsoft Windows Active Directory 2003 R2, 32-bit only
Microsoft Windows Active Directory 2008, 32-bit and 64-bit
Microsoft Windows Active Directory 2008 R2 64-bit
Microsoft Windows Active Directory 2012 (ISE 1.2)
LDAP Servers SunONE LDAP Directory Server, Version 5.2
Linux LDAP Directory Server, Version 4.1
NAC Profiler, Version 2.1.8 or later
Token Servers RSA ACE/Server 6.x Series
RSA Authentication Manager 7.x Series
RADIUS RFC 2865-compliant token servers
SafeWord server prompts
The figure shows external identity sources that have been tested and proven to work with Cisco
ISE. Note that Cisco ISE 1.2 includes Microsoft Windows Active Directory 2012.
Examples: Employees/Staff, Faculty/Students, Extended Access
Partners/Contractors
Primary Auth Methods: 802.1X or Agent-based
OTP Server Configuration
Very often, organizations used a one-time password (OTP) server for their VPN managed
users. Cisco ISE can be integrated with a number of different OTP servers.
More specific condition can be defined to Match flow

(For example: user, location)
Protocol Specific
You can define different protocol lists for different locations or types of NADs in your
deployment.

• AnyConnect 3.1
- Cisco Unified access interface for the
following:
• 802.1X for LAN/WLAN
• VPN (SSL-VPN and IPSec)
• Mobile User Security
(WSA/ScanSafe)
- Supports MACSec/MKA (802.1X-REV)
for data encryption in software.
Performance based on endpoint CPU.
- MACSec-capable hardware (network
cards) enhanced performance with
AnyConnect 3.0
Cisco NAC Agent

currently used for
posture. Will be
merged into
AnyConnect in 3.2.
You can use the native supplicant that is provided within the operating system.
A more complete and powerful solution is to use the Cisco AnyConnect Agent. Any Connect
3.1 is a unified access agent that can connect to anywhere in any way. AnyConnect 3.1 offers a
unified access interface for 802.1X (both wired and wireless), VPN, (both Secure Socket Layer
[SSL]-VPN and IP Security [IPsec]), and Mobile User Security (web security appliance [WSA]
or ScanSafe). AnyConnect also supports Layer 2 MAC security data encryption between the
endpoint and the access point.
NAC agents are also used for posturing. AnyConnect 3.2 will include the Cisco NAC Agent
Module (NAM).
Secure Access: Authorization
posturing. This topic discusses authorization.
Policy
Authorization
Posture
Corp Identity Groups

Profiling
Authorization profiles combine multiple policy elements into a set that can be applied to
clients. The Task Navigator guides the user through the screens necessary to select appropriate
options for configuring authentication as well as authorization.
Cisco ISE is preconfigured with five default authorization profiles:
 Blacklist_Access
 Cisco_IP_Phones
 Non_Cisco_IP_Phones
 DenyAccess
 PermitAccess
You can edit the built-in profiles, but it is not recommended. In practice, you will need more
granularities, so you can create custom authorization profiles. One of the built-in profiles can
be duplicated and used as a starting point for the creation of custom authorization profiles.
The Blacklist_Access profile is designed to reject connections for systems that are placed on
the black list. This profile is useful when a user reports a lost or stolen device and the device
needs to be removed from the network and prevented from initiating new connections to the
network.
Authorization logic is similar to authentication logic. An authorization policy consists of rules.
Each rule has one or more conditions. The conditions can be simple or compound. You build
authorization conditions by comparing an attribute against a value using an operator.
The main difference between the authentication and the authorization conditions is in the
configuration context.

You can set authentication conditions by navigating to Policy > Policy Elements >
Authentication > Simple Conditions or to Policy > Policy Elements > Authentication >
Compound Conditions.
You can set authorization conditions by navigating to Policy > Policy Elements >
Authorization > Simple Conditions or to Policy > Policy Elements > Authorization >
Compound Conditions.
Build an authorization policy by adding, duplicating, reordering, and deleting rules, just as you
do with authentication policies.
Who?
Permissions = Authorizations
• Employee Set VLAN = 30 (Corp Access)
• Contractor Set VLAN = 40 (Internet Only)
The figure shows a sample policy that you could build into your authorization rules. As you can
see in the example, the rules define conditions that identify the user groups that reside in an
external Active Directory database. Employees get a permission profile that can assign the
employee to a particular VLAN whereas a contractor will be put into an Internet-only VLAN.
The permission column points to an authorization profile which can include the following:
 dACLs that are stored on Cisco ISE and dynamically pushed down to the switch
 Dynamic VLAN assignment
 Voice domain assignment
 Airespace ACL name
 SGTs

Secure Access: Profiling
posturing. This topic discusses profiling.
Policy
Authorization
Posture

Profiling
NMAP Classification
NetFlow
HTTP
SNMP
DHCP
LLDP
RADIUS
Collection
Profiling collects attributes about endpoints via various controllable collectors. Once all the
attributes are collected, they are used to classify the endpoints into endpoint groups. These
groups can be used to monitor and report the endpoints on the network and used to control
access to the network.

Collection
Profiling Probes
OUI, DHCP, Netflow,
DNS, HTTP, CDP, LLDP
Classification
ID Group Assignment
ISE
The Network
Apply Policies
Internet ONLY
Video VLAN
Voice VLAN
Printer VLAN
More ………….
With Cisco ISE Profiler, begin by using the Organizationally Unique Identifier (OUI) to start
the process of classifying the device that is based on the vendor code in the MAC address. By
using some of the other profiling probes, you can further classify the type of device that is built
by a particular vendor. Once Profiler has classified the device to a certify factor, the device can
then be assigned an authorization profile. In the example that is shown in the figure, the Cisco-
IP-Phone will receive Cisco-IP-Phone profile, which could assign the voice VLAN and voice
domain with a dACL or SGT. The Motorola Android device or mobile device will not be
allowed to connect. ISE PSN will send a RADIUS CoA message to the NADs, which will then
“bounce” the port or session to cause a reauthorization to push the new authorization profile
down to the session as a function of the profiler classification.
• User-Agent is an HTTP request
header that is sent from web
browsers to web servers. User-
PSN
Agent includes application,
vendor and OS information that
can be used in profiling endpoints.
- User-Agent attributes can be
collected from web browser
sessions redirected to ISE for
existing services such as:
• Central Web Auth (CWA),
• Device Registration WebAuth
(DRW)
• Native Supplicant Provisioning
(NSP)
Endpoint Redirection
(TCP/8443)
One of the ways to collect endpoint information is through the user-agent attribute in the HTTP
header request. The user-agent identifies the vendor and operating system information. With
guests and non-802.1X devices, traffic is redirected to Cisco ISE web portal, which can then
collect the HTTP user-agent attribute. Through this attribute, the profiler can determine the
vendor, operating system, and browser information.

Wireless
Enable CoA
support on WLC
Configuration Commands:
ip http server
ip http secure-server
ip access-list extended REDIRECT-ACL
deny tcp any any <PSN_IP_address>
permit tcp any any eq http Switch Configuration Wired
permit tcp any any eq https
To support Profiler and specifically HTTP probe via HTTP redirection, the following must be
enabled:
 On the WLCs
Step 1 Navigate to RADIUS Authentication Servers > Edit.
Step 2 Enable Support for RFC 3576 which supports RADIUS CoA messages. It should be
noted that RFC 3576 has been superseded by RFC 5176.
Step 3 Navigate to WLANs > Edit “guest-cwa”.
Step 4 Choose the Security and then Layer 2 tabs.
Step 5 Click the check box for MAC filtering.
Step 6 Choose the Advanced tab.
Step 7 For the NAC state, select RADIUS NAC from the drop-down menu.
 On the switches the following commands should be added to the configuration
ip http server
ip http secure server.
ip access-list extend REDIRECT-ACL
Deny tcp any any <PSN_IP_ADRESS>
Note The above command ensures that traffic going to the PSN does not get redirected to the
PSN.
Permit tcp any any eq http

Permit tcp any any eq https
Before implementing IP http secure-server, you should generate RADIUS key pairs with
modulus 2048.
Note The figure shows an example of a simplistic redirect ACL. This ACL will be modified to
support additional protocols later in the course when discussing posturing later.

• Great and simple method of
getting DHCP traffic to ISE.
PSN
• Requires configuration of NADs
to relay DHCP packets to ISE.
• DHCP probe in ISE will collect
DHCP-REQ DHCP data to use in profiling
policy.
• For WLCs, disable DHCP proxy.
Interface Vlan50
Ip address 10.1.10.1 255.255.255.0
ip helper-address 10.1.100.10
Ip helper-address 10.1.100.5 (For ISE)
Another common profile probe is DHCP. Cisco ISE will look at the DHSCP class ID, which
will give ISE more information for the OUI. By default, DHCP remains in the Layer 2
broadcast domain and the DCHP server and ISE will generally not be in the same Layer 2. At
the Layer 3 default gateway interface, there is an IP helper address pointing to the DCHP
server. There you will have to add an additional IP helper address point to ISE-PSN.
• Aggregate and forward profiling information over
existing RADIUS traffic between NAD and ISE
DHCP, CDP, LLDP
Using RADIUS • IOS switches collect DHCP, LLDP and CDP data. Data
PSN
sent to ISE as cisco-av-pair using RADIUS accounting
updates.
- Supported on IOS 15.0(1)SE1 for Cat 3K
- Supported on IOS 15.1(1)SG for Cat 4K
Wired device-sensor accounting
device-sensor notify all-changes
HTTP & DHCP

Using RADIUS
PSN
- WLC 7.2.11
Wireless
With each sensor probe that is initiated, the switch generates a new individual packet to the
PSN and the PSN must process each packet. This could be a processing issue for each switch
and would certainly be a processing issue for the PSN if all the switches send several packets to
the PSN for every device that accesses the NAD.
The IOS sensor is a new technology added to the switches. The switch now collects all packets
and information and sends a single RADIUS packet per device to the PSN. The IOS sensor of
the switch currently collects DHCP, Cisco Discovery Protocol, and Link Layer Discovery
Protocol (LLDP). More probes will be added in the future.
IOS Sensor is supported on IOS 15.0(1) for Catalyst 3000 and IOS 15.1(1) for Cat 4000
switches. More platforms are to come.
The following is the configuration command to activate IOS sensor:
device-sensor accounting
device-sensor notify all-changes
Also, for WLCs beginning with version 7.2.11, client profiling waits and collects HTTP and
DHCP probe information and sends a single RADIUS av-pair to the PSN for each device
connecting to the WLC.
To activate the sensor, from Client Profiling select DHCP and HTTP Profiling.
These sensor probes may support and profile most devices connecting to your network.

• Traffic is mirrored to an interface
on ISE policy services node.
PSN
WWW • Both SPAN and Remote SPAN
are supported.
• Not an optimal way to send
traffic to ISE.
• SPAN Configuration Guide:
http://www.cisco.com/en/US/doc
DHCP
HTTP s/switches/lan/catalyst2940/soft
ware/release/12.1_19_ea1/confi
guration/guide/swspan.html
SPAN
Should you have NADs that do not support Central WebAuth redirects or DHCP snooping,
Cisco ISE has the option to collect Switched Port Analyzer (SPAN) and Remote SPAN
(RSPAN). The switches have to be configured to mirror the traffic to an interface on the PSN
which would put a significant load on the network and the PSN, and should only be done after
careful due diligence. For more information, use the SPAN Configuration Guide on Cisco.com.
• The NMAP utility
incorporated into ISE
PSN PSN
allows profiler to detect
new endpoints via a
subnet scan and to classify
endpoints based on their
Scan OS, OS version and
services as detected by the
OUI = Apple NMAP.
Subnet Scan
(On demand) • The Network Scan probe is
considered an active
assessment mechanism
since it communicates
directly with the endpoint
to obtain information from
the source.
IOS Sensor
• A scan can be triggered
dynamically based on
10.76.40.0/24 policy.
If you have a finely tuned security policy that states you will support a vendor’s device but only
if it is running a particular code or operating system, then HTTP and DHCP may not collect
enough attributes for you to differentiate the profiled devices. You may need to activate the
NMAP (targeted active scan) of the endpoint. To do this, the profiler must first discover the
vendor code of then go back and do a targeted network map (NMAP) active scan of the device.
Of course, this will give the profiler more details but will also put more of a load on the PSN
and it may also trigger a host IPS sensor on the end station.

• Predefined scan
actions
• Default scan
action for
Unknown
endpoints
• Adding scan action. Common Ports is a list of 15 UDP

and 15 TCP ports.
NMAP can do an operating system can, a Simple Network Management Protocol (SNMP) port
scan or scan common port numbers. As noted, you should only do operating system scan and
SNMP port scan if the operating system was not determined by a previous passive scan.
Apple HP Motorola Cisco Blackberry

WYSE
Lexmark VMware Microsoft Xerox
Samsung
There are profiles that are built into Cisco ISE that accommodate devices from most major
vendors. But what if there is not a profile for your device? This problem will be discussed later
in the course.
An exhaustive list of canned profile policies to uniquely identify the many devices that could
possibly access your network is built into Cisco ISE. First, there are the parent groups that are
identified by the OUI or vendor code. Each parent has many child devices or groups. The child
groups can have many child devices. Your authorization rules can apply permission profiles to
the parent group, child group, or child devices, depending upon how granular you make your
security policy.

PSN Cisco
Feed
PSN Server DB Partner
Notifications
Supported
• No need to wait for new Cisco ISE

version
• Zero-day support for popular
endpoints is added using Feed
Server
Even though the canned profiles are extensive, there are more devices available that have not
yet been defined as a profiled endpoint. As new devices come out, new profile policies have to
be developed. There are also devices that are unique to your particular business.
Cisco ISE1.2 offers the Profiler Feed Service. As new devices are defined, either by Cisco or
by partners and confirmed by Cisco, the policies will be placed on the Profile Feed Service.
Cisco ISE can then retrieve the new profiles from the server and dynamically add them to the
Cisco ISE profile database.
What = ? Who = Employee
• Employee Phone Set VLAN = 601 (Internet Only)
• Employee PC Set VLAN = 603 (Full Access)
Now that the profiler has discovered what the device is and to which group the device belongs,
you can apply authorization policies to the devices based on the vendor group, device group, or
even a particular device. The device groups will be stored in the internal Cisco ISE database
and will be identified in the authorization rule as the ID group. You can further implement a
policy that also looks at the user group. In the example that is shown in the figure, an employee
smart phone can access the internet, but an employee who has a workstation has full access. In
the hospital, doctors with Windows notebooks can get full access, but the same doctors with
iPads can only get to the radiology server and internet. Patients with iPads can only go to the
internet.

IP-Phones
Would like to
group all my smart
phones and iOS
devices into a
logical profile to
facilitate writing
policy
iOS-Devices
As you create more authorization profiles, you will end up creating more and more groups.
Cisco ISE 1.2 introduces logical profiling groups. With logical profile groups, you can assign
many different profile groups into a single logical profile group to which a common
authorization profile will be attached.
What = ? Who = Employee
• Employee Phone Set VLAN = 601 (Internet Only)
• Employee PC Set VLAN = 603 (Full Access)
Logical profile groups allow for much cleaner rules as authorization rules can reference logical
groups as opposed to many vendor groups.
The figure shows an example of implementing a smart phone policy using a logical profile in
Cisco ISE.

Secure Access: Posture
posturing. This topic discusses posture.
Policy
Authorization
Posture

Profiling
• Posture is the state of compliance with the company’s security policy.
- Is the system running the current Windows patches?
- Do you have anti-virus software installed? Is it up to date?
- Do you have anti-spyware installed? Is it up to date?
Cisco ISE posture service provides you with the capability to check the health of the endpoints
and, depending on the results, assign appropriate connectivity permissions. Cisco ISE
determines the security posture by obtaining from the NAC Agent of the endpoint the status of
various software components, such as service packs, software patches, antivirus, and
antispyware applications.
Cisco ISE provides automated rule sets to simplify management for over 350 partner
applications, including Microsoft Windows, online services, and antivirus software vendors.

• Microsoft updates • Antivirus • File data
- Service packs installation/signatures • Services
- Hotfixes • Antispyware • Applications/processes
installation/signatures
- OS/Browser versions • Registry keys
Posture conditions are used to check specific attributes on the client system. A posture
condition can be one or any combination of the following conditions:
 File condition: A simple condition that checks the existence of a file, the date of a file, and
the versions of a file on the client. This condition is available for Windows computers.
 Registry condition: A simple condition that checks for the existence of a registry key or
the value of the registry key on the client. This condition is available for Windows
computers.
 Application condition: A simple condition that checks if an application (process) is
running or not running on the client. This condition is available for Windows computers.
 Service condition: A simple condition that checks if a service is running on the client. This
condition is available for Windows computers.
 Dictionary simple condition: A simple condition that checks an attribute that is associated
to an operator and the operator to a value.
Examples of common posture conditions include the following:
 Windows update verification: Verifies the proper service pack and patch levels.
 Virus application verification: Verifies that the client has the correct antivirus software
installed. This function may also be used in a less restrictive capacity to verify that the
client simply has any antivirus installed.
 Virus definition verification: Verifies that virus definitions are newer than a specific date.
 Windows screen saver password verification: Verifies that the client has a Windows
screen saver password configured.
 Registry entry verification: Verifies the client registry key.
• Employee policy • Contractor policy
- Microsoft patches updated - Any AV installed, running, and
- McAfee AV installed, running, and current
current • Guest policy
- Corp asset checks - Accept AUP (no posture, Internet
- Enterprise application running only)
The Cisco NAC Agent is installed on the endpoints to assist in the posture assessment and
remediation of client devices. The NAC Agent validates the endpoint for compliance, which is
based on the requirements that are sent from the Cisco ISE server and determines the posture of
the endpoint. If the endpoint is not compliant with the requirement, then the NAC Agent
prompts to remediate the endpoint for compliance. Any failures during posture evaluation will
result in the noncompliance of the endpoint. The NAC Agent sends the appropriate compliance
report to the Cisco ISE server once the endpoint is postured as compliant or noncompliant.
There are three types of NAC Agent:
 NAC Agent for Windows: This read-only client software can check the host registry,
processes, applications, and services. The NAC Agent for Windows can be used to perform
Windows updates or antivirus and antispyware definition updates, launch qualified
remediation programs, distribute files that are uploaded to the Cisco ISE server, distribute
links to websites for users to troubleshoot their systems, or simply distribute information
and instructions.
 NAC Agent for Macintosh: The Macintosh NAC Agent provides the posture assessment
and remediation for client machines and returns the results to the Cisco ISE.
 NAC Web Agent: This agent provides temporal posture assessment for client machines.
Users can launch the NAC Web Agent executable file, which installs the Web Agent files
in a temporary directory on the client machine via ActiveX control or Java applet. After
users log into the NAC Web Agent, the Web Agent gets the requirements that are
configured for the user role and the operating system from the Cisco ISE server, checks the
host registry, processes, applications, and services for required packages, and sends a report
back to the Cisco ISE server. If requirements are met on the client, the user is allowed
network access. If requirements are not met, the Web Agent presents a dialog to the user
for each requirement that is not satisfied. The dialog provides the user with instructions and
the action to take for the client machine to meet the requirement. If the specified
requirements are not met, users can choose to accept the restricted network access while
they try to remediate the client system so that it meets requirements for the user login role.

NAC Agent for Web Agent for NAC Agent for
Windows Windows Mac OS
Posture Assessment OS/service packs/hotfixes OS/service packs/hotfixes AV installation
Options Process check Process check AV version/AV definition date
Registry check Registry check AS installation
File check File check AS version/AS definition date
Application check Application check
AV installation AV installation
AV version/AV definition date AV version/AV definition date
AS installation AS installation
AS version/AS definition date AS version/AS definition date
Windows update running Windows update running
Windows update Windows update
configuration configuration
WSUS compliance settings WSUS compliance settings
Remediation Options Message text (local check) Message text Message text
URL link (link distribution) URL link URL link
File distribution File distribution AV live update
Launch program (AS live update)
AV definition update
AS definition update
Windows update
WSUS
The table in the figure lists posture assessment and remediation options.
• Corporate Policy
- Must have Kaspersky AV installed
- Automatic remediation enforced
• Guest Policy
- Must have AV installed but can be
ANY vendor
The figure shows a posture policy example.

The policy says that corporate Windows workstations must have Kaspersky antivirus (AV)
software that is installed and automatic remediation is enforced.
The guest policy is that an AV must be installed but that any vendor is supported.
First, configure the AV remediation policy that defines what remediation actions are to be taken
should an endpoint be noncompliant with the AV requirements.
Second, configure the requirements policy to define the requirements and point to the
remediation policy.
Finally, configure the posture policy rules that define which ID-Groups are learned by the
profiling rules, the operating system learned by the profiling, and the users groups in the
external data source. If the correct conditions are met, then the posture requirements are
assigned.

I know who you are, but are you logging in from a corporate
device? Hi, I am jsmith
and my password
is *******
• User identity
- Username/password credentials User
(802.1X or WebAuth) Corporate User or

Guest (Non-Employee)?
- User certificate (802.1X)
• Machine “identity” MAC address lookup to AD/LDAP

00:11:22:AA:BB:CC
Profiling
–MAC address Posture Machine
–Machine certificate (802.1X) Machine certificates

Non-exportable user certificate
–Passwords Machine auth with
Corporate PEAP-Device
or Personal
MSCHAPv2
EAP chaining
• How do I tie the two together in a single Access

policy? + = Policy
You can perform both machine authentication and user authentication before assigning the
corporate access policy. You have learned about user authentication using 802.1X and
WebAuth.
You have reviewed a couple of ways to authenticate the machine and MAC address lookup,
either in the internal endpoints database or to an external database like Active Directory or
LDAP. You can learn about devices dynamically through profiling, but that is not really
authentication. Using the posture agent, you can find out details on the machine and can even
check for a registry setting or a particular file location (watermark) to determine if the machine
is a corporate machine.
To truly authenticate the machine, you can install machine certificates and verify those
certificates against the certificate authority (CA).
• NAC or Web Agent
checks in Windows
registry for domain
value.
• Example:
mycompany.com.
One way to declare the machine as a corporate machine is to have the NAC or Web Agent to
check the windows registry for domain value; however this check can be easily spoofed.
Another option is to “watermark” the machines with an obscure registry setting or an obscure
file with an obscure filename in a hidden directory. If the NAC Agent finds all three, then you
have a high degree of certainty that the machine is a corporate machine.

• EAP chaining uses EAP-FAST protocol extensions
• It ties both machine and user credentials to the device, thus the “owner”
is using a corporate asset
• Machine credentials are authenticated to the network using 802.1X.
• Once a user logs onto the device, session information from the machine
auth and user credentials are sent as part of the same authentication.
• If both machine and user credentials are successfully validated, then the
“owner’ is tied to the device (corporate asset).
• If both or either credentials fail, restricted network access can be given
according to ISE policy.
Machine
Credentials Machine
Authentication Machine and User Credentials
RADIUS Validated
PSN
User
AD (EAP-MSCHAPv2 inner method)
Credentials User PKI (EAP-TLS inner method)
Authentication
Cisco ISE introduced Extensible Authentication Protocol-Flexible Authentication via Secure

Tunneling (EAP-FAST) protocol extensions by including the type length value (TLV) type of
user and machine to do EAP chaining. In a single operating system event, you can encompass
both machine and user credentials. The credentials tie to a specific user and to a specific device.
In the authentication log, you will see not only the host name, but also the user name. They are
no longer separate entities. It is one entry. You can now have policies that apply if the user
authentication failed but the machine authentication has succeeded and vice versa. You can
have policies if both user and machine fail or both succeed.
User authentication includes both user and machine identity types.
AnyConnect is required for EAP chaining
To configure authorization rules for EAP chaining, you will need Cisco AnyConnect installed
on the workstation and you will set up the rule conditions for the following:
 Network Access:EapTunnel EQUALS EAP_FAST AND
 Network Access:EapAuthentication EQUALS EAP_TLS AND
 Network Access:EapChainingResult EQUALS <the TLV that you require for the rule>
 User failed and machine succeeded
 User succeeded and machine failed
 User and machine both succeeded
 User and machine both failed

• Client:
- Laptop/desktop with Ethernet/WiFi NIC and one of the following operating
systems:
• Windows 7 SP1 x 86 (32-bit) and x64 (64-bit)
• Windows Vista SP2 x86 and x64
• Windows XP SP3 x86
• Windows Server 2003 SP2 x86
- AnyConnect 3.1MR+ with Network Access Manager Mobile installed
- AnyConnect 3.1MR+ Profile Editor
• Server:
- ISE 1.1.1 (1.1MR)
For EAP chaining, you need a client that has an Ethernet or Wi-Fi network interface card
(NIC), and one of the following operating systems:
 Windows 7 SP1 x 86 (32-bit) and x64 (64-bit)
 Windows Vista SP2 x86 and x64
 Windows XP SP3 x86
 Windows Server 2003 SP2 x86
You will note that the list includes only Windows operating systems; however, Cisco has taken
a leadership role in driving this as an industry standard to support other platforms as well.
Secure Access: Sample Policy
posturing. This topic discusses a sample policy.
Policy
Authorization
Posture

Profiling
Access
Policy
User Device Type Location Posture Time Access Method Custom
The figure provides an example Cisco ISE authorization policy that uses context-aware access.

Segmentation Segmentation Pros Cons
Method Point
VLANs Ingress • Does not require switch port • Typically requires IP change
ACL management • Requires the proliferation of
• Preferred choice for path common VLANs across access and
isolation maintenance.
• VLANs still require some other
enforcement mechanisms to be
deployed
dACL Ingress • No IP address change required • Resource limits per switch on ACE
• Does not require the count per ACL
proliferation of VLANs across
access network and associated
VLAN management
• Provides access control directly
at switch port versus reliance on
upstream security device or
mechanism
SGACL Ingress • Simplifies ACL management • Enforcement is not available on all
and reduces number of ACLs platforms
required
• Uniformly enforces policy
independent of source IP
The table in the figure describes ISE policy enforcement network segmentation.
Endpoint access attempt
3 5
Authentication
Posture Profiler
2 4
CoA CoA
1
Authorization
Controlled endpoint access
This figure shows the allowance of the policy server to initiate a change in the authorization
policy that is implemented at the NAD.
Example CoA flow:
1. Initial State:
NAD port ACL: Permit DHCP, TFTP, KRB5, EAPoL
ISE: Undefined
2. Endpoint connects, 802.1X authentication completes successfully:
NAD port ACL: Permit DHCP, TFTP, KRB5, EAPoL
ISE: UID/PWD = OK, Posture = Unknown, Authorization = Temporary
3. Initial authorization policy ISE to NAD: allow posture assessment and remediation.
NAD port ACL: IP to ISE, IP to Remediation Server
ISE: UID/PWD = OK, Posture = Unknown, Authorization = Temporary
4. Posture assessment completes, endpoint is compliant.
NAD port ACL: IP to ISE, IP to Remediation Server
ISE: UID/PWD = OK, Posture = Compliant, Authorization = FullAccess
5. CoA message from ISE to NAD, allow unrestricted access:
NAD port ACL: Permit IP to Any
ISE: UID/PWD = OK, Posture = Compliant, Authorization = FullAccess
A Cisco ISE Inline Posture node can be implemented to enforce policy for NADs that do not support CoA.

Cisco Setup Assistant
This topic describes Cisco Setup Assistant.
• Walks through ISE

configuration
• Walks through NAD
configuration
• Can help with quick
proof of concept setups
Cisco Setup Assistant walks through Cisco ISE configuration and NAD configuration. The
program is not designed for a large policy services node deployment. However, it can be
helpful with quick proof of concept setups.
To do authentications, Setup Assistant will query whether you want to connect Cisco ISE to
Active Directory. As you answer the questions, Setup Assistant will prompt with additional
questions if it needs to. For example, it will ask for credentials for Active Directory or the
domain name. Setup Assistant also has a section where you can indicate the network access
devices in the network. Based on how these questions are answered, including subnets, VLAN
IDs, and so on, Setup Assistant will generate a sample configuration for that particular NAD
and IOS version. It will do the same thing for the WLC. Obviously, Setup Assistant does not
know the exact interfaces that these devices are attached to, so you cannot simply cut and paste
information from the window, but Setup Assistant comes close. The user can cut and paste
information in a text window, enter the actual interfaces that are needed, and then paste that
into the configuration. Setup Assistant takes care of NAD configuration.

Guest Portal
This topic describes using the guest portal of Cisco ISE.
At HTA Hospital, guests are offered network access. Guests include patients, their families, and
other visitors to the hospital.
This access is offered not only for the well-being of the patients and as a courtesy to their
family and friends, but also as a security measure. Allowing guess access prevent uncontrolled
access to hospital resources due to the unwitting assistance of a well meaning hospital staff
member or employee who offers a visitor or patient access to email or the Internet through the
staff member’s own account.
It would be cumbersome if hospital IT staff had to manage all guest accounts by manually
adding them to the authentication server. Because it is cumbersome, a guest services portal in
Cisco ISE allow guests to establish their own account through the self-service capabilities of
the portal which allows guests to have the access they desire without placing a huge burden on
IT staff.
Provision Manage Notify Report
Create Notify Guest Report on all

Create Guest
Sponsor Policy using different aspects of
Accounts in
method Guest
the Sponsor
Manage Accounts
Portal
sponsor groups Print
Email
Customize SMS
Portals
Cisco ISE guest services cover the full life cycle of guest accounts. The users who create guest
accounts are called sponsors. The Cisco ISE administrator assigns privileges to sponsors, who
in turn may define the attributes of the guest users.
Cisco ISE guest services provide customizable portals for both guests and sponsors.
Cisco ISE guest services allow any sponsor with appropriate privileges to easily create
temporary guest accounts and to sponsor guests. Cisco ISE allows sponsors to provide account
details to the guest by printout, email, or short message service (SMS). The entire experience,
from user account creation to guest network access, is stored for audit and reporting purposes.

• Unifying network access for guest users and employees
Guest
SSID Contractor
Corp
Guest SSID
Contractor Guest
Employee
Desktop
On wireless: On wired:
 Using multiple SSIDs  No notion of SSID
 Open SSID for Guest  Unified port: Need to use different
auth methods on single port
 Enter Flex Auth
Cisco ISE guest services feature is tied to the web authentication functionality. When a guest
user first attaches to the local network, either through a wireless or wired connection, Cisco ISE
assigns that user a very restrictive authorization profile.
On wireless most organizations will have dual Service Set Identifier (SSIDs), a Cisco corporate
SSID using Wi-Fi Protected Access (WPA) enterprise for the employees to connect and an
open SSID for guests.
On the wired network, the switch port will use Flex Auth by using 802.1X, followed by MAB.
If they fail, there will be a continuance in authorization as discussed earlier using WebAuth.
Web authentication allows guests, visitors, contractors, consultants, or customers to perform an
HTTP or HTTPS login to access a network, whether that network is a corporate intranet or the
public Internet. Based on the initial restrictive authorization profile, the NAD intercepts the
HTTP request and redirects it to the guest user login portal. The user is presented with a login
page to enter a username and password and, after successful authentication, is associated with
the appropriate authorization profile and is provided controlled network access.
I’m your I can’t get on Device
normal guest the network registration
Temporary Employee with Register

users, no misconfigured personal
802.1X system devices
Web authentication is typically used for guest network access. Guest services are covered later
in this course. Web authentication provides network access to users who authenticate using
HTTP or HTTPS using a centralized Cisco ISE service.
Web authentication may be used as a method of last resort for users with an 802.1X supplicant
that is not installed, is misconfigured, or is not functional. If the 802.1X supplicant is not
functioning properly, web authentication may be used to prompt the user for authentication
credentials and still provide access to the network. Web authentication may also be used for
guest users who have an 802.1X supplicant that is installed, but do not have a user account in
the appropriate identity database.
Web authentication can be implemented in both wired and wireless environments.
WebAuth will also be used later for the personal device registration and onboarding, which will
be discussed later in this course.

Sponsor
Imran
********
Local RADIUS
Redirection of the guest Web session

to ISE guest portal for authentication
ISE
Guest
WLC
Switches
Workstations Mobile
(iPhone) AP
To create guest accounts, connect to the sponsor portal and log in as a sponsor user. To
provision guest accounts on the Cisco ISE, you must be a sponsor user. Sponsors are generally
employees and will be authenticated against the corporate identity source sequence.
Follow these steps to create guest accounts:
Step 1 Connect to the Sponsor Portal. https://<PSN-FQDN>:8443/sponsorportal which
assumes the default port 8443 of the sponsor portal has not been changed for the
admin portal.
Step 2 (Optional) Create single guest accounts.
Step 3 (Optional) Create random guest accounts.
Step 4 (Optional) Import guest accounts from a file.
Step 5 (Optional) Verify guest user accounts.
Once the sponsor has created a guest account, the guest will attempt to connect to the network
and will get redirected to the guest portal on the PSN. There the guest will log in with the
newly created username password credentials that were provided via printout, email, or SMS.
The organization also has the option to allow a guest to use self-service for creating accounts
which allows organizations to track guests not be involved in creating guest accounts.
The guest portal is device agnostic in that a guest that connects with a workstation will get the
full web page whereas a guest connecting with a smart phone will see a page that is tailored for
that smart phone.
The guest user portal consists of the following elements:

 Guest user login screen: This screen provides username and password fields.
 Acceptable use policy screen: This screen is an optional term of use agreement.
 Required password change screen: This screen is optional at first login.
 Allow password change screen: This screen allows the user to optionally change a
password.
 Self-registration screen: This screen is an optional screen that allows guests to set up their
own user accounts.
 Device registration: If enabled, this option allows guest user accounts to self-register a
predefined number of endpoints by MAC address. Registration results in static population
of the internal endpoint store without a default ID group assignment. The user must have
valid credentials to register devices.
Cisco ISE guest services make use of the Distributed Management System of Cisco ISE to
allow for multiple Cisco ISE nodes to communicate with one another in a deployment.
Guest portals must be located on the same policy service nodes that manage the RADIUS
requests that arrive from the NADs. For example, if a node is used to manage RADIUS
requests for a NAD that depends on central WebAuth support, the guest portal must be enabled
on that node.
The guest and sponsor portals will work on any policy service node in a deployment, as long as
that node also has session services functionality enabled.

PSN
Local Web Auth (LWA) Central Web Auth (CWA)
Portal
User Auth User Auth Portal
Predefined web auth policy No web auth policy

(ACL, url)
To be clear, WebAuth, the web page, and authentication occur at the PSN. The WebAuth PSN
must be the same PSN as the RADIUS server for the NADs and it is RADIUS that returns the
authentication session numbers and authorization policies.
Local Web Auth (LWA) means that the WebAuth policy, redirect ACL, interface ACL, and the
redirect URL are hard-coded on the NAD.
This would cause a problem if there is redundancy with your RADIUS and if the NAD starts
using a different RADIUS server PSN than what the redirect URL is pointing to.
The solution is to use Central Web Auth (CWA). With CWA, the Web Auth Policy and the
Redirect URL are maintained on the PSN and dynamically pushed down to the NADs via the
radius attribute-value (AV) pair message. With this solution, the RADIUS PSN and the
WebAuth URL are always the same PSN.
ISE Database
Guest External
Database Database
 Created by  LDAP/AD
sponsors  Managed
(bulk externally
option)  Enabled/
 Guest “self disabled
service”
 Restricted
access
duration
Where can you find guest user accounts? In Cisco ISE, the guest database contains user
accounts that are created by sponsors (bulk option); are created as self service by guests; and
have restricted access duration.
In an external database, user accounts are stored in LDAP or AD, managed externally, and have
been enabled or disabled.

The sponsor portal allows you to perform the following functions:

 Create, edit, delete, suspend, and reinstate guest user accounts.
 View guest details.
Sponsors are authenticated using identity sources that are defined within Cisco ISE. Options
include the following:
 Local database
 Active Directory
 LDAP
 RADIUS
Guest sponsor groups define the permissions and settings for the sponsor user. Sponsor users
that belong to a particular sponsor group have a certain set of permissions and settings when
they log into the sponsor portal. You can set role-based permissions for sponsors to allow or
restrict access to different functions, such as creating accounts, modifying accounts, and
sending account details to guests by email or SMS.
For example, if you want a set of sponsors to be unable to log in for a short period while a
configuration is being changed, you can set the sponsor group permission to prevent login. This
method allows you to restrict a set of sponsor users from logging in without having to remove
the sponsor group.
Cisco ISE is preconfigured with three default sponsor groups: SponsorAllAccounts,
SponsorGroupGrpAccounts, and SponsorGroupOwnAccounts. You can modify and delete the
existing groups or create additional groups by navigating to Administration > Guest
Management > Sponsor Groups.
Before provisioning any guest accounts, the system administrator must configure the sponsor
portal. The sponsor portal defines the privileges that the sponsors have within the system.
Follow these steps to configure the sponsor portal settings on Cisco ISE:
Step 1 Optionally configure a sponsor group. The parameters of a sponsor group include
the sponsor authorization levels, guest roles selectable by sponsors, and sponsor time
profiles.
Step 2 Declare the identity source or identity source sequence to be used for sponsor
authentication.
Step 3 Optionally define sponsor conditions.
Step 4 Configure a sponsor group policy.
Step 5 Optionally customize the portal theme.
Step 6 Optionally customize internationalization.
Each sponsor group has a certain authorization level that is associated with it. The authorization
level defines the sponsor permissions and behavior. You configure the authorization levels
under the Authorization Level tab within the sponsor group configuration menu.
You can set Yes or No permission for the following:
 Allow login
 Create accounts
 Create random accounts
 Import CSV
 Send email
 Send SMS
 View guest password

 Allow printing guest details
You can choose one of the following options for View or Edit Accounts:
 No: Sponsors are not allowed to edit any guest accounts.
 All accounts: Sponsors are allowed to edit or view all guest accounts.
 Group accounts: Sponsors are allowed to edit guest accounts that are created by anyone in
the same sponsor user group.
 Own account: Sponsors are allowed to edit only the guest accounts they created.
You can choose one of the following options for Suspend or Reinstate Accounts:
 No: Sponsors are not allowed to suspend any guest accounts.
 All accounts: Sponsors are allowed to suspend or reinstate all guest accounts.
 Group accounts: Sponsors are allowed to suspend guest accounts that are created by anyone
in the same sponsor user group.
 Own account: Sponsors are allowed to suspend only the guest accounts they created.
 The Account Start Time setting restricts the number of days the sponsor can specify for
starting the guest account which is applicable only for the Start End type of time profile.
 The Maximum Duration of Account setting specifies the maximum duration for which a
guest account can be active. The expiration date is based on the maximum duration of the
account or the time profile duration, whichever is less. This value overrides the maximum
duration value that is set by the sponsor during the creation of the guest account when this
value is less than the one specified in the time profile.
There are multiple ways to notify guests with their credentials
and other access info
• Print the details
• Send via e-mail
• Send via SMS
To provision guest accounts on the Cisco ISE, you must be a sponsor user. The configuration is
performed in the sponsor portal. Follow these steps to create guest accounts:
Step 1 Connect to the sponsor portal.
Step 2 (Optional) Create single guest accounts.
Step 3 (Optional) Create random guest accounts.
Step 4 (Optional) Import guest accounts from a file.
Step 5 (Optional) Verify guest user accounts.
To create guest accounts, connect to the sponsor portal and log in as a sponsor user. The
sponsor portal is accessible at the address https://<PSN-FQDN>:8443/sponsorportal. This
assumes the default port 8443 of the sponsor portal has not been changed for the admin portal.
One method of provisioning guest user accounts is for a sponsor to manually create individual
guest user accounts. The attributes that are presented in the configuration page have been
defined in the guest details policy.
Alternatively, you may create a number of random users at one time. In order to configure
random users in the sponsor portal, select the Create Random Guest Accounts menu from the
main sponsor portal window, enter the number of random users to create, a username prefix (if
any), and the group role to which these users should be added.
Another option is to import guest user accounts from a comma-separated value (CSV) file. The
template file, which can be downloaded and viewed using the Download Import File Template
button, determines the format of the file.
The sponsor portal offers the option to view the created guest user accounts. The displayed list
includes the guest usernames, along with their primary attributes, such as first name, last name,
and email address.

ISE 1.2 will support multiple pre-activated
guest groups. 802.1X PEAP-
MSCHAPv2 or
Do not redirect EAP-GTC
my contractors to
guest portal
LWA to local WLC

portal
Remote Access
VPN
ISE
Guest
DB
If you have contractors or guests coming in with 802.1X clients, or an LWA to a local WLC
portal or even Remote Access VPN authentication, you do not want to redirect that traffic to the
guest portal. The problem is that if you just created guest accounts, the account does not get
activated until a guest actually logs in to the guest portal and accepts the acceptable use policy
(AUP). When a guest tries to authenticate with this method, a RADIUS message will be sent by
the NAD and ISE PSN will check against the guest database but, because the account has not
been activated, the authentication will fail.
The solution is to create guest accounts that are preactivated so that the user can log in via
802.1X, the WLC, or VPN on the ASA. The advantage is that you can use the guest life cycle
to manage users that in the past had to be managed by the AD administrator.
Cisco ISE1.2 will support multiple preactivated groups.
A contractor takes
time off. Can I
suspend and then
reinstate access?
Another new feature of Cisco ISE 1.2 is that guest accounts can be suspended and reinstated.
A guest or
contractor stay is
extended but their
account expired.
Another new and more important feature of Cisco ISE 1.2 is that an existing account can be
extended by changing the account duration.

Can I limit one
active device per
Guest account?
Additionally with Cisco ISE 1.2, you can now manage the number of sessions per user.
PSN
DMZ
Corp
PSN
Cisco ISE comes with four interfaces, but by default everything happens on interface 0. Due to
customer requests, Cisco ISE 1.2 now allows you to dedicate an interface specifically for the
guest portal and client provisioning portal in a demilitarized zone (DMZ).
In the Operations tab of the portal configuration, you can define the following guest actions:
 Guest users should agree to an AUP. The selectable options are Not Used, First Login, and
Every Login.
 Enable self-provisioning flow or mobile device management (new to Cisco ISE 1.2).
 Enable mobile portal (new to Cisco ISE 1.2).
 Allow guest users to change password.
 Require guests and internal users to change password at expiration.
 Guest users should download the posture client.
 Guest users should be allowed to perform self-service.
 Guest users should be allowed to perform device registration.
 You can check the VLAN DHCP option to refresh the IP address of Windows clients after
a VLAN change. This option applies to wired and wireless environments for guests with no
posture.

Authentication page
Acceptable usage policy
Success/failure page
Cisco ISE provides localization and internalization support for the following languages for the
sponsor portal:
 Chinese traditional; browser locale: zh-tw
 Chinese simplified; browser locale: zh-cn
 Czech_Cestina (new to Cisco ISE 1.2)
 Dutch_Netherlands (new to Cisco ISE 1.2)
 English; browser locale: en
 French; browser locale: fr-fr
 German; browser locale: de-de
 Hungarian_Magyar (new to Cisco ISE 1.2)
 Italian; browser locale: it-it
 Japanese; browser locale: ja-jp
 Korean; browser locale: ko-kr
 Polish_polski – New to ISE 1.2
 Portuguese; browser locale: pt-br (Brazilian)
 Russian; browser locale: ru-ru
 Spanish; browser locale: es-es
Internationalization and localization applies to all supported internet browsers. Cisco ISE
allows you to add, modify, and delete custom language templates for the sponsor portal. You
can also duplicate standard language templates, which you then modify to create a custom
template.
You can customize a portal theme by changing text, banners, background color, and images.
This functionality allows you to change the appearance of a portal without having to upload
customized HTML files to the Cisco ISE server. Supported image formats include JPG, JPEG,
GIF, and PNG.
You have, among others, the following customization options:
 You can change the logo of the portal login page. You can choose the default Cisco logo or
upload a custom image. When you upload the image, it is automatically resized.
 You can change the background image of the portal login page. You can choose the default
Cisco background or upload a custom background image.
 You can change the portal banner logo. You can choose the default Cisco banner or upload
a custom banner logo.

To create a personalized portal with custom HTML pages, you must first add a new portal.
The guest portal URL for wired and wireless local web authentication is
https://ip:8443/guestportal/portals/PortalName/portal.jsp, where PortalName is the name of the
portal as it is created during the upload.
The guest portal redirect URL for CWA is
https://ip:port/guestportal/gateway?sessionId=SessionIdValue&portal=PortalName&action=cw
a.
The ip and port values are updated by the RADIUS server as the URL redirect is returned to the
NAD. These values are the IP address and port number for the Cisco ISE guest portal server.
1. Add AUP checkbox to Both guests and employees
get Internet access from one SSID.
customized Guest HTML
pages. Only show the AUP on first login.
2. Save a cookie when the user

logs in.
3. Hide the AUP checkbox if the
cookie exists.
• Skills required:
- Basic HTML
- Basic
JavaScript
Both guests and employees will log in at the same guest portal. The first time a user connects
requires the user to accept the AUP. Once the user has accepted the AUP, the user should not
have to accept it again so the AUP check box can be hidden after first login.
The following are the steps for hiding the AUP checkbox:
Step 1 Add the AUP checkbox to the customized guest HTML pages.
Step 2 Save a cookie when the user logs in.
Step 3 Hide the AUP checkbox if the cookie exists.

• Operations > Authentications window will show all authentications
including guests.
• Identity and authorization can be found for guests .
To verify both successes and failures, navigate to Operations > Authentications to show all
authentications including guest.
• When Cisco ISE is used as a RADIUS server to authenticate clients,
Cisco Prime Infrastructure collects additional information about these
clients from the ISE and provides all relevant client information to Cisco
Prime Infrastructure to be visible in a single console.
Step 1: In Cisco Prime

Infrastructure, navigate to Design >
External Management Servers
(under Management Tools) > ISE
Servers.
Step 2: Add a new ISE server by

selecting Add Identity Services
Engine as shown in the figure.
Step 3: Once required information is

entered, confirm that the Cisco ISE
server is added to the list.
Cisco ISE is the RADIUS Server used to authenticate and authorize access. By integrating
Cisco ISE into Prime Infrastructure, you now have a single pane of glass to monitor the entire
network.
When Cisco ISE is used as a RADIUS server to authenticate clients, Cisco Prime Infrastructure
collects additional information about these clients from Cisco ISE and provides all relevant
client information to Cisco Prime Infrastructure to be visible in a single console.
Perform these steps:
Step 1 In Cisco Prime Infrastructure, navigate to Design > External Management Servers
(under Management Tools) > ISE Servers.
Step 2 Add a new ISE server by selecting Add Identity Services Engine as shown in the
figure above.
Step 3 Once the required information is entered, confirm that the Cisco ISE server is added
to the list.

• For wired and wireless devices and clients, offers integrated
management, monitoring, and troubleshooting
• How?
- SNMP is used to discover clients and collect client data.
- Cisco ISE is polled periodically to collect client statistics and other attributes.
Cisco Prime infrastructure offers integrated management, monitoring, and troubleshooting for
wired and wireless devices and clients.
SNMP is used to discover clients and collect client data.
Cisco ISE is polled periodically to collect client statistics and other attributes.
• Results are populated to related dashboard components and reports.
• Cisco ISE provides authentication records to Cisco Prime Infrastructure
through the REST API.
• Network administrators can choose a time period for retrieving
authentication records from Cisco ISE.
• The figure shows that the authentication record indicates that the user
was not found in the ISE database.
The dashboard and reports are populated with results.
Deliver native MDM and integrate with AnyConnect.
Native MDM Features in ISE

1 • Leverages ISE as the Device Manager
• Leverages AnyConnect Mobile as the MDM Agent
2 Integration of ISE & ASA

• Enforce ISE Policy for Remote Access Users
3 Deliver New Set of API - xGrid

• Expand ISE eco-system with new APIs (Lancope, Prime… )
4 Deliver Highly Requested Features

• Multiple AD Forest Support
• Guest API
The figure describes features that are expected in Cisco ISE 1.3.

2H CY 13 1H CY 14
AnyConnect 3.2 AnyConnect 3.3
Unified Agent (NAC Agent Layer 3 Authentication Support

Integration with AnyConnect) NEA Compliance
IPv6 Phase II SCCM Support
Web Agent
Miscellaneous VPN Requests
Grace Period Remediation
MDM Phase II (Container and App
Tunnels)
The figure describes upcoming features for Cisco AnyConnect.
Summary
• This lesson reviewed the Cisco ISE solution and its capabilities, as well
as where it fits into current network scenarios and how it is used.
• You now understand the elements used to provide secure access
including authentication and authorization policies in Cisco ISE. You
examined the Cisco ISE authentication process as well as profiling and
posturing.
• You explored how Cisco ISE Setup Assistant can be used to configure a
secure proof of concept environment to support BYOD.
• You know how Cisco ISE supports guest services for self-service guest
accounts as well as sponsored guests.
• The Cisco ISE Roadmap describes what features are expected in the
future and the compatibility capabilities for Cisco ISE to support EAP
and AnyConnect.
Cisco ISE provides consistent policy for wired, wireless, and VPN networks.
References
The following figures provide additional resources and reference information.
HLD/LLD Submissions – Tracking Page

sac-support@cisco.com
HLD/LLD Submissions – File Folder
ATP Certified SEs
http://pmbuwiki.cisco.com/ATP_Information/List_of_Partners_
who_have_completed_Training_for_ATP_ISE
TME HLD Review Alias


• Partner links
- Partner Resources (ATP info, xLD templates):
http://www.cisco.com/en/US/partner/products/ps11640/products_partner_resources_list.html
- ATP Portal (Everything ISE) http://www.ciscosecurityatp.com/
- ATP Navigator (comprehensive information site for partners):
http://www.cisco.com/web/partners/pr11/atp/atp_navigator.html
• Internal links
- ISE Sales Process: http://wwwin.cisco.com/swg/pmbu/ise/sales-portal/
- ISE - Product Resources (xLD Templates, Ordering/Licensing/Migration Guides):
http://wwwin.cisco.com/swg/pmbu/ise/resources.shtml
- PMBUwiki ATP Info (Design Lectures, List of ATP Certified SEs, etc):
http://pmbuwiki.cisco.com/ATP_Information
- PMBUwiki - ISE Performance Info: http://pmbuwiki.cisco.com/Products/ISE#Performance
• Aliases
- ISE HLD Submission Alias: sac-support@cisco.com (WW)
- ISE HLD Pre-Submission Support: ise_hld_help@cisco.com (US Only) & sac-
support@cisco.com (WW)
• Communicate ISE issues
- Americas: atp-ise-americas@cisco.com
- APJC: atp-ise-apjc@cisco.com
- EMEA: atp-ise-emea@cisco.com
• Cisco ISE product - http://www.cisco.com/go/ise

• TrustSec - http://www.cisco.com/go/trustsec
• TrustSec design and how-to guides
http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns744/landing
_DesignZone_TrustSec.html
• Cisco ISE 1.1.1 demos
https://communities.cisco.com/community/partner/borderlessnetworks/s
ecurity?view=video
• dCloud BYOD hosted demos – http://www.cisco.com/go/byoddemo
• Free NFR lab software for partners (1.1.1 Available)
- Cisco Marketplace - $35 VMware image, perpetual license, 20 endpoints
http://cisco.mediuscorp.com/ise
• PDI helpdesk - http://www.cisco.com/go/pdihelpdesk
• Program-related questions - pdihd-bn@cisco.com
• Your Cisco PDM and CSE
EAP Type Win7 Vista WinXP AC 3.0 Apple SL Ubuntu RHL
Native Native Native (10.5)
EAP-TLS Yes Yes Yes Yes Yes Yes Yes
EAP-TTLS No No No Yes Yes Yes Yes
PEAP- Yes Yes Yes Yes Yes Yes Yes

MSCHAPv2
PEAP No No No Yes Yes Yes Yes
EAP-GTC
PEAP Yes Yes Yes Yes Yes Yes Yes
EAP-TLS
EAP-FAST No No No Yes Yes Yes Yes
MSCHAPv2
EAP-FAST No No No Yes Yes Yes Yes
EAP-GTC
Ubuntu, RHL = wpa_supplicant

EAP Type ISE ACS 5.4 AD LDAP
EAP-TLS Yes Yes Yes Yes
EAP-TTLS No No Yes Yes
PEAP- Yes Yes Yes No

MSCHAPv2
PEAP Yes Yes Yes Yes
EAP-GTC
PEAP Yes Yes Yes Yes
EAP-TLS
EAP-FAST Yes Yes Yes No
MSCHAPv2
EAP-FAST Yes Yes Yes Yes
EAP-GTC
EAP and ID Store configuration and data

http://www.cisco.com/en/US/docs/security/ise/1.0.4/user_guide/ise10_man_id_stores.html

Cisco ISE and TrustSec How-To Guides:
http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns7
44/landing_DesignZone_TrustSec.html
Module Self-Check
Q1) What are the three personas built into ISE? (Choose three). (Source: Basic Cisco ISE
AAA and Guest Server Setup for Wired and Wireless Networks)
A) Inline Posture Node (IPN)
B) Monitoring & Trouble shooting (MnT)
C) Policy Administration Node (PAN)
D) Client Provisioning Portal (CPP)
E) Policy Service Node (PSN)
Q2) ISE can be installed on which platforms? (Choose three). (Source: Basic Cisco ISE
AAA and Guest Server Setup for Wired and Wireless Networks)
A) MicroSoft Server 2013
B) Cisco 33x5 Appliance
C) Cisco C3850 Switch
D) Cisco SNS-34x5-K9 Servers
E) Virtual Machine (ESXi or ESX)
Q3) Cisco ISE replaced which of the following servers? (Source: Basic Cisco ISE AAA and
Guest Server Setup for Wired and Wireless Networks)
A) Cisco Secure Access Control Server (ACS)
B) Cisco Profiler
C) Cisco Guest Server
D) Network Access Control (NAC) Manager
E) NAC Server
F) All of the above
Q4) In a Standalone deployment where all three personas are on one node. What is the
maximum number of concurrent endpoints supported? (Choose two). (Source: Basic
Cisco ISE AAA and Guest Server Setup for Wired and Wireless Networks)
_____ 1. Cisco ISE 33x5 Appliance
_____ 2. Cisco SNS-3415-K9
_____ 3. Cisco SNS-3495-K9
a. 5000
b. 10,000
c. 2000
Q5) What is new in ISE 1.2? (Choose six). (Source: Basic Cisco ISE AAA and Guest
Server Setup for Wired and Wireless Networks)
A) 64 bit operating system
B) Cisco Guest Server
C) Profiler Feed Service
D) Logical Profiling
E) Setup Assistant
F) 32 bit operating system
G) Guest Account Duration changing
© 2013 Cisco Systems, Inc. CONFIDENTIAL Basic Cisco ISE AAA and Guest Server Setup for Wired and Wireless Networks 3-93
Q6) Cisco ISE PSN has many services running. Which service is NOT running on the PSN?
(Source: Basic Cisco ISE AAA and Guest Server Setup for Wired and Wireless
Networks)
A) Guest Portal
B) Client Provisioning Portal
C) Sponsor Portal
D) Admin Portal
E) Radius Server
F) Profiling
Q7) Cisco ISE PSN is the Radius Server for the Network Access Devices (NADs). Select
the possible NADs that ISE PSN could support? (Source: Basic Cisco ISE AAA and
Guest Server Setup for Wired and Wireless Networks)
A) Cisco Switches
B) Cisco Wireless LAN Controllers
C) Cisco ASAs
D) Cisco ISE running as an Inline Posture Node (IPN)
E) All of the above
Q8) In a distributed deployment, only the Policy Service Persona will be running on a PSN.
What is the maximum number of concurrent endpoints supported on the following
PSNs? (Source: Basic Cisco ISE AAA and Guest Server Setup for Wired and Wireless
Networks)
_____ 1. Cisco ISE 3315 Appliance
_____ 4. Cisco SNS-3415-K9
_____ 5. Cisco SNS-3495-K9
a. 20,000
b. 5000
c. 2000
d. 10,000
e. 6000
f. 3000
Q9) ISE requires Licensing for production deployments. Match the correct type of License
to the following deployments requirements. (Source: Basic Cisco ISE AAA and Guest
Server Setup for Wired and Wireless Networks)
_____ 1. Customer has both wired and wireless endpoints and needs to ensure all
the devices are compliant to the corporate policies.
_____ 2. The enterprise will only be authenticating wireless clients. They wish to
know and control who and what is on their wireless only network.
_____ 3. The small business owner wants to control his employee and guest access
to his network but is currently not concerned about the health of the
devices.
a. ISE Base License
b. ISE Advance License
c. ISE Base license plus ISE Advance License
d. ISE Wireless License
Q10) The customer has a distributed deployment and has purchased the 10 SNS-3495-K9
appliances for their wired and wireless FIPs compliancy Network. How many ISE
Licenses do they require? (Source: Basic Cisco ISE AAA and Guest Server Setup for
Wired and Wireless Networks)
A) 10, one for each and every node.
B) 1, just need Base License for Primary PAN
C) 2, need a Base and Advanced License for Primary PAN
D) Depends. Will need Base and Advanced License for Primary PAN but we also
need to know how many endpoints and how many endpoints need
profiling/Posturing/MDM to truly determine the licenses required
© 2013 Cisco Systems, Inc. CONFIDENTIAL Basic Cisco ISE AAA and Guest Server Setup for Wired and Wireless Networks 3-95
Q1) B, C, E
Q2) B, D, E
Q3) F
Q4) 1 – c, 2 – c, 3 – b
Q5) A, C, D, E, G
Q6) D
Q7) E
Q8) 1 – f, 2 – e, 3 – d, 4 – b, 5 –a
Q9) 1 – c, 2 – d, 3 – a
Q10) D
Module 4
One Network—Building the

Wireless Network
Lesson 1
Wireless Network Architecture

Overview
The Cisco “One Network” strategy comprising a complete end-to-end network solution
includes wireless components and features. This lesson discusses the different wireless
architectural configurations and components available to meet the needs of different customers.
The lesson includes a forward-looking roadmap of Cisco wireless products and features to
provide you a view of how Cisco is evolving the network.
In this course, the example customer scenario is HTA Hospital. The hospital has established the
wired network infrastructure, Cisco Identity Services Engine (ISE), and Cisco Prime
Infrastructure. In this scenario, the IT team wants to verify and expand on their current wireless
capabilities. Providing them the options to choose the right architectural topology and products
for their business will enable them to serve successfully the wireless clients of their employees,
medical devices, patients, and guests.
Objectives
Upon completing this lesson and given a specific customer scenario, you will be able to meet
the following objectives:
 Describe the four Cisco wireless LAN deployment architectures
 Describe the Cisco wireless LAN portfolio of products
 Reference the Cisco wireless LAN compatibility matrix
 Discuss the Cisco wireless LAN roadmap
HTA Hospital Use Case
This topic describes a use case with HTA Hospital.
• After successfully securing their wired network, HTA Hospital decides to

leverage their existing wireless equipment.
• Deploying wireless implies configuring controllers and access points,
and optimizing the RF environment, but also applying security
configurations specific to wireless users and devices.
• As wireless is a shared medium, QoS is a major concern, and HTA
Hospital needs to optimize their network QoS to take into account the
needs of wireless devices.
• The Cisco solution also offers additional possibilities to optimize the
network experience based on user location. HTA Hospital wants to
examine these different possibilities and check which features may
apply to their specific environment.
© 2013 Cisco and/or its affiliates. All rights reserved. CONFIDENTIAL One Network-Building the Wireless Network UASEBC v1.0—4-5
Cisco Wireless LAN Deployment Architectures
This topic discusses the four different Cisco wireless deployment architectures: autonomous,
FlexConnect, centralized, and converged access.
Autonomous FlexConnect Centralized Converged Access

(Unified)
WAN
Traffic
Individual APs Traffic Distributed Centralized Traffic Distributed
at AP at Controller at Switch
Small Wireless
Branch Campus Branch and Campus
Network
Purchase Decision • Wireless only • Wireless only • Wireless only • Wired and wireless
• Simple and • Highly scalable for • Simplified • Wired and wireless
cost-effective large number of operations with common operations
for small remote branches centralized control • One enforcement point
networks • Simple wireless for wireless • One OS (IOS)
Benefits
operations with • Wireless traffic • Traffic visibility at every
DC-hosted visibility at the network layer
controller controller • Performance optimized
for 11ac
• Limited RRM, • L2 roaming only • System • Catalyst 3850 in the
Key no rogue • WAN BW and throughput access layer
Considerations detection latency
requirements
The autonomous architecture comprises individual Access Points (APs). By individual APs, we
mean each AP is managed independently and not unified by connection to the network through
attachment to a wireless LAN controller (WLC). An autonomous architecture may be desired
by smaller enterprises because they are simple to deploy and cost-effective.
A FlexConnect architecture is typically positioned for enterprises that have branch or remote
offices. This architecture is well suited for locations with a relatively small number of APs
where deployment of a WLC is not justified or desired. During FlexConnect operation, wireless
LAN data traffic is either tunneled back to a central WLC (central switching) or the data traffic
is broken out locally at the wired interface (local switching) of the AP. When a FlexConnect
AP can reach a WLC, it is said to be in connected mode. When a FlexConnect AP cannot reach
a WLC, it goes into standalone mode.
The centralized or unified architecture, often referred to as a Cisco Unified Wireless Network
(UWN), is one where APs are managed and monitored by WLCs. Clients and APs send critical
information regarding cell coverage, interference, and client traffic back to the WLCs. This
architectural model is appropriate for campus environments where traffic is centralized.
A converged access architecture represents the convergence of wired and wireless traffic,
where both types of traffic may be switched on the same converged access (CA) platform that
functions as both a switch and a WLC. The CA platforms run on IOS-based operating systems,
thus standardizing and simplifying the user interface.
Each of these architectural models has benefits as well as limitations. When determining the
correct model for a given customer, you must consider the existing network infrastructure, the
desired network performance, and the right component models and features that will support
the desired goals. Enterprises may be cost-sensitive but most also want a secure solution that
will grow as their needs grow.
© 2013 Cisco Systems, Inc. One Network—Building the Wireless Network 4-5
The flexibility of the Cisco wireless LAN portfolio and deployment architectures is by design.
Cisco is able to tailor the infrastructure and services for various vertical market applications. In
the education market space, K-12 schools are mostly concerned about cost and desire easy
wireless connections throughout the campus. Additional concerns include segmentation of
teacher and staff traffic from students and guests, collaborative learning techniques, use of
smartboards, wireless printers, and other conveniences. A school campus environment typically
has a dense number of users during certain hours of the day. Faculty, staff, students, and guests
expect bring your own device (BYOD) adaptations.
BYOD, in fact, most notably started with the higher education market segment. Wireless and
specifically mobility are essential to wireless users at a college or university. They share the
same needs for segmentation of traffic, collaborative learning, use of eReaders, and so forth.
The healthcare industry has very demanding requirements for wireless services. Security is very
important when dealing with patient care, and the use of wireless medical devices and radio
frequency identification (RFID) tags is prominent in this vertical.
These are just examples of the importance of selling the right solution to the right customer.
Cisco provides the means to support any of these explicit needs.
Cisco Wireless LAN Portfolio of Products
This topic describes the Cisco wireless LAN product portfolio.
As part of the One Network solution, wireless LAN products provide the capability for wireless
devices to connect to the network. Wireless devices connect to APs that either directly connect
to the network or are managed by WLCs. The converged access architecture makes it possible
to combine the WLC and switching functionality into one platform. The Cisco Mobility
Services Engine (MSE), in conjunction with Cisco Prime Infrastructure, provides advanced
services such as intrusion prevention, location services, and connected consumer services.
In the past couple of years, Cisco has launched its second generation of APs based on 802.11n
technology. These APs include the AP1600, AP2600, and AP3600. These APs provide the
highest possible throughput, utilize multiple antenna technology, and are CleanAir-enabled,
meaning they contain firmware that helps to mitigate sources of interference that would
otherwise cause disruption of signal quality or wireless service altogether. Features such as
CleanAir are described later in this course.
The AP1600, AP2600, and AP3600 are intended for use in indoor environments. Cisco also
offers second-generation ruggedized and outdoor APs—the Cisco 1550 Series Access Points.
Some environments such as manufacturing plants require a more durable AP construction, and
outdoor APs are exposed to the natural outdoor elements.
The portfolio of WLCs ranges from the virtual WLC to the FlexConnect WLC7500 to the
higher-capacity WLC8500. Some controllers, such as the WiSM2, fit within existing
infrastructure components, while others are standalone. The converged access controllers, the
Catalyst 3850 and the Catalyst 5760, combine the switching and controller functionality into a
single platform that is IOS-based.
As mentioned previously, the MSE extends basic wireless capabilities into more sophisticated
monitoring, interference prevention, location, and connected consumer services.
Access Points
This topic describes the models of Cisco APs.
As you move from left to right in the figure, the placement of the AP models indicates
scalability and functionality. The AP600 is an OfficeExtend component designed for
teleworkers. Sometimes termed OEAP, the AP600 allows companies to provide corporate
wireless LAN services to employees who need access from remote work locations.
The AP1600, 2600, and 3600 are built on the same foundation of 802.11n technology but are
scaled to meet the needs of businesses of various sizes. Notice that these APs provide CleanAir
capabilities.
Prior to the AP3600, Cisco launched the first CleanAir-capable AP, the AP3500. In terms of
number of clients it can support, the AP3500 addresses the business-ready market previously
served by AP1140 and AP1260. The latter two APs are not CleanAir-capable.
The AP3600 has a unique, forward-looking modular design that accommodates the ability for
customers to add more services and capabilities as needed. For example, Cisco anticipated the
pending technology evolution to 802.11ac by creating an 11ac add-on module that can be easily
inserted in the underside of the AP3600. This ability avoids a complete replacement of APs in
order to support 11ac clients and speeds. With this module available in May 2013, customers
who already deployed or who purchase the AP3600 with the module can serve 802.11ac-
capable clients.
Controllers
This topic describes Cisco WLC products.
SRE
vWLC
The figure shows WLCs from left to right, indicating the increase in scale and other
capabilities. Customers can choose from a virtual WLC running in a virtual machine
environment on a server of their choice, or they can select low-, medium-, or high-end WLCs
based on their business needs. The virtual WLC is primarily focused on price-sensitive mid-
market solutions for FlexConnect AP management. The WLC7500 is also specifically designed
for use in larger scale FlexConnect deployments. Higher-end WLCs provide capabilities such
as high availability that are not available on all WLCs.
Conveniences of a WLC-based architecture include the ability to configure multiple APs,
control software image downloads, create mobility groups, and a host of other time-saving and
more productive operations.
Cisco Mobility Services Engine
This topic describes Cisco MSE services.
Advanced Spectrum Capability Indoor Location/Context-Aware
• System wide interferer details • Real-time location tracking

• Event correlation • Tracking, probing, and associated
• Visualization of interferer zone of clients, RF tags, and wired
impact endpoints
• Interferer notification • Geo fencing/zone-based alerts
• Track and trace interferers and Layer 1 • Location analytics
threats
Wireless Intrusion Prevention Mobile Concierge

• Detection and mitigation of security • Detecting presence
penetration attacks • Delivering location-based services
Physical and
• Detection and mitigation of denial of Virtual Appliance
service attacks
• Capability supported in Monitor MSE tracks up to
Mode and data serving AP (Enhanced 50,000 endpoints and
Local Mode [ELM]) supports 10,000
Monitor Mode
or ELM AP
Cisco MSE is sold as either a virtual appliance or a physical platform. To some extent, the MSE
may be thought of as a data collection point, but with additional capabilities that make it
possible for customers to increase the effectiveness of their wireless investment.
MSE offers the following:
 A way to visually depict the impact of interference on network performance so that
interference can be reduced
 The ability to implement a wireless intrusion prevention system (wIPS) to ward off security
threats
 A way to track the location of wireless devices, displaying them on the customer’s floor
maps
More recently, MSE became part of a solution that monetizes the wireless LAN by offering
connected consumer services. For certain types of businesses such as retail, this is a game-
changing view from the customer perspective. No longer do customers worry only about the
cost of the wireless network, they can actually use it to make money.
One of the connected consumer applications is Mobile Concierge. Using a third-party
application that communicates with the MSE, enterprises can offer mobile concierge services to
its wireless end users. For example, a shopping mall may want users with iPhones, tablets, and
so on, who enter their facility to be offered a navigational map, directions to restaurants, sales
advertisements, coupons, and so forth.
Each of the MSE services is described in more detail later in this course.
Cisco Wireless LAN Compatibility Matrix
This topic describes a Cisco wireless LAN compatibility matrix, an Excel spreadsheet tool that
is useful when determining the types of APs, WLCs, and services that a customer may need.
For Cisco internal and NDA partners only
• The compatibility matrix provides an at-a-glance comparison of the

wireless LAN components and the features and functionality that each
supports.
• The matrix also indicates scaling information and best architectural fit for
large campus, service provider, small campus, and branch.
The wireless LAN compatibility matrix is a tool that helps enable system engineers and other
personnel to advise customers about deployment architectures, equipment models, and other
elements they will need to satisfy their business needs. The spreadsheet shows the WLC models
and provides details about which architecture each best supports, and many other details.
When you first open the compatibility matrix spreadsheet, notice the worksheet tabs at the
bottom. There is a read me first tab, an all controllers comparison tab, a tab for large campus,
service provider, small campus, and branch. The various types of functionality available in the
system are notated as available (√) or not available (x) under each column.
Cisco Wireless LAN Roadmap
This topic discusses new products and features targeted for future Cisco wireless LANs.
Cisco Confidential – NDA Only

Committed In Planning
Sep 2012 Dec 2012 Q2CY13 2HCY13/Q1CY14

s/w release 7.3 7.4 7.5
AP3700 - Modular AP
AP 2600 AP1600 AP3600
11ac – Wave 1
802.11n G2 802.11n G2 11ac - Wave 1 Module
Outdoor AP1532
Unified Access—WLAN Infrastructure
AP700 (also Bridge with

Outdoor AP AP3600 Autonomous s/w)
Uni Band Antenna WSSI Module China SP AP 3G Small Cell Module for
OEAP 600 Split AP3600
WLC 8500
Target Customer - SP Application Visibility and Tunneling 1552WU with Emerson
Control (AVC) HART GW
OEAP Support on vWLC
Stadium Hi-Gain Antenna
Virtual Controller Bonjour Services Directory for AP3700
Phase 1 CT2500 HA SKU, N:1
CT8500 as
Scale Flex7500 MC for Converged Access
6K APs AP Neighbor List Profiling and Policy on
(Subset of 802.11k) WLC Native IPv6 (Centralized
Mode Only)
Controller Resiliency - AP
SSO Guest Anchor on CT8500 CleanAir Express for
HA Licensing Scale WLC 2500 AP1600
Controller Resiliency Mesh Support for
FlexConnect Split HA Licensing, N:1 Client SSO FlexConnect
Tunneling Over any L2 Connection VideoStream for
802.11w (local mode) FlexConnect
802.11r – Flex Modes Bonjour Services
Protected Mgmt Frame Directory PMIPv6 MAG on AP
Phase 2
Bi-Directional Rate Limiting WLC as DHCP Proxy – New
LAG on Flex7500, WLC
8500, WLC 2500 FlexConnect Additions: Sub Options for SP Wi-Fi
Voice/Video: PEAP / EAP-TLS
11n CAC AAA ACL and QoS Certs – FIPS, CC,
802.11w UCAPL, USGv6
Guest Anchor on
PMIPv6 MAG on WLC WLC2500 CPI 1.4.1 / CPI 2.1
CPI 1.4
Cisco continues to lead the marketplace in the area of wireless LAN, which shows a very high
growth rate. The figure shows the traditional AireOS WLCs roadmap. Cisco first introduced
WLCs into the architecture when it acquired a company named Airespace. Airespace had
developed its own WLC hardware and software, and these WLCs are now referred to as having
an AireOS operating system. When Cisco introduced the converged access platforms in early
2013, the Catalyst 3850 and WLC 5760, the WLC operating system for these CA systems were
engineered to be IOS-compliant.
AireOS WLC code release 7.4, compatible with Cisco Prime Infrastructure code release 1.3,
was introduced to the market in January 2013. This release contained features that support end-
to-end network functionality such as NetFlow and application visibility and control (AVC), and
exciting new features such as multicast DNS (mDNS), also known as Bonjour Gateway, and
connected mobile experience (CMX). Such features support the Cisco Unified Access strategy,
as well as the BYOD reality of today.
The next release, 7.5, which is compatible with Cisco Prime Infrastructure 1.4, brings the
previously mentioned 802.11ac module for AP3600, high availability through client stateful
switchover (SSO), a host of enhancements, and a new CMX feature called Billboard
(sometimes abbreviated as BBX). Billboard is an MSE advanced location services (ALS)
feature that allows customer marketing personnel to offer value-added services to targeted
guests based on the location of the end user. You will learn more about these features in a
subsequent lesson. The first customer shipment (FCS) target for 7.5 and Prime 1.4 is June 2013.
There will be an interim release of Cisco Prime Infrastructure, v2.0, available between 7.5 and
8.0, to sync with converged access WLCs and provide improved feature parity with non-CA
WLCs. The Cisco Prime Infrastructure 2.0 release is targeted for late June to early July 2013
timeframe.
The next major software release after 7.5 is 8.0, compatible with Cisco Prime Infrastructure 2.1.
There is an interim planned in between (October 2013) to support the new 802.11ac AP (3700)
and the 1532 (low profile 802.11n outdoor AP). Release 8.0 target availability is February
2014. This release will support the 3G small cell module for AP3600; native IPv6; CleanAir
Express; and a number of feature enhancements.
IOS Controllers
This topic describes the roadmap plans for Cisco IOS-based WLCs.
Cisco Confidential – NDA Only

Committed In Planning
Q1CY13 Q2CY13 Q3CY13

s/w release IOS XE 3.2.0 SE IOS XE 3.2.x IOS XE 3.3
Enterprise Campus Parity Enterprise Campus Parity
Cisco Unified Access—WLAN Infrastructure
with 7.0 Release Enterprise Campus Parity with 7.4 Release

MSE 7.4 with 7.0 Release MSE 8.0
CPI 2.0 CPI 2.1
CT5760 Web GUI for Wireless on UPOE SKU, 9 Member Stacking

CT5760/Cat3850
CT5760 HA SKU, N:1
CT5500, WiSM2, CT8510
ISE 1.2 Support
MC in Converged Access Mode
Catalyst 3850 (8.0)
CT5500 and WiSM2

MC in Converged Access Mode AP3700 - Modular AP
(7.3MR1) 11ac – Wave 1
AP3600, AP2600, AP1600 * AP3600

Support 802.11ac Wave 1 Module
ISE 1.1MR Support

HA - AP SSO
With Stacking Cable
Multiple LAG
IPv6 Interface, IPv6 Client Mobility Bonjour Services Directory
Secure Copy App Visibility with G2 11n APs

Granular QoS
TrustSec SXP and SGT
Downloadable ACLs
802.11r and Neighbor List
Flexible Netflow v9
802.11w
EEM/TCL Scripting
* AP1600 not supported with CT5500/WiSM2 on 7.3MR1 with Converged Access Mode
The first release of IOS-based CA WLCs was built on IOS XE 3.2.0 SE. The wireless LAN
feature scope was equivalent to AireOS-based WLC code 7.0. The figure lists the main features
that rolled out in the first release. A maintenance release of the IOS code, IOS XE 3.2.x was
released in June 2013. The maintenance release introduced a new CA WLC web GUI and
BYOD onboarding capability. BYOD were expected to be supported in the FCS code, but
BYOD onboarding (1 SSID, 2 SSID cases, with provisioning) presented several issues related
to the onboarding process and the change of authorization returned from the Onboarding server
(ISE). The maintenance release addressed these issues, and also ensured compatibility with ISE
1.2. Please refer to module 5 for more details.
The next major release for CA WLCs is based on IOS XE 3.3, and addresses feature parity with
AireOS WLC code release 7.4. The 3.3-based release will be supported by Cisco Prime
Infrastructure code release 2.1 and similarly targeted for late August to early September 2013.
The figure lists the features equivalent to AireOS 7.4 WLC code.
Summary
This topic summarizes the key points of this lesson.
• You now understand Cisco Unified Access: One network (wired +

wireless) + One Policy + One Management
• You reviewed the four deployment architectures:
- Autonomous
- FlexConnect
- Centralized and Unified
- Converged access
• You reviewed the portfolio of WLCs, APs, MSE options, and integration
with ISE and Cisco Prime Infrastructure
- Small to large campus solutions
- Branch and campus solutions
• You can describe the roadmap objectives: Continue to build on BYOD,
mid-market solutions, RF excellence, cloud services, network resiliency,
connected consumer business, and E2E product integration
Lesson 2
Basic Wireless Connectivity

and Functionality
Overview
After verifying customer requirements and confirming network design criteria, the wireless
network components are installed and basic services need to be enabled. This lesson covers the
implementation of foundational services for a wireless network.
Making efficient use of wireless spectrum is important for network performance and requires
the system capability to manage the RF environment in real-time and still maintain appropriate
power levels. RF management also includes the ability to detect and mitigate RF interferers that
would otherwise affect network performance. With today’s growing use of wireless devices,
the wireless network also must be capable of serving a mix of clients with various levels of
wireless protocols. Also, depending on customer need and the actual network infrastructure that
the customer has, enterprise-level wireless operation often dictates the need for the highest
possible level of wireless operational resiliency.
Objectives
Upon completing this lesson, and given a customer scenario and a wireless LAN comprised of
switches, access points (APs), Cisco Unified Wireless Network (UWN) wireless LAN
controllers (WLCs), Cisco Prime Infrastructure (PI), and Cisco Mobility Services Engine
(MSE), you will be able to meet the following objectives:
 Explain how to maintain optimum RF conditions in a changing environment
 Describe how to improve client predictability and performance
 Explain how Cisco ClientLink technology uses client uplink to optimize downlink
performance
 Describe how Cisco CleanAir helps build an intelligent RF network
 Describe high availability wireless solutions
Maintaining Optimum RF Conditions in a
Changing Environment
This topic describes features and functionality of Cisco Radio Resource Management (RRM)
needed to provide maximum performance within the RF spectrum.
• What are the objectives of RRM?

- To dynamically balance the infrastructure and mitigate changes
- To monitor and maintain coverage for all clients
- To manage spectrum efficiency so as to provide the optimal throughput under
changing conditions
• What RRM does not do
- Substitute for a site survey
- Correct an incorrectly designed network
- Manufacture spectrum
© 2013 Cisco and/or its affiliates. All rights reserved. CONFIDENTIAL One Network—Building the Wireless Network UASEBC v1.0—4-5
The first enterprise Wi-Fi networks were added conveniences that were used for web surfing in
building lobbies or conference rooms. For these applications, a best-effort level of performance
was acceptable. Today, Wi-Fi has matured and is now often deployed for many mission-critical
applications. Wi-Fi is increasingly used for rich media applications such as voice and video,
which are sensitive to the impact of interference.
RRM allows the unified wireless architecture to analyze the existing RF environment
continuously, automatically adjusting the power levels and channel configurations of APs to
help mitigate such things as noise from non-802.11 signals, co-channel interference, and signal
coverage problems. RRM reduces the need to perform exhaustive site surveys, increases system
capacity, and provides automated self-healing functionality to compensate for RF dead zones
and access point (AP) failures. Even though the RRM process uses information that is gathered
by the deployed APs to make decisions on adjustments to AP channel assignments and power
settings, a change in the RF environment does not necessarily mean that a WLC will change
current settings for any given AP.
As large-scale, dense wireless LANs have become the norm, administrators are challenged
continuously with RF configuration issues. If processed improperly, these issues can lead to
wireless LAN instability and a poor end-user experience.
The addition of capacity to a wireless LAN is an issue unlike that of wired networks, where
common practice is to increase bandwidth to solve the problem. In a wireless network,
additional APs are required to add capacity, but if configured incorrectly the additional APs can
actually lower system capacity due to RF interference and other factors.
• Dynamic Channel Assignment (DCA)
- Each AP radio gets a transmit channel
assigned to it.
- Changes in “air quality” are monitored,
AP channel assignment is changed
when deemed appropriate (based on
DCA cost function).
• Transmit Power Control (TPC)
- Transit power assignment is based on
radio to radio pathloss.
- TPC is in charge of reducing Tx on
some APs—but may also increase Tx by
defaulting back to a power level higher
than the current Tx level.
- There are two versions of TPC, v1 and
v2. v1 should be preferred.
• Coverage Hole Detection and
Mitigation (CHDM)
- Detects clients in coverage holes.
- Decides on Tx adjustment (typically Tx
increase) on certain APs based on
adequacy or inadequacy of estimated
downlink client coverage.
Adequate coverage with the appropriate level of performance (throughput) to all users is
necessary. Often this requires the deployment of a large number of APs, operating on different
channels that must be selected intelligently so as not to interfere with each other. Such a task is
accomplished by the use of dynamic channel assignment (DCA) on the WLC.
The level of network performance and unnecessary noise in the wireless environment is directly
attributed to the selected transmit (TX) power levels of the APs. Maintaining performance
levels without contributing excess noise in the RF environment is accomplished by allowing the
WLC to collectively manage the AP power levels through the application of the Transmit
Power Control (TPC) algorithm, which is run on the RF group leader. TPC exists in two
versions, v1 and v2. In most cases, v1 should be preferred. v2 should only be enabled under
Cisco Technical Assistance Center (TAC) guidance to solve specific high AP density-related
issues.
Whenever a change in the AP infrastructure happens, such as an AP failure, displacement, or a
change in TX power, a coverage hole may appear and must be detected and managed. This
management is accomplished by the coverage hole detection (CHD) algorithm, which runs on
the individual WLCs.
Note In earlier versions of software, RRM was also referred to as Auto-RF.
© 2013 Cisco Systems, Inc. CONFIDENTIAL One Network—Building the Wireless Network 4-19
• RRM is configurable either on an individual controller or via a template
from the Cisco Prime Infrastructure.
• Templates are highly recommended to maintain consistency between
controllers.
CAUTION: Selection of
TPCv2 without thorough
investigation and
understanding of its impact
on the wireless environment
can severely disrupt network
coverage and capacity.
When configuring RRM within a wireless network it is highly important to maintain consistent
settings between all WLCs. Otherwise you may experience unexpected behavior within the
network. For example, should you inadvertently set one WLC to use TPC, version 1 (TPCv1)
and another for TPC, version 2 (TPCv2) while utilizing dynamic master selection, the TPC
version in use on the network will be determined by the WLC elected as the RRM master.
Potentially, if a new election occurs and the other WLC is elected as the master, the new
algorithm for TPC would determine the power settings and possibly leave coverage holes
within the network.
To avoid implementing constant changes that would keep the wireless network in a state of flux
during initial deployment or during AP additions, it is recommended to turn off RRM until all
WLCs and APs have been deployed. Then, enable RRM and allow it to stabilize the network
over the first 100 minutes after being enabled. Once the network has stabilized, an anchor time
and interval should be established to ensure that the DCA algorithm runs at least twice a day. If
the network is already running and new APs must be deployed or relocated, the RRM service
should be restarted manually once all APs have been moved or added.
There are two different algorithms from which to choose to control TPC. The algorithms are
TPCv1 Coverage Optimal Mode or TPCv2 Interference Optimal Mode. Only one algorithm
may be used at any given time within an RF group, as they are wholly incompatible with each
other.
When TPCv1 is selected, the RF group leader uses the algorithm to determine the RF
proximities of the APs in the group. This algorithm runs at a fixed 10-minute interval by
default. The group leader uses this algorithm to adjust each band’s transmit power level down
in order to limit excessive cell overlap and co-channel interference. It is important to
understand that the TPC algorithm is responsible only for turning power levels down. The
increase of transmission power is a function of the CHD and correction algorithm. For TPCv1
to work, you must have a minimum of four APs that can hear each other at an appropriate level.
TPCv1 uses the power measurements from the neighbor messages to calculate the deployment
density of the APs.
TPCv1 is designed to provide broad, even coverage between APs. To accomplish this
calculation, the algorithm tends to use higher transmit power values for each AP. For a typical
data network of average user density, this algorithm is sufficient to meet the network TPC
needs. However, when network AP placement is optimized for 5-GHz coverage, the AP
placement tends to bring the 2.4-GHz radios closer together as well, creating a dense
deployment of 2.4-GHz radios. In this type of deployment, the default values for TPCv1 tend to
produce a network with excessive 2.4-GHz coverage, referred to as an overheating situation.
TPCv2 is designed to provide good coverage around an AP while reducing the amount of
excessive interference that the same AP contributes to the wireless environment. The easiest
way to look at the differences is by comparing what is happening between the APs. Under
TPCv2, rather than running the cell edge up to a neighboring AP, the algorithm calculates for
the cell edge to occur at a point midway between the APs while still allowing sufficient overlap
for smooth roaming performance.
TPCv2 has been supported as of WLC code release 7.2 and is not a simple upgrade or tweaking
of the existing TPCv1 algorithm. TPCv2 is a completely different algorithm developed to solve
roaming and coverage issues in dense voice deployments. TPCv2 determines the cell edge
based on more than a simple power measurement. TPCv2 determines the deployment density of
each AP and calculates the required AP power by the following:
 Cell overlap area, which is the amount of interference from adjacent APs
 Cell coverage area for each AP
 Co-channel interference metric, an AP utility
Because of these different primary goals, simply using TPCv2 will not overcome fundamental
deployment issues in the network. Making the decision to shift from TPCv1 to TPCv2 requires
a firm understanding of what is different in the operation of the algorithms. Otherwise, making
the switch may mean relocating APs and will likely cause more severe problems in the network
rather than correcting problem areas. In other words, in most cases, v1 should be preferred. v2
should only be enabled under Cisco TAC guidance to solve specific high AP density-related
issues.
More detailed information on the comparison between TPCv1 and TPCv2 can be found in the
Cisco course entitled Cisco Unified Wireless Networks (CUWN).
• How do you effectively tune RF performance at the system level when a
single controller must support APs deployed in areas with vastly different
requirements?
• RF profiles allow the administrator to tune groups of APs sharing a common
coverage zone together.
- They selectively change how RRM will operate the APs within that coverage zone.
• RF profiles are created for either the 2.4-GHz radio or 5-GHz radio.
- Profiles are applied to groups of APs belonging to an AP group, in which all APs in
the group will have the same profile settings.
- There are two components to this feature:
• RF groups
- Existing capability
- No impact on channel selection algorithms
• RF profile – New in 7.2 providing administrative control over the following:
- Minimum and maximum TPC values
- TPCv1 (or TPCv2) threshold
- Data rates
In a corporate environment, administrators are facing an ever-increasing demand for wireless

services. The network designer or administrator has to consider conflicting coverage goals and
density requirements. For example, a business may have two areas where a high number of
users will meet and congregate, such as a large conference room and presentation theater, as
well as open cubicle spaces spread across multiple floors with “normal” users. In order to
provide adequate coverage in the high-density areas, a high number of APs typically are
deployed. This generally requires manipulation of both data rates and power to raise the cell
density while managing co-channel interference. This manipulation, however, affects normal
users in directly adjacent areas, resulting in a loss of coverage. Using RF profiles and AP
groups provides a solution.
A great example of this is Hall number 4 at the recent Mobile World Congress. Within this
deployment, coverage was needed in the various auditoriums throughout the building (high
density environment) and at the same time coverage was required for the public spaces in-
between (large coverage area). In a situation like this, a global change made in the RF
environment, such as a power adjustment, may have a negative impact on interference levels in
another part of the deployment, such as the auditoriums.
RF profiles allow the administrator to tune groups of APs sharing a common coverage zone.
The administrator can change how RRM operates the APs within that coverage zone.
Administrators create RF profiles for either the 2.4- or 5-GHz radios.
Application of an RF profile does not change the assigned AP status within RRM (RF group
assignment). It is still in global mode controlled by RRM, and all APs remain part of the same
original RF group. RF profiles simply allow the administrator to define a specific set of values
that RRM uses when managing a specific group of APs. An RF profile does not make any
changes to the RRM algorithms defined on the WLC. The following conditions must be met for
RF profiles to work:
 All APs assigned must have their channel and power settings managed by RRM (global
mode).
 An AP that has a custom power setting applied for AP Power is not in global mode.
— An RF profile will have no effect on this AP.
RF profiles are applied to groups of APs belonging to an AP group, in which all APs in the
group have the same profile settings. Most installations only have a couple of different
coverage zones that will benefit from having RF profiles configured. In most cases, RRM is
doing an adequate job already.
Note Only one version of TPC can be operable for RRM on a given WLC, and version 1 and
version 2 are not interoperable within the same RF group. If you select a threshold value for
TPCv2 and it is not the chosen TPC algorithm for the RF group, the value will be ignored.
Band Select
This topic describes how Band Select optimizes performance for dual-mode capable clients.
• Automatic band steering and selection for 5 GHz-capable devices
Band Select improves predictability and performance.

Currently many devices are capable of operating in either the 2.4-GHz or the 5-GHz bands but,
due to the larger proliferation of 2.4-GHz networks, devices still prefer to attempt a connection
in the 2.4-GHz band first. Many vertical markets also utilize specialized wireless clients that
either cannot (regulatory) or will not (cost factor) be converted to use the less congested 5-GHz
band. Additionally, some clients, either by design or with poorly written drivers, will delay
until the last possible moment the process of locating a new AP to roam to and will not
consider moving bands.
The result of these behaviors is that the 2.4-GHz band is expected to stay congested for the
foreseeable future. Therefore, a solution must be found that will encourage as many devices
that are capable to use the less congested 5-GHz band.
The 2.4-GHz band is often congested and, because of the 802.11b/g limit of three non-
overlapping channels, clients on this band typically experience interference from Bluetooth
devices, microwave ovens, and cordless phones as well as co-channel interference from other
APs. To combat these sources of interference and improve overall network performance, you
can configure band selection on the WLC. Cisco Band Select enables client radios that are
capable of dual-band (that is, 2.4- and 5-GHz) operation to move to a less congested 5-GHz
AP.
Band selection works by regulating probe responses to clients, making 5-GHz channels more
attractive to clients by delaying the probe responses to clients on 2.4-GHz channels. The feature
only runs on an AP when both the 2.4-GHz and 5-GHz radios are up and running.
Enabled on a per-WLAN basis using Cisco Prime Infrastructure or directly
on the controller.
• Disabled by default
• Makes 5-GHz channels more
attractive
• Not supported on WLANs with
time-sensitive applications
• Can have a detrimental
effect on the performance
clients
You can enable Band Select globally on a WLC, or you can enable or disable Band Select for a
particular wireless LAN. This flexibility is useful because Band Select-enabled wireless LANs
do not support time-sensitive applications like voice and video due to roaming delays
introduced by delaying probe responses.
Making changes to these parameters can have detrimental effects on client roaming capabilities.
You should investigate and be aware of the probing behavior of all clients expected to associate
with the WLC, and consult the WLC help file under Wireless > Advanced > Band Select before
making adjustments to these values.
Cisco ClientLink
This topic describes how Cisco ClientLink provides network optimization in a mixed-client
environment comprised of 802.11a/g and 802.11n clients. When used, ClientLink ensures that
802.11a/g clients operate at the best possible rates.
Advanced beam forming technology
Cisco ClientLink improves wireless client predictability and performance.

Network administrators recognize the need to serve several types of clients, some of them
enjoying the benefits of 802.11n technology and others still operating at 802.11a/g speeds.
Unfortunately, they often must support these non-802.11n clients without the possibility of
upgrading any time soon. These devices with lower capabilities could effectively slow down
the general process of data transfer due to the shared media nature of the communication
throughout the cell. The network administrator must ensure that the legacy devices do not
deprive the 802.11n-capable clients of achieving an optimal performance level.
Recognizing the need for businesses to protect their investment and the investment of their end
users in 802.11a/g devices, Cisco developed a technology called ClientLink. ClientLink enables
the performance benefits of 802.11n while supporting 802.11a/g devices, thereby increasing
their useful life.
ClientLink enhances the Multiple Input Multiple Output (MIMO) antenna characteristics of
modern APs. This enhancement is realized by taking advantage of the multipath propagation of
the radio signal so as to maximize the signal-to-noise ratio (SNR) where the legacy client is
located. Improved SNR yields many benefits such as a reduced number of retries and higher
data rates. For example, a client at the edge of the cell that might previously have been capable
of receiving packets at 12 Mb/s could now receive them at 36 Mb/s. Typical measurements of
downlink performance with ClientLink show as much as 25 percent greater throughput for
802.11a/g clients. By allowing the Wi-Fi system to operate at higher data rates and with fewer
retries, ClientLink increases the overall capacity of the system, which means more efficient use
of spectrum resources.
Higher PHY Data Rates
ClientLink Disabled ClientLink Enabled
Lower Data Rates Higher Data Rates
Source: Miercom; AirMagnet/Fluke Iperf Survey
The 802.11n systems take advantage of multipath by sending multiple radio signals at the same
time. Each of these signals, called a spatial stream, is sent from its own antenna using its own
transmitter. Because there is some space between these antennas, each signal follows a slightly
different path to the receiver, a situation called spatial diversity. The receiver has multiple
antennas as well, each with its own radio that independently decodes the arriving signals, and
each signal is combined with the signals from the other receive radios. The result is that
multiple data streams are received at the same time.
The designers of 802.11n provided a mechanism that would allow a system to compute the
parameters necessary to adjust the phase of the transmitted signals based on feedback
information collected from the client in what is called explicit beam forming. The idea was to
enable much higher throughput than previous 802.11a/g systems, but to do so requires an
802.11n client to decipher the signal.
Cisco recognized the opportunity to use the other possibility, implicit beam forming, whereby
the AP does not require explicit signal measurement feedback from the client but instead
computes the weights applicable to the data stream captured by each receiving antenna on the
AP. Since the Wi-Fi channel is reciprocal, it means that transmissions between APs and clients
happen on the same frequency and use the same antennas. Therefore, the AP can use the
adjustments calculated by Maximal Ratio Combining (MRC) (referred to as weights) to
optimize the reciprocal signal transmitted back to that specific client using two transmit
antennas of the APs.
The AP stores the weights for each client and computes what is called a steering matrix for
each one. The steering matrix changes the phase of each transmitted stream towards the legacy
client so that the interference phenomenon produces a maximum SNR at the location of the
client, thus increasing the speed level at which the client can work. The result is that every
client in the cell benefits from the fact that all non-802.11n clients work at higher speeds, and
thus have a lesser impact in slowing down data transfers. Cisco ClientLink technology is
unique in that it offers uplink improvements as well as downlink communication from AP to
client. This ability is significant because the majority of daily communication on the wireless
LAN, such as web browsing, email, and file downloads, occur in the downlink direction.
Cisco CleanAir Technology
This topic describes the use of Cisco CleanAir technology, its capabilities and benefits in
detecting sources of interferences in both the 2.4-GHz and the 5-GHz bands.
BEFORE AFTER
Wireless interference decreases CleanAir mitigates RF interference
reliability and performance improving reliability and performance
Wireless Client
Performance
Microwave oven
? AIR QUALITY PERFORMANCE AIR QUALITY PERFORMANCE Microwave oven
BlueTooth
BlueTooth
• Industry’s first chip-level proactive and automatic interference protection.

• Spectrum intelligence solution designed to manage the challenges of a
shared wireless spectrum.
• Who, what, when, where, and how with interference.
• Enables the network to act upon this information.
Traditional Wi-Fi chipsets evaluate the spectrum by tracking all of the energy in the airwave
that can be attributed to their own transmissions or that can be demodulated as another 802.11
radio transmission. Any energy that remains in the spectrum that cannot be demodulated or
accounted for by transmit and receive activity is lumped into a category called noise. In reality,
a lot of the noise is actually the remnants from collisions, or Wi-Fi packets that fall below the
receive threshold for reliable demodulation. Noise can come from many sources, some of
which include microwave ovens, cordless telephones, wireless video cameras, Bluetooth and
ZigBee devices, game controllers, fluorescent lights, or outdoor wireless links such as WiMax.
To extend spectrum analysis even further, Cisco created CleanAir technology. Cisco CleanAir
is a systemwide feature of a wireless network that streamlines operations and improves wireless
performance by providing complete visibility into the wireless spectrum. The CleanAir
technology is an enterprise-based, distributed spectrum analysis technology. As such, it is
similar to Cisco Spectrum Expert in some respects, but very different in others.
Essentially, Cisco has taken the technology behind the Cisco Spectrum Expert analysis tool and
integrated it directly into the infrastructure, including deep integration within the Wi-Fi chipset
in the Cisco Aironet 3500 and 3600 Series Access Points. The heart of the CleanAir system is
the Spectral Analysis Generation Engine (SAgE), the spectrum analyzer on a chip. The chipset
is always online. SAgE scans are performed once per second. If a Wi-Fi preamble is detected, it
is passed through to the chipset directly and is not affected by the parallel SAgE hardware. No
packets are lost during SAgE scanning. SAgE is disabled while a Wi-Fi packet is processed
through the receiver. SAgE is very fast and accurate. Even in a busy environment, there is more
than enough scan time to assess the environment accurately.
1. APs detect interferer and report to WLC.
2. WLC takes immediate action to protect most affected APs.
3. WLCs work in coordination (DCA/TPC) to avoid interferer.
4. MSE calculates interferer location, zone of impact, and so on.
WLC
5. You can see interferer details and map in PI.
WLC
PI
G2 AP
MSE
G2 AP
G2 AP
802.11a
G2 AP Interferer G2 AP
G2 AP
G2 AP
Cisco CleanAir combines several elements working together to offer best-in-class protection
against the negative impact of non-802.11 interferers. As soon as an interferer is detected, the
detecting access points report the interferer to their respective controller, including elements
such as interferer pattern and detected type, affected channel, interferer detected power level,
and so on.
If APs in the neighborhood are badly affected by the interferer, the controller can take
immediate action to change the affected AP channel. At regular intervals, RRM will help
controllers working in the same RF group redesign the RF channel and power map for all APs
in the affected area to mitigate the impact of the interferer.
If your network includes an MSE, the controllers will report to the MSE all the information
collected by the APs about the interferer. The MSE will be able to combine the readings from
the various APs to determine the interferer location, zone of impact, and effect on the Wi-Fi
network.
From Cisco PI, you will be able to see the reports from the controllers, and see an Air Quality
Index (AQI) that will evaluate the impact of the interferer. With the MSE reporting to PI, you
will also be able to see all interferer locations on a given floor, along with their zone of impact,
and the location of devices affected by the interferer.
1. Identify sources of interference to be detected and those which will
trigger an alarm notification.
2. Enable globally per band.
3. Verify administratively enabled on all capable APs.
3
1
With 802.11n, wireless performance is on par with wired networks, allowing enterprises to
transition more business-critical applications such as voice and video to the wireless LAN.
Today’s Wi-Fi networks are expected to run with very high reliability. It is no longer
acceptable for Wi-Fi networks to have unexpected downtime due to interference. This is why it
is very important to be able to detect all sources of interference, including non Wi-Fi sources.
Configuring CleanAir operation consists of four steps. First you must identify the sources of
interference that will be detected and reported. Next, identify the types of interferers that will
trigger a security alarm when detected, such as a jammer or a device operating on an inverted
Wi-Fi channel. Then, enable CleanAir operation on the radio bands you wish to monitor and,
finally, verify and administratively enable CleanAir on the individual AP radios that will
monitor the RF environment. Optional but recommended configuration includes configuration
of persistent device propagation and setting a value for the AQI alarm trigger.
Persistent interferers are present at a location and interfere with the wireless LAN operations
even if they are not detectable at all times. By selecting the Persistent Device Propagation
enable check box you enable the propagation of information about persistent devices detected
by CleanAir-capable APs to any neighboring non-CleanAir-capable APs in the environment.
By selecting the Air Quality Alarm check box and entering a value between 1 and 100
(inclusive) for the Air Quality Alarm Threshold field, you specify the threshold at which you
want the air quality alarm to be triggered. When the air quality falls below the threshold level,
the alarm is triggered. A value of 1 represents the worst air quality, and 100 represents the best.
The default value is 1.
Once CleanAir has been enabled and configured within the network, information on all
detected sources of interference is available for monitoring via the PI. Although individual
WLCs will also provide information on interfering devices reported by the APs associated to
the WLCs, the result is an isolated view of the overall impact on the network that any specific
interferer is causing. However, by using PI to monitor detected sources of interference, the
administrator gains a complete networkwide view of the impact and severity of any individual
interfering device.
High Availability Solutions
This topic discusses the various methods, capabilities, and limitations of the current high
availability solutions within a unified wireless architecture.
• A well-designed
wireless network
plans for component
failures by building in
redundancy where
possible.
Access
• Create redundancy
throughout the
access layer by
homing APs into
Distribution
different switches.
Core
High availability schemes are designed to provide quick recovery from a network component
failure. Recovery is often achieved with a very limited amount of downtime or with a period of
degraded capacity, while the failed components are quickly restored to operation. Customers
require a wireless network to be designed with high availability in mind to ensure a predictable
degree of operational continuity. Services may be degraded during the downtime, but the
wireless network should remain operational while the hardware failure is being repaired.
In order to provide a highly available design, redundancy should be used whenever and
wherever possible.
• Dynamic
- Rely on CAPWAP to load balance APs across controllers and populate APs
with backup controllers.
- Results in dynamic “salt-and-pepper” design.
• Deterministic
- Administrator statically assigns to APs a primary, secondary, and/or tertiary
controller.
- Cisco recommends this as a best practice.
Dynamic Redundancy Deterministic Redundancy
Pros Easy to deploy and configure—less upfront Predictability—easier operational management
work More network stability
APs dynamically load balance (though never More flexible and powerful redundancy design options
perfectly) Faster failover times
“Fallback” option in the case of failover
Cons More intercontroller roaming More upfront planning and configuration

Bigger operational challenges due to
unpredictability
Longer failover times
No “fallback” option in the event of controller
failure
When planning for WLC redundancy, two possible options exist, which are dynamic
redundancy and deterministic redundancy. With dynamic redundancy, two WLCs are used to
support the deployed APs. In this fashion, the administrator relies on the Control and
Provisioning of Wireless Access Points (CAPWAP) joining process to balance the APs across
both available WLCs. The major drawback to this type of a solution is that the APs tend to be
deployed across the available WLCs in a salt-and-pepper configuration, which results in
unnecessary intercontroller roaming. While this may be an easier solution on the front end with
less work to set it up, in the end it more often leads to larger operational challenges due to the
unpredictability of where an AP is associated.
Additionally, a deployment such as this will experience longer failover times for APs if a WLC
failure occurs due to the requirement for the AP to attempt to contact the failed WLC as part of
the AP join process. If dynamic WLC redundancy is used, all WLCs should be located in a
central location and only Layer 2 roaming should be supported.
The recommended best practice for implementing WLC redundancy without AP Stateful
Switchover (SSO) is the implementation of deterministic WLC redundancy. To accomplish
this, some thought must be given to how APs should react in the event of a loss of their
associated WLC. Each joined AP is then provided with a prioritized list of WLCs that it should
attempt to join in the event that it loses communications with the primary WLC. By providing
this information to the AP, you gain more predictability in the network for the association of all
APs. You can prevent an AP from joining a WLC that has a different wireless LAN (WLAN)
to virtual LAN (VLAN) mapping, or that does not have access to the same VLANs or
authentication servers. Another benefit is that when configured in a deterministic manner an
AP, which has joined another WLC due to loss of contact with the primary WLC, can be
configured to rejoin the primary WLC automatically as soon as the primary WLC is again
reachable.
• Redundant WLC in a geographically
separate location
WLAN-
• Layer 3 connectivity between the AP Controller-1 APs Configured With:
connected to the primary WLC and Primary: WLAN-Controller-1
Secondary: WLAN-
the redundant WLC Controller-BKP
• Redundant WLC need not be part of WLAN-

the same mobility group NOC or Controller-2
APs Configured With:
Data Center Primary: WLAN-Controller-2
• Configure high availability to detect WLAN- Secondary: WLAN-
Controller-
failure and faster failover BKP
Controller-BKP
• Use AP priority in case of WLAN-

oversubscription of redundant WLC Controller-n
APs Configured With:
Primary: WLAN-Controller-n
• Other redundancy models: N+N, Secondary: WLAN-
Controller-BKP
N+N+1, AP SSO
• Licensing:
- With N+1, N+N, N+N+1 models, make
sure that your backup controller has
enough AP licenses left to onboard APs
from failed controller
- With AP SSO, backup controller can be
standard controller with 50 AP licenses,
or dedicated HA SKU
A single WLC at a centralized location can act as a backup for APs when they lose connectivity
with the primary WLC in the local region. You can configure primary and secondary backup
WLCs (which are used if primary, secondary, or tertiary WLCs are not specified or are not
responsive) for all APs connected to the WLC. The centralized WLC does not need to be in the
same mobility group as the regional WLCs. However, the additional WLC should be the same
model and support the same number of APs as the largest one on the network. This additional
WLC allows for one WLC to fail and no APs to be without a WLC.
There are several variations of this redundancy model. In the N+1 model, one controller is a
backup for any failed controller in the network. This model offers the lowest cost. The
downside is that only one controller can fail at any given time. At the other end of the
spectrum, the N+N model sets one backup controller for any active controller. In this model, all
controllers will be loaded to 50 percent of their AP capacity to keep room for APs from a
neighboring controller in case of failure. This model offers the best redundancy mechanism, but
represents also the highest capital expense. Most networks implement a hybrid model, called
N+N+1, where each controller is loaded to a percentage of its AP capacity, higher than 50
percent but lower than 100 percent. When a controller fails, its APs can be split across several
secondary controllers, each secondary controller onboarding part of the APs of the failed
controller. The number of controllers that can be allowed to fail in this scenario relates to the
load level of each controller.
With controller code 7.3 and later, you can also configure AP SSO for a controller. With this
deployment model, a controller is used as a backup for an active controller. The backup
controller can be a standard controller (50 AP licensers are needed on that backup controller to
activate the backup function), configured as a backup. You can also use a dedicated HA SKU.
The backup controller does not play any active role in the network while the primary controller
is functioning. The backup assumes the active role if the primary controller fails.
• Backup WLCs and enhanced timers can be configured for all APs on a
given controller
Wireless >
Access Points >
Global Configuration
Wireless >
Access Points >
Edit Access Point >
Advanced
To enhance the AP failover process, in addition to the option to configure primary, secondary,
and tertiary controllers on the AP side, a configuration on the controller itself is possible. This
will set up primary and secondary backup controllers.
If there are no primary, secondary, or tertiary controllers configured on the AP side and a
primary backup controller or secondary backup controller is configured on the controller side
(downloaded to the AP), the primary backup controller or secondary backup controller, or both,
are added to the primary discovery request message recipient list of the AP.
Another way to enhance AP failover is to speed up the time taken by an AP to realize that its
primary controller failed, and to maintain an accurate list of possible backups. To reduce the
controller failure detection time, new heartbeats are added between the controller and AP with
smaller timeout values. Rather than one keepalive message being exchanged every 30 seconds,
messages can be sent down each second if needed.
• 1:1 wireless stateful failover • One WLC in active state and
capability in appliance and second WLC in hot standby state
integrated controllers that monitors the health of the
• SSID is always beaconing (even active WLC.
after primary controller is down)
• Configuration on active is
• Subsecond WLAN network synched to standby WLC via
convergence redundant port.
• HA SKU (for example, AIR-
CT5508-HA-K9) • Both the WLCs share the same
set of configurations including the
5500, WiSM2, 7500, 8500 Series IP address of the management
L2 Redundant Link
interface.
• AP’s CAPWAP state (only APs
which are in run state) is also
Active WLC Hot-Standby WLC synched.
Separate SKU Orderable

• APs do not go in discovery state
without AP Licensing when active WLC fails.
Before the release of the 7.3 WLC code, all WLCs had to be in the same mobility domain for
the primary/secondary/tertiary concept to work. The primary/secondary/tertiary WLCs had to
be defined on each AP, and each WLC had to be configured separately with its own unique IP
address. This resulted in each of the WLCs being monitored and managed separately by PI.
When an AP detected the loss of connectivity to the WLC, the AP returned to the discovery
state and restarted the CAPWAP join process. This meant that the downtime between failover
could be as much as 1.5 minutes, depending on the number of APs attempting to join a new
WLC.
With the release of the 7.3 WLC code, one-to-one WLC high availability with AP SSO became
available. When configured for SSO operation, one WLC is in the active state and the second
WLC is in a hot standby state monitoring the health of the active WLC.
The configuration on the active WLC is synched to the standby WLC via a physical
redundancy port (RP). This direct Layer 2 cable connection allows both of the WLCs to share
the same set of configurations including the IP address of the management interface.
In addition to the WLC configuration, the CAPWAP state of all APs in the run state is also
synchronized between the active and standby WLCs. The result is that the APs do not go into
the CAPWAP discovery state when the active WLC fails. It reduces the AP downtime between
failover to between 5 and 996 milliseconds in the event of a WLC failure or up to 3 seconds in
the case of network issues.
The 7.4 version of the WLC code introduced the ability to utilize an HA-SKU WLC as a
secondary WLC without AP SSO or one-to-one high availability capabilities. This allows the
HA-SKU WLC to be configured as a secondary WLC in support of a single WLC or multiple
primary WLCs without additional licensing in an N+ 1 configuration. You can still use a
standard controller as the backup controller, but that standard controller needs to have at least
50 licenses to be configurable as a backup controller.
Summary
• Cisco RRM is used to efficiently overcome the various challenges

inherently faced in an 802.11 deployment. It is like having an RF
engineer in the box who constantly monitors the RF demands and
optimizes the radio operations in real time.
• Cisco ClientLink technology uses the reciprocal nature of the Wi-Fi
channel to implement implicit beam forming by using information
obtained from the received signal to adjust the transmitted signal and
improving the SNR of individual clients.
• Band Select enables client radios that are capable of dual-band (2.4 and
5 GHz) operation to move to a less congested 5 GHz access point.
• Cisco CleanAir is a systemwide feature that streamlines operations and
improves wireless performance by providing complete visibility into the
wireless spectrum.
• The Cisco Unified Network architecture can be deployed using controller
redundancy to provide quick recovery from a network component failure.
Lesson 3
Wireless Network Security

Overview
Once basic wireless network operations are established, the next concern is to ensure that
network access is secure. This means that the right user should access the right resources, and
that data transiting through the network is protected against eavesdropping. Providing secure
network access can be especially challenging for wireless networks.
This security goal may be especially challenging in a wireless network where multiple users
share the same RF space, even with different Service Set Identifiers (SSIDs). This lesson will
suggest possible ways to ensure security of the wireless network.
Objectives
Upon completing this lesson and given a specific customer scenario and a wireless LAN with
basic functionality enabled, you will be able to describe and enable the key elements that are
needed for network security. You will be able to meet these objectives:
 Describe and enable traffic segmentation
 Describe and enable Cisco Prime Infrastructure (PI) and Cisco Identity Services Engine
(ISE) integration for security monitoring and management
 Describe how Cisco Adaptive Wireless Intrusion Prevention System (wIPS) is used to
expand security monitoring
Traffic Segmentation Needs and Methods
This topic describes the various methods for segmenting user traffic for security purposes.
Branch
ISE PI
Wan
Core WLC in DMZ
WLC
AP3600
WLC
Voice User
SSID Employees
WLC
SSID Voice Employee
Guest
Channel utilization
SSID Guests
• Segment by SSID to isolate traffic and user types.

• Limit the number of SSIDs to the minimum to avoid overheating.
• Each SSID uses encryption and different authentication.
8 SSIDs 2 SSIDs
The way wireless networks are used has changed dramatically over the last few years. Modern
networks need to connect a wide variety of devices. Some devices belong to corporate users
who need to access the network resources anytime, from anywhere, and with any device. Some
other devices belong to guests. Knowing which user accesses the network, from which location,
and with what device are key concerns for wireless network administrators.
In networks where both employees and the general public (guests) use the same wireless space,
isolation is usually needed. Guests or the general public should not be allowed to access the
resources that are used by employees. These guests should also not be allowed to view data that
is sent and received by employees through the wired or the wireless network. Ideally, the
implementation of a wireless guest network uses as much of an existing wireless and wired
enterprise infrastructure as possible. This avoids the cost and complexity of building a physical
overlay network.
In most cases, isolation can be performed on the wireless space by using different wireless
LANs (WLANs). Common isolation techniques include the following:
 Segmentation by user or device type: In this model, a separate WLAN is created for each
type of user. This isolation can be done for guest or general public traffic isolation from
corporate users, but can also be extended to the corporate users to create one WLAN for
each category (for example, marketing, sales, and so on). When specialized devices are
used (for example, portable electronic medical records [EMR] devices), WLANs can be
created to isolate each device type.
 Segmentation by application type: Corporate wired networks are often divided into
virtual LANs (VLANs), based on applications. In this environment, each VLAN is
dedicated to a specific application or group of applications. A common practice is to
separate voice and data applications and guest access to the Internet into their own VLANs.
This logic can be extended to the wireless space, where a WLAN will be assigned to each
type of application. However, one limitation of this model is that different WLANs may
still share the same RF space. Isolation may be achieved if WLANs use encryption (so that
users on one WLAN cannot capture and read traffic from another WLAN), but this
isolation does not reduce congestion if both WLANs are on the same access point (AP) and
the same band.
 Segmentation by security type: When a wireless client connects to an SSID, the client
must match the WLAN security settings. If the WLAN advertises Wi-Fi Protected Access 2
(WPA 2)-Enterprise and Advanced Encryption Standard (AES) encryption, then the client
must use WPA2-Enterprise and AES encryption. A common practice is to use Webauth for
guest users, and one or several WLANs with Layer 2 authentication for corporate users.
Each WLAN can be linked to a specific VLAN, thus ensuring that less-secure wireless
devices are not allowed access to sensitive or restricted network resources.
However, SSID segregation also presents severe limitations, which include the following:
 A Cisco wireless LAN controller (WLC) supports up to 16 SSIDs per AP. The design must
make sure that no more than 16 SSIDs are deployed per AP.
 Each SSID requires its own beacon, sent at the lowest mandatory rate. In a dense AP
environment, each additional SSID and its associated management frame overhead may
increase each channel utilization by 3 to 7 percent. The figure shows the channel utilization
in an example dense AP deployment with 8 SSIDs, and then the same channel utilization
when the SSID number is lowered to 2.
 For RF efficiency, it is necessary to limit the number of SSIDs to the strict minimum, for
example, one SSID for guests, one for VoIP devices, and one SSID for employees.
Branch
ISE PI
Wan
Core WLC in DMZ
WLC
AP3600
WLC
SSID Employees Voice VLAN, QoS, and ACL

WLC
SSID Voice Employee VLAN, QoS, and ACL
Guest VLAN, QoS, and ACL
SSID Guests
• Each category of user or device is dynamically sent to a specific VLAN/dynamic

interface.
• Specific ACLs and QoS rules are also sent to filter and control network access.
When using central authentication with ISE, you can leverage the flexibility of ISE to
dynamically send VLAN information (in the form of VLAN tag or dynamic interface name),
access control lists (ACLs), or quality of service (QoS) profiles specific to each authenticated
user and device. On the WLC, you would check the authentication, authorization, and
accounting (AAA) Override check box in the Advanced tab of the WLAN configuration
section. This will allow the ISE to return values that would be different from the WLAN
defaults.
This method allows you to send specific users to specific VLANs, with a specific QoS profile
and specific traffic filter ACL, regardless of which WLAN they use to connect.
Note QoS override is supported on WLC code 7.5 and later.
Identity-based networks (IBNs), also called Secure Access Control, provide a convenient way
to distribute ACLs based on user identification. This way, two users in the same WLAN and
sent to the same VLAN may receive different sets of ACLs. IBN ACLs are distributed to the
user along with the VLAN and other user profile details at the end of the IEEE 802.1X
authentication phase. With a Cisco WLC and Cisco ISE acting as a RADIUS server, several
subtypes of ACLs can be distributed. These include the following:
 Filter-ID ACLs: Sometimes called Airespace ACLs, these ACLs are configured on the
WLC. During the 802.1X authentication phase, the RADIUS server returns the name of the
ACL to the WLC. If the name string matches the name of an ACL configured on the WLC,
the WLC applies this ACL to the user. If the ACL is not found on the WLC, the 802.1X
authentication fails.
 Downloadable ACLs: The ACL can be configured on the WLC or on the RADIUS server.
During the 802.1X authentication phase, the RADIUS server returns the name of the ACL
to the WLC. If the name string matches the name of an ACL configured on the WLC, the
WLC applies this ACL to the user. If the ACL is not found on the WLC, the RADIUS can
send the ACL content to the WLC.
 Redirect ACL: This type of ACL is used for Webauth type of WLAN during onboarding
or web authentication. This type of ACL is used to redirect the user to another IP address,
usually a web server, where authentication will occur (when the ACL is returned before
authentication), or to a web server.
Note that ACLs sent from ISE always override the general ACL defined on the WLC.
Therefore, if an ACL is sent from the ISE to be applied to a user, this user will be limited by
this ACL. However, the user is not limited by an ACL that would be defined in the WLC at the
wireless LAN level or at the dynamic interface level.
When AAA override is used for ACLs, how several ACLs combine and result into a specific
access profile for the user must be clearly understood. ACLs can be configured and set directly
on the WLC. ACLs configured on the WLC are not stateful, and the traffic direction must be
specified in most WLC ACL rules. Once configured, a WLC ACL can be positioned on a
dynamic interface to which a WLAN is mapped. In that case, it affects all users sent to this
interface regardless of their WLAN. Alternatively, a WLC can be positioned on a WLAN. In
that case, it affects all users of that WLAN, regardless of the interface to which each user is
sent.
Note When both a WLAN and an interface ACL are implemented, the WLAN ACL overrides the
interface ACL.
For guest WLANs using Webauth, two types of ACLs can be implemented:
 Preauthentication ACLs are applied to users after open authentication and association, and
DHCP address assignment, but before web authentication. This type of ACL is commonly
used to prevent attacks such as domain name server (DNS) or DHCP poisoning.
 Postauthentication ACLs are applied to users after web authentication is completed. This
type of ACL is commonly used to restrict the extent or resources that guest users can
access.
Both types of ACLs are returned to WLC for user authenticating using
RADIUS.
Airespace ACL:
• ACL is configured on controller, ISE sends the ACL name.
• If WLC finds an ACL with that name in its configuration, WLC accepts the
authentication and applies the ACL.
• If WLC does not find an ACL with that name in its configuration, user authentication
fails.
• Works on CUWN and CA controllers, with ACS and ISE.
Downloadable ACL:
• ACL does not need to be configured on WLC, ISE sends the ACL name and version
number.
• If WLC finds an ACL with that name in its configuration (not because it was
configured on the WLC, but because it was previously obtained from the RADIUS
server with the same version), WLC accepts the authentication and applies the ACL.
• WLC does not find an ACL with that name or that version in its configuration, WLC
queries the RADIUS server for the ACL content, then accepts the authentication and
applies the ACL.
• Works on CA controllers, not on CUWN controllers.
Downloadable ACLs are more complex than Filter-ID (or Airespace) ACLs. With Filter-ID
ACLs, authentication fails if the ACL is not found on the WLC. The RADIUS server only
returns an ASCII string, which is the name of the ACL. With downloadable ACLs, you can
configure the ACL on the WLC or just on the RADIUS server. The exchange between the
WLC and the RADIUS server occurs as follows:
1. The wireless client first requests 802.11 authentication and association. The wireless LAN
uses open authentication.
2. The WLC grants association.

3. Extensible Authentication Protocol over LAN (EAPOL) starts, and the WLC authentication
manager component initiates the 802.1X authentication to relay the client Extensible
Authentication Protocol (EAP) queries to the AAA server.
4. Upon successful 802.1X/EAP authentication, the RADIUS server returns an authentication
success message, along with the client profile information. This profile information
contains the name of the ACL that should be applied to the client, along with a version
number for this ACL.
5. The WLC then looks in its cache to check if an ACL with the same name and the same
version exists. If you configured the ACL on the WLC but this client is the first client
receiving the ACL from the AAA server, then the ACL exists, but not the version number.
If another client previously received the same ACL from the RADIUS server, then the
WLC cache has both the ACL and the version number. The version number changes only
when the administrator modifies the ACL content on the AAA server. If the WLC finds the
ACL in its cache with the correct version number, the WLC applies the ACL to the user. If
you did not configure the ACL on the WLC and no client received the ACL from the AAA
server recently, then the ACL is not found.
6. When the ACL is not found in the WLC cache, the ACL is found but not with the correct
version number, or without any version number, the WLC queries the AAA server. The
AAA server then returns the content of the ACL. The ACL is applied to the client and is set
into the WLC cache.
One Network—Cisco Prime Infrastructure and ISE
Integration
This topic describes how ISE and PI can be used together to deploy security profiles for
wireless users.
Branch
ISE PI
Wan
Core
WLC in DMZ
WLC
AP3600
WLC
SSID Employees Voice VLAN and ACL

WLC
SSID Voice Employee VLAN and ACL
Guest VLAN and ACL
SSID Guests
• Prime Infrastructure is used to deploy dynamic interfaces, ACLs, and

QoS rules to WLCs.
• ISE tells WLCs which interface, ACL, and QoS rule to use for each user.
When configuring per-user VLANs, ACL, QoS profile assignment, and PI work together.
First, you can use Cisco Prime Infrastructure to create and deploy policies. When you allocate a
user to a specific VLAN, dynamic interface, Airespace ACL, or QoS profile, the element must
exist on the WLC. Using PI, you can create all of the interfaces, ACLs, and QoS profiles that
will be needed and deploy them to the WLCs. They do not need to be assigned to a specific
WLAN, but must exist on the WLC that will assign them to specific users.
Next, when the user authenticates, the WLC relays the authentication query to ISE. With the
EAP Success message, ISE also returns a profile for the user that includes the dynamic
interface name, VLAN tag, ACL name, and/or QoS profile name that must be assigned to this
user. The WLC then looks into its configuration to find the name that was returned and applies
the associated parameter to the user.
Notice that if the WLC does not find in its configuration the name of the value that is returned
by ISE, the authentication fails, and the user is denied access to the network. The only
exception is the downloadable ACL. For this element, if the WLC does not find the ACL name
in its configuration, a second query is sent to ISE to provide the ACL content.
Adaptive wIPS
This topic describes how Adaptive wIPS may be used to better identify and mitigate wireless
threats.
• Controller-integrated IDS engine:

- Detects rogues
- Detects common attack signatures
• Adaptive wIPS on MSE adds:
- Reduction in false positives (for example, APs containing rogues on one
WLC are not seen as attackers on another WLC)
- Alarm aggregation (avoids alarm duplicates)
- Enhanced detection of denial of service (DoS) attacks (finer analysis of
attack behaviors)
- Forensics (captures attack frames)
- Coordinated rogue containment
- Anomaly detection
Identifying and controlling the access of wireless users is fundamental to network security.
Establishing a strong wireless policy is also critical to establish clear rules. However, it is still
very possible that malicious users may attempt to tap into wireless communications, or to attack
the network itself. In an environment where wireless is used for critical application, such a
threat must be identified and mitigated.
The WLC-based wireless intrusion detection system (wIDS) is efficient for detecting rogues,
but also for detecting common attack signatures. The embedded wIDS system can be enhanced
by deploying the centralized Cisco Adaptive wIPS. Cisco wIPS relies on the Cisco Mobility
Services Engine (MSE) and PI to centralize the definition, deployment, and alarm consolidation
for attacks that should be monitored. wIPS is integrated into the unified wireless infrastructure
and provides wireless-specific network threat detection and mitigation against malicious
attacks, security vulnerabilities, and sources of performance disruption. wIPS can detect,
analyze, and identify wireless threats, and centrally manages mitigation and resolution of
security and performance issues.
The differences between WLC-based IDS and Adaptive wIPS are as follows:
 Reduction in false positives: The wIPS feature facilitates a reduction in false positives
with respect to security monitoring of the wireless network. In contrast to the WLC-based
solution, which triggers an alarm when it detects a number of management frames over the
air, wIPS only triggers an alarm when it detects a number of management frames over the
air that are causing damage to the wireless infrastructure network. This is a result of the
wIPS feature being able to dynamically identify the state and validity of APs and clients
present in the wireless network. Only when attacks are launched against the infrastructure
are alarms raised.
 Alarm aggregation: The wIPS system is able to correlate unique attacks seen over the air
and aggregate them into a single alarm. This is accomplished by wIPS automatically
assigning a unique hash key to each particular attack the first time it is identified. If the
attack is received by multiple wIPS-enabled APs, it will only be forwarded to Cisco Prime
Infrastructure once because alarm aggregation takes place on the MSE.
 Enhanced detection of denial of service (DoS) attacks: A DoS attack involves
mechanisms that are designed to prohibit or slow successful communication within a
wireless network. The attacks often incorporate a number of spoofed frames that are
designed to drop or falter legitimate connections within the network. wIPS has more
signatures available for detecting DoS attacks.
 Forensics: The adaptive wIPS feature provides the ability to capture attack forensics for
further investigation and troubleshooting purposes. At a base level, the forensics capability
is a toggle-based packet capture facility that logs and retrieves a set of wireless frames.
This feature is enabled on a per-attack basis within a wIPS profile that is configured on PI.
Once enabled, the forensics feature is triggered when a specific attack alarm is seen over
the airwaves. The forensic file created is based on the packets contained within the buffer
of the wIPS monitor mode AP that triggered the original alarm. The file is transferred to the
WLC via Control and Provisioning of Wireless Access Points (CAPWAP), which then
forwards the forensic file via Network Mobility Service Protocol (NMSP) to wIPS running
on the MSE. The file is stored within the forensic archive on the MSE until the customer-
configured disk space limit for forensics is reached. By default, this limit is 20 gigabytes,
which when reached, causes the oldest forensic files to be removed. Access to the forensic
file is obtained by using PI to open the alarm that contains a hyperlink to the forensic file.
The files are stored in a .CAP file format, which is accessed by WildPacket Omnipeek,
AirMagnet WiFi Analyzer, Wireshark, or any other packet capture program that supports
this format.
 Rogue detection: An AP in wIPS-optimized monitor mode performs rogue threat
assessment and mitigation using the same logic as current unified wireless
implementations. This allows a wIPS mode AP to scan, detect, and contain rogue APs and
ad-hoc networks. Once discovered, this information regarding rogue wireless devices is
reported to PI where rogue alarm aggregation takes place.
Note If a containment attack is launched using a wIPS mode AP, its ability to perform methodical
attack-focused channel scanning is interrupted for the duration of the containment.
 Anomaly detection: wIPS includes specific alarms pertaining to anomalies in attack

patterns or device characteristics captured. The anomaly detection system takes into
account the historic attack log and device history contained within the MSE to baseline the
typical characteristics of the wireless network. The anomaly detection engine is triggered
when events or attacks on the system undergo a measurable change as compared to
historical data kept on the MSE. For example, if the system regularly captures a few MAC
spoofing events each day, and then on another day MAC spoofing events are up 200
percent, an anomaly alarm is triggered on MSE. This alarm is then sent to PI to inform the
administrator that something else is going on in the wireless network beyond traditional
attacks that the system may encounter. The anomaly detection alarm also can be employed
to detect day-zero attacks that might not have a preexisting signature in the wIPS system.
SNMP Trap
MSE
Integrated PI
SOAP/XML
NMSP
• wIPS enabled APs on same
WLCs as standard APs WLAN Controller
CAPWAP CAPWAP CAPWAP
Local Mode wIPS Monitor ELM AP

AP Mode AP
PI MSE PI MSE
Overlay
• APs and WLCs dedicated to WLAN Controller WLAN Controller
wIPS function RF Group Name = RF Group Name
WIPS = WIPS
Local Mode Local Mode wIPS Monitor wIPS Monitor

AP AP Mode AP Mode AP
Adaptive wIPS uses APs set to monitor mode, with a specific submode dedicated to wIPS. In
this case, the AP does not service clients but is dedicated to attack monitoring. The AP can also
be set to local mode, and to a wIPS sub-mode. This mode is called Enhanced Local Mode
(ELM). In this case, the AP can still service clients and also perform wIPS functions. However,
APs in ELM mode can perform wIPS functions only on the main channel they service. APs in
wIPS mode (monitor mode with wIPS sub-mode) can perform wIPS functions on all channels.
Adaptive wIPS can be deployed in two ways, as an integrated solution or as an overlay
solution. An integrated wIPS deployment is a system design in which local mode and wIPS
monitor mode or ELM APs are intermixed on the same WLC and managed by the same Cisco
PI. This setup is the recommended configuration, as it allows the tightest integration between
the client-serving and monitoring infrastructures. In fact, many of the components, including
WLCs and PI, are dual-purpose, which reduces duplicate infrastructure costs.
In a wIPS overlay deployment, the wIPS monitoring infrastructure is completely separate from
the client-serving infrastructure. Each distinct system has its own set of WLCs, APs, MSE, and
PI. The reasons for selecting this deployment model often stem from business mandates that
require distinct network infrastructure and security infrastructure systems with separate
management consoles. This deployment model could also be used if the total number of APs
(wIPS and local mode) exceeds the 15,000 AP limit for PI.
In order to configure the wIPS overlay monitoring network to provide security assessment of
the client-serving infrastructure, specific configuration items must be completed. The wIPS
system operates on the idea that only attacks against trusted devices should be logged. In order
for an overlay system to view a separate unified wireless infrastructure as trusted, the WLCs
must be in the same RF group.
There are several considerations that must be remembered after separating the client-serving
infrastructure from the wIPS monitoring overlay infrastructure. These include the following:
 wIPS alarms will be shown only on the wIPS overlay PI instance.
 Management frame protection (MFP) alarms will be shown only on the client infrastructure
PI instance.
 Rogue alarms will be shown on both PI instances.
 Rogue location accuracy will be greater on the client-serving infrastructure PI, because this
deployment will use a greater density of APs than the wIPS overlay.
 Over-the-air rogue mitigation will be more scalable in an integrated model, as the local
mode APs can be used in mitigation actions.
 The security monitoring dashboard will be incomplete on both PI instances because some
events, such as wIPS, will only exist on the wIPS overlay PI. To truly monitor the
comprehensive security of the wireless network, both security dashboard instances must be
observed.
One consideration of the overlay solution is the possibility of APs on either the client-serving
infrastructure or wIPS monitoring overlay associating to the wrong WLC. This situation can be
prevented by specifying the primary, secondary, and tertiary WLC names on each AP (both
local and wIPS mode). In addition, it is recommended that the WLCs for each solution have
separate management VLANs for communication with their respective APs, and that ACLs are
used to prevent CAPWAP traffic from crossing these VLAN boundaries.
Summary
• Traffic can be segmented based on application, user type, SSID, device

type, or user credentials. In most cases, you want to use SSID
segmentation while limiting the number of SSIDs to a minimum.
• Cisco Prime Infrastructure and ISE can work together to deploy and
apply security policies to wireless users.
• Adaptive wIPS provides a deep attack detection and mitigation
mechanism.
References
For additional information, refer to these resources:
 Cisco Prime Infrastructure Configuration Guide v2.0 on wireless LAN and interface
templates, ISE interaction, ACL configuration, and wIPS, when available.
Lesson 4
Wireless Network QoS

Overview
Traffic isolation is not enough to provide optimal service to wireless users. You also have to
ensure that bandwidth consumption for each device and application matches the design
requirements. A non-critical application should not prevent a critical application from accessing
the bandwidth needed. A way to ensure this bandwidth allocation, and prioritize traffic in times
of congestion, is to implement a quality of service (QoS) policy.
QoS is different in the wireless space than it is on a wired cable. This lesson will show you
where QoS is implemented in a campus deployment of a wireless network. This lesson will also
describe the different families of QoS mechanisms used in the wireless space, with the IEEE
802.11e protocol, the Wi-Fi multimedia specification, and the various unified wireless metal
QoS profile types.
Objectives
Upon completing this lesson and given a specific customer scenario and a wireless LAN, you
will be able to enable wireless QoS policies. You will be able to meet these objectives:
 Describe where and when QoS policies are applied
 Describe the four standard metal QoS profile types
 Describe the four Alloy QoS profile types and the other mechanisms used to control traffic
flow through a wireless cell
Where and When QoS Is Applied
This topic describes where and when QoS is applied, both in the wired and the wireless spaces.
QoS technologies consist of tools and techniques used to manage network resources and are
considered the key enabling technology for network convergence. The objective of QoS
technologies is to make voice, video, and data convergence appear transparent to end users.
QoS technologies allow different types of traffic to contend inequitably for network resources.
Network devices can grant priority or preferential services to voice, video, and critical data
applications so that the quality of these strategic applications does not degrade to the point of
being unusable. Therefore, QoS is a critical, intrinsic element for successful network
convergence.
QoS relies on three types of actions:
 The first action is to identify the traffic on the network and determine QoS requirements for
the traffic. This is done by classifying traffic through packet inspection and marking each
packet with an identifier (numeric value or tag) reflecting a traffic category.
 The second action is to create prioritization and bandwidth allocation policies at key
locations in the network. When congestion occurs, these policies will determine which
traffic should be sent first and which type of traffic may be dropped. This determination is
usually based on the traffic marking as defined in the first action. This second action is
often referred to as queuing and scheduling. In certain instances, traffic may be granted a
strict bandwidth allocation where any extra traffic is dropped (this is called policing).
Traffic may also be given a strict bandwidth allocation where a portion of extra traffic is
buffered and sent later if bandwidth becomes available (this is called shaping).
 The third action is to prevent congestion. This action is often referred to as congestion
avoidance. Several techniques can be used to achieve this goal. One is to reduce the size of
each frame by compressing the frame header (this technique is only possible on point-to-
point links). Another technique disassembles large frames and interleaves the smaller and
possibly more urgent frames (this is called fragmentation and interleaving). This technique
offers a way to reduce the delay needed to send frames of high priority. Another technique
is to admit only a limited number of flows in the network. The technique is well suited for
flows that have a predictable bandwidth consumption, and is called Admission Control or,
when discussing voice, Call Admission Control (CAC).
Each QoS feature has its own purpose and fits into a global QoS strategy.
• Different types of traffic have different characteristics and needs. The
following are examples:
- Interactive video (bursty, bandwidth intensive, latency intolerant)
- Streaming video (bursty, bandwidth intensive, latency tolerant)
- Voice (consistent flow, low bandwidth consumption, latency intolerant)
Congestion in wireless cells presents slightly different challenges than on a wired network. You
can configure several Service Set Identifiers (SSIDs) for the same access points (APs).
Regardless of the number of configured SSIDs, the AP has either one or two radios. This
physical limitation means that wireless clients that seem to be isolated in different SSIDs might
still have to share the same RF space. In this shared environment, clients do not have any
awareness of each other’s traffic requirements. Clients can detect that some other stations are
sending in the cell, but they cannot analyze each other’s bandwidth needs. They compete to
gain access to the wireless medium on a per-packet basis. As clients share the same RF
environment, collisions are likely to occur, and you need first a mechanism to manage these
collisions.
Depending on their position in the cell, clients can get up to 54 Mb/s in a classical 802.11a/g
network and up to 300 Mb/s in an 802.11n network. These values have to be understood as “per
radio.” In either case, the available bandwidth in the wireless space is different from the
available bandwidth on the wired link through which the AP connects to the enterprise switch.
Congestion has to be managed to ensure that traffic coming from either side will not be
dropped because of congestion issues. The same phenomenon occurs when traffic coming from
many APs is sent to one WLC. To take an extreme example, a Cisco 5500 Series Wireless LAN
Controller (WLC) with an 8-Gb/s link to the switch can manage up to 1000 802.11n APs with
two radios each. Congestion can occur at the WLC port level.
Although congestion on the wired side of the network is an issue, the main focus of this section
is congestion in the wireless cell itself, and between the controller and the AP. Packets coming
from wireless clients need to be sent first to the AP before being forwarded to another wireless
client of the wired network. The bandwidth available in the wireless cell usually dictates the AP
bandwidth consumption on the wired side. An AP offering 24 Mb/s on the wireless side will
usually consume the same bandwidth on the wired side simply because the link of lowest
bandwidth, in this case the wireless space, dictates the overall bandwidth consumption
throughout the whole link.
These requirements imply that an efficient QoS policy must be put in place for any network
that uses the Wi-Fi network for mission critical traffic. It would not be acceptable, for example,
to let guest video traffic prevent mission-critical data from reaching the database.
Therefore, your first task is to examine the traffic expected to share the wireless space and to
classify this traffic into several categories. You will then assign a priority level and a criticality
level to each category. There are many ways to classify traffic. A common way is to identify
traffic types and then assign the corresponding QoS policies. You can do this by distinguishing
five general classes and examining the QoS requirements for each of them, including the
following:
 VoIP over Wi-Fi: This traffic bandwidth consumption is predictable. A typical call will
send a consistent number of packets per second, and will receive the same amount (for
example, 50 packets of 160 bytes each per second). Therefore, VoIP usually does not need
high bandwidth. However, VoIP packets cannot be delayed during transmission as
excessive delays result in clicks in the call or even in silences. Delay must be low and must
be consistent. Variation in the delay is called jitter and high jitter degrades the user
experience. VoIP should be given a high priority level.
 Video: You can distinguish two types of video flows. One flow is for real-time video, also
called interactive video (for example, video conferences). Another type of video is
streaming video. Video bandwidth consumption is variable and depends on the codec
(coding system chosen to represent each image and each change from one image to the
next). A major difference between these two types of video traffic is in the latency
tolerance. Interactive video is real-time, and therefore is not tolerant to high latency. A
common tradeoff to lower latency is that lower video quality is often acceptable. Streaming
video can be buffered in the receiving device, and therefore is more tolerant to high
latency.
 Web browsing: This type of traffic also includes emails and all other non-time sensitive
and non-critical traffic. This traffic would receive the lower priority classification.
 Scavenger traffic: This category groups all other, non-mission-critical data, such as peer-
to-peer traffic.
802.11e Metal Profiles
This topic describes 802.11e Wireless Multimedia (WMM), and the standard metal profile
implementation derived from 802.11e and WMM access categories.
• 802.11e has four Access Categories (AC), each having two Traffic
Categories (TC) or User Priorities (UP)
- WMM is Wi-Fi Alliance certification for partial implementation of 802.11e
- WMM is needed for 802.11n and 802.11ac rates
• You also need Open/Open or WPA2/AES security for 802.11n/ac
Priority 802.1p Priority 802.11e Designation Access Category Designation

Highest 7 NC
AC_VO Voice
6 VO
5 VI
AC_VI Video
4 CL
3 EE
AC_BE Best Effort
0 BE
2 -
AC_BK Background
Lowest 1 BK
To classify the priority level of each expected traffic type, you need to understand and use the
QoS classification and prioritization system available for wireless networks. Wireless QoS as
defined by the IEEE Task Group E was ratified late in 2005 through the 802.11e amendment
and integrated in the later versions of the standard (802.11-2007 and later). Although 802.11e
defines two modes of operation, Enhanced Distribution Coordinate Access (EDCA) and Hybrid
Controlled Channel Access (HCCA), only the EDCA has seen widespread adoption. EDCA is
the subset of operation upon which the Wi-Fi Alliance based WMM.
Notice that later protocols are built upon 802.11e. This means, for example, that WMM support
is needed for 802.11n (802.11n was ratified in 2009) or 802.11ac. Without WMM you cannot
achieve any 802.11n or 802.11ac data rate.
WMM is a set of features that are designed to improve the performance of voice, video, and
data applications that are used on Wi-Fi networks. It functions by placing the eight user priority
(UP) levels that are defined by 802.11e into four access categories (AC) that correspond to the
different traffic types:
 Voice: Highest priority traffic
 Video: Second highest priority
 Best effort: Third highest priority, mainly applications such as email or web browsers
 Background: Lowest priority, where non latency-sensitive applications reside
Each UP corresponds to a priority level defined by the 802.1p protocol, which was built to
define priority levels for wired traffic. 802.11e and WMM create a wireless equivalent to
802.1p wired priority levels (although the medium access techniques are notably different). By
prioritizing traffic streams based on the data type and application requirements, WMM helps
ensure that low priority network traffic does not degrade the performance of other highly
sensitive applications such as voice.
• Each metal level provides a single static QoS value for all traffic,
multicast as well as unicast.
- All devices on the WLAN are assumed to be of the same traffic type.
• Applications requiring different QoS treatment are assumed to be on
different WLANs.
• An 802.1p is applied to the wired side to allow proper precedence to be
applied to traffic across the entire network infrastructure.
Although the four WMM access categories bear names that match their intended usage (voice,
video, and so on), you may have good reasons to put some other type of traffic in one of these
categories. For example, you may choose to put low-latency, mission-critical traffic in the
voice or video queue, even if this traffic is not voice or video related. To simplify the queue
identification, the 802.11e and the WMM certification also designate the four access categories
with metal names (the more precious metals are expected to receive higher priority). Using a
metal name instead of a traffic type allows you to assign the traffic to the category that best
matches the traffic priority requirement, without worrying about the traffic type:
 Voice (AC_VO), with UP 6 and 7, is also called Platinum.
 Video (AC_VI), with UP 4 and 5, is also called Gold.
 Best Effort (AC_BE), with UP 3 and 0, is also called Silver.
 Background (AC-BK), with UP 1 and 2, is also called Bronze.
In most wireless implementations, including Cisco Unified Wireless Networking (CUWN)
version 7.1 and older, you can configure the four access categories (or rather metal types) with
an expected 802.11e default UP (that will be translated into the Cisco Architecture for Voice,
Video, and Integrated Data [AVVID] 802.1p value when transmitted between the AP and the
WLC1). You can then assign a metal profile to a wireless LAN. This metal profile determines
the highest QoS level expected for that wireless LAN.
Under the four fixed levels of deployments—platinum, gold, silver, and bronze—each metal
level provides a single static QoS value for all traffic, multicast as well as unicast. All devices
on the wireless LAN are assumed to be of the same traffic type. Applications requiring
different QoS treatment are assumed to be on different wireless LANs.
1
This is the meaning of the numbers circled in the figure. For example, the Platinum profile 802.1p value of 6 means
that when a frame is received with a UP of 6, this frame should be transmitted to the WLC with the 802.1p AVVID tag
matching 802.11 UP 6 in the AVVID table. The packet will display an 802.1p value of 5 (as per the AVVID table)
when forwarded between the AP and the WLC.
• IEEE determined standard L2 to L3 mapping and marking usage
• IETF and Cisco (AVVID) recommend a different mapping
• WLC and CAPWAP APs automatically converts the IEEE mapping to
AVVID mapping
AVVID 802.1p UP-Based AVVID IP DSCP AVVID IEEE
Traffic Type 802.1p UP 802.11e UP
Reserved (Network Control) 56 7 7
Reserved 48 6
Voice 46 (EF) 5 6
Video 34 (AF41) 4 5
Voice Control 24 (CS3) 3 4
Gold Background 18 (AF21) 2 2
Silver Background 10 (AF11) 1 1
Best Effort 0 (BE) 0 0.3
The process of moving a packet through the wireless network at the appropriate service level
involves the movement of the packet across the wired network as well. While both the wired
and wireless network respects QoS markings at Layer 3 (commonly using a differentiated
services code point [DSCP] marking), how Layer 2 markings are translated differs between the
two mediums. The AVVID defines the translation from the eight 802.1p priorities to IP DSCP,
and the IEEE defines the translation from IP DSCP to 802.11e UP. Two different sets of
translations must be used to ensure that the packet receives the same priority all the way across
the network. The chart shows the default values as they are mapped between layers. It also
shows the QoS values used by different types of traffic. Notice that there is no direct correlation
between Cisco AVVID DSCP and 802.11e UP. However, since they are both related to 802.1p
you can use this relationship as a translator.
802.1p is always capped to WLAN QoS profile
DSCP is never capped
Untagged wired traffic is sent at 802.11e max QoS
Suppose that the network wired infrastructure sends a data packet to the WLC and then to the
AP. This packet may have a DSCP field or an 802.1p class of service (CoS) value when leaving
the wired source. When the packet reaches the WLC, the original DSCP value is read and kept
in the inner DSCP field. The packet is transformed into an 802.11 frame and encapsulated into
the Control and Provisioning of Wireless Access Points protocol (CAPWAP). During the
encapsulation process, the original DSCP value is also transparently applied to the CAPWAP
outer header. The QoS value read in the CoS field (or DSCP field if there is no CoS field) is
then compared to the QoS value applied to the wireless LAN. Several cases can occur:
 The WLC wireless LAN has no QoS mapping: In that case, the outer header does not
carry any tag.
 The WLC wireless LAN has a QoS mapping that is higher than the CoS value in the
received packet: For example, the wireless LAN is associated to Silver, 802.1p 3, the CoS
in the packet is 2, and DSCP is 20 (AF22). In that case, the CoS value requested in the
packet is transferred to the outer header. In this example, the outer header carries the CoS
value coming from the client (2), and the outer DSCP is unchanged (AF22).
 The WLC wireless LAN has a QoS mapping that is lower than the DSCP or CoS value
in the packet: For example, the wireless LAN is associated to Silver, 802.1p 3, the CoS
value in the frame header is 5, and the associated DSCP in the packet is 46 (EF). In that
case, the CoS value in the outer header is capped to the wireless LAN maximum. In this
example, the outer header carries the CoS value 3. The DSCP value is transparently applied
to the outer header (46).
You can see that in any case, the outer CoS level does not exceed the maximum defined for the
wireless LAN, whereas the DSCP value transparently reflects the DSCP value originally
requested by the client. The packet is transferred to the switch and then to the AP. After the
packet has arrived at the AP, the inner packet is retrieved and distributed to the cell. Two cases
can occur:
 The client has no WMM support: The packet is placed in the default transmit (TX) queue
for the wireless LAN, which is the Distributed Coordination Function (DCF) queue,
without any WMM prioritization.
 The client has WMM support: The packet is placed in the appropriate queue for the
802.11e traffic category (TC) value derived from the CAPWAP packet outer DSCP value.
When doing so, the AP makes sure that the requested TC does not exceed the wireless
LAN QoS policy. For example, the wireless LAN is associated to Silver, 802.1p 3, and the
DSCP value in the packet is 46 (EF). In that case, the WMM value in the 802.11 header is
capped to the wireless LAN maximum. In this example, the 802.11 header carries the AC
tag of Silver (3). The DSCP value is transparently applied to the Layer 3 section of the
frame (46).
The same logic applies for wireless frames received at the AP and forwarded to the WLC. The
AP encapsulates the entire frame into CAPWAP, preserving the inner DSCP and 802.11e
values. For the CAPWAP header, the AP makes sure that the outer QoS value does not exceed
the WMM value configured for the wireless LAN. As the AP is usually on an access port, this
translates into the AP capping the outer DSCP value. When the encapsulated packet reaches the
WLC, the CAPWAP header is removed. The WLC then applies the same logic as on the
previous page, which means the inner DSCP value is kept unchanged. When the WLC converts
the 802.11 frame into 802.3, the 802.1p value is capped to the wireless LAN profile maximum.
This logic is very efficient in most cases, with a few exceptions:
 All traffic for a given wireless LAN is expected to be of the same type. When a wired
packet is received with no QoS marking, the WLC places the packet into the wireless LAN
profile highest queue. For example, if the wireless LAN QoS profile is set to Platinum, any
untagged packet received by the WLC and sent to a client in that wireless LAN is placed in
the Platinum category. Although the inner marking may not exist, the outer CAPWAP
marking will be set to DSCP 46 and 802.1p 5. This prioritization system makes sense for
packets that are of voice type, but is not adapted for packets that are not marked because
they do not need any priority.
 Multicast packets are not marked. These packets are forwarded on a per-VLAN basis.
Therefore, they may be sent to several wireless LANs with different QoS levels. The
consequence is that multicast packets are always sent as best effort. This may be an issue
when these packets are destined for one single wireless LAN and would require
prioritization. A typical example is music-on-hold for voice networks.
 Most devices use multiple applications simultaneously. A handheld device may be a VoIP
phone and also offer web browsing functions. When associating to a wireless LAN, it may
be difficult to choose which wireless LAN and which associated QoS level should be more
appropriate: Platinum wireless LAN for the voice function, or Silver wireless LAN for the
web browsing function? With the Bring Your Own Device (BYOD) trend, the need for
differentiated QoS inside the same wireless LAN became prevalent. This led Cisco to
enhance the default QoS mechanisms for WLANs and introduce the Alloy QoS.
Gold WLAN profile, voice packet
• Upstream traffic Payload DSCP 46 UP 6 (Platinum) DSCP AF 41 CoS 4 3
1 Payload DSCP 46 UP 6 (Platinum)
2 Payload DSCP 46 UP 6 (Platinum) DSCP AF 41 Payload DSCP 46 CoS 4 4
• Downstream traffic Payload DSCP 46 UP 5 (Gold) DSCP 46 CoS 4 2
4 Payload DSCP 46 UP 5 (Gold)
3 Payload DSCP 46 UP 5 (Gold) DSCP AF 41 Payload DSCP 46 CoS 5 1

Gold is commonly used for video applications. Gold priority level is lower than Platinum,
because video applications can often be buffered. When setting a WLAN to Gold and enabling
the default wired QoS 802.1p mapping (5), the following translation occurs as WMM traffic
transits upstream, from the WMM client to the AP and then the WLC2:
802.11e CAPWAP DSCP 802.1p
7 AF41 4
6 AF41 4
5 AF41 4
4 AF31 3
3 AF21 2
2 AF11 1
1 CS1 1
0 00 0
2
This section assumes that Layer 3 switches between the WLC and the AP use the default and recommended CoS-to-
DSCP and DSCP-to-CoS maps.
The following translation occurs for the 11 Cisco QoS base values when WMM traffic transits
downstream, from the WLC to the AP and then the WMM client:
DSCP/Application 802.1p/DSCP 802.11e
48 (CS6)/IP Routing 4/34 (AF41) 5
46 (EF)/Voice 4/34 (AF41) 5
34 (AF41)/Interactive 4/34 (AF41) 5

Video
32 (CS4)/Streaming Video 4/34 (AF41) 5
26 (AF31)/Mission Critical 3/26 (AF31) 4
24 (CS3)/Call Signaling 3/26 (AF31) 4
18 (AF21)/Transactional 2/18 (AF21) 3

Data
16 (CS2)/Network 2/18 (AF21) 3

Management
10 (AF11)/Bulk Data 1/10 (AF11) 2
8 (CS1) Scavenger 1/8 (AF11) 2
0/Best Effort 0/0 0
The illustration shows the values for an example scenario. In this case, a voice packet is sent
from a wireless client toward the network, and another voice packet is sent back from the wired
network toward the wireless client. WMM is used, and the 802.1p mapping for the Voice SSID
is the default 802.1p 6.
The upstream frame starts from the client with a DSCP value of 46 and an 802.11 UP of 6
Platinum (1). The AP encapsulates the frame into CAPWAP, checks the maximum QoS value
for the SSID, and limits the outer QoS to DSCP 41, which is the Gold level (2). If the switch
port to the AP is set to trust DSCP, the switch trusts the incoming outer DSCP value and checks
its map to know what default 802.1p value matches DSCP Assured Forwarding (AF) 41: by
default, 802.1p 4. Upon reaching a trunk on the switch, an 802.1p tag of 4 is added, matching
the DSCP 41 value. The WLC receives the frame, extracts the encapsulated content, forwards
the QoS value requested by the client (46) into the outer DSCP section, checks the maximum
QoS value for the SSID and limits the 802.1p value that matches Gold level, and sets 802.1p to
4 (4).
For downstream traffic, a packet marked DSCP 46 and 802.1p 5 reaches the WLC (1). The
WLC checks the maximum QoS level allowed on the SSID, converts the 802.3 frame into an
802.11 frame, and limits the inner UP value to 5 (Gold) for the 802.11 QoS tag. The original
DSCP value is maintained inside the packet. The WLC then encapsulates the frame in
CAPWAP, translates the DSCP value unchanged (DSCP 46) to the outer header, then limits the
802.1p value to 4 (2). When the packet reaches the switch, if trust CoS is set on the switch
trunk, the outer DSCP value is not trusted and converted to the DSCP value that should match
802.1p 4, which is AF41. When the packet leaves a switch trunk to be sent to an access port,
the switch removes the 802.1p tag. The AP receives the packet with the outer header marked as
DSCP AF41. The AP checks the maximum QoS value for the SSID and accepts the inner
limited 802.11 QoS value of 5. The AP then sends the packet to the cell using the Gold queue.
Alloy QoS and Traffic Control Techniques
This topic describes how Alloy QoS offers a finer traffic prioritization system for wireless
networks than the standard metal QoS system. This topic also describes other traffic admission
mechanisms that may help control traffic flows through the wireless network.
• Alloy QoS provides the capability to properly prioritize the multiple traffic
types that a multifunction device sends across the same WLAN.
• WLAN metal names are now treated as a profile name.
- Alloy separates default and maximum QoS levels for traffic on a WLAN.
- Instead of applying a fixed priority level, each profile name now consists of
three administratively configurable priorities.
- From the AP’s perspective, each WLAN is assigned three user priority values.
- Default configuration assigns a priority of 0 to unicast and multicast.
WLC software release 7.2 introduced Alloy QoS to enable more granular QoS control. Alloy
QoS provides the capability to properly prioritize the multiple traffic types that a multifunction
device sends across the same wireless LAN. Alloy QoS separates the default and maximum
QoS levels for traffic on a wireless LAN instead of applying a fixed priority level. Now, each
profile name consists of three administratively configurable priorities.
Sending to non-WMM clients at the default multicast QoS priority solves the multicast-unicast
priority problem. This allows WMM clients to promote traffic by applying the appropriate tag
and non-WMM client traffic to be sent at the lower default level.
From the AP’s perspective, each wireless LAN (WLAN) is assigned three user priority values:
 WLAN-maximum-priority
 WLAN-unicast-default-priority
 WLAN-multicast-default-priority
Administrators can configure each of the WLAN priority values if the QoS level is one of the
customer defined Alloy levels. Valid priority values for an Alloy level are:
 WLAN-maximum-priority – 0 to 6
 WLAN-unicast-default-priority – 0 to WLAN-maximum-priority
 WLAN-multicast-default-priority – 0 to WLAN-maximum-priority
Note that the lowest priority value is not 0 and must be considered carefully when configuring a
metal level as an Alloy profile. For example, if the WLAN-maximum-priority value is 2, then
the permitted WLAN-unicast-default-priority values are 1 or 2 and 0 is not permitted.
• Rate-limiting can be set globally or per WLAN (7.3 and later), for both
upstream and downstream directions.
Bi-Directional Rate Limiting

Another very powerful technique used to control bandwidth consumption is rate limiting. With
rate limiting, you can define how much bandwidth should be assigned to each user, both in the
upstream and the downstream directions. Rate-limiting has long been available on WLCs, but
recent codes allow a finer tuning on which limitation is applied to which user, WLAN, or QoS
profile type.
In WLC release 7.2 and before, you could configure downstream rate limiting on a per-QoS
profile basis. In WLC code releases 7.3 and later (Cisco Prime Infrastructure code 1.2 and
later), you can configure rate limiting for a QoS profile, but also for a WLAN. In both cases,
rate limiting can be set for downstream traffic, upstream traffic, or both.
Providing this ability will allow setting a priority service to a particular set of clients. A
potential use case would be in hotspot situations where a company could offer free low-
throughput service to everyone, but charge users for a high-throughput service. Rate limiting is
done by expanding the existing rate-limiting feature of QoS profiling to AP. Rate limiting is
done through strict protocol matching. Real-time rate limits are applied to UDP traffic while
data limits are applied to TCP traffic.
• Call admission control (CAC)
- Load-based: Client CAC
- Bandwidth-based: AP CAC
- SIP call admission control
• Expedited bandwidth requests
- Uses WMM traffic specifications
• Unscheduled automatic power save delivery (U-APSD)
- WMM enhancement to power saving clients
• You can also use AVC to monitor and control QoS on a per-application
basis (CUWN 7.4, CA 3.3 for visibility and 3.4 for control)
Standard metals and Alloy QoS optimize the prioritization process for frames sent to and from
the wireless space. They are congestion management mechanisms. However, they are not
sufficient to provide congestion avoidance. Several other mechanisms can be configured on the
WLC to optimize traffic admission and limit the risk of congestion in the first place, and to
improve the user experience. These mechanisms are primarily targeted toward voice and video
traffic:
 CAC
 Expedited bandwidth requests
 Unscheduled automatic power save delivery
Call Admission Control

CAC enables an AP to determine what voice or video flow should be admitted based on the cell
bandwidth availability and the potential flow expected bandwidth requirements. Three types of
CAC are available: bandwidth-based CAC, load-based CAC, and an additional CAC
mechanism for voice flows using Session Initiation Protocol (SIP). The major difference
between them is in how the bandwidth is calculated.
Load-Based CAC
A limitation of static CAC is that it only takes into account the current traffic of the AP to
determine the current bandwidth consumption. Load-based CAC incorporates a measurement
scheme that takes into account the bandwidth that is consumed by all traffic types (including
that from clients), co-channel AP loads, and co-located channel interference.
In load-based CAC, the AP continuously measures and updates the RF channel utilization (that
is, the percentage of bandwidth that has been exhausted), channel interference, and the
additional flows that the AP can admit. The AP admits a new flow only if the channel has
enough unused bandwidth to support that call. By doing so, load-based CAC prevents
oversubscription of the channel and maintains QoS under all conditions of wireless LAN
loading and interference. Load-based CAC is considered more efficient than static CAC in
most cases.
Bandwidth-Based CAC
A QoS-enabled (WMM) wireless client can specify how much bandwidth an intended traffic
flow would require by sending an add traffic stream (ADDTS) request to the AP before the
flow starts. The ADDTS frame contains a description of the intended traffic flow, called traffic
specification (TSpec), in terms of bandwidth consumption, number of packets per second, data
rates, and so on. Bandwidth-based or static CAC enables the AP to determine if it is capable of
accommodating this particular flow based on the existing client bandwidth consumption. If the
additional intended flow would result in exceeding a configurable AP radio utilization
threshold, the AP would reject the flow.
To use bandwidth-based CAC with voice applications, the wireless LAN must be configured
for Platinum QoS. To use bandwidth-based CAC with video applications, the wireless LAN
must be configured for Gold QoS. Also, make sure that WMM is enabled for the wireless LAN.
SIP CAC
SIP CAC provides bandwidth reservation for SIP-based voice calls. For standard static CAC
and load-based CAC, bandwidth is reserved via TSpec, but most SIP clients do not support
TSpec, thus preventing bandwidth reservation. When expecting SIP clients, you can configure
SIP CAC. This feature enables the WLC and the AP to examine the content of incoming
packets for a given wireless LAN and identify SIP traffic. When such traffic is identified, the
WLC or AP identifies the source and destination, and provisions bandwidth for a SIP call. This
feature is applicable for non-TSpec-based SIP calls. SIP call snooping should be enabled only if
there are non-TSpec SIP-based clients. It is recommended that you use the SIP CAC feature
only with static CAC.
Do not use SIP CAC with load-based CAC. Load-based CAC statistics are based on the AP
radio statistics that take into consideration 802.11e QoS information in the 802.11 packets. If
there are any SIP-based voice calls from clients that do not have 802.11e QoS support, those
calls will not be taken into account to limit calls that are based on load-based CAC.
You can configure the SIP CAC feature to set a maximum call limit. This feature must be
configured only for SIP-based CAC to limit the number of calls per radio. By default, this
feature is disabled. The default value for maximum number of calls is 0, which indicates there
is no check for maximum call limit.
Expedited Bandwidth Requests

The expedited bandwidth request feature enables Cisco Compatible Extensions v5 clients to
indicate the urgency of a WMM TSpec request (for example, an emergency call) to the wireless
LAN. When the WLC receives this request, it attempts to facilitate the urgency of the call by
allowing that particular call to take place, even if it violates the defined CAC thresholds. This
additional call is rejected if admitting the call would render the AP radio unusable (because the
AP utilization would exceed 95 percent of the AP capacity).
You can apply expedited bandwidth requests to both bandwidth-based and load-based CAC.
Expedited bandwidth requests are disabled by default.
Unscheduled Automatic Power Save Delivery

Unscheduled automatic power save delivery (U-APSD) is a QoS facility that is defined in IEEE
802.11e that extends the battery life of mobile clients. In addition to extending battery life, this
feature reduces the latency of traffic flow that is delivered over the wireless media. Because U-
APSD does not require the client to poll each individual packet that is buffered at the AP, it
allows delivery of multiple downlink packets by sending a single uplink trigger packet. WLC
support for U-APSD is enabled automatically when WMM is enabled. Although enabled, the
client may choose not to use it.
Application Visibility and Control
AVC, introduced in CUWN controller code 7.4, is another way of controlling QoS, on a per-
application basis. With AVC and Network-Based Application Recognition (NBAR) 2, the
controller and AP can perform deep packet inspection to identify traffic of interest (on a per-
application basis). Based on this application determination, you can block a specific traffic flow
or change the application QoS marking on the wired side.
AVC is available on CUWN controllers running code 7.4 and later. AVC will be introduced in
two phases in converged access controllers. A first phase (IOS XE release 3.3) will allow you
to monitor wireless applications (AVC is already available for wired traffic). A second phase
(IOS XE 3.4) will allow you to re-mark and limit the bandwidth allocated to the monitored
wireless applications.
Voice WLAN should be configured for the highest possible QoS by editing the WLAN and
selecting the QoS tab. Platinum (voice) should be selected from the QoS drop-down menu.
Keep in mind that QoS, being related to prioritization, is a relative factor. For example, if you
design two WLANs, one set to Bronze and the other to Silver, the second SSID will be
prioritized over the first one. You could, therefore, assign any priority level as long as the
prioritization is consistent among the WLANs. Cisco still recommends using the predefined
QoS levels (Platinum for voice, Gold for video, and so on), as some applications expect these
QoS levels and will not function properly if another QoS level is chosen.
Depending on the policy of the company and the ability of clients to support WMM, choose the
appropriate WMM support level, as follows:
 Disabled: Use this setting to disable the WMM policy.
 Allowed: Use this setting to allow the clients to communicate with the WLAN. Clients
supporting WMM will use it. Clients not supporting WMM will not use it, but will still be
allowed to associate.
 Required: Use this setting to ensure that it is mandatory for the clients to have the WMM
feature enabled to communicate with the WLAN.
To ensure that the QoS marking will be maintained between the AP and the WLC, edit the QoS
profile used for the WLAN and enable 802.1p wired QoS protocol. From the same page, you
can define the QoS level for the WLAN unicast, multicast, and untagged traffic.
For each band where you expect a specific type of traffic to be dominant, you can fine-tune the
way WMM will be applied from the EDCA parameter page for the relevant band. You can set
the band to offer more transmit opportunities for voice or video traffic. You can also keep the
default WMM settings, which offers a fair share of transmit opportunities to all WMM
categories.
You can also enable CAC, which can be set for voice (with TSpec or SIP) and/or for video
traffic. The setting of such limitations is recommended to ensure consistent quality in the calls
(audio and video) that are allowed in the relevant band of operation.
• Management and AP Manager
interfaces use 802.1Q marking
switch(config)# interface gigabitethernet 0/12

switch(config-if)# mls qos trust dscp
switch(config-if)# srr-queue bandwidth share 10 10 60 20
switch(config-if)# srr-queue bandwidth shape 10 0 0 0
switch(config-if)# priority-queue out
switch(config)# interface gigabitethernet 0/1

switch(config-if)# mls qos trust cos
switch(config-if)# srr-queue bandwidth share 10 10 60 20
switch(config-if)# srr-queue bandwidth shape 10 0 0 0
switch(config-if)# priority-queue out
The WLC-based AP in local mode is usually connected to an access port. The native
(untagged) VLAN is used for traffic to and from the WLC. In a normal configuration, no traffic
coming from or to a wireless client transits directly through the AP without going to the WLC.
When voice over wireless is implemented, the AP will tag the frames it sends to the WLC to
identify what type of traffic is being transmitted. In that case, QoS has to be configured to
prioritize voice.
The WLC is connected to a trunk port. There may be a native VLAN, but not always, because it
is not a mandatory requirement. As a matter of fact, the management interface and the AP
Manager interface should always be tagged. These interfaces are used to send QoS-enabled
traffic. Without a VLAN tag and the corresponding 802.1Q section, there is no CoS and all
traffic untagged is treated as best effort.
Just like for APs, when voice over wireless is implemented, QoS has to be configured to
prioritize voice traffic.
Notice that, on the port to the AP, DSCP is trusted. As the AP is in an access VLAN, its frame
does not contain any 802.1D header, and therefore there is no CoS. Layer 3 QoS information
must be used.
The WLC connects to a trunk, and 802.1D is present in the header, Layer 2 QoS is to be
trusted. This configuration goes beyond the corresponding switch port type—built in the way
QoS is tagged between the WLC and the AP. Trusting DSCP on the WLC port may have
unpredictable consequence on the prioritization of a given frame. CoS should be trusted.
• QoS profiles are applied on a per-WLAN basis.
• QoS roles limit bandwidth contention between WLAN users.
- Affects downstream and upstream traffic bandwidth.
- Usually applied to guest users.
- Normally used to apply lower QoS settings for guest users.
• Not supported on the Cisco 2500 Series controllers or WLCM.
Guest traffic poses another challenge for the wireless network administrator. In the course
customer scenario, HTA Hospital intends to provide wireless connectivity to customers (guests,
patients), and may charge them for its usage. However, this traffic must be controlled so that it
does not affect the critical traffic. Even if two SSIDs are configured (one for customers, one for
HTA employee and devices), the wireless space is still shared. One way to control bandwidth
utilization from customer web browsing traffic (including video streaming from web sites) is to
implement guest roles.
When you configure a guest role, you associate a bandwidth contract to that role. This contract
determines how much bandwidth an individual user matching the role is allowed to consume at
any given time, both downstream (from the wired infrastructure toward the guest device) and
upstream (from the wireless device toward the wired infrastructure). For example, you can
decide that a guest profile should only be allowed to consume 512 KB in any direction. You
can set different limits for upstream and downstream, and different limits for TCP and UDP
traffic.
Once the role is created, you can assign users to a particular role, thus limiting the bandwidth
consumption of any user mapped to the role. You can create several roles (although a user can
be mapped only to one role at a time), for example, if you want to provide several levels of
service depending on customer service subscription. Up to 10 individual QoS roles can be
defined on the WLC using either the GUI or CLI. Note that this feature is not supported on the
2500 Series controllers or the Cisco Wireless LAN Controller Module (WLCM).
Summary
• QoS is an end-to-end configuration to optimize traffic service in times of

congestion.
• In the wireless world, four main QoS traffic categories are used:
platinum, gold, silver, and bronze.
• Alloy QoS allows the administrator to determine what traffic queue
should be used for untagged unicast traffic and multicast traffic. It can be
combined with rate limiting and admission control to better manage the
Wi-Fi bandwidth.
References
 Cisco Controller Configuration Guide version 7.4, QoS section
http://www.cisco.com/en/US/docs/wireless/controller/7.4/configuration/guides/wlan/config
_wlan_chapter_010011.html
 Cisco Prime Infrastructure 2.0 Configuration Guide (when available), QoS section
Lesson 5
Additional Wireless Features

Overview
The Cisco wireless network offers more than just basic data and voice services under secure
network access control. Many enterprises are challenged by the explosion of mobile devices
and the expectations that users bring to the workplace. Users often expect the wireless network
to manage bandwidth-intensive streaming video. Cisco VideoStream allows network
administrators to adjust wireless network settings in support of streaming video services.
Enterprises also have to adapt to the explosion of Apple iPhones and iPads where users expect
to bring your own device (BYOD) into the workplace. Cisco multicast DNS (mDNS) gateway,
or Bonjour support, serves this demand. They provide i-device users the ability to discover
services such as AirPrint and AirPlay while on premises.
In keeping with the convergence of wired and wireless infrastructures, Cisco provides ever-
increasing feature parity to unify the network by extending services such as Network-Based
Application Recognition version 2 (NBAR2) to the wireless equivalent, which is application
visibility and control (AVC). AVC allows a network administrator to view and prioritize the
applications that are being used on the network. This ensures that business-critical applications
are treated at a higher priority level than non-critical applications.
Taking the wireless network capabilities into new territory, Cisco recently introduced the
Connected Mobile Experiences (CMX) solution. CMX offers a way to improve user mobility
experiences and at the same time make it possible to monetize the network through advanced
location services and Mobile Concierge.
These are examples of the continued evolution of the networks to meet customer needs. This
lesson discusses each of these capabilities in the context of the course customer scenario, HTA
Hospital.
Objectives
Given a customer scenario and an operational wireless LAN, describe and enable additional
wireless features including Cisco VideoStream, Bonjour, and mobility services solutions.
Upon completing this lesson, you will be able to meet the following objectives:
 Describe and enable Cisco VideoStream
 Describe Cisco Wireless Bonjour gateway
 Describe mobility services
Cisco VideoStream
This topic describes the advantages of the wireless streaming video feature, Cisco
VideoStream, over the use of traditional multicast in a wireless network.
• Cisco optimizes end-to-end video starting at the access point.

• Has been tested for 30X less bandwidth consumed
• Offers double the performance of competitors.
BEFORE AFTER
Manual RF Management Dynamic RF Management
Global
Enterprise
CEO M&A Sports CEO M&A Sports

Meeting Negotiation Event Meeting Negotiation Event
Like data and voice, video applications have become increasingly integrated into today’s
business processes. Video may be used for collaboration between employees and for on-
demand training. As a cost-saving measure, employees in the enterprise may be encouraged to
use videoconferencing rather than traveling for meetings whenever possible. Additionally,
corporate executives have discovered the effectiveness of disseminating important company
information through the use of IPTV.
To adapt to the increasing use of video means the network must be capable of supporting
multiple video, audio, and data streams in a reliable, synchronized manner without disruption.
However, video is a very demanding application that immediately exposes any weaknesses in
the network.
A substantial difference between Wi-Fi and a wired LAN is in the underlying Layer 2 transport,
Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) for the wireless versus
Carrier Sense Multiple Access with Collision Detection (CSMA/CD) for the wired medium. As
a result, Wi-Fi loses a greater number of packets than wired. To compensate, Wi-Fi uses a
retransmission mechanism whereby packets that are not successfully received and
acknowledged are resent. However, Wi-Fi does not provide a retransmission mechanism for
multicast traffic like video.
Packet loss is a serious problem for video, where loss of even a single packet can result in an
error that propagates for many video frames. For this reason, multicast video applications that
work well on a wired network can fail completely when they operate on a Wi-Fi network.
Basic video support is available with the use of 802.11n access points (APs). Although 802.11n
APs provide additional bandwidth and do not saturate as quickly as non-802.11n devices, they
still suffer from the same issues in supporting multicast video. It is still a CSMA/CA medium,
which does not provide any retransmission mechanisms for multicast traffic. However, Cisco
VideoStream technology adds improved multicast support for video applications.
There are three unique aspects to Cisco VideoStream that create a reliable multicast video
delivery solution. These aspects are described as follows:
1. Multicast direct provides a reliable multicast video delivery solution through the use of the
following:
 Multicast to unicast: Traditional multicast transmissions are treated much like a

broadcast transmission in a wireless network. Intended to be received by all clients in
the cell requires their transmission at the lowest mandatory data rate in the cell,
regardless of the date rate at which a client is associated. In addition to providing
packet error correction, the multicast to unicast capabilities of multicast direct allow the
transmission to be sent to each individual client at the highest rate that the client is
capable of and provide for an acknowledged receipt of the transmission.
 Direct memory access (DMA): DMA provides real-time copying of video streams at
the AP. It quickly replicates multicast packets into unicast packets through header
modification without tying up the AP CPU. This achieves greater throughput in the
process.
2. Stream admission and prioritization
With stream admission, the network administrator can configure the media stream with a
different priority based on importance within the organization. Eight priorities are available,
with 1 as the lowest and 8 as the highest. The feature can also be enabled at the radio level (2.4-
GHz and 5-GHz) and at the wireless LAN or Service Set Identifier (SSID) level. It provides
more control to the administrator to identify specific video streams for preferential quality of
service (QoS) treatment. For example, a company-wide address from the CEO takes
precedence over a replay of a recorded training session.
3. Resource reservation control (RRC)
As more and more users begin to use video in the workplace on Wi-Fi endpoints, the ability to
gracefully manage and scale a continuous and high-quality experience for fluctuating groups of
users at any given time or location is critical. RRC provides enhanced capabilities to manage
admission and policy controls. Admission and policy decisions are made based on the RF
measurements, statistical measurement of the traffic, and system configurations. RRC provides
bandwidth protection for the video client by denying requests that would cause
oversubscription. Channel utilization is used as a metric to determine the capacity and to
perform admission control.
In addition to taking advantage of the improved data rates available with 802.11n-capable APs,
Cisco VideoStream also takes into consideration the physical, MAC, and application layers of
the wireless LAN. This results in a media-ready network optimized for video delivery. Video is
classified as very important and, as such, the QoS or bandwidth that is allocated for this
transmission is high. The video stream is delivered only to those clients that request it. This
restriction has implications for both the clients who request the video stream and those clients
who do not. By sending the video stream as a unicast only to the clients who request it, and not
streaming when there is no demand, the network is not flooded with unnecessary demand and
the performance for all is enhanced. Finally, admission control is used to limit the number of
clients who are served the video stream in order to eliminate the risk of degrading the
performance for all others.
• Converts multicast flow to unicast flow at the AP level
- Optimal speed can be used, frames are acknowledged
• Uses Radio Resource Control to ensure radio resource optimal reservation,
Direct Memory Access to provide real-time copying of video streams at the AP
level, and stream admission and prioritization
IGMP Join 5 IGMP Join
Request Request
IGMP Join IGMP Join
6
Response Response
RRC Response
2
8 7
RRC Request
3 IGMP Join
RRC Response
RRC Request
Request 6. Multicast router sends
IGMP Join
1. Client sends the
Request
IGMP join IGMP join response
4 7. Multicast stream sent
2. Controller intercepts
IGMP join request
3. Controller sends AP CAPWAP
RRC request
4. AP sends RRC response
5. Controller sends 1
IGMP join request 9. Access point converts stream to
unicast and transmits to client
8. Controller forwards
multicast stream to 9
the access point
The following steps outline the sequence of events and flow of messages that occur in the
network when a video client joins the wireless network with Cisco VideoStream technology
enabled.
Step 1 A client sends an Internet Group Management Protocol (IGMP) join request toward
the network.
Step 2 The Cisco wireless LAN controller (WLC) intercepts the IGMP join request.
Step 3 The WLC sends an RRC metric request to the AP.
Step 4 The AP responds with the radio and client RRC metric information.
Step 5 If resources are available, the WLC forwards an IGMP join request to the multicast
source.
Step 6 The multicast source sends an IGMP join response.
Step 7 The multicast source adds the WLC as a recipient of the multicast stream and begins
sending the video stream to the WLC.
Step 8 The WLC forwards the multicast stream to the AP.
Step 9 AP-reliable multicast mechanisms convert the received multicast stream into unicast
packets that are destined for the client.
The IPv4 Cisco VideoStream feature for delivering reliable video to wireless clients was
extended to provide support for IPv6 clients and works in a manner very similar to IPv4. The
IPv6 operation is as follows:
 Uses Multicast Listener Discovery version 1 (MLDv1) snooping to listen for an
MLDv1 report from a client requesting to join an IPv6 multicast stream.
 Uses RRC to verify that the AP that the client is on has sufficient bandwidth available
to support another stream.
 Generates a new Multicast Group Identifier (MGID) and adds it to the table linking the
requesting client to the MGID and updates the associated AP.
 Creates an Extended Unique Identifier (EUI), EUI-64 format IPv6 address using the
MAC address associated to the IPv4 address of the virtual LAN (VLAN) interface of
the client.
 Generates an MLD report and sends it upstream.
 Takes the received IPv6 stream and encapsulates it in an IPv4 header with an IPv4
multicast address, to which all joined APs listen as the destination, and forwards it over
the multicast-enabled IPv4 network.
 Upon receiving the IPv4 encapsulated multicast, each AP checks its MGID table to
determine if it has any associated clients that want to receive the stream. If it does, it
replicates the frame, creating a copy for each client wishing to receive it, and then
unicasts it to each client.
Just like the IPv4 version, the IPv6 version requires that multicast be enabled in the IPv4
network and globally on the Cisco WLC, with the appropriate snooping type (IGMP/MLD).
Configuration and troubleshooting of the IPv6 media stream is identical to the IPv4. All that
changes is the IP address format.
• Enable the Multicast Direct feature and add your media streams.
The only difference

between creating
IPv4 streams and
IPv6 streams is the
format of the IP
address.
To configure the multicast direct feature on the WLC via the GUI, use the following procedure:
Step 1 Choose Wireless > Media Stream > General to open the Media Stream > General
page.
Step 2 Click the Multicast Direct Feature check box to enable the multicast direct feature.
The default value is disabled.
Note Enabling the multicast direct feature does not automatically reset the existing client state.
You must reset the multicast direct-enabled wireless LAN and 802.11 networks to clear
clients.
Step 3 Under Session Message Config, choose Session Announcement State to enable the
session announcement mechanism. If this feature is enabled, clients are informed
each time that a WLC is not able to serve the multicast direct data to the client.
Step 4 In the Session Announcement URL text box, enter the URL where the client can
find more information when an error occurs during the multicast media stream
transmission.
Step 5 In the Session Announcement Email text box, enter the email address of the person
who can be contacted.
Step 6 In the Session Announcement Phone text box, enter the phone number of the person
who can be contacted.
Step 7 In the Session Announcement Note text box, enter a reason why a particular client
cannot be served with a multicast media.
Step 8 Click Apply to commit your changes.
Step 9 Choose Wireless > Media Stream > Streams to open the Media Stream page.
Step 10 Click Add New to configure a new media stream. The Media Stream > New page
opens.
Step 11 In the Stream Name text box, enter the media stream name. The stream name can be
up to 64 characters.
Step 12 In the Multicast Destination Start IP Address text box, enter the start IP address of
the multicast media stream. Use IPv4 format for IPv4 streams or IPv6 format for
IPv6 streams. You can have both IPv4 and IPv6 streams defined.
Step 13 In the Multicast Destination End IP Address text box, enter the end IP address of the
multicast media stream. Use IPv4 format for IPv4 streams or IPv6 format for IPv6
streams. You can have both IPv4 and IPv6 streams defined.
Note The Stream Name, Multicast Destination Start IP Address, and Multicast Destination End IP
Address text boxes are mandatory. You must enter information in these text boxes.
Step 14 In the Maximum Expected Bandwidth text box, enter the maximum expected
bandwidth that you want to assign to the media stream. The values can range from 1
to 35,000 KB/s.
Step 15 From the Select from Predefined Templates drop-down list under Resource
Reservation Control (RRC) Parameters, choose one of the following options to
specify the details about the RRC:
 Very Coarse (below 300 KB/s)
 Coarse (below 500 KB/s)
 Ordinary (below 750 KB/s)
 Low (below 1 MB/s)
 Medium (below 3 MB/s)
 High (below 5 MB/s)
Note When you select a predefined template from the drop-down list, the following text boxes
under the RRC Parameters list their default values that are assigned with the template.
 Average Packet Size (100 to 1500 bytes): Specifies the average packet size.
The value can be in the range of 100 to 500 bytes. The default value is 1200.
 RRC Periodic Update: Enables the RRC periodic update. By default, this
option is enabled. RRC periodically updates the admission decision on the
admitted stream, according to the correct channel load. As a result, it may deny
certain low priority admitted stream requests.
 RRC Priority (1 to 8): Specifies the priority bit set in the media stream. The
priority can be any number between 1 and 8. The larger the value, the higher the
priority. For example, a priority of 1 is the lowest value and a value of 8 is the
highest value. The default priority is 4. The low priority stream may be denied in
the RRC periodic update.
 Traffic Profile Violation: Specifies the action to perform in case of a violation
after an RRC. Choose an action from the drop-down list. The possible values are
as follows:
– Drop: Specifies that a stream is dropped on periodic re-evaluation.
– Fallback: Specifies that a stream is demoted to best-effort class on periodic
re-evaluation.
The default value is Drop.
Step 16 Click Apply to save the configuration changes.
See the Cisco Wireless LAN Controller Configuration Guide for code versions 7.0 and greater
for instructions on the following:
 Enabling the media stream
 Setting the Enhanced Distributed Channel Access (EDCA) parameters
 Enabling admission control
 Configuring media bandwidth.
All of these must be accomplished in order to support video multicast using a reliable multicast
mechanism on the WLC.
Cisco Bonjour Gateway
This topic describes how the Cisco Bonjour gateway is used to enable sharing and print
services to Apple devices.
A new manufacturer representative arrives at HTA

to conduct an in-service training to a large team of
doctors and nurses on a new portable medical
application for Apple devices.
Um? We need to let him into our Hmmm… Sure..

Oh! Viewers justHere is the these
requested USB.
network
iPADs to common…
are very print? handouts! I need to print…
But how do I present? I have an
HowThere
about has
we print
to befor him using a
a solution! CanMy
iPAD. I have access
screen tosmall
is too your print
for so
traditional USB device? services please?
many people!
172.31.255.x 224.0.0.251
Corporate Guest
VLAN X VLAN Y
Although primarily designed for use in a home environment and as consumer electronics,
Apple devices are becoming more and more prevalent in the workplace. Apple devices are also
being seen in the enterprise environment in ever-increasing numbers. However, due to the
original intended use of these devices, they lack capabilities such as physical ports through
which they can share their screen output or the ability to connect to peripheral devices such as a
printer.
To make network configuration tasks transparent to the end user, Apple created Bonjour, which
enables Apple devices to discover and connect with each other without the need for user
configuration tasks. Bonjour is the Apple version of zero-configuration (Zeroconf) networking.
It is mDNS with DNS Service Discovery (DNS-SD). Multiple operating systems support
mDNS and DNS-SD including Windows, MacOSX, Android, Linux, and Solaris. These
devices advertise their services using a link scoped multicast address on the local segment via
both IPv4 and IPv6 simultaneously. This makes locating and using available services on a
typical single subnet home network fast and efficient without requiring any input from the user.
However, an enterprise network typically employs multiple VLANs to provide traffic
segmentation, and is much more complex than a user’s home network.
Because mDNS uses link scoped multicast addresses, the service advertisements are not
forwarded between VLANs or across Layer 3 boundaries (routed interfaces or switch virtual
interfaces [SVIs], and so on). Depending on security policies, enterprises may segment the
devices onto an SSID that only supports Wi-Fi Protected Access version 2-preshared key
(WPAv2-PSK) while users are on a more secure SSID supporting WPAv2 using 802.1X. These
SSIDs may be mapped to different VLANs for security purposes.
• The HTA solution is to enable the mDNS snooping capabilities on their
wireless controllers.
Bonjour Cache:
Bonjour AirPlay – VLAN 20
Advertisement AirPrint – VLAN 23
VLAN 20
Apple TV
CAPWAP Tunnel
VLAN 23
AirPrint Offered
VLAN 99 iPad Bonjour
Advertisement
AirPrint
In some cases, network administrators want to implement solutions that permit visitors to print
and to be able to display content from their iPads onto AppleTVs. Administrators may also
need employees to be able to retrieve information from any location in their facility while at the
same time streaming videos from the internet onto a TV or monitor. Each of these represents a
different class of users and the need to use different VLANs. The challenge is to find a way to
make the link-local service advertisements from Bonjour-enabled devices visible to other
Bonjour-enabled devices across a Layer 3 boundary.
Bonjour uses DNS-SD for service announcements and service queries, which allows devices to
ask for and advertise specific services such as the following:
 Printing services
 File sharing services
 Remote desktop services
 iTunes file sharing
 iTunes wireless i-device syncing (in Apple iOS v5.0+)
 AirPlay offering the following streaming services:
— Music broadcasting in iOS v4.2+
— Video broadcasting in iOS v4.3+
— Full screen mirroring in iOS v5.0+ (iPad2, iPhone4S or later)
By enabling the mDNS snooping capabilities on the WLC, the WLC can act as a gateway to the
services available on other subnets. This requires that the WLC is made aware of these service
advertisements by the presence of an interface in the subnet being configured on the WLC.
With mDNS snooping enabled, the WLC listens for Bonjour services by caching those Bonjour
advertisements (AirPlay, AirPrint, and so on) from the source/host (such as an AppleTV) along
with the information about which VLAN the advertisement was heard on. When clients ask for
or request a service, the WLC is capable of responding back to Bonjour for them. However,
when the WLC responds, it is directed to the individual client that made the request rather than
as a multicast response heard by all clients. The WLC accomplishes this by making a copy of
the cached Bonjour advertisement using a unicast MAC frame with a multicast IP header. This
allows the WLC to not only function as a Bonjour gateway, but also limits the multicast traffic
traversing the network.
An administrator can use the master service database on each WLC to limit which Bonjour
services will be supported by each WLC. A WLC will snoop for and learn about mDNS service
advertisements only if the service is present in the master service list database. The database
can hold up to 64 entries, thereby allowing the WLC to snoop and learn 64 different services.
This capability allows mDNS caching to be extended beyond the services offered on the local
link.
• The Bonjour service profile The Bonjour Policy
Service Policy Profile is a list of
provides filtering to allow only
allowed network
certain WLANs, interfaces, or applications (such as
users to access specific AirPlay or printing).
service types.
AirPrint AirPlay File
Share
Enforced via Multiple Methods
Per Interface Per-User*

Per VLAN
Per Group
(AP Group)
WLAN
* RADIUS AAA-override based, coming in a future release.
In situations where individual services must be supported on the WLC but should not be
available to all users, the administrator can define multiple mDNS profiles in addition to the
master service database. By attaching an individual profile to a wireless LAN, VLAN, interface
group, or an individual user, an administrator can also control the services available to clients.
An example would be a visitor who requires access to AirPlay and printing services shared by
employees. Visiting representatives do not need and should not have access to the same
network resources as employees. By creating two profiles and applying each one to an
appropriate interface, the visitor can be provided access to the required services while not even
seeing advertisements for prohibited services.
Mobility Services
This topic describes the additional components, capabilities, and advantages available to
customers by implementing mobility services.
• Cisco MSE collects RSSI information from all APs about all 802.11 devices in
the network, to compute their location.
• Location information can be sent to third-party applications (MSE API), PI (to
display location information), or used by additional services in MSE.
- Adaptive wIPS SERVICES
- Mobile concierge services Location Services Advanced Location

• Track and trace Services
interferers, rogues, Wi-Fi • Mobile concierge
- Location analytics clients, and RF tags • Thinksmart location
• Geo fencing/zone-based analytics
• With MSE 7.4, license is Location alerts
• Presence detection
Services or Advanced Location
Services. Wireless Intrusion Advanced Spectrum
Prevention Capability
- Location Services license can be • Detection and mitigation • Systemwide interferer
of security penetration details
upgraded to Advanced Location and DoS attacks • Interferer event correlation
• Visualization of interferer
Services license at any time. zone of impact and
interferer notification
- Cisco MSE can be a physical
PLATFORM
appliance or virtual appliance.
Physical Appliance Virtual Appliance
Cisco Mobility Services Engine (MSE) is a physical or virtual appliance that can communicate
with all controllers in the network. The communication uses a Cisco proprietary protocol called
Network Mobility Services Protocol (NMSP). With NMSP, the MSE can collect information
from all controllers about the MAC address and Received Signal Strength Indicator (RSSI)
level of all 802.11 devices detected by all APs in the network. Cisco MSE can then use this
information to compute the location of each detected 802.11 device.
This information can be sent to Cisco Prime Infrastructure (PI) to display device location on a
map. Using a specific application programming interface (API) software development kit
(SDK), this information can also be sent to third-party applications.
Loc
Base Location Services – Based on number of APs (7.4)
Advanced Location Services – Based on number of APs (7.4)
Loc
Base Location Services
Service 2
MSE
Location
Analytics
Adaptive WIPS – Based on number of APs

Loc
Before 7.4, Cisco MSE was enabled to collect and store position information for known clients
or tags by adding a Context-Aware Services (CAS) license. The number of elements that could
be tracked was determined by the licensing count for either clients or tags.
Licensing for 7.4 WLCs and MSEs, along with Cisco Prime Infrastructure 1.3, has undergone a
change. The basic Location Services license provides the same capabilities previously
identified as CAS. The new Advanced Location Service (ALS) license, which includes the base
Location Services capabilities, enables the following:
 Cisco Mobile Concierge services, which provide a platform for customers to build a
marketing campaign
 Access to the Cisco Mobile Concierge SDK (for example, Meridian), which allows a
customer to build mobile applications quickly and efficiently
 Location Analytics, which allow customers to create new knowledge about their
environment by filtering and analyzing the location data within the MSE, such as the
following:
— Routes taken
— Dwell time at a location
— New versus returning visitors
As of 7.4, licensing is moving from the current endpoint-based model to a per-AP licensing
model. The per-AP model obsoletes the per-device CAS license and introduces the following
two types of location licensing:
 Location Services
 Advanced Location Services
During the transition from pre-7.4 to 7.4, existing CAS client counts are converted to the per-
AP basis by dividing the CAS client count by 50 to determine AP license count. For example,
an MSE that is being upgraded from 7.3 to 7.4 and that is licensed for 20,000 clients will
become licensed for 20,000/50 = 400 APs.
Note If the resulting AP count is smaller than the number of APs currently on the Cisco Prime
Infrastructure, then a one-time, no-cost AP license for the remaining APs will be issued after
the upgrade. Use http://wnbu-press.cisco.com/licensing-requests/mse-license-request/ to
request required true-up licensing.
Note The transition period is limited to this release only. The next release will honor only AP-
based licensing.
Notice that Cisco MSE can also receive Adaptive Wireless Intrusion Prevention System (wIPS)
licenses, that enable participating access points to detect wireless attacks, and also capture these
attacks when needed. You can use Adaptive wIPS licenses on the same MSE where Location
Services or Advanced Location Services licenses are installed.
DETECT CONNECT ENGAGE
• Presence Detection • Auto On-Boarding
• MSE Location Services • Hot Spot 2.0

Mobile Concierge
• Location Analytics • Lobby Ambassador
Concierge enables engaging with
• ISE customers via different media
On Device
without
Application Browser Mobile App
802.11u (7.5)
/MSAP (Mobile Concierge
(QC) SDK)
With the explosion of mobile devices and the BYOD concept of connecting everyone,
everywhere, all of the time, business and venue operators are facing increasing pressure to
adapt to the challenge. At the same time, wireless LANs are becoming increasingly
sophisticated, enabling new capabilities and services. Until the introduction of Cisco CMX,
brick-and-mortar business operators had very limited visibility into their business environment.
This is especially true when trying to answer questions like where, when, and how do people
move around the venue (shopping mall, museum, airport, and so on), information which is
readily available to online businesses.
Cisco CMX leverages MSE location capabilities to deploy a three-step process to engage with
end users:
 Detect: The recognition of a mobile device and its characteristics as it approaches or
enters a venue. This is typically accomplished by the deployed APs hearing the 802.11
radio on the device probing.
 Connect: The seamless and secure on-boarding of the Wi-Fi client to the network
based on the device type and user credentials.
 Engage: The ability to deliver highly relevant content and services to the user based on
profile, preferences, and location within the venue.
By using the location information gathered during client engagement, customers can gain
insight into end-user on-site behavior. This can include the following:
 Traffic paths
 Dwell times
 Network utilization
 Peak usage
 Number and types of devices on the network
• MSE analytics determine historical traffic patterns, including footfalls,
dwell times, and which locations see the most traffic at what times of
day.
• This information can be leveraged by facility management to
optimize floor plan, travel paths, goods location (stores), and so on.
Reports
MSE
Database
Graphical User
Interface
Location
Data
Reporting
Data
Mediation Device/Path
Database Results
Database
WLC
Location Thinksmart Analytics Automatic conversion
Data Engine of data to results on:
JBoss Application dwell, device number,
Mobility Services Engine Server movement, frequency.
By helping management better understand how staff and visitors actually behave while onsite,
CMX makes it possible for them to maximize the impact of their floor plan. Using MSE with
integrated location analytics, the solution can track all Wi-Fi signals within the venue and
document the movements through a facility. The movements are anonymous, aggregated, and
analyzed to determine historical traffic patterns, including footfalls and dwell times, and to
determine which locations see the most traffic at what times of day.
With this improved insight, management can do the following:
 Determine the most trafficked locations to better position departments or services.
 Adjust venue layout to optimize traffic flow in periods of high use.
 Adjust venue layout to place goods or services along the most-used pathways.
 Staff service locations based on customer flows and time of day.
 Evaluate the impact of floor plan adjustments
Guests Inside Enterprise Marketing Department
New Web Browser

Experience Billboard Management Platform
WLAN
Real-time, web-based,
easy-to-use
Value-added services first,
then hyperlocal ads
With Cisco MSE 7.5, a new service was added: Cisco BillBoard (BBX). Cisco BBX addresses
the limitations of Cisco Mobility Services Advertisement Protocol (MSAP) and other solutions
that require specific client support (such as 802.11u for MSAP, or Qualcomm chip, and so on).
BBX provides the ability for marketing departments to send advertisements to mobile devices
connected to the local network. The only capability required for the client, beyond connecting
to the wireless network, is to embed a web browser that supports JavaScript. Based on the
wireless client location, type (known or new client), and time, icons can be sent to the client
web browser. These icons are not intrusive (their size is minimal and they appear at the edge of
the web browser window). The client can ignore the icons or choose to click them. When icons
are clicked, a message expands that can advertise specific promotions (discounts, and so on),
but also provide services, such as a map of the facility (where the client location is displayed),
and a search tool. The philosophy behind BBX is that shopping in a physical mall or store
should be as convenient as shopping online. Users should not need to walk many aisles to find
an item of interest, and should not have to discover promotions by chance. With BBX, users
can search for items of interest and be guided to the location of these items. Based on user
location and interests, promotions can be displayed directly on the client web browser.
Redirects all web traffic to MSE
WAN/Internet
3 functions (on same or different MSEs):

NMSP - BBX HTTP proxy (proxies client
HTTP traffic and sends icons based
on BBX Services instructions)
- BBX Services (determines what icons
should be sent to client, based on
client type and location)
- Location Services (determines client
location)
Campus
Network
Current traffic path

TCP/HTTP proxy traffic path
BBX traffic path
BBX leverages MSE in three different ways:

 A BBX Proxy function can be enabled to intercept wireless client web traffic. To
achieve this prerequisite, the outgoing router must be configured to relay wireless client
web traffic to the MSE. On the MSE where the BBX function runs, traffic is relayed to
the original page requested by the user. While the page is requested, the BBX Proxy
function queries the BBX Service function to determine which icon and which
advertisements should be sent to the user. Once the BBX Service returns the correct
icon(s), promotions, and information to display, BBX Proxy sends to the wireless client
the original page that the client requested. In that page, the icon and information
provided by the BBX Service function are embedded using JavaScript.
 The BBX Service function determines what information (in addition to the original
page requested by the user) should be returned to the user. The BBX Service bases its
decisions on location information returned by the location services function of the
MSE, and also on the BBX Service configuration. This configuration is done by the
marketing department and determines, for each client type (known or unknown),
location and time (of the week or the day), what icons and what promotions should be
sent.
 The Location Service provides the location information for each client. This function is
not specific to BBX, and is the Standard Location Service function of the MSE.
Notice that these three services can theoretically reside on the same MSE. However, in a large
network, it is preferable to locate each function in a separate MSE. Advanced Location
Services licenses are needed for BBX Proxy and BBX Services. Standard Location Service
license is enough for the location function. MSE 7.5 or later is needed to support BBX.
Summary
• Cisco VideoStream is a wireless feature that may be used to help

prevent multicast video traffic from completely disrupting network
service.
• The mDNS gateway (Bonjour) capability on the WLC simplifies the use
of Apple devices in an enterprise network setting.
• Whether you are in retail, hospitality, transportation, healthcare,
education, or government, the Advanced Location Analytics and Mobile
Concierge available with CMX allows you to tap into the growing mobile
lifestyle now.
Module Summary
This topic summarizes the key points that were discussed in this module.
• When designing wireless networks, the first step is to verify customer

requirements in order to select and deploy the right equipment, models,
features, and functionality.
• During the deployment phase, you need to enable critical wireless
capabilities, including high availability for resiliency when possible,
RRM, ClientLink, BandSelect, and CleanAir.
• Another key phase of wireless network deployment is to establish and
enable a wireless security policy that includes consideration of user
segmentation (levels of access to network services), authentication
methods, policy assignment, ACLs, and wIPS.
• For any network that is expected to face bandwidth limitation issues, you
need to determine and enable QoS levels that include consideration of
where and how QoS is applied, metal levels, and Alloy QoS to prioritize
traffic properly.
• You may also need to enable VideoStream, Bonjour, CMX, and other
targeted solutions as appropriate for the individual customer.
Different wireless LAN models have different requirements. Client density and types affect
access point (AP) density, which in turn affects wireless LAN controller (WLC) density in a
wireless LAN design. Location-aware network designs have a different AP layout from that of
voice and data networks. Location-aware AP placement requires APs to surround the wireless
clients. When designing a wireless network, your first step should be to carefully examine with
your customer the expected usage of the wireless network in terms of user and device quantity,
type, location, mobility and expected applications. This information will help you choose the
right features and functionalities.
During the deployment phase, some features are almost always enabled, but some features
depend on the network type. The HTA Hospital example features a dense network of APs, and
users are expected to use Wi-Fi for critical and bandwidth-intensive applications. In this type of
deployment, you have to verify basic connectivity and coverage throughout the facility. You
would also make sure that the network downtime is reduced in case of AP or WLC failure by
implementing AP Stateful Switchover (SSO). You would also optimize the network RF
efficiency with Radio Resource Management (RRM), ClientLink, Band Select, and CleanAir.
Establishing an efficient security scheme is also necessary. The required security level depends
on the client type. The HTA Hospital example allows both employees (accessing confidential
data) and the general public to use the same wireless APs. In this type of deployment, you
should make sure that traffic isolation is set to avoid unauthorized users accessing confidential
information. This isolation can be done by segregating users on different VLANs, different
Service Set Identifiers (SSIDs), and assigning each type of user a specific set of access control
lists (ACLs) to determine the extent and type of access allowed for each user type. In a network
where the general public is expected, Wireless Intrusion Prevention Systems (wIPSs) can also
be implemented to identify and mitigate wireless attacks.
As Wi-Fi resources are limited by the extent of the usable spectrum, your next concern should
be to assign a quality of service (QoS) profile to each type of user, and determine how much
bandwidth can be allocated to each type of application. You should also build a QoS policy that
assigns different priority levels to each type of traffic.
Beyond the QoS classification that can be done on the WLC, you can also monitor more
carefully and control what usage is made of the Wi-Fi resources by implementing application
visibility and control (AVC). Depending on the deployment type and the user needs, you may
also enable specialized features, including the following:
 Cisco VideoStream to optimize video flows
 Bonjour gateway to allow Apple devices to communicate with one another across subnet
boundaries
 Connected Mobile Experiences (CMX) to leverage Cisco Microsoft Services Engine
(MSE) advanced location services
 Cisco Mobile Concierge capabilities to enhance the customer experience
References
 Cisco Prime Infrastructure Configuration Guide v2.0
Module Self-Check
Q1) The wireless LAN deployment architecture that typically best addresses customer
topologies with branch locations that have a small number of APs at each branch is
__________. (Source: Basic Wireless Connectivity and Functionality)
A) Autonomous
B) FlexConnect
C) Centralized
D) Converged Access
Q2) Which wireless AP is built on second-generation 802.11n technology and has a
modular design to adapt to forward-looking capabilities such as 802.11ac? (Source:
Basic Wireless Connectivity and Functionality)
A) OEAP 600
B) AP1600
C) AP2600
D) AP3600
Q3) Which of the following is the Cisco wireless functionality that best addresses issues
with cell overlap and channel reuse? (Source: Basic Wireless Connectivity and
Functionality)
A) Band Select
B) CleanAir
C) ClientLink
D) RRM
Q4) In a CUWN infrastructure, which combination of devices and/or features best
accomplishes high availability? (Source: Basic Wireless Connectivity and
Functionality)
A) IBN and MQC
B) IBN and N+1
C) N+1 and backup controllers
D) Backup controllers and AP SSO
Q5) What feature would you recommend to customers with high density deployments who
want to monitor spectrum consumption and manage the usage of network resources?
(Source: Additional Wireless Features)
A) ACL
B) AVC
C) Bonjour
D) CleanAir
Q6) Of the four possible schemes designed to provide quick recovery from a network
component failure, how many are capable of providing subsecond AP failover?
(Source: Basic Wireless Connectivity and Functionality)
A) 1
B) 2
C) 3
D) 4
Q7) Which three algorithms that run on the WLC are collectively known as Radio Resource
Management (RRM)? (Source: Basic Wireless Connectivity and Functionality)
A) __________________________
B) __________________________
C) __________________________
Q8) Cisco ClientLink implements what type of beam forming? (Source: Basic Wireless
Connectivity and Functionality)
A) Explicit
B) Implicit
C) Reciprocal
D) Spatial
Q9) The Cisco Band Select capability, which operates by regulating probe responses to
clients, requires which of the following radios to be active in order to function?
(Source: Basic Wireless Connectivity and Functionality)
A) Only the 2.4-GHz
B) Only the 5-GHz
C) Either 2.4-GHz or 5-GHz
D) Both 2.4-GHz and 5-GHz
Q10) Information about interfering devices that are present but not always active, and known
as persistent devices detected by a CleanAir-capable AP, can be passed to neighboring
non-CleanAir-capable APs. (Source: Basic Wireless Connectivity and Functionality)
A) True
B) False
Q11) Segmentation of wireless traffic may be accomplished by identifying user type, device
type, and/or __________. (Source: Wireless Network Security)
A) User ID
B) User interface
C) PEAP
D) EAP-FAST
Q12) Which type of ACL would override a WLC-defined ACL? (Source: Wireless Network
Security)
A) Interface ACL
B) Virtual ACL
C) SSID ACL
D) AAA ACL
Q13) As a guideline, for a security-conscious enterprise wireless customer in an indoor
building environment who expects to serve primarily 2.4-GHz devices, you typically
would place one wIPS AP at about every __________ square feet. (Source: Wireless
Network Security)
A) 85,000
B) 35,000
C) 30,000
D) 15,000
Q14) What elements were introduced with Alloy QoS profiles? (Source: Wireless Network
QoS)
A) Four metal levels
B) Static service levels
C) Combination metal levels
D) Three configurable priorities
Q15) What are the four access categories of WMM? (Source: Wireless Network QoS)
A) Voice, video, background (Gold), background (Silver)
B) Voice, video, best effort, background
C) Bronze, Silver, Gold, Platinum
D) AF11, AF21, AF31, AF41
Q16) For guest users, what is the common purpose of establishing QoS roles? (Source:
Wireless Network QoS)
A) Lower bandwidth within a QoS profile
B) Client CAC
C) SIP CAC
D) CAC
Q17) When transmitting multicast video over an AP, the channel __________. (Source:
Additional Wireless Features)
A) may reach maximum capacity
B) quickly reaches maximum capacity
C) never reaches maximum capacity
D) is not impacted by multicast video
Q18) Apple devices advertise their services via a ______ message on the local segment using
__________. (Source: Additional Wireless Features)
A) Unicast, IPv6
B) Multicast, IPv6
C) Unicast, IPv4
D) Multicast, IPv4
E) Unicast, both IPv4 and IPv6 simultaneously
F) Multicast, both IPv4 and IPv6 simultaneously
Q19) An installed wireless LAN that is not deployed in accordance with the best practices
for AP count and placement for a location-enabled network will still be able to utilize
CMX services. (Source: Additional Wireless Features)
A) True
B) False
Q1) B
Q2) D
Q3) D
Q4) D
Q5) B
Q6) A
Q7) DCA, TPC, CHD
Q8) B
Q9) D
Q10) A
Q11) A
Q12) D
Q13) B
Q14) D
Q15) B
Q16) A
Q17) B
Q18) F
Q19) A
Module 5
Converged Access Solution

Design Overview
Lesson 1
Converged Access Solution

Overview
Due to issues with traffic flows within the Unified Access network as well as the desire for
greater bandwidth capacity, the following are required:
 Deeper levels of traffic visibility and control
 Enhanced resiliency
 Increased security
 The addition of multicast video traffic to the patient rooms in the HTA Hospital
The administrator has determined a need to migrate the network over to a converged access
architecture. However, due to the requirement of the hospital network being available 24/7 -
this will necessitate the new converged network infrastructure to be configured and added in
parallel to the existing hospital network. This will minimize the possibility of downtime.
Configuration of network components will be done, after discovery into pseudo wire emulation
(PWE), through the One Management interface currently employed.
Topics covered will include the requirements needed to build the converged access portion of
the network and will serve to showcase features applicable to a converged access network.
The configuration process that is required to implement a converged access network utilizing
Cisco 5760 and Cisco 3850 devices, which will run in parallel to the previously established
network architecture, will be examined. All client access for this network will be controlled by
unified policies using SA-NET and Cisco Identity Services Engine (ISE).
Objectives
Upon completion of this module, the learner will be able complete the following:
 Design and configure a converged access solution using Cisco Catalyst 3850 Series
Switches and Cisco 5700 Series Wireless LAN Controllers (WLCs)
 Describe Cisco converged access best practices
 Describe ease of deployment mechanisms and solution differentiators available when
building the converged access wireless network
Solutions and Platforms Overview
This topic describes how wireless technology has evolved and how it affects network design.
Very High Density

Pervasive Media Rich Mission Critical
Casual
indoors Applications
CleanAir
Hotspot
System Management
Capacity
Self Healing
and Optimizing VXI Capable
© 2013 Cisco and/or its affiliates. All rights reserved. CONFIDENTIAL Converged Access Solution Design Overview UASEBC v1.0—5-5
The network infrastructure for the HTA Hospital has now been created and wireless access has
become an integral part of that network. The HTA Hospital network administrator can now
begin to analyze how wireless technology has evolved over the last several years. It is
important to understand wireless network usage based on the following:
 Users such as hospital guests use the wireless access as a casual wireless hotspot.
 Hospital staff use the wireless network for critical purposes.
Considering the increased number of wireless hospital devices, wireless access has become
mainstream for hospital communications and is becoming mission critical.
The network administrator recognizes that the hospital will need to implement technologies in
the access points (APs) to deliver a quality wireless connection. Technologies such as CleanAir
and ClientLink can be used to optimize the RF spectrum. These technologies have been
developed expressly to support the wireless network environment as it becomes more critical.
Nice to Have Pervasive Media Rich Applications Mission Critical
10Gbps
B AN D W I D T H
Future
802.11ac-2
3.5 Gbps
802.11ac-1
802.11n 1 Gbps
450 Mbps
/
CLIENTS 802.11g
802.11a, 802.11b 54 Mbps
11 Mbps
11Mbps
Early 2000 2002 2004 2006 2008 2010 2012 2014 …

The network administrator has also seen many new devices being used that connect to the
network wirelessly. The expectation is that the proliferation of wireless devices is going to
continue. At the same time, the administrator has seen a trend towards these devices becoming
mission critical and a move towards higher bandwidth requirements.
The state of the art for wireless technology today is 802.11n. It utilizes three spatial streams and
delivers 450 Mb/s. An emerging technology called802.11ac will be the next wave in wireless
bandwidth and wireless capabilities. That technology will emerge in two phases:
 Phase 1 will be 1 Gb/s wireless supply throughput.
 Phase 2 will be 802.11ac, which will have a throughput of 3 to 3.5 Gb/s.
As wireless network speeds increase, wireless devices access a network, transmit, and
disconnect faster. This saves battery life and causes batteries to last longer. Longer battery life
will be a major driver for the wireless vendors to adopt the new technology.
The following trends are seen in wireless networking:
 Greater mission criticality
 Increased number of wireless devices
 Greater and greater wireless bandwidths
When you think about these three things coming together in the environment, it is necessary to
think about what impact this will have on how wireless networks are designed.
When considering tablets, smartphones, and other such devices coming into the environment,
many of these devices do not even have an option to plug into a wired network, because they
are wireless only devices. In many enterprises networks, this constitutes two out of every three
new devices coming to the network.
Think about it, and choose the best answer
1 3 5 7
One consideration for the future of the hospital network is how many wireless devices users
may carry on them two years from now. The average answer the administrator gets when
asking that question is three. Some people will have one device to for everything. Most still
expect to be carrying a smartphone, a laptop, and a tablet three years from now.
Cisco Wireless
IOS Ba s e d W LA N C ontr ol le r LAN 5760
New Controller
Internal
• Consistent IOS and ASIC w/ Catalyst 3850 Resources
• Required to scale beyond 250 AP
or 16K client domains
One Network
C onve rge d A c c e s s M ode Corporate
Network Internet
• Integrated wireless controller
• Distributed wired/wireless data planeCisco Catalyst
Catalyst Switch 3850 Cisco Firewall
(CAPWAP termination on switch) Access Point
LAN Mgmt Access Control

Solution Server
One
WirelessPolicy
Control
System Identity NAC One Management
Guest
Server
© 2013 Cisco and/or its affiliates. All rights reserved. CONFIDENTIAL
ISE Mgmt Profiler
Prime Converged Access Solution Design Overview UASEBC v1.0—5-8
This figure shows the typical design for wireless networks. An AP (on the left-hand side,)
plugging into a Catalyst switch. The AP is typically deployed in a centralized mode. In that
mode it is generating a Control and Provisioning of Wireless Access Points (CAPWAP) tunnel,
from the AP, back through the Catalyst switch, and up through the wireless LAN (WLAN)
controller (depicted on the top).
Effectively, wireless networks operate as an overlay network on top of the wired network. The
wired infrastructure is implemented and then the APs are attached. The APs seek out and find
the controller when they boot up. They form a CAPWAP tunnel back to controller and get an
overlay wireless network on top of the wired network.
This methodology has worked well for a period of years. However, with the trends of
increasing number of devices, increasing amount of mission criticality, increasing bandwidth
requirements and everything going back to a central controller, there is now a bottleneck for
wireless devices.
A new deployment option called converged access has recently become available. It is not a
new architecture, but part of the existing wireless architecture offered by Cisco. It is a new
deployment option similar to FlexConnect and the centralized mode employed today. In this
new converged network option, all policy components are first converged. Instead of having a
number of different policy tools in a network, they are converged onto an ISE.
The management component offered by Cisco is Cisco Prime Infrastructure. The network
administrator has already been using this in the HTA Hospital network, centralizing policy and
management around these two components in the network.
A third step that could be taken is the option to take the WLC function and collapse it into the
switch. This is based on the new switch platform that the network administrator has installed,
which is a Catalyst 3850. This switch now has an integrated wireless controller.
Note that this is not the Catalyst 3750G with an integrated WLC. This is an integrated platform,
with a single IOS image, a single configuration file. It is a switch that is also operating as a full
partner in the wireless roaming mobility domain. It is acting as and integrated with existing
WLCs in the environment.
When we say that the 3850 operates as a WLC, the CAPWAP tunnel now terminates directly
on the switch itself. When the AP boots up, the only controller it sees is the switch port that it is
plugged into, upstream on the 3850. The controller terminates the CAPWAP tunnel, and by
terminating the CAPWAP tunnel directly on the switch, there are a number of benefits. You
will take a look at those benefits in more detail on the following pages.
Be aware, Cisco has also introduced a new WLC based on very similar technology to that
which is in the 3850. It is called the 5760. The 5760 controller implements the same IOS, the
IOS XE, and the same underlying ASIC capability that is found on the 3850. This allows us to
deploy the network in a centralized AP mode.
If a network engineer considers converged access but feels better served by the centralized
wireless design, you can ask the engineer to consider the scalability of converged access. For
example, the centralized option allows the network to scale from 8 Gb/s with the 5508 up to 60
Gb/s with the 5760. This is because Cisco went from a CPU-based design to a heavily ASIC-
based design. There is the same fundamental technology underlying both the 3850 and 5760.
Let’s consider the converged access mode and how it operates.
If, however, we peer all of the Mobility Controllers (MCs) with a Mobility Oracle (MO), the
MO function allows simplification and scale. This is because each of the controllers in the
environment only needs to connect to the MO and the MO gives full interconnectivity to each
MC. The MO is an optional component, typically only seen on the largest builds. The MO is
designed to allow the environment to scale.
The MO function is an outgrowth of existing wireless deployments. Therefore only two new
concepts have been introduced in our converged access environment: the switch peer group
(SPG) and the MO.
The SPG is another level of hierarchy in a mobility group allowing us to scale. The MO allows
us to scale the network inside the mobility group or between mobility groups.
Other functions such as the MA and MC exist in current wireless deployments and have for
years. They have not been discussed separately before. However they are now separate
functions and are the key elements in converged access networks.
Cisco Converged Access Deployment
Single Network wide Consistent Maximum Scale with

platform for visibility for security and resiliency with distributed wired
wired and faster Quality of fast stateful and wireless
wireless troubleshooting Service control recovery data plane
Common IOS, same Wired and wireless Hierarchical bandwidth Layered network high 480G stack bandwidth;
administration point, traffic visible at management and availability design with 40G wireless / switch;
one release every hop distributed policy stateful switchover efficient multicast;
enforcement 802.11ac fully ready
U n i f i e d A c c e s s - O n e P o l i c y | O n e Ma n a g e m e n t | O n e N e t w o r k
The figure lists benefits gained when you terminate CAPWAP tunnels directly from the AP to
the switch that has become a single platform for wired and wireless access. The wireless data is
terminated in the same place and at the same time in the network as the wired data.
Because the administrator has direct visibility to wired and wireless at the same time, the
administrator can obtain networkwide visibility for functions like troubleshooting. Every port
on the Catalyst 3850 can be NetFlow-enabled for example, both upstream ports and
downstream ports, for wired as well as wireless traffic. They get direct visibility into wireless
traffic flows, at the same place and the same time in the network that they get visibility for
wired flows.
Because it is a next generation switch, there are more advanced quality of service (QoS)
capabilities in the 3850. The administrator can apply security and QoS controls at the same
place in the same time in the network for all traffic because of visibility. Maximum resiliency
with fast, stateful recovery can be gained, because of stacking the 3850s very similar to the way
you would stack 3750-Xs. The resiliency of the stack can be leveraged for the benefit of wired
as well as wireless traffic.
Cisco is also introducing a next generation wireless controller 5760 that allows the data plane to
scale up to 60 Gb/s per controller. When it is required to scale beyond that level, Cisco will
move towards 802.11ac. Wave one and wave two with multiple gigabits of traffic is possible
per AP. The network can move to a distributed wired and wireless termination model as is
available with the 3850.
Underlying all of this is the focus on one policy, one management, and one network.
 One policy with ISE
 One management with Prime Infrastructure
 One network through the integration of wired and wireless
Visibility into Wired and Wireless Traffic at the Access
Understand bandwidth • Can monitor east-west and north-south flows

consumption by various • Natively available in the hardware
devices and applications
• 48K flows on the 48-port model
• Single flow monitor can be applied to wired ports and SSID
• Requires IP Base and above
• Actively working with PAM and third-party collector vendors
Detect anomaly in traffic flows for supporting key and non-key fields
Benefits of networkwide visibility with Flexible NetFlow include visibility into the wired and
wireless traffic at the access into the network.
This allows the network administrator to see bandwidth consumption by various devices and
applications. The administrator can also use Flexible NetFlow to detect anomalies in traffic
flows.
Flexible NetFlow has the following characteristics:
 Monitors east-west and north-south flows
 Natively available in the hardware
 Supports 48K flows on the 48-port model.
 Single flow monitor can be applied to wired ports and Service Set Identifier (SSID)
 Requires IP Base and above
 Actively works with Port-to-Application Mapping (PAM) and third-party collector vendors
for supporting key and non-key fields.
20+ Years of IOS Richness – Now on Wireless
WIRELESS WIRED
Features: Features:
• Centralized deployment • Stacking, StackPower
• L2/L3 Fast Roaming • Advanced Identity
• CleanAir • Visibility and Control
• VideoStream • Flexible NetFlow
• Radio Resource • Granular QoS
Management (RRM) BENEFITS • High Availability
• Wireless Security • EEM, Scripting
• Built on UADP – Cisco’s Innovative
• Radio Performance Flexparser ASIC Technology • IOS-XE Modular OS
• 802.11ac Ready • Eliminates Operational Complexity
• Single Operating System for Wired and
Wireless
The 3850 brings together the best of wired and wireless. This is the best wired, stackable switch
that Cisco has ever made. The switch includes event stacking and is a 480 Gb/s stack.
Also included is StackPower, which is patented by Cisco and allows a power pool to be shared
across all switches in the stack, similar to what is done in the 3750-X. The same power supply
is used as the 3750-X, however in this switch there is the following features:
 More advanced QoS
 Flexible NetFlow in every port
 Better high availability model
Cisco has implemented IOS XE, which is a modular operating system. This is the first
stackable switch ever with IOS XE and is the next generation IOS from Cisco.
Cisco has introduced an advanced platform for wireless as well and has taken the features and
capabilities of the WLC and integrated them directly into a switch that will continue to evolve.
The wired switch equivalency of this platform, as it is introduced, is equivalent to the
12.2(52)SE. From a wireless perspective, the wireless capability is equivalent to AireOS 7.0
MR1, maintenance release one.
Up to 50 APs/2000
Wireless CAPWAP Clients per Stack,
and 40G per Switch 480 Gbps
Termination Stacking Bandwidth
FRU Fans, Power

Up to 2000 Clients Supplies - HA
per Stack
Stackpower
Full POE+
Granular QoS/Flexible Multi-Core CPU

NetFlow
40 Gbps Uplink
Bandwidth
Line Rate on All Ports (Modular)
Built on Cisco’s Innovative “UADP” ASIC

Taking a closer look at the 3850, you see modular uplinks, modular power supplies, and
modular fans. Everything is replaceable in the switch in terms of those types of parts. With a
480 Gb stacking architecture, up to 50 APs and up to 2000 wireless clients can be terminated
per stack. The switch can also accommodate 20 to 40 G of wireless termination per switch in
the stack. This will allow 20 G of wireless termination for a 24-port switch and 40 G of
wireless termination on the 48-port switch. It is not necessary to terminate wireless on the
switch as a wireless pass-through can also be used.
• CAPWAP termination and DTLS in hardware

• Up to 40G wireless capacity per switch
• Capacity increases with members
• 50 APs and 2000 clients per switch stack
• Wireless switch peer group support for faster
roaming: latency sensitive applications Best-in-Class
Wired Switch –
• Supports IPv4 and IPv6 client mobility with Integrated
• APs must be directly connected to Catalyst 3850 Wireless Mobility
Functionality
An important thing to understand from a design perspective is that APs terminating CAPWAP
tunnels onto the switch must be directly connected to 3850. APs that are connected through
other switches, downstream, are not supported for terminating CAPWAP on the upstream
switch. The reason for this is that the QoS model on the switch is very sophisticated and makes
the assumption that the APs are directly connected. This QoS function can provide QoS
management down to the client, the AP, and down to the radio.
Centralized or Up to 1000 First IOS-Based Up to 12,000 Concurrent Clients

Converged Access Access Points Wireless LAN Controller
Deployment Modes 802.11ac
Optimized
6x 1/10G SFP+ 60 Gbps Wireless Bandwidth

uplinks with LAG Granular QoS
Flexible NetFlow
FRU Fans FRU Power Supplies
Built on Cisco’s Innovative “UADP” ASIC

The 5760 is the WLC counterpart to the 3850. If the network designer chooses a centralized
deployment mode, they can deploy the 5760 next generation WLC. The controller is also based
on IOS-XE and the UADP chip that Cisco has developed. It can terminate up to 1000 APs. This
controller has a total of 6x10 Gigabit Ethernet ports, and is capable of up to 60 Gb/s.
One Policy, One Management,
One Network N.A.A.S.
Unified Access Wireless Unified

Network
Autonomous FlexConnect Centralized Converged Public

(Private Access Cloud
Cloud)
Unparalleled Deployment Flexibility Ease of Use

As shown in the figure, converged access is another deployment option that is available. Cisco
is not terminating any other deployment options in the wireless network environment. Those
options continue to be the right answer for certain types of clients.
For example, there is a percentage of customers that still deploy autonomous APs, standalone
APs. The majority of Cisco customers have moved to controller-based designs. However, Cisco
still has some customers where autonomous options are the right answer. Many customers
deploy FlexConnect and centralized wireless deployment modes today as well. Cisco continues
to build upon and enhance all three of those modes.
Cisco is introducing a fourth deployment option, converged access, because of bandwidth
scaling, number of clients scaling, and so forth. Cisco offers this as a deployment option to
allow networks to scale out. As you look at where wireless is going to go over the next several
years, converged access starts to become a relevant deployment option for customers.
The option shown on the extreme right-hand side of the figure, which is called public cloud, is
Meraki. Cisco acquired Meraki to be its public cloud offering. Though not discussed here,
Meraki is a network service option.
Architecture and Components Review
This topic covers the network architecture.
System Architecture
Roaming, QoS, Security
Corner Mcast, Design, Migration
Stones
Foundational Elements
for the Converged Access Solution
The foundational elements of the system architecture are the following:

 Roaming
 QoS
 Security
 Design
Once these elements are understood, you will be able to design a network with converged
access and understand how the elements function.
Increased Scalability, Centralized Policy Application
We’ve Been Here Before…
Control plane functionality on NG Controller
Centralized tunneling of user traffic to
controller (data plane and control plane) (also possible on upgraded 5508s, WiSM2s
for brownfield deployments, or NG Converged
System-wide coordination for channel Access switches for small, branch deployments)
and power assignment, rogue detection,
security attacks, interference, roaming
Hotspot Cisco
deployments with Controller Converged
nomadic roaming Functionality
Access
split with
CAPWAP
Standalone Cisco
Access Point Unified Data plane functionality on NG Switches
Wireless
(also possible on NG Controllers, for deployments
in which a centralized approach is preferred)
Autonomous Access Point • Unified wired-wireless experience

(security, policy, services)
Mode Frees up the AP to focus on real-time
communication, policy application and • Common policy enforcement, common
optimize RF and MAC functionality such services for wired and wireless traffic
as CleanAir, ClientLink (NetFlow, advanced QoS, and more)
Scale and Services Performance and Unified Experience

Several years ago, autonomous mode APs were available. That effectively means you had
standalone APs, hotspots, and nomadic roaming. Wireless was just a network of convenience.
This was an implementation for very small deployments. In this deployment model, for
example, you had an office with three or four users. This is still a perfectly viable deployment
mode today. However, a transition happened in the industry several years ago called scale and
services.
Scale means that you needed to scale up the number of APs, from a few dozen up to hundreds
or even thousands of APs in some cases. You also need to start offering services on the wireless
networks. Most of these services include services such as CleanAir for the RF base or
ClientLink for improving radio reception out to users, Radio Resource Management (RRM), as
well as channel and power assignment for APs. This became very challenging when there were
hundreds or thousands of standalone individual APs needing to be managed, each with their
own configuration file, their own software image, and so forth.
The technical answer for this was to go to a controller-based architecture, referred to as a split
MAC architecture. In this architecture, Cisco allows the AP to do what the AP does well, for
example: RF, CleanAir and ClientLink. Those capabilities are still performed by the AP.
Everything else is centralized in the controller.
Cisco centralized the data plane by CAPWAP tunneling all the data from the AP to the
controller. This centralized the control plane of the network as well. The control plane performs
functions like RRM, channel and power assignment, security detection, interference detection,
rogue detection, and roaming. Cisco is now giving customers the option to take the capability
running on the controller and split that into two pieces—a control plane and a data plane.
The control plane is the function that runs on a next generation controller like a 5760. It can
also run on today’s controllers, 5508 or Wireless Service Module 2 (WiSM2) with the
appropriate software upgrade (that would be the 7.3 MR1 capability in the network). That
control plane can also run on the 3850 switch for various small to midsized deployments, up to
50 APs or 2000 clients.
Existing Unified Wireless Deployment Today
Data Center /
Service block
PI
Internet
ISE
Intranet
Mobility EoIP Mobility Tunnel ( < 7.2) Well-known,
Group CAPWAP Option in 7.3 proven
architecture
Foreign WLC
WLC #1 “Guest” Anchor
WLC #2
Inter-Controller (Guest Anchor)

EoIP / CAPWAP Tunnel
LEGEND
Inter-Controller
EoIP / CAPWAP Tunnel
Encrypted CAPWAP
(see Notes) Tunnels
AP-Controller CAPWAP Tunnel
802.11 Control Session + Data Plane
Notes –
• AP / WLC CAPWAP Tunnels are an IETF Standard
AP AP AP AP
• UDP ports used –
• 5246: Encrypted Control Traffic
SSID – VLAN • 5247: Data Traffic (non-Encrypted or DTLS Encrypted (configurable)
Mapping • Inter-WLC Mobility Tunnels
(at controller) • EoIP – IP Protocol 97 … AireOS 7.3 introduces CAPWAP option
• Used for inter-WLC L3 Roaming and Guest Anchor
SSID2 SSID1 SSID3
To understand this architecture, begin by looking at a campus network. On this network

diagram, red represents routed and blue bridged. There are access layer switches on the bottom
with Layer 2 trunks going up to distribution layer switches in the middle with Layer 3
termination and routing. This is a typical three-tier architecture, which is a very simple,
straightforward design.
Additional elements on the diagram include the WLC, WLC #1, and some APS on the bottom;
with wireless clients connected. The clients are connecting in with SSID1. There are CAPWAP
tunnels coming back from the APs to the WLC. The yellow lines on a network diagram
illustrate the CAPWAP tunnels. The blue line going out from WLC toward the switch is a
VLAN that is associated with the CAPWAP tunnel the user’s data are coming back on. The
SSID is mapped to that blue VLAN.
Notice that you can add in another WLC, either for scale or redundancy. There is a similar set
of VLANs going to that controller. These controllers are grouped together into a mobility
group. The mobility group automatically manages roaming and related functions that happen
inside the controller.
In converged access, some of the functions that run on that controller are going to move down
onto the switch. Therefore, you need to look at what is happening inside the mobility group in
more detail. You also need to start giving names to some of the things that run inside the
controllers so that you can differentiate what still runs on the controller, what runs on the
control plane, and what runs in a data plane down in the switches.
When a mobility group is formed, one of the things that happens automatically is that the
controllers build an EoIP or a CAPWAP tunnel between themselves. This is done with a full
mesh being created between all controllers. If you are running RF versions prior to 7.2, then
that would be an Ethernet over IP (EoIP), IP protocol 97 tunnel. If it is 7.3 or above, you have
the option to run a new mobility mode, which is done with a CAPWAP tunnel
Very often, networks do include guest anchor controllers and in this network you are going to
take each one of these controllers and point it towards the guest anchor. This is indicated by a
gray line through the gray tunnels going from the controllers to the guest. The point of a guest
anchor tunnel is to drop users’ data off the firewall, take it out to the intranet, and give the guest
secured guest access from the enterprise.
Also seen are multiple SSIDs that are mapped to VLANs within the network.
Data Center /
Service block
PI
Internet
ISE
Intranet
Mobility EoIP Mobility Tunnel ( < 7.2)
Group CAPWAP Option in 7.3
MA
MC
Foreign WLC
MA WLC #1 “Guest” Anchor
WLC #2 MA
MC
MC
MA Mobility Agent
LEGEND
Terminates CAPWAP Tunnels,
Maintains Client Database
CAPWAP MC Mobility Controller
Tunnels
Handles Roaming, RRM, WIPS, etc.
AP AP AP AP
Additional
details on
controller
functionality
These will become important later

as we delve into the Converged Access deployment …
SSID2 SSID1 SSID3
There are now two functions that run on the controllers, Mobility Agents and Mobility
Controllers.
Normally, these functions are not discussed separately, because they are capabilities that run in
the controller. These are fundamental concepts regarding how converged access is built.
The MA has a responsibility to terminate CAPWAP tunnels. It also maintains the client
database. If there are thousands or tens of thousands of clients associating, de-associating,
roaming, moving around in your environment, maintaining the client database is one of the jobs
of the MA function. This MA function is going to move down onto the switch and the switch is
going to become a full partner in roaming mobility domain.
The MC manages items such as roaming, RRM, and wireless intrusion prevention as well as
others. These are functions that, by their nature, only make sense on a systemwide basis. They
are run by the MC function.
Mobility Domain MO ISE PI
Mobility Group
MC MC
Sub-Domain Sub-Domain
#1 #2
SPG SPG
MA MA MA MA MA MA
Shown in the figure is a standard campus deployment, which shows Layer 2 access, Layer 3
distribution, Layer 3 core, users coming in at the bottom, attaching to APs. The first major
difference is that the CAPWAP tunnels terminate on the switch itself.
The network is still running CAPWAP between the AP and the switch for a variety of reasons.
CAPWAP still carries a lot of the 802.11 information that is needed; however, the CAPWAP
tunnel is terminated directly on the ingress switch port. This drives all the benefits that were
previously mentioned. Now the network administrator can get direct visibility and direct
control over wireless traffic in the same place, at the same time as wired traffic in the network.
This makes the two traffic types co-equal in terms of the services that can be offered.
CAPWAP tunnel termination directly on the switch is the first big change. And because the
CAPWAP tunnel is terminating there, the MA function now needs to run on each switch.
Because of that, another new item—SPG—has been introduced. The function of the SPG is to
form a logical grouping of switches designed to localize roaming events. Typically a network
designer would build an SPG around a building or floors within a building. This is a logical
construct and will be discussed in more detail.
The SPG can be thought of as introducing another level of hierarchy into a mobility group,
because of the functionally it gives. This introduces a level of hierarchy into an otherwise flat
mobility group that allows us to scale networks.
It is also possible to group SPGs. A grouping of one or more SPGs under the control of a single
MC will constitute a subdomain. The network can have one MC managing a single SPG, or the
same MC can manage multiple SPGs. SPGs that are grouped under one MC constitute a single
mobility subdomain.
Keep in mind that when grouping controllers, two or more MCs can be grouped together into a
mobility group. This is not a new capability but rather it is the same capability that has been
built and used for years.
Another new function that has been introduced is the MO. In the environment where you have a
group of MCs you also have the requirement that the controllers be fully meshed. This is fine
when there are only two or three controllers. However, as it becomes necessary to scale that
environment, maintaining a full mesh becomes problematic. This becomes a traditional N-
squared problem.
Physical Entities –
• Mobility Agent (MA) – Terminates CAPWAP from AP, manages client database
• Mobility Controller (MC) – Manages mobility within and across sub-domains
• Mobility Oracle (MO) – Superset of MC,
allows for scalable mobility management within a domain
Logical Entities –
• Mobility Groups – Grouping of Mobility Controllers (MCs)

to enable fast roaming, Radio Frequency Management, and so on
• Mobility Domain – Grouping of MCs to support seamless roaming
• Switch Peer Group (SPG) – Localizes traffic for roams within distribution block
MA, MC, Mobility Group functionality all exist in today’s controllers (4400, 5500, WiSM2)
In the converged access network there are two different types of entities: physical entities and
logical entities.
Physical entities run on physical boxes. Examples are the MA, MC, and MO. These are things
you can feel and touch. These are physical boxes that run specific functions.
Logical entities are logical groupings you make in the environment. In wireless, these are
things like mobility groups and mobility domains. The new item Cisco has introduced is the
concept of an SPG, which assigns localized traffic in the roaming scenario. This terminology
has previously existed in wireless networks.
Best-in-Class
Wired Switch –
with Integrated
Wireless Mobility
Functionality
MA • Can act as a Mobility Agent (MA)

for terminating CAPWAP tunnels for locally connected APs …
MC • as well as a Mobility Controller (MC)

for other Mobility Agent (MA) switches, in small deployments
- MA/MC functionality works on a Stack of Catalyst 3850 Switches

- MA/MC functionality runs on Stack Master
- Stack Standby synchronizes some information (useful for intra-stack HA)
The 3850 stack can now be an MA. It is important to remember that if multiple switches are
stacked together, they do not behave as multiple separate MAs. Once stacked, they behave as
one logical stack, and they will all act as one MA. Remember, MA function terminates the
CAPWAP tunnels from the locally attached APs. For small to mid-sized deployments, this can
be up to 50 APs or 2000 clients and in some cases can scale bigger than that.
The 3850 stack can also be used as the MC. This allows wireless designs to be deployed that do
not have any discrete controller. This is for small to midsized deployments consisting of
switches alone.
Sub-Domain 1
SPGs are a logical construct, not a physical one …
SPG-B
SPGs can be formed across Layer 2 or Layer 3 boundaries
SPGs are designed to constrain roaming traffic to a
MA MA
smaller area, and optimize roaming capabilities and
MC
SPG-A performance
MA MA
Current thinking on best practices dictates that
SPGs will likely be built around buildings,
around floors within a building, or other
areas that users are likely to roam most within
• Made up of multiple Catalyst 3850 Roamed traffic within an SPG moves directly
switches as Mobility Agents (MAs), between the MAs in that SPG (CAPWAP full mesh)
plus an MC (on controller as shown) Roamed traffic between SPGs moves
via the MC(s) servicing those SPGs
• Handles roaming across SPG (L2 / L3)
• MAs within an SPG are fully-meshed Hierarchical
(auto-created at SPG formation) architecture
is optimized for
• Fast Roaming within an SPG scalability and
• Multiple SPGs under the control roaming
of a single MC form a Sub-Domain
An SPG consists of multiple 3850 switches or switch stacks, each one acting as its own MA. As
mentioned previously, there always has to be the MC function somewhere in the network. Here
it is shown running on a discrete controller, but that MC function could, for small deployments,
be running on one of the switch stacks.
The function of an SPG is to localize roaming across the SPG. The functions are as follows:
 The MAs boot up, they are pointed via one line of config to a corresponding MC.
 The MC will then tell all the MAs about each other, and the MAs will form a full mesh of
CAPWAP tunnels that run between them. The full mesh is automatically created and it is
not created on demand. It is also automatically created when the SPG is formed and when
the switches boot.
The SPG manages fast roaming within the SPG, so as clients roam from switch to switch, the
MC distributes the user’s pairwise master key to all the other MAs within the SPG. Pairwise
master keys are created when a user authenticates into the wireless network. If the MC
distributes the key to all of the MAs in the SPG, as the client roams from AP to AP, from
switch to switch, they do not have to reauthenticate as you roam, and it speeds up the roaming
times dramatically.
It is very important to understand what a roam is. A roam is a movement of a device when the
device is actually on the move while connected to the network. For example, if a user has a
smartphone, and is using a VoIP client on it, if the user is walking around the building and they
roam from AP to AP—that is a true roam.
However, if the user is using something like an iPad, and they close the smart cover (which
effectively puts it into a sleep mode) within a couple of minutes, if they don’t open the cover
again, the iPad will actually disconnect from the wireless network.
If the user roams within the building, or perhaps between buildings, and opens the iPad several
minutes later, then the device will actually authenticate to the network as a new device. That is
not a roam. The device is dropping off of the wireless network and subsequently reconnecting
to the wireless network.
SPGs are typically constructed around areas within a network where users are most likely to
roam. This is used for constraining traffic below the distribution layer for the roam. Roam
traffic within an SPG moves directly from MA to MA within that SPG. It does not need to
move through the MC in that case.
Sub-Domain 1 Sub-Domain 3
SPG-B SPG-E
MA MA MA MA
MC MC
SPG-A SPG-F
MA MA MA MA
Mobility
Group
• Made up of multiple Catalyst 3850 MC

• Made up of Multiple
switches as Mobility Agents (MAs), Mobility Controllers (MCs)
plus an MC (on controller as shown) SPG-C • Handles roaming across MG (L2 / L3)
• Handles roaming across SPG (L2 / L3)
MA MA • RF Management (RRM) and Key
• MAs within an SPG are fully-meshed SPG-D Distribution for Fast Roaming
(auto-created at SPG formation) • One Mobility Controller (MC) manages
MA MA
• Fast Roaming within an SPG the RRM for entire Group
Sub-Domain 2
• Multiple SPGs under the control • Fast Roams are limited to
of a single MC form a Sub-Domain Mobility Group member MCs
The network can still have multiple MCs, if they are in a bigger environment. Those can be
grouped together in a common mobility group. A mobility group is similar to ones used today.
They manage all the functions that a mobility group typically does, such as RRM and key
distribution. Cisco has introduced another level of hierarchy among the mobility groups.
For Your
Reference
As with any solution, there are scalability constraints to be aware of.

• These are summarized below, for quick reference
Scalability 3850 as MC 5760 5508 WiSM2
Max number of MCs in a Mobility Domain 8 72 72 72
Max number of MCs in a Mobility Group 8 24 24 24
Max number of MAs in a sub-domain (per MC) 16 350 350 350
Max number of SPGs in a

8 24 24 24
Mobility sub-domain (per MC)
Max number of MAs in a SPG 16 64 64 64
Max number of WLANs 64 512 512 512
The following scalability constraints should be considered.

 There can be up to eight SPGs under the control of a single 3850 operating as an MC per
SPG.
 Each one of those SPGs can have up to 16 MAs or 16 switch stacks. This could consist of
the 3850 based MC itself, plus up to 15 others.
Large environment can be built using 3850s only as MCs. However, when the network needs to
approach those limits or scale larger, typically a discrete controller is required such as an MC,
5760, 5508, or WiSM2. The scalability numbers with this are significantly larger because there
is a lot more CPU and a lot more memory in those discrete controllers than is available on an
access switch.
Roaming
This topic describes additional concepts related to roaming.
MC MA MC MA
WiSM2s /
5508s PSTN
PoP
PoA
CUCM
Point of Presence (PoP) vs.

Point of Attachment (PoA) –
• PoP is where the wireless user
is seen to be within the wired
portion of the network
• Anchors client IP address
• Used for security policy application
• PoA is where the wireless user
has roamed to while mobile
• Moves with user AP connectivity
• Used for user mobility and QoS
policy application
Additional concepts that need to be introduced are point of presence (PoP) and point of
attachment (PoA).
The PoP is where the wireless user is seen to be within the wired portion of the network. If this
wired network Address Resolution Protocols (ARPs) for that wireless user, it sees that wireless
user as being at the end of the dot1q trunk that comes from the switch and points towards the
controller. As far as the wired network is concerned, that is the wireless user location. You
know the wireless user is roaming somewhere, but from the wired network’s point of view, the
user is at that wireless controller, on its dot1q trunk.
The PoP is used in several ways. First of all, it anchors the client IP address. As the client
moves around from AP to AP, they might move across wired subnets. The network needs to
keep the wireless user on the same subnet, the same IP address as they roam. If their IP address
were to change, on a VoIP call for example, the IP address would change mid-call, and the
user’s connection and all his applications are going to break. The network uses the PoP concept
to anchor the client IP. Regardless of where the client roams, they keep the same IP address.
The network also, incidentally, uses it for applying a security policy. Security ACLs are applied
at the PoP.
The other concept to be discussed is PoA. Point of attachment is where the user has roamed to
while they are mobile. As they roam, the PoA may move from controller to controller for
example, where as the PoP typically would stay fixed. This is used for AP client activity and
used for remote user mobility and also to apply the QoS policy for the user at the PoA, as
opposed to the PoP.
Separate
policies and
services for wired
MC MA MC MA and wireless
WiSM2s /
5508s users
PoP PSTN
PoA
CUCM
Traffic Flows,
Unified Wireless –
Wireless policies • In this example, a VoIP user is on
implemented today’s CUWN network, and is
on controller making a call from a wireless
handset to a wired handset.
• We can see that all of the user’s
The same traffic needs to be hairpinned
traffic paths are back through the centralized
controller, in both directions.
incurred for voice,
video, data, etc. – In this example, a total of 9 hops
all centralized are incurred for each direction
of the traffic path (including the
controllers – Layer 3 roaming
Wired policies
implemented might add more hops).
on switch
In today’s architecture, such as our HTA Hospital example, there could be a wireless user,
wireless handset, and a wired phone making a phone call to each other. The way that this traffic
flow would work today, the wireless user has their PoP, PoA at the controller. The traffic would
flow up to the PoP, up to the controller, across the CAPWAP tunnel, and get terminated at the
controller. It would then be de-encapsulated and moved as IP traffic to the wired phone. The
traffic path would flow as shown in the figure. This would represent a total of nine hops in the
network—four switch hops up, four switch hops down in this particular network, plus the
controller would be a hop because it is processing in the packet.
This is a very functional architecture and many customers have this deployed. However, all the
wireless traffic is centralized in this architecture and there are scaling limits with that. As the
move is made toward 802.11ac and an increasing number of wireless clients, it is necessary to
scale and keep scaling the wireless controllers on the back end.
Another consideration is having separate policies and services for wired and wireless users. For
example having policies for the wired phone—802.1X, security policies, access control lists
(ACLs), QoS applied on the wired port. You also have a totally different set of capabilities and
functionality (usually a lesser set) applied on the WLC. There are separate policies applied at
separate places in the network. There is no visibility to the wireless traffic as it flows across the
backbone until it emerges from the CAPWAP tunnel.
Data Center-DMZ
Guest Anchors
Data Center Campus MC MA
Internet
Campus Services
Si MC MA
Si
ISE
• Initially, the user’s PoP and PoA

Si
Si
PI are co-located on the same controller
PI
Si Si • Note – in this deployment model, it is assumed

that all of the controllers across the campus
PoP do not share a common set of user VLANs
MC Layer 3 at Layer 2 (that is, the controllers are all L3-
PoAMA MC MA
Si
Mobility separated)
Si Si
5508 / Si 5508 / Group
WiSM-2 WiSM-2 • Initially, the user’s traffic flow is as shown
Campus
Access
This illustration shows a user and their PoA and PoP. These points are on an AP that is
controlled by the controller on the left-hand side of the diagram. In this case, there are two
controllers grouped together in a common mobility group.
These two controllers are plugged into two different sets of distribution layer switches. The
left-hand controller is plugged into the left-hand set of distribution switches; the right-hand
controller is plugged into the right-hand set of distribution switches. This implies that these two
controllers cannot share a common set of back-end VLANs. They are sharing the same SSIDs;
however, those SSIDs are mapped to different VLANs on their respective switches. Because
the distribution switches to which the controllers are attached are separated by a routed core the
traffic does not flow across the same forwarding VLANS. The traffic flows as shown in the
diagram.
Symmetric
Data Center-DMZ Mobility
Guest Anchors
Data Center Campus MC MA
Internet Tunneling
Campus Services
Si MC MA
Si
ISE
•
Si
Si
Now, the user roams to an AP managed by
PI a different controller, within the same
PI
Mobility Group
Si Si
• The user’s PoA moves to the new controller

PoP managing that user after the roam – but the
MC Layer 3 user’s PoP stays fixed on the original
PoAMA MC MA
Si
Mobility controller that the user associated to
Si Si
5508 / Si 5508 / Group
WiSM-2 WiSM-2 • This is done to ensure that the user retains
the same IP address across an L3 boundary
Campus roam – and also to ensure continuity of policy
Access
application during roaming
• After the roam, the user’s traffic flow is as
shown
Before roaming, the traffic would come in, across the CAPWAP tunnel, get de-encapsulated
and moved out to the network as Ethernet and IP traffic. If the user does not roam, this is their
traffic profile.
All roams in converged access look like a Layer 3 roam by default. As the user roams, the PoA
moves, but the PoP stays. The explanation for this is that the IP address of the user, the pool
their IP address was pulled from, is only valid on the left-hand side of this network. Those
subnets only exist on the left-hand side of the network, and therefore, the PoA can move if the
user’s PoP needs to be fixed.
The traffic flow for the user is going to appear as follows: The user’s traffic is going to be sent
to the controller to which they have roamed. The AP to which they have roamed happens to be
controlled by a different controller. The traffic is going to enter through the PoA switch, it is
going to move across the full mesh of CAPWAP tunnels that have been built in the mobility
group and then to their PoP controller. From there, it is going to get de-encapsulated and moved
out to the network.
From the wired network’s point of view, this user has not moved, they have remained fixed
even though a mobility event has occurred. As you understand this concept, you understand
how roaming works in today’s wireless architecture. You will understand that roaming in
converged access works this same way. However, this is being done on the switches with an
extra level of hierarchy, with the SPGs as opposed to doing this same function on the
controllers.
What is being done in a converged access network is an outgrowth of what is being done in the
traditional wireless architecture.
Converged
policies and
services for wired
and wireless
MC MA MC MA
WiSM2s / users
5508s / 5760s PSTN
CUCM
Traffic Flows, Comparison
(Converged Access) –
• Now, our VoIP user is on a Cisco
Converged Access network, and is
again making a call from a wireless
Traffic
handset to a wired handset …
does not
flow More efficient • We can see that all of the user’s
via MCs since traffic flows traffic is localized to their Peer
are localized to Group, below the distribution
the 3850 switch – layer, in both directions …
Performance
Increase In this example, a total of 1 hop
SPG is incurred for each direction
PoP
of the traffic path (assuming
PoA no roaming) … two additional
Wired and
wireless policies
hops may be incurred for routing …
implemented
on 3850 switch
There are benefits that come with this change. As you can see, the MA function has moved
down onto the switches in the converged access deployment. The MA terminates the CAPWAP
tunnel, and maintains the client database. Now this happens on the switches.
In the new model, the user associates into the network. The wireless user handset, its PoA, and
PoP are now on the switch. The user traffic is going to flow to the PoA and PoP on the switch,
then to the user’s PoP. There the data will be de-encapsulated and forwarded to the wired
device, which in this case, is connected to the same switch. Notice how much simpler this
traffic profile is. Rather than having the traffic move all the way back across the network from
centralized controllers, it is managed directly on the switchboard. This results in one switch
hop, instead of nine switch hops.
Benefits are derived from this type of traffic managing. First of all, notice how in this
environment, the MC is operating as a control plane only. For this type of environment,
effectively, the data plane termination is done on the switch. The traffic does not flow via the
MCs. This is a big part of your traffic profile. Devices associate to a wireless network and they
remain stationary.
Since traffic does not flow via the MCs in this mode it is highly optimized versus what was
seen before. Because of this the network achieves a performance increase. Also there is a
convergence of policies and services. The same policies and services used for the wired traffic
will now be applied to the wireless traffic. ACLs, QoS, and NetFlow are all at the same place
and same time for wired and wireless traffic.
Very
Notice how the 3850 switch stack common
shown is an MC (as well as an MA). roaming
In a branch such as this with 50 APs Central Location MC case
ISE PI
or less, no discrete controller is MA
necessarily required.
WAN
Guest Anchor Roaming
CAPWAP tunnel
to Guest Anchor DMZ across stack
CAPWAP
tunnels – (small branch)
control and 3850
data path Switch Roaming,
MC MA
PoP Single Catalyst 3850 Switch Stack
PoA
• In this example, the user roams within their 3850-based switch stack.
For a small Branch site, this may be the only type of roam.
Roaming within a stack does not change the user’s PoP or PoA –
since the stack implements a single MA (redundant within the stack),
and thus a user that roams to another AP serviced by the same stack
does not cause a PoA move (PoA stays local to the stack).
In this example, you have a single switch or a switch stack. Remember that the switch can also
act as MA as well as MC. In this illustration there is a PoP and PoA on the switch. Traffic
enters, terminates on the switch, and is moved out to the network. When the user roams to
another AP that is managed by the same stack, the PoA moves to another port within the same
switch stack. From the point of view of the wired network, nothing has changed.
This might be the only type of roam that will occur in a small branch that is served out of one
switch stack. This is a very common roaming case.
Roaming
across stacks
Very (larger branch)
common Roaming, Within a Switch
roaming
case
Peer Group (Branch)
• Now, let’s examine a roam at a larger branch, with multiple
3850-based switch stacks joined together via a distribution layer
uRPF, Symmetrical
Routing, NetFlow, • In this example, the larger branch site consists of a single
Stateful Policy Switch Peer Group – and the user roams within that SPG –
Application again, at a larger branch such as this, this may be
the only type of roam
The user may or may not have roamed across an L3

SPG boundary (depends on wired setup) – however, users are
MC MA MA MA
always* taken back to their PoP for policy application
PoP
PoA Overall observation * Adjustable via setting,
Again, notice how the 3850 switch stack on the may be useful for L2 roams
This looks exactly the same as a Layer 3
left is an MC (as well as an MA) in this picture –
inter-controller
in a larger branch such as this with 50 APs roam in CUWN
because
or less, no discrete controller it is exactly
is necessarily the same
required … process,
but is distributed, rather than centralized
The figure is an example of a more complex roaming design. This design is still using the 3850
as the switch stack in the environment. One of the switch stacks is operating as both MA and
MC; the other stacks are operating as MA only. The MC, the control plane, is one of the switch
stacks that is designated as the MC. This is very simple to configure with only a couple lines of
IOS config commands.
A user device attaches to the network. This user has not roamed yet. Half of it is being
controlled by the switch on the right-hand side of the network drawing. Both the PoA and the
PoP are there. The IP address they received is from a subnet associated with the switch. When
the user roams, the PoA moves to the switch that is managing the new AP. However, their PoP
stays fixed on the switch on which they originated—their origin switch. The switch they roam
to is called the foreign; the switch they roam from is referred to as the anchor.
Looking at the traffic flow, notice that the traffic comes into the switch at the PoA. All of the
switches within an SPG automatically form a full mesh of CAPWAP tunnels to each other.
This happened automatically when the SPG was built. Therefore the traffic is going to flow
across one of the prebuilt CAPWAP tunnels to the PoP switch where it will be de-encapsulated
and moved out to the network. Again there is a wireless roaming event, but from the wired
network’s point of view, the user has not moved. This looks just like a Layer 3 roam in the
traditional wireless architecture.
The network can also use a function called Layer 2 roaming. The administrator can disable the
behavior just described so that both PoP and PoA would move on a roam. That does have
various implications which will not be explored in this course.
Roaming,
Less MC Across SPGs (Campus) –
common
• Now, let’s examine a few
roaming
more types of user roams
case
• In this example, the user
Roaming roams across Switch Peer
across SPGs Groups – since SPGs are
(L3 separation typically formed around floors
assumed at or other geographically-close
access layer) areas, this type of roam
is possible, but less likely
than roaming within an SPG
SPG SPG
MA MA MA MA MA MA Typically, this type of roam
PoP will take place across an L3
PoA boundary (depends on wired
setup) – however, users are
always taken back to their
PoP for policy application
The figure represents a more complex type of roam. This roam is probably a subset of
examples. This would represent the 1 percent use case on roams. In this case it is possible that a
user could roam between two different buildings that are in two different SPGs. This still works
completely seamlessly.
This example includes roams from a switch in SPG on the left of our network diagram to a
switch in SPG on the right. Again, the PoA will move with the user; their PoP will stay fixed.
However, the SPGs are only fully meshed within themselves. There is no direct connection
from SPG left to SPG right. The purple lines represent the control path. CAPWAP tunnels run
from all the MAs up to the MC. The MC controls the roaming function in this solution on a
discrete controller. All of the switches are pointing at their MC. They all have control path
CAPWAP connections up to the MC. This path can also be used for transferring data across the
network in the event that this type of roam occurs.
In this environment, the user’s traffic will enter the switch they have roamed to—their foreign
switch. The foreign switch will realize that traffic needs to go to a different SPG. Therefore, it
will send the traffic across the control path connection to the MC. The MC will bridge the
traffic to the PoP switch where, again, it will get de-encapsulated and moved out to the
network.
In this particular case, and only in this case, this traffic actually flows through the MC on a
roam. Typically this type of roam would be a small subset of the roams that would be seen in
the environment. It is important to understand how it works and that it does work seamlessly.
Overall view –
MC
across the entire
10.125.11.14 Sub-Domain
controlled by
the MC
L09-5760-1# show wireless mobility controller client summary
Number of Clients : 5
State is the Sub-Domain state of the client.

* indicates IP of the associated Sub-domain
Associated Time in hours:minutes:seconds
MAC Address SPG 10.101.1.109 Anchor IP

State SPG 10.101.6.109
Associated IP Associated Time
--------------------------------------------------------------------------------
MA MA MA MA MA MA Roamed client, Switch 1 to Switch 6 (inter-SPG)
001e.65b7.7d1a Local PoP 10.101.1.109 10.101.6.109 00:04:36 Stationary client, Switch 7
b817.c2f0.61b2 Local 0.0.0.0 PoA
10.101.7.109 00:21:07 Roamed client, Switch 3 to Switch 1 (intra-SPG)
74e1.b65a.a8f3 Local 10.101.3.109 10.101.1.109 00:03:27 Stationary client, Switch 1
cc08.e028.6fdd Local 0.0.0.0 10.101.1.109 00:04:57 Stationary client, Switch 3
a467.06e2.813d Local 0.0.0.0 10.101.3.109 00:02:56
It is not necessary to troubleshoot on a switch-by-switch basis to understand or even get a

snapshot of what the roaming looks like in the domain. You can go to the MC and enter the
command:
show wireless MC compliance summary
This will display a snapshot of roaming across the entire domain.
There is a roamed client on top—in this case, roamed from switch 1 to switch 6. They started
off on their anchor switch of 1.109, that is the management AP of the switch and their roamed
to, or their associated AP, now is the 6.109 switch. This is an inter-SPG roam. On the next
roam, the user started on a 3.109 switch and roamed to the 1.109 switch.
In this topology, that is an intra-SPG realm. You can check out these three clients that have an
anchor stated as quad zero. These are users that have simply not roamed yet. They have
associated into the network on their associated IP. You can see they are controlled by those
switches and they have not roamed. This entire snapshot is available by going to the MC and
entering the show command.
For Your
Reference
There are multiple additional roaming scenarios

• These replicate the traffic flow expectations seen elsewhere with converged access
• Traffic within an SPG flows directly between MAs – traffic between SPGs flows via MCs
•
• Catalyst 3850-based MC deployments are likely to be common in branches and even possibly smaller campuses
• Larger deployments are likely to use discrete controllers
(5760, 5508, WiSM2s) as MCs, for scalability and simplicity
There are many other examples of roaming. These replicate the traffic flow expectations seen
elsewhere with converged access. Examples include the following:
 Catalyst 3850 MC deployments are likely to be common in branch offices and smaller
campuses.
 Larger deployments are likely to use discrete controllers for scalability and simplicity.
As we saw previously, we can also optionally use a Catalyst 3850 switch

as an MC + co-located MA for a Switch Peer Group. Let’s explore this in more detail.
• Single Catalyst 3850 MC supported per Switch Peer Group
• which can have up to 16 x MAs (stacks) per 3850-based MC Guest Anchor
• Single Catalyst 3850 MC can manage up to 50 APs and 2,000 clients MC MA
total therefore, up to 50 APs and 2,000 clients
in a Catalyst 3850-based Switch Peer Group
• MC manages inter-SPG roaming, ISE PI
RRM, Guest Access, and so on
• More scalable MC capability
can be provided by 5760/WiSM2
But what if
we want to scale
SPG larger, without
MC MA MA MA implementing
5760/WiSM2?
Is this possible?
The 3850 can be used as both an MC for small deployments as well as an MA for itself. The
limit is that that deployment can have only 50 APs and 2000 clients. That is a total limit of how
many APs and clients can be applied per stack. It is also the limit to how many APs and clients
can be applied across the entire SPG if using the 3850 as the MC.
The reason for the limitation is the CPU. The CPU in the 3850 did not get bigger than when it
was used for only controlling itself as MA or when using it as MC. Therefore, the limit of 50
APs and 2000 clients applies across the entire SPG. It is a limit of 50 APs across all the switch
stacks, 2000 clients across all the switch stacks if using the 3850 as an MC.
Switch Peer Group/Mobility Group Scaling with Catalyst 3850 –

• Up to 8 x Catalyst 3850 MCs can be formed into a Mobility Group • Guest tunneling is per MC –
• Up to 250 APs total and 16,000 clients supported (maximum) to Guest Anchor controller
across a Mobility Group made up solely of Catalyst 3850 switches Guest Anchor
MC MA
• Licensing is per MC – not pooled across MCs
• RRM, etc. is coordinated
across the MCs in the same
Mobility Group ISE PI
SPG
! "# ! "# ! "# ! "#
SPG
! "# ! "# ! "# ! "#
SPG
Mobility Group ! "#

SPG
! "# ! "# ! "#
! "# ! "# ! "# ! "#

SPG
! "#
SPG
! "# ! "# ! "# Full mesh of MCs
! "# ! "# ! "# ! "# across Mobility Group
SPG SPG
MC MA MA MA MC MA MA MA
This type of restriction can be worked around by using multiple SPGs. Each of the SPGs
operates with one of the 3850 stacks designated as an MC. The 3850 MCs can be grouped
together in a mobility group. Up to eight 3850s can operate as MCs; each one of those MCs can
be grouped together into a mobility group.
With that in mind you might think that eight times 50 would render 400 APs, but this is not
true. It is the opinion of Cisco engineers that have built converged access that 250 APs and
16,000 clients is the maximum that can be supported in this type of deployment mode. This is
due to the control plane scalability of the 3850 CPU, and its ability to keep up with roaming
events. Therefore, 250 APs and 16,000 clients is the maximum in this deployment mode.
The licensing for APs is per MC, not pooled across MCs. This is the same as licensing today.
Functions like RRM are coordinated across all the MCs. Another important fact to note is that
the guest tunnel is originated per MC after the guest anchor controller. Again this is done for
scalability reasons. The guest anchor tunnel is configured on each one of the MAs, but the
tunnel only originates logically from each MC and out to the guest anchor. That is because the
guest anchor controller can only manage a maximum of 71 incoming tunnels if a tunnel
originates from each MA or each switch stack. The guest anchor tunnel will only originate from
the MC, again, done for scaling reasons.
Considerations –
• Many larger designs (such as most campuses) will likely use a discrete
controller, or group of controllers, as MCs. Combined with Catalyst 3850 switches
as MAs, this likely provides the most scalable design option for a larger network build.
• However, if using 3850 switches as MCs for smaller builds – and with the scaling
limits detailed on the previous slide in mind – we need to determine where to
best use this capability.
• Pros –
• CapEx cost savings – via the elimination of a controller-as-MC in some designs
(typically, smaller use cases and deployments). Cost also needs to take into
consideration licensing on the Catalyst 3850 switches.
• Cons –
• OpEx complexity – due to some additional complexity that comes into roaming situations
when using multiple 3850 switch-based MCs (as detailed in the preceding slide). While
not insurmountable, this does need to be factored in as part of the decision process.
Conclusion –
In smaller designs (such as branches), the use of Catalyst 3850 switches as MCs is likely workable.
In mid-sized designs, this may also be workable, but does lead to some additional roaming considerations
(as detailed on the following slides). In large campus deployments, the use of controllers as MCs is
more likely, due to economies of scale.
Next you should consider when to use the 3850. The benefit of using 3850 as MCs is that you
gain some capital expense cost savings by not having to deploy discrete controllers in the
environment. The disadvantage to using a 3850 as MCs is operational complexity. If you
deploy this with a large number of 3850 stacks, you possibly have more MCs than you need to
manage in the environment. The conclusion is that using a 3850 as MC is workable for small
designs.
For midsized designs, this is also possibly workable, but as deployments start to scale up
towards those limits, designers typically need to implement a series of discrete controllers
instead to ease the management burden. For larger deployments, discrete controllers such as
MCs are more common due to economies of scale and scaling.
Converged Access is an evolutionary advance to our wireless deployment options.
Converged Access addresses inflection points around device and bandwidth scale, and
allows an unprecedented level of traffic visibility and control for wired and wireless deployments.
The Catalyst 3850 switch offers the best stackable switch platform in the industry,
incorporating many important advances to the state-of-the-art in stackable switching.
Many of the terms and components used to describe converged access also exist in today’s
unified wireless deployments. New components added with converged access include:
Switch Peer Group (SPG) – used to localize roaming
Mobility Oracle – used to allow greater Mobility Domain scalability
With converged access, the Catalyst 3850 switch is a full partner in the mobility roaming domain.
Roaming in converged access (by default) behaves as a Layer 3 roam does in unified access,
incorporating MAs and MCs for seamless roaming with full visibility and control over traffic flows.
In small to mid-sized deployments, the Catalyst 3850 can be used as both an MC as well as an MA.
The following key points have been discussed:

 The 3850 is the best stackable switch platform in the industry, with lots of new
functionality, wired and wireless visibility and control.
 SPGs and MO have been introduced. Everything else is repurposing what already exists in
wireless, moving it around to different places in the network to drive our ability to
distribute the functionality and scale.
 The 3850 becomes a full partner in the roaming mobility domain, providing seamless
roaming, full visibility, and traffic control and in small to midsized deployments. The 3850
can be used as both an MC as well as an MA.
Features and Licensing Overview
This topic covers the various release features and licensing.
• At FCS, converged access wireless code will bring features close to CUWN 7.0
– Also, some AP modes are not supported at FCS
Area WLC Feature list 3850 5760 Comments
Mesh AP Mesh AP no no Mesh is not in FCS
AP Hreap no no Not supported in FCS
AP Rogue detector no yes Not supported in FCS for 3850
AP Office Extend AP no no Not supported in FCS
AP PoE and 802.3at for powering AP's yes no

H-REAP Groups CCKM Fast Roam in connected mode,
H-REAP-Groups CCKM Fast Roam in the standalone mode
AP Back-up Radius server
H-REAP Radius server
H-REAP WLAN -VLAN mapping
H-REAP IP address learning
H-REAP link auditing feature
H-REAP Hardening
FlexConnect HREAP OKC features no no
AP Fast Heartbeat, Primary, Secondary, Tertiary, AP Join Priority
AP HA No yes
– Rogue detector: AP has to be on a trunk to be in RD mode. The 3850 does not support APs on trunks (they have to be in access
VLAN, in the wireless management subnet), so the 3850 does not support RD APs at FCS. The catch is the WLC role: rogue
detection is done on the MC, using info from the MC APs, not from the MA AP.
Converged access FCS code (released in January 2013) brings parity of features with Cisco
Unified Wireless Network (CUWN) 7.0 MR1 (7.0.116). Some features available in CUWN
later releases, being of great importance for your customers, could also be integrated in
converged access FCS release. However, due to the difference of platforms, some features
supported in the CUWN architecture are not supported in converged access at the time of FCS.
For example, AP failover relies on APs discovering backup controllers. As APs do not connect
directly to the 5760, this logic makes sense for APs controlled by a 5760. APs connect directly
to a 3850. The 3850 absorbs all CAPWAP traffic when wireless is configured on the 3850.
Therefore, APs connecting to a 3850 cannot connect to an external controller if the 3850 fails.
In most cases, the 3850 itself will not be reachable anymore, and APs will lose any connection
to the network. In this context, configuring backup controllers or fast heartbeats does not make
sense on a 3850 and its APs.
Notice that FCS code has a limited support for AP modes.
The table compares CUWN and converged access controllers features for the FCS release:
5760
Deployed as
MC
Local-Mode (Converged
(Centralized) Access)
# of APs Managed Scale 1000 1000
# of Clients Supported Scale 12000 12000
# of H-REAP Groups Scale  

# of APs per H-REAP Group Scale  
# of AP Groups Scale 500 500
APs per RRM Group Scale
WLANs
VLANs Scale 4096 4096
VLANs per H-REAP Group (AP Interface Limit) Scale  

# of Rogue APs Detection Support Scale 4000 4000
# of Rogue Clients Detection Support Scale 5000 5000
L3 Mobility Mobility  
RRM Feature  
Centralized Mgmt (Cisco Prime) Management  
LAG Feature  
VideoStream Feature  
WMM CAC Feature  
CCX CAC Feature  
Guest Services Internal Webauth Guest Access  
Guest Services External Webauth Centrally Switched Guest Access  
Guest Services External Webauth Locally Switched (Flex) Guest Access NA NA
Guest Anchor (No Relevance to Deployment Mode) Guest Access  

Acls—Dynamic On Controller Security  
Acls—Downloadable Security  
Acls—Flexconnect On AP Security NA NA
Data DTLS Security  

Mobility Data DTLS  
Teleworker OEAP  
Adaptive WiPS Security  
ELM Security  
Rich RF (CleanAir, ClientLink) Feature  
Open/Static WEP Security  
WPA-PSK Security  
802.1x (WPA/WPA2) Security  
MAC Authentication Security  
CCKM Fast Roaming Mobility  
PMK Fast Roaming/OKC/PKC Mobility  
Local EAP On HREAP Security  
Backup Radius Security  
MIC/SSC Security  
LSC Security  NA
TACACS Accounting Security  

LDAP Security  
Rogue Detection/Classification Security  
MFP (Client, Infrastructure) Security  
RLDP Security  
NAC Security  
QoS Markings QoS  
QoS TCLAS, SIP QoS  
Dot1p Markings QoS  
UPSD 11n  
TSpec/CAC Feature  
Voice Diagnostics Feature  
Voice Metrics Feature  
Multicast-Unicast Feature  
Multicast-Multicast Feature  
Video CAC Feature  
DFS/802.11h Feature  
Ipv6 (Client Mobility) IPv6  
Ipv6 RA Guard IPv6  
Ipv6 DHCP Guard IPv6  
Ipv6 Source Guard IPv6  
RA Throttling/Rate Limit IPv6  
IPv6 ACL IPv6  
IPv6 Client Visibility IPv6  
IPv6 Neighbor Discovery Caching IPv6  
IPv6 Bridging IPv6 NA NA
Syslog Serviceability  
CDP Feature  
WGB Support Feature  
VLAN Pooling Per Group Scale  
Passive Clients Feature  
#Of Passive Clients Support Scale 12000 12000
Band Select Feature  

Peer-To-Peer Blocking Security
Client Load Balancing (Aggressive Load Balancing) Feature  

FIPS Certification  
Intercontroller Mobility Mobility  
Client And RFID Tag Location (See Context Aware) MSE/Location Services  
Trustsec SXP Security  
Hs2.0 Feature  
Split Tunnel OEAP  
High Availability AP SSO Resiliency  
High Availability Client SSO Resiliency  
High Availability SKU And Licensing Resiliency  
11r Mobility  
ISE 1.1MR Support Security  
AAA Override (VLAN) Security  
AAA Override (ACL) Security  
Basic AAA Functions Security  
Profiling BYOD Security  
Posturing BYOD Security  
Central Guest Access Guest Access  
Local Auth Security  
Internal DHCP Server Feature  
Wired Guest Guest Access  
New Mobility Mobility  
Old Mobility Mobility  
Device Provisioning BYOD  
BYOD COA BYOD  
BYOD CWA BYOD  
BYOD DACL BYOD  
BYOD DAVCL BYOD  
Web GUI Management  
Workgroup Bridge Feature  
AVC  
Bonjour Services Directory  
New Features and Innovations
Jan 2013 – FCS Release Q3CY13 1HCY14
Infrastructure: UPOE SKU support, 9-member
Infrastructure: Catalyst 3850 with IOS-XE, 4 stack support Resiliency: ISSU, Wireless Client SSO
member stack support Wireless: 11ac/Monitor Module -AP3600, Security: Wired/Wireless Guest Access, AP
Wireless: Supported APs: 3600, 3500, 2600, AP3700(11ac), 802.11r and Neighbor List, Group and Profiles, Wireless DAI & IPSG
1600, 1260, 1140, 1040 Management Frame Protection, 802.11n Smart Ops: ERSPAN, Wireshark
Resiliency: NSF/SSO for Wired Clients, Voice CAC, Wi-Fi Direct, New Alarms, Core: IPv6 Infrastructure Support (CAPWAP,
Wireless AP SSO, Multiple LAG for MC Rogue Enhancements SNMP, Radius, Mobility, RRM)
AVC: Hierarchical Bandwidth Management, AVC: Bonjour Services Directory, application
Flexible NetFlow recognition (like NBAR)
Core: IPv6 Mobility support Security: ISE1.2
BYOD: Device On-boarding
Core: IPv6 First Hop Security, IPv6 Multicast Routing,

REP
Security: Device Sensor, MACSec, PVLAN, Multi-Auth
VLAN Assignment
AVC: Medianet
Smart Ops: Smart Call Home, EnergyWise
Core: HSRP/VRRP Wireless: Indoor or outdoor mesh, Flexconnect, Office-
Security: SGA, Critical Voice VLAN extend modes,
Base features, parity with 7.0MR Compliance: Common Criteria, JITC, FIPS Wired Guest Access with CAPWAP
Feature Parity with IOS 15.0(2)SE and Aironet OS 7.0.230.0
Several releases are planned to gradually bring parity of features between CUWN and
converged access.
A maintenance release published in June 2013 adds a Web UI (Web UI was limited to Monitor
only at FCS) for converged access controller configuration, and also bring your own device
(BYOD) onboarding. With this maintenance release, your customers can configure all BYOD
onboarding cases (1 SSID, 2 SSIDs scenarios, authentication on the controller, a RADIUS
server or ISE used with central Webauth or provisioning).
The next release, planned for Q3CY13, will add several new features:
 Some of them are new features also on the CUWN code train (for example, support for
802.11ac and 802.11ac APs, such as the 802.11ac module for the 3600 AP and the 3700
AP).
 Some features are specific to the converged access architecture. For example, the 3850 was
available as a stack of up to four switches at FCS. This limitation is extended to nine
switches in this new release. You will also be able to stack two 5760s, to offer a better
redundancy scenario for the MC role.
 Some features are an effort to continue building parity with the CUWN code. In this family
of features, you will find support for 802.11r and 802.11k (neighbor list), Bonjour,
Network-Based Application Recognition (NBAR), 802.11n Voice CAC, and Wi-Fi Direct.
This effort will continue. The following release, planned for 1HCY14, will expand the list of
features to items such as client Stateful Switchover (SSO), wired and wireless guest access
(wireless guest access is supported, but wired guest access is limited to local authentication on
the 3850, and is not supported on the 5760), RF profiles, extension of IPv6 support, and so on.
The midterm strategy is to bring parity of features between CUWN and converged access. Once
this is achieved, every new CUWN and converged access code will bring the same set of new
features.
On the 3850, you can enable (or not) configure wireless parameters
• With no wireless parameter enabled, the 3850 is a Layer 3 switch
• You can connect an AP to it, and have the AP join a controller anywhere else
Now… you configure a wireless Management Interface:

• 3850 absorbs CAPWAP traffic
• You cannot connect an AP on the 3850, and have it join another controller anymore
• No roadmap plan to support this “out of 3850 connection” as of today
3850 requires APs to be connected directly, in the wireless management VLAN

• You cannot have an AP connected to another switch join the 3850 WCM over the inter-switch trunk link
• An AP on the 3850  
Catalyst
3850

AP CAPWAP Tunnels
A common question from customers revolves around redundancy. What happens if the 3850
fails? How can APs join another controller in that case?
A first element of the answer is that the 3850 does not always absorb CAPWAP tunnels. A
3850, with factory defaults, is a Layer 3 switch that does not absorb CAPWAP tunnels. Any AP
connecting to the 3850 will need to join another controller, and the 3850 will not absorb any
CAPWAP traffic.
This behavior changes as soon as you configure a wireless management interface on the 3850
(and this behavior does not rely on the AP licenses that may be installed or not on the 3850).
The 3850 immediately becomes a wireless controller and starts absorbing CAPWAP traffic.
APs connected to the 3850 must be in the wireless management subnet, and must join the 3850.
The 3850 will not accept any AP from outside of the 3850 or the 3850 stack.
What happens if you lose the 3850 WCM?
On code 3.2SE, you can stack up to four 3850s, only one assumes the WLM role.
• The APs connected to the failed 3850 also fail.
• At stack level, automatically, an active and standby (masters) are elected.
- Process takes about 2 minutes.
• The active assumes the WCM role.
• There is only one WCM in the stack.
- But make sure that each 3850 has an AP license if needed!
Active
• All APs in the stack (up to 50) join the WCM on active.
• Do not connect more than 50 APs to the stack!
• Each switch in the stack uses an HA Manager process
to communicate with the others. AP CAPWAP Tunnels
If the 3850 itself fails, all its connected APs also fail, because they have no switching and
routing path to the rest of the infrastructure (not to mention that the 3850 may also be providing
power to these APs).
In stack however, the Wireless Control Module (WCM) function is distributed across the stack,
which means that only one 3850, elected as the stack master, will perform the WCM function,
and all APs in the stack will connect to that WCM. When the 3850 hosting the WCM function
fails, the stack election system will transfer the WCM function transparently to the stack master
standby. The backplane is copied across the stack, which means that the newly elected WCM
has all client and AP states, resulting in a transparent failover.
Keep in mind that a stack supports up to 50 APs. Also, the AP CAPWAP termination tunnel
function is the MA. An MC is needed for when APs join a controller, and that MC must have
licenses available for the joining APs. When the 3850 stack hosts both the MA and MC
function, do not add all APs licenses to the stack master. Licenses are tied to physical
appliances. If the 3850 hosting the MC function fails, its licenses will not be transferred to the
stack backup. No issue will be encountered as long as APs (or 3850s in the stack) do not
reboot. However, when APs reboot, they will need a license to rejoin their controller, and the
stack will not be able to provide that license anymore (because the stack master holding the
licensed failed).
The recommendation is to install enough licenses for the number of APs physically connected
to that 3850. During the master election, all licenses will be concatenated in the stack master. In
any failure scenario, you will always have enough licenses for the remaining 3850s in the stack.
How do APs survive the loss of the 5760? Same as CUWN N+1 (without AP SSO):
• AP discovers and joins WLC, keeps sending discovery messages to backups
• If no reply from backup after 120 s, AP stops trying and sends discovery to next backup
• By default, AP and WLC exchange keepalive every 30 s
• If no reply, AP sends 4 more keepalives, at 3 s interval (T=42s)
• Then AP tries to join backup (T up to 55 s)
You can configure a primary/secondary/tertiary

WLC and timers
• Backup list is more deterministic
• You can also configure fast heartbeats to speed up
link loss detection
The failover logic is different on the 5760, as APs do not connect directly to the 5760. You can
configure redundancy in a logic similar to that of CUWN N+1. You can configure primary,
secondary and tertiary controllers on the APs, and configure fast heartbeat timers to expedite
the failover process when the primary controller fails.
This configuration relates to the 5760 used in its MA role, that is to say terminating AP
CAPWAP tunnels.
MC is needed for AP license
• When AP joins a CA controller, the WCM queries the MC for one AP license
- Only needed at join time
- MAs do not host AP licenses
MC redundancy is limited at FCS:

You need to manually point your MA to a MC:
3850_jhlab(config)#wireless mobility controller ip 10.10.21.3
Any change in the MC address implies a manual change on each related MA

• Unless you use a clever system with virtual IPs, and so on, but this would be independent from
the 5760 configuration.
Next release (3.3/Q3CY13) will introduce 5760 HA

• MCs will share a common virtual IP address
• You will configure the virtual IP on the MA
Failover considerations are more complex for the MC role. The MC is needed for AP license
management. A converged access AP license can be installed on a 3850 or a 5760 indifferently.
The AP license cost is the same on both platforms, and licenses can be moved from one
physical device to the other (3850 to 3850 or 5760, 5760 to 5760 or 3850).
The MC is the device hosting the AP licenses for its MAs. This means that when an AP joins a
controller, that controller will query the MC for an AP license. Once that AP has joined the
controller, the MC is not needed any more to “maintain” the license. The MA to MC request
only occurs at AP join time.
This behavior does not present any difficulty when the MC role is on a 3850 stack, as explained
in the previous pages. The behavior becomes more complex when related to failover, when the
MC is a 5760 used by 3850 MAs. The MC configuration is static on the MA, which means that
you enter (on the MA) the MC IP address. If that MC fails, the MA has no location to request
licenses for joining APs. This limitation may be an issue if new APs join an MA while an MC
has failed, or if an MA reboots while an MC has failed.
This issue will be addressed for the 5760 in the next release, where you will be able to
configure two 5760s for high availability. Until then, you can also use a 5508 or WiSM2 for
your MC. On these platforms running a CUWN code compatible with converged access
(7.3.112 or 7.5 or later), you can configure high availability between two controllers, thus
ensuring MC redundancy.
Active MC goes
APs stay up and running
down in 1:1 HA – Active
Standby HA MC 5508 MC
or WiSM-2 now
down
MC Roamed and Local users,
becomeActive
HA MC
High Availability Considerations
• Local users on their MA have no
impact following a HA MC event
• Any new roaming happening after
MC HA failure from local MA
clients triggers full new re-auth (no
client SSO), both inter-SPG and
intra-SPG
• All roamed clients (inter and intra
SPG SPG SPG) will result in a “hard roam”
MA MA MA MA MA MA
PoP PoP
(re-auth, re-DHCP, change of
PoA PoA client IP address, known as
✗ ✓ Client “becoming local”)

✗
re-auths,
(No impactre-DHCPs,
Non-roamed user:
✓ (Roamed Client
re-auths, re-DHCPs,
becomes local once)
to existing becomes
local
Roamed
clients
local (Roamed Client
re-auths, re-DHCPs,
on user (between SPGs):
(No impact to existing becomes local once)
local clients on MAs) MAs)
In the case where the MC is a 5508 or a WiSM2 running a CUWN code compatible with
converged access, MC failover is transparent for the APs. APs already connected to MAs stay
connected, and new APs get their license at join time from the backup MC.
Notice that there is an impacted or roamed client. The reason is that the MC maintains a
database of all wireless clients in a given subdomain. When clients roam between controllers,
the new controller queries the MC to obtain information about the client’s previous controller.
This client database is not maintained between controllers in a high-availability scenario. This
means that when the primary MC fails, the backup MC running code 7.3112 does not have
information about the wireless clients in the domain. When clients roam, the new controller
queries the backup MC that responds that it does not know that client, and the client must
reauthenticate.
With MC controllers running code 7.5 and later, SSO also includes the client database (for a
client in the RUN state). This database is exchanged between controllers and facilitates
roaming. When a client roams to another controller (if the primary MC failed), the new
controller queries the backup MC. The backup MC was informed about the client details, and
roaming is seamless (the client does not need to reauthenticate).
Quality of Service
This topic describes the QoS options available.
Existing Unified Wireless Deployment today …
Current Mobility Architecture
5508/WiSM2
Challenges –
• Overlay model with multiple points of policy

application*
• Limited visibility into applications
• Lack of granular classification
CAPWAP
Tunnels
• Software based QoS
AP AP AP AP
* Overlay model applies to CUWN local

mode and FlexConnect centralized mode
© 2013 Cisco and/or its affiliates. All rights reserved. CONFIDENTIAL

Marking Policing Converged Access Solution Design Overview UASEBC v1.0—5-51
As discussed earlier, the architecture that exists today is well known and works very well.
There are some challenges with it, however. One of those challenges has to do with QoS and
the fact that you do have two different points within the network where you need to apply QoS.
One point is the wired port and another one is the wireless controller where all of the traffic
from the APs is going to be tunneled.
Existing Unified Wireless Deployment today …
Separate
Current QoS Architecture policies and
services for wired
WAN BLOCK 5508/WiSM2 and wireless
users
Wireless
Campus BLOCK
Distributed policies
Management implemented
Configuration on controller
and Deployment pushed to AP
Wired policies
implemented
on switch
Marking Policing
Queuing
Another challenge is the fact that you do not have a lot of visibility into that traffic because it is
encapsulated in CAPWAP tunnels, so all traffic looks the same.
If you want to find a way to rationalize or simplify your QoS strategy, the best way of going
about that is to have one source of truth for that policy and to be able to apply a policy once and
have it apply to both wired and wireless traffic.
One of the other challenges is, from a policing standpoint, where do you police traffic?
Normally you do that at the edge of the network. However, in today’s mobility architecture,
you are able to police at the edge for the wired users. However, you are applying that policing
at the anchor controller for the wireless user. Consequently, the traffic has consumed bandwidth
through the infrastructure before it reaches the controller itself. The policing activity is only
going to apply to traffic that is egressing the controller and going back out into the network.
That may not be ideal. You want to have a consistent way of applying that policy so that if you
are doing any type of rate limiting or some type of policing at the edge, you want it to apply
both for wired and wireless users concurrently at that edge so you are not consuming
unnecessary bandwidth.
The other thing that can be encountered is that at least from a policing standpoint, all of your
capabilities on the wired side are being done in hardware; whereas, when you are talking about
the wireless policies, it is actually being done at the anchor controller itself. That policy is
being applied in software, so there are implications to performance as the network implements
more of these QoS type features and applies them to more users.
Wired (Cat 3850) Wireless (Cat 3850 & CT 5760)

Modular QoS-based CLI (MQC) • Granular QoS control at the wireless edge
• Alignment with 4500E series Tunnel termination allows customers to provide QoS
treatment per SSIDs, per-clients and common
(Sup6, Sup7) treatment of wired and wireless traffic throughout the
• Class-based queueing, policing, network
shaping, marking • Enhanced bandwidth management
More queues Approximate Fair Drop (AFD) bandwidth
Management ensures fairness at client, SSID, and
• Up to 2P6Q3T queuing capabilities radio levels for NRT traffic
• Standard 3750 provides 1P3Q3T • Wireless specific interface control
• Not limited to 2 queue-sets Policing capabilities per-SSID, per-client upstream*
and downstream
• Flexible MQC provisioning abstracts AAA support for dynamic client-based QoS and
queuing hardware security policies
• Per SSID bandwidth management
* NOT available on CT 5760 at FCS
Not only does the 3850 bring together wired and wireless policies into a uniform platform. The
3850 is much more advanced than anything that Cisco has had at the access edge before. You
have more queues and are able to deliver two priority queues as well as six normal queues. The
switch has effectively doubled the number of queues on a per-port basis, which is far more than
Cisco has ever had in the past. In the past, switches usually had four queues per port, and then
you take one of those queues to provide a priority queue and you have the other three that you
are able to either shape or share that bandwidth.
With the 3850, there is even more capability. Cisco is doubling the number of queues, so you
can effectively provide two priority queues, one for voice and one for data and you are no
longer limited to just queue sets.
On the 3750, one queue set tells the switch how to map the traffic into a specific queue. You
can have one queue set for wired users, your normal users on the network, and another queue
set that applied to either phones or it applied to some other type of device. The 3750 is no
longer limited in that way. Now when you set up each port it depends on what you want that
policy to be. Once the policy is applied, you are not limited by also having to apply a queue set
to that port.
QoS is managed in a different manner. Before, Cisco had the construct of MLS QoS, which
was an outgrowth of years of switching software. Now Cisco has moved QoS to Modular QoS
CLI (MQC), so it is more aligned with what you have on the SUP-6 and SUP-7 for the 4500. It
is also what you have on the SUP2T on the 6500, as well as having MQC on all the routing
platforms. Now you have the ability to actually apply a uniform QoS policy across the network
infrastructure without having to memorize or know a completely different command set in
order to apply it.
DMZ
Wired
Prime (Cat 3850)
ISE Wireless (Cat 3850 & CT 5760)
• Alignment with 4500E series Tunnel termination allows customers to provide QoS
(Sup6, Sup7) WAN treatment of wired and wireless traffic throughout the
• Class-based queueing, policing, network
More queues INTEGRATED Approximate Fair Drop (AFD) bandwidth
UA 3850 CONTROLLER
Management ensures fairness at client, SSID, and
• Not Employee
limited
54
to 2 queue-sets
Guest Policing capabilities per-SSID, per-client upstream*
and downstream
BRANCH
Marking Policing
When you move over to the wireless side, the biggest benefit is being able to apply that single
QOS policy to both the wired and the wireless users. One of the great tools that Cisco has been
able to architect into the platform itself is the ability to do per SSID bandwidth management.
That’s something that gives us fine grained control over how QoS is applied not only at the
radio, but down to the SSID, and down to the client. Also to a certain degree, depending on
how aggressive the applications are, you can even apply a certain amount of bandwidth fairness
to those individual applications from the client.
With the CT 5760 or CAT 3850

Usage based fairWired
allocation(Cat
without3850) Wired (Cat 3850)
configuration Wireless (Cat 3850 & CT 5760)
Modular QoS based CLI
Modularwith
• Alignment QoS-based CLI (MQC)
4500E series (Sup6, • Granular QoS control at the wireless edge
Sup7)• Alignment with 4500E series Tunnel termination allows customers to provide QoS
(Sup6,Queueing,
• Class-based Sup7) Policing, treatment of wired and wireless traffic throughout the
• Class-based
Shaping, Marking queueing, policing, network
.11n AP
More Queues
Approximate Fair Drop (AFD) bandwidth
• Up More queues
to 2P6Q3T queuing capabilities Management ensures fairness at client, SSID, and
• Up 3750
• Standard to 2P6Q3T queuing
provides capabilities
1P3Q3T radio levels for NRT traffic
5 mbps • Standard 3750 provides 1P3Q3T
• Not limited to 2 queue-sets • Wireless specific interface control
5 mbps
• Not
• Flexible MQC
5 mbpsto 2 queue-sets
limited
Provisioning Max bandwidth allowed:
5 mbps abstracts
Policing capabilities per-SSID, per-client upstream*
54 – (4 * 5) = 34Mbps and downstream
• Flexible
queuing hardware
MQC provisioning abstracts AAA support for dynamic client-based QoS and
Regarding the enhanced bandwidth management on the 3850 or the 5760, since they do share
the common ASIC and architecture, one of the things that was considered desirable was make
sure you had the ability to prevent a user from taking control over all of the available
bandwidth on an AP.
One of the things that you are able to do with this enhanced bandwidth management is apply it
per user, allowing each user a fair access to that bandwidth.
In this example, you have a 54 MG radio and four users sharing the bandwidth. Then when you
add the next user, you automatically know that you are going to allocate that user the same
amount of bandwidth that the network has given everyone. Therefore, you still have bandwidth
available, should another user attach to the network.
It’s a very different approach to doing bandwidth management for wireless users.
With the 3850

Wired (Cat 3850)
Bidirectional policing at the edge per- user , per- Wireless (Cat 3850 & CT 5760)
SSID and in Hardware
•MQC
MQC based
based CLI
CLI • Granular QoS control at the wireless edge
Tunnel termination allows customers to provide QoS
• Alignment
Alignment with
with 4500E
4500E series
series (Sup6,
(Sup6, treatment per SSIDs, per-clients and common
Sup7)
Sup7) treatment of wired and wireless traffic throughout the
network
• Class-based
Class-based Queueing,
Queueing, Policing,
Policing,
Shaping,
Shaping, Marking
Marking • Enhanced bandwidth management
•More
More Queues Approximate Fair Drop (AFD) bandwidth
Queues Management ensures fairness at client, SSID, and
radio levels for NRT traffic
• Up
Up to
to 2P6Q3T
2P6Q3T queuing
queueingcapabilities
capabilities
• Standard
Standard 3750
3750 provides
provides 1P3Q3T
1P3Q3T • Wireless specific interface control
Policing capabilities per-SSID, per-client upstream*
• SSID: BYOD• Not
Not limited
limited to to 22 queue-sets
queue-sets and downstream
• QoS policy on 3850 used to police each client bidirectionally
• Policy can•beFlexible
Flexible MQC
MQC
sent via AAA Provisioning
Provisioning
to provide abstracts
abstracts
specific per-client policy AAA support for dynamic client-based QoS and
• Allocate Bandwidth
queuing
queueing hardware
hardware
or police/shape SSID as a whole security policies
As mentioned earlier, policing is a very effective tool that you use to not only protect your
infrastructure, but also to provide a certain amount of fairness to users so that one user cannot
consume more bandwidth than they should.
One of the things that you have the ability to do now, since you are moving the point at which
you are rate limiting, you are no longer waiting for the traffic to get to the controller since you
are terminating that user traffic at the access edge.
The 3850 has the ability to do bidirectional policing in hardware. Not only are you able to
scale the available bandwidth because you are terminating that traffic locally, but you are also
able to apply effective policies in such a way that there is no impact to performance.
With the CT 5760 or CAT 3850

Deterministic bandwidth is allocated per SSIDWired (Cat 3850) Wireless (Cat 3850 & CT 5760)
Modular QoS based CLI • Granular QoS control at the wireless edge
• Alignment with 4500E series (Sup6, treatment per SSIDs, per-clients and common
10% BW Sup7) 90% BW
treatment of wired and wireless traffic throughout the
network
• Class-based Queueing, Policing,
Enterprise
Guest Shaping, Marking • Enhanced bandwidth management
Approximate Fair Drop (AFD) bandwidth
More Queues Management ensures fairness at client, SSID, and

Deterministic
• Not limited BW
to 2 queue-sets Policing capabilities per-SSID, per-client upstream*
and downstream
• Flexible MQC Provisioning abstracts AAA support for dynamic client-based QoS and
Another feature is that you can apply bandwidth deterministically on a per-AP basis.
As was mentioned before, if you're on a wireless network transmitting and a large number of
users connect, then your Internet traffic may be impacted. One of the things that you have the
ability to do is to have two SSIDs, one for guest and one for enterprise. You can explicitly
allocate a percentage of bandwidth to the guest users as well as a percentage to the enterprise
users. What you are doing is protecting the enterprise from guests being able to consume all of
the available bandwidth.
This network may have started out with three guest users, and then you add more users, six,
nine, twelve users. As you add more and more guest users, they still only consume 10 percent
of the available bandwidth. This fairly allocates the 10 percent of bandwidth that has been
allocated for guests. You fairly allocate that bandwidth to each one of the users that connects.
Effectively, you are protecting the enterprise users. They are able to use all of their critical
applications. All guests still have access to bandwidth, but it in such a way that is not going to
impact the enterprise applications and enterprise users. You can do this on a per-SSID basis.
Wired (Cat 3850) Wireless (Cat 3850 & CT 5760)

Policy-map PER-PORT-POLICING
• Alignment with 4500E series Class VOIP
(Sup6, Sup7) set dscp ef
treatmenttransmit
of wired and wireless traffic throughout the
police 128000 conform-action exceed-action drop
• Class-based queueing, policing, Class VIDEO network
set dscp CS4
police 384000 conform-action transmit exceed-action drop
Class SIGNALING
More queues set dscp cs3 Approximate Fair Drop (AFD) bandwidth
Management
police 32000 conform-action transmitensures fairness
exceed-action drop at client, SSID, and
Class TRANSACTIONAL-DATA
set dscp af21
Class class-default
set dscp default
• Not limited to 2 queue-sets Policing capabilities per-SSID, per-client upstream*
and downstream
Cisco has moved to MQC. For any network designer who has done enterprise-wide QoS or
who has deployed QoS across their enterprise, it is probably one of the most difficult things that
is done in networking. You have a single source or reference of truth for developing a QoS
policy and you must take that policy via MQC and apply it across multiple platforms.
It certainly will help customers to effectively deploy QoS strategies. The confusion and the
frustration of having multiple command lines and multiple ways of applying a policy in the past
may have prevented customers from actually deploying it.
Now Cisco has one way of doing QoS which should help customers deploy QoS effectively.
Priority queues must

Marking is based on be configured they
Client SSID
table-map not set Radio* Port
are not on by default
• Classification • Classification Shaped by Shaped by

• Policing • Mutation* default default to
• Marking • Policing Sum of
• Shaping* 200Mbps Radios
• Bandwidth or
Entire SSID is rate
• Priority 400Mbps • Priority
limited, AFD manages
• Police
NRT traffic. Not configurable - • Bandwidth
based on max rate
radio can support
NOTE: SSID policies are actually per AP or BSSID.

Into a wired port Out of a wireless port
Next we will consider the order of operations for applying QoS and how that is done between a
wired client and a wireless user. Normally, on ingress into the switch, that’s where all of the
classification policing and marking is done. That’s not going to be any different. Operationally,
this is very similar to what you see on any switch available now.
What is going to be different is that when that traffic actually hits the SSID, you have the
ability to apply a policy to the SSID itself. You can then accept incoming video traffic and if it
was marked with a DSCP value of 42, you can re-mark the traffic to have a DSCP of 45. You
can also reclassify that traffic based on DSCP values or IP address, the normal classification
functions that you have.
The important thing is that not only are you doing it on ingress into the switch, at the switch
port, you can also re-evaluate that traffic and apply a different type of policy at the SSID level.
You can apply it at the radio level as well.
As that traffic is transitioning between the SSID and the radio, you can shape it. That’s a really
important aspect, because that is what gives you the ability to allocate 90 percent of the
available bandwidth at that radio for enterprise users and to control how much bandwidth guest
users have.
For each one of the radios that you have, or APs that are attached, you are also able to shape
traffic at the radio level. That radio, whether it is an 802.11n radio or it is a G radio, you are
able to shape the traffic. This is not something that’s configurable on its own. It is something
that happens by default. You know that each radio has a maximum amount of bandwidth that
they are able to consume based on the type of radio it is, and therefore shape the traffic by
default.
The point is that you do have very granular QoS control. This applies not only to what you can
do on the wireless side, but just as importantly, the QoS is really the most powerful set of QoS
tools that Cisco has ever had on an access switch.
Security
This topic describes security.
The Challenge Top of Mind Security Concerns
Device Proliferation How can we enhance How to deploy a How to ensure end-to-end
will lead to billions of devices the level of Security? consistent policy for security in a scalable way?
(Internet of Everything) all these devices?
In today’s networks you expect users to have a number of devices. There is a proliferation of
devices and the BYOD phenomenon is certainly a challenge for the corporate IT department.
The question becomes how to manage security and provide access. How does a company
control whether one of those devices gets on the network if the administrator is using simple
user names and passwords. Networks need something more granular. How do network
administrators manage this in such a way that does not prevent users from being productive,
even though they may bring their own personal devices?
Contractor Users
Guest Users
Internet
Employees
Core
ISE
AP Services
Cat 3850 • LDAP
• CA
BYOD Guest SSID (open)

BYOD Corporate SSID (dot1x)
Networks now have users that are connecting to the wired network, to the wireless network,
and through virtual private networks (VPNs). You need a unified way to grant them access as
well as being able to differentiate what services a user should get based on how they connect.
Wired Policy A
Corporate
Device
Wireless Policy B
Employee
VPN Policy C
Personal
Wired Policy C How to define and
Device
Wireless Policy D
apply security
policy consistently
User Wired Policy E
Corporate across every device
Device
Wireless Policy E on the network?
Contractor
Personal Wired Policy F
Device
Wireless Policy F
Personal Wired /
Guest
Device Wireless Policy G
The employee ID and a password can no longer be the only tool used to get access. Networks
today must determine what device is being used, what is being accessed, and how the network
is accessed. What you want to do is provide a uniform way of controlling access, which means
one set of policies, one set of rules that says who you are, what device you are using, how you
are connected, and what you are allowed to do. In this first case, the network administrator has
answered that question by saying no to allowing personal devices.
If you are a contractor coming to work and bringing a personal device, the administrator may
not want to allow that user access at all. However, for anything that they have been given as a
tool for their job, such as a laptop, they need to be able to have access, but just to the wired and
wireless network.
5 Dot1X Authentication
Corporate
Wired ISE
1 Dot1X Authentication
Device
2 AuthZ with dVLAN 30; 4 Authz with dVLAN 40;
Corporate dACL Permit ip any any; dACL Restricted Access
Wireless Corporate
Resources
Device
VLAN 30
Same-SSID
802.1q Trunk
Employee Internet
VLAN 40
Personal
Device 3 Dot1X Authentication 6 AuthZ with dVLAN 30;
dACL Permit ip any any
 Employee using the same SSID, can be associated to different VLAN interfaces and policy after EAP
authentication
 Employee using corporate wired and wireless device with their AD user id can be assigned to same
VLAN 30 to have full access to the network
 Employee using personal iDevice with their AD user id can be assigned to VLAN 40 and policy to
access internet only
If the user connects on a wireless SSID, they access the network both with a corporate asset—a
laptop—and an iPhone, for instance. The user is going to be connecting on the same SSID. The
process includes that first authentication and then ISE can dynamically put the user into a
VLAN. In the VLAN the user is given an ACL that recognizes the corporate asset and allows
the user access to everything within the infrastructure.
If the user connects on that same SSID and is using his personal device, the user goes through
that process and authentication. You need a structure that recognizes the device is a personal
device and that it should not have access to everything. The user will be put into a different
VLAN with a different set of policies or a different set of rules. You might only give them
access to the Internet, for example.
This is accomplished through network segmentation and traffic control. In this case, you are
using dynamic VLANs, but this can also be accomplished with dynamic ACLs.
• Policy management is done in IOS and policy enforcement is done in hardware for both wired and
wireless devices
- For wireless clients, WCM will decide which policy to be applied
• Client roaming
- L3 roam ACL policies will be applied on anchor switch (PoP)
- L2 roam ACL policies hand-off to newer switch (PoA)
• ACLs – centralized and distributed policy, IPv4 and IPv6
• URL redirection/URL ACL
• VLANs
• Service templates (distributed/centralized)
You can see that the mechanism is the same, but the policies that are being applied are different
depending on what type of device is being used. Authorization is incredibly important because
it says what you have access to, rather than whether or not you have access to the network.
In the case of the new wired and wireless convergence of architecture, how that policy is being
applied and what users are authorized to access needs to be consistent whether users are
connecting on a wired port or a wireless port and if they are roaming or static.
In the case of roaming, the standard method is for Layer 3 roams. ACLs are applied as part of a
user policy. Those stick to the PoP, because that is where the IP address is, and any time the
user roams in that environment, their traffic is going to move from the PoA, through the tunnel,
back to the PoP where the policy will be applied.
The process is different in a Layer 2 roam. Any dynamic policies that are applied to the user or
are downloaded based on who they are will move to a PoA at Layer 2.
In Layer 3, the policies that are applied stay with the user’s PoP. The authorization policy is
going to carry, as part of that policy, not only what the user can access in terms of dynamic
ACL, but it may put the user into a specific VLAN.
• Before Cat3850: One port, one VLAN per

access port (1:1)
• Exception: voice (one data device untagged,
one voice device tagged with VVLAN) VM
• Later: Allowing VLAN assignment on multi-
authentication ports, but first device “rules”
the port.
• Now: Each session can have individual
VLAN assigned Not a trunk!
Gi1/0/13
160 WIRED-EMPLOYEE active Gi1/0/13

170 WIRED-GUEST active Gi1/0/13
One capability that has been added to the wired infrastructure is the concept of dealing with
virtual machines (VMs). Many users run VMs on their devices to run applications they need.
An example might be running Windows applications on a Macintosh device.
In the past, the only ability available was to plug in the Mac, have it authorized on the network,
and put it on a VLAN. Any time that the user starts a VM, that VM is being bridged so there is
a different MAC address and it is getting its own IP address. The VM is being bridged to a port,
and the VM never has to be authenticated. This is not the case anymore.
Now you have the ability to authenticate multiple MAC addresses on a port, so every time a
new MAC address is learned, that MAC address has to authenticate.
Now the VMs cannot only be on their own network, you can dynamically add a VLAN for each
of the VMs running based on the authorization when the user logs in.
The port is not configured specifically as a trunk. However, every time it sees a new MAC
address it can authenticate that address. Therefore each one of the VMs is now on a different
VLAN with a different policy while the physical laptop is still on the corporate network with a
specific user ID.
Cat 3850 CT5760 CT5508

BYOD Functionality YES YES YES
Rogue detect / classify / YES YES YES
contain, RDLP
Port Security YES YES NO
IP Source Guard YES YES NO
Dynamic ARP Inspection YES YES NO
LDAP, TACACS+, YES YES YES
RADIUS
LSC and MIC YES YES YES
AP dot1x EAP-FAST YES YES YES
Secure Fast Roaming YES YES YES
802.1X-rev-2010 H/W Ready H/W Ready NO
(MACsec / MKA)
The figure shows a feature comparison chart. It is important to note that Cisco has had a very
good set of security tools on the wired network that you have never had in the wireless world.
These tools include port security, IP source guard, and Dynamic ARP Inspection (DAI). All are
tools that Cisco has had as part of their best practices for a number of years. Customers have
come to rely on these tools but they have never applied to wireless users. This feature is now
available in the 5760. Note that the 5508 does not have the same capabilities. Even with
upgraded software, there are still differences in its capability.
Cat 3850 CT5760 CT5508

IP Theft, DHCP YES YES YES
Snooping, Data Gleaning
IOS ACL YES YES YES
Adaptive wIPS, WPS YES YES YES
CIDS YES YES YES
TrustSec SGT / SGACL H/W Ready H/W Ready SXP
Guest Access YES YES YES
IPv6 RA Guard YES YES NO
MFP YES YES YES
IP Device Tracking YES YES NO
CoPP Static Static NO
Cisco has been talking about TrustSec for a number of years. Cisco infrastructure has not had
TrustSec support, including the assignment of Security Group Tags (SGTs). Both the 3850 and
the 5760 now have the hardware and the capability of being able to support SGTs end to end.
You will have the ability to deploy TrustSec all the way from the access layer, whether it is a
wired user or a wireless user, and use a consistent set of tags to greatly simplify the security
deployment.
All of the dynamic ACL capabilities are available today and can be applied to users to give
them a security policy. In the future, the ability to use TrustSec will be added. At that time
networks will not have to rely on ACLs but will use SGTs and SGT ACLs.
Harmonized security features for wired and wireless

Integrated policy for both wired and wireless
Increased scalability through optimizing a balance of centralized & distributed
architecture
From a security and a QoS standpoint, the Catalyst 3850 and the converged access platforms
are transforming and simplifying the way you apply policies as they relate to security and QoS.
You have a consistent set of tools. You have a method in the platform to apply policies in a
consistent manner, which greatly simplifies the deployment of all of these tools.
The Catalyst 3850 is the next evolutionary step from what Cisco has had in the past. The 3750
was a fine switch when introduced, but the Catalyst 3850 is the next step in switch evolution.
Multicast
This topic describes multicasting.
ISE Prime
Multicast Multicast with Traditional Deployments

Server (Multicast-Multicast mode)
• Wired Multicast Replication happens at the switch
Multiple
Replications
• Wireless Multicast Replication
at different happens at the Controller
points for
wired and
wireless Multicast Optimization
with Converged Access
Replication
happens at • Wired and Wireless Multicast Replication
the 3850
Catalyst switch for all Catalyst happens at the 3850 switch
3850 3850
clients
• Reduces the number of streams
Multicast
wired and
Access
Points
for the same traffic type in the network
wireless
receivers Wired Multicast Traffic Wireless Multicast Traffic
When managing multicast in a CUWN deployment, multicast replication happens in two

places:
 At the controller for wireless traffic
 In the wired network switches for wired traffic
This leads to additional complexity when understanding multicast traffic flows. It is necessary
to examine in CUWN how multicast traffic is managed and forwarded in each different
scenario. In a converged access deployment, multicast replication for both wired and wireless
traffic happens at the Catalyst 3850 switch. This is possible since, in converged access, both
traffic types are terminated directly on the switch itself. This ability to offer a more optimized
deployment model for multicast traffic managing has several benefits, which you will examine
in this section.
Multicast forwarding is disabled on WCM

• Multicast frames received at the controller level WLC
are not forwarded to Aps
Multicast source
IGMP Snooping is disabled on IOSd
• The IOSd does not know which AP
needs multicast forwarding
Both Multicast forwarding and IGMP snooping are

needed for multicast forwarding to be enabled 3850
• “wireless multicast” to enable IP multicast
• “ip igmp snooping/ipv6 mld snooping”
to enable snooping
AP AP AP AP
Mcast client Mcast client
Begin by examining the default state of multicast managing in the Catalyst 3850 platform. By
default, both multicast traffic forwarding and Internet Group Management Protocol (IGMP)
Snooping are disabled in the switch. Any multicast traffic received by the switch is not
forwarded along to any attached APs. In order to enable multicast traffic managing, both of
these functions must explicitly be enabled on the Catalyst 3850. This is done by using the
command wireless multicast, which enables IP multicast managing for wireless traffic streams
and the commands ip igmp snooping or ipv6 mld snooping, which manage IPv4 and IPv6
client multicast requests, for IPv4 and IPv6 traffic types respectively.
New MGID (S,G,V)

Does MGID (S,G,V)
exist? MGID, WLAN,
IGMP join report Clients MGIDIGMP join
to WLANreport
5760 map
Multicast Mcast client
source
When Multicast forwarding and IGMP snooping are enabled:

1. 5760 intercepts IGMP reports from IPv4 mcast clients
2. 5760 creates a MGID based on (Source, Group, VLAN) tuple, range 4160-
8195
3. 5760 uses IGMP snooping to determine if report should be forwarded to
source router
4. 5760 sends to AP MGID to WLAN mapping
5. AP keeps track of MGID, WLAN and client association
Next you will examine multicast traffic managing via the 5760 controller.
Note The 5760 and the 3850 share many common architectural elements and capabilities, with
the 5760 enabling centralized wireless traffic managing, and the 3850 enabling distributed
and converged wireless and wired traffic termination.
When the 5760 is deployed in a centralized mode, incoming IGMP reports from IPv4-speaking
wireless clients are intercepted as they are relayed up to the controller via the APs. Based on
this request, the 5760 creates a multicast group ID (MGID) indicating the requester’s source,
multicast group, and VLAN information. It then uses IGMP Snooping to determine if the report
should be forwarded along to the upstream multicast router within the wired network. The 5760
also sends back down to the AP the MGID-to-WLAN mapping data. The AP will use it to keep
track of any further incoming multicast streams as they arrive.
MGID (S,G,V) exist? Client for this

MGID?
No? Drop flow
Multicast No
Yes
5760
Multicast Mcast client
Yes? Forward to APs Client for this
source
MGID?
When Multicast flows from source to client:
1. WCM checks if a MGID exists for that flow

2. If MGID exists, WCM forwards to all APs, using Unicast or Multicast
No QoS tag by default, no DTLS encryption (if multicast)
If Multicast to Unicast replication is used, then traffic is sent only to those APs that have multicast
3. APs forward to each WLAN having clients for this MGID

Sent at highest mandatory rate, BE queue by default
When multicast traffic begins to flow from the source to the controller, based on the prior
request, the WCM function within the 5760 checks to see if an MGID already exists for this
flow (indicating the presence of one or more receivers downstream). If the MGID exists, the
multicast traffic is forwarded along to downstream APs using either unicast or multicast
encapsulation. By default, this traffic does not carry any explicit QoS tag setting, and no DTLS
encryption is performed for this traffic. Once the multicast traffic is received at the APs, the
APs only forward the multicast traffic over the air to those WLANs for which they have clients
for the MGID in question. This traffic, if sent, is forwarded at the highest mandatory data rate,
and uses the best-effort queue by default.
Multicast Replication Options – There are two options available: MCUC and MCMC.
MCUC (Multicast-Unicast) is the default method.

Mcast client
When client sends a “join” to a multicast
group, the multicast data will be Mcast client
encapsulated into a CAPWAP
Mcast client
data tunnel and unicasted to
the AP. Mcast client
Each AP with a client will receive a copy of the multicast stream encapsulated
as a unicast CAPWAP packet.
Only APs with active clients will receive the multicast traffic.
There are two options for how multicast data is forwarded to the APs:
 Multicast-Unicast (MCUC), which is the default)
 Multicast-Multicast (MCMC), which is more efficient if larger amounts of multicast traffic
are to be employed within the wireless network
In this example, examine the operation of MCUC using the Catalyst 3850. In MCUC mode,
when a client on a given AP sends an IGMP join for a particular multicast group, indicating it is
willing to receive multicast traffic for that group, the multicast data that subsequently arrives at
the switch will be encapsulated inside a unicast CAPWAP tunnel, and unicasted out to the AP
in question. This will result in each AP with an “interested” multicast-speaking wireless client
associated receiving a copy of the multicast data stream, encapsulated inside unicast CAPWAP
packets.
Only APs that actually have associated clients that have indicated their willingness to receive
multicast traffic will receive these unicast packet streams. This type of multicast traffic
forwarding, while simple and functional, places a burden on the controller, or switch that
enables it since that device needs to perform all of the necessary multicast replication and
multicast-within-unicast encapsulation. Thus, while MCUC is the default method of multicast
forwarding, and is simple to enable, a more efficient method of multicast forwarding is
possible, and may be desirable if larger volumes of multicast traffic are to be managed.
MCMC – A more efficient way!

AP MC2MC Group
239.100.100.100
MCMC (Multicast-Multicast) is the Mcast client
“preferred” method, where a separate
multicast CAPWAP tunnel is created Mcast client
within the switch.
Multicast source Mcast client
When a client sends a “join” to a Mcast client

multicast group, the traffic will be
encapsulated into the APs multicast
“sideband” tunnel and sent to all APs that 1. APs join MC2MC group 239.100.100.100
belong to the AP multicast group. 2. Clients join MC group 230.1.1.1
3. MA sends join for 230.1.1.1
4. MA receives 230.1.1.1 and sends it to APs as 239.100.100.100
(single packet replicated to multiple ports)
That more efficient option is Multicast-Multicast (MCMC). Basically, MCMC creates a

“sideband” multicast tunnel to which all of the APs join. Wireless clients joining a multicast
group do so via a normal IGMP join process. However, once the 3850 (acting as the MA)
relays this multicast request upstream, and multicast traffic begins to flow back downstream
towards the 3850 switch, the 3850 will encapsulate each received multicast packet (once only)
into a multicast CAPWAP tunnel (the ones that the APs joined), and send one copy of that
multicast packet to all of the APs simultaneously. Once this is received, only those APs with
multicast clients that wish to receive that stream will forward the decapsulated traffic over-the-
air. The other APs will drop it. This approach is more efficient since it avoids the multiple
MCUC encapsulations inherent in the MCUC method, thus providing more efficiency by
letting the multicast traffic replication capabilities within the switch hardware take up this load.
While MCUC is the default method of multicast operation, the MCMC approach is more
efficient and, thus, preferred.
“ip multicast-routing distributed” –

Multicast source
well known, current command for 375x series
“ip multicast-routing” –
new command, more consistent
with existing IOS based platforms
3850
AP AP AP AP
Mcast client Mcast client
Note that the method of enabling multicast routing globally on the Catalyst 3850 differs from
prior stackable switches in the 3750 family. Previously, enabling multicast within the switch
stack used the command ip multicast-routing distributed. Now, on the Catalyst 3850, this is
enabled with the simpler and shorter command, ip multicast-routing, which is also more
consistent with how multicast routing is enabled on other IOS-based switching and routing
platforms.
L09-3850-1# conf t
ap capwap multicast 238.101.101.101
All APs join the AP multicast L09-3850-1# wr mem
group. Note, the CAPWAP
L09-3850-1# sh capwap summary
multicast tunnel is not associated
CAPWAP Tunnels General Statistics:
with a single AP or interface. Number of Capwap Data Tunnels = 1
Number of Capwap Mobility Tunnels = 2
Number of Capwap Multicast Tunnels = 1
Topology – L2 or L3 access. Name APName Type PhyPortIf Mode McastIf

------ -------------------------------- ---- --------- --------- -------
Behavior – Each switch has a Ca2 - mob - unicast -
locally significant multicast Ca0 - mob - unicast -
Ca4 L09-AP3502-1_(upper_chamber) data Gi1/0/7 multicast Ca1
“channel” to which all AP’s join. Ca1 - mcas - unicast -
Name SrcIP SrcPort DestIP DstPort DtlsEn MTU

------ --------------- ------- --------------- ------- ------ -----
Ca2 10.101.1.109 16667 10.101.2.109 16667 No 1464
Ca0 10.101.1.109 16667 10.101.3.109 16667 No 1464
Ca4 10.101.1.109 5247 10.101.1.97 57575 No 1449
Ca1 10.101.1.109 5247 239.100.100.100 5247 No 540
This figure describes the MCMC operation enabled on the Catalyst 3850. Here, you can see
that each 3850 switch has a multicast channel to which all of its directly-attached APs join.
This multicast channel has local significance only, as it is only used for replicating multicast
traffic locally within the switch, and to its directly-attached APs.
In this example, the CAPWAP1 tunnel (Ca1) is being used as the MCMC “sideband” multicast
channel between the 3850 and it’s attached APs. This can be shown using the show capwap
summary command, which shows Ca1 as being a multicast tunnel, with a source of the
switch’s wireless management IP address, and a destination of this locally-significant multicast
group. This will be the information that forms the source and destination IP address information
for the Ca1 MCMC tunnel in this example. This multicast tunnel is not associated with any
single AP or interface. Rather, it is used to communicate to all of the APs that may wish to
receive multicast traffic.
Intra-WLC roaming:
3850 / 5760
1. WCM notifies IOSd with
client move notification
2. IOSd updates the CAPWAP ports AP AP
for MGIDs (groups) to which the
client was subscribed Mcast
client
3. WCM checks with the configuration
and AP capability to see if the group
should be allowed in the new AP.
4. If allowed, WCM adds all the new MGID
to the new AP and deletes the client
reference from the MGID from
the old AP.
Having seen how multicast forwarding takes place, with the MCUC or MCMC options, let’s
examine how roaming works for multicast-enabled clients. This begins with examining intra-
WLC (that is, intra-Catalyst 3850) roaming, which means a client roaming from one AP to
another, when both of those APs are managed by the same Catalyst 3850 switch. In this case,
roaming is simple. When the roam of the client is detected, the MGID to which the multicast
traffic should be forwarded is updated to point at the multicast tunnel leading to the new
roamed-to AP, and the old MGID data is deleted. This ensures that the multicast traffic can
follow the client as it roams, and is essentially just an update of the multicast forwarding state
within the switch, and to the APs it controls.
Inter-WLC Local-to-Local Client multicast traffic Client unicast traffic

(AKA Layer 2) roaming:
3850 3850
MGID (S,G,V)
1. WCM in switch1/WLC1 transfers
all the group info in the mobility MGID (S,G,V)
handoff payload to the switch2 / WLAN, Client
WLC2. AP AP
2. WCM in switch2/WLC2 creates

new MGID as if igmp report packets
from the client has arrived Mcast client
3. Old switch1 / WLC1 removes all the

client references as if a leave message
was received
4. Multicast traffic flows through
the new controller
Two different types of inter-WLC (that is, inter-Catalyst 3850 roams) are available. The first
one is for the roam type that is not actually the default in the Catalyst 3850, which is a Layer 2
roam. All roams by default in converged access with the Catalyst 3850 operate as Layer 3
roams. When a roam occurs, the PoA moves to the new roamed-to (foreign) switch, but the PoP
stays fixed at the roamed-from (anchor) switch. However, an option does exist to enable Layer
2 roaming behavior in which both the PoP and PoA would move to the new roamed-to switch
on a user roam. This obviously implies that the roamed-from switch and roamed-to switch need
to share a common set of wired-side VLANs. It is the responsibility of the network
administrator to ensure that this is indeed the case if Layer 2 roaming is enabled.
This use of Layer 2 roaming also has broader implications in terms of increased roam times and
greater authentication, authorization, and accounting (AAA)/RADIUS loading for roaming
users. That is why it is not the default on the platform. However, if Layer 2 roaming is enabled,
multicast will still operate as shown in the example.
The roamed-from switch and roamed-to switch in this example are in a common mobility group
(thus enabling roaming to take place). The roamed-from switch hands off all of the necessary
group info for the roaming client to the roamed-to switch, and the roamed-to switch creates a
new MGID based on that info just as if an IGMP Report packet had been received from the
roaming client. At the same time, the roamed-from switch deletes all of its references to the
roamed client. After this process is complete, both unicast traffic and multicast traffic simply
flow through the new roamed-to switch, and down to the roamed wireless client.
This may have increased roam times and AAA loading compared to the Layer 3 roaming
option, which is the default.
Inter-WLC Local-to-Foreign Client IGMP join Client

(AKA Layer 3) roaming: Same process unicast traffic
report multicast traffic
as local-to-local for multicast traffic: 3850 3850
MGID (S,G,V) MGID (S,G,V)
1. WCM in switch1/WLC1 transfers all the WLAN, Client
group info in the mobility handoff payload
to the switch2/WLC2. AP AP
2. WCM in switch2/WLC2 creates new MGID Possible risk: WLAN, interface ACL on WLC1 is
not moved. Client may have access on WLC2 to
3. Old switch1/WLC1 removes all the client multicast resources blocked on WLC1
Mcast client
references
4. Switch2/WLC2 sends IGMP reports
based on its WLAN/VLAN mapping
5. Multicast traffic flows through
the new controller…
6. but unicast traffic still goes through
switch1/WLC1 to preserve client IP
This topic examines multicast traffic flows for roaming users, when the default behaviour of
Layer 3 roaming is employed. In this case, once again both of the Catalyst 3850 switches in the
example are in a common mobility group, thus enabling seamless roaming to take place.
In this example, when the wireless client roams, a very similar handoff procedure takes place
between the roamed-from switch and the roamed-to switch, in terms of the MGID data that is
passed between them on a roam. The difference is not in the managing of the multicast traffic,
which will flow via the new switch after the roam. The difference is in the managing of the
unicast traffic which, since it is the PoP, is still back on the anchor switch, will flow back to
that switch via the SPG/mobility group. This anchoring of the client’s unicast traffic back at the
roamed-from switch (which holds the PoP) enables the client’s IP address to be retained across
the roam, without having to extend VLANs widely (that is, the roamed-from switch and
roamed-to switch can be either Layer 3 or Layer 2 adjacent to each other). The use of Layer 3
roaming speeds up the roaming process, since no new AAA authorization request is needed at
the roamed-to switch following a roam.
Layer 3 roaming also enables functions such as Security ACLs to be enforced at the PoP
switch, both before and after roaming, simplifying the deployment. However, in this case with
Layer 3 roaming when using multicast, it is important to note that the multicast and unicast
flows, as shown, will follow different paths in the network after the roam occurs. Following the
roam, it is more efficient to simply have all multicast traffic be forwarded from the wired
network multicast source, directly to the roamed-to switch for forwarding to the roamed
multicast client. This is the behavior that you see in the example.
The unicast traffic to/from that client, however, will still flow back to the anchor switch where
the client originated, and from there propagate upstream/downstream into the wired network.
When observing or troubleshooting this type of traffic flow, it is important to know the
difference in the unicast and multicast traffic forwarded behaviors in this instance, when using
the default of Layer 3 roaming in converged access. Also, it should be noted that, if interface
ACLs were in use, the roamed-from switch would control which multicast groups clients could
receive traffic from, those ACLs are not propagated between the switches on a roam. This
could pose a security risk in the sense that roamed clients may be able to access multicast
resources on the roamed-to switch that they may not have had access to on the roamed-from
switch. This must be accommodated for if such security enforcement methods for multicast
traffic flows are desired in the network deployment.
• Multicast on the WLC and UA 3850 uses the strength of multicast management within IOSd
• Broadcast forwarding and multicast forwarding are managed separately (you can activate one, the
other, or both, for IPV4, and/or for IPv6)
• Wireless Multicast group membership for wireless clients is managed by IGMP snooping module –
- When IGMP snooping is disabled, or when wireless multicast is disabled,
there is no Multicast MGID allocated and no multicast traffic sent to wireless client
• Multicast roaming is handled seamlessly, for both Layer 3 as well as Layer 2 roam types
The wired network multicast functionality is consistent with today’s behavior.
 Multicast forwarding by default is disabled on the Catalyst 3850 platform, and must be
explicitly enabled if desired.
 Both broadcast and multicast forwarding are managed separately, and can be enabled for
IP4 or IPv6 (or both).
 Wireless group management for multicast users is managed via the switch’s IGMP
Snooping capabilities, which creates MGIDs for wireless clients as they associate and
indicate their desire to receive a multicast traffic stream by sending out an IGMP Report
message.
 Roaming for multicast traffic is managed seamlessly for both Layer 3 (the default) as well
as Layer 2 roam types, but important differences exist for how unicast traffic vs. multicast
traffic is forwarded in these scenarios.
 The wired multicast traffic managment with the Catalyst 3850 platform is consistent with
today’s behavior.
Design Options and Migration
This topic describes design options and migration.
Up to
50 APs Applicable
to a Small
Branch
Deployment
Characteristics
• May be a lower-speed WAN link
(bandwidth and latency a concern only for guest traffic)
• Allows for advanced QoS, WAN optimization,
NetFlow, and other services for wireless and wired traffic
Deployment • Supports Layer 3 roaming
could consist
of multiple stacks – • Supports VideoStream and optimized multicast
one stack as MC/MA, • Good availability due to MA/MC redundancy within the 3850 stack. Provides
rest of stacks as
wireless continuity with either WAN outage or switch failure within the stack.
MAs only
If you have a remote branch that is fairly small, and has fewer than 50 APs you can use the
3850 without a discrete controller. The 3850 has both the MC and MA functionality. You can
use one device and scale it to allow for additional bandwidth as you move towards 802.11ac.
Deployment can consist of multiple stacks. One stack as an MC/MA and the rest of the stack as
an MA only.
The characteristics of this deployment are as follows:
 May be used on a lower-speed WAN link (bandwidth and latency a concern only for guest
traffic).
 Allows for advanced QoS, WAN optimization, NetFlow, and other services for wireless
and wired traffic.
 Supports Layer 3 roaming.
 Supports VideoStream and optimized multicast.
 Good availability due to MA/MC redundancy within the 3850 stack. Provides
wireless continuity with either WAN outage or switch failure within the stack.
Applicable
Up to to a Small to
Medium Branch
50 APs Deployment
Characteristics
• No discrete controllers deployed, even with multiple wiring
closets
• Allows for advanced QoS, WAN optimization, NetFlow,
and other services for wireless ad wired traffic
• Supports Layer 3 roaming
• Supports VideoStream and optimized multicast
• Good availability due to MA/MC redundancy within the
3850 stacks. Provides wireless continuity with either WAN
outage or switch failure within the stack.
If you need to scale the environment even further you can. Since you are still dealing with one
MC, you could have all of the other 3850s acting in the MA role. You can group them together
in an SPG.
In this example, you are showing that you are using a guest anchor because the MC is at the
campus.Notice that there is no discrete controller on the campus itself, however the MC is
acting as a foreign controller. All of the guest traffic would be going across the LAN and being
dropped into the DMZ.
Therefore you can apply whatever policy you want to apply. The important point is that the
network has got a single SPG, a 3850 that is acting as a controller with no discrete controller
within the architecture.
Characteristics of this deployment are as follows:
 No discrete controllers deployed, even with multiple wiring closets.
 Allows for advanced QoS, WAN optimization, NetFlow,and other services for wireless ad
wired traffic.
 Supports Layer 3 roaming
 Good availability due to MA/MC redundancy within the 3850 stacks. Provides wireless
continuity with either WAN outage or switch failure within the stack.
Scalability …
up to 8 x 3850-based MCs
Applicable
Up to to a Larger
Branch
250 APs Deployment
Note – MCs handling one Characteristics –

or more SPGs each, all
MCs meshed into a single • No discrete controllers deployed, even at a larger branch
Mobility Group for the site.
Guest tunnel per MC to • Allows for advanced QoS, WAN optimization, NetFlow,
Anchor. and other services for wireless ad wired traffic
• Supports VideoStream and optimized multicast
• Good availability due to MA/MC redundancy within the
3850 stacks. Provides wireless continuity with either WAN
outage or switch failure within the stack.
If you need to scale up even more, you can create multiple switch peer groups and put them all
into a larger mobility group. You can have up to eight stacks, or eight MCs, together in a single
mobility group and you can have up to 250 APs associated. This example is good for a large
branch deployment. In this case, there are no discrete controllers. You are still peering all of the
MC functionality on 3850s across multiple SPGs.
 No discrete controllers deployed, even at a larger branch.
 Allows for advanced QoS, WAN optimization, NetFlow,and other services for wireless ad
wired traffic.
 Good availability due to MA/MC redundancy within the 3850 stacks. Provides wireless
continuity with either WAN outage or switch failure within the stack.
Applicable
to a Larger
>250 APs Branch or
Small
Campus
Characteristics
• Greater scalability via the use of discrete controllers as MCs,
in conjunction with Catalyst 3850 switches as MAs
• Allows for ddvanced QoS, WAN optimization, NetFlow,
and other services for wireless and wired traffic
• Supports Layer 3 roaming, VideoStream, and optimized
multicast
• Good availability due to MA redundancy (3850 stacks) and
MC redundancy (controllers). Provides wireless continuity
with either WAN outage or switch/controller failure
• Simplified mobility deployment vs. the use of 3850 switches as
MCs/MAs
The next step would be to use discrete controllers. If you had more than 250 APs, you could
scale that by including discrete controllers. In this case, the network engineer has added either a
5760 or a WiSM2 or 5508. The important concept is that you are offloading the MC
functionality. You are also scaling out the available bandwidth that you have by continuing to
use the 3850s at the access layer where they are providing the MA functionality. This is a really
good option for a large branch in campus-type deployments.
 Greater scalability via the use of discrete controllers as MCs, in conjunction with Catalyst
3850 switches as MAs.
 Allows for advanced QoS, WAN optimization, NetFlow,and other services for wireless and
wired traffic.
 Supports Layer 3 roaming, VideoStream, and optimized multicast.
 Good availability due to MA redundancy (3850 stacks) and MC redundancy (controllers).
Provides wireless continuity with either WAN outage or switch/controller failure.
 Simplified mobility deployment versus the use of 3850 switches as MCs/MAs
Up to
Scalability … up to 8 x 3850-based MCs
Characteristics
250 APs
• No discrete controllers deployed,
even at a small campus
• Allows for advanced QoS,
NetFlow, and other services
for wireless and wired traffic
• Supports roaming between
• Good availability due to MC/MA
distribution layers, keeps
many roams localized redundancy within the Cat 3850
below distribution layer stacks – moderately scalable Applicable
using 3850s (up to 8 in total) to a Small
as MCs, combined with a single Campus
Mobility Group in the deployment Deployment
Note – MCs handling one

or more SPGs each, all MCs
meshed into a single Mobility
Group for the site. Guest tunnel
per MC to anchor.
In this scenario, the network administrator has taken the previous example where you had
multiple switch peer groups and you are creating a mobility group by peering them together.
Again there is no discrete controller on the campus itself, but the network administrator has
added an MO. What this allows you to do is scale the roaming capability and make roaming
between the SPGs faster. This is because the MO has the ability to see into each of the SPGs
and act as a reflector for all of the clients that are attached within the environment.
In this case, the network administrator has also added the guest anchor. Again, the MCs would
be acting as foreign controllers in our mobility group at the campus level, but all of the guests
would have their traffic backhauled, meaning it would be sent to the guest anchors, where a
centralized policy could be applied.
 No discrete controllers deployed, even at a small campus.
 Allows for advanced QoS, NetFlow, and other services for wireless and wired traffic.
 Supports roaming between distribution layers, keeps many roams localized below the
distribution layer.
>250 APs
Applicable
to a Larger
Campus
Characteristics
• Use of discrete controllers as MCs, combined with Catalyst 3850
switches as MAs, provides for a very scalable solution
• Allows for advanced QoS, NetFlow,
and other services for wireless and wired traffic
• Supports Layer 3 roaming – provides scalability by
keeping many roams localized to SPGs (below dist.)
• Good availability due to MA
redundancy (3850 stacks) and MC
redundancy (controllers)
• Simplified Mobility deployment using
3850 switches as MAs only, vs. the use of
3850 switches as MCs/MAs
If the 3850 was not used as an MA, you can use discrete controllers. In this deployment you are
using either a group of 5760s, WiSM2s, or 5508s. The network administrator has kept the
guest anchor and the MO. However, in this example, the guest user traffic is all going across
the WAN or going to the Internet edge, wherever the guest anchor may be. The network
administrator has included the optional MO for fast roaming and you have the ability to scale
this to a fairly large size.
 Use of discrete controllers as MCs, combined with Catalyst 3850 switches as MAs,
provides for a very scalable solution.
 Allows for advanced QoS, NetFlow, and other services for wireless and wired traffic.
 Supports Layer 3 roaming. Provides scalability by keeping many roams localized to SPGs
(below distribution layer).
 Simplified mobility deployment using 3850 switches as MAs only, versus the use of 3850
switches as MCs/MAs.
Characteristics >250 APs
• Use of discrete controllers as MCs,
combined with 3850 switches as MAs,
provides for a very Applicable
scalable solution to a Larger
• Use of distributed Campus
controllers (vs. centralized
in DC) may be more
appropriate in some • Allows for advanced QoS, NetFlow, and other services
wireless deployments for wireless and wired traffic
• Supports Layer 3 roaming – provides scalability by keeping
many roams localized to SPGs
(below distribution)
• Good availability due to MA
redundancy (3850 stacks) and
MC redundancy (controllers)
• Simplified mobility deployment
using 3850 switches as MAs only,
vs. the use of 3850 switches
as MCs/MAs)
In this case, instead of having centralized controllers, the network administrator has taken the
controllers and moved them into the distribution layer. That is the main difference. It would
functionally act much like the previous one; all the network administrator has done is create
additional controllers by moving them out.
 Use of discrete controllers as MCs, combined with 3850 switches as MAs. Provides for a
very scalable solution.
 Use of distributed controllers (versus centralized in DC) may be more appropriate in some
wireless deployments.
 Allows for Advanced QoS, NetFlow, and other services for wireless and wired traffic.
 Supports Layer 3 roaming. Provides scalability by keeping many roams localized to SPGs
(below distribution).
 Simplified mobility deployment using 3850 switches as MAs only, versus the use of 3850
switches as MCs/MAs.
Existing Unified Wireless Deployment Today…
Well-known
Data Center /
ISE
and well-proven …
Service block PI
Prior to Migration
Intranet to Converged
Access
Mobility Group
EtherIP Mobility Tunnel
5508 / WiSM2 5508 / WiSM2
Separate
policies and
services for wired
and wireless
Wireless policies
users
implemented
on controller
Wired policies All wireless

implemented CAPWAP CAPWAP
Tunnels Tunnels traffic centralized
on switch
via controllers
as shown
This topic describes how to migrate from a CUWN design towards converged access. For most
customers that would undertake a migration. This would be a gradual and incremental process,
at least in a large-scale environment. (Small deployments, such as branch offices, may simply
be able to do a “flash-cut” from CUWN to CA, but most larger deployments would perform
this migration gradually.) You will examine this migration using a large-scale campus wireless
deployment as an example.
In the CUWN architecture, you have 5508/WiSM2 controllers installed, joined into a common
mobility group. They have APs joined to them from different Catalyst switches in various
locations on the campus. The APs have each established a CAPWAP tunnel with their
respective centralized controllers. Wireless clients are all associated to the respective APs, and
have a working setup using the centralized wireless deployment model.
While this is a very functional architecture, and many thousands of customers have this
deployed, there are a few observations you can make about things that could be improved as the
customer migrates towards converged access.
 First, all of the wireless traffic in this design is centralized, creating some potential
bottlenecks as the network scales towards greater numbers of clients and greater
bandwidths per AP.
 Second, wired and wireless policies are applied at different places on the network as seen,
and with different sets of capabilities for QoS, security, NetFlow, and other functions.
Traditionally, the wired network has had more traffic visibility and control (using functions
like NetFlow) than what you have had on the wireless side of the network.
Overall, CUWN is a deployment model that has been working well for many customers, and
Cisco will be continuing to enhance and grow this deployment model. However, converged
access will also be supported as an additional deployment option for customers, providing
benefits that address some of the issues noted above.
Data Center /
Service block ISE PI
Intermediate step
Intranet
Mobility Group
CAPWAP
EtherIP Mobility
Mobility Tunnel
Tunnel
Software MC MA MC MA Software
upgrade upgrade
5508 / WiSM2 5508 / WiSM2
Initial
Migration Step –
Controller
Upgrades,
Catalyst Implementation
3850 of First CA
Switch MA MA switches Switches
Peer
Group
CAPWAP CAPWAP
Be aware Tunnels Tunnels
that feature
differences may
exist, based on
MA software
versions
As mentioned earlier, both MC and MA functionality is embedded in the centralized

controllers. As you move towards converged access, it is necessary to enable the new mobility
mode on the existing controllers, to allow interoperation with downstream Catalyst 3850
switches as the MA function migrates to these switches in a converged access deployment. The
new mobility mode switches all of the tunnels used in the solution (including inter-controller
tunnels) to CAPWAP (versus the EoIP sometimes used in older CUWN deployments). This is
necessary since the only tunnel type supported by the Catalyst 3850 platform is CAPWAP (not
EoIP).
New mobility is supported in AireOS software version 7.3.112.0 and above. It is not supported
in the 7.4 version of AireOS code. New mobility is supported in AireOS software version 7.5.
 As a first step, the software on the 5508/WiSM2 controllers needs to be upgraded to
7.3.112.0 (7.3 MR1). The 5508/WiSM2s operate by default as MCs. These platforms,
which can also terminate APs, also have the MA functionality built-in. The two controllers
shown in the figure establish mobility tunnels. (Notice that the EoIP mobility tunnel now is
a CAPWAP mobility tunnel after the upgrade, and after enabling the new mobility mode.)
 The next step is to replace some of the Catalyst 3750 switches in the customer’s
deployment with corresponding 3850 switches, using the IP Base or higher feature set, and
to ensure that switch configs are moved to the respective AP ports on the switch. In this
mode the 3850 will behave like the 3750 it replaces. No change in behavior is observed,
since wireless traffic interception has not yet been enabled on the 3850s.
 The next step is to enable the 3850’s wireless management interface, and map it to a
configured VLAN (the VLAN that the APs are deployed in). Once this is done, the switch
will start to intercept all CAPWAP tunnels from attached APs, and terminate that traffic
locally on the 3850. Only the management VLAN needs to be configured if the Catalyst
3850 is Layer 2-attached (one needs to create this VLAN if the 3850 is Layer 3-attached).
The APs now will join the Catalyst 3850 and will terminate their CAPWAP tunnels on the
switch.
The 3850s will also be formed into an SPG, and that SPG will be joined into the common
campus-wide mobility group, using one of the 5508s/WiSM2s as an MC. This allows the 3850s
to participate in seamless campus-wide roaming along with the rest of the wireless network
infrastructure deployment.
It is important to understand that there may be feature incompatibility between the 3850s, and
the centralized controllers, based on the software versions deployed on them. The Catalyst 3850
presently has features compatible with 7.0.116.0.
After this first upgrade, one would then follow the same procedure on different areas of the
network to replace the current access switches with Catalyst 3850 switches, operating in
converged access mode.
Data Center /
Service block ISE PI
Intermediate step
Intranet
Mobility Group
MC MA CAPWAP Mobility Tunnel MA
Controller MC Controller
upgrade upgrade
5760
5508 / WiSM2 5760
5508 / WiSM2
Controller Controller
Further
Migration Step –
Controller Upgrades,
Catalyst Implementation
Catalyst 3850 of Additional CA
3850 switches
switches
Switches
Switch MA MA Switch MA MA
Peer Peer
Group Group
CAPWAP CAPWAP
Tunnels Tunnels
Now that the access switch upgrades are underway, it is also possible (and may be desirable) to
also upgrade the controllers to 5760s as well. This would enhance the capacity and, in the long
term, much of the functionality of these controllers. This step is optional, but one that many
customers may consider at some point as they roll through a gradual migration such as the one
illustrated.
Caution The software features on the 5760 may not be the same as the features on the 5508/WiSM2
they replace (as the WLC 5760 presently provides a set of capabilities which is equivalent to
AireOS 7.0.116.0).
Note Non-802.11n-capable APs are not supported with the 5760 controller.
By proceeding gradually with the migration, incrementally on a wiring closet-by-wiring closet

basis, the entire campus could be migrated towards converged access, all while maintaining
seamless connectivity and roaming during the migration. Depending on the size of the site
being migrated, multiple MCs and multiple SPGs could be employed.
Increase in
Data Center / visibility and control
Service block ISE PI (NetFlow, Advanced
QoS, etc) via
local termination
Intranet of both wired and
Mobility Group wireless traffic
MC MA CAPWAP Mobility Tunnel MC MA
5760 or upgraded 5760 or upgraded

WiSM2 / 5508 WiSM2 / 5508 Increase in
Implementation performance and
of End-to-End scalability via local
Converged termination of both
Access wired and wireless
Deployment traffic
Switch MA MA MA MA Switch MA MA MA MA
Peer Peer Catalyst 3850
Groups Groups switches
Wired and CAPWAP CAPWAP Converged

wireless policies Tunnels Tunnels policies and
implemented services for wired
on 3850 switch
and wireless
users
Finally, one would arrive at the configuration as shown here – which is the Campus after the
entire migration to converged access is complete.
In this figure, several important benefits are realized.
 You have convergence of services and policies, since wired and wireless traffic are
terminated at the same place in the network – on the access-layer Catalyst 3850 switches.
This allows for functions such as QoS, security ACLs, and NetFlow to be applied the same
way, and at the same place and time, in the network for both wired and wireless traffic
flows – thus providing a convergence of wired and wireless policies and services within the
network infrastructure as shown.
 An increase in performance and scalability is also realized with converged access, due to
the distributed nature of the deployment – an important consideration as client counts
increase, and the network moves towards 802.11ac and the increased bandwidths and
traffic utilization that both of these trends imply.
 Finally, all of the advanced traffic visibility functions that you have long enjoyed within the
wired network infrastructure—such as NetFlow—now apply equally to both wired and
wireless traffic. And since the Catalyst 3850 provides an advanced set of QoS capabilities
(well beyond the access switch platforms that preceded it), a great deal of control is gained
over both wired and wireless traffic flows at the access layer of the network.
Wrap-up and Final Thoughts
This topic describes a final summary of the lesson.
Control plane functionality

on NG Controller
(also possible on upgraded 5508s, WiSM2s for
brownfield deployments, or NG Converged Access
switches for small, branch deployments)
Next-Generation WLAN Controller (5760)
Controller
Data plane functionality on NG Switches

(also possible on NG Controllers, for deployments
in which a centralized approach is preferred)
Next-Generation Switches (Catalyst 3850s)

Enabled by Cisco’s strength
inSilicon and Systems … An Evolutionary Advance to Cisco’s Wired
UADP ASIC + Wireless Portfolio, to address device and
bandwidth scale, and services demands ….
Mobility Domain MO ISE PI
Mobility Group
Cisco
MC MC Converged
Access
Deployment
Sub-Domain Sub-Domain
#1 #2
An Evolutionary
advance to Cisco’s
SPG SPG
wired + wireless
MA MA MA MA MA MA portfolio, to address
device and bandwidth
scale, and services
demands ….
In this lesson you reviewed the challenges related the dramatic increases in users, number of
wireless devices, bandwidth needs, and how the wireless network is becoming more and more
mission critical.
One option to address these issues has been to take a controller and split the functionality of the
controller into two places in the network.
There is a control plane that runs on a next generation controller. Keep in mind that it could be
in a discrete box like a 5760 or upgraded 5508 or WiSM2 or the controller function could
actually run on the 3850 itself. The 3850 would be used for small deployments and allow you
to do the data plane termination functionally on next gen switches.
Functionally, you split the controller architecture to run into places corresponding to the MC
and the MA function that you looked at before.
Converged access is an evolution to wireless deployments. It is simply another deployment
option, another tool in your tool kit that you can use at the appropriate place for next generation
integrated wired and wireless. It includes more integrated functionality, greater scalability, and
more visibility in the traffic flow. This treats the wired and wireless users equivalently in the
network and is important as you scale up.
Most other companies don’t control both the hardware and the software component in their
systems, and Cisco is unique in the industry in being able to do this.
The new ASIC that you built here, the Unified Access data plane, is the underpinning that
allows you to unify wired and wireless in a unique and powerful way.
Two new concepts have introduced:
 SPGs, the MA function which has only existed moving down into the switch, so the switch
becomes a full partner in a roaming mobility domain within those SPGs.
 The option for an MO, which allows for greater scalability on the mobility group side.
Summary
This topic summarizes the key points that you discussed in this lesson.
• To sum up, we have learned a lot about converged access in this module.
• The converged access solution, and the platforms that make it up, constitute an important new development in how wired
and wireless networks can be built and operated. By merging together the best elements of wired and wireless networking,
the Catalyst 3850 delivers a compelling new solution to address the three major trends seen in wireless today – growth in
terms of number of devices, growth in terms of bandwidth (such as 802.11ac), and growth in terms of the mission-criticality
in wireless network deployments. By combining the best of Cisco’s technology for wired and wireless components into a
single, unified, and highly innovative new access-layer switching platform, the Catalyst 3850 delivers a new option for wired
and wireless network deployments, representing the pinnacle of stackable access-layer switching capability in the industry
today.
• We reviewed the components that make up the converged access architecture – Mobility Controller (MC), Mobility Agent
(MA), Mobility Oracle (MO), and Switch Peer Groups (SPGs) – and the tasks addressed by each component within the
architecture. We compared and contrasted these components to their usage within a CUWN deployment model, which
also uses much of the same capabilities. We examined how SPGs in converged access can be used to localize roaming,
and scale the mobility deployment by introducing a layer of hierarchy into Mobility Groups. We examined how the various
converged access components interact, both with each other as well as with traditional CUWN deployments with which
they interoperate. And finally, we examined scalability of these components in the converged access solution.
• We also reviewed in some detail how roaming, QoS, security, and multicast all operate in a converged access network,
observing the benefits and capabilities that converged access delivers in each scenario, and with each set of capabilities.
We also examined various design options that are possible with converged access, ranging from small branch office
deployments up to major campus-wide implementations. Additionally, we touched upon migration from CUWN deployments
into converged access, and examined how that can be accomplished, and noted several of the items to be aware of when
doing so.
• Finally, we closed out by recapping on the advantages that converged access brings to wired/wireless deployments going
forward, by enabling greater traffic visibility, control, and scalability with a merged wired/wireless deployment at the network
edge.
Module Self-Check
Use the questions here to review what you have learned in this module. The correct answers
and solutions are found in the Module Self-Check Answer Key.
Q1) What are three of the wireless capabilities of the Cisco Catalyst 3850 switch? (Choose
three.) (Source: Converged Access Solution)
A) CAPWAP termination and DTLS in hardware
B) Up to 10G wireless capacity per switch
C) 50 APs and 1000 clients per switch stack
D) Wireless switch peer group support for faster roaming
E) Supports IPv4 and IPv6 client mobility
F) There is no need for an AP to be directly connected to a Cisco Catalyst 3850
switch
Q2) SPGs are a logical construct, not a physical one, and can be formed across Layer 2 or
Layer 3 boundaries. (Source: Converged Access Solution).
A) True
B) False
Q3) Converged access provides physical and logical entities. Identify which components
represent physical entities and which represent logical entities. (Source: Converged
Access Solution). Enter “a” for physical entity and “b” for logical entity.
_____ 1. Mobility Agent (MA)
_____ 2. Mobility Controller (MC)
_____ 3. Mobility Groups
_____ 4. Switch Peer Group (SPG)
_____ 5. Mobility Oracle (MO)
_____ 6. Mobility Domain
Q4) Many of the terms and components used to describe converged access also exist in
today’s unified wireless deployments. Which new components were added with
converged access deployments? (Choose two.) (Source: Converged Access Solution)
A) Mobility Agent (MA), which terminates CAPWAP from AP
B) Switch Peer Group (SPG), which is used to localize roaming
C) Mobility Oracle, which is used to allow greater Mobility Domain scalability
D) Mobility Controller (MC), which manages mobility within and across Sub-
Domains Radius (calling station ID)
E) Mobility Groups, which are used for grouping of Mobility Controllers (MCs)
Q5) Which new QoS features are supported when a converged access solution is used?
(Choose three). (Source: Converged Access Solution)
A) Approximate Fair Drop (AFD) Bandwidth Management ensures fairness at
client, SSID, and radio levels for NRT traffic
B) Policing capabilities per-SSID downstream and per-client upstream
C) Per SSID bandwidth management for more deterministic per-SSID bandwidth
allocation
D) Tunnel termination allows customers to provide QoS treatment per SSIDs, per-
clients and common treatment of wired and wireless traffic throughout the
network
E) Usage-based fair allocation using the Approximate Fair Drop (AFD)
Bandwidth Management three-step configuration on Cisco Catalyst 3850
platform and two-step configuration on Cisco Controller 5760 platform
Q6) With the introduction of Cisco Catalyst 3850, you have the ability to authenticate
multiple MAC addresses on a port. Every time a new MAC address is learned, that
MAC address has to authenticate. With this functionality, VMs can not only be on their
own network, you can dynamically add a VLAN for each of the VMs that is running
based on the authorization when the user logs in. (Source: Converged Access Solution)
A) True
B) False
Q7) By introducing the Cisco Catalyst 3850 into the network, you can apply a different type
of policy at different levels. For which level is that statement true? (Source: Converged
Access Solution)
A) At the switch port level on ingress into the switch
B) At the SSID level
C) At the radio level
D) All of the above.
Q8) Converged access security architecture provides increased scalability by optimizing a
balance of centralized and distributed architecture. (Source: Converged Access
Solution)
A) True
B) False
Q9) Which two statements about converged access multicast is true? (Choose two.)
(Source: Converged Access Solution)
A) Multicast on the WLC and UA 3850 uses the strength of multicast
management within IOSd
B) Multicast roaming is handled seamlessly for Layer 2-roam type only
C) Broadcast forwarding and multicast forwarding are not handled separately.
You must use both for IPV4 and/or for IPv6)
D) Wireless multicast group membership for wireless clients is managed by the
IGMP snooping module
Q10) What are the characteristics of large campus deployment with 3850s as MAs only and
centralized or distributed MCs? (Choose three). (Source: Converged Access Solution)
A) Allows for advanced QoS, NetFlow, and other services for wireless and wired
traffic
B) Supports Layer 3 roaming and provides scalability by keeping many roams
localized to SPGs
C) Good availability due to MA redundancy (3850 stacks) and MC redundancy
(controllers)
D) Good availability due to MA/MC redundancy within the 3850 stacks
E) Up to 250 APs supported.
Q1) A, D, E
Q2) A
Q3) 1-a, 2-a, 3-,b 4-b, 5-a, 6-b
Q4) B, C
Q5) A, C, D
Q6) A
Q7) D
Q8) A
Q9) A, D
Q10) A, B, C

UA SE Bootcamp - Student - Part 1

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

UA SE Bootcamp - Student - Part 1

Caricato da

Copyright:

Formati disponibili

UASEBC

• Provide training that will lead to

© 2013 Cisco Systems, Inc. CONFIDENTIAL Course Introduction 3

• Single Pane of Glass

© 2010 Cisco and/or its affiliates. All rights reserved. 6

For Branch / Small Campus

One Management and Policy with Prime and ISE

Converged Backbone & Instant

© 2013 Cisco Systems, Inc. CONFIDENTIAL Course Introduction 5

LAN Mgmt Access

Customer: Health to All Hospitals

One Policy, One Management, One Network Realized

• Increased resiliency, scalability, adaptability and visibility

• Improved ease of troubleshooting with quicker problem resolution

Prime Infrastructure provides One Management, central pane of glass for

• End-to-end application and service assurance visibility leveraging flexible NetFlow,

• Greatly enhances the visibility and troubleshooting capabilities of IT

© 2013 Cisco Systems, Inc. CONFIDENTIAL Course Introduction 7

Mod 6 Labs Module 9 Labs

LUNCH LUNCH LUNCH LUNCH LUNCH

© 2013 Cisco Systems, Inc. CONFIDENTIAL Course Introduction 9

© 2013 Cisco Systems, Inc. CONFIDENTIAL Course Introduction 11

One Network—Building the

Wired Unified Access

Traditionally, companies looked at themselves as isolated enterprises within a perimeter. These

Wireless LAN Controllers 1600 600 Series

NCS 1550 Series

5500 WiSM2 3500 Density

Cisco One Network includes the following core products:

Cisco Catalyst 3850 Series Switch

Cisco 5760 Wireless LAN Controller

Cisco Catalyst 6500 Series WiSM2 Software Enhancements

• Catalyst 6880-X • Catalyst 6807-XL

• Cisco StackPower technology provides power stacking among stack

Cisco StackPower Technology

Dual Redundant Modular Power Supplies

Cisco StackWise-480 Technology

Catalyst 6500 Supervisor 2T

Availability is the degree to which a system resists degradation or interruption of service as a

Graceful restart Graceful restart

Routing updates Routing updates

• Complex network design • Optimized network design • Simplified system

Network operators increase network reliability by configuring redundant pairs of network

Virtual Switch Domain

Active Control Plane Hot Standby Control Plane

Virtual Switch Link

Special link bundle joining two Cisco Catalyst

Virtual Switch Identifiers

Virtual Switch Link

Virtual Switch Roles

Control and Data Plane

Router MAC Address

Physical Topology Logical Topology

Traditional EtherChannel aggregates multiple physical links between two switches.

Note RPR mode is not supported with Catalyst 4500 VSS.

VSS Quad-Supervisor Uplink Forwarding

Use changeversion Command to Automate an IOS ISSU Upgrade

Switch# show issu state detail

Note Standby reloads with the target image.

Note Switchover occurs.

*Feb 25 20:54:16.092: %HA_CONFIG_SYNC-6-BULK_CFGSYNC_SUCCEED:

Smart Call Home IP SLAs

Protocol Analyzer EEM

Auto-QoS Auto Smartports Smart Install